Jedno wymaganie – kilka perspektyw

Wpadł mi nie­daw­no do skrzyn­ki mailo­wej kolej­ny arty­kuł ser­wi­su Modern Analyst, cytat:

If you cre­ate only one view of the requ­ire­ments, you must belie­ve it. You have no other cho­ice. If you deve­lop mul­ti­ple views, tho­ugh, you can com­pa­re them to look for discon­nects that reve­al errors and dif­fe­rent inter­pre­ta­tions. (źr. Why Create Multiple Requirements Views? > Business Analyst Community & Resources | Modern Analyst > Business Analyst Articles & Systems Analysis Articles | Modern Analyst).

Autor suge­ru­je by łączyć wyma­ga­nia funk­cjo­nal­ne z przy­pad­ka­mi uży­cia, testa­mi, mode­la­mi. W dużym uprosz­cze­niu: jeże­li mamy tyl­ko jed­ną per­spek­ty­wę wyma­gań (np. w posta­ci listy wyma­gań funk­cjo­nal­nych i poza­funk­cjo­nal­nych) musi­my im wie­rzyć bo nie mamy ich wery­fi­ka­to­ra (nie mamy inne­go wyj­ścia). Troszkę to łącze­nie każ­dy z każ­dym” chy­ba jed­nak nie ułatwia:

źr. http://​www​.moder​na​na​lyst​.com/

Problem kom­plet­no­ści i spój­no­ści wyma­gań jest dość trud­ny do roz­wią­za­nia. Wymagania nie­kom­plet­ne i nie­spój­ne potra­fią zaś zabić pro­jekt, wady spe­cy­fi­ka­cji (takie jak nie­kom­plet­ność i nie­spój­ność) skut­ku­ją odkry­wa­niem ich w trak­cie pro­jek­tu, rośnie w nie­kon­tro­lo­wa­ny spo­sób zło­żo­ność projektu.

Jeżeli wypra­cu­je­my wię­cej per­spek­tyw, może­my je skon­fron­to­wać i porów­nać, wykry­wa­jąc ewen­tu­al­ne nie­ści­sło­ści i błę­dy. Także [[BABoK]] (rodem z [[IIBA]]) zale­ca utrzy­my­wa­nie tak zwa­nej śla­do­wal­no­ści, to jest wywo­dze­nia np. wyma­gań na opro­gra­mo­wa­nie z wyma­gań biz­ne­so­wych, a tych z celu pro­jek­tu. Nadal jed­nak mamy tyl­ko jed­no źró­dło dla każ­de­go wyma­ga­nia. To rodzi pew­ne ryzy­ko, gdyż brak wery­fi­ka­to­ra powo­du­je, że ryzy­ko błę­du pozostaje.

Od kil­ku lat sto­su­je meto­dę pole­ga­ją­cą na testo­wa­niu lub spe­cy­fi­ko­wa­niu reli­za­cji wyma­gań. Rok 2008, na zakoń­cze­nie arty­ku­łu IEEE830-1998 ? czy pro­du­ku­je dobre wyma­ga­nia? napisałem:

Metodyka, któ­rą stosuję

  1. Wymagania funk­cjo­nal­ne to przy­pad­ki uży­cia sys­te­mu; Przypadki uży­cia sys­te­mu to czyn­no­ści wyse­lek­cjo­no­wa­ne z mode­lu pro­ce­sów na bazie zakre­su projektu.
  2. Wymagania nie­funk­cjo­nal­ne to ogra­ni­cze­nia nakła­da­ne na poszcze­gól­ne przy­pad­ki uży­cia (mogą być gru­po­wa­ne np. mak­sy­mal­ny czas odpo­wie­dzi sys­te­mu nie może prze­kro­czyć 1 s. z wyjąt­kiem rapor­tów, gdzie mak­sy­mal­ny czas odpo­wie­dzi to 1 minuta)
  3. Wymagania dzie­dzi­no­we opi­sy­wa­ne są mode­lem dzie­dzi­ny sys­te­mu (dia­gram klas lub ERD)

