User Story c.d.

Wokół metod zwin­nych nara­sta wie­le mitów, szcze­gól­nie tych o sku­tecz­no­ści w dużych pro­jek­tach. Dzisiaj kolej­ne kil­ka słów o popu­lar­nym narzę­dziu jakim jest tak zwa­ne user sto­ry” czy­li histo­ryj­ka użyt­kow­ni­ka, o ich ewo­lu­cji i o tym, że mogą być przy­dat­ne i kiedy.

Co praw­da, jako źró­dło infor­ma­cji wolę doku­men­ty, ale bywa, że tym źró­dłem infor­ma­cji są jed­nak użyt­kow­ni­cy, bo doty­czy to pro­jek­to­wa­nia np. nowych por­ta­li biz­ne­so­wych. Tu nie­ste­ty nie ma ani ustaw z wzo­ra­mi doku­men­tów ani dotych­cza­so­we­go papie­ro­we­go obie­gu doku­men­tów”. Bardzo podob­nie wyglą­da­ją start-up’y w obsza­rze ope­ra­cyj­nym. Podobnie wyglą­da ana­li­za i pro­jek­to­wa­nie sys­te­mów wspie­ra­ją­cych obsłu­gę klien­tów (CRM i podob­ne). Dlaczego? Bo tej sfe­ry nie regu­lu­ją ani prze­pi­sy ani żad­ne nor­my. Nie licząc ele­men­tów pra­wa cywil­ne­go, są cał­ko­wi­cie uznaniowe.

User Story

Historyjki użyt­kow­ni­ka, mają swój rodo­wód w EX (pro­gra­mo­wa­nie eks­tre­mal­ne) i są z regu­ły defi­nio­wa­ne tak:

In softwa­re deve­lop­ment and pro­duct mana­ge­ment, a user sto­ry is a descrip­tion con­si­sting of one or more sen­ten­ces in the eve­ry­day or busi­ness lan­gu­age of the end user or user of a sys­tem that cap­tu­res what a user does or needs to do as part of his or her job func­tion (źr. ang. wiki).

Scott Ambler pisze:

User sto­ries are one of the pri­ma­ry deve­lop­ment arti­facts for Scrum and Extreme Programming (XP) pro­ject teams. A user sto­ry is a very high-level defi­ni­tion of a requ­ire­ment, con­ta­ining just eno­ugh infor­ma­tion so that the deve­lo­pers can pro­du­ce a reaso­na­ble esti­ma­te of the effort to imple­ment it?1?

Generalnie jest to opis w potocz­nym języ­ku, ten – z uwa­gi na nie­jed­no­znacz­ność – jako wyma­ga­nie, stwa­rza pro­ble­my. Podejmowane są pró­by for­ma­li­zo­wa­nia tych histo­ry­jek. Pisze o tym autor blo­ga QAgile (poda­jąc przy­kła­dy, pole­cam cały artykuł):

W podej­ściu agi­le takim jak Scrum wyma­ga­nia defi­niu­je­my na ogól w posta­ci User Story. Prosta for­ma, któ­ra ma adre­so­wać ocze­ki­wa­nia i potrze­by użyt­kow­ni­ków czę­sto zespo­łom przy­spa­rza dużo pro­ble­mów w imple­men­ta­cji.?2?

Swego cza­su ja tak­że pisa­łem o efek­tach sto­so­wa­nia tej meto­dy z zbyt­nią ufno­ścią w jej skuteczność:

Niedawno po raz kolej­ny widzia­łem nega­tyw­ne skut­ki tego podej­ścia, tym razem był to wdra­ża­ny i zakoń­czo­ny poraż­ką (pro­jekt prze­rwa­no) obieg doku­men­tów, nie tyl­ko kosz­to­wych, więc posta­no­wi­łem do tam­te­go arty­ku­łu dodać coś jesz­cze: wyma­ga­nia zbie­ra­no tu z w posta­ci user story”.[…]

Tak więc opi­so­we user sto­ry może być wyma­ga­niem biz­ne­so­wym, testem ale raczej nie spe­cy­fi­ka­cją tego co ma powstać. Bez ana­li­zy pozwa­la­ją­cej wyspe­cy­fi­ko­wać wyma­ga­nia dzie­dzi­no­we (logi­kę wewnętrz­ną) nie mamy szans na spraw­ne stwo­rze­nie opro­gra­mo­wa­nia wykra­cza­ją­ce­go poza pro­sty zestaw kar­to­tek i reje­strów.?3?

User sto­ry to opis z per­spek­ty­wy użyt­kow­ni­ka. Najlepszą chy­ba meta­fo­rą będzie tu zna­na aneg­do­ta z opi­sy­wa­niem słonia:

User-Stories

Każdy z tych okrzy­ków to odręb­ne user story.

Wszelkie meto­dy zakła­da­ją­ce, że użyt­kow­nik wie cze­go chce i jest naj­lep­szym źró­dłem wyma­gań” bazu­ją na zaufa­niu dla tych opisów.

I tu wpa­da­my w efekt ?krę­ce­nia fil­mu?. Najczęściej tak zwa­na ana­li­za wyglą­da tak, że pra­cow­ni­cy ana­li­zo­wa­nej fir­my, w toku warsz­ta­tów lub wywia­dów, opo­wia­da­ją z jaki­mi to sytu­acja­mi mają do czy­nie­nia, co robią, kie­dy i jak, opi­su­jąc kon­kret­ne przy­pad­ki z jaki­mi mie­li do czy­nie­nia i to, jak sobie z nimi pora­dzi­li. Do tego docho­dzą przy­pad­ki, w któ­rych sobie sła­bo pora­dzi­li, przy­pad­ki tego jak sobie radzą z tym, że cze­goś nie rozu­mie­ją, a to wszyst­ko jest okra­szo­ne spo­so­ba­mi pra­cy wyni­ka­ją­cy­mi nie raz z nie­wie­dzy, nie­zna­jo­mo­ści pra­wa czy wewnętrz­nych regu­la­cji. Na domiar złe­go, nie raz moż­na się spo­tkać z przy­pad­ka­mi, w któ­rych opo­wia­da­ją­cy o swo­jej pra­cy wpla­ta ele­men­ty pozwa­la­ją­ce mu na dzia­ła­nia nie­po­żą­da­ne takie jak uprasz­cza­nie pro­ce­dur lub wręcz łama­nie pra­wa (np. swe­go cza­su pewien urzęd­nik na moich oczach w trak­cie warsz­ta­tów zgło­sił jako wyma­ga­nie wobec sys­te­mu obie­gu doku­men­tów, moż­li­wość pod­pi­sa­nia orze­cze­nia sędzie­go prze­ter­mi­no­wa­nym pod­pi­sem elek­tro­nicz­nym!).?4?

Historyjki użyt­kow­ni­ka mają sens, jed­nak nie jako kom­plet­ny opis wyma­gań na apli­ka­cję” (wczo­raj usły­sza­łem, że w pew­nej dużej insty­tu­cji zebra­no już ok. tysią­ca (!) takich histo­ry­jek i pro­ces ten nadal trwa). Mają jed­nak sens jako sam­ple” do ana­li­zy. Przekazywanie takich histo­ry­jek bez­po­śred­nio deve­lo­pe­ro­wi jest ogrom­nym ryzy­kiem. Dlaczego? Historyjka, nawet w sfor­ma­li­zo­wa­nej for­mie, nie­sie tyl­ko subiek­tyw­ne spoj­rze­nie z zewnątrz”, a pro­gra­mi­sta zaczy­na domy­ślać się i gdy­bać, nie­jed­no­krot­nie prze­kra­cza­jąc dozwo­lo­ne granice:

…?jako sprze­daw­ca, dosta­ję od klien­tów zamó­wie­nia, na pod­sta­wie któ­rych muszę wysta­wiać fak­tu­ry VAT?, do tego ana­li­tyk doda, np. po ana­li­zie otrzy­ma­nej par­tii doku­men­tów, struk­tu­rę zamó­wie­nia i fak­tu­ry VAT oraz ?algo­rytm? wyli­cze­nia podat­ków. Jeżeli pro­gra­mi­sta zaczy­na ?lepiej wie­dzieć? od zama­wia­ją­ce­go, for­su­jąc np. prost­szą imple­men­ta­cję, to zna­czy, że prze­kro­czył swo­je kom­pe­ten­cje, sam sobie ? jako deve­lo­pe­ro­wi ? robi krzyw­dę psu­jąc to opro­gra­mo­wa­nie bo klient i tak prę­dzej czy póź­niej na tych uprosz­cze­niach ?pole­gnie?.?3? 

