Requirements Model projektová dokumentace

Transkript

1 Requirements Model projektová dokumentace Plán práce Po vyhodnocení požadavků na systém a krátkým seznámením se s Netbeans platform jsme projekt rozdělili na aktivity a úkoly a sestavili work breakdown structure, kde jsem odhadli počet hodin potřebný pro jednotlivé úkoly. Plán práce je zachycen v Ganntově diagramu. Také jsme udělali kritickou cestu. Iterace I V této iteraci jsme se domluvili na nástrojích, které budeme používat na komunikaci. Založili jsme Google Code a Google Groups. Začali jsme s analýzou našeho projektu, vytvořili jsme POS. Jan Donatek založení infrastruktury Organizace týmu 1 Jan Donatek POS Analýza 0,5 Jan Donatek Získání požadavků Analýza 1 Jan Donatek Tomáš Šorejs Zápis požadavků + prototyp UI Harmonogram projektu Dokumentace 1,5 Dokumentace 1 Ota Chasák BWS, Scénáře Dokumentace 2 Ota Chasák Netbeans tutorialy Studium 2 Iterace II Protože v Ganttově modelu byly zahrnuty pouze úkoly týkající se implementace, tak jsme pokračovali podle požadavků na stránce předmětu. Začali jsme s prvním prototypem na Netbeans platform. Jaroslav Málek raci Dokumentace 0,5 Jan Donatek Kritická cesta Analýza 1 Jan Donatek Prezentace na třetí iteraci Prezentace na hodinu 0,5 Jan Donatek Rozdělení bodů, Celkový počet hodin Organizace týmu 1 Jan Donatek Rozpočet Analýza 1 Ota Chasák GUI pro modeler Implementace 3

2 Iterace III Začala implementace persistentní vrstva a její napojení na prototyp. Tomáš Vik Základní DAO Implementace 6 Tomáš Vik Studium JPA Studium 3 Jaroslav Málek integrace persistence Implementace 5 Jaroslav Málek create, update Implementace 3 Iterace IV Zde jsme začali nabírat zpoždění oproti plánu. Podle plánu v Ganttově modelu jsme měli udělat CRUD operace a export požadavků. Jaroslav Málek Přehled projektu Implementace 3,5 Jaroslav Málek Gui pro praci s kategoriemi Implementace 4 Iterace V V této iteraci se měla připravit persistentní vrstva na mergování požadavků. To se událo až v v šesté iteraci. Jan Donatek Opravení bugů 15,16 Implementace 2 Jan Donatek Tomáš Vik Iterace VI založení issues, oprava požadavků a krit. cesty Kategorie v DAO, oprava chyb Dokumentace 2 Implementace 3 V této iteraci jsme podle plánu udělali mergování požadavků. Kvůli tomu se musela dodělat persistentní vrstva, které měla být hotová v předchozí iteraci. Tomáš Vik Merge Implementace 5 Ota Chasák Merge Implementace 5 Ota Chasák Merge Implementace 2 Tomáš Šorejs oprava harmonogramu Dokumentace 1 Jaroslav Málek Upravy v kategoriich/bugfixing Implementace 1 Ota Chasák unmerge, opravy Implementace 2 Tomáš Šorejs Export Implementace 4 Tomáš Vik Dokončení DAO (merged Requirement) Implementace 2

3 Tomáš Šorejs Export Implementace 2 Petr Vejvoda Export Implementace 6 Petr Vejvoda RACI Implementace 1 Jan Donatek Závěrečná prezentace Prezentace na hodinu 3 Zhodnocení Při plánování projektu jsme dostatečně nebrali v potaz naše ostatní povinnosti ve škole a tak jsme se v druhé půlce projektu nabrali zpoždění. Určitě jsme měli začít implementovat persistentní vrstvu o iteraci dříve souběžně s prvním pratypem pro Netbeans platform, tím by nám zbylo více času na později. Hlavně bychom potřebovali více času na dokončení a zkompletování dokumentace.

4 act WBS Requirements plugin 98 hodin Implementace Analýza Náv rh 60hod Administrativa Požadav ky 2 hod Scénáře 2 hod 25hod Class diagram 1 hod Persistentní v rstv a Interface Export GUI Persistentní v rstv a 15hod Interface 20hodin Export 5hod Testování 5hod GUI 15hod Rozdělení bodů 1hod 13 hod Tvorba prezentací 7 hod Tv orba dokumentace 5 hod Study - NetBeans API 20hod Tabulka JGraph Tabulka JGraph Obr. 1 Work Breakdown Structure

5 Obr. 2 Ganttův model harmonogram projektu

