Šumperský efekt rozmnožení případů užití

http://www.objects.cz Šumperský efekt, © Kraval Ilja

Šumperský efekt rozmnožení případů užití © Ilja Kraval, 2007 http://www.objects.cz

Článek pojednává o jednom velmi nepříjemném efektu – bobtnání projektu.

1. Odhad velikosti a rozsahu informačního systému Jeden starý dobrý Murphyho zákon říká:

„Každý informační systém vypadá na první pohled menší, než ve skutečnosti je.“

Existuje také bohužel velmi pravdivý dodatek k tomuto zákonu:

„...a to i s přihlédnutím k tomuto zákonu.“

Jinak řečeno, i když velmi dobře známe znění tohoto zákona a jsme si vědomi zjevné záludnosti odhadu velikosti IS, stejně i tak uvažovaný rozsah IS podceníme. Tento Murphyho zákon o podcenění velikosti rozsahu IS je charakteristickým jevem u manažerů a u vedoucích, proto bych ho nazval příznačně „manažerskou nemocí“. Původ a příčina této nemoci je prostá: Vedoucí se soustředí na obchodní použití daného systému a z mnoha funkcionalit, které systém musím nutně umět a znát, se soustředí pouze na ty, které považuje za „zlaté“, tedy takové, za které zákazník

Strana 1


zaplatí a které jsou tedy obchodně zajímavé. Samozřejmě kromě těchto několika málo zlatých funkcionalit musí systém vykazovat ještě spoustu jiných případů užití, bez nichž by nebyl systém konzistentní a úplný. Tyto funkcionality jsou sice z hlediska obchodu chápány jako „tanečky okolo“, ale z hlediska funkčnosti a úplnosti systému jsou stejně důležité, jako „obchodně zlaté“ případy užití.

2. Bobtnání projektu v tunelu a jak mu zabránit... S uvedeným Murphyho zákonem o podcenění rozsahu projektu a následně s manažerskou nemocí souvisí i jeden vážný problém nazývaný „bobtnání projektu“. Je to jev velice nepříjemný a svým způsobem paradoxní: Lidé na projektu pracují se stále větším úsilím a paradoxně práce stále přibývá namísto toho, aby jí ubývalo. S tímto zdánlivě nelogickým jevem se můžeme setkat ve firmách používajících metodiku (spíše přesněji „anti-metodiku“ ☺) zvanou příznačně TUNEL. Její podstata je velmi jednoduchá a proto je často používaná: Na počátku projektu se vstupuje do černého tunelu. Členové vývojářského týmu procházejí poslepu tunelem od stěny ke stěně. Na cestě černou tmou, kdy je vidět opravdu jenom na krok dopředu, se díky nárazům do stěn zjišťuje, kudy cesta nevede. Neblahými zkušenostmi z neúspěšných cest a tvrdých nárazů do stěn tunelu, což reprezentují nešťastné zprávy od uživatele nad odevzdaným kusem kódu: „Takto jsme to přece nechtěli“, se zjišťuje, co se vlastně nemělo dělat a nikoliv, co se mělo udělat. Vedoucí projektu se snaží neustálými operativními zásahy uřídit projekt a najít tak nějaké světýlko na konci tunelu. Mnohdy se poštěstí a projekt se opravdu „s odřenýma ušima“ a úlevou dokončí a „jakýs takýs“ informační systém se zákazníkovi nakonec odevzdá. Právě při použití této metodiky se nejenom že ze tmy tunelu ozývají zoufalé výkřiky vývojářů: “Kdo už nám konečně řekne, jak to má být?“, ale navíc se s každou rádoby dokončenou prací objevují další a další hory nedodělků. Stále a znovu a znovu se otevírají nové a nové Pandořiny skřínky s větami typu: „Proto, aby mohlo toto takto fungovat, je třeba ještě naprogramovat toto...a k tomu, aby toto nové mohlo fungovat, musíme ještě naprogramovat toto, a k tomu... atd.“ Vedoucí projektu má oprávněný pocit cestovatele, kterému se místo kýženého cíle vynořují další a další horizonty, které musí zdolat... Otázkou je, jaké má tato situace řešení? Odpovědí je tvorba analytického modelu v UML spolu s tvorbou USE CASE MODELU a BUSINESS PROCESS MODELU...

