PROJEKTOVÝ ZÁMER
Vzor pre manažérsky výstup I-02
podľa vyhlášky MIRRI č. 401/2023 Z. z.

1.História DOKUMENTU

2.ÚČEL DOKUMENTU, SKRATKY (KONVENCIE) A DEFINÍCIE

V súlade s Vyhláškou č. 401/2023 Z.z. je dokument I-02 Projektový zámer určený na rozpracovanie detailných informácií prípravy projektu, aby bolo možné rozhodnúť o pokračovaní prípravy projektu, pláne realizácie, alokovaní rozpočtu a ľudských zdrojov. 

Účelom predkladaného dokumentu je popis informácií o zmysle a dôvodoch realizácie projektu, odhadovaných prínosoch a nákladoch projektu, odôvodnení alokácie nevyhnutných zdrojov projektu, časovom rámci realizácie a odhadovaných rizikách projektu. 

Dokument je vypracovaný v rámci prípravno-iniciačnej fázy projektu v súlade s Vyhláškou Ministerstva investícií, regionálneho rozvoja a informatizácie Slovenskej republiky č. 401/2023 Z. z. o riadení projektov a zmenových požiadaviek v prevádzke informačných technológií verejnej správy.  

2.1Použité skratky a pojmy

2.2Konvencie pre typy požiadaviek (príklady)

Konvencia pre označovanie požiadaviek je nasledovná:

R-XX

• R          – označenie požiadavky
• xx        – číslo požiadavky

3.DEFINOVANIE PROJEKTU

3.1Manažérske zhrnutie

Projekt RIP je sú súčasťou programu rozvoja IKT v rezorte ÚGKK SR, ktorý pokrýva strategický rozvoj informačných a komunikačných technológií v rezorte. Jeden z kľúčových prvkov tohto programu v najbližšom období tvoria projekty implementácie životných situácií .

Projekt RIP má za cieľ vytvoriť jednotnú technickú infraštruktúru na

1. výmenu dát medzi systémami v rámci rezortu ÚGKK SR a
2. výmenu dát medzi ostatnými externými systémami verejnej správy.

Táto platforma umožní rýchlu a bezpečnú výmenu informácií medzi rôznymi entitami, čím podporí efektívnu a plynulú prácu s údajmi naprieč viacerými inštitúciami.

Projekt po ukončení zabezpečí:

1. Štandardizáciu budúcich integrácií
2. Stanovenie integračných pravidiel a zodpovedností
3. Integráciu na referenčné registre
4. Informovanie klienta o vybavení jeho podania prostredníctvom notifikácií
5. Kontinuálne zlepšovanie služieb zavedením monitoringu služieb a zberu spätnej väzby

Napojenie RIP na register fyzických osôb (ďalej len „RFO“) na využívanie údajov RFO (konzumácia dát) a v rámci programu rozvoja IKT v ÚGKK. V následných projektoch rozvoja je plánovaná aj plná integrácia RFO s ostatnými systémami ÚGKK ako budúci konkrétny krok smerom k vyššej efektívnosti procesov rezortu ÚGKK.

Zlepšená integrácia s externými systémami a registrami verejnej správy zvýši celkovú efektivitu procesov, čo prinesie organizácii vyššiu produktivitu a občanom vyšší komfort používania služieb ÚGKK. V nasledujúcich rozvojových projektoch bude RIP základným komponentom pre budovanie potrebných budúcich integrácii v rezorte ÚGKK.

Realizácia projektu začne v 2025 procesom verejného obstarávania a projekt bude ukončený v Q1/2026. Projekt je určený zamestnancom objednávateľa.

3.2Motivácia a rozsah projektu

• ŽS2 Kúpa a vlastníctvo nehnuteľnosti na bývanie
• ŽS6 Presťahovanie
• ŽS15 Uzavretie manželstva

• Chýbajúca štandardizácia integrácie s dostupnými vstupmi (kódy, dokumentácia), ktoré obsahujú popis spôsobu a nasadenia integrácie
• Absencia integračných pravidiel a zodpovedností, ktoré by UGKK zjednodušili implementáciu danej integrácie (pravidlá by mali obsahovať hlavne rozhodnutia, ktoré systémy integrovať a predovšetkým ako ich integrovať)
• Pri navrhovaní nových projektov neustále rastie potreba systémov medzi sebou automaticky komunikovať
• Absencia automatického predvypĺňania údajov pri podaniach - čo je spôsobené absenciou integrácie systémov na referenčné registre a sprístupnenia údajov pre interné systémy cez CPDI (RFO, RPO, RA, SUSR (číselníky a územné jednotky NUTS), MetaIS (číselníky))
• Nie je podporované kontinuálne zlepšovanie služieb na základe zberu relevantných údajov - monitoring elektronických služieb a spätnej väzby nie je podporovaný

• Centrálna integračná platforma ÚGKK SR, ktorá sprostredkováva dátovú výmenu medzi internými systémami ÚGKK SR a externými inštitúciami (napr. banky, iné orgány štátnej správy).
• Integračný bod pre konsolidáciu poskytovania údajov tretím stranám
• Náhrada súčasných integrácii, ktoré sú poskytované nepodporovanými systémami, alebo po kybernetickom útoku neboli obnovené a nie sú poskytované vôbec

