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ć.

Od biznesu do przypadków użycia

Wymagania na opro­gra­mo­wa­nie są czę­sto doku­men­to­wa­ne z pomo­cą Przypadków Użycia (PU), zwa­nych w ory­gi­na­le” Use Case (UC). Wygodą sto­so­wa­nie tej kon­wen­cji jest trak­to­wa­nie Systemu jako tak zwa­nej czar­nej skrzyn­ki, czy­li cze­goś, cze­go wewnętrz­nej budo­wy nie zna­my, ale zna­my reak­cje na bodź­ce. W przy­pad­ku opro­gra­mo­wa­nia, nie wie­my jak jest ono zbu­do­wa­ne (w momen­cie zama­wia­nia go, może ono jesz­cze nie ist­nieć), ale wie­my jak reagu­je na pole­ce­nia”. Jest to uzna­nie zasa­dy, że zama­wia­ją­cy defi­niu­je CO opro­gra­mo­wa­nie ma robić a nie to JAK ono to robi. W przy­pad­ku goto­we­go opro­gra­mo­wa­nia, lub na eta­pie poprze­dza­ją­cym pro­jek­to­wa­nie, ma to sens, jed­nak nale­ży pamię­tać, że przy­pad­ki uży­cia nie deter­mi­nu­ją tego co tak na praw­dę dosta­nie­my, co opi­sa­łem w arty­ku­le o tym co na praw­dę opi­su­ją przy­pad­ki uży­cia.

Przypadki uży­cia budzą jed­nak wie­le kon­tro­wer­sji, gdyż kon­wen­cja ta jest sfor­ma­li­zo­wa­na (jest to część nota­cji UML), uży­wa­nie jej po swo­je­mu” pro­wa­dzi naj­czę­ściej do bez­u­ży­tecz­no­ści mode­li przy­pad­ków użycia.

Jeden z czy­tel­ni­ków spro­wo­ko­wał cie­ka­wą dyskusję:

…jakiej nota­cji uży­wa Pan, aby poka­zać wpływ jed­ne­go pro­ce­su na dru­gi? Konkretnie cho­dzi mi o przy­pa­dek, że pro­blem wystę­pu­je w pro­ce­sie roz­li­cza­nia płat­no­ści, ale żeby go napra­wić trze­ba wpro­wa­dzić zmia­ny w pro­ce­sie zaku­pów. Nie wiem czy samo roz­ry­so­wa­nie pro­ce­sów w BPMN jest wystar­cza­ją­ce czy moż­na to jakoś lepiej zamodelować.

Niektóre ana­li­zy wyma­ga­ją cze­goś ponad” pro­ce­sa­mi”. Mamy dwa wyj­ścia: two­rze­nie nad­rzęd­nych map pro­ce­sów i na nich szu­ka­nie” związ­ków albo zasto­so­wa­nie innej nota­cji na wyż­szym pozio­mie abs­trak­cji”. Notacja np. BPMN wystar­czy, rzecz w tym by opi­sać pro­ces na odpo­wied­nio wyso­kim pozio­mie abs­trak­cji. Tego typu pro­ble­my wyma­ga­ją uogól­nie­nia i spoj­rze­nia z wyż­szej” per­spek­ty­wy. Pomagają przy­pad­ki użycia.

Jeśli cho­dzi o mode­le PU, to przy­znam, że rzad­ko je sto­su­ję. W przy­pad­ku 1 czyn­ność – 1 PU, to jeśli mamy pro­ces w BPMN, to wg mnie model PU, to po pro­stu wrzu­ce­nie do jed­ne­go wor­ka wszyst­kich czyn­no­ści. Czyli jest to inna gra­ficz­nie (wg mnie słab­sza, bo brak kolej­no­ści) pre­zen­ta­cja tego same­go co w BPMN. Chyba że mamy czyn­no­ści, któ­re nie są wspie­ra­ne sys­te­mem albo wie­le pro­ce­sów, któ­re wyko­rzy­stu­ją tą samą czyn­ność (róż­ni akto­rzy dla tego same­go PU).

Troszkę o tym (przy­pad­ki uży­cia w skró­cie PU) tu: https://it-consulting.pl//?s=przypadki+u%C5%BCycia

