Bardzo czę­sto tak wła­śnie defi­niu­je się pro­dukt ana­li­zy wyma­gań: wyma­ga­nia funk­cjo­nal­ne opi­su­ją to co ma sys­tem robić. W dys­ku­sjach (ile mam ich za sobą :)) z pro­gra­mi­sta­mi prze­bi­ja się teza, że ana­li­tyk spe­cy­fi­ku­je to co” sys­tem ma robić, a oni już zała­twią spra­wę tego jak” ma to robić. W czym pro­blem? W tym, że lista funk­cjo­nal­no­ści to test roz­wią­za­nia (dostar­czo­ne­go opro­gra­mo­wa­nia) a nie wymagania!

Pytanie moje brzmi: A co to znaczy Jak”?

Czym jest owo jak”? Kodem pro­gra­mu, logi­ką na niskim pozio­mie, logi­ką na wyso­kim pozio­mie? Spójrzmy na taki pro­blem, wyma­ga­nie: klient wyma­ga by sys­tem pozwa­lał na wpro­wa­dza­nie tre­ści doku­men­tów, prze­ka­zy­wa­nie ich inne­mu pra­cow­ni­ko­wi wg. defi­nio­wa­nych reguł. Wiemy już co sys­tem ma robić. Tego typu sys­te­mów obie­gu doku­men­tów (tak się je czę­sto nazy­wa) są dzie­siąt­ki, róż­nią się od sie­bie nie­raz bar­dzo. Dlaczego?

Bo powyż­szy opis co” sys­tem ma robić to sta­now­czo za mało, tak na praw­dę nie defi­niu­je on nicze­go poza tym, w jaki spo­sób może zostać wyko­rzy­sty­wa­ny. Przypadek uży­cia jest dosłow­nie przy­pad­kiem uży­cia sys­te­mu”, ale przy­pad­ków uży­cia jest nie­skoń­cze­nie wie­le. Na ile spo­so­bów wyko­rzy­stu­je­cie posia­da­ne oprogramowanie?

Każdego dnia poja­wia się jakiś nowy pro­blem do roz­wią­za­nia i użyt­kow­nik pro­gra­mu będzie musiał się z nim zmie­rzyć. Skoro w toku ana­li­zy wska­za­no skoń­czo­ną licz­bę przy­pad­ków uży­cia, to czy daje to pra­wo by ktoś, np. pro­gra­mi­sta, nie zna­ją­cy ana­li­zo­wa­ne­go biz­ne­su, uzur­po­wał sobie pra­wo do pro­jek­to­wa­nia i kodo­wa­nia” tego Jak ten sys­tem będzie to robił? Do kodo­wa­nia na pew­no na pra­wo, ale czy do pro­jek­to­wa­nia tak­że? Czym jest tu to pro­jek­to­wa­nie i co jest pro­jek­to­wa­ne? Czym jest OOAD ([[Object Oriented Analysis and Design]], ang. ana­li­za i pro­jek­to­wa­nie obiektowe)?

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 ta meto­da i tak nie stwo­rzysz nawet dość dobrej symu­la­cji. 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.

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. Tak więc tra­dy­cyj­ne meto­dy, zapis wywia­dów, obser­wa­cje, ankie­ty, 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, któ­ra to część bo nie zna­my wszystkich).

Przypadki uży­cia 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 snookera.

Znacznie lep­szym wyj­ściem jest stwo­rze­nie mode­lu sto­łu i kul wraz z ich zacho­wa­niem się, reak­cja­mi na ude­rze­nia. Kto powi­nien to zro­bić? Ktoś kto dość dobrze gry­wa i rozu­mie sno­oke­ra, ale nie koniecz­nie mistrz tej gry, a tak­że zna­ją­cy jed­nak fizy­kę ciał sta­łych (tego raczej nie zna dobrze mistrz sno­oke­ra). Taki model to nie przy­pad­ki uży­cia (te są tyl­ko przy­kła­da­mi zasto­so­wa­nia) a model obiek­to­wy zawie­ra­ją­cy obiek­ty takie jak kula, kij itp.