Bywa bar­dzo czę­sto, że pro­gra­mi­sta bez żad­ne­go opo­ru przyj­mu­je histo­ryj­kę: ja jako sprze­daw­ca, chcę umie­ścić na fak­tu­rze towar, któ­re­go nie ma jesz­cze w maga­zy­nie, w celu zali­cze­nia sprze­da­ży w danym dniu” … (Komentarz zbędny…)

Czy to zna­czy, że nale­ży odejść cał­ko­wi­cie od tego narzę­dzia? Moim zda­niem nie. Wystarczy uznać , że user sto­ry” to WYŁĄCZNIE opis z per­spek­ty­wy użyt­kow­ni­ka, swo­iste jed­no spoj­rze­nie z setek możliwych”.

Swego cza­su opi­sa­łem tak­so­no­mię pojęć sto­so­wa­nych w ana­li­zie wymagań:

Taksonomia wymagań na system (źr. opracowanie własne Jarosław Żeliński)
Taksonomia wyma­gań na sys­tem (źr. opra­co­wa­nie wła­sne Jarosław Żeliński)

U szczy­tu tej hie­rar­chii mamy wyma­ga­nia biz­ne­so­we. Są to w zasa­dzie owe histo­ryj­ki użyt­kow­ni­ka. To wyra­żo­ne języ­kiem zama­wia­ją­ce­go, ocze­ki­wa­nia w sto­sun­ku do opro­gra­mo­wa­nia. Rolą ana­li­ty­ka jest takie prze­ana­li­zo­wa­nie i prze­two­rze­nie tych opi­sów, by dopro­wa­dzić do powsta­nia sfor­ma­li­zo­wa­ne­go opi­su (np. w posta­ci mode­li UML: przy­pad­ki uży­cia, model dzie­dzi­ny, ogra­ni­cze­nia, inne) czy­li do posta­ci spe­cy­fi­ka­cji usług apli­ka­cji i logi­ki (mecha­ni­zmu) dzia­ła­nia tej aplikacji.

Kolekcjonowanie wyma­gań biz­ne­so­wych w posta­ci np. user sto­ry, ma sens jako zbie­ra­nie sam­pli”, przy­kła­do­wych sytu­acji. Na ich pod­sta­wie, w toku ana­li­zy, moż­na two­rzyć mode­le i testo­wać te histo­ryj­ki (sta­ją się sce­na­riu­sza­mi testo­wy­mi). Tu pole­cam mię­dzy inny­mi blog i książ­ki Scotta Amblera:

In this epi­so­de, Scott Ambler helps us to under­stand the power of using models and how to use models in an agi­le envi­ron­ment.?5?

Wspominałem nie raz o nim i o jego książ­kach na tym blogu:

Co praw­da książ­ka ma 12 lat i trze­ba brać na to lek­ka popraw­kę, jed­nak jest to war­to­ścio­wa, nafa­sze­ro­wa­na dia­gra­ma­mi UML, książ­ka trak­tu­ją­ca o tym, że zwin­ność nie ozna­cza bała­ga­nu i pospo­li­te­go rusze­nia. Scott Ambler to kolej­ny auto­ry­tet w inży­nie­rii opro­gra­mo­wa­nia. I mimo, że niko­go nie ma sen­su mał­po­wać, na pew­no war­to się uczyć? ?6?

Ostatnio popu­lar­ność zdo­by­wa podej­ście sfor­ma­li­zo­wa­ne do histo­ry­jek użyt­kow­ni­ka, bazu­ją­ce na kon­cep­cji Scott’a Amblera (mode­lo­wa­nie) i Rona Jeffries’a, zwo­len­ni­ka porząd­ko­wa­nia, nie tyl­ko tre­ści wywia­dów ;). Tu posłu­żę się ilu­stra­cja­mi z arty­ku­łu na stro­nie Visual Paradigm.

User sto­ry is one of the most impor­tant tool for agi­le deve­lop­ment. They are often used for iden­ti­fy­ing the featu­res of a sys­tem under deve­lo­ped. User sto­ries are well com­pa­ti­ble with the other agi­le softwa­re deve­lop­ment tech­ni­qu­es and methods, such as scrum and extre­me programming. […]

Concept of 3C’s

The 3C’s refer to the three cri­ti­cal aspects of good user sto­ries. The con­cept was sug­ge­sted by Ron Jeffries, the co-inven­tor of the user sto­ries prac­ti­ce. Nowadays, when we talk abo­ut user sto­ries, we usu­al­ly are refer­ring to the kind of user sto­ries that are com­po­sed of the­se three aspects:
Card – User sto­ries are writ­ten as cards. […]
Conversation – Requirements are found and re-fined thro­ugh a con­ti­nu­ous conver­sa­tions betwe­en custo­mers and deve­lop­ment team thro­ugho­ut the who­le softwa­re pro­ject. […]
Confirmation – or also known as Acceptance cri­te­ria of the user sto­ry. […]?7?

W dużym skró­cie: histo­ryj­ki dzie­li­my na jed­nost­ko­we ele­men­tar­ne (nie­po­dziel­ne) opi­sy w posta­ci kart”, zawie­ra­ją­cych opis tego cze­go zama­wia­ją­cy ocze­ku­je od apli­ka­cji, zapis uwag (kon­wer­sa­cja) doty­czą­cych kolej­nych dys­ku­sji z zama­wia­ją­cym na temat danej histo­ryj­ki to histo­ria usta­leń, opis ocze­ki­wa­ne­go uzy­ska­ne­go efek­tu czyn­no­ści opi­sa­nych w danej histo­ryj­ce potwier­dze­nie uzy­ska­nia ocze­ki­wa­ne­go efek­tu. Idąc zaś za wska­zów­ka­mi Amblera, imple­men­ta­cję poprze­dza­my pra­cą nad kon­cep­cją imple­men­ta­cji posłu­gu­jąc się mode­la­mi na dość wyso­kim pozio­mie abstrakcji.

Karta histo­ryj­ki to pro­sty zapis utrzy­ma­ny w kon­wen­cji ja jako «aktor», chcę «nazwa czyn­no­ści» w celu «ocze­ki­wa­ny efekt». Osobiście w pro­jek­tach dopusz­czam bar­dziej luź­ną” for­mę takiej histo­ryj­ki, jed­nak pil­nu­je co do zasa­dy, by doty­czy­ła wyłącz­nie jed­ne­go uzy­ska­ne­go efek­tu koń­co­we­go”. Każda kar­ta ma uni­kal­ne ozna­cze­nie, jest bowiem uży­wa­na jako jed­no zada­nie, w bac­klo­gu i sprin­tach (kan­ban). W doku­men­ta­cji (wspo­mnia­ne narzę­dzie VP) user sto­ry wyglą­da to tak:

01-user-story-example

Historyjki mają swój cykl życia i dobrą prak­ty­ką jest reje­stro­wa­nie wszel­kich kolej­nych uzgod­nień w toku pracy:

02-conversation

Tak zapi­su­je­my sło­wo­tok” zama­wia­ją­ce­go na temat jego wizji reali­za­cji danej usłu­gi apli­ka­cyj­nej. Analogicznie zapi­su­je­my opis ocze­ki­wa­ne­go efek­tu końcowego:

03-confirmation

Do tego momen­tu mamy kla­sycz­ne” zwin­ne pro­wa­dze­nie pro­jek­tu z jego wada­mi opi­sa­ny­mi powyżej.

Wymagania powinny być spójne, kompletne i niesprzeczne”

Jak to osią­gnąć? Analityk zaczy­na zbie­rać te histo­ryj­ki i zaczy­na skła­dać z nich kom­plet­ny pro­ces biz­ne­so­wy. Stanowi on wery­fi­ka­tor, czy całość (zestaw takich histo­ry­jek) sta­no­wi jakąś spój­ną, kom­plet­ną i nie­sprzecz­ną logi­kę biz­ne­so­wą w ska­li całej fir­my. Zmorą pro­jek­tów są wyma­ga­nia odkry­wa­ne w toku wdro­że­nia, dla­te­go war­to poświę­cić czas na wery­fi­ka­cję pomy­słu na całość sys­te­mu i zwe­ry­fi­ko­wać spój­ność i kom­plet­ność tej cało­ści z pomo­cą utwo­rze­nia mode­lu każ­de­go całe­go procesu:

04-business-process-to-user-story-mapping

