Studijní systém v Univerzitním informačním systému

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

Studijní systém v Univerzitním informačním systému Diplomová práce

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

Bc. Tomáš Procházka

Brno 2003

Prohlašuji, že jsem tuto diplomovou práci tvořil zcela samostatně s využitím literatury, která je uvedena v seznamu. Na samotné tvorbě aplikací se podílelo dalších dvacet kolegů z vývojového týmu UIS.

V Brně dne 15. dubna 2003

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

Na tomto místě bych chtěl poděkovat svému vedoucímu Mgr. Ing. Milanu Šormovi za jeho cenné rady, připomínky a nápady. Dále chci poděkovat kolegům ve vývojovém týmu, bez jejichž práce by Univerzitní informační systém nemohl vyniknout v současné podobě a rozsahu.

Abstract Procházka, T., BSc. The Study System in the University Information System. Diploma thesis. Brno, 2003 This thesis covers an area of the study system in the University information system (UIS) of the Mendel University of Agriculture and Forestry in Brno. The overall architecture and the environment of the University information system are introduced. The main emphasis is laid on the study system in UIS. The basic terms concerning the study environment are explained. The principles and concepts creating the basis of the study system are described. And the individual applications used by students, teachers and the officers of Study department are presented. Information about the data forwarded to government institutions is also covered.

Abstrakt Procházka, T., Bc. Studijní systém v Univerzitním informačním systému. Diplomová práce. Brno, 2003 Práce dokumentuje studijní systém Univerzitního informačního systému (UIS) Mendelovy zemědělské a lesnické univerzity v Brně. Obsahuje informace o celkové architektuře a prostředí Univerzitního informačního systému, ale hlavní důraz je kladen na studijní systém v UIS. Vysvětleny jsou základní pojmy spojené se studijním prostředím, popsány principy a koncepty, na kterých je studijní systém založen, a jednotlivé aplikace sloužící studentům, učitelům a studijním referentkám. Obsaženy jsou rovněž informace o údajích předávaných státním institucím.

4

Obsah 1 Úvod a cíl práce 1.1 Úvod do problematiky . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Cíl práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Definice pojmů 3 Architektura informačního 3.1 Globální architektura . . 3.2 Dílčí architektury . . . . 3.3 Horizontální struktura . 3.4 Vrstvená architektura . .

8 8 9 10

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

14 14 16 17 17

4 Životní cyklus informačního systému 4.1 Úvodní studie . . . . . . . . . . . . . 4.2 Analýza . . . . . . . . . . . . . . . . 4.3 Globální návrh . . . . . . . . . . . . 4.4 Detailní návrh . . . . . . . . . . . . . 4.5 Implementace . . . . . . . . . . . . . 4.6 Zavádění systému do provozu . . . . 4.7 Provoz a správa . . . . . . . . . . . . 4.8 Ukončení provozu . . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

20 20 20 20 21 21 22 22 23

5 Modely životního cyklu 5.1 Model vodopád . . . . . 5.2 Iterativní model . . . . . 5.3 Model výzkumník . . . . 5.4 Prototypování . . . . . . 5.5 Model použitý při tvorbě

systému . . . . . . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

24 24 24 25 25 26

6 Způsoby pořízení informačního systému 6.1 Vývoj systému vlastními silami . . . . . . . 6.2 Vývoj systému externí firmou . . . . . . . . 6.3 Nákup typového informačního systému . . . 6.4 Nákup parametrizovaného systému . . . . . 6.5 Outsourcing informačního systému . . . . . 6.6 Pořízení Univerzitního informačního systému

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

28 28 28 28 29 29 29

. . . . . . . . . . . . UIS

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

5

OBSAH

7 Trendy v informačních technologiích 7.1 Trendy v oblasti základního software . . . . . . . 7.2 Trendy v oblasti aplikačního software . . . . . . . 7.3 Trendy v oblasti informačních technologií . . . . . 7.4 Trendy v metodice a vývoji informačních systémů

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

31 31 32 33 34

8 Analýza současného stavu UIS 8.1 Vrstvená architektura . . . . . . . 8.2 Popis technického řešení . . . . . 8.3 Použitý software . . . . . . . . . 8.4 Datová architektura . . . . . . . . 8.5 Jádro informačního systému . . . 8.6 Potřeby a návrhy dalšího rozvoje

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

36 36 38 40 43 46 50

. . . . . . . . .

53 53 55 56 56 58 61 61 62 62

. . . . . . . . .

64 64 65 66 66 67 67 68 68 69

11 Aplikace pro studijní administrativu 11.1 Studijní evidence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Sestava V7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Závěrečná vysvědčení a diplomy . . . . . . . . . . . . . . . . . . . . .

71 71 72 73

. . . . . .

9 Úvod do studijního systému 9.1 Základní pojmy studijního systému 9.2 Období . . . . . . . . . . . . . . . . 9.3 Univerzitní období . . . . . . . . . 9.4 Katalog předmětů . . . . . . . . . . 9.5 Prerekvizity . . . . . . . . . . . . . 9.6 Šablony předmětů . . . . . . . . . . 9.7 Doporučený plán studia . . . . . . 9.8 Výpočet ročníku studia . . . . . . . 9.9 Časový průběh období . . . . . . . 10 Aplikace studijního systému 10.1 Přijímací řízení . . . . . . 10.2 Registrace . . . . . . . . . 10.3 Rozvrhy . . . . . . . . . . 10.4 Zápis . . . . . . . . . . . . 10.5 Změny po zápise . . . . . 10.6 Záznamník učitele . . . . . 10.7 Přihlašování na zkoušky . 10.8 Koleje . . . . . . . . . . . 10.9 Další aplikace . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

6

OBSAH

12 Spolupráce se státními institucemi 74 12.1 Pojišťovna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 12.2 Ústav pro informace ve vzdělávání . . . . . . . . . . . . . . . . . . . . 74 12.3 Matrika studentů . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 13 Závěr

77

14 Literatura

78

Přílohy

80

A Ukázky aplikací studijního systému

81

7

1

Úvod a cíl práce

1.1

Úvod do problematiky

V souvislosti se zaváděním kreditního systému studia ECTS na Mendelově zemědělské a lesnické univerzitě vznikla nutnost inovovat do té doby používaný systém studijní agendy STUDENT. Protože úprava systému STUDENT do takové podoby, aby splňoval požadavky ECTS, by byla stejně náročná jako pořízení nového systému, bylo vedením univerzity rozhodnuto o pořízení systému nového, využívajícího možností moderních technologií, trendů a postupů užívaných v oblasti vývoje, návrhu a provozu informačních systémů. Z několika možných variant řešení se nakonec rozhodla vybudovat informační systém vlastními silami. Po úspěchu pilotního projektu Fakultního informačního systému na Provozně ekonomické fakultě (zkráceně označovaný jako miniFIS), který dokázal, že na univerzitě je skutečně možné takový systém vyvinout a provozovat vlastními silami, bylo vedením univerzity schváleno budování Univerzitního informačního systému (UIS). Nově budovaný systém má jasně definované cíle: • integrace stávajících proprietárních informačních systémů, • tvorba jednotné datové základny poskytující správné a aktuální informace všem uživatelům, • zavedení jednotných standardů v oblasti informačních systémů a informačních technologií, • tvorba podmínek pro racionální zavádění nových technologií na univerzitě, • podpora kreditního studia ECTS, • vzájemné propojení oblastí výuky a vědy, • zlepšení úrovně počítačové gramotnosti zaměstnanců a studentů, • odborný růst zaměstnanců pracujících na vývoji UIS. Studijní systém v UIS se na univerzitě stal primárním zdrojem informací o jejích studentech. Proto je nezbytné jeho napojení na ostatní informační systémy používané na škole (ekonomický systém, stravovací systém nebo informační systém používaný ve školní knihovně). Univerzitní informační systém také poskytuje data požadovaná státními institucemi (pojišťovna a matrika studentů). V současnosti tvoří studijní systém asi 70 % veškeré funkcionality poskytované UIS, zbytek funkcionality pokrývá ostatní integrované subsystémy. Do Univerzitního informačního systému byly také integrovány agendy, které dříve na univerzitě vůbec řešeny nebyly, především agenda spojená s evidencí a výrobou čipových karet (průkazy ISIC, ITIC, zaměstnanecké průkazy apod.). Součástí UIS je také poštovní subsystém poskytující obdobné možnosti jako jiné webové e-mailové služby (např. email.cz nebo hotmail.com) a navíc poskytuje dobré možnosti při odesílání zpráv generovaných systémem. Z dalších subsystémů UIS stojí za zmínku přístupový systém a systém centrální autentifikace. 8

1.2

Cíl práce

Univerzitní informační systém se začal tvořit v dubnu 2001 a při jeho tvorbě byly využity zkušenosti a poznatky z tvorby Fakultního informačního systému. Od září 2002 je vedena studijní agenda všech fakult v UIS. V červnu 2001 se autor této práce stal členem vývojového týmu UIS, ve kterém působil nejprve jako aplikační programátor, později začal rozšiřovat a upravovat programové moduly tvořící jádro Univerzitního informačního systému. Od listopadu 2002 působí ve funkci vedoucího vývojového týmu UIS. Zkušenosti získané při tvorbě Univerzitního informačního systému jsou shromážděny v diplomové práci Mgr. Ing. Milana Šorma (Šorm, 2002a). Ve své práci se zabývá především koncepcí budovaného systému a metodikou řízení projektu v prostředí univerzity. Další diplomovou prací dokumentující Univerzitní informační systém je práce Ing. Františka Dařeny (Dařena, 2002) o implementaci programových modulů jádra UIS. Diplomová práce Lukáše Stejskala (Stejskal, 2002) dokumentuje poštovní subsystém v UIS a Lukáš Bartík ve své diplomové práci popisuje tvorbu integrované aplikace Záznamník učitele (Bartík, 2003).

1.2

Cíl práce

Cílem této práce je poskytnout informace o celkové architektuře a prostředí Univerzitního informačního systému a zaměřit se hlouběji na studijní systém, který tvoří významnou součást UIS. Práce má vysvětlit základní pojmy z oblasti návrhu a implementace informačních systémů a termíny spojené se studiem a studijním systémem. Dále v práci čtenáři naleznou informace o základních principech, na jejichž základě je vytvořen studijní systém v UIS, a také popis aplikací spojených se studijním systémem. Na základě dlouhodobých zkušeností s vývojem a provozem aplikací v UIS budou navržena vylepšení a úpravy směřující k vylepšení chování informačního systému nejen k běžným uživatelům, ale také k pracovníkům zajišťujícím vývoj. V závěru práce bude zhodnoceno zavádění aplikací studijního systému do provozu a také odezva uživatelů na nově zaváděný systém. Základním předpokladem úspěšného zvládnutí práce je seznámení se s moderní architekturou informačních systémů a následné nastudování architektury Univerzitního informačního systému. Dále bude nutné se seznámit se studijním prostředím na MZLU v Brně. Poznatky budou získány studiem odborné literatury (citované ve vlastní práci a shrnuté v seznamu literatury) a konzultacemi na studijních odděleních a se systémovými integrátory fakult.

9

2

Definice pojmů

Práce se zabývá problematikou informačních systémů a s nimi souvisejících informačních a komunikačních technologií. Uvedená problematika se také často označuje zkratkou IS/ICT. Podobně jako ve všech ostatních vědních oborech je i v informatice a oblasti informačních systémů používána řada odborných termínů, bez jejichž znalosti není možné problematice plně porozumět. Tato kapitola obsahuje vysvětlení základních pojmů, které jsou běžně používány v odborné literatuře a při komunikaci mezi specialisty v oboru informatika a navazujících oborech. Podrobnější vysvětlení uvedených pojmů a další oblasti související s tvorbou a zaváděním informačních systémů jsou uvedeny v publikaci (Voříšek, 1996). Informace Informace je charakterizována následujícími vlastnostmi – je nehmotná, doplňuje nám znalosti (snižuje míru entropie), je obsažena nejen v samotných znacích, ale i v jejich vzájemném uspořádání. Znaky poskytují informaci pouze tomu, kdo je schopen rozpoznat jejich syntaxi a sémantiku (rozumí těmto znakům). Data Data jsou zprávy získávané smyslovým vnímáním reality, mohou být zaznamenána pomocí prostředků výpočetní techniky a dále zpracovávána. Pokud jsou data rozpoznána (většinou na základě předchozích zkušeností) a rozšiřují naše znalosti o zkoumaném objektu, pak se z dat stávají informace. Můžeme říct, že každá informace je součástí dat, ale ne každá data obsahují informaci. Systém Systém je účelově definovaná množina prvků a vazeb mezi nimi, které společně určují vlastnosti systému. Prvek je při dané úrovni rozlišení chápán jako dále nedělitelný. Prvky systému vázané pouze na prvky téhož systému jsou označovány jako vnitřní prvky, prvky s vazbou na prvek mimo systém je označován jako hraniční prvek a všechny prvky, které nejsou součástí systému jsou okolím systému. Informační systém Informační systém je systém, ve kterém jsou vazby mezi prvky reprezentovány informacemi a prvky systému jsou procesy, které transformují podněty (vstupní informace) na reakce (výstupní informace). Základním úkolem informačního systému je

10

2

DEFINICE POJMŮ

získání informací, jejich zpracování a v požadovaném čase, rozsahu a formě poskytnout informace uživateli. Informační systém obsahuje datovou základnu, technické a programové vybavení, technologie, finanční a personální zdroje. Informační technologie Informační technologie je soubor nástrojů, metod a znalostí sloužících k činnosti informačního systému (sběr, uchování, zpracování, přenos a prezentace dat). Do informační technologie patří také zákonitosti vývoje a tvorby informačních systémů. Technologie je správný název toho, čemu se dnes říká technika – technika je pouze hardwarové vybavení využívané technologií. Informační strategie Pojmem informační strategie rozumíme soustavu cílů a způsobů jejich dosažení. Smyslem informační strategie je zvyšování výkonnosti podniku, podpora dosažení strategických cílů podniku a získání strategické výhody před konkurencí. Základem informační strategie je nutnost dodržet soulad mezi globální podnikovou strategií a integrací informačního systému do podnikových procesů. Pouze při naplňování informační strategie jsou plněny strategické cíle podniku. Systémová integrace Systémová integrace je proces tvorby integrovaného informačního systému, tj. proces cílevědomého propojení všech komponent hardwaru, softwaru a podnikových procesů do fungujícího systému v souladu s informační strategií podniku. Od dobře prováděné systémové integrace lze očekávat zkrácení doby vývoje a implementace a zavedení informačního systému v podniku, lepší konkurenceschopnost podniku a lepší využití informací při řízení podniku. Samotná integrace probíhá na několika úrovních – na datové, aplikační, technologické a metodické úrovni i na úrovni uživatelského rozhraní a podnikových procesů. Integrovaný informační systém Informační systém může řešit úzkou problematiku a sloužit dílčím cílům nebo jeho činnost může pokrývat všechny oblasti v podniku a plnit podnikové strategické cíle. Systém řešící většinu činností v podniku pak můžeme nazvat integrovaným informačním systémem. Takový systém je pak většinou tvořen několika dílčími informačními systémy navzájem kooperujícími a propojenými pomocí metod systémové integrace. V současnosti ve světě převládá snaha podniků o budování integrovaných informačních systémů.

11

2

DEFINICE POJMŮ

Databázový systém Pojmem databázový systém se rozumí spojení databáze (tj. logické struktury uchovávaných dat a vlastních dat) a systému řízení báze dat (SŘBD, anglicky DBMS – Data Base Management System). Databázový systém umožňuje definici, manipulaci s daty a jejich údržbu a zajišťuje logickou správnost dat (integritu dat). Prostřednictvím jazyka pro definici dat (DDL – Data Definition Language) jsou prováděny manipulace s datovým slovníkem, jazyk pro manipulaci s daty (DML – Data Manipulation Language) umožňuje vkládání, mazání, modifikaci a čtení dat uložených v databázi. Aplikace pracující s daty nejsou součástí databázového systému. V současné době je nejrozšířenějším typem relační databáze, která je založena na modelu E. F. Codda ze 60. let. Relační databází je i databázový systém Oracle 9i využívaný v Univerzitním informačním systému. Kniha SQL: kompletní kapesní průvodce (Šimůnek, 1999) je vhodnou referenční příručkou jazyka SQL. Zdrojem základních informací o databázovém systému firmy Oracle je kniha Oracle Essentials (Greenwald, 1999). Základní i pokročilé funkce jsou velmi dobře popsány v knize Mistrovství v Oracle (Loney, 2002). Datový model Datový model je abstraktním návrhem struktury databáze. Obsahuje popis entit, jejich atributů, domén dat uchovávaných v těchto atributech a vazeb mezi entitami. Entitou je cokoliv, o čem chceme uchovávat data (např. pracoviště univerzity), atributem je údaj uchovávaný o entitě (např. adresa webové stránky pracoviště) a doménou atributu je obor možných hodnot (např. korektně zapsané URL). Problematice datového modelování se věnuje kniha Vytváříme relační databázové aplikace (Riordan, 2000) nebo Oracle Design (Ensor, 1997). SQL Structured Query Language – jazyk používaný pro komunikaci se systémem řízení báze dat. Je standardizován (norma SQL92) a díky tomu je nezávislý na použitém databázovém systému a programovacím jazyku. První verze jazyka pochází od firmy IBM a pod názvem SEQUEL se objevila v 70. letech. SQL je deklarativní jazyk (označovaný také jako jazyk čtvrté generace – 4GL), ale mnoho databázových systémů obsahuje jako doplněk procedurální jazyk (v SŘBD Oracle je to jazyk PL/SQL) vhodný pro tvorbu spouští (anglicky trigger) a uložených procedur (stored procedure).

12

2

DEFINICE POJMŮ

Internet Internet je vzájemným propojením lokálních počítačových sítí (rozsahem od LAN1 přes MAN2 až po rozsáhlé sítě WAN3 ). Fungování Internetu je založeno na řadě komunikačních protokolů a standardů, které všichni členové dodržují. Pro přenosy dat po Internetu se používá rodina protokolů TCP/IP, nad kterými vzniklo množství aplikačních protokolů (např. HTTP, FTP, SMTP, SNMP a jiné) pro různé služby poskytované Internetem (např. WWW, FTP, e-mail). V průběhu posledních několika let došlo ke značnému rozšíření využívání Internetu nejen v podnicích, ale i v domácnostech. Pozitivní vliv na masové rozšíření Internetu mezi běžné uživatele měla především služba WWW – poskytuje jednoduchý a intuitivní způsob ovládání (není nutné se učit nějaké příkazy) a díky možnosti kombinovat na stránkách text, grafiku a animace vytváří atraktivní prostředí pro prezentace služeb a výrobků podniků. Lokální sítě fungující na stejných principech, komunikačních protokolech a službách jako Internet označujeme jako internety (psáno s malým i). Vnitřní podnikové sítě (internety) jsou také označovány jako intranety, sítě mimo podnik jsou pak extranety. World Wide Web Služba WWW (World Wide Web, někdy označované také pouze web) znamenala významný krok při rozšíření Internetu mezi běžné uživatele. Služba WWW umožňuje vytvářet dokumenty obsahující grafiku, zvuky a animace a také hypertextové odkazy na jiné části téhož dokumentu nebo do jiných dokumentů. Pro tvorbu webových dokumentů se používá jazyk HTML (HyperText Markup Language) odvozený od obecného značkovacího jazyka SGML (Standard Generalized Markup Language). Dokumenty mohou být statické (tj. neměnné, předem vytvořené) nebo dynamické (tj. generované na základě požadavků).

1

Local Area Network – lokální počítačová síť Metropolitan Area Network – počítačová síť pokrývající města nebo městské aglomerace 3 Wide Area Network – počítačová síť spojující vzdálená místa (státy, kontinenty) 2

13

3

Architektura informačního systému

Architektura informačního systému zahrnuje jeho budoucí podobu, jednotlivé komponenty systému a vazby mezi nimi. Každý informační systém většího rozsahu by měl obsahovat vnitřní strukturu, která umožní efektivně plnit funkce a cíle, pro něž byl navržen. Aby informační systém splňoval potřebné vlastnosti, musí jeho architektura podporovat: • strategické cíle podniku – trendem je snižování nákladů, zvyšování kvality výrobků a služeb, zlepšení dobrého jména firmy, modernizace pracovního prostředí, • všechny uživatelské požadavky podporující dosažení strategických cílů podniku, • hardwarovou, softwarovou a datovou integraci – data jsou uložena pouze jednou a přístupná všem aplikacím, uživatelské rozhraní se drží zažitých standardů, jednotlivé softwarové moduly spolu vzájemně komunikují a spolupracují, • systém musí být rozšiřitelný a parametrizovatelný – nebude problém rozšířit stávající systém o další hardwarové a programové komponenty, určité konstanty jsou nastavitelné přes uživatelské rozhraní (např. sazba DPH při změně souvisejících předpisů), • efektivní a spolehlivé zpracování dat – zajištění dostatečně rychlé odezvy operací, zajištění konzistence dat při havárii systému, zabezpečení dat před zneužitím.

3.1

Globální architektura

Globální architektura je základní schéma znázorňující hrubou podobu budovaného informačního systému. Základem globální architektury jsou skupiny aplikací, jejich funkce a datová základna. V globální architektuře jsou vynechány veškeré detaily, aby byla co nejjednodušší a srozumitelná. Architektura vytváří poměrně stabilní rámec pro řízení tvorby informačního systému, do něhož jsou postupně začleňovány jednotlivé technologické a programové součásti v závislosti na potřebách a podmínkách podniku. Globální architektura slouží také jako prostředek komunikace mezi zadavatelem a realizátorem informačního systému, pomáhá při definici priorit nasazování informačního systému do provozu. Dobře provedený návrh architektury systému pomáhá minimalizovat dodatečné náklady spojené s chybným zadáním nebo řízením podniku. Jednotlivé komponenty architektury musí být v souladu s podnikovou strategií, funkčními a řídícími postupy v podniku a musí zajišťovat flexibilní přizpůsobení se měnícím se podnikovým procesům. Globální architektura zahrnuje také specifikaci potřebného stupně spolehlivosti – odolnost proti technickým závadám, negativním zásahům obsluhy apod.