Ogólnie PU to usłu­ga sys­te­mu, czyn­ność w pro­ce­sie to ele­ment pew­ne­go łań­cu­cha takich czyn­no­ści (pro­ces ma swój cel, pew­ne czyn­no­ści mogą się powta­rzać w róż­nych pro­ce­sach, np. archi­wi­za­cja doku­men­tu). System (opro­gra­mo­wa­nie) rzad­ko wspo­ma­ga wszyst­kie czyn­no­ści w pro­ce­sach. Model pro­ce­su słu­ży do zro­zu­mie­nia (i prze­te­sto­wa­nia) tego co i po co się dzie­je w orga­ni­za­cji, część czyn­no­ści (zakres pro­jek­tu) jest (ma być) wspie­ra­na opro­gra­mo­wa­niem (usłu­ga systemu).

Po dru­gie model PU to tak na praw­dę korzeń struk­tu­ry opi­su opro­gra­mo­wa­nia. Rolą mode­lu PU nie jest opis pro­ce­sów a spe­cy­fi­ka­cja usług sys­te­mu” z per­spek­ty­wy zewnętrz­ne­go użyt­kow­ni­ka”, jest to opis funk­cji narzę­dzia a nie proces.

Rzecz zasa­dza się w tym, jak zosta­ną zde­fi­nio­wa­ne poję­cia przy­pa­dek uży­cia” i czyn­ność” (w pro­ce­sie). Ciekawe jest to, że obie te defi­ni­cje są (PU w UML i czyn­ność w BPMN) per­ma­nent­nie zanie­dby­wa­ne (łama­ne) w doku­men­ta­cjach pro­jek­to­wych. W moich oczach jest to nie­zro­zu­mie­nie celo­wo­ści mode­lo­wa­nia, któ­re ma być lekar­stwem na nie­jed­no­znacz­ność pro­zy a nie jej inną firmą.

Dziękuję, za takie pre­cy­zyj­ne (łopa­to­lo­gicz­ne) wyja­śnie­nie. Mimo, że czy­ta­łam wcze­śniej Pana arty­ku­ły (oczy­wi­ście nie wszyst­kie) to dopie­ro teraz to do mnie wyraź­nie dotar­ło. Nadal nie wiem jak sen­sow­nie za pomo­cą mode­lu PU przed­sta­wić peł­ny zakres sys­te­mu np. ERP/CRM. Na takim dia­gra­mie powin­no być chy­ba kil­ka­dzie­siąt ele­men­tów i taki dia­gram nie będzie wg mnie przej­rzy­sty. Czy może dla jed­ne­go sys­te­mu nale­ży zro­bić kil­ka mode­li PU, ale z podzia­łem na aktorów…

A czy ma Pan może jakiś przy­kład PU gdzie akto­ra­mi są 2 sys­te­my tzn. nie ma udzia­łu oso­by fizycznej?

Duże sys­te­my war­to podzie­lić na tak zwa­ne blo­ki funk­cjo­nal­ne ogra­ni­czo­ne dzie­dzi­no­wo (tak zwa­ne [[boun­ded con­text]]) i pra­co­wać nad nimi” nie­za­leż­nie (każ­dy ma swój inter­fejs). Duży sys­tem może mieć set­ki UC, dzie­li się je na pakie­ty ale nie per aktor” a raczej per kon­tekst” (np. księ­go­wa­nie dowo­dów księ­go­wych w jed­nym pod­sys­te­mie, nie­za­leż­nie od tego ilu jest akto­rów). Nie ma sen­su upy­cha­nie na jed­nym dia­gra­mie wszyst­kich UC…

Co do zasa­dy, model PU zawie­ra poję­cie System (abs­trak­cja mode­lo­wa­ne­go opro­gra­mo­wa­nia), w nim przy­pad­ki uży­cia (PU) oraz poza nim akto­rów tego Systemu. Co jest waż­ne: model PU to model Jednego sys­te­mu i jego oto­cze­nia”, jeden model PU nie może zawie­rać wie­lu rów­no­rzęd­nych Systemów.

Co do zasa­dy model PU to: System mode­lo­wa­ny, przy­pad­ki jego uży­cia (jego usłu­gi świad­czo­ne na zewnątrz) oraz akto­rzy, akto­rem jest każ­dy zewnętrz­ny byt żąda­ją­cy obsłu­gi. Możliwe jest więc, że sys­tem nie ma żad­ne­go ludz­kie­go” akto­ra. Nie prze­sa­dzał bym z tym, że PU to głów­nie roz­mo­wy sys­te­mów” choć pro­jek­tu­jąc głów­nie” sys­te­my mid­dle­wa­re i ele­men­ty inte­gra­cji moż­na mieć takie wrażenie” 🙂

