PRÍSTUP K PROJEKTU

(Verzia dokumentu v2.07/04_2023)

Identifikovanie požiadaviek na technickú časť riešenia

Identifikácia projektu

Schvaľovanie dokumentu

OBSAH

1.POPIS ZMIEN DOKUMENTU

1.1História zmien

2.ÚČEL DOKUMENTU

V súlade s vyhláškou č. 85/2020 Z. z. o riadení projektov v znení vyhlášky č. 545/2021 Z. z. (ďalej len „vyhláška č. 85/2020 Z. z.“) - je dokument Prístup k projektu pre prípravnú fázu určený na rozpracovanie zadania a požiadaviek k projektu, aby bolo možné rozhodnúť o realizácií projektu, alokovaní rozpočtu, ľudských zdrojov a prechode do inicializačnej, a realizačnej fázy.

2.1Manažérske zhrnutie

Pre uľahčenie životných situácii občana sa vytvoril zoznam, kde by mohol eGoverment pomôcť zrýchliť vybavenie formou jednej žiadosti miesto niekoľkých žiadostí na rôznych úradoch.

MD SR chce v spolupráci s MV SR a technickým garantom MIRRI SR poskytnúť občanovi, v rámci životnej situácie – kúpa/predaj vozidla , včasnú informáciu o stave skončenia platnosti TK/EK na jeho vozidle. Hlavnou pridanou hodnotou tejto zmenovej požiadavky bude rozšírenie spôsobu komunikácie OVM s občanom (G2C) o nový elektronický komunikačný kanál formou PUSH notifikácie priamo do mobilného telefónu občana cez SVM.

Okrem toho, občanovi poskytneme informáciu o konci platnosti TK/EK na jeho e-mailovú adresu a telefón formou SMS. Tieto notifikačné správy bude zasielať JISCD a to na tie kontaktné údaje na ktoré nám on sám poskytol na verejnom portáli JISCD (už existujúce riešenie) a/alebo údaje, ktoré nám poskytne MV SR pri zmene vlastníka/držiteľa vozidla, prípadne pri aktualizácií jeho osobných údajov na MV SR (nové riešenie v rámci zjednodušovania komunikácie občana s OVM a iniciatívy 1x a dosť).

Súčasťou tohoto zmenového konania bude integrácia pre zasielanie osobných údajov z MV SR do MD SR, rozšírenie možností úpravy kontaktných údajov na verejnom portáli JISCD, integrácia na novú SMS bránu a integrácia na služby MIRRI pre zasielanie PUSH notifikácií do aplikácie Slovensko v mobile.

2.2Použité skratky

3.POPIS NAVRHOVANÉHO RIEŠENIA

Navrhované riešenie predpokladá 4 samostatné produkty ktoré budú spoločne tvoriť celé zmenové konanie. Predpokladom je že už vychádzame z existujúcej funkcionality, ktorú JISCD má pre zasielanie notifikačných správ. Okolo tohto existujúceho riešenia príde k rozšíreniu najmä v komponente notifikácií a čiastočne v integračnom komponente OSB. Všetky 4 produkty, aj keď nezávislé na sebe, budú mať spoločný dopad na komponent notifikácií a každý z produktov bude pre svoju realizáciu vyžadovať špecifickú zmenu v tomto komponente.

3.1Produkt 1 – EVO integrácia

1. Vytvorenie webovej služby pre príjem, úpravu a výmaz kontaktných údajov o vlastníkovi/držiteľovi vozidla.
   • Pri volaní tejto služby budeme zisťovať vlastníka a držiteľa vozidla, pre ktorých budeme nastavovať PUSH notifikácie.
2. Realizácia integračného zámeru medzi MV SR (IS EVO) a MD SR pre prístup k vytvorenej webovej službe.

3. MV SR bude zasielať kontaktné údaje pre vozidlo podľa ich evidencie.
   • JISCD tieto údaje bude pridávať už k existujúcim, ak nenastane prípad pre nahradenie údajov po prepise vozidla

3.2Produkt 2 - SVM integrácia