6 act Critical Path 6 6 Základní GUI (1) Persistentní vrstva (čtení dat) (1) Legend > To co není zásadní pro funkčnost > Kritická cesta Hotovo 0-0 Rozšíření uzlu 7 7 Rozpočet man/week = 8 hodin 9 Read (1) Create (2) Update (2) Delete (2) Na kritickou cestu je třeba ( 13-6 = 7 ) man/weeků. Tj. ( 7 * 8 = 56 ) hodin Nastavení defaultních hodnot (2) Na všechny úlohy ( kritická cesta + 2 * 8 (export) + 2 * 8 (default hodnoty) = = 88 ) Vyhledávání požadav ků (1) Přehled projektu Export do RTF (2) Persistentní vrsva pro merge (1) Odstraněno z projektu Mergování a rozdělování požadavků (2) Seskupování požadavků (2) 13 Odevzdání projektu Obr. 3 Kritická cesta

7 Vik Tomáš Donátek Jan Vejvoda Petr Šorejs Tomáš Málek Jaroslav Chasák Ota Úkol \ Osoba Legenda R - Analýza Responsible A - Požadavky I AR I I R I Accountable Scénáře R R AR C - Counselted I - (kept) Study - NB API I R I R R Informed Návrh Perzistentní vrstva R I I I CA C Interface I I I I R AR Export C A R R Implementace Persistence I R CA I I I Interface R I I I CA I Export I I R R Testování R R R R R R Administrativa Rozdělení bodů C R C C C C Tvorba prezentací C AR C C C R Tvorba dokumentace C C R C C C Obr. 4 RACI matice

8 Rozpočet Rozpočet dle Počet hodin Splněno na (%) Odhadovaná cena(kč) Skutečná cena(kč) WBS Kritické cesty Síťový model Cena člena týmu Man/Hour (Kč) 300 Man/Week (hodina) 6 Obr. 5 Rozpočet Na začátku projektu jsme u jednotlivých úkolů odhadli jejich délku a na základě těchto hodnot jsme vypočítali rozpočet. Body jsme rozdělili podle počtu odpracovaných hodin. Analýza Scénáře Vytvořit projekt Obr. 6 Přerozdělení bodů Scénář začíná když uživatel zvolí funkci "Add project" 1. Systém zobrazí pole pro název projektu 2. Uživatel pole vyplní a stiskne save 3. Systém uloží projekt a zobrazí ho v přehledu Přidat kategorii Scénář začíná když uživatel vybere projekt zvolí funkci "Add category" 1. Systém vyzve uživatele k zadání názvu kategorie 2. Uživatel vyplní název a stiskne save 3. Systém uloží kategorii

9 Smazat projekt Scénář začíná když uživatel vybere projekt zvolí funkci "Delete" 1. Systém smaže projekt a požadavky v něm obsažené Vytvořit požadavek Scénář začíná když uživatel zvolí funkci "Add requirement" 1. Systém vyzve uživatele k zadáni hodnot kriterii [autor, název, popis, priorita, kategorie] 2. Systém vytvoří nový požadavek Odebrat požadavek Scénář začíná když uživatel zvolí funkci "Odebrat požadavek" 1. Uživatel vybere požadavek ke smazání 2. Systém se ujistí o správném výběru 3. Uživatel potvrdí výběr 4. Systém smaže požadavek Upravit požadavek Scénář začíná, když uživatel zvolí funkci editovat 1. Systém zobrazí daný požadavek 2. Uživatel změní požadované hodnoty a zvolí funkci uložit 3. Systém požadavek uloží Zobrazit požadavek Scénář začíná, když uživatel otevře požadavek 1. Systém zobrazí podrobnosti o daném požadavku Sloučit požadavky Scénář začíná, když uživatel označí více požadavků a vybere funkci Merge 1. Systém vytvoří společný požadavek 2. Uživatel vyplní hodnoty [autor, název, popis, priorita, kategorie] Rozdělit požadavky Scénář začíná, když uživatel označí jeden nebo více požadavků a vybere funkci Merge 1. Systém zobrazí vybrané požadavky mezi ostatními 2. Pokud ve sloučeném požadavku žádný nezůstal, systém sloučený požadavek smaže Exportovat požadavek Scénář začíná, když uživatel vybere funkci Export

10 1. Systém zobrazí výběr mezi txt a xml souborem a umístěním souboru 2. Uživatel vybere a pojmenuje soubor 3. Systém provede export dfd Context diagram Requierments-Model-Plugin Požadavky Use-Case-Plugin Správa požadavků Přehled - export do MS Word Vývojářský tým Obr. 7 Kontextový model

11 custom User Interface Náv rh grafické v erze Menu Požadav ek Požadav ek2 ID: Název: Popis text id text název text popis Požadav ek3 Priorita Autor Kategorie text priorita text autor text kategorie Obr. 8 Návrh grafického uživatelského rozhraní Datový model Analýza datového modelu probíhala na základě požadavků a vlastností použitého perzistentního frameworku (EclipseLink 2.0). Rozhodli jsme se pro použití anotovaných POJO (Plain Old Java Ojbect) jako entit. Rozhodli jsme se že pro Merged Requirement (spojený požadavek) využijeme dědičnosti, protože měl skoro všechny atributy společné s obyčejným požadavkem. Návrh Při návrhu aplikace jsme vycházeli z architektury Netbeans platform, kde jsou aplikace rozděleny do modulů. Naše aplikace se skládá z pěti modulů EditorModule, ExplorerModul, ExportModul, ProjectModul a RequirementLib, které jsou mezi sebou provázané. EditorModule tvoří grafické rozhraní pro editování jednotlivých požadavků

