Fundament analizy: metodyka

Nieco ponad rok temu opi­sy­wa­łem sytu­ację, w któ­rej pewien doświad­czo­ny ana­li­tyk narze­kał, że pra­cow­ni­cy jego klien­tów nie potra­fią mu powie­dzieć cze­go chcą i jak ma dzia­łać ich przy­szły sys­tem. Odpowiedź moja jest w takich sytu­acjach zawsze taka sama:

…ana­li­za nie pole­ga na słu­cha­niu! (wyobra­ża­cie sobie lecze­nie, w któ­rym dia­gno­zy sta­wia­ją pacjen­ci?). Nie raz tu pisa­łem i kolej­ny raz powtó­rzę:
Analiza opar­ta na zezna­niach i życze­niach jej [fir­my zama­wia­ją­ce­go] pra­cow­ni­ków jest bar­dzo nara­żo­na na fia­sko, gdyż subiek­tyw­na wie­dza pra­cow­ni­ków oraz ich spe­ku­la­cje, mogą nie mieć wie­le wspól­ne­go z rze­czy­wi­sto­ścią lub pożą­da­nym sta­nem (co nie musi być ich złą wolą). Analiza orga­ni­za­cji nie może więc pole­gać tyl­ko na zapi­sa­nych subiek­tyw­nych prze­ko­na­niach jej pra­cow­ni­ków. Powinna w być 100% opar­ta na fak­tach oraz na kon­tek­ście jaki two­rzy stra­te­gia budo­wa­na przez Zarząd. (źr. : Strategia? w przy­pad­ku 90% małych i śred­nich firm w Polsce bazo­wał­by Pan na niczym | | Jarosław Żeliński IT-Consulting) 

Na stro­nie opi­su­ją­cej meto­dy­kę pro­wa­dze­nia ana­liz, napisałem:

Analiza sys­te­mo­wa to pro­ces, opar­ty na ana­li­zie fak­tów, sto­so­wa­ny w pro­jek­tach o pod­wyż­szo­nym ryzy­ku (a pro­jek­ty infor­ma­tycz­ne do takich nale­żą, ponad 70% tych pro­jek­tów to nie­ste­ty pro­jek­ty nieudane).Podstawowe pyta­nia w ana­li­zie sys­te­mo­wej to: ?jak jest i dla­cze­go jest tak jak jest? oraz ?jak powin­no być i co nale­ży uczy­nić, aby było tak jak być powin­no?, mode­lo­wa­nie zaś to narzę­dzie a nie cel. Podejście sys­te­mo­we wymu­sza logicz­ną ana­li­zę reali­zo­wa­nych przez przed­się­bior­stwo dzia­łań, pro­po­nu­jąc opar­te na mode­lach podej­ście, pozwa­la zro­zu­mieć stan obec­ny i jego przy­czy­ny. Dzięki temu wyni­ki ana­liz sys­te­mo­wych są obiek­tyw­ne. (źr.: Analiza sys­te­mo­wa orga­ni­za­cji – audyt orga­ni­za­cji | Jarosław Żeliński IT-Consulting) 

Dzisiaj arty­kuł dla zain­te­re­so­wa­nych teorią…

Czym jest analiza systemowa?

Analiza sys­te­mo­wa to reali­zo­wa­nie pew­nej pro­ce­du­ry, któ­ra – jak pisze Koźmiński – wyglą­da tak:

Kluczowym ele­men­tem ana­li­zy sys­te­mo­wej jest mode­lo­wa­nie, czy­li stwo­rze­nie abs­trak­cji bada­ne­go zja­wi­ska (orga­ni­za­cji, pro­ce­sów, itp.), ana­li­za zaś jest pro­ce­sem ite­ra­cyj­nym. W obec­nych cza­sach, gdy mówi­my o ana­li­zie sys­te­mo­wej orga­ni­za­cji, są to z regu­ły mode­le pro­ce­sów biz­ne­so­wych, mode­le infor­ma­cyj­ne, mode­le logi­ki biz­ne­so­wej. Na eta­pie ana­li­zy i bada­nia, model taki sta­no­wi hipo­te­zę mówią­cą: tak dzia­ła dana orga­ni­za­cja. Jeżeli model zosta­nie uwia­ry­god­nio­ny fak­ta­mi, sta­no­wi teo­rię opi­su­ją­cą tę orga­ni­za­cję, czy­li moż­li­we są – z uży­ciem tego mode­lu – prze­wi­dy­wa­nia skut­ków wpro­wa­dza­nych zmian w orga­ni­za­cji. Jest to pro­ces prak­tycz­nie iden­tycz­ny a tym, jaki sto­su­je się w nauce:

