rd Ed: Agile Model Driven Development with UML 2 (i moje trzy grosze o UML)">

The Object Primer 3rd Ed: Agile Model Driven Development with UML 2 (i moje trzy grosze o UML)

Kolejna bar­dzo dobra książ­ka z obsza­ru pro­jek­to­wa­nia obiek­to­we­go. Poprzednia pozy­cja tego auto­ra (Agile Modeling. Effective…) trak­to­wa­ła o tym kie­dy, co i po co mode­lo­wać. Ta, to bar­dzo dobry kurs UML na przy­kła­dach. Tak, Scott Ambler (nie on jeden) uwa­ża, że mode­lo­wa­nie (szki­co­wa­nie) i testo­wa­nie pomy­słów jest tań­sze i szyb­sze na tabli­cy (papie­rze) niż w od razu w posta­ci kodu (przy­po­mnę, że jest on jed­nym z sygna­ta­riu­szy Agile Manifesto).

Ta książ­ka to jeden z lep­szych kur­sów metod obiek­to­wych i UML jaki mia­łem w rękach. Kluczem jest roz­dział o para­dyg­ma­cie obiek­to­wym, zro­zu­mie­nie obiek­tyw­no­ści i opis bazu­ją­cy na poję­ciach a nie kodzie. Większość auto­rów tego typu ksią­żek, to ludzie o pro­gra­mi­stycz­nym rodo­wo­dzie lub aktyw­ni pro­gra­mi­ści, obiek­to­wość postrze­ga­ją przez pry­zmat tak zwa­ne­go re-uży­cia kodu i kon­struk­cji kom­pi­la­to­rów, co jest kom­plet­nym nie­po­ro­zu­mie­niem, gdyż to języ­ki pro­gra­mo­wa­nia i kom­pi­la­to­ry (lepiej lub gorzej) imple­men­tu­ją para­dyg­mat obiek­to­wy a nie odwrotnie.

Ale nie był bym sobą, gdy­bym nie miał kil­ku uwag a raczej uzu­peł­nień, gdyż nale­ży zwró­cić uwa­gę, że książ­ka zosta­ła napi­sa­na w 2004 roku (o jej popu­lar­no­ści mogą świad­czyć dwa dodru­ki w 2005 roku). Ale po kolei.

Kilka uwag ode mnie

Popatrzmy na poniż­sze pojęcia:

rela­tion­ship – sto­su­nek do, powią­za­nie z (Oxford Dictionary: the way in which two or more things are con­nec­ted), (SJP powią­za­nie: wza­jem­na zależ­ność przy­czyn i skutków).

asso­cia­tion – dołą­cze­nie, sko­ja­rze­nie (Oxford Dictionary: a con­nec­tion betwe­en things whe­re one is cau­sed by the other), (SJP zwią­zek: sto­su­nek mię­dzy rze­cza­mi, zja­wi­ska­mi itp. połą­czo­ny­mi ze sobą w jakiś spo­sób, aso­cja­cja – auto­ma­tycz­ne sko­ja­rze­nie myślowe)

Jest wie­le nie­po­ro­zu­mień zwią­za­nych z tymi poję­cia­mi, ich angiel­skie i pol­skie tłu­ma­cze­nia są bli­sko spo­krew­nio­ne, dla­te­go war­to tu się­gnąć do źró­deł, czy­li spe­cy­fi­ka­cji (http://​www​.omg​.org/​s​p​e​c​/​U​ML/) a kon­kret­nie do czę­ści Infrastructure spe­ci­fi­ca­tion. Tam w roz­dzia­le 11.3 Classes Diagram, znaj­dzie­my mode­le poję­cio­we mię­dzy inny­mi związ­ków i dowie­my się, że aso­cja­cja (asso­cia­tion) dzie­dzi­czy po związ­ku (rela­tion­ship).

Popatrzmy na rodza­je powią­zań mię­dzy klasami:

Model obiektowy asocjacja a użycie

Zostały one usze­re­go­wa­ne od góry od naj­ogól­niej­sze­go. Nie będę uży­wał sło­wa rela­cja” bo w języ­ku pol­skim koja­rzy się (a ja zastrze­gam to w swo­ich doku­men­ta­cjach) z mode­lem danych, dia­gra­mem ERD (enti­ty rela­tion­ship dia­gram). Dlatego w UML mamy (jak wyżej):

A. aso­cja­cja, naj­ogól­niej­sza jej for­ma, ozna­cza powią­za­nie dwóch klas (w mode­lach poję­cio­wych jakie­kol­wiek),
B. aso­cja­cja skie­ro­wa­na, seman­tycz­nie poka­zu­je kie­ru­nek tego związ­ku, moż­na to inter­pre­to­wać tak, że kla­sa A wie o ist­nie­niu B, a kla­sa B nie wie o ist­nie­niu A (sło­wo wie” moż­na rozu­mieć tak­że jako ma w sobie zapi­sa­na taką infor­ma­cję”),
C. zwią­zek uży­cia (kolej­ny rodzaj związ­ku), seman­tycz­nie ozna­cza współ­pra­cę klas, tu kla­sa A korzy­sta z usłu­gi (wywo­łu­je ope­ra­cję) kla­sy B,
D. zwią­zek gene­ra­li­za ji, seman­tycz­nie ozna­cza, że kla­sa B jest spe­cjal­ną for­mą (spe­cja­li­za­cją) kla­sy A, lub że kla­sa A jest uogól­nie­niem kla­sy B, w mode­lu poję­cio­wym poję­cie A to uogól­nie­nie poję­cia B (pies jest uogól­nie­niem ratler­ka, lub ratle­rek, jest szcze­gól­nym przy­pad­kiem psa, kon­kret­ny Burek, jest instan­cją – wystą­pie­niem: obiek­tem – kla­sy ratle­rek),
E. zwią­zek reali­za­cji, seman­tycz­nie ozna­cza, że kla­sa B jest spe­cy­fi­ka­cją (spo­so­bem wyko­na­nia, reali­za­cji) abs­trak­cji jaką jest kla­sa A (np. inter­fejs jest reali­zo­wa­ny kon­kret­ną kla­są lub kom­po­nen­tem), reali­za­cja to nie jest for­ma dzie­dzi­cze­nia, jak twier­dzą nie­któ­rzy wykła­dow­cy i trenerzy :(.

Asocjacja jest naj­ogól­niej­szym związ­kiem (bez żad­nych dodat­ków repre­zen­tu­je jaki­kol­wiek zwią­zek). Warto też wie­dzieć, że związ­ki te są ina­czej reali­zo­wa­ne. Asocjacje, jako trwa­łe powią­za­nie klas (obiek­tów), to zapis w atry­bu­cie kla­sy. Związki uży­cia to wywo­ła­nia ope­ra­cji. Związki gene­ra­li­za­cji i reali­za­cji są związ­ka­mi abstrakcyjnymi. 

Przypadki użycia

UML to tak­że związ­ki gene­ra­li­za­cji na dia­gra­mach Przypadków Użycia (UC, ang. Use Case). Używanie ich jed­nak ma sens czy­sto poję­cio­wy, mimo to czę­sto widu­je kosz­mar­ki nazy­wa­ne nie raz dia­gram akto­rów”, gdzie np. pod­wład­ni dzie­dzi­czą” po swo­im prze­ło­żo­nym, co jest kom­plet­ną bzdu­rą. Menedżer rzad­ko ma umie­jęt­no­ści swo­ich pod­wład­nych, doty­czy to nie raz tak­że upraw­nień (szef zespo­łu praw­ni­ków nie raz nie ma upraw­nić rad­cow­skich czy adwo­kac­kich, żaden mój szef nie miał upraw­nień do infor­ma­cji taj­nej a ja mam od 2004 roku, itp.).

Kolejnym kosz­ma­rem jest sto­so­wa­nie dia­gra­mów UC do mode­lo­wa­nia upraw­nień. Generalnie upraw­nie­nia kogoś do cze­goś to regu­ła a nie sta­ty­stycz­ne trwa­łe powią­za­nie (nawet jeże­li jest to regu­ła dają­ca komuś do cze­goś pra­wo, jest to regu­ła a nie sta­ły zwią­zek dla­te­go, że upraw­nie­nia to coś co zawsze moż­na odebrać).

UML to tak­że związ­ki <extend> i <inc­lu­de>, a słu­żą one do mode­lo­wa­nia re-uży­cia kodu (o czym wspo­mi­na tak­że Ambler w tej książ­ce). Stosowanie ich na dia­gra­mach UC na eta­pie ana­li­zy i spe­cy­fi­ko­wa­nia wyma­gań jest tak­że bzdu­rą, gdyż o jakim­kol­wiek re-uży­ciu kodu moż­na mówić naj­wcze­śniej na eta­pie pro­jek­to­wa­nia imple­men­ta­cji. Po dru­gie mając w pla­nie wyko­na­nie mode­lu wewnętrz­nej struk­tu­ry apli­ka­cji (dia­gra­my klas i kom­po­nen­tów) mode­lo­wa­nie re-uży­cia kodu czy nawet re-uży­cia sce­na­riu­szy UC, jest pozba­wio­ne sen­su, bo jest nad­mia­ro­we i przed­wcze­sne. W razie wąt­pli­wo­ści pro­szę pod­jąć pró­bę sko­ja­rze­nia dia­gra­mów sekwen­cji z odpo­wia­da­ją­cy­mi im włą­czo­ny­mi (inc­lu­de) przy­pad­ka­mi użycia.

Dwa sło­wa na temat tak zwa­nych Systemowych przy­pad­ków uży­cia. Nie są to żad­ne wewnętrz­ne UC. Z zasa­dy UC to postrze­ga­na z zewnątrz (przez akto­ra sys­te­mu) usłu­ga sys­te­mu, moż­na się spo­tkać z tym poję­ciem (tu u Amblera tak­że) ale w kon­tek­ście, takim że sys­tem w rozu­mie­niu apli­ka­cja, reali­zu­je kon­kret­ne sce­na­riu­szo­we cele użyt­kow­ni­ka (akto­ra sys­te­mu). Innymi sło­wy usłu­gą sys­te­mu jakim jest np. mło­tek (to pro­sty sys­tem, ma dwa ele­men­ty: obuch i trzo­nek :)) jest ude­rza­nie, a wbi­ja­nie gwoź­dzia, wybi­ja­nie szy­by, ude­rza­nie w dzwon itp. to kon­tek­sty akto­ra. Jednak z per­spek­ty­wy defi­nio­wa­nia apli­ka­cji jest to jeden UC, ma jeden sce­na­riusz: weź do ręki mło­tek, ustal miej­sce ude­rze­nia, uderz, jeże­li nie osią­gną­łeś ocze­ki­wa­ne­go rezul­ta­tu, powtórz. 

Modelowanie tak zwa­nych sys­te­mo­wych przy­pad­ków uży­cia” jest tak­że pozba­wio­ne sen­su, gdyż dia­gram UC nie słu­ży do mode­lo­wa­nie wewnętrz­nej archi­tek­tu­ry sys­te­mu. Przypadki uży­cia to usłu­gi apli­ka­cji (pozy­cje w jej menu) i raczej jest jed­na usłu­ga np. Konfiguracja” a nie Ustaw, Włącz, Wyłącz, Zmień, itp… Te celo­we dzia­ła­nia to treść mody­fi­ko­wa­ne­go formularza.

Przypomnę, że książ­ka ta powsta­ła w 2004 roku (na co trze­ba brać popraw­kę czy­ta­jąc ją, poja­wia się w niej dzie­dzi­cze­nie), w cza­sie gdy nie było jesz­cze mowy o powszech­nym uży­ciu nota­cji BPMN, a dia­gra­my aktyw­no­ści są dość ułom­ne i zara­zem zbyt zło­żo­ne do tego celu (o czym świad­czy rosną­ca sta­le popu­lar­ność nota­cji BPMN i spa­dek popu­lar­no­ści dia­gra­mów czyn­no­ści do mode­lo­wa­nia pro­ce­sów biznesowych).

Niestety i w lite­ra­tu­rze i w mate­ria­łach szko­le­nio­wych, czy nawet dydak­tycz­nych na uczel­niach (o zgro­zo) moż­na się spo­tkać z taki­mi antyw­zor­ca­mi” jak wyżej. Jednym z naj­bar­dziej kurio­zal­nych jest obec­nie mode­lo­wa­nie danych z uży­ciem dia­gra­mu klas, nano­sząc na nie np. jesz­cze klu­cze głów­ne (zna­la­złem coś takie­go w pew­nym pod­ręcz­ni­ku aka­de­mic­kim!). Niestety bar­dzo czę­sto auto­rzy tych mate­ria­łów, wykła­dow­cy i tre­ne­rzy, zamiast korzy­stać ze źró­deł, prze­pi­su­ją jeden od dru­gie­go pogłę­bia­jąc marazm w tej dzie­dzi­nie, a pier­wo­wzo­rem wie­lu tych here­zji są nie­ste­ty mate­ria­ły publi­ko­wa­ne przez fir­mę SPARX (pro­du­cent opro­gra­mo­wa­nia Enterprise Architect) jak choć­by mój ulu­bie­niec: czas jako Aktor sys­te­mu (co opi­sa­łem tu).

Na zakończenie

Tak więc książ­kę Scott’a Amblera gorą­co pole­cam, ana­li­ty­kom szcze­gól­nie, pro­gra­mi­stom także.

The Object Primer 3rd EditionAgile Model Driven Development with UML 2Cambridge University Press, 2004 ISBN#: 0 – 521-54018 – 6 (Źródło: The Object Primer 3rd Ed: Agile Model Driven Development (AMDD) with UML 2)

Dlaczego śladowanie wymagań jest istotne w projekcie?

Wymagania to nie­wy­czer­pa­ny temat dys­ku­sji, blo­gów i spo­rów w pro­jek­tach. Ich śla­do­wa­nie już rza­dziej jest takim tema­tem, bo mało kto to robi, a to wła­śnie mię­dzy inny­mi brak śla­do­wa­nia pro­wa­dzi do pro­ble­mów w pro­jek­cie. Typowy pro­blem to utra­ta pano­wa­nia nad zakre­sem pro­jek­tu, utra­ta pano­wa­nia nad zło­żo­no­ścią doku­men­ta­cji i ilo­ści wyma­gań” (cudzy­słów celo­wo, póź­niej o powo­dach). W kon­se­kwen­cji jakość całe­go pro­jek­tu upa­da, zado­wo­le­nie spon­so­rów tak­że (pole­cam krót­ki wpis: Why is requ­ire­ments tra­ce­abi­li­ty impor­tant on a pro­ject?). Dlaczego? Bo sko­ro wyma­ga­nia mają być FURPS i SMART, to jak to osią­gnąć i jak skon­tro­lo­wać? Jak skon­tro­lo­wać w mie­rzal­ny spo­sób np. kompletność?

O wyma­ga­niach pisa­łem nie raz, dzi­siaj z per­spek­ty­wy ich śla­do­wa­nia i celu tego pro­ce­de­ru. Bardzo czę­sto spo­ty­ka się w doku­men­tach pro­jek­to­wych wyma­ga­nia funk­cjo­nal­ne i poza­funk­cjo­nal­ne, ale mało któ­ry z tych doku­men­tów zawie­ra defi­ni­cje tych pojęć, a wyma­gań tych są set­ki a nie raz tysią­ce. Są – te wyma­ga­nia” – zbie­ra­ne” naj­czę­ściej pod­czas wywia­dów, sesji burz mózgów, sesji warsz­ta­tów wyma­gań”. Ilość wyma­gań jest naj­czę­ściej pro­por­cjo­nal­na do cza­su trwa­nia tych sesji a ana­li­za wyma­gań” jest prze­ry­wa­na gdy wyma­gań jest wystar­cza­ją­co dużo” (widy­wa­łem doku­men­ty z ponad czte­re­ma tysią­ca­mi wymagań!).

W języ­ku pol­skim sło­wo wyma­ga­nie ma bar­dzo ści­słą i bar­dzo przy­dat­na definicję:

wyma­ga­nie ?waru­nek lub zespół warun­ków, któ­rym ktoś lub coś musi odpowiadać?

Popatrzmy co na to BABOK

PMBookRequirementDefiniction

Jest to defi­ni­cja bar­dzo bli­ska tej słow­ni­ko­wej: waru­nek lub moż­li­wość pro­duk­tu lub usłu­gi, speł­nia­ją­cy ocze­ki­wa­nia” (dość wol­ne tłumaczenie ;)).

