Použití „Metody příčného řezu“ při řízení projektů a její nevýhody

Normy ISO a moderní metodiky tvorby softwaru požadují striktně oddělit jednotlivé úrovně abstrakce. Tyto úrovně zavádí také technologie zvaná Extrémně efektivní modelování a to přímo v praktické rovině, tj. v konkrétních postupech s konkrétními nástroji.

Vyvíjený informační systém (IS) je v EFEM technologii modelován a tvořen v tzv. abstraktních úrovních. Abstraktní úroveň znamená úhel pohledu na IS za určité míry abstrakce.

Nejnižší úroveň abstrakce pojímá IS jako souhrn zdrojového kódu, zkompilovaných spustitelných nebo připojených souborů, skriptů apod. Tato úroveň abstrakce odpovídá pohledu programátora, pracovníků instalace apod.

Nejvyšší úroveň abstrakce pojímá informační systém jako souhrn vlastními slovy popsatelného souhrnu funkcionalit spolu s obecně zavedenými pojmy jako evidované informace a její výskyty. Tato úroveň abstrakce odpovídá pohledu všech účastníků projektu na informační systém, tedy i „ne-programátorů“.

Všechny úrovně abstrakce popisují tentýž IS a jsou proto mezi sebou konzistentní.

EFEM technologie zavádí jako dostatečné tři úrovně tvorby IS:

analytické modelování,
modelování návrhu (design)
kódování (implementace)

Základní otázkou analytického modelování je "CO?" (tj. o co v systému jde), hlavní otázkou design modelování je "JAK?" (tj. jak bude ono CO navrženo konkrétně v daném vývojovém prostředí), základní otázkou kódování a implementace je realizace návrhu.

obrázek 1 Úrovně abstrakce IS

Celý informační systém je chápán jako souhrn všech zdokumentovaných výsledků vývojových prací na všech úrovních abstrakce, tj. Analýzy, Designu a Kódu, dále také zkratka ADC (Analysis, Design, Code). Každý i sebemenší IS vždy prochází minimálně těmito úrovněmi. Nejprve se určuje "o co v programu půjde" (analytické modelování), poté se řeší "jak se to navrhne právě v tomto prostředí" (design) a poté se programuje (kódování a implementace).

Výsledky prací na vývoji IS (tj. dokumentaci tvořenou během vývoje) rozděluje technologie EFEM do těchto tří oblastí ADC. Technologie EFEM přitom umožňuje, aby na každé úrovni byly výsledky prací dostatečně zdokumentovány a přitom nedocházelo ke nadbytečné tvorbě dokumentů podle principu minimální a přitom úplné dokumentace.

Tři různé pohledy na IS z hlediska abstraktních úrovní ADC implikují posloupnost prací na vyvíjeném IS, tj. fázování projektu. Postupuje se od nejvyšší úrovně abstrakce směrem k nižší úrovni abstrakce, tedy od analytického modelování přes design po kódování. Přitom platí princip minimální úplné dokumentace. Časová posloupnost tvorby však neznamená, že musí být hotovy všechny prvky analytického modelování v celé úplnosti k tomu, aby se mohlo přistoupit k tvorbě modelování designu, ale lze přistoupit k návrhu i po částech (tzv. Iterativní a inkrementální vývoj IS). Na základě modelů analytického modelování vznikají artefakty design modelování. Na základě výsledku modelování designu vznikají následně artefakty zdrojového kódu jako jsou samotný zdrojový kód, SQL příkazy apod. Vzniká tak v časové posloupnosti jednoznačná trojice souhrnu dokumentů popisující tutéž určitou část IS na všech třech úrovních ADC.

Výsledek vyšší úrovně abstrakce se stává zadáním pro tvorbu nižší úrovně abstrakce. Přechod z analytického modelování do modelování designu nazýváme mapování z analýzy do designu.

Přechod z designu do kódu se v technologii EFEM říká kódování, nebo ekvivalentně realizace.

Vymezení fází přesně určuje, jaké dokumenty mají kdy vzniknout a v jakém jsou vztahu. Z tohoto hlediska se jeví jako velmi užitečné, aby analytické práce prováděl určený pracovník v roli analytika a modelování návrhu prováděl druhý pracovník v roli designéra. První z nich zná velmi dobře problémovou doménu a je schopen pomocí UML a vhodných nástrojů a postupů modelovat zadání pro designéra.

V mnoha SW firmách se však na rozdíl od oddělení fáze analýzy a designu volí jiný přístup tvorby SW, nazvěme jej „model příčného řezu“. Při použití tohoto modelu se použije tento postup: Mezi pracovníky (původně programátory) se rozdělí práce tak, že se jednoduše systém pomyslně rozčlení na části, nazvěme je agendy, a pracovníci je dostanou na starost. Každý z nich potom provádí všechny práce od analýzy, přes design po kódování. Rozložení prací v projektu lze znázornit takto:

Všimněme si, že všichni analytici programátoři mají svůj „výsek“ práce a provádějí na něm práce jak analytické, tak designu a kódování. Zvolili jsme název pro tento model Metoda příčného řezu, protože dělíme IS napříč podle oblastí řešení a nikoliv podle úrovní abstrakce.

Tento způsob řízení je ve firmách velmi častý a je oblíben pro svou jednoduchost, přesněji pro jednoduchost z pozice vedoucího, nikoliv pracovníků. Stačí „prostě rozdělit“ práci a potom kontrolovat, jak se pracovníci „snaží podat výkony“. Přestože se jedná o velmi rozšířený model řízení, vřele jej nedoporučuji. Má totiž své natolik vážné nedostatky, že může vést k velmi špatným až fatálně chybným výsledkům zejména u větších projektů.

Všimněme si těchto hlavních nevýhod.

Předešlý obrázek připomíná spřežení koní a každý kůň má klapky na očích. Programátor pracující na své agendě „neví“ nic o sousedovi. Jednotlivé agendy jsou od sebe odstřiženy, bez opětovné použitelnosti, bez re-usu, bez logické návaznosti. Předávání výsledků práce je velmi obtížné a nakonec se provádí pouze ústně a náhodně, doslova na kuřářně u cigarety :).

Nejenom, že se opakují práce, ale systém není navíc přehledný, logický a transparentní. Agendy pracují bez vzájemné logiky mezi sebou, chybovost prací je enormní, navíc chyby se obtížně lokalizují, protože věci nejsou na svých logických místech, kde by měly být a opakují se všude možně, „bůh ví kde“.

Existuje reálné riziko, že pracovník bude optimalizovat svůj proces tvorby tak, že vynechá dokumentaci analýzy. Protože vyvíjí pod enormním tlakem, není se čemu divit, že vynechá povinnou část dokumentace, kterou má v hlavě a může ji tedy sám použít (proč dokumentovat něco, co vím). Výsledkem jeho prací je pouze kód a jakési velmi nepřehledné poznámky o designu a analýza zůstala pouze jako myšlenky v jeho hlavě. Důsledky jsou pro firmu hrozivé: Pracovník se nejenom že stává nezastupitelným a nenahraditelným, ale navíc mnohdy i nepoužitelným pro další vývoj na jiných pracích, protože nikdo kromě něj nemůže tuto osobu nahradit, a to mnohdy dokonce i po implementaci systému a po ukončení hlavních vývojových prací! Nikdo jiný agendě totiž nerozumí a co je horší, nikdo jiný si ani nemá co přečíst, aby jí rozuměl

Pracovník se stává „všeumělem“. Nejenom že rozumí dobře problémové doméně, například zahraničním akreditivům v bance nebo obchodování s cennými papíry, ale umí i teorii databází, administraci databáze, umí programovací jazyky (například JAVA nebo C#), zná nastavení hardwaru, instalace, webovský server a spoustu jiných věcí. Metoda příčného řezu svým zaměřením stírá specializaci a brzdí tak odborný růst zaměstnanců. Pracovník vyvíjí vše od A až do Z a je tedy specialistou na všechno, což je samo o sobě protimluv. Výsledkem takového postupu je závěr, že ve firmě se nakonec vyskytují pracovníci sice s bohatými znalostmi, ale nikoliv dobří „guru“ a dobří specialisté na nějakou oblast.

Moderní metodiky včetně EFEM nabízejí jiný způsob dělení prací: Nikoliv napříč přes agendy, ale po úrovních abstrakce a teprve při zavedení metody iteračního a inkrementálního vývoje se začíná přesně definovaným postupem podle přesný pravidel dělit IS na oblasti iterace (tzv. Iteration Area). Toto rozdělení je však až sekundární.

Použití metody příčného řezu lze považovat za jeden z nejrozšířenějších nešvarů řízení projektů a jeho odstranění vyžaduje zavedení jiných „sofistikovanějších“ postupů tvorby SW. Je třeba opustit primitivní způsob dělení prací podle schématu „ty uděláš to a ty tohle“. Technologie EFEM, která se nyní připravuje, se touto problematikou zabývá velmi podrobně ve své části „Základní pojmy řízení modelů - Model and Project Managment“ a podává velmi konkrétní postupy, které vedou k efektivnějšímu rozdělení prací mezi rolemi v projektu, současně EFEM zavádí také iterační a inkrementální způsobu vývoje pro větší a rozsáhlé projekty. Výstupy této technologie jsou velmi praktické a konkrétní, například nyní se připravují metodiky právě pro tyto postupy pro kombinaci nástrojů Enterprise Architect a Visual Source Safe resp. CVS.