Analiza systemowa zdalnie

Całkiem nie­daw­no wpadł mi w oczy arty­kuł na temat zdal­ne­go pro­wa­dze­nia ana­li­zy, ostat­ni jego aka­pit brzmi:

Virtual com­mu­ni­ca­tion and faci­li­ta­tion skills will rema­in a key com­pe­ten­cy for BAs for years to come. Stop tor­tu­ring your sta­ke­hol­ders with boring, inef­fec­ti­ve con­fe­ren­ce calls. Find new and cre­ati­ve ways to alle­via­te the com­mon pain points. Please sha­re your vir­tu­al faci­li­ta­tion tips in the com­ments below! (Business Analyst | Virtual Requirements Meetings: Painful or Practical?).

(w uprosz­cze­niu: zdal­nie pro­wa­dzo­na ana­li­za to klu­czo­wa przy­szła kom­pe­ten­cja ana­li­ty­ków, war­to prze­stać tor­tu­ro­wać ludzi wie­lo­go­dzin­ny­mi nud­ny­mi spo­tka­nia­mi, znajdź inna kre­atyw­ną dro­gę…).

Nie ja pierw­szy odkry­łem, że spo­tka­nia i warsz­ta­ty, to po pierw­sze ogrom­ny koszt (jeden dzień takich warsz­ta­tów to łącz­ny koszt dnió­wek wszyst­kich obec­nych na spo­tka­niu). Po dru­gie, takie zbio­ro­we dys­ku­sje naj­czę­ściej nie­ste­ty są nud­ne i męczą­ce, szyb­ko zmie­nia­ją się w nie­koń­czą­ce się nego­cja­cje, a zatwier­dza­nie nota­tek z takich spo­tkań to kolej­na dro­ga przez mękę (wysła­ne do wszyst­kich obec­nych wra­ca­ją z uwa­ga­mi, te trze­ba nanieść i roze­słać doku­ment jesz­cze raz…).

Tak zwa­ne warsz­ta­ty wyma­gań (tak zwa­ne [[sesje JAD]]) to jed­na z naj­bar­dziej wyna­tu­rzo­nych form tych spo­tkań, bo ich uczest­ni­cy wal­czą jak o ogień by zdo­być zapis sank­cjo­nu­ją­cych ich (nie­raz bar­dzo poboż­ne) życze­nia, każ­dy zgła­sza swo­je pomy­sły na imple­men­ta­cję, coraz to nowe fajer­wer­ki, pseu­do udo­god­nie­nia i oczy­wi­ście upraw­nie­nia dla sie­bie w nowej apli­ka­cji. Złośliwi mawia­ją, że obję­tość spe­cy­fi­ka­cji wyma­gań jest wprost pro­por­cjo­nal­na do cza­su trwa­nia (ilo­ści) takich warsz­ta­tów. Konsultanci zara­bia­ją też pro­por­cjo­nal­nie (koszt dnia pra­cy) a przy­szli użyt­kow­ni­cy zgła­sza­ją coraz to now­sze pomy­sły (z cza­sem coraz bar­dziej z poza zakre­su projektu).

Alternatywą dla tych zja­da­ją­cych czas i pie­nią­dze warsz­ta­tów jest ana­li­za doku­men­tów ope­ra­cyj­nych. Zawierają one z regu­ły ok. 80% wszyst­kich istot­nych infor­ma­cji (orga­ni­za­cji z zasa­dy doku­men­tu­ją istot­ne dla nich rze­czy), w toku pra­cy nad tymi doku­men­ta­mi moż­na wychwy­cić ewen­tu­al­ne bra­ki (to co jest reali­zo­wa­ne nie­for­mal­nie a war­to jed­nak zacząć doku­men­to­wać) oraz nie­po­trzeb­ne już doku­men­ty (zmie­nio­no pro­ce­du­ry a nie wyco­fa­no wzo­rów doku­men­tów). Wszelkie wąt­pli­wo­ści moż­na wyja­śniać tele­fo­nicz­nie lub na krót­kich spo­tka­niach w czte­ry oczy” z kon­kret­ną oso­bą, eks­per­tem z danej dzie­dzi­ny, kie­row­ni­kiem dzia­łu itp. Co cie­ka­we, tą meto­dą moż­na ana­li­zę z góry wyce­nić (licz­ba doku­men­tów do ana­li­zy jest skoń­czo­na więc zakres pra­cy tak­że) i pod­pi­sać z ana­li­ty­kiem umo­wę fixed price”.

Pracując w ten spo­sób uni­ka­my tak­że wszel­kich naci­sków ze stro­ny uczest­ni­ków spo­tkań. W trak­cie typo­wych zbio­ro­wych warsz­ta­tów i burz mózgów, bar­dzo czę­sto nie­ste­ty mają miej­sce, ze stro­ny uczest­ni­ków tych spo­tkań, uda­ne pró­by prze­my­ca­nia dodat­ko­wych nie­uza­sad­nio­nych upraw­nień, obro­na sta­tus quo na swo­im sta­no­wi­sku itp. Badanie doku­men­tów ope­ra­cyj­nych jest wol­ne od tego ryzy­ka. Wyjaśnianiu pod­le­ga­ją wyłącz­nie nie­ści­sło­ści w doku­men­tach. Na ich pod­sta­wie powsta­ją mode­le pro­ce­sów biz­ne­so­wych, wzo­ry doku­men­tów w tych pro­ce­sach itp. Zgłaszanie uwag do powsta­ją­cej doku­men­ta­cji ana­li­tycz­nej jest znacz­nie efek­tyw­niej­sze niż wal­ka o każ­de jej zda­nie w trak­cie warsz­ta­tów, jest tak­że znacz­nie tań­sze, bo tak zwa­ni eks­per­ci dzie­dzi­no­wi klien­ta oraz przy­szli użyt­kow­ni­cy, pra­cu­ją nad swo­imi uwa­ga­mi w chwi­lach wol­nych (nie są to narzu­co­ne ter­mi­ny spo­tkań) i zaj­muj im to znacz­ne mniej cza­su (nie musza z nikim się spie­rać). Dodatkową zale­tą jest pisem­ny ślad po każ­dej zmia­nie, po każ­dym nowym zgło­sze­niu (każ­dy sam spi­su­je swo­je uwa­gi i propozycje).

