Projektování informačního systému autoškoly

Transkript

1 Mendelova univerzita v Brně Provozně ekonomická fakulta Projektování informačního systému autoškoly Informační systémy (projektování) Běhalová Mária Goňa Jan Horák Martin Janza Čeněk Pavlík Jiří Pirochta Jiří Brno 2015

2

3 Obsah 3 Obsah 1 Úvod a cíl práce Úvod Cíl práce Projektové řízení Analýza okolí Porterův model 5 hybných sil SWOT analýza Identifikační listina projektu SOW Logický rámec projektu Ganttův diagram Kritická cesta WBS Rezervy Organizační schéma týmu Rozpočet Matice zodpovědnosti Rybí kost Analýza rizik Modelování Organizační struktura Procesní model Eriksson Penker Specifikace požadavků Uživatelské požadavky Systémové požadavky Use case modely Modul výuka - Scénáře Sekvenční diagram...41

4 4 Obsah 3.7 Diagram aktivit Diagram tříd Stavový diagram Prototyp GUI Procesní modelování v BPMN Závěr 49 5 Literatura 50

5 Seznam obrázků 5 Seznam obrázků Obr. 1 Identifikační listina projektu 11 Obr. 2 Logický rámec projektu 13 Obr. 3 Ganttův diagram 15 Obr. 4 Kritická cesta 18 Obr. 5 Organizační schéma týmu 23 Obr. 6 Rybí kost 25 Obr. 7 Organizační struktura autoškoly 27 Obr. 8 Procesní model Eriksson Penker 28 Obr. 9 Modul kurzy Use case 32 Obr. 10 Modul osoby Use case 33 Obr. 11 Modul řidičská oprávnění Use case 34 Obr. 12 Modul učebny Use case 35 Obr. 13 Modul vozidla Use case 36 Obr. 14 Modul výuka Use case 37 Obr. 15 Modul zkoušky Use case 38 Obr. 16 Vyhledej hodinu 41 Obr. 17 Vytvoř osobu 42 Obr. 18 Aktivita zobrazení výuky 43 Obr. 19 Aktivita vytvoření hodiny 44 Obr. 20 Diagram tříd 45 Obr. 21 Stavový diagram 46 Obr. 22 Prototyp GUI 47

6 6 Seznam obrázků Obr. 23 Proces přihlášení do autoškoly 48

7 Seznam tabulek 7 Seznam tabulek Tab. 1 Harmonogram projektu 12 Tab. 2 Hierarchická struktura činností WBS 19 Tab. 3 Časové rezervy v plánování projektu 20 Tab. 4 Matice zodpovědnosti 24 Tab. 5 Dopady 26 Tab. 6 Hodnoty rizik 26 Tab. 7 Scénář případu užití Zobrazit výuku 38 Tab. 8 Scénář případu užití Zobrazit hodinu 39 Tab. 9 Scénář případu užití Upravit hodinu 39 Tab. 10 Scénář případu užití Vytvořit hodinu 40

8 8 Ú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. Pro realizaci a začlenění nejnovějších informačních a komunikačních technologií do činnosti podniku se využívá projektů. Tímto se stává projektové řízení klíčovým aspektem v úspěchu jakékoliv organizace. 1.2 Cíl práce Hlavním cílem práce je připravit projektovou dokumentaci pro smyšlenou autoškolu. K realizaci projektu je nutné provést jednotlivé části projektového řízení. Ze všeho nejdříve bude provedena analýza okolí, SWOT analýza a identifikační listina projektu. Následovat bude SOW, logický rámec projektu, Ganttův diagram, WBS, kritická cesta, rezervy, organizační schéma týmu, rozpočet, matice zodpovědnosti, rybí kost, analýza rizik. Druhá část se bude zabývat samotným modelováním procesů smyšlené autoškoly. Postupně budou realizovány následující činnosti: organizační struktura autoškoly, procesní model Eriksson Penker, use case model, 2 scénáře (funkční požadavky), nefunkční požadavky, sekvenční diagram, diagram aktivit, diagram tříd, stavový diagram a prototyp GUI.