Strana 2


3. Metodika „UCM+BPM“ jako dobrý nástroj proti efektu bobtnání projektu Metodika nalézání případů užití a modelování IS za pomoci odhalování podnikových procesů (dále zkratka UCM+BPM) je naštěstí mezi firmami poměrně dost rozšířena. Jenom na okraj musím podotknout, že pracovníci mnohdy při práci s metodikou UCM+BPM často chybují, což však není předmětem tohoto článku. Této metodice je věnována velká pozornost na našich školeních (viz http://www.objects.cz/pobyt/pobytovaskolaUML.html) a také na našem speciálním semináři „Analytické modelování a tvorba USE CASE diagramů“ (viz http://www.objects.cz/seminare/seminare.html). V tomto článku se zaměříme na velmi pozitivní vlastnost této metodiky a totiž, že UCM+BPM může velmi dobře napomoci v boji při zamezení nepříjemného efektu bobtnání projektu, samozřejmě, je-li tato metodika správně použita. Nejprve je třeba tak trochu paradoxně podotknout, že k nárůstu počtu funkcionalit při vývoji IS dojde zákonitě a logicky vždy, tj. případy užití systému „bobtnají vždycky“ a tomu efektu se nevyhneme. Jde však o to, aby tento nárůst probíhal zásadně v kompetenci a pod kontrolou analytika a pokud možno v úvodních částech projektu a ne až při programování anebo dokonce až při implementaci systému. Jinak řečeno, při správném použití metodiky UCM+BPM si tzv. „bobtnání projektu“ užije pouze a jenom analytik a to ještě v počátcích projektu a daleko před programováním. Navíc metodika UCM+BPM v sobě skrývá možnosti systematické kontroly konzistence funkcionalit IS a to ji činí velmi silnou zbraní proti bobtnání projektu. Jinak řečeno lze zkontrolovat, zda náhodou nehrozí nabobtnání díky chybám v modelech. Chceme-li výrazně snížit riziko bobtnání projektu, tak oba modely dohromady, tj. USE CASE MODEL plus BUSINESS PROCESS MODEL, podrobíme dvěma kontrolám: 1. Kontrola úplnosti rozkladu BPM 2. Kontrola konzistence stavů výskytů, se kterými pracují scénáře případů užití První bod kontroly je poměrně dost jednoduchý. Na každém bodu rozkladu podnikových procesů se položí kontrolní otázka: Je tento rozklad opravdu úplný? Nechybí nám někde nějaká větev rozkladu? Paradoxně, pokud se nalezne chyba nějaké chybějící větve rozkladu, nebývá to na spodních úrovních, ale na úrovních vyšších, což je dost fatální chyba! Do řešení se opomene zahrnout nějaká celá agenda (například konfigurace, nastavení, administrace přístupových práv apod.). Je zřejmé, že takováto chyba otevře při programování a následném bobtnání projektu opravdu gigantickou Pandořinu skřínku ( ☺ ) ! Doporučuji, aby pokud budete tuto kontrolu provádět, tak aby se realizovala zásadně v týmu, například „brainstormingem“ před tabulí. Víc očí víc vidí a pokud někdo něco opomene (což je lidské), tak při kontrole sám po sobě opomene danou věc i podruhé i potřetí.

Strana 3


Druhá kontrola je složitější a provádí se spíše v klidu pracovny, než před tabulí. Procházejí se jednotlivé scénáře případů užití a u každé z částí scénářů se kontroluje, zda logické výskyty, se kterými scénář pracuje, někde v systému vznikají, a navíc, pokud třeba, kontroluje se, zda požadované stavy logických instancí, se kterými scénář pracuje, jsou někde nastaveny. Jinak řečeno, scénář pracující s informacemi v určitém stavu má relevanci pouze tehdy, jestliže tyto informace v systému jsou založeny a v případě, že scénář pracuje se stavy informace, tak tyto stavy jsou již někde nastaveny, což může být (a většinou bývá) úplně jiný scénář. Jednoduchými až triviálními případy porušení tohoto pravidla jsou následující příklady: Čteme například ve scénáři větu: “Obsluze se zobrazí seznam fyzických osob...“ Přitom ať hledáme, jak hledáme, tak nikde v systému není ani založení fyzické osoby obsluhou, ani import fyzických osob z externího systému, prostě nic, co by mohlo vést k tomu, že systém má co zobrazit. Podobně například při výpočtu nějaké hodnoty se uvede: Převezme se N posledních hodnot a vypočítá se průměr (tzv. klouzavý průměr). Přitom ať hledáme, jak hledáme, tak ani v tomto a ani v jiném scénáři se nikde nedočteme, kde se nastavuje hodnota N. Tento druhý příklad ukazuje na chybu, kdy chybí nastavení stavů informace (tj. hodnoty N). Samozřejmě, že analytik se snaží těmto chybám vyhnout a proto už při tvorbě scénářů v případech užití ihned „odskakuje“ do jiných scénářů a dělá si aspoň poznámky ve formě úkolů, co musí systém umět, aby tento zpracovávaný scénář mohl vůbec fungoval. A zde právě, jak vidět, nastává onen efekt „bobtnání a kocení systému“, kdy z jedné funkcionality najednou vypadne několik doprovodných funkcionalit jako „tanečky okolo“. Je zřejmé, že podcenění tohoto postupu v analýze vede k následnému bobtnání systému při programování se všemi katastrofickými dopady na projekt.

4. Šumperský efekt rozmnožení případů užití Uvedu jeden klasický příklad z praxe, který velmi názorně ukazuje použití uvedené kontroly a také je na něm velmi pěkně patrné, co by v znamenalo zanedbání tohoto užitečného postupu... V jedné SW firmě v Šumperku mne požádali o školení a konzultaci návrhu IS pomocí UML. Tato firma dodává na trh lázeňské evidenční systémy, tj. IS určené pro evidenci v lázních. Když jsem tam odjížděl, tak jsem si myslel, že takový lázeňský systém bude asi nějakou „klasickou evidencí“ typu pacient na hotelu, stravenky pacienta apod. Jak jsem se tehdy mýlil! Uvedený systém obsahoval jeden případ užití, který kvalitativně a obchodně posunul celý systém do vyšší úrovně a současně výrazně zvýšil jeho kvalitu. O co v tomto opravdu „hodně zlatém“ případu užití šlo?

Strana 4


Dříve, než vysvětlím podstatu tohoto případu užití, rád bych dopředu upozornil na efekt „množení vedlejších případů užití“, které díky funkcionalitě tohoto případu užití začnou vznikat. Onen zajímavý případ užití bychom mohli nazvat například „Vygenerování rozpisu lázeňských procedur pacientovi“ (samozřejmě nemáme na mysli procedury ve smyslu programování, ale lázeňské procedury, jako jsou skotské střiky, bahno apod.). Vysvětlení funkcionality tohoto případu užití zahájíme popisem procesu podniku, tj. vysvětlení zahájíme scénářem mimo systém (... jak je tato metodika UCM+BPM jasná a průzračná ☺ !): Pacient přichází do lázní k doktorovi a předloží chorobopis (nejlépe v elektronické podobě). Chorobopis se zadá do systému a systém vygeneruje rozpis jeho lázeňských procedur, které má absolvovat během pobytu. Přitom musí být splněna spousta podmínek. (Samotný algoritmus popisovat nebudeme, na to měli ve firmě specialistu - matematika.) Jmenujme některé z těchto podmínek a současně si zaznamenejme i vedlejší vznik celých sad nových případů užití, které musí systém znát a umět, aby tento případ užití mohl fungovat korektně. Samozřejmě v prvé řadě musí být evidován vztah mezi chorobopisem, tj. nemocemi a procedurami tak, aby pacient nedopadl jako v klasické komedii s Vlastou Burianem, kdy hlavní hrdina obdržel na ischias namísto bahna zubní protézu. Samozřejmě to znamená vyvinout celou agendu správy nemocí spolu s procedurami a vazbami mezi nimi. Další požadavek zní také rozumně, každá pozice poskytnuté procedury má svá omezení obsazeními, například do vany s bahnem by měl být umístěn jeden pacient, ale do bazénu se vejde například až 20 pacientů. Znamená to samozřejmě evidovat také plán obsazenosti všech pozic procedur, včetně výluk apod. (Mimochodem, systém se začíná kotit! ☺). Navíc některé procedury vyžadují rozdělení na muže a ženy a některé nikoliv. Nebylo by vhodné, aby systém určil, že pacient má být na jedné lázeňské proceduře na jednom konci lázní a za pět minut se objevil u jiné lázeňské procedury na druhém konci lázní. Pokud to stihne a je kardiak, nemusí už žádnou proceduru ani potřebovat. Znamená to novou sadu vedlejších případy užití: zaevidovat a udržovat v evidenci vzdálenosti mezi pozicemi procedur, resp. zavést graf pozic (ve smyslu teorie grafu) s jednotlivými uzly procedur a určovat cesty mezi nimi (mimochodem také evidovat pohyblivost pacienta). A pak mohou následovat další a další podmínky. Nakonec ještě perlička: Představme si, co by v důsledku pro projekt znamenala prostá podmínka vyjádřená touto jednoduchou větou: Vyžaduje se, aby pacient chodil pokud možno na lázeňské procedury stále ke stejnému personálu. Když si vedoucí projektu domyslí do důsledku tuto jednoduchou větu, která je tak na jeden řádek, tak ho polije studený pot a pokusí se o něj mdloby: Znamená to pro celkové dobré řešení navrhnout celou agendu docházky personálu a to nemusí znamenat jenom jejich rozdělení na pracoviště

Strana 5


spolu s pracovní dobou, ale je také třeba vyhodnotit případný požadavek na evidenci plánovaných dovolených, hlášení nemocí, evidenci možných záskoků apod. Je zřejmé, že je třeba zanalyzovat celou agendu docházky, další to větev rozkladu podnikových procesů. Všimněte si, systém sice bobtná, ale pod kontrolou analytika... Závěrem bych chtěl zdůraznit, v čem spočívá kouzlo tohoto příkladu. Všimněte si, že postupným řešením jednoho případu užití vyvstávají nové požadavky na systém. Ty by se také měly řešit ještě na analytické úrovni, a to tak, aby nakonec vše do sebe logicky zapadalo a žádná informace nezůstala takříkajíc „viset v luftě“. A to je mimo jiné jedna z hlavních zodpovědností analytika! Pokud se tento postup podcení a analytik odevzdá neúplný anebo dokonce „žádný“ USE CASE MODEL a BUSINESS PROCESS MODEL, pak hrozí bobtnání projektu a je zaděláno na vážný problém. To, co si mohl analytik v klidu promyslet logicky dopředu, se řeší za pochodu při programování a implementaci se všemi nepříznivými důsledky... Bližší podrobnosti o postupech tvorby UCM a BPM můžete nalézt na již zmíněném školení anebo semináři: http://www.objects.cz/pobyt/pobytovaskolaUML.html http://www.objects.cz/seminare/seminare.html

Konec článku

Strana 6

Šumperský efekt rozmnožení případů užití

Recommend Documents