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…

Jedno wymaganie – kilka perspektyw

Wpadł mi nie­daw­no do skrzyn­ki mailo­wej kolej­ny arty­kuł ser­wi­su Modern Analyst, cytat:

If you cre­ate only one view of the requ­ire­ments, you must belie­ve it. You have no other cho­ice. If you deve­lop mul­ti­ple views, tho­ugh, you can com­pa­re them to look for discon­nects that reve­al errors and dif­fe­rent inter­pre­ta­tions. (źr. Why Create Multiple Requirements Views? > Business Analyst Community & Resources | Modern Analyst > Business Analyst Articles & Systems Analysis Articles | Modern Analyst).

Autor suge­ru­je by łączyć wyma­ga­nia funk­cjo­nal­ne z przy­pad­ka­mi uży­cia, testa­mi, mode­la­mi. W dużym uprosz­cze­niu: jeże­li mamy tyl­ko jed­ną per­spek­ty­wę wyma­gań (np. w posta­ci listy wyma­gań funk­cjo­nal­nych i poza­funk­cjo­nal­nych) musi­my im wie­rzyć bo nie mamy ich wery­fi­ka­to­ra (nie mamy inne­go wyj­ścia). Troszkę to łącze­nie każ­dy z każ­dym” chy­ba jed­nak nie ułatwia:

źr. http://​www​.moder​na​na​lyst​.com/

Problem kom­plet­no­ści i spój­no­ści wyma­gań jest dość trud­ny do roz­wią­za­nia. Wymagania nie­kom­plet­ne i nie­spój­ne potra­fią zaś zabić pro­jekt, wady spe­cy­fi­ka­cji (takie jak nie­kom­plet­ność i nie­spój­ność) skut­ku­ją odkry­wa­niem ich w trak­cie pro­jek­tu, rośnie w nie­kon­tro­lo­wa­ny spo­sób zło­żo­ność projektu.

Jeżeli wypra­cu­je­my wię­cej per­spek­tyw, może­my je skon­fron­to­wać i porów­nać, wykry­wa­jąc ewen­tu­al­ne nie­ści­sło­ści i błę­dy. Także [[BABoK]] (rodem z [[IIBA]]) zale­ca utrzy­my­wa­nie tak zwa­nej śla­do­wal­no­ści, to jest wywo­dze­nia np. wyma­gań na opro­gra­mo­wa­nie z wyma­gań biz­ne­so­wych, a tych z celu pro­jek­tu. Nadal jed­nak mamy tyl­ko jed­no źró­dło dla każ­de­go wyma­ga­nia. To rodzi pew­ne ryzy­ko, gdyż brak wery­fi­ka­to­ra powo­du­je, że ryzy­ko błę­du pozostaje.

Od kil­ku lat sto­su­je meto­dę pole­ga­ją­cą na testo­wa­niu lub spe­cy­fi­ko­wa­niu reli­za­cji wyma­gań. Rok 2008, na zakoń­cze­nie arty­ku­łu IEEE830-1998 ? czy pro­du­ku­je dobre wyma­ga­nia? napisałem:

Metodyka, któ­rą stosuję

  1. Wymagania funk­cjo­nal­ne to przy­pad­ki uży­cia sys­te­mu; Przypadki uży­cia sys­te­mu to czyn­no­ści wyse­lek­cjo­no­wa­ne z mode­lu pro­ce­sów na bazie zakre­su projektu.
  2. Wymagania nie­funk­cjo­nal­ne to ogra­ni­cze­nia nakła­da­ne na poszcze­gól­ne przy­pad­ki uży­cia (mogą być gru­po­wa­ne np. mak­sy­mal­ny czas odpo­wie­dzi sys­te­mu nie może prze­kro­czyć 1 s. z wyjąt­kiem rapor­tów, gdzie mak­sy­mal­ny czas odpo­wie­dzi to 1 minuta)
  3. Wymagania dzie­dzi­no­we opi­sy­wa­ne są mode­lem dzie­dzi­ny sys­te­mu (dia­gram klas lub ERD)

c.d. kie­dyś nastąpi?

Tak więc mamy ciąg dal­szy :). Wspomniałem o wyma­ga­niach dzie­dzi­no­wych. Osobiście trak­tu­ję je wła­śnie jako trze­cią nogę” wspie­ra­ją­cą model wyma­gań. Funkcjonalność (usłu­ga sys­te­mu) mówi nam cze­go ocze­ku­je użyt­kow­nik, jed­nak usłu­ga sys­te­mu” opi­su­je sys­tem jako tak zwa­ną czar­ną skrzyn­kę”. Jeżeli uzu­peł­ni­my opis wyma­gań ele­men­ta­mi mode­lu dzie­dzi­ny, doda­my wery­fi­ka­tor w posta­ci opi­su wnę­trza tej czar­nej skrzyn­ki (wyma­ga­my nie tyl­ko two­rze­nia fak­tu­ry VAT” ale defi­niu­je­my jej struk­tu­rę, to się nazy­wa opis bia­łej skrzynki”).

Jak wspo­mnia­łem swe­go cza­su, opra­co­wu­jąc wyma­ga­nia na goto­we i zaawan­so­wa­ne opro­gra­mo­wa­nie nie ma sen­su jego pro­jek­to­wa­nie. Zbyt szcze­gó­ło­wa spe­cy­fi­ka­cja zbli­ża nas do pro­jek­tu, a my chce­my jed­nak coś goto­we­go (ma być taniej i szybciej).

Standardowo, spe­cy­fi­ku­jąc wyma­ga­nia, nale­ży sku­pić się na tym do cze­go będzie­my uży­wa­li opro­gra­mo­wa­nia a nie na tym jak ono to robi. Jednak do cze­go” ozna­cza co będzie­my two­rzyć i prze­twa­rzać”. Co więc robić? Proszę popatrzeć:

Tak więc wymaganie:

  1. koja­rzy­my z reali­zu­ją­cym je mode­lem (przy­pad­kiem uży­cia, pro­ce­sem, ele­men­tem dziedziny),
  2. koja­rzy­my z testem spraw­dza­ją­cym czy zosta­ło speł­nio­ne (z pomo­cą dobra­ne­go sce­na­riu­sza testowego).

Powszechnie posłu­gu­je­my się wyma­ga­nia­mi funk­cjo­nal­ny­mi. Czym jest wyma­ga­nie dzie­dzi­no­we? Wyobraźmy sobie, że chce­my opi­sać wszyst­kie meto­dy i sce­na­riu­sze wysta­wie­nia fak­tu­ry VAT. Będzie ich bar­dzo dużo, zapew­ne moż­li­we będą takie, któ­rych nie wymy­śli­li­śmy”. Bezpieczniej jest opi­sać fak­tu­rę VAT wraz z regu­ła­mi rzą­dzą­cy­mi jej poszcze­gól­ny­mi pola­mi, zamiast uznać ją za czar­ną skrzyn­kę” i pró­bo­wać opi­sać meto­dą jak moż­na jej użyć”.