Owszem, w wie­lu orga­ni­za­cjach jest ogrom­na nie­chęć do takiej pra­cy ale zary­zy­ku­ję tezę, że jedy­nym powo­dem tej nie­chę­ci jest nie­lu­bia­na przez część ludzi odpo­wie­dzial­ność za każ­de swo­je sło­wo. Ta meto­da pra­cy wyklu­cza zbio­ro­wą odpo­wie­dzial­ność za wyni­ki zbio­ro­wo pro­wa­dzo­nej ana­li­zy wymagań.

Tą meto­da pra­cu­je już kil­ka lat, korzy­sta­jąc z elek­tro­nicz­ne­go repo­zy­to­rium doku­men­tów i sys­te­mu obie­gu doku­men­tów i tre­ści (nie korzy­stam z pocz­ty elek­tro­nicz­nej do pro­wa­dze­nia pro­jek­tów z uwa­gi na bała­gan jaki wprowadza!).

Od oko­ło dwóch lat dys­po­nu­ją bar­dzo dobrym narzę­dziem, któ­re pozwa­la na płyn­ną zdal­ną inte­rak­tyw­ną pra­cę, już nie na pozio­mie kolej­nych wer­sji wysy­ła­nej wyni­ko­wej ana­li­zy, a na pozio­mie poje­dyn­czych dia­gra­mów i ich opi­sów. Jest to bez­piecz­ne opro­gra­mo­wa­nie pozwa­la­ją­ce mi, ana­li­ty­ko­wi, zdal­nie pre­zen­to­wać bie­żą­ce efek­ty pra­cy i przyj­mo­wać na bie­żą­co uwa­gi. Narzędzia te opi­sa­łem tu:

Dla utrzy­ma­nia wyso­kiej jako­ści efek­tów pra­cy sto­su­ję spraw­dzo­ne na ryn­ku opro­gra­mo­wa­nie fir­my Visual-Paradigm. W moich pro­jek­tach nie są wyko­rzy­sty­wa­ne do pra­cy żad­ne bez­płat­ne czy spo­łecz­no­ścio­we zaso­by Internetu, gdyż dostaw­cy tych usług nie bio­rą za nie odpo­wie­dzial­no­ści, ogra­ni­cza­ją, a nie raz przej­mu­ją, pra­wa do prze­trzy­my­wa­nych tam doku­men­tów i tre­ści. Z opro­gra­mo­wa­nia fir­my Visual-Paradigm korzy­sta­ją naj­więk­sze kon­cer­ny na świe­cie (lista wybra­nych użyt­kow­ni­ków pakie­tu Visual-Paradigm. Nagrody dla Visual Paradigm). (Źródło: Analiza Biznesowa – narzę­dzia CASE, Visual-Paradigm | Jarosław Żeliński IT-Consulting)

Okazuje się, że moż­na pro­wa­dzić zwin­nie nawet takie ana­li­zy, oszczę­dzić czas człon­ków zespo­łu i innych uczest­ni­ków pro­jek­tu (tak­że inte­re­sa­riu­szy, któ­rzy mogą brać udział w takiej pra­cy). Zalety opi­sa­ne w cyto­wa­nym na począt­ku arty­ku­le mogę tyl­ko potwier­dzić. Owszem nie raz spo­ty­kam się z fir­ma­mi, któ­rych pra­cow­ni­cy pre­fe­ru­ją spo­tka­nia nad pisanie.

Kluczowym powo­dem nie­chę­ci do pisa­nia jest utra­ta moż­li­wo­ści naci­sku na ana­li­ty­ka, w celu pozy­ska­nia korzyst­nych dla sie­bie, a nie koniecz­nie dla spon­so­ra pro­jek­tu, zapi­sów w doku­men­ta­cji. Po dru­gie gru­po­we spo­tka­nia i warsz­ta­ty dra­stycz­nie roz­my­wa­ją odpo­wie­dzial­ność za udzie­la­ne informacje.

Opór przed pisa­niem to naj­czę­ściej nie­chęć do pozo­sta­wia­nia śla­dów po swo­ich uwa­gach i pro­po­zy­cjach. W wie­lu fir­mach i insty­tu­cjach publicz­nych spo­ty­kam się z ogrom­ną nie­chę­cią do takiej pra­cy. Zbiorowe spo­tka­nia i warsz­ta­ty pozo­sta­wia­ją po sobie listę życzeń, pod nią listę obec­no­ści ale nie wia­do­mo kto co zgło­sił, a to pro­wa­dzi do zupeł­ne­go bra­ku odpo­wie­dzial­no­ści uczest­ni­ków takich warsz­ta­tów za treść nota­tek jakie na nich powstają.

Tak, meto­da­mi zbio­ro­wych warsz­ta­tów, powsta­ją z regu­ły doku­men­ty bar­dzo niskiej jako­ści, bar­dzo pra­co­chłon­ne, będą­ce mało mery­to­rycz­nym zgni­łym kom­pro­mi­sem, zawie­ra­ją masę nie­spój­no­ści, są strasz­nie nad­mia­ro­we. Nie raz są to doku­men­ty mają­ce, po ok. roku albo i wię­cej pra­cy! nawet kil­ka tysię­cy stron!… któ­rych z regu­ły już nikt nigdy nie czyta!

