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
Chýba aj vypracovaná príloha pre klasifikáciu systému, na ktorú sa odkazujete, aj uvedenie výslednej klasifikácie v texte projektového zámeru v časti vyhodnotenie alternatív v technol. vrstve. Uvedenie klasifikácie v odpovedi na pripomienku nie je zapracovanie do dokumentu.
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.
V Tabuľke 6 Sumarizácie nákladov chýba uvedenie časti nákladov na SW pre HW (127 822 €):
Tiež sa tu uvádza len licencia na WM Ware a licenciu na operačný systém netreba pre uvedený počet VM? Nebude treba pre systém zaradený v U4 podporovaný linux, anpr. RedHat?
Tiež som skeptický k zámeru nasadiť riešenie na samostatný HW, keď NASES plánuje obstarať pre prevádzku ÚPVS cloudovú infraštruktúru, že bude záujmom NASES prevádzkovať na samostatnej oddelenej HW platforme, takže skôr očakávam, že bude záujmom NASES zabezpečiť potrebný výkon pre katalóg poplatkov skôr zabezpečením rozšírenia kapacít existujúcej cloudovej infraštruktúry. Preto by asi bolo lepšie aj náklady inak klasifikovať a pomenovať. S kým z tímu infraštruktúry a architektov NASES ste návrh riešenia a potrebnú kalkuláciu nákladov na licencie Systémového SW preberali?
Polozky boli preklasifikovane na HW aby boli dotiahnute do spravnej "kolonky".
Co sa tyka HW tak, riesenie nema byt na samostatom hw, ma byt sucastou infra upvs. tu je vsak potrebne z dovodu potreby dedikovat zdroje pre kp, preto sme uviedli orientacne ceny hw a virtualizacie, ktore by to mohli pokryvat. finalna zostava bude zavisiet na redizajne hw pre upvs, co v sucasnosti nie je finalizovane
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).
Čiastočné zapracovanie (upravené niektoré vzťahy a doplnené kódy AS) ale hodilo by sa ešte agregovať (zahniezdiť) komponenty Register poplatkov, Komponent určenia výšky poplatku, Komponent pridávania/ zadávania zmien/ deaktivácie poplatkov a Rozhranie pre zobrazenie a informatívne určenie výšky poplatku (Web GUI) do hlavného ISVS dodaného týmto projektom Informačný systém katalógu poplatkov (isvs_15162).
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
Čiastočne zapracované. Podľa inštrukcie v šablóne I-02 je potrebné uviesť aj konzumujúce služby určené na integráciu a teda aj as_67538 - Konzumovanie služieb spoločných modulov a AS, na ktoré sa bude integrovať. Treba sem uviesť AS, na ktoré ste v METAIS nastavili vzťah tejto služby.
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.
To pojednanie o rizikách sprístupnenia kódu ako Open Source môžete odtiaľ vyhodiť. Stačí uviesť, že z bezpečnostných dôvodov nebude zdrojový kód verejne prístupný. NASES by ho ale vo svojom repozitári s riadeným prístupom používateľov mal mať.
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.
Vo verejnom obstarávaní nebude môcť NASES obstarávať servery tak, že bude obstarávať konkretny typ konkrétneho vyýrobcu, tak ich radšej neuvádzajte ani tu, a keď tak len ako príklad použitý pre určenie predpokladaných nákladov a treba uviesť, že je to len príklad možnej alternatívy použitej pre odhad nákladov. Stačí uviesť o aký typ architektúry servera ide (napr. x86-64, alebo RISC) a aký je požadovaý počet jadier CPU, RAM a celkový objem dátového úložiska.
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
názov projektu uvedený v BC/CBA nie je totožný s názvom projektu - potrebné zosúladiť.
ostatné pripomienky vznesené ku BC/CBA sú zapracované.
Zapracovane
pred RSO1.2 doplniť: "Špecifický cieľ".
Doplnene
OK, zapracované
takto nazvaná Priorita sa v OP Slovensko nenachádza.
Ok, zapracované
vedené
zapracované
veta je z templatu Projektového zámeru - prosím preštylizovať pre potreby predkladanej dokumentácie.
zapracované
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
áno, máte pravdu, OK, túto pripomienku beriem späť.
v MetaIS chýba Popis tejto KS, prosím doplniť.
OK, zapracované.
???? č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
OK, rozumiem, zapracované.
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
OK, rozumiem
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é
OK
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
OK
rovnaká pripomienka ako pri IS PEP, doplniť informácie...
Doplnene
OK
rovnaká pripomienka ako pri IS PEP, doplniť informácie...
v MetaIS doplňte do poľa Popis ISVS.
OK, zapracované
Vizualizácia motivácie chýba v priloženom súbore modelu "Katalog poplatkov architektura 20250707.archimate"
Akceptované zapracovanie
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.
Akceptované zapracovanie
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
Akceptované zapracovanie.
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.
Akceptované zapracovanie.
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?
Akceptované vysvetlenie.
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?
Akceptované
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
Chýba aj vypracovaná príloha pre klasifikáciu systému, na ktorú sa odkazujete, aj uvedenie výslednej klasifikácie v texte projektového zámeru v časti vyhodnotenie alternatív v technol. vrstve. Uvedenie klasifikácie v odpovedi na pripomienku nie je zapracovanie do dokumentu.
Dokument bol nahraty
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.
V Tabuľke 6 Sumarizácie nákladov chýba uvedenie časti nákladov na SW pre HW (127 822 €):
Tiež sa tu uvádza len licencia na WM Ware a licenciu na operačný systém netreba pre uvedený počet VM? Nebude treba pre systém zaradený v U4 podporovaný linux, anpr. RedHat?
Tiež som skeptický k zámeru nasadiť riešenie na samostatný HW, keď NASES plánuje obstarať pre prevádzku ÚPVS cloudovú infraštruktúru, že bude záujmom NASES prevádzkovať na samostatnej oddelenej HW platforme, takže skôr očakávam, že bude záujmom NASES zabezpečiť potrebný výkon pre katalóg poplatkov skôr zabezpečením rozšírenia kapacít existujúcej cloudovej infraštruktúry. Preto by asi bolo lepšie aj náklady inak klasifikovať a pomenovať. S kým z tímu infraštruktúry a architektov NASES ste návrh riešenia a potrebnú kalkuláciu nákladov na licencie Systémového SW preberali?
Podľa CBA - hárok "Rozpočet - HW a licencie":
Polozky boli preklasifikovane na HW aby boli dotiahnute do spravnej "kolonky".
Co sa tyka HW tak, riesenie nema byt na samostatom hw, ma byt sucastou infra upvs. tu je vsak potrebne z dovodu potreby dedikovat zdroje pre kp, preto sme uviedli orientacne ceny hw a virtualizacie, ktore by to mohli pokryvat. finalna zostava bude zavisiet na redizajne hw pre upvs, co v sucasnosti nie je finalizovane
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
Akceptované vysvetlenie pre túto alternatívu.
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ť?
Akceptované zapracovanie.
Stačí jedna KS aj na predbežné aj na záväzné určenie poplatku. Bude sa riadiť parametrami.
Akceptované vysvetlenie
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
Nenašiel som text uvádzaného doplnenia "schvalovania poplatkovej politiky". Kde ste to pridali?
V ramci samotneho polozky KS v META IS
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
Akceptované vysvetlenie.
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
Akceptované zapracovanie a vysvetlenie.
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.
Akceptované zapracovanie
Prosím doplniť aj METAIS kódy do tabuľky.
Akceptovaé zapracovanie
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).
Čiastočné zapracovanie (upravené niektoré vzťahy a doplnené kódy AS) ale hodilo by sa ešte agregovať (zahniezdiť) komponenty Register poplatkov, Komponent určenia výšky poplatku, Komponent pridávania/ zadávania zmien/ deaktivácie poplatkov a Rozhranie pre zobrazenie a informatívne určenie výšky poplatku (Web GUI) do hlavného ISVS dodaného týmto projektom Informačný systém katalógu poplatkov (isvs_15162).
Komponenty isvs_15162 boli zgrupene aj vizualne
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.
OK
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.
Akceptované zapracovanie
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).
Akceptované vysvetlenie.
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
Akceptované vysvetlenei a zapracovanie
Zvážte doplnie AS pre navrhnuté doplnenie KS: Poskytovanie analytických výstupov pre dohľad a prípravu politík správy poplatkov.
Akceptované vysvetlenie pri osobnej konzultácii.
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))
Čiastočne zapracované. Podľa inštrukcie v šablóne I-02 je potrebné uviesť aj konzumujúce služby určené na integráciu a teda aj as_67538 - Konzumovanie služieb spoločných modulov a AS, na ktoré sa bude integrovať. Treba sem uviesť AS, na ktoré ste v METAIS nastavili vzťah tejto služby.
Mali sme za to, ze tie su prave urcene v ramci prirucky k META IS a teda je jasne, ktory spolocny modul poskytuje ake AS na integraciu.
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
Akceptované zapracovanie
Ž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
Akceptované zapracovanie a vysvetlenie
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ý.
Akceptované zapracovanie
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.
Akceptované doplnenie požiadaviek do katalógu požiadaviek. Obrázok ma nulovú pridanú informačnú hodnotu. Ani tam nemusí byť.
Nebude treba robiť nový alebo aktualizácie existujúceho Bezpečnostného projektu? Ak treba, tak treba doplniť do katalógu požiadaviek.
Akceptované doplnenie 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.
To pojednanie o rizikách sprístupnenia kódu ako Open Source môžete odtiaľ vyhodiť. Stačí uviesť, že z bezpečnostných dôvodov nebude zdrojový kód verejne prístupný. NASES by ho ale vo svojom repozitári s riadeným prístupom používateľov mal mať.
Akceptované doplnenie katalógu požiadaviek.
Toto bolo doplnene na zaklade poziadaviek SD ako splnenie ich pripomienok
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
Akceptované zapracovanie
Dajte si do katalógu požiadaviek dodanie projektovej dokumentácie a dokumentácie dodaného riešenia podľa vyhlášky 401/2023.
Akceptované zapracovanie
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.
Akceptované zapracovanie
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
ok
Takýto údaj sa nenachádza medzi referenčnými údajmiReferencovateľné identifikátory | MetaIS
OK, zapracované.
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
Jedná sa o tento OE? Názov objektu evidencie: Register právnických osôb
v MetaIS je povinnou osobou MIRRI, poprosím zosúladiť informácie s projektovou dokumentáciou.
Upravene
OK, zapracované.
BC/CBA bola aktualizovaná a teda údaje nie sú totožné s obrázkom, pls aktualizovať obrázok.
Aktualizovane
OK, zapracované.
Licencie na Linuxové uzly nebudú potrebné - napr. Red Hat?
Cielove poziadavky budu sucastou VO resp. analyzy a dizajnu
OK.
Vo verejnom obstarávaní nebude môcť NASES obstarávať servery tak, že bude obstarávať konkretny typ konkrétneho vyýrobcu, tak ich radšej neuvádzajte ani tu, a keď tak len ako príklad použitý pre určenie predpokladaných nákladov a treba uviesť, že je to len príklad možnej alternatívy použitej pre odhad nákladov. Stačí uviesť o aký typ architektúry servera ide (napr. x86-64, alebo RISC) a aký je požadovaý počet jadier CPU, RAM a celkový objem dátového úložiska.
Uvedene len ako priklad
OK, zapracované.