diplomovka

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

Univerzitní informační systém

Diplomová práce

Vedoucí práce:Doc. Ing. Arnošt Motyčka, CSc.

Milan Šorm

Brno 2002

Chtěl bych touto formou poděkovat vedoucímu své diplomové práce, Doc. Ing.Arnoštu Motyčkovi, CSc., za celkovou podporu a ochrannou ruku, kterou poskyto-val a poskytuje mně a ostatním vývojovým pracovníkům Univerzitního informačníhosystému v průběhu řady uplynulých let. Také bych chtěl poděkovat všem vývojovýmpracovníkům Fakultního i Univerzitního informačního systému, kteří se mnou spo-lupracovali a spolupracují při mém úsilí ve tvorbě toho nejlepšího systému pro našiuniverzitu. Rovněž chci poděkovat vývojovým pracovníkům Informačního systémuMasarykovy univerzity (a především CVT FI MU), kteří mi byli velkou inspirací přitvorbě našeho informačního systému. Nakonec chci poděkovat svým rodičům a blíz-kým za pomoc při korekturách tohoto textu a za jejich trpělivost, když jsem čas odčasu nedorazil večer domů z důvodu kompletní reinstalace Oracle nebo přeprogra-mování některého zásadního modulu informačního systému.

Prohlašuji, že jsem tuto diplomovou práci vyřešil samostatně s použitím literatury,kterou uvádím v seznamu. Na tvorbě vlastního informačního systému se pod mýmvedením podílely další dvě desítky osob. Velkou inspirací pro mne byl Informačnísystém Masarykovy univerzity.

V Brně dne 20. května 2002 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

Abstract

Šorm, M. University information system. Diploma thesis. Brno, 2002.

This text is oriented to the analysis and implementation of the basic structureof University information system on Brno Mendel University of Agriculture andForestry. The main part of the work introduces the structure of the system, themethodics used and documents all known or newly created methods for buildingweb information system in a specific environment of higher education. The complexdata model of the 1st phase of such an information system realization is a constituentpart of this work.

Abstrakt

Šorm, M. Univerzitní informační systém. Diplomová práce. Brno, 2002.

Práce se zabývá analýzou a implementací základní struktury Univerzitního in-formačního systému Mendelovy zemědělské a lesnické univerzity v Brně. Stěžejníčást práce představuje strukturu systému, použitou metodiku tvorby a dokumen-tuje nastudované, příp. nově vytvořené metody pro tvorbu webových informačníchsystémů ve specifickém prostředí vysokého školství. Součástí práce je rovněž kom-pletní datový model 1. etapy realizace tohoto informačního systému.

OBSAH 5

Obsah

1 Úvod a cíl práce 71.1 Úvod do problematiky . . . . . . . . . . . . . . . . . . . . . . . . . . 71.2 Cíl práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 Základní pojmy 10

3 Současný stav IS/ICT 153.1 Trendy mající globální ekonomicko–společenský význam . . . . . . . 153.2 Trendy mající vztah k ekonomice, řízení a organizaci podniku . . . . 173.3 Trendy v oblasti základního software . . . . . . . . . . . . . . . . . . 183.4 Trendy v oblasti aplikačního software . . . . . . . . . . . . . . . . . . 193.5 Trendy v oblasti informačních technologií . . . . . . . . . . . . . . . . 213.6 Trendy v oblasti metod a nástrojů vývoje IS/ICT . . . . . . . . . . . 223.7 Trendy v organizaci a řízení IS/ICT . . . . . . . . . . . . . . . . . . . 26

4 Architektura moderních informačních systémů 284.1 Vertikální struktura IS . . . . . . . . . . . . . . . . . . . . . . . . . . 284.2 Horizontální struktura IS . . . . . . . . . . . . . . . . . . . . . . . . . 304.3 Horizontálně–vertikální struktura IS . . . . . . . . . . . . . . . . . . . 304.4 Třívrstvá architektura informačních systémů . . . . . . . . . . . . . . 31

5 Metody řízení vývoje a provozu IS 345.1 Životní cyklus projektu . . . . . . . . . . . . . . . . . . . . . . . . . . 345.2 Modely životního cyklu IS . . . . . . . . . . . . . . . . . . . . . . . . 385.3 Způsob pořízení informačního systému . . . . . . . . . . . . . . . . . 405.4 Metoda řízení vývoje a provozu UIS . . . . . . . . . . . . . . . . . . . 425.5 Řízení lidských zdrojů ve specifických podmínkách UIS . . . . . . . . 45

6 Základní cíle UIS 476.1 Administrativní podmínky a uživatelé systému . . . . . . . . . . . . . 476.2 Technické podmínky . . . . . . . . . . . . . . . . . . . . . . . . . . . 486.3 UIS jako priorita univerzity . . . . . . . . . . . . . . . . . . . . . . . 49

7 Architektura UIS 507.1 Technická architektura . . . . . . . . . . . . . . . . . . . . . . . . . . 507.2 Aplikační architektura . . . . . . . . . . . . . . . . . . . . . . . . . . 537.3 Datově–logická architektura . . . . . . . . . . . . . . . . . . . . . . . 56

8 Teorie webových informačních systémů 598.1 Jednotlivé aspekty teorie WIS . . . . . . . . . . . . . . . . . . . . . . 598.2 Budoucnost teorie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

OBSAH 6

9 Jednotlivé rodiny aplikací 679.1 Plánovaný projekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679.2 Aktuální stav vývoje . . . . . . . . . . . . . . . . . . . . . . . . . . . 719.3 Ukázka podrobné analýzy . . . . . . . . . . . . . . . . . . . . . . . . 71

10 Zhodnocení dosavadního vývoje 7210.1 Směry dalšího vývoje . . . . . . . . . . . . . . . . . . . . . . . . . . . 7210.2 Přínos UIS pro IS/ICT . . . . . . . . . . . . . . . . . . . . . . . . . . 7310.3 Poznatky a zkušenosti z provozu, zpětná vazba . . . . . . . . . . . . . 74

11 Závěr 76

12 Literatura 77

Přílohy 79

A Ukázka analýzy Studijní agendy 80

B Grafy využití FIS a UIS 91

C Vybrané ukázky aplikací z UIS 94

1 ÚVOD A CÍL PRÁCE 7

1 Úvod a cíl práce

1.1 Úvod do problematiky

Na naší univerzitě, stejně jako na mnoha dalších v naší zemi, je postupně zavá-děn kreditní systém ECTS, který má studentům umožnit mezioborová, mezifakultnía meziuniverzitní studia. Tento systém ohodnocuje jednotlivé etapy studia studentapomocí kreditů, které slouží jako ukazatel postupu studenta při studiu.Vzhledem k tomu, že části studia (jednotlivé předměty, semestry, ročníky aj.)

může student studovat na různých fakultách či dokonce školách, jedná se o jediný vě-rohodný ukazatel odrážející studentovy výsledky. Pro nezúčastněného pozorovateletento systém vypadá jako individuální studijní plán pro všechny studenty s možnostístudovat téměř cokoliv prakticky kdekoliv.Množství relevantních informací, které je nutné o každém studentovi evidovat,

ovšem při použití tohoto systému roste vysokou měrou. Pro sběr, třídění, uchovávánía získávání těchto dat je proto třeba použít prostředky výpočetní techniky. Ucelenýsoubor aplikací a příslušných dat potom představuje rozsáhlý studijní informačnísystém.Protože je však studium jednou ze stěžejních náplní činnosti vysoké školy, sou-

visí se studiem celá řada dalších skutečností. I tyto údaje je nutné v informačnímsystému podchytit. Pokud přidáme ještě druhou nejvýznamnější oblast působenívysoké školy – vědu a výzkum, dostáváme dohromady rozsáhlý integrovaný infor-mační systém, který je na naší škole souhrně nazýván Univerzitní informační systém,zkráceně UIS.Jedinou zásadní oblastí, která není v UISu zpracována, je provozní informační

systém školy (ekonomika a řízení), který je nyní provozován v systému EkonFIS. Lzeovšem předpokládat, že později bude provozní informační systém rovněž začleněn doUIS ať již v podobě systému vyvíjeného stávajícím vývojovým týmem nebo v podoběexterně dodaného systému.Aby bylo možné vytvořit Univerzitní informační systém, byl na naší škole vy-

budován Vývojový tým UIS, jehož úkolem bylo problematiku metodicky zpracovat,provést analýzu celého systému i jeho dílčích modulů a systém naimplementovat. Podobu vývoje systému tato skupina zajišťuje také rutinní provoz celého systému, poz-ději však tento provoz přejde na Oddělení automatizace informační soustavy příp.Ústav výpočetní techniky.Vývojový tým působí na naší univerzitě od roku 1998. V roce 1999 představil

pilotní projekt v podobě Fakultního informačního systému (miniFis) pro Provozněekonomickou fakultu, který v roce 2001 pokrýval většinu hlavních studijních agendtéto fakulty. Úspěch tohoto systému umožnil zahájit v roce 2001 práce na Univer-zitním informačním systému, kde bylo využito poznatků a zkušeností ze systémuminiFis.V současné době je vývoj miniFis již ukončen a probíhá jeho postupné odstavo-

vání z provozu. Velká většina jím řízených agend přechází do nových aplikací UIS,

1.2 Cíl práce 8

který je pro Provozně ekonomickou fakultu nasazen plně již od letního semestru2001/2002, pro zbytek univerzity pak od zimního semestru 2002/2003.Mým úkolem bylo koordinovat práci Vývojového týmu od jeho vzniku do dneš-

ních dní. Podílel jsem se především na základní koncepci celého informačního sys-tému, na podobě datového modelu a na analýzách jednotlivých částí informačníhosystému. V systému miniFis jsem byl autorem jádra tohoto systému a řady studijníchi nestudijních aplikací. V systému UIS se zabývám hlavně koncepční a analytickouprací.Získané zkušenosti jsou shromážděny v této diplomové práci, která je současně

základní metodickou příručkou pro porozumění Univerzitnímu informačnímu sys-tému jako jednomu z typových webových informačních systémů. Na tuto práci na-vazuje řada dílčích diplomových prací rozebírajících jádro a jednotlivé části UIS.Řada myšlenek uvedených v této práci vychází z doporučené literatury nebo

je inspirována Informačním systémem Masarykovy univerzity. Žádné myšlenky všaknebyly převzaty doslova. Vždy jsem se pokoušel nalézt řešení, které je originálnía vhodně zapadá do celé koncepce našeho informačního systému. Pokud se to někdenepovedlo (což se později ukázalo), bylo nutné celou část systému k velké nelibostiuživatelů přepracovat. To by ovšem nebylo možné bez podnětných myšlenek ostat-ních spolupracovníků z Vývojového týmu.

1.2 Cíl práce

Cílem této práce bude poskytnout všem čtenářům vysvětlení všech myšlenek, kterébyly použity při tvorbě Univerzitního informačního systému. Do okruhu jejich čte-nářů budou nepochybně patřit především vývojoví pracovníci Vývojového týmu,kteří touto prací konečně získají základní dokumentaci popisující myšlenky a me-tody, které musí denně používat ve své práci.Druhou významnou skupinou čtenářů budou systémoví integrátoři jednotlivých

fakult a pracovišť, kteří díky této práci získají představu o struktuře a vazbáchuvnitř informačního systému a ušetří si hodně práce zkoumáním a experimentová-ním s jednotlivými zdánlivě nesouvisejícími (avšak navzájem propojenými) částmisystému. Při současném stavu informovanosti se pro ně systém v mnoha ohledechchová jako černá skříňka, která odpovídá na základě vnějších podnětů a snižuje činaopak zvyšuje entropii svých uživatelů.Ostatním čtenářům se ve své práci představím prototyp funkčního webového

informačního systému, který pokrývá řadu činností velké instituce, jako je MZLUv Brně (zhruba osm tisíc uživatelů).Základem pro tuto práci bude seznámení se s architekturou moderních infor-

mačních systémů IS/ICT s důrazem především na moderní třívrstvou architekturu.Na základě zjištěného stavu IS/ICT u nás a znalosti moderní architektury budemožné analyzovat možnosti využití webových technologií při návrhu a realizaci in-formačního systému nejen pro naši vysokou školu (obecný webový informační systémpodniku).

1.2 Cíl práce 9

Hlavní přínos této práce bude spočívat ve vytvoření analýzy IS/ICT informač-ního systému pro naši univerzitu s hlavním důrazem na studijní agendu, která budepodrobně rozpracována. Vytvořený systém bude ve spolupráci s vývojovým týmemimplementován (nejprve oblast studijní agendy) na Provozně ekonomické fakultěa následně na celé univerzitě.Pro vlastní práci bude nutné nastudovat základní literaturu z oboru IS/ICT,

odzkoušet nové technologie na prototypových příkladech a vyhledat odbornou speci-alizovanou literaturu o studované problematice (bude shrnuta v seznamu literaturya citována ve vlastní práci).

2 ZÁKLADNÍ POJMY 10

2 Základní pojmy

Větší část této práce se zabývá poměrně úzkou problematikou informačních systémůa informačních a komunikačních technologií. Tato problematika se často označuje téžzkratkou IS/ICT. Stejně jako řada jiných úseků informatiky, i tato část informatickévědy kolem sebe vytvořila řadu pojmů a definic, bez jejichž znalosti nelze pochopitproblematiku v celé své šíři.Tato kapitola vysvětluje nejzákladnější pojmy běžně užívané jak v odborné

literatuře, tak v každodenní práci analytiků, programátorů a dalších specialistů pů-sobících v této oblasti. U každého pojmu je podána definice na základě obecnéencyklopedie [9] a doplňující vysvětlení, jak příslušný termín chápe osoba s informa-tickým vzděláním.

Informace

Informace je obsah zprávy, který je definován jako záporný dvojkový logaritmus jejípravděpodobnosti a vyjadřuje se v bitech. Ve své podstatě jde o velikost sníženíentropie (neznalosti) příjemce zprávy. Člověk informacím přisuzuje konkrétní vý-znam a příjem informací uspokojuje jednu z významných potřeb člověka – potřebupoznávání. Informace jsou nehmotné (a proto i obnovitelné) a lze je zaznamenatfyzickým procesem (např. pořídit digitální záznam informace). V řadě podniků jiždnes představují informace nejcennější majetek společnosti (patenty, postupy, tech-nologie, ale i informační systémy – bankovní systémy, pojišťovací systémy, systémyřízení výroby, marketingu, logistiky či managementu).

Data

Slovo data vychází z latinského datum a pod tímto pojmem rozumíme informace,které jsou předmětem zpracování ve výpočetních systémech. Informatika proto hledázpůsob, jak zaznamenat informace pomocí dat prostředky výpočetní techniky. Propotřeby této práce jsou data veškeré informace, které mají nějaký vztah k Univer-zitnímu informačnímu systému (např. je potřebuje nějaký jeho uživatel ze systémuzískat).

Informatika

Je věda o základech elektronického zpracování dat a její aplikace (teoretická informa-tika, technická informatika, kybernetika, . . . ). V našem pojetí budeme informatikourozumět vědu zabývající se přesně tím, co bylo uvedeno u pojmu data (hledánízpůsobu reprezentace a získávání dat prostředky výpočetní techniky).

Elektronické zpracování dat

Podle definice je tímto pojmem myšleno obsažné a účelné zpracování dat provedenéstrojem, převážně počítačem, ze zadných údajů (dat) s cílem ušetřit lidskou práci


a čas a zabránit chybám a omylům. Strojové zpracování dat všeho druhu vyžaduje je-jich převod do takové psané formy, které bude stroj rozumět (kódování dat). Obvyk-lým systémem elektronického zpracování dat je informační systém, který zajišťujezískávání, přenos, zpracování, uchovávání a prezentaci informací všem uživatelům.

Informační systém

Informační systém je identifikovatelný funkční celek zabezpečující cílevědomé a sys-tematické shromažďování, zpracovávání, uchovávání a zpřístupňování informací ulo-žených na hmotném nosiči v údajových základnách a reprodukovatelných technic-kými prostředky. Informační systém zahrnuje informační základnu (data), technickéa programové prostředky, technologie, finanční prostředky, procedury a pracovníky.Informační systém může a nemusí zahrnovat počítačový systém nebo subsystém.Informační systémy tvoříme na základě současné informační a komunikační techno-logie.

Informační technologie

Pod pojmem informační technologie obvykle myslíme soubor nástrojů, metod a zna-lostí sloužících k činnostem, k nimž je informační systém určen (sběr, uchování, pře-nos a prezentace informací). Rovněž informační technologie představují zákonitostivývoje a výroby informačních produktů – tedy především informačních systémů.Často tento pojem také představuje základní směr myšlení jedné epochy nebo jednékultury (informační generace, informační kultura, informační společnost). Techno-logie je správný název pro to, čemu dnes nesprávně říkáme technika (technika jsoupouze hmotné prostředky sloužící příslušné technologii k dosažení cíle).

Informační strategie

Informační strategie je ucelenou soustavou cílů a způsobů vedoucích k dosaženítěchto cílů. Cíli této strategie je pak především zvyšování výkonnosti podniku, pod-pora dosažení strategických cílů podniku a získání strategické výhody. Základnímyšlenkou informační strategie je nutnost dodržet soulad mezi globální podnikovoustrategií a integrací informačního systému. Pouze při naplňování informační stra-tegie dochází k plnění strategických cílů podniku (ostatní případy vedou nutně kestagnaci a úpadku).

Systémová integrace

Systémová integrace je jeden z hlavních principů modelu řízení vývoje, provozua užití informačního systému, jehož cílem je komplexní a integrovaný informačnísystém organizace. Tohoto cíle lze dosáhnout převážně optimální kombinací a in-tegrací vhodných komponent a služeb od různých dodavatelů. Systémová integrace


jako princip řízení informačního systému zohledňuje specifické nároky na řízení in-formačního systému, vyplývající z vysoké heterogenity produktů, služeb a jejichdodavatelů současných informačních technologií.Současně je systémová integrace také procesem zajišťujícím propojení (inte-

graci) podniku a informačního systému. Musí se přihlížet k tomu, aby informačnísystém splňoval požadavky na něj kladené, aby byl budován jako celek, na základějasné a srozumitelné architektury a přesně vymezených standardů. Samotná inte-grace pak probíhá na několika úrovních – na úrovni datové, aplikační, hardwarovéa technologické, metodické, na úrovni podnikových procesů a úrovni uživatelskéhorozhraní. Osoba či podnik, který tyto činnosti provádí, se nazývá systémový inte-grátor.

Integrovaný informační systém

Každý informační systém řeší úzce specifickou oblast a splňuje konkrétní dílčí cíle.Pokud však informační systém pokrývá oblast činnosti celé organizace a splňuje jejístrategické cíle, můžeme jej nazvat integrovaným informačním systémem. Takovýsystém je složen z dílčích informačních systémů složených dohromady pomocí me-tody řízení zvané systémová integrace. Současným světovým trendem je směřováníinformační strategie podniků právě do oblasti tvorby komplexních integrovaných in-formačních systémů budovaných a provozovaných pomocí outsourcingové společnostiv podobě systémového integrátora.

Outsourcing

Outsourcing je jedna z metod pořízení informačního systému, kdy příslušný doda-vatel zajišťuje komplexní dodávku a provoz celého informačního systému. Obvykletak dodavatel zajišťuje vrstvu technologickou, metodickou, aplikační, datovou i uži-vatelskou včetně zaškolení uživatelů, tvorby dokumentace, iniciálního uvedení doprovozu a řešení provozních problémů. Slouží současně jako technický helpdesk provšechny uživatele a zastřešuje provoz konkrétního informačního systému. Jedná sede facto o komplexní pronájem informačního systému.

Databázový systém

Databázový systém představuje úzké propojení databáze (vytvořené datové struk-tury – metadata a vlastní data) a systému řízení báze dat (Data Base ManagementSystem) bez příslušných prezentačních aplikací. Uvedený databázový systém tedyumožňuje definici, údržbu, manipulaci, zobrazování a zajišťování integrity (fyzickéa logické správnosti) dat. Takovéto databázové systémy musí být schopny efektivněspravovat rozsáhlé objemy dat. V současné době jsou nejrozšířenějším typem data-báze relační, vniklé na základě modelu E. F. Codda z konce 60. let. Experimentálnějsou užívány databáze objetově orientované, chytré databáze (schopné provádět řadu


transformací a prezentací dat jako vlastností metadat) a datové sklady (dataware-house, způsob ukládání, třídění a vyhledávání v rozsáhlých datových celcích).

Datový model

Představuje abstraktní návrh databáze, jedná se o myšlenkový popis daného pro-blému. Skládá se z entit (cokoliv, o čem je třeba uchovávat informace), atributů (in-formace týkající se konkrétní entity), domén (obory hodnot atributů, nikoliv pouzedatové typy, o kterých se hovoří až na fyzické úrovni, ale také logické podmínkya vazby) a vztahů (asociace mezi entitami). Obvykle je datový model představovánstrukturou (metadaty) konkrétní databáze informačního systému. Dnešní datovémodely dokáží být časově proměnlivé a současně chytré (smart – aplikační logika ječástečně přesunuta do datového modelu).

Structured Query Language

Jazyk SQL je strukturovaný, datově orientovaný dotazovací jazyk určený pro ko-munikaci se systémy řízení báze dat založenými na relačním modelu. První verze seobjevila již v 70. letech ve firmě IBM (nazývala se Sequel). Jedná se o jazyk stan-dardizovaný, tudíž nezávislý na programovacím prostředku, v rámci něhož je použit,či databázovém stroji (současným nejběžnějším standardem je SQL92, připravuje seSQLv3). Nad jazykem SQL je často vytvářena procedurální nadstavba řešící rozsáhléproblémy v oblasti chytrých databází (Oracle PL/SQL apod.). Řada variant SQLjazyka obsahuje vlastní prvky pro přístup např. do hiearchických datových modelů,vytváření stromových dotazů, optimalizace apod.

Internet

Jedná se o celosvětový systém propojených počítačových sítí (tzv. síť sítí), které jsouschopny si navzájem vyměňovat informace pomocí protokolu TCP/IP a přenášettak data mezi prakticky libovolnými místy na Zemi. Propojuje instituce nejrůznějšípovahy i soukromé osoby. Umožňuje komunikaci mezi lidmi a přístup k širokémuspektru služeb a informací. Neomezené možnosti také skýtá v oblasti využití proreklamní a propagační účely. Jde o zcela převratný prostředek komunikace na celémsvětě, proto bývá označován za nejnovější komunikační médium. Sítě založené nastejném principu jako Internet označujeme jako internety (s malým písmenem i)a dělíme na extranety (sítě mimo firmy) a intranety (sítě uvnitř firem). Nejvýznam-nější službou internetových sítí je World wide web.

World wide web

World wide web (alias www nebo pouze web) představuje nejrozšířenější službu nainternetu. Jde o graficky orientované prostředí hypertextových dokumentů zvanýchwww stránky, využívá moderní multimediální techniky (obrázky, zvuky, animace),


čímž je uživatelsky i komerčně přitažlivé. Hypertextový dokument umožňuje pomocíodkazů propojit jednotlivé významově blízké dokumenty. Stránky na www jsou zapi-sovány značkovacím jazykem HTML odvozeným od obecného značkovacího SGMLjazyku. Tyto stránky mohou být statické (předem připravené) nebo dynamicky ge-nerované (např. pomocí webového informačního systému). Pro zobrazení informacína www stránkách se používá internetový prohlížeč.

Webový informační systém

Každý informační systém je provozován v konkrétním uživatelském prostředí a másvá specifika. V poslední době většina významných výrobců přesunuje své aktivitydo tvorby informačních systému v prostředí World wide web, které se souhrně ozna-čují jako webové informační systémy. Kolem webových informačních systémů po-stupem času vyrostla teorie webových informačních systémů, která definuje přesnětyto systémy a umožnuje stanovit analytické postupy, metodiku a nástroje realizacetakovýchto systémů.Významně je tato teorie vytvářena především na Ústavu informatiky v rámci

vývoje Univerzitního informačního systému. Základy této teorie byly položeny na Fa-kultě informatiky Masarykovy univerzity při vývoji tamního Informačního systémuMasarykovy univerzity. Na rozvoji teorie pracují vývojoví pracovníci UIS s dalšímiodborníky z celého světa.

3 SOUČASNÝ STAV IS/ICT 15

3 Současný stav IS/ICT

Informační systémy a informační a komunikační technologie prošly za šest deseti-letí existence výpočetní techniky rozsáhlou cestou vývoje. První větší systémy prozpracování dat a poskytování informací z 60. let minulého století neobsahovaly anizlomek funkcí dnešních systémů a předčí je dokonce i systémy automaticky genero-vané (např. webové portály pro elektronický obchod).Současné informační systémy nemohou existovat bez dobré informační techno-

logie, která přímo podmiňuje jejich možnosti. Pokud tvůrce informačních systémůpodcení osvojování a prohlubování znalostí v nejmodernější informační technologii,jeho informační systém nebude konkurenceschopný. Podobně podnik, který budepoužívat informační systém vybudovaný pomocí zastaralé a neaktuální informačnítechnologie, nebude dosahovat prosperity a tedy ani konkurenceschopnosti na trhu.Pro dobrý rozvoj podniku je tedy nutný dobrý informační systém, který nelze vy-tvořit bez moderní, kvalitní a efektivní informační technologie.Informační technologie se dnes mění každé dva nebo tři roky, a to, co je dnes

na vrcholu, bude za několik málo let zaostalou technologií. Je proto třeba sledovataktuální vývoj a trendy informačních technologií. Tyto trendy sledují nejen doda-vatelé a tvůrci informačních systémů, ale i podniky a ostatní uživatelé systémůa vlády, které vytvářejí dobré podmínky pro rozvoj těchto technologií financovánímvýzkumu a vývoje, a podporují nadějné a slibné myšlenky ve veřejném i soukromémsektoru. Jednotlivé trendy IS/ICT současné doby zpracovává výborně učebnice [31],s přihlédnutím k efektivitě moderních informačních systémů pak [16].

3.1 Trendy mající globální ekonomicko–společenský význam

Nejvýznamnější technologií současné doby, která má dopad na mnoho odvětví lid-ské činnosti i na podobu informačních systémů, jsou komunikace. Komunikace serozvíjejí nejrychlejším tempem ze všech informačních technologií a v současné doběmůžeme pozorovat významný pokrok především v oblasti globálního propojovánívšech sítí dohromady – budování internetových sítí. Nejvýznamnější sítí tohoto typuje právě síť Internet.Rozvoj Internetu byl umožněn především technologickým pokrokem v oblasti

budování optických kabelů pro dálková propojení, rozvojem bezdrátových spojení(družice, pozemní rádiové, mikrovlné a laserové stanice, WiFi prostředky pro běžnébezdrátové spojení spotřebičů), budováním místních (LAN) a rozsáhlých (WAN)počítačových sítí a prudkým rozvojem vysoce výkonného hardware a software schop-ných zajistit přenos textu, grafů, obrazů, audia a videa.Budování celosvětové počítačové sítě má významný dopad na hospodářské pro-

středí a mění také některé sociální vztahy ve společnosti. Již dnes není nutné cestovatza prací a je možné pracovat přes Internet, v celosvětové síti je možné prezentovatsvou firmu s velmi nízkými marketingovými náklady, lze přes ni nakupovat, konzul-tovat problémy a podávat informace. Síť sítí slouží také jako významný prostředek

3.1 Trendy mající globální ekonomicko–společenský význam 16

zábavy. Dnes jsou k Internetu připojeny prakticky všechny akademické, veřejné i sou-kromé organizace. Internet proniká stále více do domácností běžných uživatelů, kdejiž dnes penetrace připojení k Internetu dosahuje 80% všech počítačem vybavenýchdomácností.Významný vliv má informační superdálnice (což je další současné synonymum

pro Internet), na snižování nákladů v oblasti marketingu, managementu, trhu pra-covních sil a vydávání prostředků na dopravu. Výrazným způsobem tak ovlivňujehospodářství v národním i nadnárodním významu a stává se jedním z hlavních fak-torů světové globalizace.Mezi základní vlivy Internetu (a tedy i informační superdálnice) patří podle [31]

zejména

• zvýšení konkurenceschopnosti prostředí z důvodu pronikání progresivních firemdo vzdálených teritorií a jejich trhů bez velkých nákladů,

• splývání dosud oddělených odvětví, kde se dá předpokládat propojování např.následujících odvětví a oblastí: telekomunikace, energetika, výpočetní technika,masová média, nakladatelství, knihovny a obchod,

• prolamování ochranářských monopolistických bariér (např. volání přes Internetv zemích s monopolním telekomunikačním operátorem),

• změny forem komunikace mezi obchodními partnery (klasické papírové doku-menty budou stále více nahrazovány elektronickou výměnou dat, tzv. EDI –Electronic Data Interchange – ti partneři, kteří nebudou schopni přijímat a za-sílat obchodní dokumenty (objednávky, faktury, platební příkazy apod.) elek-tronickou cestou budou v obchodě znevýhodněni, protože komunikace s nimibude málo efektivní),

• dramatické změny ve formách prodeje výrobků a služeb (stále více se budouprosazovat nákupy z domova – home shopping, zákaznické on-line bankovníslužby – home banking a další podobné formy styku se zákazníkem),

