Modelowanie obiektowe, procesy biznesowe, inżynieria oprogramowania

CASE czyli komputerowe wspomagania analizy i projektowania systemów

Od lat, pod­czas audy­tów i szko­leń, spo­ty­kam się z dziw­ny­mi dia­gra­ma­mi” two­rzo­ny­mi w celu… no wła­śnie. Ale po kolei…

Najpierw przy­po­mnę, bar­dzo tu pomoc­ne, poję­cie archi­tek­tu­ry kor­po­ra­cyj­nej, któ­ra – śle­dząc lite­ra­tu­rę przed­mio­tu – jest mode­lem (doku­men­ta­cją) wią­żą­cym model biz­ne­so­wy orga­ni­za­cji z jej zaso­ba­mi infor­ma­cyj­ny­mi i infra­struk­tu­rą słu­żą­cą do zarzą­dza­nia infor­ma­cją. Posiadanie takie­go mode­lu ma sens nie tyl­ko po to by, wie­dzieć co mamy” czy opi­sać wyma­ga­nia na to cze­go jesz­cze nie nie mamy a potrze­bu­je­my mieć”. Model taki pozwa­la ana­li­zo­wać posia­da­ne zaso­by, ale tak­że oce­nić ich wpływ na dzia­ła­nie orga­ni­za­cji, wza­jem­ny wpływ, prze­wi­dzieć reak­cje sys­te­mu na nowe bodź­ce (lub awarie).

W arty­ku­le opi­su­ją­cym pro­ces mode­lo­wa­nia od biz­ne­su do pro­jek­tu logi­ki sys­te­mu” opi­sa­łem prze­cho­dze­nie od mode­lu pro­ce­sów biz­ne­so­wych, przez przy­pad­ki uży­cia do mode­lu dzie­dzi­ny sys­te­mu (lub kom­po­nen­tów w przy­pad­ku zło­żo­nych sys­te­mów jak w arty­ku­le Przypadki uży­cia i gra­ni­ce sys­te­mu). Nie będę więc w tym miej­scu powta­rzał tych tre­ści, ale poka­że przykłady.

Opisywane tu podej­ście wyma­ga przy­ję­cia stan­dar­do­wych defi­ni­cji pojęć pro­ces biz­ne­so­wy i przy­pa­dek uży­cia oraz usłu­ga sys­te­mu (tak zwa­na prag­ma­ty­ka mode­li, powin­na być zawsze dołą­czo­na do doku­men­tów ana­li­zy). Dwie ostat­nie są w UML prak­tycz­nie toż­sa­me z pro­ce­sem biz­ne­so­wym (A use case is the spe­ci­fi­ca­tion of a set of actions per­for­med by a sys­tem, which yields an obse­rva­ble result that is, typi­cal­ly, of value for one or more actors or other sta­ke­hol­ders of the sys­tem – czyn­ność lub ich seria dają­ca jako efekt pro­dukt mają­cy war­tość dla akto­ra, źr. UML 2.4.1. 16.3.6 UseCase). W efek­cie zestaw dia­gra­mów opi­su­ją­cych orga­ni­za­cję z jej sys­te­mem infor­ma­cyj­nym, two­rzą Architekturę jak poniżej:

Model warstw AK

Usługa sys­te­mu (jego przy­pa­dek uży­cia) może wspie­rać jeden lub wie­le róż­nych pro­ce­sów biz­ne­so­wych, jed­nak na pozio­mie pro­ce­sów ele­men­tar­nych (tych któ­rych już nie dekom­po­nu­je­my), jeden pro­ces ele­men­tar­ny” może być wspie­ra­ny wyłącz­nie jed­nym przy­pad­kiem uży­cia (bo na tym pozio­mie powsta­je jeden pro­dukt). Przykładem jed­nej usłu­gi wyko­rzy­sty­wa­nej w kil­ku pro­ce­sach może być przy­pa­dek zwa­ny CRUD (Create, Retrieve, Update, Delete, czy­li Utwórz, Przywołaj, Aktualizuj, Usuń), taka usłu­ga (przy­pa­dek uży­cia typu CRUD) może wspie­rać pro­ce­sy: two­rze­nia, aktu­ali­za­cji (w tym zmia­ny sta­tu­su) i usu­wa­nia dokumentów.

Usługi są reali­zo­wa­ne przez okre­ślo­ne kom­po­nen­ty (apli­ka­cje), któ­re są insta­lo­wa­ne na kon­kret­nych plat­for­mach. Z uwa­gi na to, że kom­po­nen­ty mogą współ­pra­co­wać (wymie­niać mię­dzy sobą dane) mają udo­ku­men­to­wa­ne interfejsy.

Jak pokazać, które komponenty są wykorzystywane w określonych procesach?

Teraz przy­szedł moment, w któ­rym poja­wia­ją się czę­sto nie­stan­dar­do­we dia­gra­my wymy­śla­ne” w celu jakie­goś spo­so­bu” na poka­za­nie związ­ków pomię­dzy biz­ne­sem (pro­ce­sy biz­ne­so­we) a kom­po­nen­ta­mi opro­gra­mo­wa­nia. Poważną wadą tych pomy­słów jest przede wszyst­kim to, że są nie­stan­dar­do­we. Po dru­gie wyma­ga­ją ręcz­ne­go” wytwo­rze­nia, są pra­co­chłon­ne, mno­żą się dodat­ko­we stro­ny doku­men­ta­cji, pod­no­szą jej zło­żo­ność i pogar­sza­ją zro­zu­mia­łość całości.

Jak sobie z tym pora­dzić? Tu nie­oce­nio­ne są wła­śnie dobre pakie­ty opro­gra­mo­wa­nia CASE. Poniżej pro­sty przykład:

Model pro­ce­su biz­ne­so­we­go (pro­ces skła­da się z ele­men­tar­nych pro­ce­sów, każ­dy ma produkt):

Przykładowy proces biznesowy

Model przy­pad­ków uży­cia (zacho­wa­no nazwy z mode­lu pro­ce­sów dla orientacji):

Przypadki użycia aplikacji

Przykładowa reali­za­cja (sce­na­riusz) wybra­ne­go przy­pad­ku uży­cia (na pozio­mie kom­po­nen­tów, tu celem jest spe­cy­fi­ko­wa­nie inter­fej­su czy­li wywo­łań jed­ne­go kom­po­nen­tu przez drugi):

Czynność_4 - Scenariusz

Jak teraz spraw­dzić i poka­zać związ­ki pomię­dzy pro­ce­sa­mi, przy­pad­ka­mi uży­cia apli­ka­cji (usłu­ga­mi sys­te­mu) i kom­po­nen­ta­mi (apli­ka­cja­mi)? Zamiast two­rzyć nowe sztucz­ne i nie­stan­dar­do­we dia­gra­my znacz­nie lepiej jest poka­zać to w for­mie macie­rzy nie psu­jąc np. mode­li pro­ce­sów nie­for­mal­ny­mi zapi­sa­mi o systemach:

Macierz Procesy na uslugi

Macierz Uslugi na kommponenty

Gdyby potrzeb­ne były bar­dziej wyra­fi­no­wa­ne ana­li­zy zależ­no­ści, może­my stwo­rzyć, zamiast dwu­wy­mia­ro­wej macie­rzy, taki diagram:

Czynność_4 Analiza wpływu

I teraz sed­no czy­li co nam daje dobre narzę­dzie CASE? otóż powyż­sze macie­rze (takie i każ­dą inną) oraz model ana­li­zy wpły­wu, są gene­ro­wa­ne i aktu­ali­zo­wa­ne auto­ma­tycz­nie. Wystarczy opra­co­wać stan­dar­do­we mode­le w BPMN i UML jak powy­żej, wska­zać związ­ki pomię­dzy ele­men­ta­mi jako ich para­me­try (nie trze­ba do tego celu two­rzyć sztucz­nych dia­gra­mów) i sko­rzy­stać z moż­li­wo­ści auto­ma­tycz­ne doku­men­to­wa­nia tych związków.

Uzupełnieniem powyż­szych mode­li może być mapo­wa­nie doku­men­tów z dia­gra­mów pro­ce­sów biz­ne­so­wych na kla­sy (agre­ga­ty) repre­zen­tu­ją­ce je w opro­gra­mo­wa­niu (kom­po­nen­ty). Tu nie­ste­ty nie widzę sen­su mapo­wa­nia na dane w bazie danych” bo celem jest doku­men­to­wa­nie miej­sca prze­cho­wy­wa­nia infor­ma­cji (kom­po­nent) a nie imple­men­ta­cji (baza RDBMS, któ­ra jest jed­ną z wie­lu moż­li­wych imple­men­ta­cji utrwalania).

Ważne jest by narzę­dzie bar­dzo dobrze wspie­ra­ło spe­cy­fi­ka­cje nota­cji oraz meto­dy wery­fi­ko­wa­nia spój­no­ści mode­li takie jak śla­do­wa­nie, pod­le­głość mode­li, zależ­no­ści parent-child” i zagnieżdżanie.

(Artykuł powstał z uży­ciem opro­gra­mo­wa­nia Visual-Paradigm Agilian, pakiet ten ma moduł do pro­wa­dze­nia ana­liz wpły­wu i zależ­no­ści).

Modelowanie struktury organizacyjnej – widać światełko w tunelu

Pisząc recen­zję książ­ki Modelowanie biz­ne­so­we napi­sa­łem, że kom­plet­ny model orga­ni­za­cji to:

słow­nik pojęć (Glossary), model struk­tu­ry orga­ni­za­cyj­nej, regu­ły biz­ne­so­we (spe­cy­fi­ka­cja) oraz model pro­ce­sów biz­ne­so­wych korzy­sta­ją­cy z trzech poprzed­nich. Całość sta­no­wi dopie­ro kom­plet­ny model organizacji.

W Listopadzie ubie­głe­go roku tak­że pisa­łem o mode­lo­wa­niu struk­tu­ry organizacyjnej.

Osobiście uwa­żam, że mode­lo­wa­nie struk­tu­ry orga­ni­za­cyj­nej w UML nie jest dobrym pomy­słem. Są do tego ?prost­sze? narzę­dzia, nie przy­pad­kiem te lep­sze narzę­dzia CASE mają do tego dedy­ko­wa­ny dia­gram. Niestety nie ma tu dedy­ko­wa­nej nota­cji, dla­te­go bar­dzo waż­ne jest by słow­nik pojęć w mode­lu zawie­rał takie poję­cia jak pra­cow­nik, komór­ka orga­ni­za­cyj­ne itp. Dobrym pomy­słem jest zde­fi­nio­wa­nie wła­snej kon­wen­cji (dia­gram, sym­bo­le, defi­ni­cje pojęć) np. jak ta na począt­ku arty­ku­łu. (Modelowanie struk­tu­ry orga­ni­za­cyj­nej).

Są wido­ki by ten brak został uzu­peł­nio­ny. OMG pra­cu­je nad for­mal­nym meta­mo­de­lem ([[Organisation Structure Metamodel]]) do mode­lo­wa­nia struk­tur orga­ni­za­cyj­nych. Specyfikacja jesz­cze nie zosta­ła opu­bli­ko­wa­na, jest na eta­pie RFP, ale mamy przecieki :).

Ogólnie szkie­let tego meta­mo­de­lu ma nastę­pu­ją­cą postać:

Profil Organisation Structure Metamodel

Powyższy dia­gram przed­sta­wia pro­fil czy­li model poję­cio­wy, któ­ry może słu­żyć do budo­wy dia­gra­mu struk­tu­ry orga­ni­za­cyj­nej. Powyższe poję­cia to sys­tem ste­reo­ty­pów, czy­li znacz­ni­ków”. Przykładowy sche­mat struk­tu­ry orga­ni­za­cyj­nej z uży­ciem tych ste­reo­ty­pów mógł­by mieć poniż­szą postać (dia­gram więk­sze są dzie­lo­ne na pod­rzęd­ne struktury):

Model Struktury Organizacyjnej

Kilka słów komen­ta­rza. Szkieletem każ­dej takiej struk­tu­ry jest sys­tem komó­rek orga­ni­za­cyj­nych. Ta część z regu­ły nie budzi wąt­pli­wo­ści i nie stwa­rza pro­ble­mów, do cza­su gdy zacho­wu­je drze­wia­stą struk­tu­rę (każ­dy ma tyl­ko jed­ne­go prze­ło­żo­ne­go). Problemem poja­wia się, gdy zaczy­na­my mówić o kom­pe­ten­cjach, rolach i funk­cjach osób zaj­mu­ją­cych poszcze­gól­ne sta­no­wi­ska i pró­bie mode­lo­wa­nie funk­cjo­no­wa­nia organizacji.

Typowym pro­ble­mem, z jakim spo­ty­kam się poma­ga­jąc two­rzyć lub audy­tu­jąc mode­le pro­ce­sów biz­ne­so­wych czy np. ana­li­zy cią­gło­ści dzia­ła­nia, jest mapo­wa­nie ról w pro­ce­sach na struk­tu­rę orga­ni­za­cyj­ną oraz zarzą­dza­nie kompetencjami.