c.d. kie­dyś nastąpi?

Tak więc mamy ciąg dal­szy :). Wspomniałem o wyma­ga­niach dzie­dzi­no­wych. Osobiście trak­tu­ję je wła­śnie jako trze­cią nogę” wspie­ra­ją­cą model wyma­gań. Funkcjonalność (usłu­ga sys­te­mu) mówi nam cze­go ocze­ku­je użyt­kow­nik, jed­nak usłu­ga sys­te­mu” opi­su­je sys­tem jako tak zwa­ną czar­ną skrzyn­kę”. Jeżeli uzu­peł­ni­my opis wyma­gań ele­men­ta­mi mode­lu dzie­dzi­ny, doda­my wery­fi­ka­tor w posta­ci opi­su wnę­trza tej czar­nej skrzyn­ki (wyma­ga­my nie tyl­ko two­rze­nia fak­tu­ry VAT” ale defi­niu­je­my jej struk­tu­rę, to się nazy­wa opis bia­łej skrzynki”).

Jak wspo­mnia­łem swe­go cza­su, opra­co­wu­jąc wyma­ga­nia na goto­we i zaawan­so­wa­ne opro­gra­mo­wa­nie nie ma sen­su jego pro­jek­to­wa­nie. Zbyt szcze­gó­ło­wa spe­cy­fi­ka­cja zbli­ża nas do pro­jek­tu, a my chce­my jed­nak coś goto­we­go (ma być taniej i szybciej).

Standardowo, spe­cy­fi­ku­jąc wyma­ga­nia, nale­ży sku­pić się na tym do cze­go będzie­my uży­wa­li opro­gra­mo­wa­nia a nie na tym jak ono to robi. Jednak do cze­go” ozna­cza co będzie­my two­rzyć i prze­twa­rzać”. Co więc robić? Proszę popatrzeć:

Tak więc wymaganie:

  1. koja­rzy­my z reali­zu­ją­cym je mode­lem (przy­pad­kiem uży­cia, pro­ce­sem, ele­men­tem dziedziny),
  2. koja­rzy­my z testem spraw­dza­ją­cym czy zosta­ło speł­nio­ne (z pomo­cą dobra­ne­go sce­na­riu­sza testowego).

Powszechnie posłu­gu­je­my się wyma­ga­nia­mi funk­cjo­nal­ny­mi. Czym jest wyma­ga­nie dzie­dzi­no­we? Wyobraźmy sobie, że chce­my opi­sać wszyst­kie meto­dy i sce­na­riu­sze wysta­wie­nia fak­tu­ry VAT. Będzie ich bar­dzo dużo, zapew­ne moż­li­we będą takie, któ­rych nie wymy­śli­li­śmy”. Bezpieczniej jest opi­sać fak­tu­rę VAT wraz z regu­ła­mi rzą­dzą­cy­mi jej poszcze­gól­ny­mi pola­mi, zamiast uznać ją za czar­ną skrzyn­kę” i pró­bo­wać opi­sać meto­dą jak moż­na jej użyć”.

Młotek moż­na opi­sać tym do cze­go będzie uży­wa­ny” (przy­pad­ki uży­cia) lub jak wyglą­da”. Nie raz dru­ga meto­da jest bez­piecz­niej­sza, jed­nak jest to już pro­jek­to­wa­nie i nale­ży to robić świa­do­mie. Czy to źle? Nie, bo nie raz zapro­jek­to­wa­nie jest mniej ryzy­kow­ne niż opis do cze­go” (zamiast zło­żo­ne­go opi­su wie­lu zasto­so­wań młot­ka, pro­ściej jest go narysować).

Zawsze, przy każ­dym wyma­ga­niu, nale­ży pod­jąć decy­zję, czy reali­za­cja wyma­ga­nia przez dostaw­cę sta­no­wi ryzy­ko (i jakie). Sami pro­jek­tu­je­my reali­za­cję (two­rzy­my model) zawsze, gdy to ryzy­ko jest za duże by je akcep­to­wać. Podobnie trak­tu­je­my testy. Projektujemy je, gdy koszt nie­speł­nie­nia dane­go wyma­ga­nia prze­kra­cza dopusz­czal­ny poziom. Testem może być tak­że model (np. pro­ce­su biznesowego).

