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 Projekt Mantichora . . . . . 1.1.1 Tým Mantichora . . 1.1.2 Komunikace v týmu 1.2 Motivace . . . . . . . . . . .

. . . .

2 Specifikace cílů 2.1 Teorie k řízení projektu . . . 2.2 Analýza požadavků projektu 2.3 Rešerše aplikací podporujících 2.4 Manuál k aplikaci Assembla . 2.5 Zhodnocení vedení projektu .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

1 1 1 2 3

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

5 5 5 5 6 6

3 Teorie k řízení projektů 3.1 Organizační struktury a role v projektovém řízení . 3.1.1 Manager projektu . . . . . . . . . . . . . . 3.1.2 Pracovní týmy . . . . . . . . . . . . . . . . 3.1.2.1 Nestrukturované pracovní týmy . 3.1.2.2 Strukturované pracovní týmy . . . 3.2 Životní cyklus projektu a jeho modelování . . . . . 3.2.1 Model Build & Fix . . . . . . . . . . . . . . 3.2.2 Vodopádový model . . . . . . . . . . . . . . 3.2.3 Spirálový model . . . . . . . . . . . . . . . 3.2.4 Přírůstkový model . . . . . . . . . . . . . . 3.3 Agilní metody plánování . . . . . . . . . . . . . . . 3.4 Struktura a model použitý u projektu Mantichora

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

7 7 8 9 9 10 10 10 11 11 12 13 14

4 Analýza požadavků projektu 4.1 Požadavky vedoucího projektu a ostatních členů . . . . . . . . . . . . . . . . 4.2 Požadavky oponenta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Shrnutí analýzy požadavků . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15 15 16 17

5 Rešerše aplikací podporujících řízení projektu 5.1 Hodnotící kritéria aplikací podporujících řízení projektu . . . . . . . . . . . . 5.1.1 Kategorizační kritéria . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.1.1 Cena . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19 19 19 19

. . . . . . . . . . . . . . . . . . řízení projektu . . . . . . . . . . . . . . . . . .

xi

. . . . .

. . . . .

xii

OBSAH

5.2

5.3 5.4

5.1.1.2 Způsob nasazení . . . . . . . . . . . 5.1.1.3 Vytvořené kategotie . . . . . . . . . 5.1.2 Ostatní kritéria . . . . . . . . . . . . . . . . . Slovní zpracování jednotlivých aplikací . . . . . . . . 5.2.1 Assembla . . . . . . . . . . . . . . . . . . . . 5.2.2 FogBugz 6.0 . . . . . . . . . . . . . . . . . . . 5.2.3 GanttProject 2.0.9 . . . . . . . . . . . . . . . 5.2.4 MantisBT 1.1.6 . . . . . . . . . . . . . . . . . 5.2.5 Microsoft Office Project Standard 2007 . . . Tabelární zpracování . . . . . . . . . . . . . . . . . . Zdůvodnění vybrané aplikace . . . . . . . . . . . . . 5.4.1 Porovnání Assembly s jinými aplikacemi . . . 5.4.2 Pokrytí požadavků týmu funkcemi Assembly

6 Manuál k aplikaci Assembla 6.1 Zprovoznění Assembly a založení projektu 6.2 Uživatelské role v Assemble . . . . . . . . 6.3 Popis jednotlivých funkcí . . . . . . . . . 6.3.1 Funkce uživatelského profilu . . . . 6.3.1.1 Start . . . . . . . . . . . 6.3.1.2 Stream . . . . . . . . . . 6.3.1.3 Profile . . . . . . . . . . . 6.3.1.4 Spaces . . . . . . . . . . . 6.3.1.5 Time . . . . . . . . . . . 6.3.1.6 Money . . . . . . . . . . 6.3.1.7 Orientation . . . . . . . . 6.3.2 Funkce prostoru . . . . . . . . . . 6.3.2.1 Admin . . . . . . . . . . 6.3.2.2 Team . . . . . . . . . . . 6.3.2.3 Stream . . . . . . . . . . 6.3.2.4 Tickets . . . . . . . . . . 6.3.2.5 Milestones . . . . . . . . 6.3.2.6 Messages . . . . . . . . . 6.3.2.7 Wiki . . . . . . . . . . . . 6.3.2.8 Files . . . . . . . . . . . . 6.3.2.9 Subversion & Track . . . 6.3.2.10 Time . . . . . . . . . . . 6.3.2.11 Chat . . . . . . . . . . . 6.3.2.12 Support . . . . . . . . . . 6.3.2.13 Protfolio Manager . . . . 6.3.2.14 Member . . . . . . . . . . 6.3.2.15 Images . . . . . . . . . . 6.3.2.16 Dashboard . . . . . . . . 6.3.2.17 Scrum . . . . . . . . . . . 6.3.2.18 Webhook . . . . . . . . . 6.3.2.19 Další funkce . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

19 20 20 20 21 23 25 26 28 29 30 30 30

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33 33 34 34 34 34 35 35 35 36 36 36 36 36 37 38 38 40 41 41 41 42 43 43 43 43 43 43 44 44 44 44

OBSAH

6.4 6.5

xiii

Kde hledat další informace? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 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.1 3.2 3.3

Vodopádový model [5] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Spirálový model [5] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Přírůstkový model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

5.1 5.2 5.3 5.4 5.5

Náhled Náhled Náhled Náhled Náhled

Assembly . . . FogBugz . . . GanttProjectu Mantisu . . . . MS Projectu .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

23 25 26 28 29

6.1 6.2 6.3 6.4 6.5

Záložka Záložka Záložka Záložka Záložka

Start . . . . . . . . . . . . . . Admin - sekce Tools . . . . . Stream . . . . . . . . . . . . . Tickets - sekce Agile Planner . Files . . . . . . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

35 37 38 40 42

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

xv

3

xvi

SEZNAM OBRÁZKŮ

Seznam tabulek 3.1

Vykonávání rolí managera . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.1 5.2 5.3 5.4

Ceny Assembly používané na vlastním serveru . Ceny Assembly používané na serveru výrobce . Ceny FogBugz používaného na vlastním serveru Tabelární shrnutí rešerše . . . . . . . . . . . . .

xvii

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

9 21 22 24 29

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 Vedoucí skupiny