Mamy tu do czy­nie­nia z pro­ble­mem jakim jest to, że jed­ną rolę w pro­ce­sie może peł­nić wie­le osób (sta­no­wisk). Klasyką jest np. to, że fak­tu­rę może wysta­wić nie tyl­ko Fakturzysta ale np. każ­dy pra­cow­nik dzia­łu księ­go­wo­ści i dyr. sprze­da­ży. Porażką mode­la­rza” będzie nary­so­wa­nie dia­gra­mu, na któ­rym będzie, dla każ­de­go z powyż­szych sta­no­wisk, dedy­ko­wa­ny tor w pro­ce­sie i jakaś logi­ka bra­mek” poka­zu­ją­ca kie­dy kto wysta­wi tę fak­tu­rę. Z dru­giej stro­ny z regu­ły nie­praw­dą jest, że nikt poza fak­tu­rzy­stą nie może wysta­wić fak­tu­ry. Wystarczy jed­nak stwo­rzyć blo­czek” Rola lub Kompetencje (zależ­nie od sytuacji)->Wystawianie fak­tur i sko­ja­rzyć z wła­ści­wy­mi sta­no­wi­ska­mi, a blo­czek ten dopie­ro mapo­wać na role w pro­ce­sach. Uzyskamy dzię­ki temu praw­dziw­szy” model, uzy­sku­je­my moż­li­wość jed­no­znacz­ne­go mapo­wa­nia (śla­do­wa­nie: «tra­ce») ele­men­tów struk­tu­ry orga­ni­za­cyj­nej na model pro­ce­sów biz­ne­so­wych, być może na model dzie­dzi­ny. Możliwe sta­nie się testo­wa­nie popraw­no­ści modelu.

Praktycznie żaden dia­gram struk­tu­ry orga­ni­za­cyj­nej, jaki moż­na spo­tkać w doku­men­tach więk­szo­ści firm i spół­ek, nie nada­je się do nicze­go poza ilu­stro­wa­niem doku­men­tów w jakich jest umiesz­cza­ny. Nie ma w tym nic złe­go, do cza­su gdy nie docho­dzi do ana­li­zy funk­cjo­no­wa­nia takiej organizacji.

Ktoś zapy­ta: po co te zaba­wy, komu to prze­szka­dza? Odpowiedź jest pro­sta: dia­gram, któ­ry nie pozwa­la na ana­li­zę zależ­no­ści, ana­li­zę wpły­wu, testo­wa­nie jed­no­znacz­no­ści nie jest żad­nym mode­lem, nie jest przy­dat­ny do ana­li­zy. Można nim co naj­wy­żej ład­nie zilu­stro­wać doku­men­ty ale na pew­no nie nada­je się do ana­li­zy a przy­po­mnę, że:

nauka mówi dość jasno: aby prze­wi­dy­wać reak­cje bada­ne­go przed­mio­tu nale­ży zro­zu­mieć jak funk­cjo­nu­je i opra­co­wać jego model. Po dro­dze nale­ży udo­wod­nić, praw­dzi­wość modelu.

Zaś:

Samo utwo­rze­nie map (bo nie mode­li) w posta­ci dia­gra­mów z pomo­cą wywia­dów, sesji warsz­ta­to­wych i obser­wa­cji, da pro­dukt podob­ny do zdję­cia lot­ni­cze­go rze­ki: wie­my któ­rę­dy pły­nie, ale kom­plet­nie nie rozu­mie­my dla­cze­go aku­rat tak.

Tak więc, jeże­li ana­li­za ma posłu­żyć wdro­że­niu jakie­go­kol­wiek opro­gra­mo­wa­nia czy zmian orga­ni­za­cyj­nych, to pomo­gą nam w tym tyl­ko mode­le a nie obraz­ki”…

Na kon­fe­ren­cjach i forach toczą się sta­le dys­ku­sje na ten temat. Większość firm dorad­czych, infor­ma­tycz­nych oraz ich ana­li­ty­cy bro­nią tezy, że celem ana­li­zy jest zebra­nie infor­ma­cji w posta­ci doku­men­tów i zesta­wień. Niestety takie doku­men­ty są kom­plet­nie nie­przy­dat­ne, mają war­tość nagra­nia (patrz wyżej zdję­cie lot­ni­cze), nie da się na ich posta­wie wycią­gać żad­nych pozwa­la­ją­cych na dowo­dze­nie ich słusz­no­ści, wnio­sków nie licząc może oce­ny este­ty­ki edytorskiej.

Wiele się pisze o tym, że mode­lo­wa­nie słu­ży do doku­men­to­wa­nia pro­jek­tów. Otóż nie. Do doku­men­to­wa­nia pro­jek­tów słu­ży ryso­wa­nie, mode­lo­wa­nie słu­ży do pro­wa­dze­nia ana­liz poprzez testy mode­li, symu­la­cje i ana­li­zę sce­na­riu­szy. (Sabotaż doku­men­ta­cyj­ny).

Niewątpliwą zale­tą takiej pisa­nej obraz­ko­wej ana­li­zy” jest to, że nie wyma­ga ona abso­lut­nie żad­nych kom­pe­ten­cji poza umie­jęt­no­ścią komu­ni­ka­cji. Takim ana­li­ty­kiem może być nie­mal­że każ­dy (łatwa rekru­ta­cja, niski koszt), ale czy taki jest cel ana­liz poprze­dza­ją­cych pro­jek­ty, war­te set­ki tysię­cy zło­tych a nie raz miliony?

Na zakoń­cze­nie dodam, że naj­gor­szym spo­so­bem jaki znam i jaki nie­ste­ty czę­sto spo­ty­kam, na mode­lo­wa­nie struk­tu­ry orga­ni­za­cyj­nej, jest uży­cie dia­gra­mu klas lub dia­gra­mu przy­pad­ków uży­cia i mode­lo­wa­nie z zasto­so­wa­niem dzie­dzi­cze­nia (klas lub aktorów).

Studiowanie zakre­sów obo­wiąz­ków pra­cow­ni­ków firm jaw­nie poka­zu­je, że to nie praw­da. Wielu mene­dże­rów dzia­łów nie ma kom­pe­ten­cji swo­ich pod­wład­nych, nie raz szef dzia­łu praw­ne­go nie ma, i nie musi mieć, upraw­nień rad­cow­skich czy adwo­kac­kich, w wie­lu więk­szych sekre­ta­ria­tach, upo­waż­nie­nia do pew­nych pod­pi­sów są przy­dzie­la­ne indy­wi­du­al­nie i szef (sze­fo­wa) tego dzia­łu nie ma tych wszyst­kich upo­waż­nień. Szef kan­ce­la­rii taj­nej może mieć upraw­nie­nia do infor­ma­cji taj­nej nada­ne przez ABW, któ­rych to upraw­nień nie ma nie raz, jego prze­ło­żo­ny. Przykładów na fał­szy­wość dzie­dzi­cze­nia upraw­nień w struk­tu­rze orga­ni­za­cyj­nej moż­na podać tak ogrom­ną ilość, że dość czę­ste sto­so­wa­nie tej kon­struk­cji wyda­je mi się niezrozumiałe.

