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

Zadání bakalářské práce Analyzujte dostupné nástroje určené pro řízení projektů a zpracujte je formou rešerše. Analyzujte potřeby vedoucího práce, oponenta a studentů vzhledem k řízení týmových bakalářských resp. diplomových prací. Implementujte nebo upravte existující nástroj, která bude ulehčovat a zjednodušovat řízení projektu typu Mantichora. Vypracujte podrobnou dokumentaci tohoto nástroje. i

ii

České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů Bakalářská práce Aplikace Mantichora - Řízení projektu Václav Podlipný Vedoucí práce: Ing. Jiří Chludil Studijní program: Elektrotechnika a informatika, strukturovaný, Bakalářský Obor: Výpočetní technika 2. července 2009

iv

v Poděkování Rád bych poděkoval vedoucímu práce Ing. Jiřímu Chludilovi za vedení a cenné rady při vytváření této práce a všem členům týmu Mantichora za spolupráci.

vi

vii Prohlášení Prohlašuji, že jsem práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu 60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon). V Hradci Králové dne 2. 7. 2009.............................................................

viii

Abstract The aim of this thesis is to support management of project Mantichora which includes studying of theory about team leading, research of the current applications for support of managing the project and introducing of application which were chosen or implemented into usage in project. Introducing to usage means to acquaint team with chosen application and its possibilities. There is a comparison of several different applications in the bachelor thesis. As the best one was chosen application Assembla which covers all the team s requirements. The thesis also includes manual for using application Assembla and suggestion to improve its usage in the next part of the project Mantichora or in usage in the other projects. Abstrakt Cílem této práce je podpora řízení projektu Mantichora, což zahrnuje nastudování teorie o vedení týmů, rešerši stávajících aplikací pro podporu řízení projektu a zavedení vybrané či implementované aplikace do používání v projektu. Zavedení do užívání znamená seznámit tým s vybranou aplikací a jejími možnostmi. V bakalářské práci je porovnáno několik různých aplikací. Jako nejlepší byla vybrána aplikace Assembla, která pokryla všechny požadavky týmu. Práce obsahuje i manuál k používání aplikace Assembla a návrh na zlepšení jejího využití v dalším pokračování projektu Mantichora nebo při použití v jiných projektech. ix

x

Obsah 1 Úvod 1 1.1 Projekt Mantichora................................. 1 1.1.1 Tým Mantichora.............................. 1 1.1.2 Komunikace v týmu............................ 2 1.2 Motivace....................................... 3 2 Specifikace cílů 5 2.1 Teorie k řízení projektu.............................. 5 2.2 Analýza požadavků projektu........................... 5 2.3 Rešerše aplikací podporujících řízení projektu.................. 5 2.4 Manuál k aplikaci Assembla............................ 6 2.5 Zhodnocení vedení projektu............................ 6 3 Teorie k řízení projektů 7 3.1 Organizační struktury a role v projektovém řízení................ 7 3.1.1 Manager projektu............................. 8 3.1.2 Pracovní týmy............................... 9 3.1.2.1 Nestrukturované pracovní týmy................ 9 3.1.2.2 Strukturované pracovní týmy.................. 10 3.2 Životní cyklus projektu a jeho modelování.................... 10 3.2.1 Model Build & Fix............................. 10 3.2.2 Vodopádový model............................. 11 3.2.3 Spirálový model.............................. 11 3.2.4 Přírůstkový model............................. 12 3.3 Agilní metody plánování.............................. 13 3.4 Struktura a model použitý u projektu Mantichora............... 14 4 Analýza požadavků projektu 15 4.1 Požadavky vedoucího projektu a ostatních členů................ 15 4.2 Požadavky oponenta................................ 16 4.3 Shrnutí analýzy požadavků............................ 17 5 Rešerše aplikací podporujících řízení projektu 19 5.1 Hodnotící kritéria aplikací podporujících řízení projektu............ 19 5.1.1 Kategorizační kritéria........................... 19 5.1.1.1 Cena............................... 19 xi

xii OBSAH 5.1.1.2 Způsob nasazení......................... 19 5.1.1.3 Vytvořené kategotie....................... 20 5.1.2 Ostatní kritéria............................... 20 5.2 Slovní zpracování jednotlivých aplikací...................... 20 5.2.1 Assembla.................................. 21 5.2.2 FogBugz 6.0................................. 23 5.2.3 GanttProject 2.0.9............................. 25 5.2.4 MantisBT 1.1.6............................... 26 5.2.5 Microsoft Office Project Standard 2007................. 28 5.3 Tabelární zpracování................................ 29 5.4 Zdůvodnění vybrané aplikace........................... 30 5.4.1 Porovnání Assembly s jinými aplikacemi................. 30 5.4.2 Pokrytí požadavků týmu funkcemi Assembly.............. 30 6 Manuál k aplikaci Assembla 33 6.1 Zprovoznění Assembly a založení projektu.................... 33 6.2 Uživatelské role v Assemble............................ 34 6.3 Popis jednotlivých funkcí............................. 34 6.3.1 Funkce uživatelského profilu........................ 34 6.3.1.1 Start............................... 34 6.3.1.2 Stream.............................. 35 6.3.1.3 Profile............................... 35 6.3.1.4 Spaces............................... 35 6.3.1.5 Time............................... 36 6.3.1.6 Money.............................. 36 6.3.1.7 Orientation............................ 36 6.3.2 Funkce prostoru.............................. 36 6.3.2.1 Admin.............................. 36 6.3.2.2 Team............................... 37 6.3.2.3 Stream.............................. 38 6.3.2.4 Tickets.............................. 38 6.3.2.5 Milestones............................ 40 6.3.2.6 Messages............................. 41 6.3.2.7 Wiki................................ 41 6.3.2.8 Files................................ 41 6.3.2.9 Subversion & Track....................... 42 6.3.2.10 Time............................... 43 6.3.2.11 Chat............................... 43 6.3.2.12 Support.............................. 43 6.3.2.13 Protfolio Manager........................ 43 6.3.2.14 Member.............................. 43 6.3.2.15 Images.............................. 43 6.3.2.16 Dashboard............................ 44 6.3.2.17 Scrum............................... 44 6.3.2.18 Webhook............................. 44 6.3.2.19 Další funkce........................... 44

OBSAH xiii 6.4 Kde hledat další informace?............................ 44 6.5 Placená Assembla.................................. 44 7 Závěr 45 7.1 Zhodnocení vedení projektu............................ 45 7.2 Návrhy pro budoucnost.............................. 46 Literatura 47 A Seznam použitých zkratek 49 B Obsah přiloženého CD 51

xiv OBSAH

Seznam obrázků 1.1 Komunikace v týmu Mantichora - intenzita je naznačena tloušťkou spojnice. 3 3.1 Vodopádový model [5]............................... 11 3.2 Spirálový model [5]................................. 12 3.3 Přírůstkový model................................. 13 5.1 Náhled Assembly.................................. 23 5.2 Náhled FogBugz.................................. 25 5.3 Náhled GanttProjectu............................... 26 5.4 Náhled Mantisu................................... 28 5.5 Náhled MS Projectu................................ 29 6.1 Záložka Start.................................... 35 6.2 Záložka Admin - sekce Tools........................... 37 6.3 Záložka Stream................................... 38 6.4 Záložka Tickets - sekce Agile Planner....................... 40 6.5 Záložka Files.................................... 42 xv

