PRÍSTUP K PROJEKTU

manažérsky výstup I-03

podľa vyhlášky MIRRI č. 401/2023 Z. z.

História DOKUMENTU

Použité skratky a pojmy

1.      Popis navrhovaného riešenia

Na základe MCA z Projektového zámeru bod 1.8. je najvhodnejšou alternatívou migrácia geografického informačného systému PPA, ktorý tvoria isvs  GSAA a LPIS do privátnej časti VC.  Budúca architektúra systémov bude kopírovať súčasnú s rešpektovaním zásad cloud computingu a pravidiel architektúry vládneho cloudu.

2.      Architektúra riešenia projektu

Rozsah tejto kapitoly je prispôsobený typu projektu – zvýšenie dostupnosti isvs využitím služieb vládneho cloudu.

2.1         Biznis vrstva

Realizácia projektu nebude mať vplyv na TO BE stav biznis architektúry.

Identifikácia kľúčových životných situácii (ŽS), ktorých sa projekt týka:

Dotácie (001)
 

IS GSAA je aplikácia, prostredníctvom ktorej žiadateľ o podporu od PPA predkladá prílohy k Jednotnej žiadosti o Priame podpory na elektronickom formulári.

Funkcie GSAA

1. Geodatabáza GSAA (popis geodatabázy je v 2)                            
   • Deklarácia ZPP (Archív deklarácií ZPP, Základné nastavenie ZPP, Používateľské voľby ZPP)
   • Deklarácia ZPPE (Archív deklarácií ZPPE, Základné nastavenia ZPPE. Používateľské voľby ZPPE)
   • Číselníky: Podnet na aktualizáciu LPIS; Viazané priame platby a ochrana biotopov ; Kultúra; Ekologické opatrenie; Integrované opatrenie; Kombinácia opatrení; Plodina typ EFA Zoznam chýb a zistení z kontroly
