złożoność złożony system skomplikowany http://hikingartist.files.wordpress.com/

Zarządzanie wymaganiami

Wczoraj pod­czas dru­gie­go dnia dnia kon­fe­ren­cji EOIF jeden z refe­ra­tów (Zarządzanie wyma­ga­nia­mi biz­ne­so­wy­mi dla sys­te­mów IT wspie­ra­ją­cych elek­tro­nicz­ny obieg infor­ma­cji, Sylwia Raczko, Carrywater Group S.A.). Nie podej­mę pró­by powtó­rze­nia go, nie taki mam cel. Będzie tu kil­ka słów ode mnie. Ale po kolei.

Etap pierwszy to analiza otoczenia projektu

Najczęściej pomi­ja­ny etap w pro­jek­tach. Moim zda­niem z dwóch powo­dów. Mało któ­ry spon­sor pro­jek­tu ma świa­do­mość jakie ryzy­ka nie­sie brak wie­dzy o oto­cze­niu pro­jek­tu, bo jako spon­sor już uwie­rzył w jego suk­ces (cho­ro­ba zna­na jako emo­cjo­nal­ne podej­ście do wła­snych pomy­słów). Drugi powód to fakt, że wie­lu inte­re­sa­riu­szy pro­jek­tu ma inte­res w tym, by te ryzy­ka nie zosta­ły ujaw­nio­ne. ten etap to pierw­szy ele­ment, któ­re­go reali­za­cja napo­ty­ka opo­ry, a moim zda­niem powi­nien być wyko­na­ny nie raz przez zawar­ciem głów­nej umo­wy, gdyż może się oka­zać, że pro­jekt jest z góry ska­za­ny na porażkę.

Z per­spek­ty­wy każ­de­go sys­te­mu (sys­tem to nie tyl­ko opro­gra­mo­wa­nie, to tak­że sys­tem zarzą­dza­ni jako­ścią czy nowy sys­tem raba­to­wy) nale­ży opra­co­wać model uwzględ­nia­ją­cy tych, któ­rzy będę z nie­go bez­po­śred­nio korzy­sta­li (akto­rzy) oraz tych, któ­rzy odczu­ją skut­ki jego wdro­że­nia a mają wpływ na jego powsta­wa­nie. Taka ana­li­za wpły­wu pozwo­li oce­nić ryzy­ka gene­ro­wa­ne przez każ­de­go inte­re­sa­riu­sza i wła­ści­wie na nie zare­ago­wać. Jednym z pro­duk­tów takiej ana­li­zy jest plan komu­ni­ka­cji. Mamy więc na tym eta­pie produkty:

  1. model oto­cze­nia sys­te­mu (pro­jek­tu),
  2. ana­li­za ryzyka,
  3. plan komu­ni­ka­cji.

Więcej o tym eta­pie w arty­ku­le Udziałowcy pro­jek­tu czy­li któ­ry dia­gram UML (czy­taj).

Etap drugi analiza i specyfikowanie wymagań

Ten etap jest naj­więk­szą czę­ścią pro­jek­tu ana­li­tycz­ne­go. Jak zebrać wyma­ga­nia to tema rze­ka. Ogólnie meto­dy ana­li­zy i spe­cy­fi­ko­wa­nia wyma­gań moż­na podzie­lić na dwie grupy:

  1. meto­dy formalne,
  2. meto­dy nieformane.

Pierwsze opie­ra­ją się na zasto­so­wa­niu sfor­ma­li­zo­wa­nych sys­te­mów poję­cio­wych i wery­fi­ko­wal­nym pro­ce­sie ana­li­tycz­nym czy­li po pro­tu na sto­so­wa­niu okre­ślo­nych nota­cji (z regu­ły BMMBPMN) oraz ana­li­zy systemowej.

Drugie bazu­ją na spo­tka­niach, warsz­ta­tach, mode­ro­wa­nych sesjach. Ich głów­ną cechą jest uzna­nie, że tak zebra­ne dane są wia­ry­god­ne: uzna­nie a prio­ri, że zama­wia­ją­cy się nie myli i ma rację. Jakkolwiek to brzmi, nie jest to takie oczy­wi­ste. Wykazanie nie­sprzecz­no­ści tak zebra­nych wyma­gań jest wyko­nal­ne ale już ich spój­ność i kom­plet­ność jest nie do wyka­za­nia bo nie ist­nie­je test kom­plet­no­ści opo­wia­da­nia”, sko­ro nie moż­na wyka­zać (prze­te­sto­wać) kom­plet­no­ści to tym bar­dziej nie da się wyka­zać spójności.