• Konzumovanie dát z údajových registrov cez IS CSRÚ (CPDI) – RFO, RPO, RA
• Integrácia na spoločné moduly v zmysle § 10 zákona 305/2013 Z. z.
  • Integrácia na modul elektronického doručovania (ÚPVS MED),
  • Integrácia na autentifikačný modul (ÚPVS IAM),
  • Integrácia na modul úradnej komunikácie (ÚPVS G2G),
  • Integrácia na modul elektronických schránok (ÚPVS eDESK),
  • Integrácia na NASES kvalifikovaná služba validácie podpisov a pečatí,
  • Integrácia na modul elektronickej podateľne (CEP)
  • Integrácia na modul elektronických formulárov (MEF),
  • Integrácia na modul centrálneho úradného doručovania (CÚD).
• Zasielania notifikačných správ v prostredí elektronických služieb – integrácia na CNM ÚPVS
• Nevizuálna služba pre MV SR (Náhrada MINIK) – optimalizované nevizuálne služby
• Monitoring služieb a zber spätnej väzby pri používaní elektronických služieb - Konsolidovaná Analytická Vrstva (KAV)
• Interné integrácie
  • Integrácia na špecializovaný portál ÚGKK - kúpa a predaj nehnuteľnosti na bývanie
  • Integrácia na špecializovaný portál ÚGKK - Žiadosť o zmenu osobných údajov
  • Integrácia na systém elektronického doručovania ELODO
  • Integrácia na centrálnu databázu – „single source of truth“ ÚGKK
  • Integrácia na QES portál – za účelom pečatenia a validácie dokumentov
  • Integrácia na interný IAM
  • Integrácia na ISZS

• ŽS 02 Kúpa nehnuteľnosti
• ŽS 06 Presťahovanie
• ŽS15 Uzavretie manželstva

• Štandardizácia budúcich integrácií, ktorá zahŕňa aj stanovenie integračných pravidiel a zodpovedností
• Integrácia na referenčné registre
• Informovanie klienta o vybavení jeho podania prostredníctvom notifikácií
• Kontinuálne zlepšovanie služieb zavedením monitoringu služieb a zberu spätnej väzby
• Zvýšenie kvality poskytovaných elektronických služieb štátu

• Orientácia na používateľa
  • Jednoduchá prístupnosť služieb
  • Kvalita a spoľahlivosť
• Prirodzene digitálna verejná správa
  • Prednostné využívanie digitálnych služieb a dát pre rozhodovanie
• Údaje sú chránené
  • Maximalizácia zdieľania a spoločného využívania údajov pre lepšie rozhodovanie
  • Údaje sú starostlivo chránené
  • Údaje sú konzistentné a zrozumiteľné
• Transparentnosť VS
  • Auditovateľnosť - priebežná informácia o stave spracovania procesu, podania
  • Spätná väzba
  • Občan má prehľad o spracúvaní svojich údajov orgánmi verejnej moci
  • Kontrola nad procesmi verejnej správy - Otvorenosť údajov
  • Transparentná informatizácia verejnej správy
• Bezpečnosť
  • Optimálna úroveň bezpečnosti
  • Včasné riešenie bezpečnosti
  • Dostupnosť - odolnosť voči výpadkom

3.3Zainteresované strany/Stakeholderi

3.4Ciele projektu

3.5Merateľné ukazovatele (KPI)

3.6Špecifikácia potrieb koncového používateľa

Projekt je zameraný na integrácie systémov a koncový používateľ – osoby priamo z výstupmi projektu neprichádzajú do styku.

 3.7Detailný opis obmedzení a predpokadov

V rámci realizácie projektu Rezortnej integračnej platformy GKK (RIP GKK) boli definované nasledovné kľúčové predpoklady a obmedzenia, ktoré významne ovplyvňujú rozsah, realizáciu a plánovanie projektu.

Predpoklady

1. Predpoklad rozsahu projektu:
   Projekt RIP GKK je zameraný primárne na zavedenie technologickej platformy a vybudovanie integračného prostredia pre podporu riešenia životných situácií v rezorte.
   Ostatné budúce integračné požiadavky a rozšírenia platformy budú riešené v samostatných rozvojových projektoch. Súčasný projekt vytvára technologický základ a realizuje len vybrané integračné väzby, ktoré sú potrebné na začiatok spracovania životných situácií.
2. Predpoklad existencie preexistentného softvéru:
   S ohľadom na časové a kapacitné obmedzenia projektu sa predpokladá existencia alebo dostupnosť adaptačných konektorov (adaptérov) pre integráciu so spoločnými modulmi verejnej správy.
   Predpokladá sa, že tieto adaptéry budú štandardizované, pripravené na konfiguráciu a umožnia rýchlu integráciu bez potreby rozsiahleho vývoja. Očakáva sa tiež ich relatívne rýchla akceptácia a nasadenie.
3. Predpoklad postupnej realizácie v inkrementoch:
   Dodávka projektu je rozdelená do troch inkrementov s postupným rozširovaním funkcionalít a integrácií:
   • Prvý inkrement: Zavedenie technologickej platformy a realizácia integrácií s preexistentným softvérom, vrátane nasadenia dostupných adaptérov.
   • Druhý inkrement: Realizácia nevyhnutných integrácií potrebných pre zabezpečenie spracovania podaní pre vybrané životné situácie. Tento inkrement sa zameriava na vytvorenie funkčných tokov a zabezpečenie plnej prevádzky vybraných životných situácií.
   • Tretí inkrement: Realizácia ďalších integrácií na centrálne komponenty a iné informačné systémy verejnej správy (ISVS), stále v rozsahu riešenia životných situácií. Tento inkrement rozširuje integračné väzby a funkcionalitu v nadväznosti na potreby spracovania životných situácií v širšom kontexte.

Obmedzenia

