PTI BSC SZAK EU AKKREDITACIÓJÁNAK TAPASZTALATAI. Összefoglaló. Abstract

Informatika a felsőoktatásban 2008

Debrecen, 2008. augusztus 27-29.

PTI BSC SZAK EU AKKREDITACIÓJÁNAK TAPASZTALATAI EXPERIENCES OF EURO-INF ACCREDITATION OF THE PROGRAMME SOFTWARE ENGINEERING

Aszalós László1, Rutkovszky Edéné1, Nagy Zoltán2 Debreceni Egyetem, Informatikai Kar1, Szatmár-Beregi Kórház és Gyógyfürdő2 Összefoglaló 2008 márciusában a Debreceni Egyetem Informatikai Karának Programtervező Informatikus szak alapképzését akkreditálta az Euro-Inf szervezet. Az akkreditáció egyik eleme az Európai Parlament által 2007 októberében elfogadott Európai Képesítési Keretrendszeren alapul. Ennek a keretrendszernek az alkalmazása 2010-ig hazánkban is általánossá válik, s várhatóan a magyar akkreditációs rendszer is idomulni fog hozzá. Ezért mindenki számára érdekes lehet, hogyan is néz ki egy ilyen akkreditáció, milyen adatok összegyűjtésére volt szükség, milyen informatikai megoldásokat használtunk fel, és milyen tapasztalatokat szűrtünk le az akkreditáció során.

Kulcsszavak Euro-Inf, akkreditáció, programtervező informatikus

Abstract In March of 2008 the programme of Software Engineering at Faculty of Informatics, University of Debrecen is accredited by organization Euro-Inf. The Euro-Inf accreditation is partially based on the European Qualifications Framework accepted by European Parliament in October of 2007. This framework will be standard in Hungary at 2010, the Hungarian accreditation system will apply this method. Hence it could be interesting for Higher Educational Institutes what the structure of the Euro-Inf accreditation is, what kind of information need to collect for it, what kind of IT solutions we used, and what our experiences are.

Keywords Euro-Inf, accreditation, software engineering

1


1.


Bevezetés

A Debreceni Egyetem Informatikai Kara az országban elsőként akkreditáltathatta az EuroInf szervezetnél egyik alapképzését. A nemzeti akkreditációkkal mindenki tisztában van, de a nemzetközi akkreditáció még újdonságnak számít mindenki számára. Miért is van szükség ilyen nemzetközi akkreditációkra? A bolognai folyamat sokak számára csak annyiból áll, hogy bevezettük a kreditrendszert, s hasonló számú kreditet kell megszerezni hasonló diplomához, valamint alap- és mesterképzésre bontottuk a korábbi egyetemi képzéseket. Az 1999. július 19-ei Bolognai deklaráció [2] viszont a következőket emeli ki:  könnyedén összehasonlítható fokozatok  kétszintű képzés  európai kreditrendszer, mely elősegíti a mobilitást  diák és tanári mobilitás inkább: hallgatói és oktatói mobilitás Látható, hogy alapjában véve az első ponttal, az összehasonlítható fokozatok és képzések terén vannak még elmaradásaink. Hogyan is lehetne egy máltai és egy dán informatikus alapdiplomát összehasonlítani? Pedig ez egy lényeges szempont. A közös Európa eszméje lehetővé teszi, hogy a diák érettségi vagy BSc/BA alapdiploma megszerzése után bármely ország felsőoktatási intézményében tanulhat. De a több száz intézmény közül választani kell valahogy, s ehhez az a kiindulópont, ha az érintett össze tudja hasonlítani a huszonhét ország minden számára érdekes képzését. Ezt hivatott biztosítani az Európai Képesítési Keretrendszer [8] bevezetése, amely 2010-ig minden Európai uniós tagország oktatási intézményében végrehajtásra kerül. Azt, hogy az egyes intézmények kitűzött és közreadott kitűzései mennyire vannak összhangban a gyakorlattal, azt az akkreditáció képes felmérni. Ilyen akkreditációk során szakértők átvilágítják az adott intézmény képzését, személyi és tárgyi feltételeit, s véleményt mondanak a benyomásaikról. Természetesen miután az európai közösség tagjai vagyunk, így a közösség által meghatározott elvárások ránk, a magyar akkreditációs gyakorlatra is hatással vannak, így pár éven belül az Euro-Inf elvárásai a magyar szabványokban is megjelennek. Mi is ez az Euro-Inf [7] szervezet? Ez egy akkreditációs szervezet, amely azzal a céllal jött létre, hogy az európai mérnöki/informatikai képzések terén megteremtse az összehasonlíthatóságot. Habár a közösség szinte minden országában megvan a nemzeti akkreditációs szervezet, ám mivel ezek egymástól függetlenül jöttek létre más és más feltételrendszerrel, így csak hosszú összecsiszolódás után válnak összemérhetővé a feltételrendszerek. Az Euro-Inf szándékai szerint „Európai pecsétet” adhatna a képzéseknek, amely egyértelmű jelzés lehet a munkáltatók felé, hogy mely diplomákra milyen szinten számíthat, másrészt az akkreditáció során tapasztalt hiányosságok feltárása segíthet a képzés színvonalának emelésében. 2005-ben kezdte meg a működését a szervezet, azóta összehasonlították az egyes nemzeti akkreditációs gyakorlatokat, megbeszéléseket folytattak különféle munkaadókkal, s több lépésben finomították a módszert. Az akkreditációs folyamat önmaga is visszacsatolásos módon fejlődik, jelenleg próbaakkreditációk történnek, a különböző felsőoktatási intézményekben megtörtént látogatást követően a fejlesztő csapat a tapasztalatokat beépíti a követelményrendszer fejlesztésébe. Ennek a nemzetközi fejlesztő folyamatnak a részeként történt karunkon a próbaakkreditáció. Az Euro-Inf szervezet tagjai:

2


    2.


ASIIN: német akkreditációs szervezet, amely mérnöki, informatikai, természettudományos és matematikai képzések akkreditációjával foglalkozik. CEPIS: 32 informatikai társaság társulása Hamburgi Egyetem Padernborni Egyetem. Felhasznált szoftverek

2.1.

Jegyzetfüzet

A kar a jelentés elkészítése során csak két munkatársát tudta ráállítani erre a projektre, ezért hatékony munkavégzésre volt szükség. David Allen Getting Things Done (GTD) [1] szervezési módszereit próbáltuk követni, melynek egyik fontos összetevője, hogy ki kell üríteni a dolgozó agyát, pontosabban az elvégzendő feladatokat valahova le kell írni. Ezután már csak az éppen megoldandó feladatra kell koncentrálni, azt kell megoldani. Ezután a listából kiválasztani e következő megoldandó feladatot, s ez megy mindaddig, amíg el nem fogy a projekt összes részfeladata. Igen sok olyan számítógépes program született, amely a GTD szellemében segít a feladatok szervezésében. Egyik ilyen a GTDTiddlyWiki [3], melyet sokan megelégedéssel használnak. Mi ennek a programnak az ősét, a TiddlyWiki-t [6] használtuk. Habár a TiddlyWiki neve a mostanság divatos Web2-re utal, valójában nem is program, hanem csak egy egyszerű HTML fájl, amely jegyzetfüzetként szolgál. Épp úgy mint a Wiki rendszereknél, itt is apróbb szövegrészeket lehet beírni a rendszerbe, majd azokat címkézni. Ezután lehetőség van a teljes szöveg keresésére, de könnyű bizonyos címkéjű szövegrészeket is összeszedni. Az a rendszer plusz szolgáltatása, hogy az egyes szövegrészeket a frissítésük dátuma szerint sorrendbe képes szedni, így egyből lehetett látni, hogy legutóbb mi változott meg. A jelentés írásához több tucat dokumentumra volt szükség, s nem bírtuk nyomon követni, hogy melyik szövegrész merre is található. Épp ezért a lényeges szövegrészeket a TiddlyWiki jegyzetfüzetünkbe másoltuk be. Majd később a jelentés szövegrészeit is ide írtuk, s ide került minden olyan szövegrészlet, melyről feltételezhető volt, hogy esetleg még szükség lesz rá. Az akkreditációs jelentés legfontosabb része, az önértékelő jelentés elkészítéséhez kaptunk egy DOC formátumú sablont, de ezt messzire elkerültük. A jelentés TXT formátumban íródott, amelyből a txt2tags [4] program segítségével készült TeX formátumú állomány, majd végül a LaTeX segítségével a PDF fájl. A generált TeX forrásba csak azért kellett belenyúlni, mert az önértékelő jelentés fedőlapja speciális formátumú volt, s nem egyezett meg a txt2tags által generálttal. De erre csak egyszer, a teljes anyag lezárása után került sor. Az elkészült jelentésrészeket a sima másol-beilleszt módszerrel lehetett átvinni TXT állományokba, s szerencsére a TiddlyWiki és Txt2tags jelölésrendszere nem tér el lényegesen, nem kellett sokat kézzel kiigazítani, formázni. A jelentéshez készült Unix-os világban jól ismert Makefile lehetővé tette, hogy szinte automatizálva felkerüljön a jelentés aktuális állapota a honlapra. Megpróbálkoztunk projekt-segítő program alkalmazásával, de mivel csak két ember idejét kellett volna beosztani, s nem kellett párhuzamosan más projektet is csinálnunk, ez nem bizonyult hatékonynak. Az elektromos jegyzetfüzetünkbe hasonlóképpen be tudtuk írni az egyes részfeladatokat, s címkézni lehetett, hogy melyiket kinek kell megoldani, kitől várunk adatokat, tehát kit és miért kell nyaggatni, s mely jelentésrészek vannak már készen. A honlapra kirakott verzióban pedig az érintettek ez figyelemmel kísérhették.

