Wstęp

Wśród wie­lu zna­nych i sto­so­wa­nych spo­so­bów doku­men­to­wa­nia wyma­gań na sys­te­my są tek­sto­we i tabe­la­rycz­ne opi­sy oraz meto­dy for­mal­ne. Pierwsze są tak nie­jed­no­znacz­ne, że są źró­dłem wie­lu pro­ble­mów dru­gie tak kosz­tow­ne i nie­zro­zu­mia­łe dla ​„laików”, że w zasa­dzie nie sto­so­wa­ne. Pośrodku mamy meto­dy ​„pół­for­mal­ne” czy­li mode­le. Ich cechą jest duża jed­no­znacz­ność wyma­ga­ją jed­nak pew­ne­go mini­mal­ne­go oby­cia z dia­gra­ma­mi u ich czy­tel­ni­ka oraz dużych umie­jęt­no­ści u twór­cy. czę­sto powta­rzam swo­im stu­den­tom: dobry model jest jak wiersz: dużą sztu­ką jest jego napi­sa­nie ale do prze­czy­ta­nia powin­na wystar­czyć zna­jo­mość alfa­be­tu. W tym arty­ku­le, adre­so­wa­nym do każ­de­go kto spo­ty­ka się lub wie, że go to spo­tka, z ana­li­za­mi wyma­gań i ich doku­men­to­wa­niem za pomo­cą dia­gra­mów. Zwrócę tak­że uwa­gę na typo­we pro­ble­my i ryzy­ka zwią­za­ne ze sto­so­wa­niem popu­lar­nych meto­dyk i notacji.

Napisze kil­ka słów adre­so­wa­nych głów­nie do nabyw­ców sys­te­mów. Powiem na co zwra­cać uwa­gę w doku­men­ta­cjach wyma­gań i cze­go raczej nie robić same­mu. Cała doku­men­ta­cja wyma­gań opi­su­je to jaki ma być przy­szłe opro­gra­mo­wa­nie jed­nak klu­czem do jej sku­tecz­no­ści jest opis biz­ne­so­wy orga­ni­za­cji i jej zro­zu­mie­nie czy­li zro­zu­mia­ły dla wszyst­kich uczest­ni­ków pro­jek­tu model biz­ne­so­wy i wska­za­ny na nim zakres pro­jek­tu. Jest to naj­czę­ściej pomi­ja­ny ele­ment pro­jek­tu przez dostaw­ców sys­te­mów. Dlaczego? Zaryzykuje tezę: dostaw­cy sys­te­mów to dobrzy inży­nie­ro­wie, któ­rzy z regu­ły nie mają wie­dzy i doświad­cze­nia z zakre­su mar­ke­tin­gu i zarzą­dza­nia jed­nak anga­żo­wa­ni są w two­rze­nie narzę­dzi do wspo­ma­ga­nia zarzą­dza­nia. Źródłem wie­lu pro­ble­mów pro­jek­tów IT jest luka komu­ni­ka­cyj­na pomię­dzy biz­ne­sem a inży­nie­rią opro­gra­mo­wa­nia. Podobno powszech­nie o tym wia­do­mo a jed­nak nadal wie­le doku­men­ta­cji wyma­gań pozo­sta­wia wie­le do życze­nia. Dlaczego?

O tym jak przypadki użycia rodzą kłopoty

Obserwuję dwa rodza­je róż­nych podejść do ana­li­zy i doku­men­to­wa­nia wyma­gań: opi­sy testo­we i struk­tu­ral­ne w przy­pad­ku pla­no­wa­ne­go zaku­pu goto­we­go sys­te­mu oraz meto­dy zorien­to­wa­ne na przy­pad­ki uży­cia w pro­jek­tach budo­wa­nia sys­te­mów ​„od zera” (tak zwa­nych dedy­ko­wa­nych). Pierwsze, opi­so­we, są od daw­na uzna­ne za złe więc nie będę się nad nimi tu roz­wo­dził i gene­ral­nie odra­dzam ich sto­so­wa­nie. Metody zorien­to­wa­ne na przy­pad­ki uży­cia są coraz czę­ściej uzna­wa­ne za nie­kom­plet­ne gdyż zatra­ca­ją biz­ne­so­wy kon­tekst pro­jek­tu zaś same przy­pad­ki uży­cia nic nie mówią o tak zwa­nych aspek­tach uży­cia sys­te­mu, jego słu­żeb­nej roli w pro­ce­sach biz­ne­so­wych (mowa tu o sys­te­mach wspo­ma­ga­ją­cych zarzą­dza­nie i pokrew­nych). Do tego przy­pad­ki uży­cia są z regu­ły two­rzo­ne z udzia­łem sze­re­go­wych pra­cow­ni­ków, przy­szłych użyt­kow­ni­ków sys­te­mu Ci zaś nie dość, że naj­czę­ściej nie mają poję­cia o cało­ścio­wej stra­te­gii fir­my to z regu­ły poda­ją infor­ma­cje słu­żą­ce ich par­ty­ku­lar­ne­mu chwi­lo­we­mu inte­re­so­wi a nie inte­re­so­wi całej organizacji.