14

3.1

Globální architektura

Postupem času došlo ke značné standardizaci základních stavebních bloků globální architektury. Tato standardní architektura je zobrazována jako pyramida rozdělená podle tří úrovní řízení podniku (viz obr. 1).

EIS

MIS

TPS EDI

OIS

Obr. 1: Základní bloky globální architektury Konkrétní podoba architektury systému je ovlivněna řadou faktorů. Předmět činnosti podniku ovlivňuje vrstvu operativního řízení podniku, organizační struktura (hierarchická nebo plochá, centrálně nebo decentralizovaně řízená) spoluvytváří způsob komunikace mezi řídícími pracovníky. Je nutné brát v úvahu rozmístění jednotlivých pracovišť podniku (jedna lokalita nebo dislokace na více místech), umístění některých pracovišť na území jiných států (jiná legislativa a další odlišnosti zahraničního prostředí). Nezanedbatelným hlediskem je možnost využití stávajícího technologického a technického vybavení a personálních zdrojů v novém systému nebo bude třeba provést modernizaci techniky a doškolit nebo nově vyškolit personál. Operativní řízení podniku TPS (Transaction Processing System) reprezentuje bloky činností podniku na úrovni operativního řízení. Jejich funkce jsou prováděny rutinně, je požadována vysoká rychlost odezev a spolehlivost. Skladba aplikací je velmi silně závislá na charakteru podniku (výrobní podnik, malosériová nebo kusová výroba, hromadná výroba, podnik poskytující služby, obchodní společnosti). Blok TPS může obsahovat i další podpůrné komponenty jako např. CAD systémy. Taktické řízení podniku MIS (Management Information System) podporuje taktické řízení podniku (střednědobý horizont) a navazuje na vrstvu operativního řízení. Na základě ucelených 15

3.2

Dílčí architektury

a sumarizovaných dat z TPS umožňuje kontrolovat a řídit základní podnikové aktivity. Aplikace řeší oblasti: • ekonomiky (účetnictví, evidence majetku, závazků a pohledávek, finanční řízení), • organizace podniku (personalistika a mzdy), • obchodu. Tyto aplikace jsou hodně podobné ve většině podniků bez ohledu na jejich zaměření. Strategické řízení podniku EIS (Executive Information System) obsahuje aplikace určené ke strategickému řízení podniku. Aplikace využívají data poskytovaná nižšími vrstvami (tj. TPS a MIS) i data z externích zdrojů k analýze a poskytování informací pro strategická rozhodnutí vrcholového vedení podniku. Data jsou sledována i dlouho do minulosti. Součástí jsou systémy pro podporu rozhodování (DSS – Decision Support System). Kancelářské systémy OIS (Office Information System) zastupuje sadu aplikací zaměřených na podporu kancelářských prací. Obsahuje nejčastěji: • textový procesor, • tabulkový procesor, • software pro tvorbu prezentací, • plánovací kalendář, • aplikace podpory týmové práce, • klienta elektronické pošty, • prohlížeč webových stránek. Komunikace s okolím EDI (Electronic Data Interchange) představuje aplikace zajišťující elektronickou komunikaci s okolím podniku – dodavatelé a odběratelé, zákazníci, banky, státní instituce. V této oblasti se již v širokém měřítku prosadilo využití možností poskytovaných sítí Internet.

3.2

Dílčí architektury

Na globální architekturu navazují dílčí architektury prohlubující návrh do větších detailů – funkční, procesní, datová, technologická, softwarová a hardwarová. • Funkční architektura obsahuje rozklad základních funkčních bloků do menších funkčních celků. Nejvyšším stupněm dekompozice je rozklad funkcí na elementární (atomické) operace (transakce). 16

3.3

Horizontální struktura

• Procesní architektura popisuje probíhající činnosti v podniku. Na nejvyšším stupni abstrakce je při modelování využit kontextový diagram, na nižších stupních pak DFD diagramy (Data Flow Diagram). Procesy reprezentují místa transformace dat, jejich činnost je aktivována datovými toky nebo událostmi. Datové toky reprezentují vazby mezi prvky systému, zásobníky dat slouží k uchování potřebných dat a terminátory jsou prvky, které patří do okolí informačního systému. • Datová architektura definuje použitou datovou základnu pomocí entit, jejich atributů a vazeb mezi entitami. Při modelování je použit entitně-relační diagram (ERD). Entity lze chápat jako abstrakce množin objektů se stejnou logickou strukturou (stejnými atributy), vazby definují souvislost mezi objekty jedné, dvou nebo několika entit. Důležitou vlastností vazeb je jejich mohutnost (kardinalita). • Technologická architektura definuje způsob zpracování dat (interaktivní, dávkové, řízené událostmi, centralizované, distribuované), způsob práce aplikací (klient/server, peer-to-peer) a standardy uživatelského rozhraní. • Softwarová architektura specifikuje, z jakých programových komponent se bude celý systém skládat, určuje funkce jednotlivých komponent, jejich vstupní a výstupní data, algoritmy transformace dat, vývojové prostředí. Softwarová architektura také definuje vzájemnou spolupráci jednotlivých programových modulů. Základními typy softwarové architektury jsou lineární, hierarchická, vrstvená a síťová architektura. • Hardwarovou architekturou je určeno technické vybavení informačního systému. Jedná se nejen o servery, pracovní stanice, tiskárny, ale i jejich vzájemné propojení, použití záložních zdrojů napájení a zálohovacích zařízení.

3.3

Horizontální struktura

Jiným pohledem na strukturu informačního systému je pohled z hlediska jednotlivých složek podniku využívající tento systém. Při členění podniku na několik středisek jsou vytvářeny pro jednotlivá střediska jejich subsystémy. Při dalším členění středisek na oddělení a útvary vzniká stromová struktura. Příkladem můžou být subsystémy Výroba, Marketing, Management, Účetnictví a další členění subsystému Výroba na Nákup surovin, Kontrolu zásob apod. Kombinace vertikální architektury s horizontální strukturou vypadá jako na obr. 2.

3.4

Vrstvená architektura

V současnosti do pojmu architektura patří vnitřní systémová architektura a struktura implementačních vrstev umožňující přenášet systém mezi různými prostředími (jiný operační systém, změna databáze). Tato struktura se nazývá vrstvená architektura.

17

3.4

Vrstvená architektura

EIS

MIS

TPS Výroba

Marketing

Management Účetnictví

Obr. 2: Kombinace horizontální a vertikální architektury Nejjednodušším (a nejstarším) případem vrstvené architektury je jednovrstvá architektura, kdy všechny operace řešil jediný subsystém (tedy celý systém). Později vznikaly dvouvrstvé systémy pracující v režimu klient/server. Na straně serveru byla databázová vrstva, na straně klienta fungovala aplikační logika i prezentace dat uživateli. S růstem počtu databázových systémů, operačních systémů, požadavků na tvorbu integrovaných systémů a různých zařízení, pomocí kterých je možno budovat informační systémy, došlo ke vzniku třívrstvé architektury s těmito vrstvami: • prezentační vrstva, • aplikační vrstva, • datová vrstva. Na nejnižší úrovni je datová vrstva reprezentovaná databázovým systémem poskytujícím společnou datovou základnu různým dílčím systémům integrovaného informačního systému. Datová vrstva zajišťuje funkce pro vkládání, získávání a modi-

Prezentační vrstva Aplikační vrstva Datová vrstva Obr. 3: Schéma třívrstvé architektury

18

3.4

Vrstvená architektura

fikaci dat, kontroluje integritu ukládaných dat, provádí jejich předzpracování a agregaci. Prostřední vrstvou je vrstva aplikační, která realizuje veškeré transformace (operace a výpočty) vstupních a výstupních dat. Protože leží mezi datovou a prezentační vrstvou, bývá označována pojmem middleware. Middleware je v komerčním světě též používán pro aplikační servery. Nejvyšší vrstvou (tedy nejblíže k uživateli systému) zajišťující prezentaci výsledků a vstup požadavků a povelů od uživatele je prezentační vrstva. Podle rozsahu zajišťovaných funkcí rozlišujeme klientské programy na tlusté a tenké klienty. Činnost tlustého klienta pokrývá prezentační vrstvu a zasahuje také částečně do vrstvy aplikační. Funkcionalita tenkého klienta je omezena na co nejjednodušší zprostředkování vstupů a výstupů mezi informačním systémem a uživatelem. Většinou je možné provozovat tenké klienty na různých zařízeních (osobní počítače, PDA – kapesní počítače, mobilní telefony) a operačních systémech (MS Windows, Linux, PocketPC, . . . ). V případě realizace informačního systému v prostředí webu je klientem libovolný internetový prohlížeč.

Prezentační vrstva

Aplikační vrstva Datová vrstva Obr. 4: Schéma třívrstvé architektury s tenkým klientem Rozložení jednotlivých vrstev v třívrstvé architektuře je ilustrováno na obr. 3, situace v případě použití tenkého klienta je demonstrována na obr. 4. Je možné provést ještě detailnější rozdělení na více vrstev, ale základní členění na tři vrstvy je ve většině případů dostačující.

19

4

Životní cyklus informačního systému

Stejně jako jiné produkty, informační systém prochází od okamžiku rozhodnutí o jeho nasazení v podniku až do ukončení jeho používání různými fázemi. Souhrnně je sled všech fází nazýván životním cyklem informačního systému.

4.1

Úvodní studie

Úvodní studie je první z řady dokumentů, které vznikají při tvorbě informačního systému. V úvodní studii se odráží cíl podniku při zavádění informačního systému na základě podnikové strategie, obsahuje analýzu aktuálního stavu v podniku, identifikaci problémů v současně používaném informačním systému a v hrubých rysech návrh nového informačního systému, dekomponovaný na úroveň jednotlivých subsystémů. Dále může obsahovat odhadovanou časovou náročnost, odhad nákladů na pořízení informačního systému a srovnání s přínosem pro podnik. Úvodní studie je dokument, který předkládají uchazeči při výběrovém řízení na zavedení informačního systému v podniku. Proto jsou součástí úvodní studie také informace pro podnikový management, dopady na organizaci práce, pracovní a sociální aspekty zavedení informačního systému (požadavky na kvalifikaci zaměstnanců, zvýšení efektivity práce, redukce počtu zaměstnanců). Součástí úvodní studie jsou také technické specifikace požadavků na softwarové a hardwarové vybavení.

4.2

Analýza

Před návrhem řešení je nezbytné provést analýzu problému. Analýza je prováděna z několika různých hledisek, především je věnována pozornost procesnímu (funkčnímu) a datovému hledisku. Během procesu analýzy jsou vytvářeny různé modely sloužící ke komunikaci mezi zadavateli a analytiky. Mezi běžně vytvářené modely patří kontextový diagram (reprezentuje vazby systému na své okolí), funkční model (data-flow diagram), datový model (entitně-relační diagram), matematický model. Pro reprezentaci modelů se používá různých forem zápisu – prostý slovní popis (případně zjednodušený strukturovaný jazyk), grafické znázornění, matematický popis, matice chování a jiné. Výsledkem analýzy je rozbor problému a označení problematických partií spolu s návrhem řešení.

4.3

Globální návrh

Návrh provedený v úvodní studii je v globálním návrhu rozveden do větších detailů. Fáze globálního návrhu je prováděna na logické úrovni, tedy obecně a nezávisle na určité konkrétní hardwarové a softwarové platformě. 20

4.4

Detailní návrh

Při návrhu hardwaru jsou specifikovány požadavky na počty a rozmístění jednotlivých terminálů, požadavky na servery, požadavky na rychlost odezvy a přenosovou kapacitu datových spojů. Návrh softwarové části systému zahrnuje návrh architektury (určení jednotlivých vrstev), definici standardů pro komunikaci mezi jednotlivými moduly (protokoly), standardy v oblasti uživatelského rozhraní (konzistentní chování všech modulů k uživateli), specifikace požadovaných rychlostí odezvy a také způsob zpracování úloh (interaktivní, dávkové). Je vytvořen podrobný datový model odpovídající charakteru dat zpracovávaných v podniku (objem, forma, obsah, doba uchování). Je provedena hluboká dekompozice funkčního modelu (až na úroveň transakcí), reakce na události, vstupní a výstupní data transakcí a jejich transformace spolu s vymezením stupně automatizace (akce spouštěné na přání uživatele, akce spouštěné automaticky). Na základě provedené analýzy jsou specifikovány role uživatelů, kteří budou s informačním systémem pracovat. Jsou definována oprávnění jednotlivých uživatelů nebo celých skupin v rámci celého podniku a také potřebná kvalifikace těchto uživatelů.

4.4

Detailní návrh

U menších projektů splývá detailní návrh s globálním návrhem. Při detailním návrhu je přechod od logického návrhu k návrhu fyzickému, tj. jsou už navrženy konkrétní hardwarové a softwarové komponenty systému. Jsou navrženy specifikace počítačů, tiskáren, síťových prvků a dalšího vybavení (např. snímače čárového kódu), jejich umístění v jednotlivých místnostech a potřebné stavební úpravy. Na úrovni softwaru je zvolen databázový systém (relační databáze, strukturovaný soubor), struktura jednotlivých záznamů a datové typy. Je proveden odhad četnosti přístupů k databázi (což spolu s požadavky na rychlost odezvy určuje požadavky na hardware), frekvence ukládání nových dat a tím i nárůst velikosti databáze (důležité informace pro návrh způsobu zálohování – CD-R, jednoduchá páska, páskový robot), jsou navrženy formuláře pro vstup dat a tiskové sestavy (výstupy přizpůsobené podnikové kultuře – jednotné záhlaví, použití hlavičkového papíru apod.). Transakce ve funkčním modelu jsou dekomponovány na úroveň jednotlivých kroků, jsou navrženy algoritmy zpracování dat, jednotlivé moduly informačního systému spolu s jejich vstupy a výstupy. Výběr programovacího jazyka pro realizaci informačního systému ovlivní možnosti tvorby knihoven funkcí a vzorových řešení programů. Pro zajištění kvalifikované obsluhy jsou plánována školení a jejich obsah.

4.5

Implementace

Implementací se rozumí realizace informačního systému podle specifikací v detailním návrhu. Nakupuje se hardwarové vybavení a je na něj prováděna instalace základního softwaru. Dále je třeba vytvořit databáze dle specifikací uvedených v detailním návrhu, provést naplnění číselníků a naplnit je počátečními daty. V této fázi mohou 21

4.6

Zavádění systému do provozu

být použita i testovací data, ale je třeba připravit převod dat z původního (nahrazovaného) systému do nového systému. Je nutné zvolit metodu zavádění informačního systému (kompletní zavádění, postupné zavádění po odděleních nebo po jednotlivých modulech). Programové moduly a aplikace jsou vytvářeny podle vzorových řešení nebo jsou používány nástroje pro jejich tvorbu (CASE a RAD nástroje), průběh tvorby aplikací by měl být provázen tvorbou uživatelské (pro účely školení), provozní (nezbytné pro zajištění správného provozu systému) a programátorské (dodatečné úpravy, oprava chyb) dokumentace. Aplikace jsou testovány na správnost (verifikace a validace) poskytovaných výsledků, je kontrolovaná požadovaná rychlost odezev a výsledky testů jsou zohledněny při dalším vývoji aplikací. Během implementace je možné začít provádět základní školení uživatelů.

4.6

Zavádění systému do provozu

Zavádění informačního systému zahrnuje instalaci, konfiguraci a testování hardware a software potřebného pro provoz systému. Týmu zajišťujícímu provoz systému je předána uživatelská a provozní dokumentace a soubor operačních postupů (posloupnost kroků při startování a ukončení chodu systému, postup aktualizace systému, obnova systému po výpadku, postup při vzniku chyby). Během zavádění informačního systému dochází k souvisejícím změnám v organizaci podniku – vstupují v platnost nové organizační předpisy a směrnice, jsou prováděny potřebné personální změny. Uživatelům jsou distribuována přihlašovací jména a hesla (popř. čipové karty apod.), jsou pořádána školení v používání informačního systému i zajištění jeho provozu. V systému jsou zavedena provozní data a jsou prováděny zátěžové testy. Fáze zavádění končí pozitivním vyhodnocením akceptačních testů. Po splnění všech podmínek přechází nový systém do rutinního provozu. Starý systém je pak buď celý odstaven nebo je zachován přístup pro omezený počet uživatelů (především kvůli zpětné analýze za provozní období). Celý proces zavádění by se měl držet stanoveného harmonogramu, aby přechod od starého systému k novému byl uskutečněn v krátké době bez zbytečných průtahů.

4.7

Provoz a správa

V průběhu provozování systému dochází k údržbě hardwaru i softwaru. Hardwarové závady jsou řešeny prostřednictvím servisních oprav nebo nákupem nového zařízení. Může probíhat postupné posilování výkonu nebo vytváření záložních serverů pro případ výpadku produkčních serverů (zvýšení redundance komponent). Zásahy do softwaru informačního systému jsou prováděny v případě opravy nalezené chyby nebo při modifikaci na základě přání uživatelů. Všechny požadavky na úpravu jsou předmětem jednání s dodavatelem systému, který vyhodnotí náročnost modifikace a stanoví cenu za tyto úpravy. Součástí realizace úprav je i aktualizace dokumentace a případně může zahrnovat i přeškolení. 22

4.8

4.8

Ukončení provozu

Ukončení provozu

Poslední fází životního cyklu informačního systému je ukončení jeho provozu, který většinou probíhá souběžně s nasazením nového systému do provozu. Je proveden převod databází do nového systému, systém je zazálohován a všechny další operace jsou prováděny na novém systému. Důvody pro nahrazení stávajícího systému mohou být různé – systém již nevyhovuje situaci v podniku, výrobce ukončil podporu, podnik byl koupen jinou společností, která využívá vlastní informační systém.

23

5

Modely životního cyklu

V praxi nejsou jednotlivé fáze životního cyklu řešeny lineárně tak, jak jsou v této kapitole uvedeny, ale některé fáze se mohou překrývat nebo opakovat. Existuje několik ověřených modelů řízení návrhu a vývoje informačního systému. Budou uvedeny modely vodopádu, iterativní model, model výzkumník a model prototypování. Při reálné práci na systému často není využíván jeden konkrétní model, ale spíše kombinace uvedených modelů.

5.1

Model vodopád

Při vývoji podle modelu vodopád jsou jednotlivé fáze striktně odděleny. Postup do další fáze řešení nastává až po úplném a úspěšném vyřešení předchozí fáze, návrat ke dřívějším fázím není možný. Realizace systému tímto způsobem je možná pouze za předpokladu, že zadavatel zná přesně svoje potřeby (je schopen přesně definovat své požadavky), nedochází k jejich změně v průběhu času, nedojde ke změně využívaných technologií a řešitel je na tak vysoké úrovni, že je schopen tímto způsobem pracovat. Model vodopád definuje pořadí jednotlivých fází podle jejich logického sledu – analýza, návrh, implementace, testování a zavádění (viz obr. 5). Nevýhodou tohoto způsobu řízení je fakt, že provozuschopný informační systém vzniká až v pozdějších etapách projektu a případné nedostatky jsou detekovány až v závěru vývoje. Odstranění zjištěných nedostatků je pak tím obtížnější a nákladnější (časově i finančně), v čím dřívější fázi vznikly.

5.2

Iterativní model

Iterativní model vývoje vyžaduje aktivní účast zadavatele projektu. Po provedení analýzy, návrhu a implementace jsou shromážděny požadavky uživatelů a je provedena nová iterace cyklu analýza, návrh, implementace. Připomínky vznikají často až v průběhu času, když si uživatelé uvědomí své potřeby a možnosti, které jim systém poskytuje. Po zapracování všech připomínek, na kterých se zadavatel s dodavatelem dohodli, je vytvořena, otestována a předána k provozu konečná verze systému. Výhodou tohoto modelu je spoluodpovědnost zadavatele za rozsah řešených funkcí a plnění požadavků daných úvodní studií. Další výhodou je také skutečnost, že je zadavatel dobře informován o postupu prací na projektu. Schéma iterativního modelu je zachyceno na obr. 6.

24

5.3

5.3

Model výzkumník

Analýza

Analýza

Návrh

Návrh

Implementace

Implementace

Testování

Testování

Zavádění

Zavádění

Obr. 5: Model vodopád

Obr. 6: Iterativní model

Model výzkumník

Při práci metodou výzkumník je možné zasahovat do již dříve provedených etap a v nich provádět modifikace. Předání do provozu se provede, pokud zadavatel systém akceptuje. Na rozdíl od iterativního modelu nejsou prováděny vždy znovu všechny fáze analýzy, návrhu a implementace. Při řízení projektu tímto způsobem je velmi obtížné odhadnout časové i finanční náklady a také plán plnění jednotlivých etap. Schéma modelu výzkumník ilustruje obr. 7. Dalším problémem je dokumentace, která se musí provádět průběžně. Tvorba dokumentace v počátku projektu bez následných aktualizací nedokumentuje výsledný produkt, naopak při dokumentaci pouze výsledného produktu není z dokumentace patrné, jakým způsobem se dospělo k řešení (není ani patrné, jaký byl původní rozsah zadání). Také existuje riziko, že nebude udržen rovnoměrný rozvoj všech modulů a dojde k přílišnému soustředění pozornosti na jeden určitý modul a ostatní moduly budou strádat.

5.4

Prototypování

Smyslem prototypování je zrychlená tvorba systému, kdy je řešena pouze určitá část výsledného systému (na logické i fyzické úrovni). Při prototypování může být velmi rychle navrženo uživatelské rozhraní (vstupní formuláře, výstupní sestavy), ale tyto formuláře nemusí být plně funkční (např. prototyp nebude schopen ukládat data). 25

Model použitý při tvorbě UIS

Analýza

Analýza

Návrh

Návrh

Implementace

Implementace

Testování

Testování

Zavádění

Zavádění

