Univerzitní informační systém

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.

Brno 2002

Milan Šorm

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 poskytoval a poskytuje mně a ostatním vývojovým pracovníkům Univerzitního informačního systému v průběhu řady uplynulých let. Také bych chtěl poděkovat všem vývojovým pracovníkům Fakultního i Univerzitního informačního systému, kteří se mnou spolupracovali a spolupracují při mém úsilí ve tvorbě toho nejlepšího systému pro naši univerzitu. Rovněž chci poděkovat vývojovým pracovníkům Informačního systému Masarykovy univerzity (a především CVT FI MU), kteří mi byli velkou inspirací při tvorbě našeho informačního systému. Nakonec chci poděkovat svým rodičům a blízký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řeprogramová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ým vedení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 structure of University information system on Brno Mendel University of Agriculture and Forestry. The main part of the work introduces the structure of the system, the methodics used and documents all known or newly created methods for building web information system in a specific environment of higher education. The complex data model of the 1st phase of such an information system realization is a constituent part 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 informač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 dokumentuje nastudované, příp. nově vytvořené metody pro tvorbu webových informačních systémů ve specifickém prostředí vysokého školství. Součástí práce je rovněž kompletní datový model 1. etapy realizace tohoto informačního systému.

5

OBSAH

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

7 7 8

2 Základní pojmy

10

3 Současný stav IS/ICT 3.1 Trendy mající globální ekonomicko–společenský význam . . . 3.2 Trendy mající vztah k ekonomice, řízení a organizaci podniku 3.3 Trendy v oblasti základního software . . . . . . . . . . . . . . 3.4 Trendy v oblasti aplikačního software . . . . . . . . . . . . . . 3.5 Trendy v oblasti informačních technologií . . . . . . . . . . . . 3.6 Trendy v oblasti metod a nástrojů vývoje IS/ICT . . . . . . . 3.7 Trendy v organizaci a řízení IS/ICT . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

15 15 17 18 19 21 22 26

4 Architektura moderních informačních systémů 4.1 Vertikální struktura IS . . . . . . . . . . . . . . 4.2 Horizontální struktura IS . . . . . . . . . . . . . 4.3 Horizontálně–vertikální struktura IS . . . . . . . 4.4 Třívrstvá architektura informačních systémů . .

. . . .

5 Metody řízení vývoje a provozu IS 5.1 Životní cyklus projektu . . . . . . . . . . . . . . . 5.2 Modely životního cyklu IS . . . . . . . . . . . . . 5.3 Způsob pořízení informačního systému . . . . . . 5.4 Metoda řízení vývoje a provozu UIS . . . . . . . . 5.5 Řízení lidských zdrojů ve specifických podmínkách

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

28 28 30 30 31

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

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

34 34 38 40 42 45

. . . .

. . . .

6 Základní cíle UIS 47 6.1 Administrativní podmínky a uživatelé systému . . . . . . . . . . . . . 47 6.2 Technické podmínky . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 6.3 UIS jako priorita univerzity . . . . . . . . . . . . . . . . . . . . . . . 49 7 Architektura UIS 50 7.1 Technická architektura . . . . . . . . . . . . . . . . . . . . . . . . . . 50 7.2 Aplikační architektura . . . . . . . . . . . . . . . . . . . . . . . . . . 53 7.3 Datově–logická architektura . . . . . . . . . . . . . . . . . . . . . . . 56 8 Teorie webových informačních systémů 59 8.1 Jednotlivé aspekty teorie WIS . . . . . . . . . . . . . . . . . . . . . . 59 8.2 Budoucnost teorie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

OBSAH

6

9 Jednotlivé rodiny aplikací 9.1 Plánovaný projekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.2 Aktuální stav vývoje . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.3 Ukázka podrobné analýzy . . . . . . . . . . . . . . . . . . . . . . . .

67 67 71 71

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

72 72 73 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

1 1.1

7

Úvod a cíl práce Ú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 studenta pomocí 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 pozorovatele tento 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, souvisí se studiem celá řada dalších skutečností. I tyto údaje je nutné v informačním systé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ý informač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. Lze ovšem předpokládat, že později bude provozní informační systém rovněž začleněn do UIS 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 vybudová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. Po dobu vývoje systému tato skupina zajišťuje také rutinní provoz celého systému, pozdě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 agend této fakulty. Úspěch tohoto systému umožnil zahájit v roce 2001 práce na Univerzitním informačním systému, kde bylo využito poznatků a zkušeností ze systému miniFis. V současné době je vývoj miniFis již ukončen a probíhá jeho postupné odstavová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 semestru 2001/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 systému, na podobě datového modelu a na analýzách jednotlivých částí informačního systému. V systému miniFis jsem byl autorem jádra tohoto systému a řady studijních i nestudijních aplikací. V systému UIS se zabývám hlavně koncepční a analytickou prací. 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 systému jako jednomu z typových webových informačních systémů. Na tuto práci navazuje ř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šak nebyly 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ěkde nepovedlo (což se později ukázalo), bylo nutné celou část systému k velké nelibosti uživatelů přepracovat. To by ovšem nebylo možné bez podnětných myšlenek ostatní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 čtenářů 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 metody, 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ách uvnitř 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) částmi systému. Při současném stavu informovanosti se pro ně systém v mnoha ohledech chová jako černá skříňka, která odpovídá na základě vnějších podnětů a snižuje či naopak 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 MZLU v Brně (zhruba osm tisíc uživatelů). Základem pro tuto práci bude seznámení se s architekturou moderních informač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 bude možné analyzovat možnosti využití webových technologií při návrhu a realizaci informačního systému nejen pro naši vysokou školu (obecný webový informační systém podniku).

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á bude podrobně rozpracována. Vytvořený systém bude ve spolupráci s vývojovým týmem implementová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 specializovanou literaturu o studované problematice (bude shrnuta v seznamu literatury a citována ve vlastní práci).

2

ZÁKLADNÍ POJMY

2

10

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 pochopit problematiku 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 informatický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řebu poznávání. Informace jsou nehmotné (a proto i obnovitelné) a lze je zaznamenat fyzický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, technologie, 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. Pro potřeby této práce jsou data veškeré informace, které mají nějaký vztah k Univerzitnímu informačnímu systému (např. je potřebuje nějaký jeho uživatel ze systému získat). Informatika Je věda o základech elektronického zpracování dat a její aplikace (teoretická informatika, technická informatika, kybernetika, . . . ). V našem pojetí budeme informatikou rozumě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

2

ZÁKLADNÍ POJMY

11

a čas a zabránit chybám a omylům. Strojové zpracování dat všeho druhu vyžaduje jejich převod do takové psané formy, které bude stroj rozumět (kódování dat). Obvyklým systémem elektronického zpracování dat je informační systém, který zajišťuje zí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 systematické 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 technický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í technologie. Informační technologie Pod pojmem informační technologie obvykle myslíme soubor nástrojů, metod a znalostí sloužících k činnostem, k nimž je informační systém určen (sběr, uchování, přenos a prezentace informací). Rovněž informační technologie představují zákonitosti vý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). Technologie je správný název pro to, čemu dnes nesprávně říkáme technika (technika jsou pouze 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, podpora 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í podnikovou strategií a integrací informačního systému. Pouze při naplňování informační strategie dochází k plnění strategických cílů podniku (ostatní případy vedou nutně ke stagnaci a úpadku). Systémová integrace Systémová integrace je jeden z hlavních principů modelu řízení vývoje, provozu a 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 integrací vhodných komponent a služeb od různých dodavatelů. Systémová integrace

2

ZÁKLADNÍ POJMY

12

jako princip řízení informačního systému zohledňuje specifické nároky na řízení informačního systému, vyplývající z vysoké heterogenity produktů, služeb a jejich dodavatelů současných informačních technologií. Současně je systémová integrace také procesem zajišťujícím propojení (integraci) 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á integrace 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ého rozhraní. Osoba či podnik, který tyto činnosti provádí, se nazývá systémový integrá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í metody ří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 informačních systémů budovaných a provozovaných pomocí outsourcingové společnosti v podobě systémového integrátora. Outsourcing Outsourcing je jedna z metod pořízení informačního systému, kdy příslušný dodavatel zajišťuje komplexní dodávku a provoz celého informačního systému. Obvykle tak dodavatel zajišťuje vrstvu technologickou, metodickou, aplikační, datovou i uživatelskou včetně zaškolení uživatelů, tvorby dokumentace, iniciálního uvedení do provozu a řešení provozních problémů. Slouží současně jako technický helpdesk pro všechny uživatele a zastřešuje provoz konkrétního informačního systému. Jedná se de 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é struktury – metadata a vlastní data) a systému řízení báze dat (Data Base Management System) bez příslušných prezentačních aplikací. Uvedený databázový systém tedy umožň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 databá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

2

ZÁKLADNÍ POJMY

13