A jak są kla­sy­fi­ko­wa­ne wyma­ga­nia? Tu jest bytów” jest więcej:

PMBookRequirementDefiniction2

Tu moim zda­niem zaczy­na się mała masa­kra, bo konia z rzę­dem temu, kto jed­no­znacz­nie podzie­li dłu­gą listę cech pro­duk­tu na powyż­sze sześć kuwe­tek”. Przypomnę, że popraw­ny słow­nik pojęć to poję­cia wza­jem­nie się wyklu­cza­ją­ce, czy­li jeże­li coś jest np. wyma­ga­niem, przej­ścio­wym to nie jest żad­nym innym. Dlatego ten (taki) podział jest moim zda­niem przy­czy­ną wie­lu pro­ble­mow w projektach.

Wymagania biznesowe

Rzadko spo­ty­ka­ne a wręcz koniecz­ne do popraw­nej kon­tro­li pro­jek­tu i zarzą­dza­nia jego zakre­sem. Inna defi­ni­cja, moim zda­niem lep­sza niż ta z BABOK’a:

Business Requirements

The pur­po­se of busi­ness requ­ire­ments is to defi­ne a project?s busi­ness need, as well as the cri­te­ria of its suc­cess. Business requ­ire­ments descri­be why a pro­ject is needed, whom it will bene­fit, when and whe­re it will take pla­ce, and what stan­dards will be used to eva­lu­ate it. Business requ­ire­ment gene­ral­ly do not defi­ne how a pro­ject is to be imple­men­ted; the requ­ire­ments of the busi­ness need do not encom­pass a project?s imple­men­ta­tion deta­ils. (Business Requirements – Requirements​.com).

To rza­dziej spo­ty­ka­na defi­ni­cja wyma­gań biz­ne­so­wych. W skró­cie: wyma­ga­nia biz­ne­so­we defi­ni­cją biz­ne­so­wy cel pro­jek­tu, kry­te­ria suk­ce­su (pomy­słu); wyma­ga­nia biz­ne­so­we opi­su­ją po co pro­jekt jest uru­cha­mia­ny; wyma­ga­nia biz­ne­so­we nie mówią nic o ich imple­men­ta­cji. I to jest pro­sta i bar­dzo sku­tecz­na w uży­ciu definicja.

Schody zaczy­na­ją się przy innych wyma­ga­niach, kolej­na wersja:

Functional requ­ire­ments are a type of solu­tion requ­ire­ments. According to BABOK, the­se descri­be the beha­vior and infor­ma­tion that the solu­tion will mana­ge.” Continuing with our far­ming illu­stra­tion, an exam­ple of a func­tio­nal requ­ire­ment would be: This sys­tem will deli­ver pro­du­ce from farms in our coope­ra­ti­ve and deli­ver it to par­ti­ci­pa­ting custo­mers.” (Requirements – Requirements​.com).

Wymagania funk­cjo­nal­ne. Najczęściej poda­je się jako wyma­ga­nia wobec roz­wią­za­nia” (i słusz­nie), jed­nak nie­ste­ty, defi­nio­wa­ne są poprzez przy­kład, np. stwier­dze­nie, że funk­cjo­nal­ność to zacho­wa­nie sys­te­mu i infor­ma­cje, któ­ry­mi sys­tem zarzą­dza” jest bar­dzo nie­for­tun­ne bo nie­zwy­kle pojem­ne, pro­wa­dzi wie­lu ana­li­ty­ków to wnio­sku, że sko­ro wysta­wie­nie fak­tu­ry wyma­ga nastu klik­nięć i wpro­wa­dze­nie nastu infor­ma­cji” to wyma­gań funk­cjo­nal­nych jest też naście”. Pojęcie funk­cjo­nal­ny” jest tak sze­ro­kie, że w zasa­dzie każ­da cecha pro­duk­tu do cze­goś słu­ży i jest jakąś funk­cjo­nal­no­ścią. Przeciętny samo­chód m ich set­ki a tak na praw­dę słu­ży do prze­miesz­cza­nia się.

Poszukajmy porząd­ku i spo­so­bu śladowania.