xvi SEZNAM OBRÁZKŮ

Seznam tabulek 3.1 Vykonávání rolí managera............................. 9 5.1 Ceny Assembly používané na vlastním serveru.................. 21 5.2 Ceny Assembly používané na serveru výrobce.................. 22 5.3 Ceny FogBugz používaného na vlastním serveru................. 24 5.4 Tabelární shrnutí rešerše.............................. 29 xvii

xviii SEZNAM TABULEK

Kapitola 1 Úvod 1.1 Projekt Mantichora Projekt Mantichora vzniká jako víceletý týmový bakalářský projekt. Vedoucím projektu je Ing. Jiří Chludil z katedry počítačů FEL ČVUT. Prvotní inspirací k názvu Mantichora byl vzhled tohoto bájného tvora. Tělo této bytosti je totiž složeno z částí různých tvorů tak, jako je projekt Mantichora složen z prací různých studentů. Další inspirací byla několikadílná knižní sci-fi série od Davida Webera o Honor Harringronové a jejím rodném Hvězdném království Mantichoře, které má onu bájnou mantichoru ve znaku. Projekt Mantichora se tedy zabývá simulací vesmíru. Cílem projektu je vytvořit aplikaci zobrazující hvězdné soustavy, vesmírné lodě, družice atd. Ve finální verzi by systém měl být uživatelsky interaktivní. To znamená umožnit uživateli ovládat například vesmírné lodě, provádět s nimi manévry a možná dokonce vést bitvy. Vytvořit takový systém je ale časově velmi náročné, proto je Mantichora projektem jak týmovým, tak i víceletým. Proto nebudou v budoucnu součástí projektu pravděpodobně pouze práce bakalářské, ale i diplomové. Akademický rok 2008/2009 je prvním rokem vývoje projektu Mantichora. Z toho důvodu jsou cíle prvních bakalářů, pracujících na tomto projektu, omezeny na simulace jednoduchých hvězdných soustav. Výsledkem by tedy měl být funkční prototyp aplikace bez optimalizací. Cílem projektu pro tuto skupinu bakalářů bylo položit základní kameny aplikace Mantichora a nastínit možnosti dalšího vývoje. Proto pravděpodobně i tyto jednoduché simulace nepoběží bez viditelných chyb. 1.1.1 Tým Mantichora Celý projekt je skládankou prací prozatím sedmi studentů a Ing. Jiřího Chludila. Každý ze studentů má svůj úkol v rámci projektu. Některé práce na sebe úzce navazují, jiné jsou v podstatě samostatné. Za neformálního člena projektu je možné považovat ještě osmého studenta - Marka Sachu. 1

2 KAPITOLA 1. ÚVOD Členové týmu: Ing. Jiří Chludil - Vedoucí projektu Vedení konzultací týmu pořádaných každý týden. Schválení a úprava návrhů dalšího vývoje a nabízených řešení. Václav Podlipný - Řízení projektu Rešerše možností aplikační podpory projektu. Výběr vhodné aplikace, její nastavení, případně implementace vlastní aplikace. Jiří Kopecký - Síťová komponenta Prozkoumání nástrojů pro měření parametrů sítí. Vybrání vhodného nástroje a implementace rozhraní pro Mantichoru. Jiří Nekola - Matematicko-fyzikální engine Provádí analýzu aplikací pro výpočty matematicko-fyzikálních modelů. Implementuje matematicko-fyzikální model Sluneční soustavy a jeho napojení na grafický engine. Ondřej Čermák - Editor modelů Implementuje editor scény s podporou importu modelů a definic jejich fyzikálních vlastností. Scénu z tohoto editoru načítají grafické enginy. Michal Vaňkát - Grafický engine - OpenGL Implementuje grafický engine v prostředí OpenGL schopný načíst a zobrazit scénu z Editoru modelů. Vladimír Blažek - Grafický engine - Java 3D Implementuje grafický engine v prostředí Java 3D schopný načíst a zobrazit scénu z Editoru modelů. Zdeněk Hák - Management zásuvných modulů Rešerše knihoven a aplikací podporujících tvorbu pluginové architektury. Navrhuje alternativní možnosti propojení modulů pro aplikaci Mantichora. Marek Sacha - Studentova berlička II - podpora zásuvných modulů[4] Připravuje podporu Web Services pro projekt Studentova berlička, čímž projekt rozšíří o podporu zásuvných modulů. Po aplikaci Mantichora analyzuje možnosti nasazení Web Services. 1.1.2 Komunikace v týmu Jak je vidět z obrázku 1.1, někteří členové týmu jsou závislí na jiných více, někteří méně. Největší důraz na spolupráci se klade na skupinu editor modelů, matematicko-fyzikální engine a grafický engine. Je to z důvodu nutnosti shody na přenosu dat mezi moduly. Pro přenos dat mezi moduly bylo nakonec zvoleno XML. V editoru modelů je toto XML vytvořeno. Jsou v něm uvedeny názvy a vlastnosti jednotlivých objektů. Toto XML je nahráno do grafického enginu, pro který matematicko-fyzikální engine spočítá potřebná data. Přepočet dat a jejich zasílání grafickému enginu probíhá už za chodu aplikace. Jedná

1.2. MOTIVACE 3 Obrázek 1.1: Komunikace v týmu Mantichora - intenzita je naznačena tloušťkou spojnice se tedy o podporu zásuvných modulů. Původní idea předpokládala využití Web Services připravených od Marka Sachy pracujícího na projektu Studentova berlička. Zdeněk Hák měl původně zpracovat pouze konkurenční možnosti podpory zásuvných modulů. Nakonec se však Web Services ukázalo jako nevhodné řešení pro nasazení v projektu Mantichora díky velkému zpoždění. Aplikace si proto mezi moduly bude za běhu v první verzi vyměňovat data pomocí TCP a UDP packetů. Ostatní členové týmu řeší podporu tohoto implementačního jádra. Komunikace v týmu probíhala na každotýdenních schůzkách s vedoucím projektu a pomocí aplikace Assembla a instant messangerů. 1.2 Motivace Mojí prvotní vizí bylo vytvořit klient-server aplikaci v Javě pro podporu komunikace a výměny souborů pro menší pracovní týmy. Na konzultaci s Ing. Chludilem jsem se dozvěděl, že vede menší studentské týmy, pro které by obdobnou aplikaci potřeboval. Především pro největší tým pod vedením Ing. Chludila - Mantichora. Požadoval ale webovou aplikaci namísto klient-server aplikace, s čímž jsem souhlasil. Při rešerši se však ukázalo, že webových řešení daného problému je nespočet. Některá z těchto řešení byla dokonce freewarová a pro projekt Mantichora zcela dostačující. Nakonec bylo tedy rozhodnuto, že použijeme jednu z již naimplementovaných aplikací. Protože v tuto chvíli bylo potřeba vybranou aplikaci pouze spustit a nastavit, rozhodl jsem se, po dohodě s vedoucím práce, posunout svou bakalářskou

