Použití RUP pro malé SW projekty

Masarykova univerzita Fakulta informatiky

Použití RUP pro malé SW projekty Diplomová práce

Bc. Pavel Julinek

2008

Prohlášení Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.

Poděkování Děkuji RNDr. Jaroslavu Ráčkovi, Ph.D. za odborné vedení, cenné rady, připomínky a trpělivost při tvorbě této diplomové práce.

ii

Shrnutí Práce se zabývá problematikou metodik pro vývoj softwarových systémů. Je představena metodika Rational Unified Process (RUP), jež je následně konfigurována pro potřeby malých softwarových projektů. Je kladen důraz na výběr důležitých součástí a principů RUP, které efektivně napomáhají při vývoji a nezatěžují ho zbytečnou formálností. Použití konfigurované metodiky je demonstrováno na případové studii.

Klíčová slova Aktivita, artefakt, fáze, metodika, pracovní proces, projekt, Rational Unified Process, role, RUP, UML, vodopád.

iii

Obsah 1

Úvod ..................................................................................................................................1

2

Tradiční vývoj SW...........................................................................................................2 2.1 Výhody vodopádového životního cyklu...................................................................3 2.2 Nevýhody vodopádového životního cyklu ...............................................................3

3

Rational Unified Process .................................................................................................7 3.1 Historie RUP ............................................................................................................7 3.2 Šest základních obecných praktik při vývoji SW.....................................................8 3.2.1 Iterativní vývoj SW ...................................................................................9 3.2.2 Správa a řízení požadavků.........................................................................9 3.2.3 Použití komponentové architektury.........................................................10 3.2.4 Vizuální modelování SW ........................................................................11 3.2.5 Průběžné kontrolování kvality.................................................................11 3.2.6 Řízení změn .............................................................................................12 3.3 Pozměněné základní obecné praktiky při vývoji SW.............................................12 3.3.1 Uzpůsobení vývojového procesu.............................................................12 3.3.2 Vyvažování protichůdných priorit zákazníka..........................................13 3.3.3 Spolupráce napříč týmy ...........................................................................13 3.3.4 Opakované předvádění výsledků.............................................................14 3.3.5 Zvýšení úrovně abstrakce ........................................................................15 3.3.6 Nepřetržitá kontrola kvality.....................................................................16 3.4 Fáze životního cyklu v metodice RUP ...................................................................18 3.5 Cíle jednotlivých fází v metodice RUP ..................................................................18 3.5.1 Fáze zahájení (Inception).........................................................................18 3.5.2 Fáze projektování (Elaboration) ..............................................................19 3.5.3 Fáze realizace (Construction) ..................................................................20 3.5.4 Fáze nasazení (Transition).......................................................................20 3.6 Součásti metodiky RUP..........................................................................................21 3.6.1 Role..........................................................................................................21 3.6.2 Aktivita ....................................................................................................22 3.6.3 Artefakt....................................................................................................22 3.7 Pracovní procesy (workflow) .................................................................................23 3.7.1 Obchodní modelování .............................................................................24 3.7.2 Specifikace požadavků ............................................................................25 3.7.3 Analýza a návrh .......................................................................................25 3.7.4 Implementace ..........................................................................................25

iv

3.8

3.7.5 Testování .................................................................................................26 3.7.6 Dodání .....................................................................................................26 3.7.7 Konfigurační a změnové řízení................................................................27 3.7.8 Projektové řízení......................................................................................27 3.7.9 Prostředí...................................................................................................28 Zhodnocení metodiky RUP ....................................................................................28 3.8.1 Silné stránky ............................................................................................28 3.8.2 Slabé stránky ...........................................................................................29

4

Konfigurace RUP pro malé projekty...........................................................................30 4.1 Modifikace principů iterativního vývoje ................................................................30 4.2 Role.........................................................................................................................30 4.3 Fáze zahájení ..........................................................................................................33 4.4 Fáze projektování ...................................................................................................38 4.5 Fáze realizace .........................................................................................................41 4.6 Fáze nasazení..........................................................................................................44 4.7 Doporučení pro úspěch malých projektů................................................................46

5

Případová studie ............................................................................................................47 5.1 Fáze zahájení ..........................................................................................................47 5.2 Fáze projektování ...................................................................................................53 5.3 Fáze realizace .........................................................................................................56 5.4 Fáze nasazení..........................................................................................................57

6.

Závěr ...............................................................................................................................59

Literatura ................................................................................................................................60 Příloha A (Přehled artefaktů metodiky RUP) .....................................................................62 Příloha B (Přehled rolí metodiky RUP)................................................................................66 Příloha C (Přehled nástrojů rodiny Rational) .....................................................................68 Příloha D (Grafické znázornění fází metodiky RUP)..........................................................72 Obsah CD ................................................................................................................................76

v

1

Úvod

Nárůst počtu softwarových projektů je v dnešní době stále zřetelnější. Vznikají malé a středně velké firmy zaměřující se na vývoj aplikací a systémů. Praxe prokázala, ze řízení vývoje projektů není jednoduchou záležitostí. Pokud projekt není řízen alespoň trochu sofistikovaným způsobem, zpravidla nedopadne úspěšně. Snaha zajistit přijatelnou pravděpodobnost úspěchu projektu vedla k tvorbě mnoha metodik softwarového vývoje. Je ale nutné si uvědomit, že žádná metodika nemůže předem zajistit úspěch projektu. V současnosti existuje velké množství metodik vhodných k různým druhům projektů. Podrobněji o metodikách, jejich kategorizaci a použitelnosti pojednává [Buch05]. V této diplomové práci se zaměříme na metodiku Rational Unified Process, kterou v současné době vlastní společnost IBM. Tato velmi rozsáhlá metodika formalizuje postupy při vývoji softwarového projektu. Jedná se o komerční metodiku, která je navíc napojena na nástroje rodiny Rational. Celkově je tedy tato metodika příliš komplexní a drahá pro použití pro malé a střední projekty. Cílem této diplomové práce je modifikovat metodiku Rational Unified Process pro malé projekty tak, aby byly eliminovány zbytečné formální záležitosti, ale naopak aby podstata metodiky zůstala zachována a její silné stránky byly využity ve vývoji projektů. Vybereme tedy důležité části metodiky Rational Unified Process a uzpůsobíme je pro potřeby malých projektů. Ve druhé kapitole se seznámíme s podstatou tradičních vývojových metodik, které byly založeny na vodopádovém modelu životního cyklu projektu, tzv. vodopádu. Popíšeme hlavní charakteristiky vodopádu a jeho nevýhody pro současné typy projektů. Ve třetí kapitole představíme metodiku Rational Unified Process, podíváme se na její historii a popíšeme šest základních obecných praktik, podle nichž se tato metodika řídí. Zaměříme se na fáze životního cyklu této metodiky, které tvoří základní rámec pro vývoj. Dále popíšeme hlavní součásti této metodiky – role, aktivita, artefakt a pracovní proces. Na závěr třetí kapitoly zhodnotíme silné a slabé stránky metodiky Rational Unified Process. Ve čtvrté kapitole se zaměříme na konfiguraci metodiky pro malé softwarové projekty. Uzpůsobíme základní principy této metodiky, vybereme role důležité z hlediska projektu a artefakty, které nebudou zbytečně ztěžovat práci při vývoji. Pro každou fázi projektu navrhneme příslušné artefakty, jež mají být v dané fázi vytvářeny, a role, které za dané artefakty odpovídají při vývoji. Na závěr této kapitoly uvedeme několik doporučení pro zdárný vývoj malých projektů podle konfigurované metodiky Rational Unified Process. V páté kapitole ukážeme na případové studii, jakým způsobem může probíhat projekt, který je založen na principech konfigurované metodiky Rational Unified Process. Pro každou fázi projektu popíšeme sled důležitých událostí majících zásadní vliv na projekt. Ukážeme náplň činností jednotlivých rolí v dané fázi. Dále přiblížíme artefakty, které byly vytvářeny, na některé z nich se podíváme podrobněji. Uvedeme také nástroje z rodiny Rational, s nimiž se v dané fázi pracuje. Projekt budeme prezentovat z pohledu řízení, nepůjde nám o konkrétní implementační a jiné detaily.

1

2

Tradiční vývoj SW

K tvorbě mnohých projektů je už po mnoho let využíván tradiční vývojový proces, který se nazývá vodopádový životní cyklus. Obvykle je tento název zkracován na termín vodopád. Tento životní cyklus byl pravděpodobně využíván, i když v životní praxi se někteří s tímto termínem nesetkali nebo ho dokonce ani neznali. Tři základní principy vodopádového životního cyklu jsou následující: 1) Nelze efektivně tvořit, vyvíjet nebo budovat, dokud nejsou přesně formulovány výsledné požadavky. 2) Vývoj by neměl začít, dokud nejsou definovány všechny požadavky a zároveň nejsou v konečné podobě. Nemělo by dojít ke změnám požadavků během vývoje, vedlo by to k přepracování už vytvořeného. 3) Nelze začít pracovat na následující fázi projektu, dokud není ukončena jeho předchozí fáze.

Obrázek 2.1: Vodopádový model životního cyklu V návaznosti na předchozí principy jsou uplatňovány zvyky, které jsou s vodopádovým modelem životního cyklu úzce spojeny [Gib06]: • • • •

Požadavky a návrh jsou obsáhle dokumentovány. Přezkoumání (revize) dokumentace je prováděna po každém milníku projektu. Detailní plánování celého projektu je provedeno na jeho začátku. Úspěch projektu je odvozován na základě dodržení termínů milníků a dat stanovených v detailním plánu projektu.

2

2.1 Výhody vodopádového životního cyklu Vodopád je využíván už mnoho let. Jeho nasazení do projektů bylo dávno předtím, než se vývoj SW projektů stal běžnou záležitostí. Vodopád původně pochází z výrobního sektoru a z průmyslu. Ačkoli tento životní cyklus má v dnešní době pro SW vývoj řadu nevýhod, přesto se stále najdou jeho nezanedbatelné výhody. Vodopád je a zřejmě i nadále bude využíván. Je nasazován právě v těch situacích, ve kterých dovede uplatnit své silné stránky, tedy kdy je možné bez větších potíží uplatnit tři základní principy jeho vývoje. Mezi výhody vodopádu můžeme řadit podle Gibbse tyto [Gib06]: • Je intuitivně zřejmé, které činnosti by měly být prováděny v daný časový moment. • Je jednoduché určit pracovní nasazení (počet pracovníků), protože každá fáze má určeny specifické pracovní požadavky a pracovní rozsah v daném časovém okamžiku. • Plánování projektu je jednoduché. • Je jednoduché vyhodnotit pokrok ve vývoji. Stačí porovnat vykonanou práci s plánovanou prací stanovenou v detailním plánu. Vzhledem k těmto výhodám lze určit projekty, u kterých je výhodné použít vodopádový životní cyklus. Tyto projekty by měly mít následující vlastnosti [Gib06]: • Všechny požadavky na projekt a kompletní specifikace jeho cílů jsou známy už na začátku a významně se v době vývoje projektu nemění. • Specifikované požadavky jsou správně formulovány a pochopeny na začátku projektu. • Rizika jsou identifikována a zhodnocena na začátku projektu. • Požadavky mohou být implementovány s využitím technologií, které jsou určeny pro projekt. • Technologie zapojené do projektu se během jeho trvání nemění. • Tým určený pro práci na projektu je dobře seznámen s jeho problémovou oblastí a je sběhlý ve využívání technologií, které jsou pro zdárné dokončení projektu potřeba. Projekt, který splňuje tyto vlastnosti, je vhodné řešit pomocí vodopádového životního cyklu. Z praxe lze předpokládat, že takový projekt bude s největší pravděpodobností úspěšný. Pokud projekt předchozí vlastnosti nesplňuje, je třeba zvážit rizika, která by ho mohla ohrozit.

2.2 Nevýhody vodopádového životního cyklu Je celkem zřejmé, že vodopádový model životního cyklu má řadu nevýhod. Problémy, které se objevují u vodopádu, pramení z aplikace tohoto životního cyklu na projekty, které nesplňují výše popsané podmínky. V následující části znovu projdeme vlastnosti projektu vhodného pro vodopád. Zvážíme problémy, jež se mohou vyskytnout při nedodržení zmíněných podmínek.

Všechny požadavky na projekt a kompletní specifikace jeho cílů jsou známy už na začátku a významně se v době vývoje projektu nemění. U větších projektů, které jsou dnes vyvíjeny, není tato podmínka zpravidla splněna. U mnoha projektů je velmi složité přesně specifikovat požadavky zákazníka. Ve většině případů zákazník není schopen vyjádřit, co opravdu potřebuje. Ale v okamžiku, kdy vidí nějaké řešení, je schopen říci, zda

3

mu vyhovuje. Tento přístup je úzce spojen se změnou požadavků. Čím více řešení zákazník vidí, tím lépe je schopen vyjádřit své požadavky. Z pohledu vývoje projektu je ale velká změna požadavků zhoubou vodopádového životního cyklu. Je to dáno tím, že vodopád využívá přísně sekvenční přístup. Po ukončení fáze specifikace požadavků a návrhu je striktně dáno, jakým způsobem se bude na projektu pracovat. V tomto okamžiku se dodavatel bude hodně bránit novým požadavkům nebo jejich změně, protože to pro něj znamená krok zpět. Musí znovu prozkoumat už vytvořenou práci a modifikovat ji tak, aby vyhovovala změnám a novým požadavkům. Výsledkem je zpoždění projektu a navýšení výdajů na zdroje.

Specifikované požadavky jsou správně formulovány a pochopeny na začátku projektu. Aby systém splnil očekávání zákazníka, musí dodavatel správně a úplně pochopit požadavky vyjádřené zákazníkem. To vyžaduje na začátku projektu víc než pouhé přečtení dokumentů od zákazníka. Je nutná užší spolupráce se zákazníkem, která trvá zpravidla po delší dobu. Navíc má dodavatel za úkol přesvědčit zákazníka, že tento čas je nutný pro správné porozumění a pochopení požadavků. Tuto podmínku lze u vodopádového životního cyklu jen těžko splnit. Typický milník na začátku projektu u vodopádu zpravidla zahrnuje odsouhlasení dokumentace týkající se návrhu, prototypy obrazovek systému a další statické artefakty. Nejsou k dispozici interaktivní spustitelné implementace ani jejich části. Nic není naimplementováno do implementační fáze, kterou se dodavatel u vodopádu zabývá až po fázi návrhu. Takže pochopení požadavků a vzájemné porozumění je postaveno pouze na oboustranném prozkoumání a posouzení dokumentace. Navíc některé dokumentace zobrazují návrhové diagramy, kterým zákazník nemusí rozumět. Obecně lze konstatovat, že rozsáhlá dokumentace není spolehlivým ukazatelem úspěchu celého projektu.

Rizika jsou identifikována a zhodnocena na začátku projektu. Termínem riziko budeme označovat nejistou nebo neznámou událost, která se může v budoucnosti s větší či menší pravděpodobnosti změnit v problém. Ten by mohl negativně ovlivnit průběh nebo výsledek projektu. Je možné nalézt i jiné definice rizika. Podle Project Management Institute je riziko nejistá událost nebo podmínka, která když nastane, má pozitivní či negativní vliv na cíle projektu. Podle K. Frühaufa je riziko problém, který ještě nenastal. V dalším textu budeme brát v úvahu výhradně negativní vliv rizika na projekt. Neexistuje žádná analýza, která by odhalila a odstranila všechna rizika SW projektu, jehož rozsah je netriviální. Přitom nezáleží na zvoleném životním cyklu nebo metodice. To nejlepší, co lze udělat, je věnovat se činnostem, které umožní odhalit rizika dostatečně brzy, tak aby mohly následovat činnosti, které rizika zmírní. Podívejme se na příklad odhalení rizik u typického projektu založeném na vodopádu. Obrázek 2.2 ukazuje tři neočekávaná rizika, která byla odhalena v různých etapách životního cyklu.

4

Obrázek 2.2: Odhalení rizik u vodopádového životního cyklu Riziko 1 bylo odhaleno během fáze požadavků a analýzy. Vzhledem k tomu, že riziko bylo v životním cyklu odhaleno poměrně brzy, je pravděpodobné, že následná opatření nebudou příliš obtížná. Riziko 2 bylo odhaleno během implementační fáze, zhruba v polovině časového plánu, kdy asi polovina zdrojů byla vyčerpána. Záleží na povaze rizika, je možné toto riziko eliminovat, ale určitě si to vyžádá značně zvýšené úsilí členů týmu řešící projekt. Riziko 3 je odhaleno v pozdních fázích projektu, k předání zbývá už jen málo času, většina zdrojů byla spotřebována. Pokud se riziko naplní a bude mít významný dopad, projekt nebude dodán včas. Rizika 2 a 3 způsobila značné potíže, protože byla odhalena v polovině nebo za polovinou životního cyklu projektu. Otázkou je, zda-li je možné tato rizika odhalit dříve, aby nezpůsobila tak velké problémy. U vodopádu je to nemožné. Ale například v metodice Rational Unified Process (RUP), kde je použit iterativní vývoj, je možné rizikům předcházet dříve.

Požadavky mohou být implementovány s využitím technologií, které jsou určeny pro projekt. O technologiích, které budou použity ve fázi implementace, je rozhodnuto ve fázi stanovování požadavků nebo ve fázi analýzy. Navíc požadavky jsou zjišťovány z pohledu zákazníka, tedy bez ohledu na technologii, která bude použita ve fázi implementace. Občas se vyskytne situace, kdy implementace požadavků není možná nebo je neobvykle složitá vzhledem k vybraným technologiím. U vodopádu fáze implementace nezačne, dokud není ukončena fáze zjišťování požadavků a fáze analýzy. To znamená, že zjištění případných problémů je zpožděno. Navíc když se objeví problém s technologiemi, je nutné věnovat čas na revizi požadavků a dále pozměnit návrh tak, aby zohledňoval změněné požadavky. Toto vše zvýší zpoždění projektu.

5

Technologie zapojené do projektu se během jeho trvání nemění. U projektů trvajících déle než rok je možné sledovat skutečnost, že se během této doby na trhu objeví nově vyvinutý SW a HW, který na začátku projektu dostupný nebyl. Otázkou je, zda si zákazník přeje využít nové technologie do svých právě vyvíjených produktů. U vodopádového životního cyklu je proces zavádění nových technologií během fáze implementace nebo integrace a testování velmi riskantní. Záleží na povaze změn, ale může se stát, že dodavatel bude muset blíže přezkoumat artefakty úvodních fází projektu. Pokud je následně potřeba významnou část projektu přepracovat, dojde ke zdržení. V některých případech se projektoví manažeři ze snahy dodržet naplánovaný čas a rozpočet snaží analyzování a testování nově nasazených technologií obejít, aniž by zjišťovali, zda jsou změny technologií kompatibilní s dosavadní provedenou prací. Hrozby tohoto přístupu se objeví ve fázi integrace a testování. V tomto okamžiku problém, který se právě projevil, určitě zbrzdí celý projekt a významně zatíží rozpočet.

Tým určený pro práci na projektu je dobře seznámen s jeho problémovou oblastí a je sběhlý ve využívání technologií, které jsou pro zdárné dokončení projektu potřeba. Tato podmínka úzce souvisí s podmínkou porozumění požadavkům. Jestliže tým pracoval na podobném projektu, pravděpodobně narazí na podobná rizika, s jejichž řešením má už zkušenosti. Navíc na základě předešlých zkušeností může lépe instruovat a navádět zákazníka ve fázi specifikace požadavků. To znamená, že se tým může poučit z minulých projektů nebo fází, a tak předejít opakování stejných chyb. Jelikož vodopádový životní cyklus neumožňuje jednoduše opravit chyby způsobené v minulé fázi, je velkou výhodou mít tým, který má dostatečné zkušenosti s vodopádem. Vývoj v SW průmyslu je značně dynamický. I když tým už řešil podobný projekt, technologie nemusí být stejné jako u předchozího projektu. To může způsobit, že zkušenosti získané z předchozího projektu nemusí být tak využitelné. Vývoj nového SW se hodně podobá vývoji nového výrobku. Pro každý projekt jsou charakteristické: nové technologie, rizika, noví zákazníci, unikátní personálního složení týmu, prostředí jak při vývoji, tak při nasazení produktu. Je zřejmé, že projekty nemohou být jednoduše plánovány měsíce dopředu. Je nutné přistoupit k flexibilnějšímu přístupu, který dovede lépe ošetřovat změny. Vodopádový model životního cyklu obecně vyžaduje detailní plánování celého projektu ještě před jeho začátkem. To způsobuje, že je v SW vývoji nepraktický a nespolehlivý. Je zřejmé, že mnoho SW projektů využívá jiné přístupy než vodopádový model životního cyklu. Jedním z nich je metodika RUP nebo Select Perspective, kterou se v této práci nebudeme zabývat, je však velmi podobná metodice RUP. Více o metodice Select Perspective pojednává [Fro95].

6

3

Rational Unified Process

Rational Unified Process (zkráceně RUP) je komerční metodika společnosti IBM poskytující systematický přístup k vývoji SW. Obsahuje detailní návody, jak postupovat, aby byly splněny cíle a očekávání zadavatelů zakázky a zároveň byla splněna předem definovaná kvalita produktu, jeho rozsah, termín dodání a rozpočet. Popisuje fáze životního cyklu vývoje SW, definuje potřebné role, artefakty, odpovědnosti a pracovní procesy. Na metodiku Rational Unified Process můžeme pohlížet jako na produkt, který je rozvíjen a prodáván, nebo jako na procesní rámec (framework), který může být konfigurován, redukován, rozšířen či jinak upravován podle aktuálních potřeb organizace a konkrétního projektu. V dalším textu se budeme podrobněji zabývat procesním rámcem. Metodika RUP jako komerční produkt obsahuje několik tisíc stran textu a dodává se v elektronické podobě. Obsahuje znalostní bázi s webovým rozhraním a sadu nástrojů. Výhodou je, že může být poskytnuta celému vývojovému týmu, nevýhodou je její velmi vysoká cena. Podle [Buch05] patří metodika RUP mezi rigorózní metodiky, neboť podrobně definuje procesy a činnosti při vývoji SW. Obsahuje vysoký počet kontrolních prvků a vysokou úroveň detailu.