Czy taki model stwo­rzy pro­gra­mi­sta na bazie roz­mów? Najczęściej nie! Co pro­gra­mi­sta zro­bi więc bar­dzo dobrze? Zapisze taki model w jakimś wybra­nym języ­ku pro­gra­mo­wa­nia ([[imple­men­ta­cja]]), zadba o to by moż­li­wa była gra setek użyt­kow­ni­ków, by moż­li­wa była 24 godzi­ny, sie­dem dni w tygo­dniu, wie­le, wie­le innych rze­czy ale nie model gry w snookera.

Co naj­waż­niej­sze: model taki nie może być żad­nym uprosz­cze­niem, gdyż ode­tnie to moż­li­wość jego roz­bu­do­wy (nowe wyma­ga­nia użyt­kow­ni­ka, a te poja­wią się na pew­no) w przyszłości.

Inny przy­kład. Jeżeli począt­ko­wo pro­jek­tu­je­my model pozwa­la­ją­cy kraw­co­wi pro­jek­to­wać i szyć spodnie, nie powin­ni­śmy pro­jek­to­wać zamknię­tej kon­struk­cji dwóch nóg, nale­ży stwo­rzyć model całe­go czło­wie­ka a w imple­men­ta­cji zawrzeć tyl­ko jego część od pasa w dół”. Będzie to pewien nad­miar ale jeże­li kie­dy­kol­wiek kra­wiec zechce posze­rzyć ofer­tę o mary­nar­ki do tych spodni, będzie to pro­ste roz­sze­rze­nie mode­lu a nie two­rze­nie go pra­wie od nowa. (tu kła­nia się DDD: ang. [[Domain Driven Design]] pole­ga­ją­cy na symu­lo­wa­niu w pro­jek­cie OOAD bytów świa­ta rzeczywistego).

Tak więc doku­ment wyma­gań to nie tyl­ko przy­pad­ki uży­cia. Te są raczej testem popraw­no­ści roz­wią­za­nia, czy model jest popraw­ny (przy­po­mi­nam, że przy­pad­ki uży­cia, poza ich sce­na­riu­sza­mi, zawie­ra­ją stan począt­ko­wy i stan koń­co­wy akcji użyt­kow­ni­ka). Dokument wyma­gań to model (tu [[model dzie­dzi­ny]]), któ­ry po zaim­ple­men­to­wa­niu, będzie się zacho­wy­wał tak jak tego ocze­ku­je­my a przy­pad­ki uży­cia będą jedy­nie dowo­dem na to, że jest on popraw­ny. O czym tu mowa?

iiba-modele-w-dokumencie-wymagan

Jeśli model przy­pad­ków uży­cia to model tak zwa­nej czar­nej skrzyn­ki, to model dzie­dzi­ny (bo tak się on nazy­wa) to tak zwa­na bia­ła skrzyn­ka. Tę bia­łą skrzyn­kę tak­że moż­na prze­te­sto­wać. Jak? Potraktować” ją przy­pad­ka­mi uży­cia (np. model kul i kija, kil­ka testo­wych ude­rzeń). Skoro mamy obiek­ty sys­te­mu (model, pro­jekt roz­wią­za­nia), któ­re reagu­ją na bodź­ce, to zna­czy, że moż­li­we jest poda­nie” sta­nu wej­ścio­we­go testo­wa­ne­go przy­pad­ku uży­cia mode­lu dzie­dzi­ny i spraw­dze­niu czy wytwo­rzy on ocze­ki­wa­ny stan koń­co­wy tegoż przypadku.

Model dziedziny to nie ten świat, o którym wielu myśli

Kolejna waż­na uwa­ga: w opro­gra­mo­wa­niu nie pro­jek­tu­je­my świa­ta rze­czy­wi­ste­go (no chy­ba, że to będzie gra), pro­jek­tu­je­my nasze narzę­dzia. Innymi sło­wy: w sys­te­mie nie mode­lu­je­my Dyrektora (on pozo­sta­nie żywy po wdro­że­niu), mode­lu­je­my kart­ki papie­ru na jakich zacho­wu­je­my o nim infor­ma­cję w real­nym świe­cie. Po co? By zamiast kar­tek użyć np. sys­te­mu kadro­wo-pła­co­we­go, by wyli­czył jego wyna­gro­dze­nie szyb­ciej i bez błę­dów. Zły model (przy­po­mi­nam, sys­tem biz­ne­so­wy to nie gra) zawie­ra kla­sę User, dobry model: UserInfo. Polecam książ­kę o meto­dy­ce ana­li­zy i mode­lo­wa­nia [[Toold&Materials design]].