Obr. 7: Model výzkumník

Prototyp

5.5

Obr. 8: Prototypování

Jiným příkladem může být vytvoření prototypu určité transakce nebo algoritmu a následné ověření správnosti chování prototypu zadavatelem. Poznatky získané při tvorbě prototypů jsou pak využity při všech fázích realizace informačního systému. Prototypy samotné pak nejsou využity ve výsledném produktu, ale slouží pouze jako komunikační prostředek mezi realizátorem a zadávajícím podnikem. Role prototypu je zachycena na obr. 8. Prototyp systému, který je schopen základní manipulace s daty, je velmi užitečný při vyjasňování představ zadavatele o budovaném systému. Prototypování se velmi často u menších systémů kombinuje s metodou výzkumník, ale při tvorbě rozsáhlých systémů se nepoužívá v takovém rozsahu především z ekonomických důvodů.

5.5

Model použitý při tvorbě UIS

Při vývoji Univerzitního informačního systému dochází ke kombinování všech výše uvedených modelů. Základní návrh architektury systému a návrh základních programových modulů byl proveden na základě zkušeností s předchozími systémy a odhadu nových požadavků. Navržená struktura je pevně daná a není možné ji měnit. Jakákoliv změna by znamenala přepracování již existujících aplikací. Uvedené vlastnosti odpovídají modelu vodopád. Při tvorbě jednotlivých aplikačních modulů je užíván iterativní model. Vznikající aplikace odrážejí aktuální požadavky univerzity, ale požadavky se často v průběhu času mění a aplikace jsou podle nových požadavků tvořeny. Jako příklad uve26

5.5

Model použitý při tvorbě UIS

deného postupu je možné použít sylaby předmětů. Byl vyvinut způsob umožňující definovat každé fakultě svůj vlastní formát zobrazení sylabu předmětu. V poslední době však situace signalizuje, že budou požadovány sylaby v jednotné formě. Konkrétní aplikace jsou zpracovány nejprve do podoby prototypu (což je umožněno využitím modulů s vysokou úrovní abstrakce). Díky prototypu získá vedení univerzity představu o podobě a funkcích připravované aplikace a je umožněno konkretizovat požadavky. Následný vývoj je pak prováděn metodou výzkumník, kdy jsou zařazovány nové požadavky a úpravy vzcházející i z připomínek koncových uživatelů (sdělovaných prostřednictvím systémových integrátorů fakult). Díky využití třívrstvé architektury a nasazení Univerzitního informačního systému v prostředí webu, kde tenkým klientem je internetový prohlížeč, je možné zveřejňovat aktualizace aplikací bez nutnosti instalovat opravené verze klientského software u koncových uživatelů. Při několika aktualizacích denně je možné držet vysoké tempo vývoje a velmi pružně reagovat na požadavky univerzity nebo odstraňovat případné problémy. Nevýhodou používaného modelu vývoje je značná provázanost provozu a vývoje aplikací. Vývojový tým kromě vývoje nových aplikací zajišťuje také provoz všech zveřejněných aplikací. Hotové aplikace ani jejich následné aktualizace nejsou předávány do rutinního provozu. Aktualizace jsou prováděny v okamžiku zveřejnění aplikace z vývoje do ostrého provozu a nejsou řešeny kumulativní opravou (např. provádění aktualizace systému v týdenních nebo měsíčních intervalech). Tento nedostatek je ovšem vyvážen vysokou rychlostí reakcí na požadavky a pozitivní odezvou uživatelů na rychlost těchto reakcí.

27

6

Způsoby pořízení informačního systému

Zadavatel projektu nového informačního systému má možnost zvolit si způsob, jakým bude nový systém pořízen. Existuje řada možností pořízení, nejběžnějšími způsoby jsou vývoj systému vlastními silami, vývoj systému externí firmou, nákup typového řešení informačního systému a jeho následná úprava pro potřeby podniku, nákup parametrizovaného systému a příslušná nastavení parametrů nebo využití možností outsourcingu. Výběr způsobu dodávky informačního systému provádí zadavatel, vlastní realizace je pak svěřena systémovému integrátorovi.

6.1

Vývoj systému vlastními silami

Tento způsob pořízení informačního systému je pro podnik nejnáročnějším způsobem. Podnik musí být dostatečně vybaven po stránce technologické i personální. Na zajištění dlouhodobého vývoje systému je třeba vynaložit značné finanční prostředky (odborná literatura, školení zaměstnanců realizujících informační systém, nákup a údržba hardwaru a licencí softwaru). Jistá rizika sebou také přináší možný vznik závislosti podniku na jednotlivci (nebo celé skupině), kteří jsou klíčoví pro chod systému (např. z důvodu absence dokumentace nebo značných nárocích na znalosti jejich nástupce). Vyvážením vysokých nároků by měl být vznik informačního systému přesně podle požadavků podniku (tzv. vývoj na míru).

6.2

Vývoj systému externí firmou

Vývoj systému zajišťovaný externí firmou probíhá podobně jako v situaci, kdy si podnik systém vyvíjí sám. Vznikající informační systém je vytvářen podniku na míru, ale zadávající podnik nemusí disponovat takovým personálním a technologickým zázemím jako kdyby si systém vyvíjel ve vlastní režii. Problematickou oblastí může být vzájemná komunikace mezi zadavatelem a dodavatelem. Dalším rizikem je vznik velmi úzké vazby mezi oběma spolupracujícími firmami (nežádoucí efekt u státních zakázek). Jedná se vlastně o outsourcing vývoje informačního systému.

6.3

Nákup typového informačního systému

Pořízení informačního systému nákupem typového řešení je v praxi jeden z nejoblíbenějších. Nízká pořizovací cena typového systému je vyvážena cenou úprav potřebných pro přizpůsobení informačního systému prostředí podniku, ve kterém je systém nasazován. Výsledné náklady na pořízení systému mohou být vyšší než při vývoji systému na míru (ať už vlastními silami nebo jinou firmou). Řada firem také volí přizpůsobení vlastní organizační struktury pořízenému systému. Typové informační systémy jsou produkovány velkými společnostmi (např. Oracle, SAP AG, Microsoft 28

6.4

Nákup parametrizovaného systému

aj.) a proto se dá očekávat dobrá úroveň podpory a odpovídajícího zázemí než v případě malých dodavatelských firem. Dodavatelské společnosti působí často v několika světových regionech a proto je třeba při výběru dodavatele volit také podle možností přizpůsobení a lokalizace na národní prostředí.

6.4

Nákup parametrizovaného systému

Parametrizované systémy představují levnější variantu typových informačních systémů. Přizpůsobení systému je možné na uživatelské úrovni – systém není upraven na míru zadavateli, ale jsou nastaveny parametry systému tak, aby mu co nejvíce vyhovovaly. Cena parametrizovaného systému je vyšší než cena typového systému, protože jeho vývoj je kvůli ovlivnění parametry náročnější. Většina společností dodávajících typové systémy přechází k poskytování parametrizovaných systémů především pro jejich jednodušší nasazení u svých zákazníků (tedy rychlejší přechod na nový systém a s tím související celkově nižší náklady na zavedení systému).

6.5

Outsourcing informačního systému

Nejmladším způsobem pořízení informačního systému je outsourcing – celý projekt od vypracování úvodní studie, přes návrh až po provoz výsledného systému je svěřen externí firmě. Tato firma pak dostává pravidelné poplatky za poskytované služby. Tím jsou veškeré starosti o technologické i personální zabezpečení celého projektu na bedrech poskytovatele outsourcingu. Výběr poskytovatele pak závisí především na pozitivních referencích. V současnosti je největším problémem této metody nedostatek firem využívajících outsourcingu (a tedy málo referencí na úspěšné projekty) a neochota zadávajících podniků kompletně poskytnout veškerá svoje data cizímu subjektu.

6.6

Pořízení Univerzitního informačního systému

Při výběru způsobu, jakým bude Univerzitní informační systém na univerzitu pořízen, byly velké naděje vkládány do zakoupení typového informačního systému nebo do outsourcingu celého systému. Bohužel univerzita nedisponovala žádným pracovníkem, který by garantoval nákup typového informačního systému a následnou implementaci tohoto systému ve specifickém prostředí vysoké školy. V době, kdy se o pořízení informačního systému rozhodovalo, bylo outsourcování informačních systémů spíše v rovině teoretických úvah, ale chyběly reálné zkušenosti s dodavateli tohoto typu služeb a jakékoliv reference. Univerzita si nemohla dovolit investovat značné finanční prostředky pořízením systému způsobem, který byl značně nejistý s chybějícími praktickými zkušenostmi jak na straně dodavatelů tak jejich zákazníků. Z výše uvedených důvodů bylo přistoupeno ke kompletnímu vývoji systému na míru podmínkám univerzity. Pořízení systému dodavatelským řešením od externí firmy nakonec nebylo zvoleno, protože dodavatelská řešení nevyhovovala záměrům 29

6.6

Pořízení Univerzitního informačního systému

(značná různorodost, nedostatečná garance výsledku, nejistá stabilita dodavatelů apod.), a bylo rozhodnuto o vybudování informačního systému vlastními silami. Vývojový tým byl zpočátku tvořen teoretickými odborníky z Ústavu informatiky na Provozně ekonomické fakultě, později došlo k jeho transformaci na značně praktický tým. V současnosti je vývojový tým složen ze studentů univerzity zaměstnaných na částečný úvazek na Oddělení automatizace informační soustavy, demonstrátorů (studenti odměňováni formou stipendia) a studentů tvořících aplikace v rámci svých bakalářských a diplomových prací. Značnou motivací pro studenty je možnost získání konkurenční výhody (týmová spolupráce i práce na tvorbě takto rozsáhlého systému i znalost využívaných technologií je velmi dobrou referencí) při nástupu do praxe. Kromě toho mají zajištěno vlastní pracoviště vybavené moderní výpočetní technikou a nejsou omezeni pouze na vyhrazené hodiny v počítačových učebnách. Pro univerzitu je tento způsob pořízení výhodný ve značné pružnosti při požadavcích na modifikaci systému. Také díky všeobecně nízké platové úrovni na vysokých školách je zaměstnání vlastních lidí levnější než dodavatelský způsob pořízení informačního systému. Nevýhodou je nutnost neustálé obnovy a hledání nových pracovníků do vývojového týmu, protože na univerzitě nejsou vytvořeny podmínky pro to, aby lidé, kteří dokončí svá studia, se nadále mohli věnovat práci na Univerzitním informačním systému na plný úvazek a byli odměňováni srovnatelně jako informatičtí odborníci v komerční sféře.

30

7

Trendy v informačních technologiích

Informační systémy a informační a komunikační technologie prodělaly od doby svého vzniku značný vývoj. Možnosti prvních systémů pro hromadné zpracování dat jsou dnes pouhým zlomkem možností, které nám poskytují současné informační systémy. Dobrý informační systém není možné budovat bez informační technologie odpovídající aktuálnímu stavu vývoje, protože použitá technologie do značné míry ovlivňuje možnosti informačního systému. Podcenění sledování nejnovějších trendů v oblasti IS/ICT při současném tempu vývoje zcela jistě povede ke ztrátě konkurenceschopnosti podniku zabývajícího se tvorbou informačních systémů. Podobně tak i podnik využívající zastaralý informační systém nebo systém vybudovaný na zastaralé technologii ztrácí schopnost prosadit se v konkurenčním boji. Interval změn informačních technologií se neustále zkracuje, ještě rychleji dochází k zastarávání techniky (v současnosti je délka intervalu obměny techniky okolo dvou až tří let). Rozvoj nových a nadějných technologií je velmi často podporován nejen ze strany podniků aktivních v této oblasti, ale je podporován i státem.

7.1

Trendy v oblasti základního software

V současnosti se na trhu prosadily produkty společnosti Microsoft. Na poli osobních počítačů ovládá většinu trhu s operačními systémy různými verzemi svého operačního systému MS Windows. Operační systémy konkurenčních firem se na celkovém prodeji podílejí velmi malým procentem. Na poli serverových operačních systémů již situace tak jednoznačná není. U síťových serverů jsou přece jenom odlišné požadavky a nároky než na pracovní stanice uživatelů. V kategorii serverových operačních systémů se kromě systému MS Windows 2000 Server Edition (popř. Enterprise Edition) těší veliké oblibě různé systémy vycházející ze systému Unix (např. komerční systém Solaris, volně šířený Linux). V kategorii kancelářského software je v drtivé většině případů nasazován balík kancelářského software Microsoft Office. Balík obsahuje textový procesor, tabulkový kalkulátor, jednoduchou relační databázi, program pro tvorbu prezentací a osobní organizér (elektronická pošta, kartotéka kontaktů, plánovací kalendář, seznam úkolů). Dokumenty ve formátu MS Office se staly de facto standardem při elektronické výměně dokumentů, proto se konkurence přizpůsobila a kromě vlastních formátů dokumentů jsou její produkty schopné číst a zapisovat dokumenty ve formátu MS Office. Příkladem konkurenčního kancelářského balíku je produkt PC Suite do firmy Software602 nebo zdarma šířený balík programů StarOffice vyvíjený firmou Sun. Z důvodu značnému rozšíření kancelářského software jej v současnosti můžeme zahrnovat do základního software. S rostoucím počtem uživatelů Internetu v domácnostech se součástí operačních systémů stávají také aplikace využívající možností, které Internet poskytuje. Všu31

7.2

Trendy v oblasti aplikačního software

dypřítomný je internetový prohlížeč Internet Explorer nebo Mozilla a různí klienti elektronické pošty (MS Outlook Express, Netscape Communicator, mutt). Značně populární jsou nástroje pro rychlé předávání zpráv (instant messaging, např. program ICQ) a software pro sdílení souborů na úrovni peer-to-peer sítí. Lokalizace produktů pro různá národní prostředí a překlady do mnoha jazyků již nejsou něčím výjimečným. Roste provázanost všech aplikací (možnost v jedné aplikaci využívat funkcí poskytovaných jinými aplikací) a také možnosti modifikovat vzhled a chování aplikace podle přání uživatele (použití tzv. skinů nebo témat).

7.2

Trendy v oblasti aplikačního software

Do kategorie aplikačního software je řazeno takové programové vybavení, které již není možné považovat za základní software. Do této kategorie spadají systémy zajišťující oběh a distribuci elektronických dokumentů, specializované aplikace pro práci se zvukem, obrazem nebo videozáznamem, DTP systémy, software řídící technologické procesy a také typový aplikační software. Typový software byl vyvinut nebo upraven na míru a podle požadavků podniku a většinou jej není možné bez velkých zásahů provozovat v jiném podniku. Dobře navržený a provozovaný typový software znamená pro podnik významnou konkurenční výhodu. Plně parametrizovaný typový software umožňuje plné přizpůsobení specifikům podniku pomocí nastavení parametrů. Např. umožňuje nastavení organizační struktury podniku, účetní osnovu, hospodářské celky, výstupní sestavy aj. Možnosti parametrizace se využívají i po nasazení typového software do provozu pro přizpůsobení softwaru měnícím se vnitřním a vnějším podmínkám podniku (např. změna legislativy, změna vnitropodnikových nařízení a postupů). S rostoucími požadavky parametrizace také roste komplexnost a složitost typového software – ten musí být vytvořen tak, aby byl schopen vyhovět všem zadaným parametrům, např. sériová výroba, kusová výroba. Rostoucí složitost je způsobena také značným rozšiřováním počtu funkcí, které software poskytuje, a také využití výpočetní techniky v oblastech, ve kterých se dříve nepoužívala, jako strategické rozhodování nebo marketing. S rozšířeným využíváním třívrstvé architektury systémů se informační systém stává nezávislým na základním softwaru. S možností provozovat jeden informační systém na různých platformách (hardwarových i softwarových) a spolupracovat s různými databázovými systémy vznikají nové příležitosti uplatnění v prostředích, kde dříve provoz nebyl možný z důvodu vazby na jiné prostředí. S rostoucím množstvím kombinací základního a aplikačního softwaru narůstá heterogenita počítačových systémů. Tento trend poskytuje nové příležitosti pro integrující software zajišťující vzájemné propojení systémů. Často je v informačních systémech možnost spolupráce s kancelářským softwarem. Praxe ukazuje, že dodatečné zpracování výstupních sestav v kancelářských aplikacích, je velmi efektivní pro tvůrce informačního systému i pro uživatele. Ze strany tvůrce systému je výstup všech nestandardních sestav realizován výstupem 32

7.3

Trendy v oblasti informačních technologií

do kancelářského software. Další zpracování sestavy je pak na uživateli, který si sestavu přizpůsobí vlastním potřebám. Velikou výhodou pro uživatele je skutečnost, že pracuje v prostředí, které je mu známé.

7.3

Trendy v oblasti informačních technologií

Celkovým trendem v informačních technologiích v současnosti je snaha o standardizaci na základě všeobecně uznávaných mezinárodních standardů, norem a doporučení. Dobrým příkladem je mezinárodní počítačová síť Internet pracující na základě rodiny protokolů TCP/IP, vzájemná kompatibilita operačních systémů je dána normou POSIX, komunikace s databázovými systémy se uskutečňuje jazykem SQL, objektově orientovaná aplikační prostředí sdílejí komponenty využitím architektury CORBA nebo COM/DCOM. Využívání standardů výrobci softwaru podporují nezávislost programových systémů na konkrétní platformě. Celosvětově je znát trend posunu od jednovrstvé architektury k třívrstvé architektuře aplikačního software. Původní monolitické systémy jsou nahrazovány systémy, které mají oddělenou databázovou vrstvu, aplikační vrstvu a prezentační vrstvu zprostředkovávající komunikaci s uživatelem. Jednotlivé vrstvy mezi sebou komunikují pomocí dohodnutého rozhraní (API – Application Programming Interface), které se obvykle zakládá na některém obecném standardu (volání knihovních funkcí API, výměna strukturovaných dat např. ve formátu SGML nebo XML). Využití rozdělení systému na jednotlivé vrstvy a použití standardních komunikačních rozhraní také umožňuje nahradit libovolnou vrstvu informačního systému, např. při posilování výkonu. Významným směrem je oddělení aplikační logiky od uživatelského rozhraní (v třívrstvém modelu architektury se jedná o prezentační vrstvu). Uživatel má možnost prostřednictvím vlastních personalizačních nastavení ovlivňovat způsob, jakým se vůči němu informační systém chová (tedy nastavení prezentační vrstvy), ale současně uživatel nemůže ovlivnit aplikační vrstvu (např. podnikové procesy). Stále častěji jsou na prezentační vrstvě využíváni tzv. tencí klienti. Tenký klient se rozumí aplikace nebo zařízení sloužící pouze pro vstup dat a prezentaci výsledků, např. webový prohlížeč nebo wapový klient v mobilním telefonu. Použití tenkých klientů přináší značné úspory při zavádění a následné údržbě informačního systému – internetový prohlížeč je součástí základního software, opravu a inovaci aplikací je možné provést pouze na jednom místě a není nutné provádět aktualizaci na klientských stanicích. Trendem je opouštění centralizovaného zpracování dat, při kterém veškeré funkce jsou řízeny jediným výkonným počítačem, k distribuovanému zpracování dat. Při distribuovaném zpracování jsou data a funkce rozprostřeny po komunikační síti, klient komunikuje s nejbližším serverem a ten podle požadavků a svých možností poskytuje data nebo zprostředkuje přesměrování na další servery. Pozitivem distribuovaného zpracování jsou nižší náklady na vybudování výpočetního systému než

33

7.4

Trendy v metodice a vývoji informačních systémů

jeden vysoce výkonný server, při distribuovaném zpracování je výhodou i redundance jednotlivých komponent a tím zajištěná větší spolehlivost celého systému. V hardwarovém vybavení je také patrný posun ke standardním rozhraním. Tato rozhraní v minulosti vznikala jako aktivity jednotlivých výrobců, ale v současné době je patrná snaha výrobců postupovat při návrhu komunikačních rozhraní společně. Došlo k rozšíření rozhraní USB (Universal Serial Bus) pro připojování rozmanitých periferií (tiskárny, skenery, digitální fotoaparáty, čtečky paměťových karet, joysticky), výrobci grafických subsystémů začali používat profesionální knihovnu pro prostorovou grafiku OpenGL, víceprocesorové systémy založené na architektuře IA32 (32-bitové procesory výrobců Intel, AMD a VIA) používají standardní rozhraní SMP (Symmetric Multiprocessing) a existuje celá řada dalších případů.

7.4

Trendy v metodice a vývoji informačních systémů

Při vývoji informačních systémů je možné pozorovat odklon od sekvenčního vývoje postupným řešením fází specifikace zadání, analýzy a návrhu systému. Nové nástroje a metodiky podporují inkrementální vývoj systému. Je patrná snaha o rychlý vývoj, s tím spojená snaha o ochranu investic a zajištění vysoké spolehlivosti. Objektově orientovaný přístup Při vývoji informačních systémů a softwaru obecně je znatelný posun od strukturovaného přístupu směrem k objektově orientovanému přístupu, který věrněji reprezentuje skutečný svět. Pojmem objekt označujeme reálnou entitu, jejíž chování budeme modelovat. Každý objekt má definovanou množinu vlastností (atributů) a množinu činností, které je možné s objektem provádět. Souhrnně se činnosti objektu označují pojmem chování objektu. Jednotlivé činnosti pak znamenají změnu vnitřních vlastností (atributů) objektu, komunikace mezi objekty je potom sled činností jednotlivých objektů za účelem změny vlastností do požadovaného stavu. Pojmem třída objektů označujeme obecnou množinu všech objektů majících společné vlastnosti a chování. Instancí objektu se pak rozumí konkrétní objekt. Například třídou objektů je tiskárna (obecné zařízení schopné tisku dokumentů s atributy způsob tisku, barevná/monochromatická, komunikující určitým jazykem), instancí objektu třídy tiskárna je potom objekt tiskárny Hewlett-Packard DeskJet 690C (inkoustová tiskárna, barevná, komunikačním jazykem je PCL 3). V objektově orientovaném přístupu jsou definovány tři základní principy: • zapouzdření, • dědičnost, • polymorfismus. Zapouzdření je snaha skrýt vnitřní strukturu objektu před okolním světem. Smyslem je zabránit přímé změně vnitřních stavů objektu a udržení konzistent-