Dobra doku­men­ta­cja ana­li­ty­ka biz­ne­so­we­go w tym wyma­ga­nia, to ok. 50 – 100 stron (naj­więk­sze moje pro­jek­ty to ok. 200 str. w tym ponad 50% to dia­gra­my) zawie­ra­ją­ce opis (mode­le) logi­ki dzia­ła­nia orga­ni­za­cji i logi­ki jaką ma reali­zo­wać przy­szłe opro­gra­mo­wa­nie. Szczegóły tech­nicz­ne (w tym model danych!) powi­nien opra­co­wać dopie­ro wyko­naw­ca, na eta­pie ana­li­zy wyma­gań (kon­cep­cja imple­men­ta­cji i wdro­że­nia), nie ma sen­su zbyt wcze­sne żąda­nie” kon­kret­nych tech­no­lo­gii, tech­no­lo­gia jest kon­se­kwen­cją wyma­gań poza-funk­cjo­nal­nych. Przypomnę, że wyma­ga­nia to warun­ki jakie ma speł­nić opro­gra­mo­wa­nie a nie deta­licz­ny pro­jekt. Owszem logi­ka dzia­ła­nia biz­ne­su, w posta­ci mode­lu dzie­dzi­ny, jak naj­bar­dziej powin­na powstać, bo to jest wyma­ga­nie: taki ma być mecha­nizm dzia­ła­nia” zama­wia­nej aplikacji.

Mam świa­do­mość, że nie wszę­dzie zasto­so­wa­nie zdal­nej pra­cy jest moż­li­we ale takich przy­pad­ków jest mało. Podstawą i wystar­cza­ją­cym ele­men­tem jest wola po stro­nie zama­wia­ją­ce­go taką usłu­gę, mam tu na myśli spon­so­ra pro­jek­tu czy­li zarząd fir­my. Zapraszam do kon­tak­tu.

A po co nam ten SWOT

W poprzed­nim arty­ku­le (Ile jest tych wyma­gań na sys­tem ERP) pisa­łem, że nad­mier­ne sku­pia­nie się na szcze­gó­łach nie tyl­ko nie wno­si nicze­go do pro­jek­tu ale nie raz wręcz go nisz­czy. Dotyczy to zresz­tą ogól­nie pro­jek­tów ana­li­tycz­nych, nie tyl­ko w dzie­dzi­nie IT.

Na stro­nach jed­ne­go z bar­dziej poczyt­nych ser­wi­sów o ana­li­zie IT – http://​www​.moder​na​na​lyst​.com – poja­wił się jakiś czas temu cie­ka­wy arty­kuł o ana­li­zie SWOT. Autor opi­su­je jak tę ana­li­zę prze­pro­wa­dzić, ja opi­szę jak jej użyć w ana­li­zie sys­te­mo­wej orga­ni­za­cji i spe­cy­fi­ko­wa­niu wyma­gań. We wstę­pie arty­ku­łu czytamy:

Much of the busi­ness of busi­ness ana­ly­sis is in the deta­ils, and most busi­ness ana­ly­sts are by natu­re deta­iled, sys­te­ma­tic thin­kers. Occasionally most orga­ni­za­tions, tho­ugh, have times when they can?t see the forest for the tre­es. That is when the high-level, bro­ad-ran­ge view that SWOT Analysis affords is just as use­ful in avo­iding costly errors as unam­bi­gu­ous requ­ire­ments. (What is SWOT Analysis?).

W dużym uprosz­cze­niu: wie­lu ana­li­ty­ków sku­pia się od razu na szcze­gó­łach, bo to natu­ral­ne ele­men­ty nasze­go bez­po­śred­nie­go oto­cze­nia, nie potra­fią spoj­rzeć na orga­ni­za­cję z dale­ka, nie potra­fią dostrzec lasu patrząc na poje­dyn­cze drze­wa”. Analiza SWOT pozwa­la spoj­rzeć na pro­blem z innej, wyż­szej per­spek­ty­wy, sze­rzej, dzię­ki cze­mu jest bar­dzo uży­tecz­na w uni­ka­niu kosz­tow­nych błę­dów jaki­mi są nie­jed­no­znacz­ne wymagania. 

Jednym z zabój­ców pro­jek­tów” (a kon­kret­nie ich budże­tów i har­mo­no­gra­mów) są tak zwa­ne wyma­ga­nia osie­ro­co­ne i wyma­ga­nia nie­od­kry­te na eta­pie ana­li­zy. Są to odpo­wied­nio wyma­ga­nia zgło­szo­ne do spe­cy­fi­ka­cji i zre­ali­zo­wa­ne, z któ­rych następ­nie nikt nie korzy­sta, oraz te odkry­wa­ne dopie­ro na eta­pie wdro­że­nia. Nie da się zapro­jek­to­wać” lasu myśląc o drze­wach bo celem jest las, a nie kon­kret­ne drzewa. 

Jeden pro­jekt może mieć jeden cel, jeże­li jed­nak celem” ma być każ­dy kolej­ny krok, podróż nigdy się nie kończy.

Wymagania o jakich pisa­łem w poprzed­nim arty­ku­le to wyma­ga­nia wobec roz­wią­za­nia, któ­rym było jakieś opro­gra­mo­wa­nie”. Jednak to dru­gi etap ana­li­zy. Generalnie naj­pierw ana­li­zu­je się i defi­niu­je wyma­ga­nia biz­ne­so­we, a potem dopie­ro wyma­ga­nia wobec roz­wią­za­nia, wie­dząc już jakie warun­ki musi ono speł­niać. Przykładowym wyma­ga­niem biz­ne­so­wym może być pod­nie­sie­nie jako­ści obsłu­gi klien­ta (co by to tu teraz nie mia­ło zna­czyć), a dopie­ro reko­men­do­wa­nym roz­wią­za­niem może być, np. opro­gra­mo­wa­ne CRM albo reor­ga­ni­za­cja dzia­łu sprze­da­ży (co z resz­tą wie­le firm robi znacz­nie czę­ściej niż kupu­je nowy CRM ;)).