Takie podej­ście powo­du­je, że zanim jesz­cze dotknie­my goto­we­go pro­duk­tu (tu nie­ste­ty już po jego wybo­rze) może­my po pierw­sze: prze­te­sto­wać samą spe­cy­fi­ka­cję a po dru­gie prze­ka­zać poten­cjal­ne­mu dostaw­cy (na eta­pie zapy­ta­nia) peł­ną infor­ma­cję o tym, cze­go ocze­ku­je­my od pro­duk­tu i jak to sprawdzimy.

Powyższe podej­ście w posta­ci «full wypas” może być pra­co­chłon­ne, dla­te­go moż­li­we są warian­ty pośred­nie, czy­li tyl­ko dla wyma­gań ozna­czo­nych jako ryzy­kow­ne budu­je­my testy lub mode­le, jed­nak mamy narzę­dzie do pano­wa­nia nad tym ryzy­kiem. Po dru­gie zysku­je­my narzę­dzie do wery­fi­ka­cji, odbiór opro­gra­mo­wa­nia nie będzie spraw­dza­niem pokaź­nej i ryzy­kow­nej zara­zem listy dzie­sią­tek cech, będzie jaz­dą prób­ną na sucho”, a więc rela­tyw­nie tanią i pew­ną meto­dą testów: dostaw­ca dekla­ru­je (ofer­ta na nasze zapy­ta­nie) zgod­ność z naszy­mi wyma­ga­nia­mi, a te są wery­fi­ko­wal­ne. Należy roz­wa­żać zawsze koja­rze­nie mode­li z testami.

Kiedy jesz­cze pisze­my reali­za­cję”? Gdy chce­my pozo­stać jej auto­ra­mi i chro­nić nasz know-how.

Analiza przedwdrożeniowa ? czym jest

Praktycznie każ­dy klient pyta mnie:

Czy wybra­ny dostaw­ca opro­gra­mo­wa­nia będzie prze­pro­wa­dzał wła­sną ana­li­zę pod kątem wdro­że­nia z Pana aktyw­nym udziałem?

Na co zawsze odpo­wia­dam, że:

Dostawca skła­da ofer­tę w odpo­wie­dzi na otrzy­ma­ne zapy­ta­nie, zawie­ra­ją­ce mię­dzy inny­mi Raport z Analizy Biznesowej oraz Wymagania. Wybrany Dostawca jako pierw­szy krok, na pod­sta­wie doku­men­tów jakie otrzy­mał, opra­co­wu­je Koncepcję Wdrożenia. Koncepcja Wdrożenia to doku­ment opi­su­ją­cy to, jak Dostawca pla­nu­je prze­pro­wa­dzić wdro­że­nie swo­je­go pro­duk­tu, czy­li jak speł­ni Wymagania. Składając ofer­tę Dostawca potwier­dził, że jest w sta­nie wdro­żyć Rozwiązanie i speł­nić Wymagania, więc jakie­kol­wiek powta­rza­nie ana­li­zy fir­my Zamawiającego nie ma pra­wa się wyda­rzyć. Wszelkie infor­ma­cje potrzeb­ne do opra­co­wa­nia Koncepcji Wdrożenia, Dostawca czer­pie z tre­ści otrzy­ma­ne­go Raportu z Analizy Biznesowej [z mate­ria­łów dostar­czo­nych przez Zamawiającego], w razie dodat­ko­wych pytań, Raport ten jest uzu­peł­nia­ny [przez jego auto­ra w ramach nad­zo­ru autor­skie­go]. Jeżeli dodat­ko­we pyta­nia tego wyma­ga­ją, mają miej­sce dodat­ko­we kon­sul­ta­cje moje [auto­ra ana­li­zy] z Zamawiającym. Takie podej­ście mini­ma­li­zu­je wszel­kie (nie­ste­ty bar­dzo czę­ste) pró­by wpły­wu i per­swa­zji Dostawcy na Zamawiającego w celu nie­kon­tro­lo­wa­ne­go [przez Zamawiającego] wpły­wu na Wymagania.