3


2.2.


Archiválás menete

Az ember sose bízhat meg teljesen a technikában. Annyi időnk volt csak, hogy egyszer készítsük el a jelentést, a lehetőség szerint ki kellett zárni annak az esélyét, hogy adatvesztés miatt újra kelljen valamit csinálni. Ennek megfelelően a két szerző saját gépén levő állományokról naponta mentés készült pendrive-ra, illetve másik gépre. Az inkrementális mentés a Linux alatt a copy parancs okosan felparaméterezett változatával és az rsync paranccsal egyszerűen megoldható [5]. A copy képes a korábbi fájlokról linkeket készíteni, így bár úgy tűnik, hogy egy fájl többször is előfordul az egymást követő napokhoz tartozó alkönyvtárban, valójában csak egyszer foglal helyet. Ha változás történik, a linket felülírja az új fájl, s a későbbiekben ez „másolódik” tovább. Ennek megfelelően napi mentések voltak, egy-egy nap egy-egy alkönyvtárnak felelt meg, s egyetlen fájl azonos változatai sem foglaltak kétszer helyet. Alapjában TXT formátumú fájlokkal kellett dolgozni, a verziókövető szoftverekkel töredék tárhely elég lett volna, s az inkrementális mentéshez hasonlóan hozzá lehetett volna férni minden egyes változathoz. A probléma csak az volt, hogy az adatokat mások számára is könnyen elérhetővé kellett tenni, s az ilyen programok használatában nem járatos minden érintett kolléga. Mivel ezek a mentések nem voltak a köz számára elérhetők, viszont az aktuális állapotot a honlapon tettük elérhetővé az érintettek számára. A szerzők között, illetve a vezetőség felé email-ek továbbították a legfrissebb állományokat, illetve a hozzájuk fűzött megjegyzéseket. Mind a tárhely, mind a honlap állománya, és a levelezés is rendszeres mentés alanya, így csak pár nap kiesést jelentett volna, ha valamilyen katasztrófa miatt az elektromos eszközök mind tönkrementek volna. 2.3.

A projekt honlapja

Mivel néhány kényes természetű adat is belekerült a jelentésbe, s felsőbb döntést igényelt, hogy benne maradhat-e ezért a félkész anyagokat nem tettük ki az „internetre”. Az Informatikai Karnak nincs intranet-je, azaz belső védett hálózata, ezért az egyik szerző egyébként nyilvános személyes honlapjára kerültek fel a projekt adatai, csak link nem vezetett erre a részre sehonnan, hogy a kereső robotokat biztosan kizárjuk. Az érintett kollégák emailben kapták meg a megfelelő URL-t. Mi került fel erre a honlapra?     

a jegyzetfüzet aktuális tartalma jelentés aktuális állapota személyes adatlapok tantárgyi adatlapok áttekintő táblázat a személyes és tantárgyi adatlapokról, syllabus-okról és dolgozatokról  majd végül a bizottság számára a teljes akkreditációs anyag, felhasznált hazai és nemzetközi szabványok, valamint a látogatás menetrendje Miért is volt szükség az áttekintő táblázatra? Az a helyzet, hogy a vezetés számára átláthatóvá szerettük volna tenni a munkánkat, s folyamatosan láttatni, hogy éppen hogyan is állunk. Egy-egy ilyen táblázatban látszott, hogy ki az, aki már az összes számára kirótt feladattal végzett, s ki az, akinek elmaradása van. Valamelyes szégyenfal szerepet is betöltöttek ezek az oldalak, de nem mindenkit hatottak meg. Ezért amikor már közel jártunk a végső határidőhöz az email-es figyelmeztetést használtuk fel: a saját anyagukkal adós emberek nap mint nap kaptak egy emlékeztető levelet, hogy elmaradásuk van. A levélben