Stratég

Diagnostik Manager konfliktů

Poradce

Psycholog

Filtr

Jak by měla být vykonávána? 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. 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. Identifikovat správně potenciální problémy projektu na základě informací o projektu. 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ů. 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í. 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). 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Í Role Revizor Plánovač Kontrolor Odborník na problém Diplomat

9

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. Tabulka 3.1: Vykonávání rolí managera

3.1.2

Pracovní týmy

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


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Í

3.2.2

11

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


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


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Ů

4.3

17

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Í

5.2.1

21

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ů 20 uživatelů 100 uživatelů 500 uživatelů více jak 500 uživatelů

Cena $3 000 $8 000 $20 000 $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.


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ů 1 uživatelů 10 uživatelů 100 uživatelů 500 uživatelů více jak 500 uživatelů

Cena $199 $1 899 $14 999 $49 999 $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.


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


Ú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


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


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 placená aplikace verzovací systémy správa úkolů časová návaznost sdílení souborů sdílení zpráv/textů česká lokalizace privátní data projektu

A ano/ne 2 3 2 1 1 ne ne

F ano 1 3 X 3 2 ne ano

G ne X 1 1 X 5 ano ano

M ne 3 2 4 3 2 ano ano

P ano X 1 1 X 5 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.

30


Naproti tomu se webové aplikace soustřeďují na silnou podporu týmové komunikace a správy kódu. Týmová komunikace bývá často podpořena hned několika funkcemi. Správa kódu bývá podpořena verzovacím systémem, bug tracking funkcemi atd. To dělá z webových aplikací vhodnou volbu pro týmy zabývající se vývojem softwaru.

5.4

Zdůvodnění vybrané aplikace

K podpoře týmu Mantichora jsem vybral aplikaci Assembla zmíněnou v rešerši. Vybral jsem ji na základě požadavků z kapitoly 4 ostatních členů týmu a vedoucího projektu Ing. Chludila.

5.4.1

Porovnání Assembly s jinými aplikacemi

Základní požadavek vedoucího práce zněl - bezplatná webová aplikace. Z předcházející rešerše tuto podmínku splňuje pouze Assembla a MantisBT. Rozhodování mezi těmito dvěma systémy bylo těžké, protože Mantis má lépe propracovanou správu úkolů, ačkoliv ne tak uživatelsky příjemnou. Na druhou stranu Assembla má lepší podporu týmové komunikace a výměny souborů. Protože v týmu Mantichora jsou i lidé, kteří programátorské jádro pouze podporují, rozhodl jsem se, že větší váhu bude mít právě týmová komunikace. Přesto je třeba říct, že i Mantis je kvalitním systémem, což dokazuje i fakt, že druhý tým pod vedením Ing. Chludila - Studentova berlička - zvolil pro svou podporu právě Mantis. To, že v rešeršní části jsou uvedeny pouze dvě aplikace vyhovující základnímu kritériu, neznamená, že jsou to jediné aplikace, které jsem prozkoumal. Mezi další zajímavé aplikace, jejichž funkcemi jsem se zabýval byly: TaskFreak! 0.6.2, BugZilla 3.2.3, XP-Dev či PlanList. Avšak všechny tyto aplikace byly podle mě pro projekt Mantichora horší než Assembla. TaskFreak má velmi omezené funkce, které nezahrnují podporu verzování nebo přílohy k úkolům, i když je pravdou, že některé nedostatky TaskFreaku lze odstranit pomocí pluginů, kterých je pro TaskFreak napsána celá řada. BugZilla měla zase v porovnání s Assemblou horší vlastnosti v týmové komunikaci. BugZilla je velmi podobná systému Mantis. Oba systémy (BugZillu i TaskFreak) je nutné instalovat na vlastní server. Aplikace PlanList je pouze velmi jednoduchým úkolovníkem, který úplně postrádá jakoukoliv podporu práce se soubory, a proto je pro Mantichoru zcela nevhodná. Největším konkurentem Assembly byl XP-Dev, který nabízí větší úložný prostor v bezplatné verzi (500MB) a má mnoho podobných funkcí jako Assembla. Chybí mu ale například funkce pro správu času stráveného na projektu jednotlivými členy projektu.

5.4.2

Pokrytí požadavků týmu funkcemi Assembly

Jak jsem už zmínil, Assembla splnila základní požadavek vedoucího práce. V následujícím seznamu jsou další požadavky a funkce Assembly, které je pokrývají. Funkce jsou podrobně popsány v následující kapitole 6. • Úkolování Tento požadavek je pokryt funkcí Tickets.

5.4. ZDŮVODNĚNÍ VYBRANÉ APLIKACE

31

• Sdílení souborů Sdílení souborů je možné buďto uploadem souboru pomocí funkce Files, připojením souboru jako přílohy k ticketu nebo commitem do repozitáře verzovacího systému. • Správa časové návaznosti prací V Assemble můžeme pomocí funkce Milestones vytvářet milníky, u kterých je nastaveno datum splnění. Jednotlivé tickety jsou pak přidávány k vytvořeným milníkům. • Sdílení zpráv/textů Pro podporu sdílení zpráv a textů nabízí Assembla hned několik funkcí. Funkce Messages funguje jako vzkazník spolupracující s e-mailem. Dále je možné použít ještě Chat s historií a Wiki. • Sledování časové náročnosti Funkce Time umožňuje sledovat čas jednotlivých členů projektu strávený na určitých úkolech. • Upozorňování na změny v projektu Toto je v Assemble řešeno pomocí funkce Stream. Ta zobrazuje změny v projektu a je možné ji nastavit tak, aby odesílala i upozornění na tyto změny na e-mail. • Správa bugů Správa bugů je v Assemble zastoupena pouze aplikací Trac u verzovacích systémů. Jinak je nutné používat Tickety nejen pro úkoly, ale i pro bugy. • Velikost úložného prostoru Protože jsme předpokládali, že pro vývoj aplikace Mantichora bude stačit úložný prostor v řádu desítek megabytů. 200MB, které nabízí aplikace Assembla, jsou dostačující. • Verzovací systém a jeho typ Assembla splňuje tento požadavek integrací Subversion, Gitu a Mercurialu. Kvůli zkušenostem se Subversion jsme používali právě tento verzovací systém.

