WBS(Work Breakdown Structure)



Podobné dokumenty
Integrace datových služeb vědecko- výukové

Webová aplikace Znalostní testy online UŽIVATELSKÁ PŘÍRUČKA

Analýza Systém Správce

Uživatelská příručka

Sázková kancelář Z pekla štěstí

Základní aplikace s přehledem vlastních úkolů k řešení, umožňuje (tlačítka v pořadí zleva doprava):

Uživatelská příručka Zaměstnavatelský portál AXA

NASTAVENÍ OPRÁVNĚNÍ UŽIVATELŮ

Vize. Thang Do. Adam Papoušek.

Metoda EVM. Katedra softwarového inženýrství Fakulta informačních technologií České vysoké učení technické v Praze Ing. Martin Půlpitel, 2011

Výtisk č.: Počet listů 19. Přílohy: 0 ÚZIS ČR. Role žadatel - postup

SOFTWAROVÉ INŽENÝRSTVÍ

Základy programování Úvodní informace. doc. RNDr. Petr Šaloun, Ph.D. VŠB-TUO, FEI (přednáška připravena z podkladů Ing. Michala Radeckého, Ph.D.

Business Suite for Notes

David Staščák

Internetový informační portál INTEGRI INFO

1. Využívání služeb servisního portálu

ABRA Software a.s. ABRA on- line

Dobrý FOTO Popis produktu a jeho rozšíření

MANUÁL PRO UŽIVATELE WEBU ADRESÁŘ DESIGNÉRŮ

Databáze pro evidenci výměny a prodeje publikací Knihovny Kabinetu hudební historie EÚ AV ČR (Dokumentace k projektu)

Dobrý SHOP Popis produktu a jeho rozšíření

PROJEKT DIGITÁLNÍ MAPA VEŘEJNÉ SPRÁVY - ČÁST ÚZEMNĚ ANALYTICKÉ PODKLADY

Simulace na modelu firmy v prostředí Witness

Projekt: Internetové stránky obce Modletice

PŘÍLOHA C Požadavky na Dokumentaci

Student. Funguje: Přihlášení Výběr školy Výběr role Změna Akademického roku Změna kurzu Odhlášení Přihlášení offline

SYSTÉM PRO DRAŽBU ZNÁMEK

WORKWATCH ON-LINE EVIDENCE PRÁCE A ZAKÁZEK

Moodle uživatelská příručka

Na vod k nastavenı ovy ch schra nek Administrace

Michal Oškera (50854)

DISCORD. Návod k použití pro IVAO-CZ. Zpracoval: Jan Podlipský

REPORTING. Příručka pro Partnery a zákazníky -1-

VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY. MRBT Robotika

Test webového prohlížeče v Amazon Kindle Wi-Fi 3G

Výběrové řízení. Informační systém Autoklubu ČR. Autoklub České republiky. Strana 1 z 8

E-learningovýsystém Moodle

CÍLOVÝ KONCEPT. Ghoul Wars. pro. Jihočeskou univerzitu Pedagogickou fakultu Předmět: TDSA

Formy komunikace s knihovnami

MZDY 7 PROFI - MZDOVÝ A PERSONÁLNÍ SYSTÉM CENÍK

Seznam zkratek PRVNÍ ČÁST. Lidské dovednosti a technické nástroje 1 Úvod k první části 3

Prohlášení o souladu s GDPR 29/2018

Portál podpory. Michal Vokáč Minerva Česká republika, a.s. Service Desk

nástroj pro jednoduchou správu a vedení agendy studentských počítačových sítí na kolejích SU OPF Karviná Ing.

Nová áplikáce etesty Př í přává PC ž ádátele

PhD. Milan Klement, Ph.D. Použití systému studijní agendy STAG

KIV/ZI Základy informatiky

Use Case Model - Complete Report Grouped by Item Kind, Full Descriptions

FAKULTA INFORMAČNÍCH TECHNOLOGIÍ SPOLEČNOST DECADIC PROJEKT FRAMETRIX

Pracovní postup náběhu do produktivního provozu modulu Organizační struktura a systemizace (OSYS)

REDESIGN STATISTICKÉHO INFORMAČNÍHO SYSTÉMU V NÁVAZNOSTI NA ZAVÁDĚNÍ E-GOVERNMENTU V ČR

POZNÁMKY K VYDÁNÍ 3.1. Hilti ON!Track. Datum vydání:

Uživatelský manuál. Obsah

Obsah. Zpracoval:

Modul pro PrestaShop 1.7

Dobrý CMS Popis produktu a jeho rozšíření

Doplňky slovníku SPOT

ZÁSADY OCHRANY OSOBNÍCH ÚDAJŮ

STŘEDNÍ ŠKOLA INFORMAČNÍCH TECHNOLOGIÍ A SOCIÁLNÍ PÉČE

TECHNICKÁ DOKUMENTACE

Analýza a návrh pro Systém Správce

Metodika Portálu pohledávek ve vztahu k uživateli

Návod pro uživatele ISIS

Manažerský informační systém na MPSV. Mgr. Karel Lux, vedoucí oddělení koncepce informatiky MPSV

Vytvoření portálu odboru strukturálních fondů Ministerstva vnitra a zajištění jeho hostingu na serveru dodavatele

CZ.1.04/4.1.00/

Lokality a uživatelé

Implementace informačního systému pro knihovnu Jiřího Mahena v Brně

Migrace dat z aplikace MAXiPokladna

Requirements Model projektová dokumentace

KIV/ZI Základy informatiky. 2. cvičení Univerzitní WebNet. Přednášející: Ing. Jana Krutišová Cvičící: Ing. Michal Nykl

POSUDEK VEDOUCÍHO BAKALÁŘSKÉ PRÁCE

Antonín Přibyl Odborná praxe oborů PS a AI

ESET Anti-Theft: Ochrana pro váš notebook

Projekt: DARUJME.CZ 2.0

Řízení reálných projektů, agilní metodiky

Webový portál pro DODOM Poptávkový dokument

Téma 4: Správa uživatelského přístupu a zabezpečení II. Téma 4: Správa uživatelského přístupu a zabezpečení II

Projekt: DARUJME.CZ 2.0

ZADÁVACÍ DOKUMENTACE Comenis 2.0

INFORMAČNÍ SYSTÉMY PRO KRIZOVÉ ŘÍZENÍ INFORMAČNÍ SYSTÉMY A JEJICH VYUŽITÍ PRO KRIZOVÉ ŘÍZENÍ

Zápis z veřejného zasedání Zastupitelstva obce Loděnice, konaného dne , od 18:00 hodin

Projekt. Kultivace Seznamu zdravotních výkonů a vytvoření nezávislého SW pro jeho další údržbu a modelace

Redakční systém Joomla. Prokop Zelený

Tým C. Vytvoření webové prezentace pro agendu projektu Erasmus na VOŠIS. Perná Lucie. Huminskaya Aliona. Khabirova Maja. Al-Haj-Epraheem Yousra

datum rozhodnutí II. ÚS 2983/2015 JUDr. Jiří Zemánek odmítnuto spisová značka soudce zpravodaj výsledek ČESKÁ REPUBLIKA

Průvodce pro přenos dat

Uživatelská příručka. Vytvořte jedničku mezi stránkami v několika jednoduchých krocích

D8 Plánování projektu

METODIKA PRÁCE S IS AKREDIS

A4B33SI - Softwarové Inženýrství. Vize projektu. Projekt Jumpfish. (verze 1.0) Viktor Kozák, Simona Musilová, Vojtěch Leff, Pavel Vňuk

METODICKÝ POKYN PRO ABSOLVOVÁNÍ ODBORNÝCH PRAXÍ

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

Proč využít SW podporu řízení?

IS pro managment flotily vozidel. Project overview statement

financnasprava.sk Portál Technologie Microsoft zjednodušují komunikaci občanů s Finanční správou SR a činí výběr daní transparentnějším.

Bára Dvořáková, Centre for Modern Education CZ s.r.o. Kontakt:

Manuál PVU zadavatel Platnost pro elektronický nástroj X-EN verze 3 a novější

Transkript:

Plán projektu Jméno projektu: Systém Správce Zahájení projektu: 19. 9. 2011 Plánované ukončení projektu: 12. 12. 2011 Členové: Radim Tobolka, Jan Ševců, Petr Matějů, Lukáš Vydržel, David Staščák, Jozef Matúš Klient: Ondřej Macek, macekond@fel.cvut.cz WBS(Work Breakdown Structure) Naše WBS je poněkud široká, takže zde je rozdělena na jednotlivé podstromy, které mají společný kořen.

Odhad trvání úloh Tyto odhady jsme vytvořili tak, že jsme každý podle našich dosavadních zkušeností navrhli čas, jak dlouho by mohla daná úloha trvat. Člověk s nejvyšším a nejnižším návrhem zdůvodnil, proč navrhl to, co navrhl. Poté se návrh a zdůvodňování opakovalo a nakonec proběhl návrh třetí. Z těchto návrhů byl potom vypočten aritmetický průměr a jeho výsledek byl vzat jako odhad, jak dlouho bude potřeba na vypracování dané úlohy (tzv. časový poker). Všechny údaje jsou uvedeny v hodinách. Založení 5 Dokumentace 50 Uživatelské rozhraní 50 Databáze 5 Registrovaný uživatel 4 Přihlášení/odhlášení 3 Sessions 2 Šablona 9 Změna hesla 2 Založení nového uživatelského účtu 3 Vypsání uživatelů 4 Úprava profilu 4 Obnova hesla 2 Smazání existujícího uživatelského účtu 1 Přidání/smazání týmu 5 Přidání/odebrání člena 6 Prohlížení týmů 19 Pozvánka 7 Schvalování profilů 4 Dokončení 20 Reálný čas strávený na projektu Z výkazu práce vznikl rozpis uvedený níže. Celkový čas strávený na projektu (podle výkazu práce) je 257 hodin. Náš odhad byl však mnohem nižší 156 hodin. Jedním z důvodů takového rozdílu je naše malá zkušenost s takovýmto projektem a proto špatné odhady časů jednotlivých úloh. Dalším důvodem bylo projevení některých rizik, se kterými jsme na začátku projektu nepočítali (podrobněji v bodě Plán rizik). Všechny údaje jsou uvedeny v hodinách. Položky, u kterých je uvedena nula, se buď neimplementovali (protože byly nice to have), nebo bylo těžké přiřadit k nim konkrétní číslo. Založení 2,5 Dokumentace 71 Uživatelské rozhraní 46 Databáze 24 Registrovaný uživatel 5 Přihlášení/odhlášení 4 Sessions 0 Šablona 0 Změna hesla 4 Založení nového uživatelského účtu 4 Vypsání uživatelů 2 Úprava profilu 7 Obnova hesla 2 Smazání existujícího uživatelského účtu 2 Přidání/smazání týmu 5 Přidání/odebrání člena 4 Prohlížení týmů 3 Pozvánka 0 Schvalování profilů 0 Dokončení 10

Vykazování a plánování úkolů Úkoly jsme se snažili plánovat tak, abychom stíhali všechny potřebné dokumenty odevzdávat včas. Plán jejich odevzdávání si určil klient (v našem případě cvičící) na jeho webových stránkách (https://edux.feld.cvut.cz/courses/a4b33si/). Úkoly jsme plánovali a vykazovali pomocí sekce Issues na portále github.com. Jejich celkový přehled je k vidění na adrese https://github.com/frontgroup/project007/issues. Následuje krátká statistika z těchto stránek. Celkem bylo vypsáno 48 úkolů. Na 7 úkolech pracovalo více lidí. Jan Ševců Radim Tobolka Petr Matějů Lukáš Vydržel David Staščák Jozef Matúš 2 úkoly, oba z oblasti dokumentace; potom přestal pro tým pracovat 10 úkolů, polovina dokumentace, polovina implementace 6 úkolů, polovina dokumentace, polovina implementace 4 úkoly, všechny z dokumentace (dělal i implementaci, ale ta nebyla vypsána do úkolů) 9 úkolů, většina dokumentace 10 úkolů, převážná většina implementace Standardně je v roli Approved jen jeden člověk - vedoucí týmu. V naší situaci se odpovědnost za dílo rozkládá na všechny členy a proto je v tabulce role "celý tým."cvičící má u všech úkolů roli Consulted, neboť nám asistuje při vypracování úkolů a Informed, neboť od nás přebírá výsledek práce a hodnotí ho.

Plán rizik Plán rizik je vyjádřen v následující tabulce: V podstatě nás postihlo rizik několik. Nejdříve nás postihlo, že nás jeden člen týmu naprosto opustil. Sice občas komunikoval a proto jsme se mu snažili dávat nějaké, alespoň jednoduché, úkoly. Vždy to ale dopadlo tak, že úkol nevypracoval a ten tak zůstal na nás zbývající. To samozřejmě ovlivnilo čas a asi i kvalitu. Dále to byl špatný odhad. Jelikož ještě nemáme tolik zkušení zejména s takto rozsáhlým projektem, při odhadování trvání jednotlivých úloh jsme skutečnou délku podceňovali a tak se skutečný a odhadovaný čas stále vzdalovaly. Dalším rizikem, se kterým jsme se museli vypořádat byla špatná komunikace a koordinace. Kvůli tomu jsme se zpozdili o další kus a skutečný čas se ještě více oddálil od toho odhadovaného. A nakonec nás samozřejmě potkalo riziko spojené s písemkami. Jednalo se hlavně o zápočtovou písemku z PSI, kterou někdo musel psát dokonce dvakrát. Mimo to sem patří i dvě zápočtové písemky z JAG. Nicméně toto riziko nemělo na projekt takový dopad, jako ta dvě předešlá.

Finanční plán Takto byl rozpočet stanoven na začátku projektu: Od té doby nebyl upravován a myslíme si, že ani moc upravit nepotřebuje. Doby jednotlivých částí projektu se sice změnily (testování bylo kratší, ale programování delší), ale součet všech časů je přibližně stejný. A protože jsou všechny doby násobeny stejnou částkou. Výsledná cena se prakticky nezměnila, takže můžeme říct, že původní rozpočet jsme dodrželi. Protože náš rozpočet vycházel ze síťového diagramu a z něj jsme nesplnili všechny položky, lze říci, že jsme podcenili časovou náročnost projektu a za stejné peníze a čas jsme dodali méně funkčnosti.