e-Levéltár
NISZ, MNL, BFL konzorcium
T-Systems Zrt.
e-Levéltár
Projekt Alapító Dokumentum
„Elektronikus levéltár szoftver és hardver elemeinek szállítása, valamint kapcsolódó szolgáltatások teljesítése” tárgyú szerződés teljesítéséhez
Budapest, 2013. február. 26.
File:
C:\Users\Tihanyi\Desktop\Documents\MNL\2013\29_ELEV_vallalasok\ELEV_PAD_2_0_ 20130226.doc
Oldala:1 / 85
Dokumentum azonosító: e-Levéltár - PAD Kiadás: 2012.12.03.
Létrehozta: Xxxxxxxxxx Xxxxxx Xxxxxxxxxx: Xxxxxx Xxxxxx
Dokumentum adatok
Cím Projekt Alapító Dokumentum
Projekt Elektronikus levéltár szoftver és hardver elemeinek szállítása, valamint kapcsolódó szolgáltatások teljesítése
Rendszer e-Levéltári rendszer
Tárgy Projekt Alapító Dokumentum Szerző(k) Xxxxxxxxxx Xxxxxx, Xxxx Xxxxx Felelős Xxxxxxxxxx Xxxxxx
Megrendelő NISZ – MNL – BFL konzorcium
Fájlnév elev_pad_2_0_20130226
Azonosító e-Levéltár - PAD
Verzió V2.0
Kiadva 2013.02.26.
Oldalszám 85
Minősítés Projekt management dokumentum
Dokumentum életrajz
Verzió | Dátum | Szerző | Jóváhagyó (vállalkozó) | Jóváhagyó (megrendelő) | Leírás |
v0.01 | 2012.10.21. | Xxxxxxxxxx Xxxxxx | Első munkaváltozat | ||
v0.02 | 2012.10.29. | Xxxxxxxxxx Xxxxxx | Észrevételek alapján átdolgozott verzió | ||
v0.03 | 2012.10.28. | Xxxxxxxxxx Xxxxxx | Észrevételek alapján konszolidált verzió | ||
v0.04 | 2012.10.29. | Xxxxxxxxxx Xxxxxx | Konzorciumnak átadott első munkaverzió | ||
v0.1 | 2012.11.08. | Xxxx Xxxxx, Xxxxxxxxxx Xxxxxx | Műhelymunkán korrigált, kiegészített verzió | ||
v0.11 | 2012.11.12. | Xxxxxxxxxx Xxxxxx | Apró kiegészítések, elírások javítása, gépterem kiépítés előfeltételek berakása. | ||
v0.12 | 2012.11.12. | Xxxxxxxxxx Xxxxxx | Vállalkozó oldali névlista véglegesítése. | ||
v0.13 | 2012.11.14. | Xxxx Xxxxx | Kapcsolódó dokumentumok pontosítása, megrendelő oldali névlista pontosítása, oktatási terv, VII. számú melléklet – heti jelentés sablon | ||
v0.14 | 2012.11.14. | Xxxxxxxxxx Xxxxxx | Érdekeltek ábra hiba javítása, projektszervezet ábra kiegészítése az ismert nevekkel. | ||
v0.15 | 2012.11.14. | Xxxx Xxxxx | Megrendelő oldali névlista pontosítása | ||
v0.16 | 2012.11.16. | Xxxx Xxxxx | Megrendelő oldali névlista véglegesítése, apró javítások | ||
v1.0 | 2012.11.16. | Xxxxxxxxxx Xxxxxx | Projektszervezeti ábra véglegesítése. | ||
v1.1 | 2012.12.03. | Xxxx Xxxxx, Xxxxxxxxxx Xxxxxx | Kontaktok aktualizálása, ütemezés beillesztése, pontosítások. | ||
v2.0 | 2013.02.26. | Xxxx Xxxxx, Xxxxxxxxxx Xxxxxx | Szereplők módosítása Ütemterv részleges módosítása Kockázatkezelés újraszabályozása Minőségbiztosító rögzítése Sablonok módosítása |
Azonosító | Verzió | Cím |
Elev_Gen_Szerzodes_NISZ-MNL-BFL-TSM_20121018_alairt.doc | 2012.10.18. | Szerződés |
2012.11.14. | Szerződés 1. számú módosítási terve | |
E-lev_Gen_Vegl_Musz_leiras_20120710_v1_0 E-lev_Gen_Vegl_Musz_leiras_1_sz_mell_Kov_jegyz_20120710_v1_0 E-lev_Gen_Vegl_Musz_leiras_2_sz_mell_ HW_ig_megl_eszk_bemut_20120710_v1_0 E-lev_General_Muszaki_leiras_3_sz_melleklet_ LNYR_igenyek_v2_0 | 2012.10.18.. | Szerződés 1. számú mellékelt – Végleges műszaki leírás és mellékletei |
E_ARCH_Vegl_Szakmai_Ajánlat_20120720_final.docx és mellékletei | 2012.10.18. | Szerződés 2. számú melléklete – Ajánlatevő végleges műszaki és kereskedelmi ajánlata |
E-lev_Gen_Szerz_3sz_mell_Vegl_Ker_artablazatok_20120720 | 2012.10.18. | Szerződés 3. számú melléklet – Kereskedelmi ártáblázatok |
E-lev_Gen_Szerz_5sz_mell_Resztelj-Fiz_utem_20120720 | 2012.10.18. | Szerződés 5. számító melléklet - Részteljesítési és fizetési ütemezés |
Elev_Gen_Szerz_6sz_mell_Szoftverterm_lista | 2012.10.18. | Szerződés 6. számú melléklet - Szoftvertermékek listája |
FB jóváhagyás
Név | Szervezet | Aláírás |
Xxxxx Xxxxxx Xxxxxx | XXXX | |
xx. Xxxx Xxxxxxxxx | MNL | |
xx. Xxxxxxxx Xxxxxx | BFL | |
Xxxxxxxx Xxxxxx | T-Systems |
Tartalomjegyzék
Tartalomjegyzék 4
1. Bevezetés 7
1.1 A dokumentum célja 7
1.2 A dokumentum tartalma 7
1.3 A dokumentum hatóköre 8
1.4 Meghatározások, rövidítések 8
2. Projektismertető 10
2.1 Előzmények 10
2.2 A projekt célja 12
2.2.1 A pályázatban foglaltak megvalósítása révén elérni kívánt célok 12
2.3 Érdekeltek bevonása 15
2.4 A projekt terjedelme (hatóköre kiterjedése) 15
2.5 Nyilatkozat referenciáról 15
2.6 Előfeltételek 15
2.7 Szállítandók 17
2.7.1 Hardver és alapszoftver szállítás 17
2.7.2 Hálózat és szerverterem kiépítés 17
2.7.3 Készítendő termékek 17
2.8 Migráció 25
2.9 Kapcsolódó rendszerek, interface-ek 26
2.10 Oktatások 26
2.11 Megrendelőtől várt dokumentációk 27
3. A PROJEKTSZERVEZET FELÉPÍTÉSE ÉS MŰKÖDÉSE 28
3.1 A projektszervezet 28
3.1.1 A projektfelügyeleti (FB) szint 28
3.1.2 Projektirányítási (PVB) szint 28
3.1.3 Minőségbiztosítás 29
3.1.4 Projekt adminisztráció 30
3.1.5 Végrehajtási szint 30
3.2 Szerepkörök 31
3.2.1 Megrendelő oldali szerepkörök 31
3.2.2 Vállalkozó oldali szerepkörök 31
3.3 Résztvevők 32
3.4 Felek együttműködése, rendelkezésre állás 32
3.5 Projekt kommunikáció 33
3.5.1 Alapelvek 33
3.5.2 Kommunikációs csatornák 34
3.6 Munkavégzés, munkarend 37
3.6.1 A munkavégzés helye 37
3.6.2 Munkaidő 37
3.6.3 Szabadságolási rend 38
4. Vállalkozó oldali Minőségbiztosítás 38
4.1 Minőségbiztosítási terv 38
4.2 Minőségügyi szemlék 39
4.3 Mérések a projektben 39
5. Változáskezelési terv, a projekt terjedelmének kezelése 39
6. Tesztelési terv 40
7. Projekt terv 40
7.1 Projekt szakaszok 40
7.2 Ütemterv 41
8. Projektirányítás 41
8.1 Tervezés 41
8.2 Haladás ellenőrzése, jelentések 42
8.3 Átadás-átvételek 42
8.3.1 Tessella SDB, scopeArchiv és Oracle licencek átadás-átvétele 43
8.3.2 Infrastruktúra elemek mennyiségi átadás - átvétele 43
8.3.3 Kiépített hardver infrastruktúra átadás - átvétele 44
8.3.4 Dokumentumok átadás - átvétele 44
8.3.5 Szoftver rendszerek átadás - átvétele, hibakezelés 45
9. A PROJEKT ELJÁRÁSRENDJE 47
9.1 Projekt rendezvények 47
9.1.1 Felügyelő Bizottság ülése (FB) 47
9.1.2 Projektirányítás ülése (PVB) 47
9.1.3 Alprojekt/munkacsoport megbeszélés 48
9.1.4 Oktatás 48
9.1.5 Egyéb rendezvények 48
10. Dokumentációkezelés 48
10.1 Alapelvek, célok 48
10.2 Dokumentumok és szoftver verziók azonosítása 49
10.3 Dokumentumok nyilvántartása 49
10.4 Dokumentumok tárolása 49
10.4.1 Elektronikus dokumentumok (fájlok) tárolása 49
10.5 Archiválás 50
11. Adatkezelés 51
11.1 Az adatkezelés célja 51
11.2 Kezelt adatfajták 51
11.3 Az adatkezelés felelőse 51
11.4 Az adatok azonosítása 51
11.5 Az adatok formátuma 51
11.6 Adatok gyűjtése, tárolása, feldolgozása, szétosztása, az adatminőség biztosítása 52
11.7 Hozzáférési jogosultságok 52
11.8 Az adatok életciklusa, archiválás 52
12. Konfiguráció- és verziókezelés 52
13. KOCKÁZATKEZELÉS 53
13.1 Kockázatok kezelésének módja 53
13.2 Kockázatok 53
14. Mellékletek 54
I. melléklet, Projektszervezet 55
II. melléklet, Részletes ütemterv 57
III. melléklet, Szerep- és hatáskörök 60
IV. melléklet, Projekttag nyilvántartás 65
V. melléklet, Teszt terv sablon 70
VI. melléklet, Teszt jegyzőkönyv 77
VII. melléklet, Heti jelentés sablon 78
VIII. melléklet, Emlékeztető sablon 79
IX. Melléklet – Változáskérelmi lap sablon 84
1. Bevezetés
1.1 A dokumentum célja
A Projekt Alapító Dokumentum (a továbbiakban: PAD vagy dokumentum) célja, hogy a „Elektronikus levéltár szoftver és hardver elemeinek szállítása, valamint kapcsolódó szolgáltatások teljesítése” tárgyú szerződés teljesítésére létrehozott projekttel kapcsolatban megfogalmazza és minden, a projektben résztvevő szervezet és személy számára egyértelművé tegye a projekt szervezeti felépítését és működési rendjét, s ezzel elősegítse a projekt megvalósítása során elvégzendő tevékenységek összehangolását, minőségi teljesítését. A dokumentum célja a szerződés szerint a PAD- ban részletezett, továbbá a szerződésben nem, vagy nem részletesen tárgyalt együttműködési területek, vállalkozói, vagy megrendelői kötelezettségek, leszállítandók, átadás-átvételi kritériumok, feltételek részletes kifejtése.
1.2 A dokumentum tartalma
A PAD leírja:
• a projekt előzményét
• a projekt célját és terjedelmét,
• ütemezését,
• a szállítandó termékeket,
• a projektszervezetet,
• eljárásrendet,
• az átadás-átvétel folyamatát,
• az oktatási tervet,
• a projekt szervezet működésére vonatkozó előírásokat,
• a projektirányításra és a minőségbiztosításra vonatkozó irányelveket.
A dokumentum ismerteti a projekt indításának körülményeit, célját és a projekttől elvárt eredményeket, a szállítandó termékeket.
A dokumentum vázolja a projekt szakaszait és ütemezését, majd ismerteti a projektszervezet felépítését, működését.
A PAD része a projektszervezet működésének alapelveit meghatározó szervezeti és működési szabályzat. Ez a rész meghatározza a projektszervezet működéséhez szükséges tárgyi feltételeket, a projektben résztvevő szervezetek közti kommunikáció alapelveit, a projekt dokumentációs rendjét és a munkarendet.
A dokumentum megfogalmazza a projekt irányításával kapcsolatos feladatokat, a konfigurációk, a változások, és a kockázatok kezelésére vonatkozó alapelveket. Itt fogalmazódnak meg a főbb biztonsági követelmények és a minőségbiztosítással kapcsolatos igények.
1.3 A dokumentum hatóköre
A dokumentumban megfogalmazott alapelvek a projektben résztvevő minden szervezetre és projekttagra nézve kötelezőek a Megrendelői és a Vállalkozói oldalon egyaránt.
Amennyiben a szerződés és a PAD tartalma egymásnak ellentmond, a szerződésben foglaltak tekintendők kötelezően betartandónak.
A dokumentumot a projekt Felügyelő bizottsága hagyja jóvá.
1.4 Meghatározások, rövidítések
Fogalom/rövidítés | Magyarázat |
Alapszoftverek | A felhasználói alkalmazások működését lehetővé tevő szoftverek. Ide értjük többek között (de nem kizárólag) az eszközmeghajtókat, operációs rendszereket, alkalmazás szervereket, tűzfal- és terheléselosztó szoftvereket, vírusellenőrzőket, adatbázis-kezelőket. |
BFL | Budapest Főváros Levéltára |
ELP | Elektronikus Levéltári Portál. A T-Systems általános portálrendszerén alapuló portál alkalmazás, amely a nyilvános tartalmak közzétételét teszi lehetővé az Interneten keresztül. A nyilvános tartalmak tárolóhelye a Tessella SDB egy erre a célra implementált verziója. |
Felügyelő bizottság (FB) | A projekt legfőbb döntéshozó fóruma |
Hardver infrastruktúra | A leszállított hardvereket és a hozzájuk tartozó alapszoftvereket értjük alatta. |
KIA | Központi Archívum. A Tessella SDB ebben a projektben a központi archívum céljaira implementált verziója. A digitális tartalmak elsődleges kezelő- és tárolóhelye. |
KIFÜ | Kormányzati Informatikai Fejlesztési Ügynökség |
KIR | Központi Irattári Rendszer. A Tessella SDB ebben a projektben a központi irattári rendszer céljaira implementált verziója. |
KÜRT | KÜRT Információbiztonsági és Adatmentő Zrt. |
KRI | Külső Rendszer Interfész. A Központi Irattári Rendszer és KIA az iratképzők informatikai rendszerei között kapcsolatot teremtő interfész megoldás. |
LNYR | Levéltári Nyilvántartó Rendszer. A scopeArchiv ebben a projektben implementált változatát értjük alatta. |
LNYRK | Az LNYR-ben, mint dobozos termékben nem megvalósítható funkciókat megvalósító, a projekt keretében kifejlesztett rendszer (jogszabályi és funkcionális elvárások teljesítése). |
Fogalom/rövidítés | Magyarázat |
Megrendelő | NISZ – MNL – BFL konzorciuma |
MNL | Magyar Nemzeti Levéltár (a Magyar Országos Levéltár jogutódja) |
NISZ | NISZ Nemzeti Infokommunikációs Szolgáltató Zrt. |
PAD | |
Projekt | Az Elektronikus levéltár (EKOP-1.2.8) c. projekt keretein belül az „Elektronikus levéltár szoftver és hardver elemeinek szállítása, valamint kapcsolódó szolgáltatások teljesítése” tárgyú szerződés teljesítésére létrehozott alprojekt |
PVB | Projektvezetői Bizottság – a projektvezetés operatív döntéshozó fóruma. |
Vállalkozó | T-Systems Zrt. (Az IQSYS Zrt. jogutódja) |
A projekt alapadatai
Megrendelő | NISZ – MNL – BFL konzorcium |
Vállalkozó | T-Systems Zrt. |
szerződésszám | 2/03284/0000/2012 |
Projekt neve | Elektronikus levéltár szoftver és hardver elemeinek szállítása, valamint kapcsolódó szolgáltatások teljesítése |
típusa | Fővállalkozás, alkalmazásfejlesztés, integráció, hardver szállítás, infrastruktúra építés, migráció |
célja | E-Levéltári rendszer szállítása (hardver, szoftver, implementáció, integráció, migráció) |
kezdete | 2012.10.18. |
befejezése | 2013.07.31. |
2. Projektismertető
2.1 Előzmények
A kormányzati szándéknak és az erre vonatkozó fejlesztéseknek köszönhetően az elektronikus iratok mennyisége dinamikusan nő, aktív beavatkozás nélkül viszont néhány év alatt olvashatatlanná válnak. Ezeknek az iratoknak a nagy része joghatás kiváltására alkalmas, más részének az információs, maradandó értéke jelentős, így nem megengedhető, hogy megsemmisüljenek. Törvényi előírásokból következő irattári kötelezettségek vonatkoznak az elektronikusan keletkezett iratokra is, az ebből származó feladatok azonban speciálisak – a technikai háttér mellett a személyi feltételekben, az iratképzőkkel és a felhasználókkal való kapcsolattartásban is új követelményeket támasztanak. Így sem a kormányzat, sem a levéltárak részéről nem kerülhető meg az elektronikus iratok és az ezzel szorosan összefüggő elektronikus levéltár és informatikai infrastruktúra kialakítása.
A NISZ, a MNL, és a BFL az EKOP 1.2.8 „Az Elektronikus közigazgatás operatív program keretében megvalósuló Elektronikus levéltár” című kiemelt projekt megvalósítása céljából Konzorciumot hozott létre. Az „Elektronikus levéltár” kiemelt projektjavaslat az 1095/2007. (XII. 5.), illetve az 1004/2008. (II. 7.) Korm. határozatoknak megfelelően bekerült az Elektronikus Közigazgatás Operatív Program 2007/2008. évi akciótervébe. A Felek 2009. június 24-én támogatási szerződést kötöttek az Elektronikus levéltár című kiemelt projekt megvalósítására.
Az Elektronikus levélár projekt alapvető célja, hogy a köziratképző szervek – ideértve a törvényhozás, államigazgatás, igazságszolgáltatás szerveit és az önkormányzatokat - maradandó értékű elektronikus iratainak kezelésére kialakításra kerüljön az elektronikus iratok hosszú távú megőrzését biztosító feltételrendszer. A fejlesztés eredményeként elérhetővé kell tenni az érintett levéltári anyagot az érdeklődő külső szervezetek és személyek számára.
Az Elektronikus levélár projekt átfogó célja, hogy a levéltárak e-levéltári szolgáltatásaikkal a közigazgatás hatékony partnerévé lépjenek elő, a levéltári szolgáltatások széles körben elérhetővé tételével növeljék az esélyegyenlőséget, hozzájáruljanak a tudásalapú társadalom hatékony kiépítéséhez. Elektronikus levéltári szolgáltatásaikkal a levéltárak elősegítsék, hogy az állami és önkormányzati szervek ugyanazt a szolgáltatást kevesebb erőforrással, vagyis költséghatékonyabban láthassák el.
Az Elektronikus levélár projekt keretében a Magyar Nemzeti Levéltárban és Budapest Főváros Levéltárában valósulnak meg teljes körűen az elektronikus levéltári szolgáltatások. A projektben létrejövő központosított megoldások publikálásával ezek a szolgáltatások ingyenesen hozzáférhetővé válhatnak a többi közlevéltár számára is.
Az Elektronikus levélár projekt a köziratképző szervek – a törvényhozás, a központi és területi államigazgatási, igazságszolgáltatási szervek és önkormányzatok – működése során keletkezett elektronikus – elektronikusan keletkezett vagy digitalizált-, a nemzeti adatvagyon maradandó értékű részét képező adatok levéltárba kerülésekor a hosszú távú megőrzés, a levéltári feldolgozás, az olvashatóság fenntartása és a hozzáférhetővé tétel feltételeinek biztosítását valósítja meg.
Az Elektronikus levélár projekt eredményeképpen kerül kiépítésre a két levéltár illetékességébe tartozó köziratképzők maradandó értékű elektronikus iratainak kezelését, az elektronikus iratok hosszú távú megőrzését biztosító, az elektronikus levéltári kezelést támogató informatikai infrastrukturális szoftver és hardver háttér, valamint létrejönnek a működtetéséhez és üzemeltetéséhez szükséges feltételek. Kialakul a levéltárba adást megelőzően − a lezárt, központi elektronikus irattári anyagok tekintetében − a közfeladatot ellátó szervek által önkéntesen hozzáférhető és igénybe vehető átmeneti irattárolást támogató, a mai jogszabályi környezetnek megfelelő tárolási szolgáltatás.
Létrejönnek a Hivatali Kapuval rendelkező csatlakozott szervek részére az automatikus rendszerkapcsolat kiépítéséhez szükséges alapfeltételek. Kialakításra kerül a levéltárba adást követően a tartós levéltári megőrzést és használatot biztosító archívum szolgáltatás és az elektronikus levéltári folyamat egészének szolgáltatás jellegű informatikai támogatása. Biztosítva lesz a kezelt levéltári anyagokhoz való, a törvényi előírásoknak megfelelő hozzáférés, a levéltári őrzési helytől függetlenül. Megvalósulnak az egységes és egykapus jogosultságkezelési alapfeltételek az Ügyfélkapuval rendelkező jogosult kutatók és regisztrált felhasználók részére.
Az Elektronikus levélár projekt keretében olyan központi szolgáltatási képesség jön létre, amihez a jelenleg nem projekttag levéltárak is csatlakozhatnak, amennyiben rendelkeznek az általuk igényelt mértékű adatkapcsolat létrehozásához szükséges internetes csatlakozáshoz szükséges feltételekkel. A kialakult rendszer képes lesz ASP jellegű szolgáltatásokat biztosítani, fogadni és kezelni a később csatlakozott elektronikus levéltárak részére.
A köziratképző szervek az Elektronikus levélár eredményeként lehetőséget kapnak arra, hogy adathordozón átadhassák kötegelt elektronikus állományaikat az illetékes közlevéltárnak és igénybe vehetik a szabványos, tanúsított elektronikus iratkezelő rendszereik segítségével, önkéntes jelleggel az e-irattár tárolási szolgáltatásait. Ebben az esetben az e-irattárban tárolt iratok a levéltári rendszer számára nem elérhetőek, nem
olvashatóak, ezen iratok felett kizárólag az iratképző szerveknek van kezelési jogosultságuk.
A nem regisztrált levéltár használók a korlátozás nélkül megismerhető elektronikus iratokat az interneten keresztül szabadon használhatják. Az Ügyfélkapuval rendelkező, regisztrált ügyfelek, magánszemélyek, lehetőséget kapnak arra, hogy a publikus információkon felül kikérhessék és megismerhessék saját személyes adataikat tartalmazó irataikat ill. levéltárosi közreműködéssel vagy jóváhagyással hozzáférhetnek más, a projekt megvalósítási fázisában hatályos adatvédelmi törvény által védettnek nyilvánított személyes adattartalmakhoz. Az Ügyfélkapus azonosítóval nem rendelkező ügyfelek a levéltárak kutatótermeiben történő azonosítást követően a levéltárakban kutathatják a jogosultságuknak megfelelő elektronikus iratokat, adattartalmakat. A tudományos kutatók speciális hozzáférési jogosultsággal rendelkezhetnek, így nemcsak a nyilvános iratokhoz férhetnek hozzá, hanem, amire a jogosultságuk kiterjed. Mindezt az általuk kért módon, átmeneti tárhelyükre, elektronikus levélben, vagy a levéltári kutatóteremben biztosítva.
Az Elektronikus levélár projekt megvalósítása érdekében a NISZ, a MNL és a BFL mint közös ajánlatkérők (konzorciumvezető: NISZ) „Elektronikus levéltár szoftver és hardver elemeinek szállítása, valamint kapcsolódó szolgáltatások teljesítése” tárgyban általános, hirdetmény közzétételével tárgyalásos közbeszerzési eljárást indított TED 2011/S 252-411321; KÉ-33650/2011. szám alatt.
2.2 A projekt célja
2.2.1 A pályázatban foglaltak megvalósítása révén elérni kívánt célok
A szakmai komponensek, a megoldás kiválasztásban a BIZTONSÁG vezetett bennünket. Csak olyat ajánlunk, amiről meg vagyunk győződve, hogy teljesíthető, az egyes elemek megfelelő referenciával rendelkeznek.
Figyelembe véve a lehetőségeket, a forrásokat és az időkereteket arra a következtetésre jutottunk, hogy a siker esélyét az adja meg, ha a kulcskomponensek tekintetében létező, működő, sok referenciával rendelkező CSOMAGMEGOLDÁST adunk. A fejlesztések, különösen szűk időzítés mellett növelik a kockázatot.
A javasolt megoldás olyan, a levéltári szakma kifinomult igényeit kielégítő, Európában igen nagy számban alkalmazott központi rendszer, amit a hazai igényeknek megfelelően alakítunk ki. A rendszer biztosítja az európai szabványosításba való bekapcsolódást, annak eredményeit a projekten belül leszállítjuk. A több sikertelen külföldi példa alapján választottunk biztos megoldást. Ezt egészítjük ki a hazai törvényi szabályozás és a levéltárosok igényei alapján kialakított levéltári archívum kezelő- modullal.
Törekedtünk arra, hogy a főbb komponensekből úgy válasszuk a legelőnyösebbeket, hogy közben a kockázatot minimalizáljuk. Már csak az EU finanszírozás miatt sem megengedhető, hogy olyan termékekkel próbálkozzunk, amelyek nem bizonyítottak, és felvetik az EU forrás visszafizetésének veszélyét.
1.) Központi elektronikus archívum
Ennek megfelelően a központi, az elektronikus archiválást és a levéltári szakmában nagyon fontos, az eredeti dokumentum minden elemét megőrző, de formátumában a mindenkor használatos (10, 100, 1000 év múlva) elektronikus formátumra történő automatikus átalakítást („Preservation”) az Európában gyakorlatilag taroló TESSELLA komponenseivel oldjuk meg. Az architektúra alapvetően olyan nyílt forráskódú komponenseket tartalmaz, amelyek a későbbi kiszolgáltatott helyzetet megelőzik, a támogatás forrásigényét csökkentik.
A megoldás többszörösen bizonyított, a licencként leszállított alapverzió az Osztrák Nemzeti Levéltár, a most átadott Észt Nemzeti Levéltár teljesen működő verzióját tartalmazza. A jelenleg éppen egységesedő európai folyamatba ezzel be tudunk kapcsolódni, a későbbiekben nincs a megszülető szabványok miatt átdolgozásra szükség.
A rendszer egyszerre teljesíti a szabványos módszerekből, adattárolásból fakadó levéltári, felhasználói együttműködési lehetőségeket, illetve a levéltárak testreszabhatóságán, önálló folyamat definiálásán keresztül a levéltárak egyedi igényeinek kielégítését.
Szoftver architektúra, üzemeltethetőség
A speciális levéltári, illetve az ASP jellegű működésnek megfelelően a hatékonyságra, üzemeltethetőségre leginkább tekintettel levő Software as a Service (SaaS) elveknek eleget tévő multi-tenant megoldást használunk egységes architektúrán.
Az üzemeltethetőség növelése okán az irattári rendszerben is alapvetően azonos komponenseket használunk.
Amennyiben zöld mezős fejlesztéssel, vagy ami ezzel egyenértékű, csak papíron létező termékkel, vagy nem erre a célra kialakított, hanem általános Dokumentum- kezeléssel kísérleteznénk, úgy borítékolható volna a projekt kudarca.
2.) A BFL és az MNL papíralapú és elektronikus levéltári front-end
Az MNL és a BFL számára a papíralapú dokumentumok kezelésére egységes és központilag üzemeltetett módon a scopeArchiv licenceit biztosítjuk. Úgy integráljuk a Tessella központi rendszerrel, hogy a létrejött metaadatok nemcsak lokálisan, de a központban is szinkronban tároltak, illetve kereshetők. Az elektronikus dokumentumokat a Tessella kiterjesztéseként bevezetett elektronikus Front-End rendszer kezeli.
A rendszer felkészített a magyar sajátosságok kezelésére, elvégzi a létező rendszerek integrációját illetve migrálását, a 10/2002 követelmények kielégítését a scopeArchiv lehetőségeinek kiegészítésével/továbbfejlesztésével tervezzük.
3.) Infrastruktúra
A projekt során olyan nagy biztonságú, rendelkezésre állású, valamint katasztrófatűrő infrastruktúrát szállítunk a NISZ-be, amelyik messzemenően kielégíti a projekt követelményeit, másfelől hosszú évek óta ismerve a NISZ-t, azokat a látens követelményeket is kielégítjük, amelyek nincsenek megfogalmazva. A javasolt komponensek piacvezető gyártók termékei, amelyek a NISZ által preferált megoldások közé tartoznak és illeszkednek üzemeltetési gyakorlatába. Ezzel tarthatóak alacsonyan a tervezett oktatási, fenntartási költségek. Könnyű, rugalmas átjárást és átcsoportosítást biztosítunk a mostani és a szállítandó eszközök között, a NISZ megkapja azt a lehetőséget, hogy egy esetleges későbbi feladat változás kapcsán az eszközeit rugalmasan átcsoportosíthassa, miközben fizikai szinten mindvégig megmarad az EU projekt igényelte elkülönült projekt-architektúra.
A megoldás gerincét a FUJITSU szerver és tároló megoldásai, Cisco hálózati és a Brocade SAN megoldásai jelentik. Az alapinfrastruktúra szoftver komponenseit a Microsoft és VMware virtualizációs, Microsoft, CenOS és Debian operációs rendszerek, valamint a McAffe vírusvédelmi rendszerei adják. Ez annyit jelent, hogy a teljes infrastruktúra, a szerverek, tárolók, hálózati eszközök, virtualizáció, menedzsment mind garantáltan egymáshoz illesztett, legmagasabb minőségű komponensekből tevődik össze. A rendszer mind horizontálisan, mind vertikálisan egyaránt jól skálázható, robosztus mégis kézben tartható.
Az architektúra kialakításánál kiemelt fontosságúnak tartottuk, hogy valamennyi tervezhető hibára felkészítsük a rendszereket. Így a hardverek fizikai, szoftverek logikai hibái, sőt az emberi figyelmetlenségből eredő hibák sem eredményezhetik, hogy archívum pótolhatatlan értékei elvesszenek.
Kollégáink nemcsak jelentős gyakorlattal vagy irigylésre méltó szakmai tudással rendelkeznek saját szakterületükön, hanem hatékonyan dolgoznak csapatmunkában is. Cégünk számos tapasztalt projektvezetőt, széles látókörű és gyakorlott architektet, mérnököt és fejlesztőt tud mozgósítani, márpedig ez egy ekkora integrációs feladatnál elengedhetetlenül szükséges a sikeres végrehajtáshoz.
A Levéltárak olyan, a központi rendszerrel kapcsolatban álló, de önálló működésre is képes infrastruktúrához jutnak, amelyek hosszú időre kielégítik az igényeiket. A piac vezető gyártói által forgalmazott professzionális munkaeszközöket (munkaállomásokat, nyomtatókat, multimédiás beviteli eszközöket) szállítunk, amelyekkel könnyíthető a levéltári munkavégzés.
Megrendelő
MNL
Konzorciumi tag
BFL
Konzorciumi tag
NISZ
Konzorcium vezető
Levéltári rendszer külső felhasználói
Iratképzők
Dokumentum beküldés KA rendszerbe, KIA használata
Hozzáférés a nyilvános tartalmakhoz
Kutatók
különleges hozzáférési jogosultság a KA, LNYR rendszerekhez
2.3 Érdekeltek bevonása
Vállalkozó
T-Systems Magyarország Zrt Ajánlatadó, Fővállalkozó
Alvállalkozók
T-Systems SI projekt management, rendszerarchitektúra,
minőségbiztosítás
T-Systemc IT&T hardver szállítás, implementáció, rendszerintegráció
2.4 A projekt terjedelme (hatóköre kiterjedése)
A projekt az ajánlott hardver és szoftver rendszerek tervezésére, szállítására, üzembe helyezésére, a felhasználói teszt- és próbaüzem időszak támogatására, oktatásra és dokumentálásra, vállalkozói projektvezetésre és minőségbiztosításra terjed ki. Nem terjed ki az elkészült rendszer üzemeltetésére.
A Vállalkozó feladata a megvalósítás keretein túl garanciális szolgáltatások nyújtása. Szupport és egyéb szolgáltatások nyújtására is köthető szerződés, de ezt a szakaszt már nem tekintjük a szerződés/projekt részének.
A megvalósítás helye a MNL három telephelye, a BFL telephelye és a NISZ két telephelye. A NISZ a szerverszobák pontos helyét a szerződés aláírását követő 15 munkanapon belül megjelöli.
2.5 Nyilatkozat referenciáról
A Megrendelő kifejezetten hozzájárul, hogy a projekt sikeres lezárását követően a Vállalkozó, a projekt üzleti titoknak minősülő adatainak felhasználása nélkül, referencia anyagaiban, nyilatkozataiban jelen projektre, mint általa megvalósított rendszerszállításra és fejlesztésre hivatkozzon, a projekt nyilvános adatait ilyen kiadványokban feltüntesse.
2.6 Előfeltételek
Megrendelő (az Ügyfél oldaláról) és Vállalkozó a projekt előkészítése során feltételezésekkel éltek, melyek befolyásolták a kialakított szakmai tartalmat, határidőket és költségeket. Az alábbiakban felsoroltak összefoglalják azon feltéteket, melyek betartása mind a Vállalkozó, mind a Megrendelő részéről szükségesek a projekt sikeres lebonyolítása érdekében:
• Tartalom
• A Projekt végrehajtása során a szakmai sorrendiség, valamint a leszállítandó termékek mennyisége a szerződés szerint értendő .
• Fázisok ütemezése és lezárása.
• Feltételezzük, hogy a hivatalos projektmegbeszélések minden alkalommal határozatképesek, vagy ha nem, akkor egy munkanapon belül meg kell ismételni, akár írásban.
• A birtokában lévő, a megvalósításhoz szükséges dokumentációkat Megrendelő a projekttervben meghatározott szakasz megkezdésére Vállalkozó rendelkezésére bocsátja. (Ideértve, de nem kizárólagosan: folyamat leírások, üzemeltetői dokumentációk, futó alkalmazások rendelkezésre álló dokumentumai stb.)
• Ütemtervek és leszállítandó termékek
• A megállapodott szállítási határidőnél korábbi szállítás lehetséges a Szerződés
9.1 pontja szerint.
• Erőforrások
• Az ütemtervek teljesítéséhez szükséges, a PAD-ban definiált számú, képzettségű és tapasztalatú szakértő, mind a Megrendelő, mind a Vállalkozó oldalán rendelkezésre kell bocsátani.
• Feltételezzük, hogy a szükséges döntéshozatalhoz megfelelő mandátum és kompetencia a projekt teljes időtartalma alatt munkacsoport szinten is rendelkezésre áll abban az esetben, ha a döntési javaslatok a megbeszélést 24 órával megelőzően írásban megküldésre kerültek.
• NISZ gépterem kiépítés előfeltételei
• Munkavégzés normál munkarendben történik, az ajánlat hétvégi, ünnepnapi tevékenységgel nem kalkulál.
• Várhatóan szükség lesz egyszeri kb. 1órás teljes hűtési rendszer leállásra.
• Kamion és darus gépkocsi behajtása engedélyezett.
• A diesel teljesítményét jelen munka keretében Vállalkozó nem vizsgálja.
• Áramszolgáltatói teljesítmény lekötés növelésének szükségességét Vállalkozó nem vizsgálja.
• A szabadtéri kábelezési feladatok elvégzéséhez +5oC feletti külső hőmérséklet szükséges.
• Az új telepítésű rack-ek az elválasztófaltól nem indíthatóak, így az új telepítés 120cm-rel túl fog nyúlni a jelenlegi rack sorokon.
• A garanciális időszakban a gyártó által előírt negyedéves kötelező karbantartásokat el kell végeztetni. Ennek elmaradása garanciavesztéssel jár.
• A garancia csak a projekt keretében leszállított eszközökre vonatkozik, a teljes együttműködő rendszer korábban leszállított alkatrészeinek meghibásodása esetén üzemkiesés, redundancia vesztés következhet be, ami nem befolyásolja a korábban ismertetett garanciális javítási időket.
• Garanciális időszak a rendszer elindításától indul, várhatóan negyed-, fél év többletkarbantartás szükséges.
• Az áramsín terhelhetősége a rackek mennyisége és hűtési kapacitása alapján 250A.
• Oldallap csak a rack sorok végén kerül elhelyezésre a korábbi telepítésnek megfelelően.
• A rack-enkénti disszipáció nem érheti el a 15kW-ot.
• A felügyeleti rendszer bővítése szükséges az áramellátóban.
• A kábelnyomvonalak a meglévő nyomvonalakhoz egy-egy átkötéssel csatlakoznak
2.7 Szállítandók
2.7.1 Hardver és alapszoftver szállítás
A projekt során nagy mennyiségű hardver és 3rd party szoftver terméket (operációs rendszereket, alkalmazás és adatbázis szervereket, vírusirtó és tömörítő szoftvereket, stb.) kerül leszállításra, paraméterezésre és üzembe helyezésre. Ezeket a szerződés mellékletei tételesen felsorolják, ezért itt nem részletezzük.
2.7.2 Hálózat és szerverterem kiépítés
A projekt során szerver terem kiépítését és hálózatépítést is végzünk a szerződés mellékletét képező műszaki ajánlatban részletezett tartalommal.
2.7.3.1 Programok
Modul neve | Modul leírása | Szakmai teljesítést igazoló |
LNYR | ScopeArchiv alapú Levéltári Nyilvántartó Rendszer szállítása. Az LNYR a papíralapú dokumentumokat kezeli. Tárolja és lekérdezhetővé teszi a KIA-ból átvett digitális dokumentumok meta adatait is. | Xxxxxx Xxxx – MNL Xxxxxx Xxxx Xxxx – BFL |
LNYRK | Levéltári Nyilvántartó Rendszer Kiegészítő alkalmazás szállítása. Az LNYRK a legacy rendszerekből migrált funkcionalitást valósítja meg, valamint a 10/2002-es NKÖM rendeletben előírt nyilvántartásokat vezeti és riportokat állítja elő. | Xxxxxx Xxxx – MNL Xxxxxx Xxxx Xxxx – BFL |
KIA | Tessella SDB alapú Központi Archívum rendszer szállítása. A KIA a digitális levéltári dokumentumokat kezeli, tárolja és lekérdezhetővé teszi a LNYR-ből átvett papír alapú dokumentumok meta adatait is. | Xxx Xxxxxx – MNL Xxxxx Xxxxxx – BFL |
KIR | Tessella SDB alapú Központi Irattári Rendszer szállítása. A KIR az iratképző szervek által hivatali kapunk beküldött dokumentumok hosszú távú, biztonságos tárolását valósítja meg. | Xxx Xxxxxx – MNL Xxxxx Xxxxxx – BFL Xxxxx Xxxxx – NISZ |
KRI | Külső Rendszer Interfész szállítása. A KRI teszi lehetővé az iratképzők számára a hivatali kapu felhasználásával dokumentumok beküldését a KIA és a KIR számára. Emellett a KRI tartalmazza a szerv- és a szerződés nyilvántartást is. | Xxx Xxxxxx – MNL Xxxxx Xxxxxx – BFL Xxxxx Xxxxx – NISZ |
ELP | Elektronikus Levéltári Portál szállítása. Az ELP teszi elérhetővé az Interneten keresztül a levéltár által a nyilvánosságnak szánt statikus információkat, valamint keresési és letöltési felületet biztosít a nyilvános levéltári dokumentumokhoz. A nyilvános tartalmak tárolására egy Tessella SDB implementációt használ. | Xxx Xxxxxx – MNL Xxxxx Xxxxxx – XXX Xxxxxxxxx Xxxxx – NISZ |
2.7.3.2Projektvezetési, minőségügyi dokumentumok
Vállalkozó az alábbi projektvezetési és minőségbiztosítási terveket, dokumentumokat adja át az ütemezésben megadott határidőkkel.
Dokumentum neve | Dokumentum leírása | Átvevő |
Jelen dokumentum. Részei: • Projekt ismertetés. • Projektszervezet ismertetése. • Projekt kommunikációs szabályok lefektetése. • Projekt irányítás módszerének lefektetése, együttműködési szabályok. • Részletes projektterv (projektütemezés is). • Dokumentáció kezelés szabályozása. • Kockázatkezelés szabályozása, kockázatok rögzítése. Formátum: MS Word | Xxxx Xxxxx (NISZ) | |
Minőségbiztosítási terv | A projekt vállalkozó oldali minőségbiztosításának terve. Részei: • Minősébiztosítási és együttműködési alapelvek • Minőségbiztosítási feladatok, folyamatok • Termékekkel, folyamatokkal szemben meghatározott minőségi kritériumok • Minőség mérési módszerek, mérőszámok • Minőségügyi szemlék A dokumentumot Megrendelő nem véleményezi, azt Vállalkozó tájékoztatási céllal adja át. Formátum: MS Word | Xxxx Xxxxx (NISZ) |
Státuszjelentések | A kiadást megelőző héten a projektben történt fontosabb adatok rögzítése. Részei: • Fontosabb események. • Egyes projektelemek előrehaladása. • Azonosított problémák és azok kezelése. • Korábban azonosított, a héten megoldott problémák. Az állapotjelentés sablon alapján készül, amely jelen dokumentum melléklete. Formátum: MS Word | Xxxx Xxxxx (NISZ) |
2.7.3.3Műszaki tervek, dokumentációk
Vállalkozó az alábbi műszaki terveket, dokumentációkat adja át az ütemezésben megadott határidőkkel.
Dokumentum neve | Dokumentum leírása | Szakmai teljesítést igazoló |
Követelmény specifikáció | A követelmény specifikáció a rendszertervvel párhuzamosan a Megrendelő által adott követelménykatalógus felhasználásával készül. A követelmény specifikáció a pályázati kiírásban megadott követelmény katalógus minden egyes követelményéhez megadja, hogy az adott követelmény teljesülése a rendszerterv mely kötetének mely fejezetében van részletesen leírva. Ahol szükséges, ott a fejezet hivatkozásokon túl további megjegyzéseket is tartalmaz. Az így kialakított követelmény specifikáció egyrészt rögzíti az egyes követelmények teljesítésének módját, másrészt pontosan kijelöli a projekt határait. Az egyes követelmények teljesítésének megadott módja egyszersmind értelmezi is a követelményt. A követelmény specifikáció elfogadásával Megrendelő elfogadja a követelmények értelmezését és teljesítésének módját. A projekt későbbi szakaszában már a követelmények átértelmezésére, kiterjesztésére nincs mód. | Xxxx Xxxxx (NISZ) Xxxxxxxxx Xxxxxx (MNL) xx. Xxxxxxxx Xxxxxx (BFL) |
Formátuma: MS Excel |
Dokumentum neve | Dokumentum leírása | Szakmai teljesítést igazoló |
Rendszerterv (szoftver és infrastruktúra) | A rendszerterv az implementálandó és a fejlesztendő szoftver termékek, valamint a hardver és alapszoftver magas szintű terve. Szoftver rendszerterv tartalma • Az érintett folyamatok leírása o Folyamat elemek o Folyamat lépések • Logikai adatmodell (csak fejlesztett alkalmazások esetén) • Használati eset leírások (csak fejlesztett alkalmazások esetén) • Képernyő képek (képernyő tervek, vagy meglévő képernyők esetén valódi képernyő képek) • Áttekintő architektúra rajzok, leírások A szoftver rendszertervek tartalma a dobozos szoftverek esetében a hozzá fejlesztett funkcionalitásra és a paraméterezéssel beállított működésmódra koncentrál. A meglévő funkcionalitást csak a megértéshez szükséges mélységig tárgyalja. | Xxxx Xxxxx (NISZ) Xxxxxxxxx Xxxxxx (MNL) xx. Xxxxxxxx Xxxxxx (BFL) |
Infrastruktúra rendszerterv tartalma alrendszerenként • Tervezési megfontolások • Magas szintű architektúra • Műszaki megoldás o Architektúra ábra o Rendszerkomponensek ismertetése o Funkciók megvalósítása (naplózás, mentés, archiválás, management, rendszerbe kapcsolódás, kommunikáció, stb.) | ||
A rendszerterv több kötetben az alábbi bontásnak megfelelően készül • Tessella SDB alapú szoftverek (KIA, KIR, ELP tároló) • Scope Archiv alapú szoftverek (LNYR) • LNYRK • ELP • KRI • Infrastruktúra rendszerterv | ||
Formátuma: MS Word |
Dokumentum neve | Dokumentum leírása | Szakmai teljesítést igazoló |
Részletes specifikáció | A részletes specifikáció részletesen leírja a megvalósítandó szoftver rendszer és infrastruktúra működését részletes szinten. A részletes rendszerspecifikáció szoftverek esetén a következő elemeket tartalmazza: • Rendszerkörnyezet leírása • Feldolgozási folyamatok • Szoftverarchitektúra • Alkalmazásrétegek • Objektumspecifikációk (alkalmazás és kommunikációs) A részletes rendszerspecifikáció tartalma a dobozos szoftverek esetében a hozzá fejlesztett funkcionalitásra és a beállított működésmódra koncentrál. A meglévő funkcionalitást csak a megértéshez szükséges mélységig tárgyalja. | Xxxx Xxxxx (NISZ) Xxxxxxxxx Xxxxxx (MNL) xx. Xxxxxxxx Xxxxxx (BFL) |
Infrastruktúra esetén a következő elemeket tartalmazza alrendszerenként • Tervezési szempontok, elvárások • Ajánlott műszaki megoldás o Architektúra ábra o Rendszerkomponensek ismertetése o Műszaki megoldás ismertetése • Leszállítandó eszközök (hardver, szoftver) • Igényelt/biztosított kapcsolódási felületek (Üzemi, management, infrastruktúra) • A rendszer terjedelme | ||
A részletes specifikáció több kötetben az alábbi bontásnak megfelelően készül • Tessella SDB alapú szoftverek (KIA, KIR, ELP tároló) • Scope Archiv alapú szoftverek (LNYR) • LNYRK • ELP • KRI • Infrastruktúra rendszerterv | ||
Mivel egységes rendszerről, nem önállóan működő modulokról van szó, az egyes dokumentumoknak utalásokat, hivatkozásokat kell tartalmazniuk azokra a rendszerelemekre, amelyek megvalósítására hatással bírnak. | ||
A részletes specifikációnak pontos hivatkozással (NFK x.x.x, IFK y.y.y stb.) kell tartalmaznia a megvalósítandó követelményeket. | ||
Formátuma: MS Word |
Dokumentum neve | Dokumentum leírása | Szakmai teljesítést igazoló |
Tesztelési terv | A tesztelési terv az egyes rendszerkomponensekre és rendszer viselkedésre (hardver, szoftver) vonatkozóan határoz meg teszteseteket. A tesztesetek leírják a teszteset végrehajtásának • előfeltételeit, • szükséges megelőző paraméterezést, • a tesztelés lépéseit, • az elvárt eredményt. | Xxxx Xxxxx (NISZ) Xxxxxxxxx Xxxxxx (MNL) xx. Xxxxxxxx Xxxxxx (BFL) |
A tesztelési terv a következő bontásban készül: • Infrastruktúra teszt • Rendszer unit tesztek o KIA o LNYR o LNYRK o KIR o KRI o ELP • Integrációs • Performancia teszt • DRP teszt • UAT (User Acceptance Test, összetett, teljes folyamatokra vonatkozó tesztesetek) | ||
A tesztesetek nem terjednek ki a szállított dobozos szoftverek alapfunkcióinak tesztelésére, de kiterjednek a szállítás részeként történő beállításokra és workflowk működésére. | ||
A PAD V. melléklete a tesztelési terv sablon. A tesztelési tervet a sablon alapján készítjük. | ||
Formátuma: MS Word | ||
Teszt jegyzőkönyv | A teszt jegyzőkönyv tartalmazza a teszt terv alapján elvégzett tesztesetek eredményeit. Minden egyes tesztesetnél hivatkozik a tesztterv azonosítóra, dokumentálja a tesztelés eredményét. Jól elkülöníthetően jelöli a teszt sikerességét vagy sikertelenségét. A tesztelési jegyzőkönyv ugyanabban a bontásban készül, mint a teszt terv és ugyanazokat a teszteseteket tartalmazza. A teszt jegyzőkönyv sablonja a VI. mellékletben található | Xxxx Xxxxx (NISZ) Xxxxxxxxx Xxxxxx (MNL) xx. Xxxxxxxx Xxxxxx (BFL) |
Formátuma: MS Excel | ||
Átállási és migrációs terv | A migrációs és átállási terv tartalmazza az egyes kiváltásra kerülő legacy szoftver komponensek használatáról a projekt keretében szállítandó szoftver komponensekre való átállás lépéseit, módját, feltételeit és sorrendjét. Az átállás része az adatmigráció is. Így ez a dokumentum az adatmigrációra vonatkozóan is tartalmazza a fentieket. A dokumentum részletesen meghatározza az egyes lépések felelősét / felelőseit is, ugyanis ennek a folyamatnak a során a megrendelőnek is számos feladata van, valamint közösen végrehajtandó feladatok is vannak. A felek együttműködésének a szokásosnál is szorosabbnak és összehangoltabbnak kell lennie. | Xxxx Xxxxx (NISZ) Xxxxxxxxx Xxxxxx (MNL) xx. Xxxxxxxx Xxxxxx (BFL) |
Hardver infrastruktúra esetében, amennyiben itt is lesznek kiváltásra kerülő elemek, akkor az új hardver, vagy alapszoftver elemek alkalmazására való áttérés részleteit tartalmazza a dokumentum. | ||
Az átállási terv a következő kötetekből áll: • AD • KIA • LNYR • LNYRK • ELP • Infrastruktúra | ||
Formátuma: MS Word |
Dokumentum neve | Dokumentum leírása | Szakmai teljesítést igazoló |
Oktatási terv | Az oktatási terv az • oktatások ütemezését, • tematikáját • megértéshez szükséges képzettséget tartalmazza. Célja, hogy az oktatás folyamata tervezetten és zökkenőmentesen történjen meg. Oktatási területek • A szállított alkalmazások felhasználói, üzemeltetői train the trainer oktatása. • Szállított hardver infrastruktúra üzemeltetői oktatása train the trainer alapon. (A megfelelő előképzettséggel az oktatottaknak rendelkeznie kell.) Az oktatási terv a szerződésben megadottakkal összhangban készül el. Formátuma: MS Word | Xxxx Xxxxx (NISZ) Xxxxxxxxx Xxxxxx (MNL) xx. Xxxxxxxx Xxxxxx (BFL) |
Felhasználói kézikönyv és tananyag | A felhasználói kézikönyv célja, hogy a rendszer átlag felhasználójának és alkalmazás gazdáinak rendszerezett formában átadja a rendszer szoftverkomponenseinek hatékony használatához szükséges ismereteket. A felhasználói kézikönyv a szoftver logikájának megfelelő bontásban és sorrendben, alapvetően az egyes képernyők működésének leírásán keresztül mutatja be a teljes rendszer működését. A felhasználói kézikönyv képernyő képekkel gazdagon illusztrált, egyszerű nyelvezetű, informatikai szakkifejezésektől lehetőség szerint mentes, könnyen érthető és követhető nyelvezetet használ. A felhasználói kézikönyv egyszerre referencia jellegű kiadvány és oktató anyag. | Xxxx Xxxxx (NISZ) Xxxxxxxxx Xxxxxx (MNL) xx. Xxxxxxxx Xxxxxx (BFL) |
Felhasználói kézikönyv az alábbi szoftverkomponensekhez készül: • KIA • KIR • LNYR • LNYRK • KRI | ||
Formátuma: MS Word | ||
(A Tessella és a scope Archiv termékekhez rendelkezésre állnak az eredeti angol nyelvű felhasználói kézikönyvek is és a projekt keretében szállítjuk ezek magyar fordítását is.) | ||
Üzemeltetői dokumentáció és tananyag | A szoftver üzemeltetői dokumentáció célja, hogy a szállított szoftver rendszerek számára biztosítandó működési környezettel kapcsolatos elvárásokat, valamint szükséges beállításokat részletesen leírja. Az infrastruktúra üzemeltetői dokumentáció tartalmazza a teljes szállított működtető infrastruktúra üzemeltetéséhez szükséges rendszeres és eseti operátori és adminisztrátori tevékenységeket. | Xxxx Xxxxx (NISZ) Xxxxxxxxx Xxxxxx (MNL) xx. Xxxxxxxx Xxxxxx (BFL) |
Ugyanakkor az üzemeltetői kézikönyveknek nem célja, hogy az egyes alapszoftverekkel (operációs rendszerek, alkalmazás szerverek, adatbázis-kezelők, gyári szoftverek) kapcsolatos alapismereteket átadjon. Az ilyen ismereteket a szakemberek tanfolyamokon, vagy az egyes alapszoftverek dokumentációjában érhetik el. | ||
Az üzemeltetői kézikönyv az alábbi köteteket tartalmazza: • Tessella SDB alapú szoftverek (KIA, KIR, ELP tároló) • ScopeArchiv alapú szoftverek (LNYR) • LNYRK • ELP • KRI • Infrastruktúra (intézményenként és telephelyenként külön-külön) | ||
Formátuma: MS Word |
Dokumentum neve | Dokumentum leírása | Szakmai teljesítést igazoló |
e-Learning tananyag | Nagy tömegű felhasználó egyidejű, oktató közreműködése nélkül alkalmazható, oktatását támogató tananyag. A tananyagnak az alkalmazások legfontosabb funkcióit kell bemutatnia, azokat a funkciókat, amelyeket az egyszerű felhasználók (nem alkalmazásgazdák, nem rendszergazdák) használnak a rendszerben. A tananyag témák szerint fejezetekre osztott, úgy hogy egy-egy anyag feldolgozása 45 percnél ne vegyen több időt igénybe. e-Learning tananyaggal támogatott alkalmazások: • KIA • KIR • LNYR • XXXXX | Xxxx Xxxxx (NISZ) Xxxxxxxxx Xxxxxx (MNL) xx. Xxxxxxxx Xxxxxx (BFL) |
(Infrastruktúra üzemeltetéssel kapcsolatban e-learning tananyag nem készül.) | ||
Formátuma: MS PowerPoint | ||
Üzletfolytonossági terv (BCP) | Az üzletfolytonossági terv célja annak megadása, hogy a projekt során szállított rendszer, vagy egyes részeinek kiesése esetén, milyen helyettesítő megoldással lehet az üzletmenet folytonosságát biztosítani. Az üzletfolytonossági tervnek azokra a funkciókra, folyamatokra kell kiterjednie, amelyek elengedhetetlenek az intézményi üzleti feladatok ellátásához, amelyek elvégzésére minden körülmények között szükség van és jelen projekt részét képezik. A tervnek tartalmaznia kell mindegyik a leszállítandó IT rendszerben megvalósított kritikus folyamatot, valamint azt a helyettesítő megoldást, amellyel a funkció kiesése esetén az üzleti folyamatok elláthatók. A tervnek tartalmaznia kell azokat a kiesési időket, amely után az egyes helyettesítő folyamatokat életbe kell léptetni. | Xxxx Xxxxx (NISZ) Xxxxxxxxx Xxxxxx (MNL) xx. Xxxxxxxx Xxxxxx (BFL) |
Az érintett folyamatokat, a folyamatok folytonosságának fontosságát, a kiváltás lehetséges módjait (kézi, gépi, stb.), az érintettek körét Vállalkozó és Megrendelő közösen határozza meg. A terv elkészítésében Megrendelő segítséget nyújt vállalkozónak. | ||
A Vállalkozónak nem feladata a folyamatok normál menetének, részletes felmérése és dokumentálása. A Megrendelő biztosítja az érintett folyamatok normál menetének megfelelő dokumentáltságát. Vállalkozó a meglévő informatikával támogatott rendszerekre/infrastruktúrára vonatkozóan feltételezi a BCP dokumentum(ok) meglétét, illetve rendelkezésre állását és ezen dokumentumo(ka)t a kialakításra kerülő rendszerre vonatkozó BCP kialakításához fel kívánja használni. Vállalkozó által a BCP kidolgozása során, illetve ahhoz kapcsolódóan nem kerül végrehajtásra sem üzleti, sem informatikai kockázatelemzés. | ||
A dokumentumnak nem célja a nem a projekt során szállított rendszerek tekintetében az üzletfolytonosság tervezése. Ugyanígy nem célja a készülő dokumentum Megrendelő meglévő BCP-ibe való beillesztése, vagy azokkal bármilyen szempontból egységes elkészítése. | ||
Az üzletfolytonossági tervvel érintett alkalmazás modulok: • KIA • KIR, KRI • LNYR • LNYRK | ||
Formátuma: MS Word |
Dokumentum neve | Dokumentum leírása | Szakmai teljesítést igazoló |
Katasztrófaterv (DRP) | Az informatikai katasztrófaterv célja, hogy egy esetleges természeti, vagy ember által okozott katasztrófa esetén a szervezet előre tervezetten reagáljon és a lehető leggyorsabban újra hozzáférhessen szoftvereihez, adataihoz és hardvereihez, melyek kritikus üzleti funkciókat látnak el, a projekt keretében kerültek leszállításra, és melyek nélkül a normál szolgáltatási szint nyújtása nem biztosított. A BCP és DRP dokumentumok felkészítik a szervezetet a katasztrófa jellegű események kezelésére. Ez azt jelenti, hogy a BCP és a DRP nem a katasztrófa bekövetkezési valószínűségét, hanem – a kritikus szakmai folyamatok/tevékenységek folytonosságának biztosítása révén – a lehetséges kárkövetkezményeket csökkenti. | Xxxx Xxxxx (NISZ) Xxxxxxxxx Xxxxxx (MNL) xx. Xxxxxxxx Xxxxxx (BFL) |
A DRP átfogó útmutató az IT környezetet sújtó katasztrófa kezelésére. A terv célkitűzése, hogy következetes, teljes körű és ellenőrzött feladatsort dokumentáljon, amely feladatokhoz azután konkrét csapatok rendelhetők hozzá a szervezeten belül, akik képesek lesznek reagálni egy esetleges katasztrófahelyzetre. | ||
A DRP megközelítés olyan katasztrófa események kezelésével foglalkozik, melyek hatása rendkívül negatív és katasztrofális kihatással bír a szervezet egészére nézve. Fontos kijelenteni, hogy nem tekinthető minden kritikus esemény, vagy helyzet katasztrófának. Ezen események kezelése, elhárításukra és megelőzésükre tett erőfeszítések nem a DRP keretében, hanem az incidenskezelési és napi üzemeltetési folyamatok mentén valósul meg. | ||
A DRP kizárólagosan a leszállítandó IT rendszerre vonatkozik, és az adott telephelyek már meglévő, a rendszerhez funkcionálisan nem kapcsoló rendszerkomponensek nem tartoznak a hatókörébe. | ||
Vállalkozó a meglévő informatikával támogatott rendszerekre/infrastruktúrára vonatkozóan feltételezi a DRP dokumentum(ok) meglétét, illetve rendelkezésre állását és ezen dokumentumo(ka)t a kialakításra kerülő rendszerre vonatkozó DRP kialakításához fel kívánja használni. | ||
Vállalkozó által a DRP kidolgozása során, illetve ahhoz kapcsolódóan nem kerül végrehajtásra sem üzleti, sem informatikai kockázatelemzés | ||
A dokumentumnak nem célja a nem a projekt során szállított rendszerek tekintetében a DRP tervezés. Ugyanígy nem célja a készülő dokumentum Megrendelő meglévő DRP- ibe való beillesztése, vagy azokkal bármilyen szempontból egységes elkészítése. | ||
A katasztrófaterv fő tartalmi elemei • A katasztrófa bekövetkezése előtti felkészülési feladatok és előfeltételek rögzítése • A katasztrófa események meghatározása • Intézkedési terv (Tartalmazza a következőeket: értesítési lánc, kárfelmérés, döntés a katasztrófahelyzet tényéről, stb.) • Visszaállítási terv a rendszer működésének mihamarabbi visszaállítására (átmeneti, ideiglenes állapot) • Helyreállítási terv a normál működés végleges helyreállításának magas szintű leírása. • Xxxxxxxx, szerepek, felelősségi körök meghatározása, a fenti feladatok végrehajtásához | ||
Formátuma: MS Word |
Az egyes dokumentumok a fenti termékdefiníciókban leírtaknak megfelelően több kötetben kerülnek elkészítésre. Az egyes kötetek logikailag összetartozó egységeket dokumentálnak. A több kötetes (általában több file) megoldást egyrészt a könnyebb kezelhetőség, másrészt a több alvállalkozó közös munkájának egyszerűbb összehangolása, valamint az egyes kötetek önmagukon belüli egyenszilárdságának megőrzése indokolja.
A több kötet alkalmazása a Megrendelő számára is lehetővé teszi a kötetenkénti kiértékelést és jóváhagyást.
A dobozos termékek felhasználói és üzemeltetői kézikönyveit úgy állítjuk elő, hogy az eredeti angol nyelvű dokumentációkat magyar nyelvre fordítjuk, és külön kötetben
elkészítjük a kiegészítő információkat a termékekhez fejlesztett kiegészítésekkel kapcsolatban.
2.7.3.4 Ajánlatban szereplő és leszállítandó dokumentumok összerendelése
Az ajánlat egyes helyein tárgyalt témának megfelelően számos dokumentum megnevezése szerepel. A projekt során leszállítandó dokumentáció ezeket nem mindegyiket tartalmazza különállóan. Egyes logikailag összetartozó dokumentumok a leszállítandó dokumentációban a könnyebb kezelhetőség és átláthatóság érdekében egybeolvadnak az alábbi táblázatnak megfelelően.
Leszállítandó dokumentum | Kiírásban és ajánlatban szereplő, a leszállítandóban befoglalt dokumentumok |
PAD, Projekt ütemterv, Átadás-átvételi eljárásterv | |
Követelmény specifikáció | Követelmény specifikáció |
Rendszerterv | Logikai adatmodell, Logikai rendszerterv, Rendszerfejlesztés dokumentumai |
Részletes rendszer specifikáció | Fizikai rendszerterv, Architektúra specifikáció |
Átállási és migrációs terv | Átállási terv |
Felhasználói kézikönyv és tananyag | Oktatási tananyag, Felhasználói dokumentáció, Felhasználói kézikönyv |
Üzemeltetői dokumentáció | Prototípus rendszer dokumentumai, Implementációs dokumentumok, Installációs kézikönyv, Üzemeltetési kézikönyv, Üzemeltetői dokumentációk, Adminisztrátori kézikönyv |
e-Learning tananyag | Oktatási tananyag, Oktatási vizsgaanyag, e-Learning tananyag |
Üzletfolytonossági terv (BCP) | Üzletfolytonossági tervek |
Katasztrófaterv (DRP) | DRP terv |
2.8 Migráció
A migráció a projekt sikerének egyik kritikus folyamata. A migrálandó rendszerről rendelkezésre álló dokumentációt a Megrendelő Vállalkozó rendelkezésére bocsátja. A megvalósításhoz szükséges mélységű specifikáció hiánya kockázat-kezelési folyamat indítását kívánja. Azokban az esetekben, amikor a migrálandó rendszer kapcsán nem áll rendelkezésre a megvalósításhoz szükséges írásos információ és/vagy nincs lehetőség a
rendszer fejlesztőjével való együttműködésre jelentősen nő a teljes körű migráció megvalósításának kockázata, azonban Megrendelő és Vállalkozó a sikeres migráció érdekében minden tőle elvárhatót megtesz.
A migrálandó funkciók lehetőség szerint SDB, ill. scopeArchiv funkcióival kerülnek kiváltásra, amennyiben az SDB, vagy a scopeArchiv tartalmaz olyan funkciót, ami ezt lehetővé teszi, még akkor is, ha az nem egyezik meg pontosan az eredeti rendszer funkciójával, de megfelel a követelményjegyzékben foglaltaknak.
Ha az adat és/vagy funkció migrációja bármilyen okból nem lehetséges, Vállalkozó megkísérli a nem migrálható rendszert integrálni. A rendelkezésre álló információk (dokumentáció, migrálandó rendszer fejlesztői) hiányossága esetén ennek az eredménye nem garantálható, ezért ilyen esetekben Vállalkozó és Megrendelő egyezteti a továbblépés lehetőségeit.
A migrációs kérdésekben a scopeArchiv és a Tessella SDB munkacsoportoknak megegyezésre kell jutniuk, és mindkét munkacsoport által elfogadott elképzeléseket kell a PVB szintre felterjeszteni.
A migráció részleteit a projekt során elkészítendő migrációs terv tartalmazza részletesen.
2.9 Kapcsolódó rendszerek, interface-ek
A kialakítandó rendszernek egyetlen interfészkapcsolata van levéltárakon kívüli rendszerekkel. A KRI interfész célja, hogy az iratképző intézmények részére olyan felületet nyújtson, amelyen keresztül az iratképzők képesek iratokat elhelyezni levéltári tárolásra, vagy egyszerű megőrzésre. Megőrzés esetén az iratképzőnek előzetesen szolgáltatási szerződést kell kötnie a levéltárral, hogy igénybe vehesse a szolgáltatást. Az interfész feladata, hogy ebben az esetben a szerződések érvényességét ellenőrizze. Ennek érdekében szerződéstárat is tartalmaz.
Az iratképzők a fent körülírt szolgáltatásokat a hivatali kapu felhasználásával a levéltári rendszer KRI modulján keresztül veheti igénybe. Minden olyan iratképző rendszer, amely implementálja a KRI által kínált szolgáltatások elérésére és használatára alkalmas funkciókat, képes a szolgáltatások igénybevételére. Azok az iratképzők, amelyek nem implementálják a szükséges funkciókat a hivatali kapu felhasználásával közvetlenül is tölthetnek fel iratokat a rendszerbe. Ehhez a KRI megfelelő felületet nyújt.
Az iratképzők szoftvereinek kiegészítése a KRI szolgáltatások igénybevételére nem része a projektnek.
2.10 Oktatások
Az Elektronikus Levéltár rendszer használatbavételét és az utána következő használatát illetve üzemeltetését Vállalkozónak oktatás szervezésével és lebonyolításával kell támogatnia. Az oktatás megvalósítását két lépésben kell végrehajtani, ezen felül az oktatásnak kétszintűnek kell lennie, külön a felhasználói szintnek és külön az üzemeltetői szintnek.
Első lépésben Vállalkozónak dokumentációt kell készítenie a rendszerhez az átadás előtt. Az elkészített dokumentációt és az ahhoz kapcsolódó oktatási tematikát Ajánlatkérővel el kell fogadtatni és formálisan jóvá kell hagyatni. Az első szinten a
rendszer felhasználói számára részletes felhasználói dokumentációt kell készíteni. A felhasználói dokumentáció alapja a felhasználói felületen megjelenő Súgó tartalma. A felhasználói dokumentáció formáját webes és nyomtatott használatra egyaránt optimalizálni kell. A második szinthez az üzemeltetési előírásokról és a környezeti beállításokról kell üzemeltetési leírást készíteni.
A második lépésben a dokumentáció alapján az előre engedélyeztetett tematika szerint oktatást kell tartani Megrendelő által kijelölt személyek részére. Az oktatást a dokumentáció készítésével analóg módon két szinten kell megtartani, külön a felhasználók számára és külön az üzemeltetésben résztvevők számára. Az oktatás környezete a Megrendelőnél telepített teszt környezet, a helyszínt így Megrendelő biztosítja.
Megrendelő személyes, Train-the-Trainer jellegű oktatást kér a MNL és a BFL kijelölt 5-5 fő munkatársa részére. Az oktatás keretében felkészített munkatársak feladata lesz a további levéltári alkalmazottak felkészítése.
Más szakmai mélységű oktatási forma keretében (e-learning) szükséges megtartani nagy létszámú, kb. 2000 fő részére történő tájékoztatást, amely az elektronikus levéltári, és irattári szolgáltatásokkal közvetett kapcsolatban lévő, szélesebb körű, potenciális felhasználói réteget készíti fel a kész rendszerhez való kapcsolódásra. Az oktatás disszeminációs célokat szolgál.
Egyértelmű elvárás Vállalkozóval szemben, hogy a szerződés keretében szállított hardver és szoftver elemek üzemeltetésével kapcsolatban is tartson oktatásokat.
Az üzemeltetési dokumentáció és az ahhoz kapcsolt oktatási tematika elkészítésének a határidejét a rendszerterv elfogadását követő 60. napig kell meghatározni, és a PAD-ban rögzíteni. Az oktatás megtartását és a tudásellenőrzést a megadott oktatás lezárási határidőig kell végrehajtani maximum 20 fő részére (6-6 fős turnusokban).
2.11 Megrendelőtől várt dokumentációk
Megrendelő a projekt megfelelő szakaszában, a sikeres és megfelelő színvonalú munkavégzés érdekében a vonatkozó szabályzatoknak megfelelő módon Vállalkozó rendelkezésére bocsátja a rendelkezésére álló összes dokumentációt, különös tekintettel:
• a meglévő, projekt által érintett rendszerekhez kapcsolódó IBSZ, vagy bármilyen általános biztonsági szabályozást, amely követelményeket fogalmaz meg a rendszerrel és a hozzátartozó dokumentációkkal (pl. BCP, DRP, stb.) kapcsolatban;
• a BCP és DRP alá tartozó rendszerek esetében a már rendelkezésre álló BCP és DRP dokumentumokat.
• jelenleg futó alkalmazásainak dokumentációi.
3. A PROJEKTSZERVEZET FELÉPÍTÉSE ÉS MŰKÖDÉSE
3.1 A projektszervezet
A projektszervezet 3 szintből áll: projektfelügyeleti, projektirányítási és végrehajtási szintből.
Mindhárom konzorciumi tag és a Vállalkozó is delegál mindhárom szintre tagokat.
A projektszervezet áttekintő ábráját, amely a kommunikációs kapcsolatokat is kijelöli lásd az I. mellékletben.
A projekttagok elérhetőségét és szervezeti hovatartozását tartalmazó nyilvántartás kerül felállításra, amelyet folyamatosan karban kell tartani. A projekttag nyilvántartás jelen dokumentum IV. mellékletét képezi.
3.1.1 A projektfelügyeleti (FB) szint
A projektfelügyeleti szint a legmagasabb szintű döntéshozó fórum.
A projektfelügyeleti szinten a delegáltak szerepe a szokásos szponzori szerephez hasonló; a projekt legfelső szintű támogatását biztosítják, valamint felsővezetői szerződéses ügyekben aláíró jogkört gyakorolnak.
A Felügyelő Bizottság feladata a projekt végrehajtásához szükséges erőforrások biztosítása, a projektirányítási szint (PVB) által felterjesztett, a szerződést érintő ügyekben döntéshozatal.
A projektfelügyeleti szint hatáskörébe tartozik minden olyan döntés meghozatala, amely a szerződés módosítását igényli. A projektfelügyelők döntenek mindazokban a kérdésekben, amelyekben a PVB szintjén nem sikerült egyetértésre jutni.
A projektfelügyelőknek a projektben operatív teendőjük nincs.
A projektfelügyeleti szint nem tart reguláris üléseket. Eseti projektfelügyeleti ülést kezdeményezhet bármelyik projektfelügyelő, valamint a PVB.
A projektfelügyeleti szint üléseiről jegyzőkönyv készül, és az ebben lefektetett döntések minden résztvevőre kötelező érvényűek.
3.1.2 Projektirányítási (PVB) szint
A PVB felelős a Projekt operatív irányításáért, a szerződésben meghatározott szakmai feladatok időben, megfelelő minőségben történő teljesítéséért és a ráruházott hatáskörben intézkedik a felügyelői szint által meghozott elvi döntések érvényre juttatásáért, továbbá folyamatosan ellátja az FB képviselőit a projekt előrehaladásával kapcsolatos információkkal.
A projektvezetők teljes felelősséggel és hatáskörrel rendelkeznek a szerződés keretén belüli döntések meghozatalára. A PVB legfontosabb feladata a projekt sikeres megvalósításának biztosítása. Ennek érdekében folyamatosan figyelemmel kíséri a Projekt előrehaladását, szükség esetén haladéktalanul intézkedik a projekttervekben rögzített feladatok akadályoztatásának felszámolása érdekében.
A PVB hatáskörébe tartozik minden olyan döntés meghozatala, amely a szerződés és a PAD megváltoztatását nem igényli. Azokban a kérdésekben, amelyekben a projektvezetés szintjén nem sikerül egyetértésre jutni, továbbítják a projektfelügyelők felé.
A projektben résztvevő szervezetek projektvezetői rendelkeznek a szükséges felhatalmazással, hogy szervezetük nevében a szerződés keretein belül döntéseket hozzanak.
A projektvezetők munkáját a projekttámogatók segítik. A projekttámogatók eseti jelleggel vesznek részt a munkában, ezért a PAD-ban való nevesítésük nem indokolt.
A PVB hetente ülésezik (rendes ülések), tervezett időpontja minden kedden 9:00-kor. A projektvezetői értekezletek alapértelmezésben a BFL Teve utcai telephelyén (Budapest, Teve u. 3-5.) kerülnek megtartásra a meghívó szerinti szobában, ahol
• ellenőrzik a projektben elvégzett feladatokat,
• összevetik azok állapotát a tervezett ütemezéssel,
• megoldási alternatívákat dolgoznak ki felvetett problémák esetén,
• döntéseket hoznak korrekciós lépésekről,
• összehangolják a következő időszak tevékenységeit,
• a projekt napi munkáját ellenőrzik és irányítják,
• aktualizálják a projekt kockázati listáját.
A PVB ülések állandó meghívottjai a projekttámogatók.
Az ülések állandó napirendi pontja a projekt heti előrehaladási riportja. A PVB üléseiről jegyzőkönyv készül.
A PVB üléseken meghozott döntések a feladatok végrehajtása tekintetében kötelező erejűek.
A PVB a projekt működése során jogosult eseti munkacsoportok létrehozására. Az eseti munkacsoportok működési rendjét a PVB a létrehozással egy időben szabályozza.
Azokat a vitás kérdéseket, amelyekben a PVB nem jut közös megegyezésre, vagy a PBV hatáskörén kívül esnek, az FB elé terjeszti.
Mind a PVB-nek, mind az FB-nek jogában áll a projekt teljes időszakában a PVB-t a rendes üléseken kívül is összehívni. A rendkívüli ülések időpontját és helyszínét a projektvezetők egyeztetik.
3.1.3 Minőségbiztosítás
A minőségügyi megbízott felelős a projekt irányítási és fejlesztési folyamatainak a minőségbiztosítási tervben meghatározott módszertani előírások, szabályok szerinti lefolyásának ellenőrzéséért és betartatásáért.
A projektben mind a Megrendelő, mind a Vállalkozó alkalmaz minőségbiztosítási szakembereket. A minőségbiztosítási ellenőrök korlátozás nélkül részt vehetnek a kétoldali szakmai megbeszéléseken, illetve betekinthetnek a keletkező dokumentumokba. A vezetői megbeszéléseken meghívás esetén vehetnek részt.
A megrendelő oldalán a termékek és szolgáltatások minőségbiztosítását a KÜRT Zrt.,, a menedzsment folyamatok minőségbiztosítását a KIFÜ végzi.
3.1.4 Projekt adminisztráció
A projekt adminisztráció alapvető feladata minden, a projekttel kapcsolatos elektronikus és papír alapú dokumentum (fájl, levél, fax, email) továbbítása ill. fogadása, nyilvántartása, rendszerezése, és tárolása.
További feladata a projektvezetés támogatása az értekezletek szervezésében, anyagok sokszorosításában, értesítések, meghívók kiküldésében, jegyzőkönyvek készítésében, egyéb adminisztrátori feladatok elvégzésében.
Felek saját szervezetükön belül önálló projekt adminisztrációról gondoskodnak.
A közös események adminisztrálása FB és PVB szinten a Megrendelő feladata, a munkacsoportok szintjén pedig Vállalkozóé.
3.1.5 Végrehajtási szint
A végrehajtási szint a projekt végrehajtását végzi. A végrehajtási szinten egy vagy több munkacsoportot lehet kialakítani a projekt igényeinek megfelelően. A munkacsoportokban mindkét (Vállalkozói és Megrendelői) oldalnak biztosítania kell a szükséges erőforrásokat, amelynek mértékét és ütemezését a projektvezetés határozza meg a projekt előrehaladásának függvényében.
Az állandó munkacsoportok a következők:
Munkacsoport neve | Munkacsoport feladata | Munkacsoport vezető (Vállalkozó) | Munkacsoport vezető (Megrendelő) | |
Infrastruktúra | Infrastruktúra szállítása | Xxxxxxxx Xxxxxx | Xxxxx (NISZ) | Xxxxx |
Tessella-SDB | Tessella SDB alapú megoldások implementáló munkacsoportja (KIA, KIR) | Xxxx Xxxxxx | Xxx (MNL) | Xxxxxx |
scopeArchiv LNYRK | és | ScopeArchiv alapú megoldások, valamint LNYRK fejlesztése és szállítása implementáló munkacsoportja | Xxxxxxx Xxxxxx | Xxxxxx-Xxxx Xxxx (BFL) |
KRI | KRI fejlesztése és szállítása | Xxxxxxx Xxxxxx | Xxxxx (XXXX) | Xxxxx |
ELP | ELP fejlesztése és szállítása | Zotterné Xxxxxxx | Xxxxx | Xxxxxxxxx Xxxxx (NISZ) |
Migráció | A migrációs feladatok tervezése, megvalósítása | Xxxxxx Xxxxxx | Xxx (MNL) | Xxxxxx |
3.2 Szerepkörök
A projektben használt szerepkörök a következők.
3.2.1 Megrendelő oldali szerepkörök
Szerepkör | Feladat |
FB-tag | Projekt stratégiai felügyelete |
PVB tag | A projekt operatív döntéshozó testületének tagja, a saját szervezetének döntési kompetenciával felruházott tisztségviselője |
Projektigazgató | A projekt operatív irányítása |
Projekt támogató | A projektvezetés szakmai és projektvezetési támogatása |
Munkacsoport vezető | Projekt szakmai irányítása adott területen belül |
Projekt adminisztrátor | Projekttel kapcsolatos adminisztrációs feladatok ellátása saját szervezeten belül |
Kulcsfelhasználó | Felhasználó képviselet, véleményezés. A kész rendszert használó „kulcsfelhasználó” megjelenéséig kijelölt szakember feladata. A követelmények teljesülését a kulcsfelhasználók ellenőrzik. |
Alkalmazás gazda | Az a levéltáros szakember, aki az egyes alkalmazások felhasználó szakmai beállításait végzi el. Azokat a beállításokat, amelyek a rendszer szakmai elvárásoknak megfelelő működését befolyásolja. |
Rendszergazda | Az az informatikus szakember, aki biztosítja a rendszerek működéséhez szükséges informatikai környezet folyamatos működését és helyes beállításait. A szállított rendszerek üzemeltetéséhez szükséges informatikai beállításokat is ő végzi. |
A független minőségbiztosítói feladatok ellátása. |
3.2.2 Vállalkozó oldali szerepkörök
Szerepkör | Feladat |
Projekt felügyelő bizottság | A projektigazgatóból és a megvalósító divízió-, valamint ágazat igazgatókból áll. Feladata a projekt felső szintű felügyelete. |
Projekttulajdonos | Xxxxx biztosítása, hogy a projekt a szerződéses keretek között végrehajtásra kerüljön. |
FO projektigazgató | Az FO részéről felügyeli a projektet. |
Projektvezető helyettes | A projektvezető általános helyettese |
BO vezető | Felelős a BO-jához tartozó projektek eredményességéért és emberi erőforrásai megfelelő mértékű kihasználásáért. |
Chief architect | A projekt szakmailag helyes megvalósulásáért felelős szakmai vezető. |
Szakértő | A projekt során alkalmazott szakterületekben jártas külső, nem teljes munkaidőben a projekthez rendelt szakember, aki segíti a projekt tagokat munkájuk magas szakmai színvonalú elvégzésében. |
Fejlesztő | Szoftverfejlesztési feladatok elvégzése. |
Projekt asszisztens | A projekt munkájának segítése. Elsősorban adminisztratív és szervező feladatok ellátása. |
Tesztelő | Tesztelési feladatok elvégzése. |
Dokumentáló | Rendszer dokumentációk készítése. |
Minőségügyi megbízott | Projekt minőségbiztosításáért felelős |
Mérnök/ Rendszermérnök | Rendszerkiviteli tervek és megvalósulási dokumentációk készítője, szakértői feladatok ellátása. |
3.3 Résztvevők
Vállalkozó részéről | ||
Projekt tulajdonos | Xxxxxxxx Xxxxxx | Xxxxx Xxxxxx Attila (NISZ) xx. Xxxx Xxxxxxxxx (MNL) xx. Xxxxxxxx Xxxxxx (BFL) |
Projektigazgató | Xxxxx Xxxxx | Xxxx Xxxxx (NISZ) |
PVB delegált | Xxxxxxxxxx Xxxxxx Xxxxxxxxx Xxxxxx Márk Xxxxxx Xxxxxx | Xxxx Xxxxx (NISZ) Kiss-Xxxxx Xxxxxx (NISZ) Xxxxxxxxx Xxxxxx (MNL) Xxxxxxx Xxxxx (MNL) xx. Xxxxx Xxxxx (BFL) xx. Xxxxxxxx Xxxxxx (BFL) |
Projektvezető | Xxxxxxxxxx Xxxxxx | Xxxx Xxxxx (NISZ) |
Projekt asszisztens/Projektkoordinátor | Xxxxxx Xxxxxx | Xxxx Xxxxxx (NISZ) |
Minőségügyi megbízott | Xxxxxx Xxxxxx | Xxxxxx Xxxxxx (NISZ) |
Chief Architect | Xxxxxx Xxxxxx | - |
Architect támogató | Xxxxxx Xxxxx | - |
Független minőségbiztosító | - | xx. Xxxxxx Xxxxx (KIFÜ) Xxxxxxxx Xxxxx (KÜRT) |
3.4 Felek együttműködése, rendelkezésre állás
A projekt megvalósítása mindkét fél (Vállalkozó és Megrendelő) részéről is különleges erőfeszítést követel meg. A projekt nem valósítható meg, ha Megrendelő és a Vállalkozó nem biztosítja megfelelő mennyiségben is időben a megfelelő szakemberek és döntéshozók rendelkezésre állását a projektben. Az erőforrások késedelmes rendelkezésre állása a projekt csúszását eredményezheti. A projekt rendkívül szoros ütemezése ilyen csúszásokat nem enged meg.
Éppen ezért Xxxxx kölcsönösen vállalják, hogy a projekt végrehajtásához szükséges feladatok ellátása magas prioritást élvez. Vállalkozó és Megrendelő egyaránt vállalja, hogy
az ütemtervnek megfelelő, zökkenőmentes működéshez szükséges erőforrásokat a megfelelő időben, mennyiségben és minőségben a projekt rendelkezésére bocsátja.
3.5 Projekt kommunikáció
3.5.1 Alapelvek
A projekt sikere nagymértékben függ a kommunikáció sikerességétől. Ezért nagyon fontos, hogy a megfelelő kommunikáció kialakuljon és fennmaradjon. A kommunikáció célja elsősorban az, hogy mindenki mindig tudja, mi a feladata és mi annak a célja (mit miért kinek kell elvégezni).
A projektkommunikáció alapelvei a következők:
• A Felek közötti minden, a projektet érintő hivatalos találkozóról (interjú, minőségi szemle, átadás-átvétel stb.), megbeszélésről, értekezletről jegyzőkönyv vagy emlékeztető készül, amelynek elkészítése a Vállalkozó feladata. Kivétel képez ez alól az FB és a PVB jegyzőkönyve, amelyet Megrendelő készít. Az FB és PVB ülésekről hangfelvétel is készül.
• A résztvevők a megtárgyalt témák súlyossága és fontossága alapján közösen döntik el, hogy emlékeztető vagy jegyzőkönyv készüljön a megbeszélésről. Ha bármelyik fél kéri, hogy jegyzőkönyv készüljön, akkor jegyzőkönyvet kell készíteni.
• A jegyzőkönyveket és az emlékeztetőket az eseményt követő 2 munkanapon belül el kell készíteni.
• Az emlékeztetőkkel és a jegyzőkönyvekkel kapcsolatban 2 munkanapon belül lehet észrevételeket tenni, amelyet készítő vezet át.
• A végleges jegyzőkönyveket a soron következő megbeszélésen minden érintett félnek alá kell írnia.
• Az egyes dokumentumok e-mailben történő elküldése tekintendő átadásnak. A reagálást és a javítást is elegendő e-mailben elküldeni.
• A jegyzőkönyvekből, egy-egy aláírt példányt át kell adni az érintett feleknek (Vállalkozó, Megrendelő) iktatás, megőrzés céljából.
• A Felek közötti minden egyéb dokumentumnak, levélnek a projekt adminisztrációhoz kell kerülnie iktatásra, megőrzésre.
• A preferált írásbeli kommunikációs média az e-mail.
• A szerződéssel vagy pénzügyi kötelezettségekkel összefüggő dokumentumokat, leveleket postai levélben vagy személyesen kell átadni az átvétel írásbeli igazolásával (átadás/átvételi jegyzőkönyv).
• A projekttagok egymás munkájának segítésére kötelesek a projekt működése szempontjából fontos ismereteket egymásnak is átadni.
• A projekt adminisztrálására MS Office 97-2003 alkalmazások által előállított formátumok: Word, Excel, Visio, Project, PowerPoint, JIRA előírtak. (A módosításoknak, azokban a formátumokban, ahol ez támogatott, a korrektúra használatával kell történnie!)
A hivatalos kommunikációs csatornák a következők:
• a személyes megbeszélések,
• a telefonon történő megbeszélések,
• telekonferencia, videókonferencia,
• elektronikus levelezés,
• papír alapú levelezés,
• fax.
3.5.2 Kommunikációs csatornák
3.5.2.1Személyes megbeszélések
A megbeszéléseken a legfontosabb alapelv a meghívottak
• részvétele,
• pontos megjelenése,
• felkészültsége.
A személyes megbeszélések lehetőleg legyenek
• rendszeresek,
• egy felelős által szervezettek, aki felelős a megbeszélés helyének, konkrét céljainak és napirendjének az érintettekhez való eljuttatásáért (az érintettekkel történt egyeztetés után), a megbeszélések előtt legalább 1 nappal.
3.5.2.1.1 Megbeszélések szervezése, lebonyolítása
A megbeszélés felelőse a megbeszélést elsősorban elektronikus úton kezdeményezi; ugyanúgy a megbeszélés helyszínének lefoglalását is.
A megbeszélés résztvevői kötelesek a megbeszélés szervezőjét informálni a megbeszélés napirendjét vagy más lényeges részét érintő változtatásokról és az esetleges hiányzásról a megbeszélés kezdete előtt legkésőbb 1 munkanappal.
A megbeszélés idejét, célját, napirendjét és helyszínét, esetleg munkaanyagát a megbeszélés szervezője az érintettekhez elsősorban a projekt levelező rendszere segítségével, (elektronikus úton) juttatja el.
A nem rendszeres, eseti (ad hoc) személyes megbeszélésnek is mindig legyen felelős szervezője, aki a megbeszélés sikeres megszervezéséért és levezetéséért felel.
A megbeszélés szervezője köteles kijelölni a megbeszélés levezetőjét és a jegyzőkönyv vezetőjét. Amennyiben nincs előzetes megállapodás arról, hogy jegyzőkönyv vagy emlékeztető készüljön, akkor ezt is meg kell határozni.
Amennyiben a megbeszélésről egy vagy több nélkülözhetetlen munkatárs igazoltan vagy igazolatlanul hiányozna, az automatikusan a megbeszélés maximum 2 munkanapos elhalasztását jelenti.
Megbeszélésről résztvevőt kihívni csak halaszthatatlan esetben lehet; a munkacsoport- vezető, ill. a projektvezető távozása esetén az ilyen eset automatikusan az illető visszatértéig tartó szünetet jelent.
A megbeszélések résztvevői csak indokolt esetben jelölhetnek ki maguk helyett a megbeszélés napirendjén szereplő témákban kompetens, őket helyettesítő személyt. Ez alól kivétel a munkacsoport-vezetők esete, akik a csoportot közösen vezetik, és az ő egyeztetett belátásuk szerint vesznek részt az őket érintő megbeszéléseken.
Szakmai megbeszélést kezdeményezhet bármelyik projekttag vagy projekttámogató, azonban hivatalos döntésnek csak az tekinthető, ami az illetékes munkacsoporton belül is támogatást kapott, valamint jóváhagyásra és dokumentálásra került.
3.5.2.1.2 Jegyzőkönyv és emlékeztető készítés
A jegyzőkönyvet a jegyzőkönyv vezetője kizárólag a szabványos dokumentumok között található formanyomtatvány alkalmazásával készíti el, külön összegezve a megvitatott és eldöntött problémaköröket, valamint a meghozott döntéseket, a meghatározott feladatokat, a hozzájuk rendelt határidőt és a felelős nevét.
A jegyzőkönyv vezetője a megbeszélés befejezése után, attól számítva legkésőbb 2 munkanapon belül köteles az elkészített jegyzőkönyvet a résztvevőkhöz és az esetlegesen érintettekhez (elsősorban elektronikus úton) észrevételezésre eljuttatni, az észrevételezés határidejének meghatározásával (2 munkanap).
A jegyzőkönyv készítőjének a megbeszélés napját követő második munkanapon éjfélig kell az emlékeztetőt megküldeni. (pl: hétfő esetén szerda éjfél.)
Az emlékeztető véleményezésének értelmezése:
1. ha az emlékeztető 10 óráig megérkezik, akkor a küldés napja beleszámít a véleményezési időkeretbe;
2. ha az emlékeztető nem érkezik meg 10 óráig, akkor a határidő a küldés napját követő második munkanap éjfélig tart.
A résztvevők észrevételeiket írásban (elsősorban elektronikus úton), a jegyzőkönyvre hivatkozva tehetik meg. A megjelölt határidőig be nem érkezett észrevételek semmisnek tekintendőek.
Amennyiben a megadott határidőig a jegyzőkönyvre nem érkezik hivatalos csatornán észrevétel, akkor az eredetileg megküldött jegyzőkönyv marad érvényben, mint végleges jegyzőkönyv.
A jegyzőkönyv vezetője az észrevételeket megfelelően feldolgozza és a jegyzőkönyvet az észrevételek határidejét követő 1 munkanapon belül véglegesíti.
Feloldhatatlan ellentét esetén a jegyzőkönyv vezetője azt jelzi a projektvezetésnek, amely az ellentétet vagy feloldja/eldönti, vagy az érintettek megfelelő bevonásával tisztázza.
A jegyzőkönyv vezetője a jegyzőkönyv véglegesítéséről, illetőleg a feldolgozhatatlan ellentétről az érintetteket az észrevételek határidejét követő 1 munkanapon belül értesíti.
A jegyzőkönyv vezetője köteles a megbeszélés során felmerült problémákat és feladatokat az érintett munkacsoport-vezetőhöz vagy projektvezetőhöz haladéktalanul eljuttatni.
A fejezet jegyzőkönyvre vonatkozó megállapításai emlékeztető esetén is érvényesek.
Az e-mailben küldött levelek tárgy (subject) mezője mindig az ELEV rövid projekt névvel kezdődjön.
A Vállalkozó és Megrendelő közötti hivatalos elektronikus leveleket a következő címekre is el kell küldeni megőrzési célból:
Az egyes munkacsoportok közötti levelezés esetében az elektronikus leveleket minden esetben meg kell küldeni az alábbi közös (munkacsoport) email címekre:
Munkacsoport neve | BFL munkacsoport e-mail cím | MNL munkacsoport e-mail cím |
Infrastruktúra | ||
Tessella SDB | ||
Scope Archive és LNYRK | ||
KRI | ||
ELP | ||
Migráció |
Bizalmasnak, titkosnak minősített anyagokat e-mail-ben csak titkosítva szabad küldeni.
Az e-mail-ekben az állományokat csatoltan küldjük (1 Mb-nál nagyobb csatolt állomány ZIP-el tömörítve, szükség esetén titkosítva küldhető.)
A Megrendelők számára küldhető legnagyobb méretű csatolmány 5 MB/e-mail. Dokumentum továbbítható a T-Systems Dokushare Portál oldalára (xxxxx://xxxxxxxxx.x-
xxxxxxx.xx/x-xxxxxxxx/xxxxxxx.xxxx) mutató link e-mailben való továbbításával is.
3.5.2.3Telefon, telekonferencia
A telefonon, vagy telekonferencia megoldáson (videó konferencia, Skype, stb.) történő megbeszélések elsősorban egyeztetésre szolgálnak, másodsorban rövid és kis jelentőségű esetek megbeszélésére. Ezért az így történő megbeszélések rögzítése általában nem megkövetelt, de egy emlékeztető vagy összefoglaló email készítése ajánlott. Amennyiben bármilyen megállapodásra sor kerül, az emlékeztető vagy jegyzőkönyv készítése kötelező.
3.5.2.4Levelezés
A levél alaki és tartalmi összetevői azonosak a hivatali és irodai gyakorlatban alkalmazottakkal. Fő jellemzője, hogy elsősorban papíron létezik, a megfelelő iktatással. Eredetije általában a címzetthez kerül, míg a másolat az iktatás után a küldőnél, illetve a Projektvezetésnél található, ahonnan nem vihető el. Szüksége esetén róla munkamásolat készíthető.
3.5.2.5Fax
Azonos szabályok vonatkoznak rá, mint a papír alapú levelezésre. Külön hangsúly fektetendő a következőkre:
• Fax fedőlap készítése (hacsak nem egyértelmű, munkajellegű anyag küldéséről van
szó)
• Küldő (neve, telefonszáma), címzett (neve, titulusa, telefonszáma, faxszáma),
• Küldés dátuma
• Tárgy meghatározása, lehetőleg az e-mail-ről leírtak szellemében
• Küldött oldalak száma: 1+X formátumba, ahol X a fedőlap nélküli A4 oldalak száma
• Fax szövege: szem előtt tartandó, hogy az apró betűk a fogadó oldalon (átviteli okok és legtöbb helyen a hőérzékeny papírra történő nyomtatás miatt) általában nehezen olvashatóak
3.6 Munkavégzés, munkarend
3.6.1 A munkavégzés helye
A projekt munkái az alábbi helyszíneken fognak történni:
• Nemzeti Infokommunikációs Szolgáltató Zrt (1081 Budapest, Csokonai u. 3., 1135 Budapest, Csata u. 8., 0000 Xxxxxxxx, Xxxx x. 54-56.)
• Magyar Nemzeti Levéltár (0000 Xxxxxxxx, Xxxxx xxxx xxx 0-0., 0000 Budapest, Lángliliom u. 7., 1014 Budapest, Xxxx Xxxxxx 5.)
• Budapest Főváros Levéltára (1139 Budapest, Teve u. 3-5.)
• T-Systems Zrt (Xxxxxxxx, Xxxxxxxx xx 00.)
3.6.2 Munkaidő
A projektben a normál munkaidő vonatkozásában a Felek törzsidőt jelölnek meg, amely munkanapokon 9:00 órától 16 óráig tart.
A normál munkaidőn kívüli, és a munkaszüneti (vagy pihenő-) napra eső munkavégzésre a törvényben előírtakat kell alkalmazni.
A projekttagok egyedi és indokolt esetben a projektvezető engedélyével felmentést kaphatnak a fenti munkaidő alól, úgy, hogy a projekt sikerét ne veszélyeztessék, ill. az adott időben partner munkáját ne akadályozzák.
3.6.3 Szabadságolási rend
A projekt szoros határideire való tekintettel a projekt alapvetően nem teszi lehetővé a munkatársak hosszabb távollétét szabadságolás okán. A szabadságolásoknál – természetesen – figyelembe kell venni a Mt. előírásait.
A projekttagoknak a tervezett szabadságukat saját projektvezetőjük felé be kell jelenteni a tervezett szabadság kezdete előtt, legalább annak hosszának háromszorosát kitevő nappal.
4. Vállalkozó oldali Minőségbiztosítás
A Vállalkozó a projekt során saját ISO9001:2000 minőségbiztosítási rendszerének előírásai szerint dolgozik. A Minőségbiztosítási terv tartalmára vonatkozóan az ajánlat a mérvadó.
A megfelelő minőség ellenőrzésére a projektben rendszeres minőségügyi szemléket kell tartani, amelyeket dokumentálni kell. Ez a Vállalkozó minőségbiztosítási felelősének feladata.
A Megrendelő külső minőségbiztosítási szakértőket alkalmaz.
A Vállalkozó által alkalmazott minőségbiztosítási módszertan támogatja a Megrendelő oldali minőségbiztosítási tevékenységek teljes körű végrehajtását, Vállalkozó Megrendelő minőségbiztosítójával szorosan együttműködve járul hozzá a sikeres projekt megvalósításhoz, tehát az Elektronikus Levéltár projekt teljes időtartama alatt együttműködik Megrendelő Minőségbiztosítójával, aki folyamatos és teljes körű minőségbiztosítást végez a rendszerek átadásáig.
4.1 Minőségbiztosítási terv
A minőségbiztosítási terv a jelen PAD-tól elkülönült, mégis ahhoz szorosan kapcsolódó dokumentum, melynek célja a minőségbiztosítási feladatok meghatározása, a minőségbiztosítási folyamat leírása, valamint azon kritériumok megfogalmazása, amelyek alapján a projekt során létrehozott termékek, eredmények minősége mérhető. A projekt során nyújtott minőségbiztosítás kiemelten két fő tevékenységcsoportba sorolható:
- A projekt során végzett tevékenységek folyamatok nyomon követése és monitorozása (teljesítések figyelemmel kísérése, kockázatok kezelése, hibák kezelése és javítása),
- A projektmérföldkövekhez kapcsolódó minőségbiztosítási szemlék és tesztelések végrehatása.
Az egyes tevékenységcsoporthoz kapcsolódó feladatok, a célok eléréséhez szükséges tevékenységek részletes kifejtését a minőségbiztosítási terv tartalmazza.
4.2 Minőségügyi szemlék
A minőségi szemle célja annak ellenőrzése, hogy az elkészített termék, végrehajtott tevékenység megfelel-e a szakma által előírt követelményeknek, a Megrendelő elvárásainak, valamint a projekt céljának. A minőségi szemlék lebonyolításának időzítése a projekt mérföldkövekhez kapcsolódik.
A minőségi szemlék keretében
- Áttekintjük a kapcsolódó projektdokumentációt,
- Szükség esetén konzultálunk a projekt kulcsembereivel
- A szemle zárásaként jelentést készítünk az eredményről.
A minőségi szemlét a projekt minőségbiztosítója folytatja le.
4.3 Mérések a projektben
A minőségbiztosítás keretében tesztelhető, mérhető kritériumokat kell meghatározni, amelyek alapján a termékről vagy folyamatról megállapítható hogy rendelkezik-e az elvárt minőséggel.
A minőségi kritériumok meghatározásánál az e-Levéltári projekt esetében a felhasználók, vagyis az e-Levéltárat használó alkalmazottak, valamint a Levéltár ügyfelei szempontjából kell meghatározni. Ez alapján
- kiemelt figyelmet kell fordítani a projekt során kialakított rendszer rendelkezésre állására és a teljesítményére, terhelhetőségére;
- fontos, hogy az új alkalmazások összhangban legyenek a kialakított folyamatokkal;
- a minőségi kritériumnak objektíven kell meghatározniuk a termékeket.
Az egyes termékekhez, folyamatokhoz kapcsolódó minőségi feltételeket, azok mérésére alkalmas mérőszámokat, valamint a mérések módját a Minőségbiztosítási Terv tartalmazza.
5. Változáskezelési terv, a projekt terjedelmének kezelése
A projekt terjedelmének kijelölése az ajánlati kiírásban (különösen annak követelmény jegyzékében), az ajánlatban és a szerződésben megtörtént.
Az egyes követelmények értelmezése és megvalósítási módjának pontos megadása a követelmény specifikációban történik meg, amely a projekt egyik első terméke, melyet a Megrendelő véleményez és elfogad. A követelmény specifikáció a rendszertervvel együtt készül el és minden egyes követelményhez megadja, hogy annak a követelménynek a teljesítési módja a rendszerterv mely kötetének mely fejezetében került részletes leírásra.
A rendszerterv és a követelményspecifikáció elfogadásával a Megrendelő elfogadja a követelmények ott megadott módjának értelmezését és teljesítésének módját is. Ennek
megfelelően a projekt végrehajtása során, amennyiben a Megrendelő vagy a Vállalkozó ettől a tervtől és specifikációtól való eltérést kezdeményez, akkor azt változáskezelés keretében kell értékelni és lehet végrehajtani.
Változást kizárólag a projektvezetők kezdeményezhetnek. Változás kérés csak a megfelelő sablon alapján elkészített változáskérő lapon nyújtható be. A változáskérő lap a PAD IX. melléklete.
A változásokról minden esetben projektvezetői hatáskörben döntenek a felek. Amennyiben a változások a szerződés megváltoztatását is jelentik a projektigazgatók bevonása és jóváhagyása is szükséges.
A változások esetében a projektvezetők a megfelelő szakemberek bevonásával mérlegelik, hogy a változáskérés milyen kihatással van a projektre. Amennyiben a változás végrehajtása veszélyezteti a projekt határidőinek a betartását, vagy a Vállalkozó munkamennyiségének növekedésével jár, akkor a változtatási igényt elutasítják, azzal, hogy azt a projekt befejezése után, külön szerződés és finanszírozás keretében lehet csak végrehajtani.
Többelemű változások esetén az egyes változtatások együttes hatása lehet semleges. Vagyis a változtatás egyik eleme csökkenti, a másik növeli a Vállalkozó által elvégzendő munkamennyiséget és a változás elemek együtt nem hatnak ki negatívan a projekthatáridők betarthatóságára. Ilyen esetekben a változtatási igények elfogadhatók és a projekt keretében végrehajthatók.
Olyan változások nem fogadhatók el, amelyek valamely követelmény nem teljesüléséhez vezetnek.
6. Tesztelési terv
A projekt során a szállított hardver és szoftver termékek és megoldások tesztelésére részletes tesztelési terv készül. A tesztelés részleteit abban rögzítjük. A tesztelési terv és jegyzőkönyv sablonok jelen dokumentum V. és VI. mellékletét képezik.
7. Projekt terv
7.1 Projekt szakaszok
A projekt jelentősebb szakaszai, mérföldkövei
1. Szerződéskötés
2. Elfogadott PAD és minőségbiztosítási terv
3. Rendszerterv szállítása
4. Tessella SDB és scopeArchiv licencek szállítása
5. Részletes specifikáció szállítása
6. Xxxxxxxx, migrációs, teszt tervek szállítása
7. Infrastruktúra eszközök mennyiségi szállítása
8. Kialakított infrastruktúra átadása
9. Alkalmazásmodulok átadása
10. Megrendelői tesztelés
11. Rendszerdokumentációk átadása
12. Oktatások
13. Átállás, migráció
14. Próbaüzem
15. Végteljesítés próbaüzem után
A projekt fizetési mérföldkövei a következők:
1. Tessella SDB és scopeArchiv és Oracle licencek szállítása
2. Rendszerterv szállítása
3. Infrastruktúra eszközök mennyiségi szállítása
4. Kialakított infrastruktúra átadása
5. Alkalmazásmodulok átadása
6. Végteljesítés próbaüzem után
7.2 Ütemterv
A részletes ütemtervet a PAD mellékletét képező MS Projekt fájlban adjuk meg. Az ütemterv tartalmazza az összes leszállítandó elő- és elkészítéséhez szükséges feladatokat, a projekt összes szakaszát és mérföldkövét. Megadja az egyes feladatok kapcsán leszállítandó termékeket. Tartalmazza az egyes feladatok végrehajtásához szükséges előfeltételeket, a végrehajtás megkezdésének és befejezésének tervezett idejét.
Az ütemterv része a Megrendelő által elvégzendő a projekt végrehajtásához elengedhetetlen feladatok, valamint az átadás/átvételi revíziós folyamatok tervezése is.
A részletes ütemtervet a projektvezetői szint kölcsönös egyetértésben módosíthatja, amennyiben a módosítások nincsenek kihatással a projekt véghatáridejére, fő mérföldköveire és fizetési ütemezésére.
8. Projektirányítás
8.1 Tervezés
Az ajánlatadási szakaszban sor került a projekt átfogó tervének elkészítésére. Ez a terv tartalmazza a projekt egyes szakaszainak nagyvonalú ütemtervét, feladattervét és mérföldkőtervét.
A projekt egyes, a módszertan szerint egymást követő szakaszainak kezdete előtt megfelelő időben sor kerül a nagyvonalú ütemterv aktuális szakaszának részletes megtervezésére.
A projekt szakaszainak kivitelezése során a projektvezetés „görgetett” módon, általában a soron következő 4 hetes időszakra, de logikusan a mérföldkövekhez igazodva, állítja elő a projektterv feladatainak és lépéseinek lebontását az egyes tevékenységek és felelősök szintjére. A projekt tervezésének menetét a projektvezetés irányítja, valamint felügyeli.
A projekt ütemtervének elkészítéséhez és a haladások követésére a MS Project 2003 formátumú fájlt használunk.
8.2 Haladás ellenőrzése, jelentések
A projekt folyamán a projektvezetés rendszeresen és módszeresen végzi a megvalósulás összevetését a projekt tervével (ennek a neve: követés). Vállalkozó projektvezetője a munkacsoportok állapotjelentéseiből kiindulva, heti rendszerességgel számba veszi, az egyes tevékenységeket és meghatározza azok készültségi szintjét, valamint a további teendőket az eredményes megvalósulás érdekében.
Ideális esetben ez a tevékenységre vonatkozó terv teljesülésének konstatálását, egyúttal dokumentálását jelenti; minden egyéb esetben vagy intézkedést jelent a teljesítés érdekében, vagy szélsőséges esetben akár a terv módosítását is, ez utóbbi esetben a megfelelő indoklást is kell adni.
A heti ellenőrzés eredményét a Vállalkozó oldali projektvezető egy heti jelentésben összegzi és a jelentést továbbítja a Megrendelő oldali projektvezetőnek. A heti jelentés sablonját a PAD VII. mellékletében adjuk meg.
8.3 Átadás-átvételek
A szerződésben rögzített fizetési mérföldkő a mindkét fél által elfogadott termék/szolgáltatás átvételére vonatkozik, amelyet teljesítés igazolás kiállítása követ. A teljesítési igazolás kiállításának feltétele az átadás-átvételi folyamat eredményes befejezése.
Az átadás / átvételi folyamatok célja, hogy a Vállalkozó által késznek ítélt, saját minőségbiztosítási folyamatával ellenőrzött, dokumentumokat, eszközöket, rendszereket Megrendelőnek dokumentáltan átadja, Megrendelő ellenőrizze és átvegye.
Tekintettel a termékek sajátosságaira a dokumentumok, infrastruktúra elemek és a rendszerek átadása különböző folyamatokban valósul meg.
A folyamatok végén azonban minden esetben az átadás – átvétel dokumentálása valósul meg, melynek során felek átadás–átvételi jegyzőkönyvet állítanak ki és írnak alá. A Megrendelő nem jogosult szabályosan aláírt átadás-átvételi dokumentummal igazolt átvételtől az aláírást követően elállni. A projekt átadás-átvételi jegyzőkönyvvel lefedett része az aláírást követően teljesítettnek tekintendő figyelembe véve a jegyzőkönyvben megadott esetleges hiány, vagy hibalistára is.
Az egyes projektelemek átvételére, az átadás – átvételi jegyzőkönyv aláírására a Megrendelő oldaláról jogosultakat a 3. pontban adjuk meg. Olyan termékek esetében,
amelyek a 3. pontban nem kerültek felsorolásra a Megrendelő oldali projektvezető jogosult az átvételre, aki ezt a jogát írásban másra átruházhatja.
Az átadás-átvételi jegyzőkönyvek aláírása után az átadott/átvett termékekre vonatkozóan a TIB (Teljesítésigazolási Bizonylat) kiadása nem tagadható meg.
Az infrastrukturális elemek, eszközök tekintetében a kárveszély Megrendelőre történő átszállásának időpontja az eszközök Megrendelő telephelyére történő leszállításának és azok szállítólevélen/átadás-átvételi jegyzőkönyv alapján történő átadásának időpontja.
8.3.1 Tessella SDB, scopeArchiv és Oracle licencek átadás-átvétele
1. Az átadás-átvételi eljárás első lépése a scopeArchiv és a Tessella SDB esetében aláírt licensz szerződések, valamint a kapcsolódó CD mellékletek; az Oracle esetében pedig az ún. Welcome letter átadása, és az átadás-átvételről szóló jegyzőkönyv aláírása.
2. Az átadás-átvételt követi a Szerződés szerint a teljesítés igazolás kiállítása, amelyet a kifizetési kérelem benyújtásához szükséges dokumentációs rendben kell elkészíteni:
a. NISZ: MIE-75913/2 TIB ISO lap – Oracle 8db, Tessella SDB, ScopeArchiv licensz 63%, Aláírók: Xxxx Xxxxx, Xxxxx Xxxxxx Xxxxxx
b. MNL: Teljesítési igazolás – Oracle 4 db, ScopeArchiv licensz 22%, Aláírók: xx. Xxxx Xxxxxxxxx, Xxxxx Xxxxxx Xxxxxx (a Szerződés 20.4 miatt)
c. BFL: Teljesítés igazolás – Oracle 3 db, ScopeArchiv licensz 17%, Aláírók: dr. Á. Xxxxx Xxxxxx, Xxxxx Xxxxxx Xxxxxx (a Szerződés 20.4 miatt)
3. A vállalkozónak ezt követően 2-2 számlát kell benyújtania mindegyik konzorciumi tagnak a fenti TIB-ek tartalmával szinkronban, a prioritásoknak (86,61%, 13,39%) megfelelő osztással, tehát összesen 6 db számla készül.
8.3.2 Infrastruktúra elemek mennyiségi átadás - átvétele
Az infrastruktúra elemek fizikai átadása az eszközöknek a Megrendelő által megjelölt telephelyére szállításával és elhelyezésével történik meg. Mennyiségi átadás során nem kell vizsgálni az infrastruktúra eszközök működőképességét, csak a megadott mennyiségben való leszállítását. A mennyiségi átadás-átvétel részben vagy egészben teljesíthető a Vállalkozó telephelyén is, ebben az esetben átadás-átvételi jegyzőkönyvben, és tárolási nyilatkozatban kell rögzíteni az érintett tételeket.
Az infrastruktúra elemek mennyiségi átadása során, a leszállítandók listája alapján Megrendelő a saját szabályzatainak megfelelő módszertan alapján ellenőrzi, hogy minden tétel leszállítása és átadása megtörtént-e. Ezután egy tételes Átadás – Átvételi jegyzőkönyv készül, amely tartalmazza az átadó és átvevő személyek adatait, az átadás körülményeit és az átadott – átvett termékek listáját. Ha az eredetileg tervezetthez képest nem minden kerül átadásra, akkor egy hiánylista is készül a még hiányzó termékekről.
Előteljesítés csak alapos okkal utasítható vissza.
Az Átadás – Átvételi jegyzőkönyvet Megrendelő és Vállalkozó aláírásával igazolja.
• A mennyiségi átvételt az Megrendelő, az Üzemeltető és a Vállalkozó kijelölt képviselője végzi.
• A mennyiségi átadás-átvétel alapja minden esetben a termék fizikai meglétének ellenőrzése. Nem célja a leszállított termék (eszköz) leltározásra történő felkészítése (szétbontása).
• A mennyiségi átadás-átvétel során jegyzőkönyv készül, mely a Megrendelő aláírásával igazolja a mennyiségi átadás sikerességét.
• A teljesítés igazolását a sikeres mennyiségi átvételi eljárás lebonyolítása után az Üzemeltető által kijelölt átadás-átvételt vezető személy végzi.
8.3.3 Kiépített hardver infrastruktúra átadás - átvétele
Az infrastruktúra átadása a megrendelő telephelyein a megfelelő hardver infrastruktúra kiépítésével, az alapszoftverek telepítésével és paraméterezésével történik meg.
Miután Vállalkozó készre jelentette a hardver infrastruktúra kiépítését Felek közösen elvégzik annak működési és DRP tesztelését a korábban átadott és elfogadott teszttervek felhasználásával. A tesztelésről tesztjegyzőkönyvek készülnek.
Amennyiben a tesztelés során hibát találnak, akkor azt rögzíteni kell. A javítás, vagy eszközcsere után a hibás elem tesztelését újra el kell végezni a rá vonatkozó összes tesztesetre vonatkozóan (a korábban sikeresekre is). Ezt a folyamatot addig kell ismételni, amíg az összes teszteset hiba nélkül hajtható végre.
A sikeres tesztelés után átadás – átvételi jegyzőkönyvet kell kiállítani.
A kiépített infrastruktúra átvétele több lépésben részenként (pl. telephelyenként) is megtörténhet.
8.3.4 Dokumentumok átadás - átvétele
A dokumentumok fizikai átadása a dokumentum fájlok, vagy a kinyomtatott dokumentum Megrendelőhöz juttatásával történik meg. Ennek formája lehet fizikai adathordozó személyes átadása, vagy e-mail, esetleg FAX küldés, vagy papír alapú dokumentumok személyes vagy postai úton történő átadása is. A nagyobb terjedelmű (több, mint 5 oldal) dokumentumokat minden esetben csak file formában adjuk át, kinyomtatva nem.
Dokumentumok esetében az átadás – átvétel folyamata magában foglalja a dokumentum revízióját, azaz tartalmának a Megrendelő általi ellenőrzését és szükség esetén közös kiigazítását is.
A projekt végrehajtási idő rövidségére tekintettel a dokumentumok revíziója és átvétele egyetlen iterációban történik.
A dokumentumok átadása után 3-5 munkanap áll Megrendelő rendelkezésére, hogy az átadott dokumentumokat véleményezze. A véleményezést követően felek 3-5 munkanap közös műhelymunkával a Megrendelő változtatási igényeit megbeszélik és megegyezés
esetén a Vállalkozó a műhelymunkát követően a dokumentumban átvezeti a megbeszélt tartalmakat, és ezen módosításokat jóváhagyásra megküldi a Megrendelőnek.
A műhelymunka után esetlegesen megmaradó kidolgozatlan, vagy vitás területeket, pontokat eltérés listán rögzítik. Az ilyen területeket az átadás – átvétel után a problémát tovább tárgyalva, és/vagy eszkalálva kell rendezni (és a dokumentum új verziójában rögzíteni), de a projekt menete ilyen dokumentációs hiba, vagy egyet nem értés miatt nem állhat le. A megvalósítás során, amennyiben azt a dokumentum érinti, a vitás pontok megvalósítását a vita rendezése utánra kell időzíteni.
A megrendelői véleményezés és a műhelymunka ideje az ütemezésben dokumentum típusonként pontosan meghatározott. Azokat mindkét részről be kell tartani.
A Vállalkozó, illetve Megrendelő oldali projektvezetés felelőssége, hogy a dokumentumok átadási időpontjára ki legyenek jelölve azok a felelős szakemberek, akik az átadás átvételi folyamatban részt vesznek.
Előteljesítés csak alapos okkal utasítható vissza.
8.3.5 Szoftver rendszerek átadás - átvétele, hibakezelés
A szoftver rendszerek átadása az alkalmazások teszt környezetbe telepítésével, paraméterezésével és elindításával történik meg.
A teszt környezetbe telepítés után a Megrendelőnek 30 napja van (az ütemtervben meghatározottak szerint) az összes rendszerteszt elvégzésére. Tesztelés közben Megrendelő a megtalált hibákat folyamatosan (a felfedezést követő maximum 1 munkanapon belül) rögzíti a dokumentálás megkönnyítésére a Vállalkozó által beüzemelt hibajegy-kezelő rendszerben. A Vállalkozó a felfedezett hibákat folyamatosan javítja, a javítás eredményét a hibajegy-kezelő rendszerben dokumentálja és rendszeresen (kb. hetente) kiadott új verziókban a javított alkalmazásokat telepíti Megrendelő teszt rendszerébe. A hibajegy-kezelő rendszert mindkét félnek kötelező használni. Hiba rögzítésére más rendszer, vagy megoldás nem használható. A 30 napos ciklus egy legalább
7 napos Megrendelői teszteléssel zárul, ezért ebben az időszakban a Vállalkozó csak Megrendelő kérésére ad ki új verziót.
A hibákat megrendelő súlyosság szerint kategorizálja feladáskor (H1, H2, H3). Felek hetente hibaértekezletet tartanak az érintett szakemberek és a projektvezetők részvételével, amikor a kategorizálást felülvizsgálják, és szükség esetén módosítják.
A teszt időszak nem hosszabbítható meg. A teszt időszakban fel nem fedezett hibákat a garanciális kötelezettség keretében ki kell javítani, de az átvételt az átvétel időpontjáig nem észlelt hibák nem akadályozhatják meg. Hibának minősül, ha a rendszer nem az elfogadott rendszertervnek megfelelően működik. Nem minősül hibának, ha a rendszer nem a felhasználói igényeinek megfelelően működik, ha a felhasználói igény eltér a rendszertervben rögzítettektől.
A teszt időszakot követi egy 7 munkanapos javítási időszak, melyben a maradék hibákat javítani kell. Ebben az időszakban Megrendelő által felfedezett további hibák a fentiek értelmében rögzítésre kerülnek, de Vállalkozó ebben a ciklusban nem kötelezhető a hibák javítására.
A javítási időszakot az UAT (user acceptance test) követi. Az UAT feladata annak megállapítása, hogy minden a teszt időszakban megtalált hiba javításra került-e. Ha az
UAT során olyan újonnan felfedezett hiba kerül elő, amely az előző verzióban is benne volt, csak a tesztelés során nem derült ki, akkor azt rögzíteni és garanciában javítani is kell, de ez nem akadályozhatja meg az átvételt. A teszt időszakban rögzített és az UAT-ban nem, vagy nem megfelelően javítottnak talált hibákat újra hibaértekezleten minősíteni kell. Az átvétel feltétele, hogy a rendszerben ne legyen ebbe a kategóriába tartozó H1-es hiba, valamint, hogy a H2 és H3 hibák száma együtt ne legyen 20-nál több rendszerkomponensenként.
Ha a felfedezett hiba valamely dobozos termékre vonatkozik (beleértve a Tessella SDB és a scopeArchiv alkalmazásokat is), akkor azok javítása nem tartozik a projekt feladatai közé, így az átvétel akadálya sem lehet.
Előteljesítés csak alapos okkal utasítható vissza.
Szoftver hibakategóriák
H1-nek minősül a hiba, ha a rendszer valamely alapfunkciója egyáltalán nem használható és megkerülő megoldást sem létezik a rendszerben.
H2-nek minősül a hiba, ha egy funkció hibásan működik, de létezik a rendszerben megkerülő megoldás, azaz az elvégzendő feladat más módon, esetleg több munkával, vagy kényelmetlenebb módon, de elvégezhető. H2 kategóriájú a hiba akkor is, ha nem megkerülhető, de a rendszer olyan funkcióját érinti, amely nem elengedhetetlenül szükséges a rendszer használatához.
H3 kategóriába tartozik minden olyan hiba, amely nem tartozik a fenti két kategóriába.
Ezek elsősorban szépséghibák, hibás feliratok, apró kényelmetlenségek.
9. A PROJEKT ELJÁRÁSRENDJE
9.1 Projekt rendezvények
9.1.1 Felügyelő Bizottság ülése (FB)
Résztvevők: Projekt tulajdonosok Megrendelő projektvezetője Vállalkozó projektvezetője Delegált tagok
Célja: A projekt célok teljesülésére ható, a költségvetést vagy az ütemezést befolyásoló döntések meghozatala, a projekt működési kérdéseinek megvitatása, a projekt státuszának megbeszélése, konfliktushelyzetek megelőzése, kezelése.
Időzítés: Alkalmanként
Kezdeményező: Projekt tulajdonosok (a rendkívüli üléseket két FB tag együttesen kezdeményezheti)
Levezető: Megrendelő Projektvezetője Jegyzőkönyvező: Projekt Adminisztrátor Kimenet: Jegyzőkönyv
9.1.2 Projektirányítás ülése (PVB)
Résztvevők: Megrendelő Projektvezetője, Vállalkozó Projektvezetője
Lehetséges meghívottak:
Alprojektvezetők, munkacsoportvezetők, minőségbiztosítók képviselői, projekttámogatók
Célja: A projekt napi operatív kérdéseinek megvitatása, projekt helyzetének megbeszélése, konfliktushelyzetek megelőzése, kezelése, döntés-előkészítés
Időzítés: Hetente, keddenként, 900 órakor
Kezdeményező: A rendkívüli üléseket két PVB tag együttesen kezdeményezheti Levezető: Megrendelő Projektvezetője
Jegyzőkönyvező: Projekt Adminisztrátor Kimenet: Jegyzőkönyv
9.1.3 Alprojekt/munkacsoport megbeszélés
Résztvevők: Alprojektek vezetői, Alprojektek tagjai, Projektvezető (nem kötelező), munkacsoport vezető, munkacsoport tagok, minőségbiztosítók képviselői, projekttámogatók, PVB tagok (nem kötelező)
Célja: A munkacsoport napi operatív kérdéseinek megvitatása
Időzítés: Szükség szerint
Kezdeményező: Alprojekt vezetője, vagy munkacsoport vezető Levezető: Alprojektvezető, vagy munkacsoport vezető
Jegyzőkönyvező: Projekt Adminisztrátor, vagy kinevezett munkacsoport tag Kimenet: Emlékeztető, vagy jegyzőkönyv
9.1.4 Oktatás
Résztvevők: Alkalmanként, célhoz illeszkedően meghatározott
Célja: Előre meghatározott ismeretek átadása szervezett formában Időzítés: Alkalmanként
Kimenet: Ügyfél megelégedettségi formalap, Jelenléti ív
9.1.5 Egyéb rendezvények
Résztvevők: Alkalmanként, célhoz illeszkedően meghatározott
Célja: Egyes szakmai, menedzsment, üzleti kérdések részletes megbeszélése, információszerzés, konszenzus-keresés
Időzítés: Alkalmanként
Kezdeményező: Megrendelő Projektvezető, Vállalkozó Projektvezető, Funkcionális Projekt Vezető
Levezető: Kezdeményező által meghatározott Jegyzőkönyvező: Projekt Adminisztrátor
Kimenet: A kezdeményező által meghatározott
10. Dokumentációkezelés
10.1 Alapelvek, célok
A projekt dokumentációs rend célja, hogy a projekt során előállított (elektronikus és papír alapú) dokumentumok strukturáltan rendelkezésre álljanak, tárolhatók és egyértelműen visszakereshetők legyenek. A dokumentációs rend és az ISO biztosítja, hogy
az egyes dokumentumok élettörténetét nyomon lehessen követni, és verziókeveredés ne fordulhasson elő.
10.2 Dokumentumok és szoftver verziók azonosítása
A projektben a dokumentumok egységes azonosítására törekszünk. Ennek érdekében a dokumentumok elnevezése során minden esetben az alábbi felépítést alkalmazzuk:
ELEV_<Dokumentum neve>_<kötet azonosító>_<kiadás dátuma>_<verziószám>_<egyéb információ>.<kiterjesztés>
A <Dokumentum neve> a dokumentum rövid pár szavas azonosítása, vagy rövidítése.
Pl. PAD, Rendszerterv, DRP, Tesztterv, stb.
<kötet azonosító> A tartalmazott kötetre utaló néhány betűs rövidítés. Pl: KIA, XXX, KRI, stb., amennyiben értelmezhető.
A <verziószám>-ot a Konfiguráció és verziókezelésben megadottak szerint kell megadni.
Az <egyéb információ> alatt értjük a korrektúrát, a monogramos módosítást, és bármi egyéb hozzáadott információt.
10.3 Dokumentumok nyilvántartása
A projekttel kapcsolatos dokumentumokat a projektben résztvevő szervezetek saját dokumentációs rendjüknek megfelelően iktatják és tárolják.
A projektben hivatalosan átadandó dokumentumokat (eredménytermékek, állapotjelentések, emlékeztetők) iktatni kell.
A projekttel kapcsolatos papíralapú dokumentációkat a projektdossziékban kell tárolni. A papíralapú dokumentumok elektronikus változatát, amennyiben létezik a projektkönyvtár megfelelő alkönyvtárában meg kell őrizni.
Az elektronikusan készült dokumentumokat projektkönyvtár megfelelő alkönyvtárában kell tárolni.
Minden dokumentumot, a fentieknek megfelelően, egyedi azonosítóval kell ellátni.
A dokumentumokról nyilvántartást kell vezetni, amelynek tartalmaznia kell a dokumentum azonosítóját, kiadásának idejét, tárgyának rövid leírását és tárolási helyét.
10.4 Dokumentumok tárolása
10.4.1Elektronikus dokumentumok (fájlok) tárolása
A projekt során az előállított elektronikus állományok egy előre kialakított könyvtár- szerkezetben kerülnek elhelyezésre, amelynek szerkezete adott, részben azonban, az ésszerűség határai között, módosítható, azaz munkacsoportonként testre szabható.
A könyvtárstruktúra fő részei:
K1 | K2 | K3 | Tartalom |
Info | Információk | ||
PV | Projektvezetéssel kapcsolatos dokumentumok | ||
Admin | Projektirányítás adminisztrációja | ||
Terv | Projektirányításra vonatkozó tervek (PAD, Projektterv, | ||
stb.) | |||
AllJel | Vezetői állapotjelentések (heti, projektvezetői) | ||
Emlek | Emlékeztetők/Jegyzőkönyvek projektvezetői | ||
értekezletekről | |||
MU | Műszaki dokumentumok (megvalósítás anyagai) | ||
Felmeres | Igényfelmérés | ||
KovSpec | Követelmény specifikáció | ||
Terv | Tervezés | ||
Fejl | Fejlesztés anyagai | ||
Test | Tesztelés | ||
Migr | Migráció | ||
Inst | Telepítés, installálás | ||
Doc | Dokumentációk | ||
Okt | Oktatás | ||
QM | Minőségbiztosítással kapcsolatos dokumentumok | ||
Mintak | Dokumentum minták | ||
Terv | |||
HR | Emberi erőforrás anyagok | ||
Szerz | Szerződéses anyagok | ||
Mintak | A projektben használandó minták, template-k | ||
Keszul1 | gyüjteménye Munkakönyvtár a készítés alatt levő anyagoknak | ||
Kesz2 | Az elkészült, jóváhagyásra váró anyagok | ||
Atadott3 | Vállalkozó által Megrendelőnek átadott, kimenő | ||
Kapott4 | anyagok Megrendelőtől kapott, bejövő dokumentumok |
10.5 Archiválás
A projektdokumentáció archiválása szakaszonként történik, azaz a projektszakasz zárását követően a Projektadminisztráció zárolja az addigi dokumentációt. Ez azt jelenti, hogy abba írni, a dokumentumokon módosítani nem lehet. Az így keletkezett dokumentáció csak olvasható (ez vonatkozik az elektronikusan tárolt adatokra is), és fizikailag is elkülönítendő a másik szakasz dokumentumaitól (hálózaton más alkönyvtárba
/ folderbe kell kerülnie).
1 A könyvtáron belüli alkönyvtár szerkezet megegyezik az előzőekben felsorolt szerkezettel.
2 A könyvtáron belüli alkönyvtár szerkezet megegyezik az előzőekben felsorolt szerkezettel.
3 A könyvtáron belüli alkönyvtár szerkezet megegyezik az előzőekben felsorolt szerkezettel.
4 A könyvtáron belüli alkönyvtár szerkezet megegyezik az előzőekben felsorolt szerkezettel.
11. ADATKEZELÉS
(Lásd még: dokumentációkezelés)
11.1 Az adatkezelés célja
Az adatkezelés célja a projektben azonosított adatfajták tervezett, hatékony biztonságos előállítása, kezelése, felhasználása.
11.2 Kezelt adatfajták
Az előző fejezetben tárgyalt dokumentumokon kívül a projektben az alábbi adatfajták fordulnak elő:
• Szoftver forráskód
• CASE eszközökben kezelt adatok
• Relációs ill. objektum-orientált adatbázisban tárolt adatok
• Mérési adatok
11.3 Az adatkezelés felelőse
Az adatkezelés itt felsorolt vonatkozásaiért a projektvezető felel.
11.4 Az adatok azonosítása
Az adatok adatfájlokban jelennek meg, az elsődleges azonosítás a fájlneveken keresztül történik, a „Dokumentumkezelés” fejezetben tárgyalt könyvtárstruktúrában. A relációs adatbázisban tárolt adatok azonosításáért a kezelő alkalmazás (pl. PMTool, PROJ3) felelős, az az ott alkalmazott módon történik.
11.5 Az adatok formátuma
A projektben alkalmazott adatformátumok:
• MS Word 2003
• MS Excel 2003
• MS Projekt 2003
• MS Xxxxx 2003
• MS PowerPoint 2003
• Java, J2EE: a forráskódok nyelvi verzióit a rendszerterv határozza meg.
• StarUML 1.2
• Mérési adatok Excel 2003-ban vagy csv-ben (iso-8859-2)
11.6 Adatok gyűjtése, tárolása, feldolgozása, szétosztása, az adatminőség biztosítása
Az adatokat a „Dokumentumkezelés” fejezetben megadott könyvtárszerkezetben kell tárolni, ha csak lehet. A forráskódot, illetve a kódhoz tartozó adatokat konfigurációkezelő eszközben kell tárolni.
11.7 Hozzáférési jogosultságok
A projektvezető határozza meg az egyes adatfajtákhoz és adatállományokhoz tartozó hozzáférési jogosultságokat, a következő elvek szerint:
• alapértelmezésben az adatok a teljes projektszervezet számára elérhetők.
• valamilyen (pl. üzleti) szempontból érzékeny adatokhoz a hozzáférés korlátozható
• ha alvállalkozó is része a projektszervezetnek, ő csak a számára releváns adatokhoz férhet hozzá.
11.8 Az adatok életciklusa, archiválás
Az adatok először „munkaadatként” jelennek meg, ilyenkor nem kell követni a változásaikat. Ha később konfigurációs elem részei lesznek, konfigurációkezelés alá kell őket vonni, és a változtatásukra a megfelelő szabályt kell alkalmazni. Amikor az adat egy
„baseline” része lesz, az adott változata befagyasztásra kerül. Az adat az adatgazda döntése alapján kikerülhet a konfigurációkezelésből.
A konfigurációkezelés alá vont adatok archiválásáról a Konfiguráció- és verziókezelési terv intézkedik, a dokumentumok esetében a „Dokumentációkezelés” fejezetben leírtak az irányadók.
12. Konfiguráció- és verziókezelés
A konfigurációkezelés foglalkozik a projekt során elkészített termékek verziókezelésével és a megvalósított rendszerek konfigurációinak nyilvántartásával, menedzselésével. Nem vonatkozik a dobozos szoftverek verziókezelésére.
A konfiguráció és verziókezelés részletes szabályozására Konfiguráció- és verziókezelési terv-et kell készíteni, amely a Minőségbiztosítási terv része.
A verziókezelés célja, hogy minden a projekt során keletkező projekttermék egyszerűen menedzselhető és nyomon követhető legyen (függetlenül attól, hogy a projekt életciklusának melyik szakaszában keletkezett).
Minden, a projekt során keletkező projekttermék a verziókezelés hatáskörébe tartozik.
A konfigurációkezelés célja minden egyes, a Megrendelő számára átadott alrendszer konfigurációjáról naprakész nyilvántartás vezetése.
13. KOCKÁZATKEZELÉS
13.1 Kockázatok kezelésének módja
Kockázat alatt azoknak a negatív hatásoknak az összességét értjük, amelyek jelentősen befolyásolhatják a projekt sikerét. A kockázati tényezők közül fontosságát tekintve kiemelhetők az alábbi kockázatok:
• rendelkezésre álló emberi erőforrások (megfelelő tudás, érdekeltség, stb.),
• rendelkezésre álló idő,
• rendelkezésre álló anyagi erőforrások,
• a háttérrendszer,
• a forrásrendszerekből való elvárt minőségű adatok rendelkezésre állása.
A kockázati tényezők felsorolása nem lehet lezárt és nem lehet teljes. A kockázat definíciójából egyértelműen következő és/vagy azonosított kockázatokon túl a projekt megvalósítása során felmerülő egyéb kockázatok felismerése érdekében szükséges a projektben szereplő valamennyi résztvevő folyamatos aktív figyelme a hatáskörében jelentkező, a munkacsoportra vonatkozó tevékenységi kör sikerét veszélyeztető hatások iránt.
A kockázati tényezők felmerülését a projekttagok kötelesek a projektvezetés felé jelezni.
A kockázat tényezők gyűjtése, figyelemmel kísérése és elemzése a projektvezetés feladata.
A projekthez kapcsolódó kockázatokról és a hozzájuk tartozó paraméterekről Vállalkozó nyilvántartást vezet. A nyilvántartásban szerepelnie kell az alábbiaknak:
• A kockázat leírása,
• hatása a projektre nézve,
• tervezett megelőző, a bekövetkezés esélyét csökkentő lépések,
• esetleges bekövetkezés esetén a negatív hatást csökkentő lépések
• bekövetkezés valószínűsége (százalékban megadva),
• a kockázat súlya ötös skálán.
13.2 Kockázatok
Az azonosított kockázatokat a PAD-tól különálló, a T-Systems Dokushare Portál (xxxxx://xxxxxxxxx.x-xxxxxxx.xx/x-xxxxxxxx/xxxxxxx.xxxx) oldalán lévő elektronikus fájlban kell rögzíteni, és a PVB értekezleteken rendszeresen tárgyalni, kezelni.
14. MELLÉKLETEK
I. melléklet, Projektszervezet
Az infrastruktúra alprojekt az alábbi munkacsoportokra oszlik:
1.) Számítógépes rendszerek (szerverek, OS, mentés, storage) (Xxxxxxx Xxxxx) 2.) Hálózati megoldások (Cisco tűzfal, IPS, WiFi) (Xxxxx Xxxxx)
3.) Rendszer menedzsment (monitoring, Syslog) (Xxxxx Xxxxx) 4.) Vírusvédelem (McAfee Virusscan, ePO) (Xxxxxx Xxxxxxxx) 5.) Szabályzatok (DRP, BCP, WiFi szabályzat) (Xxxxxx Xxxxxx) 6.) Gépterem (Xxxxx Xxxxxx)
II. melléklet, Részletes ütemterv
A teljes részletességű ütemtervet Microsoft Project fájlban tartjuk nyilván, és tartjuk karban.
Időtartam | Kezdés | ||
Előfeltételek | 55 nap | Cs 13.01.17. | H 13.04.08. |
NISZ gépterem építés | 1 nap | K 13.03.05. | K 13.03.05. |
Tape-library számára hely biztosítása | 1 nap | Sze 13.03.13. | Sze 13.03.13. |
Róna utcai gépteremről átállás a Xxxxxxxx Xxxxxxxx Xxxxxx gépterem használatára | 0 nap | K 13.03.05. | K 13.03.05. |
Infrastuktúra kialakítása | 3 nap | Cs 13.01.17. | H 13.01.21. |
BFL | 0 nap | Cs 13.04.04. | Cs 13.04.04. |
Jelenlegi tűzfal infrastruktúráról a szolgáltatások átmozgatása külön kiszolgáló(k)ra | 0 nap | Cs 13.04.04. | Cs 13.04.04. |
NISZ | 3 nap | Cs 13.01.17. | H 13.01.21. |
Publikus cím igény megadása | 0 nap | Cs 13.01.17. | Cs 13.01.17. |
Belső címtartomány igény megadása | 1 nap | P 13.01.18. | P 13.01.18. |
Publikus címek biztosítása | 1 nap | H 13.01.21. | H 13.01.21. |
Belső címtartomány kijelölése és megadása | 1 nap | K 13.01.22. | K 13.01.22. |
Munkaállomás image-ek készítése | 0 nap | Cs 13.04.04. | Cs 13.04.04. |
BFL | 0 nap | Cs 13.04.04. | Cs 13.04.04. |
Helyi telepítendő tételes alkalmazáslista pontos verziószámokkal és igényekkel | 0 nap | Cs 13.04.04. | Cs 13.04.04. |
Helyi telepítendő alkalmazások átadása | 0 nap | Cs 13.04.04. | Cs 13.04.04. |
Munkaállomás hosztnév konvenció megadása | 0 nap | Cs 13.04.04. | Cs 13.04.04. |
Munkaállomásokon biztosítandó local account-ok megadása | 0 nap | Cs 13.04.04. | Cs 13.04.04. |
MNL | 0 nap | H 13.04.08. | H 13.04.08. |
Helyi telepítendő tételes alkalmazáslista pontos verziószámokkal és igényekkel | 0 nap | H 13.04.08. | H 13.04.08. |
Helyi telepítendő alkalmazások átadása | 0 nap | H 13.04.08. | H 13.04.08. |
Munkaállomás hosztnév konvenció megadása | 0 nap | H 13.04.08. | H 13.04.08. |
Munkaállomásokon biztosítandó local account-ok megadása | 0 nap | H 13.04.08. | H 13.04.08. |
Blade kiszolgálók előkészítése | 0 nap | H 13.04.08. | H 13.04.08. |
BFL | 0 nap | H 13.04.08. | H 13.04.08. |
Kiszolgálók beszerelése és üzembeállítása | 0 nap | H 13.04.08. | H 13.04.08. |
Tessella SDB előfeltételek | 28 nap | H 13.01.28. | Sze 13.03.06. |
0 nap | Cs 13.03.07. | Cs 13.03.07. |
Feladat | Időtartam | Kezdés | |
Projektindítás | 30 nap | Cs 12.10.18. | P 12.11.30. |
PAD, PT revízió | 10 nap | H 12.11.19. | P 12.11.30. |
Tessella és Scope licencek szállítása | 35 nap | H 12.11.12. | P 13.01.04. |
I. Pénzügyi részteljesítés (Tessella SDB és scopeArchiv licencek szállítása)5 | 0 nap | P 12.12.14. | P 12.12.14. |
Tessella SDB és scopeArchiv alapkiépítés elérhetővé tétele a levéltáraknak | 10 nap | H 12.12.17. | P 13.01.04. |
Rendszertervezés | 68 nap | P 12.10.19. | Cs 13.01.31. |
Infrastruktúra rendszertervek és KS elkészítés | 34 nap | Szo 12.11.10. | Sze 13.01.02. |
Infrastruktúra rendszerterv és KS revízió | 11 nap | Cs 13.01.03. | Cs 13.01.17. |
Szoftver rendszertervek és KS elkészítése | 55 nap | P 12.10.19. | H 13.01.14. |
Rendszerterv revízió | 13 nap | K 13.01.15. | Cs 13.01.31. |
II. pénzügyi teljesítés (Rendszertervek átadása) | 0 nap | Cs 13.01.31. | Cs 13.01.31. |
Részletes specifikáció elkészítése | 37 nap | K 13.01.15. | Sze 13.03.17. |
Részletes specifikáció revízió | 13 nap | Cs 13.03.18. | K 13.04.04. |
Egyéb tervek elkészítése | 42 nap | Cs 13.02.28. | K 13.04.30. |
Migrációs és átállási tervek elkészítése | 25 nap | Cs 13.03.07. | P 13.04.12. |
Migrációs és átállási terv revízió | 12 nap | H 13.04.15. | K 13.04.30. |
Tesztelési tervek elkészítése | 27 nap | Cs 13.02.28. | K 13.04.09. |
Tesztelési terv revízió | 12 nap | Sze 13.04.09. | Cs 13.04.25. |
Infrastruktúra eszközök szállítása | 50 nap | Cs 12.12.13. | Sze 13.02.27. |
III. Pénzügyi részteljesítés (Infrastruktúra eszközök mennyiségi szállítása) | 0 nap | Sze 13.02.27. | Sze 13.02.27. |
Infrastruktúra környezet kialakítása | 95 nap | Sze 13.02.20. | P 13.07.05. |
IV. Pénzügyi részteljesítés (fizikai környezet kialakítva) | 0 nap | H 13.04.29. | H 13.04.29. |
Rendszerfejlesztés, implementálás | 79 nap | K 13.01.15. | Sze 13.05.08. |
Oktatások lebonyolítása | 51 nap | H 13.05.13. | H 13.07.23. |
Megrendelői tesztelés, hibajavítás | 41 nap | H 13.05.06. | H 13.07.01. |
Dokumentációk készítése | 68 nap | Sze 13.04.10. | H 13.07.16. |
Felhasználói kézikönyvek készítése | 22 nap | Sze | P 13.05.10. |
5 A pénzügyi részteljesítések elnevezése a szerződésben lévő formában került rögzítésre.
Feladat | Időtartam | Kezdés | Befejezés |
13.04.10. | |||
Felhasználói kézikönyvek revízió | 10 nap | H 13.05.13. | P 13.05.24. |
E-learning tananyag készítése | 21 nap | H 13.05.27. | H 13.06.24. |
E-learning tananyag revízió | 10 nap | K 13.06.25. | H 13.07.08. |
Üzemeltetői dokumentáció elkészítése | 10 nap | K 13.06.18. | H 13.07.02. |
Üzemeltetői dokumentáció revízió | 10 nap | K 13.07.03. | H 13.07.16. |
Biztonsági szabályozások elkészítése | 31 nap | K 13.05.21. | K 13.07.02. |
Biztonsági szabályozások revíziója | 10 nap | K 13.07.02. | H 13.07.15. |
Átállás végrehajtása | 32 nap | K 13.06.12. | Sze 13.07.31. |
V. Pénzügyi részteljesítés (Alkalmazásmodulok leszállítva, migráció átvéve) | 0 nap | K 13.07.16. | K 13.07.16. |
Próbaüzem (14 naptári nap) | 11 nap | Sze 13.07.17. | Sze 13.07.31. |
Projekt záró dokumentumok elkészítése, projektzárás | 1 nap | Sze 13.07.31. | Sze 13.07.31. |
VI. Pénzügyi végteljesítés | 0 nap | Sze 13.07.31. | Sze 13.07.31. |
III. melléklet, Szerep- és hatáskörök
1. Projektvezetés
a. Vállalkozó projektigazgatója
Elsődleges felelőssége | A projekt elfogadtatása a szervezeten belül, a projekt erkölcsi támogatása. |
Feladatai | A projekt szponzori támogatása. Erőforrások biztosítása, döntés szerződést érintő ügyekben. |
Utasításokat ad | Saját projektvezetőnek |
Utasításokat kap | - |
Kapcsolatot tart | Saját projektvezetővel, saját projekt támogatókkal |
Jelent | - |
b. Vállalkozó projektvezetője
Elsődleges felelőssége | A projekt sikeres végrehajtása, kellő minőségben, határidőre, a rendelkezésre álló erőforrás és pénzügyi kereteken belül. |
Feladatai | A projekt irányítása a Megrendelő oldali projektvezető bevonásával, munkák ütemezése, koordinálása, feladatok kiadása, számonkérése, haladás figyelése, állapotjelentések készítése, munkacsoport-vezetés támogatása, együttműködés a Megrendelő projektvezetőjével, részvétel PV üléseken. |
Utasításokat ad | Munkacsoport vezetőknek, projekttagoknak saját szervezetén belül. |
Utasításokat kap | FB-től. |
Kapcsolatot tart | Munkacsoport vezetőkkel, projekttagokkal saját szervezetén belül. |
Jelent | FB-nek, saját projektigazgatójának. |
c. Vállalkozó alprojekt-vezetője
Elsődleges felelőssége | A projekt egy jól elkülöníthető területének sikeres végrehajtása, kellő minőségben, határidőre, a rendelkezésre álló erőforrás és pénzügyi kereteken belül. |
Feladatai | A projekt általa vezetett részterületének irányítása a Vállalkozó és a Megrendelő oldali projektvezető bevonásával, munkák ütemezése, koordinálása, feladatok kiadása, számonkérése, haladás figyelése, állapotjelentések készítése, munkacsoport-vezetés támogatása, együttműködés a Vállalkozó és a Megrendelő projektvezetőjével, részvétel PV üléseken. |
Utasításokat ad | Munkacsoport vezetőknek, projekttagoknak saját szervezetén belül. |
Utasításokat kap | Projektvezetőtől. |
Kapcsolatot tart | Munkacsoport vezetőkkel, projekttagokkal saját szervezetén belül. |
Jelent | Projektvezetőnek, saját projektigazgatójának (ha van). |
d. Megrendelő projektvezetője
Elsődleges felelőssége | A projekt sikeres végrehajtása, kellő minőségben, határidőre, a rendelkezésére álló erőforrás és pénzügyi kereteken belül. |
Feladatai | A projekt irányítása saját szervezetén belül, munkák ütemezése, koordinálása, feladatok kiadása, számonkérése, haladás figyelése, munkacsoport-vezetés támogatása, együttműködés a Vállalkozó projektvezetőjével. Szerződésen (saját meghatalmazásán) belül erőforrások biztosítása, döntés szerződésen belüli ügyekben, a projekt előrehaladásának figyelemmel kísérése, szerződés alapján szállítandó termékek elfogadása, részvétel PV üléseken. |
Utasításokat ad | Munkacsoport vezetőknek, projekttagoknak saját szervezetén belül. |
Utasításokat kap | FB-től, PVB-től |
Kapcsolatot tart | Munkacsoport vezetőkkel, projekttagokkal saját szervezetén belül. |
Jelent | FB-nek, PVB-nek |
2. Projekttámogató
Elsődleges felelőssége | A projekt szakmailag sikeres végrehajtása. |
Feladatai | Saját felügyeleti és irányítási szintjének szakmai, projektvezetési támogatása. Részvétel saját cégén belül a szakmai munkák irányításában, felügyeletében, a Vállalkozó által szállított termékek véleményezésében, a szakértői munkák támogatása a projekt teljes időszaka alatt. |
Utasításokat ad | - |
Utasításokat kap | Saját projektvezetőtől. |
Kapcsolatot tart | Saját FB és PV tagokkal, kulcsfelhasználókkal saját szervezeten belül. |
Jelent | - |
3. Munkacsoport vezető
Elsődleges felelőssége | A projekt sikeres szakmai bevezetése. |
Feladatai | A szakmai munkák koordinálása, felügyelete. |
Utasításokat ad | Saját munkacsoport tagjainak saját szervezeten belül. |
Utasításokat kap | Saját projektvezetőtől. |
Kapcsolatot tart | Saját projektvezetőjével, többi munkacsoport vezetővel, munkacsoportjának tagjaival. |
Jelent | Saját projektvezetőjének. |
4. Kulcsfelhasználó
Elsődleges felelőssége | A szállítandó rendszer felhasználói képviselete. |
Feladatai | Felhasználói képviselet az igények megfogalmazásában, a követelmény specifikáció és a rendszerterv véleményezése, részvétel a felhasználói tesztekben. |
Utasításokat ad | Saját beosztott. |
Utasításokat kap | Saját projektvezető, munkahelyi vezető. |
Kapcsolatot tart | Saját projektvezető, munkahelyi vezető. |
Jelent | Saját projektvezető, munkahelyi vezető. |
5. Minőségbiztosítás
a. Minőségügyi vezető
Elsődleges felelőssége | A projektcélok megfelelő minőségű teljesítése. |
Feladatai | A minőségügyi munkák koordinálása, felügyelete. |
Utasításokat ad | Saját munkacsoport tagjainak saját szervezeten belül. |
Utasításokat kap | Saját projektvezetőtől. |
Kapcsolatot tart | Saját projektvezetőjével, többi munkacsoport vezetővel, munkacsoportjának tagjaival. |
Jelent | Saját projektvezetőjének. |
b. Minőségügyi ellenőr
Elsődleges felelőssége | Az ellenőrzött folyamatok, termékek minőségi problémáinak feltárása. |
Feladatai | Projektfolyamatok, termékek minőségügyi ellenőrzése. |
Utasításokat ad | |
Utasításokat kap | Saját minőségügyi vezető. |
Kapcsolatot tart | Saját minőségügyi vezető. |
Jelent | Saját minőségügyi vezető. |
6. Megrendelő oldali műszaki szerepkörök
a. Tanácsadó, szakértő
Elsődleges felelőssége | Helytálló információk átadása. |
Feladatai | Szakterületének megfelelő kérdésekben a projekttagok munkájának magas szakmai színvonalú segítése. |
Utasításokat kap | Saját projektvezető, munkahelyi vezető. |
Kapcsolatot tart | Saját projektvezető, munkahelyi vezető. |
Jelent | Saját projektvezető, munkahelyi vezető. |
b. Minőségbiztosító
Elsődleges felelőssége | Helytálló információk átadása. |
Xxxxxxxxx | Xxxxxxxxxxxxxxx megfelelő kérdésekben a projekttagok munkájának magas szakmai színvonalú segítése, a projekttervben szereplő feladatok teljesülésének szakmai ellenőrzése. |
Utasításokat kap | Saját projektvezető, munkahelyi vezető. |
Kapcsolatot tart | Saját projektvezető, munkahelyi vezető. |
Jelent | Saját projektvezető, munkahelyi vezető. |
c. Rendszergazda
Feladatai | Meglévő és a projekt során szállított rendszerek üzemeltetése. |
Utasításokat kap | Saját munkahelyi vezető. |
Kapcsolatot tart | Saját munkahelyi vezető. |
Jelent | Saját munkahelyi vezető. |
7. Vállalkozó oldali műszaki szerepkörök
a. Szervező
Elsődleges felelőssége | Szállítandó rendszerek elemek szállításának, tervezésének, fejlesztésének megszervezése. |
Feladatai | Szállítandó rendszerek elemek szállításának, tervezésének, fejlesztésének megszervezése. |
Utasításokat kap | Saját munkacsoport vezető. |
Kapcsolatot tart | Saját munkacsoport vezető, munkacsoport tagok. |
Jelent | Saját munkacsoport vezető. |
b. Tanácsadó, szakértő
Elsődleges felelőssége | Helytálló információk átadása. |
Feladatai | Szakterületének megfelelő kérdésekben a projekttagok munkájának magas szakmai színvonalú segítése. |
Utasításokat kap | Saját projektvezető, munkahelyi vezető. |
Kapcsolatot tart | Saját projektvezető, munkahelyi vezető. |
Jelent | Saját projektvezető, munkahelyi vezető. |
c. Fejlesztő
Elsődleges felelőssége | Megfelelő színvonalú munkavégzés. |
Xxxxxxxxx | Xxxxxxxxxxxx vezetője által kiosztott fejlesztési feladatok elvégzése. |
Utasításokat kap | Saját munkacsoport vezetője. |
Kapcsolatot tart | Saját munkacsoport vezetője, munkacsoport tagok. |
Jelent | Saját munkacsoport vezetője. |
d. Tervező
Elsődleges felelőssége | Szállítandó rendszerek követelményeknek megfelelő megtervezése. |
Feladatai | Szállítandó rendszerek követelményeknek megfelelő megtervezése. |
Utasításokat kap | Saját munkacsoport vezető. |
Kapcsolatot tart | Saját munkacsoport vezető, munkacsoport tagok. |
Jelent | Saját munkacsoport vezető. |
e. Tesztelő
Elsődleges felelőssége | A tesztelési feladatok körültekintő, alapos elvégzése. |
Feladatai | A kiosztott tesztelési feladatok elvégzése. |
Utasításokat ad | |
Utasításokat kap | Saját munkacsoport vezető. |
Kapcsolatot tart | Saját munkacsoport vezető, munkacsoport tagok. |
Jelent | Saját munkacsoport vezető. |
f. Technológus, architektúra tervező
Elsődleges felelőssége | Követelményeknek és szakmai előírásoknak megfelelő tervezés. |
Feladatai | Architektúra megtervezése. |
Utasításokat ad | |
Utasításokat kap | Saját munkacsoport vezető. |
Kapcsolatot tart | Saját munkacsoport vezető, munkacsoport tagok. |
Jelent | Saját munkacsoport vezető. |
Elsődleges felelőssége | Oktatások megfelelő színvonalú végzése. |
Feladatai | Kiadott oktatási feladatok elvégzése. |
Utasításokat ad | |
Utasításokat kap | Saját projektvezető, munkahelyi vezető. |
Kapcsolatot tart | Saját projektvezető, munkahelyi vezető. |
Jelent | Saját projektvezető, munkahelyi vezető. |
Elsődleges felelőssége | Dokumentációk megfelelő színvonalú elkészítése. |
Feladatai | Dokumentáció készítés. |
Utasításokat ad | |
Utasításokat kap | Saját munkacsoport vezető. |
Kapcsolatot tart | Saját munkacsoport vezető, munkacsoport tagok. |
Jelent | Saját munkacsoport vezető. |
IV. melléklet, Projekttag nyilvántartás
Megrendelő
Név | Beosztás/Szerepkör | Elérhetőség |
Xxxxx Xxxxxx Xxxxxx | Xxxxxxxxxxxxx (NISZ) | x00 00 000-0000 |
xx. Xxxx Xxxxxxxxx | Xxxxxxxxxx (MNL) | x00 00 000-0000 |
xx. Xxxxxxxx Xxxxxx | mb. Főigazgató (BFL) | x00 00 000-0000 |
Xxxx Xxxxx | Projektigazgató (NISZ) | x00 00 000-0000 |
Xxxx-Xxxxx Xxxxxx | PVB delegált (NISZ) | x00 00 000-0000 |
Xxxxxxxxx Xxxxxx | PVB delegált (MNL) | x00 00 000-0000 |
Xxxxxxx Xxxxx | PVB delegált (MNL) | x00 0 000-0000/2528 |
xx. Xxxxx Xxxxx | PVB delegált (BFL) | x00 00 000-0000 |
xx. Xxxxxxxx Xxxxxx | PVB delegált (BFL) | x00 00 000-0000 |
Xxxxx Xxxxx | Infrastruktúra alprojekt vezető | x00 00 000-0000 |
Xxxxxxx Xxxxx | Levéltár-informatikai tanácsadó | x00 00 000-0000 |
Bogó Xxxxxx | Xxxxxxxxxxxxxxxxxx | x00 00 000-0000 |
Xxxxxxx Xxxxxx | Xxxxxxxx mcs delegált (NISZ) | x00 00 000-0000 |
Xxxx Xxxxxx | Xxxxxxxx mcs delegált (NISZ) | x00 00 000-0000 |
Xxxxxx Xxxxx | MNL általános infrastruktúra delegált MNL általános mcs delegált | x00 00 000-0000 |
Xxx Xxxxxx | MNL általános infrastruktúra delegált MNL általános mcs delegált | x00 00 000-0000 |
Xxxxx Xxxxxx | MNL általános infrastruktúra delegált | x00 0 000-0000/2922 |
Für Xxxxxx | Xxxxxxxx mcs delegált (BFL) | x00 00 000-0000 |
Xxxx Xxxxxx | Számítógépes Rendszerek mcs delegált (NISZ) | x00 00 000-0000 |
Xxxxx Xxxxx | Számítógépes Rendszerek mcs delegált (NISZ) | x00 00 000-0000 |
Név | Beosztás/Szerepkör | Elérhetőség |
Xxxx Xxxxxx | Számítógépes Rendszerek mcs delegált (NISZ) Rendszermenedzsment mcs delegált (NISZ) | x00 00 000-0000 |
Xxxxxx Xxxxxx | Számítógépes Rendszerek mcs delegált (NISZ) Rendszermenedzsment mcs delegált (NISZ) | x00 00 000-0000 |
Xxxxxxxx Xxxxx | Számítógépes Rendszerek mcs delegált (BFL) Vírusvédelem mcs delegált (BFL) | x00 00 000-0000 |
Xxxxxx Xxxxxx | Hálózati megoldások mcs delegált (NISZ) | x00 00 000-0000 |
Xxxx Xxxxxx | Hálózati megoldások mcs delegált (BFL) Rendszer management mcs delegált (BFL) | x00 0 000-0000 |
Xxxx Xxxxxx | Xxxxxxxxxxxx mcs delegált (NISZ) | x00 00 000-0000 |
Xxxxxx Xxxxxx | Szabályzatok mcs delegált (NISZ) | x00 00 000-0000 |
Xxxx Xxxxxx | Szabályzatok mcs delegált (BFL) | x00 0 000-0000 |
Xxx Xxxxxx | Xxxxxxxx SDB munkacsoport vezető (MNL) Migrációs munkacsoport vezető (MNL) | x00 00 000-0000 |
Xxxxx Xxxxx | Xxxxxxxx SDB mcs tag (NML) Migrációs mcs tag (MNL) | x00 0 000-0000 |
Xxxxx Xxxxxx | Xxxxxxxx SDB mcs tag (BFL) Migrációs mcs tag (MNL) | x00 00 000-0000 |
Xxxxxxx Xxxxx | Xxxxxxxx SDB mcs tag (BFL) | x00 0 000-0000 |
Xxxx Xxxxx | Xxxxxxxx SDB mcs. tag (BFL) | x00 0 000-0000 |
Xxxxxxx X.Xxxxxx | Xxxxxxxx SDB mcs tag (BFL) | x00 0 000-0000 |
Xxxxxxx Xxxxxxx Xxxxx | Xxxxxxxx SDB mcs tag (NISZ) | x00 00 000-0000 |
Xxxxx Xxxxxx | Xxxxxxxx SDB mcs tag (NISZ) | x00 00 000-0000 |
Sarusi-Xxxx Xxxx | XxxxxXxxxxx és LNYRK munkacsoport vezető (BFL) Migrációs mcs tag (MNL) | x00 00 000-0000 |
Név | Beosztás/Szerepkör | Elérhetőség |
Xxxxxxx Xxxx | ScopeArchiv és LNYRK mcs tag (BFL) Migrációs mcs tag (MNL) | x00 0 000-0000 |
Xxxxxx Xxxxx | XxxxxXxxxxx és LNYRK mcs tag (BFL) | x00 0 000-0000 |
Xxxxxx Xxxxx | ScopeArchiv és LNYRK mcs tag (BFL) | x00 0 000-0000 |
Xxxxxxx Xxxxx | XxxxxXxxxxx és LNYRK mcs tag (BFL) | x00 0 000-0000 |
Xxxxx Xxxxx | XxxxxXxxxxx és LNYRK mcs tag (BFL) | x00 0 000-0000 |
Xxxxxx Xxxx | XxxxxXxxxxx és LNYRK mcs tag (MNL) KRI mcs tag (MNL) ELP mcs tag (MNL) | x00 0 000-0000 |
Xxxx Xxxxx | XxxxxXxxxxx és LNYRK mcs tag (MNL) KRI mcs tag (MNL) | x00 0 000-0000 |
Xxxxxx Xxxxx | XxxxxXxxxxx és LNYRK mcs tag (MNL) | x00 0 000-0000 |
Xxxxxxx Xxxxxx | XxxxxXxxxxx és LNYRK mcs tag (MNL) | x00 0 000-0000 |
Ujsághy Xxxxxxx Xxxxx | ScopeArchiv és LNYRK mcs tag (NISZ) | x00 00 000-0000 |
Xxxxx Xxxxxx | XxxxxXxxxxx és LNYRK mcs tag (NISZ) | x00 00 000-0000 |
Xxxxx Xxxxx | KRI munkacsoport vezető (NISZ) | x00 00 000-0000 |
Xxxxxx Xxxxxx | KRI mcs tag (MNL) | x00 0 000-0000/2528 |
Xxxx Xxxxxx | XXX mcs tag (BFL) | x00 0 000-0000 |
Xxxx Xxxxxx | KRI mcs tag (BFL) | x00 0 000-0000 |
Xxxxxxxxx Xxxxx | ELP munkacsoport vezető (NISZ) | x00 00 000-0000 |
Xxxxxx Xxxxxxxxxxx | ELP mcs tag (MNL) | x00 0 000-0000/2790 |
Xxxxx Xxxxx | ELP mcs tag (NISZ) | x00 00 000-0000 |
Xxxxx Xxxxx | ELP mcs tag (BFL) | x00 0 000-0000 |
Név | Beosztás/Szerepkör | Elérhetőség |
Xxxx Xxxxxx | ELP mcs tag (BFL) Migrációs mcs tag (MNL) | x00 0 000-0000 |
Név | Szerepkör | Elérhetőség |
xx. Xxxxxx Xxxxx | Xxxxxxxx minőségbiztosító (KIFÜ) | x00 00 000-0000 |
Xxxx Xxxxxx | Xxxxxxxxxxxxxxxx projektszponzora (KÜRT) | x00 00 000-0000 |
Xxxxxxxx Xxxxx | Xxxxxxxxxxxxxxxx projektvezetője (KÜRT) | x00 00 000-0000 |
Név | Szerepkör | Elérhetőség |
Xxxxxxxxxx Xxxxxx | Minőségbiztosító, szakmai koordinátor (KÜRT) | x00 00 000-0000 |
Xxxxx Xxxxx | Minőségbiztosító (KÜRT) | x00 00 000-0000 |
Xxxxxx Xxxxx | Xxxxxxxxxxxxxxxx (KÜRT) | x00 00 000-0000 |
Xxxxxxxx Xxxxx | Minőségbiztosító (KÜRT) | x00 00 000 0000 |
Xxxxxxxxxx Xxxxxx | Minőségbiztosító (KÜRT) | x00 00 000-0000 |
Vállalkozó
Név | Beosztás | Elérhetőség |
Xxxxxxxx Xxxxxx | Projekt tulajdonos | x00 00 000-0000 |
Xxxxx Xxxxx | Projekt igazgató | x00 00 000-0000 |
Xxxxxxxxx Xxxxxx Xxxx | XX vezető | x00 00 000-0000 |
Xxxxxxxxxx Xxxxxx | Projektvezető | x00 00 000-0000 xxxxxxxxxx.xxxxxx.xx@xx.xx Skype: xxxxxxxxxx.xxxxxx |
Xxxxxx Xxxxxx | Xxxxx architect Xxxxxxxxx munkacsoport vezető | x00 00 000-0000 |
Xxxxxx Xxxxx | Architect | x00 00 000-0000 |
Xx. Xxxxxx Xxxxxx | Xxxxxxxxxxxxxxxx | x00 00 000-0000 |
Név | Beosztás | Elérhetőség |
Xxxxxx Xxxxxx | Projekt adminisztráció | x00 00 000-0000 xxxxxx.xxxxxx@xx.xx Skype: kajtordani |
Xxxxxxxx Xxxxxx | Infrastruktúra alprojekt vezető | x00 00 000-0000 |
Xxxxxx Xxxxxxxx | Infrastruktúra chief architect | x00 00 000-0000 |
Xxxxx Xxxxxx | Xxxxxxxx munkacsoport vezető | x00 00 000-0000 |
Xxxxx Xxxxx | Hálózati megoldások munkacsoport vezető | x00 00 000-0000 |
Xxxxxxx Xxxxx | Számítógépes Rendszerek munkacsoport vezető | x00 00 000-0000 |
Xxxxx Xxxxx | Rendszer management munkacsoport vezető | x00 00 000-0000 |
Xxxxxx Xxxxxxxx | Xxxxxxxxxxxx munkacsoport vezető | x00 00 000-0000 |
Xxxxxx Xxxxxx | Xxxxxxxxxxxx munkacsoport vezető | x00 00 000-0000 |
Xxxx Xxxxxx | Xxxxxxxx SDB munkacsoport vezető | x00 (00) 000 0000 |
Xxxxxxx Xxxxxx | Xxxxxxxx sw. architect | x00 00 000-0000 |
Xxxxxxx Xxxxxx | scopeArchiv és LNYRK munkacsoport vezető KRI munkacsoport vezető | x00 (00) 000-0000 |
Xxxxxxxx Xxxxxx | scopeArchiv műszaki felelős, rendszertervező | x00 00 0000000 |
Zotterné Xxxxx Xxxxxxx | ELP munkacsoport vezető | x00 00 000-0000 |
Xxxxx Xxxxxxxxx | Xxxxxxxxx mcs tag | x00 00 000-0000 |
Xxxxxxxx Xxxxxx | Xx. architect, rendszerszervező | x00 00 000-0000 |
Xxxxxxxx Xxxxx | Integrációs szakértő | x00 00 000-000 |
Xxxxxxx Xxxxxx | Portál szakértő | x00 00 000 0000 |
V. melléklet, Teszt terv sablon
T-Systems Zrt Elektronikus Levéltári Rendszer
Projektazonosító: XXXXXXX
verzió: 0.1
<dátum>
Átadó T-Systems részéről | |
Átvevő Ügyfél részéről | |
Átadás dátuma | <dátum> |
Érvényesség | Visszavonásig |
Fájl neve | <file neve> |
Minősítés | Alap üzleti titok |
Dokumentumtörténet
Verzió | Dátum | Készítő | Státusz | Megjegyzés |
Jóváhagyók
T-Systems részéről | Ügyfél részéről | |
Név | ||
Beosztás | ||
Aláírás | ||
Dátum |
Szellemi tulajdonjogok
Jelen dokumentáció a T-Systems Zrt. saját szellemi tulajdona. A dokumentáció más irányú felhasználása illetve harmadik félnek történő átadása csak a T-Systems Zrt. írásos beleegyezésével történhet.
Tartalomjegyzék
<TARTALOMJEGYZÉK>
1. BEVEZETÉS
1.1 A dokumentum célja
Jelen dokumentum célja a megvalósításra kerülő rendszerek által biztosított funkcionalitások tesztelésével kapcsolatos szempontok és előfeltételek, valamint a végrehajtásra kerülő tesztesetek részletes bemutatása.
A dokumentumban foglalt információk képezik az adott rendszerkomponens(ek) modul szintű tesztelésének alapját.
1.2 A dokumentum felépítése
A tesztelési-terv tartalma a következőkre terjed ki:
• A rendszerkomponens(ek) tesztelési céljának és a teszteléshez szükséges előfeltételeknek az ismertetése,
• a rendszerkomponens(ek) teszteléskori környezetének és a teszteléshez használt eszközöknek az ismertetése,
• a rendszerkomponens(ek) megfelelő működéséhez szükséges tesztesetek ismertetése.
1.3 Hivatkozás más dokumentumokra
A rendszer tesztelési-tervének alapjául szolgáló dokumentumok az alábbi táblázatban találhatóak meg:
Dokumentum neve |
1.4 Mellékletek listája
Jelen dokumentumhoz az alábbiakban felsorolásra kerülő mellékelt állományok tartoznak:
Melléklet fájlneve | Melléklet tartalma |
2. A TESZTELÉS TERJEDELME
2.1 Tesztelés célja
3. A TESZTKÖRNYEZET ISMERTETÉSE
3.1 Általános ismertetés
A teszt helyszíne: | |
A tesztben részt vevő személyek: | Tesztelési jegyzőkönyvben megadott személyek |
A tesztelés tervezett időpontja: | Érvényben lévő ütemtervben megadott időpont |
3.2 Teszteléshez használt rendszerkomponensek
3.2.1 A tesztelés tárgyát képező rendszereszköz(ök)
A tesztelés a következő rendszerkomponensekre terjed ki:
Rendszerkomponens megnevezése | Rendszerkomponens azonosítója, ha van (rendszertervnek megfelelően) |
3.2.2 A teszteléshez szükséges rendszereszköz(ök)
A tesztelés során, a tesztesetek lebonyolításához a következő rendszerkomponensek rendelkezésre állása szükséges:
Rendszerkomponens megnevezése | Rendszerkomponens azonosítója, ha van (rendszertervnek megfelelően) |
3.2.3 A teszteléshez használt kiegészítő eszközök/alkalmazások
A tesztelés egyes részeinek lebonyolításához az alábbi kiegészítő eszközök/alkalmazások kerülnek felhasználásra:
4. Tesztek ismertetése
4.1 XXXXXXX tesztek
4.1.1 <AZONOSÍTÓ> <MEGNEVEZÉS>
Teszt ID | Teszt megnevezése |
<AZONOSÍTÓ> | <Megnevezés> |
A teszt célja: | |
A teszteléshez használat tesztadatok, azok keletkezése/forrása és elérhetősége | |
A teszt eredmény (bizonyíték) rögzítése, rögzítési módja és elérhetősége | |
4.1.2 <AZONOSÍTÓ> <MEGNEVEZÉS>
Teszt ID | Teszt megnevezése |
<AZONOSÍTÓ> | <Megnevezés> |
A teszt célja: | |
A teszteléshez használat tesztadatok, azok keletkezése/forrása és elérhetősége | |
A teszt eredmény (bizonyíték) rögzítése, rögzítési módja és elérhetősége | |
…
VI. melléklet, Teszt jegyzőkönyv
A teszt jegyzőkönyv MS Excelben készül az alábbi sablon alapján.
VII. melléklet, Heti jelentés sablon
Elektronikus levéltár szoftver és hardver elemeinek szállítása, valamint kapcsolódó szolgáltatások teljesítése
Időszak: pl. 2012. 47. hét
Mérföldkövek, intézkedések | Eredeti határidő | Jelenlegi határidő | Végzett tevékenység | Teljesítés aránya % | Megjegyzések |
Fontosabb változások a legutóbbi jelentés óta:
…
Megjegyzések/kockázatok és kezelésükre tett javaslatok:
…
A következő időszak legfontosabb feladatai:
…
kelt: hely, éééé.hh.nn.
projektvezető sk.
EMLÉKEZTETŐ - <DÁTUM>.
1. ADATLAP
Időpont | |
1.1
1.2 Dokumentumtörténet
Változat | Dátum | Módosító | Jóváhagyó | Változás |
1 | Eredeti változat | |||
2 |
1.3 Megbeszélésen felhasznált dokumentumok
Azonosító | Leírás | Átadó |
File: elev_pad_2_0_20130226.doc Oldal: 79/85
Azonosító: e-Levéltár - PAD Létrehozta: xxxxxxxxxx.jozsef.
VIII. melléklet, Emlékeztető sablon
Résztvevő neve | Cég | Megjegyzés |
File: elev_pad_2_0_20130226.doc Oldal: 80/85
Azonosító: e-Levéltár - PAD Létrehozta: xxxxxxxxxx.jozsef.
1.4 Résztvevők
2.
Megbeszélés részletei
2.1 A megbeszélés célja
A megbeszélés céljának rövid leírása.
2.2 A megbeszélés összefoglalása
A megbeszélés rövid, szabadszöveges összefoglalása.
2.3 Státusz
Csak abban az esetben kell kitölteni, ha státusmegbeszélés történt.
File: elev_pad_2_0_20130226.doc Oldal: 81/85
Azonosító: e-Levéltár - PAD Létrehozta: xxxxxxxxxx.jozsef.
3.
MEGHOZOTT DÖNTÉSEK6
Sor- szám | Döntésre bocsátott kérdés | Döntés státusz (D/H)7 | Döntés / Halasztás oka | Kapcsolódó feladatok, kockázatok |
D1 | Ide kerül annak a kérdésnek, problémának a leírása, amiben | Xxx kerül a döntés leírása. Amiben a munkacsoport | Itt kell felsorolni | |
döntést kértünk. | tagok megegyeztek a kérdéssel kapcsolatban. | azoknak a kiosztott | ||
Ha nem született döntés, akkor a döntés | feladatoknak és | |||
elhalasztásának indokát kell itt leírni. | azonosított | |||
kockázatoknak a | ||||
sorszámát, amik a | ||||
döntés | ||||
elhalasztása, vagy a | ||||
döntés miatt | ||||
keletkeztek. | ||||
Halasztás esetén | ||||
elvileg nem lehet | ||||
üres. | ||||
D2 |
6 A PAD 2.6. Előfeltételek pontjában foglaltak teljesülése esetén
7 D: Döntés. Döntés született. H: Halasztás. A döntés elhalasztva (ilyenkor a döntés határidejét is szerepeltetni kell az oszlopban).
File: elev_pad_2_0_20130226.doc Oldal: 82/85
Azonosító: e-Levéltár - PAD Létrehozta: xxxxxxxxxx.jozsef.
4.
Azonosított új kockázatok
Szám | Ha… | Akkor… | Hatás (kicsi, közepes, nagy) | Bekövetkezési valószínűség (%) | Kezelés | Megjegyzés |
K1 | ||||||
K2 | ||||||
K3 |
5. Kiosztott feladatok
Sorszám | Érintett rendszer | Feladat | Határidő | Felelős |
F1 | ||||
F2 | ||||
F3 |
File: elev_pad_2_0_20130226.doc Oldal: 83/85
Azonosító: e-Levéltár - PAD Létrehozta: xxxxxxxxxx.jozsef.
Változáskérelem <projekt rövid név / sorszám> | ||||
Projekt adatok | ||||
Projekt neve: | Projektkód: | |||
A változás kezdeményezője | ||||
Név: Szervezet: | Szervezeti egység: Beosztás: | |||
A változás státusza: | Új □ / Elemzés alatt □ / Jóváhagyott □ / Elutasított □ | |||
A változás típusa: | Korrektív akció □ / Megelőző akció □ | |||
Hatókörre Bővül □ Csökken □ Nem változik □ | Ütemezésre Hosszabbodik □ Rövidül □ Nem változik □ | Erőforrás szükségletre Növekedik □ Csökken □ Nem változik □ | Költségre Növekedik □ Csökken □ Nem változik □ | |
A változáskérelem tárgya, rövid leírása: | ||||
Változáskérelem indoklása: | ||||
A változás megvalósítása, esetleges alternatívák leírása: | ||||
A változás elmaradásának következményei: | ||||
File: elev_pad_2_0_20130226.doc Oldal: 84/85
Azonosító: e-Levéltár - PAD Létrehozta: xxxxxxxxxx.jozsef.
IX. Melléklet – Változáskérelmi lap sablon
A projekt hatókörére: A projekt ütemezésére: Szükséges erőforrásokra: A projekt költségeire: Érintett projekt leszállítandók: |
Kockázatok |
Végrehajtás esetén: Elutasítás esetén: |
Napló (a változással és jelen kérelemmel kapcsolatos események, tevékenységek fejlegyze) |
Bejegyzés Bejegyző Dátum |
Jóváhagyások (az alábbiakban aláírásommal igazolom, hogy jelen projekt változáskérelem tartalmát ismerem és azzal teljes körűen egyetértek). |
Projektvezető Dátum: Név Szerepkör (a projektben) Szervezet Aláírás Dátum |
File: elev_pad_2_0_20130226.doc Oldal: 85/85
Azonosító: e-Levéltár - PAD Létrehozta: xxxxxxxxxx.jozsef.