32


Kapitola 6

Manuál k aplikaci Assembla Základní informace o Assemble jsou zmíněny v rešerši v sekci 5.2.1. Nebudu je proto opakovat, pouze připomenu, že Assembla nemá českou lokalizaci. Má pouze dvě jazykové mutace: anglickou a španělskou. V projektu Mantichora jsme používali anglickou verzi. V textu tedy zmiňuji anglické názvy funkcí.

6.1

Zprovoznění Assembly a založení projektu

Pokud chceme používat neplacenou verzi Assembly na webu http://www.assembla.com, je potřeba projít nejprve registrací. K registrování uživatele je potřeba vyplnit registrační formulář, na který se dostaneme z hlavní stránky přes odkaz Register v pravém horním rohu. Po vyplnění a odeslání registračního formuláře je na uživatelem zadanou e-mailovou adresu zaslán ověřovací e-mail, který obsahuje odkaz, po jehož otevření se účet aktivuje a je připraven k používání. Tento aktivační odkaz přivede uživatele na úvodní stránku účtu. Na úvodní stránce jsou odkazy Create a new space (vytvořit nový prostor) a Create an empty space (vytvořit prázdný prostor). Odkaz Create an empty space vede rovnou na stránku s druhým krokem registrace. Odkaz Create a new space vede na stránku, kde si můžeme vybrat z přednastavených konfigurací Assembly pro různé účely, jak je připravili tvůrci Assembly, nebo zvolit vytvoření prázdného účtu. Všechny odkazy vedou na druhý krok registrace. Druhý krok registrace se týká plateb za používání Assembly. Pro bezplatné užívání vybereme free public plan (volný veřejný plán). To nás přivede k poslednímu kroku. Třetím krokem je vyplnění formuláře, ve kterém nastavíme jméno vytvářeného prostoru, jeho URL, pod kterým bude přístupný, popis prostoru, tagy pro snadnější vyhledání prostoru a zabezpečení přístupu k prostoru. Po provedení těchto dvou registrací (uživatele a prostoru) je prostor připravený k používání. Pokud se uživatel potřebuje připojit k již založenému projektu, provede pouze registrace uživatele. Poté kontaktuje správce prostoru, ke kterému se chce přidat. Ten pak rozhodne o přijetí daného uživatele k prostoru. Důležité je si ale uvědomit, že celý zakládaný prostor je veřejný. To znamená, že do něj může kdokoliv nahlížet. Privátní prostor nabízí pouze placená verze Assembly. Bezplatná verze je proto použitelná pro komunitní a open sourcové projekty.

33

34

KAPITOLA 6. MANUÁL K APLIKACI ASSEMBLA

6.2

Uživatelské role v Assemble

V Assemble existují čtyři uživatelské role. Pokud vlastník prostoru nezmění nastavení, jsou vlastnosti těchto rolí následující. • Owner (vlastník) má možnost měnit všechny vlastnosti prostoru, upravovat nastavení funkcí Assembly, přijímat další členy do prostoru a používat funkce prostoru. Prostor může mít více vlastníků, nejméně však jednoho. Běžný člen se stane vlastníkem, pokud ho povýší některý ze stávajících vlastníků. • Member (člen) může používat funkce v prostoru (vytvářet tickety, uploadovat soubory atd.). V roli člena bývá většina účastníků v prostoru. • Watcher (pozorovatel) je členem prostoru. Pozorovatel však může celý prostor pouze prohlížet. Nemůže tedy nic editovat ani mazat. • Non-member (nečlen) může prohlížet celý prostor, nemůže ho však nijak měnit ani používat jeho funkce. Ve všech veřejných prostorech Assembly může mít tuto roli jakýkoliv uživatel internetu.

6.3

Popis jednotlivých funkcí

Jak je z obrázku 6.1 a dalších v této kapitole patrné, jsou všechny hlavní funkce přístupné ze záložek v horní části stránky. Protože jsem používal standardní vzhled Assembly, nachází se většina odkazů na rozšiřující funkce či filtry v pravé části jednotlivých stránek, což je později v textu několikrát zmíněno.

6.3.1

Funkce uživatelského profilu

Tyto funkce jsou přístupné ihned po přihlášení uživatele, ještě před jeho připojením k určitému prostoru. 6.3.1.1

Start

Tato záložka se zobrazuje po přihlášení. Obsahuje důležité aktuální informace pro přihlášeného uživatele. Jsou zobrazovány prostory, kterých je uživatel členem, nedávno navštívené prostory, odpovědi na vlastní zprávy (navazuje na funkci Messages v sekci 6.3.2.6), Milestony prostorů, ve kterých je uživatel členem (navazuje na sekci 6.3.2.5), oznámení Assembly a úkoly přiřazené tomuto uživateli. Oznámení Assembly jsou oznámeními od vývojářského týmu a většinou informují o změnách ve funkcích Assembly. Úvodní stránka také obsahuje odkazy na založení nového prostoru a na dokumentaci, ve které může uživatel najít některé užitečné tipy. Celá dokumentace je v angličtině. Pokud uživateli nevyhovuje rozložení boxů s informacemi, může si je jednoduše přeskupit pomocí funkce Drag and Drop. Záložka start je ukázána na obrázku 6.1.

6.3. POPIS JEDNOTLIVÝCH FUNKCÍ

35

Obrázek 6.1: Záložka Start

6.3.1.2

Stream

Záložka zobrazuje všechny změny, které nastaly v prostorech, jichž je uživatel členem. Funkce je v zásadě shodná se stejnojmennou funkcí v sekci 6.3.2.3. V pravé části stránky je možné v seznamu zvolit, které prostory chceme, aby byly zobrazeny. Jsou však zobrazovány všechny typy událostí. Bližší informace o typech událostí jsou v sekci 6.3.2.3. 6.3.1.3

Profile

