možné se bez něj obejít? Do jaké míry poslouží při rozhodování o budoucnosti
projektu? To jsou otázky, které si dříve nebo později musí položit manažer,
který je postaven před rozhodnutí téměř hamletovské vyvíjet či nevyvíjet
navržený softwarový systém.
Existují okamžiky v životě manažerů softwarových firem, kdy by si přáli být
jasnovidci. Klasickým příkladem je chvíle prvního rozhodování při tvorbě
informačních systémů. Tehdy se ptají: "Jít do toho projektu nebo ne?" Manažeři
spekulují o tom, co všechno je třeba zabezpečit, aby byl (zatím vysněný)
informační systém úspěšný a uplatnil se na trhu. Jejich úvahy začínají někde u
nutného počtu zaměstnanců pro realizaci projektu a končí tím, jakou
barvu budou mít reklamní materiály. Nakonec se více méně intuitivně rozhodnou
že "ano" a projekt za několik set tisíc nebo milionů rozjedou v plné kráse a...
skončí v propasti. Kde se stala chyba, co nevzali v úvahu?
Informace z okolí
Představme si, že při příštím projektu se již poučený manažer rozhodne, že v
této fázi bude velmi důsledný a začne shromažďovat všechny možné informace k
tomu, aby se náležitě a správně rozhodl. Nakonec dojde k tomu, že opět musí
hádat. Důvod je jednoduchý: Manažer totiž nezná odpověď na základní otázku jde
o složitost a rozsah samotného informačního systému, který se má řešit. A bez
podobného odhadu je úvaha o nákladech a výnosech opravdu sázkou do loterie.
Nakonec přes všechny příznivé odhady projekt sám sebe zahltí, protože firma
není schopna bobtnající systém udržet pod kontrolou.
Slepice nebo vejce...
Rozhodně nechci tvrdit, že ten, kdo posuzuje nemá studovat u projektu okolí a
jeho tržní podmínky. Manažer rozhodující o budoucnosti projektu by měl znát
rozsah systému, jeho složitost, jeho strukturu a podle toho odhadovat náklady a
čas. Vlastně jak jednoduché: Stačí, když si manažer před sebe položí takovýto
již hotový systém, což je však těžko možné. Dostali jsme se tak k problému
popsanému v nadpisu této kapitoly o slepici a vejci. Odpověď na tuto otázku
dává moderní metodologie vývoje softwaru.
Metodologie tvorby softwaru jako řešení
Není třeba mít před sebou hotový systém a podle něj posuzovat jeho rozsáhlost.
K takovému posouzení stačí mít pouze odpovídající model systému. Obecně model
chápeme jako zobrazení reality podle určitého zvoleného náhledu. Protože
jakýkoliv model vytvoříme relativně snadněji než samotný systém, můžeme k
posuzování vlastností, jako jsou rozsah, složitost, struktura atd., dospět o
mnoho dříve než až při vytváření systému.
Informační systém má také své modely, které mohou být různého typu objektový
model tříd, model scénářů apod. Jedním z nich je model případů užití, anglicky
Use Case Model. Někdy bývá tento název modelu překládán do češtiny ekvivalentně
jako model případů užití, model užitných vlastností nebo model užitných
činností.
Model případů užití
Moderní metodologie tvorby softwaru pomocí objektově-orientovaného programování
a komponentové technologie hovoří o tzv. iteračním přírůstkovém procesu tvorby
softwaru. Tento přístup je ve své podstatě logický a jednoduchý, avšak obtížně
se dodržuje. Proces tvorby probíhá cyklicky a přírůstkově minimálně se alespoň
zjišťují požadavky, vytvářejí se základní analytické dokumenty, poté následuje
návrh, implementace, testování a nasazení. V těchto fázích najdeme také
standardní modely systému, jako např. model případů užití, objektový model,
nebo model scénářů. Existují také mohutné a silné prostředky podporující řízení
procesu tvorby softwaru. Jedním z nich je např. produkt Rational Objectory
Process od firmy Rational (viz stránky www.rational.com nebo www.unicorn.cz).
Posouzení modelu případů užití
Projekt prochází na svém počátku důležitou zatěžkávací zkouškou, a tou je
posouzení modelu případů užití. Na základě tohoto modelu lze totiž získat první
signály o neočekávaně velkém rozsahu anebo složitosti systému. Bohužel, opačně
toto pravidlo neplatí. Není zárukou, že pokud z tohoto modelu nevzešel signál o
rozsahu resp. složitosti systému, tak na problémy nenarazíme jinde a jinak
(např. v nutnosti použít drahé technologie). Z hlediska manažera je důležité,
že již v prvních fázích, kdy na projektu pracuje nepočetný tým analytiků, lze
podle rozrůstajícího se modelu případů užití lehce určit, kde se skrývá úskalí
bobtnajícího systému. Potom lze buď rychle projekt skončit (aniž by se poté na
ztrátě podílela celá garda programátorů), nebo se přizpůsobit vznikajícímu
stavu.
Model případů užití nás může upozornit na velký analytický rozsah systému a
může dát první reálnou představu o velikosti systému. Navíc model je obdařen
jednou velmi užitečnou vlastností: Je lehce srozumitelný a jeho čtení
nevyžaduje žádné vysoké odborné znalosti.
Význam modelu případu užití
Je třeba poznamenat, že model případů užití se vytváří v prvé řadě jako součást
vývoje informačního systému. Teprve v druhé řadě slouží jako vodítko pro
rozhodování o osudu projektu. Model vytváří obraz systému z hlediska celkového
užití. Tím mimo jiné provádí celkovou "předběžnou inventuru" z hlediska obsahu
systému a vymezuje analytické hranice systému. Jednoduše řečeno model
prozrazuje, co systém "ještě bude umět" a "co už umět nebude". V tomto ohledu
má model případů užití mezi ostatními modely své nezastupitelné místo: Ostatní
modely musí být s tímto modelem konzistentní v tom smyslu, že každý případ
užití musí mít v jiném modelu nějaké vyjádření a nesmí tam chybět.
Obsah modelu případů užití
Model obsahuje na jedné straně okolí systému, které s ním komunikuje, a na
straně druhé obsahuje celé chování systému s popisem vnějšího pohledu na
požadovanou funkcionalitu. Na první pohled se může zdát, že vytvořit takový
model musí být dost obtížné, avšak opak je pravdou. Pokud máte od konzultanta
nebo budoucího zákazníka dostatek informací, je tvorba modelu velmi rychlá. Při
úplném dostatku analytických informací se u malých systémů jedná řádově o
hodiny až dny, u středních systémů několik dnů až málo týdnů a u velmi
rozsáhlých systémů se jedná o několik týdnů, přičemž dílčí výsledky jsou k
dispozici velmi brzy.
Navíc pokud máte k dispozici dobrý CASE nástroj, je tvorba modelu případů užití
ještě více zjednodušena. Je možné samozřejmě vytvářet model případů užití např.
pomocí textového editoru. V tom případě však nebudete mít možnost tento model
zahrnout mezi ostatní modely vyvíjeného systému. Pokud použijete CASE nástroj,
potom je tento model použitelný i pro tvorbu dalších modelů přímo pomocí
nástroje a udržujete tak přímo konzistenci vývoje v jednom prostředí.
9 0356 / darn
Kurzy na PC březen 1999
2.- 5. 3. ArchiCAD
2.- 5. 3. Corel Draw
9.- 12. 3. Jazyk C
16.-19. 3. AutoCAD
22.3. Internet
22.-24. 3. MS PROJECT 98
22.-26. 3. UNIX I
PROSPEKS, s. r. o.
školicí střediska
Zlín tel.: 067/30 174, 30 221
Olomouc tel.: 068/522 54 18
PŘEDPLATNÉ
ČLÁNKY DO MAILU