• Projekt nepokrýva všetky integračné požiadavky rezortu. Rozšírenia platformy a nové integračné väzby budú predmetom ďalších projektov podľa stanovených priorít a kapacít.
• Časové obmedzenie projektu neumožňuje rozsiahly vývoj nových adaptérov; preto sa vyžaduje dostupnosť existujúcich riešení, ktoré je možné rýchlo prispôsobiť.
• Prvá verzia platformy bude technologická s obmedzeným počtom integrácií, pričom funkcionalita bude postupne rozširovaná najprv cez inkrementy v rozsahu životných situácií a v následných projektoch na úplné potreby rezortu GKK.

3.8Vyhodnotenie rizík a závislostí

Tabuľka 5 Prehľad najzávažnejších rizík a závislostí

3.9Detailný opis rozpočtu a jeho prínosov

3.9.1 Sumarizácia nákladov a prínosov

Odhad ceny implementácie BP v rámci projektu budovania rezortnej integračnej platformy predstavuje
986 211 € s DPH  / zmenová požiadavka v prevádzke  nad 200 000 EUR do 1 000 000 EUR vrátane).

Produktový zoznam požiadaviek tvorí 10 biznis požiadaviek, z ktorých je 8 MMP (minimal marketable products), cez dodanie ktorých bude sledované splnenie míľnikov komponentu POO.

Produktový zoznam požiadaviek je súčasťou Konceptov realizácie ImP pre Projekt implementácie zmenových

 požiadaviek pre ŽS 2, ŽS6 a ŽS15 pre ÚGKK SR, časť B.

3.9.2 Zdroj financovania

Projekt rezortnej integračnej platformy bude financovaný výhradne na účely vytvorenia a nasadenia samotnej platformy a podpory počas prvého roku po dodaní, pričom financovanie bude zabezpečené z prostriedkov Plánu obnovy a odolnosti (POO).Cieľom je jej uvedenie do prevádzky najneskôr v prvom štvrťroku 2026. Po dokončení nasadenia platformy bude prevádzka a ďalší rozvoj zabezpečený Úradom pre geodéziu, kartografiu a katastrálne veci (UGKK) prostredníctvom ďalších nasledovných projektov, ktoré zabezpečia jej dlhodobú udržateľnosť a prispôsobenie sa dynamickým potrebám verejnej správy.

3.10Harmonogram projektu

3.11Návrh organizačného zabezpečenia projektu (projektový tím)

Riadiaci výbor projektu

Projektový team, pozícia, oddelenie a rola v projekte.

 4.LEGISLATÍVA

V rámci projektu nebudú riešené legislatívne zmeny.

5.NÁHĽAD ARCHITEKTÚRY

5.1 Stanovenie alternatív architektúry riešenia

5.1.1Stanovenie alternatív v biznisovej vrstve architektúry

Nižšie sa nachádzajú alternatívy, ktoré sú následne posudzované na základne kritérií v MCA. 

Alternatívy riešenia 

Pre naplnenie hlavného cieľa projektu boli stanovené nasledovné kritéria, ktoré predovšetkým vychádzajú z potreby naplnenia požiadaviek v rámci implementácie prioritnej ŽS2 Kúpa a vlastníctvo nehnuteľnosti na bývanie, ale tiež z potrieb budúceho rozvoja a prevádzky integrácii v rámci ÚGKK.

Alternatívy:

Alternatíva 1: Zachovanie súčasného stavu, bez jednotného rozvoja existujúcich systémov a integrácií

Alternatíva 2: Centrálne budovanie integrácií

Alternatíva 3: Budovanie integrácií pre každý projekt/systém zvlášť

V zmysle vyhodnotenia MCA bude ďalej riešená a posudzovaná biznis alternatíva č. 2: Centrálne budovanie integrácií, ktorá spĺňa všetky stanovené kritéria, ktoré majú vplyv na projekt. 

5.1.2 Stanovenie alternatív v aplikačnej vrstve architektúry

Na aplikačnej úrovni je potrebné adresovať nasledovné kritéria: 

Zvažované alternatívy implementácie na aplikačnej úrovni sú nasledovné:

Alternatíva 1 – Vybudovanie štandardnej jednotnej integračnej platformy

Implementácia novej centrálnej platformy, ktorá bude centralizovať všetky požadované integračné rozhrania ÚGKK. Platforma poskytne štandardizované rozhrania pre interné aj externé systémy a v čase nasadenia nahradí doterajšie integrácie (napr. ÚPVS IAM a ÚPVS eDesk).

Výhody: zníženie počtu ad-hoc integrácií, lepšia dátová konzistencia

Nevýhody: vyššie počiatočné náklady, dlhší čas implementácie, výrazný dopad na externé subjekty využívajúce existujúce integrácie

Alternatíva 2 – Postupné budovanie novej rezortnej integračnej platformy s dočasnou koexistenciou so starými/náhradnými riešeniami

Existujúce integrácie budú podľa možností obnovy po kybernetickom útoku dočasne pokryté starými/náhradnými riešeniami, kým nové integračné požiadavky budú riešené v rámci novobudovanej rezortnej platformy (RIP). Pôvodné funkcionality nad rámec tohto projektu budú postupne migrované do RIP v následných budúcich projektoch rozvoja RIP.

Výhody: zníženie rizika pri prechode na nové riešenie, flexibilita, možnosť postupnej implementácie, nižšia záťaž na vývoj a testovanie, rozloženie dopadov na existujúce integrácie s externým prostredím v čase

Nevýhody: dočasná komplexita pri správe viacerých riešení

Alternatíva 3 – Modernizácia pôvodnej platformy ESKN na Oracle ESB