3.1 Historie RUP Počátek vývoje metodiky RUP sahá na začátek 80. let 20. století a je spojen s firmou Rational Software. Jejími zakladateli jsou Paul Levy a Mike Devlin. Tato firma si kladla za úkol úspěšně vyvíjet velké komplexní SW systémy. V této době byly obdobné SW projekty záležitostí vládních orgánů, zejména Ministerstva obrany Spojených států amerických. Firma Rational Software se specializovala na dodávání značkových HW platforem a prostředí pro Adu, což byl v této době upřednostňovaný jazyk na Ministerstvu obrany. Později v 80. letech trendy na obchodním trhu způsobily, že firma Rational Software přehodnotila svou strategii. Nejprve značkové HW platformy ustoupily otevřeným systémům. Byly už zastaralé, příliš drahé a nemohly konkurovat nově vznikajícímu trhu s otevřenými systémy. Navíc otevřené platformy (např. od společnosti Sun Microsystems) byly stál výkonnější. Také osobní počítače se velmi rychle rozšířily a jejich výkon stále rostl. Takže bylo výhodné přejít s vývojem SW systémů v jazyce Ada na tyto nové platformy. Druhým milníkem bylo pomalé ustupovaní jazyka Ada. I když se o pomýšlelo na jeho nasazení v moderním SW vývoji, ukázalo se, že je přebujelý a těžko použitelný. Tato zjištění byla potvrzena rychlým rozvojem komerčního trhu, kde jedním z oblíbených jazyků bylo C++. Byla snaha jazyk Ada vylepšit, ale tento vývoj se zpozdil a byl dokončen až v roce 1995, kdy už bylo příliš pozdě. Takže v současné době je jazyk Ada na trhu jen málo využíván. Konečným trendem, který utvářel strategii firmy Rational Software, byl masivní rozvoj mikroprocesorů ve spotřebním zboží (automobily a různá elektronická zařízení). To způsobilo, že komerční

7

společnosti začaly pracovat na stále větších a komplexnějších SW projektech, ale zároveň měly jen malou zkušenost s vývojem takového SW. Příchod webových stránek umožnil tisícům obchodních společností rozvinout svou prezentaci na Internetu. Vedlo to také k vyvíjení webových aplikací pro zákazníky. Tyto trendy poskytly obrovskou příležitost pro společnost Rational Software. Její poslání se nezměnilo, stále se jednalo o zajištění úspěšného vývoje velkých a komplexních systémů, ale taktika a nabídka produktů pro úspěšný vývoj těchto systémů se zcela změnila. Společnost Rational Software nejprve provedla několik akvizic, čímž získala kompletní sadu produktů, které zahrnovaly nástroje pro celý vývojový cyklus SW vývoje. Jednalo se zejména o nástroje pro podporu managementu, testovací nástroje, analytické a návrhové nástroje nebo nástroje pro automatickou dokumentaci. Téměř ve stejnou dobu se také pracovalo na dvou jiných cílech. Prvním z nich bylo vytvoření standardizované metodiky pro modelování SW systémů. Na počátku 90. let se užívalo několik modelovacích jazyků. Trh byl roztříštěný, proto bylo obtížné vyvinout jeden nástroj, který by podporoval většinu SW vývoje. Řešením bylo, že firma Rational Software zaměstnala tři lidi, kteří měli za úkol vyvinout jeden modelovací jazyk. Byli to Grady Booch, James Rumbaugh a Ivar Jacobson. Podařilo se jim vyvinout jazyk Unified Modeling Language (UML), od něhož se očekávalo, že odstraní z trhu přemíru různých jazyků. Druhým cílem bylo vyvinout dobře popsanou množinu pravidel pro SW vývoj, která by byla podporována nástroji společnosti Rational Software. Tak se zrodila metodika RUP. V roce 2003 společnost IBM zakoupila společnost Rational Software. Metodika RUP je stále rozvíjena a snaží se zaujmout přední místo mezi metodikami SW vývoje [Gib06].

3.2 Šest základních obecných praktik při vývoji SW Metodika RUP byla vytvořena na základě mnohaletých zkušeností vývojářů se SW projekty. V celé metodice se promítají praxí prověřené postupy a praktiky, které vedou k úspěšnému vývoji systémů, zároveň zvyšují produktivitu práce, zlepšují komunikaci jak uvnitř vývojového týmu, tak mezi tímto týmem a zadavatelem, a celkově zefektivňují celý vývojový proces. Metodika RUP se od své první verze až do roku 2005 soustředila na vývoj SW pomocí šesti základních obecných praktik. Tyto praktiky (Best Practices) jsou následující [Gib06, Kru01]: 1) 2) 3) 4) 5) 6)

Iterativní vývoj SW. Správa a řízení požadavků. Použití komponentové architektury. Vizuální modelování SW. Průběžné kontrolování kvality. Řízení změn.

8

3.2.1 Iterativní vývoj SW Dnešní požadavky na důmyslné a propracované SW systémy jsou takové, že neumožňují vývoj pomocí vodopádového životního cyklu. Je nemožné postupovat sekvenčně: nejprve specifikovat celý problém, navrhnout kompletní řešení, vytvořit SW a nakonec ho testovat. Hlavním problémem tohoto přístupu je to, že chyby jsou odhalovány později, takže je mnohem nákladnější je opravit v pozdějších fázích projektu než v jeho raných fázích. Úvodní návrh bude pravděpodobně chybný, zpravidla se zaměří jen na klíčové požadavky a pozdější odhalení návrhových chyb povede k překročení rozpočtu nebo v horších případech k celkovému neúspěchu projektu. Tom Gilb výstižně tvrdí: „Pokud v projektu aktivně nenapadnete rizika, napadnou ona vás.“ Vodopádový životní cyklus zakrývá reálná rizika projektu. Zpravidla je odhaluje v době, kdy už je příliš pozdě se s nimi smysluplně vypořádat. Alternativou k vodopádovému životnímu cyklu je iterativní přístup, který umožňuje lepší porozumění problému díky postupnému vylepšování vyvíjeného SW. Iterativní vývoj lépe odhaluje vysoká rizika v každé fázi životního cyklu, a tak významně snižuje jejich dopady. Rizika projektu jsou identifikována zejména v počátečních fázích životního cyklu projektu, takže je možné je napadnout a reagovat na ně včas a efektivně. Rizika jsou tedy napadnuta a ošetřena dříve, než mohou napadnout celý projekt. Iterativní přístup nabízí řešení několika základních problémů, které se vyskytují při vývoji SW. Vážná nedorozumění a nepochopení mezi zákazníkem a vývojovým týmem jsou viditelná na počátku projektu, kdy je možné rychle a levně zjednat nápravu. Vyvinuté verze jsou předány uživatelům, kteří poskytují zpětnou vazbu, čímž lze dolaďovat požadavky na systém. Vývojový tým je nucen se zaměřovat na problémy pro projekt kritické a neřešit méně důležité záležitosti, které by odváděly pozornost od reálných hrozeb. Neustálé iterativní testování umožňuje objektivní hodnocení stavu projektu. Nesoulad mezi požadavky, návrhem a implementací je brzy odhalen. Pracovní nasazení týmů, obzvláště týmů pro testování, je rovnoměrné během celého životního cyklu projektu. Tým může získávat zkušenosti a poučit se z jednotlivých fází projektu, takže může průběžně zlepšovat svou práci. Zákazníci mají konkrétní spustitelné části systému, takže mají představu o stavu projektu během celého životního cyklu.

3.2.2 Správa a řízení požadavků Při vývoji SW se v průběhu času požadavky dynamicky mění, proto je nutné, aby byly očekávány a následně spravovány. Identifikace správných systémových požadavků je nepřetržitý proces. Těmito požadavky máme na mysli ty, které mají významný dopad na ekonomické a technické cíle systému. Kromě triviálně jednoduchých systémů je před začátkem vývoje nemožné kompletně specifikovat požadavky na systém. Navíc zákazník při dodání části systému zpravidla své požadavky změní nebo rozšíří. Uživatelé obvykle na začátku ani neví, co přesně chtějí, ale pokud nějaký systém vidí, dovedou lépe vyjádřit, co chtějí a potřebují a co je pro ně zbytečné. Požadavek je vlastnost nebo schopnost, kterou musí systém splňovat. Správa požadavků se zaměřuje na tři činnosti: zjišťování, utřídění a dokumentace funkcionality a omezení systému; vyhodnocení

9

změn požadavků a posouzení jejich dopadu na systém; sledování a dokumentace kompromisů a rozhodnutí. Správa a řízení požadavků v projektu umožňuje následující: komunikace probíhá formálně definovaným způsobem; požadavkům je možno určit prioritu, třídit je a sledovat; funkcionalitu a výkonnost je možné objektivně hodnotit; nekonzistence jsou jednodušeji objeveny; pomocí vhodných nástrojů je možné přehledně uchovávat všechny systémové požadavky, které se objevily v historii celého projektu, zároveň jsou provázány s příslušnými externími dokumenty.

3.2.3 Použití komponentové architektury Zobrazování, specifikace, tvorba a dokumentace SW systému vyžaduje, aby bylo na systém nahlíženo z různých perspektiv. Všichni lidé, kteří se na tvorbě systému nějak podílí (koncoví uživatelé, analytici, programátoři, systémoví integrátoři, testeři, projektoví manažeři), plní různé úkoly, dívají se na systém různým způsobem, který se v průběhu životního cyklu mění. Architektura systému je zřejmě nejdůležitější součástí, která má vliv na různé úhly pohledu a zároveň má dopad na iterativní a inkrementální vývoj systému během jeho celého životního cyklu. Architektura systému je ovlivněna množinou zásadních rozhodnutí, mezi než patří například: organizace SW systému; výběr základních prvků a jejich rozhraní, z nichž je systém složen; chování těchto prvků, hlavně specifikace vzájemné spolupráce; sestavení strukturních prvků do postupně větších subsystémů a definice jejich chování. Architektura SW není zaměřena pouze na strukturu a chování, ale také na použitelnost, funkcionalitu, výkonnost, robustnost, znovupoužitelnost, srozumitelnost, ekonomická a technologická omezení, smluvní a estetické záležitosti. Tvorba robustní architektury je důležitá, protože má významný vliv na znovupoužití, umožňuje přehledné rozdělení úkolů mezi vývojové týmy, separuje HW a SW závislosti, které mohou být předmětem změny, a zlepšuje udržovatelnost. To vše má samozřejmě významné finanční dopady. Pro SW architekturu je důležité užívání komponent při vývoji. Z mnoha komerčních zdrojů lze získat komponenty, které lze znovu použít nebo upravit na míru podle dané potřeby. Component Object Model (COM), Object Management Group’s (OMG), Common Object Request Broker Architecture (CORBA) a Enterprise JavaBeans (EJB) poskytují široce podporované platformy, na nichž lze úspěšně použít komponentovou architekturu. Použití komponentové architektury spolu s praktikou iterativního vývoje SW mají za následek neustálý rozvoj architektury systému. Každá iterace produkuje architekturu, která může být měřena, testována a porovnávána se systémovými požadavky. Tento přístup umožňuje neustálé napadání nejzávažnějších rizik projektu.

10

3.2.4 Vizuální modelování SW Model je zjednodušený pohled na realitu popisující systém z různých úhlů pohledu. Modely jsou vytvářeny, protože je nutné lépe porozumět systému, který má být vytvořen. Rozsáhlým systémům nelze najednou porozumět v celém jejich rozsahu. Modelování je důležité, protože napomáhá vývojovému týmu zobrazit, specifikovat, tvořit a dokumentovat strukturu a chování architektury systému. Používaní standardního modelovacího jazyka jako je například UML (Unified Modeling Language) umožňuje členům vývojového týmu vzájemnou nezkreslenou komunikaci, pomocí níž mohou jednoznačně formulovat svá stanoviska či rozhodnutí. Modelovací nástroje ulehčují správu modelů, umožňují skrýt nebo naopak vyzdvihnout potřebné detaily. Modelování také napomáhá udržovat konzistenci mezi artefakty systému a zlepšuje schopnost týmu vypořádat se s jeho složitostí. Pokud praktiku modelování spojíme s praktikou iterativního vývoje SW, zjistíme, že napomáhá k vyzdvihnutí a ohodnocení změn architektury a o těchto změnách mohou diskutovat všichni členové vývojového týmu. Pokud jsou vybrány správné modelovací nástroje, je možné v každé iteraci synchronizovat modely a zdrojové kódy. Mezi hlavní využívané modely můžeme řadit: modely případů užití, diagramy scénářů, diagramy tříd, stavové diagramy, komponentové diagramy a diagramy dodání. Výhody modelování: modely případů užití a scénáře jednoznačně specifikují chování systému; modely zachycují návrh SW; je zachycena nemodulární a nezměnitelná architektura; detaily mohou být skryty, pokud je to potřeba; modely lehčeji odhalují nekonzistence.

3.2.5 Průběžné kontrolování kvality Nalezení a oprava chyby po dodání systému je 100krát až 1000krát dražší než před dodáním. Proto je důležité neustálé hodnocení kvality systému s ohledem na jeho funkcionalitu, spolehlivost, aplikační a systémovou výkonnost [ChTh02]. Kontrola funkcionality systému zahrnuje vytváření a provádění sady testů pro každý klíčový scénář. Každý z těchto scénářů představuje jeden definovaný a požadovaný způsob chování systému. Zjišťuje se, které scénáře při testování neuspěly a co bylo příčinou neúspěchu. Dále se zkoumá, které scénáře odpovídají dosud netestovanému zdrojovému kódu. Pokud vývoj systému probíhá iterativně, je SW testován v každé iteraci, což lze považovat za průběžné kontrolování kvality. Mezi hlavní přínosy kontroly kvality patří: hodnocení stavu projektu je objektivní na základě výsledku formálních testů, neprovádí se hodnocení v subjektivní „papírové“ podobě; objektivní hodnocení odhalí nekonzistence ve specifikaci, návrhu a implementaci; testování a verifikace se zaměřují na části systému s největším rizikem, tím se zvyšuje kvalita a efektivita těchto částí; chyby jsou odhaleny zavčas, čímž se snižují náklady na jejich ošetření; nástroje pro automatické testování umožňují testování funkcionality, spolehlivosti a výkonnosti.

11

3.2.6 Řízení změn Při vývoji rozsáhlého systému je jednou z hlavních komplikací fakt, že je nutné vypořádat se s rozčleněním vývojářů do týmů, které jsou pravděpodobně umístněny na různých místech, ale na druhou stranu spolupracují na společných iteracích, produktech či platformách. Pokud by za těchto okolností chybělo sofistikované řízení, vývoj by rychle zdegeneroval v chaos. Koordinace činností a artefaktů různých týmů vyžaduje vytvoření opakovaného pracovního procesu (workflow) řídícího změny SW a artefaktů. Tato koordinace umožňuje lepší alokaci zdrojů, které vychází z priorit a rizik projektu. Spolu s praktikou iterativního vývoje umožňuje tato praktika průběžné monitorování změn, což vede k odhalení problémů, na něž je možné následně reagovat. Řízení změn má podle [Kru01] následující výhody: pracovní proces změna požadavků je formálně definován a je opakovatelný; požadavky na změny ulehčují jasnou a přesnou komunikaci; důsledné rozdělení práce snižuje riziko zasahování do práce ostatním členům týmu; statistika počtu změn je dobrou metrikou pro objektivní hodnocení stavu projektu; šíření změn je možno hodnotit a řídit.

3.3 Pozměněné základní obecné praktiky při vývoji SW Výše popsané základní obecné praktiky byly vyvinuty na základě zkušeností s vývojem velkých a komplexních SW systémů. Byly navrženy tak, aby byly použitelné v nabízených produktech společnosti Rational Software. Návrháři metodiky RUP pokračovali v rozvíjení této metodiky a praktik. V říjnu 2005 se v časopise The Rational Edge objevil článek, v němž Petr Kroll a Walker Royce pozměnili a modernizovali šest základních obecných praktik. Výsledné změny jsou následující [Gib06]: 1) 2) 3) 4) 5) 6)

Uzpůsobení vývojového procesu. Vyvažování protichůdných priorit zákazníka. Spolupráce napříč týmy. Opakované předvádění výsledků. Zvýšení úrovně abstrakce. Nepřetržitá kontrola kvality.

3.3.1 Uzpůsobení vývojového procesu (Adapt the Process) Každý projekt je odlišný. Velké projekty, na nichž pracuje mnoho lidí a týmů, které jsou geograficky roztroušené, vyžadují více formálnosti a řízení než malé projekty s několika lidmi. Navíc u každého projektu se může úroveň řízení velmi odlišovat, záleží to na vynalézavosti, kreativitě a originalitě, která je požadována. Je těžké být kreativní, pokud musí být zachovány mnohé formální způsoby řízení. Na druhou stranu existují projekty provádějící údržbu nebo vylepšující kritický SW, u něhož selhání může způsobit ztráty na životech. U takových projektů je vyšší úroveň formálnosti vyžadovaná a potřebná. Cílem je adekvátně zhodnotit situaci a modifikovat způsob zpracování projektu. Na jednu stranu je nutné, aby zbytečná formálnost nebránila rozvoji kreativního myšlení, na druhou stranu je potřeba, aby se projekt nestal neřiditelný. Podrobněji o výběru úrovně řízení projektu pojednává [BoTu03].

12

Úroveň řízení se také odvíjí od délky projektu. Například během počátečního vývoje potřebují vývojáři volné pole působnosti, aby mohli rychle vyzkoušet nové přístupy bez toho, aby je někdo striktně řídil a kontroloval. Nicméně jakmile se základní myšlenky projektu vykrystalizují nebo je dodána nová verze SW, je nutné změny formálně řídit. V následujícím výčtu je seznam charakteristik, u nichž je potřeba vyšší úroveň řízení a formálnosti. Projekt by měl být s těmito charakteristikami porovnán. Pokud jich má více, je dobré nasadit formálnější řízení a způsob zpracování než u projektů majících méně těchto charakteristik nebo dokonce žádnou [Gib06]. • • • • • •

Projektový tým je geograficky roztroušený. Skupina uživatelů produktu je velká a geograficky roztroušená. Projektový tým je složen z různých podtýmů, každý pracuje na různé části projektu. Produkt musí splňovat přísnější standardy, proti kterým musí být kontrolován. Vyvíjený produkt je technicky komplexní. Projekt je v pozdější části vývojového cyklu. Jinými slovy, dřívější fáze životního cyklu vyžadují méně formálnosti než pozdější fáze.

Způsob zpracování by měl být přizpůsobován a dolaďován na základě jiných projektů. Jakmile se SW firma stane trochu zkušenější, měla by své dřívější poznatky a zkušenosti zahrnout do projektů, které budou následovat později. Analýza postmortem se zabývá vyhodnocením ukončených projektů. Její výstupy mohou být nápomocné při zpracování nových projektů.

3.3.2 Vyvažování protichůdných priorit zákazníka (Balance competing stakeholder priorities) Pro mnoho SW týmů se stalo rutinou se nejprve zaměřit na detailní specifikaci požadavků od zákazníka a potom podle těchto požadavků vyvíjet SW. Ale tento přístup ignoruje možné příležitosti, které mohou uspokojit zákazníka jednodušším a bezpečnějším způsobem. Jedním ze způsobů, jak obejít rizika obsažená ve vývoji SW na míru, je vyhnout se takovému vývoji nakolik, nakolik je to jen možné. Lze toho dosáhnout použitím komerčního SW nebo už vyvinutého SW. Nejprve je nutné, aby projektový tým porozuměl business procesům a potřebám zákazníka. Zákazník by měl pochopit, že musí udělat kompromis mezi vlastní požadovanou funkcionalitou a možností, jak alternativně naplnit požadavky levněji a rychleji, například pomocí komerčního SW. Projektový tým by měl zákazníkovi pomoci přesně pochopit, které požadavky jsou pro něj důležité a kterých by se měl vzdát za cenu levnějšího a rychlejšího řešení.

3.3.3 Spolupráce napříč týmy (Collaborate across teams) Spolupráce je mnohem víc než jen pouhá komunikace. Znamená to vytváření týmů, které sdílí rizika a odměny, pracují kooperativně, aby dosáhly požadovaných projektových cílů. Znamená to také mezitýmové proaktivní sdílení informací, což umožňuje poskytovat informace, které mohou být nápomocny nějakému z týmů. Je také důležité vytvářet integrované prostředí, v němž mají členové týmu delegovanou pravomoc a chtějí převzít rizika a zodpovědnost.

13

Je třeba si také uvědomit, že spolupráce napříč týmy zahrnuje i skupiny lidí, které jsou často opomíjeny nebo zmíněny jen okrajově. Sem patří například lidé, kteří budou spravovat vytvořený systém, nebo lidé zajišťující formální náležitosti smluv (právní oddělení) atd.

