Felsőoktatási Informatikai Infrastruktúra Felmérése

A FI projekt

Uherkovich Péter, uhi@ipi.jpte.hu
Janus Pannonius Tudományegyetem

Abstract

Survey of Higher Educational Information Infrastructure

As an initiative of the Ministry of Culture and Education, the HUNINET Association has started a project for Surveying of Higher Educational Information Infrastructure in Hungary. The executive stuff of the project has been established including local experts at the Janus Pannonius University, Pécs. The central database has been made here on a Digital Alpha server using Oracle database system. In order to success the most up-to-date technology was put in the action. Then survey touches 89 institutions. At the end of may some overview results will be expected. The results will be published with the permission of the Ministry of Culture and Education. The steps of completing of the project, the applied technology is presented. The techniques advancing the success and the arose problems are discussed. This analysis of project can be instructive for other similar data acquisition projects.

1. Bevezetés

1.1 Előzmények

Az MKM kezdeményezésére és a HUNINET egyesület indított egy projektet, amely a Felsőoktatási intézmények informatikai infrastruktúráját hivatott felmérni. A projekt vezetését az MKM egyetértésével a HUNINET Elnöke által felkért személy végzi. Munkájában a HUNINET tagintézmények képviselôibôl álló 8 fôs Operatív Bizottság (OB) támogatja, amelynek tagjai a felmérés során egy - egy intézménycsoport részére a területfelelôsi, szakmai konzulensi feladatkört is ellátják.

Az OB összeállított egy kérdőívet, amely tartalmazta az MKM informatikai infrastruktúrára vonatkozó kérdéseit. A kérdőív volt az adatbázistervezés és a lekérdezések tervezésének kiindulópontja.

1.2 A projekt fő feladatai

2. A siker titkai

A következőkben azt mutatom be, mely dolgokat tartottuk a legfontosabbaknak a projekt sikerének érdekében.

2.1 Kommunikáció a partnerekkel

A kommunikáció egy sok résztvevős projekt esetén a legfontosabb. Hiába készítünk kifogástalanul működő rendszert, ha nem tudjuk megértetni magunkat a külső partnerekkel. Ennek érdekében az alábbi eszközöket vetettük be:

2.1.1 Egységes design

Mindenekelőtt "nevet adtunk a gyereknek". Sokkal könnyebb beszélni róla, és könnyebben kialakul a partnerek fejében egy jól körülhatárolt kép a projektről: mi tartozik oda és mi nem. A jó név rövid, köze van a megnevezett dologhoz és órákig vagy napokig tart kitalálni. Így keletkezett a FI név is. Ebből rögtön adódott a grafikai megjelenítés: egy nagy görög F betű.

A következő lépés egy egységes (grafikai) design. Így a projekthez tartozó termékekről rögtön szembeötlik, hogy az a projekthez tartozik. Ezt az egységes design-t használtuk a projekt Web lapján, a kibocsátott adatgyűjtő program ikonjaiban és az online dokumentációban.

2.1.2 World Wide Web

Bár a felmérés tárgya éppen az informatikai infrastruktúra volt, éltünk azzal a nyilvánvaló feltételezéssel, hogy intézményeink nagy része tűrhető minőségű hálózati kapcsolattal rendelkezik. Erre vonatkozó adatok egyébként a Hungarnetnél is hozzáférhetők. Napjainkra egyik leghatékonyabb (tömeg)kommunikációs eszközzé válik a World Wide Web, tehát ezt a közeget semmiképpen nem hagyhattuk figyelmen kívül. Aki képes Web elérésre, szívesen teszi, hiszen mindenki, még gyakorlottabb Net-surfölők számára is lenyűgöző a dolog közvetlensége. Másrészt technikailag könnyen megoldható a legkülönbözőbb típusú infromációk naprakész közzététele. A Web lapon a projekt hátteréről, haladásáról, olvashattak az érdeklődők, hozzájárulhattak ötleteikkel az adatbázis kódszótárához, tehettek teszőleges megjegyzéseket és kérdéseket, letölthették az elkészült rendszer próba- és végleges változatatait, az ezekhez kapcsolódó segéd adatokat. Az összegyűjtött adatok lekérdezése is (technikailag) megoldható ugyanitt.

2.2 Adatbázis

Az adatbázis célnak leginkább megfelelő megtervezése szükséges technikai feltétel. A tervezés során az SSADM rendszertervezési elveket is részben felhasználtuk. Az adatbázissal szemben támasztott legfontosabb követelmények:

A lekérdezhetőség tekintetében az volt az álláspontunk, hogy gyakorlatilag mindent le lehet kérdezni, ha az információ "benne van" az adatbázisban. Ezért az adatok szerkezetében hagytuk a többi szempontot érvényre jutni. Így az SQL lekérdezések helyenként elég bonyolultak lettek.

Az utolsó két szempont működését jól megvilágítja az a dilemma, amely a számítógépek és a hálózati szegmensek kapcsolatának felmérése körül adódott. Mivel a számítógépeket és a hálózati szegmenseket is össze kellett gyűjteni, logikusnak látszott, hogy összegyűjtésre kerüljön kapcsolatuk is. Ez azonban az adatgyűjtők munkáját jelentősen megnehezített volna, a kiinduló kérdéshalmazban pedig nem szerepelt olyan kérdés, amelynek megválaszolásához ez az adat hozzájárulhatott volna. Így végül ezt a kapcsolatot elvetettük.

Az intézményi adatgyűjtő szoftver adatbázisa és az ebből keletkező központi adatbázis lényegében azonos szerkezetű, ez utóbbi csak optimalizálási okok miatt tartalmaz további mezőket.

2.3 Időbeli ütemezés

A projekt lefutásának gyorsítására az adatbázis megtervezését követően azonnal kibocsátottunk egy papír alapú adatgyűjtő űrlap-készletet, a hozzá tartozó részletes útmutatóval. Az ötlet alapja az volt, hogy az adatgyűjtés során mindenképpen be kell járni az intézmény helyiségeit, ezt egy kisebb papírcsomóval a hóna alatt könnyebben megteszi az adatgyűjtő, mint az adatfelvivő munkaállomással. A módszer másik előnye az időnyereség: az adatfelvivő program még készül, de az adatokat már gyűjtik. Az adatfelvivő program az űrlapoknak megfelelő sorrendben és struktúrában kérte az adatokat, hogy az adatrögzítést a lehető leggyorsabban lehessen elvégezni. Ennek ellenére a kibocsátást követő 3 hét alatt az adatbázisoknak alig negyede érkezett be.

2.4 Érdekeltté tétel

A végeredmény (a jelentés) minőségét alapvetően meghatározza a bemenő adat minősége. Közismert a tétel: szemét be - szemét ki. Kevés eszköz állt rendelkezésünkre a bejövő anyag minőségének befolyásolására. Valahogyan mégis szerettük volna elérni, hogy legalább mennyiségileg tükrözze a visszaküldött adat a tényleges eszközparkot. Ennek érdekében dokumentációinkban több helyen is hangsúlyoztuk az adatok felhasználási célját. Jelen esetben ez - az MKM szándéka szerint - a további MKM által koordinált pályázatok elbírálása, továbbá az infrastruktúra működtetésére szánt költségvetési támogatás meghatározása volt. Ennek tükrében kértük az adatokhoz az intézményvezető aláírását. Nos, egy elektronikusan rögzített adatbázist ma még nem tudunk aláírni, ezért ezt csak a kinyomtatott listával tehettük meg.

Ugyanide kívánkozik az a gondolat is , hogy megfelelő minőségű adatot az infrastruktúrát ismerő szakember szolgáltat. Ezért az intézményvezetőket arra kértük fel, hogy jelöljék ki a fentieknek megfelelő szakembert, aki az intézményi adatgyűjtést vezeti. Az esetleges további munkatárasakat pedig ő gyűjtse maga köré. Az üzemeltetésért felelős szakembernek az is érdeke, hogy az MKM-nél a valóságnak megfelelő kép alakuljon ki az infrastruktúráról. Továbbá éppen az adatgyűjtés segítheti őt abban, hogy saját információit is pontosítsa az egyébként sokhelyütt spontán és öntörvényű fejlődés következtében kialakult állapotokról.

3. Technológia

3.1 Projektvezetés

A projekt méretéhez igazítva. Alkalmazott szoftvereszközök:

3.2 Rendszertervezés

Alkalmazott eszközök:

SSADM módszertan / gyalog

Az SSADM alkalmazhatóságának korlátai

Például:

3.3 Adatbáziskezelő

