PRÍSTUP K PROJEKTU
Vzor pre manažérsky výstup I-03
podľa vyhlášky MIRRI č. 401/2023 Z. z.

1.História dokumentu

2.Účel dokumentu

V súlade s Vyhláškou 401/2023 Z.z. je dokument I-03 Prístup k projektu určený na rozpracovanie detailných informácií prípravy projektu z pohľadu aktuálneho stavu, budúceho stavu a navrhovaného riešenia.

Dokument Prístup k projektu v zmysle vyššie uvedenej vyhlášky má obsahovať opis navrhovaného riešenia, architektúru riešenia projektu na úrovni biznis vrstvy, aplikačnej vrstvy, dátovej vrstvy, technologickej vrstvy, infraštruktúry navrhovaného riešenia, bezpečnostnej architektúry, špecifikáciu údajov spracovaných v projekte, čistenie údajov, prevádzku a údržbu výstupov projektu, prevádzkové požiadavky, požiadavky na zdrojové kódy. Dodávané riešenie musí byť v súlade so zákonom. Zároveň opisuje aj implementáciu projektu a preberanie výstupov projektu

2.1Použité skratky a pojmy

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

Funkcionálne (používateľské) požiadavky majú nasledovnú konvenciu:
FRxx

• U – užívateľská požiadavka
• R – označenie požiadavky
• xx – číslo požiadavky
  Nefunkčné (kvalitatívne, výkonové - Non Functional Requirements - NFR) požiadavky majú nasledovnú konvenciu:
  NRxx
• N – nefunkčná požiadavka (NFR)
• R – označenie požiadavky
• xx – číslo požiadavky
  Ostatné typy požiadaviek môžu byť ďalej definované objednávateľom

Všetky požiadavky uvedené v Prístupe k projektu v príslušných kapitolách, musia byť v súlade s funkčnými, nefunkčnými a technickými požiadavkami uvedenými v Katalógu požiadaviek I-04 (M-04 Analýza nákladov a prínosov - BC/CBA, karta: Katalóg požiadaviek).

3.Popis navrhovaného riešenia

Z pohľadu biznis architektúry chce mesto komplexne vyriešiť zber a správu údajov objektov evidencie vo svojom prostredí, pričom bude cieliť k jednoznačnému referencovaniu akýchkoľvek údajov na základe informácií o referenčnosti zdroja alebo mechanizmu, ktorý posúdi úroveň dôveryhodnosti ako aj časovej relevantnosti akéhokoľvek zdroja dát.

Projekt má za cieľ vytvoriť Centrálny dátový sklad, miesto do ktorého budú prispievať dátami všetky IS mesta, ktorý bude obsahovať funkčnosť a nástroje pre automatizované ukladanie, porovnávanie, referencovanie a poskytovanie/publikovanie údajov všetkým dotknutým IS v prostredí mesta ako aj systémom, ktoré si údaje vyžiadajú.

Zároveň chce zabezpečiť dátovou integráciou na centrálne registre automatizáciu referencovania údajov v rozsahu, ktorý je dostupný v IS CSRÚ, upraviť procesy a následne existujúce IS pri vybavovaní jednotlivých životných situácii tak, aby referent disponoval aktuálnymi údajmi potrebnými k vyriešeniu podania bez nutnosti ich prepisovania medzi IS.

V procese prvotnej inicializácie centrálneho dátového skladu využije existujúce dáta backoffice systému ako aj zber priestorových informácii (spolu s popisným údajmi), prostredníctvom Orchestračnej platformy a Dátového konektoru vytvorí základný komunikačný kanál medzi backoffice systémom a centrálnym dátovým skladom pre potreby budúcej výmeny dát medzi nimi a nastaví automatizáciu autorizácie prístupu k jednotlivým údajom na základe oprávnenosti jednotlivých IS.

Ďalej zavedie automatizované procesy zberu údajov z oblasti dopravy v centrálnom dátovom sklade z IoT zariadení aby do budúcna disponovalo údajmi pre správne rozhodnutia v oblasti riadenia dopravy.

Nad centrálnym dátovým skladom poskytne nový nástroj v podobe plnohodnotného GIS riešenia, ktorý sa stane pracovným nástrojom pre referentov a manažment mesta a zároveň publikačnm nástrojom pre občanov a tretie strany.

Obrázok č. 1  Alternatívy pre MCA

Zhrnutie / výsledok:

Výber alternatív prebiehal aplikovaním kritérií multikriteriálnej analýzy. V rámci MCA bola vybratá alternatíva 3, ktorá splnila všetky 4 zadefinované kritériá.

Preferovaný variant predstavuje plnohodnotnú realizáciu projektu v zmysle požiadaviek na komplexné, neduplicitné prostredie pre uloženie a správu dát, ich ďalšie využitie na analytické a publikačné účely.

Rovnako v rámci projektu dôjde k zavedeniu jednoznačnej referenčnosti údajov prostredníctvom Orchestračnej platformy v kombinácii s funkčným Centrálnym dátovým skladom. Mesto bude disponovať GIS nástrojom a nástrojom pre automatickú tvorbu a publikovanie Otvorených údajov.

4.Architektúra riešenia projektu

4.1Biznis vrstva

Obr. č.2 Biznis architektúra – AS IS

Aktuálna biznis architektúra MESTA v kontexte  poskytovania údajov je reprezentovaná:

• prístupovými FrontEnd kanálmi, ktoré zabezpečujú priamu elektronickú alebo písomnú komunikáciu s občanmi a podnikateľmi, prípadne ďalšími stakeholdermi,
• integračnou vrstvou mesta, ktorá aktuálne zabezpečuje v súčasnosti iba funkcionalitu prepojenia na Ústredný portál verejnej správy.

Kvalita dát: Mesto Prievidza dlhodobo bojuje s nedostatočnou kvalitou údajov, ktoré sú generované pri styku s občanom/podnikateľom/návštevníkom/inými tretími stranami. Údaje, ktoré sú spracúvané pri úradnom styku so stakeholdermi častokrát vykazujú niektoré z nižšie uvedených nedostatkov:

• duplicita údajov;
• neúplnosť údajov;
• preklepy;
• nekonzistencia údajov;
• úmyselne chybne vyplnené pole (zo strany stakeholdera – zľahčovanie úradného styku);
• nesprávny formát vložených údajov.

Vstupy z  priamej komunikácie so stakeholdermi v úrade, alebo prostredníctvom elektronických prostriedkov dlhodobo čelia horeuvedeným nedostatkom a v neúplnom/nevalidnom stave sa prenášajú do ISVS, ktorým mesto disponuje. Táto skutočnosť má za následok, že Mesto Prievidza dlhodobo bojuje s nízšou kvalitou získavaných a ukladaných dát, ktorých následne použitie na správu mesta je limitované rovnako ako ich publikácia smerom k verejnosti prostredníctvom Open Data formátov alebo prostredníctvom Webovej stránky mesta. Akékoľvek dáta určené na publikovanie je následne ešte pred publikovaním potrebné manuálne čistiť, prechádzať a kontrolovať, čo sa negatívne prejavuje na interných nákladoch mesta a samotnej efektivite výkonu agendy verejnej moci, nakoľko máme za to, že čisteniu dát by malo dochádzať jednorazovo a následne dáta vytvárať takými spôsobmi, aby nebolo potrebné vykonávať aktivity čistenia dát mesta opakovane, to znamená, že je potrebné prioritne odstraňovať príčiny a nie dôsledky. Dáta, ktoré mesto získava, spracúva, ukladá a poskytuje vyplývajú z legislatívnych povinností.

Okrem nevalidných dát, ktoré vznikajú na vstupe do ISVS Mesta Prievidza, identifikujeme ďalší problém, ktorý zásadným spôsobom vplýva na kvalitu údajov mesta a to je proces ich aktualizácie. Občan resp. iný stakeholder opomína svoju povinnosť hlásiť Mestu zmenu údajov alebo mu z povahy úkonu takáto povinnosť nevzniká, pričom pre mesto a jeho systémy je okrem kvality kritickým atribútom aj aktuálnosť údajov. Stakeholderi často krát opomínajú túto povinnosť aj voči iným OVM, ktoré sú v zmysle legislatívy referenčným alebo iným registrom pre potreby konaní realizovaných Mestom Prievidza. Aj keby sme pripustili 100% kvalitu dát v týchto registroch, Mesto Prievidza nevyužíva žiaden automatizovaný nástroj na aktualizáciu uložených dát v svojich lokálnych registroch a k aktualizácii dochádza viac menej náhodne v čase, keď stakeholder rieši inú agendu.

Vyššie uvedené pri istej miere zjednodušenia implikuje nasledovné závery:

• čím dlhšie mesto drží vo svojich IS dáta, tým je pravdepodobnejšie, že sú nevalidné;
• zamestnanci mesta pri styku s občanom sa dopúšťajú relatívnej vysokej chybovosti pri manipulácii (zápise údajov) do IS mesta;
• získavanie údajov z centrálnej autority, ktorá ručí za aktuálnosť a kvalitu vstupov sa dnes neaplikuje;
• dáta, ktoré mesto zverejňuje je potrebné manuálne kontrolovať a prácne čistiť, pričom neexistuje schéma, ktorá by túto aktivitu umožnila vykonať len jednorazovo a následne by zamedzila ďalšiemu vzniku chýb v údajoch.

Rovnaký záver je možné aplikovať aj na priestorové údaje, ktorými v súčasnom stave mesto disponuje. V minulosti mesto realizovalo pasport priestorových údajov, no postupom času sa tieto údaje stali neaktuálnymi.

Obr. č.3 Biznis architektúra – TO BE

Aktuálna biznis architektúra MESTA sa rozšíri o:

• získavanie údajov z CSRÚ za účelom ich využitia v procesoch mesta;
• poskytovanie otvorených údajov, ktoré budú občanom a podnikateľom dostupné cez Portál OpenData.gov
• Poskytovanie priestorových údajov a lokalizačných služieb, ktoré budú dostupné pre občanov, podnikateľov a pracovníkov MsÚ prostredníctvom GIS riešenia

Realizáciou projektu sa dosiahne:

• odstránenie chybovosti v aktuálne využívaných datasetoch mesta
• úprava systémov ISVS na front-office časti systému, kde dochádza ku kontaktu mesto-stakeholder (prevažne občan), kde v súčasnosti dochádza pri vkladaní údajov k chybám. V rámci tejto úpravy budú definované obmedzenia („constrains“) na úrovni ISVS, čo znemožní vložiť nevalidné
• Integrácia na centrálnu dátovú autoritu ako zdroj validných a aktuálnych údajov, ku ktorým bude mať Mesto Prievidza prístup (referenti budú môcť pracovať s aktuálnymi údajmi o stakeholderoch bez toho, aby títo museli nahlasovať zmeny mestu). Zdrojom zmien budú inštitúcie, ktorým je stakeholder povinný nahlasovať zmeny svojich údajov,
• Konsolidácia a referencovanie udajov v Centrálnom dátovom sklade pre ich ďalšie použitie internými a externými systémami
• Publikácia dát vo formáte Open Data
• Publikovanie priestorových údajov a ich využívanie na analytické účely spolu s lokalizačnými službami v rozhodovacích procesoch a pri riešení životných situácii
• Výstupom bude efektívnejší výkon agiend Mesta Prievidza, eliminácia tvorby duplicít a nevalídnych záznamov a naštartovanie procesu publikácie dátových setov.