Młotek moż­na opi­sać tym do cze­go będzie uży­wa­ny” (przy­pad­ki uży­cia) lub jak wyglą­da”. Nie raz dru­ga meto­da jest bez­piecz­niej­sza, jed­nak jest to już pro­jek­to­wa­nie i nale­ży to robić świa­do­mie. Czy to źle? Nie, bo nie raz zapro­jek­to­wa­nie jest mniej ryzy­kow­ne niż opis do cze­go” (zamiast zło­żo­ne­go opi­su wie­lu zasto­so­wań młot­ka, pro­ściej jest go narysować).

Zawsze, przy każ­dym wyma­ga­niu, nale­ży pod­jąć decy­zję, czy reali­za­cja wyma­ga­nia przez dostaw­cę sta­no­wi ryzy­ko (i jakie). Sami pro­jek­tu­je­my reali­za­cję (two­rzy­my model) zawsze, gdy to ryzy­ko jest za duże by je akcep­to­wać. Podobnie trak­tu­je­my testy. Projektujemy je, gdy koszt nie­speł­nie­nia dane­go wyma­ga­nia prze­kra­cza dopusz­czal­ny poziom. Testem może być tak­że model (np. pro­ce­su biznesowego).

Takie podej­ście powo­du­je, że zanim jesz­cze dotknie­my goto­we­go pro­duk­tu (tu nie­ste­ty już po jego wybo­rze) może­my po pierw­sze: prze­te­sto­wać samą spe­cy­fi­ka­cję a po dru­gie prze­ka­zać poten­cjal­ne­mu dostaw­cy (na eta­pie zapy­ta­nia) peł­ną infor­ma­cję o tym, cze­go ocze­ku­je­my od pro­duk­tu i jak to sprawdzimy.

Powyższe podej­ście w posta­ci «full wypas” może być pra­co­chłon­ne, dla­te­go moż­li­we są warian­ty pośred­nie, czy­li tyl­ko dla wyma­gań ozna­czo­nych jako ryzy­kow­ne budu­je­my testy lub mode­le, jed­nak mamy narzę­dzie do pano­wa­nia nad tym ryzy­kiem. Po dru­gie zysku­je­my narzę­dzie do wery­fi­ka­cji, odbiór opro­gra­mo­wa­nia nie będzie spraw­dza­niem pokaź­nej i ryzy­kow­nej zara­zem listy dzie­sią­tek cech, będzie jaz­dą prób­ną na sucho”, a więc rela­tyw­nie tanią i pew­ną meto­dą testów: dostaw­ca dekla­ru­je (ofer­ta na nasze zapy­ta­nie) zgod­ność z naszy­mi wyma­ga­nia­mi, a te są wery­fi­ko­wal­ne. Należy roz­wa­żać zawsze koja­rze­nie mode­li z testami.

Kiedy jesz­cze pisze­my reali­za­cję”? Gdy chce­my pozo­stać jej auto­ra­mi i chro­nić nasz know-how.

Managing Requirements from a Business Analyst or an Enterprise Architect perspective using BABOK 2.0 and/or TOGAF 9

Na począ­tek pod­su­mo­wa­nie cyto­wa­ne­go artykułu:

BABOK 2.0 sets up a fra­me­work for the requ­ire­ments deve­lop­ment and mana­ge­ment, which seems to appe­ar as a stan­dard used by many orga­ni­za­tions aro­und the world. Between TOGAF 9 and BABOK 2.0, the­re is almost 1:1 cor­re­spon­den­ce but the­re may be more deta­ils and acti­vi­ties in the first one. TOGAF is a metho­do­lo­gy whe­re­as the BABOK is metho­do­lo­gy agno­stic, so it can be tric­ky to trans­la­te betwe­en the two but nothing pre­vent an Enterprise Architecture team to use this ana­lo­go­us technique.

If an orga­ni­za­tion fol­lows the TOGAF metho­do­lo­gy and Business Analysts use BABOK, the later will pro­vi­de a lot of use­ful infor­ma­tion, as a refe­ren­ce; BABOK won’t give you direc­tion for an Enterprise Architecture.

Sources: Chapter 4 IIBA?s BABOK 2.0, TOGAF 9 (źr. Managing Requirements from a Business Analyst or an Enterprise Architect per­spec­ti­ve using BABOK 2.0 and/or TOGAF 9.)

W kil­ku zda­niach. Diagram poni­żej obra­zu­je dwa róż­ne spoj­rze­nia na to samo”:

BABoK vs. TOGAF
BABoK vs. TOGAF

Autor arty­ku­łu porów­nu­je obie te spe­cy­fi­ka­cje i poka­zu­je, że są prak­tycz­nie zgod­ne w 100%, nie licząc meto­dy pre­zen­ta­cji i per­spek­ty­wy. W obu przy­pad­kach ma miej­sce ana­li­za, porów­na­nie i spe­cy­fi­ka­cja celów biz­ne­so­wych oraz przy­po­rząd­ko­wa­nie ich do narzę­dzi (głów­nie ale nie tyl­ko IT) wspie­ra­ją­cych reali­za­cję tego celu. Jeżeli uznać, że spe­cy­fi­ka­cja coś opi­su­je, to zależ­nie od fazy pro­jek­tu jest spe­cy­fi­ka­cją potrzeb a potem spe­cy­fi­ka­cją tego co się posia­da (jak uda się zakup ;)).

Sprawna Inżynieria Oprogramowania: Ekstremalna obiektowość

Jestem gorą­cym fanem blo­gów dobrych (tak sądzę, że są ;)) pro­gra­mi­stów. Dlaczego? Bo to oni się męczą z moimi pro­jek­ta­mi. O czym powi­nien pamię­tać dobry ana­li­tyk pro­jek­tant? O dwóch rze­czach (zresz­tą o tym powi­nie pamię­tać każ­dy): po pierw­sze nie zapo­mi­naj kim jest Twój klient – mów do nie­go jego języ­kiem, po dru­gie jak coś two­rzysz dla swo­je­go klien­ta to nie po to by on musiał to jesz­cze raz po Tobie zro­bić po swojemu.

Analitycy jako zasoby

W pro­jek­tach infor­ma­tycz­nych naj­czę­ściej spo­ty­ka­my: ana­li­ty­ka wyma­gań (AW), ana­li­ty­ka sys­te­mo­we­go (AS), dewe­lo­pe­ra w tym archi­tek­ta sys­te­mu (D). W zasa­dzie trud­no powie­dzieć co jest pro­duk­tem dwóch pierw­szych bo Deweloper odda­je dzia­ła­ją­ce opro­gra­mo­wa­nie. Najczęściej AW dostar­cza jakiś opis tego cze­go ocze­ku­je klient, AS porząd­ku­je to co zro­bił AW np. z pomo­cą przy­pad­ków uży­cia a D bie­rze to do ręki i musi zapro­jek­to­wać i wyko­nać opro­gra­mo­wa­nie. Jak widać, odpo­wie­dzial­ność za to co powsta­nie jest roz­my­ta. Klient naj­pierw prze­ka­zu­je swo­je ocze­ki­wa­nia AW zaś otrzy­mu­je pro­dukt od D. Konia z rzę­dem temu, kto mi powie jak tego doko­nać bez per­ma­nent­nych ite­ra­cyj­nych wyja­śnień i bom­bar­do­wa­nia Klienta pyta­nia w rodza­ju co Państwo mie­li na myśli pisząc/mówiąc, że …”.

