Management projektů
Programová podpora auditu sytému managementu kvality
HOT 4IT
Plán projektu
Historie Verze Datum 0.1 8. 4. 2010 0.2 11. 4. 2010 0.3 4. 5. 2010 0.4 5. 5. 2010
Status
Kdo Špaček Petr Špaček Petr Špaček Petr Špaček Petr
Poznámka Vytvoření Doplnění informací Rozepsání některých kapitol Přidání loga
Obsah Úvod............................................................................................................................ 3 Organizace projektu .................................................................................................... 3 2.1 Vytvoření týmu .................................................................................................... 3 2.2 Členové týmu ....................................................................................................... 3 3 Plán komunikace ......................................................................................................... 3 3.1 Komunikace v rámci týmu ................................................................................... 3 3.2 Komunikace se zákazníkem ................................................................................. 4 4 Role projektu ............................................................................................................... 4 4.1 Definování rolí ..................................................................................................... 4 4.2 Přiřazení rolí ......................................................................................................... 5 5 Ţivotní cyklus vývoje produktu .................................................................................. 6 5.1 Definování ţivotního cyklu vývoj produktu ........................................................ 6 5.2 Fáze vodopádového modelu ................................................................................. 6 5.2.1 Analýza a specifikace poţadavků ................................................................. 6 5.2.2 Návrh............................................................................................................. 6 5.2.3 Implementace ................................................................................................ 7 5.2.4 Testování ....................................................................................................... 7 5.2.5 Provoz a údrţba............................................................................................. 7 6 Definování a plánování rozsahu.................................................................................. 7 6.1 Činnosti ................................................................................................................ 7 7 Definování a plánování rizik....................................................................................... 8 7.1 Rizika ................................................................................................................... 8 8 Činnosti projektu a harmonogram .............................................................................. 9 8.1 Plánování činností a harmonogram ...................................................................... 9 9 Metriky...................................................................................................................... 10 10 Změnové řízení ......................................................................................................... 10 1 2
1 Úvod V tomto dokumentu jsou popsány činnosti, které jsou zapotřebí k realizování zákazníkových poţadavků.
2 Organizace projektu 2.1 Vytvoření týmu Tým byl sestaven na první přednášce předmětu MPR. Tento postup ocenili všichni členové, protoţe tým byl vytvořen ze spoluţáků, kteří jiţ hned od začátku projevili zájem o předmět.
2.2 Členové týmu Všichni členové týmu studují studijní obor Informační systémy nebo obor Management a informační technologie. Tyto obory mají velmi blízko k zadanému problému, coţ je velká výhoda. Login 1 2 3 4 5 6 7 8 9 10
xhorni00 xcharv03 xchola01 xjanos00 xmalis00 xsouko00 xspace02 xtison00 xvlasa00 xzelin12
Jméno Jakub Horník, Bc. Lukáš Charvát, Bc. Jan Cholasta, Bc. Petr Jánošík, Bc. Radim Mališ, Bc. Tomáš Soukop, Bc. Petr Špaček, Bc. Zdeněk Tisoň, Bc. Jaroslav Vlasák, Bc. Martin Zelinka, Bc.
Email
[email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected]
Tabulka 1: členové týmu.
3 Plán komunikace 3.1 Komunikace v rámci týmu Prvotní komunikace týmu proběhla prostřednictvím školního emailu (Tabulka 1: členové týmu. ). Z dalších prostředků komunikace pouţívá tým ICQ. Avšak pro hlavní komunikaci je zvolena sluţba poskytovaná společností Google s názvem Google wave. Sluţba pracuje podobným způsobem, jako diskuze. Je moţné k jednotlivým vláknům přidávat dokumenty, vkládat hlasování (Hlasování lze vyuţívat k demokratickému rozhodování.). Dalším způsobem komunikace jsou osobní schůzky týmu. Ty byly zvoleny tak, aby se tým sešel na konci kaţdé etapy, aby mohl posoudit postup a aby mohl zahájit etapu novou.
3.2 Komunikace se zákazníkem Pro komunikaci se zákazníkem byly určeny jasné pravidla, stanoveny přímo zadávající osobou. Komunikace je zajištěna pomocí e-mailu. Bliţší její popis je na stránkách předmětu: https://www.fit.vutbr.cz/study/courses/MPR/public/. Psát zprávy, dotazy i připomínky mohou všichni členové týmu.
4 Role projektu Definování rolí je důleţité rozdělení, podle kterého lze přiřazovat členy k jednotlivým pracím. Kaţdá role je zvlášť cenově ohodnocena, čímţ lze snáze určit předběţné náklady na vývoj.
4.1 Definování rolí Role
Popis
Vedoucí projektu
Osoba, která zodpovídá za chod celého projektu. Zajišťuje soudrţnost týmu, komunikaci se zákazníkem. Kontroluje, aby vývoj probíhal podle harmonogramu.
Analytik a specifikátor
Analytik je zodpovědný za definici problému a její specifikaci. Provádí prvotní analýzu projektu.
Plánovač
Osoba, která má na starosti plán projektu. Rozděluje projekt na jednotlivé etapy, k nim přiřazuje jednotlivé role, určuje milníky. Z pravidla se jedná o vedoucího projektu. V našem případě toto pravidlo platit nebude.
Návrhář
Návrhářova zodpovědnost je navrhnout produkt tak, aby jednotlivé části odpovídaly poţadavkům zákazníka. Navrhuje procesy systému, interakci s uţivatelem, GUI, E-R model, …
Vedoucí pro oponenturu návrhu
Osoba spolupracující s návrhářem. Oponentuje návrhářovi jeho činnost.
Programátor
Programátorova práce je realizovat návrh v daném programovacím prostředí a vytvořit tak zadanou hodnotu.
Tester
Tester je zodpovědný za testování dílčích částí systému, celého systému. Zajišťuje uţivatelské, zátěţové a bezpečnostní testy.
Vedoucí pro konfigurační řízení
Osoba, která stanovuje platformu vývoje, specifikuje prostředí. Dohlíţí na funkčnost svn, wiki a v neposlední řadě na stránku projektu.
Vedoucí dokumentace
Osoba tvořící dokumentační záleţitosti. V našem týmu dokumentace nedělá jedna osoba, ale vţdy je určen člen, který danou část tvoří a dokumentuje ji.
Vedoucí pro změnové řízení
V případě změny v provádění činnosti podle plánu, tato osoba navrhuje potřebné opatření a jak se s daným problémem vypořádat.
Vedoucí pro metriky
Osoba zodpovědná za sběr a vyhodnocení metrik.
Vedoucí pro rizika
Osoba zodpovědná za plán rizik, kde určuje potencionální rizika a navrhuje jejich řešení. Posuzuje jednotlivé členy.
Vedoucí pro vyhodnocení času
Osoba, která sleduje a vyhodnocuje čas strávený na jednotlivých etapách, plánovaných i skutečných.
Vedoucí pro uzavření projektu
Člen týmu, který se stará o uzavření projektu. Hodnotí projekt, předvádí produkt. Tabulka 2: definování rolí s jejich popisem.
4.2 Přiřazení rolí V předchozí kapitole jsou definovány jednotlivé role, nyní je třeba je přiřadit k jednotlivým členům. Jednotlivé činnosti jsou rozděleny tak, aby co nejvíce vyhovovali jejich řešitelům, aby jim takzvaně „padly na míru“. Dané rozdělení by se nemělo jiţ v průběhu měnit, avšak v případě problému jsou změny připustitelné.
1
Login xhorni00
Jméno Jakub Horník, Bc.
Role Vedoucí pro oponenturu návrhu, vedoucí pro konfigurační řízení
2
xcharv03
Lukáš Charvát, Bc.
Vedoucí pro vyhodnocení času, vedoucí pro uzavření projektu.
3
xchola01
Jan Cholasta, Bc.
Programátor
4
xjanos00
Petr Jánošík, Bc.
Vedoucí projektu, vedoucí pro rizika
5
xmalis00
Radim Mališ, Bc.
Tester, vedoucí pro změnové řízení
6
xsouko00
Tomáš Soukop, Bc.
Programátor, vedoucí pro metriky
7
xspace02
Petr Špaček, Bc.
Plánovač
8
xtison00
Zdeněk Tisoň, Bc.
Návrhář
9
xvlasa00
Jaroslav Vlasák, Bc.
Analytik a specifikátor
10 xzelin12
Martin Zelinka, Bc.
Analytik a specifikátor
Tabulka 3: přiřazení rolí.
5 Životní cyklus vývoje produktu Model ţivotního cyklu vývoje softwaru popisuje jednotlivé kroky a definuje jejich návaznost.
5.1 Definování životního cyklu vývoj produktu Z důvodu jednoduchosti byl zvolen poupravený vodopádový model ţivotního cyklu. U obyčejného vodopádového modelu je třeba dokončit jednu fázi a po ní můţe následovat další. Některé aktivity však lze začít, aniţ by musela být dokončena předchozí fáze. Takţe například fáze implementační můţe začít dřív, neţ skončí fáze návrhu, protoţe například k implementaci databáze postačí jiţ navrhnutý ER diagram.
5.2 Fáze vodopádového modelu Vodopádový model je jeden s nejjednodušších modelů. Dá se povaţovat i za nejstarší model ţivotního cyklu softwaru. Nevýhodou modelu je to, ţe plánovač není schopen domyslet všechny problémy, které se vyskytnou aţ v průběhu řešení. Přesto je však tento model uţitečný a pouţitelný u jasných a srozumitelných projektů. Vycházejí z něj ostatní modely ţivotního cyklu. Základní vodopádový model má pět fází. Uspořádání je zobrazeno na následujícím obrázku. Z fází se lze vrátit pouze na fázi předchozí. Poţadavky Návrh Implementace Testování Provoz a údrţba
Obrázek 1: vodopádový model.
5.2.1 Analýza a specifikace požadavků Je úvodní fází celého projektu. Získávají se poţadavky zákazníka, které posléze analyzujeme, definujeme a nakonec je formálně specifikujeme. 5.2.2 Návrh Navazuje na analýzu poţadavků, kde se systém rozloţí na menší části, které jsou posléze navrhovány a jsou definovány vztahy mezi nimi. K návrhu systému se nejčastěji pouţívá UML diagramů, kterých jsme vyuţili i v našem týmu.
5.2.3 Implementace Při implementaci se jiţ vytváří určité hodnoty. Striktně se vychází z návrhu systému. Nedílnou součástí implementace je i testování vznikajícího kódu. Tato fáze je po provozu a údrţbě časově i finančně nejnáročnější fází. 5.2.4 Testování Při testování se ověřuje funkčnost celého systému, jako jednoho celku. Při nalezení chyb je třeba se vrátit do implementační části a tím se celý projekt prodluţuje a roste mu cena. 5.2.5 Provoz a údržba Do této fáze se dá zařadit akceptace a převzetí systému. Jejím hlavním účelem je řešení problémů, které nastanou s pouţíváním a nasazením systému. Tato fáze také zahrnuje případné rozšíření nebo opravu nově nalezených chyb.
6 Definování a plánování rozsahu Pro úspěšnou realizaci zákazníkových poţadavků je třeba splnit jednotlivé dílčí úkony, které lze popsat strukturou rozkladu práce (WBS – Work breakdown structure). Její uspořádání kopíruje plánování projektu v programu MS Project.
6.1 Činnosti Strukturu WBS je zobrazena na následujících dvou obrázcích. V kaţdém úkolu nalezneme jeho název, dobu trvání, datum zahájení a ukončení. Pro lepší čtení, doporučuji přiblíţit.
Obrázek 2: WBS - 1.část.
Obrázek 3: WBS - 2.část.
7 Definování a plánování rizik Během plánování je důleţité počítat s událostmi, které mohou negativně, ale i pozitivně ovlivnit průběh projektu. Je třeba tyto události předem definovat a vhodně se na ně připravit, aby jejich dopady nebyly nijak kritické a drastické.
7.1 Rizika Rizika jsou popsána ve speciálním dokumentu Seznam rizik, který bude zhotoven k datu v plánu projektu.
8 Činnosti projektu a harmonogram Obě tyto kapitoly jsou spojeny do jedné a rozepisují projekt na jednotlivé úkoly. Tyto úkoly jsou dále zobrazeny ve vazbách, které určují jejich závislosti.
8.1 Plánování činností a harmonogram Plán projektu je vytvořen v programu MS project a je rozdělen na dva následující obrázky. Pro lepší čtení, doporučuji přiblíţit.
Obrázek 4: plánování činností a harmonogram - 1.část.
Obrázek 5: plánování činností a harmonogram - 2.část.
9 Metriky Metriky slouţí pro sledování a vyhodnocování při postupu v projektu. Je třeba definovat sběr těchto informací a určit postup jejich vyhodnocení. Této kapitole se bude podrobně zabývat dokument pojednávající pouze o metrikách.
10 Změnové řízení V případě odchylky termínu, při nalezení chyby nebo při neočekávané události je nutné zahájit změnové řízení, kdy se optimálně sejde celý tým a řeší vzniklou situaci. Je patrné, ţe takové řízení je poměrně finančně nákladné a je tedy nutné vhodně určit časovou mez, při které se změnové řízení zahájí. Menší výkyvy lze lehce dohnat usilovnější prácí některých členů týmu nebo vyuţitím určité rezervy, která je součástí plánu. V našem projektu je tato mez přibliţně 3 pracovní dny.