Warto mode­lo­wać pro­ces gdyż wte­dy widać, że nie zawsze praw­dą jest, że jed­na (każ­da) histo­ryj­ka jest odręb­nym przy­pad­kiem uży­cia. Przypadki uży­cia wypro­wa­dza się z ele­men­tar­nych aktyw­no­ści jeden do jed­ne­go, co z uza­sad­nie­niem opi­sy­wa­łem w arty­ku­le Transformacja…. Model pro­ce­su biz­ne­so­we­go daje kon­tekst, pozwa­la lepiej zro­zu­mieć sens” cało­ści. Czy powyż­szy model pro­ce­su (nota­cja BPMN) z nanie­sio­ny­mi histo­ryj­ka­mi, nie przy­po­mi­na Wam wyni­ków bada­nia sło­nia? Tu słoń został przez ana­li­ty­ka odkry­ty: to pro­ces biz­ne­so­wy (jego model w nota­cji BPMN). Przypadkami uży­cia będą ele­men­tar­ne aktyw­no­ści w pro­ce­sie. Więcej na temat zwin­ne­go pro­wa­dze­nia pro­jek­tu z uży­ciem user sto­ry moż­na zna­leźć w tuto­ria­lu Agile hand­bo­ok.

Na zakończenie…

(źr. Martin Fowler, Analysis Patterns, 1997)
(źr. Martin Fowler, Analysis Patterns, 1997)

We are cal­led ?ana­ly­sts? for a reason! We don?t mere­ly hear sto­ries and convert them into ?requ­ire­ments?. Our inte­gra­ted value lies in going abo­ve and bey­ond the sto­ry and expan­ding bey­ond engen­de­ring deli­ve­ra­bles. We coale­sce cri­ti­cal thin­king and intel­lec­tu­al curio­si­ty to trans­form sto­ries into abs­tracts and to pro­po­se the needs as well as what the pro­blem real­ly is.?1?

___

  1. 1.
  2. 2.
  3. 3.
    Żeliński J. User sto­ry czy­li nic nie popra­wić a może nawet bar­dziej skom­pli­ko­wać. IT-Consulting. https://it-consulting.pl//2013/09/11/user-story-czyli-nic-nie-poprawic-a-moze-bardziej-skomplikowac/. Accessed May 9, 2019.
  4. 4.
    Żeliński J. Warsztaty ana­li­tycz­ne ? czy­li malo­wa­nie tra­wy. IT-Consulting. https://it-consulting.pl//2014/12/21/warsztaty-analityczne-czyli-malowanie-trawy/. Accessed May 9, 2019.
  5. 5.
  6. 6.
    Żeliński J. Agile Modeling. Effective Practices for Modeling and Documentation. IT-Consulting. https://it-consulting.pl//2015/05/27/agile-modeling-effective-practices-for-modeling-and-documentation/. Accessed May 9, 2019.
  7. 7.

Produkt analizy jako twierdzenie naukowe

Znakomita więk­szość pro­gra­mów zawie­ra ponad 10 krot­nie wię­cej kodu niż mogła by mieć, bo pro­gra­mi­ści czę­sto imple­men­tu­ją warian­ty zacho­wań a nie ich mecha­ni­zmy (co powo­du­je, że sys­te­my te są tyleż razy droż­sze niż mogły by być).

Prawie za każ­dym razem, gdy mówię (ale nie robię tego jed­nak zbyt czę­sto 😉 ), że sto­su­ję meto­dy nauko­we w ana­li­zie, spo­ty­kam się z zarzu­tem, że prze­sa­dzam. Zapewne nie ma sen­su epa­to­wa­nie w pro­jek­tach biz­ne­so­wych aka­de­mic­kim słow­nic­twem, nie ma zna­cze­nia dobór słow­nic­twa w nazwa­niu meto­dy pra­cy, bo zna­cze­nie ma skuteczność.

Twierdzenie naukowe

Poniżej defi­ni­cja tego czym jest twier­dze­nie naukowe:

Twierdzenie nauko­we ? zda­nie oznaj­mia­ją­ce speł­nia­ją­ce nastę­pu­ją­ce warun­ki :

  1. moż­na wobec nie­go sfor­mu­ło­wać kry­te­ria pozwa­la­ją­ce na eks­pe­ry­men­tal­ne, obser­wa­cyj­ne lub logicz­ne ich oba­le­nie (fal­sy­fi­ko­wal­ne według zasad Karla R. Poppera),
  2. ist­nie­ją regu­ły jego odczy­ta­nia, któ­re ogra­ni­cza­ją do skoń­czo­no­ści licz­bę ich inter­pre­ta­cji (kry­te­rium pre­cy­zji Józefa Bocheńskiego),
  3. odno­si się do empi­rycz­nie doświad­czal­nej lub logicz­nie defi­nio­wa­nej rze­czy­wi­sto­ści (tzw. widły Hume?a),
  4. jest ele­men­tem zbio­ru twier­dzeń para­dyg­ma­tu wyja­śnia­ją­ce­go rze­czy­wi­stość i pozwa­la­ją­ce­go na prze­wi­dy­wa­nie jej przy­szłych sta­nów (kon­cep­cja nauki nor­mal­nej T. S. Kuhna),
  5. twier­dze­nie będą­ce naj­prost­szym z moż­li­wych opi­sów świa­ta (tzw. Brzytwa Ockhama).

Graficznie sam pro­ces odkry­cia nauko­we­go moż­na poka­zać tak :

Budgen, D. (2003). Software design (2nd ed). Addison-Wesley.
Budgen, D. (2003). Software design (2nd ed). Addison-Wesley. 

Celowo cytu­ję tu lite­ra­tu­rę z obsza­ru inży­nie­rii opro­gra­mo­wa­nia, by poka­zać, że nie jestem odosob­nio­ny w tym podej­ściu. Dla porząd­ku poda­je tak­że defi­ni­cje poję­cia model:

model: sys­tem zało­żeń, pojęć i zależ­no­ści mię­dzy nimi pozwa­la­ją­cy opi­sać (mode­lo­wać) w przy­bli­żo­ny spo­sób jakiś aspekt rzeczywistości

Więcej o mode­lach w nauce: .

Inżynieria oprogramowania

Jeżeli uzna­my, że wynik zarów­no ana­li­zy jak i pro­jek­to­wa­nia, to tak­że mode­le (przyj­mu­je­my meto­dę pra­cy opar­tą na two­rze­niu mode­li: MDD/MDA czy­li model dri­ven deve­lop­ment”, MDA czy­li model dri­ven archi­tec­tu­re”, itp.), to w związ­ku z tym 

model, jako wynik ana­li­zy, moż­na potrak­to­wać jako twier­dze­nie nauko­we opi­su­ją­ce bada­ną (ana­li­zo­wa­ną) orga­ni­za­cję, jest on zara­zem wyma­ga­niem wobec opro­gra­mo­wa­nia (ma zostać zaimplementowany).

Wyjaśnienie: odnio­sę się do powyż­szej defi­ni­cji twier­dze­nia nauko­we­go (zgod­nie z powyż­szym pod poję­ciem model rozu­mie­my kom­plet doku­men­ta­cji zawie­ra­ją­cej mode­le, powsta­łej jako pro­dukt analizy):

  1. kry­te­rium fal­sy­fi­ka­cji: dopie­ro wska­za­nie w bada­nej orga­ni­za­cji fak­tu, któ­re­go nie opi­su­je opra­co­wa­ny model, pozwa­la uznać model (wynik ana­li­zy) za zły,
  2. ist­nie­ją regu­ły jego (mode­lu) odczy­ta­nia, czy­li do stwo­rze­nia mode­lu uży­to sfor­ma­li­zo­wa­nych nota­cji i sys­te­mów poję­cio­wych (np. BPMN, UML, BMM, SBVR itp),
  3. model powstał na bazie, i odno­si się wyłącz­nie do, zebra­nych w toku ana­li­zy fak­tów (w szcze­gól­no­ści doku­men­tów, któ­re powsta­ją w toku pra­cy ana­li­zo­wa­nej orga­ni­za­cji – doku­men­ty opi­su­ją fak­ty np. fak­tu­ra to opis fak­tu doko­na­nia sprzedaży),
  4. model pozwa­la na prze­wi­dy­wa­nie tego co zaj­dzie w odpo­wie­dzi na okre­ślo­ne bodź­ce (para­dyg­mat pro­ce­so­wy opi­su­ją­cy zacho­wa­nia i para­dyg­mat obiek­to­wy opi­su­ją­cy struk­tu­ry), mając model pro­ce­sów biz­ne­so­wych moż­na prze­wi­dzieć pro­dukt pro­ce­su, mając model apli­ka­cji moż­na prze­wi­dzieć pro­dukt każ­de­go przy­pad­ku użycia,
  5. opra­co­wa­ny model jest naj­prost­szy (mini­mal­ny) z moż­li­wych, czy­li nie da się już z nie­go usu­nąć nic bez spo­wo­do­wa­nia jego znisz­cze­nia (uczy­nie­nia nieprawdziwym).