Podsumowując: nie ma żad­ne­go powo­du, by Dostawca pro­wa­dził (powta­rzał) jaką­kol­wiek ana­li­zę”, opra­co­wu­je Koncepcję Wdrożenia, po jej zatwier­dze­niu reali­zu­je ją. Bardzo waż­ne! Umowa powin­na zawie­rać klau­zu­lę, gwa­ran­tu­ją­cą obu stro­nom moż­li­wość roz­wią­za­nia umo­wy w przy­pad­ku bra­ku poro­zu­mie­nia co do tre­ści Koncepcji Wdrożenia. (źró­dło: Jarosław Żeliński – Analizy i Badania Systemowe orga­ni­za­cji)

________

Tak więc ana­li­za przed­wdro­że­nio­wa to jest jakaś pra­ca, jej pro­duk­tem mogą być róż­ne tre­ści. Dlatego wła­śnie war­to pytać wyko­naw­cę takiej ana­li­zy o to, co będzie jej pro­duk­tem i do cze­go on posłu­ży. (źr. Wymagania na opro­gra­mo­wa­nie ERP a ana­li­za przed­wdro­że­nio­wa ? gdzie róż­ni­ca?).

Metodyk wdro­że­nio­wych jest tyle ilu dostaw­ców sys­te­mów i ana­li­ty­ków. Ich prze­gląd pozwa­la je jed­nak uogól­nić do nastę­pu­ją­cej postaci:

  1. Analiza przed­wdro­że­nio­wa.
  2. Opracowanie kon­cep­cji wdrożenia.
  3. Wdrożenie.

Z opi­sów wyni­ka, że pierw­szy etap to naj­czę­ściej wywia­dy (warsz­ta­ty) z pra­cow­ni­ka­mi, w ich wyni­ku powsta­je spe­cy­fi­ka­cja wyma­gań. Równolegle lub póź­niej powsta­je (naj­czę­ściej z udzia­łem kadr IT zama­wia­ją­ce­go) doku­ment: wyma­ga­nia poza­fun­cjo­nal­ne (inter­fej­sy, wydaj­no­ści, plat­for­ma, bez­pie­czeń­stwo itp..). Najczęściej dostaw­cy opro­gra­mo­wa­nia piszą, że:

Nasi kon­sul­tan­ci zbie­ra­ją od przed­sta­wi­cie­li fir­my infor­ma­cje o tym, jakie zada­nia ma reali­zo­wać apli­ka­cja (co?), a następ­nie przed­sta­wia­ją naj­efek­tyw­niej­sze roz­wią­za­nia funk­cjo­nal­ne i tech­nicz­ne (jak?) wraz z har­mo­no­gra­mem ich reali­za­cji (kie­dy?).

Kolejny przy­kład:

Koncepcja wdro­że­nia sys­te­mu, pod­czas któ­rej szko­li­my Grupę wdro­że­nio­wą, przy­go­to­wu­je­my listy wyma­ga­nych rapor­tów, wzo­rów doku­men­tów, instruk­cji robo­czych, opra­co­wu­je­my kon­cep­cję migra­cji danych i przy­go­to­wu­je­my pro­ce­du­ry pra­cy. (dostaw­ca oprogramowania)

Tu już temat wyma­gań spadł z listy, po pro­stu apli­ka­cja ma być, a mar­twi­my się się jak to zro­bić by była. Inny pomysł, dostaw­ca idzie jesz­cze dalej – cel jest taki sam zawsze:

…pro­po­nu­je­my zwy­kle pew­ne spraw­dzo­ne roz­wią­za­nia, któ­re przy­nio­są Klientowi mie­rzal­ne korzy­ści. Każde wdro­że­nie trak­tu­je­my indy­wi­du­al­nie, ale cel zawsze jest taki sam – wdro­żyć sys­tem w zakła­da­nym przez Klienta zakre­sie i cza­sie oraz przy kosz­tach nie wyż­szych niż planowane