4.1.1Prehľad koncových služieb – budúci stav:

4.1.2Jazyková podpora a lokalizácia

Jazyková podpora a lokalizácia bude v slovenskom jazyku.

4.2Aplikačná vrstva

Aplikačná architektúra – súčasný stav:

Obr. č.3 Aplikačná architektúra – súčasný stav

Front end mesta

Web aplikácia eGOV a webové sídlo mesta sú základnými komponentami front-office vrstvy riešenia  predstavujúce používateľské rozhranie pre verejnosť a implementované elektronické služby.

Integračná vrstva

Integračná vrstva / modul napojenia na externé IS slúži ako komunikačná infraštruktúra medzi informačnými systémamimesta a externými systémami (napr. moduly ÚPVS). Modul zabezpečuje logické riešenie pre

integráciu systémov (ich vzájomné prepojenie) a procesné spracovanie správ (smerovanie, zasielanie

a prijímanie).

Back office

Predstavuje agendové systémy mesta, ktorý tvoria najmä Informačný systém mesta Prievidza, Registratúrny systém mesta Prievidza a Geografický systém mesta Prievidza.

Aplikačná architektúra – budúci stav

Obr. č.4 Aplikačná architektúra – budúci stav

Front end mesta

základné prístupové komponenty – egov.mesta a webová stránka mesta, cez ktorý občania / podnikatelia pristupujú k elektronickým / koncovým službám, bude rozšírený o nový komponent GIS mesta s ponukou priestorových informácií a analytických nástrojov a zároveň bude vytvorený lokálny OpenData katalóg, ktorý bude poskytovať datasety pre Národný OpenData katalóg.

Integračná vrstva

Modul napojenia na externé IS bude v rámci projektu rozšírený o Dátový konektor. Integračná vrstva bude rovnako rozšírená o Orchestračnú platformu, ktorá bude doplnená o dátovú integráciu na CSRU a Centrálny dátový. V tejto časti dôjde aj k vytvoreniu prepojení databáz jednotlivých IS, tak aby mohli odovzdávať a následne konzumovať dáta. Nad takto zhromaždenými dátami bude možné prostredníctvo BI nástroja vytvárať rôzne analytické a štatistické výstupy a zároveň definovať metadáta datasetov pre OpenData, ktoré budú publikované v Lokálnom katalógu a prelinkované na data.slovensko.sk.

Back Office

tvoria ho agendové systémy mesta, ako. Informačný systém Mesta Prievidza, Registratúrny systém Mesta Prievidza. Naopak mesto už naďalej neplánuje prevádzkovať v tejto vrstve Geografický systém mesta Prievidza a jeho funkciu nahradí nový komponent na front-ende mesta..

Orchestračná platforma mesta

Tento novovybudovaný IS (Integračná zbernica služieb - Enterprise Service Bus, ESB) bude samostatným modulom Informačného systému mesta. Bude hlavnou komunikačnou platformou jednotlivých modulov riešenia a integrovaných interných a externých systémov. ESB bude spĺňať minimálne nasledovné požiadavky:

1. Podpora rôznych komunikačných protokolov

• Platforma musí podporovať široké spektrum protokolov ako napr. SOAP, REST, JMS, FTP, HTTP(S), AMQP, atď., aby umožnila komunikáciu medzi rôznorodými systémami a aplikáciami.

2. Flexibilná a škálovateľná architektúra

• Platforma musí byť škálovateľná, aby zvládala narastajúce požiadavky na výkonnosť a množstvo integrácií bez akýchkoľvek výkonnostných obmedzení. Musí tiež umožniť horizontálne aj vertikálne škálovanie podľa potrieb mesta.

3. Podpora orchestrácie a choreografie služieb

• Platforma musí podporovať rôzne spôsoby integrácie služieb vrátane orchestrácie (centrálna kontrola nad komunikáciou medzi službami) a choreografie (decentralizovaná komunikácia medzi nezávislými službami).

4. Centralizovaná správa a monitorovanie

• Platforma musí umožňovať centralizovanú správu všetkých integrácií, vrátane monitorovania výkonu, záznamu udalostí, chybovej diagnostiky a podrobnejšieho logovania.

5. Bezpečnosť a kontrola prístupu

• Platforma musí poskytovať robustné bezpečnostné mechanizmy, vrátane šifrovania, autentifikácie, autorizácie a podpory bezpečnostných štandardov ako OAuth, JWT, SAML, SSL/TLS na ochranu citlivých údajov.

6. Podpora transformačných nástrojov

• Platforma musí poskytovať nástroje na transformáciu dátových formátov medzi rôznymi systémami (napr. z XML na JSON, CSV, atď.), aby zabezpečila interoperabilitu medzi rôznymi modulmi a informačnými systémami.

7. Asynchrónna komunikácia a spracovanie správ

• ESB musí podporovať asynchrónne spracovanie a odosielanie správ t.j. okamžitá odpoveď nie je nevyhnutná, alebo kde môže dôjsť k zdržaniu v spracovaní.

8. Podpora pre rozširovateľnosť a prispôsobiteľnosť

• Platforma by mala byť dostatočne modulárna, aby umožnila prispôsobenie a rozšírenie podľa konkrétnych potrieb mesta, vrátane možnosti integrácie vlastných konektorov alebo rozhraní.

9. Zabezpečenie vysokej dostupnosti a zotavenia po poruche (high availability & failover)

• Platforma musí zabezpečiť nepretržitú dostupnosť služieb aj v prípade porúch jednotlivých komponentov, s podporou funkcionalít ako automatický failover, clustering a záložné systémy.

10. Kompatibilita s rôznymi technológiami a systémami

• ESB musí byť schopná integrácie s rôznymi platformami a technológiami vrátane cloudových služieb, lokálnych systémov, databáz, ERP systémov a pod. Okrem toho by musí umožňovať jednoduché nasadenie do hybridných prostredí (cloud a on-premise).

V rámci realizácie predmetu zákazky/projektu zabezpečí integračná platforma minimálne:

• Komunikáciu všetkých modulov realizovaných v rámci predmetu zákazky
• Publikovanie otvorených údajov a analytických služieb smerom do verejného prostredia
• Vybudovanie integračného rozhrania pre externé systémy, ktoré poskytujú referenčné údaje štátu, primárne CSRÚ, IS CISMA, ESKN a iné, ktoré budú identifikované v rámci realizačnej fázy analýza a dizajn, nevyhnutné pre realizáciu projektu
• Vybudovanie integračného rozhrania pre interné systémy obsahujúce referenčné objekty mesta

Centrálny dátový sklad

Centrálny dátový sklad bude samostatný modul Informačného systému mesta Prievidza, ktorý bude zabezpečovať správu a distribúciu údajov o referenčných objektoch evidencie mesta Prievidza. Za referenčný objekt evidencie bude považovaný každý objekt evidencie, ktorý je informačnými systémami mesta Prievidza využívaný na realizovanie viac ako jednej agendy.

Centrálny dátový sklad bude obsahovať kompletný dátový model o uložení údajov a väzieb všetkých objektov evidencie.

Všetky existujúce informačné systémy mesta budú prispievať dátami do tohto dátového skladu. Platí to aj pre zhromažďovanie dát z rôznych implementovaných IoT snímačov. Nad takýmito agregovanými a referencovateľnými dátami budú prebiehať ďalšie operácie IS mesta s nimi. Platí teda, že napríklad aj do elektronického formulára konkrétnej koncovej služby bude použitý referenčný údaj z dátového skladu, ktorý zohľadňuje stav v centrálnych referenčných registroch, pričom pre ich získanie sú využívané už existujúce a novovybudované integračné komponenty. 

Z pohľadu tvorby nového IS Centrálneho dátového skladu(zbernice) mesta sú definované základné požiadavky na jeho funkcionalitu, ktorými sú:

• Dáta od zdrojov dát bude zbernica preberať a vo finále ukladať v rámci svojho vlastného komplexného dátového modelu. Toto umožní, aby nebolo potrebné škálovať všetky zdroje na maximálnu možnú záťaž spojenú s dopytovaním dát, ale len zbernicu. Dáta pritom bude zbernica od zdrojov preberať vtedy, keď to bude výhodné pre obe strany (nočné hodiny a pod.)
• Dátový model zbernice bude koncipovaný tak, aby dokázal naraz pracovať z rôznymi verziami predpisu uložených dát.  Dáta teda nebude potrebné komplikovane migrovať z jednej verzie ich predpisu na druhú a pod.
• Model môže optimalizovať centrálne uložené dáta na rôzne typy operácií a spôsobov ich použitia – vyhľadávanie, analyticko-štatistické operácie. Dosiahnuť rovnaký efekt izolovane vo všetkých zdrojov dát by bolo omnoho náročnejšie.
• Zbernica môže poskytovať pre zapojené strany – zdroje a konzumentov dát; aj tzv. „publish-subscribe“ návrhový vzor, pri ktorom môžu byť automaticky všetci konzumenti po publikovaní novej informácie zdrojom informovaní o existencii takejto zmeny. Toto môže prispieť k zefektívneniu  celkovej architektúre procesov výmeny dát cieľového prostredia.
• Zbernica bude implementovať aj stranu tzv. „dlhodobého archívu“, kam sa  budú dáta na základe retenčných pravidiel presúvať pomocou dedikovaných funkcii. V úložisku pritom ostane referencia o tom, že tieto dáta boli presunuté do archívu. Funkcie presúvania dát do archívu budú fungovať aj opačným smerom – na základe požiadavky sa dočasne konkrétne archivované dáta budú môcť presunúť na vymedzenú časový interval späť.
• Centrálny dátový skład bude obsahovať funkcionalitu „Data Handler“, ktorá bude zabezpečovať overovanie a autorizáciu dát. V prípade, že budú o tom istom objekte evidencie v rôznych informačných systémoch evidované rôzne hodnoty toho istého atribútu (napríklad adresa bydliska), data hanlder na základe stanovených pravidiel vyhodnotí, ktorú hodnotu bude považovať za pravdivú a referenčnú do doby, kým nebude preukázaný opak. O možnom konflikte údajov musí notifikovať zodpovedný informačný systém. Údaje považované za pravdivé budú mať v centrálnom dátovom sklade príznak „referenčné“ pra daný objekt evidencie.

Obr. č.5 Princíp činnosti data handlera

Data handler bude zodpovedný za to, že pri pravidelných aktualizáciách centrálneho dátového skladu bude zabezpečená konzistencia dát a nedôjde k znehodnoteniu referenčných údajov nepravdivými alebo neoverenými údajmi. Pravidlá priority údajov budú definované v realizačnej fáze Analýza a dizajn.