Wiele firm rzu­ca się na pro­jek­ty od razu z zało­że­niem, że musi­my mieć nowe opro­gra­mo­wa­nie”. Co nie raz bywa dużym błę­dem i masą zmar­no­wa­nych środ­ków. Jak się przed tym ustrzec?

Warto popa­trzeć na orga­ni­za­cję i kon­kret­ny pro­blem z pew­nej per­spek­ty­wy, z wyż­sze­go pozio­mu abs­trak­cji, niż tyl­ko sto­jąc mię­dzy biur­ka­mi widząc kon­kret­ne spra­wy i ludzi się nimi zaj­mu­ją­cy­mi. Narzędziem pozwa­la­ją­cym wznieść” się na wyż­szy poziom abs­trak­cji jest wła­śnie ana­li­za SWOT. Analiza ta pole­ga na ziden­ty­fi­ko­wa­niu czte­rech klu­czo­wych ele­men­tów wpły­wa­ją­cych na orga­ni­za­cję : czyn­ni­ki zewnętrz­ne jaki­mi są oka­zje i zagro­że­nia oraz czyn­ni­ki wewnętrz­ne czy­li sil­ne i sła­be stro­ny orga­ni­za­cji. Tu waż­na infor­ma­cja, ana­li­za SWOT to ana­li­za cze­goś kon­kret­ne­go” w okre­ślo­nym śro­do­wi­sku”. Czynniki wewnętrz­ne opi­su­ją to coś”, zaś czyn­ni­ki zewnętrz­ne opi­su­ją śro­do­wi­sko tego cze­goś”. Można tak ana­li­zo­wać orga­ni­za­cję (np. fir­ma i jej oto­cze­nie ryn­ko­we) czy też pro­duk­ty pro­jek­tów (np. kon­kret­ne opro­gra­mo­wa­nie w fir­mie) ale nie sam pro­jekt wdro­że­nio­wy czy pro­ces (one nie są czymś”).

Analiza SWOT może być ele­men­tem ana­li­zy sys­te­mo­wej orga­ni­za­cji. Analiza SWOT to np. wstęp do opra­co­wa­nia reko­men­da­cji w odpo­wie­dzi na pro­blem biz­ne­so­wy. SWOT to iden­ty­fi­ka­cja i wpływ okre­ślo­nych ele­men­tów, pozo­sta­je oce­na tego jaki, i na co. Dlatego ana­li­za SWOT sta­ła się czę­ścią tak zwa­ne­go Modelu Motywacji Biznesowej (BMM). Model ten pozwa­la lepiej zro­zu­mieć oto­cze­nie pro­ble­mu” oraz śla­do­wać” ele­men­ty ziden­ty­fi­ko­wa­ne w ana­li­zie SWOT na kon­kret­ne pro­ce­sy biz­ne­so­we i struk­tu­rę organizacyjną.

SWOT

(dia­gram BMM: ana­li­za SWOT i przej­ście na pro­ce­sy biz­ne­so­we opr. wła­sne autora).

Z poprzed­nich moich arty­ku­łów wie­my, że wyma­ga­nia wobec roz­wią­za­nia (w tym wobec opro­gra­mo­wa­nia) mają swo­je źró­dło w pro­ce­sach biz­ne­so­wych i ich wyko­naw­cach. Jednak spi­sa­nie ich w posta­ci dekla­ra­tyw­nej listy pod­czas warsz­ta­tów i wywia­dów, pro­wa­dzi do powsta­nia dłu­giej i prak­tycz­nie nie­we­ry­fi­ko­wal­nej listy o jakiej pisa­łem w Ile jest tych wyma­gań na sys­tem ERP.

Lekarstwem na pro­blem jest wery­fi­ka­cja (two­rze­nie) listy wyma­gań wobec roz­wią­za­nia. Weryfikacja (dia­gram powy­żej) pole­ga na tak zwa­nym śla­do­wa­niu. Śladowanie to wywo­dze­nie każ­de­go wyma­ga­nia z pier­wot­nej potrze­by, jaką jest tak­ty­ka, któ­rą przy­ję­to by osią­gnąć cel. Taktyka ma swo­je źró­dło w stra­te­gii (tak­ty­ka imple­men­tu­je stra­te­gię). Strategia (jej skon­stru­owa­nie) jest odpo­wie­dzią na oka­zję ryn­ko­wą, któ­ra jest przy­czy­ną, dla któ­rej podej­mu­je­my dzia­ła­nia ryn­ko­we. Okazja ryn­ko­wa daje szan­sę na zysk” (pro­dukt dają­cy docho­dy) w posta­ci dostar­cze­nia swo­je­mu oto­cze­niu war­to­ści doda­nej. Warto tu zwró­cić uwa­gę na to, że ele­men­ty ana­li­zy SWOT tak­że powin­ny mieć swo­je uza­sad­nie­nie w posta­ci iden­ty­fi­ka­cji zewnętrz­nych i wewnętrz­nych czyn­ni­ków wpły­wu. Słabe stro­ny oraz zagro­że­nia powin­ny iden­ty­fi­ko­wać ryzy­ka pro­jek­tu. Analizę uzna­je­my za zakoń­czo­ną po ziden­ty­fi­ko­wa­niu wszyst­kich zna­nych klu­czo­wych czyn­ni­ków wpły­wu i ryzyk. Analiza taka jest ele­men­tem ana­li­zy sys­te­mo­wej orga­ni­za­cji.