Tu, dla dopeł­nie­nia, war­to dodać powszech­nie uzna­wa­ną w świe­cie nauki defi­ni­cję praw­dy (A.Tarski): twier­dze­nie praw­dzi­we to twier­dze­nie kore­spon­du­ją­ce z faktami.

Tak więc mamy to co chce­my czy­li kry­te­rium odbio­ru doku­men­ta­cji ana­li­tycz­nej i pro­jek­to­wej: nie jest to licz­ba stron a to, że mówi prawdę”. 

Z dru­giej stro­ny, nie­ste­ty nie ist­nie­je moż­li­wość wyka­za­nia popraw­no­ści doku­men­ta­cji powsta­łej w wyni­ku ankiet, wywia­dów czy burzy mózgów spi­sa­nej języ­kiem natu­ral­nym … .

cięż­ką arty­le­rię”, jak ta tu opi­sa­na, wyta­cza­my głów­nie dla pro­jek­tów ryzy­kow­nych i kosz­tow­nych… 😉 oraz wszę­dzie tam gdzie waż­na jest ochro­na know-how.

Dodatek

(dwa dni po publikacji)

Właśnie pode­sła­no mi link do cie­ka­we­go tekstu:

One of the most impor­tant ele­ments of eve­ry Business Analyst?s tool­kit is pro­cess mode­ling, which is also signi­fi­cant acti­vi­ty for Business Process Management pro­fes­sio­nals. For BPM mar­ket B? (Źródło: BPMN for Business Analysts ? why, when and how)

Przejrzałem treśc i wszyst­kie wypo­wie­dzi one krę­cą się” wokół doku­men­to­wa­nia, pre­zen­ta­cji w celu zatwier­dze­nia lub zgła­sza­nia uwag oraz nie­któ­rzy wska­zu­ją na moż­li­wość ryso­wa­nia zamiast kodo­wa­nia w celu wyko­na­nia”, albo prze­oczy­łem albo nikt nie zwró­cił uwa­gi na bar­dzo – mim zda­niem waż­ny ele­ment – two­rze­nie mode­lu orga­ni­za­cji czy­li two­rze­nie hipo­te­zy tak dzia­ła­cie” jako orga­ni­za­cja.

Problem w tym, że chy­ba więk­szość użyt­kow­ni­ków” tej (BPMN) – i nie tyl­ko – nota­cji, sto­su­je induk­cyj­ne meto­dy uwia­ry­gad­nia­nia tych mode­li, rozu­mia­nych raczej jako sche­ma­ty blo­ko­we. Podejście bazu­ją­ce na dowo­dzie z ilo­ści” (induk­cja): model pro­ce­sów jest dobry bo bar­dzo dużo osób (osób akcep­tu­ją­cych, recen­zen­tów) tak uzna­ło, jest chy­ba najgorsze.

To błąd logicz­ny: nie da się wyka­zać popraw­no­ści meto­dą induk­cyj­ną. Model owszem powi­nien być jako dia­gram zro­zu­mia­ły dla czy­tel­ni­ka, to nie ule­ga wąt­pli­wo­ści, jed­nak jego testy powin­ny pole­gać na wska­zy­wa­niu (szu­ka­niu) ewen­tu­al­nych fak­tów typu a tu mówi nie­praw­dę”. Innymi sło­wy model pro­ce­su nie jest dobry” (odzwier­cie­dla praw­dzi­wy mecha­nizm dzia­ła­nia orga­ni­za­cji) dla­te­go, że wszy­scy go zaak­cep­to­wa­li, jest dobry dla­te­go, że nikt nie zna­lazł (nie wska­zał) jego wady (nie pod­wa­żo­no go).

Projektów zakoń­czo­nych klę­ską, w któ­rych wszy­scy zaak­cep­to­wa­li doku­men­ta­cję” zna­my chy­ba wszy­scy masę.…

Tak więc ana­li­tyk, któ­ry pod­cho­dzi sys­te­mo­wo do ana­li­zy powi­nien two­rzyć hipo­te­zy tak to dzia­ła” i nie dowo­dzić ich popraw­no­ści, a cze­kać na wska­za­nie wad. Notacje (BPMN, UML, BMM, …) oraz mode­le two­rzo­ne z ich pomo­cą, są dosko­na­łym narzę­dziem do doku­men­to­wa­nia tych teorii.

Na zakoń­cze­nie pole­cam to 🙂

Źródła

Kitchenham, B., Pearl Brereton, O., Budgen, D., Turner, M., Bailey, J., & Linkman, S. (2009). Systematic lite­ra­tu­re reviews in softwa­re engi­ne­ering – A sys­te­ma­tic lite­ra­tu­re review. Information and Software Technology, 51(1), 7 – 15. https://​doi​.org/​1​0​.​1​0​1​6​/​j​.​i​n​f​s​o​f​.​2​0​0​8​.​0​9​.​009
Budgen, D. (2003). Software design (2nd ed). Addison-Wesley.
Popper, K. R. (2002). Logika odkry­cia nauko­we­go (U. Niklas, Trans.). Fundacja Aletheia.
Šenkýř, D., & Kroha, P. (2019). Problem of Incompleteness in Textual Requirements Specification: Proceedings of the 14th International Conference on Software Technologies, 323 – 330. https://​doi​.org/​1​0​.​5​2​2​0​/​0​0​0​7​9​7​8​0​0​3​2​3​0​330
Kitchenham, B. A., Budgen, D., & Brereton, P. (2016). Evidence-based softwa­re engi­ne­ering and sys­te­ma­tic reviews. CRC Press.

Koncepcja to nie wymagania!

Dwa lata temu pisa­łem o tym, czym jest, po co się pro­wa­dzi i jak, stu­dium wyko­ny­wal­no­ści projektu:

W lite­ra­tu­rze moż­na spo­tkać róż­ne ?defi­ni­cje? stu­dium wyko­nal­no­ści, jed­nak ta któ­rą opi­sa­łem, zda­je się być naj­bliż­sza defi­ni­cji, któ­rą przy­to­czy­łem na począt­ku: bazu­ją­cej na zna­cze­niu słow­ni­ko­wym. Praktyka poka­zu­je, że inten­cje spon­so­rów tych ana­liz są z nią zbież­ne: celem jest pod­ję­cie decy­zji o naj­mniej­szym ryzy­ku w świe­tle posia­da­nej na dany temat wie­dzy. Definicje bazu­ją­ce na tech­nicz­nej i finan­so­wej wyko­nal­no­ści dane­go pro­jek­tu, są spo­ty­ka­ne dość czę­sto i w lite­ra­tu­rze i na stro­nach wie­lu insty­tu­cji. Metoda pro­wa­dze­nia takich ana­liz, bazu­ją­ca na mode­lo­wa­niu czy­li na ana­li­zie sys­te­mo­wej, wyda­je się być jed­nak naj­wła­ściw­szą. (Źródło: Studium wyko­nal­no­ści ? czym napraw­dę jest | | Jarosław Żeliński IT-Consulting)

W arty­ku­le tym zwra­ca­łem uwa­gę na war­tość mode­lo­wa­nia (a nie ryso­wa­nia…), war­to­ścią tą jest testo­wa­nie kon­cep­cji. Sama kon­cep­cja nie jest żad­nym wyma­ga­niem, co ilu­stru­je świet­ny arty­kuł na stro­nach Modernanalyst​.com:

Requirements must be based on facts and real-life sce­na­rios. When the con­cept is unte­sted or not ful­ly tested, then the requ­ire­ments are hypo­the­ti­cal. Moving to design and build with hypo­the­ti­cal requ­ire­ments, the design and/or build pha­se beco­mes the testing gro­und for the con­cept. This may lead to cla­shes as each par­ty has dif­fe­rent expec­ta­tions of the out­co­me of the ?hypo­the­ses?.

Źródło: Blueprints Are Not Requirements!

Powyższy dia­gram poka­zu­je głów­ne prze­sła­nie opi­sa­nej meto­dy, któ­ra jest zgod­na w 100% z peł­ną ana­li­zą sys­te­mo­wą: pierw­szy etap to opra­co­wa­nie kon­cep­cji czy­li hipo­te­zy mówią­cej taki sys­tem jest nam potrzeb­ny” do roz­wią­za­nia pro­ble­mu biz­ne­so­we­go (potrze­by biz­ne­so­we). Kolejny etap to stwier­dze­nie popraw­no­ści pomy­słu, to nic inne­go jak stu­dium wyko­nal­no­ści, testo­wa­nie pomy­słu. Tu waż­na rzecz: test musi być pro­wa­dzo­ny w opar­ciu o fak­ty i tyl­ko fak­ty, inny­mi sło­wy model nie może koli­do­wać z rze­czy­wi­sto­ścią, musi tak­że poka­zać, że zapro­jek­to­wa­ny nowy lub zmie­nio­ny mecha­nizm dzia­ła­nia orga­ni­za­cji da ocze­ki­wa­ne efek­ty. Dopiero gdy hipo­te­za mówią­ca, że taki sys­tem reali­zu­je nasze potrze­by” zosta­nie potwier­dzo­na testa­mi na mode­lu, ma sens opra­co­wy­wa­nie wyma­gań na to roz­wią­za­nie. W toku opra­co­wy­wa­nia wyma­gań, tak­że je testu­je­my. Tu zno­wu spraw­dza się sku­tecz­ność podej­ścia pro­jekt (model) jako wymaganie”.

