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

• Központi adatbázis tervezése
• Adatok összegyûjtése
• Lekérdezések tervezése
• Jelentés készítés

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:

• Az OB által megfogalmazott kérdésekre lekérdezést lehessen összeállítani
• Alkalmas legyen ismételt vagy rendszeres adatgyûjtésre is
• Az adatok összegyûjtése ne követeljen irreálisan sok munkát
• Az összegyûjtött adatok egymással logikus, összefüggõ rendszert alkossanak

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:

• Microsoft Projekt,
• Novell file szerver megosztott hozzáféréssel

3.2 Rendszertervezés

Alkalmazott eszközök:

SSADM módszertan / gyalog

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

Például:

• Mikor csöppenünk bele
• Mi elõre meghatározott
• Milyen részletességgel és mélységben

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:

• Tervezett futtatási környezet
• Fejlesztési munkaerõ befektetés

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:

• Web lap hirdetése, propagálása,
• levelezõ lista felállítása,
• a kérdésekre adott válaszokat a WEB-re tenni.

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:

• Félreérthetõ kétlépcsõs install

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.

• Helyi rendszer hibái

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.

• Dokumentáció olvasatlansága

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.