2. GSAA webová aplikácia
   • Stavový model žiadosti (Podmienky na zmenu stavu, Udalosti zmeny stavu)
   • Čítanie a editácia
   • Zoznam poľnohospodárskych pozemkov
   • Nástroje aplikácie GSAA:
   • Validácia HU, deklarácie, Zobrazenie GPS súradníc, Priradenie lokality HU mimo KD, Identifikácia HU po rozdelení, Referenčné výmery, Zobrazovanie HU v mape podľa stavu žiadosti, Zobrazenie plôch mimo LPIS, Nástroj na meranie vzdialenosti a plochy, Import vrstvy z KML do mapy, Rozdelenie HU podľa EV, Nárazníkové zóny – brehové porasty (Referenčná externá vrstva NZ EFA, Prepočet výmery NZ BP k HU, Deklarácie NZ BP v ZPP a ZPPE), História údajov (Prepnutie, Zobrazenie historických údajov, Druhá historická vrstva HU); Výsledky krížových a SW kontrol (Kontroly, a zistenia vb IACS. Výsledky kontrol v GSAA), Úpravy aplikácie (priblíženia, „pop-up“ okno Zjednotenie roly čitateľ a administrátor HU, rola „Externý čitateľ“, Kataster nehnuteľností, Odosielanie editovaných žiadostí
3. Integrácia tretích strán               
   • Editácia HU
   • Vytvorenie ZPP
   • Vytvorenie ZPPE
   • Validácia HU a deklarácií
4. Aktualizácia LPIS v IS GSAA a IS IACS
   • Aktualizácia LPIS v GDB GSAA
   • Archivácia údajov LPIS
5. Aktualizácia LPIS v IACS prostredníctvom GSAA
6. Integrácia IS GSAA a IS IACS

LPIS je geografický informačný systém, ktorý eviduje plochy (kultúrne diely) poľnohospodárskej pôdy, ktoré sú spôsobilé pre platby. Plochy sa aktualizujú priebežne na základe ortofotosnímok v trojročnom cykle. Súčasťou LPIS sú aj údaje o EFA prvkoch a údaje od externých dodávateľov, ktoré spolu tvoria ucelený balík priestorových informácií. Údaje sú zverejnené bezplatne (pre G2B, G2C) na stránke www.podnemapy.sk.LPIS ako súbor referenčných plôch tvoriacich podklad pre podávanie žiadostí pre priame platby je potrebné meniť v súlade s aktuálnym stavom využívania krajiny. Podľa LPIS Guidance je nevyhnutné vykonávať pravidelné prehodnotenie LPIS na základe rôznych dostupných zdrojov.

Zdroje aktualizácie LPIS sú:

• Digitálne ortofotomapy
• Údaje z kontroly na mieste (KNM)
• Údaje zo satelitných záznamov pre kontrolu kvality LPIS (QA LPIS)
• Údaje zo satelitných záznamov pre kontrolu diaľkovým prieskumom Zeme

Pod aktualizáciou LPIS sa rozumie:

• Cyklická aktualizácia dielov pôdnych blokov
• Cyklická aktualizácia neproduktívnych prvkov
• Cyklická aktualizácia brehových čiar a nárazníkových zón
• Aktualizácia vrstvy terás a citlivých Trvalých trávnych porastov (TTP) v prípade zistenia nezrovnalosti
• Aktualizácia LPIS na základe ostatných zdrojov (zapracovanie výsledkov kontroly kvality, požiadavky z mailu akt.lpis@apa.sk)

Kolaboračný diagram, ktorý popisuje postupnosť procesov, ktoré sú potrebné pre vypracovanie prílohy k JŽ sa nachádza na nasledujúcom obrázku.

KD_GSAA_01_Vytvorenie grafickej prílohy k Jednotnej žiadosti o Priame podpory

2.1.1          Prehľad koncových služieb – rozsah

Projekt nemá vplyv na rozdiel koncových služieb budúceho a súčasného stavu. Rozsah koncových služieb pokrytých projektom sa nachádza v tabuľke:

2.1.2          Jazyková podpora a lokalizácia

Uveďte a do katalógu požiadaviek zaevidujte požiadavky na jazykovú podporu a lokalizáciu používateľského rozhrania a výstupov do viacerých jazykov v riešení TO BE stavu.

2.2         Aplikačná vrstva

Popis Geodatabázy GSAA (GDB GSAA)

Centrálne úložisko dát IS GSAA je na technológii ArcSDE, súčasť ArcGIS for Server. Ako RDBMS je využívaný MS SQL Server. Databáza obsahuje dáta LPIS a externé vrstvy. Každá editácia je v GDB GSAA auditovaná.

Webový mapový server

poskytovanie mapových, prvkových (editácia) a geoprocesných služieb( analýza) pre IS GSAA. Postavený na produkte ArcGIS for Server Standard, súčasťou je Portal for ArcGIS, prostredníctvom webových máp poskytuje jednotné miesto na konfiguráciu a zdieľanie priestorových údajov v IS GSAA.

GSAA webová aplikácia

editačný nástroj pre žiadateľov, vytvárajú podklady pre podanie žiadosti. Umožňuje definovať hranicu užívania ako plochu nad referenčnou vrstvou KD  (zdroj LPIS), definovať atribúty a vytlačiť grafickú a tabuľkovú prílohu. Administrátorovi  PPA umožňuje prehliadať dáta farmárov v režime čítanie.

1. strany

Ak farmár, ktorý hospodári na väčšej výmere využíva vlastný evidenčný IS, ktorý obsahuje priestorové informácie ako podklad pre podanie žiadosti. Na tento účel je vystavená OGC WFS služba, ktorá umožní pre autentifikovaného farmára odoslať svoje dáta do GSAA. Finálna validácia dát bude prebiehať v GSAA.

GIS Desktop GDB GSAA

 umožňuje, aby jej dáta boli editované prostredníctvom ArcGIS for Desktop, ktorý  poskytuje profesionálne GIS nástroje na editáciu priestorových údajov.

IS GSAA je ArcGIS for Desktop

využívaný pri hromadnom prepočítavaní údajov, správe GDB GSAA a pri rozsiahlych editáciách, ktoré je neefektívne, resp. nemožné vykonať vo webovej aplikácii.

Aplikačná vrstva GSAA a LPIS nebude projektom zmenená.

Model architektúry s hlavnými e-Government komponentami a ich vzťahmi podľa metamodelu evidencie eGovernment komponentov v MetaIS:

2.2.1          Rozsah informačných systémov – AS IS

Dotknuté ISVS a ich moduly AS IS:

2.2.2          Rozsah informačných systémov – TO BE

Ďalšia prevádzka po realizácii projektu nebude mať vplyv na rozsah systémov v TO BE stave:

2.2.3          Využívanie nadrezortných a spoločných ISVS – AS IS

V AS IS sa nevyužívajú žiadne nadrezortných ISVS (Spoločné ISVS a spoločné bloky SaaS).

2.2.4          Prehľad plánovaných integrácií ISVS na nadrezortné ISVS – spoločné moduly podľa zákona č. 305/2013  e-Governmente – TO BE

Projekt neplánuje využívanie nadrezortných a spoločných ISVS v TO BE stave.

2.2.5          Prehľad plánovaného využívania iných ISVS (integrácie) – TO BE

V nasledujúcej tabuľke je prehľad ISVS, na ktoré má GSAA a LPIS integráciu v TO BE stave:

IS IACS

Integrovaný administratívny a kontrolný systém PPA pozostáva z troch modulov - IACS, IACS eKNM (elektronické administrovanie kontrol na mieste) a IACS JRŽ (Jednotný register žiadateľov). Vo svojich moduloch podporuje nasledovné procesy: - príjem žiadosti,- krížové plnenie,- nezrovnalosti,- kontrola,- register pôdnych blokov LPIS - podporný proces,- centrálna evidencia hospodárskych zvierat - podporný proces,- platby,- výkazy, - zaznamenávanie výsledkov kontrol na mieste (KNM) a údajov z diaľkového prieskumu zeme (DPZ), - správa kmeňových dát. Prístup do IS IACS je umožnený iba oprávneným osobám – zamestnancom PPA.

Do mapovej časti aplikácie GSAA sa importujú dve vrstvy katastra nehnuteľností (parcely C a E). Ide o samostatne zapínateľné a vypínateľné vrstvy so základným popisom prvkov. Vrstvy sú dostupné pre všetkých používateľov okrem tých v role verejnosť. Import prebieha k určitému dátumu ručne kvôli stabilite GSAA, nie automatizovane.

2.2.6          Aplikačné služby pre realizáciu koncových služieb – TO BE

Realizácia projektu nemá vplyv na budovanie aplikačných služieb. Rozsah aplikačných služieb, ktoré realizujú koncovú službu sa nachádza v nasledujúcej tabuľke:

2.2.7          Aplikačné služby na integráciu – TO BE

Predmetom projektu nie je budovanie aplikačných služieb na integráciu.

2.2.8          Poskytovanie údajov z ISVS do IS CSRÚ – TO BE

Predmetom projektu nie je poskytovanie / konzumovanie údajov z IS CSRÚ.

2.3         Dátová vrstva

Realizovaný projekt nebude mať vplyv na dátový rozsah, dátovú kvalitu, referenčné údaje, otvorené údaje, analytické údaje ani na moje údaje.

2.4         Technologická vrstva

2.4.1          Prehľad technologického stavu - AS IS

Aktuálna schéma technologickej infraštruktúry je nasledovná:

Rozpis aktuálnej infraštruktúry:

2.4.2          Požiadavky na výkonnostné parametre, kapacitné požiadavky – TO BE

V nasledujúcej tabuľke sa nachádzajú požiadavky na výkonnostné parametre, kapacitné požiadavky, ktoré majú vplyv na výkon, sizing prostredia:

2.4.3          Návrh riešenia technologickej architektúry

Riešenie bude nasadené do technologického prostredia v rámci VC – nový projekt.

Technologická architektúra sa nebude výrazne líšiť od súčasnej, bude virtualizovaná. Využije sa vývojové, testovacie  aj produkčné prostredie VC.

Operačné systémy prejdú na novšie (Windows Server 2022, SQL server 2022)

V rámci budúcich obdobiach sa predpokladá navyšovanie infraštruktúry cca. o 30% každé 4 roky, aby infraštruktúra zodpovedala rámcovo aj rozvoju aplikácie

Architektúra vo VC bude vytváraná spolu s úspešným uchádzačom s rešpektovaním zásad tvorenia archotektúry vo VC:

Pri vytváraní projektu umožňuje vládny cloud vytvorenie viacerých vrstiev a prostredí. Vrstvy: DMZ, V1, V2, V3. Hierarchia vrstiev je: DMZ/V1 – V2 – V3. Komunikácia je povolená len medzi susediacimi vrstvami. Komunikácia do externých sietí (napr. GOVNET, Internet) je povolená len z vrstvy DMZ.

Servery štandardnej trojvrstvovej aplikácie (WEB/APP/DB), ktorá je dostupná z externej siete budú umiestnené nasledovne :

- DMZ – WEB

- V2 – APP

- V3 – DB

V prípade, že jeden server zabezpečuje viacero funkcií (napr. WEB/APP), budú servery umiestnené nasledovne :

- DMZ – WEB/APP

- V2 – DB

V prípade prepojenia vládneho cloudu s internou sieťou vytvorením site-to-site VPN tunela budú WEB servery poskytujúce služby do internej siete umiestnené do vrstvy V1.

Využije sa vlastnosť prostredia umožňujúca separáciu produkčných, testovacích a iných inštancií projektu.

Komunikácia medzi prostrediami nie je možná. Vládny cloud umožňuje vytvorenie 4 prostredí.

V rámci vrstvy prostredia zdieľajú jeden IP rozsah.

2.4.4          Využívanie služieb z katalógu služieb vládneho cloudu

Využívanie infraštruktúrnych služieb VC je v nasledujúcej tabuľke:

Požadované kapacitné parametre pre služby sa nachádzajú v nasledujúcej tabuľke:

Požiadavky na služby vládneho cloudu budú pred vyhlásením VO odkomunikované s prevádzkovateľom vládneho cloudu (MV SR).

2.5         Bezpečnostná architektúra

Realizáciou projektu a zmenou infraštruktúry z lokálneho riešenia na vládny cloud bude zabezpečená vysoká úroveň kybernetickej bezpečnosti a zároveň bude garantovaná  dostatočná  úroveň dostupnosti služieb.

Prihlásenie žiadateľa podlieha štandardným autorizačným oprávneniam a preto je vždy vyžiadaná autentifikácia používateľa, tzn. prihlásenie cez meno a heslo.

Webová aplikácia GSAA rozlišuje 6 rolí:

-              Žiadateľ: používateľ, ktorý používa aplikáciu na podanie žiadosti o dotáciu. Má založenú identitu v Active Directory a žiadosť v databáze. Identifikovaný je jednoznačným PPA ID, ktoré pochádza z JRŽ (Jednotný Register Žiadateľov). Vo všeobecnosti môže prezerať a editovať všetky svoje HU a deklarácie, prezerať zverejnené HU iných žiadateľov, podávať žiadosť, tlačiť prílohy atď.

-              Administrátor HU: používateľ, ktorý používa aplikáciu za účelom správy žiadostí. Má založenú identitu v Active Directory, ale nemá založenú žiadosť v databáze. Nemá pridelené PPA ID. Vo všeobecnosti môže prejsť do kontextu hociktorého žiadateľa a ňom má právomoc prezerať a editovať HU a deklarácie žiadateľa a tiež podávať žiadosť v mene žiadateľa.

-              Interný čitateľ: používateľ, ktorý používa aplikáciu za účelom prezerania údajov žiadateľov. Má založenú identitu v Active Directory, ale nemá založenú žiadosť v databáze. Nemá pridelené PPA ID. Vo všeobecnosti môže prejsť do kontextu hociktorého žiadateľa a ňom má právomoc prezerať HU a deklarácie žiadateľa. Nemá právomoc editovať údaje žiadosti.

-              Externý čitateľ: používateľ, ktorý používa aplikáciu za účelom prezerania údajov žiadateľov. Má založenú identitu v Active Directory, ale nemá založenú žiadosť v databáze. Nemá pridelené PPA ID. Vo všeobecnosti môže prejsť do kontextu hociktorého žiadateľa a ňom má právomoc prezerať HU a deklarácie žiadateľa. Nemá právomoc editovať údaje žiadosti. Oproti internému čitateľovi má obmedzené možnosti prezerania (nemá dostupné niektoré vrstvy, nemá dostupnú históriu údajov a nemá dostupné výsledky kontrol).

-              Integrátor: používateľ, ktorý pristupuje na integračné rozhrania (REST) IS GSAA a edituje žiadosť v mene žiadateľa cez externý systém. Má založenú identitu v Active Directory, ale nemá založenú žiadosť. Tento používateľ nemá priamy prístup do webovej aplikácie GAA ani nemá právomoc podávať žiadosť.

Pred kampaňou 2019 nastala väčšia zmena v koncepcii bezpečnosti pri prístupe na integračné rozhrania tretích strán. Hlavnou zmenou bolo zavedenie autentifikácie a autorizácie integrátora, ktorý doposiaľ vystupoval voči IS GSAA pod identitou žiadateľa. Hlavným prínosom tejto zmeny bolo zrušenie potreby distribúcie žiadateľových prihlasovacích údajov tretím stranám, čo výrazne zvýšilo bezpečnosť celého IS GSAA.

Autentifikácia tretích strán

Autentifikačný mechanizmus pre tretie strany je rovnaký ako pre žiadateľov a iné identity v IS GSAA. To znamená, že integrátor sa pri prístupe na webové rozhrania autentifikuje voči systému GSAA tokenom. Tento token je integrátorovi sprístupnený cez štandardnú webovú službu na generovanie tokenov a je dostupný voči menu a heslu integrátora. Nasledovne musí integrátor priložiť tento token ku každej ďalšej požiadavke na integračnú webovú službu.

Z uvedeného vyplýva, že integrátor sa autentifikuje svojim vlastným menom a heslom, nie menom a heslom žiadateľa. Týmto je zabezpečené, že všetky editácie žiadosti z tretích strán môžu byť auditované voči identite, ktorá skutočne editáciu vykonala. Výhodou tohto riešenia je tiež to, že integrátori nedisponujú heslami žiadateľov.

Autorizácia tretích strán

Samotná autentifikácia tretích strán zabezpečuje overenie skutočnej identity, ktorá pristupuje do IS GSAA. Autentifikácia bola doplnená o autorizáciu tak, aby systém vedel overiť, či daný integrátor môže vykonávať zmeny v konkrétnej žiadosti.

Za týmto účelom bola webová aplikácia rozšírená o nastavenia autorizácie. Tieto nastavenia má dostupné iba prihlásený používateľ v role žiadateľ. Žiadateľ má možnosť vybrať práve jedného integrátora a autorizovať ho tak na vykonávanie zmien v jeho žiadosť. Platnosť autorizácie je časovo obmedzená, žiadateľ môže túto platnosť meniť a v základnom nastavení je povolená do konca aktuálnej kampane.

Editácie žiadostí tretími stranami, tzn. editácie HU a editácie deklarácií, a prezeranie údajov podliehajú autorizácii na základe zoznamu autorizovaných integrátorov. Tzn. integrátor môže prezerať údaje a vykonávať editácie iba tých žiadostí, na ktoré bol autorizovaný žiadateľom.

Je vyžadovaný súlad budúcej bezpečnostnej architektúry s dotknutými právnymi normami a zároveň s technickými normami, ktoré stanovujú úroveň potrebnej bezpečnosti IS,  pre manipuláciu so samotnými dátami, alebo technické/technologické/personálne zabezpečenie samotnej výpočtovej techniky/HW vybavenia. Ide najmä o:

• Zákon č. 95/2019 Z.z. o informačných technológiách vo verejnej správe
• Zákon č. 69/2018 Z.z. o kybernetickej bezpečnosti
• Zákon č. 45/2011 Z.z. o kritickej infraštruktúre
• vyhláška Úradu podpredsedu vlády Slovenskej republiky pre investície a informatizáciu č. 78/2020 Z. z. o štandardoch pre informačné technológie verejnej správy
• vyhláška Úradu podpredsedu vlády Slovenskej republiky pre investície a informatizáciu č. 179/2020 Z. z., ktorou sa ustanovuje spôsob kategorizácie a obsah bezpečnostných opatrení informačných technológií verejnej správy
• vyhláška Úradu na ochranu osobných údajov Slovenskej republiky č. 158/2018 Z. z. o postupe pri posudzovaní vplyvu na ochranu osobných údajov
• Nariadenie Európskeho parlamentu a Rady (EÚ) 2016/679 z 27. apríla 2016 o ochrane fyzických osôb pri spracúvaní osobných údajov a o voľnom pohybe takýchto údajov, ktorým sa zrušuje smernica 95/46/ES (všeobecné nariadenie o ochrane údajov)
• Zákon č. 18/2018 Z. z. o ochrane osobných údajov a o zmene a doplnení niektorých zákonov.

Prevádzkovateľ bude požadovať realizáciu Bezpečnostného projektu v zmysle platnej legislatívy.

3.      Závislosti na ostatné ISVS / projekty

Realizácia pripravovaného projektu nie je závislá od žiadneho ďalšieho projektu.

4.      Zdrojové kódy

Budúci zhotoviteľ diela (ďalej ako Zhotoviteľ) je povinný pri akceptácii Informačného systému odovzdať Objednávateľovi (Realizátor projektu) funkčné vývojové a produkčné prostredie, ktoré je súčasťou Informačného systému.

Zhotoviteľ je povinný pri akceptácii Informačného systému alebo jeho časti odovzdať Objednávateľovi Vytvorený zdrojový kód v jeho úplnej aktuálnej podobe, zapečatený, na neprepisovateľnom technickom nosiči dát s označením časti a verzie Informačného systému, ktorej sa týka. Za odovzdanie Vytvoreného zdrojového kódu Objednávateľovi sa rozumie odovzdanie technického nosiča dát Oprávnenej osobe Objednávateľa. O odovzdaní a prevzatí technického nosiča dát bude oboma Zmluvnými stranami spísaný a podpísaný preberací protokol.

Vytvorený zdrojový kód  Informačného systému vrátane jeho dokumentácie bude prístupný v režime podľa § 31 ods. 4 písm. b) Vyhlášky č. 78/2020 (s obmedzenou dostupnosťou pre orgán vedenia a orgány riadenia v zmysle Zákona o ITVS – vytvorený zdrojový kód je dostupný len pre orgán vedenia a orgány riadenia); týmto nie je dotknutý osobitný právny režim vzťahujúci sa na Preexistentný zdrojový kód. Objednávateľ je oprávnený sprístupniť Vytvorený zdrojový kód okrem orgánov podľa predchádzajúcej vety aj tretím osobám, ale len na špecifický účel, na základe riadne uzatvorenej písomnej zmluvy o mlčanlivosti a ochrane dôverných informácií.