4



szerepelt az is, hogy ezt naponta kapják addig, míg nem végeznek a kirótt feladattal. Ez viszont segített, szinte mindenki iparkodott. 2.4. Kérdőívek Az akkreditációs szervezettől MS Word formátumú kérdőíveket kaptunk, gondolom feltételezték, hogy ilyen formátumban is kapják vissza az anyagot. Az a helyzet, hogy volt már szerencsénk több olyan projektben is részt venni, ahol sok embernek kellett összedolgoznia, s természetesen a résztvevők különböző szintű Office ismerettel rendelkeztek. Mindenki kitöltötte a rá vonatkozó kérdőívet, esetleg alakított rajta egy kicsit, például átméretezte a kérdőív egy táblázatát, mert nem fértek bele az adatai. De az is lehet, hogy nem ő, hanem az általa használt program változtatta meg a kérdőív külalakját, ahogy az az MS termékeknél időnként előfordul. Az egységes külalak érdekében a tantárgyakra és az oktatókra vonatkozó kérdőívet TeXben szedtük ki, s a visszaérkezett válaszokat is ilyen formátumban kódoltuk. Noha az oktatók több mint fele ilyen formátumban írja a cikkeit, a többiekre gondolva nem erőltettük ezt a formátumot. Az egyik szerző Windows XP alatt dolgozott, míg a másik Linux alatt UTF-8 kódolást használva. Lehet mondani, hogy egyszerűbb lett volna egységesíteni, de mindkettő otthonosan dolgozott a saját környezetében, és váltás a teljesítmény kárára mehetett volna. A két eltérő operációs rendszer használata jellemző a kari oktatókra is, ezért a kiküldött kérdőívek esetén valami megfelelő formátumot kellett találni. Az első ötlet az volt, hogy egyszerű email formájában kapja meg mindenki a már meglévő adatokkal kitöltött kérdőíveket, s a válaszlevélbe beidézett kérdőívben kell kijavítani a hiányos vagy hibás adatokat. A levelező rendszerek elrejtették a karakterkonverziós problémákat, tehát ez ezért is tűnt ésszerűnek. Másrészt az elektronikus levelezés rég felváltotta a karon belül papír leveleket, értesítőket, azaz mindenki használja. Sajnos ez nem igazán működött, Ezért az email-be beillesztett sima TXT fájlt fájó szívvel átalakítottuk Word DOC formátumra, s így küldtük ki a munkatársaknak. Annyit kértünk még, hogy a kiegészítéséket más színnel írják be a fájlba, amit mindenki meg is tett. Aztán a DOC formátumban visszakapott kérdőívekből TeX formátumú fájlba másoltuk a hiányzó adatokat. A feldolgozás folyamatos volt, s közel ötven oktató személyi adatlapját és hasonló számú tantárgyi adatlapot kellett szerkeszteni. Hogy ne maradjon ki semmi, egy megfelelő Makefile állományt készítettünk, amely automatizálta a kérdőívgyűjtemény fordítását. A már kitöltött kérdőívek PDF formátumban folyamatosan kerültek ki a projekt honlapjára, hogy mintául szolgáljanak a többi kollégának is, illetve lehetőséget nyújtottak a hibák felfedezésére, és kijavítására. Természetesen a kérdőívek első kiküldésekor a honlapon már voltak kitöltött minták. 3.

Akkreditációs anyag részei

A kezdeti információs anyagnak része volt egy felsorolás, hogy milyen anyagokat kell a bizottság részére elkészíteni: 

Felvételi szabványok és követelmények. Itt viszonylag egyszerű volt a helyzet, mivel a felvételi megszűnt, a felvi.hu honlapjára pedig könnyen lehetett hivatkozni. Persze a követelményeket lefordítottuk. Információt kértek az alternatív felvételi módokról is, ami szerintünk nem más, mint átjelentkezés más szakról, vagy egyetemről.

5





Mintatanterv. Ez magyarul kész volt, a fordításon kívül nem volt vele más dolgunk. Ezt még decemberben elkérték, hogy a bizottság kiválasztásakor figyelemmel legyenek a képzés sajátosságaira.  Az összes oktatott tantárgy adatlapja.  Az elmúlt három év diplomamunkáinak/szakdolgozatainak címei  Létesítmények listája: épületek, géptermek, felszerelés.  Oktatói és kisegítő személyzet adatlapjai  Elmúlt félév zárthelyi és vizsgadolgozatai. Az akkreditációs anyag elkészítése során pontosítottuk a igényeket, s ekkor derült ki, hogy az előző félévben oktatott tárgyak syllabus-ait is be kell mutatnunk, azaz, hogy mely héten a tananyag mely részét oktatta az előadó. 4.

