Výběr vhodné metodiky vývoje softwaru pro společnost HOUR, spol. s r.o

Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Vyšší odborná škola informačních služeb v Praze

Simona Dlugošová

Výběr vhodné metodiky vývoje softwaru pro společnost HOUR, spol. s r.o. Bakalářská práce

2012

Zadání bakalářské práce

Prohlášení Prohlašuji, že jsem bakalářskou práci na téma „Výběr vhodné metodiky vývoje softwaru pro společnost HOUR, spol. s r.o.“ zpracovala samostatně a použila pouze zdrojů, které cituji a uvádím v seznamu použité literatury.

V Praze dne 21. května 2012

…………………………………. Simona Dlugošová

Poděkování Ráda bych poděkovala paní PhDr. Heleně Kučerové, za ochotu, trpělivost, věcné připomínky a cenné rady při zpracování této bakalářské práce. Dále děkuji panu Ing. Romanu Dufkovi, zaměstnanci spolčenosti HOUR, spol. s r.o. za odborné konzultace.

Abstrakt Tématem této bakalářské práce je „Výběr vhodné metodiky vývoje softwaru pro společnost Hour, spol. s r.o.“. Hlavním úkolem práce je porovnání níže uvedených metodik za využití systému hodnocení a výběru metodik budování IS/ICT METES (Methodology Evaluation System), nalézt vhodnou metodiku pro vývoj softwaru pro plánovaný projekt Humanet. V rámci této bakalářské práce jsou porovnávány jak metodiky zaměřené na rigorózní vývoj, tak metodiky agilní. Mezi rigorózní metodiky jsou zařazeny Rational Unified Process (RUP) a Microsoft Solution Framework for CMMI Process Improvement (MSF CMMI), mezi agilní metodiky pak OpenUP, Scrum, Extrémní programování (XP) a Feature-Driven Development (FDD). Porovnání je provedeno na základě vymezených kritérií metodou METES. Pro stanovení důležitosti jednotlivých kritérií je použita Saatyho vícekriteriální metoda párového srovnávání. Na základě porovnání všech kritérií daných metodik a kritérií stanovených pro projekt Humanet, je navržena metodika, která nejlépe splňuje požadavky na něj kladené.

Klíčová slova – metodika, RUP, XP, FDD, Scrum, MSF, METES

Abstract The topic of this bachelor thesis is „The choice of the right software developing method for the company Hour, spol. s r. o.”. The main part of the work is comparing of lower introduced methods with use of system of classification and pick the right method of building IS/ICT METES (Methodology Evaluation System), find the right method for developing the software already planned project Humanet. Within the frame of this thesis are compared methods focusing on regional development and also agile methods. Into rigorous methods are classed Rational Unified Process (RUP) a Microsoft Solution Framework for CMMI Process Improvement (MSF CMMI), into agile methods are classed OpenUp, Scrum, Extreme programming (XP) and FeatureDriven Development (FDD). The comparison is accomplished based on delineated criteria by method METES. For importance setting of each criterion is used Saaty’s multicriteria method binate comparison. Based on the comparison of all criteria concrete methods and criterion for project Humanet is designed a method that fulfil most of asked requirement.

Obsah 1 Úvod ........................................................................................................................ 10

2

3

1.1

Cíl práce............................................................................................................ 10

1.2

Hypotéza ........................................................................................................... 10

1.3

Metodologie práce ............................................................................................ 10

Porovnání rigorózních a agilních metodik .............................................................. 11 2.1

Rigorózní metodiky .......................................................................................... 11

2.2

Agilní metodiky ................................................................................................ 12

2.3

Porovnání rigorózních a agilních metodik ....................................................... 13

Systém hodnocení a výběru metodik METES ........................................................ 15 3.1

Charakteristika METES.................................................................................... 15

3.2

Způsob hodnocení kritérií................................................................................. 16

3.3

Kritéria skupiny Produkt .................................................................................. 17

3.3.1

Důležitost produktu ................................................................................... 17

3.3.2

Délka projektu ........................................................................................... 17

3.3.3

Stálost požadavků...................................................................................... 17

3.3.4

Znovupoužitelnost ..................................................................................... 18

3.3.5

Velikost řešení........................................................................................... 18

3.4

4

Kritéria skupiny Lidé ........................................................................................ 19

3.4.1

Zkušenost manažera projektu .................................................................... 19

3.4.2

Kvalifikace členů týmů ............................................................................. 19

3.4.3

Motivace členů týmu ................................................................................. 20

3.4.4

Dostupnost uživatelů ................................................................................. 20

3.4.5

Velikost týmu ............................................................................................ 20

3.4.6

Rozmístění................................................................................................. 21

Charakteristika projektu .......................................................................................... 21 4.1

Vývoj softwarových aplikací ve společnosti HOUR, spol. s r.o. ..................... 21

4.2

Projekt Humanet ............................................................................................... 22 7

5

6

Výběr vhodné metodiky .......................................................................................... 23 5.1

Stanovení vah pro skupiny Produkt a Lidé....................................................... 25

5.2

Stanovení hodnot kritérií skupiny Produkt pro projekt Humanet .................... 27

5.3

Stanovení hodnot kritérií skupiny Lidé pro projekt Humanet .......................... 27

Posouzení použitelnosti vybraných metodik ........................................................... 28 6.1

Metodika Rational Unified Process (RUP) ...................................................... 28

6.1.1

Charakteristika RUP.................................................................................. 28

6.1.2

Hodnocení kritérií skupin Produkt a Lidé ................................................. 30

6.1.3

Posouzení použitelnosti RUP pro projekt Humanet.................................. 31

6.2

Metodika Microsoft Solution Framework (MSF) ............................................ 33

6.2.1

Charakteristika metodiky .......................................................................... 33

6.2.2


6.2.3

Posouzení použitelnosti metodiky MSF CMMI pro projekt Humanet ..... 36

6.3

Metodika OpenUP ............................................................................................ 38

6.3.1


6.3.2


6.3.3

Posouzení použitelnosti metodiky OpenUP pro projekt Humanet ........... 41

6.4

Metodika Feature Driven Development (FDD) ............................................... 43

6.4.1


6.4.2


6.4.3

Posouzení použitelnosti metodiky FDD pro projekt Humanet ................. 46

6.5

Metodika Scrum ............................................................................................... 47

6.5.1


6.5.2

Hodnocení skupin Produkt a Lidé ............................................................. 49

6.5.3

Posouzení metodiky Scrum pro projekt Humanet .................................... 50

6.6

Metodika Extrémní programování (XP) ........................................................... 52

6.6.1


6.6.2

Hodnocení kritérií skupin Produkt a Lidé ................................................. 54 8

6.6.3

Posouzení metodiky XP pro projekt Humanet .......................................... 55

7

Závěr ....................................................................................................................... 57

8

Seznamy a přílohy ................................................................................................... 58 8.1

Seznam použité literatury ................................................................................. 58

8.2

Seznam obrázků................................................................................................ 60

8.3

Seznam grafů .................................................................................................... 61

8.4

Seznam tabulek................................................................................................. 61

8.5

Přílohy .............................................................................................................. 62

9

1 Úvod 1.1 Cíl práce Hlavním cílem práce je provést výběr vhodné metodiky vývoje softwaru pro společnost HOUR, spol. s r.o. Potřebná analýza nejrozšířenějších rigorózních a agilních metodik je provedena na základě vícekriteriálního systému hodnocení a výběru metodik METES (Methodology Evaluation System). Společnost v současné době provádí veškerý vývoj softwaru na definované vnitropodnikové směrnici. Cílem analýzy metodik pomocí METES je nalézt co nejvhodnější metodiku vývoje pro plánovaný projekt Humanet.

1.2 Hypotéza Hlavním předpokladem je výběr některé z dnes velice rozšířených a oblíbených agilních metodik, konkrétně metodiky Scrum. Ta dokáže velice rychle reagovat na možné změny, které v rámci vývoje mohou vznikat. Předpokladem pro její zavedení je také vysoká odborná kvalifikace, jak manažera projektu, tak členů týmu, veškeré tyto podmínky plánovaný projekt splňuje. Navíc je zde také možnost podpory této metodiky pomocí nástrojů Visual Studio Team System, který je ve společnosti již pro podporu využíván.

1.3 Metodologie práce V úvodu práce jsem obecně charakterizovala rigorózní a agilní metodiky. Jsou zde definovány zásady, kterými se řídí a jaké jsou mezi nimi rozdíly. V další kapitole je charakterizován sám systém METES, jeho základní principy podle kterých pracuje a ze kterých vychází. Uvádím zde kritéria podle kterých jsou jak jednotlivé metodiky, tak projekt hodnoceny a také způsob jejich hodnocení. Čtvrtá kapitola je věnována samotnému současnému popisu vývoje softwarových aplikací ve společnosti Hour a základní charakteristice projektu Humanet. V následující kapitole se věnuji samotnému postupu výběru vhodné metodiky. V kapitole číslo šest jsou postupně charakterizovány všechny posuzované metodiky a zároveň je provedeno jejich hodnocení použitelností ve vztahu k projektu Humanet. Na závěr jsou tyto výsledky zanalyzovány a je vybrána metodika, která co nejvíce splňuje předpoklady a požadavky definované projektem.

10

2 Porovnání rigorózních a agilních metodik Metodiky pro vývoj informačních systému se dají dělit různými způsoby. Nejčastější z nich je ale rozdělení do dvou základních kategorií a to na rigorózní a agilní. Obě tyto kategorie mají mnoho svých zástupců, které lze pro vývoj softwaru použít. Každý z těchto přístupů je však vhodný pro různé projekty a to v souvislosti rozdílných předpokladů pro zavedení, oblasti použití, jejich velikostí, stálostí požadavků apod.

2.1 Rigorózní metodiky Základním předpokladem rigorózních metodik, které bývají velice často také označovány jako těžké metodiky, je striktně propracovaný popiš řízení a plánování vývoje softwaru. Tyto metodiky přesně definují posloupnost činností, které musí být při vývoji uskutečněny. Jedná se o metodiky opírající se o velmi podrobnou dokumentaci a o to že, veškeré požadavky na software lze určit předem. Většina metodik spadajících do této kategorie se odvíjí z vodopádového modelu životního cyklu, který je zobrazen na obrázku č.2-1: Vodopádový model životního cyklu. [23]

Obrázek 1-1 Vodopádový model životního cyklu

Tento model životního cyklu je definován sedmi základními kroky neboli fázemi, kterými vývoj prochází. Nejprve jsou specifikovány požadavky na systém a software, dále je provedena podrobná analýza a následný návrh programu. Ten je pak implementován, testován a uveden do provozu. Základním rysem tohoto modelu je podmínka, že vstup z jedné fáze do druhé je možný, pouze pokud je fáze předcházející zcela dokončena. [23] 11

Jak je tedy zřejmé rigorózní metodiky není vhodné používat pro vývoj softwaru u projektů, u kterých se předpokládá během jeho vývoje poměrně velké množství změn, které by mohly nastat. To by mohlo vést k velice zdlouhavému a složitému procesu. Některé rigorózní metodiky jsou dnes již realizovány také iterativním, jednotlivé fáze vývoje jsou prováděny opakovaně, či inkrementálním způsobem, vývoj je prováděn na základě přírůstků. Mezi těžké metodiky lze zařadit postupy posuzování softwarových procesů podle Capability Maturity Model Integration (CMMI) – Integrační model zralosti, nebo normu ISO/IEC 15504 a to z toho důvodu, že pohlížejí na procesy budování informačních systémů jako na definované procesy. [6, s. 64] Mezi nejznámější zástupce rigorózních metodik však patří Rational Unified Process (RUP), který je také kromě metodiky Microsoft Solution Framework for CMMI Process Improvement jednou z posuzovaných metodik pro projekt Humanet.

2.2 Agilní metodiky S vyvíjejícími se technologiemi a nástroji přestali být některé z rigorózních metodik použitelné. Rigorózní pojetí vývoje se díky předdefinovaným pravidlům nedokáže tak rychle přizpůsobovat narůstajícím a často se měnícím požadavkům zákazníků, jejich přirozeností je se jim bránit.

K selhávání těžkých metodik také

ve velkém přispívá jejich náročnost na modelování, vznik velkého množství nepotřebných meziproduktů, či nepřizpůsobivost změnám v kvalitativním způsobu vývoje. To dalo vzniknout novým metodikám vývoje, jedná se o tzv. agilní, neboli lehké metodiky. Jedná se o metodiky, které jsou iterativní. Což znamená, že jsou založeny na opakujících se procesech. Dokážou se přizpůsobovat změnám požadavků, snaží se o co nejrychlejší vývoj softwaru a kladou velký důraz na přímou komunikaci. Vývoj a postupné prosazování těchto metodik dal vzniknout v roce 2001 Manifestu agilního vývoje (Agile Manifesto), ten vymezuje čtyři základní pravidla agilních metodik a dalších 12 principů, podle kterých se řídí. Základní pravidla upřednostňují: individualitu a komunikaci před procesy a nástroji fungující software před vyčerpávající dokumentací spolupráci se zákazníkem před vyjednáváním o smluvních podmínkách reakce na změny před striktním dodržováním plánu [19]

12

Dvanáct principů agilních metodik: [19] Hlavní prioritou je vyhovět zákazníkovi za pomoci včasných a průběžných dodávek softwaru. Jsou vítány změny v požadavcích a to i v pozdějších fázích vývoje. Agilní procesy podporují změny, které by mohly vést ke zvýšení konkurenceschopnosti zákazníka. Fungující software je dodáván v pravidelných, krátkých časových úsecích několika týdnů, měsíců, popřípadě kratších. Lidé z byznysu i vývojáři musí denně spolupracovat a to po celou dobu projektu. Projekty jsou budovány motivovanými jedinci. Je jim poskytnuto takové pracovní prostředí a podpora, jakou potřebují. Zároveň je v ně kladena důvěra, za odvedení kvalitní práce. Nejúčinnější a nejefektivnější sdělování informací při vývoji je formou osobní komunikace. Hlavní mírou pokroku je fungující software. Agilní procesy podporují udržitelný vývoj. Sponzoři, vývojáři i uživatelé by měli být schopni udržovat spolu krok po neomezenou dobu. Agilní přístup je posilován za pomoci neustálého věnování pozornosti technické kvality a dobrým návrhem. Jednoduchost – umění maximalizovat množství práce, která nemusí být provedena – je základem. Nejlepší

architektury,

požadavky

a

návrhy

vznikají

v samostatně

se organizujících týmech. Tým pravidelně uvažuje nad tím, jak být efektivnějším, na základě toho vylepší své postupy a přizpůsobí i své chování. Mezi nejznámější zástupce agilního přístupu patří metodiky Feature-Driven Development, Scrum, Extrémní programování a OpenUP. Všechny tyto uvedené metodiky jsou dále charakterizovány a hodnoceny ve vztahu k projektu Humanet.

2.3 Porovnání rigorózních a agilních metodik V tabulce 2-1 Porovnání rigorózních a agilních metodik je vybráno sedm základních rozdílů, které mezi těmito dvěma kategoriemi jsou. Jsou vybírané z přehledu, který uvádí Ph.D. Alena Buchalcevová ve své knize Metodiky budování informačních systémů. [6, s. 71-73] 13

Posuzované hledisko změny

Rigorózní metodiky

jsou vítány, možnost

snaha minimalizace

rozsah řešení způsob řízení forma komunikace dokumentace

přehodnocování požadavků

snaha zabudování budoucích

pouze požadované funkce,

požadavků

