Management projektů. Programová podpora auditu sytému managementu kvality HOT 4IT. Plán projektu

Transkript

1 Management projektů Programová podpora auditu sytému managementu kvality HOT 4IT Plán projektu Historie Verze Datum Status Kdo Poznámka Špaček Petr Vytvoření Špaček Petr Doplnění informací Špaček Petr Rozepsání některých kapitol Špaček Petr Přidání loga

2 Obsah 1 Úvod Organizace projektu Vytvoření týmu Členové týmu Plán komunikace Komunikace v rámci týmu Komunikace se zákazníkem Role projektu Definování rolí Přiřazení rolí Ţivotní cyklus vývoje produktu Definování ţivotního cyklu vývoj produktu Fáze vodopádového modelu Analýza a specifikace poţadavků Návrh Implementace Testování Provoz a údrţba Definování a plánování rozsahu Činnosti Definování a plánování rizik Rizika Činnosti projektu a harmonogram Plánování činností a harmonogram Metriky Změnové řízení... 10

3 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 Jméno 1 xhorni00 Jakub Horník, Bc. xhorni00@stud.fit.vutbr.cz 2 xcharv03 Lukáš Charvát, Bc. xcharv03@stud.fit.vutbr.cz 3 xchola01 Jan Cholasta, Bc. xchola01@stud.fit.vutbr.cz 4 xjanos00 Petr Jánošík, Bc. xjanos00@stud.fit.vutbr.cz 5 xmalis00 Radim Mališ, Bc. xmalis00@stud.fit.vutbr.cz 6 xsouko00 Tomáš Soukop, Bc. xsouko00@stud.fit.vutbr.cz 7 xspace02 Petr Špaček, Bc. xspace02@stud.fit.vutbr.cz 8 xtison00 Zdeněk Tisoň, Bc. xtison00@stud.fit.vutbr.cz 9 xvlasa00 Jaroslav Vlasák, Bc. xvlasa00@stud.fit.vutbr.cz 10 xzelin12 Martin Zelinka, Bc. xzelin12@stud.fit.vutbr.cz 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 u (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.

4 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í u. Bliţší její popis je na stránkách předmětu: 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 Vedoucí projektu Analytik a specifikátor Plánovač Návrhář Vedoucí pro oponenturu návrhu Programátor Tester Vedoucí pro konfigurační řízení Vedoucí dokumentace Popis 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 je zodpovědný za definici problému a její specifikaci. Provádí prvotní analýzu projektu. 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ář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, Osoba spolupracující s návrhářem. Oponentuje návrhářovi jeho činnost. Programátorova práce je realizovat návrh v daném programovacím prostředí a vytvořit tak zadanou hodnotu. 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. Osoba, která stanovuje platformu vývoje, specifikuje prostředí. Dohlíţí na funkčnost svn, wiki a v neposlední řadě na stránku projektu. 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.

5 Vedoucí pro změnové řízení Vedoucí pro metriky Vedoucí pro rizika Vedoucí pro vyhodnocení času Vedoucí pro uzavření projektu 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. Osoba zodpovědná za sběr a vyhodnocení metrik. Osoba zodpovědná za plán rizik, kde určuje potencionální rizika a navrhuje jejich řešení. Posuzuje jednotlivé členy. Osoba, která sleduje a vyhodnocuje čas strávený na jednotlivých etapách, plánovaných i skutečných. Č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é. Login Jméno Role 1 xhorni00 Jakub Horník, Bc. 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í.

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

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

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

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

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