Jakou metodiku použít pro

Jakou metodiku použít pro konkrétní projekt? Hodnocení a výběr vhodné metodiky pro budování IS

Alena Buchalcevová K t d iinformačních Katedra f č í h ttechnologií, h l ií VŠE P Praha h

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 úspěšnost definována: 60%

• projekt dokončen včas, • dle rozpočtu, • se všemi specifikovanými

50%

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 podpora p vedení 2. p 3. jasné byznys cíle p rozsahu p projektu j 4. optimalizace 5. agilní procesy p j 6. zkušenosti s řízením projektu 7. standardní SW infrastruktura p kvalifikovaných ý p pracovníků 8. dostupnost 9. formální metodika j 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 D l t Methodology M th d l je definována jako rámec používaný pro strukturalizaci, plánování a řízení procesu vývoje informačního systému. 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, té a to t jak j k z hlediska hl di k softwarově ft ě inženýrského, tak z hlediska řízení. zdroj: VOŘÍŠEK VOŘÍŠEK, J. J a kol. 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 h

ƒ ƒ

váha metodiky

ƒ ƒ

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í představuje předmětnou oblast, oblast na jejíž podporu je IS vytvářen ƒ obecný software ƒ Content Management ƒ Business Intelligence ƒ e e-commerce commerce a další

doména

metodiky t dik pokrývající k ý jí í celý lý životní ži t í cyklus kl vývoje ý j dílčí metodiky – jen část životního cyklu IS např. jen návrh a implementace těžké metodiky – podrobný popis, rigorózní l hké metodiky lehké t dik – minimálně i i ál ě d dostatečná t t č á metodika t dik

8

Tradiční a agilní přístupy Tradiční přístupy

Agilní přístupy

referenční modely procesů

iterativní it ti í a iinkrementální k tál í model

modely životního cyklu procesů

agilní metodiky

tradiční (rigorózní) metodiky posouzeníí procesů/organizace ů/ i

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í p }

• •

ƒ

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ů, i d ktů a tak t k se ztrácí t á í hlavní hl í cílíl vývoje ý j – vytvořit fungující software odpovídající potřebám uživatelů

vodopádový p ý model životního cyklu y

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 ý j 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

11

Iterace 3

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, ostatním aby jej používali používali. Z toho t h pohledu hl d dá dáváme á přednost: ř d t }

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 j málo dokumentace, dávají j p přednost ƒ obsahují osobní komunikaci ƒ soustředí se na činnosti, které vytvářejí hodnotu eliminují činnosti, hodnotu, č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í

13

zdroj: Alpine Ascents International Inc.

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 C t l metodiky t dik • 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ě, 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 v prů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. p 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 p

ƒ

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 j aplikací p p principů p známých ý jako j Lean Manufacturing g a Total ƒ je 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 l t t a přizpůsobují ři ů b jí se ši širokému ké okruhu k h produktů. d ktů ƒ cílem je vytváření softwaru tolerantního ke změnám s třetinovou lidskou prací, prací s třetinovým časem, časem s třetinou investic do nástrojů a metod, s tř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, g metodika,, která zachovává p procesní řízení a zdůrazňuje j ƒ agilní úlohu modelování při vývoji ƒ je založena na iterativním vývoji, který je řízen užitnými vlastnostmi produktu d kt (feature-driven) (f t di )

zdroj: Feature Feature-Driven Driven Development. Development Dostupný z WWW: http://www.step-10.com/Process/FDD/index.html 18

Praktiky FDD ƒ doménové objektové modelování (Domain Object Modeling), ý jp podle užitných ý vlastností ((Developing p g by y Feature), ), ƒ vývoj 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

ƒ 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 j určenyy pro p různé typy ypy projektů p j ƒ rodina metodik,, které jsou ƒ 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.)

ƒ jjednotlivé d tli é metodiky t dik jjsou pojmenovány j á podle dl b barev, „nejlehčí“ jl hčí“ 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, 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

spravuje seznam požadavků (Product Backlog) tak, aby maximalizoval hodnotu projektu reprezentuje všechny zainteresované

Team

kros-funkční skupina lidí, kteří se sami řídí tak, aby v každém sprintu dodali fungující SW

ScrumMaster

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 p se koná Sprint p Planning g Meeting g ƒ na začátku sprintu • • •

•

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. a konci o c sp sprintu tu se koná o á Sp Sprintt review e e meeting eet g ƒ na • •

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, y ve stejný j ý čas na stejném j místě ƒ koná se vždy ƒ trvá méně než 30 minut (cílem je 15 minut) ƒ vede jjejj Scrum master ƒ účastní se všichni členové týmu (vývojáři, uživatelé , testeři,..) j jje manažeři,, abyy věděli o stavu,, ale aktivně se ƒ navštěvují 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 b d děl dělatt do d příští říští scrum porady d