34

7.4

Trendy v metodice a vývoji informačních systémů

ního stavu. Jediným korektním způsobem komunikace je prostřednictvím veřejně přístupných metod objektu, které zajistí správnou změnu stavu objektu. Dědičnost je v reálném světě přechodem vlastností z rodiče na potomka a stejně tak je tomu i v případě objektů, kde objekt získává všechny vlastnosti (atributy) a chování (metody) od svého předka. Možný je i případ vícenásobné dědičnosti, pak objekt získává vlastnosti a chování od všech svých předků. Polymorfismus znamená možnost použití různých objektů stejným způsobem. Příkladem ilustrujícím polymorfismus jsou geometrické objekty úsečka, obdélník a kružnice. Každý z uvedených objektů pak obsahuje metodu kresli() a při jejím volání dojde k vykreslení obrazce odpovídajícího tvaru podle cílového objektu. Polymorfismus je využíván mechanismem pozdní vazby. Pozdní vazba vytváří vazby mezi objekty až v okamžiku běhu programu, to znamená, že můžeme volat metodu kresli() abstraktního objektu, který je společným předkem objektů úsečka, obdélník a kružnice, a vazba na konkrétní instanci objektu je vyhodnocena až v době volání metody objektu. V objektově orientovaném přístupu se často setkáváme také s pojmy konstruktor a destruktor. Konstruktorem objektu je metoda třídy objektu, která způsobí vznik objektu. Běžně se v konstruktoru inicializují atributy objektu do počátečního stavu. Destruktorem objektu je metoda objektu, která způsobí jeho zánik. Objektově orientovanému programování se věnuje řada publikací. Za všechny uvedu knihu o objektově orientovaném programování v prostředí jazyka C++ (Virius, 2000). Nástroje pro vývoj informačních systémů Při snaze o rychlý vývoj informačních systémů se prosazují nástroje umožňující rychlý vývoj aplikací i jejich prototypů (nástroje RAD – Rapid Application Development) a také nástroje podporující návrh systémů (nástroje CASE – Computer Aided System Engineering). Uvedené nástroje používají všechny významné společnosti působící v oblasti informačních systémů. Dříve jednotlivé CASE nástroje podporovaly pouze určitou fázi životního cyklu projektu, ale jsou patrné snahy o tvorbu CASE nástrojů schopných pokrýt celý životní cyklus od budování informační strategie až po uvedení systému do provozu. Integrované řešení celého projektu v jednom nástroji také umožňuje nasazení řady kontrol na konzistenci projektu a případné upozornění na možné nedostatky. Je rozšiřován počet metodik použitelný v jednom CASE nástroji. Tato vlastnost je důležitá při návrhu integrace různých dílčích systémů v podniku, které byly navrženy při použití rozdílných metodik.

35

8

Analýza současného stavu UIS

Po pozitivní odezvě na pilotní projekt Fakultního informačního systému na Provozně ekonomické fakultě bylo vedením univerzity rozhodnuto o vývoji informačního systému schopného provozu na všech jejích fakultách. Nový informační systém měl především řešit studijní agendu jednotlivých fakult a další návazné agendy se studiem spojené. Univerzita zajišťuje vývoj a provoz Univerzitního informačního systému ve vlastní režii, důvody jsou uvedeny v oddílu 6.6. Univerzitní informační systém hojně využívá možnosti parametrizace – ta umožňuje tvořit aplikace společné všem fakultám a fakulty si chování aplikací přizpůsobí nastavením parametrů. Tento způsob tvorby aplikací je náročnější na práci při jejich návrhu, ale zjednodušuje následný provoz aplikací v měnícím se fakultním prostředí.

8.1

Vrstvená architektura

Univerzitní informační systém je navržen podle zásad třívrstvé architektury tak, jak byla popsána v kapitole 3 na straně 17. Databázová i aplikační vrstva jsou zajišťovány na straně serveru, prezentační vrstva využívá jako tenkého klienta internetový prohlížeč. Při podrobnějším pohledu na systém a jeho vrstvy je možné rozlišit jednotlivé vrstvy ještě jemněji. Interní členění vnitřní struktury Univerzitního informačního systému: • aplikace, • jádro informačního systému, • Perl a moduly, TEX a styly dokumentů, • operační systémy a databázový systém, • hardwarové vybavení. Nejnižší vrstvou je hardware databázových a aplikačních serverů, síťové prvky, zařízení podporující sledování vnějšího prostředí, zdroje záložního napájení a další. Operační systémy a databázový systém tvoří další vrstvu nad hardwarovým vybavením. Jedná se o první vrstvu softwarového vybavení zajišťující správný chod technického vybavení. K této vrstvě patří také všechny programy, které je možné považovat za základní software. Databázový systém je základním programovým vybavením poskytujícím jednotné rozhraní pro práci s daty. Za další samostatnou vrstvu je možné považovat programovací jazyk Perl, ve kterém je Univerzitní informační systém programován, spolu s obrovským množstvím modulů, které značně rozšiřují množství poskytovaných funkcí. Tyto moduly jsou udržovány svými autory a soustředěny v síti archívů CPAN (Comprehensive Perl Archive Network). Na stejné úrovni hierarchie vrstev jako Perl je i sázecí systém TEX – pomocí TEXu jsou sázeny veškeré tiskové výstupy z UIS. Možnosti TEXu je možné také dále 36

8.1

Vrstvená architektura