Od koń­ca. By powsta­ło opro­gra­mo­wa­nie (zakła­dam na dziś, że meto­da­mi obiek­to­wy­mi) musi powstać jego spe­cy­fi­ka­cja, pro­jekt któ­ry dokład­nie opi­su­je co mają zako­do­wać pro­gra­mi­ści. Bez tego nie wia­do­mo ani co ma powstać ani ile to wyma­ga pra­cy. Aby powsta­ła spe­cy­fi­ka­cja musi powstać opis logi­ki sys­te­mu bo tego wła­śnie ocze­ku­je Klient. Aby ta logi­ka powsta­ła trze­ba dokład­nie zro­zu­mieć to cze­go klient ocze­ku­je, jako że ocze­ku­je narzę­dzia wspo­ma­ga­ją­ce­go zarzą­dza­nie jego fir­mą, nale­ży tę fir­mę dokład­nie opi­sac a wcze­śniej zrozumieć.

W czym pro­blem? Mając trzy role w pro­jek­cie: AW, AS i D powsta­je zaba­wa w głu­chy tele­fon, któ­ra koń­czy się tym, że kon­tak­tu­ją się z Klientem wszy­scy bo opis słow­ny wyma­gań z regu­ły jest nie­pre­cy­zyj­ny i nie­kom­plet­ny. AS na bazie tego opi­su coś pro­jek­tu­je, D two­rzy pierw­szą wer­sje sys­te­mu. Klient to dosta­je i zgła­sza uwa­gi i ocze­ki­wa­nia, bo to tak na praw­dę jego pierw­szy kon­takt z pro­duk­tem. Proces ten zna każ­dy kto brał udział w takim pro­jek­cie (pozo­sta­łych prze­strze­gam przez takim podejściem).

Powyżej opi­sa­ny bieg wyda­rzeń to zaso­bo­we (silo­so­we) podej­ście do pro­jek­tu: jak użyć ludzi o posia­da­nych kompetencjach.

Analityk i deweloper jako właściciele procesów

Jak nale­ża­ło się spo­dzie­wać, musia­ło to dopro­wa­dzić do szu­ka­nia roz­wią­za­nia. Podobnie jak w zarzą­dza­niu w innych obsza­rach, zaczy­na­my mówić o pro­ce­sie wytwa­rza­nia opro­gra­mo­wa­nia”. A sko­ro mowa o pro­ce­sie to powin­ny się poja­wić pro­duk­ty poszcze­gól­nych pod-pro­ce­sów, ich wyko­naw­cy są wtór­ni wobec pro­duk­tów. Najpierw defi­niu­je­my pro­dukt potem wska­zu­je­my odpowiedzialnego.

W pro­ce­sie wytwa­rza­nia opro­gra­mo­wa­nia potrzeb­ne sa trzy produkty:

  1. opis celu biz­ne­so­we­go i stra­te­gii jego osią­gnię­cia, jed­nym z narzę­dzie zapew­ne będzie jakieś oprogramowanie,
  2. pro­jekt opro­gra­mo­wa­nia, nale­ży je zaprojektować,
  3. wyko­na­ne (dostar­czo­ne) oprogramowanie.

Mamy więc trzy ocze­ki­wa­ne pro­duk­ty czy­li trzy pro­ce­sy: ana­li­za biz­ne­so­wa, pro­jek­to­wa­nie, wyko­na­nie (imple­men­ta­cja). Projekt jest ści­śle powią­za­ny z ana­li­zą biz­ne­so­wa, gdyż powsta­je na bazie niej i jej peł­ne­go zro­zu­mie­nia, nasu­wa to wnio­sek, że jed­na oso­ba powin­na odpo­wia­dać za pro­jekt i dobrze jest jeśli będzie to autor ana­li­zy biz­ne­so­wej. Jakie roz­wią­za­nie jest więc skuteczne?

Tym roz­wią­za­niem wyda­ja się być:

  1. meto­dy obiek­to­we ana­li­zy, pro­jek­to­wa­nia i implementacji,
  2. podział pro­ce­su na dwa eta­py i dwie role: opra­co­wa­nie pro­jek­tu logi­ki sys­te­mu i implementacja,
  3. [[wzo­rzec pro­jek­to­wy MVC]] i [[pro­jek­to­wa­nie meto­dą DDD]].

W dużym uproszczeniu:

  1. meto­dy obiek­to­we pozwa­la­ją na uży­wa­nie od same­go począt­ku tego same­go spo­so­bu opi­su (mode­lo­wa­nia) roz­wią­za­nia, któ­re powsta­je w mia­rę postę­pów ana­li­zy, zapis tego cze­go ocze­ku­je Klient to Przypadki Użycia (czar­na skrzyn­ka) oraz Model Dziedziny (pro­jekt – bia­ła skrzynka),
  2. do two­rze­nia opro­gra­mo­wa­nia uży­wa się obec­nie naj­czę­ściej fra­me­wor­ków bazu­ją­cych na [[wzor­cu MVC]] dla któ­re­go [[Model Dziedziny]] zapro­jek­to­wa­ny zgod­nie z DDD, jest goto­wym pro­jek­tem logi­ki kom­po­nen­tu Model z MVC zaś Przypadki Użycia to wyma­ga­nia na inter­fejs użyt­kow­ni­ka opi­sa­ny jak V w MVC (kom­po­nent C – kon­tro­ler – odpo­wia­da za ste­ro­wa­nie apli­ka­cją i reali­za­cję wyma­gań poza-funkcjonalnych).

Można wiec powie­dzieć, że kie­ru­nek jest taki:

Tak więc z trzech, nie­ja­sno okre­ślo­nych ról two­rzą sie dwie:

  1. Analityk Biznesowy, któ­re­go rolą jest dostar­czyć wyma­ga­nia funk­cjo­nal­ne (przy­pad­ki uży­cia wraz z ogra­ni­cze­nia­mi) oraz Model Dziedziny,
  2. Deweloper, któ­re­go rolą jest dostar­cze­nie opro­gra­mo­wa­nia imple­men­tu­ją­ce­go tak okre­ślo­ne Wymagania, Developer ma” Architekta Systemu czy­li pro­jek­tan­ta implementacji.

Jest to pro­mo­wa­ny” przez [[IIBA w BABoK]] pro­ces i zakres kompetencji.

Teraz kolej na dono­sy z inne­go blo­ga, jest to blog programisty:

Jeff Bay pro­po­nu­je w nim 9 reguł doty­czą­cych two­rze­nia kodu (przy­kła­dy są w javie, ale więk­szość reguł odno­sić się może do w mia­rę dowol­ne­go języ­ka, szcze­gól­nie OO). Są to:

  • Tylko jeden poziom zagłę­bie­nia na metodę
  • Nie uży­waj sło­wa klu­czo­we­go else
  • Opakowuj wszyst­kie pry­mi­ty­wy i Stringi (w kla­sy o spe­cy­ficz­nej dla zasto­so­wa­nia nazwie)
  • Używaj tyl­ko jed­nej krop­ki na linię
  • Nie skra­caj nazw
  • Pilnuj wszyst­kie encje by były małe
  • Nie uży­waj klas o wię­cej niż dwóch polach
  • Klasa któ­rej polem jest kolek­cja nie powin­na mieć żad­nych innych pól (opa­ko­wy­wa­nie kolek­cji w kla­sy spe­cy­ficz­ne dla kon­tek­stu wykorzystania)
  • Nie uży­waj getterów/setterów/własności