Wielu wła­ści­cie­li firm, ich zarzą­dy, pomi­ja ten etap w pro­jek­tach z uwa­gi na swo­je prze­ko­na­nie, że ich dotych­cza­so­we dzia­ła­nia i chęć ich kon­ty­nu­acji, nie wyma­ga­ją żad­nej korek­ty, ocze­ku­ją poda­nia na tacy opi­su narzę­dzia, któ­re­go – jak sądzą – potrze­bu­ją. Zachowują się jak pacjen­ci, któ­rzy mimo, że ostat­nie bada­nia robi­li wie­le lat temu, nie dopusz­cza­ją myśli, że lekarz może im prze­pi­sać na gorącz­kę coś inne­go niż kolej­ną aspi­ry­ną. Bywa, że zbyt póź­no odkry­wa­ją, że tym razem to nie było kolej­ne przeziębienie.

Praktyka poka­zu­je, coś bar­dzo cie­ka­we­go: zamiast pro­wa­dzić żmud­ne i kosz­tow­ne wywia­dy, sesje warsz­ta­to­we, burze mózgów, któ­rych pro­duk­tem jest dłu­ga lista dość przy­pad­ko­wych pomy­słów na wyma­ga­nia”, war­to docho­dzić do listy wyma­gań meto­dą od ogó­łu do szcze­gó­łu, wła­śnie od pozio­mu ana­li­zy SWOT (opar­tej na wizji i misji orga­ni­za­cji). Takie podej­ście od razu, naj­krót­szą dro­gą, pro­wa­dzi – przez model pro­ce­sów biz­ne­so­wych – do bar­dzo spój­nej i kom­plet­nej, bez nad­mia­ro­wych (osie­ro­co­nych) wyma­gań, spe­cy­fi­ka­cji wyma­gań wobec roz­wią­za­nia. Każde wyma­ga­nie ma swo­je uza­sad­nie­nie (śla­do­wa­nie) w stra­te­gii, nie ma ryzy­ka, że coś pomi­nie­my, bo tu wery­fi­ka­to­rem jest model pro­ce­su (kom­plet­na i spraw­dzo­na lista czyn­no­ści). Koszty uzy­ska­nia spe­cy­fi­ka­cji wyma­gań tą meto­dą, są znacz­nie niż­sze niż tra­dy­cyj­ny­mi (wywia­dy) meto­da­mi bo: nie anga­żu­je­my cza­su całych zespo­łów pra­cow­ni­ków na wywia­dy i warsz­ta­ty, ryzy­ko bar­dzo kosz­tow­nych pomi­nięć i nad­mia­rów jest mini­mal­ne, licz­ba ite­ra­cji w takim pro­jek­cie zbli­ża się do JEDNEJ! i nie trze­ba odkry­wać wyma­gań meto­dą kosz­tow­nych pro­to­ty­pów na eta­pie przed­wcze­snej imple­men­ta­cji. Jedyny pro­blem” to jej prze­pro­wa­dze­nie, mimo poku­sy”, roz­po­czę­cia pro­jek­tu od razu bo nie ma cza­su na ana­li­zę, i szko­da na to pieniędzy”.

UML MDA czyli od biznesu do projektu logiki systemu

(arty­kuł uzu­peł­nio­ny w 2019 r.) 

Kolejna god­na pole­ce­nia książ­ka na ryn­ku. Nie mia­łem cza­su by wcze­śniej ją opi­sać ale w koń­cu uda­ło się. Ale od począt­ku, wró­ci­my do niej.

To co naj­czę­ściej wzbu­dza brak zaufa­nia to teza, że moż­na prze­pro­wa­dzić ana­li­zę i pro­jek­to­wa­nie opro­gra­mo­wa­nia na papie­rze”. Programiści w więk­szo­ści uwa­ża­ją, że to nie moż­li­we (rok temu na stro­nach tego blo­ga burz­li­wa dys­ku­sja z jed­nym z nich…). W więk­szo­ści przy­pad­ków pod­czas spo­tkań (kon­fe­ren­cje, pro­jek­ty itp.) z zespo­ła­mi pro­gra­mi­stów sły­szę: czy­ta­my wyma­ga­nia, kodu­je­my od razu i two­rzy­my kolej­ne wer­sje apli­ka­cji; ina­czej się nie da”. W przy­pad­ku szko­leń, ostat­nie­go dnia warsz­ta­tów naj­czę­ściej sły­szę: ooo, w cią­gu jed­ne­go dnia [teraz] powstał kom­plet­ny pro­jekt dzie­dzi­ny sys­te­mu [cho­dzi­ło o kom­po­nent], prze­te­sto­wa­ny i oczysz­czo­ny z wąt­pli­wo­ści, bra­ku logi­ki i nie­spój­no­ści, do tego łatwy w dal­szym roz­bu­do­wy­wa­niu; to co zro­bi­li­śmy teraz na dia­gra­mach UML w cią­gu dnia, jako zespół tra­dy­cyj­ną meto­dą robi­li­by­śmy co naj­mniej tydzień, bio­rąc pod uwa­gę kodo­wa­nie każ­de­go pomy­słu by go dać użyt­kow­ni­ko­wi do testów”. W zasa­dzie taki pro­ces ana­li­zy i pro­jek­to­wa­nia jest zna­ny od lat jako Model Driven Architecture (MDA):

W czym pro­blem? Nauczyć się pra­co­wać na mode­lach (abs­trak­cje sys­te­mu) a nie od razu na kodzie (a raczej poprze­dzić kodo­wa­nie ana­li­zą i pro­jek­to­wa­niem), nauczyć się wzor­ców pro­jek­to­wych i przede wszyst­kim obiek­to­we­go myśle­nia (para­dyg­ma­tu) czy­li ana­li­zy i pro­jek­to­wa­nia. Wykonanie – imple­men­ta­cja na koń­cu a nie na począt­ku (podob­nie jak baza danych: w meto­dach obiek­to­wych pro­jek­tu­je­my utrwa­la­nie na koń­cu!). Po dru­gie, nie­ste­ty, nie raz sły­sza­łem o dostaw­ców: nie mamy inte­re­su w tym by pro­jekt trwał krót­ko”, to jed­nak tyl­ko argu­ment za tym by nie zle­cać im pro­jek­to­wa­nia a tyl­ko realizację.

