Kolejní administrativa UIS

Mendelova zemědělská a lesnická univerzita v Brně Provozně ekonomická fakulta

Kolejní administrativa UIS Bakalářská práce

Vedoucí práce: RNDr. Ing. Milan Šorm

Jan Omasta

Brno 2004

Rád bych poděkoval vedoucímu mé práce RNDr. Ing. Milanu Šormovi za rady a připomínky k vypracování. Dále děkuji kolegům z vývojového týmu UIS, zejména Ing. Tomáši Majerovi, za jejich cenné rady a pomoc při samotné implementaci. Můj dík patří také Ing. Ladislavu Viktorinovi ze Správy kolejí a menz Masarykovy univerzity v Brně a Ing. Radomíru Kurečkovi z brněnské firmy ApS, s. r. o., za konzultace v oblasti ubytovacích systému vysokoškolských kolejí.

Prohlašuji, že jsem tuto práci vytvořil sám, s použitím zdrojů uvedených v seznamu literatury. K jejímu vytvoření mi napomohli rovněž kolegové z Vývojového týmu UIS, bez jejichž znalostí a rad by nebylo možné Kolejní administrativu začlenit mezi agendy UIS.

V Brně dne 31. května 2004

....................................................

4

Abstract Omasta, J. College Administration of UIS. Bachelor thesis. Brno, 2004. This thesis is oriented to the analysis, design and implementation of the College Administration of the University Information System of Mendel University at Agriculture and Forestry in Brno. The analysis describe current state of student accomodation at colleges from point of view on integration of information system. Implementated aplications serve to distribution of accomodation capacity at colleges.

Abstrakt Omasta, J. Kolejní administrativa UIS. Bakalářská práce. Brno, 2004. Práce se zabývá analýzou, návrhem a implementací Kolejní administrativy Univerzitního informačního systému Mendelovy zemědělské a lesnické univerzity v Brně. Analýza popisuje současný stav ubytování na vysokoškolských kolejích z pohledu integrace informačního systému. Implementované aplikace slouží zejména k rozdělování ubytovacích kapacit na kolejích.

5

OBSAH

Obsah 1 Úvod a cíl práce 1.1 Úvod do problematiky . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Cíl práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7 7 8

2 IS/ICT v oblasti ubytovacích systémů 9 2.1 Hotelové ubytovací systémy . . . . . . . . . . . . . . . . . . . . . . . 9 2.2 Ubytovací systémy pro vysokoškolské koleje . . . . . . . . . . . . . . 11 2.3 Studentské ubytovací agendy . . . . . . . . . . . . . . . . . . . . . . . 13 3 Dosavadní rozdělování kolejí na MZLU 3.1 Papírové rozdělování kolejí . . . . . . . 3.2 Využití systému STUDENT . . . . . . 3.3 Koleje v rámci FIS . . . . . . . . . . . 4 Použité technologie 4.1 Univerzitní informační systém . . . . 4.2 Výklad základních pojmů . . . . . . 4.3 Implementační prostředí UIS . . . . . 4.4 Typografický systém TEX . . . . . . 4.5 LWP – The World-Wide Web Library

v Brně . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . for

. . . . . . . . . . . . Perl

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

16 16 19 19 20 20 21 22 25 26

5 Předimplementační studie Kolejní administrativy 28 5.1 Požadavky na Kolejní administrativu . . . . . . . . . . . . . . . . . . 28 5.2 Prototypování aplikací . . . . . . . . . . . . . . . . . . . . . . . . . . 29 6 Implementace Kolejní administrativy UIS 6.1 Aplikace Kolejní administrativy . . . . . . . . . . 6.2 Žádosti o koleje studentů nastupujících do studia 6.3 Zjišťování dojezdové vzdálenosti . . . . . . . . . . 6.4 Předávání dat s ubytovacím systémem SKM . . . 6.5 Datové schéma . . . . . . . . . . . . . . . . . . . 7 Zhodnocení práce 7.1 Změny oproti předimplementační studii 7.2 Administrativní přínos práce . . . . . . 7.3 Ekonomický přínos práce . . . . . . . . 7.4 Výhledy do budoucna . . . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

31 31 37 37 41 42

. . . .

43 43 43 44 44

8 Závěr

47

9 Literatura

48

Přílohy

50

OBSAH

A Entitně-relační diagram

6 51

1

ÚVOD A CÍL PRÁCE

1 1.1

7

Úvod a cíl práce Úvod do problematiky

Ubytování na vysokoškolských kolejích je jednou ze součástí studentského života. Nárůst počtu studentů vysokých škol, zejména v posledním desetiletí, a téměř nulový nárůst ubytovacích kapacit vysokoškolských kolejí způsobil vysoký počet žadatelů na jedno lůžko. V současné době se koleje vůči svému zákazníkovi – studentovi – nechovají tržně. Jsou součástí univerzity a jako takové dostávají od jednotlivých fakult rozhodnutí, které studenty ubytovat. Tento rozhodovací mechanismus se děje prostřednictvím rozdělování ubytovacích dekretů. Udělení dekretu studenta opravňuje k ubytování na koleji. Samotné rozhodování, komu koleje udělit a komu ne, řídí kritéria vycházející ze vzdálenosti místa trvalého bydliště studenta, případně jeho studijního prospěchu s přihlédnutím ke zvláštním sociálním či zdravotním důvodům. Možnost bydlet na koleji je pro studenty lákavá jednak z důvodu společného bydlení s kolegy a jednak z ekonomického hlediska. Lůžko na koleji je dotováno ze státního příspěvku, díky kterému je nájemné nižší, než například při ubytování v podnájmu. Problematika je citlivá a je proto nutné při udělování dekretů postupovat s velkou dávkou obezřetnosti. Koleje se udělují na celý akademický rok, ikdyž student studuje v současné době po semestrech. V jeho rámci je studentovi možné udělit koleje na základě podané žádosti o koleje a to maximálně jednou pro všechna jeho studia na univerzitě. Žádost tedy podává student ne na své studium, ale na svou osobu. Zde je nutná součinnost jednotlivých fakult, na kterých student studuje. Na MZLU v Brně udělují koleje děkani jednotlivých fakult, kteří tak činí na základě doporučení kolejní rady. Kolejní radu definuje (Kolejní řád, 1997) jako orgán studentské samosprávy zastupující zájmy ubytovaných studentů ve vztahu ke Správě kolejí a menz a jiným subjektům zainteresovaným na řízení kolejí. K této činnosti kolejní rady přibívá ještě asistence při rozdělováním kolejí. V praxi probíhá udělování tak, že děkan vydá více či méně formální požadavky na udělování kolejí, podle kterých kolejní rada rozhodne, zda studentovi koleje udělí či nikoliv. Děkan do rozhodování může zasáhnout. Celé rozhodnutí nakonec potvrdí svým podpisem. Práci kolejní rady, která je složena ze studentů fakulty koordinuje k tomu děkanem určený zaměstnanec. Zpravidla to bývá někdo z pedagogů nebo studijní referentka. Spolupráce se studijním oddělením fakulty je také nutná při administrativních činnostech, zejména tisku dopisů a seznamů. Poznatky z každodenní činnosti předsedy studentské části kolejní rady a absence prostředků pro usnadnění rozdělování kolejí vedly autora této práce k její realizaci. Zkušenosti a znalosti, které ve své funkci získal, jsou zúročeny ve všech částech této práce.

1.2

1.2

Cíl práce

8

Cíl práce

Hlavním cílem této práce je návrh, implementace a uvedení do provozu Kolejní administrativy, subsystému Univerzitního informačního systému, řešící otázku přidělování kolejí. Prvním postupným krokem je tedy analýza současného systému udělování vysokoškolských kolejí jak v prostředí Mendelovy zemědělské a lesnické univerzity v Brně (dále jen MZLU v Brně), tak na ostatních univerzitách. Na analýzu musí navázat rozbor možné implementace systému do Univerzitního informačního systému MZLU v Brně (dále jen UIS). Samotná implementace, zkušenosti a přínosy z používání a výhledy do budoucna budou shrnuty ve druhé částí práce. Kolejní administrativa UIS má za cíl stát se plnohodnotným pomocníkem členů kolejních rad a studijních referentek při udělování kolejí. Její význam je v poloautomatizaci podávání žádostí o koleje a udělování kolejí včetně tisku ubytovacích dekretů. Důležitou vlastností je napojení na ostatní agendy UIS, zejména studijní evidenci. Úplnou integrací do UIS má být zajištěno přebírání důležitých dat o studentech a jejich studiích a také možnost tato data poskytnout dalším agendám. K poloautomatizaci udělování kolejí patří vedle tisku dokumentů Kolejní administrativy výpočet dojezdové vzdálenosti. Synchronizace dat s ubytovacím systémem Správy kolejí a menz MZLU v Brně má urychlit a zjednodušit ubytováváni studentů na jedné straně a zajistit zpětnou vazbu školy na údaje o ubytování již ubytovaných studentů. Tato práce také může částečně posloužit uživatelům Kolejní administrativy, systémovým integrátorům jednotlivých fakult a vývojářům UIS jako programová dokumentace. Analýzou současného stavu, stavu v minulosti a výhledů do budoucnosti udělování kolejí by se práce měla stát uceleným dokumentem o udělování vysokoškolských kolejích. Může být tedy využita jako zdroj analýzy při tvorbě daleko rozsáhlejšího systému tohoto typu.

2

IS/ICT V OBLASTI UBYTOVACÍCH SYSTÉMŮ

2

9

IS/ICT v oblasti ubytovacích systémů

Informační systémy a informační technologie pronikají v současné době do všech oblastí lidské činnosti. Tento trend, umocněný masovým využitím Internetu, nezadržitelně roste. Oblast ubytování, ať už klasického hotelového typu nebo ubytování na vysokoškolských kolejích, není výjimkou. Využití těchto prostředků zjednodušuje a zefektivňuje práci všech zainteresovaných osob, zpříjemňuje přístup zákazníkům a přináší přes své nesporné zaváděcí náklady spoustu ekonomických úspor.

2.1

Hotelové ubytovací systémy

Široká nabídka komerčních ubytovacích služeb všech kategorií se v naší republice za posledních patnáct let rozšířila nebývalou měrou. Drtivá většina bývalých ubytovacích zařízení přešla do soukromého vlastnictví a velké podniky byly doplněny spoustou drobných ubytoven, hotýlků a penzionů. V tak velké konkurenci je nutné přiblížit se zákazníkovi. Dnes, kdy je nabídka zařízení na téměř shodné vysoké úrovni, se boj o zákazníka přesouvá do jiných rovin. Jsou jimi zejména propagace a přímá nabídka s možností on-line rezervací a objednávek. Informační systémy, které umožňují nabídnout zákazníkovi prostřednictvím Internetu ubytovací služby a jejich on-line rezervaci lze rozdělit na dvě základní skupiny: • informační systémy ubytovacích zařízení, • informační systémy informačních center a ubytovacích agentur. Informační systémy ubytovacích zařízení Tyto systémy jsou převážně nakupovány od externích dodavatelů. Ubytovací zařízení nejsou natolik velká, aby zvládla vývoj systému vlastními prostředky. Současný trh s tímto druhem informačních systémů nabízí převážně výhodné modulární systémy, které není problém upravit na specifické potřeby uživatele. Systémy je nutné dodávat s uživatelskou podporu. Zástupci těchto IS se vyznačují následujícími vlastnostmi: • modularita – podle potřeb hotelu jsou nasazovány pouze určité části, které je možné dále rozšiřovat, • SQL databáze – v současnosti nejbezpečnější a nejlépe implementovatelná datová základna, snadné exporty do okolí informačního systému, • jednoduché a intuitivní ovládání, • vysoká automatizace procesů – např. vyúčtování stiskem jednoho tlačítka, automatické načítání nájmu a služeb, on-line přehled o kapacitách . . . , • personalizace – individuální přístup ke tvorbě vzhledu webového rozhraní a nabídky zákazníkovi.

2.1

Hotelové ubytovací systémy

10

Informační systémy informačních center a ubytovacích agentur V tomto případě se nejedná přímo o systémy, které by v ubytovacím zařízení řídily ubytování a rezervace. Jedná se pouze o prostředek komunikace mezi zákazníkem, co by uživatelem Internetových vyhledávačů a portálů, a ubytovacím zařízení. Nejběžnější je forma portálu soustřeďujícího nabídky zařízení z některé, zejména geografické, oblasti. Ze seznamu objektů si zákazník může udělat buď obrázek o službách, nebo přímo provést rezervaci a objednávku. Portál získává údaje o kapacitách a nabídkách z ubytovacích systémů jednotlivých hotelů a zpětně jim předává podklady o provedených rezervacích a objednávkách. Analýza hotelového informačního systému Detailní analýzu včetně popisu rolí hotelového informačního systému nám poskytuje (Jun a kol., 2004). Podle něj může ubytovací zařízení využít informační systém pro kompletní řízení svých agend týkajících se ubytovacích a doplňkových služeb a zpracovávat tak informace o provozu, objektech, zaměstnancích a hostech. Díky webovému rozhraní k němu mohou přistupovat i hosté či zájemci o ubytování. Data o finančních tocích jsou exportována do účetních a manažerských informačních systémů. Samotné implementační prostředí může být libovolné. Datová základna musí být ovšem schopná generovat datové výstupy pro účetní subsystém ve formě, kterou je tento schopen přijmout a zpracovat. Pro možnost přístupu uživatele k rezervacím a objednávkám je nutné webové rozhraní. To může být dalším externím systémem, se kterým jsou oboustranně vyměňovány údaje, nebo v lepším případě přímo součástí ubytovacího systému. Systém rovněž může vést agendu zaměstnanců, kterou spravuje personální oddělení, a doplňkových služeb, který si uživatel taktéž může rezervovat a objednat a jejich cena je účtována s nájemným (tenisové kurty, masáže, léčebné procedury v lázeňských domech . . . ). Návrh rolí v hotelovém informačním systému: • Recepční – má přístupné informace o ubytovacích kapacitách a hotelových hostech. Může zakládat účty hostů a pracovat s nimi. Tzn. založit a ukončit ubytování, zaevidovat a vyřídit platby. Dále má oprávnění zakládat rezervace a objednávky pokojů. • Personální pracovník – má k dispozici kompletní správu databáze zaměstnanců hotelu. • Ředitel hotelu – přistupuje k osobním a ubytovacím údajům hostů z důvodu stanovení slevy na ubytování konkrétním hostům. Dále stanovuje ceny za ubytování a termíny, kdy budou příslušné pokoje či celý hotel uzavřeny pro hosty. Systém mu na požádání vygeneruje statistiky a přehledové výroční zprávy. • Účetní – pracuje s účetním systémem, který z ubytovacího systému přejímá potřebné údaje (není jeho součástí). Informace tvoří finanční pohyby podporované IS.

2.2

Ubytovací systémy pro vysokoškolské koleje

11