Pôvodná platforma ESKN založená na Oracle ESB nie je po kybernetickom útoku funkčná a jej obnova nie je možná. Z dôvodu bezpečnostných rizík, technologického zastarania a vysokých nákladov sa táto alternatíva nepovažuje za realizovateľnú. Upgrade a modernizácia pôvodnej platformy predstavuje alternatívu 2.

Nevýhody: neobnoviteľný stav po útoku, vysoké náklady, služby nie sú v súlade s požiadavkami na budúci rozvoj

Na základe analýzy bola ako najvhodnejšia zvolená Alternatíva 2 – postupné vybudovanie novej rezortnej integračnej platformy s dočasnou koexistenciou. Toto riešenie poskytuje optimálnu rovnováhu medzi rizikom, nákladmi a flexibilitou implementácie

5.1.3 Stanovenie alternatív v technologickej vrstve architektúry

Nie je potrebný HW, bude prevádzkované na súčasnej infraštruktúre

5.2 Náhľad architektúry a popis budúceho cieľového produktu

5.3 Biznis vrstva

5.3.1 Návrh riešenia v biznis vrstve architektúry

V dokumentoch KRIMP (Koncept realizácie Implementačného plánu) boli identifikované biznis požiadavky, z ktorých vychádzajú požiadavky a budúci stav novej rezortnej integračnej platformy.

Obr.  2 Biznis architektúra - TO BE

Biznis funkcie novej Rezortnej integračnej platformy budú pokrývať predovšetkým podporu dvoch elektronických služieb, poskytovaných ÚGKK. Dôjde k náhrade existujúcej integrácie voči elektronickým službám a spoločným modulom ÚPVS rezortnou integračnou platformou:

• Podávanie návrhu na vklad – Kúpa a predaj nehnuteľnosti na bývanie (ŽS 02 - Kúpa nehnuteľností) - Nová koncová služba podávanie návrhu na vklad zameraná špecificky na – Kúpu a predaj nehnuteľnosti na bývanie
• Podávanie návrhu na doplnenie údajov na list vlastníctva do katastra nehnuteľností – Zmena údajov vlastníka A.1.1.4 (ŽS 06 - Presťahovanie a ŽS 15 – Uzavretie manželstva)
• Poskytovanie informácie z katastra nehnuteľností o nehnuteľnostiach a o právach k nehnuteľnostiam – optimalizácia služieb za účelom zlepšenia efektívnej integrácie medzi ISVS
• Poskytovanie informácie z IS zoznamu stavieb

Podpora služieb zahŕňa nové funkcionality RIP medzi ktoré patrí:

• Získavanie údajov - predstavuje prepojenie s referenčnými registrami IS CSRÚ. Zabezpečenie prijímania údajov medzi OVM - Poskytnutie rozšírenej množiny dát a zmien nad objektami evidencie.
• Monitoring služieb - bude podporovať zber údajov o podaniach nevizuálnou službou
• Zasielanie notifikácií - bude podporovať odosielanie notifikácií

Nasadením RIP budú upravené nasledovné existujúce biznis funkcie:

• Poskytovanie špecifických informácií - zabezpečenie poskytovania údajov medzi OVM - Poskytnutie rozšírenej množiny dát a zmien nad objektami evidencie. Poskytovanie údajov z IS Zoznam stavieb pre ostatné OVM z rezortnej integračnej platformy ÚGKK SR.
• Zápis práv k nehnuteľnostiam - predovšetkým návrh na vklad pre kúpu nehnuteľnosti na bývanie
• Katastrálny operát a aktualizácia - predovšetkým doplnenie údajov na list vlastníctva.

5.3.2 Prehľad koncových služieb – budúci stav (TO BE):

Tabuľka 11Prehľad koncových služieb - budúci stav (TO BE)

Účel jednotlivých koncových služieb v kontexte predmetu projektu

• ks_nová           Kúpa a predaj nehnuteľnosti na bývanie – podanie návrhu na vklad pre existujúcu nehnuteľnosť na bývanie
• ks_nová           Notifikácia klientovi o stave konania – notifikácie klientom cez CNM ÚPVS
• ks_336479 Poskytovanie informácie z katastra nehnuteľností o nehnuteľnostiach  – poskytovanie údajov pre MVSR
• ks_336480 Poskytovanie informácie z katastra nehnuteľností o právach k nehnuteľnostiam – poskytovanie údajov pre MVSR
• ks_336484 Poskytovanie výpisu z listu vlastníctva z katastra nehnuteľností – poskytovanie údajov pre MVSR
• ks_nová           Poskytovanie údajov monitoringu a spätnej väzby do KAV – poskytovanie údajov monitoringu a spätnej väzby do centráneho modulu KAV
• ks_336462       Podávanie návrhu na doplnenie údajov na list vlastníctva do katastra nehnuteľností – zapracovanie zmeny údajov vlastníka na vybraných nehnuteľnostiach v rozsahu zmeny adresy trvalého pobytu
• ks_nova           Poskytovanie informácií zo zoznamu stavieb

5.3.3 Organizačné zmeny a Procesy dotknuté navrhovaným riešením

V rámci projektu nebudú realizované zmeny procesov a organizačné zmeny.

5.3.4 Jazyková podpora lokalizácia

Požiadavky na jazykovú lokalizáciu riešenia a používateľské prostredie bude implementované v slovenskom jazyku.

5.4 Aplikačná vrstva

5.4.1 Návrh riešenia v aplikačnej vrstve architektúry