MDA to trzy klu­czo­we eta­py: CIM, PIM i PSM (szcze­gó­ło­wo opi­sa­łem w arty­ku­le o ana­li­zie). Interesuje mnie tu etap CIM (Computation Independent Model) i PIM (Platform Independent Model). Pierwszy to ana­li­za biz­ne­so­wa, nie ma ona nic wspól­ne­go z opro­gra­mo­wa­niem, jej celem jest zro­zu­mie­nie i udo­ku­men­to­wa­nie tego co robią przy­szli użyt­kow­ni­cy sys­te­mu oraz wska­za­nie zakre­su pro­jek­tu dostar­cze­nia opro­gra­mo­wa­nia. Drugi to PIM czy­li opra­co­wa­nie mode­lu logi­ki sys­te­mu bez wzglę­du na to w jakiej tech­no­lo­gii powsta­nie, tu mil­czą­cym zało­że­niem jest, że będzie to tech­no­lo­gia obiek­to­wa jed­nak język pro­gra­mo­wa­nia może być dowolny.

Dużą zale­tą tego podej­ścia jest to, że opra­co­wa­nie mode­lu PIM jako Opisu Przedmiotu Zamówienia (OPZ) jest zgod­ne z PZP (Prawo Zamówień Publicznych) bo nie deter­mi­nu­je imple­men­ta­cji ale dokład­nie opi­su­je ocze­ki­wa­nia. Uważam, że jest to naj­lep­szy spo­sób two­rze­nia OPZ, bo nie pozo­sta­wia dowol­no­ści w kwe­stii funk­cjo­nal­no­ści roz­wią­za­nia. Jaki mamy tu pro­blem? Należy oddzie­lić pro­jek­to­wa­nie od reali­za­cji czy­li mamy dwa eta­py pro­jek­tu zamiast jed­ne­go, dwóch wyko­naw­ców (ana­li­za i pro­jek­to­wa­nie oraz reali­za­cja). Wady? Nie, korzy­ści bo wyko­naw­ca i tak musi jakiś pro­jekt opra­co­wać, po dru­gie wyce­na na bazie pro­jek­tu jest dale­ko mniej ryzy­kow­na niż wyce­na na bazie kon­cep­cji”, zresz­tą skut­ki wszy­scy obser­wu­je­my na ryn­ku. Ale wra­ca­my do tematu :).

Proces od analizy do projektu

Dwa pierw­sze (CIM i PIM) to pierw­sze eta­py pro­ce­su powsta­wa­nia opro­gra­mo­wa­nia: Analiza Biznesowa i jej pro­dukt oraz pro­jek­to­wa­nie roz­wią­za­nia i jego pro­dukt. Między nimi ma miej­sce okre­śle­nie zakre­su, któ­re­go pro­duk­tem jest model przy­pad­ków uży­cia (od 2015 roku w UML 2.5.x ten dia­gram jest mode­lem uzupełniającym) 

Analiza biznesowa

Zgodnie z zale­ce­nia­mi opra­co­wu­je­my model CIM czy­li two­rzy­my model tego jak dzia­ła biz­nes”. Produktem tego eta­pu są mode­le pro­ce­sów biz­ne­so­wych (raczej [[BPMN]] niż [[UML]]). Muszą się one jed­nak cecho­wać usta­lo­nym pozio­mem abs­trak­cji (nie powin­ny być zbyt szcze­gó­ło­we) i muszą uwzględ­niać roz­dział kom­pe­ten­cji pra­cow­ni­ków (ich nie kom­pu­te­ry­zu­je­my) od ich spe­cy­ficz­nych dla danej orga­ni­za­cji i pro­ce­su (te będą wspie­ra­ne przez nowe opro­gra­mo­wa­nie). Dobrą prak­ty­ką jest poprze­dza­nie tego eta­pu (uzu­peł­nie­nie go) o ana­li­zę i model archi­tek­tu­ry kor­po­ra­cyj­nej. To jest ostat­ni gwiz­dek na wpro­wa­dza­nie ewen­tu­al­nych ulep­szeń zarzą­dza­nia (rein­ży­nie­ria pro­ce­sów) w orga­ni­za­cji. Kolejny etap to

Opracowanie modelu przypadków użycia

Przypadki uży­cia, usłu­gi sys­te­mu dla użyt­kow­ni­ków, to celo­we inte­rak­cje użyt­kow­ni­ka z sys­te­mem. Ich cechą powin­na być kom­plet­ność, bo przy­pa­dek uży­cia to reali­za­cja kon­kret­ne­go celu biz­ne­so­we­go przez użyt­kow­ni­ka. Poprawnie opra­co­wa­ny taki model pozwa­la mapo­wać czyn­no­ści z mode­lu pro­ce­sów wprost na przy­pad­ki uży­cia (ale nie koniecz­nie jeden do jed­ne­go, przy­pad­ków uży­cia może być mniej, bo ta sama usłu­ga sys­te­mu może posłu­żyć do reali­za­cji kil­ku celów biz­ne­so­wych, np. utwo­rze­nia danych jak i ich pod­glą­du czy korek­ty, przy­kła­dem mogą być tak zwa­ne [[CRUD]]«y) (klik­nij tu by zoba­czyć to na przy­kła­dzie narzę­dzia jakie­go uży­wam).

Każda czyn­ność kan­dy­du­ją­ca na przy­pa­dek uży­cia powin­na być opi­sa­na sce­na­riu­szem jej reali­za­cji opi­su­ją­cym jak pla­nu­je­my tę usłu­gę zre­ali­zo­wać. Jest to tak zwa­ny dia­log użyt­kow­nik-sys­tem. Model przy­pad­ków uży­cia to tak­że defi­ni­cja zakre­su pro­jek­tu pro­gra­mi­stycz­ne­go (robi­my to i tyl­ko to).