Narzędzia pracy

Tu nie­ste­ty poja­wia się pew­na potrze­ba: narzę­dzie. Czym ono jest? Notacja obiek­to­wa UML. Po co to? Bo two­rze­nie i testo­wa­nie dia­gra­mów jest znacz­nie szyb­sze i tań­sze (zro­bi to ana­li­tyk pro­jek­tant) niż two­rze­nie wyko­ny­wal­ne­go kodu zdat­ne­go do testowania.

Dalej: opro­gra­mo­wa­nie CASE. Czy jaki­kol­wiek roz­sąd­ny foto­graf dzi­siaj pra­cu­je nad zdję­ciem cyfro­wym z pomo­cą pro­gra­mu PaintBrusz? Edytuje poszcze­gól­ne pik­se­le na pie­cho­tę”? Nie, korzy­sta­my z PhotoShopa, Gimpa, itp. Jak nazwać wiec ana­li­ty­ka, któ­ry mode­lu­je z pomo­cą takich narzę­dzi jak PowerPoint a nawet Visio? Są narzę­dzia, pakie­ty CASE, zwal­nia­ją­ce pro­jek­tan­ta z bene­dyk­tyń­skiej pra­cy nad dia­gra­ma­mi, może się sku­pić na tre­ści. Aha: UML to nie gene­ro­wa­nie pro­gra­mu, UML to ana­li­za i mode­lo­wa­nie, to narzę­dzie doku­men­to­wa­nia swo­ich pro­jek­tów. Dobry inży­nier uży­wa rysun­ku tech­nicz­ne­go, w inży­nie­rii opro­gra­mo­wa­nia jest to wła­sne UML. Jak ktoś uwa­ża, że UML jest bez sen­su sam cofa się o deka­dę w rozwoju.

Przykład

Na pew­nym forum poja­wi­ło sie takie zada­nie, weź­my sytu­ację biz­ne­so­wą (cytat):

Mamy por­tal dla klien­tów. Klientem jest fir­ma, któ­ra kupi­ła nasz pro­dukt. Każda fir­ma ma utwo­rzo­ne kil­ka kont użyt­kow­ni­ków. Na por­ta­lu pre­zen­to­wa­ne są nasze pro­duk­ty i jakieś dodat­ko­we eks­tra­sy dla nich.

Przypadek uży­cia:

Użytkownik [po zalo­go­wa­niu się] widzi tyl­ko takie pro­duk­ty, któ­re jego fir­ma kie­dyś zakupiła.

Dla porząd­ku dia­gram Przypadków Użycia:

Jak widać, wyma­ga­nie funk­cjo­nal­ne nie za wie­le mówi, na tej pod­sta­wie może powstać nie­skoń­cze­nie wie­le roz­wią­zań. Prosty sce­na­riusz: użyt­kow­nik żąda ofer­ty, sys­tem wyświe­tla ofer­tę skła­da­ją­ca się z wcze­śniej kupio­nych pro­duk­tów. To tak­że nie poma­ga, to test tego czy sys­tem zro­bi to co chce­my. Czego nam potrze­ba? Potrzebujemy mode­lu wnę­trza, któ­ry zasy­mu­lu­je sys­tem”, infor­ma­cje któ­re posia­da­my, i odpo­wie ocze­ki­wa­ną ofer­tą”. Taki model to wła­śnie model dziedziny:

To nasze kule do sno­oke­ra”. Ale czy to dobry model? Czy przy­kła­do­wy bodziec (żąda­nie ofer­ty) da ocze­ki­wa­ny rezul­tat? Sprawdźmy to na modelu:

Co tu mamy? To symu­la­cja tego co zro­bił­by (powi­nien) przy­szły goto­wy pro­gram. Testowanie i pro­jek­to­wa­nie to pro­ces ite­ra­cyj­ny: jeże­li powyż­szy model (dia­gram sekwen­cji UML) nie da ocze­ki­wa­ne­go rezul­ta­tu (stan koń­co­wy przy­pad­ku uży­cia) należ go popra­wić. Po co takie zaba­wy? Zwróćcie uwa­gę ile obiek­tów jest na mode­lu dzie­dzi­ny, czy jeste­śmy w sta­nie to sobie wyobra­zić ze szcze­gó­ła­mi w gło­wie? Takich obiek­tów w dużym sys­te­mie będą dzie­siąt­ki! Okazji do pomył­ki, bra­ku­ją­cy obiekt, bra­ku­ją­ca infor­ma­cja itp. jest wiele.

Po takich testach (wery­fi­ka­cja roz­wią­za­nia pole­ga na potrak­to­wa­nie” mode­lu dzie­dzi­ny wybra­ny­mi lub wszyst­ki­mi przy­pad­ka­mi uży­cia) uzu­peł­ni­my wszel­kie ewen­tu­al­ne bra­ki mode­lu. Po co? By tych bra­ków nie odkry­wać na eta­pie kodo­wa­nia, bo to jest nawet 100 razy kosztowniejsze!

Ważna infor­ma­cja: powyż­sze dia­gra­my to za mało. Wywołanie ope­ra­cji kla­sy, w więk­szo­ści przy­pad­ków, wyma­ga poda­nia para­me­trów, odpo­wiedź sta­no­wi np. obiekt lub ich kolek­cja albo np. plik XML (lub inny struk­tu­ral­ny). Struktury tych obiek­tów opi­sy­wa­ne są na odręb­nych dia­gra­mach. Tak więc początkowe

Użytkownik [po zalo­go­wa­niu się] widzi tyl­ko takie pro­duk­ty, któ­re jego fir­ma kie­dyś zakupiła.

poka­za­ne na powyż­szym dia­gra­mie sekwen­cji, pole­ga na tym, że GUI zażą­da od Logiki listę nazw pro­duk­tów sprze­da­nych fir­mie, do któ­rej jest przy­po­rząd­ko­wa­ny zalo­go­wa­ny użyt­kow­nik. Żądanie to, po spraw­dze­niu logi­ki praw dostę­pu itp., zosta­nie prze­ka­za­ne do repo­zy­to­rium Informacje, któ­re zwró­ci kolek­cję obiek­tów speł­nia­ją­cą powyż­szy waru­nek. Jedna waż­na rzecz: powyż­sze to nie przy­pa­dek uży­cia” a regu­ła biz­ne­so­wa: widzi tyl­ko takie pro­duk­ty, któ­re jego fir­ma kie­dyś zaku­pi­ła. Przypadkiem uży­cie jest raczej usłu­ga apli­ka­cji Zarządzanie histo­ria zakupów.

Mamy więc kon­cep­cje roz­wią­za­nia (tak zwa­ny model logicz­ny). Powyższe dia­gra­my są tu uprosz­czo­ne, wyma­ga­ły by na pew­no dopiesz­cze­nia ale ilu­stru­ją ideę obiek­to­wej ana­li­zy i pro­jek­to­wa­nia kon­cep­cji roz­wią­za­nia. Realne pro­jek­ty są oczy­wi­ście więk­sze ale nie zapo­mi­naj­my, że duże pro­jek­ty dzie­li się (powin­no) na mniej­sze (mikro­ser­wi­sy). Model dzie­dzi­ny dzie­li się na obsza­ry dzie­dzi­no­we, (modu­ły, pod­sys­te­my) by każ­dy z nich pozwa­lał na łatwe testo­wa­nie jak powy­żej. Po dru­gie doświad­czo­ny ana­li­tyk szyb­ko wychwy­ci, któ­re pod­sys­te­my moż­na kupić na ryn­ku (tak zwa­ne ang. COTS, Commercial of the Shelf), a któ­re nale­ży zapro­jek­to­wać do wyko­na­nia. Systemy zło­żo­ne pro­jek­tu­je się na pew­nym wyż­szym pozio­mie abs­trak­cji (meto­do­lo­gia top-down), ale sta­le jest to model i jego testo­wa­nie. Ale to tyl­ko (dla użyt­kow­ni­ka ) tak zwa­na logi­ka biznesowa.