Wymagania biz­ne­so­we to cele uru­cha­mia­nia pro­jek­tu, to są cele orga­ni­za­cji (jej kadr kie­row­ni­czych). A resz­ta? Bardzo nie­pre­cy­zyj­ne defi­ni­cje wyma­gań pro­wa­dzą do setek ich inter­pre­ta­cji. Sam fakt, że te same wyma­ga­nia (jako nazwa i opis) są, przez róż­ne oso­by tego same­go zespo­łu pro­jek­to­we­go, róż­nie kla­sy­fi­ko­wa­ne, świad­czy o tym, że jest problem.

Z pomo­cą przy­cho­dzi śla­do­wa­nie, wymu­sza dopre­cy­zo­wa­nie defi­ni­cji. Dlaczego? Bo śla­do­wa­nie, by było moż­li­we do prze­pro­wa­dze­nia, wyma­ga prze­cho­dze­nia od jed­ne­go do dru­gie­go” w cało­ści (jeden do jed­ne­go lub jeden do wie­lu ale w cało­ści), nie moż­na przejść od jed­ne­go wyma­ga­nia np. biz­ne­so­we­go do dwóch i pół wyma­gań funk­cjo­nal­nych. To muszą być cał­ko­wi­te i jed­no­znacz­ne licz­by wymagań.

Jak widać wyma­ga­nia biz­ne­so­we to cele, cele lokal­ne (dzia­ły, pio­ny), więc będzie ich kil­ka­na­ście, kil­ka­dzie­siąt przy dużych pro­jek­tach, obej­mu­ją­cych cała orga­ni­za­cję. Jeden cel biz­ne­so­wy to jed­na lub kil­ka (rzad­ko wię­cej) usług jakich ocze­ku­je­my od nowe­go roz­wią­za­nia. Tak więc nale­ża­ło­by się spo­dzie­wać kil­ku­dzie­się­ciu usług roz­wią­za­nia a nie kil­ku tysię­cy wyma­gań”. Pomijając dłu­gie dywa­ga­cje o defi­ni­cjach (były już na tym blo­gu) poniż­szy sche­mat (model poję­cio­wy) poka­zu­je związ­ki pomię­dzy spo­ty­ka­ny­mi w lite­ra­tu­rze, wyma­ga­nia­mi i ich repre­zen­ta­cja­mi (tu przy­pad­ki uży­cia w UML).

Wymagania

Na dia­gra­mie zazna­czy­łem z pomo­cą tak zwa­ne­go dzie­dzi­cze­nia” (strzał­ka z nie­wy­peł­nio­nym gro­tem wska­zu­je uogól­nio­ne poję­cie, jej dru­gi zaś koniec poję­cie szcze­gó­ło­we). Zwykła linia to powią­za­nie pomię­dzy poję­cia­mi (fakt łączą­cy róż­ne poję­cia). Tak więc wyma­ga­nia wobec roz­wią­za­nia to pewien pod­zbiór wyma­gań biz­ne­so­wych (nie wszyst­kie cele biz­ne­so­we muszą wią­zać się z kon­kret­nym roz­wią­za­niem). Wymagania wobec roz­wią­za­nia to wła­śnie spor­ne, nie­jed­no­znacz­ne, poję­cia spo­ty­ka­ne w lite­ra­tu­rze. To co moż­na potwier­dzić, to podział wszyst­kich wyma­gań” wobec roz­wią­za­nia na funk­cjo­nal­ne i nie­funk­cjo­nal­ne. Mimo bra­ku ich ści­słych defi­ni­cji (czym jest moż­li­wość łatwe­go doda­wa­nia danych kon­tra­hen­ta z listy??) wie­my, że są tyl­ko te dwa. Wymagania nie­funk­cjo­nal­ne dzie­li się (mię­dzy inny­mi) na jako­ścio­we i dzie­dzi­no­we, te dru­gie to logi­ka biz­ne­so­wa i algo­ryt­my. Mamy jed­nak pre­cy­zyj­ną defi­ni­cję poję­cia przy­pa­dek uży­cia (mam na myśli defi­ni­cję w spe­cy­fi­ka­cji nota­cji UML), jest to usłu­ga sys­te­mu, świad­czo­na akto­ro­wi (na jego żąda­nie, a wiec ini­cjo­wa­na przez akto­ra), któ­rej pro­dukt ma war­tość dla akto­ra bo jest celem korzy­sta­nia z sys­te­mu przez tego akto­ra. Tak więc przy­pad­kiem uży­cia jest to, że sys­tem pozwa­la na wytwo­rze­nie fak­tu­ry VAT” a nie to, że pozwa­la wybrać kon­tra­hen­ta z listy po klik­nię­ciu myszą”. Każda usłu­ga sys­te­mu, jego przy­pa­dek uży­cia, zwią­za­ny jest ze kon­kret­ną logi­ką jego zre­ali­zo­wa­nia (wyko­na­nia) czy­li wyma­ga­niem dziedzinowym.

Śladowanie. Jak pomaga? 

Mając listę celów pro­jek­tu, okre­śla­my, któ­re pla­nu­je­my zre­ali­zo­wać z pomo­cą nowe­go opro­gra­mo­wa­nia – to wyma­ga­nia wobec roz­wią­za­nia. Wymagania wobec roz­wią­za­nia opi­su­je­my skoń­czo­ną licz­bą wyma­ga­nych usług sys­te­mu, do któ­rych jed­no­znacz­nie przy­po­rząd­ko­wu­je­my wyma­ga­nia jako­ścio­we (np. dostęp­ność) i dzie­dzi­no­we (np. wzór na war­tość podat­ku). Całość mode­lu­je­my jako przy­pad­ki uży­cia i model dzie­dzi­ny (przy­pad­ki uży­cia – usłu­gi sys­te­mu – są reali­zo­wa­ne ele­men­ta­mi mode­lu dzie­dzi­ny, kla­sa­mi lub kom­po­nen­ta­mi reali­zu­ją­cy­mi okre­ślo­ną logi­kę). Skąd brać przy­pad­ki uży­cia? Z warsz­ta­tów? Sesji burzy mózgów? Kiepski pomysł, co napi­sa­łem na począt­ku. Jeżeli już jed­nak to robi­my to śla­do­wa­nie pozwa­la pano­wać nad zakre­sem pro­jek­tu i zło­żo­no­ścią całej doku­men­ta­cji wyma­gań: po zatwier­dze­niu wyma­gań biz­ne­so­wych, odrzu­ca­my wszyst­kie zgła­sza­ne wyma­ga­nia funk­cjo­nal­ne i nie­funk­cjo­nal­ne, któ­re nie wspie­ra­ją (nie dają się zaadre­so­wać – śla­do­wać) wyma­gań biz­ne­so­wych. Skąd brać przy­pad­ku uży­cia? Najlepiej z mode­li pro­ce­sów, bo te są zwe­ry­fi­ko­wa­nym (tu śla­do­wa­nie aktyw­ność – przy­pa­dek uży­cia) mode­lem dzia­ła­nia orga­ni­za­cji. Śladowanie wyma­ga jed­nak ści­słych – jed­no­znacz­nych, defi­ni­cji. Skoro nie da się jed­no­znacz­nie zde­fi­nio­wać funk­cjo­nal­no­ści sys­te­mu”, nie sto­suj­my tego poję­cia. Pojęcie usłu­ga sys­te­mu jest dobrze zde­fi­nio­wa­ne, w UML jest to przy­pa­dek uży­cia, w SOA i archi­tek­tu­rze kor­po­ra­cyj­nej, usłu­ga apli­ka­cyj­na koja­rzo­na jest (mapo­wa­na, śla­do­wa­na) z ele­men­tar­ny­mi (ato­mo­wy­mi) pro­ce­sa­mi biz­ne­so­wy­mi (aktyw­no­ścia­mi). 

Tak więc wyma­gań biz­ne­so­wych może być kil­ka­dzie­siąt. Wymaganych usług sys­te­mu (przy­pad­ków uży­cia) w dużym pro­jek­cie tak­że może być kil­ka­dzie­siąt. Ale set­ki, czy tysią­ce wyma­gań” to wyraz utra­ty pano­wa­nia nad zakre­sem pro­jek­tu… Tu zwró­cę uwa­gę, że wyma­ga­niem (usłu­ga sys­te­mu) może być np. wytwo­rzo­na fak­tu­ra VAT zgod­na z prze­pi­sa­mi. Cechy tej fak­tu­ry (lista pól) to nie osob­ne wyma­ga­nia, to cechy (para­me­try, atry­bu­ty) jed­ne­go wyma­ga­nia. Żadna cecha fak­tu­ry VAT nie ma sama w poje­dyn­kę żad­nej war­to­ści, nie może więc być oddziel­nym przy­pad­kiem uży­cia, tak samo jak wyma­ga­niem naszym może być samo­chód, ale jego kolor czy auto­ma­tycz­na skrzy­nia bie­gów, to cechy samo­cho­du, nie ma sen­su wyma­gać czer­wo­ne­go kolo­ru” nie ocze­ku­jąc samo­cho­du (i jak uza­sad­nić, to że ten kolor wspie­ra cel biz­ne­so­wy). Przypadkiem uży­cia samo­cho­du jest podróż a nie wło­że­nie klu­czy­ka do sta­cyj­ki, bo to jest tyl­ko jeden z ele­men­tów sce­na­riu­sza roz­po­czę­cia podró­ży samochodem.

Czemu tak czę­sto jed­nak powsta­ją nie­we­ry­fi­ko­wal­ne spe­cy­fi­ka­cje na set­ki pozy­cji? Najczęściej sły­szę – z ust ana­li­ty­ka – głu­pie tłu­ma­cze­nie: bo tak mi poka­za­no na szko­le­niu (tak czy­ta­łem w jed­nej książ­ce, tak było napi­sa­ne na blo­gu XXX, tak robi się u mnie w fir­mie itp…). Warto sobie same­mu udo­wod­nić popraw­ność wytwo­rze­nia efek­tów swo­jej pra­cy, a dobra doku­men­ta­cja ana­li­tycz­na jest sama dla sie­bie dowo­dem popraw­no­ści. Tak, mój blog tak­że nale­ży weryfikować.

Warsztaty analityczne – czyli malowanie trawy