O narzę­dziach

Agilian ogól­nie wspie­ra każ­de śla­do­wa­nie”. Każda ope­ra­cja utwo­rze­nia PU z czyn­no­ści BPMN, po dro­dze ma etap wska­za­nia jaki dia­gram UC oraz jaki Model jest doce­lo­wy (a może ich być wie­le). Tu trze­ba bar­dzo uwa­żać, bo jeże­li mam pro­ces (np. w BPMN) obsłu­gi rekla­ma­cji, to poja­wią się czyn­no­ści z obsza­ru FK (spraw­dze­nia czy sprze­da­no taki towar), z obsza­ru logi­sty­ki (spraw­dze­nia kie­dy wyda­no lub dostar­czo­no) oraz CRM (czyn­no­ści biu­ro­we” obsłu­gi klien­ta, tu obsłu­ga rekla­ma­cji). W zasa­dzie jeden pro­ces użył” co naj­mniej trzy narzę­dzia (sys­te­my) z róż­nych obsza­rów dziedzinowych.

Co do adre­sa­tów dia­gra­mów, ja tak­że skła­niam się ku tezie, że dla biz­ne­su jest BPMN a PU to już dia­gram sys­te­mo­wy”, jed­nak wie­le meto­dyk (w tym RUP) trak­tu­je dia­gram PU jako pierw­szy powsta­ją­cy (?!) i jako adre­so­wa­ny do zama­wia­ją­ce­go… cóż…

Generalnie dia­gram PU jest bar­dzo dobrym korze­niem” do ana­li­zy i two­rze­nia pozo­sta­łych mode­li, ale bez powsta­ją­ce­go natych­miast” mode­lu dzie­dzi­ny nie jest moż­li­we zapro­jek­to­wa­nie gra­nic (boun­ded con­text) dla komponentów.

Spotykam się w lite­ra­tu­rze z teza­mi, któ­re uwa­żam za słusz­ne, że jeden sys­tem (pod­sys­tem) nie powi­nien prze­kra­czać 50 klas biz­ne­so­wych w dzie­dzi­nie (licz­ba bli­ska 100 to ogrom­ny sys­tem). Praca nad opro­gra­mo­wa­niem powin­na zacząć się od ana­li­zy i roz­bi­cia pro­ble­mu na straw­ne” kawał­ki. Najpierw podział na pod­sys­te­my, potem na kom­po­nen­ty, a na koń­cu kon­kret­ne kla­sy i ich realizacje.

Nie ma tu mowy o podzia­le z per­spek­ty­wy akto­ra, bo jeże­li wie­my jaka jest kon­struk­cja zapro­jek­to­wa­ne­go młot­ka albo kal­ku­la­to­ra, to nie może­my ogra­ni­czyć (bo nie mamy pod­staw) licz­by ich użyt­kow­ni­ków, bo każ­dy ma swo­je uza­sad­nio­ne powo­dy by wziąć do ręki np. młotek.…

Business Model Canvas vs. Business Motivation Model

Prawie rok temu pisałem:

Otóż klu­czo­wą cechą mode­lu dla potrzeb ana­li­zy sys­te­mo­wej jest trak­to­wa­nie go, pojęć z któ­rych się skła­da, jako pew­nej prze­strze­ni nazw (con­cep­tów) speł­nia­ją­cych pod­sta­wo­wą zasa­dę wza­jem­ne­go wyklu­cza­nia się defi­ni­cji pojęć. Dlatego nie łączę nigdy kosz­tów razem, roz­dzie­lam kosz­ty zaso­bów i kosz­ty mate­ria­łów słu­żą­cych do wytwo­rze­nia pro­duk­tów (pierw­sze nale­żą do nas, amor­ty­zu­je­my je, dru­gie kupu­je­my w pro­ce­sie zaopa­trze­nia by cał­ko­wi­cie je zużyć). Aktywności i zaso­by zaś łączę poję­ciem Proces Biznesowy, któ­ry mode­lu­je ści­sły zwią­zek pomię­dzy zaso­ba­mi (w tym role) a ich wytwo­ra­mi. To pozwa­la budo­wać zstę­pu­ją­cą hie­rar­chie dekom­po­zy­cji, uszcze­gó­ła­wia­ją­ce każ­de z tych pojęć. (Business Model Canvas).