Programiści!

Nikt Wam nie odbie­ra chle­ba, macie dużo pra­cy: po pierw­sze imple­men­ta­cja metod (algo­ryt­mów) poszcze­gól­nych obiek­tów (np. podaj nazwy pro­duk­tów, któ­re już raz kupio­no), macie zadbać o to: sys­tem ma być bez­piecz­ny, wydaj­ny, dzia­łać zdal­nie na tele­fo­nach komór­ko­wych, ma być bez­a­wa­ryj­ny itd. To wyma­ga­nia poza funk­cjo­nal­ne (lub w nie­któ­rych meto­dy­kach tak zwa­ne ogra­ni­cze­nia). Macie dzie­siąt­ki pro­ble­mów tech­nicz­nych do rozwiązania.

Ale pro­szę, nie uda­waj­cie, że zna­cie się na zarzą­dza­niu, mar­ke­tin­gu, biz­ne­sie, sprze­da­ży, ryn­ku, pro­duk­cji itp. bo to (poza pew­nie ist­nie­ją­cy­mi wyjąt­ka­mi) nie praw­da, a pro­jek­to­wa­nie na zasa­dzie wyda­je mi się że rozu­miem” to dro­ga do porażki.

Struktura wzorca MVC

Powyżej struk­tu­ra naj­czę­ściej uży­wa­ne­go, w meto­dach obiek­to­wych, wzor­ca pro­jek­to­we­go. Można uznać to za zało­że­nia pro­jek­to­we, tak wyglą­da każ­dy” sys­tem (uży­wa­ją­cych innych wzor­ców prze­pra­szam). Powyższy dia­gram pozwa­la jed­no­znacz­nie przy­po­rząd­ko­wać odpo­wie­dzial­ność za pro­jekt: ana­li­tyk pro­jek­tu­je war­stwę Model, pro­gra­mi­ści całą resz­tą. Przypadki uży­cia, per­spek­ty­wa obiek­tu User, tak­że znaj­dą się w doku­men­ta­cji wyma­gań. Co jesz­cze powin­na zawie­rać taka doku­men­ta­cja? Ewentualne ocze­ki­wa­nia użyt­kow­ni­ka do inter­fej­su użyt­kow­ni­ka (w koń­cu to zoba­czy, i tyl­ko to). wcze­śniej­sze dia­gra­my to model dzie­dzi­ny i jego testo­wa­nie. Daleki jestem od narzu­ca­nia wyko­naw­cy, w doku­men­cie wyma­gań, pozo­sta­łych ele­men­tów opro­gra­mo­wa­nia ale model biz­ne­so­wy to nie robo­ta dla programistów!

Taki pro­jekt jak powy­żej pozwa­la na dokład­ną wyce­nę, osza­co­wa­nie pra­co­chłon­no­ści. Mamy opis przed­mio­tu zamó­wie­nia”. Model dzie­dzi­ny opi­su­je kom­po­nent Model, wyma­ga­nia poza­func­kjo­nal­ne pozo­sta­łą resztę.

Proszę, nie wma­wiaj­cie swo­im klien­tem, że poza user sto­ry i przy­pad­ka­mi uży­cia nie ma innych metod opi­su wyma­gań, nie wma­wiaj­cie, że nie ma stan­dar­dów i że trze­ba pró­bo­wać” się sta­rać, bo to po pro­tu nie praw­da. To, że ktoś cze­goś nie widział (nawet przez lata swo­jej pra­cy) nie sta­no­wi żad­ne­go dowo­du na to, że to nie istnieje.