12 ExplorerModule zajišťuje stromové zobrazení jednotlivých projektů a požadavků v levé části aplikace ExportModule slouží pro exportování projektů do souborů xml nebo txt ProjectModule slouží pro zobrazení projektu v tabulkové formě Module RequirementLib obsahuje jar soubor pro práci s databází Jeden z požadavků projektu bylo vytvoření interfacu pro komunikaci s projektem Use-case Plugin. Po seznámení se s Netbeans platform jsme se rozhodli neřešit případnou komunikaci řešit pomocí interfacu, ale vytvořením samostatného modulu v Use-case Pluginu, který bude obsahovat stejné knihovny jako RequirementLib modul. Testy Vytvořili jsme několik Unit testů na perzistentní vrstvu. Testy nejsou zcela korektní, protože až po jejich vytvoření jsme se dočetli, že testy na sobě nesmí být závisle (a to ani, když jsou v jedné třídě). Od té chvíle už jsme dělali Unit testy správně, ale staré jsme nepředělávali, protože jejich výpovědní hodnota byla stále velmi dobrá. Bohužel jsme nestihli udělat systematicky scenario testy. Každý programátor si testoval funkčnost vlastního kódu sám. Pokud by šlo o skutečný projekt, bylo by třeba naplánovat akceptační testy. Takto proběhl malý akceptační test při závěrečné prezentaci, když jsme panu vyučujícímu předvedli funkčnost naší aplikace. Samozřejmě jsme tuto funkčnost nemohli předvést v plném rozsahu. Infrastruktura Náš tým používal Google Code, kde je k dispozici wiki, repozitář (umožňuje volbu mezi subversion a Mercurial) a issue tracking. Pro komunikaci v rámci týmu jsem používali Google Groups. V předmětu X36SIN jsme pro komunikaci používali Google Wave, což se při větším počtu témat ukázalo jako velmi nepřehledné. Infrastrukturu používanou letos hodnotím jako lepší, protože jednotlivé příspěvky na Google Groups lze posílat a odpovídat na ně pomocí u. Také správa wiki a repozitáře na Google Code je přehlednější v záložce updates jsou vidět změny a vše je pohromadě, což Wave neumožňoval. Soubory jsou v záložce downloads, na Wavu byly v jednotlivých tématech diskuze, což bylo později obtížnější pro hledání. Tutoriál Projekt Requirements model je implementován na Netbeans platform, pro ukládání dat používá databázi Java DB. Pro všechny členy týmu byla Netbeans platform nová technologie, takže jsme nějaký čas museli strávit učením. Jako nejlepší zdroje pro tuto platformu bych doporučil videa a tutoriály z webu Samotná dokumentace se neukázala jako moc přínosná. Asi v polovině semestru nastal problém s příchodem nové verze Netbeans, kdy jeden ze členů týmu programoval v nové verzi a nastaly konflikty v konfiguračních souborech. V příštích týmových projektech si musíme dát pozor a dopředu ujednotit jednotlivé verze vývojových nástrojů.

13 Pro práci s databází jsme použili framework JPA, který pro některé z nás byl nový, někteří ho již znali. Instalační pokyny Instalační soubor pro Windows lze stáhnout na: Pro aplikaci je nutné mít nainstalovanou databázi Java DB ( a vytvořit databázi s názvem requirement, uživatelským jménem requirement, heslo: heslo123a. Zhodnocení projektu Pro celý tým byl tento projekt premiéra, co se týče řízení softwarových projektů. Přestože tým o velikosti šesti lidí patří do malých skupin, tak se řízení ukázalo jako téměř nemožné bez použití infrastruktury. Na začátku projektu se neujalo reportování počtu odpracovaných hodin přímo do tabulky na stránkách týmu, tím jsme úplně ztratili přehled o práci. Později jsme zavedli jiný způsob reportování, který se ujal. Samostatnou kapitolu tvoří přesnost našich odhadů při plánování. Přestože každý z nás dělal podobné projekty sám v rámci semestrálních prací, tak jsme podcenili čas nutný pro tvorbu dokumentace, ostatní administrativy a testů. Tyto odhady lze zpřesnit jedině zkušeností s podobnými projekty. V příštích týmových projektech bychom se měli vyvarovat podobných chyb jaké se nám staly s vykazováním práce a také bychom měli naplánovanou práci ihned dodělat, protože před odevzdáním jsme zjistili, že některé věci nebyly dodělány a nikde to nebylo zaznamenané.