20. 4. 2009
PA103: OO metody návrhu IS © R. Ošlejšek, FI MU Brno
1
Rational Unified Process
case-study
© 2008 Radek Ošlejšek
FI MU Brno
oslejsek@fi.muni.cz
http://www.fi.muni.cz/~oslejsek/PA103
Pavel Julínek: Použití RUP pro malé SW projekty, diplomová práce, FI MU, 2008
20. 4. 2009
PA103: OO metody návrhu IS © R. Ošlejšek, FI MU Brno
2
Konfigurace RUP
příklad pro malé projekty
20. 4. 2009
PA103: OO metody návrhu IS © R. Ošlejšek, FI MU Brno
3
Přehled fází u malých projektů
• U malých projektů si vystačíme s jedním cyklem (jedním inkrementem)
• Fáze zahájení
– Jedna iterace
– Neprobíhá implementace ani návazné pracovní procesy
– Hlavním výstupem je vize projektu
– Milníkem je schválení vize projektu zadavatelem
• Fáze rozpracování
– 1-2 iterace
– Neimplementují se případy užití, implementační činnost se zaměřuje na
vytvoření stabilního prototypu architektury
• Fáze konstrukce
– Délka jedné iterace asi tři týdny
– Počet iterací závisí na typu projektu
• Fáze předání
– Jen až dvě iterace
– Již se nic neimplementuje
20. 4. 2009
PA103: OO metody návrhu IS © R. Ošlejšek, FI MU Brno
4
Přehled rolí vhodných pro menší firmu
Poznámka: Kompletní RUP definuje na 30 rolí!
20. 4. 2009
PA103: OO metody návrhu IS © R. Ošlejšek, FI MU Brno
5
Popis rolí (I)
• Projektový manažer
– Je zodpovědný za plánování, řízení, organizování a koordinaci projektu.
– Působí jako zástupce naší firmy, často komunikuje se zadavatelem
• Zadavatel
– Zákazník, investor projektu
– Určuje strategické cíle, kterých by mělo být výsledným produktem dosaženo.
– Přebírá a akceptuje výstupy jednotlivých iterací
– Může se jednat i o ostatní zaměstnance – skutečné budoucí uživatele, správce apod.
• Analytik
– Hlavní činností je získávat, porozumět, analyzovat a zaznamenávat požadavky kladené na
systém.
– Často spolupracuje se softwarovým architektem a projektovým manažerem
• Softwarový architekt
– Je zodpovědný zejména za softwarovou architekturu aplikace, způsob implementace a
dodání
– Zajišťuje vývojové nástroje a určuje postupy a standardy použité při vývoji
– Připravuje případná školení
20. 4. 2009
PA103: OO metody návrhu IS © R. Ošlejšek, FI MU Brno
6
Popis rolí (II)
• Test architekt
– Je zodpovědný za tvorbu a realizaci testovací strategie a návrhu testů
• Procesní inženýr
– Specialista na iterativní proces vývoje SW pomocí RUP
– Zabývá se konfigurací procesu vývoje převážně na začátku vývoje
– Pomáhá projektovému manažerovi v prvotním hrubém naplánování projektu
– Často působí jen externě jako konzultant
• Návrhář GUI
– Vytváří vizuální komponenty a grafický design systému
• Programátor
– implementuje a testuje
20. 4. 2009
PA103: OO metody návrhu IS © R. Ošlejšek, FI MU Brno
7
Popis projektu
• SW pro skladovou evidenci umožní v reálné čase evidovat skladové položky a
provádět specifikované operace s těmito položkami (operace uvnitř obchodní
společnosti). Dále bude systém umožňovat objednání zboží (operace mezi
obchodními společnostmi, nebo mezi obchodní společností a běžným
zákazníkem).
• Mezi hlavní cíle projektu patří poskytnutí detailního přehledu o stavu
skladových zásob, snížení počtu chybných operací, časová úspora a možnost
online objednávání skladových položek
20. 4. 2009
PA103: OO metody návrhu IS © R. Ošlejšek, FI MU Brno
8
Fáze zahájení
20. 4. 2009
PA103: OO metody návrhu IS © R. Ošlejšek, FI MU Brno
9
Fáze zahájení (I)
• Projektový manažer jmenuje analytika
• Artefakt vize projektu (analytik)
– Vznik na základě schůzek s managementem, záznamy interview, uspořádání získaných
informací
– Nejprve obsahuje cíle, které mají charakter obchodního záměru, poté se přemění v hlavní
cíle projektu.
– Ústní odsouhlasení vize zákazníkem, analytikem a projektovým manažerem.
– Ukázka z artefaktu vize:
• K udržení stálé úrovně obchodních výsledků je nutné držet krok s technologiemi a knowhow
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.
• Artefakt plán projektu (projektový manažer)
– Po odsouhlasení vize.
– Obsahuje plán první iterace v délce tři týdny, s dalšími iteracemi se nepočítá. Obsah plánu
viz následující aktivity a artefakty.
20. 4. 2009
PA103: OO metody návrhu IS © R. Ošlejšek, FI MU Brno
10
Fáze zahájení (II)
• Artefakty specifikace požadavků, základní modely případů užití, slovník pojmů (analytik)
– Vytvořeno na základě dalších schůzek se zákazníkem.
– Důležité je shodné porozumění požadavkům.
– Pravidelná kontrola ze strany projektového manažera (každý druhý den)
– Specifikace obsahuje funkční i nefunkční požadavky, např.:
• Systém bude přístupný z libovolného web. prohlížeče, a také z mobilního terminálu
Falcon 4420.
• Uživatelé musí dostat odpověď do jedné sekundy, pokud budou k systému přistupovat
prostřednictvím mobilního terminálu, a do dvou sekund přes webový prohlížeč.
• Systém bude postaven na platformě Java a SOAP, data se budou ukládat v relační
DB.
• Aktualizace plánu projektu (projektový manažer)
– Na základě upřesnění ve specifikaci požadavků.
– Zohlednění faktu, že podobný projekt už byl týmem řešen, ale naopak tým nemá zkušenosti
s webovými službami. Proto byly do fáze rozpracování naplánovány dvě iterace, které
budou řešit webové služby. Byl upraven i rozpočet s ohledem na tyto dvě iterace.
20. 4. 2009
PA103: OO metody návrhu IS © R. Ošlejšek, FI MU Brno
11
Fáze zahájení (III)
• Artefakt rizika (analytik, projektový manažer)
1) Projektový tým nemá zkušenosti s webovými službami, hrozí tedy zpoždění. Stupeň rizika:
vysoké. Ošetření: Ve fázi rozpracování proběhne školení. Jsou naplánovány dvě iterace
řešící 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í: Ve fázi rozpracování proběhnou zátěžové testy prototypů.
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í: Řešení bude navrženo ve fázi rozpracování.
• Artefakt testovací strategie (test architekt)
– V této fázi rozvíjeno velmi obecně.
– Návrh typů testů, které musí být v budoucnu detailněji rozpracovány.
• Na konci fáze zahájení obsahuje plán projektu kroky a časový rozvrh jednotlivých fází a také
podrobný plán první iterace fáze rozpracování.
20. 4. 2009
PA103: OO metody návrhu IS © R. Ošlejšek, FI MU Brno
12
Plán projektu - časový rozvrh
20. 4. 2009
PA103: OO metody návrhu IS © R. Ošlejšek, FI MU Brno
13
Plán projektu – podrobný plán 1. iterace
20. 4. 2009
PA103: OO metody návrhu IS © R. Ošlejšek, FI MU Brno
14
Fáze zahájení (IV)
• Artefakt akceptační protokol (projektový manažer)
– Artefakt vize je milníkem fáze zahájení. Po dokončení artefaktu vize, v němž je zahrnut i
rozpočet projektu, se rozhodne, jestli je projekt uskutečnitelný.
– Písemné odsouhlasení.
• Na konci fáze zahájení jsou artefakty projektu v následujícím stavu:
Artefakty ve fázi zahájení Míra dokončení (%)
Vize 100
Plán projektu 35
Slovník pojmů projektu 40
Modely případů užití 20
Specifikace požadavků 20
Rizika 25
Architektura 10
Testovací strategie 10
Plán 1. iterace ve fázi projektování 100
Plán 2. iterace ve fázi projektování 60
Akceptační protokol pro fázi zahájení 100
20. 4. 2009
PA103: OO metody návrhu IS © R. Ošlejšek, FI MU Brno
15
Fáze rozpracování
20. 4. 2009
PA103: OO metody návrhu IS © R. Ošlejšek, FI MU Brno
16
Fáze rozpracování (I)
• Zaměřeno na vývoj kvalitní architektury, která je milníkem.
• Tři iterace, jejichž výstupem je vždy implementovaný prototyp předvedený zákazníkovi.
• Analytik upřesňuje artefakt specifikace požadavků a vytváří podrobné modely případů užití.
Vybírá nejdůležitější případy užití, které jsou použity při tvorbě architektury. Aktualizuje slovník
pojmů.
• Softwarový architekt a analytik vytvářejí artefakt architektura, zejména na základě případů
užití, slovníku pojmů a specifikace požadavků. Architektura je znázorněna pěti pohledy:
logický, implementační a procesní pohled, nasazení a případy užití. Logický pohled obsahuje 4
základní balíky (dva pro prezentační vrstvu terminálu Falcon 4420 a webové rozhraní + balík
aplikační vrstvy + balík datové vrstvy).
• Programátor implementuje prototyp architektury, který následně testuje.
• Návrhář GUI vytváří uživatelské rozhraní.
• Projektový manažer dohlíží na průběh vývoje a v každé iteraci vypracovává podrobný plán
následující iterace.
• Testy jsou prováděny na základě testovací strategie. Bylo provedeno 20 testů, z toho 13
uspělo, 7 odhalilo nedostatky, jejichž vyřešení bylo naplánováno do dalších iterací. Výsledky
testů jsou zachyceny v artefaktu testovací protokol na konci každé iterace.
20. 4. 2009
PA103: OO metody návrhu IS © R. Ošlejšek, FI MU Brno
17
Fáze rozpracování (II)
• Aktualizace artefaktu rizika (projektový manažer, analytik)
1) Projektový tým nemá zkušenosti s webovými službami, hrozí tedy zpoždění. Stupeň
rizika: snížen na nízké, protože školení se zdá být dostatečné a zatím nebyl pozorován
problém s webovými službami.
2) Velké množství uživatelů může znatelně snížit systémovou výkonnost. Stupeň rizika
snížen na nízké, protože výkonnostní testy zatím dopadly dobře
3) Může vznikat nekompatibilita s webovými prohlížeči a specifickými konfiguracemi
počítačů u zákazníka. Riziko eliminováno – vyřešeno ve třetí iteraci fáze projektování.
4) 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í: Spoléhá se na to, že nové významné
funkční požadavky nebudou požadovány.
5) Chyby odhalené při testování mohou zpozdit dodání beta verze systému. Stupeň rizika:
střední. Ošetření: Ošetření chyb bude provedeno v první iteraci fáze realizace.
20. 4. 2009
PA103: OO metody návrhu IS © R. Ošlejšek, FI MU Brno
18
Fáze rozpracování (III)
• Na konci fáze rozpracování je vytvořen podrobný plán první iterace fáze realizace a hrubý plán
druhé iterace. Prototyp architektury i s GUI byl předveden zákazníkovi, byl sepsán akceptační
protokol.
• Na konci fáze rozpracování jsou artefakty projektu v následujícím stavu:
Artefakty ve fázi projektování Míra dokončení (%)
Plán projektu 75
Plán 2. iterace ve fázi projektování 100
Slovník pojmů projektu 80
Specifikace požadavků 90
Modely případů užití 85
Analytické a návrhové modely 70
Architektura 100
Návrh GUI 70
Prototyp architektury 100
Testovací strategie 90
Testovací protokol pro fázi projektování 100
Rizika 50
Plán 1. iterace ve fázi realizace 100
Plán 2. iterace ve fázi realizace 60
Akceptační protokol pro fázi projektování 100
20. 4. 2009
PA103: OO metody návrhu IS © R. Ošlejšek, FI MU Brno
19
Fáze konstrukce
20. 4. 2009
PA103: OO metody návrhu IS © R. Ošlejšek, FI MU Brno
20
Fáze konstrukce (I)
• Zaměřeno hlavně na implementaci systému, milníkem je beta verze systému.
• Dvě iterace. První bude implementovat klíčové požadavky na systém, druhá bude ošetřovat
zbytek požadavků.
• Analytik a softwarový architekt dokončují analytické a návrhové modely.
• Návrhář GUI dolaďuje grafické komponenty systému.
• Prozatím se testování zaměřovalo na technickou proveditelnost řešení. Nyní se zaměřuje na
GUI a na funkčnost systému po implementaci nových funkcí. Narostl počet testovacích případů,
proto jsou nyní použity nástroje pro automatizované testování. Test architekt naplánoval 50
testů, stihlo se jen 45, z toho 5 testů odhalilo drobné chyby. Tyto nedostatky se uvedou v
testovacím protokolu a ošetří se ve fázi nasazení.
• Analytik a programátor průběžně kontrolují, zda vyvíjený systém odpovídá artefaktu specifikace
požadavků. Analytik dále vytváří artefakt dokumentace popisující systém z uživatelského i
administrátorského pohledu. Artefakt vize se v této fázi již nemění, specifikace požadavků a
modely případů užití se mění jen nepatrně.
• Na konci každé iterace je implementovaný systém předveden zákazníkovi a projektový
manažer vyhodnotí akceptační protokol. Na konci fáze konstrukce je systém předám
zákazníkům k beta testování.
• Všechna rizika se stupněm vysoké a střední byla eliminována. Beta verze systému je
připravena a projektový manažer se zákazníkem proto mohou sepsat akceptační protokol pro
tuto fázi.
20. 4. 2009
PA103: OO metody návrhu IS © R. Ošlejšek, FI MU Brno
21
Fáze konstrukce (II)
• Na konci fáze konstrukce jsou artefakty projektu v následujícím stavu. Většina artefaktů už je
kompletně dokončena:
Artefakty ve fázi realizace Míra dokončení (%)
Plán projektu 95
Plán 2. iterace ve fázi realizace 100
Slovník pojmů projektu 95
Specifikace požadavků 100
Modely případů užití 100
Analytické a návrhové modely 100
Návrh GUI 100
Testovací strategie 100
Testovací protokoly pro fázi realizace 100
Rizika 90
Dokumentace 80
Beta verze systému 100
Plán 1. iterace ve fázi nasazení 100
Plán 2. iterace ve fázi nasazení 60
Akceptační protokoly pro fázi realizace 100
20. 4. 2009
PA103: OO metody návrhu IS © R. Ošlejšek, FI MU Brno
22
Fáze předání
20. 4. 2009
PA103: OO metody návrhu IS © R. Ošlejšek, FI MU Brno
23
Fáze předání (I)
• Zaměřeno hlavně na dodání systému a opravu odhalených chyb. Milníkem je finální verze
systému a formální ukončení projektu.
• Dvě iterace. Na začátku první iterace je beta verze dodána do produkčního prostředí k
otestování. Mezitím programátor opravuje drobné chyby odhalené ve fázi konstrukce.
• Beta verze se osvědčila, několik méně závažných chyb je opraveno ještě v této první iteraci.
Na konci první iterace je připraven release systému.
• Druhá iterace je zaměřena na finální doladění systému a provedení závěrečných testů. Z
plánovaných 50 testů uspělo 48, 2 testy odhalily drobné nedostatky, které se nakonec povedlo
odstranit.
• Analytik dokončuje práci na artefaktu dokumentace, která je předána zákazníkovi spolu s
finální verzí systému.
• Na konci fáze předání je projektovým manažerem vytvořen protokol o převzetí systému. Jeho
podpisem je projekt formálně ukončen.
• Projektovým manažerem je vypracován artefakt know-how, který zachycuje zkušenosti z
vývoje a slouží jako interní dokument pro další projekty.
20. 4. 2009
PA103: OO metody návrhu IS © R. Ošlejšek, FI MU Brno
24
Fáze předání (II)
• Na konci fáze předání jsou všechny artefakty kompletně dokončeny:
Artefakty ve fázi nasazení Míra dokončení (%)
Plán projektu 100
Plán 2. iterace ve fázi nasazení 100
Slovník pojmů projektu 100
Dokumentace 100
Release 100
Rizika 100
Testovací protokoly pro fázi nasazení 100
Finální verze systému 100
Akceptační protokoly pro fázi nasazení 100
Protokol o převzetí systému 100
Know-how 100