1. Realizácia integračného zámeru na službu MIRRI, ktorou vyžiadame zaslanie PUSH notifikácie na mobilný telefón občana spôsobom volania API ktorá zabezpečí doručenie PUSH notifikácie. Technická realizácia predpokladá volanie API služby pre zasielanie notifikácie do SVM.

2. Tak ako aktuálne už JISCD zasiela notifikačné správy na e-mail a SMS, tak bude posielať požiadavku na API MIRRI, ktoré aktivuje proces pre zobrazenie PUSH notifikácie na mobilnom telefóne občana ak ma aktivované SVM.

3.3Produkt 3 – integrácia na novú SMS bránu

1. Integrácia na novú SMS bránu podľa dodatočného zadania od MD SR.

2. Táto integrácia nebude okamžite nahrádzať existujúce riešenie, namiesto toho bude fungovať súbežne s existujúcim a bude aktivované len v prípade manuálneho prepnutia podľa konfigurácie, prípadne prepnuté naspäť na pôvodné riešenie.

3.4Produkt 4 – úprava public portálu JISCD a notifikačného komponentu

1. Úprava public portálu JISCD.

1. 
   
   • Zobrazenie zoznamu e-mailových adries a telefónnych čísiel k evidovaným vozidlám s nastavenými notifikáciami.
   • Možnosť pridania ďalšieho kontaktu.
   • Možnosť vymazania kontaktu.
   • Možnosť úpravy existujúceho kontaktu.
   • Občan môže stále zadať svoje globálne kontaktné údaje a týchto môže byť viac (pole e-mailových adries a telefónnych čísiel).
2. Úprava dátového modelu plánovaných notifikácií tak aby umožňovali odosielanie na viacero e-mailových adries a telefónnych čísiel pre jedno vozidlo.
3. Úprava notifikačného komponentu.
   • Možnosť nastavenia viacerých plánovaných notifikácií pre viacero kontaktných údajov a ich úprava/výmaz (e-mail a SMS, PUSH notifikácie)
   • Zneplatnenie všetkých plánovaných notifikácií a kontaktných údajov občana k vozidlu v prípade ak stratí väzby na vozidlo. Občan nedostane notifikáciu o zneplatnení jeho kontaktných údajov a notifikácií k vozidlu.
4. Rozšírenie číselníka a dátového modelu o novú formu notifikácie – PUSH notifikácia.

3.5Požiadavky MD SR na realizáciu

V rámci procesov interných konzultácií a stretnutí so zástupcami MIRRI sa identifikovalo viacero požiadaviek na realizáciu v rámci predmetného zmenového konania. Požiadavky sú vypísané s ich popisom v podkapitole funkčných požiadaviek.

3.6Funkčné požiadavky

4.ARCHITEKTÚRA RIEŠENIA PROJEKTU

Toto zmenové konanie nebude mať zásadný dopad na architektúru JISCD a bude najmä rozširovať už existujúcu funkcionalitu. Vytvorí sa nová webová služba na strane JISCD a zrealizuje sa integrácia na existujúce služby MIRRI/NASES a novej SMS brány. Príde k úprave existujúceho notifikačného komponentu v JISCD v zmysle tejto zmenovej požiadavky.

4.1Biznis vrstva

V rámci biznis vrstvy dochádza k naplneniu potreby občana k jeho životnej udalosti  kúpa/predaj vozidla. Veľká časť zmenového konania je technickej povahy a zásadná viditeľná zmena je možnosť prijatia informácie o stave platnosti TK/EK pre vozidlo občana na kontaktné údaje, ktoré má evidované v IS EVO MV SR a/alebo súčasne aj na jeho mobilný telefón formou PUSH notifikácie do SVM.

4.1.1Produkt 1 – EVO integrácia

Aktuálny stav – v súčasnosti nemá JISCD kontaktné údaje z MV SR.