3.3.4 Opakované předvádění výsledků (Demonstrate value iteratively) Opakované předvádění výsledků je možná nejvýraznější praktikou z šesti základních obecných praktik. V následujícím textu se zamyslíme nad hlavními principy iterativního vývoje. Komplexní SW systém je možné efektivně vyvíjet, když je rozložen na několik menších problémů, které jsou následně řešeny. Je výhodné použít pravidlo „rozděl a panuj“, tedy vytvořit několik méně složitých problémů. Složitý problém je tedy řešen tak, že jsou nejprve řešeny jednotlivé dílčí problémy. To umožňuje zaměřit se v daný čas na vybranou podmnožinu problémů. Je nemožné plně porozumět požadavkům na systém, pokud jsou jen tak sepsány. Dokumentace je stále důležitá, ale nezaručuje, že jsou identifikovány náležité požadavky a je řádně pochopena komplexnost vytvářeného sytému. Navíc je pro zákazníka jednodušší poznat, že vývoj jde správným směrem, pokud má občas nějaký hmatatelný výstup, který mu umožňuje nahlédnout do částečně implementovaného systému. Většina zákazníků nerozumí návrhovým a analytickým artefaktům. Lepší identifikace rizika a zmírnění jeho potenciálních následků je možné, pokud je více činností na SW projektu prováděno v raných fázích životního cyklu projektu. U vodopádového životního cyklu projektu nebylo mnoho důležitých činností (např. implementace a testování) prováděno, dokud nepokročil projekt do odpovídající fáze. To znamená, že možné problémy spojené s danými činnostmi není možné dřív odhalit. Naopak u iterativního vývoje jsou všechny činnosti prováděny dříve než u vodopádu. Dřívější odhalení problému vede k jeho včasnému řešení. Navíc řešení jednotlivých iterací je zpravidla seřazeno podle rizik. To znamená, že se nejprve řeší iterace projektu zaměřující se na ty části systému, které mají potenciálně nejvíce rizik. Jestliže vývoj systému směřuje k vážnému problému, je žádoucí, aby se problém objevil co nejdříve je to možné. To následně umožňuje přeskupit zdroje a určit, jak problém vyřešit. Zároveň ještě zůstává významné množství času a zdrojů. Každá iterace projektu by měla vyústit v kus kódu, který umožňuje ukázat část funkčnosti systému, jenž bude předvedena zákazníkovi. Vytvoření spustitelné ukázkové verze systému v raných fázích životního cyklu projektu umožňuje přesněji posoudit správné směřování projektu. Plánování může být založeno na základě současné zkušenosti s vývojem částí systému. Je to flexibilnější a přesnější než plánování pracující s odhady na základě pouhé dokumentace.

Výhody opakovaného předvádění výsledků Iterativní vývoj umožňuje dřívější odhalení vážných problémů a rizik než vodopádový životní cyklus. Je více adaptabilní na změny ve specifikaci požadavků. Požadavky jsou „zmrazeny“ pouze po dobu jedné iterace. Navíc jsou „zmrazeny“ pouze požadavky ovlivňující danou iteraci. Jakékoli změny požadavků v současné nebo předchozí iteraci mohou být naplánovány na následující iteraci. Mohou být změněny priority dosud neimplementovaných požadavků nebo může být změněno pořadí požadavků v iteracích nebo mohou být nové požadavky začleněny do iterace.

14

Iterativní vývoj umožňuje zákazníkům mít ještě před koncem projektu spustitelný kód implementující dané části systému. Zhotovitel systému tak může získat zpětnou vazbu od zákazníka a může přizpůsobit systém, pokud má zákazník nějaké připomínky. Jestliže se vyskytne problém v časovém plánu, je možné sestavit ranou verzi systému, který nebude implementovat některé požadavky. Je to uskutečnitelné kvůli tomu, že každá iterace poskytuje spustitelný kód. Zákazník je spokojenější, pokud dostane ranější verzi systému včas, než když má čekat na dokončení celého vývoje. Tohoto nelze dosáhnout u vodopádového životního cyklu.

3.3.5 Zvýšení úrovně abstrakce (Elevate the level of abstraction) Mnoho dnes vyvíjených SW systémů je docela komplexních. I nejzkušenější SW inženýři se nemohou dostatečně vypořádat se všemi detaily systému najednou. Abstrakce napomáhá představě vypořádat se s komplexností a s pochopením systémové architektury. Důležitou myšlenkou v objektově orientovaných metodikách je pojetí třídy. Třída zapouzdřuje data objektu a poskytuje funkce umožňující měnit data objektu daným způsobem. Data, která se dělí na atributy a metody, jsou zpřístupněna na základě implementace autora. Implementační detaily jsou pro uživatele programově skryté. Komponenta rozšiřuje toto pojetí a je považována za jednotku funkcionality. V návaznosti na pojetí třídy je komponenta kolekce logicky seskupených tříd. V každé komponentě je obsažena funkcionalita mající správně definovaný interface. Komponenta je částí systému. Interface představuje atributy a metody nezbytné pro aplikačního vývojáře k tomu, aby mohl komponentu efektivně využívat. Na obrázku 3.1 je příklad třívrstevné architektury. Všechny přístupy ke komponentám jsou z aplikační programovací vrstvy (API). Jinými slovy se jedná o interakci komponent, kde volání z komponenty do jiné komponenty je umožněno skrze interface komponent.

Obrázek 3.1: Třívrstevná architektura [Gib06]

15

Aplikace používající komponentovou architekturu mají několik výhod: Interface komponenty jasně definuje hranice mezi samotnou komponentou a uživateli komponenty. Komponentová architektura umožňuje pochopit, jakým způsobem je systém navržen, aniž by se člověk ztratil ve velkém množství detailů. Komponenty jsou snadným způsobem znovupoužitelné. V praxi jsou celé architektury často znovupoužity v různých projektech. Představa třívrstevné architektury je ukázána na obrázku 3.1. Protože komponenta vykonává specifickou funkci a má dobře definované rozhraní, je jednodušší tuto komponentu znovu použít v jiném projektu, než vyvíjet novou obdobnou. Komponentová architektura je jednodušší na údržbu. Jelikož komponenty programově skrývají své implementační detaily a závislosti jsou řešeny jen přes API, změny v implementaci komponenty téměř neovlivní její uživatele (API zůstává nezměněno). To znamená, že změny kódu mohou méně ovlivnit ostatní části systému. K ovlivnění může dojít při změně implementace, kdy komponenta předává přes API jiné výsledky než před její změnou. Ale samotná změna kódu nemůže přímo ovlivnit chování systému v jiné jeho části. Tedy komponenta je zapouzdřena. Komponentová architektura umožňuje vyvíjet funkční části systému různými týmy. Pokud týmy striktně dodržují konvence definované v rozhraní komponent, mohou vyvíjet kód odděleně. Tato skutečnost umožňuje práci distribuovaným týmům. Jiným způsobem, jak zvládnout implementaci komplexních systémů, je znovupoužití existujících systémů nebo už vyvinutých komerčních systémů (např. databáze, jiné komerční komponenty).

3.3.6 Nepřetržitá kontrola kvality (Focus continually on quality) První činností, která člověka obvykle napadne, když se zamyslí nad kvalitou vývoje SW, je testování. V metodice RUP se testování, zlepšování a měření kvality objevuje ve všech fázích životního cyklu projektu. V následujícím textu si popíšeme některé důležité činnosti spojené s kvalitou SW.

Projektový management Jedním z hlavních úkolů projektového managementu je udržet projektový tým zaměřený na správné cíle ve správný čas. Existuje více způsobů, jak tohoto dosáhnout. V metodice RUP jsou dva klíčové artefakty napomáhající projektovému managementu: plán iterace a vyhodnocení iterace. Iterační plán je detailní plán, který identifikuje, čeho má být dosaženo v dané iteraci. Zahrnuje seznam rizik, která je potřeba prozkoumat nebo je nutné se s nimi vypořádat, podmnožinu požadavků, jež by měly být implementovány, a pravděpodobně nějaké požadavky na změny, které musí být ošetřeny. Vyhodnocení iterace je vyvážené pravdivé zhodnocení, které porovnává dosažené cíle s plánem iterace. Zjišťuje, zda byly cíle iterace naplněny. Je to více než pouhá kontrola splnění implementačních požadavků stanovených pro danou iteraci. Důležité je, jestli rizika odhalená během iterace byla úspěšně odstraněna nebo zmírněna. Také je potřeba si všímat, zda nebyla identifikována nová rizika nebo nevyvstal nějaký nový problém. Výsledky vyhodnocení iterace jsou využity v plánu následujících iterací.

16

Další měření v projektovém managementu zahrnují tradiční měření jako například sledování spotřebovaných zdrojů vzhledem k plánovaným, sledování přidané hodnoty atd. Je důležité si povšimnout, že metodika RUP upřednostňuje adaptivní plánování před prediktivním plánováním. Projekty využívající iterativní model životního cyklu by neměly vytvářet detailní plány na svém začátku. Naopak detailní plány jsou vytvářeny pro současnou iteraci a možná pro následující iteraci. Detailní plány iterací jsou tvořeny s ohledem na průběžnou zkušenost s projektem, nové požadavky, odhalená rizika atd. Proto není smysluplné pokoušet se vytvořit detailní plán celého projektu a striktně sledovat jeho naplňování. Jinými slovy jestliže chceme dodržet časový plán nebo zdroje kvůli smluvním požadavkům, odchýlení od plánu na začátku projektu nemusí nutně znamenat problémy projektu. Je důležité přizpůsobovat plány s ohledem na vývoj projektu.

Zpracování požadavků Ověřování kvality požadavků zahrnuje pečlivé přezkoumání dokumentu požadavků ze tří pohledů: • Zda dokument s požadavky skutečně odráží potřeby zákazníka. • Zda jsou dokumentované požadavky testovatelné a verifikovatelné. • Zda jsou dokumentované požadavky detailní natolik, aby byly jednoznačné a vývojář jim rozuměl. Vyjasněné požadavky by měly být řádně zdokumentovány. Případné změny musí být pečlivě dokumentovány a kontrolovány. Změny požadavků by měly být automatizované. K tomu slouží nástroje pro sledování změn.

Analýza a návrh Ověřování kvality u analýzy a návrhu zahrnuje přezkoumání vytvořených artefaktů. Zejména je důležité se soustředit na následující skutečnosti: • Zda artefakty z analýzy a návrhu odpovídají artefaktům požadavků. Cílem není kontrolovat každý detail, ale to, zda tvůrci analýzy a návrhu pochopili požadavky, které mají být naplněny. • Zda mají artefakty odpovídající detailní úroveň. • Zda jsou artefakty pochopeny vývojáři, kteří provádějí „překlad“ návrhu do spustitelného kódu.

Testování Ve vodopádovém modelu životního cyklu se testování uskutečňovalo až ve velmi pozdních fázích životního cyklu. Je nemožné testovat dříve, protože žádný kus kódu není k dispozici. Pokud má projekt zpoždění, velmi často se stává, že je testování časově zkráceno nebo k němu vůbec nedojde. Testování je jednou z posledních aktivit projektu, proto je velká tendence ho v časové tísni omezovat, zejména pokud si projektový manažer nedostatečně uvědomuje důležitost testování. Výsledný produkt má nakonec spoustu nedostatků. Naopak u iterativního modelu životního cyklu se testování provádí v každé iteraci, zvláště ke konci iterace. Odhalené nedostatky mohou být odstraněny a stabilní část řešení může být ukázána zákazníkovi. V iterativním modelu životního cyklu má každá iterace dané cíle a požadavky, které musí být naplněny. Testování může probíhat dokonce i v úvodních fázích projektu.

17

3.4 Fáze životního cyklu v metodice RUP V metodice RUP je model životního cyklu projektu rozdělen do čtyř fází: fáze zahájení (Inception), fáze projektování (Elaboration), fáze realizace (Construction) a fáze nasazení (Transition) [Kad04]. Každá fáze má rozdílné zaměření, které ovlivňuje obsah jednotlivých iterací během fáze. RUP popisuje proces ve dvou rovinách. Na obrázku 3.2 je na horizontální ose zobrazen postup projektu v čase, na vertikální ose jsou popsány jednotlivé pracovní procesy. U každého pracovního procesu je zobrazen vývoj úsilí, které je potřeba vyvinout pro vybrané činnosti během životního cyklu projektu. Například je vidět, že testování je prováděno na závěr každé iterace, nejvíce úsilí je vyvinuto v posledních iteracích fáze realizace, naopak ve fázi nasazení úsilí klesá.

Obrázek 3.2: Fáze, iterace a pracovní procesy životního cyklu metodiky RUP

3.5 Cíle jednotlivých fází v metodice RUP Čtyři různé fáze životního cyklu vývoje projektu se od sebe odlišují nejen počtem obsažených iterací, ale hlavně intenzitou jednotlivých pracovních procesů. Součástí každé fáze je pevně definovaný milník, jehož splnění je nutnou podmínkou pro přechod do další fáze. Každá fáze má dále určitý účel a sadu cílů. V následujícím textu tyto fáze podrobněji představíme.

3.5.1 Fáze zahájení (Inception) Cílem fáze zahájení je dosažení daného milníku životního cyklu. Při dosažení tohoto milníku by mělo být zřejmé, zda se bude v projektu pokračovat, zda bude změněn jeho obsah nebo bude zrušen. Roz-

18

hodnutí, jak dále naložit s projektem, napomáhají různá hodnotící kritéria, mezi která podle Gibbse patří zejména tato [Gib06]: • Je se zákazníkem shoda v klíčových požadavcích na systém? V tomto okamžiku životního cyklu nejsou známy detailní požadavky, ale klíčové požadavky nejvyšší úrovně specifikovány jsou. Mezi ně například patří rozsah systému. Do této skupiny kritérií patří i následující otázky: Kdo bude systém užívat? Kolik bude uživatelů systému? Které business procesy budou systém řídit? Bude systém webově orientován, nebo bude založen na něčem jiném? • Souhlasí zákazník s cenou a časovým plánem, který je nutný pro vývoj systému? • Byla identifikována významná rizika a byla zahrnuta do plánování? Chápe zákazník rizika a jejich následky, pokud se projeví? V této fázi by měly být cíle, vize a seznam rizik v písemné podobě předány zákazníkovi k odsouhlasení. Iterace ve fázi zahájení jsou často nejobtížnější, protože mohou mít výzkumný charakter, tedy nelze předpokládat úspěšný konec. Není neobvyklé, že výsledné artefakty z fáze zahájení jsou na jednorázové použití, následně jsou zahozeny. Nicméně zkušenosti získané z raných fází projektu jsou pro další projekty velmi cenné. Na druhou stranu pokud jsou projektové cíle správně pochopeny a vývojový tým má zkušenosti s podobným systémem z minulosti, je možné, že fáze zahájení má pouze jednu iteraci. V tom případě se jedná pouze o prostou (bez více iterací) fázi životního cyklu.

3.5.2 Fáze projektování (Elaboration) Cílem fáze projektování je určit a ověřit architekturu systému, který má být vyvíjen. Je toho dosaženo pomocí iterací, které se vypořádávají s požadavky ovlivňujícími architekturu. Hlavní pozornost je věnována funkčním a dodatečným požadavkům, které významně ovlivňují architekturu systému. Například se zvažují následující skutečnosti: Kolik uživatelů současně může využívat systém? Jaké požadavky jsou kladeny na dobu odpovědi systému? Jaké jsou požadavky na spolehlivost sytému? Závisí na systému lidské životy? Výsledek iterací prováděných během fáze projektování napomáhá určit, zda je architektura systému realizovatelná a dále životaschopná. Je důležité, že pozornost stále zůstává zaměřena na architekturu. Jestliže například vybraná architektura nemůže vyhovět následným dodatečným požadavkům, systém po dodání nesplní očekávání. Přitom nezáleží na tom, jak kvalitní byly následující fáze vývoje. Klíčová výstupní měřítka fáze projektování jsou podle Gibbse následující [Gib06]: • Artefakty vytvořené v předchozí fázi (například vize produktu, obchodní případy a klíčové požadavky) jsou neměnné. • Architektura určená pro systém je ověřena pomocí spustitelného kódu, který je vytvořen v iteracích. Tento kód zahrnuje hlavní požadavky na systém. Rizika jsou identifikována a zmírněna. Jsou zaznamenány výsledky testů pro každou verzi spustitelného kódu. • Většina detailních požadavků na systém je identifikována ve fázi projektování. Je třeba si uvědomit, že některé detailní požadavky mohou být stále neznámé, ale nejdůležitější poža-

19

davky pro zákazníka jsou známé. Neexistuje přesné číslo, ale obecně se odhaduje, že 80 % požadavků na systém je identifikováno ve fázi projektování. • Trendy ovlivňující výdaje na zdroje (čas a rozpočet) jsou pro zákazníka přijatelné. • Plány iterací pro fázi realizace by měly být vytvářeny ze závěrů fáze projektování. Měl by být stanoven detailní plán pro úvodní iteraci fáze realizace. Zjištění během první iterace mohou vést ke změně následující iterace. Výsledky fáze projektování jsou na závěr vyhodnoceny. Jestliže výstupní měřítka ukazují, že bylo dosaženo přijatelných výsledků, projekt pokročí do fáze realizace.

3.5.3 Fáze realizace (Construction) V projektech založených na RUP se většina zdrojů a času spotřebuje ve fázi realizace. V tomto okamžiku jsou všechna hlavní rizika vývoje systému identifikována a zmírněna, architektura je vybrána a většina požadavků na systém je specifikována. Cílem je vyvinout na závěr každé iterace nový stabilní kód, který implementuje stále více funkcionality. Testování je prováděno během každé iterace, nezáleží na fázi. To znamená, že nová funkcionalita se začíná testovat v průběhu iterace, jakmile je vytvořen kód. Provádí se také testování funkcionality kódu z předchozích iterací. To vyžaduje blízkou spolupráci mezi testery a vývojáři. Chyby a nedostatky objevené během testování jsou zdokumentovány a je vyhodnocena či stanovena jejich priorita. Nejvážnější chyby jsou opraveny okamžitě v dané iteraci. Pokud je potřeba, mohou být chyby s nižší prioritou odsunuty do pozdějších iterací. Cílem každé iterace je vytvoření stabilního spustitelného kódu, který je možné předvést zákazníkovi. Cílem fáze realizace je vytvořit provozuschopný produkt podle specifikace. Neznamená to nutně, že je produkt kompletně dokončen, ale že implementuje všechny klíčové požadavky na systém. Tento produkt můžeme nazvat beta verzí. Některé věci mohou chybět, jako například soubory s nápovědou nebo instalační skripty, ale tato verze může být použita jako pilotní, která umožní získat užitečnou zpětnou vazbu o produktu. Při plánování fáze realizace může být užitečné zahrnout do seznamu iterací navíc jednu nebo dvě „prázdné“ iterace, které jsou umístěny na konci. Tak se vytvoří tzv. nárazníková zóna. Těmto speciálním iteracím je v plánu přiřazen čas, ale nejsou jim přiděleny požadavky. Pokud má zákazník nové požadavky nebo se objeví nějaké problémy, „prázdné“ iterace jsou vhodným místem, kde je možné tyto záležitosti dořešit. Pokud nenastanou okolnosti, které by mohly projekt zbrzdit, je možné systém dodat dříve, než bylo plánováno.

3.5.4 Fáze nasazení (Transition) Ve fázi nasazení zahrnují iterace opravu chyb a jiné záležitosti jako například soubory s nápovědou, instalační skripty, požadavky na vylepšení, konfiguraci a doladění. Také mohou být prováděny jiné významné činnosti jako například přesun dat, pokud nový systém nahrazuje systém starší. Je zajímavé si všimnout, že fáze nasazení může být jednoduchá, ale i komplexní. Záleží to na podstatě produktu. Produkt, který spočívá v jednom systému a obsluhuje ho několik málo expertů nachá-

20

zejících se na jednom místě, je jeden extrém. Druhý extrém je velký distribuovaný systém s tisíci uživateli, jehož chyba může ohrozit lidské životy. Na fázi nasazení takového systému je potřeba naplánovat mnohem více času, než by tomu bylo v prvním případě. V některých situacích je nutné, aby byl systém po nějakou dobu velmi pečlivě monitorován, aby významná část vývojářů a uživatelů byla připravena vyřešit klíčové problémy, které se mohou objevit.

3.6 Součásti metodiky RUP Metodika RUP popisuje kdo, co, jak a kdy dělá. Kdo v procesu vývoje vystupuje, co má vytvořit, jak to má vytvořit a kdy to má vytvořit. Tato příslovce se vztahují ke čtyřem elementům [Gib06]: • • • •

Role (Role) – kdo Aktivita (Activity) – jak Artefakt (Artifact) – co Pracovní proces (Workflow) – kdy

V následujících částech této podkapitoly se zaměříme na první tři základní elementy metodiky (role, aktivita, artefakt). Element pracovní proces je natolik rozsáhlý, ze mu věnujeme samostatnou podkapitolu.

3.6.1 Role Role je v metodice RUP vytvořena za účelem oddělení odpovědnosti za artefakty od konkrétních osob. Role také vykonávají přidělené aktivity. Znamená to, že za příslušné artefakty nejsou přímo odpovědny konkrétní osoby, ale role, v nichž jsou osoby obsazeny. V jedné roli může být obsazena jedna nebo více osob, stejně tak jedna konkrétní osoba může být obsazena ve více rolích. Pokud je v jedné roli obsazeno více osob, je nutné definovat odpovědnost pro každou instanci role, tedy pro každou osobu. Role tedy není konkrétní osoba. Role popisuje chování a odpovědnost. Projektový manažer určuje, které osoby budou mít kterou roli. Role tedy popisuje chování v průběhu procesu vývoje. Chování osob obsazených v roli je definováno jako aktivita, za níž je daná role odpovědná. Do rolí jsou ve vývojovém procesu obsazovány nejen osoby, které jsou součástí vývojového týmu, ale i osoby z vnějšku vývojové organizace, jako například zadavatel projektu nebo uživatel. Základním předpokladem pro obsazení osoby do určité role je znalost technik a metod, které jsou v dané roli používány při vykonávání přidělených aktivit. Termín pracovník (Worker) byl v roce 2001 nahrazen termínem role. Oba dva výrazy lze považovat za synonyma, mají stejnou sémantiku. RUP definuje přes třicet rolí, které se účastní SW vývoje. Role důležité pro malé projekty si popíšeme v kapitole 4.2. Kompletní seznam rolí je uveden v příloze B.

