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

Tento dokument je strategickým a operatívnym nástrojom, ktorý slúži na plánovanie, riadenie, implementáciu a kontrolu projektu „Inovatívne formuláre mesta Košice“. Je vypracovaný v súlade s vyhláškou č. 401/2023 Z.z. a jeho cieľom je zabezpečiť hladký priebeh všetkých etáp projektu, od prípravnej fázy až po jeho úspešnú realizáciu a udržateľnosť.

Dokument detailne rozpracováva všetky kľúčové aspekty projektu, pričom kladie dôraz na opis aktuálneho stavu, cieľového budúceho stavu a návrhu konkrétneho riešenia. Vychádza z aktuálnej situácie elektronických služieb v meste Košice, ktoré sú nepostačujúce pre moderné potreby občanov, podnikateľov a zamestnancov mesta Košice. Cieľom je vytvoriť riešenie, ktoré bude jednoduché, prístupné a efektívne. Dokument zahŕňa podrobný návrh architektúry riešenia vrátane biznis vrstvy, aplikačnej vrstvy, dátovej vrstvy, technologickej vrstvy a infraštruktúry. Taktiež obsahuje opis bezpečnostnej architektúry, ktorá má zabezpečiť ochranu údajov a systémov v súlade s legislatívou.

Významnú časť dokumentu tvorí špecifikácia údajov, ktoré budú spracované v rámci projektu. Zahŕňa aj procesy čistenia údajov, ktoré sú potrebné na dosiahnutie ich konzistencie a kvality. Prevádzka a údržba výstupov projektu sú detailne opísané, pričom dôraz sa kladie na dlhodobú udržateľnosť riešenia. Dokument sa venuje aj prevádzkovým požiadavkám, požiadavkám na zdrojové kódy a zabezpečeniu ich dostupnosti pre budúce úpravy a rozvoj. Zvláštna pozornosť je venovaná zabezpečeniu, že dodávané riešenie bude plne v súlade s legislatívnymi normami.

Implementácia projektu je detailne rozpracovaná v jednotlivých fázach, od návrhu cez testovanie až po preberanie výstupov projektu. Každá fáza je riadená podľa definovaných pravidiel riadenia kvality, pričom sú presne špecifikované procesy na overenie zhody výstupov projektu s požiadavkami. Zároveň je zabezpečený súlad so zákonom č. 95/2019 Z.z. o informačných technológiách vo verejnej správe, ako aj ďalšími normami, ako sú štandardy ID-SK 3.0.

Význam dokumentu spočíva v jeho funkcii ako základného rámca pre úspešnú realizáciu projektu. Detailné definovanie všetkých procesov, požiadaviek a výstupov umožňuje efektívne riadenie projektu a zabezpečenie jeho prínosov pre občanov a podnikateľov. Projekt „Inovatívne formuláre mesta Košice“ má potenciál významne zlepšiť dostupnosť a kvalitu elektronických služieb, zvýšiť efektivitu mestských procesov a priniesť dlhodobé úspory vo verejných financiách. Dokument zároveň zabezpečuje transparentnosť a umožňuje monitorovanie projektu zo strany všetkých zainteresovaných strán.

Tento dokument preto predstavuje dôležitý nástroj pre koordináciu a realizáciu projektu, ktorý prispieva k digitalizácii verejnej správy a modernizácii poskytovaných služieb. Jeho súlad s vyhláškou č. 401/2023 Z.z. a ďalšími legislatívnymi predpismi garantuje, že výsledky projektu budú plne reflektovať požiadavky modernej spoločnosti.

2.1Použité skratky a pojmy

3.Popis navrhovaného riešenia

Navrhované riešenie projektu „Inovatívne formuláre mesta Košice“ je úzko integrované s existujúcim Integrovaným informačným systémom mesta Košice (IIS KE). Projekt využíva aktuálne dostupné integrácie a dátové štruktúry v rámci systému, pričom predpokladá ich rozšírenie a úpravu na podporu nových funkcií a požiadaviek vyplývajúcich z modernizácie elektronických formulárov.

Prepojenie s Integrovaným informačným systémom mesta Košice