Budúci stav – JISCD poskytne webovú službu, ktorou bude MV SR zasielať kontaktné údaje občana, ktoré má vo svojej databáze. Tieto kontaktné údaje sú pre konkrétne vozidlo vo vzťahu vlastník alebo držiteľ. Pri zmene stavu vozidla nám MV SR zašle opätovne kontaktné údaje. Zároveň, keď dostaneme kontaktné údaje z MV SR, tak sa pokúsime získať PČO pre držiteľa a vlastníka vozidla. PČO potrebujeme pre nastavenie PUSH notifikácie, ktoré budeme aktívne zasielať bez ohľadu na to či máme aj iný kontakt a tento typ notifikácie plánujeme pre konkrétne vozidlo. PUSH notifikáciu budeme nastavovať prioritne iba na PČO držiteľa vozidla a to len v prípade, že ide o fyzickú osobu. Na vlastníka vozidla sa neprihliada (len ako sekundárne riešenie ak nie je držiteľ na vozidle). PUSH notifikáciu plánujeme vždy ak sú tieto podmienky splnené. Nie je možné odvolať zasielanie plánovaných notifikácií ináč ako prepisom vozidla na inú osobu.

Obrázok 1. Prijatie osobných kontaktných údajov z MV SR na JISCD.

4.1.2Produkt 2 – SVM integrácia

Aktuálny stav – JISCD nemá vybudovanú integráciu na SvM.

Budúci stav – K existujúcemu riešeniu pribudne nová forma elektronického komunikačného kanálu formou PUSH notifikácie. Tie budeme zasielať na aktivované SVM v chytrom mobilnom zariadení občana. Nebudeme ale zasielať tieto správy priamo na SVM, ale využijeme API službu, ktorú nám poskytne MIRRI cez dohodu o integračnom zámere. Predpokladáme, že na túto službu budeme zasielať PČO spolu s textom notifikačnej správy a jej typom (predmetom). Pre doručenie správy neočakávame, že bude garantované a nebudeme ani sledovať doručené/nedoručené správy. Správu budeme zasielať vždy na API ako je naplánovaná bez ohľadu na to, či má alebo nemá občan aktivované SVM.

Obrázok 2. Zaslanie PUSH notifikácie na SVM.

4.1.3Produkt 3 – integrácia na novú SMS bránu

Aktuálny stav – v súčasnosti JISCD už posiela SMS správy cez existujúcu API integráciu na dodávateľa služieb – „zasielania SMS správ“.

Objem:

na základe štatistík z r. 2022 je objem zasielaných SMS správ per mesiac – 13 tisíc.

Budúci stav – k existujúcemu riešeniu sa pridá nový dodávateľ služieb pre zasielanie SMS správ. Táto nová integrácia bude realizovaná k už existujúcej bez zmeny aktuálneho riešenia. Potrebujeme aby táto nová integrácia existovala v režime prepínania medzi už aktuálnou integráciou a touto novou integráciou. Pomocou zmeny konfigurácie JISCD potrebujeme dosiahnuť taký stav, ktorým môžeme medzi týmito dvoma integráciami prepínať kedykoľvek v čase a rozhodnúť ktorá je práve aktuálne používaná. Prioritne pre výber technológie a komunikačných protokolov by obstarávateľ uprednostňoval HTTP RESTful API.

Obrázok 3. Zaslanie SMS notifikačnej správy

4.1.4Produkt 4 – úprava public portálu JISCD a notifikačného komponentu

Aktuálny stav – v súčasnosti má JISCD zabudovanú funkcionalitu na notifikovanie občana formou e-mailovej a SMS správy. Občan sa musí prihlásiť do JISCD pomocou eID alebo kombináciou VIN a OEII. Následne si môže nastaviť globálne nastavenie alebo jednotlivé nastavenie na vozidlo, kde zadá jednu e-mailovú adresu a/alebo jedno telefóne číslo.

Budúci stav – Občan sa stále bude prihlasovať buď eID alebo kombináciou VIN a OEII do JISCD, kde bude môcť zmeniť nastavenia notifikácií. Avšak, predpokladáme že už môže zadať zoznam e-mailových adries a telefónnych čísiel. Tento zoznam bude doplnený o také kontakty, ktoré nám zašle MV SR pomocou vytvorenej webovej služby (uvedené v Produkte 1).