Trzy lata temu opi­sa­łem cały taki pro­ces, na dość może try­wial­nym przy­kła­dzie (sza­chy), ale za to (mam nadzie­ję) przej­rzy­stym. Na zakoń­cze­nie arty­ku­łu zwró­ci­łem uwa­gę, że:

Analiza i pro­jek­to­wa­nie obiek­to­we (ang. OOAD) to nie­ja­ko ?imple­men­ta­cja? kla­sycz­nej ana­li­zy sys­te­mo­wej. Nie ma ona nic wspól­ne­go ze struk­tu­ral­ny­mi meto­da­mi ana­li­zy i pro­jek­to­wa­nia opro­gra­mo­wa­nia (cze­go wie­lu zda­je się nadal nie dostrze­gać). Wygląda na to, że jest znacz­nie trud­niej­sza ale prak­ty­ka poka­zu­je, że daje znacz­nie lep­sze rezul­ta­ty. Języki obiek­to­we to nie jakaś tam nowa nazwa kla­sy na pod­pro­gra­my, a zupeł­nie nowy para­dyg­mat pro­gra­mo­wa­nia: musi być poprze­dza­ny ana­li­zą i pro­jek­tem. Jego zale­tą jest to, że pozwa­la na odwzo­ro­wy­wa­nie, nie­mal­że jak w grze, ana­li­zo­wa­ne­go i roz­wią­zy­wa­ne­go pro­ble­mu, pozwa­la na prze­te­sto­wa­nie pomy­słu na pro­gram zanim powsta­nie choć jed­na linia pro­gra­mu. Problemem i wyzwa­niem na eta­pie ana­li­zy jest zro­zu­mie­nie pro­ble­mu, co mam nadzie­ję poka­za­łem. Niestety wie­le ana­liz doku­men­to­wa­nych z uży­ciem nota­cji UML nie ma wie­le wspól­ne­go z OOAD, sta­no­wią echa struk­tu­ral­nych metod ana­li­zy i pro­jek­to­wa­nia, sto­so­wa­nia baz rela­cyj­nych już na eta­pie ana­li­zy (obiek­to­we narzę­dzia nie czy­nią pro­jek­tów obiek­to­wy­mi). Niestety błę­dy te popeł­nia­ją nawet wykła­dow­cy wie­lu uczel­ni i kur­sów. (Źródło: Plansza do gry w sza­chy czy­li ana­li­za i pro­jek­to­wa­nie | | Jarosław Żeliński IT-Consulting).

Autor arty­ku­łu przy­wo­łu­je nie­zmien­ną od lat statystykę:

According to an often-quoted stu­dy from the Gartner Group, 75% of IT pro­jects fail. The Standish Group con­ducts an annu­al survey of IT pro­jects. Their latest report shows a decre­ase in pro­ject suc­cess rates.

  1. 32% of all pro­jects suc­ce­eded: deli­ve­red on time, on bud­get, with requ­ired features.
  2. 44% were chal­len­ged: late, over bud­get, and/or with less than the requ­ired features.
  3. 24% failed: can­cel­led prior to com­ple­tion or deli­ve­red and never used.

When we look back, we not only see failu­res but can cle­ar­ly see the boom the softwa­re indu­stry has been given with its suc­cess. But the wor­ry­ing aspect is that the­re are failu­res that are recur­ring eve­ry year, may­be in a dif­fe­rent orga­ni­za­tion but mostly with com­mon cau­ses. (Źródło: Blueprints Are Not Requirements!)

…i zwra­ca uwa­gę, że ich przy­czy­ny są od lat sta­le takie same…

Requirements must be based on facts and real-life sce­na­rios.” (wyma­ga­nia muszą być opar­te na fak­tach i real­nych sce­na­riu­szach). Więc ile war­te są wizje w pro­jek­tach agi­le albo wydu­ma­ne w toku warsz­ta­to­wych burz mózgów lita­nie życzeń i pomy­słów? Nie tyl­ko moim zda­niem: nie są wie­le war­te i nie powin­ny być wymaganiami.

złożoność złożony system skomplikowany http://hikingartist.files.wordpress.com/

Kolejna wpadka IT: obiektowość

CW 4-1019 Bereza Blad Arystotelesa w IT
CW 4 – 1019 Bereza Blad Arystotelesa w IT

Tym razem wpadł mi w oko dosko­na­ły arty­kuł Pana Bogdana Berezy w COMPUTEROWRLD nr. 4 – 1019 z tego roku. Polecam cały arty­kuł do prze­czy­ta­nia, a po pra­wej cytat, któ­ry obu­dził we mnie potrze­bę uzupełnienia.

Cały arty­kuł doty­czy igno­ro­wa­nia nauki w inży­nie­rii opro­gra­mo­wa­nia na rzecz pro­stych pseu­do­ro­zwią­zań. Tu się z auto­rem w peł­ni zga­dzam: nauka jako szu­ka­nie zro­zu­mie­nia i roz­wią­zań pro­ble­mów poprzez ana­li­zę i uogól­nia­nie ma głę­bo­ki sens, histo­ria poka­zu­je, że tak zwa­ne meto­dy nauko­we są sku­tecz­ne (o czym nie raz tu już pisa­łem) ale też nie­lu­bia­ne bo trudne.

Autor napi­sał tak­że (cytat po pra­wej, moim zda­niem praw­dę), że nastą­pi­ło pew­ne sza­leń­stwo, któ­re w moich oczach dopro­wa­dzi­ło w bran­ży IT to total­ne­go pomie­sza­nia pojęć (ostat­ni aka­pit cyta­tu obok). Nie zgo­dzę się jed­nak z tym, że dane i funk­cje, zade­kla­ro­wa­ne wewnątrz jed­nej funk­cji prze­sta­ją ist­nieć, gdy się te funk­cję opu­ści” (pierw­szy aka­pit cyta­tu po pra­wej). Otóż w meto­dach obiek­to­wych nie ist­nie­je poję­cie funk­cji”, są ope­ra­cje i meto­dy oraz atry­bu­ty a nie dane, a znik­nąć mogą co naj­wy­żej atry­bu­ty obiek­tu (tu trak­to­wa­ne jako jakieś dane) pod warun­kiem, że go – ten obiekt – znisz­czy­my. Tu chy­ba jed­nak mamy pomie­sza­nie pojęć (dodam, że nie rozu­miem stwier­dze­nia funk­cja zawie­ra funk­cje i dane”).

W czym pro­blem? Otóż nale­ży bar­dzo rygo­ry­stycz­nie odróżnić:

  • ana­li­zę obiek­to­wą (OOA – Object Oriented Analysis)
  • pro­jek­to­wa­nie obiek­to­we (OOD – Object Oriented Design)
  • pro­gra­mo­wa­nie obiek­to­we (OOP – Object Oriented Programming)

Autor arty­ku­łu, pisząc jedy­nie o pro­gra­mo­wa­nie obiek­to­wym, w moich oczach ma rację. Co do zgod­no­ści OO z psy­chi­ką to i ja mam wąt­pli­wo­ści, i tu chy­ba fak­tycz­nie pomy­sło­daw­cy popłynęli.

Tu przy­po­mnę kolej­ne waż­ne pojęcia:

  • ogól­na teo­ria sys­te­mów to teo­ria ope­ru­ją­ca poję­ciem sys­tem, defi­nio­wa­nym jako zbiór ele­men­tów współ­pra­cu­ją­cych w okre­ślo­nym celu”, teo­ria ta w zasa­dzie sta­no­wi obec­nie pod­sta­wę tak zwa­nych metod naukowych,
  • para­dyg­mat obiek­to­wy to trak­to­wa­nie okre­ślo­nej rze­czy­wi­sto­ści jako zbio­ru współ­pra­cu­ją­cych obiek­tów reali­zu­ją­cych okre­ślo­ne funk­cje wobec swo­je­go otoczenia”.