požadavek minimalizace

na základě nedůvěry, direktivní

vůdcovství a spolupráce, je

řízení a kontroly

formováno na důvěře a respektu

převážně písemná

důraz na komunikaci tváří v tvář podstatná není dokumentace, ale

rozsáhlá dokumentace

pochopení

píše vodopádový, případně způsob vývoje

iterativní, přírůstkový s dlouhými iteracemi

zákazník

Agilní metodiky

přírůstkový vývoj s velmi krátkými iteracemi

podílí se na projektu jeho

přesun nositele řízení z týmu na

v začátcích a na konci;

zákazníka, je řídícím subjektem,

zaměření vývoje je orientováno

průběžně může měnit priority;

více na jednotlivé procesy, než na

nejvyšší prioritou je spokojenost

výsledky pro zákazníka

zákazníka

Tabulka 1-1 Porovnání rigorózních a agilních metodik

Cílem agilních metodik je v co nejrychlejším možném čase vytvořit produkt, který bude plně splňovat zákazníkovi požadavky. Agilní přístup je postaven na flexibilním a rychlém přizpůsobování změnám v požadavcích, které zákazník uvádí. Proto se předpokládá, že je zadavatel přímo součástí týmu vývojářů, nebo je alespoň k dispozici kdykoliv je zapotřebí. Díky tomu je na něj převáděna jistá míra zodpovědnosti. Pro agilní metodiky je také vhodnější práce v menších týmech přibližně do deseti vývojářů, využívány jsou jejich individuální znalosti a je tak také usnadněna přímá komunikace mezi jednotlivými členy. V současné době se ale jen velice těžko některé z předpokládaných postupů pro agilní vývoj dodržují, například každodenní přítomnost zákazníka je v řadě projektů přímo nemožná. Právě díky tomu, že se vývoj software řadí mezi rychle vyvíjející se odvětví, dochází tak i k přizpůsobování jednotlivých směrů pro vývoj metodik. Agilní přístupy se začínají v některých směrech formalizovat tak, aby bylo možné je použít i při větších projektech, které původně vůbec neodpovídají možnosti použití těchto

14

metodik. Často tak můžeme slyšet o možnosti kombinací těchto lehkých metodik s metodikami těžkými. U rigorózních metodik pak naopak dochází k jejich odlehčování.

3 Systém hodnocení a výběru metodik METES Pro výběr správné metodiky vývoje softwaru, kterou by bylo vhodné aplikovat na konkrétní projekt, je mnoho různých cest, jak docílit potřebného řešení. Jednou z nich je i Systém pro hodnocení a výběr metodik budování IS/ICT METES (Methodology Evaluation System). Ten byl navržen paní doc. Ing. Alenou Buchalcevovou, Ph. D., která působí jako vedoucí sekce softwarového inženýrství na katedře informačních technologií Vysoké školy ekonomické v Praze. METES vychází převážně ze systému hodnocení a výběru metodik navrženého Davidem Heckselem. Původní Heckselův systém hodnocení obsahuje 62 atributů rozdělených do čtyř skupin, z toho 51 z nich je součástí tzv. Projektového kontextu, který je rozdělen do tří skupin - Lidé, Proces a Technologie, ty charakterizují daný projekt. Zbývajících 11 atributů je definováno jako kořenových. Na základě stanovení hodnot všech atributů je pak navržen Projektový model, který je dále porovnán s Modely metodik. [10] I přes velký počet atributů tento systém však už nezohledňuje kritéria, jako jsou lokalizace metodiky, její dostupnost, kvalifikace lidí apod., METES je tedy založen na základní struktuře Heckselova systému a doplněn o novou strukturu kritérií, jejichž počet je sice podstatně menší, ale některá z nich bývají často opomíjena i přes to, že mohou hrát při výběru významnou roli.

3.1 Charakteristika METES Systém spočívá převážně v hodnocení kritérií, která jsou rozdělena do čtyř základních skupin – Produkt, Lidé, Proces a Podpora. Klíčová kritéria pro posuzování metodiky jsou obsažena ve skupinách Produkt a Lidé, ta hodnotí základní charakteristiky vyvíjeného produktu a lidí, kteří se na jeho tvorbě podílí. Kritéria skupin Proces a Podpora jsou pak dále zaměřena na zhodnocení procesů dané metodiky. Pro systém METES jsou ohodnocovány v současné době nejrozšířenější metodiky pro vývoj softwaru a to Rational Unified Process (RUP), OpenUP, Feature Driven Development (FDD), Scrum, Extreme Programming (XP) a Microsoft Solution Framework, konkrétně metodika CMMI Proces Improvement (MSF CMMI). Celá struktura hodnocení systému dle Ph. D. Aleny Buchalcevové je zobrazena na obrázku 3-1: Struktura systému hodnocení metodik METES. 15

Obrázek 1-2Struktura systému hodnocení metodik METES [6, s. 95]

3.2 Způsob hodnocení kritérií Všechna kritéria jsou hodnocena pomocí číselné stupnice od nuly do pěti. Čím nižší hodnotou je kritérium ohodnoceno, tím menší je stupeň jeho splnění a naopak. Pro každé kritérium je konkrétně specifikována stupnice, kde je každý její bod detailněji popsán. U kritérií spadajících do skupin Produkt a Lidé jsou pro posuzování metodiky ještě definovány minimální, maximální a optimální hodnoty. Ty určují rozsah, podle kterého se usuzuje, zda je metodika ve vztahu k danému projektu použitelná. Uvedená kritéria stanovená pro porovnání jsou vymezena tak, jak je stanovila Ph.D. Alena Buchalcevová ve své knize Metodiky budování informačních systému, kde je podrobně popsán celý systém pro výběr vhodné metodiky na základě systému METES. Hodnocení kritérií základních skupin Produkt a Lidé je uvedeno v kapitolách 3.3 a 3.4. Doplňková kritéria, včetně stupnice ohodnocení jsou pak k nahlédnutí v příloze č.1 Doplňková kritéria skupin Proces a Podpora, a to z toho důvodu, že ne vždy je nezbytně nutné provádět jejich analýzu. Systém METES je modelem vícekriteriální analýzy variant a využívá pro hodnocení váhy kritérií. Váha kritéria je hodnota z intervalu <0,1>, která vyjadřuje relativní důležitost tohoto kritéria v porovnání s kritérii ostatními.[6, s. 114] K jednotlivým kritériím jsou tedy stanoveny váhy důležitosti, ty jsou pak dále využívány pro určení vážených absolutních hodnot vzdáleností od optimálních hodnot každé z hodnocených metodik.

16

3.3 Kritéria skupiny Produkt Jak je již patrné z názvu skupiny, kritéria, která tato skupina obsahuje, mají za účel ohodnotit produkt, který bude vytvářen. V případě společnosti HOUR, spol. s r.o. se jedná o vývoj nových modulů. Jde zde o stanovení základní charakteristiky produktu - velikost, důležitost, požadavky. 3.3.1 Důležitost produktu První z klíčových kritérií rozlišující druh a důležitost produktu má za úkol sledovat především vliv systému z hlediska jeho poslání. Důležitým ukazatelem zde jsou také jeho možné negativní dopady v případě jeho nefunkčnosti. Hodnocení produktu je spjato s řízením kvality a formálností metodiky. Stupnice hodnocení: 0 – jen pilotní projekt 1 – doplňkový systém 2 – systém podporující fungování organizace 3 – systém kritický pro poslání (národní organizace) 4 – systém kritický pro poslání (nadnárodní organizace) 5 – systém, na kterém závisí životy lidí 3.3.2 Délka projektu Toto kritérium má za úkol ohodnotit časový úsek, který je vymezen na základě počtu měsíců, po které se předpokládá, že bude projekt vytvářen. Vzhledem k závislosti společností na rychlosti vývoje a následného nasazení svých produktů vůči rozvíjející se konkurenci na trhu, je toto kritérium zařazeno opět mezi klíčové. Stupnice hodnocení: 0 – do 1 měsíce 1 – do 3 měsíců 2 – do 6 měsíců 3 – do 12 měsíců 4 – do 24 měsíců 5 – nad 24 měsíců 3.3.3 Stálost požadavků Hraje významnou roli pro rozhodování mezi agilními a rigorózními metodikami. Definuje, zda před zahájením projektu možné předem pevně stanovit veškeré požadavky na něj a v jaké míře se dají obměňovat i v průběhu samotného vývoje 17

Stupnice hodnocení: 0 – požadavky není předem možné detailně stanovit 1 – požadavky se více než z 50% mění 2 – procento změn požadavků je cca 30% 3 – požadavky lze definovat předem, mění se jen priority požadavků 4 – požadavky lze definovat předem, mění se, ale snahou je změny potlačovat 5 – požadavky lze definovat předem a nemění se 3.3.4 Znovupoužitelnost Kritérium hodnotí požadavky na tvorbu prvků, které se budou moci dále používat nejen v rámci jednoho konkrétního projektu, ale i dalších různých, které firma plánuje. Na základě toho se pak dále rozlišuje, zda jsou vytvořené třídy těchto prvků používány pouze v jednom programovém prostředí, nebo je možno je aplikovat v programových prostředích různého charakteru. Toto kritérium opět hraje roli při výběru typu metodiky, znovupoužitelnost prvků je vyžadována především u metodik rigorózních, zatímco agilní se zaměřují na daný konkrétní problém a nezabývají se jejich budoucím využitím. Stupnice hodnocení: 0 – cílem není znovupoužitelnost 1 – snaha používat již hotové komponenty 2 – snaha vytvářet znovupoužitelné třídy v rámci projektu 3 – snaha vytvářet znovupoužitelné spustitelné komponenty v rámci projektu 4 – snaha vytvářet znovupoužitelné spustitelné komponenty v rámci organizace 5 – cílem je maximální znovupoužitelnost v rámci organizace 3.3.5 Velikost řešení Pro posouzení tohoto kritéria bylo navrženo mnoho různých způsobů, prostřednictvím kterých se snažili jejich autoři vyjádřit velikost vytvářeného softwaru číselnou hodnotou. Metodika METES určuje velikost řešení na základě počtu případů užití, ten specifikuje strukturu systému z pohledu uživatele. Jedná se o další z kritérií ovlivňujících volbu mezi agilním a rigorózním vývojem. Stupnice hodnocení: 0 – 1 až 10 1 – 11 až 40 2 – 41 až 100 3 – 101 až 200 18

4 – 201 až 300 5 – 300 a více

3.4 Kritéria skupiny Lidé Skupina zahrnuje kritéria, která mají za úkol blíže charakterizovat tým lidí, kteří se na vývoji systému podílí. Zaměřuje se převážně na zkušenosti členů týmu, jejich kvalifikaci, velikost a rozmístění. 3.4.1 Zkušenost manažera projektu Zkušenosti manažera projektu hrají velikou roli při samotném vývoji, jelikož se jedná o vedoucího celého týmu, je od něj závislých mnoho faktorů, které projekt ovlivňují a ve velkém na něm tak závisí i samotný úspěch projektu. Zkušenosti manažera jsou ohodnocovány z hlediska počtu let, ve kterých zastává tuto svou funkci. Stupnice hodnocení: 0 – 5 a více 1 – 4 až 5 let 2 – 3 až 4 roky 3 – 2 až 3 roky 4 – 1 až 2 roky 5 – 0 až 1 rok 3.4.2 Kvalifikace členů týmů Předmětem hodnocení jsou zkušenosti a dovednosti jednotlivých členů týmů, tedy vyjma manažera. Je nutné, aby metodika pro vývoj softwaru byla přizpůsobena kvalifikaci členům týmu, např. pro agilní vývoj je nezbytné, aby byl tým sestaven z jedinců, kteří mají široké zaměření a neprošli jen úzkou specializací v oboru. Stupnice hodnocení: 0 – více než 70% členů týmu je kvalifikovaných s širokým zaměřením 1 – více než 70% členů týmu je kvalifikovaných, ale specializovaných 2 – cca 50% členů týmu je málo kvalifikovaných 3 – více než 60% členů týmu je málo kvalifikovaných 4 – více než 70% členů týmu je málo kvalifikovaných 5 – více než 80% členů týmu je málo kvalifikovaných

19

3.4.3 Motivace členů týmu Kritérium se zabývá charakterovými vlastnostmi členů týmů z hlediska jejich morálních hodnot. Posuzováno je na základě míry motivace většiny členů, opět kromě manažera. U některých metodik je totiž vyžadováno, aby se členové organizovali sami. V těchto případech je více než nutné, aby byla splněna podmínka vysokých morálních hodnot jedinců tvořících tým. Stupnice hodnocení: 0 – motivovaní jedinci vysokých morálních kvalit, sdílí znalosti, sami se organizují 1 – aktivní, motivovaní jedinci, sdílí znalosti 2 – plní zadané úkoly, sdílí znalosti 3 – plní zadané úkoly, nesdílí znalosti 4 – jedinci jsou špatně motivováni a snaží se vyhýbat úkolům, nesdílí znalosti 5 – žádná motivace 3.4.4 Dostupnost uživatelů Kritérium uvádějící jak moc je sám zákazník zapojen do projektu, což je spjato i s kritériem hodnotícím stálost požadavků. V případě, že je vyvíjen software, kde dochází k častým změnám, které jsou kladeny na jeho požadavky, by měl být zákazník pro řešitele, co nejvíce dostupný. U agilních metodik je téměř vyžadována jeho denní účast. Dostupnost uživatelů je třetím klíčovým kritériem, na kterém je závislá použitelnost vybíraných metodik. Stupnice hodnocení: 0 – uživatel je součástí týmu, má odpovědnost za požadavky 1 – uživatel je k dispozici denně 2 – uživatel je k dispozici kdykoliv na vyžádání 3 – uživatel je k dispozici na začátku, konci a v průběhu projektu, v předem určených milnících 4 – uživatel je k dispozici jen na začátku a na konci projektu 5 – uživatel není dostupný 3.4.5 Velikost týmu Jednou z nejdůležitějších činností při práci na projektu je komunikace mezi členy týmu, kterou musí daná metodika řídit. Opět se tedy jedná o další z klíčových kritérií. Velikost týmu zahrnuje veškeré osoby podílející se ať už více, nebo méně na uskutečnění celé tvorby projektu a to včetně projektového manažera. 20

Stupnice hodnocení: 0 – 1 až 4 1 – 4 až 10 2 – 11 až 20 3 – 21 až 50 4 – 51 až 100 5 – více než 100 3.4.6 Rozmístění Zhodnocení rozmístění členů týmu. Poslední klíčové kritérium, na kterém vysoce závisí výběr metodiky. Některé z nich totiž vyžadují přímou, neboli osobní formu komunikace. Např. pro použití agilní metodiky pro vývoj softwaru se přímo předpokládá osobní forma komunikace. Vzhledem k velikosti týmu však není možné vždy těmto požadavkům dostát, proto se i tyto metodiky začaly v současnosti přizpůsobovat tak, aby mohl být použit i pro větší týmy. Stupnice hodnocení: 0 – v jedné místnosti 1 – v jedné budově 2 – více míst v jednom městě 3 – dvě místa v jedné zemi 4 – více míst v jedné zemi

4 Charakteristika projektu 4.1 Vývoj softwarových aplikací ve společnosti HOUR, spol. s r.o. V současné době jsou ve firmě HOUR, spol. s r.o. veškeré procesy pro vývoj softwarových aplikací prováděny na základě vnitropodnikové směrnice. Ta definuje procesy, jako jsou: specifikace a sběr požadavků na vývoj SW, posouzení požadavků, prozkoumání požadavků, analýza, objednávka, realizace navrhovaného řešení, testování, 21

