Produkty w procesie analizy wymagań

W arty­ku­le Inżynieria wyma­gań mię­dzy inny­mi opu­bli­ko­wa­łem tak­so­no­mię wyma­gań, jej roz­wi­nię­ta postać:

taksonomia wymagań

Temat wyma­gań regu­lar­nie wypły­wa na forach dys­ku­syj­nych i na kon­fe­ren­cjach. Ostatnio w podob­nej for­mie poja­wił się na pew­nym forum ser­wi­su LinkedIn i na dzi­siej­szej kon­fe­ren­cji. Na forum padło pyta­nie: co wybrać jako doku­men­ta­cje wyma­gań: SRS czy Use Case (odpo­wied­nio [[Software Requirements Specification]] czy­li [[spe­cy­fi­ka­cja wyma­gań na opro­gra­mo­wa­nie]] i Przypadki Użycia opro­gra­mo­wa­nia). Na dzi­siej­szej kon­fe­ren­cji zaś praw­nik, pod­czas swo­je­go refe­ra­tu, zwró­cił uwa­gę na fakt, że od stro­ny umów, pro­jek­ty – od ana­li­zy przed­wdro­że­nio­wej do dostar­cze­nia zamó­wio­ne­go opro­gra­mo­wa­nia – nale­ży dzie­lić pro­jekt na fazy będą­ce, zależ­nie od celu, umo­wą efek­tu (umo­wa o dzie­ło) i umo­wą sta­ran­ne­go dzia­ła­nia (umo­wa zlecenia).

Problem w tym, że SRS – czę­sto rozu­mia­ne jako doku­ment o struk­tu­rze opi­sa­nej w [[reko­men­da­cji IEEE830]], zawie­ra w pew­nej for­mie przy­pad­ki uży­cia (ale nie ich sce­na­riu­sze) rozu­mia­ne jako opis funk­cjo­nal­no­ści. Do tego reko­men­da­cja ta nie jest stan­dar­dem zawar­to­ści doku­men­tu a rekomendacją. 

SRS_IEEE830-1998Topics

Pojęcie przy­pad­ku uży­cia ma co naj­mniej dwie zupeł­nie róż­ne defi­ni­cje: jed­ną rodem z książ­ki Alistair’a Cockbourna Jak pisać efek­tyw­ne przy­pad­ki uży­cia”, dru­ga w spe­cy­fi­ka­cji nota­cji UML. Osobiście pre­fe­ru­ję te dru­gą i tyl­ko o nie będzie tu mowa (Cockbourn zresz­tą jaw­nie wyra­ża nie­chęć do UML w swo­jej książce).

Dla upo­rząd­ko­wa­nia dal­szej tre­ści przyj­mu­ję, że poję­cie przy­pa­dek uży­cia opro­gra­mo­wa­nia i funk­cjo­nal­ność opro­gra­mo­wa­nia są toż­sa­me (a kon­kret­nie przy­pa­dek uży­cia opi­su­je spo­sób reali­za­cji funk­cjo­nal­no­ści): obie okre­śla­ją to jaki efekt chce osią­gnąć (do cze­go użyć), w kon­kret­nym przy­pad­ku, użyt­kow­nik opro­gra­mo­wa­nia (kon­kret­na funk­cja jaką peł­ni opro­gra­mo­wa­nie, to jego moż­li­wy przy­pa­dek użycia).

Popatrzmy na eta­py pro­jek­tu, któ­re wyróż­nio­no na bazie tego, jakiej wie­dzy potrze­bu­je­my na każ­dym z tych eta­pów, by zapla­no­wać kolejny.

Etapy projektu

Jako pierw­sze powsta­ją wyma­ga­nia biz­ne­so­we opra­co­wa­ne na bazie oce­ny sytu­acji biz­ne­so­wej. Są one albo wła­snym pro­duk­tem Zamawiającego albo pro­duk­tem zatrud­nio­ne­go do tego celu eks­per­ta. Na bazie wyma­gań biz­ne­so­wych (celów biz­ne­so­wych) wyko­nu­je się ana­li­zę wyko­ny­wal­no­ści tych celów, powsta­je pomysł roz­wią­za­nia pro­ble­mu (osią­gnię­cia celu) w posta­ci wyma­gań wobec reko­men­do­wa­ne­go roz­wią­za­nia. Jeżeli ist­nie­je (zna­le­zio­no) na ryn­ku roz­wią­za­nie (pro­dukt lub stan­dar­do­wą usłu­gę) zosta­je ono zaku­pio­ne i wdro­żo­ne. Jeżeli nie (doty­czy nie tyl­ko cało­ści ale i czę­ści wyma­gań) nale­ży roz­wią­za­nie naj­pierw zapro­jek­to­wać a potem dopie­ro zle­cić wyko­na­nie i wdro­że­nie (a wcze­śniej na bazie pro­jek­tu wycenić).

