W bar­dzo cie­ka­wym arty­ku­le o iden­ty­fi­ko­wa­niu ​„udzia­łow­ców” pro­jek­tu (pole­cam: How to Effectively Engage Requirement Contributors to Achieve Project Success) autor opi­sał isto­tę ana­li­zy wpły­wu oto­cze­nia (pod­mio­ty zewnętrz­ne) i udzia­łow­ców na pro­jekt two­rze­nia (dostar­cze­nia) opro­gra­mo­wa­nia, bar­dzo waż­ne­go eta­pu ana­li­zy biznesowej.

Osobiście jestem gorą­cym zwo­len­ni­kiem trak­to­wa­nia opro­gra­mo­wa­nia jako zesta­wu narzę­dzi pra­cy i środ­ków do jej wyko­ny­wa­nia (ang. meta­fo­ra tools&materials czy­li opro­gra­mo­wa­nie to narzę­dzia i mate­ria­ły). Wtedy łatwiej ​„umie­ścić” sobie wyobra­że­nie powsta­ją­ce­go opro­gra­mo­wa­nia w naszym oto­cze­niu. To pocią­ga za sobą potrze­bę zro­zu­mie­nia tego ​„oto­cze­nia” i jego wpły­wu na nasz pro­jekt. Tu poja­wia się drob­ny ​„niu­ans”. Analiza sys­te­mo­wa wyma­ga jed­no­znacz­ne­go okre­śla­ne gra­ni­cy Systemu i okre­śle­nia czym on jest. W swo­ich pro­jek­tach defi­niu­ję to tak:

System to opro­gra­mo­wa­nie, któ­re powsta­nie oraz pro­jekt, któ­re­go jest on pro­duk­tem. Dzięki takiej defi­ni­cji wiem, że jeże­li coś ma wpływ na pro­jekt two­rze­nia opro­gra­mo­wa­nia to ma tak­że wpływ na samo opro­gra­mo­wa­nie, jeże­li coś ma wpływ na powsta­ją­ce opro­gra­mo­wa­nie to ma tak­że wpływ na zarzą­dza­nie pro­jek­tem jego wytworzenia.

Dlatego na eta­pie ana­li­zy wpły­wów oto­cze­nia, utoż­sa­miam pro­jekt z jego pro­duk­tem. Analiza wpły­wu oto­cze­nia na pro­jekt ma na celu (źr. wspo­mnia­ny artykuł):

1. Identyfikację insty­tu­cji regu­lu­ją­cych (ogra­ni­cza­ją­cych) dzia­ła­nie pod­mio­tu dla któ­re­go powsta­je narzę­dzie, to ogra­ni­cze­nie prze­no­si się na System bo musi on być zgod­ny z tymi ograniczeniami,
2. Identyfikację tego, kto w oto­cze­niu dostar­cza a kto kon­su­mu­je dane (wyma­ga­ne i prze­twa­rza­ne przez System oraz wytworzone),
3. Identyfikację wszyst­kich interfejsów

Moim zda­niem pod­mio­ty iden­ty­fi­ko­wa­ne w punk­tach punk­tach 2 i 3 moż­na potrak­to­wać łącz­nie, gdyż inter­fejs jest narzę­dziem wymia­ny danych, więc iden­ty­fi­ka­cja daw­cy lub bior­cy danych impli­ku­je posta­wie­nia wyma­ga­nia na inter­fejs. Warto jedy­nie zazna­czyć czy w danym wypad­ku cho­dzi o czło­wie­ka czy o inny sys­tem, jed­nak z per­spek­ty­wy ana­liz sys­te­mo­wej obaj są Aktorami Systemu. Rozróżnienie to jed­nak ma kon­se­kwen­cje w posta­ci budo­wy typu inter­fej­su: gra­ficz­ny użyt­kow­ni­ka czy komu­ni­ka­cyj­ny (sys­tem – system).

Modelowanie zależ­no­ści pomię­dzy udziałowcami

Autor arty­ku­łu słusz­nie zauwa­ża, że etap ana­li­zy udzia­łow­ców pro­jek­tu jest bar­dzo waż­ny, wska­zu­je na klu­czo­we korzy­ści pły­ną­ce z tej fazy ana­li­zy, są to:

1. zro­zu­mie­nie skut­ków wpro­wa­dza­nych zmian oraz wpły­wu na zakres pro­jek­tu i jego miary,
2. mini­ma­li­zo­wa­nie ryzy­ka powsta­nia złej spe­cy­fi­ka­cji wyma­gań (roz­mi­ja­nie się z praw­dzi­wy­mi potrzebami),
3. jasne i zro­zu­mia­łe prze­ka­za­nie ocze­ki­wań oraz ról w pro­jek­cie, każ­de­go ​„zain­te­re­so­wa­ne­go” a nale­żą do nich spon­so­rzy pro­jek­tu i przy­szli użyt­kow­ni­cy powsta­ją­ce­go systemu.