4 KAPITOLA 1. ÚVOD práci do teoretické roviny na téma Řízení softwarových projektů. Tato práce by tedy měla poskytnout vhled do problematiky řízení týmů vyvíjejících software a dát odpověď na to, jakou aplikaci použít pro podporu takového týmu.

Kapitola 2 Specifikace cílů Cílem projektu Mantichora je vytvořit aplikaci zobrazující hvězdné soustavy, vesmírné lodě, družice atd. Projekt Mantichora obsahuje mnoho částí. Mým úkolem bylo připravit pro potřeby projektu aplikaci pro podporu řízení tohoto projektu a vypracovat dokumentaci k této aplikaci. 2.1 Teorie k řízení projektu Tato část je zařazena pro lepší porozumění důležitosti použití aplikací podporujících vývoj softwaru. Teorie také vysvětluje některé pojmy související s tématem a popisuje různé možnosti vedení a organizace týmů. 2.2 Analýza požadavků projektu Pro nasazení vhodné aplikace na daný projekt je nutné analyzovat potřeby a požadavky jednotlivých členů projektu, vedoucího projektu a projektu jako celku. Analyzovat můžeme i potřeby oponenta. Požadavkem jednotlivých členů může být například začlenění systému pro správu verzí do aplikace podporující řízení projektu. Pak je ale nutné zvážit, jak velký úložný prostor bude potřeba zajistit pro verzování takového projektu. 2.3 Rešerše aplikací podporujících řízení projektu Na začátku je třeba stanovit si hodnotící kritéria, podle kterých budou různé aplikace posuzovány. Díky těmto kritériím bude možné sestavit přehled umožňující vybrat správnou aplikaci pro zamýšlené využití. Kvůli předpokládané velké rozdílnosti aplikací je třeba použít kritéria dostatečně obecná. Samotná rešerše obsahuje přehled různých systémů na základě navržených hodnotících kritérií. Celá část je pro větší přehled v závěru zpracována tabelárně. Vzhledem k ohromnému množství možných aplikací je zpracován pouze reprezentativní výběr. Nejvíce jsou zastoupeny webové aplikace, protože se pro vedení malých softwarových týmů používají nejčastěji a jsou také nejhojnější. 5

6 KAPITOLA 2. SPECIFIKACE CÍLŮ V této části je podrobně vysvětleno, proč byla vybrána právě aplikace Assembla, jaké vhodné vlastnosti má právě ve vztahu k projektu Mantichora a požadavkům členů tohoto projektu. 2.4 Manuál k aplikaci Assembla Manuál k aplikaci Assembla obsahuje popis jednotlivých funkcí a možnosti jejich nastavení. Podrobně jsou zpracovány funkce neplacené verze používané v projektu Mantichora. Dále kapitola obsahuje informace o důležitých změnách při zakoupení systému. Po přečtení této kapitoly by se měl čtenář bez problémů orientovat v Assemble a měl by být schopen si ji nastavit podle svých představ. 2.5 Zhodnocení vedení projektu Část hodnotí klady a zápory vedení projektu a také zda bylo přínosem zapojit do řízení projektu aplikaci Assembla. Pro vyhodnocení byl sestaven krátký dotazník. Dotazník také zjišťuje spokojenost s funkcemi Assembly a zjišťuje, zda členům projektu nechybí nějaká další funkcionalita.

Kapitola 3 Teorie k řízení projektů 3.1 Organizační struktury a role v projektovém řízení Vývoje softwaru se vždy účastní dvě hlavní skupiny rolí. Jsou to role na straně Objednatele a Dodavatele. Skupina rolí na straně Objednatele se vyznačuje tím, že všechny role jsou vykonávány kmenovými zaměstnanci Objednatele nebo specializovanými odborníky třetích stran tedy ne Dodavatele. Sponzor řeší finanční otázky a řadu organizačních a koordinačních úkolů. Sponzor má vliv na globální otázky budování softwaru (co a za kolik). Sponzor komunikuje jak s řešitelem, tak i s budoucími uživateli. Zadavatel sestavuje podle pokynů Sponzora zadání projektu a na základě představy o budoucí funkčnosti systému objednává takový systém od Dodavatele. Uživatel podílí se na formulaci vlastního zadání Manager projektu řídí projekt za stranu Objednatele. Představuje za stranu Objednatele nejvyšší autoritu. Tester provádí testování předaných částí softwaru. Testování probíhá na základě předem připravených scénářů. Skupina rolí na straně Dodavatele odpovídá za splnění úkolu zadaného Objednatelem. Manager projektu řídí projekt za stranu Dodavatele. Představuje za stranu Dodavatele nejvyšší autoritu. Je nositelem metodiky a měl by být i vůdčí osobností projektu. Obvykle má rozhodující vliv na úspěšnost projektu. Vedoucí pracovního týmu řídí určitý pracovní tým pracující na projektu. Člen pracovního týmu - vykonává zadání nadřízených. 7

8 KAPITOLA 3. TEORIE K ŘÍZENÍ PROJEKTŮ 3.1.1 Manager projektu Jak už bylo zmíněno, manager projektu je klíčovou osobností, proto popíšeme jeho roli důkladněji. U většiny dnešních projektů se můžeme setkat s dvěma managery: Managerem projektu Objednatele a Managerem projektu Dodavatele. V tabulce 3.1 jsou uvedeny role v působnosti Managera projektu s vysvětlením, jak by měl tyto role vykonávat. Role Jak by měla být vykonávána? Vedoucí skupiny Měl by mít nejenom formální autoritu, ale i získat autoritu neformální. Měl by mít dovednosti v práci s lidmi. Hájit pracovníky činné na projektu a prosazovat jejich zájmy. Udržet si dobré a kvalitní pracovníky na projektu, nebát se rozejít s pracovníky špatnými. Stratég Předcházet problémům na projektu na základě svých zkušeností a znalostí z předchozích projektů a na základě indicií ze současného průběhu projektu předvídat jeho budoucí problémy. Umět sestavit reálnou strategii realizace projektu vzhledem ke konkrétním podmínkám a při této strategii minimalizovat rizika s projektem spojená včetně rizik finančních. Diagnostik Identifikovat správně potenciální problémy projektu na základě informací o projektu. Manager konfliktů Prakticky každý projekt je jeden permanentní průšvih, proto by měl mít zkušenosti s řízením lidí ve vypjatých situacích a zachovat si přiměřené jednání a reakce i v případě řešení neřešitelných problémů a konfliktů. Poradce Měl by umět poradit s řešením věcných a odborných problémů projektu. To znamená, že má určité zkušenosti s výkonem práce, kterou řídí. Psycholog Znát a umět používat základní zásady psychologie při jednání jak s interními pracovníky na projektu, tak i se zástupci vedení vlastní firmy nebo Objednatele (Dodavatele). Filtr Jedna z nejdůležitějších rolí vedoucího projektu. Jejím výsledkem je, že vedoucí projektu přes sebe propouští dalším stranám pouze relevantní informace pro realizaci projektu. Je to velmi obtížná úloha, neboť vedoucí projektu má minimálně tři základní zdroje informací vlastní pracovníky projektu, vedení nebo partnery na straně Objednatele a vedení nebo partnery na straně Dodavatele.