ukončení vývoje, tvorba uživatelské dokumentace, implementace SW. Pro lepší sledování a řízení celého cyklu vývoje softwarových aplikací, je používáno vývojové prostředí Visual Studio 2010 s propojením na Team Foundation Server (TFS) společnosti Microsoft. To umožňuje udržovat zdrojový kód, správu testů a údaje o jednotlivých částech projektu na jednom místě za pomoci centrálního úložiště. Díky čemuž je i zjednodušena a zefektivněna komunikace jednotlivých týmů pracujících na vývoji. Team Foundation Server také zastřešuje nástroje pro reporting, které podávají detailní přehled o stavu projektu v reálném čase, dovolují plánování posloupnosti zpracovávání požadavků, správu projektů i portfolia. V tomto vývojovém prostředí lze zavést nástroje potřebné pro metodiky agilního vývoje softwaru. [26] Podrobnější popis činností a celkového vývoje softwarových aplikací společností HOUR, spol s r.o. je zachycen ve vývojovém diagramu, v příloze č.2 Vývojový diagram softwarových aplikací.

4.2 Projekt Humanet Společnost plánuje v časovém rozmezí dvanácti měsíců rozšířit nabídku jednoho ze stávajících produktů a to ekonomického a HR informačního systému Humanet. Informační systém Humanet je nabízen jako SaaS, který plně zastřešuje potřeby vedení a zpracování personální a účetní agendy s důrazem na řízení lidských zdrojů. Hlavní výhodou tohoto systému je, že je určen převážně pro nasazení v prostředí intranetu, internetu a mobilních zařízení. Systém je vybudován nad originální infrastrukturou společnosti HOUR, spol. s r.o. Jedná se o tzv. Network Application Framework. Tato infrastruktura se skládá z několika částí, které navzájem spolupracují a komunikují prostřednictvím TCP/IP protokolu. Prostřednictvím takto strukturovaného jádra aplikace je možné vytvářet aplikace ERP charakteru. Celá infrastruktura je vybudována nad technologií .NET Framework společnosti Microsoft. [12] Vzhledem k vysoké poptávce po produktu a také díky stále vyšším nárokům uživatelů bude stávající systém rozšířen o tyto tři nové moduly: Časový manažer, který má za úkol správu docházky zaměstnanců v reálném čase (odpracovaná doba, čerpání dovolené, služební cesty, přerušení pracovní 22

doby). Díky parametričnosti modulu, by mělo být možné jeho obsah přizpůsobovat na základě potřeb jednotlivých zákazníků. Dalším z požadavků na modul je podpora různých typů databází, jako jsou např. MySQL, Oracle, nebo Informix. Časový manažer bude propojen na již dnes velmi využívané snímače čipových karet a jeho správa zjednodušena i díky přístupnosti k němu přes webovou aplikaci. [11, s. 8-11] Příprava zaměstnanců, cílem modulu je zjednodušení řízení lidských zdrojů z hlediska jejich vzdělávání, správy, evidence a kontroly. Správa modulu je plánována na základě katalogového systému zadávání. Katalog je datový formulář, ve kterém jsou uvedeny veškeré vzdělávací aktivity. Na základě spolupráce společností Hour, spol. s r.o. a eduacation.sk, bude mít uživatel možnost vložení nabídek ve vzdělávacích službách, které jsou na portálu education.sk vedeny. Každému uživateli je v katalogu vytvářeno portfolio. Veškeré vzdělávací aktivity, ať se jedná o povinná školení či nepovinné vzdělávací kurzy, budou pro přehlednost vedeny v kalendáři, kde je možné je různě filtrovat právě na základě jejich důležitosti a druhu, ale i stavu v jakém se právě nachází (uskutečněné, probíhající, plánované). [11, s. 3-5] Controlling je modul, který slouží manažerům k usnadnění a koordinaci chodu společnosti. Modul má zastřešit takové zpracovávání dat, aby byl schopen poskytnout potřebné výstupy a to v podobě různých sestav grafů a tabulek. Všechny nástroje obsažené v modulu slouží k vylepšování firemních výsledků. Jedná se např. o nástroje pro reporting za jehož pomoci je možné sledování potřebných ukazatelů nejen v čase. Controlling má dále za cíl usnadnit tvorbu kalkulací a možných operativních analýz, to vše pro usnadnění sledování plánů podniku a případného odstraňování potencionálních rizik. [11, s. 15-16]

5 Výběr vhodné metodiky Pro výběr vhodné metodiky je vždy stanoven určitý postup. V případě systému hodnocení metodik METES jsou nejprve stanoveny váhy hodnocení pro kritéria základních skupin Produkt a Lidé, dále jsou kritéria těchto dvou skupin posuzována prostřednictvím definovaných stupnic hodnocení, které jsou podrobněji popsány v kapitolách č. 3.3 a 3.4 kritéria skupin Produkt a Lidé, a to ve vztahu k určitému projektu. Výsledkem jsou pak hodnoty, které má daný projekt splňovat.

23

Dalším krokem je výběr metodik, které by bylo možno pro uskutečnění určitého projektu aplikovat. Velice důležitou roli při výběru hrají právě tato vybraná klíčová kritéria – Důležitost produktu, Délka projektu, Dostupnost uživatelů, Velikost týmu a Rozmístění. Metodiky použitelné pro projekt jsou ty, jejichž klíčová kritéria projektu se nachází v intervalech vymezených jejich minimem a maximem. V případě, že výsledkem je větší množství než jedna použitelná metodika, jsou dále podrobněji analyzovány

prostřednictvím

výpočtu

odchylek

hodnot

klíčových

kritérií

od optimálních hodnot posuzovaných metodik. Poté jsou stanoveny váhy doplňkových kritérií skupin Proces a Podpora a následně i posouzeny. [6, s. 117] V opačném případě, kdy všechny z posuzovaných metodik přesahují stanovené intervaly a nejsou tak vhodné pro použití v projektu, dochází k podrobné analýze kritérií, jejichž hodnoty se do stanovených intervalů nevešly a následně je vybrána metodika, jejíž překročení má co nejmenší dopad na daný projekt. Může však také nastat situace, že není vybrána žádná z hodnocených metodik. [6, s. 118] Celý postup výběru vhodné metodiky je znázorněn níže na obrázku 5-1 Konceptuálním modelu diagramu tříd.

Obrázek 1-3 Konceptuální model výběru metodiky pro projekt [6, str. 97]

24

5.1 Stanovení vah pro skupiny Produkt a Lidé Pro jasné vyjádření důležitosti jednotlivých kritérií jsou stanovovány hodnoty jejich vah. Čím vyšší hodnotu váhy kritérium má, tím je pro daný projekt důležitější. Posouzení důležitosti jednotlivých kritérií je možno provést dvěma způsoby a to buď za použití již stanovených vah, tak jak je přisoudila jednotlivým kritériím autorka metodiky METES, nebo je možno si stanovit váhy vlastní a to v závislosti na požadavcích a preferencích pro konkrétní projekt. Stanovení vah je možno provést na základě mnoha metod, které se používají právě pro vícekriteriální rozhodování. Mezi nejčastější z nich patří např. Fullerova, Bodovací či Saatyho metoda. Pro projekt Humanet jsem se rozhodla pro stanovení vah jemu odpovídajících a to za pomoci Saatyho kvantitativní metody párového srovnávání. Předpokladem této metody je, že jsou jednotlivé váhy posuzovány přímo na základě znalostí nějakého experta. Expertní zhodnocení, v případě projektu Humanet je provedeno Ing. Romanem Dufkem, vedoucím manažerem projektu. Je založeno na párovém porovnávání vybraných kritérií a určení preferencí. Pro zhodnocení páru kritérií se používá devíti bodová stupnice: 1 – kritériím i a j je přisuzována stejná důležitost, jsou rovnocenná 3 – slabě preferované kritérium i před j 5 – silně preferované kritérium i před j 7 – výrazně preferované kritérium i před j 9 – absolutně preferované kritérium i před j [25] Body 2 (velmi slabě preferované kritérium i před j), 4 (mírně silně preferované kritérium i před j), 6 (velmi silně preferované kritérium i před j) a 8 (velmi výrazně preferované kritérium i před j) mohou být využity jako mezistupně pro přesnější zhodnocení, většinou se však nevyužívají. [18, s. 4-5] Preferenční hodnoty, které přisuzuje expert při hodnocení jednotlivých párů kritérií, jsou zaznamenávány do tzv. Saatyho matice S = (sij).

Jedná se o čtvercovou matici typu n x n, která má na hlavní diagonále samé jedničky, to z toho důvodu, že každé kritérium je samo sobě rovnocenné. Hodnocení párů kritérií je prováděno pomocí základní stupnice, tedy v případě, že je i-tému 25

a j-tému kritériu přisuzována stejná důležitost zapíše se do matice hodnota s ij = 1, pokud je i-té kritérium slabě preferováno před j-tým, zapíše se hodnota sij = 3 apod. Jelikož je Saatyho matice reciproční tzn., že obsahuje převrácené hodnoty s ji =

, zapíší se

v případě preferencí j-tého kritéria převrácené hodnoty, např. j-té kritérium je silně preferováno před i-tým, sij = 1/5. [25] Z jednotlivých prvků matice jsou tak zřejmé odhady podílů vah i-tého a j-tého kritéria. Pro samostatný výpočet vah je možno použít řadu postupů, jak dojít k potřebným výsledkům. Pro posouzení vah projektu Humanet, je pro co nejpřesnější výsledky použit normalizovaný geometrický průměr řádků. Pro každé i jsou spočteny hodnoty [17, s. 9]:

Výpočty vektorů s a r jsou použity jako mezikroky pro výpočet geometrického průměru řádků. Po jejich určení se dále vypočte celková hodnota vektoru r, která je potřebná pro výpočet samotných vah. Vektor v, zde tedy představuje normalizovaný vektor vah, z čehož vyplívá, že součet všech vah posuzovaných kritérií je roven jedné.

[17, s. 9] Přiřazení vah pro projekt Humanet, provedené panem Ing. Romanem Dufkem je uvedeno v tabulce č. 5.1 Stanovení vah kritérií skupin Produkt a Lidé. Zhodnoceno je zde 11 základních kritérií. Nejprve byly určeny preference kritérií nacházejících se pod

u

1

3

5

5

3

7

9

9

5

3

3

0,265

Délka projektu

1/3

1

5

5

3

7

7

7

0

1/3

0

0,109

S tálost požadavků

1/5

1/5

1

1/5

1

1

1/3

1/3

1/5

1/3

1/3

0,024

Znovupoužitelnost

1/5

1/5

5

1

3

1

3

3

1/3

1/3

1/5

0,053

Velikost řešení

1/3

1/3

1

1/3

1

3

3

3

1

3

1/3

0,064

Zkušenost manažera projektu

1/7

1/7

1

1

1/3

1

3

1/3

1/5

1/5

1/7

0,026

Kvalifikace členů týmu

1/9

1/7

3

1/3

1/3

1/3

1

1/5

1/5

1/5

1/7

0,020

Motivace členů týmu

1/9

1/7

3

1/3

1/3

3

5

1

1/7

1/7

1/7

0,030

Dostupnost uživatelů

1/5

3

5

3

1

5

5

7

1

5

1

0,146

Velikost týmu

1/3

3

3

3

1/3

5

5

7

1/5

1

1/5

0,085

Rozmístění

1/3

3

3

5

3

7

7

9

1

5

1

0,179

Zn

Důležitost produktu

st

St álo

po ž

ro d

pr oje kt

Dé lka

st p Dů l ež i to

Stanovení vah kritérií skupin Produkt a Lidé

uk tu

hodnot.

ad av ků ov up ou žit e ln Ve ost li k os tř e še ní Zk uš en os ti m an Kv až al i er fik ap ac ro eč jek le n M tu ůt oti ým va ce u č le nů Do tým stu u pn os tu živ Ve ate li k lů os tt ým u Ro zm íst ěn í Vá hy

hlavní diagonálou, na základě čehož pak došlo k doplnění odpovídajících převrácených

26 Tabulka 1-2 Stanovení vah kritérií Produkt a Lidé

1,000

Jak je již z tabulky zřejmé nejvyšší váhy a tedy důležitost je přidělena právě pěti klíčovým projektovým kritériím - Důležitost produktu, Rozmístění, Dostupnost uživatelů, Délka projektu a Velikost týmů. Mezi další znatelněji preferovaná kritéria poté spadají ještě Velikost řešení a Znovupoužitelnost. Zbývajícím kritériím je přisuzována přibližně stejná výška vah a výše preferencí je mezi nimi tak minimální.

5.2 Stanovení hodnot kritérií skupiny Produkt pro projekt Humanet Jelikož je produkt Humanet softwarem, který podporuje fungování organizace, odpovídá jeho ohodnocení kritéria Důležitost produktu stupeň číslo 2. Délka realizace projektu je vymezena časovým úsekem 12 měsíců, hodnocení kritéria Délka projektu je tedy rovno 3. Veškeré požadavky na projekt Humanet jsou předem definovány, avšak v průběhu vývoje může docházet ke změnám jejich priorit. Kritérium Stálost požadavků je hodnoceno stupněm číslo 3. V rámci řešení projektu je snahou vytvářet znovupoužitelné třídy pouze v rámci jednoho programového prostředí, hodnota kritéria Znovupoužitelnost je dána stupněm číslo 2. Projekt Humanet spadá do skupiny projektů vývoje softwaru a to z toho důvodu, že využívá více než 300 případů užití, kritérium Velikost řešení tak odpovídá hodnocení číslem 5.

5.3 Stanovení hodnot kritérií skupiny Lidé pro projekt Humanet Manažer projektu působí ve své funkci již více než 5 let, hodnocení Zkušenosti manažera tak odpovídá stupni číslo 0. Co se týká kritéria Kvalifikace členů týmů, ten je sestaven z jedinců, jejichž většina je kvalifikovaná, ale zaměřená na určitou specializaci, což odpovídá ohodnocení kritéria stupněm číslo 1. Tým je sestaven z motivovaných jedinců, komunikativních jedinců, kritérium Motivace členů týmu, je tak přiřazeno číslo ohodnocení 1. Protože je systém Humanet vyvíjen jako produkt, který je až následně nabízen cílovým zákazníkům na základě jejich jednotlivých a konkrétních požadavcích, je možné jej dále upravovat. Není uživatel přímo dostupný v průběhu vývoje projektu. Kritérium Dostupnost uživatelů tak splňuje kategorii hodnocenou číslem 5. V týmu se nachází 10 lidí včetně manažera projektu, hodnocení kritéria Velikosti týmu je rovno číslu 1. Někteří z členů týmu však působí i v zahraničí, což má za následek, že kritérium Rozmístění je hodnoceno stupněm 5. Celkové zhodnocení kritérií skupin Produkt a Lidé, provedeno na základě výběru stupně ohodnocení je pro názornost uvedeno v tabulce 5-2 Hodnocení kritérií Produkt a Lidé.

27

Kritérium

Projekt Humanet

Důležitost projektu

2

Délka projektu

3

Stálost požadavků

3

Znovupoužitelnost

2

Velikost řešení

5

Zkušenosti manažera projektu

0


1


1


5

Velikost týmu

1

Rozmístění

5

Tabulka 0-1 Hodnocení kritérií skupin Produkt a Lidé pro projekt Humanet

6 Posouzení použitelnosti vybraných metodik V této kapitole jsou charakterizovány a analyzovány veškeré metodiky, které jsou v rámci METES definovány.