Tak więc spe­cy­fi­ka­cja wyma­gań funk­cjo­nal­nych bez takich testów i bez mode­lu dzie­dzi­ny tak na praw­dę o niczym nie mówi. Czym to gro­zi? Tym, że zama­wia­ją­cy naj­czę­ściej dosta­nie to co chce (potra­fi) dostar­czyć dostaw­ca a nie to cze­go potrzebuje.

Jak to wygląda dla systemów ERP?

Jeśli z ana­li­zy wyj­dzie, że np. 3/4 wyma­gań mie­ści się w moż­li­wo­ściach goto­wych ryn­ko­wych sys­te­mów (owe COTS) to się wybie­ra goto­wy ERP (wybra­ne modu­ły) speł­nia­ją­cy opi­sa­ne wyma­ga­nia (tyl­ko przy­pad­ki uży­cia i model klu­czo­wych obiek­tów biz­ne­so­wych takich jak np. fak­tu­ra VAT). I to jest wła­ści­wa kolej­ność. Co będzie jeśli zacznie­my od wybo­ru goto­we­go sys­te­mu? Chyba nie muszę już odpowiadać…

Systemy ERP to zło­żo­ne , wie­lo­mo­du­ło­we pro­duk­ty. Czy jest sens spe­cy­fi­ko­wa­nie skoń­czo­nej licz­by ocze­ki­wa­nych funk­cjo­nal­no­ści (przy­pad­ków uży­cia) by wybrać taki sys­tem? Będzie ich nawet kil­ka tysię­cy! Nie! Ani tego nie zwe­ry­fi­ku­je­my ani nie spraw­dzi­my pod­czas odbio­ru sys­te­mu (powo­dze­nia w takich testach odbio­ro­wych). Więc jak?

System ERP moż­na wybrać na bazie pro­jek­tu, tu tyl­ko na nie­co wyż­szym pozio­mie abs­trak­cji. Analiza fir­my tak­że pole­ga tu na opra­co­wa­niu mode­li pro­ce­sów. Jednak w tym wypad­ku ich celem jest stwo­rze­nie raczej mode­lu filo­zo­fii dzia­ła­nia” fir­my a nie pro­jek­to­wa­nie sys­te­mu od zera. Założenie: sys­tem na ryn­ku ist­nie­je, nale­ży go jedy­nie wybrać z pośród wie­lu ist­nie­ją­cych. Do tego potrzeb­ny jest model dzie­dzi­ny i kon­cep­cja archi­tek­tu­ry a nie set­ki wyma­gań funkcjonalnych.

Najpierw dostaw­ca sys­te­mu ERP i wyko­na­na przez nie­go ana­li­za przed wdro­że­nio­wa czy może jed­nak naj­pierw ana­li­za wyma­gań? Zadam to samo pyta­nie ina­czej, coś z Państwa podwór­ka: naj­pierw ana­li­za miesz­ka­nia i pomysł na meblo­wa­nie a potem jaz­da po skle­pach i szu­ka­nie mebli, czy może naj­pierw daje­my sobie sprze­dać meble a potem wci­ska­my je w nasze poko­je (plus osła­wio­na ich kasto­mi­za­cja)? Państwo sami musza pod­jąć decy­zję, ryzy­ka opi­sa­łem. Powiem tyl­ko tyle: war­to zmie­rzyć dobrze miesz­ka­nie, opra­co­wać pomysł, kupić na ryn­ku to co pasu­je, a pozo­sta­łe zaka­mar­ki zle­cić dobre­mu sto­la­rzo­wi, któ­ry wpa­su­je meble i ład­nie połą­czy je z już kupionymi. 

A skąd brać te przypadki użycia?

Najgorsza meto­da, bo nie pod­da­ją­ca się testo­wa­niu (wery­fi­ka­cji), to: wywia­dy, ankie­ty, warsz­ta­ty i podob­ne meto­dy dekla­ra­tyw­ne. Dostaniemy set­ki nie­spój­nych wyma­gań, nie raz będą­cych efek­tem wewnętrz­nych wewnętrz­nych nego­cja­cji, roz­gry­wek (tak, nie­ste­ty). Powstanie nie­we­ry­fi­ko­wal­na lista na set­ki pozy­cji. Jak inaczej?