(źr. Sprawna Inżynieria Oprogramowania: Ekstremalna obiektowość.)

Jeżeli uznać, że to wyma­ga­nia w ogó­le na pro­jekt obiek­to­wy to są to wyma­ga­nia dla mnie: Analityka Biznesowego, na to jak ma wyglą­dać Model Dziedziny Systemu.

Po co to wszyst­ko? Bo tu nie ma głu­che­go tele­fo­nu, pro­dukt powsta­je w pierw­szej ite­ra­cji i każ­dy dokład­nie wie za co odpo­wia­da. Całość trwa kró­cej i jest mniej kosztowna.

P.S.

A tym jak taki pro­dukt, Wymagania, powsta­je pisa­łem już wcze­śniej, o tym jak się to imple­men­tu­je niech piszą programiści 🙂

P.S. 2

Polecam tak­że inne cie­ka­we spoj­rze­nie na ten pro­blem w arty­ku­le Analityk sys­te­mo­wy – łącz­nik dwóch świa­tów. Tu fak­tycz­nie sta­je się pro­ble­ma­tycz­ne stwier­dze­nie kim jest, a kim nie, ana­li­tyk sys­te­mo­wy. Być może Analityk Systemowy jest wła­ściw­szym ter­mi­nem, jed­nak ja boje się tego, że powszech­nie koja­rzo­ne z infor­ma­ty­ką poję­cie sys­tem” zabu­rza tak poj­mo­wa­ne zna­cze­nie ana­li­zy sys­te­mo­wej”, któ­ra nie koniecz­nie doty­czy sys­te­mów IT. Modelowanie biz­ne­su (firm, orga­ni­za­cji) meto­da­mi zna­ny­mi z ana­li­zy sys­te­mo­wej ([[ogól­na teo­ria sys­te­mów]]) jest chy­ba jed­nak ana­li­zą biz­ne­so­wą (tego biz­ne­su), ale mogę się mylić…

Rentowność projektu czyli jego wizja i wykonywalność – należy planować

dashboard

W arty­ku­le o szko­le­niu i ana­li­zie na bazie stan­dar­du IIBA i BABoK napi­sa­łem, że war­to pla­no­wać, pro­jek­to­wać i ana­li­zo­wać, bo wte­dy pro­jek­ty są prze­wi­dy­wal­ne zamiast być lote­rią.” (źr. IIBA czy­li ?jak to nie­któ­rzy robią w Ameryce? | Jarosław Żeliński – rynek IT, ana­li­za biz­ne­so­wa i pro­jek­to­wa­nie sys­te­mów.)

Pisząc to mam świa­do­mość tego, że przy­tła­cza­ją­ca więk­szość dostaw­ców opro­gra­mo­wa­nia wma­wia swo­im klien­tom, że oce­na ren­tow­no­ści jest nie­moż­li­wa w pro­jek­tach IT i nale­ży kupić co dają a nie jęczeć. Niestety wie­lu kupu­ją­cych w to wie­rzy i inwe­stu­je nie raz wie­lo­krot­nie wię­cej niż mia­ło by to eko­no­micz­ny sens.

(moja uwa­ga rok 2019: teraz mogę oce­nić, że więk­szość opro­gra­mo­wa­nia jakie audy­to­wa­łem, mia­ła nawet o rząd wiel­ko­ści wię­cej kodu niż mogła­by mieć!) 

Popatrzmy więc na pierw­szy etap ana­li­zy biz­ne­so­wej, budo­wę wizji pro­jek­tu i oce­nę wyko­ny­wal­no­ści. Pierwszy etap to ana­li­za strategiczna.

Analiza stra­te­gicz­na dzia­łal­no­ści to ana­li­za rela­cji pomię­dzy cela­mi biz­ne­so­wy­mi a biz­ne­so­wy­mi funk­cja­mi wspie­ra­ją­cy­mi je. Wizja roz­wią­za­nia powin­na odno­sić się do szan­sy biz­ne­so­wej i celu biz­ne­so­we­go. Tak więc powin­na powstać wizja reali­za­cji celu biz­ne­so­we­go (a naj­pierw sam cel oczy­wi­ście). Wizja ta naj­czę­ściej jest pew­nym ide­ałem, któ­ry nie zawsze jeste­śmy w sta­nie zre­ali­zo­wać (i czę­sto tak jest). Jednak ide­ał ten nale­ży zde­fi­nio­wać bo sta­no­wi on nasze zro­zu­mie­nie celu biz­ne­so­we­go, celu do któ­re­go fir­ma dąży.

Jak zapew­ne pamię­ta­my z pod­staw mar­ke­tin­gu: wizja fir­my do stan (swój lub swo­je­go oto­cze­nia ryn­ko­we­go), któ­ry postrze­ga­my jako ide­al­ny, misja fir­my to spo­sób dąże­nia do osią­gnię­cia tego celu.

Projekt roz­wo­ju ana­lo­gicz­nie, powi­nien mieć wizję (ide­al­ne roz­wią­za­nie), plan (osią­gal­ne roz­wią­za­nie) i stra­te­gię osią­gnię­cia tego pla­nu. Całość powin­na być osa­dzo­na w budże­cie fir­my i jej rachun­ku prze­pły­wów gotów­ko­wych. I nie cho­dzi jedy­nie o umiesz­cze­nie kosz­tów pro­jek­tu w budże­cie i oce­nę czy fir­ma to wytrzy­ma (meto­da bar­dzo czę­sto for­so­wa­na przez sprze­daw­ców roz­wią­zań IT). Chodzi o to by powią­zać te kosz­ty z odpo­wia­da­ją­cy­mi im przy­cho­da­mi oce­nić zasad­ność ich ponoszenia.

Tak więc mamy trzy ele­men­ty projektu:

  1. stan obec­ny,
  2. wizję
  3. oraz pla­no­wa­ny zakres projektu

W ramach ana­li­zy biz­ne­so­wej powi­nien naj­pierw powstać opis sta­nu obec­ne­go. Opis ten nie musi być kosz­tow­nym mode­lem pro­ce­sów biz­ne­so­wych na stan dzi­siej­szy”. Opracowanie szcze­gó­ło­we­go i kosz­tow­ne­go opi­su sta­nu obec­ne­go nie wie­le wno­si do pro­jek­tu a jest bar­dzo kosz­tow­ne. Stan obec­ny, tak zwa­ny opis as-is, to efekt tego jak poszcze­gól­ni mene­dże­ro­wie zarzą­dza­ją swo­imi zaso­ba­mi, a to zaś jest efek­tem zadań jakie im posta­wio­no. Pastwienie się nad tym bar­dzo rzad­ko wno­si war­to­ści do projektu.

