Informační systém autoškoly

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. Pirochta Jiří Brno 2014

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 Úvod a cíl práce 14 1.1 Úvod...14 1.2 Cíl práce...14 2 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 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 3 Metodika řešení 23 3.1 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 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 4 Vlastní řešení 28 4.1 Autoškola Liška a její činnosti... 28 4.1.1 Současné řešení... 28 4.2 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 ER Diagram...43 4.5 Návrh uživatelského rozhraní...43 4.6 Implementace...43 5 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 Metodika řešení 3.2.5 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. výcvik k získání nebo rozšíření skupin řidičského oprávnění A, B, C,D,E,T 2. provedení zkoušky z odborné způsobilosti k navrácení řidičského oprávnění 3. akreditované školení řidičů 4. š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-