W efek­cie pro­jek­tu­jąc opro­gra­mo­wa­nie i sto­su­jąc meto­dę dzie­dzi­cze­nia dla akto­rów sys­te­mu powie­la­my te nie­praw­dę w sys­te­mie co rodzi nie raz ogrom­ne kło­po­ty. (Modelowanie struk­tu­ry orga­ni­za­cyj­nej).

Na zakoń­cze­nie pole­cam cie­ka­wy arty­kuł na temat mode­lo­wa­nia ról w opro­gra­mo­wa­niu.

Architektura korporacyjna z OMG​.org

Swego cza­su, gdy dowie­dzia­łem się, że nota­cja ArchiMate ma jed­nak być chro­nio­na pra­wa­mi autor­ski­mi przez The Open Group a koszt cer­ty­fi­ka­cji TOGAF to cał­kiem nie­zły haracz, napisałem:

Przyznaję, że rezy­gnu­ję z tej nota­cji jak i z TOGAF?a jako meto­dy­ki. W dwóch pro­jek­tach spraw­dzi­ła się moja hipo­te­za: mode­lo­wa­nie i ana­li­za war­stwy biz­ne­so­wej i IT oraz oce­na wza­jem­nych zależ­no­ści nie wyma­ga nowej nota­cji a dobrze wyko­na­ne­go mode­lu w już zna­nych, wystar­czą nota­cje BMM, BPMN, UML oraz narzę­dzie potra­fią­ce zarzą­dzać rela­cja­mi pomię­dzy obiek­ta­mi na tych mode­lach? zary­zy­ku­ję tezę, że jest to efek­tyw­niej­sze niż two­rze­nie kolej­nych dzie­sią­tek dia­gra­mów ArchiMate. (Pokazać wię­cej z sen­sem? ).

Podstawowym powo­dem jest to, że skąd­inąd dobry pomysł, jakim jest sama archi­tek­tu­ra kor­po­ra­cyj­na, jest obkła­da­ny ide­olo­gią (mar­ke­ting?!) i opła­ta­mi, któ­rych nie rozu­miem (albo raczej rozu­miem, ale nie mam ocho­ty ich pono­sić ;)), moi klien­ci nie raz tak­że nie).

Cóż to jest ta Architektura Korporacyjna (dalej Architektura lub AK)? Ogólnie:

Based on this bro­ade­ning of sco­pe, Enterprise Architecture now covers:

  • Business Architecture
  • Data Architecture
  • Application Architecture
  • Infrastructure Architecture

(pole­cam cały, krót­ki wpis na Business Analyst Interview Questions | Modern Analyst > What is Enterprise Architecture?).

Przytoczę tu pro­stą i bar­dzo dobrą moim zda­niem defi­ni­cję zaczerp­nię­tą z refe­ra­tu [[dr. Andrzeja Sobczaka (SGH)]]:

Architektura kor­po­ra­cyj­na – for­mal­ny opis struk­tu­ry i funk­cji kom­po­nen­tów kor­po­ra­cji (obej­mu­ją­cych ludzi, pro­ce­sy, infor­ma­cje i tech­ni­kę), wza­jem­nych rela­cji pomię­dzy tymi kom­po­nen­ta­mi oraz pryn­cy­pia i wytycz­ne odno­śnie do zarzą­dza­nia pro­jek­to­wa­niem i zarzą­dza­nia zmia­ną tych kom­po­nen­tów w czasie.

Moim zda­niem nie trze­ba nic wię­cej doda­wać. Dla porząd­ku przy­to­czę defi­ni­cję sło­wa pryn­cy­pium ze słow­ni­ka j.polskiego:

pryn­cy­pium, prin­ci­pium [wym. princ-ipium] ?naj­waż­niej­sza dla kogoś lub dla cze­goś zasa­da albo war­tość? (Portal Wiedzy PWN – słow­ni­ki, ency­klo­pe­die, pod­ręcz­ni­ki aka­de­mic­kie, książ­ki spe­cja­li­stycz­ne, repe­ty­to­ria, porad­ni­ki, prze­wod­ni­ki).

Te pryn­cy­pia, to moim zda­niem uzna­nie for­ma­li­zmu w budo­wie mode­li i sfor­ma­li­zo­wa­ne zarzą­dza­nie ich zmianą.

Narzędzia OMG​.org

Co mamy w skrzyn­ce narzę­dzio­wej OMG” (www​.omg​.org)? Ludzie i pro­ce­sy to nic inne­go jak BPMN i struk­tu­ra orga­ni­za­cyj­na (ta dru­ga w BPMN lub jako sfor­ma­li­zo­wa­ny [[orga­ni­gram]]). Informacje i tech­ni­ka to nic inne­go jak UML i dia­gra­my struk­tu­ral­ne. Nie roz­wo­dząc się, całość wyglą­da ogól­nie tak:

Architektura korporacyjna - struktura

Powyższy dia­gram obrazuje:

  • kolej­ne wyma­ga­ne w AK war­stwy (doda­no na szczy­cie tak zwa­ną moty­wa­cję biznesową),
  • mapo­wa­nie zstępujące

W efek­cie, mają zasto­so­wa­nie wska­za­ne narzę­dzia (dia­gra­my, mode­le). Z ich pomo­cą może­my nie tyl­ko opra­co­wać model Architektury Korporacyjnej ale tak­że nad­zo­ro­wać go, budu­jąc macie­rze mapowania.

Tu poja­wia się poję­cie prag­ma­ty­ki w sto­so­wa­niu języ­ka (nota­cji). Ta prag­ma­ty­ka to wspo­mnia­ne już pryn­cy­pia pro­ce­so­we i obiek­to­we, oraz wska­za­ne na dia­gra­mie powy­żej uży­cie pojęć w każ­dej z wymie­nio­nych nota­cji, czy­li co i na co mapu­je­my. Mapowanie wyma­ga dopre­cy­zo­wa­nia seman­ty­ki mode­li czy­li defi­ni­cji pojęć. Jak? Najprościej nie kom­bi­no­wać np. z przy­pad­ka­mi uży­cia na biz­ne­so­we, sys­te­mo­we i inne bo to zupeł­nie nie potrzeb­ne i nie pozwa­la na pro­ste mapowanie.

Jawne mapowanie na diagramach pomiędzy warstwami

Notacja ArchiMate ma moż­li­wość (taki jest jej pośred­ni cel) jaw­ne­go poka­za­nia mapo­wa­nia pomię­dzy obiek­ta­mi warstw na dia­gra­mach. W przy­pad­ku UML też jest to for­mal­nie moż­li­we od wer­sji 2.0, zaś mapo­wa­nia BPMN->UML doko­nu­je się w doku­men­ta­cji (typo­we śla­do­wa­nie Czynność -> Przypadek użycia).