IIS KE predstavuje hlavný rámec pre integráciu elektronických služieb mesta. Navrhované riešenie sa zameriava na efektívne využitie existujúcej infraštruktúry a integrácií s cieľom minimalizovať duplicitu procesov a redundanciu údajov. Projekt umožní:

• Plnú integráciu modernizovaných formulárov s modulmi IIS KE, ako sú evidencia podaní, správa komunikácie s občanmi a spracovanie rozhodnutí.
• Automatizované výmeny údajov medzi systémami mesta Košice a externými registrami, ako sú register fyzických osôb, register právnických osôb či kataster nehnuteľností.
• Podporu už implementovaných procesov, ktoré budú prispôsobené na nové požiadavky projektu.

Dátové štruktúry

Riešenie vychádza z aktuálne používaných dátových štruktúr v IIS KE. Na podporu nových služieb a funkcionalít však projekt predpokladá ich úpravu a rozšírenie. Tieto úpravy zahŕňajú:

• Pridanie nových polí a tabuliek, ktoré umožnia zachytávanie údajov potrebných pre modernizované formuláre.
• Optimalizáciu existujúcich štruktúr s cieľom zlepšiť výkon databázových operácií a zabezpečiť rýchlejšie spracovanie údajov.
• Zavedenie pravidiel pre validáciu a čistenie údajov na zabezpečenie ich kvality a konzistencie.

Tieto zmeny budú vykonané s ohľadom na minimalizáciu dopadu na existujúce procesy a systémy. Súčasne budú vypracované mechanizmy na migráciu údajov z aktuálnych štruktúr do nových formátov, aby bol zabezpečený hladký prechod na modernizované riešenie.

Prínosy z integrácie a optimalizácie

Prepojenie projektu s IIS KE a úpravy dátových štruktúr prinesú niekoľko významných výhod:

• Efektívne spracovanie údajov: Zjednotené a optimalizované dátové štruktúry znížia duplicitu a redundanciu, čím sa zrýchli spracovanie podaní.
• Zníženie administratívnej záťaže: Automatizácia výmeny údajov medzi modulmi IIS KE a externými systémami minimalizuje manuálne zásahy zamestnancov.
• Zlepšenie používateľskej skúsenosti: Nové funkcionality umožnia občanom a podnikateľom rýchlejšie vybavovanie ich požiadaviek prostredníctvom intuitívnych formulárov.

Implementácia rozšírení

Projekt zahŕňa plán na rozšírenie a úpravu integračných modulov IIS KE, ktoré umožnia:

• Jednoduché pridávanie nových služieb a rozšírenie ich funkcionalít bez potreby zásadnej rekonfigurácie systému.
• Zavedenie rozhraní API pre komunikáciu s externými registrami a informačnými systémami verejnej správy.
• Neustále monitorovanie a optimalizáciu výkonu integračných modulov na zabezpečenie hladkého priebehu operácií.

Zabezpečenie kompatibility

Navrhované riešenie plne rešpektuje požiadavky vyhlášky č. 401/2023 Z.z., pričom zohľadňuje aj technické štandardy a legislatívne normy Slovenskej republiky. Kompatibilita so súčasnými modulmi IIS KE a zabezpečenie bezproblémového prepojenia s externými systémami sú prioritou pri návrhu a implementácii riešenia.

Dlhodobá udržateľnosť

Projekt je navrhnutý tak, aby všetky zmeny v integračných moduloch a dátových štruktúrach boli udržateľné z hľadiska budúceho rozvoja. Súčasťou projektu je plán pravidelných aktualizácií systému, údržby štruktúr a školení pre zamestnancov mesta, ktorí budú zodpovední za prevádzku a správu modernizovaného riešenia.

Prispôsobenie na budúce potreby

Úpravy dátových štruktúr a integrácií v rámci projektu zohľadňujú nielen aktuálne potreby mesta Košice, ale aj možnosť ich rozšírenia v budúcnosti. Flexibilita návrhu umožňuje rýchle zavedenie ďalších funkcionalít a služieb bez výrazného zásahu do existujúcej infraštruktúry.

Týmto riešením projekt zabezpečuje efektívne využitie existujúceho systému IIS KE, pričom reflektuje potreby modernizácie a digitalizácie mestských procesov. Návrh poskytuje dostatočný priestor pre ďalší rozvoj služieb a ich prispôsobenie na nové požiadavky občanov, podnikateľov a legislatívy.

