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

Transkript

1 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

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

3 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 Simona Dlugošová

4 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.

5 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

6 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.

7 Obsah 1 Úvod Cíl práce Hypotéza Metodologie práce Porovnání rigorózních a agilních metodik Rigorózní metodiky Agilní metodiky Porovnání rigorózních a agilních metodik Systém hodnocení a výběru metodik METES Charakteristika METES Způsob hodnocení kritérií Kritéria skupiny Produkt Důležitost produktu Délka projektu Stálost požadavků Znovupoužitelnost Velikost řešení Kritéria skupiny Lidé Zkušenost manažera projektu Kvalifikace členů týmů Motivace členů týmu Dostupnost uživatelů Velikost týmu Rozmístění Charakteristika projektu Vývoj softwarových aplikací ve společnosti HOUR, spol. s r.o Projekt Humanet

8 5 Výběr vhodné metodiky Stanovení vah pro skupiny Produkt a Lidé Stanovení hodnot kritérií skupiny Produkt pro projekt Humanet Stanovení hodnot kritérií skupiny Lidé pro projekt Humanet Posouzení použitelnosti vybraných metodik Metodika Rational Unified Process (RUP) Charakteristika RUP Hodnocení kritérií skupin Produkt a Lidé Posouzení použitelnosti RUP pro projekt Humanet Metodika Microsoft Solution Framework (MSF) Charakteristika metodiky Hodnocení kritérií skupin Produkt a Lidé Posouzení použitelnosti metodiky MSF CMMI pro projekt Humanet Metodika OpenUP Charakteristika metodiky Hodnocení kritérií skupin Produkt a Lidé Posouzení použitelnosti metodiky OpenUP pro projekt Humanet Metodika Feature Driven Development (FDD) Charakteristika metodiky Hodnocení kritérií skupin Produkt a Lidé Posouzení použitelnosti metodiky FDD pro projekt Humanet Metodika Scrum Charakteristika metodiky Hodnocení skupin Produkt a Lidé Posouzení metodiky Scrum pro projekt Humanet Metodika Extrémní programování (XP) Charakteristika metodiky Hodnocení kritérií skupin Produkt a Lidé

9 6.6.3 Posouzení metodiky XP pro projekt Humanet Závěr Seznamy a přílohy Seznam použité literatury Seznam obrázků Seznam grafů Seznam tabulek Přílohy

10 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

11 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

12 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 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

13 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 ] 13

14 Posuzované hledisko změny rozsah řešení způsob řízení forma komunikace dokumentace způsob vývoje zákazník Rigorózní metodiky Agilní metodiky snaha minimalizace jsou vítány, možnost 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ář rozsáhlá dokumentace podstatná není dokumentace, ale pochopení píše vodopádový, případně přírůstkový vývoj s velmi krátkými iterativní, přírůstkový s dlouhými iteracemi 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

15 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

16 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

17 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 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í 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ů 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

18 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 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 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ž až až až

19 4 201 až 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í 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 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

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

21 Stupnice hodnocení: 0 1 až až až až až více než 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

22 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

23 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 ] 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

24 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

25 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 = (s ij ). 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

26 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 s ij = 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, s ij = 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 hlavní diagonálou, na základě čehož pak došlo k doplnění odpovídajících převrácených hodnot. Stanovení vah kritérií skupin Produkt a Lidé Důležitost produktu Délka projektu Stálost požadavků 26 Znovupoužitelnost Velikost řešení Zkušenosti manažera projektu Kvalifikace členů týmu Motivace členů týmu Dostupnost uživatelů Velikost týmu Důležitost produktu ,265 Délka projektu 1/ /3 0 0,109 Stálost požadavků 1/5 1/5 1 1/ /3 1/3 1/5 1/3 1/3 0,024 Znovupoužitelnost 1/5 1/ /3 1/3 1/5 0,053 Velikost řešení 1/3 1/3 1 1/ /3 0,064 Zkušenost manažera projektu 1/7 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/ /7 1/7 1/7 0,030 Dostupnost uživatelů 1/ ,146 Velikost týmu 1/ / /5 1 1/5 0,085 Rozmístění 1/ ,179 Tabulka 1-2 Stanovení vah kritérií Produkt a Lidé Rozmístění Váhy 1,000

27 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 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

28 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 Kvalifikace členů týmu 1 Motivace členů týmu 1 Dostupnost uživatelů 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í 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

29 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

30 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 ] 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 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

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

32 RUP váhy min max opt projekt Humanet za hranicemi extrémů vzdálenost od optim. hodn. vážené abs. hodn. vzdáleností od optima Důležitost produktu 0, ,795 Délka projektu 0, ,109 Stálost požadavků 0, ,024 Znovupoužitelnost 0, ,053 Velikost řešení 0, ,000 Zkušenost manažera projektu 0, ,102 Kvalifikace členů týmu 0, ,078 Motivace členů týmu 0, ,090 Dostupnost uživatelů 0, ,146 Velikost týmu 0, ,340 Rozmístění 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

33 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] 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

34 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

35 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

36 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 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

37 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 opt projekt Humanet za hranicemi extrémů vzdálenost od optim. hodn. vážené abs. hodn. vzdáleností od optima Důležitost produktu 0, ,795 Délka projektu 0, ,109 Stálost požadavků 0, ,000 Znovupoužitelnost 0, ,053 Velikost řešení 0, ,000 Zkušenost manažera projektu 0, ,102 Kvalifikace členů týmu 0, ,078 Motivace členů týmu 0, ,090 Dostupnost uživatelů 0, ,146 Velikost týmu 0, ,340 Rozmístění 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

38 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 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 Průběžné získávání zpětné vazby a zlepšování. 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. 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

39 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

40 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 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

41 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 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

42 OpenUP váhy min max opt projekt Humanet za hranicemi extrémů vzdálenost od optim. hodn. vážené abs. hodn. vzdáleností od optima Důležitost produktu 0, ,000 Délka projektu 0, ,109 Stálost požadavků 0, ,048 Znovupoužitelnost 0, ,000 Velikost řešení 0, ,193 Zkušenost manažera projektu 0, ,102 Kvalifikace členů týmu 0, ,078 Motivace členů týmu 0, ,090 Dostupnost uživatelů 0, ,291 Velikost týmu 0, ,085 Rozmístění 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

43 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 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 ] 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

44 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 ] 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

45 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 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

46 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 opt projekt Humanet za hranicemi extrémů vzdálenost od optim. hodn. vážené abs. hodn. vzdáleností od optima Důležitost produktu 0, ,265 Délka projektu 0, ,109 Stálost požadavků 0, ,048 Znovupoužitelnost 0, ,000 Velikost řešení 0, ,000 Zkušenost manažera projektu 0, ,077 Kvalifikace členů týmu 0, ,039 Motivace členů týmu 0, ,030 Dostupnost uživatelů 0, ,582 Velikost týmu 0, ,170 Rozmístění 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

47 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 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

48 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