Ďalšou z funkcionalít novovybudovaného centrálneho dátového skladu  je poskytnutie analytického nástroja pre vytváranie ľubovoľných analytických výstupov nad dátami v uloženými v jeho štruktúrach. Očakáva sa plnohodnotný BI nástroj, ktorý umožní  vytváranie špecifických dátových modelov, tvorbu výpočtov v dátových modeloch, tvorbu reportov, tvorbu dashboardov, definovanie hraničných hodnôt pre automatizovanú notifikáciu ako aj zdieľanie takto vytvorených výstupov s ostatnými používateľmi .

Dátový konektor pre spojenie s Informačným systémom samosprávy

Dátový konektor pre spojenie s Informačným systémom samosprávy predstavuje modul informačného systému, rozšírenie existujúce IS samosprávy, ktorého úlohou bude migrácia údajov o všetkých objektoch a relevantných atribútoch informačného systému samosprávy do centralizovaného dátového skladu.

Súčasťou realizácie predmetu projektu bude dodanie nasledovných funkčností/elementov:

• Dokumentácia dátového modelu ISS pre objekty evidencie, ktoré sú predmetom migrácie do centrálneho dátového skladu
• Iniciačná migrácia údajov o objektoch evidencie
• Zabezpečovanie pravidelnej aktualizácie údajov o objektoch evidencie vedených v centrálnom dátovom sklade na báze 24 hodín (mimo pracovného času) z databázy ISS
• Zabezpečovanie „on demand“ aktualizácie údajov o objektoch evidencie v centrálnom dátovom sklade potrebných pre realizáciu príslušnej služby na základe volania používateľa

Predmetom migrácie do centrálneho dátového skladu budú údaje o minimálne objektoch evidencie mesta Prievidza, ktoré sú predmetom tohto projektu v niektorej z jeho častí. Rozsah jednotlivých atribútov OE bude definovaný v fáze Analýza a Dizajn.

Zoznam OE z existujúceho IS mesta, ktoré budú migrované do centrálneho dátového skladu

GIS

Dodané riešenie bude poskytnuté ako webová aplikácia dostupná prostredníctvom webových prehliadačov s responzívnym zobrazením pre počítačové aj mobilné prehliadače (na prácu s aplikáciou je potrebný iba ľubovoľný internetový prehliadač a pripojenie na internet bez nutnosti inštalácie dodatočného software), súčasťou riešenia bude aj   poskytovanie služieb  mapového servera, prvotný iniciačný import dát poskytnutých mestom a priestorový zber dát/pasport s následným importom všetkých dát do Centrálneho dátového skladu.

Nevyhnutnou podmienkou je trvalé zdieľanie všetkých dát v Centrálnom dátovom sklade.

Riešenie musí byť koncipované modulárne, modul zastrešuje istú agendu/ príp. jej časť, a musí umožňovať do budúcna  prípadný rozvoj tak konkrétneho modulu ako aj prípadné rozšírenie celého riešenia o ďalší modul.

Pri implementácii projektu budú dodané nasledovné moduly:

• Evidencia a správa verejnej zelene
• Evidencia a správa miestnych ciest a dopravy
• Evidencia a správa odpadov
• Evidencia a správa mobiliáru
• Evidencia a správa verejného osvetlenia
• Územný plán

Základnými očakávaniami pre riešenie GIS nástroja sú :

• 
  
  • pripojenie musí byť zabezpečené SSL certifikátom,
  • aplikácia musí byť prevádzkovaná v CLOUDe alebo na serveroch dodávateľa,
  • používateľské rozhranie aplikácie musí byť v slovenskom jazyku,
  • riešenie musí byť modulárne s možnosťou jeho rozšírenia o ďalšie moduly alebo funkcionality,
  • riešenie musí byť integrované na centrálny dátový sklad mesta Prievidza, ktorý je výsledkom tohto projektu,
  • riešenie musí umožniť poskytovanie dát vo formáte JSON alebo XML pre potreby vlastnej vizualizácie dát a zdieľania ako otvorené dáta,
  • riešenie musí poskytovať možnosť embedovať/vkladať mapy vo forme IFRAME do ďalšíchstránok (napríklad stránok mesta),
  • poskytovanie mapových služieb podľa štandardov Open Geospatial Consortium (OGC),
  • dynamické zobrazovanie rastrových dát prostredníctvom pohľadových dlaždíc,
  • riešenie musí podporovať funkcionalitu zberu dát,
  • používateľské rozhranie aplikácie musí byť v slovenskom jazyku,
  • vytvorenie a správa používateľov (vkladanie, zmena údajov a zrušenie prístupov) administrátorom na strane mesta,
  • riešenie musí zabezpečiť možnosť viacerých prístupov s pridelenými oprávneniami (role) pre používateľov,
  • možnosť tvorby používateľských skupín (množiny používateľov s rovnakými oprávneniami),
  • možnosť nastavenia užívateľské oprávnenia pre prístup k modulom alebo ich časti,
  • riešenie musí sprístupňovať samostatne tematicky orientované celky/moduly, určené na prácu s konkrétnou agendou (napr. pasport), v ktorých je možné editovať jednotlivé predmetné prvky/objekty a to ako ich grafické údaje tak aj popisné informácie,
  • jednotlivé moduly musia umožňovať vzájomnú prepojiteľnosť a vzájomné využívanie dát,
  • riešenie obsahuje nástroje pre vytváranie vlastných mapových kompozícií a tém s možnosťou editácie

Zároveň musí toto riešenie disponovať minimálne nižšie definovanou funkcionalitou :

• fungovanie systému v súradnicovom systéme S-JTSK,
  • zobrazovanie rôznych podkladových, rastrových aj vektorových máp (min. základná mapa, ortofotomapy, mapy územnej identifikácie, povodňové mapy, orientačné mapy, mapy správy ciest, historické mapy) ako zapínateľné/vypínateľné vrstvy,
  • zobrazovanie rôznych vrstiev a objektov aktuálneho a archívneho katastra nehnuteľností ako zapínateľné/vypínateľné vrstvy,
  • zobrazovanie tematických máp ako zapínateľné/vypínateľné vrstvy
  • možnosť zapínanie alebo vypínanie mapových vrstiev, skrývanie skupín vrstiev,
  • možnosť zmeny transparentnosti vybraných máp, vrstiev a objektov,
  • zobrazovanie legendy k mapovým vrstvám,
  • zmeny mierky zobrazenia, pohyb v mape, posun na určené lokality,
  • meranie dĺžok a plôch v mape,
• textové poznámky k mape (zvýrazňovanie a vkladanie dočasných bodov, línií a polygónov do   mapy) bez obmedzenia počtu znakov,
  • identifikácia súradníc bodov v S-JTSK aj WGS 84,
  • identifikácia vybraných objektov v mape,
  • vyhľadávanie vybraných objektov v mape,
  • vyhľadávanie vybraných objektov v mape, vyhľadávanie formou predgenerovaného fultextu,
  • vyhľadávanie bez potreby diakritiky vo vybraných mapových vrstvách,
  • zobrazovanie atribútov objektov v rámci identifikácie alebo vyhľadávania objektov v mape,
  • práca s mapovými službami podľa štandardov Open Geospatial Consortium (OGC),
  • možnosť prepínania medzi jednotlivými mapovými kompozíciami a aplikáciami pri zachovaní  zoomu a mierky v mape,
  • nápoveda pre prácu s poskytnutým riešením v slovenskom jazyku

• editačné funkcie musia byť dostupné na základe pridelených prístupových práv,
• editácie vektorových prvkov,
• integrácia máp, vrstiev a prvkov pri editácií,
• funkcia zobrazenia polohy v mape podľa polohy zariadenia (ak zariadenie podporuje zdieľanie polohy),
• editácia polohy jednotlivých prvkov v mape prebieha priamo v mapovej časti aplikácie, k dispozícii sú editačné nástroje pre body, línie, plochy aj polygóny,
• možnosť kopírovať prvky z WFS služieb do vlastnej lokálnej mapovej vrstvy,
• podpora vytvárania topologicky čistých dát, najmä prichytávanie, rozdeľovanie prvkov, preberanie geometrie z referenčných podkladov (napr. z parciel, z technickej mapy), zabezpečenie vytvárania dát s valídnou geometriou (najmä zamedzenie uloženia prvkov bez geometrie, prvkov s nulovou geometriou a pod.),
• informačná vrstva pri spracovaní editácie zobrazujúca dĺžky kreslených prvkov a nápovede pre konštrukciu základných uhlov,
• možnosť umiestnenia poznámok (body, línie, plochy) s popisom a fotografiou,
• možnosť pridania nového atribútu pre celú skupinu prvkov,
• kompletná dokumentácia objektu: každý záznam o objekte možno doplniť o fotografie alebo inú dokumentáciu v elektronickej podobe,
• editácia geometrie, podpora vytvárania topologicky čistých dát, tzn. prichytávanie, rozdelenie prvkov, prebranie geometrie z referenčných podkladov (napr. parciel, technickej mapy), zabezpečenie vytvárania dát s valídnou geometriou (najmä zamedzenie uloženia prvkov bez geometrie, prvkov s nulovou geometriou...),
• nástroje pre vytváranie tlačových zostáv a rozšíriteľnosť sady tlačových zostáv,
• nástroje pre vytváranie, editáciu a ukladanie tlačových šablón,
• tvorba tlačových zostáv s možnosťou exportu do tlačového výstupu PDF, JPEG, PNG, obsahujúceho napr. legendu, mierku, vodoznak, informácie o ochranných známkach a autorských právach, atď.,
• export mapy do formátu PDF s možnosťou vloženia nadpisu a voľby preddefinovanej mapovej mierky a veľkosti papiera,
• export pasportu a evidencie viacerých i jednotlivých objektov do formátu PDF a DOC s možnosťou voľby preddefinovanej šablóny,
• tlač vo formátoch ISO A3/A4,
• orientácia tlače na výšku/šírku - tlač s legendou/s legendou na ďalšej strane/bez legendy/len legenda atď.,
• pripájanie referenčných výkresov do mapových aplikácií vo formáte DGN verzie 7 a vyššej, tieto podkladové výkresy sú využiteľné pri editácii grafiky pre prichytávanie (snapovanie),
• priamy import a export dát minimálne z formátov DGN, DXF, GPX, SHP, CSV spôsobom, ktorý zabezpečí užívateľsky jednoduché riešenie bez predchádzajúcej úpravy dát treťou stranou,
• priamy export mapy do rastrového formátu podľa aktuálneho zobrazenia na obrazovke
• možnosť zostavenia a uloženia užívateľských SQL dotazov,
• možnosť zobrazenia vybraných prvkov pasportu podľa špecifických atribútov,
• možnosť pridania ďalších tematických vrstiev do zoznamu vrstiev v mape,
• možnosť prepínania medzi jednotlivými mapovými kompozíciami pri zachovaní zoomu a mierky v mape

Základné požiadavky na jednotlivé moduly GIS