RUP

Jedną z naj­czę­ściej spo­ty­ka­nych w fir­mach deve­lo­per­skich meto­dyk ana­li­zy i pro­jek­to­wa­nia jest Rational Unified Proces (RUP). Jest to typo­wy repre­zen­tant meto­dyk zorien­to­wa­nych na przy­pad­ki uży­cia i opi­su­je jedy­nie ogól­ne zasa­dy two­rze­nia obiek­to­we­go mode­lu sys­te­mu jakim jest tak­że dana orga­ni­za­cja. Metodyka ta bazu­je na nota­cji UML (Unified Modeling Language) ta zaś wspie­ra prak­tycz­nie tyl­ko obiek­to­we meto­dy ana­li­zy i pro­jek­to­wa­nia sys­te­mu a nie samej orga­ni­za­cji. UML nie zawie­ra nota­cji (typ dia­gra­mu) pozwa­la­ją­cej sku­tecz­nie mode­lo­wać orga­ni­za­cje w para­dyg­ma­cie pro­ce­so­wym. Diagram czyn­no­ści w UML sta­no­wi led­wie namiast­kę potrzeb­nych moż­li­wo­ści zaś jego rolą jest tak na praw­dę mode­lo­wa­nie algo­ryt­mów funk­cji (metod obiek­tów). Nawet pod­ręcz­ni­ki RUP’a odwo­łu­ją się do innych nota­cji takich jak eEPC czy od pew­ne­go cza­su BPMN (żr. UML 2.0 w akcji, pod­ręcz­nik opar­ty na pro­jek­tach i inne książ­ki o RUP). Jeżeli coś nowe­go poja­wi­ło się w RUP w kwe­stii two­rze­nia mode­li orga­ni­za­cji chęt­nie poznam tytuł i auto­ra książki.

O językach i teorii komunikacji

Niedawno uka­za­ła się cie­ka­wa książ­ka (Inżynieria sys­te­mów infor­ma­cyj­nych, Paul Beynon-Davies), opi­su­je w dość przy­stęp­ny spo­sób daw­no zna­ną z teo­rii komu­ni­ka­cji spo­łecz­nej kwe­stię kon­tek­stu i odbio­ru mode­lu. Błędy w tej mate­rii są postrze­ga­ne, nie tyl­ko prze­ze mnie, jako pod­sta­wo­we źró­dło kło­po­tów w pro­jek­tach IT. Uogólniając nie ma zna­cze­nia czy dany model jest wyko­na­ny popraw­nie od stro­ny syn­tak­tycz­nej (czy popraw­nie połą­czo­no sym­bo­le) i seman­tycz­nej (czy uży­to wła­ści­wych sym­bo­li) w tej czy innej nota­cji. Znaczenie ma to, czy adre­sat popraw­nie i jed­no­znacz­nie go zro­zu­miał (semio­ty­ka mode­lu – to jak zna­ki zosta­ły ode­bra­ne i zro­zu­mia­ne przez obser­wa­to­ra) i nic inne­go się nie liczy.

Model ma dwa zada­nia w ana­li­zie: symu­la­cja rze­czy­wi­stej orga­ni­za­cji dla ana­li­ty­ka i pro­jek­tan­ta oraz udo­ku­men­to­wa­nie decy­zji orga­ni­za­cyj­nych dla mene­dże­rów. Ten dru­gi cel jest z regu­ły zanie­dby­wa­ny i w efek­cie mene­dże­ro­wie zama­wia­ją­cy sys­tem czę­sto pod­pi­su­ją doku­men­ta­cje, któ­rych tak na praw­dę nie rozu­mie­ją pod wpły­wem suge­stii (a bywa, że per­swa­zji!) pseu­do­ana­li­ty­ków dostaw­cy sys­te­mu, że nie muszą tego rozu­mieć ale muszą pod­pi­sać bo to wymóg pro­jek­tu. Nic bar­dziej błędnego!

