Information System of Art School

(1)

VYSOK ´

E U ˇ

CEN´I TECHNICK ´

E V BRN ˇ

E

BRNO UNIVERSITY OF TECHNOLOGY

FAKULTA INFORMA ˇ

CN´ICH TECHNOLOGI´I

´

USTAV INFORMA ˇ

CN´ICH SYST ´

EM ˚

U

FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF INFORMATION SYSTEMS

INFORMA ˇ

CN´I SYST ´

EM PRO ZU ˇ

S

INFORMATION SYSTEM OF ART SCHOOL

BAKAL ´

A ˇ

RSK ´

A PR ´

ACE

BACHELOR’S THESIS

AUTOR PR ´

ACE

PAVEL SLAB ´

Y

AUTHOR

VEDOUC´I PR ´

ACE

Mgr. ROMAN TRCHAL´IK

SUPERVISOR

(2)

Abstrakt

Práce pojednává o vývoji informaˇcn´ıho systému pro základn´ı umˇeleckou ˇskolu. Jednot-livé kapitoly se vˇenuj´ı analýze poˇzadavk˚u zákazn´ıka, návrhu systému podle poˇzadavk˚u, plánován´ı projektu (Gantt˚uv diagram, ˇr´ızen´ı rizik), samotné implementaci systému v ja-zyce Ruby za pouˇzit´ı frameworku Ruby on Rails a jeho testován´ı a nasazen´ı v reálných podm´ınkách.

Abstract

This work deals with the development of the Information System for Primary Art School. Individual chapters contains the analysis of customer requirements, system designing ac-cording to the requirements, project planning (Gantt chart, risk management), the imple-mentation written in the Ruby language using the framework Ruby on Rails and its testing and deployment in real-world conditions.

Kl´ıˇ

cov´

a slova

informaˇcn´ı systém, ZUˇS, základn´ı umˇelecká ˇskola, Ruby, RUby on Rails, management pro-jektu, ˇr´ızen´ı rizik, plánován´ı, Gantt˚uv diagram

Keywords

Information System, School of Music, Art School, Ruby, Ruby on Rails, project manage-ment, risk managemanage-ment, planning, Gantt Chart

Citace

(3)

Informaˇ

cn´ı syst´

em pro ZUˇ

S

Prohl´

aˇ

sen´ı

Prohlaˇsuji, ˇze jsem tuto bakal´aˇrskou pr´aci vypracoval samostatnˇe pod veden´ım pana Mgr. Ro-mana Trchal´ıka.

. . . . Pavel Slab´y 14. kvˇetna 2013

Podˇ

ekov´

an´ı

Dˇekuji panu Mgr. Tomáˇsi Zouharovi a Alenˇe Svobodové, Dis. za odborné konzultace.

c

Pavel Slab´y, 2013.

Tato práce vznikla jako ˇskoln´ı d´ılo na Vysokém uˇcen´ı technickém v Brnˇe, Fakultˇe in-formaˇcn´ıch technologi´ı. Práce je chránˇena autorským zákonem a jej´ı uˇzit´ı bez udˇelen´ı oprávnˇen´ı autorem je nezákonné, s výjimkou zákonem definovaných pˇr´ıpad˚u.

(4)

Obsah

1 Uvod´ 4

2 Anal´yza poˇzadavk˚u 5

2.1 Z´ısk´av´an´ı informac´ı. . . 5

2.1.1 Interview . . . 5

2.1.2 Anal´yza st´avaj´ıc´ıch ˇreˇsen´ı . . . 5

2.2 Poˇzadavky na syst´em. . . 6

3 N´avrh syst´emu 7 3.1 Diagram pˇr´ıpad˚u uˇzit´ı . . . 7

3.2 Entity Relationship Diagram . . . 8

4 Pl´anov´an´ı 11 4.1 Zivotn´ı cyklus softwareˇ . . . 11

4.1.1 Etapy ˇzivotn´ıho cyklu software . . . 11

4.1.2 Modely ˇzivotn´ıho cyklu software . . . 11

4.2 Pl´an v´yvoje . . . 12

4.2.1 Definice rol´ı. . . 12

4.3 Gantt˚uv diagram . . . 12

4.4 R´ızen´ı rizikˇ . . . 14

4.4.1 Seznam rizik . . . 14

4.4.2 Skuteˇcnˇe projeven´e probl´emy . . . 14

5 Implementace 16 5.1 Datov´y model . . . 16 5.2 Importov´an´ı. . . 16 5.3 Ruby . . . 17 5.3.1 Duck Typing . . . 17 5.4 Ruby on Rails . . . 19

5.4.1 Model – View – Controller (MVC) . . . 19

5.4.2 ActiveRecord . . . 19

5.4.3 Polymorfick´a vazba . . . 19

5.4.4 Convention over Configuration . . . 19

5.4.5 DRY . . . 20

5.5 RubyGems . . . 20

(5)

6 Testov´an´ı a moˇznosti rozˇs´ıˇren´ı 22

6.1 Testov´an´ı . . . 22

6.2 Moˇzn´a rozˇs´ıˇren´ı. . . 23

7 Závˇer 24 A Obsah CD 26 A.1 Adresáˇrová struktura na CD . . . 26

B Instalace a spuˇstˇen´ı 27 B.1 Instalace. . . 27

B.1.1 Prerekvizity . . . 27

B.1.2 Instalace. . . 27

B.1.3 Konfigurace . . . 27

(6)

Seznam obr´

azk˚

u

3.1 Diagram pˇr´ıpad˚u uˇzit´ı. . . 7

3.2 Entity relationship diagram. . . 8

3.3 Stavov´y diagram ˇz´adosti – worflow. . . 10

4.1 Gantt˚uv diagram.. . . 13

4.2 Seznam ´ukol˚u Ganttova diagramu. . . 15

5.1 N´ahled pˇrehledu. . . 17

5.2 N´ahled detailu. . . 18

(7)

Kapitola 1

´

Uvod

C´ılem této práce je popsat vývoj zákaznického software – informaˇcn´ıho systému pro základn´ı umˇelecké ˇskoly. Základn´ı umˇelecké ˇskoly maj´ı specifické poˇzadavky na informaˇcn´ı systém, proto nen´ı úplnˇe pˇrirozené pouˇz´ıvat informaˇcn´ı systémy urˇcené pro základn´ı nebo stˇredn´ı ˇskoly. Hlavn´ım rozd´ılem je pˇrevaˇzuj´ıc´ı pod´ıl individuáln´ı výuky nad skupinovou.

V 2. ˇcásti práce popisuji zp˚usob z´ıskáván´ı informac´ı o potˇrebách uˇzivatel˚u, hodnot´ım konkurenˇcn´ı ˇreˇsen´ı a stanovuji c´ıle, kterých chci bˇehem implementaˇcn´ı fáze dosáhnout.

V 3. kapitole navrhuji informaˇcn´ı systém pˇredevˇs´ım pomoc´ı popisného jazyka UML. Celý projekt plánuji s kapitole4.

Kapitola5je vˇenována samotné implementaci systému, popisu specifik pouˇzitého jazyka

a frameworku. Objasˇnuji v n´ı detaily moj´ı implementace.

V kapitole6ukazuji moˇznosti testován´ı a ukazuji mnou pouˇzité testovac´ı procedury. Na konci této kapitoly také ukazuji pˇr´ıpadný moˇzný smˇer dalˇs´ıho vývoje.

(8)

Kapitola 2

Anal´

yza poˇ

zadavk˚

u

