[[Analiza wyma­gań]] to temat rze­ka, meto­dy są róż­ne ale nie będę pisał o zna­nych mi, tyl­ko o pew­nym podej­ściu sys­te­mo­wym” zorien­to­wa­nym na mode­le i wzor­ce pro­jek­to­we. Ale po kolei.

Ile mamy poziomów szczegółowości wymagań

Poziom szcze­gó­ło­wo­ści wyma­gań jest tema­tem wie­lu dys­ku­sji, pisa­łem tu już nie raz na ten temat. Tym razem nie o tym, że zarzą­dza­nie tysią­ca­mi deta­li dużych pakie­tów opro­gra­mo­wa­nia jest nie­moż­li­we (i nie­ra­cjo­nal­ne). Tym razem o tym, że sto­so­wa­ne wzor­ców, tu ana­li­tycz­nych i pro­jek­to­wych, poma­ga. Najpierw kil­ka słów o pozio­mach szcze­gó­ło­wo­ści, któ­re stosuję:

  • Najwyższy poziom abs­trak­cji to nazwa­nie celu biz­ne­so­we­go np. chce­my spraw­nie wysta­wiać fak­tu­ry VAT. Jedno zda­nie, bez szcze­gó­łów. To naj­czę­ściej jest cel spon­so­ra pro­jek­tu, któ­rym jest nie­jed­no­krot­nie ktoś z zarządu.
  • Kolejny etap to dopre­cy­zo­wa­nie tego wyma­ga­nia, w tym momen­cie powo­łu­je­my się albo na prze­pi­sy, któ­re opi­su­ją to wyma­ga­nie wystar­cza­ją­co szcze­gó­ło­wo (np. Ustawa o podat­ku VAT i Ustawa o rachun­ko­wo­ści). Jeżeli nie mamy na co się powo­łać posze­rza­my ten opis sami. Tu mamy do czy­nie­nia z usłu­gą sys­te­mu z per­spek­ty­wy zama­wia­ją­ce­go a z [[przy­pad­kiem uży­cia]] z per­spek­ty­wy oprogramowania.
  • Jeżeli opro­gra­mo­wa­nie mia­ło by być wyko­na­ne na zamó­wie­nie, powsta­je dodat­ko­wo uszcze­gó­ła­wia­ją­cy opis każ­dej usłu­gi zawie­ra­ją­cy: dane wej­ścio­we i ocze­ki­wa­ne dane wyj­ścio­we, wzo­ry for­mu­la­rzy do wpro­wa­dza­nia danych i wzór pro­duk­tu (tu wzór fak­tu­ry) oraz sce­na­riusz uży­cia czy­li ocze­ki­wa­nia zama­wia­ją­ce­go co do spo­so­bu pra­cy z przy­szłym pro­gra­mem. Opis taki robi ana­li­tyk-pro­jek­tant a jako źró­dło infor­ma­cji wystę­pu­je eks­pert dzie­dzi­no­wy (czę­sto przy­szły użytkownik).

I tu zaczy­na się cie­kaw­szy ciąg dal­szy. [[Przypadki uży­cia]] to tak zwa­ny [[opis czar­nej skrzyn­ki]], nic nie mówi o logi­ce jaką chce­my odtwo­rzyć, wbu­do­wać do nowe­go opro­gra­mo­wa­nia. Pojawia się waż­ne pyta­nie: jaką wie­dzę” ma mieć to opro­gra­mo­wa­nie? Przypadki uży­cia koja­rzy się z tak zwa­ny­mi Aktorami sys­te­mu. Są to okre­ślo­ne role, któ­re będą wyko­ny­wa­ne przez użyt­kow­ni­ków (np. Specjalista ds. Handlowych może peł­nić rolę fak­tu­rzy­sty – akto­rem jest Fakturzysta). Dopiero po zde­fi­nio­wa­niu wie­dzy jaką ma (ma mieć) Aktor, mamy pod­sta­wy defi­nio­wać wie­dzę” jakiej ocze­ku­je­my do opro­gra­mo­wa­nia (to cze­go nie potra­fi Aktor).