Obrázek 3.3: Příklad rolí

21

3.6.2 Aktivita Termín aktivita je v češtině někdy nahrazován termínem činnost. Oba výrazy mají stejnou sémantiku. Aktivity jsou úkoly, které vykonávají osoby obsazené do definované role a jejichž vstupy a výstupy jsou artefakty. Aktivitu lze považovat za jednotku práce, která může být přidělena dané osobě. Každou aktivitu je možné považovat za část definice chování role. Aktivita má jasně určenou náplň, cíl, vstup a výstup. Může ovlivnit řadu jiných artefaktů. Role může danou aktivitu vykonat v průběhu procesu vývoje pouze jednou, ale také několikrát. V tomto případě se jedná o opakovanou aktivitu. Opakované aktivity jsou zpravidla vykonávány při průchodu jednotlivými iteracemi, kdy je výstupní artefakt vytvářen, upřesňován a modifikován podle zadání a průběhu iterace. Časová náročnost aktivity záleží na její povaze, pohybuje se mezi několika sekundami až mezi několika dny. Každá aktivita je součástí určitého pracovního procesu. Příkladem aktivity může být plánování iterace. Role, která vykonává tuto aktivitu, je nazvána projektový manažer. Vstupem jsou dokumenty relevantní pro plánování, výstupem je dokument s plánem iterace.

Obrázek 3.4: Příklad aktivit programátora v pracovním procesu implementace

3.6.3 Artefakt Artefakt je v metodice RUP klíčový pojem. Představuje ucelenou informaci nebo její část, která je vytvořena, modifikována a používána v procesu vývoje. RUP definuje přes sto artefaktů. Vznikají a jsou používány po celou dobu procesu vývoje, mají přidělenou roli, která za ně odpovídá, a definovaný životní cyklus. Délka životního cyklu různých artefaktů je odlišná. Některé mohou být využity pouze jednou, jiné artefakty jsou používány a modifikovány v každé iteraci. S modifikací je třeba mít na paměti správné verzování. Artefakty se liší i podle významu. Bez některých by se vývoj projektu nedal zvládnout, například bez modelů případů užití. Některé artefakty nemusí být použity vůbec. Artefakty jsou produktem nebo meziproduktem vývoje SW, jsou to vstupy a výstupy aktivit. Nemusí se vždy jednat o dokumenty jako takové, mohou to být různé modely nebo části zdrojového kódu. Pro artefakty typu dokument obsahuje RUP předpřipravené šablony, pro modelování je dodáván nástroj Rational Rose, pro správu požadavků RequisitePro, pro tvorbu dokumentace Rational SoDa. Existují i další nástroje určené přímo pro metodiku RUP, které jsou uvedeny v příloze C. Mnohé z nich lze nahradit jinými dostupnějšími a levnějšími nástroji.

22

Artefakty důležité pro malé projekty si popíšeme v kapitolách 4.2 až 4.6. V příloze A jsou uvedeny i ostatní artefakty z metodiky RUP. Je užitečné se vyvarovat přebujelého vytváření artefaktů, protože může například vzniknout nekonzistence mezi skutečností a některým artefaktem. To může způsobit nemalé komplikace. Artefakty mají být podporou projektu, cílem není maximalizovat jejich množství.

Obrázek 3.5: Příklad artefaktů projektového manažera

3.7 Pracovní proces (workflow) Pouhé vyjmenování všech rolí, aktivit a artefaktů nevytváří proces. Potřebujeme způsob, jakým popíšeme smysluplnou posloupnost aktivit, které mají výstup. Dále bychom měli nějak zachytit interakce mezi rolemi. K tomuto účelu máme tzv. pracovní proces (workflow). Pracovní proces je posloupnost aktivit vykonávaných rolemi, které produkují viditelný výstup. Každý pracovní proces se tedy skládá z několika aktivit (činností). V notaci UML může být pracovní proces (někdy označován jako datový tok) vyjádřen na sekvenčním diagramu, na diagramu spolupráce nebo na diagramu aktivit.

Obr. 3.6: Příklad pracovního procesu

23

Je třeba si uvědomit, že ne vždy je možné nebo praktické zachytit v modelech všechny závislosti mezi aktivitami. Často jsou dvě aktivity provázány více než jak je zachyceno na modelu. Lidé nejsou stroje a pracovní proces nemůže být doslovně interpretován jako jakýsi direktivní program či harmonogram, který byl měl být zpracováván přesně a mechanicky. Pracovní proces odpovídá na otázky začínající slovem „kdy“. V metodice RUP je devět hlavních pracovních procesů, které seskupují všechny role a aktivity do logických skupin. Hlavní pracovní procesy jsou rozděleny na šest hlavních „inženýrských“ pracovních procesů a na tři hlavní „podpůrné“ pracovní procesy. Hlavní „inženýrské“ pracovní procesy: • • • • • •

Obchodní modelování (Business Modeling) Specifikace požadavků (Requirements) Analýza a návrh (Analysis and Design) Implementace (Implementation) Testování (Test) Dodání (Deployment)

Hlavní „podpůrné“ pracovní procesy: • Konfigurační a změnové řízení (Configuration and Change Management) • Projektové řízení (Project Management) • Prostředí (Environment) Ačkoli názvy hlavních „inženýrských“ pracovních procesů mohou připomínat sekvenční fáze v tradičním vodopádovém životním cyklu, měli bychom si uvědomit, že jednotlivé fáze v iteracích jsou rozdílné a pracovní procesy jsou v průběhu životního cyklu stále pozměňovány. Reálné projekty využívají v praxi těchto devět hlavních pracovních procesů, které jsou opakovaně používány s různou intenzitou nasazení v každé iteraci.

3.7.1 Obchodní modelování Jedním z hlavních problémů při vývoji SW je nedokonalá komunikace mezi zákazníkem a dodavatelem. Může to nakonec vést k tomu, že vyvinutý SW bude pro zákazníka nepoužitelný nebo nevyhovující. Pokud SW neslouží ke svému účelu, nic na tom nezmění ani fakt, že je dobře vyvinut. RUP se snaží poskytnout nástroje a procesy oběma stranám tak, aby si navzájem rozuměly. Hlavní snahou je, aby existovala souvislost mezi obchodními a SW modely. V obchodním modelování jsou dokumentovány obchodní procesy. Vzniklé modely jsou srozumitelné jak pro dodavatele, tak pro zákazníka. Zajišťují obecné porozumění mezi zákazníkem a dodavatelem. U mnoha projektů se obchodní modelování vůbec neprovádí. Tato situace nastává zpravidla u jednoduchých a dobře pochopitelných obchodních činností.

24

3.7.2 Specifikace požadavků Cílem specifikace požadavků je popis toho, co má systém dělat. Dále dodavatelům a zákazníkům umožňuje shodnout se na dodávaném systému. Aby toho bylo dosaženo, je potřeba zjistit, utřídit a zdokumentovat požadovanou funkcionalitu a omezení. Je nutné sledovat a dokumentovat dohody a rozhodnutí. Vize je dokument, který zastřešuje specifikaci požadavků. Stručně a výstižně vyjadřuje záměry budoucího systému. Je základním popisem určeným nejen pro úzkou skupinu osob na obou stranách (dodavatel a zákazník), které spolu pracovně komunikují. V rámci specifikace požadavků jsou vytvářeny tzv. modely případů užití. Je třeba zjistit aktéry představující uživatele nebo jiný systém, který s vyvíjeným systémem bude spolupracovat. Případ užití reprezentuje chování systému z hlediska aktérů. Každý případ užití je detailně popsán. Tento popis definuje, jak systém spolupracuje s aktérem a co dělá. Vytvořené modely případů užití jsou dále používány v analýze a návrhu a při testování. Nefunkční požadavky jsou popsány v dodatkové specifikaci (Supplementary Specifications).

3.7.3 Analýza a návrh Cílem analýzy a návrhu je ukázat, jak bude systém realizován v implementační fázi. Výsledný systém by měl vykonávat úkoly a funkce specifikované v modelech případů užití, měl by naplnit specifikované požadavky a měl by být robustní. Analýza a návrh produkuje analytické a návrhové modely. Návrhový model slouží jako abstrakce zdrojového kódu, tzn. návrhový model je plán, jak bude zdrojový kód strukturován a napsán. Návrhový model se skládá z návrhových tříd strukturovaných do návrhových balíčků a subsystémů, které mají dobře definované rozhraní. Dále obsahuje popisy toho, jak objekty návrhových tříd spolupracují. Návrhové činnosti se zaměřují hlavně na architekturu. Tvorba a validace architektury je hlavní náplní počátečních návrhových iterací. Architektura je reprezentována několika architekturními pohledy. Tyto pohledy zachycují hlavní strukturní návrhová rozhodnutí. Lze říci, že architekturní pohledy jsou abstrakcí nebo zjednodušením celého návrhu. V těchto architekturních pohledech jsou důležité vlastnosti vyzdviženy a detaily potlačeny. Architektura je důležitá nejen z hlediska vývoje dobrých návrhových modelů, ale i pro zkvalitnění ostatních modelů používaných během vývoje systému.

3.7.4 Implementace Cílem implementace je definovat uspořádání kódu s ohledem na implementaci subsystémů, které jsou poskládány do vrstev. Dalším cílem je implementovat třídy a objekty s ohledem na komponenty. Výstupem jsou zdrojové kódy, binární kódy, spustitelné kódy aj. Implementace je úzce spojena s testováním. Testují se především komponenty jako stavební jednotky vyvíjeného systému.

25

V závěrečných fázích je nutné, aby byl kód napsaný jednotlivými kodéry nebo týmy integrován do spustitelného systému. Systém je vyvíjen na základě implementace komponent. RUP popisuje, jak znovu použít už existující komponenty nebo jak implementovat nové. Zároveň poskytuje způsob, jak definovat komponenty takovým způsobem, aby následná správa vyvíjeného systému byla jednodušší a aby existovala větší pravděpodobnost, že komponenty budou moci být znovu použity. Výsledné komponenty jsou zkombinovány a tvoří subsystémy. Lze si to například představit jako když stavař kombinuje stavební materiál, z něhož nakonec vzniká část domu.

3.7.5 Testování Účelem testování je verifikace interakcí mezi objekty a ověřování, zda integrace komponent proběhla správně. Prochází se dokument specifikace požadavků a porovnává se, zda systém uspokojuje všechny kladené požadavky a jestli jsou tyto požadavky korektně implementovány. Zjištěné chyby a nedostatky jsou dokumentovány a předány k opravě. Jak už bylo výše zmíněno, RUP používá iterativní přístup při vývoji projektu, což znamená, že testování se provádí během celého životního cyklu projektu. Umožňuje to co nejdříve identifikovat problémy. Tento přístup významně snižuje náklady na vyřešení problému. Testy jsou prováděny ve třech oblastech: spolehlivost, funkcionalita, aplikační a systémová výkonnost. Pro každou z těchto oblastí popisuje RUP životní cyklus testování: plánování, návrh, implementace, provádění a vyhodnocení testů. RUP popisuje strategie, kdy a jak testy automatizovat. Automatizované testy jsou důležité zejména u iterativního přístupu. Umožňují použít regresní testování na konci každé iterace nebo u každé nové verze vyvíjeného systému. Regresní testování znamená, že se testuje už vyvinutý kód v kontextu nově vyvinutého kódu.

3.7.6 Dodání Pracovní proces dodání si klade za cíl úspěšně dodat vyprodukovaný systém koncovým uživatelům. Rozsah činností je různorodý: doladit, distribuovat a instalovat SW, poskytovat podporu uživatelům formou školení, manuálů atd. S tím často souvisí další činnosti: plánování a provádění beta testů, datová migrace, formální odsouhlasení systému zákazníkem. Ačkoli činnosti z procesu dodání jsou většinou prováděny ve fázi nasazení (transition phase), mnoho z těchto činností je nutné zařadit do dřívějších fází. Obvykle se dodání systému připravuje na konci fáze realizace (construction phase). Pracovní procesy dodání a prostředí zpravidla obsahují méně detailů než ostatní pracovní procesy v metodice RUP.

26

3.7.7 Konfigurační a změnové řízení Konfigurační a změnové řízení popisuje, jak řídit velké množství artefaktů, které jsou vytvářeny mnoha lidmi pracujícími na projektu. Řízení napomáhá předcházet nákladným zmatkům a zajišťuje, aby výsledné artefakty nebyly v vzájemném konfliktu. Konflikty mohou pramenit z několika skutečností. Některé z nich si popíšeme. Když dva nebo více lidí pracují odděleně na stejném artefaktu, poslední z nich může udělat změny, které zapříčiní, že bude přemazána práce ostatních lidí. Změnové řízení by mělo systémově ošetřit, aby k této situaci nedocházelo. Další konflikt může pramenit ze změněny nějakého sdíleného artefaktu, například kvůli vyřešení nedostatků daného artefaktu. Lidé, kteří s ním v následujících fázích pracují, nejsou o této změně informováni. Mohou tak pracovat s artefaktem, který už není v dané chvíli aktuální. Změnové řízení musí zajistit, aby příslušní lidé měli o změnách přehled. Většina velkých systémů je vyvíjena ve verzích. Jedna verze může být nasazena u zákazníka, zatímco druhá je testována a třetí je stále ve vývoji. Jestliže je objevena chyba v jedné verzi, je nutné, aby oprava byla provedena u všech tří verzí. Pokud nejsou změny pečlivě kontrolovány a sledovány, může nastat zmatek, který má za následek zvýšené náklady. Může se například stát, že je nutné nečekaně předělat část systému. Konfigurační a změnové řízení je důležité u paralelního vývoje. Zejména se uplatní u iterativního vývoje složitých systémů, kde je prakticky nemožné obejít se bez výkonné automatizace. Do konfiguračního a změnového řízení spadá i řízení změn požadavků, například jakým způsobem oznamovat vady, jak řídit jejich životní cyklus a jak data o chybách analyticky využít pro další vývoj.

3.7.8 Projektové řízení Projektové řízení se vypořádává s protichůdnými cíly, řídí rizika a překonává omezení tak, aby výsledný produkt uspokojil požadavky zákazníka a koncového uživatele. Pod pojmem zákazník máme na mysli zpravidla management společnosti, který si objednal systém a který nakonec za výsledný produkt zaplatí. Skutečnost, že jen málo projektů je úspěšných, je ukazatelem toho, že projektové řízení je náročný pracovní proces. Cílem projektového řízení v metodice RUP je zjednodušit úkoly natolik, nakolik je to jen možné. Metodika RUP poskytuje různé návody k projektovému řízení. Je třeba si uvědomit, že se nejedná o zaručený recept vedoucí k úspěchu, ale o návody, které zpravidla významně zvyšují šance na úspěšný vývoj a následné dodání SW systému. Projektové řízení v metodice RUP zahrnuje: základní rámec pro řízení SW projektu; návody a rady pro plánování projektu, obsazování rolí, denní řízení a kontrolu projektu; rámec pro řízení a správu rizik. Tento pracovní proces ale nepokrývá projektové řízení v celé své šíři. Například se nezabývá personalistikou, správou rozpočtu nebo správou smluv mezi zákazníkem a dodavatelem.

27

3.7.9 Prostředí Pracovní proces prostředí si klade za cíl poskytnout procesy a nástroje potřebné pro práci a podporu vývojářského týmu. Zaměřuje své aktivity na přizpůsobení procesů v rámci projektu. Také se snaží popsat procesy důležité pro podporu projektu. Popisuje přizpůsobení a rozšíření RUP tak, aby vyhovoval danému projektu. RUP je obecná a rozsáhlá metodika vývoje SW. Proto je v mnoha případech nutné, aby byl RUP upraven nebo přizpůsoben na míru projektu. Postup podle metodiky RUP by neměl být slepý. Mohla by tak být vykonávána zbytečná práce nebo by mohly vznikat artefakty, které dále nebudou potřebné. Metodika má být jednoduchá to té míry, do jaké je to jen možné. Tedy tak, aby pomocí ní bylo ještě možné vyvinout podle očekávání vysoce kvalitní SW v přijatelném časovém horizontu.

3.8 Zhodnocení metodiky RUP 3.8.1 Silné stránky Model, na kterém je metodika založena, tj. role, aktivita, artefakt, je snadno pochopitelný a systematický. Z pohledu na každý artefakt se lze dozvědět, jaká role nad ním vykonává jaké činnosti, stejně tak každá role má jasně určeno, jaké činnosti nad jakým artefaktem vykonává a za jaké artefakty je odpovědná. Také je jasně vidět, jaké činnosti jsou s každým artefaktem spojeny. Rovněž přehledné rozdělení procesu na fáze, pracovní procesy a iterace zajišťuje snadnou orientaci a rozdělení životního cyklu vývoje. Metodika RUP vznikla na základě mnohaletých zkušeností předních světových odborníků zabývajících se SW inženýrstvím. Díky tomu vychází z potřeb praxe a plně v sobě implementuje všech šest základních obecných praktik SW vývoje – iterativní vývoj, správu a řízení požadavků, použití komponentové architektury, vizuální modelování, průběžné ověřování kvality a řízení změn. Kromě popisu vývojového procesu je součástí metodiky celá řada doplňkových materiálů ve formě návodů, konceptů a studií, které doporučují, jak co nejlépe provádět aktivity SW vývoje tak, aby to přineslo požadované výsledky v požadované kvalitě. Zejména množstvím a kvalitou podrobných návodů se RUP liší od podobných zpravidla volně dostupných metodik, které z něj vycházejí. Kromě komerčně dodávaných materiálů, které jsou přidány k metodice RUP nebo k jejím nástrojům, poskytuje firma IBM množství nově vzniklých dokumentů, které jsou volně dostupné ve formě tzv. „white papers“. Metodika je jako produkt dodávána ve formě provázaných webových stránek, které lze instalovat buď lokálně, nebo jako součást vnitropodnikové sítě. Tím je zajištěna její dostupnost pro všechny zainteresované zaměstnance. Díky běžnému webovému rozhraní je orientace a procházení metodiky velice snadné, s pomocí integrované funkce vyhledávání lze v metodice jednoduše nalézt požadovanou informaci. Značka Rational a Rational Unified Process je vlastněna společností IBM. Lze předpokládat další rozvoj, rozšíření a podporu metodiky, protože má zajištěno dostatečně silné zázemí.

28

Metodika vznikla evolučním způsobem, vychází z praxe SW vývoje, je podporována silnou globální společností IBM a podporuje jazyk UML. Je používána v SW společnostech po celém světě, což vede k jejímu zdokonalování. Vytváří se tak široká komunita odborníků vyměňujících si názory na problematiku vývoje podle této metodiky.

3.8.2 Slabé stránky Vysoká míra formalizace a rozsáhlost metodiky sice na jedné straně detailně určuje jednotlivé kroky v rámci vývojového procesu, ale na straně druhé nemusí být jejich přesné vykonávání tak přínosné. Ve své základní podobě definuje RUP více jak 30 rolí a více než 100 artefaktů. Jejich výčet je uveden v příloze A (artefakty) a v příloze B (role). Vytváření a udržování takového množství artefaktů v jejich plné šíři vede k nadměrné byrokracii, která je kontraproduktivním a zdržujícím prvkem SW vývoje. V současnosti sice existuje řada konfigurací metodiky pro konkrétní typy projektů ve formě pluginů, ale ani jejich použití neodstraňuje z RUP jeho přílišnou formálnost. Z tohoto důvodu nelze na RUP pohlížet jako na metodiku přesně definující proces SW vývoje, který může být v případě potřeb přizpůsoben. Naopak je nutné metodiku v každém případě přizpůsobit charakteru a potřebám konkrétní organizace a projektu. Nejedná se tedy o možnost přizpůsobení, ale o nutnost přizpůsobení. RUP je metodikou vývoje, tedy pokrývá pouze část životního cyklu vyvíjeného systému. Neřeší provoz, údržbu, další rozšiřování a nakonec i vyřazení z provozu. Tyto nedostatky mohou být odstraněny pomocí vlastních rozšíření. Existuje metodika Enterprise Unified Process, která do RUP přidává fáze provozu a údržby (Production) a vyřazení z provozu (Retirement). Více o této metodice je možné se dočíst v [Buch05]. Metodika RUP nijak neošetřuje vytváření rozpočtu a obchodní vztahy mezi zadavatelem, zhotovitelem a případně subdodavatelem. Z toho důvodu musí být pro tyto činnosti vytvořen postup, který musí být kompatibilní s iterativním vývojem a samotnou metodikou. Možným důvodem, proč nejsou tyto činnosti ošetřeny, může být unikátnost každého obchodního vztahu. RUP také nijak nedefinuje způsob řízení lidských zdrojů, jejich výběr, motivaci, školení a další vzdělávání. Toto lze považovat za nedostatek nebo za přílišné specifikum, pro než nemá smysl definovat postupy. Úzká vazba na nástroje podporující příslušné pracovní procesy je sice jednou z výhod RUP, ale tato vazba je přímo vedena pouze k rodině nástrojů Rational, které jsou prodávány samostatně za vysoké ceny (několik set až několik tisíc dolarů za licenci k jednomu nástroji). Metodika a nástroje nejsou prodávány jako jeden balík. Z obchodního hlediska se jedná o promyšlené jednání, protože pro plné využití RUP je nutné tyto nástroje zakoupit. Vyskytuje se i názor, že existence a propagace metodiky RUP je jen marketingovým nástrojem pro podporu prodeje rodiny nástrojů Rational. V rámci konfigurace metodiky a její implementace do konkrétní organizace lze samozřejmě vytvořit vazbu i na nástroje jiných výrobců. Přehled nástrojů rodiny Rational je uveden v příloze C.