Impulsem k vytvoˇren´ı informaˇcn´ıho systému je obvykle snaha uˇsetˇrit uˇzivatel˚um ˇcas. Umoˇznit jim efektivnˇe vyˇrizovat potˇrebnou agendu. Výpoˇcetn´ı technologie umoˇzˇnuj´ı také spoustu operac´ı automatizovat. Nejdˇr´ıve je tedy nutné z´ıskat informace o tom, jak uˇzivatelé bˇeˇznˇe pracuj´ı, nalézt kritická m´ısta tˇechto pracovn´ıch proces˚u.

Výstupem této fáze vývoje aplikace je seznam poˇzadavk˚u, které by mˇela splˇnovat.

2.1 Z´ısk´

av´

an´ı informac´ı

2.1.1 Interview

Interview spoˇc´ıvá v rozhovoru s budouc´ım uˇzivatelem systému. Rozhovor m˚uˇze být volný, nebo pˇredepsaný protokolem (pˇredevˇs´ım pro potˇreby porovnáván´ı výsledk˚u u r˚uzných uˇzivatel˚u nebo pro sjednocen´ı v´ıce dotazovatel˚u). P´ısemná forma interview se nazývá do-tazn´ık.

Sám jsem volným zp˚usobem vyslechl potˇreby nˇekolika uˇzivatel˚u. Hlavn´ım uˇzivatelem tohoto informaˇcn´ıho systému bude Mgr. Tomáˇs Zouhar, ˇreditel Základn´ı umˇelecké ˇskoly

Tiˇsnov. D´ale jsem podrobil voln´emu interview Alenu Svobodovou, Dis., uˇcitelku klav´ıru

brnˇenské Základn´ı umˇelecké ˇskoly Frantiˇska J´ılka.

Z interview s tˇemito dvˇema lidmi vyplynuly n´asleduj´ıc´ı poˇzadavky popsan´e v kapitole 2.2

2.1.2 Anal´yza st´avaj´ıc´ıch ˇreˇsen´ı

Pˇredpokládám, ˇze existuje moˇznost, ˇze se touto problematikou jiˇz nˇekdo zabýval. Proto je potˇreba nejdˇr´ıve proj´ıt, pˇr´ıpadnˇe i vyzkouˇset stávaj´ıc´ı ˇreˇsen´ı a posoudit jejich vhodnost k nasazen´ı v c´ılové organizaci.

Fedena

Prvn´ı z´astupce konkurenˇcn´ıho software je Fedena psan´a v jazyce Ruby a s frameworkem

Ruby on Rails. Tento projekt je ˇs´ıˇren jako open-source Jej´ı pozitiva jsou kvalitn´ı grafick´y n´avrh a mobiln´ı verze.

(9)

iZUˇS ˇ

Ceský projekt webového informaˇcn´ıho systému iZUˇS vypadá velmi nadˇejnˇe. Má ale mnoho souˇcást´ı, které podle ˇreditele Mgr. Tomáˇse Zouhara jeho ˇskola nepotˇrebuje, napˇr´ıklad tˇr´ıdn´ı kniha. Cen´ık tohoto systému nezávis´ı na vyuˇz´ıvaných souˇcástech, ale pouze na poˇctu ˇzák˚u, coˇz je nevýhodné.

Klasifikace

Jedná se ˇceský projekt psaný v jazyce Visual C++ napsaný Pavlem Holcem. Tento systém je dosus pouˇz´ıvaný v ZUˇS v Tiˇsnovˇe, pro kterou je tento systém urˇcen. Jeho nevýhodou je, ˇ

ze se mus´ı instalovat na pracovn´ı stanice. V tomto programu také chyb´ı moˇznost pˇresun˚u výuky a t´ım také moˇznosti vyplˇnován´ı výkaz˚u pracovn´ı doby.

ˇ

Reˇsen´ı pro z´akladn´ı a stˇredn´ı ˇskoly

Základn´ı umˇelecké ˇskoly maj´ı specifické poˇzadavky na informaˇcn´ı systém, proto nen´ı úplnˇe pˇrirozené pouˇz´ıvat informaˇcn´ı systémy urˇcené pro základn´ı nebo stˇredn´ı ˇskoly. Hlavn´ım rozd´ılem je pˇrevaˇzuj´ıc´ı pod´ıl individuáln´ı výuky nad skupinovou.

2.2 Poˇ

zadavky na syst´

em

• Systém mus´ı umoˇznit spravovat matriku (evidence ˇzák˚u, jejich rodiˇc˚u, uˇcitel˚u). • Systém mus´ı umoˇznit efektivnˇe spravovat pracovn´ı dobu. Nejd˚uleˇzitˇejˇs´ı dokumenty

z t´eto oblasti jsou Dohoda o pracovn´ı dobˇe a V´ykaz pracovn´ı doby.

Dohodu o pracovn´ı dobˇe by mˇel vyplnit kaˇzdý uˇcitel na zaˇcátku kaˇzdého ˇskoln´ıho roku a pˇri kaˇzdé dlouhodobé zmˇenˇe. Zahrnuje pˇr´ımou i nepˇr´ımou pracovn´ı povinnost. Výkaz pracovn´ı doby vyplˇnuje uˇcitel na konci kaˇzdého mˇes´ıce skuteˇcnˇe odpracované

hodiny. Do tohoto dokumentu se prom´ıtnou zmˇeny oproti Dohodˇe o pracovn´ı dobˇe

jako napˇr´ıklad zmˇeny ve v´yuce, nemoci, dovolen´e a dalˇs´ı.

• Systém mus´ı být snadno pˇr´ıstupný nejen ze ˇskoln´ı s´ıtˇe, ale i z internetu, aby uˇcitelé mohli tuto agendu ˇreˇsit i z m´ıst, kde vykonávaj´ı nepˇr´ımou pracovn´ı povinnost, napˇr. doma.

• Bylo by vhodné nemuset instalovat do poˇc´ıtaˇce ˇzádnou klientskou aplikaci. Ideáln´ı je tenký klient – dnes vˇsudypˇr´ıtomný webový prohl´ıˇzeˇc.

• Systém mus´ı umoˇzˇnovat plánován´ı akc´ı, napˇr. koncert˚u nebo exkurz´ı, v ciz´ım mˇestˇe. Mˇel by umoˇzˇnovat uˇcitel˚um pos´ılat dokumenty k tˇemto akc´ım zákonným zástupc˚um

a jim umoˇznit potvrzovat tyto dokumenty.

• Syst´em by mˇel umoˇznit efektivn´ı komunikaci mezi ˇreditelem a uˇciteli, mezi uˇciteli a studenty.

(10)

Kapitola 3

N´

avrh syst´

emu

V této kapitole pop´ıˇsu návrh systému tak, aby splˇnoval poˇzadavky z kapitoly 2.2.

Pro rychlé pochopen´ı modelovaného systému zaˇcnu v kapitole3.1 diagramem pˇr´ıpad˚u uˇzit´ı (Use Case Diagram).

3.1 Diagram pˇ

r´ıpad˚

u uˇ

zit´ı

V poˇzadavc´ıch formulovaných v kapitole2.2m˚uˇzeme rozpoznat tˇri hlavn´ı skupiny uˇzivatel˚u: studenty, rodiˇce a uˇcitele. Posledn´ı jmenované m˚uˇzeme dále rozdˇelit na prosté zamˇestnance, uˇcitele, ˇreditele (v diagramu je pojmenován admin, protoˇze to bude uˇzivatel s nejvyˇsˇs´ımi právy z uˇzivatel˚u) a root s nejvyˇsˇs´ımi právy. Toto rozdˇelen´ı jsem modeloval jako dˇediˇcnost.