Zgodnie ze sło­wa­mi same­go Alberta Einsteina punk­tem wyj­ścia każ­dej teo­rii nauko­wej muszą być fak­ty i one też muszą być punk­tem doce­lo­wym. Nie ma nauk empi­rycz­nych bez fak­tów. Jak widać na powyż­szym sche­ma­cie każ­dy nauko­wiec ? badacz musi umieć poru­szać się w dwu ?świa­tach” ? jako teo­re­tyk, znaw­ca dorob­ku danej dzie­dzi­ny z któ­re­go musi korzy­stać (i w związ­ku z tym znać go) aby umieć sfor­mu­ło­wać zało­że­nia teo­re­tycz­ne wyja­śnia­ją­ce zaob­ser­wo­wa­ne fak­ty oraz jako ?empi­ryk” ? musi znać meto­dy spraw­dza­nia wysnu­tych przez sie­bie hipo­tez i kon­cep­cji wyja­śnia­ją­cych świat fak­tów. Teoria (hipo­te­za), któ­ra nie daje się spraw­dzić empi­rycz­nie, nie moż­na jej pod­dać pró­bie fal­sy­fi­ka­cji jest dla nauk empi­rycz­nych zupeł­nie bez­u­ży­tecz­na i jako taka nie jest naukowa.

Tak zwa­na Analiza Biznesowa orga­ni­za­cji, to pro­ces ana­li­zy sys­te­mo­wej, powin­na być trak­to­wa­na jak nauka empi­rycz­na: nale­ży zebrać par­tię doku­men­tów ope­ra­cyj­nych, któ­re są niczym innym jak zapi­sem fak­tów z życia orga­ni­za­cji. Na ich pod­sta­wie powsta­ją mode­le, któ­re są testo­wa­ne z uży­ciem kolej­nej par­tii doku­men­tów. Wygląda to tak:

(źr. opra­co­wa­nie własne)

A wymagania?

Mam nadzie­ję, że opi­su­jąc meto­dy­ką pro­wa­dze­nia ana­li­zy sys­te­mo­wej orga­ni­za­cji meto­da­mi zwa­ny­mi nauko­wy­mi, pomo­gę zro­zu­mieć potrze­bę rze­tel­ne­go mode­lo­wa­nia. Często o tym pisze i mówię na kon­fe­ren­cjach: pod­sta­wą dobrej ana­li­zy jest rze­tel­ne sto­so­wa­nie for­ma­li­zmów uży­tych nota­cji oraz meto­dy­ka pro­wa­dze­nia i doku­men­to­wa­nia wyni­ków analizy.

A gdzie wyma­ga­nia? Otóż zgod­nie z MDA/MDE wyma­ga­niem jest pro­jekt sys­te­mu (a nie jego wyima­gi­no­wa­ne cechy). Związek mię­dzy ana­li­zą sys­te­mo­wą a pro­jek­to­wa­niem roz­wią­za­nia opi­sał Koźmiński :

Tak więc poszu­ki­wa­nie roz­wią­za­nia pro­ble­mu pole­ga na zro­zu­mie­niu mecha­ni­zmu dzia­ła­nia orga­ni­za­cji, pod­ję­ciu decy­zji o opty­mal­nej meto­dzie roz­wią­za­nia pro­ble­mu i opra­co­wa­niu roz­wią­za­nia, rozu­mia­ne­go jako roz­bu­do­wa lub zakup nowych, zaso­bów orga­ni­za­cji np. o nowe opro­gra­mo­wa­nie, któ­re sta­je się czę­ścią sys­te­mu jakim jest ta organizacja.