ƒ

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 Beck K.: K : Extrémní programování programování, Grada, Grada 2002, 2002 ƒ popis metodiky - Beck, ISBN 80-247-0300-9

ƒ hodnoty y XP • • • •

komunikace jednoduchost zpětná ět á vazba b 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 k d se neustále tál iintegruje, t j jjsou náklady ákl d na uvolnění l ě í 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é testyy

ƒ

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ě j é ě tříd říd a metod d

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 na 1 počí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šší y 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á d ídá na d dotazy t

ƒ

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í, 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 ý j 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

vých hodiska

tradiční metodiky

agilní metodiky

SW procesy lze standardizovat

SW procesy není účelné standardizovat

požadavky je možné definovat

předem ř d jen j hrubé h bé požadavky ž d k

předem

přesně definované procesy, činnosti, artefakty

jen generativní pravidla, praktiky a principy

standardní projekty

výzkumné projekty

velké projekty

rychlé projekty menší ší týmy tý 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 íl neníí znovupoužitelnost žit l 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í  počet respondentů průzkumu průzkumu  2006 4232 Dr. Dobb’s Journal and Software  p g Development mailing lists 2007 781 Dr. Dobb’s Journal  2008 642 D D bb’ J Dr. Dobb’s Journal l  

agilní  techniky 65 %

agilní  nejpopulárnější metodiky metodiky 41 % XP         (954) FDD      (502)  Scrum  (460) ( )

69 % 69 %

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 j agilních g jje v p praxi nízký ý Znalost agilních metodik

pokročilá 19%

základní 24%

jiná Použití metodik XP 5% 5% žádná 14%

žádná 19% RUP 19%

firemní standardy 57%

nízká 38%

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 y

ƒ

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 p projektu p j ƒ metodik je velké množství, liší se svými vlastnostmi a použitelností p p pro určité typy ypy p projektů j 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

Doplňková kritéria Kritéria skupiny Proces

Kritéria skupiny p y Produkt y

Důležitost produktu

y

Délka projektu

y

Stálost p požadavků

y

Znovupoužitelnost

y

Velikost řešení

ƒ ƒ ƒ ƒ ƒ ƒ ƒ

Kritéria skupiny Podpora

Kritéria skupiny Lidé y

Zkušenost manažera projektu

y

Kvalifikace členů týmu

y

Motivace členů týmu

y

Dostupnost uživatelů

y

Velikost týmu

y

Rozmístění

Rozsah Model životního cyklu Role Podrobnost popisu procesu Dokumenty Metriky y Řízení kvality

ƒ ƒ ƒ ƒ ƒ ƒ ƒ ƒ

46

Celistvost zdrojů p Dostupnost Podpora metodiky SW nástroji Podpora zavedení metodiky Přizpůsobení metodiky Výuka na vysokých školách Školení a certifikace Lokalizace

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 Mi ft Solutions S l ti F Framework k for f CMMI Process Improvement BUCHALCEVOVÁ, Alena. Metodiky budování informačních systémů. systémů 1. 1 vyd. vyd Praha : Oeconomica, Oeconomica 2009. 2009 206 s. ISBN 978-80-245-1540-3.

ƒ

každá metodika je krátce charakterizována

ƒ

jsou ohodnocena jednotlivá kritéria

ƒ

výsledky hodnocení jsou znázorněny graficky

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 y klíčových ý výběrových ý ý kritérií p projektu j musí být ý v rámci minimální a maximální hodnoty kritéria pro metodiku 3 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 hodnoty  kritérií

Projekt SampleIS Důležitost produktu Délka projektu Stálost požadavků Znovupoužitelnost Velikost řešení Zkušenost manažera projektu Kvalifikace členů týmu Motivace členů týmu Dostupnost uživatelů Velikost týmu Rozmístění

52

2 3 2 4 3 1 1 1 3 0 0

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

RUP Důležitost produktu Délka projektu Stálost požadavků Znovupoužitelnost Velikost řešení Zk š Zkušenost t manažera ž projektu j kt Kvalifikace členů týmu Motivace členů týmu Dostupnost p uživatelů Velikost týmu Rozmístění

váhy 0,219 0 133 0,133 0,041 0,033 0,039 0,015 0,020 0,020 0,200 0,169 0,113 1,000

RUP  min 2 2 2 0 2 0 0 0 0 2 0