3.1. ORGANIZAČNÍ STRUKTURY A ROLE V PROJEKTOVÉM ŘÍZENÍ 9 Role Revizor Plánovač Kontrolor Odborník na problém Diplomat Jak by měla být vykonávána? Kontrolovat větší celky projektu, provádět revize zpracovaných plánů ve vztahu k novým skutečnostem. Připravovat plán a harmonogram realizace projektu, pravidelně jej aktualizovat. Kontrolovat plnění zadaných úkolů a z jejich plnění nebo případně neplnění vyvozovat důsledky. Měl by rozumět věcným problémům projektu, pokud možno nejlépe v celém jeho rozsahu. Veškeré problémy a konflikty na projektu řešit konstruktivně a s vizí dosažení celkového hlavního cíle, tj. úspěšného ukončení projektu. 3.1.2 Pracovní týmy Tabulka 3.1: Vykonávání rolí managera Při různýh metodikách řízení projektu se můžeme setkat s různou strukturou pracovních týmů. Tyto pracovní týmy můžeme rozdělit do dvou skupin: Nestrukturované pracovní týmy Strukturované pracovní týmy Hlavní rozdíl mezi těmito dvěma typy je ve formálnosti ustanovení pracovního týmu. Zatímco nestrukturované pracovní týmy spojují společné cíle projektu a vize jeho řešení, strukturované týmy udržují pohromadě formální mechanismy (povinnost chodit do práce, odevzdávat reporty, dodržovat zadané postupy atd.). 3.1.2.1 Nestrukturované pracovní týmy Základní charakteristikou těchto týmů je, že nejsou vnitřně členěny a jednotliví příslušníci týmu nemají předem definované funkce. V takových týmech neexistuje žádná formální autorita. Autorita je uplatňována pouze neformální, většinou na základě zkušeností nebo schopností. Rozlišujeme 3 základní typy nestrukturovaných pracovních týmů. Osamělý vlk je zvláštním typem týmu, protože obsahuje pouze jednoho člena. Tato struktura byla velmi častá u prvních velmi jednoduchých projektů. Některé dnešní informační systémy jsou tak rozsáhlé, že osamělý vlk by na jejich vyřešení potřeboval roky. Přesto se s osamělým vlkem, jako organizační jednotkou, stále setkáváme. Ne na úrovni celého projektu, ale při řešeních jednotlivých specializovaných úloh spadajících do projektu. Horda je v podstatě neorganizovaný pracovní tým. Všichni v týmu jsou si rovni a mohou pracovat na jakékoliv části problému. Princip hordy vychází z představy, že při nasazení většího počtu pracovníků dosáhneme výsledků dříve. Na první pohled logická představa je však v některých případech zcela mylná. Obecně princip hordy není příliš vhodný pro řešení sofwarových projektů, u kterých je třeba zajistit dobrou návaznost jednotlivých fází vývoje.

10 KAPITOLA 3. TEORIE K ŘÍZENÍ PROJEKTŮ Demokratická skupina je pracovním týmem, který má oproti hordě několik vylepšení. Práce na projektu není dělena rovným dílem nebo náhodně, ale na základě schopností či zájmů členů týmu. Takto získávají jednotliví členové týmu další zkušenosti a stávají se specialisty ve svém oboru. Důležité pro demokratickou skupinu, je udržet společnou vizi cíle projektu, jinak hrozí i rozpad skupiny. V demokratické skupině většinou dojde k vytvoření skupiny, která se zabývá řízením projektu kvůli lepší organizaci práce. Demokratická skupina se nejvíce podobá strukturovaným pracovním týmům a je často užívána ve studentském prostředí. Studenti při práci na takovýchto týmových projektech získávají dobré pracovní návyky pro praxi [1]. 3.1.2.2 Strukturované pracovní týmy V těchto týmech se uplatňuje přenesená formální autorita. Úkoly, odpovědnosti a pravomoce jsou udělovány vedoucím týmu. Na vedoucím týmu leží odpovědnost za splnění projektu jako celku. Chirurgický tým se skládá z ideového programátora/analytika a podpůrných členů: kodéři, sekretariát, dokumentátor. Tým hlavního programátora je podobný chirurgickému týmu, ale je oddělena role ideového a koordinačního programátora. Ideový programátor má stále odpovědnost za splnění projektu jako celku. Koordinační programátor řeší některé speciální problémy vzniklé na projektu. Vícetýmová organizace obsahuje více úrovní předešlých dvou typů. Tato struktura je vhodná pouze pro velké projekty. 3.2 Životní cyklus projektu a jeho modelování Životním cyklem projektu se rozumí soubor fází, jimiž projekt prochází od svého počátku až po jeho dokončení. Jaké tyto fáze jsou, záleží na zvoleném modelu životního cyklu. Modelování životního cyklu je výhodné použít u všech dobře strukturovatelných problémů. Vývoj softwaru mezi takové dobře strukturovatelné problémy jistě patří. Při používání a dodržování modelů jsme schopni docílit vyšší efektivity, což vede k nižší výrobní ceně softwaru. Následuje popis čtyř nejpoužívanějších modelů. 3.2.1 Model Build & Fix Tento model je nejjednodušším modelem a odpovídá extrémnímu programování. Nedochází u něj k žádnému výraznému členění na fáze. Pro práci v týmu je nevhodný. Dá se využít pouze pro menší projekty prováděné osamělým vlkem. Model Build & Fix spočívá v napsání kódu, který něco dělá. Takový počáteční kód se opravuje, dokud nefunguje podle zadání a zákazník není spokojen [5].

3.2. ŽIVOTNÍ CYKLUS PROJEKTU A JEHO MODELOVÁNÍ 11 3.2.2 Vodopádový model Vodopádový model je klasický fázový model využívaný při vývoji softwaru. Fáze v tomto modelu probíhají sekvenčně, tzn. že konkrétní fáze může začít teprve potom, co jsou předloženy všechny definované výstupy fáze předchozí (z toho také pochází označení vodopádový - každá fáze představuje jakousi kaskádu vodopádu). Vodopádový model je vhodný pro různé typy krátkodobých a střednědobých projektů. Projekty prováděné dle vodopádového modelu jsou velmi dobře plánovatelné. Vodopádový model se také vyznačuje malými projektovými riziky a relativně vysokou jistotou/bezpečností a je doporučován především pro zakázky s pevnou cenou. Vodopádový model je představen na obrázku 3.1. Obrázek 3.1: Vodopádový model [5] 3.2.3 Spirálový model Výhoda spirálového modelu spočívá v silnějším zdůraznění rozdělení životního cyklu projektu do vyhodnotitelných kroků, což umožňuje zřetelně snižovat riziko výskytu chyb a tím náklady na jejich odstraňování zejména ve velkých a dlouhodobých projektech. Pro malé projekty není spirálový model vhodný, neboť v každé fázi vyžaduje vyšší náklady na