Profile (profil) obsahuje dvě podzáložky: Information (informace) a Skills (dovednosti). V podzáložce Information můžeme nastavit či změnit informace zadané při registraci (e-mail, časovou zónu, jméno, telefon a další). Je možné změnit také heslo a přihlašovací jméno účtu. Na této stránce je také možné smazat celý účet. Stránka obsahuje i odkaz na aktuální stav profilu, jak se zobrazuje ostatním uživatelům. V podzáložce Skills je možné napsat, jaké máme dovednosti, kolik hodin týdně uživatel může strávit na projektech, zadat tagy pro vyhledávání, domovskou stránku a zemi uživatele. Nakonec je možné připojit ještě přílohu. Nastavit můžeme také viditelnost dovedností. Možnosti jsou: viditelné veřejně, viditelné spolupracovníkům v týmu a neviditelné. 6.3.1.4

Spaces

V záložce je pouze seznam prostorů, jichž je uživatel členem. Pokud je uživatel řadovým členem nebo pozorovatelem, je zobrazena možnost opuštění prostoru. Pokud je uživatel

36


vlastníkem prostoru, tuto možnost nemá. Na této stránce je také odkaz na vytvoření nového prostoru. 6.3.1.5

Time

Funkce Time v uživatelském profilu patří bohužel mezi méně povedené funkce Assembly. Zobrazuje záznamy o čase stráveném na úkolech vytvořených pomocí funkce prostoru Time 6.3.2.10. Pomocí stránky umístěné pod odkazem Start timer je možné založit úkol i zde. Nejedná se však o ticket. K tomuto úkolu lze ticket přiřadit. Další možnost je pod odkazem Export time. Měla by umět ukázat časové záznamy podle zadaného časového rozmezí nebo tyto záznamy exportovat do souboru. Při testování této funkce jsem ovšem zjistil, že výběr časového rozmezí nefunguje správně. Používání této funkce je tedy nepřehledné a pravděpodobně nebude pro uživatele přínosem. Mohu tedy pouze doporučit tuto funkci nepoužívat. 6.3.1.6

Money

Tato záložka má několik podzáložek. Nicméně, jak název napovídá, celá se zabývá penězi. V případě, že uživatel používá placenou verzi Assembly, je záložka Money důležitá. Jsou zde vidět provedené platební transakce, lze převádět peníze pomocí platebních karet nebo systému PayPal do i z Assembly. Assembla provozuje také partnerský program, který uživatel nalezne v podzáložce Affiliate program. Program nabízí 25% z peněz, které utratí za Assemblu jiný uživatel během prvních 6 měsíců užívání, pokud při registraci uvede uživatele jako doporučitele Assembly. 6.3.1.7

Orientation

Záložka obsahuje odkazy na různé články v dokumentaci k Assemble, vytvoření nového prostoru a stránku s popisem vlastností Assembly.

6.3.2

Funkce prostoru

Funkce prostoru má uživatel k dispozici okamžitě po připojení k prostoru. V prázdném prostoru bez zapnutých jakýchkoliv funkcí Assembly má uživatel v roli člena k dispozici záložky Team a Stream. Uživatel v roli vlastníka má k dispozici navíc záložku Admin. 6.3.2.1

Admin

K této záložce má přístup pouze vlastník prostoru, protože je v ní možnost upravovat vlastnosti celého prostoru. Najdeme zde odkaz na změnu prostoru z neplaceného na placený. Dále tu je možnost zvolit používané funkce v prostoru, nastavit práva různým uživatelským rolím, připojit prostor do portfolia (využívá funkci Member 6.3.2.14), změnit vzhled prostoru a informace o něm zadané při jeho vytvoření, vytvořit jeho zálohu.


37

Možnost zvolení používaných funkcí je pod odkazem Tools a je ukázána na obrázku 6.2. Přidat či odebrat funkci je možné kdykoliv během používání Assembly. Jak je z obrázku patrné, přidání nebo odebrání funkce se provede jedním kliknutím na add (přidat) nebo delete (smazat). V pravé části stránky je zobrazen seznam používaných funkcí. Pokud mají tyto funkce nějakou možnost nastavení, je u nich odkaz Settings (nastavení), který přivede uživatele na stránku s nastaveními.

Obrázek 6.2: Záložka Admin - sekce Tools

Pokud chce uživatel vytvořit zálohu, přejde na odkaz Resources and Backup a použije odkaz Request backup. Poté musí uživatel počkat 10 - 30 minut, než se záloha vygeneruje. Když po této době znovu navštíví sekci Resources and Backup, nalezne připravenou zálohu ke stažení.

6.3.2.2

Team

Na stránce v záložce Team se členům prostoru zobrazí seznam všech členů tohoto prostoru. Kliknutím na jméno člena se otevře okno se základními informacemi o něm a odkaz na stránku s jeho profilem. Za jménem je zobrazován odkaz report, který uživatele zavede na stránku, která zobrazuje činnost člena za posledních 7 dní. Vlastník projektu vidí také zmíněný seznam a navíc může jednotlivým členům přidat popisek, měnit jejich roli, nebo je vyhodit z prostoru. V pravé části stránky je možnost přidání uživatele. Uživatele lze vyhledat a následně přidat podle jeho e-mailové adresy nebo podle přihlašovacího jména. Je také možné přizvat uživatele z jiných prostorů z portfolia, pokud je používána funkce Member 6.3.2.14.

38

6.3.2.3


Stream

Tato záložka má podobnou funkci jako záložka Stream v uživatelském profilu. Zobrazuje však změny pouze v prostoru, ve kterém se uživatel právě nachází. V pravé části jsou však jiné filtry. Je možné nastavit datum, od kterého chceme zobrazit události a počet dní, zobrazených zpětně od tohoto data. Dále je možné označit, jaké typy událostí chceme zobrazit. Poslední možností je filtrování podle člena prostoru. Typy událostí jsou v Assemble různé. K většině funkcí Assembly je přiřazena nějaká událost. Události jsou tedy například vytvoření ticketu nebo jeho update. Poslední funkcí v záložce Stream je možnost nastavit zasílání e-mailů upozorňujících na změny v prostoru. Na výběr je odesílání oznámení okamžitě po nějaké změně, hodinové a denní sumáře změn nebo zakázání těchto upozorňování. Dále je možné nastavit, o jakých změnách (typech událostí) chceme být informováni. Pro používáni Assembly mohu doporučit zasílání zpráv o všech změnách v denních nebo hodinových sumářích. Náhled záložky Stream je na obrázku 6.3

Obrázek 6.3: Záložka Stream

6.3.2.4

Tickets