Każdy z tych pro­duk­tów to przed­miot osob­nej umo­wy (lub jej eta­pu). Zależnie od stop­nia nie­wie­dzy” po stro­nie Zamawiającego, może to być umo­wa o dzie­ło lub zle­ce­nia. Jednak zale­ca się (praw­ni­cy zale­ca­ją) by, zawsze tam gdzie anga­żo­wa­ny jest eks­pert (usłu­go­daw­ca) zewnętrz­ny, sto­so­wać umo­wy o dzie­ło (umo­wa efek­tu), gdyż pozwa­la to pano­wać i nad cza­sem i nad budże­tem pro­jek­tu oraz w przy­pad­ku spo­ru sądo­we­go, moż­li­we było okre­śle­nie przed­mio­tu spo­ru (opis tego co mia­ło zostać wytwo­rzo­ne – dzieło).

Do zawar­cia umo­wy o dzie­ło koniecz­ny jest opis tego co ma powstać (opis dzie­ła). Patrząc od koń­ca: zawie­ra­jąc umo­wę z dostaw­cą opro­gra­mo­wa­nia mamy wyma­ga­nia wobec pro­duk­tu goto­we­go (w momen­cie zaku­pu speł­nia je lub nie) lub wyko­na­ny pro­jekt tego co ma powstać. Aby powstał pro­jekt musi­my mieć okre­ślo­ne wyma­ga­nia wobec roz­wią­za­nia i wyma­ga­nia (cele) biz­ne­so­we. Najtrudniej jest wyce­nić etap ana­li­zy sytu­acji biz­ne­so­wej bo tu w zasa­dzie nie wie­my jaka ta sytu­acja jest. Wymagania biz­ne­so­we, by powsta­ły, wyma­ga­ją pozy­ska­nia wie­dzy o tym jak funk­cjo­nu­je orga­ni­za­cja Zamawiającego i jakie zmia­ny pla­nu­je. To etap ana­li­zy biz­ne­so­wej (model moty­wa­cji biz­ne­so­wej i mode­le pro­ce­sów biz­ne­so­wych). W tym wypad­ku będzie to raczej umo­wa sta­ran­ne­go dzia­ła­nia z eks­per­tem, któ­ry tę ana­li­zę (i mode­le) wykona.

Pewnym roz­wią­za­niem pro­ble­mu ryzy­ka umo­wy czas i mate­riał” (nie wie­my kie­dy i jakim kosz­tem powsta­nie ocze­ki­wa­ny pro­dukt), jest okre­śle­nie tego jaki kon­kret­nie pro­dukt ma powstać (opis tego, jak stwier­dzi­my, że pra­ce wyko­na­no popraw­nie) i okre­śle­nia cza­su jaki sobie na to daje­my. Wymaga to pew­nej inwe­sty­cji, poświę­ce­nia cza­su na to, ale opła­ci się bo moc­no obni­ża­my ryzy­ko projektu.

Konkluzja praw­ni­ka, by zawie­rać umo­wy o dzie­ło jeże­li tyl­ko jest to moż­li­we, jest moim zda­niem słusz­na. Tam gdzie nie mamy wystar­cza­ją­cej wie­dzy by zawie­rać takie umo­wy, war­to zain­we­sto­wać czas by okre­ślić jed­nak przed­miot umo­wy, gdyż umo­wa zle­ce­nia z eks­per­tem (dostaw­cą opro­gra­mo­wa­nia) powo­du­je, że Zamawiający kom­plet­nie nie panu­je nad umo­wą: nie wie jakie­go pro­duk­tu ocze­ki­wać, satys­fak­cja z wyko­na­nej pra­cy może nadejść w trud­nym do prze­wi­dze­nia czasie.

Druga uwa­ga: jeże­li cały pro­ces, od pierw­szej ana­li­zy do dostar­cze­nia pro­duk­tu, reali­zu­je jed­na fir­ma, mamy do czy­nie­nia z sytu­acją, w któ­rej dostaw­ca sam kon­tro­lu­je sta­wia­ne mu wyma­ga­nia bo sam sobie defi­niu­je to co ma następ­nie wytwo­rzyć. Taki brak kon­tro­li rodzi poważ­ne ryzy­ko nierzetelności.

Projekt wykonany – co było robione

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 (http://​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 Agilian fir­my Visual Paradigm)