Mendelova univerzita v Brně Provozně ekonomická fakulta
Informační systém autoškoly Bakalářská práce
Vedoucí práce: doc. Ing. František Dařena, Ph.D.
Brno 2014
Pirochta Jiří
Rád bych na tomto místě poděkoval doc. Ing. Františku Dařenovi, Ph.D. za přínosné rady a doporučení při vypracování této práce. Také chci poděkovat rodině, která mě podporovala během studia a při vypracování této práce.
Čestné prohlášení Prohlašuji, že jsem tuto práci: Informační systém autoškoly vypracoval samostatně a veškeré použité prameny a informace jsou uvedeny v seznamu použité literatury. Souhlasím, aby moje práce byla zveřejněna v souladu s § 47b zákona č. 111/1998 Sb., o vysokých školách ve znění pozdějších předpisů, a v souladu s platnou Směrnicí o zveřejňování vysokoškolských závěrečných prací. Jsem si vědom, že se na moji práci vztahuje zákon č. 121/2000 Sb., autorský zákon, a že Mendelova univerzita v Brně má právo na uzavření licenční smlouvy a užití této práce jako školního díla podle § 60 odst. 1 Autorského zákona. Dále se zavazuji, že před sepsáním licenční smlouvy o využití díla jinou osobou (subjektem) si vyžádám písemné stanovisko univerzity o tom, že předmětná licenční smlouva není v rozporu s oprávněnými zájmy univerzity, a zavazuji se uhradit případný příspěvek na úhradu nákladů spojených se vznikem díla, a to až do jejich skutečné výše. V Brně dne 21. května 2014
__________________
Abstract Pirochta, J. The Information system of driving school. Bachelor thesis. Brno: MENDELU in BRNO, 2014. Bachelor thesis is focused on the information system of driving school. At the beginning of the thesis, there is described current state of the market offer with systems for supporting process in a driving school. Next part of the thesis is aimed at the object oriented analysis and requirements design realized with UML for selected driving school. Finally, described processes are implemented using web frameworks Nette and jQuery. Keywords Information system, driving school, object oriented analysis and design, Nette, jQuery.
Abstrakt Pirochta, J. Informační systém autoškoly. Bakalářská práce. Brno: MENDELU v Brně , 2014. Bakalářská práce se zabývá informačním systémem autoškoly. Na začátku práce je popsán aktuální stav nabídky trhu na podporu procesů v autoškole. Dále je provedena objektově orientovaná analýza a návrh požadavků modelovacím jazykem UML pro vybranou autoškolu. Na závěr jsou procesy implementovány s využitím webových frameworků Nette a jQuery. Klíčová slova Informační systém, autoškola, objektově orientovaná analýza a návrh, Nette, jQuery.
Obsah
7
Obsah 1
2
Úvod a cíl práce 1.1
Úvod .........................................................................................................14
1.2
Cíl práce ...................................................................................................14
Současný stav informačních systémů a autoškol
15
2.1
Softwarové inženýrství.............................................................................15
2.2
Životní cyklus...........................................................................................16
2.2.1
Specifikace problému.......................................................................16
2.2.2
Analýza a návrh................................................................................ 17
2.2.3
Implementace ..................................................................................18
2.2.4
Testování a zavádění ........................................................................18
2.2.5
Provoz, údržba a rozvoj....................................................................19
2.3
3
14
Modely životního cyklu............................................................................19
2.3.1
Model vodopád.................................................................................19
2.3.2
Iterativní model ...............................................................................19
2.3.3
Model prototyp ............................................................................... 20
2.3.4
Model spirála .................................................................................. 20
2.4
Autoškola ................................................................................................ 20
2.5
Průzkum trhu IS pro podporu procesů autoškol ....................................21
2.5.1
ERP systémy.....................................................................................21
2.5.2
Dubensoft - Evidence autoškoly ......................................................21
2.5.3
Software pro evidenci autoškoly..................................................... 22
Metodika řešení 3.1
23
Návrhové vzory ....................................................................................... 23
3.1.1
MVC................................................................................................. 23
3.1.2
ORM a Data mapper ....................................................................... 24
3.2
Programové vybavení ............................................................................. 24
3.2.1
PHP ................................................................................................. 24
3.2.2
Javascript ........................................................................................ 25
8
4
Obsah
3.2.3
MySQL .............................................................................................25
3.2.4
HTML a CSS ....................................................................................25
3.2.5
UML ................................................................................................ 26
3.3
Nette framework..................................................................................... 26
3.4
jQuery framework................................................................................... 26
3.5
Subversion .............................................................................................. 26
Vlastní řešení 4.1
Autoškola Liška a její činnosti................................................................ 28
4.1.1 4.2
28
Současné řešení .............................................................................. 28
Vyhodnocení průzkumu trhu IS pro podporu procesů autoškol........... 29
4.2.1
ERP systémy ................................................................................... 29
4.2.2
Dubensoft - Evidence autoškoly..................................................... 29
4.2.3
Software pro evidenci autoškoly..................................................... 30
4.3
Specifikace požadavků............................................................................ 30
4.3.1
Uživatelské požadavky.................................................................... 30
4.3.2
Systémové požadavky ...................................................................... 31
4.4
Analýza a návrh .......................................................................................33
4.4.1
Autentizace a autorizace ..................................................................33
4.4.2
Úvodní obrazovka systému..............................................................34
4.4.3
Modul Osoba....................................................................................34
4.4.4
Modul výuka ....................................................................................37
4.4.5
Modul kurz.......................................................................................37
4.4.6
Modul zkouška.................................................................................39
4.4.7
Modul řidičské oprávnění............................................................... 40
4.4.8
Modul vozidlo .................................................................................. 41
4.4.9
Modul Učebna..................................................................................42
4.4.10 Diagram tříd ....................................................................................43 4.4.11
5
ER Diagram .....................................................................................43
4.5
Návrh uživatelského rozhraní .................................................................43
4.6
Implementace ..........................................................................................43
Diskuze a závěr
44
Obsah
9
5.1
Diskuze.................................................................................................... 44
5.2
Závěr ....................................................................................................... 44
6
Literatura
46
A
Obrázky - diagramy
49
B
Obrázky - návrhy uživatelského rozhraní
58
C
Tabulky - scénáře
78
10
Seznam obrázků
Seznam obrázků Obr. 1
Diagram případů užití - modul Osoba
35
Obr. 2
Diagram případů užití – modul výuka
49
Obr. 3
Diagram případů užití – modul kurz
50
Obr. 4
Diagram případů užití – modul zkouška
51
Obr. 5
Diagram případů užití – modul řidičské oprávnění
52
Obr. 6
Diagram případů užití – modul vozidlo
53
Obr. 7
Diagram případů užití – modul provozovna
53
Obr. 8
Diagram tříd
54
Obr. 9
Třída Osoba v modelové vrstvě
55
Obr. 10
E-R Diagram
56
Obr. 11
Uživatelské rozhraní - Přihlašovací stránka
58
Obr. 12
Uživatelské rozhraní - Úvodní stránka
59
Obr. 13
Uživatelské rozhraní - Moje osoba a Zobrazit osobu
60
Obr. 14
Uživatelské rozhraní - Seznam osob
61
Obr. 15
Uživatelské rozhraní - Vytvořit osobu
62
Obr. 16
Uživatelské rozhraní - Výuka
63
Obr. 17
Uživatelské rozhraní – Vytvořit hodinu.
64
Obr. 18
Uživatelské rozhraní - Zobrazit hodinu
65
Obr. 19
Uživatelské rozhraní - Seznam kurzů
65
Obr. 20
Uživatelské rozhraní - Zobrazit kurz
66
Obr. 21
Uživatelské rozhraní - Vytvořit kurz
66
Obr. 22
Uživatelské rozhraní - Upravit kurz
67
Seznam obrázků
11
Obr. 23
Uživatelské rozhraní - Seznam zkoušek
68
Obr. 24
Uživatelské rozhraní - Zobrazit zkoušku
68
Obr. 25
Uživatelské rozhraní - Upravit zkoušku
69
Obr. 26
Uživatelské rozhraní - Vytvořit zkoušku
70
Obr. 27
Uživatelské rozhraní - Vyhodnotit zkoušku
70
Obr. 28
Uživatelské rozhraní - Seznam řidičských oprávnění
71
Obr. 29
Uživatelské rozhraní - Zobrazit řidičské oprávnění
72
Obr. 30
Uživatelské rozhraní – Vytvořit řidičské oprávnění
73
Obr. 31
Uživatelské rozhraní - Seznam vozidel
74
Obr. 32
Uživatelské rozhraní - Zobrazit vozidlo
74
Obr. 33
Uživatelské rozhraní - Vytvořit vozidlo
75
Obr. 34
Uživatelské rozhraní - Seznam učeben
76
Obr. 35
Uživatelské rozhraní - Zobrazit učebnu
76
Obr. 36
Uživatelské rozhraní - Vytvořit učebnu
77
12
Seznam tabulek
Seznam tabulek Tab. 1 Scénář případu užití Zobrazit osobu
35
Tab. 2
Scénář případu užití Moje osoba
78
Tab. 3
Scénář případu užití Seznam osob
79
Tab. 4
Scénář případu užití Vytvořit osobu
79
Tab. 5
Scénář případu užití Upravit osobu
80
Tab. 6
Scénář případu užití Zobrazit výuku
81
Tab. 7
Scénář případu užití Zobrazit hodinu
81
Tab. 8
Scénář případu užití Upravit hodinu
82
Tab. 9
Scénář případu užití Vytvořit hodinu
82
Tab. 10
Scénář případu užití Zobrazit kurzy
83
Tab. 11
Scénář případu užití Zobrazit kurz
83
Tab. 12
Scénář případu užití Upravit kurz
84
Tab. 13
Scénář případu užití Vytvořit kurz
84
Tab. 14
Scénář případu užití Zobrazit zkoušky
85
Tab. 15
Scénář případu užití Zobrazit zkoušku
85
Tab. 16
Scénář případu užití Upravit zkoušku
86
Tab. 17
Scénář případu užití Vytvořit zkoušku
86
Tab. 18
Scénář případu užití Vyhodnotit zkoušku
87
Tab. 19
Scénář případu užití Zobrazit řidičská oprávnění
87
Tab. 20
Scénář případu užití Zobrazit řidičské oprávnění
88
Tab. 21
Scénář případu užití Upravit řidičské oprávnění
88
Tab. 22
Scénář případu užití Vytvořit řidičské oprávnění
89
Seznam tabulek
13
Tab. 23
Scénář případu užití Zobrazit vozidla
89
Tab. 24
Scénář případu užití Zobrazit vozidlo
90
Tab. 25
Scénář případu užití Upravit vozidlo
90
Tab. 26
Scénář případu užití Vytvořit vozidlo
91
Tab. 27
Scénář případu užití Zobrazit učebny
91
Tab. 28
Scénář případu užití Zobrazit učebnu
92
Tab. 29
Scénář případu užití Upravit učebnu
92
Tab. 30
Scénář případu užití Vytvořit učebnu
93
14
Úvod a cíl práce
1 Úvod a cíl práce 1.1
Úvod
V 21. stolení jsou již informační a komunikační technologie na poměrně vysokém stupni vývoje a společnost se na nich stává prakticky závislá. Pronikly do všech oblastí společenského života, ale především jsou nepostradatelné v hospodářské činnosti jakékoliv organizace. Každý podnik, který doposud takovýchto technologií nevyužívá, se připravuje o konkurenceschopnost. Ale nejen to, díky ICT jsou papírové dokumenty nahrazovány elektronickými, otevírají se nové prodejní a komunikační kanály, dochází ke sjednocování podnikových procesů mezi jednotlivými pobočkami, je ulehčen rozhodovací proces na strategické úrovni, více jsou využívány mobilní služby a stále častěji se provádějí online informační toky. Dnes je na trhu velká nabídka informačních systémů. Některé z nich jsou specializované na konkrétní typy podnikání, další se zaměřují jen na vybrané procesy, které musí provádět každá organizace jako je například účetnictví. Dále jsou zde komplexní integrované systémy, které se snaží pokrýt co největší část všech podnikových procesů bez ohledu na zaměření společnosti. Problém nastává u menších až středních podnikatelů, kteří podnikají ve specifické oblasti a svoje procesy provádí jedinečně. Těmto podnikatelům nepomohou komplexní informační systémy, ale také si nemohou dovolit systémy již specializované, které by si museli nechat upravit „na míru“. Toto je případ autoškol. Na trhu je dostupné omezené množství informačních systémů pro tento typ podnikání. Ovšem každá autoškola provádí svou činnost specificky. Ne každý poskytovatel je ochoten upravovat systém na požadavky konkrétní autoškoly, nebo jsou tyto úpravy pro malé autoškoly příliš nákladné.
1.2 Cíl práce Hlavním cílem práce je vytvořit informační systém pro konkrétní autoškolu. Pro vybranou autoškolu je vhodné prozkoumat současný stav informačních toků a procesů. U autoškoly zjistit hlavní nedostatky současného stavu a identifikovat možné příležitosti na zlepšení. Z těchto skutečností popsat a analyzovat specifické požadavky na podporu jednotlivých procesů. Zpracovat tyto požadavky a navrhnout přijatelné řešení vhodně zvoleným přístupem. Toto řešení informačního systému implementovat v podobě webové aplikace za pomocí moderních webových technologií. Zvolené metody a technologie zdůvodnit a případně uvést alternativní možnosti. Dílčím cílem této práce je se seznámit s nabídkou na trhu informačních systémů pro kontrolu rozhodování a podporu procesů autoškol. Také zohlednit nabídku na trhu ERP informačních systémů. Analyzovat jednotlivé nabídky a konzultovat je se zaměstnanci autoškoly, uvést jejich klady a zápory.
Současný stav informačních systémů a autoškol
15
2 Současný stav informačních systémů a autoškol Informace je nehmotná a představuje to, co je vnímáno člověkem, to, co si člověk vyměňuje s okolním světem. Z toho lze usuzovat o široce vymezeném pojmu informace, nicméně jej lze v obecné rovině chápat ve smyslu sdělování nějaké zprávy, poznatku, události či jevu. Informace jsou tedy data s určitým významem, ovšem informace vzniká z dat až v okamžiku jejich užití. Teorie informace nám říká: „Informace je zpráva, která nám upřesňuje určitá fakta o jevech nebo objektech reálného světa. Její množství je vyjadřováno mírou neurčitosti, kterou zpráva odstraní, a vyjadřuje se v bitech“. Systém je blízký pojmům jako je organismus, organizace, struktura, sjednocení. Je používán pro označení části reálného světa s charakteristickými vlastnostmi. Je složen z množiny účelově definovaných prvků a vazeb mezi nimi, jež jako celek plní určitou funkci. Systém může být umělý, vytvořený člověkem nebo přirozený, který vznikl nezávisle na člověku. Tvrdíková. Existuje celá řada definic informačního systému. V této práci je informační systém chápan ve smyslu podnikového informačního systému tak, jak jej definoval Sodomka: „Podnikový informační systém vytvářejí lidé, kteří prostřednictvím dostupných technologických prostředků a stanovené metodologie zpracovávají podniková data a vytvářejí z nich informační a znalostní bázi organizace sloužící k řízení podnikových procesů, manažerskému rozhodování a správě podnikové agendy“. [1]
2.1 Softwarové inženýrství Softwarové inženýrství je pojem, který se poprvé začal objevovat na přelomu 60. a 70. let. Do té doby se počítačové programy vytvářely těžkopádně a cílem vývoje byl spíše výsledek než funkčnost programu. Mezi programátory a zákazníky nikdo nestál. Toto velice často vedlo k nedorozuměním a nepochopením na obou stranách. V případě stížností ze strany zákazníka byl takovýto zákazník označen za neznalého. Na konci 70. let začíná vznikat Softwarové inženýrství jako obor. Softwarové firmy již mají týmy lidí specializované na jednotlivé stádia vývoje programu, vznikají také různé techniky vývoje softwaru. Rozvoj v 80. letech vedl ke konečnému uznání softwarového inženýrství jako oboru roku 1997 certifikátem v USA. [2] Softwarové inženýrství se může považovat za inženýrskou disciplínu zabývající se praktickými problémy vývoje rozsáhlých softwarových systémů a vyznačuje se několika základními principy. • Princip abstrakce a modelování. Hlavním důvodem abstrakce a modelování je snaha rozdělit zkoumanou problematiku na menší, lépe uchopitelné části. Ale také jde o pohled na data a funkce bez uvažování o technologických aspektech.
16
Současný stav informačních systémů a autoškol
• Princip iterace. Vývoj se řeší po menších částech, vše má svůj čas a je rozděleno finančně i personálně. • Princip strukturování. Problematika je strukturovaná do částí podle použité metodiky vývoje. • Princip životního cyklu. Celý vývoj programového díla je přísně podřízen po sobě jdoucím etapám, které jsou dodržovány. • Princip automatizace. Snahou vývojářů je podpořit každou etapu z životního cyklu softwarem, který by ulehčil, ale hlavně urychlil vývoj. [3] Dobrý softwarový produkt by měl po vývoji a předání zákazníkovi splňovat určité charakteristiky. Nejdůležitější vlastností je udržovatelnost. Prostředí zákazníka je dynamické a prochází neustálým vývojem, stejně tak jeho požadavky na daný produkt. Software musí být dobře napsaný, aby bylo možné jej lehce změnit podle požadavků zákazníka. Na základě rozsahu programového díla a množství dat, s kterými pracuje, je důležité dát zvýšenou pozornost na výkonnost. Velký a datově obsáhlý software může spotřebovat obrovské množství paměti a výpočetního výkonu. Software musí být spolehlivý. Ať už se jedná o stabilitu softwaru za chodu nebo otázku jeho bezpečnosti. V případě chyby nesmí způsobit žádné ekonomické škody. Software má svého uživatele, ke kterému musí být přizpůsoben. Měl by mít adekvátní dokumentaci a pro uživatele vhodné uživatelské rozhraní. [3]
2.2 Životní cyklus Životní cyklus zachycuje v softwarovém inženýrství průběh a různé etapy vývoje programového díla. Postupně prochází od prvního impulsu, nápadu na zdokonalení konkrétního procesu s využitím IS/ICT v podniku přes analýzu a návrh až po likvidaci a nahrazení za jiný produkt. Jednotlivé etapy cyklu jsou popsány níže. 2.2.1
Specifikace problému
Součástí úvodní etapy životního cyklu vývoje informačního systému je analýza současného stavu procesů v podniku a nalezení nedostatků jejich aktuálního řešení. K hrubému návrhu odstranění zjištěných nedostatků slouží výstupní dokument této etapy. Dokument odhaduje celkové náklady a přínos pro podnik, ale především stanovuje uživatelské a systémové specifikace, které blíže popisují požadavky na informační systém. Uživatelská specifikace obsahuje zadání od zákazníka. Jedná se pouze o stručný popis požadovaného systému, především problémové domény a možných rizik. Systémovou specifikaci již vytváří odběratel většinou spolu s dodavatelem. Především se zaměřují na funkční a mimofunkční požadavky. Funkční požadavky představují to, co by měl systém umět. Mimofunkční požadavky definují od-
Současný stav informačních systémů a autoškol
17
povědi na otázky typu datum dodání, spolehlivost, dostupnost, bezpečnost, rozšiřitelnost a všechny další možné otázky netýkající se přímo funkcionality systému, ale jeho vnějšího okolí. Na závěr, po vytvoření dokumentu, je nutné ověřit úplnost, konzistentnost a reálnost požadavků. Chyby, které se v této fázi neodhalí, se později odstraňují velice obtížně a za velkých nákladů. [2] [3] 2.2.2
Analýza a návrh
V průběhu vývoje softwarového inženýrství se vyvinuly dva zcela odlišné přístupy k analýze a návrhu. Jedná se o strukturovaný přístup následovaný objektově orientovaným přístupem. I přes rozdílnost přístupů má každý z nich za úkol zpracování a detailní rozepsání výstupního dokumentu z předcházející etapy. Jsou vytvářeny různé modely systému složené z diagramů a jejich podrobných popisů. Především se jedná o návrhy funkcí a datových struktur, ale také o návrh grafického uživatelského rozhraní. Zatímco analýza se zabývá spíše abstraktním zpracováním požadavků, návrh již bere v potaz technologické aspekty. • Strukturovaný přístup Jde o starší z přístupů, který je založen na čtyřech typech modelů. Všechny modely budou postupně popsány. Funkční model je reprezentován diagramem datových toků. Slouží k postupnému rozkladu, přesněji dekompozici, složitých podnikových procesů na procesy jednodušší a dále až k procesům elementárním. K popisu těchto rozkladů používá terminátory, procesy, datové toky a datastory. Terminátor je externí entita pracující se systémem. Proces transformuje ze vstupů výstupy. Datový tok se stará o přesun dat z jednoho místa v systému do druhého. Datastory ukládají používaná data. Diagram datových toků je využit i při modelování kontextového digramu. Kontextový diagram představuje model vnějšího chování systému. Popisuje vstupy, výstupy systému a elementy, které přichází se systémem do interakce. Datový model je zastoupen diagramem entit a jejich vztahů. Entita je většinou vytvářena z reálně existujících objektů, které mohou být zastoupeny čímkoliv. Každá entita má vlastnosti nazývané atributy. Atributy mohou být různých datových typů, ale také mohou mít funkci primárního, nebo cizího klíče. Mezi entitami existují vztahy. Kardinalita udává násobnost vztahů mezi dvěma entitami. Parcialita naznačuje povinnost, nebo volitelnost těchto vztahů. Časově závislé chování systému modeluje model řízení. Základem je stavový diagram, kterým jsou popisovány především systémy pracující v reálném čase. [3] • Objektově orientovaný přístup Místo dat a funkcí se nyní do centra pozornosti dostává objekt, abstrakce reality. Je základní stavební prvek objektově orientovaného přístupu. Každý
18
Současný stav informačních systémů a autoškol
objekt obsahuje atributy, ke kterým je zprostředkován přístup pouze přes metody daného objektu. Toto ukrývání vlastností objektu se nazývá zapouzdření. Každý objekt je instancí třídy, která definuje společnou množinu vlastností, které jsou společné objektům ze stejné třídy. Objekt se vyznačuje jednoznačnou identitou v rámci třídy, aktuálním stavem a chováním. Chování objektu může voláním metod měnit jeho stav, tedy hodnoty atributů, nebo může tímto způsobem komunikovat s dalšími objekty. Třída je seskupením objektů se stejnými vlastnostmi. Dalšími důležitými pojmy jsou polymorfismus a dědičnost. Polymorfismus umožňuje mít objektům z různých tříd metodu se stejným názvem, ale s rozdílným chováním. Oproti tomu dědičnost je vlastnost tříd. Potomek, třída, která dědí, obsahuje vlastnosti a chování předka třídy, z které je děděno. Objektově orientovaný přístup využívá k analýze a návrhu jazyka UML. UML definuje různé digramy pro analýzu a návrh statické, případně dynamické části systému. Pro popis jednotlivých diagramů není v této práci prostor, avšak samotnému UML bude věnována jedna z následujících kapitol. [4] 2.2.3
Implementace
Podklady k implementaci jsou dodány z předchozí etapy a tato část se zabývá již pouze vlastním implementováním jednotlivých funkcionalit zvoleným programovým vybavením. Jednotlivé moduly mohou být implementovány přímo nebo jsou používány nástroje typu CASE (Computer Aided Software Engineering), které automaticky generují základní kostru systému z návrhu. Ta obsahuje veškeré definované prvky a v mnoha případech stačí programátorovi dodělat detaily jednotlivých funkcí. Spolu s vytvářeným kódem vzniká programátorská dokumentace, ale i uživatelská příručka, která slouží ke školení uživatelů. V této fázi jsou vytvářeny databáze a připravovány testovací data. Zároveň jsou zpracovávány materiály, sloužící pro naplnění databáze reálnými daty. [2] [3] 2.2.4
Testování a zavádění
Testování je klíčovou fází, kdy se zkoumá, zda systém odpovídá zadané specifikaci a chová se podle očekávání zákazníka. To zahrnuje inspekci a kontrolu všech procesů, které systém realizuje. Testování probíhá v několika krocích. Prvním krokem je testování jednotlivých komponent k ověření jejich správného chování. Komponenty by měly být testovány bez ohledu na ostatní části systému. Systémové testování. Spojené komponenty dohromady tvoří celý systém. Tento krok je zaměřen na hledání chyb vzniklých z komunikace mezi jednotli-
Současný stav informačních systémů a autoškol
19
vými komponentami. Pro velké a složité systémy lze systémové testování ještě rozdělit do několika subsystémů. Testování přístupnosti je závěrečný krok, před tím než je systém zaváděn do provozu. Jedná se o testování nad reálnými daty poskytnuté zákazníkem. Toto testování by mělo odhalit chyby vytvořené při zpracovávání zadání systému. Po testování se systém připravuje na zavedení do provozu, instalují se podpůrné systémy a školí se uživatelé. Zavedení systému by mělo být rychlé a bezproblémové. I tak je vhodné nechat nový systém nějakou dobu koexistovat se současným řešením. [2] [3] 2.2.5
Provoz, údržba a rozvoj
Závěrečný cyklus je nejdelší fází životního cyklu informačního systému a ačkoliv to není na první pohled zřejmé, je i nejnákladnější. V poslední době se potřeby zákazníka vyvíjí velice dynamicky a tyto potřeby je nutné rychle promítnout do změny systému. Cílem tedy je zajištění bezproblémového chodu systému, průběžné aktualizace komponent na základě uživatelských zkušeností nebo objevení chybového chování a jeho oprava. S těmito změnami je spojená aktualizace dokumentace a případné přeškolení uživatelů. [2]
2.3 Modely životního cyklu V praxi máme velké množství modelů životního cyklu a jejich různých kombinací, úprav a adaptací na konkrétní zadání, kterými se vyvíjí informační systémy. Každý model říká, jak máme postupovat vývojovými etapami, a právě v tomhle je jejich rozdíl. V následujících podkapitolách budou vybrané modely popsány blíže. 2.3.1
Model vodopád
Vůbec první publikovaný model životního cyklu informačního systému. Princip modelu spočívá v postupu z jedné fáze do druhé. Následující fáze nemůže začít dříve, než je předchozí fáze dokončena, zkontrolována a odsouhlasena. S výstupy z předchozí fáze pracuje fáze následující. Při provádění jedné fáze se může nalézt chyba ze zadání z předchozí fáze. V tomto případě probíhá iterace o jednu fázi zpět k odstranění nalezené chyby. Tento postup se uplatňuje na předem jasně známé problémy a způsob jejich řešení. Pokud se žádné problémy nevyskytnou, je tento způsob velice rychlý a levný, ovšem pouze zřídka využívaný. Odběratel málokdy zná přesně své požadavky předem nebo je systém příliš komplikovaný. [2] 2.3.2
Iterativní model
Jak název napovídá tento model je založen na iteracích, ale také na aktivní účasti zadavatele. Každá iterace představuje průchod analýzou, návrhem a implementací systému. Po dokončení iterace jsou sepsány připomínky a nové poža-
20
Současný stav informačních systémů a autoškol
davky odběratele a začíná další iterace, která zahrne nové požadavky do stávajícího systému. Verze, na kterou již nemá odběratel požadavky, se stává verzí finální a je zaváděna jako hotový systém. Tento model je schopen reflektovat vyvíjející se požadavky odběratele v průběhu vývoje. Jestliže je systém vyvíjen rychle, je finančně nákladné pokrývat tvoření dokumentace ke každé verzi. Průběžné dodělávání změn má také tendenci nabourávat strukturu systému. [2] 2.3.3
Model prototyp
Prototyp představuje pouze část z celkového systému a nemusí být ani plně funkční. Můžeme mít prototypy představující návrh uživatelského rozhraní, předvádějící chování na různé vstupy do systému, ukazující strukturu systému na subsystémy a podobně. Základem je vždy co nejrychlejší vývoj prototypu a jeho představení odběrateli. Po vyhodnocení prototypu odběratelem následuje jeho vylepšení a iterace se opakuje dokud není odběratel s prototypem spokojen. Po získání finálního prototypu teprve začíná samotný vývoj systému, který prochází specifikací, návrhem a implementací. Nutno dodat, že samotný prototyp není při dalším vývoji systému použit. Reálně se dá tento postup uplatnit pouze u menších systémů. [3] 2.3.4
Model spirála
Tento model představuje mezník k přístupu vývoje softwaru. Může částečně využívat některých výše zmíněných modelů a představuje tak jejich kombinaci. Spíše než sekvenci po sobě jdoucích fází se zpětnou vazbou je postup vývoje reprezentován spirálou. Každá smyčka ve spirále reprezentuje jednu fázi z životního cyklu. Nejvnitřnější smyčka je reprezentována specifikací problému, další analýzou systému a tak dále. Jednotlivé smyčky jsou rozděleny do čtyř sektorů. V prvním jsou stanoveny specifické cíle řešené etapy, je identifikováno omezení jednotlivých procesů a jsou stanoveny rizika. V druhém sektoru jsou stanovená rizika detailněji analyzována a jsou podstoupeny kroky k jejich redukci například vytvořením prototypu. Po omezení rizik přichází na řadu realizace prováděné etapy a její kontrola dokud neodpovídá požadavkům. V posledním kroku je prováděno plánování pro další fázi. [2]
2.4 Autoškola Autoškola je vzdělávací instituce reprezentována právnickou nebo fyzickou osobou. K vykonávání této specifické činnosti je nutné povolení od státních úřadů. Autoškola připravuje studenty ke zkouškám potřebným k získání řidičského oprávnění nebo k jeho rozšíření. Autoškola poskytuje teoretickou a praktickou výuku. Teoretická výuka představuje docházku do učebny, třídy nebo specializované místnosti. Zde je uchazečům přednášena problematika řízení motorových vozidel. Součást teore-
Současný stav informačních systémů a autoškol
21
tické výuky jsou také testy na nečisto. Praktická výuka začíná na trenažérech, cvičištích nebo málo frekventovaných komunikacích. Končí jízdami za plného provozu. V osobních a nákladních automobilech sedí instruktor vedle studenta, oproti motocyklům, kde sedí instruktor přímo za studentem. V obou případech má instruktor možnost vstoupit do řízení pomocí zdvojeného řízení. Pro úspěšné absolvování autoškoly musí student složit sérii závěrečných testů. První je zkouška z předpisů o provozu na pozemních komunikacích a zdravotnické přípravy formou testu na osobním počítači. Jako další následuje zkouška z praktické jízdy. Poslední je zkouška ze znalostí ovládání a údržby vozidla ústní formou. Na všechny zkoušky dohlíží zkušební komisař, který je pověřen obcí s rozšířenou působností. Řidičské oprávnění pro motorová vozidla se osvědčuje řidičským průkazem. [5]
2.5 Průzkum trhu IS pro podporu procesů autoškol 2.5.1
ERP systémy
Využitím ERP systémů dostupných na trhu je jedno z možných řešení, jak přistoupit k pokrytí činností autoškoly. Společnosti poskytující ERP systémy se většinou zaměřují na podporu výroby, logistiky, distribuce, prodeje nebo účetnictví. Jsou ochotny moduly upravovat podle přání zákazníka, ale většinou jen v omezené míře. Jedním z mnoha produktů je ERP systém Helios Red, který je určen pro malé a střední firmy. Tento ERP nabízí širokou škálu modulů. Mezi moduly použitelné v autoškole patří především kniha jízd, evidence zákazníků s bankovním spojením nebo modul účetnictví. Samotné jádro systému Helois Red je zdarma. Ovšem celková cena uvedených modulů je kolem 23 300 Kč, kde není započítána práce na zavedení systému nebo případné přeprogramování funkcionalit. Za hodinu práce je požadováno dalších 1 400 Kč. Jsou zde další alternativy jako jsou například ERP systémy Abra G2 nebo NET Genium ERP, které ovšem nabídkou i cenou odpovídají systému Helios Red. [6] Pro podporu speciálních činností autoškoly tímto způsobem je nutné využití dalších systémů jako je Moderní autoškola. Moderní autoškola v podobě webové aplikace nabízí plánování výuky ze strany zaměstnanců autoškoly a přihlašovaní ze strany studentů. Tento šikovný systém nabízí pouze tuto funkcionalitu. Jednorázová cena je 9 500 Kč se školením zaměstnanců, zavedením systému a telefonickou podporou. Provozní poplatek je pak stanoven na 250 Kč za každý měsíc. [7] 2.5.2
Dubensoft - Evidence autoškoly
První systém přímo specializovaný na podporů činností autoškol je Dubensoft. Systém je realizován v podobě desktopové aplikace a slouží k vedení kompletní agendy autoškoly. Zprostředkovává vedení vozidel, učitelů, žáků, kurzů a zkoušek. Pro vozidla poskytuje knihy jízd. Taktéž poskytuje možnost vést záznamy
22
Současný stav informačních systémů a autoškol
docházky žáků na praktickou i teoretickou výuku. Obsahuje funkcionalitu pro generování dokumentů k zahajování kurzů a k přihlašování studentů na zkoušky. Software umožňuje zadávání dat různými způsoby. Praktickou výuku lze zadávat jako seznam jízd žáka na vozidlech nebo jako seznam jízd vozidla, které řídili různí žáci. V obou případech je výsledek stejný. Velice užitečnou funkcí programu jsou jeho výstupy. Lze tisknout prakticky jakékoli informace uchovávané programem do různých datových formátů. V databázi jsou uchovány veškeré operace nad záznamy a lze si nechat zobrazit historii jejich úprav. Jednorázový poplatek za systém činí 7000 Kč. [8] 2.5.3
Software pro evidenci autoškoly
Software pro evidenci autoškoly je poskytován provozovatelem v podobě softwaru jako služby. Není potřeba instalovat a je dostupný odkudkoliv, kde je připojení k internetu. Jsou podporovány webové prohlížeče Mozilla Firefox 2.0 a vyšší, Google Chrome, Internet Explorer 7.0 a vyšší, Safari 3.0 a vyšší. Jedním modulem systému je kniha jízd. Kniha jízd umožňuje evidovat všechny jízdy vozidel autoškoly podle typu jízdy a to na výcvikové, organizační a soukromé. Pro vedení studentů je k dispozici evidenční kniha, kde jsou vedeny i jejich platby synchronizované s bankovním účtem. Správu výuky studentů je umožněno upravovat v třídní knize. Jelikož je systém dostupný přes internet, tak poskytuje rezervační systém pro studenty. Rezervační systém je poměrně propracovaný. Umožňuje vytváření výukových šablon pro různé pracovní dny nebo zobrazení historie přihlašování jednotlivých hodin. Systém také disponuje modulem pro evidenci školení řidičů referentů s tiskem potvrzení pro zaměstnavatele. Systém v plné šíři je poskytován za 987 Kč za měsíc. [9]
Metodika řešení
23
3 Metodika řešení Ze všeho nejdříve je zapotřebí provést důkladnou analýzu vybrané autoškoly. To je popsat informační toky, procesy a veškeré činnosti, které v podniku probíhají. Následuje popis současného řešení těchto procesů. Tímto se identifikují kritické nedostatky, které je třeba řešit a zároveň se ukáží různé příležitosti ke zlepšení. Následuje průzkum trhu informačních systémů. Jsou vybrány systémy nejvíce vyhovující činnosti autoškoly. Může se jednat o systémy přímo specializované pro autoškoly nebo o systémy integrující širokou škálu funkcionalit. Tyto systémy jsou analyzovány a konzultovány se zákazníkem. V případě nenalezení uspokojivého řešení se pokračuje volbou životního cyklu pro vývoj systému vlastního. Zákazník sám nemá jasnou představu jak by měl systém vypadat, co všechno by měl umět, nebo lépe řečeno, co všechno může po systému požadovat. Tímto se předpokládá postupný vývoj, který s každou další iterací přiblíží výsledný systém požadované realitě nebo ho namíří požadovaným směrem. Zároveň je nutné zachycovat změny v zákonech. Pro realizaci informačního systému autoškoly je vhodné, v tomto případě, zvolit iterativní model vývoje, který vyhovuje všem okolnostem a je popsaný v 2.3.2. V první iteraci je vytvořena specifikace požadavků na jednoduchý systém. Jsou vedeny konzultace s pověřeným zaměstnancem autoškoly a postupně se dostává k vzájemné shodě, která vede až k následné specifikaci uživatelských požadavků. Uživatelské požadavky jsou reformulovány a sepsány do systémových požadavků. Funkční i mimofunkční systémové požadavky jsou předvedeny zákazníkovi, zákazníkem zkontrolovány a odsouhlaseny. Funkční systémové požadavky jsou rozděleny do několika základních modulů. Každý modul prochází vlastní analýzou, návrhem, implementací a testováním. Jednotlivé postupy a použité technologie při implementaci jsou popsány v následujících podkapitolách. Po představení systému zákazníkovi a po uplynutí dostatečné doby, za kterou se zákazník se systémem seznámí, je provedena druhá iterace. Iterace, která jednotlivé moduly systému přizpůsobí konkrétnějším požadavkům zákazníka a pokusí se již kompletně pokrýt podnikové procesy. Z důvodu zvolení iterativního modelu vývoje je vhodné k analýze a návrhu přistupovat objektově orientovaným přístupem uvedeným v 2.2.2. Objektově orientovaný přístup umožňuje snadnou rozšiřitelnost, oddělitelnost detailů od celku, modularitu a znovu použitelnost jednotlivých částí systému.
3.1 Návrhové vzory 3.1.1
MVC
Jedná se o jednu z nejvýznamnějších softwarových architektur pro vývoj webových aplikací. Architektura rozděluje aplikaci do tří samostatných celků (Model,
24
Metodika řešení
View, Controller). Rozdělení do celků zpřehledňuje kód, ulehčuje vývoj a umožňuje testování jednotlivých částí zvlášť. První částí je model, aplikační logika. Model reprezentuje datovou základnu aplikace. Vytváří rozhraní pro vyhledávání, vytváření, změnu a mazaní veškerých dat v systému. O existenci view nebo controlleru nemá tušení. View neboli pohled vytváří grafické rozhraní pro uživatele. Zobrazuje mu stav modelu a přijímá od něj pokyny, které předává do controlleru. Controller neboli řadič přijímá a zpracovává přes pohled požadavky od uživatele a na jejich základě volá aplikační logiku. Rozhoduje co se v daný moment bude dít a co pohled zobrazí uživateli. Na tomto vzoru je postaven Nette framework použitý pro vývoj aplikace. [10] 3.1.2
ORM a Data mapper
ORM je zkratka z anglického Object Relational Mapping. V relační databázi je entita reálného světa uchovávána jako řádek tabulky, zatímco v objektovém programování je reprezentována objektem, instancí třídy. ORM je tedy programovací technika zabezpečující mapovaní a persistenci dat mezi objektově orientovaným programovacím jazykem a relační databází. ORM také implementuje mechanismus, který do jisté míry ulehčuje programátorovi práci s SQL dotazy a umožňuje nezávislost na konkrétním databázovém systému. Mapování může probíhat různými způsoby. Jednou z používaných technik je takzvaný Data mapper. Tento způsob nabízí dostatečně flexibilní a strukturovanou modelovou vrstvu pro webovou aplikaci. Samotný Data Mapper zajišťuje spojení s úložištěm a provádění různých operací. Příkladem je vyhledávání požadovaných dat, které vrací již v podobě aplikačních objektů. Objektům zůstala pouze práce se svými vlastnostmi. Jednodušší alternativou je Active record, který spojuje práci s databází s aplikačním objektem. Tím ovšem snižuje flexibilitu aplikace. [11]
3.2 Programové vybavení 3.2.1
PHP
PHP nebo také Hypertextový preprocesor je skriptovací jazyk běžící na straně serveru. Jeho hlavním účelem je rychlý vývoj dynamicky generovaných webových stránek a aplikací, ale zvládne také konzolové a desktopové aplikace. K vývoji webových aplikací je zapotřebí tří věcí. Interpret PHP skriptu propojený s webovým serverem a webový prohlížeč. Výhody PHP jsou spojeny s jeho jednoduchostí, jeho syntaxe je velice podobná programovacímu jazyku C. Může být použit na většině dnešních operačních systémů a je podporován velkou řadou webových serverů. V posledních verzích byla zlepšena podpora objektově orientovaného přístupu. PHP rovněž poskytuje dobré spojení s databázemi a velké množství funkcí a knihoven.
Metodika řešení
25
Za nevýhodu se dá považovat nejednotné pojmenování podobných funkcí, nepřítomnost ladícího nástroje v základní distribuci, ale především se jedná o interpretovaný jazyk, neudržuje kontext mezi požadavky klienta a překládá každý požadavek znovu. Dalšími možnými jazyky pro tvorbu webových aplikací je například pro platformu .Net od Microsoftu jazyk C#. [12] 3.2.2
Javascript
Téměř většina dnešních webových stránek nebo aplikací používá Javascript. Javascript je rovněž skriptovací jazyk a je prováděn u klienta ve webovém prohlížeči. Jeho hlavním účelem je umožnit vývojáři rozhýbat jinak statický web, tedy práce s prvky grafického uživatelského rozhraní, různé animace a efekty. Za výhodu se dá považovat přesun zátěže ze serveru do prohlížeče klienta. Javascript může poskytnout různé funkce, které by byly na straně serveru proveditelné velice těžko nebo vůbec. Jako hlavní nevýhodou se jeví situace, kdy si klient Javascript v prohlížeči zakáže. V tomto případě se funkcionalita stránek závislá na Javascriptu neprovede. Na prohlížení webových stránek existuje celá řada prohlížečů a jejich verzí. Prohlížeče nemají sjednocené vyhodnocování některých příkazů a výsledek mohou zobrazit nebo provést rozdílně. Javascript nemá možnost přistupovat k souborům jak na straně serveru, tak na straně klienta. [13] 3.2.3
MySQL
S informacemi přichází požadavek na jejich ukládání a následné vyhledávání. Jednou možností je využití databázových systémů. MySQL představuje jeden z nejpoužívanějších databázových systémů vůbec. K přístupu a ukládání dat do databáze slouží MySQL server. Komunikace s databází probíhá pomocí dotazovacího jazyka SQL. MySQL představuje nenáročný, rychlý a spolehlivý databázový server. Je schopen fungovat na různých typech operačních systémů a je možné jej využít v celé řadě programovacích jazyků. Na druhou stranu MySQL nepodporuje složitější programátorské postupy a při opravdu velkém množství dat zaostává i jeho rychlost. Nabídka databázových systémů je vcelku pestrá. Za zmínku určitě stojí komerční Oracle database 12c nebo celkem rozšířené PostreSQL. [13] 3.2.4
HTML a CSS
Hypertextový značkovací jazyk, zkráceně HTML, vychází z univerzálního značkovacího jazyka SGML. Jeho hlavním účelem je strukturování obsahu webových stránek. Oproti tomu kaskádové styly, CSS, určují jakým způsobem se obsah webové stránky strukturované jazykem HTML zobrazí. Vznikly z důvodu poskytnout vývojáři možnost oddělit samotný obsah webu od jeho zobrazení. [14] [15]
26
3.2.5
Metodika řešení
UML
Jedná se o grafický jazyk pro vizualizaci návrhů systémů. Jazyk byl navržen způsobem, aby jej mohli implementovat CASE systémy. Nenabízí žádnou metodiku modelování, ale spíše pouze poskytuje vizuální syntaxi, která může být využita při sestavování modelů v průběhu celého vývojového cyklu, může být použit při modelování čehokoliv. Je vhodný pro modelování v jakémkoliv programovacím jazyce, především v objektově orientovaném, ale lze jej použít i v neobjektovém programovacím jazyce. [4]
3.3 Nette framework Nette framework ulehčuje vývoj webových aplikací. Je založen na skriptovacím jazyku PHP 5. Místem původu je České republika a jako český projekt se může těšit velké domácí komunitě vývojářů. Jeho hlavní předností je důraz na bezpečnost. O eliminování bezpečnostních rizik se stará framework sám. Má čistý objektový návrh. Jako mladý framework používá moderních technologií, návrhových vzorů a praktik. Příkladem může návrhový vzor MVC, používání technologie AJAX a dalších. Jelikož samotné PHP postrádá nástroje pro hledání chyb, přichází Nette s vlastními ladícími nástroji. Umožňuje přehledně formátovaný výpis chyb, případně proměnných, ukládání chyb do souboru a měření času mezi jednotlivými operacemi. Dalšími frameworky postavenými na PHP 5 pro vývoj webových aplikací jsou například Zend nebo Symphony. [16]
3.4 jQuery framework Hlavním cílem jQuery je ulehčit používání Javascriptu. Jinými slovy je jQuery Javascriptový framework. Jeho mottem je: „Napiš méně, udělej více“. Snaží se obecné postupy, které potřebují v Javascriptu někdy i několik desítek řádků kódu vtěsnat do řádku jediného a vývojáři ulehčit, zpřehlednit, ale hlavně ušetřit práci. Použití jQuery frameworku spočívá v procházení, manipulaci, odchytávání událostí a animaci grafických prvků nad HTML dokumentem. Také zjednodušuje práci s technologií AJAX a dokáže manipulovat s kaskádovými styly. I přes rozdíly v interpretaci Javascriptového kódu v různých webových prohlížečích, je jQuery ve všech hlavních prohlížečích použitelné. Jedinou výjimkou je Internet Explorer 6. [17]
3.5 Subversion Subversion zkráceně SVN nebo volně přeloženo systém pro verzování zdrojových kódů. Představuje užitečný nástroj pro každý vývojový tým, ale ocení ho i jednotlivec.
Metodika řešení
27
Hlavní částí verzovacího systému je repositář, který reprezentuje centrální úložiště projektu, tedy místo kam se nahrávají nově dopsané nebo opravené části kódu. Většinou je umístěn na serveru, ale lze jej zprovoznit i na lokálním počítači. Programátor má u sebe pracovní kopii, v které provádí veškeré změny a po dokončení je nahrává spolu s komentářem do centrálního úložiště. Systém sám hlídá verzování a v případě změny stejného kódu dvěma programátory je upozorní a vyžádá si opravu vzniklého stavu. Programátor má možnost si aktualizovat svoji pracovní kopii. Při každém nahrání kódu do repositáře vzniká nová revize projektu. Projekt se dělí na do různých větví. Nejdůležitější je vývojová a produkční větev. Výhodou z dodržování toho postupu je možnost dostat zpět jakoukoliv revizi i s komentářem, ale především usnadnění týmového vývoje jakýchkoliv programového díla. Alternativním verzovacím nástrojem je GitHub, který je zdarma pouze pro takzvané „open source“ projekty. [18]
28
Vlastní řešení
4 Vlastní řešení 4.1 Autoškola Liška a její činnosti Provozovatel autoškoly je Jiří Liška. Autoškola je vedena jako živnost od roku 1998. Nabízí širokou škálu služeb: 1. 2. 3. 4.
výcvik k získání nebo rozšíření skupin řidičského oprávnění A, B, C ,D ,E ,T provedení zkoušky z odborné způsobilosti k navrácení řidičského oprávnění akreditované školení řidičů školení řidičů referentů
5.
kondiční jízdy
Základní časovou jednotkou pro veškeré činnosti v autoškole spojené s výcvikem k získání skupin řidičského oprávnění nebo jejich rozšíření je období kurzu. Každému kurzu vede třídní knihu, která obsahuje seznam studentů a zaznamenává přehled o prováděné výuce. Autoškola oznamuje zahájení nových kurzů na příslušném úřadě zasláním zahajovacího dokumentu. K přihlašování studentů na závěrečné zkoušky autoškola vytváří dokument ve speciálním formátu. Do dokumentu uvádí seznam studentů, vozidlo a posílá jej opět na příslušný úřad. Až v momentě, kdy všichni studenti úspěšně splní závěrečnou zkoušku nebo odstoupí z kurzu, autoškola daný kurz uzavírá a archivuje. Do třídní knihy eviduje studentům docházku na praktickou i teoretickou výuku. V případě praktické výuky autoškola eviduje použité vozidlo. Autoškola rovněž plánuje rozvrh jízd pro kurzy s aktivními studenty a pro jim potřebná vozidla. Uskutečněné jízdy studentem na daném vozidle za jeden den vede v knize jízd. Pro každé vozidlo vytváří speciální kartu vozidla. Naopak k evidenci studentů postačuje přehled vytvořený v třídní knize. Autoškola vede účetnictví. Zaznamenává inkasované platby ze strany studentů a vydává k nim daňové doklady. Autoškola eviduje různé výdaje. Výdaje na provoz a údržbu vozidel, přívěsů, výukových prostor nebo výplaty zaměstnancům. Pro autoškolu je klíčová komunikace s veřejností. Autoškola umožňuje veřejnosti přístup k různým dokumentům. Také poskytuje upozornění na nadcházející kurzy, akreditované školení řidičů, školení řidičů referentů nebo kondiční jízdy. 4.1.1
Současné řešení
V současné době autoškola využívá k podpoře svých procesů širokou paletu různých nástrojů. Od specializovaného softwaru, přes podpůrné programy z balíku Microsoft Office, až po dokumenty v papírové podobě. O aktuálnost dat v nástrojích se stará administrativní pracovník.
Vlastní řešení
29
Třídní kniha je pro každý kurz vedena jako samostatný soubor typu Microsoft Excel. Zde eviduje seznam všech studentů přihlášených na daný kurz, informace o studentech a jejich docházku na výuku. Výuka je do souboru třídní knihy zapisována v různých časových intervalech z knihy jízd. Kniha jízd je dokument v papírové formě. Je vytvářena pro konkrétní vozidlo na daný den. Kniha jízd je vyplňována učitelem. Kurzy a zkoušky jsou vytvářeny a vedeny v systému Dubensoft. Systém je také využit ke generování úřadem definovaným dokumentům. Pouze potřebná data pro generování dokumentů ke kurzům a zkouškám zadává do systému administrativní pracovník z třídní knihy. Na tomto místě dochází k duplicitě vedených dat. Pro plánování jízd slouží poněkud nepraktický offline systém využívající soubory typu Microsoft Word. Studenti mohou tento soubor najít na webových stránkách autoškoly. Na jízdy se přihlašují na teoretické výuce nebo přes telefonní kontakt s odpovědným pracovníkem, který je zapíše na hodinu v souboru a aktualizuje jej na webových stránkách. Pro každé motorové vozidlo a přívěs je vytvořena karta vozidla. Karta je reprezentována papírovým dokumentem, který postačuje na vedení potřebných informací. Veškeré účetnictví je periodicky zpracováváno externí firmou a fakturace je prováděna opět za pomoci souboru typu Microsoft Word. Hlavním kanálem pro komunikaci s veřejností slouží webová prezentace. Zde autoškola poskytuje dokumenty ke stažení. Příkladem je posudek o zdravotní způsobilosti nebo žádost o přijetí k výuce a výcviku. Dokumenty jsou připraveny k odebrání na pobočce autoškoly. Nakonec jsou předávány ke zpracování pracovníkům autoškoly. Webová prezentace také slouží k upozornění na blížící se kurzy a ostatní akce. Tyto akce jsou také oznamovány pomocí plakátů na obecních nástěnkách.
4.2 Vyhodnocení průzkumu trhu IS pro podporu procesů autoškol 4.2.1
ERP systémy
Pro malou živnost, jakou je autoškola Liška, je nutné se zaměřit na výběr ERP systému pro malé nebo střední podniky. Kombinace těchto produktů zajistí do jisté míry pokrytí podnikových procesů. Ovšem celková cena při nejmenším přesahující 30 000 Kč je jediným rozhodujícím faktorem pro neuskutečnění této varianty řešení. 4.2.2
Dubensoft - Evidence autoškoly
Dubensoft je v malé míře autoškolou Liška používán. Ovšem desktopová aplikace s sebou přináší některá omezení. Udržovat aktuální data je možné pro více uživatelů, ale pouze v instalaci systému na jednom počítači. V systému je ekviva-
30
Vlastní řešení
lent třídní knihy, knihy vozidel i dalších funkcionalit pro vedení různých záznamů. Přesto je využíván pouze pro kurzy a zkoušky, u kterých nemá autoškola jinou možnost. Možnost zadávat data více způsoby na různých místech způsobuje nepřehledné ovládání a ztrátu orientace v systému. Systém taktéž neposkytuje jakoukoliv možnost přihlašování na výuku ze strany studentů. Některé drobné, některé závažnější nedostatky vedou autoškolu k rozhodnutí o ukončení používání tohoto systému a hledání vhodné alternativy. 4.2.3
Software pro evidenci autoškoly
Představená funkcionalita pokrývá téměř veškeré činnosti v autoškole Liška. I přesto není zákazník s softwarem pro evidenci autoškol plně spokojen. V každém modulu se nachází funkčnost, kterou je autoškola zvyklá provádět rozdílným způsobem. Příkladem může být vedení jízd v kilometrech a ne v čase. Rozdělení typu jízd na výcvikové, organizační a soukromé také nesplňuje požadovanou představu. Pokud by se autoškola pro tento systém rozhodla, byly by nutné finančně nákladné úpravy na míru, které není ochotna akceptovat.
4.3 Specifikace požadavků Z aktuální nabídky trhu si zákazník nevybral žádný systém, který by splňoval jeho požadavky do uspokojivé míry. A jelikož je současné řešení zákazníkovy nevyhovující a nedostatečné, je nutné se zaměřit na přípravu kompletně nového způsobu řízení podnikových procesů. 4.3.1
Uživatelské požadavky
Prvním rozkládaným procesem, který je pro autoškolu typický, je výuka. Výuka se skládá ze dvou typů, praktické jízdy a teoretické přednášky. Praktické jízdy mohou být za různého stupně provozu, případně trenažér nebo cvičiště. Teoretická část se skládá z obecné teorie, technické teorie a zdravotnické přednášky. Výuka probíhá v některé z provozoven a jízdy na vybraném typu vozidla s vybraným učitelem. Každá jízda nebo přednáška trvá jednu a půl hodiny. Hodin je během dne osm. Jednotlivé hodiny jsou postupně v rozmezí od 07:00 do 08:30, od 08:30 do 10:00, od 10:00 do 11:30, 11:30 do 13:00, následované hodinovou pauzou, poté od 14:00: do 15:30, od 15:30 do 17:00, od 17:00 do 18:30 a poslední od 18:30 do 20:00. Počet povinných hodin jednotlivých typů k úspěšnému absolvování výuky udává řidičské oprávnění, na které student podal přihlášku. Na jednotlivé hodiny výuky zapisuje studenta pouze vedoucí, ale student musí mít přehled, na kdy a s jakým učitelem se může zapsat. Každý učitel má možnost vypsat své hodiny, kdy může jezdit, a vybrat z dostupného typu vozidla. U hodiny je nutné mít možnost zadat textovou poznámku. Přednášky jsou vytvářeny vedoucím. Vedoucí také může vytvářet jízdy pro vybrané učitele. Pro každého studenta se eviduje účast na obou typech výuky, docházku jednotlivých studentů zapisuje opět pouze vedoucí a to v třídní knize. Vedoucí má možnost hodinu uznat, nebo neuznat v případě, že hodina neproběhne.
Vlastní řešení
31
Procesem, na který čeká každý student autoškoly, jsou závěrečné zkoušky. Zkoušky se skládají ze tří částí, kterými jsou teoretický, technický test a praktické jízdy. Pro zdárné ukončení musí student úspěšně složit všechny tři části. Zkoušky jsou vypisovány dopravním úřadem, ovšem je pouze na dané autoškole, které studenty ke zkouškám přihlásí. Pro přihlášení studentů ke zkouškám na úřadu je nutné vytvoření dokumentu ve speciálním formátu, který se generuje na základě probíhajících kurzů. Další procesy, které je potřeba podpořit informačním systémem, se týkají převážně evidence. Nejdůležitější evidencí je evidence kurzů. U každého kurzu se zaznamenává datum zahájení, datum ukončení, vedoucí kurzu a studenti přiřazení do kurzu. Kurz se může ukončit až poté, co budou mít všichni studenti absolvované závěrečné zkoušky. Kurz má evidenční číslo ve tvaru pořadové číslo kurzu v roce lomeno rok. Každý student může patřit pouze do jednoho aktivního kurzu. Studentům je nutné, jako u kurzu, generovat evidenční číslo ve tvaru pořadové číslo studenta v roce lomeno rok, dále zaznamenávat jméno, příjmení, rodné číslo, adresu, telefon, e-mail, datum narození a případně již dosažené řidičské oprávnění. Každému studentovi je možno zadávat platbu případně platby a datum, kdy tyto platby proběhly. V případě učitele je nutné sledovat, zda je učitel aktivní či nikoliv, podle toho mu umožňovat vytvářet jízdy. Aktivní, neaktivní status se sleduje i u studenta, kdy student přejde do stavu neaktivní po úspěšném splnění závěrečné zkoušky a nebude ho možné nadále přihlašovat na výuku. Pro vozidla je třeba evidovat SPZ, barvu, značku, typ vozidla a v jakém stavu se momentálně nachází, tedy aktivní, neaktivní, na opravě, nebo vyřazeno. Typ vozidla může být motocykl, osobní, nebo nákladní automobil, autobus, traktor a přívěs. U provozoven zaznamenáváme adresu a kapacitu volných míst pro teoretickou výuku. Je vhodné mít možnost vytvářet různé typy řidičských oprávnění. Podle toho, které řidičské oprávnění přihlašující se student již vlastní, a které se chystá získat, se vypočítává minimální počet potřebných hodin k výuce, z čehož se následně vypočítává cena kurzu pro studenta. Všechny tyto evidenční změny má na starost pouze vedoucí. Účetnictví je zaběhlé a doposud s ním nebyly žádné problémy, v tomto procesu tedy není nutné dělat žádné změny. Účetnictví bude i nadále provozováno externí firmou. 4.3.2
Systémové požadavky
Z dostupných informací z uživatelských požadavků jsou vypracovány funkční a mimofunkční požadavky. Na některé požadavky je pohlíženo více obecně než plyne ze zadání z důvodu možného nasazení systému i u jiných autoškol: • Funkční požadavky: Než je započat popisu jednotlivých funkcionalit, je nutné stanovit skupiny uživatelů, kteří mohou se systémem pracovat. Na základě neformální speci-
32
Vlastní řešení
fikace jsou definovány tři skupiny uživatelů a to student, zaměstnanec, někdy také v určitém kontextu uveden pod názvem učitel a vedoucí. Rozdělení do skupin uživatelů je důležité z hlediska jejich oprávnění k jednotlivým operacím v systému. Jednotlivé funkcionality systému jsou rozděleny do několika menších částí, takzvaných modulů: o Modul Osoba. Stěžejní modul zobrazuje základní informace o účtu přihlášeného uživatele. Dále je určen k evidenci osob, jejich základních údajů, ale i k určování rolí v rámci systému a podle role zobrazování relevantních možností. Tedy evidování případně pouze zobrazování jednotlivých plateb, odjetých jízd, docházky na výuku, zkoušek a kurzů u studenta nebo zobrazení odučené výuky, vedených zkoušek a kurzů pro zaměstnance. Vedoucí má možnost vytvořit novou osobu v systému. o Modul Výuka. Další důležitý modul. Modul umožňuje editaci případně pouze zobrazování týdenního rozvrhu a jeho jednotlivých hodin. Studenti si mohou zobrazit, kdy mají své jízdy nebo kdy jsou dostupné volné jízdy s jejich oblíbeným učitelem. Zaměstnanci jsou schopni vytvářet jízdy nebo přednášky a vedoucí má možnost tyto odučené hodiny potvrdit nebo studenty na vybrané hodiny přihlásit. o Modul Kurz zprostředkovává jednoduchou evidenci kurzů, tedy jejich vytváření nebo úpravu. U každého kurzu je zobrazen seznam studentů a operace z tohoto seznamu plynoucí stejně jako v modulu Osoba. Je umožněné studenty do kurzu přihlašovat nebo odstupovat. o Modul Zkouška. Jednoduchý modul umožňuje vytváření závěrečných zkoušek, zvolení odpovědného zaměstnance, přidělení vozidla a výběr studentů, kteří se chystají zkoušky ve vybraném termínu účastnit. Vedoucí má zároveň možnost zkoušku vyhodnocovat pro každého studenta zvlášť. o Modul řidičské oprávnění slouží k evidenci jednotlivých typů řidičských oprávnění a hodin potřebných k jejich úspěšnému ukončení. Pro každé řidičské oprávnění se udává jeho cena. o Modul vozidlo poskytuje evidenci vozidel. Hlavně určování typu a stavu vozidla. o Modul učebna slouží k zadávání provozoven, kde se vykonává výuka teorie. • Mimofunkční požadavky Pro celkovou dostupnost systému je implementován jako webová aplikace, která je dostupná odkudkoliv, kde je připojení k internetu. Aplikace by měla být zobrazitelná v nejběžnějších webových prohlížečích jako jsou například
Vlastní řešení
33
Internet Explorer, Mozilla Firefox, Google Chrome nebo Opera, bez nutnosti doinstalování různých rozšíření či pluginů. Požadavky na výkon jako je doba odezvy, nebo propustnost již nemohou být ovlivněny přímo. Jsou dané webovým serverem, který autoškola vlastní, a nepřeje si ho měnit. Ovšem na delší dobu trvající transakce, většinou generování reportů, je vhodné zavést softwarový zámek, který zakáže generování více stejných reportů v tutéž dobu, případně prodloužit maximální možný čas pro běh transakce. Vzhledem k vyvíjejícím se požadavkům na systém se nabízí používání stopovacího systému, který zaznamenává veškeré provedené změny a zároveň umožňuje zadávat a spravovat nové úkoly k vylepšení systému pro nadcházející verzi. Spolu s dokumentací kódu, programátorskou kuchařkou zastoupenou touto prací a navrženou modularitou systému nebude případná modifikovatelnost stávajících modulů, nebo rozšiřitelnost o další moduly představovat větší problémy. Z důvodu možného napadení systému nebo selhání hardwaru vyplývá povinnost pravidelně zálohovat data. Záloha dat představuje vytvoření kopie kořenového adresáře webové aplikace spolu s kopií databáze do zálohovací složky na webovém serveru, ale i na připojeném externím disku. Zálohovací skripty jsou spouštěny každou hodinu. Díky omezené kapacitě ukládacího prostoru se uchovávají zálohy pouze tři dny zpět. K předcházení napadení systému přes vstupní body do aplikace napomáhá automatická kontrola formulářových prvků. Ochrana hesel se dá zabezpečit pomocí dostupných šifrovacích algoritmů. Je nutné klást pozor na správné nastavení přístupových práv přímo k adresářové struktuře na webovém serveru.
4.4 Analýza a návrh 4.4.1
Autentizace a autorizace
Nepřihlášený uživatel se prokazuje evidenčním číslem a heslem. Proces autentizace převezme zadané údaje a porovná je s daty v databázi, pokud údaje souhlasí, nastaví se uživateli jeho identita a bude přesměrován na úvodní stránku, v opačném případě se objeví varovné oznámení o špatném evidenčním čísle, nebo špatně zadaném hesle. Po autentizaci uživatele ještě proběhne autorizační část, která nastaví uživateli oprávnění neboli také roli, v jaké uživatel vystupuje k jednotlivým modulům a jeho částem. Přihlašovací stránka se zobrazí i po odhlášení. Automatické odhlášení bude nastaveno po 30 minutách neaktivity. V případě, že uživatel přejde na některou z dostupných stránek, ale je odhlášen z důvodu neaktivity, systém si tuto stránku zapamatuje a po opětovném přihlášení nepřesměruje uživatele na Úvodní stránku, ale na stránku kam chtěl ve skutečnosti jít.
34
Vlastní řešení
4.4.2
Úvodní obrazovka systému
Po přihlášení do systému je uživatel přesměrován na Úvodní stránku. Úvodní stránka neobsahuje žádnou funkcionalitu, proto je popsána pouze slovně a nejsou k ní vytvořeny žádné digramy. Stránka představuje rozcestník po aplikaci. V hlavičce stránky se v pravém horním rohu zobrazuje jaký uživatel je momentálně přihlášen do systému s tlačítkem sloužícím k odhlášení. Dále jsou zde zobrazeny jednotlivé rolovací nabídky menu položek, které odkazují do daných modulů. Tyto nabídky se zobrazují uživatelům podle jejich role v systému. Více k přístupu uživatelů k nabídkám až v jednotlivých modulech. Jsou zde také uvedeny statické informace o majiteli autoškoly. Tedy jméno, příjmení, telefon, email, adresa, IČO a DIČ. Následuje je seznam všech aktivních učitelů s kontaktním telefonem a emailem. 4.4.3
Modul Osoba
Uživatele přihlášeného do systému reprezentuje osoba. Modul Osoba tedy zprostředkovává veškeré operace spjaté se správou uživatelů, ať už se jedná o jejich prohlížení, vytváření či upravování jejich hodnot. U osoby se zaznamenává evidenční číslo, jméno, příjmení, adresa, telefonní číslo, email, datum narození, rodné číslo, vlastnění řidičské oprávnění, požadované řidičské oprávnění, kurz, heslo, role a status. Modul se skládá celkem z pěti případů užití. S modulem Osoby pracují všichni tři aktéři. Diagram případů užití je zobrazen na Obr. 1. Pro ostatní moduly jsou jejich diagramy případů užití k nalezení v příloze. Vše co se týče oprávnění aktérů, popisu chování případů užití a další informace se nachází v obsahu následujících výčtů. • Zobrazit osobu Vstupní podmínkou je parametr, který nám jednoznačně identifikuje osobu, kterou se chystáme zobrazit. Jestliže nebude osoba podle tohoto parametru nalezena, bude uživatel přesměrován na Úvodní stránku s vypsáním informačního boxu o neexistenci požadované osoby. Po nalezení příslušné osoby se vykreslí blok s jejími informacemi. Přehledný scénář případu užití je k nalezení v Tab. 1. Scénáře všech dalších případů užití jsou stejně jako obrázky uvedeny v příloze.
Vlastní řešení
Obr. 1
Diagram případů užití - modul Osoba
Tab. 1
Scénář případu užití Zobrazit osobu
Stručný popis: Zobrazuje veškeré údaje o vybrané osobě. Aktéři: Vedoucí, Zaměstnanec, Student. Vstupní podmínky: Jednoznačný identifikátor osoby. Hlavní scénář: 1. Systém zobrazí veškeré informace o osobě. 2. Pokud je osoba nenalezena pokračuje se alternativním scénářem 1. Výstupní podmínky: 1. Zobrazené údaje o osobě. Alternativní scénář: 1. Informuje uživatele o důvodu nenalezení osoby.
35
36
Vlastní řešení
• Moje osoba K tomuto případu užití nejsou žádné vstupní podmínky, mohou jej zobrazit všichni aktéři. Po spuštění případu užití Moje osoba se zavolá případ užití Zobrazit osobu, který zobrazí detail aktuálně přihlášené osoby v systému. Moje osoba dále umožňuje změnu hesla tj. tři vstupy typu heslo, první pro ověření starého hesla, dva pro nové heslo. Všechny tři položky jsou povinné. Pro změnu hesla se provede kontrola starého hesla vůči databázi, zkontroluje se minimální délka hesla nastavená na 6 znaků a pokud vše souhlasí, nové heslo se uloží a zobrazí se informační oznámení o úspěchu. Pokud dojde k chybě, objeví se informační okno s chybovým oznámením. • Zobrazit osoby Případ užití Zobrazit osoby slouží k základnímu filtrování ze všech osob v databázi systému. Do této části systému má přístup pouze uživatel s rolí zaměstnanec nebo vedoucí. Prvky filtrování jsou jméno, příjmení, rodné číslo, kurz, případně zkouška. Filtr obsahuje možnost k jeho vyprázdnění a zároveň má schopnost zapamatovat si svůj předchozí stav v případě, že uživatel filtr opustí a poté se vrátí. Vyhledávání funguje v reálném čase, tedy ihned vrací výsledky, kde zobrazuje jednotlivé osoby v řádcích pod sebou. Tento systém fungování pro filtrovací formulář je použit i u všech ostatních filtrovacích formulářů v následujících odstavcích a nebude znovu popisován. Řádek vyhledané osoby obsahuje evidenční číslo, jméno, příjmení, rodné číslo a telefon. Z každého řádku se může pokračovat na případy užití Zobrazit osobu, nebo Upravit osobu. • Vytvořit osobu Vytvořit osobu může pouze vedoucí. Studentovi se automaticky generuje evidenční číslo definované v uživatelské specifikaci. Pro zaměstnance a vedoucího se generuje evidenční číslo ve tvaru pořadové číslo lomeno x. Datum narození je vybíráno z kalendáře, který stanový jednotný formát data pro celý systém, a je zobrazeno po kliknutí do vstupního prvku. Po validaci vstupních hodnot se provede zavedení osoby do systému a uživateli se oznámí úspěch či neúspěch prováděné operace. Při úspěchu je přesměrován na detail vytvořené osoby, v opačném případě mu je znovu zobrazena stránka s formulářem pro vytvoření osoby. • Upravit osobu Případ užití, kde je vstupním parametrem identifikátor ukazující pouze na jedinou osobu v databázi a může k němu přistupovat vedoucí. V případě nenalezení osoby se uživatel přesměruje na stránku Seznam osob se zobrazením chybového oznámení. Po nalezení osoby se zobrazí informace jako při vytváření osoby. Jediný rozdíl ve formuláři je ve výchozích hodnotách prvků, které jsou předvyplněny nalezenou osobou a je zobrazeno evidenční číslo osoby, které ovšem nelze měnit.
Vlastní řešení
4.4.4
37
Modul výuka
Výuka představuje hlavní činnost prováděnou v autoškole. Umožňuje uživatelům prohlížet nadcházející plán výuky, ale také výuku již proběhlou. Zaměstnancům dává možnost výuku vytvářet, upravovat a vyhodnocovat docházku. Je implementována jako samostatný modul v podobě čtyř případů užití. U výuky se eviduje vozidlo, učebna, učitel, typ, status, datum, hodina a případná poznámka. • Zobrazit výuku Pro tento případ užití není žádný vstupní parametr nebo omezení zobrazení na základně oprávnění uživatele. Nepřehlednost velkého počtu zobrazených hodin lze redukovat na začátku se vykreslujícím filtrovacím formulářem. Jako výchozí je zobrazen aktuální týden. Na konec je zobrazen samotný rozvrh jízd. Každá výuková hodina, která je v rozvrhu zobrazena, rozšiřuje stávající případ užití a to podle toho jaké oprávnění má přihlášený uživatel. Pro studenty se po otevření hodiny provede případ užití Zobrazit hodinu a pro zaměstnance a vedoucího se pokračuje případem užití Upravit hodinu. Ještě je zde možnost rozšíření případem užití Vytvořit hodinu a může jej provést zaměstnanec spolu s vedoucím. • Vytvořit a Upravit hodinu Zaměstnanec nebo vedoucí mohou vytvářet i editovat nové hodiny. Jelikož jsou tyto případy užití téměř totožné, jsou popsány společně. Při zadávání vstupních hodnot se kontroluje jejich validita. Je také nutná kontrola dostupnosti učitele, vozidla, studenta nebo provozovny. Uživatel je o výsledku informován chybovým případně potvrzujícím hlášením. Dále má uživatel v roli vedoucí možnost rozhodnout, zda jízda proběhla, nebo ji neschválit. • Zobrazit hodinu Jednoduchý případ užití pouze pro studenta. Je nutný vstupní parametr jednoznačně identifikující požadovanou jízdu, přednášku. Jedná se pouze o informace týkající se vybrané výuky, které stačí zobrazovat v objevujícím se oddílu. Pouze v případě nenalezení vybrané hodiny je nutné studenta upozornit hlášením. 4.4.5
Modul kurz
V tomto modulu máme možnost provádět kompletní administraci kurzů. Ke každému kurzu jsou přiřazeni jeho studenti, proto je kurz v rámci autoškoly považován za ekvivalent třídní knihy. Zde lze také studenta do kurzu přihlásit, v opačném případě studenta z kurzu odstoupit. U kurzu se eviduje evidenční číslo, učitel, datum zahájení a ukončení. • Zobrazit kurzy Případ užití, který nepotřebuje žádné vstupní parametry a je přístupný jakémukoliv uživateli. V první fázi se vykreslí filtrovací formulář, tak jak jsme již zvyklí z předchozích seznamů. V druhé, poslední fázi, se vykreslí do řád-
38
Vlastní řešení
ků pod sebe kurzy odpovídající vstupním parametrům z filtrovacího formuláře. Na každém řádku je uvedeno evidenční číslo, datum zahájení a případně i ukončení, vedoucí a status kurzu, který se odvozuje z dat uvedených výše. Kurz může být plánovaný, aktivní nebo ukončen. Seznam kurzů je u každého zobrazeného kurzu rozšířen případy užití Zobrazit a Upravit kurz. Zobrazit kurz je dostupný všem uživatelům, ovšem Upravit kurz je aktivní pouze pro uživatele přihlášeného s rolí vedoucí. • Zobrazit kurz Vstupním parametrem je jednoznačný identifikátor kurzu, podle kterého je požadovaný kurz vyhledán v databázi. Po nalezení kurzu je zobrazena tabulka, kde jsou vypsány všechny informace týkající se kurzu a v případě zadaného vyučujícího i jeho kontaktní údaje. Pokud má již kurz přidělené studenty, je zobrazen seznam studentů, kde je uvedeno studentovo evidenční číslo, jméno, příjmení, rodné číslo a telefon. V případě nenalezení kurzu je uživatel přesměrován na Zobrazit kurzy a je o této akci informován varovným hlášením. • Vytvořit kurz Jednoduchý případ užití pro vytváření kurzu. Nejsou potřeba žádné vstupní parametry. Oprávněný je uživatel v roli vedoucího. Povinným vstupem je datum zahájení kurzu. Datum ukončení kurzu je uzamčeno a nemůže být zadáno. V momentě odeslání formuláře se kontroluje validita vstupních hodnot, pokud jsou hodnoty nevyplněny, nebo vyplněny špatně, formulář se neodešle a uživatel je upozorněn na chybný stav. Po odeslání formuláře se generuje kurzu jeho evidenční číslo a kurz je zaváděn do databáze. Pokud vše proběhne v pořádku je uživatel informován a přesměrován na detail kurzu, v opačném případě je přesměrován opět na případ užití Vytvořit kurz. • Upravit kurz Vstupním parametrem je jednoznačný identifikátor kurzu. Případ užití je pro uživatele v roli vedoucí. Datum ukončení kurzu může být zadáno pouze v případě, že kurz neobsahuje studenta, který je aktivní a má nekonanou nebo neúspěšně ukončenou závěrečnou zkoušku. Pokud jsou na kurzu přihlášení studenti, jsou zobrazeni v tabulce obsahující jejich evidenční číslo, jméno, příjmení, rodné číslo, telefon a tlačítko umožňující studenta z kurzu odstoupit. To znamená, že student se i nadále v kurzu zobrazuje, ale již není aktivní, tudíž lze kurz uzavřít. Posledním řádkem tabulky je vždy další formulářový vstup, do kterého lze zapsat jméno, příjmení nebo evidenční číslo studenta a na základě těchto hodnot studenta přihlásit. Nakonec je uživatel informován o výsledku akce a přesměrován na tutéž stránku. V případě nenalezení kurzu v databázi je uživatel přesměrován na případ užití Seznam kurzů a je informován chybovým hlášením.
Vlastní řešení
4.4.6
39
Modul zkouška
Zkouškou projde každý student na konci navštěvovaného kurzu. Teprve zde se pozná, zda student pozorně navštěvoval přednášky a odnesl si dovednosti řízení motorového vozidla z praktických jízd. Modul slouží k práci se zkouškami. Umožňuje jejich vytváření, úpravu, zobrazení a vyhodnocování. Dále je ke zkoušce možno přihlašovat, případně ze zkoušky odhlašovat studenty. U zkoušky se eviduje učitel, vozidlo, datum a poznámka. Zkouška je složena ze tří částí. Každá část má typ a status. • Zobrazit zkoušky Pro zobrazení seznamu zkoušek není nutný žádný vstupní parametr. Přístupová práva nejsou pro jakéhokoliv uživatele omezena. Na začátku je vykreslen filtrovací. Výsledný seznam zkoušek je zobrazen do tabulky. Každý řádek odpovídá jedné zkoušce a obsahuje datum konání, vedoucího a možnost rozšíření na případy užití Zobrazit, Upravit a Vyhodnotit zkoušku. Zobrazit zkoušku nemá definována žádná uživatelská omezení, naproti tomu Změnit a Vyhodnotit ano. K oběma případům užití může přistupovat pouze uživatel, který je do systému přihlášen jako vedoucí. • Zobrazit zkoušku Jak už bylo napsáno v předchozím případu užití, Zobrazit zkoušku může jakýkoliv uživatel bez omezení. Jediným vstupním parametrem je jednoznačný identifikátor zkoušky. Po nalezení vybrané zkoušky jsou zobrazeny její základní informace. V případě, že jsou již na zkoušku přihlášení studenti, se zobrazí tabulka s jejich informacemi. Pokud nebyla zkouška podle vstupního identifikátoru nalezena, je nutno uživatele přesměrovat na Zobrazit zkoušky a viditelně ho informovat o nastalé chybě. • Vytvořit zkoušku Vytvořit zkoušku může jenom vedoucí a vstupní parametr není potřeba. Před odesláním formuláře se jako vždy kontroluje formát vstupních hodnot, kdy je uživatel o chybě ihned informován. Po odeslání formuláře je nutné zkontrolovat zda vybrané vozidlo, na kterém se koná zkouška, nemá ve stejný den naplánované jízdy. V případě kolize je nutné ukládání zkoušky ukončit a uživatele informovat. Pokud proběhne vytváření nové zkoušky v pořádku je uživateli zobrazen informační box s potvrzující zprávou a je přesměrován na případ užití Upravit zkoušku. • Upravit zkoušku Po zkontrolování vstupního parametru, který jednoznačně identifikuje zobrazovanou zkoušku a uživatelské role vedoucí, je zobrazena první část s formulářem. Jedná se o stejný formulář jako při vytváření zkoušky, ale v tomto případě je předvyplněn výchozími hodnotami z nalezené zkoušky. V další části je zobrazena tabulka představující seznam již přihlášených studentů se základními informacemi a možností studenta ze zkoušky odhlásit, ovšem pouze v případě, že ještě nebyla jeho účast na zkoušce vyhodno-
40
Vlastní řešení
cena. Posledním řádkem tabulky je, jako u kurzů, další formulářový prvek ulehčující vyhledávání ze seznamu aktivních studentů pomocí jména, příjmení nebo evidenčního čísla. V přihlašování studenta je nutné zkontrolovat, zda nemá v daný den konání zkoušky výuku. Pokud student podmínkou projde, je přihlášen na zkoušku a uživatel je informován o úspěchu, v opačném případě je informován o neúspěchu. V obou případech je uživatel přesměrován na stejnou stránku. • Vyhodnotit zkoušku Vstupním parametrem je jednoznačný identifikátor zkoušky. K případu užití má přístup uživatel v roli vedoucího. V první části je zobrazena tabulka s informacemi o zkoušce. Druhá, stěžejní část, je zastoupena tabulkou obsahující seznam studentů, kteří jsou na zkoušce přihlášeni. U každého studenta je uvedeno jméno, příjmení, rodné číslo a jednoduchý formulář představující oblasti závěrečné zkoušky. Oblastmi jsou jízdy, teorie a údržba. Formulář u každé oblasti obsahuje tři prvky, kde může být vybrán pouze jeden. Prvky pro vyhodnocení zkoušky, tedy nezadáno jako výchozí stav a uspěl případně neuspěl. Odeslání formuláře je možné pouze v případě, že datum konání zkoušky již proběhlo. Pokud je studentovi vyhodnocena hodnota uspěl, jeho status je změněn na neaktivní, co značí, že dokončil kurz. Po zpracování formuláře je uživatel informován o úspěchu nebo neúspěchu prováděné operace pomocí zprávy a je přesměrován na stejný případ užití. 4.4.7
Modul řidičské oprávnění
Řidičské oprávnění představuje povolení k řízení různých typů motorových vozidel na pozemních komunikacích. Modul řidičské oprávnění tedy umožňuje práci s lidově zvanými „řidičáky“. Ale také takto vytvořeným kombinacím nastavovat požadovaný počet hodin. Ať už se jedná o hodiny potřebné k teoretické výuce nebo hodiny požadované k úspěšnému absolvování praktických jízd na vybraných typech vozidel. Také je zde možno zadávat celkovou cenu řidičského oprávnění. Modul Řidičské oprávnění je prvním modulem, ke kterému nemá student povolený přístup. • Zobrazit řidičská oprávnění Pro zobrazení seznamu řidičských oprávnění není potřeba žádného vstupního parametru, ovšem seznam může být zobrazen pouze uživatelům s rolí zaměstnanec nebo vedoucí. Filtrovací formulář je v první části. Konečně v druhé části stránky je zobrazen výsledný seznam. Každý řádek tabulky představuje jedno řidičské oprávnění a je u něj uveden název, typ skupin, z kterých se skládá a možnost rozšíření na případy užití Zobrazit a Změnit řidičské oprávnění. • Zobrazit řidičské oprávnění Řidičské oprávnění zobrazeno tímto případem užití je reprezentováno jednoduchou tabulkou, ke které má přístup zaměstnanec a vedoucí. Pro zobra-
Vlastní řešení
41
zení potřebujeme vstupní parametr v podobě jednoznačného identifikátoru, podle kterého jsme schopni dohledat požadované řidičské oprávnění. V případě, že není oprávnění nalezeno, je uživatel přesměrován na seznam řidičských oprávnění a je o této akci náležitě informován. Tabulka zobrazující oprávnění obsahuje všechny jeho vlastnosti od názvu, typu, přes počet hodin praktických jízd každého stupně provozu a všechny druhy teoretické výuky, až po celkovou cenu za získání tohoto oprávnění. • Vytvořit a Upravit řidičské oprávnění Pro vytváření řidičských oprávnění nepotřebujeme žádný vstupní parametr. Oprávnění může vytvořit pouze vedoucí. Povinnými prvky je název řidičského oprávnění a výběr jednoho, nebo více typů skupin motorových vozidel, ze kterých se má oprávnění skládat. Ostatní vstupní prvky představují počet hodin k jízdám a teorii. Jako poslední je možno zadat celkovou cenu řidičského oprávnění, kterou je potřeba studentem zaplatit. Po validaci formuláře, kdy se kontroluje vyplnění prvních dvou prvků, je formulář odeslán, zpracován a do systému je zavedeno nové řidičské oprávnění. Pokud vše proběhne bez problému, je uživatel informován o úspěchu a přesměrován na stránku Upravit řidičské oprávnění, kde je zobrazeno právě vytvořené oprávnění. V opačném případě je uživatel informován o neúspěchu a přesměrován na tentýž formulář pro vytvoření nového oprávnění. Pro upravení řidičského oprávnění je za potřebí vstupní parametr identifikující toto oprávnění. Ve všech ostatních ohledech se úprava oprávnění chová stejně jako případ užití Vytvořit řidičské oprávnění s tím rozdílem, že formulář má předvyplněné hodnoty nalezené u daného oprávnění. 4.4.8
Modul vozidlo
Motorové vozidlo představuje v autoškole každodenní nástroj používaný k výuce praktických jízd. Modul Vozidlo umožňuje tyto motorová vozidla vytvářet, zobrazovat, případně upravovat. U vozidla se eviduje SPZ, typ, stav, výrobce a barvu. • Zobrazit vozidla Seznam zobrazuje pouze jednoduchou tabulku všech dostupných vozidel v systému. Přístup k němu má uživatel v roli zaměstnanec a vedoucí. Každý řádek tabulky představuje jedno vozidlo a zobrazuje vlastnosti jako je poznávací značka, typ a status. Na konci každého řádku je možnost rozšířit na případy užití Zobrazit a Upravit konkrétní vozidlo. • Zobrazit vozidlo Pro zobrazení vozidla je nutný vstupní parametr, který vozidlo jednoznačně identifikuje. K zobrazení má přístup uživatel v roli zaměstnance i vedoucí. Vozidlo je zobrazeno v tabulce, která obsahuje všechny jeho zaznamenávané vlastnosti. Pokud nebylo vozidlo v systému nalezeno, je uživatel přesměrován zpět na seznam vozidel a je o chybové situaci informován.
42
Vlastní řešení
• Vytvořit a Upravit vozidlo Případy užití Vytvořit a Upravit vozidlo jsou si podobné tak, jak tomu bylo u předcházejícího modulu Řidičské oprávnění. Při úpravě vozidla je nutný vstupní parametr identifikující vozidlo, při vytváření nikoliv. Pokud při úpravě vozidla nebylo vozidlo nalezeno, je uživatel přesměrován na stránku Seznam vozidel a je o této skutečnosti informován. K oběma případům má přístup pouze uživatel s rolí vedoucí. Před odesláním formuláře se kontrolují povinné prvky a formát SPZ, pokud je nalezen problém, je o něm uživatel informován. V případě validity formuláře je formulář odeslán a do systému se zadává nové vozidlo nebo se vlastnosti vozidla upravují. O výsledku prováděné akce je uživatel také informován. Pokud bylo vozidlo vytvořeno je přesměrován na úpravu vozidla, v opačném případě na seznam vozidel, nebo ať už je vozidlo upraveno úspěšně či nikoliv je uživatel přesměrován opět na úpravu téhož vozidla. 4.4.9
Modul Učebna
Učebna je místo, kde probíhá teoretická výuka. Učebna je i stanovištěm, na kterém začínají nebo končí praktické jízdy. Modul Učebna je složen ze čtyř případů užití. Uživatel si může zobrazit seznam učeben, zobrazit jednu konkrétní učebnu, nebo upravit stávající učebny. U učebny se eviduje název, adresa a kapacita. • Zobrazit učebny Pro zobrazení seznamu učeben není zapotřebí žádného vstupního parametru. Uživatel v roli vedoucího nebo zaměstnance je oprávněn zobrazit seznam. Stejně jako u vozidel, ani zde není zapotřebí filtrování. Seznam je reprezentován jednoduchou tabulkou. Každý řádek tabulky představuje jednu učebnu. U učebny je uveden její název, kapacita, adresa a možnost rozšíření, které odkazují na případy užití Zobrazit a Upravit učebnu. • Zobrazit učebnu Požadovaným vstupním parametrem je jednoznačný identifikátor učebny. Zobrazit detail učebny mohou uživatelé s rolí vedoucí nebo zaměstnanec. Jestliže nebude učebna v systému nalezena, je zapotřebí uživatele informovat a přesměrovat zpět na seznam učeben. Učebna má v tabulce zobrazeny pouze tři vlastnosti, kterými jsou název, kapacita a adresa. • Vytvořit a Upravit učebnu Zde máme opět dva velice podobné případy užití. Případ užití Upravit učebnu potřebuje identifikátor učebny jako vstupní parametr. K oběma případům má přístup pouze vedoucí. U PSČ se kontroluje formát. Vyplnění a správnost prvků se kontroluje před odesláním samotného formuláře. Pokud vyplněný formulář obsahuje chyby, není odeslán a uživatel je upozorněn. Po odeslání formuláře je v systému upravena stávající, nebo založena nová učebna. Pokud zakládání nebo úprava proběhne v pořádku je uživatel informován a přesměrován na případ užití Zobrazit učebnu.
Vlastní řešení
43
4.4.10 Diagram tříd Diagram zachycuje třídy popsané v předcházejících kapitolách, především v analýze jednotlivých modulů. Jedná se o třídy, s kterými je třeba počítat pro bezproblémový chod informačního systému. V rámci modulárnosti objektově orientované aplikace a dobrým zvykům je vhodné kolem každé třídy v diagramu tříd, která reprezentuje modul vytvořit další pomocné třídy. Tak jak je popsáno v návrhovém vzoru Data mapper v kapitole 3.1.2. Pro větší flexibilitu aplikace je tento návrh ještě rozšířen o třídu reprezentující rozhraní a repositář. Třídy reprezentující moduly je Osoba, Výuka, Kurz, Zkouška, Řidičské oprávnění, Vozidlo a Učebna. Kolem každé další třídy je minimálně nutné vytvořit přístupové třídy k databázovému serveru. Samotný diagram tříd i diagram s obslužnými třídami je k dispozici v příloze. 4.4.11
ER Diagram
Jelikož je použito objektově relačního mapování, je ER diagram velice podobný diagramu tříd. Jediným podstatným rozdílem je zachycení pomocných tabulek, které umožňují rozpad vazeb m:n. Přehled tabulek je k nalezení v digramu umístěném opět v příloze. Drobné rozdíly lze nalézt mezi datovými typy. Pro vlastnosti, které ukládají stavy nebo typy objektů je zvolen datový typ řetězec. Správnost hodnot bude kontrolována až v modelové vrstvě samotné aplikace nikoliv datovým typem množina.
4.5 Návrh uživatelského rozhraní Pro každý modul a jeho případy užití je zpracován hrubý návrh uživatelského rozhraní. Každá stránka se skládá ze dvou částí. První je menu, které umožňuje pohyb uživatele po aplikaci a odhlášení. Druhou částí je obslužná funkcionalita k danému případu užití. Tento návrh slouží především k představě jaké typy ovládání mají mít formulářové prvky. Všechny návrhy rozhraní jsou v příloze.
4.6 Implementace Tak jak bylo uvedeno ve specifikaci, výběr webového serveru pro informační systém byl omezen serverem, který již autoškola vlastní. Je k dispozici webový server Internet Informaiton Services 7.5 s integrovaným PHP 5.3.13 modulem a databázovým serverem MySQL 5.5.28. Z důvodu dostupnosti PHP modulu na serveru byl vybrán pro samotnou implementaci informačního systému Nette framework ve verzi 2.0.13. K Nette se nabízí použití knihovny pro modelovou vrstvu, která je určena k práci s databází. Knihovnou je Dibi 2. K lepší práci se zobrazováním dat byl kromě HTML 5 a CSS3 zvolen javascriptový framework jQuery 1.9.1, který již využívá samotný Nette framework. K ulehčení vývoje byl vybrán nejrozšířenější klient pro komunikaci s verzovacím systémem TortoiseSVN 1.7.10.
44
Diskuze a závěr
5 Diskuze a závěr 5.1
Diskuze
V průběhu implementace vyplynuly na povrch některé nesrovnalosti, přesněji nedořešené otázky, které se týkají uznávání výuky nebo procesu řízení kurzů a jejich studentů. Bylo by vhodné tyto otázky prodiskutovat s pověřeným pracovníkem autoškoly, aby mohly být v průběhu druhé iterace vývoje implementovány a otestovány. Zároveň se do analýzy druhé iterace mohou zařadit nové funkcionality. V první řadě zaznamenávání veškerých dotazů nad databází do logovací tabulky. Spolu s typem operace ukládat jejího uživatele, čas, obsah dotazu a podobné. K tomu mohou velice snadně posloužit repository třídy modelové vrstvy. Užitečnou funkcionalitou může být upozorňovaní emailem na vybrané události. Otázkou stále zůstává klasická webová prezentace pro nepřihlášené uživatele. Důležitým rozšířením, které se dá implementovat je reportovací modul. Exporty souhrnných výpisů kurzů, ale i hodin jednotlivých studentů, učitelů nebo hodin z pohledu vozidla jsou velice přínosné při rozhodování. Úvodní strana systému je využita pouze pro zobrazovaní aktivních učitelů. Ta může být rozšířena o zobrazování různých událostí jako je vytváření nových výukových hodin nebo zkoušek. Další možností jak pokračovat v podpoře jednotlivých procesů autoškoly je vytvoření mobilní aplikace. Je otázkou diskuze zda se zabývat vývojem kompletně nové aplikace pro typ těchto zařízení nebo věnovat další iteraci systémem a na současnou webovou aplikaci implementovat responzivní design.
5.2 Závěr Vedlejším cílem práce byl průzkum nabídky trhu informačních systémů zaměřeného přímo na podporu podnikových procesů probíhajících v autoškole. Ukázalo se, že samotná nabídka na trhu je zcela nedostatečná. V době průzkumu byly k nalezení pouze dvě nabídky. První byl systém Dubensoft, který jako desktopová aplikace neumožňuje přístup studentům k důležitým informacím o výuce nebo zkoušce. Druhou, podstatně lepší webovou aplikací, byla Evidence autoškoly 2.4. Krom pár nesrovnalostí v evidování výuky v kilometrech a ne v hodinách, neměla větší nedostatek. Po vyhodnocení nabídky tru a konzultaci s pověřeným zaměstnancem autoškoly Liška se ukázalo, že autoškola provádí svoje procesy zcela jedinečně a specificky, tudíž nelze nalezené systémy použít. Hlavním cílem práce tedy bylo popsání současného stavu podnikových procesů v autoškole Liška, jejich zpracovaní, analýza a návrh řešení informačního systému v podobě webové aplikace využívající moderní technologie. K vývoji systému byl zvolen iterativní model vývoje. Tento model nejvíce vyhovoval situaci, kdy majitel autoškoly nevěděl co od systému může očekávat.
Diskuze a závěr
45
Byla domluvena první iterace pokrývající základní procesy v podniku. V druhé iteraci, po představení systému, se může přistoupit k hlubší analýze procesů a přidání dalších funkcionalit. Po prozkoumání současného stavu, přišlo na řadu sepsání uživatelské a systémové specifikace. Systémová specifikace dále obsahovala seznam funkčních a mimofunkčních požadavků na systém. Ze systémové specifikace následovalo vytvoření analýzy a návrhu. Byl vybrán objektově orientovaný přístup pro jeho snadnou modularitu, znovu použitelnost kódu a schopnost oddělení detailů od celku. S analýzou byl zároveň prováděn návrh grafického uživatelského rozhraní pro každou jednotlivou stránku. Výsledný návrh systému byl rozdělen celkem do sedmi modulů. Zvolení technologií a prostředků pro implementaci systému bylo většinou omezeno serverem, který již autoškola vlastnila. Přesto byl pro implementaci zvolen Nette framework, jQuery nebo databázová knihovna Dibi. K lepší orientaci, ale k hlavně k zaznamenávání vývoje zdrojových kódů byl vybrán verzovací systém TortoiseSVN. Úplným závěrem lze říci, že první iteraci vývoje systému se podařilo z větší části implementovat. Systém nyní běží v autoškole na lokálním serveru a majitel rozmýšlí požadavky na druhou iteraci.
46
Literatura
6 Literatura [1] SODOMKA, P. Informační systémy v podnikové praxi. První vydání. Brno: Computer Press, 2006. 352 s. ISBN 80-251-1200-4. [2] SOMMERVILLE, I. Software Engineering. Osmé vydání. Addison-Wesley, 2006. 864 s. ISBN 0-321-31379-8. [3] RÁBOVÁ, I. Podnikové informační systémy a technologie jejich vývoje. Brno: Tribun CZ, 2008. 139 s. ISBN 978-80-7399-599-7. [4] ARLOW, J., NEUSTADT, I. UML2 a unifikovaný proces vývoje aplikací. Brno: Computer Press, 2007. 568 s. ISBN 978-80-251-1503-9. [5] Autoškola - Wikipedie [online]. c2014 [cit 2014-05-19]. Autoškola. Dostupné z WWW:
. [6] Helios [online]. c2014 [cit 2014-05-19]. Vice o HELIOS Red. Dostupné z WWW: . [7] Moderní Autoškola [online]. c2014 [cit 2014-05-19]. Internetový systém pro plánování jízd. Dostupné z WWW: . [8] Dubensoft [online]. c2014 [cit 2014-05-19]. Software Evidence autoškoly. Dostupné z WWW: . [9] Software-Autoškola [online]. c2014 [cit 2014-05-19]. On-line aplikace dostupná z webového prohlížeče. Dostupné z WWW: . [10] GRUDL, D. Nette Framework: MVC & MVP [online]. c2009 [cit. 2014-0519]. Dostupné z WWW: . [11] FOWLER, M. Catalog of Patterns of Enterprise Application Architecture [online]. c2003 [cit. 2014-05-19]. Dostupné z WWW: . [12] GILMORE, W. J. Velká kniha PHP a MySQL 5: Kompendium znalostí pro začátečníky i profesionály. Brno: Zoner Press, 2007. 864 s. ISBN 8086815-53-6. [13] Javascript [online]. c2013 [cit. 2013-10-20]. Javascript Tutorial. Dostupné z WWW: [14] HTML [online]. c2013 [cit. 2013-10-20]. HTML Tutorial. Dostupné z WWW: [15] CSS [online]. c2013 [cit. 2013-10-20]. CSS Tutorial. Dostupné z WWW: [16] Nette Framework [online]. c2013 [cit. 2013-10-20]. Rychlý a pohodlný vývoj webových aplikací v PHP. Dostupné z WWW:
Literatura
47
[17] jQuery [online]. c2013 [cit. 2013-10-20]. jQuery Tutorial. Dostupné z WWW: [18] Subversion [online]. c2013 [cit. 2013-10-20]. Apache Subversion. Dostupné z WWW:
48
Literatura
Přílohy
Obrázky - diagramy
A Obrázky - diagramy
Obr. 2
Diagram případů užití – modul výuka
49
50
Obr. 3
Obrázky - diagramy
Diagram případů užití – modul kurz
Obrázky - diagramy
Obr. 4
Diagram případů užití – modul zkouška
51
52
Obr. 5
Obrázky - diagramy
Diagram případů užití – modul řidičské oprávnění
Obrázky - diagramy
Obr. 6
Diagram případů užití – modul vozidlo
Obr. 7
Diagram případů užití – modul provozovna
53
54
Obr. 8
Obrázky - diagramy
Diagram tříd
Obrázky - diagramy
Obr. 9
Třída Osoba v modelové vrstvě
55
56
Obr. 10
Obrázky - diagramy
E-R Diagram
Obrázky - diagramy
57
58
Obrázky - návrhy uživatelského rozhraní
B Obrázky - návrhy uživatelského rozhraní
Obr. 11
Uživatelské rozhraní - Přihlašovací stránka
Obrázky - návrhy uživatelského rozhraní
Obr. 12
Uživatelské rozhraní - Úvodní stránka
59
60
Obr. 13
Obrázky - návrhy uživatelského rozhraní
Uživatelské rozhraní - Moje osoba a Zobrazit osobu
Obrázky - návrhy uživatelského rozhraní
Obr. 14
Uživatelské rozhraní - Seznam osob
61
62
Obr. 15
Obrázky - návrhy uživatelského rozhraní
Uživatelské rozhraní - Vytvořit osobu
Obrázky - návrhy uživatelského rozhraní
Obr. 16
Uživatelské rozhraní - Výuka
63
64
Obr. 17
Obrázky - návrhy uživatelského rozhraní
Uživatelské rozhraní – Vytvořit hodinu.
Obrázky - návrhy uživatelského rozhraní
Obr. 18
Uživatelské rozhraní - Zobrazit hodinu
Obr. 19
Uživatelské rozhraní - Seznam kurzů
65
66
Obrázky - návrhy uživatelského rozhraní
Obr. 20
Uživatelské rozhraní - Zobrazit kurz
Obr. 21
Uživatelské rozhraní - Vytvořit kurz
Obrázky - návrhy uživatelského rozhraní
Obr. 22
Uživatelské rozhraní - Upravit kurz
67
68
Obrázky - návrhy uživatelského rozhraní
Obr. 23
Uživatelské rozhraní - Seznam zkoušek
Obr. 24
Uživatelské rozhraní - Zobrazit zkoušku
Obrázky - návrhy uživatelského rozhraní
Obr. 25
Uživatelské rozhraní - Upravit zkoušku
69
70
Obrázky - návrhy uživatelského rozhraní
Obr. 26
Uživatelské rozhraní - Vytvořit zkoušku
Obr. 27
Uživatelské rozhraní - Vyhodnotit zkoušku
Obrázky - návrhy uživatelského rozhraní
Obr. 28
Uživatelské rozhraní - Seznam řidičských oprávnění
71
72
Obr. 29
Obrázky - návrhy uživatelského rozhraní
Uživatelské rozhraní - Zobrazit řidičské oprávnění
Obrázky - návrhy uživatelského rozhraní
Obr. 30
Uživatelské rozhraní – Vytvořit řidičské oprávnění
73
74
Obrázky - návrhy uživatelského rozhraní
Obr. 31
Uživatelské rozhraní - Seznam vozidel
Obr. 32
Uživatelské rozhraní - Zobrazit vozidlo
Obrázky - návrhy uživatelského rozhraní
Obr. 33
Uživatelské rozhraní - Vytvořit vozidlo
75
76
Obrázky - návrhy uživatelského rozhraní
Obr. 34
Uživatelské rozhraní - Seznam učeben
Obr. 35
Uživatelské rozhraní - Zobrazit učebnu
Obrázky - návrhy uživatelského rozhraní
Obr. 36
Uživatelské rozhraní - Vytvořit učebnu
77
78
Tabulky - scénáře
C Tabulky - scénáře Tab. 2
Scénář případu užití Moje osoba
Stručný popis: Umožní přihlášené osobě změnit heslo. Aktéři: Vedoucí, Zaměstnanec, Student. Vstupní podmínky: Žádné. Hlavní scénář: 1. Místo zahrnutí: případ užití Zobrazit osobu. 2. Systém zobrazí formulář na změnu hesla. 3. Uživatel potvrdí změnu hesla. 4. Je-li heslo delší než 6 znaků a shoduje se s potvrzovacím polem, pak: 4.1. Systém změní uživateli heslo. 5. Nebo: Je volán alternativní scénář 1. Výstupní podmínky: 1. Heslo změněno. Alternativní scénář: 1. Informuje uživatele o důvodu selhání změny hesla.
Tabulky - scénáře Tab. 3
79
Scénář případu užití Seznam osob
Stručný popis: Zobrazuje seznam osob existujících v systému podle filtrovacích parametrů. Aktéři: Vedoucí, Zaměstnanec. Vstupní podmínky: Žádné. Hlavní scénář: 1. Systém vykreslí filtrovací formulář. 2. Uživatel vyplní filtrovací parametry. 3. Jestliže parametrům odpovídají nějaké osoby, pak: 3.1. Systém zobrazí tabulku těchto osob se základními informacemi. 3.2. Pro každou osobu je umožněno místo rozšíření: případ užití Zobrazit osobu. 3.3. Pokud je uživatel vedoucí, pak je umožněno místo rozšíření: případ užití Upravit osobu. 4. Nebo: Systém informuje uživatele o neexistenci osob podle zadaných parametrů. Výstupní podmínky: 1. Zobrazené osoby. Alternativní scénář: Žádný.
Tab. 4
Scénář případu užití Vytvořit osobu
Stručný popis: Případ užití umožňuje vedoucímu přidat novou osobu do systému. Aktéři: Vedoucí. Vstupní podmínky: Žádné. Hlavní scénář: 1. Systém vykreslí vstupní formulář. 2. Uživatel vyplní formulářové pole. 3. V případě, že jsou vstupní pole v pořádku, pak: 3.1. Do systému je zavedena nová osoba 4. Nebo: 4.1. pokračuje se alternativním scénářem 1. Výstupní podmínky: 1. Vytvoření osoby. Alternativní scénář: 1. Uživatel je informován jaké vstupní údaje jsou vyplněny špatně.
80 Tab. 5
Tabulky - scénáře Scénář případu užití Upravit osobu
Stručný popis: Případ užití umožňuje vedoucímu upravit osobu v systému. Aktéři: Vedoucí. Vstupní podmínky: Identifikátor osoby Hlavní scénář: 1. Systém vykreslí vstupní formulář s předvyplněnými hodnotami. 2. Uživatel upraví formulářové pole. 3. V případě, že jsou vstupní pole v pořádku, pak: 3.1. Osoba v systému je upravena 4. Nebo: 4.1. pokračuje se alternativním scénářem 1. Výstupní podmínky: 1. Upravení osoby. Alternativní scénář: 1. Uživatel je informován jaké vstupní údaje jsou vyplněny špatně.
Tabulky - scénáře Tab. 6
81
Scénář případu užití Zobrazit výuku
Stručný popis: Zobrazuje seznam existující výuky v systému podle filtrovacích parametrů. Aktéři: Vedoucí, Zaměstnanec, Student. Vstupní podmínky: Žádné. Hlavní scénář: 1. Systém vykreslí filtrovací formulář. 2. Uživatel vyplní filtrovací parametry. 3. Jestliže parametrům odpovídají nějaké hodiny, pak: 3.1. Systém zobrazí tabulku těchto hodin se základními informacemi. 3.2. Pro každou hodinu je umožněno místo rozšíření: případ užití Zobrazit hodinu a upravit hodinu. 4. Nebo: Systém informuje uživatele o neexistenci osob podle zadaných parametrů. 5. Pokud je uživatel vedoucí nebo učitel, pak je umožněno místo rozšíření: případ užití Vytvořit hodinu. Výstupní podmínky: 1. Zobrazená výuka. Alternativní scénář: Žádný.
Tab. 7
Scénář případu užití Zobrazit hodinu
Stručný popis: Zobrazí základní informace výukové hodiny. Aktéři: Student. Vstupní podmínky: Identifikátor hodiny. Hlavní scénář: 1. Systém zobrazí dostupné informace. Výstupní podmínky: 1. Zobrazené informace. Alternativní scénář: Žádný.
82 Tab. 8
Tabulky - scénáře Scénář případu užití Upravit hodinu
Stručný popis: Případ užití umožňuje upravit hodinu v systému. Aktéři: Vedoucí, Zaměstnanec, Student. Vstupní podmínky: Identifikátor hodiny. Hlavní scénář: 1. Systém vykreslí vstupní formulář s předvyplněnými hodnotami. 2. Uživatel upraví formulářové pole. 3. V případě, že jsou vstupní pole v pořádku, pak: 3.1. Hodina v systému je upravena 4. Nebo: 4.1. pokračuje se alternativním scénářem 1. Výstupní podmínky: 1. Upravení hodiny. Alternativní scénář: 1. Uživatel je informován jaké vstupní údaje jsou vyplněny špatně.
Tab. 9
Scénář případu užití Vytvořit hodinu
Stručný popis: Případ užití umožňuje přidat novou hodinu do systému. Aktéři: Vedoucí, Učitel. Vstupní podmínky: Žádné. Hlavní scénář: 1. Systém vykreslí vstupní formulář. 2. Uživatel vyplní formulářové pole. 3. V případě, že jsou vstupní pole v pořádku, pak: 3.1. Do systému je zavedena nová hodina 4. Nebo: 4.1. pokračuje se alternativním scénářem 1. Výstupní podmínky: 1. Vytvoření hodiny. Alternativní scénář: 1. Uživatel je informován jaké vstupní údaje jsou vyplněny špatně.
Tabulky - scénáře Tab. 10
83
Scénář případu užití Zobrazit kurzy
Stručný popis: Zobrazuje seznam existujících kurzů v systému podle filtrovacích parametrů. Aktéři: Vedoucí, Zaměstnanec, Student. Vstupní podmínky: Žádné. Hlavní scénář: 1. Systém vykreslí filtrovací formulář. 2. Uživatel vyplní filtrovací parametry. 3. Jestliže parametrům odpovídají nějaké hodiny, pak: 3.1. Systém zobrazí tabulku těchto kurzů se základními informacemi. 3.2. Pro každý kurz je umožněno místo rozšíření: případ užití Zobrazit kurz a Upravit kurz. 4. Nebo: Systém informuje uživatele o neexistenci kurzů podle zadaných parametrů. Výstupní podmínky: 1. Zobrazené kurzy. Alternativní scénář: Žádný.
Tab. 11
Scénář případu užití Zobrazit kurz
Stručný popis: Zobrazí základní informace kurzu. Aktéři: Vedoucí, Zaměstnanec, Student. Vstupní podmínky: Identifikátor kurzu. Hlavní scénář: 1. Systém zobrazí dostupné informace. Výstupní podmínky: 1. Zobrazené informace. Alternativní scénář: Žádný.
84
Tabulky - scénáře
Tab. 12
Scénář případu užití Upravit kurz
Stručný popis: Případ užití umožňuje upravit kurz v systému a zařadit do něj studenty. Aktéři: Vedoucí. Vstupní podmínky: Identifikátor kurzu. Hlavní scénář: 1. Systém vykreslí vstupní formulář s předvyplněnými hodnotami. 2. Uživatel upraví formulářové pole. 3. V případě, že jsou vstupní pole v pořádku, pak: 3.1. Kurz v systému je upraven 4. Nebo: 4.1. pokračuje se alternativním scénářem 1. Výstupní podmínky: 1. Upravení kurzu. Alternativní scénář: 1. Uživatel je informován jaké vstupní údaje jsou vyplněny špatně.
Tab. 13
Scénář případu užití Vytvořit kurz
Stručný popis: Případ užití umožňuje přidat novou hodinu do systému. Aktéři: Vedoucí. Vstupní podmínky: Žádné. Hlavní scénář: 1. Systém vykreslí vstupní formulář. 2. Uživatel vyplní formulářové pole. 3. V případě, že jsou vstupní pole v pořádku, pak: 3.1. Do systému je zavedena nová hodina 4. Nebo: 4.1. pokračuje se alternativním scénářem 1. Výstupní podmínky: 1. Vytvoření kurzu. Alternativní scénář: 1. Uživatel je informován jaké vstupní údaje jsou vyplněny špatně.
Tabulky - scénáře Tab. 14
85
Scénář případu užití Zobrazit zkoušky
Stručný popis: Zobrazuje seznam existujících zkoušek v systému podle filtrovacích parametrů. Aktéři: Vedoucí, Učitel, Student. Vstupní podmínky: Žádné. Hlavní scénář: 1. Systém vykreslí filtrovací formulář. 2. Uživatel vyplní filtrovací parametry. 3. Jestliže parametrům odpovídají nějaké zkoušky, pak: 3.1. Systém zobrazí tabulku těchto zkoušek se základními informacemi. 3.2. Pro každou zkoušku je umožněno místo rozšíření: případ užití Zobrazit zkoušku, Upravit zkoušku a Vyhodnotit zkoušku. 4. Nebo: Systém informuje uživatele o neexistenci kurzů podle zadaných parametrů. Výstupní podmínky: 1. Zobrazené zkoušky. Alternativní scénář: Žádný.
Tab. 15
Scénář případu užití Zobrazit zkoušku
Stručný popis: Zobrazí základní informace o zkoušce. Aktéři: Zaměstnanec, Vedoucí, Student. Vstupní podmínky: Identifikátor zkoušky. Hlavní scénář: 1. Systém zobrazí dostupné informace. Výstupní podmínky: 1. Zobrazené informace. Alternativní scénář: Žádný.
86
Tabulky - scénáře
Tab. 16
Scénář případu užití Upravit zkoušku
Stručný popis: Případ užití umožňuje upravit zkoušku v systému a přihlásit na ni studenty. Aktéři: Vedoucí. Vstupní podmínky: Identifikátor zkoušky. Hlavní scénář: 1. Systém vykreslí vstupní formulář s předvyplněnými hodnotami. 2. Uživatel upraví formulářové pole. 3. V případě, že jsou vstupní pole v pořádku, pak: 3.1. Zkouška v systému je upravena 4. Nebo: 4.1. pokračuje se alternativním scénářem 1. Výstupní podmínky: 1. Upravení zkoušky. Alternativní scénář: 1. Uživatel je informován jaké vstupní údaje jsou vyplněny špatně.
Tab. 17
Scénář případu užití Vytvořit zkoušku
Stručný popis: Případ užití umožňuje přidat novou zkoušku do systému. Aktéři: Vedoucí. Vstupní podmínky: Žádné. Hlavní scénář: 1. Systém vykreslí vstupní formulář. 2. Uživatel vyplní formulářové pole. 3. V případě, že jsou vstupní pole v pořádku, pak: 3.1. Do systému je zavedena nová zkouška 4. Nebo: 4.1. pokračuje se alternativním scénářem 1. Výstupní podmínky: 1. Vytvoření zkoušky. Alternativní scénář: 1. Uživatel je informován jaké vstupní údaje jsou vyplněny špatně.
Tabulky - scénáře Tab. 18
87
Scénář případu užití Vyhodnotit zkoušku
Stručný popis: Případ užití umožňuje vyhodnotit zkoušku v systému. Aktéři: Vedoucí. Vstupní podmínky: Identifikátor zkoušky Hlavní scénář: 1. Systém vykreslí vstupní formulář se studenty. 2. Uživatel vyplní formulářové pole. 3. V případě, že jsou vstupní pole v pořádku, pak: 3.1. V systému je vyhodnocena zkouška 4. Nebo: 4.1. pokračuje se alternativním scénářem 1. Výstupní podmínky: 1. Vyhodnocení zkoušky. Alternativní scénář: 1. Uživatel je informován jaké vstupní údaje jsou vyplněny špatně.
Tab. 19
Scénář případu užití Zobrazit řidičská oprávnění
Stručný popis: Zobrazuje seznam existujících řidičských oprávnění v systému podle filtrovacích parametrů. Aktéři: Vedoucí, Zaměstnanec. Vstupní podmínky: Žádné. Hlavní scénář: 1. Systém vykreslí filtrovací formulář. 2. Uživatel vyplní filtrovací parametry. 3. Jestliže parametrům odpovídají nějaké řidičské oprávnění, pak: 3.1. Systém zobrazí tabulku těchto oprávnění se základními informacemi. 3.2. Pro každé oprávnění je umožněno místo rozšíření: případ užití Zobrazit řidičské oprávnění a Upravit řidičské oprávnění. 4. Nebo: Systém informuje uživatele o neexistenci oprávnění podle zadaných parametrů. Výstupní podmínky: 1. Zobrazená řidičská oprávnění. Alternativní scénář: Žádný.
88 Tab. 20
Tabulky - scénáře Scénář případu užití Zobrazit řidičské oprávnění
Stručný popis: Zobrazí základní informace o řidičském oprávnění. Aktéři: Zaměstnanec, Vedoucí. Vstupní podmínky: Identifikátor řidičského oprávnění. Hlavní scénář: 1. Systém zobrazí dostupné informace. Výstupní podmínky: 1. Zobrazené informace. Alternativní scénář: Žádný.
Tab. 21
Scénář případu užití Upravit řidičské oprávnění
Stručný popis: Případ užití umožňuje upravit řidičské oprávnění v systému. Aktéři: Vedoucí. Vstupní podmínky: Identifikátor řidičského oprávnění. Hlavní scénář: 1. Systém vykreslí vstupní formulář s předvyplněnými hodnotami. 2. Uživatel upraví formulářové pole. 3. V případě, že jsou vstupní pole v pořádku, pak: 3.1. Řidičské oprávnění v systému je upraveno 4. Nebo: 4.1. pokračuje se alternativním scénářem 1. Výstupní podmínky: 1. Upravení řidičského oprávnění. Alternativní scénář: 1. Uživatel je informován jaké vstupní údaje jsou vyplněny špatně.
Tabulky - scénáře Tab. 22
89
Scénář případu užití Vytvořit řidičské oprávnění
Stručný popis: Případ užití umožňuje přidat nové řidičské oprávnění do systému. Aktéři: Vedoucí. Vstupní podmínky: Žádné. Hlavní scénář: 1. Systém vykreslí vstupní formulář. 2. Uživatel vyplní formulářové pole. 3. V případě, že jsou vstupní pole v pořádku, pak: 3.1. Do systému je zavedeno nové řidičské oprávnění 4. Nebo: 4.1. pokračuje se alternativním scénářem 1. Výstupní podmínky: 1. Vytvoření řidičského oprávnění. Alternativní scénář: 1. Uživatel je informován jaké vstupní údaje jsou vyplněny špatně. Tab. 23
Scénář případu užití Zobrazit vozidla
Stručný popis: Zobrazuje seznam existujících vozidel v systému podle filtrovacích parametrů. Aktéři: Vedoucí, Zaměstnanec. Vstupní podmínky: Žádné. Hlavní scénář: 1. Systém vykreslí filtrovací formulář. 2. Uživatel vyplní filtrovací parametry. 3. Jestliže parametrům odpovídají nějaká vozidla, pak: 3.1. Systém zobrazí tabulku těchto vozidel se základními informacemi. 3.2. Pro každé vozidlo je umožněno místo rozšíření: případ užití Zobrazit vozidla a Upravit vozidla. 4. Nebo: Systém informuje uživatele o neexistenci vozidel podle zadaných parametrů. Výstupní podmínky: 1. Zobrazená vozidla. Alternativní scénář: Žádný.
90 Tab. 24
Tabulky - scénáře Scénář případu užití Zobrazit vozidlo
Stručný popis: Zobrazí základní informace o vozidle. Aktéři: Zaměstnanec, Vedoucí. Vstupní podmínky: Identifikátor vozidla. Hlavní scénář: 1. Systém zobrazí dostupné informace. Výstupní podmínky: 1. Zobrazené informace. Alternativní scénář: Žádný.
Tab. 25
Scénář případu užití Upravit vozidlo
Stručný popis: Případ užití umožňuje upravit vozidlo v systému. Aktéři: Vedoucí. Vstupní podmínky: Identifikátor vozidla. Hlavní scénář: 1. Systém vykreslí vstupní formulář s předvyplněnými hodnotami. 2. Uživatel upraví formulářové pole. 3. V případě, že jsou vstupní pole v pořádku, pak: 3.1. Vozidlo v systému je upraveno 4. Nebo: 4.1. pokračuje se alternativním scénářem 1. Výstupní podmínky: 1. Upravení vozidla. Alternativní scénář: 1. Uživatel je informován jaké vstupní údaje jsou vyplněny špatně.
Tabulky - scénáře Tab. 26
Scénář případu užití Vytvořit vozidlo
Stručný popis: Případ užití umožňuje přidat nové řidičské oprávnění do systému. Aktéři: Vedoucí. Vstupní podmínky: Žádné. Hlavní scénář: 1. Systém vykreslí vstupní formulář. 2. Uživatel vyplní formulářové pole. 3. V případě, že jsou vstupní pole v pořádku, pak: 3.1. Do systému je zavedeno nové vozidlo 4. Nebo: 4.1. pokračuje se alternativním scénářem 1. Výstupní podmínky: 1. Vytvoření vozidla. Alternativní scénář: 1. Uživatel je informován jaké vstupní údaje jsou vyplněny špatně. Tab. 27
Scénář případu užití Zobrazit učebny
Stručný popis: Zobrazuje seznam existujících učeben v systému podle filtrovacích parametrů. Aktéři: Vedoucí, Zaměstnanec. Vstupní podmínky: Žádné. Hlavní scénář: 1. Systém vykreslí filtrovací formulář. 2. Uživatel vyplní filtrovací parametry. 3. Jestliže parametrům odpovídají nějaké učebny, pak: 3.1. Systém zobrazí tabulku těchto učeben se základními informacemi. 3.2. Pro každou učebnu je umožněno místo rozšíření: případ užití Zobrazit učebnu a Upravit učebnu. 4. Nebo: Systém informuje uživatele o neexistenci učeben podle zadaných parametrů. Výstupní podmínky: 1. Zobrazené učebny. Alternativní scénář: Žádný.
91
92 Tab. 28
Tabulky - scénáře Scénář případu užití Zobrazit učebnu
Stručný popis: Zobrazí základní informace o učebně. Aktéři: Zaměstnanec, Vedoucí. Vstupní podmínky: Identifikátor učebny. Hlavní scénář: 1. Systém zobrazí dostupné informace. Výstupní podmínky: 1. Zobrazené informace. Alternativní scénář: Žádný.
Tab. 29
Scénář případu užití Upravit učebnu
Stručný popis: Případ užití umožňuje upravit učebnu v systému. Aktéři: Vedoucí. Vstupní podmínky: Identifikátor učebny. Hlavní scénář: 1. Systém vykreslí vstupní formulář s předvyplněnými hodnotami. 2. Uživatel upraví formulářové pole. 3. V případě, že jsou vstupní pole v pořádku, pak: 3.1. Učebna v systému je upravena 4. Nebo: 4.1. pokračuje se alternativním scénářem 1. Výstupní podmínky: 1. Upravení učebny. Alternativní scénář: 1. Uživatel je informován jaké vstupní údaje jsou vyplněny špatně.
Tabulky - scénáře Tab. 30
Scénář případu užití Vytvořit učebnu
Stručný popis: Případ užití umožňuje přidat novou učebnu do systému. Aktéři: Vedoucí. Vstupní podmínky: Žádné. Hlavní scénář: 1. Systém vykreslí vstupní formulář. 2. Uživatel vyplní formulářové pole. 3. V případě, že jsou vstupní pole v pořádku, pak: 3.1. Do systému je zavedena nová učebna 4. Nebo: 4.1. pokračuje se alternativním scénářem 1. Výstupní podmínky: 1. Vytvoření učebny. Alternativní scénář: 1. Uživatel je informován jaké vstupní údaje jsou vyplněny špatně.
93