transformací a prezentací dat jako vlastností metadat) a datové sklady (datawarehouse, 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 problému. Skládá se z entit (cokoliv, o čem je třeba uchovávat informace), atributů (informace týkající se konkrétní entity), domén (obory hodnot atributů, nikoliv pouze datové typy, o kterých se hovoří až na fyzické úrovni, ale také logické podmínky a vazby) a vztahů (asociace mezi entitami). Obvykle je datový model představován strukturou (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 komunikaci se systémy řízení báze dat založenými na relačním modelu. První verze se objevila již v 70. letech ve firmě IBM (nazývala se Sequel). Jedná se o jazyk standardizovaný, 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 se SQLv3). 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 SQL jazyka 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é jsou schopny si navzájem vyměňovat informace pomocí protokolu TCP/IP a přenášet tak 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ému spektru služeb a informací. Neomezené možnosti také skýtá v oblasti využití pro reklamní a propagační účely. Jde o zcela převratný prostředek komunikace na celém světě, proto bývá označován za nejnovější komunikační médium. Sítě založené na stejné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ýznamně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 na internetu. Jde o graficky orientované prostředí hypertextových dokumentů zvaných www stránky, využívá moderní multimediální techniky (obrázky, zvuky, animace),

2

ZÁKLADNÍ POJMY

14

čí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 zapisovány značkovacím jazykem HTML odvozeným od obecného značkovacího SGML jazyku. Tyto stránky mohou být statické (předem připravené) nebo dynamicky generované (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é aktivity do 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ů postupem č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 realizace takový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 Fakultě informatiky Masarykovy univerzity při vývoji tamního Informačního systému Masarykovy univerzity. Na rozvoji teorie pracují vývojoví pracovníci UIS s dalšími odborníky z celého světa.

3

SOUČASNÝ STAV IS/ICT

3

15

Současný stav IS/ICT

Informační systémy a informační a komunikační technologie prošly za šest desetiletí existence výpočetní techniky rozsáhlou cestou vývoje. První větší systémy pro zpracování dat a poskytování informací z 60. let minulého století neobsahovaly ani zlomek funkcí dnešních systémů a předčí je dokonce i systémy automaticky generované (např. webové portály pro elektronický obchod). Současné informační systémy nemohou existovat bez dobré informační technologie, 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ý bude použí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 vytvoř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 sledovat aktuální vývoj a trendy informačních technologií. Tyto trendy sledují nejen dodavatelé 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ím výzkumu a vývoje, a podporují nadějné a slibné myšlenky ve veřejném i soukromém sektoru. 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í lidské činnosti i na podobu informačních systémů, jsou komunikace. Komunikace se rozví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 typu je 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 schopný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é prostředí a mění také některé sociální vztahy ve společnosti. Již dnes není nutné cestovat za prací a je možné pracovat přes Internet, v celosvětové síti je možné prezentovat svou firmu s velmi nízkými marketingovými náklady, lze přes ni nakupovat, konzultovat 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 soukromé organizace. Internet proniká stále více do domácností běžných uživatelů, kde již dnes penetrace připojení k Internetu dosahuje 80 % všech počítačem vybavených domá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 pracovních sil a vydávání prostředků na dopravu. Výrazným způsobem tak ovlivňuje hospodářství v národním i nadnárodním významu a stává se jedním z hlavních faktorů 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 firem do 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 Internet v zemích s monopolním telekomunikačním operátorem), • změny forem komunikace mezi obchodními partnery (klasické papírové dokumenty 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 zasílat obchodní dokumenty (objednávky, faktury, platební příkazy apod.) elektronickou cestou budou v obchodě znevýhodněni, protože komunikace s nimi bude málo efektivní), • dramatické změny ve formách prodeje výrobků a služeb (stále více se budou prosazovat 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ém prodeji 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 platební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ředkovateli v 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í bude pracovat 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áklady oproti klasickým podnikům budou podstatně nižší, protože se podstatně sníží náklady na podnikové budovy, energii, cestovné atd., a produktivita jejich práce bude 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 rychlost zpracová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átu umož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, že management stanoví cíle, které IS/ICT pomůže dosáhnout, je správná. Bohužel správná metoda není ani představa IS/ICT jako rozhodujícího faktoru při stanovení metod řízení a organizace podniku. Správná cesta je, jako ostatně vždy, někde uprostřed. Pouze kombinací vhodného řízení podniku s nasazením vhodné IS/ICT je možné dosáhnout optimálního chodu podniku a být úspěšný na současném globálním trhu. Možnosti moderních IS/ICT totiž mohou zcela změnit organizaci a způsob řízení v podniku. Příkladem vhodného skloubení moderních IS/ICT a způsobu organizace a řízení podniku jsou 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 platit. 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říkladem 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í – flexibilní 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 relativně 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 reengineering, 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/ICT nebude 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 tlaku konkurence. Proto řada podnikových IS/ICT přechází dnes na model tzv. učící se organizace, 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řevádí je na smysluplná data, na základě kterých potom mění svou vnitřní strukturu a 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 etablovalo několik základních softwarových domů, především společnost Microsoft. Na osobních počítačích dnes převládá operační systém MS Windows v nejrůznějších podobách. Také kancelářské aplikace, tj. textový procesor, textový kalkulátor, kartoté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 kancelář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ý systém), ale především nekompatibilita jejich datových formátů s formáty společnosti Microsoft 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šiny dnešních operačních systémů jsou i tyto programy a tak zjednodušují instalaci a použí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í audio 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ému kaž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 je dBase, 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ž pentabyty 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 mobile computing 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 funkce tzv. smart databází, tedy databází s přidaným prvkem automatického předzpracování pomocí předprogramovaných mechanismů, spouští (triggerů) a pohledů na databázi.

3.4


Do aplikačního software řadíme veškerý software, který je natolik specifický, že nemůže být řazen k základnímu software dodávanému s vlastním hardware. Patří sem jednak úzce specializované kancelářské systémy, systémy EDI pro zajištění oběhu dokumentů 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ůže představovat značnou konkurenční výhody ve srovnání s jinými společnostmi (ale někdy může být též nezáviděníhodným břemenem, pokud vychází ze zastaralé informač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éna o analýzu podnikových cílů a podnikových procesů, výběr vhodného typového aplikačního software, volba použitelných modulů, přizpůsobení těchto modulů potřebám společ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 systé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 konkré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žadavků či při změně legislativy nebo vnitropodnikových předpisů, cílů, pravidel nebo postupů.

3.4


20

Rostoucí komplexnost TASW umožňuje zvyšování rozsahu funkcí i nad hranice 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 parametrizovaným TASW. Vnitřní složitost těchto systémů roste se snahou zapracovat všechny potenciálně možné typy provozu, např. hromadnou, sériovou, kusovou nebo kontinuá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ým systémům řízení báze dat. Dodavatelé se tak snaží hledat nové zákazníky i tam, kde by s původním systémem díky nekompatibilitě prostředí neuspěli. Tento trend vede k rostoucí heterogenitě sítí a systémů a umožňuje existenci dalších ASW zajišťujících propojení ostatní informačních systémů a vznik samostatných integrovaných informač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 efektivitu 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 mohou jednotlivé systémy čerpat a tak odstraňovat nutnost působení člověka jako zprostředkovatele informací mezi různými odděleními. Zajímavým pohledem na tuto problematiku 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 pracovat ve svých národních prostředích a nabízí zákazníkům informace v těch jazykových variantá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 je mož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 legislativy v 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ý kancelářský software v podobě Microsoft Office). EDI systém zajišťuje obousměrnou konverzi 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 distribuci zpráv na různá pracoviště (diskuzní skupiny, dokumentové servery, vývěsky, elektronická pošta). Řada systémů EDI je standardizována pomocí standardu EDIFACT.

3.5

3.5

Trendy v oblasti informačních technologií

21

Trendy v oblasti informačních technologií

Nejvýznamnějším současným trendem v celkové informační technologii je snaha o 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 protokolu TCP/IP, operační systémy navzájem zajišťují svou kompatibilitu pomocí normy POSIX, jednotlivé aplikaace používají objektově orientovanou architekturu definovanou 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 – operačního systému). Tvůrci software se proto dnes snaží tvořit software nezávislý na konkré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živatel tak má možnost personalizace vlastního systému bez ovlivnění jeho podstatných funkcí. Je tak možné vytvářet aplikace přesně zapadající do vzhledu celého ZSW a 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 to konkré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 komunikují podle definovaného rozhraní (API), obvykle na základě některého obecného standardu (XML, CORBA, volání funkcí API). Tak je možné průběžně vyměňovat a škálovat různé části systému a přizpůsobovat je konkrétním specifickým potřebám zá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á část obvykle 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 (prezentace u 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žňuje zjednoduš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 na zavá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 je trendem 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 datových či funkčních složek. Klientská část komunikuje s nejbližší serverovou částí a ta ji dle potřeby přesměrovává na další části nebo opatřuje data sama. Redukují se tak ná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í doplňky počínaje tapetou na pozadí, zvukovými efekty a animacemi a konče variantním designy (skiny) či maximální přizpůsobitelností ASW. Na jednu stranu tento trend prodražuje vlastní ASW, ale uživatelům umožňuje rychleji se se systémem sžít a vytvořit tak efektivní pracovní kombinaci spokojeného uživatele a kvalitního systému.

3.6


Významný posun zaznamenala též oblast metod a nástrojů vývoje IS/ICT. Lze vysledovat trend postupu od strukturovaných technik k technikám objektově orientovaný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 informačního systému, vysvětleme si tuto techniku podrobně (principy jsou zpracovány na základě [21] a [22]). Objektově orientovaný přístup Objektově orientovaný přístup je velmi silný formalismus využitelný především k modelová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í žehlič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é objekty mohly využít). Každý objekt si pak lze představit jako určitou množinu vlastností spolu s definovanou určitou množinou činností, které lze s tímto objektem provádět. Obvykle o těchto činnostech hovoříme ve smyslu „objekt provádí činnostÿ nebo ve smyslu antropomorfizace objektu1 . Souhrn všech činností jednoho objektu nazýváme chová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ásledek 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 činnosti pro 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. Celý 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řesnou formální specifikací, omezíme se na slovní popis formalismu. 2

3.6


