Jak řešit problém samovolného posunu realizovaného kódu od původní analýzy?

Znáte to: Analytici se hodně snaží, ale nasazený systém se díky dalším změnám postupně vzdaluje od původní analýzy. Každý systém tak z pohledu analýzy stárne a jde jen o to, jak rychle… Realizovaný kód nakonec nemusí odpovídat analytické dokumentaci a díky tomu tým padá zpět do chaotického vývoje, jako by analýza ani nebyla…

Jak tomuto samovolnému posunu „realizovaný kód versus analýza“ co nejvíce zabránit anebo aspoň omezit na přípustnou mez? Možná vám v agilní technice chybí jeden sloupec TODO.

High Level Analysis a Low Level Analysis

Doporučuji dodržovat osvědčené rozložení analytické dokumentace podle následujícího vzoru (viz obr.), který zavádí dva okruhy dokumentů, tzv. High Level Analysis a Low Level Analysis.

Pozn.: Obrázek je převzat z online školení Efektivní analýza v agilním prostředí. Na obrázku jsou znázorněny dvě varianty agilních technik SCRUM resp. KANBAN.

High Level Analysis (BPM + UCM)

Pod High Level Analysis rozumíme kombinaci procesního modelu s vazbou na případy užití, které jsou používány z “atomických” koncových procesů (tzv. tasky v syntaxi jazyka BPMN). K evidenci všech procesů se používá tzv. rozklad procesů (neboli dekompozice procesů anebo procesní mapa), viz obrázek výše.

Rozklad procesů vede vždy k přesné a důsledné  evidenci všech prvků Use Case neboli z pohledu programátora všech spustitelných funkcionalit. Pro zdárný průběh projektu je opravdu výhodné mít takovou evidenci. Pohled shora připomíná otevírání šuplíků resp. zapínaní zoom – přiblížení a oddalování detailu. Pomocí tohoto rozložení získáváme neustálou inventuru všeho, co by se mělo realizovat anebo již realizovalo. Tento přehled je navíc díky stromové hierarchii (růst uzlů stromu jde dolů geometrickou řadou) velmi účinný i pro velmi rozsáhlé systémy s řádově tisíci nebo dokonce deseti tisíci případů užití (banky, pojišťovny atd.).

Přiznám se, že na tento dokument nedám dopustit a neumím si představit, že by se v projektu netvořil.

Evidenci dokumentace High Level Analysis si vedeme a udržujeme po celou dobu projektu, jedná se o stálý nejvyšší “kontrolní” pohled na systém. Toto rozložení doporučuji používat i u menších projektů, i když se může zdát, že je to vzhledem rozsahu systému zbytečné. I zde totiž platí, co není v evidenci dokumentace projektu, jakoby neexistovalo.

Je třeba podotknout, že programátora výstupy z High Level Analysis nezajímají. Jsou však velmi zajímavé pro hlavního analytika, který si může „odfajkovávat“, co se realizuje, a také pro budoucího uživatele (zadavatel, např. business oddělení apod.) a také pro vedoucího projektu (managery aj.)

Low Level Analysis

Nižší vrstva analytické dokumentace tzv. Low Level Analysis reprezentuje (s trochou nadsázky řečeno) „vnitřky“ prvků Use Case (konkrétně UC Scenarios), tedy program v kódu a doprovodné analytické Class Modely, které zavádějí sofistikovaný pojmový slovník pro evidované prvky a vztahy mezi nimi.

Základní filosofie postupu řešení

Nyní zpět k problému posunu kódu a analýzy. Uvedu zde základní myšlenku, jakou filosofií řešit problém posunu kódu versus analýza tak, jak jej zavádím ve firmách resp. předávám na školení, a který se mi osvědčil:

1) Je třeba oddělit tvorbu Analýzy od tvorby Tasků a to i fyzicky přes kopie. Analýza a Tasky jsou dva okruhy dokumentace propojené vztahy tam a zpět typu „kdo s kým souvisí“. Tento vztah však není „živý“, ale je realizován přes kopírování obsahů.

2) Při zadání vznikají nové Tasky do realizace, ty používají analytické modely jako zdroj, kopírují se jak texty, tak diagramy. Takto se Tasky oddělují od analýzy „fyzicky“.

3) Během samotné realizace Task žije vlastním životem bez zpětného zásahu do analýzy během kódování. Pokud dochází ke změnám při realizaci, promítnou se změny v této chvíli pouze v Tasku, nikoliv v analýze.

4) Po fázi testování alias akceptace (např. sloupec v KANBANU) se u Tasku zavádí jeden další nový krok  (např. nový sloupec v KANBANU) a to „Feedback to Analysis“, viz obrázek:

V této fázi zpracování se naopak Task se svými případnými změnami stává zdrojem pro zpětnou opravu analytické dokumentace. Analýza se v zde stabilizuje do podoby, jak je realizován kód daného Tasku. Je zřejmé, že analytik zde musí úzce spolupracovat s programátory a technology, kteří se podíleli na realizaci tohoto Tasku. Teprve až po ukončení tohoto kroku končí také životní cyklus Tasku a přechází do stavu Hotovo.  Analytický model se tak stává relevantním zdrojem pro další změny.

V případě, že dojde při kódování ke zjištění rozdílu v chodu procesu, tak se musí založit zvláštní Task pro analytiky pro přehodnocení  High Level Analysis (BPMN) a provádí se klasické změnové řízení procesního modelu v BPMN. Přitom je třeba samozřejmě  využít nástroje pro řízení verzí u daného CASE nástroje, např. Baselines v EA apod.

Základní premisy technologické disciplíny

Je zřejmé, že je třeba dodržovat základní premisy technologické disciplíny:

1) Programuje se přesně to, co je zapsáno a zadáno v Tasku. Dodržení tohoto pravidla si vynucuje dva nutné procesy ve vývoji: Musí dojít ke vzniku Tasku na začátku (aby se zadalo, co se má programovat na začátku) a musí docházet k jeho změnám, když se na něco narazí při realizaci resp. je třeba blíže specifikovat. Změny se nejprve zadávají do Tasku a poté se realizují.

2) Na začátku  realizace Tasku a na jeho konci (stav Hotovo) musí být Task a Analýza v souladu.

Závěr

Všimněme si, že tímto postupem zpětné vazby až po testování se získá žádoucí stav, kdy se neztrácí agilnost, protože případné změny, které vyvstaly během kódován (upřesnění, specifikace, drobné změny apod.) se provádějí v rámci Tasku a nikoliv v analýze. Teprve následně po realizaci a po testování se změny promítnou zpět do analýzy jednorázově (a nikoli s každou drobnou změnou při realizaci).

Uvedený postup lze doplnit o další kontrolní mechanismy nad CASE nástrojem související se změnami modelů v průběhu realizace Tasku, např. porovnání verzí Baselines, změny v RDB modelu apod.


Nepřehlédněte aktuální nabídku

Webináře

Nejbližší webinář:
Pravidla pro psaní scénářů v Use Case Modelu a nejčastější chyby

termín 3.3.2021

cena 490,- Kč



Čtvrtletní vzdělávací program profesního růstu analytika

Účast hned na dvou e-learningových školeních dohromady.

Předplatné na deset jednodenních online webinářů

Ke každému webináři animovaná skripta ke stažení.

Po úspěšném absolvování kurzu certifikát.

Cena pouze 2 900 Kč




Categories

About the Author:

správce a majitel Serveru objektových technologíí http://www.objects.cz

0 Comments
0 Pings & Trackbacks

Leave a Reply