Záložka Tickets obsahuje několik podzáložek, protože tickety jsou nejdůležitější funkcí Assembly. Právě tickety jsou v Assemble používány pro úkolování. První podzáložka se jmenuje shodně - Tickets. Její příklad je na obrázku 5.1. V horní části této stránky je odkaz na vytvoření nového ticketu a výběrové pole pro filtr uplatňovaný


39

na zobrazení seznamu ticketů. Základní informace o ticketu, které při jeho vytvoření uživatel zadává, jsou: název, komu je ticket přiřazen, komponenta, milestone, do kterého patří, priorita, text úkolu a odhad počtu pracovních hodin. Automaticky je vygenerováno datum vytvoření ticketu, jeho zadavatel a status s hodnotou New (nový). K ticketu je také možné přidat soubor v příloze. Komponentu lze zadat, pouze pokud jsou vytvořeny komponenty vlastníkem prostoru. Komponenty mohou být například GUI, Síťová komponenta atd. Editací ticketů lze měnit údaje zadané při jeho vytvoření nebo ho smazat. Navíc však uživatel může rozšířit seznam členů prostoru, kteří budou detailně informování přes e-mail o změnách při plnění úkolu. Standardně je podrobně informován pouze zadavatel a řešitel. Dále je možné přidat přílohu, komentář, počet odpracovaných hodin nebo vztah k jinému úkolu. Vztahy jsou typu rodič - dítě. To se vztahuje k agilním metodám řešení úkolů, což je podrobněji popsáno u podzáložky Agile Planner (agilní plánovač). V Assemble jsou u ticketů rozlišovány čtyři stavy: nový, připravený k testování, neplatný a hotový. Uživatelsky velmi příjemnou funkcí je aktivní pravé tlačítko myši v seznamu ticketů. Při stisknutí se objeví menu, které umožní rychle změnit položky výčtového typu, jako je stav nebo řešitel, nebo zkopírovat odkaz, otevřít ticket v novém okně, nebo se dostat do jeho editace. Druhá podzáložka nazvaná Filters (filtry) umožňuje uživateli vytvořit si vlastní filtr a uložit ho do seznamu filtrů pro použití v podzáložce Tickets. Podzáložka Search (hledat) umožňuje, jak název napovídá, vyhledávání v ticketech. Systém vyhledává jak v názvech ticketů, tak i v jejich tělech. Další podzáložka se jmenuje Metrics. Ta poskytuje uživateli několik grafů aktivity (týkajících se ticketů a milestonů) v prostoru za poslední dobu. Zobrazeny jsou následující grafy: Počet podle stavu, Aktivní tickety podle priority, Aktivní tickety podle komponenty, Poměr vytvořených a uzavřených ticketů (denní a týdenní pohled), Aktivní tickety podle uživatele, Uzavřené tickety podle uživatele a Kalendář milestonů. Navíc jsou v této sekci zobrazeny tickety s nejvyšší prioritou. Šestou podzáložkou v pořadí je Batch Update (hromadná aktualizace). Zobrazuje tickety podle zvoleného filtru stejně jako první podzáložka, navíc však obsahuje zaškrtávací pole pro označení ticketu. Na stránce je také box s položkami ticketu. Nastavením těchto položek, vybráním ticketů a kliknutím na odkaz Update Selected Tickets (aktualizovat vybrané tickety) uživatel provede změnu ve všech vybraných ticketech současně. Sedmá záložka poskytuje uživateli nejpokročilejší funkci pro tickety v Assemble. Jedná se o Agile Planner. Více o agilních metodách je napsáno v sekci 3.3. Jak je vidět na obrázku 6.4, je v horní části lišta s nastaveními: Sort Stories (řazení příběhů), Send E-mail Alerts (zasílat upozornění na e-mail) a Show Closed Tickets (zobrazovat uzavřené tickety). V levé části stránky můžeme vytvářet nové story. Jsou to vlastně rodičovské tickety, pod které můžeme přiřazovat jejich děti (child tickets). Rodičovský ticket (story) je složitý úkol, jehož splnění dosáhneme splněním jeho dětí. V pravé části jsou zobrazené tickety rozděleny podle příslušnosti k milestonům. Pro jednoduché přeřazování ticketů můžeme použít funkci Drag & Drop. Poslední podzáložka jménem Settings se zobrazuje samozřejmě pouze vlastníkovi prostoru. V této záložce může vlastník vytvářet nové komponenty, měnit přednastavení polí

40


Obrázek 6.4: Záložka Tickets - sekce Agile Planner

při vytváření ticketu, přidávat nová pole nebo měnit standardní zobrazení. Dále může přenastavit strategii upozorňování na změny v ticketech, povolit zadávání ticktetů pomocí emailu či zajistit import a export ticketů z/do souboru. Samozřejmě může upravit také práva různých rolí v záložce Tickets. 6.3.2.5

Milestones

Pod záložkou Milestones je k dispozici funkce, která umožňuje sledovat termíny dokončení jednotlivých částí prací na projektu. Záložka obsahuje tři podžáložky. První z nich (Milestones) má v horní části možnost vytvoření nového milestonu. Při vytváření milestonu uživatel zadává pouze název, datum dokončení, odpovědného člena a popis. Je to právě datum dokončení, který má pomoci uhlídat časovou návaznost prací v projektu. Všechny tickety spadající pod milestone, by měly být splněny před tímto datem a milestone pak může být označen za kompletní. V podzáložce Milestones je také filtr pro zobrazení milestonů umožňující zobrazit všechny milestony, hotové milestony nebo nadcházející milestony, což je přednastavená možnost. Milestony lze také seřadit podle data splnění vzestupně nebo sestupně. U jednotlivých milestonů je také odkaz na Burndown Chart. Pod tímto odkazem se nalézá graf zobrazující, kolik hodin zbývá odpracovat na milestonu. Když u ticktetu přidaného k milestonu uživatel nastaví předpokládaný čas potřebný ke splnění, hodnota v tomto grafu se zvýší. Pokud však uživatel přidá k některému ticketu čas, který na jeho řešení už strávil, hodnota v grafu poklesne. V druhé podzáložce, nazvané Calendar, je kalendář přehledně zobrazující hotové, nadcházející a zpožděné milestony. Kalendář je stránkován po měsících.