rozšiřovat balíky maker (např. makra pro sazbu čárového kódu) nebo definovat zcela nové styly dokumentů (např. seznamy studentů nebo imatrikulační listy). Rozšiřující balíky a pomocné nástroje jsou shromažďovány v síti archívů označované CTAN (Comprehensive TEX Archive Network). Styly dokumentů pro výstup z Univerzitního informačního systému byly vytvořeny vývojovým týmem UIS, především úsilím doc. Jiřího Rybičky a Jana Přichystala. Perl i TEX není již možné považovat za základní software, který je součástí každého operačního systému, ale patří mezi aplikační softwarové vybavení. Oba programy jsou dostupné pro značné množství systémů odvozených od Unixu a také pro platformu Windows. Tím je dán stabilní základ pro budování informačního systému a možnost jeho provozování v různých prostředích. Jádrem Univerzitního systému rozumíme perlové moduly poskytující aplikacím knihovny funkcí. Používání modulů umožňuje rychlý vývoj aplikací (tvůrce aplikace využí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í se s novými aplikacemi. Opakované použití funkcí v modulech znamená menší chybovost aplikací – jsou využívány ověřené funkce, ve kterých by již měly být chyby odstraněny. Nové chyby se pak mohou objevit pouze v nově programovaných částech aplikací. Nad moduly jádra systému jsou již jednotlivé aplikace poskytující uživatelům požadovanou funkcionalitu. Byla vytvořena hierarchická struktura odpovídající řešení různé problematiky. Základním prvkem systému je aplikace, která je realizována jedním nebo více skripty. Aplikace řešící podobnou problematiku nebo různé části jedné agendy jsou sdružovány do rodin aplikací. Studijní agenda

vysvetleni.pl

zadani zadosti.pl

Zápis

zapis.pl

Skript

vysledky predmetu.pl

Studijní evidence

prubeh studia.pl

Aplikace

evidence.pl

Rodina aplikací

Obr. 9: Hierarchická struktura aplikací Příkladem rodiny aplikací je Evidence karet vydávaných univerzitou nebo ro37

8.2

Popis technického řešení

dina aplikací Studijní agenda. Aplikací z rodiny Studijní agenda je pak Studijní evidence, která umožňuje studijní referentce pracovat s údaji o studiu zaznamenanými u daného studenta nebo aplikace Zápis, která studenta postoupí do dalšího období studia. Aplikace Studijní evidence je pak složena ze skriptů evidence.pl, vysledky_predmetu.pl a dalších. Schéma hierarchie je ilustrováno obr. 9.

8.2

Popis technického řešení

Pro dosažení maximální dostupnosti (high availibility), spolehlivosti (robustní řešení) a rychlosti odezvy informačního systému bylo při návrhu hardwarové architektury zvoleno clusterové řešení. Clusterové řešení poskytuje několik významných výhod oproti použití jediného výkonného serveru: • redundance komponent – vysoká spolehlivost a robustnost je zajištěna použitím více stejných komponent tak, aby při poruše byla vadná komponenta automaticky detekována a redundantní komponenta přebrala roli původní. Při hardwarové závadě jednoho z počítačů je velmi jednoduché vyřadit vadný počítač z clusteru a po návratu ze servisu jej včlenit zpět. Celek není vyřazením jednoho stroje ovlivněn. Při závadě na jediném serveru by byl celý systém vyřazen z provozu. • skutečné paralelní zpracování – počítače třídy PC je možné osadit maximálně čtyřmi procesory, většími počty procesorů je možné vybavit servery firem Sun, SGI a IBM. V clusteru je možné spojit libovolný počet počítačů a neexistuje omezení dané architekturou použitých počítačů. V případě UIS se pak aplikační servery chovají jako jeden čtrnáctiprocesorový server. • škálovatelnost – velmi dobré možnosti dodatečného rozšíření výkonu clusteru zapojením dalších počítačů. U serverů střední a vyšší třídy se rozšiřování provádí prostřednictvím procesorových desek, ale jejich počet je omezen. Obr. 10: Kompletní sestava • pořizovací cena systému – cena jednoho běžUIS clusteru ného počítače se pohybuje okolo 20 tisíc Kč, cena clusteru tvořeného několika PC se pohybuje v řádu statisíců korun. Ceny výkonných serverů Sun nebo SGI jsou v řádu jednotek až desítek milionů Kč. Obdobně závratné jsou i ceny procesorových desek do těchto serverů. 38

8.2

Popis technického řešení

Vstupním bodem celého clusteru je firewall zajišťující ochranu vnitřních komponent clusteru a provádějící přesměrování požadavků dovnitř clusteru pro určité definované služby (např. přístup k databázi ze stravovacího systému Anete). Firewall je připojen k páteřní síti MZLU 1Gbitovým datovým spojem a záložní 100Mbitový spoj je připojen pro případ, že dojde k výpadku hlavního spoje. Na firewallu je provozován paketový filtr, systém detekce napadení (IDS – Intrusion Detection System), DNS server pro vnitřní komponenty clusteru, dále zde probíhá sběr a vyhodnocování systémových hlášení z ostatních komponent clusteru s ohledem na bezpečnost celého systému. Firewall také slouží jako rozdělovač požadavků uživatelů na jednotlivé aplikační servery. Aplikační server je tvořen clusterem 14 standardních počítačů PC, na které jsou firewallem rozkládány požadavky uživatelů. Při přístupu k UIS dostane uživatel „přidělenÿ jeden stroj z aplikačního clusteru a ten pak tohoto uživatele obsluhuje. Na všech aplikačních serverech je pomocí programu rsync udržována lokální kopie aktuálních modulů a skriptů UIS, které jsou určeny pro ostrý provoz. Na obr. 10 je vidět kompletní sestavu aplikačních serverů. Postupně shora je ve skříni namontován RMS systém, síťový switch (detail na obr. 12), čtrnáct aplikačních serverů, police pro modemy (na fotografii nejsou modemy osazeny), firewall clusteru, stroj pro vývojáře (zřetelně viditelný páskový robot) a nejníže je vidět část záložního zdroje. Databázový server poskytuje data aplikačním serverům. Hlavní databáze běží na stroji Sun Fire 880, jako záloha je použit stroj Sun Enterprise 220R. Oba servery jsou vybaveny hot-swap pevnými disky, tudíž je možné je vyměnit za chodu serveru a není nutné jej vypínat. Fotografie databázového serveru je na obr. 11. Vývojářský stroj slouží pro práci vývojářů při vývoji UIS. Je osazen páskovým robotem pro tvorbu zálohy systému a dále multiportovou kartou Cyclom Cyclades 16YeP, která umožňuje připojit až 16 zařízení se sériovým rozhraním. K multiportové kartě je připojeno šest modemů a dále sériové konzoly databázových a aplikačních serverů. Použitím sériových linek Obr. 11: Databázový server je zajištěno alternativní propojení na vnitřní kompoSun Fire 880 nenty clusteru v případě výpadku nebo při poruše síťové konektivity. Propojení pomocí sériových linek je využíváno výhradně pro servisní zásahy na stroji při výpadku síťového spojení (neslouží tedy jako náhradní datový spoj pro běžný provoz serveru). Síťovým propojovacím prvkem je 48 portový switch Cisco Catalyst 2950 se dvěma rozšiřujícími moduly pro připojení gigabitových linek. Na obr. 12 je zachycen switch (druhý shora) spolu s řídícím prvkem sledování stavu prostředí (RMS) a jedním z aplikačních serverů (bílý počítač Mercury). 39

8.3

Použitý software

Obr. 12: Systém RMS, síťový prvek a aplikační server Napájení je podpořeno dvěma zdroji záložního napájení APC SmartUPS (každý o kapacitě 5 kVA), které jsou schopny udržet systém v chodu i při výpadku napájení. Elektřina je rozvedena pomocí APC Master Switch, umožňující na dálku přes síťové spojení vypnout a opět zapnout napájení na připojených zásuvkách. Všechny součásti clusteru s výjimkou databázových serverů jsou namontovány ve standardizované skříni pro montáž přístrojů (rack) šířky 19” a výšce 41U (cca. 210 cm). Skříň je uzamykatelná a existuje široké spektrum různých doplňků (různé police, lampy, klávesnice), kterými je možné skříň přizpůsobit. Výhodou umístění počítačů do skříně je efektivní využití prostoru. Skříň je vybavena zařízením pro sledování stavu vnitřního prostředí (RMS – Rack Monitoring System) firmy Kn˝ urr s čidly otevření dveří, snímačem teploty a vlhkosti a kouřovým čidlem. Uvedené zařízení umožňuje monitorovat stabilitu vnitřního prostředí, tím přispívá k zajištění fyzické bezpečnosti celé sestavy. Zálohování aplikací a databáze se provádí jednou denně na dva servery umístěné v budově E (místo vzdálené od původního systému je vhodné zajištění při živelné pohromě). Jednou týdně je uložena záloha systému také na CD-R médium ve dvou kopiích. Jedna kopie zůstává u vedoucího vývoje, druhá kopie je uložena mimo areál školy, tzv. off-site záloha (opět je důvodem fyzická bezpečnost zálohy).

8.3

Použitý software

Operační systémy Operačním systémem na firewallu, aplikačních serverech a vývojovém stroji byl zvolen Linux – volně šiřitelná implementace operačního systému Unix. Linux umožňuje vzdálenou zprávu, je výkonný a stabilní, objevené bezpečnostní chyby v jádře systému nebo v některé z aplikací jsou velmi rychle opravovány (většinou v době oznámení o nalezení chyby na diskusních fórech již existuje oprava). Značné rozšíření Linuxu a veliká uživatelská základna vytváří předpoklady dobré podpory při řešení nestandardních situací. Na databázových serverech je nainstalován operační systém Solaris – verze Unixu vyvíjená firmou Sun Microsystems pro své pracovní stanice a servery. Na-

40

8.3

Použitý software

sazení systému Solaris umožňuje plně využít všech pokročilých vlastností serverů Sun. Databázový systém a databázové nástroje Jako databázový systém je používán SŘBD Oracle Standard Database Release 9i. Součástí instalace programového balíku databáze Oracle je i databázová konzola SQL Plus pracující v textovém režimu (pro obsluhu databáze pak postačuje libovolný textový terminál). Další součástí databázového systému je program DBA Studio, které poskytuje grafické uživatelské rozhraní k ovládání databáze. Nástroj SQL Plus není příliš uživatelsky přívětivý, proto je při vývoji UIS používána databázová konzola dbMan. Program dbMan poskytuje značný uživatelský komfort, jakým je editovatelná historie příkazů, doplňování příkazů a názvů tabulek nebo různé možnosti formátování výstupu. Program dbMan vznikl jako bakalářská práce ing. Milana Šorma (Šorm, 1999) a je stále vyvíjen a rozšiřován podle potřeb uživatelů (Šorm, 2002b). Programovací jazyk Programovacím jazykem pro implementaci Univerzitního informačního systému byl zvolen jazyk Perl. Jazyk byl navržen tak, aby umožnil dělat jednoduché věci jednoduše a přitom neznemožňoval provádět složité úlohy. Má velmi volnou syntaxi, usnadňuje manipulaci s texty a čísly a je velmi populární při tvorbě dynamických webových stránek. Existuje pro něj značné množství rozšiřujících modulů, díky své rozšiřitelnosti umožňuje velmi rychlý vývoj aplikací. Je hybridem mezi interpretovaným a kompilovaným jazykem – navenek se jeví jako interpret, uvnitř se jedná o kompilátor. Perl původně vznikl v prostředí operačního systému Unix, ale v současnosti běží také na mnoha jiných systémech včetně MS Windows a MacOS. Perlu se věnuje řada knih a dobrým výchozím bodem při studiu Perlu je rozhodně kniha Programování v jazyce Perl (Wall, 1997). Webový server Webovým serverem byl pro své vlastnosti vybrán server Apache. Apache vychází ze serveru NCSA a přebral od něj řadu vlastností. Apache je stejně jako Linux volně šiřitelný, pro své skvělé vlastnosti je nejpoužívanějším webovým serverem v prostředí Internetu. Základní vlastnosti serveru je možné dále rozšiřovat velkým množstvím již existujících doplňujících modulů nebo si vytvořit vlastní rozšíření. Rozšiřující modul mod_perl integruje programovací jazyk Perl do prostředí webového serveru Apache. Při startu Apache jsou také nahrány a zkompilovány programové moduly tvořící jádro Univerzitního informačního systému. Moduly jsou pak udržovány v paměti v kompilované podobě a nové zavedení se provádí pouze v případě, že je detekována přítomnost novější verze modulu. 41

8.3

Použitý software

Při provádění skriptů jsou skripty kompilovány pouze při prvním spuštění a dále je uchovávána jejich zkompilovaná podoba. Cachování skriptů tímto způsobem velmi významně přispívá k rychlosti odezvy v porovnání s použitím samostatného Perlu (bez modulu mod_perl v Apache). V tom případě by při každém spuštění skriptu byl spuštěn Perl, ten by načetl skript a moduly, které používá, a po jejich zkompilování a spuštění by vrátil výsledek. Použitím modulu mod_perl se všechny fáze provedou pouze jednou a všechny další požadavky znamenají pouze spuštění zkompilovaného kódu. Díky tomu nejsou odezvy prodlužovány o dobu potřebnou ke kompilaci a rychlost je srovnatelná s kompilovanými jazyky. Pro zajištění bezpečné komunikace mezi klientem a Univerzitním informačním systémem je nainstalován a používán modul webového serveru implementující protokol SSL (Secure Socket Layer). V průběhu komunikace je využívána symetrická šifra (tj. pro kódování i dekódování je použit stejný klíč), protože není tak náročná na výpočetní výkon komunikujících partnerů jako při užití asymetrické šifry (tj. použití jednoho klíče pro zakódování zprávy a jiného pro její následné dekódování). Pro bezpečnou výměnu šifrovacího klíče mezi oběma stranami je použita asymetrická šifra. Spojení vytvořené použitím SSL lze považovat za bezpečný komunikační kanál v prostředí počítačové sítě, kterou nelze považovat za bezpečnou. Přenášená data není možné odposlouchávat a také není možné provést útok na komunikaci směřující k podvržení zasílaných zpráv. Zabezpečení důvěrné komunikace je velmi důležité, protože při práci s Univerzitním informačním systémem jsou často přenášeny citlivé informace. Tiskové výstupy Pro sazbu tiskových výstupů byl zvolen systém TEX vyvinutý Donaldem Knuthem s nadstavbou LATEX. TEX poskytuje vysoce kvalitní tiskové výstupy, pracuje stejným způsobem jako překladač – podle popisu ve zdrojovém textu vytváří soubor určený pro tisk. Díky dávkovému způsobu práce není nutná interakce s uživatelem jako u WYSIWYG sázecích systémů (např. Quark Xpress). V TEXu je možné definovat styly sázených dokumentů a potom je velice snadné produkovat požadované výstupy. Například při tisku potvrzení o studiu je TEXu předáno jméno studenta, program a obor studia a fakultu, na které studuje, a připravený styl zajistí vysazení čtyř potvrzení na jednu stránku papíru. Tím je zajištěn jednotný vzhled produkovaných výstupů a usnadněna jejich tvorba. Pro základní seznámení jsou vhodné knihy LATEX pro začátečníky (Rybička, 1999) nebo kniha Typografický systém TEX (Olšák, 1995). Tisk z UIS může být směrován na tzv. virtuální tiskárny produkující dokumenty ve formátu PDF nebo PostScript. Při tomto výstupu je na serveru vytvořen výsledný soubor v požadovaném formátu a výsledek je odeslán klientovi. Další zpracování je závislé na místním nastavení a přání uživatele – soubor může být otevřen

42

8.4

Datová architektura

v prohlížeči dokumentů nebo uložen na disk. Obě virtuální tiskárny jsou dostupné všem uživatelům Univerzitního informačního systému a není potřeba je instalovat. Druhou možností je tisk na tiskárnu nainstalovanou u klienta. Tiskový výstup je uložen do PostScriptu a následně zpracován programem GhostScript, který převede PostScriptový dokument na formát tisknutelný na lokální tiskárně uživatele (provede tzv. rastrování dokumentu). Vyrastrovaný dokument je následně odeslán na tiskárnu uživatele a vytištěn. Při požadavku uživatele na tento způsob tisku si uživatel musí tiskárnu nainstalovat do prostředí Univerzitního informačního systému. Podrobnější popis tiskového subsystému byl zveřejněn ve sborníku Informatika VII (Šorm, 2000).

8.4

Datová architektura

Jak již bylo řečeno, data v Univerzitním informačním systému jsou spravována systémem řízení báze dat Oracle 9i. Celkem jsou používaná tři datová schémata: • uis pro přístup k ostré databázi, • stable je schéma jednou týdně synchronizované s ostrou databází a sloužící pro vývoj, • unstable sloužící taktéž vývoji, ale není pravidelně synchronizována s ostrou databází. Fyzický datový model v současnosti obsahuje téměř šest set tabulek obsahujících veškerá data uchovávaná v UIS. Aby byla usnadněna orientace v těchto tabulkách, byl zaveden systém předpon (prefixů) a přípon k základnímu názvu tabulky. Díky zavedené konvenci je možné se v databázovém schématu rychleji orientovat. Předpony tabulek Každá tabulka je součástí nějakého většího celku (rodiny aplikací) a na základě příslušnosti tabulky k rodině aplikací je jí přiřazen jednopísmenný prefix. Původní rozdělení prefixů od svého vzniku doznalo určitých mírných změn, ale přiřazení prefixů je stabilní. Aktuální rozložení prefixů a jim příslušné celky je v tab. 1. Za písmenem prefixu může následovat písmeno určující zvláštní význam tabulky. Pokud není písmeno označující význam tabulky uvedeno, plní tabulka roli asociativní vazby. Používané písmenné identifikátory jsou shrnuty v tab. 2. Pro lepší čitelnost jsou prefixy a přípony od základního jména oddělovány znakem podtržítko. Použití prefixů bude předvedeno na tabulce obsahující číselník specializací studijních oborů. Tabulka obsahující tento číselník je označena SC_SPECIALIZACE. První písmeno (S) indikuje příslušnost tabulky do studijního systému, druhé písmeno (C) označuje tabulku obsahující základní číselník a řetězec SPECIALIZACE je základní jméno tabulky bez prefixu. Někdy se používá pro jemnější rozlišení ještě dalších předpon vkládaných před základní název tabulky. Např. tabulky, jejichž název začíná MC_KREDIT_ jsou tabulky s číselníky stravovacího systému Kredit společnosti Anete nebo CC_DUHA_ jsou tabulky obsahující číselníky přístupového systému. 43

8.4

Prefix A B C D F I K M N P Q R S T V W Y

Datová architektura

Rodina aplikací Vývoj systému Dočasné a pokusné tabulky Centrální aplikace, karty, kamery a DUHA Dokumentace Právní systém Inventarizace a výpůjčky věcí Kmenové tabulky a zákl. číselníky, personalistika Koleje a menzy Nástěnky a dokumentový server Poštovní systém Číselníky jiných institucí (SIMS, UIR-ADR) Rozvrhy a rezervace učeben Studijní systém Tiskový systém a výstupní sestavy Vědeckovýzkumný systém Nízkoúrovňové systémové tabulky Personalizace systému Tab. 1: Přiřazení prefixů k rodině aplikací

Prefix bez označení A B C I

Význam Asociativní tabulka Tabulka generovaná automaticky triggery Tabulka obnovená ze zálohy Tabulka obsahující číselník Tabulka obsahující index pro vyhledávání údajů

Tab. 2: Prefixy označující význam tabulky Přípony tabulek Doplněním přípony k názvu tabulky dostáváme názvy dalších pomocných tabulek sloužících k uchování struktur šablon, atributů, záznamů do historie. Význam jednotlivých přípon je uveden v tab. 3. Tabulka KC_UZIVATELE_SABLONA pak obsahuje definici atributů evidovaných o uživatelích a tabulka KC_UZIVATELE_ATRIBUTY obsahuje hodnoty atributů pro jednotlivé uživatele. Tabulky s definicí šablony i tabulky obsahující hodnoty atributů mají vždy shodnou strukturu a tím je zjednodušena práce s nimi – mění se pouze název tabulky, ale sloupce jsou ve všech tabulkách definujících šablony shodné (to platí také pro atributové tabulky). Další informace o šablonách lze nalézt v popisu třídy Sablony na straně 47.

44

8.4

Přípona SABLONA ATRIBUTY HISTORIE

Datová architektura

Význam Definice šablony objektu (někdy zkráceno na SAB) Hodnoty atributů objektů (někdy zkráceno na ATR) Historické záznamy z číselníků (někdy zkráceno na HIST) Tab. 3: Přípony tabulek a jejich význam

Ostatní databázové objekty Označení pro sekvence generující hodnoty primárních klíčů vzniká přidáním přípony SEQ za název příslušné tabulky. Podobně vznikají označení pro triggery definované nad tabulkami. Přípona začíná písmenem T a za ním následuje kombinace písmen podle toho, kdy je trigger spouštěn. Význam jednotlivých písmen je uveden v tab. 4 a jejich přiřazení je provedeno na základě anglických názvů prováděných operací. Písmeno A B D I U

Význam Trigger spouštěný po akci (AFTER) Trigger spouštěný před akcí (BEFORE) Trigger vázaný na operaci mazání (DELETE) Trigger vázaný na operaci vkládání (INSERT) Trigger vázaný na operaci opravy (UPDATE)

Tab. 4: Význam jednotlivých písmen v příponě triggeru Například název triggeru SC_PREDMETY_TIUDA označuje trigger nad tabulkou SC_PREDMETY, který je spouštěn po (A) operaci vložení (I), opravy (U) nebo mazání (D). Také se stalo zvykem označovat balíčky funkcí v jazyce PL/SQL předponou PKG (z anglického názvu těchto objektů – package). Například balíček funkcí pro práci s právním systémem nese název PKG_PRAVA. Při označování nových databázových objektů je dodržováno podobné označení objektů plnících podobnou funkci (např. funkce rozhodující příslušnost různých objektů k subjektům PATRI_UZIVATEL_DO_SUBJEKTU, PATRI_PRACOVISTE_DO_SUBJEKTU apod.). Chytré databázové funkce Označení chytré databázové funkce je třeba chápat jako umístění části aplikační vrstvy informačního systému do databázového systému. Databázový systém je na nejnižší úrovni, na které lze s informačním systémem smysluplně manipulovat4 a proto je databáze vhodným umístěním pro řadu funkcí spadajících do aplikační vrstvy. 4

Přímé čtení souborů, ve kterých jsou uložena data databázovým systémem není možné považovat za racionální přístup k databázi.

45

8.5

Jádro informačního systému

Dobrým příkladem je soubor funkcí poskytovaný balíčkem PKG_STUDIUM. Tento balíček poskytuje funkce pro náročné manipulace se studijní evidencí jako je přestup studenta mezi studijními programy, převod studenta ze starého běhu do nového běhu studia, založení nového studia, ukončení studia apod. Každá z výše uvedených operací zahrnuje řadu kroků, které musí být provedeny v přesném pořadí a není možné žádný z nich vynechat, aby byla zajištěná konzistence dat. Díky uložení těchto funkcí v databázi je možné jednoduše provádět požadované operace jak přes webovou aplikaci, tak i při přístupu k databázi přes databázovou konzolu. Další výhodou umístění určitých funkcí do databáze je možnost automatického vyvolání činností při práci s databází. Typicky jsou automaticky plněny do tabulek informace o tom, kdo a kdy provedl poslední změnu jednotlivých záznamů. Jinou možností je např. při vzniku nového studia automaticky povolit přístup do budov a učeben, kam má právo vstupu.

8.5

Jádro informačního systému

Jak již bylo dříve řečeno, jádro Univerzitního informačního systému je tvořeno několika programovými moduly. Každý modul definuje jednu třídu objektů, proto při následujícím popisu budu o modulech hovořit jako o třídách objektů. Při jejich definici byla snaha o značnou obecnost. Díky velkému množství parametrů jednotlivých metod je možné v široké míře ovlivňovat jejich chování. V následujícím oddílu je uveden stručný popis jednotlivých tříd objektů tvořících jádro Univerzitního informačního systému. Třídy jsou uvedeny v abecedním pořadí. Podrobnější popis jejich rozhraní, metod a způsobu implementace lze najít v diplomové práci Ing. Františka Dařeny (Dařena, 2002). Datum Třída Datum je určená k manipulaci s datovými a časovými údaji. Obsahuje metody pro kontroly správného formátu data a času a metody převádějící časové údaje mezi formátem pro uložení v databázi (není vhodný pro snadné čtení uživatelem) a formátem pro zobrazení uživateli (respektující zažité zvyklosti v českém prostředí, ale nevhodný pro počítačové zpracování – / den .. / měsíc .. / rok . / hodina .:/ minuta .). Formaty Třída Formaty pracuje s formátováním sestav podle obecného popisu dokumentu uživatelem. Formátem se rozumí obecný dokument označkovaný jazykem vycházejícím ze značkování SGML. Určité značky jsou nahrazeny údaji získanými z databáze (např. název předmětu, jméno garanta nebo seznam doporučené literatury) a následně je dokument převeden do výstupního formátu (HTML, TEX). Tato třída je v současné době využívána pouze pro zobrazení sylabů ve veřejném katalogu předmětů, sloužila při prozkoumání možností uživatelsky definovaných výstupů a její další vývoj je nejistý. 46

8.5

Jádro informačního systému

Formular Třída objektů Formular vznikla z důvodu snadné tvorby aplikací sloužící pro práci s tabulkami. V počátcích vývoje bylo třeba vytvořit značné množství podobných aplikací realizujících stejnou činnost – evidence studijních programů, oborů a specializací, způsoby financování a další. Každá z těchto aplikací se skládala z části zobrazující obsah tabulky (číselníku), části zajišťující přidání nové položky do číselníku a části umožňující modifikaci existující položky. Třída Formular v sobě obsahuje všechny metody potřebné pro uvedené činnosti, navíc jsou při vkládání a modifikaci údajů prováděny kontroly správného zadání hodnot. Díky skutečně jednoduché a rychlé tvorbě aplikací při využití třídy Formular jsou možnosti metod neustále rozšiřovány a narůstá počet parametrů ovlivňujících chování těchto metod. Díky faktu, že drtivá většina aplikací je vytvořena použitím této třídy, je chování aplikací Univerzitního informačního systému typizované. Z dlouhodobého hlediska se existence této třídy jeví jako velmi prospěšná a je možné počítat s jejím dalším vylepšováním. Postman Třída Postman poskytuje metody pro odesílání pošty, které jsou využívány ostatními aplikacemi požadujícími služby elektronické pošty. Třída Postman vystupuje v e-mailové komunikaci v roli klienta i v roli serveru. Pošta pro lokální uživatele je ukládána přímo do databáze (a v tom případě funguje jako poštovní server), pro adresáty mimo UIS sestaví e-mailovou zprávu a předá ji k doručení poštovnímu serveru (tedy pracuje v režimu klienta elektronické pošty). Kromě odesílání standardních poštovních zpráv je možné také využít pokročilejších způsobů odesílání zpráv, které by byly při použití běžného poštovního klienta obtížně proveditelné. Je tím myšleno například odesílání tzv. systémových zpráv, které jsou praktickou aplikací EDI. Podrobnější informace o službách poskytovaných modulem Postman byly publikovány v diplomové práci E-mailový informační systém (Stejskal, 2002). Sablony Třída Sablony podporuje použití techniky zvané šablonování. Při šablonování je základní tabulka doplněna o tabulku se specifikací dodatečných údajů (atributů) a tabulku obsahující hodnoty atributů příslušné jednotlivým záznamům ze základní tabulky. Tento způsob uložení umožňuje dynamicky měnit evidované atributy, tedy například pokud je nutné u uživatele evidovat další hodnotu, je velmi jednoduché přidat do definice šablony další atribut a není nutné přidávat nový sloupec do základní tabulky. Detailnější popis šablonování je možné najít v diplomových pracích (Dařena, 2002) a (Šorm, 2002a). Metody obsažené v třídě Sablony poskytují programové rozhraní k mechanismu šablonování. Jsou k dispozici metody zjišťující základní údaje o šabloně a jednot47

8.5

Jádro informačního systému

livých atributech, metody umožňující zobrazení a ukládání jednotlivých atributů a metody na vysoké úrovni abstrakce poskytující jednotné rozhraní pro zobrazení a editaci všech atributů objektu. SuperClass Třída objektů SuperClass je společným předkem všech dalších tříd objektů. SuperClass je abstraktní třídou objektů a byla vytvořena proto, aby všechny budoucí třídy objektů patřící k jádru informačního systému měly společného předka a tím i společné základní vlastnosti. Třída SuperClass definuje konstruktor objektu, metodu umožňující určitou metodu označit jako privátní (tj. metoda může být volána pouze jinou metodou téhož objektu) a metodu vracející jméno skriptu používajícího objekt třídy SuperClass. Tisk_UIS Třída Tisk_UIS zajišťuje tiskové výstupy z Univerzitního informačního systému, sazbu dokumentu a odeslání výstupu v souboru ve formátu PDF nebo PostScript nebo odeslání dokumentu na tiskárnu uživatele tak, jak bylo popsáno v oddílu 8.3. Veškeré tiskové výstupy jsou zaznamenávány do tabulky T_LOG. V záznamech je uvedena informace kdo provedl tisk, na které tiskárně, velikost tiskové úlohy (uváděná v bajtech i stránkách) a odkaz na záznam v tabulce W_LOG spojený s tiskovou úlohou. Další možností záznamu informace je tisk čárového kódu tiskové operace do paty dokumentu. Tím je možné zjistit původ vytištěného dokumentu. UIS Třída objektů UIS je základním stavebním kamenem všech skriptů. Na existenci této třídy objektů závisí správný chod všech skriptů, protože implementuje všechny metody nezbytně nutné po korektní běh skriptů. Třída UIS poskytuje základní rozhraní mezi ostatními třídami objektů jádra systému od konkrétních použitých programových prostředků. Při změně některé z podpůrných částí dojde pouze k úpravě třídy UIS bez nutnosti zásahu do ostatních tříd. Třída UIS integruje použití následujících modulů: • CGI – modul poskytující funkce pro podporu dynamicky generovaných webových dokumentů. Obsahuje zejména funkce generující HTML kód a řeší získávání a manipulaci s parametry zasílaných z formulářů. • DBI – modul poskytující obecné databázové rozhraní (obdoba ODBC) nezávislé na konkrétním použitém databázovém systému. Komunikace s databází je zajištěna databázovým ovladačem vytvořeným pro danou databázi (např. ovladačem pro SŘBD Oracle je modul DBD::Oracle). • Cz::Cstools – modul slouží pro převod textů mezi různými kódováními češtiny. Podporuje v současnosti nejpoužívanější kódování ISO Latin 2 a Windows

48

8.5

Jádro informačního systému

CP1250 a také celou řadu starších kódování používanou v systémech MS DOS (např. PC Latin 2, KOI 8 ČS nebo kódování bratří Kamenických). Metody poskytované třídou objektů UIS je možné rozdělit podle poskytované funkcionality do několika kategorií: • Základní funkce jsou nezbytné pro správnou funkčnost aplikací a používají se v každé instanci objektu. Do kategorie základních funkcí patří konstruktor třídy (inicializuje objekty CGI, vytváří spojení s databází, zaznamenává spuštění skriptu do databáze) a destruktor objektu (odeslání výsledného dokumentu klientovi, ukončení transakcí a uzavření spojení s databází). • Designové funkce odstiňují autora aplikace od designu jednotlivých prvků stránky a od zápisu HTML kódu přímo v aplikaci. Jejich použití zajišťuje jednotný vzhled standardních prvků stránky. Pro příklad uveďme metodu titulek(), která vždy generuje nadpis pevné velikosti a zajistí jeho podtržení. Při změně designu je pak možné upravit pouze tyto funkce a není třeba opravovat všechny aplikace. • Databázové funkce zjednodušují komunikaci s databází v porovnání s přímým použitím rozhraní DBI. Nejčastěji používanými metodami jsou select() a do() pro získávání údajů z databáze a provádění SQL příkazů. Další databázové funkce podporují ovládání transakcí – zahájení transakce a potvrzení (commit) nebo zrušení (rollback) transakce. • Funkce právního systému poskytují informace o oprávněních, která byla uživateli přidělena, a také na jaký subjekt mu dané právo bylo přiděleno. Například studijní referentka potřebuje právo pracovat se studijní agendou, ale pouze na své příslušné fakultě. • Kontrolní a bezpečnostní funkce umožňují zaznamenávat údaje do auditních záznamů v databázi a poskytují funkce implementující serializaci. Auditní záznamy umožňují zaznamenávat důležité události v systému v podobě čitelné člověku, ale jsou pouhým doplňkem k záznamům vedených o každé operaci uživatele (záznamy v tabulce W_LOG). Mechanismus serializace je popsán v (Šorm, 2002a) na straně 59. • Funkce získávající jednoduché informace slouží pro zobrazení běžných informací jako jméno uživatele na základě předaného uživatelského čísla nebo název zadaného pracoviště s hypertextovým odkazem na podrobné informace o pracovišti. • Ostatní funkce nezařazené v předchozích kategoriích jsou funkce pro získávání hodnot parametrů předaných z formulářů a funkce pro převod kódování češtiny. Vyber Třída objektů Vyber implementuje způsob vkládání údajů z rozsáhlých číselníků podle zadaného vyhledávacího vzorku. Vložení hodnoty z číselníku s malým počtem položek je možné prostřednictvím rozbalovací nabídky. Při velkém počtu možných položek (např. číselník uživatelů obsahuje tisíce položek) je výhodnější nejprve výběr možných variant omezit určitým vyhledávacím vzorkem. 49

8.6

Potřeby a návrhy dalšího rozvoje

Celý postup zadání vzorku, omezení výběru a nabídky možných variant je shodný pro všechny údaje zadávané tímto způsobem. Výběr typu vkládané hodnoty se provádí při volání konstruktoru objektu spolu s dodatečnými omezeními (omezení výběru pouze na studenty, omezení na zaměstnance a podobně). Ostatní třídy Kromě výše uvedených tříd objektů jsou aplikacemi využívány specializované třídy sdružující funkce řešící příbuznou problematiku. Jejich smysl lze chápat jako knihovny funkcí implementující problematiku přidělování termínů zkoušek, přijímací řízení, seznamy studentů, sestavu V7, uživatelské rozhraní poštovního systému a mnoho dalších.

8.6

Potřeby a návrhy dalšího rozvoje

V průběhu provozu a vývoje aplikací Univerzitního informačního systému byly získány značné zkušenosti, na základě kterých je možné zhodnotit stávající stav a navrhnout možná vylepšení. Hardware Cluster je v provozu od listopadu 2002 a podle situace při nárazových akcích jakými jsou registrace a zápisy studentů se ukazuje, že stávající kapacita aplikačních serverů je dostatečná, ale úzkým místem je databázový server. Proto bylo v roce 2003 v rámci transformačního a rozvojového projektu přistoupeno k rozšíření databázového serveru o další procesorovou kartu. Pro provoz databázového systému pak bude nutné dokoupit další licence SŘBD Oracle. Z hlediska odborného zajištění správy databázového systému by bylo vhodné vyslat pracovníky datamanagementu na odborné školení. Preferované zaměření odborných školení je oblast zálohování databáze a problematika ladění výkonu databáze (indexování tabulek, optimalizace provádění dotazů a další). Jádro informačního systému Metody generující HTML kód v jádře Univerzitního informačního systému nereflektují moderní směry ve vývoji webových standardů. HTML kód generovaný modulem UIS se blíží standardu HTML verze 4, ovšem využití možností např. kaskádových stylů je téměř nulové. K této situaci navíc přispívá fakt, že HTML kód je generován modulem UIS a ne modulem CGI, který vznik nových standardů respektuje a přizpůsobuje se jim. Pro nápravu situace by bylo vhodné provést revizi modulu UIS a generování svěřit modulu CGI. Žádoucím stavem je produkovat kód stránek odpovídající aktuální verzi standardu XHTML s patřičným využitím kaskádových stylů.

50

8.6

Potřeby a návrhy dalšího rozvoje

Dále by měla proběhnout optimalizace počtu SQL dotazů do databáze. Často dochází k nadbytečnému opakovanému dotazování do databáze. Počet dotazů je možné snížit sdružením několika dílčích dotazů do jediného. Další možností je uchovávání výsledků předchozích dotazů v paměti u takových dotazů, kde za doby běhu skriptu nedojde ke změně zjišťovaných údajů (např. při požadavku na jméno uživatele je málo pravděpodobné, že dojde k jeho změně). V aplikacích roste počet parametrů, které je nezbytně nutné předávat mezi jednotlivými běhy skriptu. V současném jádru je podporován pouze přenos informace o použití změněné identity (delegovaný zástupce, superprávo). Přenos jakýchkoliv dalších parametrů musí řešit autor aplikace. Proto by měl být vytvořen mechanismus umožňující definovat autorovi aplikace seznam parametrů, které je potřeba automaticky předat odkazovanému skriptu (ať už spouštěného hypertextovým odkazem nebo definovaného jako reakce na odeslaný formulář). Problémem, který komplikuje tvorbu aplikací, jsou datové typy jednotlivých atributů v šablonách (realizované třídou Sablony) a položek ve formulářích tvořených třídou Formular. Všechny používané datové typy jsou uloženy v databázi v číselníku datových typů (uložený je identifikátor typu, jeho název a v případě číselníků ještě odkaz na tabulku číselníku). Každá hodnota v šabloně nebo formuláři je při vkládání zkontrolována na korektní vstup, převedena do formátu pro uložení v databázi a uložena. Při zobrazení hodnot je údaj přečtený z databáze převeden do tvaru čitelného a srozumitelného uživateli, např. identifikátor studijního oboru je převeden na řetězec začínající zkratkou oboru a následovaný názvem daného oboru. Nevýhodou je oddělená implementace manipulace datových typů v obou třídách (Formular a Sablony) a správným řešením je separace těchto operací do samostatné třídy objektů. Tím by bylo možné udržovat pouze jediný kód pro práci s daty. Dalším úskalím je nutnost při přidání nového datového typu do číselníku typů provést zásah do tříd Formular a Sablony, jinak není možné nový typ použít v aplikacích. Možným řešením je rozšíření evidence datových typů umožňující jejich obecnější popis a následná úprava třídy objektů pracující s datovými typy tak, aby nebyla nutná úprava modulu pro každý přidaný datový typ. Značným nedostatkem, který se projevil až po návrhu rozhraní třídy Formular, je způsob definice jednotlivých položek vstupních formulářů. Každá z položek je popsána uspořádanou čtveřicí parametrů (sloupec v databázi, datový typ, popisek a příznak nulovatelnosti) a tento zápis je v jednodušších aplikacích stále dostatečný, ale pro specifikaci dalších podmínek (např. omezení výběru z číselníku na určitou podmnožinu hodnot) bylo nutné přidat další dva parametry. Další rozšiřování je možné pouze přidáváním nových parametrů, což by vedlo ke snížení přehlednosti aplikací a jednoduchosti použití zasažených metod. Zde je univerzálnějším řešením použít pro specifikaci položek asociativních polí, přičemž určité parametry budou povinné a jiné volitelné. Časem se v Univerzitním informačním systému ustálily určité prvky uživatelského rozhraní, které nebyly při původním návrhu jádra podchyceny. Tyto prvky 51

8.6

Potřeby a návrhy dalšího rozvoje

(např. výběr fakulty a následný výběr období) jsou vývojáři sdíleny a jsou kopírovány části programového kódu ošetřující příslušný prvek. Při tomto způsobu práce není možné využít sdíleného kódu v knihovnách – dochází k nekonzistentnímu chování (např. rozdílné řazení studijních období) a chyby je nutné odstraňovat v každé aplikaci jednotlivě. Proto by měly být obdobné části kódu uloženy v samostatné třídě objektů a aplikace upraveny pro použití metod v těchto objektech. Možné rozdíly v chování lze řešit vhodnou parametrizací. Oblast nesouvisející s prezentací výsledků uživateli, ale spíše se stránkou programátorskou, je definované rozhraní, kdy při pojmenování metod a jejich parametrů je použita směs českých a anglických výrazů (např. Formular::formular_add() s parametry -polozky a -uniq). Na tomto poli by bylo prospěšné sjednotit používané označení na český nebo anglický jazyk.

52

9

Úvod do studijního systému

Oblast studijního systému je velmi obsáhlá. V globálním pohledu patří do studijního systému cokoliv spojené nějakým způsobem s výukou studentů (např. studijní agenda nebo problematika elektronických výukových systému). V této práci je obsažen popis aplikací, které souvisí s evidencí studentů a jejich studiem.

9.1

Základní pojmy studijního systému

V duchu zásad tvorby informačních systémů jsou také ve studijním systému definovány základní číselníky. U každého ze zde uvedených pojmů bude také podána informace o tabulce, ve které je číselník uložen. Stav akreditace V delším časovém úseku (horizont několik let) dochází ke změnám ve struktuře nabízených studijních programů, oborů a specializací. Jsou akreditovány a otevírány nové programy, jiné studijní programy už jen dobíhají a nejsou do nich přijímáni noví studenti, proto byl zaveden číselník akreditačních stavů, které umožňují rozdělení programů, oborů a specializací. Možné stavy akreditace jsou (v popisu je uveden pouze program, ale akreditační stavy jsou evidovány i u studijních oborů a specializací): • aktivní – studenti program studují a jsou na něj přijímáni noví, • dobíhající – studenti program ještě studují, ale noví již nejsou přijímáni, • zrušený – program už nestuduje žádný student, • neakreditovaný – program, který ještě není akreditován. Číselník stavů akreditace je uložen v tabulce SC_AKREDITACNI_STAV. Forma studia V současnosti je aktivní presenční a kombinovaná forma studia a dobíhá distanční forma. Číselník forem studia je uložen v tabulce SC_FORMY. Stupně studia Pro rozlišení různých stupňů studia vznikl jejich číselník. Aktuálně evidované stupně jsou: • bakalářský stupeň, • magisterský stupeň, • magisterský navazující stupeň, • doktorský stupeň, 53

9.1

Základní pojmy studijního systému

• celoživotní vzdělávání, • vzdělávání zahraničních studentů. Číselník stupňů studia je uložen v tabulce SC_STUPNE. Programy studia Číselník programů studia je uložen v tabulce SC_PROGRAMY. Atribut STUPEN je cizím klíčem do tabulky SC_STUPNE a určuje, na kterém stupni je program akreditován. Příslušnost studijního programu na fakultu je dána atributem PRACOVISTE. Zkratka programu se skládá ze zkratky příslušného stupně a za pomlčkou následuje libovolný text. Například studijní program Systémové inženýrství a informatika na bakalářském stupni má zkratku B-SI. Kód KKOV (zkratka označení Klasifikace kmenových oborů vzdělání) je odkazem do státního číselníku oborů, který je využíván při sběru údajů pro sdruženou matriku studentů a ÚIV (viz kapitola 12). KKOV kód musí splňovat formát „/ číslice ./ číslice . / číslice ./ číslice . / symbol stupně .ÿ. Studijní obory Číselník studijních oborů je uložen v tabulce SC_OBORY. Atribut PROGRAM určuje, do kterého studijního programu obor patří. Zkratka oboru je tvořena ze zkratky příslušného programu a po pomlčce následuje libovolný text. Například obor Ekonomická informatika v programu Systémové inženýrství a informatika na bakalářském stupni má zkratku B-SI-EI. Specializace Pro evidenci specializací platí analogie toho, co bylo řečeno u studijních oborů. Například specializace Evropská studia v podnikání a ekonomice (zkratka N-EM-ME-ES) je specializací oboru Manažersko-ekonomického (ME) ve studijním programu Ekonomika a management (EM) v navazujícím (N) stupni studia. Tabulka uchovávající číselník specializací je SC_SPECIALIZACE. Běhy Z důvodu postupného přechodu jednotlivých fakult na kreditní systém studia bylo nutné v systému odlišit studenty studující podle různých předpisů – studenti studující podle starého studijního a zkušebního řádu a studenty studující podle standardu ECTS. Další skupinou jsou studenti doktorských studijních programů studující podle individuálních studijních plánů. Aktuálně evidované běhy v tabulce SC_BEHY: • nový běh (studenti studující podle standardu ECTS), • starý běh (studenti studující podle starého Studijního a zkušebního řádu), • doktorský běh (studenti doktorských studijních programů).

54

9.2

Období

Ukončení předmětů Každý předmět má definovaný způsob svého ukončení, od kterého se pak odvíjejí možná hodnocení, kterých je možné dosáhnout. Tabulka obsahující číselník specializací je SC_UKONCENI a v současnosti jsou možná ukončení následující: • zápočet, • zkouška, • stará zkouška (ukončení používané ve starém běhu studia, má odlišnou stupnici známek – 1, 2, 3 a 4), • komisionální zkouška (průběžná zkouška na doktorském studiu), • souborná zkouška, • postupová zkouška, • státní bakalářská zkouška, • státní závěrečná zkouška, • státní doktorská zkouška. Výsledky předmětů Číselník výsledků předmětů (tabulka SC_VYSLEDKY_PREDMETU) definuje všechny možné výsledky příslušné k danému ukončení. V atributech je kromě slovního označení výsledku, příslušné zkratky a příslušnosti k ukončení předmětu také uchovávána váha výsledku a logická hodnota označující úspěšná ukončení předmětu (nastavení atributu na 1 znamená úspěšné hodnocení). Hodnocení „nedostavil seÿ se při hodnocení předmětu je ekvivalentní s hodnocením „nezapočtenoÿ (při zápočtu), resp. „nevyhovělÿ (při zkoušce), ale umožňuje rozlišit mezi situacemi, kdy student neuspěje nebo pokud vůbec nepřijde na vypsaný termín. Toto rozlišení je zavedeno z důvodu statistického zpracování údajů, aby bylo možné oddělit tyto neúspěšné pokusy od sebe (jedná se o statisticky významnou informaci).

9.2

Období

Celé studium studenta je členěno na období. Období je jednotka postupu studenta v jeho studiu – po splnění všech požadavků daných v aktuálním období je student zapsán do následujícího období a tím postupuje ve svém studiu. Podle starého studijního a zkušebního řádu trvalo jedno období celý akademický rok, s přechodem na kreditní systém studia bylo období zkráceno na jeden semestr. Datum začátku a konce období určuje fakulta ve svém harmonogramu, ale určité činnosti probíhají před začátkem období (např. přijímací řízení do zimního semestru probíhá již v předchozím letním semestru nebo registrace) a jiné činnosti probíhají ještě po skončení období (např. hodnocení období nebo výkaz činností za uplynulé období, tzv. evaluace). Jednotlivá období na sebe nemusí ani přesně navazovat, tj. konec jednoho období nemusí být bezprostředně následován začátkem dalšího období. 55

9.3

Univerzitní období

U každého období je v jeho atributech specifikováno, pro kterou fakultu (obecně pracoviště) je vytvořeno. Systémový integrátor fakulty v dostatečném předstihu vytváří nová období a nastavuje hodnoty atributů. V hodnotách atributů jsou uloženy parametry řídící spouštění určitých akcí (začátky a konce registrací, zápisu, zkouškového období, datum uzávěrky zkušebních zpráv apod.) a různé další parametry závislé na podmínkách fakulty (podmínky pro postup studentů do dalšího semestru, tisk hlaviček na dopisech generovaných informačním systémem). Významným atributem období je atribut veřejné období. Běžný uživatel systému (pedagog, student) se při práci s Univerzitním informačním systémem setká pouze s obdobími, která byla označena jako veřejná. Neveřejná období slouží systémovým integrátorům k činnostem, která nemají být viditelná běžným uživatelům. Typickým použitím neveřejného období je sklad předmětů, příprava akreditace nebo prosté ukrytí nově vytvářeného období do doby než bude kompletně připraveno a zpřístupněno uživatelům. Aby bylo možné správně vypočítat délku studia, bylo nutné každé období doplnit o atribut určující délku období v semestrech. Délka období, která trvají celý akademický rok, je dvě, délka období trvajících jeden semestr je jedna. Správný způsob určení celkové délky studia je součet délek všech období, jimiž student prošel a které právě studuje. Pro zajištění správného způsobu výpočtu a použití jednotného algoritmu, byla vytvořena databázová funkce DELKA_STUDIA_SEMESTRY, která pro zadané identifikační číslo studia vypočte délku studia v semestrech. Všechna období jsou uložena v tabulce SC_OBDOBI.

9.3

Univerzitní období

Univerzitní období vzniklo na základě potřeby určit, která období na jednotlivých fakultách patří do stejného akademického roku. V atributech každého běžného období je odkaz na záznam v tabulce univerzitních období. Univerzitní období také slouží jako vzor při tvorbě nových období – do atributů nově vytvořeného období jsou zkopírovány atributy příslušného univerzitního období. Univerzitní období jsou uchovávána v tabulce SC_UNIVERZITNI_OBDOBI.

9.4

Katalog předmětů

Katalog předmětů je kompletní souhrn všech předmětů, které se na univerzitě učily nebo právě učí. Každý předmět patří do určitého období a tím je dáno kdy a pro kterou fakultu byl vyučován. Katalog předmětů je uložen v tabulce SC_PREDMETY. V atributech každého předmětu je uložen kromě kódu a názvu předmětu také garant, garantující pracoviště, definice prerekvizit (detaily o prerekvizitách jsou popsány v oddílu 9.5), hodinová dotace, různé jazykové mutace sylabů, doporučená literatura, vyučující, možné varianty ukončení předmětu včetně jejich kreditového ohodnocení, standardní ukončení

56

9.4

Katalog předmětů

předmětu, označení předmětů, které jsou nabízeny k zápisu na ostatní fakulty, a řada dalších. Standardním ukončením předmětu je určeno jedno z možných ukončení předmětu. S tímto ukončením je předmět studentovi běžně zapisován, ale student má možnost zapsat si předmět s alternativním ukončením. Například předmět Unix má jako standardní ukončení určeno zakončení zkouškou, ale studenti mají možnost zapsat si předmět Unix i s ukončením zápočet. Kód předmětu Nejdůležitějším identifikačním prvkem předmětu je jeho kód. Pomocí kódů je zajištěna kontinuita předmětu v čase a je to jediná identifikace používaná k identifikaci stejného předmětu mezi jednotlivými obdobími. Kód předmětu musí být jedinečný v rámci jedné fakulty. Postupem času může docházet ke změnám názvu předmětu, jeho garanta, sylabu nebo způsobu ukončení, ale dokud zůstává zachovaný kód, jsou tyto předměty v obdobích považovány za ekvivalentní. Například předmět s kódem ALG před třemi roky a v současnosti je hodnocen jako ten stejný předmět. Tento fakt je velmi důležitým předpokladem pro fungování systému prerekvizit. Při tvorbě nových kódů předmětů by měla být dodržována určitá pravidla a zásady. Dodržování níže uvedených zásad není povinné, ale jejich respektování zvyšuje přehlednost katalogu předmětů. • Délka kódu předmětu by měla být nejvýše čtyři znaky. • Kód předmětu by měl obsahovat pouze velká písmena abecedy bez diakritiky a číslice. • V kódech předmětů, který má více pokračování označené římskými číslicemi, se číselné označení převádí na arabské číslice. Například kódy předmětů Statistika I a Statistika II jsou ST1 a ST2. • Kódy předmětů v obdobích patřící do starého běhu začínají prefixem S-. Role uživatelů U každého předmětu je možné definovat následující role, které poskytnou uživatelům v těchto rolích dodatečné oprávnění: • Administrativa předmětu je role zajišťující vyjmenovaným uživatelům stejná práva jako garantovi předmětu. • Cvičící je role umožňující zadávat zápočet za cvičení. • Zkoušející je role určená pedagogům, kteří jsou oprávněni zkoušet studenty a zapisovat jim závěrečné známky za předmět. • Přednášející je role, která má pouze informativní charakter. Je zvažováno vytvoření role zápočtujícího, která by umožňovala ukončovat předmět zakončený zápočtem. Přidělená role nejvýrazněji ovlivňuje chování aplikace Záznamník učitele, viz oddíl 10.6 nebo (Bartík, 2003). 57

9.5

Prerekvizity

Sklady předmětů Skladem předmětů se rozumí úložiště všech předmětů vyučovaných na fakultě v minulosti. Po datové stránce je sklad předmětů neveřejným obdobím. Veškeré modifikace předmětů (nastavení ukončení, editace sylabu, nastavení rolí uživatelů apod.) by měly probíhat ve skladu předmětů a výsledná podoba předmětu je pak zkopírována do požadovaného období. Tímto způsobem je možné mít ve skladu vždy nejaktuálnější informace o předmětech. Při přípravě nového období je pak vhodné nově tvořené období naplnit předměty ze skladu. Aplikace Katalog předmětů poskytuje možnosti pro přenos informací mezi různými obdobími (kopie všech informací o předmětu nebo pouze sylabů a přepis již existujících předmětů v cílovém období). Počet neveřejných období není nijak omezen a proto je možné využívat např. jeden sklad pro aktuálně vyučované předměty a další pro přípravu předmětů pro akreditaci. Vzhled aplikace Katalog předmětů je k vidění na obr. 16 v příloze. Kontrola katalogu předmětů Pro zajištění snadné kontroly zadání všech nezbytných údajů v katalogu předmětů vznikla aplikace, která provádí hromadnou kontrolu katalogu předmětů ve zvoleném období. Výstupem kontrolní aplikace je sestava, ve které jsou uvedeny u každého předmětu jeho nedostatky a odkazy na aplikaci umožňující jejich odstranění. V sestavě se objevují pouze předměty, u nichž byl nalezen nějaký nedostatek.

9.5

Prerekvizity

Prerekvizity slouží ke specifikaci nutných předpokladů (úspěšně absolvované nebo současně studované předměty) pro to, aby si student mohl zapsat nebo zaregistrovat daný předmět. Pokud nejsou prerekvizity splněny (nebo nejsou splněny jiné podmínky), není studentovi dovoleno zaregistrovat si nebo zapsat si zvolený předmět. Student má pak možnost požádat prostřednictvím aplikace v informačním systému garanta předmětu o výjimku a potom rozhodnutí o udělení výjimky záleží na garantovi. Žádosti o výjimky (podávané kvůli nesplněným prerekvizitám) lze považovat za druh zpětné vazby od studentů směrem ke garantům a umožňuje tak detekovat nevhodně nastavené prerekvizity. Předpis pro tvorbu prerekvizit Prerekvizity jsou zadávány jako výrokové formule podle následujícího předpisu: 1. formulí je / kód předmětu ., 2. formulí je NOW(/ kód předmětu .), 3. formulí je FORMA(/ zkratka formy .), 4. formulí je i negace formule !/ formule .,

58

9.5

Prerekvizity

5. formulí je i spojení dvou formulí pomocí logických operátorů & (a zároveň) a | (nebo), 6. libovolnou formuli je možné uzavřít do kulatých závorek, 7. libovolná formule vznikne aplikací výše uvedených pravidel. Přiřazení pravdivostních hodnot formulí • Formule / kód předmětu . je vyhodnocena jako pravdivá, pokud student během svého studia úspěšně ukončil předmět s uvedeným kódem. • Formule NOW(/ kód předmětu .) je vyhodnocena jako pravdivá, pokud má student v aktuálním období současně zapsán předmět s daným kódem. • Formule FORMA(/ zkratka formy .) je vyhodnocena jako pravdivá, pokud je student zapsán na formě studia s danou zkratkou. • Operace negace, a zároveň a nebo se vyhodnocují podle pravidel výrokové logiky (opačná pravdivostní hodnota, logický součin a logický součet). Stejná pravidla platí také pro prioritu jednotlivých operací, tedy nejvyšší prioritu má negace, pak následuje operace a zároveň a nejnižší prioritu má operace nebo. • Uzavřením části formule do závorek se mění priorita operátorů. • Prerekvizity jsou vyhodnoceny jako splněné, pokud je celý výraz vyhodnocen jako pravdivý. Virtuální předměty Na základě požadavků omezit zápis některých předmětů pouze pro určitý stupeň studia byly vytvořeny tzv. virtuální předměty. Jedná se o předměty, které student ve svém aktuálním studiu nemá zapsané, ale předpokládá se jejich splnění v rámci předchozího studia. Těmito virtuálními předměty jsou: • Státní bakalářská zkouška (SBZ), • Státní závěrečná zkouška (SZZ). Při vyhodnocování prerekvizit pak všichni studenti navazujícího studia mají automaticky splněný předmět Státní bakalářská zkouška a všichni studenti doktorského studia úspěšně absolvovali Státní závěrečnou zkoušku. Pro objasnění situace uveďme jako příklad specifikaci prerekvizit předmětu určeného pouze pro studenty doktorského studia. Jednou z prerekvizit takového předmětu bude i předmět Státní závěrečná zkouška. Je zřejmé, že student doktorského studijního programu nemá zapsaný předmět Státní závěrečná zkouška, ale musel jej absolvovat na závěr svého studia na magisterském stupni, protože jednou z podmínek přijetí na doktorský stupeň studia je ukončený magisterský stupeň vzdělání. Obdobně se postupuje u předmětu Státní bakalářská zkouška, kterou je ukončen bakalářský stupeň studia. Pozor! Předmět Postupová zkouška (PZK) není virtuální předmět, protože po jeho složení není studentovi ukončeno studium, ale student pokračuje ve svém stu-

59

9.5

Prerekvizity

diu. Postupová zkouška je běžný předmět, který ztratí svůj význam po doběhnutí pětiletých magisterských studijních programů. Příklad prerekvizit Pro názornost si nyní uvedeme příklad prerekvizit, na kterých si předvedeme jejich interpretaci. Prerekvizity předmětu Obchodní operace (kód OOB) v zimním semestru akademického roku 2002/2003 jsou zapsány tímto řetězcem: (MAR | NOW (MAR)) & (!OPO | NOW(OPO)) Kód MAR je kódem předmětu Marketing, kód OPO je označením pro předmět Obchodní podnikání. První polovina prerekvizit je vyhodnocena kladně v případě, že student v minulosti úspěšně absolvoval předmět Marketing nebo jej má zapsaný současně s předmětem Obchodní operace. Druhá část je vyhodnocena kladně, pokud student ještě neabsolvoval předmět Obchodní podnikání nebo jej má právě zapsán. Výsledné vyhodnocení je kladné v případě, že první i druhá polovina výrazu je vyhodnocena kladně. Mírně složitější jsou prerekvizity předmětu Finanční řízení podniku (kód FŘP) v letním semestru 2002/2003. Předmět je vypisován s následujícími prerekvizitami: ((ZPE|PEK) & (ZUC|USU)) | SBZ | PZK V rychlosti si uveďme významy jednotlivých kódů předmětů (řazené abecedně): • PEK – Podniková ekonomika, • PZK – Postupová zkouška, • SBZ – Státní bakalářská zkouška, • USU – Úvod do studia účetnictví, • ZPE – Základy podnikové ekonomiky, • ZUC – Základy účetnictví. Výraz v první závorce je vyhodnocen kladně, jestliže student absolvoval předmět Základy podnikové ekonomiky nebo Podniková ekonomika a zároveň absolvoval předmět Základy účetnictví nebo Úvod do studia účetnictví. Předmět Státní bakalářská zkouška je virtuálním předmětem, který mají splněný všichni studenti zapsaní na navazujícím stupni studia. Předmět postupová zkouška je běžným předmětem plněným v rámci magisterského studijního programu (většinou po třech letech studia). Výsledkem uvedených prerekvizit je stav, kdy na bakalářském stupni studia si předmět Finanční řízení podniku smí zapsat pouze student mající splněné předměty dané první částí výrazu (((ZPE|PEK) & (ZUC|USU))), libovolný student na navazujícím stupni studia a studenti magisterského stupně po složení Postupové zkoušky. Problémy spojené s prerekvizitami Zatím není možné ve studijním systému pracovat se stromem prerekvizit, ale lze vyhodnocovat pouze prerekvizity pro jediný předmět. Z důvodu absence vhodných nástrojů není možné přehledně zobrazit stromovou strukturu předmětů podle jejich návazností, ale ani není možné detekovat možné problémy jakými jsou: 60

9.6

Šablony předmětů

• Cyklus – nejjednodušším příkladem cyklu v prerekvizitách je „A závisí na Bÿ a současně „B závisí na Aÿ. Na tomto jednoduchém příkladu je vidět, že studentovi nebude umožněno zapsat si předměty A a B (pomineme-li možnost žádosti o výjimku). Ve skutečnosti mohou vzniknout i větší cykly (cyklus bude tvořen návaznostmi přes více předmětů). • Tranzitivita – příkladem tranzitivní závislosti je „A závisí na Bÿ a „C závisí na A a Bÿ, kde závislost C na B vyplývá už ze závislosti A na B. Odstraněním tranzitivních závislostí se prerekvizity zjednoduší a zpřehlední. Řešení výše nastíněných problémů (tedy zobrazení stromu prerekvizit i detekce cyklických a tranzitivních závislostí) bude realizováno bakalářskou prací vypsanou na podzim 2003.

9.6

Šablony předmětů

Pro snadnější orientaci v nabízených předmětech má studijní oddělení možnost studentům připravit šablony předmětů. Jde o pojmenované skupiny předmětů. Při registraci a zápisu si pak mohou studenti přidat předměty z celé šablony nebo pouze vybrané předměty. Se šablonami souvisí členění šablon – šablony jsou rozčleněny do skupin s podobným obsahem: • doporučený průchod studiem (obsahuje šablony, ze kterých jsou tvořeny doporučené plány), • tématické šablony (např. informatické předměty, předměty z oblasti financí, předměty zabývající se marketingem, jazyky apod.), • organizační členění (např. volitelné předměty na bakalářském stupni). Rozčlenění šablon předmětů do skupin výrazně pomáhá při orientaci v jejich velkém množství a urychluje fázi hledání předmětu s požadovanými vlastnostmi (spolu s dobře navrženými a vytvořenými šablonami předmětů).

9.7

Doporučený plán studia

Při studiu podle standardu ECTS je studentovi ponechána volnost při volbě průchodu studiem. Omezením zápisu předmětů je předepsané pořadí plnění předmětů dané prerekvizitami a úspěšné ukončení studia je podmíněno získáním určitého počtu kreditů a splněním všech povinných předmětů předepsaných studijním programem. Protože řada studentů nechce nebo není schopná vytvořit si vlastní průchod studiem, byly pro jednotlivé obory a specializace vytvořeny doporučené plány studia. Doporučený plán studia (někdy označovaný standardní průchod studiem) je vzorový studijní plán umožňující absolvování všech předepsaných předmětů a splnění dalších podmínek studia ve standardní délce studia. V Univerzitním informačním systému se doporučeným plánem rozumí určitá šablona, která je přiřazena konkrétnímu oboru studia, formě, ročníku a případně specializaci. Doporučený plán je pak využíván při registracích a zápisu studentů, 61

9.8

Výpočet ročníku studia

kdy jsou předměty v doporučeném plánu studentovi automaticky přidány, pokud ještě nemá žádné zaregistrované (resp. zapsané). Při výběru doporučeného plánu pro studenta musí odpovídat obor, forma a ročník doporučeného plánu s údaji studenta. V případě, že si tyto údaje neodpovídají, není možné doporučený plán použít. Pokud student studuje určitou specializaci studijního oboru, tak je nejprve vyhledávána odpovídající specializace v doporučených plánech, pokud není nalezena studentova specializace, je použit vyhovující doporučený plán bez uvedené specializace.

9.8

Výpočet ročníku studia

V kreditním systému studia neexistuje vzhledem k individuálnímu postupu ve studiu ročník studia. Jediným údajem o postupu ve studiu je odstudovaná doba, kterou student na univerzitě strávil. Absence informace o ročníku studia se ukázala být překážkou nejen při doplňování doporučených plánů studentům, ale i v dalších situacích. Proto vznikla databázová funkce DELKA_STUDIA_ROCNIK, která podle záznamů o průchodu studenta studiem odhaduje ročník studia, ve kterém se student nachází. Při odhadu ročníku jsou brány v úvahu i opakované ročníky a ročníky studované v rámci individuálního studijního plánu. Algoritmus odhadu ročníku ve valné většině případů dokáže ročník odhadnout správně. Pokud se odhad liší od skutečnosti, je možné v atributu studia nastavit korekci ročníku. Korekce ročníku je celé číslo, které je přičteno k odhadnutému ročníku. Korekci ročníku bude například nutné použít v případě, že student přestoupil z jiné vysoké školy do jiného než prvního ročníku. Potom odhadnutý ročník nebude souhlasit s ročníkem, do kterého na MZLU v Brně nastoupil.

9.9

Časový průběh období

Podívejme se na časovou posloupnost činností tak, jak po sobě následují v průběhu jednoho období. Nejprve je nutné, aby systémový integrátor založil nové období pro svoji fakultu. Měl by nastavit atributy období (časové údaje podle harmonogramu, nastavení ovlivňující chování aplikací na základě požadavků vedení fakulty), také je nutné připravit katalog předmětů v nově vytvářeném období. Po provedení uvedených akcí je možné zpřístupnit období ostatním uživatelům. Před spuštěním registrací do období jsou studijním oddělením vytvořeny šablony předmětů (mohou být i zkopírovány z jiného období), jsou vloženy doporučené plány. Po provedené přípravě jsou spuštěny registrace, během kterých studenti vyjádří svůj zájem o studium předmětů. Výsledky registrací jsou použity pro stanovení počtů studijních skupin, rozvrháři vytvoří rozvrh a vloží jej do Univerzitního informačního systému. Po uložení a zveřejnění rozvrhu je spuštěn zápis studentů do období. Během zápisu si studenti 62

9.9

Časový průběh období

volí cvičení, která budou navštěvovat, a tím si vytváří vlastní rozvrh. Po zápisu studentů začíná výuková část semestru a je možné provádět dodatečné změny v zápise (většinou první dva týdny ve výukové části semestru). V závěru výukové části jsou již vypisovány zkušební termíny a studenti mají možnost se přihlašovat na zápočtové testy a zkoušky. Zkušební termíny mohou být vypisovány pouze do konce zkouškového období. V době mezi koncem zkouškového období a datem uzávěrky zkušebních zpráv musejí zkoušející učitelé vyplnit a odevzdat zkušební zprávy. Navíc do výše uvedené posloupnosti činností vstupují další mimořádné akce jako je přijímací řízení (v době před zahájením semestru, do kterého jsou přijímáni) nebo závěrečné zkoušky studentů posledních ročníků.

63

10

Aplikace studijního systému

Kapitola obsahuje popis funkcí, které Univerzitní informační systém poskytuje učitelům a studentům.

10.1

Přijímací řízení

Problematika přijímacího řízení je značně obsáhlá a její rozbor přesahuje rozsah této práce. Proto je zde uveden pouze výčet činností, které jsou v Univerzitním informačním systému podporovány a automatizovány (uvedené pořadí odpovídá časovému sledu jednotlivých činností): • zadání údajů z přihlášek do UIS, • odeslání informací o uchazečích na ÚIV (viz oddíl 12.2), • evidence termínů přijímacích zkoušek, • přidělení termínů přijímacích zkoušek uchazečům, • tisk pozvánek k přijímacím zkouškám, • tisk presenčních listin pro přijímací zkoušky, • zadání výsledků přijímacích zkoušek, • sestavy pro zveřejnění výsledků přijímacích zkoušek, • sestavy pro podporu stanovení kritérií úspěšnosti u přijímacího řízení, • nastavení minimálních bodových hranic pro úspěch u přijímací zkoušky (limity pro jednotlivé předměty a celkový součet bodů), • nastavení rozhodnutí o přijetí, • tisk dopisů s oznámením o výsledku přijímacího řízení, • evidence žádostí o přezkoumání rozhodnutí o výsledku přijímacího řízení (obecně známé spíše pod označením odvolání), • zadání výsledků žádostí o přezkoumání, • tisk dopisů oznamujících výsledek přezkoumání, • převod uchazečů, kteří se dostavili k zápisu, mezi studenty. V porovnání s ostatními aplikacemi, je agenda přijímacího řízení odlišná od zbytku studijní agendy v použité identifikaci uchazečů. Všichni uživatelé Univerzitního informačního systému mají své uživatelské číslo a přihlašovací jméno (tzv. login), což umožňuje jejich jednoznačnou identifikaci. Toto uživatelské číslo ovšem nemají přidělené uchazeči o studium na univerzitě, protože v průběhu přijímacího řízeni jsou zpracováváni v samostatné části databáze. Místo uživatelského čísla je každé zapsané přihlášce systémem přiděleno registrační číslo. Všechny aplikace je možné provozovat ve vícekolovém režimu. Při více kolech přijímacího řízení je nutné zajistit rozeslání dopisů informujících uchazeče o postupu do následujícího kola a pozvánek na další kolo přijímacího řízení. Na Zahradnické

64

10.2

Registrace

fakultě v Lednici je na určité studijní programy dvoukolové přijímací řízení, ostatní fakulty mají jednokolové přijímací řízení. Přijímací řízení je významným zdrojem údajů o budoucích studentech, protože údaje zadané do systému podle podané přihlášky jsou následně přeneseny k nově vytvořenému uživateli při zápisu studenta. Po zápise je studentovi přiděleno identifikační číslo, vygenerováno přihlašovací jméno a počáteční přístupové heslo. Dále student obdrží nezbytná oprávnění, je zařazen do stravovacího systému, přihlášen k pojišťovně a zapsán do matriky studentů.

10.2

Registrace

Proces registrace je předběžným vyjádřením zájmu studenta o studium předmětů v následujícím období. Na základě výsledků registrace jsou pak určovány počty skupin ve cvičeních a seminářích a je přizpůsoben rozvrh. Registrace je pro studenta „zápisem nanečistoÿ a jsou dobrovolné, ale je zájmem studentů si předměty registrovat. Především hrozí problém s kapacitním omezením některých předmětů, protože při zápisu do předmětu jsou preferováni studenti, kteří měli předmět zaregistrován. Při prvním vstupu do registrace je studentovi automaticky doplněn doporučený plán. Následně má student možnost přidat si (jednotlivě, podle připravených šablon nebo odpovídající doporučený plán) nebo odebrat registrované předměty. Také je provedena automatická registrace neúspěšně studovaných předmětů, které jsou vypisovány v období, do kterého probíhá registrace. Opakované předměty není možné odebrat z registrace. Aktuální stav registrace je okamžitě indikován. Student je informován o celkovém stavu registrace i stavu registrace jednotlivých předmětů (aktuální pořadí studenta, celkový počet studentů registrujících si daný předmět, limit počtu studentů a volné místo), případné problémy a souhrnné informace o registrovaných předmětech (celkový počet předmětů, rozpad předmětů podle různých způsobů ukončení, součet kreditů apod.). Pokud si student z nějakého důvodu nemůže zapsat předmět (kapacitní omezení nebo nesplnění požadavků daných prerekvizitami), má možnost požádat garanta předmětu o výjimku registrovat si předmět. Žádost se podává elektronicky prostřednictvím UIS spolu s udáním odůvodnění žádosti. Stav své žádosti může student sledovat v aplikaci pro registraci předmětů a může nabývat následujících stavů: • žádost ještě nebyla podána, • žádost je podaná a čeká na vyjádření garanta předmětu, • žádost bylo vyřízena kladně, • žádost byla zamítnuta. Žádosti o výjimky má vyučující možnost sledovat v aplikaci Záznamník učitele v sestavě nových žádostí, kde vidí kdo o výjimku žádá a jaký uvádí důvod. Vyučující by měl žádost posoudit a vyhovět jí nebo ji zamítnout. Učitel má také k dispozici sestavu s již vyřízenými žádostmi.

65

10.3

Rozvrhy

Po ukončení registrací ze strany studentů jsou studijním oddělením hromadně zaregistrovány doporučené plány studentům, kteří se registrací nezúčastnili. Tím je zajištěno doplnění počtů studentů před tvorbou rozvrhu. Na základě informací získaných při registracích jsou vypočteny potřebné počty studijních skupin pro cvičení. Údaje o registrovaných předmětech a výjimkách jednotlivých studentů jsou uloženy v tabulce S_REGISTRACE. Další informace o aplikaci jsou uvedeny v demonstrátorské práci Registrace a zápis v UIS (Bartík, 2002).

10.3

Rozvrhy

Po řadě diskusí na univerzitě a zjišťování situace okolo rozvrhů na jiných školách byla zavrhnuta myšlenka vytvářet rozvrh automatizovaně, protože kompletní tvorba rozvrhu počítačem je velmi obtížně algoritmizovatelná. Místo toho byly v Univerzitním informačním systému vyvinuty aplikace podporující tvorbu rozvrhu rozvrhářem. Snahou je automatizovat činnosti, které je možné provádět rychle a efektivně díky automatizovanému zpracování údajů. Je podporován: • tisk rozvrhových kartiček, • vkládání rozvrhových akcí, • detekce a sestava kolizí. Vhodnou úlohou pro automatizované zpracování je samotné zobrazení rozvrhů. Je možné zvolit si rozvrh podle řady kritérií (např. rozvrh učitele, rozvrh učebny, osobní rozvrh studenta apod.). Rozložení rozvrhových akcí na ploše rozvrhu je při zobrazení prováděno tak, aby bylo efektivně využito místo na papíře, popř. na obrazovce. Ukázka výstupu rozvrhu učitele ve formátu HTML je na obr. 13 v příloze. Základní tabulkou obsahující rozvrhy jednotlivých fakult je SC_ROZVRHY. Ta obsahuje název rozvrhu, příslušnost rozvrhu k období (a tím i k pracovišti) a příznak, který určuje, zdali se má rozvrh zobrazovat uživatelům.

10.4

Zápis

Zápis je prováděn ve dvou krocích – nejprve si student připraví předměty, které bude chtít zapsat, a poté se na studijním oddělení nechá zapsat do dalšího období. Příprava předmětů studentem Po ukončení registrací jsou data o registrovaných předmětech přenesena do tabulky S_ZAPIS, která slouží pro uchování požadavků studentů na zápis. Také jsou přeneseny informace o podaných žádostech o výjimku, což znamená, že o ně není potřeba znovu žádat. V průběhu zápisu jsou již přístupné rozvrhy a studenti si volí, kdy budou navštěvovat cvičení. Výjimku tvoří studenti v prvním období studia, kteří jsou rozděleni do studijních skupin. Každá studijní skupina má přidělenou sadu cvičení vybíraných tak, aby

66

10.5

Změny po zápise

nebyly v kolizi s přednáškami ostatních předmětů, které mají zapsané. Rozdělení do skupin provádí po zápisu prvních ročníků studijní oddělení. Po začátku zápisu je studentům zpřístupněna aplikace pro přípravu předmětů k zápisu, která se chová stejně jako aplikace pro registraci předmětů. Po dokončení přípravy zápisu navštíví student příslušné studijní oddělení. Potvrzení zápisu na studijním oddělení Na studijním oddělení jsou studentovi zkontrolovány předměty požadované k zápisu (a případné výjimky), je provedena kontrola splnění všech požadavků pro postup do dalšího období studia a v případě úspěšného splnění požadavků je student zapsán do následujícího období. Aplikace pro zápis, kterou používají na studijních odděleních, umožňuje studijní referentce stejné operace s předměty jako aplikace, která je určená studentům (tedy přidávání a odebírání jednotlivých předmětů, přidávání předmětů ze šablon a přidání doporučeného plánu). Navíc je možné přímo z aplikace pro zápis spustit aplikaci Studijní evidence s kartou právě zapisovaného studenta, provést potřebné opravy a vrátit se zpět. Po úspěšném zapsání studenta je mu vytištěn zápisový arch se zapsanými předměty. Studijní referentky mají také možnost využít seznamu nezapsaných studentů, kde vedle jména studenta je odkaz na aplikaci Zápis. Seznamy nezapsaných studentů byly hojně využívány na těch fakultách, kde se zápis prováděl na papír a následně byli studenti zapisováni v UIS. Podrobnější informace je možné najít v práci (Bartík, 2002).

10.5

Změny po zápise

Po zápise mají studenti určité období (zpravidla prvních čtrnáct dnů po začátku výuky) možnost provádět změny v zápisu předmětů. Změny si opět student nejprve připraví a následně mu ještě změny musí být potvrzeny studijním oddělením. Aplikace pro přípravu změn v zápise používá pro uchování požadavků tabulku S_ZAPIS. Studijní referentky mají k dispozici aplikaci, která přehledně zobrazí navrhované změny v zápise (přidávané a odebírané předměty), a provede kontrolu, jestli nebudou porušeny podmínky zápisu (počty předmětů, kreditů, zkoušek apod.). V případě kladného vyřízení požadavků na změny je vytištěn nový zápisový arch.

10.6

Záznamník učitele

Záznamník učitele je aplikace integrující v sobě veškeré operace učitele vzhledem ke studentům a ke studijnímu oddělení. Aplikace také poskytuje řadu dalších užitečných evidencí, které vyučující v průběhu semestru potřebuje, a umožňuje jejich vedení v elektronické podobě. Je možné evidovat docházku, bodové hodnocení průběžných písemných prací, dále je možné vypisovat termíny zkoušek a modifikovat je,

67

10.7

Přihlašování na zkoušky

vyplňovat zkušební zprávy předmětu, je možné zobrazení seznamu studentů majících vztah k vyučovanému předmětu apod. Aplikace je propojena s poštovním systémem a tím je umožněno snadné rozesílání evidovaných informací studentům. Detailním popisem Záznamníku učitele je diplomová práce Lukáše Bartíka (Bartík, 2003).

10.7

Přihlašování na zkoušky

Aplikace Přihlašování na zkoušky je elektronickou variantou seznamů termínů vyvěšovaných na ústavech v průběhu zkouškového období. Hlavní výhodou je dostupnost informací o vypsaných termínech odkudkoliv a stejně tak možnost se na zkoušku přihlásit bez nutnosti návštěvy školy (především je to přínosné pro studenty, kteří musí do školy dojíždět). Student vidí přehlednou sestavu vypisovaných termínů, které jsou rozděleny na: • termíny, na kterých je přihlášen, • termíny, kam se ještě může přihlásit, • termíny, kam se přihlásit nemůže (termín ještě neproběhl, ale je překročená vypsaná kapacita), • termíny, které již proběhly, • předměty, které zatím nemají vypsaný žádný termín. Implicitně se zobrazují zkušební termíny všech předmětů, které má student zapsány, ale pro zvýšení přehlednosti je možné vypisovat termíny spojené pouze s určitým předmětem. Při zapisování na zkoušky je dovoleno zapsat se pouze na jediný termín z každého předmětu (není tedy možné, aby se student přihlásil současně na více termínů z jednoho předmětu). Na další termín se student může zapsat až po proběhnutí termínu, na který je přihlášen nebo se ze stávajícího termínu musí odhlásit. Dále je přihlašování studentů limitováno typem vypisovaného termínu. Termín může být vypsán jako řádný, první opravný nebo druhý opravný. Studenti, kteří ještě nebyli zapsáni na žádném termínu, se mohou hlásit pouze na řádný termín. Po absolvování jednoho termínu se student může přihlásit pouze na první opravný termín. Podobně po dvou a více termínech je dovoleno studenům přihlašovat se pouze na druhý opravný termín. Zkoušející má tak nastavením kombinace typů termínů možnost ovlivnit strukturu studentů, kteří na vypsaný termín mohou přijít.

10.8

Koleje

Při analýze a návrhu aplikací spojených s kolejní agendou byla navázána spolupráce se zástupcem kolejní rady Provozně ekonomické fakulty, který je v kontaktu s kolejními radami ostatních fakult. Všichni studenti si mohou podat žádost o ubytování na kolejích v následujícím akademickém roce. Při podání žádosti si student zvolí kolej, na které chce být ubytován, jestli požaduje pokoj s přípojkou k Internetu a jestli k žádosti podává ještě 68

10.9

Další aplikace

nějaké dodatečné důvody, ke kterým se přihlíží při rozdělování kolejí (zdravotní nebo sociální důvody apod.). Při současném studiu na více fakultách Mendelovy zemědělské a lesnické univerzity si student podává jedinou žádost. Tato žádost se pak objevuje v sestavách žádostí na všech fakultách, kde je student zapsán ke studiu. Při kladném vyřízení žádosti na jedné z fakult se na sestavách ostatních fakult začne uvádět jako student s již udělenými kolejemi. Tímto způsobem je zabráněno situaci, kdy by jeden student dostal na jeden akademický rok více kolejních dekretů. Podpora kolejní agendy v Univerzitním informačním systému zahrnuje aplikace pro: • úřední desky kolejních rad jednotlivých fakult, • zadávání žádostí o ubytování na koleji studenty, • hromadné zadávání žádostí o ubytování na koleji studijním oddělením, • výpis kontrolních sestav žádostí o koleje, • nástroj pro výpočet dojezdových vzdáleností, • aplikace pro zadávání rozhodnutí o žádosti, • tisk výstupních sestav, • tisk kolejních dekretů.

10.9

Další aplikace

Dalšími aplikacemi, které usnadňují práci studentům jsou aplikace generující dokumenty na základě standardních formulářů. Potvrzení o studiu Často studenti potřebují dokládat svůj studentský status různým státním institucím a organizacím. Pro tyto účely vydává škola studentům potvrzení o studiu. Zatím jediným způsobem získání takového potvrzení byla návštěva studenta na studijním oddělení, kde obdržel připravený formulář pro potvrzení o studiu. Formulář vyplnil a studijní referentka mu tento formulář potvrdila razítkem a podpisem. Proč ale nevyužít možností Univerzitního informačního systému? Všechny informace, které student vypisuje do papírového formuláře jsou v UIS evidovány (datum narození, studovaný program a obor, zvolená forma studia apod.). Proto byla vytvořena aplikace, která na požádání vytiskne studentovi arch potvrzení o studiu (čtyři potvrzení na jeden list papíru A4) s vyplněnými údaji. Poté si student na studijní oddělení zajde pouze pro ověření razítkem a podpisem studijní referentky. Tím dochází k úspoře času a navíc potvrzení vypadají lépe než rukou vyplňované formuláře.

69

10.9

Další aplikace

Žádost na studijní oddělení Podávání žádostí na studijní oddělení je realizováno standardním formulářem, na kterém student v záhlaví vyplní údaje o sobě a do vymezeného prostoru napíše svou žádost. Podobně jako v případě potvrzení o studiu, pomáhá UIS studentům tím, že informace vypisované do záhlaví vyplní podle údajů v databázi a student do aplikace vyplní předmět a odůvodnění své žádosti. Následně si student takto vyplněnou žádost vytiskne, podepíše a odnese na studijní oddělení k vyřízení. Závěrečné práce Aplikace na zadávání závěrečných prací slouží vedoucím bakalářských a diplomových prací k evidenci údajů o vedených pracích. Na základě vložených údajů jsou tisknuta zadání závěrečných prací, která jsou nutnou součástí každé odevzdávané práce. Zadání diplomové práce, které je součástí také této práce, je praktickou ukázkou tiskového výstupu ze zmíněné aplikace.

70

11

Aplikace pro studijní administrativu

V kapitole budou uvedeny informace o aplikacích, které jsou spojené se studijní administrativou, a které nejsou vyučujícím ani studentům přístupné.

11.1

Studijní evidence

Aplikace Studijní evidence umožňuje studijní referentce provádět manipulace se studijními informacemi studentů a udržovat tak agendu studentů v aktuálním stavu. Jak bude zřejmé z dalšího popisu, možnosti manipulace se studiem jsou značné, to je nutné zejména proto, aby studijní referentky mohly spravovat studijní agendu operativně samy a těmito operacemi nebyli zatěžováni datamanažeři vývojového týmu. Karta studenta Základní obrazovkou je karta studenta, která poskytuje souhrnné informace o studentovi. Vedle fotografie jsou základní personální údaje (kontaktní adresa, telefonní spojení, e-mail apod.) a ikony pro funkce, které se vztahují k uživateli. Pod uživatelskými informacemi je zobrazen seznam studií řazených podle data nástupu. Nejprve jsou uvedena studia, která ještě nebyla ukončena, za nimi následují studia ukončená. Odkazy na funkce mají vztah k příslušnému studiu. Všechny běžné manipulace je možné provádět pouze se studii, která ještě nebyla ukončena. Studia, která již byla ukončena, je možné pouze prohlížet a není možné je modifikovat. Pokud má student aktivní studium také na jiné fakultě, jsou zobrazeny informace pouze o fakultě a oboru studia bez možnosti nahlížet na podrobnější informace nebo je dokonce měnit. Pro úplnost jsou zobrazovány také informace o případném zaměstnaneckém poměru studenta na univerzitě (informace přebíraná z ekonomického informačního systému) a údaje o studiích na jiných vysokých školách (získané ze sdružené matriky studentů). Ukázka karty studenta je zařazena v příloze jako obr. 14. Průchod studiem Přes odkaz Průchod studiem v kartě studenta je umožněn vstup do sestavy průchodu studiem. V sestavě jsou chronologicky uvedena období studia (od nejnovějšího směrem k nejstaršímu) a u každého je zobrazena informace o začátku a konci období, datu zápisu studenta, kódu studia, studijním průměru, přerušení studia a odkaz na seznam předmětů studovaných v daném období. Pod sestavou je sada ikon zpřístupňující další funkce modifikující studium (zahájení nebo ukončení přerušení, změna studijního oboru, formy a specializace apod.). 71

11.2

Sestava V7

Studované předměty Seznam studovaných předmětů obsahuje všechny předměty zapsané studentem do určitého období. Pro každý předmět je vypsán jeho kód, název, zapsané ukončení, dosažený výsledek a celkový počet pokusů potřebný k dosažení tohoto výsledku, kredity udělené za předmět a informace o tom, kdo a kdy zadal poslední výsledek předmětu. Také je dostupný odkaz na úpravu výsledků předmětu, kde je možné libovolně modifikovat dosažené výsledky. Pod seznamem je zobrazen počet kreditů získaných v daném období. Do tohoto součtu jsou započítávány pouze kredity za úspěšně ukončené předměty. Libovolný předmět je možné odebrat, pokud nemá zadané hodnocení. V případě, že je u předmětu již zadané nějaké hodnocení, je nutné nejprve ručně odstranit všechna hodnocení předmětu. Teprve pak je možné předmět odebrat. Uvedený postup byl zvolen proto, aby se zabránilo náhodnému smazání vlivem chyby obsluhy. Pokud by studijní referentka omylem smazala předmět a automaticky by tím odstranila i dosažené hodnocení, bylo by obtížné získat údaje zpět (obnova ze zálohy je značně náročný proces). Referentka také může studentovi přidat předmět, pokud je pro to důvod. Uznané předměty se vkládají obdobným způsobem. Příklad seznamu studovaných předmětů je v příloze na obr. 15.

11.2

Sestava V7

Nezbytnou součástí protokolu o vykonané státní zkoušce (ať už bakalářské nebo magisterské) je sestava označovaná V7. Tato sestava obsahuje souhrn veškerých informací o studiu: • personální údaje o studentovi a základní informace o studiu, ke kterému se sestava V7 vztahuje, • pro každé studované období informace o předmětech podobně jako v aplikaci studijní evidence Studované předměty, • sumarizované informace za jednotlivá období (počty předmětů, součet získaných kreditů, studijní průměr apod.), • informace sumarizované za celou dobu studia (údaje jsou podobné jako u jednotlivých období). Sestava V7 také slouží studijním referentkám při kontrole indexů studentů před státní závěrečnou zkouškou, jestli splnili všechny povinnosti předepsané studijním programem. Na základě studijních výsledků obsažených ve V7 je také zkoumán nárok studenta na vyznamenání. Sestavu V7 je možné zobrazit nebo vytisknout pro jednoho studenta individuálně nebo hromadně více studentům na základě výběru. Protože ve V7 jsou obsaženy kompletní informace o studovaných předmětech a příslušných výsledcích, je možné použít tuto sestavu také při přestupu studenta z jiné vysoké školy nebo na jinou vysokou školu.

72

11.3

11.3

Závěrečná vysvědčení a diplomy

Závěrečná vysvědčení a diplomy

Na závěr studia student skládá státní závěrečnou zkoušku z odborných předmětů. Některé z těchto předmětů jsou pro daný studijní program předepsány, jiné si student volí sám. Závěrečné vysvědčení student dostává spolu s diplomem. Na vysvědčení jsou napsány známky z jednotlivých předmětů státní závěrečné zkoušky, známka za závěrečnou práci a celková známka. Aplikace na zadávání a tisk závěrečných vysvědčení podporuje právě tuto agendu. Studijní oddělení připraví šablony pro jednotlivé studijní programy (obdobně jako připravuje doporučené plány studia) a na základě přihlášek k závěrečným zkouškám doplní jednotlivým studentům volitelné předměty, které uvedli na přihlášce. Po vykonání závěrečné zkoušky je k předmětům doplněno hodnocení. Následuje tisk závěrečných vysvědčení a tisk diplomů úspěšným studentům. Těmto studentům je ukončeno jejich studium, jsou převedeni mezi absolventy, pokud nemají žádný další vztah k univerzitě, jsou jim odebrána povolení přístupu do univerzitní knihovny, menzy a prostor chráněných přístupovým systémem.

73

12

Spolupráce se státními institucemi

S činností univerzity souvisí také nezbytná komunikace se státními institucemi. Zákony je univerzitě uložena povinnost poskytovat údaje instituci zabývající se zpracováním statistických výkazů, zasílat informace o svých studentech do celostátní sdružené evidence studentů a přihlašovat nebo odhlašovat studenty a zaměstnance z pojišťovny.

12.1

Pojišťovna

Podle zákona o veřejném pojištění (Zákon o veřejném pojištění) je plátcem pojištění za určité skupiny osob stát. Tyto skupiny osob jsou vymezeny v paragrafu 7 citovaného zákona a mezi ně patří i studenti soustavně se připravující na budoucí povolání do 26 let. Z Univerzitního informačního systému jsou získávány pouze údaje o studentech. Univerzita má povinnost hlásit pojišťovně veškeré změny, ke kterým dochází. Každý měsíc je do pojišťovny odesílána sestava v dohodnutém tvaru, ve které jsou obsaženy informace o osobách, kterým vznikl nárok na úhradu pojištění státem (tedy byli zapsáni do studia, ukončili přerušení apod.), a také o osobách, kterým tento nárok zanikl (zahájili přerušení, ukončili studium apod.). Na straně Univerzitního informačního systému jsou evidovány všechny nároky na pojištění po jednotlivých měsících do historie. Při vytváření sestavy pro pojišťovnu je nejprve uložen do tabulky uchovávající předchozí stavy pojištění (SA_POJISTOVNA_STAV) aktuální stav. Poté jsou do tabulky SA_POJISTOVNA vygenerovány nové údaje o nárocích na pojištění. Nový stav je porovnán s předchozím stavem a rozdíly jsou zaznamenány do výstupní sestavy. Skript generující sestavu je spouštěn ručně, sestava pro pojišťovnu je předávána na rektorát a z rektorátu je následně odesílána do pojišťovny.

12.2

Ústav pro informace ve vzdělávání

Ústav pro informace ve vzdělávání (zkráceně označován ÚIV) je příspěvkovou organizací přímo řízenou Ministerstvem školství, mládeže a tělovýchovy. ÚIV zajišťuje následující funkce: • statistickou – vypracovává a spravuje statistické údaje v oblasti školství, • informační a knihovnickou – spravuje Státní pedagogickou knihovnu Komenského, odborné a laické veřejnosti poskytuje informační služby v oblasti vzdělávání a školství, vydává odborné publikace v oboru školství a vzdělávání, • výzkumnou a analytickou – zastupuje Českou republiku v mezinárodních výzkumech v oblasti školství, zpracovává analýzy a prognózy stavu a rozvoje vzdělávacího systému, 74

12.3

Matrika studentů

• koordinační – pracuje např. na reformě maturitní zkoušky. Na základě uvedené statistické funkce také organizuje sběr údajů ze školství. Školy zasílají ÚIV řadu výkazů, které jsou následně zpracovávány, a zveřejněny ve statistických přehledech. Informace o výkazech sbíraných od vysokých škol je uveřejněna v elektronické podobě na Internetu (ÚIV – Výkazy). Ze všech výkazů jsou získávána z Univerzitního informačního systému pouze data pro výkaz Uchazeč. Vysoké školy zasílají ÚIV dvakrát ročně informace o svých uchazečích. Poprvé je sběr dat prováděn na jaře (informace o uchazečích), podruhé jsou data sbírána na podzim (doplnění informací o výsledcích přijímacího řízení a zápisu studentů ke studiu). Přesné termíny sběru dat, metodika sběru, struktura datových vět, aktuality a další důležité informace jsou zveřejňovány na Internetu (ÚIV – Uchazeč 2003). Před odesláním výkazu je ručně spuštěn skript, který zjistí potřebné informace z databáze UIS, a vygeneruje soubory ve formátu DBF se strukturou věty předepsanou ÚIV. Pro každou fakultu je vytvořen jeden datový soubor označený jejím kódem. Soubory jsou pak předány kontaktní osobě na univerzitě (v současnosti je jí vedoucí Oddělení automatizace informační soustavy – Ing. Jana Břeňová). Kontaktní osoba má povolen přístup na webovou aplikaci na stránkách ÚIV, jejímž prostřednictvím jsou soubory přeneseny. Po určité době od odeslání údajů je možné na stránkách ÚIV v sestavách přijatých dat zkontrolovat výsledek zpracování odeslaného souboru.

12.3

Matrika studentů

Zákon o vysokých školách (Zákon o vysokých školách) ukládá vysokým školám povinnost vést matriku studentů, která slouží k evidenci o studentech a k rozpočtovým a statistickým účelům. Matrika obsahuje údaje o jednotlivých studentech vysoké školy zapsaných do bakalářského, magisterského nebo doktorského studijního programu. Zápis nově přijatých studentů do matriky se provádí neprodleně po zápisu studenta do studia v příslušném studijním programu. Pro rozpočtové a statistické účely mohou být využívány údaje o jednotlivých studentech pouze tehdy, jsou-li zpracovávány prostředky výpočetní techniky, a to formou databáze vytvořenou příslušnou vysokou školou. Proto zákon o vysokých školách, který opravňuje Ministerstvo školství, mládeže a tělovýchovy ČR (dále jen ministerstvo) sdružovat a využívat informace z matriky studentů, současně zmocňuje ministerstvo stanovit strukturu informační věty provozované databáze a její technické podmínky. Ministerstvo vypracovalo strukturu informační věty databáze z matriky studentů ve spolupráci s Ústavem výpočetní techniky Masarykovy univerzity v Brně s ohledem na již existující počítačově zpracovanou studijní agendu na vysokých školách. V této struktuře jsou matriky všech vysokých škol ČR (veřejných i soukromých) shromažďovány v centrální databázi nazvané Sdružené informace matrik studentů (označované zkráceně SIMS), nad níž je budován stejnojmenný informační systém sloužící potřebám ministerstva i vysokých škol. Provozovatelem databáze i souvisejícího informačního systému SIMS je ministerstvo. 75

12.3

Matrika studentů

Každá vysoká škola, veřejná nebo soukromá, je povinna uložit do centrální databáze svou matriku studentů a trvale ji doplňovat a aktualizovat periodickými sběry dat (uskutečňovanými zpravidla čtyřikrát ročně). Nově zřizované vysoké školy jsou povinny se přihlásit do systému SIMS neprodleně po svém zřízení a svou matriku studentů uložit do centrální databáze při nejbližším hromadném sběru dat následujícím po prvním zápisu studentů ke studiu. Ministerstvo přiděluje každé vysoké škole její přihlašovací jméno a heslo do systému SIMS a autorizovanou písemnou formou je předává akademickému vedení školy, zpravidla k rukám rektora. Správce matriky vysoké školy, pověřený vedením školy zodpovědností za správnost a úplnost údajů vedených za tuto školu v centrální databázi a vybavený přihlašovacím jménem a heslem přiděleným ministerstvem, má v systému SIMS k dispozici prostředky pro vytváření dalších uživatelských účtů v rozsahu své pravomoci. Věty pro matriku jsou generovány soustavou triggerů při jakékoliv sledované změně studia: • zahájení nového studia, • ukončení studia, • přestup studenta na jiný studijní program nebo obor, • změna studijní specializace, • změna formy studia, • zahájení a ukončení přerušení, • zápis do dalšího období studia. Sběr matriky je prováděn podobně jako v případě sběru dat ÚIV – je vygenerován soubor s předepsanou strukturou vět, následně je vygenerovaný soubor odeslán pomocí webové aplikace ke zpracování a poté jsou na stránce uveřejněny informace o výsledku importu dat do matriky.

76

13

Závěr

V současnosti je možné hodnotit projekt zavádění studijního systému v Univerzitním informačním systému do provozu jako úspěšný. Všechny fakulty od září roku 2002 přešly od evidence studentů v původním systému STUDENT na evidenci studentů v UIS. Aktuálně poskytovaný rozsah funkcionality, který pokrývají aplikace studijního systému, umožňuje vedení studijní agendy v plném rozsahu a stal se primárním zdrojem informací o studentech univerzity pro všechny ostatní systémy provozované na univerzitě. Nově zavedený systém se po počáteční nedůvěře stal běžnou součástí života univerzity a je uznáván jak u vedení univerzity, tak i běžnými uživateli. Studenty je velmi kladně hodnocena možnost přístupu ke studijním informacím o studiu, aniž by museli fyzicky navštívit školu (elektronické zapisování na zkoušky, sdělování výsledků zkoušek apod.). Učitelům poskytuje UIS širší možnosti komunikace se studenty. Studijním referentkám UIS umožňuje rychlejší a efektivnější práci automatizací rutinních úkolů a podporou jejich běžné práce. Systémoví integrátoři fakult se stali rovnocennými partnery vedení svých fakult a velmi významně pomáhají při zavádění informačního systému ve specifickém prostředí vlastní fakulty. Zpětnou vazbou od integrátorů jsou informace pro vývojový tým pro nově řešené aplikace. Velmi se zlepšila také komunikace a výměna informací mezi pedagogickou komisí rektora a vývojovým týmem. Nevýhodou současného systému je nutnost ručního generování sestav a souborů, které jsou odesílány státním institucím. Tím se do celého procesu odeslání údajů zapojuje další osoba datamažera. Řešením by bylo vytvoření aplikací v UIS, které by generovaly požadované výkazy přímo osobám, které tyto výkazy odesílají. Případně další možností je vytvoření aplikace komunikující přímo s cílovou institucí. Další rozvoj studijního systému se bude ubírat směrem elektronické podpory agend, které jsou zatím vedeny v papírové podobě (např. rezervace učeben), tedy další podpora operativního řízení. Oblastí, která zatím není řešena ve studijním systému vůbec, je podpora střednědobého řízení univerzity (manažerský informační systém). Velikou oblastí, která bude také řešena v Univerzitním informačním systému, je oblast vědy a výzkumu. Autor této práce díky svému dvouletému působení ve vývojovém týmu získal bohaté zkušenosti spojené s tvorbou a implementací rozsáhlého systému v různorodém prostředí univerzity. Později v pozici vedoucího vývojového týmu získal zkušenosti nejen s řízením pracovního kolektivu, ale také s jednáním s vrcholovým vedením univerzity, které zde vystupuje v roli zadavatele projektu.

77

14

Literatura

Bartík, L. Registrace a zápis v UIS. Demonstrátorská práce. Brno: MZLU, 2002. Bartík, L. Portálová aplikace Záznamník učitele. Diplomová práce. Brno: MZLU, 2003. In press. CPAN – Comprehensive Perl Archive Network. Webové stránky archivu. http://www.cpan.org. CTAN – Comprehensive TEX Archive Network. Webové stránky archivu. http://www.ctan.org. Dařena, F. Jádro Univerzitního informačního systému. Diplomová práce. Brno: MZLU, 2002. Ensor, D. – Stevenson, I. Oracle Design. Sebastopol, CA, USA: O’Reilly & Associates, 1997. ISBN 1-56592-268-9. Greenwald, R. – Stackowiak, R. – Stern, J. Oracle Essentials: Oracle8 and Oracle8i. Sebastopol, CA, USA: O’Reilly & Associates, 1999. ISBN 1-56592-708-7. Loney, K. – Theriault, M. Mistrovství v Oracle. Praha: Computer Press, 2002. ISBN 80-7226-635-7. Olšák, P. Typografický systém TEX Brno: CSTUG, 1995. ISBN 80-901950-0-8. Riordan, R. M. Vytváříme relační databázové aplikace. Praha: Computer Press, 2000. ISBN 80-7226-360-9. Rybička, J. LATEX pro začátečníky. 2. vydání. Brno: Konvoj, 1999. ISBN 80-85615-74-6. Stejskal, L. E-mailový informační systém. Diplomová práce. Brno: MZLU, 2002. In press. Studijní a zkušební řád Mendelovy zemědělské a lesnické univerzity v Brně. Registrován Ministerstvem školství, mládeže a tělovýchovy dne 8. listopadu 2000 pod čj. 30 473/2000-30. Dokument ve formátu HTML. http://www.mendelu.cz/rektorat/studium99/studijni rad2000.html. Šimůnek, M. SQL: kompletní kapesní průvodce. Praha: Grada Publishing, 1999. ISBN 80-7169-692-7. Šorm, M. Databázová SQL konzole dbMan. Bakalářská práce. Brno: FI MU, 1999. Šorm, M. a kol. Fakultní informační systém. In Informatika VII/2000. Brno: MZLU, 2000. Šorm, M. Univerzitní informační systém. Diplomová práce. Brno: MZLU, 2002. Šorm, M. dbMan – modulární SQL konzole. In SLT 2002. Brno: Konvoj, 2002. Ústav pro informace ve vzdělávání, Oddělení metodiky a zpracování dat – Uchazeč 2003. Dokument ve formátu HTML. http://dsia.uiv.cz/uch2003.html [cit. 5. 4. 2003].

78

14

LITERATURA

Ústav pro informace ve vzdělávání, Oddělení metodiky a zpracování dat – Výkazy. Dokument ve formátu HTML. http://dsia.uiv.cz/vykazy.html [cit. 5. 4. 2003]. Virius, M. Od C k C++. Praha: Kopp, 2000. ISBN 80-7232-110-2. Voříšek, J. Informační technologie a systémová integrace. Praha: VŠE, 1996. ISBN 80-7079-895-5. Voříšek, J. Informační systémy a jejich řízení. Praha: SERIFA, 1997. ISBN 80-7265-002-5. Wall, L. – Christiansen, T. – Schwartz, R. Programování v jazyce Perl. Praha: Computer Press, 1997. ISBN 80-85896-95-8. Zákon o veřejném zdravotním pojištění a o změně a doplnění některých souvisejících zákonů č. 48/1997 Sb. Dokument ve formátu PDF. http://www.mvcr.cz/sbirka/1997/sb016-97.pdf. Zákon o vysokých školách a o změně a doplnění dalších zákonů (zákon o vysokých školách) č. 111/1998 Sb. Dokument ve formátu PDF. http://www.mvcr.cz/sbirka/1997/sb039-98.pdf.

79

Přílohy

A

Ukázky aplikací studijního systému

V této příloze jsou ukázky vzhledu několika aplikací, které jsou součásti studijního systému v Univerzitním informačním systému.

Obr. 13: Zobrazení rozvrhu učitele

81

A UKÁZKY APLIKACÍ STUDIJNÍHO SYSTÉMU

Obr. 14: Aplikace Studijní evidence

82

A UKÁZKY APLIKACÍ STUDIJNÍHO SYSTÉMU

Obr. 15: Zobrazení studovaných předmětů (součást aplikace Studijní evidence)

83

A UKÁZKY APLIKACÍ STUDIJNÍHO SYSTÉMU

Obr. 16: Aplikace Katalog předmětů 84