12 KAPITOLA 3. TEORIE K ŘÍZENÍ PROJEKTŮ určování cílů, evaluaci, vývoj a následné plánování [2]. Spirálový model je představen na obrázku 3.2. Obrázek 3.2: Spirálový model [5] 3.2.4 Přírůstkový model V současnosti se jedná o poměrně hojně využívaný model. Smyslem tohoto modelu je rozdělit projekt na relativně samostatné části s předem přesně definovanými vzájemnými vazbami a tyto samostatné části řešit de facto jako samostatné projekty. Díky tomu dosáhneme například možnosti rozložení projektu v čase nebo změnu pracovního týmu pro implementaci dalšího přírůstku. Další výhodou tohoto přístupu je získání funkčního jádra systému v poměrně krátkém čase. Další přírůstky toto jádro pouze vylepšují a přidávají nové funkce [1]. Přírůstkový model je představen na obrázku 3.3.

3.3. AGILNÍ METODY PLÁNOVÁNÍ 13 Obrázek 3.3: Přírůstkový model 3.3 Agilní metody plánování V poslední dobře se začali hojně používat při vývoji softwaru agilní metody plánování prací na projektu. Stalo se tak z jediného důvodu. Ohromné množství (okolo 70%) projektů končí neúspěšně z hlediska dodržení termínu a ceny. Agilní metody jsou spíše souborem doporučení a praktik, než striktními pravidly. Jedním z nejčastěji zaváděných Agilních přístupů je Scrum proces, jehož cílem je rozčlenit velké a komplexní softwarové projekty, které je těžké najednou obsáhnout a pochopit. Rozděluje rozsáhlé oblasti na menší celky a stanovuje priority jednotlivých úloh. Rozsáhlým částem projektu, které je třeba rozdělit na menší celky se říká obvykle Story. Scrum proces probíhá v pravidelných cyklech - Sprintech, které by obecně neměli být delší než 30 dní, délka Sprintu závisí na povaze projektu. Pokud se ukáže, že je třeba často měnit priority v průběhu Sprintu, je nastavená délka Sprintu moc dlouhá. Výhodou těchto Sprintů je jejich pravidelnost. Každý tým by měl v každém Sprintu zvládnout mnoho úkolů se stejným součtem bodů, jako součet bodů úloh v jiných Sprintech. Na začátku Sprintu je porada, která rozhodne o prioritách následujícího Sprintu. Na konci Sprintu se odevzdává zpráva o splnění, či nesplnění zadaných úkolů.

14 KAPITOLA 3. TEORIE K ŘÍZENÍ PROJEKTŮ Síla této metody je právě v pravidelnosti, které umožňuje zjistit nadcházející problémy včas. Nasazení agilních metod stojí hlavně ze začátku určité úsilí, ale vynaložená práce se vrátí v lepším odhadu termínu dokončení [3]. 3.4 Struktura a model použitý u projektu Mantichora Náš tým po celou dobu práce na projektu pracoval jako demokratická skupina. Vedoucí projektu byl po celou dobu poradcem a plnil zhruba role managera za stranu Objednatele i Dodavatele, jak jsou popsány výše. Všem členům na první schůzce vysvětlil svojí vizi projektu. Celý tým se pak během své práce snažil tuto vizi naplnit. Zároveň také každý od začátku věděl, na jaké části projektu bude pracovat. Toto zaměření si každý vybral podle svých schopností či zájmů. Z hlediska modelu celý projekt Mantichora spadá pod přírůstkové modely. Z důvodu rozsáhlosti projektu se počítá s prací několika generací bakalářů. Náš tým jako první generace připravil jádro projektu, které budou další generace rozšiřovat a vylepšovat. Přírůstkový model je pro projekt Mantichora nejvhodnější, právě z důvodu vyměňování týmů pracujících na něm. Pokusit se o vyměnění celého pracovního týmu u jiného modelu by bylo velmi komplikované.

Kapitola 4 Analýza požadavků projektu Na prvních schůzkách týmu Mantichora jsme přemýšleli o možnostech zlepšení týmové komunikace. Jak dočasně než bude zprovozněna nějaká aplikace pro řízení projektu, tak i následně v rámci dané aplikace. Jak jsem se již zmínil v první kapitole, původně jsme počítali spíše s implementací vlastní aplikace pro podporu týmu. Proto jsem pro okamžité potřeby týmu nainstaloval fórum. Použil jsem freewarové fórum phpbb3. Toto fórum je volně ke stažení na http://www.phpbb.com/donwloads/. Používání tohoto fóra prokázalo, že pro podporu projektu jako je Mantichora, je vhodné použít mnohem rozsáhlejší aplikaci, než je právě fórum. Nicméně pomocí tohoto fóra a na schůzkách týmu jsem začal zjišťovat potřeby ostatních spolupracovníků a vedoucího projektu na připravovanou aplikaci. 4.1 Požadavky vedoucího projektu a ostatních členů Některé požadavky funkčnosti aplikace byly zjevné od začátku a všichni byli přesvědčeni o jejich opodstatněnosti. Mezi tyto požadavky patří: Úkolování Prvním požadavkem na aplikaci byla možnost úkolování. Úkolování mělo být umožněno systémem každý každému. Pokud to bude možné, měly mít úkoly různé stavy (nový, testovaný, hotový, odmítnutý apod.), různou prioritu, možnost komentářů a přikládání souborů. Sdílení souborů Dalším jasným požadavkem byla možnost sdílet soubory i jinak než jako přílohy k úkolům. Správa časové návaznosti prací Ačkoliv jsme věděli, že většina prací na projektu Mantichora lze provádět bez ohledu na jiné, předpokládali jsme, že u těsněji spolupracujících prací, jako je grafický a fyzikální engine, bude třeba nějakým způsobem zajistit časovou návaznost. Verzovací systém 15

16 KAPITOLA 4. ANALÝZA POŽADAVKŮ PROJEKTU Lidé, kteří na projektu prováděli implementační práce, požadovali zprovoznění verzovacího systému. V ideálním případě chtěli verzovací systém přímo integrovat do aplikace podpory projektu. Sdílení zpráv/textů Posledním ze základních požadavků byla možnost předávání textových zpráv. Nebylo nijak specifikováno, jestli to má být řešeno formou fóra, message boardu (vzkazová tabule) nebo Wiki. Cílem tohoto požadavku bylo přesunout dohady o důležitých rozhodnutích z instant messangerů (ICQ a jiné) do systému, kde budou uchovány za prvé pro možnost pozdější kontroly, za druhé pro jednoduchost zapojení více lidí do diskuse. Další skupinou požadavků funkčnosti jsou takové, které nepožadovali všichni, ale někteří kolegové z týmu by je ocenili. Mezi tyto požadavky patří: Sledování časové náročnosti Toto sledování bylo nápadem vedoucího projektu. Mělo za cíl zjistit náročnost jednotlivých prací na projektu, pro lepší představu náročnosti projektu Mantichora v dalších letech, případně jiných projektů. Upozorňování na změny v projektu Pro snadnější orientaci ve vývoji projektu byla požadována funkce zasílání upozorňovacích e-mailů o změnách na projektu. Správa bugů Tento požadavek vznikl až v pozdní fázi projektu. Vznikl z důvodu typu stavů, kterým bug prochází od svého objevení po vyřešení, které jsou jiné než stavy klasického úkolu. Poslední skupinou požadavků jsou požadavky na technické vlastnosti systému. Mezi tyto požadavky patří: Velikost úložného prostoru Po krátké úvaze jsme předpokládali, že pro podporu projektu Mantichora by mělo stačit datové uložiště v řádu desítek megabytů. Typ aplikace Už na první schůzce požadoval Ing. Chludil pro podporu Mantichory webovou aplikaci provozovanou zdarma. Typ verzovacího systému Protože největší zkušenosti měli někteří kolegové se systémem Subversion, považovali jsme za vhodné zprovoznění právě tohoto systému. 4.2 Požadavky oponenta Po konzultaci s oponentem a vedoucím práce jsme se shodli na tom, že by oponent neměl být součástí tvorby práce přestože, že v zadání je zmíněna i analýza potřeb oponenta vzhledem k řízení týmových bakalářských resp. diplomových prací.