23

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 stole zleva 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 strukturu vlastností 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ýroba cukru 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í toto chování). V obecném formalismu objektového přístupu jsou definovány i další druhy metod (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ě orientovaného přístupu: • dědičnost • zapouzdření • polymorfismus Vlastnost 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čnost mezi 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 metod instance. Na obrázku je tato komunikace znázorněna šipkami. Navenek se tedy kaž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 mohlo dojít ke změně vlastnosti (hnědnutí jablka), musí dojít k určité činnosti (např. oxidace povrchu jablka), tedy k vyvolání metody. 3

V 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 formalismem objektově orientovaného přístupu jednoduše modelovat.

3.6


24

Obr. 1: Zapouzdření objektu

Vlastnost polymorfismu si nejlépe představíme na příkladu. Představme si ošatku, do které lze vkládat ovoce. Pak nezáleží příliš na tom, zda se jedná o jablka č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ůsobem, 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á pak již vůni velmi reálnou. Výhoda polymorfismu je především v mechanismu, kterému se ří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 polymorfismu by bylo nutné definovat, že člověk má sníst jablko, pokud mu jablko voní (protože ví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 pak musí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 nebo kubánské pomeranče. Vzhledem k tomu, že každé ovoce má definovánu vůni a činnost snězení ovoce (byť abstraktně), je možnost tohoto stylu výuky člověka reálná. Člověk má vůči ovoci tzv. pozdní vazbu, protože do posledního okamžiku (před testem na vů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 destruktorem objektu nazveme tu činnost, která způsobuje zánik objektu (to je naopak metoda instance, protože pracuje nad konkrétním objektem). 4

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

3.6


25

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 postupně 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 implementace IS/ICT čím dál více podporují inkrementální vývoj IS/ICT a rychlý vývoj jednotlivých aplikací s použitím prototypů (RAD – Rapid Application Development). Je to reakce metodik na snahu o rychlý vývoj IS/ICT při současné ochraně investic a 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 naopak se vývoj řídí potřebami konkrétních uživatelů právě vyvíjeného systému (soft metodiky). 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ě spojeny s automatizovanými nástroji, které zefektivňují použití metod a technik v metodice obsažených. Pro tyto nástroje se vžil název CASE (Computer Aided Software Engineering, 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ých na 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 od strategického plánování (od informační strategie) až po zavedení informatického projektu do provozu – jednotlivé fáze projektu jsou přitom propojeny řadou kontrol na konzistenci projektu, • snaží se propojit jednotnými nástroji návrh a implementaci IS/ICT s provozem IS/ICT (CASE zachycující stávající stav i plánované stavy celého IS/ICT se obvykle nazývá metasystém), • CASE jsou navrhovány tak, aby byly využitelné pro projekty realizované za podpory různých metodik (tento směr vývoje CASE je významný pro ty podniky, 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žaduje, aby různé produkty byly v podniku zdokumentovány a v provozu řízeny jedním nástrojem).

3.7

3.7

Trendy v organizaci a řízení IS/ICT

26


Základem moderní organizace a řízení vývoje, zavádění a provozu IS/ICT je dnes především outsourcing a systémová integrace. Outsourcing představuje metodu minimalizace 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 zajišťováním servisu, resp. údržby hardwarových komponent. Relativně řídkým jevem je zatím outsourcing provozu IS/ICT. Je tomu tak zejména z důvodů problematické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ů zavá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 provozu IS/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 komponent IS/ICT a služeb externích dodavatelů do výsledného produktu – integrovaného informač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ého IS/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í (datamanažeři), správci počítačových sítí, specialisté na on-line konzultační služby, „zajiš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. let byly 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 organizace a techniky řízení. Koncem 80. let bylo v českých podnicích typické, že výpočetní středisko (útvar informatiky) bylo odděleno od útvaru organizace a bylo přímo podřízeno ekonomickému řediteli podniku.

3.7


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 generá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á potřeba zajištění vysoké spolehlivosti a dostupnosti prostředků IS/ICT. Jsou definovány základní stupně spolehlivosti systému a snaha všech velkých dodavatelů IS/ICT vede k zajištění plného 24×7 provozu se spolehlivostí stupně 5 (tj. 0,999 99 % dostupnost systému – asi 5 minut ročně je systém mimo provoz). Do zajištění spolehlivosti 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Ů

4

28

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žňuje tomuto 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álem pro 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 strukturu z 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 rozdě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ňovou pyramidu, 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 se na základní (OIS), resp. střední (MIS) úrovni řízení podniku tvoří jádro každého informač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 poskytovat 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é se soustředí do aplikačních programových balíků pro podporu životního cyklu informač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říchod zákazníka) aktivuje tento systém a on zajistí sesbírání podstatných dat a on-line vyhotovení 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ždodenními činnostmi. Jeho úkolem je řízení aktivit, které tuto každodenní činnost podporují (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 tedy poskytnout 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ší orientaci na analytické a rozhodovací algoritmy. Pro svoji menší strukturovatelnost bývají zpravidla řešeny nestandardizovanými postupy. Jsou orientovány na specifickou třídu uživatelů se specifickými informatickými potřebami a to v sobě odráží i potřebu použ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 rozhodování, úkoly hromadné obsluhy, dopravní úlohy (logistika) a další úlohy operačního výzkumu, statistiky, teorie her. Umožňují algoritmizovat postupy v rozhodovacích procesech. Systémy podpory vrcholového managementu (EIS) jsou účelově orientované systé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 systé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 jejich rozhodovacího procesu. Nejdůležitější činností EIS je integrace mnoha datových zdrojů 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 data administrativního charakteru v převážně písemné popř. grafické podobě. Systém pro podporu administrativy se postupně strukturuje a přizpůsobuje organizační struktuře podniku. Ve vzájemných interakcích s uživateli se postupně stabilizuje a plynule a většinou v předstihu oproti ostatním částem informačního systému absorbuje ve větší či menší míře nové produkty informačních technologií – multimediální technologie, komunikační protokoly, datové nosiče, prohlížeče v rozsáhlých počítačových sí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 jsou hlavně 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 dat a 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 jednotlivý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émy se pak dále dělí, např. u Výroby na Nákup surovin, Kontolu zásob, Plánování produkce apod. Příklad této struktury v podnikovém informačním systému je uveden na 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, Identifikač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ískáme komplexní pohled na modulární informační systém, jehož jednotlivé subsystémy jsou specifické jak z pohledu úrovně řízení, tak z pohledu organizační struktury podniku. Vhodným příkladem dělení pak může být příklad Ekonomicko-výrobního systé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 systém podle specifičnosti úrovně řízení (ve vztahu obecná a široká datová základna ke specifickému a úzkému vrcholovému řízení), horizontální dimenze naopak podporuje rozklasifikování systému podle činnosti organizace a vyčlenit jednotlivé vedoucí na dí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 systémů zasahují dva další subsystémy – kancelářský informační systém (OIS) poskytující uživatelům běžné služby jako textový procesor, tabulkový kalkulátor, prezentátor, kreslicí program, kartotéka či plánovací kalendář a systém EDI (Electronic Data 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


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ých možností daných dobou. Jedná se o ideovou jednotu použitých prvků, má definovaný 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ře5

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

4.4


32

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 jinou platformu). 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í databázové operace (databázová vrstva) na straně serveru a klientské aplikační a prezentační operace (na aplikační vrstvě). Tato architektura byla dána poměrně standardizovaný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 operačních systémů, ze kterých bylo možné k informačnímu systému přistupovat a řada informač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žby aj.). Tento posun si vyžádal vznik nového pojetí – třívrstvé architektury. Schématické 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čnou datovou 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. Je prostředníkem mezi obecnou prezentační vrstvou (tj. vstupy a výstupy uživatelů)

4.4


33

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 jsou informač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 (prezentač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é architektury však zůstává.

5

METODY ŘÍZENÍ VÝVOJE A PROVOZU IS

5

34

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 rozsáhlou personální strukturu, vybavit tyto osoby vhodnou technologií, zajistit jim přístup k informacím (a získávat od nich informace zpětnou vazbou) a celou záležitost řádně profinancovat. Celá práce s vývojem a následným provozem informačního systému však musí být určitým způsobem organizována a řízena, aby nedocházelo k 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, otestovat, zdokumentovat a následně provozovat informační systém. Některé metodiky volí 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 provozu informačního systému, posuzuje vhodnost těchto metod ve specifickém prostř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 je př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 provoz prochází. Každý projekt začíná rozhodnutím podniku o vývoji a nasazení nového informačního systému nebo o modernizaci či rozšíření stávajícího informačního systé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 projekč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ů organizace a provádějící zavádění, příp. celý vývoj, přímo v podniku a externí část týmu slož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é sestavuje globální návrh celého systému a zpřesňuje tento návrh do detailů (návrh systému). Ve druhé fázi implementuje zvolené řešení a provádí testy na správnost implementace 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


35

Úvodní studie Úvodní studie je základní krok při přípravě projektu. Jedná se o analýzu systému a 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 navržených cílů (ty předkládá zadavatel – vedení organizace). Cíle vedení mohou být velmi obecné, úvodní studie je potom dokumentem, který vzniká na základě stanovených podmínek, podnikové strategie a definuje podrobné cíle zavádění informačního systému. Analyzuje současný stav, zjišťuje pozitiva a nedostatky stávajícího informač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ích nákladů porovnaných s celkovým přínosem systému. Na základě takto vytvořeného porovnání je poté navrženo vhodné řešení, které bude v podniku či organizaci nasazeno. Výběr variantních řešení provádí po konzultaci se systémovým integrátorem nebo 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 legislativní (zákony a normy vztahující se k zaváděnému projektu, stanovení podnikových norem, 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 nového systému na podnikovou kulturu, odraz ve kvalifikaci zaměstnanců), hledisko softwarové (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ěr dodavatele 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ších projektů pak tato fáze splývá s detailním návrhem, protože není nutné zasahovat do velké šíře problémů). Cílem globálního návrhu je rozvedení úvodní studie do detailně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 informací, které se v podniku vyskytují (zdroj, tok, objem, forma, obsah, přístup, doba uchová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 je startována (kterou událostí), vstupní a výstupní data a způsob jejich transformace

5.1


36

uvnitř transakce. Nezbytnou součástí transakce je také určení, které činnosti budou manuá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 hlediska 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 vnitropodnikových i externích sítí, rozmístění jednotlivých komponent systému aj. Z hlediska 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řechodu od logického návrhu k návrhu fyzickému, tzn. k návrhu závislému na zvoleném technologickém prostředí (platforma, programovací jazyk, konkrétní užitý hardware apod.). 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 algoritmů zajišťujících splnění doby odezvy), četnost přístupů (pro potřeby indexace dat), 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 jednotlivý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 konkretizuje 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 budov, 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ých struktur v systému řízení (prvků a vazeb), návrh nových řídících procesů v navr-

5.1


37

hovaných strukturách (toky dat, algoritmy, zpracování), návrh charakteristik řídích struktur a procesů a návrh vztahů struktur a procesů. Cílem následující fáze – implementace – 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 testovacími) daty, zvolit metodu zavádění (postupné zavádění po etapách a modulech nebo kompletní 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řeba udrž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 modulů 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é aplikace je třeba testovat na správnost i dostatečný výkon (podle předem stanovených hledisek, 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ího systé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žít ke 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ému jsou 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 mezi starý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 systému a nových technologií mohou provádět modifikace. Vycházejí jak z nalezených chyb, tak na základě požadavků uživatelů tohoto informačního systému. Všechny chybové 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án mezi 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 prová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í studie nové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ího období systémy provozované v době pořízení těchto dat).

5.2


Nalezení univerzálního modelu pro řízení výstavby a celého životního cyklu informač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 provozová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 využití kombinace těchto modelů. Pro lepší pochopení námi užité metody řízení vývoje a 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ředbíhání není přípustné.6 Toto řešení je možné pouze v případě, že budoucí uživatel informač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 natolik profesionální, že je schopen tento postup přesně zvládnout. To samozřejmě ve skutečnosti nebývá. Tento model je proto považován za model řadící za sebe jednotlivé 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 systematické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ých nedostatků je pak odhalena až v závěru projektu a může mít zcela zásadní důsledky 6

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

5.2


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 potř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ě zasahovat 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ího systé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ývoj zpět do fáze analýzy. Tento cyklus probíhá tak dlouho, než jsou všechny připomínky implementová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ědnosti 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á zadavatel př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ími zkuš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 pro odběratele již přijatelný. Tento postup je náročný na celkové řízení, etapy lze těžko dopř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 dodavatele a zadavatele nad obsahem projektu). U tohoto modelu také hrozí odpoutávání se od hlavní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 sys7

Vývoj Univerzitního informačního systému po vnější stránce připomíná velmi chaos modelu výzkumník, ovšem vývojový tým užívá různé modely vývoje (viz později) a tento zdánlivý chaos je 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ánová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ědnosti za systém. Poté dochází k vytvoření informační strategie, ve které jsou analyzovány uživatelské cíle, formulována organizační strategie a sestaven návrh architektury. Následuje 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 se vybere jedna, která bude implementována. Pro ní se vytvoří přesná definice a provede se kontrola této definice. Poté přichází na řadu tvorba jednotlivých komponent až do okamžiku, kdy je celý systém kompletní. Jednotlivé etapy jsou nejprve prototypová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. Na základě prototypu také zadavatel přesně pochopí chování a rozhraní tvořeného projektu 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 rozsáhlých modelů je vhodné využít kombinaci prototypování s modelem výzkumník.

5.3


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řeby organizace, zakoupení parametrizovaného informačního systému a nastavení těchto parametrů nebo kompletní dodávka systému pomocí outsourcingu. Výběr vhodného způsobu provádí zadavatel a vlastní provedení svěřuje systémovému integrátorovi jako 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 či organizace musí disponovat dostatečnou personální a technologickou základnou pro zajiš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ůže stá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 rozsáhlou technologickou a personální základnu. Jedná se ve své podstatě o outsourcing

5.3


41

vývoje. Externí společnost vyvíjí systém přesně na míru při zachování všech výhod předchozího bodu. Náklady na systém jsou pochopitelně nižší. Problémem se však můž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ž je př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 jejich poří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ších forem pořízení informačního systému.8 Velkým problémem typových informačních systémů je nutnost adaptace a lokalizace na národní podmínky, protože většina tě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í systém přizpůsobit potřebám organizace na uživatelské úrovni – lze nastavit parametry systému tak, aby alespoň zhruba vyhovovaly příslušné organizaci. Jejich cena je však vyšší než u typových informačních systémů, protože i vývoj je nákladnější (více variant ovlivnitelných parametrem). Většina velkých společností zmíněná i v předchozím způsobu pořízení dnes přechází na vývoj parametrizovaných systémů pro jejich jednodušší 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 vypracová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 je odpově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 dodavatel zvolí řešení co možná nejlevnější (aby sám dosáhl uspokojivého zisku) a systém se nebude prodražovat. Současným největším problémem této metody je její novota, je třeba ji v praxi řádně a mnohokrát odzkoušet a získat nějaké pozitivní reference na dodavatele outsourcingových služeb. 8

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

5.4

5.4

Metoda řízení vývoje a provozu UIS

42


Vysoké školství je specifickým odvětvím, které se vždy vyznačovalo nedostatkem finančních prostředků, který ve své podobě ovlivňoval i personální zdroje (nedostatek pracovní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ých zdrojů a kvalifikace projektantů, analytiků, vývojových pracovníků a provozních operá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 se vkládaly do zakoupení typového informačního systému, příp. outsourcingu. Bohužel neexistoval na univerzitě nikdo, kdo by byl ochoten riskovat zakoupení typového systému a současně byl schopen provést adaptaci systému na univerzitu nebo univerzity 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á stabilita dodavatelů apod.), zvolila nakonec tvorbu systému vlastními silami. Dnes, s odstupem ř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áklady se 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ém zá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é je složené z pěti základních složek. Jedná se o vrcholové vedení sloužící pro styk s univerzitou (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 provozní 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 nedostatku pracovníků do jediné osoby – autora této diplomové práce. Ostatní složky jsou početnější především vlivem množství úkolů řešených v těchto skupinách. Nejpoč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

5.4


43

subsystémů včetně doplňkového software. Každý týden řeší tato skupina zhruba pět desítek úkolů a pracuje minimálně na třech rozsáhlých projektech. Podstatně menší jsou několikačlené skupiny datamanagementu (řízené Bc. Janem Müllerem), která zajišťuje realizaci datového modelu, iniciální plnění daty a hromadné datové úpravy během fáze zavádění, a skupiny provozu (řízené Ing. Hanou Netrefovou), která plní úkoly vyplývající z každodenního styku se systémovými integrátory i běžnými uživateli systému. Jednotliví pracovníci jsou dle aktuální potřeby alokování v příslušných sekcích, takže dochází ke krátkodobé migraci pracovníků na mí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ána s každým novým úkolem (i několikrát týdně). Tento způsob vnitřní struktury týmu se 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í hiearchická 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á pracoviš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ě, kdy se ústavy dělily na sekce a pracovní skupiny. Toto podrobné dělení bylo ale výnosem rektora 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 integraci univerzity jako celku a je rovnoceným partnerem vývojového týmu. Je přímým nadřízeným systémových integrátorů fakult a systémových integrátorů nefakultních pracovišť (druhé úrovně). V současné době vývojový tým jako své partnery uvažuje prá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ém pracovišti. Pro tento úkol si buduje rozsáhlou síť dvou typů pracovníků na všech pracovištích třetí úrovně spadající pod jeho fakultu (tj. na ústavech). Jedná se o tzv. OSSA (osoby spravující studijní agendu), což jsou de facto systémoví integrá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á-

5.4


44

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ým prohlíž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 integrovat 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 nefakultní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 byla vytvoř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 šablon nebo 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, problé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ému dlouhodobé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ě synchronizovat. Ve volném čase při čekání na ostatní pracuje vývojový pracovník opět na 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 systé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ádané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 dokumentace a projekčně-časový model (spotřebované personální zdroje a čas na řešení jednotlivý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ývoje a 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ů životního cyklu projektu. Základem je klasický model vodopádu, kdy základní cíle a jádro systé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 tohoto harmonogramu 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ším integrátoři získali základní představu o připravovaných funkcích. Poté je tento modul rozvinut metodou výzkumník, kdy integrátoři zpětně zasahují do vývoje modulu a průběžně požadují přepracování některých jeho částí. Tímto způsobem tedy vývojový tým vytvořil kombinaci všech čtyř základních metod životního cyklu projektu na 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ě vyvinuté a otestované moduly. Tímto způsobem lze nejrychleji odstraňovat vzniklé problémy a přizpůsobovat systém přáním univerzity (systémových integrátorů). Oproti metodě 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 jejich změ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á adaptace na požadavky univerzity a maximalizace využití dostupných zdrojů při minimálních nákladech. To nám umožňuje vyvíjet systém vlastními silami za ceny zhruba rovnocenné 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 provozu, kdy není možné předat provoz aplikací do rutinní správy univerzitě vzhledem k 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). Tento problé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 zanedbatelná.

5.5


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šechny pracovníky vývojového týmu (bez ohledu na výkon či kvalitu práce) lze rozdělit do tří kategorií podle financování a organizační příslušnosti.

5.5


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 Oddělení automatizace informační soustavy Rektorátu MZLU v Brně). Tito pracovníci jsou placeni podle standardních tabulek jako ostatní pracovníci univerzity a lze je motivovat 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 pracující zcela zdarma. U nich hrají roli pouze nepeněžní faktory. V současné době jsou přijímání všichni pracovníci již jen do třetí kategorie, přesto zájem o práci v týmu převyšuje poptávku (práce je sice dost, ale není dost techniky, prostoru a dalšího materiá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 jsou pozdě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 pracovníky s bohatými zkušenostmi z předchozího působení a předchozích informačních systé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 studenty (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 dostupnosti techniky studentům), vždy volné místo u počítače a příjemná atmosféra přátelského kolektivu vývojových pracovníků, který se věnuje i mimopracovním motivačním činnostem (plavání v pronajaté dráze, společné pracovní obědy, výjezdy, dovážka potravin z paletových prodejen, plánované promítání filmů, školení a přednášky, účast na vědeckých konferencích aj.).

6

ZÁKLADNÍ CÍLE UIS

6

47

Základní cíle UIS

Vzhledem k existenci celé řady proprietárních velmi decentralizovaných automatizovaných informačních systémů řešících desítky různých agend celoškolského, fakultní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 studia na naší škole (přechod ke kreditnímu systému ECTS je učinil nepoužitelným) přistoupilo 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í systé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 systémů, • zpřístupnění evidovaných údajů všem uživatelům, kteří údaje potřebují, v jejich nejaktuá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 (identifikač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 prorektor pro studium), které pro odborná rozhodnutí konzultuje Poradní komisi rektora pro rozvoj IS/ICT, jejímiž členy jsou vedoucí všech odborných pracovišť, které přichá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í podklady pro další rozvoj informačního systému. Systémoví integrátoři si mohou vytvořit vlastní stromovou strukturu pracovníků pro rychlou podporu jednotlivých pracovišť (ú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ího systému, konzultují řadu problémů přímo s vedením příslušných fakult (děkani, studijní 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ě jim pří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íku uč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 studentů, 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íst na kolejích studenty a řídí stravovací systém, • ostatní zaměstnanci univerzity – používají systém pro kontrolu svých evidovaných údajů, přístup k evaluacím pracovníků a komunikaci s ostatními zaměstnanci, 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é diskuzi stanoveno 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řeby studijních oddělení a oddělení, kde vzniká velké množství dat, je připravována také klasická klient/server aplikace komunikující s informačním systémem přes vhodný 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 faktu přihlédnout a navrhnout systém pro zjištění této jednoznačnosti, velká práce potom 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ěny a 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ý kontextový pohled pro pracovníky na všech stupních řízení – tj. byl implementován právní systém definující uživatele, skupiny uživatelů (s možností obsahovat opět další 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áva vztahují) – nyní je tedy možné určit, jaká oprávnění či role mají příslušní uživatelé či skupiny uživatelů pro konkrétní subjekty, • systém musí umožnit modifikaci datové základny na přání fakult bez zásahu vývojového týmu – tzn. že celý datový model je rozdělen do mnoha částí, ve kterých jsou identifikovány charakteristické objekty (např. uživatelé, pracoviště, předměty, čipové karty, tiskárny, dlouhodobé úkoly apod.), pro které jsou definovány ucelené systémy šablon umožňující předepsat na uživatelské úrovni strukturu 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ůsobit svým zvyklostem a svému vkusu – toho je dosaženo na jedné straně zcela konfigurovatelný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áhlou množinou parametrizace pomocí systémových politik (v tomto bodu se systém opírá o periodicky prováděné výzkumy mezi uživateli systému a v nemalé míře i o připravovanou disertační práci jednoho z vývojových pracovníků na téma Už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 univerzity 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řepracová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 systé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 informace potř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 sebou nese budování Univerzitního informačního systému, má pozitivní vliv nejen na kvalitu počítačové gramotnosti na naší škole, ale také na prestiži a dobrém jménu naší univerzity v naší zemi a dalších zemí v Evropě.

7

ARCHITEKTURA UIS

7

50

Architektura UIS

Vzhledem ke komplexnosti Univerzitního informačního systému je důkladně rozpracována základní architektura systému z několika hledisek. Tato architektura se odráží 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í), operač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 jejich propojení) a dále dva pohledy na architekturu centrální části UIS (provozního a 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


51

Na obrázku 6 je nastíněna globální technická architektura. Základní částí je právě UIS cluster, který je připojen přímo do páteřní sítě MZLU v Brně. Na tuto páteřní síť jsou připojeny také jednotlivá řídící PC distribuovaná po vybraných lokalitách v areálu (řízení přístupového systému, kamerového systému, jednotné autentizace apod.), a která jsou s UIS clusterem spojena pomocí šifrovaných IPinIP tunelů. Na páteřní síť jsou dále připojena dvě základní vývojová centra (místnost demonstrá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. Napojení 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 Lednice a Břeclav, kde se nachází síť Zahradnické fakulty v Lednici se dvěma řídícími body a ř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, na správný univerzitní server nebo do informačního systému). Proto je tento systém př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 Enterprise 220R osazeného dvěma procesory 360 MHz, 1 GB operační paměti a úhrnou diskovou kapacitou 54 GB vyhrazenou pro systém, SŘBD a vlastní data. Jako SŘBD je použit Oracle Standard Database 9i licencovaný pomocí EUNIS akademické licence 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 400 MHz, 640 MB operační paměti a 40 GB pevným diskem. Na tomto stroji je provozován operační systém Linux 2.4 (distribuce RedHat 7.2), programovací jazyk Perl 5.6, webový server Apache 1.3 s nádstavbami mod ssl a mod perl, firewall iptables, poštovní server qmail, synchronizace času ntpd a IDS (systém včasné detekce napadení serveru).

7.1


52

Oba stroje jsou navzájem propojeny základním 100Mbit full duplex síťovým switchem (5 portů pro budoucí rozšiřování). Aplikační stroj slouží zároveň jako firewall a řídící uzel sítě (celkem čtyři síťové adresy – Univerzitní informační systém is.mendelu.cz, Fakultní informační systém PEF pef.mendelu.cz, proxy brána pro databá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álovatelnosti vý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álohování, hlasové služby, běh více informačních systémů). Celé řešení bude montováno do 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é na 1.2 GHz a osazené 512 MB 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ělování požadavků (ověřují se techniky Round-Robin, Bandwidth detection, Random access 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ázku zakreslené switche jsou představovány jedním základním switchem Cisco Catalyst 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.2 GHz s 512 MB operační paměti. Tyto stroje jsou provozovány na operačním systému Linux 2.4 a zapojeny v clusteru pomocí software Linux Virtual Servers. Na strojích je provozováno stejné vývojové prostředí jako je uvedeno 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 750 MHz procesory, 4 GB operační paměti a v základní konfiguraci s 216 GB diskové kapacity (diskové pole). Oba stroje (plus rozšířená licence na SŘBD Oracle 9i) pracují jako redundantní cluster, který umožňuje převzít řízení jedním strojem v případě výpadku druhé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 40 GB pásek a jedna čistící), multiportovou kartou a sadou šesti hlasových modemů připojených na rotátor pobočkové ústředny (poskytování hlasových služeb). Tento stroj je zároveň 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 pomocí 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


Pod pojmem aplikační architektura myslíme základní softwarovou výstavbu celého informačního systému. Univerzitní informační systém používá klasickou třívrstvou architekturu, ve které je datová část realizována v SŘBD Oracle 9i, aplikační část pomocí webového informačního systému vystavěném nad webovým serverem Apache a programovacím jazykem Perl (konkrétní implementací mod perl) a šifrování spojení mod ssl. Prezentační vrstva je realizována jádrem systému v jazyce Perl a zobrazuje se v několika typech zařízení – základním je internetový prohlížeč HTML stránek, podporováno je ale i zobrazování na mobilních telefonech pomocí technologie W@P a pracujeme na hlasových službách dostupných na telefonním čísle 45 13 51 67. Všechny moduly, ze kterých je informační systém složen jsou dále dekomponová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, Evidence neschopenek apod.) a skripty (jednotlivé programové celky aplikací, např. Editace

7.2


54

údajů osoby je složena ze skriptů zobrazení údajů, editace údajů, vysvětlující nápově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é zapouzdř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í. Architekturu 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řeny systémy tvořící kostru UIS (nedílná součást systému, bez kterého nelze ostatní části provozovat) 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é.

7.2


55

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í funkce pak zajišťují personalizaci, autentizaci a prezentační vrstvu. Nejnižší částí zadních funkcí je API pro napojení na systém řízení báze dat. Jeho základem je DBI/DBD rozhraní jazyka Perl a obalující funkce, které zjišťují především identifikaci SQL dotazu 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é rozhraní. 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 obou uvedený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 části příp. na datově-logické úrovni se plánuje také zavedení celkového auditu změněných dat. Č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 automaticky 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 vytváření zástupných aplikací, které umožní systém lépe a rychleji využívat. Nad touto vrstvou je vrstva prezentační, která zahrnuje obohacení designu daty, doplnění základních navigačních prvků a portování příslušné funkce do alternativníh prostředí (např. na mobilní telefon). Poslední vrstvou je transparentní vrstva autentizace (a napojení na šifrovací modul webového serveru), která provádí nezávislou kontrolu 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 pro práci s netradičními typy dat). Pomocné systémy jsou pak ty systémy, které jsou využí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 potom definují 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ástin a obecnější pohled nabízí také [30]. Jádro UIS dokáže také zajistit běh aplikací mimo webové prostředí a realizovat tak dlouhodobé úkoly, konektory do jiných systémů a jednorázové konverzní systémy.

7.3


Veškerá data využívaná v UIS se nacházejí v databázi řízené systémem řízení báze dat Oracle Standard Database 9i. V této databázi je pro celý systém vyhrazeno jedno 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ři vý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é obsahují všechny evidované informace (datová báze má nyní velikost přibližně 1,5 GB). 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 A B C D E F K I M N O P Q R S T V W

význam dokumentace systému, TODO, řízení indexů a vývoje záložní a obnovené tabulky identifikační systém (karty, přístupy, kamery, jednotná autentizace) dokumentový server, diskuzní skupiny ekonomický systém, napojení na EIS (ekonomický informační systém) personalizace, designy, preference kmenové tabulky (personalizace, základní číselníky, právní systém) inventarizace, sklad menzy, stravovací systém, koleje a ubytování nástěnky, vývěsky systém objednávek a rezervací např. projektů, témat diplomových prací poštovní systém, jednotná pošta převzaté číselníky ze SIS (dle [14]) rozvrhy a rezervace učeben studijní systém, přijímací řízení tiskový systém věda a výzkum, životopisy, publikace, evaluace, granty řízení systému, logy a audit, dlouhodobé úkoly

7.3

57


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

prefix A B C I

význam agregovaná tabulka, která vzniká dlouhodobým úkolem nebo triggerem záložní kopie tabulky obnovená ze zálohy číselník indexová tabulka obsahující fulltextové vyhledávací řetězce

Kombinací obou prefixů s názvem tabulky vzniká konkrétní datová tabulka reprezentující entitu nebo asociace v datovém modelu – např. SC_PREDMETY představuje čí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 tabulce 3. Tab. 3: Užívané přípony

přípona SABLONA ATRIBUTY TODO HISTORIE

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

Tedy tabulka SC_PREDMETY_SABLONA je popisná tabulka struktury pro objektové 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 ANETE Kredit) příp. některé přípony rozlišují různé části datového celku (A_TODO_ představují 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árních klíčů. Rozšířením o přípony _T a další kombinace definují příslušné triggery nad 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 fyzický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ř. pohled KC_SUBJEKTY je určen pro budoucí rozsáhlé struktury subjektů práva v právním systé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

7.3


58

(čá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 aplikační zátěže na výkonné databázové servery a současně realizovat řadu operací při libovolné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 program dbMan, který umožňuje vývojovým pracovníkům ovládat databázi z konzolové aplikace. Tento nástroj je k dispozici všem uživatelům Internetu zdarma na síti CPAN (vyhledávatelné i z portálu Freshmeat.net). Umožňuje grafickou i textovou práci s databázi, podporuje vícenásobné spojení, transakce, placeholdery, makrojazyk, 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átované TEXové tabulky aj.) nebo importování CSV souborů přímo do parametrických SQL dotazů. Tento nástroj je denně používán ve vývoji a velmi se osvědčil. Nástroj vytvoř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řechod mezi prostředím OS Linux a OS Solaris, mezi různými verzemi SŘBD Oracle a mezi různými kódováními češtiny. Není to sice nástroj denního použití, ale je využitelný při komplikovaných přechodech. Díky tomuto nástroji mohl vývojový tým prové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 datové 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 CPAN a na portálu Freshmeat.net jej lze nálezt pod jménem svplus. Výstupy tohoto programu 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Ů

8

59

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é organizace Pionýr ČR), vedla k vytvoření aparátu popisujícímu funkce a způsoby realizace webových informačních systémů, tedy nestavových nelinerních síťových parametrizovaných informačních systémů (obvykle provozovaných v prostředí World wide web). 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ále vý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 Pazdziory z FI MU v Brně. Systém navržený podle úváděné teorie mj. řeší problematiku autentizace, auditování, modularizace, serializace, oprávnění, proměnlivého datového modelu, personalizace, 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 aplikoval uvedenou teorii na dvou zcela odlišných platformách (UNIX, Apache, Perl, Oracle a Windows, IIS, Delphi, Oracle) pro prostředí webu a W@Pu. Nyní probíhá aplikace na prostředí hlasových služeb. Jako databázový systém byl též několikrát použit PostgreSQL. S postupem času nalézáme stále obecnější aparát, který nám umožňuje efektivně 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 realizaci 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žívat informační systém v neočekávaném bodu (např. od konce sekvence požadavků), pokusil se o návrat v posloupnosti operací (tlačítko Zpět v prohlížeči) či zopakoval ně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 jednoznačnosti. Každý požadavek je označen jedinečným identifikátorem (např. číslem vygenerovaným z databázové sekvence) a toto číslo je zahrnuto do všech formulářů v odpo-

8.1


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, systém detekuje použití již použitého identifikátoru a operaci zabrání. Nevzniká tak duplicita 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 žádnou návaznost (podobně nemají pořadí ani vstupní bod – viz nelinearita a problémy s 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ěr dat – editace – kontrola – uložení) je pak nutné rozložit do izolovaných kroků a zajistit 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átil serveru (a tak nedošlo ke ztrátě dat). Nevýhodou tohoto způsobu je nutnost předávat pomě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é informace 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ých intervalech. V UIS jsou užívány obě metody, ale první metoda převládá pro svou jednoduchost 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 informač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 pro server Apache). Tiketování (jako metoda vystavěná nad odstraněním nestavovosti WIS) 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á autentizace zcela transparentně podle definovaných pravidel. Ovšem aplikace nedokáží

8.1


61

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ách nečinnosti odhlásit a zabránit tak jinému uživateli v nepovoleném vniknutí ze zapomenuté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 dokonce může být identifikátorem pro sklad). Pokud platnost tiketu vyprší nebo se aplikace rozhodne 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 bezpeč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á jen v definici vzhledu systému (designy, parametrizace výstupního chování), ale též v nastavení systému pomocí systémových politik (ovlivňují chování systému) a definici zástupných aplikací (umožňující vytvořit vlastní uživatelské aplikace pomocí předdefinovaný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 definované uživatelem (a případně sdílené mezi jednotlivými uživateli). Předpokládá se postupný vývoj až k definici zástupných aplikací, které umožňují nadefinovat si uživatelské rozhraní systému podle preferencí uživatele. Např. se automaticky nezobrazují dlouho nepoužívané odkazy, pokud k tomu nedá uživatel pokyn nebo je možné vytvořit úvodní stránku z vlastní nabídky odkazů, vytvořit rychlý přístup k aplikacím definicí zástupné aplikace obsahující základní dialogy nejpoužívanějších aplikací apod. Personalizací se zabývá budoucí disertační práce Ing. Hany Netrefové a diplomová práce Lukáše Bártíka. Jednotlivé problémy a způsob řešení v nich budou podrobně rozpracovány. Auditování Auditování představuje evidenci změn provedených v informačním systému – teorie WIS 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).

8.1


62

V současné době UIS podporuje sledování jednoduchého auditu metodou ZZ identifikace na úrovni smart funkcí datového modelu (vývoj se tedy tímto problémem nezabývá). Plánován je přechod na plný audit řízený databází, kdy bude mož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. Podrobně 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ých uživatelů – jak z hlediska bezpečnosti, tak z hlediska podpory uživatelů (často opakované sekvence kroků lze nahradit zástupnou aplikací, tápající uživatele je možno nasměrovat, proškolit, příp. jim nabídnout alternativní řešení problému). Teorie WIS nabízí jak úplné logování (vše a trvale), tak různé možnosti posuvného logování (rotují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ům nebo 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ýt interaktivní. 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 dlouhodobé jednorázové i opakované úlohy včetně explicitně vyvolaných úloh. Mechanismem 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 na jiné 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 ekonomického systému EkonFIS, do Knihovnického informačního systému, do přístupového systému DUHA, do systému Sdružených informací matrik studentů (SIMS), do systé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í na UIR-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í

8.1


63

systém. Rozsáhlé systémy potom tuto problematiku komplikují existencí hiearchie uživatelů (např. pracoviště, geografická příslušnost apod.). Teorie WIS nabízí několik typů právních systémů. Nejjednodušší právní systé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 skupině), 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í časové 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živatelé, 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živatele 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). Aby tito 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ů (delegátů) např. na úrovni ředitel – sekretariát. Tak může legálním způsobem přistupovat sekretářka ředitele do rodin aplikací Organizace času a Pošta, aniž by např. přistupovala k rodině aplikací Mzdy, jak by se určitě stalo při zabezpečení jejího přístupu sdí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čnost vývojářům a integrátorům (provozovatelům systému) umožňuje odhalit problémy vzniklé špatně nastavenými právy, špatnou definicí šablon, příp. podávat uživatelům rady 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é objekty 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é popisují atributy jednotlivých objektů v závislosti na hiearchii uživatelů a právním systému.

8.1


64

Teorie WIS také rozšiřuje definici šablon o tzv. mutované šablony (kdy lze uchovávat informace o jednom objektu v závislosti na mutačním klíči, např. informace o syllabu předmětu v závislosti na jazyku, tj. anglický, český, německý a ruský syllabus) 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, atributy), v podobě mutační šablony pak třírozměrnou strukturu (objekt, atributy, mutace). Speciální mutovaná šablona se nazývá obecně mutovaná šablona a umožňuje mutace přes množinu přirozených čísel (např. evidence extra bodů k přihlášce studenta na VŠ, kdy množina důvodů není dopředu známa). Právě využití šablon ve spojení s právním systémem umožňuje do WIS zavést maximální množství parametrizace systému. V UIS je šablonování využíváno ve všech nových aplikacích a postupně je implementováno i do aplikací starších. Jejich použití totiž umožňuje postihnout odlišnosti jednotlivých pracovišť na uživatelské úrovni. V současné době je v systému pět desí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 (definice formátů výstupních dat). Teorie WIS nabízí postup pro přípravu modulu umožňujícího definici sestav a formátů zobrazení pomocí značkovacího jazyka, který obsahuje 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. Nasazení formátů a sestav do UIS umožňuje jednotlivým fakultám přesně přizpůsobit prezentaci 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í parametrizace WIS (uživatelé s příslušným oprávněním mohou sami definovat další překlady systému). V UIS zatím není vícejazyčnost použita, ale tato možnost bude v průběhu tohoto a příštího roku implementována za předpokladu existence překladatelské skupiny (Ústav jazyků). Nutnost vícejazyčnosti vyplývá jednak ze studia zahraničních studentů na MZLU v Brně, ale také z důvodů snah většiny fakult o prezentaci informací v několika světových jazycích.