• Host – prostřednictvím svého konta může vytvářet a rušit své rezervace. Prostřednictvím www stránek vidí svoji ubytovací historii a případnou slevu na ubytování. Při provádění rezervace je ihned vypočítána celková cena za ubytování včetně slevy. • WWW uživatel – jako jediný má neautorizovaný přístup do systému. Prostřednictvím Internetových stránek přistupuje k informacím o ubytovacích zařízení, službách, kapacitách a cenách za ubytování. Stejnou cestou si může založit nový účet hosta.

2.2


Oblast vysokého školství a ubytování na kolejích zvláště je značně specifická. Univerzit je relativně malý počet, ale jsou to značně rozsáhlé instituce a jejich požadavky na kolejní ubytovací systém navzájem velmi odlišné. Univerzita má zpravidla navíc obvykle oddělení zabývající se informačními technologiemi. To je schopné buď integrovat IS dodávaný externím dodavatelem, nebo vyvinout vlastní systém, který bude vytvořen přesně podle požadavků univerzity. Následující text představuje tři zástupce komerčně dodávaných systémů. Atlantis Jak uvádí (Klimek a kol., 2000), byl na Karlově univerzitě pro potřeby evidence ubytovaných studentů používán program Atlantis. Jeho výrobce ArtPhoto jej sestavil speciálně na zakázku. Jedná se o samostatný program, který je nainstalován na počítačích všech ubytovacích kanceláří. Ty si mezi sebou informace předávají. Systém pracuje na následujícím principu: • každý ubytovaný má evidenční kartu – údaje osobní, ubytovací a o stavu finací na účtu, • student může platit několika způsoby, – platby záloh na účet kolejí – banka předává informace o provedených platbách ubytovacím kancelářím, – platby složenkou – plátce je možné identifikovat pouze fyzickým porovnáním dokladu o zaplacení složenky, – platby v hotovosti u pokladny kolejí • jsou tvořeny měsíční uzávěrky – kontrola peněžních toků, • data je možné převést do tabulkového procesoru – tvorby statistik. Problémy v architektuře tohoto systému vidí (Klimek a kol., 2000) zejména v nízké úrovni komunikace se studijními odděleními jednotlivých fakult. Ty několikrát do roka předají informace o svých studentech ubytovacím kancelářím, které je převedou do svých databází. Další nedostatky nachází v algoritmu přidělovaní ubytovacích kapacit, který není příliš odolný proti podvodům.

2.2


12