Niedawno pod­czas pro­jek­tu nadzia­łem się” na pro­blem śla­do­wa­nia. Śladowanie to wywo­dze­nie obiek­tów biz­ne­so­wych (pojęć, potrzeb, wyma­gań itp.) kolej­nych eta­pów ana­li­zy z eta­pów je poprze­dza­ją­cych. Jednym z doku­men­tów jaki otrzy­ma­łem jako źró­dło był model biz­ne­so­wy w kon­wen­cji „[[Business Model Canvas]]” i poja­wił się pro­blem, na któ­ry zwró­ci­łem uwa­gę w cyto­wa­nym na począt­ku artykule…nie dało się z nie­go wypro­wa­dzić dal­szych działań”.

Model ten ma nastę­pu­ją­ca postać:

porów­naj­my go z tym:

Definicja pro­ce­su: czyn­ność lub łań­cuch czyn­no­ści prze­kształ­ca­ją­ca wej­ście w wyj­ście wno­sząc war­tość doda­ną, odby­wa się w śro­do­wi­sku ogra­ni­czeń i wyma­ga­nych zasobów.

Jeżeli dodać infor­ma­cję, że wej­ście pro­ce­su zasi­la dostaw­ca” a wyj­ście pro­ce­su to pro­dukt dla odbior­cy”, docho­dzi­my do wnio­sku, że model biz­ne­so­wy w kon­wen­cji Business Model Canvas”, to nic inne­go jak opis pro­ce­su defi­niu­ją­ce­go klu­czo­we dzia­ła­nia ryn­ko­we ana­li­zo­wa­ne­go podmiotu.

Milczącym zało­że­niem jest fakt, że rze­czy istot­ne w «biz­ne­sie” się doku­men­tu­je (nie tyl­ko dowo­dy księ­go­we ale tak­że np. zapy­ta­nia, ofer­ty itp.).

Jak widać jest wie­le podo­bieństw pomię­dzy mode­lem Business Model Canvas a mode­lem pro­ce­su uwzględ­nia­ją­cym zaso­by i ogra­ni­cze­nia. Oba maja jed­ną wadę: poka­zu­ją wyłącz­nie to co jest robio­ne”. W ana­li­zach biz­ne­so­wych wyma­ga­na jest jed­nak wie­dza nie tyl­ko o pro­ce­sie, celu i środ­kach (fir­ma jako pro­ces ryn­ko­wy). Model pro­ce­su to model mówią­cy tak teraz pra­cu­je­my”, takich mamy klien­tów, takich dostaw­ców, takie pra­wo itp. Gdzie problem?

Jeżeli uznać sta­rą praw­dę mówią­cą: kto stoi w miej­scu ten się cofa” docho­dzi­my do wnio­sku, że model do ana­li­zy np. pla­no­wa­nych zmian nie może być tyl­ko jed­nym pro­ce­sem (mapą pro­ce­sów). Nie roz­wią­zu­je pro­ble­mu model pro­ce­sów as-is i to-be (model obec­ny i model pla­no­wa­ny) bo zni­ka nam (nie jest tu uwzględ­nia­na) infor­ma­cja o przej­ściu” z jed­ne­go do drugiego.

Dlatego przy­da­je się model (i sys­tem poję­cio­wy) BMM (Business Motivation Model), któ­ry nie tyl­ko defi­niu­je pla­no­wa­ny stan przy­szły (opis sta­nu doce­lo­we­go – END), ale każe” się zasta­no­wić i udo­ku­men­to­wać to jak go osią­gnąć, poja­wia się stra­te­gia i tak­ty­ka osią­gnię­cia sta­nu oczekiwanego.

Model BMM to model ana­li­tycz­ny, sta­no­wi nie­ja­ko listę kon­tro­l­ną tego co nale­ży poznać i zro­zu­mieć”, żeby zacząć pla­no­wać osią­gnię­cie ocze­ki­wa­ne­go sta­nu orga­ni­za­cji. Po pierw­sze nale­ży zde­fi­nio­wać ten ocze­ki­wa­ny stan i okre­ślić to, jak stwier­dzi­my że został osią­gnię­ty – miara.

Struktura mode­lu BMM:

i naj­waż­niej­sze: mamy śla­do­wa­nie na pro­duk­ty dal­szej pra­cy (Referenced ele­ments… u dołu i po lewej stro­nie dia­gra­mu): kolej­ny etap ana­li­zy biz­ne­so­wej to opra­co­wa­nie mode­li pro­ce­sów biz­ne­so­wych, struk­tu­ry orga­ni­za­cyj­nej i ziden­ty­fi­ko­wa­nie (spe­cy­fi­ka­cja) reguł biz­ne­so­wych. Całość powin­na być opar­ta” na wspól­nym dla całe­go pro­jek­tu ana­li­tycz­ne­go (i orga­ni­za­cji) słow­ni­ku pojęć.

Jak widać, kla­sycz­ny” model biz­ne­so­wy poka­zu­je tyl­ko co jest przed­mio­tem dzia­łal­no­ści i klu­czo­wym źró­dłem zysku”. Model taki jest mode­lem pro­ce­su, ten pro­ces jed­nak to tyl­ko opis tego co, jaką war­tość doda­ną, dana orga­ni­za­cja dostar­cza swo­im klien­tom i gdzie się zaopa­tru­je. Model to-Be opi­su­je stan pożą­da­ny, nie daje żad­nej wie­dzy o tym, jak do nie­go dojść. Model As-is i To-be ma lukę pomię­dzy tymi As-Is i To-be. Tę lukę wypeł­nia moim zda­niem kom­plet­ny model BMM – każe opra­co­wać” stra­te­gię, tak­ty­kę, ana­li­zę SWOT, ryzy­ka i inne mają­ce wpływ na osią­gnię­cie celu, a nawet na to czy jest on w ogó­le osiągalny.

Po co to wszyst­ko? Bo dobra ana­li­za, powin­na być sama dla sie­bie dowo­dem słusz­no­ści jej wyni­ków (dla­te­go nie raz tu napi­sa­łem, że powin­na być pro­wa­dzo­na meto­dą nauko­wą”).

Krótki wpis o śladowaniu

Często jestem pyta­ny: a co to jest to śla­do­wa­nie”? Artykuł adre­su­je nie tyl­ko ana­li­ty­kom, ale tak­że oso­bom zle­ca­ją­cym wyko­na­nie ana­li­zy, pro­jek­tu i ich doku­men­ta­cji. W arty­ku­le poda­je przy­kła­dy bazu­ją­ce na obiek­to­wych meto­dach i wzor­cach ana­li­tycz­nych jed­nak nie jest to wie­dza wyma­ga­na do jego zrozumienia.

Po kolei…

Jedną z cech doku­men­ta­cji wyso­kiej jako­ści, jest wywo­dze­nie (kon­stru­owa­nie) każ­de­go wyma­ga­nia i pozo­sta­łych ele­men­tów mode­li od ogó­łu do szcze­gó­łu (meto­da ana­li­zy top-down) i wery­fi­ko­wa­nie ich w dru­gą stro­nę (meto­da ana­li­zy bot­tom-up). Nazywane jest to coraz czę­ściej jako tak zwa­ne śla­do­wa­nie (zależ­ność «tra­ce» na mode­lach popu­la­ry­zo­wa­na przez orga­ni­za­cję IIBA). Śladowanie pozwa­la przede wszystkim:

  1. uza­sad­nić każ­de wymaganie,
  2. uza­sad­nić każ­dy ele­ment pro­jek­tu implementacji,
  3. zwe­ry­fi­ko­wać kom­plet­ność i spój­ność całej dokumentacji,
  4. zapo­biec nie kon­tro­lo­wa­ne­mu roz­ro­sto­wi zakre­su projektu,
  5. umoż­li­wia oce­nę ren­tow­no­ści pro­jek­tu per każ­de wyma­ga­nie niezależnie.

Cóż to jest śladowanie? 

Przede wszyst­kim potrzeb­ny jest szczyt”, korzeń drze­wa śla­do­wa­nia. Powinien nim być cel biz­ne­so­wy pro­jek­tu, jak nie trud­no się domy­śleć, dla jed­ne­go pro­jek­tu powi­nien być zde­fi­nio­wa­ny jeden cel głów­ny, on wyzna­cza kie­ru­nek. Możliwe są cele skła­do­we, pod­rzęd­ne, ale jeden głów­ny jest wymagany.