6.1 Metodika Rational Unified Process (RUP) Metodika Rational Unified Process byla představena společností Rational v roce 1995 jako Rational Objectory Process. Jedná se o nejznámější rigorózní metodiku vůbec, v současné době je však ve velkém rozšiřována o agilní praktiky. Svému uplatnění se těší především ve velkých softwarových společnostech, o čemž také svědčí to, že v roce 2002 byla pak odkoupena od firmy Rational společností IBM, která ji nadále rozvíjí. 6.1.1 Charakteristika RUP Většinou je jí stále, i přes možnosti používat ji jako agilní metodiku, přisuzován přívlastek těžké, detailně propracované, robustní metodiky. Tato metodika plně pokrývá většinu projektových i technických procesů, stejně tak jako procesy týkající se implementace softwaru a jeho podpory. Jedná se o silně objektově orientovanou metodiku, která je úzce spjata s modelovacím jazykem UML, ve kterém jsou vytvářeny veškeré modely a Use case (případy užití). Jejím kladem může být právě její propracovanost, takže každý z členů týmu ví vždy, co má kde, kdy a jak udělat. Původně byla spíše vhodná pro větší, složitější a důležitější projekty, na kterých se podílely velké týmy, avšak díky jejímu vývoji nyní tvoří rámec, který je možno použít 28

i pro projekty s menší důležitosti, tvořené menším počtem vývojářů. Je také podporována různými nástroji a šablonami. Tato metodika využívá iterativní model životního cyklu softwaru. Proces vývoje softwaru je možné zobrazit ve dvou základních dimenzích, jak je znázorněno na obrázku 6-1 Fáze a disciplíny RUP.

Obrázek 6-1 Fáze a disciplíny RUP [29]

Horizontální osa představuje dynamický pohled na proces, který je vyjádřen pomocí cyklu, fází, iterací a milníků. Vertikální osa reprezentuje statické hledisko procesu, popis činností, artefaktů, pracovníků a pracovních toků. [6, s. 122] Celý životní cyklus vývoje softwaru je prováděn ve čtyřech fázích: [2, s. 24] Fáze počáteční či zahajovací (Inception), Fáze elaborační, či projektovací (Elaboration), Fáze konstrukční, či realizační (Construction) a Fáze nasazení, neboli fáze předání. Počáteční fáze zabírá přibližně 10% celkové doby vývoje softwaru. V této fázi jsou převážně definovány veškeré požadavky na software, postupy a nástroje, které budou při řešení projektu využívány. Na základě toho se i vytváří předběžný model a plánují se iterace, které u metodiky RUP mívají delší časový interval. Součástí plánování je i hrubý odhad nákladů a také analýza možných rizik, které při vývoji mohou nastat. Celá zahajovací fáze nakonec závisí na tom, zda je možné projekt za daných požadavků, zdrojů a dostupných technologií realizovat. Po dokončení fáze první se vytváří návrh realizace, architektura celého projektu a vytváří se detailnější prototypy. Veškeré návrhy musí být schváleny zadavatelem, 29

cílem této fáze je stanovit si přesný plán realizace, určit a vyvinout komponenty, které jsou nezbytné. Celá tato fáze zabírá kolem 30% určené pro projekt. Jak je již zřejmé realizační fáze zabírá nejvyšší časový úsek projektu a zabývá se samotnou realizací projektu, tedy vývoje softwaru. Metodika RUP se snaží o paralelní vývoj řízeny případy užití. V této fázi se kontroluje komplexnost celého systému, průběžně se testuje a kontroluje jeho kvalita. Realizační fáze končí právě dodáním první funkční verze softwaru. Fáze předání zahrnuje činnosti, jako jsou, předání finální verze produktu a to včetně celkové dokumentace a manuálů, instalace, zaškolení uživatelů, údržbu systému či poskytnutí help-desku. Celková doba této fáze tvoří, stejně jako fáze počáteční, přibližně 10% z celkového časového intervalu provedení projektu. Metodika Rational Unified Process podporuje v celém svém životním cyklu řízení kvality produktu, čímž se také snaží zamezit vzniku případných rizik, pomáhá jí k tomu šest základních praktik, kterými se řídí: [2, s. 24-26] iterativní vývoj správa a řízení požadavků použití komponentové architektury vizuální modelování softwaru průběžné zajišťování a ověřování kvality řízení změn 6.1.2 Hodnocení kritérií skupin Produkt a Lidé Na základě propracovanosti této metodiky a jejích vyčerpávajících popisů veškerých činností a procesů, nejsou kladeny až tak vysoké nároky na zkušenosti manažera projektu, stejně tak ani na vysokou kvalifikaci členů týmů. Použití této metodiky je nejvhodnější pro projekty, které jsou vyvíjené v delším časovém úseku, tedy větší projekty, které však nekladou velké nároky na změny. Je vhodná i pro řešení projektů s omezeným přístupem uživatelů podílejících se na řešení.

30

Graf 6-1 RUP - Kritéria Produkt a Lidé - min, max, opt

Na grafu výše jsou zaneseny minimální, maximální a optimální hodnoty kritérií skupin Produkt a Lidé, tak jak je stanovila autorka pro posuzování systému metodik METES. Minimální hodnoty určují, za jakých minimálních podmínek lze metodiku ještě použít, naopak maxima určují hodnoty, které metodika překročit nemůže. Optimální hodnoty kritérií mapují, kdy je použití metodiky pro projekt nejvhodnější a její zavedení nejefektivnější. 6.1.3 Posouzení použitelnosti RUP pro projekt Humanet V následující tabulce jsou znázorněny veškeré hodnoty potřebné pro analýzu vhodnosti zavedení metodiky RUP pro projekt Humanet na základě hodnocení systému METES. Určení a způsob výpočtu vah je uveden výše v kapitole č. 5.1. Minima, maxima a optima stanovená pro danou metodiku, jsou uvedena tak, jak je definovala autorka systému METES Ph.D. Alena Buchalcevová. Pro hodnocení RUP je vybrána rozsáhlá, těžká verze Rational Unified Process 2003.06.15.

31

RUP

váhy

min

max

za hranicemi extrémů

projekt Humanet

opt

vzdálenost od optim. hodn.

vážené abs. hodn. vzdáleností od optima


0,265

2

5

5

2

0

-3

0,795

Délka projektu

0,109

2

5

4

3

0

-1

0,109


0,024

2

5

2

3

0

1

0,024

Znovupoužitelnost

0,053

0

4

3

2

0

-1

0,053

Velikost řešení

0,064

2

5

5

5

0

0

0,000


0,026

0

4

4

0

0

-4

0,102


0,020

0

5

5

1

0

-4

0,078


0,030

0

4

4

1

0

-3

0,090


0,146

0

4

4

5

1

1

0,146

Velikost týmu

0,085

2

5

5

1

-1

-4

0,340

Rozmístění

0,179

0

5

5

5

0

0

0,000

1,000

1,737

Tabulka 6-1 Posouzení použitelnosti metodiky RUP pro projekt Humanet

Ohodnocení projektu Humanet je provedeno na základě charakteristik projektu a za pomoci pana Ing. Romana Dufka ze společnosti HOUR, spol. s r.o. Jednotlivé číselné hodnoty, které jsou u projektu uvedeny, jsou stanoveny dle toho, kterému stupni ohodnocení dané kritérium pro projekt přísluší. Ve sloupci označeném „za hranicemi extrému“ jsou sledovány hodnoty, které se vychylují z intervalu minim a maxim ve kterých lze metodiku možno použít. Pokud se projekt Humanet plně vejde do tohoto intervalu je zde uvedena hodnota nuly, v případě, že do stanoveného intervalu nespadá je uvedeno, o kolik jej Humanet přesahuje. Pět projektově klíčových kritérií, které hrají v hodnocení zásadní roli je vyznačeno modře. Jak je tedy z tabulky 6-1 patrné, projekt Humanet v případě metodiky RUP přesahuje dvě z pěti klíčových projektových kritérií a to kritéria Dostupnost uživatelů, kde přesahuje maximální hodnotu ve které je metodika RUP použitelná a Velikost týmu, kde naopak dosahuje hodnoty nižší, než ve které lze metodiku zavést. Jelikož v hodnocení dochází k překročení, a to více než ve dvou, z projektových klíčových kritérií, znamená to, že je metodika Rational Unified Process pro projekt Humanet nepoužitelná. Dále jsou v tabulce ještě uvedeny vzdálenosti projektu Humanet od optimálních hodnot metodiky RUP ve kterých je její použití nejefektivnější. Hodnoty definující vzdálenosti od optima jsou poté ještě využity k výpočtu absolutních hodnot vzdáleností od optima, kde jsou jejich absolutní hodnoty vynásobeny váhami kritérií, celkový 32

součet těchto hodnot pak udává o kolik, se celkově hodnoty kritérií projektu Humanet liší od optimálních hodnot metodiky RUP. Překročení intervalu hodnot, kdy je metodiku RUP možné použít, je lépe vidět z grafu níže, kde jsou porovnány minimální hodnoty, maximální hodnoty a hodnoty projektu stanovené pro projekt Humanet.

Graf 6-2 Posouzení použitelnosti metodiky RUP pro projekt Humanet

6.2

Metodika Microsoft Solution Framework (MSF) Je metodika, která byla uveřejněna v roce 1993 společností Microsoft. Zahrnuje

praktiky zabývající se vývojem softwaru. V mnoha případech bývá označována spíše pouze jako obecný metodický rámec, který má za úkol řízení procesů pří vývoji softwaru. [20, s. 1-4] 6.2.1 Charakteristika metodiky Metodika MSF je ovlivněna myšlenkami extrémního programování a dělí se na dva metodické rámce a to MSF for Agile Software a MSF for CMMI Process Improvement. [4, s. 115] Metodika MSF for Agile Software je, jak je již patrné přímo z jejího názvu, metodikou zaměřenou na agilní vývoj softwaru a je tak vhodnější spíše pro menší projekty na kterých se podílí menší týmy. Zatímco MSF for CMMI Process Improvement je metodika, která je založena na o něco formálnějších postupech. CMMI je označení pro Capability Maturity Model Integration, tedy Integrační model zralosti. Jedná se o referenční model procesů a postupů, který zahrnuje doporučení na základě 33

kterých, by se vývojářský tým měl řídit. Model zralosti obsahuje pět úrovní, MSF for CMMI Process Improvement odpovídá jejímu třetímu stupni a to zralosti definované. Definovaná úroveň zralosti říká, že je definován proces na úrovni organizace, který

je

popsán

ve

standardech,

procedurách,

nástrojích

a

metodách

a institucionalizován, je definováno i přizpůsobování procesů podle typu projektu [6, s. 24] Obecný rámec definovaný metodikou Microsoft Solution Framework zastřešuje tři následující oblasti: Základní principy Týmový model Procesní model Základní principy definují veškeré zásady, které jsou společné pro všechny členy týmu podílející se na vývoji. Mezi nejzákladnější z nich bych zahrnula partnerství se zákazníkem, to má za cíl zabezpečit dobrou komunikaci mezi týmem a zákazníkem, postavenou na stanovení společných cílů. Dalším z důležitých principů je, aby byli zapojeni všichni členové týmu, kteří budou spolupracovat na uskutečnění definované vize, která je všem společná. Důraz je přitom kladen také na kvalitu vyvíjeného produktu a snahu rychlého přizpůsobení se vznikajícím změnám. Týmový model určuje organizovanost jednotlivých pracovníků a jimi prováděných činností. Jak je znázorněno na obrázku 6-2 skládá se tento model ze sedmi skupin, které jsou rozděleny na základě činností a zaměření, kterými se zabývají, ke každé skupině je určen i odpovědný pracovník, všichni členové týmu jsou si však rovni. Tyto skupiny je i možno buď různě rozšiřovat, nebo právě naopak zmenšovat dle potřeb konkrétního projektu.

Obrázek 6-2 Týmový model MSF [20]

34

Každá role v týmu plní určité činnosti, jejichž výsledkem jsou pak pracovní produkty. Např. v rámci projektového řízení se jedná především o činnosti spojené se splněním veškerých požadavků zadaných zadavatelem. Veškerá práce, kterou jednotlivý členové týmu provádějí je pečlivě plánována a kontrolována za pomocí pracovních položek. V projektovém portálu se pak dále ještě generují reporty, které slouží k podpoře řízení celého projektu. Procesní model MSF je iterativní s opakujícími se krátkými vývojovými cykly, které na sebe navazují. Každý z tohoto cyklu je ukončen přidáním nebo pravou funkčnosti softwaru. Procesní model se dělí do pěti fází [20, s. 5-6] Tvorba vize – dohodnutí společného cíle projektu, jeho základních vlastnostech a předběžném harmonogramu Plánování – tvorba plánu jednotlivých iterací, tato fáze je ukončena po jejich veškeré definici Vývoj – tvorba kódu, jeho testování, vytváření dokumentace Stabilizace – testování a ověřování celkové kvality systému, kontrola možné implementace a splnění definovaných požadavků. Nasazení – samotná implementace systému u zákazníka Veškeré fáze jsou znázorněny na obrázku 6-3 Procesním modelu MSF.

Obrázek 6-3 Procesní model MSF

V rámci MSF jsou zahrnuty tři disciplíny, které jsou spojeny s řízením projektu – samotné řízení projektu, příprava týmu a risk management. MSF for CMMI pokrývá téměř všechny procesy podporující projekty na úrovni organizace, projektové procesy, technické procesy, procesy implementace software tak i procesy pro podporu softwaru. Jedná se další z těžkých metodik, která podrobně popisuje veškeré procesy a je založena na iterativním vývoji.

35

6.2.2 Hodnocení kritérií skupin Produkt a Lidé Pro zhodnocení jak kritérií skupin Produkt a Lidé tak i pro posouzení použitelnost metodiky pro projekt Humanet je zvolena verze MSF for CMMI Processs Improvement a to verze 4.0. Tato metodika se řadí mezi těžší společně s metodikou RUP, detailně popisuje veškeré procesy související s životním cyklem produktu a je tedy spíše určena pro velké, důležité projekty, jejichž vývoj může trvat až 24 měsíců. Na těchto projektech se může i podílet více týmů, které se mohou nacházet i v různých zemích. Díky dobrému popisu jednotlivých procesů nejsou kladeny vysoké nároky na odbornou kvalifikaci manažera projektu, ani členy týmu. Požadavky na projekt lze definovat předem, i když se následně mohou z části měnit, například jejich priority, proto je zde přítomnost zadavatele důležitá hlavně na začátku a konci projektu. Metodika MSF CMMI se snaží vytvářet znovupoužitelné komponenty v rámci projektu, tato metodika je velice úzce spjata s Visual Studio Team System. V grafu 6-3 jsou zachycena optima, minima a maxima určená pro metodiku MSF CMMI. Jak je vidět většina optimálních hodnot se shoduje s maximálními hodnotami, ve kterých lze metodiku zavést.

Graf 6-3 MSF CMMI - min, max, opt

6.2.3 Posouzení použitelnosti metodiky MSF CMMI pro projekt Humanet Projekt Humanet se u metodiky MSF CMMI vejde do všech stanovených intervalů minimálních a maximálních hodnot až na jedno z klíčových kritérií a to Dostupnost uživatelů. Z hlediska systému METES je i tato metodika pro daný projekt 36