Vytvorený zdrojový kód musí byť v podobe, ktorá zaručuje možnosť overenia, že je kompletný a v správnej verzii, t. j. v takej, ktorá umožňuje kompiláciu, inštaláciu, spustenie a overenie funkcionality, a to vrátane kompletnej dokumentácie zdrojového kódu (napr. interfejsov a pod.) takejto Informačného systému alebo jeho časti. Zároveň odovzdaný Vytvorený zdrojový kód musí byť pokrytý testami (aspoň na 90%) a dosahovať rating kvality (statická analýza kódu) podľa CodeClimate/CodeQL a pod. (minimálne stupňa B).

Pre zamedzenie pochybností, povinnosti Zhotoviteľa týkajúce sa Vytvoreného zdrojového kódu platí i na akékoľvek opravy, zmeny, doplnenia, upgrade alebo update Vytvoreného zdrojového kódu a/alebo dokumentácie, ku ktorým dôjde pri plnení diela alebo v rámci záručných opráv. Vytvorené zdrojové kódy budú vytvorené vyexportovaním z produkčného prostredia a budú odovzdané Objednávateľovi na elektronickom médiu v zapečatenom obale. Zhotoviteľ je povinný umožniť Objednávateľovi pri odovzdávaní Vytvoreného zdrojového kódu, pred zapečatením obalu, skontrolovať v priestoroch Objednávateľa prítomnosť Vytvoreného zdrojového kódu na odovzdávanom elektronickom médiu.