(11)

3.2 Entity Relationship Diagram

Entity Relationship Diagram ukazuje pˇredevˇs´ım vztahy mezi entitami. ER diagram

nalez-nete na obrázku3.2. Popis entit a jejich významných atribut˚u následuje.

Obr´azek 3.2: Entity relationship diagram.

Student

Student je reálný ˇzák, který bude navˇstˇevovat ˇskolu.

Skupina

Skupina je skupina ˇzák˚u. Na mnoha m´ıstech v systému je moˇzné pracovat bud’ s jedn´ım konkrétn´ım ˇzákem nebo celou skupinou takových ˇzák˚u. Kaˇzdý uˇcitel m˚uˇze má vlastn´ı

sku-piny. Skupina m´a platnost pouze v jednom ˇskoln´ım roce.

Rodiˇc

Rodiˇc je osoba rodiˇce ˇzáka. Skuteˇcnost, ˇze rodiˇc m˚uˇze m´ıt v systému v´ıce dˇet´ı, nebude implementována v rámci této iterace vývoje.

(12)

Uˇcitel

Uˇcitel je re´aln´a osoba uˇcitele.

Uˇcebna

Uˇcebna pˇredstavuje reálnou uˇcebnu vyskytuj´ıc´ı se v urˇcité budovˇe. Zmˇena uˇceben m˚uˇze být pomˇernˇe ˇcastá záleˇzitost, proto je vázána na ˇskoln´ı rok.

Budova

Budova pˇredstavuje poboˇcku ˇskoly. Je charakterizovaná svým názvem, který v sobˇe pravdˇepodobnˇe ponese svou adresu.

Pˇredmˇet

Pˇredmˇet pˇredstavuje vyuˇcovaný pˇredmˇet. Je charakterizován svým názvem, nicménˇe na vysvˇedˇcen´ı se pouˇz´ıvaj´ı oficiálnˇejˇs´ı názvy, proto je zde také oficiáln´ı název.

Rozvrh

Rozvrh hodin je kolekce hodin, která patˇr´ı jednomu uˇciteli. Speciáln´ım typem rozvrhu je Dohoda o pracovn´ı dobˇe. Dohoda o pracovn´ı dobˇe je zakládána jako bˇeˇzný rozvrh a poté m˚uˇze uˇcitel poˇzádat o ustaven´ı rozvrhu dohodou. Kaˇzdý uˇcitel m˚uˇze m´ıt libovolný poˇcet rozvrh˚u, ale pouze jeden jako aktivn´ı Dohodu. Také by mˇel m´ıt kaˇzdý mˇes´ıc nˇejakou do-hodu platnou, podle reálných zkuˇsenost´ı vˇsak k vyplˇnován´ı dohod docház´ı ˇcasto aˇz zpˇetnˇe (obzvláˇst’ na zaˇcátku ˇskoln´ıho roku z toho d˚uvodu, ˇze se jedná o individuáln´ı výuku a jej´ı domluva je také individuáln´ı).

Hodina

Hodina je kl´ıˇcovou entitou informaˇcn´ıho systému. Vztah mezi hodinou a rozvrhem nazýváme kompozice, která vyjadˇruje, ˇze hodina nemá smysl bez odpov´ıdaj´ıc´ıho rozvrhu. Hodina se odehrává v jedné uˇcebnˇe. Uˇc´ı j´ı právˇe jeden uˇcitel a jeden ˇzák nebo skupina ˇzák˚u.

ˇ Z´adost

ˇ

Zádost libovolného uˇzivatele k ˇrediteli. M˚uˇze m´ıt konkrétn´ı pˇredmˇet (napˇr´ıklad prohláˇsen´ı rozvrhu za Dohodu o pracovn´ı dobˇe) nebo nemus´ı. V pˇr´ıpadˇe, ˇze ˇzádost má konkrétn´ı pˇriˇrazený pˇredmˇet a akci, postará se systém o vykonán´ı této akce sám. Pokud ale nemá konkrétn´ı pˇredmˇet pˇriˇrazen, je d˚uleˇzitý text ˇzádosti, který ˇreditel mus´ı analyzovat a poˇzadovanou akci uˇcinit ruˇcnˇe.

ˇ

Zádost je proces, který je popsán pomoc´ı schématu nazývaného workflow. Toto workflow obsahuje tyto stavy: nová, podaná, poˇzadováno doplnˇen´ı,zam´ıtnutá a schválená. Vazby mezi tˇemito stavy jsou znázornˇeny v obrázku3.3.

Pˇresun

Pˇresun pˇredstavuje pˇresun, který patˇr´ı jedné konkrétn´ı hodinˇe. Pˇresun mus´ı být schvalován, proto je k nˇemu vˇzdy vytvoˇrena ˇzádost. Pˇresun se zobrazuje v rozvrz´ıch, ale pokud jiˇz je nˇejaká hodina pˇresunuta, nem˚uˇze být rozvrh prohláˇsen za Dohodu o pracovn´ı dobˇe.

(13)

Obrázek 3.3: Stavový diagram ˇzádosti – worflow.

Zpr´ava

Zpráva pˇredstavuje zprávu od jednoho uˇzivatele jinému. Pˇri urˇcitých situac´ıch v systému (napˇr´ıklad schválená ˇzádost) budou zas´ılány zprávy zúˇcastnˇeným uˇzivatel˚um. Zpráva by také do budoucna mˇela m´ıt svou prioritu a systém bude vysoce prioritn´ı zprávy pˇrepos´ılat na email a ty nejurgentnˇejˇs´ı jako SMS do mobiln´ıho telefonu. Ale toto rozˇs´ıˇren´ı pˇrepos´ılán´ı nebude implementováno v této iteraci vývoje systému.

(14)

Kapitola 4

Pl´

anov´

an´ı

Plánován´ı je proces stanoven´ı postup˚u pro ˇr´ızen´ı a kontrolu plánované ˇcinnosti. Plánovat lze napˇr´ıklad lidské zdroje, rizika, náklady nebo proces implementace.

Informaˇcn´ı systém tak, jak byl navrˇzen v kapitole3, lze podle doby trván´ı povaˇzovat za stˇrednˇedobý aˇz dlouhodobý projekt. Podle poˇctu ˇclovˇekodn´ı jej m˚uˇzeme zaˇradit mezi malé aˇz stˇrednˇe velké projekty.

V kapitole4.4 najdete anal´yzu rizik.

Kapitola 4.1.2pojedn´av´a o modelech ˇzivotn´ıho cyklu software.

4.1 Zivotn´ı cyklus software

ˇ

Model ˇzivotn´ıho cyklu definuje etapy vývoje softwaru a jejich ˇcasovou následnost, definuje nutné ˇcinnosti kaˇzdé etapy a pro kaˇzdou etapu definuje jej´ı vstupy a výstupy.

4.1.1 Etapy ˇzivotn´ıho cyklu software

• Analýza – poˇzadavky zákazn´ıka jsou analyzovány

• Návrh – na základˇe analyzovaných poˇzadavk˚u zákazn´ıka je navrˇzen systém

• Implementace – podle návrhu je systém implementován

• Testován´ı – testován´ı implementovaného software podle poˇzadavk˚u • Provoz a údrˇzba – nasazen´ı systému a jeho udrˇzován´ı

4.1.2 Modely ˇzivotn´ıho cyklu software

Vodop´adov´y

Tento model je typickým zástupcem lineárn´ıch (sekvenˇcn´ıch) model˚u. Následuj´ıc´ı etapa zaˇc´ıná aˇz po ukonˇcen´ı té pˇredcházej´ıc´ı. V tomto modelu existuje moˇznost návratu k pˇredcházej´ıc´ı etapˇe.