8.1


65

Systém výstupů a tisk Problematika tisku sestav na tiskárnách z webového prostředí je velmi komplikovaná. Postup vycházející z práce Bc. Pavla Šmerka z FI MU Brno byl zahrnut do teorie 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 programem GhostScript pro konkrétní uživatelem zvolenou tiskárnu. Na tuto tiskárnu je pak výsledek tištěn pomocí programu UNIX lpr nebo na sdílenou tiskárnu systému MS 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řipojení uživatele přes dial-up apod.). Modularita Pro dosažení maximální efektivnosti koloběhu návrh – vývoj – testování – provoz př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čet vý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 modernizovat systé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 architektuře UIS. Samodokumentace Nejvíce zanedbávanou částí při vývoji informačního systému je dokumentace (jak uživatelská, tak především vývojářská). Teorie WIS nabízí nástroje pro podporu už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 úrovní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ývojářů 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 komfortně 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 programovací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í zobrazová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 mohou vznikat 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živatelsky jednoduš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é vyhledá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ích formulářů v systému. V současné době teorie WIS definuje čtyři základní fulltextové indexovací techniky, především indexování podřetězců, indexování slov, indexování výrazů a indexová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 podoby praktické příručky popisující jednotlivé řešené aspekty s podrobnými postupy jejich 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 se nachází jak proprietární řešení uvedených problematik, tak aplikace postupů popsaných teorií. Druhou oblastí zájmu vývojových pracovníků bude vytvoření obecného generá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í problematiku obecných věcí a bude možné se věnovat vývoji skutečně podstatných částí informačních systémů, jako jsou výpočtové funkce, kontroly dat a aplikace jednoduše pořizující a opravující data. Tento generátor bude v první fázi vytvořen pro prostř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Í

