IS ROM bude konzumovať služby, ktoré nie sú vypublikované na CPDI (napr. zmenové dávky IS RFO). Prostredníctvom IS CPDI budú konzumované služby napr. UPSVaR.
IS ROM bude konzumovať služby, ktoré nie sú vypublikované na CPDI (napr. zmenové dávky IS RFO). Prostredníctvom IS CPDI budú konzumované služby napr. UPSVaR.
Metaúdaje k datasetom je potrebné katalogizovať na portáli otvorených dát data.slovensko.sk podľa aktuálneho metaúdajového štandardu DCAT AP-SK/resp. zároveň ku projektu vytvoriť lokálny katalóg otvorených dát, resp. OpenApi a tú/ten zaregistrovať na portál data.slovensko.sk
Dáta je potrebné v rámci dátovej kvality stotožňovať a referencovať voči referenčným registrom, používať identifikátori ako IČO, identifikátor adresy, resp. fyzickej osoby, zaviesť biznis pravidlá/metodiku ku dátovej kvalite, obmedzenia pre dáta (hodnoty, formáty, rozsahy...) keďže sa plánuje zlučovanie dát z rôznych registrov a IS
koľkým subjektom sa budú údaje poskytovať, resp. ak je to cieľ, nie je vhodné na to vytvoriť KPI napr. počet subjektov, ktorým sú poskytované anonymizované údaje?
podľa informácií v projekte sú v projekte aj elektronické služby pre občana. Podľa § 8 vyhlášky 401/2023 Z. z. je potrebné zrealizovať používateľský prieskum už v prípravnej a iniciačnej fáze a spracovať z neho výsledky v projekte. Prebehol takýto prieskum?
Ak je súčasťou projektu alebo zmenovej požiadavky v prevádzke vytvorenie alebo zmena elektronickej služby s grafickým používateľským rozhraním slúžiacej koncovým používateľom, vytvorenie alebo zmena elektronickej služby s aplikačným rozhraním, spôsoby a postupy elektronizácie agendy verejnej správy podľa osobitného predpisu sú realizované v týchto projektových fázach, kde jedna je používateľský prieskum, ktorý je výstupom prípravnej a iniciačnej fázy projektu a predmetom ďalšieho spracovania v realizačnej fáze projektu. https://www.slov-lex.sk/ezbierky-fe/pravne-predpisy/SK/ZZ/2023/401/20231115#paragraf-8.nadpis
V opačnom prípade konštatujeme porušenie § 8 písm. a) vyhlášky MIRRI č. 401/2023 Z. z. o riadení projektov a zmenových požiadaviek v prevádzke informačných technológií verejnej správy v nadväznosti na § 24 ods. 2 zákona č. 95/2019 Z. z.o ITVS
prínosy prosím aj vysvetliť a popísať. V CBA sú akési údaje, ale nie sú vysvetlené. Na záložke parametre agendové sú pre jednotlivé moduly uvedené časy pre spracovanie (čas úradníka) a následne po implementácii projektu nie je nič - dôjde k automatizácii? Z čoho vyplývajú časy? Taktiež to vyzerá, že máte rovnaký prínos využitý pri viacerých moduloch a tiež prínosy začínajú plynúť ešte v čase realizácie projektu, čo nezodpovedá realite.
Áno výstupom je automatizácia a keďže výstupy projektu začnú byť dostupné v prvom roku a s cieľom porovnať voči AS/IS stavu, ktorý reprezentuje rovnaké množstvo podaní manuálne spracovaných tak sa uvádzajú pre prvý rok.
Prosím - podstatné - CBA, ktorú ste použili, ktorá bola zverejnená na QA stránke, nie je určená pre iné projekty okrem tých z výzvy 617, ktorá je už uzavretá. Prosím o použitie správnej CBA
V projektovom tíme absentuje pozícia UX dizajnér, ktorá má byť súčasťou projektového tímu podľa vyhlášky 401/2023 Z. z.. Kto vo vašom projekte zastreší oblasť UX?
Absentuje legislatíva: zákon o ITVS 95/2019 Z. z., vyhláška o elektronizácii agendy verejnej správy 547/2021 Z. z., vyhláška o o štandardoch pre informačné technológie verejnej správy 78/2020 Z. z.
Váš projekt sa nachádza v realizačnej fáze, no podľa 401/2023 používateľský prieskum má byť súčasťou a výstupom prípravnej a iniciačnej fázy projektu. Prosím o zosúladenie.
tuto je to trochu inak popísané, ako sa spomínalo na úvodnom stretnutí k projektu. Tam bolo spomenuté, že legislatíva nie je rizikom, ale z tohto textu vyplýva celkom veľké riziko, ak by neexistoval právny základ na adresnú energo pomoc
Stále platí, že celý systém IS ROM môže byť vybudovaný na základe zákona č. 71/2025 Z.z. o poskytovaní údajov na účel adresnej pomoci. Zmienený odstavec len poukazuje na riziko, že nebudú definované legislatívne podmienky na vyplácanie energopomoci, čo však pri súčasnom stave rozpracovania legislatívy nepredpokladáme.
čiže vznikajú tieto nové koncové služby pre občana - viete nám v texte popísať, na čo jednotlivé služby slúžia?
Zároveň v rámci názvov odporúčame pri tvorbe dodržiavať princípy § 26 v vyhlášky 78/2020 Z. z., ale aj z Príručky k MetaIS
Odporúčame teda použitie slovesného podstatného mena ako "podávanie sťažnosti..." alebo "Nahlasovanie zmeny údajov odberného miesta").
Taktiež z názvov by malo byť jasné, o čo ide. Napr. Udelenie adresnej pomoci je nešpecifické a je písané z pohľadu OVM, lebo OVM niečo udeľuje, ale občan o niečo žiada.
nižšie popisujete 1 proces, ale vychádzajúc z prínosov aj koncových služieb pre občana, zmení sa toho na biznis úrovni teda dosť. Pýtam sa teda:
1. aké zmeny nastanú na biznis úrovni, ktoré spôsobia to, že sa ušetrí toľko času úradníka, koľko píšte v prínosovej časti CBA (Parametre agendové)?
2. čo celý projekt znamená pre občana - tu sa pýtam ako občan - čo bude vlastne výsledkom projektu ako celok, ako to budem môcť použiť? Čo to pre mňa znamená? Ako zistíte, či som vhodný kandidát pre energopomoc? Viete popísať v jednoduchosti celý proces/výsledok tohto projektu?
AS/IS proces znamená, že občania by dokumenty a žiadosti o adresnú pomoc museli nosiť na úrady. TO/BE stav znamená, že adresná energopomoc bude poskytovaná proaktívne, na základe existujúcich údajov z ISVS. V prípade nezrovnalostí môže občan podať reklamáciu.
Potreba monitoringu je vždy. V Kat. požiadaviek máte požiadavku na integráciu na prevádzkový monitoring, tak prečo je tu len možnosť? Keď robíte takýto projekt, treba riešiť aj monitoring funkčnosti a dostupnosti systému a kvôli citlivosti spracovávaných dát aj bezpečnostný monitoring a integráciu na SIEM.
V katalógu požiadaviek máte síce odpovedajúce funkčné požiadavky ale kvôli sledovaniu realizácie KS si dajte k príslušným požiadavkám na realizáciu KS kódy METAIS aj do katalógu požiadaviek.
Neplánujete obstarať žiadne licencie SW. V CBA máte uvedené licencie na Power BI. Tie ste neplánovali do rozpočtu zaradiť? Tieti licencie na Poer BI máte v CBA uvedené so zaradením do "A1 - Manažment osobných údajov" príčom v popise projektu píšete, že oblasť Mojich údajov (dát) nie je v projekte riešená. Zosúlaďte CBA, katalóg požiadaviek a popis projektu s textom I-02 Proj. zámer.
Nebudete potrebovať licencie na operačný systém alebo databázový systém, keďže v projekte uvažujete s vybudovaním DB clusterov. Plánujete všetok systémový SW riešiť len pomocou open source? Nebude potrebovať licencovať Oper. systém na HW? Privátny vládny cloud poskytuje len voľne dostupný Linux. V prípade, že by ste chceli použiť napr. RedHat alebo inú platenú distribúciu, bude ju musieť obstarať. Nepotrebujete si an takéto investície dať nejakú alokáciu finančných prostriedkov do rozpočtu?
Prosím vložiť obrázok a najlepšie aj odkaz do Architektonického modelu (názov pohľadu), ktorý ste nahrali a po úprave nahráte novú verziu do METAIS k proj. dokumentácii.
V náhľade celkovej architektúry uveďte pre dodávané komponenty evidované v METAIS aj ich kódy v názve komponentu napr. do zátvorky, aby vrcholový model a jeho hlavné dodávané komponenty odpovedali ich evidencii v METAIS.
Obrázok vložený. Prosíme zvážiť pridanú hodnotu zapracovania kódov META IS do obrázkov, pretože by obrázky boli neprehľadné (z dôvodu formátovania zobrazovaných reťazcov).
V architektoncikom modeli, ktorý ste nahrali uveďte pri plánovaných koncových službách aj kód služby v METAIS (napr. tak, že za názov služby dáte do zátvorky kód METAIS). Zosúlaďte model s evidecniou v METAIS minimálne na vrcholových pohľadoch na systém, kde sú uvedené eGovernement komponenty evidované v METAIS. Z názvu všetkých koncových služiev v modeli odstráňte zbytočný text "Životná situácia - " - zneprehľadňuje to model. Modelovaný vzťah rola "Správca adresnej pomoci" je kompozíciou biznis rozhrania "Energoportál" je dosť divný. Dalo by sa síce nájsť vysvetlenie a interpretácia takéhoto vzťahu, ale asi ste skôr chceli povedať, že Energoportál buď slúži alebo je obsluhovaný pracovníkom MHSR v roli správca adresnej pomoci, nie? Týka sa to aj ďalších podobných vzťahov v modeli a náhľade biznis vrstvy. Taktiež odporúčam pre sprehľadnenie náhľadu usporiadať súvisiace komponenty k sebe do vrstiev (pracovníci, role, rozhrania, služby, biznis dáta).
Prosíme zvážiť pridanú hodnotu zapracovania kódov META IS do obrázkov, pretože by obrázky boli neprehľadné (z dôvodu formátovania zobrazovaných reťazcov).
API odberné miesta nie je vhodný názov pre aplikačnú službu. Pozrite príručku METAIS s usmernením pre názov koncových služieb a podobný vzor treba použiť aj pre aplikačné služby. API je rozhranie, nie služba. Pre KS ks_381391, ks_381392, ks_381393 by vhodným názvom AS bolo napr. "Evidovanie (alebo aj "Evidencia") odberných miest". Pre ks_381389 a tiež aj pre ks_381390 a ks_381386 aplikačná služba s názvom "Poskytnutie údajov o adresnej pomoci" pre zisťovaciu časť procesu. Pre spracovanie žiadostí a sťažností (ks_381387, ks_381388, ks_381390) napr. aplikačná služba "Spracovanie žiadostí". Pre generovanie šekov s adresnou pomocou aplikačnej služby "Generovanie (výpočet) dát adresnej pomoci". Lepšie poznáte problematiku a tak môžete prpraviť lepšie názvy aplikčných služieb. pripomínam tiež, že jedna aplikačná služba (AS) môže slúžiť viacerým KS a žiadna KS by namala byť bez aspoň jednej obsluhujúcej AS. Doplňte a opravte tiež evidenciu v METAIS (nezmyselné viacnásobné evidovanie aplik. služieb s rovnakým názvom eGov API, "API Odberné miesta") Do tejto tabuľky v dokumente I-02 doplňte kódy METAIS aplikačných služieb.
Tu má byť uvedený kód a názov aplikčnej služby, ktorá realizuje integráciu na strane konzumenta služby spoločného modulu a nie kód modulu poskytujúceho službu. V poslednom stĺpci má byť uvedená služba (služba spol. modulu), na ktorú bude AS uvedená v prvom stĺpci integrovaná.
Uveďte si požiadavku na dodávku Bezpečnostného projektu aj do Katalógu požiadaviek. A taktiež do požiadavky doplňte, že v dodávanom systéme budú aplikované opatrenia identifikované bezpečnostným projektom a že bezpečnostný projekt bude priebežne počas projektu altualizovaný podľa skutočnej realizácie a nasadenia systému.
Požiadavku na konkrétnu úroveň dostupnosti si dajte aj do katalógu požiadaviek. Taktiež s do katalógu dajte požiadavku na parametre RTO a RPO. Z katalógu požiadaviek odstráňte zbytočné duplicitné nekonkretizované požiadavky na zálohovanie a dostupnosť pre jednotlivé podmoduly. Buď k nim uveďte konkrétne parametre, alebo ich vyriešte jednou spoločnou požiadavkou. Nepotrebujete nafukovať počet požiadaviek zbytočnými duplicitami.
Chýbajúce obrázky nižšie pre znázornenie uvedených procesov: Overenie získania energopomoci, Podanie sťažnosti pre nezískanie energopomoci, Podanie sťažnosti o nesprávnej energopomoci, Žiadosť o vylúčenie z energopomoci
V arch. modeli (súbor rom 1.archimate) máte pekný obrázok plánovaného nasadenia s názvom "Architektúra". Môžete ho tu uviesť. V modeli mu ale zmeňte názov, lebo je to skôr náhľad plánovaného nasadenia systému ako všeobecný názov "Architektúra"
Pre overovanie stíhania budete asi potrebovať nejakú aplikačnú službu pre Lustrácie, lebo asi tieto dáta Vám MVSR neposkytne hromadne. Pre overenie registra trestov zvážte použitie IS CPDI namiesto priamej integrácie na Gen. prokuratúru.
Pre potenciálnu integráciu systémov, ktoré používajú plánované pracoviská spolupracujúcich OVM (úrady práce, Slov. pošta, CallCentrum MVSR, atď.) budete asi potrebovať samostatnú sadu služieb pre takúto integráciu, ak tieto orgány budú chcieť implementovať vlastné používateľské rozhranie do svjich systémov namiesto použitia web rozhrania systému ROM pre sprostredkovateľov energopomoci.
V biznis architektúre vám chýba aktér pracovník sprostredkovania energopomoci a príslušná rola a distribučný kanál ( napr. nejaká špecializovaná podčasť Energoportálu alebo API pre integráciu systému sprostredkovateľa pomoci) a tomu odpovedajúca aplikačné časti - web rozhranie a API pre integráciu sprstredkovateľov pomoci.
Dajte si do katalógu požiadaviek, že vám má dodávateľ dodať návrh testovacích scenárov pre otestovanie plnej funkčnosti dodávaného systému a tiež že má podľa definovaných scenárov vykonať a protokolárne zdokladovať automatizované otestovanie funkčnosti systému podľa navrhnutých testovacích scenárov.
V modeli a obrázku aplikačnej architektúry uveďte aj METAIS kódy znázornených ISVS, ich modulov a tiež aplikačných služieb (napr. do zátvorky k názve komponentu). Plánované podmoduly systému ROM radšej modelujte ako funkčné bloky, ak nebudú samostatne nasadzované a evidované v METAIS ako podmoduly. Samostatne nasadzované podmoduly, ako je napr. web portál, analytický systém, samostatnú integračnú platformu by bolo lepšie uviesť ako podmoduly systému ROM a zaevidovať ich tiež v METAIS buď ako podmoduly systému ROM alebo ako súčasne dodávané systémy v tomto projekte.
Prosíme zvážiť pridanú hodnotu zapracovania kódov META IS do obrázkov, pretože by obrázky boli neprehľadné (z dôvodu formátovania zobrazovaných reťazcov).
1. záložka moduly CBA - pre moduly 17 až 20 máte zle nastavené productivity faktory, ktoré ponúkajú možnosti len 15, 20, 25 a 30. Tu to dotiahol excel nejak chbyne, prosíme opraviť
2. záložka UAW - prosím, vysvetlite používateľov:
3 typy používateľov typu občan
3 typy používateľov typu zamestnanec inštitúcie verejnej správy
11 systémov verejnej správy - tu je aj zle nastavená zložitosť (má byť 2 alebo 1 podľa Metodiky k CBA - 1 = používateľ je systém s definovaným aplikačným programovým rozhraním, 2 = systém interagujúci prostredníctvom protokolu (napr. Transmission control protocol/Internet protocol)
4 isvs mimo verejnej správy - tiež je tu zle nastavená zložitosť
3. v celej CBA pravdepodobne nie je aktualizovaná sadzba DPH na 23% - vyriešite vyplnením správnej CBA
4. ak financujete projekt z Programu Slovensko , tak na záložke pozície interné v CBA v bunke Q2 nepoužívate odmeny - tie sú zahrnuté v sadzbách
5. prínosy na záložke Parametre agendové sa vám rátajú od 1. roku, ale v realite nastanú v podstate až v roku 3.
6. záložka ECF - tu ste zadávali hodnoty? Všade sú 1ky.
7. záložka Pozície interné - v prípade projektov z Programu Slovensko sa neuplatňujú odmeny - bunka Q2
uvedené ID/názvy cieľov nezodpovedajú tým, čo ste si nastavili. Vyzerá to tak, že ciele a ukazovatele sú oddelené. Tieto kapitoly a ich tabuľky sú prepojené z dôvodu, aby si OVM nastavilo ciele projektu a následne k nim v ďalšej tabuľke priradilo merateľné ukazovatele, na základe ktorých sa meria ich naplnenie.
nechápem, ako toto môže byť merateľný ukazovateľ projektu. Nesúvisí vôbec s projektom ako takým a je závislý čisto od faktorov, ktoré nie sú projektom ovplyvnené.
Všetky integrácie sú plánované napriamo? Prečo nevyužiť IS CPDI pre konzumáciu registrov, ktoré sú už na IS CPDI naintegrované?
IS ROM bude konzumovať služby, ktoré nie sú vypublikované na CPDI (napr. zmenové dávky IS RFO). Prostredníctvom IS CPDI budú konzumované služby napr. UPSVaR.
RFO? RA? Prečo nevyužiť už existujúce poskytovateľské integrácie?Postup na IS Centrálna platforma dátovej integrácie | Ministerstvo investícií, regionálneho rozvoja a informatizácie SR
IS ROM bude konzumovať služby, ktoré nie sú vypublikované na CPDI (napr. zmenové dávky IS RFO). Prostredníctvom IS CPDI budú konzumované služby napr. UPSVaR.
OK VYRIEŠENÉ
bolo by vhodné doplniť
tieto pomôcky je vhodné vymazať
OK VYRIEŠENÉ
v súčasnosti je prípravná a iniciačná fáza spolu
Metaúdaje k datasetom je potrebné katalogizovať na portáli otvorených dát data.slovensko.sk podľa aktuálneho metaúdajového štandardu DCAT AP-SK/resp. zároveň ku projektu vytvoriť lokálny katalóg otvorených dát, resp. OpenApi a tú/ten zaregistrovať na portál data.slovensko.sk
Anonymizovaný dataset reklamácií/sťažností? Štatistické údaje ku poskytnutej pomoci?
Považujeme za nerelevantný údaj.
Dáta je potrebné v rámci dátovej kvality stotožňovať a referencovať voči referenčným registrom, používať identifikátori ako IČO, identifikátor adresy, resp. fyzickej osoby, zaviesť biznis pravidlá/metodiku ku dátovej kvalite, obmedzenia pre dáta (hodnoty, formáty, rozsahy...) keďže sa plánuje zlučovanie dát z rôznych registrov a IS
Všetko čo sa dá refencovať bude referencované ako napr. adresa, R.Č. vo referenčným registrom.
Prosím o uvedenie priority a špecifického cieľa z Programu Slovensko
Priorita 2P1 - energetická efektívnosť a dekarbonizácia
Špecifický cieľ RSO2.3 - vývoj inteligentných energetických systémov, sietí a uskladnenia mimo Transeurópskej ener. siete (TEN-E)
Prosím uviesť aj do textu
na toto nie je KPI? automatizácia akých procesov? Neprinesie automatizácia urýchlenie procesov a úsporu času?
Uvedené v 3.4, 3.5 a 3.6
koľkým subjektom sa budú údaje poskytovať, resp. ak je to cieľ, nie je vhodné na to vytvoriť KPI napr. počet subjektov, ktorým sú poskytované anonymizované údaje?
Ide o otvorené a analytické údaje a počet konzumentov nie je možné momentálne určiť.
podľa informácií v projekte sú v projekte aj elektronické služby pre občana. Podľa § 8 vyhlášky 401/2023 Z. z. je potrebné zrealizovať používateľský prieskum už v prípravnej a iniciačnej fáze a spracovať z neho výsledky v projekte. Prebehol takýto prieskum?
Neprebehol, pretože elektronické služby sú nevyhnutné pre reklamačný proces.
Bez ohľadu na to, či sú služby nevyhnutné, platí:
Ak je súčasťou projektu alebo zmenovej požiadavky v prevádzke vytvorenie alebo zmena elektronickej služby s grafickým používateľským rozhraním slúžiacej koncovým používateľom, vytvorenie alebo zmena elektronickej služby s aplikačným rozhraním, spôsoby a postupy elektronizácie agendy verejnej správy podľa osobitného predpisu sú realizované v týchto projektových fázach, kde jedna je používateľský prieskum, ktorý je výstupom prípravnej a iniciačnej fázy projektu a predmetom ďalšieho spracovania v realizačnej fáze projektu. https://www.slov-lex.sk/ezbierky-fe/pravne-predpisy/SK/ZZ/2023/401/20231115#paragraf-8.nadpis
V opačnom prípade konštatujeme porušenie § 8 písm. a) vyhlášky MIRRI č. 401/2023 Z. z. o riadení projektov a zmenových požiadaviek v prevádzke informačných technológií verejnej správy v nadväznosti na § 24 ods. 2 zákona č. 95/2019 Z. z.o ITVS
prínosy prosím aj vysvetliť a popísať. V CBA sú akési údaje, ale nie sú vysvetlené. Na záložke parametre agendové sú pre jednotlivé moduly uvedené časy pre spracovanie (čas úradníka) a následne po implementácii projektu nie je nič - dôjde k automatizácii? Z čoho vyplývajú časy? Taktiež to vyzerá, že máte rovnaký prínos využitý pri viacerých moduloch a tiež prínosy začínajú plynúť ešte v čase realizácie projektu, čo nezodpovedá realite.
Áno výstupom je automatizácia a keďže výstupy projektu začnú byť dostupné v prvom roku a s cieľom porovnať voči AS/IS stavu, ktorý reprezentuje rovnaké množstvo podaní manuálne spracovaných tak sa uvádzajú pre prvý rok.
OK VYRIEŠENÉ
Prosím - podstatné - CBA, ktorú ste použili, ktorá bola zverejnená na QA stránke, nie je určená pre iné projekty okrem tých z výzvy 617, ktorá je už uzavretá. Prosím o použitie správnej CBA
správna:
CBA bola preklopená do správnej šablóny.
Vychádza vaša špecifikácia potrieb používateľa z používateľského prieskumu?
Nie, pretože elektronické služby sú nevyhnutné pre reklamačný proces.
V projektovom tíme absentuje pozícia UX dizajnér, ktorá má byť súčasťou projektového tímu podľa vyhlášky 401/2023 Z. z.. Kto vo vašom projekte zastreší oblasť UX?
Doplníme.
Absentuje legislatíva:
zákon o ITVS 95/2019 Z. z.,
vyhláška o elektronizácii agendy verejnej správy 547/2021 Z. z.,
vyhláška o o štandardoch pre informačné technológie verejnej správy 78/2020 Z. z.
Doplníme do kapitoly 4.
Váš projekt sa nachádza v realizačnej fáze, no podľa 401/2023 používateľský prieskum má byť súčasťou a výstupom prípravnej a iniciačnej fázy projektu. Prosím o zosúladenie.
Projekt sa nachádza v prípravnej a incializačnej fáze harmonogram bude aktualizovaný. Prieskum v realizačnej fáze je zameraný na testovanie UX.
Neuvažujete nad tým, že by ste šli v súlade s jednotným dizajnovým manuálom elektronických služieb a webových sídel - IDKS? https://idsk.gov.sk/co-je
Dielo bude v súlade s IDSK 3.0
tuto je to trochu inak popísané, ako sa spomínalo na úvodnom stretnutí k projektu. Tam bolo spomenuté, že legislatíva nie je rizikom, ale z tohto textu vyplýva celkom veľké riziko, ak by neexistoval právny základ na adresnú energo pomoc
Stále platí, že celý systém IS ROM môže byť vybudovaný na základe zákona č. 71/2025 Z.z. o poskytovaní údajov na účel adresnej pomoci. Zmienený odstavec len poukazuje na riziko, že nebudú definované legislatívne podmienky na vyplácanie energopomoci, čo však pri súčasnom stave rozpracovania legislatívy nepredpokladáme.
prosím len o skontrolovanie nahratia obrázkov v projekte, nakoľko ich nikde nevidíme.
Vyriešené.
Všeobecná pripomienka. Po úpravách v XWIKI je vždy potrebné aktualizovať verziu dokumentácie aj v MetaIS stlačením
čiže vznikajú tieto nové koncové služby pre občana - viete nám v texte popísať, na čo jednotlivé služby slúžia?
Zároveň v rámci názvov odporúčame pri tvorbe dodržiavať princípy § 26 v vyhlášky 78/2020 Z. z., ale aj z Príručky k MetaIS
Odporúčame teda použitie slovesného podstatného mena ako "podávanie sťažnosti..." alebo "Nahlasovanie zmeny údajov odberného miesta").
Taktiež z názvov by malo byť jasné, o čo ide. Napr. Udelenie adresnej pomoci je nešpecifické a je písané z pohľadu OVM, lebo OVM niečo udeľuje, ale občan o niečo žiada.
KS podporujú proces priznávania a reklamácií v rámci poskytovania energopomoci. Popis KS je v bode 3.6
nižšie popisujete 1 proces, ale vychádzajúc z prínosov aj koncových služieb pre občana, zmení sa toho na biznis úrovni teda dosť. Pýtam sa teda:
1. aké zmeny nastanú na biznis úrovni, ktoré spôsobia to, že sa ušetrí toľko času úradníka, koľko píšte v prínosovej časti CBA (Parametre agendové)?
2. čo celý projekt znamená pre občana - tu sa pýtam ako občan - čo bude vlastne výsledkom projektu ako celok, ako to budem môcť použiť? Čo to pre mňa znamená? Ako zistíte, či som vhodný kandidát pre energopomoc? Viete popísať v jednoduchosti celý proces/výsledok tohto projektu?
AS/IS proces znamená, že občania by dokumenty a žiadosti o adresnú pomoc museli nosiť na úrady. TO/BE stav znamená, že adresná energopomoc bude poskytovaná proaktívne, na základe existujúcich údajov z ISVS. V prípade nezrovnalostí môže občan podať reklamáciu.
v prípade, ak využívate spoločné moduly, resp. idete vytvárať na ne integrácie, prosíme o postup podľa Príručky k MetaIS kapitola 2.4
Áno budeme.
OK VYRIEŠENÉ
prosíme v texte o vyjadrenie k možnostiam použitia open source SW alebo krabicových riešení v projekte
Neexistuje komerčne dostupný SW, pre čiastkové moduly budú využité open source platformy.
prosíme o doplnenie k napĺňaniu NKIVS 2021 - ktorú prioritnú os a jej cieľ projekt napĺňa/prispieva k ich naplneniu
OS 2 Digitálna a dátová transformácia. 2.4 dobudovať digitálne prostredie založené na zdieľaní údajov vo VS
Prosím uviesť aj do textu projektu
táto časť je nevyplnená zo šablóny
Doplníme odsek 4.
V prípade nasadenia do privátnej časti vládneho cloudu v správe MVSR by mala byť namiesto "Infra_sluzba_6" služba "infra_sluzba_509".
Opravené.
Duplicita s Tabuľka 11. Navrhujem odstrániť.
Písané podľa šablóny je nutná zmena?
Potreba monitoringu je vždy. V Kat. požiadaviek máte požiadavku na integráciu na prevádzkový monitoring, tak prečo je tu len možnosť? Keď robíte takýto projekt, treba riešiť aj monitoring funkčnosti a dostupnosti systému a kvôli citlivosti spracovávaných dát aj bezpečnostný monitoring a integráciu na SIEM.
Uvedený komponent bude použitý aj pre aplikačný monitoring. Zmena bude zapracovaná v texte.
V katalógu požiadaviek máte síce odpovedajúce funkčné požiadavky ale kvôli sledovaniu realizácie KS si dajte k príslušným požiadavkám na realizáciu KS kódy METAIS aj do katalógu požiadaviek.
Bude doplnené.
Neplánujete obstarať žiadne licencie SW. V CBA máte uvedené licencie na Power BI. Tie ste neplánovali do rozpočtu zaradiť? Tieti licencie na Poer BI máte v CBA uvedené so zaradením do "A1 - Manažment osobných údajov" príčom v popise projektu píšete, že oblasť Mojich údajov (dát) nie je v projekte riešená. Zosúlaďte CBA, katalóg požiadaviek a popis projektu s textom I-02 Proj. zámer.
Aktualizujeme podľa upravenej CBA.
Nebudete potrebovať licencie na operačný systém alebo databázový systém, keďže v projekte uvažujete s vybudovaním DB clusterov. Plánujete všetok systémový SW riešiť len pomocou open source? Nebude potrebovať licencovať Oper. systém na HW? Privátny vládny cloud poskytuje len voľne dostupný Linux. V prípade, že by ste chceli použiť napr. RedHat alebo inú platenú distribúciu, bude ju musieť obstarať. Nepotrebujete si an takéto investície dať nejakú alokáciu finančných prostriedkov do rozpočtu?
OS budú IaaS v rámci VC a pre DB bude použitý open source.
Dáta do analytickej databázy (BI) by mali byť tiež anonymizované a pseudonymizované. Požiadavku máte v kat. požiadaviek.
Bude doplnené v kap 5.2.
Prosím vložiť obrázok a najlepšie aj odkaz do Architektonického modelu (názov pohľadu), ktorý ste nahrali a po úprave nahráte novú verziu do METAIS k proj. dokumentácii.
V náhľade celkovej architektúry uveďte pre dodávané komponenty evidované v METAIS aj ich kódy v názve komponentu napr. do zátvorky, aby vrcholový model a jeho hlavné dodávané komponenty odpovedali ich evidencii v METAIS.
Obrázok vložený. Prosíme zvážiť pridanú hodnotu zapracovania kódov META IS do obrázkov, pretože by obrázky boli neprehľadné (z dôvodu formátovania zobrazovaných reťazcov).
V architektoncikom modeli, ktorý ste nahrali uveďte pri plánovaných koncových službách aj kód služby v METAIS (napr. tak, že za názov služby dáte do zátvorky kód METAIS). Zosúlaďte model s evidecniou v METAIS minimálne na vrcholových pohľadoch na systém, kde sú uvedené eGovernement komponenty evidované v METAIS. Z názvu všetkých koncových služiev v modeli odstráňte zbytočný text "Životná situácia - " - zneprehľadňuje to model.
Modelovaný vzťah rola "Správca adresnej pomoci" je kompozíciou biznis rozhrania "Energoportál" je dosť divný. Dalo by sa síce nájsť vysvetlenie a interpretácia takéhoto vzťahu, ale asi ste skôr chceli povedať, že Energoportál buď slúži alebo je obsluhovaný pracovníkom MHSR v roli správca adresnej pomoci, nie? Týka sa to aj ďalších podobných vzťahov v modeli a náhľade biznis vrstvy. Taktiež odporúčam pre sprehľadnenie náhľadu usporiadať súvisiace komponenty k sebe do vrstiev (pracovníci, role, rozhrania, služby, biznis dáta).
Prosíme zvážiť pridanú hodnotu zapracovania kódov META IS do obrázkov, pretože by obrázky boli neprehľadné (z dôvodu formátovania zobrazovaných reťazcov).
Tak ako steto uviedli pre niektoré z ISVS, aj pre ostatné integrované ISVS treba uviesť ich METAIS kódy.
API odberné miesta nie je vhodný názov pre aplikačnú službu. Pozrite príručku METAIS s usmernením pre názov koncových služieb a podobný vzor treba použiť aj pre aplikačné služby. API je rozhranie, nie služba. Pre KS ks_381391, ks_381392, ks_381393 by vhodným názvom AS bolo napr. "Evidovanie (alebo aj "Evidencia") odberných miest".
Pre ks_381389 a tiež aj pre ks_381390 a ks_381386 aplikačná služba s názvom "Poskytnutie údajov o adresnej pomoci" pre zisťovaciu časť procesu. Pre spracovanie žiadostí a sťažností (ks_381387, ks_381388, ks_381390) napr. aplikačná služba "Spracovanie žiadostí". Pre generovanie šekov s adresnou pomocou aplikačnej služby "Generovanie (výpočet) dát adresnej pomoci". Lepšie poznáte problematiku a tak môžete prpraviť lepšie názvy aplikčných služieb. pripomínam tiež, že jedna aplikačná služba (AS) môže slúžiť viacerým KS a žiadna KS by namala byť bez aspoň jednej obsluhujúcej AS. Doplňte a opravte tiež evidenciu v METAIS (nezmyselné viacnásobné evidovanie aplik. služieb s rovnakým názvom eGov API, "API Odberné miesta") Do tejto tabuľky v dokumente I-02 doplňte kódy METAIS aplikačných služieb.
Trváme na pôvodnom názvosloví.
Podľa inštrukcií v príručke METAIS, kap. 2.4, doplňte aj AS pre integráciu s modulom otvorené údaje.
Doplníme
Tu má byť uvedený kód a názov aplikčnej služby, ktorá realizuje integráciu na strane konzumenta služby spoločného modulu a nie kód modulu poskytujúceho službu. V poslednom stĺpci má byť uvedená služba (služba spol. modulu), na ktorú bude AS uvedená v prvom stĺpci integrovaná.
Doplníme
Dajte si túto požiadavku aj do katalógu požiadaviek.
Doplníme
Uveďte si požiadavku na dodávku Bezpečnostného projektu aj do Katalógu požiadaviek. A taktiež do požiadavky doplňte, že v dodávanom systéme budú aplikované opatrenia identifikované bezpečnostným projektom a že bezpečnostný projekt bude priebežne počas projektu altualizovaný podľa skutočnej realizácie a nasadenia systému.
Doplníme
Požiadavku na konkrétnu úroveň dostupnosti si dajte aj do katalógu požiadaviek. Taktiež s do katalógu dajte požiadavku na parametre RTO a RPO. Z katalógu požiadaviek odstráňte zbytočné duplicitné nekonkretizované požiadavky na zálohovanie a dostupnosť pre jednotlivé podmoduly. Buď k nim uveďte konkrétne parametre, alebo ich vyriešte jednou spoločnou požiadavkou. Nepotrebujete nafukovať počet požiadaviek zbytočnými duplicitami.
Upravíme
Chýbajúce obrázky nižšie pre znázornenie uvedených procesov: Overenie získania energopomoci, Podanie sťažnosti pre nezískanie energopomoci, Podanie sťažnosti o nesprávnej energopomoci, Žiadosť o vylúčenie z energopomoci
Doplnené
V arch. modeli (súbor rom 1.archimate) máte pekný obrázok plánovaného nasadenia s názvom "Architektúra". Môžete ho tu uviesť. V modeli mu ale zmeňte názov, lebo je to skôr náhľad plánovaného nasadenia systému ako všeobecný názov "Architektúra"
Zapracujeme
Pre overovanie stíhania budete asi potrebovať nejakú aplikačnú službu pre Lustrácie, lebo asi tieto dáta Vám MVSR neposkytne hromadne. Pre overenie registra trestov zvážte použitie IS CPDI namiesto priamej integrácie na Gen. prokuratúru.
Očakávame AS pre Lustrácie.
V prípade GP SR zvážime, v prípade dostupnosti využijeme IS CPDI.
Pre potenciálnu integráciu systémov, ktoré používajú plánované pracoviská spolupracujúcich OVM (úrady práce, Slov. pošta, CallCentrum MVSR, atď.) budete asi potrebovať samostatnú sadu služieb pre takúto integráciu, ak tieto orgány budú chcieť implementovať vlastné používateľské rozhranie do svjich systémov namiesto použitia web rozhrania systému ROM pre sprostredkovateľov energopomoci.
Toto bude definované v štádiu analýzy a návrhu.
V biznis architektúre vám chýba aktér pracovník sprostredkovania energopomoci a príslušná rola a distribučný kanál ( napr. nejaká špecializovaná podčasť Energoportálu alebo API pre integráciu systému sprostredkovateľa pomoci) a tomu odpovedajúca aplikačné časti - web rozhranie a API pre integráciu sprstredkovateľov pomoci.
Neočakávame využívanie sprostredkovateľov.
Dajte si do katalógu požiadaviek požiadavku na to, že Vám má dodávateľ dodať dokumentáciu systému podľa vyhlášky 401/2023.
Doplníme
Dajte si do katalógu požiadaviek, že vám má dodávateľ dodať návrh testovacích scenárov pre otestovanie plnej funkčnosti dodávaného systému a tiež že má podľa definovaných scenárov vykonať a protokolárne zdokladovať automatizované otestovanie funkčnosti systému podľa navrhnutých testovacích scenárov.
Doplníme
V modeli a obrázku aplikačnej architektúry uveďte aj METAIS kódy znázornených ISVS, ich modulov a tiež aplikačných služieb (napr. do zátvorky k názve komponentu). Plánované podmoduly systému ROM radšej modelujte ako funkčné bloky, ak nebudú samostatne nasadzované a evidované v METAIS ako podmoduly. Samostatne nasadzované podmoduly, ako je napr. web portál, analytický systém, samostatnú integračnú platformu by bolo lepšie uviesť ako podmoduly systému ROM a zaevidovať ich tiež v METAIS buď ako podmoduly systému ROM alebo ako súčasne dodávané systémy v tomto projekte.
Prosíme zvážiť pridanú hodnotu zapracovania kódov META IS do obrázkov, pretože by obrázky boli neprehľadné (z dôvodu formátovania zobrazovaných reťazcov).
CBA:
1. záložka moduly CBA - pre moduly 17 až 20 máte zle nastavené productivity faktory, ktoré ponúkajú možnosti len 15, 20, 25 a 30. Tu to dotiahol excel nejak chbyne, prosíme opraviť
2. záložka UAW - prosím, vysvetlite používateľov:
3 typy používateľov typu občan
3 typy používateľov typu zamestnanec inštitúcie verejnej správy
11 systémov verejnej správy - tu je aj zle nastavená zložitosť (má byť 2 alebo 1 podľa Metodiky k CBA - 1 = používateľ je systém s definovaným aplikačným programovým rozhraním, 2 = systém interagujúci prostredníctvom protokolu (napr. Transmission control protocol/Internet protocol)
4 isvs mimo verejnej správy - tiež je tu zle nastavená zložitosť
3. v celej CBA pravdepodobne nie je aktualizovaná sadzba DPH na 23% - vyriešite vyplnením správnej CBA
4. ak financujete projekt z Programu Slovensko , tak na záložke pozície interné v CBA v bunke Q2 nepoužívate odmeny - tie sú zahrnuté v sadzbách
5. prínosy na záložke Parametre agendové sa vám rátajú od 1. roku, ale v realite nastanú v podstate až v roku 3.
6. záložka ECF - tu ste zadávali hodnoty? Všade sú 1ky.
7. záložka Pozície interné - v prípade projektov z Programu Slovensko sa neuplatňujú odmeny - bunka Q2
8. nie je vyplnená záložka Zdroje financovania
CBA je v štádiu prerábky do nového formuláru a požiadavky zapracujeme.
uvedené ID/názvy cieľov nezodpovedajú tým, čo ste si nastavili. Vyzerá to tak, že ciele a ukazovatele sú oddelené. Tieto kapitoly a ich tabuľky sú prepojené z dôvodu, aby si OVM nastavilo ciele projektu a následne k nim v ďalšej tabuľke priradilo merateľné ukazovatele, na základe ktorých sa meria ich naplnenie.
nechápem, ako toto môže byť merateľný ukazovateľ projektu. Nesúvisí vôbec s projektom ako takým a je závislý čisto od faktorov, ktoré nie sú projektom ovplyvnené.