W koń­czą­cym się roku trzy razy mia­łem do czy­nie­nia z nie mały­mi (czy­taj kosz­tow­ny­mi) doku­men­ta­mi zawie­ra­ją­cy­mi mode­le pro­ce­sów biz­ne­so­wych” i spe­cy­fi­ka­cję wyma­gań”. Wszystkie trzy mia­ły pew­ne wspól­ne cechy:

  1. były pro­ble­my z przy­dat­no­ścią tych doku­men­tów, co było powo­dem popro­sze­nia mnie o oce­nę i reko­men­da­cje w kwe­stii ich naprawy,
  2. wszyst­kie były pro­duk­tem zbio­ro­wych warsz­ta­tów pro­ce­so­wych” i warsz­ta­tów wyma­gań” z pra­cow­ni­ka­mi mode­lo­wa­nej firmy,
  3. żaden nie nada­wał się do uży­cia jako mate­riał do stwo­rze­nia opro­gra­mo­wa­nia, mimo, że wszyst­kie one były pro­duk­tem pierw­sze­go eta­pu pro­jek­tu o nazwie ana­li­za przed-wdrożeniowa”,
  4. wszyst­kie cier­pia­ły na pro­blem nad­mia­ru szcze­gó­łów, nie­jed­no­znacz­no­ści i bra­ku spójności.

Jedenaście lat temu (tak jede­na­ście!) napisałem:

Często fir­my ofe­ru­ją usłu­gę i pro­dukt Model (mapę) Procesów Biznesowych. Co dają? Dają nie­udol­nie zro­bio­ny opis pro­ce­dur, nie­słusz­nie nazwa­nych pro­ce­sa­mi. Setki sche­ma­tów obra­zu­ją­cych kto, co i jak robi. A po co to robi? Tego tam z regu­ły nie opi­sa­no! Dziesiątki i set­ki stron dia­gra­mów, któ­re lądu­ją na pół­ce i nie są uży­wa­ne pod­czas wdro­że­nia. Powstaje opra­co­wa­nie, któ­re jest nie­zro­zu­mia­łe przez zarząd fir­my zle­ca­ją­cej tę pra­cę. Zarząd nie przy­zna się, że nie rozu­mie bo podob­no to zna­na fir­ma dorad­cza lub wdro­że­nio­wa opra­co­wa­ła. A moim zda­niem, jeże­li Zarząd nie potra­fi zro­zu­mieć udo­ku­men­to­wa­ne­go obra­zu wła­snej fir­my to doku­ment jest do kitu a nie Zarząd. (Modelowanie biz­ne­so­we czy­li pil­no­wa­nie hochsz­ta­ple­rów).

Dlaczego tak jest? Dlaczego tak bar­dzo popu­lar­ne są tego typu warsz­ta­ty a nie rze­tel­ne, dają­ce wyso­kiej jako­ści pro­duk­ty, analizy?

Obserwacja gry vs. reguły gry

To co się dzie­je na sto­le bilar­do­wym (meta­fo­ra z książ­ki M.Fowlera) moż­na opi­sać z pomo­cą praw fizy­ki i reguł gry w bilar­da. To co obser­wu­je­my na sza­chow­ni­cy (meta­fo­ra z blo­ga Paula Harmona) to wynik reguł gry, doświad­cze­nia i kla­sycz­nych zagry­wek. W obu przy­pad­kach docho­dzą też do gło­su wie­dza i umie­jęt­no­ści gra­czy. Piłka noż­na to regu­ły gry, pra­wa fizy­ki (tor pił­ki po kop­nię­ciu pił­ki) i umie­jęt­no­ści zawod­ni­ków. Można tu podać wie­le innych przy­kła­dów efek­tów łącz­ne­go ist­nie­nia okre­ślo­nych reguł oraz umie­jęt­no­ści ludzi.

Każda orga­ni­za­cja (fir­ma, urząd, inne) to ludzie z ich wie­dzą i umie­jęt­no­ścia­mi oraz regu­ły gry” czy­li obo­wią­zu­ją­ce Prawo i wewnętrz­ne regu­la­cje. I teraz poja­wia się pyta­nie: czym jest model orga­ni­za­cji? Przede wszyst­kim model to uprosz­cze­nie rze­czy­wi­sto­ści, jed­nak sto­pień tego uprosz­cze­nia nie jest przy­pad­ko­wy. To co uprasz­cza­my (pomi­ja­ne szcze­gó­ły) zale­ży od kon­tek­stu w jakim ten model będzie uży­ty, bo two­rze­nie mode­lu na jeden cel: uży­cie go w kon­kret­nym celu. Tu nie­ste­ty” wkra­cza nauka, mam na myśli podej­ście (meto­da nauko­wa w ana­li­zie).

Spójrzmy na to od koń­ca. Aby powsta­ło jakie­kol­wiek narzę­dzie wspo­ma­ga­ją­ce pra­cę np. ludzi wyko­nu­ją­cych swo­je obo­wiąz­ki w orga­ni­za­cji, narzę­dziem taki jest tak­że opro­gra­mo­wa­nie (czy­li apli­ka­cje), musi powstać opis tego narzę­dzia. Aplikacje to takie narzę­dzia, two­rzy­my je głów­nie z dwóch powo­dów: two­rzy­my elek­tro­nicz­ne wer­sje kar­to­tek (reje­strów) oraz two­rzy­my elek­tro­nicz­ne wer­sje okre­ślo­nych umie­jęt­no­ści (np. wyli­cza­nie pier­wiast­ków w kal­ku­la­to­rze). Tak więc aby zamó­wić u deve­lo­pe­ra Kartotekę musi ją opi­sać i to jest rela­tyw­nie pro­ste: two­rzy­my wzór Kartoteki, np. kar­to­te­ki pra­cow­ni­ka, książ­ki w biblio­te­ce itp. Nieco trud­niej jest opi­sać (udo­ku­men­to­wać) umie­jęt­ność, zresz­tą naj­pierw trze­ba ja jakoś zde­fi­nio­wać. Umiejętności, tu wyma­ga­ne, mogą być róż­ne: od umie­jęt­no­ści wery­fi­ka­cji danych wpro­wa­dza­nych do kar­to­tek aż do umie­jęt­no­ści wytwa­rza­nia nowych infor­ma­cji na bazie tych dostęp­nych w kar­to­te­kach. Np. utwo­rze­nie fak­tu­ry sprze­da­ży wyma­ga sko­rzy­sta­nia z kar­to­te­ki klien­tów, z kar­to­te­ki ofe­ro­wa­nych towa­rów i usług, kar­to­te­ki towa­rów dostęp­nych w maga­zy­nie, trze­ba tak­że posia­dać umie­jęt­ność popraw­ne­go wyli­cze­nia war­to­ści podat­ków na for­mu­la­rzu fak­tu­ry, mogą do tego dojść upu­sty zależ­ne od wie­lu czyn­ni­ków: war­to­ści zaku­pu, aktu­al­nych pro­mo­cji, sta­tus kupu­ją­ce­go i wie­le innych. Inny przy­kład: zare­je­stro­wa­nie nowe­go doku­men­tu w archi­wum wyma­ga sko­rzy­sta­nia z kar­to­te­ki doku­men­tów oraz umie­jęt­no­ści nada­nia doku­men­to­wi spe­cjal­ne­go zna­ku, sygnatury.

workshopI tu wpa­da­my w efekt krę­ce­nia fil­mu”. Najczęściej tak zwa­na ana­li­za wyglą­da tak, że pra­cow­ni­cy ana­li­zo­wa­nej fir­my, w toku warsz­ta­tów lub wywia­dów, opo­wia­da­ją z jaki­mi to sytu­acja­mi mają do czy­nie­nia, co robią, kie­dy i jak, opi­su­jąc kon­kret­ne przy­pad­ki z jaki­mi mie­li do czy­nie­nia i to, jak sobie z nimi pora­dzi­li. Do tego docho­dzą przy­pad­ki, w któ­rych sobie sła­bo pora­dzi­li, przy­pad­ki tego jak sobie radzą z tym, że cze­goś nie rozu­mie­ją, a to wszyst­ko jest okra­szo­ne spo­so­ba­mi pra­cy wyni­ka­ją­cy­mi nie raz z nie­wie­dzy, nie­zna­jo­mo­ści pra­wa czy wewnętrz­nych regu­la­cji. Na domiar złe­go, nie raz moż­na się spo­tkać z przy­pad­ka­mi, w któ­rych opo­wia­da­ją­cy o swo­je pra­cy wpla­ta ele­men­ty pozwa­la­ją­ce mu na dzia­ła­nia nie­po­żą­da­ne takie jak uprasz­cza­nie pro­ce­dur lub wręcz łama­nie pra­wa (np. swe­go cza­su pewien urzęd­nik na moich oczach w trak­cie warsz­ta­tów zgło­sił jako wyma­ga­nie wobec sys­te­mu obie­gu doku­men­tów, moż­li­wość pod­pi­sa­nia orze­cze­nia sędzie­go prze­ter­mi­no­wa­nym pod­pi­sem elektronicznym!).

Dokumenty, któ­re dosta­ję do recen­zji, to czę­sto wła­śnie zapi­sy, wręcz ste­no­gra­my z takich spo­tkań, i nie ma zna­cze­nia czy to zapi­sy pro­zą” czy zapi­sy w posta­ci obraz­ko­wej z uży­ciem nota­cji BPMN czy UML (gdzie nota­cja jest wyko­rzy­sty­wa­na raczej jako biblio­te­ka sym­bo­li a nie narzę­dzie z jego syn­tak­ty­ką i seman­ty­ką). To doku­men­ty, któ­re sta­no­wią rodzaj ste­no­gra­mu z roz­mów, są jak fil­my nakrę­co­ne pod­czas roz­gry­wa­nia par­tii sza­chów lub bilar­da: miłe w oglą­da­niu, dłu­gie, kosz­tow­ne i kom­plet­nie nie­przy­dat­ne do napi­sa­nia kom­pu­te­ro­wej gry.

Do opi­sa­nia każ­dej z tych gier, a tak­że do opi­sa­nia tego jak funk­cjo­nu­je orga­ni­za­cja, wystar­czy doku­ment opi­su­ją­cy zasa­dy gry (regu­ły biz­ne­so­we) oraz mini­mal­ną wie­dzę i umie­jęt­no­ści gra­czy oraz to jakie i w jakiej kolej­no­ści rze­czy maja powstać czy­li model pro­ce­sów biz­ne­so­wych. Model pro­ce­sów jed­nak to nie jest film” opi­su­ją­cy czy­jąś pra­cę a logicz­ny łań­cuch aktyw­no­ści two­rzą­cych, każ­da, przy­dat­ny biz­ne­so­wi produkt.

