eurekaZ poję­ciem ana­li­zy wyma­gań spo­ty­kam się regu­lar­nie, co chy­ba w moim przy­pad­ku nie jest zasko­cze­niem :). Jednak jest pewien niu­ans, któ­ry moż­na wychwy­cić ana­li­zu­jąc takie ana­li­zy wyma­gań, a tak­że słu­cha­jąc opo­wia­dań o przy­go­dach programistów.

Miałem nie­daw­no kolej­ny audyt doku­men­ta­cji wyma­gań opra­co­wa­nej samo­dziel­nie przez zama­wia­ją­ce­go. Była duża i trud­na w odbio­rze”, kil­ka osób z tej fir­my spi­sa­ło, każ­da dla swo­je­go dzia­łu i ze swo­jej per­spek­ty­wy, ocze­ki­wa­nia. Uporządkowali to tema­tycz­nie. Te kil­ka osób, plus ich pod­wład­ni, pra­co­wa­li nad tym trzy mie­sią­ce (mimo, że nie full time” to jed­nak suge­ru­je sobie same­mu osza­co­wać koszt tej pra­cy). Dokument w pier­wot­nej wer­sji prak­tycz­nie nie był przy­dat­ny. Drugim powo­dem napi­sa­nia tego arty­ku­ły była dys­ku­sja na pew­nym forum na temat kom­pe­ten­cji w IT, ale o tym na końcu.

Praktycznie zawsze spe­cy­fi­ka­cja wyma­gań wyko­na­na samo­dziel­nie przez zama­wia­ją­ce­go, to tak na praw­dę opis tego cze­go sobie życzy na bazie swo­ich dotych­cza­so­wych doświad­czeń. Regułą w takich przy­pad­kach w zasa­dzie jest to, że nowy sys­tem” to coś lep­sze­go od tego co mamy teraz”. Specyfikacja wyma­gań (jej treść) spro­wa­dza się do listy popra­wek i nowych żądań. Jeżeli wyma­ga­nia zosta­ły opra­co­wa­ne jako zapis wywia­dów lub ankiet przez tak zwa­ne­go ana­li­ty­ka” z zewnątrz (pra­cow­nik dostaw­cy opro­gra­mo­wa­nia, nie­za­leż­ny ana­li­tyk), efek­ty są prak­tycz­nie takie same (pomi­jam tu for­mę ich udokumentowania).

Zacytuje po raz kolej­ny meta­fo­rę z książ­ki Martina Fowlera:

Wyobraźmy sobie kogoś, kto chce napi­sać pro­gram symu­lu­ją­cy grę w sno­oke­ra. Problem ten może zostać opi­sa­ny przy­pad­ka­mi uży­cia opi­su­ją­cy­mi powierz­chow­nie cechę: ?Gracz ude­rza bia­ła kulę, któ­ra prze­miesz­cza się z pew­ną pręd­ko­ścią, ta po okre­ślo­nym cza­sie ude­rza czer­wo­ną kulę pod okre­ślo­nym kątem, ude­rzo­na czer­wo­na kula prze­miesz­cza się na pew­na odle­głość w pew­nym kie­run­ku.? Możesz sfil­mo­wać set­ki tysię­cy takich ude­rzeń, zare­je­stro­wać para­me­try każ­de­go ude­rze­nia i jego skut­ki. Jednak tą meto­dą i tak nie stwo­rzysz nawet dość dobrej symulacji.

Jak nie trud­no się domy­śleć ana­li­za wyma­gań nie może trwać w nie­skoń­czo­ność, powsta­nie mało takich opi­sów sce­na­riu­szy czy­li opis moc­no nie­kom­plet­ny. Zapis wywia­dów, obser­wa­cje, ankie­ty i poprze­sta­nie na nich, nie mają pra­wa się spraw­dzić bo w skoń­czo­nym cza­sie na ana­li­zę zawsze będzie ich za mało a i tak będą cha­otycz­ne (będzie to tyl­ko część tego co może się wyda­rzyć i nie wia­do­mo, ile to pro­cent cało­ści bo nie zna­my wszystkich).

Przypadki uży­cia same w sobie, sta­no­wią bar­dzo mier­ne przy­bli­że­nie rze­czy­wi­sto­ści. Oddanie pro­gra­mu do użyt­ku, reali­zu­ją­ce­go tyl­ko ?kon­kret­ne sce­na­riu­sze? i to w spo­sób ?obmy­ślo­ny? przez pro­gra­mi­stę, któ­ry nie potra­fi grać w sno­oke­ra a tyl­ko sły­szał od gra­cza jak się to robi, naj­pew­niej skoń­czy się zaba­wą w kolej­ne ite­ra­cje, pro­to­ty­py itp. Taki pro­gram będzie coraz lep­szy ale nadal nie dotknie nawet reali­zmu sno­oke­ra (wię­cej o tym tu Czy wyma­ga­nia opi­su­ją tyl­ko to ?co? sys­tem ma robić?).