4.3. SHRNUTÍ ANALÝZY POŽADAVKŮ 17 4.3 Shrnutí analýzy požadavků Po provedení této analýzy bylo jasné, jakou aplikaci chceme. Zbývalo ji tedy pouze implementovat nebo najít vhodnou aplikaci pro nasazení v našem týmu. Započetím rešerše, je však vhodné stanovit si hodnotící kritéria.

18 KAPITOLA 4. ANALÝZA POŽADAVKŮ PROJEKTU

Kapitola 5 Rešerše aplikací podporujících řízení projektu 5.1 Hodnotící kritéria aplikací podporujících řízení projektu Hodnotící kritéria jsem sestavil pro větší objektivitu posuzování různých aplikací. Jsou zavedena proto, aby všechny aplikace byly hodnoceny ze stejných pohledů. Díky tomu je následná rešerše přehlednější a má větší vypovídací hodnotu. Pokud bychom nepoužili hodnotící kritéria, nemohli bychom dobře porovnávat různé aplikace, protože srovnávat možnost verzovacího systému s možností použití Wiki prostě nelze. Také tím předejdeme opomenutí vyhodnocení některého důležitého hlediska u rešeršovaných aplikací. Tato kritéria jsem rozdělil do dvou skupin - kategorizační kritéria a ostatní kritéria. 5.1.1 Kategorizační kritéria Pro vytvoření kategorií jsem použil dvě kritéria - cenu a způsob nasazení. 5.1.1.1 Cena Asi nikoho nepřekvapí, že je cena na prvním místě. Stejně jako u všech produktů, které lidé nakupují, i u softwaru hraje důležitou roli kvalita, při výběru z produktů. Nicméně kvalita hraje roli jen pokud si produkt můžeme dovolit. Kritérium ceny nám rozdělí rešeršované aplikace na tři kategotrie - placené, částečně placené a bezplatné. Částečně placená aplikace je taková, která má některé funkce k použití zdarma, ale některé pokročilejší funkce či vylepšení jsou již placené. 5.1.1.2 Způsob nasazení Způsob nasazení rozděluje aplikace na webové a desktopové. Webové aplikace můžeme dále rozdělit na dvě skupiny. 19

20 KAPITOLA 5. REŠERŠE APLIKACÍ PODPORUJÍCÍCH ŘÍZENÍ PROJEKTU První skupinou jsou aplikace, které používáme vzdáleně přes internet na stránkách tvůrců, druhou skupinou jsou aplikace, jejichž instalační soubory si stáhneme a nainstalujeme je na vlastní server. Často máme možnost využít obou těchto přístupů, ale ne vždy a pokud ano, je rozdíl například v ceně. 5.1.1.3 Vytvořené kategotie Jednoduchými počty zjistíme, že při takto zvolených kategorizačních kritériích vznikne devět kategorií. Rešeršní část ovšem obsahuje pouze pět aplikací. Je to ze dvou důvodů. Buďto proto, že některé aplikace spadají do více kategorií (například webové aplikace lze často provozovat na stránkách výrobce nebo je stáhnout a provozovat na svém serveru), nebo proto že například kategorie částečně placené desktopové aplikace není obsazena, protože takových aplikací se nedělá mnoho a pro podporu řízení projektu jsem žádnou takovou nenašel. 5.1.2 Ostatní kritéria Tato kritéria nám pomohou zaměřit se na jednotlivé funkce aplikací pro podporu řízení projektu. U většiny aplikací samozřejmě nebudou alespoň některé z těchto kritérií vůbec pokryta nebo budou řešena jiným způsobem. Na způsob splnění daných kritérií bude upozorněno v jednotlivých rešerších. Následující kritéria nepotřebují komentář, proto uvedu pouze jejich seznam: Požadavky na instalaci Propojení s verzovacími systémy Správy úkolů Časová návaznost částí projektu Sdílení souborů Sdílení zpráv/textů Česká lokalizace Veřejnost/privátnost projektu Dále bude u každého systému poznamenáno, pod jakou licencí je systém vytvořen, kým byl vytvořen (vývojář nebo společnost), ceník (u placených nebo částečně placených aplikací), domovská stránka projektu a screenshot z aplikace. Případně bude ještě uvedena nějaká zajímavá funkce daného systému. 5.2 Slovní zpracování jednotlivých aplikací Následujících pět aplikací je zpracováno v abecedním pořadí.

5.2. SLOVNÍ ZPRACOVÁNÍ JEDNOTLIVÝCH APLIKACÍ 21 5.2.1 Assembla Kategorie: částečně placená webová aplikace provozovaná na serveru výrobce placená webová aplikace provozovaná na vlastním serveru Licence: proprietární Vývoj: Assembla, LLC Domovská stránka projektu: http://www.assembla.com/ Cena: Základní funkce při použití na webu výrobce zdarma. Ceny za Assemblu při instalaci na vlastní server jsou uvedeny v tabulce 5.1. Počet uživatelů Cena 20 uživatelů $3 000 100 uživatelů $8 000 500 uživatelů $20 000 více jak 500 uživatelů $15/uživatel Tabulka 5.1: Ceny Assembly používané na vlastním serveru Placené použití na webu výrobce je možné vyzkoušet v pětidenní trial verzi. Ceny jsou uvedeny v tabulce 5.2. Uvedené ceny jsou platné k 25.6. 2009 [6]. Instalační požadavky [7]: Stažený instalační balík je virtual machine image spustitelný ve VMPlayeru. Balík obsahuje Assemblu na linuxovém jádru Debian 5.0, Apache server, mod_passenger, Ruby a MySQL server. Doporučuje se spouštět pod serverovým operačním systémem (Linux/MS Windows server) přes VMWare. Doporučená hardwarová konfigurace: RAM: 4GB CPU: Core 2 Duo nebo Quad Core Volné místo: alespoň 6GB Stručný popis: Assembla se vyznačuje pěkným a na pohled příjemným rozhraním. Z počátku ovšem může uživatelům činit potíže se v systému zorientovat. Již v neplacené verzi obsahuje Assembla řadu funkcí. Z verzovacích systémů máme na výběr Subversion, Git a Mercurial všechny ve spojení s Tracem, což je nástroj pro správu

