Jakou metodiku použít pro konkrétní projekt? konkrétní

Transkript

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 <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
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
39
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élka projektu
Stálost požadavků
Znovupoužitelnost
Velikost řešení
Zkušenost manažera projektu
Dostupnost uživatelů
Velikost týmu
Rozmístění
52
2
3
2
4
3
1
1
1
3
0
0
krok 2 – posouzení metodiky RUP
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élka projektu
Znovupoužitelnost
Velikost řešení
Zk š
Zkušenost
t manažera
ž projektu
j kt
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
krok 2 - posouzení metodiky OpenUP
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élka p
projektu
j
Znovupoužitelnost
Velikost řešení
Zk š
Zkušenost
t manažera
ž
projektu
j kt
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
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
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