SMLOUVA
SMLOUVA
O DODÁVCE A IMPLEMENTACI ŘEŠENÍ PRO E-PORTÁL ZLÍNSKÉHO KRAJE A ZAJIŠTĚNÍ NÁSLEDNÉ PODPORY
č. objednatele: D/3239/2024/ŘDP
uzavřená na základě ust. § 2586 a násl. a § 2358 a násl. zákona č. 89/2012 Sb., občanský zákoník, ve znění pozdějších předpisů (dále jen „občanský zákoník“)
Smluvní strany
Objednatel: Zlínský kraj
Adresa: xxxxx Xxxxxx Xxxx 00, 000 00 Xxxx
IČO: 70891320
DIČ: CZ70891320
Zastoupený: Ing. Xxxxxxx Xxxxxxx, hejtmanem Bankovní spojení: Česká spořitelna, a.s., č.ú.1827552/0800
(dále jen „Objednatel“) a
Zhotovitel: InQool, a.s
Adresa sídla: Xxxxxxxxxxxx 00/0, Xxxxxxx, 000 00 Xxxx IČO: 29222389
DIČ: CZ29222389
Zapsaný v obch. rejstř.: vedeném u Krajského soudu v Brně, oddíl B, vložka 6125 Zastoupený1: Mgr. Xxxxxxx Xxxxx, předsedou představenstva
Mgr. Xxxxxxx Xxxxx, členem představenstva Bankovní spojení2: Československá obchodní banka, a. s.; č.ú.
(dále jen „Zhotovitel“)
Preambule
1. Tato smlouva je uzavírána v rámci realizace projektu „Rozvoj digitalizace ve Zlínském kraji“, reg. číslo CZ.06.01.01/00/22_008/0000473 (dále jen „Projekt “), který Objednatel realizuje v rámci Integrovaného regionálního operačního programu (dále jen „IROP“), a který je spolufinancovaný z fondů Evropské unie a na který obdržel Objednatel dotaci od Ministerstva pro místní rozvoj – poskytovatele dotace. Uzavření této smlouvy předcházelo zadávací řízení veřejné zakázky s názvem „Rozvoj digitalizace ve Zlínském kraji“, resp. jeho části A, a to dle zákona o zadávání veřejných zakázek. Zhotovitel se zavazuje splnit předmět této smlouvy nejen v souladu s touto smlouvou, ale také v souladu se zadávací dokumentací (zadávacími podmínkami zadávacího řízení) a jeho nabídkou, které předcházely a týkaly se uzavření této smlouvy. V případě rozporů jednotlivých výše uvedených dokumentů má přednost tato smlouva. V případě rozporů jednotlivých ustanovení příloh této smlouvy a ustanovení smlouvy samotné mají přednost ustanovení samotné smlouvy, pokud není v této smlouvě výslovně uvedeno jinak.
2. Účelem této smlouvy je dodávka, implementace a instalace nového portálového řešení na krajské úrovni, které bude sloužit jako transakční řešení pro fyzické a právnické osoby, a dále jako portál pro spolupráci s krajskými příspěvkovými organizacemi na řešení agend. Portál bude mít pro všechny zmíněné rovněž informační funkci. Účelem této smlouvy je rovněž následná podpora provozu předmětného portálového řešení (díla).
1 Jméno a příjmení osoby a označení funkce statutárního orgánu
2 Bankovní účet se musí shodovat s účtem používaným pro ekonomickou činnost registrovaným u správce daně.
3. Zhotovitel prohlašuje, že je plně způsobilý k řádnému a včasnému provedení předmětu smlouvy, že se detailně seznámil s rozsahem a povahou předmětu smlouvy, a to tak, že jsou mu známy veškeré relevantní technické, kvalitativní a jiné podmínky nezbytné k jeho realizaci, a že disponuje takovými kapacitami a odbornými znalostmi, které jsou nezbytné pro realizaci předmětu smlouvy za dohodnuté maximální smluvní ceny uvedené v této smlouvě, a to rovněž ve vazbě na jím prokázanou kvalifikaci pro plnění veřejné zakázky. Pověří-li Zhotovitel provedením díla či zajištěním podpory jeho provozu jinou osobu, má Xxxxxxxxxx při provádění díla či zajištění podpory jeho provozu jinou osobou odpovědnost, jako by dílo či zajištění podpory jeho provozu prováděl sám. Zhotovitel je oprávněn plnit předmět smlouvy pouze prostřednictvím svých zaměstnanců nebo osob uvedených v seznamu poddodavatelů. Změnu poddodavatele je Zhotovitel oprávněn provést pouze s předchozím souhlasem Objednatele. Xxxxxxxxxx je povinen dílo včetně jeho následné podpory provozu plnit prostřednictvím osob (projektového týmu) uvedených v článku X. odst. 4 této smlouvy.
4. Pokud je v této smlouvě uvedeno slovo „řádně“, pak nevyplývá-li z kontextu jinak, myslí se tím bez veškerých vad a nedodělků, a to jak faktických, tak i právních. Pokud je v této smlouvě nebo její příloze uvedeno slovo „zadavatel“ nebo „Zadavatel“ myslí se jím „Objednatel“. Pokud je v této smlouvě nebo její příloze uvedeno slovo „dodavatel“ nebo „Dodavatel“ myslí se jím „Zhotovitel“. Připadne-li termín (doba) plnění uvedená v tabulce odstavce 1 článku I. této smlouvy na sobotu, neděli či státní svátek, dohodly se smluvní strany na tom, že je možné termín (dobu) plnění splnit (bez toho, aniž by se Zhotovitel ocitl v prodlení) ještě bezprostředně následující pracovní den.
Článek I. Předmět smlouvy
1. Xxxxxxxxxx se touto smlouvou zavazuje provést na svůj náklad a na své nebezpečí pro Objednatele dílo a zajistit podporu jeho provozu a Objednatel se touto smlouvou zavazuje uhradit Xxxxxxxxxxx za provedení díla a za zajištění jeho provozu a podpory dohodnutou cenu, to vše za podmínek v této smlouvě dále uvedených.
2. Pro účely této smlouvy se dílem rozumí komplexní dodávka a implementace (včetně instalace) nového portálového řešení na krajské úrovni, které bude sloužit jako transakční řešení pro fyzické a právnické osoby, a dále jako portál pro spolupráci s krajskými příspěvkovými organizacemi na řešení agend. Portál bude mít pro všechny zmíněné rovněž informační funkci. Podrobný popis díla je uveden v příloze č. 1, která je nedílnou součástí této smlouvy. Součástí díla je také zpracování implementační analýzy (dokumentace), nezbytné kvalifikované seznámení (školení) obsluhy/zaměstnanců Objednatele, jakož i zástupců příslušných příspěvkových organizací Objednatele (tj. uživatelů a administrátorů) s dodaným dílem, a dále také testovací a pilotní provoz, a rovněž předání veškeré dokumentace související s dodaným dílem (ať už uvedené v této smlouvě, či jejích přílohách).
3. Podmínky zajištění podpory provozu díla jsou uvedeny v příloze č. 2, která je nedílnou součástí této smlouvy.
4. Při plnění smlouvy se Zhotovitel zavazuje postupovat v souladu se svojí nabídkou, kterou podal v rámci zadávacího řízení, které předcházelo a týkalo se uzavření této smlouvy (mj. též v souladu s údaji, které uvedl ve „Formuláři technických požadavků“, který byl součástí jeho nabídky a který je přílohou č. 4 této smlouvy) a v souladu s obsahem formuláře OHA, který je přílohou č. 6 (resp. v souladu s příslušnými požadavky v něm uvedenými, pokud se týkají E-portálu či předmětu plnění této smlouvy).
5. Při plnění této smlouvy se Zhotovitel zavazuje dodržovat Bezpečnostní pravidla informačního systému Objednatele uvedená v příloze č. 3 této smlouvy.
Článek II.
Způsob, doba a místo plnění
1. V níže uvedené tabulce je uveden harmonogram plnění, který je pro smluvní strany závazný, a na základě něhož bude předmět plnění prováděn po příslušných částech v rámci jednotlivých fázích.
Fáze | Obsah plnění (podrobnější popis jednotlivých výstupů zejména co se týče fází 1 až 4 je uveden v kapitole „Požadované výstupy díla“ v Příloze č. 1 této smlouvy) | Termín (doba) plnění (uplynutí Milníku) |
fáze 1 - implementační analýza | Realizace implementační analýzy (IA) V průběhu plnění této fáze Zhotovitel předává průběžně Objednateli dílčí části implementační analýzy, které Objednatel průběžně připomínkuje. Vytvoření grafického návrhu Vytvoření znalostní databáze (DB) pro chatbota | ihned po nabytí účinnosti této smlouvy |
Akceptace příslušné části plnění - akceptační řízení: nejpozději 10 pracovních dnů před uplynutím Milníku 1 (před podpisem akceptačního protokolu č. 1) předá Zhotovitel finální verzi Implementační analýzy vč. vizuálního návrhu Objednateli a tento se k ní vyjádří a podá Zhotoviteli případné připomínky do 5 pracovních dnů. Připomínky budou zapracovány Zhotovitelem do 5 pracovních dnů. | ||
Milník 1 | Vyhotovení a podpis akceptačního protokolu č. 1 | nejpozději do 75 dnů od nabytí účinnosti této smlouvy |
fáze 2 – vývoj a implementace do testovacího prostředí | Vývoj ePortálu a chatbota dle IA V průběhu plnění této fáze Zhotovitel předává průběžně Objednateli dílčí části vývoje a implementace do testovacího prostředí, které Objednatel průběžně připomínkuje či kontroluje, nicméně akceptační řízení jako celek k této části plnění probíhá až na konci této fáze (viz buňka níže) Tvorba systému ePortál Realizace integrací Eportálu na cílové systémy Tvorba formulářů Eportálu Tvorba obsahu v rámci Eportálu (životní situace) Tvorba systému chatbot Implementace do testovacího prostředí Objednatele | |
Akceptace příslušné části plnění - akceptační řízení: Nejpozději 14 pracovních dnů před uplynutím Milníku 2 (před podpisem akceptačního protokolu č. 2) navrhne Zhotovitel termín zahájení akceptačního řízení Objednateli. Akceptační řízení probíhá zpravidla 14 pracovních dní, ve kterých Objednatel kontroluje předávanou příslušnou část plnění. | ||
Milník 2 | Vyhotovení a podpis akceptačního protokolu č. 2 | nejpozději do 9 měsíců od nabytí účinnosti této smlouvy |
fáze 3 – testovací provoz a realizace testů | Testování ePortálu a chatbota v testovacím prostředí Objednatele Realizace testů podle IA |
Odstranění vad a nedodělků zjištěných během testovacího provozu. Implementace řešení ePortálu do produkčního prostředí Objednatele | ||
Akceptace příslušné části plnění - akceptační řízení: nejpozději 7 pracovních dnů před uplynutím Milníku 3 (před podpisem akceptačního protokolu č. 3) navrhne Zhotovitel termín zahájení akceptačního řízení Objednateli. Akceptační řízení probíhá zpravidla 5 pracovních dní, ve kterých Objednatel kontroluje předávanou příslušnou část plnění | ||
Milník 3 | Vyhotovení a podpis akceptačního protokolu č. 3 | nejpozději do 10 měsíců od nabytí účinnosti této smlouvy |
fáze 4 – pilotní provoz a realizace testů | Pilotní provoz ePortálu a chatbota v produkčním prostředí Objednatele Realizace testů podle IA Asistence při pilotním provozu Odstranění vad a nedodělků zjištěných během pilotního provozu. Implementace do produkčního prostředí Objednatele Vytvoření systémové dokumentace Předání licencí | |
Akceptace příslušné části plnění a dále díla jako celku - přejímací řízení: nejpozději 7 pracovních dnů před uplynutím Milníku 4 (před podpisem protokolu o předání a převzetí díla) navrhne Xxxxxxxxxx termín zahájení přejímacího řízení Objednateli. Přejímací řízení probíhá zpravidla 5 pracovních dnů, ve kterých Objednatel kontroluje předávanou příslušnou část plnění i dílo jako celek. | ||
Milník 4 | Vyhotovení a podpis protokolu o předání a převzetí díla | nejpozději do 11 měsíců od nabytí účinnosti této smlouvy. |
fáze 5 – podpora díla | zhotovitel zajistí podporu díla v průběhu jeho běžného provozu | od dokončení fáze 4 v délce 72 měsíců |
2. Dodávka a implementace díla a rovněž testovací a pilotní provoz včetně realizace testů proběhne v sídle Objednatele. Jednotlivé druhy školení obsluhy/zaměstnanců Objednatele, jakož i zástupců příslušných příspěvkových organizací (tj. administrátorů a uživatelů) proběhnou nejpozději do konce fáze 4 v sídle Objednatele (pokud se smluvní strany nedohodnou jinak), a to v časovém rozsahu a počtu osob detailně uvedených v příloze č. 1 této smlouvy. Podpora provozu díla bude probíhat v souladu s přílohou č. 2 této smlouvy.
3. Při provádění předmětu plnění této smlouvy se Zhotovitel zavazuje počínat si s odbornou péčí tak, aby byl zcela naplněn předmět a účel této smlouvy a zajištění podpory provozu díla bylo v souladu s požadavky Objednatele uvedenými v této smlouvě a jejích přílohách.
4. Zhotovitel je povinen v průběhu plnění předmětu této smlouvy dodržovat obecně závazné předpisy a normy, postupovat s náležitou odbornou péčí, podle nejlepších znalostí a schopností, sledovat a chránit oprávněné zájmy Objednatele. Zhotovitel je povinen vynaložit maximální úsilí, aby docílil nejlepšího možného výsledku při plnění předmětu této smlouvy prostřednictvím využití svých znalostí a zkušeností.
5. Při plnění předmětu této smlouvy postupuje Zhotovitel samostatně, je však vázán pokyny Objednatele. Zhotovitel je povinen bez zbytečného odkladu písemně upozornit Objednatele na nevhodnost jeho pokynů k provedení předmětu této smlouvy. Pokud nevhodné pokyny brání v řádném provádění předmětu této smlouvy, je Zhotovitel povinen v nezbytně nutném rozsahu přerušit provádění předmětu této smlouvy do doby změny pokynů Objednatele nebo písemného sdělení, že Objednatel trvá na provádění předmětu této smlouvy dle svých pokynů. V souvislosti s realizací předmětu této smlouvy po dobu takového přerušení má Zhotovitel nárok na prokazatelně vynaložené náklady.
6. Zhotovitel je povinen v průběhu provádění předmětu této smlouvy neprodleně informovat Objednatele o všech skutečnostech, které mají nebo mohou mít vliv na provedení díla či podporu jeho provozu.
7. Pokud Objednatel zjistí, že Xxxxxxxxxx provádí předmět plnění této smlouvy v rozporu se svými povinnostmi, je oprávněn požadovat, aby Zhotovitel odstranil v Objednatelem stanovené lhůtě vzniklé vady a předmět plnění prováděl řádným způsobem.
Článek III.
Spolupůsobení Objednatele a Zhotovitele
1. Objednatel se zavazuje poskytnout nebo zprostředkovat Zhotoviteli informace nezbytné pro řádné plnění této smlouvy.
2. Objednatel se zavazuje poskytnout Zhotoviteli (případně třetím osobám, které se budou podílet na plnění předmětu této smlouvy) veškerou součinnost potřebnou pro řádné plnění této smlouvy, kterou je možné po něm spravedlivě požadovat.
3. Zhotovitel se zavazuje poskytnout nezbytnou součinnost technickému dozoru Objednatele, případně pak osobám, které provedou nezávislé penetrační testy.
Článek IV.
Licenční podmínky
1. Zhotovitel podpisem této smlouvy poskytuje Objednateli v souladu s § 2358 a násl. občanského zákoníku nevýhradní licenci ke všem způsobům užití administrátorské a uživatelské provozní dokumentace, coby autorského díla vytvořeného v rámci plnění této smlouvy.
Pokud se týká ostatních písemných výstupů, které Zhotovitel na základě této smlouvy pro Objednatele zhotoví (a které nespadají pod ustanovení odst. 2 až 5 tohoto článku), vztahují se na ně práva a povinnosti, která podle zákona č. 121/2000 Sb., autorský zákon, ve znění pozdějších předpisů (dále jen „autorský zákon“) platí pro dílo vytvořené na objednávku.
Objednatel má rovněž právo dokumenty dle tohoto odstavce dále jakkoliv upravovat, zejm. učinit z nich součást jiného autorského díla či používat z nich výňatky.
Licence dle tohoto odstavce 1 se udělují jako časově, množstevně a územně neomezené.
2. K veškerému software (včetně technologického) a ke grafickým dílům, která jsou součástí díla, Zhotovitel podpisem této smlouvy poskytuje Objednateli ve smyslu § 2358 a násl. občanského zákoníku také příslušné licence. Tyto licence jsou dodány (poskytnuty) jako územně neomezené, a to (časově) minimálně po dobu trvání majetkových práv autora k autorskému dílu, přičemž jsou dodány (poskytnuty) tak, aby Objednatel mohl dílo užívat zejména, nikoliv však výlučně k účelu, ke kterému bylo takové dílo Zhotovitelem vytvořeno v souladu s touto smlouvou, a to minimálně v rozsahu nezbytném pro řádné užívání díla Objednatelem. Pokud se však jedná o dobu platnosti standardizovaných licencí, Zhotovitel dodává (poskytuje) tyto licence tak, jak je na trhu nabízí jejich producent, nicméně pokud nesplňují podmínku dle předchozího souvětí, pak je Zhotovitel povinen zajistit obnovu těchto licencí nebo návaznou dodávku dalších licencí tak, aby uvedená podmínka byla fakticky splněna, a to alespoň do skončení doby
podpory díla (tj. až do skončení fáze 5); náklady na obnovu nebo znovupořízení licencí k software a ke grafickým dílům jsou již zahrnuty v ceně příslušných licencí (příloha č. 5 této smlouvy).
3. V případě vzniku skutečností uvedených v odstavci 4 tohoto článku bude Zhotovitel povinen poskytnout Objednateli zdrojový kód dodaného software (s výjimkou platformového software) v nezakryptované podobě společně s jeho písemným komentářem. Zhotovitel je rovněž, v případě vzniku skutečností uvedených v odstavci 4 tohoto článku, povinen poskytnout Objednateli také zdrojový kód v nezakryptované podobě společně s jeho písemným komentářem případných úprav, změn a dalšího vývoje dodaného software, pokud k nim v rámci plnění této smlouvy došlo. V případě vzniku skutečnosti uvedené v odstavci 4 písmeno b) tohoto článku, se povinnost Zhotovitele vztahuje pouze na tu část zdrojového kódu, která je objektivně potřebná pro splnění smluvní povinnosti nebo závazku Objednatele.
4. V případě, že:
a) Zhotovitel neposkytne Objednateli sjednané plnění dle této smlouvy včas a řádně (zejména neposkytne podporu díla), nebo
b) Objednatel bude v rámci realizace fáze 5 potřebovat zajistit v důsledku plnění svých smluvních povinností nebo závazků vůči třetím osobám zpřístupnění zdrojového kódu (nebo jeho příslušné části) Zhotovitelem dodaného softwaru (např. v případě zadávání veřejné zakázky, k jejímuž splnění je nutná znalost zdrojového kódu nebo jeho příslušné části Zhotovitelem dodaného software), nebo
c) dojde k uplynutí doby podpory díla (fáze 5),
dojde tímto ke vzniku skutečnosti, na níž odkazuje ustanovení odstavce 3 tohoto článku a v takovém případě je Zhotovitel povinen splnit na výzvu Objednatele povinnosti spočívající v poskytnutí zdrojových kódů uvedených v odstavci 3 tohoto článku Objednateli, přičemž Objednatel má poté právo upravovat a měnit výše uvedené zdrojové kódy a tím zasahovat, měnit, upravovat nebo rozšiřovat dodaný software. V případě úpravy nebo změny výše uvedených zdrojových kódů Objednatelem nebo osobou plnící svůj závazek pro Objednatele, nenese Zhotovitel žádnou odpovědnost za nežádoucí následky využití tohoto oprávnění Objednatele.
5. Vzhledem k celkové ceně za plnění se licence za užití administrátorské a uživatelské provozní dokumentace a jiných (ostatních) písemných výstupů dle tohoto článku sjednávají jako bezúplatné. Cena licencí k softwaru (SW), případně grafickým dílům je uvedena v příloze č. 5 této smlouvy.
6. Xxxxxxxxxx je povinen uspořádat si své právní vztahy se třetími osobami tak, aby plně dostál svým závazkům dle této smlouvy. Neexistují vůči Objednateli žádné jiné nároky Zhotovitele na peněžité protiplnění, než ty, které jsou výslovně uvedené v této smlouvě.
7. V případě, že některá z licencí nezbytných pro řádnou funkčnost a provoz díla nebyla Zhotovitelem uvedena v jeho nabídce v zadávacím řízení, které předcházelo a týkalo se uzavření této smlouvy, nebo není výslovně uvedena v této smlouvě (resp. v její příloze č. 5), pak platí, že Zhotovitel je povinen dodat Objednateli bez jakýchkoliv finančních nároků všechny potřebné licence tak, aby množstevně, časově a územně zajistily legální a řádnou funkčnost a provoz díla.
8. Xxxxxxxxxx souhlasí s tím, že licence poskytnuté v souladu s touto smlouvou a jejími přílohami bude užívat nejen Objednatel, ale rovněž jeho příslušné jednotlivé příspěvkové organizace, a to v rozsahu a dle podmínek uvedených v této smlouvě, jakož i v její příloze č. 1, č. 4 a č. 5.
Článek V. Předání a převzetí plnění
1. Dílo bude prováděno a předáváno po částech, a to na základě písemných akceptačních protokolů a závěrečného protokolu o předání a převzetí díla. V průběhu realizace díla smluvní strany akceptačními protokoly a závěrečným protokolem o předání a převzetí díla schvalují, že byla provedena určitá dodávka nebo služba. Jednotlivé protokoly musí vždy obsahovat konkrétní vymezení poskytnutých dodávek a služeb. Za Objednatele a Zhotovitele jsou akceptační protokoly a závěrečný protokol o předání a převzetí díla, jakož i níže uvedené případné protokoly o odstranění vad a nedodělků oprávněni podepsat jejich zástupci ve věcech technických. Na straně Objednatele bude příslušné akceptační protokoly, jakož i protokol o předání a převzetí díla, případně protokoly o odstranění vad a nedodělků, podepisovat i technický dozor. Jeho účast na akceptačním a přejímacím řízení zajistí Objednatel. Na základě oboustranně podepsaného protokolu o předání a převzetí díla dochází k přechodu vlastnictví ke všem jednotlivým příslušným částem díla i díla jako celku na Objednatele. K přechodu nebezpečí škody k příslušným částem díla i díla jako celku na Objednatele dochází na základě oboustranně podepsaného protokolu o předání a převzetí díla.
2. O tom, že v rámci fáze 1 byla příslušná část díla týkající se implementační analýzy (včetně veškerých dodávek a služeb vztahujících se k této části díla-plnění uvedených v článku II. této smlouvy, potažmo v příloze č. 1 této smlouvy) dokončena a předána Xxxxxxxxxxxx Objednateli sepíší smluvní strany příslušný akceptační protokol č. 1. Zhotovitel dodá nejpozději 10 pracovních dnů před uplynutím Milníku 1 Objednateli finální verzi Implementační analýzy vč. vizuálního návrhu a Objednatel se k ní vyjádří a podá případné písemné připomínky do 5 pracovních dnů od dodání finální verze Implementační analýzy vč. vizuálního návrhu. Implementační analýzu vč. vizuálního návrhu se zapracovanými připomínkami Objednatele Zhotovitel předá Objednateli do 5 pracovních dnů. Akceptační protokol č. 1, podepsaný oběma smluvními stranami, tak bude potvrzením toho, že tato část plnění byla provedena a předána Objednateli. Objednatel není povinen akceptovat plnění týkající se fáze 1 (tj. převzít Implementační dokumentaci), pokud vady či nedodělky brání převzetí či užití této části plnění nebo způsobilosti sloužit svému účelu, o čemž bude sepsán písemný zápis (protokol), který smluvní strany podepíší a uvedou v něm svá stanoviska. Zhotovitel je povinen odstranit vady a nedodělky plnění týkající se fáze 1 (ať už bránící nebo nebránící převzetí či užití této části plnění nebo způsobilosti sloužit svému účelu) v náhradní lhůtě 5 pracovních dnů, což však nemá vliv na plnění ostatních smluvních povinností Zhotovitele. O odstranění všech vad a nedodělků části plnění týkající se fáze 1 bude následně sepsán protokol o odstranění vad a nedodělků. Právo Objednatele na smluvní pokutu v případě řádného a včasného neprovedení části plnění týkající se fáze 1 není stanovením náhradní lhůty pro odstranění vad a nedodělků (ať už bránících či nebránících převzetí či užití části plnění týkající se fáze 1 nebo způsobilosti sloužit svému účelu) dotčeno, s výjimkou případu uvedeného v čl. VIII. odst. 1 větě druhé.
3. O tom, že v rámci fáze 2 byla příslušná část díla týkající se vývoje a implementace do testovacího prostředí (včetně veškerých dodávek a služeb vztahujících se k této části díla-plnění uvedených v článku II. této smlouvy, potažmo v příloze č. 1 této smlouvy) dokončena a předána Xxxxxxxxxxxx Objednateli, sepíší smluvní strany akceptační protokol č. 2. Zhotovitel je povinen navrhnout (a to nejpozději 14 pracovních dnů před uplynutím Milníku 2) Objednateli datum zahájení akceptačního řízení. Akceptační řízení bude trvat zpravidla 14 pracovních dní, ve kterých bude Objednatel oprávněn zkontrolovat příslušné předávané plnění – část díla, a bude završeno akceptací na základě akceptačního protokolu č. 2. Objednatel není povinen akceptovat příslušné předávané plnění - část díla, pokud vady či nedodělky brání jeho převzetí či užití této části plnění nebo způsobilosti sloužit svému účelu, o čemž bude sepsán písemný zápis (protokol), který smluvní strany podepíší a uvedou v něm svá stanoviska. Zhotovitel je povinen odstranit vady a nedodělky plnění týkající se této části plnění/díla (ať už bránící nebo nebránící převzetí či užití této části plnění/díla nebo způsobilosti sloužit svému účelu) v náhradní lhůtě 5 pracovních dnů, což však nemá vliv na plnění ostatních smluvních povinností Zhotovitele. O odstranění všech vad a nedodělků části plnění/díla předávané v rámci akceptačního protokolu č. 2 bude následně sepsán protokol o odstranění vad a nedodělků. Právo Objednatele na smluvní pokutu v případě řádného a včasného neprovedení části plnění/díla předávané v rámci akceptačního protokolu č. 2 není stanovením náhradní lhůty pro odstranění vad a nedodělků (ať už bránících či nebránících převzetí či užití předmětné části plnění/díla nebo způsobilosti sloužit svému účelu) dotčeno, s výjimkou případu uvedeného v čl. VIII. odst. 1 větě druhé.
4. O tom, že v rámci fáze 3 byla příslušná část díla týkající se testovacího provozu a realizace testů (včetně veškerých dodávek a služeb vztahujících se k této části díla-plnění uvedených v článku II. této smlouvy, potažmo v příloze č. 1 této smlouvy) dokončena a předána Xxxxxxxxxxxx Objednateli, sepíší smluvní strany akceptační protokol č. 3. Zhotovitel je povinen navrhnout (a to nejpozději 7 pracovních dnů před uplynutím Milníku 3) Objednateli datum zahájení akceptačního řízení. Akceptační řízení bude trvat zpravidla 5 pracovních dní, ve kterých bude Objednatel oprávněn zkontrolovat příslušné předávané plnění – část díla, a bude završeno akceptací na základě akceptačního protokolu č. 3. Objednatel není povinen akceptovat příslušné předávané plnění-část díla, pokud vady či nedodělky brání jeho převzetí či užití této části plnění nebo způsobilosti sloužit svému účelu, o čemž bude sepsán písemný zápis (protokol), který smluvní strany podepíší a uvedou v něm svá stanoviska. Zhotovitel je povinen odstranit vady a nedodělky plnění týkající se této části plnění/díla (ať už bránící nebo nebránící převzetí či užití této části plnění/díla nebo způsobilosti sloužit svému účelu) v náhradní lhůtě 5 pracovních dnů, což však nemá vliv na plnění ostatních smluvních povinností Zhotovitele. O odstranění všech vad a nedodělků části plnění/díla předávané v rámci akceptačního protokolu č. 3 bude následně sepsán protokol o odstranění vad a nedodělků. Právo Objednatele na smluvní pokutu v případě řádného a včasného neprovedení části plnění/díla předávané v rámci akceptačního protokolu č. 3 není stanovením náhradní lhůty pro odstranění vad a nedodělků (ať už bránících či nebránících převzetí či užití příslušné části plnění/díla nebo způsobilosti sloužit svému účelu) dotčeno, s výjimkou případu uvedeného v čl. VIII. odst. 1 větě druhé.
5. O tom, že v rámci fáze 4 byla příslušná část díla týkající se pilotního provozu a realizace testů (včetně veškerých dodávek a služeb vztahujících se k této části díla-plnění uvedených v článku II. této smlouvy, potažmo v příloze č. 1 této smlouvy) dokončena a předána Xxxxxxxxxxxx Objednateli, a dále o tom, že dílo jako celek bylo zhotoveno (dokončeno) a předáno Xxxxxxxxxxxx Objednateli sepíší smluvní strany protokol o předání a převzetí díla. Objednatel výzvou učiněnou nejpozději 7 pracovních dnů před uplynutím Milníku 4 vyzve Xxxxxxxxxxx k předání díla, a současně mu navrhne datum zahájení přejímacího řízení, na
základě, kterého dojde k převzetí díla. Přejímací řízení trvá zpravidla 5 pracovních dní, ve kterých bude Objednatel oprávněn zkontrolovat příslušné předávané plnění – část díla i dílo jako celek, a bude završeno akceptací na základě protokolu o předání a převzetí díla.
6. Pokud nebudou při přejímacím řízení zjištěny vady ani nedodělky které by bránily převzetí či užití celého díla nebo způsobilosti sloužit svému účelu, je Objednatel povinen takto řádně provedené dílo jako celek převzít, a to na základě písemného protokolu o předání a převzetí díla, podepsaného oběma smluvními stranami. Nedílnou součástí protokolu o předání a převzetí díla je soupis případných vad a nedodělků nebránících převzetí či užití díla nebo způsobilosti sloužit svému účelu, které je povinen Zhotovitel odstranit v režimu (lhůtě) podmínek zajištění podpory provozu díla (dle přílohy č. 2 této smlouvy). V případě, že Objednatel odmítne předávané dílo z důvodu jeho neúplnosti či vad, které brání převzetí či užití díla nebo způsobilosti sloužit svému účelu, převzít, je Xxxxxxxxxx povinen tyto nedodělky či vady odstranit v režimu (lhůtě) podmínek zajištění podpory provozu díla (dle přílohy č. 2 této smlouvy). O nepřevzetí díla ze shora uvedených důvodů se pořídí písemný zápis (protokol), který smluvní strany podepíší a uvedou v něm svá stanoviska. O odstranění vad a nedodělků (ať už bránících či nebránících převzetí či užití díla nebo způsobilosti díla sloužit svému účelu) pořídí smluvní strany písemný zápis (protokol o odstranění vad a nedodělků celého díla), který smluvní strany podepíší. Právo Objednatele na smluvní pokutu v případě řádného a včasného neprovedení díla není stanovením lhůty pro odstranění vad a nedodělků (ať už bránících či nebránících převzetí či užití díla nebo způsobilosti díla sloužit svému účelu) v režimu podmínek zajištění podpory provozu díla dotčeno, s výjimkou případu uvedeného v čl. VIII. odst. 2 větě druhé.
7. Jestliže je protokol o předání a převzetí díla řádně podepsán smluvními stranami, považují se veškeré údaje o opatřeních a lhůtách v protokole uvedené za dohodnuté, pokud některá ze smluvních stran výslovně v protokole neuvede, že s určitými body protokolu nesouhlasí. Jestliže Objednatel v protokole popsal vady, nebo uvedl, jak se vady projevují, berou smluvní strany na vědomí, že tím současně požaduje bezúplatné odstranění takových vad, není-li uvedeno jinak.
8. Odmítne-li Objednatel dokončené dílo převzít nebo nedojde-li k dohodě o předání a převzetí díla, sepíší o tom strany zápis, v němž uvedou svá stanoviska. Zhotovitel není v prodlení, jestliže Objednatel odmítl bezdůvodně převzít dokončené dílo, které netrpí vadami a nedodělky bránícími převzetí či užití díla nebo způsobilosti sloužit svému účelu.
9. Místem akceptačních řízení i přejímacího řízení je sídlo Objednatele.
10. Nedohodnou-li smluvní strany jinak, vyhotoví akceptační protokoly a protokol o předání a převzetí díla zhotovitel, případně protokol o odstranění vad a nedodělků Zhotovitel.
11. Pokud se týká zajišťování provozu díla a podpory jeho provozu (fáze 5 plnění), o tomto plnění se akceptační protokoly nevyhotovují.
Článek VI.
Cena a platební podmínky
1. Celková cena za plnění (tj. součet ceny za dílo viz odst. 2 tohoto článku a ceny za zajištění podpory díla viz odst. 5 tohoto článku) dle této smlouvy činí:
celková cena bez DPH 7.144.111,- Kč DPH 21 % 1.500.263,31 Kč
celková cena včetně DPH 8.644.374,31 Kč
(slovy osmmilionůšestsetčtyřicetčtyřitisíctřistasedmdesátčtyři korun českých třicetjedna haléřů).
2. Z celkové ceny za plnění uvedené v odstavci 1. tohoto článku činí cena za dílo: cena bez DPH 5.344.111,- Kč
DPH 21 % 1.122.263,31 Kč
cena včetně DPH 6.466.374,31 Kč
(slovy šestmilionůčtyřistašedesátšesttisíctřistasedmdesátčtyři korun českých třicetjedna haléřů).
3. Cena za dílo bez DPH dle předchozího odstavce 2 tohoto článku je stanovena jako pevná a nejvýše přípustná (není-li v ní uvedeno výslovně jinak) a zahrnuje veškeré náklady Zhotovitele nezbytné k provedení díla dle této smlouvy (tj. především zpracování Implementační analýzy, vývoj a implementace do testovacího prostředí, testovací i pilotní provoz a realizace testů, poskytnutí licencí a příslušné dokumentace díla, školení obsluhy Objednatele (uživatelů a administrátorů) s dodaným dílem atd.). Ceny všech poskytovaných licencí, které jsou součástí ceny za dílo, a jejich specifikace vztahujících se k provozu
díla jsou podrobně uvedeny v příloze č. 5 této smlouvy. Xxxx za dílo je hrazena z dotace na Projekt a z vlastních prostředků Objednatele.
4. Objednatel neposkytuje zálohy. Xxxx za dílo bude Objednatelem uhrazena jedinou platbou na základě daňového dokladu-faktury vystavené Zhotovitelem. Zhotovitel je oprávněn vystavit fakturu až po řádném provedení díla, tj. bez veškerých vad a nedodělků, a to na základě oboustranně podepsaného protokolu o předání a převzetí díla, ze kterého bude zjevné, že dílo je předáváno a převzato bez veškerých vad a nedodělků (tj. bez výhrad), případně na základě oboustranně podepsaného protokolu o odstranění vad a nedodělků celého díla.
5. Z celkové ceny za plnění uvedené v odstavci 1. tohoto článku činí cena za zajištění podpory provozu díla (po celou dobu fáze 5):
cena bez DPH 1.800.000,- Kč
DPH 21 % 378.000,- Kč
cena včetně DPH 2.178.000,- Kč
(slovy dvamilionyjednostosedmdesátosmtisíc korun českých).
6. Cena za zajištění podpory provozu díla bez DPH dle předchozího odstavce 5 tohoto článku je stanovena jako pevná a nejvýše přípustná a zahrnuje veškeré náklady Zhotovitele nezbytné k splnění jeho povinnosti zajistit podporu díla dle této smlouvy, není-li v příloze č. 2 této smlouvy uvedeno jinak.
7. Zhotovitel fakturuje za zajištění podpory provozu díla za každých 6 měsíců, ve kterých je služba poskytována. Za datum uskutečnění zdanitelného plnění je považován poslední den každého 6. měsíce poskytnuté podpory, počítáno od dne předání a převzetí řádně dokončeného díla na základě protokolu o předání a převzetí díla. (Příklad: bude-li dílo předáno 30. 9. 2025, bude datum uskutečnění zdanitelného plnění první faktury 31. 3. 2026, druhé faktury 30. 9. 2026, třetí faktury 31. 3. 2027 atd.) Každá z faktur bude znít na částku odpovídající jedné dvanáctině ceny dle odstavce 5. tohoto článku. Cena za zajištění podpory díla není Objednatelem hrazena z dotace na Projekt, ale z jiných zdrojů Objednatele.
8. Každá faktura musí splňovat předepsané náležitosti účetního dokladu ve smyslu § 11 zákona č. 563/1991 Sb., o účetnictví, ve znění pozdějších předpisů, s výjimkou odst. 1 písm. f), nebo předepsané náležitosti daňového dokladu ve smyslu § 29 až § 30 zákona č. 235/2004 Sb., o dani z přidané hodnoty, ve znění pozdějších předpisů. Na každé faktuře za provedení díla (tj. s výjimkou faktur vystavených za zajištění podpory díla dle odst. 5 tohoto článku) musí být uvedeno registrační číslo Projektu
„CZ.06.01.01/00/22_008/0000473“ a jednotlivé položky, za něž je fakturováno.
V případě, že je Zhotovitel plátcem DPH, pak součástí každé faktury musí být prohlášení Zhotovitele o tom, že:
- nemá v úmyslu nezaplatit daň z přidané hodnoty u zdanitelného plnění podle této faktury (dále jen
„daň“),
- mu nejsou známy skutečnosti, nasvědčující tomu, že se dostane do postavení, kdy nemůže daň zaplatit a ani se ke dni vystavení této faktury v takovém postavení nenachází,
- nezkrátí daň nebo nevyláká daňovou výhodu
- úplata za plnění dle této faktury není odchylná od obvyklé ceny,
- úplata za plnění dle této faktury nebude poskytnuta zcela nebo zčásti bezhotovostním převodem na účet vedený poskytovatelem platebních služeb mimo tuzemsko,
- nebude nespolehlivým plátcem,
- bude mít u správce daně registrován bankovní účet používaný pro ekonomickou činnost,
- souhlasí s tím, že pokud ke dni uskutečnění zdanitelného plnění nebo k okamžiku poskytnutí úplaty na plnění bude o Zhotoviteli zveřejněna správcem daně skutečnost, že Zhotovitel je nespolehlivým plátcem, uhradí Objednatel daň z přidané hodnoty z přijatého zdanitelného plnění příslušnému správci daně,
- souhlasí s tím, že pokud ke dni uskutečnění zdanitelného plnění nebo k okamžiku poskytnutí úplaty na plnění bude zjištěna nesrovnalost v registraci bankovního účtu Zhotovitele určeného pro ekonomickou činnost správcem daně, uhradí Objednatel daň z přidané hodnoty z přijatého zdanitelného plnění příslušnému správci daně.
9. Splatnost faktur je 30 dnů od data jejich doručení Objednateli. Faktura se považuje za uhrazenou okamžikem odepsání fakturované částky z účtu Objednatele ve prospěch účtu Zhotovitele. Platba bude Objednatelem provedena bankovním převodem na účet Zhotovitele uvedený na str. 1 této smlouvy. Faktura, která neobsahuje veškeré náležitosti dle této smlouvy (včetně příloh) bude Objednatelem vrácena Zhotoviteli s výzvou k opravě nebo doplnění. Od doručení opravené faktury Objednateli běží nová 30 denní lhůta splatnosti. Objednatel je oprávněn pozastavit platbu faktury za zajištění podpory provozu díla účtovanou dle odstavce 7 tohoto článku, a to v případě, že Zhotovitel bude v prodlení s odstraněním
Požadavku v kategorii „Kritická“ nebo „Standardní“, tj. překročí max. dobu určenou pro vyřešení příslušných Požadavků od zadání, a to v kategorii „Kritická“ nebo „Standardní“. V době pozastavení platby za fakturu za zajištění podpory provozu díla neběží (staví se) lhůta splatnosti příslušné faktury a pokračuje v běhu až po odstranění předmětného Požadavku. Pozastavení faktury dle tohoto odstavce nemá vliv na případné uplatnění práva Objednatele na zaplacení příslušných smluvních pokut.
10. Cenu za plnění lze překročit v případě změny zákonné sazby daně z přidané hodnoty (dále jen „DPH“) v průběhu plnění. V případě změny sazby DPH v průběhu plnění není nutné uzavírat dodatek ke smlouvě, pouze se k příslušnému základu daně uvedenému v této smlouvě přičte sazba DPH účinná v době vzniku zdanitelného plnění.
Článek VII.
Záruka a odpovědnost za vady, podpora provozu díla
1. Zhotovitel poskytuje Objednateli záruku na vlastnosti a funkčnost díla (na to, že dílo bude mít v jednotlivých částech i jako celek smluvené parametry a bude řádně fungovat). Záruční doba na jednotlivé části díla, i dílo jako celek trvá a bude poskytována po dobu 72 měsíců, tj. po celou dobu fáze 5 – podpora díla. Běh záruční doby počíná dnem následujícím po dni protokolárního předání a převzetí (celého) díla.
2. Odstraňování záručních vad a nedodělků se řídí touto smlouvou a Podmínkami zajištění podpory provozu díla (příloha č. 2 této smlouvy). Pokud nároky z odpovědnosti za vady díla nelze z jejich povahy řešit v rámci zajištění podpory díla (příloha č. 2 této smlouvy), budou smluvními stranami řešeny v souladu s příslušnými ustanoveními občanského zákoníku.
3. Náklady na provedení a/nebo zajištění veškerých úkonů vyplývajících z poskytnuté záruky a zajištění podpory provozu díla dle přílohy č. 2 této smlouvy (zejména náklady na dopravu, opravu, náklady na update, upgrade, úpravy konfigurace a další činnosti uvedené zejména v kapitole III. přílohy č. 2 této smlouvy) jsou uhrazeny v souladu s článkem VI. (zejména jeho odstavci 5 a 7) této smlouvy a Zhotovitel tak není oprávněn účtovat Objednateli žádné další platby z tohoto titulu, nevyplývá-li ze smlouvy jinak.
4. Zhotovitel je povinen provést nápravu vady dle výše uvedeného i v případě, kdy reklamaci neuznává, přičemž nese související náklady až do doby, než se prokáže, zdali byla vada reklamována oprávněně. Prokáže-li se ve sporných případech, že Objednatel vadu reklamoval neoprávněně, tzn., že Zhotovitel za vadu neodpovídá či se na ni nevztahuje poskytnutá záruka či podpora provozu díla, je Objednatel povinen uhradit Zhotoviteli veškeré Zhotovitelem účelně vynaložené a doložené náklady vzniklé v souvislosti s odstraněním neoprávněně reklamované vady.
5. Zhotovitel prohlašuje, že má sjednáno smluvní pojištění odpovědnosti za škody způsobené při výkonu své podnikatelské činnosti týkající se předmětu plnění dle této smlouvy u Generali Česká pojišťovna a. s., s limitem pojistného plnění 50.000.000,- Kč (minimálně však 3.000.000,- Kč). Kopie pojistné smlouvy bude předána Objednateli na jeho vyžádání. Zhotovitel se zavazuje po celou dobu plnění předmětu této smlouvy mít platnou a účinnou pojistnou smlouvu nejméně s minimálním limitem pojistného plnění uvedeného v závorce věty první tohoto odstavce.
Článek VIII. Sankce a náhrada škody
1. Nesplní-li Zhotovitel svůj závazek řádně dokončit a předat příslušnou část plnění/díla završenou vyhotovením a podpisem příslušného akceptačního protokolu prováděnou v rámci v rámci fáze 1 nebo v rámci fáze 2 nebo v rámci fáze 3 ve sjednaném rozsahu a čase plnění, je Objednatel oprávněn požadovat po Zhotoviteli zaplacení smluvní pokutu ve výši 1.500,- Kč za každý započatý kalendářní den prodlení s řádným dokončením a předáním příslušné části plnění/díla, přičemž Zhotovitel je povinen v případě uplatnění tohoto práva Objednatelem mu takovou smluvní pokutu zaplatit. V případě, že příslušná část plnění/díla prováděná v rámci fáze 1 nebo v rámci fáze 2 nebo v rámci fáze 3 a završená vyhotovením a podpisem příslušného akceptačního protokolu nebude provedena (dokončena a předána) ve sjednaném rozsahu a čase plnění pouze s ohledem na setrvávající drobné vady a nedodělky (tj. vady a nedodělky nebránící převzetí nebo užití příslušné části plnění/díla nebo způsobilosti sloužit svému účelu), které posléze Zhotovitel odstraní v náhradní lhůtě 5 kalendářních dnů, není povinen Zhotovitel zaplatit Objednateli smluvní pokutu uvedenou ve větě první tohoto odstavce. V případě, že však takové drobné vady a nedodělky Zhotovitel neodstraní v náhradní lhůtě, je povinen zaplatit Objednateli smluvní pokutu v původní výši, tj. počítáno ode dne, kdy měl dle této smlouvy příslušnou část plnění/díla prováděnou v rámci fáze 1 nebo v rámci fáze 2 nebo v rámci fáze 3 řádně a včas dokončit a předat Objednateli.
2. Nesplní-li Zhotovitel svůj závazek řádně dokončit a předat dílo jako celek ve sjednaném rozsahu a čase plnění (v rámci fáze 4), je Objednatel oprávněn požadovat po Zhotoviteli zaplacení smluvní pokutu ve výši 0,2 % z ceny díla včetně DPH (uvedené v odst. 2 čl. VI. této smlouvy) za každý započatý kalendářní den prodlení s řádným dokončením díla, přičemž Xxxxxxxxxx je povinen v případě uplatnění tohoto práva Objednatelem mu takovou smluvní pokutu zaplatit. V případě, že dílo nebude provedeno (dokončeno a předáno) ve sjednaném rozsahu a čase plnění pouze s ohledem na setrvávající drobné vady a nedodělky (tj. vady a nedodělky nebránící převzetí nebo užití díla nebo způsobilosti díla sloužit svému účelu), které posléze Xxxxxxxxxx odstraní ve lhůtě dle režimu podmínek zajištění podpory provozu díla, není povinen Zhotovitel zaplatit Objednateli smluvní pokutu uvedenou ve větě první tohoto odstavce. V případě, že však takové drobné vady a nedodělky Zhotovitel neodstraní ve lhůtě dle režimu podmínek zajištění podpory provozu díla, je povinen zaplatit Objednateli smluvní pokutu v původní výši, tj. počítáno ode dne, kdy měl dle této smlouvy dílo řádně a včas dokončit a předat Objednateli.
3. Objednatel je oprávněn po Zhotoviteli požadovat a Zhotovitel je povinen v případě uplatnění tohoto práva zaplatit Objednateli smluvní pokutu ve výši 200,- Kč za každou započatou pracovní hodinu prodlení s potvrzením přijetí Požadavku do systému HelpDesk (viz článek III. odst. 6 přílohy č. 2 této smlouvy).
4. Objednatel je oprávněn po Zhotoviteli požadovat a Zhotovitel je povinen v případě uplatnění tohoto práva zaplatit Objednateli smluvní pokutu ve výši 3.000,- Kč za každý započatý pracovní den (BD ve smyslu přílohy č. 2 této smlouvy) prodlení s odstraněním vady či nedodělku, resp. prodlení s vyřešením Požadavku od zadání (platí pro odstraňování vad, resp. vyřešení Požadavků v kategorii „Standardní“ a „Nízká“, v rámci fáze 5). Objednatel je oprávněn po Zhotoviteli požadovat a Zhotovitel je povinen v případě uplatnění tohoto práva zaplatit Objednateli smluvní pokutu ve výši 800,- Kč za každou započatou pracovní hodinu prodlení s odstraněním vady či nedodělku, resp. prodlení s vyřešením Požadavku od zadání (platí pro odstraňování vad, resp. vyřešení Požadavků v kategorii „Kritická“, v rámci fáze 5).
5. Objednatel je oprávněn po Zhotoviteli požadovat a Zhotovitel je povinen v případě uplatnění tohoto práva zaplatit Objednateli smluvní pokutu ve výši 2.000,- Kč za každý započatý kalendářní den, kdy podpora díla nebyla zajištěna v souladu s parametry stanovenými touto smlouvou a zároveň toto nesplnění povinnosti Zhotovitele není sankcionováno smluvními pokutami uvedenými v odstavci 3 nebo 4 tohoto článku.
6. Pokud Zhotovitel poruší své povinnosti dle článku XII. odst. 4. této smlouvy, je Objednatel oprávněn po Zhotoviteli požadovat a Zhotovitel je povinen v případě uplatnění tohoto práva zaplatit Objednateli smluvní pokutu ve výši 10.000,- Kč za každý dotčený subjekt údajů.
7. Pokud jedna smluvní strana poruší své povinnosti dle článku XII. odst. 2. nebo odst. 3 této smlouvy, je druhá smluvní strana oprávněna po první smluvní straně požadovat a první smluvní strana je povinna v případě uplatnění tohoto práva zaplatit druhé smluvní straně smluvní pokutu ve výši 20.000,- Kč za každý zjištěný případ úniku důvěrných informací.
8. Pokud Zhotovitel nebo jeho zaměstnanci, případně jeho poddodavatelé, poruší bezpečnostní pravidla informačního systému Objednatele, na než je odkazováno v článku 14 přílohy č. 3 této smlouvy, je Objednatel oprávněn po Zhotoviteli požadovat a Zhotovitel je povinen v případě uplatnění tohoto práva povinen zaplatit Objednateli smluvní pokutu ve výši 20.000,- Kč za každý zjištěný případ jejich porušení.
9. V případě, že Xxxxxxxxxx poruší své povinnosti uvedené v odst. 5. článku VII. této smlouvy, je povinen zaplatit Objednateli smluvní pokutu ve výši 1.500,- Kč, a to za každý započatý den porušení povinnosti Zhotovitele.
10. V případě, že Zhotovitel poruší povinnost informovat o všech skutečných majitelích Zhotovitele a poddodavatelů a jejich změnách dle článku XIV. odst. 4 této smlouvy, je Objednatel oprávněn po Zhotoviteli požadovat a Zhotovitel je povinen v případě uplatnění tohoto práva povinen zaplatit Objednateli smluvní pokutu ve výši 10.000,- Kč za každý jednotlivý zjištěný případ.
11. V případě, že Xxxxxxxxxx poruší své povinnosti uvedené v odst. X. odst. 4 této smlouvy, tzn. v případě, že bude dílo provádět prostřednictvím člena projektového týmu Zhotovitele, který nesplňuje příslušné kvalifikační požadavky na člena projektového týmu nebo který není předem písemně odsouhlasen Objednatelem, je Objednatel oprávněn po Zhotoviteli požadovat a Zhotovitel je povinen v případě uplatnění tohoto práva povinen zaplatit Objednateli smluvní pokutu ve výši 30.000,- Kč, a to za každý jednotlivý zjištěný případ porušení.
12. Pokud dojde ke splnění podmínky uvedené pod příslušným písmenem odst. 4 článku IV. této smlouvy a Zhotovitel neposkytne Objednateli zdrojové kódy uvedené v odst. 3 článku IV. této smlouvy, je Objednatel oprávněn po Zhotoviteli požadovat a Zhotovitel je povinen v případě uplatnění tohoto práva zaplatit Objednateli smluvní pokutu ve výši 10 % z ceny díla bez DPH (uvedené v odst. 2 čl. VI. této smlouvy).
13. V případě nedodržení termínu splatnosti řádně vystavené faktury, je Zhotovitel oprávněn účtovat Objednateli úrok z prodlení ve výši dle obecné úpravy práva občanského (dle nařízení vlády č. 351/2013 Sb., kterým se určuje výše úroků z prodlení a nákladů spojených s uplatněním pohledávky, určuje odměna
likvidátora, likvidačního správce a člena orgánu právnické osoby jmenovaného soudem a upravují některé otázky Obchodního věstníku, veřejných rejstříků právnických a fyzických osob a evidence svěřeneckých fondů a evidence údajů o skutečných majitelích, ve znění pozdějších předpisů).
14. Smluvní pokuty a úroky z prodlení podle tohoto článku jsou splatné do 30 dnů ode dne doručení jejich vyúčtování druhé smluvní straně.
15. Smluvní strany nesou odpovědnost za způsobenou škodu v rámci platných právních předpisů a této smlouvy. Smluvní strany se zavazují k vyvinutí maximálního úsilí k předcházení škodám a k minimalizaci vzniklých škod.
16. Zhotovitel je odpovědný Objednateli za plnění povinností vyplývajících z této smlouvy a za škodu způsobenou mu v souvislosti s plněním předmětu této smlouvy, a to i tehdy, byla-li škoda v této souvislosti způsobena zástupcem či pracovníkem Zhotovitele nebo jeho poddodavatelem. Za škodu způsobenou Zhotovitelem Objednateli dle této smlouvy se považuji mimo jiné zkrácení výše finančních prostředků podpory Objednateli na Projekt či finanční sankce uplatněné vůči Objednateli poskytovatelem dotace, subjekty implementační struktury IROP nebo orgány veřejné správy, a to za podmínky, že tato škoda vznikla v příčinné souvislosti s jednáním, nejednáním či opomenutím Zhotovitele při plnění předmětu této smlouvy, např. nedodržením termínu plnění díla jako celku bez vad a nedodělků z viny na straně Zhotovitele (či jeho poddodavatelů). V případě vzniku škody definované v tomto odstavci se zavazuje její výši Zhotovitel Objednateli uhradit, pakliže Objednatel vůči Zhotoviteli právo na náhradu škody uplatní. Zaplacením jakékoliv smluvní pokuty uvedené v této smlouvě není dotčeno právo Objednatele vůči Zhotoviteli na náhradu způsobené škody (či její výši), která vznikla v příčinné souvislosti s jednáním, nejednáním či opomenutím Zhotovitele při plnění předmětu této smlouvy.
17. Pohledávky Objednatele na zaplacení smluvní pokuty nebo náhrady škody je možno započíst na splatné i nesplatné pohledávky Zhotovitele za Objednatelem. Objednatel je oprávněn jednostranně započítat svou pohledávku plynoucí z této smlouvy (např. Zhotovitelem nezaplacenou příslušnou smluvní pokutu) za Zhotovitelem vůči pohledávce Xxxxxxxxxxx plynoucí z této smlouvy za Objednatelem (např. Objednatelem nezaplacenou cenu příslušné již poskytnuté podpory provozu díla). Objednatel je rovněž oprávněn zaplatit cenu příslušné již poskytnuté podpory provozu díla sníženou o částku, která by se rovnala smluvní pokutě, kterou by byl oprávněn Objednatel požadovat zaplatit po Zhotoviteli za porušení smluvní povinnosti Zhotovitele dle této smlouvy.
Článek IX. Ukončení smlouvy
1. Smluvní strany se dohodly, že tato smlouva zaniká písemnou dohodou obou stran, písemným odstoupením smluvní strany od smlouvy nebo výpovědí v souladu s tímto článkem.
2. Případná práva a povinnosti smluvních stran z odstoupení od smlouvy budou řešena, není-li v této smlouvě výslovně uvedeno jinak, podle příslušných ustanovení občanského zákoníku. Od této smlouvy lze odstoupit v případě podstatného porušení povinností jednou smluvní stranou, jestliže je takové porušení povinnosti označeno za podstatné touto smlouvou nebo zákonem. Odstoupení od smlouvy je účinné dnem doručení písemného oznámení o odstoupení druhé smluvní straně, přičemž jednotlivé smluvní závazky plynoucí z této smlouvy se zrušují od počátku s výjimkou těch, které se dle občanského zákoníku nezrušují (např. právo na náhradu škody, právo na zaplacení smluvní pokuty nebo úroku z prodlení). Každá ze smluvních stran této smlouvy je oprávněna od této smlouvy nebo její příslušné části odstoupit v případě jejího podstatného porušení druhou smluvní stranou.
3. Za podstatné porušení smlouvy Xxxxxxxxxxxx se považuje zejména to, když:
• byly zjištěny nedostatky v provádění díla Xxxxxxxxxxxx nebo když Xxxxxxxxxx i přes písemnou výtku Objednatele provádí dílo způsobem, který vede nepochybně k vadnému plnění, přičemž tyto nedostatky nebo nedohodnutý postup či dosavadní vadný výsledek provádění díla, který Objednatel Zhotoviteli písemně vytkl, není Zhotovitelem odstraněn ani v dodatečné lhůtě poskytnuté mu Objednatelem,
• se prokáže, že Xxxxxxxxxx ve své nabídce v rámci zadávacího řízení, které předcházelo a týkalo se uzavření této smlouvy, uvedl nepravdivé údaje, pokud se týká funkčních a technických požadavků zadavatele (Objednatele),
• Zhotovitel je v prodlení s řádným dokončením jakékoliv z fází 1 nebo 2 nebo 3 nebo 4 o více než 30 dní
• Zhotovitel je v prodlení s řádným dokončením díla delším než 30 kalendářních dnů,
• Zhotovitel opakovaně provádí dílo prostřednictvím osob, které nesplňují (kvalifikační) požadavky uvedené v článku X. odst. 4 této smlouvy (pojmem „opakovaně“ se rozumí, že došlo k porušení tohoto požadavku min. ve dvou případech),
• Zhotovitel i přes písemnou výtku Objednatele zajišťuje podporu provozu díla v rozporu s parametry uvedenými v této smlouvě po dobu delší než dva týdny,
• byl podán insolvenční návrh na zahájení insolvenčního řízení ve věci Zhotovitele, nebo probíhá-li insolvenční řízení, v němž je řešen úpadek či hrozící úpadek Zhotovitele, to vše podle zákona č. 182/2006 Sb., o úpadku a způsobech jeho řešení, ve znění pozdějších předpisů
• Zhotovitel vstoupí do likvidace, nebo bylo-li rozhodnuto o zrušení Zhotovitele,
• Zhotovitel poruší jakoukoli z povinností uvedených v druhé větě odst. 2. čl. XIV. této smlouvy,.
4. Objednatel upozorňuje Zhotovitele, že plnění pouze části díla nemá pro Objednatele význam, proto odstoupí-li Objednatel od smlouvy zejména z důvodů uvedených v první nebo třetí odrážce odstavce 3 tohoto článku, může Objednatel odstoupit od smlouvy (celého jejího plnění) bez ohledu na to, že některé části díla byly již provedeny a Objednateli předány, přičemž v takovém případě jsou smluvní strany povinny si vrátit vzájemně poskytnutá plnění, nedohodnou-li se jinak.
5. Za podstatné porušení této smlouvy Objednatelem se považuje zejména to, jestliže je Objednatel i přes písemnou urgenci Zhotovitele v prodlení s úhradou řádně vystavené faktury trvající déle než patnáct dnů od této urgence nebo jestliže Objednatel opakovaně (nejméně 2x) neposkytnul součinnost uvedenou v této smlouvě, a to ani do 15 dnů od doručení písemného oznámení Zhotovitele o neposkytnutí součinnosti Objednatele nebo jestliže Objednatel neposkytnul podklady nebo informace Zhotoviteli, které je dle této smlouvy povinen Objednatel poskytnout, a to ani na základě opakované (nejméně 2x) písemné výzvy Zhotovitele.
6. Objednatel je oprávněn vypovědět tuto smlouvu v případě opakované (nejméně 2x) neomluvené neúčasti Zhotovitele na pracovních schůzkách. V tomto případě činí výpovědní doba 30 dní a plyne dnem následujícím po doručení výpovědi Zhotoviteli.
7. Objednatel je oprávněn vypovědět zajišťování podpory provozu díla, a to i bez udání důvodů. Výpovědní lhůta činí šest měsíců. Výpověď musí být písemná a běží od prvního dne měsíce následujícího po doručení výpovědi.
8. Objednatel je oprávněn vypovědět zajišťování podpory díla také v případě, že Xxxxxxxxxx nezajištuje podporu díla řádně a včas. Výpovědní lhůta činí jeden měsíc. Výpověď musí být písemná a běží od prvního dne měsíce následujícího po doručení výpovědi.
Článek X. Organizace a komunikace
1. Smluvní strany jsou povinny v průběhu plnění této smlouvy se neprodleně vzájemně informovat o všech skutečnostech, které mají nebo mohou mít vliv na plnění předmětu této smlouvy, přičemž se zavazují k vyvinutí maximálního úsilí k předcházení škodám a k minimalizaci vzniklých škod. V průběhu plnění smlouvy se smluvní strany v rámci pracovních schůzek setkávají v sídle Objednatele (nedohodnou-li se kontaktní osoby/zástupci jinak), aby konzultovali průběh plnění a rovněž, aby si vzájemně průběžně předávali a připomínkovali (kontrolovali) dílčí části prováděného díla v rámci příslušných fází. Podrobnosti organizace a komunikace dohodnou smluvní strany na svém prvním jednání. Jednání - pracovní schůzky (mohou probíhat i distanční formou) organizuje Zhotovitel, který připravuje podklady pro jednání, vyhotovuje zápisy z jednání (pracovních schůzek), prezenční listiny apod. Originál všech zápisů a listin vzešlých z jednání (pracovních schůzek) předává Objednateli. Xxxxxxxxxx bude při realizaci díla postupovat dle zásad projektového řízení. Ze všech jednání (pracovních schůzek) mezi smluvními stranami budou vyhotoveny zápisy. Zápisy vyhotovuje Xxxxxxxxxx již v průběhu jednání, po jednání (pracovní schůzce) je Objednatel připomínkuje a obě smluvní strany je odsouhlasí. Všechny dokumenty, které bude Zhotovitel zpracovávat, bude Objednateli předávat k připomínkování průběžně.
2. Kontaktní údaje smluvních stran Objednatel:
zástupci – kontaktní osoby ve věcech technických:
zástupci - kontaktní osoby ve věcech smluvních:
Zhotovitel:
zástupci - kontaktní osoby ve věcech technických:
zástupci - kontaktní osoby ve věcech smluvních:
Adresa do systému HelpDesk pro hlášení vad a reklamací je uvedena v příloze č. 2 této smlouvy.
V běžných záležitostech, a pokud není v této smlouvě uvedeno jinak, jsou dle charakteru záležitosti za smluvní strany oprávněni jednat jejich zástupci – kontaktní osoby ve věcech technických nebo smluvních. Za smluvní strany jsou oprávněny v záležitostech uplatňování smluvních pokut, úroků z prodlení a náhrad škod jednat a podepisovat jejich zástupci – kontaktní osoby ve věcech smluvních.
Pokud zástupci - kontaktní osoby ve věcech technických nedosáhnou shody ohledně řešení problému při plnění této smlouvy, postoupí se problém k řešení zástupcům - kontaktním osobám ve věcech smluvních. Pokud ani zástupci - kontaktní osoby ve věcech smluvních nedosáhnou shody ohledně řešení takového problému, postoupí se problém k řešení na úroveň vyššího managementu smluvních stran.
3. Pokud dojde ke změně názvu smluvní strany, adresy jejího sídla, bankovního spojení, statutárního orgánu, zástupce – kontaktní osoby či osoby oprávněné jednat ve věcech smluvních či technických a jejich telefonických čísel anebo e-mailových adres, jsou smluvní strany povinny změnu písemně oznámit druhé smluvní straně, a to předem nebo nejpozději bezodkladně poté, co ke změně dojde. Dostačující formou oznámení změny je zaslání e-mailu zástupci - kontaktní osobě druhé smluvní strany ve věcech smluvních, která je povinna obdržení e-mailu do 2 pracovních dnů potvrdit. V případě změny v kontaktních údajích uvedených v tomto odstavci není třeba uzavírat dodatek ke smlouvě.
4. Zhotovitel je povinen využívat pro plnění smlouvy po celou dobu zhotovování (provádění) díla projektový tým, který bude minimálně v počtu 6 osob (případně s výjimkou dále v tomto odst. 4 uvedenou) v níže uvedeném složení, které budou naplňovat minimálně tyto (kvalifikační) požadavky:
• min. 1 Projektový manažer, jenž bude zejména zajišťovat plánování, organizaci, řízení a kontrolu realizace zakázky (předmětu plnění této smlouvy) tak, aby bylo dosaženo stanovených projektových cílů, a to ve stanoveném termínu a v rámci stanoveného rozpočtu, přičemž tento musí splňovat následující min. požadavky:
Vzdělání: min. bakalářské, popř. min. vyšší odborné vzdělání
Praxe v oboru minimálně 5 let praxe v oboru ICT získaná v posledních 10 letech
Reference, zkušenosti: zkušenosti s řízením projektů spočívajících v dodávce a implementaci aplikačního SW řešení na pozici projektového manažera (vedoucího projektu, vedoucího realizačního týmu nebo na obdobné řídící funkci odpovědné za vedení projektu) při realizaci minimálně 2 (dvou) zakázek (projektů) představujících dodávky a implementaci aplikačního SW řešení, ve finančním objemu minimálně 2 mil. Kč bez DPH za každou z takových zakázek, a to získané v období posledních 10 letech.
Další požadavky: znalost českého jazyka pro potřeby odborné komunikace na pracovní úrovni
• min. 1 Business/Procesní analytik, jenž bude zejména zajišťovat procesní analýzu řešení v souladu se zadáním, přičemž tento musí splňovat následující min. požadavky:
Vzdělání: min. bakalářské, popř. min. vyšší odborné vzdělání
Praxe v oboru: minimálně 3 roky praxe v oboru ICT získaná v posledních 10 letech
Reference, zkušenosti: zkušenosti na pozici procesního analytika nebo business analytika při realizaci minimálně 2 (dvou) obdobných zakázek představujících dodávky a implementaci aplikačního SW řešení pro oblast dlouhodobého ukládání a archivaci dat (var. portálových řešení) ve finančním
objemu minimálně 2 mil. Kč bez DPH za každou z takových zakázek, a to získané v období posledních 10 letech.
Další požadavky: znalost českého jazyka pro potřeby odborné komunikace na pracovní úrovni
• min. 1 Programátor, jenž bude zejména zajišťovat projektování a programování, vývoj SW řešení a jeho částí, jak back-end tak front-end na úrovni programování, řešení mechanizmů přístupových oprávnění, ověřování identit, přičemž tento musí splňovat následující min. požadavky:
Vzdělání: minimálně středoškolské s maturitou.
Praxe v oboru: minimálně 5 let praxe v oboru ICT získaná v posledních 10 letech
Reference/zkušenosti: zkušenosti s tvorbou SW řešení, a to při realizaci minimálně 1 (jedné) zakázky ve finančním objemu minimálně 2 mil. Kč bez DPH a to získané v období posledních 10 letech
Další požadavky: znalost českého jazyka pro potřeby odborné komunikace na pracovní úrovni
• min. 1 Databázový specialista, jenž bude zejména zajišťovat návrh databázového modelu, správu databáze a jeho částí, přičemž tento musí splňovat následující min. požadavky:
Vzdělání: minimálně středoškolské s maturitou
Praxe v oboru: minimálně 5 let praxe v oboru ICT získaná v posledních 10 letech
Reference/zkušenosti: zkušenosti s tvorbou datových modelů, se správou databází, implementací SW řešení využívajících databáze pro ukládání dat, a to při realizaci minimálně 1 (jedné) zakázky ve finančním objemu minimálně 2 mil. Kč bez DPH, a to získané v období posledních 10 letech
Další požadavky: znalost českého jazyka pro potřeby odborné komunikace na pracovní úrovni
• min. 1 Síťový specialista/správa infrastruktury, jenž bude zejména zajišťovat implementaci a konfiguraci SW řešení v síťovém prostředí On-Premium i cloud, přičemž tento musí splňovat následující min. požadavky:
Vzdělání: minimálně středoškolské s maturitou
Praxe v oboru: minimálně 5 let praxe v oboru ICT získaná v 10 letech
Reference/zkušenosti: Zkušenosti s implementací SW řešení v síťové infrastruktuře, konfigurace infrastruktury pro provoz SW řešení, a to při realizaci minimálně 1 (jedné) zakázky ve finančním objemu minimálně 2 mil. Kč bez DPH, a to získané v období posledních 10 letech
Další požadavky: znalost českého jazyka pro potřeby odborné komunikace na pracovní úrovni
• min. 1 Lektor/Školitel, jenž bude zejména zajišťovat zaškolení uživatelů a správců, zaměstnanců Objednatele, přičemž tento musí splňovat následující min. požadavky:
Praxe v oboru: minimálně 3 roky praxe školitele v oboru/oblasti ICT získaná v posledních 5 letech
Reference/zkušenosti: zkušenosti na pozici lektora, zkušenosti se školeními v oblasti ICT, doložené min. 3 vzdělávacími akcemi, které lektor/školitel lektorsky vedl či školil v posledních 5 letech, přičemž každá z akcí musela trvat min. 16 hodin a týkat se oblasti/oboru ICT.
Další požadavky: znalost českého jazyka pro potřeby zaškolení uživatelů
Uvedené osoby projektového týmu musí splňovat požadavky, které na ně Objednatel stanovil v technické kvalifikaci v zadávacím řízení, které předcházelo a týkalo se uzavření této smlouvy, a které jsou zároveň shodně uvedené pod jednotlivými odrážkami výše v tomto odstavci. Role/funkce Programátor, Databázový specialista, Síťový specialista/správa infrastruktury a Lektora/školitele může být kumulována s některou z ostatních rolí/funkcí projektového týmu v rámci jedné osoby, v případě že příslušná osoba splňuje všechny kvalifikační požadavky uvedené výše pro jednotlivé kumulované role/funkce. V případě kumulace jednotlivých rolí/funkcí v rámci jedné osoby však musí mít projektový tým Zhotovitele min. 4 osoby. Změny (doplnění) člena projektového týmu je možné provést pouze po předchozí dohodě smluvních stran na základě písemného protokolu o těchto změnách podepsaného zástupci – kontaktními osobami ve věcech technických nebo smluvních. Pokud dochází ke změně (doplnění) člena projektového týmu, musí nový člen projektového týmu splňovat požadavky, které na něj Objednatel stanovil v technické kvalifikaci v zadávacím řízení, která předcházelo a týkalo se uzavření této smlouvy, a které jsou rovněž shodně uvedené pod jednotlivými odrážkami výše v tomto odstavci, přičemž tyto požadavky musejí být doloženy prostřednictvím dokladů, které byl Zhotovitel povinen předložit v předmětném zadávacím řízení. Provedení změny osoby Zhotovitelem bez splnění shora uvedených podmínek se považuje za podstatné porušení smlouvy, nejedná-li se o případ vyšší moci.
5. Nastanou-li u některé ze smluvních stran skutečnosti bránící řádnému plnění této smlouvy, je povinna to ihned bez zbytečného odkladu oznámit druhé straně.
6. Zhotovitel je povinen oznámit Objednateli všechny okolnosti, které zjistil při plnění předmětu této smlouvy, které mohou mít vliv na změnu pokynů Objednatele. Zjistí-Ii Zhotovitel, že pokyny Objednatele jsou nevhodné či neúčelné pro plnění předmětu této smlouvy, je povinen na to Objednatele neprodleně písemně upozornit. Zhotovitel je povinen chránit zájmy Objednatele, zejména je povinen upozornit Objednatele na veškerá nebezpečí škod, která jsou mu známa a která souvisejí s plněním předmětu této smlouvy.
7. Po ukončení této smlouvy je Zhotovitel bez zbytečného odkladu povinen předat Objednateli veškeré podklady, které mu Objednatel předal za účelem realizace předmětu plnění této smlouvy, resp. je povinen mu je předat i dříve např. po předání díla, pokud je již nepotřebuje pro zajištění podpory provozu díla.
Článek XI.
Povinnosti archivace a součinnosti při kontrolách
1. Zhotovitel je povinen archivovat veškerou dokumentaci spojenou s předmětem plnění této smlouvy (zejm. účetní doklady) od účinnosti této smlouvy do 31.12.2035, včetně umožnění přístupu k ní. Pokud je v českých právních předpisech stanovena lhůta delší, musí se jí Zhotovitel řídit.
2. Zhotovitel je povinen minimálně do 31.12.2035 poskytovat informace a dokumentaci vztahující se k předmětu plnění této smlouvy zaměstnancům nebo zmocněncům pověřených orgánů [Centra pro regionální rozvoj ČR, Ministerstva pro místní rozvoj ČR, Ministerstva financí ČR, Evropské komise, Evropského účetního dvora, Nejvyššího kontrolního úřadu, Auditního orgánu (dále jen „AO“), Platebního a certifikačního orgánu (dále jen „PCO“), příslušného orgánu finanční správy a dalších oprávněných orgánů státní správy] a je povinen informovat Objednatele, případně poskytovatele dotace o skutečnostech majících vliv na plnění předmětu této smlouvy, především je povinen informovat o jakýchkoli kontrolách a auditech provedených v souvislosti s plnění předmětu této smlouvy. Zhotovitel je rovněž minimálně do 31.
12. 2035 povinen vytvářet podmínky k provádění kontrol (auditů) vztahujících se k realizaci plnění předmětu této smlouvy, podrobit se jejich provedení a poskytnout součinnost pro jejich výkon, a dále je povinen na žádost Objednatele, poskytovatele dotace, řídícího orgánu IROP, Centra pro regionální rozvoj ČR, Agentury ochrany přírody a krajiny ČR, PCO nebo AO poskytnout veškeré informace o výsledcích těchto kontrol a auditů včetně protokolů z těchto kontrol a zpráv o auditech. V souladu s § 2 písm. e) zákona č. 320/2001 Sb., o finanční kontrole, ve znění pozdějších předpisů je Xxxxxxxxxx povinen poskytnout kontrolním orgánům a Objednateli veškerou potřebnou součinnost při výkonu finanční kontroly a obdobně zavázat i své případné poddodavatele.
Článek XII.
Ochrana informací a závazek mlčenlivosti
1. Za důvěrné informace ve smyslu § 1730 občanského zákoníku se bez ohledu na formu jejich získání považují veškeré informace, které se týkají obsahu, struktury a zabezpečení informačních a
komunikačních systémů Objednatele či jeho příslušných příspěvkových organizací. Dále se považují za důvěrné informace takové informace, které jsou jako důvěrné výslovně některou ze stran označeny.
2. Smluvní strany jsou povinny zajistit utajení získaných důvěrných informací způsobem obvyklým pro utajování takových informací, není-li výslovně sjednáno jinak. Tato povinnost platí bez ohledu na ukončení účinnosti této smlouvy. Strany mají právo požadovat navzájem doložení dostatečnosti utajení důvěrných informací. Strany jsou povinny zajistit utajení důvěrných informací i u svých zaměstnanců, zástupců, jakož i jiných spolupracujících třetích stran, pokud jim takové informace byly poskytnuty. Ustanovení zákona č. 106/1999 Sb., o svobodném přístupu k informacím, ve znění pozdějších předpisů nejsou tímto dotčena.
3. Právo užívat, poskytovat a zpřístupnit důvěrné informace mají obě strany pouze v rozsahu a za podmínek nezbytných pro řádné plnění práva a povinností vyplývajících z této smlouvy.
4. Zhotovitel není v rámci plnění této smlouvy zpracovatelem osobních údajů, jejichž správcem je Objednatel nebo jeho příslušné příspěvkové organizace, ani by neměl při plnění této smlouvy přijít do styku s takovými osobními údaji. V případě, že by se Xxxxxxxxxx při plnění této smlouvy náhodně seznámil s osobními údaji, jejichž správcem je Objednatel či jeho příslušné příspěvkové organizace, je povinen tyto údaje považovat za důvěrné informace a jako s důvěrnými s nimi zacházet, jakož i zachovat mlčenlivost ve vztahu k takovým osobním údajům, a dále je povinen učinit taková opatření, aby nemohlo dojít k dalšímu neoprávněnému nebo nahodilému přístupu k těmto osobním údajům, k jejich změně, zničení či ztrátě, neoprávněným přenosům, neoprávněnému zpracování, jakož i k jejich jinému zneužití přiměřeně tak, jak je uvedeno v 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ů), které stanovuje práva a povinnosti při zpracování osobních údajů, v zákoně č. 110/2019 Sb., o zpracování osobních údajů, v platném znění, případně pak v dalších zákonech, které budou mít přímou souvislost k ochraně osobních údajů. V případě, že nastane skutečnost uvedená v předchozí větě, je Zhotovitel povinen zavázat k mlčenlivosti i veškeré své zaměstnance, jakož i veškeré třetí osoby, které by mohly přijít s takovými informacemi (osobními údaji) v rámci své činnosti, byť nahodile, do styku. Za porušení povinnosti mlčenlivosti osobami, které se budou podílet na provádění díla dle této smlouvy, odpovídá Xxxxxxxxxx, jako by povinnost porušil sám.
5. Závazky k zachovávání důvěrnosti informací zůstanou v plném rozsahu platné a účinné i po ukončení platnosti a účinnosti této smlouvy, a to až do doby, kdy se tyto stanou obecně známými jinak než porušením této smlouvy, nebo je poskytující smluvní strana přestane utajovat. V pochybnostech se má za to, že utajování informací trvá.
6. Po ukončení účinnosti této smlouvy je každá ze smluvních stran povinna bez zbytečného odkladu vrátit druhé smluvní straně všechny poskytnuté materiály obsahující důvěrné informace včetně jejich případně pořízených kopií. O předání a převzetí se sepíše protokol podepsaný oběma smluvními stranami (jejich zástupci ve věcech technických, případně smluvních).
Článek XIII. Bezpečnostní pravidla
1. Zhotovitel se zavazuje dodržovat Bezpečnostní pravidla informačního systému Objednatele uvedená v Příloze č. 3. této smlouvy. Obdobně se povinnosti Zhotovitele uvedené v Příloze č. 3 této smlouvy vztahují i na případné poddodavatele Zhotovitele. Zhotovitel je povinen takového poddodavatele zavázat k dodržování a zachovávání bezpečnostních pravidel v souladu s Přílohou č. 3 této smlouvy. V případě, že by došlo k porušení povinnosti Zhotovitele prostřednictvím některého z jeho poddodavatelů, odpovídá za toto porušení Zhotovitel, jako by povinnost porušil sám.
2. Zhotovitel se zavazuje, že všechny osoby podílející se na plnění smlouvy budou při svých činnostech dodržovat a zachovávat bezpečnostní pravidla uvedená v Příloze č. 3. této smlouvy.
3. Zhotovitel se zavazuje, že seznámí všechny osoby podílející se na plnění smlouvy, kteří budou do informačních systémů nebo do prostor Objednatele přistupovat, s bezpečnostními pravidly před začátkem jakýchkoliv aktivit.
4. Přihlašovací údaje do informačních systémů nebo přístupů do prostor Objednatele, případně příspěvkových organizací, budou předávány na základě jednotlivých písemných protokolů.
Článek XIV. Závěrečná ujednání
1. Smlouva podléhá zveřejnění v Registru smluv v souladu se zákonem č. 340/2015 Sb., o zvláštních podmínkách účinnosti některých smluv, uveřejňování těchto smluv a o registru smluv (zákon o registru smluv). Smluvní strany se dohodly, že Objednatel v zákonné lhůtě odešle tuto smlouvu k řádnému uveřejnění do registru smluv vedeného Ministerstvem vnitra ČR. O uveřejnění této smlouvy Objednatel bezodkladně informuje Xxxxxxxxxx (postačí e-mailem prostřednictvím kontaktní osoby/zástupce ve věcech technických nebo smluvních). V případě, že ihned po podpisu této smlouvy není jednou ze smluvních stran oznámeno písemně druhé smluvní straně (postačí e-mailem prostřednictvím kontaktní osoby/zástupcem ve věcech technických nebo smluvních), že smlouva nebo její přílohy obsahují obchodní tajemství, berou smluvní strany na vědomí, že tato obchodní smlouva nebo její přílohy neobsahují obchodní tajemství.
2. Xxxxxxxxxx prohlašuje, že si je vědom skutečnosti, že objednatel má zájem na realizaci veřejné zakázky (resp. plnění předmětu této smlouvy) v souladu se zásadami společensky odpovědného zadávání veřejných zakázek. Zhotovitel se zavazuje po celou dobu trvání smluvního poměru založeného touto smlouvou zajistit dodržování veškerých právních předpisů, zejména pak pracovněprávních (odměňování, pracovní doba, doba odpočinku mezi směnami, placené přesčasy), dále předpisů týkajících se oblasti zaměstnanosti a bezpečnosti a ochrany zdraví při práci, tj. zejména zákona 435/2004 Sb., o zaměstnanosti, ve znění pozdějších předpisů a zákona 262/2006 Sb., zákoníku práce, ve znění pozdějších předpisů, a to vůči všem osobám, které se na plnění zakázky, resp. plnění předmětu této smlouvy, podílejí a bez ohledu na to, zda budou činnosti prováděné v rámci realizace plnění předmětu smlouvy prováděny zhotovitelem či jeho poddodavatelem. Dále se zavazuje, že při plnění této smlouvy bude v míře, kterou připouští řádné plnění předmětu této smlouvy, využívat pro komunikaci a korespondenci prostředky elektronické komunikace, bude minimalizovat spotřebu kancelářského materiálu, a pokud není uvedené v této smlouvě či jejích přílohách jinak se, snažit minimalizovat dopad na životní prostředí, respektovat udržitelnost či možnosti cirkulární ekonomiky a pokud je to možné a vhodné bude implementovat nové nebo značně zlepšené produkty, služby nebo postupy; tento závazek bude požadovat i od svých poddodavatelů.
3. Zhotovitel se zavazuje předložit objednateli seznam poddodavatelů v souladu s ustanovením § 105 odst. 1 zákona č. 134/2016 Sb., o zadávání veřejných zakázek, v platném znění, tzn. jaká část plnění veřejné zakázky (této smlouvy) byla zadána třetím osobám, o které osoby se jednalo (identifikační údaje dle § 28 odst. 1 písm. g) zákona o zadávání veřejných zakázek). Úprava či doplnění seznamu poddodavatelů v průběhu plnění této smlouvy, jsou možné pouze na základě písemné dohody smluvních stran. Změna poddodavatele uvedeného v nabídce, předložené do zadávacího řízení předcházejícího a týkajícího se uzavření této smlouvy, v průběhu plnění této smlouvy je možná pouze se souhlasem Objednatele, a to i tehdy, pokud Zhotovitel pomocí tohoto poddodavatele neprokazoval splnění kvalifikace. Pokud však Zhotovitel prokázal splnění části kvalifikace pomocí poddodavatele, je oprávněn ho nahradit pouze poddodavatelem, který splňuje požadovanou část kvalifikace ve stejném nebo větším rozsahu. Objednatel není oprávněn souhlas s výměnou poddodavatele bez objektivního důvodu odmítnout.
4. Zhotovitel je povinen v rámci plnění předmětu této smlouvy poskytnout Objednateli či poskytovateli dotace k Projektu informaci o všech skutečných majitelích Zhotovitele a o všech skutečných majitelích poddodavatelů, kterými Zhotovitel prokazoval kvalifikaci v rámci zadávacího řízení předcházejícího a týkajícího se uzavření této smlouvy, to vše ve smyslu čl. 3 bodu 6 směrnice (EU) 2015/849, resp. § 2 písm.
e) zákona č. 37/2021 Sb., o evidenci skutečných majitelů, ve znění pozdějších předpisů, a sice jméno (jména) a příjmení, datum narození a identifikační číslo (čísla) pro účely DPH nebo daňové identifikační číslo (čísla) těchto skutečných majitelů. Dále je povinen Zhotovitel poskytnout Objednateli či příslušnému poskytovateli dotace bez zbytečného odkladu informace o změnách v osobách skutečných majitelů zhotovitele a poddodavatelů uvedených ve větě první tohoto odstavce.
5. Zhotovitel tímto ve vztahu k předmětu plnění této smlouvy prohlašuje, že ve smyslu nařízení Rady (EU) č. 2022/576 ze dne 8. dubna 2022, kterým se mění nařízení (EU) č. 833/2014 o omezujících opatřeních vzhledem k činnostem Ruska destabilizujícím situaci na Ukrajině, (dále jen „nařízení Rady (EU) č. 2022/576“):
a) on ani (i) kterýkoli z jeho poddodavatelů či jiných osob dle § 83 zákona č. 134/2016 Sb., o zadávání veřejných zakázek, ve znění pozdějších předpisů, který se bude podílet na plnění předmětu této smlouvy nebo (ii) kterákoli z osob, jejichž kapacity bude Zhotovitel využívat, a to v rozsahu více než 10 % celkové ceny za plnění uvedené v článku VI. odst. 1 této smlouvy:
aa) není ruským státním příslušníkem, fyzickou či právnickou osobou nebo subjektem či orgánem se sídlem v Rusku,
ab) není z více než 50 % přímo či nepřímo vlastněn některým ze subjektů uvedených v písmeni aa), ani
ac) nejedná jménem nebo na pokyn některého ze subjektů uvedených v písmeni aa) nebo ab);
b) není osobou uvedenou v sankčním seznamu v příloze nařízení Rady (EU) č. 269/2014 ze dne
17. března 2014, o omezujících opatřeních vzhledem k činnostem narušujícím nebo ohrožujícím územní celistvost, svrchovanost a nezávislost Ukrajiny (ve znění pozdějších aktualizací) (dále jen „nařízení Rady (EU) č. 269/2014“) nebo nařízení Rady (ES) č. 765/2006 ze dne 18. května 2006 o omezujících opatřeních vůči prezidentu Xxxxxxxxxxx a některým představitelům Běloruska (ve znění pozdějších aktualizací)3 (dále jen „nařízení Rady (ES) č. 765/2006“) nebo nařízení Rady (EU) č. 208/2014 ze dne 5. března 2014, o omezujících opatřeních vůči některým osobám, subjektům a orgánům vzhledem k situaci na Ukrajině ze dne 5. března 2014 o omezujících opatřeních vůči některým osobám, subjektům a orgánům vzhledem k situaci na Ukrajině (ve znění pozdějších aktualizací) (dále jen „nařízení Rady (EU) č. 208/2014“);
c) žádné finanční prostředky, které obdrží za plnění předmětu této smlouvy, přímo ani nepřímo nezpřístupní fyzickým nebo právnickým osobám, subjektům či orgánům s nimi spojeným nebo v jejich prospěch uvedeným v sankčním seznamu v příloze nařízení Rady (EU) č. 269/2014 ve spojení s prováděcím nařízením Rady (EU) č. 2022/581 ze dne 8. dubna 2022, kterým se provádí nařízení (EU) č. 269/2014 o omezujících opatřeních vzhledem k činnostem narušujícím nebo ohrožujícím územní celistvost, svrchovanost a nezávislost Ukrajiny (dále jen „prováděcí nařízení Rady (EU) č. 2022/581“), nařízení Rady (EU) č. 208/2014 nebo nařízení Rady (ES) č. 765/2006;
d) že neobchoduje se sankcionovaným zbožím, které se nachází v Rusku nebo Bělorusku či z Ruska nebo Běloruska pochází a nenabízí takové zboží v rámci plnění veřejných zakázek (potažmo plnění předmětu této smlouvy);
e) s ohledem na výše uvedené se zavazuje dodržovat mezinárodní sankce Evropské unie, přijaté v souvislosti s ruskou agresí na území Ukrajiny vůči Rusku a Bělorusku, zejména nařízení Rady EU č. 2022/576, nařízení Rady (EU) č. 269/2014 ve spojení s prováděcím nařízením Rady (EU) č. 2022/581, nařízení Rady (EU) č. 208/2014 a nařízení Rady (ES) č. 765/2006.
6. V případě změny skutečností uvedených v odstavci 5 tohoto článku se Zhotovitel zavazuje o těchto změnách Objednatele neprodleně informovat. Zhotovitel se rovněž zavazuje nevyužít pro plnění předmětu této smlouvy osoby nebo poddodavatele, na které se vztahují mezinárodní sankce uvedené pod písmenem
e) odstavce 5 tohoto článku.
7. Xxxxxxxxxx bere na vědomí povinnost Objednatele vyplývající ze zákona č. 106/1999 Sb., o svobodném přístupu k informacím, ve znění pozdějších předpisů.
9. Tuto smlouvu lze změnit nebo doplňovat pouze písemnými dodatky, které budou podepsány oběma smluvními stranami, není-li v ní uvedeno jinak. Přílohu č. 3 této smlouvy – Bezpečnostní pravidla informačního systému Objednatele, je oprávněn změnit Objednatel jednostranně (avšak pouze způsobem, který nevyvolá u zhotovitele nepřiměřené vícenáklady), přičemž o této změně neprodleně informuje Xxxxxxxxxxx, a zároveň Zhotoviteli předá aktualizovanou Přílohu č. 3 této smlouvy, a to vše na základě písemného protokolu podepsaného prostřednictvím zástupců – kontaktních osob smluvních stran ve věcech technických. Za nepřiměřené vícenáklady pro Zhotovitele však není považována samotná smluvní pokuta v případě nesplnění např. nové povinnosti/závazku Zhotovitele uvedené ve změněné (aktualizované) Příloze č. 3 této smlouvy. Nepřiměřené vícenáklady by se musely týkat přímo zajištění nové povinnosti/závazku. Za nepřiměřené náklady se nepovažují náklady v hodnotě do 4.000,- Kč ročně ve vztahu ke každé nové povinnosti/závazku.
10. Nedílnými součástmi této smlouvy jsou následující přílohy:
Příloha č. 1 – Technická specifikace (podrobné vymezení) díla Příloha č. 2 – Podmínky zajištění podpory provozu díla
3 Aktualizovaný seznam sankcionovaných osob je uveden například na internetových stránkách Finančního analytického úřadu zde xxxxx://xxx.xxxxxxxxxxxxxxxxxxxxxx.xx/xxxx/xxxxxxxx-xxxxxxx-xxxx-xx-xxxxxxx-xxxxxx-xxxxx-xxxxx.
Příloha č. 3 – Bezpečnostní pravidla informačního systému Objednatele Příloha č. 4 – Formulář technických požadavků
Příloha č. 5 – Seznam licencí a jejich cena Příloha č. 6 – Formulář OHA
Pokud se v těchto přílohách hovoří o zadavateli či žadateli, myslí se jím Objednatel. Pokud se v těchto přílohách hovoří o dodavateli, uchazeči, účastníkovi nebo poskytovateli, myslí se jím Zhotovitel. Pokud se v těchto přílohách hovoří o řešení, programovém vybavení, systému, nástroji apod., myslí se jím dílo nebo jeho část, pokud z kontextu nevyplývá jiný význam. Pokud je v těchto přílohách něco upraveno odlišně než v textu smlouvy samotné, přednost má text smlouvy samotné.
11. V případě, že Zhotovitel je plátcem DPH, pak podpisem této smlouvy výslovně prohlašuje, že:
- nemá v úmyslu nezaplatit daň z přidané hodnoty u zdanitelného plnění podle této smlouvy (dále jen
„daň“),
- mu nejsou známy skutečnosti, nasvědčující tomu, že se dostane do postavení, kdy nemůže daň zaplatit a ani se ke dni podpisu této smlouvy v takovém postavení nenachází,
- nezkrátí daň nebo nevyláká daňovou výhodu,
- úplata za plnění dle této smlouvy není odchylná od obvyklé ceny
- úplata za plnění dle této smlouvy nebude poskytnuta zcela nebo zčásti bezhotovostním převodem na účet vedený poskytovatelem platebních služeb mimo tuzemsko,
- nebude nespolehlivým plátcem,
- bude mít u správce daně registrován bankovní účet používaný pro ekonomickou činnost,
- souhlasí s tím, že pokud ke dni uskutečnění zdanitelného plnění nebo k okamžiku poskytnutí úplaty na plnění bude o Zhotoviteli zveřejněna správcem daně skutečnost, že Zhotovitel je nespolehlivým plátcem, uhradí Objednatel daň z přidané hodnoty z přijatého zdanitelného plnění příslušnému správci daně,
- souhlasí s tím, že pokud ke dni uskutečnění zdanitelného plnění nebo k okamžiku poskytnutí úplaty na plnění bude zjištěna nesrovnalost v registraci bankovního účtu Zhotovitele určeného pro ekonomickou činnost správcem daně, uhradí Objednatel daň z přidané hodnoty z přijatého zdanitelného plnění příslušnému správci daně.
12. Zhotovitel je povinen dodržovat zásadu DNSH (Do No Significant Harm), tj. „významně nepoškozovat“ životní prostředí blíže specifikovanou zejména v dokumentech týkajících se „Implementace zásady
„významně nepoškozovat“ životní prostředí (DNSH) v projektech IROP 2021-2027“, které jsou ke stažení zde: xxxxx://xxxx.xxx.xx/xx/xxxx-0000-0000/xxxxxxxxx
13. V souladu s ustanovením § 1801 občanského zákoníku se ve smluvním vztahu založeném touto smlouvou vylučuje použití ustanovení § 1799 a § 1800 občanského zákoníku.
14. Práva a povinnosti smluvních stran výslovně v této smlouvě neupravená se řídí příslušnými ustanoveními občanského zákoníku; pokud se týká té části smlouvy, jejímž předmětem je provedení (zhotovení) díla a není-li v této smlouvě uvedeno jinak, použijí se na ni ustanoveními občanského zákoníku pro smlouvu o dílo.
15. Případná neplatnost některého ustanovení této smlouvy nemá za následek neplatnost ostatních ustanovení. V případě, že kterékoliv ustanovení této smlouvy se stane neúčinným nebo neplatným, smluvní strany se zavazují bez zbytečného odkladu nahradit takové ustanovení novým, které svým obsahem a smyslem odpovídá nejlépe obsahu a smyslu ustanovení původního.
16. Tato smlouva nabývá platnosti dnem jejího podpisu oběma smluvními stranami. Tato smlouva nabývá účinnosti dnem jejího uveřejnění prostřednictvím registru smluv dle § 6 zákona č. 340/2015 Sb., o zvláštních podmínkách účinnosti některých smluv, uveřejňování těchto smluv a o registru smluv (zákon o registru smluv), ve znění pozdějších předpisů. V případě, že tato smlouva bude vyhotovena a podepsána v analogové formě, bude vyhotovena ve třech stejnopisech, z nichž Objednatel obdrží dvě vyhotovení a Zhotovitel jedno vyhotovení. V případě, že tato smlouva bude vyhotovena v elektronické/digitální podobě, každá smluvní strana ji bude mít k dispozici, a to po jejím podepsání příslušnými elektronickými podpisy oběma smluvními stranami.
Doložka dle § 23 zákona č. 129/2000 Sb., o krajích, ve znění pozdějších předpisů
Rozhodnuto orgánem kraje: Rada Zlínského kraje
Datum a číslo jednací: 16.9.2024, usnesení č. 0901/R25/24
za Objednatele: za Zhotovitele:
Ve Zlíně dne: …………. Ve Zlíně dne: ……………
.................................. ...................................
Xxx. Xxxxx Xxxxx Xxx. Xxxxx Xxxxx
hejtman předseda představenstva
...................................
Xxx. Xxxxx Xxxxx člen představenstva
Kontroloval:
Příloha č. 1 TECHNICKÁ SPECIFIKACE DÍLA
3Obsah
1.1 Požadované služby ePortálu a aplikace chatbot 4
2. Požadavky na funkcionality ePortálu 8
3. Požadavky na funkcionality chatbota 22
4. Společné technické požadavky 26
4.1 Požadavky na dokumentaci a implementační analýzu 26
4.3 Umístění Aplikace a zajištění domén 29
4.4 Přístupnost, podpora prohlížečů a responzivní zobrazení 29
4.6 Požadované technické parametry dostupnosti a výkonnosti 30
4.7 Šifrování a kryptografie 30
4.8 Společné bezpečnostní požadavky 34
5. Parametry poskytnuté infrastruktury Zadavatele a poskytnuté technologie 37
1. ePortál Zlínského kraje
Požadovaným výstupem Díla je dodání a implementace nového portálového řešení na krajské úrovni, které bude sloužit jako transakční řešení pro fyzické a právnické osoby, a dále jako portál pro spolupráci s krajskými příspěvkovými organizacemi na řešení agend. Portál bude mít pro všechny zmíněné rovněž informační funkci.
ePortál Zlínského kraje (dále jako ePortál) bude navržen jako moderní portálové modulární řešení, které bude nasazeno on-premise v rámci ICT infrastruktury Zlínského kraje. Řešení nebo jeho části je možné realizovat na open source platformě.
V rámci ePortálu bude nasazen další výstup díla, SW řešení pro automatizovanou komunikaci s uživatelem – chatbot, který bude k dispozici pro všechny uživatele portálu a bude jim poskytovat odpovědi na časté dotazy, případně jim pomůže s navigaci v rámci portálu a využíváním funkcí portálu.
ePortál bude rozdělen na tři části – na veřejnou část, která bude k dispozici pro všechny návštěvníky a bude obsahovat kromě úvodních informací informační články, životní situace a aktuality pro občany kraje a právnické osoby, sídlící v rámci kraje. Další částí bude neveřejná část pro občany a firmy, která bude vázána na autentizaci skrze NIA a datové schránky, skrze část budou realizovány transakční služby pro občana a právnickou osobu. Autentizovat se bude moci jak fyzická a právnická osoba, tak zástupce obce. Třetím prostředím bude tzv. backoffice prostředí, které bude architektonicky odděleno od předchozích dvou prostředí, bude nasazeno v interní LAN Zlínského kraje a budou do ni skrze autentizaci přes Identity management (IDM) nebo Active-directory (AD) přistupovat pracovníci Zlínského kraje nebo pracovníci příspěvkových organizací Zlínského kraje.
Pracovníci Zlínského kraje budou portál administrovat, uživatelé kraje s rolí administrátor tedy budou mít neomezený přístup k modularitě neveřejné části a backoffice části a budou moci jednotlivé moduly a funkce konfigurovat. Autorizace bude řešena přes systém rolí, který bude implementovaný v rámci ePortálu a bude umožňovat přiřadit hromadné role uživatelům, případně upravit příslušná oprávnění pro konkrétního uživatele administrátorem.
Výčet požadovaných služeb ePortálu a chatbota je uveden v následující subkapitole. Dále je uveden
požadovaný výčet výstupů Díla v rámci další subkapitoly.
1.1 Požadované služby ePortálu a aplikace chatbot
ePortál bude poskytovat následující služby skrze své moduly a funkce:
• Služba autentizace přes důvěryhodné přihlášení – ePortál umožní autentizaci do neveřejné části portálu přes autentizační rozhraní. Jako autentizační rozhraní budou využity Národní bod pro identifikaci a autorizaci (NIA) a datové schránky (ISDS) a dále bude realizována integrace na Identity management Zlínského kraje (IDM) či Active-directory pro backoffice část.
• Informační služby – ePortál bude poskytovat v rámci všech prostředí informace pro uživatele ve formě článků a aktualit.
• Přístup k dokumentům a informacím – ePortál bude zpřístupňovat data a soubory. U souborů umožní jejich stažení. Data a soubory budou zpřístupněny pouze uživatelům dle jejich oprávnění.
• Formulářové služby – ePortál bude obsahovat formulářové řešení, které umožní navrhovat elektronické formuláře, zobrazitelné v rámci UI portálu s následnou možností jejich vyplnění uživatelem. Formulář bude předvyplněn údaji, které jsou o uživateli již známé skrze autentizaci a bude obsahovat masky, kterými bude kontrolovat uživatelem zadané informace dle jednotlivých kolonek formuláře.
• Služba elektronické podání – ePortál umožní elektronické podání formuláře na podatelnu. Podání bude zasíláno do podatelen příspěvkových organizací a Zlínského kraje (typově dvě spisové služby).
• Služba sledování stavu podání – ePortál následně umožní v rámci neveřejné části uživateli sledovat jeho podání v jakém se nachází stavu. Tento údaj bude přebírán ePortálem ze spisové služby.
• Služba platba přes platební bránu – ePortál umožní zaplatit uživateli poplatky přes platební bránu, která bude v portálu integrovaná. Umožní realizovat platbu na účet Zlínského kraje nebo účty příspěvkových organizací.
• Služba historie plateb – ePortál bude v rámci neveřejné části uživateli zobrazovat historii jeho plateb realizovaných přes ePortál.
• Služba statistika uživatele – ePortál bude pro uživatele vytvářet statistiku jeho využití ePortálu ve formě informačního dashboardu.
• Služba výstupy z datového skladu – ePortál umožní přebírat data z datového skladu Zlínského kraje.
• Služba výstupy z digitálního repozitáře – ePortál umožní v rámci backoffice části dotazování do IS Digitální repozitář, následně převezme výsledky vyhledávání a umožní uživateli stažení požadované datové sady dvou typů.
• Služba administrace dotace – ePortál bude sloužit jako aplikační řešení pro řešení krajských dotací. Umožní zažádat o dotaci přes neveřejnou část s následnou administrací dotace v backoffice části portálu.
• Služba notifikace – ePortál bude umožňovat zasílání notifikací uživatelů prostřednictvím SMS
a e-mailem.
• Služba uživatelské administrace – ePortál umožní uživatelskou administraci podle typu uživatele od základního nastavení komunikačního kanálu notifikace pro občana či firmu až po komplexnější administraci pracovníka kraje.
• Služba administrace modularity – ePortál umožní správcům modulů konfigurovat jejich
modul.
• Služba administrace ePortálu – ePortál bude obsahovat administraci, řešící systémové fungování ePortálu, vč. konfigurace portálu, modulů, formulářů, monitoringu, log managementu, správy rolí, managementu databáze ePortálu.
Chatbot pak bude poskytovat následující služby:
• Služba informační asistence – chatbot bude poskytovat uživatelům informační asistence vč. řešení častých dotazů a navigace v ePortálu. Chatbot bude obsahovat znalostní okruhy dle
typu prostředí, tedy u veřejné části bude schopen zodpovědět časté dotazy a poradit
s autentizací, v neveřejné části bude navíc uživateli asistovat při podání formuláře nebo platbě, v backoffice části bude uživateli asistovat při práci v jednotlivých modulech.
• Služba neustálé dostupnosti – chatbot bude dostupný 24/7 a bude nasazený na ICT
prostředcích Zlínského kraje.
• Služba rozpoznání kontextu informace a přirozenou komunikaci s uživatelem – chatbot
bude využívat NLP (natural language processing, tedy bude komunikovat s uživatelem
v textové podobě přirozeným jazykem. Bude schopen rozpoznat kontext komunikace
s uživatelem a jeho dotaz a bude se na základě komunikace s uživateli učit pro zvyšování úspěšnosti zodpovězení dotazu skrze prvky umělé inteligence (AI).
• Indexování webů – chatbot bude indexovat vybrané weby na základě pravidelného intervalu nebo uživatelským spuštěním a bude z těchto webů přebírat obsah a obohacovat svou znalostní DB, čímž umožní reagovat na dotazy informacemi z indexovaných webů a
odkazovat na ně.
1.2 Požadované výstupy Díla
V rámci realizace Díla je Zadavatelem požadováno pro úspěšné splnění projektu a následnou akceptaci Díla dodání výstupů, které Xxxxxxxxxx považuje za nutné pro nasazení a provoz díla v souladu se zavedenými procesy Zadavatele a plnění platné legislativy. Zadavatel je povinná osoba vůči ZoKB.
Požadované výstupy
• Implementační analýza (IA)– Dodavatel realizuje implementační analýzu, v rámci které ve spolupráci se Zadavatelem upřesní požadavky na cílový systém a způsob realizace. Součástí bude popis cílového systému pro jeho realizaci a nasazení. Součástí implementační analýzy bude také podrobný harmonogram a obsah předmětu provádění díla. Analýzu akceptuje Zadavatel po vypořádání připomínek.
• Vytvoření grafického návrhu - V rámci implementační analýzy vznikne vizuální návrh ePortálu a chatbota, který bude ve 3 variantách představen Zadavateli, ten následně předá Dodavateli pokyny k dalším úpravám vizuálního návrhu a akceptuje vítěznou variantu po zakomponování požadavků Zadavatele.
• Vytvoření znalostní DB – Součástí implementační analýzy je analýza znalostních okruhů, se kterou bude chatbot operovat. V rámci té Xxxxxxxxx realizuje rozhovory s gesčními organizačními útvary Zadavatele a vytvoří cílovou podobu znalostní databáze pro často kladené dotazy. Po vytvoření ePortálu do DB zavede rovněž znalostní databáze asistence v jednotlivých prostředích – neveřejného a backoffice.
• Vytvoření ePortálu – Dodavatel realizuje vývoj/dodání díla v rámci prostředí Dodavatele do
cílové podoby, požadované Zadavatelem.
• Vytvoření chatbota – Dodavatele vytvoří cílovou aplikaci chatbot ve třech instancích – pro
veřejnou, neveřejnou a backoffice část ePortálu. Chatbot bude obsahovat uživatelskou aplikaci
– klienta a aplikaci pro správu chatbota. Zakomponuje do instancí chatbota znalostní databázi
často kladených dotazů ze vstupní analýzy a dále dle instance znalostní databázi asistence
v jednotlivých prostředích – neveřejného a backoffice.
• Implementace do testovacího prostředí – Dodavatel za spolupráce Xxxxxxxxxx realizuje implementaci ePortálu a chatbota do testovacího prostředí Zadavatele.
• Realizace integrací – Dodavatel zajistí ve spolupráci se Zadavatelem integraci ePortálu a chatbota na cílové systémy dle implementační analýzy.
• Vytvoření formulářů – Dodavatel vytvoří elektronické formuláře v rámci ePortálu dle
vstupních podkladů od Zadavatele v rozsahu dle IA.
• Vytvoření životních situací – Dodavatel vytvoří informační články typu životní situace v rámci
ePortálu dle vstupních podkladů od Zadavatele (20 článků).
• Realizace testů – Dodavatel zajistí sadu testů, kterými ověří parametry ePortálu a chatbota. Dodavatel otestuje ePortál a chatbota již v rámci svého vývojového prostředí, následně budou testy realizované na testovacím prostředí Zadavatele a pro ověření následně na produkčním. Dodavatel realizuje minimálně následující testy:
o Performance testy – pro vývojové prostředí Dodavatele a testovací prostředí Zadavatele, v rámci testu bude ověřena odezva systému a vytížení HW, testy budou realizovány při simulaci vysokého vytížení.
o Funkční testy – pro tyto testy vytvoří Dodavatel testovací scénáře a bude je realizovat společně se Xxxxxxxxxxx. Z funkčních testů vznikne seznam případných zjištění – vad, které Dodavatel odstraní a následně se provede další iterace funkčních testů. Testy budou realizované pro všechna prostředí a scénáře budou reflektovat funkcionality daného prostředí.
o Bezpečnostní testy – Dodavatel zajistí nezávislé bezpečnostní otestování ePortálu a chatbota vč. všech jeho prostředí třetí stranou včetně penetračních testů. Testy budou realizovány dle metodiky OWASP TOP10. Případné zjištěné chyby Dodavatel odstraní.
o UX/UI testy – Dodavatel ve spolupráci se Zadavatelem zajistí UX/UI testy prostředí
ePortálu a chatbota a provede úpravy podle zjištěných neoptimalit UX/UI portálu.
o Akceptační testy – realizuje Zadavatel, Dodavatel je povinen odstranit nedostatky, nalezené testy.
• Implementace do produkčního prostředí – Dodavatel zajistí migraci ePortálu a chatbota do produkčního prostředí Zadavatele po odstranění případných vad z testování, doplnění znalostní DB na základě testování a akceptaci Zadavatele.
• a akceptaci Zadavatele.
• Vytvoření systémové dokumentace – Dodavatel vytvoří pro ePortál a chatbota systémovou dokumentaci popisující technický stav ePortálu a chatbota a dále vytvoří dokumentaci pro administrátory, která bude popisovat správu ePortálu, chatbota a jeho znalostní DB, vč. jejího doplňování a jejich prostředí. Současně vytvoří Dodavatel uživatelskou dokumentaci pro uživatele veřejné i neveřejné části a uživatele backoffice části ePortálu a uživatelskou dokumentaci pro práci s chatbotem. Dokumentace bude rovněž k dispozici jako nápověda v rámci UI prostředí Díla.
• Školení – Dodavatel zrealizuje školení v prostorách Zadavatele, přičemž bude realizovat oddělené školení pro administrátory (vč. administrátorů modulů) a pro uživatele. Uživatelské školení bude společné pro školené z řad Zadavatele a zástupců příspěvkových organizací Zadavatele.
• Předání zdrojových kódů – Dodavatel předá pro vyvíjené části systému zdrojové kódy Zadavateli jako strojově čitelná data vč. manuálu popisujícího strukturu zdrojových kódů a jejich kompilaci/spuštění, a to dle podmínek článku IV. Smlouvy.
• Předání licencí – Dodavatel k dílu předá nevýhradní časově, početně a místně neomezenou licenci. Současně předá licence k SW třetích stran, budou-li využity v rámci díla a rovněž předá licence k technologickému SW, které dílo bude využívat.
• Asistence při pilotním provozu – Dodavatel poskytne Zadavateli podporu při pilotním provozu díla, která se bude spočívat v součinnosti při vyhodnocování parametrů provozu a dále zajistí odstranění případných vad a neoptimalit, které se mohou při pilotním provozu projevit a nasadí jejich opravu nejprve do testovacího prostředí a po schválení Zadavatelem do produkce. Xxxx rovněž asistovat při případném doplňování znalostní DB pro zajištění její integrity a bezchybnosti.
Pozn. Spolupráce Zadavatele se spočívá v poskytnutí součinnosti při implementaci z pohledu nastavení přístupů, poskytnutí HW s minimálními parametry viz tento dokument, poskytnutí testovacích uživatelů pro otestování systému, zajištění součinností Dodavatelů integrovaných systémů a poskytování nezbytných vstupů pro vytvoření Díla. Za veškeré výstupy Díla odpovídá Dodavatel a je garantem jejich realizace.
2. Požadavky na funkcionality ePortálu
ePortál bude dodán jako portálové modulární řešení splňující aktuální platnou legislativu pro informační systémy veřejné správy.
Níže jsou uvedeny požadavky na ePortál a související výstupy dle oblastí:
2.1 Architektura
Architektura ePortálu bude řešena jako modulární s realizovanými integracemi mezi moduly, čímž umožní přebírání dat mezi moduly a jejich další práci s nimi v jiném modulu. Architektura bude navržena jako otevřená s možností rozšíření o další moduly v rámci rozvoje řešení.
Backend ePortálu bude navržen s využitím aktuálních a bezpečných algoritmů, které nevykazují kybernetickou zranitelnost. Backend bude rozdělen do dvou oddělených instancí – první pro backoffice část a druhou pro veřejnou a neveřejnou část. Tyto instance budou nasazeny na oddělené infrastruktuře a budou fungovat v rozdílných úsecích sítě. Mezi těmito částmi bude zajištěna zabezpečená a logovaná integrace umožňující předávání informací mezi instancemi.
ePortál ZK
Vypublikované aplikace
dostupné z internetu
Web
aplication firewall
LAN
Zadavatele
Neveřejná část
ePortál
Veřejná část
ePortál
Integrace
Integrace
Interní IS a aplikace Zadavatele
Backoffice část
ePortál
Obrázek 1- Rozdělení přístupů do prostředí dle sítě – public a LAN
Frontend ePortálu bude navržen s využitím aktuálních a bezpečných algoritmů, které nevykazují kybernetickou zranitelnost a bude reflektovat požadavky subkapitoly Zobrazení. Frontend bude navržen ve třech prostředích.
Pro všechna prostředí platí, že frontend bude konfigurovatelný přes administraci ePortálu, bude tedy možné měnit strukturu a zobrazení frontendu administrátorem s využitím grafického rozhraní ePortálu přes WYSIWYG editor, jenž bude součástí ePortálu.
Veřejné prostředí bude navrženo jako veřejně přístupné prostředí bez vázanosti na uživatelské role a IP adresu. Bude zobrazovat modul aktuality, modul články, klienta chatbota instance veřejné části ePortálu a bude zajišťovat přechod do neveřejného prostředí.
Neveřejné prostředí bude navrženo jako zabezpečené prostředí vázané na autentizaci přes prostředky důvěryhodné autentizace NIA a ISDS. Výchozí role uživatelů neveřejného prostředí budou předdefinované a přiřazované na základě důvěryhodného přihlášení uživatele. Neveřejná část bude zobrazovat moduly:
• modul aktuality,
• modul články,
• modul elektronické formuláře,
• modul platby,
• modul sledování podání,
• modul historie plateb,
• modul uživatelská statistika,
• modul výstupy z datového skladu,
• modul dokumenty,
• modul uživatelská administrace.
K těmto modulům budou přiřazeny oprávnění v rámci rolí, které budou navrženy v implementační analýze Dodavatelem. Neveřejné prostředí bude dále obsahovat chatbota s instancí pro neveřejnou část ePortálu.
Backoffice prostředí bude realizováno backendem oddělené instance pro backoffice a bude vázané na autentizační rozhraní Zlínského kraje a jeho příspěvkových organizací – Identity managment systém nebo Active-directory. Prostředí bude přístupné pouze ze sítě Zadavatele přes VLAN a nebude do něho možné přistupovat z jiného prostředí ePortálu.
Integrace mezi Backoffice prostředím a dalšími prostředími ePortálu musí být realizované jako zabezpečené logované integrace s šifrovaným přenosem dat. Integraci a přenos dat nebude možné odposlechnout, nebude možné údaje změnit, ani zaslat integračním rozhraním škodlivý SW či jiná než schválená data.
Backoffice prostředí bude zobrazovat moduly:
• modul aktuality,
• modul články,
• modul administrace dotací,
• modul uživatelská statistika,
• modul výstupy z datového skladu,
• modul výstupy z digitálního repozitáře,
• modul dokumenty,
• modul uživatelská administrace,
• modul administrace modularity,
• modul administrace ePortálu.
K modulům bude v jednotlivých prostředích přístup přes menu.
ePortál bude obsahovat integrační rozhraní, skrze které bude možné realizovat integrace mezi částmi ePortálu a rovněž s externími informačními systémy a aplikacemi. Více k integracím je uvedeno v subkapitole integrace.
Zadavatell PPřřííssppěěvvkkoovvéé oorrggaanniizzaaccee ZZaaddaavvaatteellee
VPN point
Obbččaann Fiirma
NIA/ISDS IDM/AD
Neveřejná část
ePortál
Veřejná část
ePortál
Integrace
ePortál ZK
Backoffice část
ePortál
Obrázek 2 - Vizualizace přístupů do ePortálu
2.2 Zobrazení
Grafická podoba ePortálu bude vycházet z UI analýzy Dodavatele a výsledného grafického návrhu, který schválí Zadavatele. Struktura a zobrazení bude reflektovat Design systém xxx.xx (xxxxx://xxxxxxxxxxxx.xxx.xx/), ale rovněž požadavky Zadavatele k vizuální identitě Zadavatele a doporučení vzniklé z UX testování, které v rámci projektu bude Dodavatel realizovat.
Zobrazení bude v souladu s platnou legislativou v oblasti ČR, především zákona č. 99/2019 Sb. o přístupnosti internetových stránek a mobilních aplikací a se zákonem č. 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ů.
Jednotlivá prostředí a stránky budou strukturovány jako sémanticky korektní web – tj. přehledně formátované HTML s využitím HTML 5 a stylováním v CSS3. ePortál tedy bude mít správně strukturovaný HTML kód. Dále využije principů komprimace a minifikace vkládaných skriptů (pro CSS a JS).
ePortál bude navržen jako plně responzivní řešení, tj. zobrazení ePortálu se bude měnit podle velikosti displeje zobrazovacího zařízení, vč. podpory mobilních zařízení – tabletů a mobilních telefonů.
Prostředí bude umožňovat zobrazení libovolných HTML elementů, podporováno bude vkládání multimédií – obrázků, videí. Tyto elementy budou vložitelné v rámci WYSIWYG editoru, přes který se bude konfigurovat vzhled, struktura a obsah stránek. Za strukturu stránek ePortálu a naplnění legislativy je zodpovědný Dodavatel, následně po převzetí odpovídá za soulad úprav s legislativou Zadavatel.
2.3 Moduly
Níže jsou uvedeny požadavky na moduly ePortálu. V návaznosti na tyto požadavky bude bližší detail modulů a jejich funkcí zkoumán Dodavatelem v rámci implementační analýzy za součinnosti Zadavatele.
2.3.1 modul aktuality
Modul aktuality bude sloužit k zobrazení aktualit vlastníka ePortálu nebo některého z autorizovaných
vkladatelů aktualit Zadavatelem.
Aktuality budou obsahovat obrázek, datum vystavení, klíčová slova, kategorii aktuality, perex, obsah aktuality, zobrazení těchto atributů bude volitelné autorem. U aktuality bude možné vybrat pro které části ePortálu se budou publikovat – veřejná/neveřejná/backoffice či kombinace částí portálu. Obsah aktuality bude vkládaný skrze WYSIWYG editor.
Aktuality se budou vkládat/editovat/publikovat/odstraňovat v rámci backoffice prostředí a následně budou publikované v rámci vybraných prostředí. Publikaci bude možné odložit, omezit její platnost. Vkládat aktuality bude příslušná role v rámci systému rolí.
Aktuality bude možné provázat na notifikace, resp. zvolit, zda při publikaci dojde k notifikaci uživatelům o nové aktualitě. U aktuality bude možné nastavit vlastní URL.
Aktuality pro neveřejné a backoffice uživatele by měly být zobrazeny v rámci dashboardu úvodní strany
neveřejného a backoffice prostředí.
2.3.2 modul články
Modul články bude realizován obdobně jako aktuality s tím rozdílem, že půjde o stránky s delším obsahem a budou součástí jiné sekce. Oproti aktualitám bude možné k jednotlivým publikovaným článkům možné omezit přístup pro určité role nebo uživatele.
Články budou obsahovat obrázek, datum vystavení, klíčová slova, kategorii článku, perex, obsah článku, zobrazení těchto atributů bude volitelné autorem. U článku bude možné vybrat pro které části ePortálu se budou publikovat – veřejná/neveřejná/backoffice či kombinace částí portálu. Obsah článku bude vkládaný skrze WYSIWYG editor.
Ćlánky se budou vkládat/editovat/publikovat/odstraňovat v rámci backoffice prostředí a následně budou publikované v rámci vybraných prostředí. Publikaci bude možné odložit, omezit její platnost. Vkládat aktuality bude příslušná role v rámci systému rolí. Bude rovněž možné duplikovat existující články a na základě duplikátu vytvořit nový článek za pomocí editace duplikovaného článku.
Články budou mít verzovatelné, tedy bude se ukládat historie článků a bude možný návrat k původním verzím článku. U článku bude možné nastavit vlastní URL.
Články bude možné provázat na notifikace, resp. zvolit, zda při publikaci dojde k notifikaci vybraným
uživatelům o novém článku
Pro veřejnou část portálu budou existovat články typu Životní situace. Ty budou se standardizovanou strukturou sloužit k informování občanů o řešení své životní situace u Zadavatele nebo jeho příspěvkové organizace. V rámci dodání bude Dodavatelem vytvořeno 20 článků životních situací. Další
články bude vytvářet Zadavatel na základě dokumentace a školení Dodavatele duplikací existujících životních situací a jejich úpravou.
2.3.3 modul elektronické formuláře
Modul elektronické formuláře bude obsahovat editor formulářů a prohlížeč formulářů. Modul bude řešen jako webové řešení s návrhem a zobrazením formulářů v rámci UI ePortálu, není možný redirect na jiný externí SW mimo ePortál či doménu.
Formuláře budou k dispozici v neveřejné části ePortálu a budou tvořeny v backoffice části. Formuláře bude možné v rámci seznamu formulářů neveřejné části ePortáu členit do více úrovní dle příjemce nebo kategorie.
Editor formulářů bude realizovat grafické vytvoření formuláře a jeho kolonek. Editor bude fungovat v režimu návrhu a v režimu náhledu na hotový formulář. V rámci editace bude docházet k návrhu formuláře a v rámci náhledu bude možné sledovat formulář a jeho chování ve stejné podobě jako v prohlížeči formulářů.
V rámci kolonek bude možné navázat tyto atributy na existující dostupné atributy ePortálu (např. údaje přebírané z NIA/ISDS., údaje přebírané z některého modulu ePortálu). Tyto atributy by následně byly vyplňovány v rámci prohlížeče automaticky z daného datového zdroje.
U kolonek bude možné nastavit jejich masku v rámci vytvoření a editace kolonky. Masky budou obsahovat předdefinované masky (např. telefon, e-mail, jméno, adresa, PSČ apod.) a v případě, že v rámci prohlížeče bude následně uživatel vkládat údaje ve špatném formátu, bude na to upozorněn a vyzván k jejich opravě, nebude možné formulář s těmito špatně vloženými údaji odeslat.
U kolonek bude možné stanovit, zda se jedná o povinně vyplňované kolonky nebo volitelně vyplňované. U povinně vyplňovaných pak nebude v rámci prohlížeče možné odeslat formulář bez jejich vyplnění. Formuláře umožní vkládání log a jiných grafických či HTML prvků.
U formuláře bude nastavitelný příjemce formuláře, resp. spisová služba příjemce. Příjemce formuláře bude vždy minimálně jeden. Pokud bude příjemců více, bude možné navolit, zda je příjemce povinný či nepovinný, případně určit omezovací kritéria, kolik příjemců musí uživatel vybrat (např. minimálně jednoho).
Formulář by měl umožnit podpis formuláře přes elektronický podpis – konkrétní detail bude řešit implementační analýza. Tento požadavek (podpis formuláře) bude zadáván v rámci konfigurace formuláře.
Formuláře bude možné ukládat, editovat, mazat, publikovat. Bude rovněž možné duplikovat existující formuláře a na základě duplikátu vytvořit nový formulář za pomocí editace duplikovaného formuláře. Publikace bude probíhat do neveřejné části ePortálu, bude možné omezit přístup k formulářům na základě rolí.
Prohlížeč formulářů umožní obdobně jako náhled v rámci editoru formuláře zobrazení formuláře a vyplnění jeho kolonek.
Uživateli bude po vybrání formuláře k vyplnění zobrazen daný elektronický formulář, který následně vloží po odsouhlasení uživatele automaticky doplňované údaje z dostupných zdrojů. Pokud nebudou tyto údaje k dispozici, bude možné je vyplnit uživatelsky, avšak tyto atributy budou obsahovat v metadatech informaci, že se jedná o uživatelem vkládané údaje.
Při vyplňování bude uživatel upozorňován na špatně zadávané údaje za pomocí masek kolonek formuláře. Po vyplnění formuláře před jeho odesláním dojde k automatické kontrole a v případě, že nebudou vyplněny povinné údaje a/nebo budou kolonky vyplněny ve špatném formátu, bude vyzván uživatel k nápravě s vyznačením chyb a upozorněním na chyby. Součástí podávaného formuláře mohou být přílohy. K formuláři tedy bude možné přiložit přílohy, přičemž pole pro přílohu rovněž půjde vyznačit jako povinné, stejně jako kolonky formuláře.
Při vyplňování formuláře bude možné si formulář uložit v rozpracovaném stavu a později se k němu vrátit, pokud bude v té době formulář stále platný nebo nebude stanoveno časové omezení k návratu do formuláře.
Před odesláním může být uživatel vyzván k podpisu. Dále uživatel obdrží informaci o příjemcích formuláře, přičemž je-li příjemců více, může vybrat jednoho či více příjemců formuláře (na základě konfigurace formuláře). Typickým příkladem může být unifikovaný formulář pro školská zařízení, kdy uživatel vybere konkrétní školské zařízení ze seznamu škol, které má formulář obdržet.
Formulář bude následně odeslán ePortálem do spisové služby dané organizace či organizací (spisové služby Ginis nebo Geovap). Konkrétní detail publikace formuláře vč. kanálu bude řešit implementační analýza. Formuláře budou zasílány jako strojově čitelné soubory v otevřeném formátu, předpoklad je .csv nebo .xml.
Specifickými budou formuláře související s dotacemi, ty budou kromě standardní cesty podání předání skrze integraci do modulu administrace dotací, kde budou následně vytěžovány a administrovány.
Pro tyto specifické formuláře bude rovněž umožněno, aby byly uživateli navráceny administrátorem dotace z backoffice části portálu. V takovém případě se formulář objeví v seznamu rozpracovaných formulářů, ale bude vyznačen jako vrácený k opravě. Případně bude takto vyznačen v rámci historie podání – bude řešeno implementační analýzou. Uživatel bude o tomto notifikován. Následně bude mít možnost tento formulář opravit a zaslat zpět k opětovné kontrole.
2.3.4 modul platby
Modul platba bude obsahovat funkcionality editor plateb a zadávání plateb. Modul umožní návrh šablon elektronických plateb a přebírání údajů do platební brány s následnou možností zaplatit uživatelem skrze platební bránu v ePortálu.
Editor plateb bude fungovat v backoffice části ePortálu a hotové šablony plateb budou přebírány do neveřejné části, kde budou přes zadávání plateb realizovány.
Editor plateb umožní nastavit jednotlivé platby s předvyplněním atributů plateb (číslo účtu, název platby, částku, variabilní, specifický či konstantní symbol apod.), tyto atributy mohou být následujících typů:
• Zadané správcem
• Přebírající údaje uživatele z dostupných údajů
• Zadávané uživatelem
• Vybírané uživatelem přes listbox
Atributy zadá správce modulu (Zadané správcem) nebo budou vázány na uživatelské údaje, které se budou doplňovat automaticky, obdobně jako u formulářů z dostupných dat o uživateli (Přebírající údaje uživatele z dostupných údajů). Dalším typem atributu platby bude atribut k doplnění uživatelem,
který vyplní uživatel (Zadávané uživatelem). Zde bude obdobně jako u formulářů nasazen systém šablon, který bude kontrolovat správnost formátu zadávaných dat. Posledním typem je atribut, který uživatel vybere skrze rozevírací seznam (Vybírané uživatelem přes listbox), možnosti ze seznamu bude zadávat správce v rámci vytváření plateb.
Následně po vytvoření platby (šablony platby) vypublikuje platbu správce přes editor do neveřejné části ePortálu. Platby bude opět možné v rámci neveřejné části vázat na uživatelské role.
Zadávání plateb je funkcionalita v rámci neveřejné části portálu, která umožní uživateli dospecifikovat platbu (uživatelsky doplňované nebo vybírané atributy platby) a platbu následně provést přes platební bránu, do které bude takto dospecifikovaná šablona platby zaslána.
Platby (šablony plateb) budou v rámci neveřejné části portálu kategorizovány do více úrovní obdobně jako u formulářů, bude je možné kategorizovat dle typu platby, příjemce či jiného kritéria Zadavatele.
ePortál bude podporovat platební brány Comgate, Gopay, PayU s možností změny platební brány v rámci realizace projektu nebo rozvoje v rámci servisních prací na ePortálu. Platební bránu bude zajišťovat Zadavatel.
2.3.5 modul sledování podání
Modul sledování podání umožní uživateli v neveřejné části ePortálu sledovat stav podání, které učinil přes ePortrál v rámci modulu elektronické formuláře. Údaje o stavu podání budou přebírány ze spisových služeb (přijato, zpracováváno, předáno, uzavřeno apod.). Stavy podání budou k dispozici v rámci seznamu podání. Na změnu stavu podání bude možné navázat notifikaci. V rámci sledovaného podání bude k dispozici podávaný dokument, který byl předán do spisové služby a bude možné jej stáhnout daným uživatelem z ePortálu.
2.3.6 modul historie plateb
Modul historie plateb bude přebírat realizované platby a zobrazovat je ve formě přehledného seznamu v sekci neveřejné části ePortálu. Seznam bude obsahovat stav platby (neúspěšná, dokončená apod.) a veškeré údaje dané platby (typ platby, částka, příjemce, VS, SS, KS, datum a čas platby, poznámka apod.).
K platbám bude možné administrátorem přiřadit stav „zaúčtováno“, který se propíše do neveřejné části ePortálu k historii platby. Stav zaúčtováno bude možné řešit importem s ID platby. Konkrétní detail bude analyzovat implementační analýza. Zvažované je rovněž přebírání stavu platby (zaúčtováno) do historie plateb přímo z IS Ginis Zadavatele, tuto možnost bude řešit implementační analýza.
2.3.7 modul administrace dotací
Modul administrace dotací bude sloužit k administraci dotací, které poskytuje nebo zprostředkovává Zadavatel. Modul bude řešit administraci dotací vč. vedení jednotlivých dotací, sběru žádostí, hodnocení žádostí, vytváření dokumentů k dotacím a výstupních sestav. Z modulu bude rovněž možné provádět vytěžování dat do exportního souboru v otevřeném formátu.
Administrace dotací bude striktně fungovat v rámci backoffice části ePortálu a přístup do něj bude mít pouze uživatelská role s definovanými oprávněními.
Modul bude přebírat vstupní formuláře žádostí o dotaci od uživatelů z neveřejné části portálu. Tyto žádosti budou v rámci administrace kontrolovány a schvalovány. V rámci hodnocení žádosti bude možné vrátit uživateli formulář s chybami vč. vyznačení chyb s průvodní informací k vrácenému formuláři. Formulář bude moci uživatel zaslat v rámci workflow procesu zpět opravené k opětovné kontrole.
Formuláře se budou vázat na jednotlivé dotace, které budou v ePortálu vedeny jako datové objekty, které bude možné dále sdružovat do skupin – např. program s více dotacemi. Data z formulářů bude možné v rámci modulu selektovat a vytěžit, čímž je bude možné přebírat do dalších číselníků modulu.
Pro uživatele neveřejné části budou kromě formulářů k dispozici články s aktuálně vypsanými dotacemi, které budou rovněž obsahovat odkaz na vyplnění formuláře žádosti o dotaci (modul elektronické formuláře), dále přílohy článku (provázání na sekci dokumenty) a k novým dotacím budou vznikat aktuality (modul aktuality). Vypsání nové dotace, její změna nebo upozornění na termín podání žádosti budou vázány na notifikace ePortálu.
2.3.8 modul uživatelská statistika
Uživatelská statistika bude k dispozici v neveřejné části ePortálu a backoffice části ePortálu. Statistika bude prezentovaná ve formě přehledného interaktivního dashboardu s odkazem na část ePortálu se zdrojovými daty statistiky, např. při kliknutí uživatele na statistiku podaných formulářů bude přesunut do sekce historie podání. Statistika uživatele by měla být zobrazena po přihlášení uživatele v rámci dashboardu úvodní strany neveřejného a backoffice prostředí.
Typickými statistikami pro uživatele neveřejné části mohou být – počet přihlášení do ePortálu, poslední přihlášení, počet podaných formulářů, počet realizovaných plateb, zaplaceno celkem a podobně.
Statistiky pro uživatele backoffice prostředí budou záviset na typu uživatele, resp. jeho roli. Statistiky budou řešeny v návaznosti na navrhované funkcionality v rámci implementační analýzy.
Statistiky bude možné konfigurovat šablonově administrátorem v backoffice části ePortálu. Šablony navrhne v rámci realizace Dodavatel, Zadavatel následně bude mít možnost vytvářet další uživatelské statistiky. U statistik bude možné určit výchozí statistiky, které se budou zobrazovat v návaznosti na typ uživatele a jeho prostředí. Správce bude mít možnost jednotlivá pole statistik přidat, odstranit, konfigurovat nebo skrýt.
2.3.9 modul výstupy z datového skladu
Modul by měl umožnit na základě známých údajů o uživateli v neveřejné části portálu dotazování datového skladu Zadavatele na disponibilní soubory, které se vážou k danému občanovi či firmě. Těmito soubory by měly být primárně uzavřené smlouvy Zadavatele s občanem/právnickou osobou.
Výpis těchto souborů by následně měl být uživateli k dispozici a soubory by mělo být možné stáhnout, přičemž stažení dokumentu z datového skladu bude zajišťovat ePortál skrze integraci.
Pro uživatele backoffice části by měl modul umožnit fulltextové či atributové dotazování, na základě kterého by uživatel obdržel seznam výsledků – souborů v datovém skladu, které by odpovídali parametrům vyhledávání. Tyto soubory by následně měl uživatel možnost stáhnout obdobně jako uživatel neveřejné části smlouvu.
2.3.10 modul výstupy z digitálního repozitáře
Modul bude sloužit k přebírání výstupů z aplikace digitální repozitář, která je pořizována souběžně s projektem ePortálu. Digitální repozitář vede digitalizované informace o sbírkových předmětech ve formě metadat nebo jako související přílohy. Modul bude dostupný pouze v rámci backoffice části ePortálu.
Modul bude umožňovat dotazování se aplikace repozitář na datové objekty aplikace přes realizovanou integraci na digitální repozitář. Dotazování bude realizované jako fulltextové vyhledávání a dále jako parametrizované vyhledávání podle atributů. Atributy vyhledávání budou obsaženy ve formě tzv. šablon vyhledávání. Šablony vyhledávání budou selektovatelné uživatelem a dle vybrané šablony se uživateli zobrazí množina atributů, která je relevantní vůči typu datového objektu (např. stavební dokumentace, numismatika apod.). ePortál musí umožňovat tvorbu šablon a přidávání nových atributů vyhledávání do ePortálu administrátorem skrze administraci ePortálu.
Modul bude uzpůsoben pro dva typy uživatelů – expertní uživatele (badatele) a standardní uživatele. Expertní uživatel nebude mít nijak limitované vyhledávání, standardní uživatel může mít omezené možnosti, respektive vyhledávání bude v rámci UI uživatelsky uzpůsobeno s cílem jednoduchého vyhledávání.
Po potvrzení vyhledávání se ePortál skrze integraci dotáže aplikace digitální repozitář, která ePortálu vrátí seznam relevantních záznamů (datových objektů). Výsledky bude možné seřazovat na základě jejich atributů – ID, velikost, název, popis apod. U těchto objektů bude k dispozici tlačítko pro stažení datového objektu.
Expertní uživatel bude mít dvě možnosti stažení datového objektu, a to kompletní stažení objektu ve formě metadat dle OAIS a dále zjednodušené agregované stažení datového objektu. V obou případech po kliknutí na příslušné tlačítko dojde k zaslání informace digitálnímu repozitáři, který vrátí ePortálu příslušný soubor, jenž si následně uživatel stáhne. Standardní uživatel bude mít k dispozici pouze možnost stažení agregovaných dat o datovém objektu.
Šablona vyhledávání
Fulltext search
Fulltextové vyhledávání a
výběr šablony
atributového vyhledávání
Název
Rok
Typ
ID
Nově definovaný atribut
Kategorie1 Kategorie 2
Kategorie 3
Numismatika
Stavební dokumentace budov
...
...
...
….
...
Hledej
Atributové vyhledávání
Výsledky vyhledávání
Název
Velikost
Popis
Stažení
Metadata stažení OAIS (pro datové experty)
Položka 1
Položka 2
Položka 3
Položka 4
112MB
popis
Stažení
Stažení kompletní sady
Obrázek 3 - Ilustrační prezentace úrovní modulu
2.3.11 modul dokumenty
Modul umožní nahrávat dokumenty v rámci backoffice části a přístup k nim v rámci všech prostředí ePortálu. Přístup k dokumentům bude omezen na základě prostředí a uživatelských rolí.
Přes UI portálu bude možné vkládat libovolné soubory, primárně textové dokumenty ve formátech
.pdf a .docx. K dokumentům bude možné vkládat metadata – název a popis dokumentu. Bude možné kromě omezení přístupu k dokumentu nastavit platnost dokumentu, tedy dobu, po kterou bude možné dokument stáhnout.
Uživatelé budou mít k dokumentům přístup v rámci přehledné sekce, kde bude možné dokumenty sdružovat podle různých kritérií – např. určení, typ dokumentu. Dokumenty bude možné seřazovat na základě jejich atributů – čas vložení, velikost, název apod.
Dokumenty vložené na ePortál přes modul dokumenty bude možné vkládat do aktualit a článků, případně je dále vkládat do struktury stránek ePortálu přes WYSIWYG editor.
2.3.12 modul uživatelská administrace
Modul umožní administraci nastavení samotnému uživateli dle dostupných oprávnění v rámci
přiřazené role. Uživatelská administrace bude přístupná z menu. V rámci neveřejné části je předpoklad
nastavení notifikačních kanálů a jejich výběr pro realizaci notifikace. Dále by měla administrace umožnit změny v disponibilních modulech, např. označení aktualit jako přečtených, skrytí atributů v uživatelské statistice a podobě. Celkový výčet nastavení bude navržen dodavatelem v rámci implementační analýzy na základě podoby cílové funkcionality a schválen Zadavatelem.
2.3.13 modul administrace modularity
Modul umožní přístup k nastavení konkrétního modulu, tj. obdobně jako v modulu administrace ePortálu, ale s omezením na dané moduly, ke kterým bude mít uživatel nastavenou roli.
2.3.14 modul administrace ePortálu
Administrace ePortálu bude k dispozici v rámci backoffice části ePortálu a může se jednat o separátní prostředí nebo může být součástí backoffice, pouze s omezením na roli administrátora, vhodné řešení navrhne dodavatel v rámci implementační analýzy.
Administrace bude sloužit ke konfiguraci všech modulů na úrovni administrátora dle funkcionalit daného modulu. Kromě konfigurace modulů bude administrace sloužit k systémovému nastavení ePortálu. Minimálně musí řešit následující konfigurace:
• Log management ePortálu a zasílání logu do centrálního log managementu – log management
bude řešen v souladu s požadavky na výčet logů pro KIVS.
• Zálohování ePortálu a statistiku záloh, vč možnosti automatického spuštění záloh
s nastavitelnou frekvencí
• Revize a nastavení uživatelských rolí – jednou s možností je, že role bude ePortál řešit přebíráním z identity management aplikace Zadavatele, případně řešení, kdy role budou nastaveny v rámci IDM, ale ePortál bude mít řešené prohlížení rolí v administraci s možností změn, které se propíšou do IDM v rámci integrace. V detailu bude oblast uživatelských rolí řešit implementační analýza.
• Konfigurace a sledování integrací a notifikačních kanálů
• Konfigurace DB – bude-li součástí navrhovaného řešení databáze, administrace ePortálu by měla umožnit přístup do DB pro nahlížení, případně doplňování databáze zásahem administrátora ePortálu. V detailu bude tuto možnost řešit implementační analýza.
• Verzování CMS – administrátor bude mít dohled nad verzováním administrace ePortálu (CMS
– content managment systém), součástí může být systém aktualizací modulů či samotné administrace, ale konkrétní pojetí bude popisovat implementační analýza na základě cílového řešení.
2.4 Integrace
ePortál bude obsahovat integrační rozhraní, které umožní oboustrannou komunikacemi s IS a aplikacemi Zadavatele či třetích stran. Integrační rozhraní bude navrženo jako bezpečné a šifrované, logované a konfigurované pro partnerský IS/aplikaci.
Integrační rozhraní bude navrženo tak, aby umožňovalo v budoucnu realizaci integrace na další IS/aplikace, než jsou definované v rámci tohoto dokumentu a umožní rovněž konfigurace integrací pro případ, ve kterém dojde ke změně na straně IS/aplikace druhé strany.
Zadavatel zajistí Dodavateli dostupné API systému a aplikací, na které bude realizována integrace ePortálu a dále zajistí součinnost dodavatele aplikace/IS druhé strany v podobě konzultací realizace integrace mezi ePortálem a integračním rozhraním druhé strany.
V rámci nasazení ePortálu Dodavatelem budou realizované následující integrace:
2.4.1 Externí integrace
Níže je uveden požadovaný seznam integrací na SW třetích stran, které nejsou ve vlastnictví
Zadavatele:
• Integrace NIA – bude realizovaná integrace na Národní bod pro identifikaci a autorizaci. Tato integrace bude sloužit k přihlášení občanů, případně zástupců právnických osob či zástupců obcí do ePortálu.
• Integrace ISDS – bude realizovaná integrace na datové schránky, konkrétně bude umožněno důvěryhodné přihlašování s využitím ID datové schránky. Integrace bude sloužit k přihlášení občanů vlastnící datovou schránku, zástupců právnických osob či zástupců obcí do ePortálu.
• Integrace platební brány – v rámci ePortálu bude realizovaná integrace na platební bránu, přes kterou budou moci uživatelé neveřejné části portálu realizovat platby Zadavateli nebo příspěvkovým organizacím Zadavatele. ePortál bude podporovat minimálně platební brány Comgate, Gopay, PayU s možností změny platební brány v rámci realizace projektu nebo rozvoje v rámci servisních prací na ePortálu.
2.4.2 Interní integrace
Níže je uveden seznam požadovaných integrací na SW, které jsou ve vlastnictví Zadavatele:
• Integrace aplikace Chatbot – ePortál bude mít realizovanou integraci na aplikaci Chatbot, která je součástí Díla. Chatbot bude mít integrovanou klientskou aplikaci do UI ePortálu s instancí znalostní databáze v závislosti na části ePortálu (veřejná/neveřejná/backoffice). Prostřednictvím klientské aplikace bude chatbot přijímat zprávy od uživatele a odesílat mu odpovědi.
• Integrace na datový sklad Zadavatele – ePortál bude mít realizovanou integraci na datový sklad Zadavatele, ze kterého bude na základě uživatelského dotazování vracet seznam dostupných souborů a bude zprostředkovávat jejich stažení.
• Integrace na digitální repozitář Zadavatele – ePortál bude mít realizovanou integraci na vznikající digitální repozitář Zadavatele, ze kterého bude na základě uživatelského dotazování vracet seznam dostupných souborů (resp. datových objektů) a bude zprostředkovávat jejich stažení.
• Integrace na IS Ginis – bude realizovaná integrace na IS Ginis Zadavatele za účelem napojení na spisovou službu Ginis pro předání podání a získávání informace o stavu řešení podání (spisu). Zvažované je rovněž přebírání stavu platby (zaúčtováno) do historie plateb. Zadavatel má k dispozici integrační platformu Ginis XRG, která bude pro integraci využita.
• Integrace na spisovou službu Geovap – bude realizovaná integrace ePortálu na spisovou službu Geovap (která je využívaná příspěvkovými organizacemi) pro předání podání ePortálem a získávání informace o stavu řešení podání (spisu).
• Integrace na IDM/AD – bude realizovaná integrace na identity management aplikaci Zadavatele (produkt EOS firmy MARBES CONSULTING s.r.o.) pro SSO autentizaci do ePortálu, přebírání rolí z IDM a pro potřebu hierarchičnosti rolí a přístupů i organizační strukturu. Rovněž
může Zadavatel vyžadovat integraci na Azure Active directory (AAD) a Active directory (AD) v případě, že nebude možné plnohodnotně integrovat IDM. V takovém případě jsou k dispozici dvě AD – Zadavatele a příspěvkových organizací, typově dva různé produkty.
• Integrace na mail server a SMS bránu – bude realizovaná integrace na SMTP server a SMS Bránu Zadavatele, skrze které bude ePortál realizovat notifikace
2.5 Nasazení
ePortál bude nasazen on-premise v prostředí Zadavatele na infrastruktuře Zadavatele. K dispozici bude infrastruktura a technologický SW, který je dále popisován v rámci tohoto dokumentu.
Dodavatel nasadí ePortál ve třech prostředích:
• Vývojové prostředí – vývojové prostředí realizuje Dodavatel svými prostředky. V rámci prostředí garantuje bezpečnost SW a dat, pokud byla některá Zadavatelem již předána. Dále Dodavatel zajistí přístup Zadavatele do vývojového prostředí skrze zabezpečený přístup VPN pro možné ověřování funkcionalit vznikajícího ePortálu. Přístup Xxxxxxxxxx bude realizován po dohodě s Dodavatelem. Vývojové prostředí Dodavatele nebude dostupné ze sítě internet.
• Testovací prostředí – testovací prostředí bude realizováno Dodavatelem za součinnosti Zadavatele na infrastruktuře Zadavatele s využitím technologického SW Zadavatele a Dodavatele. Prostředí bude sloužit k otestování ePortálu a jeho částí. Po nasazení ePortálu do produkčního prostředí zůstane testovací prostředí zachováno a bude se využívat pro srovnávání s produkčním prostředím, pro nasazování aktualizací a nových funkcionalit, řešených v rámci rozvoje ePortálu. Přístupy k částem ePortálu budou vázány na autentizaci a nebudou volně přístupné.
• Produkční prostředí – produkční prostředí bude realizováno Dodavatelem za součinnosti Zadavatele na infrastruktuře Zadavatele s využitím technologického SW Zadavatele a Dodavatele. Prostředí bude sloužit pro cílový provoz ePortálu pro všechny koncové uživatele, jak na straně Zadavatele a jeho příspěvkových organizací, tak veřejnosti nebo autentizovaných z řad veřejnosti.
ePortál bude mít tři části, které Dodavatel vytvoří, ty jsou popsány v rámci kapitoly architektura. Tyto části (veřejná, neveřejná a backoffice) budou součástí každého z uvedených prostředí výše. Část backoffice bude oddělena na aplikační i síťové úrovni a bude se nacházet v jiných síťových perimetrech. Mezi částmi bude realizovaná zabezpečená integrace.
ePortál umožní nasazení na infrastruktuře v režimu vysoké dostupnosti, s detailem bude seznámen Dodavatel v rámci implementační analýzy.
2.6 Bezpečnost
ePortál bude nasazen v režimu zabezpečení na vysokou bezpečnostní úroveň dle vyhlášky č. 315/2021 Sb. Nastavení a garance bezpečnosti ePortálu bude popsána Dodavatelem v rámci implementační analýzy. Zabezpečení musí reflektovat princip security-by-design, který bude aplikován již při vývoji ePortálu, dále budou provedeny nezávislé bezpečnostní testy. Pro šifrování, které bude aplikované pro všechny části ePortálu bude platit, že budou využity pouze aktuální kryptografické prostředky, vykazující nízkou zranitelnost.
Bezpečnost bude i po nasazení pravidelně vyhodnocována v rámci servisní podpory, řešení bude aktualizováno pro zachování bezpečnosti ePortálu, jeho provozu a dat. Bezpečnost je dále popisována v kapitole Společné technické požadavky.
2.7 Požadavky na školení
K ePortálu budou realizovaná školení Dodavatele, a to dvě školení – uživatelské a administrátorské.
Administrátorské školení bude realizované jak pro administrátory celého ePortálu, tak pro administrátory jednotlivých modulů. Školení budou korespondovat s uživatelskou a administrátorskou dokumentací (uživatelská a systémová příručka). Součástí školení bude vytváření formulářů.
Uživatelské školení bude zaměřeno na ovládání backoffice části, ale rovněž bude realizované školení na neveřejnou část, aby byl Zadavatel schopen přenést znalost ovládání části dále k externím uživatelům.
Školení budou realizovaná lektorem Dodavatele v prostorách Zadavatele s možností účasti online. Školení se kromě zaměstnanců Zadavatele budou moci účastnit zástupci příspěvkových organizací Zadavatele, účast nebude Dodavatelem limitovaná. Předpokládaný rozsah školení je 24 hodin pro administrátorské školení a 8 hodin pro uživatelské školení. Školení bude možné rozdělit do více navazujících školení a cílová délka školen se bude odvíjet od cílové komplexnosti ePortálu, cílem je srozumitelné a kompletní seznámení uživatelů a administrátorů s ePortálem.
2.8 Požadavky na licence
K ePortálu bude předaná nevýhradní licence, početně a místně neomezená. Licence bude udělena Zadavateli a pro příspěvkové organizace Zadavatele. Současně předá Dodavatel licence k SW třetích stran, budou-li využity v rámci díla a rovněž předá licence k technologickému SW, které dílo bude využívat, tyto licence třetích stran budou Dodavatelem zajištěny minimálně na dobu 72 měsíců od akceptace díla.
3. Požadavky na funkcionality chatbota
Chatbot bude navržen jako aplikace umožňující přirozenou komunikaci s respondentem za využití NLP (Natural language processing). Bude možné jej implementovat do libovolného webového prostředí využívajícího standard HTML5. V rámci dodání bude nasazen v portálovém řešení ePortál Zlínského kraje. Chatbot bude nasazen on-premise na infrastruktuře Zadavatele. Chatbot bude schopen rozpoznávat větu, její kontext a dle toho reagovat s příslušnou odpovědí, případně se dotázat na upřesnění dotazu. Aplikace se z jednotlivých konverzací bude učit s využitím prvků umělé inteligence (AI) a bude kontinuálně zvyšovat úspěšnost odpovědí.
Aplikace chatbot bude řešena formou samostatných instancí, přičemž každá instance bude mít svoji
separátní znalostní databázi z důvodu bezpečnosti. V rámci dodání díla budou vytvořeny 3 instance:
• Instance veřejná část – instance bude obsahovat odpovědi na často kladené dotazy, bude schopna obecně a taxativně popsat jaké funkce umožňuje neveřejná část ePortálu a pomůže respondentovi s postupem autentizace do neveřejné části portálu.
• Instance neveřejná část – instance bude obsahovat informace veřejné části portálu a navíc bude disponovat znalostními okruhy dle funkcí neveřejné části portálu, díky kterým bude asistovat uživateli při využívání funkcí ePortálu. Bude asistovat při vyplnění formuláře vysvětlením typů atributů (uživatelské/předvyplněné, povinné/nepovinné), při jeho odeslání, pomůže uživateli s realizací platby přes platební bránu a pomůže uživateli s navigací v neveřejné části portálu, vč. asistence při uživatelské administraci – nastavení notifikačního kanálu a dalšího.
• Instance backoffice část – tato instance bude realizovaná pro interní část ePortálu, která bude oddělena na technologické úrovni od předchozích částí ePortálu a bude sloužit primárně pro navigaci uživatele.
Chatbot bude postavěn jako modulární aplikace skládající se z několika modulů. Požadované jsou
následující moduly:
• Modul klient – klientská aplikace pro komunikaci s respondentem. Bude realizovaná pomocí pop-up ikony, přičemž po kliknutí na ikonu se otevře okno s úvodní zprávou chatbota a konzolí pro vkládání textu. Po vkládání textu bude informace vyhodnocena chatbotem a dle shody klient vrátí respondentovi relevantní odpověď. V případě nerozpoznání dotazu požádá o upřesnění dotazu.
• Modul administrace – aplikace správce, v rámci které by měla být k dispozici možnost konfigurace chatbota, jeho úvodní věty, správa znalostní databáze a doplnění o nové znalostní okruhy a odpovědi. Administrace by měla rovněž obsahovat informace z monitoringu chatbota. Měla by správci zobrazit statistiky – počty konverzací, počty dotazů, nejčastěji kladené dotazy a statistika by měla rovněž zobrazit nezodpovězené dotazy nebo dotazy s malou mírou shody, na které následně bude možné reagovat doplněním znalostního okruhu do DB. Administrace bude rovněž umožňovat konfiguraci a administraci indexace webů.
Chatbot by měl umožnit notifikaci prostřednictvím SMS nebo e-mailem. Měl by poskytovat pravidelný denní report chatbota s výčtem denní statistiky, dále by notifikace sloužila k nahlášení nestandardních informací správci – nedostupnost chatbota, nepřiměřeně velké množství konverzací a související navýšení provozního výkonu, klíčová slova, která jsou v administraci vyznačená jako riziková apod.
Chatbot bude ukládat provozní historii konverzací. Historie bude dostupná přes administraci a bude možné nastavit frekvenci jejího výmazu. Při práci v neveřejné části a backoffice části by měl chatbot operovat s ID uživatele a rovněž jemu umožnit přístup k poslední realizované konverzaci. Chatbot by neměl operovat s osobními údaji a údaje, které vyhodnotí jako osobní by neměl dále zpracovávat, neměl by je ukládat do historie konverzace a zobrazit je v aplikaci klient jako anonymizované.
Indexace webů by měla pracovat tím způsobem, že chatbot bude vytěžovat weby a konkrétní stránky dle výběru administrátora. Primárně se bude jednat o portály Zadavatele a jeho příspěvkových organizací, ale může se jednat i o weby třetích stran. Chatbot by měl převzít informace z těchto webů, převést je ve znalosti a obohatit o ně odpovědi na dotazy uživatelů. V rámci administrace by měl být umožněn:
• výběr indexovaných webů,
• přidání nových indexovaných webů,
• ruční spuštění indexace,
• nastavení automatické indexace a její frekvence,
• zobrazení výsledků indexace,
• ke zvážení je možnost ručního přiřazení výsledků k odpovědi chatbota,
• administrace bude obsahovat report problémů indexace, na něž bude napojena i notifikace. Konkrétní řešení indexace bude ve větším detailu řešit implementační analýza.
3.1 Upřesňující požadavky
Technicky bude Chatbot plnit minimálně následující požadavky:
o standardní podpora českého jazyka (nabízené řešení musí disponovat oficiální podporou českého jazyka a Dodavatelem trénovaný, průběžné rozvíjený statistický model pro automatizované zpracování otázek klientů Zadavatele (tzv. Natural Language Processing – NLP))
o Zadavatel požaduje možnost zadávání úmyslů, resp. cílů našich klientů pomocí otázek zapsaných přirozeným, hovorovým českým jazykem (systém musí dále umožňovat tvorbu libovolných významových entit a jejich synonym, plně přizpůsobitelným požadované (libovolné) tématice), Tyto zadávané informace doplní informace získané indexací webů nebo informace z jiných datových zdrojů.
o grafické nástroje pro tvorbu a úpravu chatbota (Zadavatel požaduje grafické uživatelské prostředí pro kompletní tvorbu, ladění a testování chatbota, (je nutné, aby toto rozhraní bylo použitelné pro ne-programátory a umožnilo jednoduché a rychlé změny konverzační logiky)
o Indexace webů – chatbot musí umožnit indexování webů a obohacovat znalostní DB těmito informacemi.
o Využití modelu AI – chatbot bude využívat prvky umělé inteligence pro pochopení kontextu otázek klientů, výběru vhodné odpovědi a jejich kombinování, možnosti samoučení a zlepšování úspěšnosti odpovědi
o možnost rozvoje řešení o funkcionalitu umožňující jednoduché vytváření formulářů
pro přesné a úplné shromáždění potřebných dat v kontextu probíhající konverzace
s klientem, (v první fázi rozvoje řešení bude tato funkce používána pro anonymní klienty, v budoucí fázi projektu musí umožnit personalizovaný sběr dat s ohledem na již známá data o konkrétním přihlášeném klientovi) (realizace není součástí VZ).
o nástroje pro analýzu provozu – možnost kontinuálně získávat informace o uskutečněných konverzacích, úspěšných, resp. neúspěšných otázkách klientů Zadavatele umožňující kontinuální učení/zlepšování na základě předchozích konverzací (přímo ve vybrané konverzaci požadujeme možnost realizovat jednoduchým, grafickým způsobem dodatečné učení/tréning chatbota na námi definovanou správnou odpověď)
o řešení je součástí širší platformy umožňující snadnou rozšiřitelnost a další funkcionality. Koncepce umožní další budoucí rozvoj, z těchto důvodů Zadavatel požaduje, aby provozní platforma umožnila:
- Nasazení on-premise na infrastruktuře Zadavatele
- Nasazení v rámci webových stránek HTML5 (v rámci dodání na ePortálu Zlínského kraje)
- Email služba
- SMS služba
- možnost zabezpečeného připojení na existující tradiční tzv. „on-premise“ informační systémy
- aplikačně/integrační služby umožňující snadné volání externích funkcí a aplikační logiky.
- databázové a analytické služby pro statistické vyhodnocení úspěšnosti
komunikace s UI v rámci administrace
- možnost integrace na externí chatovací platformy, např. Facebook Messenger a další
- dostupnost chatbota musí být minimálně 99,5 % (na prostředcích Zadavatele) v režimu 24/7 a chatbot musí být schopen při plném vytížení schopen řešit paralelně až 100 konverzací s uživateli při reakční době na odpověď do 4 sekund
3.2 Požadavky na licence
Dodavatel k dílu předá nevýhradní časově, početně a místně neomezenou licenci. Licence bude udělena Zadavateli a pro příspěvkové organizace Zadavatele. Licence umožní nasazení díla v rámci dalších prostředí Zadavatele a jeho příspěvkových organizací a umožní modifikaci díla (minimálně nasazení dalších instancí chatbota s odlišnou znalostní DB). Současně předá Dodavatel licence k SW třetích stran, budou-li využity v rámci díla a rovněž předá licence k technologickému SW, které dílo bude využívat, tyto licence třetích stran budou Dodavatelem zajištěny minimálně na dobu 72 měsíců od akceptace díla.
3.3 Požadavky na školení
K chatbotovi budou realizováno administrátorské školení Dodavatele.
Bude realizované pro administrátory celé aplikace chatbot a pro správce jednotlivých funkcionalit. Školení budou korespondovat s uživatelskou a administrátorskou dokumentací (uživatelská a systémová příručka). Součástí školení bude vytváření a modifikace znalostní databáze, realizace indexování webů, analytika chatbota, nasazeni chatbota do HTML prostředí a jeho konfigurace.
Školení bude realizované lektorem Dodavatele v prostorách Zadavatele s možností účasti online. Školení se kromě zaměstnanců Zadavatele budou moci účastnit zástupci příspěvkových organizací Zadavatele, účast nebude Dodavatelem limitovaná. Předpokládaný rozsah školení je 10 hodin. Školení bude možné rozdělit do více navazujících školení a cílová délka školen se bude odvíjet od cílové komplexnosti chatbota, cílem je srozumitelné a kompletní seznámení administrátorů s chatbotem.
3.4 Požadavky na testy
Kromě testů popisovaných v kapitole Společné technické požadavky bude realizován Test znalostní DB a chování chatbota s cílem ověření komplexnosti znalostní DB chatbota a jeho schopnosti zodpovědět dotazy uživatelů.
Bude otestována úspěšnost zodpovězených dotazů při různém způsobu dotazování a bude rovněž otestována kompletnost znalostních okruhů chatbota. Testy bude realizovat testovací skupina složená ze zástupců budoucích uživatelů pro jednotlivá prostředí a při testech bude asistovat zástupce Dodavatele.
Testy budou realizovány ve dvou částech. První část proběhne dle scénářů, které připraví Dodavatel a schválí Zadavatel. Druhá část nezávislého ověření bude realizována náhodným testováním Zadavatele. Dle výsledku testů dojde k případným opravám, doplněním a optimalizacím chatbota a jeho znalostní databáze Dodavatelem.
4. Společné technické požadavky
4.1 Požadavky na dokumentaci a implementační analýzu
Implementační analýza bude popisovat Dílo do takového detailu, aby byla možná jeho realizace a zpracování Provozní dokumentace k Aplikaci (za Aplikaci je pro potřebu kapitoly společných technických požadavků označované výstupy Díla, tedy aplikace ePortál a chatbot) Dodavatelem.
Provozní dokumentace bude zpracovaná v souladu s požadavky zákona č. 365/2000 Sb., o informačních systémech veřejné správy, v platném znění, a vyhlášky č 529/2006 Sb., v platném znění, případně jí nahrazující vyhlášky č. 360/2023 Sb., v platném znění.
Obsahem Provozní dokumentace bude zejména:
• Bezpečnostní dokumentace informačního systému veřejné správy,
• Systémová příručka,
• Uživatelská příručka,
Dokumentace bude také obsahovat podrobný popis implementace. Tento popis bude součástí Systémové příručky nebo může být uveden v samostatném dokumentu. Veškerá dokumentace bude předána v elektronické podobě.
Implementační analýza musí obsahovat minimálně následující:
1. Implementační část – vznikne za součinnosti Zadavatele
• Řízení projektu:
- Administrativní údaje.
- Seznam kontaktních osob realizačního týmu (Dodavatel, Objednatel (pro
potřebu popisu kapitoly je za Objednatele označen Zadavatel)).
- Přístup k systému helpdesk.
• Popis průběhu implementace včetně podrobného harmonogramu implementace pro všechny části:
- Podrobný harmonogram popisující všechny fáze implementace.
- Plán kvalifikovaného seznámení obsluhy s dodaným dílem.
- Předání do testovacího provozu – kontrola dodaného řešení Objednatelem před sepsáním akceptačního protokolu
- Testovací provoz – kontrola dodaného řešení Objednatelem ve zkušebním provozu, který simuluje co nejvíce běžný provoz.
- Uvedení do produkčního provozu a sepsání protokolu o předání a převzetí díla.
- Podrobný harmonogram provedení testů Aplikace.
• Popis dodávaného řešení
- bude popsáno co, na kterých serverech a kde je nainstalováno, nastaveno, provázáno, jaké služby a úlohy v jaké časové intervaly a pod jakými účty jsou spouštěny. Stručný a věcný popis, minimálně červeně vyznačené části v systémové a bezpečnostní části. Podrobnější popis pak bude uveden ve finální systémové a bezpečnostní části. Části nevyznačeně červeně bude následně obsahovat dokumentace skutečného provedení k Aplikaci.
2. Systémová část:
• schéma a popis aplikační, systémové a síťové architektury a infrastruktury – topologie,
vazby, prostupy, servery, sítě, funkční bloky, popis struktury adresářů a databáze atd.
• Specifikace všech dodávaných HW a SW prvků, konfigurace jak hlavních, tak i jejich významných dílčích částí, popis funkce v rámci dodaného řešení.
• systémové požadavky pro běh Aplikace,
• Specifikace funkcionalit modulů Aplikace
• návrh a podrobný popis architektury Aplikace a propojení všech částí Aplikace (veřejná, neveřejná a backoffice část).
• návrh a popis všech komunikačních datových rozhraní příp. webových služeb, budou- li v řešení použity pro předávání dat mezi spolupracujícími systémy nebo
částmi/moduly Aplikace – aplikační nebo procesní integrace.
• nastavení proti přetěžování systému,
• popis existujících vazeb a integrací
- např. import organizační struktury, rolí z IDM (aplikace EOS) – co, kdy, jak, kým apod.
• podporované standardy při integraci systémů
- datové, systémové, bezpečnostní apod.
• možnosti zajištění rozšíření stávající funkcionality pro potřeby integrovatelnosti
aplikace s okolními systémy
• seznam použitých technologií (např. ASP, PHP, XML, JavaScript, jQuery…)
• režim správy Aplikace (kdo, co spravuje)
• princip aktualizace
• plány nasazování aktualizací, podle nichž budou průběžně vydávané záplaty testovány a následně aplikovány na IS
• seznam licencí i free licencí a jejich parametry (licenční smlouvy budou separátní
dokumenty)
3. Bezpečnostní část - popis realizovaných bezpečnostních opatření, mechanismů a jejich
návazností:
• popis veškerých metod přístupů např.: aplikace přistupuje k DB – bude uveden účet a odkaz na umístění hesla, četnost (pokud jde o relevantní údaj) apod.
• popis autorizace a autentizace uživatele
• popis uživatelských rolí, jejich oprávnění
• popis správy uživatelů
• logování operací a chyb – kam se loguje, kde se nastavuje úroveň logování, co se loguje
v návaznosti na bod l kapitoly bezpečnostní požadavky);
• popis zálohování - co, jak často, na jak dlouho, kam, jakým způsobem atd., a obnovy,
disaster recovery scenáře
• popis a návod k využívání bezpečnostních funkcí (pokud jsou implementovány), vztah k jednotlivým rolím, k činnosti správce (záleží na typu a účelu aplikace, např. doba timeout session, zasílání SMS při určitých akcích, kdo může prohlížet logy, spouštět synchronizaci apod.)
• popis naplnění doporučení OWASP Top10, jedná-li se o webovou aplikaci
Kontrolní analýza, která bude realizovaná před předáním díla do prostředí Objednatele naváže na implementační analýzu a vyznačí v rámci ní změny, případně doplněné, došlo-li k rozšíření funkcionalit. Rovněž doplní nové požadavky na implementaci, pokud takové nastaly. Kontrolní analýza bude dodaná ve dvou verzích – s revizí původních textů implementační části (změny, doplnění) a jako čistopis.
4.2 Požadavky na testy
Dodavatel bude realizovat k Aplikacím následující testy, z nichž budou vyhotoveny protokoly, které budou předány Objednateli.
4.2.1 Performance testy
Performance testy budou realizovány pro vývojové prostředí Dodavatele a testovací prostředí Objednatele, v rámci testu bude ověřena odezva systému a vytížení HW, testy budou realizovány při simulaci vysokého vytížení. Následně budou tyto testy opakovány na produkčním prostředí v rámci pilotního provozu pro ověření, že hodnoty jsou oproti testovacímu prostředí nezměněny nebo lepší. Cílem je ověření, že hodnoty výkonu dosahují požadovaných v kapitole Požadované technické parametry dostupnosti a výkonnosti.
Dostupnost – Za dostupnost infrastruktury je odpovědný Objednatel, avšak za dostupnost samotné aplikace dle SLA je odpovědný Dodavatel. Pokud dojde v rámci testu k omezení dostupnosti chybou typu blackbox, kdy nebude patrné, proč není Aplikace dostupná, bude situace řešena analytickými silami obou stran za vzájemné součinnosti.
Výkonnost – Za optimalizaci řešení pro požadovanou zátěž je odpovědný Dodavatel.
4.2.2 Funkční testy
Pro funkční testy vytvoří Dodavatel testovací scénáře a bude je realizovat společně se Objednatelem. Z funkčních testů vznikne seznam případných zjištění – vad, které Dodavatel odstraní a následně se provede další iterace funkčních testů. Testy budou realizované pro všechna prostředí a scénáře budou reflektovat funkcionality daného prostředí.
4.2.3 Bezpečnostní testy
Dodavatel zajistí nezávislé bezpečnostní otestování Aplikace vč. všech jeho prostředí třetí stranou včetně penetračních testů v souladu s požadavky kapitoly Oveření bezpečnosti.
4.2.4 UX/UI testy
Dodavatel ve spolupráci se Objednatelem zajistí UX/UI testy prostředí Aplikace a provede úpravy podle zjištěných neoptimalit UX/UI portálu. UX/UI testování bude opakované ve vývoji, nasazení na testovacím prostředí a produkčním prostředí, bude ukončeno v rámci pilotního provozu. Dojde-li ke změně UI vlivem optimalizace, budou změny zaneseny do odpovídající dokumentace Aplikace.
4.2.5 Akceptační testy
Akceptační testy bude realizovat Objednatel. Testy budou probíhat ve dvou částech. První část proběhne dle scénářů, které připraví Dodavatel a schválí Objednatel. Druhá část nezávislého ověření bude realizována náhodným testováním Objednatele. V průběhu testů bude Dodavatel poskytovat součinnost na vyžádání.
Z obou částí vznikne seznam případných zjištění, které dodavatel odstraní. Cílem akceptačních testů je ověření funkčnosti řešení a ověření původních testů. Po úspěšném odstranění zjištění a potvrzení může pokračovat proces akceptace.
4.3 Umístění Aplikace a zajištění domén
• Administraci předmětných domén na úrovni DNS záznamů zajistí Zlínský kraj.
• Aplikace bude umístěna on-premise ve virtualizovaném prostředí technologického centra
Objednatele (TC KÚZK, TCK).
Požadovaná lokalizace
• Aplikace, všechny její části budou mít UI v českém a anglickém jazyce.
• Školení k aplikacím proběhne v českém jazyce, a to jak školení administrátorů, tak uživatelů.
• Veškerá dokumentace, vč. implementační analýzy, kontrolní analýzy, provozní dokumentace bude psaná v českém jazyce.
4.4 Přístupnost, podpora prohlížečů a responzivní zobrazení
• Aplikace musí splňovat všechny zákonné normy a standardy. Pro webovou aplikaci se jimi rozumí zvláště:
- Musí být v souladu se zákonem č. 99/2019 Sb., o přístupnosti webových stránek
(WCAG 2.1)
- ISVS 005/02.01 (xxxx://xxx.xxxx.xx/)
- HTML 5, CSS 3
- WAI-AA (xxxx://xxx.x0.xxx/XXX/) :
i. webové stránky: Web Content Accessibility Guidelines (WCAG)
ii. authoring tools: Authoring Tool Accessibility Guidelines (ATAG)
iii. prohlížeče: User Agent Accessibility Guidelines (UAAG)
iv. webové aplikace: Accessible Rich Internet Applications (WAI-ARIA)
- Metodika Bliend Ffrienly Web 2.3 (xxxx://xxxxxxxxxxxxx.xx/xxxxxxxx)
- Optimalizace pro SEO
Dodaná aplikace a šablony budou napsány tak, aby bylo možné provést SEO optimalizaci (jedná se především o možnost zadávání meta tagů, popiskům k netextovým prvkům, správná strukturu a sémantika, kanonické URL)
• Aplikace musí být optimalizována pro běžně používané internetové prohlížeče.
Podporovaná je vždy aktuální a jedna předchozí verze poslední vydané číselné řady prohlížeče:
• Desktop: Microsoft Edge, Google Chrome, Safari, Mozilla Firefox;
• Mobilní zařízení: Android browser, Google Chrome, Safari, Mozilla Firefox.
• Aplikace bude podporovat responzivní zobrazení, tj. zobrazení Aplikace se bude měnit podle velikosti displeje zobrazovacího zařízení, vč. podpory mobilních zařízení – tabletů a mobilních telefonů.
4.5 Legislativa
Řešení bude v souladu s platnou legislativou, minimálně pak musí plnit:
• veškeré požadavky plynoucí z právních předpisů ve vztahu k subjektu Objednatele, který je financován z veřejných zdrojů, zejména pak požadavky plynoucí z níže zmíněných právních předpisů
• Požadavky ze zákona zákonem č. 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ů.
• požadavky plynoucí ze zákona č. 99/2019 Sb., o přístupnosti internetových stránek a mobilních aplikací a o změně zákona č. 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ů
• požadavky plynoucí z 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ů)
• požadavky plynoucí ze zákona č. 127/2005 Sb., o elektronických komunikacích a o změně některých souvisejících zákonů (zákon o elektronických komunikacích), ve znění pozdějších předpisů – zejména v souvislosti s používáním tzv. cookies
• požadavky plynoucí ze zákona č. 106/1999 Sb., o svobodném přístupu k informacím, ve znění pozdějších předpisů
Dále musí dodavatel v rámci řešení dodržet směrnice Web Content Accessibility Guidelines (WCAG) 2.1
4.6 Požadované technické parametry dostupnosti a výkonnosti
Objednatel požaduje dodávku kvalitně provedeného a optimalizovaného software a nikoliv software, který bude nedostatečnou kvalitu návrhu a zpracování na úrovni kódu a procesů kompenzovat nepřiměřenými systémový prostředky a požadavky na ně směrem k objednateli za účelem dodržení odezvy a funkcionality systému.
Objednatel s ohledem na předpokládaný dlouhodobý provoz a životnost pořizovaného řešení požaduje, aby byla Aplikace postavena na současných, a nikoliv již překonaných/opouštěných technologiích, které zajistí dlouhodobou podporu daného řešení. Za překonané/opouštěné technologie jsou objednatelem považovány takové, u kterých v příštích 2 letech jejich tvůrce ukončí podporu jejich životního cyklu a dále takové, jejichž vývoj a podpora již byly ukončeny.
Pro nasazenou Aplikaci v době spuštění do pilotního provozu, stejně jako pro Aplikaci v provozu platí
následující požadované hodnoty:
• SLA (dostupnost Aplikace) 95 %
• Počet paralelně pracujících uživatelů 100
• První request (first byte) vyřízený do 300ms
• Maximální doba odezvy z Aplikace změřená službou xxxxxxxxxxx.xxx bude 2 sekundy na poskytnutých HW prostředcích KÚZK
• Maximální doba reakce chatbota na dotaz uživatele bude 4 sekundy na poskytnutých HW
prostředcích KÚZK při vytížení 100 paralelních konverzací
V rámci akceptačních testů bude Objednatelem provedena kontrola pomocí veřejně dostupné kontrolní služby na adrese xxxxx://xxxxxxxxxxx.xxx/ kdy bude vyžadováno splnění celkového načtení úvodní stránky do 2 sekund. V případě, že bude načtení delší, musí Dodavatel provést opravy s cílem splnění SLA bez omezení funkčnosti díla.
4.7 Šifrování a kryptografie
Komunikace mezi částmi Aplikace bude probíhat v šifrované podobě. Stejně tak veškerá uživatelská nebo citlivá data budou ukládaná šifrovaně a přístup k nim bude zabezpečený. Budou použity pouze
takové kryptografické prostředky, které nejsou prolomeny, jsou aktuální a schvalované ze strany NÚKIB
pro KIVS.
Kromě výše uvedeného musí Aplikace naplňovat rovněž níže uvedené minimální požadavky na
kryptografii, které vychází z aktuální best-practice a z doporučení NÚKIB.
Pro šifrování, elektronické podepisování a provádění otisků dat (hashování) nesmí být použity proprietární/uzavřené algoritmy, ale ty, které jsou považovány za standardy, jejich funkcionalita je všeobecně známá, popsaná a jsou všeobecně považovány za bezpečné.
Hashovací funkce – Ukládání otisků hesel
● pro ukládání hesel uživatelů mohou být použity pouze tyto tzv. pomalé hashovací funkce:
○ Argon2i
○ bcrypt
○ scrypt
○ PBKDF2
● při hashování hesla musí být použit pseudonáhodně vygenerovaný kryptografický salt
● pro ukládání hesel nesmí být použity tzv. rychlé hashovací funkce typu MD-X, SHA-X, apod. Hashovací funkce – Elektronické podepisování e-mailů a dokumentů
● SHA-2 a vyšší
● délka otisku 256 bitů a vyšší
Hashovací funkce – Ověřování integrity souborů
● SHA-2 a vyšší
● délka otisku 224 bitů a vyšší
V rámci akceptačních testů bude Objednatelem provedena kontrola pomocí veřejně dostupných kontrolních služeb xxxxx://xxx.xxxxxxx.xxx/, xxxxx://xxx.xxxxxxxxxxxxxxx.xxx/ a xxxxx://xxxxxxxxxxx.xxxxxxx.xxx/, kdy bude vyžadováno splnění alespoň úrovně A.
Kryptografie
Je vyžadováno:
● verze protokolu minimálně TLSv1.2 a vyšší
● cipher suite musí být vybrána na základě serverem preferovaného pořadí
● vyšší priority musí mít cipher suites, které obsahují varianty asymetrických algoritmů s eliptickými křivkami, např.:
○ ECDHE musí mít vyšší prioritu než DHE
○ ECDSA musí mít vyšší prioritu než DSA
● všechny EXPORT cipher suites musí být zakázány
● algoritmy a funkce pro výměnu klíčů
○ algoritmus pro výměnu klíčů musí podporovat Perfect forward secrecy
■ tzn., že šifrovací klíč je vyměněn mezi klientem a serverem tak, aby jej nebylo možné získat se znalostí privátního klíče serveru, např. musí být použit Diffie- Hellman (DH nebo ECDH) algoritmus
■ a navíc se musí jednat o tzv. ephemeral Diffie-Hellman (DHE, ECDHE), tzn. že pro každou session je generován nový set Diffie-Hellman klíčů
○ délky klíčů:
■ pro Diffie-Hellman (DH) - je preferováno 3072 bitů, ale v odůvodněných případech je možné využít 2048 bitů
■ pro Elliptic Curve Diffie-Hellman (ECDH) – 256 bitů a více
○ nesmí být použita anonymní výměna klíčů
● algoritmy a funkce pro autentizaci
○ minimální délky klíčů:
■ RSA – je preferováno 3072 bitů, ale v odůvodněných případech je možné využít 2048 bitů
■ ECDSA - 256 bitů
■ algoritmy a funkce pro symetrické šifrování
● nesmí být použita hodnota NULL v cipher suites
● nesmí být použity tyto šifry:
○ DES, 3DES, RC4
● minimální délka šifrovacího klíče - 128 bitů
● cipher suites s šiframi s větší délkou klíče musí mít větší prioritu v seznamu ciphersuites než s menší délkou klíče
■ MAC (Message Authentication Code)
● použití SHA funkce s minimální délkou hashe 256 bitů
● vyšší délky otisků musí mít vyšší prioritu v cipher suites
■ Způsob naplnění:
● Diffie-Hellman implementace: xxxxx://xxxxxx.xxx/xxxxxxxx.xxxx
Certifikáty
● minimální délka privátního klíče
○ RSA 2048 bitů
○ ECDSA - 256 bitů
● hash funkce pro podpis
○ SHA-2 s minimální délkou 256 bitů
● v případě veřejně publikované webové aplikace
○ certifikát musí být vydaný důvěryhodnou certifikační autoritou, bude rozpracováno
v rámci prováděcí dokumentace
○ je možné použít multi-domain certifikát, ne však wildcard certifikát
Asymetrická kryptografie – TLS cipher suites
● Doporučené cipher suites (v doporučeném pořadí), které naplňují výše zmíněné požadavky
● TLS1.3: TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256 TLS_AES_128_CCM_SHA256
● TLS1.2: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
Šifrování, podepisování a autentizace
● týká se různých technologií PKI, PGP, S/MIME, SSH, apod.
● minimální délka klíče
○ algoritmus DSA – je preferováno 3072 bitů, ale v odůvodněných případech je možné využít 2048 bitů
○ algoritmus RSA – je preferováno 3072 bitů, ale v odůvodněných případech je možné využít 2048 bitů
○ algoritmus ECDSA - 256 bitů
● Ověřování (např. SSH klíče)
○ délka klíče u RSA a DSA algoritmů je preferováno 3072 bitů, ale v odůvodněných případech je možné využít 2048 bitů
○ délka klíče minimálně 256 bitů u algoritmů používajících eliptické křivky
Symetrická kryptografie
● nesmí být použity tyto šifry:
○ DES, 3DES, RC4, Blowfish, Kasumi
● minimální délka šifrovacího klíče - 128 bitů
○ pro šifru Chacha20 minimálně 256 bitů a se zatížením klíče menším než 256 GB
● nesmí být použity tyto módy pro ochranu integrity:
○ HMAC-SHA1, CBC-MAC-X9.19
HTTP hlavičky webového serveru
Webový server musí být nakonfigurován tak, aby zajišťoval maximální možnou míru bezpečnosti informační a naplňoval minimálně následující požadavky na bezpečnostní http hlavičky:
● X-Frame-Options
○ Musí být implementována (tzn. server ji musí klientské aplikaci zasílat)
○ Záhlaví může nabývat pouze hodnot DENY nebo SAMEORIGIN dle potřeby
● Strict-Transport-Security
○ Musí být implementována
○ Direktiva xxx-age musí nabývat hodnoty minimálně 31536000
○ Ostatní direktivy jsou volitelné
● Content-Security-Policy
○ Musí být implementována
○ Nesmí obsahovat direktivy unsafe-inline, unsafe-eval
○ Aktiva mohou být načítána pouze prostřednictvím zabezpečeného protokolu
(direktiva https:)
○ Aktiva mohou být načítána pouze z konkrétních a bezpečných zdrojů
○ Pokud by bylo nutné načítat aktiva z jiných zdrojů, které nejsou umístěny na infrastruktuře Objednatele či infrastruktuře Dodavatel, je nutné nejprve schválení Objednatelem. Bez schválení nemohou být tyto zdroje použity k načítání aktiv.
● X-Content-Type-Options
○ Musí být implementována
● Referrer-Policy
○ Musí být implementována
○ Nesmí obsahovat direktivy: prázdný string, unsafe-url
● Permissions-Policy
○ Musí být implementována
○ Mohou být povolena pouze ta oprávnění, která jsou skutečně potřeba, všechna ostatní musí být explicitně zakázána
● X-XSS-Protection
○ Musí být implementována
○ Directiva politiky musí nabývat hodnoty 1; mode=block
● Server
○ Pokud je hlavička implementována, musí být změněna tak, aby neodhalovala citlivé
informace odhalující verzi webového serveru
● Set-Cookie
○ Pokud se jedná o session cookies, musí obsahovat direktivu nastavující secure a httponly flagy.
● Cross-Origin-Embedder-Policy
○ Musí být implementována
● Expect-CT
○ Musí být implementována
● Cross-Origin-Opener-Policy
○ Musí být implementována
● Cross-Origin-Resource-Policy
○ Musí být implementována
4.8 Společné bezpečnostní požadavky
● Pokud Aplikace zpracovává nebo umožňuje zpracovávat osobní údaje:
○ musí být v souladu s Nařízením Evropského parlamentu a Rady EU 2016/679 - obecné nařízení o ochraně osobních údajů – General Data Protection Regulation (GDPR).
○ musí splňovat všechny relevantní požadavky zákona 110/2019 Sb., o zpracování osobních údajů, které je možno zajistit technicky v Aplikaci. Aplikace bude např. automatizovaně pořizovat záznamy o operacích při zpracování osobních údajů v Aplikaci, dle ustanovení § 36.
○ v případě webových stránek bude v souladu s Doporučením pro webové stránky, které je definováno ve stanovisku č. 1/2011 Úřadu pro ochranu osobních údajů.
○ Řešení musí splňovat minimálně úrovně „A“ služeb pro ověření na adrese:
xxxxx://xxx.xxxxxxx.xxx/ xxxxx://xxx.xxxxxxxxxxxxxxx.xxx/ xxxxx://xxxxxxxxxxx.xxxxxxx.xxx/
● Aplikace musí mít nainstalovány všechny relevantní bezpečnostní záplaty již v době předání a stanoveny mechanismy pro implementaci aktuálních bezpečnostních záplat během provozu.
● U vstupních polí přístupných anonymním uživatelům (obsahuje-li je Aplikace) musí mít webová Aplikace implementovány antispamové ochranné mechanismy.
● Aplikace musí přistupovat do databáze (je-li součástí) jen prostřednictvím jednoho speciálního „společného“ účtu. (Není možno pro přístup do databáze používat účty
uživatelů.) Tento účet musí být odlišný od administrátorského účtu, který bude používán pro
správu / vzdálenou správu.
● Zajištění logování Aplikace bude dle 2. odst. §22 vyhlášky 82/2018 Sb., např. informace o činnosti uživatelů a administrátorů (přihlášení, odhlášení, manipulace s účty a oprávněními, úspěšné i neúspěšné pokusy činností, kritické i chybové hlášení apod.).
● V rámci logování bude zajištěna integrita informací pomocí adekvátních kryptografických prostředků (např. šifrování, el. podpis), aby bylo možné jednoznačně určit, kdo změnu / operaci provedl.
4.8.1 Další požadavky související s autentizací, autorizací a oprávněním
Pro interní uživatele Objednatele musí Aplikace (část backoffice u ePortálu, část administrace u
chatbota) umožnit následující:
● aplikace bude umožňovat import uživatelů, organizační struktury, rolí z identitního systému Objednatele (IDM – aplikace EOS) nebo Active Directory.
● aplikace bude umožňovat řízení přístupových oprávnění uživatelů (aplikačních rolí) a jejich správu z identitního systému Objednatele (IDM – aplikace EOS) nebo z Active Directory. Oprávnění přístupu k jednotlivým částem (min. na úrovni site) budou řízena pomocí členství ve skupině Active Directory;
● přebírat autentizaci uživatele ze systému MS Windows, tzn., že bude umožňovat přihlašování
single sign-on (SSO); ověřování pomocí bezpečného protokolu (Kerberos).
4.9 Ověření bezpečnosti
Aby mohl být informační systém zařazen do infrastruktury objednatele a akceptován, musí splňovat bezpečnostní opatření, která zajistí, že informační systém nebude vykazovat zranitelnosti při ověření penetračními testy minimálně dle metodiky OWASP Testing Guide, ve stable verzi 4.2 1.
Podmínkou pro akceptaci předmětu plnění je, aby žádný z případných nálezů penetračních testů neměl dle scoring systému CVSS v3.1 base score větší hodnotu než 3.9.
Objednatel si vyhrazuje právo provést penetrační test jakékoliv části předmětu plnění.
1 xxxxx://xxxxx.xxx/xxx-xxxxxxx-xxx-xxxxxxxx-xxxxxxx-xxxxx/x00/
Dodavatel se zavazuje, že v rámci vývoje Aplikace byly provedeny nezávislé penetrační testy minimálně dle metodiky OWASP Testing Guide, ve stable verzi 4.2 a odstraněny všechny nálezy před nasazením u Objednatele. Z testu bude doložen Objednateli protokol.
Během provozu Aplikace na KÚZK a smluvního vztahu s Dodavatelem zajišťuje Dodavatel Aplikace pravidelné penetrační testování minimálně jednou za rok v rámci interního vývoje. Aplikace bude testována minimálně dle metodiky OWASP Testing Guide, ve stable verzi 4.2. Dodavatel vyhotovuje záznamy o penetračním testování a výsledky předloží Objednateli.
Aplikace musí být chráněna proti známým bezpečnostním chybám a hrozbám, nejenom dle metodiky OWASP.
4.10 Zajištění bezpečnosti
Dodavatel je povinen zajistit bezpečný provoz dodávaného řešení. V případě zjištění zranitelnosti řešení, zejména v případě jejího zveřejnění a přidělení CVE označení, je Dodavatel povinen provést bezodkaladné opatření ke snížení dopadů takové zranitelnosti. Dále je Dodavatel povinen provést instalaci bezpečnostních záplat v termínech definovaných v tabulce služeb a SLA dle závažnosti CVE dle scoring systému CVSS v3.1 base score.
5. Parametry poskytnuté infrastruktury Zadavatele a poskytnuté technologie
Objednatelem poskytnutá virtualizační platforma v technologickém centru KÚZK
Zadavatel vyžaduje provoz systému v rámci technologického centra Zadavatele (TC KÚZK, TCK) ve
virtualizačním prostředí VMWare VSphere verze 7.
Pro potřebu nasazení a provozu Aplikace jsou navržené kapacitní možnosti pro všechny virtuální stroje (počet vCPU, velikost operační paměti, úložiště…) specifikovány následovně:
počet podporovaných vCPU | 24 |
velikost úložiště virtuálních strojů (OS, soubory s programovým kódem, logy apod, tzn. mimo obsahová uživatelská data pro prezentaci a zálohy) | 500 GB |
velikost operační paměti virtuálních strojů | 32 GB |
Požadavky na změnu parametrů je možné řešit se Zadavatelem, který v odůvodněných případech může parametry změnit. V takovém případě bude požadovaný počet a typ virtuálních serverů (počet jader, velikost paměti, zpropagovaná úložiště a přístupy do síťových prostředí) nastaven Zadavatelem v rámci správy svého virtualizovaného prostředí dle odsouhlaseného požadavku Dodavatele.
Operační systémy:
V oblasti operačních systémů (OS) Zadavatel nabízí možnost využití licencí OS Windows server 2022 Zadavatele pro provoz Aplikace. Nechává ale Dodavateli volnost v rámci dodávky i jiného řešení OS do té míry, do které si Dodavatel zajistí licence, bezproblémový provoz a správu OS na virtualizované platformě Zadavatele a současně jejich podporu ze strany jejich výrobce minimálně po dobu 72 měsíců od akceptace Aplikace.
Databázové prostředí:
V oblasti databázového prostředí Zadavatel nabízí možnost využití licencí MS SQL Server 2022 Zadavatele pro provoz Aplikace. Nechává ale Dodavateli volnost v rámci dodávky i jiného řešení databázového prostředí do té míry, do které si Dodavatel zajistí licence, bezproblémový provoz a správu databázového prostředí na virtualizované platformě Zadavatele a současně jejich podporu ze strany jejich výrobce minimálně po dobu 72 měsíců od akceptace Aplikace.
6. Doplňující informace
Uchazeč v rámci nabídky dodá vyplněnou přílohu č. 4 Smlouvy (Formulář plnění požadavků Zadavatele). V rámci této přílohy vyplní k jednotlivým požadavkům, převzatých z technické specifikace, zda tyto požadavky dodávané Dílo plní vyplněním ANO či NE. Do dalšího sloupce vyplní, jakým způsobem bude požadavek v rámci dodání plnit. Uchazeč takto vyplní všechna žlutě vyznačená pole ve všech listech dokumentu podle požadavků na Aplikaci. V případě, že nebudou splněny všechny požadavky Zadavatele či nebude uveden popis splnění požadavku, bude nabídka vyřazena, neboť nebude plnit požadavky Zadavatele na Dílo.
Uchazeč kromě požadavků daných touto technickou specifikací musí v rámci plnění a dodání Díla splnit požadavky dané v příloze č. 6 Smlouvy (Formulář OHA). V případě, že bude uchazečem interpretován různý výklad požadavků z dokumentů, platí, že přednost má požadavek dokumentu Technická specifikace.
Příloha č.2 – Podmínky pro zajištění podpory provozu díla
I. Úvodní ustanovení
1. Součástí plnění smlouvy je fáze 5 – podpora díla, tj. následná komplexní technická (servisní) podpora, údržba a zajištění provozu díla - Aplikace, která je blíže specifikovaná v příloze číslo 1
– Obchodních podmínek, Technická specifikace) v průběhu produkčního provozu a to po dobu 72 měsíců, která se počítá od dokončení fáze 4, tj. od předání a převzetí díla. Po celou dobu fáze 5 běží a trvá na celé dílo i jeho jednotlivé části záruční doba. Během a v rámci fáze 5 – podpory díla Dodavatel řeší kromě činností uvedených v článku III. této přílohy rovněž záruční vady a nedodělky díla, resp. Požadavky, a to dle níže uvedené Tabulky služeb a SLA. Veškeré náklady na podporu díla (včetně podpory dodaného software) dle „Smlouvy o dodávce a implementaci řešení pro ePortál Zlínského kraje a zajištění následné podpory“ (dále také jen „Smlouva“) jsou zahrnuty v ceně za zajištění podpory provozu díla, která je uvedena v článku
VI. odst. 5 Smlouvy. Dodavatel není oprávněn si za podporu díla účtovat jakékoliv další částky, pokud není uvedeno v této příloze Smlouvy jinak.
2. Požadavek na servisní zásah může být Objednatelem uplatněn:
• systémem HelpDesk na adrese
• e-mailem na adrese pokud není možno použít HelpDesk, Dodavatel požadavek do HelpDesku dodatečně doplní
• telefonem na čísle pokud není možno použít HelpDesk, Dodavatel požadavek do Helpdesku dodatečně doplní
pozn.: údaje lze před podpisem Xxxxxxx s vybraným Dodavatelem upravit
Podpora díla (Aplikace) se bude sestávat ze:
a) Základní podpora díla:
• Legislativních aktualizací Aplikace
• Bezpečnostních aktualizací Aplikace
• Odstraňování nahlášených vad
• Pravidelná profylaxe Aplikace
b) Rozšířená podpora díla:
• Analýzy a realizace rozvoje dle požadavku Objednatele
3. Definice termínů použitých v této příloze Smlouvy:
• Incident – událost, která neprobíhá očekávaným způsobem (nestandardní stav) a ovlivňuje nebo může ovlivnit poskytovanou službu (nefunkčnost Aplikace, chyba ve zdrojovém kódu Aplikace, chyba ve způsobu (formě) implementace, nedostupnost dat apod.).
• Změna – změnové požadavky ze strany Objednatele specifikované v odst. 5 článku III. této přílohy.
• Požadavek – Incident nebo Změna.
• BD – Business Day – pracovní den – doba od 8.00 do 16.00 hodin v pracovní dny pondělí až pátek (mimo víkendy a svátky platné v České republice).
• NBD – Next Business Day – následující pracovní den.
• KI – komunikační infrastruktura
• SLA – Service-Level Agreement – požadované služby Aplikace
• KU(ZK) - Krajský úřad (Zlínského kraje)
II. Práva a povinnosti Objednatele
1. Objednatel se zavazuje poskytnout Dodavateli veškerou součinnost potřebnou k zajištění služeb v rámci podpory díla. Objednatel se zejména zavazuje předávat Dodavateli potřebné
nebo důvodně Dodavatelem vyžádané informace a podklady pro provádění těchto služeb.
2. Objednatel se zavazuje umožnit Dodavateli vzdálený přístup na provozní server způsobem stanoveným v předávacím protokolu. Přístupové údaje sdělují zástupci – kontaktní osoby Objednatele ve věcech technických a to zástupcům – kontaktním osobám Dodavatele ve věcech technických. Přístup do prostředí Objednatele je mimo dobu používání neaktivní. Aktivace provádí zástupci – kontaktní osoby Objednatele před použitím vzdáleného přístupu na základě žádosti zástupce – kontaktní osoby Dodavatele na dohodnutou dobu.
3. Objednatel je oprávněn k nahlášení Požadavku Dodavateli prostřednictvím některého z výše uvedených kontaktů. Požadavky budou přednostně hlášeny prostřednictvím systému HelpDesk, v případě použití jiného způsobu hlášení (e-mail, telefon) provede Dodavatel dodatečný zápis hlášení do HelpDesku.
4. V případě hlášení Požadavku osobou Objednatele jinou než kontaktní osobou pro podrobnější informace o daném Požadavku, uvede osoba Objednatele její jméno a telefonní číslo pro případný kontakt od řešitele na straně Dodavatele.
5. Objednatel zajistí Dodavateli pracovní prostor v místě plnění podpory díla v rozsahu nutném pro provedení servisních služeb.
6. Objednatel poskytne Dodavateli po nabytí účinnosti Smlouvy kompletní dokumentaci prostředí a potřebné přístupové údaje pro plnění podpory díla.
7. Objednatel je povinen informovat Dodavatele o všech opatřeních a zásazích, které na programovém vybavení či jiných místech týkajících se programového vybavení provedl sám.
8. Objednatel si vyhrazuje právo monitorovat a zakázat neoprávněné aktivity Dodavatele.
9. Objednatel si vyhrazuje právo auditovat smluvní povinnosti Dodavatele nebo nechat provést tyto audity třetí stranou.
III. Minimální rozsah služeb v rámci základní podpory díla a práva a povinnosti Dodavatele
1. Provádění profylaxe Aplikace v 3měsíčním intervalu – inspekce a sledování chodu informačního systému u Objednatele, zejména:
• kontrola bezpečnosti, funkcionality a odezvy systému;
• kontrola vazeb (konzistence dat);
• kontrola zaplňování databázového a úložného prostoru a návrhy na jeho rozšiřování;
• kontrola zálohování a bezpečnosti dat;
• mapování vytížení systému a návrh optimalizace (zejména selekty a indexy);
včetně provádění potřebných zásahů k optimalizaci chodu a předcházení poruchám.
O provedené profylaxi bude Dodavatelem proveden zápis nebo pořízena informace do systému HelpDesk, který potvrzuje Objednatel.
Dodavatel bude v rámci nastavené Smlouvy kvartálně realizovat profylaxi Aplikace, v rámci které ověří její stav, parametry a vyhodnotí nutnost změn. V případě, že se bude jednat o funkční vady, které ohrožují funkčnost, bezpečnost Aplikace, případně dochází k nesouladu s legislativou, provede opravy bezodkladně a nasadí je po odsouhlasení Objednatele. V případě že během profylaxe objeví Dodavatel prostor pro zlepšení nebo modernizaci v souladu s aktuální best- practice, seznámí s těmito závěry Objednatele, který následně rozhodne o pokračování v analýze v režimu rozvoje Aplikace.
Během provozu Aplikace na KÚZK a smluvního vztahu s Dodavatelem zajišťuje Dodavatel Aplikace pravidelné penetrační testování minimálně jednou za rok v rámci interního vývoje. Aplikace bude testována minimálně dle metodiky OWASP Testing Guide, ve stable verzi 4.2. Dodavatel vyhotovuje záznamy o penetračním testování a výsledky předloží Objednateli.
Bezpečnost řešení Aplikace musí být po celou dobu podpory chráněna proti známým bezpečnostním chybám a hrozbám, nejenom dle metodiky OWASP.
2. Zapracování změn (update, upgrade) díla, jejichž příčinou byla legislativní změna právních předpisů, to znamená, že Aplikace a její funkcionality musí být Dodavatelem uvedeny v soulad s aktuálním stavem právního řádu v ČR (tj. v soulad s platnými obecně závaznými právními předpisy ČR a EU platnými a účinnými na území ČR), avšak vždy s předchozím odsouhlasením ze strany Objednatele. Dodavatelem budou vyhodnocovány změny legislativy a rovněž aktuální bezpečnostní situace a varování v oblasti kyberbezpečnosti od bezpečnostních složek, NÚKIB, dodavatelů antivirových řešení apod., vůči těmto zjištěním bude komparovat nastavení Aplikace a v případě, že identifikuje zranitelnost Aplikace, provede vytvoření aktualizace/opravy, kterou nasadí nejprve do testovacího, následně do produkčního prostředí Aplikace po schválení Objednatelem.
Zapracování změn (update, upgrade) díla z důvodů legislativních změn právních předpisů musí vést ke stejné nebo vyšší kvalitě uživatelského komfortu a být dostupné nejpozději před nabytím účinnosti legislativních změn právních předpisů.
3. Zajištění aktualizace Aplikace – nárok na zlepšení, dodatky a nové verze všech komponent/modulů Aplikace (upgrade a update), aktualizace znalostní DB, formulářů a životních situací včetně jejich instalace a implementace v 3měsíčním intervalu. Zajištění aktualizace Aplikace může vzniknout z iniciativy Objednatele nebo Dodavatele a pokud vznikne z iniciativy Dodavatele, pak před provedením jednotlivých upgrade či update musí vždy proběhnout odsouhlasení ze strany Objednatele (postačí prostřednictvím zástupců – kontaktních osob ve věcech technických), a to minimálně v rozsahu prováděné úpravy (upgrade, update) a času, ve kterém taková činnost bude provedena. V případě zveřejnění zranitelnosti systému Dodavatel zajistí její odstranění.
4. Služba „Help-line“ - Dodavatel zajistí Help-line a bude ji udržovat dostupnou v pracovní dny vždy nepřetržitě od 8 do 16 hodin. V rámci poskytování služby „Help-line“ získává Objednatel nárok na konzultace a garantovanou pomoc při řešení technických problémů Objednatele souvisejících s provozem Aplikace. Jedná se o vzdálené konzultace a řešení po telefonu, e-mailu nebo s využitím aplikace HelpDesk.
• V případě zjištění, že se jedná o chybu na straně Objednatele, poskytne Dodavatel jako součást této služby Objednateli správný postup řešení problematiky.
• V případě, že bude potřeba věc řešit jako potřebnou úpravu, jako novou funkcionalitu, a nikoliv jako problém se stávajícím řešením, zpracuje Dodavatel a předá Objednateli v rámci této služby popis rozsahu takové úpravy, a to včetně její funkcionality a rozsahu pracnosti.
5. Zajištění řešení změnových požadavků (dále jen „Změn“) týkajících se zejména:
• úpravy konfigurace a funkcionalit;
• migrace dat;
• tvorba a integrace nových funkcionalit.
Objednatel má právo požadovat po Dodavateli zajištění řešení změnových požadavků (Změn) podle potřeby, a to v rozsahu max. 40 hodin prací ročně. V případě nevyčerpání 40 hodin prací ročně se nevyčerpané hodiny převádějí do následujícího roku. Aktivity, které jsou součástí předchozích odstavců tohoto článku (provádění pravidelné profylaxe, zapracování legislativních změn, zajištění aktualizace Aplikace a zajištění služby Help-line), nejsou považovány za Změny.
6. Řešení Požadavků (Incidentů a Změn) v místě instalace díla v souladu s SLA, a to takto:
Specifikace požadovaných služeb (SLA), které je Xxxxxxxxx povinen zajistit:
Dodavatel se zavazuje každý zjištěný či nahlášený Požadavek zapsat do HelpDesku s příslušným zařazením typu Požadavku (název služby, označení) a priority řešení (kategorie), pokud již tak neudělal Objednatel. Dodavatel neprodleně zahájí práce na řešení Požadavku ve lhůtách podle následující tabulky kategorie a typu Požadavku. Objednatel může v případě neodpovídajícího zařazení Požadavku (zejména kategorie) iniciovat změnu zařazení, přičemž rozhodné je zařazení Požadavku Objednatelem. Řešení probíhá jako u nového Požadavku dle změněné kategorie s příslušnými SLA.
Dodavatel bude uvádět podrobné řešení Požadavku do HelpDesku, závěrečné vyřešení Požadavku odsouhlasuje Objednatel. V případě odůvodněného zamítnutí vyřešení Objednatelem běží lhůta pro řešení Požadavku dále.
Požadavky jsou klasifikovány dle jejich závažnosti a provozních podmínek na tři kategorie důležitosti:
• Kritická
• Standardní
• Nízká
Pokud o Změně/zjištění třetí stranou bude informován nejprve Objednatel, oznámí jej Dodavateli skrze smluvený komunikační kanál, přičemž bude Dodavatel reagovat na Změnu/zjištění v souladu s SLA dle kategorie Požadavku.
Odstraňování nahlášených vad bude Dodavatel realizovat rovněž na základě zjištění vlastního nebo požadavku v časech SLA dle kategorie Požadavku.
Dodavatel bude v rámci podpory provozu realizovat analýzu a realizaci rozvoje Aplikace na základě schválení realizace Objednatelem. V rámci analýzy provede analýzu obtížnosti a vyčíslí změnu nákladově a s časovým vyjádřením náročnosti změny vč. předpokládaného termínu nasazení. Realizaci rozvoje následně dle analýzy schvaluje Objednatel. Požadavky na rozvoj budou hlášeny stejným kanálem jako požadavky na odstranění vad dle SLA kategorie Nízká a SLA bude platit pro analýzu rozvoje. Pro realizaci bude platit termín daný analýzou.
A) Zajištění bezpečnosti provozu
Dodavatel je povinen zajistit bezpečný provoz dodávaného řešení. V případě zjištění zranitelnosti řešení, zejména v případě jejího zveřejnění a přidělení CVE označení, je Dodavatel povinen provést bezodkladné opatření ke snížení dopadů takové zranitelnosti. Dále je Dodavatel povinen provést instalaci bezpečnostních záplat v termínech definovaných v tabulce služeb a SLA dle závažnosti CVE dle scoring systému CVSS v3.1 base score.
B) Tabulka služeb a SLA
Dodavatelem bude poskytována podpora Aplikace ve funkční, bezpečnostní oblasti a v oblasti souladu s legislativou. Objednatelem budou hlášeny Požadavky Dodavateli na základě změny (změna chování Aplikace, změna legislativy, změna bezpečnostní situace, požadovaná změna – rozvoj) či zjištění (chyba, nefunkčnost, problém) s uvedením kategorie Požadavku. Dle kategorie Požadavku bude Dodavatel reagovat přijetím Požadavku v HelpDesku dle SLA a následně řešením Požadavku s termínem řešení dle SLA.
Požadavky jsou klasifikovány dle jejich závažnosti a provozních podmínek na tři kategorie důležitosti:
• Kritická
o Incidenty vylučující užívání Aplikace nebo její části (tj. problémy zabraňující provozu Aplikace), provoz Aplikace je zastaven.
o Změny/zjištění vysoké priority řešení, zejména ohrožující provoz nebo bezpečnost díla či jeho částí.
• Standardní
o Ostatní Požadavky, které nespadají do kategorie „Kritická“ nebo „Nízká“.
• Nízká
o Změny/zjištění nízké priority řešení, které neohrožují provoz nebo bezpečnost Aplikace či její části.
Řešení Požadavků probíhá v režimu:
• 8 x 5 - tj. pracovní dny od 8:00 do 16:00 hodin
Název Služby | Kategorie Požadavků | Režim | CVSS score | Potvrzení o přijetí Požadavku v systému HelpDesku | Max. doba do vyřešení Požadavk u od zadání |
Provoz Aplikace | Kritická | 8 x 5 | větší než 9.0 | do 30 minut | do 6 hodin |
Standardní | 8 x 5 | do 9.0 | do 1 hodiny | do 3 BD | |
Nízká | 8 x 5 | do 3.0 | do 1 hodiny | do 10 BD |
V případě rozsáhlejší Změny či zjištění zařazeného do Nízké kategorie řešení Požadavků může být za vyřešení Požadavku považováno i zpracování analýzy a náročnosti řešení požadované Změny.
Příklad: Je-li zadán Požadavek v kategorii „Kritická“ na HelpDesk v pátek v 15:45 hodin, je Dodavatel povinen potvrdit přijetí Požadavku nejpozději v pondělí 8:15 hod, a dále je povinen vyřešit Požadavek nejpozději do pondělí 13:45 hodin (6h je počítáno od zadání Požadavku jen v době pro řešení Požadavků).
Příklad 2: Je-li zadán Požadavek v kategorii „Standardní“ na HelpDesk v pátek v 5:15 hodin, je Dodavatel povinen potvrdit přijetí Požadavku nejpozději v pátek 9:00 hod, a dále je povinen vyřešit Požadavek nejpozději do středy 16:00 hodin.
Příklad 3: Je-li zadán Požadavek v kategorii „Standardní“ na HelpDesk v pátek v 8:45 hodin, je Dodavatel povinen potvrdit přijetí Požadavku nejpozději v pátek 9:45 hod, a dále je povinen vyřešit Požadavek nejpozději do středy 16:00 hodin.
Po nahlášení/zadání a následném zpětném potvrzení Požadavku kontaktuje řešitel případu Objednatele a dohodne podrobnosti o možnostech a průběhu řešení. Objednatel má možnost změny Kategorie na základě závažnosti Požadavku.
Max. doba vyřešení Požadavků se počítá od času nahlášení/zadání Požadavku. Na základě prokazatelného doložení Dodavatelem může být max. doba vyřešení Požadavků prodloužena (a to pouze na základě písemné dohody/protokolu podepsané zástupci – kontaktními osobami smluvních stran ve věcech technických) o čas pro součinnost Objednatele nebo v případech zásahu vyšší moci (podle příslušných ustanovení zákona č. 89/2012 Sb., občanského zákoníku ve znění pozdějších předpisů), tj. o dobu trvání času pro součinnost Objednatele, případně o dobu trvání nesoučinnosti Objednatele, dále o dobu trvání zásahu vyšší moci. V případě, že součástí řešení (díla) je i dodávka open source, odpovídá (nehledě na výše v tomto odstavci uvedené) za tento software Dodavatel, tím pádem to není důvod pro prodloužení doby vyřešení Požadavků od zadání.
C) Provoz systému HelpDesk pro evidenci veškerých Požadavků, který musí poskytovat:
• přístup pro min. 5 uživatelů Objednatele
• jednoduché a pohodlné vkládání Požadavků uživatelem podle jeho oprávnění, kdy kromě textového popisu je možné vkládat i soubory;
• možnost nastavení typu Požadavku (název služby, označení) a priority řešení (kategorie);
• sledování vývoje řešení Požadavku včetně interakcí Objednatele:
o číslo Požadavku,
o čas vzniku události,
o čas založení Požadavku,
o typ Požadavku a priorita řešení (kategorie),
o vypočítaná lhůta pro vyřešení dle SLA,
o popis zadání Požadavku,
o podrobný popis jednotlivých kroků řešení požadavku včetně řešitele,
o možnost interakce / komentáře Objednatele v dílčích řešeních,
o čas vyřešení Požadavku,
o čas odsouhlasení řešení Objednatelem,
o celkový strávený čas na řešení požadavku,
o vyhodnocení splnění SLA.
• závěrečné řešení Požadavku schvalováno Objednatelem;
• kriteriální vyhledávání Požadavků;
• seznam všech hlášených Požadavků po dobu podpory díla – výpis Požadavků s datem a časem zadání, názvem, aktuálním stavem řešení, aktuálním řešitelem, datem a časem vyřešení, celkovým stráveným časem na řešení;
• ukončení řešení Požadavku až po schválení vyřešení Objednatelem;
• e-mailové notifikace při založení, změně stavu a ukončení řešení Požadavku, konfigurace notifikací podle jednotlivých typů Požadavků;
• přístup k aplikaci přes webový prohlížeč 24 hodin denně – bez nákladů pro Objednatele (zejména na software nebo licence).
7. Zajištění zálohování v pravidelných intervalech stanovených v příslušné dokumentaci a před každým zásahem, při kterém by mohlo dojít k situaci vyžadující provedení obnovy.
8. Aktualizace veškeré dokumentace specifikované v příloze č. 1 Smlouvy při každé změně díla.
9. Dodavatel se zavazuje udržovat aktuální zdrojové kódy díla (resp. Aplikace) a související dokumentaci, tj. včetně zdrojových kódů a související dokumentace týkající se každé změny (update, upgrade) informačního systému.
10. Zpracování pololetních hodnotících reportů poskytovaných služeb sloužících jako podklad pro fakturaci služeb včetně přehledného uvedení případu nedodržených parametrů služeb a odečtení pokut za toto nedodržení. Minimální obsah reportu: Xxxxx Xxxxxxxxx, čas založení Požadavku, lhůta pro vyřešení dle SLA, popis zadání Požadavku, podrobný popis řešení požadavku i s jednotlivými kroky, čas vyřešení Požadavku, celkový strávený čas na řešení požadavku, vyhodnocení splnění SLA.
IV. Činnosti nad rámec služeb podpory provozu díla
1. Dodavatel se zavazuje také k vykonávání činností nad rámec služeb podpory provozu díla nebo k vykonávání činností, které sice spadají pod služby podpory provozu díla, ale přesahují jejich vymezený časový rámec [jedná se zejména o případ, kdy dojde k překročení – vyčerpání rozsahu hodin prací uvedených v článku III. odst. 5 této přílohy], a to za cenu v místě a čase obvyklou, maximálně však za hodinovou sazbu ve výši 1000,- Kč bez DPH.
2. Vedle částky dle předchozího odstavce je Dodavatel oprávněn vyúčtovat také cestovné za ceny v místě a čase obvyklé.
3. Cena za činnosti dle tohoto článku není součástí ceny za podporu díla nabídnutou Dodavatelem v nabídce a bude fakturována Dodavatelem samostatně. Objednatel bude řešit případné změny ceny podpory požadované Objednatelem dle předchozích odstavců tohoto článku v analogii s § 222 odst. 4 zákona. č. 134/2016 Sb.
V. Smluvní pokuty a sankce za porušení podmínek zajištění provozu a podpory
Smluvní pokuty vztahující se k podmínkám podpory díla jsou uvedeny v článku VIII. Smlouvy.
Bezpečnostní pravidla informačního systému (IS) Zlínského kraje (ZK)
Verze 2.7
ICT (informační a komunikační technologie) jsou veškeré informační technologie používané pro komunikaci a práci s informacemi
IS (Informační systém) je celek složený z počítačového hardwaru, souvisejícího softwaru a dat.
Správce IS je pracovník Odboru informačních a komunikačních technologií, Oddělení serverové a síťové infrastruktury ZK. Je uveden jako odpovědná osoba předávajícího v předávacím protokolu
o předání přihlašovacích údajů.
Druhá smluvní strana je subjekt, se kterým Zlínský kraj uzavřel smlouvu, jejíž přílohou jsou tato bezpečnostní pravidla, a dále všichni jeho pracovníci, poddodavatelé apod.
Při porušení bezpečnostních pravidel druhou smluvní stranou mohou být přidělené přístupové účty bez předchozího upozornění zablokovány nebo zcela odebrány.
1) Přístup k IS ZK
a) Přístup jiných subjektů (druhé smluvní strany) k IS ZK je možný pouze na základě smluvně ošetřeného vztahu se Zlínským krajem.
b) Druhá smluvní strana je povinna používat pouze jí přidělené přístupy a povolené způsoby přístupu, (fyzické přístupy, přístupové údaje, povolené časy pro přístup a přidělená oprávnění), a je odpovědná za jejich používání. Přidělené údaje jsou pro druhou stranu závazné, jsou důvěrné a jsou platné jen po dobu platnosti smlouvy. Tyto údaje jsou uvedeny v Předávacím protokolu k účtu. Přidělené přístupové údaje jsou přiděleny konkrétní osobě a nesmí být sdíleny.
c) Přístupy a přístupová oprávnění jsou přidělena pouze v rozsahu nezbytně nutném pro výkon smluvních závazků. Druhá smluvní strana nesmí bez souhlasu správce IS vytvářet nové přístupové účty a do přidělených účtů a oprávnění zasahovat a měnit je. Pokud druhá smluvní strana zjistí, že skutečná oprávnění jsou odlišná od dohodnutých, neprodleně na to upozorní odpovědné osoby nebo Správce IS.
d) Přistupovat k IS ZK mohou pouze poučení pracovníci druhé smluvní strany. Druhá smluvní strana zajistí před zahájením prací poučení a proškolení všech svých pracovníků a subdodavatelů, kteří budou přistupovat k IS ZK.
2) Práce v IS ZK
a) Druhá smluvní strana je povinna dodržovat bezpečnostní pravidla a stanovené postupy pro práci v IS ZK a nese v souladu s platnou legislativou a předpisy svůj díl odpovědnosti za nedodržení či porušení pravidel, případně za škody vzniklé v důsledku bezpečnostních incidentů, které zavinila.
b) Druhá smluvní strana zajistí přiměřenou úroveň bezpečnostního povědomí svých zaměstnanců a dodavatelů, kteří se podílejí na plnění předmětu smlouvy.
c) Je přísně zakázáno vykonávat jiné než dohodnuté činnosti, přistupovat k jiným než povoleným prostředkům, službám, serverům a datům, a tyto zdroje nesmí neúměrně zatěžovat. Dále je zakázáno provádět jakékoli úkony směřující k zjišťování rozsahu přidělených oprávnění, monitorování síťové komunikace, dostupnosti síťových prostředků a služeb a způsobů zabezpečení které nesouvisí s plněním předmětu smlouvy, a provádět pokusy o jejich překonání.
d) Druhá smluvní strana nesmí vytvářet žádné přístupové cesty do IS ZK a měnit přístupová oprávnění. Tyto změny může provádět Správce IS na základě písemné žádosti.
e) Činnost druhé smluvní strany v IS ZK je monitorována a evidována. Neoprávněné aktivity může Správce IS zakázat. Pověření pracovníci ZK mohou ověřovat dodržování stanovených bezpečnostních pravidel a plnění smluvních povinností, nebo je nechat prověřit třetí stranou.
Druhá smluvní strana jim při tom poskytne nezbytnou součinnost. V případě zjištění nedostatků je povinna druhá smluvní strana tyto odstranit ve lhůtě stanovené Správcem IS.
f) Pracovníci druhé smluvní strany jsou povinni řídit se pokyny odpovědných osob (uvedených ve smlouvě), Správců IS a dalších pracovníků Odboru informačních a komunikačních technologií.
g) Xxxxx smluvní strana je povinna bez zbytečného prodlení předávat Správci IS informace o provedených zásazích a změnách, promítnout je do dokumentace a předat Správci IS. Všechny změny, které mohou ovlivnit bezpečnost IS ZK, musí být předem projednány a schváleny Správcem IS.
3) Účty a hesla
a) Druhá smluvní strana je povinna chránit přístupové účty heslem. Druhá strana nesmí sdělit názvy účtů a hesla žádné neoprávněné osobě. Heslo musí splňovat aktuální požadavky ZK na kvalitu a platnost a musí být uchováno v tajnosti. Hesla musí být vždy předávána bezpečným způsobem. Pokud je to možné, musí být použita více faktorová autentizace.
b) Přístupové účty jsou standardně neaktivní. Jejich aktivaci na dobu nezbytnou k provedení dohodnutých prací schvalují a zajištují na základě žádosti druhé smluvní strany odpovědné osoby ZK. Žádost musí obsahovat informace o prováděných činnostech a předpokládané době prací. Druhá smluvní strana nesmí bez předchozího schválení provádět jiné než nahlášené práce.
4) Vzdálený přístup a vzdálená údržba
a) Vzdálený přístup do IS ZK je možný pouze způsobem schváleným ZK, popsaným ve smlouvě nebo schválené technické dokumentaci. Vzdálený přístup musí být vždy šifrován. Přistup ke konkrétním systémům či technologiím musí probíhat přes přidělený přístupový „jump server“ ZK, na kterém musí být viditelné všechny prováděné činnosti. Činnosti vzdálené správy jsou ze strany ZK zaznamenávány.
b) Druhá smluvní strana smí vzdáleně přistupovat do IS ZK pouze z pracovní stanice, která má nainstalovaný podporovaný operační systém, nainstalovány všechny bezpečnostní záplaty operačního systému vydané výrobcem, a má aktivní a aktuální antivirovou ochranu.
c) Druhá smluvní strana smí vzdáleně přistupovat do IS ZK pouze z ověřených IP adres. Konkrétní IP adresy schvaluje Správce IS.
d) Přístup k IS ZK za účelem vzdálené údržby musí být chráněn kromě šifrování i silnou autentizací druhé smluvní strany.
e) Pracovní stanice určené k přístupu do IS ZK ze vzdálené lokality musí být druhou smluvní stranou fyzicky zabezpečeny proti přístupu neoprávněných osob.
5) Zabezpečení fyzického přístupu k IS
a) Servery, síťové komponenty a další ICT zařízení jsou zabezpečeny proti fyzickému přístupu. Přístup do místností se servery s citlivými daty a přístup k síťovým zařízením je regulován a odpovídajícím způsobem monitorován. Pokud fyzické zabezpečení citlivých dat není dostatečné, musí být zabezpečena šifrováním.
b) Opravy ICT komponent mohou být prováděny pouze na základě smluvně ošetřeného vztahu se ZK.
c) Fyzický přístup k prostředkům IS je umožněn pouze druhým smluvním stranám (servisní a dodavatelské organizace, dohody o provedení práce apod.), u kterých udělení přístupu vyplývá z uzavřené smlouvy. Fyzický přístup k prostředkům IS je možné uskutečnit pouze se souhlasem Správce IS nebo vedoucího oddělení serverové a síťové infrastruktury, Odboru informačních a komunikačních technologií.
d) Pohyb pracovníků druhých smluvních stran v prostorách serverovny (servisní zásah, revize zařízení apod.) je možný pouze v doprovodu odpovědných pracovníků Odboru informačních a komunikačních technologií nebo jimi pověřených osob.
e) Pro přímé připojení (v prostorách ZK) do IS ZK smí být použita pouze přidělená technika ZK. Připojování cizí techniky do vnitřní sítě ZK je zakázáno. Výjimky povoluje Správce IS.
f) Na přidělenou techniku ZK nesmí být bez souhlasu Správce IS nahráván, instalován nebo z ní odebírán žádný software.
g) Při opuštění pracoviště musí druhá smluvní strana provést jeho zajištění (pracovní stanice, nosiče dat, papírové dokumenty) před neoprávněným přístupem.
h) Druhá smluvní strana je povinna uchovávat přenosná paměťová média na bezpečném místě, např. v uzamčené skříni, stolu nebo místnosti. Originální datová média a záložní kopie citlivých souborů musí být chráněna nejen proti odcizení a zneužití, ale i proti poškození nebo zničení.
i) Druhá smluvní strana je povinna chránit přidělené pracovní stanice a data na nich uložená proti odcizení, proti neoprávněnému přístupu a proti poškození nebo zničení.
6) Důvěrnost informací
a) Za důvěrné informace ZK (bez ohledu na formu jejich zachycení) se považují zejména veškeré technické informace o IS ZK, které nebyly ze strany ZK označeny jako veřejné.
b) Druhá smluvní strana je povinna zajistit odpovídající ochranu všech důvěrných informací.
7) Ochrana dat a informačních aktiv
a) Data ZK jsou ve vlastnictví ZK, který k nim má primární užívací právo.
b) Druhá smluvní strana je povinna chránit všechna data ZK, se kterými přijde do styku. Všechny nové aplikace a aktualizace musí být ověřeny v testovací prostředí. Používat ostrá data pro zkušební a testovací účely je zakázáno. Výjimku může v odůvodněných případech povolit pouze vedoucí odboru ICT.
c) Druhá smluvní strana odpovídá za všechna převzatá data (elektronická a tištěná), způsob jejich použití a ochranu před neoprávněným přístupem a zneužitím. Není-li ve smlouvě stanoveno jinak, před ukončením smluvního vztahu druhá smluvní strana vrátí všechna převzatá data a všechny jejich kopie bezpečně zlikviduje.
d) Druhá smluvní strana je do protokolárního předání pracovníkům ZK odpovědná za všechna zpracovávaná aktiva a je povinna je odpovídajícím způsobem zabezpečit. Dále je povinna vytvořit a průběžně aktualizovat plán zálohování.
e) Ukládání pracovních dat je možné pouze na místa, která určí odpovědná osoba.
f) Druhá smluvní strana nesmí zobrazovat, měnit, mazat nebo kopírovat citlivá data, zejména pak osobní údaje, pokud to nesouvisí se schváleným účelem přístupu.
g) Vadná zařízení (včetně pevných disků) s nešifrovanými citlivými daty mohou být druhou smluvní stranou předány externím servisním specialistům pouze po schválení Správcem IS nebo vedoucím oddělení serverové a síťové infrastruktury, Odboru informačních a komunikačních technologií.
h) Pokud druhá smluvní strana při práci v IS ZK přijde do styku s osobními údaji dle platné legislativy nebo jinými neveřejnými informacemi, je povinna o zjištěných skutečnostech zachovávat mlčenlivost a zajistit jejich utajení.
i) Všechna nepotřebná data (elektronická, na mediích i papírová) musí být druhou smluvní stranou vždy neprodleně bezpečně skartována.
j) Druhá smluvní strana je povinna všechny zásahy na serverech předem odsouhlasit se Správcem IS a zaznamenat stanoveným způsobem.
k) Druhá smluvní strana je povinna řídit změny v konfiguraci systému, při realizaci aktualizací, zálohování apod. Druhá smluvní strana navrhne předmětné změny, tyto zdokumentuje a předloží Správci IS. Druhá smluvní strana poskytuje součinnost Správci IS při vyhodnocení rizik (např. prostřednictvím analýzy rizik) a potencionálních dopadů změny. Druhá smluvní strana je povinna v případě vyžádání Správcem IS provést testování funkčnosti a bezpečnosti změny. Změnu provede až po odsouhlasení Správcem IS, přičemž vždy takovým způsobem, aby byla zaručena i možnost navrácení do předchozího stavu.
l) Druhá smluvní strana je povinna řídit rizika a na požádání informovat Správce IS jakým způsobem řídí rizika (včetně popisu způsobu řízení rizik či metody řízení) a jaká jsou zbytková rizika související s předmětem dodávané služby. Správce IS má právo způsob řízení rizik
u druhé smluvní strany ověřit a druhá strana je povinna poskytnout Správci IS nezbytnou součinnost.
8) Ochrana proti škodlivým kódům
a) Druhá smluvní strana je povinna všechny servery a pracovní stanice v IS ZK a pracovní stanice druhé smluvní strany, které se připojují k IS ZK, vybavit antivirovým skenerem. Výjimky schvaluje Správce IS.
b) Pokud některé aplikace nabízejí možnost zvýšené ochrany, musí být odpovídajícím způsobem nastavena. Způsob nastavení schvaluje Správce IS.
c) Nebezpečné typy souborů jsou blokovány na hranicích bezpečnostního perimetru. Výjimky schvaluje v řádně odůvodněných a zdokumentovaných případech Správce IS.
d) Druhá smluvní strana je povinna dodržovat zásady ochrany proti virům a škodlivým kódům nejen pro nastavení a využívání prostředků ZK, ale i na přístupových bodech a svých vlastních zařízeních.
e) Druhá smluvní strana je povinna pro zajištění provozní a komunikační bezpečnosti provádět pravidelné sledování a analýzy technických zranitelností a jejich následné ošetření.
9) Bezpečnostní incidenty
a) Druhá smluvní strana je povinna neprodleně (telefonicky a následně písemně např. prostřednictvím Helpdesku, e-mailu apod.) hlásit odpovědným osobám porušení těchto Bezpečnostních pravidel, všechny zjištěné neobvyklé události, které jsou, nebo mohou být bezpečnostními incidenty, a to zejména ve vztahu k plnění smlouvy, jejíž přílohou jsou tato bezpečnostní pravidla, zjištěná zranitelná místa, nedostatky a nesoulady. Při jejich prošetřování a odstraňování je povinna poskytnout účinnou součinnost.
b) Druhé smluvní straně není povoleno řešení bezpečnostních incidentů a odstraňování nedostatků či nesouladů vlastními silami bez předchozího schválení Správcem IS.
10) Používání internetu
a) Druhá smluvní strana může používat při práci v IS ZK internet pouze pro účely plnění smlouvy a za podmínky dodržování všech všeobecně uznávaných bezpečnostních pravidel, platných pro práci s internetem. Stahování souborů, používání FTP a jiných služeb je možné jen po dohodě se Správcem IS.
b) Pokud není ve smlouvě stanoveno jinak, není povoleno využívat elektronickou korespondenci z prostředí ZK.
11) Tisk
a) Druhá smluvní strana může tisknout na tiskárnách ZK pouze s povolením odpovědné osoby. Tisknout je povoleno pouze dokumenty související s předmětem smlouvy a při tisku je nutno šetřit spotřební materiál.
b) Druhá smluvní strana je povinna zabezpečit tištěné dokumenty proti neoprávněnému přístupu jak během tisku, tak i po jeho vytisknutí, až do jejich bezpečné skartace.
12) Použití kryptografických technik
a) Kryptografické metody musí být druhou smluvní stranou použity vždy, jestliže není možné bezpečnost dat nebo komunikace zaručit jinými způsoby. Jedná se např. o přenosy citlivých dat prostřednictvím nedůvěryhodných sítí nebo přístup externích subjektů k citlivým zdrojům.
b) Druhá smluvní strana je oprávněna použít pouze takové kryptografické algoritmy a protokoly a v takovém užití (např. odpovídající délky klíčů), které jsou podle platných standardů všeobecně považovány za bezpečné.
c) Druhá smluvní strana není oprávněna použít proprietární nebo obecně neuznávané algoritmy, výjimky povoluje Správce IS.
13) Předání dat
a) Data vzniklá při používání systému musí být exportovatelná v otevřeném, strukturovaném a strojově čitelném formátu (např. formát csv, xml, json), přičemž přesný formát odsouhlasuje Správce IS. K exportovaným datům bude dodán popis struktury, význam a vazby mezi jednotlivými daty.
b) Data musí být předána při ukončení smluvního vztahu a kdykoliv na vyžádání Správce IS. V případě, že Správce IS při ukončení smluvního vztahu rozhodne, že již data nejsou potřebná, zajistí druhá smluvní strana jejich bezpečnou likvidaci. Konkrétní způsob likvidace dat musí být odsouhlasen Správcem IS.
c) Druhá smluvní strana je povinna poskytnout nezbytnou součinnost (včetně případné migrace dat) týkající se změn v IS ZK, a to kdykoliv na požádání Správce IS nebo v případě ukončení smlouvy, jejíž přílohou jsou tato bezpečnostní pravidla.
14) Smluvní pokuty
a) Pokud druhá smluvní strana poruší bezpečnostní pravidla uvedená v článku 1, písm. b) až d), článku 2, písm. b), c), d), f), g), článku 3, písm. a), článku 4, písm. b) až e), článku 5, písm. e) až i), článku 7, písm. b) až l), článku 8, písm. a), d), e), článku 9, písm. a), b), článku 10, písm. a), článku 11, písm. b), článku 12, písm. a) až c), článku 13, písm. a) až c) je Zlínský kraj oprávněn po druhé smluvní straně požadovat a druhá smluvní strana je povinna v případě uplatnění tohoto práva zaplatit Zlínskému kraji pokutu za každý zjištěný případ porušení. Výše smluvní pokuty je uvedena ve smlouvě.
Pořadové číslo
1
2
3
4
5
6
7
Dodavatel bude realizovat k Aplikacím testy uvedené ve výčtu technické specifikace jako společní a rovněž testy uvedené v technické specifikaci Aplikace.
8 Z testů budou vyhotoveny protokoly, které budou předány Objednateli.
Performance testy budou realizovány pro vývojové prostředí Dodavatele a testovací prostředí Objednatele, v rámci testu bude ověřena odezva systému a vytížení HW, testy budou realizovány při simulaci vysokého vytížení. Následně budou tyto testy opakovány na produkčním prostředí v rámci pilotního provozu pro ověření, že hodnoty jsou oproti testovacímu prostředí nezměněny nebo lepší. Cílem je ověření, že hodnoty výkonu dosahují požadovaných v kapitole Požadované
9 technické parametry dostupnosti a výkonnosti.
Dostupnost – Za dostupnost infrastruktury je odpovědný Objednatel, avšak za dostupnost samotné aplikace dle SLA je odpovědný Dodavatel. Pokud dojde v rámci testu k omezení dostupnosti chybou typu blackbox, kdy nebude patrné, proč není Aplikace dostupná, bude situace řešena analytickými silami obou stran za
10 vzájemné součinnosti.
Požadovaná vlastnost (požadavky) | Splňuje uchazeč požadavky (Ano/Ne) | Popis naplnění požadavků dodavatelem |
Dokumentace | - | - |
Implementační analýza bude popisovat Dílo do takového detailu, aby byla možná jeho realizace a zpracování Provozní dokumentace k Aplikaci (za Aplikaci je pro potřebu kapitoly společných technických požadavků označované výstupy Díla, tedy aplikace ePortál a chatbot) Dodavatelem. Provozní dokumentace bude zpracovaná v souladu s požadavky zákona č. 365/2000 Sb., o informačních systémech veřejné správy a vyhlášky č 529/2006 Sb. v platném znění. Obsahem Provozní dokumentace bude zejména: • Bezpečnostní dokumentace informačního systému veřejné správy, • Systémová příručka, • Uživatelská příručka. Dokumentace bude také obsahovat podrobný popis implementace. Tento popis bude součástí Systémové příručky nebo může být uveden v samostatném dokumentu. Veškerá dokumentace bude předána v elektronické podobě. Implementační analýza a Provozní dokumentace bude obsahovat požadovaný minimální výčet informací, uvedený v kapitole Požadavky na dokumentaci a implementační analýzu dokumentu Technická specifikace. Kontrolní analýza, která bude realizovaná před předáním díla do prostředí Objednatele naváže na implementační analýzu a vyznačí v rámci ní změny, případně doplněné, došlo-li k rozšíření funkcionalit. Rovněž doplní nové požadavky na implementaci, pokud takové nastaly. Kontrolní analýza bude dodaná ve dvou verzích – s revizí původních textů implementační části (změny, doplnění) a jako čistopis. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup |
ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup | |
ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup | |
ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup | |
ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup | |
ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup | |
ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup | |
Testy | - | - |
ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup | |
ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup | |
ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup |
ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup |
ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup |
ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup |
ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup |
ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup |
- | - |
ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup |
ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup |
- | - |
ANO | Naplnění proběhne jako standardní součást dodávky frontend částí |
ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup |
ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup |
- | - |
Výkonnost – Za optimalizaci řešení pro požadovanou zátěž je odpovědný 11 Dodavatel.
Pro funkční testy vytvoří Dodavatel testovací scénáře a bude je realizovat společně se Objednatelem. Z funkčních testů vznikne seznam případných zjištění – vad, které Dodavatel odstraní a následně se provede další iterace funkčních testů. Testy budou realizované pro všechna prostředí a scénáře budou reflektovat funkcionality
12 daného prostředí.
Dodavatel zajistí nezávislé bezpečnostní otestování Aplikace vč. všech jeho prostředí třetí stranou včetně penetračních testů v souladu s požadavky kategorie
13 požadavků Oveření bezpečnosti
Dodavatel ve spolupráci se Objednatelem zajistí UX/UI testy prostředí Aplikace a provede úpravy podle zjištěných neoptimalit UX/UI portálu. UX/UI testování bude opakované ve vývoji, nasazení na testovacím prostředí a produkčním prostředí, bude ukončeno v rámci pilotního provozu. Dojde-li ke změně UI vlivem
14 optimalizace, budou změny zaneseny do odpovídající dokumentace Aplikace.
Akceptační testy bude realizovat Objednatel. Testy budou probíhat ve dvou částech. První část proběhne dle scénářů, které připraví Dodavatel a schválí Objednatel. Druhá část nezávislého ověření bude realizována náhodným testováním Objednatele. V průběhu testů bude Dodavatel poskytovat součinnost na vyžádání. Z obou částí vznikne seznam případných zjištění, které dodavatel odstraní. Cílem akceptačních testů je ověření funkčnosti řešení a ověření původních testů. Po úspěšném odstranění zjištění a potvrzení může pokračovat
15 proces akceptace.
Umístění Aplikace a zajištění domén
16 Administraci předmětných domén na úrovni DNS záznamů zajistí Zlínský kraj.
Aplikace bude umístěna on-premise ve virtualizovaném prostředí technologického 17 centra Objednatele (TC KÚZK, TCK).
Lokalizace
18 Aplikace a všechny její části budou mít UI v českém jazyce
Školení k aplikacím proběhne v českém jazyce, a to jak školení administrátorů, tak 19 uživatelů
Veškerá dokumentace, vč. implementační analýzy, kontroní analýzy, provozní 20 dokumentace bude psaná v českém jazyce
Přístupnost, podpora prohlížečů a responzivní zobrazení
ANO | Naplnění proběhne jako standardní součást dodávky frontend částí |
ANO | Naplnění proběhne jako standardní součást dodávky frontend částí |
ANO | Naplnění proběhne jako standardní součást dodávky frontend částí |
ANO | Naplnění proběhne jako standardní součást dodávky frontend částí |
- | - |
Aplikace musí splňovat příslušné zákonné normy a standardy nutné pro její řádné fungování. Pro webovou aplikaci se jimi rozumí zvláště:
- Musí být v souladu se zákonem č. 99/2019 Sb., o přístupnosti webových stránek (WCAG 2.1)
- ISVS 005/02.01 (xxxx://xxx.xxxx.xx/)
- HTML 5, CSS 3
- WAI-AA (xxxx://xxx.x0.xxx/XXX/) :
i. webové stránky: Web Content Accessibility Guidelines (WCAG)
ii. authoring tools: Authoring Tool Accessibility Guidelines (ATAG)
iii. prohlížeče: User Agent Accessibility Guidelines (UAAG)
iv. webové aplikace: Accessible Rich Internet Applications (WAI-ARIA)
- Metodika Bliend Ffrienly Web 2.3 (xxxx://xxxxxxxxxxxxx.xx/xxxxxxxx)
- Optimalizace pro SEO
21
Dodaná aplikace a šablony budou napsány tak, aby bylo možné provést SEO optimalizaci (jedná se především o možnost zadávání meta tagů, popiskům
22 k netextovým prvkům, správná strukturu a sémantika, kanonické URL)
Aplikace musí být optimalizována pro běžně používané internetové prohlížeče. Podporovaná je vždy aktuální a jedna předchozí verze poslední vydané číselné řady prohlížeče:
• Desktop: Microsoft Edge, Google Chrome, Safari, Mozilla Firefox;
• Mobilní zařízení: Android browser, Google Chrome, Safari, Mozilla Firefox.
23
Aplikace bude podporovat responzivní zobrazení, tj. zobrazení Aplikace se bude měnit podle velikosti displeje zobrazovacího zařízení, vč. podpory mobilních
24 zařízení – tabletů a mobilních telefonů.
Legislativa
ANO | Naplnění proběhne jako standardní součást dodávky |
ANO | Naplnění proběhne jako standardní součást dodávky |
- | - |
ANO | Naplnění proběhne jako standardní součást dodávky |
ANO | Naplnění proběhne jako standardní součást dodávky |
Řešení bude v souladu s platnou legislativou, minimálně pak musí plnit:
• veškeré požadavky plynoucí z právních předpisů ve vztahu k subjektu Objednatele, který je financován z veřejných zdrojů, zejména pak požadavky plynoucí z níže zmíněných právních předpisů
• Požadavky ze zákona zákonem č. 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ů.
• požadavky plynoucí ze zákona č. 99/2019 Sb., o přístupnosti internetových stránek a mobilních aplikací a o změně zákona č. 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ů
• požadavky plynoucí z 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ů)
• požadavky plynoucí ze zákona č. 127/2005 Sb., o elektronických komunikacích a o změně některých souvisejících zákonů (zákon o elektronických komunikacích), ve znění pozdějších předpisů – zejména v souvislosti s používáním tzv. cookies
• požadavky plynoucí ze zákona č. 106/1999 Sb., o svobodném přístupu k informacím, ve znění pozdějších předpisů
23
Dále musí dodavatel v rámci řešení dodržet směrnice Web Content Accessibility
24 Guidelines (WCAG) 2.1
Technické parametry dostupnosti a výkonnosti
Objednatel požaduje dodávku kvalitně provedeného a optimalizovaného software a nikoliv software, který bude nedostatečnou kvalitu návrhu a zpracování na úrovni kódu a procesů kompenzovat nepřiměřenými systémový prostředky a požadavky na ně směrem k objednateli za účelem dodržení odezvy a funkcionality
25 systému.
Objednatel s ohledem na předpokládaný dlouhodobý provoz a životnost pořizovaného řešení požaduje, aby byla Aplikace postavena na současných, a nikoliv již překonaných/opouštěných technologiích, které zajistí dlouhodobou podporu daného řešení. Za překonané/opouštěné technologie jsou objednatelem považovány takové, u kterých v příštích 2 letech jejich tvůrce ukončí podporu jejich
26 životního cyklu a dále takové, jejichž vývoj a podpora již byly ukončeny.
ANO | Naplnění proběhne jako standardní součást dodávky |
ANO | Naplnění proběhne jako standardní součást dodávky |
- | - |
ANO | Naplnění proběhne jako standardní součást dodávky |
ANO | Naplnění proběhne jako standardní součást dodávky |
ANO | Naplnění proběhne jako standardní součást dodávky |
- | - |
Pro nasazenou Aplikaci v době spuštění do pilotního provozu, stejně jako pro Aplikaci v provozu platí následující požadované hodnoty:
• SLA (dostupnost Aplikace) 95 %
• Počet paralelně pracujících uživatelů 100
• První request (first byte) vyřízený do 300ms
• Maximální doba odezvy z Aplikace změřená službou xxxxxxxxxxx.xxx bude 2 sekundy na poskytnutých HW prostředcích KÚZK
• Maximální doba reakce chatbota na dotaz uživatele bude 4 sekundy na poskytnutých HW prostředcích KÚZK při vytížení 100 paralelních konverzací
27
V rámci akceptačních testů bude Objednatelem provedena kontrola pomocí veřejně dostupné kontrolní služby na adrese xxxxx://xxxxxxxxxxx.xxx/ kdy bude vyžadováno splnění celkového načtení úvodní stránky do 2 sekund. V případě, že bude načtení delší, musí Dodavatel provést opravy s cílem splnění SLA bez
28 omezení funkčnosti díla.
Kryptografie
Komunikace mezi částmi Aplikace bude probíhat v šifrované podobě. Stejně tak veškerá uživatelská nebo citlivá data budou ukládaná šifrovaně a přístup k nim bude zabezpečený. Budou použity pouze takové kryptografické prostředky, které
29 nejsou prolomeny, jsou aktuální a schvalované ze strany NÚKIB pro KIVS.
Kromě výše uvedeného musí Aplikace naplňovat rovněž uvedené minimální požadavky na kryptografii v dokumentu Technická specifikace, kapitole Šifrování
30 a kryptografie, které vychází z aktuální best-practice a z doporučení NÚKIB
Pro šifrování, elektronické podepisování a provádění otisků dat (hashování) nesmí být použity proprietární/uzavřené algoritmy, ale ty, které jsou považovány za standardy, jejich funkcionalita je všeobecně známá, popsaná a jsou všeobecně
31 považovány za bezpečné.
Bezpečnost
Pokud Aplikace zpracovává nebo umožňuje zpracovávat osobní údaje, pak
● musí být v souladu s Nařízením Evropského parlamentu a Rady EU 2016/679 - obecné nařízení o ochraně osobních údajů – General Data Protection Regulation (GDPR).
● musí splňovat všechny relevantní požadavky zákona 110/2019 Sb., o zpracování osobních údajů, které je možno zajistit technicky v Aplikaci. Aplikace bude např. automatizovaně pořizovat záznamy o operacích při zpracování osobních údajů v Aplikaci, dle ustanovení § 36.
● v případě webových stránek bude v souladu s Doporučením pro webové stránky, které je definováno ve stanovisku č. 1/2011 Úřadu pro ochranu osobních údajů.
● Řešení musí splňovat minimálně úrovně „A“ služeb pro ověření na adrese: xxxxx://xxx.xxxxxxx.xxx/
xxxxx://xxx.xxxxxxxxxxxxxxx.xxx/ xxxxx://xxxxxxxxxxx.xxxxxxx.xxx/
32
Aplikace musí mít nainstalovány všechny relevantní bezpečnostní záplaty již v době předání a stanoveny mechanismy pro implementaci aktuálních
33 bezpečnostních záplat během provozu.
U vstupních polí přístupných anonymním uživatelům (obsahuje-li je Aplikace) musí 34 mít webová Aplikace implementovány antispamové ochranné mechanismy.
Aplikace musí přistupovat do databáze (je-li součástí) jen prostřednictvím jednoho speciálního „společného“ účtu. (Není možno pro přístup do databáze používat účty uživatelů.) Tento účet musí být odlišný od administrátorského účtu, který bude
35 používán pro správu / vzdálenou správu.
Zajištění logování Aplikace bude dle 2. odst. §22 vyhlášky 82/2018 Sb., např. informace o činnosti uživatelů a administrátorů (přihlášení, odhlášení, manipulace s účty a oprávněními, úspěšné i neúspěšné pokusy činností, kritické i chybové
36 hlášení apod.).
V rámci logování bude zajištěna integrita informací pomocí adekvátních kryptografických prostředků (např. šifrování, el. podpis), aby bylo možné
37 jednoznačně určit, kdo změnu / operaci provedl.
Pro interní uživatele Objednatele musí Aplikace (část backoffice u ePortálu, část administrace u chatbota) umožnit následující:
● aplikace bude umožňovat import uživatelů, organizační struktury, rolí z identitního systému Objednatele (IDM – aplikace EOS) nebo Active Directory.
● aplikace bude umožňovat řízení přístupových oprávnění uživatelů (aplikačních rolí) a jejich správu z identitního systému Objednatele (IDM – aplikace EOS) nebo z Active Directory. Oprávnění přístupu k jednotlivým částem (min. na úrovni site) budou řízena pomocí členství ve skupině Active Directory;
● přebírat autentizaci uživatele ze systému MS Windows, tzn., že bude umožňovat přihlašování single sign-on (SSO); ověřování pomocí bezpečného protokolu (Kerberos).
38
Ověření bezpečnosti
ANO | Naplnění proběhne jako standardní součást dodávky |
ANO | Naplnění proběhne jako standardní součást dodávky |
ANO | Naplnění proběhne jako standardní součást dodávky frontend částí |
ANO | Naplnění proběhne jako standardní součást dodávky backend částí |
ANO | Naplnění proběhne jako standardní součást dodávky backend částí |
ANO | Naplnění proběhne jako standardní součást dodávky backend částí |
ANO | Naplnění proběhne jako standardní součást dodávky na míru objednateli |
- | - |
ANO | Naplnění proběhne jako standardní součást bezpečnosti dodávky |
ANO | Naplnění proběhne jako standardní součást bezpečnosti dodávky |
ANO | Naplnění proběhne jako standardní součást bezpečnosti dodávky |
ANO | Naplnění proběhne jako standardní součást bezpečnosti dodávky |
ANO | Naplnění proběhne jako standardní součást bezpečnosti dodávky |
ANO | Naplnění proběhne jako standardní součást bezpečnosti dodávky |
- | - |
ANO | Naplnění proběhne jako standardní součást bezpečnosti dodávky |
- | - |
ANO | Naplnění proběhne jako standardní součást SLA dodávky |
ANO | Naplnění proběhne jako standardní součást SLA dodávky |
ANO | Naplnění proběhne jako standardní součást SLA dodávky |
Aby mohl být informační systém zařazen do infrastruktury objednatele a akceptován, musí splňovat bezpečnostní opatření, která zajistí, že informační systém nebude vykazovat zranitelnosti při ověření penetračními testy minimálně
39 dle metodiky OWASP Testing Guide, ve stable verzi 4.2 [1].
Podmínkou pro akceptaci předmětu plnění je, aby žádný z případných nálezů penetračních testů neměl dle scoring systému CVSS v3.1 base score větší hodnotu
40 než 3.9.
Objednatel si vyhrazuje právo provést penetrační test jakékoliv části předmětu
41 plnění.
Dodavatel se zavazuje, že v rámci vývoje Aplikace byly provedeny nezávislé penetrační testy minimálně dle metodiky OWASP Testing Guide, ve stable verzi
4.2 a odstraněny všechny nálezy před nasazením u Objednatele. Z testu bude
42 doložen Objednateli protokol.
Během provozu Aplikace na KÚZK a smluvního vztahu s Dodavatelem zajišťuje Dodavatel Aplikace pravidelné penetrační testování minimálně jednou za rok v rámci interního vývoje. Aplikace bude testována minimálně dle metodiky OWASP Testing Guide, ve stable verzi 4.2. Dodavatel vyhotovuje záznamy o penetračním
43 testování a výsledky předloží Objednateli.
Aplikace musí být chráněna proti známým bezpečnostním chybám a hrozbám,
44 nejenom dle metodiky OWASP.
Zajištění bezpečnosti
Dodavatel je povinen zajistit bezpečný provoz dodávaného řešení. V případě zjištění zranitelnosti řešení, zejména v případě jejího zveřejnění a přidělení CVE označení, je Dodavatel povinen provést bezodkaladné opatření ke snížení dopadů takové zranitelnosti. Dále je Dodavatel povinen provést instalaci bezpečnostních záplat v termínech definovaných v tabulce služeb a SLA dokumentu Technická
45 specifikace dle závažnosti CVE dle scoring systému CVSS v3.1 base score.
Zajištění provozu
Pro Aplikace bude dodavatelem poskytovaná podpora po dobu 6 let podle přílohy
46 č. 2 Smlouvy.
Podpora se bude sestávat ze zajištění:
• Legislativních aktualizací Aplikace
• Bezpečnostních aktualizací Aplikace
• Odstraňování nahlášených vad
• Pravidelná profylaxe Aplikace
• Analýzy a realizace rozvoje dle požadavku Objednatele
47
Dodavatelem budou vyhodnocovány změny legislativy a rovněž aktuální bezpečnostní situace a varování v oblasti kyberbezpečnosti od bezpečnostních složek, NÚKIB, dodavatelů antivirových řešení apod., vůči těmto zjištěním bude komparovat nastavení Aplikace a v případě, že identifikuje zranitelnost Aplikace, provede vytvoření aktualizace/opravy, kterou nasadí nejprve do testovacího,
48 následně do produkčního prostředí Aplikace po schválení Objednatelem.
ANO | Naplnění proběhne jako standardní součást SLA dodávky |
ANO | Naplnění proběhne jako standardní součást SLA dodávky |
ANO | Naplnění proběhne jako standardní součást SLA dodávky |
ANO | Naplnění proběhne jako standardní součást SLA dodávky |
ANO | Naplnění proběhne jako standardní součást SLA dodávky |
ANO | Naplnění proběhne jako standardní součást SLA dodávky |
ANO | Naplnění proběhne jako standardní součást SLA dodávky |
ANO | Naplnění proběhne jako standardní součást SLA dodávky |
ANO | Naplnění proběhne jako standardní součást SLA dodávky |
Pokud o změně/zjištění třetí stranou bude informován nejprve Objednatel, oznámí jej Dodavateli skrze smluvený komunikační kanál, přičemž bude Dodavatel
49 reagovat na Změnu/zjištění v souladu s SLA dle kategorie požadavku.
Odstraňování nahlášených vad bude dodavatel realizovat rovněž na základě zjištění 50 vlastního nebo požadavku v časech SLA dle kategorie požadavku.
Dodavatel bude v rámci podpory provozu díla kvartálně realizovat profylaxi Aplikace, v rámci které ověří její stav, parametry a vyhodnotí nutnost změn. V případě, že se bude jednat o funkční vady, které ohrožují funkčnost, bezpečnost aplikace, případně dochází k nesouladu s legislativou, provede opravy bezodkladně a nasadí je po odsouhlasení Objednatele. V případě že během profylaxe objeví Dodavatel prostor pro zlepšení nebo modernizaci v souladu s aktuální best-practice, seznámí s těmito závěry Objednatele, který následně
51 rozhodne o pokračování v analýze v režimu rozvoje Aplikace.
Dodavatel bude v rámci podpory provozu díla realizovat analýzu a realizaci rozvoje na základě schválení realizace Objednatelem. V rámci analýzy provede analýzu obtížnosti a vyčíslí změnu nákladově a s časovým vyjádřením náročnosti změny vč. předpokládaného termínu nasazení. Realizaci rozvoje následně dle analýzy schvaluje Objednatel. Požadavky na rozvoj budou hlášeny stejným kanálem jako požadavky na odstranění vad dle SLA kategorie Nízká a SLA bude platit pro
52 analýzu rozvoje. Pro realizaci bude platit termín daný analýzou.
Dodavatel je povinen zajistit bezpečný provoz dodávaného řešení. V případě zjištění zranitelnosti řešení, zejména v případě jejího zveřejnění a přidělení CVE označení, je Dodavatel povinen provést bezodkaladné opatření ke snížení dopadů takové zranitelnosti. Dále je Dodavatel povinen provést instalaci bezpečnostních záplat v termínech definovaných v tabulce služeb a SLA dle závažnosti CVE dle
53 scoring systému CVSS v3.1 base score.
Během provozu Aplikace na KÚZK a smluvního vztahu s Dodavatelem zajišťuje Dodavatel Aplikace pravidelné penetrační testování minimálně jednou za rok v rámci interního vývoje. Aplikace bude testována minimálně dle metodiky OWASP Testing Guide, ve stable verzi 4.2. Dodavatel vyhotovuje záznamy o penetračním
54 testování a výsledky předloží na požádání.
Bezpečnost řešení Aplikace musí být po celou dobu podpory chráněna proti
55 známým bezpečnostním chybám a hrozbám, nejenom dle metodiky OWASP.
Dodavatelem bude poskytována servisní podpora dle parametrů SLA, stanovených
56 v kapitole Taxxxxx xlužeb a SLA přílohy č. 2 Smlouvy
Vytvoření a zpřístupnění systému HelpDesk v souladu s podmínkymi přílohy č 2 57 Smlouvy, kap. III
Požadovaná vlastnost (požadavky) | Splňuje uchazeč požadavky (Ano/Ne) | Popis naplnění požadavků dodavatelem |
ePortál | - | - |
ePortál Zlínského kraje (dále jako ePortál) bude navržen jako moderní portálové modulární řešení, které bude nasazeno on-premise v rámci ICT infrastruktury Zlínského kraje. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní součást navržené a realizované architektury portálu. |
ePortál bude rozdělen na tři části – na veřejnou část, neveřejnou část a backoffice část. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní součást navržené a realizované architektury portálu. |
ePortál bude obsahovat integrační rozhraní, skrze které bude možné realizovat integrace mezi částmi ePortálu a rovněž s externími informačními systémy a aplikacemi. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní součást navržené a realizované architektury portálu. |
Backend ePortálu bude navržen s využitím aktuálních a bezpečných algoritmů, které nevykazují kybernetickou zranitelnost. Backend bude rozdělen do dvou oddělených instancí – první pro backoffice část a druhou pro veřejnou a neveřejnou část. Tyto instance budou nasazeny na oddělené infrastruktuře a budou fungovat v rozdílných úsecích sítě. Mezi těmito částmi bude zajištěna zabezpečená a logovaná integrace umožňující předávání informací mezi instancemi. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní součást navržené a realizované architektury portálu. |
Frontend ePortálu bude navržen s využitím aktuálních a bezpečných algoritmů, které nevykazují kybernetickou zranitelnost a bude reflektovat požadavky subkapitoly Zobrazení. Frontend bude navržen ve třech prostředích. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní součást navržené a realizované architektury portálu. |
Pro všechna prostředí platí, že frontend bude konfigurovatelný přes administraci ePortálu, bude tedy možné měnit strukturu a zobrazení frontendu administrátorem s využitím grafického rozhraní ePortálu přes WYSIWYG editor, jenž bude součástí ePortálu. | ANO | Bude realizováno přes CMS komponentu portálu. |
Veřejné prostředí bude navrženo jako veřejně přístupné prostředí bez vázanosti na uživatelské role a IP adresu. Bude zobrazovat modul aktuality, modul články, klienta chatbota instance veřejné části ePortálu a bude zajišťovat přechod do neveřejného prostředí. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní součást navržené a realizované architektury portálu. |
Neveřejné prostředí bude navrženo jako zabezpečené prostředí vázané na autentizaci přes prostředky důvěryhodné autentizace NIA a ISDS. Výchozí role uživatelů neveřejného prostředí budou předdefinované a přiřazované na základě důvěryhodného přihlášení uživatele. Neveřejná část bude zobrazovat moduly: | ANO | Naplnění proběhne dle definovaných požadavků jako standardní součást navržené a realizované architektury portálu. |
Backoffice prostředí bude realizováno backendem oddělené instance pro backoffice a bude vázané na autentizační rozhraní Zlínského kraje a jeho příspěvkových organizací – Identity managment systém nebo Active-directory. Prostředí bude přístupné pouze ze sítě Zadavatele přes VLAN a nebude do něho možné přistupovat z jiného prostředí ePortálu. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní součást navržené a realizované architektury portálu. |
Integrace mezi Backoffice prostředím a dalšími prostředími ePortálu musí být realizované jako zabezpečené logované integrace s šifrovaným přenosem dat. Integraci a přenos dat nebude možné odposlechnout, nebude možné údaje změnit, ani zaslat integračním rozhraním škodlivý SW či jiná než schválená data. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní součást navržené a realizované architektury portálu. |
Zobrazení | - | - |
Pořadové číslo
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
Grafická podoba ePortálu bude vycházet z UI analýzy Dodavatele a výsledného grafického návrhu, který schválí Zadavatele. Struktura a zobrazení bude reflektovat Design systém xxx.xx (xxxxx://xxxxxxxxxxxx.xxx.xx/), ale rovněž požadavky Zadavatele k vizuální identitě Zadavatele a doporučení vzniklé z UX testování, které v rámci projektu bude Dodavatel realizovat. | ANO | Grafická podoba bude respektovat požadavky a bude navržena a odsouhlasena v analytické fázi realizce |
Zobrazení bude v souladu s platnou legislativou v oblasti ČR, především zákona č. 99/2019 Sb. o přístupnosti internetových stránek a mobilních aplikací a se zákonem č. 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ů. | ANO | Grafická podoba bude respektovat legislativní požadavky. |
Jednotlivá prostředí a stránky budou strukturovány jako sémanticky korektní web – tj. přehledně formátované HTML s využitím HTML 5 a stylováním v CSS3. ePortál tedy bude mít správně strukturovaný HTML kód. Dále využije principů komprimace a minifikace vkládaných skriptů (pro CSS a JS). | ANO | Šablony frontend částí budou realizovánu v souladu s pravidli sémantického webu. |
ePortál bude navržen jako plně responzivní řešení, tj. zobrazení ePortálu se bude měnit podle velikosti displeje zobrazovacího zařízení, vč. podpory mobilních zařízení – tabletů a mobilních telefonů. | ANO | Šablony frontend částí budou realizovány jako plně responsivní. |
Prostředí bude umožňovat zobrazení libovolných HTML elementů, podporováno bude vkládání multimédií – obrázků, videí. Tyto elementy budou vložitelné v rámci WYSIWYG editoru, přes který se bude konfigurovat vzhled, struktura a obsah stránek. Za strukturu stránek ePortálu a naplnění legislativy je zodpovědný Dodavatel, následně po převzetí odpovídá za soulad úprav s legislativou Zadavatel. | ANO | Šablony frontend částí včetně CMS budou realizovány v souladu s požadavkem. |
Služby | - | - |
Služba autentizace přes důvěryhodné přihlášení – ePortál umožní autentizaci do neveřejné části portálu přes autentizační rozhraní. Jako autentizační rozhraní budou využity Národní bod pro identifikaci a autorizaci (NIA) a datové schránky (ISDS) a dále bude realizována integrace na Identity management Zlínského kraje (IDM) či Active-directory pro backoffice část. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní součást navržené a realizované architektury portálu. |
Informační služby – ePortál bude poskytovat v rámci všech prostředí informace pro uživatele ve formě článků a aktualit. | ANO | Naplnění proběhne na úrovni CMS a obsahové části portálu. |
Přístup k dokumentům a informacím – ePortál bude zpřístupňovat data a soubory. U souborů umožní jejich stažení. Data a soubory budou zpřístupněny pouze uživatelům dle jejich oprávnění. | ANO | Naplnění proběhne jako standardní součást portálových komponent. |
Formulářové služby – ePortál bude obsahovat formulářové řešení, které umožní navrhovat elektronické formuláře, zobrazitelné v rámci UI portálu s následnou možností jejich vyplnění uživatelem. Formulář bude předvyplněn údaji, které jsou o uživateli již známé skrze autentizaci a bude obsahovat masky, kterými bude kontrolovat uživatelem zadané informace dle jednotlivých kolonek formuláře. | ANO | Součástí dodávky portálu bude formulářová komponenta s požadovanými parametry. |
Služba elektronické podání – ePortál umožní elektronické podání formuláře na podatelnu. Podání bude zasíláno do podatelen příspěvkových organizací a Zlínského kraje (typově dvě spisové služby). | ANO | Naplnění proběhne na základe důvěryhodné identifikace odesílatele a integrace na spisovou službu dle národního standardu. |
Služba sledování stavu podání – ePortál následně umožní v rámci neveřejné části uživateli sledovat jeho podání v jakém se nachází stavu. Tento údaj bude přebírán ePortálem ze spisové služby. | ANO | Naplnění proběhne na základe důvěryhodné identifikace odesílatele a integrace na spisovou službu dle národního standardu. |
Služba platba přes platební bránu – ePortál umožní zaplatit uživateli poplatky přes platební bránu, která bude v portálu integrovaná. Umožní realizovat platbu na účet Zlínského kraje nebo účty příspěvkových organizací. | ANO | Naplnění proběhne na základe důvěryhodné identifikace odesílatele a integrace na platební bránu. |
Služba historie plateb – ePortál bude v rámci neveřejné části uživateli zobrazovat historii jeho plateb realizovaných přes ePortál. | ANO | Naplnění proběhne na základe důvěryhodné identifikace odesílatele a integrace na platební bránu. |
Služba statistika uživatele – ePortál bude pro uživatele vytvářet statistiku jeho využití ePortálu ve formě informačního dashboardu. | ANO | Bude součástí architektury portálu se zobrazením v uživatelském rozhraní. |
Služba výstupy z datového skladu – ePortál umožní přebírat data z datového skladu Zlínského kraje. | ANO | Bude součástí architektury portálu se zobrazením v uživatelském rozhraní. |
Služba výstupy z digitálního repozitáře – ePortál umožní v rámci backoffice části dotazování do IS Digitální repozitář, následně převezme výsledky vyhledávání a umožní uživateli stažení požadované datové sady dvou typů. | ANO | Bude součástí architektury portálu se zobrazením v uživatelském rozhraní. |
Služba administrace dotace – ePortál bude sloužit jako aplikační řešení pro řešení krajských dotací. Umožní zažádat o dotaci přes neveřejnou část s následnou administrací dotace v backoffice části portálu. | ANO | Modul bude součástí architektury portálu s dodáním na míru Zadavateli. |
Služba notifikace – ePortál bude umožňovat zasílání notifikací uživatelů prostřednictvím SMS a e-mailem. | ANO | Modul bude součástí architektury portálu s dodáním na míru Zadavateli. |
Služba uživatelské administrace – ePortál umožní uživatelskou administraci podle typu uživatele od základního nastavení komunikačního kanálu notifikace pro občana či firmu až po komplexnější administraci pracovníka kraje. | ANO | Modul bude součástí architektury portálu a využije funkcionality CMS |
Služba administrace modularity – ePortál umožní správcům modulů konfigurovat jejich modul. | ANO | Modul bude součástí architektury portálu s dodáním na míru Zadavateli. |
Služba administrace ePortálu – ePortál bude obsahovat administraci, řešící systémové fungování ePortálu, vč. konfigurace portálu, modulů, formulářů, monitoringu, log managementu, správy rolí, managementu databáze ePortálu. | ANO | Modul bude součástí architektury portálu a využije administrátorských funkcionalit CMS |
Výstupy | - | - |
Implementační analýza – Dodavatel realizuje implementační analýzu, v rámci které ve spolupráci se Zadavatelem upřesní požadavky na cílový systém ePortál a způsob realizace. Součástí bude popis cílového systému pro jeho realizaci a nasazení. Analýzu akceptuje Zadavatel po vypořádání připomínek. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup |
Vytvoření grafického návrhu - V rámci implementační analýzy vznikne vizuální návrh ePortálu, který bude ve 3 variantách představen Zadavateli, ten následně předá Dodavateli pokyny k dalším úpravám vizuálního návrhu a akceptuje vítěznou variantu po zakomponování požadavků Zadavatele. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup |
Vytvoření ePortálu – Dodavatel realizuje vývoj/dodání díla v rámci prostředí Dodavatele do cílové podoby, požadované Zadavatelem. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup |
Kontrolní analýza – Dodavatel naváže na implementační analýzu, ověří stav systému po jeho vytvoření a aktualizuje případné požadavky na implementaci. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup |
Implementace do testovacího prostředí – Dodavatel za spolupráce Xxxxxxxxxx realizuje implementaci ePortálu do testovacího prostředí Zadavatele. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup |
Realizace integrací – Dodavatel zajistí ve spolupráci se Zadavatelem integraci ePortálu na cílové systémy dle implementační a kontrolní analýzy. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup |
Vytvoření formulářů – Dodavatel vytvoří elektronické formuláře v rámci ePortálu dle vstupních podkladů od Zadavatele (30 formulářů). | ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup |
Vytvoření životních situací – Dodavatele vytvoří informační články typu životní situace v rámci ePortálu dle vstupních podkladů od Zadavatele (20 článků). | ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup |
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
Realizace testů – Dodavatel zajistí sadu testů, kterými ověří parametry ePortálu. Dodavatel otestuje ePortál již v rámci svého vývojového prostředí, následně budou testy realizované na testovacím prostředí Zadavatele a pro ověření následně na produkčním. Dodavatel realizuje minimálně následující testy: | ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup |
Performance testy – pro vývojové prostředí Dodavatele a testovací prostředí Zadavatele, v rámci testu bude ověřena odezva systému a vytížení HW, testy budou realizovány při simulaci vysokého vytížení. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup |
Funkční testy – pro tyto testy vytvoří Dodavatel testovací scénáře a bude je realizovat společně se Zadavatelem. Z funkčních testů vznikne seznam případných zjištění – vad, které Dodavatel odstraní a následně se provede další iterace funkčních testů. Testy budou realizované pro všechna prostředí a scénáře budou reflektovat funkcionality daného prostředí. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup |
Bezpečnostní testy – Dodavatel zajistí nezávislé bezpečnostní otestování ePortálu vč. všech jeho prostředí třetí stranou včetně penetračních testů. Testy budou realizovány dle metodiky OWASP TOP10. Případné zjištěné chyby Dodavatel odstraní. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup |
UX/UI testy – Dodavatel ve spolupráci se Zadavatelem zajistí UX/UI testy prostředí portálu a provede úpravy podle zjištěných neoptimalit UX/UI portálu. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup |
Akceptační testy – realizuje Zadavatel, Xxxxxxxxx je povinen odstranit nedostatky, nalezené testy. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup |
mplementace do produkčního prostředí – Dodavatel zajistí migraci ePortálu do produkčního prostředí Zadavatele po odstranění případných vad z testování a akceptaci Zadavatele. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup |
Vytvoření systémové dokumentace – Dodavatel vytvoří pro ePortál systémovou dokumentaci popisující technický stav ePortálu a dále vytvoří dokumentaci pro administrátory, která bude popisovat správu ePortálu a jeho prostředí. Současně vytvoří Dodavatel uživatelskou dokumentaci pro uživatele neveřejné části a uživatele backoffice části ePortálu. Dokumentace bude rovněž k dispozici jako nápověda v rámci UI prostředí ePortálu. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup |
Školení – Dodavatel zrealizuje školení v prostorách Zadavatele, přičemž bude realizovat oddělené školení pro administrátory (vč. administrátorů modulů) a pro uživatele. Uživatelské školení bude společné pro školené z řad Zadavatele a zástupců příspěvkových organizací Zadavatele. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup |
Předání zdrojových kódů – Dodavatel předá pro vyvíjené části systému zdrojové kódy Zadavateli jako strojově čitelná data vč. manuálu popisujícího strukturu zdrojových kódů a jejich kompilaci/spuštění, a to dle podmínek uvedených v čl. IV. Smlouvy. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup |
Předání licencí – Dodavatel k dílu předá nevýhradní časově, početně a místně neomezenou licenci. Současně předá licence k SW třetích stran, budou-li využity v rámci díla a rovněž předá licence k technologickému SW, které dílo bude využívat. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup |
Asistence při pilotním provozu – Dodavatel poskytne Zadavateli podporu při pilotním provozu díla, která se bude spočívat v součinnosti při vyhodnocování parametrů provozu a dále zajistí odstranění případných vad a neoptimalit, které se mohou při pilotním provozu projevit a nasadí jejich opravu nejprve do testovacího prostředí a po schválení Zadavatelem do produkce. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup |
Moduly | - | - |
108
109
110
111
112
113
114
115
Součásdtí ePortálu budou moduly: • modul aktuality, • modul články, • modul elektronické formuláře, • modul platby, • modul sledování podání, • modul historie plateb, • modul uživatelská statistika, • modul administrace dotací, • modul výstupy z datového skladu, • modul výstupy z digitálního repozitáře, • modul dokumenty, • modul uživatelská administrace, • modul administrace modularity, • modul administrace ePortálu. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní součást navržené a realizované architektury portálu. |
Modul aktuality | - | - |
Modul aktuality bude sloužit k zobrazení aktualit vlastníka ePortálu nebo některého z autorizovaných vkladatelů aktualit Zadavatelem. | ANO | Naplnění proběhne formou standardního modulu aktualit CMS včetné customizací na míru dle požadavků |
Aktuality budou obsahovat obrázek, datum vystavení, klíčová slova, kategorii aktuality, perex, obsah aktuality, zobrazení těchto atributů bude volitelné autorem. U aktuality bude možné vybrat pro které části ePortálu se budou publikovat – veřejná/neveřejná/backoffice či kombinace částí portálu. Obsah aktuality bude vkládaný skrze WYSIWYG editor. | ANO | Naplnění proběhne formou standardního modulu aktualit CMS včetné customizací na míru dle požadavků |
Aktuality se budou vkládat/editovat/publikovat/odstraňovat v rámci backoffice prostředí a následně budou publikované v rámci vybraných prostředí. Publikaci bude možné odložit, omezit její platnost. Vkládat aktuality bude příslušná role v rámci systému rolí. | ANO | Naplnění proběhne formou standardního modulu aktualit CMS včetné customizací na míru dle požadavků |
Aktuality bude možné provázat na notifikace, resp. zvolit, zda při publikaci dojde k notifikaci uživatelům o nové aktualitě. | ANO | Naplnění proběhne formou standardního modulu aktualit CMS včetné customizací na míru dle požadavků |
Aktuality pro neveřejné a backoffice uživatele by měly být zobrazeny v rámci dashboardu úvodní strany neveřejného a backoffice prostředí. | ANO | Naplnění proběhne formou standardního modulu aktualit CMS včetné customizací na míru dle požadavků |
U aktuality bude možné nastavit vlastní URL. | ANO | Naplnění proběhne formou standardního modulu aktualit CMS včetné customizací na míru dle požadavků |
Modul články | - | - |
Modul články bude realizován obdobně jako aktuality s tím rozdílem, že půjde o stránky s delším obsahem a budou součástí jiné sekce. Oproti aktualitám bude možné k jednotlivým publikovaným článkům možné omezit přístup pro určité role nebo uživatele. | ANO | Naplnění proběhne formou standardního modulu aktualit CMS včetné customizací na míru dle požadavků |
Články budou obsahovat obrázek, datum vystavení, klíčová slova, kategorii článku, perex, obsah článku, zobrazení těchto atributů bude volitelné autorem. U článku bude možné vybrat pro které části ePortálu se budou publikovat – veřejná/neveřejná/backoffice či kombinace částí portálu. Obsah článku bude vkládaný skrze WYSIWYG editor. | ANO | Naplnění proběhne formou standardního modulu aktualit CMS včetné customizací na míru dle požadavků |
118
119
120
121
122
123
124
125
126
Ćlánky se budou vkládat/editovat/publikovat/odstraňovat v rámci backoffice prostředí a následně budou publikované v rámci vybraných prostředí. Publikaci bude možné odložit, omezit její platnost. Vkládat aktuality bude příslušná role v rámci systému rolí. Bude rovněž možné duplikovat existující články a na základě duplikátu vytvořit nový článek za pomocí editace duplikovaného článku. | ANO | Naplnění proběhne formou standardního modulu aktualit CMS včetné customizací na míru dle požadavků |
Články budou mít verzovatelné, tedy bude se ukládat historie článků a bude možný návrat k původním verzím článku. U článku bude možné nastavit vlastní URL. | ANO | Naplnění proběhne formou standardního modulu aktualit CMS včetné customizací na míru dle požadavků |
Články bude možné provázat na notifikace, resp. zvolit, zda při publikaci dojde k notifikaci vybraným uživatelům o novém článku | ANO | Naplnění proběhne formou standardního modulu aktualit CMS včetné customizací na míru dle požadavků |
Pro veřejnou část portálu budou existovat články typu Životní situace. Ty budou se standardizovanou strukturou sloužit k informování občanů o řešení své životní situace u Zadavatele nebo jeho příspěvkové organizace. | ANO | Naplnění proběhne formou standardního modulu aktualit CMS včetné customizací na míru dle požadavků |
V rámci dodání bude Dodavatelem vytvořeno 20 článků životních situací. Další články bude vytvářet Zadavatel na základě dokumentace a školení Dodavatele duplikací existujících životních situací a jejich úpravou. | ANO | Naplnění proběhne formou standardního modulu aktualit CMS včetné customizací na míru dle požadavků |
Modul elektronické formuláře | - | - |
Modul elektronické formuláře bude obsahovat editor formulářů a prohlížeč formulářů. Modul bude řešen jako webové řešení s návrhem a zobrazením formulářů v rámci UI ePortálu, není možný redirect na jiný externí SW mimo ePortál či doménu. | ANO | Naplnění proběhne formou dodávky formulářového modulu, jeho integrace do CMS včetně customizací na míru dle požadavků |
Formuláře budou k dispozici v neveřejné části ePortálu a budou tvořeny v backoffice části. Formuláře bude možné v rámci seznamu formulářů neveřejné části ePortáu členit do více úrovní dle příjemce nebo kategorie. | ANO | Naplnění proběhne formou dodávky formulářového modulu, jeho integrace do CMS včetně customizací na míru dle požadavků |
Editor formulářů bude realizovat grafické vytvoření formuláře a jeho kolonek. Editor bude fungovat v režimu návrhu a v režimu náhledu na hotový formulář. V rámci editace bude docházet k návrhu formuláře a v rámci náhledu bude možné sledovat formulář a jeho chování ve stejné podobě jako v prohlížeči formulářů. | ANO | Naplnění proběhne formou dodávky formulářového modulu, jeho integrace do CMS včetně customizací na míru dle požadavků |
V rámci kolonek bude možné navázat tyto atributy na existující dostupné atributy ePortálu (např. údaje přebírané z NIA/ISDS., údaje přebírané z některého modulu ePortálu). Tyto atributy by následně byly vyplňovány v rámci prohlížeče automaticky z daného datového zdroje. | ANO | Naplnění proběhne formou dodávky formulářového modulu, jeho integrace do CMS včetně customizací na míru dle požadavků |
U kolonek bude možné nastavit jejich masku v rámci vytvoření a editace kolonky. Masky budou obsahovat předdefinované masky (např. telefon, e-mail, jméno, adresa, PSČ apod.) a v případě, že v rámci prohlížeče bude následně uživatel vkládat údaje ve špatném formátu, bude na to upozorněn a vyzván k jejich opravě, nebude možné formulář s těmito špatně vloženými údaji odeslat. | ANO | Naplnění proběhne formou dodávky formulářového modulu, jeho integrace do CMS včetně customizací na míru dle požadavků |
U kolonek bude možné stanovit, zda se jedná o povinně vyplňované kolonky nebo volitelně vyplňované. U povinně vyplňovaných pak nebude v rámci prohlížeče možné odeslat formulář bez jejich vyplnění. Formuláře umožní vkládání log a jiných grafických či HTML prvků. | ANO | Naplnění proběhne formou dodávky formulářového modulu, jeho integrace do CMS včetně customizací na míru dle požadavků |
129
130
131
132
133
134
135
136
137
U formuláře bude nastavitelný příjemce formuláře, resp. spisová služba příjemce. Příjemce formuláře bude vždy minimálně jeden. Pokud bude příjemců více, bude možné navolit, zda je příjemce povinný či nepovinný, případně určit omezovací kritéria, kolik příjemců musí uživatel vybrat (např. minimálně jednoho). | ANO | Naplnění proběhne formou dodávky formulářového modulu, jeho integrace do CMS včetně customizací na míru dle požadavků |
Formulář by měl umožnit podpis formuláře přes elektronický podpis – konkrétní detail bude řešit implementační analýza. Tento požadavek (na podpis formuláře) bude zadáván v rámci konfigurace formuláře. | ANO | Naplnění proběhne formou dodávky formulářového modulu, jeho integrace do CMS včetně customizací na míru dle požadavků |
Formuláře bude možné ukládat, editovat, mazat, publikovat. Bude rovněž možné duplikovat existující formuláře a na základě duplikátu vytvořit nový formulář za pomocí editace duplikovaného formuláře. Publikace bude probíhat do neveřejné části ePortálu, bude možné omezit přístup k formulářům na základě rolí. | ANO | Naplnění proběhne formou dodávky formulářového modulu, jeho integrace do CMS včetně customizací na míru dle požadavků |
Prohlížeč formulářů umožní obdobně jako náhled v rámci editoru formuláře zobrazení formuláře a vyplnění jeho kolonek. | ANO | Naplnění proběhne formou dodávky formulářového modulu, jeho integrace do CMS včetně customizací na míru dle požadavků |
Uživateli bude po vybrání formuláře k vyplnění zobrazen daný elektronický formulář, který následně vloží po odsouhlasení uživatele automaticky doplňované údaje z dostupných zdrojů. Pokud nebudou tyto údaje k dispozici, bude možné je vyplnit uživatelsky, avšak tyto atributy budou obsahovat v metadatech informaci, že se jedná o uživatelem vkládané údaje. | ANO | Naplnění proběhne formou dodávky formulářového modulu, jeho integrace do CMS včetně customizací na míru dle požadavků |
Při vyplňování bude uživatel upozorňován na špatně zadávané údaje za pomocí masek kolonek formuláře. Po vyplnění formuláře před jeho odesláním dojde k automatické kontrole a v případě, že nebudou vyplněny povinné údaje a/nebo budou kolonky vyplněny ve špatném formátu, bude vyzván uživatel k nápravě s vyznačením chyb a upozorněním na chyby. Součástí podávaného formuláře mohou být přílohy. K formuláři tedy bude možné přiložit přílohy, přičemž pole pro přílohu rovněž půjde vyznačit jako povinné, stejně jako kolonky formuláře. | ANO | Naplnění proběhne formou dodávky formulářového modulu, jeho integrace do CMS včetně customizací na míru dle požadavků |
Při vyplňování formuláře bude možné si formulář uložit v rozpracovaném stavu a později se k němu vrátit, pokud bude v té době formulář stále platný nebo nebude stanoveno časové omezení k návratu do formuláře. | ANO | Naplnění proběhne formou dodávky formulářového modulu, jeho integrace do CMS včetně customizací na míru dle požadavků |
Před odesláním může být uživatel vyzván k podpisu. | ANO | Naplnění proběhne formou dodávky formulářového modulu, jeho integrace do CMS včetně customizací na míru dle požadavků |
Dále uživatel obdrží informaci o příjemcích formuláře, přičemž je-li příjemců více, může vybrat jednoho či více příjemců formuláře (na základě konfigurace formuláře). | ANO | Naplnění proběhne formou dodávky formulářového modulu, jeho integrace do CMS včetně customizací na míru dle požadavků |
Formulář bude následně odeslán ePortálem do spisové služby dané organizace či organizací (spisové služby Ginis nebo Geovap). Konkrétní detail publikace formuláře vč. kanálu bude řešit implementační analýza. Formuláře budou zasílány jako strojově čitelné soubory v otevřeném formátu, předpoklad je .csv nebo .xml. | ANO | Naplnění proběhne formou dodávky formulářového modulu, jeho integrace do CMS včetně customizací na míru dle požadavků |
Specifickými budou formuláře související s dotacemi, ty budou kromě standardní cesty podání předání skrze integraci do modulu administrace dotací, kde budou následně vytěžovány a administrovány. | ANO | Naplnění proběhne formou dodávky formulářového modulu, jeho integrace do CMS včetně customizací na míru dle požadavků |
139
140
141
142
143
144
145
146
Pro formuláře dotací bude rovněž umožněno, aby byly uživateli navráceny administrátorem dotace z backoffice části portálu. V takovém případě se formulář objeví v seznamu rozpracovaných formulářů, ale bude vyznačen jako vrácený k opravě. Případně bude takto vyznačen v rámci historie podání – bude řešeno implementační analýzou. Uživatel bude o tomto notifikován. Následně bude mít možnost tento formulář opravit a zaslat zpět k opětovné kontrole. | ANO | Naplnění proběhne formou dodávky formulářového modulu, jeho integrace do CMS včetně customizací na míru dle požadavků |
Modul platby | - | - |
Modul platba bude obsahovat funkcionality editor plateb a zadávání plateb. Modul umožní návrh šablon elektronických plateb a přebírání údajů do platební brány s následnou možností zaplatit uživatelem skrze platební bránu v ePortálu. | ANO | Naplnění bude realizováno dodávkou modulu platby na míru požadavkům Zadavatele a jeho integrace do CMS a okolí portálu |
Editor plateb bude fungovat v backoffice části ePortálu a hotové šablony plateb budou přebírány do neveřejné části, kde budou přes zadávání plateb realizovány. | ANO | Naplnění bude realizováno dodávkou modulu platby na míru požadavkům Zadavatele a jeho integrace do CMS a okolí portálu |
Editor plateb umožní nastavit jednotlivé platby s předvyplněním atributů plateb (číslo účtu, název platby, částku, variabilní, specifický či konstantní symbol apod.), tyto atributy mohou být následujících typů: • Zadané správcem • Přebírající údaje uživatele z dostupných údajů • Zadávané uživatelem • Vybírané uživatelem přes listbox či obdobný UI prvek | ANO | Naplnění bude realizováno dodávkou modulu platby na míru požadavkům Zadavatele a jeho integrace do CMS a okolí portálu |
Atributy zadá správce modulu (Zadané správcem) nebo budou vázány na uživatelské údaje, které se budou doplňovat automaticky, obdobně jako u formulářů z dostupných dat o uživateli (Přebírající údaje uživatele z dostupných údajů). Dalším typem atributu platby bude atribut k doplnění uživatelem, který vyplní uživatel (Zadávané uživatelem). Zde bude obdobně jako u formulářů nasazen systém šablon, který bude kontrolovat správnost formátu zadávaných dat. Posledním typem je atribut, který uživatel vybere skrze rozevírací seznam (Vybírané uživatelem přes listbox), možnosti ze seznamu bude zadávat správce v rámci vytváření plateb. | ANO | Naplnění bude realizováno dodávkou modulu platby na míru požadavkům Zadavatele a jeho integrace do CMS a okolí portálu |
Následně po vytvoření platby (šablony platby) vypublikuje platbu správce přes editor do neveřejné části ePortálu. Platby bude opět možné v rámci neveřejné části vázat na uživatelské role. | ANO | Naplnění bude realizováno dodávkou modulu platby na míru požadavkům Zadavatele a jeho integrace do CMS a okolí portálu |
Zadávání plateb je funkcionalita v rámci neveřejné části portálu, která umožní uživateli dospecifikovat platbu (uživatelsky doplňované nebo vybírané atributy platby) a platbu následně provést přes platební bránu, do které bude takto dospecifikovaná šablona platby zaslána. | ANO | Naplnění bude realizováno dodávkou modulu platby na míru požadavkům Zadavatele a jeho integrace do CMS a okolí portálu |
Platby (šablony plateb) budou v rámci neveřejné části portálu kategorizovány do více úrovní obdobně jako u formulářů, bude je možné kategorizovat dle typu platby, příjemce či jiného kritéria Zadavatele. | ANO | Naplnění bude realizováno dodávkou modulu platby na míru požadavkům Zadavatele a jeho integrace do CMS a okolí portálu |
ePortál bude podporovat platební brány Comgate, Gopay, PayU s možností změny platební brány v rámci realizace projektu nebo rozvoje v rámci servisních prací na ePortálu. Platební bránu bude zajišťovat Zadavatel. | ANO | Naplnění bude realizováno dodávkou modulu platby na míru požadavkům Zadavatele a jeho integrace do CMS a okolí portálu |
Modul sledování podání | - | - |
148
149
150
151
152
153
154
Modul sledování podání umožní uživateli v neveřejné části ePortálu sledovat stav podání, které učinil přes ePortrál v rámci modulu elektronické formuláře. Údaje o stavu podání budou přebírány ze spisových služeb (přijato, zpracováváno, předáno, uzavřeno apod.). Stavy podání budou k dispozici v rámci seznamu podání. Na změnu stavu podání bude možné navázat notifikaci. V rámci sledovaného podání bude k dispozici podávaný dokument, který byl předán do spisové služby a bude možné jej stáhnout daným uživatelem z ePortálu. | ANO | Naplnění bude realizováno dodávkou modulu podání na míru požadavkům Zadavatele a jeho integrace do CMS a okolí portálu (integrací) |
Modul historie plateb | - | - |
Modul historie plateb bude přebírat realizované platby a zobrazovat je ve formě přehledného seznamu v sekci neveřejné části ePortálu. Seznam bude obsahovat stav platby (neúspěšná, dokončená apod.) a veškeré údaje dané platby (typ platby, částka, příjemce, VS, SS, KS, datum a čas platby, poznámka apod.). | ANO | Naplnění bude realizováno dodávkou modulu podání na míru požadavkům Zadavatele a jeho integrace do CMS a okolí portálu (integrací) |
K platbám bude možné administrátorem přiřadit stav „zaúčtováno“, který se propíše do neveřejné části ePortálu k historii platby. Stav zaúčtováno bude možné řešit importem s ID platby. Konkrétní detail bude analyzovat implementační analýza. Zvažované je rovněž přebírání stavu platby (zaúčtováno) do historie plateb přímo z IS Ginis Zadavatele, tuto možnost bude řešit implementační analýza. | ANO | Naplnění bude realizováno dodávkou modulu podání na míru požadavkům Zadavatele a jeho integrace do CMS a okolí portálu (integrací) |
Modul administrace dotací | - | - |
Modul administrace dotací bude sloužit k administraci dotací, které poskytuje nebo zprostředkovává Zadavatel. Modul bude řešit administraci dotací vč. vedení jednotlivých dotací, sběru žádostí, hodnocení žádostí, vytváření dokumentů k dotacím a výstupních sestav. Z modulu bude rovněž možné provádět vytěžování dat do exportního souboru v otevřeném formátu. | ANO | Naplnění bude realizováno dodávkou modulu dotací na míru požadavkům Zadavatele a jeho integrace do CMS a okolí portálu |
Administrace dotací bude striktně fungovat v rámci backoffice části ePortálu a přístup do něj bude mít pouze uživatelská role s definovanými oprávněními. | ANO | Naplnění bude realizováno dodávkou modulu dotací na míru požadavkům Zadavatele a jeho integrace do CMS a okolí portálu |
Modul bude přebírat vstupní formuláře žádostí o dotaci od uživatelů z neveřejné části portálu. Tyto žádosti budou v rámci administrace kontrolovány a schvalovány. V rámci hodnocení žádosti bude možné vrátit uživateli formulář s chybami vč. vyznačení chyb s průvodní informací k vrácenému formuláři. Formulář bude moci uživatel zaslat v rámci workflow procesu zpět opravené k opětovné kontrole. | ANO | Naplnění bude realizováno dodávkou modulu dotací na míru požadavkům Zadavatele a jeho integrace do CMS a okolí portálu |
Formuláře se budou vázat na jednotlivé dotace, které budou v ePortálu vedeny jako datové objekty, které bude možné dále sdružovat do skupin – např. program s více dotacemi. Data z formulářů bude možné v rámci modulu selektovat a vytěžit, čímž je bude možné přebírat do dalších číselníků modulu. | ANO | Naplnění bude realizováno dodávkou modulu dotací na míru požadavkům Zadavatele a jeho integrace do CMS a okolí portálu |
Pro uživatele neveřejné části budou kromě formulářů k dispozici články s aktuálně vypsanými dotacemi, které budou rovněž obsahovat odkaz na vyplnění formuláře žádosti o dotaci (modul elektronické formuláře), dále přílohy článku (provázání na sekci dokumenty) a k novým dotacím budou vznikat aktuality (modul aktuality). Vypsání nové dotace, její změna nebo upozornění na termín podání žádosti budou vázány na notifikace ePortálu. | ANO | Naplnění bude realizováno dodávkou modulu dotací na míru požadavkům Zadavatele a jeho integrace do CMS a okolí portálu |
Modul uživatelská statistika | - | - |
156
157
158
159
160
161
162
163
Uživatelská statistika bude k dispozici v neveřejné části ePortálu a backoffice části ePortálu. Statistika bude prezentovaná ve formě přehledného interaktivního dashboardu s odkazem na část ePortálu se zdrojovými daty statistiky, např. při kliknutí uživatele na statistiku podaných formulářů bude přesunut do sekce historie podání. Statistika uživatele by měla být zobrazena po přihlášení uživatele v rámci dashboardu úvodní strany neveřejného a backoffice prostředí. | ANO | Naplnění bude realizováno využitím standardních funkcionalit CMS s customizací v rámci uživatelské vrstvy |
Typickými statistikami pro uživatele neveřejné části mohou být – počet přihlášení do ePortálu, poslední přihlášení, počet podaných formulářů, počet realizovaných plateb, zaplaceno celkem a podobně. | ANO | Naplnění bude realizováno využitím standardních funkcionalit CMS s customizací v rámci uživatelské vrstvy |
Statistiky pro uživatele backoffice prostředí budou záviset na typu uživatele, resp. jeho roli. Statistiky budou řešeny v návaznosti na navrhované funkcionality v rámci implementační analýzy. | ANO | Naplnění bude realizováno využitím standardních funkcionalit CMS s customizací v rámci uživatelské vrstvy |
Statistiky bude možné konfigurovat šablonově administrátorem v backoffice části ePortálu. Šablony navrhne v rámci realizace Dodavatel, Zadavatel následně bude mít možnost vytvářet další uživatelské statistiky. U statistik bude možné určit výchozí statistiky, které se budou zobrazovat v návaznosti na typ uživatele a jeho prostředí. Správce bude mít možnost jednotlivá pole statistik přidat, odstranit, konfigurovat nebo skrýt. | ANO | Naplnění bude realizováno využitím standardních funkcionalit CMS s customizací v rámci uživatelské vrstvy |
Modul výstupy z datového skladu | - | - |
Modul by měl umožnit na základě známých údajů o uživateli v neveřejné části portálu dotazování datového skladu Zadavatele na disponibilní soubory, které se vážou k danému občanovi či firmě. Těmito soubory by měly být primárně uzavřené smlouvy Zadavatele s občanem/práívnickou osobou. | ANO | Naplnění bude realizováno dodávkou modulu na míru požadavkům Zadavatele a jeho integrace do CMS a okolí portálu (integrace) |
Výpis těchto souborů by následně měl být uživateli k dispozici a soubory by mělo být možné stáhnout, přičemž stažení dokumentu z datového skladu bude zajišťovat ePortál skrze integraci. | ANO | Naplnění bude realizováno dodávkou modulu na míru požadavkům Zadavatele a jeho integrace do CMS a okolí portálu (integrace) |
Pro uživatele backoffice části by měl modul umožnit fulltextové či atributové dotazování, na základě kterého by uživatel obdržel seznam výsledků – souborů v datovém skladu, které by odpovídali parametrům vyhledávání. Tyto soubory by následně měl uživatel možnost stáhnout obdobně jako uživatel neveřejné části smlouvu. | ANO | Naplnění bude realizováno dodávkou modulu na míru požadavkům Zadavatele a jeho integrace do CMS a okolí portálu (integrace) |
Modul výstupy z digitálního repozitáře | - | - |
Modul bude sloužit k přebírání výstupů z aplikace digitální repozitář, která je pořizována souběžně s projektem ePortálu. Digitální repozitář vede digitalizované informace o sbírkových předmětech ve formě metadat nebo jako související přílohy. Modul bude dostupný pouze v rámci backoffice části ePortálu. | ANO | Naplnění bude realizováno dodávkou modulu na míru požadavkům Zadavatele a jeho integrace do CMS a okolí portálu (integrace) |
Modul bude umožňovat dotazování se aplikace repozitář na datové objekty aplikace přes realizovanou integraci na digitální repozitář. Dotazování bude realizované jako fulltextové vyhledávání a dále jako parametrizované vyhledávání podle atributů. Atributy vyhledávání budou obsaženy ve formě tzv. šablon vyhledávání. Šablony vyhledávání budou selektovatelné uživatelem a dle vybrané šablony se uživateli zobrazí množina atributů, která je relevantní vůči typu datového objektu (např. stavební dokumentace, numismatika apod.). ePortál musí umožňovat tvorbu šablon a přidávání nových atributů vyhledávání do ePortálu administrátorem skrze administraci ePortálu. | ANO | Naplnění bude realizováno dodávkou modulu na míru požadavkům Zadavatele a jeho integrace do CMS a okolí portálu (integrace) |
166
167
168
169
170
171
172
Modul bude uzpůsoben pro dva typy uživatelů – expertní uživatele (badatele) a standardní uživatele. Expertní uživatel nebude mít nijak limitované vyhledávání, standardní uživatel může mít omezené možnosti, respektive vyhledávání bude v rámci UI uživatelsky uzpůsobeno s cílem jednoduchého vyhledávání. | ANO | Naplnění bude realizováno dodávkou modulu na míru požadavkům Zadavatele a jeho integrace do CMS a okolí portálu (integrace) |
Po potvrzení vyhledávání se ePortál skrze integraci dotáže aplikace digitální repozitář, která ePortálu vrátí seznam relevantních záznamů (datových objektů). Výsledky bude možné seřazovat na základě jejich atributů – ID, velikost, název, popis apod. U těchto objektů bude k dispozici tlačítko pro stažení datového objektu. | ANO | Naplnění bude realizováno dodávkou modulu na míru požadavkům Zadavatele a jeho integrace do CMS a okolí portálu (integrace) |
Expertní uživatel bude mít dvě možnosti stažení datového objektu, a to kompletní stažení objektu ve formě metadat dle OAIS a dále zjednodušené agregované stažení datového objektu. V obou případech po kliknutí na příslušné tlačítko dojde k zaslání informace digitálnímu repozitáři, který vrátí ePortálu příslušný soubor, jenž si následně uživatel stáhne. Standardní uživatel bude mít k dispozici pouze možnost stažení agregovaných dat o datovém objektu. | ANO | Naplnění bude realizováno dodávkou modulu na míru požadavkům Zadavatele a jeho integrace do CMS a okolí portálu (integrace) |
Modul dokumenty | - | - |
Modul umožní nahrávat dokumenty v rámci backoffice části a přístup k nim v rámci všech prostředí ePortálu. Přístup k dokumentům bude omezen na základě prostředí a uživatelských rolí. | ANO | Naplnění bude realizováno využitím standardních funkcionalit CMS s customizací v rámci uživatelské vrstvy |
Přes UI portálu bude možné vkládat libovolné soubory, primárně textové dokumenty ve formátech .pdf a .docx. K dokumentům bude možné vkládat metadata – název a popis dokumentu. Bude možné kromě omezení přístupu k dokumentu nastavit platnost dokumentu, tedy dobu, po kterou bude možné dokument stáhnout. | ANO | Naplnění bude realizováno využitím standardních funkcionalit CMS s customizací v rámci uživatelské vrstvy |
Uživatelé budou mít k dokumentům přístup v rámci přehledné sekce, kde bude možné dokumenty sdružovat podle různých kritérií – např. určení, typ dokumentu. Dokumenty bude možné seřazovat na základě jejich atributů – čas vložení, velikost, název apod. | ANO | Naplnění bude realizováno využitím standardních funkcionalit CMS s customizací v rámci uživatelské vrstvy |
Dokumenty vložené na ePortál přes modul dokumenty bude možné vkládat do aktualit a článků, případně je dále vkládat do struktury stránek ePortálu přes WYSIWYG editor. | ANO | Naplnění bude realizováno využitím standardních funkcionalit CMS s customizací v rámci uživatelské vrstvy |
Modul uživatelská administrace | - | - |
Modul umožní administraci nastavení samotnému uživateli dle dostupných oprávnění v rámci přiřazené role. Uživatelská administrace bude přístupná z menu. V rámci neveřejné části je předpoklad nastavení notifikačních kanálů a jejich výběr pro realizaci notifikace. Dále by měla administrace umožnit změny v disponibilních modulech, např. označení aktualit jako přečtených, skrytí atributů v uživatelské statistice a podobě. Celkový výčet nastavení bude navržen dodavatelem v rámci implementační analýzy na základě podoby cílové funkcionality a schválen Zadavatelem. | ANO | Naplnění bude realizováno využitím standardních funkcionalit CMS v oblasti rolí a oprávnění pro administrační část |
Modul administrace modularity | - | - |
Modul umožní přístup k nastavení konkrétního modulu, tj. obdobně jako v modulu administrace ePortálu, ale s omezením na dané moduly, ke kterým bude mít uživatel nastavenou roli. | ANO | Naplnění bude realizováno využitím standardních funkcionalit CMS v oblasti rolí a oprávnění pro administrační část s nutnou customizací v rámci aplikační i uživatelské vrstvy |
Modul administrace ePortálu | - | - |
175
176
177
178
Administrace ePortálu bude k dispozici v rámci backoffice části ePortálu a může se jednat o separátní prostředí nebo může být součástí backoffice, pouze s omezením na roli administrátora, vhodné řešení navrhne dodavatel v rámci implementační analýzy. | ANO | Naplnění bude realizováno využitím standardních funkcionalit CMS s případnými customizacemi, které vyplynou z detailní analýzy požadavků |
Administrace bude sloužit ke konfiguraci všech modulů na úrovni administrátora dle funkcionalit daného modulu. Kromě konfigurace modulů bude administrace sloužit k systémovému nastavení ePortálu. Minimálně musí řešit následující konfigurace: • Log management ePortálu a zasílání logu do centrálního log managementu – log management bude řešen v souladu s požadavky na výčet logů pro KIVS. • Zálohování ePortálu a statistiku záloh, vč možnosti automatického spuštění záloh s nastavitelnou frekvencí • Revize a nastavení uživatelských rolí – jednou s možností je, že role bude ePortál řešit přebíráním z identity management aplikace Zadavatele, případně řešení, kdy role budou nastaveny v rámci IDM, ale ePortál bude mít řešené prohlížení rolí v administraci s možností změn, které se propíšou do IDM v rámci integrace. V detailu bude oblast uživatelských rolí řešit implementační analýza. • Konfigurace a sledování integrací a notifikačních kanálů • Konfigurace DB – bude-li součástí navrhovaného řešení databáze, administracew ePortálu by měla umožnit přístup do DB pro nahlížení, případně doplňování databáze zásahem administrátora ePortálu. V detailu bude tuto možnost řešit implementační analýza. • Verzování CMS – administrátor bude mít dohled nad verzováním administrace ePortálu (CMS – content managment systém), součástí může být systém aktualizací modulů či samotné administrace, ale konkrétní pojetí bude popisovat implementační analýza na základě cílového řešení. | ANO | Naplnění bude realizováno využitím standardních funkcionalit CMS s případnými customizacemi, které vyplynou z detailní analýzy požadavků |
Integrační rozhraní | - | - |
ePortál bude obsahovat integrační rozhraní, které umožní oboustrannou komunikacemi s IS a aplikacemi Zadavatele či třetích stran. Integrační rozhraní bude navrženo jako bezpečné a šifrované, logované a konfigurované pro partnerský IS/aplikaci. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní součást navržené a realizované architektury portálu v rámci integrační vrstvy |
Integrační rozhraní bude navrženo tak, aby umožňovalo v budoucnu realizaci integrace na další IS/aplikace, než jsou definované v rámci tohoto dokumentu a umožní rovněž konfigurace integrací pro případ, ve kterém dojde ke změně na straně IS/aplikace druhé strany. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní součást navržené a realizované architektury portálu v rámci integrační vrstvy |
Zadavatel zajistí Dodavateli dostupné API systému a aplikací, na které bude realizována integrace ePortálu a dále zajistí součinnost dodavatele aplikace/IS druhé strany v podobě konzultací realizace integrace mezi ePortálem a integračním rozhraním druhé strany. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní součást navržené a realizované architektury portálu v rámci integrační vrstvy |
V rámci nasazení ePortálu Dodavatelem budou realizované následující integrace: | ||
Integrace NIA – bude realizovaná integrace na Národní bod pro identifikaci a autorizaci. Tato integrace bude sloužit k přihlášení občanů, případně zástupců právnických osob či zástupců obcí do ePortálu. | ANO | Naplnění proběhne dle definovaných požadavků jako součást navržené a realizované architektury portálu v rámci integrační vrstvy |
Integrace ISDS – bude realizovaná integrace na datové schránky, konkrétně bude umožněno důvěryhodné přihlašování s využitím ID datové schránky. Integrace bude sloužit k přihlášení občanů vlastnící datovou schránku, zástupců právnických osob či zástupců obcí do ePortálu. | ANO | Naplnění proběhne dle definovaných požadavků jako součást navržené a realizované architektury portálu v rámci integrační vrstvy |
Integrace platební brány – v rámci ePortálu bude realizovaná integrace na platební bránu, přes kterou budou moci uživatelé neveřejné části portálu realizovat platby Zadavateli nebo příspěvkovým organizacím Zadavatele. ePortál bude podporovat minimálně platební brány Comgate, Gopay, PayU s možností změny platební brány v rámci realizace projektu nebo rozvoje v rámci servisních prací na ePortálu. | ANO | Naplnění proběhne dle definovaných požadavků jako součást navržené a realizované architektury portálu v rámci integrační vrstvy |
Integrace aplikace Chatbot – ePortál bude mít realizovanou integraci na aplikaci Chatbot, která je součástí Díla. Chatbot bude mít integrovanou klientskou aplikaci do UI ePortálu s instancí znalostní databáze v závislosti na části ePortálu (veřejná/neveřejná/backoffice). Prostřednictvím klientské aplikace bude chatbot přijímat zprávy od uživatele a odesílat mu odpovědi. | ANO | Naplnění proběhne dle definovaných požadavků jako součást navržené a realizované architektury portálu v rámci integrační vrstvy |
Integrace na datový sklad Zadavatele – ePortál bude mít realizovanou integraci na datový sklad Zadavatele, ze kterého bude na základě uživatelského dotazování vracet seznam dostupných souborů a bude zprostředkovávat jejich stažení. | ANO | Naplnění proběhne dle definovaných požadavků jako součást navržené a realizované architektury portálu v rámci integrační vrstvy |
Integrace na digitální repozitář Zadavatele – ePortál bude mít realizovanou integraci na vznikající digitální repozitář Zadavatele, ze kterého bude na základě uživatelského dotazování vracet seznam dostupných souborů (resp. datových objektů) a bude zprostředkovávat jejich stažení. | ANO | Naplnění proběhne dle definovaných požadavků jako součást navržené a realizované architektury portálu v rámci integrační vrstvy |
Integrace na IS Ginis – bude realizovaná integrace na IS Ginis Zadavatele za účelem napojení na spisovou službu Ginis pro předání podání a získávání informace o stavu řešení podání (spisu). Zvažované je rovněž přebírání stavu platby (zaúčtováno) do historie plateb. Zadavatel má k dispozici integrační platformu Ginis XRG, která bude pro integraci využita. | ANO | Naplnění proběhne dle definovaných požadavků jako součást navržené a realizované architektury portálu v rámci integrační vrstvy |
Integrace na spisovou službu Geovap – bude realizovaná integrace ePortálu na spisovou službu Geovap (která je využívaná příspěvkovými organizacemi) pro předání podání ePortálem a získávání informace o stavu řešení podání (spisu). | ANO | Naplnění proběhne dle definovaných požadavků jako součást navržené a realizované architektury portálu v rámci integrační vrstvy |
Integrace na IDM/AD – bude realizovaná integrace na identity management aplikaci Zadavatele (produkt EOS firmy MARBES CONSULTING s.r.o.) pro SSO autentizaci do ePortálu, přebírání rolí z IDM a pro potřebu hierarchičnosti rolí a přístupů i organizační strukturu. Rovněž může Zadavatel vyžadovat integraci na Active directory (AD) v případě, že nebude možné plnohodnotně integrovat IDM. V takovém případě jsou k dispozici dvě AD – Zadavatele a příspěvkových organizací, typově dva různé produkty. | ANO | Naplnění proběhne dle definovaných požadavků jako součást navržené a realizované architektury portálu v rámci integrační vrstvy |
Integrace na mail server a SNS bránu – bude realizovaná integrace na SMTP server a SMS Bránu Zadavatele, skrze které bude ePortál realizovat notifikace | ANO | Naplnění proběhne dle definovaných požadavků jako součást navržené a realizované architektury portálu v rámci integrační vrstvy |
Nasazení | - | - |
ePortál bude nasazen on-premise v prostředí Zadavatele na infrastruktuře Zadavatele. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektová aktivita |
Dodavatel nasadí ePortál ve třech prostředích: | ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektová aktivita |
181
182
183
184
185
186
187
188
189
190
192
193
194
195
196
197
198
199
200
Vývojové prostředí – vývojové prostředí realizuje Dodavatel svými prostředky. V rámci prostředí garantuje bezpečnost SW a dat, pokud byla některá Zadavatelem již předána. Dále Dodavatel zajistí přístup Zadavatele do vývojového prostředí skrze zabezpečený přístup VPN pro možné ověřování funkcionalit vznikajícího ePortálu. Přístup Xxxxxxxxxx bude realizován po dohodě s Dodavatelem. Vývojové prostředí Dodavatele nebude dostupné ze sítě internet. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektová aktivita |
Testovací prostředí – testovací prostředí bude realizováno Dodavatelem za součinnosti Zadavatele na infrastruktuře Zadavatele s využitím technologického SW Zadavatele a Dodavatele. Prostředí bude sloužit k otestování ePortálu a jeho částí. Po nasazení ePortálu do produkčního prostředí zůstane testovací prostředí zachováno a bude se využívat pro srovnávání s produkčním prostředím, pro nasazování aktualizací a nových funkcionalit, řešených v rámci rozvoje ePortálu. Přístupy k částem ePortálu budou vázány na autentizaci a nebudou volně přístupné. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektová aktivita |
Produkční prostředí – produkční prostředí bude realizováno Dodavatelem za součinnosti Zadavatele na infrastruktuře Zadavatele s využitím technologického SW Zadavatele a Dodavatele. Prostředí bude sloužit pro cílový provoz ePortálu pro všechny koncové uživatele, jak na straně Zadavatele a jeho příspěvkových organizací, tak veřejnosti nebo autentizovaných z řad veřejnosti. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektová aktivita |
Veřejná, neveřejná a backoffice části budou součástí každého z uvedených prostředí výše. Část backoffice bude oddělena na aplikační i síťové úrovni a bude se nacházet v jiných síťových perimetrech. Mezi částmi bude realizovaná zabezpečená integrace. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní součást navržené a realizované architektury portálu. |
ePortál umožní nasazení na infrastruktuře v režimu vysoké dostupnosti, s detailem bude seznámen Dodavatel v rámci implementační analýzy. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní součást navržené a realizované architektury portálu. |
Bezpečnost | - | - |
ePortál bude nasazen v režimu zabezpečení na vysokou bezpečnostní úroveň dle vyhlášky č. 315/2021 Sb. Nastavení a garance bezpečnosti ePortálu bude popsána Dodavatelem v rámci implementační analýzy. Zabezpečení musí reflektovat princip security-by-design, který bude aplikován již při vývoji ePortálu, dále budou provedeny nezávislé bezpečnostní testy. Pro šifrování, které bude aplikované pro všechny části ePortálu bude platit, že budou využity pouze aktuální kryptografické prostředky, vykazující nízkou zranitelnost. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní součást navržené a realizované architektury portálu. |
Bezpečnost bude i po nasazení pravidelně vyhodnocována v rámci servisní podpory, řešení bude aktualizováno pro zachování bezpečnosti ePortálu, jeho provozu a dat. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní servisní aktivita |
Školení | - | - |
K ePortálu budou realizovaná školení Dodavatele, a to dvě školení – uživatelské a administrátorské. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektová aktivita |
Administrátorské školení bude realizované jak pro administrátory celého ePortálu, tak pro administrátory jednotlivých modulů. Školení budou korespondovat s uživatelskou a administrátorskou dokumentací (uživatelská a systémová příručka). Součástí školení bude vytváření formulářů. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektová aktivita |
Uživatelské školení bude zaměřeno na ovládání backoffice části, ale rovněž bude realizované školení na neveřejnou část, aby byl Zadavatel schopen přenést znalost ovládání části dále k externím uživatelům. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektová aktivita |
Školení budou realizovaná lektorem Dodavatele v prostorách Zadavatele. Školení se kromě zaměstnanců Zadavatele budou moci účastnit zástupci příspěvkových organizací Zadavatele, účast nebude Dodavatelem limitovaná. Předpokládaný rozsah školení je 24 hodin pro administrátorské školení a 8 hodin pro uživatelské školení. Školení bude možné rozdělit do více navazujících školení a cílová délka školen se bude odvíjet od cílové komplexnosti ePortálu, cílem je srozumitelné a kompletní seznámení uživatelů a administrátorů s ePortálem. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektová aktivita |
Licence | - | - |
K ePortálu bude předaná nevýhradní licence, početně a místně neomezená. Licence bude udělena Zadavateli a pro příspěvkové organizace Zadavatele. Současně předá Dodavatel licence k SW třetích stran, budou-li využity v rámci díla a rovněž předá licence k technologickému SW, které dílo bude využívat, tyto licence třetích stran budou Dodavatelem zajištěny minimálně na dobu 72 měsíců od akceptace díla. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup |
201
202
Pořadové číslo
203
204
205
206
207
208
209
210
211
Požadovaná vlastnost (požadavky) | Splňuje uchazeč požadavky (Ano/Ne) | Popis naplnění požadavků dodavatelem |
Chatbot | - | - |
V rámci ePortálu bude nasazen další výstup díla, SW řešení pro automatizovanou komunikaci s uživatelem – chatbot, který bude k dispozici pro všechny uživatele portálu a bude jim poskytovat odpovědi na časté dotazy, případně jim pomůže s navigaci v rámci portálu a využíváním funkcí portálu. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup |
Chatbot bude navržen jako aplikace umožňující přirozenou komunikaci s respondentem za využití NLP (Natural language processing).Chatbot bude schopen rozpoznávat větu, její kontext a dle toho reagovat s příslušnou odpovědí, případně se dotázat na upřesnění dotazu. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní součást navržené a realizované architektury chatbota. |
Chatbota bude možné implementovat do libovolného webového prostředí využívajícího standard HTML5. V rámci dodání bude nasazen v portálovém řešení ePortál Zlínského kraje. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní součást navržené a realizované architektury chatbota. |
Chatbot bude nasazen on-premise na infrastruktuře Zadavatele | ANO | Naplnění proběhne dle definovaných požadavků jako standardní součást navržené a realizované architektury chatbota. |
Chatbot se z jednotlivých konverzací bude učit s využitím prvků umělé inteligence (AI) a bude kontinuálně zvyšovat úspěšnost odpovědí. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní součást navržené a realizované architektury chatbota. |
Služby | - | - |
Služba informační asistence – chatbot bude poskytovat uživatelům informační asistence vč. řešení častých dotazů a navigace v ePortálu. Chatbot bude obsahovat znalostní okruhy dle typu prostředí, tedy u veřejné části bude schopen zodpovědět časté dotazy a poradit s autentizací, v neveřejné části bude navíc uživateli asistovat při podání formuláře nebo platbě, v backoffice části bude uživateli asistovat při práci v jednotlivých modulech. | ANO | Naplnění proběhne na základě standardních funkcionalit chatbota a následné konfigurace a customizace na míru obsahovým, informačním a funkčním požadavkám zadavatele. |
Služba neustálé dostupnosti – chatbot bude dostupný 24/7 a bude nasazený na ICT prostředcích Zlínského kraje. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní součást navržené a realizované architektury chatbota. |
Služba rozpoznání kontextu informace a přirozenou komunikaci s uživatelem – chatbot bude využívat NLP (natural language processing, tedy bude komunikovat s uživatelem v textové podobě přirozeným jazykem. Bude schopen rozpoznat kontext komunikace s uživatelem a jeho dotaz a bude se na základě komunikace s uživateli učit pro zvyšování úspěšnosti zodpovězení dotazu skrze prvky umělé inteligence (AI). | ANO | Naplnění proběhne na základě standardních funkcionalit chatbota a následné konfigurace a customizace na míru obsahovým, informačním a funkčním požadavkám zadavatele. |
Indexování webů – chatbot bude indexovat vybrané weby na základě pravidelného intervalu nebo uživatelským spuštěním a bude z těchto webů přebírat obsah a obohacovat svou znalostní DB, čímž umožní reagovat na dotazy informacemi z indexovaných webů a odkazovat na ně. | ANO | Naplnění proběhne pomocí customizovaných rozšíření, které se integrují na znalostní bázi chatbota. |
Výstupy | - | - |
Implementační analýza – Dodavatel realizuje implementační analýzu, v rámci které ve spolupráci se Zadavatelem upřesní požadavky na cílový SW chatbot a způsob realizace. Součástí bude popis cílového sw pro jeho realizaci a nasazení. Analýzu akceptuje Zadavatel po vypořádání připomínek. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup |
213
214
215
216
217
218
219
220
221
222
Vytvoření znalostní DB – Součástí implementační analýzy je analýza znalostních okruhů, se kterou bude chatbot operovat. V rámci té Xxxxxxxxx realizuje rozhovory s gesčními organizačními útvary Zadavatele a vytvoří cílovou podobu znalostní databáze pro často kladené dotazy. Po vytvoření ePortálu do DB zavede rovněž znalostní databáze asistence v jednotlivých prostředích – neveřejného a backoffice. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup |
Vytvoření grafického návrhu – V rámci vstupní analýzy vznikne vizuální návrh klientské aplikace chatbota a UI návrh administrace chatbota. Grafický návrh bude ve 3 variantách představen Zadavateli, ten následně předá Dodavateli pokyny k dalším úpravám vizuálního návrhu a akceptuje vítěznou variantu po zakomponování požadavků Zadavatele. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup |
Vytvoření chatbota – Dodavatele vytvoří cílovou aplikaci chatbot ve třech instancích – pro veřejnou, neveřejnou a backoffice část ePortálu. Chatbot bude obsahovat uživatelskou aplikaci – klienta a aplikaci pro správu chatbota. Zakomponuje do instancí chatbota znalostní databázi často kladených dotazů ze vstupní analýzy a dále dle instance znalostní databázi asistence v jednotlivých prostředích – neveřejného a backoffice. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup |
Kontrolní analýza – Dodavatel naváže na implementační analýzu, ověří stav SW po jeho vytvoření a aktualizuje případné požadavky na implementaci. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup |
Implementace do testovacího prostředí – Dodavatel za spolupráce Xxxxxxxxxx realizuje implementaci chatbota do ePortálu v testovacím prostředí Zadavatele. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup |
Realizace integrací – Dodavatel zajistí integraci chatbota do ePortálu dle předimplementační analýzy a případné integrace na jiné IS. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup |
Realizace testů – Dodavatel zajistí sadu testů, kterými ověří parametry chatbota. Dodavatel otestuje chatbota již v rámci svého vývojového prostředí, následně budou testy realizované na testovacím prostředí Zadavatele a pro ověření následně na produkčním. Dodavatel realizuje minimálně následující testy: | ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup |
Performance testy – pro vývojové prostředí Dodavatele a testovací prostředí Zadavatele, v rámci testu bude ověřena odezva chatbota při různém vytížení respondenty. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup |
Funkční testy – pro tyto testy vytvoří Dodavatel testovací scénáře a bude je realizovat společně se Zadavatelem. Z funkčních testů vznikne seznam případných zjištění – vad, které Dodavatel odstraní a následně se provede další iterace funkčních testů. Testy budou realizované pro všechna prostředí a scénáře budou reflektovat funkcionality daného prostředí. V rámci funkčních testů proběhnou testy znalostní DB a chování chatbota. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup |
Testy znalostní DB a chování chatbota – bude otestována úspěšnost zodpovězených dotazů při různém způsobu dotazování a bude rovněž otestována kompletnost znalostních okruhů chatbota. Testy bude realizovat testovací skupina složená ze zástupců budoucích uživatelů pro jednotlivá prostředí a při testech bude asistovat zástupce Dodavatele. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup |
Bezpečnostní testy – Dodavatel zajistí nezávislé bezpečnostní otestování chatbota vč. všech jeho instancí třetí stranou včetně penetračních testů. Testy budou realizovány dle metodiky OWASP TOP10. Případné zjištěné chyby Dodavatel odstraní. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup |
UX/UI testy – Dodavatel ve spolupráci se Zadavatelem zajistí UX/UI testy chatbota úpravy podle zjištěných neoptimalit UX/UI portálu. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup |
Akceptační testy – realizuje Zadavatel, Xxxxxxxxx je povinen odstranit nedostatky, nalezené testy. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup |
Implementace do produkčního prostředí – Dodavatel zajistí migraci chatbota do ePortálu v produkčním prostředí Zadavatele po odstranění případných vad z testování, doplnění znalostní DB na základě testování a akceptaci Zadavatele. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup |
Vytvoření systémové dokumentace – Dodavatel vytvoří pro chatbota systémovou dokumentaci popisující technický stav chatbota a dále vytvoří dokumentaci pro administrátory, která bude popisovat správu chatbota a jeho znalostní DB, vč. jejího doplňování. Současně vytvoří Dodavatel uživatelskou dokumentaci pro práci s chatbotem. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup |
Školení – Dodavatel zrealizuje školení v prostorách Zadavatele, přičemž bude realizovat oddělené školení pro administrátory a pro uživatele | ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup |
Předání zdrojových kódů – Dodavatel předá pro vyvíjené části aplikace zdrojové kódy Zadavateli jako strojově čitelná data vč. manuálu popisujícího strukturu zdrojových kódů a jejich kompilaci/spuštění a to dle podmínek uvedených v čl. IV. Smlouvy | ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup |
Předání licencí – Dodavatel k dílu předá nevýhradní časově, početně a místně neomezenou licenci. Licence umožní nasazení díla v rámci dalších prostředí Zadavatele a jeho příspěvkových organizací a umožní modifikaci díla. Současně předá licence k SW třetích stran, budou-li využity v rámci díla a rovněž předá licence k technologickému SW, které dílo bude využívat. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup |
Asistence při pilotním provozu – Dodavatel poskytne Zadavateli podporu při pilotním provozu díla, která se bude spočívat v součinnosti při vyhodnocování parametrů provozu a dále zajistí odstranění případných vad a neoptimalit, které se mohou při pilotním provozu projevit a nasadí jejich opravu nejprve do testovacího prostředí a po schválení Zadavatelem do produkce. Xxxx rovněž asistovat při případném doplňování znalostní DB pro zajištění její integrity a bezchybnosti. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní projektový výstup |
Instance | - | - |
Aplikace chatbot bude řešena formou samostatných instancí, přičemž každá instance bude mít svoji separátní znalostní databázi z důvodu bezpečnosti. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní součást navržené a realizované architektury chatbota. |
224
225
226
227
228
229
230
231
232
V rámci dodání díla budou vytvořeny 3 instance: Instance veřejná část – instance bude obsahovat odpovědi na často kladené dotazy, bude schopna obecně a taxativně popsat jaké funkce umožňuje neveřejná část ePortálu a pomůže respondentovi s postupem autentizace do neveřejné části portálu. Instance neveřejná část – instance bude obsahovat informace veřejné části portálu a navíc bude disponovat znalostními okruhy dle funkcí neveřejné části portálu, díky kterým bude asistovat uživateli při využívání funkcí ePortálu. Bude asistovat při vyplnění formuláře vysvětlením typů atributů (uživatelské/předvyplněné, povinné/nepovinné), při jeho odeslání, pomůže uživateli s realizací platby přes platební bránu a pomůže uživateli s navigací v neveřejné části portálu, vč. asistence při uživatelské administraci – nastavení notifikačního kanálu a dalšího. Instance backoffice část – tato instance bude realizovaná pro interní část ePortálu, která bude oddělena na technologické úrovni od předchozích částí ePortálu a bude sloužit primárně pro navigaci uživatele. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní součást navržené a realizované architektury chatbota. |
Moduly | - | - |
Chatbot bude postavěn jako modulární aplikace skládající se z několika modulů. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní součást navržené a realizované architektury chatbota. |
Požadované jsou následující moduly: Modul klient – klientská aplikace pro komunikaci s respondentem. Bude realizovaná pomocí pop-up ikony, přičemž po kliknutí na ikonu se otevře okno s úvodní zprávou chatbota a konzolí pro vkládání textu. Po vkládání textu bude informace vyhodnocena chatbotem a dle shody klient vrátí respondentovi relevantní odpověď. V případě nerozpoznání dotazu požádá o upřesnění dotazu. Modul administrace – aplikace správce, v rámci které by měla být k dispozici možnost konfigurace chatbota, jeho úvodní věty, správa znalostní databáze a doplnění o nové znalostní okruhy a odpovědi. Administrace by měla rovněž obsahovat informace z monitoringu chatbota. Měla by správci zobrazit statistiky – počty konverzací, počty dotazů, nejčastěji kladené dotazy a statistika by měla rovněž zobrazit nezodpovězené dotazy nebo dotazy s malou mírou shody, na které následně bude možné reagovat doplněním znalostního okruhu do DB. Administrace bude rovněž umožňovat konfiguraci a administraci indexace webů. | ANO | Naplnění proběhne dle definovaných požadavků jako standardní součást navržené a realizované architektury chatbota. |
Další funkce | - | - |
Chatbot by měl umožnit notifikaci prostřednictvím SMS nebo e-mailem. Měl by poskytovat pravidelný denní report chatbota s výčtem denní statistiky, dále by notifikace sloužila k nahlášení nestandardních informací správci – nedostupnost chatbota, nepřiměřeně velké množství konverzací a související navýšení provozního výkonu, klíčová slova, která jsou v administraci vyznačená jako riziková apod. | ANO | Naplnění proběhne na základě standardních funkcionalit chatbota a následné customizace na míru integračním požadavků |
233
234
235
236