• posílení bezhotovostních plateb a vznik elektronických peněz (při elektronickémprodeji zboží a služeb hotovostní platby nepřipadají v úvahu, proto rozšiřovánítohoto způsobu prodeje bude dále posilovat různé formy bezhotovostního pla-tebního styku) – zajímavý pohled na tento problém je popsán v [2] a [18],

• nové typy obchodních dohod mezi partnery založené na společném využívánídatových zdrojů (např. registr restaurací, který přináší zisk zprostředkovateliv podobě části platby v restauraci, zákazníkovi v podobě snazšího vyhledánírestaurace a objednání jídla a restauraci v podobě zvýšení klientely),

• změny stylu práce – virtuální týmy a virtuální podniky (dojde k dalšímu zvýšenípodílu duševní práce a práce doma bez určené pracovní doby; řada lidí budepracovat na dočasné kontrakty pro více zaměstnavatelů najednou; pro zadanýúkol budou vytvářeny z těchto pracovníků virtuální pracovní týmy – postupněbudou vznikat virtuální podniky, které budou značně flexibilní, jejich nákladyoproti klasickým podnikům budou podstatně nižší, protože se podstatně snížínáklady na podnikové budovy, energii, cestovné atd., a produktivita jejich prácebude vyšší),

3.2 Trendy mající vztah k ekonomice, řízení a organizaci podniku 17

• efektivnější spojení státních institucí s občany a podniky (např. v USA je možnépodávat daňové přiznání elektronicky, což šetří práci úředníků a zvyšuje rychlostzpracování; u nás se podobná možnost zatím ověřuje) a

• nové možnosti demokracie (informační superdálnice propojující občany státuumožní snadná a rychlá referenda, volby a přesné průzkumy veřejného mínění).

3.2 Trendy mající vztah k ekonomice, řízení a organizaci podniku

Podle [31] existují dva základní pohledy na vztah mezi řízením podniku a IS/ICT.Pokud budeme řízení podniku brát jako primární činnost bez ohledu na nasazenýIS/ICT, pravděpodobně brzy ztratíme konkurenceschopnost, i když myšlenka, žemanagement stanoví cíle, které IS/ICT pomůže dosáhnout, je správná. Bohuželsprávná metoda není ani představa IS/ICT jako rozhodujícího faktoru při stano-vení metod řízení a organizace podniku.Správná cesta je, jako ostatně vždy, někde uprostřed. Pouze kombinací vhod-

ného řízení podniku s nasazením vhodné IS/ICT je možné dosáhnout optimálníhochodu podniku a být úspěšný na současném globálním trhu. Možnosti moderníchIS/ICT totiž mohou zcela změnit organizaci a způsob řízení v podniku. Příkla-dem vhodného skloubení moderních IS/ICT a způsobu organizace a řízení podnikujsou např. rezervační systémy dnešních leteckých společností nebo bankovní platebnía kreditní karty spolu s celosvětovou sítí obchodů, ve kterých lze těmito kartami pla-tit. Zajímavé případové studie na toto téma lze nalézt např. v [1], [3], [4], [7] a obecněi v [32].V obchodní činnost lze dnes s úspěchem nasadit celou řadu moderních aplikací

IS/ICT, které podstatně usnadní práci a urychlí všechny obchodní transakce. Příkla-dem mohou být snímače čárového kódu, registrační pokladny, elektronické etikety,zákaznické karty, automatizované informační terminály a sledování toku zákazníkůpokladnou.Významnou roli hrají IS/ICT v moderním způsobu organizace společností – fle-

xibilní organizace se pružně přizpůsobuje dynamicky se měnícím podmínkám trhu.Není nutné budovat složitou hiearchickou organizační strukturu ani budovat rela-tivně nezávislé obchodní jednotky – pracovní týmy, oddělení a vedení se pružně měnípodle toho, jak to podmínky trhu a efektivního řízení organizace požadují.Velmi frekventovaný termín dneška je BPR, neboli Business process re-

engineering, což je ve své podstatě snaha o optimální reakci podniku na externíudálost, tedy zajištění co nejrychlejší odezvy na objednávku za minimálních ná-kladů pro podnik. Této optimalizace se obvykle dosahuje pomocí nových funkcípodnikových IS/ICT. Otázka o způsobu využívání IS/ICT se tak od usnadňovánípráce z doby před 30 lety mění na otázku, co se stane, pokud podnik do IS/ICTnebude dostatečně investovat (ztráta konkurenceschopnosti podniku).Informační systémy pronikají však i na ostatní úrovně podnikového řízení, tzn.

od strategické úrovně v podobě analýzy situace v pronikání na nové trhy, přes opera-

3.3 Trendy v oblasti základního software 18

tivní úroveň v podobě vytváření virtuálních pracovních týmů po běžné pracovníky,kteří mohu využívat mobilní IS/ICT při své každodenní práci.Informace dnes hrají klíčovou úlohu v majetku a postavení podniku. Podnik

bez správných informací nemůže otevřít nový trh ani úspěšně čelit silnému tlakukonkurence. Proto řada podnikových IS/ICT přechází dnes na model tzv. učící seorganizace, tzn. sbírá veškeré informace, ukládá je do rozsáhlých datových skladů(data warehousing) a pomocí expertních systémů potom informace analyzuje a pře-vádí je na smysluplná data, na základě kterých potom mění svou vnitřní strukturua přizpůsobuje se aktuálnímu trhu.

3.3 Trendy v oblasti základního software

V současné době se již na globálním světovém trhu se základním softwarem etablo-valo několik základních softwarových domů, především společnost Microsoft. Naosobních počítačích dnes převládá operační systém MS Windows v nejrůznějšíchpodobách. Také kancelářské aplikace, tj. textový procesor, textový kalkulátor, kar-totéka, prezentátor a organizér (pošta, kalendář, úkoly) jsou dnes dodávány převážněfirmou Microsoft (MS Office). Vzhledem ke standardizaci a rozsáhlé penetraci kance-lářských systémů řadíme již dnes všechny běžné kancelářské systémy mezi základnísoftware. Podrobně se touto problematikou zabývá např. [17].Pouze jako serverové operační systémy dnes soupeří systém MS Windows se

systémem Novell NetWare a různými klony operačního systému Unix (např. Linux,Solaris apod.). Existuje sice řada alterativních systémů (Mac System či Unixovépracovní prostředí na stanici jako operační systém, StarOffice jako kancelářský sys-tém), ale především nekompatibilita jejich datových formátů s formáty společnostiMicrosoft a nedostatečná publicita brání jejich rozšíření a používání.Velmi důležitou úlohu dnes hraje síťový software, umožňující připojení počítače

k místní síti, příp. síti Internet, a práci se základními komunikačními prostředky,jako je elektronická pošta, diskuzní skupiny, přenášení souborů, instant messaging(předávání zpráv) či vyhledávání informací na World wide webu. Součástí většinydnešních operačních systémů jsou i tyto programy a tak zjednodušují instalaci a po-užívání těchto nástrojů pro běžného uživatele.Samozřejmostí je dnes lokalizace produktů do národních jazyků, provázanost

všech aplikací, grafické uživatelské prostředí, současný běh více programů nebo např.podpora různých externích zařízení, jako jsou scannery, IP telefony, videokamery,reproduktory, střihací pulty či měřiče teploty vody v akváriích aj.V souvislosti s pronikáním běžných pracovních počítačů do domácností roste

také význam hardware a především základního software pro ovládání domácí au-dio a video techniky, podporu domácnosti (řízení spotřebičů, rodinný informačnísystém) a systémy SoHo (Small Office, příp. Home software – integrované systémyřízení malých kanceláří a domácností). I když řada domácích systémů patří ještěstále do kategorie aplikačního software, značná standardizace a výroba typových za-

3.4 Trendy v oblasti aplikačního software 19

řízení umožňuje některé systémy SoHo řadit již k základnímu software dostupnémukaždému uživateli s hardware.Nelze opomenout ani trendy v systémech řízení báze dat (SŘBD), kde dochází

k postupnému přechodu od jednoduchých relačních databázových systémů, jako jedBase, FoxPro, Access či Paradox k relačním příp. objektově orientovaným systé-mům v podobě MS SQL Serveru, systémů Informix, Oracle či Sybase. SoučasnéSŘBD nabízí podporu různých typů dat (strukturovaná data, obrázky, texty, grafy,video, audio, geografická data), zpracování velkých objemů dat (terabyty až pen-tabyty informací), podporu řízení velkých transakcí (jejichž délka trvání jsou dny,týdny či měsíce), vazbu na pohyblivé databáze obchodních cestujících (trend mobilecomputing a personálních databází na příručních zařízeních) či on-line propojovánírůzných SŘBD do rozsáhlých datových center. Různé SŘBD dnes nabízí i funkcetzv. smart databází, tedy databází s přidaným prvkem automatického předzpra-cování pomocí předprogramovaných mechanismů, spouští (triggerů) a pohledů nadatabázi.

3.4 Trendy v oblasti aplikačního software

Do aplikačního software řadíme veškerý software, který je natolik specifický, že ne-může být řazen k základnímu software dodávanému s vlastním hardware. Patří semjednak úzce specializované kancelářské systémy, systémy EDI pro zajištění oběhu do-kumentů v organizaci a především typově orientovaný aplikační software (TASW).Tento software byl speciálně vyvinut pro potřeby konkrétní firmy a obvykle jej nenímožné bez rozáhlejších úprav použít u jiné společnosti. Takový software pak můžepředstavovat značnou konkurenční výhody ve srovnání s jinými společnostmi (aleněkdy může být též nezáviděníhodným břemenem, pokud vychází ze zastaralé in-formační technologie).Nasazování TASW v podniku má několik kroků, které podrobně rozebírá

např. [17], citevorisek nebo ve školním prostředí konkrétně [32]. Jedná se zejménao analýzu podnikových cílů a podnikových procesů, výběr vhodného typového apli-kačního software, volba použitelných modulů, přizpůsobení těchto modulů potřebámspolečnosti, nasazování jednotlivých modulů, parametrizace, vyškolení zaměstnanců,převedení datové základny, spuštění a podpora podniku po dobu provozu tohoto sys-tému.Parametrizace TASW umožňuje do jisté míry užívat vhodný aplikační software

a pomocí nastavení různých parametrů jej přizpůsobit na specifické podmínky kon-krétního podniku. V klasickém parametrizovaném TASW je možné nastavit např.organizační strukturu podniku, hospodářská střediska, účetní osnovu, strukturu vý-stupních dat aj. Parametrizace se nevyužívá jenom při prvotním nasazování TASW,ale i v průběhu jeho života při přizpůsobování systému, zapracovávání nových poža-davků či při změně legislativy nebo vnitropodnikových předpisů, cílů, pravidel nebopostupů.

3.4 Trendy v oblasti aplikačního software 20

Rostoucí komplexnost TASW umožňuje zvyšování rozsahu funkcí i nad hra-nice současné automatizace procesů a zapojovat tak moderní IS/IT i v oblastech,které zatím byly obvykle zpracovávány jiným způsobem, např. strategické řízení,marketing, příp. umožňuje pokrýt požadavky různých typů podniků jedním para-metrizovaným TASW. Vnitřní složitost těchto systémů roste se snahou zapracovatvšechny potenciálně možné typy provozu, např. hromadnou, sériovou, kusovou nebokontinuální výrobu.Velké množství současých TASW je již nezávislé na základním software, a je tak

možné provozovat jeden informační systém na různých platformách a proti různýmsystémům řízení báze dat. Dodavatelé se tak snaží hledat nové zákazníky i tam, kdeby s původním systémem díky nekompatibilitě prostředí neuspěli. Tento trend vedek rostoucí heterogenitě sítí a systémů a umožňuje existenci dalších ASW zajišťu-jících propojení ostatní informačních systémů a vznik samostatných integrovanýchinformačních systémů.Řada kancelářských systémů je úzce integrována s ASW, protože výstupy všech

systémů je nejjednodušší směřovat do obvyklých kancelářských aplikací, na kteréjsou již uživatelé zvyklí. Taktéž práce ve známém prostředí umožňuje zvyšovat efek-tivitu uživatelů i celého systému. Propojováním jednotlivých systémů vzniká velkýintegrovaný centrální datový sklad obsahující mnoho informací, ze kterých mohoujednotlivé systémy čerpat a tak odstraňovat nutnost působení člověka jako zpro-středkovatele informací mezi různými odděleními. Zajímavým pohledem na tutoproblematiku může být např. [5].Globální trh a nadnárodní působení jednotlivých společností dnes vyžaduje

také vícejazyčné systémy, které umožní jednotlivým národním pobočkám pracovatve svých národních prostředích a nabízí zákazníkům informace v těch jazykovýchvariantách, kterým uživatelé rozumí. Pro efektivitu přípravy takových systémů se(stejně jako v mnoha jiných oblastech) využívá stavebnicového řešení systému, kdy jemožné pomocí navzájem samostatných modulů zajistit nejen různé funkce, ale takéodlišné pracovní prostředí, národní mutace nebo postihnout odlišnosti legislativyv jednotlivých zemích.Významným trendem dnešních ASW je rovněž EDI, elektronická výměna dat.

Mnoho z moderních systémů podporuje tzv. bezpapírovou kancelář, tzn. kancelář,ve které data putují pouze mezi jednotlivými prvky výpočetní techniky (uživatelé,informační systémy, dodavatelé a zákazníci, banky a úřady). Tyto systémy umožňujíautomatické konverze do vhodných formátů, na které jsou místní uživatelé zvyklí(informační systém pracuje v systému TEX, ale uživatelé jsou zvyklí na běžný kan-celářský software v podobě Microsoft Office). EDI systém zajišťuje obousměrnoukonverzi a tím zjednodušuje uživatelům práci. Navíc zajišťuje koloběh dokumentů(workflow), ověřuje přístup k dokumentům (security access) či zajišťuje distribucizpráv na různá pracoviště (diskuzní skupiny, dokumentové servery, vývěsky, elektro-nická pošta). Řada systémů EDI je standardizována pomocí standardu EDIFACT.

3.5 Trendy v oblasti informačních technologií 21

3.5 Trendy v oblasti informačních technologií

Nejvýznamnějším současným trendem v celkové informační technologii je snahao všeobecnou standardizaci na bázi mezinárodních norem a doporučení. Např. celápočítačová síť Internet pracuje na základě standardního komunikačního protokoluTCP/IP, operační systémy navzájem zajišťují svou kompatibilitu pomocí normyPOSIX, jednotlivé aplikaace používají objektově orientovanou architekturu defino-vanou pomocí standardu CORBA nebo DCOM, s databází komunikujeme pomocístandardního protokolu SQL nebo ODBC.Základní snahou je totiž možnost zvyšovat výkon software pomocí škálování

hardware (tzn. rozšiřováním, příp. výměnou hardware či základní platformy – ope-račního systému). Tvůrci software se proto dnes snaží tvořit software nezávislý nakonkrétní platformě a opírají se právě o výše zmíněné standardy a doporučení. Dalšívýznamnou snahou je oddělení uživatelského prostředí od vlastního ASW. Uživateltak má možnost personalizace vlastního systému bez ovlivnění jeho podstatnýchfunkcí. Je tak možné vytvářet aplikace přesně zapadající do vzhledu celého ZSWa jeho designu, aniž by tento design musel být autorovi software dopředu znám.Významným trendem je posun od jednovrstvé k třívrstvé architektuře ASW.

Původní monolitické systémy se nyní skládají ze tří zcela nezávislých částí, a tokonkrétně systému řízení dat aplikace, systému řízení funkcí aplikace a systémuřízení uživatelského prostředí a komunikace s uživatelem. Tyto části spolu komu-nikují podle definovaného rozhraní (API), obvykle na základě některého obecnéhostandardu (XML, CORBA, volání funkcí API). Tak je možné průběžně vyměňovata škálovat různé části systému a přizpůsobovat je konkrétním specifickým potřebámzákazníka.Dalším významným trendem je posun od monolitických aplikací s centrálním

řízením dat k distribuovaným aplikacím na bázi modelu klient/server. Serverová částobvykle zajišťuje právě výše uvedené dvě nižší vrstvy třívrstvé architektury ASW –práci s daty a funkční (aplikační) část. Třetí vrstva je svěřena klientu (prezentaceu uživatele) a je dnes často redukována do podoby jednoduchých tenkých klientů,např. v podobě webového prohlížeče (webové informační systémy). To umožňujezjednodušit zavádění u zákazníka, protože webový prohlížeč je integrální součástíZSW a každý uživatel jej umí používat. Redukují se tak významně náklady nazavádění a provoz ASW.Dříve bylo velkým trendem centralizované zpracování dat, kdy na jeden počí-

tač, který řídil veškerá data a funkce, se připojovalo velké množství klientů. Dnes jetrendem distribuované zpracování, kdy data a funkce jsou rozprostřeny v rozsáhlékomunikační síti, a není nutné dopředu znát polohu a rozmístění jednotlivých dato-vých či funkčních složek. Klientská část komunikuje s nejbližší serverovou částí a taji dle potřeby přesměrovává na další části nebo opatřuje data sama. Redukují se taknáklady na výstavbu špičkových datových center se servery o velkých výkonech, zvy-šuje se celková redundance (a tudíž stabilita systému) a systém je méně zranitelný(poškození části neovlivní fungování celku, ale pouze některých částí ASW).

3.6 Trendy v oblasti metod a nástrojů vývoje IS/ICT 22

Díky rostoucí intuitivnosti ZSW jsou dnes uživatelé zvyklí na velmi kvalitnía ergonomicky efektivní uživatelská prostředí. Vyžadují různé multimediální do-plňky počínaje tapetou na pozadí, zvukovými efekty a animacemi a konče variant-ním designy (skiny) či maximální přizpůsobitelností ASW. Na jednu stranu tentotrend prodražuje vlastní ASW, ale uživatelům umožňuje rychleji se se systémemsžít a vytvořit tak efektivní pracovní kombinaci spokojeného uživatele a kvalitníhosystému.

3.6 Trendy v oblasti metod a nástrojů vývoje IS/ICT

Významný posun zaznamenala též oblast metod a nástrojů vývoje IS/ICT. Lzevysledovat trend postupu od strukturovaných technik k technikám objektově orien-tovaným, které lépe vystihují reálný svět. Vzhledem k tomu, že tento formalismus ječasto využíván jak na datové, tak na aplikační části budovaného Univerzitního infor-mačního systému, vysvětleme si tuto techniku podrobně (principy jsou zpracoványna základě [21] a [22]).

Objektově orientovaný přístup

Objektově orientovaný přístup je velmi silný formalismus využitelný především k mo-delování reálné situace. Tento formalismus se pokouší přesně odrážet reálný stav věcíse zanedbáním všeho nepodstatného pro řešení příslušného problému.Objektem nazveme libovolnou reálnou věc, kterou chceme modelovat. Nemusí

se jednat jen o věci konkrétní (jako je např. jablko, dům, osoba, napařovací žeh-lička, . . . ), ale mohou to být i věci abstraktní (např. logické myšlení je abstraktnívěc, kterou můžeme chtít namodelovat nějakým objektem tak, aby ji jiné objektymohly využít).Každý objekt si pak lze představit jako určitou množinu vlastností spolu s de-

finovanou určitou množinou činností, které lze s tímto objektem provádět. Obvykleo těchto činnostech hovoříme ve smyslu „objekt provádí činnostÿ nebo ve smysluantropomorfizace objektu1. Souhrn všech činností jednoho objektu nazýváme cho-váním objektu2.Chování (jednotlivé činnosti) obvykle provádí změnu stavu objektu (modifikaci

jeho vlastností). Komunikace mezi objekty je pak sled činností, které mají za násle-dek změnu stavu jednotlivých objektů. Veškerá komunikace je potom prováděna zaúčelem změny vlastností, což přesně odpovídá reálnému světu (provádíme činnostipro změnu našeho stavu – nasycení, zahřátí se, uspokojení vlastních potřeb, . . . ).Objekty získávají své vlastnosti a chování díky tomu, že jsou instancí nějaké

třídy objektů. Třída objektů tak definuje chování a strukturu vlastností pro všechny

1Říkáme, že např. objekt obdélník „víÿ, jak má spočítat svou plochu apod.2Celý tento formalismus lze samozřejmě zapsat formálně např. jako O = (P,B), kde P je

množina vlastností (z angl. properties) a B množina relací představujících chování objektu (z angl.behaviour). Vzhledem k tomu, že smyslem této práce není provádět precizní důkazy nad přesnouformální specifikací, omezíme se na slovní popis formalismu.


objekty, které k této třídě patří. V objektové terminologii se jednotlivým činnostemříká metody a toto chování odrážejí tzv. metody instancí.Uvedený formalismus přesně odráží reálnou situaci – třída objektů s názvem

jablko má konkrétní instance – mé jablko, sousedovo jablko, třetí jablko na stolezleva apod. Tyto instance jsou konkrétní fyzické objekty – jablka. Mají své vlastnosti– barvu, vzhled, vůni, chuť aj. Každé má specifické hodnoty vlastností, ale strukturuvlastností mají všechna jablka stejnou. Všechna jablka mají také stejné chování –mezi jejich základní činnost patří růst, roztrušování semen, produkce vůně, výrobacukru apod. Tyto metody jsou prováděny nad konkrétní instancí (roste konkrétníjablko), ale jsou všechny stejné pro celou třídu objektů (všechna jablka mají totochování).V obecném formalismu objektového přístupu jsou definovány i další druhy me-

tod (a tedy chování) – jedná se o metody třídy (pracují nad všemi instancemi pří-slušné třídy – např. vyhledání objektu), přičemž některé metody tříd jsou specifické– metody konstruktorů (vytvářejí nové instance – např. metoda početí dítěte apod.).Tento formalismus je velmi užitečný v teorii objektově orientovaného programování,ovšem nemá přesný odraz v reálném světě (snad s výjimkou metod konstruktorů).Nad objekty jsou dále definovány tři základní vlastnosti objektově orientova-

ného přístupu:• dědičnost• zapouzdření• polymorfismusVlastnost dědičnosti představuje přesně to, co její název napovídá. Pokud ně-

která třída dědí z jiné třídy, znamená to, že přejímá všechny vlastnosti a chovánírodičovské třídy. Pojem dědičnosti lze rozšířit na více předků – vícenásobná dě-dičnost – pak ovšem dědí třída vlastnosti a chování od všech rodičovských tříd.Používáme zde pojmů nadtřída a podtřída. Opět tato vlastnost odráží reálný svět(syn dědí vlastnosti a chování od matky i otce, jde tedy o vícenásobnou dědičnostmezi nadtřídami otec a matka a podtřídou syn)3.Zapouzdření umožňuje skrýt vnitřní vlastnosti objektu a vnitřní chování před

vnějším světem. Představme si objekt podle obrázku 1 na následující straně.Je vidět, že vlastnosti objektu jsou vnějšímu světu skryty a jediná možnost

komunikace zůstává prostřednictvím definovaného rozhraní pomocí vybraných me-tod instance. Na obrázku je tato komunikace znázorněna šipkami. Navenek se tedykaždý objekt chová jako černá skříňka. Manipulovat s vlastnostmi smíme jen pomocívolání metod (provádění činností objektu).Vlastnost zapouzdření tak umožňuje jednoduše zachovávat stav konzistence

všech vlastností objektu. To ovšem přesně odpovídá reálnému světu – aby mohlodojít ke změně vlastnosti (hnědnutí jablka), musí dojít k určité činnosti (např. oxi-dace povrchu jablka), tedy k vyvolání metody.

3V reálném světě ovšem není dědičnost dokonalá, řídí se zákony dědičnosti a dochází k mutacím– vlivu nežádoucích faktorů do procesu dědičnosti – tyto zvláštnosti nelze ovšem formalismemobjektově orientovaného přístupu jednoduše modelovat.


Obr. 1: Zapouzdření objektu

Vlastnost polymorfismu si nejlépe představíme na příkladu. Představme siošatku, do které lze vkládat ovoce. Pak nezáleží příliš na tom, zda se jedná o ja-blka či hrušky, můžeme vždy provést činnosti jako snězení ovoce, cítíme vůni ovoceči můžeme ovoce použít jako surovinu pro výrobu šťávy pomocí činnosti lisováníovoce. Polymorfismus tedy znamená využitelnost různých objektů stejným způso-bem, pokud mají tyto objekty společného předka (viz dědičnost objektů), který mádefinovánu příslušnou činnost.Přitom tento předek má příslušnou činnost definovánu často velmi abstraktně

– ostatně jakou vůni má ovoce? Konkrétní instance ovoce – např. jablko – má pakjiž vůni velmi reálnou. Výhoda polymorfismu je především v mechanismu, kterémuse říká pozdní vazba. Představme si model světa, ve kterém modelujeme procesčlověka, jehož úkolem je sníst ovoce, pokud mu toto ovoce voní. Bez polymorfismuby bylo nutné definovat, že člověk má sníst jablko, pokud mu jablko voní (protoževíme, jak voní jablko). Podobně musíme totéž definovat pro hrušky, třešně, švestky,meruňky a mnoho dalšího přípustného ovoce. Přidáním dalšího druhu ovoce pakmusíme proces člověk doplnit o reakci na novou vůni4.S využitím polymorfismu naučíme člověka reagovat na vůni ovoce vykonáním

činnosti snězení ovoce – bez ohledu na to, zda se jedná o granátová jablka nebokubánské pomeranče. Vzhledem k tomu, že každé ovoce má definovánu vůni a činnostsnězení ovoce (byť abstraktně), je možnost tohoto stylu výuky člověka reálná. Člověkmá vůči ovoci tzv. pozdní vazbu, protože do posledního okamžiku (před testem navůni) není známo, o jaké ovoce půjde.Máme tedy definovány objekty jako instance tříd objektů, tyto objekty mají

své vlastnosti a chování a splňují vlastnosti dědičnosti, zapouzdření a polymorfismu.Pro úplnost našeho objektového popisu přidáme ještě dvě nové definice.Konstruktorem objektu nazveme tu činnost, která způsobuje vznik objektu

(jedná se o metodu třídy objektu tak, jak již byla popsána výše). Naopak destruk-torem objektu nazveme tu činnost, která způsobuje zánik objektu (to je naopakmetoda instance, protože pracuje nad konkrétním objektem).

4Uvedená metoda se nazývá brzká vazba a nevyužívá polymorfismu.


Více o objektech a formalismu objektově orientovaného přístupu lze nalézt např.v knihách [21] a [22] a v dalších učebnicích programovacích jazyků.

Další současné metody a nástroje vývoje

Můžeme pozorovat odklon od klasického sekvenčního vývoje IS/ICT, ve kterém po-stupně za sebou následovaly fáze specifikace požadavků, analýzy a návrhu systému,implementace systému a zavedení systému. Nové metodiky vývoje a implementaceIS/ICT čím dál více podporují inkrementální vývoj IS/ICT a rychlý vývoj jednot-livých aplikací s použitím prototypů (RAD – Rapid Application Development). Jeto reakce metodik na snahu o rychlý vývoj IS/ICT při současné ochraně investica zajišťování maximální spolehlivosti IS/ICT (podrobně viz [16] a [17]).Za velmi pozitivní lze označit současný odklon od tzv. hard metodik vývoje,

kdy již vývoj není podřízen současné hardwarové a softwarové technologii, ale na-opak se vývoj řídí potřebami konkrétních uživatelů právě vyvíjeného systému (softmetodiky). Je tedy kladen důraz především na uživatele a cílem není vlastní systém,ale spokojený uživatel vytvářeného systému.Moderní metodiky pro vývoj IS/ICT jsou v poslední dobe již standardně spo-

jeny s automatizovanými nástroji, které zefektivňují použití metod a technik v me-todice obsažených. Pro tyto nástroje se vžil název CASE (Computer Aided SoftwareEngineering, resp. Computer Aided System Engineering). V současné době využí-vají CASE všechny významné softwarové domy a většina větších týmů zaměřenýchna vývoj IS/ICT.Pro rozvoj CASE a pro snahy tvůrců CASE jsou typické tyto trendy:

• usilují o to, aby automatizovanými nástroji pokryly celý životní cyklus IS odstrategického plánování (od informační strategie) až po zavedení informatickéhoprojektu do provozu – jednotlivé fáze projektu jsou přitom propojeny řadoukontrol na konzistenci projektu,

• snaží se propojit jednotnými nástroji návrh a implementaci IS/ICT s provozemIS/ICT (CASE zachycující stávající stav i plánované stavy celého IS/ICT seobvykle nazývá metasystém),

• CASE jsou navrhovány tak, aby byly využitelné pro projekty realizované zapodpory různých metodik (tento směr vývoje CASE je významný pro ty pod-niky, které realizují svůj IS/ICT integrací různých produktů od různých vý-robců, protože tyto produkty jsou obvykle vyvinuty a zdokumentovány s pou-žitím různých metodik – vytvoření integrovaného IS/ICT podniku však vyža-duje, aby různé produkty byly v podniku zdokumentovány a v provozu řízenyjedním nástrojem).

3.7 Trendy v organizaci a řízení IS/ICT 26

3.7 Trendy v organizaci a řízení IS/ICT

Základem moderní organizace a řízení vývoje, zavádění a provozu IS/ICT je dnespředevším outsourcing a systémová integrace. Outsourcing představuje metodu mi-nimalizace vlastního vývoje. Outsourcing znamená (dle [31]) úplný nebo částečnýpřechod k převažujícímu zajištění vývoje IS/ICT dodavatelským způsobem včetnědoplňujících služeb (instalačních, konzultačních, školících).Jde tak o vytěsňování všech informatických aktivit, které je efektivnější řešit