Nebezpečenstvo poškodenia zdrojových kódov prechádza na Objednávateľa momentom prevzatia Informačného systému alebo jeho časti, pričom Objednávateľ sa zaväzuje uložiť zdrojové kódy takým spôsobom, aby zamedzil akémukoľvek neoprávnenému prístupu tretej osoby. Momentom platnosti SLA zmluvy umožní Objednávateľ poskytovateľovi, za predpokladu, že to je nevyhnutné, prístup k Vytvorenému zdrojovému kódu výlučne na účely plnenia povinností z  uzatvorenej SLA zmluvy.

Strany sa môžu dohodnúť, že okrem odovzdania Informačného systému alebo jeho časti, poskytne Zhotoviteľ Objednávateľovi tiež primeranú a nevyhnutnú súčinnosť za účelom zverejnenia dokumentácie na verejne prístupnom úložisku (podľa inštrukcie Objednávateľa) v súlade s § 31 Vyhlášky č. 78/2020 Z. z..

Usmernenia pre oblasť zdrojových kódov:

• Metodické usmernenie č. 024077/2023 – o kvalite zdrojových kódov a balíkov softvéru zverejnené na stránke: https://mirri.gov.sk/sekcie/informatizacia/riadenie-kvality-qa/

Inštrukcie k EUPL licenciám: https://commission.europa.eu/content/european-union-public-licence_en