Wszelkie meto­dy opar­te na burzach mózgów przy­szłych użyt­kow­ni­ków pra­wie zawsze ska­zu­ją pro­jekt na poraż­kę, intu­icyj­ne opi­sy­wa­nie przy­szło­ści to tyl­ko nie­spraw­dzal­ne pro­jek­cje dotych­cza­so­wych doświad­czeń. Sam fakt, że pro­jekt wdro­że­nio­wy uda­ło się dopro­wa­dzić do koń­ca nie jest żad­nym suk­ce­sem, suk­ce­sem jest zro­bie­nie tego i to moż­li­wie naj­efek­tyw­niej, tak­że myśląc o tym, że po zakoń­cze­niu wdro­że­nia cią­giem dal­szym są kosz­ty utrzy­ma­nia i roz­wo­ju, o czym wie­lu zapomina.

Źródła

Zelinski, J. (2020). Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns. In Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities (pp. 78 – 89). IGI Global. https://​www​.igi​-glo​bal​.com/​b​o​o​k​/​a​p​p​l​i​c​a​t​i​o​n​s​-​a​p​p​r​o​a​c​h​e​s​-​o​b​j​e​c​t​-​o​r​i​e​n​t​e​d​-​s​o​f​t​w​a​r​e​/​2​3​5​699
Koźmiński, A. K. (1979). Decyzje: ana­ly­za sys­te­mo­wa orga­ni­za­cji. Pánstwowe Wydawn. Naukowe.

Poziomy szczegółowości wymagań – wzorce DDD – czyli czym jest analiza obiektowa