Jak widać są to bar­dzo do sie­bie podob­ne (nie­mal­że toż­sa­me) poję­cia. Studiując lite­ra­tu­rę przed­mio­tu zary­zy­ku­ję tezę, że ta zbież­ność nie jest przy­pad­ko­wa :), pierw­sze obiek­to­we języ­ki pro­gra­mo­wa­nia powsta­ły w ośrod­kach aka­de­mic­kich na potrze­by pro­wa­dze­nia badań opar­tych o symulacje.

W świe­cie ludzi IT” poję­cie obiek­to­wo­ści” zosta­ło cał­ko­wi­cie zawłasz­czo­ne na uży­tek języ­ków pro­gra­mo­wa­nia. Jest to w moich oczach wiel­ka szko­da wyrzą­dzo­na obiek­to­we­mu podej­ściu, teo­rii a tak­że samej inży­nie­rii opro­gra­mo­wa­nia. Autor ma rację pisząc, że obiek­to­wość” jako taka (powyż­sze defi­ni­cje) nie ma nic wspól­ne­go (nie tyl­ko) z prze­no­sze­niem danych ze sto­su na ster­tę czy z dzie­dzi­cze­niem. Ale to wła­śnie efekt tego zawłasz­cze­nia (i opis imple­men­ta­cji obiek­to­wo­ści” w języ­kach programowania).

Gdzie zalety i sukces obiektowości?

Jednym z klu­czo­wych czyn­ni­ków ryzy­ka pro­jek­tów z obsza­ru inży­nie­rii opro­gra­mo­wa­nia, two­rzo­ne­go dla firm i orga­ni­za­cji, jest zła jakość spe­cy­fi­ka­cji wyma­gań. Zajmuję się o tym od lat, wszel­kie (słusz­nie skry­ty­ko­wa­ne przez Pana Berezę) pro­ste meto­dy zbie­ra­nia wyma­gań” dają w efek­cie to, co nazy­wa­ne jest nie­kom­plet­no­ścią i nie­spój­no­ścią. Przyczyną pora­żek pro­jek­tów pro­gra­mi­stycz­nych, poda­wa­ną w 100% przy­pad­ków tych pora­żek, jest nie­kom­plet­ność i nad­mia­ro­wość spe­cy­fi­ka­cji wyma­gań. Niekompletność to wyma­ga­nia odkry­wa­ne dopie­ro na eta­pie wdro­że­nia, nad­mia­ro­wość to tak zwa­ne wyma­ga­nia osie­ro­co­ne, czy­li funk­cjo­nal­no­ści zgło­szo­ne jako wyma­ga­ne na eta­pie ana­li­zy wyma­gań i nie wyko­rzy­sty­wa­ne po dostar­cze­niu opro­gra­mo­wa­nia. Pierwsze gene­ru­ją dodat­ko­we kosz­ty, dru­gie to czy­ste mar­no­traw­stwo środ­ków. Nieodkryte wyma­ga­nia dodat­ko­wo nisz­czą” pier­wot­ny harmonogram.

Jak poma­ga tu obiek­to­wość”? Pomaga jako meto­da ana­li­zy, poma­ga jako meto­da pro­jek­to­wa­nia, poprze­dza­ją­ce­go spe­cy­fi­ko­wa­nie wyma­gań. W czym rzecz?

Popularna i fał­szy­wa teza, mówią­ca, że wyma­ga­nia się zbie­ra”, pro­wa­dzi do dekla­ra­tyw­nej i nie­we­ry­fi­ko­wal­nej spe­cy­fi­ka­cji wyma­gań funk­cjo­nal­nych i poza-funk­cjon­la­nych (przy­po­mi­nam wyma­ga­nia odkry­te i osie­ro­co­ne). Popularna i mitycz­na jakość wyma­gań nazy­wa­na SMART i FURPS nie daje żad­ne­go narzę­dzia do testo­wa­nia kom­plet­no­ści i nie­sprzecz­no­ści wyma­gań, więc nie da się stwier­dzić, że kon­kret­na spe­cy­fi­ka­cja wyma­gań jest SMART i FURPS, wcze­śniej niż po zakoń­cze­niu pro­jek­tu. Tak więc FURPS i SMART spo­koj­nie, moim zda­niem, moż­na zali­czyć do tego co Pan Bereza nazy­wa bzdur­ną misty­fi­ka­cją”, i co nie­ja­ko wyja­śnia pew­na filo­zo­ficz­na praw­da” mówią­ca: nie ist­nie­ją pro­ste meto­dy roz­wią­zy­wa­nia zło­żo­nych problemów.

Sprawdzoną w inży­nie­rii jako takiej, meto­dą, jest pro­ces wytwór­czy mają­cy trzy eta­py: ana­li­za potrzeb, pro­jek­to­wa­nie i testy, wyko­na­nie (wytwo­rze­nie) na bazie pro­jek­tu. Wprowadzenie zmian w każ­dym następ­nym eta­pie jest prze­cięt­nie o rząd wiel­ko­ści kosz­tow­niej­sze. Wynika z tego, że inwe­sty­cja w ana­li­zę i pro­jek­to­wa­nie poprze­dza­ją­ce budo­wę, jest jak naj­bar­dziej uza­sad­nio­na. Jednak kolek­cjo­no­wa­nie wyma­gań” to nie jest żad­na ana­li­za, to dopie­ro zbie­ra­nie danych do analizy.

A gdzie tu OOA, OOD, OOP?

Jak podejść do pro­ble­mu spe­cy­fi­ko­wa­nia wyma­gań” z dużo mniej­szym ryzy­kiem? Zamówić opro­gra­mo­wa­nie na bazie pro­jek­tu, a nie na bazie opi­su czar­nej skrzyn­ki”. Co pro­jek­to­wać? Na pew­nie nie wszyst­ko. Wg. róż­nych sza­cun­ków, tak zwa­na logi­ka biz­ne­so­wa to ok. 3 – 5% cało­ści kodu (któ­ry zawie­ra mię­dzy inny­mi roz­bu­do­wa­ne kom­po­nen­ty komu­ni­ka­cyj­ne, inte­gra­cyj­ne, wydaj­no­ścio­we, bez­pie­czeń­stwa, set­ki biblio­tek, itp.) pro­blem w tym, że te 3 – 5% kodu decy­du­je w 100% o przy­dat­no­ści aplikacji.

Analiza obiek­to­wa (OOA) to meto­da ana­li­zy i opi­su przed­mio­tu ana­li­zo­wa­ne­go (np. orga­ni­za­cji). Projektowanie obiek­to­we (OOD) to meto­da opi­su logi­ki dzia­ła­nia tego co chce­my stwo­rzyć (narzę­dzie pra­cy). Programowanie obiek­to­we to jest to co przy­wo­łał Pan Bereza, jed­nak cechą OOP jest to, że pro­jekt obiek­to­wy, pro­dukt OOD jest moż­li­wy do imple­men­ta­cji wprost” w języ­ku obiek­to­wym na eta­pie OOP. Innymi sło­wy wyma­ga­niem nie jest lista wyma­gań” a pro­jekt, ana­lo­gicz­nie jak w każ­dej innej inży­nie­rii: wyma­ga­niem wobec wyko­naw­cy jest pro­jekt tego co nale­ży wyko­nać a nie tyl­ko słow­ny opis tego cze­go ocze­ku­je zamawiający.

OOA i OOD jest łączo­ne w OOAD z tego powo­du, że obiek­to­wy opis (model) cze­goś” jest 9w meto­dach obiek­to­wych) zara­zem pro­jek­tem tego cze­goś”. Mając obiek­to­wy model opro­gra­mo­wa­nia (czę­ści opi­su­ją­cej jego biz­ne­so­wą logi­kę dzia­ła­nia, nazy­wa­nej Modelem Dziedziny) może­my spraw­dzić (prze­te­sto­wać) jak speł­nia on wyma­ga­nia funk­cjo­nal­ne zanim jesz­cze, powsta­nie znacz­nie droż­sza od pro­jek­tu, imple­men­ta­cja. Mamy szan­se, rela­tyw­nie niskim kosz­tem, zmie­nić pro­jekt zanim uru­cho­mi­my kosz­tow­ny zespół pro­gra­mi­stów. Na bazie takie­go mode­lu moż­li­we jest w ogó­le wyko­na­nie ana­li­zy wyko­nal­no­ści.