nepoužitelná, protože je překročena hranice u jednoho z klíčových projektových kritérií. Další z jejich výhod je i úzká provázanost na Visual Studio Team System, které je ve společnosti HOUR, spol. s r.o. již zavedeno a členové týmu by se mu nemuseli nově učit. Co se týká optimálních hodnot, těch metodika dosahuje v kritériích Stálost požadavků, Velikost řešení a Rozmístění.

MSF CMMI

váhy

min

max


projekt Humanet

opt




0,265

2

5

5

2

0

-3

0,795

Délka projektu

0,109

2

5

4

3

0

-1

0,109


0,024

2

5

3

3

0

0

0,000

Znovupoužitelnost

0,053

0

4

3

2

0

-1

0,053

Velikost řešení

0,064

2

5

5

5

0

0

0,000


0,026

0

4

4

0

0

-4

0,102


0,020

0

5

5

1

0

-4

0,078


0,030

0

4

4

1

0

-3

0,090


0,146

0

4

4

5

1

1

0,146

Velikost týmu

0,085

1

5

5

1

0

-4

0,340

Rozmístění

0,179

0

5

5

5

0

0

0,000

1,000

1,713

Tabulka 6-2 Posouzení použitelnosti metodiky MSF CMMI pro projekt Humanet

Jak je z grafu vidět, metodika MSF CMMI přesahuje daný interval pouze jednou a to v maximu u kritéria Dostupnost uživatelů.

Graf 6-4 Posouzení použitelnosti metodiky MSF CMMI pro projekt Humanet

37

6.3 Metodika OpenUP Metodika OpenUP se řadí mezi relativně nové agilní metodiky. Vznikla v roce 2007 na základě odlehčení metodiky Unified Process a je dostupná pod Eclipse Public Process. 6.3.1

Charakteristika metodiky Jedná se o open-source metodiku, která využívá jako metodika RUP iteračního

či inkrementálního modelu životního cyklu softwaru a stejně tak je postavena na případech užití a snaží se o co největší eliminaci případných rizik, které by mohly při vývoji vzniknout. OpenUP je postaven na čtyřech základních pravidlech, které uvádí Manifest agilního vývoje softwaru. Konkrétní pravidla metodiky OpenUP a principy manifestu jsou pro srovnání uvedeny v tabulce 6-3. Principy metodiky OpenUP

Základní pravidla Manifestu agilního vývoje

Spolupráce na společných zájmech a sdílení porozumění. Hodnocení konkurenčních priorit s cílem maximalizovat hodnoty pro zákazníka. Zaměření na architekturu a organizovaný vývoj s cílem minimalizace rizik

Individualita a komunikaci je upřednostněna před procesy a nástroji. Spolupráce se zákazníkem je důležitější než vyjednávání o smluvních podmínkách. Fungující software má přednost před vyčerpávající dokumentací. Reakce na změny jsou vítány před striktním dodržováním plánu.

Průběžné získávání zpětné vazby a zlepšování.

Tabulka 6-3 Mapování principů OpenUP a Manifestu agilního vývoje [13, s. 4]

Metodika OpenUP je označována jako minimálně dostatečná, což znamená, že i přes její kompletnost a rozsah se dá dále velice snadno rozšířit a přizpůsobit na základě požadavků, které jsou na vyvíjený produkt kladeny. Jejím základním rysem je oddělenost znovupoužitelného metodického obsahu a procesního obsahu, v tom jsou vybírány jednotlivé části z obsahu metodického, které jsou pak následně provázány v souvislosti s řízením daných postupů. [4, s. 117]

METODICKÝ RÁMEC Metodický obsah    

produkty role úlohy návody

Procesní obsah    

popis produktu popis rolí popis činností vzor schopností

 dodávka

Obrázek 6-4 Metodický rámec

38

Jak je vidět na obrázku 6-4 Metodický obsah zahrnuje definici produktů, rolí, úloh a návodů, procesní obsah pak určuje životní cyklus daného projektu a sleduje ho z časového hlediska. Metodický obsah je rozdělen do tří základních úrovní. V první úrovni je analyzována práce jednotlivců a to jak přispěli k postupu ve vývoji, tento pokrok je měřitelný za pomoci tzv. mikro-přírůstku. Druhá úroveň sleduje pokrok ve vývoji z hlediska celého týmu, ten je ohodnocovaný na základě týdenních iterací. Hlavním cílem této úrovně je testování softwaru a dokončení verze softwaru, který bude bez problému spustitelný. Třetí úrovní metodického obsahu je samotný životní cyklus projektu, ten je opět jako u metodiky RUP rozdělen do čtyř základních fází a to fáze zahájení, rozpracování, konstrukce a zavedení. Metodika definuje 3 základní prvky a to: Role -

tým metodiky OpenUP se skládá ze sedmi základních rolí a to,

projektového manažera, analytika, architekta, vývojáře, testera, zainteresované strany a kohokoliv. Všechny tyto role jsou na sobě vzájemně závislé a každá z nich má v rámci iterací dané úkoly, které musí splnit. Projektový manažer je jednou z klíčových rolí projektu, vytváří časový harmonogram, projektový a iterační plán z čehož vyplívá jeho celková zodpovědnost za projekt jako celek, včetně jeho úspěšného dokončení a předání finálního produktu zákazníkovi. Analytik má za úkol komunikovat se zainteresovanou stranou a stanovit rozsah vyvíjeného systému a určit veškeré požadavky na software, včetně jejich priorit. Architekt pak definuje veškeré artefakty a technické potřeby spojené s návrhem architektury projektu. Cílem vývojáře je rozvoj jednotlivých částí projektu, do jeho kompetencí spadají činnosti, jako jsou návrh systému a vytvoření jeho prvků, vytvoření skriptu a implementace produktu. Tester má za úkol otestování softwaru v průběhu celého vývoje jeho tvorby, má tak zaručit a zajistit jeho bezchybnou funkčnost. Zainteresovanou stranou v tom o případě rozumíme koncové uživatele, které mohou výsledek a průběh celého vývoje softwaru znatelně ovlivnit, na základě měnění svých požadavků. Jako kohokoliv označujeme osobu, která zadává žádosti pro uskutečnění změn v projektu, jelikož není tato osoba přímo identifikována, může jí být kdokoliv z členů týmů podílejícího se na projektu. Disciplína – je postavena na vodopádovém modelu vývoje tzn., že veškeré skupiny úloh, které spolu určitým způsobem souvisí a jsou zahrnuty právě v rámci nějaké disciplíny, se pro lepší organizovanost řídí právě tímto modelem. 39

OpenUP je rozdělen do těchto disciplín – Požadavky, Architektura, Vývoj, Testování, Řízení projektu, Řízení konfigurací a změn. [6, s. 130] Úloha – jedná se o činnost, která je vykonávána jednotlivými rolemi v týmu. Metodika OpenUP zahrnuje 18 definovaných úloh, v jejichž rámci jsou určovány pracovní produkty. [6, s. 130] Vybrané prvky z metodického obsahu se ukládají do tzv. vzorů schopností, které jsou součástí procesního obsahu. Tyto vzory slouží buď jako jednotlivé dílčí, v tomto případě popisují jednu konkrétní oblast z vývoje, jako je např. zahájení projektu, nebo jsou seskupeny a tvoří šablonové vzory. Výsledkem je kompletní procesní šablona iterací, kterou je možno opakovaně užívat dle potřeb. Celý vývoj metodiky OpenUp, je jak, již bylo řečeno, rozdělen do čtyř fází, které jsou znázorněny na obrázku 6-5.

Obrázek 6-5 Proces metodiky OpenUP [13, s.7]

V první fázi zahájení jsou určeny milníky životního cyklu objektu, po iteraci, či několika iteracích přechází do druhé fáze, kde je definována architektura vznikajícího produktu. Poté opět po určitém počtu iterací dochází do třetí fáze, ve které je ověřována schopnost provozu software. V závěru dochází k posledním nutným iteracím vyzkoušení softwaru a následnému zavedení produktu u zákazníka. Metodika OpenUP je vhodná spíše pro realizaci projektů v menších týmech, je však snadno rozšiřitelná a přizpůsobitelná. Co se týká hlediska pokrytí procesů, pokrývá tato metodika pouze částečně přibližně polovinu projektových procesů. Většina jejího zaměření je pak zahrnuta v procesech implementace softwaru a podpory softwaru. 6.3.2 Hodnocení kritérií skupin Produkt a Lidé Metodiku OpenUP je vhodné použít při krátkodobých projektech, které mají být realizované přibližně do šesti měsíců a u kterých se předpokládá vysoká proměnlivost požadavků v průběhu vývoje. Určená je tedy spíše pro projekty, které nemají životní důležitost a je řešena menšími týmy. Díky tomu, že se jedná o variantu open-source metodiky jsou k dispozici různé šablony, využívá tedy již hotových komponent, což

40

ve výsledku neklade vysoké požadavky na zkušenosti a dovednosti vedoucího projektu, ani na vysokou kvalifikaci členů týmů či jejich morální motivovanost. Na grafu 6-5 jsou zachyceny minimální a maximální hodnoty, při kterých je možno OpenUP ještě použit. Současně jsou zde zaneseny optimální hodnoty, při jejichž splnění metodika plně zastoupí veškeré požadavky související s vývojem a zajistí tak kvalitní výsledný produkt.

Graf 6-5 OpenUP – min, max, opt

6.3.3 Posouzení použitelnosti metodiky OpenUP pro projekt Humanet V tabulce níže máme opět uvedeny stanovené váhy důležitosti produkty, minima a maxima použitelnosti metodiky a její optimální hodnoty, které jsou pro posouzení použitelnosti metodiky OpenUP pro projekt Humanet nezbytné. Jak můžeme vidět, hodnocený projekt přesahuje tři z posuzovaných kritérií, přičemž dvě z nich jsou opět kritérii klíčovými pro projekt a to Dostupnost uživatelů a Rozmístění. Projekt Humanet je posuzován jako velký projekt, zatímco metodika OpenUP, jak již bylo zmíněno, je vhodná právě naopak pro projekty menší. Uživatel není v rámci projektu téměř dostupný, což není vzhledem k měnícím se požadavkům zcela úměrné, přesahuje projekt Humanet interval vymezený pro dostupnost uživatele. Díky tomu, že metodika OpenUP má být aplikována spíše v na menších projektech, pracuje na vývoji i menší množství lidé, jejichž rozmístění by mělo být ideálně v jedné místnosti. Posuzovaný projekt však splňuje naprosto opačné podmínky.

41

OpenUP

váhy

min

max


projekt Humanet

opt




0,265

0

2

2

2

0

0

0,000

Délka projektu

0,109

0

4

2

3

0

1

0,109


0,024

1

5

1

3

0

2

0,048

Znovupoužitelnost

0,053

0

3

2

2

0

0

0,000

Velikost řešení

0,064

0

3

2

5

2

3

0,193


0,026

0

4

4

0

0

-4

0,102


0,020

0

5

5

1

0

-4

0,078


0,030

0

4

4

1

0

-3

0,090


0,146

0

3

3

5

2

2

0,291

Velikost týmu

0,085

0

2

2

1

0

-1

0,085

Rozmístění

0,179

0

1

1

5

4

4

0,716

1,000

1,713

Tabulka 6-4 Posouzení použitelnosti metodiky OpenUP pro projekt Humanet

Metodika OpenUP, přesahující opět dvě z pěti klíčových projektových kritérií, je stejně jako metodika RUP posouzena jako nepoužitelná pro projekt Humanet.

Graf 6-6 Posouzení použitelnosti metodiky OpenUP pro projekt Humanet

V grafu 6-6 jsou pro přehlednost znázorněny minimální a maximální hodnoty, ve kterých lze metodiku OpenUP aplikovat na projekt, aby měl předpoklady pro jeho úspěšné splnění. Jsou zde přehledněji zviditelněné hodnoty kritérií, ve kterých projekt Humanet dané intervaly přesahuje – kritéria Velikost řešení, Dostupnost uživatelů a Rozmístnění. 42

6.4 Metodika Feature Driven Development (FDD) Metodika Feature-Driven Development je zástupcem agilních metodik a to i přes to, že je o něco formálnější než běžné agilní metodiky jako je např. Extrémní programování. Tato metodika i přes veškeré agilní principy stále zdůrazňuje potřebu předchozího modelování.

Feature-Driven Development vzniklo na konci 90. let

20. stolení a jejími autory jsou Jeff De Luca a Peter Coad. 6.4.1 Charakteristika metodiky FDD je založeno na krátkém iterativním vývoji a to většinou ve dvou-týdenním intervalu. V průběhu iterace dochází k návrhu a provedení tzv. užitných vlastností. Užitná vlastnost je důkazem funkčnosti produktu, jedná se o srozumitelný, měřitelný a realizovatelný důkaz, který má důležitou hodnotu pro zákazníka. [16, s. 177-182] Metodika si tedy potrpí na řízení kvality v průběhu celého vývoje softwaru. Snaží se o snížení rizik a nejistoty při vývoji. U zadavatelů projektů je tato metodika oblíbená díky průběžné dodávce nových verzí produktu, ten je tedy neustále informován jakým směrem se ubírá celý proces vývoje a v jaké fázi se právě nachází. Životní cyklus metodiky Featre Driven Development je rozdělen do pěti fází [6, s.138]: Tvorba celkového modelu Seznam užitné vlastnosti Plánování užitné vlastnosti Návrh užitné vlastnosti Realizace užitné vlastnosti

Obrázek 6-6 Fáze životního cyklu FDD

Výše na obrázku 6-6 je znázorněno pět fází vývoje, podle metodiky FDD. Jak je zřejmé ve všech fázích se metodika převážně věnuje právě specifikacím týkajících se užitných vlastností. Vynechává tak například některé fáze jako jsou u metodiky OpenUP, nebo RUP, fáze zabývající se dodáním produktu apod. První krok vývoje této metodiky začíná vypracováním modelu životního cyklu produktu. To je možné např. pomocí notace UML. Na základě případu užití, pak lze určit skupina nejzákladnějších vlastností, které musí software naplňovat. Budoucí uživatele při společné práci 43

s vývojáři určí základní požadavky, které by měl systém splňovat. Výsledek celé této fáze může prezentován prostřednictvím diagramu tříd. Je tak vytvářen základní model celkové projektu, který je postupně doplňován o další požadavky. Ve druhé fázi dochází k vytvoření seznamu, jehož obsahem jsou, užitné vlastnosti, které jsou hodnoceny na základě určení jejích preferencí. Užitné vlastnosti jsou v tomto seznamu detailněji rozděleny do různých kategorií. Cílem třetí fáze je, rozplánovaní vývoje na základě seznamu vytvořeného v přecházející fázi. Na základě určených se sestaví pořadí, ve kterém budou jednotlivé vlastnosti zaváděny do systému. Čtvrtá fáze má za úkol, podrobné zpracování návrhu projektu na základě užitných vlastností, které jsou rozděleny mezi členy týmu podle toho, kdo za danou vlastnost zodpovídá. V závěrečné fázi realizace je vyvíjeny systém realizován a testován osobou zodpovědnou za určitou třídu. Praktiky FDD: [6, s. 136-138] Doménové objektové modelování – model pro celkový rámec metodiky, který je pak dále rozvíjen na základě užitných vlastností. Vývoj dle užitných vlastností – veškerý vývoj FDD je závislý na stanovených užitných požadavcích. Individuální vlastnictví tříd – je prosazováno individuální vlastnictví kódu, každý z členů pracuje na jemu určené části. Díky tomu je viditelné, kdo zodpovídá za integritu dané části. Týmy použitelné pro vlastnosti – každé užitné vlastnosti je přisouzen člen týmu, který zodpovídá za jeho správné zavedení. Jsou vytvářeny přímo týmy pro užitné vlastnosti, kde se seskupují vlastníci jednotlivých tříd. Inspekce – dohlíží na to, aby byla kvalita vyvíjeného produktu co nejvyšší a to od návrhu až po samotný kód. Pravidelné buildy – v pravidelných časových úsecích dochází k seskupení jednotlivých částí kódů, ty jsou pak posuzovány jako celek. Řízení konfigurací – zdrojového kódu, specifikace požadavků, analýzy a testování. Reporting – snaha o eliminaci počtu činností, které by souviseli se sběrem informací, v jakém stavu se vyvíjený projekt nachází.

