České Vysoké učení technické v Praze Fakulta

 České Vysoké učení technické v Praze Fakulta elektrotechnická Projektová vize webové aplikace UnderTracker 1 Název projektu UnderTracker Zkratka projektu UT Email projektu [email protected] Odkaz na stránky projektu https://www.assembla.com/spaces/undertracker Seznam řešitelů projektu Anastasia Kuznetsova Nikita Silin Jan Kotouč Jaroslav Smutek Peter Schmiedt Termín cvičení (semestr, den, hodina) Paralelka 103, ZS 2014/2015, Pondeli, 16:15 Jméno cvičícího Martin Komárek Tomas Černý Datum odevzdání 10.10.2014 Tabulka verzí dokumentu Verze Datům Obnovení 1.0 1.10.2014 1.1 4.10.2014 1.2 9.10.2014 2 Obsah 1 Seznámení s problematikou 1.1 Cil projektu
1.2 Současná řešení a jejich nevýhody
4 4 2 Zainteresované osoby a instituce
2.1 Zadavatelé
2.2 Dodavatelé
2.3 Uživatelé
2.4 Ostatní zainteresované osoby
6 6 6 7 3 Požadavky na funkcionalitu 3.1 Správa uživatelů
3.2 Správa projektu
7 7 7 7 7 7 8 8 3.2.1 Správa Kategorií
3.2.2 Správa Týmu
3.2.3 Správa Události
3.2.4 Správa Issues
3.2.5 Správa Wiki­Stránek
3.3 Privátní zprávy
4 Nefunkční (ostatní) požadavky 4.1 Technologické požadavky
4.2 Potencionální rozšíření
8 8 5 Časový harmonogram
6 Finanční náklady 8 6.1 Mzdové náklady
6.2 Náklady na software
6.3 Náklady na cloudový server
6.4 Celkové náklady na aplikaci
6.5 Rozdělení nákladů do jednotlivých iterací
9 9 10 10 10 7 Matice odpovědnosti RACI
11 3 1 Seznámení s problematikou Issue Tracker System ( dále ITS) je softwarová aplikace, která slouží ke správě a sledování životního cyklu události ( dále issues ) v rámci nějakého projektu. ITS často bývají jednou ze součástí rozsáhlého systému pro řízení vývoje softwaru v celé organizaci. Obvykle se taková řešení používají ve větších firmách, kde systém používají nejenom programátoři ale i designéři, manažeři a tak dále. Daná komplexní řešení jsou východiskem pro velké společnosti, ale pro menší firmy mohou být zbytečně složité a drahé. 1.1 Cíl projektu Naším cílem je vytvořit flexibilní webovou aplikaci jednoduchou na ovládání, kterou lze použit jak pro evidenci chyb v softwaru (tzv. bug ­ tracker) tak i jako helpdesk s možností zadání chybových hlášení, program dále mohou využívat jakékoliv firmy zabývající se vývojem (nejen softwaru). Hlavním přínosem pro menší společnosti při použití našeho ITS UnderTracker bude zlepšení organizace práce, díky možnosti přidávat události jako jsou např. setkání, snadnější evidenci odvedené práce a času stráveném na daných úkolech a hlavně rychlému nasazení ve firmě díky webovému volně přístupnému rozhraní. 1.2 Současná řešení a jejich nevýhody Bugzilla (http://www.bugzilla.org/) Jedná se o open source software původně vyvinutý a používaný Mozillou pro evidenci softwarových chyb. Nástroj lze integrovat s dalšími nástroji (například s SVN). Jednou z nevýhod je složité nastavení uživatelských práv a komplikované uživatelské rozhraní (dále UI). Nástroj je určen převážně pro interní využití. Assembla (http://www.assembla.com/) Assembla je kompletním Project Management Systemem, s rozsáhlým výčtem nástrojů. Jedním s nástrojů je Ticket System. Assembla je vhodná pro velké projekty a velké firmy. Pro male a střední firmy muže být drahá, a obsahovat spoustu zbytečných věci. Trac (http://trac.edgewall.org/) Trac je open source projekt. Jednou z jeho výhod je výborná integrace s SVN. Trac představuje dostačující řešení pro menší projekty a týmy. Web­interface je založen na technologii Wiki. Nevýhodou je složitější instalace a nutnost serveru s MySQL. 4 Jira (https://www.atlassian.com/software/jira) Nejpoužívanější software pro správu projektu vyvíjený společností Atlassian. Jedná se o komerční produkt s jednorázovým poplaktkem za licenci na jeden server. Atlassian však zdarma poskytuje licenci pro OpenSource projekty. Je to velmi flexibilní nástroj poskytující bohatou možnost konfigurace a přizpůsobení systému celkově. Github Issue Tracker (https://github.com/) Výhody Github issue trackeru jsou stejné jako u Trac má výbornou integraci se SVN/GIT a velkou rozšířenost. K jeho nevýhodám patří, že nelze nahrávat soubory do issue a také jeho silná orientace na vývoj softwaru. Porovnávání issue trackerů: Funkce Bugzilla Assembla Trac Github Jira Nezávislý ITS Ano Ne Ano Ne Ne Rozdělení podle kategorii Ano Ano Ano Ano Ano Time Tracking Ano Ano Ano Ano Ano Privátní zprávy (PM) Ne Ne Ne Ne Ano Minimalistický Design Ne Ne Ne Ne Ne Přistup k ITS zdarma Ano Ne Ano Ano Ano Nepotřebuje server Ne Ano Ne Ano Ano Uživatelské typy pro Issues Ne Ne Ne Ne Ano K Issues lze přiložit přílohu Ano Ano Ano Ne Ano 5 2 Zainteresované osoby 2.1 Zadavatelé Projekt UnderTracker (UT) je vypracován v rámci předmětu Úvod do softwarového inženýrství (dále USI) na FEL ČVUT. Zadavatelem a zároveň i konzultantem projektu je Ing. Martin Komárek. Technickým vedoucím projektu je Ing. Tomáš Černý, MSc. .
2.2 Dodavatelé Dodavateli jsou studenti předmětu USI vyjmenované dále: Anastasia Kuznetsova, Nikita Silin, Jan Kotouč, Jaroslav Smutek, Peter Schmiedt. 2.3 Uživatelé Uživatelé jsou jednotliví lidé nebo malé a střední firmy, které vyžadují univerzální systém pro správu a usnadnění procesu řízení projektů. Vzhledem k tomu, že systém umožňuje rozdělení issue na kategorie, je vhodný jak pro lidi s malými projekty, tak i pro malé a střední firmy s vyššími požadavky. Seznam typu uživatelů: ● Super­Admin ( technicky správce systému ) ● Project creator ● Project moderator ● Project member ● Ticket creator ● Ticket assignee ( práva učastníků projektu vzhledem k Issue) 2.4 Ostatní zainteresované osoby Seznam osob které mohou ovlivnit projekt během vývoje nebo provozu. Hackeři Pro každou společnost zabezpečení dat je jednou z nejdůležitějších věcí. V náší aplikaci data předávána mezi serverem a klientem budou zabezpečena pomoci standartních protokolu ASP.NET. Sponzoři V případě velkého zajmu a zajištění finanční podpory ze strany sponzorů projekt muže být vyvinut dál. Možná rozšíření jsou popsána v bodě 4.2 . 6 3 Požadavky na funkcionalitu 3.1 Správa uživatelů Správa uživatelů řeší registraci uživatele do systému, přidání uživatele do týmu a projektů. 3.2 Správa projektů Každý uživatel může vytvořit jeden až několik projektů, spravovat je, přidávat nové členy do týmů, vytvářet nové události atd.. 3.2.1 Správa Kategorií Systém podporuje tvorbu kategorií. Kategorie může mít Jméno, popis a seznam ticketů, které ji patří. 3.2.2 Správa Týmu Ve správě týmu je možné přidávat uživatele jako členy týmu a udělovat jim v týmu role. Uživatel může mít několik rolí na základě různých projektu/issue. Seznam roli viz. 2.2.1 3.2.3 Správa Událostí Moderátor projektu může vytvořit poznámku k události, která obsahuj název, popis a čas události. 3.2.4 Správa Issues Moderátor projektu může vytvořit “Issue ticket”, který je definován několika vlastnostmi: ● Hlavička ● Popis ● Priorita ● Typ ● Zainteresované osoby (assignee) ● Deadline (Termín do) ● Time Spent (Celkový čas na daném ticketu) Uživatel, který je přihlášen do projektu a uveden jako zainteresovaná osoba v Issue, může zapsat odpracované hodiny na daném ticketu a tím navýšit celkový “Time Spent”. Ostatní vlastnosti může měnit pouze “Ticket Creator” a “Project moderator”. 7 3.2.5 Správa Wiki­Stránek Moderátor projektu může spravovat Wiki­stránky projektu: přidávat nové stránky, opravovat je a tak dále. 3.3 Privátní zprávy Každý uživatel má možnost poslat interní privátní zprávu ( dále PM ) jednomu až několika uživatelům najednou. Příjemcem může být jakýkoliv uživatel webové aplikace UT. Interní PM se odesílají pouze do osobní schránky v aplikaci UT a nejsou provázaný s poštovnými schránkami jiných dodavatelů. 4 Nefunkční (ostatní) požadavky 4.1 Technologické požadavky Klient: PC s možností připojení na internet a webovým prohlížečem bez ohledu na platformě. Server: Minimální požadavky: Server s 1GHz procesorem, 1GB RAM. Požadovaná platforma Windows server s ASP.NET backend.Dostatečná disková kapacita pro relační databázi používanou programem. Doporučené požadavky: Server s 2GHz procesorem, 2GB+ RAM. Požadovaná platforma Windows server s ASP.NET backend. Dostatečná disková kapacita pro relační databázi používanou programem. Verze systémů: C# 3.0 a vyšší platforma .NET 4.0 a vyšší 4.2 Potencionální rozšíření ● Možnost integrace s SVN ● Rozšíření do plného systému pro správu projektu ● Vizualizace statistik 5 Časový harmonogram Terminy odevzdání jednotlivých částí projektu: 1. Iterace ­ 3. týden Vize projektu, seznam požadavku. 8 2. Iterace ­ 5. týden ­ prvotní analýza K vizi projektu přidána byznys analýza, katalog funkčních a obecných požadavků, model možných užití 3. Iterace ­ 8. týden ­ detailní analýza funkčních a obecných požadavků 4. Iterace ­ 10. týden Plán testování možných užití, model architektůry, komunikace a nasazení, výkaz práce jednotlivých členů, zpráva o implementaci. 5. Iterace ­ 12. týden ­ Finální verze 6 Finanční náklady 6.1 Mzdové náklady Předpokládané mzdové náklady jsou počítané při časové náročnosti projektu 120 hodin na člověka, tj. celkem 600 Man­hour. Výpočet mzdových nákladů počítá se zaměstnáním pracovníků formou Dohody o provedení práce. Zaměstnavatel odvádí za zaměstnance veškeré povinné odvody dle platné legislativy (sociální a zdravotní pojištění). Pracovník Hrubá Předpokladaný Celková Další mzdové hodinová celkový počet hrubá náklady mzda v Kč hodin mzda v Kč (sociální a zdravotní pojištění) Celkové mzdové náklady na pracovníka Kuznetsova 192 120 23 000 7 820 30 820 Smutek 192 120 23 000 7 820 30 820 Kotouč 192 120 23 000 7 820 30 820 Silin 192 120 23 000 7 820 30 820 Schmiedt 192 120 23 000 7 820 30 820 Celkem 154 100 Tyto náklady obsahují personální náklady pouze na vývoj samotné aplikace. Následný servis by měl být řešen v rámci dalšího projektu či SLA smlouvy. 6.2 Náklady na software Pro vývoj je potřeba zakoupení 2 licencí Microsoft Visual Studio 2013 v ceně 16 433 včetně DPH. Celkové náklady na software budou tvořit částku 32 866 Kč včetně DPH 9 6.3 Náklady na cloudový server Cena cloudového serveru, který vyhovuje požadavkům aplikace, se pohybuje v oblasti 2000 Kč/měsíc. Budeme­li počítat s prvním rokem provozu, náklady na tento server se budou pohybovat v řádu 24 000 Kč. 6.4 Celkové náklady na aplikaci Na základě předchozích bodů bude celková cena aplikace tvořena z následujících složek: Druh nákladů Náklady na položku v Kč Personální náklady 154 100 Náklady na software 32 866 Náklady na cloudový server 24 000 Ostatní náklady 5 000 Celkové náklady 215 966 Odhadovaná cena aplikace je tedy 215 966 Kč. Vzhledem k tomu že je vyvíjen v rámci předmětu USI, bude systém veden jako freeware. 6.5 Rozdělení nákladů do jednotlivých iterací Z hlediska rozdělení finanční náročnosti do jednotlivých iterací předpokládáme členění dle následující tabulky. Iterace Finanční náročnost v Kč % z celku 1.
iterace 10 799 5 2.
iterace 32 395 15 3.
iterace 75 588 35 4.
iterace 75 588 35 5.
iterace 21 596 10 10 7 Matice odpovědností RACI Iterace 1. 2. Část Silin Nikita Kuznetsova Jaroslav Jan Anastasia Smutek Kotouč Peter Schmiedt Vize C R A C I Oponentura C A C C R Vize C R A C I C A I R I Byznys analýza
Katalog funkčních a obecných požadavků C A R I C Model případu užití C A I C R I R C A I R I R C A A R I C C C A R R I R A C C C R A C C C C I I A R C A I R R C I A R I R A I C I 3. 4. 5. Analytický doménový
model
Robustní architektonický
základ
Model architektury
Model komunikace
Model nasazení
Zpráva o implemetaci
Plán testování případu
užití
Uživatelský manuál
Zpráva o testování
DVD k projektu
Vysvětlivky a zkratky: Responsible – kdo fakticky vypracuje? Accountable – kdo zodpovídá za vypracování? Consulted – s kým nutno konzultovat? Informed – koho nutno informovat o výsledku 11 9 December, 2014
UnderTracker
Analytic Domain Model
Analytic Domain Model diagram
Figure 1:
Analytic Domain Model
Page 1 of 34
9 December, 2014
Business Domain Model
Business Domain Model diagram
Business Domain Model popisuje strukturu systému. Zobrazuje entity, které jsou z pohledu systému důležité.
Figure 2:
Business Domain Model
Priority
Popisuje typy priorit, které lze přiřadit Issue Ticketu
Status
Popisuje stav Issue Ticketu
Page 2 of 34
9 December, 2014
Business Process Model
Business Process Model diagram
Business Proces Model (BPM) - model podnikových neboli obchodních procesů. Dany model realizuje "TO BE" pohled
Figure 3:
Business Process Model
Add User to Project
Add User to Project diagram
Dany diagram popisuje proces přidaní nového člena do projektu.
Figure 4:
Add User to Project
Page 3 of 34
9 December, 2014
Create Project
Create Project diagram
Diagram popisuje proces vytvořeni nového projektu.
Figure 5:
Create Project
Page 4 of 34
9 December, 2014
Problem Capturing
Problem Capturing diagram
Diagram popisuje proces zachyceni problému. Project Member teprve zkusí najít daný problém mezi již existujícími
Issue, pokud ho nenajde založí novy Issue.
Figure 6:
Problem Capturing
Page 5 of 34
9 December, 2014
Solution Process
Solution Process diagram
Diagram popisuje proces řešeni problému. Project Manager(PManager) nebo Issue Creator(ICreator) průběžně
kontroluje, zda problém byl vyřešen, pokud problém nebyl vyřešen do deadlinu nebo přestal byt relevantním PManager
nebo ICreator mají právo bud’ přiřadit ho jiné osobě nebo zavřít.
Figure 7:
Solution Process
Page 6 of 34
9 December, 2014
Component Model
Component Model diagram
Figure 8:
Component Model
Page 7 of 34
9 December, 2014
Basic Components Map
Basic Components Map diagram
Figure 9:
Basic Components Map
Page 8 of 34
9 December, 2014
Deployment Diagram
Deployment Diagram diagram
Figure 10:
Deployment Diagram
Page 9 of 34
9 December, 2014
Requirements
Requirements diagram
Požadavky jsou rozdělené do dvou skupin: Funkční požadavky a Obecné požadavky.
Figure 11:
Requirements
Functional Requirements
Functional Requirements diagram
Seznam funkčních požadavků
Figure 12:
Functional Requirements
Page 10 of 34
9 December, 2014
Conversation Management
Conversation Management diagram
Systém bude umožňovat uživateli poslat interní privátní zprávu jednomu až několika uživatelům najednou.
Figure 13:
Conversation Management
R03.1: Conversation
Systém will allow to organize conversation between group of users
R03.2: Messages
Systém will allow to add messages to the conversation if user is a member of this conversation
Page 11 of 34
9 December, 2014
Issue Management
Issue Management diagram
Systém bude umožňovat uživateli s roli “Moderátor projektu” vytvořit “Issue ticket”
Figure 14:
Issue Management
R02.1: Issue creation
Systém will allow team members to create Issues
R02.2: Issue Settings
Systém will allow Issue Creator and Project Moderator to specify certain data about the issue:
 Title
 Description
 Priority
 Type
 Category
 Deadline
R02.3: Issue Status
Systém will allow Project Moderator and Issue Creator to
change the status of the Issue to one of the following
items:
 Opened
 In Progress
 Closed
 Invalid
R02.4: Time investment
Systém will allow to specify time invested into the specific issue.
Page 12 of 34
9 December, 2014
R02.5: Total time invested
Systém will provide information about total time invested into the issue by all the users
R02.6: Issue Assignee
Systém will allow Issue Creator and Project Moderator to set assignee for the issue, which has to be another
member of the project.
Page 13 of 34
9 December, 2014
Project Management
Project Management diagram
Systém bude umožňovat uživateli vytvořit jeden až několik projektů, spravovat je, přidávat nové
členy do týmů, vytvářet nové události
Figure 15:
Project Management
R01.1.1: Invite project members
Systém will allow Project Creator to invite any registered user into the project.
R01.1.2: Remove project members
Systém will allow Project Creator to remove any team member from the project.
R01.1.3: Member roles
Systém will allow project creators and project moderators to set roles for other members of the project.
R01.1: Team Management
Systém will allow user to manage the existing project
R01.2: Project categories
Systém will allow to create and remove categories with a unique name in the context of a project.
R01.3: Project events
Systém will allow to create/remove events in the context of the project
R01.4: Project creation
Systém will allow to create a new project with a unique name.
Page 14 of 34
9 December, 2014
User Management
User Management diagram
Figure 16:
User Management
R00.1: Logging in
Systém will allow to log in into the system using registered username and password
R00.2: Creating new account
Systém will allow to register new account when user is not logged in
R00.3: Logging out
Systém will allow to log out when user is logged in
R00.4: Users administration
Systém will provide CRUD interface for system administrator to manage users
Page 15 of 34
9 December, 2014
Wiki-Pages Management
Wiki-Pages Management diagram
Systém bude umožňovat uživateli s roli “Moderator projektu” spravovat Wiki-stranky projektu: přidávat nové stránky,
opravovat je.
Figure 17:
Wiki-Pages Management
R04.1: Wiki administration
Systém will allow to create/remove wiki-pages in the context of project
R04.2: Wiki content management
Systém will allow to change content of wiki-pages
R04: Wiki-Pages Management
Systém will allow maintaining wiki-pages in the context of a project.
Page 16 of 34
9 December, 2014
Non-Functional Requiremenents
Non-Functional Requiremenents diagram
Figure 18:
Non-Functional Requiremenents
Q00: Web-Interface
Systém will have a public Web-Interface
Q01: DotNet Framework 4.0
Systém will be based on .Net Framework 4.0
Q02: C# 3.0
Systém will be created in C# 3.0
Q03: Cloud Server
Systém will run on a cloud server.
Page 17 of 34
9 December, 2014
Use-Case Model
Use-Case Model diagram
Figure 19:
Use-Case Model
Page 18 of 34
9 December, 2014
Actors
Actors diagram
Figure 20:
Page 19 of 34
Actors
9 December, 2014
Conversation Management
Conversation Management diagram
Figure 21:
Conversation Management
Requirements Mapping diagram
Figure 22:
Requirements Mapping
Page 20 of 34
9 December, 2014
Add message
Popis:
Člen může přidat zprávu do konverzace.
Požadavek: existuje alespoň jedna konverzace.
ID_19: Vytvoření zprávy
Základní průběh:
1. Uživatel chce přidat novou zprávu do konverzace
2. Uživatel vybere konverzaci
3. System zobrazí formulář pro přidaní nové zprávy
4. Uživatel vyplní formulář
5. IF uživatel nevyplnil povinna pole
THEN system vrátí uživateli předvyplněni formulář
6. Systém uloží zprávu a pošle ji příjemci
Create conversation
Popis:
Uživatel vytvoří konverzaci s jedním i několika uživateli najednou.
Požadavek:
Uživatel musí být členem projektu, uživatele kterým chce poslat zprávu jsou účastníci projektu.
ID_20: Vytvoření konverzaci
Základní průběh:
1. UC začíná, když uživatel chce založit novou konverzaci s jedním a nebo několika členy týmu
2. System vytvoří novou konverzaci
3. INCLUDE(Add message)
4. System uloží zprávu přidanou do konverzace
Delete message
Popis:
Use Case popisuje tok události při odstraněni zprávy
Požadavek: existuje alespoň jedna zpráva.
ID_21: Odstranění zprávy
Základní průběh:
1. Uživatel chce odstranit zprávu
2. System zobrazí existující zprávy
3. Uživatel vybere zprávu, kterou chce odstranit
4. System odstraní vazbu mezi uživatelem a zprávou
Alternativní průběh (Odstranění zprávy, kdy je zobrazen obsah zprávy) :
1. System zobrazí zprávu
2. Uživatel požádá system o odstraněni zprávy
3. System odstraní vazbu mezi uživatelem a zprávou
Page 21 of 34
9 December, 2014
Read message
Popis:
Use Case popisuje tok události při čtení zprávy
Požadavek:
Mail-box uživatele je viditelný
ID_22: Přečtení zprávy
Základní průběh:
1. Uživatel chce přečíst zprávu.
2. System zobrazí zprávy uživatele
3. Uživatel vybere zprávu.
4. System zobrazí vybranou zprávu.
Alternativní průběh:
1. System upozorni uživatele na obdrženi nové zprávy
2. Uživatel vybere zprávu.
3. System zobrazí zprávu.
Page 22 of 34
9 December, 2014
Issue Management
Issue Management diagram
Figure 23:
Issue Management
Page 23 of 34
9 December, 2014
Requirements Mapping diagram
Figure 24:
Requirements Mapping
Add invested time
Přidaní času stráveného nad daným issue.
ID_13: Přidání time spend
1. Uživatel chce přidat čas stráveny nad daným issue.
2. Uživatel vyplní příslušné okno s formulářem
3. Uživatel potvrdí a Systém uloží změny.
Page 24 of 34
9 December, 2014
Change issue status
Změna stavu daného issue.
Požadavek:
Issue je viditelná
ID_14: Změna stavu issue
1. Uživatel chce změnit stav issue.
2. Uživatel si vybere nový stav issue, na který chce issue změnit.
3. Následně uživatel potvrdí výběr a Systém provede změnu.
Create Issue
Popis:
Přidaní issue uživatelem do projektu.
Požadavek:
Uživatel je členem nebo autorem projektu do kterého chce přidat issue.
Substránka Issue je viditelná.
ID_15: Přidání issue
Základní průběh:
1. UC začíná když uživatel chce přidat issue.
2. uživatel vyplní informace o issue do formuláře
2.1 IF povinna pole nejsou vyplněna
THEN uživatel je informován hláškou
3. Po vyplněni informaci o issue system přidá issue do seznamu issue daného projektu.
Alternativní průběh (issue již existuje):
IF uživatel má práva na úpravu existující issue
THEN je přesměrován na úpravu existující issue
IF uživatel nemá práva na úpravu existující issue
THEN je upozorněn hláškou že nemá práva na úpravu
Modify issue data
Popis:
Úprava již existující issue u daného projektu.
Požadavek:
Seznam issue daného projektu je viditelný Uživatel má práva na úpravu dané issue
ID_16: Úprava existující issue
Základní průběh:
1. UC začíná když uživatel chce upravit issue.
2. uživatel je v puštěn systémem do issue, kde může změnit informace o issue.
3. Po skončeni uprav uživatel potvrdí úpravy a issue je systémem upravena.
Alternativní průběh:
1. UC začíná když uživatel je přesměrován z tvorby issue na úpravu, protože daná issue již existuje.
2. uživatel je v puštěn systémem do issue, kde může změnit informace o issue.
3. Po skončeni uprav uživatel potvrdí úpravy a issue je systémem upravena.
Page 25 of 34
9 December, 2014
Set issue assignee
Přiřazení uživatele k issue.
ID_17: Přiřazení issue uživateli
1. Uživatel chce přiřadit k issue assignee.
2. Uživatel si vybere daného assignee ze seznamu.
3. Uživatel výběr potvrdí a Systém provede přiřazení.
View issue data
Zobrazení dát k issue.
Požadavek:
Seznam issue je viditelný.
ID_18: Zobrazení issue
1. Uživatel chce zobrazit data k příslušnému issue.
2. Uživatel vybere ze zobrazených issue a Systém issue otevře pro čtení.
Page 26 of 34
9 December, 2014
Project Management
Project Management diagram
Figure 25:
Project Management
Page 27 of 34
9 December, 2014
Requirements Mapping diagram
Figure 26:
Requirements Mapping
Change member's role
ID_7: Změna role u uživatele
Základní průběh:
1. Uživatel chce změnit roli jednoho z členů týmu
2. System zobrazí členy týmu
3. Uživatel vybere příslušného člena týmu
4. System zobrazí výpis roli
5. Uživatel vybere jednu z roli
6. System uloží provedené změny
Page 28 of 34
9 December, 2014
Create custom category
ID_8: Vytvoření kategorie
Základní průběh:
1. Uživatel chce vytvořit novou kategorii
2. System zobrazí stránku pro přidaní nové kategorie
3. Uživatel vyplní potřebné udaje
4. System přidá novou kategorii
Create event
Popis:
Vytvořeni události k danému projektu.
Požadavek:
Stránka projektu je viditelná
ID_9: Tvorba události
Základní průběh:
1. Uživatel chce vytvořit událost
2. System zobrazí formulář pro přidaní nové události
3. Uživatel vyplní udaje
4. IF povinna pole nejsou vyplněna nebo nejsou vyplněna správně,
THEN uživatel je informován chybovou hláškou
5. System vytvoří událost
Create new project
Popis:
Uživatel chce vytvořit projekt v systému
Požadavek:
Uživatel je přihlášen do systému. Substránka projekty je viditelná
ID_10: Vytvoření projektu
Základní průběh:
1. Uživatel chce vytvořit projekt.
2. System zobrazí formulář, který je zapotřebí vyplnit pro vytvořeni nového projektu
3. Uživatel vyplní formulář
4. IF povinna pole nejsou vyplněna
THEN zobrazí se chybová hláška a formulář předvyplněni předchozími hodnotami
5. System vytvoří projekt a jeho autora zapíše jako „Project Moderator“(PMO) u tohoto projektu.
Page 29 of 34
9 December, 2014
Invite user to project
Požadavek:
Uživatel se nachází na stránkách projektu. Osoba, kterou uživatel chce přidat do týmu je
zaregistrovaná v systému.
ID_11: Přidání uživatele do projektu
Základní průběh:
1. Uživatel chce přidat do projektu nového člena
2. System zobrazí formulář pro vyhledávání mezi registrovanými osoby
3. Uživatel vybere osobu, kterou chce přidat do týmu
4. System přidá osobu mezi členy projektu
Remove user from project
Popis:
Odstraněni uživatele z projektu. Uživatel je přihlášen, stránka projektu je viditelná
ID_12: Odebrání uživatele z projektu
Základní průběh:
1. Uživatel chce odstranit jednoho z členů projektu
2. System zobrazí seznam členů projektu.
3. Uživatel vybere uživatele pro odstraněni
4. IF uživatel, který bude odstraněn, je vlastníkem Issue,
THEN uživatel je informován hláškou, že je nutno issue přidělit jinému uživateli
5. System odebere uživatele z projektu
Page 30 of 34
9 December, 2014
User Management
Requirements Mapping diagram
Figure 27:
Requirements Mapping
User Management diagram
Figure 28:
User Management
Page 31 of 34
9 December, 2014
Log in
Popis:
Registrovány uživatel se chce přihlásit do systému
Požadavek:
Hlavní stránka aplikace je viditelná
ID_4: Přihlášení uživatele do systému
Základní průběh:
1. Návštěvník systému se chce přihlásit
2. System zobrazí přihlašovací formulář
3. Uživatel vyplní formulář
4. System z validuje formulář
IF pole username nebo password jsou vyplněna správně
THEN System přihlásí uživatele do systému
ELSE system zobrazí chybovou hlášku, pote zase zobrazí novy přihlašovací formulář, uživatel musí vyplnit pole znovu
dokud nebudou obě správně.
Log out
Popis:
Odhlášení uživatele z systému
Požadavek:
Uživatel musí být přihlášení
ID_5: Odhlášení uživatele z systému
Základní průběh:
1. Use Case začíná když se uživatel chce odhlásit z systému
2. Uživatel požádá system o odhlášeni
3. System odhlásí uživatele
Register
Popis:
Novy uživatel se chce zaregistrovat do systému
Požadavek:
Hlavní stránka aplikace je viditelná
ID_6: Registrace uživatele
Základní průběh:
1. UC začíná když se návštěvník systému chce zaregistrovat do systému
2. Návštěvník systému vyplní udaje v formuláři pro registraci.
3. System z validuje vyplněna pole
IF povinna pole jsou nevyplněna
THEN návštěvník systému bude upozorněn hláškou „Nutné vyplnit všechna povinna pole“, formulář se nebude z
validován
ELSE system uloží obdržena data a přihlásí uživatele do systému
Výjimka:
Při nesprávném vyplněni polí není návštěvník systémem registrován, ale pole která byla vyplněna špatně jsou zvýrazněna
Page 32 of 34
9 December, 2014
Wiki-Pages Management
Requirements Mapping diagram
Figure 29:
Requirements Mapping
Wiki-Pages Management diagram
Figure 30:
Wiki-Pages Management
Page 33 of 34
9 December, 2014
Change page content
Popis:
Upraveni existující Wiki stránky
Požadavek:
Existující projekt a vytvořená Wiki stránka
ID_1: Úprava obsahu Wiki stránky
Základní průběh:
1. Use Case začíná, když chce uživatel upravit jednu z Wiki stránek
2. Include(Vybrat Wiki stránku)
3. Uživatel upraví Wiki stránku projektu ve formuláři.
IF uživatel smaže veškerý obsah Wiki stránky THEN je informován hláškou, že bude smazán veškerý obsah Wiki stránky
4. System uloží do záznamu všechny změny provedené uživatelem.
Create Wiki page
Vytvořeni Wiki stránky projektu.
Požadavek:
Existující projekt
ID_2: Vytvoření Wiki stránky
Základní průběh:
1. Uživatel chce vytvořit novou Wiki stránku
2. Uživatel otevře Wiki stránky
3. Uživatel vyplní stránku (HTML formát)
4. IF uživatel nic nevyplnil
THEN System se zeptá, zda chce uživatel vytvořit prázdnou stránku
ELSE System uloží provedené změny
Remove Wiki page
Popis:
Odstraněni Wiki stránky
Požadavek:
Vytvořený projekt a existující Wiki stránky projektu
ID_3: Odstranění Wiki stránky
Základní průběh:
1.Uživatel chce odstranit jednu z Wiki stránek projektu.
2. System zobrazí příslušnou stránku
3. Uživatel vybere možnost "Odstranit"
4. IF Wiki stránka není prázdna,
THEN uživatel je informován hláškou, stránka obsahuje data
5. Uživatel potvrdí odstraněni stránky
6. System smaže obsah stránky
Page 34 of 34
Individuální zhodnocení dosavadní práce na
projektu UnderTracker.
Anastasia Kuznetsova (vedoucí týmu) “Jako vedoucí týmu jsem se setkala s následujícími problémy: 1.
Členové týmu nedodržují pevně stanovené terminy pro odevzdávání svých úkolů. S daným problémem se bohužel potýkám v každé iteraci. Kvůli tomu se nemůžu spolehnout na své kolegy a jsem nucena pořád kontrolovat průběh jejich prácí, problém zhoršuje špatná komunikace ze strany některých členů týmu. 2.
Problém popsaný v bodě č. 1 ovlivňuje i kvalitu odvedené práce. (Pokud úkol nebyl vypracován před konzultaci/ve stanoveném terminu nemůžeme zkontrolovat jeho správnost.) 3.
Podle mě u většiny členů týmu chybí zájem o projekt. Musím říct, že problémy popsané výše jsou způsobené zčásti i mým vedením. V příštích iteracích budu provádět přesnější kontrolu úkolů a zavedu přísnější bodové hodnocení, které bude ovlivňovat nejenom kvalita vypracovaného úkolu ale i čas odevzdání (zda úkol byl odevzdán po či před deadlinem). ” Nikita Silin “Projektu se věnuji na maximum, dle mých možností. Z projektu mám zatím pozitivní pocit. Práci ostatních členů týmu nebudu hodnotit.” Jan Kotouč “Do této chvíle si myslím, že projekt funguje s malými problémy relativně dobře. Návrhy na zlepšení Sám za sebe mohu říci, že bohužel jsem zatím nemohl věnovat projektu tolik času, kolik bych chtěl a to z důvodu velkého pracovního vytížení. Povedlo se mi ale trochu upravit svůj časový plán a v následujících iteracích bych měl mít na pracování na projektu více času než doposud. Co se týče práce v týmu, tak myslím, že jediné, co by se mělo zlepšit je komunikace uvnitř a přesné zadání jednotlivých úkolů a jejich kontrola. ” Jaroslav Smutek “Podle mě, projekt i tým ze začátku fungoval na drobné obtíže dobře, bohužel s postupem se projevila časová vytíženost na všech členech týmu jenž měla negativní dopad na projekt. Sám na sebe můžu říci, že jsem odevzdal některé práce na těsno nebo po termínu, což se budu snažit napravit.” Peter Schmiedt “Musím se přiznat, že jsem některé úkoly odevzdával po termínu, resp. těsně před. Nebylo to z důvodu nezájmu o projekt, spíše z důvodu pracovního vytížení. Beru na vědomí výše popsaná opatření a budu se snažit své nedostatky odstranit.” Výpis ticketů ze systému ASSEMBLA za poslední iteraci
number
summary
assigned_to_name status
hours
24 Implementace pripadu uziti
Nikita Silin
Accepted
2
25 Implementace pripadu uziti, dokumentace
Anastasia Kuznetsova
Accepted
2
Hours
Description
Práce nad 3. iteraci
Date
User
Project
11/29/2014
Anastasia Kuznetsova
UnderTracker
2 Implemetace pripadu uziti, dokumentace
11.14.2014
Peter Schmiedt
UnderTracker
1 Analytický doménový model
11.14.2014
Peter Schmiedt
UnderTracker
2 Analytický doménový model
11.14.2014
Nikita Silin
UnderTracker
3 Robustní architektonický základ
11.14.2014
Anastasia Kuznetsova
UnderTracker
1,5 Dokumentace, Scénáře případů užití
11.14.2014
Anastasia Kuznetsova
UnderTracker
3 Dokumentace, Scénáře případů užití
11.9.2014
Jan Kotouč
UnderTracker
1 Katalog funkčních a obecných požadavků a BPM
11.2.2014
Jan Kotouč
UnderTracker
2 Katalog funkčních a obecných požadavků a BPM
11.1.2014
Jaroslav Smutek
UnderTracker
1,5 Prvotní model architektury systému
10.31.2014
Jan Kotouč
UnderTracker
1,5 Katalog funkčních a obecných požadavků a BPM
10/26/2014
Jaroslav Smutek
UnderTracker
1 Prvotni model architektury systemu
10/24/2014
Nikita Silin
UnderTracker
4 Vytvoreni Use-Case modelu, mapovani pozadavku
10/24/2014
Nikita Silin
UnderTracker
2 Opravy diagramu BPM a BDM
10/24/2014
Anastasia Kuznetsova
UnderTracker
4 Kontrola diagramu, oprava vize, odevzdani, kontrola BDM modelu
10/24/2014
Jaroslav Smutek
UnderTracker
2 Opravy diagramu BPM a BDM
10/24/2014
Anastasia Kuznetsova
UnderTracker
2 Opravy diagramu BPM a BDM
10/23/2014
Anastasia Kuznetsova
UnderTracker
2 Opravy diagramu BPM a BDM
10/23/2014
Jan Kotouč
UnderTracker
10/19/2014
Jaroslav Smutek
UnderTracker
10/13/2014
Jan Kotouč
UnderTracker
10.10.2014 Nikita Silin
UnderTracker
10.10.2014 Nikita Silin
UnderTracker
0.5
BPM model vypracovany
4 BDM model
1 Oprava vize - Jan
0.5
Oprava odstavce "Porovnavani jiz existujicich reseni"
1 Oprava vize
10.9.2014 Jaroslav Smutek
UnderTracker
0.5
Opravy ve vizi - Jara
10.5.2014 Jan Kotouč
UnderTracker
1 Korekce/editace vize
10.5.2014 Jan Kotouč
UnderTracker
1 Meeting ohledne vize
10.4.2014 Jaroslav Smutek
UnderTracker
1,5 Korekce/editace vize
10.1.2014 Anastasia Kuznetsova
UnderTracker
2,5 Meeting ohledne vize
10.1.2014 Jaroslav Smutek
UnderTracker
2 Meeting ohledne vize
10.1.2014 Nikita Silin
UnderTracker
2 Meeting ohledne vize
Celkový součet hodin práce nad 3. iteraci: 16,5 hodin
Celkový součet hodin práce nad projektem: 55, 4 hodin
V každé iteraci musí být přerozdělen minimálně takový počet bodů kolik je členů týmu!
Přerozdělené
body celkem
3.týden
5.týden
Důvod přerozdělení. Musí Přerozdělené
být vyplňeno!
body
Důvod přerozdělení
4
Prace na dokumentaci,
priprava a kontrola vizi
Nutno prerozdelit.
Vypracovala dokumentaci,
2 opravila BPM a BDM model
Smutek Jaroslav
0
Dobra prace, vzdycky
vysel vstric
Vytvoril BDM model, pomahal
2 pri oprave BPM modelu
Schmiedt Peter
-3
Neumyslne se nepodelil
na vytvoreni vizi. Navic je
nutno prerozdelit body
Silin Nikita
5
Prace na dokumentaci,
zadne pripominky
-7
Na meetingu resime
problemy ohledne
projektu, ne osobni
zalezitosti..
Příjmení a jméno
Kuznetsova
Anastasia
Kotouč Jan
Celkem (musí být 0)
Přerozděleno
#REF!
Přerozdělené
body
Celkem
Implementace pripadu uziti,
2 dokumentace
Vytvoril prvotni model
architektury systemu,
1 scenare pripadu uziti
0
#REF!
10.týden
Přerozdělené
body
Důvod přerozdělení
Kontrola odvedene prace,
dokumentace, scenare
-5 pripadu uziti
Oprava vize, oponentura
(praci vypracoval po
-4 stanovenemu deadlinu)
Vytvoril Use-Case diagramy,
mapovani pozadavku,
pomahal pri oprave BPM
1 modelu
Vytvoril BPM model
(odevzdal ho po terminu, kvuli
cemu jsme ho nestihli opravit
s ucitelem). BPM model byl
nasledne upraven protoze
-1 obsahoval chyby.
0
#REF!
8.týden
Přerozdělené
body
Důvod přerozdělení
5
4
Nutno prerozdelit body, v
prubehu dane iterace neodvedl
2 zadnou praci
-5
0
2Napsal oponenturu
-2
-3
5
5
-3
-7
0
-1
Vytvoril analyticky
domenovy model, scenare
1 pripadu uziti
Nutno prerozdelit body!!
Vytvoril repozitar na github
a architektonicky zaklad
2 projektu
-3Implementace pripadu uziti
Nutno prerozdelit body!!
Vytvoril katalog funkcnich a
obecnych pozadavku,
1 scenare pripadu uziti.
-4V dane iteraci neodvedl zadnou
0
-1
#REF!
#REF!
#REF!