Fowler pisze:

Aby napi­sać na praw­dę dobrą grę, powi­nie­neś raczej zro­zu­mieć pra­wa rzą­dzą­ce ruchem kul, ich zależ­ność od siły i kie­run­ku ude­rze­nia, kie­run­ku itp. Zrozumienie tych praw pozwo­li Ci znacz­nie łatwiej napi­sać dobre oprogramowanie.

I tu jest sed­no: ana­li­za nie powin­na być tyl­ko pasmem wywia­dów, któ­re­go pro­duk­tem będę set­ki stron zapi­sów z ankiet i prze­pro­wa­dzo­nych roz­mów. Analiza, to duża pra­ca, któ­rej celem powin­no być zro­zu­mie­nie a nie tyl­ko opisanie. 

Jaka jest róż­ni­ca? Produktem ana­li­zy, czy­li zro­zu­mie­nia zja­wi­ska (pra­cy fir­my itp.) jest model jej logi­ki dzia­ła­nia (logi­ka biz­ne­so­wa), ten model – popraw­ny – pozwa­la prze­wi­dy­wać co nas cze­ka (testo­wa­ny jest na popraw­ność loso­wo wybra­ny­mi zda­rze­nia­mi w fir­mie). Ten model to model dzie­dzi­ny sys­te­mu (model logi­ki biz­ne­so­wej: spe­cy­fi­ka­cja reguł biz­ne­so­wych). Produktem wywia­dów jest nie­ste­ty wyłącz­nie opis skut­ków w reak­cji na bodź­ce (np. przy­pad­ki uży­cia) ale nadal nie­zro­zu­mia­łe jest to dla­cze­go aku­rat takie” skutki.

Wszystko to co nas ota­cza, samo w sobie jest natu­ral­nie pro­ste. Złożone są, nie poszcze­gól­ne rze­czy, a to, że jest ich wie­le i mają na sie­bie wza­jem­ny wpływ. Celem ana­li­zy jest ziden­ty­fi­ko­wa­nie w naszym oto­cze­niu tych pro­stych ele­men­tar­nych rze­czy i zro­zu­mie­nie ich wza­jem­ne­go na sie­bie wpły­wu. Zrozumienie to mani­fe­stu­je się w posta­ci umie­jęt­no­ści stwo­rze­nia mode­lu tych współ­ist­nie­ją­cych pro­stych rze­czy, zro­zu­mie­nia i opi­sa­nia ich cech i reguł wza­jem­ne­go oddzia­ły­wa­nia. Jeżeli tym ana­li­zo­wa­nym śro­do­wi­skiem jest orga­ni­za­cja, powsta­nie jej model, wie­dza o tym jak funk­cjo­nu­je. A gdzie tu jest miej­sce na opro­gra­mo­wa­nie? By powsta­ło, nale­ży stwo­rzyć tak­że i jego model, by zro­zu­mieć i opi­sać to cze­go potrze­buj­my. Pamiętajmy, że jed­na z naj­trud­niej­szych gier na świe­cie ? sza­chy ? to tyl­ko kil­ka­na­ście figur i pro­ste regu­ły ich prze­miesz­cza­nia. Nawet naj­więk­sza orga­ni­za­cja to tyl­ko skoń­czo­na licz­ba ról i reguł ich postę­po­wa­nia. Należy je tyl­ko odkryć. (żr. Jarosław Żeliński, refe­rat na kon­fe­ren­cji: Firma IT-Consulting Jarosław Żeliński – ana­li­tyk biz­ne­so­wy).

Nie kry­ty­ku­je idei sto­so­wa­nia przy­pad­ków uży­cia, sam je sto­su­ję. One jed­nak są kon­kret­ny­mi, pla­no­wa­ny­mi przy­pad­ka­mi uży­cia opro­gra­mo­wa­nia, to mini­mal­ny zestaw opcji w menu – wyma­ga­ne teraz” usłu­gi sys­te­mu. To nie ma jed­nak nic wspól­ne­go z wewnętrz­ną budo­wą opro­gra­mo­wa­nia, ta powin­na mode­lo­wać zasta­ną rzeczywistość.