Adatok összegyűjtésének nehézségei 4.1. Képzési keretrendszer

2007 októberében elfogadta az Európai Parlament a Európai Képzési Keretrendszert [8], amely a tudást, a gyakorlati ismereteket és a kompetenciákat nyolc szintű skála alapján értékeli. 2005 óta Magyarországon is többen foglalkoztak ezzel a témakörrel, de az oktatók több mint 99 százaléka még nem is hallott róla. Noha két oldalon elfér az egész táblázat, egykét napot eltölt vele az ember, míg teljes egészében felfogja a rendszert. Az akkreditációs bizottság pedig elvárta, hogy a tantárgyi tematikák mellett azok oktatásának a szintje is megjelenjen, mert ugyanazokat az ismereteket különféle szinteken is el lehet sajátítani. (Gondoljon például mindenki a nappali és levelezős képzés jellemző színvonalkülönbségére!) A tantárgyakat a következőképpen osztottuk be ebbe a keretrendszerbe: elkészítettünk egy fél asztalt lefedő táblázatot, melyben egyrészt a tantárgyakat, másrészt az Euro-Inf által egy informatikustól elvárható kompetenciákat soroltuk fel. Első elképzelésünk az volt, hogy egy adott tantárgy/kompetencia párost be lehet sorolni a nyolc szint valamelyikére, akár tudás, akár gyakorlati ismeret szempontjából. Hamar rájöttünk, hogy ennek a négy-dimenziós mátrixnak a kezelése lehetetlen, így a tantervi tematikák, a kimeneti követelmények és számonkérési gyakorlatok alapján eldöntöttük, hogy a szóban forgó óra segíti-e az adott kompetenciát, vagy sem. Míg a magyar akkreditációs bizottság a programtervező informatikus részére tizenhárom igen általános kompetenciát fogalmaz meg, az Euro-Inf közel ötvennel számol, amelyek elég konkrétak. Végül e táblázatot a tantárgyi adatlapokkal összevetve megtörtént a besorolás, ahol többnyire a kezdeti alapozó tárgyak hármas, korai szakma tárgyak jellemzően négyes, majd a specializáló tantárgyak ötös tudásszintet kaptak. A gyakorlati rész jellemzően inkább ketteshármas szintet jelentett. A keretrendszernél a kompetencia szintek jellemzően egy fizikai munkásra tervezettek, a kulcsszavak a felelősség és önállóság. A helyzet az, hogy adatbázisról tanulóinkat nem állítjuk oda egy valódi bank adatbázisait kezelni, vagy a szerverprogramozást sem a napi feladatainkat ellátó szervereken gyakorolják, csak egy mintakörnyezetben, ahol nem igazán lehet a dolgokat elrontani, ezért felelősségről nem igazán beszélhetünk. Ennek megfelelően a kompetencia szintek egy és kettő környékén mozogtak, ha egyáltalán volt értelme egy adott tantárgy esetén. 4.2. Oktatási adatok

6



A kreditrendszer bevezetése során az Informatikai Kar illetve jogelődje három informatikai rendszert használt. Az első, saját fejlesztésű Elektromos Tanulmányi Osztályt a Neptun váltotta, majd azt a Egységes Tanulmányi Rendszer (ETR). Sajnos egyik sem volt képes rá, hogy a vezetőséget naprakész adatokkal lássa el, ami pedig egy ilyen rendszer egyik alapvető feladata lenne. Az egyes előadásokra, gyakorlatokra jelentkezett diákok számát csak kerülő megoldásokkal, bő egy-két óra alatt lehetett kinyerni. A szakdolgozatcímek megszerzéséhez is több nyilvántartást kellett összefésülni. A szakot elhagyó diákok számáról szóló, illetve az egyes tantárgyak átlageredményeit, szórásait hiába vártuk a helyi ETR központból, majd egy hetes késéssel megkaptuk az adatbázis ránk vonatkozó adatait kiexportálva egy táblázatkezelő formátumában. Az egyik szerző statisztikai programok használatában szerzett tapasztalatának köszönhetően egy nap alatt elkészültek a kért statisztikák. Meglepő volt látni a tantárgyak hosszú listáját a japán nyelvi kurzusoktól a dzsessztörténetig, de legalább nem lehet azt mondani, hogy szakbarbárokat képzünk. 4.3.

„Ott van a honlapon”