dodavatelsky, mimo podnik. Outsourcing vývoje IS/ICT je v praxi již běžnou zále-žitostí – většina podniků nakupuje typové aplikační programové vybavení (TASW),resp. zadávají tvorbu „na míru šitéhoÿ ASW externí firmě. Podobně je tomu se za-jišťováním servisu, resp. údržby hardwarových komponent. Relativně řídkým jevemje zatím outsourcing provozu IS/ICT. Je tomu tak zejména z důvodů problematic-kého zajištění ochrany dat podniku před zneužitím jinými subjekty a z důvodů přílišvysoké závislosti podniku na poskytovateli služby.Přes uvedené nevýhody se však jedná o jeden z nejvýhodnějších způsobů za-

vádění a provozu IS/ICT v podniku. Pro vysokou školu takto zajištěný informačnísystém doporučuje i prof. Vrana v metodické příručce [32] pro systémové integrá-tory univerzitních informačních systémů. Tento ve světě již běžný způsob provozuIS/ICT začíná nacházet uplatnění i v našich podmínkách. Velmi příznivě se k použitíoutsourcingu jako efektivní metodě implementace informačního systému staví taképrof. Molnár ve své knize [16].Trendem, který propojuje řadu předchozích, je tzv. systémová integrace, která

je chápána jako komplex činností směřujících k integraci jednotlivých komponentIS/ICT a služeb externích dodavatelů do výsledného produktu – integrovaného in-formačního systému podniku.Častým případem je, že outsourcing se praktikuje i na systémovou integraci,

tzn. vytvořením a rozvojem integrovaného IS podniku je poveřena externí firma– systémový integrátor, která přebírá zodpovědnost za funkčnost a kvalitu celéhoIS/ICT podniku.Při provozu IS/ICT se i v souvislosti s předchozími metodami stále častěji

uplatňují specializované funkce, zejména informační manažeři, správci databází (da-tamanažeři), správci počítačových sítí, specialisté na on-line konzultační služby, „za-jištovačiÿ externích dat (information providers) pověření hodnocením, výběrem a ná-kupem externích datových zdrojů, auditoři informačních systému a mnozí další.Růst významu IS/ICT pro podnik a vznik nových informatických profesí má

u většiny podniku vliv i na organizační strukturu podniku. V 70. a začátkem 80. letbyly z informaticky zaměřených funkčních míst na nejvyšších pozicích v podnikovéhierarchii vedoucí výpočetních středisek, kteří byli obvykle zařazeni do útvaru or-ganizace a techniky řízení. Koncem 80. let bylo v českých podnicích typické, ževýpočetní středisko (útvar informatiky) bylo odděleno od útvaru organizace a bylopřímo podřízeno ekonomickému řediteli podniku.

3.7 Trendy v organizaci a řízení IS/ICT 27

Současným trendem v zahraničních i tuzemských podnicích je další posun řízeníinformatiky směrem k vrcholovému vedení podniku. V podnicích je zřizována funkceředitele informatiky (CIO – chief information officer), který je přímo podřízen gene-rálnímu řediteli podniku. S ohledem na úzké vazby informatiky a organizace bývádo útvaru informatiky začleněn i útvar organizace.Vzhledem k vysoké závislosti podniků na informačních systémech vzniká po-

třeba zajištění vysoké spolehlivosti a dostupnosti prostředků IS/ICT. Jsou defino-vány základní stupně spolehlivosti systému a snaha všech velkých dodavatelů IS/ICTvede k zajištění plného 24×7 provozu se spolehlivostí stupně 5 (tj. 0,999 99% do-stupnost systému – asi 5 minut ročně je systém mimo provoz). Do zajištění spo-lehlivosti nespadá jen funkceschopnost hardware a bezchybnost software, ale takéon-line podpora uživatelům, adekvátní bezpečnost systému před vnějším i vnitřnímútokem, zálohování, redundance a kontrola na všech úrovních.

4 ARCHITEKTURA MODERNÍCH INFORMAČNÍCH SYSTÉMŮ 28

4 Architektura moderních informačních systémů

Každý informační systém je rozsáhlý systém s vnitřní strukturou, která umožňujetomuto systému efektivně realizovat jeho funkce a plnit cíle, pro které byl navržen.Pro zobrazení vnitřní struktury informačního systému se používají dva základnípohledy – horizontální a vertikální. Vhodným kompaktním výchozím materiálempro popis architektury IS je [17], s přihlédnutím k efektivitě pak [16], příp. [31].Návaznosti na podněty v průmyslu či obchodu shrnuje [12].

4.1 Vertikální struktura IS

Vertikální dimenze informačního systému představuje jeho hiearchickou strukturuz hlediska poskytovaných služeb různým úrovním managementu podniku, příp. běž-ným uživatelům. Základní členění představují tři klasické vrstvy členění podle roz-dělení činnosti managementu:

• úroveň strategického plánování (vrcholové řízení),• úroveň taktického řízení (střední úroveň řízení),• úroveň operativního řízení (řízení transakcí a technologických procesů).Vzhledem k faktu, že informační systém poskytuje služby všem řídícím slož-

kám podniku, bývá tato základní struktura rozšiřována na pěti- a vícestupňovoupyramidu, která je znázorněna na obrázku 2.

Obr. 2: Znázornění vertikální struktury IS pětistupňovou pyramidou

Systém transakčního zpracování (TPS) spolu se systémy řízení uplatňujícími sena základní (OIS), resp. střední (MIS) úrovni řízení podniku tvoří jádro každéhoinformačního systému. Jejich základním úkolem je připravit a aktualizovat data prořídící aktivity na nejnižší a střední úrovni řízení, udržovat základní evidenci a posky-tovat základní přehledy ze všech oblastí činnosti podniku. K tvorbě a projektováníTPS/OIS a MIS existuje řada více či méně dokonalých metod a nástrojů, které sesoustředí do aplikačních programových balíků pro podporu životního cyklu infor-mačního systému či alespoň jeho podstatných částí.Operativní informační systém (což je jiný název pro TPS) podporuje kaž-

dodenní aktivity operativního managementu společnosti. Jeho chování je vysoce

4.1 Vertikální struktura IS 29

standardizováno, jeho funkce jsou prováděny rutinně a je požadována velmi rychláodezva, spolehlivost a eliminace případných chyb. Událost vnějšího světa (příchodzákazníka) aktivuje tento systém a on zajistí sesbírání podstatných dat a on-linevyhotovení příslušných dokumentů. Současně mohou být uložena data pro pozdějšídávkové zpracování v tomto či jiných systémech.Manažerský informační systém stojí nad úrovní TPS a nezabývá se každoden-

ními činnostmi. Jeho úkolem je řízení aktivit, které tuto každodenní činnost podpo-rují (tedy systém řízení operativy, aktivity) umožňuje na základě předzpracovaných(strukturovaných, ucelených a částečně sumarizovaných vstupních dat z TPS) datřídit a kontrolovat činnost základních podnikových aktivit. Úkolem MIS je tedyposkytnout přehled o kontaktu jednotlivých zaměstnanců se zákazníky.Systémy pro podporu rozhodování (DSS) a systémy pro podporu vrcholového

managementu (EIS) představují oproti TPS a MIS podstatně výraznější orientacina analytické a rozhodovací algoritmy. Pro svoji menší strukturovatelnost bývajízpravidla řešeny nestandardizovanými postupy. Jsou orientovány na specifickou tříduuživatelů se specifickými informatickými potřebami a to v sobě odráží i potřebupoužití specifických metod zpracování informací v těchto systémech.Decision Support Systems (DSS) primárně podporují střední úroveň řízení. Mají

převážně izolovaný charakter – optimalizační úlohy, příp. úlohy vícekriteriálního roz-hodování, úkoly hromadné obsluhy, dopravní úlohy (logistika) a další úlohy operač-ního výzkumu, statistiky, teorie her. Umožňují algoritmizovat postupy v rozhodova-cích procesech.Systémy podpory vrcholového managementu (EIS) jsou účelově orientované sys-

témy. Řeší problémy top managementu a tvoří špičku pomyslné pyramidy. Integrujív sobě všechny důležité datové a technologické zdroje z celého informačního sys-tému. Proti DSS jsou na ně kladeny specifické nároky na prezentaci dat ve stručné,jasné a správné podobě. Jsou pomocníkem vrcholového managementu v celé šíři je-jich rozhodovacího procesu. Nejdůležitější činností EIS je integrace mnoha datovýchzdrojů do jednoduchých a přehledných výstupů.Střední část pyramidy potom představují systémy na podporu administrativy

(OAS), které zajišťují zvýšení výkonosti a produktivitu administrativních (kancelář-ských pracovníků). Hlavním posláním OAS je vytvářet, modifikovat a přenášet dataadministrativního charakteru v převážně písemné popř. grafické podobě. Systém propodporu administrativy se postupně strukturuje a přizpůsobuje organizační struk-tuře podniku. Ve vzájemných interakcích s uživateli se postupně stabilizuje a plynulea většinou v předstihu oproti ostatním částem informačního systému absorbuje vevětší či menší míře nové produkty informačních technologií – multimediální techno-logie, komunikační protokoly, datové nosiče, prohlížeče v rozsáhlých počítačovýchsítích apod.Pozice OAS není v pyramidě stabilizovaná a tyto systémy se mohou prolínat

do ostatních složek informačního systému. Někteří autoři uvádějí rovněž prohozenépořadí MIS a OAS v pětivrstevném pyramidovém uspořádání. Systémy OAS jsouhlavně u velkých systémů značně různorodé a lze do nich zařadit kancelářské sys-

4.2 Horizontální struktura IS 30

témy, systémy řízení bází dat, prezentační programy, prostředky pro přenos data napojení na externí zdroje dat.

4.2 Horizontální struktura IS

Druhým základním pohledem na strukturu informačního systému je pohled jed-notlivých složek organizace, která tento systém využívá (obvykle jednotlivá oddě-lení a útvary podniku). Pokud je například organizace členěna do čtyř základníchútvarů (divizí), hovoříme o čtyřech základních subsystémech. Další vnitřní členěnídivizí vytváří další subsystémy jednotlivých subsystémů (stromová struktura).Obvykle tak vzniká několik základní subsystémů, jako je Výroba, Věda a vý-

zkum, Marketing, Finance a účetnictví, Management, Obchod apod. Tyto systémyse pak dále dělí, např. u Výroby na Nákup surovin, Kontolu zásob, Plánování pro-dukce apod. Příklad této struktury v podnikovém informačním systému je uvedenna obrázku 3.Podobné horizontální členění lze nalézt také ve specifickém prostředí vysokého

školství – např. základní dělení na Výuku, Výzkum, Ekonomickou agendu, Iden-tifikační systém, Stravování, Správu počítačů apod. A jednotlivé systémy (např.Výuku) můžeme dále rozdělit do specifických subsystémů (Studijní oddělení, Zá-znamník učitele, Průchod studiem, Rozvrhy apod.).

4.3 Horizontálně–vertikální struktura IS

Kombinací obou výše zmíněných pohledů na strukturu informačního systému zís-káme komplexní pohled na modulární informační systém, jehož jednotlivé subsys-témy jsou specifické jak z pohledu úrovně řízení, tak z pohledu organizační strukturypodniku. Vhodným příkladem dělení pak může být příklad Ekonomicko-výrobníhosystému uvedený v [17], jehož struktura je znázorněna na obrázku 4.Takto rozčleněný informační systém lze potom jednoduše modulárně vyvíjet

a integrovat do celopodnikových potřeb. Vertikální dimenze umožňuje rozdělit sys-tém podle specifičnosti úrovně řízení (ve vztahu obecná a široká datová základna kespecifickému a úzkému vrcholovému řízení), horizontální dimenze naopak podporujerozklasifikování systému podle činnosti organizace a vyčlenit jednotlivé vedoucí nadílčích úsecích (v kombinaci pak vzniká vedoucí na základní úrovni, např. vedoucískladu; dále vedoucí na střední úrovni – vedoucí marketingových analýz a vedoucívrcholové úrovně – výrobní náměstek apod.).Na všech úrovních potom do základního modelu architektury informačních sys-

témů zasahují dva další subsystémy – kancelářský informační systém (OIS) posky-tující uživatelům běžné služby jako textový procesor, tabulkový kalkulátor, prezen-tátor, kreslicí program, kartotéka či plánovací kalendář a systém EDI (ElectronicData Interchange), který zajišťuje koloběh dat mezi uživateli (bezpapírová kancelář– pošta, vývěska, dokumentový server, diskuzní skupiny, instant messaging a další).

4.4 Třívrstvá architektura informačních systémů 31

Obr. 3: Horizontální struktura IS – podle organizační struktury podniku

4.4 Třívrstvá architektura informačních systémů

Architekturu obecně chápeme (na základě [12]) jako dílo navrhovatele vytvářejícífunkční prostor pro další realizaci podle základních ideových představ a technickýchmožností daných dobou. Jedná se o ideovou jednotu použitých prvků, má defino-vaný styl, smysl i poslání. Architektura může být otevřená změnám a přestavbám,ovšem pouze při zachování stanoveného stylu5. Architektura informačních systémůje obecná definice platná v informatice a používá se již půl století.V současné době do pojmu architektura v oblasti informačních systémů

patří jednak vnitřní systémová struktura (horizontální, vertikální i horizontálně--vertikální), tak struktura jednotlivých implementačních vrstev, které umožňují pře-

5Na gotický chrám nelze přimontovat barokní věž.


Obr. 4: Horizontální a vertikální struktura podnikového informačního systému

nášet systém mezi různými prostředími (portování informačního systému na jinouplatformu). Toto pojetí se nazývá vrstvená architektura.Nejstarší vrstvenou architekturou byla jednovstevná architektura systému, kdy

příslušný systém řešil všechny operace na úrovni jediného subsystému. Pozdějí(v 80. letech) vznikají první dvouvrstvé systémy klient/server, které odlišují da-tabázové operace (databázová vrstva) na straně serveru a klientské aplikační a pre-zentační operace (na aplikační vrstvě). Tato architektura byla dána poměrně stan-dardizovaným prostředím klientů (řádkové prostředí, jednoduchá grafická prostředí,standardizovaná grafická API).S postupem času vznikala stále složitější grafická prostředí, vzrůstal počet ope-

račních systémů, ze kterých bylo možné k informačnímu systému přistupovat a řadainformačních systémů začala zpřístupňovat svá data i prostřednictvím jiných zaří-zení, než jsou klasické síťové terminály (kiosek, mobilní telefon, PDA, hlasové službyaj.). Tento posun si vyžádal vznik nového pojetí – třívrstvé architektury. Schéma-tické znázornění této architektury je na obrázku 5.

Obr. 5: Třívrstvá architektura

Nejnižší vrstvu zde tvoří vrstva datová, která zajišťuje nejen napojení na systémřízení báze dat, ale i základní datově–funkční operace zajišťující ukládání, výběr,agregace, předzpracování, integritu a audit dat. Tím je možné využívat společnoudatovou vrstvu několika různým systémům v integrovaném informačním systému.Prostřední vrstvou je vrstva aplikační (někdy též funkční), která zajišťuje veš-

keré výpočty a operace prováděné mezi vstupněvýstupními požadavky a daty. Jeprostředníkem mezi obecnou prezentační vrstvou (tj. vstupy a výstupy uživatelů)


a datovou vrstvou, která zajišťuje centrální správu dat. Tato vrstva je někdy ozna-čována za middleware, protože zajišťuje transformace dat. V komerční sféře jsouinformační subsystémy této vrstvy označovány jako aplikační servery.Nejvyšší vrstvu představuje vrstva prezentační, která zajišťuje vstup požadavků

uživatele a prezentaci výsledků (zobrazení, jednoduché datové transformace, filtry,výběry, třídění, agregace). Obvykle existuje několik prezentačních vrstev pro různédruhy zařízení, platformy a prostředí. U webových IS tato vrstva degraduje na formá-tování výstupu (aplikaci designu) a tenký klient (prohlížeč internetových stránek).V rámci třívrstvé architektury dochází k dalšímu podrobnému členění, které

např. striktně odděluje základní datovou vrstvu od metadatové vrstvy (určené právěk předzpracování dat) nebo naopak vytváří dvě úrovně prezentační vrstvy (prezen-tační a zobrazovací vrstvu, kde prezentací je myšlena příprava výsledných údajůa zobrazením vlastní aplikace pro zobrazení údajů). Základní smysl třívrstvé archi-tektury však zůstává.

5 METODY ŘÍZENÍ VÝVOJE A PROVOZU IS 34

5 Metody řízení vývoje a provozu IS

Vývoj a provoz informačního systému je náročná a nákladná věc. Vyžaduje značnézdroje personální, technologické, informační i finanční. Je zapotřebí vytvořit roz-sáhlou personální strukturu, vybavit tyto osoby vhodnou technologií, zajistit jimpřístup k informacím (a získávat od nich informace zpětnou vazbou) a celou záleži-tost řádně profinancovat. Celá práce s vývojem a následným provozem informačníhosystému však musí být určitým způsobem organizována a řízena, aby nedocházelok neefektivním prostojům a zbytečným debatám nad neužitečnými problémy.Existuje řada doporučených postupů, které umožňují navrhnout, vytvořit, otes-

tovat, zdokumentovat a následně provozovat informační systém. Některé metodikyvolí cestu vlastního vývoje, jiné postupují naopak zcela dodavatelskou cestou (např.outsourcing). Tato kapitola rozebírá základní metody přístupu k řízení vývoje a pro-vozu informačního systému, posuzuje vhodnost těchto metod ve specifickém pro-středí vysokého školství a rozebírá metodu vývoje, kterou využívá náš vývojovýtým (včetně uvedení výhod a nevýhod zvolené metodiky). V závěru kapitoly jepředstaven způsob řízení lidských zdrojů při vývoji systémů ve školství a problémy,se kterými se vedoucí vývoje potýká.

5.1 Životní cyklus projektu

Pro pochopení metod řízení vývoje a provozu informačního systému je nejprve dů-ležité poznat životní cyklus projektu, tedy jednotlivé etapy, kterými vývoj a provozprochází. Každý projekt začíná rozhodnutím podniku o vývoji a nasazení novéhoinformačního systému nebo o modernizaci či rozšíření stávajícího informačního sys-tému.Po přijetí tohoto rozhodnutí je nutné vytvořit projekční tým, který zodpovídá za

výsledek projektování a vývoje vlastního řešení – provoz je potom rutinní záležitostíprovozních operátorů, kteří ale již v době zavádění systému úzce spolupracují s pro-jekčním týmem. Projekční tým je řízen vedoucím projektu a je složen minimálněze dvou základních složek – základní tým složený z vlastních pracovníků organi-zace a provádějící zavádění, příp. celý vývoj, přímo v podniku a externí část týmusložená z poradců, konzultantů a externích systémových integrátorů, kteří zajišťujítechnologické know–how celého projektu.Projekční tým vytváří v první fázi úvodní studii (analýzu systému), poté se-

stavuje globální návrh celého systému a zpřesňuje tento návrh do detailů (návrhsystému). Ve druhé fázi implementuje zvolené řešení a provádí testy na správnost im-plementace vůči návrhu. V poslední fázi projekční tým zavádí systém do organizace.Zde přebírá odpovědnost provozní tým, který systém provozuje, udržuje a zpětněpředává problémy k řešení projekčnímu týmu.

5.1 Životní cyklus projektu 35

Úvodní studie

Úvodní studie je základní krok při přípravě projektu. Jedná se o analýzu systémua jde o klíčovou fázi projekčního procesu. Smyslem úvodní studie je vyhodnocenístruktury a chování firmy (organizace) jako reálného systému před zrcadlem na-vržených cílů (ty předkládá zadavatel – vedení organizace). Cíle vedení mohou býtvelmi obecné, úvodní studie je potom dokumentem, který vzniká na základě stanove-ných podmínek, podnikové strategie a definuje podrobné cíle zavádění informačníhosystému. Analyzuje současný stav, zjišťuje pozitiva a nedostatky stávajícího infor-mačního systému, pakliže byl nějaký již využíván.Dokument rovněž obsahuje základní návrh řešení nového informačního systému

včetně dekompozice na jednotlivé nasazované subsystémy. Může obsahovat návrh ně-kolika variant společně s časovým odhadem a s odhadem finančních i personálníchnákladů porovnaných s celkovým přínosem systému. Na základě takto vytvořenéhoporovnání je poté navrženo vhodné řešení, které bude v podniku či organizaci nasa-zeno. Výběr variantních řešení provádí po konzultaci se systémovým integrátoremnebo s projekčním týmem přímo zadavatel, tj. vedení podniku.Na úvodní studii lze pohlížet z celé řady hledisek – hledisko informační (hrubý

datový model a způsob distribuce dat), dále hledisko procesní (kontextový diagram,hrubý funkční a procesní model chování systému), hledisko organizační a legisla-tivní (zákony a normy vztahující se k zaváděnému projektu, stanovení podnikovýchnorem, výběr vzorových pracovišť pro implementaci a stanovení garantů projektu,kteří ponesou zodpovědnost za kvalitní nasazení systému).Dalšími hledisky pak mohou být hlediska pracovní, sociální a etická (vliv no-

vého systému na podnikovou kulturu, odraz ve kvalifikaci zaměstnanců), hlediskosoftwarové (výběr vhodného software pro realizaci, možnost volby vlastní výrobyči dodání externího software), hledisko hardwarové (požadavky na hardware, výběrdodavatele na základě podmínek poskytovaných jednotlivými dodavateli, stanovenídimenze (parametrů) zvoleného hardware) a hledisko ekonomické a finanční (ná-klady na tvorbu, nákup a provoz systému, ocenění přínosů systému pro organizaci,posouzení výnosnosti a nutnosti systém zavést).

Globální návrh informačního systému

Na základě schválení úvodní studie provede projekční tým globální návrh (u menšíchprojektů pak tato fáze splývá s detailním návrhem, protože není nutné zasahovat dovelké šíře problémů). Cílem globálního návrhu je rozvedení úvodní studie do detail-nějšího návrhu, tento návrh je ale stále nazávislý na použitém hardware a software.Dochází zde k vytvoření podrobného datového modelu IS na základě analýzy infor-mací, které se v podniku vyskytují (zdroj, tok, objem, forma, obsah, přístup, dobauchování atd.).Z funkčního hlediska se provádí dekompozice systému a jeho subsystémů až

na úroveň jednotlivých transakcí. U každé transakce je dále specifikováno, jak jestartována (kterou událostí), vstupní a výstupní data a způsob jejich transformace


uvnitř transakce. Nezbytnou součástí transakce je také určení, které činnosti budoumanuální, které automatizované, které dávkové apod. Dále je třeba specifikovat, jakékategorie uživatelů budou se systémem přicházet do styku (právní systém, rozloženírolí, delegátů, superoprávnění), charakteristiky těchto uživatelů, podrobné oprávněníjednotlivých skupin či jednotlivců z celopodnikového hlediska, specifická zaměřenípráv skupin na jiné skupiny apod.Je nutné pamatovat i na požadovanou kvalifikaci uživatelů nového informačního

systému a případně plánovat postupná školení a rekvalifikace pracovníků. Z hle-diska softwaru se provádí návrh softwarové architektury (vrstvy, vývojová prostředí),standardů (pro uživatelské rozhraní, dokumentaci, způsob zápisu zdrojového kódu,evidence protokolů, . . . ), výběr typového software, určení požadavků na odezvu,rozdělení akcí podle typů (dávkové, interaktivní, časem řízené aplikace).V oblasti hardware se určí požadavky na jednotlivá zařízení, topologie vnitro-

podnikových i externích sítí, rozmístění jednotlivých komponent systému aj. Z hle-diska metod a technik se dále určí, jaké způsoby budou používáný při modelování,návrhu apod. – entitně relační diagramy, data flow diagramy, vývojové diagramy,UML, objektová pojetí návrhu, programátorské paradigma (funkcionální, logické,imperativní, . . . ).

Detailní návrh projektovaného systému

Na globální návrh projektovaného systému navazuje návrh detailní, kde docházík úplné detailizaci až na elementární úroveň. Z jednotlivých hledisek dochází k pře-chodu od logického návrhu k návrhu fyzickému, tzn. k návrhu závislému na zvolenémtechnologickém prostředí (platforma, programovací jazyk, konkrétní užitý hardwareapod.). Z hlediska informačního dochází k výběru konkrétního způsobu uchovánídat (databáze, soubory), struktura jednotlivých vět, výběr vhodných datových typů,odhaduje se velikost báze dat (pro stanovení požadavků na hardware a definice al-goritmů zajišťujících splnění doby odezvy), četnost přístupů (pro potřeby indexacedat), navrhují se konkrétní vstupně/výstupní obrazovky a příslušné tiskové sestavy.V oblasti procesní a funkční architektury dochází k dekompozici transakcí na

jednotlivé kroky, navrhují se použité algoritmy, způsoby komunikace s uživatelem,plánuje se testování systému. Ze softwarového hlediska se provádí návrh jednotli-vých modulů informačního systému včetně vstupů a výstupů, použitých algoritmů,zvoleného programovacího jazyka, určují se přesné standardy a programové vzory,na základě kterých poté může probíhat implementace. V oblasti hardware se kon-kretizuje konfigurace jednotlivých zařízení (počítače, tiskárny, síťové prvky atd.),jejich rozmístění, harmonogram instalace, případné potřeby úprav místností či bu-dov, rozsáhlé personální změny, plán školení a obsah těchto školení aj.

Implementace řešení

Detailním návrhem skončila specifikace charakteristik systému, tj. návrh novýchstruktur v systému řízení (prvků a vazeb), návrh nových řídících procesů v navr-


hovaných strukturách (toky dat, algoritmy, zpracování), návrh charakteristik řídíchstruktur a procesů a návrh vztahů struktur a procesů. Cílem následující fáze – im-plementace – je navržený systém realizovat ve zvoleném technologickém prostředí,které je definované ve fázi detailního návrhu.Je třeba vytvořit databázi, provést naplnění iniciálními (případně i testova-

cími) daty, zvolit metodu zavádění (postupné zavádění po etapách a modulech nebokompletní zavádění metodou velkého třesku, zavádění po lokalitách (experimentálníověření funkčnosti) nebo v celém podniku najednou). Z pracovního hlediska je třebaudržovat pracovní kolektiv, vybrat pracovníky pro provoz informačního systému,provádět úvodní školení uživatelů.V oblasti software dochází k vlastnímu vývoji jednotlivých programových mo-

dulů a aplikací na základě vytvořených vzorů či s použitím nástrojů pro jejich tvorbu(generátory, CASE). Vše je třeba dokumentovat z hlediska programátorského (dalšírozšiřování, oprava chyb) i uživatelského (pro účely školení, provozu). Vyvíjené apli-kace je třeba testovat na správnost i dostatečný výkon (podle předem stanovenýchhledisek, např. doba odezvy či zatížení) a na základě výsledků testů případně prová-dět potřebné úpravy. Nakupuje se hardware potřebný k provozování informačníhosystému, konfiguruje se, testuje na stanovené parametry, provádí se předinstalace.

Zavádění informačního systému

Poslední fází prováděnou projekčním týmem je zavádění informačního systému.V této fázi se systém zavádí do organizace včetně souvisejících plánovaných změn.Předávají se pokyny pro pracovníky obstarávající provoz (provozní tým), předáváse uživatelská dokumentace, organizační předpisy a operační postupy (zpracovánídávkových úloh, spuštění a ukončení systému, postup při vzniku chyby, výpadku,modernizaci).Na základě akceptačního testu a vyhodnocení výsledků se ukončí starý systém,

příp. je tento systém převeden do pomocného režimu, aby jej bylo možné využítke zpětným analýzám za evidované provozní období. Jednotliví uživatelé obdržínová přihlašovací jména a hesla pro nový systém, účastní se plánovaných školenív oblasti používání informačního systému i v oblasti nových organizačních předpisůa pokynů. Dochází k instalaci sofware potřebného k chodu informačního systému,definitivně se instaluje, konfiguruje a testuje hardware a počítačové sítě. Na systémujsou vykonávány zátežové testy a testy s provozními daty. Celé zavádění se řídípodrobným harmonogramem, aby bylo možné minimalizovat dobu přechodu mezistarým a novým systémem.

Provoz a údržba nového systému

Ve fázi provozu a údržby se na základě zkušeností z využívání informačního sys-tému a nových technologií mohou provádět modifikace. Vycházejí jak z nalezenýchchyb, tak na základě požadavků uživatelů tohoto informačního systému. Všechnychybové stavy a požadavky jsou nejprve vyhodnoceny, určí se, jaké konkrétní zásahy

5.2 Modely životního cyklu IS 38

bude třeba vykonat, provedou se nutné změny a opravený systém je distribuovánmezi uživatele (včetně informování o změně a případného doškolení či přeškolení).Podle těchto změn je prováděna i průběžná aktualizace dokumentace, která zároveňslouží uživatelům jako orientace v řešených problémech. V oblasti hardware se pro-vádí jeho údržba a případná obnova, dokupování, posilování (škálování) či vytvářeníredundance (záloh pro případ výpadku).

Konec života systému

V okamžiku přechodu na nový systém ukončuje starý systém svůj životní cyklus.Je však využit jako základ pro analýzu nového systému, pro tvorbu úvodní studienového systému a po řadu dalších let může sloužit jako referenční systém, příp.systém pro analýzu starých dat (např. elektrárny užívají pro data z konkrétníhoobdobí systémy provozované v době pořízení těchto dat).