Metody for­mal­ne bazu­ją na ana­li­zie od ogó­łu do szcze­gó­łu” orga­ni­za­cji i opra­co­wa­niu jej kom­plet­ne­go mode­lu (na wyma­ga­nym dla danej ana­li­zy pozio­mie szcze­gó­ło­wo­ści). Model taki sta­je się narzę­dziem testo­wa­nia wyma­gań, np. mając mode­le wszyst­kich pro­ce­sów biz­ne­so­wych może­my spraw­dzić, czy nie pomi­nę­li­śmy jakichś istot­nych dzia­łań, któ­re wyma­ga­ły by uję­cia w wymaganiach.

Bardzo waż­na rze­czą jest jest podzie­le­nie wyma­gań na biz­ne­so­we i funk­cjo­nal­ne bo to nie to samo (czy­taj Produkty w pro­ce­sie ana­li­zy wyma­gań). Pani Raczko przy­wo­ła­ła defi­ni­cję Rona Ross’a, jed­nak chy­ba zbyt upro­ści­ła ory­gi­nał spro­wa­dza­jąc sło­wo sys­tem” do opro­gra­mo­wa­nie”. Znany mi ory­gi­nał brzmi:

We defi­ne a busi­ness requ­ire­ment as ?some­thing cal­led for or deman­ded by a busi­ness model that a sys­tem model must support?

We defi­ne a sys­tem model as fol­lows a model that pro­vi­des a design for an auto­ma­ta­ble sys­tem that is com­pu­ta­tio­nal­ly competent.

(źr. What?s the Difference Between Business Requirements and Functional Requirements?)

Rzecz w tym, że sło­wo com­pu­ta­tio­nal” ozna­cza wyli­czal­ność” w rozu­mie­niu da się wyli­czać auto­ma­tycz­nie (raczej w sen­sie algo­ryt­micz­nym). To nie koniecz­nie musi być kom­pu­ter, mogą to być okre­ślo­ne do wdro­że­nia pro­ce­du­ry (przy­po­mnę, że przed­mio­tem pro­jek­to­wa­nia może być sys­tem zarzą­dza­nia jako­ścią lub sys­tem raba­to­wy sprze­da­ży). Warto zwró­cić uwa­gę, że Ross nie użył sło­wa requ­ire­ment” (wyma­ga­nia) w odnie­sie­niu do sys­te­mu a model”. Ross tak­że słusz­nie zauwa­ża, że wiki­pe­dia zrów­nu­je poję­cie wyma­gać z wyma­ga­nia­mi funk­cjo­nal­ny­mi co jest i moim zda­niem błę­dem. Prawdopodobnie to uprosz­cze­nie w pre­zen­ta­cji zosta­ło doko­na­ne z uwa­gi na tema­ty­kę kon­fe­ren­cji, uwa­żam jed­nak, że jest groź­ne. Mam wszyst­kie książ­ki Ross’a i wyda­je mi się, że nie zrów­nu­je on poję­cia sys­tem z oprogramowaniem.

Wymagania biz­ne­so­we w sto­sun­ku do wyma­gań sys­te­mo­wych” cechu­je inna bar­dzo waż­na róż­ni­ca: treść wyma­gań biz­ne­so­wych MUSI być w 100% zro­zu­mia­ła dla zama­wia­ją­ce­go, napi­sa­na jego języ­kiem. Model sys­te­mu, jako wyma­ga­nia na sys­tem, może być (i z regu­ły jest) już wie­dzą tajem­ną” zro­zu­mia­łą tyl­ko dla dostaw­cy systemu.

Zarządzanie zmianą wymagań