Aplikačná vrstva UGKK v rozsahu riešenia pozostáva z viacerých informačných systémov podporujúcich výkon funkcií a činností definovaných na úrovni biznis architektúry. Je rozdelené primárne do nasledujúcich oblastí:

Moduly front-endu – Špecializovaný portál:  

Modernizovaný špecializovaný portál doplnkových služieb katastra nehnuteľností bude komunikovať so spoločnými modulmi prostredníctvom rezortnej integračnej platformy a bude využívať údaje získané cez RIP pre potreby predvypĺňania elektronických formulárov.

Centrálne systémy ÚGKK: 

V rámci projektu bude budovaná Rezortná integračná platforma (RIP) GKK (isvs_14801), ktorá plní funkciu nového centrálneho integračného komponentu pre poskytovanie a konzumovanie údajov a služieb interných systémov ÚGKK smerom k externým integrovaným IS 

Rezortná integračná platforma implementuje nasledovné funkcie/integrácie: 

• Konzumovanie integračných služieb
  • Integrácia na isvs_5836 IS CSRÚ/CPDI ako realizácia Modulu procesnej integrácie a integrácie údajov
    • Register a identifikátor právnických osôb, podnikateľov a orgánov verejnej moci (RPO)
    • Register fyzických osôb
    • Základné číselníky – časť hlavička základného číselníka
    • Register adries
    • Štatistické číselníky a klasifikácie
  • Integrácia isvs_9513 Centrálna API manažment Platforma (CAMP) ako realizácia Modulu procesnej integrácie a integrácie údajov
    • Odosielanie notifikácii o stave platieb a konaní
  • Integrácia isvs  Konsolidovaná Analytická Vrstva (KAV)
    • Odosielanie informácii o používaní služieb

• Poskytovanie služieb na integráciu externým subjektom
  • sluzba_is_1484 Poskytnutie informácie z KN o nehnuteľnostiach (v zmysle ZS06 pre MVSR)
  • sluzba_is_1485 Poskytnutie informácie z KN o právach k nehnuteľnostiam (v zmysle ZS06 pre MVSR)
  • sluzba_is_1489 Poskytnutie výpisu z listu vlastníctva z KN (v zmysle ZS06 pre MVSR)
  • nová AS Podávanie návrhu na vklad do katastra nehnuteľností – kúpa a predaj nehnuteľnosti na bývanie
  • nová AS Notifikácia klientovi o stave konania
  • nová AS Poskytovanie informácií zo zoznamu stavieb

• Manažment integrácii
  • Web rozhranie pre manažment platformy
  • Sledovanie stavu jednotlivých komponentov (adaptéry, procesy)
  • Správa bežiacich procesov (Ukončenie, prerušenie, spustenie, procesov)
  • Konfigurovateľnosť bez potreby zásahov dodávateľa a programovania
  • Auditné záznamy
  • Štatistika a sledovanie služieb

• Elektronická podatelna
  • Prijatie podania  a automatizovaná kontrola prichádzajúceho podania
  • nová AS Adaptéry na centrálne komponenty

Externé systémy:  

Projekt počíta s integráciou na: 

• isvs_9513 Centrálna API manažment Platforma  (CAMP) ako realizácia Modulu procesnej integrácie a integrácie údajov
• isvs_5836 IS CPDI ako realizácia Modulu procesnej integrácie a integrácie údajov  pre komunikáciu s CNM
•  

Agendové informačné systémy

Podporujú výkon konkrétnej agendy a realizujú kľúčové aplikačné služby. 

Agendové informačné systémy poskytujú interne služby a údaje pre budované integrácie a tiež konzumujú získavané údaje.

Architektúra aplikačných systémov je zobrazená na nasledovnom obrázku:

Obr.  3 Aplikačná architektúra - TO BE

5.4.2 Rozsah informačných systémov – budúci stav (TO BE)

Tabuľka 12 Rozsah informačných systémov - budúci stav (TO BE)

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

V súčasnom stave sú využívané nasledovné spoločné moduly podľa zákona č. 305/2013  e-Governmente.

Aktuálne neexistuje integrácia na IS CPDI.

Tabuľka 13 Využívanie nadrezortných a spoločných ISVS – súčasný stav (AS IS)

5.4.4 Prehľad plánovaných integrácií na nadrezortné ISVS – spoločné moduly podľa zákona č. 305/2013 Z.z. o  e-Governmente – budúci stav (TO BE)

Tabuľka 14 Prehľad plánovaných integrácií na spoločné moduly – budúci stav (TO BE)

5.4.5 Prehľad plánovaných integrácií na iné ISVS  – budúci stav (TO BE)

Služby iných ISVS pre integráciu sú plánované pre MVSR, budúce ďalšie integrácie v rámci projektu budú realizované prostredníctvom spoločných modulov a teda nasledovných ISVS:

• isvs_9513 Centrálna API manažment Platforma  (CAMP) ako realizácia Modulu procesnej integrácie a integrácie údajov
• isvs_5836 IS CSRÚ ako realizácia Modulu procesnej integrácie a integrácie údajov

Tabuľka 15 Prehľad plánovaných integrácií na iné ISVS  – budúci stav (TO BE)

5.4.6 Aplikačné služby pre Koncové služby – budúci stav (TO BE)

Tabuľka 16 Aplikačné služby pre Koncové služby – budúci stav (TO BE)

5.4.7 Aplikačné služby na integráciu – budúci stav (TO BE)

Tabuľka 17 Aplikačné služby na integráciu – budúci stav (TO BE)

5.5    Dátová architektúra

5.5.1    Objekty evidencie

Nie je relevantné pre projekt integračného charakteru