Jeho hlavn´ı výhodou je nejlepˇs´ı struktura výsledného systému (za pˇredpokladu nemˇenných poˇzadavk˚u). Nevýhody pˇrevaˇzuj´ı nad výhodami: zákazn´ık takˇrka nikdy nen´ı schopen urˇcit hned na poˇcátku vývoje vˇsechny poˇzadavky a spustitelnou verzi dostane aˇz v závˇereˇcných fáz´ıch projektu.

(15)

Spir´alov´y

Model spirálový ˇrad´ıme mezi iterativn´ı modely. Systém se vyv´ıj´ı v jednotlivých iterac´ıch, pˇriˇcemˇz výstupem kaˇzdé iterace je reálný výsledek. Takovéhoto vývoje se zákazn´ık aktivnˇe ´

uˇcastn´ı (pr˚ubˇeˇzné akceptaˇcn´ı testován´ı, zmˇeny specifikace). Inkrementáln´ı

Inkrementáln´ı model patˇr´ı do skupiny hybrid˚u mezi sekvenˇcn´ımi a iterativn´ımi modely. Na základˇe specifikace se stanov´ı ˇcásti systému a kaˇzdá z nich je jiˇz vyv´ıjena lineárn´ım pˇr´ıstupem. Samotný model nen´ı konkrétnˇe urˇcen, ale naopak má nˇekolik variant (napˇr´ıklad jako sekvence vodopád˚u nebo poˇcáteˇcn´ı fáze – analýza, návrh – jsou provedeny vodopádem a jednotlivé ˇcásti jsou implementovány vodopádem bez tˇechto etap).

Pouˇzit´y model

Ve své práci bylo naplánováno vyuˇzit´ı inkrementáln´ı model ˇzivotn´ıho cyklu software. Analýza poˇzadavk˚u a návrh systému bude proveden vodopádovým modelem. Systém je rozdˇelen na nˇekolik logicky souvisej´ıc´ıch oblast´ı a kaˇzdá z tˇechto oblast´ı byla zpracována samostatným vodopádem (zkráceným o analýzu, návrh a akceptaˇcn´ı testován´ı). Detailn´ı plán popisuji v kapitole4.2.

4.2 Pl´

an v´

yvoje

4.2.1 Definice rol´ı

Pavel Slabý bude m´ıt na starosti analýzu, návrh systému, komunikaci se zákazn´ıkem,

implementaci systému, testován´ı a údrˇzbu systému. V Ganttovˇe diagramu vystupuje pod zkratkou SL.

Mgr. Tomáˇs Zouhar vystupuje v roli zákazn´ıka – je zadavatelem. Je ˇreditelem Základn´ı umˇelecké ˇskoly Tiˇsnov. V diagramu vystupuje svými iniciály TZ.

Alena Svobodová, Dis. je jedn´ım z uˇcitel˚u brnˇenské Základn´ı umˇelecké ˇskoly Frantiˇska J´ılka. Nebude pˇr´ımým uˇzivatelem systému, ale pˇresto jej´ı pohled je v mnohém uˇziteˇcný. Pom˚uˇze obzvláˇst’ analýzu situace, která pˇri vysvˇetlován´ı jednou osobou je znaˇcnˇe zkreslena.

4.3 Gantt˚

uv diagram

Gantt˚uv diagram ukazuje ˇcasovou souslednost ˇcinnost´ı a jejich z´avislosti.

Na obrázku 4.1je zobrazen Gantt˚uv diagram zobrazuj´ıc´ı plán projektu. ˇCervenou bar-vou je zobrazena kritická cesta.

(16)

27 03 IX 2012 10 17 24 01 X 2012 08 15 22 29 05 XI 2012 12 19 26 03 XII 2012 10 17 24 31 07 I 2013 14 21 28 04 II 2013 11 18 25 04 III 2013 11 18 25 01 IV 2013 08 15 22 29 06 V 2013 13 SL;TZ;AS SL;TZ SL SL;TZ SL SL SL SL;TZ TZ SL SL SL;TZ TZ SL SL SL;TZ TZ SL SL;TZ SL;TZ SL SL;TZ TZ SL;TZ ZUŠ IS - stránka1 13

(17)

4.4 R´ızen´ı rizik

ˇ

4.4.1 Seznam rizik

Nejdˇr´ıve definuji uvádˇené vlastnosti rizik. Závaˇznost na stupnici 1 − 3 (3 je nejzávaˇznˇejˇs´ı) udává jak závaˇzný dopad by toto riziko mˇelo v pˇr´ıpadˇe projeven´ı. Pravdˇepodobnost´ı výskytu se snaˇz´ım urˇcit, jak moc pravdˇepodobné je, ˇze se toto riziko projev´ı. Popis rizika ukazuje moˇzný pr˚ubˇeh rizika, moˇzné dopady a d˚uvody, proˇc jej uvaˇzuji. Popis vypoˇrádán´ı ˇr´ıká, jak tomuto riziku pˇredcházet, a jakým zp˚usobem zm´ırnit jeho dopady.

Porucha poˇc´ıtaˇce

Z´avaˇznost: 1

Pravdˇepodobnost v´yskytu: 10 %

Popis rizika: M˚uˇze doj´ıt k poruˇse mého poˇc´ıtaˇce a t´ım ke ztrátˇe dat, znemoˇznˇen´ı práce. Popis vypoˇrádán´ı: V tomto pˇr´ıpadˇe je kl´ıˇcová prevence. Je d˚uleˇzité m´ıt data zálohována (k tomuto úˇcelu pouˇz´ıvám Dropbox ). Abych eliminoval dopad znemoˇznˇen´ı práce je vhodné m´ıt záloˇzn´ı poˇc´ıtaˇc, mohu také vyuˇz´ıt poˇc´ıtaˇce v CVT naˇs´ı fakulty.

Zastaven´ı spolupr´ace ze strany ˇreditele

Z´avaˇznost: 3

Popis rizika: M˚uˇze se stát, ˇze ˇreditel ZUˇS ztrat´ı zájem o dokonˇcen´ı, zájem o spolupráci. Závaˇznost záleˇz´ı pˇredevˇs´ım na tom, jak moc pˇrestane komunikovat. Pokud by úplnˇe ztratil zájem o dokonˇcen´ı projektu je to pro projekt velmi kritické. Pokud by ovˇsem nekomunikoval pouze krátkodobˇe, napˇr´ıklad z d˚uvodu vyt´ıˇzenosti, mohlo by to zp˚usobit zdrˇzen´ı konkrétn´ı etapy projektu. Protoˇze ale nˇekteré ˇcinnosti z jeho strany stoj´ı v kritické cestˇe, mohlo by se i stát, ˇze by se projekt mohl zadrhnout úplnˇe.

Popis vypoˇrádán´ı: V plánován´ı jsem se snaˇzil ˇrediteli plánovat ˇcinnosti tak, aby nestály vˇzdy v kritické cestˇe. Pokud by ovˇsem podobná situace nastala, nen´ı moˇznosti úniku. Nˇekteré jeho ˇcinnosti mohou zastat i jiné osoby z oboru, ale v nˇekterých je nezastupitelný.

Zmˇeny v poˇzadavc´ıch

Z´avaˇznost: 2

Popis rizika: Zadavatel m˚uˇze zjistit, ˇze vyv´ıjen´y syst´em nen´ı podle jeho pˇredstav, nebo ˇze chce nˇejakou funkˇcnost pˇridat.

