Ostatni arty­kuł o pro­ce­sie ana­li­zy i pro­jek­to­wa­nia koń­czył się tak:

Po wyko­na­niu powyż­sze­go, otrzy­ma­my kom­plet­ny model apli­ka­cji w nota­cji UML. Będzie to wła­śnie model PIM. Wszelkie nie­ja­sno­ści powin­ny zostać wyja­śnio­ne. Pozostaje reali­za­cja, model PSM, czy­li opa­ko­wa­nie pro­jek­tu ?tech­ni­ka­lia­mi? (w tym reali­za­cja wyma­gań poza­funk­cjo­na­lych) czy­li tym co dają nam np. fra­me­wor­ki MVC i podob­ne. Oczywiście nie jest to ?try­wial­ny pro­blem?, ale w takim pro­jek­cie deve­lo­per roz­wią­zu­je pro­ble­my jako­ści sys­te­mu a nie logi­ki biz­ne­so­wej sys­te­mu (podob­nie jak inży­nier budow­la­ny, któ­ry ma posta­wić moc­ny i bez­piecz­ny dom, bo jego funk­cjo­nal­ność to pro­blem miesz­kań­ca i zada­nie pro­jek­tan­ta archi­tek­ta). (UML Process czy­li od biz­ne­su do pro­jek­tu logi­ki sys­te­mu).

Często dosta­ję pyta­nia o ogól­ną, poglą­do­wą mapę takie­go pro­jek­tu by łatwo było oce­nić czym jest opi­sy­wa­ne śla­do­wa­nie, jaka jest kolej­ność pra­cy i jakie mode­le powsta­ją. Podjąłem pró­bę poka­za­nia tego:

Kolejność pra­cy (klik­nij by powiększyć):

1. Określenie celu biz­ne­so­we­go, powsta­je doku­ment wyja­śnia­ją­cy jakie ​„biz­ne­so­we” korzy­ści chce­my (orga­ni­za­cja) osią­gnąć, nie powin­no być celem samym w sobie kupie­nie cze­goś (np. sys­te­mu ERP), korzy­ści te powin­ny być wyra­żo­ne osta­tecz­nie w pie­nią­dzu (potrzeb­ne do ana­li­zy ren­tow­no­ści projektu).
2. Kolejny etap to opra­co­wa­nie mode­lu moty­wa­cji biz­ne­so­wej, będzie to mate­riał do wypra­co­wa­nia Wymagań Biznesowych. Model ten zawie­ra prze­ło­że­nie celu biz­ne­so­we­go na wyma­ga­ne dzia­ła­nia: tak­ty­kę i stra­te­gię jego osią­gnię­cia: raz jest to reor­ga­ni­za­cja a raz nowy sys­tem ERP. Tu poja­wia­ją się takie ele­men­ty jak ana­li­za SWOT czy oddzia­ły­wa­nia, ana­li­za wyko­ny­wal­no­ści i oce­ny wpły­wu oto­cze­nia na pro­jekt. Powstają Wymagania Biznesowe (źró­dłem są stra­te­gia i tak­ty­ka osią­ga­nia celu biz­ne­so­we­go).
3. Następnie kolej na opra­co­wa­nie mode­lu pro­ce­sów biz­ne­so­wych dla całej orga­ni­za­cji na pozio­mie opi­su­ją­cym klu­czo­we pro­duk­ty (doku­men­ty i fak­ty). Zaczyna powsta­wać słow­nik pojęć i reguł biznesowych.
4. Kolejny etap to dekom­po­no­wa­nie pro­ce­sów biz­ne­so­wych ​„odpo­wie­dzial­nych” (powią­za­nych) za reali­za­cje Wymagań Biznesowych, te pro­ce­sy dekom­po­nu­je­my (uszcze­gó­ło­wio­ne mode­le) do pozio­mu czyn­no­ści two­rzą­cych i zmie­nia­ją­cych doku­men­ty i fak­ty. Dodajemy kolej­ne ziden­ty­fi­ko­wa­ne poję­cia i regu­ły. Na tym eta­pie moż­li­wa jest opty­ma­li­za­cja procesów.
5. Jeżeli opty­ma­li­za­cja reali­zu­je wyma­ga­nia biz­ne­so­we pro­jekt się koń­czy. Jeżeli oka­zu­je się, że wyma­ga­nia biz­ne­so­we wyma­ga­ją np. tech­no­lo­gii IT, pro­jekt ma dal­szy ciąg.
6. Określenie wyma­gań na opro­gra­mo­wa­nie to wska­za­nie tych czyn­no­ści w pro­ce­sach, któ­rych wspar­cie tą tech­no­lo­gią pomo­że zre­ali­zo­wać wyma­ga­nia biz­ne­so­we. Po ana­li­zie powsta­je na jej pod­sta­wie lista ocze­ki­wa­nych usług opro­gra­mo­wa­nia, są to tak zwa­ne przy­pad­ki uży­cia sys­te­mu. Każdy przy­pa­dek uży­cia ma okre­ślo­ny stan począt­ko­wy, koń­co­wy (ewen­tu­al­nie doku­ment jaki ma powstać), cel biz­ne­so­wy (uza­sad­nie­nie) oraz akto­ra czy­li wska­za­nie użyt­kow­ni­ka (a kon­kret­nie roli jaką peł­ni w orga­ni­za­cji). Powstaje spe­cy­fi­ka­cja wyma­gań funk­cjo­nal­nych i poza-funk­cjo­nal­nych (jako­ścio­wych, np. takich jak wydaj­ność czy nie­za­wod­ność). Na tym eta­pie dys­po­nu­je­my spe­cy­fi­ka­cją pozwa­la­ją­cą na szu­ka­nie goto­we­go opro­gra­mo­wa­nia na ryn­ku ofe­ru­ją­ce­go tak opi­sa­ne funk­cjo­nal­no­ści. Elementem spe­cy­fi­ka­cji wyma­gań jest słow­nik pojęć i reguł biz­ne­so­wych. Można dołą­czyć mode­le procesów.
7. Jeżeli nie znaj­du­je­my pro­duk­tu speł­nia­ją­ce­go wszyst­kie wyma­ga­nia w 100%, decy­du­je­my, któ­re bra­ku­ją­ce wyma­ga­nia funk­cjo­nal­ne jeste­śmy goto­wi wytwo­rzyć spe­cjal­nie dla nas. Wymaga to utwo­rze­nia dla każ­dej takiej funk­cjo­nal­no­ści (przy­pad­ku uży­cia, PU) spe­cy­fi­ka­cji w posta­ci opi­su jej reali­za­cji. Jest to pro­jekt (doku­ment) zawie­ra­ją­cy tak zwa­ny model dzie­dzi­ny sys­te­mu czy­li obiek­ty biz­ne­so­we i logi­kę ich współ­dzia­ła­nia. Dla każ­de­go PU powsta­je dia­gram opi­su­ją­cy jak obiek­ty mode­lu dzie­dzi­ny ​„reali­zu­ją” (współ­dzia­ła­nie) każ­dy przy­pa­dek uży­cia (dia­gra­my sekwencji).