A saját kari honlapunk viszonylag jól szervezett, így viszonylag könnyen ráakadhatunk a keresett adatra. Ehhez persze az is hozzátartozik, hogy szinte naponta használjuk. Persze az is előfordult, hogy lényeges információk nem kerültek ki idejében, de rövid időn belül sikerült ezeket a hiányosságokat megszüntetni. Viszont ahogy a honlap mérete egyre nő, a gyakorlatlan felhasználó egyre nehezebben találja meg a számára fontos adatot a keresés hiányában. Az egyetemi honlappal hasonló helyzet, de ez jóval méretesebb, mint a kari. Az akkreditációhoz szükséges szabványok, szabályok vagy DOC, vagy PDF formátumban szerepeltek, s a kereső ezeket nem indexelte. Fél napokat is sikerül eltölteni a böngészéssel, míg az ember ráakadt a szükséges információra. Pedig ott voltak, sőt a meglepetéssel értesültünk róla, hogy mennyire frissek, s mennyire az Euro-Inf szellemében íródtak. 5.

Látogatás tapasztalatai

Az Euro-Inf által előre kiadott dokumentumokban szerepelt a látogatás menete, amely egységes minden esetben:      

találkozó az egyetem és a képzési program vezetőivel találkozó a képzési program vezetőivel találkozó az oktatói karral infrastruktúra megtekintése (ipari partnerek) találkozó a diákokkal záró találkozó az egyetem és a képzési program vezetőivel

Mindez egy nap alatt megy le, igen feszített az ütem. Nem fér bele egy közös ebéd sem, a bizottság emiatt előre kért pár szendvicset ebéd gyanánt. 5.1.

Találkozó az egyetemi vezetőkkel

Az informatika nem egy régi tudományág, ennek megfelelően nincsen egységes múltja. Nálunk a matematikából nőtte ki magát, máshol a mérnöki tudományokból, de más eredet is könnyen elképzelhető.

7



Ennek megfelelően nem volt haszontalan, hogy a bizottság látott egy bemutatót magáról az egyetemről, annak szervezeti változásairól, majd egyet az egyetem tudományos életéről. Így a bizottság elhelyezhette a képzésünket az egyetem életében. 5.2.

Találkozó a képzési program vezetőivel

Az egyetemi bemutatók kicsit elhúzódtak, így a kar, s a Programtervező informatikus szak bemutatása már a második találkozóra maradt. A bemutatott tények, számok mellett a bizottságot a következők érdekelték: 

  

    

Hogyan kapnak szerepet különféle cégek a képzésben? (Tehát nem a tudomány elefántcsont-tornyában lakozunk, azaz hatnak ránk a világ dolgai, változásai.) A Programtervező Informatikus szak tanterve eléggé feszített, így nincs túl sok lehetőség szabadon választott órák tartására, ám próbálunk nyitni a cégek irányába. Szerencsére a cégek igen nyitottak a diákjaink irányában, a 2008 áprilisában tartott szakmai napokon négy teljes nap megtelt programokkal úgy, hogy párhuzamosan is tartottak előadásokat. Reméljük hagyományos tantervi órák is lesznek ezekből. Másrészt pár cég gyakornokokat vesz fel diákjaink közül, így a cég is megismeri leendő dolgozóit, a diákok is gyakorlatot szereznek. Érdekelte a bizottságot a képzés anyagi háttere. Ehhez el kellett magyarázni, hogy nincs tandíj, az állam a létszám alapján fizet, s a cégek rendszerint csak a szakképzési támogatáson keresztül támogatják az egyetemet. Érdekes volt számukra az ötszáz fős kurzusok megszervezése is. Itt az előadásokat és a gyakorlatokat kellett elmagyarázni, bár nem értettem, hogy miért, mert maga az adatlap ezeket külön kérte, sőt az átlagos létszámokat is. Sarkalatos pont volt a képzés áteresztő képessége, mert a több mint 100 emberből aki elkezdte a képzést, három év alatt csak szűk tucatnyi végzett. Persze külföldi hírekből gyakran hallja az ember, hogy külföldön az ötéves képzést átlagosan 6-7 év alatt végzik el, de hogy hasonló tendenciák érvényesülnek nálunk is, az korábban nem volt nyilvánvaló. Próbáltuk kiemelni a jelentésben, hogy már nem válogathatunk a jelentkezők között, országosan egységes eljárás után kapjuk meg őket, s nem mindenki rendelkezik kiváló képességekkel. Elmondtuk azt is, hogy kar három évenként értékeli és felülvizsgálja a képzést. A bizottság a matematikai tárgyak további könnyítését javasolta. Meglepő kérdés volt az, hogy milyen gyakran találkozhat a diák az oktatóval személyesen, s milyen formában. Érdekelte a bizottságot a szakdolgozatok írásának menete a dolgozat meghirdetésétől annak megvédéséig. Ehhez kapcsolódott az a kérdés, hogy milyen arányban vannak azok a szakdolgozatok, melyek egy külső céghez kapcsolódnak, illetve hogyan szándékozunk ezt az arányt növelni. Hogyan küzdünk a szakdolgozatokban a plagizáció ellen? Elég hosszan írtunk a jelentésben az egyetemi illetve a kari könyvtárról, amely matematikai, informatikai könyveket és folyóiratokat gyűjt. Felmerült a kérdés, hogy mekkora az informatikai könyvek aránya. Mivel az Informatikai Karon oktató tanárok nagy részének matematikai irányultságú a kutatási területe, így matematikai könyveket is nagy számban vásárol a Kar. Tehát csak becsülni tudtuk az arányt. Valószínű senki nem fogja ennek megfelelően átnézni a harmincezer kötetet.