Popis vypoˇrádán´ı: Prevenc´ı je peˇclivá analýza a zapojen´ı zadavatele do procesu vývoje. V pˇr´ıpadˇe výskytu takovéto zmˇeny m˚uˇze být potˇrebné posunout term´ın dokonˇcen´ı.

4.4.2 Skuteˇcnˇe projeven´e probl´emy

Doˇslo k výskytu rizika Zastaven´ı spolupráce ze strany ˇreditele. Jak bylo napsáno v popisu pr˚ubˇehu, m˚uˇze j´ıt o velmi závaˇzný aˇz kritický problém. ˇReditel mˇel za úkol uˇzivatelské testován´ı a pˇredevˇs´ım akceptaˇcn´ı testován´ı a byla plánovaná jeho úˇcast u nasazen´ı systému v ZUˇS Tiˇsnov. Z tohoto d˚uvodu byly tyto aktivity výraznˇe zpoˇzdˇeny a jejich vyhodnocen´ı nebylo dostupné v dobˇe psan´ı této zprávy.

(18)

1 Získávání informací 5 dní 3.9.12 8:00 7.9.12 17:00 SL;TZ;AS 2 Analýza požadavků 5 dní? 10.9.12 8:00 14.9.12 17:00 1 SL;TZ 3 Návrh systému (rámcový) 14 dní? 17.9.12 8:00 22.9.12 0:00 2 SL 4 Konzultace a upravování analýzy a návrhu 50 dní? 24.9.12 8:00 30.11.12 17:00 3 SL;TZ 5 Návrh systému (detailní) 265,12 dní? 24.9.12 8:00 21.12.12 17:00 3 SL 6 Implentace obecné funkčnosti 28 dní? 2.1.13 8:00 8.2.13 17:00 4;5

7 Progamování 112,12 dní? 2.1.13 8:00 8.2.13 17:00 4;5 SL

8 Implentace modulu Matrika 32 dní? 2.1.13 8:00 15.2.13 0:00 4;5

9 Progamování modulu 112,12 dní? 2.1.13 8:00 8.2.13 17:00 4;5 SL 10 Funkční testování 1 den? 11.2.13 8:00 11.2.13 17:00 9 SL;TZ 11 Uživatelské testování 1 den? 12.2.13 8:00 12.2.13 17:00 10 TZ 12 Úprava podle připomínek z testování 5 dní? 13.2.13 8:00 15.2.13 0:00 10;11 SL 13 Implementace modulu Rozvrhy 20 dní? 11.2.13 8:00 10.3.13 17:00 6

14 Progamování modulu 55,12 dní? 11.2.13 8:00 1.3.13 17:00 6 SL 15 Funkční testování 2 dní? 4.3.13 8:00 5.3.13 17:00 14 SL;TZ 16 Uživatelské testování 1 den? 6.3.13 8:00 6.3.13 17:00 15 TZ 17 Úprava podle připomínek z testování 10,12 dní? 7.3.13 8:00 10.3.13 17:00 15;16 SL 18 Implementace modulu Akce 15 dní? 11.2.13 8:00 1.3.13 17:00 6

19 Programování modulu 34,12 dní? 11.2.13 8:00 22.2.13 17:00 6 SL 20 Funkční testování 1 den? 25.2.13 8:00 25.2.13 17:00 19 SL;TZ 21 Uživatelské testování 1 den? 26.2.13 8:00 26.2.13 17:00 20 TZ 22 Úprava podle připomínek z testování 7,12 dní? 27.2.13 8:00 1.3.13 17:00 20;21 SL 23 Design 10 dní? 11.3.13 8:00 22.3.13 17:00 6;8;13;18 SL;TZ 24 Celková kontrola produktu 5 dní? 25.3.13 8:00 29.3.13 17:00 23 SL;TZ 25 Případné úpravy 13,12 dní? 1.4.13 8:00 5.4.13 17:00 24 SL 26 Nasazení systému v ZUŠ Tišnov 1 den? 1.4.13 8:00 1.4.13 17:00 24 SL;TZ 27 Testovací provoz 10 dní? 2.4.13 8:00 15.4.13 17:00 26 TZ 28 Vyhodnocení testovacího provozu 2 dní? 16.4.13 8:00 17.4.13 17:00 27 SL;TZ

Jméno Trvání Začátek Konec Předchůdci Iniciály zdroje

ZUŠ IS

(19)

Kapitola 5

Implementace

Rozhodl jsem se vytvoˇrit webový informaˇcn´ı systém. Dnes je nˇekolik bˇeˇznˇe pouˇz´ıvaných jazyk˚u pro vývoj webových stránek. Jedn´ım nejmodernˇejˇs´ıch je Ruby. Také je velmi sloˇzité napsat webové stránky ”z ˇcistého listu”, proto se dnes velmi ˇcasto pouˇz´ıvaj´ı frameworky, které za programátora obstarávaj´ı typické a ˇcasto opakované problémy. Bezesporu nej-pouˇz´ıvanˇejˇs´ım frameworkem v jazyce Ruby je Ruby on Rails (v´ıce v kapitole 5.4).

V´ysledek m˚uˇzete vidˇet na obr´azc´ıch 5.1a 5.2

5.1 Datov´

y model

Datový model odpov´ıdá Entity Relationship Diagramu (viz kapitola3.2) s nˇekolika drobnými odliˇsnostmi. Tyto odliˇsnosti prob´ırám na následuj´ıc´ıch ˇrádc´ıch.

Celkový pohled na datomvý model ukazuji v obrázku 5.3

Uˇzivatel´e

V Entity Relatioship Diagramu vystupuj´ı entity student, uˇcitel a rodiˇc. Tyto tˇri entity

bychom obvykle modelovali jako dˇediˇcnost (konkrétnˇe Multi-Table Inheritance), ale v mnou zvoleném frameworku tato moˇznost nen´ı. Jako moˇznou alternativu lze pouˇz´ıt polymorfickou vazbu. Princip polymorfické vazby vysvˇetluji v kapitole5.4.3.

Dalˇs´ı zmˇeny

Pˇridána tabulka imports, která obsahuje informace o tom, kdo a kdy provádˇel import, a zda byl úspˇeˇsný.

5.2 Importov´

an´ı

Podle poˇzadavk˚u je potˇreba implementovat vstup data nejen pˇr´ımo od uˇzivatele, ale také nepˇr´ımo pˇres jiˇz pouˇz´ıvaný systém (popsaný v kapitole 2.1.2). Tento systém nemá da-tabázovou strukturu kompatibiln´ı s mnou navrˇzenou, proto je nutné pouˇz´ıvat oddˇelené databáze. Klasifikace také neˇreˇs´ı nˇekteré moduly mnou vyv´ıjeného systému (plánován´ı akc´ı, pˇresuny výuky).

Kv˚uli moˇznému soubˇeˇznému pouˇz´ıván´ı obou systém˚u je potˇreba zavést zp˚usob, jak importovat nebo synchronizovat data.

(20)

Obr´azek 5.1: N´ahled pˇrehledu.

Pˇri importován´ı dat nastává nˇekolik problém˚u. Jedn´ım z nich je neexistence loginu a hesla. Login generuji z jména a pˇr´ıjmen´ı. Heslo si m˚uˇze uˇzivatel zvolit po prvn´ım pˇrihláˇsen´ı. ActiveRecord nen´ı na podobné operace pˇripraven, proto je potˇreba import provádˇet vykonáván´ım pˇr´ıkaz˚u v

”surov´em“ jazyce SQL.

5.3 Ruby

Jazyk Ruby ˇrad´ıme mezi interpretovan´e objektovˇe orientovan´e skriptovac´ı jazyky.