4.Architektúra riešenia projektu

4.1Biznis vrstva

Na úrovni biznis vrstvy nedochádza k zásadnej zmene medzi stavom AS IS a TO BE, pretože hlavným cieľom projektu je

• zvýšiť mieru využívania elektronických služieb mesta Košice,
• zvýšiť komfort vyhľadania a navigácie na elektronickú službu mesta Košice,
• zvýšiť komfort vypĺňania elektronických formulárov a
• zosúladiť riešenie Infomodulu a elektronických formulárov so súčasnou legislatívou (ID SK 3.0).

V rámci modernizácie navigácie a výberu elektronických služieb na portáli mesta Košice, je potrebné sa zamerať na nasledovné oblasti:

1. Používateľská prívetivosť (UX):

• Potreba intuitívnej navigácie, ktorá umožní používateľom rýchlo a jednoducho nájsť požadované služby v prehľadných kategóriách a podkategóriách.
• Responzívny dizajn, ktorý zaistí pohodlné používanie na mobilných zariadeniach, tabletoch aj desktopoch.
• Možnosť personalizácie, aby si používatelia mohli prispôsobiť portál podľa svojich potrieb a preferencií.

2. Konzistentnosť a vizuálny dizajn:

• Konzistentný dizajn naprieč celým portálom, ktorý vytvorí harmonický a profesionálny dojem.
• Použitie štandardu ID-SK 3.0
• Zlepšenie čitateľnosti cez vhodné veľkosti písma, kontrastné farby a jednoduché grafické prvky.

3. Vyhľadávacie funkcie:

• Potreba pokročilého vyhľadávania s rýchlymi a presnými výsledkami.
• Možnosti filtrovania a triedenia obsahu, aby používatelia mohli efektívne nájsť informácie na základe relevantných kritérií.

4. Integrácia s existujúcimi systémami:

• Hladká integrácia s Kontom Košičana, aby používatelia mali jednotný prístup k personalizovaným službám.
• Automatizované načítavanie údajov z centrálnych registrov na zníženie záťaže používateľov.

5. Prístupnosť:

• Dodržiavanie štandardov prístupnosti, aby bol portál dostupný aj pre ľudí so zdravotným postihnutím.
• Zahrnutie alternatívnych textov pre obrázky a multimediálny obsah.

6. Spätná väzba a podpora:

• Potreba vytvorenia kanálov, ktoré umožnia používateľom poskytovať spätnú väzbu a návrhy na zlepšenie.
• Dostupnosť technickej podpory prostredníctvom rôznych kanálov, ako sú e-mail, alebo telefón.

Týmito vylepšeniami je možné dosiahnuť efektívnejší a používateľsky príjemnejší portál, ktorý lepšie spĺňa potreby obyvateľov mesta Košice.

Obrázok 1- Biznis vrstva

Obrázok 1 zobrazuje biznis vrstvu v notácii ArchiMate a popisuje biznis funkcie súvisiace s portálom elektronických služieb mesta Košice. Interakcie sú rozdelené do dvoch hlavných biznis funkcionalít: Výber služby a navigácia a Vytvorenie elektronického podania.

Výber služby a navigácia

Táto časť sa zaoberá prvotným kontaktom používateľa s portálom a poskytuje mu možnosť orientovať sa medzi dostupnými službami mesta Košice.  Používateľ si vyberá konkrétnu službu z ponuky na základe rôznych pohľadov (kategorizácie) – podľa toho či vystupuje ako fyzická osoba, alebo podnikateľ, podľa údajov získaných prihlásením prostredníctvom eID karty a pod. Systém poskytuje filtrovanie, aby sa vyhľadávanie zjednodušilo. Po výbere služby systém zobrazí podrobné informácie, ako sú postup podania, legislatíva, potrebné prílohy alebo požiadavky na autorizáciu. Tento krok slúži na informovanie používateľa pred samotným podaním.

Vytvorenie elektronického podania

Vytvorenie elektronického podania je riadený proces, ktorý sa skladá z nasledovných krokov:

• Predvyplnenie elektronického formulára: Ak sú dostupné údaje o používateľovi (napríklad z predchádzajúcich podaní alebo registrov), systém automaticky vyplní časť formulára, aby sa proces urýchlil.
• Zobrazenie elektronického formulára na vyplnenie: Používateľ dostane prístup k formuláru, kde môže doplniť chýbajúce informácie. Formulár je navrhnutý tak, aby bol používateľsky prívetivý.
• Kontrola zadaných údajov: Systém vykoná automatickú kontrolu správnosti a úplnosti zadaných údajov. Používateľ má tiež možnosť manuálne skontrolovať a upraviť údaje pred ich odoslaním.
• Priloženie požadovaných príloh k formuláru: Používateľ môže nahrať požadované  elektronické dokumenty vo formátoch v zmysle štandardov SR,
• Autorizácia: Pred odoslaním je potrebné overiť identitu používateľa. Môže ísť o overenie prostredníctvom kvalifikovaného elektronického podpisu,
• Odoslanie elektronického podania: Po úspešnom vyplnení a kontrole údajov sa podanie odošle na spracovanie do elektronickej schránky mesta Košice.

Získanie spätnej väzby na portáli je kľúčové pre zlepšovanie používateľskej skúsenosti a poskytovanie kvalitných služieb. Bude realizovaný:

• cielenou otázkou,
• možnosťou odpovede prostredníctvom ikony (udelenie hviezdičiek) a
• možnosťou napísania hodnotenia v textovej forme.

Zozbierané údaje sa budú  analyzovať. Je dôležité identifikovať opakujúce sa témy a venovať pozornosť problémom, ktoré môžu negatívne ovplyvňovať používateľský zážitok.

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

4.1.2Jazyková podpora a lokalizácia

Používateľské rozhranie bude lokalizované do slovenského jazyka.

4.2Aplikačná vrstva

Z pohľadu štruktúry modulov na aplikačnej vrstve nedochádza k zmene. Zmena sa však bude realizovať modernizáciou uvedených modulov a to:

• Infomodul-u a
• modulu eFORM

InfoModul

Zabezpečuje verejné grafické rozhranie systému ESKE. Súčasťou grafického rozhrania je celá elektronická služba. Infomodul riadi kroky navigácie a poskytovania každej elektronickej služby. V rámci projektu bude modernizovaný spôsob sprevádzania občana a podnikateľa poskytovanou elektronickou službou.

eForm modul – interný

Tento modul vytvára technické prostredie pre prevádzku elektronických formulárov náležiacich k elektronickej službe. Modul zabezpečuje technické nastavenie, funkcionalitu, čítanie a doplňovanie číselníkových hodnôt (napr. zoznamy položiek, číselníky poplatkov, geografické číselníky, ...), komunikuje s komponentom riadiacim prílohy podania. Komponent interný eForm modul si vyžaduje rozsiahlu zmenu tak, aby bolo možné samotné elektronické formuláre vytvárať a prevádzkovať podľa požiadaviek:

• prevádzka a vytváranie elektronických formulárov v súlade s požiadavkami aktuálne platného jednotného dizajnu elektronických služieb ID SK,
• jednoriadkový dizajn formulárov,
• súhrnný kontrolný report s možnosťou prekliknutia sa na chybu vo formulári,
• zmena rozdelenia formulára do záložiek a na kroky,
• zmena polí formulára v zmysle princípu otázok a navigácie s pochopením požadovanej informácie v texte,
• interaktívne a dynamické úpravy polí a rozsahu formulárov podľa vložení údajov v predchádzajúcich korkoch vypĺňania formulára,
• zobrazovanie informácií o podaní podľa vyplnených údajov vo formulári,
• v prípade ak je následkom podania úhrada, informovanie o sume úhrady klienta, ktorý podanie vytvára.

Obrázok 4 Aplikačná vrstva

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

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

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

Kapitola pre plánovaný projekt nie je relevantná.

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

Kapitola pre plánovaný projekt nie je relevantná.

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

Kapitola nie je pre plánovaný projekt relevantná.

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

Kapitola nie je pre plánovaný projekt relevantná.

macro:idmacro:idmacro:id4.2.9Konzumovanie údajov z IS CSRU – TO BE

Kapitola nie je pre plánovaný projekt relevantná.

4.3Dátová vrstva

Kapitola nie je pre plánovaný projekt relevantná.

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