8




 


Kérdésként felmerült, hogy hogyan változnak a tantervek (tematikák), ugyanis az informatika nem egy statikus tudomány. Mennyire van joga egy új kollégának a meglévő tanterven módosítania? Hogyan módosulhat egy tematika, mi ennek a menete? Megkérdezték, hogy mi kell ahhoz, hogy valaki taníthasson, s mi a habilitáció feltétele. Ebben a részben az utolsó kérdés az oktatásban használt programok felsorolására irányult, de rendszerint ilyen formában nem szokás nálunk a többiek tevékenységét követni, s a tantárgyi tematikák sem tartalmaznak konkrét szoftvereket.

5.3.

Találkozó az oktatókkal

Az akkreditációra egy csütörtöki napon kerül sor, s emiatt nem lett felforgatva a Kar élete. Az órák a normális menetrendben lettek megtartva, így az oktatói találkozón csak azok vehettek részt, akiknek az adott időtartamban nem volt órájuk, összesen.7 fő..  



 

A bizottság folytatta ott, ahol abbahagyta, konkrét szoftverfejlesztési környezetek felől érdeklődött, amelyeket az oktatásban használunk. Majd a Magyar Akkreditációs Bizottság dokumentumaiban szereplő Programtervező Informatikusok számára előírt kimeneti követelmények/kompetenciák megvalósulása iránt érdeklődtek. Az a helyzet, hogy ezek igen általános megfogalmazásúak, nem igazán szerepelnek benne konkrétumok. Ehhez képest az Euro-Inf által megfogalmazott kompetenciák konkrétak, viszonylag egyszerűen hozzá tudtuk rendelni azokat a tantárgyakat, melyek segítenek az elsajátításában. Ennek megfelelően csak kitérő választ tudtunk adni az eredeti kérdésre. A jelentésben megfogalmaztuk, hogy a képzésben a projektalapú szemlélet nem igazán jellemző, ritkán kell a diákjainknak csoportokban/teamekben dolgozniuk. Ennek ellenére a csoportmunka elméleti alapjait megtanulják egyes tantárgyakkal. A bizottság a konkrét tantárgyakra lett volna kíváncsi, de az érintett oktató hiányában nem tudtunk kielégítően válaszolni. A bizottság az oktatókat is megkérdezte, hogy mi a tantárgyi tematikák megváltozásának/megváltoztatásának menete, illetve hogyan készülnek a szakdolgozatok. A bizottságot érdekelte az is, hogy a csalások ellen hogyan védekezünk, mert ez a bizottság tagjainak anyaintézetében egyre nagyobb problémát okoz. Erre fel tudtunk hozni példaként olyan kollégát, aki a bemutatott algoritmust kéri implementálni, s a beérkezett majd száz programot szoftverrel hasonlítja össze, s a nagyon hasonlók szerzőit személyesen ellenőrzi.

5.4 Találkozó a cégek képviselőivel Debrecenben az utóbbi időben egyre több informatikai vállalkozás telepedik meg, akik minden végzett diákunknak tudnának állást ajánlani. A bizottság ezen cégek képviselőivel is elbeszélgetett. Hat cég képviselői voltak jelen. 

A cégeket elsőként arról kérdezték, hogy melyek a végzettjeink erősségei, és melyek a gyöngéi. Erősségként említették az általános képességek magas szintjét, erős elméleti alapokat matematikából és programozásból, az angol nyelv ismeretét. Gyengeségük a diákjainknak a fejlesztési gyakorlat, Microsoft termékek magasabb szintű ismerete, a C# és .Net programnyelvek nem tudása, a projektszemlélet és a a vevő/felhasználóspecifikus szemlélet hiánya. (A cégek nem voltak túl lelkesek az igen magas szintű