Ważnym ele­men­tem pro­jek­tu jest zde­fi­nio­wa­nie po co to robi­my” i nie powi­nien to być argu­ment bo inni mają”. Benchmarking na tym eta­pie, pole­ga­ją­cy na porów­na­niu zaso­bów jest złym pomy­słem. Porównanie wskaź­ni­ków (czy­li wła­śnie bench­mar­king) nie jest porów­na­niem zaso­bów! Porównując się np. z kon­ku­ren­cją porów­nu­je­my cudze osią­gi z wła­sny­mi, jeże­li mamy taką moż­li­wość, to poza przy­cho­da­mi tak­że kosz­ty itp. Ale porów­na­nie takie to nie jest oce­na czym oni jeż­dżą” a oce­na jak oni jeżdżą”.

Po dru­gie kolej­na mar­ke­tin­go­wa zasada: 

nie da się sko­pio­wać cudze­go biz­ne­su, moż­na co naj­wy­żej usta­wić się obok. To jak w spo­rcie, goniąc kogoś może­my co naj­wy­żej iść po cudzych śla­dach za kimś, ale to nie to samo co zaję­cie cudzej pozy­cji bo to nie moż­li­we tą meto­dą. Wyprzedzanie pole­ga na zmia­nie toru ruchu by obejść konkurenta!

Tak więc pierw­szy krok to wizja. Drugi krok to ana­li­za wyma­gań, trze­ci to usta­le­nie zakre­su pro­jek­tu czy­li opra­co­wa­nie stu­dium wyko­ny­wal­no­ści. Dalej ma miej­sce uszcze­gó­ło­wie­nie pla­nu w zakre­sie projektu.

Określenie obsza­ru ren­tow­no­ści pro­jek­tu. Należy to zro­bić na samym począt­ku przy oka­zji budże­to­wa­nia i ana­li­zy prze­pły­wów gotów­ko­wych. To tu są dane o tym jakim kosz­tem i jakie korzy­ści chce­my osiągnąć.

Gdybyśmy mie­li wstęp­ną spe­cy­fi­ka­cję wyma­gań biz­ne­so­wych, to z każ­dym kolej­nym wyma­ga­niem przy­ra­sta łącz­ny koszt imple­men­ta­cji cało­ści. Korzyści poja­wia­ją się dopie­ro od pew­ne­go miej­sca, pew­ne mini­mum musi być zaim­ple­men­to­wa­ne, żeby sys­tem w ogó­le był przy­dat­ny. Idąc dalej osią­ga­my próg mini­mal­ny: korzy­ści zre­kom­pen­so­wa­ły nakła­dy. W mia­rę imple­men­ta­cji kolej­nych wyma­gań rosną korzy­ści jed­nak od pew­ne­go momen­tu ten wzrost się zała­mu­je. Dalsze ulep­sze­nia powo­du­ją, że koszt ulep­szeń zja­da” powsta­ją­ce korzy­ści. Osiągamy gór­ny próg rentowności.

Po wyko­na­niu takiej ana­li­zy wska­zu­je­my opty­mal­ny zakres pro­jek­tu: miej­sce gdzie bilans korzy­ści jest naj­ko­rzyst­niej­szy. Jest to stan to-be czy­li zapla­no­wa­ny świa­do­mie zakres projektu.

Jak prowadzić taką analizę?

Po pierw­sze nale­ży opra­co­wać spe­cy­fi­ka­cję wyma­gań biz­ne­so­wych. Każde z tych wyma­gań powin­no uzy­skać prio­ry­tet, np.:

  1. Bez nie­go potrze­by biz­ne­so­we nie zosta­ną zrealizowane
  2. Bez nie­go roz­wią­za­nie będzie mia­ło ogra­ni­czo­ną użyteczność
  3. Bez nie­go roz­wią­za­nie zre­ali­zu­je potrzeb­ny w pod­sta­wo­wej, pro­stej formie

To pozwo­li odrzu­cić wyma­ga­nia, któ­re powo­du­ją prze­kro­cze­nie budże­tu ren­tow­no­ści, a któ­re nie powo­du­ją zbyt duże­go pomniej­sze­nia osią­ga­nych korzyści.

Proces ten jest ite­ra­cyj­ny, mając jako model finan­so­wy rachu­nek prze­pły­wów gotów­ko­wych, może­my testo­wać wpływ wyma­gań na koszt pro­jek­tu i jego ren­tow­ność. Aby było to moż­li­we nale­ży w całym pro­ce­sie ana­li­zy wyma­gań pro­wa­dzić testy pro­jek­tu. Polegają one na tak zwa­nym śla­do­wa­niu. Cechy użyt­ko­we roz­wią­za­nia muszą się mapo­wać na potrze­by (cele) biz­ne­so­we. Stałe testo­wa­nie tego mapo­wa­nia to wła­śnie śla­do­wa­nie”. Zakres pro­jek­tu to w efek­cie lista cech pla­no­wa­nych do reali­za­cji w pro­jek­cie (wyma­ga­nych do reali­za­cji wizji). Śladowanie to, w całej doku­men­ta­cji obej­mu­je spraw­dza­nie mapowania:

Potrzeby biz­ne­so­we <?> Cechy użyt­ko­we wizji i zakre­su <?> Wymagania <?> Specyfikacja

Projekt ana­li­zy wyma­gań na każ­dym eta­pie jest testo­wa­ny, wali­do­wa­ny. Walidacja to spraw­dze­nie czy wyma­ga­nia są wła­ści­we. Kolejnym kro­kiem jest wyspe­cy­fi­ko­wa­nie roz­wią­za­nia. Zależnie od pro­jek­tu (może to być pro­jekt zmian orga­ni­za­cyj­nych, pro­jekt wdro­że­nia nowe­go opro­gra­mo­wa­nia) wali­do­wa­ne są wyma­ga­nia np. na nowy, pro­ce­so­wy sys­tem zarzą­dza­nia fir­mą (np. wyma­ga­nia w sto­sun­ku do nowej struk­tu­ry orga­ni­za­cyj­nej) albo na nowe opro­gra­mo­wa­nie wspo­ma­ga­ją­ce zarzą­dza­nie (np. ERP). Weryfikacja to testo­wa­nie roz­wią­za­nia, okre­śle­nie czy roz­wią­za­nie speł­nia wymagania.

Walidacja wymagań

Walidacja pole­ga na prze­te­sto­wa­niu czy nasze wyma­ga­nia zaspo­ka­ja­ją reali­za­cję celu biz­ne­so­we­go. Aby taki test prze­pro­wa­dzić, nale­ży zbu­do­wać model fir­my, któ­ry będzie­my testo­wa­li (raczej nie ma sen­su robie­nie tego na żywym cie­le”, było by to bar­dzo kosz­tow­ne). Te mode­le tu, to nic inne­go jak mode­le pro­ce­sów biz­ne­so­wych. Jednak model pro­ce­su to nie model wszyst­kie­go co się dzie­je”. Model pro­ce­su do testów to wewnętrz­ny model prze­pły­wu wartości”.

