Vývoj IS 4.blok Vývoj informačních systémů Procesy při vývoji SW Metodiky doc. Ing. Alena Buchalcevová, Ph.D buchalc@vse.cz
Agenda 2 So 29.3.2014 8:00 11:15 306 procesy při vývoji SW referenční model procesů podle ISO/IEC 12207 Integrační model zralosti(cmmi) norma ISO/IEC 29110 pro velmi malé podniky metodiky pro vývoj SW, definice, prvky metodiky kategorizace metodik rigorózní metodiky charakteristika metodika RUP - best practices, fáze metodiky, možnosti přizpůsobení metodiky metodika MMDIS agilní metodiky - charakteristika, principy metodika OpenUP metodika MMSP
Proces vývoje softwaru definuje kdo, co, kdy a jak transformuje požadavky do hotového SW řešení vize a požadavky software 3
Proces vývoje softwaru dvě stránky jazyková UML procesní KatalogZajezdu Zajezd TerminZajezdu AdresaPrechodBydliste Adresa uliceacislo mesto psc stat AdresaTrvBydliste procesy životního cyklu softwaru metodiky např. Unified process Rational Unified Process (RUP) MMDIS, agilní metodiky a další 4
Prvky v oblasti SW procesů Jak zavést procesy? modely životního cyklu procesů Co? referenční modely procesů ISO/IEC 12207 ISO/IEC 15288 CMMI Jak dobře to děláme? posouzení procesů/organizace CMMI ISO/IEC 15504 návody na zavedení standardů zlepšování procesů CMMI ISO/IEC 15504 metodiky 5
MODEL ZRALOSTI CAPABILITY MATURITY MODEL 6
Model zralosti Capability Maturity Model je referenční model vyspělých postupů, který ve vymezených disciplínách posuzuje schopnost vykonávat činnosti, které jsou pro tyto disciplíny stanoveny původně několik zralostních modelů vyvinuty v Software Engineering Institute SEI History of CMMs CMM for Software v1.1 (1993) INCOSE SECAM (1996) Systems Engineering CMM v1.1 (1995) Software CMM EIA 731 SECM Integrated Product v2, draft C (1997) (1998) Development CMM (1997) v1.02 (2000) v1.1 (2002) 7 CMMI for Acquisition v1.2 (2007) CMMI for Development v1.2 (2006) CMMI for Development v 1.3 CMMI for Services v1.2 (2007)
CMMI for Development 8
CMMI for Development (CMMI DEV) v 1.3 je referenční model procesů, které pokrývají celý životní cyklus softwarového produktu (od návrhu, přes vývoj a následnou údržbu) Proces je v CMMI modelu definován jako sada vzájemně provázaných činností, které transformují vstupy na výstupy pro dosažení definovaného účelu. Model CMMI-DEV definuje 22 procesních oblastí. Procesní oblast (process area) je skupina navzájem spojených praktik, které pokud implementujeme kolektivně, naplní množinu cílů, jež jsou podstatné pro zlepšení dané oblasti. 9
10 zdroj: Extreme Programming, Six Sigma, CMMI How they work together A JPMorgan Case study
Dvě reprezentace - dva způsoby zlepšování procesů kontinuální stupňovitý Pro kontinuální zlepšování se používá úroveň způsobilosti (capability level), která je definována jako dosažení zlepšení procesů v určité procesní oblasti. Stupňovitá reprezentace pracuje s úrovní zralosti (maturity level), která představuje stupeň zlepšení procesů v rámci předdefinované množiny procesních oblastí, v nichž jsou dosaženy všechny definované cíle. 11
Dvě reprezentace v CMMI - DEV v. 1.2 zdroj: Mulač. CMMI, Cesta ke zlepšení zralosti organizace IT při budování IS 12 využívá předdefinované množiny procesních oblastí, která definuje cestu organizace ke zlepšení úrovně zralosti maturity level (1-5) umožňuje organizaci vybrat si oblast procesů nebo několik oblastí procesů a zlepšovat procesy v této oblasti úrovně způsobilosti capability level (0-5)
Přehled úrovní způsobilosti a zralosti v CMMI-DEV v 1.3 úroveň kontinuální reprezentace úrovně způsobilosti (capability levels) stupňovitá reprezentace úrovně zralosti (maturity levels) 0 neúplný (Incomplete) 1 vykonávaný (Performed ) úvodní (Initial ) 2 řízený (Managed ) řízená (Managed) 3 definovaný (Defined) definovaná (Defined ) 4 kvantitativně řízená (Quantitatively Managed ) 5 optimalizovaná (Optimizing) 13
Kontinuální reprezentace 14
Kontinuální reprezentace Proces na úrovni způsobilosti 0 - neúplný proces není vykonáván vůbec nebo jen částečně. Na této úrovni nejsou naplněny některé specifické cíle procesu. Proces na úrovni způsobilosti 1 - vykonávaný proces je takový proces, který vytváří pracovní produkty, specifické cíle procesní oblasti jsou splněny, ale proces není institucionalizován. Řízený proces je vykonávaný proces, který je plánován a realizován na základě politik, proces je monitorován, řízen, kontrolován a vyhodnocován na shodu s popisem. Definovaný proces je řízený proces, který je přizpůsobován specifickým podmínkám na základě postupů definovaných v organizaci. 15
Stupňovitá reprezentace 16
Stupňovitá reprezentace Organizational Performance Management úroveň zralosti 5 Causal Analysis and Resolution Organizational Process Performance úroveň zralosti 4 Quantitative Project Management Requirements Development Technical Solution Product Integration Verification Validation Decision Analysis and Resolution úroveň zralosti 3 Organizational Process Focus Organizational Process Definition Organizational Training Integrated Project Management Risk Management Project Planning Project Monitoring and Control 17 Supplier Agreement Management Requirements Management úroveň zralosti 2 Measurement and Analysis Process and Product Quality Assurance Configuration Management engineering project management process management support
Úrovně zralosti 18 úrovně zralosti 1 úvodní Initial 2 řízená Managed 3 definovaná Defined 4 kvantitativně řízená Quantitatively Managed 5 optimalizovaná Optimizing charakteristika softwarové procesy jsou náhodné a chaotické organizace nemají stabilní prostředí pro podporu procesů, reagují pouze na vzniklé problémy. organizace mají definovány a zavedeny postupy řízení projektu, procesy jsou disciplinované a i v případě stresu jsou vykonávány podle popisu procesy jsou dobře definovány a chápány a jsou popsány ve standardech, procedurách, nástrojích a metodách jsou definovány i standardy pro přizpůsobování procesů podle typu projektu procesy jsou řízeny s využitím kvantitativních technik jsou definovány metriky pro vybrané podprocesy, ty jsou měřeny a vyhodnocovány na základě toho je možné předpovídat výkon procesů procesy se neustále zlepšují na základě chápání příčin změn v průběhu procesů
Charakteristiky úrovní 19
Volba reprezentace 20 je možné zvolit jednu z reprezentací, ale i obě kontinuální reprezentace je flexibilnější pokud se CMMI používá pro zlepšení procesů umožňuje zlepšovat různé procesy na různé úrovni umožňuje zaměřit se na pro organizaci nejdůležitější procesy je to novější přístup, nejsou údaje o návratnosti stupňovitá reprezentace představuje systematický, strukturovaný přístup pro zlepšení procesů na bázi referenčního modelu krok po kroku po jednotlivých úrovních dosažení určité úrovně zralosti je východiskem pro další úroveň je vhodnější, pokud nevíte, kde začít a pokud organizace má méně zkušeností se zlepšováním procesů umožňuje zaměřit se na ty procesy, které jsou nutné pro danou úroveň zralosti je to prověřený přístup, řada případových studií demonstrujících návratnost investic
Přínosy CMMI 21 zdroj: Diane L. Gibson, Dennis R. Goldenson, Keith Kost: Performance Results of CMMI - Based Process Improvement
Výsledky zavedení CMMI 22 zdroj: Diane L. Gibson, Dennis R. Goldenson, Keith Kost: Performance Results of CMMI - Based Process Improvement
Výsledky zavedení CMMI 23
24 http://www.sei.cmu.edu/cmmi/casestudies/profiles/pdfs/upload/2011septcmmi-2.pdf
25 http://www.sei.cmu.edu/cmmi/casestudies/profiles/pdfs/upload/2011septcmmi-2.pdf
26 http://www.sei.cmu.edu/cmmi/casestudies/profiles/pdfs/upload/2011septcmmi-2.pdf
27 http://www.sei.cmu.edu/cmmi/casestudies/profiles/pdfs/upload/2011septcmmi-2.pdf
28
Souhrn CMMI Od roku 2006 bylo hlášeno 4846 posouzení Nejrychleji roste počet posouzení v Číně, Španělsku, Brazílii, Argentině, Indii Více než 66% posouzených organizací má méně než 100 zaměstnanců Většina posouzení je na stupni zralosti 2 a 3 Počet posouzení v USA a Číně představuje více než 55% všech posouzení Čína nyní hlásí více posouzení než USA 29 http://www.sei.cmu.edu/cmmi/casestudies/profiles/pdfs/upload/2011septcmmi-2.pdf
MEZINÁRODNÍ NORMY V OBLASTI PROCESŮ ŽIVOTNÍHO CYKLU 30
Norma ISO/IEC 12207 Procesy v životním cyklu softwaru Systems and software engineering Software life cycle processes definuje procesy, činnosti a úkoly, které je třeba provádět při dodávce, vývoji, provozu, údržbě a odstranění softwarového produktu (služby) a také procesy pro definování, řízení a zlepšování procesů životního cyklu softwaru nepředepisuje žádný specifický model životního cyklu softwaru, metodiku vývoje, metody ani techniky norma ISO/IEC 12207 byla vydána v roce 1995, v letech 2002 a 2004 prošla revizemi. V roce 2008 byla vydána revize, která harmonizuje procesy v životním cyklu softwaru s procesy v životním cyklu systému, tedy s normou ISO/IEC 15288:2002 Norma ISO/IEC 12207:2008 definuje 43 procesů v 7 procesních skupinách 31
ISO/IEC 12207:2008 Smluvní procesy Akvizice Dodávka Procesy podporující projekty na úrovni organizace Řízení modelu životního cyklu Procesy v kontextu systému Projektové procesy Plánování projektu Hodnocení a řízení projektu Řízení rozhodování Technické procesy Definice požadavků zainteresovaných Analýza požadavků systému Návrh architektury systému Implementace Softwarově specifické procesy Procesy implementace SW Implementace SW Analýza SW požadavků Návrh SW architektury Detailní návrh SW Procesy podpory SW Řízení dokumentace SW Řízení SW konfigurací Ověřování kvality SW Verifikace SW 32 Řízení infrastruktury Řízení portfolia projektů Řízení lidských zdrojů Řízení kvality Řízení rizik Řízení konfigurací Řízení informací Měření zdroj: ISO/IEC 12207: Systems and software engineering Software life cycle processes, 2008 Integrace systému Testování systému Instalace SW Podpora akceptace SW Provoz SW Údržba SW Odstranění SW Konstrukce SW Integrace SW Testování SW Doménové inženýrství Řízení znovupoužití aktiv Validace SW Review SW Audit SW Řešení problémů Procesy znovupoužití SW Řízení programu znovupoužití
Posuzování zralosti procesů Integrační model zralosti Capability Maturity Model Integration CMMI norma ISO/IEC 15504 definuje Model pro posouzení procesů (Process Assesment Model) 33
ISO/IEC 15504 CL 5 PA 5.1 PA 5.2 Optimalizovaný Inovace procesu Optimalizace procesu CL 4 PA 4.1 PA 4.2 Předvídatelný Měření procesu Kontrola procesu CL 3 PA 3.1 PA 3.2 Zavedený Vymezení procesu Zavedení procesu CL 2 PA 2.1 PA 2.2 Řízený Řízení výkonnosti Řízení pracovních produktů 34 CL 1 PA 1.1 Vykonávaný Výkonnost procesu CL 0 Nekompletní
POSUZOVÁNÍ SW PROCESŮ V MALÝCH PODNICÍCH 35
Malé a střední podniky (MSP) Small-and Medium Sized Enterprise (SME) v USA podnik s méně než 500 zaměstnanci v Evropě podnik s méně než 250 zaměstnanci anebo obratem menším než 50 miliónů euro OECD dělí MSP na mikro podniky (do 10 zaměstnanců), malé podniky (do 50 zaměstnanců), střední podniky (50 až 250 zaměstnanců). v Evropě tvoří mikro podniky 93% všech organizací v USA 56%. 36 A. Buchalcevová,
Vymezení kategorie velmi malých podniků v Evropě 85 % všech SW firem má méně než 10 zaměstnanců, v Kanadě (oblast Montrealu) 80% SW firem má méně než 25 zaměstnanců a více než 50% SW firem méně než 10 zaměstnanců, v Brazílii 70% všech SW firem má méně než 10 zaměstnanců. Na základě těchto průzkumů pracovní skupina WG24 v rámci ISO/IEC JTC1/SC7 definovala kategorii velmi malé podniky jako podniky s méně než 25 zaměstnanci. 37 A. Buchalcevová,
Specifika velmi malých podniků specifické byznys modely a byznys cíle malý podíl na trhu limitované finanční a lidské zdroje odlišná organizační struktura Proto vyžadují odlišný přístup k zavádění a posuzování softwarových procesů. 38 A. Buchalcevová,
Průzkum využívání norem a standardů v malých podnicích realizován pracovní skupinou WG24 v rámci ISO/IEC JTC1/SC7 v roce 2006 cílem bylo získat informace o využívání mezinárodních norem a dalších de facto standardů v malých podnicích a identifikovat problémy, které s jejich aplikací mají průzkumu se účastnilo 392 respondentů z 29 zemí včetně České republiky 228 respondentů, tj. 58% všech respondentů, byly podniky s méně než 25 zaměstnanci tedy VMP 39 A. Buchalcevová
Výsledky průzkumu využívání norem a standardů v malých podnicích více než 70% VMP uvedlo, že vyvíjí životně důležité systémy, systémy kritické pro poslání organizace anebo systémy pro státní správu v kategorii velmi malých podniků bylo certifikováno méně než 18% firem u firem s více než 25 zaměstnanci bylo certifikováno 53% firem 55% používá ISO normy 47% používá modely CMM, CMMI 40 A. Buchalcevová 40
Výsledky průzkumu využívání norem a standardů v malých podnicích/2 otázka proč firma standardy a normy nepoužívá nedostatek zdrojů (28%) standardy nejsou vyžadovány (24%) standardy jsou příliš byrokratické a nejsou k dispozici návody na jejich aplikaci(15%) 74% podniků uvedlo, že je pro ně velmi důležité získat certifikaci 40% podniků má zájem získat ISO certifikaci přes 62% malých podniků by ocenilo návody a příklady, jak zavést standardy a normy 55% vyjádřilo potřebu lehkých a snadno pochopitelných norem doplněných šablonami a vzory 41 A. Buchalcevová 41
Pracovní skupina WG24 v rámci ISO/IEC JTC1/SC7 - cíle pomoci malým organizacím vytvářet kvalitní software, vytvořit množinu profilů, které umožní postupně zlepšovat SW procesy, adresovat specifické potřeby trhu malých organizací vytvořením doménově specifických profilů, poskytnout příklady a snadno pochopitelné návody, poskytnout základnu pro spolupráci malých organizací, vyvinout škálovatelné profily a návody, které umožní velmi malým podnikům dosáhnout shody s normami: ISO/IEC 12207 ISO 9001:2000 posuzovat procesy dle ISO/IEC 15504 42 A. Buchalcevová 42
43 O Connor, R. Introduction to ISO/IEC software engineering standards
Zdroje pro normu ISO/IEC 12207 Systems and software engineering Software life cycle processes ISO/IEC 15504 Process Assesment ISO/IEC 90003 Guidelines for the application of ISO 9001:2000 to computer software 44 A. Buchalcevová
Mezinárodní norma Life-Cycle Profiles for Very Small Entities 45 A. Buchalcevová
Generic Profile Group Four profiles within the Generic Profile Group Profile Group Generic Generic Generic Generic Profile Advanced Intermediate Basic Entry Advanced Intermediate Basic Entry 46 2014-03-28 ISO/IEC 29110
Life-Cycle Profiles for Very Small Entities TR 29110-4.1 Basic Profile 47 A. Buchalcevová
Balíčky nasazení Deployment packages část 5.1 obsahuje návod, jak implementovat softwarové procesy ten je doplněn o tzv. balíčky nasazení pro každý proces obsažený v základním profilu je vytvořen balíček, který vysvětluje: smysl procesu cíl jeho zavedení způsob jeho zavedení doporučuje techniky a metody, které slouží k realizaci procesu obsahuje šablony dokumentů, které je třeba při realizaci procesu vytvářet balíčky budou volně dostupné ke stažení na internetu 48 A. Buchalcevová 48
Současný stav normy Current version: ISO/IEC 29110-2 and ISO/IEC 29110-4-1, published in January 2011. Current version: ISO/IEC TR 29110-1, ISO/IEC TR 29110-3 and ISO/IEC TR 29110-5-1-2, published in 2011 and available from ISO/ITTF as a free download http://standards.iso.org/ittf/publiclyavailablestandards/index.html Current version: ISO/IEC TR 29110-5-1-1:2012 - Management and engineering guide for the Entry profile has been published in English and French in September 2012 and are available from ISO/ITTF as a free download http://standards.iso.org/ittf/publiclyavailablestandards/index.html 49 Deployment packages http://profs.logti.etsmtl.ca/claporte/english/vse/index.html A. Buchalcevová
Zdroje k normě ISO/IEC 29110 http://profs.logti.etsmtl.ca/claporte/english/vse/index.html http://en.wikipedia.org/wiki/iso_29110 http://cs.wikipedia.org/wiki/iso_29110 50
Prvky v oblasti SW procesů Jak zavést procesy? modely životního cyklu procesů Co? referenční modely procesů ISO/IEC 12207 ISO/IEC 15288 CMMI Jak dobře to děláme? posouzení procesů/organizace CMMI ISO/IEC 15504 návody na zavedení standardů zlepšování procesů CMMI ISO/IEC 15504 metodiky 51
METODIKY BUDOVÁNÍ IS 52
Vymezení pojmu metodika Metodika vývoje softwaru Software Development Methodology Metodika vývoje IS IS Development Methodology je definována jako rámec používaný pro strukturalizaci, plánování a řízení procesu vývoje informačního systému. Metodika budování IS/ICT definuje principy, procesy, praktiky, role, techniky, nástroje a produkty používané při vývoji, údržbě a provozu informačního systému, a to jak z hlediska softwarově inženýrského, tak z hlediska řízení. 53 zdroj: VOŘÍŠEK, J. a kol. Principy a modely řízení podnikové informatiky. 1.vyd. Praha: Oeconomica, ISBN 978-80-245-1440-6
Prvky metodiky dimenze fáze role principy činnosti vzory standardy praktiky techniky produkty procesy nástroje metriky 54 prostředí hodnoty - postoje
Stručná historie metodik 70. léta Rozvoj strukturovaných metodik Coad/Yourdon 80. léta Rozvoj komplexních metodik SSADM, Information Engineering 90. léta Rozvoj objektových metodik OMT, Booch, OOSE, Fusion 1995 - Sjednocování objektových metodik, sjednocování notací UML, RUP 2000 - Odlehčování metodik - agilní metodiky FDD, ASD, XP, Crystal, SCRUM 2005 - Konvergence tradičních a agilních metodik tradiční metodiky obohacovány o agilní metody agilní metodiky škálovány na větší a distribuované projekty 55
Metodiky budování IS/ICT metodik je velké množství důvody různé technologie vyžadují různé techniky organizace se liší firemní kulturou každý jedinec je jedinečný každý tým je jedinečný projekty se liší velikostí projekty se liší důležitostí snaha prezentovat se komerční důvody 56
Kritéria pro kategorizaci metodik celý systém versus projekt rozsah metodiky váha metodiky přístup k vývoji způsob vývoje doména 57
Kritérium Celý systém versus projekt většina metodik vývoje SW se týká jednoho projektu například RUP projektové metodiky je třeba řídit vývoj informačního systému v rámci celé organizace globální metodiky - např. MMDIS, Enterprise Unified Process (EUP) rozšíření RUP na úroveň celé organizace 58
Kritérium Rozsah metodiky některé metodiky se zabývají jen návrhem a implementací SW jiné zahrnují i zavedení a údržbu datová organizační funkční/procesní technologická... sponzor vedoucí projektu koncový uživatel analytik návrhář tester dokumentátor 59 expert na doménu UST GAN DAN IMP ZAV PUR fáze životního cyklu projektu
Kritérium Váha metodiky methodology weight velikost metodiky x hustota metodiky velikost metodiky methodology size počet kontrolních prvků obsažených v metodice hustota metodiky methodology specific density míra podrobnosti a těsnost tolerance v metodice, vyžadovaná detailnost a konzistence prvků Podle tohoto kritéria rozlišujeme těžké metodiky lehké metodiky 60
Kritérium Přístup k vývoji a Způsob vývoje Přístup k vývoji strukturované metodiky RAD metodiky objektově orientované metodiky metodiky pro komponentový vývoj metodiky pro vývoj orientovaný na služby Způsob vývoje tradiční metodiky s vodopádovým životním cyklem metodiky pro iterativní a přírůstkový vývoj 61
Kritérium domény EAI BIN SCM ERP CRM ECO OIS CTM WKF ELE Enterprise Application Integration Business Intelligence Supply Chain Management Enterprise Resource Planning Customer Relationship Management e-commerce kancelářské systémy Content Management wokflow e-learning 62
Kritéria pro kategorizaci metodik celý systém versus projekt globální metodiky - v rámci celé organizace - např. MMDIS, Enterprise Unified Process (EUP), projektové metodiky - zabývají se vývojem části IS jeden projekt většina metodik například RUP rozsah metodiky pokrývající celý životní cyklus vývoje - např. MMDIS dílčí metodiky zabývají se jen částí životního cyklu IS - např. jen návrh a implementace podrobnost metodiky těžké metodiky - podrobný popis, rigorózní lehké metodiky - minimálně dostatečná metodika přístup k vývoji strukturované metodiky RAD metodiky objektově orientované metodiky metodiky pro komponentový vývoj metodiky pro vývoj orientovaný na služby 63 způsob vývoje tradiční metodiky s vodopádovým životním cyklem metodiky pro iterativní a přírůstkový vývoj doména
Do jaké míry je možné proces vývoje SW popsat? přesné a podrobné postupy jen principy 64 tradiční metodiky (rigorózní metodiky) agilní metodiky
Tradiční přístupy Agilní přístupy referenční modely procesů modely životního cyklu procesů iterativní a inkrementální model tradiční (rigorózní) metodiky agilní metodiky posouzení procesů/organizace 65
Tradiční - rigorózní metodiky vycházejí z předpokladů : požadavky je možné specifikovat předem, změnám se snažíme zabránit, jsou náročné velké množství meziproduktů ztrácí se cíl vývoje vytvořit fungující SW odpovídající potřebám uživatelů 66
Agilní metodiky lehké metodiky, nepopisují procesy, ale principy, málo dokumentace, dávají přednost osobní komunikaci zaměřeny na ty činnosti, které vytvářejí hodnotu, eliminují činnosti, které hodnotu nepřinášejí inovace a kreativita se rozvíjejí v chaosu, proto málo procesů, spíše praktiky 67
Rational Unified Process RUP dříve řazena mezi rigorózní metodiky, od roku 2003 se do ní vkládají agilní principy a praktiky dnes jde o rámec metodik, který lze škálovat a vytvořit jak těžkou metodiku, tak agilní metodiku RUP je komerční produkt, ale existuje volně dostupná metodika Unified Process dobře definovaný a strukturovaný SW inženýrský proces 68
Klíčové praktiky a principy Best Practices iterativní a inkrementální vývoj správa požadavků použití komponentové architektury vizuální modelování (UML) kontrola a ověřování kvality řízení změn vytvářejte jen to, co je nezbytné Lean procesy, agilita minimalizujte papírovou dokumentaci buďte flexibilní poučte se z chyb prověřujte rizika definujte cíle a metriky pokroku podpořte proces nástroji na vývoj SW 69
Vývoj řízený případy užití (Use Case) případ užití popisuje kompletní a smysluplné služby, které systém poskytuje uživatelům a jiným systémům případy užití řídí práci v průběhu iterace plánování iterace vytvoření a prověření architektury definice testovacích případů a procedur návrh uživatelského rozhraní a vytvoření uživatelské dokumentace Requirements Analysis & Design Use-Case Model Analysis & Design Model realized by Implementation Implementation Model implemented by 70 Test Test Model verified by
Praktika 1: iterativní a inkrementální vývoj Best Practices iterativní a inkrementální vývoj správa požadavků použití komponentové architektury vizuální modelování (UML) kontrola a ověřování kvality řízení změn 71
Problémy vodopádového modelu model předpokládá, že se všechny požadavky specifikují na začátku projektu, iterace jsou možné jen v rámci jedné fáze, případně je možné se vrátit k předchozí fázi, nemáme zpětnou vazbu od zákazníka, pozdní integrace systému, ke které dochází až po naprogramování všech modulů 72
Iterativní vývoj Požadavky Plánování Řízení projektu Analýza a návrh Implementace Testování 73 Ověřování výsledkem každé iterace je spustitelný produkt. Nasazení
Praktika 2: správa požadavků Best Practices iterativní a inkrementální vývoj správa požadavků použití komponentové architektury vizuální modelování (UML) kontrola a ověřování kvality řízení změn 74
Správa požadavků znamená ujistit se že řešíme správný problém vytváříme správný systém systematickým přístupem k získávání organizaci dokumentaci a řízení měnících se požadavků na SW Needs Features SW requirements Aspekty správy požadavků analýza problému pochopení uživatelských potřeb definice systému řízení rozsahu zpřesnění definice systému řízení měnících se požadavků 75
Požadavky Needs Features Problem Space Solution Space Software Requirements 76 Test Scripts Design User Docs
Praktika 3: použití komponentové architektury Best Practices iterativní a inkrementální vývoj správa požadavků použití komponentové architektury vizuální modelování (UML) kontrola a ověřování kvality řízení změn 77
Důvod použití komponentové architektury základ znovupoužitelnosti komponenty architektury základ řízení projektu plánování přidělování lidí dodávka řízení složitosti a integrity vrstvená komponentová architektura Applicationspecific Businessspecific Middleware 78 Systemsoftware
Praktika 4: vizuální modelování Best Practices iterativní a inkrementální vývoj správa požadavků použití komponentové architektury vizuální modelování (UML) kontrola a ověřování kvality řízení změn 79
Proč modelovat vizuálně? zachycuje strukturu i chování ukazuje, jak jednotlivé prvky spolupracují udržuje návrh a implementaci konzistentní skrývá detaily umožňuje přesnou komunikaci 80
Æ Á ¹ ¼ ëçñ º ±â»ç ëàú äã»çñ Ù. ÈÀÏ ü ÀÚ Â Àоî  ¹ ¼ÀÇ Á º ÇØ ç ¹ ¼ ü ¼³Á À» äã»çñ Ù. È é ü  ÀоîµéÀΠüµé ëçø ÀÌ º Î Á ÄÀ» ½ÃÄÑ È é º ÁØ Ù. 1: Doc view request ( ) 9: sortbyname ( ) L 2: fetchdoc( ) 3: create ( ) 6: filldocument ( ) 4: create ( ) 8: fillfile ( ) 5: readdoc ( ) 7: readfile ( ) Window95 ¹ ¼ ü Å óàì¾ðæ.exe Windows NT Windows NT ¹ ¼ ü Áø.EXE Windows95 IBM Mainframe µ ÀÌÅ º À̽º¼¹ö Solaris ÀÀ ë¼¹ö.exe Windows95 ¹ ¼ ü ¾ÖÇà Alpha UNIX Vizuální modelování v UML Use-Case Diagram Class Diagram Statechart Diagram umožňuje více pohledů poskytuje přesnou syntaxi a sémantiku add file Use Case 1 FileMgr DocumentList Document Actor A Use Case 2 Actor B fetchdoc( ) sortbyname( ) add( ) delete( ) FileList flist add( ) delete( ) 1 name : int docid : int numfield : int get( ) open( ) close( ) read( ) sortfilelist( ) create( ) filldocument( ) read() fill the code.. Openning add file [ numberoffile= =MAX ] / flag OFF close file Writing Use Case 3 Reading close file Closing Collaboration 9: sortbyname ( ) Diagram mainwnd : MainWnd 1: Doc view request ( ) rep Repository (from Persistence) name : char * = 0 readdoc( ) readfile( ) read( ) File GrpFile read( ) open( ) create( ) fillfile( ) FileManager Repository DocumentList Deployment Diagram 2: fetchdoc( ) 4: create ( ) gfile : GrpFile Document 8: fillfile ( ) user : Clerk filemgr : FileMgr 3: create ( ) 6: filldocument ( ) GraphicFile File FileList 7: readfile ( ) repository : Repository 5: readdoc ( ) document : Document 81 user mainwnd filemgr : FileMgr document : Document Sequence Diagram gfile repository Component Diagram Forward and Reverse Engineering Target System
Praktika 5: kontrola a ověřování kvality Best Practices iterativní a inkrementální vývoj správa požadavků použití komponentové architektury vizuální modelování (UML) kontrola a ověřování kvality řízení změn 82
Chápejte kvalitu jako základ vývoje, ne až zpětně náklady na opravu SW náklady ztracených příležitostí náklady ztracených zákazníků Oprava softwarových chyb stojí 100 až 1000 krát více, pokud se odhalí a opraví až po nasazení náklady 83 Inception Elaboration Construction Transition
Testujte každou iteraci Iteration 1 Iteration 2 Iteration 3 Iteration 4 modely a implementace Test Suite 1 Test Suite 2 Test Suite 3 Test Suite 4 testy 84 Často bývá levnější najít chybu pomocí testů implementace než kompletní kontrolou návrhu.
Praktika 6: řízení změn Best Practices iterativní a inkrementální vývoj správa požadavků použití komponentové architektury vizuální modelování (UML) kontrola a ověřování kvality řízení změn 85
Co řídíme? bezpečné pracoviště (workspace) pro každého vývojáře automatizované řízení integrace a sestavení (integration/build management paralelní vývoj Workspace Management Parallel Development Řízení změn je víc než check-in a check-out Process Integration REPORT ALERT Build Management 86 Aspekty řízení změn Change Request Management Configuration Status Reporting Configuration Management Change Tracking Version Selection Software Manufacture
Fáze a disciplíny RUP Horizontální osa - dynamický pohled na proces vývoje SW cykly, fáze, Fázeiterace a milníky Disciplíny Obchodní modelování Požadavky Analýza a návrh Implementace Testování Zavedení Konfigurační management Řízení proj ektu 87 Prostředí Vertikální osa - statické hledisko procesu, popis činností, artefaktů, pracovníků a pracovních toků 9 oblastí procesů, které představují logické seskupení činností definovaných v RUP
Iterace je definovaná posloupnost činností, která má stanovený plán a hodnotící kritéria a končí uvolněním (release) produktu plán iterace definuje artefakty, role a činnosti. iterace je měřitelná. iterace je časově omezená iterace je řízena riziky 88
Fáze iterativního vývoje hlavní milníky Inception Elaboration Construction Transition 89 Time cíl Inception: pochopit, co vytvářet vize, high-level požadavky, business case ne detailní požadavky Elaboration: pochopit, jak vytvářet architektura, detailizace většiny požadavků ne detailní design Construction: vytváření produktu fungující produkt, kompletní systémové testy Transition: prověření řešení akceptace
struktura obsahu Životní cyklus v RUP v jedné iteraci, se prochází všechny disciplíny 90 čas
Při plánování se používají různé úrovně podrobnosti Plán projektu hrubý jeden pro celý projekt Plán iterace podrobný příští iterace fáze a milníky co a kdy v rámci každé fáze iterace počet iterací předmět, délka aktuální iterace 91
Délka iterace typicky 2-8 týdnů Co vede k delším iteracím složité vztahy mezi zainteresovanými, zákonná a jiná omezení nezralé nástroje (správa verzí, IDE, testovací nástroje ) velký tým, málo zkušení členové týmu složitá technologie a architektura dlouhý projekt Příklady délky iterací 5 lidí, 1-2 týdny 20 lidí, 3-4 týdny 80 lidí, 8 týdnů 92
Metodika MMDIS principy a koncepty pro řízení informatiky
MMDIS Multidimensional Management and Development of Information System MMDIS metodika od roku 1992 vyvíjena na KIT VŠE návodem na způsob uvažování při vývoji IS/ICT z hlediska kategorizace MDIS 1992 metodika globální spíše lehká bez rozlišení domény pro různé přístupy k vývoji základem - multidimenzionalita, tj. řešení IS/ICT souběžně z různých pohledů MMDIS 1999 MeFIS 2003 94 MBI 2012
Cíl MMDIS cílem je vývoj a provoz integrovaného informačního systému, který optimálně využívá potenciálu dostupných informačních technologií (IT) k maximální podpoře podnikových cílů zajištění efektivní podpory podnikových cílů a podnikových procesů pomocí integrovaných informatických služeb, procesů a zdrojů 95 zdroj Alena prof. Voříšek Buchalcevová
Zásady MMDIS požadované služby a související funkcionalita IS jsou odvozeny od podnikových cílů a od potřeb podnikových procesů IS je realizován jako: komplexní integrovaný systém vytvořený z řady různých komponent a služeb různých dodavatelů, otevřený systém na bázi mezinárodních i podnikových standardů, IS je řízen, rozvíjen a provozován na základě jednotné metodiky a jednotné soustavy pravidel, 96 zdroj Alena prof. Voříšek Buchalcevová
MMDIS - charakteristika, struktura MMDIS skládá se z: 8 základních principů řízení 5 navzájem propojených konceptuálních modelů (konceptů) řízení metodika je otevřená - principy i koncepty se vyvíjejí spolu s vývojem: hospodářského prostředí informačních technologií metod řízení 97 zdroj Alena prof. Voříšek Buchalcevová
Principy MMDIS princip myšlenkový přístup k chápání a analýze problému a s ním spojené zásady (pravidla) řešení problému principy MMDIS jsou aplikovány v konceptech MMDIS principy jsou základem pro metody, techniky a nástroje řízení 8 základních principů metodiky MMDIS: multidimenzionalita integrace vrstvenost flexibilita otevřenost standardizace kooperace měřitelnost (metriky) 98 zdroj Alena prof. Voříšek Buchalcevová
Konceptuální modely MMDIS konceptuální model (koncept) objasňuje, jak chápat řízený systém souvisejí s ním metody, které jsou doporučením, jak daný systém řídit každý z modelů akcentuje jiné dimenze problematiky řízení 5 základních konceptuálních modelů metodiky MMDIS: architektura řízení firmy (model řízení podnikových procesů) integrace strategie, procesů, služeb a zdrojů (model SPSR) integrace oblastí řízení (model systémové integrace) rozvoj integrovaného IS (model tvorby a dalšího rozvoje IS) systém řízení IS (model řízení informatických procesů ve firmě) 99 zdroj Alena prof. Voříšek Buchalcevová
1. Princip: Multidimenzionalita Každý složitý problém je nutné analyzovat, hodnotit, navrhovat řešení a řídit z mnoha různých dimenzí (pohledů) Pravidla multidimenzionality: 1) identifikuj všechny dimenze, které významně ovlivňují řešení problému 2) vyřeš problém nejdříve v rámci každé dimenze 3) integruj dílčí řešení do výsledného řešení 100 zdroj Alena prof. Voříšek Buchalcevová
Dvě základní skupiny dimenzí 101 dimenze, které definují fáze vývoje IS/ICT úroveň integrace IS/ICT, použitá úroveň abstrakce časová dimenze řešení dimenze, které se aplikují v každé fázi vývoje - obsahové dimenze IS/ICT informační/datová (inf), procesní/funkční (pro), ekonomická/finanční (eko), organizační/legislativní (org), pracovní/sociální/etická (pra), softwarová (sw), hardwarová (hw), metodická (met), dokumentační (dok) manažerská (mng). zdroj Alena prof. Voříšek Buchalcevová
P2 P2 provozovaný IS GST IST MtS US GAN n PROJEKTU (některé z nich v provozu) DAN IM ZA PU mng dok P1... Pn... P1 met Pn hw 102 inf sw pro eko org pra zdroj Alena prof. Voříšek Buchalcevová
2. Princip: Integrace Každý složitý systém má mnoho komponent a mnoho vazeb mezi těmito komponentami. Provoz a vývoj systému je spojen s řízením těchto vazeb. Pravidla integrace: 1) identifikuj všechny vazby mezi komponentami, které jsou významné pro řešení problému 2) urči optimální charakteristiky každé vazby 3) uveď vazbu do optimálního stavu a neustále ji v tomto stavu udržuj 103 Příklad: IS se skládá minimálně z komponent - HW, SW, data a lidé. Vazba HW - SW určuje - na kterých počítačích je instalován který software, vazba SW- lidé určuje přístupová práva uživatelů k jednotlivým aplikacím,... zdroj Alena prof. Voříšek Buchalcevová
3. Princip: Vrstvenost Základem řešení problému je opakované použití abstrakce tak, že na každé nižší úrovni abstrakce řešíme zadaný problém pomocí podrobnější rozlišovací úrovně. Vrstva je tvořena objekty vzniklé aplikací stejné úrovně abstrakce. A A V (j+ 1 ) B C D A V (j) A V (j-1 ) 104 zdroj Alena prof. Voříšek Buchalcevová
4. Princip: Flexibilita Požadavky na chování systému a okolí systému se neustále vyvíjejí. Systém proto musí být schopen se těmto změnám přizpůsobovat, a to pokud možno snadno. Pravidla flexibility: 1) identifikuj oblasti očekávaných změn 2) komponenty a vazby systému dotčené očekávanými změnami navrhni jako parametrické 3) sleduj vývoj změn a dle nich upravuj hodnoty parametrů Příklady: možnost definovat účetní osnovu v účetním SW, personifikace uživatelského rozhraní, třídění došlé pošty dle různých kritérií,... 105 zdroj Alena prof. Voříšek Buchalcevová
5. Princip: Otevřenost Rozsáhlejší změny systému nejsou realizovatelné jen změnou parametrů, ale je třeba je řešit novou komponentou. Systém musí být otevřený ve smyslu snadného vyjímání starých a zabudovávání nových komponent od různých výrobců. Pravidla budování otevřeného systému: 1) Architekturu systému navrhni tak, aby se systém skládal z relativně nezávislých komponent 2) Využívej zejména standardizované komponenty, tzn. - při vývoji systému pokud možno nepoužívej komponenty, které díky svému nestandardizovanému rozhraní výrazně zmenšují možnost volby navazujících komponent 106 zdroj Alena prof. Voříšek Buchalcevová
6. Princip: Standardizace ISO9000 ISO 20000 Opakované řešení problému se zjednoduší a zlevní, použijeme-li standardy. Na některá řešení se vztahují závazné standardy - zákony, směrnice, normy. Pravidla standardizace: 1) identifikuj mezi komponentami a jejich vazbami ty, které podléhají závazným standardům 2) aplikuj závazné standardy 3) identifikuj mezi komponentami a jejich vazbami ty, které je vhodné dále standardizovat 4) navrhni a aplikuj standardy pro tyto případy 107 Příklad: finanční SW musí respektovat daňové zákony, je vhodné standardizovat uživatelské rozhraní všech aplikací IS,... zdroj Alena prof. Voříšek Buchalcevová
7. Princip: Kooperace Klíčem úspěchu v globální ekonomice je určit vlastní unikátní znalosti a kompetence, o které se opře podnikatelský záměr a ostatní potřebné znalosti a kompetence získat od obchodních partnerů. Pravidla kooperace: 1) identifikuj svoje unikátní znalosti, kompetence a zdroje 2) identifikuj ostatní potřebné znalosti, služby, zdroje,... 3) integruj interní a externí znalosti, služby a zdroje 4) sdílej znalosti, služby a zdroje se svými partnery Příklad: outsourcing podnikového stravování, outsourcing vývoje, resp. provozu IS/ICT, ASP,... 108 zdroj Alena prof. Voříšek Buchalcevová
8. Princip: Měřitelnost (metriky) Co nelze měřit nelze ani řídit Pravidla měření: 1) identifikuj, co je třeba měřit 2) urči vhodné metriky, způsob získávání a optimální hodnoty 3) měř a vyhodnocuj naměřené hodnoty metrik 4) je-li hodnota mimo určený interval - proveď zásah Příklad: zisk za uplynulý rok, objem služeb realizovaných na trhu v ČR, dostupnost funkcí IS, zákaznická spokojenost, počet koncových stanic,... 109 zdroj Alena prof. Voříšek Buchalcevová
Konceptuální modely MMDIS 1. architektura řízení firmy (model řízení podnikových procesů) 2. integrace strategie, procesů, služeb a zdrojů (model SPSR) 3. integrace oblastí řízení (model systémové integrace) 4. rozvoj integrovaného IS (model tvorby a dalšího rozvoje IS) 5. systém řízení IS (model řízení informatických procesů ve firmě) 110 zdroj Alena prof. Voříšek Buchalcevová
Agilní metodiky lehké metodiky, nepopisují procesy, ale principy, málo dokumentace, dávají přednost osobní komunikaci zaměřeny na ty činnosti, které vytvářejí hodnotu, eliminují činnosti, které hodnotu nepřinášejí inovace a kreativita se rozvíjejí v chaosu, proto málo procesů, spíše praktiky 111
Formy komunikace osobní komunikace písemná dokumentace 112 telefon videonahrávka e-mail
Manifest pro agilní vývoj SW podepsán v únoru 2001 Odhalili jsme lepší způsob vývoje SW, sami jej používáme a chceme pomoci i ostatním, aby jej používali. Z toho pohledu dáváme přednost: individualitám a komunikaci před procesy a nástroji provozuschopnému software před obsažnou dokumentací spolupráci se zákazníkem před sjednáváním kontraktu reakci na změnu před plněním plánu 113
Které metodiky řadíme mezi agilní? Adaptive Software Development (ASD), Dynamic Systems Development Method (DSDM), Feature-Driven Development (FDD), Extreme Programming (XP), Lean Development, SCRUM, Crystal metodiky, Agile Modeling nové metodiky OpenUP MSF for Agile SW development 114
Charakteristika agilních metodik lehké metodiky - minimálně dostatečná metodika nepopisují procesy, ale principy a praktiky zdroj: Alpine Ascents International Inc. obsahují málo dokumentace, dávají přednost osobní komunikaci soustředí se na činnosti, které vytvářejí hodnotu, eliminují činnosti, které hodnotu nepřinášejí přesouvají zodpovědnost za definování požadavků na zákazníka jsou založeny na spolupráci zákazníků a vývojářů 115 využívají individualit a silných stránek lidí
10 hlavních principů agilních metodik 1. Nejvyšší prioritou je včas a kontinuálně dodávat software, který zákazníkům přináší hodnotu. zákazníka zajímá, zda dostane fungující software v každé iteraci a zda poskytovaná funkcionalita uspokojí jeho potřeby, ty je však nutné neustále prověřovat, protože jsou předmětem změny 2. Změnu požadavků je možné provést i v pozdějších fázích vývoje, protože tím může zákazník získat konkurenční výhodu. je třeba realizovat krátké iterace (od dvou týdnů do dvou měsíců) a na jejich konci dodávat fungující software 116
10 hlavních principů agilních metodik 3. Uživatelé a vývojáři spolupracují denně na projektu. koncept specifikace požadavků - na začátku jen hrubé požadavky, které se potom na základě každodenních jednání s uživateli zpodrobňují a mění, přenesení odpovědnosti za projekt na uživatele. 4. Motivovaní jedinci, kteří mají vytvořeny podmínky pro práci a mají podporu vedení, jsou klíčovým faktorem úspěchu projektu. 5. Nejefektivnějším způsobem přenosu informací v rámci vývojového týmu je osobní komunikace. Agilním metodikám bývá vytýkána nedostatečná dokumentace. Dokumentace ale není cílem projektu. Smyslem dokumentace je pochopení problému, kterého se mnohem lépe, rychleji a s menšími náklady dosáhne používáním přímých technik komunikace. 117
10 hlavních principů agilních metodik 6. Primární mírou úspěchu je fungující software. 7. Agilní procesy předpokládají zdravý vývoj. Vývojáři běžně pracují přesčas a o víkendech, což zákonitě snižuje jejich produktivitu. Je třeba vymezit pracovní prostor (cca 40 hodin týdně), v jehož rámci zůstane tým v dobré kondici. 8. Perfektní technické řešení i návrh. Agilní přístupy zdůrazňují kvalitu návrhu, která je nezbytná pro realizaci změn. Návrh není samostatnou etapou, která je plně dokončena před zahájením implementace, ale je to iterativní činnost prováděná v průběhu projektu. 9. Zásadním požadavkem je jednoduchost řešení, tj. umění maximalizovat množství neudělané práce. 118 10. Nejlepší architektury, požadavky a návrhy vznikají ze samoorganizujících se týmů. Tento princip zdůrazňuje kreativitu lidí, častou komunikaci a přizpůsobování metodiky
předpoklady Porovnání rigorózních a agilních metodik rigorózní metodiky agilní metodiky SW procesy lze popsat požadavky je možné definovat předem SW procesy nelze popsat předem jen hrubé požadavky 119 přesně definované procesy, činnosti, artefakty standardní projekty, velké projekty jen generativní pravidla, praktiky a principy výzkumné projekty time-to-market menší týmy
OpenUP nová agilní metodika dostupná pod Eclipse Public License v1.0 minimálně dostatečná, kompletní metodika pro vývoj softwaru, která je snadno přizpůsobitelná a rozšiřitelná vznikla zeštíhlením metodiky Unified Process je založena na: iterativním a inkrementálním modelu životního cyklu případech užití řízení rizik architektuře 120
Stažení metodiky OpenUP Eclipse Process Framework Project (EPF) http://www.eclipse.org/epf/ stažení publikované metodiky OpenUP stáhnout a uložit zip soubor rozbalit otevřít index.htm 121
V metodice je oddělen znovupoužitelný metodický obsah od jeho aplikace v procesu metodický obsah definuje produkty (work products), role (roles), úlohy (tasks) a návody (guidance) procesní obsah vyjadřuje časové hledisko a představuje životní cyklus projektu 122
3 úrovně metodického obsahu 123
Role zainteresovaná strana (stakeholder) analytik (analyst) architekt (architect) vývojář (developer) tester (tester) vedoucí projektu (project manager) kdokoli (any role) 124
Disciplína představuje skupinu úloh (tasks), které se týkají určité oblasti zájmu seskupení úloh do samostatných disciplín představuje efektivní způsob organizování obsahu, který usnadňuje pochopení disciplíny v OpenUP Požadavky Architektura Vývoj Testování Řízení projektu 125
Úlohy, pracovní produkty Úloha je jednotka práce vykonávaná určitou rolí (rolemi) OpenUP definuje 19 úloh v rámci úloh se vytvářejí, modifikují nebo používají pracovní produkty za vytvoření a změnu produktu je odpovědná určitá role produkty jsou předmětem verzování OpenUP definuje 17 produktů, které by se měly v projektu používat 126
Praktiky Open Source Practices for Agile Projects řídící praktiky technické praktiky (softwarově inženýrské) 127
Výsledný proces představuje kompletní a integrovanou procesní šablonu pro specifický typ projektu OpenUP definuje výsledný proces pro iterativní vývoj v rámci 4 fází 128
Metodika OpenUP pokrytí procesů referenčního modelu ISO/IEC 12207 129
Metodika OpenUP - grafické vyjádření hodnot kritérií skupiny Produkt a Lidé minimální a maximální hodnoty kritérií optimální hodnoty kritérií 130
Metodika OpenUP - grafické vyjádření hodnot kritérií skupiny Proces a Podpora 131
Fáze Inception hlavní cíl - pochopit, co máme vytvářet Cílem je definice cílů projektu, požadavků, sestavení harmonogramu projektu (plán iterací), odhad nákladů projektu a definice rizik. Počáteční fáze končí rozhodnutím, zda je projekt za daných požadavků, dostupných technologií, zdrojů a rozpočtu možné realizovat Inception Elaboration Construction Transition zdroj IBM Academic Initiative
Fáze Inception cíle 1. pochopit, co máme vytvářet vize, pro koho je systém a jakou má hodnotu, rozsah systému, úvodní use-case model Identify and Refine Requirements 133 2. identifikovat klíčové požadavky důležité případy užití a nefunkční požadavky Initiate Project Identify and Refine Requirements 3. určit minimálně jedno možné řešení - identifikovat kandidáty na architekturu Agree on Technical Approach 4. definovat náklady, harmonogram, rizika Initiate Project Plan and Manage Iteration
Fáze Inception workflow 134
Fáze Elaboration hlavní cíl - pochopit, jak vytvářet Cílem fáze je definovat architekturu systému. V této fázi by měl být vytvořen prototyp, který ověří všechny architektonické principy a umožní zpřesnění plánu realizace systému. Měly by být definovány komponenty pro opakované použití, které je třeba vyvinout zpodrobnění požadavků podle potřeby (~80%) navrhnout stabilní architekturu definovat, implementovat a otestovat rozhraní hlavních komponent identifikovat závislosti na externích komponentách a systémech implementovat klíčové komponenty cca 10% kódu je implementováno architektura je řízena klíčovými případy užití 20% případů užití řídí 80% architektury navrhnout, implementovat a otestovat klíčové scénáře případů užití Inception Elaboration Construction Transition zdroj IBM Academic Initiative
Fáze Construction hlavní cíl - vytvořit produkt dokončení požadavků a designového modelu design, implementace a testování každé komponenty prototyp systému a zpětná vazba od uživatelů rozvoj architektury denní nebo týdenní buildy pomocí automatizovaného procesu testování každého buildu automatizované regresní testy zátěžové testy pro prověření architektury dodání plně funkčního softwaru (beta release) včetně dokumentace Inception Elaboration Construction Transition zdroj IBM Academic Initiative
Fáze Transition hlavní cíl dodání uživatelům Cílem fáze je zajistit, aby uživatelé mohli systém používat. Součástí této fáze je školení uživatelů, předání dokumentace, vytvoření help desk atd. dodávky bug-fix uvolnění (release) úprava dokumentace úprava popisu uvolnění (release) Inception Elaboration Construction Transition zdroj IBM Academic Initiative
Plán iterace popisuje. vytvářené produkty práci, která má být vykonána délku iterace adresovaná rizika The iteration Plan 138 co kdo dělá metriky zdroj IBM Academic Initiative
Burndown chart 139