Evidencia a správa verejnej zelene

• modul na správu aktuálneho pasportu zelene mesta - evidencia a správa verejnej zelene (plochy zelene, biologické prvky zelene, technické prvky zelene), vrátane súvisiacich činností (údržba, výruby a iné zásahy),

• databázová evidencia pre správu súvisiacich informácií, možnosť uloženia príslušných povolení a fotodokumentácie,

• dodávka číselníkov drevín a zelene v zmysle arboristických štandardov platných na území SR,

• evidencia chránených stromov - číslo pamätného stromu, dôvod ochrany, dátum vyhlásenia/zrušenia, grafické znázornenie ochrannej zóny v mape (automatické generovanie na základe priemeru kmeňa),

• evidencia zdravotného stavu stromov - automatické hlásenie o plánovanej kontrole dendrologických údajov,

• evidencia mestskej zelene a súvisiacich objektov (výmery plôch/počty prvkov, kvalitatívne atribúty),

• evidencia a zobrazenie prvkov v rôznych stavoch (súčasný, návrh, zrušený) s možnosťou obnovenia zrušených prvkov (historizácie, vrátane geometrie),

• evidencia vykonaných a plánovaných zásahov (kosenie, údržba stromov),

• mapa kosenia - prezentácia informácií o dátume najbližšieho plánovaného kosenia a posledného vykonaného kosenia trávnatých plôch v meste a stave vykonaných prác,

• výpočet nákladov na údržbu - možnosť využitia a porovnanie rôznych cenníkov, možnosť využitia rôznych sád úkonov,

• možnosť generovania výstupných zostáv - sumarizácia prvkov podľa druhu za vybranú základnú (evidenčné) plochu/za vybrané územia, sumarizácia nákladov na údržbu za vybranú základnú (evidenčné) plochu/za vybrané územia,

• výpis parciel dotknutých vybranými prvkami zelene,

• možnosť nastavenia východzej hodnoty v číselníkoch (pri vytváraní nového prvku sa východzia hodnota atribútu vkladá automaticky),

• možnosť pripojenia dokumentov a fotodokumentácie ku všetkým prvkom,

• evidencia zakladateľov (resp. editorov) dát spolu s dátumami a časmi založenia (resp. editácie) u jednotlivých prvkov a možnosť podľa týchto hodnôt vyhľadávať,

• editácia geometrie: podpora vytvárania topologicky čistých dát, tzn. prichytávanie, rozdelenie prvkov, prebranie geometrie z referenčných podkladov (napr. parciel, technickej mapy), zabezpečenie vytvárania dát s validnou geometriou (najmä zamedzenie uloženia prvkov bez geometrie, prvkov s nulovou geometriou...),

Evidencia a správa miestnych ciest a dopravy

• modul na správu aktuálneho pasportu dopravy mesta - evidencia a správa miestnych ciest, chodníkov, parkovísk a parkovací miest, mostov, dopravného značenia, kanalizačných vpustí a kanalizačných poklopov, objektov MHD a inžinierskych objektov,

• evidencia ciest, chodníkov, zvislého a vodorovného dopravného značenia, povrchov, mostov, vpustí, zjazdov, technických a iných objektov, opráv a zásahov na cestách,

• evidencia dĺžok a plôch ciest a mostov a ich súčty (všetkých ciest, podľa tried ciest),

• evidencia a zobrazenie prvkov v rôznych stavoch (súčasný, návrh, zrušený) s možnosťou obnovenia zrušených prvkov,

• zobrazenie prvkov pasportu podľa špecifických atribútov alebo podľa farieb v číselníku,

• zobrazenie ciest v mape podľa kategórie ciest (štátna, krajská, miestna, účelová), podľa triedy ciest, podľa typu úseku (vozovky, chodníky, cyklotrasy), podľa funkčnej skupiny (rýchlostná, zberná, obslužná, upokojená, cyklistická, pre chodcov), podľa povrchu,

• evidencia zásahov na cestách - zobrazenie v mape podľa dátumu záruky, upozornenie

  na končiacu záruku v systéme GIS a e-mailom

• výpis parciel dotknutých ciest,

• obsahuje číselníky s možnosťou prednastavenia predvolenej hodnoty v jednotlivých atribútoch,

• možnosť pripojenia dokumentov (napr. povolenia) a fotodokumentácie ku všetkým prvkom pasportu,

• evidencia opráv ku všetkým prvkom v pasporte,

• editácia v mape,

• podpora vytvárania topologicky čistých dát, tzn. prichytávanie, rozdelenie prvkov,

• zabezpečenie vytvárania dát s valídnou geometriou (najmä zamedzenie uloženia prvkov bez geometrie, prvkov s nulovou geometriou...),

• rotácia zvislých a vodorovných značení,

• história zmien a možnosť obnovenia hodnôt v atribútoch vrátane geometrie,

• evidencia zakladateľov (resp. editorov) dát spolu s dátumami a časmi založenia (resp. editácie) u jednotlivých prvkov a možnosť podľa týchto hodnôt filtrovať a vyhľadávať,

• záujmové oblasti,

• možnosť zavádzať informácie o možnosti parkovania, parkovacej zóne,

• možnosť zavádzať informácie o únosnosti vozovky,

• možnosť zavádzať informácie o pláne letnej údržby, minimálne v rozsahu poradia a zodpovedného subjektu a ceny,

• možnosť zavádzať informácie o pláne zimnej údržby, minimálne v rozsahu poradia, zodpovedného subjektu a ceny,

• možnosť generovať sumarizačné štatistiky napr.: za celkovú/vybratú dĺžku, priem. šírku a plochu atď,

• pri priechodoch pre chodcov možnosť zavádzať informácie o osvetlení a bezbariérovom prístupe,

• otvorenosť riešenia pre možnosť integrácie pre načítanie, vizualizáciu, analýzy a reporty z dát zo smart zariadení,

• pri vpustiach musí byť možné zavádzať informácie o čistení v minimálnom rozsahu: početnosti, dátume a musí byť možné vytvárať zjednodušené plány čistenia

Evidencia a správa odpadov

• atribúty stojiska: názov lokality, evidenčné číslo, zvozová oblasť, povrch, technický stav, typy kontajnerov, vlastník stavby, poznámka, prístupné pre verejnosť,

• naviazanie na parcelu (parcelné číslo),

• musí obsahovať údaje o adrese v rozsahu ulica, popisné číslo

• musí umožniť naviazanie entity typ odpadu, napr. separovaný odpad, TKO, nebezpečný odpad, objemový odpad atď.,

• požaduje sa pri jednotlivých entitách (typ odpadu) evidovať typ nádoby, objem, komodita, údaje o správe zariadenia,

• požaduje sa evidencia údajov o zvoze odpadu vrátane plánu zvozu (minimálne na úrovni dňa v týždni a početnosti) a ceny za odvoz,

• štatistické vyhodnotenie odpadového hospodárstva na základe zozbieraných dát,

• otvorenosť riešenia pre možnosť integrácie pre načítanie, vizualizáciu, analýzy a reporty z dát z RFID/USG a iných čipov/ smart zariadení,

• na všetky objektové triedy sa požaduje nástroj na evidenciu Opráv, minimálne v rozsahu popis, číslo faktúry, dátum, dátum záruky, subjekt, druh opravy, cena.

Evidencia a správa mobiliáru

• komplexný nástroj pre správu a údržbu drobného majetku

• evidencia a zobrazenie prvkov v rôznych stavoch (súčasný, návrh, zrušený) s možnosťou obnovenia zrušených prvkov,

• zobrazenie prvkov pasportu podľa špecifických atribútov alebo podľa farieb v číselníku,

• popis funkcií SW agendy:

• obsahuje číselníky s možnosťou prednastavenia predvolenej hodnoty v jednotlivých atri bútoch,

• možnosť pripojenia dokumentov (napr. povolenia) a fotodokumentácie ku všetkým prvkom  pasportu,

• evidencia opráv ku všetkým prvkom v pasporte,

• editácia v mape,

• podpora vytvárania topologicky čistých dát, tzn. prichytávanie, rozdelenie prvkov,

• zabezpečenie vytvárania dát s valídnou geometriou (najmä zamedzenie uloženia prvkov bez geometrie, prvkov s nulovou geometriou...),

• rotácia zvislých a vodorovných značení,

• história zmien a možnosť obnovenia hodnôt v atribútoch vrátane geometrie,

• evidencia zakladateľov (resp. editorov) dát spolu s dátumami a časmi založenia (resp. editácie) u jednotlivých prvkov a možnosť podľa týchto hodnôt vyhľadávať,

• záujmové oblasti,

Evidencia a správa verejného osvetlenia

• agenda bude slúžiť na evidenciu priestorovej databázy verejného osvetlenia a pridružených zariadení (rozvádzače, stožiare, káble, ... ),

• možnosť k jednotlivým prvkom viesť základné informácie (technické parametre, Informácie o ich vybavení, záruke, dodávateľovi...),

• informácie o revízii (napr. typ revízie, termín atď.) a oprave (popis, dátum, záruka, číslo faktúry atď.),

• možnosť užívateľsky doplňovať číselníky,

• možnosť pripojenia dokumentov a fotodokumentácia ku všetkým objektom evidencie,

• modul na upozornenia a notifikácie (napr. email) a záručné lehoty, atď.,

• historizácia zmien a možnosť obnovenia vybraného historického stavu prvku vrátane geometrie,

• evidencia zakladateľov, možnosť doplňovania opráv k jednotlivým prvkom evidencie zakladateľov (resp. editorov) dát spolu s dátumami a časmi založenia (resp. editácie) u jednotlivých prvkov a možnosť podľa týchto hodnôt filtrovať a vyhľadávať,

• editácia geometrie - podpora vytvárania topologicky čistých dát, tzn. prichytávanie, rozdelenie prvkov, zabezpečenie vytvárania dát s validnou geometriou (najmä zamedzenie uloženia prvkov bez geometrie, prvkov s nulovou geometriou, ... )

• otvorenosť riešenia pre možnosť integrácie pre načítanie, vizualizáciu, analýzy a reporty z dát zo smart zariadení,

Územný plán

• vizualizáciu dát územného plánu a generelov,

• vizualizácia hlavného záväzného výkresu územného plánu vo forme podkladovej mapy, so zachovaním symbológie v zmysle schválenej dokumentácie, ku výkresu bude dostupná plnohodnotná grafická legenda,

• požaduje sa, aby súčasťou boli minimálne podkladové vrstvy (alebo rastre): výkres komplexný návrh priest. usporiadania a funkčného využitia územia, výkres verejného dopravného vybavenia, výkres verejného technického vybavenia I., výkres verejného technického vybavenia II., výkres perspektívneho použitia PPF a LPF na nepoľnohospodárske účely, výkres ochrany prírody a tvorby krajiny vrátane prvkov múses,

• mapová aplikácia bude umožňovať identifikáciu "Funkčné/Regulačné plochy" s atribútmi funkcia, etapa a regulatív,