Opracowanie modelu dziedziny

Specyfikacja usług sys­te­mu (przy­pad­ki uży­cia) to tak zwa­ne wyma­ga­nia funk­cjo­nal­ne. Jest to sta­now­czo za mało by cokol­wiek (w szcze­gól­no­ści opro­gra­mo­wa­nie) mogło powstać. Problem w tym, że samo stwier­dze­nie sys­tem ma wcią­gać śmie­ci” nijak się nie ma do kon­struk­cji urzą­dze­nia jakim jest odku­rzacz. Wymaganie poza­funk­cjo­nal­ne, że ma ich wcią­gać co naj­mniej 90%” tak­że nic nie mówi o tym co na praw­dę ma zostać wytwo­rzo­ne. Brakuje PROJEKTU.

Takim pro­jek­tem jest model dzie­dzi­ny, jed­nak nie jest to dia­gram klas na któ­rym poka­że­my, że np. ist­nie­je zwią­zek logicz­ny brud­ne­go dywa­nu z odku­rza­czem! bo to jest tyl­ko model poję­cio­wy (słow­nik pojęć). Model dzie­dzi­ny sys­te­mu to model dzie­dzi­no­wej logi­ki jaką nale­ży odwzo­ro­wać w opro­gra­mo­wa­niu. Owszem, jest to tak­że Diagram klas UML, ale zupeł­nie inny niż tak zwa­ny model kon­cep­tu­al­ny, któ­ry po pro­stu jest tyl­ko słow­ni­kiem (i czę­sto jest mylo­ny z mode­lem danych!).

Model dzie­dzi­ny sys­te­mu to sed­no ana­li­zy obiek­to­wej. To model całej logi­ki biz­ne­so­wej apli­ka­cji: kla­sy, ich ope­ra­cje i atry­bu­ty. Nie powi­nien to być na pew­no tak zwa­ny [[ane­micz­ny model dzie­dzi­ny]] a nie­ste­ty takie wła­śnie są one w więk­szo­ści pro­jek­tów jakie widuję.

Na tym eta­pie, mode­lo­wa­nie dzie­dzi­ny sys­te­mu, powsta­ją suche” kla­sy, bez metod i atry­bu­tów (tak, bez atry­bu­tów!). W pro­jek­tach zło­żo­nych sys­te­mów, powsta­nie mode­lu dzie­dzi­no­we­go powin­no być poprze­dzo­ne powsta­niem mode­lu kom­po­nen­tów (tak­że sto­sow­ny dia­gram UML), któ­ry jest pośred­nią war­stwą abs­trak­cji w takich pro­jek­tach. W takim przy­pad­ku począt­ko­wo ope­ru­je­my prak­tycz­nie tyl­ko na kla­sach abs­trak­cyj­nych i ich inter­fej­sach (są to inter­fej­sy tych komponentów).

Projektowanie realizacji czyli testowanie modelu dziedziny

Mając model dzie­dzi­ny, czy­li listę spe­cja­li­zo­wa­nych wyko­naw­ców” kon­kret­nych prac, może­my przy­stą­pić do testów sce­na­riu­szy przy­pad­ków uży­cia. Takim testem jest pró­ba zre­ali­zo­wa­nia sce­na­riu­sza przy­pad­ku uży­cia z pomo­cą obiek­tów mode­lu dzie­dzi­ny. Na tym eta­pie powsta­je dia­gram sekwen­cji (lub ste­ro­wa­nia inte­rak­cją, prze­pły­wu inte­rak­cji) dla każ­de­go przy­pad­ku uży­cia. Dobrą prak­ty­ką jest sto­so­wa­nie tu dia­gra­mów prze­pły­wu inte­rak­cji. Służą one do mode­lo­wa­nie nie­try­wial­nych przy­pad­ków uży­cia, prze­pły­wu sce­na­riu­szy alter­na­tyw­nych, ekra­nów itp.

W trak­cie two­rze­nia dia­gra­mu sekwen­cji pro­jek­to­wa­ne są ope­ra­cje klas (meto­dy to ich reali­za­cje). Diagram sekwen­cji opi­su­je dia­log pomię­dzy obiek­ta­mi pro­wa­dzą­cy do zre­ali­zo­wa­nia zada­nia, jakim jest cel przy­pad­ku uży­cia (jego stan koń­co­wy). Dialog taki to nic inne­go jak wywo­ła­nia ope­ra­cji obiek­tów przez inne obiek­ty (lub wła­snych). Po opra­co­wa­niu dia­gra­mu sekwen­cji obiek­ty, któ­re bra­ły w niej udział wzbo­ga­cą” się w pro­jek­cie o swo­je ope­ra­cje. Na tym eta­pie może się oka­zać, że pew­ne obiek­ty zmie­nia­ją swo­je sta­ny. Dla ich klas pro­jek­tu­je­my dia­gra­my maszy­ny sta­no­wej. Jeżeli oka­że się, że jakiś obiekt wyko­nu­je nie­try­wial­ne zada­nia (obli­cze­nio­we, zło­żo­ny pro­ces itp.), jego ope­ra­cję, któ­ra za to odpo­wia­da, doku­men­tu­je­my z pomo­cą np. dia­gra­mu czyn­no­ści – taki algo­rytm to Metoda danej Operacji. Za każ­dym razem spraw­dza­my zgod­ność z ocze­ki­wa­nia­mi użyt­kow­ni­ka i uzu­peł­nia­my kla­sy o nie­zbęd­ne atry­bu­ty, w szcze­gól­no­ści, jeże­li repre­zen­tu­ją one doku­men­ty czy formularze.

Projekt wykonany

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 architekta).

Poniżej pro­duk­ty takiej ana­li­zy i pro­jek­to­wa­nia w posta­ci dia­gra­mów (mode­li), pierw­szy to BPMN, pozo­sta­łe UML:

Aby zoba­czyć jak to zro­bić pakie­tem Agilian obej­rzyj Tutorial pakie­tu Visual-Paradigm Agilian

A teraz lektura Craig’a Larman’a

Larman w swo­jej książ­ce opi­su­je nie­mal­że iden­tycz­ne podej­ście (tabe­la poni­żej). Kluczową róż­ni­cą jest jed­nak źró­dło infor­ma­cji pier­wot­nej. U Larman’a jest to model przy­pad­ków uży­cia i ich sce­na­riu­sze. W porów­na­niu z mode­lem biz­ne­so­wym, pod­le­ga­ją­cym testo­wa­niu czy wali­da­cji, całe ryzy­ko pro­jek­tu spo­czy­wa na jako­ści mode­lu przy­pad­ków uży­cia. Jeżeli powsta­ły one jako efekt np. burzy mózgów, ankie­to­wa­nia pra­cow­ni­ków zama­wia­ją­ce­go czy tak zwa­nych sesji JAD ([[Joint Application Development]]), jest bar­dzo praw­do­po­dob­ne, że całe ryzy­ko złej jako­ści takie­go mode­lu (a jest ono bar­dzo duże jak poka­zu­je prak­ty­ka) zosta­nie prze­nie­sio­ne na projekt.

To jest wła­śnie pro­blem nazy­wa­ny użyt­kow­nik nie wie cze­go chce”. Po to się robi ana­li­zy biz­ne­so­we by w koń­cu wie­dział. Nie zmie­nia to fak­tu, że książ­kę Larman’a gorą­co pole­cam każ­de­mu pro­jek­tan­to­wi i pro­gra­mi­ście z ambi­cja­mi na meto­dy obiek­to­we i wzor­ce projektowe.

Larman’s UML Process

Use Cases
  • Define user inte­rac­tion with the system.
  • Underline nouns to iden­ti­fy con­cepts in the pro­blem domain.
Conceptual Model
  • Use the under­li­ned nouns from the use cases to cre­ate the con­cepts in the con­cep­tu­al model.
  • Some of the nouns, if they iden­ti­fy sim­ple data types, are used to cre­ate attri­bu­tes of the­se concepts.
  • Create asso­cia­tions betwe­en the concepts.
System Sequence Diagram
  • Create sys­tem sequ­en­ce dia­grams for each use case scenario.
  • Each sequ­en­ce event in the dia­gram cor­re­sponds to a user inte­rac­tion with the sys­tem spe­ci­fied by the expan­ded use case.
System Contracts
  • Specify post-con­di­tions for each sys­tem event in the sys­tem sequ­en­ce diagrams.
  • Use the con­cep­tu­al model to iden­ti­fy objects cre­ated, asso­cia­tions for­med, and attri­bu­tes modified.
Collaboration Diagram
  • Create a col­la­bo­ra­tion (or sequ­en­ce) dia­gram for each sys­tem event in the sys­tem sequ­en­ce diagrams.
  • Assign respon­si­bi­li­ties to clas­ses in the con­cep­tu­al model to ful­fill the post-con­di­tions in the contracts.
  • Use asso­cia­tions from the con­cep­tu­al model in con­junc­tion with pat­terns (Expert, Creator) to assign responsibilities.
Class Diagram
  • Add methods and addi­tio­nal attri­bu­tes which were disco­ve­red in the col­la­bo­ra­tion dia­grams to the clas­ses in the con­cep­tu­al model.
Code
  • Create clas­ses with the­ir names, attri­bu­tes and method signa­tu­res taken from the class diagram.
  • For each method on a class, use the col­la­bo­ra­tion dia­grams to find the sequ­en­ce of mes­sa­ges gene­ra­ted when the method is cal­led and cre­ate at least one line of code for each message.

(Based on Craig Larman’s Applying UML and Patterns -> Larman’s UML Process).

kon­wen­cje bar­dzo bli­ska powyż­szej (Larmana) opi­sa­no na stro­nach MSDN, tu wyciąg:

You can cre­ate seve­ral dif­fe­rent views of the users» requ­ire­ments. Each view pro­vi­des a par­ti­cu­lar type of infor­ma­tion. When you cre­ate the­se views, it is best to move fre­qu­en­tly from one to ano­ther. You can start from any view.

Diagram or document What it descri­bes in a requ­ire­ments model Section
Use case diagram Who uses the sys­tem and what they do with it. Describing how your sys­tem is used
Conceptual class diagram Glossary of types that are used to descri­be the requ­ire­ments; the types visi­ble at the sys­te­m’s interface. Defining terms used to descri­be requirements
Activity dia­gram Flow of work and infor­ma­tion betwe­en acti­vi­ties per­for­med by users and sys­tem or its parts. Showing work flow betwe­en users and your system
Sequence dia­gram Sequence of inte­rac­tions betwe­en users and sys­tem or its parts. An alter­na­ti­ve view to the acti­vi­ty diagram. Showing inte­rac­tions betwe­en users and your system
Additional docu­ments or work items Performance, secu­ri­ty, usa­bi­li­ty and relia­bi­li­ty criteria. Describing quali­ty of servi­ce requirements
Additional docu­ments or work items Constraints and rules not spe­ci­fic to a par­ti­cu­lar use case Showing busi­ness rules

Notice that most of the dia­gram types can be used for other pur­po­ses. For an ove­rview of dia­gram types, see Developing Models for Software Design. For basic infor­ma­tion abo­ut dra­wing dia­grams, seeHow to: Edit UML Models and Diagrams.

Na zakończenie

Powyżej opi­sa­ny pro­ces w cało­ści moż­na prze­ćwi­czyć wraz z pozna­niem wyma­ga­nych dia­gra­mów UML na warsz­ta­tach, któ­re pro­wa­dzę.

Serdecznie zapra­szam.