Modelujemy wyłącz­nie pro­ce­sy (prze­pływ pra­cy), nie pro­ce­du­ry, nie zakre­sy obo­wiąz­ków i nie kom­pe­ten­cje czy regu­ły biz­ne­so­we. Pozostałe szcze­gó­ły to obszar zarzą­dza­nia zaso­ba­mi czy zakre­sa­mi kom­pe­ten­cji (tu wię­cej o mode­lo­wa­niu). Mając popraw­ny model pro­ce­sów, może­my prze­te­sto­wać każ­de wyma­ga­nie i jego wpływ na procesy.

Biznesowa spe­cy­fi­ka­cja wyma­gań opi­su­je tak zwa­ną czar­ną skrzyn­kę”, czy­li nie zna­ne nam od środ­ka roz­wią­za­nie. Wymagania na tym eta­pie to tak zwa­ne przy­pad­ki uży­cia. Walidacja pole­ga wyłącz­nie na mapo­wa­niu (śla­do­wa­niu) celów biz­ne­so­wych na te wymagania.

Weryfikacja roz­wią­za­nia

Kolejny, ostat­ni etap ana­li­zy biz­ne­so­wej to wer­sy­fi­ka­cja roz­wią­za­nia. Mając tak zwa­li­do­wa­ną listę wyma­gań (tak zwa­ną Specyfikację Wymagań Biznesowych) może­my zabrać się za wery­fi­ka­cję roz­wią­za­nia. Tu sce­na­riusz wyglą­da tak:

  1. zapra­sza­my do skła­da­nia ofert dostaw­ców goto­we­go opro­gra­mo­wa­nia prze­ka­zu­jąc im spe­cy­fi­ka­cje wymagań,
  2. dostaw­ca pra­cu­jąc nad ofer­tą wery­fi­ku­je na ile jego roz­wią­za­nie speł­nia wyma­ga­nia (wyko­nu­je tak zwa­ną [[ana­li­zę gap/fit]]), powi­nien przed­sta­wić listę tak lub nie speł­nia­nia wyma­gań i swo­ją wycenę,
  3. jeże­li na tym eta­pie, ofer­ty są nie­sa­tys­fak­cjo­nu­ją­ce, opra­co­wu­je­my spe­cy­fi­ka­cję każ­dej funk­cjo­nal­no­ści (każ­de­go wyma­ga­nia) czy­li pro­jek­tu­je­my roz­wią­za­nie, któ­re­go nie zna­leź­li­śmy na rynku.

Na tym eta­pie zapa­da decy­zja o archi­tek­tu­rze roz­wią­za­nia: podział na ele­men­ty (pod­sys­te­my) goto­we i dedy­ko­wa­ne. Dedykowane muszą zostać zapro­jek­to­wa­ne. Projekty te (mode­le) są tak­że wery­fi­ko­wa­ne.

Kolejny etap to zapy­ta­nie o ofer­ty na reali­za­cję zapro­jek­to­wa­nych pod­sys­te­mów. W przy­pad­ku pro­jek­tów IT kom­plet­ne wyma­ga­nia to: przy­pad­ki uży­cia, regu­ły biz­ne­so­we, ogra­ni­cze­nia (wyma­ga­nia poza­funk­cjon­la­ne). Zaleca się (nie umiesz­czo­no na dia­gra­mie) uzu­peł­nie­nie mode­lu pro­ce­sów o tak zwa­ną taksonomię.

Jeżeli poja­wi się potrze­ba zapro­jek­to­wa­nia dedy­ko­wa­ne­go roz­wią­za­nia, poja­wi się model dzie­dzi­no­wy sys­te­mu wraz z uszcze­gó­ła­wia­ją­cy­mi go dia­gra­ma­mi sta­nów. Weryfikacja tej czę­ści spe­cy­fi­ka­cji pole­ga na tak zwa­nym testo­wa­niu bia­łej skrzyn­ki” czy­li pro­jek­tu roz­wią­za­nia. Tu są to dia­gra­mu sekwen­cji UML.

Całość pro­ce­su ana­li­zy i wery­fi­ka­cji bazu­je na opi­sa­nej już wcze­śniej Analizie Systemowej. Jeżeli zaś ktoś pro­po­nu­je jako wynik ana­li­zy wyma­gań, nie­we­ry­fi­ko­wal­ne wie­lo­stro­ni­co­we opi­sy w rodza­ju user sto­ry lub wypunk­to­wa­ne listy jako wyni­ki wywia­dów, burzy mózgów czy sesji JAD, to war­to mieć świa­do­mość, że to bar­dzo ryzy­kow­ne, bo nie­we­ry­fi­ko­wal­ne i nie­te­sto­wal­ne dokumenty.

Specyfikacja zawie­ra­ją­ca set­ki wypunk­to­wa­nych szcze­gó­ło­wo wyma­gań to nic inne­go jak nie­zro­zu­mie­nie fak­tu, że lista taka nie pod­da­je się żad­nym wali­da­cjom, a dla dostaw­cy goto­we­go opro­gra­mo­wa­nia jest bez­war­to­ścio­wa z uwa­gi na zbyt­nią szcze­gó­ło­wość. Z taka listą ana­li­za gap/fit wyka­że pra­wie cał­ko­wi­tą nie­zgod­ność z tym co ma w ofer­cie i u zde­spe­ro­wa­ne­go dostaw­cy wyge­ne­ru­je ofer­tę na tak zwa­ne kasto­mi­za­cje, te zaś zabi­ją budżet projektu.

Czy to warte zachodu

Praktyka takich ana­liz poka­zu­je, że pro­por­cje pro­jek­tów: ana­li­za i pro­jek­to­wa­nie vs. reali­za­cja, mają nastę­pu­ją­cą postać (dane sko­ry­go­wa­ne dla pro­jek­tów zna­nych auto­ro­wi w Polsce):

1. Czasowo: 50/50% (dane z USA: 75/25),

2. Kosztowo: 20 – 30/80 – 70% (dane z USA: 50/50, roz­rzut zale­ży od stop­nia zło­żo­no­ści dzie­dzi­ny systemu),

(zależ­nie od spe­cy­fi­ki pro­jek­tu i jego zło­żo­no­ści mogą poja­wić się pew­ne odstęp­stwa). Tak więc jak bume­rang wra­ca ta sama war­tość pro­go­wa pro­jek­tów, dla któ­rych war­to takie ana­li­zy robić. Jeżeli uzna­my, że opi­sa­na tu ana­li­za wyma­ga pew­nych nie­ma­łych kom­pe­ten­cji i doświad­cze­nia oraz pew­ne­go mini­mal­ne­go cza­su jaki nale­ży poświę­cić na zba­da­nie i opra­co­wa­nie mode­lu fir­my to jej koszt zaczy­na się od kil­ku­na­stu tysię­cy, daj­my na to 15 tys. W takim razie budżet całe­go pro­jek­tu powi­nien wymo­ści co naj­mniej 5 x 15 = 75 tys. zł. (pamię­ta­my, że koszt ana­li­zy to 20% war­to­ści pro­jek­tu). Analiza taka (dla tego nie­skom­pli­ko­wa­ne­go przy­pad­ku) wraz z pro­jek­to­wa­niem trwa, bio­rąc pod uwa­gę czas ocze­ki­wa­nia na przy­go­to­wy­wa­nie danych przez fir­mę ana­li­zo­wa­ną, ok. jed­ne­go miesiąca.