44

Metodika FDD pokrývá určitou podporu projektových procesů a dále je zaměřena spíše na podporu procesů implementace, jako jsou detailní návrh, konstrukce a integrace softwaru. Dále zastřešuje většinu procesů pro podporu vývoje softwaru. 6.4.2 Hodnocení kritérií skupin Produkt a Lidé Metodika FDD je hůře dostupná a není dodávána s nástroji pro správu, proto je zde nezbytné zastřešit před samotným vývojem modelování předem, což však také tato metodika vyžaduje a prosazuje. Díky tomu je možné tuto metodiku zavést i u projektů s vyšší důležitostí. Optimální doba stanovená pro uskutečnění projektu kolem šesti měsíců. Jelikož se jedná o agilní metodiku, není stanovení požadavků předem striktně dáno, v průběhu celého vývoje se mohou různě měnit s tím je však také spojena potřeba účasti zákazníka na projektu, není nutné, aby byla denní, ale jsou zde kladeny vyšší nároky z důvodů změn. Díky popisu procesů a dobrému řízení kvality produktu není kladen až tak velký důraz na odborné znalosti manažera projektu ani jednotlivé členy týmu. Velikost týmu je na střední úrovni, tedy projekt vedený pod metodikou FDD lze vyvíjet jak v menším, tak větším počtu jednotlivců, optimální hodnot se pohybuje přibližně kolem 15 lidí. Tým by měl být pohromadě, nejlépe na jednom místě. Na grafu níže jsou opět zachyceny optima, minim a maxim odpovídající metodiky Featrue-Driven Development. Tak jak jsou vymezeny pro hodnocení metodikou METES.

Graf 6-7 FDD - min, max, opt

45

6.4.3 Posouzení použitelnosti metodiky FDD pro projekt Humanet Metodika FDD je již třetí z posuzovaných metodik, která opět překračuje intervalové rozpětí metodiky FDD dané jejími minimálními a optimálními hodnotami. V tomto případě dochází k překročení kritéria Velikost řešení, projekt Humanet je totiž postaven na více než 300 případů užití, což řadí tento projekt do kategorie velkých projektů. Je vidět, že dochází k opětovnému překročení stejných klíčových projektových kritérií – Dostupnost uživatelů a Rozmístění, avšak u metodiky OpenUP bylo toto překročení o jeden stupeň, v případě metodiky FDD se jedná o případ opačný, překračuje dané intervaly o celé 4 stupně. Veškeré tyto hodnoty posouzení jsou zaznamenány v tabulce níže.

FDD

váhy

min

max


projekt Humanet

opt




0,265

0

3

3

2

0

-1

0,265

Délka projektu

0,109

0

4

2

3

0

1

0,109


0,024

1

3

1

3

0

2

0,048

Znovupoužitelnost

0,053

0

2

2

2

0

0

0,000

Velikost řešení

0,064

0

4

5

5

1

0

0,000


0,026

0

3

3

0

0

-3

0,077


0,020

0

3

3

1

0

-2

0,039


0,030

0

2

2

1

0

-1

0,030


0,146

0

1

1

5

4

4

0,582

Velikost týmu

0,085

0

4

3

1

0

-2

0,170

Rozmístění

0,179

0

1

1

5

4

4

0,716

1,000

2,036

Tabulka 6-5 Posouzení použitelnosti metodiky FDD pro projekt Humanet

Na grafu posouzení použitelnosti metodiky Feature-Driven Development pro projekt Humanet jsou srovnány minimální a maximální hodnoty metodiky s hodnotami projektu Humanet. U kritérií Dostupnost uživatelů a Rozmístění jsou znatelné velké rozdíly mezi hodnotami definovanými pro projekt a hodnotami vymezeními optimem.

46

Graf 6-8 Posouzení použitelnosti metodiky FDD pro projekt Humanet

6.5 Metodika Scrum Scrum je řazen mezi jednu z nejznámějších a nejpoužívanějších agilních metodik. Představena byla v roce 2002 a jejími autory jsou, Ken Schwabe, Jeff Stuherland a Mike Beedle. 6.5.1 Charakteristika metodiky Metodika Scrum se zabývá spíše komunikací mezi členy týmů snahou rychle a pružně reagovat na změny, než postupovat podle přesně definovaných procesů vývoje. Veškeré procesy jsou samo-organizovány. Scrum je metodika postavená na iteračním vývoji, snaží se dodávat fungující části aplikace v co nejkratším čase a na základě zpětné vazby u zákazníka aplikuje a upravuje vyvíjený software podle jeho nových požadavků.

Obrázek 6-7 Scrum - popis procesů [1]

47

Metodika Scrum je rozdělena do tří základních fází. Celý její proces je zachycen na obrázku 6-7. První fázi můžeme označit jako plánovací. Tato fáze zahrnuje plánování postupných dodávek softwaru včetně jeho celkového prvotního návrhu. Nejdůležitější části je však definice zákazníkových požadavků na vyvíjený systém, včetně uvedení jejich priorit. Tyto požadavky se uvádějí ve formě tzv. User stories (požadavky mluvící řečí zákazníka) a jsou evidovány v nejdůležitějším dokumentu metodiky Scrum nazvaném, Product backlog. Veškeré položky, které tento dokument obsahuje, jsou neustále aktualizovány a udržovaný na jednom místě, díky tomu je zde lepší možnost sledování veškerých jejích změn a rychlé přizpůsobení. Druhou fází je samotný vývoj, ten je zaznamenáván v tzv. Sprintech, které se odehrávají v rozmezí jednoho týdne až třiceti dní. Na konci každého Sprintu, jeden, nebo více týmů představí výsledky, kterých dosáhli. V každé iteraci aktuálního Sprintu jsou zpracovávány požadavky, které byly definovány v Product backlogu pro daný časový úsek tzn., že v průběhu každého z nich je zpracovávána jen část z uvedených požadavků. Pro měření procesu definuje metodika Scrum Burn-down chart, ten umožňuje sledování již odvedené práce na produktu a usnadňuje určování množství práce, kterou je nezbytné udělat k dokončení ať už Sprintu či celého vyvíjeného produktu. Ukázka možného reportu Burn-down chartu je znázorněna na obrázku níže.

Obrázek 6-8 Scrum - Burndown Report [1]

Poslední fází metodiky je samotná dodávka, ke které dojde, pokud jsou již veškeré požadavky uvedené v Product backlogu zpracované a neobsahují již žádné nové. To má za následek ukončení cyklu Sprintů. Výsledný produkt je pak dále integrován a jsou testovány jednotlivé moduly, veškerá dokumentace k produktu se zpracovává až v této fázi.

48

Metodikou Scrum je původně určena pro menší týmy o počtu přibližně sedmi členů. Definuje tak pouze tři základní role, a to Scrum Mastera, Product Ownera a Tým vývojářů. Scrum master je řídícím prvkem celého týmu, jeho povinností je naslouchat potřebám a pomáhat mu, jeho úkolem je tým budovat a provádět ho Scrumem. Má také za úkol zabránit prodlevám ve vývoji a podporovat jednotlivé procesy. Product Owner je zadavatelem prací, zastupuje zákazníka a jeho vizi projektu. Jeho úkolem je definovat funkce, určovat jejich priority, poskytovat zpětnou vazbu, koordinovat a přijímat či zamítat prezentované výsledky. [1] Tým vývojářů se skládá z menšího počtu členů, nejsou zde přesně definovány jednotlivé role členů týmu, jako u předchozích metodik, např. analytik, architekt apod., dochází k totiž k jejich prolínání. Úkolem týmu je definovat technické odhady, náročnost produktu, vývoj produktu a jeho kvalita. Metodika Scrum je založena na několik praktikách, které ji dělají tak jedinečnou a odlišují od metodik ostatních. Jednou těchto praktik je jsou pořádány každodenní porady neboli Scrum meetings, kde se sleduje postup při vývoji projektu a jsou analyzovány možné překážky, které by mohly tento vývoj narušit. Tyto porady jsou řízené Scrum Masterem a účastní se jich všichni členové týmu včetně manažerů. Každý člen týmu musí zodpovědět na následující tři otázky [6, s. 144] Které položky si dokončil od minulé porady? Jaké jsou nové úkoly, které bude řešit? Jaká jsou možná mezení a překážky, která brání při řešení úkolu? Scrum částečně pokrývá v rámci procesů podporujících projekty na úrovni organizace činnosti spojené s řízením životního cyklu modelu, dále pokrývá projektové procesy, část technických procesů a procesy softwarové implementace související s analýzou softwarových požadavků a integrací softwaru. Je zaměřen převážně na procesy související s oblastí řízení. 6.5.2 Hodnocení skupin Produkt a Lidé Metodika Scrum, je definována jako lehká agilní metodika založená na iterativním vývoji. Její použití se doporučuje projekty realizované do jednoho roku, je však také vhodná pro velmi krátké projekty. Ve své podstatě se dá použít jak pro méně, tak i více rozsáhlé projekty. Požadavky na projekt nelze, jak již to u agilních metodik bývá, definovat přesně předem. Scrum vítá velké objemy změn, tudíž by měl být uživatel členem týmu, který je přítomen denně. Tým se skládá z vysoce kvalifikovaných,

motivovaných

jedinců, 49

kteří

se

samo-organizují.

Vedoucím

projektovým manažerem, by měl mít také bohaté znalosti a zkušenosti, nejlépe je na toto místo dosadit přímo certifikovaného Scrum Mastera. Metodika není v českém jazyce dobře dostupná, snaží se o využívání již hotových komponent a je podporována různými softwarovými nástroji, např. Visual Studio Team Foundation.

Graf 6-9 Scrum - min, max, opt

V grafu 6-9 jsou znázorněny minimální a maximální hodnoty metodiky Scrum, včetně jejich optimálních hodnot. Veškeré tyto hodnoty jsou stanoveny tak, jsou určeny v systému METES. 6.5.3 Posouzení metodiky Scrum pro projekt Humanet Metodika Scrum, jak je patrné z hodnot, které přecházejí za hranice extrému, také nespadá mezi ty metodiky, které by mohl být pro projekt Humanet použitelné. Znovu jsou kromě kritéria Znovupoužitelnost překročena dvě z pěti klíčových projektových kritérií a to Dostupnost uživatelů a jejich Rozmístění. V metodice Scrum je díky neustále se měnícím požadavkům nutná přítomnost budoucího uživatele. I ze vzdáleností projektu od optimálních hodnot, je zřejmé, že metodika optimálně odpovídá projektu pouze ve třech kritériích – Velikosti řešení, Kvalifikaci a motivaci členů týmů.

50

SCRUM

váhy

min

max


projekt Humanet

opt




0,265

0

3

3

2

0

-1

0,265

Délka projektu

0,109

1

5

3

3

0

-2

0,217


0,024

0

3

0

3

0

3

0,072

Znovupoužitelnost

0,053

0

1

1

2

1

1

0,053

Velikost řešení

0,064

0

5

5

5

0

0

0,000


0,026

0

2

2

0

0

-2

0,051


0,020

0

1

1

1

0

0

0,000


0,030

0

1

1

1

0

0

0,000


0,146

0

1

0

5

4

5

0,728

Velikost týmu

0,085

1

4

3

1

0

-2

0,170

Rozmístění

0,179

0

3

3

5

2

-2

0,358

1,000

1,915

Tabulka 6-6 Posouzení použitelnosti metodiky Scrum pro projekt Humanet

V následujícím grafickém znázornění je opět uvedeno, jak se liší hodnoty stanovených kritérií u projektu Humanet, od minimálních a maximálních možností ve kterých je možno metodiku Scrum aplikovat.

Graf 6-10Posouzení použitelnosti metodiky Scrum pro projekt Humanet

51

6.6 Metodika Extrémní programování (XP) Extrémní programování (XP) patří v současné době k nejznámějším zástupcům z kategorie agilních metodik. 6.6.1 Charakteristika metodiky Tento poměrně mladý přístup vznikl v roce 1999 jako řešení tehdejších projektových problémů. Vychází z toho, že pokud něco funguje správně, je nutné to využívat v nejvyšší možné míře, tedy extrémně. Extrémní programování je orientováno na psaní zdrojových kódů.

Obrázek 6-9 Průběh podle XP [2, s. 27]

Obrázek 6-9 znázorňuje průběh vývoje projektu. V první, neboli explorační, fázi zákazník sepíše různé varianty využitelnosti softwaru, které chce mít obsaženy v jeho první verzi. Doba trvání této fáze se pohybuje v rozmezí několika týdnů, až měsíců. Po explorační fázi následuje fáze plánovací. V této fázi musí zákazník stanovit a přidělit priority jednotlivým požadavkům, zatímco programátoři posoudí, s jakým časem je nutné počítat při jejich následné implementaci. Zde je také již vybráno několik zadání, s kterými se pracuje v první iteraci. To vše trvá zpravidla pouze několik dnů. Dále následuje fáze jednotlivých iterací až ke konečnému uvolnění výsledku. Již první iterace určuje alespoň hrubou architekturu celého systému. Zákazník si na začátku každé iterace vybírá, co se bude implementovat s tím, že na jejím konci se výsledky testují pro zjištění úspěšnosti. Produkční fáze začíná v době, kdy se povede vytvořit, za pomoci iterací, první verzi produktu. Následně dochází k testování produktu s cílem ověřit, zda je již vhodná chvíle k nasazení systému koncovému zákazníkovi. Produkt, který se 52

podaří u zákazníka úspěšně zavést, je nutné udržovat a spravovat. To se řeší ve fázi údržby. Projekt končí v době, kdy zákazník nemá žádné další požadavky a funkcionalitu systému. Tím se dostáváme do poslední fáze, která se nazývá fáze smrti projektu. Praktiky, které jsou využívány metodikou XP je nutné využívat všechny, jako celek. Využití pouze části z nich může sice vést k určitým zlepšením, nikoliv však bezpodmínečně. Mezi dvanáct základních praktik patří: Plánování hry – Blízká spolupráce dodavatele se zákazníkem. Okamžité získání zpětné vazby od programátorů. Zákazník na pracovišti – Zástupce z řad zákazníka je stále přítomen na pracovišti a je tedy po celou dobu při práci programátorů. V praxi není vždy snadné tento bod splnit. Vydávání malých verzí – Časté vydávání nových verzí dává zákazníkovi výborný přehled o postupu projektu. Metafora – Jde o nalezení společného, jednoduchého a zároveň snadno zapamatovatelného jazyka, který bude využíván v celém projektu a který zabrání vzniku komunikačních problémů. Párové programování – Dva programátoři pracují společně na jednom počítači. V okamžiku, když jeden z nich píše kód, druhý kontroluje, zda je kód optimální a zároveň přemýšlí, jak tento kód ovlivní okolní prostředí. Společné vlastnictví kódu – Nejsou osoby přímo zodpovědné za určité části kódu. Jinými slovy, každý může upravit jakoukoli část kód. Díky tomu vetší množství pracovníků rozumí větší části projektu. Standardy kódu – Standardy při psaní kódu zvyšují efektivitu práce s ním. Různé osoby mají možnost upravit stejný kód bez vzniku problémů. Čtyřicetihodinový pracovní týden – K příjemnému pracovnímu prostředí patří i rozumná pracovní doba. Velké množství přesčasů vede k zvyšování množství programátorských chyb. Nepřetržitá integrace – Velmi časté přidávání nových funkcionalit do systému a jejich okamžité testování. Jednoduchý návrh – Návrh musí být co možná nejjednodušší. Zavádíme řešení, která jsou zrovna třeba. Aktuálně reagujeme na nastalé situace. Refaktorizace kódu – Neustálé vylepšování kvality kódu. Snaha zlepšit čitelnost, odstranit duplicity atp. vede k zpříjemnění práce s kódem. 53