41

Poslední podzáložkou je Import/Export. Import je umožněn z aplikace Basecamp. Exportovat kalendář je možné do iCal (kalendář používaný v Mac OS) nebo do Google Calendar, který je umístěn na http://www.google.com/calendar/. 6.3.2.6

Messages

Tato funkce je jednoduchým fórem. Umožňuje umísťovat zprávy a reagovat na ně. Při vytvoření zprávy musíme zadat její předmět a obsah. Můžeme také zvolit její prioritu (5 stupňů + bez priority), připojit přílohu a zvolit komu z týmu přijde upozornění na zprávu na e-mail. V pravé části je menu filtrů. Máme zde možnosti zobrazovat pouze první zprávu vláken, zprávy řazeny podle data od nejnovějších, zprávy řazeny podle priority nebo všechny zprávy umístěné ve vláknech. Také je možné zapnout či vypnout zobrazování těla zpráv v jejich seznamu. Vlastník má dispozici navíc odkaz Settings, pod kterým může nastavit nutnost potvrzování zpráv vlastníkem před zobrazením, automatické zobrazování těl zpráv v jejich seznamu povolení zasílat zprávy do této funkce z e-mailu pro určitou uživatelskou roli. Také může nastavit přístup různým uživatelským rolím. 6.3.2.7

Wiki

Jedná se o klasickou Wiki, která je k vidění na mnoha webech. Umožňuje tedy vytvářet vzájemně prolinkované texty. V pravé části jsou k dispozici opět nástroje pro manipulaci s jednotlivými vytvořenými stránkami. Je tu možnost editace stránky, její vytištění, historie a smazání. Dále je tu navigace ve vytvořených stránkách, možnost jejich reorganizace a vytvoření nové stránky. Velmi pěkně je zpracována zejména historie stránky, která umožňuje zobrazovat i rozdíly mezi uloženými verzemi. Vlastník prostoru má navíc v pravém menu odkaz Settings. V nastaveních může povolit přidávání komentářů k stránkám na Wiki, formát značkování při tvorbě stránek a nastavit přístup různým uživatelským rolím. 6.3.2.8

Files

Files je jednoduchou funkcí pro sdílení souborů. Obsahuje samozřejmě možnost nahrání, vyhledání a smazání souboru. Při nahrání souboru může uživatel nadefinovat jeho tagy pro vyhledávání a napsat jeho popis. Filtr tagů se zobrazuje v levé části, jak je vidět na náhledu 6.5. Před názvem souboru je zaškrtávací pole. Pokud zaškrtneme více polí může uživatel hromadně soubory mazat nebo měnit jejich tagy. U souborů je možné pomocí funkce edit nahrát novou verzi. Datumy změn se zaznamenávají v detailech o souboru, jak je opět vidět na obrázku 6.5. Funkce Files obsahuje také filtr Image Tool nástroj obrázků. Tento nástroj vybere ze souborů pouze obrazové soubory včetně souborů *.pdf.

42


Obrázek 6.5: Záložka Files

6.3.2.9

Subversion & Track

Tato záložka je jednou z možností, pokud chce uživatel používat verzovací systém v Assemble. V záložce je levá půlka věnována Subversion. Uživatel v ní nalezne zmínku o možných Subversion klientech, odkaz na procházení repozitáře pomocí Tracku, odkaz na integrovaný prohlížeč kódu nebo odkaz na import/export repozitáře. Dalšími možnými nastaveními je: přenastavení odkazu na procházení repozitáře pomocí Tracku tak, že vede na integrovaný prohlížeč kódu, umožnění zadávání Track ticketů z SVN komentářů nebo nastavení URL, kam má Assembla poslat HTTP GET po provedeném commitu. Poslední zmíněná funkce slouží pro propojení s jinou webovou aplikací. Pravá půlka záložky je věnována nastavením Tracku. Vlastník prostoru nalezne v pravé půlce navíc možnosti nastavení přístupu jednotlivých rolí. Track může fungovat i jako samostatná aplikace, proto má i svoje tickety nebo wiki. Modul ticketů a wiki však při používání Assembly může uživatel vypnout. Tuto možnost najde mezi nastaveními v této záložce. Dále tu je možnost resynchronizace Tracku, kterou uživatel použije pokud se objeví chybová hláška. Chyba někdy nastane po nahrání SVN repozitáře. Další možnosti jsou: import ticketů z Tracku do Assembly a restart oprávnění v Tracku, protože Track má vlastní administrátorské rozhraní, na které se uživatel dostane přes odkaz Admin. Poslední možností je import/export Track databáze. Assembla obsahuje ještě několik verzovacích nástrojů, které nebudu podrobně rozepisovat. Jsou to: Source/SVN, Source/Git, Subversion & Trac, Git & Trac, Mercurial & Trac, External Subversion, GitHub.


6.3.2.10

43

Time

V této záložce může uživatel ukládat záznamy o čase stráveném na projektu. Tyto záznamy je možné provázat s tickety, není to ale podmínkou. Záložka umožňuje také prohlížení uložených záznamů. Uživatel si může zvolit, kteří členové prostoru a v jakém časovém rozmezí ho zajímají. Pod odkazem Settings přístupném pro vlastníka prostoru lze nastavit maximální povolený čas, který je možné přiřadit k ticketu. 6.3.2.11

Chat

Tato funkce není klasickým chatem, který všichni znají z mnoha webů. Narozdíl od těchto webů obsahuje historii a možnosti uploadu souborů. Tuto funkce je vhodné použít, pokud tým využívající Assemblu pracuje na projektu intenzivně a členové projektu jsou k Assemble připojeni velmi často. V takovém případě může do značné míry tento chat zastoupit funkci instant messangerů, oproti kterým nabízí výhodu komunikace více než dvou členů zároveň. Některé dnešní instant messangery toto sice umí také, ale uživatel musí vždy znovu vytvářet komunikační skupinu. Funkcí Chat končí funkce používané týmem Mantichora. Žádnou z následujících funkcí už náš tým nevyužíval. 6.3.2.12

Support

