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 MIRRI č. 401/2023 Z.z. v znení neskorších predpisov je tento výstup I-02 Projektový zámer určený na rozpracovanie detailných informácií prípravnej a iniciačnej fázy projektu z pohľadu aktuálneho stavu, budúceho stavu a navrhovaného riešenia.

Dokument Projektový zámer obsahuje manažérske zhrnutie, rozsah, ciele a motiváciu na realizáciu projektu, zainteresované strany, návrh merateľných ukazovateľov a obsahuje aj

1. detailný opis požadovaných projektových výstupov,
2. detailný opis obmedzení, predpokladov, tolerancií a návrh organizačného zabezpečenia projektu,
3. detailný opis rozpočtu projektu a jeho prínosov,
4. harmonogram projektu,
5. vyhodnotenie rizík a závislostí,

architektúru riešenia projektu na úrovni biznis vrstvy, aplikačnej vrstvy, dátovej vrstvy, technologickej vrstvy a bezpečnostnej architektúry, vyhodnotenie alternatív riešenia projektu pre každú vrstvu architektúry riešenia,

1. špecifikáciu a klasifikáciu údajov spracovaných v projekte,
2. požiadavky na prevádzku a údržbu výstupov projektu,
3. požiadavky na technologickú infraštruktúru a posúdenie alternatív prevádzky infraštruktúry cloud computingom,
4. požiadavky na zdrojové kódy,
5. opis implementácie projektu a preberania výstupov projektu.

Dokument vychádza zo schváleného projektového zámeru (Názov PZ IÚI  - Implementácia Inteligentných riešení v obci  Špačince), ktorý bolo na 13. zasadnutí Kooperačnej rady UMR Trnava schválená  V UZNESENí 13b/2025

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

• F          – funkcionálna alebo použí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         – nefukčná požiadavka (NFR)
• R         – označenie požiadavky

xx        – číslo požiadavky

3.Popis navrhovaného riešenia

Cieľom projektu je podpora a rozvoj obce prostredníctvom inovatívnych technológií, využívanie a prepájanie dát tak, aby sa zvýšila kvalita života, ekologickosti, bezpečnosti, odolnosti a udržateľnosti obce s dôrazom: na bezpečnosť občanov, ochranu majetku obce, zníženie výdavkov obce pri správe verejných budov a zvýšenie transparentnosti obce,  zlepšenie dopravnej situácie obce a kvality mikroklímy v kontexte blízkosti Jadrovej elektrárne Jaslovské Bohunice .

Cieľovou skupinou sú (výzva nedefinuje presnú cieľovú skupinu projektu, pre projekt definujeme):

1. Obyvatelia obce Špačince a MFO Trnava, ktorí budú profitovať z výstupov projektu
2. Prevádzkovatelia a užívatelia dátových systémov
3. Obyvatelia a návštevníci obce Špačince a celého územia MFO Trnava, ktorí budú profitovať z bezpečnejšieho mestského prostredia a efektívnejšieho riadenia

Miesto realizácie projektu: intravilán obce Špačince - zastavané plochy a k nim priliehajúce plochy (v okolí budov Obecného úradu, Základnej školy, Materskej školy, v okolí cintorína a na cestách v obci Špačince). Ulice: Hlavná, Hospodárska, Čerešňová, Ulička, Na pažiti, Poľovnícka, Na vŕšku, Poštová, Trnavská, Kaštieľska, Jozefa Strečanského, Športová, Hromová, Pod kaštieľom, Poľná, Horná,  Družstevná, Veterná, Krajná, Mlynská, Mierová, Záhradkárska, Brehová, Nad mlynom)

HA 1 IoT, dáta a platformy pre rozvoj tvorby, spracovania a využívania dát s cieľom inteligentného rozhodovania, plánovania a správy obce Špačince

Hlavná aktivita je zvolená v súlade s hlavnou aktivitou opatrenia 1.2.2: IoT, dáta a platformy - Podpora rozvoja tvorby, spracovania, využívania a prepájania dát v rámci verejnej správy, najmä rozvoja dátových platforiem, informačných systémov (v nadväznosti na inteligentné riadenie a podpory budovania miest a regiónov) a súvisiacich nástrojov s pridanou hodnotou pre inteligentné rozhodovanie, plánovanie a správu.

Predmetom aktivity je tvorba dátovo-analytickej platformy pre kamerový systém pre rozvoj tvorby, spracovania a využívania dát s cieľom inteligentného rozhodovania, plánovania a správy. Kamery ako IoT zariadenia budú mať vlastný analytický systém, ktorý bude zabezpečovať záznamové, ovládacie funkcie a systém riadenia. Analytické výstupy budú využívané nielen na bezpečnostné, ale aj rozvojové účely mesta pri ďalšom plánovaní obce Špačince.

HA2 Podpora bezpečnosti fyzického prostredia obce Špačince

Hlavná aktivita 2 je zvolená v súlade s hlavnou aktivitou opatrenia 5.1.3: prevencia kriminality (kamerové systémy, inštalácia nových bodov, ich rekonštrukcia v rizikových lokalitách ako súčasť integrovaného projektu, posilnenie pomáhajúcich profesií, adresná podpora aktivít zameraných na primárnu prevenciu, osveta a scitlivovanie bezpečnostných zložiek). Predmetom  doplnkovej aktivity je prevencia kriminality a zvýšenie bezpečnosti. Špeciálne kamery budú určené na detekciu konkrétnych osôb, čo môže byť užitočné napríklad pri pátraní po nezvestných osobách alebo pri identifikácii páchateľov trestných činov. V zmysle výzvy tieto aktivity chápeme ako doplnkovú aktivitu ku HA1. Cieľom je získať reálne makro dáta o počtoch, ktoré nám pomôžu pri lepšom plánovaní, skvalitnenia života obyvateľov, dopravy, parkovania, zlepšenia infraštruktúry, zvýšenia bezpečnosti a komfortu a zníženia kriminality.

4.Architektúra riešenia projektu

Alternatíva č.1: Zachovanie súčasného stavu

• Uvedená alternatíva predstavuje zachovanie súčasného stavu. Táto alternatíva by znamenala nerealizovanie projektu - pri zachovaní súčasného stavu nebolo možné postúpenie údajov z IoT zariadení a kamerového systému do IoT
• Alternatíva č. 2: Realizácia časti projektu
• Uvedená alternatíva predstavuje realizáciu časti projektu vlastnými kapacitami. Táto alternatíva je v súčasnosti nerealizovateľná. Pre obec by znamenala vysoké finančné zaťaženie, ktoré nie je v súčasnej situácie realizovateľné.
• Alternatíva č.3 Plnohodnotná realizácia projektu
• Alternatíva č.3 znamená realizáciu projektu v plnom rozsahu v zmysle technických návrhov riešení súčasnej situácie. Rovnako táto alternatíva znamená získavanie údajov z IoT zariadení pre oblasť a kamerového systému.

4.1Biznis vrstva

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

4.1.2Jazyková podpora a lokalizácia

Jazyková lokácia  - slovenčina.

4.2Aplikačná vrstva

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

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

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

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

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

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

4.2.9Konzumovanie údajov z IS CSRU – TO BE

4.3Dátová vrstva

N/A, predmetom projektu nie je manažment údajov.

4.3.1Údaje v správe organizácie

N/A 

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

4.3.3Referenčné údaje

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

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

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