5.5.2    Referenčné údaje

V rozsahu projektu nie sú žiadne údaje definované ako referenčné.

5.5.3    Poskytovanie údajov z ISVS do IS CPDI – budúci stav (TO BE)

Projekt nerealizuje poskytovanie nových objektov evidencie z ISVS do IS CPDI.

5.5.4    Konzumovanie údajov z IS CPDI – budúci stav (TO BE)

Tabuľka 21 Konzumovanie údajov z IS CPDI – budúci stav (TO BE)

5.5.5    Identifikácia údajov a subjektov pre konzumovanie alebo poskytovanie údajov do/z CPDI (CSRÚ)

5.5.6    Kvalita a čistenie údajov

Nie je relevantné pre projekt.

5.5.7    Otvorené údaje

Nie je relevantné pre projekt.

5.5.8    Analytické údaje

Nie je relevantné pre projekt.

5.5.9    Moje údaje

Nie je relevantné pre projekt.

5.5.10    Prehľad jednotlivých kategórií údajov

Nie je relevantné pre projekt.

5.6    Technologická architektúra

5.6.1    Návrh riešenia technologickej architektúry

Zmeny v rámci implementácie aplikačných zmien budú riešené na súčasnej infraštruktúre ÚGKK. 

5.6.2    Požiadavky na výkonnostné parametre, kapacitné požiadavky – budúci stav (TO BE)

Nerelevantné, bude riešené na súčasnej infraštruktúre ÚGKK. 

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

Výstupy projektu nebudú využívať služby vládneho cloudu.

5.7    Bezpečnostná architektúra

5.7.1    Návrh riešenia bezpečnosti

Súčasný stav (AS-IS) bezpečnostnej architektúry
V súčasnosti informačný systém katastra nehnuteľností po kybernetickom útoku nedisponuje centralizovanou integračnou platformou. Integrácie s externými subjektmi sú realizované individuálne, prostredníctvom API rozhraní a ad-hoc komunikačných kanálov. Neexistuje jednotný prístup k zabezpečeniu identity, jednotné logovanie integračných volaní, ani centralizovaný monitoring a detekcia incidentov v integračnej vrstve. 

Budúci stav (TO-BE) bezpečnostnej architektúry
Navrhované riešenie počíta so zavedením modernej a rezortnej integračnej platformy, ktorá sa stane. Táto platforma bude postavená s dôrazom na splnenie požiadaviek kategórie III podľa vyhlášky č. 179/2020 Z.z., ako aj ďalších relevantných právnych predpisov vrátane zákona č. 69/2018 Z.z. o kybernetickej bezpečnosti, zákona č. 18/2018 Z.z. o ochrane osobných údajov (GDPR) a štandardov IT verejnej správy podľa vyhlášky č. 78/2020 Z.z.

Budúca bezpečnostná architektúra bude vychádzať z nasledujúcich princípov:
-    Centralizované logovanie a monitoring aktivít na účely detekcie a riešenia bezpečnostných incidentov,
-    Zabezpečená komunikácia medzi systémami výhradne prostredníctvom protokolov podporujúcich šifrovanie,
-    Segmentácia siete a izolácia integračnej vrstvy v samostatných bezpečnostných zónach.

5.7.2    Určenie obsahu bezpečnostných opatrení

Tabuľka 33 Určenie zdrojov a obsahu minimálnych bezpečnostných opatrení

5.7.3    Legislatívne, právne, štatutárne, regulačné a zmluvné požiadavky,

Integračná platforma bude vybudovaná v súlade s platnou legislatívou a technickými normami upravujúcimi informačné technológie a bezpečnosť vo verejnej správe. Platforma bude súčasťou informačného systému verejnej správy kategórie III podľa vyhlášky č. 179/2020 Z.z., a preto bude podliehať požiadavkám na vypracovanie bezpečnostného projektu v zmysle § 23 ods. 1 a 2 zákona č. 95/2019 Z.z. 

Integračná vrstva bude spĺňať minimálne bezpečnostné opatrenia v rozsahu kategórie III, vrátane zabezpečeného prenosu dát, autentifikácie a autorizácie prístupov, logovania a monitorovania činností, ochrany integrity a dostupnosti služieb. Architektúra platformy bude zohľadňovať princípy vyplývajúce z vyhlášky č. 78/2020 Z.z. o štandardoch pre IT verejnej správy a bude rešpektovať rámec kybernetickej bezpečnosti podľa zákona č. 69/2018 Z.z. a vykonávacej vyhlášky č. 362/2018 Z.z.

5.7.4    Riešenie autentifikácie a prístupov používateľov

K rezortnej integračnej platforme nebudú mať prístup Externý používatelia a z pohľadu Interných používateľov iba rola administrátora rezortnej integračnej platformy prostredníctvom administrátorského účtu rezortnej integračnej platformy.

6.    PREVÁDZKA A ÚDRŽBA VÝSTUPOV PROJEKTU

6.1    Návrh riešenia prevádzky a údržby

Prevádzka a údržba diela bude počas prvého roka po jeho nasadení zabezpečená v rámci záručnej podpory poskytovanej dodávateľom, ktorá bude zahrnutá v cene diela. Táto podpora zahŕňa podporu prevádzky systému v súlade s nasledujúcimi kapitolami . 

Po ukončení záručnej lehoty bude technická podpora, údržba a nadväzujúce prevádzkové služby zabezpečená prostredníctvom samostatne obstarávanej SLA (Service Level Agreement), ktorá umožní pokračovanie v plynulej a spoľahlivej prevádzke systému v súlade s prevádzkovými a bezpečnostnými požiadavkami organizácie. Tento model zabezpečuje oddelenie implementačnej fázy od dlhodobej prevádzky a umožňuje transparentné zabezpečenie služieb po ukončení záruky.