Testování – Požadavek na zákazníka z hlediska vytváření testů. Zákazník je ten, pro koho se systém navrhuje a tak se předpokládá, že právě zákazník nejlépe ví, co od systému očekává a k čemu ho potřebuje. Devízou Extrémního programování je fakt, že se snaží zlepšit pracovní podmínky samotným programátorům. Na místo někdy až zbytečných formalit, které je nutné dodržovat, spíše prosazuje volnější pracovní prostředí s ohledem na dobrou komunikaci pracovníku a vzájemné dohodě, což má za cíl přinést zlepšení výsledů. Extrémní programování je poměrně oblíbenou metodikou, která se dočkala řady rozšíření a která je často kombinována s jinak orientovanými metodikami. Optimální velikost pracovního týmu je v rozmezí od tří do dvaceti pracovníků. Tato metodika je tedy vhodná pouze pro malé a středně velké projekty. U velkých projektů, ve kterých je zapojeno větší množství lidí, nelze tuto metodiku využít. Jistá benevolence, která vyplývá z podstaty XP, by vedla ke vzniku zmatků, až k chaosu. Samotné zavedení přístupu XP není úplně snadné. Ačkoli jsou praktiky, které popisují tuto metodiku poměrně intuitivní, pořád se jedná o jisté změny, které s sebou přináší problémy a je nutné si na ně zvyknout. Metodika Extrémního programování se zaměřuje především na zastřešení procesů související s implementací a podpory software. Dále také částečně zaměřen na procesy technické a to především – definice požadavků, integrace a testování systému. 6.6.2 Hodnocení kritérií skupin Produkt a Lidé Metodika XP je metodika vhodná pro středně důležité projekty s optimální dobou realizace během šesti měsíců. Protože se jedná o rychlou agilní metodiku, není zde možnost určit veškeré požadavky předem, díky tomu je nutné, aby byl zadavatel projektu členem týmu a průběžně ujasňoval, upřesňoval a měnil požadavky na projekt. Pro XP jsou vhodné menší týmy do 10 členů, kteří jsou lokalizováni v nejlépe v jedné místnosti. Tato metodika se snaží využívat již hotových komponent, avšak jsou zde kladeny vysoké nároky na odbornost a kvalifikaci jak projektového manažera, tak jednotlivé členy týmu, jejichž zaměření by mělo být široké. Pro tuto metodiku existují šablony, jako např. pro Visual Studio Team System od společnosti Microsoft. V současnosti je metodika Extremního programování, dále vyvíjena a upravována tak, aby bylo možné ji použít i pro velké, důležité projekty a větší týmy. Na grafu č. 6-11 je možné vidět minima, maxima a optima hodnot kritérií pro metodik XP.

54

Graf 6-11 XP - min, max, opt

6.6.3 Posouzení metodiky XP pro projekt Humanet Z tabulky pro hodnocení zřejmé, že tato metodika přesahuje až 4 kritéria, ve kterých se nevejde Projekt Humanet do stanovených intervalů. Prvním z nich je kritérium Znovupoužitelnost, zde se pohled Extrémního programování a požadavku na projekt Humanet dosti liší. Zatímco XP využívá již hotové komponenty, v rámci projektu Humanet mají být vytvořeny znovu použitelné třídy. Dalším z kritérií je Velikost řešení, XP není určeno pro tak velké projekty jako je Humanet. Projekt se i u této metodiky stále nevejde do intervalů u klíčových kritérií Dostupnosti uživatelů, která je v případě XP nezbytná a Rozmístění. V obou případech těchto kritérií je projekt Humanet vysoce za hranicemi extrému. Ani metodika Extrémního programování není pro posuzovaný projekt použitelná a to i přes to, že existují její šablony pro Visual Studio Team System, které je v současné době společnost Hour používá.

55

XP

váhy

min

max


projekt Humanet

opt




0,265

0

3

3

2

0

-1

0,265

Délka projektu

0,109

0

4

2

3

0

1

0,109


0,024

0

3

0

3

0

3

0,072

Znovupoužitelnost

0,053

0

1

1

2

1

1

0,053

Velikost řešení

0,064

0

3

3

5

2

2

0,129


0,026

0

2

2

0

0

-2

0,051


0,020

0

1

1

1

0

0

0,000


0,030

0

1

1

1

0

0

0,000


0,146

0

1

0

5

4

5

0,728

Velikost týmu

0,085

0

1

1

1

0

0

0,000

Rozmístění

0,179

0

1

1

5

4

4

0,716

1,000

2,123

Tabulka 6-7 XP - Posouzení použitelnosti metodiky XP pro projekt Humanet

Pokud se podíváme

na

zhodnocení optimálních hodnot, metodika Extrémního programování odpovídá přesným optimům projektu Humanet pouze ve třech kritériích a to Kvalifikaci členů týmu, jejich motivaci a velikosti. V grafu 6-12 jsou zaneseny pro srovnání minimální a maximální hodnoty u každého z kritérií, které odpovídají Extrémnímu programování a jsou srovnány s hodnotami kritérií projektu Humanet.

Tabulka 6-8 Posouzení metodiky XP pro projekt Humanet

Graf 6-12Posouzení použitelnosti XP pro projekt Humanet

56

7 Závěr V této bakalářské práci byly porovnány metodiky pro vývoj softwaru pro projekt Humanet. Porovnání bylo provedeno na základě vícekriteriálního systému hodnocení a porovnání metodik METES. Byly stanoveny váhy důležitosti pro jednotlivá posuzovaná kritéria a dále pak byl projekt Humanet ohodnocen na základě stupnice hodnocení definované pro každé z posuzovaných kritérií. Porovnání projektu Humanet s jednotlivými metodikami pro vývoj softwaru bylo provedeno na základě toho, zda se hodnoty definované pro tento projekt vešly do intervalů stanovených minimálními a maximálními hodnotami, ve kterých jsou metodiky používány. Základními hlediskem, zde je pět klíčových projektových kritérií, jejichž hodnoty pro projekt Humanet nesmí přesahovat hranice extrému.

Bohužel z analýzy kritérií projektu Humanet vyplynulo, že u všech

z posuzovaných metodik překračuje minimálně jedno z těchto klíčových projektových kritérií, což má za výsledek, že ani jedna z posuzovaných metodik není pro projekt Humanet použitelná. Z hodnocení vyplývá, že projekt nesplňuje povětšinou kritéria metodik, co se týká Dostupnosti uživatelů a Rozmístění členů týmů. Doporučuji se tedy na tyto dvě hlediska zaměřit. Pokud bych však i přes to, na základě provedené analýzy porovnání metodik měla některou z nich doporučit, bude to jistě metodika MSF for CMMI Process Improvement, projekt Humanet se v hodnocení této metodiky vešel do všech intervalů kritérií, ve kterých je metodika ještě použitelná až na jedno z klíčových a to Dostupnost uživatelů. Tato metodika přepokládá dostupnost uživatele alespoň na začátku a na konci vývoje softwaru, pokud by bylo možné toto v rámci posuzovaného projektu zajistit, byla by tato metodika navrhnuta jako optimální. Její další neskutečnou výhodou je, že je úzce spjata s Visual Studio Team Systém, které je ve společnosti pro sledování vývoje systémů již využíván, nebyl by tedy pro členy týmů žádným úplně novým nástrojem. MSF for CMMI Process Improvement je posuzována jako těžká metodika, tudíž nedošlo k potvrzení mé původní hypotézy, že dojde k doporučení zavést jednu z agilních metodik a to konkrétně Scrum, byla právě naopak vyvrácena.

57

8 Seznamy a přílohy 8.1 Seznam použité literatury [1]

Attestica Scrum. Attestica [online]. 2012 [cit. 2012-05-20]. Dostupné z: http://www.attestica.biz/cz/ALMaSCRUM.html#scrum

[2]

BOSÁK, Martin. Agilní přístup v projektovém řízení [online]. Praha, 2008 [cit. 2012-04-15]. Dostupné z: http://martinbosak.cz/files/BP%20%20Martin%20Bosak%20%20Agilni%20pris tup%20v%20PM.pdf. Bakalářská práce. VŠE v Praze.

[3]

BRABEC, Tomáš, BUCHALCEVOVÁ, Alena. Využitelnost metodiky XP při vývoji aplikací webových služeb. Ostrava 04.06.2007 – 06.06.2007. In: Tvorba softwaru 2007. Ostrava : Ekonomická fakulta VŠB TU, 2007, s. 1–7. ISBN 97880-248-1427-8.

[4]

BRUCKNER, Tomáš, Jiří VOŘÍŠEK, Alena BUCHALCEVOVÁ a kolektiv. Tvorba informačních systémů. 1. vyd. Praha: Grada Publishing, 2012, 360 s. ISBN 978-80-247-4153-6.

[5]

BUCHALCEVOVÁ, Alena. Metodika Feature-driven development neopouští modelování a procesy, a přesto přináší výhody agilního vývoje. Ostrava 01.06.2005 – 03.06.2005. In: Tvorba softwaru 2005. Ostrava : Tanger, 2005, s. 25–30. ISBN 80-86840-14-X.

[6]

BUCHALCEVOVÁ, Alena. Metodiky budování informačních systémů. 1. vyd. Praha: Oeconomica, 2009. 206 s. ISBN 978-80-245-1540-3.

[7]

BUCHALCEVOVÁ, Alena. Metodiky vývoje a údržby informačních systémů. 1. vyd. Praha: Grada, 2005, s. 54-55. ISBN 80-247-1075-7.

[8]

ČSN ISO/IEC 12207. Informační technologie: Procesy v životním cyklu softwaru. 2003.

[9]

HAJDIN, Tomáš. Agilní metodiky vývoje software [online]. Brno, 2005 [cit. 2012-04-17]. Dostupné z: http://is.muni.cz/th/39440/fi_m/dp.pdf. Diplomová práce. Masarykova Univerzita.

58

[10]

HECKSEL, D.L. Methodology Evaluation and Selection. [online] Sun Software Services, Sun Microsystems [cit. 2012-04-30]. Dostupný z: http://www.davidhecksel.com/projetctcontext/whitepaper.html.

[11]

HOUR, spol. s r.o. Analýza zakládaného modulu Humanet. Žilina, 2012.

[12]

Humanet. Hour.sk [online]. 1999-2012 [cit. 2012-05-10]. Dostupné z: http://www.hour.sk/sk/humanet.

[13]

Introduction to OpenUP. [online] The Eclipse Foundation, 2007 [cit.2012-0515]. Dostupné z: http://www.eclipse.org/epf/general/OpenUP.pdf

[14]

ISO/IEC 12207. Systems and software engineering : Software life cycle processes. 2008.

[15]

ISO/IEC 15289. Systems And Software Engineering – Content of systems and software life cycle process information products (Documentation). 2006.

[16]

KADLEC, Václav. Agilní programování: Metodiky efektivního vývoje softwaru. 1. vyd. Brno: Computer Press, 2004, 280 s. ISBN 8025103420.

[17]

KALČEVOVÁ, Jana. Vícekriteriální hodnocení variant VHV. Praha, 2008. 9s. Dostupné z: http://jana.kalcev.cz/vyuka/kestazeni/EKO422-Vahy.pdf

[18]

LESÁK, Petr. Metoda Analytic Network Process [online]. Praha, 2011 [cit. 2012-05-4]. Dostupné z: https://isis.vse.cz/zp/portal_zp.pl?prehled=vyhledavani;...prace=1. Diplomová práce. VŠE v Praze.

[19]

Manifesto for Agile Software Development [online]. 2001 [cit. 2012-05-01]. Dostupné z: http://agilemanifesto.org/

[20]

MSF for CMMI Process Improvement v5.0. Microsoft.com [online]. 2010 [cit. 2012-05-07]. Dostupné z: http://msdn.microsoft.com/enus/library/dd997574.aspx

[21]

POPELKA, Vladimír. Srovnávací analýza metodik vývoje software [online]. Praha, 2009 [cit. 2012-04-28]. Dostupné z: http://info.sks.cz/www/zavprace/soubory/54300.pdf. Bakalářská práce. VŠE v Praze, Vyšší odborná škola informačních služeb. 59

[22]

Správa IT služeb [online] [cit.2012-05-03]. Dostupné z: http://download.microsoft.com/download/5/5/d/55/55da927f-d3fb-43dd-8a732bc2f96be56a/Zivotni_cyklus_aplikaci_FINAL.pdf

[23]

Testování softwaru. Manuální testování: Modely životní cyklu softwaru [online]. 2011 [cit. 2012-04-29]. Dostupné z: http://testovanisoftwaru.cz/manualnitestovani/modely-zivotniho-cyklu-softwaru/vodopadovy-model/

[24]

TURNER, Michael S.V. Microsoft Solutions Framework Essentials. Washington: Microsoft Press, 2006, 340 s. ISBN 0-7356-2353-8.

[25]

Vícekriteriální rozhodování. SPEM skriptum [online]. 2008 [cit. 2012-15-04]. Dostupné z: http://etext.czu.cz/php/skripta/objekt.php?titul_key=79&obj=108&no=5.4%20%205

[26]

Visual Studio Team Foundation Server 2010. Microsoft [online]. 2012 [cit. 2012-04-30]. Dostupné z: http://www.microsoft.com/cze/msdn/vstudio/2010/team-foundation-server.aspx

[27]

VYMĚTAL, Dominik. Informační systémy v podnicích: Teorie a praxe projektování. 1. vyd. Praha: Grada Publishing, 2009. ISBN 978-80-247-3046-2.

[28]

WÖLCZ, Rastislav. HOUR, spol. s r.o. Vývoj SW aplikácií. Žilina, 2012.

[29]

Xs project manager [online]. 2010-2012 [cit. 2012-05-20]. Dostupné z: http://xspm.cz/help/o-aplikaci-xspm

8.2 Seznam obrázků Obrázek 2-1 Vodopádový model životního cyklu .......................................................... 11 Obrázek 3-1Struktura systému hodnocení metodik METES .......................................... 16 Obrázek 5-1 Konceptuální model výběru metodiky pro projekt ................................... 24 Obrázek 6-1 Fáze a disciplíny RUP ................................................................................ 29 Obrázek 6-2 Týmový model MSF .................................................................................. 34 Obrázek 6-3 Procesní model MSF .................................................................................. 35 Obrázek 6-4 Metodický rámec ........................................................................................ 38 Obrázek 6-5 Proces metodiky OpenUP ......................................................................... 40 Obrázek 6-6 Fáze životního cyklu FDD ......................................................................... 43 60

Obrázek 6-7 Scrum - popis procesů ................................................................................ 47 Obrázek 6-8 Scrum - Burndown Report ......................................................................... 48 Obrázek 6-9 Průběh podle XP ........................................................................................ 52

