Elektronikus pályáztatás és bíráltatás - kísérletek és tapasztalatok NetWorkShop 2004, Győr, 2004. április 7.
Patakfalvi Zoltán <
[email protected]>, Veress Péter
BME Villamosmérnöki és Informatikai Kar Hanák Péter , Simonkay Sándor <[email protected]> Nemzeti Kutatási és Technológiai Hivatal (NKTH)
Tartalom 1. 2.
Bevezető.........................................................................................................................2 Az elektronikus pályázás és projektkövetés fő fázisai (áttekintés) ...................................2 2.1. A pályázás támogatásának fázisai ...........................................................................2 2.2. A bíráltatás és döntés támogatásának szintjei ..........................................................3 2.3. A szerződéskötés támogatásának szintjei.................................................................3 2.4. A projekt (szakmai, ill. pénzügyi) követésének támogatási szintjei..........................4 2.5. A megvalósításról ...................................................................................................4 3. Űrlap feldolgozás – adattárolás .......................................................................................5 3.1. Tervezési szempontok.............................................................................................5 3.2. XML, ahogy mi használjuk .....................................................................................6 3.3. Felületek (Excel, Java form, html: célja cserélhetőség)............................................6 3.4. A feldolgozás/ellenőrzés .........................................................................................6 3.5. Adatbázis................................................................................................................7 4. Űrlap befogadás kezelése................................................................................................7 4.1. Levél eltárolása.......................................................................................................7 4.2. Csatolmányok feldolgozása.....................................................................................8 4.3. Adatbázisba töltés ...................................................................................................8 5. Elektronikus bíráltatás ....................................................................................................9 5.1. Követelmények a bírálati dokumentációkat kezelő rendszerrel szemben..................9 5.2. Megvalósítás.........................................................................................................10 6. Összefoglalás................................................................................................................10
1
1. Bevezető A ciklikusan ismétlődő tevékenységeket jól lehet és érdemes számítógéppel támogatni. Az utóbbi években az ügyviteli munkafolyamatok számítógépes támogatása egy-egy területen igen sikeres volt, az elért eredmények látványosak. Példaként az APEH, ill. a Westel Mobil Rt. ügyfélszolgálati rendszerét említhetjük. A kormányzati, ill. önkormányzati szférában is számos olyan kezdeményezés van, amely az ügyviteli munkafolyamatok egészét számítógéppel akarja támogatni, de ezen a téren még rengeteg a tennivaló.
2. Az elektronikus (áttekintés)
pályázás és
projektkövetés
fő
fázisai
I. A pályázás támogatása. II. A bíráltatás és döntés támogatása. III. A szerződéskötés támogatása. IV. A projekt (szakmai, ill. pénzügyi) követésének támogatása. A teljes folyamatot támogató számítógépes rendszernek egységes elvek alapján felépülő, szabványokon alapuló pl.: XML-alapú egymással adatcserére képes, moduláris, a továbbfejleszthetőség szempontjából nyitott, platform független rendszernek kell lennie. Fontos a (létező) szabványok alkalmazása, szükség esetén „belső szabványok” kialakítása az egyes alrendszerek, ill. hasonló célú rendszerek (pl. a KPI PIR-je, a Nemzeti Fejlesztési Terv keretében meghirdetett pályázatok Egységes Monitoring és Információs Rendszere (EMIR), a Nemzeti Kutatás-nyilvántartó Rendszer stb.) átjárhatóvá tételéhez. Kritikus kérdés az adatbázisok karbantartása, a központosított és az elosztott kezelés megfelelő összhangjának megtalálása. 2.1.
A pályázás támogatásának fázisai • Pályázati felhívás és útmutató előállítása: verziókontroll, szövegváltozatok kezelése és generálása, pályázati portál stb. • Pályázati űrlap, más adatlapok és nyilatkozatok előállítása • Pályázati űrlapok és pályaművek fogadása, ellenőrzése, feldolgozása
Mára megszokottá, természetessé vált, hogy a pályázók szinte kivétel nélkül szövegszerkesztővel, táblázatkezelővel és más programokkal készítik el a projektjavaslatokat, és utána kinyomtatva adják be. Nem okozna gondot, hogy a nyomtatott változat mellett vagy helyett az elektronikus változatot is beadják. (Az IKTÁ-ban ez már évek óta követelmény, az OM KFHÁ többi pályázatánál 2002-ben csupán kérés volt, amelynek számos pályázó eleget tett; 2003-ban az OM KFHÁ összes pályázatánál követelmény volt, amelynek 780 pályázó önálló, ill. konzorcium - eleget tett.). A pályázók a projektjavaslatok összeállításához szívesen használ(ná)nak olyan programokat, amelyek a munkájukat megkönnyítik, azaz • ellenőrzik a bevitt adatok formai helyességét, ellentmondás-mentességét és a korlátok betartását, • figyelmeztetnek egyes adatok hiányára, • előállítják a származtatott adatokat, sőt ennél többet is segítenek azzal, hogy • meghatározzák a projektjavaslat elvárt szerkezetét, és
2
•
vezetik a pályázót a projektjavaslat összeállításában. Az adatok helyességének ellenőrzött volta, az előírt szerkezet betartása stb. a pályázatkezelők és bírálók feladatát is megkönnyíti, ezzel hozzájárul a teljes pályázási folyamat minőségének javulásához. A pályázás elektronikus támogatásán belül további fázisokat különböztethetünk meg, többek között: 1. A pályázati felhívások és háttéranyagok (pl. jogszabályok) közreadása a weben („pályázati portál”). 2. Egy-egy pályázati rendszeren belül egységesített - esetleg kismértékben eltérő - pályázati űrlapok. 3. Összefoglaló: nyilvánosságra is hozható, magyarul és angolul; a bírálóknak szóló, magyarul, esetleg angolul is. 4. Munka- és költségterv (azokban a pályázatokban – pl. a tematikus pályázatokban -, ahol részletes munka- és költségtervet kell készíteni, egységes lehet; az eltérések megfelelő tervezéssel és programozási technológiával kezelhetők). 5. A projektjavaslatok elektronikus beadása off-line: mágnes- vagy CD-lemezen és/vagy online: elektronikus levélben vagy weblapon ún. feltöltéssel. 6. A projektjavaslatok elektronikus változatának fogadása: lemezek, elektronikus levelek, feltöltések; manuális, félautomatikus, ill. automatikus kezeléssel. 7. Relációs adatbázis építése a projektjavaslatok adataiból - egyedi pályázatonként, ill. közös minden pályázatra, kimutatások. 8. Elektronikus aláírás kezelése, hitelesítés. 2.2.
A bíráltatás és döntés támogatásának szintjei • Bírálók pályáztatása • Bíráltatás (elektronikus támogatással) • Döntés előkészítés (bizottságok), statisztika • Döntés nyilvánosságra hozása, értesítő levelek, bírálatok kiküldése, szerződéskötési ajánlat • Döntésről lista a webre, projektcélok magyarul és angolul (a projektkövetés kezdete) Nagy szükség van rá, ki van próbálva (IKTA), de rugalmas és átfogó megvalósítása nehéz. 1. Szakértői relációs adatbázis építése: adatlap, szakmai önéletrajz, kompetenciák leírása kulcsszavakkal (pályázatonként külön létrehozása!), ehhez tezaurusz kialakítása szükséges. 2. Bírálati relációs adatbázis építése: egyéni bírálatok, csoportos bírálatok, szakértői bizottsági bírálatok, zsűrik döntési javaslatai, döntések és indoklásuk; projektköltség és támogatási összeg, szerződéskötési feltételek kezelésével. 3. A bírálatok elektronikus fogadása: „távmunka”. 4. A teljes bírálati munkafolyamat követése (workflow), kimutatások, jelentések, statisztika összeállítása. 5. A pályázóknak kiadandó/kiadható bírálatok összeállításának támogatása. 2.3.
A szerződéskötés támogatásának szintjei • Általános tájékoztató és pályázó specifikus hozzáférésű pályázati portál: adatbázisok alapján automatizmusokkal segíti a szerződéskötést • A szerződéskötésnél megjelenő új adatok rögzítése az adatbázisban, szerződésmódosítások kezelése, a munkafolyamat követése
3
1. A szerződéskötési menetrend, a szerződésminta-űrlapok, a mellékletek elkészítéséhez szükséges űrlapok, valamint az ún. támogatásigénylő űrlapok közreadása a weben (az űrlapok adatai adatbázisból származzanak). 2. A szerződéskötéshez szükséges háttéranyagok (pl. jogszabályok) közreadása a weben (az 1.-2. pont a pályázati portál keretében valósítandó meg). 3. A szerződéskötés dokumentumainak rögzítése adatbázisban: alapadatok, szkennelt okiratok, szerződésmódosítások stb. 4. A teljes szerződéskötési munkafolyamat követése (workflow), kimutatások, jelentések, statisztika összeállítása. 2.4.
A projekt (szakmai, ill. pénzügyi) követésének támogatási szintjei • Projektkövetés § pénzügyi, jogi - megoldott § szakmai – megoldatlan • Szakmai (tartalmi) projektkövetés § nyilvános (beszámolók, előadások, zárójelentés, hasznosítás stb.) – Extranet! § nem nyilvános (jelentések, bírálatok, hiányosságok stb.) – Intranet! § Kereshető adatbázis a webre!
Az IKTA pályázattal szerzett tapasztalatok alapján a megvalósítása, ha az előző szintek megvannak, nem okoz különösebb szakmai nehézséget. A kitűzendő feladatok egy részét a 2002. januárjától felfutó rendszerben működő Nemzeti Kutatás-nyilvántartó Rendszer meg fogja valósítani, azonban a rendszerben tárolt adatok köre, elsősorban a rendszer átfogó, nemzeti jellege miatt, erősen korlátozott, és ez a projektek eredményességének megítélését, az eredmények nyilvánosságát korlátozza. Az alábbi 3. és a 4. pontok azok, amelyek a projekteredmények nyilvánosságra hozásával, folyamatos karbantartásával és hozzáférhetővé tételével különösen fontosak lehetnek a közpénzek felhasználásának átláthatóvá tétele érdekében. 1. Szakmai beszámolók elektronikus fogadása, tárolása. 2. Pénzügyi elszámolások összefoglaló részének elektronikus fogadása, tárolása. 3. Közzétételre szánt beszámolók elektronikus változatának fogadása, publikálása a weben. 4. Projekt-adatlapok generálása és publikálása a weben. 2.5. A megvalósításról A rendszernek nyitottnak, skálázhatónak, modulárisnak (többrétegűnek) kell lennie. A feladathoz illő programozási technológiát kell használnia (relációs adatbázis-kezelő, Internet/intranet-techológia, XML/XSL/HTML stb.). Több fázisban, a fokozatosság elvének betartásával, a tapasztalatok folyamatos figyelembe vételével kell megvalósítani. A tárolás alapját az XML fájl képezi. Minden adat először ebben a formátumban kerül rögzítésre. Ezt követően kerül az adat az adatbázisba, ha annak van értelme. Egyes esetekben, mint a beszámolók, jogszabályok tárolása, nincs értelme adatbázisnak, így ez esetben csupán az XML az egyetlen tárolási mód. Az adatok konzisztenciájának biztosítása érdekében, ha módosul bármely XML fájl, az azonnal érvényre jut a relációs adatbázisban is. Egy ilyen rendszer fő alrendszerei célszerűen a következők: 1. Űrlapkitöltő és projektterv-leíró alrendszer a KMŰFA-pályázatokhoz (AR1): a. 1. modul: a projekt alapadatait és a pályázók adatait tartalmazó űrlapokat állítja elő (amennyire lehet, ellenőrzötten).
4
2.
3. 4. 5.
6. 7. 8. 9.
b. 2. modul: a munkaterv költségtábláit és egyéb kötött elemeit (táblázatait) segít kitölteni (ellenőrzötten). c. Az összes mező nevét és tartalmát előre meg kell határozni. d. A pályázó saját számítógépén lokálisan, ill. Internet, Intranet hálózaton keresztül is működnie kell. e. Az adatokat XML formátumban kell előállítania. Törzsadat-szerver alrendszere (AR2): a. Alapvető, hogy a társaságok és személyek (pályázók, kedvezményezettek, munkahelyek, szakértők, bírálók, téma- és projektvezetők stb.) egymással is összefüggő törzsadatait szigorúan felügyelt és karbantartott rendszerben tároljuk, kezeljük. A többi on-line rendszer meghatározott módon ettől a rendszertől kérhet/kaphat adatokat. Pályázatkezelő alrendszer (AR3): a. A projektjavaslatok, pályaművek adatait fogadja (amelyeket az AR1 állít elő). A bíráltatást segítő alrendszer (AR4): a. A bíráltatást és a döntés előkészítésének további fázisait segíti. A támogatási szerződések megkötését és a támogatások kifizetését segítő alrendszer: az AR3 költségvetési adataira alapozva nyilvántartja a elszámolásokat, kifizetéseket stb. (AR5). A szakértői megbízási szerződések megkötését és kifizetéseiket segítő alrendszer (AR6). A projektkövetést segítő alrendszer: az AR3 munkatervi adataira alapozva nyilvántartja a beszámolási határidőket, a beszámolókat, az ezekről készült értékeléseket stb. (AR7). A nyilvánosságra hozandó adatok megjelenítését segítő alrendszer (AR8). A napi munkavégzést segítő állomány-szerver, levelező, fórumozó stb. alrendszer (AR9).
3. Űrlap feldolgozás – adattárolás 3.1. Tervezési szempontok Az új űrlap kitöltő-fogadó-feldolgozó rendszer fejlesztésének kezdetén két szempontot igyekeztünk szem előtt tartani: az űrlap szerkezet könnyen szerkeszthető legyen úgy, hogy az esetleges változásokat, illetve az új típusú űrlapokat programozási készségekkel kevésbé felvértezett felhasználók is fel tudják vinni. Másrészt célunk volt az egyes űrlapelemekhez tartozó megkötéseket (szintaktikai és szemantikai kényszereket egyaránt) jól elkülönülve kezelni, hogy azok szerkesztése és bővítése könnyen elérhető legyen a változások követése során. A munka előre haladtával aztán más szempontok is előtérbe kerültek: látszott hogy egy űrlap megjelenítéséhez többfajta eszközben kell gondolkodnunk, az elsőre természetesnek tűnő webes hozzáférésnél sokkal célszerűbb lehet egy off-line kitöltő, sőt ezek közül is hasznosabb lehet egy kitöltő alkalmazás helyett valamilyen speciális – makrókkal gazdagított - dokumentum (Excel, Word) vándoroltatása. Ugyanígy látható volt, hogy az adattárolásnál is sokféleeszközzel kell együttműködni (fogadási adatbázis, pénzügyi adatbázis – Lotus Notes, webes publikálása adatbázisa stb.). Emellett sok tekintetben - elsősorban a már említett kényszerek definiálhatósága érdekében - célszerűnk látszott egy a gépi feldolgozást segítő, de strukturált formára alakítása: egy XML szerkezet létrehozása. Egy-egy űrlap-elemhez (mezőhöz) tehát definiálni kell megjelenítés-beli elhelyezkedését és tulajdonságait; a rá vonatkozó (szintaktikai) kényszereket; adatbázisbeli helyét – esetleg több adatbázisra is megadva; az XML struktúra-beli helyét. Nem mezőhöz tartozó tulajdonságokat (egyes megjelenítési tulajdonságok, szemantikai kényszerek) szintén érdemes rendezett szerkezetben – ugyanebben a leíróban – szintén XML formában tárolni. Ez a mezők közötti összefüggések jellemzőinek tárolására is alkalmas lehet. 5
3.2. XML, ahogy mi használjuk Az űrlap adatainak ellenőrzését azok XML struktúrába rendezése után struktúra-béli helyük alapján végezzük. Az adatok jellege egyébként is szinte ordít egy effajta megjelenítésért. Az XML kínálta fa szerkezet megfelel igényeinknek, egyedül – épp az egyértelmű és kényelmes adatelérés miatt – azt a kikötést tesszük, hogy bár az űrlapon néha előfordul azonos jellegű adatok egymást követő sora (pl. a pénzügyi táblázatban), mégsem engedjük meg, hogy ugyanazon útvonal adott szintjén több azonos elnevezésű csomópont (node) legyen. Ilyen esetekben sorszámozott node-neveket használunk. Az említett XML formájú leírónkban valamennyi adatelemet felsoroljuk, ezek aláosztott node-jaiban rendre tároljuk az XML struktúra-beli helyet, az adatbázis mezőnev(ek)et (fogadási, Lotus) és a formai követelmény két attribútumát. A megjelenítési tulajdonságokat jelen rendszer – a későbbiekben ismertetett okokból - nem tartalmazza. A szemantikai kényszerek kezelését sem fedi le a jelenlegi megvalósítás. 3.3. Felületek (Excel, Java form, html: célja cserélhetőség) Ahogy a leíró megadja egy-egy mező legfontosabb feldolgozási paramétereit úgy tárolhatná megjelenítési tulajdonságait is. Így ez vezérelhetné a megjelenítést is, generálná az űrlapot (egy drag&drop-os wysiwyg – what you see is what you get jellegű szerkesztő pedig editálhatná ezt a leírót). A leíró megjelenítésére alkalmas technikák az off-line használat nehézségei miatt (pl. PHP/JSP generálta HTML) vagy nagy mennyiségű háttérkód hordozása és speciális környezetigényük miatt (Java form felület) nem látszottak alkalmasnak (bár egy JSP elvű megjelenítési próba-megvalósítás elkészült). Így került előtérbe egy a felhasználók irányába talán barátságosabb megoldás: Visual Basic kódok segítségével a hasznos tartalmat speciális text fájlba kimenteni képes Excel dokumentum. Ez a leíró általi vezérelhetőséget nem teszi lehetővé, és platformfüggetlenségét tekintve is elmarad az említett lehetőségektől. További hátrány, hogy kitöltő oldalon nincs mód szintaktikai ellenőrzésre (ehhez szükséges lenne a leíró XML vándoroltatása és érdemleges VB-es feldolgozhatósága). Az Excel form megoldás esetén az űrlapkinézet az Excelben szerkeszthető. A leíró XML-t az Excel-es űrlap speciális kitöltése után programmal generáljuk, amely megoldja az ellenőrzés és az adatbázisba vitel számára az egyértelmű megfeleltetést. Az Excel csökkentett képességei miatt az űrlapkinézethez szükséges leírórészben használatos nyelvezet kidolgozására nem volt szükség. Egy teljesen a leírótól vezérelt rendszernél ezzel a szép feladattal is meg kellene birkóznunk. Próbálkozások történtek, de a felmerült problémák megoldására nem volt idő. Az Excel szintjén nem foglalkozunk a strukturált adat XML előállításával. A „kimentő” algoritmusunk csak a hasznos adatokat sortöréssel elválasztva tároló (XML fejléces) text fájlt állít elő, ez a beküldési formátum. Ebből generál egy java alkalmazás strukturált adat XML-t, mely felhasználja a mezőket leíró XML-t. 3.4. A feldolgozás/ellenőrzés Ez a strukturált forma teremt lehetőséget arra, hogy az adatállomány (amelyet pl. szintaktikai ellenőrzésre és a tárolás segítésére használunk) független legyen a megjelenítéstől, pl. az űrlapkép konkrét mezősorrendjétől (a beérkezett állomány sorai az űrlap mezőinek sorrendjét követték). Ez a függetlenség egyben megjelenítő eszköz függetlenséget is jelent: ha a későbbiekben más technológiákkal kívánjuk a kitöltést segíteni (pl. a már említett Java form) akkor a kitöltőnek – a leírót figyelembe véve – ilyen formátumra kell csak hoznia a kimeneti fájlt. A feldolgozás további menete (szintaktikai ellenőrzés, adattárolás) ez alapján folyhat (ebből a szempontból az Excel és a strukturált XML-lé formáló alkalmazás jelenti jelen állapotban a megjelenítési rétegeket). 6
A szemantikai ellenőrzés – amely az összefüggésben részt vevő mezők jó megcímezhetőségét igényli, szintén csak ilyen kifinomultabb struktúra esetén képzelhetően el. A szintaktikai hibák felderítéséhez legtöbbször csak egy adatmező tartalmát kell látnunk, és ezt a tartalmat kell formailag vizsgálnunk, szemantikai vizsgálatnál több mezőtartalom közötti összefüggések meglétét követelhetjük meg. Az általunk megvalósított szintaktikai ellenőrzéshez típusokat definiáltunk, és ehhez rendeltük a kényszereket. Egy mező leíró blokkjában a típusmegnevezés mellett egy szám jellegű adatot (legtöbbször hosszjellemzőként) is rögzítettünk. Típusaink általánostól (sztring, szám) egészen speciálisig terjedtek (adószám, dátumelem). Míg az előzőhöz jellemzően ellenőrző algoritmusok tartoztak, hogy minden karaktere adott osztályú-e, addig utóbbihoz karakterszámot, formai megkötéseket kellett rendelni (számon kívül kötőjel is lehet benne, vagy pontra is végződhet stb.). A típushoz tartozó megkötések ellenőrzését – adatonként haladva – külön modul végzi, az ellenőrző algoritmusok ebben vannak implementálva. A rendszer újabb típusok bevezetésével és a hozzájuk tartozó algoritmusok elkészítésével fokozatosan fejleszthető, így kezdetben egyszerűsített ellenőrzésekkel is működőképes. 3.5. Adatbázis Adatbázisunk cserélhetősége miatt is jól használhatóak a bevezetett típusok. Adatbáziskezelőnként külön listában rendelhetünk saját típusainkhoz az adott adatbázis-kezelőben használatos típusokat. Így éppúgy számként fog megjelenni a kötőjeleitől megtisztított adószám, és pl. az irányítószám, de lehet, hogy int vagy integer típusú mezőbe töltődik be. Az alkalmazás a fogadó adatbázis generálására is alkalmas: a leíró XML a mezőneveket és a típusokat tartalmazza - utóbbit közvetve, a típusmegfeleltető listákon keresztül. Hiányosságként írható le, hogy a mezőink csoportosítása egyelőre nem átgondolt: több adattábla esetén hova kerüljön egy mező tartalma, esetleg több táblában is szerepeljen, illetve melyik adatlapon jelenjen meg (többlapos űrlap esetén). Ezek jelenleg a kódba szerkesztetten jelennek meg, csak úgy mint a táblák közötti kapcsolati mezők vagy a tartalomtól független adatok (beküldési e-mail cím, beérkezési dátum, beérkezés fájlneve, stb.).
4. Űrlap befogadás kezelése A feldolgozó program az e-mailen keresztül beküldött pályaművek fogadását, csatolmányának, azaz az űrlapnak a leválasztását, majd adatbázisba töltését végzi. A fogadás és a csatolmány leválasztása egymástól teljesen független folyamat. Ezáltal a pályaművek érkezési sebessége és feldolgozásuk sebessége nem befolyásolják egymást, azaz az esetleges torlódások nem jelentenek problémát. 4.1. Levél eltárolása Levél érkezésekor az alkalmazás megvizsgálja: mailer-daemon, azaz levelezőrendszer által generált üzenet jött-e. A generált üzenetek korai kiszűrésével gyorsítjuk alkalmazásunk futását. A megfelelő üzenetek egyedi névvel ellátva megadott könyvtárba kerülnek. A név két részből áll: a küldő e-mail címe és egy egyedi szám, mely annak a folyamatnak az azonosító száma, mely elhelyezte a levelet: [email protected] Az eltárolás során a beérkezett levelek egy várakozási sorba jutnak mindaddig, míg további feldolgozásuk, azaz csatolmányuk leválasztása meg nem történik. Ezáltal nagy számú levél egyidejű érkezésekor a lassabb feldolgozási folyamat egyesével, sebességének megfelelően kapja az e-maileket. Hasznos, ha a pályaművek állapotával kapcsolatban a pályázó információt kap, ezért őt e-mailben értesítjük a tárolás megtörténtéről. A mailerdaemon stb. rendszer üzenetek nem kapnak választ a „gerjedés” elkerülése érdekében. 7
Az eltárolást követően a program második moduljára vár a csatolmányok leválasztásának és adatbázisba töltésének folyamata. 4.2. Csatolmányok feldolgozása A csatolmányokat a pályázónak előre megadott formátumban kell beküldenie, ezt a program ellenőrzi. Az előre megadott formátum a következőket jelenti: - A csatolmány csak 1 db kódolt ZIP fájlt tartalmazhat, melynek neve a következő módon áll össze: AAA-BBBBBBBB-0-EEHHNNOOPP ahol: AAA - a pályázat rövid 3 vagy 4 jegyű azonosítója BBBBBBBB - a pályamű 8 karakteres azonosítója 0 - jelzi, hogy ez a teljes űrlap (a program képes fogadni űrlap részletet is) EEHHNNOOPP – az űrlap elmentésének pontos dátuma (év,év-hó,hó-nap,nap-perc,perc-mperc,mperc) - A ZIP fájlnak 1 db XML fájlt szükséges tartalmaznia, mely nevének szintén szabványosnak és a ZIP fájl nevével megegyezőnek kell lennie. - Ezt a nevet a levél tárgyában is meg kell adni az ügyfélszolgálati munka segítésére. A megoldás miatt biztosított, hogy a pályaművet az űrlapkitöltő programmal csomagolták össze. Amennyiben a pályázó megfelelően, tehát a fenti módon küldi be munkáját, az a kitömörítés elvégzését követően pályázatonként csoportosítva eltárolásra kerül. Jelenleg a pályázók, a rendszer közelmúltban történt bevezetése miatt, gyakran a kért formátumtól eltérően küldik be pályaművüket. Az alkalmazás erre is fel van készítve. Amennyiben a csatolmány elnevezése nem helyes, de tartalmaz szabványos elnevezésű XML fájlt – azaz vélhetőleg helyes űrlapot - az a fenti módon, csoportosítva kerül eltárolásra. A többi előforduló csatolmány (pl. xls, txt, jpg, doc, rtf) eltérő helyre kerül, hiszen nincsen rájuk szükség. Ha valamilyen hiba csúszik a feldolgozási folyamatba, a hiba súlyosságától függően vagy a soron következő levél feldolgozása kezdődik meg (például csatolmány hiánya esetében), vagy folytatódik e levél további feldolgozása (például sérülés, hibás fájl küldés esetén). Utóbbi esetben, ha a hibát valamely csatolmány okozta, az eltárolásra kerül, de szintén külön e célra létesített helyen. Amennyiben a pályázó többször küldi be ugyanazt az űrlapot, vagy régebbit küld be, azok figyelmen kívül lesznek hagyva. Újabb űrlap beküldése esetén a régi verzió frissítésre kerül. 4.3. Adatbázisba töltés A feldolgozás utolsó - harmadik – lépése az előírásoknak megfelelően beküldött XML fájlok szerkezeti és tartalmi ellenőrzése. A teljesen hibátlan XML fájlok ezt követően bekerülnek az adatbázisba. Ha a fájl hibát is tartalmaz, akkor nem kerül az adatbázisba feltöltésre. A feldolgozási folyamat 4.2 és 4.3. része rögzítésre kerül egy log fájlban oly módon, hogy a most feldolgozott levélről keletkezett információk a már meglévő log fájlhoz hozzáfűződnek. Így az összes levélhez kapcsolódó események egy log fájlban láthatóak. Egy levél log-olása az alábbi módon történik: Mon Mar 1 12:19:40 CET 2004 [email protected]: 1. Levélformátum: Ok.
- levélküldés ideje és küldő e-mail címe - a levélformátum vizsgálat eredménye
8
- csatolmány vizsgálat eredménye (szabványos vagy nem) - sikerült-e az XML fájlt az 3. XML spoolba feltöltés: Ok. adatbázisba feltöltés sorába elhelyezni - sikerült-e az XML fájlt a megfelelő 4. Fájlfeltöltés (fájlnév:MEC1-19750917-0-0402160902.xml): Ok. helyre másolni 5. Szabványos XML előállítás: Ok. - történt-e adatbázisba töltés, ha nem 6. Adatbázisba töltés (hibák miatt): Sikertelen. - hibák felsorolása 2. Csatolmány (szabványos): Ok.
Részletezés: - szintaktikai hiba: Hiba a következő adatban: ev1/ho1 (22. A pályázó költségvetése munkalap H 8 cella) : Kötelezően elvárt mező nincs kitöltve.
- pályaműben előforduló hibák jelzése
A feldolgozás eredményéről a pályázó újabb válaszlevélben kap tájékoztatást. A levél tartalma lényegében a log fájl adott levélhez tartozó tartalmával egyezik meg, de részletesebb szövegezéssel. A log fájl inkább az eseményekre és a tömörségre koncentrál. A levélben felsorolt hibák kijavításával a pályázónak ismét be kell küldenie űrlapját. E lépés a hibák megszűntéig tetszőleges alkalommal ismételhető, hiszen mindig csak a legfrissebb verzió kerül eltárolásra. A hibátlan beküldés után, a nyugtázó levél kiküldésével párhuzamosan, az űrlap adatai az adatbázisba kerülnek. Nagyobb mennyiségű levél beérkezésekor igen nagyméretű log fájl keletkezik, hiszen az az összes levél feldolgozásának lépéseit tartalmazza. E fájlnak az áttekintése szinte lehetetlen, ezért erről egy segédalkalmazás megfelelő felparaméterezésével kimutatások készíthetők.
5. Elektronikus bíráltatás 5.1. Követelmények a bírálati dokumentációkat kezelő rendszerrel szemben A kutatás-fejlesztési projektjavaslatok bírálati folyamatában – az adott pályázat sajátosságait figyelembe véve - több szinten keletkeznek dokumentumok, úgymint: o egyéni szakértői bírálatok; o az egyéni bírálatokból összeállított ún. csoportbírálatok; o a csoportbírálatokból a szakmai bizottságok véleményével kiegészített bizottsági bírálatok; o a szakmai bizottsági bírálatokból a zsűri (alprogrambizottság, programbizottság stb.), véleményével kiegészített döntési javaslat; o a szakmai bírálatok pályázóknak kiadandó változata (amely a bírálók nevét nem tartalmazza). A rendszer feladata a bíráltatás támogatása, nevezetesen a rendszernek o tartalmaznia kell az egyes pályázatok bírálati űrlapmintáit; o beépített szövegszerkesztővel segítenie kell a bírálatok elkészítését, a hozzáférési jogosultságok kezelését, az adatvédelmet, és meg kell oldania az elkészült bírálatok azonosíthatóságát; o lehetővé kell tennie a dokumentumok leszármaztathatóságát abban az értelemben, hogy a bírálati folyamatban olyan új dokumentumokat lehessen létrehozni, amelyek tartalma részben vagy egészben a már meglévő dokumentumokból képződik. A leszármaztatási szabályokat adatszerűen lehessen megadni.
9
Alapkövetelmény a platformfüggetlenség, dokumentált struktúrájú XML állományokon keresztüli adatcsere, off-line dokumentumszerkesztés és új űrlapminták és jogosultsági adatok betöltése. Előnyös, ha alkalmas helyesírás ellenőrzésre. A bírálói űrlapot azok a szakértők töltik ki, akik bírálatra (vagy az értékeléssel kapcsolatban más szakértői tevékenységre) vállalkoznak. Ez az űrlap Weblapon nyilvánosan elérhető. A beküldésekor szabványos formátumú életrajz csatolása szükséges. A bírálati űrlapokat a projektjavaslatokat értékelő szakértők töltik ki. Az egyéni anonim űrlapot kivéve ezek elérhetők belső hálózaton, mert ezeket a zárt ülésen töltik ki, az egyéni anonim űrlapot pedig lokálisan (otthon). Az űrlapok elektronikus levélben és (mágnes)lemezen fogadhatók. A szakértői bizottságok (szakmai bizottságok) és a zsűri jegyzőkönyve formalizált. 5.2. Megvalósítás A megvalósított rendszer egy speciális aláírás fájl segítségével és többszintű hozzáférés lehetőségével biztosítja a jogosultságok és a hitelesítés kezelését, valamint a publikus csatornákon továbbított anyagok védelmét. A rendszer támogatja a döntés után a szakmai bírálatok pályázóhoz eljuttatandó változatának előállítását. Ezt a Scriptum Kft. készítette, egyelőre az IKTA, EEF, KMA és CSI pályázatoknál használtuk.
6. Összefoglalás A cikkben kivonatosan próbáltuk bemutatni a kutatás-fejlesztési pályáztatás folyamatát és elektronikus támogatásának lehetőségeit. A szerteágazó feladatok megoldására univerzálisan használható rendszer még nem született, ilyet véleményünk szerint egy lépésben nem is lehet megvalósítani. Az egyes részfeladatok megoldását támogató próbálkozások és azok összekapcsolási kísérletei alapján azonban sok olyan tapasztalat halmozódott fel, ami időszerűvé teszi egy átfogó rendszer tervezését és elkészítését, ezzel a rendszeresen ismétlődő, rengeteg kézi munka jelentős részének gépesítését. A hatékony megoldás érdekében szükségesnek látszik: - A pályáztatáshoz kapcsolódó egyéb országos rendszerek (MÁK, NKR, cégadatbázisok, címjegyzékek, stb.) közötti elektronikus átjárhatóság, egységesítés növelése. - A más jellegű pályáztató rendszerekkel közös részek és az eltérő sajátosságok moduláris felépítésen alapuló kezelése. - A különböző oldalakról érintett résztvevők (pályázók, bírálók, pályázatkezelők, stb.) elektronikus feldolgozással kapcsolatos ismereteinek fokozatos, de folyamatos növelése.
10