V této záložce je možné zadávat tickety stejně jako v záložce Tickets. Zde vytvořené tickety se zobrazují i v záložce Tickets, ale neobsahují tolik informací. Jde o zjednodušené tickety vhodné pro zadávání úkolů typu: Objednat nový notebook. Záložka obsahuje tři podzáložky. Open Ticket (otevřené tickety), Closed Tickets (uzavřené tickety) a pro vlastníka prostoru opět Settings. V nastaveních může uživatel zvolit, které pole budou tyto tickety obsahovat a zda budou tato pole pouze viditelná nebo i editovatelná. Lze zde také uložit uvítací zprávu této funkce zobrazovanou u otevřených ticketů. Samozřejmostí je nastavení přístupu různých uživatelských rolí. 6.3.2.13

Protfolio Manager

Portfolio manager umožňuje vytvářet skupiny prostorů. 6.3.2.14

Member

Tato funkce umožňuje přidat prostor do skupiny prostorů (portfolia). 6.3.2.15

Images

Funkce Images (obrázky) umožňuje nahrání obrázků do galerie. Výhodou oproti funkci Files je viditelnost náhledů.

44


6.3.2.16

Dashboard

Funkce Dashboard (vývěska) zobrazuje podobné informace jako Stream v sekci 6.3.2.3. Informace jsou ale rozděleny podle typu do boxů. Boxy lze přeskupit pomocí funkce Drag & Drop. 6.3.2.17

Scrum

Scrum je jednoduchou funkci používanou při agilním plánování. Srum umožňuje podávat denní nebo týdenní zprávy o provedených a připravovaných pracích. 6.3.2.18

Webhook

V této záložce může uživatel vytvořit spojení mezi Assemblou a jinou aplikací. Uživatel zadá URL, kam se mají data poslat, vybere metodu (GET/POST), typ dat (aplication/xml, text/plain atd.) a pak zadá do posledního pole patřičný zdrojový kód, který se má poslat a vybere události, které se mají zasílat. V Pravé části záložky jsou předpřipravená nastavení například pro Twitter, což je sociální síť s blogy. 6.3.2.19

Další funkce

Assembla poskytuje ještě několik málo bezplatných funkcí pro spojení s jinými webovými aplikacemi nebo pro propojení více prostorů v Assemble. Jedná se tedy o okrajové funkce, u nichž jsem neprozkoumal jejich funkčnost, protože jsem neuvažoval o jejich nasazení při projektu Mantichora nebo jiném projektu.

6.4

Kde hledat další informace?

Na stránkách Assembly každému novému uživateli Assembly pomůže prohlédnout si tutoriálová videa, které nalezne na stránce http://www.assembla.com/features/videos/. Dalším dobrým zdrojem informací o funkcích a vlastnostech Assembly je její dokumentace na stránce http://www.assembla.com/wiki/show/breakoutdocs/. Tato dokumentace je v angličtině.

6.5

Placená Assembla

Největší výhodou, kterou uživatel placené verze Assembly získá, je možnost vedení privátních projektů. Dalšími výhodami je větší a v případě potřeby rozšiřitelný úložný prostor, e-mailová a telefonická zákaznická podpora a lepší zabezpečení pomocí šifrování. Možné je zesílit bezpečnost také použitím IP filtrů pro přístup k prostoru. Placená Assembla obsahuje také několik vylepšení ve svých funkcích.

Kapitola 7

Závěr Cílem této práce bylo poskytnout základní teorii k řízení projektu, prozkoumat možnosti aplikační podpory řízení projektu a připravit vhodnou aplikaci pro použití v projektu Mantichora. Z rešeršní části vyplynula jako nejlepší aplikace pro projekt Mantichora aplikace Assembla. Tato poskytuje velké množství funkcí a ne všechny byly použity při práci na projektu a některé z použitých mohly být využívány lépe a efektivněji. Přesto použití této aplikace, přispělo v první etapě projektu Mantichora k plynulému vývoji. Protože je Mantichora modulární aplikací, byl by její vývoj bez použití Assembly nebo obdobné aplikace mnohem obtížnější a méně dynamický.

7.1

Zhodnocení vedení projektu

Pro zhodnocení vedení projektu a nasazení Assembly byl sestaven dotazník, který vyplnili jak členové, tak vedoucí projektu Mantichora. Dotazník se skládal ze dvou částí. První mapovala zkušenosti s týmovými projekty, druhá používání Assembly a vedení projektu. První část ukázala velkou nezkušenost všech členů projektu s prací v týmu. Žádný z členů týmu Mantichora nikdy nepracoval s aplikací pro podporu řízení projektu a jen někteří měli zkušenosti s používáním verzovacích systémů. Většina členů týmu také v dotazníku přiznala, že se k týmu přidala právě proto, aby získala zkušenosti s týmovou prací. Tato zkušenost se určitě bude hodit všem v jejich budoucí kariéře. Druhá část dotazníku ukázala, že členové týmu byli s podporou, kterou jim poskytla aplikace Assembla, spokojeni a pokládají použití této aplikace za přínosné. Všichni tázaní však jednomyslně odmítli možnost, že by Assembla mohla zcela nahradit instant messangery v komunikaci týmu. To také trochu souvisí s četností používání Assembly. V průměru používali členové týmu Assemblu zhruba 3-krát týdně. Ukázalo se také, že členové používající Assemblu častěji (většinou 5x týdně) využívají i funkci zasílání upozornění o změnách na e-mail. Ne všichni členové týmu používali funkci Assembly pro sledování časové náročnosti a ti, co ji používali, bohužel nezapsali všechny provedené úkony. Proto se nepodařilo získat věrohodná data o náročnosti jednotlivých úloh. Přes použití Assembly všichni také potvrdili důležitost každotýdenních setkání týmu a nutnosti informovanosti celého týmu o vývoji v jednotlivých částech projektu. Dotazník uzavírala otázka na hodnocení vedoucího projektu

45

46

KAPITOLA 7. ZÁVĚR

Ing. Chludila. Hodnotilo se jako ve škole a výsledná známka byla 2-3. Sám vedoucí práce se ohodnotil stupněm 3 a přiznal nedostatek času, což bylo také nejčastější výtkou ostatních členů týmu. Další výtkou byla malá motivace k dodržování dohodnutých termínů. Naopak velmi kladně byly hodnoceny již zmíněné každotýdenní schůzky týmu.

7.2

Návrhy pro budoucnost