Systémy ApS Brno Brněnská firma ApS, s. r. o. produkuje ubytovací systémy pro vysokoškolské koleje. Tyto systémy se zabývají problematikou ubytování na kolejích v následujících oblastech: • evidence údajů o studentech, jejich studiích, žádostech o koleje, kritériích pro udělení kolejí a ISIC kartách – tato data přebírá systém ze studijního systému univerizty na žádost správce ubytovacího systému, před uložením projdou data čištěním, • zjištění kritérií pro udělení kolejí – z údajů o studentových studijních úspěších, zvláštních důvodech pro udělení kolejí a dojezdnosti je pomocí vzorce sestaven koeficient pro udělení kolejí a sestaven pořadník, • udělení kolejí – probíhá sestavením pořadníku ubytovaných studentů, • předubytování a rezervace pokoje • ubytování studenta • platby studenta za kolejné a doplňkové služby • ubytování dalších osob na kolejích Základním kritériem pro přidělení kolejí je doba dojíždění, tj. časová vzdálenost místa trvalého pobytu žadatele a místem studia. Tato doba je určována systémem Koleje 2002 z databáze pořizované od provozovatele elektronických jízdních řádů, společnosti CHAPS, s. r. o. (CHAPS, http://www.chaps.cz). Databáze, upravená pro potřeby stanovení dojezdnosti, obsahuje všechny zastávky na území České a Slovenské republiky. IS KaM je prvním zástupcem produktů ApS Brno. Tento klientsky obsluhovaný kolejní ubytovací systém byl uvedený v roce 1996. Jedná se o program postavený na Microsoft Visual Basic modulech a datové základně Microsoft Acces. Tento systém využívají ubytovací kanceláře Správy kolejí a menz MZLU v Brně. Klientská architektura systému vyžaduje provádět replikace databází vytvořených na jednotlivých pracovních stanicích. Zásadním problémem je možnost vzniku konfliktu v průběhu pořizování replikací, který vede ke ztrátě konzistence databáze. (ApS Brno, 2003) uvádí, že čas potřebný k synchronizaci replik je přímo úměrný počtu změn, které se mají přenést. V praxi to znamená, že časy se pohybují mezi hodnotami 2–40 min. Po tuto dobu je nutné, aby si spojení zachovalo maximální spolehlivost. V opačném případě může dojít až k poškození jedné nebo obou replik účastnících se synchronizace, což zpravidla vede ke ztrátě dat. Tento jev není možné eliminovat, lze pouze minimalizovat jeho důsledky, neboť je vlastností samotného vývojového prostředí. Koleje 2002 je nástupcem IS KaM z roku 2002. Tento ubytovací systém je postaven na architektuře klient – server. Datovou základnu tvoří MS SQL server. Klientské aplikace jsou vyvinuté v prostředí MS Visual Basic. Velký důraz je u systému Koleje 2002 kladen na začlenění a komplexní pohled na problematiku. Jednotlivé dílčí systémy by měly vzájemně spolupracovat a doplňovat se. Tato vzájená integrace se týká se především přístupových systémů, systémů pro

2.3

Studentské ubytovací agendy

13

správu menzy (výdej jídel, normování stravy atd.), ubytování a předubytování studentů a dalších. Z této teorie vychází i architektura těchto systémů na bázi jednoho zdroje informací.

Obr. 1: Architektura informačních systémů na bázi jednoho zdroje informací (ApS Brno, 2003)

• • • • • •

2.3

Změny architektury systému Koleje 2002 oproti IS KaM: jedna datová základna – eliminace možnosti vzniku konfliktů dat, čtvrtinový rozsah klientských aplikací, automatická aktualizace klientské aplikace v případě úpravy, podpora pro využití identifikačních médií (čipové karty, magnetické karty atd.), grafická interaktivní prezentace obsazenosti pokojů (štafle), platby kolejného a dalších poplatků pomocí clearingového účtu kolejí, na jehož konto jdou pravidelná inkasa od studentů a také hotovostní platby provedené na clearingové pokladně.


Na ubytovací systémy, které řeší otázku samotného ubytování na kolejích navazují systémy, které umožňují studentovi podat žádost o ubytování, zjistit její stav a případnou další správu jeho ubytování týkající se zejména rezervace pokoje a kontroly plateb za ubytování. Masarykova univerzita v Brně Správa kolejí a menz (SKM MU, http://skm.muni.cz/) Masarykovy univerzity v Brně využívá pro ubytování studentů systém Koleje 2002. Přihlášku k ubytování na kolejích podává student prostřednictvím Informačního systému Masarykovy Univerzity v Brně (IS MU, http://is.muni.cz). Pro zpřístupnění informací o ubytování je pro studenty vyvinuto webové rozhraní umístěné na webových stránkách správy (SKM MU – Moje ubytování, https://ycollege.skm.muni.cz/). Toto rozhraní využívá služeb systému yCollege

2.3


14

firmy Y Soft (Y Soft, http://www.ysoft.cz). yCollege je projekt, který umožňuje snadnou a rychlou správu připojení univerzitní kolejní sítě na Internet. Integrace se stávajícím ubytovacím systémem umožňuje zobrazovat pomocí uživatelského účtu informace ze systému Koleje 2002. Přístupové jméno i heslo je totožné s IS MU. Verifikace je prováděna zasláním obdrženého hesla na server IS MU. Ten vrátí informaci, zda je heslo správné. Hlavní funkcí webového rozhraní je zjištění stavu aktuální žádosti. Po udělení kolejí je nutné, aby student potvrdil svůj zájem o koleje, provedl tedy předubytování. Tímto úkonem se již se studentem jedná jako s budoucím nájemníkem. Po předubytování může student provést rezervaci pokoje. Předubytování i rezervace se děje osobní návštěvou na ubytovací kanceláři kolejí. Změny stavu žádosti a důležitá upozornění jsou studentovi zasílána prostřednictvím univerzitního poštovního systému. Další informační hodnota spočívá v zobrazení historie ubytování, stav dřívějších žádostí a výpis studentových plateb za koleje. Při obsazování volných lůžek v průběhu akademického roku je opět využito informačního systému univerzity. Jednou týdně jeho pomocí může student vyjádřit svůj stálý zájem o koleje a tím se dostat do nejbližšího pořadníku. Pokud jsou mu koleje podle pořadníku uděleny je informován systémem webového rozhraní SKM a e-mailovou zprávou. Vysoké učení technické v Brně Tato univerzita integruje jak ubytovací systém Koleje 2002, tak systém pro výdej stravy ve vysokoškolských menzách, Menza 2000 ApS Brno. Menza 2000 byla navržena pro potřeby Kolejí a menz VUT v Brně (KaMB, http://www.skm.vutbr.cz/), které upustilo od objednávkového systému stravování. V informačním systému univerzity (Brutis, http://pony.ro.vutbr.cz) je část Koleje a menzy. Zde je studentovi umožněno pracovat s informacemi o jeho ubytování a stravování. Podání žádosti o ubytování na příští akademický rok je základní aplikace. Student její pomocí požádá o ubytování na kolejích. Ve své žádosti si může vybrat nejen koleje, ale přímo i pokoj, na kterém chce bydlet. Žádost obsahuje všechny relevantní údaje, včetně bankovního účtu pro inkaso kolejného. Podáním žádosti student potvrdí pravost údajů v ní uvedených. Přehled volných pokojů slouží k informování o možnostech výběru pokoje pro podání žádosti či rezervaci. Jedná-li se o pokoj, na kterém již student bydlí nebo volný pokoj, může jeho rezervaci provést hned, jinak až v termínu k tomu stanoveném. Nemá-li student zájem o konkrétní pokoj, vybere volbu „libovolný pokojÿ a v potaz se bere pouze blok kolejí. Aplikace Obraty Menza 2000 zobrazují studentovy pohyby na jeho účtu KaMB VUT v Brně. Jsou zde zobrazeny všechny údaje o výdeji či vkladu na kartu.

2.3


15

České vysoké učení technické v Praze Na ČVUT v Praze má otázku kolejí na starosti Správa účelových zařízení (SÚZ, http://www.suz.cvut.cz/), pod jejíž vedením fungují koleje, hotely, menzy a sportoviště ČVUT v Praze. Žádost o koleje je zveřejněna ke stažení na webových stránkách správy. Žádost, ve formátu Microsoft Word .doc, student vyplní a odevzdá. Na stránkách je dále aplikace pro zjištění dojezdnosti. Její pomocí zjistí student výsledné body za dojezdnost. Pro výpočet bodů předá student aplikaci PSČ sídla obecního úřadu trvalého bydliště. Tento systém vykazuje ze sledovaných nejmenší míru integrace s ubytovacím systémem.

3

DOSAVADNÍ ROZDĚLOVÁNÍ KOLEJÍ NA MZLU V BRNĚ

3

16

Dosavadní rozdělování kolejí na MZLU v Brně

Systém rozdělování kolejí na Mendelově zemědělské a lesnické univerzitě v Brně nemá mezi analyzovanými univerzitami obdoby. Na všech ostatních školách udělují koleje celouniverzitně útvary spravující koleje a menzy bez ohledu na studentovu fakultu. Oproti tomu na MZLU v Brně rozdělují volná místa na kolejích prostřednictvím fakultních kolejních rad mezi své studenty děkani fakult. Ti mohou prostřednictvím vnitřního předpisu fakulty vytyčit vlastní kritéria pro udělení kolejí. Fakulta má k rozdělení určitý počet míst – kvótu, kterou jim stanovuje každoročně komise prorektora pro řízení ubytování. Vyjádření studentova práva na ubytování na koleji se děje udělením ubytovacího dekretu, který student obdrží od děkana. Vedle klasického řešení papírové agendy, představoval určitou modernizaci a vylepšení systém studijní agendy STUDENT. Doslova revolucí v udělování kolejí v prostředí MZLU v Brně byl na Provozně ekonomické fakultě předchůdce Univerzitního informačního systému – FIS, Fakultní informační systém PEF (Šorm a kol., 2000).

3.1

Papírové rozdělování kolejí

Systém tohoto rozdělování byl v minulosti klasickou papírovou agendou, která byla náročná zejména na administrativní práci. Informace byly předávány pouze výměnou papírových formulářů, které bylo nutné jednotlivě vyplnit. Podání žádosti o koleje Student doposud podával žádost o koleje vyplněním papírového formuláře, který odeslal, nebo odevzdal na studijní oddělení fakulty. V žádosti uvedl fakultu, kterou studuje, své osobní identifikační údaje, adresu trvalého bydliště, vzdálenost bydliště od místa studia a případná zdravotní a sociální hlediska pro přednostní udělení kolejí (důvody pro udělení kolejí). Pravdivost uvedených údajů potvrdil student svým podpisem. Svůj zájem bydlet na příslušných kolejích mohl student vyjádřit pouze poznámkou na tiskopise žádosti o koleje. Pro tento údaj nebyla na tiskopise žádná kolonka. Student neměl tudíž záruku, že si jeho poznámky na formuláři kolejní rada všimne a vezme ji v potaz. Při procházení kvanta podaných žádostí není přehlédnutí údaje standardně neuvedeného formulářem nic neobvyklého. Případné zvláštní sociální nebo zdravotní důvody pro udělení kolejí dokládal student předáním potvrzení od lékaře či úřadu sociálního zabezpečení příslušné studijní referentce na studijním oddělení. Udělování kolejí Samotné rozdělování se dělo v několika kolech. První kolo následovalo po shromáždění žádostí o koleje studentů, kteří v následujícím akademickém roce budou studovat druhý a vyšší ročník. V tomto kole nejsou rozdělena všechna místa. Je ponecháno

3.1


17

dostatečné množství míst pro uspokojení žadatelů, kteří v příštím roce nastoupí do prvních ročníků. Ti svoji žádost o koleje podají až při zápise do studia. Další kola probíhají zpravidla po shromáždění žádostí nově nastupujících studentů. V nich jsou podle mírnějších kritérií udělena místa studentům prvních ročníků. Zbytek míst je rozdělen mezi staršími studenty, kteří se již odvolali proti zamítavému rozsudku z prvního kola. Shromážděné žádosti bylo nutné zpracovat. V první řadě se jednalo o vyčlenění žádostí, které jsou nekompletní. Následně byly zvlášť setříděny žádosti s řádně doloženými a uznanými zvláštními důvody pro udělení kolejí. Doložení zvláštního důvodu neznamená automatické přednostní udělení kolejí. Závažnost důvodu posuzuje kolejní rada. Ještě jednu skupinu žádostí bylo nutné vyčlenit – žádosti studentů doktorských studijních programů. Těm jsou koleje udělovány automaticky, nevztahuje se na ně pořadí podle dojezdnosti. Úplné žádosti studentů bakalářských a magisterských studijních programů bez uznaných zvláštních důvodů byly seřazeny podle kilometrické vzdálenosti. Řazení bylo prováděno na základě údajů, které uvedl student. Nebývalo proto nezvyklé, že studenti se stejným místem trvalého pobytu měli rozdílné dojezdové vzdálenosti. To mohlo být způsobeno jednak využitím jiného spoje a jednak úmyslnou manipulací se vzdáleností studentem. Necentralizovaný systém výpočtu vzdálenosti a snaha studentů i nečestně získat koleje znevýhodňoval studenty, kteří dojezdovou vzdálenost udali přesně. Další možností manipulace dojezdové vzdálenosti byla „účelová změna bydlištěÿ. V těchto případech student úředně změnil místo svého trvalého pobytu a kopii rozhodnutí přiložil k odvolání žádosti o koleje. Dožadoval se tak udělení kolejí podle jiné, samozřejmě větší, vzdálenosti. Oproti ostatním žadatelům byl tento student neoprávněně zvýhodněn. Při špatné provázanosti studijího oddělení a kolejní rady nemusel student tuto změnu hlásit na studijním oddělení. Vyhnul se tak nepříjemnosti ze změny byplívající – jiná adresa pro doručení písemností. Kolejní rada měla možnost, při chybném uvedení, vzdálenost upravit, nebo zkontrolovat na studijním oddělení správnost adresy trvalého pobytu. Kontrola a následná úprava těchto údajů všech žadatelů nebyla ovšem v silách rady. Proto přistupovala zejména k úpravám markantních rozdílů vzdáleností a úpravě vzdáleností měst, které se blížili hranici pro udělení a neudělení kolejí. Studentům z těchto měst byla vzdálenost sjednocena tak, aby ji měli všichni stejnou a tudíž se v jednom sídle nenašli dva studenti z jedné fakulty s jiným rozhodnutím o udělení kolejí bez přihlédnutí ke zvláštním důvodům. Po seřazení podle vzdáleností byl určen počet studentů, kterým budou v tomto kole udělování koleje uděleny. Vyhotovení seznamů a dopisů Ze všech žádostí o koleje bylo nutné sestavit seznamy studentů. Ty byly vyhotovovány jednak z uspokojených studentů, jednak ze studentů, jimž byla žádost o koleje zamítnuta. Seznamy nebyly vyhotovovány pouze pro potřeby kolejní rady při udě-

3.1


18

lování kolejí. Z vyhlášky o řízení ubytování vyplývá kolejní radě povinnost předat ubytovacím kancelářím jednotlivých kolejí seznam studentů, kterým byl udělen ubytovací dekret pro tyto koleje. Ruční vyhotovování seznamů, které musela kolejní rada provést značně stěžovalo její práci. K usnadnění vyhotovení seznamů se využívalo tabulkového procesoru. Ten umožnil provádět různá třídění a řazení žadatelů. Žadatelům, kterým bylo v jejich žádosti vyhověno byl vystaven ubytovací dekret. Zhotovení dekretu probíhalo doplněním studentovy adresy, ročníku studia a označení fakulty, která koleje uděluje, na tiskopis, který pro příslušný rok stanovila komise pro řízení ubytování. Dekret byl dále ručně očíslován pro fakultu jedinečným číslem. Čísla se udělovala podle pořadí dekretu. Z důvodu evidence bylo nutné číslo zanést ještě do seznamu. Po zhotovení dekretů byly tyto opatřeny podpisem děkana fakulty a úředním razítkem. Adresaci dekretu bylo možné provést dvojím způsobem. Prvním bylo napsáním adresy přímo do tiskopisu. Tento způsob představoval ruční či strojopisové vypsání velkého množství dekretů. Druhou možností bylo opětovné využití tabulkového procesoru a již zhotovených seznamů. Z těch byly pomocí CSV souborů vytvořeny adresní štítky, které byly vytištěny a následně nalepeny do tiskopisu na místo adresy. Každý štítek byl pro ověření pravosti orazítkován úředním razítkem. Studentům, kterým nebylo vyhověno v jejich žádosti měl být zaslán zamítací dopis, proti kterému se měli možnost písemně odvolat. Zde se praktika fakult rozchází. Některé z nich rozhodnutí o zamítnutí žádosti rozesílaly, jiné z úsporných důvodů pouze vyvěsily seznam uspokojených žadatelů. Student, který podle údajů na seznamu nebyl uspokojen se mohl proti rozhodnutí taktéž odvolat. Ubytovací dekrety a zamítací dopisy byly následně uloženy do obálek a nachystány pro hromadné odeslání z podatelny. Pro hromadné odesílání zásilek je nutné zhotovit pro potřeby České pošty, s. p., sestavu odeslaných dopisů. Jedná se o vyplnění poštou vydaného tiskopisu. To bylo nutné provést ručně. Ubytování studentů V září se studenti, kteří obdrželi ubytovací dekret, dostavili k ubytování. Kolejní rada jim předala potřebné formuláře a zvolila pokoj. Na základě údajů z evidenční karty ubytovaného je ubytovatelka zanesla do ubytovacího systému kolejí. Pokud na kolejích bydlel student již dříve, nebylo nutné údaje do systému zadávat, u ostatních studentů ano. V průběhu školního roku bývá studijní oddělení fakulty dotazováno sociálními úřady na fakt, zda studenti pobírající příspěvek na dopravu nebydlí na kolejích. Doplňováním do těchto seznamů prováděly ubytovatelky na kolejích. Ty musely každého studenta zvlášť vyhledat v ubytovacím systému.

3.2

3.2

Využití systému STUDENT

19

Využití systému STUDENT

Pro zjednodušení agendy rozdělování kolejí byl využíván i systém studijní agendy STUDENT. Ten byl vyvinut na tehdejším oddělení Automatizace informační soustavy (AIS) pro potřeby studijních oddělení fakult MZLU v Brně. Jednalo se o klientsky obsluhovaný systém, který pracoval s databázovými soubory a uchovával o studentovi všechny důležité informace. Nad údaji o jednotlivých studentech (systém jich uchovával desítky) bylo možné provádět operace selekce a projekce. Z údajů systém umožňoval tvořit tiskové sestavy adresních štítků, tisk na samostatné obálky, tisk seznamů a exportní CSV soubory pro další využití. Zařazování studentů do sestav probíhalo buď databázovou selekcí, nebo „ručnímÿ výběrem ze seznamu skupiny studentů. Kolejí se týkaly, kromě adresy a identifikace studenta, jen tři údaje – informace, zda podal student žádost, zda mu byly uděleny koleje a jaká je jeho vzdálenost od místa trvalého bydliště do místa studia. Z celkového souboru studentů byly proto projekcí vybrány jen výše uvedené údaje a vybrání ti studenti, kteří si podali žádost o koleje. Z podmnožiny údajů již referentka mohla systémem STUDENT sestavovat podle potřeby seznamy nebo tisknout adresní štítky k nalepení na dekrety a zamítací dopisy.

3.3

Koleje v rámci FIS

Na Provozně ekonomické fakultě byla Kolejní administrativa řešena v rámci projektu FIS Fakultním informačním systémem PEF (Šorm a kol., 2000). Systém obsahoval menší okruh aplikací, které umožňovali podání žádosti o koleje, hromadné udělení kolejí a tisk ubytovacích dekretů a seznamů studentů pro koleje. Autorem těchto aplikací byl vývojář Ing. Lukáš Bártík a dále je udržoval Ing. Tomáš Majer. Funkčnost a struktura těchto aplikací byla podobná se současnou Kolejní administrativou. Koleje byly stejně jako celý systém FIS koncipovány pouze pro použití na jedné fakultě. Součástí této agendy byl také systém pro výpočet vzdálenosti místa trvalého bydliště od místa studia. Pro výpočet bylo použito algoritmu dijkstra, který řeší problém nalezení nejkratšího spojení mezi dvěma body v grafu. Jako síť grafu byly použity všechny obce, pro které byla vzdálenost zjišťována a jako hrany vzdálenosti těchto míst. Algoritmus měl ovšem značnou časovou složitost. Osobní zkušenosti s užíváním Kolejí ve FISu z pohledu člena kolejní rady vedly autora této práce k návrhu a tvorbě stávající agendy řešící problematiku celouniverzitně.

4

POUŽITÉ TECHNOLOGIE

4

20

Použité technologie

Kolejní administrativa je jednou z celouniverzitních agend Univerzitního informačního systému Mendelovy zemědělské a lesnické univerzity v Brně. Jako jeho součást byla vyvinuta, je v něm proto plně integrována a je přizpůsobena jeho technologiím. Pro výpočet vzdálenosti místa trvalého bydliště využívá knihoven programovacího jazyka Perl. Předáváním dat s ubytovacím systémem na SKM MZLU v Brně se stala spojovacím článkem kolejí a UIS.

4.1

Univerzitní informační systém

Studium a jeho zabezpečení je stěžejní náplní činnosti vysoké školy. S ním souvisí celá řada dalších skutečností. Pokud ke studiu přidáme navíc druhou nejvýznamnější oblast působnosti vysoké školy – subsystém pro vědu a výzkum, získáme oblast pro rozsáhlý integrovaný informační systém. Z důvodu značného rozsahu začleněných informací je pro jejich sběr, třídění, uchovávání a získávání použito prostředků výpočetní techniky. Jedná se konkrétně o typový webový informační systém vyvinutý právě pro potřeby vysokého školství. Systém dostal název Univerzitní informační systém Mendelovy zemědělské a lesnické univerzity v Brně, zkráceně UIS. Vývojem systému od analýzy přes implementaci až po uvedení do rutinního provozu se zabývá, k tomuto účelu v roce 1998 vybudovaný, Vývojový tým UIS. Ten při vývoji navázal na úspěšný pilotní projekt Fakultního informačního systému Provozně ekonomické fakulty – FIS. Ten nahrazoval dříve používaný systém studijní evidence STUDENT a integroval další používané agendy. UIS na tuto myšlenku navázal, s cílem integrovat postupně všechny specifické oblasti, které na univerzitě zpracovávají decentralizované informační systémy. Od června 2003, kdy došlo k restrukturalizaci oddělení rektorátu MZLU v Brně zabývajících se IS/ICT, působí na univerzitě Ústav informačních a komunikačních technologií (ÚIKT). Jeho Oddělení koncepce a vývoje zastřešuje nadále Vývojový tým UIS a stará se o další vývoj systému. V jeho čele stojí autor koncepce UISu RNDr. Ing. Milan Šorm. O provoz se v současnosti stará Oddělení provozu a správy aplikací (OPSA) ÚIKT. Třetí oddělení, Oddělení infrastruktury (OI), zabezpečuje chod výpočetní techniky a její propojení. OPSA také provozuje EkonFis – provozní informační systém školy obstarávající oblasti ekonomiky a řízení. EkonFis tvoří samostatný systém, který je s UIS propojen každodenní synchronizací dat. Namísto implementace této zásadní oblasti přímo do prostředí UIS zvolilo vedení univerzity outsourcingové řešení – modulární systému SAP. Jeho integrace je zatím v začátcích. V současnosti (květen 2004) probíhají školení pracovníků.

4.2

4.2

Výklad základních pojmů

21

Výklad základních pojmů

Pro pochopení dalšího výkladu a celé architektury UIS je nutné poznat základní pojmy týkající se informačních systémů, zejména pojmy z teorie webových informačních systémů. Informační systém Představuje uspořádaný souhrn lidí, technických prostředků a metod zabezpečujících sběr, přenos, uchování a zpracování dat za účelem tvorby a prezentace informací pro potřeby uživatelů, činných v systémech řízení. Transformaci dat od sběru po prezentaci lze provádět pomocí výpočetní techniky. Informační systém vystavěný nad prostředky počítačové techniky nazýváme IS/ICT technologií. (Rábová, 2003) Integrovaný informační systém Pokud je informační systém natolik rozlehlý, že pokrývá většinu agend podniku a je sestaven z více subsystémů nazýváme jej integrovaným. Takovýto systém je tvořen systémovou integrací, smysluplným propojením hardware, software, podnikových procesů a okolního prostředí. Osobou provádějící tento proces může být jak svépomocí tvořící vývojáři, tak externí dodavatel. Dodavatelská forma tvorby informačního systému se nazývá outsourcing. (Rábová, 2003) Webový informační systém (WIS) Definujeme jako takový parametrizovaný informační systém, který je provozován v nelineárním nestavovém síťovém prostředí (a nabízí tudíž svým uživatelům v maximální míře přizpůsobení jeho chování pomocí nastavení parametru). Takový systém pak mj. řeší problematiku autentizace, auditování, modularizace, serializace, oprávnění, proměnlivého datového modelu, personalizace, hierarchického zařazení uživatelů a samodokumentace. (Šorm, 2003) Nelinearita – specifičnost prostředí www oproti klasickému prostředí klient/server přináší základní problémy nelinearity a nestavovosti. Nelinearita spočívá v tom, že prováděné operace nemusí mít počáteční vstupní bod a dodržovat očekávanou posloupnost. Toto narušuje uživatel zadáním přesné URL prohlížeči a používáním tlačítek prohlížeče Back a Reload. Princip odstranění nelinearity je založen na serializaci požadavků (jednotné identifikaci, jednoznačnosti a zaručení posloupnosti). Nestavovost – souvisí s nelinearitou. Jednotlivé požadavky na sebe nijak nenavazují, je proto nutné na ně nahlížet jako na jednotlivé a samostatné přístupy k informačnímu systému. Při sestavování operací z více izolovaných kroků je nutné zajistit transport dat mezi těmito kroky. Ten je možné provést buď přenosem parametrů mezi jednotlivými aplikacemi, nebo skladem parametrů relace.

4.3

Implementační prostředí UIS

22

Autentizace, autorizace a systém oprávnění – každý uživatel má v systému definovanou jinou roli, která je specifikovaná přístupovými právy. Vzhledem k nelinearizaci požadavků je nutné při každém z nich provést autentizaci uživatele. Metody autentizace, které nám nabízí teorie WIS, jsou autentizace závislá na platformě (modul pro server Apache) a autentizace tiketováním. Tiketování (veřejné či vystavěné na principu cookies) je obecně přenositelnější a nabízí větší možnosti řízení relace týkající se odhlašování, doby přihlášení a spotřeby zdrojů. Modularita – principy koloběhu vývoje (analýza – návrh – vývoj – testování – provoz), postupného uvolňování aplikací a úpravy podle požadavků uživatelů WIS vyžaduje možnost spolupráce více vývojářů na jedné rodině aplikací a proměnlivost jejich počtu. Tento způsob vývoje je umožněn díky důslednému uplatnění modularity na všech úrovních vývoje. Jednotnost ovládání – vychází z modularity. Pro tvorbu jednotlivých aplikací využívají vývojáři ustálené, v modulech definované, prvky, které uživatel zná a je schopen je bezproblémově ovládat. Důležitou vlastností je jednotnost designu a vzhledu navigačních prvků.

4.3


Univerzitní informační systém je, jak již bylo uvedeno webový informační systém. Jako takový byl vystavěn na webovém serveru Apache, aplikacích vytvořených v programovacím jazyce Perl (specifikace mod perl),a s datovou základnou spravovanou databázovým systémem Oracle9i. Provoz UIS zajišťuje pro tyto účely sestavený výkonný servrový cluster. Databázová platforma Oracle9i Databázová platforma Oracle9i je pojem zahrnující databázový server včetně sady nástrojů pro správu a zabezpečení dat v databázi. Všechny tyto nástroje jsou dodávané společností Oracle, případně třetími stranami, přičemž i tyto nástroje se vztahují k platformě Oracle9i. Pokud vynecháme slovo „databázováÿ, budeme pod pojmem „Platforma Oracle9iÿ chápat vedle databázové části také aplikační server (Oracle9i AS), případně další serverové aplikace. Oracle9i je objektově-relační platforma, též někdy nazývaná jako „postrelačníÿ. Obsahuje tedy objektové typy a pro manipulaci s daty v objektových tabulkách využívá objektových přístupů. (Lacko, 2003) Databázový systém – spojení databáze a systému řízení báze dat (SŘBD). Přitom databází rozumíme strukturovanou množinu homogenních souborů, tedy data uložená v určitých strukturách. SŘBD je integrovaný softwarový prostředek řídící bázi dat, tedy nástroje sloužící pro ukládání a manipulaci s daty. Existují různé modely uspořádání dat ve strukturách. Text této práce se bude věnovat pouze modelu relačnímu. Právě ten využívá UIS jako své datové základny.

4.3


23

Relační databázový model – představuje v současnosti nejpoužívanější model souboru dat. Je tvořen pouze jediným definičním konstruktem databázové relace. Tu tvoří data a metadata, neboli schéma relace, určující jméno relace, jména atributů a jejich domény – datové typy. Relační model musí podle (Lacko, 2003) splňovat následující minimum: • všechna data v databázi jsou uložena v tabulkách, • fyzická struktura dat a jejich uložení je na uživateli nezávislé a odstíněné, • předpokládá se existence databázového jazyka, který umožňuje realizovat minimálně restrikci, projekci a spojení. Relační algebra – je matematickým jazykem pro zápis dotazů nad relacemi. Pracuje vždy s celými relacemi a umožňuje s nimi provádět množinové operace, projekci, selekci a kartézský součin. Tyto operace a jejich kombinace vytváří kompletní množinu operací s relačně uspořádanými daty. SQL – Structured Query Language je databázový jazyk blízký přirozenému jazyku (angličtině) vytvořený pro práci s daty v databázích. Oproti přirozené angličtině má ovšem přesně definovaná syntaktická a lexikální pravidla. Jedná se o dotazovací jazyk, mající tři podskupiny dotazů: • DDL – Data Definition Language. Pomocí příkazů z této skupiny můžeme definovat, vytvářet, měnit a rušit databázové struktury, jako jsou například tabulky, indexy, triggery, uložené procedury apod. • DQL – Data Querying Language. V podstatě jen jeden, za to však mocný příkaz – SELECT. Jeho pomocí klient zformuluje a položí dotaz databázi. Ta jej přenese, dekóduje, optimalizuje, provede a předá zpět klientovi. • DML – Data Modification Language. Skupina příkazů umožňujících vkládání, aktualizaci a mazání dat. PL/SQL – Oraclovská implementace procedurálního rozšíření jazyka SQL. Samotné SQL je sekvenčně prováděný neprocedurální jazyk, který neumožňuje užít cyklů, podmínek, větvení, procedur, funkcí ani objektového programování. PL/SQL tyto schopnosti má a navíc umožňuje deklarovat konstanty, proměnné a kurzory a to jak staticky, tak dynamicky, transakčně zpracovávat dotazy a podporuje modularitu. Normalizace databází – proces zjednodušování databází. Vede dále k odstranění redundancí dat a značně zefektivňuje práci s tabulkami. V případě relačních databází je možné konstatovat, že čím jsou tabulky ve vyšších normálních formách, tím lépe by se s nimi z hlediska aplikační logiky mělo pracovat. Tento výrok neplatí vždy. Ve speciálních případech zvyšování výkonu a tvorby datových skladů se od normalizace upouští. Hloubku normalizace definujeme normální formou. Každá z forem obsahuje vlastní omezení a zároveň zapouzdřuje podmínky všech norem předchozích. V relačních databázích je s výjimkou analýz OLAP doporučeno dodržovat minimálně druhou normu – tedy atomičnost atributů a závislost každého sloupce na primárním klíči.

4.3


24

Programovací jazyk Perl Perl – Practical Extraction and Report Language nebo také Pathologicaly Eclectic Rubbish Lister – jazyk vhodný pro manipulaci s texty, se silnou podporou regulárních výrazu, tedy vhodný pro vývoj CGI skriptů. Existují stovky modulů, ze kterých složíme aplikaci za několik minut. Rozhraní DBI dovoluje přistupovat k takřka všem komerčním i free databázovým serverům. Jedná se o přední skriptovací jazyk používaný pro vývoj webových informačních systémů. Autor Larry Wall navrhl Perl pro vlastní potřeby v roce 1983. Perl měl nahrazovat nedostačující prostředky pro zpracování textů a dálkové řízení počítačů a byl koncipován pro platformu operačních systémů třídy UNIX. Velké ohlasy na uvolnění způsobily rozšíření jazyka a jeho přenositelnosti. V současnosti se jedná o jeden z nejpřenositelnějších jazyků. Internetová komunita, která se zasluhuje o rozšiřování perlovských modulů i běznou uživatelskou podporu, zřídila a udržuje veřejně přístupný archiv všeho kolem Perlu CPAN (CPAN, http://www.cpan.org). Referenční příručkou jazyka je pro české uživatele (Wall, 1997). Perl – jazyk pro webový informační systém. Perl byl pro tvorbu UIS vybrán právě pro nativní podporu a komunikaci s webovým serverem Apache a možnostem, které nabízí. V první řadě jsou to vlastnosti, kvůli kterým vznikl, tj. práce s textem a regulární výrazy. Další skvěle využitelnou vlastností je pro hledání a řazení využitelné asociativní pole neboli hash. Podpora modulárního a objektového programování je u tak velkého projektu, jakým UIS bezesporu je, nutností. Pro generování kódu HTML je využito metod modulu CGI. CGI – Common Gateway Interface označuje jednoduché rozhraní, kterým lze napojit téměř libovolný externí program na WWW server. Napojení se odehrává výměnou vstupních dat, které program zpracuje a odevzdání dat předepsanou formou zpět. Velkým problémem toho rozhraní je bezpečnost. Jmenovitě možnost spouštění nechtěných programů ze serveru. Jediným způsobem zabezpečení je kontrola přijímaných dat a nedůvěra ve veškerou kontrolu provedenou přímo formulářem či JavaScriptem. (Satrapa, 2001) Vývojové prvky UIS Vývojový tým UIS za dobu své působnosti navrhnul a vyvinul nejen jádro systému a databázovou strukturu, ale i spoustu dalších prvků, které zefektivňují a zjednodušují jak práci systému, tak činnost programátorů. V této části jsou uvedeny zejména ty, které jistým způsobem ovlivnily implementaci Kolejní administrativy. Jádrem UIS rozumíme perlovské moduly poskytující aplikacím knihovny funkcí. Používání modulů umožňuje rychlý vývoj aplikací (tvůrce aplikace používá připravených vstupních formulářů a výstupních sestav), použití shodných prvků v aplikacích přináší konzistentní chování k uživateli, a to znamená rychlé seznámení s novými aplikacemi. Opakované použití funkcí v modulech a následně aplikacích znamená menší chybovost aplikací – jsou využívány ověřené funkce, ve kterých by měly být

4.4

Typografický systém TEX

25

chyby odstraněny. Nové chyby se pak mohou objevit pouze v nově programovaných částech aplikací. (Procházka, 2003) Šablonování je způsob uložení dat v relační databázi. Šablony objektů popisují atributy jednotlivých objektů v závislosti na hierarchii uživatelů a právním systému. V rámci webového informačního systému jsou šablony rozšířeny o tzv. mutované šablony. Informace o objektech lze potom uchovávat v závislosti na mutačním klíči (např. uložení syllabu předmětu v různých jazykových verzích/mutacích). Šablony tak přinášejí, v případě prostých šablon, dvourozměrně definovanou strukturu (objekt, atributy), v případě mutovaných šablon pak trojrozměrně definovanou strukturu (objekt, atributy, mutace). Princip šablonování umožňuje zásadním způsobem modifikovat strukturu uchovávaných dat pomocí jazyka pro modifikace dat (DML) místo užití jazyka pro definici dat (DDL). Při kombinaci s hierarchií uživatelů a právním systémem umožňuje šablonování přivést do informačního systému maximální množství parametrizace systému. Všechny aplikace se po provedení datové změny přizpůsobí a začnou nová data používat. Využití šablonování umožňuje vytvářet aplikace řízené datovou vrstvou. Standardizované aplikace potom nechají ovlivňovat svou náplň práce právě daty. Uživatelé tak získávají nástroj, kterým mohou systém rozšiřovat a vylepšovat bez nutnosti konzultovat vývojový tým. Výhody předčí i větší režii databáze při zpracování sestav a provádění náročnějších dotazů nad daty. (Šorm, 2003) Obecná kvalifikace je mechanismus výběru určité podskupiny objektů s určitými vlastnostmi, bez tvorby dotazu přímo v aplikační vrstvě programátorem. Dotazy připravuje dle požadavků aplikačních programátorů datamanagement pomocí aplikací k tomu určených a ukládá je v databázi. Programátor je potom zavolá použitím PKG KVALIFIKATOR. Více o této problematice (Kutín, 2004).

4.4

Typografický systém TEX

Jak uvádí (Rybička, 2003), TEX je volně šířitelný systém počítačové sazby, který vytvořil Donald E. Knuth ze Stanfordské univerzity. Vytvořil jej proto, aby mohl své texty publikovat v požadovaném tvaru, protože sazeči v tiskárně vnesli obvykle do matematických vztahů mnoho chyb. Koncepce systému je navržena tak promyšleně a obecně, že od roku 1983, kde se rozšířila první verze, nedošlo k žádným zásadním změnám. Tento systém, v němž je definováno přes tři sta příkazů, obsahuje mocný mechanismus pro rozšiřování vlastních schopností. Proto nad ním byly vytvořeny nadstavby, které umožňují snadnější a přirozenější zápis sázeného textu. Jednou z nejvýznamnějších volně šířených nadstaveb je systém LATEX, vytvořený Leslie Lamportem z Digital Equipment Corporation. Charakteristiku LATEXu uvádí (Rybička, 2003): LATEX není určen jen pro sazbu matematických textů. Obsahuje mnoho pomůcek pro poměrně snadnou sazbu běžných publikací – článků, zpráv nebo knih. Základní myšlenkou této nadstavby je

4.5

LWP – The World-Wide Web Library for Perl

26

zpřístupnit běžným uživatelům poněkud složitý jazyk pro sazby. Většina příkazů tedy uživateli nabízí, co chce sázet, nikoliv jak to chce sázet. Tento princip spolu s odvozovacím mechanismem pro tvorbu nových příkazů umožňuje zcela zobecnit význam jednotlivých prvků uživatelova dokumentu a přizpůsobit je konkrétnímu použití v různých situacích. V podmínkách UIS je nadstavby LATEX využito při generování všech tiskových výstupů. K těmto účelům vyvinutý modul Tisk UIS.pm provádí on-line sazbu. Aplikace připraví z databáze strukturovaná data, která nasází podle stylů do zdrojového kódu LATEXu. LATEX kód přeloží do formátu DVI, který předá programu GhostScript. Ten zajistí tisk na předvolenu tiskárnu prostřednictvím UNIX lpr, Samby, nebo vygeneruje dokument ve formátech PDF či PostScript. (Přichystal, 2002)

4.5


Knihovna LWP (libwww-perl), je sada perlovských modulů, které zprostředkovávají jednoduché a ucelené aplikační programové rozhraní ke službě World-Wide Web. Hlavním cílem knihovny je zajistit třídy a funkce umožňující tvorbu WWW klientů. Dále knihovna obsahuje moduly které mají obecné užití a třídy sloužící k implementaci jednoduchých HTTP serverů. Většina modulů knihovny zpřístupňuje objektově orientované rozhraní. Uživatelský agent, zaslané dotazy i obdržené odpovědi, vše je reprezentováno prostřednictvím objektů. Objektové pojetí tvoří jednoduché a účinné rozhraní k těmto službám. Rozhraní je otevřené veškerým rozšířením a vlastním vylepšením uživatele/programátora. Protokol HTTP Protokol HTTP je jednoduchý aplikační síťový protokol využívající služeb transportního protokolu TCP. Tento protokol tvoří základ systému World-Wide Web. Při komunikaci založené na principu klient/server obdrží na svůj požadavek klient odpověď formou textové zprávy. Formát a obsah textových zpráv je specifikován v RFC dokumentech. Komunikace pomocí protokolu HTTP začíná klient ustanovením spojení se serverem a zasláním požadavku formou dotazu – request. Zpráva obsahuje URI (Uniform Resource Identifier), verzi protokolu a zprávu typu MIME obsahující parametry dotazu, informace o klientovi a volitelně tělo zprávy. Server odpoví taktéž pomocí zprávy obsahující tentokrát verzi protokolu zprávy, kód úspěchu či chyby a MIME zprávu – informace o serveru, skupinu metainformací a volitelně tělo. Každá HTTP zpráva má záhlaví, kterým rozumíme část zprávy obsahující hlavičky. Hlavičky se liší podle typu zprávy a identifikují jak zprávu jako takovou tak i data k ní připojená. Informace, které obsahují, určují například datum vytvoření zprávy, typ zprávy, identifikaci klienta a serveru, základní, předchozí a přesměrovanou URL a další.

4.5


27

Dotaz může být položen formou následujících základních metod: • GET – požadavek o zaslání celé entity specifikované URI. • HEAD – požadavek záhlaví entity specifikované URI. • POST – požadavek o přijetí obsahu zprávy do entity specifikované v URI (např. zaslání dat do formuláře, připojení dat do databáze, . . .) LWP::UserAgent LWP::UserAgent je modul implementující uživatelského agenta služby WWW v jazyce Perl. Přináší dohromady třídy modulů HTTP a LWP umožňující využít všechny možnosti jádra knihovny libwww-perl. Díky svému jednoduchému použití může být modulu využito přímo k vyřízení WWW požadavků, nebo k účelům pro aplikace typického chování. Při běžném použití je vytvořen objekt třídy LWP::UserAgent, který je následně nastaven hodnotami pro spojení. Objekt následně vytvoří požadavek HTTP::Request. Ten je použit postoupením některé dotazovací metodě objektu UserAgent, která jej vyřídí použitím příslušného protokolu a vrátí HTTP::Response. Tento postup je u nejpoužívanějších typů dotazů zjednodušen použitím metod get(), head() a post(). (CPAN, http://www.cpan.org)

5

PŘEDIMPLEMENTAČNÍ STUDIE KOLEJNÍ ADMINISTRATIVY

5

28

Předimplementační studie Kolejní administrativy

Před samotnou realizací aplikací Kolejní administrativy, v březnu 2003, byla vypracována tato předimplementační studie, která měla za cíl poodhalit úskalí vývoje a navrhnout strukturu systému. Při její tvorbě vycházel autor z požadavků, které na udělování kolejí kladl (Kolejní řád, 1997) a (Vyhláška o ubytování, 2003). Cenným zdrojem informací byly dále osobní zkušenosti členů kolejní rady a studijních referentek s udělováním kolejí v minulosti. Velká část poznatků vycházela z agendy kolejí ve Fakultním informačním systému PEF. Studie byla konzultována s vedoucím studijního oddělení PEF Ing. Dedíkovou, studijní referentkou PEF paní Škubalovou a vedoucím tehdejší Sekce studijního systému UIS Ing. Dařenou. Zde uvedený text studie plně koresponduje se stavem z března 2003. Změny a odklony od původní studie, které Kolejní administrativa prodělala během svého vývoje jsou uvedeny v části Zhodnocení práce.

5.1

Požadavky na Kolejní administrativu

Maximální automatizace procesů Zvýšení automatizace procesů je jedním z důvodů zavádění Kolejní administrativy. Je nutné stanovit hranici odlišující automatické procesy v udělování a vstup lidského faktoru, který je zde nezbytný. Varianta plně automatizovaného udělování je sice implementovatelná, avšak v našich podmínkách nemožná. Podávání žádostí by bylo spuštěno parametry období. Po jeho ukončení by systém vyčkával na stanovení kvót kolejí. To by bylo impulsem pro seřazení žádostí podle kritérií a rozhodnutí systému komu koleje udělit. Následně by byly vygenerovány dopisy. I kdyby spouštění jednotlivých činností bylo možné řídit, nemožnost zasahovat do jejich průběhu by přinesla jen komplikace. Začlenění všech fakult Udělování spojuje celouniverzitní a fakultní přístup způsobem, který je v podmínkách celého UIS jedinečný. Student žádá o koleje jako osoba studující na univerzitě prezenční studium. Není podstatné, na které fakultě toto studium realizuje. V momentě udělování kolejí ovšem kolejní rady jednotlivých fakult vybírají podmnožinu studentů, kteří studují prezenční studium právě na jejich fakultě a rozhodují, zda studentovi koleje udělí či ne. Studentovi jsou uděleny koleje a on se při ubytování dostaví za kolejní radou, která mu koleje udělila. Při tom je důležité studentům, kteří studují na Zahradnické fakultě umožnit udělit koleje v Lednici. V momentě udělení kolejí se zapíše údaj, která fakulta studentovi koleje udělila a té on potom nadále v řízení o kolejích pro daný akademický rok přísluší.

5.2

Prototypování aplikací

29

Studentům, kteří studují prezenční studium na více fakultách může koleje udělit kterákoliv z nich, ovšem pouze ta, která se k tomu rozhodne jako první. Pokud mu tato fakulta koleje posléze odebere, mohou mu ostatní fakutly koleje udělit. Spekulace, kterou mohou fakulty ušetřit několik míst ve své kolejní kvótě, se nebere v úvahu. Komunikace univerzita – kolejní rady – SKM Komunikace vedení univerzity s SKM prostřednictvím kolejních rad je nezbytně nutná pro součinnost a návaznost procesů udělení kolejí, ubytování studenta a jeho vystěhování po ukončení studia. Doposud tato komunikace probíhala pouze předáním seznamů studentů, jimž byly uděleny koleje. Vytištěný seznam pomáhal kolejní radě v ubytování, ubytovací kancelář jej využila pouze v případě, že se student dostavil k ubytování v době, kdy ještě neprobíhalo ubytování. Jedná se zejména o studenty doktorských studijních programů, kteří se potřebují ubytovat s předstihem. Kolejní rada je na kolejích ovšem nejdříve první den řádného ubytování. Předání seznamů formou tiskových sestav přineslo na koleje informaci o studentovi, ovšem pouze jeho jméno, adresu trvalého bydliště, případně ročník studia. Další zpracování těchto informací bylo odkázáno na jejich přepis. Transporty dat mezi UIS a ubytovací kanceláří by měly umožnit zefektivnit ubytování. Pokud bude mít ubytovatelka u studenta předvyplněny všechny důležité údaje, ubytování se výrazně zrychlí.

5.2


Aplikace Kolejní administrativy budou rozčleněny na dvě části. Přístup k nim bude umožněn uživatelům s aktivním studiem nebo oprávněním UIS pro členy kolejní rady. Pokud bude uživatel spadat do obou kategorií, budou mu aplikace přístupny všechny. Část pro studenty • Úřední deska kolejní rady – vychází z potřeb kolejní rady informovat studenty, zejména o pravidlech udělování kolejí, postupech při podávání žádostí a ubytování a termínech všech těchto akcí. • Podání žádosti o koleje – Student si vybere preferovanou kolej a oznámí odevzdání potvrzení o doplňujících kritériích pro udělení na studijním oddělení. • Zjištění vyřízení žádosti – Zobrazení aktuálního stavu žádosti o koleje. • Projevení zájmu o koleje – V průběhu akademického roku student, který si podal odvolání žádosti o koleje, projevuje zájem o koleje. Tím se dostane do pořadníku, ze kterého jsou zaplňovány uvolňované kapacity kolejí.

5.2


30

Část pro kolejní rady • Administrativa úřední desky – Aplikace pro správu příspěvků na úřední desce. • Podání žádosti za jinou osobu – Možnost dohledat studenta a podat za něj žádost o koleje. • Hromadné udělení kolejí – Žadatelům je dávkově možné udělit koleje. Výpis je proveden po částech z důvodu náročnosti aplikace. • Tisk seznamů, dekretů, zamítnutí – Aplikace pro tvorbu a tisk potřebných sestav. – seznamy obsahují název seznamu, datum vytištění, ID, jméno, obor, semestr, adresa, vzdálenost (prospěch), zda byly koleje uděleny nebo vytištěn dekret. – dekrety – číslování dle fakulty a ID studenta. • Zjišťování zájmu – Sestavení pořadníku pro rozdělení míst, která se uvolnila během roku. Sestavením se aplikace nuluje a pro další týden musí student zájem znovu potvrdit. • Specifika studentů nastupujících do prvních ročníků studia – v aplikacích je nutné ošetřit případy studentů nastupujících do studia libovolného programu, zejména z těchto důvodů: – v srpnu student ještě není zaveden v databázi UIS, nemá zde účet a žádost o koleje musí podat písemně, – není jednotný termín přijímání a zápisů, – je snaha udělit koleje co nejdříve. Plán vývoje • podávání žádostí – březen/duben 2003, • udělování míst a tisk seznamů, dekretů a odmítnutí – duben 2003, • projevování zájmu – září 2003. Otázky, které je nutno dořešit v průběhu implementace • • • •

oprávnění pro přístup k udělování, odebrání kolejí při ukončení studia – nahlášení na SKM a vystěhování studenta, kvóta kolejí – pevný počet míst, na který se můžeme bezpečně spolehnout výpočet vzdáleností – algoritmus pro generování dojezdové vzdálenosti.

Výhledy do budoucna • Pokusit se prosadit zrušení ubytovacích dekretů, zamítacích dopisů a tím pádem i odvolání proti neudělení kolejí. Dále se zasadit o omezení formulářů při ubytování. • Vyřešit otázku rezervace pokojů studenty – předubytování pomocí UISu.

6

IMPLEMENTACE KOLEJNÍ ADMINISTRATIVY UIS

6

31

Implementace Kolejní administrativy UIS

Podle výše uvedené studie, poznatků teoretické části této práce a poznatků, které se vyplynuli na povrch až v průběhu implementace, byla vytvořena následující implementace Kolejní administrativy UIS. Kromě aplikací UIS obsahuje i algoritmus výpočtu dojezdové vzdálenosti, zakládání žádostí nových studentů a předávání dat se SKM MZLU v Brně.

6.1

Aplikace Kolejní administrativy

V systému jsou dvě základní skupiny uživatelů Kolejní administrativy. Na straně jedné studenti, kteří chtějí vyjádřit svůj zájem o koleje a na straně druhé členové kolejních rad a studijní referentky, které mají za úkol koleje rozdělit a rozeslat studentům ubytovací dekrety. Pro druhou skupinu existují následující oprávnění: • koleje-p – právo umožňující zobrazovat a tisknout seznamy vyhověných a zamítnutých žádostí • koleje-e – kompletní správa žádostí a možnost udělit koleje, zahrnuje i právo koleje-p • koleje-v – generování dojezdové vzdálenosti U referentských aplikací se v případě, kdy má uživatel příslušné oprávnění pro víc fakult, nabídne výběr fakulty, za kterou chce pracovat. Tento výběr se může u udělování kolejí zdát v rozporu s tvrzením, že student žádá o koleje ne za své studium na některé fakultě, ale za svou osobu. Je nutné si uvědomit, že koleje jsou udělovány z počtu míst na kolejích, které dostala jako kvótu určitá fakulta a ta je rozděluje mezi své studenty. Může nastat situace, kdy je nutné souběžně spravovat v rámci fakulty žádosti podané na různá období. Například v dubnu, kdy už jsou zpravidla podány žádosti o koleje, je potřeba manipulovat ještě s žádostmi na nynější období, protože na základě těchto žádostí studenti bydlí a na období další, protože se blíží rozdělování kolejí. U všech referentských aplikací je proto nabízen výběr univerzitních období, které ještě neskončily a už u nich začalo nebo proběhlo období podávání žádostí. Kromě aplikace Individuální podávání žádostí o koleje a jejich opravy, kde výběr relevantních období následuje až po výběru studenta, je výběr období prvním krokem po volbě fakulty. Pokud je relevantní fakulta, nebo období právě jedno, přeskakuje aplikace tento výběr a ihned zobrazí další krok. Studentské aplikace jsou v systému dvě. Přístup k nim mají všichni nevyřazení prezenční studenti MZLU v Brně. I když má student na univerzitě více vyhovujících studií, v Kolejní administrativě figuruje pouze jednou a to pro všechny fakulty, na kterých má svá neukončená studia.

6.1


32

Podání žádosti o koleje Podat žádost o koleje má právo aktivní student prezenčního studia. Přídavek aktivní znamená nejen nepřerušené, ale také nevyřazené studium. Pokud má student studium přerušeno, ale v období, na které se žádost o koleje podává, bude přerušení ukončeno, je vyzván ke kontaktování členů kolejní rady příslušné fakulty, kteří jsou po posouzení schopni mu žádost o koleje zadat. Podávání na jednotlivá období je řízeno atributy univerzitního období, které stanovuje systémový integrátor univerzity. Ten nastaví, ve kterém termínu bude podávání žádostí studentům zpřístupněno. Aplikace se studentům v nabídce zobrazuje neustále, formulář k podání žádosti se zobrazí pouze, pokud se nachází v termínu podávání žádosti. V jiných případech se zobrazí upozornění, kdy je či bylo možné žádost podat. Vybírají se vždy následující období, než současné. Žádost je podávána vždy na následující rok. Formulář pro zadání obsahuje seznam pro výběr preferovaných kolejí a zaškrtávací pole pro preferenci pokoje s internetovou přípojkou a uvedení zvláštních důvodů pro udělení kolejí. Potvrzením druhého políčka student udává, že důvody doloží na studijním oddělení fakulty. Zjištění stavu žádosti o koleje Tato aplikace umožňuje studentovi soustavnou kontrolu nad stavem jeho žádosti. Zobrazují se v ní stavy žádostí na období, pro které již proběhlo podávání žádostí, ale tato období ještě neskončila, tedy buď trvají, nebo ještě nezačala. Vychází se z předpokladu, že univerzitní období na sebe nepřetržitě navazují. Žádost prochází následujícími stavy: • Žádost o udělení kolejí na následující akademický rok byla podána – Student nebo referentka podali studentovi na určité univerzitní období žádost o koleje. Tímto je žádost zadána do databáze a student začíná figurovat v Kolejní administrativě jako žadatel. Nadále budou s jeho žádostí moci pracovat kolejní rady a referentky fakult, na kterých bude mít student neukončené studium. • Koleje na následující rok byly uděleny – Některá fakulta, kterou student studuje, mu vyhověla v jeho žádosti a udělila mu tak koleje. Je evidováno, která fakulta koleje studentovi udělila. Tento stav je pouze dočasný a brzy je změněn na: • Koleje byly uděleny a dekret byl vytištěn studijní referentkou – Dekret byl vytištěn v hromadném tisku dekretů a byl předán děkanovi fakulty k podpisu. • Koleje byly uděleny, dekret vytištěn a odeslán na adresu trvalého bydliště studenta – Po podpisu dekretu děkanem fakulty byl spolu s ostatními uložen do obálek a odeslán na adresu trvalého bydliště studenta. Pro většinu studentů v tomto bodě končí jejich aktivní účast v Kolejní administrativě. Jeho osobou se již kolejní rada pro následující akademický rok nebude zabývat, kromě zvláštních případů, kdy je nutné studentovi vytisknout duplikát dekretu, student vrátí dekret či je vyřazen z Kolejní administrativy.

6.1


33

• Dekret byl vytištěn a osobně předán studentovi – Pokud byl dekret vytištěn pomocí aplikace pro individuální manipulaci s žádostí o koleje, je žádosti nastaven tento stav. Rozdíl mezi hromadným tiskem a touto variantou je fakt, že v tomto případě není dekret zařazen do sestavy pro podatelnu – není hromadně odesílán. • Duplikát dekretu byl vytištěn a osobně předán studentovi – Ve výjimečných případech je studentovi vystaven duplikát ubytovacího dekretu, který má s původním dekretem stejné číslo a liší se pouze poznámkou duplikát za svým názvem. • Žádost o koleje byla zamítnuta – Kolejní rada již projednala studentovu žádost, ale nerozhodla v ní kladně. Možnost, že budou studentovi koleje uděleny, trvá. • Zamítnutí žádosti o koleje bylo vytištěno – Zamítnutí žádosti o koleje bylo uznáno za definitivní a student bude obeznámen o zamítnutí své žádosti. Proti oznámení o zamítnutí se student může ve stanovené lhůtě odvolat. • Zamítnutí žádosti o koleje bylo vytištěno a odesláno na adresu trvalého bydliště studenta – Podobně jako u hromadného odesílání ubytovacích dekretů je vystavena sestava pro podatelnu a dopis je odeslán. • Žádost pozbyla platnosti, student byl vyřazen ze studia – Student byl z Kolejní administrativy vyřazen z důvodu ukončení studia, nebo jeho plánovaného ukončení státní zkouškou. Vyřadit studenta z Kolejní administrativy může referentka v případě, že na její fakultě student studuje své jediné studium. • Dekret byl studentem vrácen a stornován – Pokud student obdrží ubytovací dekret a rozhodne se jej neuplatnit a vrátí jej, je žádost nastavena do tohoto stavu a místo může být přerozděleno. Vrácením dekretu student vyjadřuje konec svého zájmu o koleje. Kromě stavu žádosti se student dozví preferované koleje a vzdálenost od místa trvalého bydliště, případně koeficient pro udělení kolejí. Pod tabulkou vypisující žádosti se z důvodu předcházení komplikací zobrazuje studentova adresa trvalého bydliště a doplňující informace týkající se udělování. Individuální podávání žádostí o koleje a jejich opravy Jedná se o první a zároveň nejrozsáhlejší z řady „referentskýchÿ aplikací Kolejní administrativy. Umožňuje provádět jednotlivé operace se studentovou žádostí od jejího podání přes udělení, zamítnutí, vytištění dekretu či jeho duplikátu až po zrušení žádosti o koleje či zrušení studentova dekretu.1 Podle aktuálního stavu žádosti nabízí aplikace příslušné formulářové prvky k práci se žádostí. Jelikož se jedná o individuální manipulaci s žádostí studenta, je prvním krokem výběr studenta. Výběr není prováděn jinak než v UISu standardním výběrem osob, a to pouze z prezenčních nevyřazených studentů fakulty. Pro případy, kdy má student přerušené studium a má zájem si podat žádost na následující akademický rok, kdy již bude mít aktivní studium, umožňuje aplikace založit a pracovat s žádostí studenta prezenčního studia, který má neaktivní, tzn. přerušené, studium. 1

Podrobný rozpis stavů žádostí se nachází v předchozí části „Studentské aplikaceÿ tohoto textu.

6.1


34

Vytištění dekretu či jeho duplikátu se děje pro osobní předání, dopis tudíž není zařazen do sestavy pro podatelnu. Číslování dekretu ovšem zapadá do celkového fakultního číslování (viz dále). Hromadné udělování kolejí Koleje je možno udělovat podle stupňů studia. Tento postup je využit zejména u studentů nastupujících do prvních ročníků bakalářského stupně a studentů doktorských studijních programů. Ostatní studenti jsou zařazeni do jedné skupiny. Kolejní rada Zahradnické fakulty má pro výběr studentů ještě kritérium, zda žádali o koleje v Lednici či v Brně. Ve výběru jsou studenti seřazeni podle kritéria pro udělení a je možné jim hromadně udělit koleje. Tato aplikace je určena zejména pro souhrnné udělování kolejí, není koncipována na dohledávání studentů. Možnost udělovat koleje je podmíněna stanovením kvót kolejí. Nastavené kvóty jsou zobrazovány v informační tabulce. Po výběru fakulty, období a skupiny studentů jsou žadatelé o koleje vypsáni po padesáti na stránku. Samotné udělení se provede označením zaškrtávacího pole u studenta, které se objeví pouze v případě, kdy student ještě nemá uděleny pro dané období žádné koleje. Pokud má, zobrazí se místo pole zkratka fakulty, která mu koleje již udělila. Studentovi jsou dále ze seznamu vybrány koleje. Přednastaveny jsou v seznamu ty koleje, které student preferoval ve své žádosti. Uložení údajů potvrdí uživatel stiskem tlačítka ve spodní části stránky. Po odeslání údajů se udělí koleje vybraným studentům a to pouze v případě, že ještě nemají uděleny koleje a počet žadatelů, kterým již fakulta vybrané koleje udělila pro zvolený akademický rok, nepřesahuje kvótu kolejí. O zdárném průběhu či překročení kvóty je uživatel informován. Jakmile jsou aplikací pro celou fakultu uděleny koleje alespoň jednomu studentovi, je ostatním žadatelům se stavem Žádost o koleje byla podána nastaven stav na Žádost o koleje byla zamítnuta. Tato operace vychází z předpokladu, že jakmile někdo poprvé použije aplikaci na hromadné udělování kolejí, bude v zápětí chtít studentům, kterým koleje neudělil zaslat rozhodnutí o zamítnutí žádosti, aby se k němu mohl student odvolat a v příštím kole mohlo být jeho žádosti vyhověno. Stanovení kvót jednotlivých kolejí Na fakultách jsou pro určitý akademický rok koleje rozdělovány z počtů míst na kolejích pro jednotlivé fakulty, které stanoví komise pro řízení ubytování. Tyto počty nazýváme kvótou příslušných kolejí. Z důvodu přerozdělování rezerv na kolejích v průběhu ubytování je možnost kvótu nastavit a také měnit v průběhu celého roku. Význam kvóty spočívá v kontrole počtu udělených míst. Při každém udělení kolejí se kontroluje, zda by další udělení kolejí nepřekročilo kvótu fakulty pro tyto koleje. Kontrola je prováděna buď při individuální manipulaci s žádostí či při každém jednotlivém udělení při hromadném udělování kolejí.

6.1


35

Nastavení a změnu kvóty může provést uživatel s právem koleje-e zadáním, nebo přepsáním čísla kvóty v tabulce kvót. Údaje je nutné uložit stiskem tlačítka Uložit pod tabulkou. Tisk seznamů Seznamy studentů, žadatelů o koleje, mohou být použity k různým účelům. Z jejich použití vychází skupina studentů a údaje, které se na nich mají objevit. Uživatel zvolí skupinu studentů podle: • stavu jejich žádosti (podaných, udělených, vystavěných dekretů a zamítnutých), • stupně studia, • kolejí, které žádali, nebo jim byly uděleny. Údaje, které se na seznamu zobrazí jsou dány stavem žádosti. Všechny seznamy obsahují jméno, adresu trvalého bydliště a ročník studia žadatele. Kilometrická vzdálenost a minutáž jsou uvedeny pouze na seznamech podaných žádostí. Na všech seznamech naopak figurují koleje a požadavek internetu. V sestavě udělených kolejí a vystavěných dekretů se jedná o udělené koleje, na ostatních o preferované. S preferovanými kolejemi se tiskne i informace o doložení zvláštních důvodů pro udělení kolejí. Posledním parametrem sestavení seznamu je formát výstupu. Volba HTML zobrazí seznam v přehledné tabulce na obrazovku, tisk generuje výstup na tiskárnu či do souboru. Tisky v Kolejní administrativě se podřizují nastavení tiskového subsystému UIS. Tisk zamítacích dopisů a dekretů Student je informován o udělení či zamítnutí kolejí výpisem stavu žádosti v aplikaci Zjištění stavu žádosti a také obdržením jednoho z dopisů generovaných Kolejní administrativou. Jedná se o ubytovací dekret a rozhodnutí o zamítnutí žádosti o koleje. Ubytovací dekret je tiskopis opravňující studenta k ubytování. Dekretem vyhovuje děkan fakulty studentově žádosti o koleje. Na základě jeho obdržení se student osobně dostaví do ubytovací kanceláře dekretem určených kolejí, kde se ve spolupráci se členy kolejní rady ubytuje. Termín ubytování stanovuje vyhláška pro řízení ubytování ve vysokoškolských kolejích, kterou schvaluje na své každoroční schůzi stejnojmenná komise. Na dekretu je vyznačeno období, na které je student ubytován. Podle rozhodnutí Komise pro řízení ubytování ve vysokoškolských kolejích musí být dekrety číslovány. Číslo dekretu je řetězec alfanumerických znaků, jehož první znak je písmeno identifikující fakultu, která dekret vydala (A, L, P, Z). Následuje pořadové číslo vydání dekretu. Pokud je studentovi již jednou dekret vytištěn a je mu tak přiřazeno číslo zůstává mu pro to období již toto číslo a při tisku duplikátu dekretu nebo opětovném tisku dekretu po zrušení je použito již jednou udělené číslo.

6.1

36


Rozhodnutí o zamítnutí žádosti o koleje je úředním dopisem, kterým děkan fakulty informuje studenta – žadatele o koleje, že jeho žádosti nevyhověl a umožňuje mu tak se proti svému rozhodnutí odvolat. Oba dopisy jsou tištěny hromadně. Z databáze jsou vybráni všichni žadatelé studující na příslušné fakultě podle druhu dopisu. Pro ně je po padesáti vygenerován dopis. Tvorba probíhá on-line sazbou prostřednictvím tiskového subsystému UIS. Tiskový výstup je použit ten, který má uživatel předdefinovaný. Z důvodu nutnosti skládat dekret do obálky s průsvitkou a celkovému rozvržení je doporučeno tisknout dopisy do formátu PostScript (PS). Rozfázované generování dopisů po padesáti kusech je navrženo kvůli velké zátěži serveru a velkým výstupním souborům. Ty nebyl webový server schopen předat uživateli. žádost o koleje

ano

ano

hromadné udělení

hromadně vytištěný dekret

hromadné odeslání dekretů

udělení kolejí

zamítnutí žádosti

ne odeslání zamítnutí individuálně předaný dekret

ano sestava zamítacích dopisů pro podatelnu

ano

ne

ano sestava odesílaných dekretů

ne

ne

žádost zamítnuta a ohlášeno žádost zamítnuta bez ohlášení

ne

ztráta dekretu

ano

duplikát dekretu

zrušení dekretu ne

storno dekretu

ano

konec zájmu o koleje

ne ubytovaný student

Obr. 2: Vývojový diagram cesty žádosti o koleje.

6.2

Žádosti o koleje studentů nastupujících do studia

37

Tisk sestav pro podatelnu je posledním z úkonů, které je potřeba v Kolejní administrativě provést před odesláním dekretů či zamítacích dopisů. Tyto sestavy korespondují s formulářem České pošty pro hromadné odeslání doporučených dopisů. Do sestav je nutné doplnit pouze pořadové číslo každé zásilky, datum odeslání a číslo přílohy přijímací knihy.

6.2

Žádosti o koleje studentů nastupujících do studia

Student, který nastupuje do studia na univerzitě a neměl na ní předchozí studium, je z pohledu podávání žádostí o koleje specifickým subjektem. Žádost o koleje odevzdá formou vyplněného tiskopisu studijní referentce při zápisu do studia. V tento okamžik nemá v UIS účet a je zde stále veden jako uchazeč o studium. Druhá zvláštnost spočívá v mírnějším kritériu pro udělení kolejí, které studenti nastupující zejména do bakalářských studijních programů mají. Uchazečovu žádost o koleje, kterou odevzdal při zápise, je nutné přenést do UIS. K tomuto účelu slouží aplikace přijímacího řízení Zadávání docházky. Zde zaeviduje referentka mimo jiné studentův zájem o koleje. Tohoto příznaku je dále využito při převodu uchazeče do studia. Mezi zhruba jedenácti úkony, které je při převodu nutné provést je i založení žádosti o koleje. Žádost je založena pouze na základě předchozí evidence ze zadávání docházky.2 V momentě založení žádosti má již uživatel účet v informačním systému a aktivní studium. Nejdříve se zjišťuje, zda nemá student žádost již podánu z některého jiného studia. Pokud ano, nová žádost se nezakládá. V řízení rozdělování kolejí je potřeba mít informaci, zda student nastoupil do studia a do jakého. Samotné založení žádosti by tudíž nestačilo. K žádosti studenta nastupujícího do studia je přidán atribut studium prvak. Tento atribut obsahuje identifikátor studia, do kterého student nastoupil v období, na které je podána žádost o koleje. Zmírněné kritérium nemusí mít všichni studenti. V praxi jsou zvýhodňování pouze studenti nastupující do bakalářských studijních programů. Proto je evidován další atribut nastupuje na stupen. Ten uchovává informaci o stupni studia z atributu studium prvak.

6.3

Zjišťování dojezdové vzdálenosti

Koleje jsou rozdělovány podle kritérií, která určí děkan příslušné fakulty. Kritérií může být víc, jejich zohlednění je určeno absolutním koeficientem vzorce, který může být stanoven. Hlavní váhu má ovšem vzdálenost od místa trvalého bydliště studenta do místa studia v kilometrech. Z důvodu nutnosti centrálního stanovení vzdálenosti byl stanoven výpočet vzdálenosti z údajů vrácených serverem pro vyhledávání spojení z jízdních řádů idos.datis.cdrail.cz (dále IDOS). Vzdálenosti jsou vypočítávány pro všechny obce, které jsou obsaženy v databázi UIS. K výpočtu je vytvořena aplikace Výpočet dojezdové vzdálenosti. Z důvodu 2

Více o problematice přijímacího řízení (Majer, 2004).

6.3


38

značného počtu zjišťovaných údajů a hrozby pádu http spojení ze strany prohlížeče (příznak timeout) je výpočet rozdělen na skupiny sídel podle počátečního písmena názvu obce. Algoritmus zjišťování Údaje pro zjištění spojení předané serveru jsou následující: • zdrojová obec (místo trvalého bydliště studenta), • cílová obec (místo studia, tedy Brno nebo Lednice), • datum, • čas, • příznak, že se jedná o vyhledání podle data a času příjezdu, • kontrolní sekvence, • další údaje nutné pro vyhledání spojení. Parametr kontrolní sekvence nemá význam parametru spojení, ale je nutný pro navrácení požadavku ze serveru. IDOS obsahuje mechanismus obrany před vyhledávacími roboty stahujícími informace o spojích. Jednotlivé skripty si mezi sebou předávají skrytý parametr link, řetězec čtyř alfanumerických znaků. Ten je každý den měněn za nový. K získání informací ze serveru je tedy nutné předat i tento skrytý parametr, což prohlížeče při odeslání dělají. Robot provádí přímo stažení stránky bez předchozího vyplnění formuláře, který link obsahuje. Pro obejití této ochrany je vždy před odesláním první obce ze skupiny stažena prázdná stránka http://idos.datis.cdrail.cz/ConnForm.asp. Její html kód obsahuje hodnotu parametru link, která je potom použita při výpočtu dalších vzdáleností. Zjišťování vzdálenosti a minutáže probíhá pomocí LWP::UserAgent. Parametry jsou předány serveru a je přijata odpověď. Odpověď samotná obsahuje pouze informaci o přesměrování. URL, pod kterou je možné nalézt přesměrovanou odpověď, obsahuje parametr záhlaví Location. Z něj je metodou LWP::UserAgent::header získáno URL a to staženo. Stažený html kód již obsahuje informace o nalezených spojích. Pomocí regulárních výrazů jsou z kódu zjištěny hodnoty délky trasy a doby jízdy včetně přestupů. Aritmetický průměr těchto hodnot je výsledkem zjišťování. Ne pro všechny obce ovšem vrátí funkce zajišťující zjišťování hodnoty dojezdnosti. Podle vráceného kódu rozlišuje aplikace 4 stavy: • dojezdnost byla zjištěna – zjištěné hodnoty jsou uloženy do databáze. • nabídka výběru ze seznamu objektů – danému názvu zdrojové obce odpovídá více obcí v databázi IDOS. Zpravidla se jedná o víc obcí stejného názvu, ovšem z jiného okresu. Okres je zapsán jako kód za názvem obce v hranatých závorkách.3 Pokud název zdrojové obce rozšířený o starý kód okresu získaný z databáze UIS odpovídá některé obci v seznamu, provede se nové vyhledání. Jako název zdrojové obce bude použito jméno a okres. Nevyhovuje-li přímo některá položka 3

Pro obec Lhota z okresu Brno okolí by název z rozšířením vypadal následovně: Lhota [BO].

6.3

39


seznamu, zobrazí se seznam uživateli k ručnímu výběru. Po výběru je IDOSu předán přímo kód obce, k záměně tudíž nemůže dojít. • server IDOS objekt nezná – objekt není v databázi IDOS. Dojezdnost může být v případě potřeby zjištěna doplňkovým dohledáním. • spojení v příslušném časovém období neexistuje – pro zadané podmínky příjezdu do Brna neexistuje vyhovující spoj. Dojezdnost může být dohledána pomocí doplňkového dohledání. Server IDOS pracuje nativně v kódování CP1250. Názvy obcí a vracených seznamů objektů je nutné překódovat pomocí balíku Cz::Cstocs. zjištění kontrolní sekvence

zdrojová obec

ne

výpočet dojezdnosti podle kódu IDOS

ano ne

ano

cílová obec

vybral uživatel obec

ano výpočet dojezdnosti podle názvu zdrojové obce

ne

zobrazení seznamu k ručnímu výběru ne

nalezeno

ano

dojezdnost uložena

ano

nalezeno

ne ne

zná IDOS obec

výpočet dojezdnosti podle kódu IDOS ano

ano porovnání zdrojové obce s obcí v seznamu IDOS

je obec v seznamu IDOS

ne

Obr. 3: Diagram výpočtu vzdálenosti pro skupiny obcí.

Pro obce, kterým nebyla dojezdnost stanovena z důvodu neznalosti objektu nebo neexistence spojení v příslušném čase, ale v těchto obcích mají žadatelé o koleje svá bydliště, se používá možnost Dopočet. Nejedná se o samotné dohledávání. U obcí, pro které nebyl výpočet stanoven standardně lze předpokládat, že ji IDOS prostě nezná. Dopočet je koncipován tak, že jsou pro místa trvalých bydlišť žadatelů o koleje, kterým nebyly nalezeny dříve a mají tak vzdálenost a minutáž o hodnotě NULL nabídnuty přímo políčka pro zadání vzdálenosti a minutáže. Toto určení je definitivní. Po určení jsou vzdálenosti uloženy jak do databáze vzdáleností, tak přímo do žádostí studentů. Dopočet je koncipován jako dodatečné určení vzdálenosti pro studenty, kteří bydlí v obcích, jejichž dojezdnost nebyla stanovena řádně. Z toho důvodu je nutné Dopočet provádět po každém podávání žádostí o koleje.

6.3


40

Studenti se státním občanstvím Slovenské republiky a trvalým bydlištěm na území své vlasti, pro které je také nutné zjistit vzdálenost, mají místo trvalého bydliště uloženo zpravidla ne jako kód obce, ale přímo řetězec názvu. Dojezdnost není počítána pro obce, nýbrž přímo pro jednotlivé žadatele o koleje. Dojezdnost je uložena přímo do žádostí. Dohledávání tudíž musí probíhat až po termínu podávání žádosti o koleje. Stanovení jejich dojezdnosti probíhá podobně jako doplňkové dohledání. Buď je vzdálenost zjištěna, nabídnut seznam odpovídajících objektů nebo přímo políčka na zapsání dojezdnosti. Práce s aplikací Aplikace mají význam pro každoroční zjištění vzdáleností všech obcí, které obsahuje databáze UIS. Tento úkon je dobré provádět z důvodů náročnosti procesu a nutnosti mít srovnatelné údaje právě před podáváním žádostí o koleje. Z údajů je následně vytvořena databáze vzdáleností. Při podání žádosti jsou hodnoty dojezdnosti uloženy podle místa trvalého bydliště žadatele přímo do žádosti o koleje. Obce v ČR jsou roztříděny podle počátečního písmene názvu. Pro vyhledání každé třídy je nutné zadat datum a čas příjezdu do místa studia ve tvaru, který je před nabídnut. Tento termín by měl být z důvodu srovnatelnosti u všech skupin stejný. Po zadání termínu se provede výpočet. U obcí, které nebyly nalezeny, nebo neexistuje v příslušném období žádné spojení je uživatel výpisem informován. Vrátí-li IDOS seznam pro upřesnění názvu obce, je ten zobrazen uživateli k volbě. Po výběru a odesláním tlačítkem Dokončit, jsou vrácené případy přepočítány dle výběru. Pokud uživatel nezvolí žádnou možnost, není dojezdnost určena a obec se tak ocitá ve skupině obcí dohledatelných doplňkově. Dopočet je využíván pro určení dojezdnosti obcí, pro které se nepodařilo ji stanovit v rámci obcí v ČR tříděných podle počátečního písmene názvu. Protože je dopočet prováděn pouze pro obce, ve kterých bydlí žadatelé o koleje, je prvním krokem specifikace, na které univerzitní období tito studenti o koleje žádají. Aplikace vrátí seznam obcí, pro které vzdálenost již dříve nenalezla. U každého spojení určeného názvem, PSČ, okresem a cílovou obcí jsou přímo políčka k zadaní kilometrů a minut. Po zadání a odeslání informací tlačítkem Dokončit jsou vzdálenosti uloženy do databáze vzdáleností a doplněny k žádostem o koleje. Slovenské dojezdnosti se vypočítávají až po skončení podávání žádostí. Dojezdnost není určena podle obce z databáze UIS, ale podle jména místa trvalého bydliště uloženého u žadatelovy adresy. Spolu s termínem příjezdu je nutné stanovit období, na které jsou tyto žádosti podány. Další postup je již totožný s doplňkovou formou hledání. Nabídka políček pro zadání je posledním stupněm zjištění údajů. Toto vyhledání musí uživatel provést ručně.

6.4

6.4

Předávání dat s ubytovacím systémem SKM

41

Předávání dat s ubytovacím systémem SKM

Jedním z cílů Kolejní administrativy vytyčených v předimplementační studii bylo zlepšit komunikaci ubytovacích kanceláří a kolejních rad. Kromě seznamů, které umožňuje generovat, je pro předání informací zřízena obousměrná synchronizace dat s ubytovacím systémem IS KaM na kolejích MZLU v Brně. Předávání dat je řízeno ze strany ubytovací kanceláře a vedení SKM. Pro tyto potřeby byl IS KaM rozšířen a pracovníci správy mohou tuto operaci spustit manuálně. Současná architektura ubytovacího systému neumožňuje automatizaci tohoto procesu. V databázi UIS jsou pro tyto potřeby zřízeny datové struktury ze kterých si SKM data stahuje, nebo do nich ukládá. Předání dat nutných k ubytování Proces ubytování je značně ztížen a zdržován nutností zadávat o studentovi do IS KaM veškeré údaje týkající se jeho osoby a studia. Jedním z efektivních způsobů eliminace zbytečných operací je před vyplnění studentových osobních informací. Pro ubytování jsou potřeba následující informace: • identifikační číslo studenta (zároveň identifikátor řádku pohledu tabulky), • jméno, příjmení a titul, • rodné číslo, datum narození, místo narození, pohlaví, • státní příslušnost, číslo občanského průkazu, • obec, ulice, poštovní směrovací číslo, • fakulta, ročník, typ studia, • číslo karty, číslo čipu, čárový kód, • udělené koleje. Data jsou z různých struktur UIS seřazena do pohledu USKM.STUDENTI, který si může IS KaM stáhnout a data využít. Do pohledu jsou zařazeni všichni studenti MZLU v Brně. Stahování dat se proto provádí zejména před začátkem hlavní vlny ubytování, tedy v září. Studenty, kterým byly uděleny koleje může systém vzít jako budoucí ubytované. Ostatní data jsou pro systém také cenná, protože student se může k ubytování přihlásit v průběhu školního roku. Zpracování dat o ubytování studentů Zpětnou vazbou o ubytovaných studentech, na kterou je možné navázat při dalším rozšiřování Kolejní administrativy zejména v oblastí rezervace pokojů a statistických zjišťování o pohybu studenta na kolejích, tvoří tabulka USKM.UBYTOVANI. Podobně jako může IS KaM získávat informace, předává po spuštění uživatelem data databázi UIS. Předávány jsou tyto údaje o ubytovaném: • rodné číslo ubytovaného – jediný údaj identifikující ubytovaného, • datum ubytování, • datum ukončení ubytování,

6.5

Datové schéma

42

• koleje, blok, pokoj – alfanumerické řetězce definující pokoj, kde je osoba ubytována. Ubytovací systém předává všechna data, která o ubytovaných shromažďuje. Předání probíhá tak, že systém přemaže tabulku uskm.ubytovani a naplní ji všemi daty, které o ubytovaných uchovává. V současnosti se jedná o cca 3000 záznamů. Pokud se student v průběhu roku přestěhuje, je uložen pouze jeden záznam s datem nástupu prvního ubytování, ale s pokojem posledního ubytování.

6.5

Datové schéma

V datovém schématu UIS jsou pro potřeby kolejí a menz vyčleněny tabulky s názvem začínajícím na M. Z dvaceti dvou tabulek schématu M% slouží potřebám Kolejní administrativy dvanáct. Ostatní tabulky jsou využity pro napojení stravovacího systému ANETE na databázi UIS. Tabulky jsou užity pro následující účely: • MC KOLEJE – číselník kolejí doplněný o atributovou a šablonovou tabuku, • MC KOLEJE ATRIBUTY a MC KOLEJE SABLONA – tabulky umožňující šablonovat nad číselníkem MC KOLEJE, • M KOLEJE KVOTY – struktura pro uložení kvót kolejí. Kvóty se evidují pro určitou fakultu v příslušném akademickém roce na příslušné koleje, • M KOLEJE ZADOSTI – zde jsou uloženy žádosti o koleje, které student podává pro jednotlivá univerzitní období. Evidují se koleje, které student žádá i na které bude ubytován, fakulta z jejíž kvóty mu byly koleje uděleny, vzdálenost a další, • M KOLEJE ZADOSTI ATRIBUTY a M KOLEJE ZADOSTI SABLONA – šablonovací schéma k žádosti o koleje, • MA DEKRETY CISLA – pomocná tabulka k databázové funkci generující čísla dekretů. Každé vygenerované číslo je zde uloženo, aby nemohlo dojít k duplikacím. Číslo je definováno fakultou, obdobím a pořadovým číslem. Každý rok proto číslování začíná od počátečního čísla jedna, • MC KOLEJE STAVY – číselník stavů, kterými žádost o koleje může procházet, • MC VZDALENOSTI – tabulka vzdáleností všech obcí v ČR, pro které byla vzdálenost vypočtena, • MC VZDALENOSTI VYPOCTY – evidence provedených výpočtů vzdáleností. Nutné pro stanovení aktuálnosti výpočtu před jeho novým provedením, • M USKM STUDENTI – „synchronizačníÿ pohled USKM.STUDENTI.

7

ZHODNOCENÍ PRÁCE

7

43

Zhodnocení práce

Kolejní administrativa má za sebou první rok provozu. Po tomto období je možné provést drobné ohlédnutí a zhodnocení jejího přínosu.

7.1

Změny oproti předimplementační studii

Předimplementační studie, vytvořená ihned po zadání práce, vznikla s více jak ročním předstihem než text této práce. Od dob návrhu se mnoho věcí ovlivňujících problematiku kolejí změnilo a implementace byla postupně upravována požadavkům uživatelů a změnám podmínek rozdělování kolejí. První ze zásadních změn, ke které došlo, byla neexistence úřední desky kolejní rady. V době studie autor pociťoval její nutnost a podobný sdělovací prostředek v UIS chyběl. Záhy byla tato mezera doplněna „Dokumentovým serveremÿ (Matuška, 2003). Dalším prostředkem informování studentů, který v té době zprovoznil vedoucí této práce je studentský informační portál založený na systému phpRS – koleje.mendelu.cz. Potřeba úřední desky kolejní rady tudíž zanikla. Myšlenka projevování zájmu o koleje v průběhu akademického roku se v počátcích zdála dobrá. Rozhodnutí Komise pro řízení ubytování ve vysokoškolských kolejích MZLU v Brně ovšem její opodstatnění degradovalo. Rozdělení volných kapacit na kolejích, od přerozdělení po ubytování, má podle tohoto rozhodnutí plně v rukou ubytovací kancelář příslušných kolejí. Student, který díky své aktivitě přijde na koleje ihned po uvolnění místa bude tudíž ubytován. K tomuto kroku byly koleje přinuceny zejména z důvodu nízké pružnosti obsazování. Ta je podle vedení kolejí způsobena menším přetlakem žadatelů o jedno lůžko, než je na ostatních brněnských univerzitách. Jedna ze změn vedla ovšem i k rozšíření funkčnosti Kolejní administrativy. Aplikace nazvaná ve studii „Podání žádosti za jinou osobuÿ, která měla sloužit pouze pro podání žádosti dohledané osobě, se ztělesnila v nejrozsáhlejší aplikaci „Individuální podávání žádosti o koleje a jejich opravyÿ. Ta od pouhého zadání žádosti umožňuje provést všechny operace až po tisk dekretu či jeho duplikátu.

7.2

Administrativní přínos práce

Jedním z cílů této práce bylo stát se „plnohodnotným pomocníkem členů kolejních rad a studijních referentek při udělování kolejíÿ. Z tohoto cíle přímo vyplývají požadavky na její implementci a zároveň její očekávaný přínos. Při porovnání klasické „papírovéÿ agendy, kterou musela kolejní rada absolvovat před nasazením Kolejní administrativy, s poloautomatizovaným udělování kolejí jsou příznivé dopady zřejmé. Činnost kterou doposud prováděla skupina lidí i několik dní se dnes neuvěřitelně zkrátila. V minulosti ztrávila, např. kolejní rada PEF, dva dny rozdělováním kolejí. Dnes trvá setkání, na kterém rada pouze podle hlavních

7.3

Ekonomický přínos práce

44

a doložených zvláštních kritérií rozhodne, komu koleje udělí, i s vygenerováním všech dopisů 3 hodiny. Po tomto úkonu je již možné vytisknout dekrety, zamítací dopisy a sestavy pro podatelnu a vygenerovat seznamy studentů. Po samotném rozeslání dopisů je všechna práce s udělováním kolejí u konce. Složité procedury s řazením studentů, ověřováním jejich studií a vzdáleností odpadly. Rovněž byly eliminovány složité postupy nutné k vypsání tiskopisů dekretů, zamítacích dopisů a sestavení seznamů. Při možných výjimkách a specifikách jednotlivých studentů a jejich žádostí mohou nastat různé komplikace. Možnost individuálního přístupu k žádosti ovšem tyto problémy všechny vyřeší. Neustálá evidence rozdělených dekretů a mezifakultní koordinace při udělování zprůhlednila tuto problematiku. V dřívějších dobách stačilo k ubytování získat potvrzený ubytovací dekret s vlastním jménem. Zpětné dohledání udělení bylo téměř nemožné. Snížená volnost kolejních rad a studijních referentek v této oblasti eliminovala možné machinace s ubytovacími kapacitami. Předáním dat ubytovacím kancelářím kolejí byl znatelně urychlen a zkrácen proces ubytování. Ubytovatelka nemusí již zadávat do systému všechny údaje o studentovi. K dispozici má i informaci o studentovi udělených kolejí, která je pro ni stěžejní.

7.3

Ekonomický přínos práce

Ekonomické přínosy práce vycházejí v plné míře z administrativních úspor. Veškerá urychlení způsobená zavedením Kolejní administrativy se mohou odrazit na snížení zátěže studijních oddělení, které může vést až k ušetřením pracovních sil. Ty by bylo možné nadále využít na jiných potřebnějších postech a v oblastech, které se dnes rozvíjejí. Automatizace procesů umožňuje snížení dohledu nad celou problematikou. V současnosti již není zapotřebí, aby oblast kolejí měla na starosti právě jedna studijní referentka, která musí evidovat a uchovávat o studentech a jejich bydlení veškeré informace. Vše je uchováváno a spravováno systémem, který zpracovává většinu studijně administrativních agend na MZLU v Brně. Přístup a práce s tímto systémem se pro většinu pracovníků a studentů univerzity stává samozřejmostí. Pro zaškolení nového pracovníka je nutné pouze pochopit systém rozdělování kolejí. Ten je, spolu s obsluhou aplikací, důkladně popsán v textu této práce.

7.4

Výhledy do budoucna

Jak již bylo řečeno v části o změnách oproti předimplementační studii, Kolejní administrativa prochází, stejně jako celý UIS, neustálým vývojem. Hnacím motorem jsou změny předpisů upravujících jednotlivé oblasti života univerzity a nové poža-

7.4


45

davky uživatelů. Základní funkci pro rozdělování kolejí na MZLU v Brně plní Kolejní administrativa dobře. V této oblasti také nelze očekávat velkých změn. Předubytování Budoucnost rozvoje této práce je zejména v možnostech většího záběru problematiky. Jednou z takových oblastí je předubytování studentů, tedy rezervace jejich pokojů. Stejně, jako si student podává žádost o koleje by mohl, pokud by mu byly koleje uděleny, zažádat o určitý pokoj. Rezervace pokojů v současnosti probíhá pouhým zápisem do seznamu u kolejní rady. Po letošních dobrých zkušenostech kolejní rady PEF z rozfázováním rezervace do dvou kol by bylo možné tento způsob využít i při implementaci předubytování do Kolejní administrativy UIS. Rozfázování vychází z předpokladu, že na pokoj, na kterém student již bydlí, má přednostní právo se předubytovat. Implementace by ovšem vedle evidence jednotlivých kolejí vyžadovala i evidenci pokojů a jejich lůžek. Zjednodušení ubytování Dalším velkým přínosem Kolejní administrativy UIS by v budoucnu byla úprava a zjednodušení ubytování. Všechny dokumenty a seznamy, které je nutné tisknout a zasílat studentům či ubytovacím kancelářím zbytečně zatěžují zainteresované strany jak po technické, tak po ekonomické stránce. Zářným příkladem jsou ubytovací dekrety a zamítací dopisy. Pro každého s žadatelů o koleje se musí minimálně jednou některý z těchto dopisů vystavit. Znamená to tisk dopisu, jeho podpis děkanem fakulty a doporučené odeslání. Při počtech žadatelů o koleje, které hravě přesáhnou tři tisíce, by jenom finanční úspory studijního oddělení dosahovaly desítek tisíců korun ročně. Oznámení o vyhovění žádosti o koleje vidí student v aplikacích kolejní administrativy. Dále by mohl pomocí univerzitní pošty obdržet informační e-mailovou zprávu. Rezervací pokoje by student potvrdil svůj zájem bydlet na kolejích. Pro SKM by se tento student již stal ubytovaným a do svého systému by převzala veškerá data a mohla provést s předstihem jeho ubytování. Student by se potom dostavil pouze na vrátnici bloku, kde bude bydlet. Zde by převzal klíč od pokoje a byl zapsán do seznamu. V průběhu následujícího týdne by se dostavil k podpisu ubytovací smlouvy. Tato úprava ovšem naráží kromě kvalifikovanosti vrátných na právní zvyklosti a nutnosti, které musí ubytování jakožto právní akt provázet. SKM se brání tomu, aby student byl na koleje vpuštěn před podpisem ubytovací smlouvy. Další překážkou je kromě nechuti kompletní reorganizace ubytování současný ubytovací systém, jehož přizpůsobení novinkám je podle ubytovací kanceláře nemožné.

7.4


46

Modernizace ubytovacího systému na kolejích MZLU v Brně Ubytovací systém IS KaM používaný na SKM MZLU v Brně je již svou architekturou značně zastaralý. Vzhledem k tomu, že jsou na MZLU v Brně využívány pouze funkcionality týkající se ubytovávání studentů, je vyhovující. Zároveň ovšem konzervuje současný způsob ubytování, který se jeví neekonomickým. Modernizaci by si proto zasloužily v zájemné součinnosti jak systém IS KaM, tak celý postup ubytování. Na tomto místě je třeba podotknout, že ze strany SKM není chuť v tomto směru cokoliv měnit. Jednou z možností je integrovat systém Koleje 2002. Tento systém je ovšem natolik komplexní, že k jeho plnohodnotnému využití by bylo potřeba přizpůsobit kompletně způsob rozdělování kolejí a ubytování studentů na MZLU v Brně. Specifika skladby žadatelů o koleje jednotlivých fakult reorganizaci tímto způsobem neumožňují. Jako druhá možnost se jeví vývoj nového systému podle požadavků SKM. Při této variantě by bylo vhodné zmodernizovat po dohodě s SKM postupy ubytování. Vznikly by tak nové požadavky a podmínky pro implementaci. Následovalo by důležitým rozhodnutí, zda vytvořit nový systém vlastními silami, nebo jeho vývoj zadat externímu dodavateli. Outsorcing tohoto řešení by si vyžádal podrobnější analýzu. Možnost vyvinout ubytovací systém vlastními prostředky, respektive vytvořit jej jako součást UIS je reálnější. Jednalo by se o agendu, která by návázala na Kolejní administrativu „směrem ke kolejím.ÿ Systém pro rozdělení kolejních kapacit je v současné době hotov. Bylo by dále nutné analyzovat a následně implementovat zejména tyto oblasti: • rezervace pokojů – tzv. předubytování, z něhož by vycházelo rozmístění studentů na pokoje při ubytování, • evidence kolejí, bloků, pokojů a lůžek – aplikace pro evidenci a správu včetně speciálního vybavení, od kterého by se odvíjel nájem, • evidence dalších zařízení – zařízení, která nejsou součástí pokoje, ale student si je může krátkodobě či dlouhodobě pronajmout, • evidence externích ubytovaných – nutné zejména pro krátkodobé ubytování osob, které nejsou z MZLU v Brně, v rámci hospodářské činnosti kolejí, • systém plateb za nájemné – s výhodou by se mohlo využít clearingového účtu, na který by student odváděl pravidelné platby, • clearingová pokladna – externí ubytovaní platí zpravidla v hotovosti, nebo fakturací, • osobní účet ubytovaného – revize veškerých plateb s kolejemi spojených, • návaznost na účetní systém kolejí – účetní systém SKM by z ubytovacího přebíral informace o peněžních tocích na kolejích, • napojení na přístupový systém – důvodem je možnost identifikace studenta při ubytování pomocí ISIC karty.

8

8

ZÁVĚR

47

Závěr

Prvním cílem této práce, který bylo nutné splnit při její tvorbě, byla důkladná analýza prostředí kterého se práce týká – rozdělování kolejí. Tato oblast není autorovi neznámou. Jakožto člen kolejní rady Provozně ekonomické fakulty ji zná podrobně. Důležitou částí tvorby této práce bylo rovněž seznámení se s řešením příbuzné problematiky v oblasti IS/ICT. Informace získané tímto rozborem se staly nezbytnými jak při odhalování možných úskalí návrhu a vývoje, tak pomohly zrychlení celého postupu a zamezily tak vývoji špatným směrem. Metody implementace subsystémů v prostředí Univerzitního informačního systému MZLU v Brně byly ovšem pro autora novinkou. Seznámení se s touto problematikou zabralo větší úsilí. Z porozumění chování a možností webových informačních systémů následně vycházely úpravy původních rozborů, analýz a návrhů. Cyklus tvorby informačního systému proběhl u tohoto subsystému více než jedenkrát. Na konci poslední iterace lze prohlásit, že subsystém je plně funkční a splňuje na něj kladené požadavky. Faktickými výsledky této práce je, kromě tohoto textu, soubor aplikací, sloužících zde popsaným způsobem k rozdělování kolejí. V současné době jsou pro uvedené účely aplikace plně funkční a jejich další vývoj neprobíhá. Rozšíření funkcionalit subsystému je však možné. Budoucnost výsledků této práce ovšem závisí na chystané reformě dotací na ubytování, kterou v současné době předkládá Ministerstvu školství Studentská komora Rady vysokých škol České republiky. Reforma by měla přinést nový systém dotování vysokoškolského ubytování. Zatím ovšem není jasné, jak se dopady těchto a souvisejících změn projeví na samotném rozdělování kolejí. Osobním přínosem z tvorby této práce pro mě bylo obeznámení se s integrací informačního systému a vývojem jeho nových částí. Pochopení teorie webových informačních systémů, která má podle mého mínění před sebou velkou budoucnost, je pro mne neméně důležité. Osvojil jsem si zejména schopnosti analýzy a systematického pohledu na problematiku. Bylo mi velkou ctí, že jsem se po dobu implementace Kolejní administrativy stal členem Vývojového týmu UIS.

9

9

LITERATURA

48

Literatura

ApS Brno, divize projekční techniky Popis systémů. Dokument MS Word. Brno: ApS s. r. o., 2003. AZSoft – Rezervační systém. Webové stránky projektu. http://www.jansustr.cz [cit. 8. 5. 2004]. CPAN – Comprehensive Perl Archive Network. Webové stránky archivu. http://www.cpan.org [cit. 27. 4. 2004]. Dařena, F. Jádro Univerzitního informačního systému. Diplomová práce. Brno: MZLU, 2002. Chaps spol. s r. o.. Webové stránky provozovatele elektronických jízdních řádů. http://www.chaps.cz [cit. 8. 5. 2004]. Klimek, D. a kol. Informační systém pro podporu správy kolejí. Projekt do předmětu Informační systémy I. Praha: MFF CUNI, 2000. Webová prezentace projektu. http://www.jboss.cz/david.klimek/isi/ [cit. 8. 5. 2004]. Jun, R. a kol. HOTELIS – Informační systém hotelů. Projekt do předmětu Softwarové inženýrství. Praha: FEL ČVUT, 2004. Webová stránka projektu. http://hotelis.unas.cz/index.php [cit. 8. 5. 2004]. Koleje a menzy VUT v Brně. Webové stránky správy kolejí VUT v Brně. http://www.skm.vutbr.cz/ [cit. 8. 5. 2004]. Kolejní řád vysokoškolských kolejí Mendelovy zemědělské a lesnické univerzity v Brně. Brno: MZLU, 1997. Kutín, A. Využití obecné kvalifikace v jádře IS. Diplomová práce. Brno: MZLU, 2004. Lacko, L. Oracle: Správa, programování a použití databázového systému. Brno: Computer Press, 2003. ISBN 80-7226-699-3. Majer, T. Problematika přijímacího řízení v integrovaných informačních systémech. Diplomová práce. Brno: MZLU, 2004. Matuška, F. Dokumentový server. Bakalářská práce. Brno: MZLU, 2003. OPENHotel – Hotelový informační systém. Webové stránky projektu. http://www.gubi.cz/pages/his.html [cit. 8. 5. 2004]. Procházka, T. Studijní systém v Univerzitním informačním systému. Diplomová práce. Brno: MZLU, 2003. Přichystal, J. Tisk z UISu. Lednice 2002, Brno: MZLU, 2002. Rábová, I. Informační systémy / Informační technologie. Brno: Konvoj, 2003. ISBN 80-7302-060-2. Informační systém Masarykovy univerzity. http://is.muni.cz [cit. 23. 4. 2004]. Informační systém Vysokého učení technického v Brně. http://pony.ro.vutbr.cz [cit. 14. 4. 2003]. Rybička, J. LATEXpro začátečníky. Brno: Konvoj, 2003. ISBN 80-7302-049-1. Správa kolejí a menz Masarykovy univerzity Brno. Webové stránky správy kolejí MU. http://skm.muni.cz/ [cit. 8. 5. 2004]. Satrapa, P. Perl pro zelenáče. Praha: Neocortex, 2001. ISBN 80-86330-02-8.

9

LITERATURA

49

Moje ubytování. Informační systém osobního přístupu k informacím o ubytování na SKM MU. https://ycollege.skm.muni.cz/ [cit. 8. 5. 2004]. Správa účelových zařízení ČVUT v Praze. Webové stránky správy kolejí ČVUT v Praze. http://www.suz.cvut.cz/ [cit. 8. 5. 2004]. Šimůnek, M. SQL: Kompletní kapesní průvodce. Praha: Grada Publishing, 1999. ISBN 80-7169-692-7. Šorm, M. a kol. Fakultní informační systém. Příspěvek na konferenci Informatika. Brno: MZLU, 2000. Šorm, M. Univerzitní informační systém. Diplomová práce. Brno: MZLU, 2002. Vyhláška o ubytování ve vysokoškolských kolejích MZLU v Brně pro akademický rok 2003/2004. Brno: MZLU, 2003. Šorm, M. Webové informační systémy. Příspěvek na konferenci MendelNet. Brno: MZLU, 2003. Wall, L. Programovací jazyk Perl. Brno: Computer Press, 1997. ISBN 80-8589695-8. Y Soft, s. r. o. Webová prezentace tvůrce systému yCollege. http://www.ysoft.cz [cit. 8. 5. 2004].

Přílohy

A

A

ENTITNĚ-RELAČNÍ DIAGRAM

51

Entitně-relační diagram

Entitně-relační diagram graficky znázorňuje datové struktury systému prostřednictvím jednotlivých entit a relačních vazeb.

Obr. 4: Entitně-relační diagram datové struktury Kolejní administrativy UIS

Kolejní administrativa UIS

Recommend Documents