[[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.

Metoda naukowa w analizie biznesowej

Struktura analizy

Dokumenty, któ­re two­rzę, maja struk­tu­rę typo­wej pra­cy nauko­wej, czy­li skła­da­ją się z nastę­pu­ją­cych części:

  • Wprowadzenie: jak wyglą­da sytu­acja, co jest pro­ble­mem do roz­wią­za­nia (np. w danej orga­ni­za­cji), jak go stwier­dzo­no, jakie fak­ty świad­czą o tym, jaki jest cel.
  • Opis uży­tych metod.
  • Opis dzia­ła­nia bada­nej orga­ni­za­cji, rekomendacje.
  • Opis reko­men­do­wa­ne­go roz­wią­za­nia: pro­jekt zmian orga­ni­za­cyj­nych, opis (pro­jekt) reko­men­do­wa­ne­go opro­gra­mo­wa­nia, itp.
  • Opis dal­szych prac i podsumowanie.
  • Rejestr wszel­kich wyja­śnień udzie­lo­nych w kwe­stii tre­ści doku­men­tu i jego rozszerzeń. 

Zainteresowanych szcze­gó­ła­mi zapra­szam do dal­szej lek­tu­ry tego artykułu.

Krótko o metodzie naukowej

Dużo piszę na blo­gu o ana­li­zie wyma­gań opar­tej na mode­lach i ana­li­zie sys­te­mo­wej, jako pod­sta­wie meto­dy­ki pro­wa­dze­nia ana­liz. Są to ogól­nie tak zwa­ne meto­dy nauko­we . Cechy tego podejścia:

Idealny, prak­tycz­ny model meto­dy naukowej 

Tradycyjnie, nie­za­leż­nie od roz­ma­itych kwe­stii filo­zo­ficz­nych i spo­łecz­nych, zazwy­czaj przyj­mu­je się, że na meto­dę nauko­wą skła­da się nastę­pu­ją­cy zbiór czyn­no­ści ?*?:

  • Obserwacje wstęp­ne
  • Budowanie hipo­te­zy
  • Wykonywanie rze­tel­nych eks­pe­ry­men­tów wery­fi­ku­ją­cych hipo­te­zę lub rze­tel­ne zbie­ra­nie danych histo­rycz­nych mają­cych potwier­dzić teo­rię lub jej zaprzeczyć
  • Przyjęcie lub odrzu­ce­nie hipo­te­zy w opar­ciu o zebra­ne dane.
  • Powtarzanie pro­ce­du­ry – czy­li sta­ła wery­fi­ka­cja sta­rych i budo­wa­nie nowych hipo­tez w momen­cie gdy sta­re prze­sta­ją się sprawdzać.

Ponadto, wyni­ki badań nauko­wych pod­da­ne muszą być kry­ty­ce innych naukowców.

Jednym z pod­sta­wo­wych narzę­dzi metod nauko­wych, jest tak zwa­na idealizacja:

Idealizacyjna Koncepcja Nauki
Punktem wyj­ścia ide­ali­za­cyj­nej kon­cep­cji nauki było spo­strze­że­nie (1968, ss.80n., 1970a, 1971a […]), że wbrew induk­cjo­ni­zmo­wi, nauki empi­rycz­ne nie uogól­nia­ją fak­tów empi­rycz­nych w pra­wa ? pra­wa mówią o gazach (ryn­kach, pra­wo­daw­cach, itd.) dosko­na­łych a fak­ty noto­rycz­nie wyda­rza­ją się gazom (ryn­kom, pra­wo­daw­com, itd.) dale­kim od dosko­na­ło­ści, bo ?real­nie ist­nie­ją­cym?. .

Idealizacja pole­ga roz­po­czy­na­niu wyja­śnia­nia doko­na­nych obser­wa­cji z uży­ciem mini­mal­ne­go mode­lu. Model tej jest testo­wa­ny kolej­ny­mi fak­ta­mi i roz­sze­rza­ny jest o ile wyma­ga tego wyja­śnie­nie kolej­nych fak­tów. Po kil­ku takich ite­ra­cjach model pod­da­wa­ny jest kry­ty­ce innych obser­wa­to­rów, może być dalej popra­wia­ny lub uzna­ny za popraw­ny (nie­pod­wa­żo­ny). Na tym eta­pie uzna­je­my, że tak powsta­ły model wyja­śnia obser­wo­wa­ne fak­ty: jest nauko­wą teo­rią wyja­śnia­ją­cą (meto­do­lo­gia nauk). Idealizacja, jako narzę­dzie, zna­la­zła tak­że zasto­so­wa­nie na polu ana­liz biz­ne­so­wych .

A co na naszym analitycznym podwórku?

Pojęcie model poja­wia się w pro­jek­tach ana­li­tycz­nych nie­mal­że w 100% przy­pad­ków. Potocznie mówi się, że powsta­ją mode­le pro­ce­sów biz­ne­so­wych, mode­le przy­pad­ków uży­cia, mode­le dzie­dzi­ny sys­te­mu i wie­le innych. Warto jed­nak wie­dzieć, że co praw­da mode­lem bywa nawet poje­dyn­czy dia­gram (sche­mat blo­ko­wy), jed­nak jeże­li mówi­my o mode­lu dzia­ła­nia jakiejś orga­ni­za­cji (urząd, przed­się­bior­stwo, inne) to jest on raczej bar­dziej zło­żo­ny i przed­sta­wia­ny jest na wie­lu róż­nych dia­gra­mach. Często sto­so­wa­ne jest poję­cie per­spek­ty­wy mode­lo­wa­nia, co zna­czy, że two­rzy­my kon­tek­sto­wy opis dzia­ła­nia. Tak kon­tra­sto­wość pole­ga na pomi­ja­niu jed­nych aspek­tów mecha­ni­zmu dzia­ła­nia orga­ni­za­cji na korzyść innych.

Jeżeli opi­su­je­my orga­ni­za­cję z per­spek­ty­wy kolej­no­ści reali­zo­wa­nych zadań i ich pro­duk­tów abs­tra­hu­jąc cał­ko­wi­cie od tego jakich narzę­dzi uży­wa­ją wyko­naw­cy tych czyn­no­ści, two­rzy­my model pro­ce­sów biz­ne­so­wych. Model taki poka­zu­je jakie zada­nia, i w jakim celu, są reali­zo­wa­ne. Z tego powo­du jest uzu­peł­nia­ny mode­lem reguł biz­ne­so­wych (logi­ka reali­za­cji pro­ce­sów) i mode­lem poję­cio­wym (jed­no­znacz­ność), tłu­ma­czą­cym zna­cze­nia pojęć uży­tych w tych mode­lach. Skoro są ludzie i uży­wa­ją narzę­dzi do pra­cy, poja­wia się tak­że potrze­ba opi­sa­nia tych narzę­dzi. Powodem jest zro­zu­mie­nie tego jak dzia­ła­ją i jak poma­ga­ją ludziom w reali­za­cji ich zadań, część z nich słu­ży do auto­ma­ty­zo­wa­nia pew­nych prac. Jednym z takich narzę­dzi jest opro­gra­mo­wa­nie (apli­ka­cja) a ich opis to albo doku­men­ta­cja apli­ka­cji ist­nie­ją­cej, albo pro­jekt pla­no­wa­nej do wyko­na­nia i dostarczenia. 

Tu poja­wia się zada­nie: zro­zu­mieć jak dzia­ła orga­ni­za­cja i zapro­jek­to­wać narzę­dzie, któ­re będzie poma­ga­ło w zada­niach jakie ona reali­zu­je. Rzecz w tym, że opro­gra­mo­wa­nie jako narzę­dzie nie jest zama­wia­ne jako coś cze­go wyma­ga orga­ni­za­cja” a jako coś co wes­prze jej dzia­ła­nie”, narzę­dzie sta­no­wią­ce roz­wią­za­nie” pro­ble­mu jaki chce roz­wią­zać zamawiający.

Gdzie tu miej­sce na nauko­we meto­dy? Mamy dwa zada­nia do wykonania:

  1. opra­co­wać model dzia­ła­nia orga­ni­za­cji czy­li opra­co­wać teo­rią wyja­śnia­ją­cą to, co się w niej dzieje,
  2. opra­co­wać pro­jekt roz­wią­za­nia czy­li zbu­do­wać mecha­nizm dzia­ła­nia narzę­dzia, któ­re umiesz­czo­ne w tej orga­ni­za­cji, roz­wią­że pro­blem opi­sa­ny przez zama­wia­ją­ce­go; to narzę­dzie może być zre­ali­zo­wa­ne jako oprogramowanie.

Potocznie pierw­szy etap nazy­wa­ny jest Analizą biz­ne­so­wą dru­gi to Projektowanie logi­ki opro­gra­mo­wa­nia. Przyjmując, że sto­su­je­my nauko­we podej­ście, naj­pierw two­rzy­my model orga­ni­za­cji a potem model logi­ki potrzeb­ne­go jej opro­gra­mo­wa­nia (teo­rie mówią­ce, że tak to dzia­ła), testu­je­my je i uzna­je­my za popraw­ne, jeże­li nie uda­ło ich pod­wa­żyć. Na tym blo­gu znaj­dzie opis takie­go pro­ce­su pod nazwą MDA. Jednak jeże­li nauko­wo to opie­ra­my się wyłącz­nie na fak­tach (czy­li nie pro­wa­dzi­my wywia­dów a ana­li­zu­je­my dokumenty).

Po kolei:

  • obser­wa­cje to ana­li­za tego co i jak się w fir­mie dzie­je (ana­li­za fak­tów czy­li doku­men­tów, wywia­dy tyl­ko w ostateczności),
  • budo­wa­nie hipo­te­zy to two­rze­nie mode­lu logi­ki dzia­ła­nia (pro­ce­so­we­go, obiek­to­we­go) tej firmy,
  • eks­pe­ry­men­ty to testo­wa­nie mode­li poprzez spraw­dza­nie czy są jakieś fak­ty w orga­ni­za­cji, któ­rych nie potra­fi­my wyja­śnić naszym modelem,
  • przy­ję­cie lub odrzu­ce­nie i napra­wa” hipo­te­zy czy­li ulep­sza­nie mode­lu (jeśli był wadliwy).

Moje pro­jek­ty to nic inne­go jak kon­kret­ne powsta­łe spe­cy­fi­ka­cje wyma­gań na opro­gra­mo­wa­nie sta­no­wią­ce sobą tak na praw­dę mode­le mecha­ni­zmu dzia­ła­nia. Spełnienie wyma­gań to zgod­ność zacho­wa­nia opro­gra­mo­wa­nia z opi­sa­nym (wyma­ga­nym) mecha­ni­zmem, zgod­ność tę spraw­dza­my testa­mi.

Na koniec o tym czym jest hipoteza:

Hipoteza – osąd, teo­ria, któ­ra nie zna­la­zła jesz­cze potwier­dze­nia w fak­tach, lub w przy­pad­ku hipo­tez mate­ma­tycz­nych nie zosta­ła jesz­cze popraw­nie udo­wod­nio­na.
Stawianie i testo­wa­nie hipo­tez to jeden z pod­sta­wo­wych pro­ce­sów twór­cze­go myśle­nia oraz fun­da­men­tal­ny ele­ment pro­ce­su two­rze­nia nauki.

(źr. cyta­tów Metoda nauko­wa).

Tak więc, sko­ro opro­gra­mo­wa­nie w swej cen­tral­nej czę­ści zawie­ra Model (patrz wzo­rzec MVC) logi­ki biz­ne­so­wej, to zna­czy, że nale­ży naj­pierw (1) zro­zu­mieć jak dzia­ła ta orga­ni­za­cja i udo­ku­men­to­wać jej model dzia­ła­nia, (2) pod­jąć decy­zję któ­ry obszar dzia­ła­nia orga­ni­za­cji ma być wspie­ra­ny nowym opro­gra­mo­wa­niem, i któ­ra część jej mode­lu dzia­ła­nia ma być zaim­ple­men­to­wa­na w opro­gra­mo­wa­niu, (3) wyko­nać implementację.

User Story to co naj­wy­żej mate­riał badaw­czy a Przypadki uży­cia to zakres pro­jek­tu. Kluczem jest zro­zu­mie­nie mecha­ni­zmu dzia­ła­nia, tak jak pra­wa fizy­ki są tym co tłu­ma­czy dzia­ła­nie nawet pro­ste­go młotka…

Jeżeli ktoś uwa­ża, że zapis z obser­wa­cji zacho­wa­nia się orga­ni­za­cji może sta­no­wić wyma­ga­nie dla inży­nie­ra, to tak jak by uznał, że zapis obser­wa­cji zacho­wa­nia się samo­cho­du i jego kie­row­cy może sta­no­wić wystar­cza­ją­cy mate­riał do wypro­du­ko­wa­nia skrzy­ni biegów… 

Teorie, któ­re nie mogą być prze­te­sto­wa­ne, bo np. to co opi­su­ją nie jest obser­wo­wal­ne, nie kwa­li­fi­ku­ją się jako teo­rie
nauko­we. Przykłady:

Księżyc zasie­dla­ją Małe Zielone, któ­rych ani
nie moż­na zoba­czyć, ani zła­pać ? ŹLE

Na Księżycu nie ma Małych Zielonych ?
DOBRZE, łapiąc jed­ne­go moż­na sfal­sy­fi­ko­wać
hipo­te­zę

Polecam tak­że źró­dło­wy wykład: meto­da nauko­wa.

(źr. http://www.home.umk.pl/~mwojc/wyklady_Teren/metoda%20naukowa.pdf)


  1. ?*?
    patrz tak­że http://​www​.racjo​na​li​sta​.pl/​k​k​.​p​h​p​/​s​,​2​432

Żródła

McMullin, E. (1985). Galilean ide­ali­za­tion. Studies in History and Philosophy of Science Part A, 16(3), 247 – 273. https://​doi​.org/​1​0​.​1​0​1​6​/​0​039 – 3681(85)90003 – 2
Ackoff, R. L., Magidson, J., & Addison, H. J. (2006). Idealized design: cre­ating an organization’s futu­re. Wharton School Pub.
Popper, K. R. (2002). Logika odkry­cia nauko­we­go (U. Niklas, Trans.). Fundacja Aletheia.
Subbotin A.L. (1970). Idealization as a Method of Scientific Knowledge. In Tavanec P.V. (eds) Problems of the Logic of Scientific Knowledge. Synthese Library.
Wheeler, B. (2018). Idealization and the Laws of Nature. Springer.
Kitchenham, B. A., Budgen, D., & Brereton, P. (2016). Evidence-based softwa­re engi­ne­ering and sys­te­ma­tic reviews. CRC Press.
Nola, I. R., & Sankey, H. (n.d.). HARD PROBLEMS IN THE PHILOSOPHY OF SCIENCE: IDEALIZATION AND COMMENSURABILITY. 20.

Aktualizacja gru 21, 2020 @ 23:25