Istnieje coś takie­go jak zasa­da SOLID pro­jek­to­wa­nia opro­gra­mo­wa­nia (jed­na z klu­czo­wych cech dobrych pro­jek­tów opro­gra­mo­wa­nia). Cóż to jest SOLID? To roz­wi­nię­cie od ang. Single respon­si­bi­li­ty, Open-clo­sed, Liskov sub­sti­tu­tion, Inter­fa­ce segre­ga­tion and Depen­den­cy inver­sion (wię­cej na stro­nie SOLID (object-orien­ted design) – Wikipedia, the free encyc­lo­pe­dia).

Dzisiaj tyl­ko o skut­kach zanie­dba­nia jed­nej, klu­czo­wej chy­ba wła­sno­ści, któ­ra doty­czy całej apli­ka­cji: Open-Close, któ­ra ozna­cza: apli­ka­cja powin­na być zamknię­ta na zmia­ny i otwar­ta na roz­bu­do­wę.  Dla wie­lu na począt­ku ta zasa­da brzmi wręcz kurio­zal­nie ale ona jak naj­bar­dziej jest moż­li­wa do reali­za­cji. Proszę zwró­cić uwa­gę, że takie wła­snie są dobrze zarzą­dza­ne fir­my, nie ma w nich rewo­lu­cji orga­ni­za­cyj­nej co roku, one się roz­wi­ja­ją a nie zmieniają.

Oprogramowanie, jeże­li w wyni­ku ana­li­zy wyma­gań opra­co­wa­no nie tyl­ko raport z wywia­dów ale tak­że model logi­ki dzia­ła­nia, też speł­ni te zasa­dę. Czym gro­zi jej nie­speł­nie­nie w sto­sun­ku do opro­gra­mo­wa­nia? A tym, do cze­go przy­znał się jeden z pro­gra­mi­stów pod­czas pew­nej dys­ku­sji na forum:

kil­ka razy doświad­czy­łem sytu­acji, że aby speł­nić nowe pro­ste wyma­ga­nie trze­ba było się namę­czyć zarów­no z mode­lem danych jak i apli­ka­cją, Oczywiście moż­na w takiej sytu­acji zarzu­cić, że sys­tem był źle zapro­jek­to­wa­ny, nie­ska­lo­wal­ny, nie prze­strze­gał SOLIDów, nie korzy­stał z wzor­ców itd ale to już jest inna bajka.