6.2    Zabezpečenie podpory používateľov a prevádzky

Riešenie, ktoré je predmetom implementačného projektu, nemá priamych koncových používateľov, poskytuje však služby pre ďalšie aplikácie, moduly a systémy.

Podpora prevádzky bude realizovaná cez 3 úrovne podpory, s nasledujúcim označením a obsahom činnosti:
•    Podpora L1 (podpora 1. stupňa - Level 1) - začiatočná úroveň podpory, ktorej základnou funkciou je zhromaždiť informácie, previesť základnú analýzu a určiť príčinu problému a jeho klasifikáciu. Typicky sú v úrovni L1 riešené priamočiare a jednoduché problémy a základné diagnostiky, overenie dostupnosti jednotlivých vrstiev infraštruktúry (sieťové, operačné, vizualizačné, aplikačné atď.) a základné užívateľské problémy (typicky zabudnutie hesla), overovanie nastavení SW a HW atď. Je zabezpečovaná  prostredníctvom pracoviska jednotného kontaktného miesta.

•    Podpora L2 (podpora 2. stupňa – Level 2 -  postúpenie požiadaviek od L1) – riešiteľské tímy s hlbšou technologickou znalosťou danej oblasti. Riešitelia na úrovni Podpory L2 nekomunikujú priamo s koncovým užívateľom, ale sú zodpovední za poskytovanie súčinnosti riešiteľom 1. úrovne podpory pri riešení eskalovaného hlásenia, čo mimo iného obsahuje aj spätnú kontrolu a podrobnejšiu analýzu zistených dát predaných riešiteľom 1. úrovne podpory. Výstupom takejto kontroly môže byť potvrdenie, upresnenie, alebo prehodnotenie hlásenia v závislosti na potrebách Objednávateľa. Primárnym cieľom riešiteľov na úrovni Podpory L2 je dostať Hlásenie čo najskôr pod kontrolu a následne ho vyriešiť - s možnosťou eskalácie na vyššiu úroveň podpory – Podpora L3.

•    Podpora L3 (podpora 3. stupňa) - Podpora 3. stupňa predstavuje najvyššiu úroveň podpory pre riešenie tých najobtiažnejších Hlásení, vrátane prevádzania hĺbkových analýz a riešenie extrémnych prípadov.

Typické zodpovednosti za realizáciu podpory sú: 
•    L1 (Level 1: priamy kontakt zákazníka) - jednotný kontaktný bod bude zabezpečovaný pracoviskom v správe Úradu geodézie, kartografie a katastra Slovenskej republiky.
•    L2 (Level 2: postúpenie požiadaviek od L1) - riešiteľské tímy s hlbšou znalosťou rezorntej integračnej platformy budú tvorené pracovníkmi Výskumného ústavu geodézie a kartografie v Bratislave 
•    L3 (Level 3, postúpenie požiadaviek od L2) - na základe zmluvy o dodávke inf. systému zabezpečí externý dodávateľ po dobu jedného roka, riešenie prevádzkových incidentov a servisných požiadaviek.
 

Tabuľka 34 Prehľad riešenia zabezpečenia podpory používateľov a prevádzky

6.3 Riešenie incidentov v prevádzke - parametre úrovní služby

Parametre služby riešenia incidentov v prevádzke sú špecifikované na základe určenia priority incidentu pomocou kombinácie jeho naliehavosti a dopadu podľa najlepších skúseností z praxe (best practice) z oblasti manažmentu IT služieb (  Information Technology Infrastructure Library - ITIL V3) nasledovným spôsobom:

Incident - za incident je považovaná každá nahlásená alebo inak zistená relevantná skutočnosť týkajúca sa aktíva (informačného systému) alebo jeho časti, ktorého nedostupnosť alebo nefunkčnosť má vplyv na poskytovanie služieb.

Tabuľka 35 Klasifikácia Naliehavosti incidentu

Tabuľka 36 Klasifikácia Závažnosti incidentu

Určenie priority incidentu je kombináciou dopadu a naliehavosti podľa nasledovnej matice:

Tabuľka 37 Určenie priority incidentu

Parametre služby Riešenia incidentov v prevádzke:

Tabuľka 38 Parametre služby Riešenia incidentov v prevádzke

Vysvetlivky k tabuľke

(1) Reakčná doba je čas medzi nahlásením incidentu verejným obstarávateľom (vrátane užívateľov IS, ktorí nie sú v pracovnoprávnom vzťahu s verejným obstarávateľom) na helpdesk úrovne L3 a jeho prevzatím na riešenie.

(2) DKVI (Doba konečného vyriešenia incidentu) - znamená čas obnovenia štandardnej prevádzky - čas medzi nahlásením incidentu verejným obstarávateľom a vyriešením incidentu poskytovateľom podpory (do doby, kedy je funkčnosť prostredia znovu obnovená v plnom rozsahu). Doba konečného vyriešenia incidentu od nahlásenia incidentu verejným obstarávateľom sa počíta počas celého dňa. Do tejto doby sa nezarátava čas potrebný na nevyhnutnú súčinnosť verejného obstarávateľa, ak je potrebná pre vyriešenie incidentu. V prípade potreby je poskytovateľ podpory oprávnený požadovať od verejného obstarávateľa schválenie riešenia incidentu.

