Dokumetace projektu Školní informační systém Stupid kids industries Zkratka: SIS Email: skolni informacni system ski@googlegroups.com 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é vlastnosti Ladislav Mejzlík 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 Učitel 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ů 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 Dopad Řešení č. 1 Řešení č. 2 Úraz člena týmu, onemocnění, smrt Technické potíže (výpadek internetu, potíže s HW) Nepochopení zadání Středně vysoká Vysoký Rozdělení členovy práce mezi ostatní Středně vysoká Středně vysoký Přesun subjektu do bezproblémového prostředí Vysoká Středně vysoký Konzultace s ostatními členy týmu Externí výpomoc Konzultace s hlavou týmu Napadení vývojářských PC Chyba v řízení lidských zdrojů (rozepře v týmu) Nízká Vysoký Obnova dat Lepší prevence do budoucna Vysoká 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. Systém umožní přihlášenému uživateli zobrazovat a měnit své osobní a kontaktní údaje (email, telefonní číslo,...) 1.3.2. 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 ) 1.4.2. Systém umožní učiteli zobrazit a upravit své předměty, přidat materiály 1.4.3. Systém umožní žákovi zobrazit své předměty a informace o nich Priorita: nezbytné 16
1.5. Rozvrhy 1.5.1. Systém umožní studijnímu oddělení vytvářet a upravovat rozvrhové paralelky předmětů 1.5.2. Systém umožní studijnímu oddělení zadávat dočasné změny rozvrhu (suplování, změny místnosti, ) 1.5.3. Systém umožní učiteli a žákovi zobrazit své aktuální rozvrhy 1.5.4. Systém umožní učiteli zobrazit seznam žáků na své paralelce 1.5.5. Systém umožní zákonnému zástupci zobrazit rozvrh dítěte Priorita: nezbytné 1.6. Známky 1.6.1. Systém používá k hodnocení výsledků číselnou škálu (na stupnici od 1 do 5) 1.6.2. Systém umožní učiteli zapsat žákům známky 1.6.3. Systém umožní učiteli zobrazit známky a průměry známek žáků, které vyučuje 1.6.4. Systém umožní žákovi zobrazit známky a průměr známek svých předmětů 1.6.5. 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. Systém umožní studijnímu oddělení zadávat změny ve výuce 1.8.2. Systém umožní studijnímu oddělení zobrazit změny ve výuce 1.8.3. 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. 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 2. 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 3. 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 4. 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. 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í 5. 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 6. 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) 7. 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 8. 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 9. 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. <<extend>> Uživatel má možnost stáhnout studijní materiály 10. 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 11. 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, ) 12. 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 13. 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 14. 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í 15. 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 16. 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 17. 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 18. 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. Uživatel vybere předmět, u kterého chce zobrazit žáky 18.3. 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