Imple-mentace tohoto jazyka byla naps´ana v jazyce C jedin´ym ˇclovˇekem Yukihiro Matsumoto

v komunitˇe vývojáˇr˚u známý sp´ıˇse jako Matz [4]. Jazyk Ruby je plnˇe objektovˇe orientovaný, coˇz znamená, ˇze vˇse je objekt.

Jazyk Ruby je velmi intuitivn´ı a ˇcitelný, svou syntax´ı se velmi podobá anglickému jazyku.

5.3.1 Duck Typing

Duck typing je princip uplatnˇen´y v jazyce Ruby. Jeho myˇslenka je ´udajnˇe odvozena od

v´yroku Jamese Whitcomba Rileyho:

”When I see a bird that walks like a duck and swims like a duck and quacks

like a duck, I call that bird a duck.“ [11]

Tato myˇslenka ˇr´ıká, ˇze jazyk nezkoumá, která rozhran´ı tˇr´ıda implementuje, ale jednoduˇse

mu zkus´ı zaslat zpr´avu. Tˇr´ıda, kter´a implementuje metodu, tedy nemus´ı implementovat

(21)

(22)

Tento jev zp˚usobuje rychlejˇs´ı psan´ı kódu. Má ale i své nevýhody. M˚uˇze se vyskytnout problém v pˇr´ıpadˇe, ˇze se v jednom prostˇred´ı vyskytuje napˇr´ıklad tˇr´ıda Hodiny s metodou natáhni a souˇcasnˇe napˇr´ıklad Facka. Takováto zámˇena by mohla m´ıt pro program fatáln´ı d˚usledky. Jako kaˇzdý programovac´ı prostˇredek je nutné být si vˇedom odpovˇednosti, která pˇri jeho poˇzit´ı pˇricház´ı.

5.4 Ruby on Rails

5.4.1 Model – View – Controller (MVC)

MVC je návrhový vzor, který oddˇeluje datovou vrstvu, ˇr´ıdic´ı vrstvu a vrstvu prezentaˇcn´ı. Jednotlivé ˇcásti popisuji v následuj´ıc´ıch odstavc´ıch.

Model Model je abstrakce objekt˚u z re´aln´eho svˇeta, obvykle jsou jeho data uloˇzeny

v jedné tabulce. Nejedná se ovˇsem pouze o data, ale také o bl´ızkou business logiku jako napˇr´ıklad validace vstup˚u.

View View, neboli pohled, zajiˇst’uje prezentaˇcn´ı vrstvu aplikace.

Controller Controller, ˇcesky ˇradiˇc, zajiˇst’uje ˇr´ızen´ı aplikace. Controller je meziˇclánkem mezi modelem a view. Jeho starost´ı je zobrazit správný pohled. Pˇri vyvolán´ı akce ve view se ˇr´ızen´ı opˇet pˇredá ˇradiˇci, aby zareagoval a vykreslil správné view pˇr´ıpadnˇe aktualizoval model.

5.4.2 ActiveRecord

Vˇetˇsina modern´ıch framework˚u poskytuje nˇejakou formu ORM (Object – Relational

Map-ping). ORM je automatický zp˚usob, jak v relaˇcn´ı databázi uloˇzit stav objektu z objektovˇe orientovaného jazyka [5].

Ve frameworku Ruby on Rails je persistence dat zajiˇstˇena pomoc´ı ActiveRecord.

5.4.3 Polymorfick´a vazba

Polymorfická vazba je specialitou frameworku Ruby on Rails. Pˇri bˇeˇzné asociaci vytvoˇr´ıme jeden sloupec v tabulce, který udává odkaz na hodnotu v jiné tabulky. Obvykle za úˇcelem udrˇzen´ı referenˇcn´ı integrity systému definujeme také ciz´ı kl´ıˇce. Polymorfická vazba nevytvoˇr´ı pouze jeden sloupec, ale sloupce dva. Prvn´ı sloupce typu integer, udává id (primárn´ı kl´ıˇc) v jiné tabulce, a sloupce typu varchar, který udává, ve které tabulce se id má hledat.

Za úˇcelem zrychlen´ı vyhledáván´ı jsem definoval sloˇzený index na sloupce pod´ılej´ıc´ı se na polymorfické vazbˇe.

5.4.4 Convention over Configuration

Convention over Configuration je n´azev principu hojnˇe vyuˇz´ıvan´eho v Ruby on Rails.

Spoˇc´ıvá v tom, ˇze m´ısto sloˇzité konfigurace kaˇzdé drobnosti v konfiguraˇcn´ıch souborech se pouze vydaj´ı nejlepˇs´ı osvˇedˇcené postupy, kterých by se vývojáˇri mˇeli drˇzet. Tento prin-cip by mˇel umoˇznit rychlejˇs´ı vývoj a udrˇzovatelnˇejˇs´ı kód.

Tento princip je vyuˇzit napˇr´ıklad v názvových konvenc´ıch, konvenc´ıch pojmenován´ı soubor˚u, názv˚u sloupc˚u v databázi apod.

(23)

5.4.5 DRY

DRY znamen´a Don’t repeat yourself (Neopakuj se). Jedn´a se o princip, kdy by se

pro-gramátor mˇel snaˇzit nepsat stejný kód v´ıcekrát, ale pouze nastat poprvé a pak jen volat. Tento princip nut´ı programátora psát pˇrehlednˇejˇs´ı, ˇcistˇs´ı a t´ım také udˇzovatelnˇejˇs´ı kód.

5.5 RubyGems

RubyGems je bal´ıˇckovac´ı systém pro programy, resp. knihovny v jazyce Ruby [6]. Podobá se bal´ıˇckovac´ım systém˚um yum nebo apt-get z prostˇred´ı Linuxu.

RubyGems nepouˇz´ıvá podepisován´ı zdrojových kód˚u certifikáty [7], proto se ˇcasto stává terˇcem útok˚u [8].

5.5.1 Pouˇzit´e gemy

”Gem je zabalená aplikace nebo knihovna v jazyce Ruby. Je definována svým jménem a verz´ı.“ [6]

Protoˇze komunita vývojáˇr˚u v Ruby je pomˇernˇe poˇcetná, existuje jiˇz velké mnoˇzstv´ı gem˚u, které usnadˇnuj´ı práci. Také já jsem v této práci nˇejaké vyuˇzil a v této kapitole popisuji jejich úˇcel.

CanCan

CanCan [9] je knihovna, která umoˇzˇnuje na jednom m´ıstˇe zapsat ACL (Access Control List) – seznam oprávnˇen´ı pro ˇr´ızen´ı pˇr´ıstupu. Jej´ı hlavn´ı výhodou je, ˇze kód je lokalizován do jediného souboru app/models/ability.rb a celý kód je psát deklarativnˇe.

Workflow

Knihovna workflow [10] umoˇzˇnuje, jak název napov´ıdá, jednoduˇse deklarovat workflow pro model. Workflow m˚uˇzeme definovat jako schéma ˇcinnosti procesu. ˇCasto je implementován jako koneˇcný automat, pˇr´ıpadnˇe Petriho s´ıt’. D´ıky pouˇzit´ı gemu Workflow se tˇemito imple-mentaˇcn´ımi detaily nemus´ım zabývat.

Workflow se skládá ze stav˚u, pˇrechod˚u mezi nimi. Pˇrechody mohou být opatˇreny stráˇz´ı a pˇred, resp. po vykonán´ı pˇrechodu mohou vykonávat nˇejakou funkci.

Sorted a will paginate