22 KAPITOLA 5. REŠERŠE APLIKACÍ PODPORUJÍCÍCH ŘÍZENÍ PROJEKTU Cena $3/měsíc/uživatel $24/měsíc $49/měsíc $99/měsíc $249/měsíc Vlastnosti Assembly $3 za další uživatele v projektu $0.30 za 100MB prostoru 40 uživatelů 1 projekt 2GB prostoru 40 uživatelů 10 projektů 5GB prostoru profesionální nástroje pro správu neomezeně uživatelů 20 projektů 20GB prostoru profesionální nástroje pro správu neomezeně uživatelů 100 projektů 50GB prostoru profesionální nástroje pro správu Tabulka 5.2: Ceny Assembly používané na serveru výrobce bugů vytvoření pro spolupráci s repozitáři. Subversion a Git je také možno použít ve spojení s prohlížečem kódu. Případně je možné připojit vlastní Subversion externě. Správa úkolů je řešena pomocí ticketů, kterým jdou v případě potřeby přidávat další pole v administračním rozhraní projektu. Pro řešení časové návaznosti jsou v Assemble milestony (milníky). Tyto milestony mají svoje datum splnění. Pod vytvořený milestone se přidávají jednotlivé tickety, které mohou mít i závislosti (rodič - dítě) mezi sebou. Pro lepší orientaci a vyhledávání v ticketech je možné použít různé filtry. Sdílení souborů je vyřešeno jednoduchým uploadem souboru. U souboru lze uložit komentář a tagy pro lepší vyhledávání. Soubor lze také přehrávat novými verzemi. Informace o době aktualizace se také ukládají v detailech o souboru. V neplacené verzi je k dispozici 200MB prostoru. Do toho se započítává i místo využité v repozitářích. Správa textů nebo zpráv je vyřešena několika způsoby. Prvním a nejjednodušším způsobem je jednoduchý chat s historií. Dalším mnohem mocnějším nástrojem je možnost zpráv s vláknem odpovědí. Na tyto zprávy je možné upozorňovat pomocí e-mailu a je možné u nich nastavit prioritu. Poslední možností výměny textů je klasická Wiki. Nedostatkem Assembly je naprostá absence jakýchkoliv lokalizací a veřejnost projektů v neplacené verzi Assembly. V neplacené verzi může naprosto kdokoliv nahlížet soubory projektu. Mezi další zajímavé funkce Assembly patří možnost ukládání informací o čase stráveném na jednotlivých ticketech. Je možné přidávat i záznamy o čase bez ticketů. Další zajímavou funkcí je webhook, který umožňuje zasílat zprávy o změnách na projektu do externího webového systému.

5.2. SLOVNÍ ZPRACOVÁNÍ JEDNOTLIVÝCH APLIKACÍ 23 Placená verze systému nabízí technickou podporu, možnost vést projekty privátně nikoliv pouze veřejně, propracovanější podporu ticketů a lepší správu týmu. Obrázek 5.1: Náhled Assembly 5.2.2 FogBugz 6.0 Kategorie: placená webová aplikace provozovaná na serveru výrobce placená webová aplikace provozovaná na vlastním serveru Licence: proprietární Vývoj: Fog Creek Software Domovská stránka projektu: http://www.fogcreek.com/fogbugz/ Cena: Na webu výrobce je možné vyzkoušet aplikaci po 45 dní zdarma. Cena při používání na serveru výrobce je $25 / uživatel / měsíc. Ceny při používání na vlastním serveru jsou uvedeny v tabulce 5.3. Uvedené ceny jsou platné k 1.7. 2009 [8]. Instalační požadavky: pro Windows [11]: Web server: IIS

24 KAPITOLA 5. REŠERŠE APLIKACÍ PODPORUJÍCÍCH ŘÍZENÍ PROJEKTU Počet uživatelů Cena 1 uživatelů $199 10 uživatelů $1 899 100 uživatelů $14 999 500 uživatelů $49 999 více jak 500 uživatelů $15/uživatel Tabulka 5.3: Ceny FogBugz používaného na vlastním serveru.net Framework 2.0 Databáze: MySQL 4.1 a vyšší, MS SQL 7.0 2000, 2005, 2008 nebo MS Jet 4.0sp3 Mail server Verzovací systém: Subversion, Perforce, CVS, Visual SourceSafe nebo Vault pro Mac OS [10], Unix [9]: Web server: Apache s PHP 5.1 a vyšším a s rozšířeními XML, IMAP, MySQL, iconv Databáze: MySQL 4.1 a vyšší Mail server Open source.net: Mono Nástroj příkazové řádky: Curl Verzovací systém: Subversion, Perforce, CVS, Visual SourceSafe nebo Vault Stručný popis: FogBugz má na první pohled velmi jednoduchý, ale příjemný design. Pěkným rysem této aplikace je nebývale široká podpora verzovacích systémů. Umí spolupracovat se všemi, které jsou uvedeny v sekci instalační požadavky. Úkol se ve FogBugz nazývá case. Tyto casy mají několik možných typů vhodných pro různé typy úkolů včetně bugů. Rozhraní obsahuje filtry pro vyhledávání. Mají také vlastní datumy splnění. Jejich časová návaznost však nijak řešena není. Sdílet soubory lze v aplikaci pouze pomocí příloh ke casům nebo pomocí verzovacího systému, což se dá považovat za malou nevýhodu. Týmovou komunikaci řeší FogBugz pomocí Wiki nebo diskusí. V diskusích se dají vytvářet skupiny, a v těch pak jednotlivá diskusní vlákna. Lokalizaci FogBugz sice podporuje, ale je přeložen pouze do několika málo jazyků. Čeština mezi ně bohužel nepatří. Zajímavou funkcí je možnost vytvoření úkolu jako e-mailu. Takový úkol se po vytvoření přidá do seznamu úkolů a ještě se odešle na zadaný e-mail. Podporovány jsou i kopie a skryté kopie e-mailu.

5.2. SLOVNÍ ZPRACOVÁNÍ JEDNOTLIVÝCH APLIKACÍ 25 Obrázek 5.2: Náhled FogBugz 5.2.3 GanttProject 2.0.9 Kategorie: bezplatná desktopová aplikace Licence: GPL 2.0 a CPL, avšak používá celou řadu knihoven psaných pod jinými open sourcovými licencemi [12] Vývoj: GanttProject Team Domovská stránka projektu: http://www.ganttproject.biz/ Cena: zdarma Instalační požadavky: Aplikace je psaná v Javě, proto je jediným požadavkem funkční JRE. Stručný popis: Protože se jedná o čistě desktopovou aplikaci bez serverové části, neexistuje u této aplikace žádná návaznost na verzovací systémy nebo podpora sdílení souborů či textů. Možné jsou pouze komentáře u jednotlivých úkolů. Aplikace podporuje alespoň zasílání e-mailů členům projektu přes MS Outlook Express. Pro lepší týmovou práci je vhodné ukládat zdrojový soubor projektu na server pomocí WebDAV nebo FTP. Tyto funkce pro přenos dat jsou GanttProjectem podporovány.