5.      Prevádzka a údržba

Havarijné stavy v rámci pravidelných zabezpečených záloh systému budú realizované štandardizovaným spôsobom v prostredí prevádzkovateľa cloudových služieb. V prípade ďalšieho rozšírenia  poskytovaných služieb  informačného systému bude zabezpečené navýšenie požadovaných hardvérových parametrov v reálnom čase.

Popis ďalších prevádzkových požiadaviek a údržby nie je predmetom projektu, nakoľko v rozsahu projektu nie je SLA k informačnému systému.

Dostupnosť systému musí byť zabezpečená minimálne tak, ako je v stave AS IS a vyššia.

6.      Požiadavky na personál

Aktuálne sú požiadavky na udržiavanie a prevádzku HW, ktoré budú eliminované migráciou do cloudu.

Realizácia projektu bude znamenať navýšenie požiadaviek na personál v oblastiach:

• Prevádzka isvs v Cloude

PPA disponuje dostatočnými odbornými kapacitami na pokrytie týchto požiadaviek bez dodatočných nákladov na školenia.

7.      Implementácia a preberanie výstupov projektu

Spôsob realizácie projektu bude metódou waterfall.

Odovzdanie a prevzatie Diela alebo jeho časti sa uskutoční v termínoch špecifikovaných v časovom harmonograme. Výsledkom odovzdania Diela alebo jeho časti Zhotoviteľom a jeho prevzatia Objednávateľom je podpísanie akceptačného protokolu oprávnenými osobami. Akceptačný protokol musí byť pred jeho podpisom schválený Riadiacim výborom projektu.