9

67

Jednotlivé rodiny aplikací

Celý Univerzitní informační systém je rozčleněn do několika rozsáhlých modulů (Studijní 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, rozpracovaný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 letech 1998 až 2001, kdy byl zahájen vývoj Univerzitního informačního systému. Ten je 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 seznamu: • 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í, formulářů aj. • Anketa k předmětům – představuje modul aplikací určených k zpětné vazbě od studentů k učitelům (hodnocení předmětů studenty, posuzování došlých anonymních odpovědí, srovnání předmětů pro vedení fakulty a školy). • Dlouhodobé úkoly – představuje kompletní agendu dlouhodobých a opakovaných úkolů (tj. kontrolní sestavy konzistence, napojení na jiné informační systémy – především ekonomický informační systém školy apod.). • Dokumentační systém – obsahuje uživatelské i vývojářské návody, dokumentace jednotlivých modulů, slovníček odborných pojmů i dokument s často pokládanými otázkami; řada modulů pak obsahuje ještě vlastní kontextovou nápovědu pří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ými se studenti na tyto akce přihlašují. • Evaluace – umožňují vedení školy a fakult získávat informace o ústavech a dále vedoucím ústavu informace o vlastním sebehodnocení zaměstnanců, jde de facto o zhodnocení příspěvku osob k roli univerzity v rámci pedagogické a vědeckový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 informace o 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ímu systé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 karet ISIC a ITIC a také ostatních zaměstnaneckých a studentských karet používaných na naší univerzitě (všechny karty jsou vybaveny bezkontaktním čipem pro identifikač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 bezkontaktní identifikační technologií (s využitím karet studentů a zaměstnanců), dále umožňuje sledovat pomocí videokamery pohyb v různých částech areálů a zaznamená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 fotografiemi osob na MZLU, přes pracoviště, telefonní seznam zaměstnanců a místnosti po informace o studiu (programy, obory, specializaci, předměty, doporučené plány aj.). • Inventarizace – modul umožňuje zaměstnancům sledovat vybavení jejich místností a zadávat požadavky na přesun a přísun materiálu a vybavení mezi místnostmi a převody mezi pracovišťmi; umožňuje také sekretariátům ústavů, tajemníkům fakult a kvestorce sledovat a potvrzovat tento pohyb; v konečném důsedku pak umožňuje zkrátit dobu nutnou ke každoroční inventarizaci na minimum. • Katalog předmětů – umožňuje definovat, které předměty jsou v kterém období vyučovány, s přihlédnutím k prostupným studijním programům, nutnosti evidovat vícejazyčné syllaby předmětů, řadu ukončení předmětů včetně jejich kreditové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áci s Ú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 na naší univerzitě – ve formě krátkých vzkazů, oznámení a krátkodobých dokumentů 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 technických podmínek, tj. zajištění pohodlné práce s informačním systémem – podporuje 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,

9.1

Plánovaný projekt

69

• 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šem existujícím uživatelům – také je řada operací provedených v informačním systé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 jeho studiu a první zápis studentů na naší univerzitě – zajišťuje také prezentaci informací 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), podklady z 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í, kontrolu konzistence rozvrhu, zobrazování a tisk rozvrhů dle řady kritérií a rezervaci místností pro (nejen) zkouškové akce, ve druhé fázi bude subsystém podporovat 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ých a softwarových zdrojů (včetně licencí) mezi pracovníky univerzity, sledující dostupnost 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í celouniverzitních agend na nezávislý stravovací systém dodávaný externí firmou (atypizovaný hardware), zajišťuje konzistenci uživatelů, identifikačních karet (použitých též jako stravovací karty) a napojení úvěru ze stravovacího systému na 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 aplikací (Katalog předmětů, Studijní evidence, Informace o MZLU, Formáty a sestavy) je aplikace umožňující zobrazit a sázet informační brožuru s informacemi pro 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 informace o 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).