Metoda ta jest spraw­dzo­na, dzia­ła, jest sku­tecz­na. Pierwszy, gło­śno, napi­sał o tym Eric Evans w dzie­le Domain-Driven Design: Tackling Complexity in the Heart of Software (pisa­łem o tym tu: Poziomy szcze­gó­ło­wo­ści wyma­gań ? wzor­ce DDD ? czy­li czym jest ana­li­za obiek­to­wa). Problem pole­ga na tym, że biz­ne­so­wa ana­li­za obiek­to­wa (OOAD), dają­ca jako efekt model dzie­dzi­ny (czy­li sed­no biz­ne­so­wych apli­ka­cji), wyma­ga zupeł­nie innych kom­pe­ten­cji (nie licząc rozu­mie­nia samej obiek­to­wo­ści) niż kom­pe­ten­cje pro­gra­mi­stów i archi­tek­tów opro­gra­mo­wa­nia. Nie praw­dą jest, że tyl­ko deve­lo­per” ma tu kom­pe­ten­cje do pro­jek­to­wa­nia opro­gra­mo­wa­nia. W obsza­rze ana­li­zy i mode­lo­wa­nia biz­ne­su” z regu­ły nie ma żad­nych kom­pe­ten­cji. Potwierdza to tak­że obec­ny model kom­pe­ten­cji Analityka Biznesowego pre­zen­to­wa­ny przez orga­ni­za­cję IIBA.

Tak więc obiek­to­wość jako pana­ceum na pro­ble­my pro­gra­mi­stów i pro­gra­mo­wa­nia to w moich oczach jak naj­bar­dziej wpad­ka. Obiektowość jako sku­tecz­ne meto­da ana­li­zy świa­ta” i jego mode­lo­wa­nia to suk­ces, ale to tyl­ko kon­ty­nu­acja roz­wo­ju ogól­nej teo­rii sys­te­mów. Obiektowość dała tej teo­rii bar­dzo dobre narzę­dzie – obiek­to­we meto­dy mode­lo­wa­nia. Specyfikowanie wyma­gań w posta­ci czar­nej skrzyn­ki się nie spraw­dza, sta­ty­sty­ki pora­żek pro­jek­tów są nie­zmien­ne od lat. Specyfikacja wyma­gań w posta­ci pro­jek­tu jest nie­mal­że dosko­na­ła (ale tyl­ko na tyle na ile dosko­na­ły jest projekt). 

Arystoteles (jak słusz­nie zauwa­żył Pan Bereza), uwa­żał, że przed­mio­ty cięż­sze spa­da­ją szyb­ciej i miał on pra­wo posłu­żyć się heu­ry­sty­ką, w jego cza­sach fizy­ka nawet nie racz­ko­wa­ła. Nie zapo­mi­naj­my jed­nak, że Arystoteles dał pod­wa­li­ny dzi­siej­szych metod nauko­wych, tezą: praw­dzi­wa wie­dza to zna­jo­mość przyczyn.

Mamy jed­nak inny para­doks: Znamy sta­ty­sty­ki mówią­ce, że ok. 75% pro­jek­tów IT to poraż­ki, a mimo to nadal naj­czę­ściej sto­so­wa­ne są meto­dy wyko­rzy­sty­wa­ne przez więk­szość”. To się nazy­wa kon­for­mizm Project Managera, któ­ry jak widać, jest sil­niej­szy od umie­jęt­no­ści wycią­ga­nia wnio­sków: histo­ria uczy ludzi, że histo­ria nicze­go ludzi nie nauczyła…

Niski poziom analizy…

Pod arty­ku­łem Plansza do gry w sza­chy, zna­lazł się mię­dzy inny­mi taki komentarz:

Kolejna kwe­stia to taka, że nie widzę war­to­ści w tak nisko­po­zio­mo­wej ana­li­zie. Diagram dzie­dzi­ny i ilu­stra­cja Inicjacji gry są nie­zro­zu­mia­łe dla mnie jako laika i tak samo będą nie­zro­zu­mia­łe dla moje­go klien­ta. Nie wiem więc cze­mu dokład­nie słu­żą i co wnoszą.

Powyższe to typo­we podej­ście zama­wia­ją­ce­go lub (i) spon­so­ra pro­jek­tu. To co tu teraz napi­szę, to abso­lut­nie nie jest kry­ty­ka auto­ra powyż­szej wypo­wie­dzi. To ste­reo­ty­po­we, stan­dar­do­we podej­ście wie­lu zama­wia­ją­cych (i nie raz ich pośred­ni­ków) sys­te­my IT: sam zama­wiam i sam odbieram.

To trosz­kę tak, jak by pod­miot inwe­stu­ją­cy w biu­ro­wiec w cen­trum mia­sta sam podej­mo­wał się oce­ny doku­men­ta­cji tech­nicz­nej wyko­na­nej przez archi­tek­ta, algo gorzej: uznał, że sko­ro tej doku­men­ta­cji nie rozu­mie to jej po pro­tu nie chce! Paradoksalnie, powyż­sze podej­ście to naj­częst­sza przy­czy­na pora­żek pro­jek­tów (budow­nic­two wypra­co­wa­ło praw­ne zasa­dy, IT się jesz­cze bro­ni gło­sa­mi dostawców).

W czym pro­blem? Dokładnie w tym, z czym spo­ty­ka­my się kupu­jąc samo­chód: kupu­ją­cy uwa­ża, że rozu­mie to co widzi i cze­go potra­fi użyć (przy­po­mnę, że każ­dy kie­row­ca uży­wa w samo­cho­dzie skrzy­ni bie­gów ale nie każ­dy rozu­mie jej dzia­ła­nie). Pokazanie (opi­sa­nie) w salo­nie, jaki samo­chód jest nam potrzeb­ny, to góra kil­ka godzin. Przekonanie się o tym, co na praw­dę kupi­li­śmy, to już co naj­mniej kil­ka­set (a nie raz kil­ka tysię­cy) prze­je­cha­nych kilo­me­trów. Prawdę o tym co kupi­li­śmy powie nam dopie­ro mecha­nik po zaku­pie, jest to jed­nak za póź­no na zmia­ny. Kto z Państwa sko­rzy­stał z pora­dy dobre­go mecha­ni­ka przed zaku­pem samo­cho­du? Pamiętajmy, że samo­chód to tysią­ce współ­pra­cu­ją­cych pod­ze­spo­łów, któ­re z nich zna­cie, rozu­mie­cie i widzi­cie? A wszyst­kie mają wpływ na walo­ry użyt­ko­we samochodu.

Projekty IT wyglą­da­ją bar­dzo podob­nie, mało kto – przed wybo­rem dostaw­cy opro­gra­mo­wa­nia – pła­ci za ana­li­zę, pra­wie nikt za pro­jekt, któ­re­go nie rozu­mie, ale pra­wie każ­dy sam zama­wia (opi­su­jąc cza­sem jakieś swo­je wyma­ga­nia) i nie­ste­ty pra­wie każ­dy pro­jekt (przy­po­mnę, że to ponad 75%) to kło­po­ty dla kupu­ją­ce­go i na koszt kupującego.

cennik-mechanika

Odpowiedź na zarzut cytowany na początku

W pro­jek­tach ana­li­tycz­nych mamy trzy klu­czo­we eta­py: ana­li­za, pro­jek­to­wa­nie oraz wytwo­rze­nie. Analiza to coś co zro­zu­mie każ­dy zama­wia­ją­cy, bo jej efek­tem jest opis jego wła­snej dzia­łal­no­ści. Powstaje po to, by nikt nie miał wąt­pli­wo­ści jaki jest biz­ne­so­wy cel pro­jek­tu i jak będzie on reali­zo­wa­ny (ale celem biz­ne­so­wym pro­jek­tu nie jest zakup opro­gra­mo­wa­nia!, to jeden z moż­li­wych spo­so­bów jego reali­za­cji). W mię­dzy­cza­sie powsta­je model pro­ce­so­wy, to doku­ment dla ana­li­ty­ka. Celem jego two­rze­nia jest mini­ma­li­za­cja ryzy­ka nie­kom­plet­no­ści i nie­spój­no­ści pro­jek­tu i doku­men­ta­cji wyma­gań. Nie jest praw­dą, że zama­wia­ją­cy ma tu coś do spraw­dze­nia, ale praw­da jest, że zama­wia­ją­cy bie­rze udział w jego testo­wa­niu (spraw­dze­niu popraw­no­ści). Model pro­ce­sów to for­mal­ny opis wyma­ga­ją­cy już pew­nej wiedzy. 

Podstawowym błę­dem jaki popeł­nia­ją zle­ce­nio­daw­cy ana­liz, jest pró­ba for­so­wa­nia zmian w mode­lach w rodza­ju pro­szę mi dopi­sać jesz­cze, że cza­sa­mi ten doku­ment tra­fia do…”. 