Tak na praw­dę dostaw­cy opro­gra­mo­wa­nia z regu­ły od razu zaczy­na­ją od punk­tu: kon­cep­cja wdro­że­nia sys­te­mu XXX. Pojawia się czę­sto poję­cie spraw­dzo­ne roz­wią­za­nia. I nigdy nie wiem co to jest: wzo­rzec pro­jek­to­wy czy model refe­ren­cyj­ny. Pierwszy jest tyl­ko meto­dą (nadal nie mamy roz­wią­za­nia), dru­gi to naj­czę­ściej kopia pomy­słu poprzed­nie­go klienta.

Nie zmie­rzam do kry­ty­ki tego podej­ścia, chce poka­zać, że to natu­ral­na, z per­spek­ty­wy dostaw­ców opro­gra­mo­wa­nia, kon­cep­cja, bo biz­ne­so­wy cel każ­dej z tych firm to sprze­daż i wdra­ża­nie ofe­ro­wa­nych przez sie­bie produktów.

Do czego zmierzam?

Do tezy, mówią­cej: sko­ro dostaw­cy opro­gra­mo­wa­nia zaczy­na­ją od opra­co­wa­nia kon­cep­cji wdro­że­nia swo­je­go pro­duk­tu, to ktoś powi­nien przed nimi opra­co­wać w ramach ana­li­zy przed, spe­cy­fi­ka­cję potrzeb. Aby powsta­ła spe­cy­fi­ka­cja potrzeb powi­nien ktoś zde­fi­nio­wać pro­blem, wska­zać moż­li­we roz­wią­za­nia i oce­nić ich wykonywalność.

Nie ma tak­że sen­su szu­ka­nie pro­ble­mu na siłę tyl­ko po to, by wdro­żyć jakieś opro­gra­mo­wa­nie bo jego sprze­daw­ca tak chce. Dostawcy goto­we­go opro­gra­mo­wa­nia powin­ni się w koń­cu pogo­dzić z pro­stym ryn­ko­wym fak­tem: to oni są wybie­ra­ni a nie oni wybie­ra­ją, dokład­nie tak jak każ­dy inny pro­dukt na rynku.

Analiza systemowa jako analiza przedwdrożeniowa

Posłużmy się czymś takim jak Klasyczna ana­li­za systemowa.

Analiza sys­te­mo­wa to dzie­dzi­na wie­dzy doty­czą­ca pozna­nia ukła­dów orga­ni­za­cyj­nych i spo­so­bów ich dzia­ła­nia. Umożliwia łącze­nie dorob­ku róż­nych dzie­dzin nauki wokół wybra­nych pro­ble­mów. Ma cha­rak­ter inter­dy­scy­pli­nar­ny i syn­te­ty­zu­ją­cy, słu­żąc pro­jek­to­wa­niu przy­szłych struk­tur i dzia­łań w opar­ciu o kry­te­ria spraw­no­ścio­we. Doskonali i upo­wszech­nia skwan­ty­fi­ko­wa­ne meto­dy ana­li­zy wyko­rzy­stu­jąc meto­dę mode­lo­wa­nia mate­ma­tycz­ne­go i teo­re­tycz­ne kon­struk­cje odzwier­cie­dla­ją­ce w uprosz­czo­ny spo­sób rze­czy­wi­stość. Badania ope­ra­cyj­ne sta­no­wią pod­sta­wę ana­li­zy sys­te­mo­wej. Analiza sys­te­mo­wa ? to sztu­ka pozna­wa­nia i okre­śla­nia sys­te­mów dro­gą budo­wa­nia modeli.

