Smlouva o poskytování služeb Portálového systému SZIF a Portálové aplikace pro Monitoring Approach (Portálový systém SZIF)

















Smlouva o poskytování služeb Portálového systému SZIF a Portálové aplikace pro Monitoring Approach (Portálový systém SZIF)

PŘÍLOHA Č. 1



Závazné implementační, funkční a technické požadavky na dodávku Díla

1Předmět veřejné zakázky – Díla

1.1Specifikace předmětu - Díla

Předmětem Smlouvy jsou:

  • Služby zajištění provozu a rozvoje nového Portálového systému SZIF a Portálových aplikací XXXX (dále jen „Systém“) v cloudové infrastruktuře Poskytovatele či třetí strany nebo infrastruktuře obdobné v souladu s parametry a požadavky uvedenými v této specifikaci a Katalogových listech služby, Maintenance licencí a Exit

  • Dílo v podobě návrhu, implementace a nasazení Systému skládajícího se z:

    • Portálového systému SZIF,

    • Portálových aplikací XXXX

v podobě řešení vybudovaného s využitím cloudových technologií zajišťujících budoucí přenositelnost Systému mezi prostředími různých poskytovatelů služeb provozu a rozvoje. Jako standard pro návrh a výstavbu Systému byly zvoleny aktuálně nejvyužívanější cloudové technologie umožňující mimo jiné provoz Systému v infrastruktuře veřejných či privátních cloudů. Požadavky na návrh a výstavbu Systému jsou uvedeny v Technické dokumentaci – Příloha č. 5 zadávací dokumentace. Systém bude provozován v cloudové anebo obdobné infrastruktuře Poskytovatele či třetí strany s využitím cloudových služeb.

Tento dokument specifikuje závazné implementační, funkční a technické požadavky na Dílo. Specifikace požadavků na Služby je předmětem samostatného dokumentu Technické dokumentaci – Příloha č. 5 zadávací dokumentace a Přílohy č. 3 Smlouvy.

Předmětem Díla je návrh, implementace a nasazení Systému tak, aby jeho prostřednictvím bylo možné poskytovat Službu tvořící druhou dílčí část předmětu Smlouvy. Součástí Díla jsou dále další výstupy a plnění uvedené v této kapitole.

Objednatel požaduje poskytnutí Systému ve formě služby zahrnující provoz Systému v cloudové infrastruktuře Poskytovatele anebo třetí strany či obdobné. Systém však bude zahrnovat specifické funkcionality vyvinuté na míru pro Objednatele dle požadavků uvedených v této specifikaci a zejména v zadání pro implementaci Portálových aplikací XXXX. Tyto funkcionality jsou specifické pro agendy Objednatele a jejich vývoj představuje z pohledu Objednatele investici, pro kterou musí nezbytně zajistit dlouhodobou udržitelnost. Z těchto důvodů Objednatel požaduje, aby byl Systém navržen a implementován s využitím takových technologií, aby všechny části Systému, které nejsou konzumovány jako cloud služba, bylo možné bez problémů migrovat k jinému poskytovateli cloudových služeb anebo přenést do on-premise infrastruktury Objednatele. Z těchto důvodů je mimo jiné požadováno, aby byly části Systému, které nebudou konzumovány jako cloudová služba, vybudovány s využitím kontejnerizace podporované většinou poskytovatelů cloudových služeb založené na kontejnerizačních a orchestračních technologiích podporovaných hlavními veřejnými a privátními poskytovateli cloudových služeb. Veškeré případné serverless funkcionality musí být implementovány využitím standardních jazyků v souladu s požadavky uvedenými v Technické dokumentaci – Příloha č. 5 zadávací dokumentace. Objednatel se dle příslušných ujednání Smlouvy stává držitelem neomezené nevýhradní licence ke všem částem Systému implementovaných na míru dle požadavků Objednatele a Objednatel bude zároveň disponovat užívacím právem pro všechny licence potřebné k vybudování a provozu Systému.

Dílo zahrnuje dodávku licencí vč. maintenance do doby zahájení Služeb provozu.

Implementace Systému zahrnuje další dílčí položky předmětu veřejné zakázky, přičemž specifikace položek předmětu je uvedena v Technické dokumentaci – Příloha č. 5 zadávací dokumentace:

Analytická a přípravná fáze Implementace:

  • Analýza prostředí SZIF a požadavků na výstavbu systému.

  • Součinnost a spolupráce při návrhu řešení a přípravě zadání Portálových aplikací XXXX.

  • Analýza zadání Portálových aplikací XXXX.

  • Detailní návrh řešení Portálového systému a Portálových aplikací XXXX.

  • Příprava cloudových služeb pro provoz Systému.

Fáze vlastní Implementace Díla (Systému):

  • Implementace Portálového systému SZIF (části Systému).

  • Implementace Portálových aplikací XXXX (části Systému).

  • Zabezpečení Systému a zajištění kontinuity provozu.

  • Testování Systému.

  • Dokumentace Systému

  • Školení Systému

Součástí Díla je též Pilotní provoz a akceptační provoz.

1.2Požadavky na řešení Systému

V této kapitole je popsána obecná podoba architektury Systému.

Portálový systém SZIF (dále také zkráceně „PORSYS“) představuje univerzální portálový framework (řešení/technologie) umožňující postupně budovat portálové aplikace Objednatele. Portálový systém SZIF nabízí sadu sdílených komponent a služeb, díky nimž je možné opakovaně využívat již jednou vytvořené funkcionality a budovat tak nové portálové aplikace efektivněji a rychleji. Základní logická architektura řešení Systému zahrnující komponentu Portálového systému SZIF je znázorněna na obrázku Obrázek 1 - Základní logická architektura Systému.

Obrázek 1 - Základní logická architektura Systému

Portálový systém SZIF je budován jako jednotné prostředí umožňující postupně implementovat jednotlivé portálové aplikace Objednatele. Součástí předmětu Xxxxxxx je návrh a výstavba prvních portálových aplikací - Portálových aplikací XXXX (dále také zkráceně „PORMACH“). Portálový systém SZIF zahrnuje několik základních logických dále uvedených komponent poskytujících sdílené funkcionality a služby pro portálové aplikace.

Kalendář

Sdílená komponenta Portálového systému SZIF. Komponenta poskytuje klientům funkcionality kalendáře, kam mohou přidávat své vlastní události, a do které je možné manuálně či automatizovaně přidávat události ze strany Objednatele. Komponenta pro automatickou správu událostí poskytuje API v podobě webových služeb publikovaných na integrační platformě XXXX (pro interní systémy) a SAP PO pro externí systémy.

Novinky

Sdílená komponenta Portálového systému SZIF. Komponenta představuje část uživatelské aplikace poskytující informace o novinkách. Součástí funkcionalit je přihlášení a odhlášení odběru novinek, kdy je výskyt novinek notifikován využitím služeb Notifikátoru. Komponenta pro automatickou správu novinek poskytuje API v podobě webových služeb publikovaných na integrační platformě XXXX (pro interní systémy) a zároveň SAP PO pro externí systémy. Notifikátor např. zasílá uživateli notifikaci v okamžiku, kdy je do jeho profilu vložena nějaká nová informace, dojde ke změně stavu administrace (průchodu procesem), nebo dojde ke změně evidovaných dat – nový dokument, úkol, výstraha.

Notifikátor

Sdílená komponenta Portálového systému SZIF zajišťující odesílání všech typů notifikací. Komponenta zahrnuje rozhraní uživatele pro nastavení notifikací. Notifikace oznamují uživateli výskyt události a jsou prezentovány ve společném pohledu v Portálovém systému SZIF. V případě XXXX jsou notifikace generovány zejména při výskytu alertu XXXX, tedy v případě porušení dotačních podmínek, upozornění na blížící se rozhodné lhůty, ale i konfigurovatelné notifikace o novinkách a výzvách ke spolupráci.

Generování alertu/události je realizováno na straně portálové aplikace, která dle pravidel definovaných v nastavení portálové aplikace pro uživatele, volá Notifikátor pro založení notifikací.

Komponenta Notifikátor obsahuje uživatelské rozhraní umožňující uživatelům nastavit preference notifikací zahrnující:

  • jaké notifikace odesílat,

  • v jakých časových oknech notifikace odesílat,

  • jakými kanály notifikace odesílat,

  • jak notifikace seskupovat (např. seskupit všechny notifikace za poslední 2h do jedné informační zprávy).

Součástí výstupu je i vybudování notifikačních kanálu v podobě emailových notifikací a notifikací prostřednictvím mobilní aplikace.

Grafy a reporty

Sdílená komponenta Portálového systému SZIF. Komponenta umožňující do libovolné části portálové aplikace vložit graf či tabulkový report. Graf či report vykreslují předaná data.

Úložiště a sdílení dokumentů a souborů

Sdílená komponenta Portálového systému SZIF. Komponenta zajišťující publikaci souborů klientům veřejné správy a zároveň i příjem souborů od klientů veřejné správy. Komponenta je napojena na antivirový systém tak, aby všechny publikované a nahrávané soubory mohly procházet antivirovou kontrolou.

SSO autentizace, autorizace a řízení přístupu k obsahu

Sdílená komponenta Portálového systému SZIF. Komponenta zajišťuje funkcionality komunikace s autentizačními a autorizačními systémy Objednatele. Komponenta je odpovědná za přidělení správného oprávnění přistupujícímu uživateli. Prostřednictvím rozhraní komponenty je možné spravovat role a související oprávnění k portálovým aplikacím a obsahu portálu, nebudou-li tyto řízeny integrovanými bezpečnostními systémy Objednatele. Komponenta zároveň obsahuje funkcionalitu napojení na systémy jednotného přihlášení SSO Objednatele, které budou integrovány na Národní bod identifikačních a autentizačních služeb (NIA) a v případě potřeby i Jednotný identitní prostor a Katalog autentizačních a autorizačních služeb (JIP/XXXX). Centrální autentizační systém Objednatele a IDM Objednatele budou zajišťovat i přístup ke službám NIA.

Součástí předmětu Smlouvy je dále vytvoření systému jednotného přihlášení mezi novým Portálovým systémem a existujícím portálem SAP.

Fulltext vyhledávání a indexace

Sdílená komponenta Portálového systému SZIF. Komponenta zajišťuje indexaci obsahu a poskytuje sdílené vyhledávací funkce v obsahu portálu.

Auditování a auditní log

Sdílená komponenta Portálového systému SZIF. Komponenta zajišťující logování/auditování všech významných operací či událostí v systému a jednotlivých portálových aplikacích. Auditní informace jsou přístupné oprávněným uživatelům webové administrátorské aplikace Portálového systému SZIF.

Uživatelské profily, preference a konfigurace

Sdílená komponenta Portálového systému SZIF. Komponenta zajišťuje správu uživatelských profilů, preferencí a konfigurací a poskytuje rozhraní pro uživatele určené pro editaci profilů, preferencí a konfigurací.

Do profilu jsou při přístupu klienta přenášeny základní informace o identitě klienta z IDM/IAM Objednatele.

Zasílání zpráv (chat)

Součástí sdílených funkcionalit Portálového systému SZIF bude komunikační modul pro komunikaci s klienty veřejné správy prostřednictvím rychlých zpráv (chat). Pro zasílání zpráv je požadováno anebo platí:

  • funkcionalita a vzhled bude obdobná standardním veřejně provozovaným chat prostředím,

  • při přístupu k Portálovému systému SZIF bude klientovi proaktivně nabídnuta možnost chatu s pracovníkem SZIF (nabídka rady a pomoci),

  • zprávy v chatu budou organizovány do vláken, přičemž vlákna se mohou vztahovat ke konkrétním entitám v portálových aplikacích (např. vlákno chatu ke konkrétnímu důkaznímu podkladu v PORMACH, či konkrétní AP v PORMACH),

  • zprávy chatu budou archivovány s možností zobrazení celé historie chatu klientovi veřejné správy i pracovníkovi Objednatele,

  • řešení bude umožňovat na straně Objednatele převzít komunikaci v chatu mezi pracovníky Objednatele (např. z důvodů dovolené či jiné pracovní nepřítomnosti).

Statistiky přístupů a využití portálu

Sdílená komponenta Portálového systému SZIF. Komponenta zajišťuje sledování přístupů k Portálovému systému SZIF jako celku, jednotlivým aplikacím a částem aplikací. Informace o přístupech ve formě statistik publikuje pro následný reporting.

Redakční systém

Sdílená komponenta Portálového systému SZIF. Komponenta poskytuje rozhraní a funkcionality pro správu obsahu informační části portálu. Součástí funkcionalit jsou i procesy revize, schvalování a publikace obsahu.

Systémová konfigurace a nastavení

Sdílená komponenta Portálového systému SZIF. Komponenta zajišťuje systémové nastavení a konfiguraci portálu. Konfigurace a nastavení jsou spravovány prostřednictvím webové systémové administrátorské aplikace.

Webová systémová administrátorská aplikace

Sdílená komponenta Portálového systému SZIF. Webová aplikace určená pro oprávněné uživatele Objednatele či administrátory Objednatele. Aplikace umožňuje technicky spravovat celé řešení Portálového systému SZIF a parametry jednotlivých implementovaných portálových aplikací.

GUI framework a komponenty

Sdílená komponenta/framework Portálového systému SZIF. Komponenta poskytuje sdílené prvky grafického uživatelského rozhraní, skripty, kaskádové styly, statické zdroje (obrázky atd.) a jiné sdílené prvky využitelné pro výstavbu portálových aplikací, případně jinou podobu stavebních prvků a funkcionalit využitím kterých je možné budovat hostované portálové aplikace. Hlavní úlohou frameworku je zajistit, že všechny portálové aplikace budované v Portálovém systému SZIF budou navrženy a implementovány maximálně efektivně a budou disponovat jednotným vzhledem a shodnými ovládací prvky a ergonomií obsluhy.

Portálový systém SZIF a v něm implementované Portálové aplikace XXXX budou komunikovat s řadou systémů. Přehled komunikace a datových toků při pohledu na celé řešení a jeho začlení do prostředí Objednatele, jsou znázorněny na obrázku Obrázek 2 – Datové toky a výměna informací mezi systémy.

Obrázek 2 – Datové toky a výměna informací mezi systémy

Za účelem potřebné komunikace mezi systémy jsou dle požadavků Objednatele systémy integrovány využitím jasně definovaných a volně vázaných rozhraní. Přehled integrace systémů a využitých rozhraní je znázorněn na obrázku Obrázek 3 - Řešení integrace jednotlivých systémů.



Obrázek 3 - Řešení integrace jednotlivých systémů

Portálové řešení SZIF musí dále naplňovat následující požadavky:

  • Podpora federace portálů:

    • Možnost začlenit portál a portálové aplikace do nadřazených střechových portálů veřejné správy ČR, resp. podpora jednotného přihlášení prostřednictvím SAML2 a odkazování konkrétních částí portálových aplikací ze střechových portálů,

    • Podpora odkazování externího obsahu v prostředí Objednatele s přechodem k externímu obsahu a návratem z externího obsahu zpět na Portálový systém SZIF využitím systému jednotného přihlášení (uživatel nemusí opakovaně zadávat přihlašovací informace),

    • Podpora začlenění externího obsahu Objednatele do prezentace publikované v Portálovém systému SZIF (např. portlety, iframe, AJAX API) s využitím systému jednotného přihlášení (příklad – integrace obrazovek jiných webových aplikací Objednatele – Portálu farmáře do nového Portálového systému),

  • Auditování přístupů uživatelů:

    • Záznam informací o přistupujících uživatelích do Portálového systému SZIF obsahující zejména:

      • Login přistupujícího uživatele,

      • Datum a čas přihlášení do systému, datum a čas odhlášení ze systému,

      • IP adresa přistupujícího uživatele,

      • Detekovaný prohlížeč a informace o klientovi z hlavičky User-Agent,

    • Generování přehledu/reportu se seznamem uživatelů, kteří ve zvoleném období přistoupili k Portálovému systému SZIF,

    • Možnost zobrazení přehledu aktuálně přihlášených uživatelů (pouze oprávněné role).

  • Auditování dalších operací v systému (např. operace s dokumenty, správami atd.).

Portálové aplikace XXXX

Portálové aplikace XXXX (PORMACH) jsou prvními portálovými aplikacemi implementovanými v rámci předmětu Smlouvy využitím Portálového systému SZIF (PORSYS). Aplikace představují uživatelské rozhraní IS XXXX (Kontroly podmínek opatření využitím satelitního monitoringu a geotagovaných fotografií).

Portálové aplikace XXXX tvoří dvě samostatné aplikace:

  • Portálová aplikace XXXX pro žadatele - aplikace pro klienty veřejné správy/žadatelé poskytuje komunikační kanál umožňující žadatelům (klientům veřejné správy) komunikovat v průběhu administrace jednotných žádostí a monitoringu podmínek opatření (dotačních titulů) se zaměstnanci Objednatele. Zároveň aplikace proaktivně informuje a notifikuje žadatele.

  • Portálová aplikace XXXX pro SZIF - samostatná aplikace pro zaměstnance Objednatele, mimo jiné i pro terénní inspektory Objednatele, kteří jejím prostřednictvím spravují data XXXX. Pracovníci Objednatele, typicky inspektoři, pro přístup k aplikaci v terénu využívají mobilní zařízení. Aplikace a celý Portálový systém SZIF tak musí poskytovat responzivní design. Aplikace je zároveň využita pro správu nastavení a informací v IS XXXX ze strany zaměstnanců Objednatele či kooperujících organizací.

Obě portálové aplikace přistupují k datům a funkcionalitám IS XXXX prostřednictvím API publikovaného na Integrační platformě IS XXXX. Systém tedy bude přistupovat k datům využitím datového propojení mezi cloudovým prostředím Poskytovatele či třetí strany a lokalitou datového centra Objednatele. Uvedenému faktu musí odpovídat i zvolené řešení síťové konektivity mezi cloudovým prostředím a lokalitou Objednatele tak, aby bylo možné zabezpečit požadované objemné přenosy dat při naplnění požadavků na dostupnost a výkonnost Systému uvedených v Příloze č. 3 Smlouvy.

Obrázek 4 - Blokové schéma PORMACH a integrace na IS XXXX

PORMACH představuje čistě rozhraní k funkcionalitám implementovaným v IS XXXX. Veškerá business logika a funkcionality budou implementovány na straně IS XXXX a PORMACH konzumovány využitím výše uvedeného rozhraní. V PORMACH bude implementováno uživatelské rozhraní a logika samotných portálových aplikací zahrnující navigace mezi jednotlivými částmi aplikace, spouštění akcí atd.

Při návrhu řešení a architektury Systému musí být zohledněny základní architektonické principy a cíle eGovenmentu ČR dokumentované v Informační koncepci ČR. Dokument informační koncepce je publikován na adrese:

xxxxx://xxxxx.xxx.xx/xxxx?x[]xxxxxxxx%X0%0Xx%X0%XX%0X&x[]xxxxxxxxx%0X

Návrh řešení Systému musí dále být v souladu s následujícími požadavky a principy:

  • kontejnerizace všech částí Systému vyvinutých v rámci projektu za účelem poskytování služby, které nejsou poskytovány ve formě cloudových služeb,

  • řešení umožňuje provoz v cloudovém prostředí s podporou kontejnerizačních a orchestračních technologií podporovaných hlavními poskytovateli veřejných a privátních cloudových služeb,

  • řešení umožňuje jednoduché a bezproblémové migrace řešení a služeb k jinému poskytovateli služeb s minimální potřebou změn a zásahů do služeb,

  • využití otevřených technologií a standardů (jako jsou HTML 5, SOAP, REST, GraphQL),

  • autentizace a autorizace uživatelů využitím centrálních služeb Objednatele,

  • auditování a logování všech klíčových operací,

  • responzivní design umožňující plnohodnotnou práci s portálem a portálovými aplikacemi nejenom na počítačích a pracovních stanicích, ale i s využitím mobilních zařízení, jako jsou tablety a chytré mobilní telefony.

Systém bude dále vybudován v souladu se standardy a legislativními předpisy uvedenými v tomto dokumentu. Dále v této kapitole jsou uvedeny obecné standardy Objednatele vztahující se k provozu informačních systémů a řízení služeb a dále specifické standardy vztahující se k problematice poskytování dotací a kontrol plnění podmínek dotací.

1.2.1Standardy

Objednatel je certifikován dle ISO/IEC 27001:2013 a ISO/IEC 20000-1:2011 a tedy každé řešení, které pořizuje, musí umožnit dodržení těchto standardů.

Tabulka 1 - Přehled standardů vztahujících se k předmětu veřejné zakázky

Ref.

Text

ISO/IEC 27001:2013 včetně certifikace pro všechny oblasti ISMS i působnost Fondu (Objednatel) jako platební agentury

ISO/IEC 20000-1:2011; ITIL – management IT služeb

IS č.1/2019 Politika bezpečnosti informací, kapitola 6.7.2. Cloud computing – využívání cloudových služeb

OGC standardy

Souhrn odpovědí EK k výkladu nařízení 809/2014 v dokumentu „Q&A on monitoring for claim years 2018 and 2019“ Ares(2018)4341814 - xxxxx://xxxxxxxx.xxx.xx.xxxxxx.xx/xxxxxxx/xxxxxx/0/00/XxxxxxxxxxXXXX0000xxxxxxxxxx.xxx

Souhrn odpovědí EK k výkladu nařízení 809/2014 v dokumentu DS/CDP/2019/01

JRC Technical report DS/CDP/2017/03 definující principy systematického monitoringu zemědělské aktivity s využitím konceptu markerů.

JRC Technical report DS/CDP/2018/17 definující doporučené rozhodovací postupy pro náhradu kontrol na místě kontrolami pomocí monitoringu.

1.2.2Legislativní požadavky a strategické dokumenty

Níže uvedená tabulka informuje o legislativních dokumentech, kterými se řešení řídí.

Tabulka 2 - Přehled legislativních požadavků a strategických dokumentů souvisejících s předmětem zakázky

Ref.

Text

Poznámka

Nařízení Evropského parlamentu a Rady (EU) č. 1306/2013 ze dne 17. prosince 2013 o financování, řízení a sledování společné zemědělské politiky.


Prováděcí nařízení komise (EU) č. 809/2014 ze dne 17. 6. 2014, kterým se stanoví prováděcí pravidla k nařízení Evropského parlamentu a Rady (EU) č. 1306/2013, pokud jde o integrovaný administrativní a kontrolní systém, opatření pro rozvoj venkova a podmíněnost.


Nařízení Komise v přenesené pravomoci (EU) č. 907/2014 ze dne 11. března 2014, kterým se doplňuje nařízení Evropského parlamentu a Rady (EU) č. 1306/2013, pokud jde o platební agentury a další subjekty, finanční řízení, schválení účetní závěrky, jistoty a použití eura.


Prováděcí nařízení komise (EU) č. 908/2014 ze dne 6. července 2014, kterým se stanoví pravidla pro uplatňování nařízení Evropského parlamentu a Rady (EU) č. 1306/2013, pokud jde o platební agentury a další subjekty, finanční řízení, schvalování účetní závěrky, pravidla pro kontroly, jistoty a transparentnost.


Nařízení Evropského parlamentu a Rady (EU) 2019/881 ze dne 17. 4. 2019 o agentuře ENISA („Agentuře EU pro kybernetickou bezpečnost“) o certifikaci kybernetické bezpečnosti ICT a o zrušení nařízení (EU) č. 526/2013 („akt o kybernetické bezpečnosti“)


Nařízení Evropského parlamentu a Rady (EU) 2016/679 ze dne 27. dubna 2016 o ochraně fyzických osob v souvislosti se zpracováním osobních údajů a o volném pohybu těchto údajů a o zrušení směrnice 95/46/ES (obecné nařízení o ochraně osobních údajů – GDPR) ve znění pozdějších předpisů


Nařízení Evropského parlamentu a Rady (EU) 910/2014 v platném znění (EIDAS)


Návrh nařízení Evropského parlamentu a Rady (EU), kterým se stanoví pravidla podpory pro strategické plány, jež mají být vypracovány členskými státy v rámci společné zemědělské politiky (strategické plány SZP) a financovány Evropským zemědělským záručním fondem (EZZF) a Evropským zemědělským fondem pro rozvoj venkova (EZFRV) 2018/0216(COD).


Zákon č. 252/1997 Sb., o zemědělství, ve znění pozdějších předpisů


Zákon č. 256/2000 Sb., o Státním zemědělském intervenčním fondu, ve znění pozdějších předpisů


Zákon č. 500/2004 Sb., správní řád, ve znění pozdějších předpisů


Zákon č. 255/2012 Sb., o kontrole (kontrolní řád), ve znění pozdějších předpisů


Zákon č. 320/2001 Sb., o finanční kontrole, ve znění pozdějších předpisů


zákon č. 182/2006 Sb., o úpadku a způsobech jeho řešení (insolvenční zákon), ve znění pozdějších předpisů


Zákon č. 110/2019 Sb., o zpracování osobních údajů


Zákon č. 297/2016 Sb., o službách vytvářející důvěru pro elektronické transakce, ve znění pozdějších předpisů


Zákon č. 250/2017 Sb., o elektronické identifikaci, ve znění pozdějších předpisů


Zákon č. 12/2000 Sb., o právu na digitální služby, ve znění pozdějších předpisů


Zákon č. 365/2000 Sb., o informačních systémech veřejné správy a o změně některých dalších zákonů, ve znění pozdějších předpisů a jeho prováděcí vyhlášky


Zákon č. 300/2008 Sb., o elektronických úkonech a autorizované konverzi dokumentů ve znění pozdějších předpisů


Zákon č. 301/2008 Sb., kterým se mění některé zákony v souvislosti s přijetím zákona o elektronických úkonech a autorizované konverzi dokumentů, ve znění pozdějších předpisů


Zákon č. 181/2014 Sb., o kybernetické bezpečnosti a o změně souvisejících zákonů, ve znění pozdějších předpisů (ZOKB)


Zákon č. 106/1999 Sb., o svobodném přístupu k informacím, ve znění pozdějších předpisů