Na co ja odpo­wie­dzia­łem: nie, to jest wła­śnie ta baj­ka o nazwie ana­li­za wyma­gań i pro­jek­to­wa­nie, któ­re powin­ny być zro­zu­mie­niem a nie tyl­ko ste­no­gra­mem. Wtedy nowe funk­cjo­nal­no­ści opro­gra­mo­wa­nia moż­na doda­wać bez potrze­by prze­bu­do­wy jego wewnętrz­nej struk­tu­ry. Nie raz jest z powo­du tych kosz­tów po pro­tu nie­moż­li­wy jest roz­wój sys­te­mu. Oceńcie teraz Państwo sami, Ci któ­rzy tego doświad­czy­li, skut­ki wdro­że­nia np. sys­te­mu ERP z kasto­mi­za­cją.… nie­ste­ty ogrom­na więk­szość tego opro­gra­mo­wa­nia nie speł­nia zasa­dy SOLID. Dlaczego? Bo model rela­cyj­ny baz danych, jeże­li obej­mu­je wszyst­kie dane sys­te­mu, nie­ste­ty nie speł­nia tej zasa­dy z zało­że­nia. A dostaw­cy tych sys­te­mów wręcz cie­szą się z tego rekla­mu­jąc się: nasz sys­tem jest w peł­ni zin­te­gro­wa­ny poprzez pra­cę na wspól­nej bazie danych”.… Jak to prze­czy­tasz, nie kupuj tego…

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 7 komentarzy

  1. Sławomir Sobótka

    Pracując z wie­lo­ma zespo­ła­mi pro­gra­mi­stycz­ny­mi zauwa­ży­łem, że pro­blem z SOLID (na pozio­mie deve­lop­men­tu) pole­ga zwy­kle (choć nie zawsze) na tym, że SOLID wyda­je się zbyt pro­sty. Często jest wręcz stry­wia­li­zo­wa­ny do pozio­mu składni.

    Natomiast zasa­dy te moż­na sto­so­wać na pozio­mie mode­lu dome­no­we­go, arch. apli­ka­cji i sys­te­mo­wej z wyko­rzy­sta­niem porząd­nych fra­me­wor­ków, któ­re wspie­ra­ją solid na róż­nych pozio­mach i na róż­ne sposoby.

    Można osią­gnąć na praw­dę dużą gięt­kość nie­wiel­kim narzu­tem. Są tyl­ko dwa warun­ki: zna­jo­mość tech­nik oraz wie­dza o tym, gdzie ta gięt­kość wystę­pu­je i gdzie jest opła­cal­na (czy­li dobre rozu­mie­nie pro­ble­mu dziedzinowego)…

    1. Jarek Żeliński

      Hm… jeże­li ktoś uwa­ża, że SOLID jest pro­sty to podzi­wiam :), bo opra­co­wa­nie pro­jek­tu, w któ­rym np. roz­bu­do­wa pro­ste­go maga­zy­nu ilo­ścio­we­go do pozio­mu maga­zy­nu ope­ru­ją­ce­go egzem­pla­rzem nie jest try­wial­ne :). Chyba klu­czem jest ostat­nie Twoje zdanie :). 

      Osobiście wycho­dzę z zało­że­nia, że sko­ro świat się roz­wi­ja a nie cyklicz­nie wymie­nia na nowy, to trze­ba szu­kać zro­zu­mie­nia tego…:) i zro­bić wła­ści­wy model.

    2. Rafał Osiecki

      Kluczem jest zro­zu­mie­nie zasad SOLID już na pozio­mie kon­cep­tu­al­nym, w cał­ko­wi­tym ode­rwa­niu od fra­me­wor­ków, kodu i tym podob­nych bebe­chów. Zespół któ­ry zna i rozu­mie pod­sta­wo­we pra­wi­dła gry będzie instynk­tow­nie doko­ny­wał dobrych wybo­rów, wie­dząc jak nega­tyw­ne kon­se­kwen­cje nie­sie za sobą zła­ma­nie zasad.

      Dużym pro­ble­mem jest to, że kara za zła­ma­nie zasad nie jest obli­ga­to­ryj­na i jest odro­czo­na w cza­sie. Za zwy­kły błąd skład­ni IDE lub kom­pi­la­tor uka­rze nas natych­mia­sto­wo. W przy­pad­ku gwał­tu na zasa­dach SOLID, kary może­my spo­dzie­wać się po kil­ku mie­sią­cach lub wcale.

      Piszesz o gięt­ko­ści, ale nawet naj­lep­sze zro­zu­mie­nie pro­ble­mu dzie­dzi­no­we­go nie zastą­pi szkla­nej kuli. Nie jeste­śmy w sta­nie prze­wi­dzieć przy­szło­ści, więc więk­szość z tych gięt­kich miejsc pozo­sta­nie bez­u­ży­tecz­na, zwięk­sza­jąc tyl­ko balast, któ­ry dźwi­gać muszą kolej­ne poko­le­nia pro­gra­mi­stów zanu­rza­ją­cych się w projekt.

      Dla mnie gięt­kość to wyna­tu­rzo­na inter­pre­ta­cja zasa­dy otwar­te-zamknię­te, co zwy­kle koń­czy się tym, że mamy na utrzy­ma­niu mnó­stwo kodu typu boiler­pla­te, fabryk i inter­fej­sów z jed­ną imple­men­ta­cją. Czas poświę­co­ny na myśle­nie o gięt­ko­ści lepiej spo­żyt­ko­wać na myśle­nie o pro­sto­cie. Prostota nas wyzwo­li, umoż­li­wi bez­bo­le­sne doda­nie gięt­ko­ści, jeśli tyl­ko w przy­szło­ści będzie taka potrzeba.

    1. Jarek Żeliński

      Zmieniłem duże [G] na loso­wo dobie­ra­ne mon­ste­ry :), zdję­cia się poja­wia­ją gdy ktoś ma pro­fil na Gravatarze 🙂 (roz­po­zna­wa­nie odby­wa się po adre­sie email).

  2. Sławomir Sobótka

    Pisząc zbyt pro­sty” nie mia­łem na myśli, że jest powiedz­my uwa­ża­ny pogar­dli­wie za pro­stac­ki. Chodziło mi o to, że jest inter­pre­to­wa­ny z naiw­nym zało­że­niem aaa, to pro­ste, my to mamy prze­cież, są interfejsy”.

    1. Jarek Żeliński

      Też coś podob­ne­go mia­łem na myśli :), wie­lu pro­gra­mi­stów trak­tu­je SOLID w zupeł­nym ode­rwa­niu o mode­lo­wa­nej rze­czy­wi­sto­ści i to postrze­gam za błąd, bo zapo­mi­na­ją, że poszcze­gól­ne kla­sy to odwzo­ro­wa­nia rze­czy­wi­sto­ści a nie tyl­ko podział kodu na jakieś fragmenty”…

Dodaj komentarz

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