29

4

Konfigurace RUP pro malé projekty

Cílem této kapitoly je poskytnout efektivní konfiguraci metodiky RUP pro malé projekty tak, aby byla použitelná pro úspěšný vývoj aplikací v rámci malého vývojového týmu. Snahou je zejména odstranit zbytečnou „byrokracii“, která je pro metodiku RUP příznačná, a zachovat postupy a meziprodukty nezbytné pro úspěšný vývoj. Z tohoto důvodu definujeme v rámci konfigurace pouze potřebné artefakty, role a činnosti s minimální nezbytnou mírnou formalizace. Je ale nutné si uvědomit, že se nejedná o agilní metodiku vývoje SW, i když s ní má některé rysy společné. Popis vývojového procesu se bude mírně lišit od popisu procesu RUP, zejména z důvodu omezeného rozsahu diplomové práce. Narozdíl od metodiky RUP nebudeme exaktně definovat pracovní procesy a jejich činnosti, ale zaměříme se pouze na jednotlivé činnosti z pohledu rolí a z pohledu artefaktů. Toto zjednodušení by nemělo být překážkou v pochopení podstaty a průběhu vývojového procesu.

4.1 Modifikace principů iterativního vývoje Projekt je řízen podle principů iterativního vývoje metodiky RUP. Některé principy je ale nutné pro potřebu malého projektu modifikovat: Fáze zahájení obsahuje pouze jednu iteraci, v jejímž průběhu neprobíhá implementace ani návazné pracovní procesy. Hlavním výstupem fáze zahájení je vize projektu, jejíž schválení zadavatelem projektu je milníkem této fáze. Fáze projektování obsahuje jednu až dvě iterace. Zatím se neimplementují případy užití, veškerá implementační činnost se zaměřuje na vytvoření stabilního prototypu architektury. Fáze nasazení obsahuje jen jednu iteraci, pokud nedochází ke komplikacím a vše má hladký průběh. V této fázi už neprobíhá implementace. Iterace je vždy formálně zahájena a ukončena projektovým manažerem podle plánu projektu. Akceptační testování a zpracování výsledků dané iterace však probíhají v následující iteraci. Vhodnou délkou každé iterace ve fázi realizace je doba tří týdnů. Délka iterací ale může být přizpůsobována aktuálním potřebám.

4.2 Role Pro malé projekty zpracovávané metodikou RUP jsme vybrali osm klíčových rolí, jejichž charakteristiky si popíšeme v následujících odstavcích. Jedná se o role, nikoli o konkrétní osoby. To znamená, že může nastat situace, kdy dvě osoby budou zastávat stejnou roli. V takovém případě je nutné definovat daným osobám pravomoci a odpovědnost za artefakty a dále určit činnosti, které odpovídají této roli. Také se u malých projektů může stát, že dvě role definované v RUP zastává jedna osoba. V tomto případě není třeba nic upravovat. Jen je nutné dát pozor na to, aby daná osoba ve více rolích nebyla přetížena.

30

Projektový manažer Projektový manažer je zodpovědný za plánování, řízení, organizování a koordinaci celého projektu. Nepůsobí pouze uvnitř projektu, ale je jeho zástupcem navenek a často komunikuje ze zadavatelem projektu (zákazníkem). Kvalitní projektový manažer by měl mít znalosti a zkušenosti s vývojem SW, a to nejen z řídící pozice, ale i z pozice programátora a analytika. U osoby obsazené do role projektového manažera se předpokládá celková orientace v oboru informačních technologií, zkušenosti s obchodním jednáním, analytické a prezentační dovednosti, schopnost rychlé orientace v problémové doméně, schopnost plánování personálních, finančních a kapacitních zdrojů. Pro úspěšné vedení projektu jsou také nezbytné manažerské kompetence jako jsou komunikační schopnosti, rozhodnost, schopnost delegovat, vést a motivovat, přirozená autorita a cílevědomost („tah na branku“). Zadavatel Zadavatel projektu je zákazník. Primárně je to investor projektu, pochází od něj iniciativa projekt zahájit, určuje strategické cíle, kterých by mělo být výsledným produktem dosaženo. Zadavatel se účastní obchodního jednání s obchodním zástupcem SW společnosti a je jednou ze stran smluvního vztahu zastřešující projekt vývoje. Zadavatel rovněž přebírá a akceptuje výstupy každé iterace. Pro zjednodušení situace budeme za zadavatele považovat také budoucí uživatele a správce, ale i další osoby, které budou s budoucím systémem přicházet do styku. V této roli vystupují všechny osoby na straně zákazníka. Pokud to bude pro pochopení nutné, role zadavatele bude specifikována podrobněji. Kvalita výběru osob pro tuto roli má klíčový vliv na kvalitu komunikace, zejména na kvalitu získaných požadavků. Při výběru je velice důležitá rozmanitost osob, tzn. že by v této roli měl být zástupce každé kategorie zainteresovaných osob. Zadavatel by měl být zejména schopen komunikovat a sdělovat své požadavky, potřeby a představy. Analytik Hlavní činností analytika je získávat, porozumět, analyzovat a zaznamenávat požadavky kladené na aplikaci a provádět jejich rozklad do případů užití. Každý případ užití pak analytik podrobně specifikuje. Kromě specifikace jednotlivých případů užití se analytik podílí i na tvorbě architektury aplikace. Nezbytná je častá spolupráce se softwarovým architektem a projektovým manažerem. Mezi další činnosti analytika patří správa změnových požadavků, připomínek, hlášení problémů a správa rizik projektu. Analytik by se měl orientovat ve věcné problémové doméně. Pokud tuto orientaci nemá, měl by být schopen problematiku řešené domény rychle nastudovat a pochopit. Měl by to být extrovertní typ člověka, který má vynikající komunikační a prezentační schopnosti. Měl by být schopen pochopit představy zadavatele, získávat jeho požadavky na systém a ty pak strukturovaně a srozumitelně zaznamenávat. Navíc se předpokládají znalosti různých komunikačních technik (vedení interview, brainstormingů, workshopů apod.) a schopnost sociální empatie. Očekává se u něj schopnost zvolit správ-

31

nou techniku získávání požadavků v závislosti na osobnostním typu zadavatele, časovému prostoru a typu získávaných požadavků. U analytika je rovněž nezbytná znalost problematiky správy požadavků, technik a nástrojů objektově a strukturovaně orientované analýzy a návrhu. Softwarový architekt Softwarový architekt je zodpovědný zejména za softwarovou architekturu aplikace, způsob implementace a dodání. Kromě návrhu architektury aplikace a návrhů realizace případů užití zajišťuje i vývojové nástroje a určuje postupy a standardy používané při implementaci. V jeho kompetenci je v případě potřeby i příprava školení pro vývojáře a administrátorské dokumentace aplikace. Na strukturu znalosti softwarového architekta jsou kladeny vysoké nároky. Měl by mít zkušenosti s programováním a celým procesem vývoje SW, přehled v oblasti CASE nástrojů, znalost problematiky konfiguračního řízení, testování a systémové integrace. Nezbytné jsou znalosti technik objektově orientovaného návrhu a návrhových vzorů. Samozřejmostí je schopnost pochopit všechny požadavky kladené na systém. Test architekt Test architekt je zodpovědný za tvorbu a realizaci testovací strategie a návrhu testů ověřujících kvalitu vyvíjené aplikace. Test architekt by měl mít znalosti problematiky a metodik testování, testovacích nástrojů a technologií, návrhu a vyhodnocování metrik. Téměř nutností jsou zkušenosti s programováním. Procesní inženýr Procesní inženýr je specialista na iterativní proces vývoje SW podle metodiky RUP. Je to role, která se zabývá konfigurací procesu vývoje vzhledem ke specifikům každého projektu. Z tohoto důvodu se tato role nejintenzivněji uplatňuje na začátku projektu ve fázi zahájení. Procesní inženýr zpravidla působí externě jako konzultant, část jeho aktivit může převzít projektový manažer. Procesní inženýr připravuje školení, seznamuje všechny účastníky projektu s aktuální konfigurací procesu a s obecnými aspekty iterativního vývoje a dále pomáhá projektovému manažerovi v prvotním hrubém naplánování projektu. Osoba obsazená do role procesního inženýra by měla mít bohaté zkušenosti s celým životním cyklem vývoje SW, zejména pak s projekty řízenými podle některé iterativní metodiky, nejlépe přímo podle metodiky RUP. Vhodné je mít zkušenosti z práce v některé z řídících pozic. Mezi další důležité vlastnosti patří komunikační a prezentační schopnosti, schopnost rychle se učit a na základě nových poznatků i rozhodovat. U velmi malých projektů se může stát, že roli procesního inženýra a projektového manažera zastává jedna osoba.

32

Návrhář GUI Návrhář GUI vytváří vizuální komponenty a grafický design aplikace. Člověk v této roli by měl mít zejména grafické cítění a znalost problematiky grafického designu aplikací a grafické ergonomie. Programátor Osoba obsazená v roli programátora je zodpovědná za implementaci případů užití a SW komponent podle jejich návrhu a pravidel stanovených v architektuře. Kromě toho programátor ke každému případu užití implementuje, spouští a vyhodnocuje jednotkové testy. Osoba obsazená do role programátora musí mít znalosti programování v jazyce, v němž bude aplikace vyvíjena. Předpokládá se i znalost souvisejících technologií nebo alespoň schopnost nové technologie rychle vstřebat. Kromě toho jsou nutné znalosti z oblasti testování, jazyka UML a orientace v objektovém návrhu aplikací.

Obrázek 4.1: Organizační struktura rolí

4.3 Fáze zahájení Cílem fáze zahájení je získat a analyzovat co nejvíce požadavků na systém. Zejména je důležité se zaměřit na nejrizikovější požadavky. Obecně jsou požadavky získávány na základě interview se zadavatelem projektu. Ve fázi zahájení je vypracován hrubý plán projektu a dále zpřesněný plán iterací pro fázi projektování. Pro její první iteraci je zpracován detailní plán. Fáze zahájení obsahuje jednu iteraci, jejímž milníkem je schválená vize projektu.

33

Artefakty a činnosti Plán projektu (projektový manažer) Cílem artefaktu je zachytit hrubý plán pro celý projekt, který je spolu s postupem projektu neustále zpřesňován. Kromě toho artefakt slouží jako přehled o aktuálním stavu projektu, shrnuje a hodnotí jeho uskutečněnou část. Na vytvoření plánu projektu se kromě projektového manažera podílí i zadavatel, spolu s ním jsou definovány hlavní milníky projektu a jejich akceptační kritéria. Na základě tohoto artefaktu by mělo být všem členům vývojového týmu i zadavateli zřejmé, v jakém stavu se projekt nachází a jak je plánován jeho další postup. Součástí plánu projektu je i zpřesněný plán aktuální a příští fáze a podrobný plán aktuální a příští iterace. Plán fáze detailně popisuje cíle fáze, akceptační kritéria milníku, termíny, zdroje a počet iterací spolu s jejich věcnou náplní a kritérii. V plánu aktuální a příští iterace jsou detailně určeny činnosti a jejich věcný obsah, artefakty, zdroje a kritéria úspěchu daných iterací. Činnosti projektového manažera v souvislosti s artefaktem plán projektu jsou následující: plánování fáze zahájení a přepokládané délky projektu; stanovení úkolů a cílů aktuální fáze; sestavení hrubého plánu fází projektu včetně jejich obsahu a rizik; definování milníků fází projektu a akceptačních kritérií; stanovení časového a věcného rozsahu a plánování dalších fází a alokování potřebných zdrojů; zhodnocení rizik další fáze; detailní stanovení rozsahu, činností, cílů, artefaktů, odpovědností a kritérií úspěchu pro další iterace; porovnávání plánu fáze zahájení s jejím skutečným průběhem; hodnocení průběhu fáze, dosažení milníků a spokojenosti zadavatele s dosavadním průběhem projektu; každodenní řízení projektu. Vývojový proces a školení (projektový manažer, procesní inženýr) Cílem artefaktu je formálně definovat vývojový proces, jeho artefakty, role, aktivity a ostatní aspekty. Vývojový proces představuje implementaci a úpravu metodiky RUP pro konkrétní projekt. Artefakt obsahuje i školení ohledně vývojového procesu, kterým by měla projít každá osoba pracující na projektu řízeném podle metodiky RUP. Artefakt vytváří a upravuje procesní inženýr spolu s projektovým manažerem. V praxi se u velmi malých projektů může stát, že role procesního inženýra a projektového manažera splynou v jednu, tedy bude je zastávat jedna osoba. Akceptační protokol (projektový manažer) Akceptační protokol obsahuje záznam o akceptaci výstupu každé iterace zadavatelem. Před vlastní akceptací obsahuje seznam známých chyb a nedostatků, které mají být v aktuální iteraci opraveny nebo zapracovány do projektu. V případě potřeby obsahuje i specifikaci akceptačních kritérií. V iteracích, kde probíhá akceptační testování buildu, obsahuje protokol po akceptaci seznam všech chyb a změnových požadavků objevených zadavatelem v rámci akceptačního testování. Taková chyba nebo nedostatek vstupuje ve formě hlášení problému nebo schváleného změnového požadavku do některé z dalších iterací.

34

Dopad a závažnost změnových požadavků musí být ohodnoceny projektovým manažerem, často i ve spolupráci s analytikem. Následně jsou změnové požadavky zaneseny do změnového řízení. Zpravidla to znamená, že jsou zapracovány do artefaktu požadavek na změnu. Na základě hodnocení v akceptačním protokolu lze vyhodnocovat úspěšnost celého projektu. Z akceptačního protokolu musí být na první pohled zřejmý stupeň spokojenosti zadavatele s výstupem dané iterace. Artefakt je vytvořen na konci fáze zahájení, tato fáze obsahuje jen jednu iteraci. Dále je aktualizován na konci každé iterace. Na konci projektu je tak vytvořena sada akceptačních protokolů. Vize (analytik) Hlavním obsahem artefaktu vize je definice cílů z pohledu zadavatele, kterých má být dosaženo, a definice rozsahu systému (definice hranic funkcionality a odpovědnosti aplikace). Artefakt by měl zajistit konzistenci očekávaných cílů a jejich pochopení všemi zainteresovanými osobami. Ve vizi je zachycen souhrn klíčových požadavků na vysokém stupni abstrakce. Kromě textového popisu požadavků je nanejvýš vhodné požadavky zachytit i pomocí grafické notace, zvyšuje to přehlednost a čtenáři to zjednodušuje pochopení vize. Vzhledem ke skutečnosti, že vize je prezentována zadavatelům systému, musí být její obsah a forma srozumitelná i těmto osobám. Vize schválená zadavatelem je milníkem fáze zahájení. Vize je vytvořena ve fázi zahájení a v případě získání nových klíčových požadavků je aktualizována i v následujících fázích projektu. V případě aktualizace je nutné její opětovné schválení. U malých projektů vedou pozdější změny v artefaktu vize zpravidla k velkým komplikacím. Je značně nabourán časový harmonogram, je nutné zrevidovat alokaci zdrojů. Proto je velmi důležité, aby artefaktu vize byla věnována zvýšená pozornost i za cenu toho, že bude vytvářen o nějakou dobu déle. Je nutné si se zadavatelem přesně vyjasnit cíle a ověřit, zda to, co požaduje, opravdu potřebuje. Změna vize v průběhu projektu je zpravidla chybou analytika ve fázi zahájení. Specifikace požadavků (analytik) Cílem artefaktu je zachytit všechny od zadavatele získané požadavky na systém. Jedná se o klíčový artefakt, na jehož základě pak vznikají další artefakty a plánování celého procesu vývoje. Součástí artefaktu specifikace požadavků je i vize a modely případů užití. Vize a specifikace požadavků se mohou svým obsahem překrývat. Narozdíl od vize však specifikace požadavků není určena pro prezentaci vně projektu, slouží pouze pro interní účely. Podrobnost popisu jednotlivých požadavků se liší podle fáze projektu a podle jejich významu. Na konci fáze zahájení je zpravidla podrobně popsána nejméně polovina vstupních požadavků s nejvyšším koeficientem rizika a priority. Na konci fáze projektování by měly být podrobně popsány i všechny zbývající vstupní požadavky. Kromě vstupních požadavků jsou součástí artefaktu i změnové a chybové požadavky (hlášení problému).

35

Každý nový funkční požadavek by měl mít alespoň následující atributy: identifikátor, název, osoba v roli zadavatele, popis, koeficient priority, koeficient rizika, stav zapracování do modelu případu užití. Modely případů užití (analytik) Model případů užití obsahuje seznam identifikovaných případů užití, jejich aktérů a podrobný popis. Kromě textového popisu obsahuje i grafické vyjádření případů užití v notaci UML a podrobnou specifikaci každého případu užití. Je vhodné mít k případům užití vytvořeno grafické uživatelské rozhraní. Jednotlivé případy užití jsou identifikovány na základě funkčních požadavků. Důsledná identifikace případů užití je předpokladem k úspěchu projektu, protože jednotlivé případy užití zpravidla procházejí procesem vývoje jako nedělitelné celky. Na základě případů užití je plánován projekt vývoje a jeho jednotlivé aktivity. Artefakt je vytvořen na začátku fáze zahájení, kdy obsahuje seznam prozatím známých případů užití. Na základě analýzy je v průběhu fáze zahájení k jednotlivým případům užití přidán i jejich podrobnější popis (specifikace případu užití). Prioritně jsou zpracovávány případy užití s nejvyšším součinem koeficientů priority a rizika. V průběhu dalších fází je artefakt doplňován o nově identifikované případy užití a už identifikované případy užití jsou podrobně specifikovány. K vytvoření modelů případu užití musí analytik provést následující úkoly: identifikovat případy užití, jejich aktéry a vztahy; přiřadit případům užití priority; ohodnotit rizikovost a technickou složitost případů užití; graficky namodelovat případy užití pomocí UML; podrobně specifikovat případy užití. Rizika (analytik) Artefakt rizika obsahuje seznam všech známých rizik projektu. Na jeho základě jsou pak rizika projektu řízena tak, aby se v případě jejich projevení minimalizoval negativní dopad na projekt. Celý projekt je plánován tak, aby byla všechna rizika postupně a co nejdříve (od nejzávažnějších po nejméně závažné) eliminována či přijata. Artefakt rizika je vytvořen na začátku projektu a dále je aktualizován v průběhu všech fází. Rizika je možné pro jejich snazší analýzu a lepší přehlednost rozdělit do kategorií podle typu: technologická, obchodní, vnější. Technologické riziko plyne z nestability nebo z neznalosti technologií použitých při vývoji systému. Důvodů pro použití těchto technologií může být celá řada, od požadavku zákazníka, který si přeje použít danou technologii, až po výhodnost dané technologie při řešení dané problematiky. Obchodní rizika plynou hlavně z neznalosti zhotovitele sytému, zejména z neznalosti problémové domény zákazníka nebo ze složitosti jejího pochopení. Pro dobře provedenou analýzu je dokonalá znalost problémové domény klíčovým faktorem. Vnější rizika nelze ovlivnit v rámci projektu. Jako příklad lze uvést změnu legislativy, která má dopad na projekt, nebo špatnou finanční situaci zadavatele projektu.

36

U každého rizika by měly být zaznamenány minimálně následující informace: identifikátor, název, popis, závažnost, dopad na projekt v případě projevu rizika, příčiny rizika, způsob monitoringu, způsob eliminace či přijetí, krizový plán v případě projevu rizika, stav rizika. Slovník pojmů projektu (analytik) Slovník pojmů projektu obsahuje důležité pojmy týkající se řešené problémové domény projektu a jejich popis. Účelem dokumentu je jasně specifikovat důležité pojmy tak, aby se předešlo nedorozumění ohledně věcného obsahu pojmu, a to jak uvnitř vývojového týmu, tak mezi ním a zadavatelem. Je důležité popisovat i „naprosto jasné“ pojmy, často i ony mají pro zainteresované osoby různý význam. Artefakt je vytvořen na začátku fáze zahájení, v dalších fázích je doplňován a udržován v aktuálním stavu. Architektura (softwarový architekt) Architektura je popis a způsob uspořádání komponent systému a rozhraní, pomocí nichž komponenty navzájem komunikují. V průběhu životního cyklu projektu se vytváří mnoho modelů. Ty jsou uceleným znázorněním systému, zatímco architektura se soustředí pouze na prvky architektonicky významné. Tyto prvky ovlivňují strukturu systému, jeho robustnost, výkon, pružnost a rozšiřitelnost. Jsou znázorňovány modelem 4+1, který obsahuje pět pohledů na architekturu: logický, implementační, procesní, pohled nasazení a případy užití. Logický pohled znázorňuje strukturu systému z hlediska výsledné funkcionality. Jedná se o abstraktní model návrhu, který popisuje hlavní moduly, subsystémy a třídy. Hlavním prostředkem je diagram tříd znázorňující objektové třídy a vztahy mezi nimi a diagram objektů popisující vztahy mezi konkrétními instancemi jednotlivých tříd [Ald05]. Implementační pohled zachycuje systém z pohledu organizace statických SW komponent (exe, dll, html). Znázorňuje rozčlenění sytému do jednotlivých modulů. Hlavním prostředkem tohoto pohledu je diagram komponent [Ald05]. Procesní pohled zachycuje sytém jako množinu navzájem komunikujících procesů. Řeší otázku konkurence a paralelismu procesů. Modelování procesů a komunikace mezi jimi se provádí pomocí procesního diagramu [Ald05]. Pohled nasazení definuje návaznost spustitelných programů a ostatních komponent. Zaměřuje se na topologii HW a dalších SW komponent. Typickým formálním prostředkem je diagram nasazení [Ald05]. Případy užití představují pohled na systém z hlediska jeho funkcionality pro koncového uživatele. Tento pohled je jádrem architektury systému, zbývající pohledy zajišťují realizaci zde specifikovaných požadavků. Základním prostředkem tohoto pohledu je model případů užití [Ald05]. Architektura určuje technologie, nástroje a frameworky, se kterými bude daný systém vyvíjen. Stejně tak definuje přístupy a pravidla používané při implementaci. Součástí architektury je i definice potřebného běhového a databázového prostředí, plán nasazení a instalace produktu.

