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…