9 Projektové řízení 9 2 Projektové řízení 2.1 Analýza okolí Porterův model 5 hybných sil Vyjednávací síla dodavatelů o Autoškola jako podnik poskytující služby nemá příliš mnoho dodavatelů. Jedním z nich je dodavatel výukových materiálů (učebnic, ukázkových testů, atd.), jeho vyjednávací síla však nebude nijak velká, protože autoškola může velmi jednoduše vybrat jiného dodavatele. o Podobné (i když poměrně složitější) to bude z pohledu dodání automobilů používaných na výuku. I zde autoškola má velké množství možností od koho automobily koupit, takže zde také vyjednávací síla prodejců automobilů nebude moc velká. o Jiné to však bude pravděpodobně při dodání systému pro závěrečné zkoušky. Dodavatelů v tomto případě bude určitě méně a i hledání informací o těchto subjektech bude složitější. Především z prvního důvodu bude zde vyjednávací síla dodavatelů poměrně velká. Vyjednávací síla odběratelů o Zákazníky v tomto případě představují (potenciální) studenti samotné autoškoly. Jejich vyjednávací síla je poměrně vysoká. Zákazník se prakticky kdykoliv může rozhodnout pro konkurenční autoškolu a jeho rozhodnutí ho prakticky nic nestojí (kromě již vynaloženého času). Toto rozhodnutí také může učinit z toho důvodu, že existuje poměrně velké množství autoškol (konkurence, viz níže). Tento fakt podporuje také to, že informace o jednotlivých autoškolách jsou velmi jednoduše a rychle k naleznutí. Zákazník se tak může na spoustě věcí s autoškolou dohodnout (např. placení kurzu, či konkrétních termínech výuky). Hrozba nově vstupujících firem o Hrozba vstoupení nového konkurenta je poměrně malá. Je to především z důvodu existence bariér vstupu nových konkurentů na trh. Zde se jedná především o velké prvotní náklady potřebné pro nakoupení vozového parku a vytvoření zázemí autoškoly (garáže, učebny a jejich vybavení). Z tohoto důvodu je vstup na trh velmi obtížný. Konkurence v odvětví

10 10 Projektové řízení o Množství firem na tomto trhu (autoškoly v Brně) je poměrně velké (kolem 90), z toho také plyne poměrně velká konkurence v odvětví v dané oblasti. o Jednotlivé autoškoly se snaží odlišit především cenou, protože na tu jsou zákazníci nejvíce citliví (zákazníky autoškoly jsou nejčastěji studenti, pro které je toto kritérium obzvlášť důležité). Odlišení probíhá v podobě nejrůznějších slev, například sleva pro studenty, množstevní sleva pro více osob nebo při zakoupení více kurzů. Autoškoly se snaží odlišit (získat konkurenční výhodu) samozřejmě i jinak, třeba novým vozovým parkem či dalším vybavením, ale nemá to takový úspěch jako odlišení se nižší cenou. Hrozba nových substitutů o V současné době neexistuje žádná možnost substitutů, protože neexistují žádné instituce podobné autoškole a zkrátka jinak získat řidičský průkaz nelze. 2.2 SWOT analýza Silné stránky Slabé stránky Příležitosti Hrozby o Dobrá lokalita autoškoly (snadná dostupnost) o Velké množství nabízených kurzů (skupin řízení) o Moderní vozový park osobních automobilů o Možnost zapůjčení a zakoupení studijních materiálů o Poměrně levné kurzy (především pro studenty) o Chybějící informační systém o Dlouhé proluky mezi zahájením kurzů o Zastaralé motocykly a dodávky o Nespolupráce se středními školami o Drahé kondiční jízdy o Zvyšující se počet automobilů o Novela vyhlášky (těžší získání ŘP) o Velké množství konkurentů o Velká vyjednávací síla zákazníků

11 Projektové řízení Identifikační listina projektu Obr. 1 Identifikační listina projektu 2.4 SOW Purpose: Tento projekt je zpracován z důvodu zlepšení konkurence schopnosti dané autoškoly. Měl by byt přínosem pro fungování a zrychleni administrativy a zvýšení počtu studentů. Scope of Work: V rámci projektu je navržena a implementována aplikace pro autoškolu. Práce zahrnuje analýzu, návrh, implementaci, testovaní a zavedení aplikace do systému autoškoly. Location of Work: Místem konáni porad a kontroly postupu projektu je budova Q Mendelovi univerzityv Brně. Následné dílčí úkoly jsou pak zpracovány v tzv. Home Office, kde jednotlivý členové teamu pracují na svých úkolech. Period of Performance: Jednotlivé časové úseky projektu jsou zobrazeny v následující tabulce

12 12 Projektové řízení Tab. 1 Harmonogram projektu Zahájení projektu Analýza a návrh Zhodnocení řešení Nasazení Ukončení projektu Deliverables Schedule: Nejdříve je provedena analýza problému, následně na tuto analýzu je předložen návrh řešení. Pokud jsou vyřešeny všechny nedostatky návrhu pokračuje se k implementaci a zavedeni do firmy. Acceptance Criteria: Po vypracování návrhu, si zadavatel zkontroluje specifikace a poskytne zpětnou vazbu dodavateli. Tento proces se opakuje, dokud zadavatel není spokojen s návrhem a následně se pokračuje k implantaci. Special Requirements: K tomuto projektu jsou zapotřebí softwarové nástroje jako Microsoft Office a Enterprise architect. Dále pak je zapotřebí dostatečný počet pracovních stanic (PC, notebook). Pro potřebu dojezdu na porady je potřeba vlastnit řidičsky průkaz skupiny B nebo průkaz městské hromadné dopravy. Nejsou potřeba zadně certifikace pro práci na projektu. Type of Contract/Payment Schedule: Interní rozpočet byl stanoven na korun. Tento rozpočet by měl být dostatečný pro pokrytí veškerých potřeb během vývoje aplikace a zavedení. Platba za hotový projekt bude provedena po úspěšném zavedení a prvotním zaškolení zaměstnanců autoškoly.