W począt­ko­wej fazie pro­jek­tu bar­dzo waż­ne jest to ostat­nie, gdyż pomył­ka tu potra­fi zni­we­czyć wszyst­kie pozo­sta­łe wysiłki.

Tu jed­nak poja­wia się pro­blem w tre­ści arty­ku­łu. Użyto w nim pew­nych mode­li (dia­gra­mów) ​„nie­co” nagię­tych seman­tycz­nie. Pojęcia (uży­te dia­gra­my i ich ele­men­ty) są nie­co prze­mie­sza­ne i nie zacho­wu­ją spój­no­ści zna­czeń uży­tych sym­bo­li. Czy to aż takie złe? Niestety tak. Dlaczego? Notacja UML (jak każ­da) to pewien sys­tem poję­cio­wy: zestaw pojęć i ich defi­ni­cji. Łamanie ich, ten sam sym­bol uży­wa­ny do wyra­że­nia róż­nych pojęć, pro­wa­dzi do utra­ty jed­no­znacz­no­ści mode­li i nieporozumień.

Diagramy auto­ra artykułu:

udzia­łow­cy:

Autor powyż­szych dia­gra­mów (i wymie­nio­ne­go we wstę­pie arty­ku­łu) nazwał pierw­szy ​„Diagram prze­pły­wu danych (ang. DFD, Data Flow Diagram) pozio­mu zero” a dru­gi, dia­gra­mem zależ­no­ści udzia­łow­ców pro­jek­tu. Formalnie DFD nie zawie­ra poję­cia aktor, powyż­sze to dia­gram aktyw­no­ści UML (popraw­ny). W UML akto­rem jest każ­dy zewnętrz­ny byt, będą­cy bene­fi­cjen­tem usłu­gi świad­czo­nej przez System. Pojęcia «External Entity» w nota­cji DFD ozna­cza ​„zewnętrz­ne obiek­ty” (źró­dła danych lub ich cel), w UML nie ma ono odpo­wied­ni­ka jako odręb­ne poję­cie (UML i para­dyg­mat obiek­to­wy nie ope­ru­ję poję­ciem danych).

Ogólnie w UML strzał­ki prze­ry­wa­ne mają zna­cze­nie ​„Zależy od” (jest bior­cą usłu­gi) i jako takie mają tu zły kie­ru­nek, gdyż sym­bol zależ­no­ści w UML to wska­za­nie na obiekt, od któ­re­go coś jest uza­leż­nio­ne, lub z usług cze­go korzy­sta. Tu strzał­ki obra­zu­ją coś, co autor nazwał ​„kie­ru­nek prze­pły­wu”, co jest nie­po­praw­ne bo ta ​„strzał­ka” w UML nie ozna­cza prze­pły­wu. Tak więc powy­żej Pilot nie zale­ży od Lotu a jest raczej odwrot­nie. Umieszczenie takie­go dia­gra­mu w doku­men­ta­cji zawie­ra­ją­cej inne dia­gra­my UML pra­wie na pew­no dopro­wa­dzi do nie­po­ro­zu­mień (dia­gram zosta­nie źle zin­ter­pre­to­wa­ny). Jeżeli Załoga (CabinCrew) świad­czy usłu­gi Pasażerowi, to strzał­ka powin­na mieć kie­ru­nek prze­ciw­ny (Pasażer korzy­sta, jest zależ­ny, z usług Załogi). Jeżeli inten­cją było zobra­zo­wa­nie prze­pły­wu nale­ża­ło utwo­rzyć inny dia­gram, tym bar­dziej, że powyż­szy dia­gram nie poka­zu­je, co tak na praw­dę prze­pły­wa od Załogi do Pasażera (?). Jednak zacho­wu­jąc seman­ty­kę UML, dia­gram taki moż­na utworzyć. 

Jak to powin­no wyglą­dać poprawnie?

UML i diagramy przypadków użycia jako model udziałowców

Pomijając samą nazwę (przy­pad­ki uży­cia), dia­gra­my te pozwa­la­ją na mode­lo­wa­nie pojęć takich jak:

1. System, czy­li byt (jakieś np. opro­gra­mo­wa­nie) świad­czą­cy jakieś usłu­gi (cechu­ją­cy się jaki­miś funkcjonalnościami),
2. Aktor czy­li zewnętrz­ny wzglę­dem sys­te­mu byt, mają­cy bez­po­śred­nią lub pośred­nią inte­rak­cję z systemem,
3. Zależność, czy­li wska­za­nie pary obiek­tów będą­cych w rela­cji ​„klient-usłu­go­daw­ca”, klient jest uza­leż­nio­ny od usługodawcy,
4. Realizacja czy­li wska­za­nie pary obiek­tów, gdzie jeden (imple­men­ta­cja) jest fizycz­ną reali­za­cją dru­gie­go (ide­ali­za­cja, model).