Projekt ma trzy klu­czo­we eta­py: audyt orga­ni­za­cji czy­li jej pozna­nie i opra­co­wa­nie mode­lu dzia­ła­nia. Kolejny to Specyfikowanie wyma­gań na opro­gra­mo­wa­nie. Ostatni etap ana­li­zy i pro­jek­to­wa­nia to opra­co­wa­nie mode­lu logi­ki jaką ma reali­zo­wać zama­wia­ne opro­gra­mo­wa­nie. Cała ta doku­men­ta­cja zawie­ra know-how orga­ni­za­cji war­ty ochrony.

Na dia­gra­mie poka­za­no tak zwa­ne ​„śla­do­wa­nie” czy­li kolej­ne wywo­dze­nie ele­men­tów mode­li z poprze­dza­ją­cych je ogól­niej­szych eta­pów ana­li­zy. Taka doku­men­ta­cja pozwa­la unik­nąć kosz­tow­ne­go odkry­wa­nia potrzeb­nych funk­cjo­nal­no­ści pod­czas dostar­cza­nia kolej­nych wer­sji opro­gra­mo­wa­nia i prze­pro­jek­to­wy­wa­nia go. Specyfikacja logi­ki sys­te­mu pozwa­la dokład­nie spre­cy­zo­wać jakie opro­gra­mo­wa­nie jest zama­wia­ne (co ma ono reali­zo­wać i jak). Całość to opis know-how, któ­ry nadal zosta­je przy zama­wia­ją­cym (jest posia­da­czem praw do tej doku­men­ta­cji bo wyko­nał ja sam lub zle­cił nie­za­leż­ne­mu ana­li­ty­ko­wi a nie dostaw­cy oprogramowania).

Skąd się bio­rą problemy