13 Projektové řízení Logický rámec projektu Obr. 2 Logický rámec projektu

14 14 Projektové řízení 2.6 Ganttův diagram

15 Projektové řízení 15 Obr. 3 Ganttův diagram

16 16 Projektové řízení 2.7 Kritická cesta

17 Projektové řízení 17

18 18 Projektové řízení Obr. 4 Kritická cesta

19 Projektové řízení WBS Tab. 2 Hierarchická struktura činností WBS Vývoj SW pro autoškolu 1 Analýza 1.1 Specifikace požadavků Získání požadavků od zákazníka Zmapování vnitřních procesů Tvorba akceptačních testů 1.2 Analýza požadavků Funkční analýza Technická analýza Analýza rizik Předběžný návrh a cenový odhad Zpracování zpětné vazby od zákazníka 2 Návrh 2.1 Architektonický návrh Návrh struktury aplikace Návrh modulů aplikace Funkční návrh Technický návrh 2.2 Grafický návrh Návrh grafického designu Návrh Uživatelského rozhraní 3 Tvorba aplikace 3.1 Implementace programového jádra Implementace základní kostry aplikace Implementace modulů Implementace funkcí a metod 3.2 Implementace grafického rozhraní Implementace grafického designu Implementace uživatelského rozhraní 3.3 Fukční testy Jednotkové testy Testy funkcí a metod 3.4 Modulární testy Test modulu Osoba

20 20 Projektové řízení 2.9 Rezervy Test modulu Výuka Test modulu Kurz Test modulu Vozidlo Test modulu Zkouška Test modulu Učebna Test modulu Řidičské oprávnění 4 Dokončení aplikace 4.1 Sestavení aplikace Propojení modulů Napojení grafické části k jádru aplikace Systémové testy 4.2 Předání aplikace Předvedení aplikace zákazníkovy Akceptační testy Úpravy aplikace Tvorba dokumentace 5 Ukončení projektu 5.1 Zhodnocení a analýza projektu Vyhodnocení rentability projektu Časová analýza Celkové zhodnocení projektu Tab. 3 Časové rezervy v plánování projektu Název úkolu Celková časová rezerva Vývoj SW pro autoškolu 0 dny 1 Analýza 0 dny 1.1 Specifikace požadavků 0 dny Získání požadavků od zákazníka 0 dny Zmapování vnitřních procesů 4 dny Tvorba akceptačních testů 4 dny 1.2 Analýza požadavků 0 dny Funkční analýza 0 dny Technická analýza 0 dny

21 Projektové řízení Analýza rizik 0 dny Předběžný návrh a cenový odhad 0 dny Zpracování zpětné vazby od zákazníka 0 dny 2 Návrh 0 dny 2.1 Architektonický návrh 0 dny Návrh struktury aplikace 0 dny Návrh modulů aplikace 0 dny Funkční návrh 0 dny Technický návrh 0 dny 2.2 Grafický návrh 0 dny Návrh grafického designu 15 dny Návrh Uživatelského rozhraní 15 dny 3 Tvorba aplikace 0 dny 3.1 Implementace programového jádra 0 dny Implementace základní kostry aplikace 0 dny Implementace modulů 0 dny Implementace funkcí a metod 20 dny 3.2 Implementace grafického rozhraní 0 dny Implementace grafického designu 25 dny Implementace uživatelského rozhraní 25 dny 3.3 Fukční testy 4 dny Jednotkové testy 2 dny Testy funkcí a metod 2 dny 3.4 Modulární testy 12 dny Test modulu Osoba 12 dny Test modulu Výuka 12 dny Test modulu Kurz 12 dny Test modulu Vozidlo 12 dny Test modulu Zkouška 12 dny