Obrázok 4. Úprava kontaktných údajov občanom na public portály JISCD.

4.2Aplikačná vrstva

Predpokladáme v tejto zmenovej požiadavke zmeny v aplikačnej architektúre, ktoré budú mať rozširujúci charakter bez výraznej zmeny existujúcej architektúry. Budeme upravovať formulár na aktualizáciu kontaktných údajov na public portáli JISCD.

Obrázok 5. Architektúra riešenia zmenovej požiadavky.

4.2.1Zmeny na OSB

Predpokladáme rozšírenie internej vstupnej brány (BE) na komponente OSB o novú webovú službu na príjem dát z EVO. Zároveň rozšírime existujúcu službu na OSB ktorá poskytuje rozhranie na aktualizáciu kontaktných údajov volaním z public portálu JISCD.

4.2.2Zmeny v notifikačnom komponente

Predpokladáme realizáciu úpravy najmä v notifikačnom komponente, kde bude potrebná aktualizácia dátového modelu a funkcionality.

V rámci aplikačných zmien je potrebné zaručiť odosielanie správ a ich evidenciu v čase pomocou audit logov. Je dôležité aby sme vždy vedeli dohľadať aké zmeny predchádzali aktuálnemu stavu dát a teda aj naplánovaných notifikačných správ. Zároveň potrebujeme v tomto audit logu vedieť pôvod zdroja dát (či ide o zmenu zo strany občana cez public portál JISCD alebo o aktualizáciu z EVO). Súčasťou tohto audit logu bude aj informácia o odosielaní notifikačných správ.

Ďalšími zmenami v notifikačnom komponente bude realizácia integrácie na SVM. Predpokladáme, že táto integrácia iba rozšíri aktuálne zasielanie na e-mailové adresy a SMS. Pre jedno vozidlo bude však existovať len jedna PUSH notifikácia naplánovaná vstupom z EVO. Nie je súčasťou zmenovej požiadavky možnosť zmeny plánovanej PUSH notifikácie cez public portál JISCD. Občan, ktorý je držiteľom vozidla (iba ako fyzická osoba) bude mať automaticky plánovanú PUSH notifikáciu.

Zároveň požadujeme zmeniť plánované notifikácie pre e-mailové adresy a SMS takým spôsobom, aby ich bolo možné zaslať na viacero kontaktných údajov. Napríklad tak, že dostaneme aktualizáciu kontaktných údajov z EVO, na ktoré naplánujeme notifikačné správy a tieto údaje občan uvidí na public portáli JISCD. K týmto už naplánovaným notifikačným správam pridá ďalšie kontaktné údaje a aj pre tieto sa naplánuje notifikácia. Môže mať teda aj 3 e-maily a 2 telefóne čísla. Zároveň ale platí, že občan môže mať nastavené kontaktné údaje globálne a teda musí ísť o prienik medzi údajmi pre konkrétne vozidlo a globálne nastavenie ak sa plánujú notifikácie pre jedno vozidlo.

Všetky plánované notifikácie musia byť odvolané okamžite, keď notifikačný komponent zistí, že došlo ku zmene držiteľa vozidla a následne teda podľa vyššie popísaných pravidiel naplánovať notifikačné správy pre nového držiteľa vozidla.

Pri zmenách kde sa nemení držiteľ vozidla a dochádza z pohľadu aplikácie len ku zmene v kontaktných údajoch, tak pri business aktivite „výmaz údajov“ tento kontaktný údaj nebudeme reálne vymazávať. Iba ho označíme stavom „neplatné“ a nebudeme ho zobrazovať občanovi vo formulári. Dôvodom je, že ak občan vymazal tento kontaktný údaj cez formulár public portálu JISCD, tak pri prípadnej aktualizácii toho istého kontaktného údaju automatizovaným spôsobom z EVO cez webovú službu JISCD, nesmie prísť k jeho znovu naplánovaniu.

4.2.3SVM integrácia

Notifikačný komponent bude obsahovať integráciu na MIRRI/NASES webovú službu ktorou bude vyvolávať PUSH notifikácie cez SVM v mobilnom zariadení občana.