Analizujemy fir­mę, two­rzy­my jej model pro­ce­so­wy jak na dia­gra­mie powy­żej. Model pro­ce­sów testu­je­my z pomo­cą real­nych doku­men­tów. Po takich testach, wybie­ra­my na tym mode­lu te czyn­no­ści, któ­re uzna­my za nasze wyma­ga­nia. Praktyka poka­zu­je, że jest ich tak na praw­dę dzie­siąt­ki a nie set­ki (są to logicz­ne czyn­no­ści z ewen­tu­al­ny­mi warian­ta­mi). Nie może­my się tu pomy­lić bo mamy prze­te­sto­wa­ny model pro­ce­so­wy fir­my. Jednak ten model tak­że (podob­nie jak mode­le UML) musi pod­le­gać testom i for­ma­li­za­cji (naj­le­piej zasto­so­wać for­mal­ną, pozwa­la­ją­ca na testo­wa­nie, nota­cję, np. BPMN – powyż­szy dia­gram). Bez tego, model pro­ce­sów nie będzie lep­szy od opi­su słow­ne­go. Ale o tym już było 🙂 (i pew­nie jesz­cze będzie).

(wię­cej o przej­ściu z pro­ce­sów na przy­pad­ki uży­cia: trans­for­ma­cja mode­lu pro­ce­sów na model przy­pad­ków uży­cia)

Zamawiających nie stać na takie analizy jak powyżej.

Czyżby? Taka ana­li­za to ok. 20% budże­tu prac pro­gra­mi­stycz­nych i 50% cza­su pro­jek­tu. Bez niej jed­nak pro­jekt pły­nie w user sto­ry, pro­to­ty­py, odkry­wa­nie wyma­gań w trak­cie pro­jek­tu, ite­ra­cje (Agile?), ter­min jest prze­su­wa­ny kolej­ny raz. Klient pła­ci. Badania wyka­zu­ją (i dekla­ru­ją to tak­że wyko­naw­cy, czy­taj poprzed­nie moje posty z cyta­ta­mi, gorą­co pole­cam blo­gi pro­gra­mi­stów i ich opi­nie o use­rach oraz ana­li­ty­kach i sprze­daw­cach ich firm!), że w kon­se­kwen­cji kosz­tu­je to 200% pla­nu pier­wot­ne­go (typo­wy narzut dostaw­ców opro­gra­mo­wa­nia, patrz dia­gram poni­żej, bywa że narzu­ca­ją nawet 500% na nie­wie­dzę i niezrozumienie) !!!!!!

Powyższa meto­da pozwa­la by pro­jekt miał to co powi­nien mieć: dobrze okre­ślo­ny zakres pro­jek­tu (opis przed­mio­tu zamó­wie­nia) a na jego pod­sta­wie dobrze osza­co­wa­ny budżet (ren­tow­ność!) i ter­min wykonania.

Nikt tego nie rozumie czyli kto i co czyta: adresaci dokumentów

Często innym, poza budże­tem, argu­men­tem prze­ciw­ko takim ana­li­zom jest zarzut: Klient nie rozu­mie mode­li ani dia­gra­mów więc po co je robić”. A kto powie­dział, że Klient ma je czy­tać! Klient jest przede wszyst­kim źró­dłem wie­dzy o wła­snej fir­mie, wery­fi­ku­je model pro­ce­sów z pomo­cą ana­li­ty­ka, usta­la zakres pro­jek­tu, spraw­dza i potwier­dza biz­ne­so­wy opis swo­jej fir­my i jej potrze­by. Potem zatwier­dza ewen­tu­al­ne pro­to­ty­py ekranów.

Ten zarzut nie­ste­ty czę­sto sta­wia­ją tak­że nie­kom­pe­tent­ni dostaw­cy, nie potra­fią­cy nic inne­go poza eks­pe­ry­men­ta­mi, pro­to­ty­pa­mi i zja­da­niem budże­tu Klienta: im wię­cej tym lepiej…