Dla roz­róż­nie­nia akto­rów na oso­by (fizycz­ne) i inne sys­te­my moż­na użyć ste­reo­ty­pów. Na dia­gra­mie wyglą­da to tak (zmie­ni­łem kon­tekst na wła­sny przykład):

System kon­kret­ny to jakieś ist­nie­ją­ce opro­gra­mo­wa­nie wyma­ga­ją­ce inte­gra­cji. Inny sys­tem to zgod­na z UML abs­trak­cja Aktora Projektowanego Systemu (System kon­kret­ny jest jego Realizacją). Aktorzy mogą zale­żeć od sie­bie a tak­że od Projektowanego Systemu. Projektowany System może zale­żeć od Aktora. Jak to wyglą­da ​„real­nie” czy­li na kon­kret­nym przykładzie?

Powyższy dia­gram, w peł­ni zgod­ny z UML, ma nastę­pu­ją­ce zalety:

1. Użyte poję­cia są god­ne ze stan­dar­dem a więc nie pro­wa­dzą do nie­jed­no­znacz­no­ści w inter­pre­ta­cji modeli,
2. Narzędzia typu CASE bez pro­ble­mu pozwo­lą nary­so­wać powyż­sze, a ele­men­ty tego dia­gra­mu mogą posłu­żyć zgod­nie z UML, jako kla­sy­fi­ka­to­ry dal­szych, pod­le­głych (zależ­nych), ele­men­tów mode­lu (obiek­tów i innych diagramów),
3. Model popraw­nie odwzo­ro­wu­je mode­lo­wa­ne ele­men­ty bez zapo­ży­cza­nia zna­czeń z innych, nie­obiek­to­wych, nota­cji i bez łama­nia zasad UML a więc model jest jed­no­znacz­ny i weryfikowalny.

Wydaje mi się, że powyż­szy dia­gram nie wyma­ga komen­ta­rza. Diagramy takie sto­su­ję jako ele­ment doku­men­ta­cji biz­ne­so­wej, przed­sta­wia­nej spon­so­ro­wi pro­jek­tu do zatwier­dze­nia. Są one czy­tel­ne, nazy­wa się je tak­że ana­li­zą ​„inte­re­sa­riu­szy” (ja sta­ram się uni­kać tego dziw­ne­go tłu­ma­cze­nia sło­wa sta­ke­hol­ders).

Stosowanie reguł (seman­ty­ki i syn­tak­ty­ki) UML pozwa­la utrzy­mać spój­ność mode­li zależ­nych (pod­le­głe temu dia­gra­mo­wi uszcze­gó­ło­wie­nia Projektu Systemu, reali­za­cja Aktorów, przy­pad­ki uży­cia itp.) oraz zacho­wać spój­ność logicz­ną i poję­cio­wą całej doku­men­ta­cji. To zaś jest warun­kiem wery­fi­ka­cji popraw­no­ści całe­go projektu.

UML to nota­cja, któ­rej klu­czo­wym poję­ciem jest kla­sy­fi­ka­tor (opar­ta jest na defi­nio­wa­nych poję­ciach i rela­cjach mię­dzy nimi) dla­te­go war­to prze­strze­gać (zawsze war­to) zasad nota­cji i np. nie utoż­sa­miać Aktora System CRM (jest to jakaś abs­trak­cja sys­te­mu inte­gro­wa­ne­go) z kon­kret­nym Jakimś Systemem CRM. Aktor ma kon­kret­ne zna­cze­nie na dia­gra­mie UML (zde­fi­nio­wa­ne wyżej) i kon­kret­ny sys­tem tak­że. Zachowanie tego podzia­łu (abs­trak­cja i jej reali­za­cja) pozwa­la zde­fi­nio­wać oddziel­nie wyma­ga­nia i oddziel­nie kon­kret­ne roz­wią­za­nia je speł­nia­ją­ce, co jest isto­tą roz­dzia­łu wyma­gań od speł­nia­ją­cych je roz­wią­zań (a tak­że meto­dy­ki MDA roz­dzie­la­ją­cej pro­jekt od jego implementacji).

Diagramy przy­pad­ków uży­cia są bar­dzo waż­ny­mi dia­gra­ma­mi, gdyż sta­no­wią ​„korzeń” mode­lu reali­za­cji sys­te­mu zaś łama­nie zasad nota­cji już na począt­ku pro­jek­tu pro­wa­dzi prak­tycz­nie zawsze do utra­ty moż­li­wo­ści ich, mode­li, weryfikacji.

Udziałowcy projektu