Czarna skrzyn­ka (wyłącz­nie przy­pad­ki uży­cia) jako wyma­ga­nie jest bar­dzo ryzy­kow­nym narzę­dziem, bo nie defi­niu­je tego jaką wie­dzę” ma mieć (odtwa­rzać) to opro­gra­mo­wa­nie. Tu potrzeb­ne jest okre­śle­nie z cze­go będą powsta­wa­ły ocze­ki­wa­ne pro­duk­ty (co jest potrzeb­ne do wysta­wia­nia fak­tu­ry VAT, np. pro­duk­ty i usłu­gi zna fak­tu­rzy­sta czy ma je pod­po­wia­dać oprogramowanie).

Potrzebny jest więc opis logi­ki biz­ne­so­wej, któ­rą chce­my zaim­ple­men­to­wać. Ten opis to sed­no pro­ble­mu pra­cy analityka.

I przy­szła pora na ana­li­zę”. Powszechnie nad­uży­wa­ne sło­wo ana­li­za oznacza:

ana­li­za [gr. anály­sis ?roz­ło­że­nie?, ?roz­biór?], roz­ło­że­nie pew­ne­go obiek­tu na ele­men­ty skła­do­we (czę­ści, cechy, rela­cje); może być zabie­giem fizycz­nym lub czyn­no­ścią myślo­wą; (za Encyklopedia PWN).

Słowo klucz: ele­men­ty skła­do­we”. W meto­dach pra­cy, któ­re sto­su­ję, powyż­sze jest pod­sta­wo­wym narzę­dziem” pra­cy. Ale tu małe wyja­śnie­nie: nie­ste­ty więk­szość spo­ty­ka­nych doku­men­tów ana­li­tycz­nych, nie wie­le ma wspol­ne­go z ana­li­zą. Dlaczego? Skoro ana­li­za to roz­ło­że­nie na ele­men­ty skła­do­we”, to czym jest zapis życzeń i ocze­ki­wań wyar­ty­ku­ło­wa­ny usta­mi pra­cow­ni­ków jakiejś fir­my czy orga­ni­za­cji na spo­tka­niach, w posta­ci tek­stu, tabel lub nie­for­mal­nych obraz­ków ? Jest po pro­stu jakimś spi­sem ale na pew­no nie analizą.

Żeby doko­nać jakiej­kol­wiek ana­li­zy musi­my sobie naj­pierw zde­fi­nio­wać jakieś ele­men­ty skła­do­we”. Analiza zda­nia pole­ga na wyod­ręb­nie­niu słów, koja­rze­niu ich w związ­ki itp. ale począt­kiem jest ist­nie­ją­cy słow­nik i regu­ły gra­ma­tycz­ne. Analiza che­micz­na to roz­ło­że­nie sub­stan­cji na z góry zna­ne pier­wiast­ki (pomi­jam ich odkry­wa­nie). Czym jest ana­li­za biz­ne­so­wa czy ana­li­za wymagań?

Analiza pro­ce­sów biz­ne­so­wych wyma­ga zro­zu­mie­nia tego co dzie­je się w ana­li­zo­wa­nej fir­mie i roz­ło­że­nie tego na pre­de­fi­nio­wa­ne ele­men­ty skła­do­we. W zasa­dzie mamy jeden: pro­ces biz­ne­so­wy. Jego defi­ni­cja okre­śla ato­mo­wy ele­ment takiej ana­li­zy. Jeżeli patrzy­my więc dia­gram zawie­ra­ją­cy pro­sto­ką­ty i linie będą­ce gra­ficz­nym zapi­sem tego co powie­dzia­no”, nie jest to żaden wynik ana­li­zy ani model a jedy­nie obraz­ko­wy zapis opowieści.