37

Architektura je rozvíjena především ve fázi projektování. Ve fázi zahájení je zaměřena na následující úkoly: určení technologií, na nichž bude systém založen; určení vývojových a jiných podpůrných CASE nástrojů, které budou v projektu použity; základní členění aplikace. Testovací strategie (test architekt) Testovací strategie určuje přístupy k testování. Stanovuje, které artefakty vývojového procesu budou v jeho průběhu testovány a jak se bude nakládat s výsledky testů. Dále určuje metriky, podle nichž budou testy vyhodnocovány. Od testovací strategie se v dalším průběhu projektu odvíjí návrh jednotlivých testů a celý přístup k testování. Při vypracovávání testovací strategie spolupracuje test architekt s analytikem a softwarovým architektem. Testovací strategie je rozvíjena od začátku projektu, největší pracovní úsilí je vyvinuto ve fázi projektování.

4.4 Fáze projektování Cílem fáze projektování je eliminovat nejzávažnější rizika, která byla identifikována ve fázi zahájení, a podrobně specifikovat všechny známé požadavky a případy užití. Narozdíl od fáze zahájení probíhá v této fázi návrh a implementace architektonického jádra aplikace. V této fázi nejsou implementovány žádné případy užití. Výstupem iterací jsou modely případů užití a prototyp GUI, které jsou prezentovány zadavateli. Fáze obsahuje zpravidla jednu až dvě iterace. Milníkem je zadavatelem schválený a připomínkovaný prototyp uživatelského rozhraní. Dalším artefaktem milníku je prototyp architektury, která eliminuje nejzávažnější známá technologická a jiná rizika. Přesný počet a délka iterací závisí na zkušenostech pracovníků projektu s danými technologiemi a problémovou oblastí. Po skončení fáze projektování by měl být už detailně určen další harmonogram prací na projektu včetně předpokládaného data nasazení aplikace do produkčního prostředí.

Artefakty a činnosti Všechny artefakty vzniklé v předešlé fázi jsou podle potřeby aktualizovány. Potřeba aktualizace plyne z průběhu projektu, znalosti nových požadavků a z výsledků jejich analýzy. Kromě toho vznikají nové artefakty, které jsou výsledkem implementace a testování. Plán projektu (projektový manažer) Na začátku fáze projektování obsahuje artefakt zpřesněný plán této fáze včetně podrobného plánu pro první iteraci. V průběhu fáze projektování jsou pravidelně plánovány následující iterace, aktuální iterace jsou řízeny a hodnoceny. Před ukončením fáze projektování je zpřesněn plán zbývajících fází projektu. Možnost zpřesnit plán zbývajících fází plyne z faktu, že na konci fáze projektování existuje

38

stabilní architektura a rozsah systému. Při plánování fáze realizace se doporučuje naplánovat minimálně dvě iterace, které mimo jiné umožní stabilizaci řešení. Akceptační protokol (projektový manažer) Akceptační protokol je aktualizován na konci každé iterace. Je zde zaznamenáváno hodnocení zadavatele a případné připomínky a nedostatky. Vize (analytik) Artefakt vize je aktualizován pouze v případě nových klíčových požadavků. Případná aktualizace vize si vyžádá přeplánování zbývajících částí projektu. U dobře zpracované vize z fáze zahájení by nemělo docházet k aktualizacím. Specifikace požadavků (analytik) Ve fázi projektování stále přicházejí nové požadavky a stávající požadavky jsou upřesňovány. Kromě toho do artefaktu přibývají hlášení problémů a změnové požadavky na základě akceptačního protokolu. Modely případů užití (analytik) Model případů užití je ve fázi projektování aktualizován na základě nově získaných a upřesněných požadavků. Je doplněna specifikace případů užití analyzovaných v předešlé fázi tak, aby byly nachystány pro implementaci. V průběhu fáze projektování jsou přidávány nové případy užití, které s sebou přinášejí novou funkcionalitu. Také dochází k úpravám případů užití, například přezkoumání stereotypů extend nebo include. Na konci fáze projektování by měla být u malých projektů všechna nebo alespoň většina případů užití namodelována a specifikována. Je doporučeno nechat si na konci fáze projektování od zadavatele schválit specifikaci případů užití. Záleží na složitosti modelů a schopnosti zadavatele těmto modelům porozumět. Ale obecně platí, že tyto modely by neměly být zbytečně složité, právě naopak by měly být po krátkém zaškolení čitelné i pro zadavatele, resp. pro vedoucí osobu v roli zadavatele. Rizika (analytik) Činnosti spojené s artefaktem jsou totožné s činnostmi z fáze zahájení, jedná se o rozšíření a úpravu obsahu tohoto artefaktu. Slovník pojmů projektu (analytik) Činnosti spojené s artefaktem jsou totožné s činnostmi z fáze zahájení, jedná se o rozšíření a úpravu obsahu tohoto artefaktu.

39

Architektura (softwarový architekt) Ve fázi projektování je artefakt rozpracován do potřebného stupně detailnosti tak, aby už nemusel být v dalších fázích výrazně upřesňován a měněn. Cílem této fáze je vytvořit stabilní architekturu. Na jejím základě je postavena celá aplikace a je jí ovlivněn způsob implementace jednotlivých případů užití, proto je její dokončení prioritou fáze projektování. Na vytvoření obsahu artefaktu se spolu se softwarovým architektem podílí i analytik. U malých projektů se může stát, že tyto dvě role splynou a zastává je jedna osoba. Architektura a její prototyp jsou součástí milníku fáze projektování. Testovací strategie (test architekt) V průběhu fáze projektování je dopracována testovací strategie tak, aby podle ní bylo možné v dalších fázích úspěšně zjišťovat kvalitu všech testovaných artefaktů a celého produktu. Obsah testovací strategie je výrazně ovlivněn architekturou systému. Při kompletaci testovací strategie spolupracuje test architekt s analytikem a softwarovým architektem. Prototyp architektury (programátor) Artefakt představuje implementaci architektonického jádra aplikace. Prototyp architektury by měl řešit rizika, která byla ve fázi projektování stanovena k eliminaci. Důležité je otestování prototypu výkonnostními testy. Prototyp architektury je na konci fáze prezentován zadavateli. U malých projektů implementuje prototyp architektury zpravidla jednoduché funkce a je z něj patrné, jak budou vypadat i ostatní funkce. Lze to přirovnat k hrubé stavbě domu, kdy je možné rozpoznat základní rysy a domyslet si, jak asi bude dům vypadat, až bude kompletně dostavěn. Návrh GUI (návrhář GUI) Artefakt představuje ucelený grafický návrh pro celou aplikaci. Na základě v něm definovaných pravidel budou vyvíjeny vizuální komponenty aplikace. Artefakt je tedy jejím grafickým manuálem. Je vhodné sestavit několik variant návrhu a tyto varianty předložit zadavateli, aby si zvolil tu, která bude dále podle potřeby rozvíjena. Součástí artefaktu je i prototyp GUI, který představuje detailní návrh několika obrazovek, nejlépe klíčových případů užití. Z prototypu by měl být patrný způsob navigace mezi obrazovkami a umístění vizuálních a navigačních prvků. Prototyp musí mít „hmatatelnou podobu“, může se jednat o vytištěné obrazovky nebo o implementaci bez požadované funkcionality. Návrh GUI je součástí milníku fáze projektování a je v průběhu této fáze předložen zadavateli ke schválení. V průběhu dalších fází se nepředpokládá další výrazný rozvoj artefaktu, je aktualizován na základě připomínek a změnových požadavků. U malých projektů je někdy možné zkombinovat návrh GUI a prototyp architektury. V tomto případě se jedná o nejlepší řešení pro zadavatele. Vznikne spustitelná verze systému (build), která bude mít požadované grafické rozhraní a bude implementovat základní funkcionalitu. Zadavatel si může systém vyzkoušet a jelikož má v průběhu projektu „hmatatelný“ výsledek, zpravidla je spokojen.

40

Testovací protokol (analytik) Artefakt obsahuje výsledky výkonového testování a seznam chyb, které byly objeveny při interním funkčním a integračním testování buildu systému. Podkladem pro funkční testování je specifikace případů užití obsažená v modelu případu užití a testovací strategie. Podkladem pro výkonové a integrační testování je kromě testovací strategie i architektura. Objevené chyby a funkční nedostatky odhalené při testování vstupují později do požadavků jako hlášení problémů a jsou opraveny v aktuální nebo v některé následující iteraci. Součástí dokumentace každé odhalené chyby musí být popis podmínek, při nichž vznikla, stejně jako ohodnocení její závažnosti a požadovaná priorita opravy.

4.5 Fáze realizace Průběh fáze realizace by měl být takřka rutinní záležitostí, pokud byly kvalitně zpracovány předchozí fáze. Jejím cílem je výroba konečného produktu. Ve fázi realizace je už známa naprostá většina požadavků na systém a případy užití, a tak probíhá dolaďování analýzy a návrhu, ale hlavně implementace a testování. Po každé iteraci je build systému prezentován zadavateli projektu, který ho následně testuje. Poskytuje tak zpětnou vazbu a další upřesňující a změnové požadavky. Z hlediska řízení projektu probíhá plánování, řízení iterací a zpřesňování plánu pro zbývající část projektu. Ve fázi realizace se také vytváří artefakty týkající se nasazení aplikace do produkčního prostředí zákazníka a artefakty související se školením a dokumentací. Lze předpokládat, že pokud nepřijde nový klíčový nebo změnový požadavek a pokud byl projekt kvalitně naplánován, bude možné ukončit fázi s naplánovaným počtem iterací. V případě příchodu a přijetí zásadního požadavku je nutné zbývající část projektu výrazněji přeplánovat. Tato situace by neměla nastat, pokud je kvalitně provedena práce analytika. Je vhodné si pro fázi realizace naplánovat navíc jednu iteraci, která na začátku nebude mít přiděleny žádné úkoly. Je to „nárazník“, kam se přesouvají nalezené chyby a nedodělky, jež se nestihnou vyřešit v plánované iteraci. Pokud vše probíhá podle plánu, je možné tuto iteraci zrušit, a tím zkrátit celkovou dobu projektu. V tomto případě bude zadavatel jistě rád, když projekt skončí dříve, než bylo plánováno. Naopak pokud by se měl projekt opozdit, zadavatel určitě projeví svou nespokojenost. Proto je velmi moudré tuto jednu „nárazníkovou“ iteraci, která se zdá na první pohled zbytečná, zahrnout do plánu projektu. Milníkem fáze realizace je build aplikace splňující všechny specifikované požadavky.

Artefakty a činnosti Všechny artefakty vzniklé v předešlé fázi jsou podle potřeby aktualizovány. Potřeba aktualizace plyne z průběhu projektu, znalosti nových požadavků a z výsledků jejich analýzy. Kromě toho vznikají nové artefakty související s implementací a s nasazením systému do produkčního prostředí zákazníka.

41

Plán projektu (projektový manažer) Ve fázi realizace obsahuje plán projektu naplánované iterace a harmonogram zbývajících fází projektu. Na základě průběhu projektu jsou řízeny a vyhodnocovány aktuální iterace, jsou plánovány následující iterace. Akceptační protokol (projektový manažer) Artefakt je v každé iteraci doplňován připomínkami zadavatele. Dále obsahuje hodnocení výstupů. Vize (analytik) Artefakt je aktualizován pouze v případě nových nebo změnových klíčových požadavků. Jeho případná aktualizace si vyžádá změnové řízení a přeplánování projektu. Ke změně vize by v této fázi nemělo docházet. Specifikace požadavků (analytik) Ve fázi realizace přichází zejména upřesňující požadavky, změnové požadavky a hlášení problémů. Tyto požadavky jsou získávány na základě testovacího a akceptačního protokolu. V případě příchodu zcela nových požadavků může být nezbytné přeplánování projektu, stejně jako při přijetí zásadního změnového požadavku, který prošel změnovým řízením. Modely případů užití (analytik) V průběhu fáze realizace je artefakt plně zkompletován a dále případně modifikován podle změnových požadavků. Je doporučeno schválení plně specifikovaných případů užití zadavatelem. Rizika (analytik) Činnosti spojené s tímto artefaktem jsou stejné jako v předchozích dvou fázích, jedná se o rozšíření a úpravu jeho obsahu. Architektura (softwarový architekt) Architektura systému by měla být ve fázi realizace dostatečně stabilní a neměla by být výrazněji upravována. V případě potřeby výrazné úpravy architektury muže být nezbytný redesign a reimplementace všech komponent, a tudíž i přeplánování celého projektu. V takovém případě se zřejmě jedná o špatnou práci analytika. Softwarový architekt určuje způsob nasazení do produkčního prostředí a nasazuje, případně udržuje produkční běhové a databázové prostředí.

42

Testovací strategie (test architekt) Testovací strategie by ve fázi realizace už neměla být dále rozvíjena, možné jsou její dílčí úpravy podle aktuálního průběhu projektu a testování. Testovací protokol (analytik) Testovací protokol obsahuje ve fázi realizace kromě výsledků výkonových testů i výsledky funkčních a integračních testů. Tyto výsledky jsou v každé iteraci analyzovány a po zpracování případně vstupují do specifikace požadavků. Návrh GUI (návrhář GUI) Ve fázi realizace jsou na základě artefaktu vytvářeny grafické komponenty pro jednotlivé případy užití. U malých a specifických projektů je možné vytvořit GUI už ve fázi projektování. Implementovaný případ užití (programátor) Artefakt implementovaný případ užití je zdrojovým kódem realizujícím konkrétní případ užití. V průběhu projektu vzniká mnoho jeho instancí (verzí). Artefakt implementace případu užití může být rozložen v několika souborech, může se jednat o databázové tabulky, třídy, rozhraní, konfigurační a jiné soubory. Instance artefaktu jsou agregovány do komponent tak, jak je definováno členění systému v architektuře. Nedílnou součástí artefaktu jsou komentáře zdrojového kódu a jednotkové testy ověřující základní a alternativní tok případů užití. Instance artefaktu jsou uloženy v pracovním prostoru programátora, případně v systému zajišťujícím automatickou správu verzí, např. CVS (Concurrent Version Control System), Subversion nebo Rational ClearCase. Build (softwarový architekt) Build představuje spustitelnou instanci aplikace. Jsou v něm obsaženy všechny dosud implementované a pro běh systému potřebné komponenty. Zhotovený build je testován akceptačními, výkonnostními a integračními testy. Po vytvoření je build nasazen do testovacího běhového prostředí. V posledních iteracích fáze realizace je build nasazován do beta testovacího provozu do produkčního prostředí. Build je vytvářen před koncem každé iterace, v níž probíhala implementace. V případě potřeby je možné tento artefakt vytvářet častěji. Informace o buildu (projektový manažer) Informace o buildu je souhrn známých chyb, nedostatků a změn v porovnání s předchozím buildem. Artefakt je vytvářen ke každému buildu, ten je následně testován akceptačními testy, které se přidávají k tomuto artefaktu.

43

Testovací sada (programátor) Testovací sada je soubor jednotkových testů sestavovaných pro každou komponentu na základě testovací strategie. Do tohoto souboru jsou přidávány testy jednotlivých případů užití spadající do dané komponenty. Díky testovací sadě lze otestovat všechny případy užití implementované v jedné komponentě. Požadavek na změnu (projektový manažer) Artefakt obsahuje změnový požadavek, jehož přijetí by si vyžádalo přeplánování projektu. Je třeba si uvědomit, že se jedná o požadavky, které byly rozpoznány až po uzavření specifikace požadavků nebo které se týkají už uzavřené vize. Na základě tohoto artefaktu provádí projektový manažer spolu se zadavatelem a případně i s dalšími rolemi změnové řízení. Artefakt je vytvořen až ve fázi realizace z toho důvodu, že do jejího začátku není závazně stanoven přesný harmonogram zbývajících fází projektu, a tak není nutné příliš formalizované přijetí změny. Související změnové požadavky mohou být obsaženy ve stejné instanci artefaktu, jinak je vhodné pro každý změnový požadavek vytvořit samostatnou instanci a provést samostatné změnové řízení. Dokumentace (analytik) Artefakt obsahuje uživatelskou a administrátorskou dokumentaci systému. Administrátorská dokumentace musí poskytovat návody, jak úspěšně provozovat systém, protože ten bude zpravidla užíván jiným subjektem než je zhotovitel systému. V případě potřeby školení uživatelů nebo administrátorů obsahuje artefakt i potřebné školící materiály. Uživatelská dokumentace je vytvářena v průběhu fáze realizace na základě dokumentovaných případů užití. Administrátorská dokumentace musí být vytvořena před prvním nasazením aplikace do produkčního prostředí.

4.6 Fáze nasazení Cílem fáze nasazení je úspěšně předat a zprovoznit kompletní systém v produkčním prostředí včetně předání kompletní dokumentace a případného zaškolení uživatelů a administrátorů. V této fázi probíhá poslední akceptační testování konečného produktu. V případě pozitivních výsledků testů může být celý proces vývoje zakončen. V případě negativních výsledků bude potřeba přidat iteraci na odstranění překážek akceptace, pokud není naplánována „nárazníková“ iterace nebo pokud už je vyčerpána. Předpokládá se jediná iterace, jejímž milníkem je zprovoznění systému a ukončení projektu vývoje. V průběhu fáze by neměly nastat významné komplikace s nasazením systému do produkčního prostředí, protože nasazení mělo být otestováno v průběhu závěrečných iterací fáze realizace. V praxi se stává, že pokud ve fázi realizace dojde k problémům, které si vyžádají neplánované zdroje (zejména čas), nastává tendence k urychlení testů, aby se dohnala časová ztráta. Uspěchané testování zpravidla neodkryje všechny chyby, které by byly za normálních okolností odhaleny, a potom dochází k problémům ve fázi nasazení.

44

Pokud by v průběhu fáze nasazení přišel nový nebo změnový požadavek, který by měl vliv na její průběh, musí být vždy zahájeno změnové řízení. V případě přijetí změnového požadavku bude projekt navrácen do fáze realizace.

Artefakty a činnosti Většina artefaktů z předešlých fází projektu už není zpravidla aktualizována. V následujícím textu popíšeme artefakty, u nichž dochází k plánované aktualizaci, a artefakty nové. Plán projektu (projektový manažer) Ve fázi nasazení je v případě bezproblémového nasazení systému projekt naposledy vyhodnocen. V případě nutnosti přidání iterace je tato iterace podrobně naplánována. Akceptační protokol (projektový manažer) Akceptační protokol obsahuje výsledky posledních akceptačních testů a výsledky beta testování. Ve fázi nasazení by už neměl obsahovat žádné významné připomínky, jejichž vyřešení by vyžadovalo nasazení velkého úsilí. V opačném případě je nutné naplánovat novou iteraci a tyto nedostatky odstranit. Build (softwarový architekt) Ve fázi nasazení je build distribuován zákazníkovi a naposledy akceptačně testován. Dokumentace (analytik) Ve fázi nasazení probíhají finální korekce dokumentace, školení uživatelů a administrátorů. Informace o buildu (projektový manažer) Ve fázi nasazení je naposledy vytvořen artefakt informace o buildu. Vývojový proces (projektový manažer, procesní manažer) Celý vývojový proces je zhodnocen, případně je upravena jeho konfigurace na základě analýzy post mortem. Slouží jako podklad pro další projekty obdobného typu. Implementovaný případ užití (programátor) V případě výskytu chyby v systému je provedena oprava.

45

Protokol o ukončení projektu (projektový manažer) Artefakt obsahuje záznam o ukončení projektu. V okamžiku podepsání zadavatelem a projektovým manažerem je projekt formálně ukončen. Součástí protokolu je seznam všech artefaktů předávaných zadavateli (zákazníkovi) a seznam jeho případných připomínek. Kromě samotného systému se předává i artefakt dokumentace. Know-how (projektový manažer) Artefakt je vytvořen za účelem uchování znalostí získaných při vývoji projektu. Obsahuje nové poznatky všech osob zúčastněných na projektu, které by mohly být použity v dalších projektech. Kromě toho je jeho součástí i seznam komponent, které by mohly být znovu použity v dalších projektech.