• pri identifikácii funkčných plôch uvádzať aj odkaz na celé znenie regulatívu,

• pri identifikácii regulačných plôch uvádzať aj odkaz na celé znenie regulatívu,

• možnosť pridania ďalších územnoplánovacích podkladov vo forme plánov (rastrov),

• možnosť pridania jednotlivých urbanistických štúdií vo forme plánu (rastru),

Digitálnotechnická mapa

• správa a vizualizáciu dát jednotlivých vrstiev inžinierskych sieti v rozsahu Plyn, Teplo, Elektrická energia, Telekomunikačné siete, Voda a kanalizácia

• agenda bude slúžiť na evidenciu priestorovej databázy jednotlivých inžinierskych sietí (vedenia, koncové zariadenia a pod...)

• možnosť k jednotlivým prvkom viesť základné informácie (technické parametre, Informácie o ich vybavení, záruke, dodávateľovi...),

• informácie o revízii (napr. typ revízie, termín atď.) a oprave (popis, dátum, záruka, číslo faktúry atď.),

• možnosť užívateľsky doplňovať číselníky,

• možnosť pripojenia dokumentov a fotodokumentácia ku všetkým objektom evidencie,

PRVOTNÝ MOBILNÝ ZBER/PASPORT ÚDAJOV

Do novozadefinovaných dátových štruktúr GIS modulov sa očakáva vykonanie pasportu údajov a to v nasledujúcich oblastiach a rozsahu:

Technické požiadavky na tvorbu pasportov

Pasporty musia byť spracované podľa princípov budovania a fungovanie geografických informačných systémov (GIS). Pasporty budú obsahovať grafickú (mapovú) časť a popisnú (databázovú) časť. Každý objekt – prvok pasportu musí byť zobrazený v mape, musí byť jednoznačne identifikovaný a musí mať väzbu na množinu vlastností (atribútov), ktorá je stanovená pre príslušnú triedu prvkov, ktorej je členom. Každý prvok musí byť možné vyhľadať a zobraziť na mape a zobraziť jeho množinu atribútov.

Požiadavky na spôsob zberu dát

Požaduje sa, aby pri tvorbe pasportov bola použitá kombinácia 3 metód zberu údajov. Kombinácia metód je vyžadovaná z dôvodu zabezpečenia polohovej presnosti a komplexnosti pasportizovaných objektov. Požaduje sa aby pri zbere údajov leteckými metódami bol zber vykonaný mimo vegetačného obdobia rastlín, pre dosiahnutie čo najvyššej presnosti.

Minimálny obsah mapových podkladov dodaných v projekte

• štátne ortofotomapy,
• parcely katastra nehnuteľností – C a E,
• druhy pozemkov,
• hranica intravilánu
• parcely C a E vo vlastníctve mesta,
• parcely C a E vo vlastníctve VÚC,
• parcely C a E vo vlastníctve SR,
• ulice a cestné komunikácie,
• adresné body v meste,
• miestopis,
• katastrálne územia, časti mesta.

Pre implementáciu a prevádzku GIS riešenia bude v projekte vytvorená pozícia Referenta pre spracovanie údajov GIS

IoT snímače

Plne autonomné riešenie implementácie snímačov na najfrekventovanejších uzloch dopravného systému mesta. Mesto zadefinovalo 4 lokality/križovatky, kde chce zbierať dáta o hustote dopravy.

1. Svetelná križovatka Matice slovenskej – Nábrežie s. Cyrila – Nábrežie sv. Metoda (vjazd on Novák a Handlovej)
2. Sverelná križovatka Bojnická cesta – ul. sama Chalúpku (vjazd od Bojníc)
3. Kruhový objazd na Nedožerskej ceste (vjazd od Nedožier – Brezian)
4. Svetelná križovatka Košovská cesta – Nábrežie sv. Metoda (vjazd od priemyselnej zóny)

Snímače budú umiestnené na stĺpoch vo vlastníctve mesta, a budú zaznamenávať okrem počtu vozidiel, ktoré v konkrétnom čase prechádzajú daným miestom aj ich typ. Tieto dáta budú odosielať do novovybudovaného Centrálneho dátového skladu mesta, čo na strane mesta sprocesuje Orchestračná platforma Mesta Prievidza. Minimálna požadovaná frekvencia odosielania dát je 1 krát denne.

• Rovnaké požiadavky sú kladené aj na snímače hluku, teploty a prašnosti ovzdušia, pričom tieto plánuje mesto umiestniť v rovnakých lokalitách ako pri senzoroch hustoty dopravy

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

Uveďte dotknuté ISVS a ich moduly AS IS:

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

Uveďte informácie o dotknutých ISVS z pohľadu ich ďalšej prevádzky po realizácii projektu – TO BE stav:

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

Uveďte informácie o využívaných, resp. nevyužívaných nadrezortných ISVS (Spoločných ISVS a spoločných blokov SaaS) – AS IS stav. Všetky realizované integrácie na nadrezortné ISVS v AS IS stave musia byť evidované v MetaIS.

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

Uveďte plánované využívanie nadrezortných a spoločných ISVS v TO BE stave.

• Povinnosť využívať nadrezortné ISVS ustanovuje najmä zákon č. 305/2013 Z. z. o elektronickej podobe výkonu pôsobnosti orgánov verejnej moci a o zmene a doplnení niektorých zákonov (zákon o e-Governmente) a iné legislatívne predpisy. Prehľad a informácie o nadrezortných ISVS sú uvedené v prílohe P8 Zoznam nadrezortných blokov a podporných spoločných blokov Používateľskej príručky MetaIS.

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

Uveďte v nasledujúcej tabuľke prehľad ISVS, pri ktorých sa plánuje využívanie služieb iných ISVS, spoločných blokov (SaaS) alebo služieb inf. systémov tretích strán v TO BE stave.
Plánované využívanie a integrácie služieb iných ISVS musí byť evidované v MetaIS – zaevidovanie vzťahu na aplikačnú službu určenú na externú integráciu poskytujúcim ISVS .

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

Uveďte v nasledujúcej tabuľke budované aplikačné služby, realizáciu koncových služieb aplikačnou službou, koncová služba by mala byť realizovaná aspoň jednou aplikačnou službou (KS môžu realizovať aj viaceré aplikačné služby). Všetky aplikačné služby a ich vzťah na koncové služby musia byť evidované v MetaIS.

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

Uveďte v nasledujúcej tabuľke budované aplikačné služby a ich využitie na integráciu na spoločné moduly a iné ISVS alebo ich poskytovanie na externú integráciu a predpokladané vybudovanie cloudových služieb “softvér ako služba“ (SaaS):

• Plánované aplikačné služby musia byť evidované v MetaIS s fázou životného cyklu a musia mať v MetaIs evidované všetky povinné atribúty a vzťahy,
• Evidencia integrácií v MetaIS sa realizuje evidovaním vzťahov aplikačných služieb budovaného//rozvíjaného ISVS na príslušné aplikačné služby nadrezortných ISVS. Podrobné informácie sú uvedené v Používateľskej príručke MetaIS, kap. 2.1.3.3.1 a kap. 2.1.3.3.2. Detailný popis služieb IS CSRÚ a poskytovaných objektov evidencie je v aktuálnej verzii integračného manuálu IS CSRÚ.
• Ak IS povinnej osoby potrebuje konzumovať alebo poskytovať služby iným ISVS alebo IS tretích strán prostredníctvom modulu Centrálna API Manažment Platforma (CAMP) a jej modulu API Gateway, je potrebné aplikačné služby IS Povinnej osoby naviazať na príslušné integračné služby CAMP (API Gatewy).
• Budované aplikačné služby musia mať v MetaIs evidované SLA parametre pre východiskový a cieľový stav. Podrobné informácie sú uvedené v Používateľskej príručke MetaIS, kap. 2.1.3.

  AS (Kód MetaIS)	Názov AS	Realizuje ISVS (kód MetaIS)	Poskytujúca alebo Konzumujúca	Integrácia cez CAMP	Integrácia s IS tretích strán	SaaS	Integrácia na AS poskytovateľan (kód MetaIS)

• Na informáciu je v nasledujúcej tabuľke prehľad AS na externú integráciu Spoločných modulov podľa § 10 zákona 305/2013 Zz. Vo finálnom dokumente túto tabuľku prehľadu AS spoločných modulov vymažte:

• Na informáciu sú v nasledujúcich diagramoch vzory modelovania integrácie na nadrezortné a spoločné moduly podľa § 10 zákona 305/2013 Zz podľa usmernenia v Používateľskej príručke MetaIS. Vo vašom finálnom dokumente tieto vzory vymažte a nahraďte svojím diagramom ilustrujúcim plánované integrácie:
  
  Obrázok 5 Integrácie na spoločné moduly ÚPVS – ref. príklad
  
  Obrázok 6 Integrácie na IS CAMP- referenčný príklad
  
  Obrázok 7 Integrácie na IS CSRÚ – ref. príklad
  
   

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

Uveďte v nasledujúcej tabuľke prehľad poskytovaných údajov (objektov evidencie, ďalej OE) z ISVS do IS CSRÚ v TO BE stave.

4.2.9Konzumovanie údajov z IS CSRU – TO BE

Uveďte v nasledujúcej tabuľke prehľad konzumovaných údajov z IS CSRÚ v TO BE stave. Súčasné dostupné objekty evidencie a údaje v IS CSRÚ sú uvedené v integračnom manuáli IS CSRÚ.

4.3Dátová vrstva

Každá organizácia by mala mať zavedený systematický manažment údajov (vrátane nastavenie príslušných procesov a metodík pre správu celého životného cyklu údajov) a byť schopná evidovať a spravovať údaje v strojovo-spracovateľnej podobe. V kapitolách nižšie je potrebné popísať AS IS a následne TO BE stav organizácie z pohľadu údajov, ich štruktúry a následného výkonu príslušnej agendy vo vzťahu k projektu.

4.3.1Údaje v správe organizácie