5.2 Modely životního cyklu IS

Nalezení univerzálního modelu pro řízení výstavby a celého životního cyklu infor-mačního systému je nemožné. Existuje však celá řada v praxi prověřených modelů,které nabízí základní užívaná paradigmata v řízení návrhu, vývoje, zavádění a pro-vozování informačních systémů. Jedná se především o model vodopád, iterativnímodel, model výzkumník a model prototypování. V reálné praxi často dochází k vy-užití kombinace těchto modelů. Pro lepší pochopení námi užité metody řízení vývojea provozu Univerzitního informačního systému si tyto základní modely představme(na základě [12] a [17]).

Model vodopád

V tomto modelu každá etapa začíná až v okamžiku, kdy je etapa předcházejícíúplně a úspěšně dokončena. Jakýkoliv návrat zpět k předcházejícím etapám či před-bíhání není přípustné.6 Toto řešení je možné pouze v případě, že budoucí uživatelinformačního systému je schopen předem úplně a trvale (beze změny) definovat svépožadavky, že nedojde ke změně používaných technologií, a že řešitelský tým je na-tolik profesionální, že je schopen tento postup přesně zvládnout. To samozřejmě veskutečnosti nebývá. Tento model je proto považován za model řadící za sebe jednot-livé fáze tak, jak odpovídají logickému postupu akcí – analýza, návrh, implementace,testování, zavádění.Mezi hlavní problémy tohoto klasického modelu, který je vhodný pro syste-

matického a konzervativního manažera projektu, patří především problém přesnéformulace zadání a fakt, že provozuschopná verze informačního systému je uživateli(ale i dodavateli) dostupná až v posledních etapách projektu. Existence případnýchnedostatků je pak odhalena až v závěru projektu a může mít zcela zásadní důsledky

6Podobně jako voda nemůže téci vodopádem nahoru.

5.2 Modely životního cyklu IS 39

jak v úspěšnosti projektu, tak ve finančních nákladech spojených s jejich odstraně-ním.Úspěšně lze tento model využít ve vývoji v sekvencích (tj. v definici postupných

kroků v podobě stanovení informační strategie a architektury systému, analýze po-třeb, návrhu prototypu, ladění představ uživatele prototypem, vytvoření konečnéhořešení a instalace s předáním a akceptačním testem). Tím vzniká hrubá koncepceživotního cyklu projektu, ve které je použití modelu vodopádu na místě.

Iterativní model

Iterativní model je vhodný v tom případě, že budoucí uživatel bude průběžně zasa-hovat do tvorby systému. Obvykle si totiž s postupem času zadavatel uvědomí, jakédalší funkce by mohl potřebovat a mění se tak jeho požadavky na kvalitu budoucíhosystému (a mnohdy i na kvantitu – tj. množství funkcí, systémů a subsystémů).Nejprve je provedena základní úvodní studie, pak následuje fáze analýzy, návrhu

a imlementace. V případě, že vzniknou další požadavky na změnu, vrací se vývojzpět do fáze analýzy. Tento cyklus probíhá tak dlouho, než jsou všechny připomínkyimplementovány a pak se vytvoří konečná verze. Ta se teprve předává k používánízadavatelem. Tento model je pro dodavatele přijatelnější z důvodu spoluzodpověd-nosti zadavatele na rozsahu funkcí a správné plnění jednotlivých cílů úvodní studie.Je totiž nutná aktivní účast zadavatele na vývoji produktu. Navíc má zadavatelpřehled o postupu plnění jednotlivých cílů a etap projektu.

Model výzkumník

Tento model je vhodné použít v případě, že je žádoucí se spolu s přibývajícímizkušenostmi vracet k předchozím etapám a provádět korekce či další rozšiřovánívýsledků těchto etap. Konečný produkt je předán v okamžiku, kdy je jeho stav proodběratele již přijatelný. Tento postup je náročný na celkové řízení, etapy lze těžkodopředu plánovat z hlediska financí, času a personálního zabezpečení.Často se zapomíná na tvorbu dokumentace a dodatečně vzniklá dokumentace

pak odráží konečný stav a nebere v ohled původní uživatelské požadavky. Nenítak možné uřčit, co bylo v původním zadání (může dojít ke sporům dodavatelea zadavatele nad obsahem projektu). U tohoto modelu také hrozí odpoutávání se odhlavního směru vývoje a neustálému toku oprav a úprav v jedné etapě (výzkumnickéhrátky, jejichž výsledkem je jeden dokonalý a třicet nedodělaných modulů).7

Model prototypování

Prototyp je chápán jako částečná implemetace produktu (na logické nebo fyzickéúrovni), kde jsou zahrnuty všechna vnější rozhraní (tj. jedná se o vizuální obálku sys-

7Vývoj Univerzitního informačního systému po vnější stránce připomíná velmi chaos modeluvýzkumník, ovšem vývojový tým užívá různé modely vývoje (viz později) a tento zdánlivý chaosje způsoben především chybějícím zadáním ze strany vedení univerzity při řešení projektu.

5.3 Způsob pořízení informačního systému 40

tému). Na počátku prototypování je fáze inicializace projektu. Dochází v ní k pláno-vání jednotlivých procesů, k vytvoření časového plánu, formování řešitelského týmu,detailnímu rozkladu prací, sestavení finančního plánu a určení plánu odpovědnostiza systém.Poté dochází k vytvoření informační strategie, ve které jsou analyzovány uživa-

telské cíle, formulována organizační strategie a sestaven návrh architektury. Násle-duje fáze definice architektury informačního systému – prozkoumá se výchozí stav,definují se jednotlivé požadavky na architekturu a na základě nekolika variant sevybere jedna, která bude implementována. Pro ní se vytvoří přesná definice a pro-vede se kontrola této definice. Poté přichází na řadu tvorba jednotlivých komponentaž do okamžiku, kdy je celý systém kompletní. Jednotlivé etapy jsou nejprve proto-typovány a následně implementovány.Cílem prototypování je vytvořit v krátkém čase funkční systém (prototyp), aby

bylo možné naplnit databázi reálnými daty a provádět s nimi běžné operace. Nazákladě prototypu také zadavatel přesně pochopí chování a rozhraní tvořeného pro-jektu a s dostatečným předstihem může korigovat svou představu. Tento model nenívhodný pro rozsáhlé projekty – jeho realizace je příliš obtížná a neekonomická. U roz-sáhlých modelů je vhodné využít kombinaci prototypování s modelem výzkumník.

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

Stejně jako existuje řada možností pro řízení vlastního návrhu, vývoje, zaváděnía provozu systému, existuje i celá škála možností, jak pořídit nový informační systém.Mezi základní způsoby patří vývoj systému vlastními silami, vývoj externí společ-ností, nákup typového informačního systému, který je následně upraven pro potřebyorganizace, zakoupení parametrizovaného informačního systému a nastavení těchtoparametrů nebo kompletní dodávka systému pomocí outsourcingu. Výběr vhodnéhozpůsobu provádí zadavatel a vlastní provedení svěřuje systémovému integrátorovijako osobě či podniku s nejvyšší kvalifikací pro zajištění celé dodávky.

Vývoj systému vlastními silami

Vývoj systému vlastními silami je nejnákladnější způsob vývoje systému. Podnik čiorganizace musí disponovat dostatečnou personální a technologickou základnou prozajištění dlouhodobého vytváření a zavádění systému a musí mít dostatek prostředkůk profinancování tohoto procesu. Odměnou za nákladnost vývoje je systém přesněsplňující požadavky organizace (tzv. vývoj na míru). Velkým problémem se můžestát postavení vývoje na jednom klíčovém pracovníkovi (znalci technologie), jehožodchod by byl pro organizaci katastrofou.

Vývoj systému externí společností

Tento druh vývoje je analogický s předchozím typem, ale není nutné vlastnit roz-sáhlou technologickou a personální základnu. Jedná se ve své podstatě o outsourcing

5.3 Způsob pořízení informačního systému 41

vývoje. Externí společnost vyvíjí systém přesně na míru při zachování všech výhodpředchozího bodu. Náklady na systém jsou pochopitelně nižší. Problémem se všakmůže stát komunikace mezi dodavatelem a zadavatelem a velká neprůhlednost ře-šení. Dochází navíc k velkému provázání společností zadavatele a dodavatele, což jepředevším ve veřejnoprávních a státních institucích něchtěný jev.

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

Typových informačních systémů je na současném trhu celá řada. Náklady na jejichpořízení nejsou vysoké, ale náklady za přizpůsobení se podniku těmto systémům(nebo přizpůsobení systémů potřebám podniku) mohou být v konečném efektu vyššínež vlastní či dodavatelský vývoj systému. Přesto se jedná o jednu z nejoblíbenějšíchforem pořízení informačního systému.8 Velkým problémem typových informačníchsystémů je nutnost adaptace a lokalizace na národní podmínky, protože většinatěchto systémů je vytvářena nadnárodními společnostmi, jako je např. SAP, Oracle,QAD, LCS, SPA AG, Minihouse Automatisering či UpDate Marketing Service.

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

Oproti typovým informačním systémům je možné parametrizovaný informační sys-tém přizpůsobit potřebám organizace na uživatelské úrovni – lze nastavit parametrysystému tak, aby alespoň zhruba vyhovovaly příslušné organizaci. Jejich cena je všakvyšší než u typových informačních systémů, protože i vývoj je nákladnější (více vari-ant ovlivnitelných parametrem). Většina velkých společností zmíněná i v předchozímzpůsobu pořízení dnes přechází na vývoj parametrizovaných systémů pro jejich jed-nodušší nasazení u zákazníka.

Outsourcing celého řešení

Nejmodernějším řešením je outsourcování celého projektu – od návrhu a vypraco-vání úvodní studie až po provoz systému. Platíme zde pouze za odvedenou práci,přičemž veškeré personální a technologické náklady leží na dodavateli. Dodavatel jeodpovědný za přizpůsobení systému našim požadavkům a my nemusíme řešit způ-sob, jak toho dosáhnout. Principy trhu nám pak do jisté míry zaručují, že dodavatelzvolí řešení co možná nejlevnější (aby sám dosáhl uspokojivého zisku) a systém senebude prodražovat. Současným největším problémem této metody je její novota, jetřeba ji v praxi řádně a mnohokrát odzkoušet a získat nějaké pozitivní reference nadodavatele outsourcingových služeb.

8Řada firem volí variantu nového vybudování společnosti okolo zakoupeného informačního sys-tému.

5.4 Metoda řízení vývoje a provozu UIS 42

5.4 Metoda řízení vývoje a provozu UIS

Vysoké školství je specifickým odvětvím, které se vždy vyznačovalo nedostatkemfinančních prostředků, který ve své podobě ovlivňoval i personální zdroje (nedostatekpracovníků). V současné době navíc platová situace vyhání ze školství osoby znaléaktuálních moderních technologií a vzniká tak problém i v oblasti technologickýchzdrojů a kvalifikace projektantů, analytiků, vývojových pracovníků a provozníchoperátorů.Mendelova zemědělská a lesnická univerzita v Brně zvažovala několik způsobů

dodání komplexního integrovaného informačního systému, přičemž velké naděje sevkládaly do zakoupení typového informačního systému, příp. outsourcingu. Bohuželneexistoval na univerzitě nikdo, kdo by byl ochoten riskovat zakoupení typovéhosystému a současně byl schopen provést adaptaci systému na univerzitu nebo uni-verzity na systém. S outsourcováním komplexního řešení projektu v té době ještěnebyly žádné praktické zkušenosti a škola si nemohla dovolit proinvestovat velképeníze do v té době značně spekulativního způsobu dodání systému.Přistoupila proto k řešení vývoje systému na zelené louce (komplexní vývoj)

a volila mezi dodavatelským a vlastním řešení. Vzhledem k tomu, že dodavatelskářešení nevyhovovala jejím záměrům (různorodost dodavatelů, nedostatečná stabilitadodavatelů apod.), zvolila nakonec tvorbu systému vlastními silami. Dnes, s odstu-pem řady let, se zdá toto řešení jako správné, protože umožňuje univerzitě pružněadaptovat informační systém na její měnící se potřeby. Vysoké finanční nákladyse díky nízkým platům ve školství a specifickému způsobu řízení lidských zdrojůpodařilo prakticky eliminovat.

Struktura vývojového týmu

Vývojový tým, který byl původně složen ze zaměstnanců pracujících na výzkumnémzáměru z oblasti informačních systémů se postupem času transformoval z teoreticképodoby do silně praktického složení. Na teoretických základech položených původnískupinou však tým staví dodnes. Základem týmu je kvalifikované vedení, které jesložené z pěti základních složek. Jedná se o vrcholové vedení sloužící pro styk s uni-verzitou (zadavatelem) a systémovými integrátory jednotlivých složek univerzity(přímí zástupci zadavatele), dále o analytickou skupinu (zajišťující specifikace, ná-vrhy a analýzy celého systému i jeho jednotlivých částí), realizační skupinu (vlastnívývoj a implementace ve zvoleném prostředí), datamanagement (vývojová a pro-vozní skupina obsluhující datovou vrstvu třívrstvé architektury UIS) a provoznískupina (zajišťující zavádění systému na jednotlivých částech univerzity).Vrcholové vedení a analytická skupina v současné době splývají vlivem nedo-

statku pracovníků do jediné osoby – autora této diplomové práce. Ostatní složkyjsou početnější především vlivem množství úkolů řešených v těchto skupinách. Nej-početnější je realizační skupina, která je řízena p. Františkem Dařenou a pracuje v nívíce než deset vývojových pracovníků. Jejich úkolem je vývoj jádra systému a všech


subsystémů včetně doplňkového software. Každý týden řeší tato skupina zhruba pětdesítek úkolů a pracuje minimálně na třech rozsáhlých projektech.Podstatně menší jsou několikačlené skupiny datamanagementu (řízené Bc. Ja-

nemMüllerem), která zajišťuje realizaci datového modelu, iniciální plnění daty a hro-madné datové úpravy během fáze zavádění, a skupiny provozu (řízené Ing. HanouNetrefovou), která plní úkoly vyplývající z každodenního styku se systémovými inte-grátory i běžnými uživateli systému. Jednotliví pracovníci jsou dle aktuální potřebyalokování v příslušných sekcích, takže dochází ke krátkodobé migraci pracovníků namísta se zvýšeným výskytem problémů.Realizační sekce vzhledem k náročnosti problémů, které musí řešit, má složitou

členitou vnitřní strukturu podle plněných úkolů, která je dynamicky přestavovánas každým novým úkolem (i několikrát týdně). Tento způsob vnitřní struktury týmuse ve zpětné perspektivě několika let jeví jako velmi efektivní a úsporný. Docházík maximální eliminaci prostojů dynamickou alokací pracovních sil a přizpůsobenípersonálních zdrojů aktuálním potřebám.

Zavádění systému na univerzitě

Pro rychlé zavádění a provoz systému na univerzitě byla vytvořena speciální hiear-chická stromová struktura, která umožňuje rychle a efektivně plnit systém daty,školit uživatele a současně poskytovat jednotnou zpětnou odezvu na vytvořené novéfunkce systému.Základem této struktury je skupina systémových integrátorů. Celá univerzita

pracuje na základě pevné struktury pracovišť, kde na nejvyšší úrovni stojí samotnáuniverzita. Na druhé úrovni jsou jednotlivé fakulty (příp. rektorát, celoškolská praco-viště, Ústřední správa kolejí a menz a vysokoškolské zemědělské a lesnické podniky).Na třetí úrovni jsou potom jednotlivé ústavy (příp. děkanáty, arboreta, skleníky,laboratoře a další organizační útvary). Dříve existovalo dělení na čtyři úrovně, kdyse ústavy dělily na sekce a pracovní skupiny. Toto podrobné dělení bylo ale výnosemrektora zrušeno již před několika lety.Systémový integrátor univerzity (v současné době tuto funkci zastává vývojový

tým, ale probíhají přípravy na jmenování příslušného pracovníka) zajišťuje inte-graci univerzity jako celku a je rovnoceným partnerem vývojového týmu. Je přímýmnadřízeným systémových integrátorů fakult a systémových integrátorů nefakultníchpracovišť (druhé úrovně). V současné době vývojový tým jako své partnery uvažujeprávě tyto integrátory.Příslušný integrátor je tzv. „druhý muž fakultyÿ, který má za úkol zavádět

informační systém a ostatní informační a komunikační technologie na příslušnémpracovišti. Pro tento úkol si buduje rozsáhlou síť dvou typů pracovníků na všechpracovištích třetí úrovně spadající pod jeho fakultu (tj. na ústavech). Jedná seo tzv. OSSA (osoby spravující studijní agendu), což jsou de facto systémoví in-tegrátoři jednotlivých ústavů a jejich úloha již dávno přesáhla jen správu studijníagendy, a o tzv. OSVT (osoby spravující výpočetní techniku) zodpovědné za zavá-


dění nových informačních a komunikačních technologií, správu počítačů a školeníuživatelů v tzv. informatickém minimu (používání kancelářského software – textovýeditor, tabulkový procesor, dále užívání elektronické pošty a práce s internetovýmprohlížečem).Vzhledem k tomu, že jednotliví fakultní integrátoři si řídí svoji činnost sami,

mohou výrazně ovlivnit rychlost integrace jejich pracoviště a lze tak systém inte-grovat po lokalitách (typicky je v UIS nejprve integrováno nové řešení na Provozněekonomické fakultě a teprve později je integrováno na ostatních fakultách či nefa-kultních pracovištích).

Metoda úkolového řízení vývojového týmu

Pro dosažení vysoké rychlosti při vývoji Univerzitního informačního systému bylavytvořena poměrně efektivní metoda úkolového řízení jednotlivých pracovníků. Zá-kladem této metody je začlenění do sekcí a přidělení dlouhodobého pracovního úkolu(poštovní systém, přístupový systém, jádro systému, systém formulářů a šablonnebo dokumentační systém), na kterém pracovník pracuje ve všech volných chví-lích. Průběžně při této práci jsou mu však přidělovány úkoly dle aktuální potřeby,které pracovník přednostně řeší. V okamžiku, kdy v úkolu narazí na problém, pro-blém ohlásí a pokračuje v práci na dlouhodobém projektu. Analogicky při dokončeníúkolu předá úkol do další fáze (např. testování či zavádění) a věnuje se opět svémudlouhodobému úkolu.Některé úkoly vyžadují týmovou práci, kdy na úkolu může pracovat i několik

pracovníků současně, ale v určitých záchytných bodech úkolů se musí vzájemně syn-chronizovat. Ve volném čase při čekání na ostatní pracuje vývojový pracovník opětna svém dlouhodobém úkolu. Tímto způsobem jsou prakticky eliminovány veškeréprostoje a všichni pracovníci jsou vytíženi na plnou kapacitu. Samozřejmě by v sys-tému úkolů brzy vznikl zmatek a nebyl by vůbec kontrolovatelný ze strany vedenísekcí či celého vývojového týmu. Proto byl vytvořen řídící systém tzv. TODO bloků,kde jsou jednotlivé úkoly evidovány spolu se stavem, prioritou, datem předpokláda-ného dokončení, přidělenými pracovníky a podrobnými komentáři o průběhu plnění.V současné době prochází tento systém rekonstrukcí, kdy bude možné přímo

z tohoto systému generovat zadání úkolů, průběžné protokoly, část dokumentacea projekčně-časový model (spotřebované personální zdroje a čas na řešení jednotli-vých úkolů, překryv a počet přerušení pracovníka směrem k naléhavějším úkolům).Tyto údaje umožní vedení týmu i jednotlivých sekcí lépe plánovat čas a směr vývojea přidělovat úkoly pracovníkům tak, aby přerušování bylo minimalizované.

Použitý model životního cyklu

Vývojový tým používá poměrně specifickou kombinaci jednotlivých modelů život-ního cyklu projektu. Základem je klasický model vodopádu, kdy základní cíle a jádrosystému jsou vyvinuty bez možnosti návratu zpět (čímž se zjednoduší jejich vývoj –po dobu tohoto vývoje totiž celý vývojový tým stojí a nikdo nemůže pracovat; jednou

5.5 Řízení lidských zdrojů ve specifických podmínkách UIS 45

bylo nutné již toto jádro přeprogramovat a vznikl dvouměsíční prostoj celého týmu).V ostatních etapách je použit model iterativní, kdy jsou podle harmonogramu vyví-jeny moduly požadované univerzitou, ale univerzita sama zpětně zasahuje do tohotoharmonogramu a obohacuje jej o nové požadavky.Jednotlivé požadavky (moduly) jsou zpracovávány metodou prototypování, kdy

příslušný modul je nejprve vytvořen v hrubých rysech, aby univerzita a předevšímintegrátoři získali základní představu o připravovaných funkcích. Poté je tento mo-dul rozvinut metodou výzkumník, kdy integrátoři zpětně zasahují do vývoje modulua průběžně požadují přepracování některých jeho částí. Tímto způsobem tedy vývo-jový tým vytvořil kombinaci všech čtyř základních metod životního cyklu projektuna různých úrovních systému.Současně byla zvolena metoda just-in-time-developing, kdy je systém současně

provozován a vyvíjen a několikrát denně dochází k aktualizaci systému na nově vyvi-nuté a otestované moduly. Tímto způsobem lze nejrychleji odstraňovat vzniklé pro-blémy a přizpůsobovat systém přáním univerzity (systémových integrátorů). Oprotimetodě jednoměsíčních aktualizací se tak systém ubírá vpřed mílovými kroky.Vzhledem k využití třívrstvé architektury a webového informačního systému je

také možné systém průběžně modifikovat na jediném místě a změna se ihned projevíu všech uživatelů (používání standardizovaných tenkých klientů bez nutnosti jejichzměny při každé iteraci systému).

Výhody a nevýhody zvolené metody

Obrovskou výhodou zvolené metody vývoje je rychlý vývoj, přesná a rychlá adaptacena požadavky univerzity a maximalizace využití dostupných zdrojů při minimálníchnákladech. To nám umožňuje vyvíjet systém vlastními silami za ceny zhruba rovno-cenné s dodavatelským řešením. Celý tým vystupuje v pozici outsourcera systému,čímž navenek vytváří skupinu, u které lze hodnotit její efektivitu a srovnávat jís ostatními možnostmi současného trhu.Za velkou nevýhodu však lze označit problematiku provázanosti vývoje a pro-

vozu, kdy není možné předat provoz aplikací do rutinní správy univerzitě vzhledemk nepřetržitému toku aktualizací (neexistuje žádná aktualizační rutina, vše probíháv okamžiku zveřejnění nové verze samočinně přímo z vývojového serveru). Tentoproblém je nám často (především ze strany Ústavu výpočetní techniky) vytýkán.Avšak vzhledem k výhodám, které nám tato metoda přináší, je tato nevýhoda za-nedbatelná.

5.5 Řízení lidských zdrojů ve specifických podmínkách UIS

Nedostatek financí na českých univerzitách nás nutí k volbě netradičních prostředkůpro motivování pracovníků v řízení lidských zdrojů uvnitř vývojového týmu. Všechnypracovníky vývojového týmu (bez ohledu na výkon či kvalitu práce) lze rozdělit dotří kategorií podle financování a organizační příslušnosti.

5.5 Řízení lidských zdrojů ve specifických podmínkách UIS 46

První kategorii vytváří pracovníci univerzity zaměstnaní na různě velké úvazky(typicky poloviční) na různých pracovištích (nejčastěji Ústav informatiky PEF a Od-dělení automatizace informační soustavy Rektorátu MZLU v Brně). Tito pracovnícijsou placeni podle standardních tabulek jako ostatní pracovníci univerzity a lze jemotivovat i po stránce finanční (mimo ostatní níže uvedené metody).Druhou kategorii tvoří pracovníci pracující jako demonstrátoři (především

Ústavu informatiky), kteří dostávají mimořádné stipendium, které umožňuje jejichčástečnou finanční motivaci. Zde již však hrají významnou roli především ostatnímotivační faktory, vzhledem k výši stipendia. Poslední kategorii tvoří pracovníci pra-cující zcela zdarma. U nich hrají roli pouze nepeněžní faktory. V současné době jsoupřijímání všichni pracovníci již jen do třetí kategorie, přesto zájem o práci v týmupřevyšuje poptávku (práce je sice dost, ale není dost techniky, prostoru a dalšíhomateriálního zabezpečení).A jaké jsou ty nepeněžní motivační faktory? Základním faktorem je možnost

být při zavádění velkého systému a získávat zkušenosti. Protože zkušenosti jsoupozději v zaměstnání bohatě honorovány, jedná se o jistou formu odložené peněžnímotivace. Tyto zkušenosti lze získávat jednak z knih a materiálů vývojového týmu,ale také z diskuzí s ostatními pracovníky, především pak s dlouholetými pracov-níky s bohatými zkušenostmi z předchozího působení a předchozích informačníchsystémů.Dalším významným faktorem je pronikání do univerzitního prostředí, kde řada

pracovníků získává významné kontakty, buduje si zázemí pro své současné i potenci-ální (doktorské) studium, vytváří si předpoklady pro svou diplomovou, bakalářskouči disertační práci a získává přístup k informacím v předstihu před ostatními stu-denty (konkurenční výhoda).Mezi ostatní faktory pak patří možnost budovat si v prostorách školy zázemí

(pracoviště), přístup k výpočetní technice (i mimo standardní dobu dostupnostitechniky studentům), vždy volné místo u počítače a příjemná atmosféra přátelskéhokolektivu vývojových pracovníků, který se věnuje i mimopracovním motivačním čin-nostem (plavání v pronajaté dráze, společné pracovní obědy, výjezdy, dovážka po-travin z paletových prodejen, plánované promítání filmů, školení a přednášky, účastna vědeckých konferencích aj.).

6 ZÁKLADNÍ CÍLE UIS 47

6 Základní cíle UIS

Vzhledem k existenci celé řady proprietárních velmi decentralizovaných automatizo-vaných informačních systémů řešících desítky různých agend celoškolského, fakult-ního či ústavního významu (vytvořených v průběhu několika uplynulých desítek let)a problému několika dosud používaných agend v důsledku změny systému studiana naší škole (přechod ke kreditnímu systému ECTS je učinil nepoužitelným) při-stoupilo vedení univerzity k podpoře snah Provozně ekonomické fakulty v tvorběnového integrovaného informačního systému nazvaném Univerzitní informační sys-tém (UIS).Hlavní cíle tohoto projektu jsou zejména:

• centralizace a sjednocení různých používaných proprietárních informačních sys-témů,

• zpřístupnění evidovaných údajů všem uživatelům, kteří údaje potřebují, v jejichnejaktuálnější podobě,

• odstranění duplicit a zavedení jednotných standardů v oblasti IS/ICT,• podpora kreditního systému studia ECTS,• propojení oblastí výuky a vědy do jednoho spolupracujícího systému,• implementace modelu plně elektronické (bezpapírové) kanceláře v co nejširšímožné míře,

• vytvoření podmínek pro účelné zavádění nových technologií na naší škole (iden-tifikační systémy, stravovací systém aj.),

• zvýšení počítačové gramotnosti zaměstnanců a studentů naší školy a• rozvoj schopností pracovníků univerzity, kteří se na vývoji podílejí.

6.1 Administrativní podmínky a uživatelé systému

Vývoj a provoz Univerzitního informačního systému je velmi náročný na lidskézdroje. Strategii zavádění systému řídí přímo vedení univerzity (kvestorka a prorek-tor pro studium), které pro odborná rozhodnutí konzultuje Poradní komisi rektorapro rozvoj IS/ICT, jejímiž členy jsou vedoucí všech odborných pracovišť, které při-chází s informatikou do činnosti, a také vedoucí vývojového týmu UIS. Operativnířízení vývoje a provozu je ponecháno na Oddělení automatizace informační soustavy.Vývoj systému je dále řízen vedoucím vývojového týmu, který má v současné dobědvě desítky kvalifikovaných vývojových pracovníků.Pro zajištění hladkého chodu integrace systému na jednotlivé fakulty jsou na

fakultách vytvořeny funkce systémových integrátorů fakult (a systémového integrá-tora rektorátu pro rektorát, celoškolská pracoviště, koleje, menzy a školní podniky).Systémoví integrátoři implementují systém na konkrétní fakultě, delegují oprávněník jednotlivým aplikacím a školí vlastní uživatele. Současně shromažďují podkladypro další rozvoj informačního systému. Systémoví integrátoři si mohou vytvořitvlastní stromovou strukturu pracovníků pro rychlou podporu jednotlivých praco-višť (ústavů, oddělení, útvarů) – obvykle jednu osobu na jeden ústav. Vzhledem

6.2 Technické podmínky 48

k tomu, že systémoví integrátoři mohou výrazně ovlivnit směr rozvoje informačníhosystému, konzultují řadu problémů přímo s vedením příslušných fakult (děkani, stu-dijní proděkani).Univerzitní informační systém využívá několik velkých skupin uživatelů, při-

čemž jednotný právní systém zajišťuje přístup uživatelů k omezené množině jimpřístupných agend (řízení právního systému je ponecháno na systémových integrá-torech jednotlivých fakult). Jednotlivé skupiny uživatelů jsou

• učitelé – využívají systém mj. ke komunikaci se studenty, vytváření informacípro studenty, elektronické přihlašování na zkoušky a sestavování záznamníkuučitele a zkušební zprávy,