(3) Spoľahlivosť - maximálny počet incidentov za kalendárny mesiac. Každá ďalšia chyba nad stanovený limit spoľahlivosti sa počíta ako začatý deň omeškania bez odstránenia vady alebo incidentu. Duplicitné alebo technicky súvisiace incidenty (zadané v rámci jedného pracovného dňa, počas pracovného času 8 hodín) sú považované ako jeden incident.

(4) Incidenty nahlásené verejným obstarávateľom poskytovateľovi podpory v rámci testovacieho prostredia majú prioritu 3 a nižšiu. Vzťahujú sa výhradne k dostupnosti testovacieho prostredia. Za incident v testovacom prostredí sa nepovažuje incident vztiahnutý k práve testovanej funkcionalite.

Vyššie uvedené SLA parametre nebudú použité pre nasledovné služby:

• Služby systémovej podpory na požiadanie (nad paušál)
• Služby realizácie aplikačných zmien vyplývajúcich z legislatívnych a metodických zmien (nad paušál)

Pre tieto služby budú dohodnuté osobitné parametre dodávky.

6.4 Požadovaná dostupnosť informačného systému:

6.5    Požiadavky na ľudské zdroje potrebné pre zabezpečenie prevádzky

Uveďte požiadavky na personálne zabezpečenie prevádzky budovaného systému (TO BE) a súvisiacich prevádzkových procesov.
Uveďte požiadavky na zabezpečenie potrebných školení a certifikátov pre používateľov, pracovníkov podpory, prevádzky a správy budovaného systému.

6.6    Požiadavky na zdrojové kódy

Dodávka rezortnej integračnej platformy bude pozostávať z troch častí: technologickej platformy (poskytnutie licencie a podpory namiesto zdrojových kódov), existujúcich adaptérov (s odovzdaním ich zdrojových kódov) a vlastných, na mieru vyvinutých adaptérov (s povinným odovzdaním kompletných zdrojových kódov). Objednávateľ získa dispozičné práva ku všetkým dodaným zdrojovým kódom, dokumentácii a výstupom diela; zdrojové kódy budú plne kompilovateľné, riadne okomentované a zdokumentované, archivované v Git repozitári a odovzdané pri záverečnom míľniku projektu. Zmluvné podmienky budú obsahovať ustanovenia na predchádzanie závislosti od jediného dodávateľa (tzv. vendor lock-in). Všetky uvedené požiadavky budú realizované v súlade so zákonom č. 95/2019 Z.z. o informačných technológiách vo verejnej správe, metodickým usmernením MIRRI SR č. 024077/2023 a s príslušnými inštrukciami k používaniu licencie EUPL. 

V zmluve budú dohodnuté pravidlá pre odovzdanie, správu a archiváciu zdrojových kódov, ktoré zabezpečia, že objednávateľ bude mať vždy k dispozícii aktuálne verzie. Odovzdanie zdrojových kódov prebehne minimálne na konci projektu (počas záverečnej akceptácie celého diela), pričom môže byť dohodnuté aj priebežné odovzdávanie po hlavných míľnikoch projektu. 

Pri každom odovzdaní zdrojového kódu sa vyhotoví preberací protokol, v ktorom objednávateľ potvrdí prevzatie kódu. Objednávateľ má právo pred podpisom protokolu skontrolovať odovzdané zdrojové kódy (napr. vykonať audit kvality, skúsiť ich zkompilovať).

Zdrojové kódy budú uložené a archivované v centrálnom repozitári zdrojových kódov spravovanom štátom (podľa vyhlášky č. 78/2020 Z.z. § 31) alebo v repozitári objednávateľa. Po finálnej akceptácii diela dodávateľ poskytne kompletný balík zdrojových kódov aj v offline forme (napr. na elektronickom médiu) pre archívne účely objednávateľa. V prípade zmien počas trvania zmluvy (aktualizácie, záručné opravy, nové verzie) platí, že dodávateľ priebežne odovzdáva aktualizovaný zdrojový kód k daným úpravám bez zbytočného odkladu (najneskôr pri odovzdaní upravenej funkčnosti do užívania). 

Preberanie zdrojových kódov bude naviazané na fakturačné míľniky projektu. Objednávateľ uhradí príslušnú časť ceny diela až po úspešnom odovzdaní a prevzatí zdrojových kódov za danú etapu. Najmä záverečná fakturácia (záverečná splátka) bude podmienená tým, že dodávateľ odovzdá kompletné zdrojové kódy celého riešenia a relevantnú dokumentáciu. 
V prípade predčasného ukončenia projektu alebo zmluvy musí dodávateľ odovzdať aktuálny zdrojový kód ku dňu ukončenia, inak nedôjde k uvoľneniu platby (táto podmienka bude taktiež zakotvená v zmluve).

7.    OPIS IMPLEMENTÁCIE PROJEKTU A PREBERANIA VÝSTUPOV PROJEKTU

Implementácia a preberanie výstupov projektu bude realizované v súlade s Vyhláškou Ministerstva investícií, regionálneho rozvoja a informatizácie Slovenskej republiky č. 401/2023 Z. z. o riadení projektov a zmenových požiadaviek v prevádzke informačných technológií verejnej správy v zmysle ustanovení podľa § 5 a nasledovných ustanovení. 

8.    ODKAZY

Doplňte odkazy na iné existujúce materiály, ktoré sú zdrojovými informáciami. V maximálnej miere sa vyhnite duplikovaným informáciám a ich aktualizácii na viacerých miestach v priebehu prípravy prípravnej projektovej dokumentácie, jej pripomienkovania a hodnotenia.

9.    PRÍLOHY