Objednávateľ neprevezme Dielo alebo jeho časť (čiastkové plnenie), ak vykazuje Diela alebo jeho časť právne a/alebo faktické vady. Dielo alebo jeho časť (čiastkové plnenie) má vady, ak je zhotovené v rozpore podmienkami stanovenými v budúcej Zmluve o dielo a/alebo v rozpore so všeobecne záväznými právnymi predpismi.

Prílohou Akceptačného protokolu je:

• zápisnica o vykonaných akceptačných testoch, ak sa Akceptačným protokolom odovzdáva Informačný systém alebo jeho časť,
• zoznam autorov diel a zoznam autorských diel vytvorených v rámci plnenia budúcej Zmluvy o dielo, ak sú súčasťou odovzdávaného Diela alebo jeho časti,
• prezenčné listiny zo školení, ak boli vykonané pre užívateľov Diela, spolu so školiacim materiálom,
• vyhlásenie o splnení požiadaviek (dodržaní štandardov pre ISVS/ITVS) formou odpočtu splnenia jednotlivých relevantných požiadaviek stanovených vo Vyhláške č. 78/2020, Vyhláške č. 401/2023 a Vyhláške č. 179/2020,
• dokumenty a doklady osvedčujúce kvalitu a/alebo kompletnosť

Strany vykonajú vo vzájomnej súčinnosti akceptačné testy. Výsledky akceptačných testov sa zachytia v zápisnici podpísanej oprávnenými osobami oboch strán.

Ak sa strany v budúcej Zmluve o dielo nedohodnú inak, Zhotoviteľ je povinný odovzdať Objednávateľovi dokumentáciu k Dielu alebo jeho časti na elektronickom zariadení/nosiči dát (USB prenosné zariadenie) alebo na inom vhodnom, dohodnutom nosiči dát a v prípade potreby a požiadavky Objednávateľa aj v jednom vyhotovení v písomnej forme pri podpise Akceptačného protokolu.

8.      Prílohy

Architektúra eGOV komponentov z MetaIS: eGOV komponenty GSAA a LPIS.xml