A FEFA 1208. sz. projekt (KEFIR projekt) keretében a JPTE mint gesztor intézményhez került DEC alpha szerver és Oracle adatbáziskezelő azonnal kínálkozott, mint központi adatbáziskezelő. Ezt a szervert a JPTE - eredeti céljának megfelelően - az új tanulmányi rendszer felépítésére, bevezetésére használja, kapacitása azonban lehetővé teszi a FI projekt adatainak tárolását is. Az Oracle kétségtelenül a piacon található adatbázis kezelők legmagasabb kategóriájába tartozik.

3.4 Fejlesztői környezet

A fejlesztői környezet kiválasztásakor a következő szempontok játszottak szerepet:

Mivel az egyetemen rendelkezésre álló Borland Delphi fejlesztőrendszer önként adódott, csapatunk tapasztalatokkal rendelkezett vele szemben, továbbá a fenti követelményeknek megfelelt, más lehetőséget érdemben nem vizsgáltunk.

4. Problémák és eredmények

4.1 Kapcsolattartás

A WEB lap olvasottságára az azon keresztül érkezett kérdések, hozzászólások, valamint az ott elhelyezett intézményi rendszer (próbaverzióinak) letöltési aránya utal. Ez a vártnál alacsonyabb volt, de nem jelentéktelen. A megjegyzések, kérdések rovaton át összesen 25 darab hozzászólás érkezett. Az adatfelvivő programot az intézmények 22 %-a töltötte le.

Mit lehetett volna jobban csinálni:

4.2 Termék kibocsátás

A gondos tervezésnek és tesztelésnek köszönhetően mindössze 4 változatot bocsátottunk ki: ez kellően kevés, ezt jobb belső teszteléssel is alig lehet lejjebb szorítani. Az elektronikus letölthetőség lehetővé tette, hogy kipostázás előtt egyes intézményeknél is tudtak tesztelést végezni, így a postán csak az utolsó változatot kellett kiküldenünk. Ez az eljárás jelentős költségcsökkentő tényező volt.

4.3 Installálás

Változatos, de egyedi problémák merültek fel:

A Borland Database Engine gyári installálókészletét kellett először futtatni, és utána külön telepíteni magát a terméket.

A legtöbb installálási és működési hiba a helyi rendszer (Windows) hibájából származott, újrainstallálásakor az ilyen hibák rendszerint elhárultak.

Több olyan kérdés, fennakadás előfordult, amely nem következett volna be, ha elolvassák a dokumentációt. Ez többféleképpen is rendelkezésre állt, és erre a tényre a kísérőlevél, Web-lap külön felhívta a figyelmet. Az installáló lemezen az online dokumentáció (Windows help fájlok) nem tömörített formában szerepeltek, hogy akár a telepítő lemezről is meg lehessen azokat nyitni, installálás előtt. Természetesen a szokásos README.TXT fájl is tartalmazta a telepítés szöveges útmutatását.

4.4 Adatfelvitel

A telepített program használatában felmerülő nehézségek szintén a dokumentáció olvasatlanságából származtak, pedig az online help rendkívül részletesen, mezőszinten, környezetfüggő módon tartalmaz részletes útmutatást. Csak az F1 gombot kellett volna nyomni, de ha valakinek ez mégsem jutna eszébe, az űrlapok nagy méretű "Help" gombokat is tartalmaztak.

4.5 Visszaküldés

Az adatok visszaküldésére többféle technológia állt rendelkezésre, ezt a leleményes intézmények megtoldották néhány saját ötlettel. Az alapvető módszer floppy lemezen, postán. Kiegészítő lehetőség volt ftp-vel küldeni. Egy csak írható direktorit bocsátottunk rendelkezésre. Volt olyan túlbuzgó intézményi megbízott, aki Excel táblába külön begépelte az adatokat és ezt küldte vissza kinyomtatott formában.

4.6 Felvitt adatok minősége

Erre vonatkozólag a cikk írásakor még csak kevés, szúrópróbaszerű ellenőrzés eredménye alapján tudok előzetes következtetést tenni. A legjelentősebb probléma itt is a dokumentáció el nem olvasása. Ez itt súlyosabb hiba, mint a telepítésnél, hiszen a hibát feltehetőleg már a program kibocsátása előtti adatgyűjtéskor követték el. Találtam olyan intézményt, amely "külső" perifériaként felvitt minden beépített floppy meghajtót. A hiányzó adatokra nehéz következtetni, de helyenként gyanúsan hiányzik a hálózattal kapcsolatos adat.