To kolej­ne nie­chcia­ne dziec­ko w pro­jek­tach. Jeżeli zgo­dzi­my się, że zmia­na wyma­gań jest nor­mą” to brak wie­dzy (zapi­sów) o tych zmia­nach potra­fi zabić pro­jekt. Problem, któ­ry ja widzę w wie­lu pro­jek­tach to: im łatwiej zgło­sić i egze­kwo­wać zmia­nę w wyma­ga­niach tym wię­cej tych zmian jest. Nie cho­dzi o to by tych zmian zaka­zy­wać, cho­dzi o to by były one za każ­dym razem prze­my­śla­ne, a cho­dzi głow­nie o wpływ zmian na ter­min i budżet projektu.

Ja tak­że widzę tu dużą róż­ni­cę. Z moich obser­wa­cji wyni­ka, że pro­jek­ty, w któ­rych zasto­so­wa­no zwin­ne meto­dy zarzą­dza­nia nimi, bar­dzo czę­sto tra­cą kon­tro­lę nad zakre­sem pro­jek­tu. Po pierw­sze dla­te­go, że wpro­wa­dza­nie zmian bez ich doku­men­to­wa­nia i świa­do­me­go prze­pro­jek­to­wy­wa­nia sys­te­mu, pro­wa­dzi do nie­kon­tro­lo­wa­ne­go przy­ro­stu pra­cy. Po dru­gie pro­jek­ty zwin­ne cechu­je to, że nie mają opi­sa­ne­go zakre­su pro­jek­tu a jedy­nie wizje pro­duk­tu jaki ma powstać, w efek­cie jedy­nym ele­men­tem pro­jek­tu jakim zarzą­dza kie­row­nik pro­jek­tu jest prak­tycz­nie tyl­ko budżet gdyż zakres jako taki nie ist­nie­je a har­mo­no­gram to tyl­ko na bie­żą­co defi­nio­wa­ne etapy.

Zarządzanie wymaganiamiUogólniając nie­co: w meto­dach kla­sycz­nych ist­nie­je sztyw­na gra­ni­ca pomię­dzy fazą ana­li­zy i spe­cy­fi­ko­wa­nia wyma­gań a fazą ich imple­men­ta­cji. W meto­dach zwin­nych mamy pętlę zgła­sza­nia zmian (i nowych wyma­gań), któ­ra z regu­ły nie jest dokumentowana.

Czy to powo­du­je, że w meto­dach kla­sycz­nych odci­na­my sobie moż­li­wość zasto­so­wa­nia nowych pomy­słów? Absolutnie nie, nowe pomy­sły są mate­ria­łem na nowy pro­jekt. Zgłaszane zmia­ny są ana­li­zo­wa­ne i albo są akcep­to­wa­ne bo mają mały lub żaden wpływ na budżet i har­mo­no­gram, albo są odkła­da­ne na etap eks­plo­ata­cji i roz­wo­ju” w cyklu życia pro­duk­tu (nowy cel pro­jek­tu i nowy pro­jekt). Pani Raczko stwier­dzi­ła, że jej doświad­cze­nie wska­zu­je, że pro­jek­ty pro­wa­dzo­ne meto­dą kla­sycz­ną są z regu­ły szyb­ciej koń­czo­ne, ale doty­czy to raczej więk­szych pro­jek­tów. Moje doświad­cze­nia są ana­lo­gicz­ne. Granicą któ­rą kie­dyś obli­cza­łem, po prze­kro­cze­niu któ­rej war­to zre­zy­gno­wać z metod zwin­nych, jest budżet prze­kra­cza­ją­cy 100 tys. zł. Jak widać nie są to aż tak wiel­kie pro­jek­ty. Jednak dla każ­dej fir­my utra­ta 100 tys. zł (nie­uda­ny pro­jekt) sta­no­wi bar­dzo odczu­wal­ny wydatek.

Jak wyglą­da taka zmiana?

Zarządzanie zmianą