Otóż mapo­wa­nie moż­na poka­zać na wie­le spo­so­bów. Moim zda­niem robie­nie tego na dia­gra­mach, po pierw­sze nie­co je zaciem­nia, po dru­gie i tak nie eli­mi­nu­je przy­dat­no­ści stwo­rze­nia macie­rzy mapo­wa­nia. Ta dru­ga może być wyge­ne­ro­wa­na auto­ma­tycz­nie, jeże­li tyl­ko uży­wa­my dobre­go narzę­dzia CASE (bez nie­go zresz­tą nie wyobra­żam sobie wyko­na­nia żad­ne­go więk­sze­go mode­lu przy zacho­wa­niu roz­sąd­nej pracochłonności).

Po dru­gie nawet śred­ni model, mają­cy kil­ka­dzie­siąt obiek­tów, będzie wyma­gał dużej ilo­ści dodat­ko­wych dia­gra­mów obra­zu­ją­cych samo mapo­wa­nie, któ­re to dodat­ko­we dia­gra­my nie wno­szą war­to­ści doda­nej do pro­jek­tu, bo macierz gene­ro­wa­na auto­ma­tycz­nie z repo­zy­to­rium narzę­dzia CASE i tak jest łatwiej­sza w uży­ciu i per­cep­cji, sta­no­wi też nie­ja­ko auto­ma­tycz­ny wali­da­tor” czy jest ono – mapo­wa­nie – popraw­ne i kompletne.

TOGAF – subiektywnych słów kilka

O tym krót­ko. Wiem, że sta­no­wi swe­go rodza­ju gotow­ca”, ale czy skór­ka war­ta wypraw­ki? Celem budo­wa­nia AK nie jest wdro­że­nie TOGAF”a” (czy też Siatki Zachmann’a), celem jest … no wła­śnie co? O tym na końcu.

W przy­pad­ku TOGAF v 8.x mamy czte­ry obsza­ry modelowania:

  • Business Architecture
  • Data Architecture
  • Applications Architecture
  • Technology Architecture

(źr. The Open Group Architecture Framework Version 8.1.1., nowa wer­sja TOGAF 9, w porów­na­niu z powyż­szym, roz­cią­ga się na ele­men­ty moty­wa­cji biznesowej).

Nie będę się roz­pi­sy­wał na temat wszyst­kich warstw. Kilka słów o jed­nej: Architektura Danych.

TOGAF i ArchiMate (jak ja rozu­miem obie spe­cy­fi­ka­cje) ope­ru­je poję­ciem danych, oddzie­lo­nych od logi­ki biz­ne­so­wej. Obecnie sto­so­wa­ne meto­dy i narzę­dzia w pro­ce­sie wytwa­rza­nia opro­gra­mo­wa­nia opar­te są na para­dyg­ma­cie obiek­to­wym, któ­ry kom­plet­nie igno­ru­je poję­cie wydzie­lo­nych danych jako takich. Mam tu na myśli bazy danych (w szcze­gól­no­ści rela­cyj­ne). Bazy danych, w meto­dach obiek­to­wych, to ele­men­ty imple­men­ta­cji, więc są one poza obsza­rem ana­li­zy i pro­jek­to­wa­nia. Przedmiotem prze­twa­rza­nia w para­dyg­ma­cie obiek­to­wym są obiek­ty biz­ne­so­we wraz z ich wewnętrz­ną logi­ką i zachowaniami.

Jaki jest więc sens brnię­cia wstecz do cza­sów ana­li­zy struk­tu­ral­nej (odręb­nie ana­li­zo­wa­ne i imple­men­to­wa­ne dane i funk­cje ich przekształcania)?

Przypomnę tu tyl­ko deli­kat­nie, że np. celem pro­ce­su sprze­da­ży nie są dane zapi­sa­ne na Fakturze VAT a pozy­ska­nie środ­ków ze sprze­da­ży pro­duk­tów, obiekt biz­ne­so­wy Faktura VAT wraz z regu­ła­mi nali­cza­nia podat­ku, to jakaś mate­ria­li­za­cja tego fak­tu a nie cel sam w sobie. Powoływanie się więc na dane” w moich oczach nie jest żad­nym postę­pem”.

Na zakończenie

Mamy więc pomysł o wdzięcz­nej nazwie Architektura Korporacyjna. Jej defi­ni­cję, moim zda­niem, moż­na spro­wa­dzić do treści:

Architektura Korporacyjna to model i jego doku­men­ta­cja, zawie­ra­ją­cy całą i wystar­cza­ją­cą wie­dzę o tym, co ma wpływ na dostar­cza­nie pro­duk­tu (J.Żeliński)

Po nam to? Po co nam taka doku­men­ta­cja? Przykłady korzy­ści z jej posiadania:

  • mamy na tacy” model sys­te­mu zależ­no­ści (w tym ana­li­za wpły­wu) pozwa­la­ją­cy natych­miast oce­nić ryzy­ka zwią­za­ne z wza­jem­nym wpły­wem na sie­bie pro­ce­sów, ludzi, zaso­bów (np. jakie skut­ki będzie mia­ło wyłą­cze­nie kon­kret­ne­go ser­we­ra czy spóź­nie­nie do pra­cy kon­kret­ne­go pracownika),
  • mamy na tacy” wyma­ga­nia na opro­gra­mo­wa­nie, bez nie­po­trzeb­ne­go zwin­ne­go” ich poszu­ki­wa­nia meto­dą prób i błę­dów, nie­za­leż­nie od tego czy kupu­je­my nowe czy wymie­nia­my (nie­ste­ty, tak zwa­ne zwin­ne meto­dy to nie raz bar­dzo duże kosz­ty zarzu­co­nych bocz­nych ście­żek” odkry­wa­nych burzą mózgów),
  • od razu zauwa­ży­my, że idea posia­da­nia mono­li­tycz­ne­go sys­te­mu ERP II nie bar­dzo ma sens, usztyw­nia orga­ni­za­cje oraz two­rzy potęż­ny [[„sin­gle point of failu­re”]] (zło­śli­wi doda­ją sin­gle point of big cost” :)),
  • i naj­waż­niej­sze: jak tyl­ko prze­pro­wa­dzi­my ana­li­zę i wyko­na­my model AK, szyb­ko wychwy­ci­my tak zwa­ne osie­ro­co­ne wyma­ga­nia na opro­gra­mo­wa­nie, osie­ro­co­ne sta­no­wi­ska pra­cy, osie­ro­co­ne pro­ce­du­ry, … (osie­ro­co­ne: nie­wy­ko­rzy­sty­wa­ne), to nie raz źró­dło samo w sobie – eli­mi­na­cja sie­rot” – ogrom­nych oszczęd­no­ści juz na samym począt­ku projektu,
  • i inne …

