1. Návrh autorizácie funkciou prístupového miesta (autorizácia klikom). – Prezentuje Anton Svetlošák, SKIT doplní primárne dopady (napr. tokeny) a GAP medzi dodávkou mUPVS,
2. Kompetenčné centrá NASES – Ideový zámer – aktualizovaná prezentácia, prezentuje NASES.
   1. Projektová idea – schvaľovanie.
3. MVP SVK 3.0 – 3 nedoriešené body (schránka, prepínanie FO/PO, zrýchlenie aktivácie schránky) čo sa mali dokončiť, prístup k schránke natívne, alebo cez webview
4. SVM prostredia – aktuálna dokumentácia: Je z predloženej dokumentácie jasné, aký je súčasný a budúci stav SVM?  Je z dokumentácia jasné aký je aktuálny stav prevádzkového prostredia SVM v NASES? Je z požadovanej informácie zrejmé, aké sú závislosti medzi projektami SVM, CAMP, mUPVS a jednotlivých prevádzkových prostredí? Su jasne identifikovane rozdiely medzi súčasným (prevádzkovým) stavom a budúcim stavom? Je zrejmý postup pri prechode do cieľového stavu SvM so zohľadnením závislosti v jednotlivých prostrediach? – Prezentuje Anton Svetlošák, doplní SKIT
5. OOTS preferencia, či to má pokryť CIP ako nové/upravené moduly, alebo samostatný projekt

1. Návrh autorizácie funkciou prístupového miesta (autorizácia klikom).
2. NASES – kompetenčné centrá NASES pre elektronickú komunikáciu štátu
3. MVP SVK 3.0 – 3 nedoriešené body
4. SVM prostredia – aktuálna dokumentácia
5. OOTS

Záver: Vzhľadom na neprítomnosť zástupcov SKIT, tento bod agendy bol odložený na budúce stretnutie.

Bod 2 agendy: Kompetenčné centrá NASES – Ideový zámer – aktualizovaná prezentácia, prezentuje NASES. – po žiadosti NASES sme odstránili z programu. Prezentácia ideového zámeru bude na budúcom stretnutí.

• Projektová idea – schvaľovanie.

Záver: Projektová idea – Všetci prítomní členovia komisie schválili návrh – 4/5

Bod 3 agendy: MVP SVK 3.0 – 3 nedoriešené body (schránka, prepínanie FO/PO, zrýchlenie aktivácie schránky) čo sa mali dokončiť, prístup k schránke natívne, alebo cez webview

• • Webview funkcionalita je obmedzená, odporúča sa menšie dátové toky – tam kde netreba používať lokálne úložisko na mobile. Webview sa nemá používať ak v rámci webu sú všetky zdroje – javascript v moci vlastníka. Update sa robí len na 1 mieste.
  • Natívna aplikácia sa odporúča – lokálne úložisko dát, odosielanie súborov, ktoré sú z mobilu dostupné. Samotná aplikácia nemá dosah na vzhľad, je to na vývojárovi aplikácie. Zdrojový kód – natívna aplikácia. Zložitejšia kontrola nad vývojom.
  • Aká je pridaná hodnota eDesk v mobile keď už existuje funkcionalita preposielania na email na UPVS už teraz dostupná? Funkcionalita preposielania je len v starej verzií. Používatelia sa dopytujú, kedy bude schránka v SVM dostupná.
  • Off-line režim: pre produkt nie je podstatná.
  • EKR rozhrania: Natívna verzia čiastočne odbremení množstvo volaní. V rámci mUPVS sa bude využívať súčasne EKR rozhrania. Je potrebné zo strany SKIT do-špecifikovať či sa zníži počet volaní.
  • Vo verzií v MPV produkťáci akceptujú problém s doručenkami.

Pre MVP: webview je dočasné riešenie, menej rizikové z pohľadu pridávania funkčnosti aj vzhľadom na komplikované nasadzovanie v NASES.

Finálna verzia: budú sa aj odosielať dáta – z toho dôvodu je lepšie používať natívnu aplikáciu. Väčšia bezpečnosť. Offline prístup. Napojiť ale už na nový eDesk.

Úloha: definovať checklist čo všetko by mal SKIT doplniť – aké informácie, kritéria aby sme to vedeli dôsledne porovnať. SKIT tento checklist následne vyplní.

Zatiaľ pracujeme s predpokladom, že sa to v oboch prípadoch stihne a že v prípade problémov je možné tento bod zo scope odstrániť.

Aktivácia schránky. Potvrdené, že sa to stíha do marca. Ostatné dokumenty (potrebné zadania) boli dopracované.

Záver: Všetci prítomní členovia komisie schválili návrh scope MVP – 4/5

Bod 4 agendy: SVM prostredia – aktuálna dokumentácia

Záver: Vzhľadom na neprítomnosť zástupcov SKIT, tento bod agendy bol odložený na budúce stretnutie.

Bod 5 agendy: OOTS preferencia, či to má pokryť CIP ako nové/upravené moduly, alebo samostatný projekt

• CIP má prihlasovanie na mUPVS CIP má webview – dalo by sa to použiť ako podklad k preview space. Aj logovanie a monitorovanie – toto by bolo treba popísať vo OPZ (využiť z CIP, alebo vlastný). Zohľadniť, že komponenty pre zachytávanie a vyhodnocovanie logov, monitoring poskytne prevádzkovateľ (napr. NASES). V rámci CAMP sa buduje jadro monitorovacieho a logovacieho systému, ktoré je preferované riešenie ako centrálny systém.
• Je možné využiť aj iné existujúce systémy a moduly – MetaIS, CSRU, Formuláre atď.
• Z pohľadu obstarávania by to malo ako samostatný systém
• Mala by existovať možnosť pre-použitia už existujúcich funkcionalitách, aj keď to môže poskytnúť výhodu existujúcim dodávateľom
• V oboch prípadoch by to mal byť samostatný, nezávislý systém s API, ktorý sa ale bude môcť integrovať na existujúce systémy a moduly.

Záver: Všetci prítomní členovia komisie súhlasia s OOTS riešením ako samostatným systémom

– 4/5

Kľúčové úlohy a rozhodnutia vyplývajúce zo zasadnutia:

Rozhodnu-tie (R)

Informácia (I)