Kluczowe korzy­ści to kom­plet­na doku­men­ta­cja pro­jek­tu, jest ona nie tyl­ko pomoc­na po jego zakoń­cze­niu, ale tak­że w trak­cie jego trwa­nia, gdyż sta­no­wi narzę­dzie kon­tro­li budże­tu. Bardzo złym mier­ni­kiem postę­pu pro­jek­tu jest dekla­ro­wa­nie zuży­wa­nych zaso­bów (robo­czo­go­dzi­ny lub dni), w zwin­nych meto­dach to w zasa­dzie jest to jedy­ny mier­nik. Jeżeli zaś dys­po­nu­je­my doku­men­ta­cją każ­dej zmia­ny, jest ona znacz­nie bar­dziej wia­ry­god­nym mier­ni­kiem postę­pu pro­jek­tu, gdyż zarzą­dza­my pro­jek­tem zada­nio­wo a nie zaso­bo­wo. W meto­dach zwin­nych nie da się wyko­nać ana­li­zy wpły­wu zmia­ny na cały pro­jekt, bo nie ist­nie­je doku­men­ta­cja całe­go sys­te­mu (jego model), on dopie­ro powsta­je w trak­cie trwa­nia pro­jek­tu. Tak więc w zasa­dzie nie ist­nie­je poję­cie ana­li­zy ryzy­ka zgła­sza­nej zmia­ny w meto­dach zwin­nych. W meto­dzie kla­sycz­nej, mamy udo­ku­men­to­wa­ny, każ­dy etap pro­jek­tu co, poza ewen­tu­al­ny­mi spo­ra­mi o zakres, pozwa­la pano­wać nad spój­no­ścią i nie­sprzecz­no­ścia zgła­sza­nych zmian wyma­gań, gdyż spe­cy­fi­ka­cja – jako całość – przez cały czas trwa­nia pro­jek­tu (a nie tyl­ko na począt­ku) ma być kom­plet­na, spój­na i niesprzeczna.

Na koniec narzędzia

W tej kwe­stii jed­no jest pew­ne: jeże­li już uzna­my, że wyma­ga­nia­mi zarzą­dza­my, to robie­nie tego narzę­dzia­mi biu­ro­wy­mi (edy­tor tek­stu, arkusz kal­ku­la­cyj­ny, pro­ste opro­gra­mo­wa­nie do dia­gra­mów typu Visio) strasz­nie pod­nie­sie pra­co­chłon­ność pro­jek­tu (czy­taj o sabo­ta­żu doku­men­ta­cyj­nym). Klienci, któ­rzy uwa­ża­ją, że wol­no użyć tyl­ko narzę­dzi, któ­rych sami na co dzień uży­wa­ją, sami sobie robią krzyw­dę, bo zgła­sza­nie zmian nie pole­ga na mody­fi­ka­cji cudzych doku­men­tów pro­jek­to­wych, a na two­rze­niu wła­snych (czy­taj o zgła­sza­niu zmian).

Biorąc pod uwa­gę fakt, że wyma­gań w śred­nim nawet pro­jek­cie jest co naj­mniej kil­ka­dzie­siąt, utrzy­ma­nie ich spój­no­ści i ana­li­za wpły­wu każ­dej zmia­ny na cały pro­jekt sta­je się bene­dyk­tyń­ską pra­cą, naj­czę­ściej szyb­ko zarzu­ca­ną wła­śnie z powo­du pra­co­chłon­no­ści (a nie bra­ku jej sen­su). Dlatego w zasa­dzie brak narzę­dzia CASE do zarzą­dza­nia wyma­ga­nia­mi (są z regu­ły czę­ścią narzę­dzi do ana­li­zy i mode­lo­wa­nia) w zasa­dzie w moich oczach dys­kwa­li­fi­ku­je usługodawcę.

Z powyż­sze­go pły­nie tak­że kolej­ny wnio­sek: autor spe­cy­fi­ka­cji wyma­gań, powi­nien kon­ty­nu­ować pro­jekt jako oso­ba zarzą­dza­ją­ca wyma­ga­nia­mi, i bar­dzo dobrze jest jeże­li pra­cu­je po stro­nie Zamawiającego, gdyż sta­no­wi natu­ral­ny mecha­nizm kon­tro­li pra­cy dostaw­cy np. opro­gra­mo­wa­nia. Zamawiający nie ma innej moż­li­wo­ści real­ne­go, mery­to­rycz­ne­go nad­zo­ru nad dostaw­cą, to Zamawiający powi­nien zarzą­dzać wyma­ga­nia­mi bo to w koń­cu jego wymagania!

Inne artykuły na podobny temat

Dodaj komentarz

Twój adres email nie zostanie opublikowany

Komentuj i zadawaj pytania autorowi.

Identyfikator *
E-mail *
Witryna internetowa

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.