9.1

Plánovaný projekt

70

• Telefonní seznam – aplikace tohoto modulu umožňují evidovat přidělená telefonní čísla na úrovni jednotlivých ústavů a vytvářet telefonní seznam v elektronické i tištěné podobě. • Tiskový subsystém – tento subsystém zajišťuje sazbu a tisk výstupů ze všech ostatních modulů univerzitního informačního systému pomocí sázecího systému LaTeX; sází se do formátů PostScript a Protable Document Format, příp. je dokument přímo tištěn na síťové tiskárně nebo na tiskárně sdílené v systému Microsoft 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ší unviverzity – vědeckovýzkumnou činnost; jeho součástí je systém pro evidenci vícejazyč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ý systém je využit jako podklad pro modul Evaluace a data z tohoto systému jsou též 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ány vývoje a stavu jednotlivých komponent. • Zkušební zprávy – další částí studijního systému je kompletace výsledků jednotlivý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ů, studenti jsou informováni o zadaném hodnocení a sami mohou kontrolovat, zda se shoduje hodnocení v jejich výkazu studia (indexu) a v informačním systému a včas si tak zajistit opravu případných nedostatků; do budoucna je plánováno potvrzová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, kdy student přechází do nového období; dochází zde k potvrzení operací provedených v registraci (příp. změně struktury zapisovaných předmětů), kontrole nutně zapisovaný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ých studentů v jednotlivých předmětech řadu údajů, např. docházku, průběžné bodová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 studentů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 ve fázi analýzy a není dosud jasná jejich přesná specifikace.