Predpokladáme realizáciu integračného zámeru, ktorú detailnejšie definujeme v realizačnej fáze v DNR.

Pre realizáciu tejto zmeny je nevyhnutný predpoklad, že MD SR zabezpečí súčinnosť s poskytovateľom služieb SVM na ktoré sa bude JISCD integrovať v rozsahu komunikačného a technologického partnera pre integráciu, technickej a biznis špecifikácie.

4.2.4Nová SMS brána

Aktuálne existuje v JISCD implementácia na zasielanie správ formou SMS. Toto riešenie chceme prepoužiť a vytvoriť novú dodatočnú integráciu na nového poskytovateľa odosielania SMS správ. Toto nové riešenie bude existovať spolu už s existujúcim, a teda pôvodné riešenie musí ostať zachované aj naďalej.

Je treba realizovať takú aplikačnú zmenu pri ktorej vznikne konfiguračný parameter v systéme, ktorým môžeme medzi týmito dvoma riešeniami na zasielanie SMS správ prepínať. A toto prepnutie by malo byť takého charakteru aby nemalo dopad na prevádzku a teda samotné prepnutie nevyžaduje výpadok alebo reštart systému.

Pre realizáciu tejto zmeny je nevyhnutný predpoklad, že MD SR zabezpečí súčinnosť s poskytovateľom SMS služieb na ktorého sa bude JISCD integrovať v rozsahu komunikačného a technologického partnera pre integráciu, technickej a biznis špecifikácie.

4.3Dátova vrstva

Predpokladáme zmeny v dátovej vrstve, a to pridaním nového typu notifikácie formu PUSH. Zároveň zmena modelu v notifikačnom komponente takým spôsobom aby bolo možné naplánovať viacero notifikačných správ pre viacero kontaktných údajov, ale maximálne len jednu notifikačnú správu pre typ PUSH.

Predpokladáme vznik audit logu pre zmeny, ktoré sa udejú v súvislosti s plánovanými notifikáciami tak aby bolo možné dohľadať a potvrdiť akúkoľvek prípadnú reklamáciu alebo podnet týkajúci sa notifikačných správ. Najmä teda pridanie kontaktného údaju a jeho naplánovanie, zmena a preplánovanie, výmaz a jeho zrušenie plánovanej notifikácie a samotné zasielanie notifikácií.

4.4Technologická vrstva

Toto zmenové konanie nemá dopad na technologickú vrstvu a nevyžaduje žiadnu zmenu na tejto vrstve.

4.5Bezpečnostná architektúra

Zmenové konanie bude mať dopad na bezpečnosť vzhľadom na vytvorenie novej webovej služby na strane JISCD pre integráciu s EVO. Predpokladáme definovanie spôsobu autentifikácie a autorizácie z integračného zámeru a detailnejšiu špecifikáciu v DNR.

Zároveň vznikne potreba vytvorenia sieťových prestupov, a to smerom na JISCD z EVO a súčasne aj z JISCD smerom na služby SVM. Tieto sieťové prestupy budú iba v rámci GOVNET.

4.6Legislatíva

Vyžaduje sa zmena legislatívy tak aby MV SR malo právny podklad pre oprávnené zdieľanie kontaktných údajov spolu s MD SR na držiteľov a vlastníkov vozidiel.

Zmena sa týka najmä Zákona č. 8/2009 Z.z. konkrétne § 111 ods. 3 pism. E).

5.ZÁVISLOSTI NA OSTATNÉ ISVS / PROJEKTY

Predpokladáme nasledovné závislosti na ostatných ISVS:

• Z EVO na JISCD
  • webová služba na JISCD pre zápis, výmaz a aktualizáciu kontaktných údajov vlastníka/držiteľa vozidla, ktorú bude volať EVO

• Z JISCD na SVM API
  • posielanie PUSH notifikačných správ ktoré bude zasielať JISCD na SVM pomocou webovej služby, ktorú nám poskytne MIRRI/NASES

6.PREVÁDZKA A ÚDRŽBA

