V zásade to nie je koncová služba v pravom slova zmysle, lebo sa aktivuje automaticky pri konaní a KP vráti záväznú hodnotu, ktoru občan alebo podnikateľ zaplati. Ukazuje, že záväzné určenie poplatku nie je vlastná koncová služba katalógu ale občan/podnikateľ sa k záväznému určeniu poplatku dostanú prostredníctvom koncových služieb iných IS, ktoré budú na katalóg naintegrované.
vysvetlenie vyssie, nejedna sa o KS v pravom slova zmysele
Ukazuje, že záväzné určenie poplatku nie je vlastná koncová služba katalógu ale občan/podnikateľ sa k záväznému určeniu poplatku dostanú prostredníctvom koncových služieb iných IS, ktoré budú na katalóg naintegrované
Máte na mysli: Informačný systém pre platby a evidenciu správnych a súdnych poplatkov (IS PEP), isvs_5585? Ak áno, doplniť príslušné informácie do tabuľky.
Pokiaľ viem, tak motivácia nie je rozšíriť IS PEP o katalóg poplatkov ale dodať samostatný modul Katalógu poplatkov. Aj kvôli tomu, že evidencia platieb realizovaná systémom PEP prejde časom do Štátnej pokladnice. Aj kvôli vendor-lock pri IS PEP. Nakoniec aj nižšie v cieľoch je uvedené, že IS PEP sa má integrovať na nový Katalóg poplatkov a nie že IS PEP bude mať v sebe integrovaný katalóg poplatkov. A taktiež vo vyhodnotení alternatív riešenia nebola zvolená alternatíva rozširovania IS PEP.
Primárne by sa mali priraďovať poplatky ku Koncovým službám (KS) a podaniam. Vzťah k život. situáciám je odvodený od zaradenia KS ku položke život. situácie.
V návrhu technologickej vrstvy sa uvažuje o nasadení spolu s modulmi ÚPVS a teda na infraštruktúre NASES pre ÚPVS, takže tento predpoklad o dostupnosti kapacít vo vládnom cloude neodpovedá celkom návrhu riešenia. Buď to treba preformulovať na dostupnosť kapacít technologickej infraštruktúry privátneho cloudového riešenia v prevádzke NASES alebo treba prehodnotiť technologické riešenie.
Podľa týchto údajov je na interné práce úprav existujúcich systémov počítané zhruba 1 človekomesiac a pre katalóg poplatkov zhruba 8 človekomesiacov pri pesimistickej cene práce 5000€/osoba. Naozaj to bude tak málo? Nebudú do projektovej prípravy, pripomienkovania dokumentácie, testovania, prípravy technologickej infraštruktúry zapojení interní pracovníci NASES viac?
Takto to bolo odsúhlasené na strane NASES a MIRRI. Toto su dedikované náklady v rámci projektu rozvoja. Čo neznamená, že do toho nebudú zapojené ešte ďalšie kapacity, ktoré však nebudú financované z projektu
Nemalo by tu v prípade PEP byť tiež NIE alebo aspoň ČIASTOČNE? Určite má alebo by mohlo mať IS PEP správu všetkých poplatkov - aj pre neelektronické služby?
Pre vyhodnotenie varánt technologického riešenia je potrebné urobiť klasifikáciu systému podľa metodiky MIRRI ako to uvádza aj šablóna I-02 projektového zámeru (Klasifikáciu urobte podľa Metodického usmernenia pre klasifikáciu ISVS 023107/2023/oSBATA-1: https://mirri.gov.sk/sekcie/informatizacia/dokumenty/vladny-cloud/metodicke-usmernenia/)
Pre klasifikácie U1 až U3 je treba uvažovať vo variante použitia služieb vládneho cloudu aj s použitím služieb verejnej časti vládneho cloudu, kde kapacitné obmedzenia privátnej časti vládneho cloud nie sú.
Napriek tomu, že verejný cloud má dostatočné zdroje, nie je ich garancia pre kritickú infraštruktúru dostatočne zmluvne zabezpečiteľná (ťažko sa uplatňujú sankcie a dôkazné bremeno je na štáte, súdy môžu trvať roky).
Sablona I02 pre cloud sa vyplna ak nie je navrhnuta infrastruktura on premise. My mame on premise. Uroven systemu je U4, vid vypracovana priloha pre klasifikaciu systemu. Do textu pre UPVS a PEP alternativy doplnene cloudove
Ak súčasťou dodávky má byť aj HW v alternatíve TA3, ktorá bola zvolená v tomto hodnotení, tak prečo nie je v rozpočte uvedený náklad na doplnenie HW do infraštruktúry ÚPVS? Treba buď prehodnotiť hodnotenie v tomto bode, napr. či naozaj treba rozšíriť HW NASES, alebo ide len o alokáciu potrebných výpočtových zdrojov z riešenia privátneho cloudu NASES.
Ako sa myslelo toto Možno? Či už by bolo riešenie v privátnej časti alebo verejnej časti VC, tak veľmi pravdepodobne obe časti sú schopné pri správnom návrhu riešenia umožňujúcom škálovanie do šírky poskytnúť potrebný vysoký výkon.
"Velmi pravdepodobne" pre kritickú infraštruktúru nestačí
Sablona I02 pre cloud sa vyplna ak nie je navrhnuta infrastruktura on premise. My mame on premise. Uroven systemu je U4, vid vypracovana priloha pre klasifikaciu systemu. Do textu pre UPVS a PEP alternativy doplnene cloudove
Myslí sa týmto vyhodnotením riziko nákladov pracovníkov prevádzky, ktorí by sa museli zaučiť na nové technológie, alebo sú to náklady na služby a licencie, ktoré by NASES musel zakúpiť navyše k existujúcim licenciám, ktoré by vedel NASES prepoužiť?
Záväzné určenie poplatku nie je vlastná koncová služba katalógu ale občan/podnikateľ sa k záväznému určeniu poplatku dostanú prostredníctvom koncových služieb iných IS, ktoré budú na katalóg naintegrované
Ešte by bolo možno vhodné pre vybrané OVM (MFSR a možno nejaké ďalšie) pridať ešte KS typu G2G: Poskytovanie analytických výstupov pre dohľad a prípravu politík správy poplatkov. Sem by spadalo aj vytvorenie publikačnej verzie poplatkov pre zverejnenie v Zbierke. Alebo by sa pre tento účel publikovania urobila špeciálna služba alebo by bola súčasťou schvaľovania aktuálneho cenníka z MFSR nasledujúcou KS. Tiež asi bude potrebná KS pre MFSR pre schválenie a publikovanie katalógu poplatkov, keďže asi zmeny poplatkov zadaných z OVM budú musieť prejsť nejakým schválením z MFSR pred ich oficiálnym zverejnením.
Predpokladám, že proces zadania a zmeny poplatkov ešte prejde nejakou optimalizáciou a prehodnotením, spôsobu autorizácie zmeny poplatkov - či naozaj má mať zadanie zmeny položiek katalógu charakter podania a či sa uatorizácia nedá urobiť jednoduchšie len mechanizmom riadenia prístupov na základe rolí používateľov, dodatočným potvrdením napr. systémom 4 očí schvaľovateľa na OVM a auditným žurnálom zmien.
Mechanizmus riadenia prístupov na základe rolí rozhodne nie je jednoduchší ako používanie formulárov, znamená to z dôvodu kritickej infraštruktúry významné navýšenie rozpoštu z dôvodu bezpečnosti
Rovnako hromadný import je sucastou katalogu poziadaviek - Import poloziek
V alternatívach riešenia bolo vyhodnotené odporúčanie pre alternatívu AA2, takže len na tú by sa mal projekt zamerať. Ak je AA1 myslená ako prechodná fáza k AA2, tak to potom tak treba uviesť a potom je otázne, či má byť AA1 hodnotená ako alternatíva, ak je len prechodnou fázou k AA2.
V METAIS je evidovaný systém s názvom "Informačný systém Katalóg platieb", Kód MetaIS = isvs_15162. Zosúlaďte názov ISVS (ale aj ostatných položiek eGov komponentov) v tomto dokumente I-02 a v evidencii METAIS. Doplňte v METAIS aj ich popisy tak, aby bolo jasné, aký je ich účel aj bez tohto dokumentu a taktiež nezabudnite doplniť vzťahy medzi ISVS-AS a AS-KS.
Zosúlaďte názvy komponentov v návrhu architektúry podľa ich evidencie v METAIS a názve použitov v tomto dokumente (v METAIS je evidovaný Katalóg platieb, na obrázku je Register poplatkov a v texte sa hovorí o Katalógu poplatkov).
Taktiež uveďte v obrázkoch kódy evidovaných METAIS komponentov, anpr. do zátvorky k názvu komponentu pre ich ľahšiu vzájomnú referencovateľnosť.
Podľa popisu by som očakával, že Komponent určenia výšky poplatku a Komponent pridávania poplatkov budú asi funkčné moduly Registra poplatkov (Katalógu poplatkov). V obrázku sú medzi nimi vzťahy "slúži" a nie agregácie (v prípade podradenia komponentu pod materský modul) alebo priradenia (v prípade modelovania podriadeného komponentu ako funkčný modul, ktorý enbude samostatne nasadený a evidovaný v METAIS).
Tabuľka má byť vyplnená opačne. V prvých dvoch stĺpcoch je systém budovaný projektom v našom prípade isvs_15162 a v 3. a 4. stĺpci majú byť uvedené systémy, na kottoré sa bude budovaný systém isvs_15162 integrovať. Treba uviesť aj ich METAIS kódy.
Služby as_67407 a as_67406 treba zlúčiť do jednej AS Evidovanie položiek poplatkov, ktoré bude poskytovať všetky CRUD operácie, napr. tak, že sa jedna AS premenuje a druhá sa prepoužije na inú službu. Pre všetky AS treba evidovať v METAIS ch vzťah na ISVS, ktorý ich bude realizovať a tiež na KS , pre ktoré budú poskytovať aplikačnú podporu (vzťah AS slúži KS).
Pridanie položky je iná služba ako zmena položky. Mohlo by sa to robit roznymi metodami tej istej služby, ale z pohľadu zadania v MetaIS je to takto jednoduchšie. Jedna je C, druhá je UD. R priamo nie je, je sprostredkované službami 4 a 5. Inak by sa museli robiť pracné úkony na strane integrovaných systémov, čo asi nie je cieľom.
Služby 67404 a 67405 treba zlúčiť do jednej AS Určenie výšky poplatku a treba zaevidovať jej vzťah na KS a ISVS. Stačí jedna služba určenia poplatku a typ jej výsledku bude určovaný vstupnými a výstupnými parametrami.
Nie je jasné, čo požaduje autor pripomienky analyzovať. Samotné informácie o počte zaplatených poplatkov, rozdelení na služby a podobne riešia IS PEP a Štátna pokladnica
Ešte by v tu bolo treba AS pre využitie spoločných modulov podľa príručky METAIS kap. 2.4 (WebSSO - služby autentifikácie voči IAM a služby odosielania správ cez G2G (ak sa budú návrhy na zmeny čáísleníka odosielať ako podanie))
V rámci aplikačných služieb je vytvorená a naviazaná služba as_67538 - Konzumovanie služieb spoločných modulov na jednotlivé spoločné moduly. Máme za to, že toto nie je služba na externú integráciu, ale as spoločných modulov su na externú integráciu
Toto je taký vysokoúrovňový obrázok, až je zbytočný, lebo si čitateľ musí domyslieť, že poplatok je niekde schovaný medzi parametrami služby. Nemáte nejaký detailnejší obrázok, napr. z existujúcej štúdie na katalóg poplatkov?
Samotný dátový model bude predmetom Detailného návrhu riešenia. Paušálna požiadavka na rámcový dátový model je diktovaná metodikou MIRRI aj pre projekty, kde nie je úplne nevyhnutná
Je niekoľko spôsobov uchopenia riešenia, v ktorých ŽS a OVM sú enumerácie alebo samostatné objekty. Nechajme to na dodávateľa riešenia, konzultanti píšuci dokumentáciu sa prikláňajú k názoru, že je vhodnejšie to mať ako samostatné objekty.
Bolo doplnené do katalógu požiadaviek, že detailny datovy model bude sucast Analyzy a dizajnu
Hlavným objektom evidencie by predsa mali byť položky katalógu poplatkov ktoré majú vzťah na Katalóg služieb (preberaný z METAIS). tento hlavný biznis objekt Poplatok tu nemáte uvedený.
Biznis objekt Poplatok je výstupom koncovej služby. Je tvorený sadou atribútov a položiek v tvare XML alebo JSON, ktoré vychádzajú z uvedených objektov evidencie a sú prípadne doplnené resp. vypočítané na základe týchto atribútov a položiek samotnou aplikáciou
NASES má aj presnejší a konkrétnejší obrázok pre svoju technologickú architektúru pre nové moduly ÚPVS pripravované v rámci Slovensko 3.0, keďže podľa bvyhodnotenia technologických alternatív je plánované jej využitie. V katalógu požiadaviek máte pre netechnické požiadavky Podpora CI/CD pipeline (nie je v obrázku), Záťažové a penet. testy, Profylaktika a Cloud Ready. Mohli by ste zrevidovať? A doplniť katalóg požiadaviek? Bude to treba aj pre katalóg požiadaviek do verejného obstarávania.
Bude treba uviesť vybrané požiadavky z postupov ÚPVS pre manažment zdroj. kódov aj do katalógu požiadaviek. A taktiež terba dať požiadavku na poskytnutie aktuálnej verzie zdroj. kódov riešenia spolu s právami na ich plné použitie Objednávateľom.
Dajte si do katalógu požiadaviek požiadavku na dodanie Testovacích scenárov, zdokumentované úspešné vykonanie automatizovaných testov požadovanej funkčnosti dodávateľom pred odovzdaním systému na UAT Objednávateľovi
Takto jednoducho sa to nedá odbyť. Podľa obsahu vzoru I-02 treba určiť požadovanú dostupnosť systému v % prev. času a hodnoty RTO a RPO a dať ich do katalógu požiadaviek. Potenciálny dodávateľ potrebuje vedieť aké sú konkrétne hodnoty dostupnosti aj reakčných časov pri podpore, lebo nemusí poznať aktuálne prevádzkové podstupy a predpisy NASES. Taktiež požiadavky na dostupnosť môžu byť rôzne pre každý modul ÚPVS.
názov BC/CBA nekorešponduje s názvom projektu - prosím zosúladiť.
Pripomienky ku BC/CBA:
záložka: UAW_v02 - r.7-r.11 nie sú doplnené informácie
záložka: POZICIE_INTERNE - "O20" - zdôvodniť počet 2x Špecialista na publicitu, inak zmeniť na 1 pracovnú pozíciu.
záložka: "Harmonogram" - doplniť ostatné moduly
Harmonogram doplneny
UAW je relevantné len pre katalog poplatkov
pred RSO1.2 doplniť: "Špecifický cieľ".
Doplnene
takto nazvaná Priorita sa v OP Slovensko nenachádza.
vedené
veta je z templatu Projektového zámeru - prosím preštylizovať pre potreby predkladanej dokumentácie.
Predmetný text aj s uvedením §15a ods. 4 Zákona o súdnych poplatkoch vyššie ako "Definícia číselníka". Duplicitne nie je potrebné text uvádzať.
Nie je to duplicita, su to dva rozne zakony - Zakon o sudnych poplatkoch a Zakon o spravnych poplatkoch
v MetaIS chýba Popis tejto KS, prosím doplniť.
???? čo ste chceli týmto popisom vyjadriť?
V zásade to nie je koncová služba v pravom slova zmysle, lebo sa aktivuje automaticky pri konaní a KP vráti záväznú hodnotu, ktoru občan alebo podnikateľ zaplati.
Ukazuje, že záväzné určenie poplatku nie je vlastná koncová služba katalógu ale občan/podnikateľ sa k záväznému určeniu poplatku dostanú prostredníctvom koncových služieb iných IS, ktoré budú na katalóg naintegrované.
Po diskusii s Architekturou bola doplnena KS aj do META IS
prosím o vyplnenie v MetaIS a následne i v projektovej dokumentácii.
neda sa priradit k ZS lebo poplatky sa tykaju viacerych ZS, preto sme dali ALL
toto bude ďalšia KS?
Ukazuje, že záväzné určenie poplatku nie je vlastná koncová služba katalógu ale občan/podnikateľ sa k záväznému určeniu poplatku dostanú prostredníctvom koncových služieb iných IS, ktoré budú na katalóg naintegrované
Máte na mysli: Informačný systém pre platby a evidenciu správnych a súdnych poplatkov (IS PEP), isvs_5585? Ak áno, doplniť príslušné informácie do tabuľky.
Doplnene
rovnaká pripomienka ako pri IS PEP, doplniť informácie...
Doplnene
rovnaká pripomienka ako pri IS PEP, doplniť informácie...
v MetaIS doplňte do poľa Popis ISVS.
Vizualizácia motivácie chýba v priloženom súbore modelu "Katalog poplatkov architektura 20250707.archimate"
Pokiaľ viem, tak motivácia nie je rozšíriť IS PEP o katalóg poplatkov ale dodať samostatný modul Katalógu poplatkov. Aj kvôli tomu, že evidencia platieb realizovaná systémom PEP prejde časom do Štátnej pokladnice. Aj kvôli vendor-lock pri IS PEP. Nakoniec aj nižšie v cieľoch je uvedené, že IS PEP sa má integrovať na nový Katalóg poplatkov a nie že IS PEP bude mať v sebe integrovaný katalóg poplatkov. A taktiež vo vyhodnotení alternatív riešenia nebola zvolená alternatíva rozširovania IS PEP.
Primárne by sa mali priraďovať poplatky ku Koncovým službám (KS) a podaniam. Vzťah k život. situáciám je odvodený od zaradenia KS ku položke život. situácie.
Bolo doplnené aj do katgalógu požiadaviek
V návrhu technologickej vrstvy sa uvažuje o nasadení spolu s modulmi ÚPVS a teda na infraštruktúre NASES pre ÚPVS, takže tento predpoklad o dostupnosti kapacít vo vládnom cloude neodpovedá celkom návrhu riešenia. Buď to treba preformulovať na dostupnosť kapacít technologickej infraštruktúry privátneho cloudového riešenia v prevádzke NASES alebo treba prehodnotiť technologické riešenie.
Podľa týchto údajov je na interné práce úprav existujúcich systémov počítané zhruba 1 človekomesiac a pre katalóg poplatkov zhruba 8 človekomesiacov pri pesimistickej cene práce 5000€/osoba. Naozaj to bude tak málo? Nebudú do projektovej prípravy, pripomienkovania dokumentácie, testovania, prípravy technologickej infraštruktúry zapojení interní pracovníci NASES viac?
Nemalo by tu v prípade PEP byť tiež NIE alebo aspoň ČIASTOČNE? Určite má alebo by mohlo mať IS PEP správu všetkých poplatkov - aj pre neelektronické služby?
Pre vyhodnotenie varánt technologického riešenia je potrebné urobiť klasifikáciu systému podľa metodiky MIRRI ako to uvádza aj šablóna I-02 projektového zámeru (Klasifikáciu urobte podľa Metodického usmernenia pre klasifikáciu ISVS 023107/2023/oSBATA-1: https://mirri.gov.sk/sekcie/informatizacia/dokumenty/vladny-cloud/metodicke-usmernenia/)
Pre klasifikácie U1 až U3 je treba uvažovať vo variante použitia služieb vládneho cloudu aj s použitím služieb verejnej časti vládneho cloudu, kde kapacitné obmedzenia privátnej časti vládneho cloud nie sú.
Sablona I02 pre cloud sa vyplna ak nie je navrhnuta infrastruktura on premise. My mame on premise. Uroven systemu je U4, vid vypracovana priloha pre klasifikaciu systemu. Do textu pre UPVS a PEP alternativy doplnene cloudove
Ak súčasťou dodávky má byť aj HW v alternatíve TA3, ktorá bola zvolená v tomto hodnotení, tak prečo nie je v rozpočte uvedený náklad na doplnenie HW do infraštruktúry ÚPVS? Treba buď prehodnotiť hodnotenie v tomto bode, napr. či naozaj treba rozšíriť HW NASES, alebo ide len o alokáciu potrebných výpočtových zdrojov z riešenia privátneho cloudu NASES.
Rovako bol doplneny aj návrh technologickeho riešenia do prislušnej casti.
Ako sa myslelo toto Možno? Či už by bolo riešenie v privátnej časti alebo verejnej časti VC, tak veľmi pravdepodobne obe časti sú schopné pri správnom návrhu riešenia umožňujúcom škálovanie do šírky poskytnúť potrebný vysoký výkon.
Sablona I02 pre cloud sa vyplna ak nie je navrhnuta infrastruktura on premise. My mame on premise. Uroven systemu je U4, vid vypracovana priloha pre klasifikaciu systemu. Do textu pre UPVS a PEP alternativy doplnene cloudove
Myslí sa týmto vyhodnotením riziko nákladov pracovníkov prevádzky, ktorí by sa museli zaučiť na nové technológie, alebo sú to náklady na služby a licencie, ktoré by NASES musel zakúpiť navyše k existujúcim licenciám, ktoré by vedel NASES prepoužiť?
Stačí jedna KS aj na predbežné aj na záväzné určenie poplatku. Bude sa riadiť parametrami.
Ešte by bolo možno vhodné pre vybrané OVM (MFSR a možno nejaké ďalšie) pridať ešte KS typu G2G: Poskytovanie analytických výstupov pre dohľad a prípravu politík správy poplatkov. Sem by spadalo aj vytvorenie publikačnej verzie poplatkov pre zverejnenie v Zbierke. Alebo by sa pre tento účel publikovania urobila špeciálna služba alebo by bola súčasťou schvaľovania aktuálneho cenníka z MFSR nasledujúcou KS.
Tiež asi bude potrebná KS pre MFSR pre schválenie a publikovanie katalógu poplatkov, keďže asi zmeny poplatkov zadaných z OVM budú musieť prejsť nejakým schválením z MFSR pred ich oficiálnym zverejnením.
Zaroven doplnene do KS , ze sa jedna aj o pripadny proces schvalovania poplatkovej politiky
Predpokladám, že proces zadania a zmeny poplatkov ešte prejde nejakou optimalizáciou a prehodnotením, spôsobu autorizácie zmeny poplatkov - či naozaj má mať zadanie zmeny položiek katalógu charakter podania a či sa uatorizácia nedá urobiť jednoduchšie len mechanizmom riadenia prístupov na základe rolí používateľov, dodatočným potvrdením napr. systémom 4 očí schvaľovateľa na OVM a auditným žurnálom zmien.
Rovnako hromadný import je sucastou katalogu poziadaviek - Import poloziek
V alternatívach riešenia bolo vyhodnotené odporúčanie pre alternatívu AA2, takže len na tú by sa mal projekt zamerať. Ak je AA1 myslená ako prechodná fáza k AA2, tak to potom tak treba uviesť a potom je otázne, či má byť AA1 hodnotená ako alternatíva, ak je len prechodnou fázou k AA2.
Omylom ostalo v AA1 jedno oznacenie ako AA2, co uplne popieralo zmysel. Opravene
V METAIS je evidovaný systém s názvom "Informačný systém Katalóg platieb", Kód MetaIS = isvs_15162. Zosúlaďte názov ISVS (ale aj ostatných položiek eGov komponentov) v tomto dokumente I-02 a v evidencii METAIS. Doplňte v METAIS aj ich popisy tak, aby bolo jasné, aký je ich účel aj bez tohto dokumentu a taktiež nezabudnite doplniť vzťahy medzi ISVS-AS a AS-KS.
Prosím doplniť aj METAIS kódy do tabuľky.
Zosúlaďte názvy komponentov v návrhu architektúry podľa ich evidencie v METAIS a názve použitov v tomto dokumente (v METAIS je evidovaný Katalóg platieb, na obrázku je Register poplatkov a v texte sa hovorí o Katalógu poplatkov).
Taktiež uveďte v obrázkoch kódy evidovaných METAIS komponentov, anpr. do zátvorky k názvu komponentu pre ich ľahšiu vzájomnú referencovateľnosť.
Podľa popisu by som očakával, že Komponent určenia výšky poplatku a Komponent pridávania poplatkov budú asi funkčné moduly Registra poplatkov (Katalógu poplatkov). V obrázku sú medzi nimi vzťahy "slúži" a nie agregácie (v prípade podradenia komponentu pod materský modul) alebo priradenia (v prípade modelovania podriadeného komponentu ako funkčný modul, ktorý enbude samostatne nasadený a evidovaný v METAIS).
Tabuľku môžte kvôli prehľadnosti vymazať, keďže sa v tomto prípade nepoužije, podľa zdôvodnenia v prvej vete tejto kapitoly.
Tabuľka má byť vyplnená opačne. V prvých dvoch stĺpcoch je systém budovaný projektom v našom prípade isvs_15162 a v 3. a 4. stĺpci majú byť uvedené systémy, na kottoré sa bude budovaný systém isvs_15162 integrovať. Treba uviesť aj ich METAIS kódy.
Služby as_67407 a as_67406 treba zlúčiť do jednej AS Evidovanie položiek poplatkov, ktoré bude poskytovať všetky CRUD operácie, napr. tak, že sa jedna AS premenuje a druhá sa prepoužije na inú službu. Pre všetky AS treba evidovať v METAIS ch vzťah na ISVS, ktorý ich bude realizovať a tiež na KS , pre ktoré budú poskytovať aplikačnú podporu (vzťah AS slúži KS).
Služby 67404 a 67405 treba zlúčiť do jednej AS Určenie výšky poplatku a treba zaevidovať jej vzťah na KS a ISVS. Stačí jedna služba určenia poplatku a typ jej výsledku bude určovaný vstupnými a výstupnými parametrami.
Zároveň bola vytvorená nová KS Záväzné úrčenie poplatku ako aj previazanie na prislusnu AS
Zvážte doplnie AS pre navrhnuté doplnenie KS: Poskytovanie analytických výstupov pre dohľad a prípravu politík správy poplatkov.
Ešte by v tu bolo treba AS pre využitie spoločných modulov podľa príručky METAIS kap. 2.4 (WebSSO - služby autentifikácie voči IAM a služby odosielania správ cez G2G (ak sa budú návrhy na zmeny čáísleníka odosielať ako podanie))
Toto je taký vysokoúrovňový obrázok, až je zbytočný, lebo si čitateľ musí domyslieť, že poplatok je niekde schovaný medzi parametrami služby. Nemáte nejaký detailnejší obrázok, napr. z existujúcej štúdie na katalóg poplatkov?
Datovy model bol zmeneny
Životná situácia je len klasifikačný parameter koncovej služby a súvisiaceho podania. Nemá zmysel ho tu uvádzať.
Bolo doplnené do katalógu požiadaviek, že detailny datovy model bude sucast Analyzy a dizajnu
Hlavným objektom evidencie by predsa mali byť položky katalógu poplatkov ktoré majú vzťah na Katalóg služieb (preberaný z METAIS). tento hlavný biznis objekt Poplatok tu nemáte uvedený.
NASES má aj presnejší a konkrétnejší obrázok pre svoju technologickú architektúru pre nové moduly ÚPVS pripravované v rámci Slovensko 3.0, keďže podľa bvyhodnotenia technologických alternatív je plánované jej využitie. V katalógu požiadaviek máte pre netechnické požiadavky Podpora CI/CD pipeline (nie je v obrázku), Záťažové a penet. testy, Profylaktika a Cloud Ready.
Mohli by ste zrevidovať? A doplniť katalóg požiadaviek? Bude to treba aj pre katalóg požiadaviek do verejného obstarávania.
Nebude treba robiť nový alebo aktualizácie existujúceho Bezpečnostného projektu? Ak treba, tak treba doplniť do katalógu požiadaviek.
Bude treba uviesť vybrané požiadavky z postupov ÚPVS pre manažment zdroj. kódov aj do katalógu požiadaviek. A taktiež terba dať požiadavku na poskytnutie aktuálnej verzie zdroj. kódov riešenia spolu s právami na ich plné použitie Objednávateľom.
Dajte si do katalógu požiadaviek požiadavku na dodanie Testovacích scenárov, zdokumentované úspešné vykonanie automatizovaných testov požadovanej funkčnosti dodávateľom pred odovzdaním systému na UAT Objednávateľovi
Dajte si do katalógu požiadaviek dodanie projektovej dokumentácie a dokumentácie dodaného riešenia podľa vyhlášky 401/2023.
Takto jednoducho sa to nedá odbyť. Podľa obsahu vzoru I-02 treba určiť požadovanú dostupnosť systému v % prev. času a hodnoty RTO a RPO a dať ich do katalógu požiadaviek. Potenciálny dodávateľ potrebuje vedieť aké sú konkrétne hodnoty dostupnosti aj reakčných časov pri podpore, lebo nemusí poznať aktuálne prevádzkové podstupy a predpisy NASES. Taktiež požiadavky na dostupnosť môžu byť rôzne pre každý modul ÚPVS.
Základné číselníky sú schvaľované na zasadnutiach pracovnej skupiny PS1
Doplnené slovo poplatkov
Takýto údaj sa nenachádza medzi referenčnými údajmiReferencovateľné identifikátory | MetaIS
objekty evidencie integrované na IS CDPI sú popísané tu:Postup na IS Centrálna platforma dátovej integrácie | Ministerstvo investícií, regionálneho rozvoja a informatizácie SR
Upravene
V úvode sa spomínajú otvorené údaje, katalóg je verejne prístupný a môže byť sprístupnený ako otvorený dataset na portáli data.slovensko.sk
Takýto údaj sa nenachádza medzi referenčnými údajmiReferencovateľné identifikátory | MetaIS
objekty evidencie integrované na IS CDPI sú popísané tu:Postup na IS Centrálna platforma dátovej integrácie | Ministerstvo investícií, regionálneho rozvoja a informatizácie SR