Zákon č. 12/2020 Sb., o právu na digitální služby a o změně některých zákonů, ve znění pozdějších předpisů


zákon č. 499/2004 Sb., o archivnictví a spisové službě, ve znění pozdějších předpisů


Nařízení vlády č. 307/2014 Sb., o stanovení podrobností evidence využití půdy podle uživatelských vztahů, ve znění pozdějších předpisů


Vyhláška č. 53/2007 Sb., o technických a funkčních náležitostech uskutečňování vazeb mezi informačními systémy veřejné správy prostřednictvím referenčního rozhraní (vyhláška o referenčním rozhraní)


Vyhláška č. 82/2018 Sb., o bezpečnostních opatřeních, kybernetických bezpečnostních incidentech, reaktivních opatřeních, náležitostech podání v oblasti kybernetické bezpečnosti a likvidaci dat, ve znění pozdějších předpisů (VOKB)


Vyhláška č. 317/2014 Sb. o významných informačních systémech a jejich určujících kritériích, ve znění pozdějších předpisů


Strategický plán SZP ČR definující podmínky způsobilosti intervencí ze, respektive nařízení vlády definující podmínky způsobilosti jednotlivých opatření (Nařízení vlády č. 43/2018 Sb., Nařízení vlády č. 50/2015 Sb., Nařízení vlády č. 75/2015 Sb., Nařízení vlády č. 76/2015 Sb.).


Program Digitální Česko; Informační koncepce ČR (dále IK ČR)


Akční plán EU pro eGovernment na období 2016-2020


ePrivaci EU - nařízení o respektování soukromého života a ochrany osobních údajů v elektronických komunikacích jak fyzických osob, tak právnických osob (ekvivalent listovního tajemství).



1.3 Minimální technické požadavky na realizaci Díla (Systému)

Tato kapitola obsahuje seznam minimálních požadavků na dodávané plnění. Minimální technické požadavky nezahrnují veškeré funkční požadavky, jedná se o zásadní technologická kritéria, která jsou z pohledu Objednatele neměnná pro zajištění implementace i zajištění následného provozu Systému.

Řešení jako celek musí splnit předmět plnění a Objednateli umožnit dosažení deklarovaných cílů uvedených v příloze č. 5 zadávací dokumentace s názvem „Specifikace předmětu plnění veřejné zakázky“ a v příloze č. 6 zadávací dokumentace s názvem „Technická dokumentace – NDA“.

1.3.1Obecné požadavky

Reference

Znění požadavku

Splnění požadavku

Obslužná rozhraní Systému zahrnující uživatelská a administrační rozhraní ve formě webových aplikací.

[DOPLNÍ POSKYTOVATEL]

Bezproblémová funkcionalita Systému a jím poskytovaných zobrazení a portálových aplikací v internetových prohlížečích Microsoft Edge, Google Chrome, Mozilla Firefox, Safari, Opera a Samsung Internet na počítačích s operačními systémy Windows, Mac OS, Linux a mobilních zařízeních s operačními systémy IOS a Android, přičemž pro každou platformu je požadována podpora vybraných výše uvedených prohlížečů dle aktuální podpory běhu a možnosti instalace daného prohlížeče na vybranou platformu.

[DOPLNÍ POSKYTOVATEL]

Podpora vykreslování obsahu pro zařízení s různou velikostí displeje, tedy podpora i pro zobrazení v prohlížečích na mobilních zařízeních, poskytování tzv. responzivního designu.

[DOPLNÍ POSKYTOVATEL]

Systém bude navržen a implementován tak, aby pro jeho provoz bylo možné využívat i méně výkonná zařízení běžně využívaná klienty veřejné správy.

[DOPLNÍ POSKYTOVATEL]

Podpora publikace obsahu na úrovni portálu či jednotlivých portálových aplikací ve formě formátovaného textu, tabulek, odkazů, dynamického textu načítaného z integrovaných služeb, multimediálního obsahu, tabulek, reportů, grafů a souborů ke stažení.

[DOPLNÍ POSKYTOVATEL]

Publikace katalogu integrovaných aplikací s odkazem na konkrétní aplikace. Zobrazení pouze položek, pro které uživatel disponuje příslušným oprávněním.

[DOPLNÍ POSKYTOVATEL]

Správa uživatelského profilu, preferencí uživatele a nastavení.

[DOPLNÍ POSKYTOVATEL]

Rozhraní Systému pro všechny typy uživatelů lokalizované do Českého jazyka.


Systém podporuje lokalizaci uživatelského rozhraní, resp. ovládacích a dalších prvků, a publikovaného obsahu do více jazykových mutací.

[DOPLNÍ POSKYTOVATEL]

Lokalizace uživatelského rozhraní bude realizována mimo programový kód prostřednictvím samostatných dat s překlady v podobě souborů, databází či obdobné, tak aby úprava či rozšíření překladu nevyžadovaly překlad aktualizovaného zdrojového kódu aplikace.

[DOPLNÍ POSKYTOVATEL]

Lokalizaci publikovaného obsahu realizována uživatelsky prostřednictvím webového rozhraní.

[DOPLNÍ POSKYTOVATEL]



1.3.2Požadavky na architekturu

Reference

Znění požadavku

Splnění požadavku