Uzupełnieniem mode­lu wpły­wu udzia­łow­ców pro­jek­tu jest ich spe­cy­fi­ka­cja. Tu wypa­da tyl­ko przy­tak­nąć auto­ro­wi arty­ku­łu, zale­ca on by każ­de­go akto­ra opi­sać atrybutami:

1. opis,
2. dane kon­tak­to­we,
3. ocze­ki­wa­nia (akto­ra wzglę­dem systemu),
4. w jakiej dzie­dzi­nie jest spe­cja­li­stą (eks­pert dziedzinowy),
5. wpły­wy w orga­ni­za­cji (for­mal­ne i nieformalne),
6. cele.

Osobiście jestem zwo­len­ni­kiem cał­ko­wi­tej jaw­no­ści komu­ni­ka­cji w pro­jek­tach dla­te­go nie sto­su­ję poję­cia ​„nie­for­mal­ne­go wpły­wu” w pro­jek­tach. To pozwa­la mi z jed­nej stro­ny upro­ścić zarzą­dza­nie doku­men­ta­cja pro­jek­to­wą (mam jed­ną wer­sję dostęp­ną dla Zamawiającego i Wykonawcy) a dru­giej nie nara­żam innych na ryzy­ko przy­pad­ko­we­go ​„odkry­cia” infor­ma­cji nie­for­mal­nych, mogą­cych być dla jed­nej ze stron pro­jek­tu powo­dem ​„emo­cji”.

Analiza RACI

W przy­pad­ku udzia­łow­ców pro­jek­tu dobrą prak­ty­ką jest budo­wa pro­stej macie­rzy RACI (klik­nij po opis tego narzę­dzia). Co do zasa­dy przyj­mu­je się, że każ­dy obszar pro­jek­tu ma:

1. jed­ną oso­bę (lub gro­no osób, komi­tet) odpo­wie­dzial­ną za reali­za­cję (Responsible),
2. jed­na oso­bą (lub gro­no osób, komi­tet) akcep­tu­ją­cą zakres (Accauntable/Approver),
3. oso­by, któ­rych opi­nie mogą lub muszą być uwzględ­nia­ne, eks­per­ci dzie­dzi­no­wi (Consulted),
4. oso­by, któ­re muszą być na bie­żą­co infor­mo­wa­ne o postę­pach pro­jek­tu (Informed).

Określenie roli każ­de­go udzia­łow­ca w sto­sun­ku do każ­de­go z wyma­gań pozwa­la usta­lić w pro­jek­cie jed­no­oso­bo­wą odpo­wie­dzial­ność po stro­nie Zamawiającego. Ja oso­bi­ście sto­su­ję tę meto­dę jed­nak w sto­sun­ku do obsza­rów dzie­dzi­no­wych lub grup wyma­gań. Użycie macie­rzy RACI w sto­sun­ku do poje­dyn­czych wyma­gań jest chy­ba zbyt dro­bia­zgo­wym podej­ściem. Takie uogól­nie­nie daje jako efekt rela­tyw­nie mniej zło­żo­ne doku­men­ty, a wiec łatwiej­sze w percepcji.

Uwaga na zakończenie

Model kon­tek­sto­wy sys­te­mu („udzia­łow­ców”) nie jest dia­gra­mem mode­lu­ją­cym wyma­ga­nia, więc nie nale­ży na nim umiesz­czać przy­pad­ków uży­cia sys­te­mu (mimo, że uży­wa­my zesta­wu pojęć UML z gru­py Przypadki użycia). 

Dobrą prak­ty­ką two­rze­nia mode­li (tak­że w w UML) jest two­rze­nie dia­gra­mów w jed­nym kon­tek­ście. Umieszczanie na jed­nym dia­gra­mie ​„wszyst­kie­go co wie­my i co moż­na poka­zać” pro­wa­dzi to utrud­nie­nia per­cep­cji tych dia­gra­mów, a nie raz wręcz do utra­ty kon­tek­stu i co za tym idzie, ich zro­zu­mia­ło­ści w ogóle.

Zwracam tu tak­że uwa­gę, że dia­gram ten to nie rela­cje zna­ne z mode­li danych. Po pierw­sze nie są to (Aktor czy System) dane, po dru­gie zwią­zek logicz­ny pomię­dzy dany­mi to zupeł­nie inne poję­cie niż zależ­ność ​„klient-usłu­go­daw­ca”. Jeżeli wia­do­mo co ozna­cza fakt, że opro­gra­mo­wa­nie świad­czy pew­ną usłu­gę akto­ro­wi to inter­pre­ta­cja rela­cji ​„encja sys­tem i encja aktor” mogła by tu być trud­na do inter­pre­ta­cji. Po dru­gie encje w mode­lach ERD to byty pasyw­ne, cze­go nie moż­na powie­dzieć o Udziałowcach i Systemach, dla­te­go mode­lo­wa­ne są tu w para­dyg­ma­cie obiek­to­wym nota­cją UML.