4.7 Doporučení pro úspěch malých projektů Předpokladem úspěšného použití je malá velikost řešitelského týmu. Za maximální počet osob považujeme 15 členů týmu. Toto omezení je dáno tím, že není nijak formálně ošetřen způsob řízení přístupů k artefaktům a způsob publikace nových informací. Rovněž správa verzí artefaktů je řešena jednoduchým způsobem, který by se stal v případě většího množství osob nedostačujícím. Neformální komunikace členů vývojového týmu je předpokladem hladkého průběhu procesu vývoje. V případě většího počtu osob by bylo účelné definovat více specializovaných rolí. Obsah výstupních artefaktů a činností vývojového procesu je definován na základě objektově orientovaného přístupu. V případě vývoje v neobjektovém jazyce by musel být celý proces vývoje modifikován. Předpokládá se zkušenost pracovníků se SW vývojem a znalost objektových prostředků jazyka UML. Z toho důvodu není ošetřeno seznamování nových pracovníků s touto problematikou. Nutnost neplánovaného školení pracovníka by vzhledem k malé velikosti týmu mohla ohrozit plynulé pokračování prací na vývoji. Samozřejmě toto neplatí o školení, které vede procesní inženýr a které se týká konfigurace metodiky pro daná specifika projektu. Konkrétní vývojový tým nesmí strnule zůstat u jedné konfigurace metodiky. Naopak musí být po každém ukončeném projektu konfigurace vyhodnocena a případně upravena. Rovněž je vhodné spolu s rostoucí zkušeností projektového manažera i ostatních rolí snižovat formálnost některých projektových dokumentů. Samozřejmě nesmí být ohrožena jednoznačnost komunikace. Konfigurovaná metodika neřeší obchodní řízení projektu, musí tedy být řešeno vně vývojového týmu.

46

5

Případová studie

Cílem této kapitoly je demonstrovat projekt, na němž budou ukázány klíčové principy metodiky RUP. Na projekt je nahlíženo retrospektivně, tzn. že už je ukončen a poskytuje nám zpětný pohled na jednotlivé fáze a iterace. Záměrem není popsat tvorbu projektu kompletně do všech detailů, ale ukázat životní cyklus vývoje SW, procesy, role a aktivity, které hlavním způsobem ovlivňují vývoj projektu. Případová studie byla tvořena na základě spolupráce se společností IBA CZ, s.r.o. Vzhledem k tomu, že mnohé informace podléhají obchodnímu tajemství, je případová studie jen zčásti podobná opravdovému projektu v této společnosti. Většina skutečností je dopracována nebo přepracována tak, aby nebylo narušeno obchodní tajemství.

5.1 Fáze zahájení Cílem projektu bylo vyvinout SW pro skladovou evidenci. Systém měl zejména umožnit evidovat skladové položky a provádět specifikované operace s těmito položkami (operace uvnitř obchodní společnosti). Dále měl systém umožnit objednávání zboží (operace mezi obchodními společnostmi nebo mezi obchodní společností a běžným zákazníkem). Systém byl vyvíjen jako interní projekt, tzn. že vývojový tým byl součástí obchodní společnosti, která systém požadovala. Naléhavost začlenit systém pro skladovou evidenci do obchodních procesů vyplynula z potřeby konkurenceschopnosti na trhu. Všechny skladové operace byly doposud evidovány převážně v papírové podobě, což často vedlo k chybám. Také rychlost vyskladnění a uskladnění byla tímto limitována. Objednávky byly řešeny externě bez přímé návaznosti na skladové procesy. Proto se management rozhodl pro vytvoření systému skladové evidence, který bude napomáhat řízení skladových operací v reálném čase. Mezi hlavní cíle projektu patřilo poskytnutí detailního přehledu o stavu skladovaných položek, snížení počtu chybných operací, časová úspora a možnost online objednávání skladových položek. Od systému se také očekávalo snížení vlivu lidského faktoru na obchodní procesy. Systém měl být využit zejména pro interní účely, ale předpokládalo se, že skladová evidence bude prodávána i obchodním partnerům. Zadavatelem projektu byl management obchodní společnosti (dále jen zákazník). Projektový manažer byl sice zaměstnancem té samé obchodní společnosti, ale to z pohledu případové studie není významné. Proběhlo několik informačních schůzek zákazníka a projektového manažera. Cílem bylo vyjasnit si základní cíle zákazníka a postoje projektového manažera. Bylo rozhodnuto, ze se začne vyvíjet systém skladové evidence podle metodiky RUP. Projekt byl oficiálně zahájen 5.3.2007. Projektový manažer měl možnost bez větších komplikací obsazovat zaměstnance do rolí v projektu. Nejprve byla obsazena role analytika, který dostal za úkol zpracovat vizi projektu. Analytik vedl různá interview se zákazníkem. V této fázi analytik prováděl práci zčásti podobnou práci projektového manažera, který se scházel s managementem ještě před spuštěním projektu. Analytik ovšem výstupy interview formálně zaznamenával, informace uspořádal a postupně vytvářel artefakt vize, který vznikal po celou dobu fáze zahájení. Nejprve artefakt obsahoval cíle, které měly charakter obchodního záměru. Od tohoto záměru byly vytvářeny hlavní cíle projektu. Skladová evidence měla

47

umožňovat přehledné vedení a správu skladové hospodářství. Dále pak byl zanesen požadavek na vytváření a správu objednávek. V následujícím odstavci je pro ukázku uvedena část artefaktu vize: K udržení stálé úrovně obchodních výsledků je nutné držet krok s technologiemi a know-how konkurenčních obchodních společností. Pro větší efektivitu práce obchodních zástupců a lepší dostupnost pro zákazníky je nutné zlepšit proces vyhledávání informací o nabízeném zboží a zjednodušit proces objednávání zboží. Záměrem je vyvinout online systém pro vyhledávání a objednávání zboží. Tento systém umožní výrazné zefektivnění vyřizování objednávek v porovnání se současným „ručním“ způsobem vyřizování. Očekává se rychlá návratnost investic a nárůst ziskovosti společnosti. Byla vytvořena první verze artefaktu vize, která byla ústně odsouhlasena zákazníkem, analytikem a projektovým manažerem. V tuto chvíli začal projektový manažer vytvářet plán projektu. Nejprve byl vytvořen plán první iterace fáze zahájení. Její délka byla stanovena na tři týdny. Další iterace ve fázi zahájení nebyly plánovány. V projektovém plánu byly zachyceny následující aktivity a zodpovědnost za jednotlivé artefakty pro fázi zahájení: • Navrhnout a odsouhlasit artefakt vize (analytik). • Definovat základní požadavky na systém (analytik) – vytvořit artefakt specifikace požadavků, který obsahuje klíčové požadavky na systém a hlavní omezení. • Navrhnout rozsah systému (analytik) – vytvořit modely případů užití na nejvyšší úrovni, každý aktér a případ užití bude krátce popsán. • Vytvořit celkový plán projektu a podrobný plán první iterace fáze projektování (projektový manažer). • Identifikovat rizika projektu (analytik). • Navrhnout koncept testovací strategie (test architekt). • Navrhnout pracovní verzi architektury (softwarový architekt). • Vytvořit slovník pojmů projektu (analytik). Aktivity ve fázi zahájení se zaměřovaly zejména na specifikaci požadavků a na vytvoření artefaktu vize. Byly identifikovány hlavní případy užití a byl rozvíjen plán projektu. Na konci fáze zahájení mělo být rozhodnuto, zda v projektu pokračovat, nebo ne. Milníkem této fáze byl artefakt vize, v němž bylo toto rozhodnutí zachyceno. Projektový manažer dále v projektovém plánu zachytil: • Shrnutí celého projektu – popis účelu projektu, rozsah projektu a cíle projektu. • Řízení projektu – odhady nákladů a časové plány, určení fází a milníků. • Určení rolí a odpovědností – seznam klíčových rolí v projektu, obsazení těchto rolí konkrétními zaměstnanci. • Procesní plán – vývojový proces včetně metodiky, nástrojů a technik, které jsou v projektu použity.

48

Projektový manažer u tohoto projektu nevyužil služeb procesního inženýra. Vývojový proces navrhl sám a zahrnul ho přímo do artefaktu plán projektu, takže nevytvářel samostatný artefakt vývojový proces a školení, jak je doporučeno v předchozí kapitole. Po schválení první verze artefaktu vize začal analytik pracovat na specifikaci požadavků. Organizoval několik informačních schůzek se zákazníkem, na kterých docházelo k upřesňování představ o budoucím systému. Důležité bylo shodné porozumění požadavkům. Úkolem analytika také bylo navádět zákazníka k reálným a užitečným požadavkům na systém. Spolu s artefaktem specifikace požadavků vytvářel analytik i modely případu užití a slovník pojmů projektu. Projektový manažer pravidelně kontroloval stav vývoje těchto artefaktů a s analytikem měl pracovní schůzku zpravidla každé dva dny. Artefakt specifikace požadavků zahrnoval jak funkční, tak nefunkční požadavky na systém. Mezi nefunkční požadavky například patřilo: • Systém se bude automaticky lokalizovat podle operačního systému (přizpůsobení časové zóny a jazyka). • Systém bude přístupný jak z webového prohlížeče, tak z mobilního terminálu Falcon 4420. • Systém bude intuitivní, takže uživatelé nebudou muset absolvovat školení. • Systém nebude závislý na jednom webovém prohlížeči, musí být přístupný přes webový prohlížeč Mozilla Firefox i MS Internet Explorer. • Uživatelé musí dostat odpověď do jedné sekundy, pokud budou k systému přistupovat pomocí mobilního terminálu, a do dvou sekund, pokud budou přistupovat pomocí webového prohlížeče. Na základě upřesňujících informací z artefaktu specifikace požadavků projektový manažer aktualizoval plán projektu. Systém měl zajistit funkčnost skladového hospodářství, které by bylo přístupné jak z webového rozhraní, tak mobilního terminálu Falcon 4420. Na základě artefaktu specifikace požadavků, modelů případů užití a slovníku pojmů začal softwarový architekt navrhovat pracovní verzi architektury systému. Výsledný produkt měl být postaven na platformě Java, měl využívat webové služby na základě SOAP (Service Oriented Architecture Protocol) a data ukládat do databáze. Projekt skladové evidence měl podobnou složitost a navrženou architekturu jako systém, který byl již v minulosti vyvíjen, kromě webových služeb, s nimiž neměl vývojový tým zkušenosti. Projektový manažer proto v plánování tyto skutečnosti zohlednil. Časový rámec projektu, rozpočet a potřebné úsilí byly plánovány na základě dřívějších zkušeností. Nezkušenost s webovými službami byla ošetřena tím způsobem, že do fáze projektování byly naplánovány dvě iterace, které řešily webové služby. Následně byl rozpočet upraven tak, aby zohledňoval náklady na tyto dvě iterace. Projektový manažer spolu s analytikem vytvářeli artefakt rizika. Stupeň rizik byl zahrnut do následující stupnice: vysoké, střední a nízké riziko. Identifikovaná rizika ve fázi zahájení, jejich stupeň a návrh řešení je shrnut v následujícím výčtu.

49

1) Projektový tým nemá zkušenosti s webovými službami. Je možné, že projekt bude opožděn. Stupeň rizika:Vysoké. Ošetření rizika: Ve fázi projektování proběhne školení vývojového týmu ohledně webových služeb. Jsou naplánovány dvě iterace, které budou řešit webové služby. 2) Velké množství uživatelů může znatelně snížit systémovou výkonnost. Stupeň rizika:Střední. Ošetření rizika: Ve fázi projektování proběhnou zátěžové testy prototypů. Na základě výsledků bude určen další postup. 3) Může vznikat nekompatibilita s webovými prohlížeči a specifickými konfiguracemi počítačů u zákazníka. Stupeň rizika:Nízké. Ošetření rizika: Řešení bude navrženo ve fázi projektování. Testovací strategie byla v této fázi rozvíjena velmi obecně. Test architekt navrhnul typy testů, které měly být v budoucnu detailněji rozpracovány. Mezi tyto testy patřilo: jednotkové testování, integrační testování, systémové testování a akceptační testování. Na konci fáze zahájení měl projektový manažer v plánu projektu zahrnuty následující informace, které se týkaly celkového hrubého plánu projektu:

Fáze projektování (plánovaná délka 12 týdnů) Iterace 1 (plánovaná délka 4 týdny) • Dokončit analýzu a návrh jádra systému. ƒ ƒ

Vytvořit podrobné modely případů užití pro jádro systému. Vytvořit analytické modely případů užití a jejich na základě vytvořit návrhové modely. Dokončit architekturu na nejvyšší úrovni a zachytit ji v artefaktu architektura.

• Vytvořit prototyp architektury. ƒ Implementovat jádro systému. • Provést výkonnostní testy. Iterace 2 (plánovaná délka 4 týdny) • Školení týmu ohledně webových služeb. • Dokončit analýzu a návrh systému pro požadavky, které se týkají webových služeb. ƒ ƒ

Vytvořit podrobné modely případů užití pro webové služby. Vytvořit analytické modely případů užití a na jejich základě vytvořit návrhové modely. Zaměřit se na artefakt architektura, doplnit jej a vylepšit.

• Vylepšit prototyp architektury pro webové služby, propojit jádro systému s webovými službami. ƒ Implementovat prvky týkající se webových služeb. • Provést testování (zejména integrační).

50

Iterace 3 (plánovaná délka 4 týdny) • Dokončit analýzu a návrh systému pro požadavky, které se týkají webových služeb a dosud nebyly zpracovány. ƒ ƒ

Na základě modelů případů užití vytvořit analytické modely a upravit dosud vytvořené návrhové modely. Vylepšit architekturu a zachytit ji v artefaktu architektura.

• Vytvořit prototyp architektury pro webové služby tak, aby byl systém přístupný jako webová služba. • Provést výkonnostní a integrační testy.

Fáze realizace (plánovaná délka 8 týdnů) Iterace 1 (plánovaná délka 4 týdny) • Implementovat a otestovat klíčové požadavky na systém. ƒ

Využít podrobné modely případů užití, analytické a návrhové modely. Je možné případné vylepšení návrhových modelů. Implementace.

• Integrace a testování. Iterace 2 (plánovaná délka 4 týdny) • Implementace a testování zbylých požadavků. ƒ

Využít podrobné modely případů užití, analytické a návrhové modely. Je možné případné vylepšení návrhových modelů. Implementace.

• Integrace a testování. • Příprava dodání. • Vyhodnotit, zda je implementace dostatečně připravena na beta testování.

Fáze nasazení (plánovaná délka 6 týdnů) Iterace 1 (plánovaná délka 3 týdny) • Dodání beta verze systému. • Zpětná vazba a oprava chyb beta verze systému. • Připravit release, distribuci a instalaci. Iterace 2 (plánovaná délka 3 týdny) • Zpětná vazba z release a oprava chyb. • Připravit finální verzi systému, distribuci a instalaci. Na obrázku 5.1 je časové rozložení jednotlivých fází a iterací v projektu. Na konci každé fáze je uveden milník, který má samozřejmě nulovou délku trvání. Dále byl v projektovém plánu zahrnut i podrobný plán první iterace fáze projektování, který je zachycen na obrázku 5.2.

51

Obrázek 5.1: Časový rozvrh projektu

Obrázek 5.2: Podrobný plán první iterace fáze projektování

52

Projektový manažer došel k závěru, že projekt je uskutečnitelný. Spolu s analytikem dokončil artefakt vize, v němž byl zahrnut i rozpočet projektu. Artefakt vize byl milníkem fáze zahájení. Po písemném odsouhlasení (akceptační protokol) se projekt přesunul do fáze projektování. Na konci fáze zahájení byly artefakty projektu v následujícím stavu: Artefakty ve fázi zahájení Vize Plán projektu Slovník pojmů projektu Modely případů užití Specifikace požadavků Rizika Architektura Testovací strategie Plán 1. iterace ve fázi projektování Plán 2. iterace ve fázi projektování Akceptační protokol pro fázi zahájení

Míra dokončení (%) 100 35 40 20 20 25 10 10 100 60 100

Tabulka 5.1: Artefakty ve fázi zahájení Ve fázi zahájení byly v projektu použity následující RUP nástroje: • • • • • •

IBM Rational Software Architect IBM Rational SoDA IBM Rational RequisitePro IBM Rational Composer IBM Rational Rational Portfolio Manager IBM Rational Clear Case

5.2 Fáze projektování Fáze projektování se zaměřovala na vývoj kvalitní architektury, která byla milníkem této fáze. Byly naplánovány tři iterace, každá měla mít délku 20 pracovních dnů. Výstupem každé iterace měl být implementovaný prototyp, který měl být otestován a předveden zákazníkovi. Tato částečná implementace systému si kladla za cíl ověřit stabilitu architektury, dále funkčnost, spolehlivost, použitelnost, výkon a podporu. Během této fáze analytik upřesňoval artefakt specifikace požadavků a vytvářel podrobné modely případů užití. Určoval hlavní a alternativní toky událostí a vybíral nejdůležitější případy užití. Pro tyto nejdůležitější případy užití byly vytvořeny primární a sekundární scénáře, které byly použity při tvorbě architektury. Na základě scénářů testovací architekt dále rozvíjel testovací strategii. Analytik aktualizoval slovník pojmů projektu.

53

Jednotkové testování se mělo zaměřit na funkční kvalitu systému. Odpovědnost za provádění tohoto testování ležela na programátorovi, který se zaměřoval zejména na kód a prováděl tzv. testování bílých skříněk. Integrační testování se zaměřovalo na funkční požadavky, hlavně na testování kódu, zda požadovaně a korektně spolupracuje s okolními částmi systému. Zodpovědnost za toto testování měl programátor, ale hlavní zodpovědnost za konečnou kvalitu komponent měl softwarový architekt. Programátor se zaměřoval na testování pomocí tzv. bílých a černých skříněk. Bylo prováděno i další testování (systémové, akceptační), které bylo popsáno v artefaktu testovací strategie. Softwarový architekt pracoval spolu s analytikem na artefaktu architektura. Výchozími podklady pro práci byl artefakt modely případů užití, slovník pojmů projektu a specifikace požadavků. Artefakt architektura obsahoval kompletní přehled o architektuře systému. Byly zde zachyceny různé architekturní pohledy, které zdůrazňovaly odlišné aspekty systému a skrývaly detaily, jež by ztěžovaly chápání systému. Cílem bylo zachytit důležitá architekturní řešení, která měla být použita při vývoji. Kromě samotné architektury vyvíjel analytik a softwarový architekt analytické a návrhové modely, které poskytovaly detailnější pohled na systém. Architektura byla znázorněna modelem 4+1. Bylo tedy použito 5 pohledů na architekturu: logický, implementační, procesní, pohled nasazení a případy užití. V logickém pohledu byly využity 4 hlavní balíky. Dva z nich se týkaly prezentační vrstvy, protože bylo třeba rozlišit mezi mobilním terminálem Falcon 4420 a webovým rozhraním. Další dva balíky se týkaly aplikační a datové vrstvy. Na základě materiálů od softwarového architekta a analytika implementoval programátor prototyp architektury. Tento prototyp byl následně testován pomocí výkonnostních testů. Kromě implementace vznikal i návrh grafického uživatelského rozhraní, za nějž měl zodpovědnost návrhář GUI. Projekt probíhal podle plánu stanoveného ve fázi zahájení. Projektový manažer dohlížel na průběh vývoje a v každé iteraci plánoval podrobný plán následující iterace. Testy byly prováděny na základě testovací strategie. Testování odhalilo některé problémy. V této fázi bylo naplánováno a provedeno 20 testů, z toho 13 testů proběhlo bez problému, 7 testů odhalilo nedostatky, jejichž vyřešení bylo naplánováno do dalších iterací. Na konci každé iterace bylo vyhodnoceno testování a analytik zachytil výsledky v artefaktu testovací protokol. Na konci projektu tak byla vytvořena sada těchto testovacích protokolů. Během fáze projektování analytik a projektový manažer aktualizovali artefakt rizika. Na konci fáze projektování byla dokumentována následující rizika. 1) V případě nových funkčních požadavků od zákazníka není možné dodat kompletní systém včas. Stupeň rizika: Střední. Ošetření rizika: Spoléhá se na to, ze nové významné funkční požadavky nebudou specifikovány.

54

2) Chyby odhalené při testování mohou zpozdit dodání beta verze systému. Stupeň rizika: Střední. Ošetření rizika: Ošetření chyb bude provedeno v první iteraci fáze realizace. Očekává se, že problémy budou vyřešeny včas. 3) Projektový tým nemá zkušenosti s webovými službami. Stupeň rizika: Nízké. Ošetření rizika: Školení se zdá být dostatečné, zatím nebyl zpozorován problém s webovými službami. 4) Velké množství uživatelů může znatelně snížit systémovou výkonnost. Stupeň rizika: Nízké. Ošetření rizika: Výkonnostní testy zatím dopadly dobře. 5) Může vzniknout nekompatibilita s webovými prohlížeči a specifickými konfiguracemi počítačů u zákazníka. Stupeň rizika: Riziko eliminováno. Ošetření rizika: Vyřešeno v třetí iteraci fáze projektování. Na konci fáze projektování projektový manažer vytvořil podrobný plán první iterace fáze realizace a hrubý plán druhé iterace fáze realizace. Prototyp architektury i s GUI byl předveden zákazníkovi k odsouhlasení. Nebyly shledány žádné významné nedostatky, byl sepsán akceptační protokol a projekt postoupil do fáze realizace. Během fáze projektování dospěla práce na artefaktech projektu do stavu, který je uveden v tabulce 5.2. Je vidět, že některé artefakty byly zcela dokončeny a dále se už neměnily. Artefakty ve fázi projektování Plán projektu Plán 2. iterace ve fázi projektování Slovník pojmů projektu Specifikace požadavků Modely případů užití Analytické a návrhové modely Architektura Návrh GUI Prototyp architektury Testovací strategie Testovací protokol pro fázi projektování Rizika Plán 1. iterace ve fázi realizace Plán 2. iterace ve fázi realizace Akceptační protokol pro fázi projektování

Míra dokončení (%) 75 100 80 90 85 70 100 70 100 90 100 50 100 60 100

Tabulka 5.2: Artefakty ve fázi projektování

55

Ve fázi projektování byly v projektu použity následující RUP nástroje: • • • • • •

IBM Rational Software Architect IBM Rational SoDA IBM Rational RequisitePro IBM Rational Composer IBM Rational Rational Portfolio Manager IBM Rational Clear Case

