Jakou metodiku použít pro konkrétní projekt? Hodnocení a výběr vhodné metodiky pro budování IS Alena Buchalcevová Katedra informačních č technologií, VŠE Praha
Agenda metodika jako nástroj zvýšení úspěšnosti SW projektů vymezení pojmu metodika a kategorizace metodik rigorózní a agilní metodiky postup výběru metodiky pro konkrétní projekt 2
Úspěšnost softwarových projektů dle průzkumů Standish Group 60% úspěšnost definována: projekt dokončen včas, dle rozpočtu, 50% se všemi specifikovanými funkcemi 40% 30% 20% 10% 0% 1994 1996 1998 2000 2002 2004 2006 úspěšný 16% 27% 26% 28% 34% 29% 35% neúspěšný 31% 40% 28% 23% 15% 18% 19% s problémy 53% 33% 46% 49% 51% 53% 46% zdroj:chaos Summary 2008 3
Deset kritických faktorů úspěchu projektu 1. nedostatečné zapojení uživatelů do projektu 2. podpora p vedení 3. jasné byznys cíle 4. optimalizace rozsahu projektu 5. agilní procesy 6. zkušenosti s řízením projektu 7. standardní SW infrastruktura 8. dostupnost kvalifikovaných pracovníků 9. formální metodika 10. nástroje zdroj: [JOHNSON,2006]) 4
Metodické zdroje v oblasti procesů budování IS/ICT 5
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í. zdroj: VOŘÍŠEK, J. a kol. Principy a modely řízení podnikové informatiky. 1.vyd. Praha: Oeconomica, ISBN 978-80-245-1440-6 6
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 7
Kategorizace metodik zaměření metodiky globální metodiky v rámci celé organizace např. MMDIS, Enterprise Unified Process projektové metodiky týkají se jednoho projektu například RUP rozsah metodiky pokrývající í celý životní cyklus vývoje dílčí metodiky jen část životního cyklu IS např. jen návrh a implementace váha metodiky těžké metodiky podrobný popis, rigorózní lehké metodiky minimálně i ě dostatečná t č metodika přístup k řešení základní paradigma, na kterém je metodika založena strukturované metodiky objektově orientované metodiky metodiky pro komponentový vývoj metodiky pro vývoj orientovaný na služby typ řešení vývoj nového řešení (na zelené louce) integrace řešení rozvoj a rozšíření řešení (upgrade) customizace a implementace typového řešení užití řešení doména představuje předmětnou oblast, na jejíž podporu je IS vytvářen obecný software Content Management Business Intelligence e-commerce a další 8
Tradiční a agilní přístupy Tradiční přístupy Agilní přístupy referenční modely procesů modely životního cyklu procesů iterativní ti a inkrementální model agilní metodiky tradiční (rigorózní) metodiky posouzení procesů/organizace 9
Důvod vzniku agilních metodik reakce na problémy při použití tradičních metodik v současných projektech turbulentní ekonomické prostředí mění se požadavky na IS nové technologie a nové aplikační domény IS je třeba zavést velmi rychle tradiční metodiky jsou postaveny na písemné formě komunikace - vytvářejí velké množství meziproduktů, a tak se ztrácí hlavní cíl vývoje vytvořit fungující software odpovídající potřebám uživatelů vodopádový model životního cyklu 10
Agilní metodiky jsou založeny na iterativním vývoji vycházejí z přesvědčení, že jedinou cestou, jak prověřit správnost navrženého systému, je vyvinout jej co nejrychleji, předložit zákazníkovi a na základě zpětné vazby jej upravit iterativní vývoj s velmi krátkými iteracemi dřívější iterace adresují největší rizika výsledkem každé iterace je spustitelný produkt každá iterace zahrnuje integraci a testování Iterace 1 Iterace 2 Iterace 3 11
Manifest agilního vývoje softwaru podepsán v únoru 2001 Odhalili jsme lepší způsob vývoje softwaru, sami jej používáme a chceme pomoci i ostatním, aby jej používali. Zt toho pohledu dáváme á přednost: ř individualitám a komunikaci před procesy a nástroji provozuschopnému softwaru 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 12
Charakteristika agilních metodik lehké metodiky - minimálně dostatečná metodika nepopisují procesy, ale principy a praktiky 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ářů využívají individualit a silných stránek lidí zdroj: Alpine Ascents International Inc. 13
Zástupci agilních metodik původní Dynamic Systems Development Method (DSDM) Adaptive Software Development ( ASD) Feature Driven Development (FDD) Extrémní programování (Extreme Programming, XP) Lean Development Scrum Crystal metodiky Agilní modelování (Agile Modeling) nové Microsoft Solutions Framework (MSF) for Agile Software Development OpenUP 14
Dynamic Systems Development Method (DSDM) vznikla ve Velké Británii v první polovině 90 let rozvoj metodiky a její rozšiřování - DSDM konsorcium http://www.dsdm.org má ze všech agilních metodik nejlépe propracovaný systém školení a kvalitní dokumentaci je populární jak v Evropě, tak v USA představuje rozšíření praktik rychlého vývoje aplikací (RAD) dynamic - reprezentuje schopnost přizpůsobit se změnám vprůběhu procesu vývoje. zaměřena zejména na softwarově inženýrskou oblast, méně se zabývá oblastí řízení kombinuje přístup rychlého vývoje aplikací (Rapid Application Development) s objektově orientovaným vývojem základní technikou používanou při analýze a návrhu je prototypování přínosem metodiky je řízení jejího rozvoje, propagace, školení a implementace. 15
Adaptive Software Development (ASD) představuje filosofické zázemí pro agilní metodiky autorem je Jim Highsmith je silně ovlivněna teorií komplexních adaptivních systémů. Změnám, které nastávají, se nesmíme bránit, ale musíme se na ně adaptovat dynamický cyklus Speculate Collaborate Learn. zdroj Highsmith, J.: Retiring Lifecycle Dinosaurs, Software Testing &Quality Engineering, July/August 2000. 16
Lean development autorem je Robert Charette je aplikací principů p známých jako Lean Manufacturing a Total Quality Management na oblast vývoje softwaru je založena na konceptu dynamické stability schopnost přizpůsobit se rychle a efektivně požadavkům (dynamická část) je spojena se schopností vytvářet stabilní, neustále se zlepšující vnitřní procesy, které mají obecnou platnost t a přizpůsobují ů se širokému okruhu produktů. cílem je vytváření softwaru tolerantního ke změnám střetinovou lidskou prací, s třetinovým časem, s třetinou investic do nástrojů a metod, střetinovou námahou přizpůsobit se novému tržnímu prostředí 17
Feature-Driven Development (FDD) autory jsou Jeff De Luca a Peter Coad, agilní metodika, která zachovává procesní řízení a zdůrazňuje úlohu modelování při vývoji je založena na iterativním vývoji, který je řízen užitnými vlastnostmi produktu (feature-driven) di zdroj: Feature-Driven Development. Dostupný z WWW: http://www.step-10.com/process/fdd/index.html 18
Praktiky FDD doménové objektové modelování (Domain Object Modeling), vývoj podle užitných vlastností (Developing by Feature), užitná vlastnost(feature) malá funkce (realizovatelná během 2 týdenní iterace) s hodnotou pro zákazníka vyjádřená ve formátu <akce> <výsledek> <objekt> vlastnictví tříd (Individual Class Ownership), týmy pro užitné vlastnosti (Feature Teams), inspekce (Inspections) pravidelné buildy (Regular Builds), řízení konfigurací (Configuration Management), reporting/viditelnost výsledků (Reporting/Visibility of Results). 19
Crystal metodiky autorem je Alistair Cockburn rodina metodik, které jsou určeny ypro různé typy projektů výběr vhodné metodiky z rodiny se provádí na základě : velikosti projektu, kterou určuje počet členů týmu (osa x), důležitosti systému (osa y) třetí rozměr určuje hledisko, pro které je metodika optimalizována (produktivita, trasovatelnost apod.) jednotlivé metodiky jsou pojmenovány podle barev, nejlehčí metodika je nazvána Clear, potom následuje Yellow, Orange, Red, Maroon, Blue, Violet atd. Například Orange je D40 metodika - je určena pro týmy do 40 lidí, kteří sedí v jedné budově a pracují na projektu, který může znamenat větší ztrátu peněz. 20
Crystal metodiky zdroj: Cockburn,A.:Crystal, Crystal, the Manifesto, the Methodology Framework 21
Scrum autory jsou Ken Schwaber, Jeff Sutherland a Mike Beedle framework pro řízení projektu vývoj SW není definovaný proces, který je možné přesně popsat a opakovat, ale empirický proces empirický proces vyžaduje odlišný styl řízení - vyžaduje konstantní monitorování a adaptaci implementace empirického procesu má 3 pilíře viditelnost do procesu inspekce adaptace Product Owner Team ScrumMaster spravuje seznam požadavků (Product Backlog) tak, aby maximalizoval hodnotu projektu reprezentuje všechny zainteresované kros-funkční skupina lidí, kteří se sami řídí tak, aby v každém sprintu dodali fungující SW zodpovídá za Scrum proces, jeho správnou implementaci a maximalizaci užitku 22
Scrum zdroj: Scrum Tutorial, Advanced Development Methods 23
Sprint sprint je 30 denní iterace na začátku sprintu se koná Sprint Planning Meeting trvá max. 8 hodin, cíl - definovat Sprint Backlog první 4 hodiny - Product Owner prezentuje požadavky nejvyšší priority v Product Backlogu, tým se dotazuje na obsahu, účel, význam požadavků, nakonec vybere požadavky nejvyšší priority do Sprint Backlogu druhé 4 hodiny tým plánuje Sprint jde o plán předběžný, který se neustále v průběhu sprintu upravuje každý den se koná Scrum Meeting 15 min. na konci sprintu se koná Sprint review e meeting trvá 4 hodiny tým prezentuje, co bylo vyvinuto Sprint retrospective meeting - zlepšení procesu a praktik 24
Scrum Stand up meeting umožňuje monitorovat stav projektu, koná se vždy ve stejný čas na stejném místě trvá méně než 30 minut (cílem je 15 minut) vede jej j Scrum master účastní se všichni členové týmu (vývojáři, uživatelé, testeři,..) navštěvují je manažeři, aby věděli o stavu, ale aktivně se neúčastní slouží ke zjištění problémů, ale ne k jejich řešení každý účastník musí zodpovědět 3 otázky co udělal od poslední scrum porady co bude dělat do příští scrum porady jaké překážky mu stojí v cestě 25
Extrémní programování XP metodika určená zejména pro malé až středně velké týmy 2 10 programátorů, které vyvíjejí software, jehož zadání není jasné a nebo se mění autory metodiky jsou Kent Beck, Ward Cunningham a Ron Jeffries popis metodiky - Beck, K.: Extrémní programování, Grada, 2002, ISBN 80-247-0300-9 hodnoty XP komunikace jednoduchost zpětná vazba odvaha 26
Praktiky XP 27
Praktiky XP plánovací hra na začátku je stanoven hrubý plán, po každé iteraci se zpřesňuje, zpřesňuje jej zákazník na základě odhadů programátorů nejdříve se řeší ty nejdůležitější požadavky jde o kombinaci byznys priorit a technologických možností malé verze iterativní, přírůstkový vývoj co nejmenší řešení v jedné iteraci pokud se neustále integruje, jsou náklady na uvolnění ě nové verze minimální nepřetržité testování snižuje chybovost, takže po uvolnění verze není nutné dlouho testovat 28
Praktiky XP metafora vývoj je řízen metaforou příběhem, jak má systém fungovat pomáhá chápat prvky systému a vztahy mezi nimi něco jako architektura testování automatizované testy testování před kódováním refaktorizace změna struktury systému bez změny jeho chování pro zjednodušení, zpřehlednění, zajištění flexibility 29
Praktiky XP jednoduchý návrh nejjednodušší možné řešení žádné budoucí požadavky správný SW má v každém okamžiku tyto vlastnosti: všechny testy fungují neobsahuje duplicitní logiku obsahuje důležité hlášky má co nejméně ě tříd a metod jednoduchý návrh odpovídá hodnotám komunikace složitý návrh se těžko sděluje zpětná vazba ověření správnosti realizací a otestováním odvaha nyní stačí, až bude potřeba víc, dodělá se 30
Praktiky XP párové programování programují dva programátoři na1počítači ten, který má klávesnici a myš přemýšlí o implementaci dané metody, druhý přemýšlí strategicky jaké další testy napsat jak zjednodušit implementaci páry jsou dynamické a během dne se mění povzbuzuje komunikaci protože se páry mění, informace se rozšiřuje v týmu vyšší kvalita kódu kontrola, že se nevrátíme ke starým praktikám (nebudeme psát testy, nebudeme refaktorovat) 31
Praktiky XP společné vlastnictví kódu každý může provést jakoukoli změnu kdekoli v systému nepřetržitá integrace integrace a buildy několikrát denně udržitelný vývoj 40 hodin týdně, maximálně 1 týden práce přesčas, dovolená zákazník na pracovišti uživatel je stále k dispozici odpovídá na dotazy definuje priority požadavků standardy pro psaní zdrojového kódu všichni dodržují konvence pro psaní zdroj. kódu, které jsou zaměřeny na komunikaci prostřednictvím zdroj. kódu nutný předpoklad pro párové programování a společné vlastnictví kódu 32
Agilní modelování autor Scott Ambler umožňuje překonat mýty o modelování lehká metodika pro efektivní modelování postavená na prověřených modelovacích technikách jde o kolekci praktik - doporučení, jak efektivně modelovat je možné ji použít v rámci jiných metodik (RUP, XP, SCRUM, FDD,... 33
OpenUP minimálně dostatečná, ale kompletní metodika pro vývoj SW přizpůsobitelná a rozšiřitelná zeštíhlený Unified Process založena na iterativním a inkrementálním životním cyklu, případech užití, řízení rizik a architektuře oddělení znovupoužitelného metodického obsahu od jeho použití v procesu nástroj Eclipse Process Framework Composer umožňuje snadnou konfiguraci metodiky ve formě metodických doplňků a balíčků 34
Porovnání tradičních a agilních metodik tradiční metodiky agilní metodiky vých hodiska SW procesy lze standardizovat požadavky je možné definovat předem SW procesy není účelné standardizovat předem ř jen hrubé požadavky přesně definované procesy, činnosti, artefakty jen generativní pravidla, praktiky a principy standardní projekty velké projekty výzkumné projekty rychlé projekty menší týmy 35
Předpoklady agilního vývoje zákazník je součástí týmu a je k dispozici denně malý tým max. 8 vývojářů v jedné místnosti vysoká kvalita vývojářů dokumentace a modely nehrají při vývoji klíčovou roli požadavky a prostředí se mění v průběhu vývoje vývojáři mají zkušenosti potřebné k přizpůsobování procesů cílem není znovupoužitelnost t Omezení agilního vývoje omezená podpora pro distribuované prostředí vývoje omezená podpora subdodavatelů omezená podpora pro vytváření znovupoužitelných artefaktů omezená podpora pro vývoj ve velkém týmu omezená podpora pro vývoj kritických aplikací omezená podpora pro vývoj velkého komplexního softwaru 36
Současný stav používání agilních metodik ve světě Agile Alliance, řada konferencí nejvýznamnější konference Agile průzkumy zaměřené na používání agilních metodik průzkum organizovaný Agile Alliance a VersionOne Scott Ambler realizoval v r. 2006, 2007 a 2008 průzkum míry používání agilních metodik rok provádění průzkumu počet respondentů agilní techniky agilní metodiky nejpopulárnější metodiky 2006 4232 Dr. Dobb s Journal and Software Development mailing lists 65 % 41 % XP (954) FDD (502) Scrum (460) 2007 781 69 % Dr. Dobb s Journal 2008 642 69 % Dr. Dobb s Journal zdroj: Results from Scott Ambler s March 2006 Agile Adoption Rate Survey, Results from Scott Ambler s March 2007 Agile Adoption Survey, Results from Scott Ambler s February 2008 Agile Adoption Survey posted at www.agilemodeling.com/surveys/ 37
The state of Agile Development 2009 průzkum realizovaný VersionOne 2570 účastníků z 88 zemí zdroj: The state of Agile Development 2009, VersionOne 38
The state of Agile Development 2009 zdroj: The state of Agile Development 2009, VersionOne 39
The state of Agile Development 2009 zdroj: The state of Agile Development 2009, VersionOne 40
Současný stav používání agilních metodik v České republice průzkum používání agilních metodik v ČR v roce 2006 většina firem veřejné metodiky nepoužívá a nahrazuje je firemními standardy nebo projekty řídí ad-hoc rozsah znalostí o metodikách, zejména agilních je v praxi nízký Znalost agilních metodik XP 5% jiná 5% Použití metodik pokročilá 19% žádná 19% RUP 19% žádná 14% základní 24% nízká 38% firemní standardy 57% v posledním době se situace mění - začínají se používat agilní metodiky zejména Scrum a Extrémní programování založeno Agilní konsorcium 41
Nástroje pro agilní vývoj agilní vývoj nevyžaduje nutně používání nástrojů v posledních letech - řada nástrojů, které podporují agilní vývoj řízení projektu nástroje pro kontinuální integraci a sestavování produktu automatizované testy Rally Software Development, VersionOne (produkt V1) ThoughtWorks (produkt Mingle) IBM Rational Method Composer Eclipse Process Framework Composer Rational Team Concert Express postaven na nové platformě Jazz 42
Zlatá střední cesta původně byly agilní metodiky velmi antagonistické vůči tradičním přístupům postupně se ukazuje, že je možné oba přístupy kombinovat tradiční metodiky je možné odlehčit a aplikovat v jejich rámci některý z agilních přístupů na druhé straně je snaha použít agilní metodiky na větší projekty projekty vyvíjené distribuovanými týmy projekty větší důležitosti proto je třeba je více formalizovat a doplnit nové praktiky 43
Výběr metodiky metodika použitá na projektu patří mezi 10 kritických faktorů úspěšnosti projektu metodik je velké množství, liší se svými vlastnostmi a použitelností pro určité typy projektů význam výběru metodiky pro konkrétní projekt 44
Návrh systému hodnocení a výběru metodik METES Methodology Evaluation System 45
Kritéria systému METES Výběrová kritéria Kritéria skupiny Produkt Doplňková kritéria Kritéria skupiny Proces Rozsah Důležitost produktu Model životního cyklu Délka projektu Role Stálost požadavků Podrobnost popisu procesu Znovupoužitelnost Dokumenty Velikost řešení Metriky Řízení kvality Kritéria skupiny Lidé Kritéria skupiny Podpora Zkušenost manažera projektu Celistvost zdrojů Dostupnost Kvalifikace členů týmu Podpora metodiky SW nástroji Motivace členů týmu Podpora zavedení metodiky Dostupnost uživatelů Přizpůsobení metodiky Velikost týmu Výuka na vysokých školách Rozmístění Školení a certifikace Lokalizace 46
Hodnocení metodik 6 vybraných současných metodik Rational Unified Process (RUP) OpenUP Feature driven development (FDD) Scrum Extrémní programování (XP ) Microsoft Solutions Framework for CMMI Process Improvement každá metodika je krátce charakterizována jsou ohodnocena jednotlivá kritéria výsledky hodnocení jsou znázorněny graficky BUCHALCEVOVÁ, Alena. Metodiky budování informačních systémů. 1. vyd. Praha : Oeconomica, 2009. 206 s. ISBN 978-80-245-1540-3. 47
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í 48
Metodika OpenUP grafické vyjádření hodnot kritérií skupiny Proces a Podpora 49
Metodika OpenUP pokrytí procesů referenčního modelu ISO/IEC 12207 50
Postup výběru metodiky 3 kroky 1. stanovení hodnot výběrových kritérií (Produkt a Lidé) pro daný projekt 2. výběr použitelných metodik pro daný projekt hodnoty klíčových výběrových ý kritérií projektu musí být v rámci minimální a maximální hodnoty kritéria pro metodiku 3. výběr doporučené metodiky na základě velikosti odchylek hodnot projektových výběrových kritérií od optimálních hodnot a hodnot doplňkových kritérií 51
Výběr metodiky pro projekt SampleIS krok 1 stanovení hodnot výběrových kritérií pro daný projekt Projekt SampleIS hodnoty kritérií Důležitost produktu 2 Délka projektu 3 Stálost požadavků 2 Znovupoužitelnost 4 Velikost řešení 3 Zkušenost manažera projektu 1 Kvalifikace členů týmu 1 Motivace členů týmu 1 Dostupnost uživatelů 3 Velikost týmu 0 Rozmístění 0 52
Výběr metodiky pro projekt SampleIS krok 2 posouzení metodiky RUP výběr použitelných metodik pro daný projekt hodnoty klíčových výběrových kritérií projektu musí být v rámci minimální a maximální hodnoty kritéria pro metodiku za vzdálenost vážené abs. RUP RUP RUP RUP Projekt hranicemi od optim. hodnoty váhy min max opt SampleIS extrémů hodnoty vzdáleností Důležitost produktu 0,219 2 5 5 2 0 3 0,656 Délka projektu 0,133 2 5 4 3 0 11 0133 0,133 Stálost požadavků 0,041 2 5 2 2 0 0 0 Znovupoužitelnost 0,033 0 4 3 4 0 1 0,033 Velikost řešení 0,039 2 5 5 3 0 2 0,077 Zkušenost manažera projektu 0,015 0 4 4 1 0 3 0,045 Kvalifikace členů týmu 0,020 0 5 5 1 0 4 0,081 Motivace členů týmu 0,020 0 4 4 1 0 3 0,059 Dostupnost uživatelů 0,200 0 4 4 3 0 1 0,2 Velikost týmu 0,169 2 5 5 0 2 5 0,843 Rozmístění 0,113 0 5 5 0 0 5 0,565 1,000 2,692 53
Výběr metodiky pro projekt SampleIS krok 2 - posouzení metodiky OpenUP výběr použitelných metodik pro daný projekt hodnoty klíčových výběrových kritérií projektu musí být v rámci minimální a maximální hodnoty kritéria pro metodiku OpenUP váhy Open UP min Open UP max Open UP opt Projekt SampleIS za hranicemi extrémů vzdálenost vážené abs. od optim. hodnoty hodnoty vzdáleností Důležitost produktu 0,219 0 2 2 2 0 0 0 Délka projektu 0,133 0 4 2 3 0 1 0,133 Stálost požadavků 0,041 1 5 1 2 0 1 0,041 Znovupoužitelnost 0,033 0 3 2 4 1 2 0,066 Velikost řešení 0,039 0 3 2 3 0 1 0,039 Zkušenost manažera projektu 0015 0,015 0 4 4 1 0 3 0,045 Kvalifikace členů týmu 0,020 0 5 5 1 0 4 0,081 Motivace členů týmu 0,020 0 4 4 1 0 3 0,059 Dostupnost uživatelů 0,200 0 3 3 3 0 0 0 Velikost týmu 0,169 0 2 2 0 0 2 0,337 Rozmístění 0,113 0 1 1 0 0 1 0,113 1,000 0,914 54 není klíčové výběrové kritérium
Výběr metodiky pro projekt SampleIS krok 2 - shrnutí, krok 3 seznam použitelných metodik OpenUP Krok 3 výběr doporučené č metodiky na základě velikosti odchylek hodnot projektových výběrových kritérií od optimálních hodnot pro metodiku čím nižší hodnota, tím lepší Projekt SampleIS za hranicemi kličových kritérií vážený součet abs. hodnot vzdáleností od optima RUP 2,692 OpenUP 0,914 FDD 1,644 Scrum 1,935 XP 1,428 MSF 2,733 55
Výběr metodiky pro projekt SampleIS krok 3 - výběr doporučené metodiky posouzení hodnot doplňkových kritérií váha kritéria RUP RUP vážený OpenUP OpenUP vážený FDD vážený Scrum Scrum vážený XP XP vážený MSF CMMI MSF CMMI vážený Kritérium FDD Rozsah 0,051 4 0,205 3 0,153 3 0,153 2 0,102 1 0,051 5 0,256 Model životního cyklu 0,089 4 0,355 5 0,444 5 0,444 5 0,444 5 0,444 4 0,355 Role 0,026 3 0,079 2 0,053 2 0,053 2 0,053 1 0,026 3 0,079 Podrobnost popisu procesu 0,059 5 0,296 5 0,296 3 0,178 0 0,000 0 0,000 5 0,296 Dokumenty ou 0,027 4 0,106 3 0,080 3 0,080 1 0,027 1 0,027 4 0,106 Metriky 0,030 3 0,089 1 0,030 3 0,089 2 0,060 2 0,060 3 0,089 Řízení kvality 0,038 5 0,192 2 0,077 2 0,077 2 0,077 2 0,077 5 0,192 Celistvost zdrojů 0,195 5 0,975 5 0,975 2 0,390 2 0,390 2 0,390 4 0,780 Dostupnost t 0195 0,195 2 0390 0,390 5 0975 0,975 1 0195 0,195 1 0195 0,195 1 0195 0,195 3 0585 0,585 Podpora metodiky SW nástroji 0,106 5 0,530 4 0,424 1 0,106 4 0,424 4 0,424 3 0,318 Podpora zavedení metodiky 0,038 5 0,192 0 0,000 2 0,077 2 0,077 2 0,077 2 0,077 Přizpůsobení metodiky 0,038 5 0,192 5 0,192 3 0,115 4 0,154 3 0,115 4 0,154 Výuka na vysokých školách 0,023 5 0,115 5 0,115 4 0,092 4 0,092 5 0,115 2 0,046 Školení a certifikace 0,025 5 0,124 4 0,099 4 0,099 4 0,099 5 0,124 5 0,124 Lokalizace 0,059 0 0,000 0 0,000 0 0,000 0 0,000 0 0,000 0 0,000 3840 3,840 3912 3,912 2148 2,148 2192 2,192 2124 2,124 3457 3,457 56
Děkuji za pozornost