9.2

9.2

Aktuální stav vývoje

71

Aktuální stav vývoje

V současné době (duben 2002) je kompletně dokončeno jádro Univerzitního informačního systému a moduly Dlouhodobé úkoly, Evidence místností, Formáty a sestavy, Identifikační průkazy, Identifikační subsystém, Informace o MZLU, Katalog předmětů, Přijímací řízení, Stravovací systém, Studijní evidence, Tiskový subsystém a Vývoj UIS. Některé moduly ovšem budou v budoucnu přepracovány, protože dosud nejsou implementovány všechny požadavky nebo představy o činnosti příslušného modulu. 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í semestr 2002) jsou v plánu též moduly Elektronické přihlašování na zkoušky, Nástěnky a 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ím informač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 zdokonalování systému, implementaci nově vymyšlených modulů a přípravu na analýzu a implementaci ekonomického informačního systému (pravděpodobně externí dodávka př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 Univerzitního informačního systému – Studijní agendy. Tato analýza vychází z většiny publikací, které byly publikovány o Informačním systému Masarykovy univerzity (v seznamu literatury autoři Brandejs, Pazdziora, Misáková, Hollanová) a vlastních zkušeností a myšlenek.

10

ZHODNOCENÍ DOSAVADNÍHO VÝVOJE

10

72

Zhodnocení dosavadního vývoje

Dosavadní zkušenosti z používání předchozího Fakultního informačního systému i nového Univerzitního informačního systému nás přesvědčují, že se univerzita vydala 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ůže se 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 patrno, jak se vyvíjí situace jednotlivých studentů, vyučujících a předmětů v průběhu období (roku či semestru), nemusí čekat na sumarizaci dat jednou za čtvrtletí jako v předchozích systémech. Zavádění kreditního studijního systému by bez univerzitní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ém místě. Jen tak bylo možné zabránit duplicitám, zbytečnému vyplácení dotací na stravné 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ích agend. 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ývojovému týmu rozsáhlou podporu v jejich snahách o rozvoj a zdokonalování UIS. Proto také podporuje cestu vedení vývojového týmu na konferenci EUNIS 2002 do Porta a úč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ý, finanční a mzdový systém, systémy pro oběh dokumentů) a zavádění nových technologií (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 nestandardní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áříme především pro ně. Další oblastí naší činnosti je další automatizace agend především studijní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ěh dokumentů). Tuto agendu lze jistě automatizovat. Původní Fakultní informační systém Provozně ekonomické fakulty nebyl přenositelný ani do vícefakultního provozu, ani na jinou instituci. Proto i jedním z předpokladů při návrhu nového systému bylo vytvoření takového datového a funkčního modelu, aby bylo možné systém přenášet do prakticky libovolného provozu. Tento ná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ém a 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 evidovaný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 se dvěma dalšími českými vysokými školami, které o systém příp. o metodiku vývoje a 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 Masarykovy univerzity a Studijní agendu Západočeské univerzity) z hlediska zájmu o 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ůsobem zvýšit produktivitu při tvorbě Univerzitního informačního systému. Vývojový tým se zabývá skutečně inovativními úkoly a rozšiřuje funkčnost systému pomocí smysluplný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ňovat chování systémů pro jejich subjekty (pracoviště). Vývojový tým nemusí do tohoto procesu zasahovat. Celý systém je postaven modulárně a využívá mnoho předpřipravených komponent 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ích modulů (dlouhodobé projekty), přičemž vývojové sekce spolupracují se specializovanými sekcemi datamanagementu, provozu či podpory uživatelů. Každá sekce je tak odpově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áce mezi č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ývojové 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 jednotliví vedoucí sekcí, vedoucí realizace a vedoucí vývoje mohou postupně kontrolovat vý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ěn př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 pracovníků, postup práce na dílčích projektech, pracnost projektu, stav projektu, určovat priority či sledovat problémy při vývoji vznikající. Lze tímto způsobem masivně pracovat na 200 paralelních projektech při 20 pracovnících. Řada projektů je totiž ve stá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í nedostatky užívaného software (především RDBMS Oracle) – jedná se o databázovou konzoli dbMan (volně dostupná na Internetu), dokumentační nástroj SchemaView Plus (dostupný na síti CPAN), zálohovací software a fulltext indexační engine SuperIndex.

10.3


Vývojový tým průběžně zjišťuje odezvu na zavádění nových funkcí u uživatelů systému. Zpracoval jednoduchý dotazník, ve kterém se mohl anonymně vyjádřit libovolný 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 úzkou množinou osob (méně než deset osob) a dostává podklady v předzpracované vytříděné podobě rozčleněné podle priorit. Řada rutinních úkolů se tak přesouvá na jednotlivé 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 dat a možnost delegovat oprávnění uživatelů na další uživatele v rámci jejich pole pů-

10.3


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ů či doktorandy. Tato metoda není příliš podporována, ale je možná pro řešení akutních problémů počítačové indispozice (neschopnosti užít jej k přípravě nutných dat).

11

11

ZÁVĚR

76

Závěr

Při vývoji Univerzitního informačního systému na MZLU došlo k vytvoření velmi progresivní technologie pojmenované teorie webových informačních systémů. Tato technika v kombinaci s rozsáhlými zkušenostmi vývojářů systému umožnila vytvořit informač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řehodnocení postojů k automatizaci celouniverzitních agend a umožnil jednání o inovaci takových složek, jako je systém přidělování místností, inventarizace u koncových uživatelů, strhávání finančních částek za stravování ze mzdy či sdělování výsledku př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 budoucnu integrovat do UIS ekonomický systém, vytvořit systém podpory distančního vzdělávání budovaný naší univerzitou ve spolupráci s VUT Brno a UTB Zlín či zavést systém jednotné autentifikace uživatelů v síti MZLU k počítačům nebo sjednotit poč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 se strategickým, taktickým, operativním i krizovým řízením vlastního projektu. Z tohoto 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ému studiu 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

12

LITERATURA

77

Literatura

[1] Brandejs, M. – Hollanová, I. – Misáková, M. – Pazdziora, J. Univerzitní 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. Administrative 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-house Developed 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 pro univerzitu 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 RUFIS 1999. 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ých a 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 elektronickou 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 systé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 Based on 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 Publishing, 1996. 260 s. ISBN 80-8169-436-2. [22] Pecinovský, R. – Virius, M. Objektové programování II. Praha: Grada Publishing, 1996. 264 s. ISBN 80-8169-436-3. [23] Riordan, R. M. Vytváříme relační databázové aplikace. Praha: Computer Press, 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 jejich aplikace. Brno, 1994. [25] Rybička, J. Konstrukce testů ve výukových informačních systémech. In Informační systémy a jejich aplikace. Brno, 1995. [26] Rybička, J. Problémy implementace výukových informačních systémů. In Informač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 Firma a 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. In Studnice IX. Brno: Konvoj, 2002. In press. [30] Šorm, M. – Dařena, F. University information system at Brno Mendel University of Agriculture and Forestry. Brno: MZLU, 2002. Submission to EUNIS Elite 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 Information System. Edited by EUNIS. Brno: VUT, 2001. 158 s. A Handbook. ISBN 80-214-1837-0.

Přílohy

A

A

UKÁZKA ANALÝZY STUDIJNÍ AGENDY

80

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ího informač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 systé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ému urč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 podstatnou funkci 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ému univerzitního informačního systému Masarykovy univerzity, na jehož vývoji jsem měl možnost se podílet. Při analýze jsem přihlížel rovněž k tomu, že jsem reprezentantem největší skupiny uživatelů – studentů – a při své každodenní práci mohu naslouchat problémům dalších velkých skupin uživatelů – učitelů a studijního oddělení. Návrh se snaží zjednodušit práci všem těmto skupinám uživatelů, i když jejich požadavky jsou často protichů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 rozvoje na začátku vývoje informačního systému, kdy bylo nutno co nejrychleji vytvořit provozuschopné 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 mnohem 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 studiu 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ší univerzity prakticky 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ému je již koncepce období pojata plně a důsledně ve všech aplikacích včetně Katalogu př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 naznačím možnosti, které systém přinese jednotlivým skupinám uživatelů.

A


81