• studenti – systém užívají především pro elektronické přihlašování na zkoušky,získávání informací o svém studiu, komunikaci s vyučujícími a studijním oddě-lením a tisk rozvrhů,

• vedení univerzity, fakult a studijní oddělení – používají systém mj. pro řízenísystému studia, zjišťování zájmu o vypsání předmětu (registrace), zápis stu-dentů, sestavování Katalogu předmětů, vytváření rozvrhů a zjišťování průběž-ných výsledků studia jednotlivých studentů a tisk výstupních sestav,

• zaměstnanci Správy kolejí a menz – vytváří předpoklady pro obsazování místna kolejích studenty a řídí stravovací systém,

• ostatní zaměstnanci univerzity – používají systém pro kontrolu svých evidova-ných údajů, přístup k evaluacím pracovníků a komunikaci s ostatními zaměst-nanci, tisk telefonního seznamu apod.,

• systémoví integrátoři – mj. řídí chování systému na jednotlivých fakultách,ovlivňují identifikační systém, delegují pravomoce na další uživatele,

• vývoj systému – tito pracovníci využívají také dokumentační funkce informač-ního systému a nástroje pro simulaci problémů uživatelů.

6.2 Technické podmínky

Z technického hlediska bylo na nově budovaný informační systém po rozsáhlé diskuzistanoveno několik důležitých kritérií

• systém bude umožňovat připojení z libovolného místa, kde je dostupný Internet– tento požadavek splňuje nejlépe webový informační systém, ovšem pro potřebystudijních oddělení a oddělení, kde vzniká velké množství dat, je připravovánataké klasická klient/server aplikace komunikující s informačním systémem přesvhodný middleware server,

• systém bude obsahovat všechna potřebná data právě jednou (tj. bez zbyteč-ných redundancí) – při analýze datového modelu bylo nutno k tomuto faktupřihlédnout a navrhnout systém pro zjištění této jednoznačnosti, velká práce po-tom byla odvedena též datamanagementem v okamžiku převodu starých údajůdo nového systému, kdy musely být statisíce údajů prakticky ručně přečištěnya zjednoznačněny,

6.3 UIS jako priorita univerzity 49

• systém bude pracovat s obecným právním systémem zajišťujícím vhodný kon-textový pohled pro pracovníky na všech stupních řízení – tj. byl implementovánprávní systém definující uživatele, skupiny uživatelů (s možností obsahovat opětdalší skupiny uživatelů), práva, role (role je skupina práv podobně jako existujískupiny pro uživatele) a subjekty (což jsou pracoviště, vůči kterým se právavztahují) – nyní je tedy možné určit, jaká oprávnění či role mají příslušní uži-vatelé či skupiny uživatelů pro konkrétní subjekty,

• systém musí umožnit modifikaci datové základny na přání fakult bez zásahuvývojového týmu – tzn. že celý datový model je rozdělen do mnoha částí, vekterých jsou identifikovány charakteristické objekty (např. uživatelé, pracoviště,předměty, čipové karty, tiskárny, dlouhodobé úkoly apod.), pro které jsou de-finovány ucelené systémy šablon umožňující předepsat na uživatelské úrovnistrukturu doplňkových atributů těchto objektů,

• systém musí být uživatelsky přívětivý – celý systém je proto navržen maximálněobecně a parametrizovaně, aby si jednotliví uživatelé mohli systém přizpůso-bit svým zvyklostem a svému vkusu – toho je dosaženo na jedné straně zcelakonfigurovatelným ovládáním systému (design, ovládací prvky, skladba stránky,definice výstupních formátů jednotlivých sestav), na straně druhé pak rozsáhloumnožinou parametrizace pomocí systémových politik (v tomto bodu se systémopírá o periodicky prováděné výzkumy mezi uživateli systému a v nemalé mířei o připravovanou disertační práci jednoho z vývojových pracovníků na témaUživatelsky přívětivé informační systémy).

6.3 UIS jako priorita univerzity

Projekt Univerzitního informačního systému byl zařazen jako jedna z priorit univer-zity v plánu dlouhodobého rozvoje jak z hlediska rozvoje informačních technologií,tak z hlediska studijní a vědeckovýzkumné činnosti školy).Projekt se stal jednou z priorit především díky následujícím třem důvodům:

• změna studijního systému na kreditní systém ECTS vyžaduje kompletní pře-pracování několika agend provozovaných dosud na naší škole, je jistě levnějšíprovést přepracování studijního systému v součinnosti s integrací dalších sys-témů,

• integrace informačních systémů spolu s propojením, vyčištěním a zpřístupně-ním dat v konečném důsledku umožní rychle a efektivně vyhledávat informacepotřebné na všech stupních řízení školy, což představuje znatelnou úsporu v ná-kladech,

• zavádění a implementace moderních informačních technologií, které s sebounese budování Univerzitního informačního systému, má pozitivní vliv nejen nakvalitu počítačové gramotnosti na naší škole, ale také na prestiži a dobrémjménu naší univerzity v naší zemi a dalších zemí v Evropě.

7 ARCHITEKTURA UIS 50

7 Architektura UIS

Vzhledem ke komplexnosti Univerzitního informačního systému je důkladně roz-pracována základní architektura systému z několika hledisek. Tato architektura seodráží v řadě myšlenek, které formují tento informační systém a je nedílnou součástívšech návrhů a analýz vypracovaných pro tento informační systém. Nejdůležitějšíjsou technická, aplikační a datově–logická architektura. Spolu s personálním zajiš-těním (daným použitou metodou vývoje a metodou úkolového řízení pracovníků)vytváří základní kostru celého informačního systému. Personální zajištění bylo jiždiskutováno výše.

7.1 Technická architektura

Technická architektura systému představuje veškeré hardwarové zabezpečení, kteréje potřeba pro provoz Univerzitního informačního systému včetně konfigurace zá-kladních prvků tohoto hardware (síťové prvky, modemy, zálohovací zařízení), ope-rační systémy a jejich instalace a konfigurace použitých softwarových produktů.Architektura UIS sestává ze základní koncepční architektury shrnující aktuální

globální architekturu systému (které lokality obsahují jaká základní zařízení a je-jich propojení) a dále dva pohledy na architekturu centrální části UIS (provozníhoa vývojového clusteru) – staré pojetí používané do současné doby v provozu a novépojetí připravované na tento rok (zatím v ověřovacím stádiu).

Obr. 6: Globální technická architektura UIS

7.1 Technická architektura 51