Występujące w ota­cza­ją­cym nas świe­cie zja­wi­ska np. przy­rod­ni­cze, spo­łecz­ne, gospo­dar­cze, tech­nicz­ne, bez wzglę­du na ich rodzaj, zwy­kło się w potocz­nym rozu­mie­niu nazy­wać sys­te­ma­mi. Za sys­te­my uwa­ża się rów­nież kon­struk­cje abs­trak­cyj­ne, takie jak licz­by, infor­ma­cje, poję­cia, zada­nia, teo­rie. Analogicznie jako sys­tem trak­tu­je się tak­że zbio­ro­wo­ści wska­za­nych wyżej towa­rów kon­kret­nych i abs­trak­cyj­nych. (źr.http://​mfi​les​.pl/​p​l​/​i​n​d​e​x​.​p​h​p​/​A​n​a​l​i​z​a​_​s​y​s​t​e​m​owa)

Produkty pośred­nie i koń­co­wy takiej analizy:

  1. Ograniczenia, cele, kryteria
  2. Opis warian­tów
  3. Scenariusze i ich skutki
  4. Rekomendacje jako wynik analizy

Jakich pro­duk­tów nale­ża­ło by ocze­ki­wać w ana­li­zie przed­wdro­że­nio­wej czy­li, jak sama nazwa wska­zu­je, poprze­dza­ją­cej jakie­kol­wiek wdro­że­nie. Ano, bazu­jąc na pro­duk­tach kla­sycz­nej ana­li­zy systemowej:

  1. Opis aktu­al­nej sytu­acji fir­my i cel jaki chce zrealizować
  2. Opis i oce­nę moż­li­wych warian­tów reali­za­cji tego celu.
  3. Analiza sce­na­riu­szy dla każ­de­go warian­tu, mate­ria­łem do pra­cy tu są mode­le orga­ni­za­cji ana­li­zo­wa­nej (tu są i po to mode­le pro­ce­sów biz­ne­so­wych), moż­li­we, że jed­ną z metod osią­gnię­cia celu jest ich optymalizacja.
  4. W wyni­ku ana­li­zy wyni­ków tych testów (pro­of-of-con­cept) mamy reko­men­da­cje, to one zawie­ra­ją listę tego czym powin­no się cha­rak­te­ry­zo­wać opro­gra­mo­wa­nie, jeże­li oka­że się, że to moż­li­wy spo­sób na reali­za­cje celu (bo nie koniecznie).

Tak więc, gdy­by uzna­no, że nale­ży kupić i wdro­żyć opro­gra­mo­wa­nie to nale­ży doko­nać jego wybo­ru. Mając mode­le (pro­ce­sy i tak­so­no­mie) poka­zu­je­my je dostaw­cy opro­gra­mo­wa­nia i pyta­my czy jego pro­dukt pasu­je do nasze­go mode­lu. Może paso­wać w czę­ści lub cało­ści. Po oce­nie kil­ku takich ofert:

  1. Znajdujemy opro­gra­mo­wa­nie pasu­ją­ce do całe­go nasze­go mode­lu i wdrażamy.
  2. Znajdujemy opro­gra­mo­wa­nie pasu­ją­ce tyl­ko do czę­ści nasze­go mode­lu, wybie­ra­my naj­lep­sze. Dla pozo­sta­łych potrzeb wyko­nu­je­my pro­jekt ich logi­ki: to pro­jekt budo­wy (mecha­nizm dzia­ła­nia) bra­ku­ją­ce­go modu­łu, usłu­gi apli­ka­cyj­nej lub odręb­nej aplikacji.

Mamy więc ana­li­zę biz­ne­so­wą i spe­cy­fi­ko­wa­nie wyma­gań poprzez opra­co­wa­nie wery­fi­ko­wal­nych mode­li a nie tyl­ko listę potrzeb, któ­rej nie­ste­ty nie da się zwe­ry­fi­ko­wać co do kom­plet­no­ści i spój­no­ści bo nie ma narzę­dzia spraw­dza­ją­ce­go. Co jest takim narzę­dziem? Ano mode­le i to, że powsta­ły (jeże­li powsta­ły) przy pomo­cy sfor­ma­li­zo­wa­nej notacji.

Projekt taki ma trzy wyróż­nio­ne eta­py i pro­duk­ty zara­zem. Pierwszy, ana­li­za biz­ne­so­wa, to two­rze­nie mode­lu pro­ce­sów biz­ne­so­wych i tak­so­no­mii orga­ni­za­cji. Celem tego eta­pu jest stwo­rze­nie mode­li, któ­re w dal­szej czę­ści prac nie­ja­ko zastą­pią nam fir­mę (opi­su­ją ja w spo­sób kom­plet­ny). Są one zawsze testo­wa­ne a jeże­li zaj­dzie taka potrze­ba, tak­że opty­ma­li­zo­wa­ne. Jest to klu­czo­wy etap całej ana­li­zy przed­wdro­że­nio­wej. Są to pod­sta­wo­we mode­le, posłu­żą do testo­wa­nia hipo­tez (sce­na­riu­szy) opi­su­ją­cych cele biz­ne­so­we i ren­tow­ność (patrz wcze­śniej­szy opis ana­li­zy sys­te­mo­wej) a póź­niej będą pod­sta­wą ewen­tu­al­ne­go pro­jek­to­wa­nia oprogramowania.

Kolejny etap to spe­cy­fi­ko­wa­nie wyma­gań. Rzadko kie­dy daje się dostaw­com opro­gra­mo­wa­nia model pro­ce­so­wy z uwa­gi na to, że nie pre­cy­zu­je on dokład­nie zakre­su pro­jek­tu (opi­su­je cała fir­mę). Dlatego dla dostaw­cy opro­gra­mo­wa­nia two­rzy się Specyfikacje Wymagań, powsta­je ona w języ­ku dostaw­cy. Zależnie od kon­wen­cji powsta­je spe­cy­fi­ka­cja zawie­ra­ją­ca: opis kon­cep­cji roz­wią­za­nia, sta­no­wi ona opis i kon­tekst cało­ści. Kolejnym ele­men­tem są wyma­ga­nia funk­cjo­nal­ne (usłu­gi apli­ka­cji, jej przy­pad­ki uży­cia) i ich ogra­ni­cze­nia (ja raczej nie sto­su­je ter­mi­nu wyma­ga­nia poza­funk­cjo­nal­ne). Ograniczenia są koja­rzo­ne z poszcze­gól­ny­mi wyma­ga­nia­mi a uogól­nia­ne na całość. W tej czę­ści sto­su­ję mode­le przy­pad­ków uży­cia (nota­cja UML).

Ostatni etap to pro­jek­to­wa­nie. Polega na prze­pro­wa­dze­niu ana­li­zy obiek­to­wej i zapro­jek­to­wa­niu kon­cep­cji archi­tek­tu­ry roz­wią­za­nia oraz opra­co­wa­nia mode­lu dzie­dzi­ny czy­li mode­lu reali­za­cji logi­ki biz­ne­so­wej pzrez przy­pad­ki uży­cia (patrz wcze­śniej­sze artykuły).

Analizę biz­ne­so­wą wyko­nu­je zawsze z powo­dów chy­ba oczy­wi­stych. Specyfikowanie wyma­gań, jeże­li przed­mio­tem pro­jek­tu będzie opro­gra­mo­wa­nie. Projektowanie doty­czy tych ele­men­tów, któ­re nie zna­la­zły się w goto­wym opro­gra­mo­wa­niu i potrzeb­ne są dedy­ko­wa­ne podsystemy.

Czy to kosz­tow­na meto­da? Z moich wyli­czeń ryzy­ka finan­so­we­go wyni­ka, że pro­go­wą war­to­ścią jest budżet na cały pro­jekt rzę­du ok. 75 tys. zaś ana­li­za jest usta­lo­nym pro­cen­tem tej war­to­ści (odzwier­cie­dla postrze­ga­ne ryzy­ko projektu).

Dla dostaw­ców powsta­je tu klu­czo­we ryzy­ko: ich pro­dukt może, w czę­ści lub cało­ści, nie speł­niać wyma­gań okre­ślo­nych przez model fir­my i spe­cy­fi­ka­cję wyma­gań. Może się oka­zać się, że ich pro­dukt zupeł­nie nie nada­je się dla tej kon­kret­nej fir­my. Dlatego dostaw­cy czę­sto od razu suge­ru­ją opra­co­wa­nie kon­cep­cja wdro­że­nia, któ­ra tak na pra­we jest stu­dium moż­li­wo­ści wdro­że­nia kon­kret­ne­go pro­duk­tu, w kon­se­kwen­cji powsta­je lista tego co wyma­ga mody­fi­ka­cji i lista tego co nie zosta­nie zre­ali­zo­wa­ne. Produkt goto­wy z defi­ni­cji ma ogra­ni­cze­nia wdro­że­nio­we bo jest, mimo dekla­ro­wa­nej para­me­try­za­cji, goto­wym pro­duk­tem a nie narzę­dziem pro­gra­mi­stycz­nym. Z tego powo­du moim zda­niem, moż­na już zauwa­żyć na ryn­ku pakie­ty ERP zmie­rza­ją­ce w stro­nę bycia śro­do­wi­skiem pro­gra­mi­stycz­nym. Tu warun­kiem ich podat­no­ści na zmia­ny jest to, czy wewnętrz­na inte­gra­cja reali­zo­wa­na jest poprzez współ­dzie­le­nie danych czy poprzez ich wymia­nę (pomię­dzy modu­ła­mi). Pierwsza meto­da w moich oczach dys­kwa­li­fi­ku­je pro­dukt, bo prak­tycz­nie jego mody­fi­ko­wal­ność jest bar­dzo ograniczona.

Czy dostaw­ca opro­gra­mo­wa­nia może wyko­nać tak opi­sa­ną ana­li­zę? Może. A może sam kupu­ją­cy? Też może. więc o co cho­dzi? O posia­da­ne kom­pe­ten­cje i ryzy­ko bra­ku obiektywizmu:

analityk wymagan
analityk biznesowy

Bardzo czę­sto spo­ty­kam się ze sto­so­wa­niem nor­my IEEE opi­su­jąc spe­cy­fi­ka­cję wyma­gań (napi­sa­łem o tym dwa lata temu, prze­czy­taj). Norma ta, IEEE830-1998, jed­nak w żad­nym stop­niu nie opi­su­je jak spe­cy­fi­ka­cja ma powstać, opi­su­je tyl­ko co ma zawie­rać doku­ment i zwra­ca uwa­gę, że doku­ment powi­nien być spój­ny a wyma­ga­nia wery­fi­ko­wal­ne, opi­su jak to osią­gnąć nie ma.

Problemem jest nie to, jak zapi­sać wyma­ga­nia, bo to mały pro­blem, a to skąd je wziąć.

Inny cytat na koniec:

jest wie­le metod, narzę­dzi, spo­so­bów zapi­su i mode­lo­wa­nia wyma­gań, pew­nie mogli­by­śmy dłu­go się sprze­czać, któ­re są lep­sze, a któ­re gor­sze. Chodzi jed­nak tak napraw­dę o war­to­ści jaki­mi powin­ni­śmy się kie­ro­wać spe­cy­fi­ku­jąc wyma­ga­nia – powin­ny one być zro­zu­mia­łe dla przy­szłych czy­tel­ni­ków, powin­ny być jed­no­znacz­ne, spój­ne, wery­fi­ko­wal­ne, łatwe do zmia­ny, kom­plet­ne i popraw­ne. (źr. Blog O wymaganiach)

_____

(aktu­ali­za­cja: 2016-10-03)

Obecnie już widać, że naj­sku­tecz­niej­szą for­mą doku­men­to­wa­nia wyma­gań, prze­ka­zy­wa­nych dostaw­cy roz­wią­za­nia, jest opra­co­wa­nie pro­jek­tu. Dokładnie tak jak w każ­dej innej inży­nie­rii”. Słowny i para-słow­ny (tabel­ki itp.) opis koła zęba­te­go nigdy nie zastą­pi rysun­ków technicznych…