8.3 Seznam grafů Graf 6-1 RUP - Kritéria Produkt a Lidé - min, max, opt ................................................ 31 Graf 6-2 Posouzení použitelnosti metodiky RUP pro projekt Humanet ......................... 33 Graf 6-3 MSF CMMI - min, max, opt ............................................................................ 36 Graf 6-4 Posouzení použitelnosti metodiky MSF CMMI pro projekt Humanet ............ 37 Graf 6-5 OpenUP – min, max, opt .................................................................................. 41 Graf 6-6 Posouzení použitelnosti metodiky OpenUP pro projekt Humanet ................... 42 Graf 6-7 FDD - min, max, opt......................................................................................... 45 Graf 6-8 Posouzení použitelnosti metodiky FDD pro projekt Humanet......................... 47 Graf 6-9 Scrum - min, max, opt ..................................................................................... 50 Graf 6-10Posouzení použitelnosti metodiky Scrum pro projekt Humanet ..................... 51 Graf 6-11 XP - min, max, opt ......................................................................................... 55 Graf 6-12Posouzení použitelnosti XP pro projekt Humanet........................................... 56

8.4 Seznam tabulek Tabulka 1-1 Porovnání rigorózních a agilních metodik .................................................. 14 Tabulka 1-2 Stanovení vah kritérií Produkt a Lidé ......................................................... 26 Tabulka 0-1 Hodnocení kritérií skupin Produkt a Lidé pro projekt Humanet ................ 28 Tabulka 6-1 Posouzení použitelnosti metodiky RUP pro projekt Humanet ................... 32 Tabulka 6-2 Posouzení použitelnosti metodiky MSF CMMI pro projekt Humanet ....... 37 Tabulka 6-3 Mapování principů OpenUP a Manifestu agilního vývoje ......................... 38 Tabulka 6-4 Posouzení použitelnosti metodiky OpenUP pro projekt Humanet ............. 42 Tabulka 6-5 Posouzení použitelnosti metodiky FDD pro projekt Humanet ................... 46 Tabulka 6-6 Posouzení použitelnosti metodiky Scrum pro projekt Humanet ................ 51 Tabulka 6-7 XP - Posouzení použitelnosti metodiky XP pro projekt Humanet ............. 56 Tabulka 6-8 Posouzení metodiky XP pro projekt Humanet ........................................... 56

61

8.5 Přílohy

Příloha č. 1 - Doplňková kritéria pro hodnocení vhodnosti metodiky

Kritéria skupiny Proces Do této skupiny spadají kritéria, popisující procesy, které předcházejí a dále doprovázejí samotný vznik informačního systému. Snaží se zachytit jaký je jeho životní cyklus a požadavky na související dokumentaci a výši jeho kvality.

Rozsah Ohodnocuje, v jaké šíří, se organizace zabývá procesy souvisejícími s vývojem softwaru. Toto zhodnocení je prováděno na základě životního cyklu softwaru tak, jak ho definuje norma ISO/IEC 12207. Jejím obsahem je 43 procesů souvisejících se softwarem, ty jsou rozděleny do dvou hlavních skupin a to procesy v kontextu systému a softwarově specifické procesy. 0 – jen procesy implementace SW 1 – procesy implementace a podpory SW 2 – převážně projektové procesy 3 – procesy implementace SW, podpory SW a projektové procesy 4 – systémové a softwarové procesy včetně projektových 5 – velmi vysoké pokrytí procesů referenčního modelu ISO/IEC 12207

Model životního cyklu Kritérium ujasňuje jaký model životního cyklu softwaru, který určuje. Daná metodika z něj vychází. V současnosti je mnoho různých modelů, mezi nejznámější z nich však patří např. vodopádový či spirálový model, ze kterých se mnoho nových také odvíjí. 0 – žádný 1 – vodopádový model 2 – V-model 3 – spirálový model 4 – iterativní model, iterace > 1 měsíc 5 – iterativní model, velmi krátké iterace (do měsíce)

62

Role Kritérium posuzuje, jaké jsou různé typy rolí pracovníků a jaký je jejich počet. Role jsou rozděleny do větších celků, určujících hlavní činnosti, na které jsou zaměřené. Kritérium je přímo úměrné s kritériem Rozsah, čím více je vykonáváno procesů, tím více typů rolí je v týmu zastoupeno. 0 – jen jedna role 1 – 2-5 SW inženýrských rolí v projektu 2 – SW inženýrské i řídící role v projektu, celkem méně než 10 rolí 3 – SW inženýrské i řídící role v projektu, více než 10 rolí 4 – SW inženýrské i řídící role v projektu i celopodnikové role řídící 5 – SW inženýrské i řídící role v projektu, celopodnikové SW inženýrské i řídící

Podrobnost popisu procesu Souvisí s tím, zda je nutno veškeré procesy vývoje detailně evidovat. Toto kritérium je spjato s kritériem Kvalifikace členů týmu. Pokud je tým složen z vysoce kvalifikovaných lidí, je postačující i méně podrobný popis. Může mít značný vliv při volbě mezi agilní a rigorózní metodikou. 0 – nejsou definovány žádné procesy 1 – u procesu jsou definovány cíle procesu, spouštěcí událost, zodpovědná role 2 – popsány jsou navíc metriky a omezující podmínky 3 – popsán navíc výstup procesu 4 – popsány činnosti, role, vstupy, výstupy 5 – vstupy, výstupy a role přiřazeny k činnostem

Dokumenty Objem požadovaných dokumentů pro projekt je hodnocen na základě veškerých procesů uvedených dle normy ISO/IEC 15289, ta určuje veškeré náležitosti, které musí daná dokumentace k vývoji softwaru splňovat. Ve stupnici pro hodnocení je uvedeno procentuální vyjádření procesů, které metodika vyžaduje vytvořit. Množství dokumentace je ve velkém odvíjeno od náročnosti a velikosti projektů. 0 – není požadována dokumentace 1 – minimální dokumentace v jednoduché formě 2 – jen dokument specifikace Softwarových požadavků 3 – vytváří se více než 40% dokumentů 4 – vytváří se více než 60% dokumentů 63

5 – vytváří se více než 80% dokumentů

Metriky Jeden z prvků, který by měl být součástí každé metodiky, který umožňuje sledovat, jak efektivní jsou procesy vývoje a poskytuje informace o jeho aktuálním stavu. Zefektivňují kontrolu kvality vyvíjeného produktu. 0 – nepracuje s metrikami 1 – definuje některé metriky a způsob měření, ale jejich význam nepřeceňuje 2 – definuje některé metriky a způsob měření, jejich význam je značný 3 – definuje systém metrik, jejich měření je součástí metodiky 4 – definuje systém metrik, metodika je na metrikách závislá 5 – na základě metrik dochází k zlepšování procesů

Řízení kvality Řízení kvality je jednou z nejdůležitějších činností metodiky, je nezbytné, aby kvalita softwaru sledována a průběžně kontrolována v průběhu celého jeho vývoje. Kritérium je tedy sledováno z hlediska provádění testování softwaru. 0 – nezabývá se řízením kvality 1 – jen akceptační testování 2 – provádí se testování softwaru 3 – provádí se testování softwaru i testování systému 4 – jsou definovány standardy kvality a metriky kvality 5 – velký důraz na řízení kvality v celém životním cyklu, využití nástrojů

Kritéria skupiny Podpora Závisí od způsobů, jak je možné metodiku zavést, jaká je technická podpora, dostupnost zdrojů poskytujících potřebné informace o metodice, možnosti jejího přizpůsobení a získávání vzdělání a certifikací, tudíž i kvalifikovaných členů týmu, kteří se v dané problematice orientují.

Celistvost zdrojů Kritérium Celistvost zdrojů zkoumá, v jakém rozsahu je možné získat veškeré informace s metodikou spojené. Pro některé metodiky jsou dostupné zdroje, kde jsou uvedeny veškeré nezbytné informace na jednom místě, naopak u některých metodik je nutno pátrat ve více zdrojích, jako jsou různé knihy, odborné články apod. 64

0 – žádné zdroje 1 – informace jsou jen v článcích 2 – informace jsou v různých zdrojích – články, rozhovory, knihy, webové stránky 3 – metodika je v jednom základním zdroji 4 – metodika je v jednom základním zdroji a navíc jsou k dispozici další zdroje 5 – metodika je dostupná jako aplikace, snadná navigace, vyhledávání

Dostupnost Hodnotí se způsob jak určitou metodiku získat, od čehož se i dále odvíjí cenová relace, která je za ni požadována. Možnosti jsou různé od volně dostupných forem, přes komerční produkty či open-source. 0 – není veřejně dostupná 1 – dostupná v komerčních publikacích 2 – komerční produkt 3 – volně dostupná 4 – open-source licence 5 – open-source licence i s nástroji na správu obsahu

Podpora metodiky softwarovými nástroji Sleduje v jaké míře je možno metodiku podpořit softwarovými nástroji. Zahrnuje jak nástroje pro podporu všech činností, které jsou metodikou zastřešeny, tak nástroje pro správu obsahu. Cílem je zajistit přehlednější a spolehlivější dodržování metodiky i kvality samotného SW produktu. 0 – metodika není podpořena nástroji 1 – metodika je integrována s nástroji, které podporují některé činnosti 2 – metodika je přímo zabudována do jednoho vývojového nástroje 3 – metodika je integrována s nástroji, které podporují celý životní cyklus vývoje 4 – metodika lze formou procesních šablon zabudovat do různých nástrojů 5 – spolu s metodikou jsou dodávány nástroje na správu obsahu

Podpora zavedení metodiky Na podporu metodiky je u tohoto kritéria nahlíženo ze strany jejich dodavatelů a to z hlediska analýzy, výběru, úprav, zavedení a proškolování. Posuzuje se, jestli existují společnosti, které vybranou metodiku zavádí, případně poskytují odborné konzultace. 65

0 – žádná podpora 1 – možnost konzultací u distributora 2 – poskytnutí konzultantů do firmy, která metodiku zavádí 3 – konfigurace metodiky 4 – konfigurace a školení metodiky 5 – zavedení metodiky plně realizováno externí firmou

Přizpůsobení metodiky Jelikož je každý projekt jiný, není vždy možné, aby byly jednotlivé projekty realizovány dle striktně daných postupů a pravidel nějaké z metodik. Ty se musí do jisté míry dát přizpůsobit konkrétním podmínkám projektu tak organizace. Zohledňuje se struktura společnosti, její firemní kultura, tak samozřejmě i velikost a důležitost projektu. 0 – nezabývá se přizpůsobováním metodiky 1 – přizpůsobení metodiky je možné jen na začátku projektu 2 – doporučuje přizpůsobení metodiky na začátku projektu 3 – přizpůsobování metodiky je možné i v průběhu projektu (např. po každé iteraci) 4 – doporučuje přizpůsobování metodiky i v průběhu projektu 5 – má nástroje na přizpůsobování metodiky

Výuka na vysokých školách Jak velký je v České Republice a v zahraničí metodice přikládán význam z hlediska vzdělávání. Hodnotí se, jestli jsou nabízeny vzdělávací programy na vysokých školách, které by připravili své studenty na budoucí práci s metodikou jako kvalifikované členy týmu. 0 – neučí se na VŠ 1 – učí se jen některé techniky, které jsou součástí metodiky 2 – učí se jen v rámci přednášek ve světě 3 – učí se jen praktické použití ve světě 4 – učí se jen v rámci přednášek v ČR 5 – učí se jen praktické využití v ČR

66

Školení a certifikace Opět se vztahují jak na území ČR, tak zahraničních státy. Základním bodem hodnocení je míra poskytnutí školení a certifikací, které by měly za účel vychovávání kvalifikovaných zaměstnanců, tvořící členy týmů podílejících se na projektu. 0 – nejsou školení ani certifikace 1 – školení ve světě 2 – školení i v ČR 3 – školení a certifikace mimo Evropu 4 – školení a certifikace v Evropě 5 – školení a certifikace i v ČR

Lokalizace Jednou z překážek pro nezavedení některých metodik v tuzemsku může být jejich nedostupnost v českém jazyce, což je také základem hodnocení tohoto kritéria. 0 – není v českém jazyce 1–x 2–x 3 – částečná lokalizace 4–x 5 – je plně v českém jazyce

67

Krok

Příloha č. 2 – Vývojový diagram SW aplikací společnosti HOUR, spol. s r.o.

1

2

Vstup

Vývojový diagram

Číslo procesu - meno súboru

Vývoj SW aplikácií

HP03-01

Činnosť

Požiadavky môžu byť: od zákazníkov, z analýzy konkurencie, z analýzy trhu, nové technológie ...

Evidencia požiadaviek

Výstup

Evidencia požiadaviek, príp. FK_HP03_01

Zber požiadaviek na vývoj SW aplikácií

Zaradenie požiadavky?

Zodpovednosť Riaditelˇsekcie služieb zákazníkom

Začiatok


Posúdenie požiadavky

3

SW

Nie

Zadávateľ požiadavky VSTS (príp. HI)

VSTS


Schvaľovateľ požiadavky

Znalec VSTS

Áno

4


Preskúmanie požiadavky

Nie - vyžaduje sa doplnenie

Informácie kompletné?

5

Programátor, senior programátor VSTS

VSTS

Programátor, senior programátor

Áno Potrebná analýza?

6

Áno

7

VSTS


Nie Návrh riešenia, príp. objednávka na analýzu

Analýza

Zadávateľ požiadavky VSTS, W:/ ...

8


Ocenenie úlohy

Požiadavka na interné schválenie alebo FK_HP03_01

Získanie zdrojov na realizáciu

9

Schválené zdroje?

VSTS

Nie


Zadávateľ požiadavky

Evidencia požiadaviek VSTS

Áno Pokračovanie

Dôverné!!!

Interný dokument!

68

Strana 1 z 2

Krok

Vstup

Vývojový diagram

Číslo procesu - meno súboru

Vývoj SW aplikácií

HP03-01

Činnosť

Výstup

SW

Riaditelˇsekcie služieb zákazníkom

Pokračovanie

10

11

12

13

14

Návrh riešenia

Evidencia objednávok


Vytvorenie objednávky

Evidencia objednávok VSTS


Prijatie objednávky

Návrh riešenia

Riaditelˇsekcie služieb zákazníkom

Programátor VSTS

Zdrojové kódy, FK_HP03_01

Realizácia navrhovaného riešenia

Programátor VSTS

Záznam z testovania, evidencia objednávok

Testovanie navrhovaného riešenia

Zdrojové kódy

Zadávateľ objednávky VSTS

Priradenie objednávky


Zodpovednosť

Zadávateľ objednávky VSTS, W:/ ...,

Nie - vyžaduje sa zdôvodnenie

15

Zadávateľ objednávky

Možno uzavrieť vývoj? Áno

16

17

Evidencia objednávok, PL, dokumentácia IÚ

Ukončenie vývoja

Nový SW, podklady ...

VSTS, HI

Užívateľská dokumentácia

Tvorba užívateľskej dokumentácie

Zadávateľ objednávky

Dokumentarista W:/ ...,

Nie - vyžaduje sa zdôvodnenie

18

Možno uzavrieť dokumentáciu?

Áno

Odovzdanie SW na ďalšie použitie

Metodik, koordinátor W:/ ...,

Áno

19 Koniec

Dôverné!!!

Interný dokument!

69

Strana 2 z 2

Výběr vhodné metodiky vývoje softwaru pro společnost HOUR, spol. s r.o

Recommend Documents