ADÁSVÉTELI SZERZŐDÉS VÁLLALKOZÁSI ELEMEKKEL VEGYESEN
Xx. Xxxxxx Xxxxx
Szerződés nyilvántartási száma: 1025431
ADÁSVÉTELI SZERZŐDÉS VÁLLALKOZÁSI ELEMEKKEL VEGYESEN
„A Biztonságos Kézbesítési Szolgáltatás, a Központi Azonosítási Ügynök, és az Ügyfélkapuhoz kötődő anonimizálási feladatok beszerzéséhez”
tárgyában
amely létrejött egyrészről a
NISZ Nemzeti Infokommunikációs Szolgáltató Zártkörűen Működő Részvénytársaság
Székhely: 1081 Budapest, Csokonai u. 3.
Cégjegyzékszám: Cg. 00-00-000000
Adószám: 10585560-2-44
Bankszámlaszám: K&H Bank Zrt. 10403239-00027183-00000001 Képviseli: Xxxxxxxx Xxxxxx
Képviselő titulusa: vezérigazgató mint Vevő, a továbbiakban: Vevő
másrészről a(z)
Név:BI-Tech Informatika Korlátolt Felelősségű Társaság Xxxxxxxx0000 Xxxxxxxx, Xxxxxx xxxx 0.
Cégjegyzékszám01-09-865385 Adószám:13633473-2-42
Bankszámlaszám:11714006-25992405 Képviseli:xx. Xxxxxx Xxxxx
Név: Traco Zrt.
Székhely: 0000 Xxxxxxxx, Xxxxxxxx xxxx 0 xxxxxxxxxx 0.
Cégjegyzékszám: 00-00-000000
Adószám: 11856403-2-42
Képviseli: Xxxxxx Xxxxxx
Név: Digitran Hungária Digitális Transzformáció Zrt. Székhely: 0000 Xxxxxxxx, Xxxxxx xxxx 0/X Xxxxxxxxxxxxxx: 00-00-000000
Adószám: 26196413-2-41
Képviseli: Xxxxxx Xxxxx
Név: Spirity Enterprise Zrt.
Székhely: 0000 Xxxxxxxx, Xxxxxxx xxxxxxxxxxxxxxx xxxx 0-00 Xxxxxxxxxxxxxx: 00-00-000000
Adószám: 26633710-2-43
Képviseli: Xxxxxxxx Xxx
Név: IT_CM Kereskedelmi és Szolgáltató Kft. Székhely: 0000 Xxxxxxxx, Xxxxxxx xxxx 0.
Xx. Xxxxxx Xxxxxx
Digitálisan aláírta: Xx. Xxxxxx Xxxxxx Xxxxx
dr. Burján
Digitálisan aláírta: xx. Xxxxxx Xxx Xxxxxx
1. Xxxxx
Dátum: 2022.04.28
13:25:57 +02'00'
Xxx Xxxxxx Xxxxx: 2022.04.28
13:18:17 +02'00'
Cégjegyzékszám: 00-00-000000
Adószám: 12038208-2-43
Képviseli: Xxxxxxxxx Xxxxx
Név: UniOffice Rendszerház Kft Székhely: 0000 Xxxxxxxx, Xxxxx xxxx 0
Cégjegyzékszám: 00-00-000000 Adószám:10748743-2-43
Képviseli: Xxxxxx Xxxxxx
mint Eladó1, (a továbbiakban együtt: Xxxxx)
között (Vevő és Xxxxx továbbiakban együtt: Felek) alulírott helyen és napon az alábbi feltételekkel.
Preambulum
Felek rögzítik, hogy a Digitális Kormányzati Ügynökség Zártkörűen Működő Részvénytársaság, (a továbbiakban: Beszerző) által EKR000814292020 szám alatt, a központosított közbeszerzés hatálya alá tartozó Érintett Szervezetek részére a közbeszerzésekről szóló 2015. évi CXLIII. törvény (a továbbiakban: Kbt.) és a Nemzeti Hírközlési és Informatikai Tanácsról, valamint a Digitális Kormányzati Ügynökség Zártkörűen Működő Részvénytársaság és a kormányzati informatikai beszerzések központosított közbeszerzési rendszeréről szóló 301/2018. (XII. 27.) Korm. rendelet alapján
„Meglévő IBM szoftverlicencek bővítése (ILIC20)” tárgyban lefolytatott keretmegállapodás megkötésére irányuló eljárás első része eredményeképpen a Beszerző és Eladó között keretmegállapodás jött létre (a továbbiakban: KM).
KM azonosítószáma: DKM01ILIC20 KM aláírásának dátuma: 2021. május 11.
KM időbeli hatálya: 2023. május 12.
KM nettó értéke: 7.929.000.000 forint + Áfa.
Jelen szerződést Eladó, mint a közbeszerzési eljárásban közös ajánlatot benyújtó ajánlattevő közösen teljesíti. Eladó egymás közti, illetve a Vevő közti viszonyát a jelen szerződés és az Eladó együttműködési megállapodása tartalmazza. A jelen szerződés aláírója Xxxxx nevében jelen szerződést – meghatalmazás alapján – az összes közös ajánlattevő nevében írja alá.2
Eladó (mint a közbeszerzési eljárás közös ajánlattevői) kijelenti, hogy jelen szerződésből eredő kötelezettség teljesítéséért egyetemleges felelősséget vállal.3
Eladó, jelen szerződés aláírásával kinyilvánítja, hogy ismeri és a szerződés teljesítése során figyelembe veszi, elfogadja és betartja a jelen szerződés tárgyát, annak megvalósítását érintő valamennyi jogszabályt, az egyébként rá vonatkozó etikai normákat.
1. A szerződés tárgya, mennyisége
1 A keretmegállapodásos eljárás első részében közös ajánlatot tevő ajánlattevők közösen kötelesek szerződést kötni. A szöveg a közös ajánlattevők száma szerint bővítendő.
2 A szerződés véglegesítése során kerül véglegesítésre vagy törlésre
3 Közös ajánlattétel esetén
1.1. A jelen szerződés a keretmegállapodásos eljárás 2. része eredményeképpen a Vevő – hivatkozott KM tárgyát képező termékekre (árukra és szolgáltatásokra) vonatkozó -
„A Biztonságos Kézbesítési Szolgáltatás, a Központi Azonosítási Ügynök, és az Ügyfélkapuhoz kötődő anonimizálási feladatok beszerzéséhez” tárgyú beszerzési igénye megvalósítására jött létre. A jelen szerződés alapján Vevő megrendeli, Xxxxx pedig elvállalja jelen szerződés 1. számú mellékletében nevesített termékek (áruk és szolgáltatások) biztosítását. Jelen szerződés teljesítése során Xxxxx által nyújtandó szolgáltatások részletezését jelen szerződés 2. számú melléklete (műszaki leírás) tartalmazza. Eladó elvállalja az alábbi szolgáltatások (feladatok) ellátását:
a) Eladónak be kell tanítania a Vevő fejlesztési és üzemeltetési területének munkatársait az IBM InfoSphere Optim Tesztadatkezelő megoldás használatára és működtetésére egy gyakorlati pilotprojekt során (továbbiakban: Oktatási feladat),
b) Eladónak az éles üzemben lévő rendszerek tekintetében végre kell hajtania az anonimizáláshoz kötődő IBM InfoSphere Optim Tesztadatkezelő paraméterezési és oktatási feladatokat, illetve le kell szállítani az elvárt dokumentációkat (továbbiakban: Paraméterezési feladat),
c) támogatási erőforrás biztosítása (továbbiakban: opciós szakértői óra/ felhasználói támogatás)
1.2. Az 1.1 pontban meghatározott szolgáltatásokat Eladónak jelen szerződésben (ideértve jelen szerződés 2. számú mellékletét is) meghatározottak szerint kell teljesítenie.
1.3. Vevő az 1.1 c) pontban meghatározott feladat teljesítésére 2022. 12. 31. napjáig jogosult egyedi megrendeléseket kibocsátani.
1.4. Jelen szerződés 1.1. c) pontjában meghatározott opciós szakértői órát Vevő nem köteles teljes mértékben lehívni. Eladó jelen pontban foglaltakat elfogadja és kijelenti, hogy Vevővel szemben semmilyen jogcímen kártérítési igényt nem érvényesít arra az esetre, ha Vevő az 1.1 c) pontban meghatározott opciót nem vagy nem teljesen használja fel az előzőekben meghatározott időpont lejártáig. Vevő az opció rendelkezésre tartásáért külön díjat nem fizet.
1.5. A jelen szerződésben meghatározott teljesítést és számlakiállítást a(z) BI-Tech Informatika Kft.(székhely:0000 Xxxxxxxx, Xxxxxx xxxx 0. ) teljesíti.4
2. A teljesítés határideje, a szerződés hatálybalépése
2.1. Jelen szerződés a Xxxxx által történő kölcsönös aláírás napján lép hatályba. Amennyiben az aláírások nem ugyanazon a napon történnek, a hatályba lépés időpontja a legutolsó aláírás napja.
2.2. Teljesítési határidők:
2.2.1. Jelen szerződés 1.1. a) és b) pontjába foglalt feladatok (Oktatási és Paraméte- rezési feladat) teljesítési határideje:
4 a szerződés véglegesítésekor kerül kitöltésre
sorszám | Megnevezés | Eredmény Termék | Teljesítési ütem | Teljesí- tés mér- téke (%) |
1. rész- fel- adat | Pilot fázis: Oktatás, Telepítés támoga- tás, gyakorlati pilot projekt | Oktatás megtörténik, a rend- szerek telepítésre kerülnek, a pilot projekt sikeresen zárul. Oktatási dokumentációk. | 2022.05.30.5 | 25 |
2. rész- fel- adat | Koncepcionális tervezés, Paramétere- zések, Paraméterezések átadása Teszt- re | Koncepcionális terv elfoga- dása: Logikai és fizikai tervek Tesztfázis indulása: Telepí- tési, üzemeltetési, tesztelési dokumentációk. | 2022.10.25.6 | 40 |
3. rész- fel- adat | Éles telepítés, próbaüzem Projekt zá- rása | Projektzárás: minden követel- ményt teljesít, köztük azt is, hogy megfelelő idő alatt lefut a teljes anonimizálás. Rend- szerbiztonsági terv, Oktatási dokumentációk, próbaüzem alatti változásokból adódóan minden érintett dokumentáció aktualizálása, frissítése. | 2022.11.30. | 35 |
2.2.2. Szerződő Felek megállapodnak, hogy a 2.2.1. pontban meghatározott határidők
– a végteljesítési határidő kivételével – nem fix határidők, azok módosításához elegendő Felek jelen szerződés 17.1 pontjában meghatározott kapcsolattartói- nak megállapodása.
2.3. Xxxxx jelen szerződést határozott időre kötik. Jelen szerződés megszűnik, ha jelen szerződésben meghatározott feladatait Felek mindegyike teljesíti.
3. A teljesítés helye
3.1. A szolgáltatások teljesítése ún. távoli munkavégzés keretein belül valósul meg, amihez a szükséges mértékű jogosultságokat a szolgáltatások elvégzéséhez Vevő biztosítja Xxxxx részére jelen szerződés hatálybalépésétől számított 10 napon belül.
3.2. Helyszíni támogatás esetén a teljesítés helye: Vevő budapesti telephelyeinek egyike
3.3. Papír alapú és CD- lévő dokumentum(ok) átadásának helye: 1135 Budapest, Csata u. 8.
3.4. Az elektronikus dokumentum(ok) átadásának helye: xxxxxxx.xxxxxx@xxxx.xx, valamint a szerződésben megjelölt kapcsolattartó email címe.
5 a szerződés véglegesítésekor a nyertes ajánlat alapján kerül kitöltésre
6 a szerződés véglegesítésekor a nyertes ajánlat alapján kerül kitöltésre
4. Oktatási feladat (1. részfeladat) teljesítésével kapcsolatos előírások
4.1. Eladó a jelen szerződés teljesítése során köteles Vevő kijelölt szakembereit (kulcsfel- használók és üzemeltetők) oktatásban részesíteni. Az oktatást magyar nyelven kell megtartani.
4.2. Eladó köteles az oktatás időpontja előtt 10 nappal Vevő részére e-mailben megküldeni az oktatási tervet, amelyet a jelen szerződés 2. számú mellékletében meghatározottakra tekintettel kell összeállítani.
4.3. Az oktatási tervet Vevő 5 napon belül véleményezi és annak elfogadásáról elfogadó nyilatkozatot állít ki. Az oktatás megkezdésének feltétele az oktatási terv Vevő általi jóváhagyása.
4.4. Eladó minden oktatás megkezdése előtt az oktatásban részesítendő szakemberek szá- mára az elhangzottak követésére alkalmas oktatási segédanyagot ad át. Vevő oktatás- ban részesített szakemberei az oktatáson való részvételüket jelenléti ív aláírásával iga- zolják.
4.5. Az oktatáshoz szükséges technikai feltételeket Vevő biztosítja. Eladó az oktatást jogo- sult távoktatás/online oktatás útján megtartani, melyről Felek az oktatás megkezdését megelőzően egyeztetnek.
4.6. Eladó a legutolsó oktatás befejezését követő 5 napon belül köteles Vevőnek átadni:
a) az oktatási terv elfogadásáról kiállított elfogadó nyilatkozatot,
b) az oktatásokon felvett jelenléti íveket
c) oktatási jegyzőkönyvet.
4.7. Vevő a 4.6. pont szerinti dokumentumok átvételét követő 10 napon belül kiállítja az Oktatási feladat teljesítésére vonatkozó Teljesítést Igazoló Bizonylatot (továbbiakban: TIB).
4.8. A TIB mintáját jelen szerződés 3. számú melléklete tartalmazza. Vevő TIB kiállítását mindaddig megtagadhatja, amíg Eladó annak kiállításához szükséges valamennyi do- kumentumot nem vagy nem teljes körűen adja át.
5. Paraméterezési feladat (2. és 3. részfeladat) teljesítésével kapcsolatos általános előírások
5.1. A Paraméterezési feladat keretében elkészítendő eredménytermékeket (paraméterezés, dokumentumok) Vevő – az oktatás kivételével – átadás-átvételi eljárás keretében veszi át.
5.2. Az átadás-átvételéről minden esetben átadás-átvételi jegyzőkönyvet kell felvenni, melyben legalább az alábbi adatokat kell rögzíteni:
- átadás-átvételi eljárás helye, ideje,
- Felek jelen lévő képviselőinek neve, beosztása,
- átvétellel érintett termék legfontosabb adatai (név, típus, release- és verziószám, példányszám (dokumentum esetében)),
- átadás-átvételi eljárás legfontosabb eseményei,
- Felek képviselői által rögzíteni kívánt adatok, tények,
- átadás-átvételi eljárás során észlelt hibák felsorolása, Xxxxx képviselőinek a hibákkal kapcsolatos észrevételei, hibajavítással kapcsolatos Vevői elvárások meghatározása,
- Vevő kifejezett nyilatkozata, hogy a terméket/szolgáltatást átveszi-e vagy sem,
- az átvétel megtagadása esetén az átvétel megtagadásának az indoka, valamint a megismételt átadás-átvételi eljárás időpontja,
- Felek képviselőinek aláírása.
5.3. Vevő az átadás-átvétel során jogosult a Ptk. 6:127. § (2) bekezdésében biztosított jo- gával élni, mely alapján nem köteles vizsgálni azokat a tulajdonságokat, amelyek mi- nőségét tanúsítják, vagy amelyekre a jótállás kiterjed.
5.4. Bármely nem szerződésszerű teljesítés jogi fenntartás nélküli elfogadása Vevő részéről nem értelmezhető joglemondásként azon igényekről, amelyek Vevőt a szerződéssze- gés következményeként megilletik.
5.5. Felek kijelentik, hogy az átadás-átvétel szabályait közösen, a jóhiszeműség és a tisz- tesség követelményének figyelembevételével állapították meg.
5.6. 2. részfeladat teljesítésével kapcsolatos előírások
5.6.1. Eladónak a 2. részfeladat teljesítése során a jelen szerződés 2. számú mellékletében meghatározott dokumentumokat kell elkészítenie. A dokumentumokkal kapcsolatos tartalmi és formai követelményeket jelen szerződés 2. számú melléklete tartalmazza.
5.6.2. A 2. részfeladat teljesítése során elkészítendő dokumentumok (3.3. és 3.4. szerinti) átadás-átvétele megkezdhetőségének feltétele, hogy a dokumentum feleljen meg a jelen szerződés 2. számú mellékletében meghatározott formai követelményeknek. Amennyiben az átadott dokumentum megfelel jelen szerződés 2. számú mellékletében meghatározott formai követelményeknek, Vevő a dokumentum átvételéről átvételi elismervényt állít ki.
5.6.3. A dokumentum átadás-átvétele során Vevő azt vizsgálja, hogy az átvett dokumentum megfelel-e az adott dokumentummal szemben jelen szerződés 2. számú mellékletében meghatározott tartalmi követelményeknek.
5.6.4. Az átvett dokumentumot Vevő 15 napon belül véleményezi és amennyiben az nem felel meg a jelen szerződés 2. számú mellékletében meghatározott tartalmi követelményeknek 10 napon belüli javítását kéri. Vevő adott dokumentum elfogadását mindaddig megtagadhatja, amíg az nem felel meg a vele szemben meghatározott tartalmi követelményeknek.
5.6.5. Dokumentumok véleményezése esetén az átadás-átvételi jegyzőkönyvben az átadás- átvételi eljárás új időpontja helyett a javított dokumentum átadásának időpontját kell rögzíteni. A javított dokumentum véleményezésére a jelen pont rendelkezéseit kell megfelelően alkalmazni.
5.7. 3. részfeladat teljesítésével kapcsolatos előírások
5.7.1. Jelen szerződés keretében kifejezetten Vevő számára felparaméterezett IBM
InfoSphere Optim Tesztadatkezelő átadás-átvétele az alább felsorolt lépésekben történik:
- Tesztelés
- Éles telepítés
- Próbaüzem
- Éles bevezetés
5.7.2. Tesztelés
5.7.2.1. A tesztelés során a jelen szerződés 2. számú mellékletében meghatározott teszteket kell lefolytatni.
5.7.2.2. A tesztelés megkezdésének feltétele adott teszteléshez tartozó, jelen szerződés 2. számú melléklete szerinti tesztelési dokumentum(ok) Vevő általi elfogadása.
5.7.2.3. Eladó köteles a tesztelés során minden szükséges tájékoztatást megadni a felparaméterezett IBM InfoSphere Optim Tesztadatkezelő alkalmazással és annak működésével kapcsolatban, illetve Vevő erre vonatkozó igénye esetén helyszíni támogatást nyújtani.
5.7.2.4. A tesztelés akkor tekinthető sikeresnek, ha az 5.7.2.5 pontban meghatározott esetek egyike sem merül fel. A tesztek során felmerülő hibákat Felek tesztjegyzőkönyvben rögzítik. Egyebekben a tesztjegyzőkönyvben legalább az alábbiakat kell rögzíteni:
a) a tesztelés helye, valamint kezdő időpontja,
b) Felek jelen lévő képviselőinek neve és beosztása,
c) a tesztjegyzőkönyv tartalmi követelményeként előírtak
d) a tesztelés során történt lényeges események leírása,
e) a tesztelés során bekövetkezett hibajelenségek leírása, hiba kategóriába sorolása és ki- javításukkal kapcsolatos előírások és azok határideje,
f) Feleknek az esetleges hibákkal kapcsolatos álláspontja,
g) Vevő kifejezett nyilatkozata arra vonatkozóan, hogy a tesztelés sikeres volt-e,
h) Felek jelen lévő képviselőinek aláírása.
5.7.2.5. Sikertelen a tesztelés, ha:
a) a tesztelés során kritikus vagy súlyos hiba merült fel,
b) Xxxxx nem javított ki a tesztelés során felmerült minden hibát és/vagy nem oldott meg a teljesítménnyel kapcsolatos minden problémát,
c) valamely a paraméterezésre vonatkozó Vevő által jóváhagyott specifikációban és/vagy részletes rendszertervben meghatározott funkció hiányzik,
d) a rendszer korábbi funkcióinak és riportjainak működése és eredményei nem vagy nem rendeltetésszerűen működnek,
e) a paraméterezés használhatatlan, működésképtelen.
5.7.2.6. Amennyiben a teszt sikertelen, ezt a teszt-jegyzőkönyvben kell rögzíteni. Sikertelen teszt esetén a felmerült hibák, hiányosságok javítását Eladó köteles azonnal megkezdeni, s ezzel egyidejűleg a Felek a hibajavításra ésszerű póthatáridőt tűznek ki, melyet az átadás-átvételi jegyzőkönyvben rögzíteni kell. A kijavítást követően a Felek
ismételt tesztet tartanak. Amennyiben az ismételt teszt is sikertelen Vevő választása szerint:
a) jogosult további javítást kérni vagy
b) a meghiúsulás jelen szerződés 13. pontjában meghatározott jogkövetkezményeinek al- kalmazása mellett a szerződéstől elállni, vagy azt azonnali hatállyal felmondani.
5.7.2.7. A tesztelések során feltárt hibák – a hiba jellege alapján – a Műszaki leírás szerint a következő hibaosztályokba sorolandóak:
a) kritikus,
b) súlyos,
c) alacsony szintű.
5.7.2.8. A hibák kategorizálását a Vevő tesztelési felelősei végzik. Amennyiben Xxxxx a Vevő valamely hiba kategorizálására vonatkozó döntésével nem ért egyet, észrevételét köteles a tesztelési jegyzőkönyvben rögzíteni és Feleknek a kérdésről egyeztetést kell tartaniuk.
5.7.2.9. Eladó köteles a tesztelések során az IBM InfoSphere Optim Tesztadatkezelő paraméterezésében végrehajtott módosításokkal összhangban a szükséges módosításokat a vonatkozó dokumentációkban átvezetni. A módosított dokumentációk átadás-átvételére a 5.6. pont rendelkezéseit kell alkalmazni.
5.7.3. Éles telepítés
5.7.3.1. A telepítés kizárólag az NISZ üzemeltetés által végezhető az Eladói doku- mentációk alapján.
5.7.3.2. A tesztkörnyezetben sikeresen telepített verzió éles telepítésre átadásának kö- vetelménye az adott verzióhoz tartozó telepítő készlet és kód egy csomagba foglalása. Szükséges továbbá csatolni a tesztkörnyezetben végzett tesztek tesztjegyzőkönyveit is, melyek bizonyítják, hogy adott verzió nem tartalmaz olyan hibát, ami akadályozná az éles telepítést.
5.7.3.3. A verzióhoz kiadott csomagban együtt kell átadni az adott verzióhoz tartozó kódot, konfigurációs fájlokat, build scripteket, telepítési és üzemeltetési dokumentá- ciót, valamint a telepítendő állományokat. A telepítési dokumentumnak többek között tartalmaznia kell azt is, hogy milyen funkcionalitás tesztelésével lehet ellenőrizni a telepítés sikerességét. Amennyiben ez az ellenőrzés hiba nélkül megtörténik, akkor a telepítés sikeresnek tekinthető. Sikertelen telepítés esetére a visszaállítás lépéseinek leírását is tartalmaznia kell a telepítési leírásnak.
5.7.4. Próbaüzem
5.7.4.1. A rendszer próbaüzemét Vevő szakemberei végzik Eladó szakembereinek tá- mogatása mellett.
5.7.4.2. A rendszer éles bevezetésére akkor kerülhet sor, ha a rendszer egészére vo- natkozó próbaüzem (élesre való telepítés utáni működés ellenőrzés, annak
megfelelőségének vizsgálata a követelmények alapján) sikeresen lezárul. A próba- üzem alatt a rendszernek a műszaki specifikációban található összes követelményt tel- jesítenie kell, köztük azt is, hogy megfelelő idő alatt lefut a teljes anonimizálási folya- mat. Tehát a funkcionális ellenőrzésen túl a performancia is ellenőrzésre kerül. Az ellenőrzés eredményeiről tesztjegyzőkönyv kerül kiálltásra.
5.7.4.3. A próbaüzem alatt az üzemeltetési terület elemzi a monitoring rendszerbe be- kötött hardver- és szoftverelemek működését, erőforrás kihasználtságát, továbbá vizs- gálja az IBM InfoSphere Optim Tesztadatkezelő éles alkalmazás logok-at. Ennek ered- ményéről szintén tájékoztatásra kerül az Eladó. Amennyiben valamelyik erőforrás ese- tében szűk keresztmetszet látszik, akkor az Eladónak meg kell vizsgálnia, hogy az adott ponton a paraméterezés optimalizálásával elkerülhető-e a túlzott erőforráshasz- nálat. Amennyiben a paraméterezés optimalizációjával a szűk keresztmetszet orvosol- ható, akkor új verzió kiadása szükséges, melyet újabb próbaüzem futtatás követ majd.
5.7.4.4. A próbaüzem alatti esetleges változásokból adódóan minden érintett doku- mentáció aktualizálása, frissítése szükséges.
5.7.5. Éles bevezetés
5.7.5.1. A rendszer éles bevezetését Vevő szakemberei végzik Xxxxx szakembereinek támogatása mellett.
5.7.5.2. A rendszer éles bevezetésére akkor kerülhet sor, ha a rendszer egészére vo- natkozó próbaüzem fázis sikeresen lezárul, a paraméterezés megfelelő funkcionalitás- sal, és stabil működéssel bír. Az éles bevezetéshez szükséges az összes dokumentáció aktualizálása, frissítése és Vevő oldali elfogadása.
5.8. Eladónak a 3. részfeladat teljesítése során a jelen szerződés 2. számú mellékletében meghatározott dokumentumokat kell elkészítenie. A dokumentumokkal kapcsolatos tartalmi és formai követelményeket jelen szerződés 2. számú melléklete tartalmazza.
A dokumentumok átadás-átvételére során jelen szerződés 5.6. pontjának rendelkezéseit kell megfelelően alkalmazni.
5.9. A 3. részfeladat keretében tartandó oktatásra jelen szerződés 4. fejezetének rendelkezéseit kell megfelelően alkalmazni.
6. Támogatási erőforrás biztosítása
6.1. Eladó a jelen szerződés 2. számú mellékletében meghatározott órakeret terhére fel- használói támogatás keretében munkanapokon 8:00-17:00 óra között telefonon illetve e-mail-en hozzáférési lehetőséget biztosít a szakértőihez, akik segítenek a rendszer működése során felmerülő kérdések, hibának nem minősülő problémák megoldásá- ban.
6.2. Vevő felhasználói támogatásra vonatkozó igényét Eladó alábbi elérhetőségein jelent- heti be:
- E-mail cím: xxxx_xxxxxxx@xx-xxxx.xx
- Telefonszám: x0000000000
6.3. A felhasználói támogatásra vonatkozó igénybejelentésben (egyedi megrendelés) a leg- alább az alábbi adatokat kell megadni:
- azon helyszínt és időpont, ahol Xxxxxxxx meg kell jelennie (személyes megjelenést igénylő feladat esetén) vagy a feladat teljesítésének a határideje,
- egyeztetés tárgyának vagy az Xxxxx által ellátandó feladatnak a meghatározása,
- a feladat teljesítésének helye.
6.4. Személyes megjelenésre vonatkozó igény esetén a 6.2 pont szerinti igénybejelentést legalább 2 munkanappal korábban meg kell küldeni Eladó részére. Személyes megje- lenést igénylő feladat esetében az igénybejelentést olyan részletezettséggel kell meg- adni, amely lehetővé teszi, hogy Eladó a megfelelő szakértelemmel rendelkező szak- embere jelenlétét biztosítsa.
6.5. Eladó a Teljesítést Igazoló Bizonylat kiállítása érdekében köteles átadni Vevőnek a felhasználói támogatás keretében teljesített feladatairól készített kimutatást. A felhasz- nálói támogatás keretében teljesített feladatokról készített kimutatásban legalább az alábbi adatokat kell szerepeltetni:
- a tárgyhónapban felhasználói támogatás keretében elvégzett feladatok (ideértve az egyeztetéseken, megbeszéléseken való részvételt is) és feladatonként a feladatra for- dított idő (óra)
6.6. Vevő a 6.5 pont szerinti dokumentumok átvételét követő 15 napon belül kiállítja a felhasználói támogatás teljesítésére vonatkozó Teljesítést Igazoló Bizonylatot. Amennyiben az átadott kimutatással kapcsolatban Vevőnek észrevétele van, Felek a Teljesítést Igazoló Bizonylat kiállítására rendelkezésre álló határidőn belül egyeztetést tartanak.
6.7. Vevő a felhasználói támogatásra vonatkozó Teljesítést Igazoló Bizonylat kiállítását mindaddig megtagadhatja, amíg Eladónak kiállításához szükséges 6.5 pont szerinti do- kumentumokat nem vagy nem teljes körűen adja át.
7. Teljesítésigazolás
7.1. 1. részfeladatra vonatkozó teljesítésigazolás
Jelen szerződés 4.7. – 4.8. pontjában meghatározottak szerint.
7.2. 2. részfeladatra vonatkozó teljesítésigazolás
7.2.1. Eladó a 2. részfeladathoz tartozó feladatait teljesíti, ha a jelen szerződés 2. számú mel- lékletében meghatározott 2. részfeladathoz tartozó dokumentumokat Vevő átvette.
7.2.2. Eladó a 2. részfeladat teljesítését követő 5 napon belül köteles Vevőnek átadni a do- kumentumok átvételét igazoló átadás-átvételi jegyzőkönyvek egy példányát. Vevő az előzőekben meghatározott dokumentumok átvételét követő 15 napon belül kiállítja a Teljesítést Igazoló Bizonylatot.
7.2.3. Vevő TIB kiállítását mindaddig megtagadhatja, amíg Xxxxx annak kiállításához szük- séges valamennyi dokumentumot nem vagy nem teljes körűen adja át.
7.3. 3. részfeladatra vonatkozó teljesítésigazolás
7.3.1. Eladó a 3. részfeladathoz tartozó feladatait teljesíti, ha az eredménytermékek átadás- átvétele sikeresen lezárult (azokat Vevő átvette), Xxxxx az elkészített paraméterezést átadta és Xxxxx az oktatást megtartotta.
7.3.2. Eladó a 3. részfeladat teljesítését követő 5 napon belül köteles Vevőnek átadni:
a) az eredménytermékek átvételét igazoló átadás-átvételi jegyzőkönyvek egy példányát,
b) az oktatás(ok) oktatási tervének elfogadását igazoló vevői nyilatkozatok(ok) egy példányát valamint az oktatás(ok)on felvett jelenléti ív(ek) egy-egy példányát,
7.3.3. Vevő ezen dokumentumok átvételét követő 10 napon belül kiállítja a Teljesítést Igazoló Bizonylatot.
7.3.4. Vevő TIB kiállítását mindaddig megtagadhatja, amíg Eladó annak kiállításához szükséges valamennyi dokumentumot nem vagy nem teljes körűen adja át.
7.4. Támogatási erőforrás biztosítására vonatkozó teljesítésigazolás
Jelen szerződés 6.6.- 6.7. pontjában meghatározottak szerint.
8. Eladó jogai és kötelezettségei
8.1. Eladó jelen szerződésben meghatározott feladatait magyar nyelven köteles teljesíteni.
8.2. Eladó kijelenti, hogy rendelkezik jelen szerződésben meghatározott feladatok teljesítéséhez szükséges engedélyekkel, jogosultságokkal.
8.3. Eladó felelős az általa nyújtott tevékenység minőségi megfelelőségéért, szakszerűségéért, szerződésszerűségéért és teljes körűségéért. Eladó köteles a szerződés szerinti kötelezettségeit a tőle elvárható legnagyobb gondossággal, magas színvonalon teljesíteni.
8.4. Eladó jelen szerződésben meghatározott feladatait Vevő utasításai szerint és érdekeinek érvényesítésével, megóvásával, a Vevővel történő folyamatos egyeztetés mellett köteles ellátni. Eladó köteles minden olyan egyeztetésen, megbeszélésen részt venni, melyen Vevő a jelenlétét igényli.
8.5. Eladó köteles Vevőt haladéktalanul figyelmeztetni abban az esetben, ha a Vevő célszerűtlen vagy szakszerűtlen utasítást ad. A figyelmeztetés elmulasztásából eredő kárért Xxxxx felelős.
8.6. Amennyiben Vevő elmulasztja valamely jelen szerződésben meghatározott kötelezettsége teljesítését, Eladó köteles tájékoztatni Vevőt a mulasztásnak a munkára
gyakorolt előrelátható hatásairól. Vevő késedelme az Eladó egyidejű késedelmét kizárja.
8.7. Eladó jelen szerződés teljesítéséhez szükséges szakképzett munkaerőt a szerződés időtartama alatt köteles biztosítani.
8.8. Eladó jelen szerződésben meghatározott feladatai teljesítéséhez a keretmegállapodásos közbeszerzési eljárás első részében benyújtott ajánlatában megnevezett alvállalkozókat veheti igénybe a Kbt. 138. §-ban meghatározottak szerint.
8.9. Amennyiben jelen szerződés teljesítése során további szakemberek, alvállalkozók bevonása válik szükségessé (ideértve azt az esetet, amikor Xxxxx (mint ajánlattevő) alkalmasságának igazolásában részt vett szakember, alvállalkozó helyett szükséges más személy vagy alvállalkozó bevonása), akkor ezen személy/alvállalkozó bevonásakor a Kbt. 138. § (2) - (4) bekezdéseiben foglaltak szerint kell eljárni, valamint a KM vonatkozó rendelkezéseit kell alkalmazni.
8.10. Eladó felelősséget vállal, hogy a jelen szerződés teljesítésébe általa bevont személyekkel, alvállalkozókkal munkájuk, hozzájárulásuk arányában elszámol. Vevőt fizetési kötelezettség – jelen szerződésben szabályozottak szerint – kizárólag Eladó irányába terheli.
8.11. Eladó a teljesítés során jogosan igénybevett alvállalkozóért, egyéb közreműködőért úgy felel, mintha maga járt volna el. Eladó, ha jelen szerződésben, valamint a KM-ben szabályozottak megsértésével von be alvállalkozót jelen szerződés teljesítésébe, felelős azokért a károkért is, amelyek e személy, szervezet igénybevétele nélkül nem következtek volna be.
8.12. Eladó köteles jelen szerződés hatálya alatt tulajdonosi szerkezetét Vevő számára meg- ismerhetővé tenni és a Kbt. 143. § (3) bekezdés szerinti ügyletekről Vevőt haladékta- lanul értesíteni.
8.13. Eladó jelen szerződés aláírásáig átadta Xxxxxxx a kitöltött Xxxxxxxxxxx Partner adata- iról dokumentumot, amely jelen szerződés 5. számú mellékletében található.
9. Vevő jogai és kötelezettsége
9.1. Vevő köteles biztosítani Xxxxx szakembereinek a teljesítés helyén történő munkavégzést a teljesítéshez szükséges mértékig és időtartamban. Vevő köteles biztosítani Xxxxx jelen szerződés teljesítésében közreműködő szakemberei részére a teljesítés helyére történő belépést és az ott történő munkavégzést.
9.2. Vevő biztosítja az Eladónak a rendszerhez történő indokolt, szükséges és elégséges mértékű zavartalan hozzáférést.
9.3. Ahhoz, hogy Xxxxx jelen szerződésben meghatározott feladatait teljesíthesse, Vevő
Eladó részére szükséges kapacitású és sávszélességű távoli hozzáférést, Vevő informatikai környezetébe belépési lehetőséget biztosít (távoli hozzáférés).
9.4. Vevő előzetes egyeztetést követően biztosítja Xxxxx szakemberei számára a munkaidőn túli valamint a hétvégén történő munkavégzést.
9.5. Vevő köteles Xxxxx rendelkezésére bocsátani minden olyan információt, adatot és dokumentumot, amely Eladó tevékenységének szakszerű és körültekintő ellátásához szükséges. Vita esetén Felek dokumentáltan, igazolható módon kötelesek rögzíteni azon adatoknak és információknak a körét, amelyek minimálisan szükségesek ahhoz, hogy Eladó szerződésszerűen tudjon teljesíteni.
9.6. Bármely nem szerződésszerű teljesítés jogi fenntartás nélküli elfogadása Vevő részéről nem értelmezhető joglemondásként azon igényekről, amelyek Vevőt a szerződésszegés következményeként megilletik.
10. A fizetendő ellenérték
10.1. Eladót a szerződésszerű teljesítés ellenértékeként, a teljesítésigazolással igazolt, elvégzett feladatok után, az alábbi táblázat szerint illeti meg ellenszolgáltatás:
Feladat megneve- zése | Teljesítés mértéke (%) | Nettó díj (Ft) |
1. részfeladat | 25 | 12 524 000 |
2. részfeladat | 40 | 19 941 000 |
3. részfeladat | 35 | 17 451 000 |
Mindösszesen | 100 | 49 916 000 |
10.2. A jelen szerződés keretében nyújtott opciós szakértői óra díja 16.500.-Ft/óra + beszerzési díj + szoftverlicenc-gazdálkodási díj + áfa, azaz Tizenhatezer-ötszáz forint/óra + beszerzési díj + szoftverlicenc-gazdálkodási díj + általános forgalmi adó.
Az opciós szakértői óra értéke 1.650.000.-7 Ft + beszerzési díj + szoftverlicenc- gazdálkodási díj + áfa, azaz Egymillió-hatszázötvenezer forint + beszerzési díj szoftverlicenc-gazdálkodási díj + általános forgalmi adó.
10.3. Felek rögzítik, hogy az általános forgalmi adó mértékére és megfizetésének módjára a mindenkori hatályos jogszabályi rendelkezések az irányadóak.
10.4. A 10.1 és 10.2. pont szerinti szerződéses ár tartalmazza a megajánlott szolgáltatás nyújtásával összefüggő valamennyi adót, illetéket, díjat és jogdíjat, de nem tartalmazza az általános forgalmi adót, a beszerzési díjat, valamint szoftverlicenc-gazdálkodási díjat. A beszerzési díj meghatározására a KM és a DKÜ rendelet 13-14. §-aiban foglalt rendelkezések az irányadóak. A beszerzési díj alapja a Vevő általi beszerzések általános forgalmi adó nélkül számított értéke, mértéke 1,75% + áfa. A beszerzési díjat Vevő az Eladón keresztül fizeti meg.
7 összesen = óradíj x 100 óra
10.5. Vevő a DKÜ rendelet 14/A. § (5) bekezdése szerinti mértékű szoftverlicenc- gazdálkodási díj fizetésére köteles a DKÜ felé, amelyet Eladón keresztül köteles teljesíteni.
10.6. Eladót a jelen szerződésben rögzített ellenértéken (10.1. és 10.2. pont) túl, további díjazás, költségtérítés, vagy szolgáltatás jelen szerződés teljesítéséért semmilyen jogcímen nem illeti meg. A jelen szerződésben meghatározott árak a szerződés időtartama alatt kötöttnek tekintendők, azok semmilyen jogcímen nem emelhetők.
10.7. Eladó a beszerzési díjat és a szoftverlicenc-gazdálkodási díjat köteles a szerződés teljesítése alapján járó ellenérték kiszámlázásával egy időben a Vevő részére kiállított számlára külön tételként szerepeltetni.
11. Fizetési feltételek
11.1. Eladó a jelen szerződés teljesítéséért az alábbiak szerint jogosult számlát benyújtani:
- a jelen szerződés 1.1. a) és b) pontjában meghatározott feladatok teljesítéséért El- adó 3 db számla benyújtására jogosult,
- a jelen szerződés 1.1. c) pontjában meghatározott feladat teljesítéséért Eladó 1 db számla benyújtására jogosult.
11.2. Eladó a teljesítés ellenértékére a számvitelről szóló 2000. évi C. törvény 167. §-ában foglaltak alapján kiállított számla ellenében jogosult. A benyújtandó számla kötelező mellékletei az előírásnak megfelelően kiállított és mindkét Fél által aláírt Teljesítést Igazoló Bizonylat.
11.3. Eladó tudomásul veszi, hogy a teljesítés nettó ellenértéke a „Közigazgatási szakrendszerek egységes eléréséhez és interoperabilitásához központi alkalmazás szintű szolgáltatások biztosítása” tárgyú KÖFOP-1.0.0-VEKOP-15-2016- 00025azonosító számú projekt terhére ún. „szállítói finanszírozás” keretében a Támogató által közvetlenül az Eladónak kerül kifizetésre.
11.4. Eladó tudomásul veszi, hogy hogy a Támogatási szerződés szerint, Teljesítést Igazoló Bizonylattal igazolt, Eladót megillető nettó díjat a Vevő hiánytalan és hibátlan kifizetési kérelmének a Támogatóhoz történő beérkezését követő 30 napon belül a Támogató egyenlíti ki közvetlenül az Eladó bankszámlájára történő átutalással a Kbt.
135. § (1), (4) és (6) bekezdéseiben valamint a Ptk. 6:130. § (1)-(2) bekezdésében meghatározottaknak megfelelően, a 2014–2020 programozási időszakban az egyes európai uniós alapokból származó támogatások felhasználásának rendjéről szóló 272/2014. (XI. 5.) Kormányrendeletben (továbbiakban: Kormányrendelet) foglaltakra figyelemmel. Eladó tudomásul veszi, hogy a Támogató a Vevőt, mint kedvezményezettet hiánypótlásra szólíthatja fel. A fizetési határidőbe a hiánypótlásra igénybe vett időtartam nem számít be.
11.5. A számla általános forgalmi adó tartalmát közvetlenül a Vevő utalja át Eladó részére a számla Vevő központi iktatásra szolgáló elérhetőségére történő beérkeztetését kö- vető 15 napon belül.
11.6. A számla szabályszerű kiállítása után Eladó a számlát a Vevő nevére és a Vevő köz- ponti iktatójába (1389 Budapest, Pf.: 133.) küldi. Vevő a Kbt. 27/A. § alapján lehetővé teszi az elektronikus számla befogadását is az x_xxxxxxx@xxxx.xx e-mail címen.
11.7. Eladó tudomásul veszi, hogy a számlát az alábbiak szerint köteles kiállítani:
- a számlán szerepeltetni szükséges a NISZ Zrt. nevét, címét, adószámát és az általa megadott belső azonosításra szolgáló szerződés számot,
- a számlának meg kell felelnie az általános forgalmi adóról szóló 2007. évi CXXVII. törvény (Áfa tv.) 169. § szerinti előírásoknak,
- a számlán szerepeltetni szükséges a szállított eszközök/szolgáltatások megnevezését, a tevékenység leírását és annak TESZOR számát,
- fizetési határidőként a számla kézhezvételét követő 30 napot,
- a számlán fel kell tüntetni az Eladó bankszámlaszámát, a bank nevét, valamint az adószámát,
- a számlán fel kell tüntetni a „számla” elnevezést,
- a számlán fel kell tüntetni a projekt megnevezését, illetve azonosító számát:
Közigazgatási szakrendszerek egységes eléréséhez és interoperabilitásához központi alkalmazás szintű szolgáltatások biztosítása, KÖFOP-1.0.0-VEKOP-15-2016-00025
- a számlán a beszerzési díj összegét külön tételként kell szerepeltetni (KM V.3.) (be- szerzési díj 1,75%+áfa).
− a számlán a szoftverlicenc-gazdálkodási díj összegét külön tételként kell szerepel- tetni.
Amennyiben Eladó elektronikus számlát nyújt be, a számlának meg kell felelnie:
- az Áfa tv. 175. §-a szerinti előírásoknak; valamint
- EN 16931-1:2017 számú európai szabványnak és az Európai Bizottság által e szab- ványhoz az Európai Unió Hivatalos Lapjában közzétett szintaxislistának.
11.8. Eladó tudomásul veszi, hogy amennyiben jogszabály – így különösen az adózás rend- jéről szóló 2017. évi CL. törvény, vagy annak végrehajtási rendelete - Vevő pénzügyi teljesítését adóigazolás benyújtásához, illetve köztartozásmentes adatbázisban való szerepléshez köti, úgy Vevő ezen jogszabályok szerint jár el a kifizetés során.
11.9. Vevő az Eladó által benyújtott számlával kapcsolatos kifogásait – az indok(ok) meg- jelölésével küldi meg az Eladó részére. Az Eladó jogszabályi előírásoknak, illetve a jelen szerződésben foglalt rendelkezéseknek megfelelően kiállított számlájának befo- gadását a Vevő nem tagadhatja meg.
11.10. Amennyiben a fizetési határidő munkaszüneti napra, ünnepre vagy bankszüneti napra esik, akkor a következő banki munkanap a számla kiegyenlítésének határideje.
11.11. Vevő a Korm. rendelet 118/A. § és 119. § alapján biztosítja az Eladó részére a
szerződés elszámolható összege 30%-ának megfelelő mértékű szállítói előleg igénylé- sének lehetőségét.
11.12. A szállítói előleget - az áfa nélküli összeg tekintetében - (előlegbekérő dokumentum Vevőhöz történő benyújtásán keresztül) Eladó közvetlenül a Támogatótól igényelheti. A Vevő az értesítéstől számított 5 napon belül jelezheti a szállítói előleggel kapcsola- tos fenntartását. Ennek hiányában a szállítói előleg-igénylést a Vevő részéről elfoga- dottnak kell tekinteni.
11.13. Előleg igénylésekor a megkötött szerződés elszámolható – az áfa nélküli - összegé- nek 10%-a erejéig az Eladó mentesül a biztosítéknyújtási kötelezettség alól. Ameny- nyiben 10 %-nál magasabb mértékű előleg kifizetésére kerül sor, az Eladó a szerződés elszámolható összegének 10%-a és az igényelt szállítói előleg különbözetére jutó tá- mogatás összegének megfelelő mértékű, az Irányító Hatóság javára szóló a Kbt. 134.
§ (6) bekezdése vagy a Korm. rendelet 83. § (1) bekezdése szerint más biztosítékot nyújt vagy a Korm. rendelet 118/A. § (2a) b) pontjának figyelembevételével nem nyújt biztosítékot. Az előlegként igénybe vett összeg a teljesítést követően kiállított számlák összegéből kerül levonásra.
11.14. Vevő köteles az Eladó által kiállított és megküldött előlegszámlát annak beérkezését követő 5 napon belül záradékolni és a Támogató részére megküldeni időközi kifizetési igénylés keretében.
11.15. Amennyiben Vevő kifogást emel a benyújtott számlával kapcsolatosan, úgy a szám- lát a számla igazolt kézhezvételét követő 10 naptári napon belül visszaküldi Eladónak. A fizetési határidő a számla újbóli benyújtását követően újra kezdődik.
11.16. Eladó a számla áfa tartalmának késedelmes kiegyenlítése esetén a késedelmi időre a Ptk. 6:155. § (1) bekezdése szerint jogosult késedelmi kamatra.
11.17. A szállítói finanszírozásból fakadó bármely fizetési késedelemért – ide nem értve az áfa megfizetését - Vevő felelősséggel nem tartozik.
11.18. Vevő mentesül a késedelmes fizetés jogkövetkezménye alól, amennyiben Eladó a számlát nem a szerződésben a számla megküldésére meghatározott 11.6 pont szerinti címre (központi iktató vagy e-mail) nyújtja be, vagy a számla egyéb – jelen szerződés- ben szabályozott okból – nem fogadható be.
11.20. Eladó nem fizet, illetve számol el a Szerződés teljesítésével összefüggésben olyan költségeket, melyek a Kbt. 62. § (1) bekezdés k) pont ka-kb) alpontja szerinti feltéte- leknek nem megfelelő társaság tekintetében merülnek fel, és melyek Eladóadóköteles jövedelmének csökkentésére alkalmasak.
11.21. Felek rögzítik, hogy a jelen megállapodás szerinti, a Felek közti elszámolás tekinte- tében irányadónak tekintik a 272/2014. (XI. 5.) Korm. rendelet rendelkezéseit (továb- biakban: Korm. rendelet).
11.22. Az ellenérték megfizetésére egyebekben a KM V.2 pontjának rendelkezéseit kell al- kalmazni.
11.23. Az Eladó a jelen egyedi szerződésből eredő követelését nem engedményezheti har- madik személyre.
11.24. Alvállalkozó(k) igénybevétele esetén:
11.24.1. Amennyiben Eladó a teljesítéshez alvállalkozó(ka)t vesz igénybe, Vevő a Kbt. 135. § (3) bekezdés szerint fizeti ki a szerződésben foglalt ellenértéket.
11.24.2. Eladó köteles gondoskodni arról, hogy alvállalkozó(ka)t teljes körűen tájé- koztassa a számlázás, számlakiállítás, kifizetés körülményeiről, határnapjairól.
11.24.3. Vevő a Teljesítést Igazoló Bizonylat kiadásával egyidejűleg felhívja Eladót, valamint az Alvállalkozó(ka)t, hogy az adott teljesítés elismerését követően állítsák ki számláikat. Egyidejűleg, amennyiben nem szerepelnek az Art. 36/A. §-a szerinti köz- tartozásmentes adózói adatbázisban, kötelesek benyújtani a tényleges kifizetés idő- pontjától számított 30 napnál nem régebbi keltezésű együttes nemleges adóigazolást. Jelen szerződés az adózás rendjéről szóló 2003. évi CXII. törvény (Art.) hatálya alá tartozik, ezért Vevő számlát kizárólag az Art. 36/A. §-ban foglalt feltételek teljesítése esetén jogosult kifizetni. Az adóigazolás beérkezési határideje a fizetési határidőt meg- előző 5. munkanap; Eladó(k) köteles(ek) az alvállalkozói számlák másolatát is benyúj- tani. Az adóigazolás késedelmes benyújtásából eredő fizetés elmaradás a Vevő szá- mára következménnyel nem jár.
12. Jótállás
12.1. Eladó a szerződés teljesítése során átadott IBM InfoSphere Optim Tesztadatkezelő pa- raméterezésére 18 hónap teljeskörű jótállást vállal. A jótállás kezdete az végleges pa- raméterezés átvételének az időpontja.
12.2. Eladó jótállás keretében vállalja, hogy az átadott paraméterezés a jótállási idő alatt a rá vonatkozó, jóváhagyott specifikációban és részletes rendszertervben továbbá egyéb dokumentumokban meghatározottak szerint működik.
12.3. Jótállás keretében Eladó köteles:
- javítani a rendeltetésszerű használat és üzemeltetés során kiderülő hibákat, mind az általa átadott paraméterezésnél, mind az általa átadott paraméterezés miatt hibásan működő funkciók, riportok esetében,
- biztosítani a vonatkozó (technikai-, és a végfelhasználói) dokumentáció(k) fris- sítését.
12.4. Jótállás alá tartozó hibabejelentését Vevő Eladó alábbi elérhetőségein teheti meg mun- kanapokon 9:00-17:00 óra között:
- E-mail cím: xxxx_xxxxxxx@xx-xxxx.xx
- Telefonszám: x0000000000
- Xxxxx xxxxxxxx-kezelő rendszere: xxxx://xx-xxxx.xxxxxxxx.xxx
Telefonon megtett hibabejelentést Vevőnek 60 percen belül írásban is meg kell erősítenie.
Vevőnek bejelentéseit elsősorban Eladó hibajegy-kezelő rendszerében kell megtennie, melyhez Eladó a jótállás időtartamára hozzáférést biztosít részére. Eladónak a hibaelhárítási tevékenységeket napra készen elérhetővé kell tennie Vevő számára a hibajegy-kezelő rend- szerben.
12.5. A hibabejelentésnek legalább az alábbi adatokat kell tartalmaznia:
- hibát bejelentő személy neve, beosztása, e-mail címe
- meghibásodott termék azonosító adatai (verzió száma),
- észlelt hibajelenség leírása,
- a hiba kategóriája,
- hibabejelentés száma.
12.6. Eladónak a hibabejelentést vissza kell igazolnia 2 órán belül.
12.7. A meghibásodások az 2. számú melléklet szerinti hibakategóriákba sorolhatók be.
12.8. Eladónak a bejelentett meghibásodásokat az 2. számú mellékletben meghatározott ha- táridőn belül kell kijavítania.
12.9. A hibajavítás befejezését követően tesztelést kell lefolytatni, melynek során Vevő meggyőződik arról, hogy a hiba kijavítása megtörtént-e, illetve, hogy a hibajavítás nem okozott-e újabb hibákat. A tesztelésről jegyzőkönyvet kell felvenni. Vevő a hibajaví- tást a tesztelési jegyzőkönyv aláírásával fogadja el.
12.10. Amennyiben Xxxxx olyan okból, amelyért felelős jótállási kötelezettségét nem vagy késedelmesen teljesíti, Vevő jogosult a javítását harmadik személlyel elvégeztetni, melynek költségét Eladó viseli.
12.11. A jótállási kötelezettség teljesítésével kapcsolatos valamennyi költséget Eladó viseli.
13. Kötbér
13.1. Amennyiben jelen szerződés 2.2. pontjában meghatározott határidőig olyan okból, amelyért felelős, Eladó jelen szerződés 1. és 2. számú mellékletében meghatározott valamennyi termé- ket nem adja át, szolgáltatást nem teljesít, illetve a hozzá tartozó dokumentumok átadás-átvé- tele nem fejeződik be sikeresen Eladó – az erre okot adó körülmény jellegétől (késedelem, hibás teljesítés vagy meghiúsulás) függően – késedelmi, hibás teljesítési vagy meghiúsulási kötbér fizetésére köteles.
13.2. A késedelmi kötbér mértéke: a késedelem 1-10. naptári napja alatt napi 0,5%, a késedelem 11. napjától napi 1% mértékű. A késedelmi kötbér maximális mértéke 20 %. A késedelmi kötbér alapja a késedelmesen teljesített mennyiség nettó értéke.
13.4. A hibás teljesítési kötbér mértéke: 20%. A hibás teljesítési kötbér alapja a hibásan teljesített mennyiség nettó értéke. A Ptk. 6:187. § (2) bekezdésének alkalmazását Xxxxx kifejezetten ki- zárják, akként, hogy Vevő a szavatossági igény (pl. termék kijavításának kérése, kicserélése) érvényesítésére kitűzött határidő eredménytelen eltelte esetén hibás teljesítés miatti kötbérigé- nyét is érvényesítheti.
13.5. A Szerződés olyan okból történő meghiúsulása esetén, amelyért Eladó felelős, Eladó meghiú- sulási kötbér fizetésére köteles, melynek mértéke a Szerződés nettó értékének 25 %-a. A szer- ződés meghiúsultnak tekintendő, amennyiben Vevő Eladó súlyos szerződésszegése miatt a Szerződést azonnali hatállyal felmondja vagy Vevő a Szerződéstől Eladó súlyos szerződéssze- gése miatt eláll.
13.6. Felek rögzítik, hogy figyelemmel a KM X.2.1. pontjára, ugyanazon kötbéralap tekintetében csak egy kötbér alkalmazható.
13.7. Vevő a kötbérigényről kötbérértesítőt állít ki, melynek összegét jogosult az Eladót megillető díjba beszámítani. Vevő jogosult az esedékessé vált kötbér összegét a díjból visszatartani a Kbt. szabályainak betartásával.
13.8. Eladó tudomásul veszi, hogy a Vevő jogosult a kötbért meghaladó kárának érvényesítésére, illetve, hogy a késedelmi illetőleg hibás teljesítési kötbér megfizetése nem mentesíti a teljesítés alól.
13.9. A kötbérigények érvényesítése nem zárja ki a szerződésszegésből eredő egyéb igények érvé- nyesítésének lehetőségét.
14. A szerződés módosítása, megszüntetése és megszűnése
14.1. Jelen szerződés rendes felmondással nem szüntethető meg.
14.2. Xxxxx jelen szerződést kizárólag a Kbt. 141. §-ban foglaltak figyelembevételével és kizárólag írásban módosíthatják.
14.3. Vevő jogosult Eladó súlyos szerződésszegése esetén Eladóhoz intézett írásbeli értesítésével a szerződést azonnali hatállyal felmondani. Súlyos szerződésszegésnek minősül különösen, ha:
a) Eladó a teljesítést jogos ok nélkül megtagadja,
b) a késedelmi kötbér eléri a maximumot,
c) Eladó megsérti teljesítés módja és átadás-átvétel fejezettben szabályozottakat
d) Xxxxx megsérti a jelen szerződés 15. pontjában meghatározott jogszavatossági előíráso- kat,
e) jelen szerződés 16.5. pontjában (titoktartási kötelezettség megsértése) esetben,
f) Eladó valamely – az a)-e) pontban nem nevesített – jelen szerződésben meghatározott kötelezettségét saját érdekkörében felmerült okból, Vevő erre vonatkozó felszólítása ellenére, Vevő által megadott határidőre nem teljesíti.
g) Eladó jogsértő tevékenységet követ el
14.4. Vevő jogosult – választása szerint – jelen szerződést azonnali hatállyal felmondani vagy attól elállni a Kbt. 143. § (1) bekezdésében szabályozott eset bekövetkezése esetén.
14.5. Vevő köteles – választása szerint – jelen szerződést azonnali hatállyal felmondani vagy attól elállni a Kbt. 143. § (2) bekezdésében szabályozott eset bekövetkezése esetén.
14.6. Vevő jogosult és egyben köteles jelen szerződést azonnali hatállyal felmondani a Kbt. 143.
§ (3) bekezdésében meghatározott esetek valamelyikének bekövetkezése esetén.
14.7. Bármelyik Fél jogosult a szerződést azonnali hatállyal felmondani abban az esetben, ha a másik Fél ellen jogerősen felszámolási eljárást rendeltek el vagy, ha a másik Fél végelszámolással történő megszűnését határozta el.
14.8. Amennyiben Xxxxx jogsértő tevékenységet folytat Vevő köteles felszólítani Eladót írásban a jogsértő tevékenység azonnali befejezésére. Amennyiben Xxxxx jogsértő tevékenységét nem fejezi be azonnal az értesítést követően, úgy Vevő jogosult azonnali hatállyal felmondani a szerződést.
14.9. Eladó Vevő súlyos szerződésszegése esetén jogosult a szerződést Vevőhöz intézett írásbeli értesítésével azonnali hatállyal felmondani. Súlyos szerződésszegést követ el Vevő különösen, ha a szerződésben meghatározott fizetési kötelezettségének Eladó írásos felszólítása ellenére, az abban megadott határidőig nem tesz eleget.
14.10. Az azonnali hatályú felmondásról írásban kell értesíteni a másik felet. A szerződés megszűnésének időpontja a felmondásról szóló értesítés kézbesítésének napja.
14.11. Az azonnali hatályú felmondás a jótállás és szerzői jogi rendelkezések hatályát nem érinti.
15. Felhasználói jogok, jogszavatosság
15.1. Eladó jelen szerződés aláírásával elismeri, hogy Vevő az ellenérték megfizetését követően a szerzői jogról szóló 1999. évi LXXVI. törvény hatálya alá tartozó kifejezetten Vevő számára készített művek korlátozásmentes vagyoni jogát megszerzi. Ezen vagyoni jogokat és Vevő jogo- sult bármely költségvetési szerv részére ingyenesen, vagy térítésmentesen átadni, részére fel- használási jogot biztosítani.
15.2. Eladó szavatosságot vállal azért, hogy a jelen szerződés keretében átadott egyik terméken sem áll fenn harmadik személyeknek olyan joga (pl. szerzői joga, szabadalma vagy védjegye), amely a Vevő jelen szerződés szerinti jogainak megszerzését, gyakorlását korlátozza vagy aka- dályozza.
15.3. Eladó kijelenti és garantálja, hogy a jelen szerződés teljesítése során átadásra kerülő termé- kek saját termékei vagy azok felett jelen szerződés teljesítésének vonatkozásában jelen szerző- désben meghatározottak teljesítéséhez szükséges mértékű, - a jogosultságnak más részére tör- ténő, jelen szerződésben szabályozottak szerinti továbbadási jogát is magában foglaló – rendel- kezési jogosultságokkal rendelkezik.
15.4. Eladó szavatolja, hogy amennyiben jelen szerződésben meghatározott feladatai teljesítésé- hez más személyt is igénybe vesz, ezen természetes és jogi személyekkel olyan tartalmú szerző- déseket köt, melyek Vevő jelen szerződés szerinti jogainak megszerzését és gyakorlását lehetővé teszik, illetve nem korlátozzák vagy akadályozzák.
15.5. A jelen pontban szabályozott felelősségvállalások (jogszavatossági vállalás) Eladót jelen szerződés megszűnését követően is terhelik. Egyebekben a valóságnak meg nem felelő
jogszavatossági nyilatkozat esetén a Vevő – a kártérítési igényének fenntartása és a meghiúsulás jogkövetkezményeinek alkalmazása mellett – a szerződést azonnali hatállyal jogosult felmon- dani.
15.6. Eladó vállalja, hogy félként vesz részt minden, Vevő ellen jelen szerződéssel összefüggésben szabadalom bitorlás vagy szerzői jog megsértése miatt indított eljárásban. Eladó köteles továbbá megtéríteni Vevő jelen pont szerinti eljárásokkal kapcsolatban felmerült minden kárát és költsé- gét.
16. Titoktartás
16.1. Eladó vállalja, hogy a közpénzek felhasználásának nyilvánosságáról szóló szabályozásnak megfelelően üzleti titok címen nem tagadja meg a tájékoztatást a jelen szerződés lényeges tartalmáról.
16.2. Felek kötelesek jelen szerződés teljesítése során a másik Féllel kapcsolatban tudomásukra jutott információkat, adatokat valamint tényeket bizalmasan kezelni, azokat nyilvánosságra nem hozhatják, illetéktelen harmadik személy részére hozzáférhetővé nem tehetik azzal, hogy egyik fél sem akadályozhatja meg a másikat olyan információ kiadásában, amelyet valamely hatósági vagy bírósági eljárás vagy törvényi előírás tesz szükségessé.
16.3. Amennyiben jelen szerződés teljesítésével kapcsolatban Xxxxxxxx harmadik személy számára valamely információt kell kiadnia, azt kizárólag Vevő előzetes írásos hozzájárulásával teheti meg.
16.4. Szerződő Felek megállapodnak, hogy jelen pont alkalmazása szempontjából nem minősülnek harmadik Xxxxxx Xxxxx által szerződésszerűen igénybe vett alvállalkozók, feltéve, hogy jelen szerződésben való közreműködésük előtt titoktartási nyilatkozatot írnak alá és adnak át Vevőnek.
16.5. Eladó teljes felelősséggel tartozik a titoktartási kötelezettségének megsértéséből eredő károkért és tudomásul veszi és elfogadja, hogy a titoktartási kötelezettség megszegése esetén a Vevő jogosult – választása szerint - a jelen szerződéstől elállni vagy jelen szerződést azonnali hatállyal felmondani.
17. Felek közötti kapcsolattartás
17.1. Jelen szerződésben Felek szakmai kapcsolattartásra kijelölt képviselői:
a) Vevő részéről:
Név: Xxxxxxxxxx Xxxx Beosztás: Projektmenedzser Telefon szám: x0000000000
Mobiltelefon szám: x00000000000
E-mail cím: xxxxxxxxxx.xxxx@xxxx.xx
b) Eladó részéről:
Név: xx. Xxxxxx Xxxxx Xxxxxxxx: ügyvezető Telefon szám: x0000000000
Mobiltelefon szám: x00000000000
E-mail cím: xxxxx.xxxxxx@xx-xxxx.xx
17.2. Jelen szerződésben Vevő részéről teljesítés igazolására együttesen jogosult személyek : Név: Xxxxx-Xxxx Xxxxxxxxx
Beosztás: Projekt dokumentációs és monitoring osztályvezető és
Név: Xxxxxxx Xxxxx
Beosztás: Projektmenedzsment igazgató
17.3. Felek jelen pontban meghatározott kapcsolattartóik útján tartják a szerződés teljesítése során a kapcsolatot. Bármelyik Fél jogosult a 17.1-17.2 pontban meghatározott kapcsolattartója/teljesítésigazolója személyét megváltoztatni. Szerződő felek megállapodnak, hogy a 17.1-17.2 pontban meghatározott kapcsolattartók/teljesítésigazoló személyében bekövetkező változás nem igényel szerződésmódosítást, elegendő arról a másik Felet írásban tájékoztatni. A kapcsolattartó/teljesítésigazoló személyében bekövetkezett változás a másik Féllel való szerződésszerű közléstől hatályos. A kapcsolattartó személyek a szerződésmódosításra nem jogosultak.
17.4. Szerződő Felek rögzítik, hogy minden, jelen szerződés teljesítésével kapcsolatos nyilatkozatot vagy egyéb értesítést (továbbiakban: értesítés) szerződésszerűen küldenek meg egymásnak. Szerződésszerű megküldésnek minősül, az írásban és
- írásban igazolt személyes átadással,
- tértivevényes ajánlott levélben,
- elektronikus aláírással ellátott visszaigazolt e-mailben megküldött értesítés.
17.5. Az e-mail útján történő kézbesítés esetén az értesítés akkor válik joghatályossá, amikor a címzett azt igazoltan kézhez vette, arról automatikus vagy kifejezett visszaigazolás érkezett. A tértivevényes ajánlott postai küldeményt a kézbesítés megkísérlésének napján kézbesítettnek kell tekinteni, ha a címzett az átvételt megtagadta. Ha a kézbesítés azért volt eredménytelen, mert a címzett az iratot nem vette át (az a feladóhoz nem kereste jelzéssel érkezett vissza), az iratot – az ellenkező bizonyításáig – a postai kézbesítés második megkísérlésének napját követő ötödik munkanapon kell kézbesítettnek.
17.6. Szerződő Xxxxx megállapodnak, hogy a postai utat kizárólag a szerződésszegéssel valamint jelen szerződés megszüntetésével kapcsolatos értesítések megküldésére veszik igénybe. Jelen pontban meghatározott esetekben azonban a kézbesítés kizárólag postai úton (tértivevényes ajánlott levélben) vagy írásban igazolt személyes átadással történhet.
18. Vis Maior
18.1. A Felek nem felelnek azokban az esetekben, ha a késedelmes teljesítés vagy meghiúsulás vis maior eredménye.
18.2. A jelen pont értelmezése szempontjából Felek „vis maior”-nak tekintik azokat az eseménye- ket, amelyek a Feleknek érdekkörén kívül, Felek részéről elháríthatatlanul olyan okból követ- keznek be, amelyért Felek egyike sem felelős és amelyek Felek szerződésszerű teljesítését akadályozzák vagy késleltetik a szerződés teljesítését feltéve, hogy ezen körülmények a jelen szerződés aláírását követően jönnek létre és az említett időpontban még nem voltak előre lát- hatóak és nem voltak elháríthatóak, így különösen:
a) természeti katasztrófák (villámcsapás, földrengés, árvíz, hurrikán, stb.);
b) tűz, robbanás, járvány, karantén korlátozások;
c) radioaktív sugárzás, sugárszennyeződés;
d) háború vagy más konfliktusok, megszállás, ellenséges cselekmények, mozgósítás, rekvirálás vagy embargó;
e) sztrájk, felkelés, forradalom, lázadás, katonai vagy egyéb államcsíny, polgárháború és terrorcselekmények;
f) zendülés, rendzavarás, zavargások.
18.3. A vis maiornak közvetlen összefüggésben kell állnia az arra hivatkozó Fél tevékenységével, mely összefüggést az arra hivatkozó Félnek írásban igazolnia szükséges.
18.4. Amennyiben vis maior miatt a szerződésben foglalt határidők nem teljesíthetőek, erről a vis maior eseményre hivatkozó Fél köteles haladéktalanul írásban tájékoztatást adni és a tájékoz- tatás alapján Xxxxx kötelesek egyeztetni egymással a szerződés teljesítésének további módjá- ról. Amennyiben Vevő egyéb irányú írásos utasítást nem ad, Xxxxxxxx tovább kell teljesítenie szerződéses kötelezettségeit, amennyiben az észszerűen lehetséges, és meg kell keresnie min- den ésszerű alternatív módot a teljesítésre.
18.5. A vis maiorra hivatkozó felet terheli a 18.2. pontban szereplő feltételek kétséget kizáró és teljes körű bizonyítása.
18.6. A vis maiorra hivatkozó felet terheli annak bizonyítása, hogy a vis maior eseménynek a szer- ződésszerű teljesítésre kiható következményét az adott helyzetben elvárható gondosság tanú- sítása esetén sem – vagy csak aránytalan áldozat árán – lehetett volna elhárítani.
18.7. Amennyiben a vis maior miatt a teljesítési határidő meghaladja a teljesítési határidő leteltét követő 15 naptári napot, a Vevőnek jogában áll – választása szerint – jelen szerződéstől elállni vagy jelen szerződést azonnali hatállyal felmondani. Ez esetben mindkét Fél maga viseli a vis maior miatt felmerült kárát.
19. Egyéb rendelkezések, a szerződés tartalmának értelmezése
19.1. Felek kijelentik, hogy nem válik a szerződés tartalmává minden szokás, amelynek alkalmazá- sában a korábbi üzleti kapcsolatukban megegyeztek, és minden gyakorlat, amelyet egymás között kialakítottak, továbbá minden olyan szokás és gyakorlat, melyet az adott üzletágban a hasonló jellegű szerződés alanyai által széles körben ismernek és rendszeresen alkalmaznak.
19.2. Felek megállapodnak, hogy amennyiben jelen szerződés bármely rendelkezése utóbb érvény- telennek minősül (részleges érvénytelenség), a szerződés többi részét érvényesnek tekintik, kivéve, ha a Felek együttes írásbeli nyilatkozata alapján azt az érvénytelen rész nélkül nem kötötték volna meg.
19.3. Eladónak és a Vevőnek meg kell tennie mindent annak érdekében, hogy közvetlen tárgyalások útján rendezzenek minden olyan nézeteltérést vagy vitát, mely közöttük a szerződés keretében felmerült. Minden ezzel kapcsolatos tényről, akadályozó körülményről a felek kölcsönösen kötelesek egymást írásban tájékoztatni.
19.4. Ha Felek közvetlen tárgyalások megkezdésétől számított 30 naptári napon belül nem tudják megoldani a szerződés alapján vagy ezzel összefüggésben keletkezett jogvitájukat, úgy a jog- vita elbírálására a rendes bírósági fórumokat választják.
19.5. Ha bármelyik Fél egy vagy több esetben nem ragaszkodik a jelen szerződésben meghatározott valamely jog, jogorvoslat vagy választás gyakorlásához, az nem jelenti azt, hogy ugyanannak a feltételnek a jövőbeni teljesítéséről, vagy ugyan azon jog jövőbeni gyakorlásáról is le fog mondani, vagy a követeléseitől el fog állni. A jelen szerződésből fakadó vagy ahhoz kapcso- lódó bármilyen jogról történő lemondás csak erre vonatkozó kifejezett írásbeli nyilatkozat ese- tén érvényes.
19.6. Jelen szerződés főszövegének és mellékleteinek ellentmondása esetén a szerződés fő szöveg- ének rendelkezését kell alkalmazni.
19.7. A jelen szerződésben nem szabályozott kérdésekben, valamint bármely, a teljesítéssel kapcso- latos ellentmondás esetén a hivatkozott KM, illetve annak mellékletei, vonatkozó rendelkezé- sei, továbbá Magyarország mindenkor hatályos jogszabályai irányadók. Jelen szerződés a KM- ban meghatározottakkal ellentétes rendelkezéseket nem tartalmazhat.
19.8. Eladó a jelen szerződés aláírásával kijelenti, hogy a nemzeti vagyonról szóló 2011. évi CXCVI. törvény 3. § (1) bekezdés 1. pontja szerinti átlátható szervezetnek minősül. Eladó erre vonatkozó nyilatkozata jelen szerződéshez 6. számú mellékletként kerül csatolásra. Eladó tu- domásul veszi, hogy a nyilatkozatban foglaltak változásáról - a változás bekövetkezésétől szá- mított 8 napon belül - köteles Vevőt írásban értesíteni. Eladó tudomásul veszi továbbá, hogy a valótlan tartalmú nyilatkozat alapján létrejött szerződést Vevő jogosult azonnali hatállyal felmondani, vagy attól elállni.
Jelen szerződés elválaszthatatlan részét képezi a Beszerző és az Eladó között létrejött fent hivatkozott KM, továbbá az alábbi mellékletek:
1. számú melléklet: Megrendelt termékek megnevezése, mennyisége, egységára, ára
2. számú melléklet: Műszaki leírás (Vevő közbeszerzési műszaki leírása)
3. számú melléklet: Teljesítést Igazoló Bizonylat (TIB minta)
4. számú melléklet: Eladó szerződés aláírásakor ismert alvállalkozói
5. számú melléklet: Nyilatkozat Partner adatairól (minta)
6. számú melléklet: Eladó átláthatósági nyilatkozata
7. számú melléklet: A Kbt. 136. § (2) bekezdése szerinti meghatalmazás8
Budapest, …………….….. Budapest, …………….…..
…………………………………………… | ………………………………………………… |
NISZ Nemzeti Infokommunikációs Szolgáltató Zrt. Vevő | BI-Tech Informatika Kft. Eladó |
8 Kizárólag abban az esetben lesz a szerződés része, ha az Eladó külföldi adóilletőségű
1025431 nyilvántartási számú szerződés 1. számú melléklete
Megrendelt termékek megnevezése, mennyisége, egységára, ára 9
<.. image(A képen asztal látható Automatikusan generált leírás) removed ..>
9 Nyertes Ajánlattevő ajánlata alapján
1025431 nyilvántartási számú szerződés 2. számú melléklete
MŰSZAKI LEÍRÁS
a Biztonságos Kézbesítési Szolgáltatás, a Központi Azonosítási Ügynök, és az Ügyfélkapuhoz kötődő anonimizálási feladatok beszerzéséhez
Verzió | Dátum | Változás oka |
0.1 | 2021-05-26 | Alapverzió |
0.2 | 2021-07-22 | Pontosítások |
1.0 | 2021-11-12 | Végleges verzió |
Az éles üzemben lévő rendszer elvárt anonimizálási feladatainak bemutatása 29
Érintett rendszerek és adatkörök 29
Adatok az érintett rendszerekről 32
Használandó anonimizáló eszköz 32
Elképzelt anonimizálási folyamat 33
TÁMOGATÁSI ERŐFORRÁS BIZTOSÍTÁSA (OPCIONÁLIS) 34
Fontos tények és feltételezések 36
NEM FUNKCIONÁLIS KÖVETELMÉNYEK 38
Jogszabályi megfelelőség, követés 39
Teljesítmény követelmények, hibajavítási határidők 39
A rendszer rendelkezésre állása 39
Méretezhetőség, skálázhatóság 40
Adatkezelés, adatbázis menedzsment 40
Adatintegritás, konzisztencia 41
Központi konfiguráció, menedzsment 43
Logikai architektúrával kapcsolatos követelmények 50
Felhasználói felülettel kapcsolatos követelmények 54
Szállítással kapcsolatos követelmények 57
Projektvezetéshez és minőségirányításhoz kapcsolódó követelmények 58
Teszteléssel kapcsolatos követelmények 60
Szállítandó dokumentációval kapcsolatos követelmények 64
Oktatással, betanítással kapcsolatos követelmények 68
Éles indulással kapcsolatos követelmények 68
Jótállás, támogatás és követés követelményei 68
Dokumentációk tartalmi leírása 71
A beszerzés célja
Jelen Műszaki leírásban meghatározott beszerzés célja kettős. Egyrészt a NISZ fejlesztési és üzemeltetési területének mun- katársait az IBM InfoSphere Optim Tesztadatkezelő megoldás használatára és működtetésére be kell tanítani elméleti tu- dásátadás, majd egy gyakorlati pilotprojekt során. Másrészt az éles üzemben lévő, nagy méretű rendszer adatbázisából teszt környezetbe áttölteni – terheléses tesztelési célok érdekében – az adatokat, melynek során minden érzékeny adatot masz- kolni kell biztonsági a célok elérése érdekében, a visszafejthetetlen anonimizáció során a rendszeren belüli és rendszerek közötti adatkonzisztencia megtartásával.
Az anonimizálási szolgáltatás bevezetése tekintetében egyrészt az IBM InfoSphere Optim Tesztadatkezelő paraméterezési feladatainak elvégzése, másrészt támogatási erőforrás biztosítása a scope.
Célzott olvasókör
Ajánlatkérő – ajánlattevő
Az éles üzemben lévő rendszer elvárt anonimizálási feladatainak bemutatása
Érintett rendszerek és adatkörök
Az alábbi rendszerek esetében kell elvégezni a tesztadat-anonimizálást:
• Központi Azonosítási Ügynök
• Ügyfélkapu
• Biztonságos Kézbesítési Szolgáltatás
Központi Azonosítási Ügynök
A Központi Azonosítási Ügynök (KAÜ) olyan, a Kormány által kötelezően nyújtott teljes körű azonosítási szolgáltatás, amely a szabályozott elektronikus ügyintézési szolgáltatásokban (SZEÜSZ-ökben) azonosít, és azt továbbítja a felhaszná- lók, intézmények felé.
A szolgáltatás magába foglalja az ügyfélkapus jelszavas azonosítást, valamint a Kormány által kötelezően nyújtott sze- mélyazonosításokat (pl. részleges kódú telefonos azonosítás, arcképes azonosítás, elektronikus személyi igazolvány).
A KAÜ az azonosításnál az igénylő által megadott azonosító adatok alapján a viszontazonosítás elvégzését is biztosítja azokban az esetekben, ahol az azonosítási szolgáltató ezt lehetővé teszi, ezzel felgyorsíthatja az elektronikus ügyintézést. A közigazgatási szerv az elektronikus ügyintézés esetén köteles a KAÜ igénybevételével történő azonosítás elfogadását biztosítani.
Ügyfélkapu
Az Ügyfélkapu a magyar kormányzat elektronikus ügyfélbeléptető és azonosító rendszere. Lehetővé teszi, hogy a felhasz- náló – felhasználónevének és jelszavának megadását követően- biztonságosan léphessen kapcsolatba az elektronikus köz- igazgatási ügyintézést, illetve elektronikus közigazgatási szolgáltatásokat nyújtó szervezetekkel. A szolgáltatást az elekt- ronikus ügyintézést biztosító szervek és azok ügyfelei díjmentesen vehetik igénybe. A természetes személy a szolgáltatás igénybevételéhez szükséges regisztrációt az ügyfélkapu létesítésére feljogosított regisztrációs szerveknél (kormányabla- kok, kiemelt NAV ügyfélszolgálatok, külképviseletek stb.) személyesen, elektronikus személyazonosító igazolvány birto- kában online kezdeményezheti.
Elektronikus ügyintézést biztosító szervek az azonosítási szolgáltatást a KAÜ – Központi Azonosítási Ügynök szolgálta- táshoz csatlakozva vehetik igénybe.
Biztonságos Kézbesítési Szolgáltatás
A BKSZ elektronikus dokumentumok kézbesítését biztosító szolgáltatás, amely lehetővé teszi a tárhellyel rendelkező szer- vezetek és természetes személyek számára a hiteles dokumentumalapú kommunikációt.
Biztosítja – többek között –
• a címzett értesítését küldemény érkezéséről,
• az üzenetek fogadásának, valamint sikeres vagy sikertelen kézbesítésének igazolását, erről elektronikus vevény kiállítását és a tárhelyre történő megküldését,
• a dokumentum és az igazolások sérthetetlenségét,
• tárhely adminisztrációs felület elérését a különböző beállítások elvégzésére (pl. kapcsolat- tartási e-mail cím megváltoztatása, vevénykezelési profil módosítása).
A BKSZ-hez kapcsolódó tárhelyszolgáltatások:
1. KÜNY-tárhely: az állampolgárok számára nyújtott, a KÜNY-regisztrációhoz kapcsolódó hivatalos elektronikus kapcsolattartásra szolgáló tárhely;
2. Hivatali tárhely vagy HKP: az elektronikus ügyintézést biztosító szervek, valamint a Kor- mány által kijelölt, közfeladatot ellátó szervek (a továbbiakban együtt: együttműködő szervek) számára nyújtott hivatalos elektronikus kapcsolattartásra szolgáló postafiók;
3. Cégkapu: a gazdálkodó szervezetek számára biztosított hivatalos elektronikus kapcso- lattartásra szolgáló tárhely.
Fenti rendszereket tekintve az anonimizálásnak az alábbi adatkörökre kell kiterjednie. A tervezés során kisebb bővülés lehetséges:
• Születési név
• Viselt név
• Születési ország
• Születési település
• Születési dátum
• Anyja neve
• Nem
• Állampolgárság
• E-mail cím
• Bejelentkezési név
• Elhalálozás dátuma
• Kliens IP címe
• Dokumentum típus
• Dokumentum típus leírás
• Dokumentum megjegyzés
• Dokumentum file neve
• Dokumentum bináris
• Dokumentumhoz rendelt címkék
• Kapcsolattartó neve
• Kapcsolattartó e-mail címe
• Kapcsolattartó telefonszáma
• E-mail tárgya, törzse
• Hivatal, Cégkapu rövid és hosszú neve, adószáma
• Ügyfélkapu nyitás dátuma
• Postafiók azonosító
• Postafiók profil név és szabály adat
• Tárhely cím azonosító
1.1.1.1. Jelenlegi kialakítás
Az érintett rendszerek mindegyikénél a környezetek kialakítása jelenleg a következő:
• Fejlesztői környezet: korlátlan hozzáférés, a Szállító telepíti az alkalmazást/paraméterezést.
• T2 – Integrációs tesztkörnyezet: Szállítók számára hozzáférés kizárólag tesztelési céllal (kor- látozott), telepítés illetve verzióváltás kizárólag az NISZ üzemeltetés által végezhető a szál- lítói dokumentációk alapján.
• T3 – Terheléses tesztkörnyezet: Szállítók számára nem hozzáférhető, a telepítés illetve ver- zióváltás kizárólag az NISZ üzemeltetés által végezhető a szállítói dokumentációk alapján.
• Éles környezet, hozzáférés a NISZ üzemeltetési szabályai alapján.
A T2 Integrációs tesztkörnyezet az egyetlen olyan környezet, mely a különböző egyéb külső vagy belső rendszerekkel adatszintű integrációt valósít meg, így az üzleti funkcionális tesztek itt hajthatók csak végre. A többi tesztsíkon az integráció nem teljeskörű, így az üzleti tesztek csak részben vagy egyáltalán nem kivitelezhetők. Ehhez a környezethez csatlakoznak a különböző intézmények is a saját rendszereik integrációs tesztelése szempontjából, nekik a rendszerek között integrált tesztadatokat biztosítunk (pl.: személyi és lakcím adatok, ügyfélkapu belépési adatok, hivatali és cégkapu tárhely adatok, stb.), hogy a majdani éles működés teljes funkcionalitását le tudják tesztelni.
A T3 Terheléses tesztkörnyezet az alkalmazásokat futtató gépek erőforrása tekintetében megegyezik az éles környezetével, itt tehát szűk keresztmetszet nincs, azonban a rendelkezésre álló adatbázis és filerendszer mérete jóval kisebb az elvártnál, így az éles adatmennyiségnek megfelelő tesztadatok számosságban nem állnak rendelkezésre, így a tesztek eredményére nem feltétlen lehet alapozni az éles működés során. Ehhez a környezethez nem csatlakoznak a különböző intézmények, akik részéről korábban igény volt, hogy ők is szeretnének terheléses teszteket végezni úgy, hogy azok az integrációs pontok is megvannak, melyek a teszteléshez szükségesek.
Fenti problémák miatt a környezet kialakításában változtatásokat tervezünk.
1.1.1.2. Elképzelt új kialakítás
A rendszerek a Kormányzati Adatközpontba (KAK) kerülnek költöztetésre. Ebben a korszerűbb környezetben a terheléses teszthez szükséges adatbázis és filerendszer méretek is az élessel megegyező méretben tudnak rendelkezésre állni, így a terheléses tesztek pontosabb, a valóságnak jobban megfelelő eredménnyel tudnak majd szolgálni.
A Szállítóknak minden esetben alkalmazkodniuk kell a NISZ-ben elfogadott tesztkörnyezet struktúrához, amely a követ- kező lesz:
• Fejlesztői környezet: korlátlan hozzáférés, a Szállító telepíti az alkalmazást/paraméterezést.
• T1 – Tesztkörnyezet: Szállítók számára hozzáférés kizárólag tesztelési céllal (korlátozott), első telepítés illetve verzióváltás kizárólag az NISZ üzemeltetés által végezhető a szállítói dokumentációk alapján.
• T2 – Integrációs tesztkörnyezet és terheléses tesztkörnyezet: Szállítók számára hozzáférés kizárólag tesztelési céllal (korlátozott), a telepítés illetve verzióváltás kizárólag az NISZ üze- meltetés által végezhető a szállítói dokumentációk alapján.
• Éles környezet, hozzáférés a NISZ üzemeltetési szabályai alapján.
Mint látható az integrációs és terheléses tesztkörnyezet összevonásra került, továbbá mivel a rendelkezésre álló infrastruk- túra se korlátozza már az élesnek megfelelő méretű adatmérettel történő tesztelést, így ezt a környezetet akár a NISZ által üzemeltetett érintett rendszerek, akár a csatlakozó intézmények által rendszerei is fel tudják használni egyszerre az integ- ráció és terheléses tesztelésükhöz is.
Adatok az érintett rendszerekről
Az értintett rendszerek mindegyike jelenleg Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 verziót használ, mely a KAK-ba történő Exadatára költözés során várhatóan upgrade-elésre kerül legalább 19c verzióra. Az anonimizálás- nak nem szabad feltételének tekinteni az adatbázis upgrade-t, tehát ezt a verzióváltás nélkül is el kell tudni végezni!
Az adatbázis szervezek active és standby kialakításúak, az aktív rész az F70-ben, a standby a WDC helyszínen találhatóak, a szinkront az Advanced Data Guard biztosítja. Az adatbázis Real Application Clusters módban működik, tehát egy adat- bázis több szerveren fut.
További perzisztencia rétegként NFS van jelenleg használatban, és ez a KAK-be költözés során is így marad. Az anonimizálással érintett Oracle adatbázis mérete kb. 70TB, a táblák száma kb. 80db.
Az anonimizálással szintén érintett NFS mérete kb. 50-100TB.
Exadata méretek: az Exadata jelenlegi kialakítása összesen oldalanként 1-1 db compute machine-t jelentenek. Darabonként 4 db fizikai szerverrel, amelyek 2-2 CPU-t tartalmaznak. Minden CPU 22 fizikai maggal rendelkezik. Így egy oldal össze- sen 176 fizikai core kiosztását teszi lehetővé, melyből 80db mag marad felhasználható oldalanként.
Használandó anonimizáló eszköz
A projekt során a NISZ Zrt. rendelkezésére álló IBM InfoSphere Optim Tesztadatkezelő megoldást kell használni, melyben a szerepkör alapú jogosultságkezelés megvalósítható, illetve a Windows operációs rendszerhez AD integrációt kell meg- valósítani.
Lényeges, hogy fenti dobozos eszköz minél több funkcionalitásának kihasználásával, és a későbbiekben minél kevesebb egyedi fejlesztői ráfordítással valósuljon meg a tesztadat-anonimizáció ajánlatkérői oldalon.
Az eszköz biztosítja és a paraméterezés során kihasználandó képességei:
• kerüljön létrehozásra a központosított, dokumentált adatvagyon leltár, a bizalmas adatok feltérképezése is valósuljon meg,
• kulcselemek anonimizálását a beépített függvényeivel,
• komplex adatmaszkolási feladatok megvalósítására képes,
• beépített lookup táblákat kell használni, melyek segítségével pl. nevek és címek anonimizá- lása megoldott,
• referenciális integritás megőrzése a rendszerek és adattáblák között (üzletileg értelmezhe- tők legyenek az elmaszkolt adatok továbbra is, ne sértse a maszkolás az üzleti megoldások logikai működését),
• az adatforrások elsődleges kulcsai közti kapcsolatok alapján az összes releváns táblában konzisztens módon történjen az anonimizáció. Nem minden esetben javasolt lecserélni az elsődleges kulcsokat az adatminőségi hibák elkerülése érdekében. Ez az egyes adatköröknél a beszállító és a NISZ közötti konzultáció során kerül véglegesítésre.
• a tesztadatkezelési folyamat működtetése és az adatbázis változásainak nyomonkövetése automatizációval történjen.
Az IBM-mel történt egyeztetés alapján a preferált operációs rendszer platfrom a Windows. Amennyiben szükség van az adatfelderítés és adatvagyon modulra, akkor további két virtuális gép javasolt Red Hat 7 vagy 8 operációs rendszerrel.
Tesztadatkezelési projekt folyamata
1. Adatfelderítés
a. Szabályok készítése
b. Felderítés, klasszifikáció futtatása
c. Referenciális integritások felderítése
d. Adatfelderítési riport (adatvagyon katalógus vagy Excel alapon)
2. Ügyfél oldali validáció
a. Adatfelderítési riport
b. Referenciális integritások (subset esetén)
3. Maszkolás, tesztadatok előállítása
a. Referenciális integritások rögzítése (subset esetén)
b. Forrásadatok kiválasztása
c. Maszkolási szabályok alkalmazása és futtatása
4. Folyamat automatizálása, időzítése
Elképzelt anonimizálási folyamat
Az alább az Ajánlatkérő által elképzelt anonimizálási folyamat leírása található, melytől a Szállító az Ajánlatkérővel egyez- tetve eltérhet, amennyiben a Szállító által javasolt megoldás is kielégíti az összes követelményt.
Mint az az Elképzelt kialakítás fejezetben látható, a T2-es intergációs és terheléses tesztkörnyezet adatait kell bővíteni az anonimizált adatokkal. Természetesen ez már az éles anonimizálási folyamat része, de az anonimizálást tesztelni is kell, tehát ennek is kell lennie egy teszt környezetének, és ha az itt történt anonimizálási tesztelési folyamatok lezajlottak, akkor kerülhet csak éles síkra az anonimizálási rendszer.
Fontos követelmény, hogy a jelenleg a T2-es intergációs és terheléses tesztkörnyezetben lévő adatok egyik anonimiálási folyamat során se tűnhetnek el, ezekre az integált tesztadatokra mindig szükség van/lesz, mivel a belső tesztlők és a csat- lakozó intézmények is ezeket használják a teszteléseik során. Az anonimizált adatbázisnak realisztikusnak kell lennie, pl.: nemek aránya, kor eloszlás, területi eloszlás, stb.
A T2-es intergációs és terheléses tesztkörnyezet kialakításának lépései a következők lennének:
1. A jelenlegi T2 Integrációs tesztkörnyezeti adatbázisból új T2 Integrációs tesztkörnyezet és terheléses tesztkörnyezet adatbázis kialakítása. Ez az adatbázis tartalmazza azokat az integ- rációs adatokat, melyeknek az anonimizálási folyamatok során meg kell maradniuk. Ezek- nek az adatoknak egy része módosulhat, törlődhet, illetve új rekordok is keletkezhetnek.
2. Az új T2 Integrációs tesztkörnyezet és terheléses tesztkörnyezet adatbázis feltöltése az ano- nimizált adatokkal: ez a sík lenne feldúsítva az anonimizált adatokkal. Alapesetben ez lenne az integrációs teszt környezet, és az éles adatok anonimizálása és betöltése után egyben a terheléses teszt környezet is.
Fentiek miatt a betöltött anonimizált adatokat meg kell jelölni, vagy külön nyilvántartást kell róluk vezetni annak érdeké- ben, hogy az újbóli anonimizáláskor a megtartandó adatoktól elkülönítve legyenek kezelhetők, akár egy teljesen új anoni- mizált betöltésről legyen szó, akár az élesen változott adatok különbségének rágörgetéséről. Ennek a megjelölésnek olyan- nak kell lennie, ami nem befolyásolja az alaprendszer performanciáját. Nem célszerű például minden táblába új oszlopot létrehozni egy jelölőnek, ami az anonimizált adat jelölésére szolgál, mivel így változik a tábla szerkezete, így a futtatott lekérdezések végrehajtási terve is más lehet, ami miatt fals eredményt hozhatnak a terheléses tesztek. Ezt a folyamatot a beszállító és a NISZ közösen alakítja ki a tervezés folyamán.
Az adatbázis anonimizálásán túl az NFS filerendszeren lévő bináris adatokat is anonimizálni szükséges. Az adatbázisban lévő adatok hivatkoznak az NFS-en lévő file-okra, így az adatkonzisztenciát itt is meg kell tartani!
Magát az anonimizálandó bináris tartalmat nem kell feldolgozni (ez bizonyos esetben lehetetlen is, mivel titkosított állo- mányok is lehetnek), hanem hasonló számosságban/eloszlásban/méretben helyettesítő állományokat kell alkalmazni, lehe- tőleg az eredeti file típusának megfelelően, pl.: PDF esetén PDF-et, XML esetén XML-t, stb. Mivel az IBM Optim alapve- tően adatbázisban található adatok anonimizálását tudja végrehajtani, így erre a problémára a megoldást a beszállító és a NISZ közösen alakítja ki a tervezés folyamán, a fileokat a NISZ generálja, ezekre kell az adatbázis hivatkozásokat kialakí- tani.
A paraméterzés célja
Az IBM InfoSphere Optim Tesztadatkezelő felparaméterezésének célja az éles üzemben lévő, nagy méretű rendszer adat- bázisából teszt környezetbe áttölteni – terheléses tesztelési célok érdekében – az adatokat, melynek során minden érzékeny adatot maszkolni kell biztonsági a célok elérése érdekében, a visszafejthetetlen anonimizáció során a rendszeren belüli és rendszerek közötti adatkonzisztencia megtartásával.
Ezáltal olyan terheléses tesztek futtathatók, melyek valós képet adhatnak az alkalmazások teljesítményproblémáival és optimalizációs lehetőségeivel kapcsolatban még az éles üzembe történő telepítés előtt.
A következő lépések során a szállító a NISZ munkatársaival szoros együttműködésben kell dolgozzon:
• Felmérési fázis, amely során a környezeti jellemzőket, rendszerkapcsolatokat és érzékeny adatköröket mérjük fel. A fent bemutatott adat- és metaadat feltérképezés szoftver funkció segítségével validáljuk a korábban NISZ által meghatározott érzékeny adatok lokációkat.
• Koncepció és rendszertervezés, mely során a kialakítandó tesztadatkezelés/teszt menedzs- ment folyamat alkotóelemeinek magas szintű terve készül el.
• Telepítés, mely során a paraméterezés a NISZ környezetbe való beüzemelése és illesztése történik meg.
• Konfiguráció és folyamatfejlesztés, mely során a KAÜ, Ügyfélkapu és BKSZ rendszerekre való anonimizált áttöltés beállítása, valamint az alábbi speciális igények kiszolgálása a cél:
o Strukturált adatok esetében a KAÜ, az Ügyfélkapu és BKSZ adatbázisában tárolt, scope-ba tartozó adatkörök a mérvadóak. Ez esetben realisztikus adat-anonimizá- lás történik.
o Nemstrukturált adatok esetében NFS-en, illetve adatbázisban tárolt bináris adatok- ban végzünk maszkolást – előre meghatározott, konstans fájltartalommal történő felülírás művelete által.
o A tesztadatok anonimizálását úgy szükséges megvalósítani, hogy az integrált tesz- telési folyamatokban használatos közel 800 db teszt user törzsadatai sértetlenek maradjanak, így a tesztelés folytonossága biztosítva legyen. Az anonimizált tranz- akciós adatok és teszt userek összerendelése a folyamatfejlesztés utolsó szakaszá- ban szintén a feladat részét képezi, melynek technikai részletei egyeztetések alap- ján közösen kerülnek meghatározásra.
• Tesztelés, mely során a folyamat végtermékeként előálló integrált tesztkörnyezetet adat- validációs teszteknek vetjük alá.
Oktatás és pilotprojekt
A NISZ fejlesztési és üzemeltetési területének munkatársait az IBM InfoSphere Optim Tesztadatkezelő megoldás haszná- latára és működtetésére be kell tanítani elméleti tudásátadás, majd egy gyakorlati pilotprojekt során.
A feladatvégzés végén a NISZ kijelölt munkatársainak olyan oktatási szintre kell eljutniuk, hogy használni tudják akár más rendszerek anonimizálásához is az eszközt.
Az oktatásnak azokra a szoftverelemekre is ki kell terjednie, amik a szkópban felsorolt rendszerek anonimizálásához nem feltétlen, vagy egyáltalán nem kellenek, de más rendszer esetén szükségesek lehetnek. Ilyenek példádul az adatfelderítéshez vagy a tesztadat generáláshoz kötődő szoftverelemek.
Támogatási erőforrás biztosítása (opcionális)
Jelen paraméterezési feladaton túl a NISZ Zrt. más szakrendszerek vonatkozásában is az anonimizálási feladataihoz szak- értői órákat kíván biztosíttatni. Az elvárt mennyiség: 100 szakértői óra
Jelen fejezetben a Szakmai motíváció fejezetben ismertetésre került paraméterezési feladat funkcionális követelményeire, továbbá az oktatás és pilotprojektre vonatkozó teljesítési ütemezés kerül meghatározásra.
A nem funkcionális követelmények tejes körű teljesítése minden alábbi ütemezési fázisban külön-külön elvárt. Az egyes fázisok időtartamára (kivéve a 3. fázis) vonatkozóan az Ajánlattevőnek kell ajánlatot tennie.
sorszám | Megnevezés | Eredmény Termék | Teljesítési ütem | Teljesítés mértéke (%) |
1. | Pilot fázis: Oktatás, Telepítés támoga- tás, gyakorlati pilot projekt | Oktatás megtörténik, a rend- szerek telepítésre kerülnek, a pilot projekt sikeresen zárul. Oktatási dokumentációk. | Ajánlattevő adja meg | 25 |
2. | Koncepcionális tervezés, Paramétere- zések átadása Teszt-re | Koncepcionális terv elfoga- dása: Logikai és fizikai tervek Tesztfázis indulása: Telepí- tési, üzemeltetési, tesztelési dokumentációk. | Ajánlattevő adja meg | 40 |
3. | Éles telepítés, próbaüzem Projekt zá- rása | Projektzárás: minden követel- ményt teljesít, köztük azt is, hogy megfelelő idő alatt lefut a teljes anonimizálás. Rend- szerbiztonsági terv, Oktatási dokumentációk, próbaüzem alatti változásokból adódóan minden érintett dokumentáció aktualizálása, frissítése | 2022.11.30 | 35 |
Pilot fázis
Az első fázisban Ajánlattevőnek be kell tanítani a NISZ fejlesztési és üzemeltetési területének munkatársait az IBM InfoS- phere Optim Tesztadatkezelő megoldás használatára és működtetésére egy gyakorlati pilotprojekt során.
A feladatvégzés végén a NISZ kijelölt munkatársainak olyan oktatási szintre kell eljutniuk, hogy használni tudják akár más rendszerek anonimizálásához is az eszközt.
Második fázis
A második fázisban a szkópban megjelölt rendszerek tekintetében a különböző környezetekben végre kell hajtani az ano- nimizáláshoz kötődő paraméterezési és oktatási feladatokat, illetve le kell szállítani az elvárt dokumentációkat.
Megkövetelt kötöttségek
A megvalósítás során nem módosítható, megkövetelt kötöttségek az alábbiak:
• az adatok érzékenysége miatt az adatáramlás titkosítását biztosítani kell a folyamat kiinduló- pontjától a védett adatbázisba való kerülésig
• az adminisztrációs felületek csak a belső, védett alkalmazásban valósulhatnak meg
• az infrastruktúrát KAK környezetbe kell telepíteni, a használni kívánt technológiákat, hardver- és szoftverkomponenseket a NISZ érintett szakembereivel előzetesen szükséges egyeztetni. A kiválasztott komponenseket a Megrendelőnek is jóvá kell hagynia.
Definíciók és fogalmak
SZEÜSZ | Szabályozott elektronikus ügyintézési szolgáltatás |
KEÜSZ | Központi elektronikus ügyintézési szolgáltatás |
KAÜ | Központi Azonosítási Ügynök |
KÜNY | Központi Ügyfél-regisztrációs Nyilvántartás |
KAK | Kormányzati Adatközpont |
Eüsztv. | 2015. évi CCXXII. törvény az elektronikus ügyintézés és a bizalmi szolgáltatások általános sza- bályairól |
Ibtv. | 2013. évi L. törvény az állami és önkormányzati szervek elektronikus információbiztonságáról |
Vhr. | 451/2016. (XII. 19.) Korm. rendelet az elektronikus ügyintézés részletszabályairól |
Fontos tények és feltételezések
A projekt jelen dokumentumban bemutatott elvárásoknak megfelelő, sikeres megvalósulásához az alábbi feltételezések teljesülése szükséges.
Adatforrás állandósága – a feltöltendő állományok struktúrájában történő bármilyen változtatásról az érintetteket hala- déktalanul tájékoztatni szükséges.
Belső erőforrások rendelkezésre állásának biztosítása – A megrendelő által delegált erőforrások szükséges rendelke- zésre állása (lásd Résztvevők) a projekt során biztosított.
A megvalósító informálása a jogszabályi változásokról - jogszabálynak minősül e dokumentum tekintetében a törvény, a kormányrendelet, a miniszterelnöki rendelet, a miniszteri rendelet. A projektet érintő jogszabályi változásokról a megva- lósító naprakész információkat fog kapni a szakmai résztvevőktől, a bevont szakértők szükség esetén konzultációs lehető- séget kapnak, hogy egyeztessenek a jogszabályi változásoknak az új rendszerre vonatkozó hatásairól.
Jelen beszerzési eljárás tárgya a szkópban megjelölt éles üzemben lévő rendszerek tekintetében végre kell hajtani az anonimizáláshoz kötődő IBM InfoSphere Optim Tesztadatkezelő paraméterezési és oktatási feladatokat, illetve le kell szállítani az elvárt dokumentációkat, illetve ezt megelőzően a pilotfázisban az Ajánlattevőnek be kell tanítani a NISZ fejlesztési és üzemeltetési területének munkatársait az IBM InfoSphere Optim Tesztadatkezelő megoldás használatára és működtetésére egy gyakorlati pilotprojekt során.
Követelmény továbbá az anonimizálási feladatokat ellátó rendszer jelen műszaki leírásban részletesen kifejtett funkcionális és egyéb követelményeknek megfelelő szállítása, paraméterezése, a kapcsolódó tesztelési, dokumentációs követelmények teljesítése.
Ajánlattevőnek ajánlatot kell tenni a tervezési, szervezési fázistól kezdve a rendszer éles üzembeállítását követő kiemelt támogatás elvégzésig terjedő paraméterezési és kapcsolódó szolgáltatási feladatok ellátására az fenti pontokban részletezettek szerint.
A műszaki leírásban található összes terv és a követelmény a részletes tervezés fázisában pontosításra szorulhat!
Feladat jogi háttere
A szolgáltatás működését az alábbi jogszabályok és egyéb jogforrások rendelkezéseivel összhangban, azoknak megfelelve kell biztosítani, illetve az elvárt paraméterezési feladatot végrehajtani:
• a természetes személyeknek a személyes adatok kezelése tekintetében történő védelméről és az ilyen adatok szabad áramlásáról, valamint a 95/46/EK rendelet hatályon kívül helye- zéséről szóló, az Európai Parlament és Tanács (EU) 2016/679 Rendelete (2016. április 27.) (a továbbiakban: GDPR),
• 2013. évi L. törvény az állami és önkormányzati szervek elektronikus információbiztonságá- ról (továbbiakban: Ibtv.),
• 41/2015. (VII. 15.) BM rendelet az állami és önkormányzati szervek elektronikus informá- cióbiztonságáról szóló 2013. évi L. törvényben meghatározott technológiai biztonsági, va- lamint a biztonságos információs eszközökre, termékekre, továbbá a biztonsági osztályba és biztonsági szintbe sorolásra vonatkozó követelményekről.
A fejezetben található összes terv és a követelmény a részletes tervezés fázisában pontosításra szorulhat!
Funkciók
Azonosító | Megnevezés | Leírás |
FN-001 | Anonimizálás | Minden érzékeny adatot maszkolni kell biztonsági a célok elérése érdekében, a visszafejthetetlen anonimizáció során a rendszeren belüli és rendszerek közötti adatkonzisztencia megtartásával. |
FN-002 | Anonimizálás adatkörei | Az anonimizálásnak az alábbi adatkörökre kell kiterjednie. A ter- vezés során kisebb bővülés lehetséges: • Születési név • Viselt név • Születési ország • Születési település • Születési dátum • Anyja neve • Nem • Állampolgárság • E-mail cím • Bejelentkezési név • Elhalálozás dátuma • Kliens IP címe • Dokumentum típus • Dokumentum típus leírás • Dokumentum megjegyzés • Dokumentum file neve • Dokumentum bináris • Dokumentumhoz rendelt címkék • Kapcsolattartó neve • Kapcsolattartó e-mail címe • Kapcsolattartó telefonszáma • E-mail tárgya, törzse • Hivatal, Cégkapu rövid és hosszú neve, adószáma • Ügyfélkapu nyitás dátuma • Postafiók azonosító • Postafiók profil név és szabály adat • Tárhely cím azonosító |
FN-003 | Intergált tesztadatok biztosí- tása | A T2 Integrációs tesztkörnyezet az egyetlen olyan környezet, mely a különböző egyéb külső vagy belső rendszerekkel adatszintű in- tegrációt valósít meg, így az üzleti funkcionális tesztek itt hajtha- tók csak végre. A többi tesztsíkon az integráció nem teljeskörű, így az üzleti tesztek csak részben vagy egyáltalán nem kivitelezhetők. Ehhez a környezethez csatlakoznak a különböző intézmények is a saját rendszereik integrációs tesztelése szempontjából, nekik a rendszerek között integrált tesztadatokat biztosítunk (pl.: személyi és lakcím adatok, ügyfélkapu belépési adatok, hivatali és cégkapu tárhely adatok, stb.), hogy a majdani éles működés teljes funkcio- nalitását le tudják tesztelni. |
T2-es intergációs és terheléses tesztkörnyezetben lévő adatok egyik anonimiálási folyamat során se tűnhetnek el, ezekre az inte- gált tesztadatokra mindig szükség van/lesz, mivel a belső tesztlők és a csatlakozó intézmények is ezeket használják a teszteléseik so- rán. | ||
FN-004 | Használandó anonimizáló eszköz és kihasználandó ké- pességei | A projekt során a NISZ Zrt. rendelkezésére álló IBM InfoSphere Optim Tesztadatkezelő megoldást kell használni. Lényeges, hogy fenti dobozos eszköz minél több funkcionalitásá- nak kihasználásával, és minél kevesebb fejlesztői ráfordítással va- lósuljon meg a tesztadat-anonimizáció ajánlatkérői oldalról. Az IBM InfoSphere Optim Tesztadatkezelő felparaméterezése so- rán kihasználandó képességei: • kerüljön létrehozásra a központosított, dokumentált adatvagyon leltár, a bizalmas adatok feltérképezése is valósuljon meg, • kulcselemek anonimizálását a beépített függvényeivel, • komplex adatmaszkolási feladatok megvalósítására ké- pes, • beépített lookup táblákat kell használni, melyek segítsé- gével pl. nevek és címek anonimizálása megoldott, • referenciális integritás megőrzése a rendszerek és adat- táblák között (üzletileg értelmezhetők legyenek az elmaszkolt ada- tok továbbra is, ne sértse a maszkolás az üzleti megoldások logikai működését), • az adatforrások elsődleges kulcsai közti kapcsolatok alapján az összes releváns táblában konzisztens módon történjen az anonimizáció, • a tesztadatkezelési folyamat működtetése és az adatbázis változásainak nyomonkövetése automatizációval történjen. A preferált operációs rendszer platfrom a Windows. Adatfelderítés és adatvagyon modul esetén RedHat 7/8 szükséges. |
FN-005 | Realisztikus eloszlás | Az anonimizált adatbázisnak realisztikusnak kell lennie, pl.: ne- mek aránya, kor eloszlás, területi eloszlás, stb. |
FN-006 | Anonimizált adatok nyilván- tartása | Fentiek miatt a betöltött anonimizált adatokat meg kell jelölni, vagy külön nyilvántartást kell róluk vezetni annak érdekében, hogy az újbóli anonimizáláskor a megtartandó adatoktól elkülö- nítve legyenek kezelhetők, akár egy teljesen új anonimizált betöl- tésről legyen szó, akár az élesen változott adatok különbségének rágörgetéséről. |
FN-007 | Anonimizált adatok nyilván- tartása, performancia | Az anonimizált adatok megjelölésnek olyannak kell lennie, ami nem befolyásolja az alaprendszer performanciáját. Nem célszerű például minden táblába új oszlopot létrehozni egy jelölőnek, ami az anonimizált adat jelölésére szolgál, mivel így változik a tábla szerkezete, így a futtatott lekérdezések végrehajtási terve is más lehet, ami miatt fals eredményt hozhatnak a terheléses tesztek. |
FN-008 | Filerendszer anonimizálása | Az adatbázis anonimizálásán túl az NFS filerendszeren lévő biná- ris adatokat is anonimizálni szükséges. Az adatbázisban lévő ada- tok hivatkoznak az NFS-en lévő file-okra, így az adatkonziszten- ciát itt is meg kell tartani. Magát az anonimizálandó bináris tartal- mat nem kell feldolgozni (ez bizonyos esetben lehetetlen is, mivel titkosított állományok is lehetnek), hanem hasonló számosság- ban/eloszlásban/méretben helyettesítő állományokat kell alkal- mazni, lehetőleg az eredeti file típusának megfelelően, pl.: PDF esetén PDF-et, XML esetén XML-t, stb. . Mivel az IBM Optim alapvetően adatbázisban található adatok anonimizálását tudja végrehajtani, így erre a problémára a megoldást a beszállító és a NISZ közösen alakítja ki a tervezés folyamán, a fileokat a NISZ generálja, ezekre kell az adatbázis hivatkozásokat. |
Nem funkcionális követelmények
A fejezetben található összes terv és a követelmény a részletes tervezés fázisában pontosításra szorulhat!
Sikerkritériumok
Azonosító | Megnevezés | Leírás |
SK-001 | jogszabályoknak való megfelelés megvalósítása | |
SK-002 | optimalizált, egyszerű folyamatok kialakítása, amelyek felesleges lépésektől mentesek | |
SK-003 | az anonimizálásnak a követelmények között található idő alatt kell lefutni, úgy hogy az éles rendszert csak kis mértékben terhelje | |
SK-004 | a NISZ kijelölt munkatársainak olyan oktatási szintre kell eljutniuk, hogy használni tudják akár más rendszerek anonimizálásához is az eszközt |
Tervezési megszorítások
Azonosító | Megnevezés | Leírás |
TM-001 | Verziókeze- lés | A paraméterezés során előállított eredmény teszt átadásá- nak előfeltétele, hogy az előrehaladás követhető legyen, az adott verzióban implementált képességek és hibajavítá- sok beazonosíthatók legyenek. Ennek érdekében minden átadott példánynak tartalmaznia kell a verziószámot, a létrehozás időpontját, és a változások pontos leírását ki- adási jegyzékben kell mellékelni. |
TM-002 | Átadás tesz- telésre | A fejlesztői tesztkörnyezetben sikeresen telepített verzió tesztre átadásának követelménye az adott verzióhoz tar- tozó telepítő készlet és paraméterezés egy csomagba fog- lalása. A verzióhoz kiadott csomagban együtt kell átadni az adott verzióhoz tartozó paraméterezést, konfigurációs fájlokat, build scripteket, telepítési dokumentációt és a te- lepítendő állományokat. |
Jogszabályi megfelelőség, követés
Azonosító | Megnevezés | Leírás |
JMK-001 | Jogszabályi megfelelőség | A szállított rendszernek az átadás időpontjában hatályos jogszabályi előírásoknak teljes mértékben meg kell felel- nie. |
Teljesítmény követelmények, hibajavítási határidők
A rendszer rendelkezésre állása
Azonosító | Megnevezés | Leírás |
RA-001 | Üzemidő | A rendszer üzemideje: negyedévente, és ekkor kb. 1 hé- tig 7 × 24 |
RA-002 | Tervezett kar- bantartások | Ajánlattevő dolgozzon ki a rendelkezésre álló erőforrás kapacitásnak megfelelő mentési tervet. Állítsa össze en- nek menetét, gyakoriságát. |
Azonosító | Megnevezés | Leírás |
VI-001 | Anonimizá- lási folyamat időigénye | A teljes anonimizálási folyamat nem tarthat tovább, mint 10 munkanap. |
Azonosító | Megnevezés | Leírás |
MS-001 | Anonimizálási folyamat ter- helése | Az anonimizálási folyamat nem okozhat 5%-nál több többletterhelést az éles adatbázison a futása során. |
MS-002 | Skálázhatóság | Az IBM InfoSphere Optim Tesztadatkezelő alkalmazás tekintetében minimálisan elvárt követelmény, hogy an- nak minden lényeges komponense skálázható legyen. Tehát az üzemeltetés során, a rendszer kapacitásának minimális erőfeszítéssel, a rendszer felépítésének módo- sítása nélkül, a terheléssel arányosan növelhetőnek kell lennie. Ezért kiemelt figyelmet kell fordítani: • az adatbázis méret növekedés, • a tranzakciószám emelkedés, • a tranzakciók bonyolultságának növekedése, • a felhasználói szám növekedés kezelésére. Ajánlattevő ajánlatában mutassa be, hogy az általa szál- lított megoldás miként felel meg a skálázhatósági köve- telménynek, és esetlegesen milyen korlátozásokkal ren- delkezik az ajánlott megoldás ezen a téren. Habár a há- lózat nem tartozik jelen beszerzés tárgyába, Ajánlatte- vőnek ajánlatában ki kell térnie az általa javasolt megol- dás sávszélesség-igényére is. |
Hibakategóriákat lásd a teszt követelményeknél.
Azonosító | Megnevezés | Leírás |
ERR-001 | Kritikus hiba elhárítása | Megkerülő megoldás biztosítása: 4 óra Végleges megoldás biztosítása: 24 óra |
ERR-002 | Súlyos hiba el- háritása | Megkerülő megoldás biztosítása: 24 óra Végleges megoldás biztosítása: 3 munkanap |
ERR-003 | Alacsony hiba elhárítása | Megkerülő megoldás biztosítása: 3 munkanap Végleges megoldás biztosítása: 6 munkanap |
Adatkezelés, adatbázis menedzsment
Azonosító | Megnevezés | Leírás |
DBM-001 | Időbélyeg | Az adatrekordok rögzítése kötődjen időbélyeghez. |
DBM-002 | Helyreállíthatóság | Amennyiben a rekordok rögzítését követően bármi- lyen későbbi időpontban az adattartalom módosul, úgy a rendszer rögzítse a módosítási információkat |
oly módon, hogy logikailag (lekérdezésekben, ripor- tokban) pontosan helyreállíthatók legyenek az egyes, eltérő időpontokban érvényes adattartalmak. |
Azonosító | Megnevezés | Leírás |
AK-001 | Konzisztencia | A rendszernek garantálnia kell a benne tárolt adatok in- tegritását és konzisztenciáját. Az adatbázisokban és az üzenet feldolgozó modulokban olyan megoldásokat kell alkalmazni, amelyek biztosítják, hogy a tárolt és továbbított, egymással összefüggő adatok között az összefüggések ellentmondásmentesek legye- nek. Az integritás ellenőrzését ütemezetten működő, automa- tikusan végrehajtható ellenőrző algoritmusok végzik. A végrehajtott ellenőrzéseket naplózzák, és bármely adat sé- rülése esetén riasztást küldenek. |
AK-002 | Konzisztencia | A konzisztencia ellenőrző algoritmusok vezérléséhez ki kell alakítani egy ütemező szolgáltatást. Az ütemező szol- gáltatás konfigurációjának megfelelően menedzseli az egyes munkamenet példányokat az ellenőrző algoritmu- sokból. |
AK-003 | Konzisztencia | Az adatszerkezet illetve adatmodell kialakításánál figye- lembe kell venni a tranzakciós szinten garantálható kon- zisztens kialakítást. A komponensek mentén történő sze- parációnak olyannak kell lennie, hogy valamely rész elér- hetetlensége miatt inkonzisztens tárolt állapot ne jöhessen létre. |
AK-004 | Konzisztencia | Mind a működési logika, mind pedig a tárolt adatok te- kintetében a rendszer biztosítsa a konzisztens állapot visz- szaállíthatóságát. |
AK-005 | Konzisztencia | A rögzített adatok minden esetben legyenek, és feldolgo- zásuk alatt folyamatosan maradjanak konzisztensek (egy módosított adatból esetlegesen származtatott adat minden esetben automatikusan frissüljön, és ellentmondásos adat együttesek ne forduljanak elő egyetlen állapotban sem). |
Azonosító | Megnevezés | Leírás |
DI-001 | Hozzáférés | Az architektúrának garantálnia kell azt, hogy az üzemelte- tők nem - illetve csak a megfelelő engedélyek birtokában és független naplózás mellett - férnek hozzá az ügyfelek tulajdonában álló adatokhoz. |
Azonosító | Megnevezés | Leírás |
SA-001 | Mentés | A rendszernek lehetővé kell tennie, hogy a felhasználók számára a rendszer szolgáltatásai elérhetők és |
használhatók legyenek az adatmentések ideje alatt is, min- den központi szolgáltatási funkcióra vonatkozóan 7x24 órában. | ||
SA-002 | Mentés | Mentés ideje alatt az indokolt teljesítménycsökkenés a ké- rések kiszolgálásában elfogadható. Az üzemeltetői alkal- mazásban az adminisztratív funkciók korlátozása indokolt esetben elfogadható a mentési eljárás közben. |
SA-003 | Mentés | A rendszer mentéseinek ki kell terjednie minden olyan rendszer összetevőre, amely a rendszer teljes működőké- pességének helyreállításához szükséges. (A mentésből a rendszer minden komponense legyen maradéktalanul helyreállítható a megfelelő hardver eszközök rendelke- zésre állása esetén.) |
SA-004 | Mentés | A rendszert úgy kell kialakítani, hogy az újraindítások, vagy mentésből történő adat/rendszer visszatöltések a meghatározott maximális kiesési időn belül végrehajtha- tóak legyenek. |
SA-005 | Mentés | A mentési eljárás keretében gondoskodni kell a funkcio- nális adatokon túl a naplóállományok mentéséről mind a fájlrendszerbe, mind az adatbázisba történő naplózás ese- tében az adott tárolási technológiának megfelelő eszköz- zel. |
SA-006 | Mentés | Az adatok biztonságos kezelése érdekében a rendszernek biztosítania kell, hogy akár a központi mentőrendszer akár a lokális mentőrendszer felhasználásával megvalósuló adatmentések ideje alatt az adatok elérése folyamatos kell maradjon. |
SA-007 | Mentés | A rendszerben alkalmazott tárolórendszereknek biztosíta- nia kell, hogy nagy mennyiségű adatok mozgatása a tároló rendszerek között ne befolyásolja a rendszer működését, biztosítsa az üzemszerű működés során az adatokhoz való hozzáférést. |
SA-008 | Mentési és archiválási terv | A leszállított mentési és archiválási tervnek illeszkedni a kell a rendszer biztonsági besorolása és a törvényi szabá- lyozás által meghatározott követelményekhez. |
SA-009 | Archiválás | Adatok archiválás koncepciójának, kivitelezésének kidol- gozása. |
Azonosító | Megnevezés | Leírás |
E-001 | Teszt támo- gatás | A végfelhasználói teszteket az Ajánlatkérő vagy megbí- zottja végzi. Ezen tesztek során az Ajánlattevőnek folya- matos támogatást kell biztosítani a hibák elemzése, súlyo- zása és a javítások átadása, illetve az újratesztelési folya- matok során. |
Azonosító | Megnevezés | Leírás |
EX-001 | Exportálás | A rendszer legyen képes az alkalmazásban a menedzsment felületen elérhető riportok szabványos, nyílt formátumba (ODF és PDF) történő exportálására. |
Rendszermenedzsment
Központi konfiguráció, menedzsment
Azonosító | Megnevezés | Leírás |
KM-001 | A rendszernek architekturálisan úgy kell felépülnie, és olyan technológiákat kell használnia, amelyek segítségével biztosítható, hogy a funkciók, szolgáltatások használata és frissítése a lehető legkisebb mértékben támasszon helyi IT támogatási igényeket. | |
KM-002 | A rendszernek a rendszerfelügyelet (Nagios, PVSR agen- tek) számára riasztási alapinformációkat kell biztosítaniuk az egyes modulok működésében lényegesnek minősülő rendszerjellemzők JMX interfészen keresztüli lekérdezhe- tőségével. | |
KM-003 | Az egyes üzemeltetési jellemzők esetében az üzemeltetési dokumentációkban egyaránt rögzíteni kell a megengedett és a beavatkozást igénylő paramétereket, ezek alapértelme- zett értékeit. | |
KM-004 | Szükség szerint létre kell hozni ütemezett feladatkezelő modult, amely képes a különböző ütemezett feladattípusok példányainak ütemezés szerinti futtatására. Ahol a művelet jellege megengedi a művelet megszakítását és későbbi időpontban folytatását, ott a rendszernek bizto- sítania kell a megszakítás vezérléséhez szükséges informá- ciókat a műveletet végrehajtó programmodul számára, va- lamint biztosítani kell a későbbi újraindításnál a művelet megfelelő paraméterekkel való futtatását. | |
KM-005 | A konfigurációs állományokból nem tárolhatóak nyíltan a különböző rendszer kapcsolatokhoz szükséges érzékény adatok (username, password). | |
KM-006 | A konfigurációs állományokban lévő rendszer paraméterek értéke olvasható, módosítható legyen. Az értékek meg- adása listából történjen, ahol előre definiált értékeket vár a rendszer. (bekapcsolva, kikapcsolva). Üzemeltetői beavat- kozást csak a rendszer újraindítására igényeljen. Ennek megtörténtét is láthatóvá kell tenni a felületen időpont megjelöléssel. Az értékek módosítása naplózásra kerüljön. |
Azonosító | Megnevezés | Leírás |
MT-001 | A rendszernek biztosítania kell a kvantitatív módon kife- jezhető működési paraméterek mérését, kapcsolódó |
adatgyűjtést és jelentéskészítést (pl. rendelkezésre állás és megbízhatóság, válaszidők). | ||
MT-002 | A rendszernek rendelkeznie kell menedzsment szintű ri- porting, felügyeleti és riasztási komponenssel. | |
MT-003 | Elvárás a rendszert felügyelő infrastruktúrával szemben a riasztási és riport lehetőségek biztosítása és a monitorozási rendszer egységessége és integráltsága, valamint a széles körökben elterjedt monitorozó rendszerekhez történő kap- csolódás (pl. NAGIOS, MS SCOM, PVSR). |
Azonosító | Megnevezés | Leírás |
NA-001 | Naplózás | A rendszerben végrehajtott mindennemű műveletet naplózni kell. A rendszernek naplóznia kell minden felhasználói és ad- minisztrátori tevékenységet, a rendszerben elvégzett művele- tek nyomon követhetősége érdekében. |
NA-002 | Naplózás | A naplózás célja szerint két fő naplócsoport kell, hogy meg- valósuljon: • Rendszer naplózás: rendszerfolyamatok, szerver oldali események mély szintű, operatív üzemel- tetési célú naplózására, • Audit célú naplózás: a rendszeren történő szolgál- tatás igénybevétel naplózására. Ezek technológiai megvalósítása a jogszabályi követelmé- nyeket kielégítő módon kell, hogy megvalósuljon. |
NA-003 | Naplózás | Az Audit célú naplózásoknál biztosítani kell: • a bejegyzések megőrzését az általuk hivatkozott objektu- mok rendszerben való létezésének megfelelően, időkorlát nélkül, • a naplóbejegyzések dinamikus lekérdezhetőségét az üze- meltetés számára, • a jogszabályban előírt hiteles naplózásra vonatkozó felté- teleket. Amennyiben ez egyetlen naplózási technológiával nem kielé- gíthető, akkor elfogadható olyan duplikált naplózást alkal- mazó megoldás, amely több eszközzel együttesen biztosítja a feltételeket. Pl.: a dinamikusan lekérdezhető naplózási funk- cióknál adatbázis alapú naplózás is megvalósítható a hiteles naplózáson kívül, a funkciótól függően akár duplikáltan is. |
NA-004 | Naplózás | A hiteles naplózás megvalósításához a rendszer a NISZ meg- levő Syslog NG PE alapú Graylog naplózását kell, hogy igénybe vegye, ide kell irányítani a naplófileokat. A naplóál- lományok személyes adatot nem tartalmazhatnak. A |
minimálisan megvalósítandó feladat a helyben keletkezett napló file-ok rendszeres átmásolása egy másik mappába, ami egy távoli gép felcsatolt megosztása. | ||
NA-005 | Naplózás | Amennyiben technikailag lehetséges, akkor a NISZ meglevő Syslog NG PE alapú naplózásában az aláírás és az időbélyeg- zés a GOV-CA által kibocsátott tanúsítvánnyal és időbélyeg- gel történjen. |
NA-006 | Naplózás | A rendszer köteles elvégezni az átvett dokumentumokon vég- zett valamennyi műveletnek olyan megoldással történő nap- lózását, amely az utólagos észlelhetetlen módosítás lehetősé- gét kizárja. |
NA-007 | Naplózás | A rendszer Rendszernaplójában alkalmazás szinten minden szerveroldali naplóeseményt rögzíteni kell a műveletek rész- leteiről, hibákról, kivételekről. Kifejezetten rögzíteni kell az alkalmazáspéldányok és a naplózási funkció elindulását, és leállását. Valamennyi önálló naplózást megvalósító infrastrukturális elemnél (alkalmazás szerver, load balancer, stb.) biztosítani kell a rendszernaplóba való becsatornázás lehetőségét, és az egyéb követelményekkel összhangban ezeket a bekötéseket meg kell valósítani. A Rendszernapló esetében biztosítani kell, hogy minden az alkalmazásban bekövetkező kivételről a naplózáson kívül ri- asztást is küldjön a rendszer a központi monitoring rendszer felé. |
NA-008 | Naplózás | Az Audit naplóban adattartalmi szempontból az alábbi külön- böző naplózási típusokat kell megvalósítani: • Általános Audit napló: Tartalmaznia kell a többi specia- lizált audit napló típusba be nem sorolható esetekben a következő eseményeket: • a naplózási funkció elindulása és leállítása, • tranzakció szinten megvalósuló adatmódosítások, bele- értve a konfigurációs módosításokat is, • állapotváltozások, • bejelentkezések (sikeres/sikertelen), • kapcsolódó rendszerek bekérdezését • stb. • Fájltárolási Audit napló: a tárolt fájlokhoz kapcsolódó műveletekkel kapcsolatos eseményeket tárolja, • Biztonsági napló: a rendszer integritásával és elvárt mű- ködésével kapcsolatban észlelt bármely hiba, valamint a különböző hozzáféréssel kapcsolatos biztonsági |
események naplózására szolgáló naplótípus. (Pl.: a rend- szeradminisztrációs paraméterekkel, jogosultságokkal kapcsolatos változtatásra irányuló műveletek, a metaada- tok változtatására irányuló műveletek és azok eredmé- nye.) | ||
NA-009 | Naplózás | Általános elvárás, hogy a naplózás keretében a rendszer a naplóbejegyzésekben gyűjtsön be elegendő információt ah- hoz, hogy ki lehessen mutatni, hogy milyen események tör- téntek, miből származtak ezek az események, és mi volt ezen események kimenetele. Amennyiben a követelményekben felsorolt adattartalom, eseménydefiníciók és felsorolások együttese ezt nem biztosítja, akkor a rendszertervezés kereté- ben ezeket pontosítani szükséges. A naplóban az elvégzett műveletekkel együtt minden esetben tárolni szükséges a végrehajtó személy, vagy automatikus rendszerfolyamat beazonosíthatóságához szükséges adatokat és a műveletvégzés idejét. |
NA-010 | Naplózás | Személyes adat és biztonsági szempontból érzékeny informá- ciók egyetlen naplózási típusban sem rögzíthető. |
NA-011 | Naplózás | A helyben tárolt naplóba történő betekintés csak és kizárólag az arra felhatalmazott személyek részére legyen megengedett. |
NA-012 | Naplózás | A helyben tárolt naplóinformációk védelme érdekében a rendszernek meg kell védenie a naplóinformációkat és a napló kezelő eszközöket a jogosulatlan hozzáféréssel, módo- sítással és a törléssel szemben. A filerendszeri védelem NISZ feladat, de ajánlattevőnek meg kell adni, hogy mely mappá- kat/fileokat kell védeni. |
NA-013 | Naplózás | A rendszer tegye lehetővé a naplók időszakos archiválását a megfelelő teljesítmény fenntartása érdekében. |
NA-014 | Naplózás | A rendszernek biztosítania kell a felhasználók tevékenységé- ről szóló jelentések elkészítését (kérésre, illetve igény esetén ütemezetten, automatikusan, vagy alkalmazásbeli rendelle- nességek esetén esemény-vezérelten). |
NA-015 | Naplózás | A naplózás részletes tervezésekor az alábbi őrzési/archiválási feltételeket figyelembe véve kell méretezni és kialakítani a konkrét megoldást: • A Rendszernapló a NISZ Zrt. Archiválási Szabályzata szerint a keletkezését követő 12-24 hónapig megőrzendő üzemeltetési, hibakeresési célból. • Az Audit napló dinamikus leválogathatóságot biztosító része, párosítható kell, hogy legyen mind a kapcsolódó tárolt fájlokkal, a törlésre kerülő fájlokkal együtt töröl- hető legyen. A várhatóan nagy elemszámú naplóállo- mány tárolására olyan technikai megoldást kell alkal- mazni, amely támogatja az adatok hatékony visszakere- sését időszak, eseménytípus és felhasználó azonosító |
alapján, valamint az elavult/ritkán igényelt naplóadatok részleges archiválását, és visszatöltését. • Az audit naplóhoz kapcsolódó hiteles naplóállományok megőrzése a jövőbeli tárolási költségek függvényében az állományok tárolási idejét is jelentősen meghaladhatja bi- zonyítási célokból, így tervezési szempontból korlátlan megőrzési időre kell tervezni. Ennek érdekében biztosí- tani kell a hiteles naplóállományok rendszeren kívüli tá- rolásának lehetőségét. | ||
NA-016 | Naplózás | A rendszer működését illetően kifejezett igény, hogy napló- zatlan adatmódosítás nem történhet. |
NA-017 | Naplózás | A rendszer naplóforrásait úgy kell kialakítani és konfigurálni, hogy biztosított legyen valamennyi naplóforrás bejegyzései- nek időbeli szinkronitása a NISZ-es időszerver szolgáltatás- hoz. |
NA-018 | Naplózás | A naplóbejegyzések továbbításakor biztosítani kell, hogy megbízható adatátviteli csatornán történjen. A rendszeren kí- vülre naplóállományok csak biztonságos SSL csatornán ke- resztül továbbíthatóak. |
NA-019 | Naplózás | A naplózásra vonatkozóan az alábbi dokumentációs követel- ményeket kell teljesíteni: • A tervezéskor várható hibajelenségekről és hibaüzenetek- ről részletes leírást és hibakezelési útmutatót kell készíteni az üzemeltetői kézikönyvben. • A tesztterveknek valamennyi naplózási típus tesztelését tartalmaznia kell. |
NA-020 | Naplózás | A rendszert - a tervezéstől az átadás-átvételig - folyamatában kell felkészíteni a SZEÜSZ jogszabályi megfelelést vizsgáló, zárt rendszerre vonatkozó auditra. Az auditra felkészített rendszer minősítése külső auditor bevonásával a folyamat vé- gén történik. |
Biztonsági követelmények
Azono- sító | Megnevezés | Leírás |
BI-001 | Biztonsági osz- tályba sorolás | A megvalósítandó rendszernek a vonatkozó törvény- ben foglalt előírásokból a 3-as biztonsági osztálynak (bizalmasság – 3, sértetlenség - 3, rendelkezésre állás - 3) megfelelő logikai intézkedések követelményeit kell teljesítenie. |
BI-002 | Integrált védelmi mechanizmusok il- letéktelen haszná- lat ellen | A rendszernek támogatnia kell saját védelmi mechaniz- musokat az ügyintézési csatorna folyamatos lefogla- lása ellen, túlterhelésének megakadályozására. Az |
alábbiakra minimálisan szükség van (paraméterezhető, opcionális módon): • automatikus felhasználói azonosító zárolás többszöri (paraméterezhető számú) sikertelen kapcsolatfelépí- tési kísérletet követően, és riasztás küldése a funkci- onális rendszer-adminisztrátornak és üzemeltető személyzetnek | ||
BI-003 | Rendszerbiztonsági terv | Ajánlattevő feladata Rendszerbiztonsági terv készítése, mely tartalmazza min. az alábbiakat: • az elektronikus információs rendszer hatókörét, alapfeladatait (biztosítandó szolgáltatásait), bizton- ságkritikus elemeit és alapfunkcióit; • az elektronikus információs rendszer és az általa ke- zelt adatok jogszabály (41/2015 BM rendelet) sze- rinti biztonsági osztályát; • az elektronikus információs rendszer működési kö- rülményeit és más elektronikus információs rendsze- rekkel való kapcsolatait; • az elektronikus információs rendszer biztonsági kö- vetelményeit; • a követelményeknek megfelelő aktuális vagy terve- zett védelmi intézkedéseket |
BI-004 | Paraméterezési fo- lyamat | A paraméterezési folyamatot dokumentálni kell. A do- kumentumban szerepeltetni kell a paraméterezés során: • alkalmazott szabványokat és alkalmazott eszközöket • alkalmazott speciális eszköz opciókat és konfigurá- ciókat • végrehajtott változásokat |
Azonosító | Megnevezés | Leírás |
FB-001 | Fizikai biztonság | A 41/2015 BM rendelet Fizikai védelmi intézkedései szerint. |
Azonosító | Megnevezés | Leírás |
AB-001 | Adatvédelmi, adatbiztonsági jogszabályokat, alapel- veket nem sértő technikák alkalmazása. |
1.1.1.3. Az adatok elérése
Azonosító | Megnevezés | Leírás |
V-001 | Vírusvédelem | A rendszer kialakítása során gondoskodni kell a rendszer kártékony kódok elleni védelemről. A befogadott fájlokat -amennyiben van ilyen- ellen- őrizni kell, és amennyiben kártékony kóddal fertőzött, akkor el kell utasítani a befogadását („megsemmisítés”). |
V-002 | Vírusvédelem | A kártékony kód (vírus) ellenőrző komponenst üzemelte- tési okokból egy lazán csatolt önállóan skálázható réteg- ben kell megvalósítani, az alkalmazásszerverektől füg- getlenül. A felhasználásra kerülő vírusellenőrző szoftvert a megrendelő biztosítja, az ehhez történő integrációt szükséges megvalósítani. |
V-003 | Adatelérés | Hozzáférés az adattároló réteghez: A munkaállomásokon futó kliens-oldali szoftverkomponens (megjelenítő réteg) csak a szerver-oldali szoftverkomponens (közbenső ré- teg, üzleti logika) közvetítésével férhet hozzá a szintén szerver-oldali adatbázis-kezelő szoftverhez (RDBMS, adattároló réteg). |
V-004 | Adatelérés | A megjelenítő és az adattároló réteg között nem létesít- hető közvetlen kapcsolat. |
V-005 | Adatelérés | Az adatok elérhetőségét jogosultsághoz kell rendelni, a hozzáféréseket naplózni kell. |
1.1.1.4. Azonosítás
Azonosító | Megnevezés | Leírás |
AZ-001 | Azonosítás | Az IT biztonsági jogszabályi követelmények szerint min- den rendszernek egyedileg azonosítania és hitelesítenie kell a szervezet felhasználóit, a felhasználók által végzett tevékenysége(ke)t. Ennek biztosítása érdekében az auten- tikációs követelményekhez kapcsolódva a felhasználóke- zelést úgy kell kialakítani, hogy a kapcsolódó rendszerek felhasználó kezelése és az Üzemeltetői Felület felhasz- náló kezelése minden tekintetben elkülönüljön egymástól. |
1.1.1.5. Jogosultság
Azonosító | Megnevezés | Leírás |
J-001 | Jogosultságok | Nemcsak a felhasználói felületről érkező szolgáltatás ké- relmi igények esetén kell autentikációt, majd autorizációt végezni, de az interfészek oldaláról is szükséges ellen- őrizni a küldő (vagy fogadó) oldal jogosultságát. Ebben az esetben nem szükséges a személy szintű azonosítás, elégséges lehet egy adatvédelmi szempontból megfelelő biztonságú. |
J-002 | Jogosultságok | Nemcsak az adatkezelők oldaláról kell a személyes ada- tok védelmét biztosítani, de hasonló módon, az adatfel- dolgozói (rendszerüzemeltetők) személyzet is csak felha- talmazással férhet hozzá ezekhez az információkhoz. |
J-003 | Jogosultságok | A rendszerhez csak azonosított, érvényes, hitelesített fel- használói azonosítóval/fiókkal ellátott felhasználók fér- hetnek hozzá. |
1.1.1.6. Tárolás
Azonosító | Megnevezés | Leírás |
T-001 | Rögzítés, tá- rolás | Az alkalmazás tegye lehetővé, hogy az adatok bevitele, rögzítése csak egyszer történjen, és ne legyen szükség is- mételt adatbevitelre. A rögzített adatok minden esetben legyenek konzisztensek (egy módosított adatból esetlege- sen származtatott adat minden esetben automatikusan frissüljön, és ellentmondásos adat együttesek ne fordulja- nak elő egyetlen állapotban sem). |
1.1.1.7. Megőrzés, törlés
Azonosító | Megnevezés | Leírás |
SD-001 | Selejtezés | A rendszernek képesnek kell lennie a mentett adatok (adat- bázisok, kapcsolódó adatok, stb.) ütemezett selejtezésére oly módon, hogy biztosítsa, hogy az adatok csak a jogsza- bályilag előírt időtartamig tárolódjanak a rendszerben. |
SD-002 | Selejtezés | A rendszer képes kell legyen selejtezési modell kezelésére, amellyel megvalósítható, hogy a rendszer bizonyos adata- ira, adatcsoportjaira különböző megőrzési időszakokat le- hessen előírni. |
Azonosító | Megnevezés | Leírás |
ÜB-001 | Helyreállítási terv | A rendszerhez szükséges katasztrófa utáni helyreállítási tervnek részletesen ismertetnie kell a tárolt adatok össze- függéseit, a helyreállítási tevékenységek egymásutánját, a visszaállítás helyességét bizonyító eljárásokat. |
Logikai architektúrával kapcsolatos követelmények
Azonosító | Megnevezés | Leírás |
LAK-001 | A szállított alkalmazás legyen képes kezelni több adat- bázist. |
1.1.1.8. A rendszer felépítése, modularitása
Azonosító | Megnevezés | Leírás |
MOD-001 | A moduláris felépítésnek biztosítania kell a szoftverrend- szer hatékony továbbfejleszthetőségét, módosíthatóságát a meglévő, jól bevált modulok (kódok) újrafelhasználhatósá- got, újhasznosíthatóságát. | |
MOD-002 | Az alkalmazás legyen képes kezelni, ha egy-egy modul át- menetileg nem elérhető. Ilyen helyzetben ne omoljon össze az alkalmazás. |
1.1.1.9. Szoftver-architektúra
Azonosító | Megnevezés | Leírás |
SA-001 | Az Ajánlattevő csak olyan, más forrásból származó szoftvertermékeket, ill. dokumentációt használhat, me- lyek szabad felhasználásúak vagy az Ajánlattevő rendel- kezik annak licencével. | |
SA-002 | A paraméterezést úgy kell elvégezni, hogy az Ajánlatte- vőnél életbe léptetett verziókezelési és frissítési szabá- lyozásokhoz, folyamatokhoz illeszkedjen | |
SA-003 | Az üzemeltetési kézikönyv tartalmazza a konfigurációs beállításokat, melyek úgy kerülnek kialakításra, hogy a rendszer csak a szükséges szolgáltatásokat nyújtsa és ki- tér azokra a funkciókra, portokra, protokollokra, szolgál- tatásokra, szoftverekre, melyek használatát korlátozni, vagy tiltani kell. |
1.1.1.10. Felhasznált kész komponensek
Azonosító | Megnevezés | Leírás |
KK-001 | Az Ajánlattevőnek olyan konfigurációt kell meghatároz- nia, ami csak a legszükségesebb szolgáltatásokat tartal- mazza és csak a minimális erőforrásokat veszi igénybe. Ez azt jelenti, hogy csak olyan szolgáltatások futhatnak, amikre feltétlenül szükség van és olyan paraméterekkel, ami szükséges a működéshez. Az Ajánlattevő az Üzemel- tetési kézikönyvben részletesen leírja e szolgáltatásokra vonatkozó konfigurációs beállításokat. |
1.1.1.11. Portolhatóság, platformfüggőség
Azonosító | Megnevezés | Leírás |
PP-001 | Platform | A külső ügyfelek számára biztosított alkalmazások nem kötődhetnek konkrét kliens-oldali operációs rendszerhez. |
1.1.1.12. Bővíthetőség, skálázhatóság
Azonosító | Megnevezés | Leírás |
BS-001 | Rendelkezésre ál- lás | A rendszerek funkcionalitása okán folyamatosan elér- hetőnek kell lennie a végfelhasználók számára. Az el- várt folyamatos (7/24) elérhetőség teljesítéséhez a rendszernek nagy megbízhatóságúnak kell lennie. A rendszer megbízhatósága alatt • a rendelkezésre állás, • a robusztusság, • az adatintegritás és konzisztencia szempontjainak történő megfelelést értjük. |
BS-002 | Robusztusság | A robusztusság alatt értendő, hogy a rendszer alkotó- elemeiben történő bárminemű meghibásodás nem be- folyásolhatja negatívan a többi alkotóelemének |
folyamatos működését. Továbbá egy új kapcsolódó rendszer illesztése nem lehet negatív hatással a mű- ködő rendszerre. | ||
BS-003 | Skálázás | Az rendszert úgy kell megtervezni és létrehozni, hogy annak minden lényeges komponense skálázható le- gyen. Az üzemeltetés során, a rendszer kapacitásának a terheléssel arányosan növelhetőnek kell lennie, a rendszer felépítésének módosítása nélkül. Ezért kiemelt figyelmet kell fordítani: • az adatbázis méret növekedés, • a tranzakciószám emelkedés, • a felhasználói szám növekedés kezelésére. |
BS-004 | Állapotmentesség | A web szolgáltatások állapotmentesek legyenek. Az állapotmentesség a munkamenetet (session) alkal- mazó web alkalmazásoknál nem követelmény, de azok megfelelő kezeléséről (például session replikáció web szerver klaszterben vagy sticky session load ba- lancer alkalmazása) gondoskodni kell. |
BS-005 | Bővíthetőség | A rendszer tervezése és kialakítása során figyelembe kell venni a bővíthetőség és módosíthatóság követel- ményeit, mivel az elvárt funkcionalitásban változások lehetnek, mind a belső szabályozás, mind pedig a jog- szabályi háttér változása okán, amely következtében a rendszer környezete, kapcsolódó rendszerek követel- ményei is változhatnak. A rendszer funkcionalitása le- gyen könnyen, egyszerűen megváltoztatható, illetve szükség esetén könnyen kiterjeszthető, bővíthető. |
1.1.1.13. Szolgáltatási szint
Azonosító | Megnevezés | Leírás |
SZ-001 | Szolgáltatási szint | Az adatvagyon megőrzése szempontjából kritikus elemek tekintetében a rendszer geo-redundáns megvalósítást al- kalmazzon. |
SZ-002 | Szolgáltatási szint | A klaszterezett környezet és a több telephelyes működés során a node-ok és a telephelyek közötti adat szinkronizá- ciót a KAK infrastrukturális szinten biztosítja a működte- téshez szükséges funkciókkal. Az paraméterezéskor tekintettel kell lenni ezek technoló- giai kötöttségeire (pl.: Oracle RAC kompatibilitás), de a telephelyek közötti váltásra, szinkronizálásra nem kell eszközöket és támogató logikát fejleszteni. Egy telephelyen belül az aktív klaszter elemek közötti adatmegosztást (például webes alkalmazások esetén az esetleges session replikációról) a rendszernek kell megva- lósítania. |
1.1.1.14. Jogosultságok
Azonosító | Megnevezés | Leírás |
JOG-001 | Jogosultságok | Biztosítani kell az egységes jogosultsági modellel kap- csolatos integrációt, a kapcsolatot a címtár rendszerekkel. |
JOG-002 | Jogosultságok | A felhasználónév/jelszó típusú azonosítás mellett a rend- szer tegye lehetővé az egyéb típusú, hardveres authenti- kációs módszerek jövőbeni alkalmazhatóságát (pl. digitá- lis aláírás és időbélyegző kezelés, jelszó támogatás, chip- kártyás azonosítás). |
JOG-003 | Jogosultságok | A jogosultságokat többszintű modellben kell reprezen- tálni (pl. jog-szerepkör-user), hogy azok karbantartása, felhasználókhoz rendelése minél egyszerűbb legyen. A szerepkör alapú jogosultságkezeléshez AD integrációt kell megvalósítani |
JOG-004 | Jogosultságok | A rendszer tegye lehetővé a felhasználók többdimenziós csoportosítását (szerepkörök/felhasználói profilok, szer- vezeti hierarchia/osztályok). A jogosultsági rendszernek legalább szerep/profil alapú kialakítást kell támogatnia, valamint az adatok megtekintése, kezelése tekintetében biztosítania a szervezeti hierarchia és TS figyelembevéte- lét, és ennek során különös tekintettel lennie az egyes megtekintett adatok személyes adat jellegére, azaz a vo- natkozó adatvédelmi jogszabályokra. |
JOG-005 | Jogosultságok | A jogosultságmodell elsősorban szerepkörökön keresztül szabályozza a szolgáltatások, funkciók elérhetőségét; ugyanakkor lehetőséget kell adni bizonyos adatoktól függő hozzáférés beállításra is. |
1.1.1.15. Központi menedzselhetőség
Azonosító | Megnevezés | Leírás |
KM-001 | A rendszernek illeszkednie kell az Ajánlattevő webser- vice-en keresztül elérhető központi ügyintézői jogosult- ságkezelőjéhez, mely a felhasználókhoz rendelhető pon- tosan körülhatárolt szerepköröket definiál. Ajánlatkérő a követelmény teljesítéséhez átadja a jogosultságkezelő szolgáltatás fejlesztői dokumentumait | |
KM-002 | Az alkalmazásnak lehetővé kell tennie a jogok és szerep- körök kapcsolatainak felhasználói felületről történő kar- bantartását és lekérdezését, a központi jogosultságkezelő- höz illesztetten. | |
KM-003 | Ajánlattevő ajánlatában mutassa be a szállítani kívánt al- kalmazás illeszkedését az ajánlatkérő által meghatározott központi jogosultságkezelőhöz. |
Integrációs követelmények
Azonosító | Megnevezés | Leírás |
IK-001 | Integráció | A rendszer a működése során számos külső adatforrásból származó tartalmat használ fel és külső rendszerek szá- mára adatokat szolgáltat. Az éles üzembe helyezéshez szükséges feltétel, hogy az Ajánlattevő az későbbiekben definiált tartalmakat a rendszerbe integrálja: biztosítsa a felhasznált adatok rendelkezésre állását és adatok továb- bítását külső rendszerek felé. |
IK-002 | Integráció | Az integráció során ügyelni kell arra, hogy a rendszer optimalizált sávszélesség-igénnyel működjön. |
IK-003 | Integráció | A külső rendszerekkel kapcsolatot tartó interfészek leíró- fájlok alapján legyenek konfigurálhatóak. A kapcsolat- tartás során alkalmazzanak szabványos megoldásokat. |
Azonosító | Megnevezés | Leírás |
RK-001 | Integráció | A rendszernek a részletesen meghatározott interfészeken, rendszerkapcsolatokon túlmenően integrálódnia kell a meglévő informatikai alaprendszerekkel (pl. levelezési rendszer). |
Felhasználói felülettel kapcsolatos követelmények
Azonosító | Megnevezés | Leírás |
FFK-001 | Felhasználói felület | A kialakított rendszer minden grafikus felhasználói felü- lettel rendelkező funkciója legyen képes zavartalanul működni végfelhasználói kliens oldalon az alábbi feltéte- lek szerint: • Az alkalmazás felhasználói környezetének meg- valósítása, operációs rendszer és böngésző plat- form függetlennek kell lennie. • A rendszernek az Internet Explorer, Firefox, Chrome böngészők ajánlatkérő által meghatáro- zott verzióival kell működnie (azonos felhaszná- lói élményt nyújtva). • Az alkalmazás vékony kliens oldalon telepítést ne igényeljen. |
FFK-002 | Felhasználói felület | A felhasználói felület támogassa a korszerű adatbeviteli eszközöket (pl. érintőképernyő), a rendszert lehessen bil- lentyűzettel és egérrel is kezelni. Az Ajánlattevő javasol- jon felhasználói adatbeviteli eszközöket, a javaslatát in- dokolja. |
Azonosító | Megnevezés | Leírás |
ERG-001 | Ergonómia | A képernyőképek legyenek megjelenésükben és funkci- onalitásukban áttekinthetőek, logikus felépítésűek. |
ERG-002 | Ergonómia | A rendszer felhasználói felületének meg kell felelnie az 50/1999. (XI.3) EüM rendelet (a képernyő előtti munka- végzés minimális egészségügyi és biztonsági követel- ményeiről) és az EGK 90/270 EU irányelvnek – tehát, többek között lehetővé kell tennie az Ajánlatkérő szá- mára, hogy a rendszer felhasználói részére a megfelelő képernyő előtti munkavégzésre vonatkozó körülménye- ket biztosíthassa. |
ERG-003 | Ergonómia | A korszerű, felhasználóbarát felületnek valamennyi esetben, ahol ez a hatékonyságot ténylegesen támogatja, biztosítania kell segédeszközöket a felhasználói adatbe- vitel gyorsítására, hatékonyságának növelésére. Ilyenek például: az értékválasztós mezők (legördülő listák), elő- gépelésre érték felajánlás, választási lehetőségek dina- mikus, környezetfüggő szűkítése. Ilyen és ehhez ha- sonló megoldások bevezetésére lehetőséget kell biztosí- tani minden olyan űrlap, mező, felületi vezérlőelem ese- tén, amelynél a megoldás alkalmazása Ajánlatkérő fo- lyamatai szemszögéből a rendszer használatát egyszerű- síti. |
ERG-004 | Ergonómia | Az automatizmusok, segítő komponensek, intuitív fel- használást támogató mechanizmusok alkalmazása nem mehet az adatrögzítés pontosságának, megbízhatóságá- nak a rovására, így használatukat lehetőleg opcionálissá, paraméterezhetővé kell tenni. A szótárak kezelése, bő- vítése minden esetben külön jogosultsághoz legyen kö- tött. |
ERG-005 | Ergonómia | A felhasználói felületen megjelenített adatoknak a rend- szerben tárolt információkat kell tükrözniük, és azok változása esetén a felületen lévő adatoknak automatiku- san, felhasználói beavatkozás nélkül frissülniük kell. |
ERG-006 | Ergonómia | Az alkalmazás felépítésén túlmenően a felhasználói munkát segíteni kell a megfelelő (adott esetben többféle) beviteli eszköz támogatásával (azoknál a munkahelyek- nél, ahol ez hatékonyság növelő) – pl. érintőképernyő, egér/billentyűzet. A felhasználói felület legyen egységes, rendszer szerte egységes felépítési koncepciót, ergonómiát, struktúrát, felhasználási logikát támogasson. |
ERG-007 | Karakterkész- let | A rendszer az UTF-8 szabvány szerint kezelje az űrla- pok kitöltésére használható karaktereket mind bevitel, mind megjelenítés, mind pedig betűrend szerinti rende- zés tekintetében. |
Azonosító | Megnevezés | Leírás |
L-001 | Nyelvi ele- mek | A rendszer felhasználói felületeinek nyelve a felhasználó által választhatóan magyar vagy angol legyen. |
L-002 | Nyelvi ele- mek | A rendszer adminisztrációs felületeinek nyelve magyar vagy angol legyen. |
L-003 | Nyelvi ele- mek | A rendszer felhasználói felülete biztosítson egyszerű módszert a felület nyelvének megváltoztatására. |
L-004 | Nyelvi ele- mek | A felhasználói felületen minden elem (feliratok, menük, üzenetek) egységes módon, a kiválasztott (alapértelme- zett) nyelven jelenjen meg. |
L-005 | Nyelvi ele- mek | A rendszer minden komponense támogassa a magyar ka- rakterek tárolását, kezelését és megjelenítését. E tekintet- ben a rendszer legyen egységes. |
L-006 | Nyelvi ele- mek | A felhasználói felületen megjelenített adatok formátuma legyen egységes, függetlenül attól, hogy az adatot a fel- használói felületen rögzítik vagy külső rendszerből szár- mazik. |
L-007 | Nyelvi ele- mek | Hiba esetén a felhasználók számára értelmezhető, a kivá- lasztott (alapértelmezett) nyelven hibaüzenetet jelenítsen meg. |
L-008 | Nyelvi ele- mek | Legyen támogatott és a magyar számformátum (tizedes- vessző és esetleges elválasztó pontok, ezres csoportosí- tás). |
L-009 | Nyelvi ele- mek | Legyen a magyar dátum-, és idő-formátum használata tá- mogatott. |
L-010 | Nyelvi ele- mek | Dátum típusú adatok bevitele esetén mindig legyen a for- mátum-megfelelésre vonatkozó ellenőrzés. |
Azonosító | Megnevezés | Leírás |
HK-001 | Adatok ellen- őrzése | A kitöltés helyességének teljes körű vizsgálata, a hibás adatok egyértelmű jelzése a kitöltés közben történjen. Az ellenőrzés oly módon legyen megoldva, hogy az adat- rögzítés folyamatát ne akadályozza. |
HK-002 | Állapot kijel- zése | A felület adjon egyértelmű jelzést, ha adatokra vár (kom- munikál más komponensekkel), vagy valami okból nem képes felhasználói beavatkozást fogadni (a központi rendszerek nem elérhetőek). |
HK-003 | Folyamatok megszakítása | A 2-5 másodperces időhorizonton túlnyúló kötegelt mű- veletek esetén folyamatjelzést kell biztosítani, leállítási lehetőséggel (a leállítási lehetőség bizonyos helyzetekben korlátozott lehet). |
Azonosító | Megnevezés | Leírás |
H-001 | Súgó | A rendszernek a felhasználói munkaállomásokról elérhető, alkalmazásba épített, helyzetérzékeny interaktív súgót kell biztosítania, amely a minimálisan felhasználói kéziköny- vet/felhasználáshoz szükséges információkat tartalmazza. |
H-002 | Súgó | A súgó nyelve egyezzen meg a kiválasztott nyelvvel. |
H-003 | Súgó | Gyorssúgók megjelenítése a kontrollok használatának és az adatmezők értelmezésének támogatására. |
Üzemeltetési követelmények
Azonosító | Megnevezés | Leírás |
FT-001 | Hibakezelés és hibatűrés | Valamennyi szinten (végfelhasználói, funkcionális admi- nisztrátori, üzemeltetői), hiba esetében a rendszer a fel- használók számára értelmezhető, magyar nyelvű hibaüze- netet küldjön. A központi monitoring rendszerben riasztás keletkezzen az eseményről. |
FT-002 | Hibakezelés és hibatűrés | Minden hibajelenség kerüljön naplózásra. |
FT-003 | Hibakezelés és hibatűrés | A hibajelenségekről és hibaüzenetekről részletes leírás és hibakezelési útmutató álljon rendelkezésre. |
Azonosító | Megnevezés | Leírás |
K-001 | Mentési ter- vek | Napló táblák mentési eljárásának kidolgozása |
Szállítással kapcsolatos követelmények
1.1.1.16. Szállítandó termékek
Azonosító | Megnevezés | Leírás |
TER-001 | Logikai architektúra terv | |
TER-002 | Fizikai architektúra terv | |
TER-003 | Fizikai rendszerterv | |
TER-004 | Telepítési dokumentáció | |
TER-005 | Üzemeltetési dokumentáció | |
TER-006 | Rendszerbiztonsági terv | |
TER-007 | Oktatási dokumentációk | |
TER-008 | Tesztterv | |
TER-009 | Tesztforgatókönyv | |
TER-010 | Tesztjegyzőkönyv |
1.1.1.17. Szerzői jogok
Azonosító | Megnevezés | Leírás |
SZER-001 | 3rd party | Ajánlattevőnek rendelkeznie kell a jelen dokumentumban megfogalmazott követelmények teljesítéséhez szükséges szükséges valamennyi olyan vagyoni értékű joggal (szerzői jog, védjegy, szabadalom, használati minta, ipari minta, know- how, licensz, stb., amelyek a jelen műszaki leírás keretében szállított dokumentumok, termékek, |
szoftverek és szolgáltatások vagy annak részei használatára vonatkozóan felmerülhetnek. |
1.1.1.18. Szállítandó szolgáltatások
Azonosító | Megnevezés | Leírás |
SZG-001 | Szükség szerint a leírt követelmények megvalósításához. |
Projektvezetéshez és minőségirányításhoz kapcsolódó követelmények
1.1.1.19. Módszertani követelmények
Azonosító | Megnevezés | Leírás |
MK-001 | Szabványos eszközök, módszertan alkalmazása | A projekt keretein belül Ajánlattevőtől már működő refe- renciákkal rendelkező, kész termék paraméterezését vár- juk. A bevezetés, testre szabás során esetlegesen alkalma- zott testre szabási műveletek minden esetben széles kör- ben elfogadott, szabványos, dokumentált fejlesztési mód- szertannal és eszközökkel történjen, továbbá valamennyi módosítás, igazítás és testre szabás részletesen kerüljön dokumentálásra, és megfelelően tükröződjön az Ajánlat- kérő, mint végfelhasználó részére testre szabott végfel- használói dokumentációban is. |
1.1.1.20. Tervezési követelmények
Azonosító | Megnevezés | Leírás |
TERV- 001 | Funkcionális al- kalmasság | 1. Az felparaméterezett alkalmazásnak (szoftverter- méknek) olyan funkciókat kell biztosítani, ame- lyek teljes mértékben megfelelnek a specifikáció- ban meghatározott és az azokból eredő igények- nek. 2. Az felparaméterezett alkalmazásnak (szoftverter- méknek) szolgáltatnia kell az igényeknek megfe- lelő eredményeket a megkívánt pontossággal és meg kell könnyítenie a specifikált feladatok elvég- zését. |
TERV- 002 | Teljesítmény haté- konyság | 1. A felparaméterezett alkalmazásnak (szoftverter- méknek) hatékonyan, takarékosan kell használnia a futtató környezet erőforrásait, a nagyobb terhe- lések esetén azonban képesnek kell lennie a ren- delkezésére álló erőforrások maximális kihaszná- lására is. 2. Kiemelten fontos az adatbázis-tervezés általános alapelveinek betartása: normalizálás, funkcionális függőségek, a lehető legkisebb redundanciára tö- rekvés (relációs adatbázis esetén). 3. A felparaméterezett alkalmazásnak (szoftverter- méknek) meg kell felelnie a specifikációban meg- határozott performancia elvárásoknak. |
TERV- 003 | Kompatibilitás | 1. A felparaméterezett alkalmazásnak (szoftverter- méknek) képesnek kell lennie az együttműködésre környezetével. 2. A felparaméterezett alkalmazásnak (szoftverter- méknek) hatékonyan kell ellátnia a feladatát osz- tott erőforrású környezetben is anélkül, hogy ká- ros hatással lenne az infrastruktúra többi elemére. 3. A felparaméterezett alkalmazásnak (szoftverter- méknek) a kormányzati infrastruktúrába – előre nem tervezett, illetve indokolatlan infrastruktúra fejlesztés nélkül – integrálhatónak kell lennie, ki- emelt elvárás a megrendelőnél rendelkezésre álló üzemeltetői kompetenciával és kapacitással stabi- lan működtethető technológiák használata. 4. Mindemellett azonban a paraméterezés komplexi- tását célszerű a lehető legalacsonyabb szinten tar- tani, a konkrét célt nem szolgáló, funkció nélküli összetett hierarchiák és függőségek kerülendők. |
TERV- 004 | Megbízhatóság | A felparaméterezett szoftverrendszernek tartósan a specifikációban elvárt funkcionalitást és teljesít- ményt biztosítva kell működnie. |
TERV- 005 | Biztonság | 1. A felparaméterezett szoftverrendszerben biztosí- tani kell a vele kezelt, feldolgozott és a benne tá- rolt adatok védelmét. 2. Biztosítani kell, hogy az adatokhoz csak az arra feljogosított (megfelelő jogosultsággal rendel- kező) személyek, technikai rendszerelemek fér- hessenek hozzá. 3. Adatvédelmi, adatbiztonsági jogszabályokat, alapelveket nem sértő technikák alkalmazása. 4. Magyar és Európai Uniós jogszabályok és egyéb normák figyelembe vétele (titkosítás, adatvédelem stb.). |
TERV- 006 | Karbantarthatóság | 1. A rendszert úgy kell kialakítani, hogy az könnyen javítható, módosítható legyen. 2. A rendszermodulok tesztelhetők, újrafelhasznál- hatók, a paraméterezés könnyen értelmezhető, ele- mezhető legyen. 3. Az alkalmazott technikák és technológiák semmi- lyen módon nem korlátozhatják a versenyt a ké- sőbbi módosításra, továbbfejlesztésre kiírt pályá- zat estén. 4. A meghatározott kódformázási szabályoknak való megfelelés. |
5. A paraméterezés legyen egyszerű, áttekinthető, könnyen értelmezhető, duplikációktól mentes és könnyen karbantartható. 7. Az egyes elemek szerepének, működésének meg- értését segítő commentek használata. 8. Egységes, leíró (beszédes) névkonvenciók hasz- nálata. 9. Többrétegű architektúra (pl. Prezentációs réteg, Üzleti logika réteg, Perzisztencia réteg) A szüksé- ges rétegek számát és funkcióját az egyes feladat- hoz igazítottan, többek közt a várható terhelés fi- gyelembe vételéve, a robusztusság, skálázhatóság és a hatékony, gazdaságos üzemeltethetőség érde- kében kell meghatározni. 10.Preferált a perzisztens állapot mentes üzleti logi- kai és prezentációs réteg kialakítása. Az alkalma- zás üzleti logikáját megvalósító modul rugalma- san legyen skálázható, ne kelljen az alkalmazás specifikus állapot szinkronizációt figyelembe venni a skálázás során. 11.Moduláris felépítés | ||
TERV- 007 | Hordozhatóság | A telepítési, áttelepítési, eltávolítási leírásnak aktuá- lisnak, részletesnek, folyamatszerűnek és követhe- tőnek kell lenni. Tartalmaznia kell a függőségeket és a várható kimeneteket. |
Teszteléssel kapcsolatos követelmények
Azonosító | Megnevezés | Leírás |
TESZT- 001 | Dokumentáció | Az átadás-átvétel során az alábbi, teszteléssel kapcsolatos dokumentumok leszállítása szükséges: • Fizikai rendszerterv • Tesztterv • Tesztelési forgatókönyv • Tesztesetek (manuális tesztesetek és automatizált szkriptek) • Teszt adatgyűjtemény (tesztfelhasználók, teszt- adatok, ősfeltöltés) • Tesztjegyzőkönyv • Nem funkcionális tesztelési terv (pl. karbantartha- tósági, telepíthetőségi, megfelelőségi tesztek) |
TESZT- 002 | Teszt tervezés | A teszt tervezéssel szemben elvárt NISZ oldali követel- mény, hogy a Szállítónak részleteznie kell az alábbiakat: • tesztelési módszer, különösképpen a fejlesztői tesztelést, rendszertesztelést és rendszerintegrá- ciós tesztelést • mérföldkövek, ütemezés • hatókör • leszállítandók • Tesztadatmenedzsment (tesztesetek, teszteredmé- nyek) és hibamenedzsment folyamata • teszteszközök • átadás-átvételi kritériumok (kiemelten a hibakate- góriák) |
TESZT- 003 | Teszt típusok | • Az alábbi teszttípusokat kell végrehajtani: • Komponens teszt: annak ellenőrzése, hogy az egyes részegységek önmagukban működőképe- sek-e. • Integrációs teszt (rendszer integrációs teszt): An- nak ellenőrzése, hogy az egyes modulok, alrend- szerek és a kapcsolódó rendszerek közötti műkö- dés megfelelő. • Funkcionális teszt: Annak ellenőrzése, hogy teszt rendszerre átadott rendszer az igazgatási és infor- matikai rendszertervben leírt funkciók megfele- lően működnek. • Folyamat teszt: Annak ellenőrzése, hogy teszt rendszerre átadott rendszerben a leírt folyamatok végigvihetőek. • Felhasználói teszt: Annak ellenőrzése, hogy a fe- lületről elérhető funkcionalitások a rendszer do- kumentációkban megfogalmazott követelmé- nyeknek megfelelően működnek. • Ergonómiai teszt: Annak ellenőrzése, hogy a rendszer megfelel-e az alapvető ergonómiai köve- telményeknek. • Interfész teszt: Annak ellenőrzése, hogy a rend- szer a kapcsolódó rendszerekkel kommunikálni |
képes, az interfészek mindkét oldali rendszerben megfelelően működnek. • Terheléses teszt: Annak ellenőrzése, hogy a ma- ximális (vagy azt csekély mértékben meghaladó) terhelés alatt is jól működik a rendszer. • Sebesség teszt: Annak ellenőrzése, hogy tipikus adatmennyiség esetén a rendszer kiszolgálási ideje a kritikus szint alatt marad. | ||
TESZT- 004 | Teszt végre- hajtás | A teszt végrehajtással szemben elvárt NISZ oldali köve- telmény, hogy a Szállítónak részleteznie kell az alábbia- kat: • a tesztelés konkrét végrehajtási technikáját és esz- közét • a végrehajtandó tesztlépéseket, tesztadatokat • az elvárt működést • hibakezelést, javítás módját, javítócsomagok üte- mezését • a teszt végrehajtásának dokumentálását, jegyző- könyv készítését • a tesztelés pillanatnyi állapotát (hibák száma sú- lyosság szerint, futtatott/nem futtatott tesztek ará- nya) |
TESZT- 005 | Környezetek | A Szállítóknak minden esetben alkalmazkodniuk kell a NISZ-ben elfogadott tesztkörnyezet struktúrához, amely a következő: • Fejlesztői környezet (korlátlan hozzáférés, a Szál- lító telepíti az alkalmazást/paraméterezést). • T1 – Tesztkörnyezet (Szállítók számára hozzáfé- rés kizárólag tesztelési céllal (korlátozott)), első telepítés illetve verzióváltás kizárólag az NISZ üzemeltetés által végezhető a szállítói dokumen- tációk alapján. • T2 – Integrációs Tesztkörnyezet (Szállítók szá- mára hozzáférés kizárólag tesztelési céllal (korlá- tozott)), a telepítés illetve verzióváltás kizárólag az NISZ üzemeltetés által végezhető a szállítói dokumentációk alapján. |
• Éles környezet, hozzáférés a NISZ üzemeltetési szabályai alapján A tesztesetek kidolgozásánál (kiemelten az automatizált) fokozott elvárás, hogy mindegyik tesztkörnyezetben fut- tathatónak (például tesztadatok, adatbázis és integráció hi- ányában megfelelő interfész szimulációk rendelkezésre áll) kell lenniük. | ||
TESZT- 006 | Tesztesetek | A tesztesetekkel szemben támasztott követelmény, hogy biztosítaniuk kell a reprodukálhatóságot és a pontos hiba meghatározást. Ezért az alábbi információkat tartalmaz- niuk kell: • teszteset azonosító, • teszteset név, • teszteset leírás, • szükséges előfeltételeket és függőségeket, • tesztlépéseket (elemi szinten) és végrehajtásuk el- várt eredményét, • követelmény azonosítót. Az automatikusan futtatható tesztekkel kapcsolatosan el- várás még: • a tesztkészlet egymás után többször is futtatható legyen egyéb beavatkozás (alaphelyzetbe állítás) nélkül, ezt a tesztkészletnek biztosítania kell. • a tesztkészletnek futtatás nélkül is ellenőrzésre al- kalmasnak kell lennie (megfelelően kommen- tezve minden lépés, utasítás), hogy a funkcionali- tás ellenőrizhető legyen. |
TESZT- 007 | Hibák katego- rizálása | A hibákat kategorizálni szükséges az alábbiak szerint: a) kritikus, b) súlyos, c) alacsony szintű, attól függően, hogy a tesztelés folytatása érdekében – il- letve a hibamentesség fenntartása, vagy a publikálhatóság függvényében is – milyen fontossággal kell javítani, meg- oldani. Kritikus: a rendszer (alkalmazás) egészének, jól elkülö- níthető részének, egyes alapfunkcióinak használatát lehe- tetlenné tevő probléma, vagy olyan súlyos mértékben kor- látozó hiba, hogy a rendszer, az érintett rész (alkalmazás) vagy az érintett funkció a napi tevékenység végzése során nem vehető igénybe, illetve csak olyan ésszerűtlen erőfe- szítések árán használható, amelyek gazdasági szempont- ból nem indokoltak. Ebbe a hibakategóriába tartoznak pél- dául a következők: |
-a rendszer (alkalmazás) gyakori, előre nem látható és ki nem védhető leállása, -a rendszer (alkalmazás) összeomlása, amikor a hiba fenn- állása miatt újra kell indítani az alkalmazást, -az adatbázis vagy az adatállomány súlyos sérülése, integ- ritásának, konzisztenciájának sérülése, -indokolatlan további manuális feldolgozást igénylő szitu- ációk előállása, -akadály, amely olyan súlyos hibát jelent, hogy a rendszer (alkalmazás) használata nem folytatható semmilyen mó- don, - olyan IT biztonsági hiba, mely a Megrendelő működés- ének, eszközeinek, adatainak biztonságát jelentősen ve- szélyezteti. A hiba kijavítása nélkül nem képzelhető el az éles üzemi működés. Súlyos: a hiba kihat ugyan a rendszer egyik funkciójára, mellyel adott folyamat nem vagy csak részlegesen hasz- nálható, de anélkül, hogy ezáltal a rendszer működése ösz- szességében jelentősen sérülne (pl. nem a rendszer alap- funkciója vagy nem kritikus funkciót érint stb.); a hiba a napi működést akadályozza, de a hibajavításra rendelkezésre álló időben nem befolyásolja olyan mérték- ben a munkavégzést, hogy az elérje a kritikus szintet. Alacsony: az előző kategóriákba nem sorolható, a rend- szer működését érdemben nem befolyásoló hiba. |
Szállítandó dokumentációval kapcsolatos követelmények
A dokumentációs követelmények teljesítése során, ahol ez értelmezhető, a korábban elkészült dokumentáció bővítésével és kiegészítésével kell eleget tenni a követelményeknek. Ahol ez értelmezett, ott a dokumentációt az Ajánlatkérő átadja a nyertes Ajánlattevőnek, a tulajdonjog fenntartása mellett.
Azonosító | Megnevezés | Leírás |
DOK-001 | Általános követel- mények | A rendszer tervezése, kivitelezése során keletkező, valamint az éles üzemeltetésre történő átadáshoz szükséges, jelen Műszaki leírásban leszállítandó ter- mékként felsorolt dokumentumokra vonatkozó álta- lános követelmények: • a dokumentum lapszámozott legyen; • tartalmazzon verziókezelésre vonatkozó infor- mációt; • rendelkezzen tartalomjegyzékkel; • ha a dokumentumban szereplő ábrák száma a tí- zet meghaladja, akkor rendelkezzen külön ábra- jegyzékkel; • egyértelműen azonosítható legyen a dokumen- tum készítésének dátuma és az utolsó módosítás dátuma; • tartalmazzon a szállító oldali termék minőség- biztosításra vonatkozó információt; |
• legyen jól strukturált, fejezetekre bontott; • a fejezetek azonosíthatók (pl. hierarchikus szá- mozással) legyenek; • a dokumentumban a könnyebb megértést ábrák segítsék (kiemelten a folyamatok leírása kap- csán); • a dokumentum elektronikus példányának fájl- neve feleljen meg a projekt definíciós tervben rögzített névkonvencióknak. • a dokumentum magyar nyelvű legyen | ||
DOK-002 | Formai követel- mény | Az információs rendszer dokumentálása során az alábbi pontokban részletezett formai elemeket min- den dokumentumban értelemszerűen kell szerepel- tetni. a. Dokumentum adatlap: i. a Dokumentum címe, ii. tárgya, iii. fájl neve és verziója, iv. Dokumentum típusa, v. Dokumentum verziószáma, vi. Dokumentum státusza, vii. Dátum, viii. Készítő, Ellenőr. ix. verziószám, x. státusz, b. minősítés, c. lapszámozás, d. Tartalomjegyzék, e. Tárgymutató. |
DOK-003 | Formátum | Az információs rendszer dokumentációjának egy eredeti nyomtatott példányban és szerkeszthető Mic- rosoft Word és nyomtatható PDF formátumban elektronikus formában kell rendelkezésre állnia |
DOK-004 | Tartalmi elvárások | Szállítandó dokumentáció tartalma a jelen dokumen- tum utolsó fejezetében csatolt, előállítandó doku- mentumokban foglaltaknak megfelelően kerüljön összeállításra. |
DOK-005 | Logikai architektúra terv | Leírja a tervezett megoldás főbb logikai komponen- seit és azok kapcsolatait, specifikálja a megvalósí- tandó szolgáltatásokat (használati eseteket), és is- merteti a működési folyamatot, a felhasznált adatkö- röket. |
DOK-006 | Fizikai architektúra terv | A terv a megvalósítandó rendszer fizikai reprezentá- cióját írja le, dokumentálja a felhasznált hardver- és szoftverelemeket, a LAN és WAN hálózat konfigu- rációját. |
DOK-007 | Fizikai rendszerterv | Azüzleti funkciók fizikai megvalósításának alapjául szolgáló dokumentum. A dokumentum olyan részle- tességgel írja le a megvalósítandó rendszert, hogy további tervezési döntésekre a megvalósítás során ne legyen szükség. A felhasznált dobozos termékek esetében dokumen- tálja a konfigurációs paramétereket. |
DOK-008 | Rendszerbiztonsági terv | Célja, hogy bemutassa a rendszerrel kapcsolatos biztonsági elő- írásokat és biztonsági funkciókat, összhangban a hatályos jog- szabályokban foglaltakkal. Sablont az Ajánlatkérő fogja szerző- déskötést követően biztosítani. |
DOK-009 | Tesztterv | A dokumentum bemutatja a tesztelés folyamatát, a rendszer megvalósítási és átadási fázisai során vég- rehajtandó teszttípusokat, a teszttípusokhoz kapcso- lódó feladatokat, előfeltételeket és erőforrás igénye- ket, valamint a tesztelési folyamatban érintett sze- repköröket és feladatköröket. Minden, a követelmény-specifikációban meghatáro- zott követelményre kell tesztesetet létrehozni, meg- határozva, hogy mely feltételek teljesülése esetén te- kintjük sikeresnek a tesztet. |
DOK-010 | Tesztforgatókönyv | Leírja részletesen azokat a teszteseteket, amelyeket a tesztelés során el kell végezni. Minden teszteset és tesztscript, automatizáló script megoldások a tesztforgatókönyvvel együtt kell ké- szüljenek és szállítódjanak. |
DOK-011 | Teszt jegyzőkönyv | A Tesztelési jegyzőkönyvek igazolják, hogy a tesz- telés a terveknek megfelelően megtörtént. |
DOK-012 | Üzemeltetési doku- mentáció | Az éles üzembe helyezés utáni zökkenőmentes mű- ködés biztosításához szükséges tevékenységeket tar- talmazó dokumentum. Napi, heti üzemeltetési feladatokhoz szükséges mi- nimális jogosultsági szint definiálása. |
DOK-013 | Telepítési doku- mentum | Az éles üzembe helyezés és tesztrendszer felépítésének lebo- nyolításához kapcsolódó tevékenységeket tartalmazó dokumen- tum a következő tartalmi elemekkel: • Ajánlott hardverkövetelmények meghatáro- zása • Kapcsolódó egyéb rendszerek, rendszerkompo- nensek kapcsolatainak és konfigurációjának le- írása: • A telepítéshez szükséges telepítő csoma- gok pontos neve, verziószáma • Diszkterületek megosztása • Fájl rendszer típusa, mérete • A telepítés szükséges előfeltételeinek, a te- lepítendő egyéb szoftverkomponensek le- írása; |
• A telepítés lépéseinek pontos leírása • A telepítés utáni konfigurációs feladatok leírása • Sikertelen telepítés esetére a visszaállítás lépéseinek leírása • Az alkalmazás konfigurációja során hasz- nálható összes konfigurációs paraméter le- írása • Az alkalmazás eltávolításának lépései • Milyen funkcionalitás tesztelésével lehet ellenőrizni a telepítés sikerességét | ||
DOK-014 | Oktatási dokumen- tációk | Ajánlattevőnek el kell látnia a kulcsfelhasználók, üzemeltetők tantermi (NISZ telephelyén) vagy on- line oktatását (utóbbi a preferált), melyhez oktatási tervet, jegyzőkönyvet kell készíteni az Ajánlatkérő tartalmi elvárása szerint. Az oktatási terv minimálisan tartalmazza: • az oktatandó témát • a tervezett időráfordítást • a tervezett hallgatói létszámot • a helyszínt • az oktatás időpontját. • oktatási anyag (amely alkalmas a végfel- használók oktatására is) A későbbi végfelhasználók oktatása „Train to trainer” módszer- rel történik, melyhez nyertes Ajánlattevőnek oktatási anyagot kell készítenie. |
Oktatással, betanítással kapcsolatos követelmények
Azonosító | Megnevezés | Leírás |
OKT-001 | Ajánlattevőnek el kell látnia a kulcsfelhasználók, üzemel- tetők tantermi (NISZ telephelyén) vagy online oktatását (utóbbi a preferált), melyhez oktatási tervet, jegyzőköny- vet kell készíteni az Ajánlatkérő tartalmi elvárása szerint. Az oktatási terv minimálisan tartalmazza: • az oktatandó témát • a tervezett időráfordítást • a tervezett hallgatói létszámot • a helyszínt • az oktatás időpontját. • oktatási anyag (amely alkalmas a végfelhasználók oktatására is) A kulcsfelhasználók oktatása kapcsán maximum 10 fővel, az üzemeltetők oktatása kapcsán maximum 10 fővel kell számolni. | |
OKT-002 | A későbbi végfelhasználók oktatása „Train to trainer” mód- szerrel történik, melyhez nyertes Ajánlattevőnek oktatási anyagot kell készítenie. Ajánlattevő ajánlatában mutassa be a tervezett tananyag főbb elemeit. |
Éles indulással kapcsolatos követelmények
Azonosító | Megnevezés | Leírás |
IND-001 | Éles beveze- tés | A rendszer éles bevezetésére akkor kerülhet sor, ha a rendszer egészére vonatkozó próbaüzem(élesre való tele- pítés utáni működés ellenőrzés, annak megfelelőségének viszgálata a követelmények alapján) sikeresen lezárul. |
Jótállás, támogatás és követés követelményei
Azonosító | Megnevezés | Leírás |
GAR-001 | Jótállás | A projekt során szállított rendszer valamennyi összete- vőjére (szoftver-komponensek és azok esetleges új ver- ziói, paraméterezés, egyéb eszközök) az Ajánlattevő 18 hónap jótállást vállal. Az Ajánlattevő a jótállás kapcsán felmerülő szolgáltatásokat a rendszer telepítésének hely- színén teljesíti. |
GAR-002 | Bevezetést követő szakértői támogatás – konszolidációs időszak | A rendszer bevezetését követően Ajánlattevő rendszeres konzultációs megbeszéléseket, igény esetén szakértői se- gítséget nyújt az Ajánlatkérő részére az opcionális keret terhére. |
GAR-003 | Helpdesk | Az Ajánlattevőnek a teljes jótállási időszakban harma- dik szintű ügyeletet (szakértői szintű termék és szolgál- tatás támogatás) kell biztosítania a garanciális hibajaví- tásokhoz kötődően. |
GAR-004 | Hibakategóriák | A jótállási időszakban is a fentiekben szerepeltett hiba- kategóriák, illetve azokhoz tartozó elhárítási idők az irányadóak. |
Infrastruktúra
A rendszer a Kormányzati Adatközpontban (KAK) fog elhelyezkedni. KAK-nak nevezzük a két új telephelyen létrejövő géptermet. A géptermek feladata a KAK Felhő befogadása, valamint a felhőbe nem integrálható rendszerek számára host- ing-szerű elhelyezés biztosítása.
A KAK Felhő egy privát informatikai felhő, mely IaaS, PaaS, SaaS szolgáltatásokat nyújt. A kialakítandó rendszereknek integrálhatóknak kell lenniük a KAK Felhő által nyújtott szolgáltatásokkal. A szolgáltatásokhoz történő kapcsolódás során a beköltöző rendszereknek szükséges alkalmazkodnia a KAK lehetőségeihez. Amennyiben a felhőbe nem integrálható a rendszer, KAK hosting-ban szükséges elhelyezni. Ebben az esetben, a teljes fizikai infrastruktúra kialakítása szükséges (tűzfal, SAN, LAN, számítási kapacitás, tároló).
KAK Felhő architektúra alapsémája
A KAK Felhő két telephelyen kerül felépítésre. Egy-egy telephelyen a következő architektúra kerül kialakításra:
•
•
1. ábra KAK Felhő architektúra alapsémája
Az architektúra kialakításánál figyelembe vett alapvetések:
A KAK Felhő VMware és OpenStack alapú számítási kapacitást tartalmaz.
A VMware alapú szerverek 16 GBites FC SAN hálózaton keresztül kapcsolódnak a tároló rendszerekhez. A beszerzett tároló támogatja a storage virtualizációt, így a későbbiekben beszerzésre kerülő, blokk típusú tárolók integrációja várhatóan problémamentes lesz.
Az OpenStack alapú rendszerek Ethernet hálózaton, iSCSI-n érik el a tárolót. Az itt tervezett tároló rendelkezik az OpenStack-ben megkövetelt Cinder driverrel.
Mind a két tároló rendelkezik natív NAS funkcionalitással.
A tervezett SAN hálózat a VMware alatti tárolót (vagy tárolókat), a VMware szervereket, valamint a mentéshez használt mentőszervereket, VTL-eket és Tape Library eszközöket köti össze klasszikus, telephelyenként két fabric-os felépítésben. A Fabric-ban minden berendezés két külön adatúton érhető el amelyeknek – a legelejét és a legvégét kivéve – nincs közös pontja.
Felhőre fejlesztett alkalmazások
A felhőre fejlesztett alkalmazásokon azt értjük, hogy az alkalmazás web-es felülettel rendelkezik a felhasználók felé, és legalább a következő rétegekből áll:
• Load balancer;
• Applikációs szerverek (virtuálisak);
• Perzisztencia réteg (file share / adatbázis / object store);
• több site-os kialakítás.
Az applikációs szerverek lehetőség szerint állapotmentesen működjenek.
2. ábra Felhőre fejlesztett alkalmazások
HA (High Availability), azaz telephelyen belüli, magas rendelkezésre állás megoldása:
• A Load balancer-eket a redundáns perimeter eszköz fogja biztosítani, így annak a kiesése nem okoz leállást (legrosszabb esetben a session-ök vesznek el, ezért az éppen bejelentke- zett felhasználóknak újra kell authentikálni);
• Egy applikációs szerver kiesése esetén elindul egy új, ha az applikációs szerver tényleg álla- potmentes, akkor a kiesése / újraindulása egyáltalán nem érzékelhető felhasználói oldalról. Ha nem sikerül teljesen állapotmentesre, akkor a rajta átmenő session-ök vesznek el, a fel- használókat újra kell authentikálni.
• Perzisztencia réteg: Az adatbázis- és a storage-rétegben nincs SPOF, egy eszköz kiesése nem okoz a felhasználók számára érzékelhető változást.
• HA esemény esetén gyakorlatilag nincs kiesett idő.
DR (Disaster Recovery) - katasztrófa elhárítási megoldás telephelykiesés esetén:
A perimeter eszköz site-ot vált, a további kéréseket a „B” site-on futó applikációs szerverek felé továbbítja, melyek a „B” site adatbázisát / fájl szerverét veszik igénybe. A felhasználóknak valószínűleg megszakad a kapcsolata, és újra kell authen- tikálni, ellenőrizni kell, hogy az utolsó művelet sikeres volt vagy sem. A kiesési idő várhatóan kevesebb, mint 20 perc.
Dokumentációk tartalmi leírása
54-NY2
54-NY3
54-NY4
54-M1_v5.0_Az
Tesztterv.docx Tesztforgatókönyv.doTesztjegyzőkönyv.docelőállítandó dokumen
1025431 nyilvántartási számú szerződés 3. számú melléklete
6-NY2 Teljesítést igazoló bizonylat 2.0
TELJESÍTÉST IGAZOLÓ BIZONYLAT
Kiállítás helye: | Kiállítás dátuma: | ||
Vállalkozó/ Szállító cég neve: | |||
Megrendelő: NISZ Nemzeti Infokommunikációs Szolgáltató Zrt. | Képviselő (1) neve, beosztása: (a TIB aláírója) | Képviselő (2) neve, beosztása: (a TIB jóváhagyója) | |
Szakmai kapcsolattartó neve, beosztása: | |||
Szerződés/Megrendelés tárgya: | |||
Megrendelő szerződés/Meg- rendelés száma (SZL): | |||
Teljesítés igazolás tárgya: | |||
Teljesítés szerződés szerinti üteme/dátuma/időszaka1: | |||
Teljesítés tényleges dátuma: | |||
Megjegyzés2: | |||
Megrendelő képviselői igazolják, hogy a Vállalkozó/Szállító az árut, terméket vagy eszközt a Megren- delő telephelyére szállította, átadta, illetve a szolgáltatást elvégezte a szerződésben foglaltak szerint. A teljesítést igazoló, dokumentáló iratok (szállítólevél, berendezéslista, átadás-átvételi jkv., minőség- vizsgálati jkv., tesztelési minősítés, más ) a teljesítést igazoló szakterü-
letnek átadásra kerültek; a teljesítés a szerződés szerinti tartalomnak és minőségnek megfelel/ a szerződésben foglaltaktól eltérően a Megjegyzésben részletezett eltérésekkel történt3. A fent jelzett és archivált dokumentumokat a teljesítést igazoló szakterület visszakereshető módon megőrizni kö- teles.
A Vállalkozó/Szállító számláját ezen igazolt tétel(ek)re benyújthatja.
Elfogadott nettó teljesítmény érték (Ft): | ||||
a szerződésben meghatározott egyéb devizában | Devizanem: | Érték: | ||
Az elfogadott teljesítésből visszatartott kötbér (Ft): | ||||
Megrendelő képviselője (1) | Megrendelő képviselője (2) |
+36 1 459 4200 | nisz.hu |
1 A megfelelő aláhúzandó, és az aláhúzásnak megfelelően kitöltendő.
2 A nem szerződésszerű teljesítés tényének feltüntetése itt jelölhető. Ennek kitöltése esetén a Vállalkozó/Szállító részére a nyom- tatvány mellékleteként az 1. számú függelék Kötbérértesítő megküldése is szükséges.
3 A megfelelő szövegrész aláhúzással jelölendő.
1025431 nyilvántartási számú szerződés 4. számú melléklete
Eladó szerződés aláírásakor ismert alvállalkozói
1. A közbeszerzési eljárásban nevesített alvállalkozó(k):
Alvállalkozó neve:……………………………
Alvállalkozó székhelye/címe:………………...
Alvállalkozó feladata:………………………...
Alvállalkozó neve:……………………………
Alvállalkozó székhelye/címe:………………...
Alvállalkozó feladata:………………………...
2. A teljesítésbe bevonni kívánt, a közbeszerzési eljárásban nem nevesített alvállalkozók:
Alvállalkozó neve:……………………………
Alvállalkozó székhelye/címe:………………...
Alvállalkozó feladata:………………………...
Alvállalkozó neve:……………………………
Alvállalkozó székhelye/címe:………………...
Alvállalkozó feladata:………………………...
Nyilatkozom, hogy a jelen pontban nevesített alvállalkozó(k) nem áll(nak) a Kbt. 62. § (1)-(2) bekezdésében meghatározott kizáró okok hatálya alatt.
............................., 20…... ...... ..........
.............................................
Aláírás
1025431 nyilvántartási számú szerződés 5. számú melléklet
6-NY4 Nyilatkozat Partner adatairól 2.0 |
NYILATKOZAT PARTNER ADATAIRÓL
Azonosító adatok: | ||
Teljes név (cégjegyzéknek megfelelően): BI-TECH Informatika Szolgáltató és Tanácsadó Korlátolt Felelősségű Társaság | Rövid név (cégjegyzéknek megfelelően): BI-TECH Informatika Kft. | |
Cégjegyzék szám, EV szám, működési engedély szám, bírósági nyilvántartási szám, egyéb…01-09-865385…szám (megfelelő aláhúzandó): | ||
Adószám: 13633473-2-42 | Uniós adószám: HU13633473 | |
Kapcsolattartó adatai | ||
Név: dr. Plasek Gábor | Beosztás: Ügyvezető | |
Telefonszám: +36-1-785-09-46 | ||
Cím | ||
Székhely (ország, irányítószám, város, utca, házszám): 1142 Budapest, Rohonc utca 5. | ||
Levelezési cím, amennyiben eltér a székhelytől (ország, irányítószám, város, utca, házszám): | ||
Vevő partner esetében a következőket is ki kell tölteni, amennyiben releváns: | ||
Számla küldési cím (ország, irányítószám, város, utca, házszám): Cégnév: | ||
Számlázási cím (ország, irányítószám, város, utca, házszám): | ||
Számlavezető bank | ||
Neve: OTP Bank Nyrt | ||
Bankszámlaszáma: 117140006-25992405 | Bankszámla devizaneme: HUF | |
Különös adózásra vonatkozó információk (adózásra vonatkozó törvények alapján, az irreleváns sorban NEM-et kell beírni, amelyik sor vonatkozik a partnerre, ott IGEN-t) | ||
Pénzforgalmi elszámolás [áfa tv. XIII/A. fejezet, 169.§.(h)]: NEM | Különbözet szerinti elszámolás [áfa tv. XV.-XVII. fejezet, 169.§.(p,q,)]: NEM | Önszámlázás [áfa tv. 169.§.(l)]: NEM |
Fordított adózás [áfa tv. 169.§.(n)]: NEM Milyen tevékenység alapján: | Alanyi mentesség [áfa tv. XIII. feje- zet]: NEM | Tevékenység alapján mentes [áfa tv. VI. fejezet]: NEM Milyen tevékenység alapján: |
KATA [2012. évi CXLVII. törvény]: NEM | ||
Kelt………………….………
…………………………………………..
Cégszerű aláírás
1025431nyilvántartási számú szerződés 6. számú melléklete
Eladó átláthatósági nyilatkozata
Nyilatkozat az államháztartásról szóló 2011. CXCV. törvény 41. § (6) bekezdésében foglalt feltételnek való megfelelésről
Nyilatkozattevő: BI-TECH Informatika Korlátolt Felelősségű Társaság Székhely: 1142 Budapest, Rohonc utca 5.
Cégjegyzékszám: 01-09-865385
Adószám: 13633473-2-42
Képviseletében eljár: dr. Plasek Gábor
Jelen okirat aláírásával nyilatkozom, hogy az általam képviselt BI-TECH Informatika Kft. a nemzeti vagyonról szóló 2011. évi CXCVI. 3. § (1) bekezdés 1. pontja1 szerinti átlátható szervezet.
Tudomásul veszem, hogy a nyilatkozatban foglaltak változásáról köteles vagyok a Digitális Kor- mányzati Ügynökség Zrt.-t haladéktalanul írásban értesíteni.
Tudomásul veszem, hogy a valótlan tartalmú nyilatkozat alapján létrejött szerződést a Digitális Kor- mányzati Ügynökség Zrt. jogosult felmondani, vagy attól elállni.
Budapest, 20…...
…………………..…..
1 3. § (1) E törvény alkalmazásában
1. átlátható szervezet:
a) az állam, a költségvetési szerv, a köztestület, a helyi önkormányzat, a nemzetiségi önkormányzat, a társulás, az egy- házi jogi személy, az olyan gazdálkodó szervezet, amelyben az állam vagy a helyi önkormányzat külön-külön vagy együtt 100%-os részesedéssel rendelkezik, a nemzetközi szervezet, a külföldi állam, a külföldi helyhatóság, a külföldi állami vagy helyhatósági szerv és az Európai Gazdasági Térségről szóló megállapodásban részes állam szabályozott piacára bevezetett nyilvánosan működő részvénytársaság,
b) az olyan belföldi vagy külföldi jogi személy vagy jogi személyiséggel nem rendelkező gazdálkodó szervezet, amely megfelel a következő feltételeknek:
ba) tulajdonosi szerkezete, a pénzmosás és a terrorizmus finanszírozása megelőzéséről és megakadályozásáról szóló törvény szerint meghatározott tényleges tulajdonosa megismerhető,
bb) az Európai Unió tagállamában, az Európai Gazdasági Térségről szóló megállapodásban részes államban, a Gazdasági Együttműködési és Fejlesztési Szervezet tagállamában vagy olyan államban rendelkezik adóilletőséggel, amellyel Magyar- országnak a kettős adóztatás elkerüléséről szóló egyezménye van,
bc) nem minősül a társasági adóról és az osztalékadóról szóló törvény szerint meghatározott ellenőrzött külföldi társa- ságnak,
bd) a gazdálkodó szervezetben közvetlenül vagy közvetetten több mint 25%-os tulajdonnal, befolyással vagy szavazati joggal bíró jogi személy, jogi személyiséggel nem rendelkező gazdálkodó szervezet tekintetében a ba), bb) és bc) alpont szerinti feltételek fennállnak;
c) az a civil szervezet és a vízitársulat, amely megfelel a következő feltételeknek:
ca) vezető tisztségviselői megismerhetők,
cb) a civil szervezet és a vízitársulat, valamint ezek vezető tisztségviselői nem átlátható szervezetben nem rendelkeznek 25%-ot meghaladó részesedéssel,
cc) székhelye az Európai Unió tagállamában, az Európai Gazdasági Térségről szóló megállapodásban részes államban, a Gazdasági Együttműködési és Fejlesztési Szervezet tagállamában vagy olyan államban van, amellyel Magyarországnak a kettős adóztatás elkerüléséről szóló egyezménye van;
……………. nyilvántartási számú szerződés 7. számú melléklete
Eladó Kbt. 136. § (2) bekezdése szerinti meghatalmazása1
1 Kizárólag abban az esetben lesz a szerződés része, ha Eladó külföldi adóilletőségű.