Ktoś może zarzu­cić powyż­szej kal­ku­la­cji nie­re­ali­zo­wal­ność wdro­że­nia w takim cza­sie. Odpowiem z prak­ty­ki tak: wdro­że­nia sys­te­mów ERP pozba­wio­ne eta­pu tak zwa­nej kasto­mi­za­cji” są bar­dzo spraw­ne. Koszty kasto­mi­za­cji zaś to nawet 75% kosz­tów całe­go wdro­że­nia (war­to popa­trzeć na ofer­ty, a moż­na tych kosz­tów uniknąć!).

Firmy pro­gra­mi­stycz­ne mają­ce dobry pro­jekt reali­zu­ją go i odda­ją do użyt­ku z regu­ły już w pierw­szym podej­ściu. Tak zwa­ne pro­to­ty­py, testy, odkry­wa­nie wyma­gań itp. to cechy pra­cy na źle, zbyt ogól­nie i bez testo­wa­nia (np. tak zwa­ne user sto­ry) okre­ślo­nych wyma­ga­niach. Jeżeli pro­jekt jest już wyko­na­ny i prze­te­sto­wa­ny na eta­pie ana­li­zy i wery­fi­ka­cji, fir­ma pro­gra­mi­stycz­na musi tyl­ko wyko­nać implementacje.

Jeżeli ktoś mimo to zaprze­cza powyż­sze­mu to musi mieć świa­do­mość, że negu­je potwier­dzo­ne doko­na­nia ostat­nich 20 lat wie­lu dobrych firm ana­li­tycz­nych na świe­cie, a od nie­daw­na tak­że w Polsce. Działalność IIBA i jej człon­ko­wie są na to żywym dowo­dem (na dowód mam tak­że swo­je referencje).

Dlaczego takich ana­liz wyko­nu­je się mało? No cóż, nie są one w inte­re­sie dostaw­cy, któ­ry twier­dzi, że jego sys­tem np. ERP jest na pew­no dobry”. Po dru­gie wie­le firm kupu­ją­cych opro­gra­mo­wa­nie uzna­je, że ich nie doty­czy ryzy­ko pro­jek­to­we i pomi­ja­ją ana­li­zy, a te są prze­cież niczym innym jak obni­że­niem ryzy­ka nie­po­wo­dze­nia takich pro­jek­tów. Pamiętajmy, że ponad 80% pro­jek­tów wdro­że­nio­wych w IT to pro­jek­ty z sil­nie prze­kro­czo­ny­mi budże­ta­mi i ter­mi­na­mi, część z nich (sza­cu­je się je na ok. 16%) to pro­jek­ty zanie­cha­ne z tego powodu.

Każdy z Państwa sam musi sobie odpo­wie­dzieć na pyta­nie: czy 20% budże­tu jest war­te tego by chro­nić pozo­sta­łe 80%.

(źr. bada­nia Cortex), dostęp 2011)

jak to niektórzy robią w Ameryce”">

IIBA czyli jak to niektórzy robią w Ameryce”

O szkoleniu

Ameryka przy­je­cha­ła do nas, [[Darryl Booker]], któ­ry 20 lat (poza pra­cą na uczel­ni) pra­cu­je jako kon­sul­tant, ana­li­tyk biz­ne­so­wy był tre­ne­rem na szko­le­niu, któ­re mam wła­śnie za sobą.

Z jed­nej stro­ny trzy dni pozna­wa­łem coś do cze­go sam docho­dzi­łem, co w zasa­dzie znam i potra­fię, jed­nak z dru­giej stro­ny szko­le­nia pro­wa­dzo­ne przez ludzi z dużym doświad­cze­niem zawsze mają dwa aspek­ty: po pierw­sze począt­ku­ją­cy dowie­dzą się jak nale­ży pra­co­wać i co powin­no pod­czas tej pra­cy powsta­wać po dru­gie dla mnie (dla każ­de­go z dużym doświad­cze­niem) bar­dzo cen­ne są kon­tak­ty z inny­mi ludź­mi z bran­ży, bo porów­na­nie wie­dzy, wymia­na doświad­czeń oraz dys­ku­sje pozwa­la­ją porów­nać swo­je doko­na­nia z cudzy­mi. W wie­lu pro­jek­tach i na kon­fe­ren­cjach sły­szę, że wymy­ślam jakieś nie­stwo­rzo­ne rze­czy bo nikt tak nie robi (mode­lo­wa­nie, testo­wa­nie wyma­gań, pro­of-of-con­cept, itp.). Otóż nie praw­da, po pro­tu bar­dzo wie­lu ludzi (w bar­dzo wie­lu pro­jek­tach) nie zarzą­dza ryzy­kiem przyj­mu­jąc gene­ral­nie opty­mi­stycz­ne wer­sje wydarzeń.

Czego się nauczy­łem na tym szko­le­niu? Że war­to pla­no­wać, pro­jek­to­wać i ana­li­zo­wać bo wte­dy pro­jek­ty są prze­wi­dy­wal­ne zamiast być loterią.

Jak to się robi? Od kil­ku lat pro­mu­ję ideę nauko­wej ana­li­zy sys­te­mo­wej: opis celu, opis pro­ble­mu, sta­wia­nie hipo­tez, mode­le i sce­na­riu­sze, reko­men­da­cje i pro­jekt. Nie musi to być i nie jest żaden tak zwa­ny wodo­spad” pro­jek­to­wy ([[wat­ter fall model IT]]), zwin­ność tu pole­ga na reago­wa­niu na każ­dym eta­pie pro­jek­tu na pro­ble­my i wpro­wa­dza­nie zmian, pro­dukt pro­jek­tu jest zawsze mode­lo­wa­ny i testo­wa­ny na każ­dym eta­pie. W efek­cie spe­cy­fi­ka­cja tego co ma powstać jest kom­plet­na, nie wyma­ga pro­to­ty­po­wa­nia” na żywym cie­le (powsta­je kod dla klien­ta, któ­ry zgła­sza uwa­gi do tego co zoba­czy) a zama­wia­ją­cy wie co dosta­nie w dniu zamó­wie­nia i wie ile to będzie kosztowało.

Mity dostawców oprogramowania

Dostawcy goto­we­go opro­gra­mo­wa­nia szer­mu­ją tezą, że oszczę­dzą Wam kosz­tów ana­li­zy bo mają wie­dzę i doświad­cze­nie zawar­te” w swo­im pro­duk­cie. Ryzyko, że wyma­ga­nia biz­ne­so­we zosta­ną źle zde­fi­nio­wa­ne i ryzy­ko, że dostar­czo­ny pro­dukt nie speł­nia tych wyma­gań jest igno­ro­wa­ne (klient zamó­wił to klient dosta­nie, czy to będzie mu potem potrzeb­ne to nie nasz problem).