6.1Prevádzkové požiadavky

Zmenové konanie nemá dopad na už existujúce prevádzkové požiadavky.

6.2Požadovaná dostupnosť IS:

Zmenové konanie nemá dopad na už existujúce požiadavky dostupnosti a parametre RTO a RPO.

7.VÝSTUPY PROJEKTU

Podľa platnej zmluvy sú výstupy projektu nasledovné

• DNR (podľa zmluvy so zadávateľom Funkčná špecifikácia)
  • Plán Testovania
  • Zoznam Testovacích prípadov
  • Testovacie prípady UAT
• Akceptačný protokol úspešného integračného testovania adaptéra pre príjem, úpravu a výmaz kontaktných údajov. ( Vid plán Testovania).
• Akceptačný protokol úspešného integračného testovania pre adaptér na zaslanie PUSH notifikácie na mobilný telefón občana v JISCD ( Vid plán Testovania)
• Akceptačný protokol úspešného integračného testovania pre adaptéra na integráciu na novú SMS bránu v JISCD, ( Vid plán Testovania).
• Sumárny protokol akceptačných testov vrátane prehľadu akceptačných výhrad a Prezenčných listín z testovania
• Release notes
• Upravené časti aplikácie JISCD nasadené na produkčné prostredie.

8.HARMONOGRAM

Predpokladáme realizáciu zmenového konania ako celku so všetkými produktami a funkčnými požiadavkami. To znamená, že bude dodaný jeden veľký aplikačný balík do produkčného prostredia. Detailnejší harmonogram implementácie bude upresnený na základe DNR a potvrdení termínov tretích strán na ktoré má dopad toto zmenové konanie.

Účinnosť Zmenového konania: Po schválení Zmenového konania na základe vystavenej a doručenej objednávky.

8.1Časové závislosti

• Realizačná fáza projektu začína doručením objednávky dodávateľovi
• V prvých krokoch realizačnej fázy vznikne Detailný návrh riešenia s popisom všetkých zmien a návrhom riešenia pre jednotlivé produkty.
• Produkty v ďalšej fáze je možné začať implementovať až keď je Detailný návrh riešenia schválený objednávateľom.
• Integračné produkty sú závislé od termínov dohodnutých k Integračnom zámere. Prípadné posuny mimo rámca tohto Projektového Prístupu majú za následok posun konečných termínov
• Integračné produkty sú závislé na dodaní súčinnosti pre integráciu od externého dodávateľa služieb
• Produkt 4 – úprava public portálu JISCD a notifikačného komponentu ja závislá od ukončenia prác pre všetky ostatné produkty 1 až 3
• V rámci testovania sa vykoná a dodá objednávateľovi v konkrétnych častiach realizácie:
  • na začiatku realizačnej fázy Plán testovania
  • počas realizácie na základe upresnení vývoja Zoznam testovacích prípadov
  • po internom testovaní (FAT) Testovacie prípady UAT
• Najskorší možný termín nasadenia na produkčné prostredie je po úspešnom UAT všetkých produktov.

9.ROZPOČET A PRÍNOSY

Rozpočet pre implementáciu požadovanej zmeny je definovaný na základe platných sadzieb zmluvy a stanovených náročností realizácie. Rozpočet je zahrnutý v prílohe č. 1

9.1Rozpočet

Rozpočet pre implementáciu požadovanej zmeny je definovaný na základe platných sadzieb zmluvy a stanovených náročností realizácie. Zahrnutý je v prílohe č. 1

9.2Prínosy

Prínos je v najmä pre občana v jeho životnej situácií  kúpa/predaj vozidla. Predpokladáme zlepšenie informovanosti občana o stave platnosti TK/EK pre jeho vozidlo a tým zníženie rizika prevádzky nespôsobilého vozidla v cestnej premávke. Tým sa zníži riziko občana pre jeho pokutovanie zo strany štátu pre nesplnenie si povinnosti.

10.PRÍLOHY

Príloha 1: Rozpočet a fakturácia

Príloha 2: Register rizík a závislostí - Životná situácia kúpa vozidla