22 22 Projektové řízení Test modulu Učebna 12 dny Test modulu Řidičské oprávnění 12 dny 4 Dokončení aplikace 0 dny 4.1 Sestavení aplikace 0 dny Propojení modulů 10 dny Napojení grafické části k jádru aplikace 10 dny Systémové testy 12 dny 4.2 Předání aplikace 0 dny Předvedení aplikace zákazníkovy 0 dny Akceptační testy 5 dny Úpravy aplikace 7 dny Tvorba dokumentace 26 dny 5 Ukončení projektu 0 dny 5.1 Zhodnocení a analýza projektu 0 dny Vyhodnocení rentability projektu 0 dny Časová analýza 0 dny Celkové zhodnocení projektu 0 dny

23 Projektové řízení Organizační schéma týmu Obr. 5 Organizační schéma týmu 2.11 Rozpočet Obr. 6 Rozpočet

24 24 Projektové řízení 2.12 Matice zodpovědnosti Tab. 4 Matice zodpovědnosti Oddělení Manažer Analytici Designeři Programátoři Testeři Osoba Jan Goňa Čeněk JanzaJiří Pavlík Mária Běhalová Jiří Pirochta Martin Horák Čeněk JanzaJří Pavlík Mária Běhalová Úkoly Specifikace požadavků Z S S Analýza požadavků Z S Architektonický návrh S S Z S Grafický návrh S Z S Implementace programového jádra Z S S Implementace grafického rozhraní S S Z Fuknční testy Z S Modulární testy S Z Sestavení aplikace S S S Z S Předání aplikace Z S S Zhodnocení a analýza projektu Z S S Z = zodpovídá S = Spolupracuje

25 Projektové řízení Rybí kost Obr. 7 Rybí kost

26 26 Projektové řízení 2.14 Analýza rizik Tab. 5 VVD VD SD MD VMD Tab. 6 VVHR VHR SHR MHR Dopady velmi vysoký vysoký střední dopad malý velmi malý Hodnoty rizik velmi vyská hodnota rizika vysoká střední malá

27 Modelování 27 3 Modelování 3.1 Organizační struktura Obr. 8 Organizační struktura autoškoly

28 28 Modelování 3.2 Procesní model Eriksson Penker Obr. 9 Procesní model Eriksson Penker 3.3 Specifikace požadavků 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či-

29 Modelování 29 tel 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. 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, , 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.

30 30 Modelování Systémové požadavky Z dostupných informací z uživatelských požadavků jsou vypracovány funkční a nefunkč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í specifikace 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ů: 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. 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. 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. 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ášť. 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. Modul vozidlo poskytuje evidenci vozidel. Hlavně určování typu a stavu vozidla. Modul učebna slouží k zadávání provozoven, kde se vykonává výuka teorie. Nefunkční požadavky

31 Modelování 31 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 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.

32 32 Modelování 3.4 Use case modely Obr. 10 Modul kurzy Use case

33 Modelování 33 Obr. 11 Modul osoby Use case

34 34 Modelování Obr. 12 Modul řidičská oprávnění Use case

35 Modelování 35 Obr. 13 Modul učebny Use case

36 36 Modelování Obr. 14 Modul vozidla Use case

37 Modelování 37 Obr. 15 Modul výuka Use case

38 38 Modelování Obr. 16 Modul zkoušky Use case 3.5 Modul výuka - Scénáře Tab. 7 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:

39 Modelování 39 Žá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. 4. Nebo: Systém informuje uživatele o neexistenci výuky podle zadaných parametrů. Výstupní podmínky: 1. Zobrazená výuka. Alternativní scénář: Žádný. Tab. 8 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ý. Tab. 9 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.

40 40 Modelování 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. 10 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ě.

41 Modelování Sekvenční diagram Obr. 17 Vyhledej hodinu

42 42 Modelování Obr. 18 Vytvoř osobu

43 Modelování Diagram aktivit Obr. 19 Aktivita zobrazení výuky

44 44 Modelování Obr. 20 Aktivita vytvoření hodiny

45 Modelování Diagram tříd Obr. 21 Diagram tříd

46 46 Modelování 3.9 Stavový diagram Obr. 22 Stavový diagram

47 Modelování Prototyp GUI Obr. 23 Prototyp GUI

48 48 Modelování 3.11 Procesní modelování v BPMN Obr. 24 Proces přihlášení do autoškoly

49 Závěr 49 4 Závěr Na závěr můžeme konstatovat, že jsem si vyzkoušeli projektové řízení na realizaci informačního systému autoškoly. Na začátku projektu byla vytvořena identifikační listina projektu, SOW a logický rámec. Nelze opomenout i vytvoření analýzy okolí a SWOT analýzu. Následovalo vytvoření WBS, stanovení rozpočtu, rizik a struktury projektového týmu. V práci je také zahrnuta kritická cesta, ganttův diagram. V druhé části práce bylo provedeno samotné modelování. Tedy procesní modelovaní pomocí notace Eriksson Penker a BPMN. Následovaly diagramy UML a stanovení požadavků na systém.