Jednym z pod­sta­wo­wych ele­men­tów stra­te­gii osią­ga­nia celów biz­ne­so­wych jest ulep­sza­nie pro­ce­sów biz­ne­so­wych w orga­ni­za­cji. w tym celu wyko­nu­je się audyt orga­ni­za­cji, któ­re­go pro­duk­tem jest jej peł­ny model, ten zawie­ra mię­dzy inny­mi, jako skła­do­we, mode­le pro­ce­sów biznesowych.

Każdy pro­ces biz­ne­so­wy to jed­na lub sze­reg powią­za­nych czyn­no­ści. Wymagania są koja­rzo­ne (wywo­dzo­ne) z tych czyn­no­ści, któ­re pla­nu­je­my uspraw­nić np. z pomo­cą narzę­dzia jakim jest pla­no­wa­ne nowe lub roz­bu­do­wy­wa­ne oprogramowanie.

W przy­pad­ku opro­gra­mo­wa­nia dedy­ko­wa­ne­go, to jest two­rzo­ne­go na zamó­wie­nie, tymi wyma­ga­nia­mi są ocze­ki­wa­ne usłu­gi, tak zwa­ne przy­pad­ki uży­cia, opro­gra­mo­wa­nia (sys­te­mu). Są one wywo­dzo­ne z tych czyn­no­ści, któ­re nowe opro­gra­mo­wa­nie ma wspie­rać. Tak się okre­śla zakres pro­jek­tu, któ­ry jak widać, też wywo­dzo­ny jest z mode­lu (pro­ce­sów).

Kolejny pro­jek­to­wa­ny ele­ment to model dzie­dzi­ny sys­te­mu. Zawiera on obiek­ty biz­ne­so­we oraz ele­men­ty odpo­wie­dzial­ne za reali­za­cje każ­dej usłu­gi nowe­go opro­gra­mo­wa­nia. Są to kla­sy (i obiek­ty) w mode­lu dzie­dzi­ny. Każdy przy­pa­dek uży­cia jest wywo­dzo­ny z czyn­no­ści w pro­ce­sie, kla­sy ste­ru­ją­ce są wywo­dzo­ne z przy­pad­ków uży­cia, kla­sy repre­zen­tu­ją­ce obiek­ty prze­twa­rza­ne, są wywo­dzo­ne z doku­men­tów i zdarzeń.

Dalej z przy­pad­ków uży­cia wywo­dzo­ne są dia­gra­my sekwen­cji mode­lu­ją­ce sce­na­riu­sze zacho­wa­nia sys­te­mu w reak­cji na dzia­ła­nia użyt­kow­ni­ka (tak zwa­ne­go akto­ra). Klasy na mode­lach sekwen­cji są wywo­dzo­ne z mode­lu dziedziny.

Jeżeli model pro­ce­sów biz­ne­so­wych zawie­ra defi­ni­cje reguł biz­ne­so­wych, wywo­dzo­ne są z nich kla­sy lub ich ope­ra­cje, odpo­wie­dzial­ne za prze­strze­ga­nie” tych reguł.

Śladowanie w opi­sa­nej powy­żej kon­wen­cji ma nastę­pu­ją­ca postać:

Jak widać nad­zo­ro­wa­nych jest (śla­do­wa­nie) wie­le logicz­nych sko­ja­rzeń. Tego rodza­ju dia­gra­mów w pro­jek­cie jest nie mało, nie raz kil­ka­dzie­siąt i wię­cej, logicz­nych połą­czeń (czer­wo­ne linie prze­ry­wa­ne obra­zu­ją­ce śla­do­wa­nie) są więc set­ki. Jak nie­trud­no się domy­śleć, ręcz­ne” śle­dze­nie tych powią­zań jest prak­tycz­nie nie moż­li­we. (podob­nie zresz­tą jak ręcz­ne opra­co­wy­wa­nie zło­żo­nych rapor­tów finan­so­wych z tysię­cy danych).

Bez spe­cjal­ne­go narzę­dzia utrzy­ma­nie wyso­kiej jako­ści pro­jek­tu jest prak­tycz­nie nie moż­li­we przy zacho­wa­niu roz­sąd­ne­go nakła­du pra­cy. Narzędzia te to pakie­ty opro­gra­mo­wa­nia wspo­ma­ga­ją­ce pro­jek­to­wa­nie CASE (ang. com­pu­ter aided sys­tems engi­ne­ering lub com­pu­ter aided softwa­re engi­ne­ering, oso­bi­ście pre­fe­ru­je to pierw­sze roz­wi­nię­cie tego skrótu).