26 KAPITOLA 5. REŠERŠE APLIKACÍ PODPORUJÍCÍCH ŘÍZENÍ PROJEKTU Úkoly jsou zpracovány skvěle, lze u nich nastavovat procento splněnosti, datum zadání a ukončení. Úkolům lze také přiřazovat více zdrojů (lidí) a návaznost na jiné úkoly. Časová návaznost je výborně zobrazena pomocí Ganttova diagramu, podle kterého se celý program jmenuje a který můžete vidět na obrázku 5.3, nebo pomocí PERT diagramu. PERT diagram je jiným zobrazením časové návaznosti úkolů. Ganttův diagram a diagram PERT jsou vzájemně převoditelné. V Ganttově diagramu je také možné vyznačit kritickou cestu. Kritická cesta zobrazuje úkoly, které se nesmějí zpozdit, aby nedošlo ke zpoždění celého projektu. Dobrou vlastností programu je česká lokalizace, která rozhodně usnadní orientaci v programu. GanttProject má také možnost importovat a exportovat soubory ve formátu používaném v MS Projectu nebo přehledně zobrazit graf přidělených zdrojů k jednotlivým úkolům. Právě možnost otevření souborů z MS Projectu dělá z této malé aplikace zajímavý produkt, protože je narozdíl od MS Projectu zdarma. Protože GanttProject napsán v Javě a jeho instalační soubor má pouhých 9 MB, je také velmi dobře přenositelný. Jak je vidět, je celá aplikace primárně dělána pro podporu větších projektů, kde jednotlivé úkoly trvají několik pracovních dní. Jde však o velmi všestrannou aplikaci pomocí níž lze organizovat práci na velké škále různých projektů od stavebnictví až po informační technologie. Obrázek 5.3: Náhled GanttProjectu 5.2.4 MantisBT 1.1.6 Kategorie: bezplatná webová aplikace provozovaná na vlastním serveru

5.2. SLOVNÍ ZPRACOVÁNÍ JEDNOTLIVÝCH APLIKACÍ 27 Licence: GPL Vývoj [15]: Victor Boctor Domovská stránka projektu: http://www.mantisbt.org/ Cena: zdarma Instalační požadavky [13]: pro MantisBT 1.1.x: Web server: Apache, IIS, atd. PHP s 4.3.0 a vyšší Databáze: MySQL 4.1.1 a vyšší (MS SQL a DB2 jsou také podporovány) Mail server Verzovací systém: CVS, Subversion pro MantisBT 1.2.x: Web server: Apache, IIS, atd. PHP s 5.2.0 a vyšší Databáze: MySQL 4.1.1 a vyšší (MS SQL, DB2 a PostgreSQL jsou také podporovány) Mail server Verzovací systém: CVS, Subversion Stručný popis: MantisBT má designově velmi strohé uživatelské rozhraní, kterým neupoutá. Z verzovacích systémů si při použití Mantisu můžeme vybrat mezi CVS a Subversion. Protože je ale MantisBT bugtracking aplikací, jsou možnosti nastavení stavů úkolů (bugů) nebo informací o nich velmi rozsáhlé. Úkoly mohou mít také vztah rodič - dítě, což představuje jediný styl řešení časové návaznosti v Mantisu. Administrátor projektu však může upravovat dokonce i tabulku možných přechodů mezi stavy úkolu. Sdílení souborů je možné jak v samostatné záložce dokumenty, tak pomocí příloh u úkolů. Popřípadě samozřejmě pomocí repozitáře. K aplikaci je možné přidat modul s Wiki pro zlepšení výměny textů v týmu. V základní instalaci však Wiki obsažena není. Stejně jako velká část jiných open sourcových aplikací má i Mantis mnoho lokalizací včetně české. Protože na několik textů bylo při překladu do češtiny zapomenuto, zůstanou i po změně jazykového nastavení v angličtině. Protože si Mantis instaluje každý uživatel na vlastní server, může si sám vybrat, zda budou jeho projekty veřejné nebo privátní. Poslední věc, která by měla být zmíněna, jsou zajímavé funkce pojmenované v Mantisu Road map a Billing. Road map přehledně ukazuje splněné a nesplněné úkoly na projektu a jejich poměr. Funkce Billing je schopna spočítat odpracované hodiny jednotlivých uživatelů a vynásobit hodinovou sazbou.

28 KAPITOLA 5. REŠERŠE APLIKACÍ PODPORUJÍCÍCH ŘÍZENÍ PROJEKTU Obrázek 5.4: Náhled Mantisu 5.2.5 Microsoft Office Project Standard 2007 Kategorie: placená desktopová aplikace Licence: proprietární Vývoj: Microsoft Domovská stránka projektu: http://office.microsoft.com/en-us/project/default.aspx Cena [14]: 17 160 Kč Instalační požadavky: MS Project lze nainstalovat pouze na Windows XP, Vista, Server 2003 a Server 2008. Stručný popis: MS Project je profesionálním softwarem pro práci s týmem. Kromě verze Standard existuje i verze Professional. Pro zlepšení týmových funkcí je také možné zakoupit MS Project server 2007. Ovšem i samotná klientská verze podporuje alespoň používání více účtů na jedné instalaci klienta. Podpora verzování nebo sdílení není v tomto produktu nikterak zahrnuta. Stejně jako v případě GanttProjectu je zpracování úkolů a jejich časové návaznosti vynikající. Aplikace zahrnuje Ganttův diagram, síťový (PERT) diagram, kalendář úkolů a zobrazení vytížení a používání zdrojů. Díky české lokalizaci se uživatel v MS Projectu snadno a rychle zorientuje. Další nabízené funkce jsou například generování grafů pro prezentace nebo počítání nákladů spojených s alokovanými zdroji na projektu. Pro vyzkoušení produktu a jeho funkcí je možné stáhnout 60-ti denní trial verzi.

5.3. TABELÁRNÍ ZPRACOVÁNÍ 29 Obrázek 5.5: Náhled MS Projectu 5.3 Tabelární zpracování V následující tabulce 5.4 jsou uvedeny rešeršované systémy a jejich sledované vlastnosti. Protože systémy zpracovávají dané vlastnosti jinak, oznámkoval jsem jejich řešení jako ve škole od 1 do 5. Pokud není daná vlastnost vůbec zahrnuta v systému, je to v tabulce znázorněno znakem X. U některých vlastností je použité slovní hodnocení. Aby nebylo nutné tabulku dělit na více částí, což by ji znepřehlednilo, jsou v hlavičce uvedeny místo plných názvů aplikací jejich zkratky: A - Assembla, F - FogBugz, G - GanttProject, M- MantistBT, P - MS Project. Vlasnost A F G M P placená aplikace ano/ne ano ne ne ano verzovací systémy 2 1 X 3 X správa úkolů 3 3 1 2 1 časová návaznost 2 X 1 4 1 sdílení souborů 1 3 X 3 X sdílení zpráv/textů 1 2 5 2 5 česká lokalizace ne ne ano ano ano privátní data projektu ne ano ano ano ano Tabulka 5.4: Tabelární shrnutí rešerše Z tabulky 5.4 jsou dobře patrné silné a slabé stránky desktopových a webových aplikací. Největší rozdíl je samozřejmě ve výměně dat, ať už souborů nebo zpráv. Tyto funkce nebývají u desktopových aplikací implementovány, protože je k nim potřeba server. Síla desktopových aplikací spočívá především v názorných diagramech a grafech zmíněných v rešerších GanttProjectu a MS Projectu. Další silnou stránkou je export do tisknutelných formátů nebo formátů pro prezentaci.