Dalej: pro­jek­to­wa­nie opro­gra­mo­wa­nia. Na czym pole­ga ana­li­za obiek­to­wa i pro­jek­to­wa­nie? Po pierw­sze zno­wu potrzeb­ne są ele­men­ty skła­do­we” (przy­po­mi­nam, że ma być ich skoń­czo­na licz­ba, mają zde­fi­nio­wa­ne zna­cze­nia, któ­re się na sie­bie nie nakła­da­ją (nic nie może paso­wać do dwóch defi­ni­cji jed­no­cze­śnie) i pozwa­la­ją, z usta­lo­na dokład­no­ścią, na zbu­do­wa­nie ana­li­zo­wa­nej całości.

Przykład

Opiszę jak moż­na pro­wa­dzić ana­li­zę i budo­wać część wyma­gań o nazwie model dzie­dzi­ny (model logi­ki biznesowej).

Zgodnie z powyż­szym nale­ży zacząć od zde­fi­nio­wa­na sobie skoń­czo­nej licz­by kloc­ków (ich typów). Np. LEGO, moż­na z nich zbu­do­wać wszyst­ko” akcep­tu­jąc pew­ną gra­ni­ce w odtwa­rza­niu uszcze­gó­łów. Typów pod­sta­wo­wych kloc­ków jest kil­ka a jed­nak moż­na z nich zbu­do­wać dom, samo­lot czy kaczkę:

Analiza pole­ga na tym, by real­ny dom lub kacz­kę roz­ło­żyć na skoń­czo­na licz­bę (z regu­ły nie wiel­ką) pro­stych ele­men­tów skła­do­wych, któ­rych słow­ni­kiem” jest posia­da­ny zestaw LEGO. Wynikiem ana­li­zy jest doku­ment” w posta­ci instruk­cji jak zło­żyć domek z LEGO”. Innymi sło­wy, mamy skoń­czo­ną licz­bę ele­men­tów budul­co­wych” ana­li­za pole­ga na zro­zu­mie­niu pro­ble­mu, roz­ło­że­niu go na takie wła­śnie elementy.

Osobiście jestem zwo­len­ni­kiem sto­so­wa­nia [[wzor­ca pro­jek­to­we­go MVC]] oraz sty­lu ana­li­zy i pro­jek­to­wa­nia zwa­ne­go DDD (ang. [[Domain Driven Design]], pro­jek­to­wa­nie ste­ro­wa­ne dzie­dzi­ną sys­te­mu, arty­kuł o DDD). DDD to wzor­ce zarów­no ana­li­tycz­ne jak i pro­jek­to­we. Te wzor­ce to wła­śnie takie ato­mo­we kloc­ki”.

Na eta­pie ana­li­zy, roz­kła­da­my” ana­li­zo­wa­ną fir­mę (jej część) na ele­men­tar­ne skład­ni­ki. W DDD są to poje­dyn­cze encje i ich agre­ga­ty, typy (value-object), usłu­gi, fabry­ki, repo­zy­to­ria. Analiza pole­ga na opi­sa­niu (roz­ło­że­niu jej ) całej logi­ki opro­gra­mo­wa­nia z pomo­cą tych kil­ku stan­dar­do­wych kloc­ków”. Model taki dla deve­lo­pe­ra sta­je się pro­jek­tem, a te kloc­ki wzor­ca­mi projektowymi.

Poniżej zaba­wo­wy” przy­kład takiej analizy.

Aktorem jest użyt­kow­nik. Potrzebny mu jest sys­tem” któ­ry da mu przed­miot wyko­na­ny z kloc­ków LEGO (domek). System cał­ko­wi­cie izo­lu­je Aktora od swo­je­go wnę­trza z pomo­cą Recepcji (View w mode­lu MVC). Wewnątrz mamy zestaw kloc­ków (encje, agre­ga­ty), deli­kwen­ta wie­dzą­ce­go jak wyko­nać domek (usłu­ga) oraz fabry­kę kloc­ków (na bazie wzor­ców two­rzy­my ich tyle ile potrze­bu­je­my, ile zażą­da usługodawca).

Aby zacho­wać wytwo­rzo­ne kloc­ki a tak­że wyni­ki prac czy pół­pro­duk­ty, musi­my mieć pudeł­ko na kloc­ki: repo­zy­to­rium. Nad cało­ścią czu­wa Kontroler, eki­pa ludzi zaj­mu­ją­ca się wszyst­ki­mi poza spe­cja­li­stycz­ny­mi” (poza-dzie­dzi­no­wy­mi) zada­nia­mi. Z racji tego, że takie poję­cia jak wydaj­ność, zaso­by, bez­pie­czeń­stwo itp. są uni­wer­sal­ne, taka eki­pa back offi­ce (skrzyn­ka na zabaw­ki, recep­cja, kon­tro­ler) może zostać wyna­ję­ta nie­mal­że dla każ­dej fir­my bez wzglę­du na bran­że (to się nazy­wa fra­me­work). Specyficzna jest tyl­ko dzie­dzi­na, tu typ klocków.

Tak więc ana­li­za wyma­gań na opro­gra­mo­wa­nie to lista wyma­ga­nych usług. Wymagania na dedy­ko­wa­ne opro­gra­mo­wa­nie zaś to nie jest spi­sa­nie i sor­to­wa­nie ocze­ki­wań. Analiza to roz­ło­że­nie pro­ble­mu (fir­ma klien­ta) na kloc­ki zgod­ne z uzna­ną (uży­wa­ną) meto­dy­ką i wzor­ca­mi. DDD (opis wzor­ców pro­jek­to­wych DDD) to wła­śnie jeden z takich zesta­wów klocków.

Wynikiem ana­li­zy jest model (a nie tyl­ko obra­zek) opi­su­ją­cy jak dzia­ła ana­li­zo­wa­na fir­ma, zbu­do­wa­ny z kloc­ków, tu opi­sa­nych w DDD.

Dla deve­lo­pe­ra taki model jest pro­jek­tem logicz­nym ([[Platform Independent Model w nomen­kla­tu­rze OMG/MDA]]). W efek­cie ana­li­tyk nie tyl­ko zro­zu­miał i udo­ku­men­to­wał pro­blem, ana­li­tyk zapro­jek­to­wał logi­kę biz­ne­so­wą opro­gra­mo­wa­nia, moż­li­wą do bez­po­śred­niej imple­men­ta­cji przez deve­lo­pe­ra (przy zało­że­niu, że sto­su­je meto­dy obiek­to­we i zna uży­te wzor­ce). Taki efekt dają meto­dy obiek­to­we i prag­ma­ty­ki np. DDD. Za to wła­śnie bar­dzo lubię obiek­to­wy para­dyg­mat i DDD: obiek­to­wość” zrów­nu­je wynik ana­li­zy z pro­jek­tem, DDD daje nam zestaw kloc­ków: słow­nik pojęć, zro­zu­mia­ły dla biz­ne­su” i dla deve­lo­pe­ra. DDD to zestaw wzor­ców pozwa­la­ją­cy na dogłęb­ne zro­zu­mie­nie ana­li­zo­wa­ne­go pro­ble­mu i będą­ce zara­zem pro­jek­tem jego implementacji.

Kim więc jest dobry analityk?

Jest to ktoś, kto potra­fi ana­li­zo­wa­ną orga­ni­za­cję roz­ło­żyć na ele­men­ty skła­do­we”. Tymi ele­men­ta­mi są wzor­ce pro­jek­to­we, ele­men­ty sto­so­wa­nej nota­cji. Wynik ana­li­zy to nie rysu­nek”, to model w posta­ci sche­ma­tu blo­ko­we­go (dia­gra­mu), na któ­rym każ­dy ele­ment ma ści­śle okre­ślo­ne znacz­nie, kon­struk­cję i zasa­dy wza­jem­ne­go łącze­nia i oddziaływania.

Analiza Biznesowa to roz­ło­że­nie ana­li­zo­wa­ne­go przed­mio­tu” na skoń­czo­ny zestaw ele­men­tów, któ­ry z okre­ślo­ną dokład­no­ścią zacho­wu­je się tak, jak ana­li­zo­wa­na orga­ni­za­cja. Jeżeli te ele­men­ty skła­do­we mają tak­że swo­je odwzo­ro­wa­nie w kodzie pro­gra­mu, to wynik ana­li­zy sta­je się pro­jek­tem tego oprogramowania.

Więc pozio­my szcze­gó­ło­wo­ści wyma­gań to:

  • cele biz­ne­so­we (pro­duk­ty pro­ce­sów biznesowych)
  • opis usług żąda­nych od opro­gra­mo­wa­nia (tu tak­że for­mat­ki papierowe/ekranowe, przy­pad­ki uży­cia oprogramowania)
  • opis (pro­jekt) wewnętrz­nej logi­ki biz­ne­so­wej (wewnętrz­ne ele­men­ty skła­do­we i sce­na­riu­sze ich współdziałania)

P.S.

Artykuł ma cha­rak­ter badaw­czy”, wszel­kie uwa­gi mile widziane.

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Ten post ma 4 komentarzy

  1. Hania Wesołowska

    Bardzo obra­zo­wa ta ana­lo­gia do kloc­ków lego:) Skończony zbiór kloc­ków, okre­ślo­ne zasa­dy łącze­nia. Po ana­li­zie potrzeb­ni nam są fachow­cy od skła­da­nia kloc­ków i mogą to zro­bić po otrzy­ma­niu instruk­cji od ana­li­ty­ka. Na tym przy­kła­dzie nawet dziw­nie wyglą­da­ło­by, gdy­by mie­li na pod­sta­wie zło­żo­ne­go, zaciem­nio­ne­go kształ­tu tego, co ma powstać, zga­dy­wać, jakie mia­ły­by tu być uży­te ele­men­ty. I budu­je­my taką kacz­kę (z tylu ele­men­tów), na jaką stać zamawiającego.

    Żeby poznać te ele­men­ty pod­sta­wo­we pew­nie przy­da się lepiej przy­bli­żyć sobie DDD.

    1. Jarek Żeliński

      Od pew­ne­go cza­su jestem gorą­cym orę­dow­ni­kiem” DDD bo fak­tycz­nie two­rzy wspól­ny język ana­li­tyk biz­ne­so­wy – deve­lo­per… wyma­ga to od ana­li­ty­ków jed­nak pozna­nia i zro­zu­mie­nia metod obiek­to­wych ana­li­zy bo obiek­to­we meto­dy two­rze­nia sto­su­ję programiści.…

  2. TOMIN

    Jarku zga­dzam się w 100%. Takie są rów­nież moje doświadczenia.
    1. Analiza biz­ne­so­wa to nie 1000 wier­szy o sadze­niu gro­chu” – zapis wypo­wie­dzi użyt­kow­ni­ka. Dopiero odpo­wied­nie dia­gra­my oraz opar­cie się o wzor­ce pro­jek­to­we (kloc­ki;)) pozwa­la odkryć rze­czy­wi­sty cha­rak­ter pro­ce­sów biz­ne­so­wych oraz wyma­gań w sto­sun­ku do sys­te­mu”.
    2. Same przy­pad­ki uży­cia to dopie­ro począ­tek. Podejście do opro­gra­mo­wa­nia i wyma­gań klien­ta na zasa­dzie czar­nej skrzyn­ki”, bez ana­li­zy pro­ce­su oraz danych, to tak jak­by robić pro­jekt domu okre­śla­jąc tyl­ko licz­bę i roz­miar okien i drzwi;)

  3. Sławomir Sobótka

    Pocieszające, że są Analitycy, któ­rzy zasta­na­wia­ją się po co, komu i do cze­go mają słu­żyć ich arte­fak­ty. Wszyscy gra­my do wspól­nej bram­ki” – cho­dzi o powsta­nie dzia­ła­ją­ce­go sys­te­mu (któ­ry robi lub oszczę­dza pie­nią­dze), a nie jak to cza­sem bywa o wypro­du­ko­wa­nie rela­cji z wła­snych prze­żyć zwią­za­nych z pró­bą zro­zu­mie­nia domeny.

    Generalnie w doku­men­ta­cji na każ­dym pozio­mie bra­ku­je czę­sto zasta­no­wie­nia nad pro­stą kwe­stią: dla kogo ją two­rzę, jakie potrze­by i pyta­nia będzie miał jej odbior­ca (ew. ja za kil­ka miesięcy).

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.