Jak tym zarzą­dzać? Na pew­no nie ręcz­nie, bez opro­gra­mo­wa­nia CASE w zasa­dzie nie­re­al­ne. Czy to kosz­tow­ne? Hm… kła­nia się ana­li­za ROI, każ­da orga­ni­za­cja ma swój próg ren­tow­no­ści. Jednak od sie­bie powiem tak: oszczęd­no­ści poja­wia­ją się natych­miast w posta­ci iden­ty­fi­ka­cji sie­rot”. Kolejny etap oszczęd­no­ści to reor­ga­ni­za­cja kosz­tów i ryzyk zarzą­dza­nia orga­ni­za­cją, kosz­tów posia­da­nia opro­gra­mo­wa­nia, kosz­tów jego roz­wo­ju, kosz­tów zaku­pu i two­rze­nia. Dobra wia­do­mość: począ­tek każ­dy już ma w posta­ci pro­wa­dzo­nej doku­men­ta­cji w dzia­le HR.

Jak więc wyglą­da­ją narzę­dzia rodem z OMG, któ­re w zupeł­no­ści wystarczą??

Jest to zestaw nota­cji (BMM, BPMN, UML), któ­ry ma nie­mal­że każ­dy pakiet CASE. Notację ArchiMate mają nie­ste­ty tyl­ko nie­któ­re z nich, a jak The Open Group zacznie egze­kwo­wać opła­ty licen­cyj­ne to będzie chy­ba tyl­ko gorzej (co cie­ka­we sami twó­cy ArchiMate piszą, że uszcze­gó­ło­wie­nie mode­lu AK wyko­na­ne­go z pomo­cą ArchiMate wyma­ga uży­cia nota­cji UML). Koszty jed­nej licen­cji pakie­tu CASE (nie raz wystar­czy mieć jed­ne­go Architekta w orga­ni­za­cji) w wie­lu przy­pad­kach nie prze­kra­cza­ją 1000USD. Jeżeli więc uda się unik­nąć kolej­nej ana­li­zy wyma­gań za kil­ka­dzie­siąt tysię­cy to już ROI mamy w kieszeni.

A po co te for­ma­li­zmy (pryn­cy­pia)? Na eta­pie ana­li­zy i mode­lo­wa­nia pozwa­la­ją wery­fi­ko­wać popraw­ność mode­li i całej struk­tu­ry. Na eta­pie zarzą­dza­nia zmia­ną pano­wać nad kosz­ta­mi zmian i ryzy­ka­mi w rodza­ju i czasopisma”…:)

Druga dobra wia­do­mość: spo­koj­nie moż­na to (rola Architekta) out­so­ur­so­wać, będzie jesz­cze taniej.

Analiza biznesowa

Po uka­za­niu się arty­ku­łu Reguły biz­ne­so­we jako motor.. czę­sto jestem pyta­ny dla­cze­go restryk­cyj­nie pil­nu­ję for­mal­nych zasad ana­li­zy w pro­jek­cie. Powód jest tyl­ko jeden: to jedy­ny spo­sób na osią­gnie­cie spój­no­ści i kom­plet­no­ści w pierw­szym podejściu.

Iteracyjne dopro­wa­dza­nie doku­men­tu (opra­co­wa­nia) do wyma­ga­ne­go pozio­mu jego jako­ści jest bar­dzo kosz­tow­ne. Zaryzykuje tezę, że jeden dobry ana­li­tyk (na umo­wę o dzie­ło ;)) wyko­na tę samą pra­ce znacz­nie szyb­ciej, taniej i lepiej niż prze­cięt­ny zespół z pro­ce­sem kon­tro­li jako­ści w posta­ci recen­zen­tów”. Nawet jeden ana­li­tyk z tra­dy­cyj­nym podej­ściem plus jeden recen­zent to pro­ces kosz­tow­niej­szy (dru­ga oso­ba w pro­jek­cie) i trwa­ją­cy znacz­nie dłu­żej (kolej­ne ite­ra­cje recen­zji, to tak­że koszt). Dyskusje pozo­sta­wiam Państwu, ja nie znam przy­pad­ku by powyż­sze się nie spraw­dzi­ło. Warunek: wła­ści­we sto­so­wa­nie wła­ści­wych narzę­dzi analitycznych.

Typowe zadanie: model organizacji

Model orga­ni­za­cji to doku­ment opi­su­ją­cy ją w spo­sób pozwa­la­ją­cy na zro­zu­mie­nie przy­czyn tego co i jak sie w niej dzie­je oraz na prze­wi­dy­wa­nie skut­ków pla­no­wa­nych dzia­łań (np. orga­ni­za­cyj­nych). Kluczowym, osta­tecz­nym narzę­dziem pra­cy jest model pro­ce­sów biz­ne­so­wych ale on jest efek­tem wie­lu rze­czy, w tym reguł biz­ne­so­wych (z regu­ły for­ma zarzą­dzeń itp.), kom­pe­ten­cji pra­cow­ni­ków. Reguły i kom­pe­ten­cje powin­ny być spój­ne i jed­no­znacz­ne stąd poja­wia się potrze­ba posia­da­nia w orga­ni­za­cji wspól­ne­go słow­ni­ka ter­mi­nów (ostat­nio spo­tka­łem fir­mę, w któ­rej nowe pro­jek­ty mają for­mal­ną wewnętrz­ną nazwę Temat a nie Projekt) .

Model taki to tak­że jedy­ny spo­sób za udo­ku­men­to­wa­nie i zatrzy­ma­nie w fir­mie Wiedzy o tym jak funk­cjo­nu­je i dla­cze­go aku­rat tak, mimo rota­cji pra­cow­ni­ków, od któ­rej nie jest wol­na żad­na fir­ma. Na począ­tek mała burza mózgów, czy­li cze­go oba­wia­ją się zarzą­dy firm:

Biblioteka

Jak roz­wią­zać te problemy?

Zakres projektu analitycznego

Jak wspo­mnia­no model pro­ce­sów jest koń­co­wym efek­tem pra­cy jed­nak nie jest on zawie­szo­ny w powie­trzu”. Aby wyko­nać go popraw­nie i sku­tecz­nie” (mieć moż­li­wość auto­au­dy­tu i wery­fi­ka­cji) nale­ży mieć: słow­nik pojęć biz­ne­so­wych (ang. glos­sa­ry, obej­mu­je swo­im zasię­giem obiek­ty biz­ne­so­we np. klu­czo­we doku­men­ty), model struk­tu­ry orga­ni­za­cyj­nej oraz spe­cy­fi­ka­cje reguł biznesowych.

Metamodel projektu

Słownik pojęć