Pro bˇeˇzné pouˇz´ıván´ı je velmi potˇrebné ˇrazen´ı, stránkován´ı a filtrován´ı seznam˚u. Pomáhá to nejen v tom, aby uˇzivatel nebyl zahlcen data, ale také umoˇzˇnuje urychlit zpracován´ı stránky.

ˇ

Razen´ı a stránkován´ı jsem pˇrenechal tˇemto gem˚um, ale filtrován´ı jsem naprogramoval sám, protoˇze jsem nenaˇsel jiˇz implementovaný filtrovac´ı mechanismus tak jednoduchý, tak rychlý a zároveˇn tak uˇzivatelsky efektivn´ı.

Validates Timeliness

(24)

(25)

Kapitola 6

Testov´

an´ı a moˇ

znosti rozˇ

s´ıˇ

ren´ı

Testován´ı je jedna z metod zajiˇst’ován´ı kvality software. Jeho c´ılem je odhalit chyby vývoje a prokázat poˇzadované vlastnosti. Existuje nˇekolik typ˚u rozdˇelen´ı testován´ı, napˇr´ıklad sta-tické a dynamické, ˇcerná skˇr´ıˇnka a b´ılá skˇr´ıˇnka nebo automatické a amanuáln´ı.

Problém testován´ı se m˚uˇze vyskytnout v pˇr´ıpadˇe, ˇze tester hledá chybu a ona neexistuje. Tato situace se dá vyˇreˇsit vyhrazen´ım ˇcasu pro tento proces.

Dalˇs´ım problémem je situace, kdy testován´ı je úspˇeˇsné (nenalezlo chybu). Tento výsledek ale nevypov´ıdá o bezchybnosti software.

6.1 Testov´

an´ı

Funkcion´aln´ı testov´an´ı

Jeden ze zp˚usob˚u testován´ı ˇcerné skˇr´ıˇnky. Tester porovnává pouze vstupy a výstupy.

Testoval jsem pomoc´ı tzv. náhodných procházek. Ty pomohou urˇcit, zda v programu

nejsou z´asadn´ı chyby.

Testován´ı ukázalo, ˇze souˇcasná kontrola chyb je nedostateˇcná. Kontrola je takto m´ırná proto, ˇze importován´ım z databáze souˇcasného systému dostáváme pomˇernˇe ˇcasto nevalidn´ı data a ztˇeˇzovalo by to pouˇz´ıván´ı systému. Toto oˇsetˇrován´ı povaˇzuji za smˇer dalˇs´ıho vývoje (viz6.2).

Akceptaˇcn´ı testov´an´ı

Akceptaˇcn´ı testován´ı provád´ı zadavatel. Na základˇe jeho výsledku se rozhoduje, zda smlouva o vývoji software byla ˇrádnˇe splnˇena ˇci nikoliv.

V m´em pˇr´ıpadˇe ovˇsem doˇslo k propuknut´ı probl´emu, kdy si zadavatel neudˇelal dostatek ˇ

casu na vˇcasné testován´ı a výsledky akceptaˇcn´ıch test˚u v dobˇe odevzdán´ı této práce nejsou k dispozici (v´ıce informac´ı o tomto problému naleznete v kapitole4.4.2).

Pilotn´ı testov´an´ı

Jedná v podstatˇe o testovac´ı nasazen´ı systému. Testuj´ı ho jiˇz skuteˇcn´ı budouc´ı uˇzivatelé. V mém pˇr´ıpadˇe byl systém spuˇstˇen na testovac´ı doménˇe. V dobˇe odevzdán´ı této práce ale jeˇstˇe nebyly k dispozici zanalyzované výsledky (v´ıce informac´ı o tomto problému naleznete v kapitole4.4.2).

(26)

Automatick´e testov´an´ı

Automatické testy jsou provádˇeny na základˇe pˇresnˇe daného postupu automaticky – bez pozornosti uˇzivatele. Jeho hlavn´ı výhodou je rychlost. Jedná se o nezbytnost v pˇr´ıpadˇe Test-Driven Development (testy ˇr´ızený vývoj). Automatické testy také velmi usnadˇnuj´ı refactoring (refaktorizaci). Refaktorizace je proces zmˇeny kódu tak, aby byl ˇcitelnˇejˇs´ı, udrˇzovatelnˇejˇs´ı, rychlejˇs´ı, optimalizovanˇejˇs´ı apod. bez zmˇeny vstup-výstupn´ıch dat.

Framework Ruby on Rails poskytuje prostˇredky pro automatick´e testov´an´ı, bohuˇzel

jsem jich nevyuˇzil dostateˇcnˇe, proto se velmi zkomplikovalo fin´aln´ı refaktorov´an´ı.

6.2 Moˇ

zn´

a rozˇ

s´ıˇ

ren´ı

D´ıky evidenci pracovn´ıch nepˇr´ıtomnost´ı (dovolená, nemocenská, apod.) by systém mohl být schopen Výkaz pracovn´ı doby generovat úplnˇe bez zásahu ˇclovˇeka. O uˇziteˇcnosti této moˇznosti bude nutné nejdˇr´ıve pˇresvˇedˇcit uˇzivatele systému z ˇrad uˇcitel˚u.

Dalˇs´ı funkc´ı, která by mohla být zváˇzena pro budouc´ı implementaci je oboustranná syn-chronizace do databáze p˚uvodn´ıho systému.

Pro lepˇs´ı kontroly zadaných údaj˚u je potˇreba pˇridat mnoˇzstv´ı evidovaných údaj˚u. Napˇr´ıklad abych mohl kontrolovat, zda má uˇcitel pˇriˇrazen správný poˇcet ˇzák˚u, zda má správný poˇcet vyuˇcovac´ıch hodin nebo zda má správný poˇcet hodin nepˇr´ımé pracovn´ı povinnosti, bych mu-sel do systému zanést informaci o velikosti úvazku a poˇcet hodin týdnˇe, které má daný ˇzák zaplacený. Zadáván´ı tˇechto údaj˚u je potˇreba natolik zautomatizovat, aby se uˇcitel, resp. ˇreditel, mohl vˇenovat jiné ˇcinnosti, která je obzvláˇstˇe na zaˇcátku ˇskoln´ıho roku potˇreba v jiných oblastech.

Tento syst´em jsem implementoval tak, by bylo snadn´e pˇridat evidenci vˇsech zamˇestnanc˚u a evidovat jejich pracovn´ı dobu.

Z databáze p˚uvodn´ıho systému dostáváme nˇekdy nevhodná data. Napˇr´ıklad rodiˇc, který má na jedné ˇskole v´ıce ˇzák˚u, dostane pro kaˇzdé rodiˇcovstv´ı vlastn´ı pˇrihlaˇsovac´ı a heslo. Tyto duplicity je moˇzné odstranit napˇr´ıklad t´ım, ˇze vazba mezi rodiˇcem a ˇzákem vznikne v systému aˇz pozdˇeji neˇz importem, napˇr´ıklad t´ım, ˇze rodiˇc zadá údaje ˇzáka, které ho v systému identifikuj´ı.

Kv˚uli této skuteˇcnosti jsou po celém systému pouze minimáln´ı kontroly zadaných dat (nejtristnˇejˇs´ı dopad je asi u validac´ı koliz´ı v rozvrhu). To je potˇreba pro plné pouˇz´ıván´ı také zmˇenit.

Pˇrepos´ılán´ı doˇslých zpráv na email nebo SMS podle priority, bude také implementováno pozdˇeji.

Pro bˇeˇzné pouˇz´ıván´ı budou také nutné tiskové sestavy jejichˇz podobu jsem nestihl