za  vzdálenost  vážené abs.  RUP  Projekt  hranicemi  od optim.  hodnoty  opt SampleIS extrémů hodnoty vzdáleností

RUP  max 5 5 5 4 5 4 5 4 4 5 5

53

5 4 2 3 5 4 5 4 4 5 5

2 3 2 4 3 1 1 1 3 0 0

0 0 0 0 0 0 0 0 0 ‐2 0

‐3 ‐1 1 0 1 ‐2 ‐3 ‐4 ‐3 ‐1 ‐5 ‐5

0,656 0 133 0,133 0 0,033 0,077 0,045 0,081 0,059 0,2 0, 0,843 0,565 2,692

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 Důležitost produktu Délka p projektu j Stálost požadavků Znovupoužitelnost Velikost řešení Zk š Zkušenost t manažera ž projektu j kt Kvalifikace členů týmu Motivace členů týmu p uživatelů Dostupnost Velikost týmu Rozmístění

váhy 0,219 0,133 0,041 0,033 0,039 0 015 0,015 0,020 0,020 0,200 , 0,169 0,113 1,000

Open  Open Open  za  vzdálenost  vážené abs.  UP UP  UP UP  UP Projekt UP   Projekt  hranicemi  hranicemi od optim.  od optim hodnoty  hodnoty min max opt SampleIS extrémů hodnoty vzdáleností 0 0 1 0 0 0 0 0 0 0 0

2 4 5 3 3 4 5 4 3 2 1

54

2 2 1 2 2 4 5 4 3 2 1

2 3 2 4 3 1 1 1 3 0 0

0 0 0 1 0 0 0 0 0 0 0

není klíčové výběrové kritérium

0 1 1 2 1 ‐3 ‐4 ‐3 0 2 ‐1

0 0,133 0,041 0,066 0,039 0,045 0,081 0,059 0 0,337 0,113 0,914

Výběr metodiky pro projekt SampleIS krok 2 - shrnutí, krok 3 ƒ

seznam použitelných metodik – OpenUP

K k 3 výběr Krok ýbě d doporučené č é metodiky t dik ƒ

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ší

vážený součet  abs. hodnot  Projekt  za hranicemi  vzdáleností od  SampleIS kličových kritérií optima RUP OpenUP FDD Scrum XP MSF

2,692 0,914 1,644 1,935 1,428 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í

Kritérium Rozsah Model životního cyklu Role Podrobnost popisu procesu Dokumenty ou e y Metriky Řízení kvality Celistvost zdrojů D t Dostupnost t Podpora metodiky SW nástroji Podpora zavedení metodiky Přizpůsobení metodiky Výuka na vysokých školách Školení a certifikace Lokalizace

MSF  MSF váha  RUP  OpenUP  FDD  Scrum  XP  MSF  CMMI  kritéria RUP vážený OpenUP vážený FDD vážený Scrum vážený XP vážený CMMI vážený 0,051 4 0,205 3 0,153 3 0,153 2 0,102 1 0,051 5 0,256 0,089 4 0,355 5 0,444 5 0,444 5 0,444 5 0,444 4 0,355 0,026 3 0,079 2 0,053 2 0,053 2 0,053 1 0,026 3 0,079 0,059 5 0,296 5 0,296 3 0,178 0 0,000 0 0,000 5 0,296 0,027 4 0,106 3 0,080 3 0,080 1 0,027 1 0,027 4 0,106 0,030 3 0,089 1 0,030 3 0,089 2 0,060 2 0,060 3 0,089 0,038 5 0,192 2 0,077 2 0,077 2 0,077 2 0,077 5 0,192 0,195 5 0,975 5 0,975 2 0,390 2 0,390 2 0,390 4 0,780 0 195 0,195 2 0,390 0 390 5 0 975 1 0,195 0,975 0 195 1 0,195 0 195 1 0,195 0 195 3 0,585 0 585 0,106 5 0,530 4 0,424 1 0,106 4 0,424 4 0,424 3 0,318 0,038 5 0,192 0 0,000 2 0,077 2 0,077 2 0,077 2 0,077 0,038 5 0,192 5 0,192 3 0,115 4 0,154 3 0,115 4 0,154 0,023 5 0,115 5 0,115 4 0,092 4 0,092 5 0,115 2 0,046 0,025 5 0,124 4 0,099 4 0,099 4 0,099 5 0,124 5 0,124 0,059 0 0,000 0 0,000 0 0,000 0 0,000 0 0,000 0 0,000 3 840 3,840 3 912 3,912 2 148 2,148 2 192 2,192 2 124 2,124 3 457 3,457 56

Děkuji j za pozornost p