Jest pod­sta­wo­wym wery­fi­ka­to­rem i gwa­ran­tem jed­no­znacz­no­ści wszel­kich zapi­sów, w tym nazw na mode­lach pro­ce­sów, pojęć uży­tych w regu­łach biz­ne­so­wych (w tym np. w wewnętrz­nych zarzą­dze­niach, pro­ce­du­rach itp.), nazw uży­tych w struk­tu­rze orga­ni­za­cyj­nej . Pojęcia te nie powin­ny być wza­jem­nie sprzecz­ne ani zazę­bia­ją­ce się” (każ­da rzecz w fir­mie powin­na paso­wać tyl­ko do jed­nej defi­ni­cji), nie powin­ny być defi­nio­wa­ne przez sie­bie same (jed­no z pomo­cą dru­gie­go). Zbudowanie popraw­ne­go (czy­taj bez­piecz­ne­go dla pro­jek­tu) słow­ni­ka jest trud­nym zada­niem. Tu for­ma­li­zmem jest utrzy­ma­nie powyż­szych zasad oraz sto­so­wa­nie odpo­wied­nich narzę­dzi ana­li­tycz­nych (spo­so­bów iden­ty­fi­ka­cji i weryfikacji).

Słownik reguł biznesowych

To kolej­ny ele­ment, któ­re­mu poma­ga­ją for­ma­li­zmy. Zgodnie z defi­ni­cją Reguła biz­ne­so­wa to ogra­ni­cze­nie obej­mu­ją­ce całą orga­ni­za­cję, regu­ła nie jest pro­ce­sem ani pro­ce­du­rą. Reguły (ich treść i spo­sób zapi­su) muszą być jasne (zro­zu­mia­łe), spój­ne i wery­fi­ko­wal­ne. Ich two­rze­nie, kon­tro­la nie­sprzecz­no­ści i kom­plet­no­ści wyma­ga tak­że prze­strze­ga­nia pew­nych zasad (for­ma­li­zów). W prze­ciw­nym wypad­ku ska­za­ni jeste­śmy na ich wery­fi­ka­cję poprzez wdro­że­nie i obser­wo­wa­nie skut­ków czy­li efek­tów ubocz­nych w orga­ni­za­cji po wpro­wa­dze­niu np. nowych zaka­zów lub obo­wiąz­ków, co jest dłu­go­trwa­łe i bar­dzo kosztowne.

Narzędziem do wychwy­ty­wa­nia” i wery­fi­ka­cji logi­ki poję­cio­wej reguł biz­ne­so­wych (te są for­mu­ło­wa­ne z uży­ciem słow­ni­ka pojęć) jest tak zwa­ny dia­gram faktów:

Model faktow Biblioteka

Diagram ten (nie da się go zastą­pić ani dia­gra­mem klas UML ani mode­lem danych!) ma pew­ną spe­cy­fi­kę poję­cio­wą: skła­da się wyłącz­nie z pojęć zde­fi­nio­wa­nych w słow­ni­ku (pro­sto­ką­ty) oraz ze zda­rzeń zwa­nych fak­ta­mi, któ­re je opi­su­ją (a nie wią­żą!) zde­fi­nio­wa­ne poję­cia. W ten spo­sób opi­su­je­my (testu­je­my, ana­li­zu­je­my) klu­czo­wą, spe­cy­ficz­ną, sfe­rę dzia­ła­nia orga­ni­za­cji. Powyższe nie zastę­pu­je mode­lu pro­ce­sów, któ­ry opi­su­je powsta­wa­nie war­to­ści jako prze­pływ pra­cy. Tu mamy do czy­nie­nia z ele­men­tar­ny­mi fak­ta­mi opi­su­ją­cy­mi pod­sta­wo­we dzia­ła­nia w orga­ni­za­cji (model ten nie ope­ru­je poję­ciem kla­sa, zda­rze­nie ani produkt).

Po wyko­na­niu i prze­te­sto­wa­niu powyż­sze­go dys­po­nu­je­my słow­ni­kiem pojęć i spe­cy­fi­ka­cją reguł biz­ne­so­wych speł­nia­ją­cą powyż­sze wymagania:

Zestawienie regul i pojec

Struktura organizacyjna

W brew pozo­rom jej opra­co­wa­nie nie jest łatwe. Struktura orga­ni­za­cyj­na okre­śla pod­le­głość i zara­zem odpo­wie­dzial­ność. Powinna być jed­no­znacz­na. Jako model sta­no­wi pew­ną hie­rar­chię, któ­rej szczy­tem jest pod­miot mode­lo­wa­ny (na szczy­cie jest to orga­ni­za­cja, w pew­nym sen­sie obra­zu­je to oso­bę praw­ną). Celem jest okre­śle­nie jed­no­znacz­nej pod­le­gło­ści i odpo­wie­dzial­no­ści każ­de­go pra­cow­ni­ka. Pracownik peł­ni funk­cje zde­fi­nio­wa­ną przez jego umo­co­wa­nie w tej struk­tu­rze, dopusz­czal­ne jest to, że jakaś oso­ba zaj­mu­je wię­cej niż jed­no sta­no­wi­sko (wte­dy nazy­wa­my to PO czy­li peł­nią­cy obo­wiąz­ki). W efek­cie pozwa­la to na jed­no­znacz­ne przy­po­rząd­ko­wa­nie oso­by do roli w pro­ce­sie (o tym w dal­szej części).

Model struktury organizacyjnej

Powyższy dia­gram jest try­wial­ny ale obra­zu­je tę hie­rar­chię. Gdyby z jakie­goś powo­du Kierownik biblio­te­ki miał wypo­ży­czać jeden dzień książ­ki, to zna­czy, że kon­kret­ny Kowalski (ten kie­row­nik) tego dnia będzie peł­nił obo­wiąz­ki (rolę) Bibliotekarza. System peł­nią­ce­go obo­wiąz­ki” poma­ga w utrzy­ma­niu prząd­ku organizacyjnego.

Każdy ele­ment na takim dia­gra­mie (ele­ment struk­tu­ry orga­ni­za­cyj­nej) powi­nien mieć okre­ślo­ne: wyma­ga­ne umie­jęt­no­ści oraz zakres obo­wiąz­ków. Zakres obo­wiąz­ków to odpo­wie­dzial­ność, zaś umie­jęt­no­ści okre­śla­ją co kon­kret­na oso­ba musi umieć albo inny­mi sło­wy cze­go kon­kret­nej oso­bie nie trze­ba mówić (instru­ować jej) by wyko­na­ła swo­ją pra­cę popraw­nie. Poprawnie ozna­cza tu: w ocze­ki­wa­ny spo­sób. Im mniej­sze umie­jęt­no­ści tym bar­dziej szcze­gó­ło­wy musi być opis pra­cy jaką dana oso­ba ma wyko­ny­wać by robi­ła to zgod­nie z ocze­ki­wa­nia­mi (jest to ści­sła zależność).