Jak zapew­ne czy­tel­ni­cy już zauważyli,…

…mode­le bez sys­te­mu śla­do­wa­nia są prak­tycz­nie nie­we­ry­fi­ko­wal­ne, ich jako­ści nie da się oce­nić a ich sto­so­wa­nie jest wyso­ce ryzy­kow­ne o ile w ogó­le sensowne.

Po co to wszystko? 

Jak wspo­mnia­no na począt­ku, do zapa­no­wa­nia na zło­żo­no­ścią pro­jek­tu i jego ren­tow­no­ścią. Kolejny powód to moż­li­wość wery­fi­ka­cji kom­plet­no­ści wyma­gań. Odkrywanie wyma­gań dopie­ro w trak­cie reali­za­cji pro­jek­tu (wery­fi­ka­cja wyma­gań dopie­ro z pomo­cą kolej­nych jego pro­to­ty­pów) to powszech­nie zna­ny zabój­ca projektów”.

Dobrze opra­co­wa­ny, kom­plet­ny model orga­ni­za­cji, jego wyko­na­nie poprze­dza opi­sa­ny powy­żej model, łączy w sobie:

  1. model moty­wa­cji biz­ne­so­wej,
  2. model struk­tu­ry organizacyjnej,
  3. model pro­ce­sów biz­ne­so­wych (wymie­nio­ny już powyżej),
  4. model reguł biz­ne­so­wych.

Elementy każ­de­go z tych mode­li są ze sobą powią­za­ne: role w pro­ce­sach są wywo­dzo­ne ze sta­no­wisk w mode­lu orga­ni­za­cyj­nym, ana­li­zo­wa­ne pro­ce­sy są wywo­dzo­ne ze stra­te­gii w mode­lu moty­wa­cji, regu­ły biz­ne­so­we są koja­rzo­ne z czyn­no­ścia­mi w pro­ce­sach i wywo­dzo­ne z aktów praw­nych i wewnętrz­nych zarządzeń.

Mając tak opra­co­wa­ny kom­plet­ny model orga­ni­za­cji, zawie­ra­ją­cy śla­do­wa­nie, i odpo­wied­nie opro­gra­mo­wa­nie CASE moż­na prze­pro­wa­dzić ana­li­zę oddzia­ły­wa­nia, np. spraw­dzić na jakie oso­by w orga­ni­za­cji prze­nie­sie się zmia­na wybra­nych reguł biz­ne­so­wych. Mając model sys­te­mu infor­ma­tycz­ne­go sko­ja­rzo­ny z pro­ce­sa­mi, moż­na spraw­dzić wpływ awa­rii poszcze­gól­nych pod­sys­te­mów na pro­ce­sy biz­ne­so­we i ich skut­ki dla fir­my. Takich ana­liz moż­na wyko­nać wie­le, nie było by to moż­li­we bez tak skon­stru­owa­ne­go modelu.

Dlatego, pod­sta­wo­wą war­to­ścią popraw­nie wyko­na­nych mode­li orga­ni­za­cji i uży­cia wła­ści­wych narzę­dzi, jest nie tyl­ko opra­co­wa­nie wyma­gań np. na opro­gra­mo­wa­nie. Możliwe jest testo­wa­nie reak­cji ele­men­tów struk­tu­ry orga­ni­za­cji na zda­rze­nia np. awa­rie. Możliwe jest opra­co­wa­nie pro­jek­tów inte­gra­cji, wymia­ny opro­gra­mo­wa­nia. Możliwe jest spraw­dze­nie na co ma wpływ np. nie­ocze­ki­wa­na nie­obec­ność pra­cow­ni­ka. To tyl­ko wybra­ne przy­kła­dy, jed­nak moż­li­we jest to wyłącz­nie pod warun­kiem posia­da­nia popraw­nie wyko­na­ne­go modelu.

Wartość doda­na takiej ana­li­zy może być bar­dzo duża. Jeżeli podej­mu­je się decy­zje o inwe­sty­cjach rzę­du setek tysię­cy a nie raz dzie­sią­tek milio­nów zło­tych to wspar­cie tych decy­zji ana­li­za­mi, któ­rych war­tość jest o rząd albo dwa rzę­dy mniej­sza ma głę­bo­ki sens…