5.3 Fáze realizace Fáze realizace se zaměřovala hlavně na implementaci systému. Byly naplánovány dvě iterace, každá měla mít délku 20 pracovních dnů. První iterace měla implementovat klíčové požadavky na systém, druhá měla ošetřovat zbytek požadavků. Milníkem této fáze byla beta verze systému. Největší úsilí bylo vloženo do implementace, ale kromě toho se musely vyřešit zbývající scénáře z fáze projektování. Byly ošetřeny stejným způsobem jako v předchozí fázi a následně implementovány. Analytik a softwarový architekt dokončili práci na analytických a návrhových modelech. Návrhář GUI doladil grafické komponenty systému. Do fáze realizace se testování zaměřovalo zejména na technickou proveditelnost řešení. Ve fázi realizace se testování zaměřilo na GUI a také na to, zda testy provedené na prototypu architektury budou úspěšné i po implementaci nových funkcí. Narostl počet testovacích případů, byly použity automatické nástroje pro testování, které částečně snížily úsilí vynaložené na „manuální“ testování. Ve fázi realizace analytik a programátor kontrolovali, zda vyvíjený systém odpovídá artefaktu specifikace požadavků. Analytik dále vytvářel artefakt dokumentace, který popisoval systém jak z uživatelského, tak z administrátorského pohledu. Artefakt vize se během této fáze už neměnil, specifikace požadavků a modely případů se měnily jen nepatrně. Na konci každé iterace byl implementovaný systém předveden zákazníkovi a projektový manažer vyhotovil akceptační protokol. Žádné závažnější připomínky ze strany zákazníka nebyly hlášeny. Do konce fáze realizace bylo ověřeno, že systém je dostatečně kvalitní na to, aby mohl být poskytnut koncovým uživatelům pro beta testování. Samotné testování ve fázi realizace mělo menší problémy. Test architekt měl v této fázi naplánováno 50 testů. Stihlo se implementovat a provést jen 45 testů, z toho 5 testů odhalilo drobné chyby, které se měly ošetřit ve fázi nasazení. Tyto nedostatky byly uvedeny do testovacího protokolu. Projektový manažer tyto skutečnosti zachytil i v podrobném plánu první iterace fáze nasazení, který vytvořil na konci fáze realizace. Během fáze realizace byla všechna rizika se stupněm vysoké a střední eliminována. Beta verze systému byla připravena k dodání, což bylo milníkem této fáze. Projektový manažer a zákazník sepsali akceptační protokol pro fázi realizace. Na konci fáze realizace byly artefakty ve stavu, který popisuje tabulka 5.3. Většina artefaktů už byla kompletně dokončena.

56

Artefakty ve fázi realizace Plán projektu Plán 2. iterace ve fázi realizace Slovník pojmů projektu Specifikace požadavků Modely případů užití Analytické a návrhové modely Návrh GUI Testovací strategie Testovací protokoly pro fázi realizace Rizika Dokumentace Beta verze systému Plán 1. iterace ve fázi nasazení Plán 2. iterace ve fázi nasazení Akceptační protokoly pro fázi realizace

Míra dokončení (%) 95 100 95 100 100 100 100 100 100 90 80 100 100 60 100

Tabulka 5.3: Artefakty ve fázi realizace Ve fázi projektování byly v projektu použity následující RUP nástroje: • • • • • • • • •

IBM Rational Software Architect IBM Rational SoDA IBM Rational RequisitePro IBM Rational Manual Tester IBM Rational Performance Tester IBM Rational Functional Tester IBM Rational Composer IBM Rational Rational Portfolio Manager IBM Rational Clear Case

5.4 Fáze nasazení Fáze nasazení se zaměřovala na dodání systému a opravu odhalených chyb. Milníkem byla finální verze systému a formální ukončení projektu. Byly naplánovány dvě iterace, každá měla mít délku 15 pracovních dnů. Na začátku první iterace byla beta verze systému dodána do produkčního prostředí k otestování. Mezitím programátor opravoval drobné chyby odhalené ve fázi realizace, na jejichž včasné ošetření nezbyl čas. Beta verze se v produkčním prostředí docela osvědčila, byly reportovány jen méně závažné chyby, které byly ještě v první iteraci opraveny. Na konci první iterace byl připraven release, jež byl opět nasazen do produkčního prostředí. Druhá iterace se zaměřovala na finální doladění systému a provedení závěrečných testů. Z plánovaných 50 testů uspělo 48 testů, 2 testy odhalily drobné nedo-

57

statky, jež se nakonec povedlo odstranit. Analytik dokončil práci na artefaktu dokumentace, ten byl předán zákazníkovi spolu s finální verzí systému. Na konci fáze nasazení projektový manažer vytvořil protokol o převzetí systému. Zákazník a projektový manažer tento protokol podepsali, a tím byl projekt formálně ukončen. Projektový manažer ještě vypracoval interní dokument o projektu, kde zachytil zkušenosti z vývoje (artefakt know-how). Tabulka 5.4 obsahuje artefakty, na nichž se pracovalo během fáze nasazení. Na konci této fáze byly všechny artefakty samozřejmě zcela dokončeny. Artefakty ve fázi nasazení Plán projektu Plán 2. iterace ve fázi nasazení Slovník pojmů projektu Dokumentace Release Rizika Testovací protokoly pro fázi nasazení Finální verze systému Akceptační protokoly pro fázi nasazení Protokol o převzetí systému Know-how

Míra dokončení (%) 100 100 100 100 100 100 100 100 100 100 100

Tabulka 5.4: Artefakty ve fázi nasazení Ve fázi nasazení byly v projektu použity následující RUP nástroje: • • • •

IBM Rational Manual Tester IBM Rational Functional Tester IBM Rational Rational Portfolio Manager IBM Rational Clear Case

58

6. Závěr Vývoj softwarového systému je složitý proces, který vyžaduje širokou škálu znalostí a dovedností. Zahrnuje mnohem více než jen pouhé psaní kódu. V dnešní době nelze úspěšně vyvíjet a řídit projekty pouze „intuitivním“ způsobem. Praxe ukázala, že přirozené schopnosti člověka nejsou pro tuto problematiku dostatečné. Pro zvýšení pravděpodobnosti úspěchu je důležité, aby vývojový tým používal nějakou metodiku, která definuje pravidla, principy a postupy mající vliv na efektivnost a organizaci práce. Softwarový vývoj se musí zaměřovat na všechny aktivity potřebné pro dodání kvalitního sytému zákazníkovi. Na druhou stranu by proces vývoje neměl být zbytečně složitý. Cílem této diplomové práce bylo představit metodiku Rational Unified Process a konfigurovat ji pro potřeby malých softwarových projektů. Nejprve jsme vyšli z tradičního vývoje systémů podle vodopádového životního cyklu. Ukázali jsme jeho výhody a nevýhody pro současný způsob vývoje softwaru. Lze konstatovat, že nevýhody obecně převažují nad výhodami. Vodopád je vhodný jen pro specifickou množinu projektů. Dále jsme se zaměřili na popis metodiky Rational Unified Process. Tato metodika zahrnuje celý životní cyklus projektu. Zaměřuje se na nejlepší praktiky, které jsou empiricky vyzkoušené dlouholetou praxí. Tato metodika je velmi obsáhlá a formální, takže ji lze stěží celou použít pro vývoj menších systémů. Pro malé projekty jsme navrhli modifikaci této metodiky, která odstraňuje nadbytečné role, artefakty a činnosti. Metodika je uzpůsobená pro specifika vyskytující se právě u malých projektů. V případové studii jsme ukázali, jakým způsobem může být konfigurovaná metodika využita v praxi. Metodika Rational Unified Process je silně svázána s nástroji rodiny Rational. Jejich cena se pohybuje v řádech desítek tisíc korun za jeden nástroj. Sada těchto nástrojů tedy stojí statisíce, a to uvažujeme pouze o licencích pro jednotlivce. Pořízení těchto nástrojů do větší firmy může vyjít na několik milionů korun. Jedná se tedy o nezanedbatelnou finanční částku. Na druhou stranu lze tyto nástroje uspokojivě nahradit levnějšími nebo dokonce nekomerčními nástroji. Během tvorby této diplomové práce byla navázána spolupráce se společností IBA CZ, s.r.o. Přístupy k softwarovému vývoji jsou v dnešní době natolik různorodé, že na začátku bylo nutné vyjasnění základních pojmů, o kterých si obě strany myslely, že jejich sémantika je naprosto jednoznačná. Nakonec se ukázalo, že i literatura přistupuje k těmto pojmům odlišným způsobem. I když vznikají stále nové metodiky, je třeba si uvědomit, že každý projekt je specifický. Je tedy nutné vybrat správnou metodiku a zpravidla ji ještě konfigurovat. Ale i sebelepší metodika uzpůsobená pro konkrétní projekt není zárukou úspěchu. Je dobrým návodem, jak se vyhnout potenciálním problémům, ale z povahy věci nemůže garantovat zdárné dokončení projektu. Stále je třeba mít na paměti důležité faktory, které nelze formálně ošetřit, například lidský faktor a s ním spojená různá selhání. Na druhou stranu jsou skutečnosti, které lze kvalitně ošetřit nebo řídit, například formální správa požadavků, jasná komunikace, reálný odhad složitosti systému, důsledné testování, předcházení rizikům, kontrolované provádění změn a další. Vzhledem k budoucnosti se jeví jako pravděpodobné, ze se problematice metodik softwarového vývoje bude věnovat stále větší pozornost.

59

Literatura [Ald05]

ALDORF, Filip. Metodika RUP [online]. 2005 [cit. 2007-04-11]. Dostupný z WWW: .

[ArNe03] ARLOW, Jim, NEUSTADT, Ila. UML a unifikovaný proces vývoje aplikací : průvodce analýzou a návrhem objektově orientovaného softwaru. Brno : Computer Press, 2003. 387 s. ISBN 807226947X. [BoTu03] BOEHM, Barry W., TURNER, Richard. Balancing Agility And Discipline : A Guide For The Perplexed. Pearson Education Limited, 2003. 304 s. ISBN 9780321186126. [Buch05]

BUCHALCEVOVÁ, Alena. Metodiky vývoje a údržby informačních systémů : kategorizace, agilní metodiky, vzory pro návrh metodiky. Praha : Grada, 2005. 163 s. ISBN 80247-1075-7.

[BuPa02]

BUCHALCEVOVÁ, Alena, PAVLÍČKOVÁ, Jarmila. Základy softwarového inženýrství : objektově orientovaný přístup. Praha : Vysoká škola ekonomická, 2002. 216 s. ISBN 8024502682.

[BSŠ02]

BUCHALCEVOVÁ, Alena, STANOVSKÁ, Iva, ŠIMŮNEK, Milan. Základy softwarového inženýrství : základní témata. Praha : Vysoká škola ekonomická, 2002. 198 s. ISBN 8024503468.

[CoHu95] COTTERELL, Mike, HUGHES, Robert. Software Project Management. Itp New Media, 1995. 274 s. ISBN 1850321906. [Fro95]

FROST, Stuart. The Select Perspective. Tesseract Publishing, 1995. 104 s. ISBN 1899340017.

[Gib06]

GIBBS, Dennis. Project Management with the IBM Rational Unified Process. IBM Press, 2006. 312 s. ISBN 0-321-33639-9.

60

[ChTh02] CHRISTENSEN, Mark, THAYER, Richard H. The Project Manager's Guide to Software Engineering's Best Practices. Wiley-IEEE Computer Society Pr, 2002. 552 s. ISBN 0769511996. [Kad04]

KADLEC, Václav. Agilní programování : metodiky efektivního vývoje softwaru. Brno : Computer Press, 2004. 280 s. ISBN 8025103420.

[Kru01]

KRUCHTEN, Philippe. The Rational Unified Process An Introduction. 2nd edition. Boston : Addison-Wesley, 2001. 298 s. ISBN 0-201-70710-1.

[RJB05]

RUMBAUGH, James, JACOBSON, Ivar, BOOCH, Grady. The unified modeling language reference manual. 2nd edition. Boston : Addison-Wesley, 2005. 721 s. ISBN 0321245628.

[Vach07]

VACH, David. IBM Rational [online]. 2007. 2007 [cit. 2007-04-11]. Dostupný z WWW: .

61

Příloha A Přehled artefaktů metodiky RUP Příloha podává souhrn artefaktů, které jsou vytvářeny nebo používány během životního cyklu projektu zpracovávaného podle metodiky Rational Unified Process. Artefakty jsou setříděny do logických skupin podle devíti hlavních pracovních procesů. U každého artefaktu je uveden odpovědný pracovník, resp. odpovědná role. Výčet je převzat z [Kru01], uvedené názvy jsou ponechány v angličtině, české ekvivalenty nejsou ustálené nebo jsou mnohdy krkolomné.

Business Modeling Artifact Set Target-Organization Assessment

Business-Process Analyst

Business Vision

Business-Process Analyst

Business Glossary

Business-Process Analyst

Business Rules

Business-Process Analyst

Supplementary Business Specification

Business-Process Analyst

Business Use-Case Model

Business-Process Analyst

Business Use-Case realization

Business Designer

Business Object Model

Business-Process Analyst

Business Architecture Document

Business-Process Analyst

Requirements Artifact Set Requirements Management Plan

System Analyst

Stakeholder Requests

System Analyst

Glossary

System Analyst

Vision

System Analyst

Requirements Attributes

System Analyst

Supplementary Specification

System Analyst

Software Requirements Specification

Use-Case Specifier

Use-Case Model

System Analyst

Use-Case Package

Use-Case Specifier

Boundary Class

User-Interface Designer

Use-Case Storyboard

User-Interface Designer

User-Interface Prototype

User-Interface Designer

62

Analysis and Design Artifact Set Reference Architecture

Architect

Reference Architecture Fit/Gap Analysis

Architect

Software Architecture Document

Architect

Use-Case Realization

Designer

Analysis Model

Architect

Analysis Class

Designer

Design Model

Architect

Design Subsystem

Designer

Design Package

Designer

Design Class

Designer

Interface

Designer

Capsule

Capsule Designer

Data Model

Database Designer

Implementation Artifact Set Implementation Model

Architect

Implementation Subsystem

Implementer

Component

Implementer

Integration Build Plan

System Integrator

Test Artifact Set Test Plan

Test Designer

Test Model

Test Designer

Test Procedure

Test Designer

Test Case

Test Designer

Test Script

Test Designer

Workload Model

Test Designer

Test Package

Designer

Test Class

Designer

Test Subsystem

Implementer

Test Component

Implementer

63

Test Result

Tester

Test Evaluation Summary

Test Designer

Deployment Artifact Set Deployment Plan

Deployment Manager

Bill of Materials

Deployment Manager

Release Notes

Deployment Manager

Installation Component

Implementer

Support Material

Technical Writer

Training Material

Course Developer

Product Artwork

Graphic Artist

Configuration and Change Management Artifact Set Configuration Management Plan

Configuration Manager

Project Repository

Configuration Manager

Configuration Audit Findings

Configuration Manager

Change Request

Change Control Manager

Project Management Artifact Set Business Case

Project Manager

Software Development Plan

Project Manager

Iteration Plan

Project Manager

Problem Resolution Plan

Project Manager

Risk Management Plan

Project Manager

Product Acceptance Plan

Project Manager

Measurement Plan

Project Manager

Iteration Assessment

Project Manager

Status Assessment

Project Manager

Work Order

Project Manager

Project Measurements

Project Manager

Review Record

Project Manager

64

Environment Artifact Set Quality Assurance Plan

Process Engineer

Development Organization Assessment

Process Engineer

Project-Specific Templates

Process Engineer

Development Case

Process Engineer

Guidelines (Design, Test, etc.)

Many Workers

Supporting Environment

System Administrator

Tool Support Assessment

Tool Specialist

Tools

Tool Specialist

65

Příloha B Přehled rolí metodiky RUP Příloha podává souhrn rolí, které jsou zahrnuty v metodice Rational Unified Process. Je důležité si uvědomit, že role není individuum, ale popisuje chování a činnosti, kterým se daná osoba v dané roli musí uzpůsobit. Výčet je převzat z [Kru01], uvedené názvy rolí jsou ponechány v angličtině, české ekvivalenty nejsou ustálené nebo jsou mnohdy krkolomné. Je převzata i stará terminologie názvu role. V současnosti je oficiální anglický název role, starší název je worker.

Analyst Worker Set Business-Process Analyst Business Designer Business-Model Reviewer Requirements Reviewer System Analyst Use-Case Specifier User-Interface Designer

Developer Worker Set Architect Architect Reviewer Capsule Designer Code Reviewer Database Designer Design Reviewer Designer Implementer Integrator System Integrator

Tester Worker Set Test Designer Tester

66

Manager Worker Set Change Control Manager Configuration Manager Deployment Manager Process Engineer Project Manager Project Reviewer

Additional Worker Set Any Worker Course Developer Graphic Artist Stakeholder System Administrator Technical Writer Tool Specialist

67

Příloha C Přehled nástrojů rodiny Rational Příloha podává souhrn jednotlivých produktů rodiny Rational. U každého produktu je uveden krátký popis. Pod pojmem Rational je ve firmě IBM seskupena množina aplikací, která uceleně pokrývá všechny fáze vývoje SW. Dále jsou tyto produkty seskupeny podle účelu, ke kterému jsou využity během vývoje. Výčet a popis produktů je převzat z [Vach07] a [Kad04].

Rational Ada Developer • integrované vývojové prostředí navrženo pro aplikace založené na Ada-dase

IBM Rational Application Developer • vývojové prostředí založené na Open Source projektu Eclipse ve verzi 3

IBM Rational ClearCase • nástroj pro správu verzí, obdoba např. CVS (Concurrent Version Control System), Subversion

IBM Rational ClearQuest • produkt pro sledování závad a změn v rámci SW vývoje aplikace

IBM Rational Data Architect • nástroj pro datové modelování a integrační návrh, který usnadňuje návrh všech typ; databází, od jednoduchých až po komplexní a složité relační databáze

IBM Rational Functional Tester • umožňuje automatizovat funkční a regresní testování aplikací napsaných nejen na platformě Java, ale také v prostředí .NET a webových aplikací

IBM Rational Manual Tester • nástroj pro správu (vytváření) manuálních testů

IBM Rational Method Composer • flexibilní procesní platforma obsahující procesy a nástroje pro použití během řízení životního cyklu IT (IT Lifecycle Management)

IBM Rational Performance Tester • produkt pro testování (nejen) zátěže a výkonu webových aplikací

68

IBM Rational Portfolio Manager • poskytuje možnost monitorovat a řídit rizika, problémy a zdroje napříč portfoliem stejně jako umožňuje plánovat, řídit a hodnotit každý projekt nebo celé portfolio

IBM Rational PurifyPlus • run-time řešení pro analýzu SW navržené tak, aby pomáhala vývojářům a programátorům v produkci kvalitních a spolehlivých zdrojových kódů. Spolehlivost je zajišťována přes dvě základní funkce: detekování chyb operační paměti a tzv. memory leak detekci

IBM Rational RequisitePro • nástroj pro správu, sledování, vyhodnocování a řízení požadavků v průběhu vývoje projektu

IBM Rational Robot • nástroj automatizující testování aplikací vytvořených v různých vývojových prostředích a jazycích zahrnujících HTML, DHTML, Microsoft Visual Studio .NET, Microsoft Visual Basic, C++, Java, Oracle Developer/2000, PeopleSoft a Sybase PowerBuilder. Představuje jediný nástroj poskytující plnou nativní podporu jazyků postavených na platformě .NET, jako jsou VB.NET, C# a J#

IBM Rational Rose XDE Developer • umožňuje softwarovým designérům a architektům vytvářet na platformě nezávislé modely architektury, vytvářet nebo editovat znovupoužitelné šablony a vzory. To vše s využitím notace UML (Unified Modeling Language)

IBM Rational SoDa • nástroj pro automatické generování dokumentace, obsahuje šablony pro MS Word a Adobe FrameMaker

IBM Rational Software Architect • integrované prostředí pro vývoj a tvorbu aplikací (nejen) orientovaných na služby za pomoci modelového vývoje UML

IBM Rational Software Modeler • uživatelsky nastavitelná vývojová aplikace, založená na UML modelové architektuře vývoje aplikací

IBM Rational TestManager • základní kámen všech testovacích nástrojů rodiny Rational, umožňuje plánování a řízení veškerých testovacích aktivit

69

IBM Rational Unified Process • samotná metodika neobsahuje nástroje, tyto jsou dodávány jako komerční produkty s vlastní licencí

IBM Rational Web Developer • nástroj pro tvorbu, testování a umisťování webových stránek a služeb podporujících různé programové prostředí

Návrh a vývoj • • • • •

IBM Rational Software Architect IBM Rational Rose XDE Developer IBM Rational Web Developer IBM Rational Application Developer IBM Rational Data Architect

Správa softwaru v průběhu životního cyklu aplikace • Rational Portfolio Manager • IBM Rational Unified Process

Analýza a správa požadavků • IBM Rational RequisitePro • IBM Rational Software Modelerk

Automatizované testování a kvalita • • • • • •

IBM Rational Functional Tester IBM Rational Performance Tester IBM Rational Manual Tester IBM Rational Robot IBM Rational TestManager IBM Rational PurifyPlus

70

Konfigurační a změnové řízení • IBM Rational ClearCase • IBM Rational ClearQuest

71

Příloha D Grafické znázornění fází metodiky RUP

Obrázek D.1: Role a artefakty ve fázi zahájení

72

Obrázek D.2: Role a artefakty ve fázi projektování

73

Obrázek D.3: Role a artefakty ve fázi realizace

74

Obrázek D.4: Role a artefakty ve fázi nasazení

75

Obsah CD Zdrojový text diplomové práce ve formátu doc. Text diplomové práce pro tisk ve formátu pdf.

76