Jaki opis powsta­nie po prze­pro­wa­dze­niu kil­ku dni warsz­ta­tów z gra­cza­mi, któ­rzy gra­ją od lat, zasa­dy gry zna­ją na pamięć, bywa ze podej­mu­ją pró­by łama­nia zasad dla osią­gnię­cia doraź­nych efek­tów? To będą dłu­gie, nie raz nie­spój­ne wywo­dy. Każdą z wymie­nio­nych gier opi­su­ją jed­nak jed­no­znacz­nie dwa bar­dzo krót­kie doku­men­ty: regu­ły gry oraz mini­mal­ne umie­jęt­no­ści i wie­dza każ­de­go z gra­czy. Z takim doku­men­tem każ­dy pro­jek­tant opro­gra­mo­wa­nia sobie pora­dzi bez problemu.

Niestety wie­le pro­duk­tów eta­pu pro­jek­tu o nazwie ana­li­za przed-wdro­że­nio­wa to tak zwa­ne malo­wa­nie tra­wy: kawał kosz­tow­nej i niko­mu nie przy­dat­nej pra­cy. Jakiś temu pisa­łem z innej okazji:

Niestety, pod­czas tak zwa­nych typo­wych ana­liz, opar­tych na wywia­dach i spo­tka­niach warsz­ta­to­wych, im wię­cej inte­rak­cji tym więk­sze pole do mani­pu­la­cji i per­swa­zji (świa­do­mej lub nie, ale jed­nak). Po dru­gie, nie ma żad­nej gwa­ran­cji, że nicze­go nie pomi­nię­to (w takich roz­mo­wach w zasa­dzie oma­wia­ne są rze­czy cie­ka­we i rzad­kie a pra­wie nigdy oczywiste). […]

Drugim pro­ble­mem i poważ­nym błę­dem jest uzna­nie, że ?sko­ro te ana­li­zy to spo­tka­nia i zapi­sy­wa­nie ich wyni­ków, to może to robić nie­mal­że każ­dy byle był komu­ni­ka­tyw­ny?. Bzdura. Po pierw­sze takie dzia­ła­nie to nie są ana­li­zy a ste­no­gra­my ze spo­tkań, po dru­gie są one zapi­sem subiek­tyw­ne­go oglą­du sytu­acji, jaki mają odpy­ty­wa­ni pra­cow­ni­cy danej fir­my (do tego z ich tyl­ko per­spek­ty­wy). (Nowoczesne tech­no­lo­gie w służ­bie zdro­wia, czy­li tele­me­dy­cy­na w pro­jek­tach IT).

Dlatego rolą ana­li­ty­ka biz­ne­so­we­go nie jest spi­sa­nie prze­bie­gu dzie­sią­tek wywia­dów i setek indy­wi­du­al­nych wyma­gań. Nie mają więk­sze­go sen­su doku­men­ty na dwa, trzy tysią­ce stron (nikt ich nie czy­ta!). Rolą ana­li­ty­ka biz­ne­so­we­go jest prze­ana­li­zo­wa­nie dostęp­nych doku­men­tów, infor­ma­cji, i stwo­rze­nie opi­su mecha­ni­zmu dzia­ła­nia orga­ni­za­cji oraz opi­su roz­wią­za­nia, narzę­dzia mogą­ce­go uspraw­nić dzia­ła­nie orga­ni­za­cji. Opisu zawie­ra­ją­ce­go regu­ły biz­ne­so­we, prze­twa­rza­ne infor­ma­cje (wzo­ry doku­men­tów) oraz listą usług jakie ma świad­czyć pla­no­wa­na do wdro­że­nia apli­ka­cja wraz z opi­sem tego, jak te usłu­gi mają być reali­zo­wa­ne (umie­jęt­no­ści, któ­re moż­na zauto­ma­ty­zo­wać). Sens mają więc zwię­złe opi­sy i mode­le mecha­ni­zmów dzia­ła­nia orga­ni­za­cji oraz opi­sy tego jakie infor­ma­cje i jak mają być prze­twa­rza­ne z uwzględ­nie­niem tego, że część tych prac nadal będą wyko­ny­wa­li ludzie. Takie jak regu­ły gry w sza­chy: waż­ne są dwie stro­ny opi­su reguł gry a nie set­ki stron opi­sów przy­kła­do­wych partii.

klientsobiezyczyBardzo czę­sto sły­szę od deve­lo­pe­rów, ze więk­szość doku­men­tów jakie dosta­ją jest nie­przy­dat­na. Nie raz zasta­na­wiam się, dla­cze­go mimo to więk­szość usłu­go­daw­ców two­rzy tak nie­przy­dat­ne doku­men­ty? Najprawdopodobniej dla­te­go, że słu­cha­nie i ste­no­gra­fo­wa­nie jest łatwe… Z dru­giej stro­ny, nie raz nie­ste­ty sami zama­wia­ją­cy chcą takich wła­śnie doku­men­tów, Ci jed­nak są uspra­wie­dli­wie­ni, bo to nie oni są ana­li­ty­ka­mi. Ci ostat­ni sami decy­du­ją jaki­mi ana­li­ty­ka­mi są…

Drugim powo­dem jest dość powszech­ny brak umie­jęt­no­ści abs­trak­cyj­ne­go myśle­nia. Problem ten widać czę­sto na eta­pie mode­lo­wa­nia pro­ce­sów biz­ne­so­wych: zamu­la­nie zbęd­ny­mi szcze­gó­ła­mi. Bardzo wie­lu ana­li­ty­ków ma skłon­no­ści do wgłę­bia­nia się w nie­istot­ne szcze­gó­ły, to wła­śnie objaw bra­ku umie­jęt­no­ści two­rze­nia abs­trak­cji. Do tego stop­nia, że powstał pomysł na sfor­ma­li­zo­wa­nie zaj­mo­wa­nie się tymi szcze­gó­ła­mi (Case Management). Ciekawa dys­ku­sja na ten temat poja­wi­ła się na LinkedIn. Ja ze swej stro­ny pole­cam arty­kuł (Case Managemet) oraz wypo­wie­dzi Paula Harmona w dyskusji:

At the pro­cess level, we want the abi­li­ty to descri­be and orga­ni­ze a gene­ric set of acti­vi­ties. We might be con­cer­ned, for exam­ple, with how we orga­ni­ze Hotel Guest Services. To be cle­ar what we mean by orga­ni­zing Hotel Guest Services, we might talk abo­ut a spe­ci­fic instan­ce in which a hotel orga­ni­zed guest servi­ces. One of the things we might deci­de, for exam­ple, was that the hotel wan­ted eve­ry­one to use the guest’s name. Thus, we might think of all of the acti­vi­ties in which employ­ees might inte­ract, and pon­der how we would pro­vi­de each set of employ­ees with each guest’s name. It obvio­usly would­n’t be a mat­ter of sim­ply noti­fy­ing one gro­up – like tho­se who take restau­rant rese­rva­tions of who is in what room – sin­ce, as Roger sug­ge­sts, a hotel guest could pro­ce­ed in any order, going to the pool, or to a con­fe­ren­ce ses­sion, or pro­ce­eding to make a restau­rant rese­rva­tion. In this case we are pro­ba­bly tal­king abo­ut put­ting infor­ma­tion into a data­ba­se from which vario­us employ­ees could easi­ly retrie­ve it. Processes are dyna­mic and com­plex, in part, becau­se the gene­ric pro­cess descrip­tion isn’t as pre­scrip­ti­ve as it would be in a pro­duc­tion line, whe­re the sta­tions are set and the beha­viors expec­ted at each sta­tion are well defi­ned. They are cases” becau­se each instan­ce of the pro­cess uses a dif­fe­rent set of acti­vi­ties in a dif­fe­rent order – as in the Rescue Hostage exam­ple. When we plan for a Rescue Hostage case or pro­ject if you pre­fer, we deve­lop a series of sce­na­rios, and prac­ti­ce a lar­ge set of acti­vi­ties. When the time comes to exe­cu­te the pro­cess, we begin by plan­ning for the spe­ci­fic instan­ce case. The idea that we start the pro­cess with a gene­ric: Plan for the Specific Rescue Effort, acti­vi­ty may be gene­ric, but any deta­iled exam­ple of it will be an instan­ce, sin­ce in the very natu­re of the plan­ning we are tailo­ring to the spe­ci­fic instan­ce. (Case Management Approaches | LinkedIn).

Sekwencje a procesy

Swego cza­su napi­sa­łem tekst o nie­jed­no­znacz­no­ści tre­ści w doku­men­ta­cji jako źró­dle kło­po­tów w pro­jek­tach: Analityk biz­ne­so­wy czy­li wyple­nić dwu­znacz­ność… Warto pamię­tać, że:

Bałagan poję­cio­wy w rapor­cie z ana­li­zy, powo­du­je, że raport nie pozwa­la na jego jed­no­znacz­ną inter­pre­ta­cję, co prak­tycz­nie dys­kwa­li­fi­ku­je go jako przy­dat­ne źró­dło infor­ma­cji w projekcie.

Dzisiaj kon­ty­nu­acja tej tezy w kon­tek­ście powsta­ją­cych mode­li, ich tre­ści i szczegółowości.

Weźmy np. dość czę­sto poja­wia­ją­ce się poję­cia: pro­ces sys­te­mo­wy” czy też sys­tem” w mode­lu pro­ce­su biz­ne­so­we­go, sekwen­cje i dia­gra­my sekwen­cji itp. Spotykam się nie­ste­ty z masą beł­ko­tu i here­zji w doku­men­tach, na blo­gach czy nawet w książ­kach… Na listach dys­ku­syj­nych LinkedIn widać, że pro­blem nie doty­czy tyl­ko nasze­go kra­ju :). Przyczyną tych pro­ble­mów jest prak­tycz­nie zawsze igno­ro­wa­nie defi­ni­cji pojęć tak języ­ko­wych (język w jakim pisa­na jest doku­men­ta­cja) jak i nota­cyj­nych (igno­ro­wa­nie lub po pro­stu nie­zna­jo­mość lub nawet nie zro­zu­mie­nie stan­dar­du). Czy nazy­wa­nie cze­goś here­zją to moje subiek­tyw­ne uzna­nie? Myślę, że nie, to porów­na­nie (audyt?) ze stan­dar­da­mi i ogól­nie uzna­ny­mi sys­te­ma­mi poję­cio­wy­mi, jed­nym z nich język ojczy­sty auto­ra dokumentu.