Jak widać jest to obszar ana­li­zy, któ­ry przy oka­zji porząd­ku­je kwe­stie zarzą­dza­nia zaso­ba­mi ludzkimi. 

W wie­lu fir­mach obser­wu­ję w tej sfe­rze bała­gan i z jed­nej stro­ny Zarząd nie dopusz­cza myśli o napra­wie­niu” struk­tu­ry orga­ni­za­cyj­nej, a z dru­giej w nie­skoń­czo­ność szu­ka przy­czyn kło­po­tów orga­ni­za­cyj­nych wymy­śla­jąc kolej­ne nowe, nie roz­wią­zu­ją­ce pro­ble­mu, zarządzenia.

Model procesów biznesowych

Pora na kon­kre­ty. Model (mapa) pro­ce­sów biz­ne­so­wych to efekt powyż­szych ogra­ni­czeń (tak: regu­ły biz­ne­so­we oraz struk­tu­ry orga­ni­za­cyj­ne i zakre­sy obo­wiąz­ków to ogra­ni­cze­nia). Dobrze opra­co­wa­ny model pro­ce­su jest kon­kret­ny, nie roz­wle­kły i czy­tel­ny. Opisuje (obra­zu­je) prze­pływ pracy:

Model procesow

Model pro­ce­sów biz­ne­so­wych bywa nazy­wa­ny (zgod­nie z teo­rią łań­cu­cha war­to­ści M.E.Portera) mode­lem wewnętrz­ne­go (fir­mo­we­go) łań­cu­cha war­to­ści. Model taki powi­nien być w 100% zgod­ny z defi­ni­cją pro­ce­su biz­ne­so­we­go, naj­czę­ściej przy­ta­cza­ną jest: pro­ces biz­ne­so­wy to czyn­ność lub łań­cuch czyn­no­ści, zamie­nia­ją­cy infor­ma­cje – stan wej­ścia w stan wyj­ścia, two­rząc war­tość doda­ną. Model taki powi­nien wiec obli­ga­to­ryj­nie zawie­rać: opis i stan wej­ścia, wyj­ścia, listę czyn­no­ści. Czynnikami opi­su­ją­cy­mi szcze­gó­ły wyko­na­nia każ­dej czyn­no­ści są: regu­ły biz­ne­so­we (w tym pro­ce­du­ry) oraz kom­pe­ten­cje wykonawcy.

W efek­cie otrzy­mu­je­my spój­ny i czy­tel­ny model pro­ce­su, nie prze­ła­do­wa­ny zbęd­ny­mi szcze­gó­ła­mi, zarzą­dza­ny i łatwy w uży­ciu. Korzyści z takie­go modelu:

  1. zmia­ny zakre­sów obo­wiąz­ków nie wyma­ga­ją jego aktualizacji
  2. zmia­ny reguł biz­ne­so­wych nie wyma­ga­ją jego aktualizacji
  3. zmia­na przy­po­rząd­ko­wa­nia kon­kret­nej oso­bie peł­nio­nych obo­wiąz­ków nie wyma­ga jego aktualizacji
  4. jest dosko­na­łym narzę­dziem do ana­li­zy wyma­gań na sys­te­my IT

To efek­ty utrzy­ma­nia for­mal­nej zasa­dy mówią­cej, że każ­da infor­ma­cja jest utrzy­my­wa­na w jed­nym miej­scu ze wska­za­niem gdzie jest wyko­rzy­sty­wa­na. Pozwala to tak­że wyko­nać szyb­ko tak zwa­na ana­li­zę wpły­wu (ryzyk) czy­li na co ma wpływ poten­cjal­na inge­ren­cja w jakiś ele­ment modelu:

wypozyczenie-ksiazki-analysis-diagram

Na zakończenie

Źródła stan­dar­dów na eta­pie ana­li­zy biz­ne­so­wej czy­li mode­lo­wa­nia struk­tur zarząd­czych organizacji:

  1. Semantics Of Business Vocabulary And Business Rules
  2. RuleSpeak
  3. BPMN
  4. Business Rules Group (w tym Business Motivation Model)

Stosowanie opi­sa­nych tu for­ma­li­zmów to uzna­nie, że dobre i spraw­dzo­ne stan­dar­dy pozwa­la­ją zmi­ni­ma­li­zo­wać ryzy­ko pro­jek­tów analitycznych.

Analiza to nie zbie­ra­nie danych o fir­mie i ich sor­to­wa­nie, bo czy to nie brzmi jak eko­lo­gicz­ne zbie­ra­nie śmie­ci? Analiza to porząd­ko­wa­nie zebra­nej wie­dzy o orga­ni­za­cji, korzy­sta­jąc z wypra­co­wa­nych sys­te­mów poję­cio­wych, czy­li przy­po­rząd­ko­wy­wa­nie wszyst­kie­go co wie­my do skoń­czo­nej licz­by pojęć, oraz uzu­peł­nia­nie lub napra­wia­nie wszyst­kie­go cze­go zabra­nie w tak opra­co­wa­nym mode­lu. Kluczem dobrej ana­li­zy jest uogól­nia­nie czy­li wychwy­ty­wa­nie rze­czy istot­nych oraz odsie­wa­nie infor­ma­cji zbęd­nych, nie mają­cych wpły­wu na cel pro­jek­tu a zaciem­nia­ją­cych go. Analiza to odkry­wa­nie i rozu­mie­nie reguł, pano­wa­nie nad zło­żo­no­ścią organizacji.

Większość pro­jek­tów takich jak np. wdra­ża­nie nowych metod kon­tro­lin­gu, zrów­no­wa­żo­nej kar­ty wyni­ków, nowych sys­te­mów IT itp. cier­pi głów­nie z powo­du posia­da­nia nad­mia­ru infor­ma­cji z jed­nej stro­ny i kom­plet­ne­go jej nie­zro­zu­mie­nia z dru­giej. Sławne już w bada­niach złe i nie­kom­plet­ne wyma­ga­nia” czy zmia­ny zakre­su pro­jek­tu w trak­cie jego trwa­nia” to kla­sycz­ne skut­ki złej (a czę­sto pomi­ja­nia!) ana­li­zy biz­ne­so­wej. Koszty tych pora­żek wie­lo­krot­nie prze­wyż­sza­ją koszt takich analiz.

Udziałowcy projektu czyli który diagram UML …

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:

business-contexst-diagram

udzia­łow­cy:

stakeholder-relationship-model

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):

model-kontekstowy-dla-projektu-dostarczenia-systemu

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?

model-kontekstowy-dla-projektu-dostarczenia-systemu-2

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.

[czer­wiec 2020] Po pew­nej dys­ku­sji doda­łem tu powyż­szy dia­gram, pyta­nie brzmia­ło jak poka­zać na dia­gra­mie sytu­acje opi­sa­ną tu tek­stem (diagramDescription).

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.