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

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

Obsah

3

Obsah 1

2

Úvod a cíl práce

8

1.1

Úvod .......................................................................................................... 8

1.2

Cíl práce .................................................................................................... 8

Projektové řízení 2.1

9

Analýza okolí............................................................................................. 9

2.1.1

Porterův model 5 hybných sil ........................................................... 9

2.2

SWOT analýza..........................................................................................10

2.3

Identifikační listina projektu................................................................... 11

2.4

SOW ......................................................................................................... 11

2.5

Logický rámec projektu ...........................................................................13

2.6

Ganttův diagram ......................................................................................14

2.7

Kritická cesta............................................................................................16

2.8

WBS..........................................................................................................19

2.9

Rezervy.................................................................................................... 20

2.10 Organizační schéma týmu ...................................................................... 23 2.11 Rozpočet.................................................................................................. 23 2.12 Matice zodpovědnosti ............................................................................. 24 2.13 Rybí kost ................................................................................................. 25 2.14 Analýza rizik............................................................................................ 26 3

Modelování

27

3.1

Organizační struktura............................................................................. 27

3.2

Procesní model Eriksson Penker............................................................ 28

3.3

Specifikace požadavků ............................................................................ 28

3.3.1

Uživatelské požadavky .................................................................... 28

3.3.2

Systémové požadavky ..................................................................... 30

3.4

Use case modely...................................................................................... 32

3.5

Modul výuka - Scénáře ........................................................................... 38

3.6

Sekvenční diagram...................................................................................41

4

Obsah

3.7

Diagram aktivit ........................................................................................43

3.8

Diagram tříd ............................................................................................45

3.9

Stavový diagram ..................................................................................... 46

3.10 Prototyp GUI ...........................................................................................47 3.11 Procesní modelování v BPMN................................................................ 48 4

Závěr

49

5

Literatura

50

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

Obr. 23

Seznam obrázků

Proces přihlášení do autoškoly

48

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

Ú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.

Projektové řízení

9

2 Projektové řízení 2.1 Analýza okolí 2.1.1

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


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 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) • Slabé stránky o Chybějící informační systém o o o o

Dlouhé proluky mezi zahájením kurzů Zastaralé motocykly a dodávky Nespolupráce se středními školami Drahé kondiční jízdy

• Příležitosti o Zvyšující se počet automobilů o Novela vyhlášky (těžší získání ŘP) • Hrozby o Velké množství konkurentů o Velká vyjednávací síla zákazníků


11

2.3 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


Tab. 1

Harmonogram projektu

Zahájení projektu Analýza a návrh Zhodnocení řešení Nasazení Ukončení projektu •

•

•

•

1. 1. 2015 1. 2. 2015 1. 6. 2015 1. 9. 2015 1. 1. 2016

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 1 000 000. 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.


2.5 Logický rámec projektu

Obr. 2

Logický rámec projektu

13

14

2.6 Ganttův diagram



Obr. 3

Ganttův diagram

15

16

2.7 Kritická cesta



17

18

Obr. 4


Kritická cesta


2.8 WBS Tab. 2

Hierarchická struktura činností WBS

Vývoj SW pro autoškolu 1 Analýza 1.1 Specifikace požadavků 1.1.1 Získání požadavků od zákazníka 1.1.2 Zmapování vnitřních procesů 1.1.3 Tvorba akceptačních testů 1.2 Analýza požadavků 1.2.1 Funkční analýza 1.2.2 Technická analýza 1.2.3 Analýza rizik 1.2.4 Předběžný návrh a cenový odhad 1.2.5 Zpracování zpětné vazby od zákazníka 2 Návrh 2.1 Architektonický návrh 2.1.1 Návrh struktury aplikace 2.1.2 Návrh modulů aplikace 2.1.3 Funkční návrh 2.1.4 Technický návrh 2.2 Grafický návrh 2.2.1 Návrh grafického designu 2.2.2 Návrh Uživatelského rozhraní 3 Tvorba aplikace 3.1 Implementace programového jádra 3.1.1 Implementace základní kostry aplikace 3.1.2 Implementace modulů 3.1.3 Implementace funkcí a metod 3.2 Implementace grafického rozhraní 3.2.1 Implementace grafického designu 3.2.2 Implementace uživatelského rozhraní 3.3 Fukční testy 3.3.1 Jednotkové testy 3.3.2 Testy funkcí a metod 3.4 Modulární testy 3.4.1 Test modulu Osoba

19

20


3.4.2 Test modulu Výuka 3.4.3 Test modulu Kurz 3.4.4 Test modulu Vozidlo 3.4.5 Test modulu Zkouška 3.4.6 Test modulu Učebna 3.4.7 Test modulu Řidičské oprávnění 4 Dokončení aplikace 4.1 Sestavení aplikace 4.1.1 Propojení modulů 4.1.2 Napojení grafické části k jádru aplikace 4.1.3 Systémové testy 4.2 Předání aplikace 4.2.1 Předvedení aplikace zákazníkovy 4.2.2 Akceptační testy 4.2.3 Úpravy aplikace 4.2.4 Tvorba dokumentace 5 Ukončení projektu 5.1 Zhodnocení a analýza projektu 5.1.1 Vyhodnocení rentability projektu 5.1.2 Časová analýza 5.1.3 Celkové zhodnocení projektu

2.9 Rezervy Tab. 3

Časové rezervy v plánování projektu

Název úkolu

Vývoj SW pro autoškolu 1 Analýza 1.1 Specifikace požadavků 1.1.1 Získání požadavků od zákazníka 1.1.2 Zmapování vnitřních procesů 1.1.3 Tvorba akceptačních testů 1.2 Analýza požadavků 1.2.1 Funkční analýza 1.2.2 Technická analýza