Protože letošní tým byl spokojen z aplikací Assembly, bylo by tedy dobré pokračovat v jejím používání i v dalších letech. Dokonce bych navrhl, aby příští tým pokračoval v práci ve stejném prostoru v Assemble, v jakém pracoval letošní tým, nebo aby bylo založeno portfolium prostorů, do kterého bude zařazen jak stávající prostor, tak nový prostor vytvořený pro příští tým. V aplikaci Assembla byla připravena funkce Chat, která ale nebyla využívána, a proto by měla být z nabídky odstraněna. Naopak by pro další roky bylo přínosné striktní dodržování milestonů. Ty by podle mne měl vytvářet vedoucí práce nebo jeden, jím pověřený člen týmu. V týmu by měli i nadále zůstat letošní členové alespoň v roli watchera (pozorovatele). Za zvážení určitě stojí využití agilního plánování. Myslím, že pro projekt Mantichora by toto plánování bylo přínosné, zvláště bude-li i budoucí tým pokračovat v každotýdenních schůzkách, které se velmi osvědčily. Myslím, že agilní plánování s týdenním Sprintem by přineslo rychlý a dynamický rozvoj celé aplikace. Pokud bude zvolena tato metoda, mělo by být jasně na každé schůzce rozhodnuto, na jakých Story se bude v následujícím Sprintu pracovat. Stojí za zvážení, jestli nezadávat úkoly do Assembly přímo na schůzce. Story by měl spravovat a určovat vedoucí projektu. V případě agilního plánování je možné přidat do Assembly záložku Scrum umožňuje odevzdávání pravidelných reportů. Myslím však, že vyžadování reportů ke Sprintům, je zbytečně oficiální. K dobrému naplánování příští etapy projektu by mohla přispět příprava obecných cílů již přes prázdniny. Tyto cíle možná bude nutné značně upravit podle studentů, kteří se přihlásí k projektu Mantichora, přesto by však měli pomoci dobře rozvrhnout jednotlivé úseky projektu a navrhnout milestony a komponenty projektu. Pokud chceme v příštích etapách lépe sledovat časovou náročnost úkolů, je třeba přimět studenty, aby zadávali všechna data. V časové náročnosti by se rozhodně neměl objevit pouze čas strávený nad vytvořením řešení, ale i čas strávený při studiu potřených podkladů.

Literatura [1] P. Doucek. Řízení projektů informačních systémů. PROFESSIONAL PUBLISHING , Praha, 2th edition, 2006. [2] I. V. Nešetřil. Fázová organizace projektu a průběhové modely. http://fmmi10.vsb.cz/639/qmag/mj19-cz.htm, stav z 1. 7. 2009. [3] Z. Šochová. Agilní metody a scrum. http://businessworld.cz/business-rizeni-podniku/Agilni-metody-a-Scrum-4740, stav z 1. 7. 2009. [4] M. Sacha. Studentova berlička ii - podpora zásuvných modulů. https://dip.felk.cvut.cz/browse/pdfcache/sacham1_2009bach.pdf, stav z 1. 7. 2009. [5] P. Steinbauer. Softwarové inženýrství. http://www.mechatronics.cz/lib/exe/fetch.php?id=mechmedia=mech:si:si1.pdf, stav z 1. 7. 2009. [6] Assembla - pricing/plans. http://www.assembla.com/plans, EN, stav z 1. 7. 2009. [7] Assembla - assembla private install software. http://www.assembla.com/wiki/show/breakoutdocs/Assembla_Private_Install_Software, EN, stav z 1. 7. 2009. [8] Fogbugz - price list. http://www.fogcreek.com/FogBugz/PriceList.html, EN, stav z 1. 7. 2009. [9] Fogbugz - instalation requirements - unix. http://www.fogcreek.com/FogBugz/docs/60/topics/setup/Unixssystemrequirements.html, EN, stav z 1. 7. 2009. [10] Fogbugz - instalation requirements - mac os. http://www.fogcreek.com/FogBugz/docs/60/topics/setup/Macsystemrequirements.html, EN, stav z 1. 7. 2009.

47

48

LITERATURA

[11] Fogbugz - instalation requirements - windows. http://www.fogcreek.com/FogBugz/docs/60/topics/setup/Windowssystemrequirements.html, EN, stav z 1. 7. 2009. [12] Ganttproject - licence. http://www.ganttproject.biz/license, EN, stav z 1. 7. 2009. [13] Mantisbt - requirements. http://www.mantisbt.org/requirements.php, EN, stav z 1. 7. 2009. [14] Předpokládané ceny produktů systému microsoft office 2007. http://www.microsoft.com/cze/office/howtobuy/prices.mspx, stav z 1. 7. 2009. [15] Wikipedie - mantis. http://cs.wikipedia.org/wiki/Mantis, stav z 1. 7. 2009.

Příloha A

Seznam použitých zkratek CPL Common Public License CPU Central Processing Unit CVS Concurrent Versions System FTP File Transfer Protocol GPL General Public License GUI Graphical User Interface HTTP Hypertext Transfer Protocol IIS Internet Information Services IMAP Internet Message Access Protocol JRE Java Runtime Enviroment LLC Limited liability company MS Microsoft OS Operating System PERT Project Evaluation and Review Technique PHP Personal Home Page RAM Random Access Memory SQL Structured Query Language SVN Subversion URL Uniform Resource Locator VM Virtual Machine

49

50

PŘÍLOHA A. SEZNAM POUŽITÝCH ZKRATEK

WebDAV Web-based Distributed Authoring and Versioning XML Extensible Markup Language

Příloha B

Obsah přiloženého CD readme.txt text Bakalarska_prace.pdf zdroj 1_uvod.tex 2_cile.tex 3_teorie.tex 4_pozadavky.tex 6_reserse.tex 8_dokumentace.tex 9_zhodnoceni.tex Bakalarska_prace.tex hyphen.tex k336_thesis_macros.sty reference.bib figures LogoCVUT.pdf img agile.jpg assembla.jpg files.jpg fogbugz.jpg ganttproject.jpg komunikace.jpg mantis.jpg msproject.jpg prirustek.jpg spirala.jpg start.jpg stream.jpg tools.jpg vodopad.jpg

51

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

Recommend Documents