Przytłaczająca więk­szość pro­jek­tów to roz­po­czę­cie pra­cy od pró­by zebra­nia wyma­gam funk­cjo­nal­nych z pomi­nię­ciem całej ana­li­zy biz­ne­so­wej. Jedynym więc ich źró­dłem są przy­szli użyt­kow­ni­cy, Ci jed­nak po pierw­sze nie mają wie­dzy o kon­tek­ście zaś ich cele są inne niż spon­so­ra pro­jek­tu. Nie mamy żad­ne­go narzę­dzia pozwa­la­ją­ce­go spraw­dzić zasad­ność każ­de­go z tak zebra­nych wyma­gań ani tego czy są ​„spój­ne i kom­plet­ne”. W efek­cie nie­spój­no­ści i bra­ku­ją­ce wyma­ga­nia odkry­wa­ny dopie­ro w trak­cie projektu.

Metody zwa­ne zwin­ny­mi idą jesz­cze dalej: pra­ce dewe­lo­per­skie są roz­po­czy­na­ne są zanim powsta­nie kom­plet­na spe­cy­fi­ka­cja, poja­wia­ją­ce się wyma­ga­nia są natych­miast, z pomi­nię­ciem ich mode­lo­wa­nia i wery­fi­ka­cji pomy­słu, imple­men­to­wa­ne (kod to pierw­szy model i wery­fi­ka­cja). Ryzyko, że nowe, odkry­wa­ne w trak­cie tego pro­ce­su, wyma­ga­nia i meto­dy ich imple­men­ta­cji będą nie­spój­ne czy wręcz sprzecz­ne jest ogrom­ne co poka­zu­je prak­ty­ka: meto­dy zwin­ne dają pro­duk­ty nie raz po bar­dzo wie­lu ite­ra­cjach i naj­czę­ściej są kon­trak­to­wa­ne umo­wa­mi ​„czas i mate­riał”, bo w zasa­dzie ina­czej się tym wypad­ku nie da. Deklarowanie ter­mi­nów i budże­tu wyma­ga­ło by ogrom­nych narzu­tów na nie­wie­dzę w momen­cie roz­po­czy­na­nia pra­cy (co jest tak­że powszech­na praktyką).

Na zakoń­cze­nie

Opisany pro­ces jest zgod­ny z zale­ce­nia­mi OMG​.org (https://​www​.omg​.org/​mda). Audyt to etap CIM (stan­dar­do­wo [[nota­cja BPMN]], sys­tem pojęć i [[nota­cja BMM]], hie­rar­chia struk­tu­ry orga­ni­za­cyj­nej, słow­nik reguł i pojęć) a pro­jek­to­wa­nie przy­pad­ków uży­ci i mode­lu dzie­dzi­ny to etap PIM (Platform Independent Model, [[nota­cja UML]]).

Wykonanie takiej ana­li­zy jest pra­co­chłon­ne i wyma­ga duże­go doświad­cze­nia, umie­jęt­no­ści ana­li­zy pro­ce­sów biz­ne­so­wych, pro­jek­to­wa­nia obiek­to­we­go i dobre­go narzę­dzia CASE, jed­nak mode­le te pozwa­la­ją tak­że prze­pro­wa­dzić ana­li­zy wpły­wu (zależ­no­ści pomię­dzy pro­ce­sa­mi, skut­ki i podat­ność na awa­rie opro­gra­mo­wa­nia itp.) oraz zre­du­ko­wać do mini­mum praw­do­po­do­bień­stwo prze­kro­cze­nia ter­mi­nu i kosz­tów (sta­ty­sty­ki wska­zu­ją na śred­nie prze­kro­cze­nie kosz­tów o 60% i ter­mi­nów o 200% pro­jek­tów z niskiej jako­ści spe­cy­fi­ka­cji wymagań).

Praktyka auto­ra wska­zu­je, że war­to taką ana­li­zę prze­pro­wa­dzić dla pro­jek­tów, któ­rych budżet prze­kra­cza 50 – 70 tys, zł i więk­szych, jej koszt jest zawsze znacz­nie niż­szy niż ryzy­ko­wa­ne 60% budże­tu. Paradoksalnie, w tych więk­szych pro­jek­tach, zbie­ra­nie wyma­gań i zarzą­dza­nie nimi meto­da­mi warsz­ta­tów i ankiet wyma­ga zaan­ga­żo­wa­nia wie­lu pra­cow­ni­ków po stro­nie zarów­no klien­ta jak i dostaw­cy (np. [[sesje JAD]]), z regu­ły jest to więk­szy koszt niż jeden ana­li­tyk z opi­sa­ny­mi kom­pe­ten­cja­mi i narzę­dzia­mi pra­cy, a otrzy­ma­ny pro­dukt – spe­cy­fi­ka­cja wyma­gań – niż­szej jako­ści (pro­ble­my spój­no­ści i kompletności).

(autor uży­wa pakie­tu CASE ana­li­tycz­no-pro­jek­to­we­go fir­my Visual Paradigm)