Celková časová rezerva

0 dny 0 dny 0 dny 0 dny 4 dny 4 dny 0 dny 0 dny 0 dny


1.2.3 Analýza rizik 1.2.4 Předběžný návrh a cenový odhad 1.2.5 Zpracování zpětné vazby od zákazníka 2 Návrh 2.1 Architektonický návrh 2.1.1 Návrh struktury aplikace 2.1.2 Návrh modulů aplikace 2.1.3 Funkční návrh 2.1.4 Technický návrh 2.2 Grafický návrh 2.2.1 Návrh grafického designu 2.2.2 Návrh Uživatelského rozhraní 3 Tvorba aplikace 3.1 Implementace programového jádra 3.1.1 Implementace základní kostry aplikace 3.1.2 Implementace modulů 3.1.3 Implementace funkcí a metod 3.2 Implementace grafického rozhraní 3.2.1 Implementace grafického designu 3.2.2 Implementace uživatelského rozhraní 3.3 Fukční testy 3.3.1 Jednotkové testy 3.3.2 Testy funkcí a metod 3.4 Modulární testy 3.4.1 Test modulu Osoba 3.4.2 Test modulu Výuka 3.4.3 Test modulu Kurz 3.4.4 Test modulu Vozidlo 3.4.5 Test modulu Zkouška

21

0 dny 0 dny 0 dny 0 dny 0 dny 0 dny 0 dny 0 dny 0 dny 0 dny 15 dny 15 dny 0 dny 0 dny 0 dny 0 dny 20 dny 0 dny 25 dny 25 dny 4 dny 2 dny 2 dny 12 dny 12 dny 12 dny 12 dny 12 dny 12 dny

22

3.4.6 Test modulu Učebna 3.4.7 Test modulu Řidičské oprávnění 4 Dokončení aplikace 4.1 Sestavení aplikace 4.1.1 Propojení modulů 4.1.2 Napojení grafické části k jádru aplikace 4.1.3 Systémové testy 4.2 Předání aplikace 4.2.1 Předvedení aplikace zákazníkovy 4.2.2 Akceptační testy 4.2.3 Úpravy aplikace 4.2.4 Tvorba dokumentace 5 Ukončení projektu 5.1 Zhodnocení a analýza projektu 5.1.1 Vyhodnocení rentability projektu 5.1.2 Časová analýza 5.1.3 Celkové zhodnocení projektu


12 dny 12 dny 0 dny 0 dny 10 dny 10 dny 12 dny 0 dny 0 dny 5 dny 7 dny 26 dny 0 dny 0 dny 0 dny 0 dny 0 dny


2.10 Organizační schéma týmu

Obr. 5

Organizační schéma týmu

2.11 Rozpočet

Obr. 6

Rozpočet

23

24


2.12 Matice zodpovědnosti Tab. 4

Matice zodpovědnosti Oddělení Osoba

Manažer Analytici Designeři Programátoři Testeři Jan Goňa Čeněk Janza Jiří Pavlík Mária Běhalová Jiří Pirochta Martin Horák Čeněk JanzaJří Pavlík Mária Běhalová

Úkoly Specifikace požadavků Analýza požadavků Architektonický návrh Grafický návrh Implementace programového jádra Implementace grafického rozhraní Fuknční testy Modulární testy Sestavení aplikace Předání aplikace Zhodnocení a analýza projektu

Z = zodpovídá S = Spolupracuje

Z S

S Z S

S S Z S

S Z

S Z S

S

S Z

S Z S

S Z Z

S

S S

S

Z S

S

S Z S


2.13 Rybí kost

Obr. 7

Rybí kost

25

26


2.14 Analýza rizik Tab. 5

Dopady

VVD VD SD MD VMD

velmi vysoký vysoký střední dopad malý velmi malý

Tab. 6

Hodnoty rizik

VVHR VHR SHR MHR

velmi vyská hodnota rizika vysoká střední malá

Modelování

3 Modelování 3.1 Organizační struktura

Obr. 8

Organizační struktura autoškoly

27

28

Modelování

3.2 Procesní model Eriksson Penker

Obr. 9

Procesní model Eriksson Penker

3.3 Specifikace požadavků 3.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či-

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, 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.

30

Modelování

3.3.2

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

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

Modelování

3.4 Use case modely

Obr. 10

Modul kurzy – Use case

Modelování

Obr. 11

Modul osoby – Use case

33

34

Obr. 12

Modelování

Modul řidičská oprávnění – Use case

Modelování

Obr. 13

Modul učebny – Use case

35

36

Obr. 14

Modelování

Modul vozidla – Use case

Modelování

Obr. 15

Modul výuka – Use case

37

38

Obr. 16

Modelování

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:

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

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ě.

Modelování

3.6 Sekvenční diagram

Obr. 17

Vyhledej hodinu

41

42

Obr. 18

Modelování

Vytvoř osobu

Modelování

3.7 Diagram aktivit

Obr. 19

Aktivita zobrazení výuky

43

44

Obr. 20

Modelování

Aktivita vytvoření hodiny

Modelování

3.8 Diagram tříd

Obr. 21

Diagram tříd

45

46

Modelování

3.9 Stavový diagram

Obr. 22

Stavový diagram

Modelování

3.10 Prototyp GUI

Obr. 23

Prototyp GUI

47

48

Modelování

3.11 Procesní modelování v BPMN

Obr. 24

Proces přihlášení do autoškoly

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.

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

Recommend Documents