Model to pew­na for­mal­na struk­tu­ra. Model gry w sza­chy to sza­chow­ni­ca, bier­ki i regu­ły gry, a nie set­ki godzin fil­mów nakrę­co­nych pod­czas roz­gry­wa­nia real­nych par­tii. Niestety więk­szość widzi i podzi­wia roz­gry­wa­ne par­tie i ocze­ku­je fil­mu, jed­nak opro­gra­mo­wa­nie BigBlue (kom­pu­ter z tym pro­gra­mem wygrał w sza­chy z mistrzem świa­ta) to nie tysią­ce zapi­sa­nych par­tii gry, a pro­gram mają­cy zaim­ple­men­to­wa­ne regu­ły gry… nie­ste­ty tak to wygląda.

Analityk może oddać jako wyma­ga­nie tak­że prze­te­sto­wa­ny pro­jekt logicz­ny opro­gra­mo­wa­nia. Wtedy wyma­ga­na jest tak­że zgod­ność zacho­wa­nia się opro­gra­mo­wa­nia z tą logi­ką. Po co? By wyeli­mi­no­wać ryzy­ka, któ­rych źró­dłem jest nie­zro­zu­mie­nie biz­ne­su zama­wia­ją­ce­go przez deve­lo­pe­ra (to zresz­tą nie jego rola), oraz ryzy­ka zwią­za­ne z budo­wa­niem mar­ży po stro­nie wyko­naw­cy (uprasz­cza­nie pro­jek­tu w celu obni­że­nia pracochłonności).

Istnieje nie­ste­ty tak­że bar­dzo duże ryzy­ko, któ­re­go źró­dłem jest sto­so­wa­nie sta­rych, struk­tu­ral­nych metod wytwa­rza­nia opro­gra­mo­wa­nia czy­li roz­biór” (i pro­jekt) sys­te­mu na bazę danych i pro­ce­du­ry. Ta prak­ty­ka (meto­da) nie­ste­ty daje jako efekt opro­gra­mo­wa­nie bar­dzo kosz­tow­ne w pro­jek­to­wa­niu i roz­wo­ju. Od metod struk­tu­ral­nych znacz­nie lep­sze są meto­dy obiek­to­we, nie­ste­ty samo dekla­ro­wa­nie korzy­sta­nia z .NET czy Java albo nota­cji UML nie czy­ni sto­so­wa­nych metod obiektowymi.

software_development

Metody zwin­ne, to być może dosko­na­łe meto­dy pra­cy w pro­jek­tach zwią­za­nych ze spo­łecz­no­ścio­wy­mi stro­na­mi WWW, ale w pro­jek­tach biz­ne­so­wych nie­ste­ty są to meto­dy tak­że bar­dzo kosz­tow­ne i nie­prze­wi­dy­wal­ne, dla­te­go pro­jek­ty zwin­ne to bar­dzo rzad­ko pro­jek­ty o usta­lo­nym w umo­wie zakre­sie (opis tego co ma powstać). Po lewej stro­nie (dia­gram ze stron pew­ne­go deve­lo­pe­ra) typo­wa zwin­na” pro­ce­du­ra two­rze­nia opro­gra­mo­wa­nia: usu­wa­nie przez deve­lo­pe­ra błę­dów pro­jek­tu (szcze­gól­nie doty­czą­cych reali­zo­wa­nej logi­ki biz­ne­so­wej) może być pętlą nie­skoń­czo­ną, któ­rą tyl­ko wyczer­pa­nie budże­tu lub gra­nicz­ny ter­min jest w sta­nie zatrzy­mać, co może nie dać w efek­cie żad­ne­go przy­dat­ne­go produktu.

Na koniec ku prze­stro­dze cytat pew­ne­go użyt­kow­ni­ka systemu: 

Niestety źle dobra­ny sys­tem infor­ma­tycz­ny, mają­cy wspierać/automatyzować czyn­no­ści w pro­ce­sie, może być powo­dem powsta­nia całych pod­ręcz­ni­ków pro­ce­dur nie­uza­sad­nio­nych biz­ne­so­wo, dedy­ko­wa­nych użyt­kow­ni­kom tego sys­te­mu, stwa­rza­jąc przy tym pozo­ry, że to sam pro­ces jest ich źródłem 🙁

Niestety tak się czę­sto koń­czą pro­jek­ty, w któ­rych pomię­to ana­li­zę i pro­jek­to­wa­nie i od razu wybra­no dostaw­cę i pro­dukt (ana­li­za wyko­na­na przez dostaw­ce to raczej jak wdro­żyć to co mamy” a nie jak roz­wią­zać pro­blem użytkownika”).

Problemem więk­szo­ści pro­jek­tów IT jest zało­że­nie, że tyl­ko dostawca/wykonawca usłu­gi ma wie­dzę o tym jak to zro­bić. Tezę tę for­su­ją naj­czę­ściej wła­śnie wyko­naw­cy (deve­lo­pe­rzy), a pro­blem pole­ga na tym, że wyko­naw­ca dąży tu do sytu­acji, w któ­rej sam sobie sta­wia wyma­ga­nia a potem roz­li­cza ich reali­za­cję. 

Wykonanie ana­li­zy wyma­gań wła­sny­mi zaso­ba­mi (kupu­ją­ce­go) z regu­ły daje złe efek­ty, powo­dem są zbyt sil­ne zależ­no­ści wła­snych pra­cow­ni­ków mię­dzy sobą i ich zależ­ność od aktu­al­nie posia­da­nych zaso­bów. Do tego docho­dzi brak obiek­ty­wi­zmu i obcią­że­nie do zacho­wa­nia wła­snej pozycji.

Plansza do gry w szachy czyli analiza i projektowanie

Na ten wpis pew­nie wie­lu z Was cze­ka, tak przy­naj­mniej suge­ru­ją listy do mnie i gło­sy na forach, a tak­że poten­cjal­ni klien­ci. Ci, któ­rych nie­ste­ty cza­sem kry­ty­ku­ję, tak­że pew­nie cze­ka­ją. Pokażę na pro­stym przy­kła­dzie, pro­ces od ana­li­zy przez wyma­ga­nia aż do pro­jek­tu dedy­ko­wa­ne­go opro­gra­mo­wa­nia. Całość będzie zgod­na z faza­mi CIM/PIM (www​.omg​.org/​mda). Projekt dzie­dzi­ny, któ­ry powsta­nie będzie speł­niał zasa­dy SOLID pro­jek­to­wa­nia obiek­to­we­go, pro­jek­to­wa­nia przez kom­po­zy­cje (zamiast dzie­dzi­cze­nia) (pole­cam arty­kuł Łukasza Barana) i DDD. Opis doty­czy każ­de­go pro­jek­tu zwią­za­ne­go z opro­gra­mo­wa­niem, tak­że goto­wym np. ERP, CRM, EOD itp.

Korzystałem z opi­su zasad gry w sza­chy zamiesz­czo­ne­go na WIKI:

Zasady gry w sza­chy ? pra­wi­dła regu­lu­ją­ce spo­sób roz­gry­wa­nia par­tii sza­chów. Choć pocho­dze­nie gry nie zosta­ło dokład­nie wyja­śnio­ne, to współ­cze­sne zasa­dy ukształ­to­wa­ły się w śre­dnio­wie­czu. Ewoluowały one do począt­ków XIX wie­ku, kie­dy to osią­gnę­ły wła­ści­wie swą bie­żą­cą postać. W zależ­no­ści od miej­sca zasa­dy gry róż­ni­ły się od sie­bie, współ­cze­śnie za prze­pi­sy gry odpo­wia­da Międzynarodowa Federacja Szachowa (Fédération Internationale des Échecs, FIDE). Przepisy te mogą się róż­nić w przy­pad­ku róż­nych warian­tów gry, np. dla sza­chów szyb­kich, bły­ska­wicz­nych czy kore­spon­den­cyj­nych. (Zasady gry w sza­chy ? Wikipedia, wol­na ency­klo­pe­dia).

To na co chcę zwró­cić tu uwa­gę w szcze­gól­no­ści, to metafora:

pro­jek­tu­jąc (mode­lu­jąc) opro­gra­mo­wa­nie dla czło­wie­ka, mode­lu­je­my narzę­dzie dla tego czło­wie­ka a nie jego samego.

Swego cza­su pisa­łem, w arty­ku­le o nazy­wa­niu klas, że opro­gra­mo­wa­nie z regu­ły zastę­pu­je dotych­cza­so­we narzę­dzie czło­wie­ka a nie czło­wie­ka jako takie­go. Druga waż­na rzecz: aktor jest rów­no­praw­nym ele­men­tem sys­te­mu (tu sys­te­mem jest orga­ni­za­cja z jej ludź­mi i uży­wa­ny­mi przez nich narzę­dzia­mi). No to zaczynamy.

Czytaj dalej… Plansza do gry w sza­chy czy­li ana­li­za i pro­jek­to­wa­nie”