Dokumetace projektu
Školní informační systém Stupid kids industries Zkratka: SIS Email: skolni informacni system
[email protected] Webová stránka: https://www.assembla.com/spaces/projekt is/ Řešitelé: ●
Ladislav Mejzlík
●
Ondřej Doležal
● ●
Ondřej Skoumal Temirlan Kurbanov
●
Adam Paulík
Termín cvičení: ZS 2014/2015, pondělí, 9:15 Cvičící: Ing. Ondřej Macek Datum odevzdání: 28.11.2014
České vysoké učení technické v Praze Semestrální práce k předmětu A4B33SI
1
Obsah Úvodní strana
1
Tabulka verzí
3
Úvod
3
Zainteresované osoby
4
Klíčové vlastnosti
4
Popis systému
4
Kvalitativní požadavky
5
Použité technologie
5
Požadavky ze strany klienta
5
Možná rizika a jejich řešení
6
Rozpočet
6
RACI matice
7
Business process model
8
Business domain model
14
Analytický model tříd
15
Požadavky
16
Use case model
19
Use case description
20
Model komponent
23
Model nasazení
24
Přehled práce týmu
25
2
Tabulka verzí Verze
Datum
Popis
Autor
1
22.9. 2014
Papírová verze ze cvičení
Skupinová práce
2
29.9. 2014
Převedení do elektronické verze
Skupinová práce
3
3.10. 2014
Vytvoření RACI matice
Skupinová práce
4
5.10. 2014
Úprava formátování, přidán úvod a klíčové Ladislav Mejzlík vlastnosti
5
6.10. 2014
Přidání kvalitativních požadavků, RC1
Ladislav Mejzlík
6
6.10. 2014
Korektura
Ondřej Doležal
7
8.10.2014
Úprava úvodu a klíčových faktorů
Skupinová práce
8
9.10.2014
Přidána tabulka rizik, doplněn rozpočet
Ondřej Doležal
9
9.10.2014
Přidána finální RACI matice
Ondřej Skoumal
10
9.10.2014
Finální korektura
Ondřej Doležal
11
10.10. 2014
Drobné úpravy, finální formátování
Skupinová práce
12
21.10.2014
Úprava vize dle připomínek (oponentury)
Ondřej Doležal
13
28.11.2014
Uprava obsahu, vlozeni modelu
Skupinová práce
Úvod Projekt bude sloužit jako školní informační systém pro správu předmětů, učitelů a žáků. Zjednoduší práci s rozvrhy, které budou uchovávány v elektronické podobě. Všechny dočasné změny rozvrhu budou vidět okamžitě. Systém bude zároveň sloužit jako elektronická žákovská knížka, ve které se budou uchovávat známky a docházka žáků. V systému bude možnost nastavit upozornění na změny rozvrhu, přidání nové známky a překročení stanovené hranice absencí na mobilní zařízení (Android, iOS).
3
Zainteresované osoby Zákazník: ZŠ Mělník Zodpovědná osoba: Jakub Novák (ředitel) Konzultant zakázníka: Lukáš Vodrážka (učitel informatiky) Koncoví uživatelé: studijní oddělení, učitelé, žáci, zákonní zástupci
Klíčové vlastnosti ● ● ● ● ● ● ● ●
databáze učitelů databáze žáků správa rozvrhu rozdělení na sudý a lichý týden zvýraznění dočasných změn zápis známek možnost zadat váhu známky výpočet průměru ○ archivace pololetní a roční známky ● nízké pořizovací náklady ● mobilní notifikace (Android, iOS) s využitím Pushbullet API
Popis systému Systém musí být schopen obsluhovat více uživatelů najednou. Systém bude zabezpečen uživatelským jménem a heslem. Systém bude umožňovat sdílení souborů. Ředitel ● představuje hlavní autoritu ● spravuje učitele, žáky a zákonné zástupce ● vytváří předměty a jejich rozvrhové paralelky ● spravuje suplování ● přijímá elektronické neschopenky učitelů Učitel ● zobrazuje a upravuje svoje předměty ● zobrazuje rozvrhy ● zobrazuje seznam žáků na své paralelce ● zapisuje docházku a známky žáků ● přidává výukové materiály ● kontroluje omluvenky odevzdané zákonným zástupcem (dle hodiny, na kterou žák chyběl) ● zobrazuje hodiny, které má suplovat ● odesílá neschopenky řediteli 4
Žák ● zobrazuje svůj rozvrh ● kontroluje svoji docházku a známky ● zobrazuje seznam domácích úkolů ● prohlíží materiály nahrané učiteli Zákonný zástupce ● zobrazuje rozvrh dítěte ● kontroluje docházku a známky dítěte ● elektronicky odevzdává omluvenky učiteli
Kvalitativní požadavky Univerzálnost systému ● Intuitivní ovládání snadná správa bez znalosti programování ○ pro ředitele atd ● Spolehlivost systému (nedochází k pádům) ● Bezpečnost (uchovávání a editace informací) ● Současný přístup 100 uživatelů ● 98% dostupnost systému (počítáno za posledních 30 dnů) ● Systémové role (dle postavení) ● Provázanost s cloudovým úložištěm (ukládání studijních materiálů, omluvenek
Použité technologie ● ● ●
JAVA 7 SE Oracle MySQL UML 2.0
Požadavky ze strany klienta ● ●
Musí se vejít na 1 DVD Dodání včetně HW (serveru)
5
Možná rizika a jejich řešení Riziko
Šance
Řešení č. 1
Řešení č. 2
Úraz člena týmu, Středně vysoká Vysoký onemocnění, smrt
Rozdělení členovy práce mezi ostatní
Externí výpomoc
Technické potíže Středně vysoká Středně vysoký (výpadek internetu, potíže s HW)
Přesun subjektu do bezproblémového prostředí
Nepochopení zadání
Vysoká
Dopad
Středně vysoký Konzultace s ostatními členy týmu
Konzultace s hlavou týmu
Nízká Napadení vývojářských PC
Vysoký
Obnova dat
Lepší prevence do budoucna
Chyba v řízení Vysoká lidských zdrojů (rozepře v týmu)
Vysoký
Teambuilding
Diskuze s problémovými členy
Rozpočet ● ● ● ●
● ●
Spuštění testovacího provozu na koncovém hardwaru proběhne začátkem června 2017 Ostré spuštění systému proběhne na konci srpna 2017 Cena za kopii je stanovena na 200 tis. Kč ○ předpokládáme prodej 23 licencí Cena za vývoj je odhadována na 375 tis. Kč ○ odhadovaná doba vývoje je 3 měsíce ○ požadovaný plat pro jednoho člena týmu je 25 tis. Kč mesíčně po zdanění (x3 měsíce x5 členů týmu) Odhadované měsíční náklady pro zákazníka jsou 10 tis. Kč měsíčně (2000 Kč provoz + 3000 Kč údržba + 5000 Kč podpora a SW aktualizace serveru) Server není zahrnut v pořizovací ceně, na servery ovšem nabízíme zvýhodněné nabídky, nabídka pro červen 2017 (ceny včetně DPH): HP ProLiant ML310e Gen8 v2 za 13 200 Kč, Fujitsu PRIMERGY TX1310 M1 za 10 500 Kč (nabídka se mění každý měsíc) ● Pro cloud bude využito bezplatné úložiště Dropbox
6
RACI Matice
7
Byznys analýza Business Process Model ●
Proces průběhu vyučovací hodiny
8
●
Proces suplování
9
●
Proces přidání učitele
10
●
Proces přidání žáka
11
●
Proces vytvoření rozvrhu
12
● Proces omluvení žáka
13
Business Domain Model
14
Analytický model tříd
15
Požadavky Přehled priorit 1. Nezbytné program musí splňovat tyto požadavky 2. Žádoucí program by měl splňovat tyto požadavky 3. Navíc program by mohl splňovat tyto požadavky
1.
Funkční požadavky 1.1.
Registrace 1.1.1.
Systém umožní studijnímu oddělení přidávat nové uživatele učitele, žáky s jejich zákonnými zástupci
Priorita: nezbytné
1.2.
Přihlášení/odhlášení
1.2.1. Systém umožní nepřihlášeným uživatelům přihlášení 1.2.2. Systém umožní uživatelům odhlásit se Priorita: nezbytné
1.3.
Kontaktní údaje 1.3.1. 1.3.2.
Systém umožní přihlášenému uživateli zobrazovat a měnit své osobní a kontaktní údaje (email, telefonní číslo, ...) Systém umožní studijnímu oddělení zobrazit seznam všech uživatelů a aktuální informace jich se týkající
Priorita: nezbytné
1.4.
Předměty 1.4.1.
Systém umožní studijnímu oddělení vytvářet nové předměty a upravovat existující předměty (mění čas, učitele…) Systém umožní učiteli zobrazit a upravit své předměty, přidat materiály Systém umožní žákovi zobrazit své předměty a informace o nich
1.4.2. 1.4.3. Priorita: nezbytné
16
1.5.
Rozvrhy 1.5.1. 1.5.2.
Systém umožní studijnímu oddělení vytvářet a upravovat rozvrhové paralelky předmětů Systém umožní studijnímu oddělení zadávat dočasné změny rozvrhu (suplování, změny místnosti, …) Systém umožní učiteli a žákovi zobrazit své aktuální rozvrhy Systém umožní učiteli zobrazit seznam žáků na své paralelce Systém umožní zákonnému zástupci zobrazit rozvrh dítěte
1.5.3. 1.5.4. 1.5.5. Priorita: nezbytné
1.6.
Známky 1.6.1.
1.6.2. 1.6.3. 1.6.4. 1.6.5.
Systém používá k hodnocení výsledků číselnou škálu (na stupnici od 1 do 5) Systém umožní učiteli zapsat žákům známky Systém umožní učiteli zobrazit známky a průměry známek žáků, které vyučuje Systém umožní žákovi zobrazit známky a průměr známek svých předmětů Systém umožní zákonnému zástupci kontrolovat známky a průměr známek svého dítěte
Priorita: nezbytné
1.7.
Docházka žáků
1.7.1. Systém umožní učitelu zapisat docházku žáků 1.7.2. Systém umožní žákovi kontrolovat svou docházku za aktuální pololetí 1.7.3. Systém umožní zákonnému zástupci kontrolovat docházku dítěte 1.7.4. Systém umožní zákonnému zástupci odevzdávat elektronické omluvenky 1.7.5. Systém umožní učitel kontrolovat omluvenky žáků Priorita: žádoucí
1.8.
Docházka učitelů 1.8.1. 1.8.2. 1.8.3.
Systém umožní studijnímu oddělení zadávat změny ve výuce Systém umožní studijnímu oddělení zobrazit změny ve výuce Systém umožní učiteli oznamovat neschopnost
Priorita: žádoucí
17
2.
Obecné požadavky 2.1.
Intuitivní ovládání Aplikace by měla být snadno ovladatelná bez použití dokumentace
Priorita: žádoucí
2.2.
Spolehlivost systému
2.2.1. Střední doba do výpadku je půl roku 2.2.2. Střední doba do opětovného uvedení do provozu je jeden den Priorita: žádoucí
2.3.
Bezpečnost (uchovávání a editace informací) 2.3.1.
Systém zabrání přístup neautorizovaným osobám Priorita: nezbytné
18
Use case model
19
Use case description 1.
2.
3.
4.
Registrovat nové uživatele (požadavek 1.1.1) ● precondition: uživatel je členem skupiny “Studijní oddělení” 1.1. Studijní oddělení vyplní informace o novém uživateli podle přijaté přihlášky (žák a jeho zákonní zástupci) nebo podle životopisu (učitelé a zaměstnanci školy) 1.2. Systém validuje datat a zobrazí výzvu k potvrzení vytvoření uživatele 1.3. Uživatel potvrdí uložení nového uživatele ● Alternativní scénař: ○ Chyba v datech, nebo nepotvrzení vytvoření v 1.3 ■ Návrat do bodu 1.1 Zobrazit seznam všech žáků včetně jejich informací (požadavek 1.3.2) ● precondition: uživatel je členem skupiny “Studijní oddělení” 2.1. Systém zobrazí seznam žáků v tabulce se základními informacemi 2.2. Uživatel má možnost třídit seznam podle různých informací 2.2.1. <<extend>> Uživatel má možnost seznam vytisknout 2.3. Systém zobrazí setříděný seznam 2.4. Uživatel může zobrazit podrobnosti o jednotlivém žákovi 2.5. Systém zobrazí detailní informace o vybraném žákovi 2.5.1. <<extend>> Uživatel má možnost informace vytisknout Zobrazit seznam všech učitelů včetně jejich informací (požadavek 1.3.2) ● precondition: uživatel je členem skupiny “Studijní oddělení” 3.1. Systém zobrazí seznam učitelů 3.2. Uživatel má možnost třídit seznam podle různých informací 3.2.1. <<extend>> Uživatel má možnost seznam vytisknout 3.3. Systém zobrazí setříděný seznam 3.4. Uživatel může zobrazit podrobnosti o jednotlivém učitelovi 3.4.1. <<extend>> Uživatel má možnost informace vytisknout 3.5. Systém zobrazí podrobné informace o vybraném učiteli Vytvořit a upravit rozvrhy (požadavek 1.5.1) ● precondition: uživatel je členem skupiny “Studijní oddělení” 4.1. Systém zobrazí seznam předmětů 4.2. Uživatel vybere předmět pro který chce vytvářet, nebo editovat rozvrh 4.3. Systém zobrazí seznam již vytvořených hodin vybraného předmětu 4.4. Uživatel vybere hodinu ze seznamu již vytvořených hodin pro editaci nebo stiskne tlačítko “Nová hodina” 4.5. Systém zobrazí dialogové okno pro editaci a vytvoření hodiny 4.6. Uživatel vyplní informace o hodině (učitel, místnost, žáci, typ opakování {vše, sudý, lichý}, čas hodiny, rozmezí od kdy do kdy se bude předmět vyučovat), a potvrdí uložení 4.7. Systém zobrazí seznam již vytvořených hodin vybraného předmětu 4.8. Uživatel může přidat další hodin (pokračovat krokem 4.4) nebo přejít na výběr předmětů (krok 4.1) 20
4.9.
5.
6.
7.
8.
9.
Po zadání všech změn má uživatel možnost zkontrolovat chyby v rozvrhu tlačítkem “Kontrola rozvrhu”, které vypíše případné chyby (učitel nebo žák má více hodin ve stejný čas, v jedné třídě se učí více hodin ve stejný čas), systém uživatel pouze varuje, chyby povolí Zadat dočasné změny rozvrhu (suplování, změna místnosti, ...) (požadavek 1.5.2) ● precondition: uživatel je členem skupiny “Studijní oddělení” 5.1. Systém zobrazí seznam vyučovaných předmětů 5.2. Uživatel vybere předmět 5.3. Systém zobrazí hodiny vybraného předmětu 5.4. Uživatel vybere hodinu u které chce zadat změnu 5.5. Systém zobrazí dialogové okno pro změnu informací o hodině 5.6. Uživatel zadá změněné informace o hodině, případně zaškrtne políčko “odpadá” 5.7. Uživatel potvrdí uložení změn Přihlásit se do systému (požadavek 1.2.1) 6.1. Systém zobrazí přihlašovací obrazovku 6.2. Uživatel vyplní přihlašovací údaje a potvrdí přihlášení 6.3. Systém zkontroluje přihlašovací údaje 6.4. Uživatel A) je přihlášený nebo B) se zobrazí okénko hlásící chybu v systému(špatné údaje, chyba v programu) Zobrazit své osobní a kontaktní údaje (požadavek 1.3.2) 7.1. Uživatel spustí okénko okénko se svými informacemi 7.2. Systém zobrazí podrobné informace o uživateli Měnit své osobní a kontaktní údaje (požadavek 1.3.2) 8.1. Uživatel spustí okénko okénko se svými informacemi 8.2. Systém zobrazí podrobné informace o uživateli 8.3. Uživatel přepne do režimu editace 8.4. Systém zobrazí editační okno 8.5. Uživatel změní potřebné informace 8.6. Systém data validuje 8.7. Uživatel potvrdí uložení změn ● Alternativní cesta: ○ Špatně zadaná data v kroku 8.6 ■ Systém zobrazí chybovou hlášku, a pokračuje krokem 8.4 Zobrazit informace o svých předmětech včetně studijních materiálů (požadavek 1.4.3) 9.1. Systém zobrazí seznam uživatelových předmětů 9.2. Uživatel může třídit seznam podle různých vlastností 9.3. Systém zobrazí setříděný seznam 9.3.1. <<extend>> Uživatel má možnost seznam vytisknout 9.4. Uživatel vybere předmět, u kterého chce zobrazit podrobné informace 9.5. Systém zobrazí podrobné informace o vybraném předmětu 9.5.1. <<extend>> Uživatel má možnost podrobnosti vytisknout
21
9.5.2.
10.
11.
12.
13.
14.
15.
16.
17.
18.
<<extend>> Uživatel má možnost stáhnout studijní materiály Zobrazit svůj aktuální rozvrh (požadavek 1.5.3) 10.1. Systém zobrazí uživatelův stálý rozvrh 10.2. Uživatel může přepnout zobrazení týdne na sudý, lichý a kombinovaný 10.2.1. <<extend>> Uživatel má možnost rozvrh vytisknout Zobrazit svoji docházku za aktuální pololetí (požadavek 1.9.2) ● precondition: uživatel je členem skupiny “Žák” 11.1. Uživatel zobrazí svoji docházku, včetně souhrných informací (procentuální zameškanost, …) Zobrazit svoje známky za aktuální pololetí (požadavek 1.6.4) ● precondition: uživatel je členem skupiny “Žák” 12.1. Uživatel zobrazí svoje známky za aktuální pololetí, včetně průměrů za předmět a celkového průměru Zobrazit své závěrečné a pololetní známky za všechna období (požadavek 1.6.4) ● precondition: uživatel je členem skupiny “Žák” 13.1. Uživatel zobrazí svoje závěrečné a pololetní známky za všechna období, včetně průměrů za předmět a celkového průměru Poslat omluvenku (požadavek 1.9.4) 14.1. Systém zobrazí přehled docházky žáka 14.2. Zákonný zástupce vybere absenci, kterou chce omluvit 14.3. Systém zobrazí okno pro zadání důvodu absence 14.4. Zakonný zástupce napíše důvod absence a potvrdí uložení Omluvit absenci žáka (požadavek 1.9.5) 15.1. Systém zobrazí absence žáků 15.2. Učitel zkontroluje důvod absence 15.3. Učitel označí absenci jako omluvenou nebo jako nedostačující a důvod je smazán Přidat studijní materiál ke svým předmětům (pomocí odkazu) (požadavek 1.4.2) ● precondition: uživatel je učitel předmětu 16.1. Systém zobrazí seznam předmětů 16.2. Uživatel vybere předmět, u kterého chce přidat nebo upravit studijní meteriály 16.3. Systém zobrazí editační okno 16.4. Uživatel připíše odkaz do příslušné kolonky Změnit informace o svých předmětech (požadavek 1.4.2) ● precondition: uživatel je učitel předmětu 17.1. Systém zobrazí seznam předmětů 17.2. Uživatel vybere předmět, u kterého chce provádět změny 17.3. Systém zobrazí editační okno 17.4. Uživatel změní příslešné informace 17.5. Uživatel potvrdí změny Zobrazit seznam žáků svých hodin (požadavek 1.5.4) ● precondition: uživatel je učitel předmětu 18.1. Systém zobrazí seznam předmětů 22
18.2. 18.3.
Uživatel vybere předmět, u kterého chce zobrazit žáky Systém zobrazí seznam žáků 18.3.1. <<extend>> Uživatel může seznam vytisknout 19. Zapsat známku žákům svých hodin (požadavek 1.6.2) ● precondition: uživatel je učitel předmětu 19.1. Systém obrazí seznam předmětů 19.2. Uživatel vybere předmět, u kterého chce zadat známky 19.3. Systém zobrazí seznam žáku, s možností přidat známku 19.4. Uživatel žákům zapíše známku 20. Zapsat závěrečné (pololetní) známky svým žákům (požadavek 1.6.2) ● precondition: uživatel je učitel předmětu 20.1. Systém zobrazí seznam předmětů 20.2. Uživatel vybere předmět, u kterého chce zadat známky 20.3. Systém zobrazí seznam žáku, s možností přidat známku 20.4. Uživatel žákům zapíše závěrečnou známku
Model komponent
23
Model nasazení
24
Přehled práce týmu za celý projekt
Adam Paulík Datum
Ticket
Hodiny
28.11.2014
42: Úprava BPM
5,00
14.11.2014
30: Vytvoření textového popisu Use case
1,50
14.11.2014
31: Meating HO před odevzdání 3. iterace
1,00
14.11.2014
28: Class diagram
4,00
2.11.2014
8: Meeting 5
1,00
2.11.2014
23: Přehled práce týmu, finální PDF
1,00
2.11.2014
17: Meeting 2.2
3,00
2.11.2014
20: Posudek 2. iterace projektu MEDISERVICE
1,00
2.11.2014
24: Oprava BPM
6,50
24.10.2014
10: Uprava pozadavku pred 2. odevzdanim
1,00
24.10.2014
13: Vytvoření základní verze Business Domain Modelu
2,00
24.10.2014
16: Vytvoření BPM
1,00
24.10.2014
16: Vytvoření BPM
5,00
10.10.2014
4: Meeting 2
1,50
9.10.2014
1: Vize
3,00
CELKEM
37,5
25
Ladislav Mejzlík Datum
Ticket
Hodiny
28.11.2014
43: Meeting 4.1
1
28.11.2014
41: Úprava Use case description
2,5
28.11.2014
40: Mapování požadavků na use case
0,75
27.11.2014
36: Přeformulování požadavků
1
27.11.2014
35: Model komponent
1,5
27.11.2014
34: Model nasazení
1,5
14.11.2014
31: Meating HO před odevzdání 3. iterace
1
14.11.2014
30: Vytvoření textového popisu Use case
2
13.11.2014
27: Vytvoření Videa
2
13.11.2014
25: Třídy pro obsluhu databáze
1,5
13.11.2014
25: Třídy pro obsluhu databáze
3,5
31.10.2014
12: Use case model
0,75
27.10.2014
20: Posudek 2. iterace projektu MEDISERVICE
1,5
24.10.2014
17: Meeting 2.2
3
23.10.2014
8: Meeting 5
1
23.10.2014
12: Use case model
1
22.10.2014
12: Use case model
2
12.10.2014
7: Oponentura projektu MediService
1
10.10.2014
5: Meeting 4
2
10.10.2014
3: Meeting 3
2,5
10.10.2014
2: Meeting 1
3
9.10.2014
1: Vize
3,25
CELKEM
39,25
26
Ondřej Doležal Datum
Ticket
Hodiny
28.11.2014
44: Uprava obsahu
4
14.11.2014
26: Úprava UseCase modelu
1
14.11.2014
31: Meating HO před odevzdání 3. iterace
1
14.11.2014
32: Editace vize
2
30.10.2014
9: Uprava vize pred 2. odevzdanim
1
24.10.2014
17: Meeting 2.2
1
23.10.2014
10: Uprava pozadavku pred 2. odevzdanim
1
21.10.2014
10: Uprava pozadavku pred 2. odevzdanim
1
21.10.2014
9: Uprava vize pred 2. odevzdanim
1,5
15.10.2014
8: Meeting 5
1
13.10.2014
7: Oponentura projektu MediService
0,5
10.10.2014
3: Meeting 3
2
10.10.2014
4: Meeting 2
2,8
10.10.2014
2: Meeting 1
3
9.10.2014
1: Vize
4,5
CELKEM
27,3
27
Temirlan Kurbanov Datum
Ticket
Hodiny
28.11.2014
43: Meeting 4.1
2.0
28.11.2014
39: Analyticky model trid
1.0
28.11.2014
39: Analyticky model trid
4.0
16.11.2014
33: Vytvoreni zakladu tridy Uzivatel
1.0
14.11.2014
33: Vytvoreni zakladu tridy Uzivatel
2.0
2.11.2014
22: Uprava katalogu pozadavku
3.0
31.10.2014
11: Vytvoření katalogu požadavků
0.5
24.10.2014
17: Meeting 2.2
3.0
24.10.2014
11: Vytvoření katalogu požadavků
1.0
22.10.2014
11: Vytvoření katalogu požadavků
1.0
22.10.2014
11: Vytvoření katalogu požadavků
4.0
12.10.2014
7: Oponentura projektu MediService
1.0
10.10.2014
5: Meeting 4
2.0
10.10.2014
3: Meeting 3
2.5
10.10.2014
4: Meeting 2
1.5
10.10.2014
2: Meeting 1
3.0
9.10.2014
1: Vize
0.2
9.10.2014
1: Vize
1.0
9.10.2014
1: Vize
2.0
CELKEM
35,7
28
Ondřej Skoumal Datum
Ticket
Hodin
28.11.2014
38: Výpis ticketů z assembly
1.0
28.11.2014
37: Oprava Domain Modelu
28.11.2014
43: Meeting 4.1
2.0
28.11.2014
37: Oprava Domain Modelu
1.5
14.11.2014
28: Class diagram
3.0
14.11.2014
29: Výpis ticketů z assembly
0.5
14.11.2014
31: Meating HO před odevzdání 3. iterace
1.0
14.11.2014
29: Výpis ticketů z assembly
0.5
14.11.2014
28: Class diagram
6.0
2.11.2014
8: Meeting 5
1.0
2.11.2014
17: Meeting 2.2
3.0
2.11.2014
21: Úprava Domain Modelu
2.0
31.10.2014
21: Úprava Domain Modelu
5.0
24.10.2014
15: Úprava a vytvoření finální verze Business Domain Modelu
6.0
24.10.2014
13: Vytvoření základní verze Business Domain Modelu
2.0
12.10.2014
7: Oponentura projektu MediService
2.0
10.10.2014
5: Meeting 4
2.0
10.10.2014
3: Meeting 3
2.5
10.10.2014
4: Meeting 2
2.0
10.10.2014
2: Meeting 1
3.0
9.10.2014
1: Vize
3.3
CELKEM
53,8
Celkem tým: 193,3 hodin
29