Popíšte dátovú architektúru riešenia na úrovni objektov evidencie a vzťahov medzi nimi v AS IS stave. Pri popise je potrebné vychádzať z metodiky Ministerstva vnútra - Metodika identifikácie, vizualizácie a referencovania údajov pri dátovom modelovaní vo verejnej správe (zverejnená na stránke https://www.minv.sk/?np-optimalizacia-procesov-vo-verejnej-sprave v Aktivite 5).

• Uveďte diagramy tried a štruktúrovaný popis entít a atribútov vhodný aj pre strojové spracovanie. Diagram tried uveďte vo forme úplného logického modelu.
• Popíšte procesy riadenia životného cyklu správy údajov, kde je potrebné zrozumiteľne zdokumentovať dátové štruktúry, proces tvorby údajov, štatistické metodológie (ak budú použité), dátové zdroje, kontext a ďalšie aspekty manažmentu údajov. Proces riadenia pre manažment údajov musí byť zavedený nad informačnými systémami, ktoré obsahujú objekty evidencie a budú riešené v projekte.
• Popíšte zavedenie systematického manažmentu údajov v organizácií.
• Po organizačnej stránke je podmienkou zavedenie role dátového kurátora (dátový architekt) v organizácii, v rozsahu ako ju definuje strategická priorita Manažment údajov a strategická priorita Otvorené údaje, ktorý bude zodpovedný za koncept systematického manažmentu údajov a úpravu organizačnej štruktúry smerom k vytvoreniu rezortnej dátovej kancelárie.

4.3.2Dátový rozsah projektu - Prehľad objektov evidencie - TO BE

Pre budované informačné systémy vytvorte tzv. doménový model, ktorý definuje návrh dátových prvkov súvisiacich s projektom.

• Úlohou doménového modelu je vizuálne znázorniť rozsah predmetných údajov daného projektu, pričom je možné abstrahovať od nepodstatných detailov. Je platformovo nezávislý (nie je určený pre konkrétny programovací jazyk),
• V nasledujúcej tabuľke uveďte a popíšte Objekty Evidencie (ďalej len OE) v jednotlivých ISVS/registroch súvisiace s projektom.
• Doménový model by mal byť v súlade s existujúcim Centrálnym modelom údajov verejnej správy (viac informácií na: https://mirri.gov.sk/sekcie/informatizacia/egovernment/datova-kancelaria/interoperabilita/ a https://metais.vicepremier.gov.sk/publicspace?pageId=59836112.).
• Pre modelovanie doménového modelu je potrebné stiahnuť si Centrálny model údajov verejnej správy v preferovanej distribúcii a v novom modeli použiť existujúce dátové prvky, ak tieto patria do domény projektu. Z technického pohľadu je odporučený jazyk UML (pre zjednodušený doménový model môžete použiť aj jazyk ArchiMate).
• V prípade, že sa používa dátový prvok z Centrálneho dátového modelu je nutné použiť skrátenú formu URI identifikátora daného prvku, napr. pper:PhysicalPerson je skrátený tvar https://data.gov.sk/def/ontology/physical-person/PhysicalPerson

ID OE	Objekt evidencie - názov	Objekt evidencie - popis	Referencovateľný identifikátor URI dátového prvku
			(Ak nie je priradené URI uveďte „Nemá“)
			Obrázok 8 Doménový model - príklad Obrázok 9 Zjednodušený doménový model - príklad

4.3.3Referenčné údaje

V národnej koncepcii informatizácie verejnej správy bol zadefinovaný princíp „jedenkrát a dosť“, ku ktorému boli ďalej detailnejšie rozpracované úlohy v dokumente Strategická priorita Manažment údajov. Cieľom je dosiahnutie stavu, kedy orgány verejnej moci pri poskytovaní svojich služieb odstránia povinnosti občanov alebo podnikateľských subjektov predkladať údaje vo forme rôznych výpisov, odpisov, potvrdení, atď., ktorými už disponuje verejná správa v rámci svojich registrov.
Za účelom dosiahnutia TO BE stavu, z ktorého bude benefitovať občan / podnikateľský subjekt úsporou svojho času a prostriedkov, je potrebné popísať viacero nasledujúcich krokov na úrovni participujúcich subjektov verejnej správy:

• Popísať, aká je aktuálna kvalita údajov v zdrojových registroch,
• Uviesť dôvod vyhlásenia referenčných údajov (údaje musia byť k subjektu evidencie jedinečné a k týmto údajom je podľa osobitných predpisov uvedená domnienka správnosti),
• Uviesť poskytovateľov a konzumentov (vlastníkov) údajov do centrálnej platformy dátovej integrácie (modulu procesnej integrácie a integrácie údajov slúžiacim pre výmenu údajov pri výkone verejnej moci elektronicky),
• Popísať legislatívu a procesy vo verejnej správe (konkrétnej životnej situácie), pre konkrétne údaje identifikované v projekte (odstránenie legislatívnych povinností predkladať úradom výpisy a potvrdenia a automatizácia procesov viažucich sa k životným situáciám a interakcie s občanom / podnikateľským subjektom).

4.3.3.1Objekty evidencie z pohľadu procesu ich vyhlásenia za referenčné

V tejto časti dokumentu je potrebné definovať/popísať rozsah a štruktúru na úrovni registrov / objektov evidencie / údajov, ktoré sa navrhujú vyhlásiť za referenčné v naviazanosti na ich zrealizovateľné vzájomné zdieľanie medzi subjektami verejnej správy a dodržanie pravidla, že za referenčné údaje/atribúty sú vyhlasované také údaje/atribúty, ktoré sú k subjektu evidencie jedinečné a práve tie, ktoré využívajú subjekty verejnej správy pri realizácii princípu „1 x a dosť“.

• Popísať a zdôvodniť navrhované objekty evidencie k vyhláseniu za referenčné z pohľadu ich dátovej kvality v zmysle podkapitoly venujúce sa kvalite a čisteniu údajov,
• Popísať, ako bude zabezpečená dostupnosť poskytovania navrhovaných objektov evidencie za referenčné (t.j. v rámci nich údaje/atribúty) cez Modul procesnej integrácie a integrácie údajov, t.j. integráciou cez jeho dátovú časť - IS CSRÚ,
• Uviesť časový harmonogram procesu vyhlasovania a zmeny referenčných údajov. Informácie o procese vyhlasovania a zmeny referenčných údajov sú uvedené v metodickom usmernení MIRRI o postupe zaraďovania referenčných údajov do zoznamu referenčných údajov vo väzbe na referenčné registre a vykonávania postupov pri referencovaní: https://metais.vicepremier.gov.sk/confluence/download/attachments/2621442/Metodicke_usmernenie_UPVII_3639_2019_oDK_1_FINAL.pdf?version=1&modificationDate=1554714761337&api=v2
• V nasledujúcej tabuľke uveďte návrh na vyhlásenie a zmeny referenčných údajov, ktoré budú poskytnuté na dátovú integráciu realizáciou projektu. V tabuľke uveďte OE z tabuľky uvedenej v kapitole 4.3.2 Dátový rozsah projektu - Prehľad objektov evidencie - TO BE:

4.3.3.2Identifikácia údajov pre konzumovanie alebo poskytovanie údajov do/z CSRU

Identifikujte a uveďte v nasledujúcej tabuľke potenciálnych konzumentov objektov evidencie, ktoré budú poskytnuté na dátovú integráciu realizáciou projektu, vrátane ich oprávnenosti/nároku na konzumovanie v zmysle konkrétnych ustanovení osobitných právnych predpisov na strane konzumenta, prípadne aj na strane poskytovateľa. V nadväznosti na uvedené identifikujte osobitné právne predpisy (až na úroveň konkrétneho ustanovenia), ktoré je nutné novelizovať v záujme dosiahnutia TO BE stavu využitia údajov a jeho bezproblémovej aplikovateľnosti.
V tabuľke uveďte OE z tabuľky uvedenej v kapitole 4.3.2 Dátový rozsah projektu - Prehľad objektov evidencie - TO BE:
Poznámka: Pre úspešné napojenie ISVS na IS CSRÚ v roli konzumenta údajov je nutné postupovať podľa integračného manuálu IS CSRÚ.

4.3.4Kvalita a čistenie údajov

4.3.4.1Zhodnotenie objektov evidencie z pohľadu dátovej kvality

Zhodnoťte objekty evidencie so zameraním sa na významnosť kvality údajov pre biznis procesy (možné riziká v dôsledku dátovej nekvality), t.j. ak bude údaj nepresný, bude mať nesprávnu hodnotu, formát, nebude vyplnený, alebo stotožnený voči referenčnému registru, ako významne to ovplyvní príslušnú agendu:

• uveďte, či a ako bude zapracovaná možnosť overenia hodnoty údaja,
• uveďte, či bude zapracované pri zadávaní údajov obmedzenie hodnôt, napríklad formou číselníka, alebo podmienok,
• uveďte, či budú dáta migrované z iného ISVS.
  V nasledujúcej tabuľke vyhodnoťte významnosť a citlivosť kvality údajov a prioritu (poradie dôležitosti) pre meranie dátovej kvality objektov evidencií – t.j. poradie, v akom bude správca ISVS približne realizovať meranie dátovej kvality a čistiť údaje. Prvé 2 záznamy sú vyplnené ako príklad. Vymažte, resp. prepíšte ich vlastnými údajmi. Riadky v tabuľke doplňte podľa potreby.
  V tabuľke uveďte OE z tabuľky uvedenej v kapitole 4.3.2 Dátový rozsah projektu - Prehľad objektov evidencie - TO BE:

4.3.4.2Roly a predbežné personálne zabezpečenie pri riadení dátovej kvality

V nasledujúcej tabuľke definujte potrebné kapacity pre zabezpečenie riadenia dátovej kvality – napr. dátový kurátor, data steward, dátový špecialista pre dátovú kvalitu, databázový špecialista, projektový manažér a pod. (informácie k téme: https://mirri.gov.sk/sekcie/informatizacia/egovernment/datova-kancelaria/datova-kvalita/ )

4.3.5Otvorené údaje

V nasledujúcej tabuľke doplňte objekty evidencie, ktoré budú realizáciou projektu sprístupnené ako otvorené údaje. Uveďte názov objektu evidencie (identifikované v kapitole dátový rozsah projektu) pre kategóriu otvorených údajov a stanoviť úroveň požadovanej kvality (interoperability) otvorených údajov. Pravidlá pre úroveň interoperability verejných otvorených údajov sú stanovené v https://wiki.vicepremier.gov.sk/pages/viewpage.action?pageId=23986518.
Požadovaná kvalita:

• Automatizované publikovanie otvorených údajov v kvalite 3★ (Všetky datasety je potrebné registrovať v centrálnom katalógu otvorených údajov na data.gov.sk). Formát CSV, XML, ODS, JSON
• Automatizované publikovanie otvorených údajov v kvalite 4★ (Všetky datasety je potrebné registrovať v centrálnom katalógu otvorených údajov na data.gov.sk) Formát údajov RDF, OWL, TriX, JSON
• Automatizované publikovanie otvorených údajov v kvalite 5★ (Všetky datasety je potrebné registrovať v centrálnom katalógu otvorených údajov na data.gov.sk) Formát údajov RDF, OWL, TriX, JSON.
  V tabuľke uveďte OE z tabuľky uvedenej v kapitole 4.3.2 Dátový rozsah projektu - Prehľad objektov evidencie - TO BE:

4.3.6Analytické údaje

Analytické údaje predstavujú obrovskú skupinu dát získavaných vysokou rýchlosťou z vysokého počtu rôznych typov zdrojov. V priestore verejnej správy sa jedná o dátové zdroje, ktoré sú vytvárané a spravované jednotlivými organizáciami za účelom podpory služieb verejnej správy, služieb vo verejnom záujme alebo verejných služieb. Tieto údaje môžeme okrem uvedenej primárnej funkcie využiť aj na analytické spracovanie, tak aby verejná správa dokázala využívať svoje údaje pre potreby prípravy analýz, na podporu rozhodovania, riadenia a lepší návrh politík. Podmienkou pre plné využitie potenciálu údajov vo verejnej správe je ich poznanie (informácie o dátových zdrojoch, ich obsahu a atribútoch) a zabezpečenie prístupu k analytickým údajom pre analytické jednotky.  
V nasledujúcej tabuľke uveďte, ktoré objekty evidencie budú projektom pripravené na analytické účely a sprístupňované pre analytické jednotky (napr. pre systém Konsolidovaná Analytická Vrstva – KAV: https://data.gov.sk/id/egov/isvs/9655 ).
Informácie k sprístupneniu dátových zdrojov organizácie na analytické účely: https://mirri.gov.sk/sekcie/informatizacia/egovernment/datova-kancelaria/analyticke-udaje/

4.3.7Moje údaje

V tejto časti je potrebné uviesť informácie súvisiace s údajmi, ktoré spadajú do kategórie mojich údajov, z pohľadu budúceho TO BE stavu projektu. Za moje údaje sa považujú najmä: 

• množina údajov o konaní, ktoré sa týkajú fyzickej osoby alebo právnickej osoby 
• množina údajov, vrátane osobných údajov, viažucich sa k fyzickej osobe alebo právnickej osobe ako ku subjektu evidencie, ktoré sú predmetom evidovania povinným subjektom, 
• množina údajov obsiahnutých v návrhu na začatie konania, žalobe, rozhodnutí, žiadosti, sťažnosti, vyjadrení, stanovisku a ohlásení alebo inom dokumente, ktorý vydáva v konaní povinný subjekt, viažuci sa ku konkrétnej fyzickej osobe alebo právnickej osobe.
  Relevantné údaje budú sprístupnené prostredníctvom modulu procesnej integrácie a integrácie údajov - modul Manažmentu osobných údajov pre dotknuté osoby (občanov a podnikateľov) na základe preukázania elektronickej identity osoby. Podmienkou je zabezpečiť, aby údaje identifikované pre službu moje údaje boli prístupné elektronicky v strojovo-spracovateľnom formáte automatizovaným spôsobom cez aplikačné programovacie rozhranie, alebo prostredníctvom modulu procesnej integrácie a integrácie údajov.
  Informácie k sprístupneniu dátových zdrojov organizácie pre službu moje údaje:
  https://mirri.gov.sk/sekcie/informatizacia/egovernment/datova-kancelaria/moje-udaje/ .
  Minimálny rozsah pre vyhlásenie dátových prvkov za moje údaje, ktoré musí žiadateľ v projekte zabezpečiť: 
• označenie povinného subjektu, 
• názov ISVS v ktorom je dátový prvok obsiahnutý, 
• kód informačného systému, v ktorom je dátový prvok obsiahnutý, podľa centrálneho metainformačného systému, 
• označenie dátového prvku, 
• strojovo-spracovateľný formát dátového prvku, 
• technickú špecifikáciu aplikačného programovacieho rozhrania, 
• ďalšie doplňujúce informácie. 
• transparentný pohľad na prístup k údajom subjektu, k logom (kto pristupoval k údajom, za akým účelom a kedy). 
  V prípade, že predkladateľ projektu disponuje údajmi, ktoré spadajú do kategórie mojich údajov, je potrebné vyplniť nasledovnú tabuľku. V tabuľke uveďte OE z tabuľky uvedenej v kapitole 4.3.2 Dátový rozsah projektu - Prehľad objektov evidencie - TO BE.

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

Vyplňte nasledujúcu súhrnnú tabuľku pre kategorizáciu údajov dotknutých projektom z pohľadu využiteľnosti týchto údajov.
V tabuľke uveďte OE z tabuľky uvedenej v kapitole 4.3.2 Dátový rozsah projektu - Prehľad objektov evidencie - TO BE.

4.4Technologická vrstva

4.4.1Prehľad technologického stavu - AS IS

Uveďte popis a model technologickej vrstvy AS IS stavu, používané výpočtové prostriedky, konfigurácie siete, problematické body, ktoré je potrebné projektom riešiť.

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

Doplňte pre TO BE stav do nasledujúcej tabuľky požiadavky na výkonnostné parametre, kapacitné požiadavky, ktoré majú vplyv na výkon, sizing prostredia, napr. počet interných používateľov, počet externých používateľov, počet spracovávaných procesov, dokumentov, komunikáciu medzi vrstvami architektúry IS, využívanie sieťovej infraštruktúry (Govnet, LAN, VPN, …).

4.4.3Návrh riešenia technologickej architektúry

Uveďte návrh a model architektúry technologickej vrstvy s prihliadnutím na zavedenie Cloud-Native ako štandardu pre vývoj nových ITVS a pre programovanie starých ITVS do nového štandardu a na zavedenie štandardu vytvárania a používania zdieľaných služieb.
V prípade, že riešenie nepredpokladá využívanie cloudových služieb z katalógu služieb vládneho cloudu (Iaas,PaaS,SaaS podľa katalógu služieb VC), je potrebné nevyužitie cloudových služieb z katalógu služieb vládneho cloudu dostatočne zdôvodniť.
Taktiež požiadavky riešenia na HW, SW a licencie v zmysle požadovaného sizingu pre vývojové, testovacie a produkčné prostredie je potrebné uviesť v dokumente BC/CBA na príslušných kartách.
V popise návrhu riešenia je požadované uviesť:

• prístup k riešeniu technologickej architektúry a súvisiace architektonické rozhodnutia
• popis požiadaviek na prevádzkové prostredia (vývoj, test, produkčné)
• diagram nasadenia a komunikačnej infraštruktúry.
  Pri výbere požiadaviek na riešenie, je potrebné klásť dôraz na výber služieb, ktoré sú založené na najmodernejších technológiách, prostredníctvom ktorých bude vytvorený predpoklad na vývoj/tvorbu moderného ISVS. Pre navrhované riešenie odporúčame použiť prístup pre vývoj takzvaných Cloud Native aplikácií. Riešenie „Cloud-native“ ISVS, je v čo najväčšej miere nezávislé na umiestnení v cloude, resp. datacentre. Nezávislosť novo vyvíjaného ISVS od cloudového prostredia by malo byť základnou prioritou a podmienkou architektúry ISVS.

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

Zaevidujte v MetaIS využívanie infraštruktúrnych služieb vašimi ISVS. Podrobné informácie o evidencii využívania infraštruktúrnych služieb sú uvedené v Používateľskej príručke MetaIS, kap. 2.1.4.3 ISVS využívajúci infraštruktúrne služby.

• Vývojové – určené pre vývoj systému
• Testovacie – určené pre testy nových modulov, úprav, zmenových požiadaviek a retesty na úrovni upgrade‑ov (nie pre záťažové testovanie).
• Produkčné – určené pre produkčnú (ostrú) prevádzku systému
• Ďalšie existujúce alebo plánované prostredia, ktoré budú potrebné, napr. predprodukčné, integračné, fix prostredie
  Poznámky:
  Ak potrebujete pre príslušné prostredie viaceré infraštruktúrne služby, pridajte si potrebné riadky.
  V prípade, že neplánujete využitie cloudových služieb z katalógu služieb vládneho cloudu, uveďte v tabuľke požadovaných výpočtových zdrojov (sizing) pre jednotlivé prostredia parametre výpočtových zdrojov, ktoré plánujete v projekte použiť. Namiesto názvu a kódu infraštruktúrnej služby uveďte kód a názov výpočtového zdroja evidovaného v MetaIS.
  V súlade s NKIVS by technologická architektúra mala byť založená na cloudových službách. V rámci verejného obstarávania je potrebné potenciálneho uchádzača o zákazku požiadať o návrh technologickej infraštruktúry potrebnej pre implementáciu a prevádzku navrhovaného riešenia. Dodávateľ by pre svoj návrh technologického prostredia mal využiť hlavne cloudové služby vládneho cloudu uvedené v katalógu služieb, ktoré prešli procesom klasifikácie, hodnotenia, registrácie a zaradenia do katalógu služieb zverejnenom na stránke MIRRI: https://www.mirri.gov.sk/sekcie/informatizacia/egovernment/vladny-cloud/katalog-cloudovych-sluzieb.

4.5Bezpečnostná architektúra

Uveďte popis AS IS stavu z pohľadu súčasného riešenia bezpečnostnej architektúry,
Uveďte popis TO BE stavu riešenia bezpečnostnej architektúry (+ popis alternatív),
Uveďte súlad navrhovanej 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.
  Stručne popíšte postupy na dosiahnutie potrebnej úrovne bezpečnosti a spôsob zabezpečenia aktív projektu na jednotlivých vrstvách architektúry (dôvernosť, dostupnosť a integrita).
  Uveďte požiadavky na realizáciu Bezpečnostného projektu⁶
  Doplňte požiadavky na používateľské role, správu prístupov a správu aplikácie:
• Interní používatelia (pracovníci jednotlivých organizačných jednotiek, pracovníci administrácie a správy aplikácie, pracovníci prevádzky a podpory)
• Externí používatelia (zákazníci, partneri - tretie strany).

5.Závislosti na ostatné ISVS / projekty

Uveďte sumárny prehľad všetkých projektov, programov a informačných systémov (ISVS), od ktorých je realizácia pripravovaného projektu závislá.
Uveďte ako záujmové osoby (stakeholder) organizačné jednotky verejnej správy zodpovedné za poskytnutie potrebnej súčinnosti pre pripravovaný projekt.

6.Zdrojové kódy

Doplňte požiadavky na zdrojové kódy (napr. zo vzorovej zmluvy). Aké druhy, formy a štruktúry zdrojových kódov požadujte odovzdať. Stručne popíšte aj spôsob ich preberania, periodicitu (pri akých míľnikoch) a spôsob archivácie,
Doplňte pravidlá pre preberanie, správu a archiváciu zdrojových kódov a tieto pravidlá následne preniesť do Zmluvy o dielo alebo zmluvy na podporu (ZoD/SLA).
Naviažte preberanie/odovzdávanie zdrojových kódov na fakturačné míľniky.
Navrhnite spôsob, ako predísť „Vendor lock-in“ = t.j. dodávané riešenie musí byť v súlade so Zákonom o ITVS (ktorý „vendor lock-in“ nepovoľuje). Následne ustanovenia predchádzaniu vendor-lockinu musia byť zahrnuté aj v ZoD a SLA.
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

7.Prevádzka a údržba

Doplňte popis AS IS stavu zabezpečenia prevádzky a údržby a úroveň poskytovania služieb (SLA).
Doplňte popis TO BE stavu zabezpečenia prevádzky a údržby a úroveň poskytovania služieb (SLA).
Uveďte prehľad všetkých predpokladaných požiadaviek na prevádzku a údržbu cieľového riešenia.

7.1Prevádzkové požiadavky

Uveďte popis L1 úrovne – požiadavky / očakávania
Uveďte popis L2 úrovne – požiadavky / očakávania
Uveďte popis L3 úrovne – požiadavky / očakávania
Uveďte štandardný čas podpory, čas/rýchlosť odstraňovania vád, dostupnosť systému, zálohovanie, plán obnovy systému, atď.
Uveďte požadované SLA na služby systémovej a aplikačnej podpory – servisné služby vzťahujúce sa na produkčné a testovacie prostredie IS.

7.1.1Úrovne podpory používateľov

Help Desk bude realizovaný cez 3 úrovne podpory, s nasledujúcim označením:

• L1 podpory IS (Level 1, priamy kontakt zákazníka) - jednotný kontaktný bod verejného obstarávateľa – IS Solution manager, ktorý je v správe verejného obstarávateľa a v prípade jeho nedostupnosti Centrum podpory používateľov (zabezpečuje prevádzkovateľ IS a DataCentrum).
• L2 podpory IS (Level 2, postúpenie požiadaviek od L1) - vybraná skupina garantov, so znalosťou IS (zabezpečuje prevádzkovateľ IS – verejný obstarávateľ).
• L3 podpory IS (Level 3, postúpenie požiadaviek od L2) - na základe zmluvy o podpore IS (zabezpečuje úspešný uchádzač).
  Definícia:
• Podpora L1 (podpora 1. stupňa) - začiatočná úroveň podpory, ktorá je zodpovedná za riešenie základných problémov a požiadaviek koncových užívateľov a ďalšie služby vyžadujúce základnú úroveň technickej podpory. Základnou funkciou podpory 1. stupňa 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ď.
• Podpora L2 (podpora 2. stupňa) – 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 najobťiažnejších Hlásení, vrátane prevádzania hĺbkových analýz a riešenie extrémnych prípadov.
  Pre služby sú definované takéto SLA:
• Help Desk je dostupný cez IS Solution manager a pre vybrané skupiny užívateľov cez telefón a email, incidenty sú evidované v IS Solution manager,
• Dostupnosť L3 podpory pre IS je 8x5 (8 hodín x 5 dní od 8:00h do 16:00h počas pracovných dní),

7.1.2Riešenie incidentov – SLA parametre

Za incident je považovaná chyba IS, t.j. správanie sa v rozpore s prevádzkovou a používateľskou dokumentáciou IS. Za incident nie je považovaná chyba, ktorá nastala mimo prostredia IS napr. výpadok poskytovania konkrétnej služby Vládneho cloudu alebo komunikačnej infraštruktúry.
Označenie naliehavosti incidentu:

• 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.

7.2Požadovaná dostupnosť IS:

7.2.1Dostupnosť (Availability)

Dostupnosť (Availability) je pojem z oblasti riadenia bezpečnosti v organizácii. Dostupnosť znamená, že dáta sú prístupné v okamihu jej potreby. Narušenie dostupnosti sa označuje ako nežiaduce zničenie (destruction) alebo nedostupnosť. Dostupnosť je zvyčajne vyjadrená ako percento času v danom období, obvykle za rok. Orientačný zoznam dostupnosti je uvedený v nasledovnom prehľade:

• 90% dostupnosť znamená výpadok 36,5 dňa
• 95% dostupnosť znamená výpadok 18,25 dňa
• 98% dostupnosť znamená výpadok 7,30 dňa
• 99% dostupnosť znamená výpadok 3,65 dňa
• 99,5% dostupnosť znamená výpadok 1,83 dňa
• 99,8% dostupnosť znamená výpadok 17,52 hodín
• 99,9% (“tri deviatky”) dostupnosť znamená výpadok 8,76 hodín
• 99,99% (“štyri deviatky”) dostupnosť znamená výpadok 52,6 minút
• 99,999% (“päť deviatok”) dostupnosť znamená výpadok 5,26 minút
• 99,9999% (“šesť deviatok”) dostupnosť znamená výpadok 31,5 sekúnd
  Hoci je obvyklé uvádzať dostupnosť v percentách, presnejšie ukazovatele sú vyjadrením doby obnovenia systému a na množstvo dát, o ktoré môžeme prísť:
• RTO (Recovery Time Objective) - doba obnovenia systému, t.j. za ako dlho po výpadku musí byť systém funkčný (pre bližšie info klik na nadpis)
• RPO (Recovery Point Objective) - aké množstvo dát môže byť stratené od vymedzeného okamihu
• Recovery Time - čas potrebný k obnove
  Riešenie dostupnosti v praxi: Nedostupnosť dát je jedným z rizík, ktorý môže postihnúť každú organizáciu. Dostupnosť je jedným s kľúčových požiadaviek na každý dôležitý informačný systém a vplyv na dostupnosť má mnoho faktorov, napríklad:
• Dostupnosť servera
• Dostupnosť pripojenie k internetu
• Dostupnosť databázy
• Dostupnosť webových stránok
  V prípade, že je časť softvér alebo infraštruktúra zabezpečovaná externe (napr. hosting, webhosting), prenáša sa zodpovednosť za dostupnosť týchto komponentov na dodávateľa. Potom je potrebné mať vhodným spôsobom ošetrenú úroveň dostupnosti, ktorú musí dodávateľ dodržať. Zvyčajne je dostupnosť súčasťou dohody o úrovni poskytovaných služieb (SLA).

7.2.2RTO (Recovery Time Objective)

Recovery Time Objective (zvyčajne sa požíva skratka RTO) je jeden z ukazovateľov dostupnosti dát. RTO vyjadruje množstvo času potrebné pre obnovenie dát a celej prevádzky nedostupného systému (softvér). Môže byť, v závislosti na použitej technológii, vyjadrené v sekundách, hodinách či dňoch.
Využitie RTO v praxi: Ukazovateľ RTO sa z pohľadu zákazníka využíva pre vyjadrenie doby pre obnovu dát. (napr. formou SLA). Na druhú stranu poskytovatelia dnes môžu voliť rôzne technológie zálohovanie, respektíve replikovanie dát a dobu obnovy dát znížiť až k nulovému výpadku. Existujúce technológie sa delia zhruba nasledovne:

• Tradičné zálohovanie - výpadok a obnova trvá cca hodiny až dni
• Asynchrónne replikácie dát - výpadok a obnova v poriadku sekúnd až minút
• Synchrónny replikácie dát - nulový výpadok

7.2.3RPO (Recovery Point Objective)

Recovery Point Objective (zvyčajne sa požíva skratka RPO) je jeden z ukazovateľov dostupnosti dát. RPO vyjadruje, do akého stavu (bodu) v minulosti možno obnoviť dáta. Inými slovami množstvo dát, o ktoré môže organizácia prísť.
Využitie RPO v praxi: Ukazovateľ RPO sa z pohľadu zákazníka využíva pre vyjadrenie množstva obnoviteľných dát. (napr. formou SLA). Na druhú stranu poskytovatelia dnes môžu voliť rôzne technológie zálohovanie, respektíve replikovanie dát a bod obnovy dát znížiť až k nulovej strate. Existujúce technológie sa delia zhruba nasledovne:

• Tradičné zálohovanie - výpadok a obnova trvá cca hodiny až dni
• Asynchrónne replikácie dát - výpadok a obnova v poriadku sekúnd až minút, strata sa blíži k nule
• Synchrónny replikácie dát - nulová strata

8.Požiadavky na personál

Doplniť požiadavky na projektové personálne zabezpečenie (projektové role a ich obsadenie).
Doplniť rámcové požiadavky na obsadenie TO BE procesu.
Doplniť požiadavky potrebných školení a certifikátov.

9.Implementácia a preberanie výstupov projektu

Posúďte a doplňte spôsoby realizácie projektu a ich dopad na harmonogram projektu a preberanie výstupov pripravovaného projektu.
V zmysle Vyhlášky 401/2023 Zz o riadení projektov a zmenových požiadaviek v prevádzke je potrebné posúdiť výber spôsobu realizácie projektu metódou waterfall, metódou agile alebo metódou waterfall s prvkami metódy agile.
V zmysle vyhlášky 401/2023 Zz o riadení projektov a zmenových požiadaviek v prevádzke je možné pristupovať k realizácii projektu prostredníctvom čiastkových plnení, t.j. inkrementov, a to:

• Inkrement musí obsahovať z realizačnej fázy projektu aspoň etapu Implementácia a Testovanie a Nasadenia do produkcie. Je možné ho realizovať viacerými iteráciami v závislosti od charakteru projektu a každý doručený inkrement projektu je nasadený na produkčnom prostredí informačnej technológie a je možné začať s dokončovacou fázou projektu, alebo pokračovať ďalším inkrementom.
• Ak realizačná fáza veľkých projektov pozostáva z dodania jedného funkčného celku alebo dodania výlučne technických prostriedkov, objednávateľ v produkte PI-03 Prístup k projektu a v M-05 Analýza nákladov a prínosov - BC/CBA, posúdi a vyhodnotí aj alternatívy rozdelenia na inkrementy na preukázanie ekonomickej nevýhodnosti alebo technických obmedzení rozdeliť projekt na inkrementy.

10.Prílohy

V prípade potreby doplňte zoznam príloh 
Poznámka: odporúčame, aby ste si VŠETKY TABUĽKOVÉ VSTUPY evidovali a spravovali v jednom centrálnom súbore formátu EXCEL – s cieľom minimalizovať budúcu prácnosť s aktualizáciou a udržiavaním obsahu.
Inštrukcie k verejnému pripomienkovaniu:

• Podľa §4 ods. 10 vyhlášky č. 401/2023 Z.z je potrebné zrealizovať pripomienkovanie Projektového prístupu odbornou verejnosťou, zaevidovať a vyhodnotiť pripomienky odbornej verejnosti.
• Oznámenie o začatí verejného pripomienkovania zverejniť v centrálnom metainformačnom systéme verejnej správy na mieste určenom Orgánom vedenia.
• Dať na schválenie riadiacemu výboru výstupy po zverejnení vyhodnotenia pripomienok.
• Vyhodnotenie zverejniť na webovom sídle objednávateľa (do projektového adresára).
  1 Podľa § 2 ods. 1 písm. i) vyhlášky MIRRI č. 401/2023 Z.z. o riadení projektov a zmenových požiadaviek v prevádzke informačných technológií verejnej správy sa objednávateľom rozumie správca alebo prevádzkovateľ ITVS, ktorý projekt realizuje alebo chce realizovať.
  2 https://avssr.horizzon.cloud/. O prístup do repozitára a poskytnutie licencie pre modelovací nástroj pracujúci s repozitárom modelov je potrebné požiadať na e-mailovej adrese: sprava_EA@mirri.gov.sk.
  3 The Open Group ArchiMate Model Exchange File Format Standard a špecifikácia BPMN 2.0
  4 Napr. modelovací nástroj Archi - Open Source ArchiMate Modelling: https://www.archimatetool.com.
  5 Napr. modelovací nástroj pre BPMN - Camunda Modeler - Open Source Desktop Modeler: https://camunda.com/download/modeler/.
  6 Správca ISVS je povinný zaviesť v organizácii systém riadenia informačnej (a kybernetickej) bezpečnosti a vypracovať bezpečnostný projekt pre ISVS podľa vyhlášky Ú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)
  Strana 23/23