Koncepce období Veškerou dobu existence systému lze rozdělit na řadu i nestejně dlouhých období. Je teoreticky 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ým rokem – tj. ke dvěma nesouměrným semestrům tvořícím jeden rok. Jeden semestr je obohacen o řadu atypických akcí, jako je přijímání ke studiu, úprava Katalogu či stipendia a přidělování kolejí, druhý semestr je naopak bohatší o zkušební zprávy a uzavírání ročníků spojené s postupy. Ideální souměrnosti obou částí (hlavně díky kolejí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 daném období, ale předchází mu určitá doba nazývaná předobdobí, analogicky na konci období (tzv. poobdobí, které je mnohem kratší než předobdobí). V předobdobí dochází například k již zmíněnému přijímání do studia, v poobdobí naopak k postupům studentů 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ředcházejícího či některého jiného zvoleného období, čímž se zajistí stejné výchozí podmí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 kterém dochází ke studiu studentů. Po ukončení a uzavření období by se již nemělo data modifikovat. Konec předchozího období nemusí a ani nebývá nutně začátkem nové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ího ročníku vlivem změn z Ministertva školství, mládeže a tělovýchovy by mohlo být jedním z důvodů). Katalog předmětů Katalog obsahuje veškeré předměty, které se na fakultě či potažmo univerzitě někdy vyučovaly (včetně aktuálně vyučovaných předmětů). Data v Katalogu předmětů jsou uchovávana s ohledem na příslušné období. Rozlišujeme přitom období veřejná a neveř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ého orgá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

A


82

garant propojí učitele na příslušnou rozvrhovou akci v rozvrhu svého předmětu, dostá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, údaje o 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 II vyž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 zakreslena, 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 studium na 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í na př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šak oboje), což ovšem samozřejmě dostaneme tranzitivitou z podmínky neslučitelnosti dvou předmětů. Pro korektní průchod studiem je také třeba určit, že příslušný předmět je povinný pro Státní zkoušku – zde lze zavést prerekvizitu Státní zkoušky z daného okruhu (informatiky) na Státní zkoušce jako takové a navíc závislost Státní zkoušky příslušného okruhu na tomto předmětu. Je jisté, že takový strom závislostí není jednoduché sestavit a že je nutná spoluprá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 je ještě o něco složitější zavedením vazeb „a současně se studujeÿ, negací či snahou o konkrétní určení, kdy má být předmět studován (např. ne v prvním ročníku, tedy zá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ředměty ke studiu mezi fakultami (tzv. vyvážení předmětů mimo fakultu), protože pro zapsá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-

A


83

tou výuky díky slabším vědomostem některých studentů. To je i jeden z cílů nového Studijní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 standardu ECTS, 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ákup předmětů v daném období a na Stromu závislostí předmětů, čímž se mu určitým způ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 vlastního studijního plánu pro další období, je mu provedena registrace předmětů podle standardní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, proto už mohou být některé skupiny ve výhodné časové termíny zaplněny. Místo pro standardní průchod je vždy zajištěno – není tedy nutné se o nic starat, student však nedostane žá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. Souběž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 vlastnímu zápisu přijatých uchazečů a k imatrikulacím. To vše provází značná agenda s 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, kdy si studenti mohou zapsat libovolné předměty (přičemž preference zájmu jsou brány z 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ášejí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 se zú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ého období. Navíc lze systém doplnit o řadu dalších aplikací, např. Stipendia provázející

A


84

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, vyváž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 akademické obce. Vše začíná evidencí přihlášek ke studiu v databázi uchazečů. Po uzavření přijímání přihlášek se sestaví výstup pro matriku studentů a nad databází lze provozovat nutné agendy související s přijímacím řízením (rozesílání dopisů a informací, přehledy, vlastní tvorba přijímacího řízení, odhad potřebných míst na kolejích apod.). 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 aplikaci pro prezentaci výsledků přijímacího řízení). Tato situace se může opakovat několikakolově. 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é databá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, tisk prvotní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 formou registrace podle předem daných šablon standardního průchodu studiem. V novém systému UIS (stejně jako ve stávajícím FIS) bude k dispozici nástroj, pomocí kterého si student může stanovit, o jaké předměty má v novém období zájem s přihlédnutím ke Stromu závislostí a případně k Vyváženým předmětům mimo fakultu (tj. lze si zapsat 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 ze Standardního průchodu studiem. Na základě údajů z registrace může být sestaven

A


85

rozvrh. Druhou fází registrace je tzv. předzápis, který tento rozvrh potřebuje pro své provedení. Do předzápisu postupují studenti již podle výsledků dosažených na základě zadaných Zkušebních zpráv z předchozího období (tedy až těsně před samým začátkem nového období, po skončení předobdobí). Zredukovaná množina studentů si zapisuje předměty zvolené v registraci (příp. i jiné, pokud jsou volné kapacity a bude toto dovoleno novým Studijním a zkušebním řádem) a určuje si, do kterých skupin chce patř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 pro vš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 velmi složité algoritmické situaci nelze při automatickém doplňování skupin brát v potaz křížení rozvrhových akcí apod. Studenti by se tedy ve vlastním zájmu měli účastnit registrace 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 neprovedení 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říklad rozvrhy, protože si sami mohou tímto způsobem rozvrh ve velké míře ovlivnit a jsou tedy 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ím oddě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 vedením fakulty apod.). Rozvrhy Za zamyšlení stojí i samotná problematika rozvrhů. Po mnohých debatách jsme dospěli k názoru, že počítačem sestavený rozvrh nemůže splňovat kritérium optimality, protože toto kritérium nelze přesně vyslovit (každý rozvrh totiž obsahuje něco ve 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í rozvrhový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 automaticky zpracovatelné podoby lepší způsob. Nabízí se několik řešení – provádět sesta-

A


86

vení ručním způsobem, ovšem v automatizované počítačové podobě. Bohužel velikost současných obrazovek v nižších cenových relacích nepřesahuje výrazně dvacet palců, což je pro zobrazení rozvrhu v přehledné podobě málo. Velkoplošné obrazovky s ú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řechá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 do kó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čnosti by 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ým zář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í mohlo pů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ÿ. Tato pomůcka umožňuje manipulovat s předměty v prostoru. Dalším krokem by pak mohla být senzorická rukavice apod. Jako řešení nelze zavrhnout také možnost nahradit 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šak kvalita 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řenosu návrhu do informačního systému, ale i při kontrolách správnosti rozvrhu, při mož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. Vzhledem k tomu, že by podobné zařízení mohly sdílet všechny čtyři fakulty, lze se dostat u ř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ím kole 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ány předměty z tzv. šablon, které si vytváří studijní oddělení.

A


87

Celá část prvního kola se pro studijní oddělení časově zkrátí na jeden den, což je proti 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 kontrolovat proti 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í bude znač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ém studiu ve vlastním průběhu období. Dokonce ani učitel, pokud si nevede nějakou agendu 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šek apod. 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 sledovat z tohoto Záznamníku relevantní údaje o své osobě. Tyto údaje pak může získávat i 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 neschopenek a ostatní učitelé tak mohou snadno zjistit, které absence studenta jsou podloženy dokladem na studijním oddělení. To je ideální úkol pro Záznamník učitele a agendu studentů. Dalším nástrojem pro studenty je potom přehled o aktuálních zadaných známká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žít jednak jako myšlenky domácího cvičení, ověření znalostí, tak i k bodovaným testům přímo v příslušné učebně ve škole. Možnosti takového pojetí výuky jsou zatím nedozírné. Záznamník učitele Nejzajímavější aplikací pro učitele je Záznamník učitele. Jedná se o aplikaci zastřešující veškeré operace učitele ve vztahu ke studentům, ke studijnímu oddělení

A


88

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 univerzity 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řístup ostatní 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 takto sdíleny. Vyučující si tak může udržovat privátní agendu a jednoduše přenášet data mezi 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ěžnou prací 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ě oslovovat skupiny studentů či všechny studenty, kteří mají předmět zapsán. Podobných aktivní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 vztah mezi těmito listy a Zápočtovým listem. Pomocí Kontaktního listu, Nástěnek a Terminář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). Tento vý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ůže jen osoba se zápočtem). Výsledkem zadávání Zkouškového listu a užívání termináře zkoušek je potom navržená známka na Zkouškovém listu, která může být opět zkouš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 dovoleno nahlížet vedením fakulty (aby mohl například studijní proděkan rozhodovat a měl k dispozici dostatek údajů).

A


89

Pro zjednodušení práce se Záznamníkem budou vytvořeny desítky standardních typů 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živatelům, kteří chtějí využívat elektronický Záznamník maximální měrou (a tím minimalizovat svoji papírovou agendu). Záznamník může přijímat například i elektronicky odevzdávané případové studie a protokoly a sledovat datum a čas jejich odevzdá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 lze zveř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 ankety pro 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ých té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 anketynebo anketu konkrétního předmětu. Po využití kódu pozbývá kód platnosti. Studenti si 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čujícím apod.). Toto odesílání probíhá zpožděně z důvodů bezpečnosti (učitel může zahlé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á otevř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í agendy studia. 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 System). Na druhou stranu poskytne učitelům chybějící nástroje a přehled o dosažených studijní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.

A


90

Jako řada jiných změn, přinese i implementace tohoto systému zřejmě řadu komplikací z hlediska nepochopení koncepce, čemuž se budeme snažit zabránit napří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 takto investovaný č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

B

GRAFY VYUŽITÍ FIS A UIS

91

Grafy využití FIS a UIS

Oba budované informační systémy evidují průběžně všechny dosud provedené operace (již více než 4 miliony operací za dobu svého provozu). Každou noc jsou zpracová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 uplynulé době (souhrnný graf přístupů od uvedení systému FIS v březnu 2000 do provozu, 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ími mě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ěr operací uvnitř systému (po přihlášení) vůči všem operacím. Také přístupy vývojové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 rozhraní), 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ě).

B


92

Další graf na obrázku 11 zobrazuje poměr užívání obou systémů podle jednotlivý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 – je patrný 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í na univerzitě 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í.

B


93

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 studenti (skupina s největším počtem osob). Zajímavé je ale vztáhnout tyto hodnoty k počtu uživatelů příslušné skupiny užívající UIS (u uživatelů ze světa je počítán poč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 jednoho uživatele

C

C

VYBRANÉ UKÁZKY APLIKACÍ Z UIS

94

Vybrané ukázky aplikací z UIS

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

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

C


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

95

C


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

96

C


Obr. 17: Informace o osobě na MZLU

97

C


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

98

Univerzitní informační systém

Recommend Documents