Systém je navržen a budován v souladu s Národním architektonickým plánem (xxxxx://xxxxx.xxx.xx/xxx_xxxxxxxx) a v něm publikovanými architektonickými principy.

[DOPLNÍ POSKYTOVATEL]

Systém je navržen a implementován modulárně s jasně definovanými rozhraními tak, aby v případě budoucího rozvoje bylo možné rozvíjet samostatné moduly a implementovat moduly nové bez ohrožení funkcionalit ostatních modulů.

[DOPLNÍ POSKYTOVATEL]

Systém zahrnuje platformu či framework poskytující sdílené služby, funkcionality, komponenty a další zdroje pro implementaci a provoz jednotlivých portálových aplikací. Platforma či framework musí umožňovat všem portálovým aplikacím poskytovat shodný standardní vzhled a jednotnou ergonomii obsluhy.

[DOPLNÍ POSKYTOVATEL]

Všechny skripty a další zdroje využité v portálových aplikacích jsou minimalizovány tak, aby při jejich načtení byl minimalizován objem komunikace mezi serverem a klientem. Zároveň je Systém navržen tak, aby bylo minimalizováno i množství samotných požadavků na přenos dat.

[DOPLNÍ POSKYTOVATEL]

Podpora SEO (Search Engine Optimization) minimálně v informační části Systému a portálových aplikací, poskytování informací v podobě srozumitelné robotickým vyhledávačům a indexovacím službám.

[DOPLNÍ POSKYTOVATEL]

Systém podporuje nasazování nových portálových aplikací či nasazování nových verzí existujících portálových aplikací bez dopadů na provoz samotného Systému včetně všech ostatních nasazených a provozovaných portálových aplikací.

[DOPLNÍ POSKYTOVATEL]

Podpora definice vlastních vzhledu a stylu PORSYS včetně jednotlivých portálových aplikací tak, aby bylo možné naplnit požadavky na standardní vzhled portálů eGovernment (Design systém eGovernment - xxxxx://xxxxxxxxxxxx.xxx.xx) a požadavky na standardní vzhled Objednatele.

[DOPLNÍ POSKYTOVATEL]

Podpora běhu v prostředí s vysokou dostupností na více hostitelských uzlech bez ztráty dat sezení uživatele v případě selhání jednoho z uzlů tvořících infrastrukturu.

[DOPLNÍ POSKYTOVATEL]

Zajištění kontinuity provozu a ošetření výpadků a nedostupností integrovaných systémů a služeb.

[DOPLNÍ POSKYTOVATEL]

Podpora zálohy všech klíčových aktiv Systému a jejich obnovy ze zálohy.

[DOPLNÍ POSKYTOVATEL]

Podpora publikace PORSYS za reverzní proxy.

[DOPLNÍ POSKYTOVATEL]

Podpora začlenění externích aplikací / externího obsahu do prezentace PORSYS.

[DOPLNÍ POSKYTOVATEL]

Podpora jednotného vzhledu a ergonomie hostovaných portálových aplikací.

[DOPLNÍ POSKYTOVATEL]

Sdílení a přepoužívání sdílených funkcionalit a služeb Systému pro výstavbu portálových aplikací.

[DOPLNÍ POSKYTOVATEL]

Jednoznačné a bezpečné oddělení informací publikovaných pro klienty veřejné správy a informací interní povahy určených čistě pro potřeby pracovníků Objednatele.

[DOPLNÍ POSKYTOVATEL]



1.3.3Redakční systém

Reference

Znění požadavku

Splnění požadavku

Podpora uživatelsky přívětivé správy obsahu PORSYS s využitím WYSIWYG („What you see is what you get“ - uživatel graficky edituje v zobrazení, které odpovídá cílovému zobrazení) editoru, funkcionalita redakčního systému.

[DOPLNÍ POSKYTOVATEL]

Podpora procesu návrhu, schvalování a publikace obsahu.

[DOPLNÍ POSKYTOVATEL]

Publikace obsahu prostřednictvím API.

[DOPLNÍ POSKYTOVATEL]

Podpora standardě publikovaného typu obsahu zahrnujícího formátovaný text s možností rozdělení do sloupců, tabulky, multimediální obsah, odkazy, soubory.

[DOPLNÍ POSKYTOVATEL]

Podpora šablon obsahu.

[DOPLNÍ POSKYTOVATEL]

Lokalizace obsahu do více jazykových mutací s využitím WYSIWYG editoru.

[DOPLNÍ POSKYTOVATEL]

Podpora exportu a importu formátovaného obsahu za účelem editace v externích nástrojích.

[DOPLNÍ POSKYTOVATEL]



1.3.4Sdílení souborů

Reference

Znění požadavku

Splnění požadavku

Podpora sdílení souborů mezi klienty a pracovníky Objednatele.

[DOPLNÍ POSKYTOVATEL]

Zajištění antivirové kontroly sdílených souborů.

[DOPLNÍ POSKYTOVATEL]

Omezení maximální velikosti sdílených souborů.

[DOPLNÍ POSKYTOVATEL]

Omezení povolených typů sdílených souborů.

[DOPLNÍ POSKYTOVATEL]

Omezení maximálního prostoru na úrovni uživatele a zastupovaného subjektu pro sdílení všech souborů.

[DOPLNÍ POSKYTOVATEL]

Podpora organizace sdílených souborů do hierarchické struktury složek.

[DOPLNÍ POSKYTOVATEL]

Podpora doplnění popisných informací a metadat ke sdíleným soborům.

[DOPLNÍ POSKYTOVATEL]

Podpora odkazování souborů.

[DOPLNÍ POSKYTOVATEL]

Podpora nastavení maximální životnosti souborů a automatické mazání či archivaci souborů v okamžiku vypršení platnosti.

[DOPLNÍ POSKYTOVATEL]

Podpora předání souborů do integrovaných systémů.

[DOPLNÍ POSKYTOVATEL]

Podpora současného nahrání a stažení více souborů ze strany uživatele.

[DOPLNÍ POSKYTOVATEL]

Podpora publikace a správy sdílených souborů prostřednictvím API.

[DOPLNÍ POSKYTOVATEL]



1.3.5Notifikace

Reference

Znění požadavku

Splnění požadavku

Podpora odesílání notifikací o nově publikovaném obsahu, událostech v portálových aplikacích a dalších skutečnostech specifických pro implementované portálové aplikace.

[DOPLNÍ POSKYTOVATEL]

Podpora využití notifikačních kanálů SMS, email, portálové okno (část portálu s přehledem notifikací/upozornění) a rozhraní pro notifikace prostřednictvím externí mobilní aplikace.

[DOPLNÍ POSKYTOVATEL]

Podpora uživatelského nastavení notifikací s možností definovat cílovou destinaci, četnost a způsob notifikace pro definované typy/kategorie notifikací.

[DOPLNÍ POSKYTOVATEL]

Podpora trvalého či dočasného potlačení notifikací prostřednictvím notifikačních kanálů email, SMS a mobilní aplikace.

[DOPLNÍ POSKYTOVATEL]

Zabezpečení proti spamu a zneužití notifikační funkcionality.

[DOPLNÍ POSKYTOVATEL]

Podpora odeslání textu a v případě kanálů podporujících formátovaný text i formátovaného textu a příloh.

[DOPLNÍ POSKYTOVATEL]

V případě formátovaného textu podpora odesílání odkazů v notifikacích, zejména odkazů na související informace v portálu a portálových aplikací, po jejichž následování klientem dojde na straně klienta k zobrazení odkazovaných informací v internetovém prohlížeči anebo mobilní aplikaci.

[DOPLNÍ POSKYTOVATEL]

Podpora klasifikace notifikací dle významu a důležitosti s možností vizuálního odlišení významu události v notifikačním kanálu.

[DOPLNÍ POSKYTOVATEL]

Řízení oprávnění pro práci s notifikacemi na úrovni uživatele a zastupovaného subjektu.

[DOPLNÍ POSKYTOVATEL]

Evidence a prezentace příznaku zobrazení/přečtení notifikace volitelně na úrovni uživatele či celého subjektu s možností uživatelské změny hodnoty příznaku.

[DOPLNÍ POSKYTOVATEL]



1.3.6Formuláře

Reference

Znění požadavku

Splnění požadavku

Podpora zobrazení chytrých interaktivních webových formulářů.

[DOPLNÍ POSKYTOVATEL]

Podpora nápovědy ve formulářích.

[DOPLNÍ POSKYTOVATEL]

Lokalizace formulářů do českého jazyka s podporou lokalizace do dalších jazykových mutací.

[DOPLNÍ POSKYTOVATEL]

Podpora grafického návrhu formulářů ve vizuálním návrhovém nástroji.

[DOPLNÍ POSKYTOVATEL]

Podpora průvodců, sekcí a navigace v rozsáhlých formulářích.

[DOPLNÍ POSKYTOVATEL]

Podpora vložení/začlenění formuláře do stránky portálové aplikace anebo zobrazení v samostatném okně či záložce prohlížeče klienta.

[DOPLNÍ POSKYTOVATEL]

Podpora automatického doplňování dat a kontrol/validace vkládaných dat.

[DOPLNÍ POSKYTOVATEL]

Podpora vstupních formulářových prvků (polí) a souborových příloh.

[DOPLNÍ POSKYTOVATEL]

Podpora odeslání dat formou volání určených webových služeb REST, SOAP s daty ve formátu XML nebo JSON.

[DOPLNÍ POSKYTOVATEL]

Podpora definice šablony formálních výstupů, které budou zobrazeny klientům a umožněno stažení v podobě souborů, zejména PDF/A souborů opatřených kvalifikovanou pečetí a časovým razítkem.

[DOPLNÍ POSKYTOVATEL]



1.3.7Využití cloudových technologií a služeb

Reference

Znění požadavku

Splnění požadavku

Podpora provozu Systému v cloudovém prostředí s využitím cloudových služeb a kontejnerizace.

[DOPLNÍ POSKYTOVATEL]

Komponenty vyvíjené na míru Objednatele, které nejsou poskytovány ve formě cloudové služby, anebo využité komerční komponenty tvořící řešení musí být kontejnerizovány a orchestrovány využitím technologií podporovaných hlavními poskytovateli veřejných a privátních cloudových služeb do podoby celkového řešení Systému tak, aby je bylo možné v případě potřeby přenést k jinému poskytovateli cloudových služeb či do on-premise infrastruktury Objednatele vyhovující cloudovým standardům.

[DOPLNÍ POSKYTOVATEL]

Konfigurace cloudové infrastruktury a služeb musí být exportovatelné v podobě konfiguračních souborů (IaaC – Infrastructure as a Code) či obdobné tak, aby je bylo možné v případě exitu cloudových služeb předat jinému provozovateli, který je následně může využít jako zdroj informací pro přípravu nového nasazení. Konfigurace musí být předána v podobě IaaC zdrojů a formátů běžně podporovaných hlavními provozovateli veřejných a privátních cloudových služeb.

[DOPLNÍ POSKYTOVATEL]

V případě využití IaaS a dalších PaaS služeb, musí být využity pouze takové standardní služby, jejichž obdobu lze čerpat i v případě hostování Systému v prostředí jiného poskytovatele cloudových služeb. Komponenty Systému bude možné v jiném cloudovém prostředí rekonfigurovat pro napojení na nové obdobné cloudové služby.

[DOPLNÍ POSKYTOVATEL]

Řešení a v něm implementované portálové aplikace musí být schopny čerpat/zapisovat business data z/do odborných systémů a volat funkcionality odborných systémů, přičemž data a funkcionality budou v podobě webových služeb publikovány na integrační platformě XXXX. Řešení musí podporovat provoz v cloudu při práci s daty a backend funkcionalitami provozovanými on-premise v infrastruktuře Objednatele.

[DOPLNÍ POSKYTOVATEL]

Cloudové služby musí být škálovatelné a umožňovat rychlé dočasné či trvalé snížení a zvýšení množství využitých zdrojů v závislosti na počtu uživatelů a intenzitě užití služeb Systému. Škálování musí být možné realizovat automaticky na základě monitorovaných metrik anebo manuálně zásahem Provozovatele cloudové služby.

[DOPLNÍ POSKYTOVATEL]

Cloudové služby musí mít certifikaci systému managementu bezpečnosti informací ISO 27001 (s uplatněním norem ISO 27017 pro bezpečnostní opatření u cloudových služeb a ISO 27018 o ochraně osobních údajů v cloudu).

[DOPLNÍ POSKYTOVATEL]

1.3.8Zabezpečení

Reference

Znění požadavku

Splnění požadavku




Systém je klasifikován jako Významný informační systém dle ZoKB a dle související prováděcí vyhlášky č. 317/2014 Sb., o významných informačních systémech a jejich určujících kritériích, ve znění pozdějších předpisů a musí být proto navržen a implementován tak, aby naplňoval všechny požadavky vyplývající z uvedené legislativy.

[DOPLNÍ POSKYTOVATEL]

Systém musí být zabezpečen proti všem hlavním zranitelnostem webových aplikací s ohledem na skutečnost, že bude přístupný veřejně pro klienty veřejné správy, a tedy kontinuálně přístupný z internetu.

[DOPLNÍ POSKYTOVATEL]

Systém musí využívat kryptografické a další bezpečnostní standardy a sílu kryptografických algoritmů odpovídající jeho významu a požadavkům na zabezpečení v souladu uznávanými standardy pro tento typ systémů.

[DOPLNÍ POSKYTOVATEL]

Systém musí podporovat autentizaci a autorizaci uživatelů využitím služeb bezpečnostních systémů Objednatele založenou na principu jednotného přihlášení.

[DOPLNÍ POSKYTOVATEL]

Systém musí být schopen automaticky zakládat oprávněného uživatele při prvním přístupu anebo automatickým provisioningem ze strany bezpečnostních systémů Objednatele.

[DOPLNÍ POSKYTOVATEL]

Řízení oprávnění využitím systému uživatelských účtů, skupin, rolí s vazbou na zastupovaný subjekt.

[DOPLNÍ POSKYTOVATEL]

Autorizace uživatelů pro využití funkcionalit ve všech modulech/částech PORSYS v kontextu zastupovaného subjektu a přístup k informacím náležících zastupovanému subjektu v rozsahu odpovídajících oprávnění uživatele pro zastupovaný subjekt.

[DOPLNÍ POSKYTOVATEL]

Komunikace s klientem řešena výhradně kanálem zabezpečeným TLS v poslední známé verzi anebo verzi podporované klientem, minimálně však verzí TLS 1.2 nebo TLS 1.3.

[DOPLNÍ POSKYTOVATEL]

Zabezpečená TLS komunikace pro přístup ke všem dalším zdrojům načítaným do portálových stránek (není kombinován zabezpečený a nezabezpečený obsah).

[DOPLNÍ POSKYTOVATEL]

Uložení certifikátů (zejména privátních klíčů) v zabezpečeném úložišti.

[DOPLNÍ POSKYTOVATEL]

Podpora logování přístupů včetně zápisu adresy klienta s využitím X-Forwarded-For hlavičky v případě využití proxy apod.

[DOPLNÍ POSKYTOVATEL]

Podpora logování/auditování všech z pohledu bezpečnosti významných událostí v Systému.

[DOPLNÍ POSKYTOVATEL]

Podpora předávání bezpečnostních událostí do dohledového systému Objednatele.

[DOPLNÍ POSKYTOVATEL]



2Implementační požadavky na dodání Díla (Systému) a pilotní a akceptační provoz



Dodání Informačního systému (Dílo) zahrnuje zejména tyto tři základní části:

  • Dodávka licencí vč. maintenance Dodaného SW,

  • Implementace Systému,

  • Zajištění služeb Pilotního a akceptačního provozu.

2.1 Dodávka licencí SW produktů

Přestože hlavním předmětem Smlouvy je provoz Systému jako služby v cloudovém prostředí Poskytovatele, je součástí předmětu Smlouvy i návrh, implementace a nasazení Systému tak, aby bylo možné uvedenou službu řádně a dle požadavků Objednatele poskytovat. Objednatel předpokládá, že pro návrh a výstavbu řešení mohou být využity i komerční softwarové komponenty, jejichž nasazení je podmíněno zajištěním odpovídajících licencí.

Předmětem Dodávky licencí SW produktů je dodání kompletního SW licenčního vybavení dle požadavků stanovených Zadávací dokumentací včetně jejích příloh nezbytných pro:

  • realizaci Implementace Systému (Díla) zahrnujícího veškeré technické, funkční, bezpečnostní a další vlastnosti,

  • poskytování průběžných služeb provozu a rozvoje Systému (Díla),

  • poskytování jednorázových služeb souvisejících se službami provozu a rozvoje Systému (Díla).

Dodávky licencí SW produktů jsou součástí dodávky Díla, a to včetně jejich maintenance po dobu Pilotního a akceptačního provozu (zahrnuty v ceně Jednotková cena dodávky licencí vč. maintenance do doby zahájení poskytování Služeb provozu (bez DPH)). Cena dodávky licencí a cena jejich maintenance (od zahájení poskytování Služeb provozu) je stanovena pro 100.000 jmenných uživatelů a 6.000 současně přistupujících uživatelů. Zvýšení ceny licencí SW produktů a jejich maintenance je možné za podmínek popsaných v Příloze č. 7 Smlouvy.

Předmětem dodávky není zajištění licencí těch hardware a software komponent, které jsou specifické pro prostředí Poskytovatele a jejichž využití v případě migrace služeb provozu a rozvoje k jinému dodavateli není možné. Pro zamezení pochybnostem se uvádí, že se jedná o svou povahou čistě podpůrné komponenty, jejichž absence při migraci nebude mít dopad na funkčnost Systému v prostředí jiného dodavatele.

Součástí Dodávky licencí SW produktů je poskytnutí kompletních licenčních dokumentů a klíčů, instalačních médií, standardní technické dokumentace výrobce SW nezbytné pro instalaci SW vybavení, zahájení Implementace Systému a následný provoz implementovaného Systému. Předmětem dodávky je rovněž zajištění maintenance výrobce Objednateli do doby ukončení Pilotního a akceptačního provozu. U tzv. open source software dle odst. 22.10 Smlouvy je součástí Dodávky licencí SW produktů původní uživatelská, provozní a administrátorská dokumentace, je-li k dispozici, a předmětem dodávky je rovněž zajištění maintenance Poskytovatele Objednateli do doby ukončení Pilotního a akceptačního provozu.

2.1.1Soupis dodávaných licencí SW produktů

Níže uvedený výčet licencí obsahuje soupis veškerých poskytovaných licencí SW komponent nezbytných pro implementaci Systému v rozsahu stanoveném zadávacími podmínkami veřejné zakázky tak, aby byly splněny veškeré požadované vlastnosti Systému. V případě, že při Implementaci bude zjištěno, že dodávané licence nepokrývají veškeré funkční, technické a další požadavky definované Zadávací dokumentací a Smlouvou, zajistí Poskytovatel dodávku potřebných dodatečných licencí, a to bez nároku na jakékoliv navýšení ceny Díla či ceny za Maintenance licencí.

Seznam licencí:

[BUDE DOPLNĚNO PŘED PODPISEM SMLOUVY NA ZÁKLADĚ VÍTĚZNÉ NABÍDKY V SOULADU S PŘÍLOHOU Č. 7 SMLOUVY]

2.1.2Harmonogram a způsob převzetí dodávky licencí SW produktů

Celkový termín dodání licencí je stanoven na maximálně 20 (dvacet) pracovních dní ode dne nabytí účinnosti Smlouvy.

Způsob a formát předání dodávky licencí:

[DOPLNÍ POSKYTOVATEL - POSKYTOVATEL SPECIFIKUJE ZPŮSOB A FORMÁT PŘEDÁNÍ DODÁVKY. ZPŮSOB DODÁVKY NEBUDE ZAHRNOVAT POŽADAVKY NA AKTIVITY ZE STRANY OBJEDNATELE VŮČI VÝROBCŮM SW (NAPŘ. REGISTRACE SW, KOMUNIKACE SE SW PODPOROU MIMO ÚZEMÍ ČR, VALIDACE EMAILOVÝCH ÚČTŮ, ATD.). VEŠKERÉ ČINNOSTI SOUVISEJÍCÍ S PŘÍPRAVOU PODKLADŮ PRO PŘEDÁNÍ DODÁVKY TAK ZAJISTÍ POSKYTOVATEL. POSKYTOVATEL DÁLE UVEDE KOMPLETNÍ ROZSAH DOKUMENTACE VÝROBCE A DOKUMENTACE K OPEN SOURCE SW, KTERÁ BUDE PŘEDMĚTEM DODÁVKY TAK, ABY BYLO MOŽNÉ NA ZÁKLADĚ TÉTO DOKUMENTACE REALIZOVAT IMPLEMENTACI SYSTÉMU DLE PARAMETRŮ DEFINOVANÝCH V ZADÁVACÍ DOKUMENTACI.]

Poskytovatel poskytne předmět Dodávky licencí SW produktů Objednateli nejpozději do 10 (deseti) pracovních dní ode dne nabytí účinnosti Smlouvy. Pro realizaci předmětu dodávky licencí SW produktů jsou Oprávněnými osobami za stranu Objednatele i Poskytovatele myšleny osoby uvedené v příloze č. 5 Smlouvy uvedené v rolích Oprávněná osoba za oblast obchodní. Předmět Dodávky licencí SW produktů bude tedy předávat Oprávněná osoba za Poskytovatele, přebírat předmět Dodávky licencí SW produktů bude Oprávněna osoba za Objednatele. Součástí předání ze strany Poskytovatele bude:

  • Předávací protokol obsahující:

    • kompletní výčet předmětu Dodávky licencí SW produktů – seznam veškerých SW produktů s uvedením licenčních kódů,

    • přehled instalačních médií, případně odkazy na instalační soubory výrobce, v případě, že jsou tyto dostupné ke stažení z webových stránek výrobce,

    • výčet veškeré licenční dokumentace a licenčních podmínek a podmínek užití a použití open source software,

    • podpis Oprávněné osoby ze strany Poskytovatele garantující předání kompletního Předmětu Dodávky licencí SW produktů.

  • licenční dokumenty výrobce SW platné ke dni předání předmětu dodávky; v případě, že budou licenční dokumenty předávány prostřednictvím elektronického média, proběhne předání na dvou identických nosičích chráněných proti modifikaci, změně, či výmazu,

  • technická dokumentace výrobce nezbytná k instalaci SW technologií platná ke dni předání předmětu dodávky; v případě, že bude licenční dokumentace předávána prostřednictvím elektronického média, bude předána na dvou identických nosičích chráněných proti modifikaci, změně, či výmazu,

  • podmínky užití a použití open source software platné ke dni předání předmětu dodávky; v případě, že budou podmínky předávány prostřednictvím elektronického média, proběhne předání na dvou identických nosičích chráněných proti modifikaci, změně, či výmazu,

  • potvrzení výrobce (výrobců) o zajištění maintenance licencí Objednateli jakožto koncovému příjemci maintenance a potvrzení Poskytovatele o zajištění maintenance open source software Objednateli jakožto koncovému příjemci maintenance. Maintenance v rámci Dodávky licencí SW produktů bude kalkulována do ceny licence a bude zajištěna pro všechny SW licence po celou dobu Pilotního a akceptačního provozu, tedy do okamžiku zahájení poskytování Služeb provozu.

Na základě předání předmětu Dodávky licencí SW produktů Oprávněné osobě ze strany Objednatele bude zahájena akceptační procedura pro předání Dodávky licencí SW produktů. Oprávněná osoba ze strany Objednatele ověří úplnost předání Dodávky licencí SW produktů. Pokud Oprávněná osoba zjistí, že předmět Dodávky licencí obsahuje vady bránící akceptaci a potvrzení Předávacího protokolu, vznese písemnou námitku nejpozději do 4 (čtyř) pracovních dní následujících po předání Předmětu Dodávky licencí SW produktů ze strany Oprávněné osoby Poskytovatele. V případě vznesení námitky ze strany Objednatele zajistí Poskytovatel nápravu a opravený Předmět Dodávky licencí SW produktů předá Oprávněné osobě ze strany Objednatele nejpozději do následujících 2 (dvou) pracovních dní ode dne obdržení námitky, případně nejpozději do 16. (šestnáctého) pracovního dne ode dne nabytí účinnosti smlouvy, podle toho, který z uvedených termínů nastane dříve. Na základě obdržení opraveného Předmětu Dodávky provede Oprávněná osoba ze strany Objednatele kontrolu předmětu Dodávky licencí SW produktů. Pokud již bude Předmět Dodávky obsahovat veškeré nezbytné náležitosti a bude odpovídat smluvním podmínkám, potvrdí Oprávněná osoba ze strany Objednatele Předávací protokol svým podpisem a zašle potvrzený předávací protokol Oprávněné osobě Poskytovatele nejpozději 4. (čtvrtý) pracovní den ode dne obdržení opraveného předmětu Dodávky licencí.

V případě, že Oprávněná osoba ze strany Objednatele nevznese písemnou námitku do 4 (čtyř) pracovních dní ode dne obdržení předmětu Dodávky licencí, případně opraveného předmětu Dodávky licencí SW produktů, ani nezašle potvrzený předávací protokol Oprávněné osobě Poskytovatele, má se za to, že předmět Dodávky licencí obsahuje veškeré nezbytné náležitosti a odpovídá smluvním podmínkám. V takovém případě zašle Oprávněná osoba Poskytovatele Oprávněné osobě Objednatele písemné vyrozumění, že Předmět dodávky licencí SW produktů byl tímto akceptován a bude vystavena faktura k 1. fakturačnímu milníku dle kapitoly 6.1.3 Smlouvy.

2.2 Implementace systému

Před zahájením poskytování Služeb musí být Systém navržen a vybudován v souladu s požadavky na funkcionality Systému a požadavky na podobu a parametry Služeb. Vzhledem ke skutečnosti, že Systém zahrnuje obslužné portálové aplikace, které představují uživatelská rozhraní k IS XXXX, musí být návrh a implementace Systému realizovány ve spolupráci s dodavatelem projektu IS XXXX, tedy realizátorem veřejné zakázky „Implementace a provoz informačního systému SZIF pro Monitoring Approach“ (dále jen „VZ IS XXXX)“ a dalších souvisejících zakázek. Zejména dodávky Systému a IS XXXX musí být koordinovány tak, aby bylo možné jednotlivé inkrementy IS XXXX vždy testovat prostřednictvím uživatelského rozhraní portálových aplikací v Systému.

Systém musí být zároveň navržen a implementován s využitím technologií umožňujících jeho snadnou migraci k jinému poskytovateli služeb provozu a rozvoje, jak je požadováno v příloze č. 5 Zadávací dokumentace – Specifikace předmětu plnění veřejné zakázky.

Příprava, návrh a implementace Systému budou realizovány formou implementačního projektu. Informace o požadavcích na řízení implementačního projektu jsou uvedeny v následující kapitole. Implementační projekt bude zahrnovat dvě základní fáze:

  • Analytická a přípravná fáze Implementace,

  • Vlastní Implementace.

Tyto fáze se mohou v závislosti na zvolené metodě projektového řízení a vývoje opakovat v jednotlivých iteracích zajišťujících dodávku předem specifikovaných částí a funkcionalit Systému.

Příprava, návrh a Implementace Systému musí probíhat ve spolupráci s Dodavatelem související zakázky VZ IS XXXX, jejímž předmětem je hlavní část informačního systému pro podporu agend XXXX (IS XXXX). IS XXXX bude obsahovat business logiku a zajišťovat správu dat XXXX, přičemž funkcionality a data budou přístupná Systému prostřednictvím jasně definovaného API.

Projekt IS XXXX je integračním projektem a jako takový zajišťuje koordinaci a řídí spolupráci ostatních projektů a projektových týmů zapojených do návrhu a výstavby systémové podpory agend XXXX. Harmonogram projektu, implementační práce, testování a další aktivity v rámci projektu dodávky Systému musí být navrženy dle požadavků souvisejícího projektu IS XXXX a musí být s tímto projektem v souladu.

Vhledem k rozsahu projektu a různým požadovaným termínům na dodávky funkcionalit budou jednotlivé funkcionality IS XXXX v souvisejícím výše uvedeném projektu klasifikovány dle priority a v závislosti na přidělené prioritě implementovány a nasazeny v rámci implementační fáze projektu (tzv. Kritické funkcionality - prioritní) anebo v průběhu následného Pilotního a akceptačního provozu (tzv. Požadované funkcionality a Kritické - ostatní). Klasifikace funkcionalit bude probíhat jako součást analytické fáze projektu IS XXXX. Vzhledem ke skutečnosti, že Systém, respektive v něm provozované portálové aplikace, představují uživatelské rozhraní k IS XXXX, musí priority funkcionalit Systému odpovídat prioritám IS XXXX. Funkcionality a jejich priority proto budou definovány v projektu IS XXXX a Dodavatelem Systému v průběhu analýzy dovozeny priority požadavků na Systém. Během implementačního projektu tedy bude vybudován Systém pouze v rozsahu nezbytně nutných funkcionalit s nejvyšší prioritou tak, aby bylo možné zajistit administraci Společné zemědělské politiky v nezbytném rozsahu pro naplnění všech legislativních povinností a akreditačních kritérií SZIF. Tyto funkcionality budou v průběhu analytické fáze souvisejícího projektu IS XXXX definovány jako funkčnosti kategorie „Kritická“. Funkcionality kategorie „Kritická“ budou prioritizovány do dvou skupin: Do skupiny „Kritická - prioritní“, které musí být naimplementovány do závazného milníku 15. 9. 2022, a do skupiny „Kritická - ostatní“, které musí být naimplementovány do 31. 3. 2023.

Funkcionality „Kritické – ostatní“ a funkcionality „Požadované“ budou implementovány v průběhu Pilotního a akceptačního provozu. Objednatel nepředpokládá vývoj a nasazování Požadovaných funkcionalit před 31. 3. 2023. Funkcionality budou nasazovány průběžně v dílčích termínem odsouhlasených v rámci projektového řízení.

Implementační projekt bude dále postihovat i navazující fázi:

  • Zajištění služeb Pilotního a akceptačního provozu.

Během této fáze bude zajištěno komplexní ověření vlastností Systému a všech funkčností kategorie „Kritická - prioritní“ v provozním prostředí a v rámci standardní administrace SZP. Zároveň v průběhu Pilotního a akceptačního provozu bude docházet k uvolňování do produktivního prostředí (PROD) funkcionalit definovaných jako nezbytných pro zajištění finální akceptace Systému v souladu s postupným uvolňováním funkcionalit v souvisejícím projektu VZ IS XXXX (Kritické – ostatní a Požadované funkcionality). Výstavba Systému a harmonogram tak musí být v  souladu se stanoveným projektovým harmonogramem a veškerými požadavky na informační systém XXXX. Funkcionality implementované a nasazované v  průběhu Pilotního a akceptačního provozu budou klasifikovány v  průběhu analýzy jako funkčnosti kategorie „Kritické - ostatní“ a „Požadovanéá“. V průběhu Pilotního a akceptačního provozu rovněž může docházet k úpravám a novému vývoji Systému na základě identifikovaných potřeb změny Systému.

Vzhledem k tomu, že předmětem dodávky a implementace Díla není jedna jediná součást, musí veškeré projektové, implementační a zejména dokumentační procesy zohledňovat právě odlišnost jednotlivých součástí tak, aby bylo jednoznačně zřejmé, co je předmětem veškerých analytických, implementačních i následně provozních služeb pro části:

  • Portálový systém SZIF

  • Portálová aplikace XXXX pro žadatele

  • Portálová aplikace XXXX pro SZIF

  • BUDE DOPLNĚNO PŘED PODPISEM SMLOUVY NA ZÁKLADĚ VÍTĚZNÉ NABÍDKY V SOULADU S PŘÍLOHOU Č. 7 SMLOUVY

2.2.1Řízení implementačního projektu a projektová metodika

[DOPLNÍ POSKYTOVATEL - POSKYTOVATEL V RÁMCI NABÍDKY SPECIFIKUJE KOMPLETNÍ METODIKU ŘÍZENÍ PROJEKTU IMPLEMENTACE V SOULADU S MEZINÁRODNĚ UZNÁVANÝM STANDARDEM, KTERÝ BUDE V RÁMCI ŘÍZENÍ IMPLEMENTACE UPLATŇOVÁN. TATO METODIKA BUDE UVEDENA V TÉTO KAPITOLE PŘÍLOHY SMLOUVY. V RÁMCI DEFINOVANÉ METODIKY BUDE UVEDENO, Z JAKÉHO MEZINÁRODNÍHO STANDARDU METODIKA VYCHÁZÍ. ZA STANDARD NENÍ V TOMTO PŘÍPADĚ POVAŽOVÁNA METODIKA, KTERÁ JE VYUŽÍVÁNA SPECIFICKY POSKYTOVATELEM, ČI JEHO PODDODAVATELI. ZA STANDARD JE POUŽÍVÁNA OBECNÁ METODOLOGIE PRO PROJEKTOVÉ ŘÍZENÍ ČI IMPLEMENTACI - NAPŘ. PRINCE 2, PRINCE 2 AGILE, PMBOK, SCRUM, ATD. SPECIFIKOVANÁ METODIKA MUSÍ BÝT STEJNÁ JAKO CERTIFIKACE, KTEROU JE PROKAZOVANÁ TECHNICKÁ KVALIFIKACE - PROKAZATELNÁ ZNALOST MEZINÁRODNĚ UZNÁVANÉHO STANDARDU NEBO METODOLOGIE PROJEKTOVÉHO ŘÍZENÍ NA POZICI ČLENA REALIZAČNÍ TÝMU „PROJEKT MANAGER“. JINÝMI SLOVY PROJEKT MANAGER MUSÍ DISPONOVAT CERTIFIKACÍ ODPOVÍDAJÍCÍ ZDE NAVRŽENÉ METODICE.

VZHLEDEM K TOMU, ŽE CELÝ PROJEKT SZIF, PROSTŘEDNICTVÍM KTERÉHO MÁ BÝT ZAJIŠTĚNA FUNKČNOST KOMPLEXNÍHO INFORMAČNÍHO PROSTŘEDÍ PRO NAPLNĚNÍ POŽADAVKŮ PRO MONITORING APPROACH, ZAHRNUJE NEJEN IMPLEMENTACI TECHNOLOGIÍ DODÁVANÝCH V RÁMCI VEŘEJNÉ ZAKÁZKY, ALE ROVNĚŽ IMPLEMENTACI DALŠÍCH NOVÝCH OBLASTÍ (SLUŽBY VYHODNOCOVÁNÍ SATELITNÍCH A DALŠÍCH DAT - IS XXXX, SAMAS, SLUŽBY GEOTAGOVANÝCH FOTOGRAFIÍ), INTEGRACI NA TYTO NOVÉ OBLASTI I NA STÁVAJÍCÍ INFORMAČNÍ PROSTŘEDÍ SZIF, JE NEZBYTNÉ ZAJISTIT V RÁMCI REALIZACE IMPLEMENTAČNÍHO PROJEKTU V RÁMCI TÉTO VEŘEJNÉ ZAKÁZKY PROVÁZANOST SE VŠEMI DALŠÍMI SOUVISEJÍCÍMI EXTERNÍMI OBLASTMI. POSKYTOVATEL V RÁMCI PŘÍPRAVY PROJEKTOVÉ METODIKY A IMPLEMENTAČNÍ METODIKY DEFINUJE PROCESY ŘÍZENÍ A IMPLEMENTACE TAKOVÝM ZPŮSOBEM, ABY BYLO MOŽNÉ ZAJISTIT SOUČINNOST, INTEGRACI A PŘÍPADNĚ SYNCHRONIZACI VÝVOJE I S DALŠÍMI POSKYTOVATELI SLUŽEB, ZEJMÉNA S DODAVATELEM SYSTÉMU IS XXXX, PRO KTERÝ PŘEDSTAVUJE SYSTÉM UŽIVATELSKÁ ROZHRANÍ. VZHLEDEM K TOMU, ŽE TECHNOLOGIE A IMPLEMENTAČNÍ PRÁCE REALIZOVANÉ V RÁMCI SOUVISEJÍCÍ VEŘEJNÉ ZAKÁZKY „VZ Implementace a provoz informačního systému SZIF pro Monitoring Approach (VZ IS XXXX)“ JSOU STĚŽEJNÍ A PRIMÁRNÍ PRO CELÉ FUNGOVÁNÍ NOVÝCH ČÁSTÍ INFORMAČNÍHO SYSTÉMU SZIF, JE NEZBYTNÉ, ABY PROCESY ZAJIŠŤOVANÉ POSKYTOVATELEM SLUŽEB IS XXXX BYLY URČUJÍCÍ A ŘÍDÍCÍ I PRO OSTATNÍ PARTNERY SZIF VČETNĚ DODAVATELE SYSTÉMU V RÁMCI TÉTO VEŘEJNÉ ZAKÁZKY. TEDY Z TECHNICKÉHO A PROJEKTOVÉHO HLEDISKA MUSÍ PROJEKTOVÁ A IMPLEMENTAČNÍ METODIKA ZAJIŠŤOVAT I ČÁSTI CHARAKTERISTICKÉ PRO SLUŽBY SYSTÉMOVÉ INTEGRACE TAK, ABY CELÉ INFORMAČNÍ PROSTŘEDÍ PRO MONITORING APPROACH VZNIKALO VE SPOLUPRÁCI S OSTATNÍMI POSKYTOVATELI A DÍLČÍ ČÁSTI INFORMAČNÍHO PROSTŘEDÍ BYLY VYVÍJENY, TESTOVÁNY A IMPLEMENTOVÁNY S DOSTATEČNOU FLEXIBILITOU A KOORDINOVANĚ S OSTATNÍMI POSKYTOVATELI SLUŽEB, NAPŘ. PŘI VYUŽITÍ NĚKTERÝCH AGILNÍCH PROCESŮ/METOD.

Součástí definované metodiky řízení projektu implementace musí být minimálně:

  • Způsob nastavení projektu, definice projektových struktur, projektových procesů, kompletní výčet projektové dokumentace (viz dále).

  • Formální projektová struktura bude tříúrovňová, v rámci této projektové struktury bude nejvyšším projektovým orgánem Projektový (Řídící) výbor, který bude vrcholným projektovým a eskalačním orgánem. Projektový výbor bude mít lichý počet členů, kdy počet zástupců ze strany Objednatele bude vyšší, než počet zástupců ze strany Poskytovatele a členy Projektového výboru budou oprávněné osoby ze strany Objednatele dle PŘÍLOHY č. 5 Smlouvy.

  • Definice a nastavení projektových rolí – Definice všech projektových rolí na straně Poskytovatele, stanovení požadovaných projektových rolí na straně Objednatele, definice odpovědností projektových rolí.

  • Řízení harmonogramu projektu, plánování a kontrola harmonogramů a termínů.

  • Řízení kapacit projektu a řízení požadavků na součinnost ze strany Objednatele, kdy součástí bude formalizovaný postup pro zajištění součinnosti nad rámec projektového plánu. Minimální doba na zajištění požadované součinnosti bude 3. pracovní den po vznesení konkrétního požadavku na součinnost ze strany Poskytovatele. Objednatel výslovně stanovuje, že pro každý vznesený Požadavek na poskytnutí součinnosti, který nebude stanoven a odsouhlasen v projektovém harmonogramu, musí být jednoznačně identifikován účel požadované součinnosti, způsob poskytnutí součinnosti (např. jednání, dokument, mimořádné testování, atd.), odkaz na řešenou oblast/část/systém (v případě požadavku na součinnost u analytických prací bude odkazem konkrétní část/kapitola/odstavec analytického dokumentu), rizika při neposkytnutí součinnosti.

  • V rámci projektové metodiky budou nastaveny principy pro řízení projektové a implementační dokumentace, včetně způsobů ukládání a řízení, verzování a schvalování. Veškeré projektové dokumenty budou řízené takovým způsobem, aby bylo prokazatelně doloženo, kdy jaký dokument vznikl, kdo je jeho autorem, kdy byl dokument upravován, schválen a akceptován.

    • Principy řízení projektové dokumentace budou definovány pro veškeré požadavky na implementační a provozní dokumentaci stanovené v kapitole č. 2 Přílohy č. 5 Zadávací dokumentace. U každého požadavku bude definována klasifikace, zda bude požadavek řešen formou dokumentu (standardní řízení, verzování a schvalování dokumentu), či dokumentované informace (dynamicky měnící se obsah řešený v elektronické podobě – pro tento typ dokumentace musí být definován princip řízení a aktualizace dokumentace). Rovněž bude pro každý požadavek určeno, zda se bude jednat o dokumentaci (dokument/dokumentovanou informaci), která bude realizována (vytvoření a akceptace) v rámci Analytické a přípravné fáze, Vlastní Implementace, nebo Pilotního a akceptačního provozu, případně, zda se bude jednat o dokument/dokumentovanou informaci vznikající a aktualizovanou až v rámci poskytování Navazujících služeb (v takovém případě zde bude pouze uvedeno, že požadavek je naplněn v rámci řízení provozní dokumentace a konkrétní způsob řízení takovéto dokumentace bude předmětem přílohy č. 3 Smlouvy).

    • Součástí projektové metodiky budou minimálně následující šablony projektové dokumentace:

      • Nastavení projektu, projektová metodika

      • Záznam/zápis z jednání projektových/realizačních týmů

      • Záznam/zápis z jednání eskalační úrovně projektu – Projektový výbor

      • Požadavek na poskytnutí součinnosti

      • Akceptační protokol/dokument

POSKYTOVATEL může využít jako výchozí šablony přiložené v návrhu přílohy č. 3 Smlouvy.

    • Zbývající šablony projektové dokumentace v podobě dokumentů budou předloženy nejpozději v rámci přípravné etapy projektu.

  • Formy a způsob komunikace v rámci projektu – formální komunikace.

  • Řízení rizik, projektu, řízení problémů projektu, eskalační mechanismy projektu.

  • Změnové řízení projektů zahrnující formalizaci změn prostřednictvím Požadavků na změnu.

  • Detailní popis způsobů akceptace dílčích částí projektu, jednotlivých etap projektu i celku projektu. Objednatel výslovně uvádí, že v rámci akceptačního řízení je nezbytné definovat procesy pro průběžnou akceptaci, která bude formalizovaná.

  • Řízení kvality projektu – součástí projektové metodiky musí být řízení kvality projektu, které umožní přezkoumání způsobu realizace projektu nezávislým auditním subjektem. Objednatel výslovně uvádí, že řízení projektu a samotná implementace informačního systému musí být v souladu s požadavky na řízení vývoje a implementace Významného informačního systému - dle klasifikace Zákona č. 181/2014 Sb. o kybernetické bezpečnosti a o změně souvisejících zákonů a navazujících předpisů a v souladu s požadavky na řízení dodavatelů dle řady norem ISO/IEC 27000.

  • V případě, že bude některá z oblastí projektové metodiky upravována/definována v rámci Přípravné etapy Analytické a přípravné fáze, bude zde toto výslovně uvedeno s uvedením předpokládaného rozsahu úprav/definice. ]

2.2.1.1Součinnost v rámci realizace implementačního projektu

[DOPLNÍ POSKYTOVATEL - POSKYTOVATEL SPECIFIKUJE SOUČINNOST NEZBYTNOU PRO REALIZACI PŘEDMĚTU SMLOUVY, KTEROU BUDE POŽADOVAT ZAJISTIT V PRŮBĚHU REALIZACE DODÁVKY A IMPLEMENTACE, A TO JAK ZE STRANY OBJEDNATELE, TAK ZE STRANY DALŠÍCH DODAVATELŮ OBJEDNATELE. VEŠKERÁ SOUČINNOST BUDE DEFINOVÁNA V RÁMCI STANOVENÉHO HARMONOGRAMU, A TO V DETAILU ODPOVÍDAJÍCÍ ETAPĚ/FÁZI IMPLEMENTACE INFORMAČNÍHO SYSTÉMU TAK, ABY BYLO MOŽNÉ SOUČINNOST V ADEKVÁTNÍ PODOBĚ DLOUHODOBĚ PLÁNOVAT A ZAJISTIT.]

Součinnost bude v průběhu realizace implementace poskytována výhradně v pracovní dny mezi 9-17 hodinou a nepřekročí rozsah:

  • 1 FTE (Full Time Equivalent – při 8 hodinové pracovní době) zaměstnanců Objednatele zodpovědných za věcnou část Implementace Systému – tedy zaměstnance, kteří budou fakticky zodpovídat za věcné nastavení funkčnosti Systému.

  • 0,5 FTE (Full Time Equivalent – při 8 hodinové pracovní době) zaměstnanců Objednatele zodpovědných za projektovou, technickou a informačně bezpečnostní část implementace Systému – tedy zaměstnance, kteří budou zodpovídat za technické, infrastrukturní, bezpečnostní a projektové podmínky – bezpečnostní architektura, solution architektura a na SZIF zajišťují chod a fungování ICT technologií včetně projektového řízení a řízení ISMS.

  • 0,5 FTE (Full Time Equivalent – při 8 hodinové pracovní době) pracovníků Dodavatelů, zajišťujících návrh, implementaci a následný provoz IS XXXX, provoz a rozvoj dalšího aplikačního prostředí IS SZIF, na který bude Systém integrován; poskytování externích služeb nezbytných pro implementaci Systému (např. správa GT FOTO, SAP portál).

Detailní specifikace požadované součinnosti v rámci jednotlivých etap projektu Implementace bude průběžně upřesňována a řízena prostřednictvím projektového harmonogramu, případně prostřednictvím Požadavků na poskytnutí součinnosti dle schválené projektové dokumentace a nastavení projektu.

2.2.2Analytická a Přípravná fáze Implementace

Předmět a cíle analytické a přípravné fáze Implementace:

  • Stanovení detailní organizační struktury implementačního projektu a veškerých náležitostí řízení implementačního projektu,

  • Definice, potvrzení metodiky řízení implementačního projektu, seznámení projektových týmů s detailní metodikou projektu a projektovými principy, přičemž metodika řízení implementačního projektu musí být v souladu s metodikou a požadavky souvisejícího integračního projektu IS XXXX,

  • Realizace předimplementační analýzy, která bude definovat konkrétní aplikační řešení a podobu Systému, přičemž v průběhu analýzy bude jako hlavní vstup pro návrh a výstavbu Systému využito zadání připravené, případně průběžně předávané, dodavatelem souvisejícího projektu IS XXXX,

  • Návrh a příprava cloudových služeb pro Implementaci a zajištění Služeb provozu Systému.

2.2.2.1Příprava projektu (přípravná etapa)

Předmět etapy:

V rámci přípravné etapy bude potvrzena a formálně odsouhlasena uvedená detailní metodika řízení projektu pro realizaci kompletní Implementace Systému, která stanovuje konkrétní projektové postupy a způsoby řízení projektu. Zároveň bude definován a schválen harmonogram implementačního projektu. Projektová metodika a harmonogram musí být v souladu a koordinovány s metodikou řízení projektu a harmonogramem samostatného souvisejícího projektu IS XXXX, který bude v rámci všech dílčích zakázek pro výstavbu systémové podpory agend XXXX vystupovat jako hlavní integrační projekt. Za odsouhlasení projektové metodiky, nastavení projektových principů a následnou vlastní realizaci implementačního projektu odpovídají Oprávněné osoby za oblast projektovou ze strany Objednatele i Poskytovatele uvedené v těchto rolích v Příloze č. 5 Smlouvy.

Cíl Etapy:

  • Detailní nastavení projektu, včetně odpovídajících standardů pro řízení implementačního projektu.



Termín zahájení etapy:

  • Následující pracovní den po nabytí účinnosti smlouvy, tj. BUDE DOPLNĚNO PŘED PODPISEM SMLOUVY.

Doba trvání:

  • Maximálně 10 (deset) pracovních dní.



Termín ukončení etapy:

  • Nejdéle dle harmonogramu plnění v souladu s Přílohou č. 8 Smlouvy.BUDE DOPLNĚNO PŘED PODPISEM SMLOUVY V SOULADU S DEFINOVANÝM TERMÍNEM ZAHÁJENÍ A DOBOU TRVÁNÍ.



Vstupy:

  • Účinná Smlouva, zadávací dokumentace, nabídka Poskytovatele v zadávacím řízení Veřejné zakázky, definovaná metodika řízení projektu.

Výstupy:

  • Nastavená detailní organizační struktura projektu v odpovídajícím členění.

  • Definovaný a oboustranně odsouhlasený harmonogram implementačního projektu:

    • Harmonogram bude plně v souladu s milníky souhrnně uvedenými v kapitole č. 3 této Přílohy č. 1 Smlouvy.

    • Úprava harmonogramu je možná pouze, pokud nedojde ke změně těchto uvedených milníků.

    • Detail harmonogramu musí v každé etapě/fázi projektu umožňovat realizaci projektových prací a odpovídající alokaci zdrojů na straně Poskytovatele i Objednatele, včetně zajištění odpovídající součinnosti třetích stran ze strany Objednatele pro konkrétní projektové úlohy.

  • Formálně odsouhlasené zahájení projektu dle stanoveného harmonogramu:

    • Xxxxxxxx projektu bude realizováno prostřednictvím Kick-off jednání projektu za účasti členů Řídícího Výboru projektu ze strany Poskytovatele i Objednatele a dalších případně přizvaných členů projektových týmů či pracovníků Poskytovatele i Objednatele.

    • Součástí zahájení projektu, a tedy Kick-off jednání, bude písemné odsouhlasení závazku používat definovanou projektovou metodiku a realizovat projekt v souladu se stanoveným harmonogramem projektu.

    • Svolání Kick-offu zajistí oprávněné osoby Poskytovatele i Objednatele nejpozději 10. (desátý) pracovní den po nabytí účinnosti Smlouvy, kdy jednání Kick-off bude mít formální charakter.

    • Před jednáním Kick-off může dojít ke dvěma jednáním k nastavení projektu, zároveň bude v průběhu doby trvání etapy probíhat průběžná komunikace tak, aby pro jednání Kick-off byly k dispozici veškeré nezbytné podklady a finální verze projektové dokumentace podléhající schválení na jednání.

Kritéria akceptace etapy:

  • Odsouhlasená projektová metodika a nastavení projektu.

  • Definovaná organizační struktura projektu.

  • Odsouhlasený projektový harmonogram dle stanovených milníků.

  • Formálně potvrzené zahájení projektu prostřednictvím Kick-off jednání nejpozději 10. (desátý) pracovní den od účinnosti Smlouvy.

2.2.2.2Předimplementační analýza

Předmět Etapy:

V rámci této etapy první fáze bude realizována analýza s cílem identifikovat veškeré informace a požadavky nezbytné pro návrh a Implementaci Systému. Výstupy analýzy pak budou využity pro návrh řešení Systému zahrnujícího mimo jiné Portálový systém SZIF a Portálové aplikace XXXX. Analýza zahrnuje několik dílčích položek:

  • Analýza prostředí SZIF a požadavků na výstavbu Systému,

  • Součinnost a spolupráce při návrhu řešení a přípravě zadání Portálových aplikací XXXX s Dodavatelem IS XXXX, tedy projektovým týmem integrační veřejné zakázky VZ IS XXXX,

  • Analýza zadání Portálových aplikací XXXX,

  • Detailní návrh řešení Systému zahrnující Portálový systém SZIF a Portálové aplikace XXXX.

Analýza musí probíhat koordinovaně s analýzou integračního projektu IS XXXX, přičemž koordinaci prací, projektových schůzek a dalších aktivit bude zajišťovat dodavatel IS XXXX.

Funkcionality IS XXXX, pro které budou Portálové aplikace XXXX představovat uživatelské rozhraní jsou rozděleny na tzv. Kritické funkčnosti - prioritní, které budou dodány jako součást implementačního projektudo 15. 9. 2022, a dále Kritické funkčnosti - ostatní a tzv. Požadované funkčnosti, které budou dodány v průběhu pilotního provozu. Vzhledem k tomu, že Systém představuje uživatelské rozhraní k IS XXXX, musí na základě prioritizace požadavků v IS XXXX být dovozeny priority požadavků na Systém Dodavatelem Systému, tedy této veřejné zakázky tak, aby pro Kritické funkcionality a Požadované funkcionality v IS XXXX byly vždy dodány odpovídající části uživatelských rozhraní implementovaných v Systému. Definice priorit je následující:

  • Kritická funkčnost – jedná se o takové funkčnosti informačního systému XXXX a Systému, které Objednatel stanovuje jako zcela nezbytné pro zajištění administrace Společné zemědělské politiky v takovém rozsahu, aby byly naplněny veškeré legislativní podmínky administrace na úrovni národní i Evropské legislativy a byl rovněž garantován výkon činností Objednatele jako akreditované Platební agentury; funkčnosti kategorie „Kritická“ budou prioritizovány do dvou skupin: Do skupiny „Kritická - prioritní“ a do skupiny „Kritická -ostatní“. Veškeré funkčnosti takto klasifikované jako „Kritická - prioritní“ musí být plně implementované, otestované a předané do rutinního produktivního používání již pro období Pilotního a akceptačního provozu. V případě nezajištění implementace Kritických funkčností „Kritická - prioritní“, jejich neotestování a nepředání do produktivního provozu nebude možné akceptovat implementační fázi (vlastní Implementaci) projektu XXXX a tohoto projektu a realizovat přechod do fáze Pilotního a akceptačního provozu. Funkčnosti „Kritická - ostatní“ musí být plně implementované, otestované a předané do rutinního produktivního používání do 31. 3. 2023.

  • Požadovaná funkčnost – jedná se o takové funkčnosti informačního systému XXXX a Systému, které jsou požadované pro zajištění plnohodnotného provozu informačního systému XXXX a Systému, nicméně mohou být testovány a uvolňovány do produktivního využívání v průběhu Pilotního a akceptačního provozu. Typicky se jedná o činnosti, které lze po dočasnou dobu zajistit jiným způsobem. V případě nezajištění implementace požadovaných funkčností, jejich neotestování a nepředání do produktivního provozu, nebude možné akceptovat fázi Pilotního a akceptačního provozu a realizovat přechod do standardního provozu s poskytováním navazujících služeb.



Předmětem etapy tak bude zejména:

  • Zahájení, realizace a akceptace analytických prací, které budou detailizovat a specifikovat funkční, technické a další požadavky na funkčnost Systému.

  • Definice naplnění jednotlivých požadovaných funkčností specifikovaných v rámci předmětu Smlouvy – kategorizace požadovaných funkčností a rozdělení priorit dle výše uvedených kritérií.

  • Precizace jednotlivých vrstev architektury Systému s vytvořením odpovídajících architektonických modelů Systému. V rámci solution architektury, případně aplikační architektury, budou veškeré požadované funkčnosti přiřazeny k jednotlivým architektonickým částem a SW komponentám využitým pro celkové řešení Systému. Toto přiřazení se v rámci akceptace Díla stane součástí komplexní dokumentace Systému, která bude následně kontinuálně udržovaná i po plné akceptaci Díla, aby bylo možné v kterýkoliv okamžik jednoznačně prokázat vazbu konkrétní SW komponenty a daných funkčností.

  • Příprava a odsouhlasení veškerých nezbytných architektonických a analytických dokumentací obsahující detailní návrh Systému dle standardů projektové a implementační dokumentace.

  • Příprava harmonogramu vlastní Implementace, který bude definovat průběh včetně souvisejících činností – implementační, integrační práce, testování, akceptace, uvolňování do produktivního prostředí.

Cíl Etapy:

  • Realizace analytických a přípravných prací nezbytných pro zahájení Implementace Systému.

  • Vytvoření a akceptace odpovídající architektonické dokumentace, na základě které bude možné realizovat Implementaci Systému.

  • Vytvoření a akceptace implementační dokumentace s definicí postupů Implementace a odpovědností na straně Poskytovatele i Objednatele.

  • Vytvoření harmonogramu dle definovaných pravidel a požadavků na dokumentaci, harmonogram bude definován takovým způsobem, aby detailně pokrýval jak fázi vlastní Implementace dle kapitoly 2.2.4. tohoto dokumentu (zahrnující implementaci minimálně veškerých Kritických funkčností - prioritních), tak Akceptační část služeb Pilotního a akceptačního provozu dle kapitoly 2.3.1.2. (zahrnující implementaci všech zbývajících funkčností). Harmonogram bude navržen a připraven v souladu s požadavky a milníky hlavního integračního projektu IS XXXX.





Termín zahájení etapy:

  • 11. (jedenáctý) pracovní den po nabytí účinnosti Xxxxxxx, tj. BUDE DOPLNĚNO PŘED PODPISEM SMLOUVY.



Doba trvání:

Dle harmonogramu plnění v souladu s Přílohou č. 8 Xxxxxxx.[DOPLNÍ POSKYTOVATEL - POSKYTOVATEL SPECIFIKUJE PŘEDPOKLÁDANOU NEZBYTNOU DOBU PRO REALIZACI ETAPY. NAVRHOVANÁ DOBA BUDE STANOVENA S OHLEDEM NA SPECIFIKACI PŘEDMĚTU PLNĚNÍ VEŘEJNÉ ZAKÁZKY, DEFINOVANÉ MINIMÁLNÍ TECHNICKÉ PODMÍNKY DÍLA, STANOVENOU PROJEKTOVOU METODIKU, POŽADAVKY NA DOKUMENTACI I DEFINOVANOU SOUČINNOST NEZBYTNOU PRO REALIZACI ETAPY.]



Termín ukončení etapy:

  • Nejdéle dle harmonogramu plnění v souladu s Přílohou č. 8 SmlouvyBUDE DOPLNĚNO PŘED PODPISEM SMLOUVY V SOULADU S DEFINOVANÝM TERMÍNEM ZAHÁJENÍ A DOBOU TRVÁNÍ.



Vstupy:

  • Definovaná metodika řízení projektu.

  • Stanovený harmonogram projektu.

  • Specifikace předmětu plnění Veřejné zakázky.

  • Technická dokumentace.

  • Legislativní a další podmínky stanovující podmínky implementace a provozu významných ISVS.

  • Standardy informační a kybernetické bezpečnosti – zejména ZoKB, ISO/IEC 27001



Výstupy:

  • Odpovídající analytická dokumentace a dokumentace architektury Systému, která bude splňovat požadavky na implementační dokumentaci dle kapitoly č. 6.4.5. Přílohy č. 5 Zadávací dokumentace a bude odpovídat principům řízení projektové dokumentace dle kapitoly č. 6.1. této Přílohy č. 5 Zadávací dokumentace. Analytická dokumentace a dokumentace architektury bude obsahovat kompletní přehled požadovaných funkčností a způsob jejich realizace v rámci Implementace včetně kategorizace funkčností na Kritické a Požadované.

    • Obsahem musí být minimálně:

      • Popis aplikační a softwarové architektury:

        • Blokové schéma komponent řešení – popis jednotlivých vrstev řešení, vymezení komponent / modulů a jejich vazeb, popis integrace na okolní systémy.

        • Rámcový způsob realizace jednotlivých komponent / modulů systému prostřednictvím standardizovaných SW technologií, jejich parametrizací, vývojem na míru a konfigurací.

        • Popis způsobu řešení přístupu uživatelů k aplikaci a způsob řešení uživatelských oprávnění s využitím IDM a dalších bezpečnostních nástrojů Objednatele.

        • Koncept monitoringu funkčnosti, dostupnosti a výkonnosti Systému na úrovni aplikace.

        • Koncept monitoringu a zajištění bezpečnosti Systému na úrovni aplikace a hostitelské infrastruktury.

        • Ergonomie Systému – popis řešení ergonomie a snadného ovládání uživateli z pohledu efektivity práce a logiky přístupu k informacím.

      • Požadavky na řízení infrastruktury pro zajištění rozvoje a následného provozu Systému:

        • Požadavky na řízení výkonu jednotlivých komponent Systému (kontejnerizace, clustering).

        • Požadavky na způsob zálohování, aby bylo možné splnit požadavky na navazující Služby.

        • Další požadavky na standardizovanou či cloudovou infrastrukturu infrastrukturu.

  • Implementační dokumentace Systému vypracovaná v souladu s kapitolou č. 6.1. Přílohy č. 5 Zadávací dokumentace obsahující minimálně:

    • Bezpečnostní část Implementace Systému

    • Harmonogram Implementace Systému, harmonogram bude obsahovat detailní plán realizace implementace Kritických funkčností (jak kategorie „Kritická prioritní“, tak kategorie „Kritická - ostatní“) a rámcový harmonogram realizace Požadovaných funkčností. ., jejichž Implementace funkčnosti Kritická – ostatní a Požadovaná bude realizována v rámci navazující fáze Pilotního a akceptačního provozu (v té budou realizovány i funkčnosti Kritické ostatní).

    • Definice všech publikovaných a konzumovaných rozhraní Systémem spolu s požadovanou součinností a požadavky na zajištění implementace/poskytování služeb třetích stran, a to zejména, nikoliv však výhradně, na následující prostředí:

      • Informační systém XXXX (IS XXXX)

      • Informační systém SZIF na platformě SAP

      • Informační systém LPIS

      • IDM prostředí Objednatele

      • Prostředí pro realizaci služeb SAMAS – vyhodnocování satelitních snímků

      • Prostředí pro realizaci služeb pro geotagované fotografie

    • Strategie testování a akceptační kritéria stanovená pro konkrétní požadované funkčnosti; Strategie testování bude obsahovat popis procesu testování, definici nezbytných realizovaných testů dle ZoKB a ISO 27001 minimálně v rozsahu:

      • Instalační testy

      • Funkční testy

      • Uživatelské testy

      • Integrační testy

      • Testy interní integrity dat

      • Bezpečnostní testy

      • Zátěžové testy

      • Testy obnovy Systému

  • Šablony vývojářské a provozní dokumentace, pokud tyto šablony nebyly zpracovány v rámci přípravy Projektové dokumentace.



    • Kritéria akceptace etapy:

      • Odsouhlasená analytická dokumentace a dokumentace architektury Systému.

      • Odsouhlasená implementační dokumentace.

      • Odsouhlasené šablony vývojářské a provozní dokumentace.

      • Formálně odsouhlasené zahájení fáze vlastní Implementace.

2.2.2.3Příprava Cloudových služeb pro provoz Systému

Předmět Etapy:

V rámci této etapy zajistí Poskytovatel vytvoření prostředí ve své vlastní infrastruktuře anebo infrastruktuře třetí strany (poddodavatele Poskytovatele) s využitím cloudových technologií a služeb uvedených dále tak, aby bylo možné zajistit Implementaci Systému dle specifikace Systému a jednotlivých architektonických, funkčních a dalších požadavků. Budou vytvořena prostředí pro tříúrovňovou architekturu zahrnující:

  • Produktivní prostředí (PROD) instalované v režimu vysoké dostupnosti (High availability - HA) – umístěné do dvou nezávislých lokalit.

  • Testovací prostředí (TEST) instalované v režimu vysoké dostupnosti (High availability - HA) – umístěné do dvou nezávislých lokalit.

  • Vývojové prostředí bez režimu vysoké dostupnosti (High availability - HA) – umístěné v jedné lokalitě.

Prostředí bude navrženo a vytvořeno tak, aby odpovídalo provozním parametrům a předpokládaným počtům uživatelů definovaným v Příloze č. 3 Smlouvy. Pro návrh a výstavbu Systému budou využity cloudové technologie, služby a postupy běžně využívané hlavními poskytovateli veřejných a privátních cloudových služeb v podobě kontejnerizace aplikací a jejich orchestrace tak, aby výsledné řešení bylo jednoduše migrovatelné mezi různými poskytovateli služeb provozu a rozvoje Systému.

Pro návrh, výstavbu a provoz Systému lze využít cloudové služby Dodavatele anebo třetí strany (i v podobě privátního cloudu) typů IaaS (Infrastructure as a Service), PaaS (Platform as a Service), SaaS (Software as a Service) či FaaS (Function as a Service).

Využité cloudové služby musí naplňovat následující požadavky:

  • cloudové služby mají certifikaci systému managementu bezpečnosti informací ISO 27001 (s uplatněním norem ISO 27017 pro bezpečnostní opatření u cloudových služeb a ISO 27018 o ochraně osobních údajů v cloudu),

  • externí subjekt (poskytovatel cloudových služeb) musí být pravidelně (min. 1x ročně) auditován v oblasti bezpečnosti informací, kontrolní protokoly a auditní zprávy musí být dostupné SZIF na vyžádání,

  • poskytovatel cloudových služeb musí splňovat a doložit pravidla pro ukládání a archivaci dat v rámci EU/EHP ve dvou geograficky oddělených lokalitách v EU/EHP; ukládání a archivace dat musí být prováděna ve dvou geograficky oddělených lokalitách v EU/EHP; nebude docházet k předávání osobních údajů mimo EU/EHP.

Pro přípravu cloudové infrastruktury a využití cloudových služeb dále platí:

  • Případné využití cloudových služeb musí být navrženo tak, aby byla zachována možnost migrace Systému k jinému poskytovateli cloudových služeb.

  • Komponenty vyvíjené na míru Objednatele anebo využité komerční komponenty tvořící řešení musí být kontejnerizovány a orchestrovány využitím kontejnerizačních a orchestračních technologií podporovaných hlavními poskytovateli veřejných a privátních cloudových služeb do podoby celkového řešení Systému tak, aby je bylo možné v případě potřeby přenést k jinému poskytovateli služeb provozu a rozvoje Systému či do on-premise infrastruktury Objednatele.

  • V případě využití IaaS a dalších PaaS služeb, musí být využity pouze takové standardní služby, jejichž obdobu lze čerpat i v případě hostování Systému v prostředí jiného poskytovatele služeb provozu a rozvoje.

  • Serverless funkcionality, resp. služby FaaS, mohou využívat některý z programovacích jazyků:

  • Java,

  • .NET,

  • Node.js (JavaScript nebo TypeScript kompilovaný do JavaScript),

  • Python,

  • Cloudové služby, zejména služby zajišťující ukládání a správu dat budou hostovány v datových centrech nacházejících se v lokalitách v EU/EHP.

  • Síťové propojení cloudové infrastruktury a on-premise prostředí Objednatele (datových center), pokud se bude jednat o dvě vzdálené lokality, bude realizováno dedikovanou, dostatečně výkonnou a maximálně zabezpečenou komunikační linkou. Připojení bude vytvořeno jako součást projektu. Propojení infrastruktury Systému (včetně případné cloudové infrastruktury) a on-premise prostředí Objednatele musí reflektovat skutečnost, že většina dat obsluhovaných Systémem je uložena v on-premise prostředí Objednatele (datových centrech). Systém k těmto datům přistupuje prostřednictvím API webových služeb publikovaných v lokalitě datového centra Objednatele. Síťové propojení musí umožňovat zajistit dostatečnou kapacitu a rychlost linky odpovídající vysokému objemu datových přenosů mezi prostředím Systému (včetně případně lokality cloudu) a on-premise infrastrukturou Objednatele.

  • Pro zajištění bezpečnosti Systému a jím poskytovaných služeb je možné využít IaaS cloudové služby.

  • Všechny využité cloudové služby (bez ohledu na skutečnost, zda se jedná o veřejný či privátní cloud) budou na straně poskytovatele cloudu pravidelně aktualizovány tak, aby byl minimalizován výskyt chyb a rizik souvisejících s případnými zranitelnostmi cloudových služeb.

  • Cena cloudových služeb potřebných po dobu Implementace funkcionalit kategorie „Kritická - prioritní“) (tj. před zahájením Pilotního a ověřovacího provozu) je zahrnuta do ceny Díla (položky Příprava cloudových služeb pro provoz Systému). Cena cloudových služeb od zahájení Pilotního a akceptačního provozu bude účtována dle skutečného čerpání v souladu s pravidly dle Přílohy č. 3 a 7 této Smlouvy. Cena Správy cloudových služeb pro provoz a rozvoj Systému a reporting čerpání cloudových služeb (odpovídá aktivitě A19 Služeb provozu dle přílohy č. 3 této Smlouvy) bude po dobu Pilotního a akceptačního provozu zahrnuta v měsíční paušální ceně Pilotního a akceptačního provozu.

  • Infrastruktura a její konfigurace musí být exportovatelné v podobě konfigurací (IaaC – Infrastracture as a Code), přičemž musí být využity standardy běžně podporované většinou poskytovatelů cloudových služeb.

  • Součástí poskytovaných (případně cloudových) služeb budou i nástroje pro řízení projektu využitím agilního přístupu – DEV-OPS, pokrývající celý životní cyklus návrhu, nasazení a rozvoje služby. Nástroje budou zahrnovat:

    • Repositář pro správu zdrojových kódů, jiných artefaktů a jejich verzování s využitím technologií GIT,

    • Správu požadavků,

    • Projektové řízení pro agilní týmy,

    • Automatizované sestavování programů (Continuous Integration),

    • Testování,

    • Release management – řízené nasazování nových verzí.

V rámci etapy přípravy cloudových služeb budou realizovány takové práce, které umožní realizaci následné implementace přenositelného Systému.

Cíl Etapy:

Zajistit přípravu cloudové infrastruktury a služeb pro Implementaci Systému a nasazení do všech výše uvedených prostředí.



Termín zahájení etapy:

[DOPLNÍ POSKYTOVATEL - POSKYTOVATEL STANOVÍ TERMÍN ZAHÁJENÍ ETAPY NA ZÁKLADĚ SVÝCH EXPERTNÍCH ZNALOSTÍ TAK, ABY BYLO MOŽNÉ ZAJISTIT IMPLEMENTACI SYSTÉMU A UVEDENÍ DO PILOTNÍHO A AKCEPTAČNÍHO PROVOZU V SOULADU SE STANOVENÝMI MILNÍKY.]



Doba trvání:

[DOPLNÍ POSKYTOVATEL - POSKYTOVATEL DEFINUJE DOBU TRVÁNÍ NA ZÁKLADĚ SVÝCH EXPERTNÍCH ZNALOSTÍ TAK, ABY BYLO MOŽNÉ ZAJISTIT IMPLEMENTACI SYSTÉMU A UVEDENÍ DO PILOTNÍHO A AKCEPTAČNÍHO PROVOZU V SOULADU SE STANOVENÝMI MILNÍKY.]



Termín ukončení etapy:

[DOPLNÍ POSKYTOVATEL - POSKYTOVATEL STANOVÍ TERMÍN UKONČENÍ ETAPY NA ZÁKLADĚ SVÝCH EXPERTNÍCH ZNALOSTÍ TAK, ABY BYLO MOŽNÉ ZAJISTIT IMPLEMENTACI SYSTÉMU A UVEDENÍ DO PILOTNÍHO A AKCEPTAČNÍHO PROVOZU V SOULADU SE STANOVENÝMI MILNÍKY.]



Vstupy:

  • Technická dokumentace – Příloha č. 5 zadávací dokumentace,

  • Technická dokumentace – Příloha č. 6 zadávací dokumentace,

  • Technické řešení – Příloha č. 2 Xxxxxxx,

  • Harmonogram Implementace,

  • Metodika řízení projektu Implementace.



Výstupy:

  • Připravená cloudová infrastruktura a služby ve všech výše uvedených prostředích pro realizaci Implementace a provoz Systému,

  • Dokumentace infrastruktury, v případě cloudu s přehledem všech cloudových služeb využitých pro provoz Systému, jejich základních parametrů,

  • IAAC (Infrastructure as a Code) zdrojové a konfigurační soubory uložené v repositáři zdrojových kódu projektu a předané Objednateli na přenosném digitálním médiu, případně další zdrojové a konfigurační soubory využitých cloudových služeb.



Kritéria akceptace etapy:

  • Odsouhlasená dokumentace a předané zdrojové a konfigurační soubory.

2.2.3Vlastní implementace Díla (Systému)

V rámci této fáze bude, v souladu se schválenou implementační dokumentací a stanoveným projektovým harmonogramem, probíhat vlastní Implementace Systému. Zároveň bude vytvářena kompletní provozní, technická a ostatní dokumentace Systému v souladu s pravidly definovanými ve stanovené metodice řízení projektu implementace.

Implementace Systému pokrývá dvě základní části Systému:

  • Portálový systém SZIF,

  • Portálové aplikace XXXX.

2.2.3.1Implementace Portálového systému SZIF

Předmět:

V této dílčí části implementace Systému bude navržen a vytvořen univerzální Portálový systém SZIF umožňující nasazovat a provozovat jednotlivé portálové aplikace. První nasazené a provozované aplikace budou Portálové aplikace XXXX. Pro výstavbu Portálového systému SZIF mohou být využity:

  • softwarové komponenty navržené a vyvinuté na míru Objednatele v rámci projektu,

  • existující komerční či jiné komponenty třetích stran,

  • cloudové služby standardního charakteru, které mohou být nahrazeny podobnými cloudovými službami v prostředí jiného poskytovatele cloudových služeb (např. databázové služby, služby úložiště dat, atd.),

  • cloudové serverless služby s možností využití programovacích jazyků uvedených v kapitole 10.2 přílohy č. 5 zadávací dokumentace.

Veškeré software komponenty vyvinuté na míru Objednatele a komerční komponenty třetích stran musí být implementovány či připraveny jako kontejnerizované služby nebo být jejich součástí tak, aby je bylo možné v případě potřeby jednoduše migrovat k jinému poskytovateli služeb provozu a rozvoje či do on-premise prostředí Objednatele.

Vstupy:

  • Požadavky na Portálový systém SZIF vyplývající ze zadávací dokumentace,

  • Požadavky na Systém identifikované v průběhu předimplementační analýzy,

  • Zadání připravené v rámci souvisejícího projektu IS XXXX a požadavky identifikované v průběhu tohoto projektu,

  • Příloha č. 5 zadávací dokumentace - Specifikace předmětu plnění veřejné zakázky,

  • Příloha č. 6 zadávací dokumentace - Technická dokumentace – NDA,

  • Příloha č. 2 Smlouvy - Technické řešení.

Výstupy:

  • Funkční Portálový systém SZIF nasazený ve vývojovém, testovacím a produkčním prostředí.

  • Všechny artefakty nezbytné pro překlad a nasazení Portálového systému SZIF včetně případného Docker image jednotlivých služeb a zdroje pro orchestraci celého řešení v prostředí Poskytovatele Služeb či v cloudovém prostředí. Artefakty budou předány prostřednictvím repositáře či jiných nástrojů pro vývoj dostupných jako součást poskytovaných Služeb. Z tohoto repositáře prováděn překlad a nasazení celého řešení do všech prostředí Systému (vývoj, test, produkce).

2.2.3.2Implementace Portálových aplikací XXXX

V této části Díla budou navrženy, implementovány a nasazeny Portálové aplikace XXXX v prostředí Portálového systému SZIF dle zadání připraveného v rámci souvisejícího projektu IS XXXX. Zadání může existovat i ve formě backlog či jiné podobě v závislosti na využité metodice projektové řízení a vývoje zvolené v rámci projektu IS XXXX. Jako podklad pro Implementaci bude zároveň využit i výstup Předimplementační analýzy. Pro výstavbu Portálových aplikací XXXX budou využity sdílené služby, komponenty a framework Portálového systému SZIF. Pravidla pro využití software komponent a požadavek na jejich kontejnerizaci, pokud budou pro implementaci potřeba, jsou obdobná jako v případě Portálového systému SZIF.

Vstupy:

  • Požadavky na Portálové aplikace XXXX vyplývající ze zadávací dokumentace,

  • Požadavky na systém identifikované v průběhu předimplementační analýzy,

  • Zadání připravené v rámci souvisejícího projektu IS XXXX a požadavky identifikované v průběhu tohoto projektu,

  • Příloha č. 5 zadávací dokumentace - Specifikace předmětu plnění veřejné zakázky,

  • Příloha č. 6 zadávací dokumentace - Technická dokumentace – NDA,

  • Příloha č. 2 Smlouvy - Technické řešení.

Výstupy:

  • Funkční Portálové aplikace XXXX nasazené ve všech prostředích Portálového systému SZIF, případně jejich nová verze v případě inkrementálního/postupného vývoje. Portálové aplikace XXXX anebo jejich inkrementální části jsou plně funkční a integrované na všechny kooperující systémy zahrnující Integrační platformu XXXX, Portál farmáře SAP, Systém GT-Foto, Geografický informační systém (GIS) a Portál MZe.

  • Všechny artefakty nezbytné pro vytvoření image kontejnerů jednotlivých služeb a vyžadované pro řádné nasazení a orchestraci celého řešení v cloudovém prostředí Poskytovatele či třetí strany, pokud budou aplikace v této podobě implementovány (tedy nebudou budovány a nasazovány přímo prostředky Portálového systému SZIF). Artefakty budou předány prostřednictvím repositáře či jiných nástrojů pro vývoj dostupných jako součást poskytovaných Služeb. Z tohoto repositáře či jiných systémů bude možné provést kompletní překlad a nasazení Portálových aplikací XXXX do všech prostředí (vývoj, test, produkce), pokud aplikace nebudou budovány a nasazovány přímo prostředky Portálového systému SZIF.

2.2.3.3ZPŮSOB VLASTNÍ Implementace sYSTÉMU

[DOPLNÍ POSKYTOVATEL - POSKYTOVATEL SPECIFIKUJE ZPŮSOB VLASTNÍ IMPLEMENTACE PORSYS A PORMACH TAKOVÝM ZPŮSOBEM, ABY TATO ČÁST ODPOVÍDALA PŘEDCHOZÍ STRUKTUŘE SMLOUVY. TEDY V SOULADU S NAVRHOVANOU METODIKOU ŘÍZENÍ PROJEKTU IMPLEMENTACE, STANOVENÝMI ZADÁVACÍMI PODMÍNKAMI, NAVRHOVANÝM TECHNICKÝM ŘEŠENÍM A ARCHITEKTUROU NAVRHNE ČLENĚNÍ FÁZE IMPLEMENTACE DO JEDNOTLIVÝCH DÍLČÍCH ETAP TAK, ABY VEŠKERÉ ČINNOSTI IMPLEMENTACE NA SEBE LOGICKY A VĚCNĚ NAVAZOVALY, PŘÍPADNĚ BYLY REALIZOVÁNY PARALELNĚ TAM, KDE TO JE MOŽNÉ.



DEFINOVANÝ ZPŮSOB IMPLEMENTACE MUSÍ BEZPODMÍNEČNĚ SPLŇOVAT A POKRÝVAT NÁSLEDUJÍCÍ SOUČÁSTI:

- VEŠKERÉ PROCESY IMPLEMENTACE MUSÍ BÝT V SOULADU S PARAMETRY ISO 27001, TEDY ZEJMÉNA:

  • NAPLNĚNÍ BEZPEČNOSTNÍCH POŽADAVKŮ INFORMAČNÍCH SYSTÉMŮ (ČÁST A.14.1 NORMY)

  • ZAJIŠTĚNÍ BEZPEČNOSTI V PROCESECH VÝVOJE A PODPORY (ČÁST A.14.2 NORMY)

  • ZAJIŠTĚNÍ OCHRANY DAT PRO TESTOVÁNÍ (ČÁST A.14.3 NORMY)



- SOUČÁSTÍ PROCESŮ IMPLEMENTACE MUSÍ BÝT POSTUPY PRO TESTOVÁNÍ IMPLEMENTOVANÝCH FUNKCIONALIT, MIGRACI DO PRODUKTIVNÍHO PROSTŘEDÍ (RELEASE).

- PROCESY IMPLEMENTACE MUSÍ PODLÉHAT FORMALIZOVANÉMU ZPŮSOBU AKCEPTACE, KDY PROCES AKCEPTACE MUSÍ UMOŽŇOVAT PROKAZATELNÉ VYHODNOCENÍ NAPLNĚNÍ POŽADAVKU, KTERÝ JE PŘEDMĚTEM KONKRÉTNÍHO IMPLEMENTAČNÍHO KROKU (PŘÍKLAD - V PŘÍPADĚ POŽADAVKU NA IMPLEMENTACI ČÍSELNÍKU, JEHOŽ SPRÁVU MÁ V PROVOZNÍM PROSTŘEDÍ ZAJIŠŤOVAT ZAMĚSTNANEC OBJEDNATELE, MUSÍ BÝT V RÁMCI IMPLEMENTACE OVĚŘENO, ŽE KONKRÉTNÍ ČÍSELNÍK JE NAIMPLEMENTOVÁN V INFORMAČNÍM SYSTÉMU TAKOVÝM ZPŮSOBEM, KDY VEŠKERÉ FUNKCIONALITY NA TENTO ČÍSELNÍK NAVÁZANÉ FUNGUJÍ KOREKTNĚ V SOULADU SE ZADÁNÍM, ŽE PRO SPRÁVU ČÍSELNÍKU JE K DISPOZICI ODPOVÍDAJÍCÍ UŽIVATELSKÉ ROZHRANÍ, SPRÁVA ČÍSELNÍKU JAKO TAKOVÁ JE MOŽNÁ POUZE S KONKRÉTNÍM PŘIDĚLENÝM OPRÁVNĚNÍM, KTERÉ SI NEMŮŽE PŘIDĚLIT ZAMĚSTNANEC SPRAVUJÍCÍ ČÍSELNÍK SÁM. V RÁMCI SYSTÉMU JSOU NASTAVENÉ A FUNKČNÍ TAKOVÉ MECHANISMY, KTERÉ ZAJISTÍ, ŽE UŽIVATELSKÝM ZÁSAHEM DO ČÍSELNÍKU NEDOJDE K NARUŠENÍ HISTORICKÝCH DAT, TEDY SYSTÉMOVÉ NASTAVENÍ ČÍSELNÍKU BUDE UMOŽŇOVAT VERZOVÁNÍ A NAVAZUJÍCÍ FUNKCIONALITY BUDOU STANDARDNĚ RESPEKTOVAT NEJEN UŽIVATELSKÉ NASTAVENÍ PLATNOSTI ČÍSELNÍKU, ALE ROVNĚŽ SYSTÉMOVÝ ČAS PROVEDENÉ ZMĚNY).

- SOUČÁSTÍ AKCEPTACE MUSÍ BÝT VYTVOŘENÍ ODPOVÍDAJÍCÍ DOKUMENTACE VČETNĚ ŠKOLÍCÍ A UŽIVATELSKÉ DOKUMENTACE. TAM, KDE JE TO ÚČELNÉ, MUSÍ BÝT SOUČÁSTÍ I SAMOTNÉ ŠKOLENÍ UŽÍVATELŮ NEBO KLÍČOVÝCH UŽIVATELŮ. POŽADAVKY NA ŠKOLENÍ VZNESENÉ ZE STRANY ZAMĚSTNANCŮ OBJEDNATELE PODÍLEJÍCÍCH SE NA IMPLEMENTACI MUSÍ BÝT PRO POSKYTOVATELE ZÁVAZNÉ.

- AKCEPTACE NESMÍ BÝT JEDNOKROKOVÁ, TEDY AKCEPTACÍ DÍLČÍCH IMPLEMENTOVANÝCH CELKŮ NEBUDE POTVRZENA AKCEPTACE CELÉHO SYSTÉMU. AKCEPTAČNÍ PROCES V RÁMCI TÉTO FÁZE IMPLEMENTACE SYSTÉMU MUSÍ ZAHRNOVAT PLNÝ ROZSAH NEZBYTNÝCH TESTŮ V SOULADU SE STANOVENOU STRATEGIÍ TESTOVÁNÍ. PLNÝ AKCEPTAČNÍ PROCES MUSÍ BÝT NAVRŽEN TAKOVÝM ZPŮSOBEM, ABY POSTIHOVAL OVĚŘENÍ JAK DÍLČÍCH FUNKČNOSTÍ, TAK CHOVÁNÍ SYSTÉMU JAKO CELKU. ZÁROVEŇ TENTO AKCEPTAČNÍ PROCES MUSÍ POSTIHOVAT VEŠKERÉ POŽADAVKY NA VYTVOŘENÍ A OVĚŘENÍ ODPOVÍDAJÍCÍ DOKUMENTAČNÍ ZÁKLADNY SYSTÉMU. AKCEPTAČNÍ PROCES BUDE DEFINOVÁN JAKO "PODMÍNĚNÝ", STEJNĚ TAK AKCEPTACE REALIZOVANÁ V RÁMCI TÉTO FÁZI NEBUDE KONEČNOU AKCEPTACÍ DODÁVKY DÍLA (SYSTÉMU).

PRO KAŽDOU ETAPU IMPLEMENTACE BUDOU DEFINOVÁNY NÁSLEDUJÍCÍ PARAMETRY:

- PŘEDMĚT ETAPY

- CÍL ETAPY

- TERMÍN ZAHÁJENÍ ETAPY

- DOBA TRVÁNÍ ETAPY

- TERMÍN UKONČENÍ ETAPY

- VSTUPY

- VÝSTUPY

- KRITÉRIA AKCEPTACE ETAPY

POKUD BUDE POSKYTOVATEL VYUŽÍVAT TAKOVOU METODIKU IMPLEMENTACE, KTERÁ OBSAHUJE AGILNÍ ZPŮSOB ŘÍZENÍ IMPLEMENTACE A NENÍ TEDY VHODNÉ PRO TAKOVÝTO ZPŮSOB IMPLEMENTACE DEFINOVAT UVEDENÉ PARAMETRY STRIKTNĚ, NAVRHNE A DEFINUJE POSKYTOVATEL TAKOVÉ PROCESY IMPLEMENTACE, ZE KTERÝCH BUDE NADE VŠÍ POCHYBNOST ZŘEJMÉ, JAKÝM ZPŮSOBEM BUDE IMPLEMENTACE JAKO CELEK PROBÍHAT TAK, ABY BYLY V RÁMCI IMPLEMENTACE ZAJIŠTĚNÉ VEŠKERÉ NEZBYTNÉ SOUČÁSTI STANOVENÉ VÝŠE.]

2.3Pilotní a akceptační provoz

Služby Pilotního a akceptačního provozu jsou poskytovány ve dvou průběžných oblastech – Akceptační část služeb a Pilotní část služeb, služby v těchto oblastech jsou poskytovány kontinuálně a opakovaně dle definic jednotlivých částí služeb.

Dále je součástí Pilotního a akceptačního provozu etapa Finální akceptace Díla (Systému), jejímž cílem je potvrdit celkový soulad nastavení Systému s definovanými požadavky, finalizovat veškerou nezbytnou dokumentaci pro zajištění akceptace Díla jako celku, aby bylo možné ukončit plnění této části Smlouvy a zahájit plnění navazujících Služeb v souladu s Přílohou č. 3 Smlouvy.

2.3.1Kontinuálně zajišťované oblasti Pilotního a akceptačního provozu

2.3.1.1Součinnost v rámci Pilotního a akceptačního provozu

Součinnost bude v průběhu pilotního a akceptačního provozu poskytována v následujícím rozsahu:

  • V pracovní dny mezi 9-17 hodinou 1 FTE (Full Time Equivalent – při 8 hodinové pracovní době) zaměstnanců Objednatele zodpovědných za věcnou část implementace Systému – tedy zaměstnance, kteří budou fakticky zodpovídat za věcné nastavení funkčnosti Systému.

  • V pracovní dny mezi 9-17 hodinou 0,5 FTE (Full Time Equivalent – při 8 hodinové pracovní době) zaměstnanců Objednatele zodpovědných za projektovou, technickou a informačně bezpečnostní část implementace Systému – tedy zaměstnance, kteří budou zodpovídat za technické, infrastrukturní, bezpečnostní a projektové podmínky – bezpečnostní architektura, solution architektura a na SZIF zajišťují chod a fungování ICT technologií včetně projektového řízení a řízení ISMS.

  • V pracovní dny mezi 7-19 hodinou Service Desk Objednatele – 1. úroveň podpory pro zajištění 2. úrovně podpory třetích stran a 2. úrovně podpory ze strany Objednatele.

  • 0,5 FTE (Full Time Equivalent – při 8 hodinové pracovní době) pracovníků Dodavatelů, zajišťujících návrh, implementaci a následný provoz IS XXXX, provoz a rozvoj dalšího aplikačního prostředí IS SZIF, na který bude Systém integrován; poskytování externích služeb nezbytných pro implementaci Systému (např. správa GT FOTO, SAP portál).

2.3.1.2Akceptační část služeb

Akceptační část služeb bude realizována kontinuálně po dobu 9 15,5 měsíců od ukončení fáze vlastní Implementace funkcionalit Kritických - prioritních. Přestože budou služby realizovány kontinuálně, budou řízeny v souladu s definovanou projektovou a implementační metodikou a dle schváleného, či průběžně aktualizovaného projektového harmonogramu.

Předmět služeb:

Předmětem poskytovaných služeb je vývoj/customizace a průběžná Implementace dílčích funkčností Systému, jejichž realizace nebyla dokončena/provedena v průběhu fáze vlastní Implementace funkcionalit Kritických - prioritních. Mimo jiné se toto týká funkcionalit, které byly klasifikovány jako Požadované a Kritické - ostatní. Poskytování služeb bude realizováno tak, aby docházelo ke kontinuálnímu předávání jednotlivých částí Systému do plnohodnotného provozu. Součástí bude průběžné testování těchto dílčích funkčností kategorie Požadovaná a Kritické - ostatní, jejich postupné uvolňování do produktivního provozu, kde budou jednotlivé funkčnosti ověřovány na základě již dostupných produktivních dat vznikajících v průběhu administrace dotačních opatření a bude potvrzena jejich dílčí akceptace.

Předmětem služeb je rovněž finální ověření chování Kritických funkčností v ostrém provozu, kdy bude ověřeno, že se jednotlivé implementované funkčnosti chovají korektně i při využití plných produktivních dat a při integraci na další produktivní prostředí IS SZIF a jiné integrované systémy.



Nezbytný vstup:

  • Realizovaná Akceptace vlastní Implementace.

  • Nastavená projektová a implementační metodika a pravidla pro dokumentaci.

  • Platný projektově řízený harmonogram implementace pro Akceptační část služeb Pilotního a akceptačního provozu.



Požadovaný výstup služeb:

  • Dokončené Dílo - Systém dle stanovených požadavků zahrnujících veškeré definované funkčnosti.

  • Dokumentace Systému nezbytná k zahájení Finální akceptace Díla (Systému).

  • Projektová dokumentace nezbytná k zahájení Finální akceptace Díla (Systému).



Termín zahájení poskytování služeb:

  • 1. pracovní den po ukončení Implementace informačního systému v části funkcionalit Kritických - prioritních (nejpozději 31. 315. 9. 2022).



Doba trvání:

  • 9 15,5 kalendářních měsíců



Termín ukončení etapy:

  • Nejpozději 31. 12. 20232



Kritéria akceptace služeb:

  • Veškeré definované funkčnosti jsou uvolněné do produktivního provozu a jsou formálně potvrzené akceptace všech těchto funkčností.

  • Je implementována a funkční kompletní integrace funkčností na další prostředí informačního systému SZIF a formálně potvrzena akceptace dílčích integrací.

  • Je připravena veškerá nezbytná dokumentace pro zahájení Finální akceptace Díla (Systému).

2.3.1.3Pilotní část služeb

Pilotní část služeb bude realizována kontinuálně po dobu 12 18,5 měsíců od ukončení fáze vlastní Implementace funkcionalit Kritických - prioritních. Pro poskytování pilotní části služeb bude nominován Provozní projektový tým, ve složení odpovídajícím Organizačnímu zajištění poskytování služeb dle kapitoly č. 2 Přílohy č. 3 Smlouvy, který bude zajišťovat kontinuální poskytování služeb ze strany Poskytovatele i nezbytné činnosti a součinnosti ze strany Objednatele potřebné k realizaci těchto služeb.

Termín zahájení poskytování služeb:

  • 1. pracovní den po ukončení Implementace informačního systému v části funkcionalit Kritických - prioritních (nejpozději 31. 315. 9. 2022).



Doba trvání:

  • 12 18,5 kalendářních měsíců



Termín ukončení poskytování služeb:

  • Nejpozději 31. 3. 20234

Jednotlivé aktivity zajišťované v průběhu pilotní části služeb a jejich parametry jsou definovány v následujících katalogových listech:

Označení

Název Aktivity

A01

Vlastní provoz a správa aplikační vrstvy Systému

Rozsah aktivity

Popis (obsah) aktivity

Kontinuální provozní aktivita


Poskytovatel služby bude zajišťovat stálý provoz všech jednotlivých modulů a komponent Systému, jejichž implementace byla předmětem Dodání Díla. Předmětem provozu je zajištění komplexního Systému včetně infrastruktury v prostředí Dodavatele, třetí strany či cloudovém prostředí. Provoz bude zajištěn pro veškeré komponenty

umístěné v prostředích:

- PROD

- TEST

- DEV


Předmětem služby je zajištění korektní funkcionality veškerých postupně do produktivního prostředí uvolňovaných funkčností Systému.


Předmětem služby je rovněž zajištění všech náležitostí pro korektní průběh integračních vazeb na jiné systémy v rozsahu dle implementačních a provozních potřeb definovaných v implementačním harmonogramu.


Poskytovatel bude vykonávat všechny činnosti vedoucí k bezproblémovému chodu produktivního, testovacího, vývojového prostředí Systému.


Funkčnost prostředí musí odpovídat požadované dostupnosti (viz dále) a odezvám jednotlivých funkčností v souladu s akceptační a provozní dokumentací Systému.


Součástí provozu jsou komplexní expertní služby Poskytovatele nezbytné pro vlastní korektní fungování implementovaných funkčností dostupných v jednotlivých prostředích a modulech. Z hlediska provozu Systému je tedy za korektně provozované prostředí považováno takové prostředí, které je nejen dostupné a funkční, ale rovněž veškeré funkčnosti jsou dostupné určeným koncovým uživatelům/případně integrovaným aplikacím a systémům.

Doba zajištění aktivity

7x24 – provozní doba znamená zajištění služeb v pracovní i nepracovní dny 24 hodin denně.

Do provozní doby není započítávána doba pro Servisní okno. Servisní okno je definováno od soboty 00:00 do neděle 24:00 každý 1. víkend v měsíci, využití tohoto času je podmíněno souhlasem Objednatele (Vedoucí, nebo Garant Projektového týmu provozu).




SLA parametry / Vyhodnocení

Definice

Požadovaná hodnota

Vyhodnocení

Dostupnost – TEST/DEV

Za dostupné se považuje testovací/vývojové prostředí Systému, které poskytuje korektní fungování implementovaných a akceptovaných funkčností koncovému uživateli/systému.

95 % provozní doby

Do doby dostupnosti v rámci vyhodnocovacího období není započítávána doba, během které se vyskytne Vada Systému kategorie A, B, nebo X.

Xxxxxxxxx je definována v kapitole č. 4.

Dostupnost – PROD

Za dostupné se považuje produktivní prostředí Systému, které poskytuje korektní fungování implementovaných a akceptovaných funkčností koncovému uživateli/systému.

97,5 % provozní doby

Do doby dostupnosti v rámci vyhodnocovacího období není započítávána doba, během které se vyskytne Vada Systému kategorie A, B, nebo X.

Xxxxxxxxx je definována v kapitole č. 4.

Odezva – TEST/DEV

50 % provozní doby zobrazení stránky do 5 sekund (načtení viditelného obsahu stránky)

Do doby odezvy v rámci vyhodnocovacího období není započítávána doba, během které se vyskytne Vada Systému kategorie A, B, nebo X.

Xxxxxxxxx je definována v kapitole č. 4.

Odezva – PROD

90 % provozní doby zobrazení stránky do 5 sekund (načtení viditelného obsahu stránky)

Do doby odezvy v rámci vyhodnocovacího období není započítávána doba, během které se vyskytne Vada Systému kategorie A, B, nebo X.

Xxxxxxxxx je definována v kapitole č. 4.

Vada Systému Kategorie „A“ – Vysoká významnost

Popis vady:

Implementovanou Funkčnost není možné produktivně používat, neexistuje, nebo nebylo poskytnuto náhradní řešení. Chyba funkčnosti nebyla odstraněna do 2 hodin (kalkulováno v rámci Doby zajištění aktivity) od okamžiku nahlášení prostřednictvím Service Desku, rovněž v této lhůtě nebylo poskytnuto náhradní řešení.

Maximální počet Vad/vyhodnocovací období:


v PROD prostředí: 3

v TEST prostředí: N/A

Kreditace je definována v kapitole č. 4.

Vada Systému Kategorie „B“ – Střední významnost

Popis vady:

Implementovanou Funkčnost není možné produktivně používat v plném rozsahu, Poskytovatel zajistil náhradní řešení. Chyba funkčnosti nebyla odstraněna do 16 hodin od okamžiku nahlášení incidentu prostřednictvím Service Desku.

Maximální počet Vad/vyhodnocovací období:


v PROD prostředí: 6

v TEST prostředí: N/A

Kreditace je definována v kapitole č. 4.

Vada Systému Kategorie „C“ – Nízká významnost

Popis vady:

Implementovanou Funkčnost je možné produktivně používat s dílčím omezením, které nemá vliv na samotné chování Systému. Chyba funkčnosti nebyla odstraněna do 40 hodin od nahlášení Incidentu prostřednictvím Service Desku.

Maximální počet Vad/vyhodnocovací období:


v PROD prostředí: 8

v TEST prostředí: N/A

Kreditace je definována v kapitole č. 4.

Výpočet celkové dostupnosti Systému v průběhu vyhodnocovacího období:


Požadovaná doba dostupnosti (hod) = (počet dní v kalendářním měsíci*24 hodin) – Celková doba plánovaných odstávek v daném kalendářním měsíci (hod)


Reálná doba dostupnosti (hod) = Požadovaná doba dostupnosti – Celková doba nedostupnosti v rámci Požadované doby dostupnosti


Kde Celková doba nedostupnosti v rámci Požadované doby dostupnosti se vypočte takto:

  • Budou vybrány všechny časové intervaly, v nichž se služba Systému nalézala ve stavu vady kategorie A, B a provede se sjednocení těchto intervalů. Tím dostaneme množinu časových intervalů, v nichž byla služba Systému nedostupná z důvodu vady.

  • Od této množiny odečteme průnik této množiny s množinou intervalů, po které trvaly plánované odstávky (v době plánované odstávky služba být dostupná nemusí).

  • Součet délek intervalů ve výsledné množině je Celková doba nedostupnosti v rámci Požadované doby dostupnosti.


Skutečná dostupnost (%) = Reálná doba dostupnosti (hod) / Požadovaná doba dostupnosti (hod)* 100



Výpočet odezvy Systému v průběhu vyhodnocovacího období:


Požadovaná doba v limitu odezvy (hod) = (počet dní v kalendářním měsíci*24 hodin) – Celková doba plánovaných odstávek v daném kalendářním měsíci (hod)


Reálná doba v limitu odezvy (hod) = Požadovaná doba v limitu odezvy – (Celková doba trvání Vad A (hod) + Celková doba trvání Vad B (hod) + Celková doba trvání Vad C (hod))


Skutečná odezva (%) = Reálná doba v limitu odezvy (hod) / Požadovaná doba v limitu odezvy (hod)


Požadované výstupy aktivity

Název výstupu

Charakteristika

Způsob akceptace

Zpráva o plnění Pilotní části služeb

Pro akceptaci poskytování služeb v rámci vyhodnocovacího období bude zpracována souhrnná Zpráva o plnění Pilotní části služeb, která bude vycházet primárně z dat provozního monitoringu a dat Service Desku. Součástí Zprávy bude i soupis všech dob incidentů s vyznačením, který incident svojí dobou řešení a dopadem byl klasifikován jako Vada s vyznačením kategorie a doby trvání Vady dle stanovených SLA parametrů. Tato Zpráva bude zahrnovat i ostatní aktivity plnění Pilotní části služeb.

Pro akceptaci Zprávy o plnění pilotní části služeb se uplatní postup stanovený v rámci aktivity A09.

Způsob stanovení celkové ceny aktivity a fakturace

Měsíční paušální cena

Celková cena aktivity za vyhodnocovací období (kalendářní měsíc) bude zahrnuta v paušální měsíční ceně za poskytování služeb Pilotního a akceptačního provozu pro celé prostředí Systému.


Fakturace je realizována za každé vyhodnocovací období (kalendářní měsíc) se zohledněním příslušné kreditace.





Označení

Název Aktivity

A02

Aktualizace dat/kopie

Rozsah aktivity

Popis (obsah) aktivity

Provozní aktivita na vyžádání


V rámci této aktivity zajistí Poskytovatel na vyzvání Objednatelem kopii produktivních dat do testovacího prostředí (TEST), aby bylo možné v testovacím prostředí zajistit kompletní simulaci interních business procesů Objednatele. Objednatel v rámci požadavku na provedení kopie specifikuje rozsah kopírovaných dat i dotčenou komponentu/komponenty tak, aby bylo možné kopii realizovat. Požadavek zašle Garant projektového týmu provozu nebo Vedoucí projektového týmu provozu (za Objednatele) prostřednictvím Service Desku. Tito jediní pracovníci Objednatele jsou oprávněni autorizovat provedení Aktualizace/kopie dat.

Kopie dat musí být realizována takovým způsobem, aby nezpůsobila nekonzistence v aplikační logice připraveného testovacího prostředí. Kopie funkcionalit, ve které dojde k nahrazení aplikační logiky testovacího prostředí, je možná pouze na výslovné schválení či požadavek Objednatele. V případě, že se Poskytovatel a provozovatel infrastruktury dohodnou, že existuje vhodnější způsob přípravy kopie dat (například klon systému), je toto možné realizovat pouze v případě schválení navrhovaného řešení uvedenými kontaktními osobami.

Doba zajištění aktivity

Na vyžádání max. 6 krát během období poskytování Pilotní části služeb.


SLA parametry / Vyhodnocení

Definice

Požadovaná hodnota

Vyhodnocení

Požadovaná kopie dat do testovacího prostředí. Součástí kopie bude provedení odpovídajících systémových testů deklarujících úspěšné provedení kopie dat.

Potvrzená realizace kopie dat.

Písemné potvrzení ze strany Poskytovatele o provedení kopie dat.

Požadované výstupy aktivity

Název výstupu

Charakteristika

Způsob akceptace

Zpráva o plnění Pilotní části služeb

Potvrzení o realizované kopii dat včetně doložení výsledků odpovídajících systémových testů bude součástí Zprávy o plnění o plnění Pilotní části služeb.

Pro akceptaci Zprávy o plnění pilotní části služeb se uplatní postup stanovený v rámci aktivity A9.

Způsob stanovení celkové ceny aktivity

Dle plnění

Celková cena aktivity za vyhodnocovací období (kalendářní měsíc) není zahrnuta v paušální měsíční ceně služeb Pilotního a akceptačního provozu pro celé prostředí Systému. Tato aktivita bude hrazena pouze při vyžádání Objednatelem, a to ve výši dle ceny aktivity A02 pro poskytování Služeb provozu (příloha č. 7 Smlouvy, list Cena služeb provozu).


Fakturace bude vždy realizována k období, ve kterém byla aktivita skutečně čerpána.



Označení

Název Aktivity

A03

Bezpečnostní aktualizace Systému

Rozsah aktivity

Popis (obsah) aktivity

Kontinuální provozní aktivita


Poskytovatel je povinen zajistit odpovídající stav Systému, tedy infrastruktury, Portálového systému SZIF, Portálových aplikací XXXX a dalších komponent Systému, tak, aby byla zajištěna adekvátní úroveň kybernetické a informační bezpečnosti. Na základě této povinnosti bude Poskytovatel provádět realizaci bezpečnostních aktualizací Systému, kdy předmětem aktualizací bude instalace, implementace, nastavení maximálně možných opatření pro zajištění ochrany dat Objednatele i ochrany samotného Systému.

Na základě aktivity bezpečnostního monitoringu, doporučení a požadavků jednotlivých výrobců technologických komponent zajistí Poskytovatel implementaci bezpečnostních částí kódu, patchů, záplat a dalších programových částí v souladu s doporučením výrobce. Pokud se nejedná o aktualizaci kritickou, bez které by byla zásadním způsobem ohrožena bezpečnost Systému, bude realizace bezpečnostních aktualizací primárně probíhat dvoukrokově:

  1. Aktualizace DEV a TEST prostředí včetně nezbytného otestování stavu Systému a následné ověření při standardním užívání testovacího prostředí.

  2. Aktualizace PROD prostředí včetně nezbytného otestování stavu Systému. Aktualizace PROD prostředí bude realizována minimálně s odstupem 14 kalendářních dnů, pokud je to možné a vhodné.

V případě cloudové prostředí se předpokládá průběžná aktualizace všech využitých cloudových služeb v DEV, TEST i PROD prostředí bez dopadu na dostupnost hostovaných aplikačních částí Systému.


Poskytovatel zašle požadavek na realizaci bezpečnostní aktualizace na Bezpečnostního manažera (za Objednatele) s uvedením navrhovaného harmonogramu provedení aktualizací a identifikací předpokládaných dopadů realizace bezpečnostních aktualizací. Bezpečnostní manažer neprodleně požadavek posoudí, ověří v rámci projektových struktur Objednatele vhodnost termínu a rozhodne o realizaci požadavku, případně ve spolupráci s Poskytovatelem navrhne náhradní termín.

Po realizaci bezpečnostní aktualizace bude provedena aktualizace příslušné provozní a projektové dokumentace. Toto bude uvedeno ve Zprávě o plnění Pilotní části služeb.

Doba zajištění aktivity

V případě, že se nejedná o kritickou bezpečnostní záplatu, bude aktivita realizována mimo Pracovní dobu Objednatele.

V případě, že se jedná o kritickou bezpečnostní záplatu, může být aktivita realizována po schválení Objednatelem v Pracovní době. V takovém případě, pokud bude po dobu aktivity přerušen provoz Systému, se jedná o Plánovanou odstávku.

SLA parametry / Vyhodnocení

Definice

Požadovaná hodnota

Vyhodnocení

Zajištění odpovídajícího stavu bezpečnosti Systému.

Plná bezpečnost používaných technologií a služeb v souladu s doporučeními výrobce či poskytovatele.

Jedná se o plnou odpovědnost Poskytovatele, v případě nezajištění bude toto řešeno v souladu s ustanoveními ZoKB a Smlouvy.

Požadované výstupy aktivity

Název výstupu

Charakteristika

Způsob akceptace

Zpráva o plnění Pilotní části služeb

V rámci Zprávy o plnění Pilotní části služeb bude identifikováno, jaké bezpečnostní aktualizace byly realizovány ve vyhodnocovacím období.

Pro akceptaci Zprávy o plnění pilotní části služeb se uplatní postup stanovený v rámci aktivity A09.

Způsob stanovení celkové ceny aktivity

Měsíční paušální cena

Celková cena aktivity za vyhodnocovací období (kalendářní měsíc) bude zahrnuta v paušální měsíční ceně služeb Pilotního a akceptačního provozu pro celé prostředí Systému.


Fakturace je realizována za každé vyhodnocovací období (kalendářní měsíc) se zohledněním příslušné kreditace.



Označení

Název Aktivity

A04

Provozní aktualizace Systému

Rozsah aktivity

Popis (obsah) aktivity

Kontinuální provozní aktivita


Poskytovatel je povinen zajistit odpovídající stav Systému tak, aby byla zajištěna adekvátní úroveň provozního prostředí Systému. Na základě této povinnosti bude Poskytovatel provádět realizaci provozních aktualizací Systému, kdy požadovaným stavem je zajištění plně aktuálního aplikačního prostředí Systému v souladu s doporučeními výrobce či poskytovatele služeb. A to bez ohledu na skutečnost, zda je Systém provozován v infrastruktuře Poskytovatele, třetí strany či cloudové infrastruktuře. Předmětem aktualizací tak bude instalace, implementace, nastavení provozních částí kódu, patchů, záplat a dalších programových částí v souladu s doporučením výrobce či poskytovatelů využitých služeb.

Tyto aktualizace budou realizovány zejména na základě výstupů provozního monitoringu, doporučení a požadavků jednotlivých výrobců technologických komponent. Pokud se nejedná o aktualizaci kritickou, která by mohla zásadním způsobem ohrozit stabilitu provozního prostředí Systému, bude realizace provozních aktualizací primárně probíhat dvoukrokově:

  1. Aktualizace DEV a TEST prostředí včetně nezbytného otestování stavu Systému a následné ověření při standardním užívání testovacího prostředí.

  2. Aktualizace PROD prostředí včetně nezbytného otestování stavu Systému. Aktualizace PROD prostředí bude realizována minimálně s odstupem 28 kalendářních dnů, pokud je to možné a vhodné.


V případě cloudové prostředí se předpokládá průběžná aktualizace všech využitých cloudových služeb v DEV, TEST i PROD prostředí bez dopadu na dostupnost hostovaných aplikačních částí Systému.

Poskytovatel zašle požadavek na realizaci bezpečnostní aktualizace na Vedoucího projektového týmu provozu (za Objednatele) s uvedením navrhovaného harmonogramu provedení aktualizací a identifikací předpokládaných dopadů realizace provozních aktualizací. Vedoucí projektového týmu provozu neprodleně požadavek posoudí, ověří v rámci projektových struktur Objednatele vhodnost termínu a rozhodne o realizaci požadavku, případně ve spolupráci s Vedoucím týmu provozu (za Poskytovatele) navrhne náhradní termín.

Po realizaci provozní aktualizace bude provedena aktualizace příslušné provozní a projektové dokumentace. Toto bude uvedeno ve Zprávě o plnění Pilotní části služeb.

Doba zajištění aktivity

V případě, že se nejedná o kritickou provozní aktualizaci, bude aktivita realizována mimo Pracovní dobu Objednatele.

V případě, že se jedná o kritickou provozní aktualizaci, může být aktivita realizována po schválení Objednatelem v Pracovní době. V takovém případě, pokud bude po dobu aktivity přerušen provoz Systému, se jedná o Plánovanou odstávku.

SLA parametry / Vyhodnocení

Definice

Požadovaná hodnota

Vyhodnocení

Zajištění odpovídajícího stavu provozního aplikačního prostředí Systému.

Plně stabilní provozní prostředí Systému nastavené a provozované dle doporučení výrobců a poskytovatelů využitých služeb.

Jedná se o plnou odpovědnost Poskytovatele, v případě nezajištění bude toto řešeno v souladu s ustanoveními ZoKB a Smlouvy.

Požadované výstupy aktivity

Název výstupu

Charakteristika

Způsob akceptace

Zpráva o plnění Pilotní části služeb

V rámci Zprávy o plnění Pilotní části služeb bude identifikováno, jaké provozní aktualizace byly realizovány ve vyhodnocovacím období.

Pro akceptaci Zprávy o plnění pilotní části služeb se uplatní postup stanovený v rámci aktivity A09.

Způsob stanovení celkové ceny aktivity

Měsíční paušální cena

Celková cena aktivity za vyhodnocovací období (kalendářní měsíc) bude zahrnuta v paušální měsíční ceně za poskytování služeb Pilotního a akceptačního provozu pro celé prostředí Systému.


Fakturace je realizována za každé vyhodnocovací období (kalendářní měsíc) se zohledněním příslušné kreditace.



Označení

Název Aktivity

A05

Optimalizace chodu Systému

Rozsah aktivity

Popis (obsah) aktivity

Kontinuální provozní aktivita


Na základě vyhodnocení dat provozního monitoringu aplikační vrstvy Systému a informací poskytovaných v rámci implementačního (ch) týmu (ů) Systému bude Poskytovatel analyzovat chování Systému, přijímat opatření k zajištění optimálního provozního prostředí Systému, případně identifikovat oblasti a definovat náměty na zlepšení.


Poskytovatel tak bude v rámci zajištění služeb včas vyhodnocovat stav informačního prostředí Systému a všechna zjištění bude identifikovat jako možná rizika (pozitivní i negativní).

Doba zajištění aktivity

Kontinuálně po dobu plnění Pilotní části služeb.

SLA parametry / Vyhodnocení

Definice

Požadovaná hodnota

Vyhodnocení

V rámci fungování jednotlivých týmů (provozní i implementační) jsou identifikována a přijímána opatření k zajištění optimálního chodu Systému.

Průběžné řízení rizik.

Jedná se o projektovou odpovědnost na straně Poskytovatele i Objednatele.

Požadované výstupy aktivity

Název výstupu

Charakteristika

Způsob akceptace

Zpráva o plnění Pilotní části služeb

Součástí Zprávy o plnění Pilotní části služeb bude část obsahující navrhované, či realizované aktivity vedoucí k optimalizaci provozního prostředí Systému.

Pro akceptaci Zprávy o plnění pilotní části služeb se uplatní postup stanovený v rámci aktivity A09.

Způsob stanovení celkové ceny aktivity

Měsíční paušální cena

Celková cena aktivity za vyhodnocovací období (kalendářní měsíc) bude zahrnuta v paušální měsíční ceně za poskytování služeb Pilotního a akceptačního provozu pro celé prostředí Systému.


Fakturace je realizována za každé vyhodnocovací období (kalendářní měsíc) se zohledněním příslušné kreditace.



Označení

Název Aktivity

A06

Opravy chyb

Rozsah aktivity

Popis (obsah) aktivity

Kontinuální provozní aktivita


Aktivita „Opravy chyb“ se vztahuje na realizaci všech dílčích činností, které jsou nezbytné pro odstranění identifikované nebo hlášené chyby. Jedná se například, nikoliv však výlučně, o činnosti související s analýzou chyby, úpravou analytických modelů, programování zdrojového kódu, testování, instalace na testovací prostředí, atd. Opravy chyb se vztahují na všechny technologické části a služby Systému. Aktivita se vztahuje i na prostředí třetích stran, pokud je chyba identifikována na úrovni aplikačního prostředí Systému. V takovém případě je identifikovaná chyba evidována pracovníky Poskytovatele v Service Desku jako incident.

V rámci dané aktivity poskytuje Poskytovatel odborné aplikační, systémové i konzultační služby, aby odstranil všechny identifikované chyby plnění.

Veškeré Opravy chyb musí být autorizovány příslušným odpovědným pracovníkem Objednatele, a to buď na úrovni projektového týmu, pokud se jedná o drobnou chybu, která byla v projektovém týmu identifikována (zde stačí odsouhlasení emailem, jestliže se nejedná o opravu vyžadující kompletní release), případně na úrovni Service Desku, pokud se jedná o chybu, která je většího významnějšího charakteru.

V případě, že je pracovníkem Poskytovatele identifikována chyba, je nezbytné opravu chyby vždy odsouhlasit pracovníkem Objednatele, a to i v případě, že může pracovník Poskytovatele chybu opravit sám. Pokud by byl realizován zásah v Systému, který bude následně odlogován, jako neautorizovaný, jedná se o porušení integrity Systému. V případě identifikované chyby s možností opravy, kterou není možné z jakýchkoliv důvodů schválit na úrovni projektového týmu, zakládá pracovník Poskytovatele prostřednictvím Service Desku ticket incidentu/problému, s tím že do textu ticketu již navrhuje způsob řešení.

Evidenci chyb identifikovaných a opravených na úrovni Projektového týmu předkládá Vedoucí provozního týmu souhrnně Zprávy o plnění Pilotní části služeb.

Doba zajištění aktivity


Dle potřeby v Provozní době, pokud se nejedná o opravu prostřednictvím releasu a oprava nemá dopad na provoz Systému.


V případě, že má realizace Opravy chyby dopad na provoz Systému, musí být vždy autorizována pracovníkem Service Desku Objednatele. V případě, že je oprava chyby autorizována pracovníkem Service Desku Objednatele i v Provozní době, přestože má oprava dopad na provoz Systému, jedná se o Plánovanou odstávku.

SLA parametry / Vyhodnocení

Definice

Požadovaná hodnota

Vyhodnocení

Autorizovaná oprava chyb

Veškeré identifikované chyby jsou opravovány řízeným postupem tak, aby nebyla narušena integrita Systému.

Na základě předkládaných reportů systémových zásahů pracovníků Poskytovatele bude ověřeno, zda se jednalo o autorizované zásahy do prostředí Systému. V případě, že nebude zásah autorizován, uplatní se kreditace definována v kapitole č. 4.

Požadované výstupy aktivity

Název výstupu

Charakteristika

Způsob akceptace

Zpráva o plnění Pilotní části služeb.


Reporty systémových zásahů v Systému.

V rámci Zprávy budou identifikované veškeré Opravy autorizované na úrovni daných projektových týmů.


Budou ověřovány reporty systémových zásahů v Systému.

Pro akceptaci Zprávy o plnění pilotní části služeb se uplatní postup stanovený v rámci aktivity A09.

Způsob stanovení celkové ceny aktivity

Měsíční paušální cena

Celková cena aktivity za vyhodnocovací období (kalendářní měsíc) bude zahrnuta v paušální měsíční ceně za poskytování služeb Pilotního a akceptačního provozu pro celé prostředí Systému.


Fakturace je realizována za každé vyhodnocovací období (kalendářní měsíc) se zohledněním příslušné kreditace.



Označení

Název Aktivity

A07

Bezpečnostní monitoring provozu Systému

Rozsah aktivity

Popis (obsah) aktivity

Kontinuální provozní aktivita


Poskytovatel je povinen zajistit komplexní aktivity bezpečnostního monitoringu Systému. Předmětem bezpečnostního monitoringu je tak sledování stavu Systému, průběžné vyhodnocování informací týkajících se bezpečnosti Systému, všech jeho součástí a využitých služeb. Monitoring musí zahrnovat automatizovaný dohled i činnosti pracovníků Poskytovatele související zejména s vyhodnocováním nestandardních stavů, bezpečnostních událostí a incidentů a jejich hlášení na stranu Objednatele.

Aktivity bezpečnostního monitoringu budou primárně zaměřeny na následující oblasti:

  • Chování uživatelů Systému (zajištění logování aktivit s dopadem na bezpečnost dle požadavků ZoKB).

  • Bezpečnost osobních dat v Systému.

  • Obecná bezpečnost dat.

  • Provoz aplikační vrstvy s ohledem na kybernetickou a informační bezpečnost.

  • Další oblasti v souladu s požadavky na implementaci GDPR a závaznými legislativními požadavky zejména ZoKB a prováděcích předpisů a Zákona č. 365/2000 Sb.

Aktivity bezpečnostního monitoringu musí splňovat následující rozsah:

  • Monitoring a provádění kontroly stavů všech bezpečnostně relevantních mechanismů implementovaných v rámci prostředí.

  • Monitoring bezpečnosti Systému s ohledem na ICT prostředí, které ovlivňuje provoz Systému, typicky:

    • Infrastruktura pro Systém

    • Informační systémy Objednatele integrované na Systém:

      • IS XXXX.

      • IS SZIF na platformě SAP.

      • IDM SZIF.

      • Systémy pro správu přístupů.

      • LPIS a případně další integrované registry a systémy.

    • Aplikační služby nezbytné pro fungování komplexního informačního prostředí pro podporu agend XXXX, jehož je Systém součástí:

      • Služby SAMAS.

      • Služby Geotagovaných fotografií.

V případě podezření na vznik bezpečnostní události/incidentu ve vnějším prostředí, kdy toto může mít dopad na chod Systému, zajištění notifikace Bezpečnostního manažera Objednatele nejpozději do 15 minut od zjištění nežádoucího stavu.

  • Kontrola bezpečnostních logů (na denní bázi).

  • Monitoring nových verzí bezpečnostních aktualizací/záplat/patchů pro zajištění bezpečnostních aktualizací Systému.

  • Notifikace Service Desku Objednatele (alerting) při výskytu nežádoucích situací do 15 minut od vzniku/zjištění. Vyhodnocování těchto stavů a identifikaci příčin. Analýza řešených problémových situací a návrh opatření pro jejich eliminaci. Prozkoumání vhodnosti přijatých opatření.

  • Poskytovatel v případě zjištění bezpečnostní události/incidentu bezprostředně informuje Bezpečnostního manažera Objednatele a zajistí identifikaci dotčených modulů/funkčností včetně předání této informace na 1. úroveň Service Desk SZIF.

  • Poskytovatel v případě nalezení příčiny bezpečnostní události/incidentu a též řešení bezpečnostní události/incidentu, bezprostředně informuje Bezpečnostního manažera Objednatele a 1. úroveň Service Desk SZIF.

  • Poskytovatel zajistí dohled nad neoprávněnými pokusy o přihlášení do aplikačního prostředí Systému a předání této informace na Service Desk SZIF a Bezpečnostního manažera SZIF. Za neoprávněný pokus se považuje opakovaný pokus o využití jiného než odsouhlaseného mechanismu přihlašování, případně identifikovaný pokus o prolomení standardního způsobu přihlašování.

  • Pro realizaci aktivit bezpečnostního monitoringu musí být v prostředí Systému implementovány odpovídající monitorovací a logovací nástroje dle schválené architektury Systému.

  • Součástí aktivit bude správa záznamů a logů zahrnující sběr, ukládání, zpracování a vyhodnocování bezpečnostních záznamů jednotlivých modulů Systému. Záznamy se musí archivovat v souladu s požadavky ZoKB pro významný informační systém dle vyhlášky příslušného prováděcího předpisu ZoKB.

  • Bezpečnostní monitoring musí splňovat požadavky dle ISO 27001:2013.

Doba zajištění aktivity

Automatizovaný dohled a sběr dat - 7x24 – provozní doba znamená zajištění služeb pracovní i nepracovní dny 24 hodin denně;

Interakce pracovníků Poskytovatele vůči pracovníkům Objednatele – v případě zjištění bezpečnostní události/incidentu neprodleně.

SLA parametry / Vyhodnocení




Předmětem vyhodnocení aktivity Bezpečnostního monitoringu bude samostatná zpráva předkládaná na měsíční bázi.

Zpráva bude obsahovat minimálně:

  • Měsíční přehled o zaznamenaných incidentech a nežádoucích situacích

  • Měsíční přehled pokusů o narušení bezpečnosti Systému

  • Záznamy o privilegovaných přihlášeních do Systému

  • Záznamy o používání vzdáleného přístupu do Systému mimo privilegovaná přihlášení

  • Identifikovaná bezpečnostní rizika

  • Opatření realizovaná v průběhu vyhodnocovacího období a navrhovaná pro období následující

  • Veškeré další podklady dokládající realizaci Bezpečnostního monitoringu Systému Poskytovatelem v souladu s Best Practice a požadavky ZoKB, případně ISO 27001.

Požadované výstupy aktivity

Název výstupu

Charakteristika

Způsob akceptace

Zpráva měsíčního vyhodnocení bezpečnostního monitoringu Systému.

Bude se jednat o dokument, který bude klasifikován jako diskrétní. Dokument nebude kromě Garanta projektového týmu (Provozní tým) a Bezpečnostního manažera SZIF zpřístupněn dalším pracovníkům Objednatele. Tento dokument nebude standardní součástí Zprávy o plnění Pilotní části služeb. Ve Zprávě o plnění Pilotní části služeb bude uveden odkaz s termíny předání Zprávy měsíčního vyhodnocení bezpečnostního monitoringu Systému.

Pro akceptaci Zprávy měsíčního vyhodnocení bezpečnostního monitoringu Systému se uplatní obecná akceptační kritéria pro předávání dokumentace dle Smlouvy.

Způsob stanovení celkové ceny aktivity

Měsíční paušální cena

Celková cena aktivity za vyhodnocovací období (kalendářní měsíc) bude zahrnuta v paušální měsíční ceně za poskytování služeb Pilotního a akceptačního provozu pro celé prostředí Systému.


Fakturace je realizována za každé vyhodnocovací období (kalendářní měsíc) se zohledněním příslušné kreditace.



Označení

Název Aktivity

A08

Provozní monitoring Systému

Rozsah aktivity

Popis (obsah) aktivity

Kontinuální provozní aktivita


Poskytovatel je povinen zajistit komplexní aktivity provozního monitoringu implementovaného Systému. Předmětem provozního monitoringu je tak sledování stavu Systému, průběžné vyhodnocování informací týkajících se provozu Systému, a to včetně jeho všech součástí a využitých služeb.

Monitoring musí zahrnovat automatizovaný dohled i činnosti pracovníků Poskytovatele související zejména s vyhodnocováním nestandardních stavů, provozních událostí a incidentů a jejich hlášení na stranu Objednatele.

Aktivity provozního monitoringu budou primárně zaměřeny na následující oblasti:

  • Chování uživatelů Systému (zajištění logování chování uživatelů dle požadavků ZoKB).

  • Provozní stabilita jednotlivých modulů/systémů v Systému.

  • Provozní monitoring Systému – výkon, dostupnost, stabilita, provozní události/incidenty.

  • Provozní monitoring rozhraní Systému – výkon, dostupnost, stabilita, provozní události/incidenty.

  • Monitoring konzistence dat v Systému.

  • Administrace systému a implementace změn v Systému.

  • Další nezbytné činnosti garantující stabilní a funkční prostředí Systému odpovídající provozním BEST PRACTICE standardům (ITIL, ISO/IEC 20000).

Aktivity provozního monitoringu musí splňovat následující rozsah:

  • Monitoring a provádění kontroly stavů všech provozně relevantních mechanismů implementovaných v rámci prostředí.

  • Monitoring chování Systému s ohledem na okolní ICT prostředí, které ovlivňuje provoz Systému, typicky:

    • Infrastruktura pro Systém

    • Informační systémy Objednatele integrované na Systém:

      • IS XXXX.

      • IS SZIF na platformě SAP.

      • IDM SZIF.

      • Systémy pro správu přístupů.

      • LPIS a případně další integrované registry a systémy.

    • Aplikační služby nezbytné pro fungování komplexního informačního prostředí pro podporu agend XXXX:

      • Služby SAMAS.

      • Služby Geotagovaných fotografií.

V případě identifikace provozní události/incidentu ve vnějším prostředí, kdy toto může mít dopad na chod Systému, zajištění notifikace Service Desku Objednatele nejpozději do 15 minut od zjištění nežádoucího stavu.

  • Kontrola provozních logů (na denní bázi).

  • Monitoring nových verzí systému, provozních aktualizací/záplat/patchů pro zajištění provozních aktualizací Systému.

  • Notifikace Service Desku Objednatele (alerting) při výskytu nežádoucích situací do 15 minut od vzniku/zjištění. Vyhodnocování těchto stavů a identifikaci příčin. Analýza řešených problémových situací a návrh opatření pro jejich eliminaci. Prozkoumání vhodnosti přijatých opatření.

  • Poskytovatel v případě zjištění provozní události/incidentu bezprostředně informuje 1. úroveň Service Desk SZIF.

  • Poskytovatel v případě nalezení příčiny provozní události/incidentu a též řešení provozní události/incidentu, bezprostředně informuje 1. úroveň Service Desk SZIF.

  • Součástí aktivit bude správa záznamů a logů zahrnující sběr, ukládání, zpracování a vyhodnocování bezpečnostních záznamů jednotlivých modulů Systému. Záznamy se musí archivovat v souladu s požadavky ZoKB pro významný informační systém dle vyhlášky příslušného prováděcího předpisu ZoKB.

  • Provozní monitoring Systému musí být nastaven a prováděn v souladu s ISO/IEC 27001 v aktuální platné verzi.

Doba zajištění aktivity

Automatizovaný dohled a sběr dat - 7x24 – provozní doba znamená zajištění služeb pracovní i nepracovní dny 24 hodin denně;

Interakce pracovníků Poskytovatele vůči pracovníkům Objednatele - 5x12 – garantovaná provozní doba znamená zajištění služeb pracovní dny 12 hodin denně (7:00 – 19:00).

SLA parametry / Vyhodnocení




Předmětem vyhodnocení aktivity Provozního monitoringu bude samostatná Zpráva měsíčního vyhodnocení provozního monitoringu Systému. Zpráva bude obsahovat minimálně:

  • Měsíční přehled o zaznamenaných incidentech a nežádoucích situacích

  • Měsíční přehled realizovaných administrátorských operací na úrovni pracovníků Poskytovatele

  • Měsíční přehled provozních činností realizovaných ze strany Poskytovatele

  • Identifikovaná provozní rizika

  • Opatření realizovaná v průběhu vyhodnocovacího období a navrhovaná pro období následující

Veškeré další podklady dokládající realizaci Provozního monitoringu Systému Provozovatelem v souladu s Best Practice a požadavky odpovídající legislativy vztahující se na provoz významných informačních systémů veřejné správy.

Požadované výstupy aktivity

Název výstupu

Charakteristika

Způsob akceptace

Zpráva měsíčního vyhodnocení provozního monitoringu Systému.

Zpráva měsíčního vyhodnocení provozního monitoringu Systému bude součástí souhrnné Zprávy o plnění Pilotní části služeb.

Pro akceptaci Zprávy o plnění pilotní části služeb se uplatní postup stanovený v rámci aktivity A09.

Způsob stanovení celkové ceny aktivity

Měsíční paušální cena

Celková cena aktivity za vyhodnocovací období (kalendářní měsíc) bude zahrnuta v paušální měsíční ceně za poskytování služeb Pilotního a akceptačního provozu pro celé prostředí Systému.


Fakturace je realizována za každé vyhodnocovací období (kalendářní měsíc) se zohledněním příslušné kreditace.





Označení

Název Aktivity

A09

Vyhodnocení SLA parametrů provozu

Rozsah aktivity

Popis (obsah) aktivity

Kontinuální provozní aktivita


Poskytovatel je povinen v rámci poskytování Pilotní části služeb zajistit kompletní vyhodnocení veškerých provozních aktivit, stavu systému i činností realizovaných jednotlivými pracovníky Poskytovatele v rámci definovaných aktivit. Vyhodnocení bude spočívat v prověření a doložení podkladů parametrů provozu Systému v podobě souhrnné Zprávy o plnění Pilotní části služeb, kdy jednotlivé dílčí oblasti definovaných aktivit budou součástí této souhrnné Zprávy o plnění Pilotní části služeb (vyjma Zprávy měsíčního vyhodnocení bezpečnostního monitoringu Systému).


Obsah zprávy popisující věcnou oblast poskytovaných aktivit bude v takovém detailu, který dostatečně dokládá samotný průběh realizace služeb a naplnění podmínek jednotlivých aktivit. Zároveň zpráva obsahuje jednoznačné potvrzení stanovených parametrů služeb a dokládají splnění či porušení jednotlivých SLA s případným vyčíslením kreditace.

Doba zajištění aktivity

1krát měsíčně na počátku každého vyhodnocovacího období (kalendářní měsíc) za uplynulé vyhodnocovací období.

SLA parametry / Vyhodnocení




Celková Zpráva o plnění Pilotní části služeb bude zpracována a předána nejpozději během 5. (pátého) pracovního dne vyhodnocovacího období následujícího po ukončení předchozího vyhodnocovacího období.

Zpráva bude předána v elektronické podobě umožňující počítačové zpracování. Dílčí zprávy budou primárně ve formátu .pdf v generované (případně skenované, se zachováním strojové čitelnosti) podobě. Ty části zpráv, které budou obsahovat taková data, jejichž zobrazení ve standardním dokumentu (.pdf) znamená zhoršenou orientaci v datech, budou předány ve formátu .xlsx.

Zpráva bude standardně chráněna proti změně dat; čtení, systémové kopírování a elektronický podpis akceptační doložky ze strany kontaktní osoby Objednatele budou umožněny. Kontaktní osobou pro převzetí zprávy bude Garant provozního týmu.

Požadované výstupy aktivity

Název výstupu

Charakteristika

Způsob akceptace

Zpráva o plnění Pilotní části služeb

Předaná a akceptovaná úplná Zpráva o plnění Pilotní části služeb.

Pro akceptaci ze strany kontaktní osoby Objednatele je stanovena lhůta 5 pracovních dní od předání Zprávy o plnění Pilotní části služeb ze strany Poskytovatele. V případě, že nebude ze strany kontaktní osoby Objednatele vznesena výhrada

nejpozději 5. (pátého) pracovního dne od předání Zprávy o plnění Pilotní části služeb, má se za to, že je Zpráva akceptována. V případě, že budou ze strany kontaktní osoby Objednatele vzneseny výhrady, je Poskytovatel povinen Zprávu o plnění Pilotní části služeb aktualizovat a předat nejpozději během 3. (třetího) pracovního dne od obdržení výhrad. Následná lhůta pro akceptaci upravené Zprávy o stavu provozu Systému je stanovena na 3 pracovní dny.

Poskytovatel je oprávněn fakturovat plnění Pilotní části služeb na základě akceptované Zprávy o plnění Pilotní části služeb.


Způsob stanovení celkové ceny aktivity

Měsíční paušální cena

Celková cena aktivity za vyhodnocovací období (kalendářní měsíc) bude zahrnuta v paušální měsíční ceně za poskytování služeb Pilotního a akceptačního provozu pro celé prostředí Systému.


Fakturace je realizována za každé vyhodnocovací období (kalendářní měsíc) se zohledněním příslušné kreditace.



Označení

Název Aktivity

A10

Zajištění 2. a 3. úrovně podpory Service Desku

Rozsah aktivity

Popis (obsah) aktivity

Kontinuální provozní aktivita


Poskytovatel bude, ve vztahu k Systému, zajišťovat kompletní službu podpory pro zajištění poskytování služeb i pro realizaci implementace. Tato podpora bude poskytována v rozsahu odpovědností definovaných následujícím schématem primárně prostřednictvím Service Desku, jakožto standardizovaného nástroje pro poskytování podpory v prostředí SZIF. Komplexní zajištění podpory Systému bude zajišťováno součinností různých subjektů.


Poskytovatel zajistí formou služby výkon činnosti 2. úrovně podpory pro oblast prostředí Systému v rozsahu dodávaných a provozovaných aplikačních komponent a služeb. Součástí poskytování služeb podpory není podpora výrobců HW a SW, které nejsou součástí Dodávky a Implementace Systému.


Shape1

1. úroveň podpory zajišťuje Objednatel. V rámci 1. úrovně podpory je zajišťována komunikace s koncovými uživateli. Na této úrovni dochází ke klasifikaci jednotlivých hlášení, kategorizaci a předávání na řešitelské týmy 2. úrovně podpory.

Z hlediska 1. úrovně podpory jsou rozlišovány primárně 3 typy hlášení:

  • Incident (na tento typ hlášení se vztahují SLA na administraci hlášení – reakční doba)

  • Problém (na tento typ hlášení se vztahují SLA na administraci hlášení – reakční doba)

  • Požadavek (na tento typ hlášení se nevztahují SLA na administraci hlášení, v případě nerealizace požadavku se uplatní sankční mechanismy dle příslušné aktivity)

Každé hlášení (incidentu/problému) je zadáváno prostřednictvím ticketu.

V případě, že je ticket postoupen Poskytovateli, stává se Poskytovatel řešitelem konkrétního ticketu a musí na tento ticket reagovat, resp. zahájit jeho řešení dle stanovených lhůt.

Z hlediska významnosti ticketů jsou stanoveny tři kategorie.

  • Vysoká významnost – funkčnost Systému není možné produktivně používat, neexistuje náhradní řešení, tento stav ohrožuje realizaci procesů SZIF.

  • Střední významnost – funkčnost Systému není možné produktivně používat v plném rozsahu, resp. existuje náhradní řešení, které umožní realizaci procesů SZIF mimo Systém.

  • Nízká významnost – funkčnost Systému je možně produktivně používat s dílčím omezením, které nemá vliv na realizaci procesů SZIF.



V rámci 2. úrovně podpory zajistí Poskytovatel zejména následující činnosti:

  • Provádění servisních služeb:

    • Řešení nestandardních stavů/incidentů a požadavků v denním provozu předaných z 1. úrovně podpory. Odstraňování incidentů na úrovni provozu Systému (chyby funkčností, nedostupnosti funkčností, modulů, incidenty na úrovni chyb v datech).

    • Komunikace s 1. úrovní podpory prostřednictvím Service Desku SZIF. (Jedná se o formální komunikaci, která je předmětem standardní archivace v Service Desk nástroji Objednatele)

    • Komunikace s 3. úrovní podpory prostřednictvím interních postupů Poskytovatele.

  • Zadávání požadavků na 1. úroveň podpory – jedná se zejména o požadavky na poskytnutí součinnosti, realizaci služby, aj. odborné činnosti ze strany pracovníků Objednatele i ostatních dodavatelů Objednatele, kteří zajišťují provoz dalších částí informačního prostředí SZIF (typicky například provozovatel infrastruktury), kdy realizace těchto požadavků je nezbytná pro zajištění služeb poskytovaných Poskytovatelem v odpovídajícím rozsahu (např. pro realizaci kopie dat).

  • Provádění dalších odborných činností 2. úrovně podpory v rámci eskalačních postupů a procesů podpory SZIF (podpora a analýzy stavu Systému při řešení bezpečnostních incidentů, incidentů a poruchových stavů na aplikační úrovni) a poskytnutí odborné podpory Objednateli při komunikaci s dalšími externími subjekty (dodavateli).


Služba 2. úrovně podpory musí být schopna:

  • na základě výstupů aktivit provozního a bezpečnostního monitoringu musí být na 2. úrovni podpory umožněna:

    • verifikace funkčnosti nebo dostupnosti služeb z pohledu Objednatele.

    • detekce degradace funkčnosti než se projeví u koncových uživatelů Objednatele (pokud je toto možné).

    • prvotní analýza pro rychlé a jednoznačné určení a předání odpovědnému týmu/pracovníkovi zodpovědnému za řešení provozní/bezpečnostní situace.



V rámci služeb 3. úrovně podpory zajistí Poskytovatel zejména následující činnosti:

  • Interní řešení ticketů v prostředí Poskytovatele a komunikace s 2. úrovní podpory.


Pro výkon činností v rámci služeb 2. úrovně podpory bude Poskytovatel využívat prostředí Service Desku SZIF; podpora procesů řízení ICT služeb v souladu s mezinárodním standardem ITIL,

  • Incident a Request Management – zpracování incidentů, požadavků, dotazů na provoz Systému.

  • Release Management – prostřednictvím Service Desku SZIF bude zajištěna evidence všech požadovaných releasů nových/změněných funkčností Systému realizovaných prostřednictvím služeb rozvoje.

  • Problem Management – identifikace, kategorizace, diagnostika a řešení problémů v Systému.

  • Nastavení workflow a eskalačních procedur.

Doba zajištění aktivity

  • 7x24 – provozní doba znamená zajištění služeb pracovní i nepracovní dny 24 hodin denně.

SLA parametry

Parametr

Požadovaná hodnota

Vyhodnocení

Následující parametry stanovují požadavky na zajištění úrovně služeb Service Desku ze strany Poskytovatele. Komunikace a realizace procesů mezi 2. a 3. úrovní na straně Poskytovatele není předmětem vyhodnocení. Poskytovatel musí tyto procesy nastavit interně tak, aby splnil níže uvedené požadavky. Veškeré níže uvedené lhůty jsou vztaženy k Době zajištění aktivity, tedy rovněž lhůty jsou kalkulovány podle této Doby. Čas mimo tuto Dobu se nezapočítává do vyhodnocení

Doba reakce na přidělení ticketu

(Lhůta, do jejíhož uplynutí musí 2. úroveň Service Desku potvrdit přijetí ticketu a zahájit řešení prostřednictvím Service Desk nástroje)

30 minut

Porovnání systémového času mezi nahlášením (doba odeslání) ticketu z 1. úrovně a potvrzením zahájení řešení ze strany Poskytovatele.

Maximální doba řešení ticketu

Vysoké významnosti


Lhůta, do jejíhož uplynutí musí být ticket vyřešen nebo nalezeno náhradní řešení, které umožní snížit významnost na Střední či Nízkou – při snížení významnosti se doba řešení vysoké významnosti započítává do doby řešení nižší významnosti, tedy Doba měření lhůty není znovu zahájena, ale pokračuje.


(V případě, že bude požadována součinnost jiného dodavatele nebo Objednatele, lhůta je pozastavena do doby poskytnutí součinnosti. Pokud je požadavek na součinnost požadován neoprávněně, lhůta stále běží, toto platí i pro následující významnosti.)

120 minut (2 hodiny)

Porovnání systémového času mezi nahlášením (doba odeslání) ticketu z 1. úrovně a potvrzením zahájení řešení ze strany Poskytovatele.

V případě nezajištění řešení do požadované doby řešení je ticket klasifikován jako Vada Systému Kategorie „A“ a dojde k uplatnění kreditace.

Maximální doba řešení ticketu

Střední významnosti


Lhůta, do jejíhož uplynutí musí být ticket vyřešen nebo nalezeno náhradní řešení, které umožní snížit významnost na Nízkou – při snížení významnosti se doba řešení vysoké významnosti započítává do doby řešení nižší významnosti, tedy Doba měření lhůty není znovu zahájena, ale pokračuje.

8 hodin

Porovnání systémového času mezi nahlášením (doba odeslání) ticketu z 1. úrovně a potvrzením zahájení řešení ze strany Poskytovatele.

V případě nezajištění řešení do požadované doby řešení je ticket klasifikován jako Vada Systému Kategorie „B“ a dojde k uplatnění kreditace.

Maximální doba řešení ticketu

Nízké významnosti


Lhůta, do jejíhož uplynutí musí být ticket vyřešen.

40 hodin

Porovnání systémového času mezi nahlášením (doba odeslání) ticketu z 1. úrovně a potvrzením zahájení řešení ze strany Poskytovatele.

V případě nezajištění řešení do požadované doby řešení je ticket klasifikován jako Vada Systému Kategorie „C“ a dojde k uplatnění kreditace.

Požadované výstupy aktivity

Název výstupu

Charakteristika

Způsob akceptace

Zpráva o plnění Pilotní části služeb

Součástí Zprávy o plnění Pilotní části služeb bude strukturovaný přehled všech ticketů, jejichž Maximální doba řešení časově spadá do vyhodnocovacího období s uvedením ID ticketu, doby předání, doby reakce, požadované Maximální doby řešení a reálné doby řešení.

Pro akceptaci Zprávy o plnění pilotní části služeb se uplatní postup stanovený v rámci aktivity A09.

Způsob stanovení celkové ceny aktivity

Měsíční paušální cena

Celková cena aktivity za vyhodnocovací období (kalendářní měsíc) bude zahrnuta v paušální měsíční ceně za poskytování služeb Pilotního a akceptačního provozu pro celé prostředí Systému.


Fakturace je realizována za každé vyhodnocovací období (kalendářní měsíc) se zohledněním příslušné kreditace.



Označení

Název Aktivity

A11

Úpravy a rozvoj Systému prostřednictvím Požadavků na změnu (PZ)

Rozsah aktivity

Popis (obsah) aktivity

Aktivita na vyžádání


Prostřednictvím aktivity se realizují a evidují veškeré změny v Systému, které se nevztahují k samotné Implementaci Díla, tedy jedná se o funkčnosti, které nebyly předmětem definovaného zadání.


Proces rozvoje prostřednictvím požadavku na změnu se sestává z následujících kroků:

  1. Vytvoření Požadavku na změnu – PZ

Předmětem tohoto kroku je vyplnění formuláře PZ, jehož součástí je kompletní zadání požadované funkčnosti.

Součástí Zadávaného PZ bude minimálně:

  • Předmět: stručný název/popis požadavku,

  • Priorita: dle důležitosti/naléhavosti - Nízká, Střední, Vysoká,

  • Žádající: Jméno, Příjmení,

  • Datum zadání,

  • Požadované datum předání k uživatelským testům na testovacím prostředí,

  • Požadované datum produktivního startu – zahájení užívání funkčností realizovaného PZ,

  • Podmínky Akceptace funkčnosti a PZ ze strany Objednatele,

  • Autorizace PZ – schválení zadání požadavku na změnu věcným metodickým garantem Objednatele, Vedoucím projektového týmu a Garantem projektového týmu Objednatele.

Vytvoření PZ zajišťuje Objednatel.


  1. Předání PZ Objednatelem k posouzení Poskytovatelem

Jedná se o formální krok, kdy vedoucí daného projektového týmu Objednatele předává vyplněný formulář PZ na Poskytovatele (dle formy předání buď na příslušného Vedoucího projektového týmu Poskytovatele, nebo prostřednictvím automatizovaného nástroje). Okamžikem prokazatelného předání je aktivována lhůta pro posouzení PZ Poskytovatelem.


  1. Posouzení PZ Poskytovatelem a předání posouzeného PZ k rozhodnutí Objednateli

Předmětem tohoto kroku je věcné, odborné (projektové) a finanční posouzení Požadavku na změnu a zároveň doplnění všech dalších nezbytných záležitostí PZ. Součástí posouzení PZ, které na své straně zajišťuje Poskytovatel, je rovněž věcné vyhodnocení a návrh řešení implementace daného PZ. Výstupem posouzení PZ bude upravený formulář obsahující následující údaje ze strany Poskytovatele:

  • Popis implementace a návrh řešení požadované úpravy/změny Systému

  • Identifikované dopady na:

    • Navrhovanou architekturu Systému.

    • Bezpečnostní a provozní prostředí a vlastnosti Systému.

    • Rozhraní Systému na další systémy a datovou vrstvu.

    • Další provozně a bezpečnostně významné oblasti informačního prostředí Objednatele.

  • Potvrzené požadované termíny realizace PZ, případně navržené nové termíny, pokud není možné původní požadované termíny splnit. V případě nově navržených termínů se tyto musí maximálně blížit požadovaným termínům, zároveň Poskytovatel k navrženým termínům uvede zdůvodnění, proč není možné realizovat PZ v původních termínech požadovaných Objednatelem.

  • Požadavky na zdroje – s uvedením jednotlivých rolí poskytovatele a předpokládanou čerpanou kapacitu (v hod).

  • Maximální kapacitní náročnost daného PZ (v hod a MD) a maximální cenu realizovaného PZ.

  • Autorizaci PZ ze strany oprávněných pracovníků Poskytovatele.

Výše uvedené údaje musí být ze strany Poskytovatele doplněny do formuláře PZ vždy. V případě, že nejsou identifikované dopady v jednotlivých oblastech, bude i v těchto částech minimálně doplněno vyjádření, že žádné dopady nebyly ze strany Poskytovatele identifikovány.

Maximální doba posouzení a odeslání posouzeného PZ je stanovena na 5 pracovních dnů. Nejpozději 5. pracovní den (do konce pracovní doby Objednatele) navazující po dni předání PZ k posouzení bude doplněné, posouzené a autorizované PZ předáno stanoveným způsobem na Objednatele.


  1. Rozhodnutí o realizaci PZ

Na základě posouzeného PZ určí Objednatel, zda bude PZ realizován dle zaslaného návrhu, kdy výsledkem mohou být následující stavy PZ:

  • Schválení PZ na základě posouzení ze strany Poskytovatele v plném rozsahu úprav provedených Poskytovatelem. V takovém případě bude schválený a autorizovaný PZ zaslán Poskytovateli, kdy se PZ stává závaznou objednávkou realizace rozvojového požadavku.

  • Neschválení PZ bez náhrady – v takovém případě informuje Objednatel Poskytovatele, že daný PZ nebude realizován.

  • Projednání PZ – PZ je nezbytné realizovat, ale jsou nezbytné úpravy – v takovém případě iniciuje Vedoucí projektového týmu Objednatele projednání návrhu daného PZ, kdy výstupem projednání musí být buď stavy: Schválení PZ, Neschválení PZ bez náhrady.

V případě rozhodnutí o Schválení PZ či Neschválení PZ zasílá Objednatel potvrzení o stavu PZ nejpozději 5. pracovní den (do konce pracovní doby Objednatele) navazující po dni předání posouzeného PZ ze strany Poskytovatele k Rozhodnutí na Objednatele. V případě požadavku na Projednání PZ bude lhůta pro rozhodnutí stanovena individuálně dohodou Objednatele a Poskytovatele.


  1. Zahájení realizace PZ

Na základě Schválení PZ zahájí Poskytovatel realizaci Požadavku na změnu. Vývoj Požadavku na změnu bude realizován na Vývojovém prostředí. Toto prostředí není dostupné pro pracovníky Objednatele a rovněž na tomto prostředí nejsou standardně uchovávána žádná data (produktivní/testovací) Systému. Předávání funkcionalit do testovacího prostředí, kde probíhá samotné testování (jak ze strany Poskytovatele, tak ze strany Objednatele) je plně v provozní režii Poskytovatele. Poskytovatel musí přenos funkcionalit do testovacího prostředí realizovat takovým způsobem, aby nedocházelo k nekonzistencím u dalších funkčností, které mohou být připravovány v rámci testovacího prostředí. Vývoj na straně Poskytovatele bude realizován takovým způsobem, aby bylo garantováno zachování principů bezpečného vývoje dle ISO 27001.

  1. Předání výstupů PZ k otestování

Předávání jednotlivých požadovaných částí funkčností dle PZ bude probíhat v souladu s definovaným a schváleným harmonogramem PZ. O možnosti zahájení testování vyrozumí vždy oprávněná osoba Poskytovatele zadavatele PZ ze strany Objednatele. Testování probíhá dle definovaných testovacích scénářů za účelem ověření požadovaných funkčností.

  1. Potvrzení otestování PZ

V případě, že je testování úspěšné, následuje potvrzení a akceptace provedených testů. Tato akceptace probíhá na úrovni zadavatel PZ a určený pracovník Poskytovatele. Akceptace testů je potvrzována vždy formálně elektronickou formou. Jakmile bude akceptováno otestování funkčnosti v testovacím prostředí, založí oprávněná osoba Poskytovatele Požadavek na uvolnění PZ do produktivního prostředí prostřednictvím ServiceDesku.

  1. Schválení releasu PZ do produktivního prostředí

Na základě definovaného Požadavku na uvolnění PZ do Produkce určí Vedoucí týmu provozu nejbližší možný termín releasu PZ do produktivního prostředí, a to v souladu s nastavenými lhůtami pro uvolňování do Produktivního prostředí a autorizuje Požadavek na release PZ, který je následně předán na zástupce provozního týmu ze strany Objednatele. Zástupce provozního týmu ze strany Objednatele potvrdí realizaci releasu nejpozději do 11 hodin v den požadovaného releasu, pokud není do této doby realizace releasu ze strany Objednatele potvrzená, má se za to, že je release schválen. Zamítnutí releasu ze strany Objednatele bude možné pouze, pokud jsou identifikována taková rizika, že by mohla být ohrožena stabilita informačního prostředí na straně Objednatele.

  1. Akceptace PZ

Na základě releasu požadovaných funkčností PZ do produktivního prostředí následuje akceptační procedura daného PZ. Na straně Objednatele dojde k ověření, že veškeré uvolněné funkčnosti odpovídají požadovaným charakteristikám. Zároveň dojde k ověření, že byla provedena aktualizace veškeré nezbytné dokumentace. Po tomto ověření vystaví Vedoucí projektového týmu Objednatele Akceptační protokol k danému PZ, zajistí jeho potvrzení oprávněnými osobami na straně Objednatele a předá jej příslušnému Vedoucímu Projektového týmu na straně Poskytovatele. Vystavení a předání Akceptačního protokolu musí být realizováno nejpozději do konce pracovní doby 14. kalendářního dne po releasu PZ do produktivního prostředí. V případě, že nedojde k předání Akceptačního protokolu v daném termínu, zašle příslušný Vedoucí projektového týmu Poskytovatele písemnou informaci na Vedoucí programu Objednatele i Poskytovatele, že daný PZ je považován za akceptovaný z důvodu nesoučinnosti ze strany Objednatele. V takovém případě potvrzuje na základě této informace Akceptaci PZ Vedoucí programu Poskytovatele.

Doba zajištění aktivity

Dle potřeby v garantované provozní době:

5x12 – garantovaná provozní doba znamená zajištění služeb v pracovní dny 12 hodin denně (7:00 – 19:00).

SLA parametry / Vyhodnocení

Definice

Požadovaná hodnota

Vyhodnocení

Požadované výstupy aktivity

Název výstupu

Charakteristika

Způsob akceptace

Akceptovaný PZ

V případě dokončení realizace rozvojového požadavku je potvrzena Akceptace daného PZ.

Formální potvrzení akceptačního protokolu k PZ.

Způsob stanovení celkové ceny aktivity a fakturace

Dle plnění

Fakturace je realizována dle skutečně čerpaných kapacit na realizaci PZ za jednotkovou cenu Služeb rozvoje, kdy potvrzení kapacit je předmětem akceptačního protokolu. Skutečné čerpání nesmí překročit maximální stanovený objem kapacit ze strany Poskytovatele k příslušnému PZ.

Fakturace je realizována souhrnně za každé vyhodnocovací období (kalendářní měsíc), ve kterém byly jednotlivé PZ akceptovány se zohledněním příslušné kreditace.



2.3.2Finální akceptace Díla (Systému)

Období Finální akceptace Díla bude probíhat po dobu 3 měsíců od ukončení poskytování akceptační části služeb, tedy nejpozději od 2. 1. 20234. Po dobu Finální akceptace Díla bude ze strany Poskytovatele zajištěno poskytování pilotní části služeb, tedy bude zajištěn plnohodnotný provoz Systému.

Předmět finální akceptace Díla (Systému):

Předmětem bude detailní ověření dílčích implementovaných funkčností i chod celého Systému v plně produktivním provozu s využitím produktivních dat a dokončenou komplexní integrací Systému na okolní části informačního prostředí SZIF.

Předmětem rovněž bude ověření stavu projektové, provozní, bezpečnostní i implementační dokumentace, kdy bude zejména nezbytné potvrdit:

  • Kompletnost dokumentace

  • Obsah jednotlivých typů dokumentace

  • Aktuálnost dokumentů

  • Způsob a formu zpracování

  • Využitelnost dokumentace, a to zejména ve vztahu k dalším provozním i rozvojovým aktivitám.

Průběh Finální akceptace Díla bude realizován na základě definovaného projektového harmonogramu a stanovených detailních akceptačních kritérií.

Součástí Finální akceptace Díla bude závěrečné formální jednání implementačního týmu projektu, které potvrdí dokončení implementace Systému, předání do plnohodnotného provozu a zahájení poskytování Služeb dle Přílohy č. 3 Smlouvy v plném rozsahu.



Nezbytný vstup:

  • Dokončené Dílo – Systém dle stanovených požadavků zahrnujících veškeré definované funkčnosti.

  • Dokumentace Systému nezbytná k zahájení Finální akceptace Díla (Systému).

  • Projektová dokumentace nezbytná k zahájení Finální akceptace Díla (Systému).



Požadovaný výstup služeb:

  • Akceptační protokoly potvrzující splnění veškerých funkčních, provozních, projektových, bezpečnostních a implementačních požadavků na dodávku Systému.

  • Aktualizovaná dokumentace Systému.



Termín zahájení poskytování služeb:

  • 1. pracovní den po ukončení poskytování akceptační části služeb (nejpozději 2. 1. 20234).



Doba trvání:

  • 3 kalendářní měsíce



Termín ukončení etapy:

  • Nejpozději 31. 3. 20243



Kritéria akceptace služeb:

  • Systém je produktivně užíván:

    • Neexistují žádné Vady Systému kategorie A a kategorie B k funkčnostem, které byly předmětem Implementace; rovněž žádná implementovaná funkčnost není akceptována s výhradou;

    • Neexistují žádná nefunkční rozhraní, která byla předmětem Implementace;

    • Prostředí je provozně stabilní, nejsou na úrovni Systému sledovány nekonzistence v zátěži na úrovni technické a síťové infrastruktury po dobu minimálně dvou kalendářních měsíců.

  • Byl proveden plný rozsah testů Systému, který byl vyžadován nastavenou metodikou Implementace, testy byly realizovány v souladu s Best Practice a příslušnými legislativními i dalšími předpisy závaznými pro Objednatele (typicky ISO/IEC 27001).

  • Je předána veškerá dokumentace:

    • Dokumentace je kompletní a v plném požadovaném rozsahu;

    • Jednotlivé části Dokumentace jsou aktuální a akceptované;

    • Dokumentace v podobě modelů je plně dostupná pracovníkům Objednatele dle stanovených principů;

    • Technická dokumentace Systému včetně zdrojových kódů, popisů vývoje a vývojových objektů, customizací, úprav je plně dostupná pracovníkům Objednatele dle stanovených principů;

    • Veškerá projektová dokumentace je uložena na určeném projektovém úložišti a je akceptovaná.

  • Jsou nastavené Programové struktury a projektové principy pro zahájení poskytování Služeb dle přílohy č. 3 Smlouvy.

  • Jsou finálně potvrzeny všechny požadované akceptační protokoly a projekt dodávky Díla – Systému je formálně ukončen.

2.3.3Cloudové služby v době pilotního a akceptačního provozu

Cloudové služby poskytované před zahájením Pilotního a akceptačního provozu jsou součástí Implementace Systému. Cloudové služby poskytované po dobu Pilotního a akceptačního provozu se řídí pravidly dle Přílohy č. 3 Smlouvy, a to včetně pravidel kreditace při porušení povinností při jejich poskytování. Cloudové služby poskytované po ukončení Pilotního a akceptačního provozu jsou součástí Služeb provozu.

3Závazné milníky pro předání Díla (Systému)

Tyto stanovené milníky pro předání Díla jsou definované jako nepřekročitelné. Veškeré dílčí i celkové harmonogramy na úrovni projektu, Implementace, Pilotního a akceptačního provozu musí být v souladu s níže stanovenými termíny. Mimo tyto milníky je možné harmonogramy upravovat takovým způsobem, aby byly zajištěny podmínky pro realizaci implementace Díla v souladu s veškerými podmínkami definovanými ve Smlouvě i Zadávací dokumentaci na realizaci veřejné zakázky „VZ Portálový systém SZIF a Portálové aplikace pro Monitoring Approach (Portálový systém SZIF)“.

  • Dodávka licencí pro Implementaci – nejpozději do 20 (dvaceti) pracovních dní ode dne účinnosti smlouvy, tj. do BUDE DOPLNĚNO PŘED PODPISEM SMLOUVY.

  • Nastavení projektu a zahájení projektu formou kick-off projektu, tedy dokončení Přípravné etapy Analytické a přípravné fáze Implementace – nejpozději 10. (desátý) pracovní den ode dne účinnosti smlouvy, tj. BUDE DOPLNĚNO PŘED PODPISEM SMLOUVY.

  • Dokončení implementace funkčností kategorie „Kritická - prioritní“, testování, podmíněná akceptace (tj. akceptace všech funkčností kategorie „Kritická - prioritní“) a přechod do Pilotního a akceptačního provozu – nejpozději do 31. 315. 9. 2022.

  • Dokončení implementace funkčností kategorie „Kritická -ostatní“, testování, podmíněná akceptace všech funkčností kategorie „Kritická - ostatní“ – nejpozději do 31. 3. 2023.

  • Zajištění implementace a testování všech funkčností kategorie „Požadovaná“ a zahájení Finální akceptace Díla (Systému) v rámci Pilotního a akceptačního provozu. Předložení veškeré nezbytné projektové a provozní dokumentace pro zahájení akceptačního řízení a posouzení ze strany Odboru hlavního architekta v souladu s § 5 odst. 2, Zákona č. 365/2000 Sb. – 9 15,5 měsíců ode dne zahájení Pilotního a akceptačního provozu – nejpozději do 31. 12. 20232.

  • Ukončení pilotní části služeb a dokončení finální akceptace Díla (ukončení Pilotního a akceptačního provozu) – 12 18,5 měsíců ode dne zahájení Pilotního a akceptačního provozu – nejpozději do 31. 3. 20234.

4Vyhodnocení a akceptace dodávky Díla (Systému)

Realizace dodávky Díla (Systému) podléhá vyhodnocení, zda byly jednotlivé části dodávky a poskytované služby realizovány v souladu s definovanými podmínkami a obsah výstupů odpovídá požadavkům Objednatele vyplývajícím ze Smlouvy, případně projektové a implementační dokumentace. Poskytovatel je povinen v souladu s definovanými harmonogramy vypracovat odpovídající projektovou dokumentaci, která dokládá realizaci činností Poskytovatele v souladu s definovanými požadavky. V rámci etapy Pilotního a akceptačního provozu je Poskytovatel povinen vypracovávat projektovou dokumentaci na bázi vyhodnocovacího období (jeden kalendářní měsíc), kdy předmětem bude čerpání služeb ve skončeném vyhodnocovacím období. Tato projektová dokumentace se sestává z odpovídajících výkazů jednotlivých aktivit tak, jak jsou definovány v katalogových listech a popisech služeb, případně obsah projektové dokumentace vyplývá z implementačních a projektových metodik. Součástí jednotlivých projektových dokumentů musí být vyhodnocení kvality poskytovaných služeb dle definovaných požadavků a SLA parametrů včetně vyčíslené kreditace dle definovaných podmínek. Kreditace aktivit v rámci Pilotní části služeb Pilotního a akceptačního provozu bude vždy vztažena k danému vyhodnocovacímu období a částka faktury za dané období bude o tuto kreditaci upravena. Kreditace vztahující se k samotné Implementaci Díla a souvisejícím oblastem je primárně vztažena k jednotlivým fakturačním milníkům Díla a cenám dle přílohy č. 7 Smlouvy.  

V následujících kapitolách 4.1. – 4.3. jsou uvedeny jednotlivé parametry vyhodnocení a kreditace k nim vztažené. V případě, že není uvedeno jinak, je v rámci níže definovaných kapitol cenou, ze které je kreditace kalkulována, vždy myšlena cena bez DPH.

4.1Parametry a kreditace Dodávky licencí SW produktů

P.č.

Název parametru

Kreditace

Způsob výpočtu

1.

Nedodržení termínu Dodávky licencí WS SW produktů

30.000,- Kč

Kreditace za každý kalendářní den prodlení při nesplnění daných termínů Dodávky licencí SW produktů ze strany Poskytovatele. Kreditace bude uplatněna formou slevy z ceny Dodávky licence. (Cena dodávky licencí vč. maintenance do doby zahájení poskytování Služeb provozu).

2.

Nepředání technické dokumentace výrobce nebo podmínek užití a použití open source software

15.000,- Kč

Kreditace za každý kalendářní den prodlení s předáním technické dokumentace výrobce nebo podmínek užití a použití open source software ze strany Poskytovatele. Kreditace bude uplatněna formou slevy z ceny Dodávky licence.

(Cena dodávky licencí vč. maintenance do doby zahájení poskytování Služeb provozu).

3.

Nepředání potvrzení o zajištění maintenance výrobce nebo potvrzení Poskytovatele o zajištění maintenance open source software

15.000,- Kč

Kreditace za každý kalendářní den prodlení s předáním potvrzení o zajištění maintenance Objednateli jako koncovému příjemci maintenance výrobce nebo Poskytovatele ve vztahu k open source software ze strany Poskytovatele. Kreditace bude uplatněna formou slevy z ceny Dodávky licence.

(Cena dodávky licencí vč. maintenance do doby zahájení poskytování Služeb provozu).

4.2Parametry a kreditace implementace Systému

P.č.

Název parametru

Kreditace

Způsob výpočtu

1.

Nedodržení termínu zahájení projektu formou kick-off

1,0 %

Z ceny Analytické a přípravné fáze Implementace (Jednorázová cena služby) za každý kalendářní den prodlení z důvodů na straně Poskytovatele. Kreditace bude uplatněna formou slevy z ceny Analytické a přípravné fáze Implementace.

Nedodržení dílčího milníku jednotlivých etap i koncového termínu Analytické a přípravné fáze dle platného projektového a implementačního harmonogramu

1,0 %

Z ceny Analytické a přípravné fáze Implementace (Jednorázová cena služby) za každý kalendářní den prodlení z důvodů na straně Poskytovatele. Prodlení může být způsobeno nepředáním, nebo neakceptací požadovaného dílčího i finálního výstupu dle stanovených parametrů.

Kreditace bude uplatněna formou slevy z ceny Analytické a přípravné fáze Implementace.

Nedodržení dílčího milníku jednotlivých etap vlastní Implementace funkčností kategorie „Kritická - prioritní“, „Kritická – ostatní“ a „Požadovaná“ dle platného projektového a implementačního harmonogramu

0,5 %

Z ceny vlastní Implementace (Jednorázová cena služby) za každý kalendářní den prodlení z důvodů na straně Poskytovatele. Prodlení může být způsobeno nepředáním, nebo neakceptací požadovaného dílčího výstupu dle stanovených parametrů.

Kreditace bude uplatněna formou slevy z ceny vlastní Implementace.

4.

Neuvolnění funkčnosti do testovacího prostředí ve schváleném termínu

0,1 %

Z ceny vlastní Implementace (Jednorázová cena služby) za každý kalendářní den prodlení předání jednotlivé funkčnosti do testovacího prostředí z důvodů na straně Poskytovatele. Prodlení může být způsobeno nepředáním, nebo neakceptací předání funkčnosti do testovacího prostředí.

Kreditace bude uplatněna formou slevy z ceny vlastní Implementace.

5.

Neuvolnění funkčnosti do produktivního prostředí ve schváleném termínu

0,2 %

Z ceny vlastní Implementace (Jednorázová cena služby) za každý kalendářní den prodlení předání jednotlivé funkčnosti do produktivního prostředí z důvodů na straně Poskytovatele. Prodlení může být způsobeno nepředáním, nebo neakceptací předání funkčnosti do testovacího prostředí.

Kreditace bude uplatněna formou slevy z ceny vlastní Implementace.

6.

Nedodržení termínu Dokončení implementace, testování a podmíněné akceptace (dokončení vlastní Implementace funkčností kategorie „Kritická - prioritní“ a „Kritická - ostatní“)

1,0 %

Z ceny vlastní Implementace (Jednorázová cena služby) za každý kalendářní den prodlení z důvodů na straně Poskytovatele. Prodlení může být způsobeno nepředáním, nebo neakceptací požadovaného dílčího výstupu dle stanovených parametrů.

Kreditace bude uplatněna formou slevy z ceny vlastní Implementace.

7.

Nedodržení termínu Dokončení implementace, testování a podmíněné akceptace funkčností kategorie Požadovaná

1,5 %

Z ceny vlastní Implementace (Jednorázová cena služby) za každý kalendářní den prodlení předání jednotlivé funkčnosti do produktivního prostředí z důvodů na straně Poskytovatele.

Prodlení může být způsobeno nepředáním, nebo neakceptací požadovaného dílčího výstupu dle stanovených parametrů.

Kreditace bude uplatněna formou slevy z ceny vlastní Implementace.



4.3Parametry a kreditace Pilotního a akceptačního provozu

4.3.1Parametry a kreditace Akceptační části služeb

Nepoužije se.

4.3.2P.č.

4.3.3Název parametru

4.3.4Kreditace

4.3.5Způsob výpočtu

4.3.61.

4.3.7Neuvolnění funkčnosti do testovacího prostředí ve schváleném termínu

4.3.80,1 %

4.3.9Z ceny vlastní Implementace (Jednorázová cena služby) za každý kalendářní den prodlení předání jednotlivé funkčnosti do testovacího prostředí z důvodů na straně Poskytovatele. Prodlení může být způsobeno nepředáním, nebo neakceptací předání funkčnosti do testovacího prostředí.

4.3.10Kreditace bude uplatněna formou slevy z ceny vlastní Implementace.

4.3.112.

4.3.12Neuvolnění funkčnosti do produktivního prostředí ve schváleném termínu

4.3.130,2 %

4.3.14Z ceny vlastní Implementace (Jednorázová cena služby) za každý kalendářní den prodlení předání jednotlivé funkčnosti do produktivního prostředí z důvodů na straně Poskytovatele. Prodlení může být způsobeno nepředáním, nebo neakceptací předání funkčnosti do testovacího prostředí.

4.3.15Kreditace bude uplatněna formou slevy z ceny vlastní Implementace.

4.3.163.

4.3.17Nedodržení termínu Dokončení implementace, testování a podmíněné akceptace

4.3.181,5 %

4.3.19Z ceny vlastní Implementace (Jednorázová cena služby) za každý kalendářní den prodlení předání jednotlivé funkčnosti do produktivního prostředí z důvodů na straně Poskytovatele.

4.3.20Prodlení může být způsobeno nepředáním, nebo neakceptací požadovaného dílčího výstupu dle stanovených parametrů.

4.3.21Kreditace bude uplatněna formou slevy z ceny vlastní Implementace.

4.3.22

4.3.23Parametry a kreditace Pilotní části služeb

P.č.

Aktivita

Název parametru

Kreditace

Způsob výpočtu

1.

A11

Neprovedení vyhodnocení dopadů požadavku na bezpečnostní a provozní prostředí Systému

10.000,- Kč

Jednorázová kreditace pro každý schválený rozvojový požadavek, kreditace bude uplatněna při akceptaci požadavku.

2.

A11

Nepředání posouzeného PZ na Objednatele v požadovaném termínu.

8.000,- Kč

Jednorázová kreditace za každý kalendářní den prodlení se zasláním ohodnoceného a posouzeného PZ ze strany Poskytovatele, pokud není posun termínu schválen Objednatelem. Kreditace bude uplatněna při akceptaci požadavku.

3.

A11

Neprovedení vyhodnocení dalších požadovaných dopadů PZ (architektura, rozhraní)

5.000,-

Jednorázová kumulativní kreditace pro každý PZ. Výše kreditace je konstantní, pokud nebude provedeno vyhodnocení jednoho, nebo obou uvedených dopadů. Kreditace bude uplatněna při akceptaci požadavku.

4.

A11

Nesplnění schválených milníků PZ z důvodů na straně Poskytovatele

5 %

Jednorázová kreditace z ceny daného PZ pro každý rozvojový požadavek – kreditace bude uplatněna při akceptaci požadavku z ceny PZ v případě, že PZ nebude:

  • předáno k testování v odsouhlaseném termínu, nebo

  • nebude aktualizována dokumentace v odsouhlaseném termínu, nebo

  • nebude provedeno školení v odsouhlaseném termínu, nebo

  • nebude proveden release v odsouhlaseném termínu

za předpokladu, že nebyl posun termínů odsouhlasen na příslušné projektové úrovni.

5.

A11

Neprovedení testování požadavku v testovacím prostředí před požadavkem na release.

10.000,- Kč

Jednorázová kreditace pro každý rozvojový požadavek – kreditace bude uplatněna při akceptaci požadavku z ceny PZ.

6.

A11

Neautorizovaný release

20 %

Jednorázová kreditace pro každý rozvojový požadavek – kreditace bude uplatněna při akceptaci požadavku z ceny PZ.

7.

A01

Dostupnost a odezva prostředí PROD

2,0 %

Z paušální měsíční ceny služeb Pilotního a akceptačního provozu za každých započatých 0,2% pod stanovenou hodnotu parametru.

8.

A01

Dostupnost a odezva prostředí TEST/DEV

1,0 %

Z paušální měsíční ceny služeb Pilotního a akceptačního provozu za každých započatých 0,2% pod stanovenou hodnotu parametru.

9.

A01

Výskyt Vady A

5,0 %

Z paušální měsíční ceny služeb Pilotního a akceptačního provozu za každý další výskyt nad maximální počet vad ve vyhodnocovacím období.

10.

A01

Výskyt Vady B/C

2,0 %

Z paušální měsíční ceny služeb Pilotního a akceptačního provozu za každý další výskyt nad maximální počet vad ve vyhodnocovacím období.

11

A02

Nerealizovaná kopie v daném termínu

2,0 %

Z paušální měsíční ceny služeb Pilotního a akceptačního provozu v případě nerealizace kopie v daném termínu z důvodů na straně Poskytovatele.

12.

A03

Zjištění nerealizované bezpečnostní aktualizace v prostředí PROD

2,0 %

Z paušální měsíční ceny služeb Pilotního a akceptačního provozu za každé zjištěné neprovedení bezpečnostní aktualizace, pokud neprovedení nebylo výslovně schváleno Objednatelem.

13.

A04

Neprovedení otestování bezpečnostní aktualizace v prostředí DEV a TEST

1,0 %

Z paušální měsíční ceny služeb Pilotního a akceptačního provozu za každé zjištěné neprovedení testování bezpečnostní aktualizace v prostředí DEV a TEST, pokud neprovedení nebylo výslovně schváleno Objednatelem.

14.

A06

Zjištění neautorizovaného zásahu (opravy chyby) v Systému

0,5 %

Z paušální měsíční ceny služeb Pilotního a akceptačního provozu za každý zjištěný případ neautorizovaného zásahu do Systému ze strany Poskytovatele.

15.

A07

Nenahlášení podezření na vznik bezpečnostní události/incidentu včas

1,0 %

Z paušální měsíční ceny služeb Pilotního a akceptačního provozu za každých 15 minut prodlení nahlášení podezření na vznik bezpečnostní události/incidentu bezpečnostnímu manažerovi SZIF.

16.

A08

Nenahlášení podezření na vznik provozní události/incidentu včas

0,5 %

Z paušální měsíční ceny služeb Pilotního a akceptačního provozu za každých 15 minut prodlení nahlášení podezření na vznik provozní události/incidentu na 1. úroveň Service Desku SZIF.

17.

A10

Nedodržení reakční doby na přidělení ticketu během provozní doby 5x12

1,0 %

Z paušální měsíční ceny služeb Pilotního a akceptačního provozu za každých 30 minut prodlení (nad rámec stanovené reakční doby) potvrzení zahájení řešení ze strany Poskytovatele pro každý jednotlivý ticket.

18.

A10

Nedodržení reakční doby na přidělení ticketu během provozní doby 7x24

1,0 %

Z paušální měsíční ceny služeb Pilotního a akceptačního provozu za každých 180 minut prodlení (nad rámec stanovené reakční doby) potvrzení zahájení řešení ze strany Poskytovatele pro každý jednotlivý ticket, pokud je ticket ze strany Objednatele zaslán mimo dobu 5x12.



4.3.23.1Vyhodnocení a fakturace Pilotní části služeb Pilotního a akceptačního provozu

Nejpozději během 5. (pátého) pracovního dne vyhodnocovacího období následujícího po ukončení předchozího vyhodnocovacího období předkládá Vedoucí projektového týmu Poskytovatele Vedoucímu projektového týmu Objednatele soupis čerpání kapacit projektového týmu, jehož součástí je zvlášť vyčleněná samostatná část obsahující seznam akceptovaných PZ v uplynulém kalendářním měsíci a reálné uvedení kapacit čerpaných v rámci daných PZ (reálné čerpání nesmí překročit maximální stanovenou a odsouhlasenou kapacitní náročnost jednotlivých PZ). Vedoucí projektového týmu Objednatele provede kontrolu soupisu čerpání kapacit, a pokud je tento soupis v pořádku, akceptuje jej včetně zvlášť autorizovaného seznamu akceptovaných PZ.

Fakturace za vyhodnocovací období je tak realizována na základě akceptace Zprávy o plnění pilotní části služeb a na základě dílčích akceptací prací a potvrzeného seznamu akceptovaných PZ. Přílohou faktury za konkrétní vyhodnocovací období jsou všechny příslušné akceptační dokumenty za dané období včetně vyčíslení uplatněných kreditací k jednotlivým aktivitám a rozvojovým požadavkům (PZ).

4.3.24Parametry a kreditace Finální akceptace Díla (Systému)

P.č.

Název parametru

Kreditace

Způsob výpočtu

1.

Neakceptování dodávky Díla (Systému) v odsouhlaseném termínu

1,5 %

Z celkové ceny Implementace Díla za každý kalendářní den prodlení s akceptací způsobené na straně Poskytovatele. Prodlení může být způsobeno nepředáním, nebo neakceptací předání jednotlivých požadovaných výstupů, a to specificky:

  • Plně produktivně provozovaný Systém zajišťující veškeré požadované funkčnosti v odpovídající kvalitě,

  • Kompletní provozní a bezpečnostní dokumentace nezbytná k zajištění služeb dle Přílohy č. 3 Smlouvy včetně veškerých zdrojových kódů administrátorských a jiných dokumentů,

  • Kompletní akceptovaná projektová dokumentace k implementaci Systému,

  • Kompletní architektonická dokumentace včetně všech požadovaných modelů.

Případně dalšími vadami bránící akceptaci dle projektově a smluvně stanovených podmínek.

Kreditace bude uplatněna formou slevy z Celkové ceny Implementace.



S tátní zemědělský intervenční fond

Ve Smečkách 33, 110 00 Praha 1 Strana 80/80

Document Metadata

Filed: March 18th, 2023