9







Java oktatás miatt, a gyakorlatban nem igazán használják.) Felmerült az is, hogy a környező országokból olyan munkaerő szerezhető, aki négy-öt idegen nyelven beszél, míg a mi diákjaink csak angolul tudnak, de a beszélt nyelvvel, főleg az üzleti nyelvvel az angol esetén is baj van. A T-Systems beszámolt arról, hogy az informatikusaink nem tudnak németül, s a cég nem vállalkozott arra, hogy megtanítsák őket németül. Ezért németül tudó diplomásokat alkalmaztak, akiket kitanítottak az informatika alapjaira. A bizottság érdeklődött a felől is, hogy milyen tárgyakat látnának szívesen a cégek a képzésben. Itt a céges megoldások (enterprise solution), csapatmunka, valamint a fejlesztés folyamata voltak a cégek sarkalatos pontjai, bár ez utóbbi kettővel nyitott kapukon kopogtatnak. A bizottság rákérdezett arra, hogy a felvett új munkaerő között mekkora számban vannak a nálunk végzettek, illetve hogy a jelenleg végzettek többszörösét hajlandók lennének-e alkalmazni. Ez utóbbi kérdésre a megnyugtató igen válasz érkezett.

5.5.

Találkozó a diákokkal

Abban a szerencsés helyzetben vagyunk, hogy beindult a mesterképzésünk, így van pár diákunk, aki a PTI képzést végigcsinálta. Sikerült ilyen diákot is részvételre bírni, valamint néhány jelenlegi PTI diákot is. A hallgatói önkormányzatunk képviselői az Egyetemi Tanácson kellett megjelenni az akkreditáció idejében, s a helyettesítést sem tudták megoldani. Így ezen a találkozón csak a hallgatók és az akkreditációs bizottság tagjai vettek részt. Felmerül itt is a túl sok matematikai tárgy megléte, az előadás és gyakorlat kettőse, a csoportlétszámok, a projektmunka szerepe és ennek oktatása. A legmeglepőbb kérdés az az volt, hogy ismeri-e az átlag diák a dékánt, vagy sem. Mivel a dékánia igen sok külön programot szervez, rendszeresen fórumot tart, és a dékán megtiszteli a szakesteket a látogatásával, erre nem lehetett panasz. 6.

Értékelő jelentés

A látogatás után több mint két hónappal érkezett meg a akkreditációs bizottság közel negyven oldalas jelentésének piszkozata. Az akkreditálók számára teljesen idegen rendszer több félreértésre adott alkalmat, így több pontosításra is szükség volt. Másrészt a bizottság igényelte a fontosabb szabályzatok angol fordítását, ami csak a tanulmányi és vizsgaszabályzatunk esetén több mint száz oldal. Az önértékelő jelentést elfogadták, a benne szereplő adatok, tények egybeestek a látogatás során tapasztaltakkal. Kifogásolták viszont, hogy az oktatóink nincsenek teljesen tisztában a szak illetve a tantárgyak kimeneti követelményivel, pedig annak megfelelően kellene oktassunk. Javasolták a diákok leterheltségének és a problematikus tárgyak vizsgálatát, hogy az átlagos képzési idő rövidüljön, növekedjen a végzettek száma. Irodalomjegyzék [1] Allen, David, 2002, Getting Things Done: The Art of Stress-Free Productivity, Penguin [2] Bologna declaration, 1999, http://ec.europa.eu/education/policies/educ/bologna/ bologna.pdf [3] Bowers, Nathan, 2005, GTDTiddlyWiki, http://nathanbowers.com/gtdtw/

10



[4] Jargas, Aurelio, 2008, txt2tags: One source, Multi targets, http://txt2tags. sourceforge.net/ [5] Korb, Kevin, 2005, Backups using rsync, http://www.sanitarium.net/golug/ rsync_backups.html [6] Ruston, Jeremy, 2005, TiddlyWiki, a reusable non-linear personal notebook, http://www.tiddlywiki.com/ [7] The Euro-Inf Project - European Accreditation of Informatics Programmes, http://www.euro-inf.eu/ [8] The European Qualifications Framework, http://ec.europa.eu/education/policies/ educ/eqf/index_en.html

11

PTI BSC SZAK EU AKKREDITACIÓJÁNAK TAPASZTALATAI. Összefoglaló. Abstract

Recommend Documents