Najpierw kil­ka klu­czo­wych defi­ni­cji (słow­nik języ­ka pol­skie­go PWN):

pro­ces: prze­bieg nastę­pu­ją­cych po sobie i powią­za­nych przy­czy­no­wo okre­ślo­nych zmian

pro­ce­du­ra: okre­ślo­ne regu­ły postępowania

sekwen­cja: układ jakichś ele­men­tów, w któ­rym nastę­pu­ją one w okre­ślo­nej kolejności

sce­na­riusz: zapla­no­wa­ny lub prze­wi­dy­wa­ny roz­wój wydarzeń

Proces, defi­ni­cja biz­ne­so­wa” mówi o pro­duk­cie pro­ce­su biz­ne­so­we­go, jest nim wła­śnie ta wpro­wa­dzo­na zmia­na”. Procedura w prak­ty­ce jest regu­łą (biz­ne­so­wą). Sekwencja w UML to nic inne­go jak usta­lo­na (dla sen­su lub powo­dze­nia ope­ra­cji) kolej­ność zda­rzeń (wywo­łań). Scenariusz to poję­cie wyko­rzy­sta­ne w opi­sie przy­pad­ków uży­cia: sce­na­riusz przy­pad­ku uży­cia”. W związ­ku z tym, że przy­pad­ki uży­cia są wyma­ga­niem (opi­sem uży­cia pro­duk­tu), inte­rak­cja aktor – sys­tem, ma sta­tus pla­no­wa­ny”. Uznanie w pro­jek­cie, że wyma­ga­nie jest OK”, daje w kon­se­kwen­cji pro­jekt”, czy­li sekwen­cję opi­su­ją­cą reali­za­cję przy­pad­ku uży­cia. Jak widać, słow­nik nie jest taki zły, nota­cje i ich sys­tem poję­cio­wy w szczególności.

Porządkujemy wie­dze dalej. Zajrzyjmy do MDA Guide Version 1.0.1:

MDA CIM model

MDA PIM model

Model CIM to model opi­su­ją­cy logi­kę dzia­ła­nia (sens ist­nie­nia) mode­lo­wa­nej orga­ni­za­cji, to model tego co i po co się dzie­je” a nie jak i czym”. Tu nie poka­zu­je­my narzę­dzi (jakim jest np. opro­gra­mo­wa­nie). Standardem na tym pozio­mie mode­lo­wa­nia są nota­cje BMM i BPMN. Rzecz w tym, że model pro­ce­sów biz­ne­so­wych nie powi­nien zawie­rać żad­nych pojęć typu sys­tem” czy opro­gra­mo­wa­nie”. Dlaczego? Bo dla zro­zu­mie­nia i udo­ku­men­to­wa­nia tego jak dzia­ła orga­ni­za­cja, potrzeb­na jest wie­dza o tym jakie infor­ma­cje i jak są prze­twa­rza­ne, a nie czym”.

Często widu­ję pró­by poka­za­nia na jed­nym dia­gra­mie: pra­cy ludzi, inte­gra­cji sys­te­mów, szcze­gó­łów pro­ce­dur i wszyst­ko inne, co tyl­ko autor doku­men­tu wie. To total­ne nie­po­ro­zu­mie­nie, to pokaz nie­zro­zu­mie­nia tego czym są mode­le, a są uprosz­cze­nia­mi (abs­trak­cja­mi), okre­ślo­ny­mi per­spek­ty­wa­mi ana­li­zo­wa­ne­go zjawiska.

Model PIM to obraz logi­ki dzia­ła­nia (część biz­ne­so­wa, dome­na) narzę­dzia jakim jest apli­ka­cja. Tu poja­wia się to, jakie infor­ma­cje i jak są (mają być) prze­twa­rza­ne. Model ten jed­nak nie opi­su­je szcze­gó­łów (śro­do­wi­sko apli­ka­cji, fra­me­work, roz­wią­za­nia tech­no­lo­gicz­ne np. logo­wa­nie, kodo­wa­nie, itp.), opi­su­je wyłącz­nie biz­ne­so­wą logi­kę dzia­ła­nia apli­ka­cji. Gdzie i jak to pro­jek­to­wać, poka­zać, testować?

Przytoczę po raz kolej­ny dia­gram ze stro­ny Business Process Trends:

(źr. http://www.bptrendsassociates.com/)
(źr. http://​www​.bptrend​sas​so​cia​tes​.com/)

Mamy tu trzy pozio­my mode­lo­wa­nia orga­ni­za­cji: archi­tek­tu­ra pro­ce­sów, mode­le pro­ce­sów oraz ich imple­men­ta­cja. Architekturę pro­ce­sów z regu­ły przed­sta­wia się jako wyso­ko­po­zio­mo­we uogól­nie­nie np. z pomo­cą pro­stej nota­cji zna­nej jako pago­ni­ki” :):

Diagram Mapa Procesów

Modele pro­ce­sów two­rzy­my z uży­ciem, nie raz tu już oma­wia­nej, nota­cji BPMN. Tu jest mowa o pro­ce­sach biz­ne­so­wych i ewen­tu­al­nych ich pod­pro­ce­sach ale nadal poziom szcze­gó­ło­wo­ści nie scho­dzi poni­żej pary aktyw­ność i jej pro­dukt” (pro­ces biz­ne­so­wy). Implementacja to regu­ły wg. któ­rych reali­zo­wa­ne są poszcze­gól­ne aktyw­no­ści. Dana aktyw­ność jest reali­zo­wa­na albo na bazie umie­jęt­no­ści jej wyko­naw­cy (rola) i nie two­rzy­my jej dia­gra­mu a powo­łu­je­my się na opis sta­no­wi­ska, albo na bazie pro­ce­du­ry czy­li wyko­naw­ca danej pra­cy musi prze­strze­gać reguł narzu­co­nych pro­ce­du­rą. Procedurę spi­su­je­my w punk­tach z ewen­tu­al­ny­mi warian­ta­mi (a nie mode­lu­je­my obraz­ka­mi). Ale imple­men­ta­cja to albo wdro­że­nie pro­ce­du­ry albo wdro­że­nie oprogramowania. 

A gdzie te systemowe procesy”?

Otóż nie ma cze­goś takie­go, nie w archi­tek­tu­rze opi­sy­wa­nej stan­dar­do­wo ani w BPMN ani w UML, nie ma (nie znam) w archi­tek­tu­rze kor­po­ra­cyj­nej. Mając wie­dzę o kom­po­nen­tach sys­te­mu (róż­nych apli­ka­cjach) mamy wie­dzę do cze­go zosta­ły one stwo­rzo­ne i jakie reali­zu­ją zada­nia (zna­my ich inter­fej­sy). Zaś ele­men­tem, któ­ry ini­cju­je w sys­te­mie jaką­kol­wiek sekwen­cję wyda­rzeń (inte­rak­cji mię­dzy apli­ka­cja­mi, kom­po­nen­ta­mi, obiek­ta­mi) jest zaini­cjo­wa­ny przy­pa­dek uży­cia sys­te­mu, a kon­kret­nie zda­rze­nie ini­cju­ją­ce wyge­ne­ro­wa­ne przez kon­kret­ne­go akto­ra. Jeżeli teraz przy­po­mni­my sobie, że akto­rem sys­te­mu może być tak­że inny sys­tem (kła­nia się dia­gram przy­pad­ków uży­cia), ini­cju­ją­cy inte­rak­cje (żąda obsłu­gi, np. przez API) to mamy peł­ny obraz sytu­acji: aktor ini­cju­je sekwen­cje wyda­rzeń jaką są kolej­no nastę­pu­ją­ce po sobie wza­jem­ne wywo­ła­nia kom­po­nen­tów lub obiek­tów. Znowu klu­czo­wym poję­ciem sta­je się tu SYSTEM (na dia­gra­mie przy­pad­ków uży­cia jest to ele­ment System czy­li oryg. sub­ject” danej per­spek­ty­wy) i jego gra­ni­ce. To aku­rat bar­dzo ład­nie poka­zu­je ten turorial:

Tak więc mamy:

  1. pro­ce­sy biz­ne­so­we jako pary aktyw­ność i jej pro­dukt (za pro­dukt odpo­wia­da wyko­naw­ca pro­ce­su, są to np. mode­le w nota­cji BPMN),
  2. pro­ce­du­ry (lub wyma­ga­ne umie­jęt­no­ści), opi­su­ją­ce ato­mo­we (nie­po­dziel­ne) aktyw­no­ści (opi­sa­ne np. w posta­ci wypunk­to­wa­nych list), two­rze­nie pro­ce­dur to imple­men­ta­cja okre­ślo­nych aktyw­no­ści meto­da­mi orga­ni­za­cyj­ny­mi (np. wdro­że­nie sys­te­mu zarzą­dza­nia jako­ścią ISO),
  3. sce­na­riu­sze przy­pad­ków uży­cia opi­su­ją inte­rak­cje aktor-apli­ka­cja (opi­sa­ne jako punk­to­wa­ne listy, mode­lo­wa­ne jako inte­rak­cje aktor-sys­tem w nota­cji UML), jest to imple­men­ta­cja okre­ślo­nych aktyw­no­ści w aplikacji,
  4. sekwen­cje opi­su­ją inte­rak­cje pomię­dzy kom­po­nen­ta­mi (obiek­ta­mi, mode­lo­wa­ne dia­gra­mem sekwen­cji UML), czy­li ele­men­ta­mi archi­tek­tu­ry apli­ka­cji (sys­te­mu).

Bardzo dobrze poka­zu­je to model SOA opi­sa­ny w poprzed­nim arty­ku­le Wzorzec CRUD. Warstwa pro­ce­sów, usług aplikacyjnych/przypadków uży­cia i kom­po­nen­tów to odręb­ne war­stwy i per­spek­ty­wy. Nie mie­sza­my więc ani pozio­mów abs­trak­cji ani per­spek­tyw mode­li. W prze­ciw­nym razie, ule­ga­jąc suge­stiom w rodza­ju ale ja chcę zoba­czyć to wszyst­ko na jed­nym dia­gra­mie” pcha­my pro­jekt w kie­run­ku utra­ty pano­wa­nia nad zło­żo­no­ścią”… To pro­sta dro­ga do klę­ski projektu.

Process for System Architecture and Requirements Engineering

Czy da się wyspe­cy­fi­ko­wać wyma­ga­nia na duże mia­sto? Poproście kil­ka­na­ście osób o wypi­sa­nie tego jakich funk­cji ocze­ku­ją od swo­je­go mia­sta. Dostaniecie dłu­gą listę wyobra­żeń zawie­ra­ją­cych prze­mie­sza­ne moż­li­wo­ści, ich jakość i wydaj­ność. Otóż zło­żo­ne­go sys­te­mu nie da sen­sow­nie” opi­sać z pomo­cą zwy­kłej listy ocze­ki­wań. Będzie bar­dzo duża i zdez­ak­tu­ali­zu­je się toku trwa­nia pro­jek­tu, któ­ry pla­nu­je się raczej na lata niż niż tygodnie.

Książka zawie­ra opis szkie­le­tu (fra­me­work) mode­lo­wa­nia sys­te­mu infor­ma­cyj­ne­go opar­te­go na czte­rech pod­sta­wo­wych obsza­rach: inter­fejs użyt­kow­ni­ka, wej­ście i wyj­ście, klu­czo­wej oraz wspo­ma­ga­ją­cej logi­ki. Główny trzon szkie­le­tu to wej­ście, prze­twa­rza­nie i wyj­ście, czy­li pro­ces”. Autorzy budu­ją sys­tem poję­cio­wy opar­ty na ana­li­zie od ogó­łu do szcze­gó­łu, abs­trak­cji, tak­że obiek­to­wym para­dyg­ma­cie (auto­rzy ope­ru­ją związ­ka­mi całość cześć, dzie­dzi­cze­niem, związ­kiem usłu­go­bior­ca – usłu­go­daw­ca). Złożony sys­tem dzie­lo­ny jest na kom­po­nen­ty, całość jed­nak utrzy­ma­na w duchu biz­ne­so­wych sche­ma­tów blokowych.

W czę­ści opi­su­ją­cej wyma­ga­nia, poja­wia się bar­dzo waż­ne i przy­dat­ne zało­że­nie: wyma­ga­nia są defi­nio­wa­ne nie­za­leż­nie od tech­no­lo­gii. Druga waż­na rzecz: wyma­ga­nia to słow­nik (zesta­wie­nie) cech: moż­li­wo­ści sys­te­mu oraz – tych moż­li­wo­ści (funk­cje) – cechy jako­ścio­we i wydaj­no­ścio­we. Szkielet (abs­trak­cja) sys­te­mu to trzy typy ele­men­tów (w książ­ce trzy per­spek­ty­wy): pamięć (enti­ty model) czy­li miej­sca prze­cho­wy­wa­nia infor­ma­cji (repo­zy­to­ria). Dalej pro­ce­sy – tu, funk­cje prze­twa­rza­ją­ce dane prze­cho­wy­wa­ne w pamię­ci oraz ste­row­nie (spra­wo­wa­nie kon­tro­li) nad całością.

Całość sta­no­wi pew­ne prze­mie­sza­nie ana­li­zy obiek­to­wej (model abs­trak­cji od ogó­łu do szcze­gó­łu z dzie­dzi­cze­niem, kom­po­nen­ty) i struk­tu­ral­nej (mode­le danych i prze­pły­wu danych). Całość jest opa­ko­wa­na” wyma­ga­nia­mi w rozu­mie­niu słow­ni­ka cech systemu.

Z opi­su moż­na wysnuć wnio­sek, że auto­rzy nie wprost (nie powo­łu­ją się na ten model) nawią­zu­ją do obiek­to­we­go mode­lu BCE (opi­sa­łem go w arty­ku­le Wzorzec ana­li­tycz­ny BCE). Korzystają z dia­gra­mu klas UML (jaw­nie o nim pisze) jako mode­lu poję­cio­we­go. Jednak model pro­ce­sów to już model DFD zna­ny z ana­li­zy struk­tu­ral­nej (De Marco). W obsza­rze defi­nio­wa­nia pro­ce­sów (w tej książ­ce funk­cje prze­twa­rza­ją­ce) przy­wo­łu­ją tak­że tabli­ce decy­zyj­ne (tabli­ce decy­zyj­ne).

Warto tę książ­kę prze­czy­tać, by poznać dobrze opi­sa­ną, spój­ną, zorien­to­wa­ną na mode­le, kon­cep­cję ana­li­zy i mode­lo­wa­nia sys­te­mów biz­ne­so­wych. Dla kogoś mają­ce­go przy­wią­za­nie do ana­li­zy struk­tu­ral­nej, opi­sa­ny szkie­let będzie zapew­ne dobrym narzę­dziem pra­cy. Przyznam jed­nak, że nadal koja­rzy mi się to z lata­mi 90-tymi i pierw­szy­mi narzę­dzia­mi typu EJB ([[Enterprise Java Bean]]) i ane­micz­nym mode­lem dzie­dzi­ny. Autorzy przy­wo­łu­ją meto­dy obiek­to­we jako sze­ro­ko obec­nie rekla­mo­wa­ne”, jed­nak mam wra­że­nie, że nie mają prze­ko­na­nia do tego mode­lu, uzna­ją­ce­go ści­sły zwią­zek danych i pro­ce­sów prze­twa­rza­nia w posta­ci obiek­tów. Co cie­ka­we jed­nak widzą zale­ty tego na wyż­szych pozio­mach abs­trak­cji”, a tak się skła­da, że obiek­to­wy para­dyg­mat zakła­da imple­men­ta­cję wła­śnie tej abs­trak­cji – obiek­to­we­go mode­lu – w takiej posta­ci jaka powsta­je na eta­pie ana­li­zy i pro­jek­to­wa­nia (mode­lo­wa­nia) sys­te­mu (prze­czy­taj arty­kuł o DDD).

Dalsza część książ­ki to opis pro­ce­su wytwa­rza­nia apli­ka­cji co tu pomi­nę, tak­że dla­te­go, że nie jest moim celem stresz­cza­nie tu tej książ­ki. Opisałem ją bo (pomi­ja­jąc struk­tu­ral­nie zorien­to­wa­ną meto­dę ana­li­zy i pro­jek­to­wa­nia) bar­dzo dobrze opi­su­je war­tość doda­ną same­go pro­ce­su ana­li­zy opar­tej na mode­lo­wa­niu. Porządkuje to wie­dzą o sys­te­mie, mode­le sta­no­wią też doku­men­ta­cję sys­te­mu, są mapo­wa­ne” na wymagania.

Na koniec war­to pod­kre­ślić jed­ną rzecz: ana­li­za i spe­cy­fi­ko­wa­nie wyma­gań, zakła­da­jąc abs­tra­ho­wa­nie wyma­gań od tech­no­lo­gii, dosko­na­le nada­je się do pro­jek­tów zakła­da­ją­cych zakup goto­we­go opro­gra­mo­wa­nia. Autor nad­mie­nia na począt­ku, iż zakła­da­nie że będzie to od razu jeden mono­li­tycz­ny sys­tem, że taki jest lep­szy, jest moc­no nacią­ga­ne. Nawiązując do meta­fo­ry z budo­wa­niem mia­sta: powsta­je ono w cza­sie, będzie ono raczej zło­że­niem kom­po­nen­tów ([[COTS]]) niż monolitem.

Trzeba tę mieć jed­nak świa­do­mość tego, że książ­kę pierw­szy raz wyda­no w 2000 roku, jej napi­sa­nie mogło trwać ok. roku, może dwóch, a to zna­czy, że opi­su­je ona doświad­cze­nia auto­rów z lat 80 i 90 tych (cze­go auto­rzy nie ukry­wa­ją). To były cza­sy, gdy meto­dy obiek­to­we racz­ko­wa­ły a struk­tu­ral­ne prze­ży­wa­ły jesz­cze szczy­ty popularności.

Co cie­ka­we auto­rzy, w dodat­ku na koń­cu książ­ki, przy­zna­ją, że model zorien­to­wa­ny obiek­to­wo jest bar­dzo dobrą abs­trak­cją sys­te­mu, jed­nak uzna­ją, że na potrze­by imple­men­ta­cji waż­ny jest model struk­tu­ral­ny. Myślę, że to efekt przy­zwy­cza­je­nia auto­rów do trak­to­wa­nia wyma­gań jako prze­pi­su na pisa­nie kodu pro­gra­mu, pisa­nie meto­da­mi i narzę­dzia­mi strukturalnymi…

Tak więc czy­ta­jąc takie książ­ki, nadal popu­lar­ne, nie zapo­mi­naj­my o tym z jakiej epo­ki się wywo­dzą. Nie zapo­mi­naj­my, że meto­dy struk­tu­ral­ne to dro­ga do mono­li­tycz­nych sys­te­mów, któ­rych zwin­ność” jest porów­ny­wal­na raczej do wiel­kie­go traw­le­ra prze­twór­ni na Bałtyku, a dzi­siaj są potrzeb­ne małe, szyb­kie, dedy­ko­wa­ne kutry rybac­kie, któ­re w moż­na bar­dzo w ilo­ści i spe­cja­li­za­cji, łatwo dobrać do panu­ją­cych warun­ków na ryn­ku i zmie­niać w razie potrzeby.

Tytuł: Process for System Architecture and Requirements Engineering
Autor: Derek Hatley, Peter Hruschka, Imtiaz Pirbhai0
Wyd.: Published August 2nd 2013 by Addison-Wesley Professional (Goodreads | Process for System Architecture and Requirements Engineering Dorset House eBooks by Derek Hatley ? Reviews, Discussion, Bookclubs, Lists).

Nowoczesne technologie w służbie zdrowia, czyli telemedycyna w projektach IT

Jakiś czas temu pisa­łem o uru­cho­mia­nej usłu­dze zdal­nej ana­li­zy”. Dla wie­lu ludzi brzmi to kurio­zal­nie: prze­cież ana­li­za to kon­takt z ludź­mi!” I tu widzę pod­sta­wo­wy błąd postrze­ga­ny w oce­nie tym czym jest ana­li­za, któ­ra nie jest dia­lo­giem”. Metafora z leka­rzem jest chy­ba bar­dzo dobrym porów­na­niem: lekarz pra­cu­je w dwóch eta­pach”: ana­li­za i posta­wie­nie dia­gno­zy, pro­jek­to­wa­nie roz­wią­za­nia oraz zapla­no­wa­nie i wdro­że­nie kura­cji. Owszem, są pew­ne róż­ni­ce w sto­sun­ku do pro­jek­tów IT, ale więk­szość z nich to pro­jek­ty pole­ga­ją­ce na oce­nia sta­nu fak­tycz­ne­go (co chce­my ulep­szyć) i pla­no­wa­niu zmian (kura­cji).

Niestety, pod­czas tak zwa­nych typo­wych ana­liz, opar­tych na wywia­dach i spo­tka­niach warsz­ta­to­wych, im wię­cej inte­rak­cji tym więk­sze pole do mani­pu­la­cji i per­swa­zji (świa­do­mej lub nie, ale jed­nak). Po dru­gie, nie ma żad­nej gwa­ran­cji, że nicze­go nie pomi­nię­to (w takich roz­mo­wach w zasa­dzie oma­wia­ne są rze­czy cie­ka­we i rzad­kie a pra­wie nigdy oczy­wi­ste). Świat radzi sobie z tym na róż­ne spo­so­by, np. w medy­cy­nie są to bada­nia spe­cja­li­stycz­ne na odle­głość, gdzie lekarz spe­cja­li­sta nie zna pacjen­ta, widzi jedy­nie np. jego zdję­cie RTG lub wynik bada­nia tomografem.

Drugim pro­ble­mem i poważ­nym błę­dem jest uzna­nie, że sko­ro te ana­li­zy to spo­tka­nia i zapi­sy­wa­nie ich wyni­ków, to może to robić nie­mal­że każ­dy byle był komu­ni­ka­tyw­ny”. Bzdura. Po pierw­sze takie dzia­ła­nie to nie są ana­li­zy a ste­no­gra­my ze spo­tkań, po dru­gie są one zapi­sem subiek­tyw­ne­go oglą­du sytu­acji, jaki mają odpy­ty­wa­ni pra­cow­ni­cy danej fir­my (do tego z ich tyl­ko perspektywy).

Tak więc wyko­na­nie ana­li­zy orga­ni­za­cji (ana­li­zy sys­te­mo­wej) nie pole­ga na roz­mo­wach i wywia­dach” a na dogłęb­nej oce­nie tego co i jak się dzie­je w orga­ni­zmie” danej fir­my i oce­na tego sta­nu rze­czy. Dalsze dzia­ła­nia to opi­sa­nie sytu­acji pro­ble­mo­wej i oce­na moż­li­wych roz­wią­zań (sce­na­riu­szy). Dopiero teraz przy­cho­dzi pora na wdro­że­nie wybra­ne­go warian­tu (kura­cja o naj­niż­szym ryzy­ku). Można tu już dostrzec dwa eta­py: ana­li­za i reko­men­da­cje oraz fak­tycz­ne lecze­nie (wdra­ża­nie roz­wią­za­nia). Dobra prak­ty­ką (uod­por­nie­nie na per­swa­zje i subiek­ty­wizm) jest oddziel­nie ana­li­zy od wdro­że­nia a tak­że bar­dziej stu­dio­wa­nie fak­tów niże subiek­tyw­ne­go ich opi­su z ust pacjen­ta” (ten może być uzu­peł­nie­niem ale nie jedy­nym źródłem).

Od pew­ne­go cza­su dobrze radzi sobie z tym medycyna:

Poziom zna­jo­mo­ści elek­tro­kar­dio­gra­fii jest znacz­nie zróż­ni­co­wa­ny – róż­ny zakres umie­jęt­no­ści w zakre­sie inter­pre­ta­cji EKG jest pro­ble­mem zgła­sza­nym w wie­lu kra­jach nie tyl­ko w Polsce. Centrum Telemedycyny odpo­wia­da w tym zakre­sie na zapo­trze­bo­wa­nie wie­lu małych ośrod­ków (ZOZów, NZOZów), któ­re bądź nie posia­da­ją eta­to­wo zatrud­nio­nych spe­cja­li­stów kon­sul­tu­ją­cych zapi­sy EKG bądź spe­cja­li­ści tacy są dostęp­ni w bar­dzo ogra­ni­czo­nym zakresie.

Dzięki dedy­ko­wa­nym urzą­dze­niom EKG ośro­dek medycz­ny ma moż­li­wość prze­sy­ła­nia do kon­sul­tan­ta-spe­cja­li­sty badań elek­tro­kar­dio­gra­ficz­nych i uzy­ska­nie peł­nej oraz facho­wej infor­ma­cji na temat rodza­ju wady pacjen­ta i spo­so­bu dal­sze­go postę­po­wa­nia. [wytł. moje] (Nowoczesne tech­no­lo­gie w służ­bie zdro­wia, czy­li tele­me­dy­cy­na w Instytucie Kardiologii – Artykuły – Nowoczesna klinika).

O co cho­dzi z tą zdal­ną ana­li­zą? W dużym skró­cie bada­na fir­ma gro­ma­dzi doku­men­ty ope­ra­cyj­ne (czy­li zapi­sy fak­tów) i prze­ka­zu­je je do ana­li­zy, na ich pod­sta­wie odtwa­rza­na jest wewnętrz­na orga­ni­za­cja dzia­ła­nia: pro­ce­sy biz­ne­so­we, mode­le logi­ki biz­ne­so­wej itp.(zdal­na ana­li­za biz­ne­so­wa). Wymaga to jed­nak sto­sow­ne­go wypo­sa­że­nia”, o czym pisa­łem w poprzed­nim arty­ku­le (moje narzę­dzia ana­li­ty­ka). Owszem ska­la takiej ana­li­zy jest inna niż wyko­na­nie i oce­na bada­nia tomo­gra­fem kom­pu­te­ro­wym, ale meto­da jest taka sama: prze­świe­tle­nie (ana­li­za doku­men­tów ope­ra­cyj­nych), opra­co­wa­nie mode­li (zdję­cie) i reko­men­da­cje (moż­li­we spo­so­by dal­sze­go postę­po­wa­nia). Potem, zależ­nie od decy­zji, anga­żo­wa­ne są fir­my (wybra­ne na bazie wyma­gań) wdra­ża­ją­ce okre­ślo­ne rozwiązanie.

Niedawno skoń­czy­łem pro­jekt pro­wa­dzo­ny wła­śnie tą meto­dą, dru­gi dobie­ga koń­ca. Owszem, były spo­tka­nia, gdyż pew­ne dzia­ła­nia (są takie w każ­dej fir­mie) są nie­sfor­ma­li­zo­wa­ne i jedy­nym spo­so­bem by je postać, jest zapy­tać i usły­szeć. Jednak cała ana­li­za odby­wa się w spo­sób prak­tycz­nie wyklu­cza­ją­cy, jakie­kol­wiek naci­ski czy per­swa­zje. Informacje pozy­ski­wa­ne z doku­men­tów są zim­ne i obiek­tyw­ne”, bar­dzo czę­sto zarzą­dy bada­nych firm są zasko­czo­ne wyni­ka­mi. Praca odby­wa się nie­mal­że w cza­sie rze­czy­wi­stym, gdyż każ­dy powsta­ją­cy model (sche­mat blo­ko­wy) jest natych­miast prze­ka­zy­wa­ny do oce­ny oso­bom odpo­wie­dzial­nych za dany obszar biz­ne­so­wy i natych­miast komen­to­wa­ne (opro­gra­mo­wa­nie do zdal­nej pra­cy z mode­la­mi). Tak powsta­łe mode­le i opi­sy dzia­ła­nia są odar­te” z wszel­kie­go narzu­tu” zaciem­nia­ją­ce­go obraz sytu­acji (pro­dukt takiej ana­li­zy to nie 1000 stron a raczej 100 czy­li moż­na to prze­czy­tać). Firma wdra­ża­ją­ca roz­wią­za­nie tak­że ma taki dostęp, wyglą­da to tak:

Obieg informacji w projekcie analitycznym

(zobacz tak­że : opis peł­ne­go pro­ce­su ana­li­zy)

Ludzie wyko­nu­ją­ce dane pra­ce mają ten­den­cje do opi­sy­wa­nia wszel­kich zna­nych im warian­tów, są ich nie raz set­ki, a tak na praw­dę pro­ces bywa jeden i to rela­tyw­nie pro­sty. Typowym przy­kła­dem jest gospo­dar­ka maga­zy­no­wa: skła­da się tyl­ko z kil­ku ope­ra­cji i doku­men­tów: przy­ję­cie z zewnątrz, wyda­nie na zewnątrz, roz­chód wewnętrz­ny, przy­ję­cie wewnętrz­ne, prze­su­nię­cie mię­dzy­ma­ga­zy­no­we. Złożoność pro­duk­cji mon­ta­żo­wej, sprze­da­ży czy dys­try­bu­cji tkwi w ilo­ści tych ope­ra­cji i zło­żo­no­ści opi­su każ­de­go fak­tu. Model gospo­dar­ki mate­ria­ło­wej jest pro­sty, pro­blem bywa w tym, że mate­ria­łów jest dużo, mogą mieć ogra­ni­czo­ny czas przy­dat­no­ści, skom­pli­ko­wa­ny spo­sób zama­wia­nia itp.

Tak więc war­to się zasta­no­wić jak dotrze­my do wie­dzy o naszej fir­mie, i na ile jest ona wia­ry­god­na, nie zaciem­nio­na nad­mia­rem zbęd­nych szcze­gó­łów i czy wie­dza ta jest obiek­tyw­na. Dobra ana­li­za kon­kret­nej orga­ni­za­cji, fir­my, urzę­du, i jej wyni­ki nie może być np. poli­tycz­na (regu­lar­nie spo­ty­kam w fir­mach ana­li­zy, któ­rych celem jest wyka­za­nie przy­dat­no­ści okre­ślo­ne­go roz­wią­za­nia!) bo to dzia­ła­nie pole­ga­ją­ce na ofe­ro­wa­niu leków przed dia­gno­zą (rekla­my leków bez recep­ty w TV!). Tak moż­na sobie tyl­ko zaszko­dzić. A zdal­na ana­li­za (fak­tycz­nie zdal­nie odby­wa się ok. 80% pra­cy) poza­wa­la po pierw­sze obni­żyć jej koszt, a po dru­gie zobiek­ty­wi­zo­wać jej wyniki.

Osoby zain­te­re­so­wa­ne testem zdal­nej ana­li­zy pro­szę o kon­takt ema­il, bez­płat­ny test nie doty­czy firm świad­czą­cych usłu­gi o podob­nym charakterze.