Developerzy ofe­ru­ją­cy wyko­na­nie dedy­ko­wa­ne­go opro­gra­mo­wa­nia bez ana­li­zy wyma­gań a np. tyl­ko z pomo­cą tak zwa­nych sesji JAD (ang. [[Joint appli­ca­tion design]]) i kolej­nych pro­to­ty­pów, w ogó­le nie bio­rą pod uwa­gę ryzy­ka nie­kom­plet­no­ści tak okre­ślo­nych wyma­gań ani bra­ku ich spój­no­ści (zna­ny pro­blem odkry­wa­nia wyma­gań w trak­cie wdro­że­nia). Klient powie co chce i będzie OK a opro­gra­mo­wa­nie i tak ma być bo każ­dy ma.

A ryzy­ko, że ana­li­za potrzeb i pro­jekt tego co ma powstać, wyko­na­na przez przy­szłe­go wyko­naw­cę, będzie tak na praw­dę tyl­ko spe­cy­fi­ka­cję tyl­ko tego co dostaw­ca potra­fi wykonać?

Dlaczego tak często projekty łamią zasady rozsądku i zarządzania ryzykiem?

Wczoraj na sali i w kulu­arach padły mię­dzy inny­mi takie odpowiedzi:

  1. dostaw­cy opro­gra­mo­wa­nia bar­dzo czę­sto nie potra­fią takiej ana­li­zy wyko­nać bo nie mają wyma­ga­nych kom­pe­ten­cji, ale potra­fią pro­gra­mo­wać i tyl­ko na to się godzą.

  2. dostaw­cy opro­gra­mo­wa­nia dosko­na­le wie­dzą, że ist­nie­je ryzy­ko że ich pro­dukt nie speł­nia wyma­gań więc bar­dzo czę­sto nie dopusz­cza­ją do takich ana­liz for­su­jąc od razu wdro­że­nie (wręcz tępią w pro­jek­tach zewnętrz­nych analityków!).

  3. klien­ci mają sta­le do czy­nie­nia z dostaw­ca­mi a bar­dzo rzad­ko z nie­za­leż­ny­mi ana­li­ty­ka­mi i bar­dzo czę­sto przyj­mu­ją wia­rę w to co mówią dostawcy.

  4. nie ist­nie­ją nie­za­leż­ni analitycy.

Na ostat­nie odpo­wiem tak: jest ich (nas) mało… ale to łatwo spraw­dzić: popro­sić o refe­ren­cje i zapy­tać co reko­men­do­wa­li. Dobry ana­li­tyk nigdy nie reko­men­du­je imple­men­ta­cji a tyl­ko two­rzy spe­cy­fi­ka­cję biz­ne­so­wą. Po trze­cie, war­to anga­żo­wać ludzi zna­nych w bran­ży z tego, że nie są na pro­wi­zjach u producentów.

Agile…

Wielu z deve­lo­pe­rów idzie dalej: nie trze­ba ana­li­zy, trze­ba od razu zacząć two­rzyć roz­wią­za­nie, [[Agile Manifesto]] – hasło prze­wod­nie tej meto­dy jasno mówi, że cho­dzi o to by pro­gra­mo­wać a nie o to by coś doku­men­to­wać, szko­da cza­su na głu­po­ty (zawsze tak okre­ślo­ne meto­dy zwin­ne koja­rzy­ły mi się z home­opa­tią: dostaw­cy obie­cu­ją coś nie wie­dząc co na praw­dę boli i nie bio­rą żad­nej odpo­wie­dzial­no­ści za skut­ki, co cie­ka­we żad­ne dane nie potwier­dza­ją sku­tecz­no­ści tych metod).

Inna cie­ka­wost­ką metod Agile jest to, że pro­jekt koń­czy się nie wte­dy gdy powsta­nie to co zamó­wił (a raczej wyobra­żał sobie klient bo nic nie zamó­wił, w koń­cu nie powsta­ła żad­na spe­cy­fi­ka­cja) tyl­ko to co powsta­nie dopó­ki nie skoń­czy się budżet. Co powsta­nie? Zobaczymy jak skończymy.

IIBA czyli czym jest ta Analiza Biznesowa

Od pew­ne­go cza­su IIBA pro­mu­je idee Analizy Biznesowej, któ­ra jest poważ­nym zagro­że­niem dla opi­sa­nych wyżej dostaw­ców. Dlaczego? Bo pro­mu­je two­rze­nie doku­men­tów pozwa­la­ją­cych naj­pierw dokład­nie wyspe­cy­fi­ko­wać to co jest potrzeb­ne (czy­taj pomo­że w biz­ne­sie!), potem dopie­ro zosta­je to zamó­wio­ne i dostar­czo­ne lub wykonane.

Nie da się tak? A wła­śnie, że się da. Czy to kosz­tow­ne? Zapytam tak? Co lep­sze nie­przy­dat­ny pro­dukt za 100tys. zł czy przy­dat­ny za 120tys.? Co lep­sze, pro­jekt pla­no­wa­ny na pól roku za 100tys. i wyko­na­ny w ter­mi­nie czy obie­ca­ny za 50tys. w kwar­tał a dostar­czo­ny za 250 tys, po dwóch latach?

To się nazy­wa RYZYKO a ana­li­za i pro­jek­to­wa­nie to zarzą­dza­nie tym ryzykiem!

Co oferuję jako analityk a IIBA zaleca

Porządny pro­jekt analityczny:

[sin­gle­pic id=119 w=533 h=533 float=center]

Kończący się spe­cy­fi­ka­cją wyma­gań (IIBA nazy­wa to Dokument Wymagań Biznesowych):

[sin­gle­pic id=122 w=533 h=533 float=center]

A teraz to co mogę pole­cić: szko­le­nie Analiza Biznesowa w MT&DC. Dostawców nauczy pra­cy a klien­tów wia­ry, że moż­na lepiej. Dlaczego tak pole­cam to szko­le­nie? Bo jego koszt to nic w porów­na­niu do strat jakie gene­ru­je źle zapla­no­wa­ny pro­jekt a któ­rych moż­na unik­nąć lub znacz­nie zmi­ni­ma­li­zo­wać. Nawet jeśli ktoś po szko­le­niu nie będzie potra­fił sam od razu takiej ana­li­zy wyko­nać (bo raczej po trzech dnia nie) to na pew­no będzie w sta­nie oce­nić to co pro­po­nu­ją dostaw­cy a potem zarzą­dzać takim pro­jek­tem. Potem z cza­sem sam (lub na kolej­nych szko­le­niach) nauczy się dobrej ana­li­zy biznesowej.

Na koniec naj­waż­niej­sze, para­fra­zu­jąc stwier­dze­nie Daryll’a: ana­li­ty­kom, któ­rych jedy­nym narzę­dziem pra­cy jest pakiet MS Office, w szcze­gól­no­ści Excel i PowerPoint, z góry dzię­ku­je­my (on uży­wa pro­fe­sjo­nal­nych narzę­dzi CASE i pakie­tów do zarzą­dza­nia projektami).

Inny bar­dzo cie­ka­wy arty­kuł o wyma­ga­niach: Jak zawa­lić pro­jekt infor­ma­tycz­ny. Analiza wymagań.