Modele pro­ce­sów to narzę­dzie ana­li­ty­ka, mode­le UML tak­że ale te czy­ta wyko­naw­ca (jak wyko­naw­ca nie potra­fi czy­tać UML to on ma pro­blem, a nie ana­li­tyk czy klient.!). To dokład­nie tak jak z miesz­ka­niem: pro­jek­tant wnętrz słu­cha klien­ta i poka­zu­je mu efekt pra­cy: wizu­ali­za­cję. Potem opra­co­wu­je doku­men­ta­cje tech­nicz­ną dla sto­la­rza, rysun­ki tech­nicz­ne, nazwy mate­ria­łów. Tego klient fak­tycz­nie raczej nie rozu­mie ale nie dla nie­go są te doku­men­ty. Jednak dobry sto­larz to twór­czy inży­nier, potra­fią­cy wyko­nać pro­jekt i nie wci­ska klien­to­wi, tań­szych mate­ria­łów, nie uprasz­cza fine­zyj­nych zwień­czeń sza­fy bo po pro­tu psuje.

Jak wie­my sto­la­rze są róż­ni dla­te­go coraz czę­ściej pro­jek­tan­ci wpi­su­ją do swo­ich umów tak zwa­ny nad­zór autor­ski nad reali­za­cją. Ja tak­że tak robię.

Dla zain­te­re­so­wa­nych nie­co wię­cej na ten temat na stro­nach MSDN:

http://​msdn​.micro​soft​.com/​e​n​-​u​s​/​l​i​b​r​a​r​y​/​d​d​4​0​9​3​7​6​.​a​spx

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. Piotr R.

    To co pisa­łem na GL, roz­wi­nę tu. Różne podej­ścia wytwa­rza­nia opro­gra­mo­wa­nia bio­rą udział w grze ryn­ko­wej. Rynek nie będzie cze­kał całych epok na odkry­cie naj­sku­tecz­niej­szych roz­wią­zań. To jest kwe­stia naj­bliż­szych 5. lat w cią­gu któ­rych oka­że się któ­ra meto­dy­ka jest naj­sku­tecz­niej­sza w danych oko­licz­no­ściach. Ja w każ­dym razie zamie­rzam się dalej roz­wi­jać w takim kie­run­ku aby być przy­go­to­wa­nym na moment gdy rynek odkry­je to co zosta­ło opi­sa­ne powyżej.

  2. Wojciech Soczyński

    @Piotr R. – mam wra­że­nie, że za naszą zachod­nią gra­ni­cą takie postę­po­wa­nie to stan­dard. Niestety w Polsce, poziom kul­tu­ry biz­ne­so­wej jest jesz­cze zbyt niski by ludzie odpo­wie­dzial­ni za decy­zję zarów­no ze stro­ny firm softwa­re­’o­wych jak i klien­tów zro­zu­mie­li, że to się opła­ca. W naszym kra­ju ludzie nie­ste­ty mają zbyt wąskie hory­zon­ty myślo­we i cza­so­we – nasta­wie­ni są na szyb­ki efekt. Strategią firm wytwa­rza­ją­cych opro­gra­mo­wa­nie jest to, by jak naj­szyb­ciej poka­zać coś” klien­to­wi, nie waż­ne czy to dzia­ła czy też nie. Byle ład­nie wyglą­da­ło i stwa­rza­ło pozo­ry a póź­niej w ramach umów ser­wi­so­wych uzu­peł­nia się szcze­gó­ły. Nie muszę mówić ile fru­stra­cji i ner­wów kosz­tu­je to obie stro­ny. Niestety ludzie nie chcą się uczyć na wła­snych błędach…

  3. olam.

    chęt­nie zoba­czy­ła­bym wszyst­kie rysun­ki, jest szan­sa popra­wić coś, zeby sie popraw­nie wyświetlały?

    1. Jaroslaw Zelinski

      Faktycznie coś poszło nie tak”… Artykuł napra­wio­ny i deli­kat­nie prze­re­da­go­wa­ny (po tych kil­ku latach musia­łem ;)). Wszelkie pyta­nia mile widziane..

  4. Aleksandra Młyńczyk

    fan­ta­stycz­nie, dzię­ku­ję uprzej­mie i bio­rę się jesz­cze raz do lektury ?

Dodaj komentarz

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