Istotą opi­su wyma­gań na sys­tem jest kon­tekst całe­go pro­jek­tu i tej inwe­sty­cji a kon­tek­stem tym jest model biz­ne­so­wy i zakres pro­jek­tu. Model biz­ne­so­wy moż­na wyko­nać nawet meto­da­mi for­mal­ny­mi za pomo­cą pseu­do­ko­du czy języ­ka rela­cji logicz­nych jed­nak model taki jest bez­war­to­ścio­wy, jeże­li nie sta­no­wi sobą zro­zu­mia­łe­go prze­ka­zu dla każ­de­go zaan­ga­żo­wa­ne­go w pro­jekt czy­taj ​„szcze­gól­nie klien­ta biz­ne­so­we­go”. Kluczem do suk­ce­su jest tu mode­lo­wa­nie czy­li zobra­zo­wa­nie w spo­sób zro­zu­mia­ły dla każ­dej stro­ny w pro­jek­cie IT isto­ty biz­ne­su i jego kon­tek­stu w pro­jek­cie two­rze­nia i wdra­ża­nia opro­gra­mo­wa­nia. Model biz­ne­so­wy i wewnętrz­na struk­tu­ra zarzą­dza­nia orga­ni­za­cji to nie obiek­to­we mode­le a pro­ce­so­we mapy łań­cu­chów two­rze­nia war­to­ści w fir­mie. Model obiek­to­wy ma zasto­so­wa­nie dopie­ro pod­czas two­rze­nia mode­li infor­ma­cyj­nych czy­li struk­tu­ry danych prze­cho­wy­wa­nych i prze­twa­rza­nych w fir­mie a dane to nic inne­go jak repre­zen­ta­cja tych infor­ma­cji, któ­re fir­ma chce prze­twa­rzać oraz spo­sób w jaki chce to robić o czym wie­lu ana­li­ty­ków zda­je się zapo­mi­nać. Jak więc pro­wa­dzić ana­li­zy wymagań?

Na począ­tek moż­na chy­ba pole­cić dość dobrze udo­ku­men­to­wa­ne w lite­ra­tu­rze meto­dy ana­li­zy struk­tu­ral­nej, któ­rej czę­ścią jest mode­lo­wa­nia pro­ce­sów za pomo­cą Diagramów Przepływów Danych. Jako meto­da ana­li­zy i pozy­ski­wa­nia wyma­gań nie­co sie skom­pro­mi­to­wa­ła (bar­dzo pra­co­chłon­na i trud­na w obsza­rze kore­la­cji mode­lu pro­ce­sów i mode­lu danych) jed­nak uczy pro­ce­so­we­go podej­ścia do ana­li­zy. Jako doce­lo­we narzę­dzie pole­cam raczej współ­cze­sne mode­le pro­ce­sów biz­ne­so­wych zorien­to­wa­ne na pro­duk­ty pro­ce­sów (infor­ma­cje). Tu pole­cam prze­stu­dio­wa­nie dostęp­nej w sie­ci doku­men­ta­cji do takich nota­cji i narzę­dzi jak eEPC (pro­gram ARIS), BPMN (www​.omg​.org), ADONIS (wła­sna nota­cja) i wie­le innych w tym wie­le zaawan­so­wa­nych narzę­dzi CASE (Computer Aided System Engineering). Większość tych narzę­dzi ma wbu­do­wa­ną moż­li­wość uży­cia nota­cji BPMN i UML.

Dokumentacje te opi­su­ją głów­nie nota­cję jed­nak na dostęp­nych tam przy­kła­dach moż­na sie nie mało nauczyć. Naczelną zasa­dą mode­lo­wa­nia jed­nak zawsze będzie zro­zu­mia­łość mode­li dla człon­ków mode­lo­wa­nych orga­ni­za­cji. Po dru­gie mode­lo­wa­nie to sztu­ka, nie da się tego nauczyć z jed­nej książ­ki jak rze­mio­sła, nie ma goto­wych pro­ce­dur na wyko­na­nie dobre­go mode­lu. Modelowanie wyma­ga roz­le­głej wie­dzy i doświadczenia.

Na zakończenie: nie modeluj biznesu jeżeli go nie rozumiesz

