prosím doplniť akými dvoma evidenciami bude systém disponovať
helena_bystrianova, 2023/04/12 15:01
prosím doplniť číslo modulu a zaevidovať do META IS
pavol_suja, 2023/05/23 07:39
Uvedené moduly, tak ako sú namodelované v aplikačnej architektúre na úrovni backendov nereprezentujú samostatné funkčné aplikačné moduly, ide o interné moduly jednej a tej iste aplikácie. Moduly Systém 1 - 3 sú samostatné IS, členenie na moduly je logické pre konkrétne implementácie API.
vladimir_kovac, 2023/06/14 19:43
Akceptované vysvetlenie
helena_bystrianova, 2023/04/12 15:05
prosím do modelu zakresliť vazby, prepojenia,
vladimir_kovac, 2023/04/13 16:05
Biznis schému treba zladiť s aplikačnou a poskytovanými službami. Väzby zakresliť len vtedy, keď treba niektorú významnú zvýrazniť. Funkčný blok "Aktualizovanie údajov" je aj názvom taký všeobecný, že je v schéme zbytočný, ak nereprezentuje nejakú kľúčovú funkčnosť rozdielnu od ostatných funkčných blokov pre hlavné uvedené evidencie (osôb, splnomocnení, použití...). Pod zasielaním notifikácií sa myslí zasielaníe správ o použití splnomocnenia do schránky správ v eDesk? Bolo by treba upresniť a radšej dať k schéme popis komponentov namiesto výpočtu funkcií v odrážkach.
pavol_suja, 2023/05/09 09:07
Upravené
vladimir_kovac, 2023/04/13 16:09
Čo sa myslí pod lokálnou inštanciou? Lokálna inštancia registra pre OVM ako tenanta? Lokálna inštancia v akej infrašruktúre? A pod vlastným interným frontendom? Neplánuje sa pre tento register web rozhranie ale nejaké inštalované frontendové aplikácie?
pavol_suja, 2023/05/09 09:07
Upravené. Doplnené.
vladimir_kovac, 2023/06/14 17:13
Akceptované zapracovanie
vladimir_kovac, 2023/04/13 16:16
Treba lepšie popísať, čo sa myslí pod správou SaaS služieb a či naozaj ide o vytvorenie dátovo a funkčne oddelenej inštancie služby pre tenata (OVM) alebo ide len o vytvorenie prístupových práv pre správu používateľov príslušného OVM a konfigurácie parametrov vytvárania splnomocnení pre služby agend, ktoré sú v gescii OVM.
pavol_suja, 2023/05/09 09:08
Doplnené, upravené
vladimir_kovac, 2023/06/14 17:31
Akceptované vysvetlenie
vladimir_kovac, 2023/04/13 16:21
Pre evidenciu služieb a agend, pre ktoré si budú OVM spravovať parametre evidencie a poskytovania splnomocnení treba zabezpečiť väzbu na registráciu agendy a služby v METAIS, aby boli konfigurované služby v registri splnomocnení viazané na referenčný register služieb v METAIS (ÚPVS tiež bude mať mapovanie publikovaných služieb na METAIS).
pavol_suja, 2023/05/23 07:46
Doplnené do doménového modelu.
vladimir_kovac, 2023/06/14 19:53
Akceptované zapracovanie
vladimir_kovac, 2023/04/13 16:23
Kvôli formulárom bude pravdepodbne potrebná aj integrácia na modul MEF ÚPVS.
pavol_suja, 2023/05/09 09:34
Doplnené. Upravené.
vladimir_kovac, 2023/06/14 19:48
Akceptované zapracovanie
vladimir_kovac, 2023/04/13 16:28
Treba pridať integráciu Centrálnu API manažment platformu (isvs_9513), lebo pravdepodobne bude pre online služby s interakciou klienta (občana, podnikateľa) použitie plánovaného RestAPI rýchlejšie a jednoduchšie integrovateľné, ako získavanie splnomocnenia cez konsolidačné rozhranie poskytovania dát cez CSRÚ. Pre backend scenáre v OVM môže vyhovovať viac integrácia na CSRÚ (hlavne ak ju už OVM má urobenú).
pavol_suja, 2023/05/09 09:45
Doplnené
vladimir_kovac, 2023/06/14 19:54
Akceprované zapracovanie
vladimir_kovac, 2023/04/13 16:33
Treba používať aj kódy z METAIS - IS CSRÚ = isvs_5836. Integráciu na IS CSRÚ treba popísať a evidovať v METAIS podľa príručky k METAIS.
pavol_suja, 2023/05/09 10:39
Doplnené.
vladimir_kovac, 2023/04/13 16:38
K službám treba evidovať aj ich kód METAIS. Tiež nepovoliť registráciu služby, ktorá nebude referencovaná na evidenciu v METAIS.
pavol_suja, 2023/05/23 07:53
Doplnené, aktualizovaný doménový model.
vladimir_kovac, 2023/06/14 19:56
Akcptované zapracovanie
vladimir_kovac, 2023/04/13 16:44
Pridať aj METAIS (isvs_63) a CAMP (isvs_9513)
pavol_suja, 2023/05/09 09:09
Doplnené
vladimir_kovac, 2023/06/14 17:30
Akceptované zapracovanie
vladimir_kovac, 2023/04/13 16:49
Treba zladiť s biznis architektúrou (funkčné bloky a koncové a aplikačné služby). Určite bude obsahovať správu inštancií alebo to bude len správa prístupov OVM nad spoločným databázovým priestorom?
pavol_suja, 2023/05/09 09:09
Upravené. Doplnené.
vladimir_kovac, 2023/06/14 20:21
Akceptované zapracovanie
vladimir_kovac, 2023/04/13 16:54
Čo bude vlastná klientska inštancia OVM. Bolo by to treba lepšie popísať a zakresliť do aplikačnej a technologickej infraštruktúry, aby bolo jasnejšie ako je plánované túto aplikačnú časť realizovať a čo bude znamenať pre jednotlivé OVM.
pavol_suja, 2023/05/23 07:36
Doplnené
vladimir_kovac, 2023/06/14 17:31
Akceptované zpracovanie.
vladimir_kovac, 2023/04/13 16:57
Podľa diskusie na kick-off MVSR a MIRRI 12.4.2023 by sa malo uvažovať aj s koncovou službou asitovaného vytvorenia splnomocnenia na fyzickom kontakton mieste (matrike, u notára, a...). Treba pridať, ak používateľský prieskum neukáže, že o takú službu nie je dostatočný záujem.
pavol_suja, 2023/05/09 09:07
Doplnené
vladimir_kovac, 2023/06/14 17:12
Akceptované zapracovanie
vladimir_kovac, 2023/04/14 13:28
OK. Jeden z hlavných bodov a prínosov projektu.
pavol_suja, 2023/05/09 10:44
OK
vladimir_kovac, 2023/04/14 13:37
Objekty predpokladám budú len triedy objektov (napr. vozido, nehnuteľnosť, osoba atď.), nie konkrétne objekty. Treba pre istotu upresniť, aby sa cez objekt súhlasu nezverejnili údaje, ktoré už by mohli byť považované za osobné. Okrem objektu by bolo zaujímavé reportovať aj službu ku ktorej sa splnomocnenia evidovali a použili a tie už sa dajú referencovať aj cez URI, takže otvorené údaje by už mohli byť aj kvality úrovne 5 a rovnako by asi mohli byť cez URI referencované aj typy objektov splnomocnení, ktoré tiež môžu mať URI na definícu príslušného dátového prvku v METAIS.
pavol_suja, 2023/05/23 07:54
Doplnené. Upravené.
Budú sa poskytovať len typy objektov, nie konkrétne identifikátory. Nový typ si vie zadefinovať aj OVM. Typom sa myslí napr. osoba, vozidlo, adresa …. Služby sú tam už uvedené.
vladimir_kovac, 2023/06/14 19:57
Akceptované zapracovanie
vladimir_kovac, 2023/04/14 13:45
Neviem odhadnúť pre aký analytický účel by tieto údaje boli zaujímavé pre analytické jednotky , ale pre analytické sracovanie by mohol byť záujem dostať dáta pseudonymizované, najlepšie funkciou iS CSRÚ, aby boli pseudonymizované jednotne a dali sa cez pseudonymizované hodnoty robiť presnejšie analýzy.
pavol_suja, 2023/05/09 10:46
Upravené
vladimir_kovac, 2023/06/14 19:59
Akceptované zapracovanie
vladimir_kovac, 2023/04/14 13:56
Riešenie treba pripravovať ako multi jazyčné, minimálne časť pre frontend, aby sa pomocou doplnenia konfiguračných dát pre doplnkový jazyk dala urobiť jazyková mutácia klientskeho rozhrania pre občanov minimálne pre 1 ďalší jazyk (EN). Napr. pre prípad cudzincov identifikovaných cez eIDAS dávajúcich splnomocnenie pre lokálneho zástupcu pre riešenie niektorých ich záležitostí na Slovensku.
pavol_suja, 2023/05/09 10:49
Upravené.
vladimir_kovac, 2023/06/14 19:59
Akceptované zapracovanie
vladimir_kovac, 2023/04/14 14:09
Formou tradičného zálohovania je problematické zabezpečiť nulovú stratu dát. Aj pre opis predmetu zákazky pre VO treba určiť RPO, aby s tým vedel dodávateľ v ponuke počítať a podľa toho mohol urobiť adekvátny odhad náročnosti implementácie.
pavol_suja, 2023/05/09 10:52
Doplnené. Upravené.
vladimir_kovac, 2023/06/14 20:01
Akceptované zapracovanie
vladimir_kovac, 2023/04/14 14:10
Aj pre opis predmetu zákazky pre VO treba určiť RPO, aby s tým vedel dodávateľ v ponuke počítať a podľa toho mohol urobiť adekvátny odhad náročnosti implementácie. O to viac, keď bude musieť zohľadniť možnosti poskytované službami privátneho vládneho cloudu.
pavol_kopacka, 2023/04/16 14:57
hodnoty RTO a RPO sú požadované parametre, ktoré určuje vlastník systému na základe reálnych potrieb a nie problémy, ktorý budú nejakou formou (zálohovaním) v budúcnosti riešené. Nulová strata údajov by znamenala RPO=0. Prosím písať logické texty, nie "RPO bude riešené formou tradičného zálohovania a obnovy!
Uvedený obrázok je potrebné doplniť o vzťahy a prepojenia, a tiež je vodné doplniť označenie dôležitých (najmä nových) objektov podľa definovaných Kódov v MetaIS. Napríklad IS CREP- (isvs_11435)
pavol_kopacka, 2023/04/16 14:24
Je priama integrácia na RFO a RPO v súlade s referenčnou architektúrou? V obrázku (Obrázok č.3 Model aplikačnej architektúry) sú uvedené iné externé ISVS ako sumárne v tabuľkách tejto kapitoly.
pavol_kopacka, 2023/04/16 14:27
Referenčné údaje od čísla 6 nebudú k ničomu priradené?
pavol_suja, 2023/05/09 09:51
Doplnené. Opravené.
pavol_kopacka, 2023/04/16 14:29
Prosím doplniť vzťahy medzi objektmi.
pavol_suja, 2023/05/09 10:46
Doplnené
pavol_kopacka, 2023/04/16 14:32
Bezpečnosť vládneho cloudu a bezpečnosť aplikácie sú dve rôzne veci. Bezpečnosť cloudu nezabezpečí bezpečnosť aplikácie. V tejto kapitole sa očakáva popis konkrétnej použitej bezpečnostnej architektúry
pavol_suja, 2023/05/09 10:50
Upravené.
pavol_kopacka, 2023/04/16 14:35
Bude navrhnutá znamená, že ešte nie je k dispozícií žiaden návrh, ani žiadne konkrétne požiadavky na dostupnosť, dôvernosť a integritu , ale len všeobecné požiadavky súladu so všetkými legislatívnymi predpismi SR?
pavol_suja, 2023/05/09 10:50
Upravené.
pavol_kopacka, 2023/04/16 14:44
Ak bude produkčné prostredie v privátnej časti VC a vývojové u dodávateľa riešenia, ako bude riešená bezpečnostná architektúra a bezpečná komunikácia?
pavol_kopacka, 2023/04/16 14:47
Prevádzka prostredia pre vývoj nie je odporúčaná ani žiadúca pre privátnu časť VC.
pavol_suja, 2023/05/09 10:48
Zmenené. Vývojové prostredie bude u dodávateľa.
vladimir_kovac, 2023/06/14 19:46
Prosím doevidovať vzťah isvs_11435 (IS CREP) využívania služieb EKR MVSR (isvs_10980) na integráciu s ÚPVS.
vladimir_kovac, 2023/06/14 19:54
Prosím doevidovať v METAIS vzťah indikujúci integráciu IS CREP na CAMP podľa príručky METAIS (vytvorenie aplik. služby isvs_11435 napr. "Poskytovanie služieb prostredníctvom API GW" a následne vytvoriť vzťah "AS slúži AS" na aplikačnú službu as_60157_ “Konzumovanie služieb z API GW"). Bude potrebné doplniť aj do textu projektového prístupu túto integračnú službu (aj keď pravdepodobne bude skutočná integrácia robená cez nezaevidovanú integračnú platformu MVSR). Potrebné doplniť integračnú službu do tabuľky Tabuľka č.4 Prehľad budovaných aplikačných služieb.
vladimir_kovac, 2023/06/14 19:55
Prosím doevidovať vzťah isvs_11435 (IS CREP) využívania služieb EKR MVSR (isvs_10980) na integráciu s ÚPVS.
vladimir_kovac, 2023/06/14 20:10
Externý frontend pre koncových používateľov by mal byť podľa jednotného dizajnu pre webové sídla verejnej správy id-sk https://idsk.gov.sk/
vladimir_kovac, 2023/06/14 20:17
Prosím zapracovanie zmien v prístupe k projektu na základe pripomienok MIRRI aj do katalógu požiadaviek v dokumente BC_CBA..xlsx (napr. poskytovanie služeib aj asistovaným spôsobom, podpora jazykovej mutácie, ID-SK atď.)
prosím doplniť akými dvoma evidenciami bude systém disponovať
prosím doplniť číslo modulu a zaevidovať do META IS
Uvedené moduly, tak ako sú namodelované v aplikačnej architektúre na úrovni backendov nereprezentujú samostatné funkčné aplikačné moduly, ide o interné moduly jednej a tej iste aplikácie. Moduly Systém 1 - 3 sú samostatné IS, členenie na moduly je logické pre konkrétne implementácie API.
Akceptované vysvetlenie
prosím do modelu zakresliť vazby, prepojenia,
Biznis schému treba zladiť s aplikačnou a poskytovanými službami. Väzby zakresliť len vtedy, keď treba niektorú významnú zvýrazniť. Funkčný blok "Aktualizovanie údajov" je aj názvom taký všeobecný, že je v schéme zbytočný, ak nereprezentuje nejakú kľúčovú funkčnosť rozdielnu od ostatných funkčných blokov pre hlavné uvedené evidencie (osôb, splnomocnení, použití...). Pod zasielaním notifikácií sa myslí zasielaníe správ o použití splnomocnenia do schránky správ v eDesk? Bolo by treba upresniť a radšej dať k schéme popis komponentov namiesto výpočtu funkcií v odrážkach.
Upravené
Čo sa myslí pod lokálnou inštanciou? Lokálna inštancia registra pre OVM ako tenanta? Lokálna inštancia v akej infrašruktúre? A pod vlastným interným frontendom? Neplánuje sa pre tento register web rozhranie ale nejaké inštalované frontendové aplikácie?
Upravené. Doplnené.
Akceptované zapracovanie
Treba lepšie popísať, čo sa myslí pod správou SaaS služieb a či naozaj ide o vytvorenie dátovo a funkčne oddelenej inštancie služby pre tenata (OVM) alebo ide len o vytvorenie prístupových práv pre správu používateľov príslušného OVM a konfigurácie parametrov vytvárania splnomocnení pre služby agend, ktoré sú v gescii OVM.
Doplnené, upravené
Akceptované vysvetlenie
Pre evidenciu služieb a agend, pre ktoré si budú OVM spravovať parametre evidencie a poskytovania splnomocnení treba zabezpečiť väzbu na registráciu agendy a služby v METAIS, aby boli konfigurované služby v registri splnomocnení viazané na referenčný register služieb v METAIS (ÚPVS tiež bude mať mapovanie publikovaných služieb na METAIS).
Doplnené do doménového modelu.
Akceptované zapracovanie
Kvôli formulárom bude pravdepodbne potrebná aj integrácia na modul MEF ÚPVS.
Doplnené. Upravené.
Akceptované zapracovanie
Treba pridať integráciu Centrálnu API manažment platformu (isvs_9513), lebo pravdepodobne bude pre online služby s interakciou klienta (občana, podnikateľa) použitie plánovaného RestAPI rýchlejšie a jednoduchšie integrovateľné, ako získavanie splnomocnenia cez konsolidačné rozhranie poskytovania dát cez CSRÚ. Pre backend scenáre v OVM môže vyhovovať viac integrácia na CSRÚ (hlavne ak ju už OVM má urobenú).
Doplnené
Akceprované zapracovanie
Treba používať aj kódy z METAIS - IS CSRÚ = isvs_5836. Integráciu na IS CSRÚ treba popísať a evidovať v METAIS podľa príručky k METAIS.
Doplnené.
K službám treba evidovať aj ich kód METAIS. Tiež nepovoliť registráciu služby, ktorá nebude referencovaná na evidenciu v METAIS.
Doplnené, aktualizovaný doménový model.
Akcptované zapracovanie
Pridať aj METAIS (isvs_63) a CAMP (isvs_9513)
Doplnené
Akceptované zapracovanie
Treba zladiť s biznis architektúrou (funkčné bloky a koncové a aplikačné služby). Určite bude obsahovať správu inštancií alebo to bude len správa prístupov OVM nad spoločným databázovým priestorom?
Upravené. Doplnené.
Akceptované zapracovanie
Čo bude vlastná klientska inštancia OVM. Bolo by to treba lepšie popísať a zakresliť do aplikačnej a technologickej infraštruktúry, aby bolo jasnejšie ako je plánované túto aplikačnú časť realizovať a čo bude znamenať pre jednotlivé OVM.
Doplnené
Akceptované zpracovanie.
Podľa diskusie na kick-off MVSR a MIRRI 12.4.2023 by sa malo uvažovať aj s koncovou službou asitovaného vytvorenia splnomocnenia na fyzickom kontakton mieste (matrike, u notára, a...). Treba pridať, ak používateľský prieskum neukáže, že o takú službu nie je dostatočný záujem.
Doplnené
Akceptované zapracovanie
OK. Jeden z hlavných bodov a prínosov projektu.
OK
Objekty predpokladám budú len triedy objektov (napr. vozido, nehnuteľnosť, osoba atď.), nie konkrétne objekty. Treba pre istotu upresniť, aby sa cez objekt súhlasu nezverejnili údaje, ktoré už by mohli byť považované za osobné. Okrem objektu by bolo zaujímavé reportovať aj službu ku ktorej sa splnomocnenia evidovali a použili a tie už sa dajú referencovať aj cez URI, takže otvorené údaje by už mohli byť aj kvality úrovne 5 a rovnako by asi mohli byť cez URI referencované aj typy objektov splnomocnení, ktoré tiež môžu mať URI na definícu príslušného dátového prvku v METAIS.
Doplnené. Upravené.
Budú sa poskytovať len typy objektov, nie konkrétne identifikátory. Nový typ si vie zadefinovať aj OVM. Typom sa myslí napr. osoba, vozidlo, adresa …. Služby sú tam už uvedené.
Akceptované zapracovanie
Neviem odhadnúť pre aký analytický účel by tieto údaje boli zaujímavé pre analytické jednotky , ale pre analytické sracovanie by mohol byť záujem dostať dáta pseudonymizované, najlepšie funkciou iS CSRÚ, aby boli pseudonymizované jednotne a dali sa cez pseudonymizované hodnoty robiť presnejšie analýzy.
Upravené
Akceptované zapracovanie
Riešenie treba pripravovať ako multi jazyčné, minimálne časť pre frontend, aby sa pomocou doplnenia konfiguračných dát pre doplnkový jazyk dala urobiť jazyková mutácia klientskeho rozhrania pre občanov minimálne pre 1 ďalší jazyk (EN). Napr. pre prípad cudzincov identifikovaných cez eIDAS dávajúcich splnomocnenie pre lokálneho zástupcu pre riešenie niektorých ich záležitostí na Slovensku.
Upravené.
Akceptované zapracovanie
Formou tradičného zálohovania je problematické zabezpečiť nulovú stratu dát. Aj pre opis predmetu zákazky pre VO treba určiť RPO, aby s tým vedel dodávateľ v ponuke počítať a podľa toho mohol urobiť adekvátny odhad náročnosti implementácie.
Doplnené. Upravené.
Akceptované zapracovanie
Aj pre opis predmetu zákazky pre VO treba určiť RPO, aby s tým vedel dodávateľ v ponuke počítať a podľa toho mohol urobiť adekvátny odhad náročnosti implementácie. O to viac, keď bude musieť zohľadniť možnosti poskytované službami privátneho vládneho cloudu.
hodnoty RTO a RPO sú požadované parametre, ktoré určuje vlastník systému na základe reálnych potrieb a nie problémy, ktorý budú nejakou formou (zálohovaním) v budúcnosti riešené. Nulová strata údajov by znamenala RPO=0. Prosím písať logické texty, nie "RPO bude riešené formou tradičného zálohovania a obnovy!
Doplnené. Upravené.
Akceptované zapracovanie
pri tvorbe a kreslení náhľadu architektúry treba dodržiavať metodiku (https://metais.vicepremier.gov.sk/confluence/download/attachments/2621442/PouzPrirucka_MetaIS_v23.pdf?version=4&modificationDate=1666248414247&api=v2)
Uvedený obrázok je potrebné doplniť o vzťahy a prepojenia, a tiež je vodné doplniť označenie dôležitých (najmä nových) objektov podľa definovaných Kódov v MetaIS. Napríklad IS CREP- (isvs_11435)
Je priama integrácia na RFO a RPO v súlade s referenčnou architektúrou? V obrázku (Obrázok č.3 Model aplikačnej architektúry) sú uvedené iné externé ISVS ako sumárne v tabuľkách tejto kapitoly.
Referenčné údaje od čísla 6 nebudú k ničomu priradené?
Doplnené. Opravené.
Prosím doplniť vzťahy medzi objektmi.
Doplnené
Bezpečnosť vládneho cloudu a bezpečnosť aplikácie sú dve rôzne veci. Bezpečnosť cloudu nezabezpečí bezpečnosť aplikácie. V tejto kapitole sa očakáva popis konkrétnej použitej bezpečnostnej architektúry
Upravené.
Bude navrhnutá znamená, že ešte nie je k dispozícií žiaden návrh, ani žiadne konkrétne požiadavky na dostupnosť, dôvernosť a integritu , ale len všeobecné požiadavky súladu so všetkými legislatívnymi predpismi SR?
Upravené.
Ak bude produkčné prostredie v privátnej časti VC a vývojové u dodávateľa riešenia, ako bude riešená bezpečnostná architektúra a bezpečná komunikácia?
Prevádzka prostredia pre vývoj nie je odporúčaná ani žiadúca pre privátnu časť VC.
Zmenené. Vývojové prostredie bude u dodávateľa.
Prosím doevidovať vzťah isvs_11435 (IS CREP) využívania služieb EKR MVSR (isvs_10980) na integráciu s ÚPVS.
Prosím doevidovať v METAIS vzťah indikujúci integráciu IS CREP na CAMP podľa príručky METAIS (vytvorenie aplik. služby isvs_11435 napr. "Poskytovanie služieb prostredníctvom API GW" a následne vytvoriť vzťah "AS slúži AS" na aplikačnú službu as_60157_ “Konzumovanie služieb z API GW"). Bude potrebné doplniť aj do textu projektového prístupu túto integračnú službu (aj keď pravdepodobne bude skutočná integrácia robená cez nezaevidovanú integračnú platformu MVSR). Potrebné doplniť integračnú službu do tabuľky Tabuľka č.4 Prehľad budovaných aplikačných služieb.
Prosím doevidovať vzťah isvs_11435 (IS CREP) využívania služieb EKR MVSR (isvs_10980) na integráciu s ÚPVS.
Externý frontend pre koncových používateľov by mal byť podľa jednotného dizajnu pre webové sídla verejnej správy id-sk https://idsk.gov.sk/
Prosím zapracovanie zmien v prístupe k projektu na základe pripomienok MIRRI aj do katalógu požiadaviek v dokumente BC_CBA..xlsx (napr. poskytovanie služeib aj asistovaným spôsobom, podpora jazykovej mutácie, ID-SK atď.)