Na obrázku 6 je nastíněna globální technická architektura. Základní částí jeprávě UIS cluster, který je připojen přímo do páteřní sítě MZLU v Brně. Na tutopáteřní síť jsou připojeny také jednotlivá řídící PC distribuovaná po vybranýchlokalitách v areálu (řízení přístupového systému, kamerového systému, jednotné au-tentizace apod.), a která jsou s UIS clusterem spojena pomocí šifrovaných IPinIPtunelů. Na páteřní síť jsou dále připojena dvě základní vývojová centra (místnostdemonstrátorů E03 a vývojové stanice na Ústavu informatiky.K páteřní síti jsou dále připojeny externí systémy (stravovací systém Kredit,

Knihovnický informační systém apod.), se kterými musí UIS spolupracovat. Napo-jení na další systém je prováděno přes Internet (stát a třetí firmy – např. SIMS, GTS,UIV, zdravotní pojišťovny a další). Přes Internet je také k MZLU připojena Lednicea Břeclav, kde se nachází síť Zahradnické fakulty v Lednici se dvěma řídícími bodya řadou uživatelů informačního systému.Do tohoto řešení spadá také server centrálního příjmu pošty, který přijímá e-

-maily z páteřní sítě a konzultuje UIS pro správné doručení (mimo univerzitu, nasprávný univerzitní server nebo do informačního systému). Proto je tento systémpřipojen jak do páteřní sítě, tak na Univerzitní informační systém.Vlastní UIS cluster je složen z řady počítačů a dalších síťových i nesíťových

prvků. Aktuální zapojení UIS clusteru (v provozu) je zobrazeno na obrázku 7.

Obr. 7: Architektura UIS clusteru (stávající řešení)

Stávající řešení využívá dvou základních strojů – databázového stroje Sun En-terprise 220R osazeného dvěma procesory 360MHz, 1GB operační paměti a úhrnoudiskovou kapacitou 54GB vyhrazenou pro systém, SŘBD a vlastní data. Jako SŘBDje použit Oracle Standard Database 9i licencovaný pomocí EUNIS akademické li-cence pro provozní systémy. Jako operační systém je použit Sun Solaris 8.Druhým strojem je aplikační server PC Celeron s procesorem taktovaným na

400MHz, 640MB operační paměti a 40GB pevným diskem. Na tomto stroji je pro-vozován operační systém Linux 2.4 (distribuce RedHat 7.2), programovací jazykPerl 5.6, webový server Apache 1.3 s nádstavbami mod ssl a mod perl, firewalliptables, poštovní server qmail, synchronizace času ntpd a IDS (systém včasnédetekce napadení serveru).

7.1 Technická architektura 52

Oba stroje jsou navzájem propojeny základním 100Mbit full duplex síťovýmswitchem (5 portů pro budoucí rozšiřování). Aplikační stroj slouží zároveň jakofirewall a řídící uzel sítě (celkem čtyři síťové adresy – Univerzitní informační systémis.mendelu.cz, Fakultní informační systém PEF pef.mendelu.cz, proxy brána prodatabázový stroj tarzan.mendelu.cz a řídící uzel UIS cluster node.mendelu.cz).Požadavky na systém, velké zatížení a rozvoj systémů jsou faktory vedoucí

k budování nového řešení UIS clusteru, které je znázorněno na obrázku 8.

Obr. 8: Architektura UIS clusteru (nové řešení)

Uvedené řešení rozšiřuje možnosti UIS clusteru do oblasti lepší škálovatelnostivýkonu (postupné zvyšování výkonu menšími investicemi), redundance (zajištěníprovozu při výpadku některé komponenty) a větších aplikačních možností (záloho-vání, hlasové služby, běh více informačních systémů). Celé řešení bude montovánodo standardní 19” skříně. Základem je šest odlišných komponent.První komponentu představuje firewall s přepisovacími proxy tabulkami pro ří-

zení připojení k dalším částem clusteru. Firewall je běžné PC Celeron taktované na1.2GHz a osazené 512MB paměti. Důležitá je přítomnost čtyř síťových zařízení (dvěDualHead síťové karty). Firewall je připojen dvěma redundantním linkami do páteřnísítě MZLU. Pro řízení clusteru firewall využívá load-balancing mechanismu rozdělo-vání požadavků (ověřují se techniky Round-Robin, Bandwidth detection, Randomaccess a další). Operačním systémem firewallu je Linux 2.4.

7.2 Aplikační architektura 53

Druhou komponentou jsou síťové propojovací prvky. Všechny na obrázkuzakreslené switche jsou představovány jedním základním switchem Cisco Cata-lyst 2950, který je pomocí mechanismu VLAN vhodně rozdělen na několik men-ších switchů. Tento 100Mbit full duplex switch s 24 porty představuje špičku ve svékategorii.Třetí komponentou je provozní aplikační cluster tvořený standardními stroji

PC Celeron taktovanými na 1.2GHz s 512MB operační paměti. Tyto stroje jsouprovozovány na operačním systému Linux 2.4 a zapojeny v clusteru pomocí softwareLinux Virtual Servers. Na strojích je provozováno stejné vývojové prostředí jako jeuvedeno u staré architektury.Čtvrtou komponentou jsou databázové stroje. K původnímu databázovému

stroji je přidán druhý stroj Sun Fire V880 Server osazený dvěma 750MHz procesory,4GB operační paměti a v základní konfiguraci s 216GB diskové kapacity (diskovépole). Oba stroje (plus rozšířená licence na SŘBD Oracle 9i) pracují jako redun-dantní cluster, který umožňuje převzít řízení jedním strojem v případě výpadkudruhého. Nový server pracuje jako primární.Pátou komponentou je potom vývojový server (stávající aplikační server)

s novým šestipáskovým vysokorychlostním zálohovacím robotem (pět 40GB páseka jedna čistící), multiportovou kartou a sadou šesti hlasových modemů připojenýchna rotátor pobočkové ústředny (poskytování hlasových služeb). Tento stroj je záro-veň konzolou všem ostatním strojům a prvkům v systému.Šestou komponentou je systém napájení celého UIS clusteru. Je realizován po-

mocí velké APC SmartUPS 3000INET RM a systému dálkového řízení napájeníMasterSwitch (pomocí webového prostředí lze ovládat napájení strojů).

7.2 Aplikační architektura

Pod pojmem aplikační architektura myslíme základní softwarovou výstavbu celéhoinformačního systému. Univerzitní informační systém používá klasickou třívrstvouarchitekturu, ve které je datová část realizována v SŘBD Oracle 9i, aplikační částpomocí webového informačního systému vystavěném nad webovým serverem Apachea programovacím jazykem Perl (konkrétní implementací mod perl) a šifrování spo-jení mod ssl. Prezentační vrstva je realizována jádrem systému v jazyce Perl a zob-razuje se v několika typech zařízení – základním je internetový prohlížeč HTMLstránek, podporováno je ale i zobrazování na mobilních telefonech pomocí tech-nologie W@P a pracujeme na hlasových službách dostupných na telefonním čísle45 13 51 67.Všechny moduly, ze kterých je informační systém složen jsou dále dekompo-

novány na své složky, kterými jsou rodiny aplikací (vždy několik rodin aplikací,např. Záznamník učitele, Studijní evidence a Katalog předmětů, tvoří jeden modul,např. Studijní agendu), dále aplikace (např. rodina aplikací Studijní evidence je slo-žena z aplikací Průběh studia, Studované předměty, Editace údajů osoby, Evidenceneschopenek apod.) a skripty (jednotlivé programové celky aplikací, např. Editace


údajů osoby je složena ze skriptů zobrazení údajů, editace údajů, vysvětlující nápo-vědy a validátoru opravy).Zachovává se pravidlo, že jeden vývojový pracovník pracuje na jednom skriptu.

Aplikace a rodiny aplikací mohou mít společné programové moduly, které zapouz-dřují pomocí objektově orientovaného programování řadu společných funkcí (např.výpočet průměru, test prerekvizit, editační formuláře). Tyto programové jednotky(moduly) mají různý stupeň obecnosti a nejobecnější zasahují všechny moduly (Zá-kladní a Pomocné systémy).Aplikační architekturu si lze představit také z pohledu jednotlivých realizačních

vrstev, které reprezentují logické celky, které spolu navzájem spolupracují. Archi-tekturu UIS vycházející z teorie WIS si můžeme znázornit např. schématem 9.

Obr. 9: Aplikační architektura (realizační vrstvy)

Je patrné, že základem celého systému je jádro UIS, do kterého jsou vnořenysystémy tvořící kostru UIS (nedílná součást systému, bez kterého nelze ostatní částiprovozovat) a rodiny aplikací, které představují jednotlivé aplikační celky.Jádro systému obklopuje všechny ostatní části a hraje důležitou roli jak na

vlastní aplikační vrstvě, tak na vrstvě prezentační a jako rozhraní k vrstvě datové.


Podrobně se problematikou jádra zabývá diplomová práce [11], zde si pouze nastí-níme základní strukturu.Jádro UIS je rozděleno na dvě stěžejní části – zadní a přední funkce. Zadní

funkce představují aplikační vrstvu a napojení na vrstvu datovou, přední funkcepak zajišťují personalizaci, autentizaci a prezentační vrstvu. Nejnižší částí zadníchfunkcí je API pro napojení na systém řízení báze dat. Jeho základem je DBI/DBDrozhraní jazyka Perl a obalující funkce, které zjišťují především identifikaci SQLdotazu v SQL cache (pro účely optimalizace), ladicí nástroje a detekci chyb (zasílánípodrobných informací pracovníkům vývoje).Vlastní napojení na datovou vrstvu používá vyšší vrstva, API pro datové roz-

hraní. Toto API dokáže transformovat fyzický i logický model databáze na objektověorientované pojetí UIS. Zde dochází k transformacím a zpřístupnění takových prvkůdatového modelu, jako je šablona, mutovaná šablona či obecně mutovaná šablona.Všechny ostatní části jádra a vyšší vrstvy přistupují k databázi s využitím obouuvedených API (OOP příp. fyzický přístup).Třetí vrstvu představuje skupina funkcí pro řízený audit (auditování důležitých

aplikací, kde rozhodování o důležitosti provádí programátor či analytik) a logovánípřístupů (evidují se všechny provedené operace a jejich parametry). V této částipříp. na datově-logické úrovni se plánuje také zavedení celkového auditu změněnýchdat. Čtvrtá vrstva představuje Právní systém, což je spolu s technikou šablonovánía formátů nejdůležitější součást celého systému. Tento systém (později vysvětlen)umožňuje vývojovým pracovníkům vyvíjet jednoduché aplikace, které se automa-ticky přizpůsobují různým částem univerzity.Nejvyšší část zadních funkcí představuje jádro webového informačního systému,

které řeší především problematiku odstranění nestavovosti, serializace, platformovénezávislosti. Do jádra WIS patří i některé další části jádra UIS (např. právní systémči audit), ale protože ty jsou v UIS mírně odlišné, nezahrnujeme je do této vrstvy.Přední funkce UIS představuje modul Personalizace, který umožňuje tvorbu

alternativních designů systému, přizpůsobení aplikací preferencím uživatele a vy-tváření zástupných aplikací, které umožní systém lépe a rychleji využívat. Nadtouto vrstvou je vrstva prezentační, která zahrnuje obohacení designu daty, do-plnění základních navigačních prvků a portování příslušné funkce do alternativníhprostředí (např. na mobilní telefon). Poslední vrstvou je transparentní vrstva auten-tizace (a napojení na šifrovací modul webového serveru), která provádí nezávisloukontrolu přístupu a případné přebírání identity (delegáti, superpráva).Kostru UIS mimo jádra UIS tvoří pak především Základní systémy (především

systém jednotného zobrazování a chování aplikací, systémy pro konverzi dat a propráci s netradičními typy dat). Pomocné systémy jsou pak ty systémy, které jsouvyužívány pouze určitou skupinou aplikací, ale zachovávají si vlastní míru obecnosti(výstupní systémy, tiskový systém, formáty aj.). Vlastní chování systému potomdefinují rodiny aplikací, které jsou složeny ze dvou základních realizačních vrstev –obecných aplikačních modulů a konkrétních aplikací.

7.3 Datově–logická architektura 56

Podrobnosti o této architektuře lze nalézt v [27], [28], [29] a [11]. Hrubý nástina obecnější pohled nabízí také [30]. Jádro UIS dokáže také zajistit běh aplikací mimowebové prostředí a realizovat tak dlouhodobé úkoly, konektory do jiných systémůa jednorázové konverzní systémy.

7.3 Datově–logická architektura

Veškerá data využívaná v UIS se nacházejí v databázi řízené systémem řízení bázedat Oracle Standard Database 9i. V této databázi je pro celý systém vyhrazenojedno základní schéma UIS. Existují dva základní uživatelé – uživatel uis, pomocíkterého k systému přistupují všechny aplikace a uživatel sys, který je používán přivývoji systému (definice datového modelu, správa databáze a SŘBD).Základní datový model je rozčleněn do tří základních skupin – fyzický datový

model, logický datový model a smart databázové funkce (inteligentní chování celédatabáze). Fyzický datový model je tvořen necelými čtyřmi sty tabulkami, které ob-sahují všechny evidované informace (datová báze má nyní velikost přibližně 1,5GB).Pojmenování všech tabulek vychází ze systému předpon a přípon, které nám umož-ňují orientovat se v datovém modelu. Systém předpon definuje dvě úrovně předpon– příslušnost k datovému celku a účel tabulky.Příslušnost k datovému celku se určuje pomocí jednopísmenného identifikátoru

na první pozici podle následující stanovené tabulky 1.

Tab. 1: Příslušnost k datovému celku

prefix významA dokumentace systému, TODO, řízení indexů a vývojeB záložní a obnovené tabulkyC identifikační systém (karty, přístupy, kamery, jednotná autentizace)D dokumentový server, diskuzní skupinyE ekonomický systém, napojení na EIS (ekonomický informační systém)F personalizace, designy, preferenceK kmenové tabulky (personalizace, základní číselníky, právní systém)I inventarizace, skladM menzy, stravovací systém, koleje a ubytováníN nástěnky, vývěskyO systém objednávek a rezervací např. projektů, témat diplomových pracíP poštovní systém, jednotná poštaQ převzaté číselníky ze SIS (dle [14])R rozvrhy a rezervace učebenS studijní systém, přijímací řízeníT tiskový systémV věda a výzkum, životopisy, publikace, evaluace, grantyW řízení systému, logy a audit, dlouhodobé úkoly


Druhá pozice předpony je vyhrazena pro rozlišení účelu datové tabulky. Pře-hled užívaných jednopísmenných identifikátorů je uveden v následující přehlednétabulce 2.

Tab. 2: Účel datové tabulky

prefix významA agregovaná tabulka, která vzniká dlouhodobým úkolem nebo triggeremB záložní kopie tabulky obnovená ze zálohyC číselníkI indexová tabulka obsahující fulltextové vyhledávací řetězce

Kombinací obou prefixů s názvem tabulky vzniká konkrétní datová tabulka re-prezentující entitu nebo asociace v datovém modelu – např. SC_PREDMETY předsta-vuje číselník studijního systému PREDMETY, tedy evidenci všech existujících předmětův Katalogu předmětů.Kombinací tohoto jména s příponou můžeme dostat speciální pomocné tabulky,

které slouží pro evidence atributů, struktur objektových šablon nebo pokyny prořízení indexových mechanismů apod. Přehled používaných přípon je uveden v ta-bulce 3.

Tab. 3: Užívané přípony

přípona významSABLONA struktura objektové šablony (někdy pouze SAB)ATRIBUTY hodnoty atributů objektového pohledu (někdy pouze ATR)TODO pokyny pro indexovací mechanismusHISTORIE historické záznamy v číselnících (někdy také jen HIST nebo H)

Tedy tabulka SC_PREDMETY_SABLONA je popisná tabulka struktury pro objek-tové pojetí předmětů Katalogu předmětů. Existují i další předpony, které umožnujírozlišit původ dat (např. MC_KREDIT_ jsou číselníky stravovacího systému ANETEKredit) příp. některé přípony rozlišují různé části datového celku (A_TODO_ předsta-vují tabulky příslušné k evidenci TODO bloků apod.).Přidáním přípony _SEQ pak vznikají sekvence pro přidělování hodnot primár-

ních klíčů. Rozšířením o přípony _T a další kombinace definují příslušné triggerynad tabulkami. Předpona PKG_ je určena k definici objektových balíků pro vytvá-ření smart databáze.Logický datový model vytváří soustavu pohledů a zpětných triggerů nad fyzic-

kým modelem a zajišťuje tak zpětnou kompatibilitu při změnách v datovém modelu,vyplnění mezer v datovém modelu sloužících k budoucímu rozšiřování (např. pohledKC_SUBJEKTY je určen pro budoucí rozsáhlé struktury subjektů práva v právnímsystému, ale nyní je představován jen jako pohled do číselníku pracovišť).Pod pojmem smart databázové funkce označujeme soustavu procedur, funkcí

a objektových balíků pro práci s právním systémem, automatické auditování tabulek


(částečné i úplné audity, automatické značení údajů o poslední změně – kdo a kdy,tzv. ZZ identifikace) a práci se šablonami. Smart funkce umožňují přesun části apli-kační zátěže na výkonné databázové servery a současně realizovat řadu operací přilibovolném přístupu k databázi (nejen z aplikací, ale i z ovládací konzole dbMan,grafického prostředí DBA Studio apod.).Pro údržbu datového modelu bylo nutné vytvořit několik základních nástrojů,

které může datamanagement využívat při své práci. Základním nástrojem je pro-gram dbMan, který umožňuje vývojovým pracovníkům ovládat databázi z konzo-lové aplikace. Tento nástroj je k dispozici všem uživatelům Internetu zdarma na sítiCPAN (vyhledávatelné i z portálu Freshmeat.net). Umožňuje grafickou i textovoupráci s databázi, podporuje vícenásobné spojení, transakce, placeholdery, makroja-zyk, modulární plug-iny, dohledávání příkazů a datových objektů pomocí doplňovánípříkazů tabelátorem, stránkování, vstupy a výstupy do souborů či formátování vý-stupu do různých pohledů (tabulky, SQLPlus tabulky, HTML výstup, CSV, formáto-vané TEXové tabulky aj.) nebo importování CSV souborů přímo do parametrickýchSQL dotazů. Tento nástroj je denně používán ve vývoji a velmi se osvědčil. Nástrojvytvořil jako bakalářský projekt na FI MU autor této diplomové práce.Druhým významným nástrojem je program oradump, který umožňuje zálohovat

databázové schéma fyzickým exportem nezávislým na platformě. Umožnil nám pře-chod mezi prostředím OS Linux a OS Solaris, mezi různými verzemi SŘBD Oraclea mezi různými kódováními češtiny. Není to sice nástroj denního použití, ale je vy-užitelný při komplikovaných přechodech. Díky tomuto nástroji mohl vývojový týmprovést přechod z databáze 8i na 9i během jediné noci, což se zatím nepodařiložádné jiné české univerzitě.Trojici nástrojů uzavírá program SchemaView Plus, který umožňuje kreslit da-

tové modely v grafickém prostředí Tk. Podporuje několik typů propojení včetněautomatického hledání trasy, základní funkce pro návrh datového modelu, získá-vání hotového schéma z databázových systémů a tisk těchto schémat do PostScriptu(včetně posterování až do velikosti A0). I tento nástroj je k dispozici na síti CPANa na portálu Freshmeat.net jej lze nálezt pod jménem svplus. Výstupy tohoto pro-gramu jsou použity i v této diplomové práci. Autorem obou programů je rovněžautor této diplomové práce.

8 TEORIE WEBOVÝCH INFORMAČNÍCH SYSTÉMŮ 59

8 Teorie webových informačních systémů

Práce na vývoji obou informačních systémů (fakultního i univerzitního), jakoži tvorba dalších jednoúčelových informačních systémů ze strany jednotlivých autorůUIS pro komerční či charitativní použití (např. informační systém dětské organi-zace Pionýr ČR), vedla k vytvoření aparátu popisujícímu funkce a způsoby realizacewebových informačních systémů, tedy nestavových nelinerních síťových paramet-rizovaných informačních systémů (obvykle provozovaných v prostředí World wideweb).Mezi autory teorie webových informačních systémů nyní patří především autor

této diplomové práce a František Dařena. Na její praktické aplikaci se pak dálevýrazně podílejí Bc. Tomáš Procházka (programování) a Bc. Jan Müller (databáze).Některé myšlenky jsou přepracováním zajímavých myšlenek Mgr. Jana Pazdzioryz FI MU v Brně.Systém navržený podle úváděné teorie mj. řeší problematiku autentizace, audi-

tování, modularizace, serializace, oprávnění, proměnlivého datového modelu, perso-nalizace, hiearchického zařazení uživatelů a samodokumentace.Teorie webových informačních systémů poskytuje celou řadu modelů, pomocí

kterých lze modelovat a realizovat uvedené požadavky. Tyto modely jsou nezávisléna zvolených softwarových a hardwarových prostředcích. Vývojový tým aplikovaluvedenou teorii na dvou zcela odlišných platformách (UNIX, Apache, Perl, Oraclea Windows, IIS, Delphi, Oracle) pro prostředí webu a W@Pu. Nyní probíhá aplikacena prostředí hlasových služeb. Jako databázový systém byl též několikrát použitPostgreSQL.S postupem času nalézáme stále obecnější aparát, který nám umožňuje efek-

tivně popsat realitu. Takový aparát se potom pokoušíme vhodně zařadit do celéteorie. Uvedená teorie bude námětem další vědecké práce autora této diplomovépráce především na doktorském stupni studia.

8.1 Jednotlivé aspekty teorie WIS

V současné době teorie zahrnuje celou řadu oblastí běžně řešených při návrhu a reali-zaci WIS. Jednotlivé dosud zpracované aspekty jsou popsány v následujících sekcích.

Odstranění nelinearity WIS

Každý programátor aplikací na webu řešil již problém, kdy uživatel začal užívatinformační systém v neočekávaném bodu (např. od konce sekvence požadavků), po-kusil se o návrat v posloupnosti operací (tlačítko Zpět v prohlížeči) či zopakovalněkterý požadavek (tlačítko Obnovit v prohlížeči). Tento problém je řešen pomocíserializace požadavků – jednotné identifikace požadavků, jejich posloupnosti a jed-noznačnosti.Každý požadavek je označen jedinečným identifikátorem (např. číslem vygene-

rovaným z databázové sekvence) a toto číslo je zahrnuto do všech formulářů v odpo-

8.1 Jednotlivé aspekty teorie WIS 60

vědi na požadavek. Pokud je následně formulář odeslán, je zapsáno použití tohotočísla do databáze. Pokud by došlo k opětovnému pokusu o provedení operace, sys-tém detekuje použití již použitého identifikátoru a operaci zabrání. Nevzniká takduplicita dat a uživatel je přinucen pohybovat se v systému lineárně.

Odstranění nestavovosti WIS

Specifičností prostředí www oproti klasickému prostředí klient/server je nestavovéprogramování – jednotlivé požadavky a prováděné operace nemají mezi sebou žád-nou návaznost (podobně nemají pořadí ani vstupní bod – viz nelinearita a problémys ní související) a jsou ve své postatě izolovanými přístupy k informačnímu systému.Posloupnost jednotlivých operací (např. několikakrokový výběr či posloupnost výběrdat – editace – kontrola – uložení) je pak nutné rozložit do izolovaných kroků a za-jistit transport dat mezi těmito kroky. Teorie WIS nabízí dva mechanismy přenosu– přenos parametrů mezi jednotlivými požadavky nebo sklad parametrů relace.Přenos parametrů mezi požadavky je zajišťován průběžným sběrem použitých

údajů a jejich kompletací do jednoho předávaného požadavku. Tento řetězec je potévždy zaslán klientovi ve skrytém prvku (hidden) tak, aby jej prohlížeč opět vrátilserveru (a tak nedošlo ke ztrátě dat). Nevýhodou tohoto způsobu je nutnost předávatpoměrně značné množství údajů, které stále putují mezi klientem a serverem (cožse jistě odrazí na rychlosti provozu systému vlivem zatížení komunikační linky).Druhou metodou je sklad parametrů relace, kdy všechny průběžně sbírané infor-

mace jsou ukládány do speciální datové tabulky a označeny identifikátorem, kterýje předáván stejně jako ostatní parametry v metodě přenosu parametrů mezi po-žadavky. Tento identifikátor stačí na obnovení dat podle skladu (datové tabulky).Problém vzniká, pokud uživatel přeruší posloupnost a data ve skladu tak stárnout.Jiný proces musí proto zajišťovat periodické uklízení skladu v určitých časovýchintervalech.V UIS jsou užívány obě metody, ale první metoda převládá pro svou jednodu-

chost a šetření datovými zdroji.

Autentizace a autorizace

Zjištění a prokázání totožnosti uživatele jsou často řešené problémy i v běžných in-formačních systémech, ovšem u nestavového a nelineárního WIS představují značnýproblém, který je ještě zkomplikován omezenými možnostmi klientské aplikace –např. webového prohlížeče. Teorie WIS nabízí řešení pomocí tiketování (ať již ve-řejného nebo pomocí cookies), příp. autentizací závislou na platformě (modul proserver Apache). Tiketování (jako metoda vystavěná nad odstraněním nestavovostiWIS) je obecně přenositelnější a nabízí větší možnosti v řízení relace (odhlášení,doba přihlášení, spotřeba zdrojů apod.).UIS používá metodu autentizace závislou na platformě pomocí databázového

autentizačního modulu pro webový server Apache. Na této úrovni probíhá auten-tizace zcela transparentně podle definovaných pravidel. Ovšem aplikace nedokáží


korektně řídit tuto komunikaci a tak není možné např. provést odhlášení ze systémuči kontrolovat spotřebu zdrojů a dobu přihlášení (nelze uživatele po 15 minutáchnečinnosti odhlásit a zabránit tak jinému uživateli v nepovoleném vniknutí ze zapo-menutého okna prohlížeče).Tiketování je metoda založená na autentizace plně řízené aplikací (jádrem WIS)

– v případě přístupu do autentifikované části je uživatel dotázán na jméno a heslo.Pokud se autorizace zdaří, je vygenerován tiket s omezenou platností, který je předá-ván jako parametr mezi požadavky (viz odstranění nestavovosti, tento tiket dokoncemůže být identifikátorem pro sklad). Pokud platnost tiketu vyprší nebo se aplikacerozhodne tiket dále nepředat (odhlášení), je uživatel ze systému definitivně odhlá-šen. Tato metoda nabízí nevýhodu v nutnosti trvalé generace tiketu do všech odkazůa možnost proniknutí tiketu do nešifrovaného kanálu prohlížeče a průniku v případěodposlechnutí tohoto tiketu.Pro tyto nevýhody nebyla tato metoda zvolena (UIS vyžaduje vyšší formu bez-

pečnosti). Tiketování je metoda, která je běžně využívána freemailovými servery,seznamkami, diskuzními chaty apod.

Personalizace

Přizpůsobení informačního systému potřebám a zvyklostem uživatele nespočívá jenv definici vzhledu systému (designy, parametrizace výstupního chování), ale též v na-stavení systému pomocí systémových politik (ovlivňují chování systému) a definicizástupných aplikací (umožňující vytvořit vlastní uživatelské aplikace pomocí před-definovaných komponent).UIS implementuje v prví fázi pouze nastavení základních systémových politik

(např. zobrazování či naopak nezobrazování fotografií) a variantní designy defino-vané uživatelem (a případně sdílené mezi jednotlivými uživateli). Předpokládá sepostupný vývoj až k definici zástupných aplikací, které umožňují nadefinovat siuživatelské rozhraní systému podle preferencí uživatele. Např. se automaticky ne-zobrazují dlouho nepoužívané odkazy, pokud k tomu nedá uživatel pokyn nebo jemožné vytvořit úvodní stránku z vlastní nabídky odkazů, vytvořit rychlý přístupk aplikacím definicí zástupné aplikace obsahující základní dialogy nejpoužívanějšíchaplikací apod.Personalizací se zabývá budoucí disertační práce Ing. Hany Netrefové a diplo-

mová práce Lukáše Bártíka. Jednotlivé problémy a způsob řešení v nich budou po-drobně rozpracovány.

Auditování

Auditování představuje evidenci změn provedených v informačním systému – teorieWIS nabízí nástroje pro sledování jednoduchého auditu (kdo a kdy provedl poslednízměnu, tzv. ZZ identifikace) a pro zajištění plného auditu (historie změn příslušnéhoúdaje).


V současné době UIS podporuje sledování jednoduchého auditu metodouZZ identifikace na úrovni smart funkcí datového modelu (vývoj se tedy tímto pro-blémem nezabývá). Plánován je přechod na plný audit řízený databází, kdy budemožné sledovat veškeré změny na klíčových údajích (studijní a personální systém,věda a výzkum, systém práv).Užití auditování umožňuje zobrazit konkrétní odpovědnost za vložená data,

která nutí jednotlivé pracovníky zamyslet se nad správností vkládaných dat. Po-drobně se tímto problémem zabývá [1].

Logování

Na rozdíl od auditování umožňuje logování sledovat posloupnost práce jednotlivýchuživatelů – jak z hlediska bezpečnosti, tak z hlediska podpory uživatelů (často opa-kované sekvence kroků lze nahradit zástupnou aplikací, tápající uživatele je možnonasměrovat, proškolit, příp. jim nabídnout alternativní řešení problému). Teorie WISnabízí jak úplné logování (vše a trvale), tak různé možnosti posuvného logování (ro-tující logy, postupná sublimace starých parametrů a logů).Stávající UIS provádí úplné logování všech operací a obsahuje také historii

operací z předchozí Fakultního informačního systému PEF. Existují aplikace, kterétuto historii zpřístupňují uživatelům a umožňují např. systémovým integrátorůmnebo vývojovému týmu sledovat historii operací cizích osob.

Dlouhodobé úlohy

Každý systém dříve či později vyžaduje zpracování úloh, jejichž běh přestává býtinteraktivní. V případě WIS je pak interaktivita ztížena nutností vystavit odpověďna požadavek v relativně krátké době. Řada sestav se tak z kategorie interaktivníaplikace přesouvá do dlouhodobě běžící úlohy. Teorie WIS nabízí řešení pro dlou-hodobé jednorázové i opakované úlohy včetně explicitně vyvolaných úloh. Mecha-nismem dlouhodobých úloh lze řešit též propojení informačního systému na externísystémy (vzdálené datové toky). Toto propojení nazýváme externím konektorem najiné informační systémy.V současné době provozuje UIS externí konektory ke starému systému studijní

agendy STUDENT, konektory do starvovacího systému ANETE Kredit, do ekono-mického systému EkonFIS, do Knihovnického informačního systému, do přístupo-vého systému DUHA, do systému Sdružených informací matrik studentů (SIMS), dosystémů Zdravotních pojišťoven a propojení na Ústav pro informace ve vzdělávání.Počet konektorů stále roste (plánuje se napojení na RIV, automatické propojení naUIR-ADR apod.).

Systém oprávnění

Každý informační systém definuje kategorie uživatelů, kteří smějí provádět určitétřídy úloh, a tak rozlišuje různě privilegované uživatele. Vytváří tak určitý právní


systém. Rozsáhlé systémy potom tuto problematiku komplikují existencí hiearchieuživatelů (např. pracoviště, geografická příslušnost apod.).Teorie WIS nabízí několik typů právních systémů. Nejjednodušší právní sys-

tém řeší problematiku uživatelů a jim přiřazených oprávnění, nejrozsáhlejší právnísystém umožňuje mimo uživatelů definovat též skupiny uživatelů (a skupiny ve sku-pině), ale také skupiny oprávnění (tzv. role, včetně role obsahující jiné role) a dávajído souvislosti objekty práva (uživatele, skupiny uživatelů) s právy (příp. rolemi),subjekty práva (např. hiearchická pracoviště, geografickou oblast) a atributy práva(čtení, zapisování, delegování práva apod.). Celou situaci pak provazují pomocí ča-sové platnosti jednotlivých přiřazení.UIS používá v současné době středně náročnou variantu právního systému (uži-

vatelé, skupiny, práva, subjekty, delegování, časové rozlišení) a pracuje se na zavedeníúplného systému práv. Inspirací pro budování systému práv je např. [20].

Delegáti

Při přechodu organizace od papírové administrativy k elektronické lze nalézt uži-vatele neschopné provádět agendu v elektronické podobě (nedůvěra k počítačům,obtíže s jejich zvládnutím, nedostatek času pro zvládnutí nové technologie). Abytito uživatelé nemohli zkomplikovat zavádění systému, je možné zavést definici tzv.delegátů, což jsou osoby vykonávající funkce v příslušných rodinách aplikací za pů-vodní uživatele.Jinou oblastí využití tohoto přístupu v teorii WIS je definice zastupitelů (dele-

gátů) např. na úrovni ředitel – sekretariát. Tak může legálním způsobem přistupovatsekretářka ředitele do rodin aplikací Organizace času a Pošta, aniž by např. přistu-povala k rodině aplikací Mzdy, jak by se určitě stalo při zabezpečení jejího přístupusdílením stejného hesla mezi ředitelem a její osobou.Stejné myšlenky delegátů pak mohou využít vývojoví pracovníci k definici tzv.

superpráv, což je oprávnění zobrazit si informační systém v takové podobě, v jakéjej vidí konkrétní uživatel (v rozsahu příslušné rodiny aplikací) – tato skutečnostvývojářům a integrátorům (provozovatelům systému) umožňuje odhalit problémyvzniklé špatně nastavenými právy, špatnou definicí šablon, příp. podávat uživatelůmrady přesně podle situace, v jaké se uživatel nachází.Systém delegátů i superpráv je v UISu zahrnut v maximální míře a integrátoři

jsou proškoleni k jeho využívání. Počet sdílených hesel tak výrazně klesá.

Šablonování

Při provozu velkých systémů dochází často ke změně požadavků na udržované ob-jekty a informace vedené o těchto objektech. K těmto změnám pak často docházítaké v závislosti na hiearchii uživatelů (lokální změna na jednom pracovišti, v jednélokalitě). Teorie WIS nabízí řešení pomocí definice tzv. šablon objektů, které po-pisují atributy jednotlivých objektů v závislosti na hiearchii uživatelů a právnímsystému.


Teorie WIS také rozšiřuje definici šablon o tzv. mutované šablony (kdy lze ucho-vávat informace o jednom objektu v závislosti na mutačním klíči, např. informaceo syllabu předmětu v závislosti na jazyku, tj. anglický, český, německý a ruský sylla-bus) nebo informace o prospěchu jednotlivých osob v závislosti na předmětu.Šablony přinášejí jednak dvourozměrně definovanou strukturu (objekt, atri-

buty), v podobě mutační šablony pak třírozměrnou strukturu (objekt, atributy, mu-tace). Speciální mutovaná šablona se nazývá obecně mutovaná šablona a umožňujemutace přes množinu přirozených čísel (např. evidence extra bodů k přihlášce stu-denta na VŠ, kdy množina důvodů není dopředu známa). Právě využití šablon vespojení s právním systémem umožňuje do WIS zavést maximální množství parame-trizace systému.V UIS je šablonování využíváno ve všech nových aplikacích a postupně je imple-

mentováno i do aplikací starších. Jejich použití totiž umožňuje postihnout odlišnostijednotlivých pracovišť na uživatelské úrovni. V současné době je v systému pět de-sítek šablon, z toho asi pětina mutovaných a několik obecně mutovaných šablon.

Formáty a sestavy

V závislosti na použití šablonování a právního systému dochází k potřebám přizpů-sobovat výstupní sestavy, příp. prezentovat údaje v informačním systému (definiceformátů výstupních dat). Teorie WIS nabízí postup pro přípravu modulu umožňu-jícího definici sestav a formátů zobrazení pomocí značkovacího jazyka, který obsa-huje vizuální formátovací značky dvou tříd abstrakcí (vizuální, formátové) a datovéznačky podporující ostatní možnosti teorie WIS (šablonování, mutace, vícejazyčnost,právní systém).Výstupem tohoto modulu pak nemusí být jen zobrazený výstup v prohlížeči,

ale prakticky libovolný výstupní formát (vhodně obecně popsatelný) – TEX, HTML,XML, RTF, CSV, proprietární formáty kancelářského balíku MS Office apod. Na-sazení formátů a sestav do UIS umožňuje jednotlivým fakultám přesně přizpůsobitprezentaci svých dat světu.

Vícejazyčnost

Každý systém je dříve či později nutné nasadit v několika jazykových mutacích.Teorie WIS přidává známou vlastnost jazykových překladů do možností parametri-zace WIS (uživatelé s příslušným oprávněním mohou sami definovat další překladysystému).V UIS zatím není vícejazyčnost použita, ale tato možnost bude v průběhu to-

hoto a příštího roku implementována za předpokladu existence překladatelské sku-piny (Ústav jazyků). Nutnost vícejazyčnosti vyplývá jednak ze studia zahraničníchstudentů na MZLU v Brně, ale také z důvodů snah většiny fakult o prezentaci in-formací v několika světových jazycích.


Systém výstupů a tisk

Problematika tisku sestav na tiskárnách z webového prostředí je velmi kompliko-vaná. Postup vycházející z práce Bc. Pavla Šmerka z FI MU Brno byl zahrnut doteorie webových informačních systémů. Jedná se o metodu přípravy dat pomocísázecího systému TEX do podoby PostScript nebo PDF a další rasterizace progra-mem GhostScript pro konkrétní uživatelem zvolenou tiskárnu. Na tuto tiskárnu jepak výsledek tištěn pomocí programu UNIX lpr nebo na sdílenou tiskárnu systémuMS Windows pomocí protokolu SMB (balík programů Samba).Systém výstupů a tisku zahrnuje také přehledné ovládací aplikace napodobující

chování velmi rozšířeného systému MS Windows. Systém tisku nyní v UIS procházípodstatnou rekonstrukcí a plánuje se podpora tisku na mobilních zařízeních (připo-jení uživatele přes dial-up apod.).

Modularita

Pro dosažení maximální efektivnosti koloběhu návrh – vývoj – testování – provozpřináší teorie WIS důsledné uplatnění modularity na všech úrovních rozlišitelnosti(tj. modul, rodina aplikací, aplikace, skript). Tak je možné libovolně měnit početvývojových pracovníků pracujících na konkrétním modulu, průběžně uvolňovat vý-sledky, připravovat aplikace pomocí prototypování, opravovat chyby a modernizovatsystém v závislosti na aktuálních požadavcích uživatelů systému.Podrobnosti o užití této vlastnosti teorie webových informačních systémů byly

diskutovány výše v podobě metody řízení vývoje a provozu UIS a v kapitole o ar-chitektuře UIS.

Samodokumentace

Nejvíce zanedbávanou částí při vývoji informačního systému je dokumentace (jakuživatelská, tak především vývojářská). Teorie WIS nabízí nástroje pro podporuuživatelů (nápovědy, kontexové nápovědy, často pokládané otázky, slovníček pojmů,doporučené postupy, on-line poradce, nástroje pro evidenci chyb).Nabízí také dokumentační nástroje pro vývojáře (dokumentace na třech úrov-

ních – dokumentační texty, dokumentace datového modelu (komentovaný model,schéma modelu), dokumentace programových kódů, nástroje pro plánování vývoje– úkoly (todo), časový plán (workflow), úkolování integrace a provozu). Tyto ná-stroje v maximální míře generují dokumentační texty, aby zredukovaly práci vývo-jářů v této důležité oblasti na minimum.Mezi obecné dokumentační texty celého UIS může patřit i tato diplomová práce.

Jednotnost ovládání

Teorie WIS definuje vhodné postupy, kterými lze vytvořit pěkně vypadající i kom-fortně ovladatelné aplikace z jedoduchých komponent, jaké např. pro definici formu-

8.2 Budoucnost teorie 66

lářů nabízí jazyk HTML. Tyto postupy lze snadno převést na objekty programova-cích jazyků a tak velmi elegantně realizovat aplikace zajišťující vstupy a výstupy.Současné moduly UIS pro zajištění jednotnosti ovládání umožňují zobrazo-

vání údajů v tabulkách, práci se šablonami, třídění sloupců, úpravy, předvýběry,hromadné úpravy, filtry, rozčleňování velkých číselníků podle abecedy, dohledávánía výběry, obrázkové navigační prvky a intuitivní nápovědné texty. Současně vytváříjednoduché rozhraní pro vývoj, takže nové, pohodlné a jednotné aplikace mohouvznikat velmi rychle. Důraz je kladen na vysokou „multimediálnostÿ všech aplikací.Podrobně se těmito moduly zabývá např. [11].

Indexování

Řada databázových systémů (např. Oracle) nabízí funkce na fulltextové indexovánípodřetězců, ale toto indexování není ve všech databázích stejné a není uživatelskyjednoduše konfigurovatelné. Proto teorie WIS přidává několik typů indexů, pomocíkterých si mohou uživatelé zvolit skladbu fulltextových indexů pro určité vyhle-dávání a výběry (např. k objektu uživatel si nadefinovat indexování podle jména,příjmení, rodného příjmení, čísla karty, rodného čísla, osobního čísla zaměstnance,čísla čipu v bezkontaktní kartě a identifikačního čísla osoby v systému). Vyhledávacímodul pak umožňuje jednodušší zapojení těchto indexovaných výběrů do ostatníchformulářů v systému.V současné době teorie WIS definuje čtyři základní fulltextové indexovací tech-

niky, především indexování podřetězců, indexování slov, indexování výrazů a inde-xování začátků slov. Podrobně se metodami indexování a jejich využitím zabývá [11].Díky indexování je vyhledávání a dohledávání údajů v UIS velmi rychlé a přehledné.

8.2 Budoucnost teorie

Vývojový tým předpokládá zpracování teorie webových informační systémů do po-doby praktické příručky popisující jednotlivé řešené aspekty s podrobnými postupyjejich modelování a aplikování. Takto vytvořená metodická příručka je využitelnájak pro tvorbu nových systémů, tak pro dokumentaci stávajících systémů, kde senachází jak proprietární řešení uvedených problematik, tak aplikace postupů popsa-ných teorií.Druhou oblastí zájmu vývojových pracovníků bude vytvoření obecného gene-

rátoru (toolkitu), který umožní generování koster webových informačních systémůna základě uvedené teorie. Tím bude možné neřešit stále se opakující problematikuobecných věcí a bude možné se věnovat vývoji skutečně podstatných částí infor-mačních systémů, jako jsou výpočtové funkce, kontroly dat a aplikace jednodušepořizující a opravující data. Tento generátor bude v první fázi vytvořen pro pro-středí UNIX, Apache, Perl, Oracle a prostředí www. Předpokládá se volné sdílenívýsledků bádání některým open-source portálem.

9 JEDNOTLIVÉ RODINY APLIKACÍ 67

9 Jednotlivé rodiny aplikací

Celý Univerzitní informační systém je rozčleněn do několika rozsáhlých modulů (Stu-dijní agenda, Věda a výzkum, Plně elektronická kancelář, Identifikační systém, Ří-zení UIS, Personalizace, Dokumentace), jejichž počet stále kolísá (vzhledem k rozši-řování zadání ze strany univerzity). Tyto moduly jsou složeny z řady rodin aplikací,které řeší konkrétní specifické úkoly. Popis aktuálně zpracovávaných (hotových, roz-pracovaných či analyzovaných) rodin aplikací je náplní této kapitoly.

9.1 Plánovaný projekt

Původní projekt Fakultního informačního systému PEF byl vyvíjen postupně v le-tech 1998 až 2001, kdy byl zahájen vývoj Univerzitního informačního systému. Tenje vyvíjen od jara roku 2001 a jeho vývoj je předpokládán minimálně do roku 2005.Postupně budou implementovány jednotlivé moduly z následujícího abecedního se-znamu:

• Jádro Univerzitního informačního systému – představuje všechny systémovémoduly a aplikace nutné k provozu vlastního informačního systému, obslužnéaplikace pro správce a uživatele, systém práv, šablon, výběrů, indexování, for-mulářů aj.

• Anketa k předmětům – představuje modul aplikací určených k zpětné vazbě odstudentů k učitelům (hodnocení předmětů studenty, posuzování došlých ano-nymních odpovědí, srovnání předmětů pro vedení fakulty a školy).

• Dlouhodobé úkoly – představuje kompletní agendu dlouhodobých a opakova-ných úkolů (tj. kontrolní sestavy konzistence, napojení na jiné informační sys-témy – především ekonomický informační systém školy apod.).

• Dokumentační systém – obsahuje uživatelské i vývojářské návody, dokumentacejednotlivých modulů, slovníček odborných pojmů i dokument s často pokláda-nými otázkami; řada modulů pak obsahuje ještě vlastní kontextovou nápovědupřímo v aplikacích.

• Elektronické přihlašování na zkoušky – zahrnuje všechny aplikace umožňujícíučitelům vypisovat a kontrolovat termíny jednotlivých akcí (písemné testy, zá-počty, odevzdávání seminárních prací, zkoušky apod.) a také aplikace, kterýmise studenti na tyto akce přihlašují.

• Evaluace – umožňují vedení školy a fakult získávat informace o ústavech a dálevedoucím ústavu informace o vlastním sebehodnocení zaměstnanců, jde de factoo zhodnocení příspěvku osob k roli univerzity v rámci pedagogické a vědecko-výzkumné činnosti univerzity.

• Evidence místností – umožňuje sledovat vybavení univerzity z hlediska areálů,budov a místností, jakož i kapacity, plánky rozesazení místností a informaceo vybavení místností např. pro zapisování na zkoušky nebo pro sestavovánírozvrhů.

9.1 Plánovaný projekt 68

• Formáty a sestavy – představují souhrn aplikací umožňujících definovat obecnýformát výstupní sestavy a zobrazovat tuto sestavu s přihlédnutím k právnímusystému, volbě uživatelova formátu, omezujících podmínek a aktuální definicišablon objektů.

• Identifikační průkazy – tato agenda umožňuje evidenci zájmu, výrobu, aktivaci,vydávání a ověřování platnosti mezinárodních studentských a učitelských karetISIC a ITIC a také ostatních zaměstnaneckých a studentských karet používa-ných na naší univerzitě (všechny karty jsou vybaveny bezkontaktním čipem proidentifikační a stravovací systémy).

• Identifikační subsystém – tento systém umožňuje kontrolovat pohyb osob v are-álech omezováním jejich přístupu pomocí turniketů a dveří ovládaných bezkon-taktní identifikační technologií (s využitím karet studentů a zaměstnanců), dáleumožňuje sledovat pomocí videokamery pohyb v různých částech areálů a za-znamenávat změny, informovat vrátnici, dokumentovat průchody osob bezpeč-nostními zónami apod.

• Informace o MZLU – tato část vytváří jednu z dynamických prezentací našíuniverzity, zobrazuje celou řadu informací počínaje informacemi a fotografiemiosob na MZLU, přes pracoviště, telefonní seznam zaměstnanců a místnosti poinformace o studiu (programy, obory, specializaci, předměty, doporučené plányaj.).

• Inventarizace – modul umožňuje zaměstnancům sledovat vybavení jejich míst-ností a zadávat požadavky na přesun a přísun materiálu a vybavení mezi míst-nostmi a převody mezi pracovišťmi; umožňuje také sekretariátům ústavů, ta-jemníkům fakult a kvestorce sledovat a potvrzovat tento pohyb; v konečnémdůsedku pak umožňuje zkrátit dobu nutnou ke každoroční inventarizaci na mi-nimum.

• Katalog předmětů – umožňuje definovat, které předměty jsou v kterém ob-dobí vyučovány, s přihlédnutím k prostupným studijním programům, nutnostievidovat vícejazyčné syllaby předmětů, řadu ukončení předmětů včetně jejichkreditového ohodnocení apod.

• Koleje – modul představuje celou agendu podání žádosti, vyhodnocení žá-dostí, přidělování kolejí, tisk dekretů a sledování využití kolejí (ve spoluprácis Ústřední správou kolejí a menz).

• Nástěnky a dokumentový server – základní modul plně elektronické kanceláře,který zajišťuje předávání informací mezi jednotlivými osobami a pracovišti nanaší univerzitě – ve formě krátkých vzkazů, oznámení a krátkodobých doku-mentů na nástěnkách a ve formě dlouhodobých vyhlášek, zápisů a dokumentův dokumentovém serveru.

• Personalizovaný přístup a designy – modul umožňující naplnění jedné z tech-nických podmínek, tj. zajištění pohodlné práce s informačním systémem – pod-poruje variabilní designy pro různé uživatele, přizpůsobení aplikací a nastavenísystémových politik ovlivňujících chování celého systému,


• Poštovní subsystém – druhý modul plně elektronické kanceláře integrují poš-tovní systém do informačního systému, tzn. je zajištěno doručování pošty všemexistujícím uživatelům – také je řada operací provedených v informačním sys-tému hlášena e-mailem uživateli (udělení známky, vypsání termínu zkoušky,přidání informací na nástěnky apod.).

• Přijímací řízení – umožňuje evidenci uchazečů o studium, průběh jejich přijí-macího řízení a odvolání, vkládání specifických informací o studentovi a jehostudiu a první zápis studentů na naší univerzitě – zajišťuje také prezentaci in-formací o výsledku přijímacích zkoušek – www, elektronická pošta, papírovénástěnky, SMS, W@P a hlasové modemy.

• Registrace – zjišťuje zájem studentů o vypisované předměty a vytváření po-řadí pro předměty s kapacitním omezením (specializované laboratoře), podkladyz registraci určují, které předměty se budou v příslušném období otevírat, a taképředpoklady pro tvorbu rozvrhů – kolize, kapacitní omezení, počty skupin apod.

• Rozvrhy – v první fázi rozvrhy zajišťují vkládání rozvrhových akcí, kontrolukonzistence rozvrhu, zobrazování a tisk rozvrhů dle řady kritérií a rezervacimístností pro (nejen) zkouškové akce, ve druhé fázi bude subsystém podporo-vat tvorbu rozvrhů (průběžná kontrola konzistence, nabídka nezařazených akcí,poloautomatizovaná tvorba rozvrhu aj.).

• Správa počítačů a sítě – modul umožňující sledovat rozložení hadwarovýcha softwarových zdrojů (včetně licencí) mezi pracovníky univerzity, sledující do-stupnost výpočetní techniky i zatížení přenosových linek (infrastruktury v are-álu i meziareálové propojení), dále modul zajišťující jednotné přihlašování k celéuniverzitní síti (předpokládá se autentizace na bázi protokolu LDAP, v staršíčásti univerzitní sítě pak NDS a systém kopírování hesel).

• Stravovací systém – univerzitní informační systém zajišťuje propojení celouni-verzitních agend na nezávislý stravovací systém dodávaný externí firmou (aty-pizovaný hardware), zajišťuje konzistenci uživatelů, identifikačních karet (po-užitých též jako stravovací karty) a napojení úvěru ze stravovacího systémuna mzdový systém v ekonomickém informačním systému (srážka ze mzdy, pří-spěvky odborových organizací apod.).

• Studijní brožury – logickým pokračováním řady studijní a prezentačních apli-kací (Katalog předmětů, Studijní evidence, Informace o MZLU, Formáty a se-stavy) je aplikace umožňující zobrazit a sázet informační brožuru s informacemipro nové i stávající uchazeče a prezentovat tak univerzitu i u široké počítačověneorientované veřejnosti.

• Studijní evidence – jádro studijního systému umožňující evidovat informaceo studentech, sledovat průběh jejich studia v jednotlivých obdobích, evidovatžádosti studentů, vytvářet řadu sestav a studentům prezentovat dosažené vý-sledky jejich studia; tato část je propojena s celostátním systémem Sdruženéinformace matrik studentů (SIMS).


• Telefonní seznam – aplikace tohoto modulu umožňují evidovat přidělená tele-fonní čísla na úrovni jednotlivých ústavů a vytvářet telefonní seznam v elektro-nické i tištěné podobě.

• Tiskový subsystém – tento subsystém zajišťuje sazbu a tisk výstupů ze všechostatních modulů univerzitního informačního systému pomocí sázecího systémuLaTeX; sází se do formátů PostScript a Protable Document Format, příp. jedokument přímo tištěn na síťové tiskárně nebo na tiskárně sdílené v systémuMicrosoft Windows; součástí subsystému jsou i obslužné aplikace pro definovánínových tiskáren, oprávnění k nim a sledování jejich využívání.

• Věda a výzkum – tento modul podporuje druhou oblast činnosti naší unviver-zity – vědeckovýzkumnou činnost; jeho součástí je systém pro evidenci víceja-zyčných strukturovaných životopisů, podaných a řešených grantů a publikacíjednotlivých pracovníků včetně výstupu do celostátní databáze RIV; celý sys-tém je využit jako podklad pro modul Evaluace a data z tohoto systému jsoutéž prezentována mimo univerzitu.

• Vývoj UIS – servisní modul zajišťující řadu informačních a dokumentačních slu-žeb pro vývojový tým informačního systému, např. evidence vyvíjených skriptůa sledování jejich verzí, dokumentace datového schématu, plánování činnosti,systém pro ohlašování nalezených chyb v systému (bugzilla) a časové plányvývoje a stavu jednotlivých komponent.

• Zkušební zprávy – další částí studijního systému je kompletace výsledků jednot-livých předmětů pro potřeby studijních oddělení a vedení fakult a univerzity;učitelé touto aplikací shromažďují výsledky z jednotlivých předmětů, studentijsou informováni o zadaném hodnocení a sami mohou kontrolovat, zda se sho-duje hodnocení v jejich výkazu studia (indexu) a v informačním systému a včassi tak zajistit opravu případných nedostatků; do budoucna je plánováno potvr-zování udělení známky pomocí digitálně podepsaného dopisu.

• Zápis – je sekvence činností, které provádí student a studijní v okamžiku, kdystudent přechází do nového období; dochází zde k potvrzení operací provedenýchv registraci (příp. změně struktury zapisovaných předmětů), kontrole nutně za-pisovaných předmětů (nesplnění požadavků), zapisování do konkrétního cvičenía vytvoření zápisového archu pro studenta i studijní a tvorby rozložení studentůdo skupin pro vyučující.

• Záznamník učitele – tento modul umožňuje vyučujícím evidovat u jednotlivýchstudentů v jednotlivých předmětech řadu údajů, např. docházku, průběžné bo-dování, výsledky písemných prací a testů, témata seminárních prací ve formělistů záznamníku učitele apod.; jednotlivé informace lze také zpřístupnit stu-dentům příp. provést automatickou kalkulaci hodnocení předmětu.

Uvedený seznam není zcela úplný, protože některé rodiny aplikací jsou stále vefázi analýzy a není dosud jasná jejich přesná specifikace.

9.2 Aktuální stav vývoje 71

9.2 Aktuální stav vývoje

V současné době (duben 2002) je kompletně dokončeno jádro Univerzitního infor-mačního systému a moduly Dlouhodobé úkoly, Evidence místností, Formáty a se-stavy, Identifikační průkazy, Identifikační subsystém, Informace o MZLU, Katalogpředmětů, Přijímací řízení, Stravovací systém, Studijní evidence, Tiskový subsystéma Vývoj UIS. Některé moduly ovšem budou v budoucnu přepracovány, protože dosudnejsou implementovány všechny požadavky nebo představy o činnosti příslušnéhomodulu.V nejbližší době budou pak dokončeny moduly Dokumentační systém, Koleje,

Personalizovaný přístup a designy a Poštovní subsystém. V tomto období (letní se-mestr 2002) jsou v plánu též moduly Elektronické přihlašování na zkoušky, Nástěnkya dokumentový server, Registrace, Rozvrhy, Studijní brožury, Telefonní seznam,Zkušební zprávy a Zápis, které jsou již implementovány v původním Fakultníminformačním systému Provozně ekonomické fakulty a nyní čekají na přepracovánído nového systému.Uvedené moduly ze seznamu v předchozí části plánujeme kompletně dokončit

do konce kalendářního roku 2003. Další dva roky práce jsou počítány na zdokonalo-vání systému, implementaci nově vymyšlených modulů a přípravu na analýzu a im-plementaci ekonomického informačního systému (pravděpodobně externí dodávkapřizpůsobená našim potřebám a podmínkám).

9.3 Ukázka podrobné analýzy

V příloze této diplomové práce je podrobně rozebrána analýza jedné části Univer-zitního informačního systému – Studijní agendy. Tato analýza vychází z většinypublikací, které byly publikovány o Informačním systému Masarykovy univerzity(v seznamu literatury autoři Brandejs, Pazdziora, Misáková, Hollanová) a vlastníchzkušeností a myšlenek.

10 ZHODNOCENÍ DOSAVADNÍHO VÝVOJE 72

10 Zhodnocení dosavadního vývoje

Dosavadní zkušenosti z používání předchozího Fakultního informačního systémui nového Univerzitního informačního systému nás přesvědčují, že se univerzita vy-dala dobrou cestu. Studenti již nemusejí navštěvovat školu při triviálních operacích,jako je přihlašování na zkoušky nebo zjištění získané známky. Naopak vyučujícímůže snadno zajistit, že nedochází k podvodům při přihlašování na zkoušky, můžese studenty komunikovat i mimo dobu přednášek a cvičení, předávat jim studijnímateriály apod.Vedení fakulty získalo pravidelný přísun aktuálních informací, ze kterých je pa-

trno, jak se vyvíjí situace jednotlivých studentů, vyučujících a předmětů v průběhuobdobí (roku či semestru), nemusí čekat na sumarizaci dat jednou za čtvrtletí jakov předchozích systémech. Zavádění kreditního studijního systému by bez univerzit-ního informačního systému nebylo možné, protože všichni studenti de facto studujípodle individuálních studijních plánů.Integrování některých celouniverzitních agend, jako je pošta, identifikační prů-

kazy, identifikační a stravovací systém apod. bylo možné jen díky pečlivému vyčiš-tění dat a jejich prezentaci konkrétním uživatelům ve správný okamžik na správnémmístě. Jen tak bylo možné zabránit duplicitám, zbytečnému vyplácení dotací nastravné apod., což v konečném výsledku znamenalo úsporu finančních prostředků.Nejnovější aplikace – Identifikační systémy, Veřejný katalog předmětů, napojení

na stravovací systémy, studijní agenda a čištění dat v systému ukazují, že nasazenísystému je skutečně „univerzitníÿ, protože systém pokrývá většinu celouniverzitníchagend. Neřeší dosud pouze problematiku ekonomického systému, který je ponechá-ván stranou.Vedení univerzity je s průběhem vývoje velmi spokojeno a poskytuje vývojo-

vému týmu rozsáhlou podporu v jejich snahách o rozvoj a zdokonalování UIS. Prototaké podporuje cestu vedení vývojového týmu na konferenci EUNIS 2002 do Portaa účast UIS v soutěži EUNIS Elite Award for Excellence v letošním roce.

10.1 Směry dalšího vývoje

Potenciální vývojovou oblastí mimo výše uvedené rodiny aplikací je integrace dal-ších užívaných celouniverzitních agend (stavební odbor, personální, ekonomický, fi-nanční a mzdový systém, systémy pro oběh dokumentů) a zavádění nových techno-logií (správa prostředků výpočetní techniky skrz informační systém, jako je např.jednotná správa oprávnění k tiskárnám, sdíleným diskovým kapacitám a nestan-dardním síťovým zařízením, systémy distanční podpory vzdělávání aj.).Hlavní důraz však v nejbližší době klademe na odstranění případných chyb

v systému a zpracovávání požadavků našich uživatelů, protože systém vytvářímepředevším pro ně. Další oblastí naší činnosti je další automatizace agend předevšímstudijního oddělení, kde je soustředěna v některých částech roku velká manuálnípráce (zpracování přihlášek uchazečů, potvrzování a kontrola dat, sestavování dopisů

10.2 Přínos UIS pro IS/ICT 73

a reklamních materiálů, hlavičkové dopisy, podpora nestandardních žádostí, oběhdokumentů). Tuto agendu lze jistě automatizovat.Původní Fakultní informační systém Provozně ekonomické fakulty nebyl přeno-

sitelný ani do vícefakultního provozu, ani na jinou instituci. Proto i jedním z před-pokladů při návrhu nového systému bylo vytvoření takového datového a funkčníhomodelu, aby bylo možné systém přenášet do prakticky libovolného provozu. Tentonávrh nebyl zcela dodržen na implementační úrovni (řada nápovědných textů mluvívýslovně o Mendelově zemědělské a lesnické univerzitě v Brně), ale jedním z po-žadavků v nejbližší době bude úprava na plně přenositelný systém (parametrizace,víceorganizační provoz, jazykové mutace systému).Náš systém samozřejmě neimplementuje zcela obecný studijní systém libovolné

země, ale prakticky libovolný studijní a zkušební řád používající kreditní systéma rozdělující studium na období, ve kterých jsou studovány programy a případněobory a specializace (zaměření), je aplikovatelný. Obecná struktura šablon a formátůpak umožňuje snadno na uživatelské úrovni dodefinovat široké spektrum evidova-ných údajů pro jednotlivé agendy.V nejbližší době neplánujeme žádnou implementaci systému na jiné vysoké

škole, protože je systém stále ve vývoji. Přesto jsme již prováděli konzultace sedvěma dalšími českými vysokými školami, které o systém příp. o metodiku vývojea vývojářské nástroje (tj. jádro našeho systému) projevily zájem. Můžeme tak nášsystém řadit na pomyslené třetí místo v naší republice (za Informační systém Ma-sarykovy univerzity a Studijní agendu Západočeské univerzity) z hlediska zájmuo tento systém.

10.2 Přínos UIS pro IS/ICT

Vytvoření teorie webových informačních systémů umožnilo razantním způsobemzvýšit produktivitu při tvorbě Univerzitního informačního systému. Vývojový týmse zabývá skutečně inovativními úkoly a rozšiřuje funkčnost systému pomocí smyslu-plných modulů bez nutnosti zabývat se rozsáhlým rozšiřováním stávajících modulůči drobnými změnami. Především systém práv, šablonování, sestav a formátů umož-ňuje ze strany oprávněných uživatelů (např. systémových integrátorů) ovlivňovatchování systémů pro jejich subjekty (pracoviště). Vývojový tým nemusí do tohotoprocesu zasahovat.Celý systém je postaven modulárně a využívá mnoho předpřipravených kompo-

nent pro realizaci typických problémů - užití právního systému, šablon, formátů, vý-běrů, formulářů – vše maximálně jednoduše, se stejným chováním ve všech aplikacích(což napomáhá uživatelům jednoduše užívat nové funkce v informačním systému).Velmi se osvědčil způsob projektového řízení vývoje – vedoucí vývoje rozčleňuje

průběžně vývojový tým do řady sekcí, které jsou odpovědné za vývoj konkrétníchmodulů (dlouhodobé projekty), přičemž vývojové sekce spolupracují se specializova-nými sekcemi datamanagementu, provozu či podpory uživatelů. Každá sekce je takodpovědná za analýzu, vývoj, odzkoušení a uvedení do praxe konkrétní nové části

10.3 Poznatky a zkušenosti z provozu, zpětná vazba 74

informačního systému. Uvnitř sekcí se užívá kombinovaného přístupu – spoluprácemezi členy sekce na vývoji jedné části modulu nebo opět projektové řízení na nižšíúrovni.Vývojový tým ověřil, že je bez větších obtíží možné paralelně provozovat vývoj

i provoz systému. Denně dochází k desítkám aktualizací provozního systému z vývo-jové oblasti pomocí speciálního software, který automaticky dokumentuje provedenézměny, kontroluje konzistenci a základní funkčnost systému a pomocí kterého jed-notliví vedoucí sekcí, vedoucí realizace a vedoucí vývoje mohou postupně kontrolovatvývoj systému.Samodokumentující funkce informačního systému umožňují průběžně udržovat

informace o dokumentaci a stavu systému (databázové komentáře, komentáře změnpři vývoji modulů, dokumentační texty). Na přání je pak možné z těchto fragmentůsestavit kompletní vývojářskou dokumentaci systému.Osvědčila se myšlenka evidence úkolů ve společném manažeru úkolů – TODO

bloku. Jednotliví vedoucí tak mohou průběžně sledovat vytížení jednotlivých pracov-níků, postup práce na dílčích projektech, pracnost projektu, stav projektu, určovatpriority či sledovat problémy při vývoji vznikající. Lze tímto způsobem masivně pra-covat na 200 paralelních projektech při 20 pracovnících. Řada projektů je totiž vestádiích analýzy příp. testování – TODO blok umožňuje neztratit informace o stavužádného projektu a včas uvést kadý týden několik nových funkcí, které rozšiřujíkvalitu systému a přitom u uživatelů navozují pocit průběžně vyvíjeného systému.Pro vývoj bylo nutné vytvořit několik individuálních nástrojů pokrývající ne-

dostatky užívaného software (především RDBMS Oracle) – jedná se o databázovoukonzoli dbMan (volně dostupná na Internetu), dokumentační nástroj SchemaViewPlus (dostupný na síti CPAN), zálohovací software a fulltext indexační engine Su-perIndex.

10.3 Poznatky a zkušenosti z provozu, zpětná vazba

Vývojový tým průběžně zjišťuje odezvu na zavádění nových funkcí u uživatelů sys-tému. Zpracoval jednoduchý dotazník, ve kterém se mohl anonymně vyjádřit libo-volný uživatel FIS. Této možnosti využilo přibližně 100 uživatelů a přibližně 70%uživatelů bylo se systémem velmi spokojeno. Dalších 20% vytýkalo systému vý-znamné nedostatky a pouze necelých 10% bylo se systémem velmi nespokojeno.Nejdůležitější moment provozu představovalo zřízení systémových integrátorů

řešících problémy jednotlivých fakult a vytvoření stromové struktury pracovníkůpodpory na ústavech na těchto fakultách. Tím vývojový tým jedná jen z úzkoumnožinou osob (méně než deset osob) a dostává podklady v předzpracované vy-tříděné podobě rozčleněné podle priorit. Řada rutinních úkolů se tak přesouvá najednotlivé integrátory.Nutným krokem pro provoz systému je evidence podrobných logů o operacích

jednotlivých uživatelů (včetně dlouhodobé historie), evidence přístupů a změn data možnost delegovat oprávnění uživatelů na další uživatele v rámci jejich pole pů-

10.3 Poznatky a zkušenosti z provozu, zpětná vazba 75

sobnosti (integrátor deleguje studijní pravomoce na vedoucího studijního oddělenía ta jej dále deleguje na studijní referentky.Speciální funkce umožňující zobrazit si systém z pohledu jednotlivých uživatelů

(samozřejmě v kontextu s právním systémem, tj. integrátor pouze pro svou fakultu,vývojáři všude) zajišťuje pružné řešení problémů vznikajících s provozem systému.Řada zaměstnanců není dosud schopna plně užívat počítač – proto existuje

funkce delegátů umožňující předat část svých pravomocí na sekretariáty ústavů čidoktorandy. Tato metoda není příliš podporována, ale je možná pro řešení akutníchproblémů počítačové indispozice (neschopnosti užít jej k přípravě nutných dat).

11 ZÁVĚR 76

11 Závěr

Při vývoji Univerzitního informačního systému na MZLU došlo k vytvoření velmiprogresivní technologie pojmenované teorie webových informačních systémů. Tatotechnika v kombinaci s rozsáhlými zkušenostmi vývojářů systému umožnila vytvořitinformační systém pokrývající potřeby univerzity ve studijní a vědeckovýzkumnéoblasti a zajistit průběžný vývoj vytvářející průměrně tři nové moduly měsíčně(deset rodin aplikací, desítky aplikačních balíků).Nový Univerzitní informační systém nastartoval na MZLU řadu jednání o pře-

hodnocení postojů k automatizaci celouniverzitních agend a umožnil jednání o ino-vaci takových složek, jako je systém přidělování místností, inventarizace u koncovýchuživatelů, strhávání finančních částek za stravování ze mzdy či sdělování výsledkupřijímacího řízení pomocí hlasových služeb informačního systému.Vývojový tým při vývoji načerpal dostatek nových zkušeností umožňující v bu-

doucnu integrovat do UIS ekonomický systém, vytvořit systém podpory distančníhovzdělávání budovaný naší univerzitou ve spolupráci s VUT Brno a UTB Zlín či za-vést systém jednotné autentifikace uživatelů v síti MZLU k počítačům nebo sjednotitpočtovní systém na centralizovaný systém se zajištěnou doručitelností pošty.V průběhu čtyř let vývoje systému byly splněny vytčené cíle a projekt je úspěšně

na univerzitě provozován. Podařilo se dosáhnout uznání jak u běžných uživatelů,tak u vedení univerzity. Vývojový tým načerpal rozsáhlé množství zkušeností, kterépozději zužitkuje v praxi.Autor práce získal zkušenosti nejen s analýzou, návrhem a vlastním vývojem

a zaváděním do provozu u velkého informačního systému, ale především také zku-šenosti související s přípravou komplexního projektu a nenahraditelné zkušenosti sestrategickým, taktickým, operativním i krizovým řízením vlastního projektu. Z to-hoto pohledu se uplynulé čtyři roky i tato práce jeví jako velmi úspěšné.Autor bude dále pokračovat v rozebírané problematice na pozici vedoucího

vývoje Univerzitního informačního systému a zároveň se bude věnovat doktorskémustudiu na téma Webové informační systémy. Tato teorie vznikla spontáně na základěprávě budovaných informačních systémů nejen ve vysokém školství.

12 LITERATURA 77

12 Literatura

[1] Brandejs, M. – Hollanová, I. – Misáková, M. – Pazdziora, J. Uni-verzitní IS: předsudky, pověry a realita. In RUFIS 2000. Brno: VUT, 2000.http://is.muni.cz/clanky/rufis2000.pl.

[2] Brandejs, M. Nové možnosti komunikace v IS MU. In Zpravodaj ÚVT. Brno:MU, 2001. http://is.muni.cz/clanky/komunikace-zpravodaj.pl.

[3] Brandejs, M. Informační systém Masarykovy univerzity v roce 2000. Výročnízpráva o provozu a vývoji. Brno: FI MU, 2001.http://is.muni.cz/clanky/vyrocka2000.pl.

[4] Brandejs, M. Informační systém Masarykovy univerzity v roce 1999. Výročnízpráva o provozu a vývoji. Brno: FI MU, 2000.http://is.muni.cz/clanky/vyrocka1999.pl.

[5] Brandejs, M. – Hollanová, I. – Misáková, M. – Pazdziora, J. Admi-nistrative Systems for Universities Should Be More Than Just a Spreadsheet.In EUNIS 2001. Berlin: EUNIS, 2001.http://is.muni.cz/clanky/eunis2001-university.pl.

[6] Brandejs, M. – Hollanová, I. – Misáková, M. – Pazdziora, J. In-houseDeveloped UIS for Traditional University: Recommendations and Warnings.In EUNIS 2001. Berlin: EUNIS, 2001.http://is.muni.cz/clanky/eunis2001-casestudy.pl.

[7] Brandejs, M. – Hollanová, I. – Misáková, M. – Pazdziora, J. IS prouniverzitu ve třetím tisíciletí. In UNINFOS 2000. Nitra: UNINFOS, 2000.http://is.muni.cz/clanky/uninfos2002.pl.

[8] Brandejs, M. Úplná elektronizace studijních agend vysoké školy. In RUFIS1999. Brno: VUT, 1999. http://is.muni.cz/clanky/rufis-brandejs.pl.

[9] Čermák, J. a kol. Universum 1–10. Praha: Odeon a Knižní klub, 2000–2001.7 200 s. ISBN 80-207-1060-4.

[10] Černá, H. Návrh implementace síťového výukového systému. Brno: MZLU,1999. 83 s. Diplomová práce.

[11] Dařena, F. Jádro Univerzitního informačního systému. Brno: MZLU, 2002.60 s. Diplomová práce. In press.

[12] Dohnal, J. – Pour, J. Architektury informačních systémů v průmyslovýcha obchodních podnicích. Praha: Ekopress, 1997. 301 s. ISBN 80-86119-02-5.

[13] Hollanová, I. – Misáková, M. Katalog předmětů: několik zkušeností s elek-tronickou podporou ECTS. In RUFIS 1999. Brno: VUT, 1999.http://is.muni.cz/clanky/rufis-hollanova-pics.pl.

[14] Kokeš, J. Standardy státního informačního systému České republiky. Praha:Úřad pro státní informační systém, 1998. 258 s.

[15] Misáková, M. Principy administrativního serveru informačního systému MU.In Zpravodaj ÚVT 1/98 Informační systém MU další generace. Brno: MU,1998. http://is.muni.cz/clanky/principy-zpravodaj.pl.

12 LITERATURA 78

[16] Molnár, Z. Efektivnost informačních systémů. Praha: Grada, 2000. 142 s.ISBN 80-7169-410-X.

[17] Motyčka, A. Architektura, součásti a vývoj podnikových informačních sys-témů s ohledem na současný stav a trendy v informačních technologiích. Brno:MZLU, 1995. 190 s. Habilitační spis.

[18] Pazdziora, J. Dokumentový server IS MU. In RUFIS 2000. Brno: VUT, 2000.http://www.fi.muni.cz/~adelton/papers/rufis00.html.

[19] Pazdziora, J. – Brandejs, M. University Information System Fully Basedon WWW. In ICEIS 2000. Stafford: ICEIS, 2000.http://www.fi.muni.cz/~adelton/papers/www-uni-is.html.

[20] Pazdziora, J. Autentizovaný přístup a systém práv v IS MU. In RUFIS 1999.Brno: VUT, 1999.http://www.fi.muni.cz/~adelton/papers/rufis99.html.

[21] Pecinovský, R. – Virius, M. Objektové programování I. Praha: Grada Pu-blishing, 1996. 260 s. ISBN 80-8169-436-2.

[22] Pecinovský, R. – Virius, M. Objektové programování II. Praha: Grada Pu-blishing, 1996. 264 s. ISBN 80-8169-436-3.

[23] Riordan, R. M. Vytváříme relační databázové aplikace. Praha: ComputerPress, 2000. 280 s. ISBN 80-7226-360-9.

[24] Rybička, J. Informační systémy ve výuce. In Informační systémy a jejichaplikace. Brno, 1994.

[25] Rybička, J. Konstrukce testů ve výukových informačních systémech. In In-formační systémy a jejich aplikace. Brno, 1995.

[26] Rybička, J. Problémy implementace výukových informačních systémů. In In-formační systémy a jejich aplikace. Brno, 1997.

[27] Šorm, M. a kol. Fakultní informační systém. In Studnice VII. Brno: Konvoj,2001. s. 50-113. ISBN 80-7302-011-4.

[28] Šorm, M. Nový pohled na návrh webových informačních systémů. In Firmaa konkurenční prostředí 2002. Brno: Konvoj, 2002. 6 s. In press.

[29] Šorm, M. Postup práce na fakultním a univerzitním informačním systému. InStudnice IX. Brno: Konvoj, 2002. In press.

[30] Šorm, M. – Dařena, F. University information system at Brno Mendel Uni-versity of Agriculture and Forestry. Brno: MZLU, 2002. Submission to EUNISElite Award of Excellence. http://is.mendelu.cz/dok/eunis2002.pdf.

[31] Voříšek, J. Informační technologie a systémová integrace. Praha: VŠE, 1996.198 s. ISBN 80-7079-895-5.

[32] Vrána, I. – Búřil, J. – Černý, A. Methods for Building a University In-formation System. Edited by EUNIS. Brno: VUT, 2001. 158 s. A Handbook.ISBN 80-214-1837-0.

Přílohy

A UKÁZKA ANALÝZY STUDIJNÍ AGENDY 80

A Ukázka analýzy Studijní agendy

V této části jsem připravil ukázku z analýzy jedné ze stěžejních částí Univerzitníhoinformačního systému. Uvedená analýza je základní analýzou tohoto modulu, kterábyla později doplňována a pozměňována. Všechny analýzy vytvářené v našem sys-tému jsou tvořeny z pohledu autora analýzy. Uvedená analýza byla též součástí [27]a je pro účely této diplomové práce mírně upravena.

Motivace

Studijní subsystém je bezesporu základní funkcí v libovolném informačním systémuurčeném pro libovolné školství.V analýze problematiky a v návrhu jsem vycházel především ze současného

stavu a předchozího informačního systému STUDENT, protože nový systém musítento předcházející v plné míře nahradit (a tedy nesmí zanedbat žádnou podstatnoufunkci systému původního), dále pak z nové úpravy Studijního a zkušebního řádu,který je přijat na univerzitní úrovni, a také i z existujícího studijního subsystémuuniverzitního informačního systému Masarykovy univerzity, na jehož vývoji jsemměl možnost se podílet.Při analýze jsem přihlížel rovněž k tomu, že jsem reprezentantem největší sku-

piny uživatelů – studentů – a při své každodenní práci mohu naslouchat problémůmdalších velkých skupin uživatelů – učitelů a studijního oddělení. Návrh se snaží zjed-nodušit práci všem těmto skupinám uživatelů, i když jejich požadavky jsou častoprotichůdné.Můj původní návrh, který jsem vypracoval v roce 1999, vycházel z koncepce

aktivního a neaktivního Katalogu předmětů, kde jsou uchovávána data vždy s pří-znakem aktuálnosti. Toto zjednodušení mělo svůj význam v době překotného rozvojena začátku vývoje informačního systému, kdy bylo nutno co nejrychleji vytvořit pro-vozuschopné jádro s některými výstupy vhodnými pro prezentace.Bohužel (či naopak bohudík) pro reálný provoz systému je třeba rozlišovat mno-

hem více charakteristik než aktuálnost. Z časového hlediska je třeba rozlišovat časovéobdobí, ve kterém k události došlo (archiv známek, zápisy apod.). Koncepce obdobíbyla detailně rozpracována v univerzitním systému Masarykovy univerzity. Při stu-diu této koncepce jsem v době návrhu Fakultního informačního systému dospěl k ná-zoru, že rozlišovat období i například u sylabů předmětů je z hlediska naší univerzityprakticky neupotřebitelné (vzhledem k množství uchovávaných dat a jejich relativněmalým změnám mezi jednotlivými obdobími). V Univerzitním informačním systémuje již koncepce období pojata plně a důsledně ve všech aplikacích včetně Katalogupředmětů a syllabů těchto předmětů.V následujícím textu se nejprve pokusím nastínit základní myšlenku koncepce

období, potom důkladně rozeberu jedno období na jednotlivé akce a na závěr na-značím možnosti, které systém přinese jednotlivým skupinám uživatelů.


Koncepce období

Veškerou dobu existence systému lze rozdělit na řadu i nestejně dlouhých období. Jeteoreticky jedno, zda jako období bereme dnešní etapu, semestr či akademický rok.Osobně se přikláním k jakémusi hybridnímu období mezi semestrem a akademickýmrokem – tj. ke dvěma nesouměrným semestrům tvořícím jeden rok. Jeden semestrje obohacen o řadu atypických akcí, jako je přijímání ke studiu, úprava Katalogu čistipendia a přidělování kolejí, druhý semestr je naopak bohatší o zkušební zprávya uzavírání ročníků spojené s postupy. Ideální souměrnosti obou částí (hlavně díkykolejím a přijímacímu řízení) zřejmě nikdy nedosáhneme.Začátek období se většinou neshoduje se skutečným začátkem vyučování v da-

ném období, ale předchází mu určitá doba nazývaná předobdobí, analogicky na konciobdobí (tzv. poobdobí, které je mnohem kratší než předobdobí). V předobdobí do-chází například k již zmíněnému přijímání do studia, v poobdobí naopak k postupůmstudentů do vyšších ročníků. Začátek i konec období zahajuje a stanovuje příslušnákompetentní osoba, nejčastěji studijní proděkan.Zahájení období je provázeno zkopírováním veškerých údajů o období z před-

cházejícího či některého jiného zvoleného období, čímž se zajistí stejné výchozí pod-mínky pro nové období, jaké byly konečné podmínky období předchozího. Následněse v předobdobí modifikují tyto podmínky, čímž vzniká originální období, ve kte-rém dochází ke studiu studentů. Po ukončení a uzavření období by se již nemělodata modifikovat. Konec předchozího období nemusí a ani nebývá nutně začátkemnového období. Obvyklá situace je ta, že nové období začíná mnohem dříve, nežpředchozí končí (tj. předobdobí probíhá současně s předchozím obdobím). Opačnásituace může nastat rovněž, ale nejedná se o častý případ (nucené vynechání prvníhoročníku vlivem změn z Ministertva školství, mládeže a tělovýchovy by mohlo býtjedním z důvodů).

Katalog předmětů

Katalog obsahuje veškeré předměty, které se na fakultě či potažmo univerzitě někdyvyučovaly (včetně aktuálně vyučovaných předmětů). Data v Katalogu předmětů jsouuchovávana s ohledem na příslušné období. Rozlišujeme přitom období veřejná a ne-veřejná, kdy neveřejné období (sklady) používáme pro přípravu předmětů a veřejnáobdobí pro prezentaci. Mezi obdobími lze předměty kopírovat.V Katalogu jsou kromě základních údajů (název, zkratka apod.) udržovány

i údaje o garantovi předmětu, což je osoba pověřená vedením fakulty (či příslušnéhoorgánu stanoveného Statutem) zajišťovat výuku a hodnocení předmětu.Garant má možnost podrobně udržovat strukturovanou formou sylaby ke svým

předmětům. Samozřejmostí jsou vícejazyčné syllaby o předem dané struktuře. V sou-časné době patří do struktury závislosti, cíl předmětu, obsah včetně hodinové dotace,metody výuky, ukončení předmětu a doporučená literatura.Garant dále může specifikovat učitele, kteří se předmětu věnují z hlediska ně-

kolika rolí – přednášející, cvičící, zkoušející (role lze opět kumulovat). V případě, že


garant propojí učitele na příslušnou rozvrhovou akci v rozvrhu svého předmětu, do-stávají studenti možnost sledovat, kdo a kdy příslušný předmět přednáší nebo cvičí.Toto rozdělení hraje důležitou úlohu ve využívání základní aplikace pro učitele –Záznamníku učitele (viz dále).Každý předmět má rovněž definovánu řadu ukončení, která mohou být různě

kreditově ohodnocena. Údaje o předmětu je možné udržovat pomocí šablony, údajeo syllabech pomocí mutované šablony přes jazyky a údaje o kreditovém hodnoceníukončení pomocí mutované šablony přes jednotlivé typy ukončení.

Strom závislostí

S Katalogem předmětů velice úzce souvisí Strom závislostí. Řada předmětů je totižzávislá na jiných předmětech či skutečnostech, tzv. prerekvizitách. Např. Statistika IIvyžaduje studium Statistiky I. Ale i Statistika I vyžaduje například Matematiku,čímž se vytváří celá řada vazeb mezi jednotlivými předměty, která, pokud je zakres-lena, vytváří pomyslný strom závislostí.Závislosti však nemusí být pouze takto jednoduché. Může vzniknout i požadavek

vzájemné neslučitelnosti předmětů, např. osoba, která vystudovala Počítačové sítěurčené pro obor EI již nemá mít možnost zapsat si volitelný předmět Počítačové sítěa komunikace pro studenty z oboru ME a naopak. Řada předmětů vyžaduje studiumna určitém stupni studia, např. Diplomovou práci lze zapsat až na inženýrském(magisterském) stupni. Tento problém lze elegantně vyřešit uvedením závislostí napředmětech typu Bakalářská, Souborná či Postupová zkouška. To ovšem přináší dalšívztah – předcházet musí to a nebo ono (a dokonce výlučně – to, nebo ono, ne všakoboje), což ovšem samozřejmě dostaneme tranzitivitou z podmínky neslučitelnostidvou předmětů.Pro korektní průchod studiem je také třeba určit, že příslušný předmět je po-

vinný pro Státní zkoušku – zde lze zavést prerekvizitu Státní zkoušky z danéhookruhu (informatiky) na Státní zkoušce jako takové a navíc závislost Státní zkouškypříslušného okruhu na tomto předmětu.Je jisté, že takový strom závislostí není jednoduché sestavit a že je nutná spo-

lupráce všech garantů. Vznikají dokonce vzájemně se vylučující situace (podmínky)a kruhové podmínky (můj předmět je závislý na předmětu X a předmět X závisína mém předmětu, což lze řešit dohodou nebo zápisem ve stejném období). V sou-časné době se zabýváme vytvořením právě tohoto stromu. Celá problematika jeještě o něco složitější zavedením vazeb „a současně se studujeÿ, negací či snahouo konkrétní určení, kdy má být předmět studován (např. ne v prvním ročníku, tedyzávislost některého úvodního předmětu na tomto předmětu apod.).Vedlejším efektem kvalitního Stromu závislostí je potom možnost nabízet před-

měty ke studiu mezi fakultami (tzv. vyvážení předmětů mimo fakultu), protože prozapsání řady předmětů je stanovena řada prerekvizit a tak student jiné fakulty musíabsolvovat celou linii předcházejících předmětů, a není tedy nutné klesnout s kvali-


tou výuky díky slabším vědomostem některých studentů. To je i jeden z cílů novéhoStudijního a zkušebního řádu, ze kterého tato studie vychází.

Standardní průchod studiem

Nový Studijní a zkušební řád se snaží zavést plně kreditní studium podle standarduECTS, což je situace, kdy si student volí průchod studiem sám (analogie individu-álních studijních plánů) v závislosti na tom, kolik má k dispozici kreditů pro nákuppředmětů v daném období a na Stromu závislostí předmětů, čímž se mu určitýmzpůsobem koriguje průběh studia.Řada studentů ovšem svůj průchod studiem nedokáže a ani nechce ovlivňovat.

Proto je třeba zavést doporučený či standardní průchod studiem, kde je stanoveno,jak student má postupovat studiem, aby za standardní délku studia dospěl k cíli.A pokud student v tzv. registraci, o které bude řeč později, neprovede volbu vlast-ního studijního plánu pro další období, je mu provedena registrace předmětů podlestandardního průchodu.Tento standardní průchod má pro studenty jen jednu nevýhodu – automatická

registrace se provádí až na závěr té části období, ve které probíhá registrace, protouž mohou být některé skupiny ve výhodné časové termíny zaplněny. Místo pro stan-dardní průchod je vždy zajištěno – není tedy nutné se o nic starat, student všaknedostane žádnou jinou výhodu.

Klasické období

Klasické období začíná (jak již bylo uvedeno) otevřením období. Následují příslušnéúpravy Katalogu předmětů, Stromu závislostí a Standardního průchodu studia. Sou-běžně s tímto procesem (v předobdobí) dochází k přijímání nových studentů, v prvnífázi tedy k zadávání uchazečů o studium, dále k přijímacímu řízení a pak k vlast-nímu zápisu přijatých uchazečů a k imatrikulacím. To vše provází značná agendas návazností na koleje a menzy apod.V závěru předchozího období nastává čas na provedení registrace – zjištění

zájmu studentů o předměty. Poté se sestaví rozvrh a nastane období zápisu, kdysi studenti mohou zapsat libovolné předměty (přičemž preference zájmu jsou brányz registrace) a rozdělení se do skupin podle vlastního zájmu. Na základě těchtoúdajů (tzv. předzápisového kola) se na studijním oddělení provádí dvoukolový zápis(zápis a kontrola) a stanoví definitivní zařazení do skupin, upraví rozvrh a rozdělído učeben. Garanti předmětů nejpozději v tomto okamžiku určují, který přednáše-jící/cvičící bude přednášet/cvičit kterou rozvrhovou akci.Začíná vlastní období, v jehož průběhu jsou využívány možnosti Záznamníku

učitele a navazujících aplikací pro studenty. V jeho závěru začíná zkouškové, kdy sezúročí práce se Záznamníkem učitele a ke slovu přicházejí aplikace typu Zapisovánína zkoušky a Zkušební zprávy. Studentům se nabídne Anketa a vlastní období končíuzavřením Zkušebních zpráv. Nyní mohou být údaje přeneseny do již započatéhoobdobí. Navíc lze systém doplnit o řadu dalších aplikací, např. Stipendia provázející


zápisy nebo naopak udělovaná po uzavření Zkušebních zpráv, evidence celé řadyžádostí, evidence neschopenek apod.Vzhledem k otevřenosti koncepce lze do období zařadit další množství aplikací

– Tisk brožurek, Elektronické indexy včetně digitálního podepisování známek, vy-vážení předmětů mezi fakulty aj. Zde se již dostáváme na pomezí propojení obdobíi do jiných částí UIS, zejména na Vědu a výzkum nebo Dokumentový server (nynínazýván Nástěnky).Rozeberme si nyní jednotlivé etapy klasického období podrobněji, včetně užití

příslušných aplikací a nastínění jejich možností dalšího využití.

Přijímací řízení

Přijímací řízení se celé odehrává v odlišných databázích, aby nedošlo k propojenídat se stávajícím systémem před definitivním přijetím nových studentů do akade-mické obce. Vše začíná evidencí přihlášek ke studiu v databázi uchazečů. Po uza-vření přijímání přihlášek se sestaví výstup pro matriku studentů a nad databází lzeprovozovat nutné agendy související s přijímacím řízením (rozesílání dopisů a infor-mací, přehledy, vlastní tvorba přijímacího řízení, odhad potřebných míst na kolejíchapod.).Po přijímacích zkouškách je databáze uchazečů doplněna o jejich výsledky a je

automaticky vybrána skupina určená k postupu dál (zde je možné napojit aplikacipro prezentaci výsledků přijímacího řízení). Tato situace se může opakovat několi-kakolově. Konečnou fází je vybrání skupiny přijatých studentů a provedení potřebnéagendy – rozesílání dopisů, zápis a rozdělení do skupin, tisk imatrikulačích listů,potvrzení o studiu aj.Navazovat mohou agendy pro koleje a menzy, určení potřebných stipendií pro

mimořádné situace aj. Na konci přijímacího řízení se data převedou do ostré da-tabáze, vygenerují se hesla pro přístup do systému a provedou nutné systémovéagendy (napojení na systém správy účtů na jednotlivých serverech a stanicích, tiskprvotních údajů – přihlašovací kartičky, brožurky pro seznámení se se systémem).

Registrace a předzápis

V současném systému STUDENT je tato pasáž nahrazena automatickou formouregistrace podle předem daných šablon standardního průchodu studiem. V novémsystému UIS (stejně jako ve stávajícím FIS) bude k dispozici nástroj, pomocí kteréhosi student může stanovit, o jaké předměty má v novém období zájem s přihlédnutímke Stromu závislostí a případně k Vyváženým předmětům mimo fakultu (tj. lze sizapsat i předměty z jiných fakult, příp. škol). Systém se musí postarat o povinnépředměty, povinná opakování apod.Výsledkem této pasáže je kompletně předpřipravený zápis pro studijní oddě-

lení, tj. studentům, kteří neprovedou žádnou registraci jsou zapsány předměty zeStandardního průchodu studiem. Na základě údajů z registrace může být sestaven


rozvrh. Druhou fází registrace je tzv. předzápis, který tento rozvrh potřebuje prosvé provedení.Do předzápisu postupují studenti již podle výsledků dosažených na základě za-

daných Zkušebních zpráv z předchozího období (tedy až těsně před samým začátkemnového období, po skončení předobdobí). Zredukovaná množina studentů si zapisujepředměty zvolené v registraci (příp. i jiné, pokud jsou volné kapacity a bude totodovoleno novým Studijním a zkušebním řádem) a určuje si, do kterých skupin chcepatřit v daném předmětu, což umožňuje plynulejší a variabilnější rozvrh závisejícípouze na aktivitě studentů.Studentům, kteří se předzápisu nezúčastní, se do předzápisu přenesou všechna

data z registrace (tedy potenciálně i standardní průchod studiem), a protože provšechna místa z registrace je vyhrazeno místo v předzápise, přidělí se jim volnámísta ve skupinách. Tento proces probíhá až na konci předzápisu. Vzhledem k velmisložité algoritmické situaci nelze při automatickém doplňování skupin brát v potazkřížení rozvrhových akcí apod. Studenti by se tedy ve vlastním zájmu měli účastnitregistrace a především předzápisu.Přechodem na kreditní systém tak odpadá složité přerozdělování do skupin, kří-

žení předmětů, volba volitelných předmětů a poměrně nenásilnou cestou je umož-něn individuální profil studia. Většina úkonů je dobrovolná, avšak jejich neprove-dení může studentovi poměrně zkomplikovat studium (např. nemusí mít tzv. slušnýrozvrh apod.). Naopak by se měla zmírnit tendence studentů kritizovat napříkladrozvrhy, protože si sami mohou tímto způsobem rozvrh ve velké míře ovlivnit a jsoutedy jeho spolutvůrci.Po začátku vlastního období studenti mohou provádět změny ve svém zápisu

(de facto vytvářet návrh pro nový zápis), jak to umožňuje přijímaný Studijní a zku-šební řád. Student ovšem veškerý svůj připravený návrh musí potvrdit na studijnímoddělení, které mu změnu může zakázat (např. z toho důvodu, že by jeho zrušenípředmětu snížilo počet zapsaných osob do předmětu pod hranici stanovenou vede-ním fakulty apod.).

Rozvrhy

Za zamyšlení stojí i samotná problematika rozvrhů. Po mnohých debatách jsmedospěli k názoru, že počítačem sestavený rozvrh nemůže splňovat kritérium optima-lity, protože toto kritérium nelze přesně vyslovit (každý rozvrh totiž obsahuje něcove smyslu části osobnosti svého tvůrce, protože odráží určité těžko formulovatelnépodmínky). Problém rozvrhů je tedy jen velice těžko algoritmizovatelný.Ovšem pro zobrazení rozvrhů je vhodné užít počítače a především informačního

systému. Otázka přenosu rozvrhů do informačního systému formou zadání rozvrho-vých akcí zůstává otevřena. Vlastním opisem se zanáší řada chyb a nepřesností,nehledě k velké pracnosti a ztrátě času.Bylo by proto vhodné najít pro přenos ručně sestaveného rozvrhu do automa-

ticky zpracovatelné podoby lepší způsob. Nabízí se několik řešení – provádět sesta-


vení ručním způsobem, ovšem v automatizované počítačové podobě. Bohužel veli-kost současných obrazovek v nižších cenových relacích nepřesahuje výrazně dvacetpalců, což je pro zobrazení rozvrhu v přehledné podobě málo. Velkoplošné obrazovkys úhlopříčkou několik desítek palců jsou zase k tomuto jednoúčelovému řešení přílišdrahé.Další variantou je zobrazování promítáním na zeď či plátno – zde ovšem pře-

cházející postava rozvrháře vrhá na zeď stín, který komplikuje proces zobrazování.Umístění projektoru mimo centrální pozici zase deformuje zobrazovanou plochu dokónického tvaru, což vede k matoucímu dojmu při práci s časovou linií dne.Dalším nápadem je využití brýlí na virtuální realitu, resp. spíše jen brýlí na

pozměnění reality. Tyto brýle zobrazují realitu dokreslenou počítačem, což znamená,že nyní užívané tabule s rozvrhy by se zobrazovaly pouze virtuálně (ve skutečnostiby neexistovaly) a data by byla uložena v počítači. I toto řešení nese řadu nevýhod– od technického problému s kabeláží (řešení by bylo použít přenos infračervenýmzářením nebo bezdrátovým přenosem) po psychický odpor – pohybovat se v prázdnémístnosti podél zdi by v případě vyrušení náhodným příchozím bez brýlí mohlopůsobit zavádějícím dojmem.Otázka není vyřešena, ovšem pro úsporu času je toto řešení třeba nalézt. Vlastní

technika návrhu je potom možná pomocí například 3D myši, tzv. „netopýraÿ. Tatopomůcka umožňuje manipulovat s předměty v prostoru. Dalším krokem by pakmohla být senzorická rukavice apod. Jako řešení nelze zavrhnout také možnost na-hradit velkoplošný monitor LCD panelem s případným konvertorem RGB počíta-čového signálu na PAL signál vhodný pro zobrazení na takovémto zařízení. Avšakkvalita těchto konvertorů není dosud na takové výši, aby byl obraz ostrý a kvalitní,a tudíž vhodný k dlouhodobější práci.Výhoda automatizovaného návrhu se projeví nejen v rychlosti a správnosti pře-

nosu návrhu do informačního systému, ale i při kontrolách správnosti rozvrhu, přimožnosti rychle a optimálně si zobrazovat pohledy z různých hledisek apod., čehožna ryze mechanickém řešení nástěnných tabulí nelze nikdy dosáhnout. Vzhledemk tomu, že by podobné zařízení mohly sdílet všechny čtyři fakulty, lze se dostatu řady návrhů do přijatelných cenových relací.Pro zobrazování rozvrhů v informačním systému mluví jasně myšlenka získání

aktuálního rozvrhu studenty i bez návštěvy školy (především dojíždějící studenti)a též zpětná kontrola správnosti rozvrhu, kontrola křížení apod.

Zápis

Vlastní zápis pro studijní oddělení se provádí dvoukolovým způsobem. V prvnímkole probíhá již zmíněný předzápis. Zde je nutný částečný zásah studijního oddělení,např. při povinném opakování ročníku, vyřazení studentů apod. V současné doběprobíhá celá tato část plně v režii studijního oddělení, tj. studentům jsou zapisoványpředměty z tzv. šablon, které si vytváří studijní oddělení.


Celá část prvního kola se pro studijní oddělení časově zkrátí na jeden den, což jeproti současnému třídennímu zadávání velká úspora. V druhém kole potom docházíke kontrole koexistence indexů a dat v předzápisu a potvrzování korektních zápisů.Zde je možné s výhodou využít tištěných sestav, které lze přímo u zápisu kontrolovatproti indexům, zaznačovat případné chyby a ty později opravit v systému. Finančníúspora z důvodu kopií indexů i časová úspora z hlediska studijního oddělení budeznačná.Po provedení kontroly dojde k automatickému převedení dat.

Studium z hlediska studenta

V současném systému nemá student žádnou šanci získat nějaké informace o svémstudiu ve vlastním průběhu období. Dokonce ani učitel, pokud si nevede nějakouagendu vlastními prostředky, nemůže o studentovi nic podrobného říct. Přitom jeřada agend klasických – docházka, bodování cvičení, aktivita, průběžné písemnépráce, případové studie či protokoly, udílení zápočtů, zkoušková s termíny zkoušekapod.Proč tedy tyto úkony nezautomatizovat? O tom pojednává další část s ná-

zvem Záznamník učitele (někdy též Zápisník). Student by měl mít možnost sledovatz tohoto Záznamníku relevantní údaje o své osobě. Tyto údaje pak může získávati garant předmětu a sledovat tak situaci ve svém předmětu i v průběhu semestru.Při dotažení této myšlenky do konce lze umožnit studijnímu oddělení nebo

vedení fakulty nahlížet do průběžné agendy a získat tak další materiál k posuzovánížádostí studenta, např. o komisionální přezkoušení.Podobným způsobem lze řešit i neschopenky studentů od lékařů. Proč obíhat

desítku učitelů a přesvědčovat je o příslušné neschopence? Například na Fakultěinformatiky Masarykovy univerzity má studijní oddělení nástroje pro evidenci ne-schopenek a ostatní učitelé tak mohou snadno zjistit, které absence studenta jsoupodloženy dokladem na studijním oddělení. To je ideální úkol pro Záznamník učitelea agendu studentů.Dalším nástrojem pro studenty je potom přehled o aktuálních zadaných znám-

kách do Zkušební zprávy a možnost elektronicky se přihlašovat na jednotlivé zkoušky,zápočty nebo průběžné písemné práce.Díky projektu Virtuální univerzita (e-learning) lze tuto myšlenku dále rozší-

řit i na případné získávání elektronických testů a jejich provádění, čehož lze využítjednak jako myšlenky domácího cvičení, ověření znalostí, tak i k bodovaným tes-tům přímo v příslušné učebně ve škole. Možnosti takového pojetí výuky jsou zatímnedozírné.

Záznamník učitele

Nejzajímavější aplikací pro učitele je Záznamník učitele. Jedná se o aplikaci za-střešující veškeré operace učitele ve vztahu ke studentům, ke studijnímu oddělení


i k vedení fakulty. Kromě toho umožňuje tato aplikace učiteli udržovat většinu svéagendy v elektronické podobě a tím minimalizovat počet papírů ve vlastní kanceláři.Základní myšlenku Záznamníku učitele jsem přejal z fakultního informačního

systému používaného v letech 1995–99 na Fakultě informatiky Masarykovy univer-zity a značně ji rozvedl.Rozlišujeme Záznamník předmětu, který zakládá garant (resp. jádro tohoto

Záznamníku je založeno automaticky) a k jehož vybraným částem mají přístupostatní vyučující předmětu, a Záznamník učitele, který si vytváří každý vyučujícísám a jehož součástí jsou vybrané části Záznamníku předmětu, které jsou taktosdíleny. Vyučující si tak může udržovat privátní agendu a jednoduše přenášet datamezi ní a centrální agendou.Každý Záznamník je složen z řady různých listů, které mohou být mezi sebou

propojeny některým vztahem. Lze tak vytvořit list docházky, bodovací list písemnépráce, list zkouškový aj. Potom lze nadefinovat vztah mezi docházkou a průběžnouprací ve vztahu k zkouškovému listu, např. nutná docházka či zadaný počet bodůdovoluje účast na zkoušce.Kromě těchto evidenčních listů je součástí Záznamníku Kontaktní list, kde jsou

uvedeni všichni studenti předmětů s kontakty a odkud je možné hromadně oslovo-vat skupiny studentů či všechny studenty, kteří mají předmět zapsán. Podobnýchaktivních součástí může být více – Terminář zkoušek, zápočtů, písemných prací,propojení na Nástěnku předmětu apod.Typická práce jednotlivých cvičících spočívá v obhospodařování Zápočtového

listu, který je součástí Záznamníku předmětu. Cvičící si vytvoří vlastní součásti zá-počtu – docházku, průběžné práce, závěrečnou písemnou práci a nadefinuje vztahmezi těmito listy a Zápočtovým listem. Pomocí Kontaktního listu, Nástěnek a Ter-mináře písemných prací a Termináře zápočtů udržuje kontakt se studenty a jako vý-sledek všech těchto operací je automaticky navržen zápočet (příp. zamítnut). Tentovýsledek se odrazí na společném Zápočtovém listu (cvičící může zápočet samozřejměručně ovlivnit).K Zápočtovému listu má přístup garant a zkoušející, kteří mohou zápočet také

ovlivnit – a ti mají navíc definován Zkouškový list (příp. jeho součásti – písemnoučást, ústní část apod.) a tento list je napojený na Zápočtový list (ke zkoušce můžejen osoba se zápočtem). Výsledkem zadávání Zkouškového listu a užívání termi-náře zkoušek je potom navržená známka na Zkouškovém listu, která může být opětzkoušejícím či garantem ovlivněna.Nakonec garant předmětu uzavře Záznamník předmětu a data ze Zkouškového

listu jsou přenesena do Zkušební zprávy, která je k dispozici studijnímu oddělení.Studenti mohou nahlédnout ty části Záznamníku, kam jim příslušný cvičící,

zkušející či garant povolí nahlížet (minimálně je povolen Zkouškový a Zápočtovýlist). Tímto omezením si učitel může udržovat různé poznámky a hodnocení studentůmimo jejich pole působnosti. Obdobně je k různým částem Záznamníku dovolenonahlížet vedením fakulty (aby mohl například studijní proděkan rozhodovat a mělk dispozici dostatek údajů).


Pro zjednodušení práce se Záznamníkem budou vytvořeny desítky standardníchtypů Záznamníku, pomocí nichž budou moci vyučující a garanti založit standardníZáznamníky. Možnost tvořit si individuální Záznamník bude určena pokročilým uži-vatelům, kteří chtějí využívat elektronický Záznamník maximální měrou (a tím mi-nimalizovat svoji papírovou agendu). Záznamník může přijímat například i elek-tronicky odevzdávané případové studie a protokoly a sledovat datum a čas jejichodevzdání apod. Tyto práce jsou potom k dispozici trvale v systému a nezabírajídalší prostor v kanceláři vyučujícího.Záznamník je po uzavření stále přístupný pomocí Historie, takže lze zpětně

zjišťovat průběžné hodnocení, minulé práce apod. Práce z Historie záznamníku lzezveřejnit do části Věda a výzkum, na Nástěnky apod.

Anketa

Pro získání zpětné vazby od studentů bude k dispozici Anketa. Strukturu anketypro daný rok stanoví vedení fakulty. Anketa se týká jednotlivých předmětů (příp.jen vybrané množiny), studijního oboru, fakulty a případných dalších navrženýchtémat. Struktura ankety se pro různá témata může odlišovat.V době vyhlášení ankety na konci období jsou studentům elektronicky zaslány

anonymní kódy (náhodné řetězce), přičemž každý kód aktivuje některý typ ankety-nebo anketu konkrétního předmětu. Po využití kódu pozbývá kód platnosti. Studentisi tedy mezi sebou mohou kódy vyměňovat a tím získat dojem větší anonymity.Výsledky ankety se shromažďují a v zadaných intervalech (např. jednou denně)

zasílají zvolenému okruhu osob (vedení fakulty, garantovi předmětu, všem vyuču-jícím apod.). Toto odesílání probíhá zpožděně z důvodů bezpečnosti (učitel můžezahlédnout studenta zadávat anketu a následně se podívá do svých došlých odpovědí– a ztrácí se tím anonymita).Budou také existovat nástroje pro hromadné odpovídání na anketu (formou

vystavení na veřejných nástěnkách či zaslání mailem), tvorba statistik z odpovědíapod.

Závěrem

Závěrem lze podotknout, že navržený systém elektronizace studia ponechává ote-vřené další aspekty, jako jsou Elektronické indexy, využití Digitálního podpisu apod.,které v budoucnu umožní ještě více zjednodušit a zpříjemnit doprovázející agendystudia.Systém přinese zjednodušení práce studentům, zvýší jejich informovanost

a umožní zavést plně kreditní ECTS systém studia (European Credit Transfer Sys-tem). Na druhou stranu poskytne učitelům chybějící nástroje a přehled o dosaženýchstudijních výsledcích. Rovněž jim umožní odstranit řadu papírové agendy.Studijní oddělení a vedení fakulty získají včas (a to i s předstihem jednoho roku)

potřebné informace, navíc studijnímu oddělení odpadá řada přepisování dat, kterése tímto systémem pořídí již u zdroje.


Jako řada jiných změn, přinese i implementace tohoto systému zřejmě řadukomplikací z hlediska nepochopení koncepce, čemuž se budeme snažit zabránit na-příklad touto osvětovou prací.I když se v počáteční fázi zavádění systému bude některým skupinám uživatelů

zdát, že je na ně kladeno více požadavků než dříve, později se ukáže, že taktoinvestovaný čas do pořízení dat usnadní život tisícům uživatelů.Z časového hlediska byla uvedena první část této koncepce do provozu na PEF

ještě v průběhu roku 2000, definitivní přechod na nový systém se pak projeví u celéuniverzity na začátku období akademického školního roku 2002/2003, tedy přibližněv květnu roku 2002 (předobdobí, registrace).

B GRAFY VYUŽITÍ FIS A UIS 91

B Grafy využití FIS a UIS

Oba budované informační systémy evidují průběžně všechny dosud provedené ope-race (již více než 4 miliony operací za dobu svého provozu). Každou noc jsou zpra-covávány podrobné statistiky, které umožňují uživatelům sledovat různá vyjádřeníprogresivního počtu operací.Následující graf na obrázku 10 prezentuje vývoj užívání obou systémů v uply-

nulé době (souhrnný graf přístupů od uvedení systému FIS v březnu 2000 do pro-vozu, v červnu 2001 byl připojen také Univerzitní informační systém, který užívajívšechny fakulty i mimofakultní pracoviště). Údaje za poslední měsíc (duben 2002)jsou aproximovány pomocí průměru na den (aby data byla srovnatelná s ostatnímiměsíci).

Obr. 10: Graf užívání FIS a UIS v předchozích dvou letech

Z grafu je patrný každoroční nárůst počtu operací i stále se zlepšující poměroperací uvnitř systému (po přihlášení) vůči všem operacím. Také přístupy vývojo-vého týmu jsou dnes již zcela zanedbatelné vzhledem k celkovému počtu přístupů.Zajímavý je stabilní trend přístupu přes rozhraní pro mobilní telefony (W@P roz-hraní), které již není rok vyvíjeno, ale má stále stabilní množství operací každý měsíc(poskytuje údaje pouze o Provozně ekonomické fakultě).


Další graf na obrázku 11 zobrazuje poměr užívání obou systémů podle jednot-livých ústavů.

Obr. 11: Graf užívání FIS a UIS z hlediska jednotlivých ústavů

Smysl tohoto grafu je v rozboru údajů za Provozně ekonomickou fakultu – jepatrný nejvyšší počet přístupů z děkanátu PEF, kde je systém v rutinním používánía z Ústavu informatiky PEF, kde pracuje většina vývojářů. Některá oddělení nauniverzitě se již významně zapojila do používání informačního systému. Všechnyústavy s méně než 750 zaznamenanými operacemi jsou vedeny v kategorii Ostatní.


Třetí prezentovaný graf na obrázku 12 zobrazuje poměr užívání obou informač-ních systému podle jednotlivých základních skupin uživatelů.

Obr. 12: Graf užívání FIS a UIS jednotlivými skupinami uživatelů

Nejvýznamnější skupinou užívající naše informační systémy jsou bezesporu stu-denti (skupina s největším počtem osob). Zajímavé je ale vztáhnout tyto hodnotyk počtu uživatelů příslušné skupiny užívající UIS (u uživatelů ze světa je počítánpočet unikátních adres mimo rozsah MZLU, kdy rozsah MZLU je počítán dvojná-sobně – přístup z práce a z domu a jsou odečteni studenti – další přístup z domu).Tato situace je znázorněna na následujícím grafu na obrázku 13.

Obr. 13: Graf užívání FIS a UIS jednotlivými skupinami uživatelů vztažený na jednohouživatele

C VYBRANÉ UKÁZKY APLIKACÍ Z UIS 94

C Vybrané ukázky aplikací z UIS

Tato příloha obsahuje vybrané ukázky aplikací ze současného Univerzitního infor-mačního systému.

Obr. 14: Úvodní obrazovka Univerzitního informačního systému


Obr. 15: Základní nabídka po přihlášení do Univerzitního informačního systému


Obr. 16: Multimediální vzhled aplikace na vyhledávání osob na MZLU


Obr. 17: Informace o osobě na MZLU


Obr. 18: Katalog předmětů (Zahradnická fakulta v Lednici)

Documents

diplomovka