Na koniec dru­ga waż­na uwa­ga: nie da się mode­lo­wać orga­ni­za­cji i biz­ne­su nie zna­jąc tych dzie­dzin. Modelowanie pro­ce­sów biz­ne­so­wych, jak sama nazwa wska­zu­je, wyma­ga wie­dzy z zakre­su i mode­lo­wa­nia i pro­ce­sów biz­ne­so­wych czy­li zarzą­dza­nia i mar­ke­tin­gu. Dlatego oso­ba pra­gną­ca się nauczyć mode­lo­wa­nia biz­ne­so­we­go może nie musi koń­czyć MBA ale powin­na mieć dużą wie­dzę z zakre­su mar­ke­tin­gu i zarzą­dza­nia. Pamiętając tak­że, że w defi­ni­cji pro­ce­su biz­ne­so­we­go jest ​„two­rze­nie war­to­ści” pole­cam prze­stu­dio­wa­nie lite­ra­tu­ry takiej jak ​„try­lo­gia” M.E.Portera, a przy­naj­mniej jego ​„Przewagę kon­ku­ren­cyj­ną” gdzie dokład­nie jest omó­wio­na teo­ria łań­cu­cha war­to­ści i pro­ce­sy biz­ne­so­we. Polecam tak­że 3. roz­dział (W jaki spo­sób infor­ma­cja wpły­wa na prze­wa­gę kon­ku­ren­cyj­ną, w tym pod­roz­dział Konkurowanie w epo­ce infor­ma­cji) M.E.Porter ​„O kon­ku­ren­cji” gdzie opi­sa­no model łań­cu­cha war­to­ści w biz­ne­sie w posta­ci klu­czo­wych pro­ce­sów fir­my ryn­ko­wej. Jak ktoś ma czas to może zali­czyć tak­że ​„mar­ke­ting” Kottlera to jed­nak jest bar­dziej ope­ra­cyj­ny opis zarzą­dza­nia. Polecam tak­że gorą­ca ZarządzanieP.Druckera.

Podsumowując: sys­te­my dla biz­ne­su two­rzo­ne są na proś­bę tego biz­ne­su by w tym biz­ne­sie poma­gać. Dlatego biz­nes na każ­dym kro­ku musi rozu­mieć opis tego co dosta­nie od ana­li­ty­ka wyma­gań zaś na począ­tek nale­ży opi­sać (zamo­de­lo­wać) sam biz­nes i do tego potrzeb­ne są mię­dzy inny­mi mode­le biz­ne­so­we i mode­le pro­ce­sów biznesowych.

Metodyki inży­nie­rii opro­gra­mo­wa­nia, sto­so­wa­ne tak­że w ana­li­zie wyma­gań na tak zwa­ne ​„goto­we sys­te­my”, zorien­to­wa­ne na model biz­ne­so­wy i model dzie­dzi­ny sys­te­mu nale­żą do naj­sku­tecz­niej­szych i para­dok­sal­nie naj­rza­dziej sto­so­wa­nych. Dlaczego? Moim zda­niem wła­śnie dla­te­go, że w wie­lu przy­pad­kach pomi­ja sie etap rze­tel­nej ana­li­zy biz­ne­so­wej w pro­jek­tach IT pozwa­la­jąc, by opis wyma­gań wyko­nał od razu inży­nier ​„bo to taniej”.

2010 r. Notatka: ​„Zdaniem ana­li­ty­ków fir­my decy­du­ją­ce się na wdro­że­nie sys­te­mu ERP mogą unik­nąć roz­jeż­dza­ją­cych się ter­mi­nów i nad­mier­nie wyso­kich kosz­tów dzię­ki odpo­wied­nio prze­pro­wa­dzo­nej ana­li­zie przed­wdro­że­nio­wej. Eksperci pod­kre­śla­ją bowiem, że więk­szość kosz­tów gene­ro­wa­nych przez pro­jekt wdro­że­nio­wy nie ma nic wspól­ne­go z kosz­tem same­go opro­gra­mo­wa­nia. ​„Średnio trzy czwar­te budże­tu pochła­nia­ją kosz­ty wdro­że­nia, mody­fi­ka­cji stan­dar­do­wej funk­cjo­nal­no­ści oraz moder­ni­za­cji sprzę­tu” – czy­ta­my w rapor­cie Panorama Consulting Group.” (źr. IDG, 2010r)

P.S. 2016 r. 

Osobom zain­te­re­so­wa­nym pole­cam opis jed­nej z meto­dyk ana­li­zy wyma­gań i pro­jek­to­wa­nia zorien­to­wa­nych na model biz­ne­so­wy i model dzie­dzi­ny sys­te­mu wraz z przy­kła­do­wym pro­jek­tem opi­sa­ny w mojej książ­ce Analiza Biznesowa.