(27)

Kapitola 7

Z´

avˇ

er

C´ılem tohoto textu bylo popsat proces v´yvoje informaˇcn´ıho syst´emu. Tento proces byl

popsán od analýzy poˇzadavk˚u zákazn´ıka, pˇres návrh systému podle poˇzadavk˚u, pˇres plánován´ı celého procesu vývoje a ˇr´ızen´ı rizik, aˇz po popis samotné aplikace a jej´ıho testován´ı.

Poˇzadavky zákazn´ıka jsem ˇcerpal z nˇekolika zdroj˚u. Prvn´ım byl Mgr. Tomáˇs Zouhar, ˇreditel Základn´ı umˇelecké ˇskoly Tiˇsnov. Druhý zdrojem byla uˇcitelka Alena Svobodová, Dis., uˇcitelka klav´ıru brnˇenské Základn´ı umˇelecké ˇskoly Frantiˇska J´ılka. Této problematice se vˇenuje kapitola2.

Kapitolu 3jsem vˇenoval návrhu informaˇcn´ıho sytému. Podle tohoto návrhu jsem v ka-pitole5 ukázal detaily implementace tohoto systému.

Hlavn´ı c´ıle tohoto projektu (vytvoˇrit systém podle poˇzadavk˚u) se podaˇrilo splnit. Pro-jekt jsem peˇclivˇe naplánoval, analyzoval rizika projektu, jak popisuji v kapitole4.2. Bˇehem vývoje se vyskytly problémy, jejichˇz dopad jsem se snaˇzil minimalizovat. Hlavn´ım problémem byl úpadek zájmu zadavatele systému, který popisuji v kapitole 4.4.2.

Snaˇzil jsem se informace od nˇeho nahradit informacemi z jiných zdroj˚u, nˇekteré vˇsak (napˇr´ıklad pilotn´ı testován´ı) bez zadavatele uskuteˇcnit nelze. Informaˇcn´ı systém byl tedy

implementov´an, ale pilotn´ı nasazen´ı a jeho vyhodnocen´ı nestihlo probˇehnout do doby

ode-vzdán´ı této práce.

V rámci ˇreˇsen´ı tohoto projektu jsem se zdokonalil v jazyce Ruby a detailnˇeji si osvojil práci s MVC frameworkem Ruby on Rails. Vyzkouˇsel jsem nˇekteré z mnoha pˇredpˇripravených knihoven (gem˚u), které jsem volnˇe k dispozici a které velmi usnadˇnuj´ı a urychluj´ı vývoj. Také jsem si prakticky ovˇeˇril, jak d˚uleˇzité jsou d˚ukladná analýza a plánován´ı vývoje.

Tento informaˇcn´ı systém je moˇzné dále vylepˇsovat v nˇekolika smˇerech. Namátkou vyberu z kapitoly6.2zas´ılán´ı zpráv do emailu nebo do mobiln´ıho telefonu jako SMS, synchronizace s databáz´ı p˚uvodn´ıho systému, reset hesla nebo rozˇs´ıˇren´ı evidovaných dat tak, aby bylo moˇzno nˇekteré operace automatizovat (napˇr´ıklad generován´ı výkaz˚u pracovn´ı doby zcela automaticky).

Tento systém se budu snaˇzit dále rozv´ıjet a dotáhnout k úspˇeˇsnému nasazen´ı v Základn´ı umˇelecké ˇskole Tiˇsnov.

(28)

Literatura

[1] HOLZNER, S. Zaˇc´ın´ame programovat v Ruby on Rails. Vyd. 1. Pˇreklad Karel

Vor´aˇcek. Brno: Computer Press, 2007, 384 s. ISBN 978-80-251-1630-2.

[2] KR ´AL, J. Informaˇcn´ı syst´emy. 1. vyd. Brno: Science, 1998, 357 s. ISBN 80-86083-00-4.

[3] HARTL, M. Ruby on Rails Tutorial. 2012. 2. Dostupn´e z:

http://ruby.railstutorial.org/ruby-on-rails-tutorial-book

[4] About Ruby [online]. [cit. 2013-04-30]. Dostupn´e z:http://www.ruby-lang.org/en/

[5] Active Record Basics [online]. [cit. 2013-04-29]. Dostupn´e z:

http://guides.rubyonrails.org/active_record_basics.html

[6] RubyGems User Guide — RubyGems Manuals [online]. [cit. 2013-04-29]. Dostupn´e z:

http://docs.rubygems.org/read/chapter/1%20Introducing%20RubyGems

[7] BOßLET, M. We Need to Sign Ruby Gems! But How? [online]. [cit. 2013-05-14].

Dostupn´e z:http:

//emboss.github.io/blog/2013/02/15/we-need-to-sign-ruby-gems-but-how/

[8] KOETSIER, J. RubyGems.org hacked, interrupting Heroku services and putting sites using Rails at risk [online]. [cit. 2013-04-30]. Dostupn´e z:

http://venturebeat.com/2013/01/30/rubygems-org-hacked-interrupting-heroku-services-and-putting-millions-of-sites-using-rails-at-risk/

[9] DOBRIAKOV, V. CanCan Home [online]. [cit. 2013-04-29]. Dostupn´e z:

https://github.com/ryanb/cancan/wiki

[10] DOBRIAKOV, V. What is workflow? [online]. [cit. 2013-04-30]. Dostupn´e z:

http://www.geekq.net/workflow/

[11] HEIM, M. Exploring Indiana highways: trip trivia. Wabasha, Minn: T.O.N.E. Pub, 2007. ISBN 978-097-4435-831.

(29)

Pˇ

r´ıloha A

Obsah CD

A.1 Adres´

aˇ

rov´

a struktura na CD

Na CD naleznete tyto sloˇzky:

Navod k instalaci a spusteni obsahuje PDF soubor s n´avodem k instalaci, konfiguraci

a spuˇstˇen´ı.

Technicka zprava pdf obsahuje PDF soubor s s touto technickou zpr´avou.

Technicka zprava zdroj obsahuje soubory, které jsou potˇreba pro vysázen´ı technické

zpr´avy pomoc´ı programu LA_TEX.

Navod k instalaci a spusteni obsahuje PDF soubor s n´avodem k instalaci, konfiguraci

(30)

Pˇ

r´ıloha B

Instalace a spuˇ

stˇ

en´ı

B.1 Instalace

B.1.1 Prerekvizity

Pˇred samotnou instalac´ı systému je potˇreba m´ıt nainstalované (konkrétn´ı verze jsou do-poruˇcené, je moˇzné ˇze systém bude fungovat i pˇri jiné konfiguraci):

• Ruby 1.9.3 • RubyGems 1.8 • Bundler

• Ruby on Rails 3

• JSRuntime kompatibiln´ı s ExecJS podle https://github.com/sstephenson/execjs

• Datab´azov´y server.

B.1.2 Instalace

Nakop´ırujte vˇsechny soubory do sloˇzky na disku. Vstupte do t´eto sloˇzky.

Zadán´ım následuj´ıc´ıho pˇr´ıkazu do terminálu nainstalujete vˇsechny potˇrebné gemy: > bundle install

B.1.3 Konfigurace

Je potˇreba nastavit pˇrihlaˇsovac´ı údaje k databázi v config/database.yml. Potém je potˇreba spustit vytvoˇren´ı databáze, a naplnˇen´ı daty pomoc´ı: > rake db:setup

B.1.4 Spuˇstˇen´ı

Pomoc´ı n´asleduj´ıc´ıho pˇr´ıkazu spust´ıte serverovou aplikaci: > rails s