ZADÁVACÍ DOKUMENTACE
K č. j. ČÚZK-10685/2020
ZADÁVACÍ DOKUMENTACE
Česká republika - Český úřad zeměměřický a katastrální Pod sídlištěm 1800/9, Kobylisy, 18211 Praha 8
IČO: 00025712
zadává nadlimitní veřejnou zakázku na služby v otevřeném řízení
ve smyslu zákona č. 134/2016 Sb., o zadávání veřejných zakázek, ve znění pozdějších předpisů,
s názvem
„Vybudování informačního systému Digitální mapy veřejné správy“
Evidenční číslo veřejné zakázky ve Věstníku veřejných zakázek: Z2020-029319
Obsah
Předmět plnění veřejné zakázky 8
Součinnost s třetími stranami v oblasti HW a SW 19
Technologická infrastruktura Dodavatele 24
Vývojové/testovací prostředí pro vývoj IS napojených na IS DMVS 26
Chybovost IS DMVS, cena plnění pro účely uplatnění slevy z plnění 26
Vedení dokumentace – projektová kancelář 28
Obstarání TI (HW), SW nebo služeb 33
Zajištění jakosti a kvality 36
Doba a místo plnění veřejné zakázky 38
Doba plnění veřejné zakázky 38
Místo plnění veřejné zakázky 38
Doklady o kvalifikaci, změna kvalifikace 44
Prokazování splnění kvalifikace při společném podání nabídky 44
Prokázání kvalifikace prostřednictvím poddodavatele 44
Prokázání kvalifikace získané v zahraničí 45
Cena, požadavky na způsob zpracování nabídkové ceny 47
Nabídková cena za plnění dle VZ 47
Požadavky na zpracování nabídky 48
Formální požadavky Zadavatele na zpracování nabídky 48
Otevírání obálek s nabídkami 49
Doporučená osnova pro zpracování nabídky 49
Popis způsobu hodnocení dle dílčích hodnotících kritérií 52
Vysvětlení zadávací dokumentace 56
Seznam tabulek
Tabulka 1 - předpokládaný věcný a časový průběh plnění 10
Tabulka 2 - základní způsobilost 39
Tabulka 4 - kritéria hodnocení 52
Tabulka 5 - pracovníci (rozšířená certifikace) 53
Tato zadávací dokumentace je zpracována dle ustanovení § 36 zákona č. 134/2016 Sb., o zadávání veřejných zakázek, ve znění pozdějších předpisů (dále jen „ZZVZ“).
Tato veřejná zakázka je zadávána v otevřeném řízení dle ustanovení § 56 ZZVZ.
Zadavatelem veřejné zakázky je Česká republika – Český úřad zeměměřický a katastrální
sídlo: | Xxx xxxxxxxxx 0000/0, Xxxxxxxx, 00000 Xxxxx 0 |
IČO: | 00000000 |
tel.: | x000 000 000 000 |
fax: | x000 000 000 000 |
e-mail: xxxx@xxxx.xx ID DS: uuaaatg
(dále jen „Zadavatel“)
Osoba oprávněná jednat jménem zadavatele: Xxx. Xxxxx Xxxxxxx, místopředseda Kontaktní osoba: Xxx. Xxxxxx Xxxxxx, e-mail: xxxxxx.xxxxxx@xxxx.xx
Seznam použitých zkratek je uveden v Příloze ZD01.
Tato ZD se poskytuje pouze za účelem zpracování nabídky pro zadání VZ, Účastník ZŘ není oprávněn ji použít k jiným účelům.
Požadavky, vymezené zadávacími podmínkami, je Účastník ZŘ povinen plně a bezvýhradně respektovat při zpracování své nabídky. Neakceptování požadavků Zadavatele, uvedených v této ZD, bude považováno za nesplnění zadávacích podmínek s následkem vyloučení Účastníka ZŘ z účasti na ZŘ.
V případě, že zadávací podmínky VZ obsahují přímé nebo nepřímé požadavky nebo odkazy na určité dodavatele nebo výrobky, patenty na vynálezy, užitné vzory, průmyslové vzory, ochranné známky nebo označení původu, umožňuje Zadavatel pro plnění VZ použití i jiných, kvalitativně a technicky rovnocenných řešení, které naplní Zadavatelem požadovanou funkcionalitu (byť jiným způsobem). Případné další náklady Xxxxxxxxxx související s takovým rovnocenným řešením (např. na pořízení nezbytných licencí, jejich podporu po dobu plnění veřejné zakázky) musí být v takovém případě součástí nabídkové ceny Účastníka ZŘ.
V současné době neexistuje informační systém digitální mapy veřejné správy. Několik krajů, většina měst i některé menší obce (obvykle pouze v intravilánu města či obce) si vedou digitální technické mapy. Tyto nezávisle vedené DTM nejsou standardizované, vzájemně propojené a mají různá rozhraní. Plošný, celorepublikový systém, neexistuje.
Zákonem č. 47/2020 Sb., kterým byl novelizován zákon č. 200/1994 Sb. o zeměměřictví, ve znění pozdějších předpisů (ZemZ), je zakotvena povinnost vést digitální technickou mapu kraje, kdy správcem digitální technické mapy kraje je stanoven krajský úřad, a to v přenesené působnosti. Vlastní obsah DTM krajů je věcně členěn na vlastní údaje o dopravní a technické infrastruktuře a na údaje o základní povrchové situaci. Podrobné vymezení toho, jaké druhy zařízení, jaké konkrétní objekty a jaké údaje týkající se těchto objektů a zařízení budou v krajských DTM vedeny, bude stanovovat prováděcí právní předpis – vyhláška o digitální technické mapě.
Pro ČÚZK nově vyplývá z novely povinnost vybudovat a spravovat IS DMVS, který bude centrálním systémem zastřešujícím krajské IS DTM a zároveň bude IS DMVS zajišťovat funkce, které je nutné řešit na centrální úrovni, tj.
- vytvoření jednotného rozhraní pro zobrazení katastrální mapy, ortofoto mapy a digitálních technických map krajů,
- vytvoření jednotného rozhraní pro předávání údajů k aktualizaci digitálních technických map krajů a pro zápis do digitálních technických map krajů,
- vedení seznamu vlastníků, provozovatelů a správců technické infrastruktury, včetně údajů o tom, v jakém území plní povinnost podle § 161 odst. 1 věty druhé stavebního zákona (zákon č. 183/2006 Sb., StavZ), a vlastníků, provozovatelů a správců dopravní infrastruktury včetně údajů o tom, v jakém území působí,
- vedení seznamu editorů digitálních technických map krajů a osob, které za editora plní jeho editační povinnost, včetně rozsahu jejich oprávnění k editaci.
IS DMVS bude garantovaným zdrojem dat, který umožní vést data vlastníků, správců a provozovatelů dopravní a technické infrastruktury v jednotné datové struktuře a v aktuální podobě.
Předmět plnění veřejné zakázky
Popis kódu CPV | CPV |
Vývoj programového vybavení | 72262000-9 |
Podpora programového vybavení | 72261000-2 |
Implementace programového vybavení | 72263000-6 |
Údržba a opravy programového vybavení | 72267000-4 |
Poradenství v oblasti programového vybavení | 72266000-7 |
Obecné informace
Zadavatel hodlá uzavřít s jedním vybraným Účastníkem ZŘ smlouvu na vybudování informačního systému Digitální mapy veřejné správy (dále jen „IS DMVS“) a jeho následnou údržbu. Podrobněji je předmět veřejné zakázky vymezen v dalším textu a v přílohách této ZD.
Zadavatel předpokládá, že vybudování IS DMVS bude spolufinancováno z Integrovaného regionálního operačního programu Výzva č. 94. S ohledem na tuto skutečnost bude smlouva s vítězným Účastníkem ZŘ uzavřena teprve v okamžiku, kdy Zadavatel obdrží od poskytovatele dotace rozhodnutí o poskytnutí dotace. Zadavatel předpokládá, že k rozhodnutí o poskytnutí/neposkytnutí dotace dojde ve IV. čtvrtletí roku 2020.
V této souvislosti si Zadavatel vyhrazuje právo neuzavřít smlouvu s vítězným Účastníkem ZŘ a zrušit VZ dle § 127 odst. 2 písm. e) ZZVZ pro případ, že předmětnou dotaci neobdrží.
Předpokládaný věcný a časový průběh plnění VZ:
Řádek | aktivita/část plnění | odkaz na ZD | Termín předání plnění | Termín (nejzazší) ukončení akceptačního řízení |
1 | Podpis smlouvy a zveřejnění v registru smluv | x | x | |
2 | Zprovoznění projektové kanceláře | do 2 měsíců od začátku účinnosti smlouvy | x | |
3 | Zprovoznění on-line dostupného úložiště | do 2 měsíců od začátku účinnosti smlouvy | x | |
4 | Zprovoznění automatického propojení SDM Zadavatele a HD Dodavatele pro účely hlášení a reportování chyb z testování předávaného plnění | do 3 měsíců od začátku účinnosti smlouvy | x | |
5 | Zprovoznění TI Dodavatele | do 3 měsíců od začátku účinnosti smlouvy | x | |
6 | Detailní analýza a návrh řešení – požadavky pro implementační dodávku DMVS I. | Příloha ZD05 | 17. 3. 2021 | 31. 3. 2021 |
7 | Detailní analýza a návrh řešení – požadavky pro implementační dodávky DMVS II., III., IV. | Příloha ZD05 | 16. 7. 2021 | 30. 7. 2021 |
8 | Implementační dodávka DMVS I. | Příloha ZD05 | 12. 8. 2021 | 30. 9. 2021 |
9 | Implementační dodávka DMVS II. | Příloha ZD05 | 10. 3. 2022 | 29. 4. 2022 |
10 | Implementační dodávka DMVS III. | Příloha ZD05 | 11. 11. 2022 | 30. 12. 2022 |
11 | Implementační dodávka DMVS IV. | Příloha ZD05 | 9. 3. 2023 | 28. 4. 2023 |
12 | Finální akceptace a předání IS DMVS do rutinního provozu | Příloha ZD05 | 29. 4. 2023 | 30. 6. 2023 |
Tabulka 1 - předpokládaný věcný a časový průběh plnění
Po finální akceptaci a předání IS DMVS do rutinního provozu Zadavatel předpokládá v průběhu kalendářního roku zpravidla dvě standardní dodávky IS DMVS. Za standardní dodávku se přitom považuje taková dodávka, jejíž celková pracnost se pohybuje v rozmezí 500 – 600 ČLD.
V případě, že by k podpisu smlouvy mělo dojít po 31. 1. 2021, dojde ještě před podpisem smlouvy ke zkrácení harmonogramu plnění tak, aby byly zachovány poměrově délky jednotlivých výše uvedených aktivit a zároveň došlo k ukončení akceptačního řízení aktivity „Finální akceptace a předání IS DMVS do rutinního provozu“ nejpozději k 30. 6. 2023 (termín vyplývající ze spolufinancování projektu z fondů EU).
Vybudování IS DMVS zahrnuje všechny časové a věcné etapy tvorby IS, zejména analýzu, návrh, vývoj, prototypování, testování, implementaci, pilotní provoz a instalaci veškerého aplikačního programového vybavení, integraci jednotlivých komponent (včetně TI) do komplexního funkčního řešení, tvorbu dokumentace, školení v potřebném rozsahu, poskytnutí záruky a koordinaci výše uvedených činností.
Definice
4.1.3.1 Záruční vada
Nesprávná funkčnost IS DMVS splňující záruční podmínky dle bodu 4.17; oprava je provedena bezplatně v rámci záruky.
4.1.3.2 Drobná úprava
Modifikace systému nepřesahující pracnost 5 ČLD.
4.1.3.3 Činnost na objednávku
Činnosti na objednávku zahrnují zejména:
- úpravy IS DMVS, které překračují rozsah drobné úpravy (4.1.3.2) nebo vyžadují zpracování podrobné analýzy, designu, prototypování, testování a implementaci.
- podporu při řešení havárií a problémů IS DMVS, např. havárie na infrastruktuře nebo závada ostatních komponent IS DMVS,
- podporu provozu IS DMVS, např. monitorování provozu nad rámec řešený v rámci PÚ,
- součinnost při řízení životního cyklu SW,
- vypracování závazných technických podmínek pro obstarání TI,
- vypracování analýzy úprav IS DMVS zadaných Zadavatelem,
- činnosti v oblasti bezpečnosti nad rámec řešený v rámci PÚ.
Fakturace probíhá na základě výsledků akceptačního řízení případně na základě výkazů práce nebo pracností, které musí Zadavatel odsouhlasit.
Zadavatel vychází z předpokladu, že celková pracnost všech činností na objednávku může pro plnění v rámci této VZ činit 3 000 ČLD.
Údržba IS DMVS
4.1.4.1 Provozní údržba (PÚ)
PÚ znamená zejména řešení a odstraňování provozních problémů a havárií tak, aby nebyl v žádném okamžiku ohrožen výkon činností IS DMVS.
Zadavatel po Dodavateli požaduje:
- zajištění PÚ v rozsahu 55 ČLD za 1 kalendářní měsíc, přičemž z toho řešení drobných úprav IS DMVS a mimozáručních vad musí činit 10 ČLD s možností převodu v rámci čtvrtletí poskytování služeb
- aby v nabídkové ceně uvedl výši měsíčního paušálního poplatku (v Kč bez DPH) za PÚ, a to za 30 měsíců,
- implementaci výsledků PÚ do produkčního prostředí, a to v případě:
o oprav/úprav IS DMVS v pravidelných intervalech, a to buď ve formě samostatných dodávek nebo přidruženě s plněním dle objednávek;
o opravných skriptů či oprav kritických, závažných nebo bezpečnostních chyb urychleně bez vazby na dodávku IS DMVS.
PÚ je hrazena měsíčním paušálním poplatkem a zahrnuje:
4.1.4.1.1 Identifikaci požadavku
Identifikací požadavku se rozumí analýza příčin problému nahlášeného Zadavatelem.
4.1.4.1.2 Kategorizaci požadavku
Kategorizací požadavku, v návaznosti na identifikaci, se rozumí stanovení, zda jde o:
- záruční vadu,
- mimozáruční vadu,
- chybu z testování,
- činnost na objednávku dle 4.1.3.3, (rozsahem přesahuje drobnou úpravu a nebude tedy řešena v rámci PÚ).
Výsledná kategorizace podléhá schválení Zadavatele.
4.1.4.1.3 Odhad pracnosti v ČLD
Odhad pracnosti v ČLD pro řešení drobné úpravy, činnosti na objednávku a mimozáruční vady.
Vyřešením požadavku se rozumí zejména následující činnosti Dodavatele:
- vypracování analýzy a návrhu řešení,
- implementace dle Zadavatelem odsouhlaseného návrhu řešení, včetně případné úpravy dat,
- provedení interního otestování,
- předání úpravy Zadavateli k testování,
- zařazení úpravy do příslušné verze IS DMVS (dodávka nové verze IS DMVS nebo opravný patch).
Kritické chyby a závažné chyby budou v rámci PÚ řešeny se stejným SLA jako kritické chyby spadající do záruky, viz Příloha ZD09.
4.1.4.1.5 Činnosti v oblasti bezpečnosti
Rozsah činností Dodavatele je uveden v bodu 4.1.5, přičemž Dodavatel při řešení zranitelností postupuje podle bodů 4.1.4.1.1 až 4.1.4.1.4.
4.1.4.1.6 Monitorování provozu
Zadavatel požaduje, aby Dodavatel v rámci PÚ, minimálně v období 3 pracovních dnů následujících po instalaci změn IS DMVS do produkčního prostředí, případně až do vyřešení zjištěných problémů, prováděl monitorování provozu IS DMVS. Monitorovány musí být zejména části IS DMVS, které byly v rámci dané verze modifikovány (modifikací se rozumí i zavedení nové funkčnosti), nebo části, které nebyly modifikovány, ale mohou být úpravami přímo nebo nepřímo ovlivněny.
Výsledky monitorování provozu budou vzájemně odsouhlaseným způsobem v dohodnutých časových intervalech předávány Zadavateli. U nově zaváděných funkčností zároveň Dodavatel předá Zadavateli popis provozního monitorování (sledované metriky, způsob získávání metrik, jejich meze, typické intervaly sledování, reakce na mezní hodnoty). Dodavatel bude dále v rámci monitorování upozorňovat Zadavatele na problémy (nefunkčnost, úzká místa atd.), která při monitorování zjistil. U problémů, které mohou ohrozit funkčnost IS DMVS, bude Dodavatel upozorňovat Zadavatele bezodkladně.
Zadavatel požaduje, aby Účastník ZŘ v nabídce popsal způsob (organizačně/procesně i technicky), jakým zajistí poinstalační monitorování provozu IS DMVS v rámci PÚ - jak zajistí monitorování, jak bude určovat a vyhodnocovat naměřené parametry a upozorňovat Zadavatele na kritické stavy.
4.1.4.1.7 Zajištění podpůrných a souvisejících činností s plněním VZ
Zajištěním všech podpůrných a souvisejících činností s plněním VZ se rozumí zejména:
- podpora při instalaci změn (dodávek) IS DMVS na referenční a produkční prostředí,
- vedení a administrace projektu,
- zajištění online dostupného zabezpečeného úložiště (viz bod 4.22),
- zřízení, zdokumentování a vedení projektové kanceláře (viz bod 4.15),
- zajištění a zdokumentování propojení HD systémů pro řízení testování (viz bod 4.7),
- komunikace se Zadavatelem, účast na schůzkách, součinnost s třetími stranami,
Zadavatel v této souvislosti požaduje, aby Dodavatel v předstihu minimálně 5 dní před fakturací za PÚ předkládal Zadavateli k odsouhlasení výkazy či přehledy s výsledky průběžné provozní údržby za dané období.
Závazný vzor výkazu práce za provozní údržbu není stanoven. Provozní údržba bude vykazována měsíčně a konečná podoba výkazu bude stanovena až s vítězem zadávacího řízení s přihlédnutím k jeho interní evidenci práce.
V IS DMVS budou vedeny osobní údaje dle zákona č. 110/2019 Sb., o zpracování osobních údajů, ve znění pozdějších předpisů. Předmětem zpracování v IS DMVS nebude zvláštní kategorie osobních údajů ve smyslu čl. 9 GDPR (citlivé údaje). Zabezpečení zpracování osobních údajů v IS DMVS bude upraveno příslušnými vnitřními předpisy (zejména „Politikou systému řízení bezpečnosti informací resortu ČÚZK“ a „Opatřením, kterým se stanovují závazná pravidla pro zpracování a ochraně osobních údajů a postupy při uplatnění práv subjektu údajů v podmínkách ČÚZK“). Osobní údaje budou uloženy v databázi IS DMVS a přístup k nim bude umožněn jen oprávněným zaměstnancům ČÚZK na základě jim přidělené
uživatelské role. Oprávněným zaměstnancům ČÚZK bude jejich role přidělovat pověřený administrátor přístupů, kterým bude pověřený vedoucí zaměstnanec ČÚZK.
Při realizaci předmětu plnění je Dodavatel povinen zajistit minimálně splnění požadavků kladených platnými právními předpisy na IS KII a VIS, a to zejména dle zákona č. 365/2000 Sb., o informačních systémech veřejné správy a podle zákona č. 181/2014 Sb., o kybernetické bezpečnosti, včetně jejich prováděcích předpisů.
Seznam bezpečnostních dokumentů Zadavatele je uveden v Příloze ZD11.
4.1.5.1 Stupně důvěrnosti informací
Zadavatel požaduje všechny informace týkající se předmětu plnění (dále též jen „informace“) klasifikovat a přidělovat jim následující stupně důvěrnosti:
- Veřejné – informace, jejichž zveřejnění nenaruší bezpečnost informací v resortu.
- Interní – informace, jejichž zveřejnění mimo Zadavatele by mohlo narušit bezpečnost informací, jsou určeny pouze pro zaměstnance Zadavatele nebo Dodavatele.
- Diskrétní – informace, se kterými se smí seznamovat pouze určený okruh osob.
- Přísně diskrétní – informace vyžadující nejvyšší stupeň ochrany; mohou se s nimi seznamovat pouze přesně určené fyzické osoby, přístup k těmto informacím podléhá písemné evidenci.
Informace bez označení stupně důvěrnosti bude klasifikována jako „interní“.
4.1.5.2 Činnosti Dodavatele/Specialisty kybernetické bezpečnosti prováděné v rámci měsíčního paušálu
Zadavatel požaduje, aby specialista kybernetické bezpečnosti Dodavatele dle XxXX zastával pro IS DMVS roli:
- manažer kybernetické bezpečnosti,
- architekt kybernetické bezpečnosti.
Uvedené role, včetně povinností, které z těchto rolí vyplývají, jsou uvedeny v Příloze ZD15. Tyto role mohou zastávat dvě osoby Dodavatele (obě tyto osoby pak musí splňovat kvalifikační požadavky Zadavatele na Specialistu kybernetické bezpečnosti).
Zadavatel požaduje, aby Účastník ZŘ v nabídce popsal, jakým způsobem bude dle tohoto bodu a jeho podbodů proaktivně zajišťovat bezpečnost IS DMVS (používané procesy a činnosti Dodavatele, např. kontrola v rámci průběhu analýzy řešení, kontroly kódu, případně způsob provádění bezpečnostních testů nad rámec uvedený v Příloze ZD10 atd.).
4.1.5.2.1 Oblast dokumentace
Zadavatel požaduje, aby Dodavatel při celkové akceptaci plnění a dále 1x ročně:
- dle ZoISVS vyhodnotil dodržování Informační koncepce informačních systémů veřejné správy resortu zeměměřictví a katastru (části týkající se IS DMVS), stanovil závěry z vyhodnocení a navrhl opatření, která budou přijata k odstranění nedostatků, a to formou zápisu o vyhodnocení,
- dle ZoISVS aktualizoval a nadále udržoval aktuální provozní dokumentaci IS DMVS,
- dle ZoKB a VoKB předal a nadále udržoval aktuální bezpečnostní dokumentaci IS DMVS dle Přílohy ZD12.
4.1.5.2.2 Další činnosti
- sledovat zejména:
o informační servis Národního úřadu pro kybernetickou a informační bezpečnost,
o security bulletiny/advisory společností, jejichž SW se v IS DMVS využívá
o další zdroje zabývající se zveřejňováním zranitelností,
a pravidelně Zadavatele informovat o možných relevantních hrozbách a zranitelnostech souvisejících s IS DMVS navrhovat opatření na jejich eliminaci,
- navrhovat změny (zlepšení) v oblasti bezpečnosti IS DMVS,
- z hlediska bezpečnosti průběžně sledovat a kontrolovat projednávané změny a úpravy IS DMVS (analýzy a návrhy řešení) a navrhovat případné úpravy,
- pro oblasti zasažené/měněné v dodávce IS DMVS provádět z hlediska bezpečnosti kontrolu architektury a kódu (code review),
- při každé změně IS DMVS předat do měsíce aktualizaci havarijního plánu (tj. plánů obnovy) IS DMVS včetně postupů při obnově provozu IS DMVS,
- do jednoho měsíce od začátku účinnosti smlouvy a v souladu s bodem 4.15 vytvořit a udržovat aktuální dokument popisující zajištění bezpečnosti (organizační i technická opatření) projektové kanceláře Dodavatele včetně řízení přístupu k ní,
- trvale zajišťovat bezpečnost informací a bezpečnost činností při vlastním plnění Dodavatele (zabezpečení infrastruktury, postupů, ochrany dat apod.),
- svolávat minimálně 1x za 2 měsíce v sídle Zadavatele jednání k zajištění bezpečnosti IS DMVS a pořizovat z nich zápisy. Na jednáních informovat o aktuálním stavu plnění činností, úkolů, konzultovat spolu se zástupcem Zadavatele problémy, předkládat návrhy na zlepšení bezpečnosti, předkládat k připomínkám návrhy/aktualizace dokumentů aj.,
- průběžně zajišťovat aktuálnost dokumentů týkajících se bezpečnosti uvedených v Příloze ZD12.
4.1.5.2.3 Oblast bezpečnostních testů
Zadavatel požaduje, aby Dodavatel provedl bezpečnostní testy IS DMVS před předáním plnění k celkové akceptaci a dále vždy před předáním dodávky nové verze nebo hotfixu/patche IS DMVS, a to minimálně v rozsahu dle Přílohy ZD10.
Na základě zjištěných zranitelností nebo při jiných bezpečnostních testech, auditech, penetračních testech anebo na základě zjištění výskytu možné zranitelnosti musí Specialista kybernetické bezpečnosti zajistit včasný návrh a realizaci opatření schválených Zadavatelem.
4.1.5.3 Činnosti na objednávku v oblasti bezpečnosti
Činnostmi na objednávku se rozumí zejména:
- poskytnutí součinnosti Zadavateli při kontrole prováděné Ministerstvem vnitra ČR dle XxXXXX,
- poskytnutí součinnosti Zadavateli při kontrole v oblasti kybernetické bezpečnosti prováděné dle ZoKB,
- činnosti Dodavatele spojené s implementací oprav na odstranění zranitelností, které nevznikly při jeho plnění.
Cílem projektu je vytvoření IS DMVS s jednotným komunikačním rozhraním, který bude zajišťovat funkcionalitu danou právními předpisy, zejména ZemZ a prováděcí vyhláškou o digitální technické mapě (návrh vyhlášky viz Příloha ZD03). Požadovaná funkčnost je specifikována v Příloze ZD02 formou globální architektury IS DMVS a v Příloze ZD04, která popisuje jednotné komunikační rozhraní a technické parametry IS DMVS. V rámci plnění předmětu VZ je požadována realizace dle harmonogramu v Příloze ZD05. IS DMVS musí být připraven na pravidelné i nepravidelné změny, doplňování a úpravy funkcionalit, datových struktur a dalších prvků dle potřeb a požadavků Zadavatele.
Zapojení pracovníků Zadavatele
Zadavatel požaduje, aby Dodavatel v celém průběhu plnění VZ:
- umožnil Zadavateli odborný dohled nad pracovníky Dodavatele (kontrola kvality kódu, dodržování standardů, projektových postupů, možnost řízení technologických a koncepčních směrů IS DMVS apod.),
- umožnil Zadavateli neomezený a úplný přístup ke svému vývojovému prostředí, zdrojovým kódům, systému pro správu a verzování zdrojových kódů, produktům/nástrojům, technologické infrastruktuře, dokumentaci a všem dalším podkladům a výstupům souvisejícím s plněním VZ, včetně umožnění tohoto přístupu prostřednictvím sítě internet (např. VPN).
Vybudování IS DMVS je podmíněno právními předpisy, zejména XxxX, který nově přináší povinnost ČÚZK vybudovat a spravovat IS DMVS. IS DMVS bude centrální části systému zastřešující krajské IS DTM a bude zajišťovat funkce, které je nutné řešit na centrální úrovni. Předmět plnění této veřejné zakázky zahrnuje i zapracování změn právních předpisů, případně nových právních předpisů, které budou publikovány ve Sbírce zákonů do 30. 9. 2025.
Zadavatel požaduje, aby při plnění předmětu VZ byly dodržovány všechny relevantní právní předpisy upravující působnost a činnost Zadavatele.
Závazná právní úprava
IS DMVS bude jedním z pěti základních informačních systémů pro Digitalizaci stavebního řízení a územního plánování. IS DMVS bude tvořen propojením katastrální mapy, ortofoto mapy a digitálních technických map krajů. ZemZ ve znění účinném od 1. 7. 2023, v § 4d odst. 3) zákona stanoví, že IS DMVS zajišťuje zejména:
a. jednotné rozhraní pro zobrazení katastrální mapy, ortofoto mapy a digitálních technických map krajů; krajské úřady poskytují k tomu nezbytnou součinnost,
b. jednotné rozhraní pro předávání údajů k aktualizaci digitálních technických map krajů,
c. vedení seznamu vlastníků, provozovatelů a správců technické infrastruktury, včetně údajů o tom, v jakém území plní povinnost podle § 161 odst. 1 věty druhé StavZ, a vlastníků, provozovatelů a správců dopravní infrastruktury včetně údajů o tom, v jakém území působí,
d. vedení seznamu editorů digitálních technických map krajů a osob, které za editora plní jeho editační povinnost, včetně rozsahu jejich oprávnění k editaci.
Další požadavky na IS DMVS klade např.:
- zákon č. 194/2017 Sb., o opatřeních ke snížení nákladů na zavádění vysokorychlostních sítí elektronických komunikací a o změně některých souvisejících zákonů ve znění pozdějších předpisů,
- zákon č. 123/1998 Sb., o právu na informace o životním prostředí,
- zákon č. 183/2006 Sb., o územním plánování a stavebním řádu (stavební zákon),
- zákon č. 12/2020 Sb., o právu na digitální služby a o změně některých zákonů (digitální ústava),
- vyhláška č. 31/1995 Sb., kterou se provádí zákon č. 200/1994 Sb. o zeměměřictví a o změně a doplnění některých zákonů souvisejících s jeho zavedením
- vyhláška č. 499/2006 Sb., o dokumentaci staveb,
- vyhláška č. 500/2006 Sb., o územně analytických podkladech, územně plánovací dokumentaci a způsobu evidence územně plánovací činnosti (vyhláška o ÚAP),
- vyhláška č. 526/2006 Sb., kterou se provádějí některá ustanovení stavebního zákona ve věcech stavebního řádu.
Očekávané úpravy právních předpisů
V legislativním procesu je prováděcí vyhláška o digitální technické mapě (viz Příloha ZD03), která stanoví:
- obsah DTM,
- zjednodušený způsob vedení DTM,
- způsob předávání údajů o změnách obsahu DTM,
- výměnný formát DTM,
- obsah seznamu vlastníků, správců a provozovatelů DTI,
- obsah seznamu editorů DTM.
Obecné požadavky na IS DMVS z hlediska architektury:
- co největší dodržování SOLID principu1,
- při propojování IS DMVS s ostatními IS nebo aplikacemi musí být v co největší míře využity standardní integrační prostředky a platformy (API, WS, ESB), namísto proprietárních a těsných vazeb.
- IS DMVS musí mít oddělenou business logiku od prezentace a dat, musí být škálovatelný, auditovatelný a musí mít možnost dalšího rozvoje a rozšíření za pomoci technologií splňujících průmyslové standardy a zamezení dodávky ve formě tzv. „black boxu“,
- IS DMVS musí být otevřen pro změny a doplňování nových modulů, které musí být realizovatelné za minimálního dopadu na provoz,
- IS DMVS musí být tvořen tak, aby obsahoval co nejmenší počet závislostí ve smyslu, že požadavek na úpravu/doplnění funkčnosti v jednom modulu vyvolá změny v jiných modulech,
1 SOLID (single responsibility, open-closed, Liskov substitution, interface segregation, dependence inversion) je sada doporučení, principů a vodítek, sloužících k tvoření objektového návrhu.
- IS DMVS musí být tvořen tak, aby například změny workflow vyvolané změnami právních předpisů bylo možné navrhnout a realizovat co nejvíce konfiguračně nebo bez zásadní změny architektury.
Zadavatel požaduje, aby Účastník ZŘ v rámci nabídky podrobně popsal návrh řešení IS DMVS z hlediska architektury a jeho komponent.
Při rozvoji IS DMVS v technologické oblasti musí Dodavatel zajistit plnou integritu a funkčnost jak všech částí IS DMVS, tak celého systému jako celku.
Pokud bude při plnění nutná migrace nebo úprava dat, musí proběhnout v co nejkratší době a s minimálním dopadem a s využitím současného provozovaného HW.
Dodavatel musí vzhledem k ochraně investic Zadavatele při návrhu řešení respektovat současné HW prostředí Zadavatele.
Zadavatel požaduje, aby Dodavatel navrhl IS DMVS jako centralizovaný, využívající clustering na všech úrovních (databázová, aplikační, …) v režimu active-active přes obě Zadavatelem provozované lokality. Výpadek jedné z lokalit nesmí způsobit nedostupnost služeb nebo ztrátu dat.
Zadavatel předpokládá provoz IS DMVS na Oracle Database Enterprise Edition (v době implementace verze 19c), kterou má plně licencovanou pro provoz na své TI, včetně RAC.
V oblasti aplikačních serverů má Zadavatel licencován produkt Oracle Weblogic Server Suite. Podrobný popis TI Zadavatele a licencí Oracle dostupných pro provoz IS DMVS je uveden v Příloze ZD06.
Zadavatel připouští použití SW nebo služby třetí strany, včetně nekomerčních/Open Source. V případě nekomerčního/Open Source SW Zadavatel požaduje, aby za něj Dodavatel převzal plnou odpovědnost a zajistil jeho podporu, opravy chyb atd., viz též bod 4.18.
Obecné požadavky:
- Použité systémové platformy a SW musí mít garanci průběžného vývoje a oprav po dobu pěti let od zahájení jejich produkčního provozu u Zadavatele a podpory od výrobce nebo dodavatele další tři roky po ukončení vývoje této platformy.
- Provozovaný software pro IS DMVS musí vždy respektovat certifikační matice jednotlivých produktů, včetně vazeb na OS apod.
Zadavatel požaduje, aby Účastník ZŘ v rámci nabídky podrobně popsal jím navrhovanou technologickou oblast řešení, včetně SW (databáze, aplikační servery, middleware, frameworky, mapový editor atd.).
Mapový prohlížeč a editor
Součástí IS DMVS bude i mapový prohlížeč a editor specifikovaný v příloze ZD02.
Zadavatel vlastní licence pro Aplikační mapový server - AMS Marushka pro 1 nebo více publikačních center a neomezený počet uživatelů, který již provozuje na jiných projektech.
Zadavatel upozorňuje, že dle licenčních podmínek není oprávněn tento licencovaný software zveřejnit, zpřístupnit třetí straně nebo použít v její prospěch, prodat, postoupit, pronajmout, zapůjčit nebo jinak poskytnout, komerčně využívat, provozovat jako službu nebo komerčně sdílet či jinak tržně realizovat, ať už za poplatek nebo zdarma.
Zadavatel požaduje, aby Dodavatel v průběhu plnění VZ poskytoval součinnost (např. doporučení nových verzí k instalaci, součinnost při testování, řešení problémů,…) při provádění upgrade používaného SW na aktuálně podporované verze. Požadavek se týká jak serverové, tak klientské části.
Nabízené řešení musí umožňovat instalovat bezpečnostní patche instalovaného SW bez nutnosti úprav DMVS, pokud nebude dohodnuto jinak.
Obecné podmínky
Řešení pro monitorování provozu musí umožňovat monitorování odděleně pro jednotlivé moduly DMVS.
Rozhraní pro monitoring
Zadavatel požaduje, aby Účastník ZŘ v rámci nabídky popsal návrh na specifikaci rozhraní (SQL dotazy, skripty…), kterým budou výsledky monitorování předávány Zadavateli pro napojení do jím používaných systémů pro monitorování:
- Manageengine Application manager (xxxxx://xxx.xxxxxxxxxxxx.xxx/xxxxxxxx/xxxxxxxxxxxx_xxxxxxx/),
- Cacti (xxxxx://xxx.xxxxx.xxx/),
- Oracle Enterprise manager – Cloud control xxxxx://xxx.xxxxxx.xxx/xxxxxxxxxxx/xxx/xxxxxxxxxx-xxxxxxx/xxxxxxxx/xxxxx.xxxx),
- Icinga (xxxxx://xxxxxx.xxx/).
Další požadavky na monitorování jsou uvedeny v Příloze ZD02.
Dokumentace
V rámci předání každé dodávky IS DMVS má Dodavatel povinnost předat Zadavateli podklady pro nastavení monitoringu:
- definice sledovaných oblastí a metrik,
- dvojúrovňové definice hodnot jednotlivých metrik ukazující na problémy IS DMVS; první úroveň je varování před možnými problémy, druhá úroveň je závažný stav,
- aktualizovaný popis monitorování provozu a funkčnosti IS DMVS,
- aktualizovaný popis rozhraní pro předávání výsledků monitorování,
- dokument s upozorněním na možné problematické oblasti a jejich speciální monitorování, které mohou v rámci změn v dané dodávce IS DMVS vzniknout.
Zadavatel konstatuje, že výchozím zdrojem evidence problémů/požadavků souvisejících s předmětem plnění veřejné zakázky bude systém pro hlášení a reportování chyb z testování SDM, provozovaný na produktu CA Service Desk Manager verze r.17.
Zadavatel požaduje, aby Účastník ZŘ v příloze smlouvy popsal procesy, kterými budou problémy/požadavky na straně Dodavatele evidovány, zpracovávány a řešeny; přímé řešení v SDM Zadavatele se nepředpokládá ani nepožaduje.
Zadavatel dále požaduje, aby Dodavatel zajistil odpovídající technické podmínky pro dosažení průběžného a automatizovaného souladu obsahu SDM Zadavatele a HD Dodavatele tak, aby funkční automatické propojení obou systémů prostřednictvím webových služeb bylo k dispozici nejpozději do 3 měsíců od účinnosti smlouvy.
Popis požadovaných/předávaných údajů ze SDM Zadavatele do HD Dodavatele a obráceně je uveden v Příloze ZD13.
Součinnost s třetími stranami v oblasti HW a SW
Zadavatel požaduje úzkou spolupráci Dodavatele s dodavateli a výrobci stávající TI, programového vybavení a souvisejících či spolupracujících interních či externích aplikací či informačních systémů, a to minimálně v členění a rozsahu uvedeném v tomto bodu. V případě pořízení dalších komponent TI IS DMVS bude obdobná spolupráce požadována i pro další, zde neuvedené, dodavatele.
Dodavatel si musí zajistit veškerý SW včetně příslušných licencí, který je nutný pro rozvoj IS DMVS a který bude provozovaný mimo infrastrukturu Zadavatele.
HW
Zadavatel požaduje v případě potřeby spolupráci Dodavatele s hlavním dodavatelem HW, se společností GC System a.s. (dodavatel centrální ICT infrastruktury ČÚZK) a Hewlett-Packard s.r.o. (disková pole). Dále Zadavatel požaduje spolupráci Dodavatele i s případnými dalšími dodavateli HW.
Operační systémy
Zadavatel požaduje v případě potřeby spolupráci Dodavatele s dodavateli operačních systémů, používaných v centrální infrastruktuře ČÚZK. Jedná se o OS AIX a Linux-RedHat (dodavatelem je společnost GC System a.s.) a Windows (dodavatelem je společnost MICROSOFT, s. r. o.).
SW pro antimalwarovou ochranu
Pro ochranu stanic, notebooků a serverů v prostředí Zadavatele je využíván produkt Sophos Endpoint Protection.
Kancelářské a další aplikace
Jako kancelářská aplikace se používá Microsoft Office 2016 Standard. Dále je běžně užíván Adobe Acrobat Reader DC, PDF – XChange, 602 XML Filler, 7-Zip.
Elektronická podatelna (EPVDS)
Dodavatel: xxxxx.xx, a.s.
Zadavatel požaduje spolupráci Dodavatele s xxxxx.xx, a.s. v oblastech napojení IS DMVS na EPVDS pro provádění obesílání.
LDAP/AD a elektronická pošta
Zadavatel požaduje v případě potřeby spolupráci Dodavatele se společností Microsoft s.r.o., jejíž produkty Exchange 2013/2016 a Active Directory (lokální, nikoliv Azure AD) Zadavatel provozuje.
Základní registry
XXX, registr obyvatel, stávající dodavatel: ICZ a. s.,
ROS, registr osob, stávající dodavatel: Xxxxxxx, s. r. o.,
RÚIAN, registr územní identifikace, adres a nemovitostí, stávající dodavatel Ness Czech s.r.o. RPP, registr práv a povinností, stávající dodavatel: Asseco Central Europe, a. s.,
ISZR, informační systém základních registrů, stávající dodavatel: AutoCont a. s.,
ORG, převodník jednoznačných identifikátorů fyzických osob (AIFO), stávající dodavatel: Tesco SW a. s.
Také u všech výše uvedených registrů může dojít v době trvání smlouvy ke změně dodavatelů. Požadavky Zadavatele na integraci IS DMVS s ISZR jsou uvedeny v Příloze ZD02.
Zásadním požadavkem Zadavatele na rozvoj IS DMVS je soulad se všemi relevantními standardy, a to zejména principu SOLID, s veřejnými standardy vydávanými organizacemi ISO, IEEE, IETF, se standardy vztahujícími se ke zvoleným technickým prostředkům, se standardy ISVS (nyní prováděcí vyhlášky k ZoISVS), splnění minimálních technických požadavků dle ZoKB a uvedených v jeho prováděcích právních předpisech, a to ve všech fázích a jednotlivých dílčích krocích při vybudování a rozvoji IS DMVS. Další požadavky Zadavatele, zejména upřesnění formy a výstupů z analytických činností a požadavky na dokumentaci, jsou uvedeny v odst. 4.9.3.
Zadavatel požaduje použít při plnění veřejné zakázky takovou metodiku vývoje IS, která umožňuje použití metody prototypování, a to minimálně v níže uvedených krocích s tím, že pro výsledky provozní údržby IS DMVS se použijí v přiměřeném rozsahu. Metodika vývoje musí pokrývat/reflektovat i provozní údržbu.
Zadavatel požaduje, aby Účastník ZŘ v nabídce ve formě přílohy smlouvy podrobně popsal metodiku vývoje, včetně použitých technologií a nástrojů pro vývoj, řízení projektu atd.
Analýza
Tato část zahrnuje zejména analýzu požadavků, definování funkčnosti, stanovení základních principů řešení s možností variant, návaznost na okolí, úprav/návrhu datového a funkčního modelu, vytvoření základních návrhů sestav, obrazovek, včetně jejich vzájemných návazností (workflow) a odhadu výsledků výkonnostních testů s cílem umožnit Zadavateli posoudit vhodnost řešení a to včetně stanovení nákladů implementace (pokud půjde o variantní řešení, pak pro každou z variant samostatně). Součástí je i analýza dat potřebných pro provoz systému a analýza existujících dat určených pro migraci do systému a stanovení požadavků pro případná zadávací řízení na nezbytné modifikace hardwarové a softwarové základny IS DMVS, případně další komponenty (požadavky na případná zadávací řízení a jejich parametry musí být projednány a odsouhlaseny Zadavatelem).
Zadavatel požaduje provádění analýz iterativním postupem. Po každé iteraci bude Zadavatel analytické výstupy připomínkovat, aby bylo zřejmé, že se řešení ubírá požadovaným směrem. Zpřesnění analýzy jsou dále přípustná, např. dle výsledků ověření prototypovaných řešení.
Design, vyhotovení prototypů, dokončení vývoje
Prototyp, pokud bude vyžadován, umožňuje posoudit sestavy, uživatelské rozhraní/interface, základní funkčnost a odezvy, komunikaci s dalšími IS a workflow.
Zadavatel spolupracuje s Dodavatelem při řešení připomínek a vyvstalých problémů, podává návrhy na úpravy řešení. Vyhotovení prototypu, jeho testování a oboustranné odsouhlasení předchází fázi dokončení vývoje. Při přípravě harmonogramu dané dodávky IS DMVS, obsahující požadavky na prototyp, musí být činnosti spojené s prototypovanými modifikacemi předřazeny fázi dokončení vývoje, a to s dostatečným časovým prostorem.
Obecné požadavky na dokumentaci jsou uvedeny v Příloze ZD14.
4.9.3.1 Vývojářská dokumentace
Požadavky na vývojářskou dokumentaci jsou uvedeny v Příloze ZD14.
4.9.3.2 Provozní dokumentace
Zadavatel požaduje, aby Dodavatel průběžně vytvářel a udržoval provozní dokumentaci IS DMVS.
Provozní dokumentace musí obsahovat četnost a přehled všech činností administrátorů souvisejících s provozem IS DMVS, které musí kontrolovat či provádět. Tím je myšlena například povinnost DB administrátora vytvářet nové tablespace pro časový partitioning, kontrola běhu některých procesů (DB jobů) a detekce jejich neúspěchů, promazávání logů IS DMVS na aplikačních serverech, sledování aplikačního žurnálu, podklady pro kontrolu funkčnosti systému a vyhodnocování chybových stavů atd.
V případě potřeby poskytne Zadavatel Dodavateli součinnost.
4.9.3.3 Instalační dokumentace
Zadavatel požaduje, aby Dodavatel průběžně vytvářel a udržoval instalační dokumentaci IS DMVS.
Instalační dokumentace musí obsahovat popis všech činností pro instalaci systému od úrovně základního software (např. požadavky na instalaci operačního systému atd.) až po aplikace, aby Zadavatel mohl na základě předané instalační dokumentace a předávaných výstupů provést kompletní instalaci IS DMVS na nově vytvořeném prostředí, na kterém je zprovozněn základní software a vytvořena databáze pro IS DMVS.
4.9.3.4 Obsah provozní a instalační dokumentace
Požadavky Zadavatele na věcný a formální obsah instalační a provozní dokumentace (po dohodě se Zadavatelem lze obsah rozdělit na několik samostatně udržovaných dokumentů):
a) Členění po jednotlivých logických celcích IS DMVS a po vrstvách TI (DB, aplikační, prezentační, grafická, klientská …).
b) Specifikace požadavků na infrastrukturu (typy serverů, sítě) a SW (OS, verze DB, potřebné doplňky DB, aplikační servery – typ instalace, verze, patche, ...).
c) Dokumentace nemusí popisovat obecnou instalaci OS a SW, ale musí obsahovat popis parametrů, které jsou jiné než standardní (seznam výjimek). Popis instalace SW bude udržovat Zadavatel, po Dodavateli se požaduje poskytnutí potřebné součinnosti.
d) Popis všech kroků pro úspěšnou instalaci komponent IS DMVS - vytvoření DB schématu, vytvoření tablespace, nahrání DB objektů, instalace a konfigurace grafických serverů, prezentačních serverů, aplikačních serverů, deploy aplikací na server, uložení certifikátů a klíčů apod.
e) Popis veškeré aktuální konfigurace systému (v tomto bodě dále jako „popis“). Rozsáhlejší konfigurační soubory nemusí být obsaženy přímo v tomto popisu, ale mohou být předány jako samostatné soubory v adresářové struktuře, která bude přílohou popisu (v popisu je potřeba uvést odkazy na konfigurační soubory v adresářové struktuře). Rozsahem menší konfigurace mohou být obsaženy přímo v popisu a zároveň též jako příloha ve zmíněné adresářové struktuře. Adresářová struktura musí být vhodně členěna dle typu serverů a prostředí IS DMVS.
f) Aktualizace při změnách konfigurace i při nových verzích systémů IS DMVS.
g) Datová struktura IS DMVS musí být primárně vedena v programátorské dokumentaci. Z pohledu provozu je nutné instalovat DB tabulky včetně komentářů. Komentáře ke sloupcům tabulky ponesou vysvětlující text k účelu sloupce, v komentáři celé tabulky bude vysvětlen účel tabulky v rámci IS DMVS a popis dat v ní uchovávaných a označení verze tabulky.
h) Přehled všech možností konfigurace systému, včetně aplikačních konstant. V přehledu bude vypsáno označení (kód a název DB konstanty, název atributu v XML, ...), kde se nastavení nachází (DB, soubor na serveru, ...), čeho se konfigurace týká, jaké možnosti nabízí, zdali je možné upravit konfiguraci za provozu systému, zdali je úprava platná ihned po změně nebo je potřeba další akce (restart komponenty) a významový popis jednotlivých možností na chod systému. Odkazy na dokumenty z výstupu analýzy, v rámci kterých konfigurace vznikla či byla modifikována.
i) Přehled všech modulů aplikace IS DMVS tedy i „nevizuální“ moduly. K modulům je potřeba uvést popis, co vykonávají a jak je jejich činnost auditována z pohledu DMVS. Odkazy na dokumenty z výstupu analýzy, v rámci kterých moduly vznikly.
j) Postupy pro monitoring jednotlivých částí IS DMVS , popis metrik a způsobu jejich získávání, mezní hodnoty metrik a reakce na překročení těchto mezních hodnot, typické intervaly sledování metrik. Více informací je uvedeno v bodě 4.6.
k) Přehled a popis databázových jobů a scheduled tasks vytvořených či vyžadovaných systémy IS DMVS. V popisu musí být zdokumentován nejen význam DB jobu, ale také, jak lze sledovat průběh jobu, kde se nacházejí výsledky DB jobu (log) a jaký dopad do funkčnosti IS DMVS bude mít odstávka DB jobu (plánovaná či neplánovaná).
l) Dokumentace vazeb IS DMVS na okolní IS – v této struktuře:
- slovní popis a obrazové schéma,
- znázornění toků dat,
- přesná definice rozhraní,
- odkazy na dokumenty (analýzu a design), kde se napojení na jiný IS řešilo.
Pokud IS DMVS využívá nějaké aplikační rozhraní jiného systému, je toto rozhraní také popsáno (bylo-li vytvořeno jen pro IS DMVS) nebo popis vazby obsahuje odkaz na dokumentaci rozhraní (pokud rozhraní a dokumentaci nevytvářel Zadavatel).
m) Další nastavení a činnosti systémů IS DMVS:
- zakládání speciálních uživatelů,
- nastavování práv a řízení přístupu,
- používání certifikátů (bezpečné uložení certifikátů).
n) Popis logování systému (umístění logů apod., systém sledování)
- logy databázových úloh,
- aplikační logy Java aplikací,
- logy na klientské stanici.
o) Postupy (návody krok za krokem včetně případných skriptů) pro:
- vybudování referenčního prostředí (například s využitím klonu produkčního prostředí a postupu pro ošetření vazeb a nedokončených úloh),
- vytvoření prostředí pro umožnění vývoje a testování externích informačních systémů napojených na IS DMVS (převážně přes WS), včetně možnosti testování změn v IS DMVS a přípravy na ně externími odběrateli.
4.9.3.5 Uživatelská dokumentace
Zadavatel požaduje, aby Dodavatel:
- pokud nebude při plnění VZ dohodnuto jinak, s každou novou verzí IS DMVS předal kompletní uživatelskou dokumentaci,
- dodával písemně přehled všech změn funkčnosti v každé konkrétní dodávce, aby uživatelská dokumentace IS DMVS byla předána nejpozději při předání plnění do akceptačního řízení,
- v případě, že se zásadním způsobem mění chování IS DMVS, jeho rozhraní apod., Zadavatel požaduje dodání uživatelské dokumentace 2 měsíce předem, aby mohla být s předstihem distribuována uživatelům a mohli se tak na změnu připravit.
Uživatelská dokumentace musí být členěna po skupinách uživatelů:
- administrátor IS DMVS (www rozhraní),
- administrátor IS DTM,
- editor DTI a ZPS, oprávněný uživatel.
Uživatelská dokumentace musí být:
- dodána pro offline distribuci (např. PDF formát, Web Help, HTML Help),
- integrována do www rozhraní minimálně na úrovní odkazů z jednotlivých stránek.
Zadavatel preferuje, aby dokumentace pro integraci do www rozhraní byla vytvářena nástrojem HelpSmith2, který je používán u IS provozovaných Zadavatelem3.
4.9.3.6 Dokumentace pro dodavatele IS využívajících rozhraní IS DMVS
Zadavatel požaduje, aby Dodavatel vytvářel a předával dokumentaci pro dodavatele/vývojáře IS využívajících rozhraní IS DMVS.
Dokumentace musí minimálně obsahovat:
- detailní specifikaci rozhraní Rxx (viz příloha ZD04), včetně WSDL, XSD apod.,
- seznam informačních a varovných hlášení a chyb, včetně vysvětlení,
3 Ukázka - Návrh na vklad do KN, xxxxx://xx.xxxx.xx/Xxx/Xxxx/xxxxx.xxx
- logiku práce s rozhraním - posloupnosti volání služeb atd.,
- další potřebné informace.
Konfigurační management Dodavatele musí umožňovat paralelní vývoj dodávek a patchů, a to bez negativního vlivu na kvalitu jednotlivých dodávek IS DMVS, a evidenci změn jednotlivých zdrojů, získat zpětně zdroje jak k jednotlivým realizovaným požadavkům/úpravám IS DMVS tak i globálně k libovolné verzi IS DMVS jako celku.
Uložení/potvrzení změny (commit) do verzovacího nástroje musí být možné jen při jejím svázání s požadavkem (task, bug, work item), na jehož základě se změna provedla.
Technologická infrastruktura Dodavatele
Zadavatel požaduje, aby pro realizaci předmětu plnění této veřejné zakázky použil Dodavatel TI a konfigurační management (viz 4.10), který bude minimálně umožňovat paralelní:
- vývoj a prototypování 2 dodávek,
- podporu produkčního provozu včetně všech činností, jako:
o vývoj/provádění změn,
o interní testování,
o referenční testování,
o integrační testy,
o bezpečnostní testy,
o atd.
Dodavatel musí zaručit, že má k dispozici nebo si zajistí TI, včetně SW, potřebnou pro realizaci předmětu plnění VZ, včetně jejího případného upgradu, a dále, že při návrzích na upgrade TI Zadavatele se bude řídit jen potřebami IS DMVS bez ohledu na jím vlastněnou TI a jiné projekty. TI pro vývoj dodávky DMVS I musí být zprovozněna a připravena k použití nejpozději do 3 měsíců od začátku účinnosti smlouvy, zároveň však nejpozději tak, aby byla k dispozici pro vývoj dodávky DMVS I.
Po zprovoznění TI Dodavatel předvede Zadavateli TI buď v prostorách Dodavatele nebo vzdáleným přístupem. Ověření TI pro vývoj dodávky DMVS I bude probíhat na modelovém požadavku (příloha ZD07). Ostatní TI požadovanou dle tohoto bodu ZD zprovozní Dodavatel dle Harmonogramu realizace díla (Příloha ZD05).
V rámci ověření TI bude Zadavateli předán popis TI Dodavatele dle tohoto bodu ZD.
Pokud nebude ověření TI pro vývoj dodávky DMVS I Zadavatelem úspěšné, má Zadavatel právo požadovat po Dodavateli za každý započatý den prodlení poskytnutí slevy z ceny ve výši 5 000 Kč, a to až do úspěšného otestování TI pro vývoj dodávky DMVS I.
Pokud k úspěšnému otestování Zadavatelem nedojde do 4 měsíců od začátku účinnosti smlouvy, má Zadavatel s ohledem na stěžejnost TI pro plnění celé smlouvy právo smlouvu vypovědět tak, že smlouva bude ukončena posledním dnem měsíce, ve kterém byla Dodavateli doručena její výpověď.
TI Dodavatele, která bude využívána pro plnění předmětu VZ, bude k dispozici i Zadavateli, viz bod 4.1.7.
Zadavatel požaduje, aby Účastník ZŘ v příloze smlouvy popsal metodiku, kterou bude používat pro interní testování IS DMVS. Interním testováním se rozumí testování na straně Dodavatele. Minimální rozsah interního testování, který bude doložen testovacím protokolem, je definován v Příloze ZD08.
Zadavatel požaduje, aby Účastník ZŘ uvedl zejména:
- popis, jak provádí interní testování,
- popis, jaký automatizovaný SW prostředek používá pro:
o funkční testování, včetně popisu:
o jaké typy testů (SQL Query, simulované klikání na ovládací prvky www nebo
desktopu,…) daný SW podporuje,
o jak daný SW prostředek využívá,
- popis testování bezpečnosti dle Přílohy ZD10, vč. používaného nástroje (např. specializované programové vybavení typu Acunetix, Metaspolit, Nessus,…),
- zda/jakým způsobem je podporováno testování v prostředí virtualizované infrastruktury,
- jak při vývoji používá unit testy.
Zadavatel požaduje, aby Dodavatel před předáním řešení k testování v referenčním prostředí Zadavatele prováděl interní testování na svém testovacím prostředí. Před nasazením nové dodávky IS DMVS na referenční pracoviště Zadavatele předá Dodavatel Zadavateli protokoly z provedeného interního testování, s ohledem na požadavky uvedené v Příloze ZD08.
Před nasazením nové verze IS DMVS do produkčního prostředí musí být provedeny uživatelské a bezpečnostní testy, s tím, že nalezené kritické zranitelnosti v oblasti bezpečnosti (viz stupně závažnosti v Příloze ZD10) musí být napraveny a opakovaně ověřeny před nasazením dané verze IS DMVS do produkčního prostředí.
Zadavatel dále vyžaduje, aby Dodavatel v rámci interního testování prováděl na svém testovacím prostředí (na prostředí Dodavatele) kontrolu výstupu/dodávky z hlediska souladu postupů s metodikou, standardy, obecně závaznými právními předpisy apod., přičemž za minimální rozsah interních testů Zadavatel považuje:
- testy funkcionality nových a měněných modulů,
- ověření funkčnosti komunikace s externími IS (je-li předmětem dodávky úprava, která ji může ovlivnit),
- provedení průřezových testů,
- ověření instalace včetně kontroly správnosti a úplnosti sestavení dodávky,
- ověření bezpečnosti webových služeb a aplikací,
- ověření, zda výstup vyhovuje z hlediska dostatečných odezev systému.
Popis rozsahu požadovaných interních testů, které předcházejí předání dodávky k testování a předání finální dodávky, jsou popsány v Příloze ZD08.
Vývojové/testovací prostředí pro vývoj IS napojených na IS DMVS
Zadavatel požaduje, aby součástí IS DMVS bylo i vývojové/testovací prostředí pro vývoj IS využívajících rozhraní IS DMVS (registrované subjekty, DTM kraje apod.). Toto prostředí musí minimálně umožňovat vývoj a testování rozhraní WS. V testovacím prostředí musí být neveřejná data anonymizována a nesmí být jakkoli odvoditelná z jiných vazeb. Datová základna nemusí být úplná, ale současně musí pokrýt všechny obvykle se vyskytující situace.
Testovací prostředí nebude napojené na IS DTM, jeho funkce musí být nahrazeny FAKE rozhraním nebo jen interně emulovány.
Uživatelé budou autentizováni buď proti testovací NIA nebo mohou být předpřipraveny konkrétní uživatelské profily.
Testovací prostředí musí být provozovatelné bez závislosti na provozu IS DMVS. Při změně rozhraní IS DMVS nebo JVF musí být k dispozici nejméně v předstihu instalace na produkční prostředí:
- 6 měsíců v případě, kdy nebude možné provozovat souběžně v produkčním prostředí starou a novou verzi,
- 1 měsíc v případě, kdy bude možné provozovat souběžně v produkčním prostředí starou a novou verzi.
Chybovost IS DMVS, cena plnění pro účely uplatnění slevy z plnění
Chybovost
Z důvodu dosažení odpovídající kvality IS DMVS Zadavatel požaduje, aby výskyt chyb zjištěných Zadavatelem při testování na referenčním prostředí byl prokazatelným způsobem na straně Dodavatele evidován (např. ve formě samostatné položky v HD Dodavatele) tak, aby se na tomto základě mohl výskyt chyb průběžně sledovat a po ukončení testování sumarizovat a po odsouhlasení Zadavatelem použít pro následné stanovení sankce za chyby v předmětu plnění (dále též „chybovost“). Za chybu se pro tyto účely považuje neshoda mezi vzájemně odsouhlaseným způsobem řešení požadavku a následnou funkčností ověřenou Zadavatelem na referenčním prostředí, která vyžaduje opravu a její opakované otestování. Není-li ani tato oprava úspěšná, započítává se opakovaně do chybovosti. Za chybu se považuje:
- chyba v instalačních zdrojích či v definovaném postupu instalace (vlastní instalaci provádí Zadavatel, a to jak na referenční prostředí, tak do prostředí produkčního),
- zjištěná nekonzistence v analýze, např. používání různých pojmů pro stejnou věc nebo chybějící části (např. v textu je uvedena chyba, která ale není uvedena v číselníku chyb).
Za chybu se nepovažuje nesoulad zjištěný při testování prototypů.
Zadavatel požaduje, aby se do celkové chybovosti v případě dodávky DMVS IV a následujících dodávek započítávaly i chyby v IS DMVS zjištěné v období 6 týdnů po instalaci IS DMVS do produkčního prostředí.
Výstupy vázané na dodávku IS DMVS
Zadavatel požaduje, aby Dodavatel v rámci předání implementační nebo produkční dodávky dle této VZ předal Zadavateli výstupy z plnění potřebné pro instalaci dodávky a pro další rozvoj a údržbu IS DMVS. Tyto výstupy jsou považovány za součást dodávky IS DMVS. Jedná se zejména o tyto výstupy:
- výstupní protokoly z interního testování na straně Dodavatele,
- všechny zdrojové kódy, včetně použitých nekomerčních/Open Source SW, přičemž dokumentace zdrojových kódů musí být na takové úrovni, aby byla srozumitelná i třetí, nezúčastněné osobě,
- export použitých repository,
- všechny používané nástroje, pomocné utility a skripty (např. pro konfigurační řízení, práce s verzovacím nástrojem, skripty pro tvorbu buildů apod.) a jejich detailní popis,
- testovací scénáře,
- analytické modely,
- design,
- programátorská dokumentace,
- uživatelská dokumentace,
- instalační a provozní dokumentace,
- dokumentace pro dodavatele IS využívajících rozhraní IS DMVS,
- dokumentaci webových služeb a dokumentaci všech WSDL, XML, XSD včetně podrobných komentářů jednotlivých elementů a atributů,
- popis TI, včetně všech komponent, analytické dokumenty odpovídající reálnému nasazení systému do ostrého provozu, včetně všech jeho komponent,
- popis monitorování provozu (viz bod 4.6),
- provozní dokumentace,
- výsledky bezpečnostních testů a provedení kontrolních checklistů.
Výstupy nevázané na dodávku IS DMVS
Zadavatel požaduje, aby Dodavatel níže uvedené výstupy v průběhu plnění VZ udržoval v aktuálním stavu a na vyžádání je Zadavateli předával, s tím, že poslední předání výstupů Zadavateli bude k datu ukončení smluvního vztahu. Jedná se zejména o:
- popis používaných nástrojů pro vývoj IS DMVS a jejich nastavení,
- popis konfiguračního řízení,
- projektové standardy (jmenné konvence apod.),
- použité způsoby a metodiky vývoje,
- checklisty pro kontrolu provedení všech potřebných kroků při tvorbě a sestavování dodávky (včetně bezpečnostních checklistů),
- principy monitorování a aktualizace požadavků v systému pro evidenci požadavků,
- bezpečnostní dokumentaci IS,
- kompletní export projektové kanceláře vedené dle bodu 4.15 dle požadavku na export uvedený v témže bodě,
- export obsahu HD Dodavatele (viz bod 4.7).
Průběžné výstupy
Zadavatel požaduje, aby Dodavatel umožnil provádění synchronní kopie SVN nebo obdobného nástroje používaného pro správu a verzování zdrojových kódů a jiných souborů do prostředí Zadavatele.
Vývojové prostředí
Zadavatel požaduje, aby jako součást poslední standardní dodávky IS DMVS v rámci této VZ Dodavatel na žádost Zadavatele a za přítomnosti pracovníků Zadavatele zprovoznil na infrastruktuře Zadavatele prostředí pro další rozvoj IS DMVS, a to pouze na základě posledních předaných výstupů dle bodů
4.14.2 a 4.14.3. Zajištění potřebných licencí vývojových nástrojů a produktů je v zodpovědnosti Zadavatele.
Součástí činností Dodavatele je provedení kontrolního sestavení kompletní poslední dodané verze IS DMVS a na jeho základě vytvoření dodávky IS DMVS, která bude pro její ověření z hlediska kompletnosti a funkčnosti všech částí IS DMVS Zadavatelem následně podle informací z předané dokumentace Dodavatele nainstalována na předem určené referenční prostředí Zadavatele.
Součástí zprovoznění je i vytvoření detailního popisu celého postupu, včetně seznamu nutného software, parametrů jeho instalace apod.
Akceptace poslední dodávky IS DMVS je možná pouze za předpokladu zprovoznění prostředí dle tohoto bodu.
V případě, že vytvoření a otestování takto vytvořené a nainstalované dodávky IS DMVS na referenčním prostředí Zadavatele po žádosti Zadavatele nebude úspěšné, vyhrazuje si Zadavatel právo udělit sankci až ve výši 10 000 000 Kč.
Vedení dokumentace – projektová kancelář
Zadavatel požaduje, aby Účastník ZŘ v přílohách smlouvy popsal základní principy a způsob vedení dokumentace projektových výstupů a vedení projektové kanceláře (PK) v elektronické podobě. PK může být řešena i formou online hostované služby u třetí strany.
Zadavatel požaduje pro práci s projektovými dokumenty používat:
- standardizovaný formát Office Open XML (OOXML, ISO/IEC 29500, ECMA 376) minimálně ve verzi standardu Office 2016,
- Office 2016 nebo jiné nástroje, které plně podporují možnosti používaného formátu OOXML, včetně možností revizí, strukturovaných komentářů a jejich vypořádávání.
U souborů, které Zadavatel nebude upravovat nebo připomínkovat, je po dohodě možné používat i jiný formát (např. PDF).
Požadavky na projektovou kancelář:
- vzdálený přístup pro určené zástupce Zadavatele prostřednictvím sítě internet,
- plnou funkčnost ve standardních prohlížečích (Microsoft Internet Explorer 11, Edge, Mozilla Firefox, prohlížeče založené na jádře Chromium, …),
- kontrola povinné jmenné konvence při rezervaci a vkládání souborů,
- fultextové vyhledávání,
- verzování souborů včetně označení verze i v rámci jména souboru,
- různé stupně důvěrnosti souborů dle bodu 4.1.5.1 včetně označení stupně důvěrnosti i v rámci jména souboru,
- struktura s rozdělením souborů podle logických kategorií (zápisy z jednání, žádosti o změnu, dokumentace,…) včetně označení kategorie i v rámci jména souboru,
- řízení uživatelského přístupu minimálně pro jednotlivé logické kategorie a stupně důvěrnosti s možností definice oprávnění minimálně typu: čtení/stažení souboru, rezervace souboru, vytvoření/vložení souboru, editace souboru, zneplatnění souboru,
- možnost rezervace nových souborů včetně automatického číslování v rámci jednotlivých logických kategorií,
- export celé PK na filesystém se zachováním rozdělení podle logických kategorií a všech verzí souborů,
- uložení různého typu souborů (Word, Excel, MS Project, ZIP, RAR,…),
- logování a audit.
Zadavatel požaduje minimálně denní zálohování obsahu PK s minimálně týdenní historií.
Zadavatel požaduje plné zprovoznění PK v rozsahu výše uvedených požadavků nejpozději do 2 měsíců od začátku účinnosti smlouvy.
Zadavatel si vyhrazuje právo rozhodovat o výsledné definici logických kategorií, typech dokumentů a jejich zkratek a o jmenné konvenci.
Akceptace výstupů Zadavatelem bude prováděna v závislosti na charakteru výstupu a na základě pravidel uvedených ve smlouvě.
Akceptační řízení musí vést k některému ze závěrů uvedených v čl. 4.16.5. Výsledky akceptačního řízení budou uvedeny do akceptačního protokolu.
Akceptační řízení musí být ukončeno nejpozději patnáctý pracovní den po jeho zahájení. Ukončením akceptačního řízení se rozumí podpis akceptačního protokolu oběma smluvními stranami.
Akceptační řízení jiného plnění než dodávky IS DMVS (např. analýzy)
Akceptační řízení začne nejpozději jedenáctý pracovní den po předání plnění ve finální podobě, pokud při převzetí plnění nedojde k jiné dohodě. Zadavatel nejméně dva pracovní dny před akceptačním řízením předá Dodavateli výhrady k předanému plnění s vyznačením jejich závažností. V rámci akceptačního řízení budou projednány výhrady Zadavatele, stanovena jejich výsledná závažnost a určen způsob a termín jejich odstranění. Při stanovení výsledné závažnosti připomínek Zadavatel vezme do úvahy stanovisko Dodavatele. V návaznosti na celkové posouzení stavu plnění bude stanovena i případná sankce za kvalitu daného plnění a prodlevu v plnění, a to ve formě slevy z ceny plnění.
Předání dodávky
Předáním dodávky se rozumí konzistentní předání všech výstupů, které dodávku tvoří (instalační zdroje, dokumentace, výstupy dle 4.14.2 atd.). Předání může být provedeno jak na médiu (CD, DVD, USB flash/disk atd.), tak elektronickou formou (e-mail, úložiště dle 4.22, atd.). Při předání bude vyhotoven předávací protokol, který obsahuje popis předání a otisk (hash) předávaných výstupů.
Akceptační řízení implementační dodávky
Po ověření instalace předané dodávky pomocí instalačních zdrojů na referenčním prostředí Zadavatele (provádí Zadavatel) a následném ukončení funkčních, průřezových a případně integračních testů odpovídajících implementačnímu milníku bude vyhodnocena závažnost neopravených chyb zjištěných při testování, vyřešení kritických a důležitých zranitelností v oblasti bezpečnosti (pokud jsou v dané implementační dodávce bezpečnostní testy vyžadovány) a závažnost chyb zjištěných při ověření instalace dodávky (a zapsaných do HD Dodavatele) a bude rozhodnuto o provedení nebo odložení implementace dodávky IS DMVS. Pokud bude rozhodnuto Zadavatelem o odložení implementace, považuje se plnění až do jeho řádného předání (bez chyb a zranitelností, které způsobily odložení implementace) za nepředané a Dodavatel je v prodlení s předáním plnění.
Akceptační řízení dodávky IS DMVS, která se instaluje do produkce
Po ověření instalace předané dodávky pomocí instalačních zdrojů na referenčním prostředí Zadavatele (provádí Zadavatel) a následném ukončení funkčních, průřezových a případně integračních testů bude vyhodnocena závažnost neopravených chyb zjištěných při testování, vyřešení kritických a důležitých zranitelností v oblasti bezpečnosti a závažnost chyb zjištěných při ověření instalace dodávky (a zapsaných do HD Dodavatele) a bude rozhodnuto o provedení nebo odložení instalace dodávky IS DMVS do produkčního prostředí. Pokud bude rozhodnuto Zadavatelem o odložení instalace, považuje se plnění až do jeho řádného předání (bez chyb a zranitelností, které způsobily odložení instalace) za nepředané a Dodavatel je v prodlení s předáním plnění.
Akceptační řízení bude zahájeno do 6 týdnů po provedení uživatelského ověření dané dodávky v produkčním prostředí tak, aby bylo možné na straně Zadavatele řádně zpracovat a vyhodnotit výsledky uživatelského ověření a posoudit chyby z produkčního prostředí nahlášené uživateli IS DMVS (a zapsaných do HD Dodavatele). Vstupem pro akceptační řízení budou také chyby zjištěné uživateli IS DMVS v období 6 týdnů po instalaci dodávky IS DMVS do produkčního prostředí.
Po vyhodnocení akceptačních uživatelských, výkonnostních testů a chyb z produkčního prostředí Zadavatel předá Dodavateli výhrady k předanému plnění s vyznačením jejich závažností. Při akceptačním řízení budou projednány výhrady Zadavatele, stanovena jejich výsledná závažnost a v návaznosti na to i výše doplatku dle čl. 4.16.6 a určen způsob a termín jejich odstranění.
Možné výsledky akceptačního řízení
4.16.5.1 Akceptováno bez výhrad
V případě, že Zadavatel v průběhu akceptačního řízení nenalezne v předaném plnění žádné vady ani nedodělky, uvede Zadavatel do akceptačního protokolu, že předané plnění bylo akceptováno bez výhrad a akceptační protokol potvrdí svým podpisem.
4.16.5.2 Akceptováno s výhradami
4.16.5.3 Neakceptováno
V případě, že budou v průběhu akceptačního řízení v předaném plnění zjištěny takové vady a nedodělky, které by bránily v užití díla či jeho části, není předané plnění akceptováno. Obě strany se dohodnou na termínech nového předání a nového akceptačního řízení. Do akceptačního protokolu Zadavatel uvede, že předané plnění nebylo akceptováno, dohodnuté termíny nového předání a akceptačního řízení a obě strany akceptační protokol potvrdí svým podpisem; výše sankce za prodlení s plněním se přitom počítá od původního smluvního termínu plnění (případná nesoučinnost Zadavatele se do doby prodlení Dodavatele nezapočítává).
Doplatek na výhrady z akceptačního řízení
Pokud je akceptační řízení ukončeno s výsledkem „Akceptováno s výhradami“, bude pro každou jednotlivou výhradu stanoveno zádržné jako část z ceny daného plnění (výstup, činnost), které bude vázáno na vyřešení dané výhrady z akceptace dle odsouhlasených postupů a termínů (dále jen „Dílčí Doplatek“); přitom platí, že:
4.16.6.1 všechny výhrady z akceptace nemusí být odstraněny v jednom společném termínu;
4.16.6.2 při stanovení výše Dílčího Doplatku se vychází zejména z ceny/pracnosti daného dílčího výstupu nebo činnosti Dodavatele a vlivu na další užití dané části plnění, případně na celé plnění;
4.16.6.3 součet všech Dílčích Doplatků tvoří Celkový Doplatek.
Postup fakturace při výhradách z akceptačního řízení
4.16.7.1 Dodavatel je v případě akceptace s výhradami oprávněn po podpisu akceptačního protokolu fakturovat částku ve výši ceny dílčího plnění poníženou o Celkový Doplatek, případně i o slevy z plnění, jsou-li splněny podmínky pro jejich uplatnění (např. chybovost, prodlení Dodavatele,…).
4.16.7.2 V případě vyřešení všech výhrad z akceptace v jednom společném termínu je po podpisu protokolu o vyřešení všech výhrad z akceptace Dodavatel oprávněn fakturovat částku Celkového Doplatku, poníženou o 10% z celkové výše Celkového Doplatku, a to za každý i započatý měsíc od data, ke kterému mělo být akceptační řízení ukončeno, tedy 15 pracovních dnů po zahájení akceptačního řízení. Měsícem se přitom rozumí 30 kalendářních dní. Minimální snížení Celkového Doplatku přitom činí 10% výše Celkového Doplatku.
4.16.7.3 Pokud jsou výhrady z akceptace vyřešeny ve více krocích s různými termíny pro jejich odstranění, bude Celkový Doplatek fakturován po Dílčích Doplatcích odpovídajících vyřešené části výhrad z akceptace v daném kroku na základě podpisu protokolu o vyřešení výhrad z akceptace příslušných danému kroku; postup dle bodu 4.16.7.2 se použije pro každý Dílčí Doplatek samostatně.
Na předmět plnění dle této VZ Zadavatel požaduje poskytnutí záruky. Zadavatel požaduje, aby záruční doba, ve které bude Dodavatel odstraňovat vady plnění bezplatně, měla délku 24 měsíců od finální akceptace a dále pak vždy od akceptace konkrétního plnění, zároveň však nejdéle do konce smlouvy.
Další požadavky Zadavatele v oblasti záruky jsou uvedeny v Příloze ZD09. Přitom Zadavatel požaduje, aby Dodavatel opravy IS DMVS řešené v rámci záruky předával Zadavateli průběžně a pokud možno rovnoměrně v jednotlivých verzích IS DMVS tak, aby v poslední předávané verzi IS DMVS (dále též
„poslední dodávka“) byly dořešeny všechny záruční vady spadající do záruky, které byly Dodavateli nahlášeny do doby zahájení funkčních testů poslední dodávky dle této VZ. Při nesplnění této podmínky požaduje Zadavatel uplatnění slevy z plnění, resp. smluvní pokuty, v případě, že již nebude následovat další fakturace, a to ve výši 20.000,- Kč (bez DPH) za každou jednotlivou neopravenou záruční vadu.
Požadavky spadající do záruky nahlášené Dodavateli i po termínu zahájení funkčních testů poslední dodávky budou řešeny dle podmínek uvedených v Příloze ZD09.
Pokud se Účastník ZŘ rozhodne v IS využít nekomerční/Open Source SW, vztahuje se záruka i na něj.
Na změny ve zdrojovém kódu provedené Zhotovitelem nebo použitou novou verzí daného SW je z hlediska záruky pohlíženo stejně jako na změnu IS DMVS.
Účastník ZŘ není oprávněn použít takový nekomerční/Open Source SW, jehož začleněním do IS DMVS by tento ztratil svůj proprietární charakter (tj. jestliže by podle licenčních podmínek takového nekomerčního/Open Source SW jeho začleněním do IS DMVS došlo k povinnosti zpřístupnit IS DMVS pod tzv. svobodnou licenci/licencí copyleft).
Obstarání TI (HW), SW nebo služeb
Definice
Službami se rozumí služby třetích stran, nikoliv služby poskytované Dodavatelem v rámci plnění této VZ.
Technickými podmínkami se rozumí nejen vlastní technické podmínky pro konkrétní zařízení, ale též komplexní soubor požadavků (tedy jak technických, tak i např. též kvalifikačních požadavků apod.), kterým musí dodávaná TI vyhovět, a které budou vyhovovat pro použití (specifikace) v ZŘ podle ZZVZ. Jejich použití Zadavatelem pro VZ není závazné.
Požadavky Zadavatele
Nabídka účastníka ZŘ nesmí obsahovat požadavek na to, aby Zadavatel obstaral SW vyžadující platbu za licence nebo support, TI nebo služeb, s výjimkou těch, které jsou uvedeny v ZD.
V případě, že Zadavatel bude pořizovat TI, SW nebo služby, které mají nebo mohou mít dopad na IS DMVS, Zadavatel požaduje, aby se Dodavatel zavázal k vypracování závazných technických podmínek, které budou podléhat akceptačnímu řízení.
V případě, že požadavky na TI bude dotčena i síť WAN, požaduje Zadavatel, aby Dodavatel respektoval obecný rámec podmínek pro síť KIVS, daný veřejnými zakázkami řízenými MVČR.
Budou-li při obstarání TI dodrženy akceptované technické podmínky, bude povinností Dodavatele zakomponovat je do funkčního celku IS DMVS a Dodavatel bude ručit i za jejich kompatibilitu a dostatečnou výkonnost pro potřeby IS DMVS.
Zadavatel požaduje, aby Dodavatel v rámci plnění VZ u všech činností na objednávku předkládal Zadavateli v termínech dle harmonogramu daného plnění k odsouhlasení návrhy pracnosti jednotlivých činností požadovaných Zadavatelem. Návrh pracnosti může být po dohodě se Zadavatelem variantní.
Práce Dodavatele na analýze, jejíž pracnost nebyla Zadavatelem odsouhlasena, nebude Zadavatelem uhrazena.
Pokud nebude dohodnuto jinak, tak pro činnosti přesahující pracnost 10 ČLD Dodavatel dále doloží detailní rozpad pracnosti, přičemž součet položek detailního rozpadu pracnosti musí dávat celkovou pracnost. Rozpad pracnosti musí zahrnovat minimálně:
- design,
- programátorské činnosti členěné po modulech/ komponentách, v případně většího počtu shodných úprav seskupené do skupin typu reporty apod.,
- testování vývojářem (Unit testy apod.),
- testování Dodavatelem,
- napojení na systémy třetích stran pro účely integrace/testování,
- vyhotovení FAKE komponent, a to pouze v případě, že pro danou oblast není k dispozici testovací prostředí/aplikace,
- tvorbu veškeré dokumentace pro následné předání Zadavateli,
- činnosti spojené s instalací řešení do provozu,
- stanovení monitoringu – vytvoření nových sledovaných metrik a jejich integraci do rozhraní pro monitorování Zadavatelem, včetně jejich zdokumentování a předání Zadavateli dle bodu 4.6,
- položkově ostatní činnosti s pracností přesahující 2 ČLD.
Zadavatel požaduje, aby Účastník ZŘ jako součást své nabídky provedl analýzu, design, návrh a implementaci modelového požadavku, jehož zadání je uvedeno v Příloze ZD07.
Zadavatel požaduje, aby Dodavatel zajistil online dostupné zabezpečené úložiště pro vzájemnou výměnu dat se Zadavatelem. Úložiště bude sloužit např. pro objemnější data, která nelze přenést e-mailem (předávání dodávek IS DMVS, různé logy a výstupy apod.).
Zadavatel požaduje plné zprovoznění zabezpečeného úložiště nejpozději do 2 měsíců od začátku účinnosti smlouvy.
Zadavatel požaduje, aby Účastník ZŘ v příloze smlouvy popsal metodiku řízení projektu, jejíž součástí bude i popis organizace práce vývojového týmu, a která bude minimálně obsahovat popisy následujících částí:
- metodika řízení projektu,
- zodpovědnosti jednotlivých členů týmu,
- způsob plánování přírůstků a oprav,
- přidělování úkolů členům týmu a revize jejich plnění (code review, testování),
- způsoby testování aplikace a protokoly s výsledky testů,
- tvorba časových plánů pro dodání verzí.
Zadavatel požaduje, aby metodika řízení projektu obsahovala minimálně tyto projektové orgány a role:
Orgány řízení projektu
4.23.1.1 Řídící výbor (ŘV)
ŘV je společný orgán Zadavatele a Dodavatele a je vrcholným rozhodovacím orgánem projektu s primární úlohou udávat směr a zajišťovat rozhodování o projektu. Jedná se o nejvyšší orgán projektu, který akceptuje projektové výstupy, schvaluje změny, kontroluje a sleduje průběh projektu. ŘV zejména zajišťuje:
- vytváření podmínek pro úspěšnou realizaci projektu,
- kontrolu a sledování průběhu projektu,
- návrhy koordinace projektu s externími organizacemi a orgány,
- vyjadřování svého stanoviska k akceptaci výsledků jednotlivých etap projektu na základě výsledků akceptačního řízení
4.23.1.2 Výkonný výbor (VV)
VV projektu je společný orgán Zadavatele a Dodavatele a je přímo podřízený ŘV. Zastřešuje projekt po věcné stránce, zajišťuje chod projektu (řízení, plánování, úkolování, kontrolu) a využívá alokované zdroje pro projekt tak, aby byly naplněny výstupy projektu v daném rozsahu, čase a kvalitě. VV zejména zajišťuje:
- podrobné řízení a kontrolu průběhu projektu,
- operativní řešení problémů, které nevyžadují rozhodnutí ŘV,
- podrobnou specifikaci jednotlivých etap projektu a navrhování z toho vyplývajících upřesnění,
- schválení detailního průběhu akceptačního řízení,
- rozhodování o vytvoření smíšených pracovních týmů.
Organizátory VV jsou Vedoucí projektu Zadavatele a vedoucí projektu Dodavatele. Členy VV jsou především vedoucí všech týmů, které jsou v daném čase zřízeny.
4.23.1.3 Výbor při řízení kybernetické bezpečnosti (VKB)
VKB především zajišťuje:
- koordinaci plánování opatření k zajištění kybernetické bezpečnosti,
- spolupráci a projednání záměrů plánovaných koncepčních materiálů z oblasti kybernetické bezpečnosti,
- posouzení a projednávání dopadů plánovaných změn projektu k zajištění kybernetické bezpečnosti.
Role v projektu, kompetence
4.23.2.1 Vedoucí projektu Dodavatele
Hlavní pravomoci a odpovědnosti:
- připravuje a odpovídá za dodržování termínů dle schváleného harmonogramu u činností prováděných Dodavatelem,
- odpovídá za poskytování součinnosti Dodavatele
- detailně plánuje, koordinuje a kontroluje všechny aktivity projektu na své úrovni řízení
- navrhuje požadavky na změny,
- kontroluje vedení projektové dokumentace dle schválených projektových vzorů a dohlíží na dodržování projektových postupů,
- připravuje podklady pro ŘV,
- účastní se ŘV,
- připravuje podklady a účastní se VV.
4.23.2.2 Vedoucí projektu Zadavatele
Hlavní pravomoci a odpovědnosti:
- kontroluje a zodpovídá za průběh projektu v rámci schválených cílů a rozsahu projektu na straně Zadavatele,
- odpovídá za poskytování součinnosti Zadavatele,
- kontroluje a odpovídá za dodržování termínů dle Smlouvy a za schválení a dodržování rozhodujících termínů
- sleduje dodržování dohodnuté kvality projektu,
- detailní plánování a koordinace s dalšími projekty na straně Zadavatele,
- kontrola vedení projektové dokumentace dle schválených projektových vzorů
Pro větší názornost Zadavatel požaduje, aby text dokumentu byl doplněn grafickými schématy procesů (procesními diagramy) v notaci BPMN.
Zadavatel požaduje, aby Xxxxxxxxx plánoval a zajistil jakost a kvalitu IS DMVS. Plánování zajištění jakosti a kvality projektu IS DMVS je chápáno jako ucelený proces zajištění jakosti v rámci celého životního cyklu IS DMVS, který zajišťuje, že jakost bude zahrnuta do všech etap a procesů realizace projektu IS DMVS včetně řízení a kontroly projektu.
Systém jakosti a kvality je souhrnem postupů, činností, prostředků a organizačních opatření zaměřených na dosažení jakosti vytvářeného díla, tj. na dosažení definovaných požadavků Zadavatele a cílů projektu IS DMVS. Pojmem jakosti díla se rozumí nejen jakost výsledného díla, ale i jakost procesu, v jehož rámci dílo vzniká. Zajištěním jakosti a kvality je např. i provádění kontroly kvality kódu, zajištění jednotnosti používání termínů a pojmů, zajištění jednotnosti projektových dokumentů, plnění stanovených cílů atd.
Zadavatel požaduje:
- vytvořit dokumentaci k projektu IS DMVS tak, aby umožnila kontinuální sledování jakosti jak vývojového procesu, tak výstupů etap projektu IS DMVS,
- zavést kontrolní mechanismus, který zajistí, že nedostatky v jakosti projektu IS DMVS budou kontinuálně zjišťovány (identifikovány) a následně transformovány do nápravných opatření (eliminovány),
- neustále zdokonalovat procesy řízení kvality, aby byly efektivní a účinné,
- použít takové metodiky a metody řízení projektu a návrhu IS DMVS, které zajistí správné provádění jednotlivých činností a zabezpečení jakosti projektu IS DMVS, a které umožní kontinuální zdokonalování projektových procesů,
- dosáhnout ověřitelnosti všech výstupů projektu IS DMVS vůči akceptačním kritériím,
- zajistit, že požadavky na jakost díla se budou plnit.
Zadavatel požaduje, aby Účastník ZŘ v příloze smlouvy popsal, jak zajistí jakost a kvalitu projektu.
Doba a místo plnění veřejné zakázky
Zadavatel požaduje, aby došlo k ukončení akceptačního řízení aktivity „Finální akceptace a předání IS DMVS do rutinního provozu“ nejpozději k 30. 6. 2023 (termín vyplývající ze spolufinancování projektu z fondů EU). Následovat pak bude 30 měsíců rutinního provozu, kdy bude Dodavatel poskytovat PÚ a základní rozvoj IS DMVS.
Místem plnění veřejné zakázky je především sídlo Zadavatele.
Místem plnění veřejné zakázky je i housingové centrum T-Mobile v Praze, kde je umístěna část technického zařízení Zadavatele. Dojde-li ke změně housingového centra, musí tuto změnu Dodavatel respektovat.
Místem plnění veřejné zakázky mohou být výjimečně také sídla krajských úřadů v celé ČR, pokud si to vyžádá situace.
Zadavatel tímto stanovuje požadavky na prokázání základní způsobilosti podle § 74 a násl. ZZVZ, profesní způsobilosti podle § 77 ZZVZ a technické kvalifikace podle § 79 a násl. ZZVZ.
Způsobilým není podle § 74 odst. 1 ZZVZ Účastník ZŘ, který | Způsob prokázání |
a) byl v zemi svého sídla v posledních 5 letech před zahájením ZŘ pravomocně odsouzen pro trestný čin uvedený v příloze č. 3 k tomuto zákonu nebo obdobný trestný čin podle právního řádu země sídla dodavatele; k zahlazeným odsouzením se nepřihlíží, | Výpis z evidence Rejstříku trestů |
b) má v České republice nebo v zemi svého sídla v evidenci daní zachycen splatný daňový nedoplatek, | Potvrzení příslušného finančního úřadu a písemné čestné prohlášení ve vztahu ke spotřební dani |
c) má v České republice nebo v zemi svého sídla splatný nedoplatek na pojistném nebo na penále na veřejné zdravotní pojištění, | Písemné čestné prohlášení |
d) má v České republice nebo v zemi svého sídla splatný nedoplatek na pojistném nebo na penále na sociální zabezpečení a příspěvku na státní politiku zaměstnanosti, | Potvrzení příslušné okresní správy sociálního zabezpečení |
e) je v likvidaci, proti němuž bylo vydáno rozhodnutí o úpadku, vůči němuž byla nařízena nucená správa podle jiného právního předpisu nebo v obdobné situaci podle právního řádu země sídla dodavatele. | Výpis z obchodního rejstříku nebo písemné čestné prohlášení v případě, že není v obchodním rejstříku zapsán |
Tabulka 2 - základní způsobilost
Je-li dodavatelem právnická osoba, musí podmínku podle § 74 odst. 1 písm. a) ZZVZ splňovat tato právnická osoba a zároveň každý člen statutárního orgánu. Je-li členem statutárního orgánu dodavatele právnická osoba, musí podmínku podle § 74 odst. 1 písm. a) ZZVZ splňovat:
a) tato právnická osoba,
b) každý člen statutárního orgánu této právnické osoby a
c) osoba zastupující tuto právnickou osobu v statutárním orgánu dodavatele. Účastní-li se ZŘ pobočka závodu:
a) zahraniční právnické osoby, musí podmínku podle § 74 odst. 1 písm. a) ZZVZ splňovat tato
právnická osoba a vedoucí pobočky závodu,
b) české právnické osoby, musí podmínku podle § 74 odst. 1 písm. a) ZZVZ splňovat osoby uvedené v odstavci 2 a vedoucí pobočky závodu.
Podle § 226 a násl. ZZVZ je možno splnění základní způsobilosti prokázat předložením výpisu ze seznamu kvalifikovaných dodavatelů. Ve smyslu § 228 ZZVZ nesmí být výpis ze seznamu starší než 3 měsíce.
Profesní způsobilosti podle § 77 ZZVZ prokáže Účastník ZŘ, který ve vztahu k České republice předloží výpis z obchodního rejstříku nebo jiné obdobné evidence, pokud jiný právní předpis zápis do takové evidence vyžaduje.
Podle § 226 a násl. ZZVZ je možno splnění profesní způsobilosti prokázat předložením výpisu ze seznamu kvalifikovaných dodavatelů v tom rozsahu, v jakém údaje ve výpisu ze seznamu kvalifikovaných dodavatelů prokazují splnění kritérií profesní způsobilosti. Ve smyslu § 228 ZZVZ nesmí být výpis ze seznamu starší než 3 měsíce k poslednímu dni, ke kterému má být požadovaná kvalifikace prokázána.
K prokázání kritérií technické kvalifikace Zadavatel požaduje předložení:
Podle § 79 odst. 2 písm. b) ZZVZ
Seznam významných dodávek nebo významných služeb poskytnutých za poslední 3 roky před zahájením ZŘ včetně uvedení pro každou dodávku/službu:
- ceny v Kč bez DPH,
- doby jejich poskytnutí – datum začátku a konce plnění,
- identifikace objednatele,
- kontaktů na ověření reference,
- popisu, v jaké roli se na naplnění podílel (zda jako hlavní dodavatel nebo poddodavatel),
- popisu částí a činností, které při plnění zajišťoval (bez poddodavatelů),
- v případě hlavního dodavatele detailní rozpad na všechny poddodavatele s určením jednotlivých částí a % jejich velikosti (součet musí být 100 %, včetně částí hlavního dodavatele).
Z předloženého seznamu musí jednoznačně a doložitelně vyplývat, že Účastník ZŘ v uvedeném období realizoval nejméně tři referenční služby v oblasti ICT, přičemž:
1) referenční službou v oblasti ICT se rozumí kompletní dodání informačního systému, tj. návrh, vývoj, dodávka a nasazení informačního systému (případně jeho údržba a další rozvoj v případě přímé návaznosti na tyto činnosti) a dodávka služeb ICT s tím souvisejících,
2) se vždy musí jednat o samostatný informační systém, nikoli o spojení několika menších systémů jednoho objednatele, byť všech realizovaných Účastníkem ZŘ,
3) hodnota každé referenční služby musí být alespoň 25 mil. Kč bez DPH (do hodnoty referenční služby se nezapočítává cena případně dodávaného hardware a cena licencí třetích stran),
4) hodnota minimálně jedné referenční služby musí být alespoň 35 mil. Kč bez DPH (do hodnoty referenční služby se nezapočítává cena případně dodávaného hardware a cena licencí třetích stran),
5) minimálně jedna referenční služba se musí týkat IT systému napojeného na základní registry,
6) minimálně jedna referenční služba se musí týkat IT systému s minimálně 500 současně pracujícími uživateli a musí se týkat IT systému obsahujícího zpracování jak popisných, tak s nimi provázaných grafických/prostorových dat, a musí splňovat tyto požadavky a funkčnosti:
- zaobjektovaná prostorová data s využitím standardních spatial funkčností Oracle (SDO_GEOM), Bentley, Esri, Hexagon a obdobných, případně open source knihoven,
- implementované kontroly topologie,
- publikace na internetu pro 500 současně pracujících uživatelů,
- vizualizace a editace různých typů geometrie (polygon, linie, bod atd.).
Doba uvedená výše se považuje za splněnou, pokud byla dodávka/služba uvedená v příslušném seznamu v průběhu této doby dokončena; to neplatí u zakázek pravidelné povahy, u nichž se pro účely prokázání technické kvalifikace považuje za rozhodný rozsah zakázky realizovaný v průběhu požadované doby.
Účastník ZŘ může k prokázání splnění tohoto kritéria kvalifikace použít dodávky, služby nebo stavební práce, které poskytl:
a) společně s jinými dodavateli, a to v rozsahu, v jakém se na plnění zakázky podílel, nebo
b) jako poddodavatel, a to v rozsahu, v jakém se na plnění dodávky, služby nebo stavební práce podílel.
Podle § 79 odst. 2 písm. c) a písm. d) ZZVZ
Jmenný seznam odborníků, kteří se budou v týmu Účastníka ZŘ podílet na plnění veřejné zakázky, bez ohledu na to, zda jde o zaměstnance Účastníka ZŘ nebo osoby v jiném vztahu k Účastníkovi ZŘ.
Zadavatel požaduje, aby se tým skládal alespoň z osob zastávajících níže uvedené role.
6.3.2.1 Podrobnosti k prokázání kvalifikace
Přílohou seznamu členů týmu budou jejich profesní životopisy, které budou pro každého člena obsahovat alespoň následující údaje:
1. jméno a příjmení,
2. jméno role a podrobný popis funkce a činností na plnění VZ,
3. údaj o zaměstnavateli, popř. IČO,
4. reference na projekty relevantní k plnění této VZ včetně rolí a doby působení na referenčních projektech,
5. přehled další profesní praxe vztahující se k předmětu plnění VZ,
6. přehled získaného vzdělání (včetně odborného), osvědčení a certifikací (jsou-li vyžadovány). Přílohou životopisu pak budou příslušná osvědčení a certifikace (jsou-li vyžadovány).
Role mohou být navzájem mezi sebou kumulované v jedné osobě, jedna osoba může zastávat maximálně dvě role.
Všechny požadované certifikace musí být platné k datu podání Nabídky a Účastník ZŘ se zavazuje je udržovat po celou dobu trvání VZ.
Dodavatel deklaruje, že osoby, jejichž odbornou kvalifikací bylo prokázáno v nabídce Dodavatele na plnění veřejné zakázky splnění kvalifikačních předpokladů, budou skutečně zapojeny v dostatečném rozsahu dle povahy aktuálně poskytovaného plnění v uvedených rolích do plnění předmětu smlouvy.
Dodavatel je na vyžádání povinen kdykoliv skutečné zapojení těchto osob prokazatelně doložit. Po dobu, kdy Xxxxxxxxx neplní tento závazek a není schopen prokázat skutečné zapojení těchto osob při poskytovaném plnění, je povinen poskytnout Zadavateli slevu z ceny ve výši 5 000,- Kč, a to za každý započatý pracovní den/osobu, u které nebude schopen její zapojení prokázat.
Zadavatel požaduje, aby obsazení pozic dle bodů 6.3.2.2, 6.3.2.3, 6.3.2.4 a 6.3.2.6 bylo zajištěno a plněno s ohledem na svoji stěžejnost pro řádné plnění VZ přímo Dodavatelem. Tato část kvalifikace tak nemůže být prokázána prostřednictvím poddodavatele.
U požadavků na konkrétní stupeň certifikace jsou povoleny i stupně vyšší. Uvedené platí i na bod 12.2.3.
Seznam rolí a minimálních požadavků:
6.3.2.2 Projektový manažer (minimálně 1 osoba)
- zkušenost minimálně se dvěma úspěšně dokončenými projekty zaměřenými na vývoj SW, které byly řízeny projektovou metodikou PRINCE2, IPMA, PMI nebo obdobné,
- praxe na pozici projektového manažera minimálně 5 let,
- minimálně 3 účasti na projektech obdobného rozsahu (koordinace projektového týmu o min. velikosti 10 osob a s rozpočtem projektu vyšším než 25 mil. Kč bez DPH) na pozici projektového manažera.
6.3.2.3 Hlavní architekt (minimálně 1 osoba)
- praxe v roli architekta IS minimálně 5 let,
- architektonický návrh minimálně dvou projektů využívajících enterprise architektury EMS, SOA nebo distribuovaných systémů,
- minimálně 3 účasti na projektech obdobného rozsahu (s rozpočtem projektu vyšším než 25 mil. Kč bez DPH) na pozici hlavní architekt,
- zkušenost s tvorbou architektur informačních systémů s minimálně 500 současně pracujícími uživateli s dostupností (SLA) vyšší než 99 %.
6.3.2.4 Hlavní analytik informačních systémů (minimálně 1 osoba)
- tvorba analýzy pro minimálně dva projekty, u kterých:
o byla prováděna analýza za pomocí jazyka UML 2.0,
o byla využívána enterprise architektura EMS, SOA nebo distribuované systémy,
o probíhala integrace na jiné IS,
- praxe v roli analytika IS minimálně 5 let,
- zkušenost s vedením týmu analytiků minimálně dvou rozsáhlých IS s rozpočtem projektu vyšším než 25 mil. Kč bez DPH.
6.3.2.5 Specialista kybernetické bezpečnosti (minimálně 1 osoba4)
- splnění podmínek stanovených v odst. 1 a odst. 2 § 7 VoKB,
- minimálně na dvou projektech zastávání role manažera nebo architekta kybernetické bezpečnosti dle VoKB,
4 Pokud bude role Manažer kybernetické bezpečnosti a Architekt kybernetické bezpečnosti dle bodu 4.1.5.2 zastávat více jak jedna osoba, požadavky uvedené v tomto bodě platí pro každou z těchto osob.
- zkušenosti s tvorbou analýz rizik a analýz zranitelností informačních a komunikačních systémů a metodik tvorby bezpečnostních analýz a návrhů procesních opatření,
- zkušenosti s návrhem opatření v oblasti kybernetické bezpečnosti,
- zkušenost s návrhem fyzické bezpečnosti informačního systému,
- zkušenost s tvorbou plánů obnovy informačního systému v případě havárie,
- jednu z následujících certifikací:
o Certified Information Security Manager (CISM),
o Certified in Risk and Information Systems Control (CRISC),
o Certified Information Systems Security Professional (CISSP),
o Manažer BI (akreditační schéma ČIA).
U osoby, zastávající roli Architekt kybernetické bezpečnosti se v případě, že současně nezastává roli Manažer kybernetické bezpečnosti, rozšiřuje seznam možných certifikací o následující:
o Certified Ethical Hacker (CEH),
o CompTIA Security +.
6.3.2.6 Systémový architekt (minimálně 1 osoba)
- minimálně 3 praktické zkušenosti v roli Systémového architekta infrastruktury nebo obdobné roli v oblasti návrhů a realizace IS s rozpočtem projektu vyšším než 25 mil. Kč,
- zkušenost v roli Systémového architekta s tvorbou architektur IS s dostupností (SLA) vyšší než 99%
- zkušenost v roli Systémového architekta IS využívajících technologií a architektur SOAP, EMS, SOA, microservices, kontejnerizace,
- jednu z následujících certifikací:
o Open Group Certified Architect Level 15,
o TOGAF 9 Foundation (Level 1)6.
6.3.2.7 Databázový administrátor (minimálně 1 osoba)
- praxe s administrací RDBMS minimálně 5 let,
- zkušenost s administrací rozsáhlých databází provozovaných on-premise na vícenodovém clusteru a s minimálně 500 současně pracujícími uživateli,
- profesní certifikace pro použitý databázový systém.
6.3.2.8 Vývojoví pracovníci (minimálně 4 osoby):
- praxe s vývojem IS využívajících relační databáze a znalost SQL jazyka,
- praxe v pozici vývojáře minimálně 5 let.
6.3.2.9 Vedoucí pracovník kontroly kvality (minimálně 1 osoba):
- praxe v oboru QA minimálně 5 let,
- minimálně 2 účasti na projektech s rozpočtem projektu vyšším než 20 mil. Kč bez DPH a více jak 500 aktivními uživateli na pozici vedoucího QA.
5 xxxxx://xxx.xxxxxxxxx.xxx/xxxxxx/xxxx/xxxx/xxxxxxxxx.xxx
6 xxxx://xxx.xxxxxxxxx.xxx/xxxxx0/xxxx/xxxx/xxxxx0_xxxx_xxxxxxx.xxx
Doklady o kvalifikaci, změna kvalifikace
Za účelem prokázání kvalifikace Zadavatel přednostně vyžaduje doklady evidované v systému e-Certis, který identifikuje doklady k prokázání splnění kvalifikace.
Zadavatel stanoví, že Účastník ZŘ nemůže v nabídce nahradit předložení dokladů čestným prohlášením. Účastník ZŘ může nahradit požadované doklady jednotným evropským osvědčením pro veřejné zakázky.
Před uzavřením smlouvy si Zadavatel od vybraného Účastníka ZŘ vyžádá předložení originálů nebo ověřených kopií dokladů o kvalifikaci, pokud již nebyly v ZŘ předloženy.
Doklady prokazující základní způsobilost podle § 74 ZZVZ a profesní způsobilost podle § 77 odst. 1 ZZVZ musí prokazovat splnění požadovaného kritéria způsobilosti nejpozději v době 3 měsíců přede dnem zahájení ZŘ.
Pokud po předložení dokladů nebo prohlášení o kvalifikaci dojde v průběhu ZŘ ke změně kvalifikace Účastníka ZŘ, je Účastník ZŘ povinen tuto změnu Zadavateli do 5 pracovních dnů oznámit a do 10 pracovních dnů od oznámení této změny předložit nové doklady nebo prohlášení ke kvalifikaci; Zadavatel může tyto lhůty prodloužit nebo prominout jejich zmeškání. Povinnost podle předchozí věty Účastníku ZŘ nevzniká, pokud je kvalifikace změněna takovým způsobem, že:
a) podmínky kvalifikace jsou nadále splněny,
b) nedošlo k ovlivnění kritérií pro snížení počtu účastníků ZŘ nebo nabídek a
c) nedošlo k ovlivnění kritérií hodnocení nabídek.
Dozví-li se Zadavatel, že Účastník ZŘ nesplnil povinnost uvedenou v odstavci 1 ZZVZ, Zadavatel jej bezodkladně vyloučí ze ZŘ.
Prokazování splnění kvalifikace při společném podání nabídky
V případě podání společné účasti Účastníků ZŘ prokazuje základní způsobilost a profesní způsobilost podle § 77 odst. 1 ZZVZ každý z nich samostatně.
V případě, že má být předmět VZ plněn společně několika Účastníky ZŘ, jsou Zadavateli povinni předložit současně s doklady prokazujícími splnění kvalifikačních předpokladů písemný závazek, že všichni tito Účastníci ZŘ budou vůči Zadavateli a třetím osobám z jakýchkoliv právních vztahů vzniklých v souvislosti s VZ zavázáni společně a nerozdílně, a to po celou dobu plnění VZ a také po dobu trvání jiných závazků vyplývajících z VZ.
Prokázání kvalifikace prostřednictvím poddodavatele
Účastník ZŘ může podle § 83 ZZVZ prokázat určitou část ekonomické kvalifikace, technické kvalifikace nebo profesní způsobilosti s výjimkou kritéria podle § 77 odst. 1 ZZVZ požadované Zadavatelem prostřednictvím jiných osob (s výjimkou obsazení výše vyjmenovaných pozic, kde je využití poddodavatele vyloučeno). Účastník ZŘ je v takovém případě povinen Zadavateli předložit:
a) doklady prokazující splnění profesní způsobilosti podle § 77 odst. 1 ZZVZ jinou osobou,
b) doklady prokazující splnění chybějící části kvalifikace prostřednictvím jiné osoby,
c) doklady o splnění základní způsobilosti podle § 74 ZZVZ jinou osobou a
d) písemný závazek jiné osoby k poskytnutí plnění určeného k plnění veřejné zakázky nebo k poskytnutí věcí nebo práv, s nimiž bude Účastník ZŘ oprávněn disponovat v rámci plnění veřejné zakázky, a to alespoň v rozsahu, v jakém jiná osoba prokázala kvalifikaci za Účastníka ZŘ.
Má se za to, že požadavek podle § 83 odst. 1 písm. d) ZZVZ je splněn, pokud obsahem písemného závazku jiné osoby je společná a nerozdílná odpovědnost této osoby za plnění veřejné zakázky společně s Účastníkem ZŘ. Prokazuje-li však Účastník ZŘ prostřednictvím jiné osoby kvalifikaci a předkládá doklady podle § 79 odst. 2 písm. a), b) nebo d) ZZVZ vztahující se k takové osobě, musí dokument podle
§ 83 odst. 1 písm. d) ZZVZ obsahovat závazek, že jiná osoba bude vykonávat stavební práce či služby, ke kterým se prokazované kritérium kvalifikace vztahuje.
Prokázání kvalifikace získané v zahraničí
V případě, že byla kvalifikace získána v zahraničí, prokazuje se doklady vydanými podle právního řádu země, ve které byla získána, a to v rozsahu požadovaném Zadavatelem.
Předpokládaná hodnota VZ je stanovena ve výši 96. 133. 595 Kč bez DPH.
Cena, požadavky na způsob zpracování nabídkové ceny
Nabídková cena za plnění dle VZ
Účastník ZŘ uvede v nabídce celkovou nabídkovou cenu za plnění dle VZ v členění dle tabulky „Tabulka 3
- nabídková cena“ (vyplňují se zeleně označené položky).
Celková nabídková cena nesmí být vyšší než předpokládaná hodnota VZ uvedená v bodě 7.
A | B | C | D | E |
Řádek | Skupina nebo odkaz na ZD | Cena za 1 ČLD/1měsíc v Kč bez DPH | Počet ČLD/měsíců | Nabídková cena v Kč bez DPH |
1 | Předmět plnění VZ dle bodu | Účastník ZŘ nevyplňuje | ------ | Kč |
2 | Činnosti na objednávku | Kč | 3000 ČLD | Kč |
3 | PÚ dle bodu 4.1.4.1 za 55 ČLD/měs. | Kč | 30 měsíců | Kč |
4 | Další činnosti související s předmětem plnění | Účastník ZŘ nevyplňuje | ------- | Kč |
5 | Celková nabídková cena | Kč |
Vysvětlivky k tabulce:
Tabulka 3 - nabídková cena
Řádek 1: uveďte ve sloupci E celkovou cenu plnění VZ pro bod uvedený ve sloupci B.
Řádek 2: uveďte ve sloupci C cenu za 1 ČLD a ve sloupci E celkovou cenu pro zadaný počet ČLD (sloupec D) při plnění činností na objednávku (součin sloupců C a D).
Řádek 3: uveďte ve sloupci C cenu za 1 měsíc poskytování PÚ, ve sloupci E uveďte celkovou cenu pro zadaný počet měsíců (sloupec D při provádění PÚ (součin sloupců C a D).
Řádek 4: pokud v rámci plnění VZ předpokládáte nezbytnost dalších činností, uveďte ve sloupci E jejich celkovou cenu.
Řádek 5: uveďte ve sloupci E bez variant celkovou, úplnou nabídkovou cenu za plnění celé veřejné zakázky.
Za mimořádně nízkou nabídkovou cenu dle § 28 odst. 1 písm. o) ZZVZ se ve sloupci C považuje cena nižší než 8500 Kč bez DPH za 1 ČLD/467 500 Kč bez DPH za 1 měsíc.
Požadavky na zpracování nabídky
Formální požadavky Zadavatele na zpracování nabídky
Nabídka musí být zpracována v českém jazyce. Listiny v jiném než českém jazyce budou doplněny úředním překladem do českého jazyka.
Povinnost připojit k dokladům úředně ověřený překlad do českého jazyka se nevztahuje na následující doklady:
- doklady ve slovenském jazyce,
- vysokoškolské diplomy v latinském jazyce,
- certifikáty k prokázání kvalifikace v anglickém jazyce.
Požadavek na český jazyk nabídky se nevztahuje také na odborné technické názvosloví, které může být uvedeno v anglickém jazyce.
Zadavatel nepřipouští varianty nabídky.
Zadavatel neposkytuje úhradu nákladů spojených s vypracováním nabídky. Zadavatel uvádí, že požaduje podání nabídek pouze v elektronické podobě.
Zadavatel uvádí následující podrobnější informace k podání nabídek v elektronické podobě:
- Pro podání nabídky v elektronické podobě bude použit Národní elektronický nástroj (dále jen
„NEN“), dostupný na internetové adrese: xxxxx://xxx.xxxxx.xx/, kde má Zadavatel svůj profil viz xxxxx://xxx.xxxxx.xx/xxxxxx/XXXX. Podrobné informace o elektronickém nástroji NEN jsou dostupné na internetové adrese xxxxx://xxx.xxxxx.xx/, zejména v sekci „Informace pro uživatele“ v podsekcích „Provozní řád“ a „Uživatelské příručky“.
- Zadavatel upozorňuje, že nabídku je při jejím podání nezbytné zašifrovat veřejným klíčem Zadavatele, který Účastníkům ZŘ poskytuje Zadavatel v elektronickém nástroji (NEN) spolu se ZD.
- Účastník ZŘ musí být pro možnost podání nabídky v nástroji registrován. Registrace není okamžitá a podléhá schválení provozovatele systému, který má 2 pracovní dny na akceptaci nebo zamítnutí registrace, pokud žádost o registraci nebude obsahovat veškeré požadované náležitosti.
- Zadavatel nenese odpovědnost za technické podmínky na straně Účastníka ZŘ. Zadavatel upozorňuje, že podání nabídky ve lhůtě pro podání nabídek je odpovědností Účastníka ZŘ. Zadavatel v této souvislosti upozorňuje, že elektronický nástroj (NEN) může postihnout výpadek funkčnosti, za který Zadavatel neodpovídá. Zadavatel proto doporučuje, aby nabídky byla podány v dostatečném časovém předstihu.
- Pokud je v této ZD uveden požadavek na podepsání konkrétních dokumentů, postačí předložení podepsaného dokumentu v naskenované formě, dokument tedy NEMUSÍ být opatřen elektronickým podpisem založeným na kvalifikovaném certifikátu dle zákona č. 397/2016 Sb., o službách vytvářejících důvěru pro elektronické transakce, ve znění pozdějších předpisů.
- Nabídka musí být až na části, které to vylučují (např. naskenované certifikace), podána ve strojově čitelné podobě.
- Zadavatel preferuje podání nabídky ve formátu PDF.
Nabídka musí být podána do 06. 10. 2020 do 10:00 hodin. Podáním nabídky se rozumí úspěšné dokončení odeslání nabídky v NEN, včetně nahrání veškerých příloh. Za rozhodný časový údaj se považuje čas uvedený v NEN.
Zadávací lhůta, tj. lhůta, po kterou jsou Účastníci ZŘ podle § 40 ZZVZ svými nabídkami vázáni, činí 8 měsíců a začíná běžet dnem následujícím po skončení lhůty pro podání nabídek.
Otevřením nabídky v elektronické podobě se rozumí zpřístupnění jejího obsahu Zadavateli. Nabídky v elektronické podobě se otevírají po uplynutí lhůty pro podání nabídek. Otevírání nabídek v elektronické podobě není veřejné.
Doporučená osnova pro zpracování nabídky
Doporučená osnova pro zpracování nabídky je uvedená v Příloze ZD16.
Komunikace v ZŘ probíhá především písemně v elektronické podobě, a dále zejména v souladu s § 211 odst. 3 ZZVZ.
Při komunikaci uskutečňované prostřednictvím datové schránky je dokument dle § 211 odst. 6 ZZVZ doručen dodáním do datové schránky adresáta.
Doručením prostřednictvím NEN je okamžik přijetí datové zprávy na elektronickou adresu adresáta či adresátů datové zprávy v NEN.
Podrobné informace o komunikaci pomocí NEN lze nalézt v dokumentech dostupných na internetové adrese xxxxx://xxx.xxxxx.xx/, zejména v sekci „Informace pro uživatele“ v podsekcích „Provozní řád“ a „Uživatelské příručky“.
Obchodní podmínky jsou upraveny v závazném návrhu smlouvy, která je Přílohou 17 této ZD. Znění návrhu smlouvy je pro Účastníka ZŘ závazné a tento je v něm oprávněn doplnit pouze ty údaje/části, které jsou k tomu určeny.
Hodnocení nabídek bude v souladu s § 114 ZZVZ provedeno podle jejich ekonomické výhodnosti, konkrétně pak na základě nejvýhodnějšího poměru nabídkové ceny a kvality podle následujících kritérií hodnocení při zohlednění jejich vah.
Všechny výpočetní operace v rámci hodnocení budou prováděny se zaokrouhlováním na 2 desetinná místa.
Kritérium | Popis | váha v % |
1 | Nabídková cena plnění dle smlouvy (řádek 5 sloupec E tabulky „Tabulka 3 - nabídková cena“) | 50 |
2 | Zpracování modelového požadavku | 15 |
3 | Kvalita, zkušenosti a odbornost realizačního týmu Účastníka ZŘ | 10 |
4 | Způsob a metodika vývoje, tvorba dokumentace projektu | 15 |
5 | Technická kvalita řešení | 10 |
Tabulka 4 - kritéria hodnocení
Popis způsobu hodnocení dle dílčích hodnotících kritérií
Kritérium č. 1: Nabídková cena plnění dle smlouvy
Při hodnocení nabídkové ceny plnění dle smlouvy bude hodnocena výše nabídkové ceny bez DPH (položka v řádku 5 v tabulce „Tabulka 3 - nabídková cena“ v bodě 8.1), přičemž nabídka s nejnižší nabídkovou cenou získá ohodnocení 100 bodů, ostatní nabídky získají bodové ohodnocení dle vzorce:
X=Ymin/Y*100, kde
- Y je hodnocená nabídková cena,
- Ymin je nejnižší podaná nabídková cena (ze všech hodnocených nabídek),
- X je dosažený počet bodů pro hodnocenou nabídku.
Kritérium č. 2: Zpracování modelového požadavku
V rámci tohoto hodnotícího kritéria Zadavatel požaduje navrhnout řešení zpracování modelového požadavku viz bod 4.21, Příloha ZD07.
U tohoto kritéria hodnocení budou u navrhovaného řešení modelového požadavku kladně hodnoceny zejména následující skutečnosti:
- vysoká celková úroveň pochopení problematiky a navrhovaného řešení vzhledem ke specifikaci v zadání,
- účelnost a efektivita navrhované architektury řešení pro Zadavatele, rozdělení do vhodných komponent a jejich vazeb,
- kvalita zdrojového kódu - vhodnost a přiměřenost rozsahu využívání doporučených postupů a návrhových principů,
- vysoká podrobnost, kvalita a vypovídající úroveň zpracování dokumentace – architektonická/analytická/design, programátorská, instalační
- účelný návrh publikovaného API s detailním popisem,
- podrobnost, správnost a vypovídací hodnota (přehlednost) zpracování jednotlivých výstupů aplikace a snadnost jejich pochopení uživatelem.
Nejvhodnější nabídce bude přiděleno 100 bodů. Ostatním nabídkám bude přidělen takový počet bodů, který bude vyjadřovat kvalitu zpracování hodnoceného požadavku ve vztahu k nejvhodnější nabídce.
Kritérium č. 3: Kvalita, zkušenosti a odbornost realizačního týmu Účastníka ZŘ
Hodnocení nabídek v rámci tohoto hodnotícího kritéria bude provedeno na základě následujícího postupu: Nejdříve bude sestaveno pořadí nabídek tak, že se sečtou body v tabulce „Tabulka 5 - pracovníci (rozšířená certifikace)“ uvedené ve sloupci „Body“ pro řádky, kde je ve sloupci „Splňuje“ uvedena hodnota „ano“
Následně bude nabídce s nejvyšším součtem přidělených bodů přiřazeno ohodnocení 100 bodů a každé následující nabídce bodové ohodnocení dle vzorce:
X=Y/Ymax*100, kde:
- Y je počet bodů hodnocené nabídky pro dané kritérium,
- Ymax je počet bodů nejlépe hodnocené nabídky pro dané kritérium,
- X je výsledný počet bodů pro hodnocenou nabídku pro dané kritérium.
Všechny předkládané certifikace musí být platné k datu podání Nabídky a Účastník ZŘ se zavazuje je udržovat v platnosti po celou dobu trvání VZ.
Řádek | Popis | Splňuje (ano/ne) | Body |
1 | Projektový manager dle bodu 6.3.2.2 má některou z následujících certitikací: - PRINCE2 Practitioner nebo PRINCE2 Agile, - PMI Project Management Professional (PMP) nebo Certified Associate in Project Management (CAPM). | 10 | |
2 | Hlavní architekt dle bodu 6.3.2.3 má certitikaci - ArchiMate 3 Foundation (Level 1) | 10 | |
3 | Hlavní analytik dle bodu 6.3.2.4 má certitikaci - OMG Certified UML Professional 2 (OCUP 2) | 10 | |
4 | Systémový architekt dle bodu 6.3.2.6 má některou z následujících certitikací: - Open Group Certified Architect (Open CA) Level 2, - TOGAF 9 Certified (Level 2). | 8 |
Tabulka 5 - pracovníci (rozšířená certifikace)
Vysvětlivky k tabulce „Tabulka 5 - pracovníci (rozšířená certifikace)“:
Pokud pracovník uváděný v rámci prokázání kvalifikace v bodu 6.3.2 splňuje vyšší certifikaci uvedenou ve sloupci „Popis“, tak ve sloupci „Splňuje“ Účastník ZŘ uvede hodnotu „ano“ a jako součást nabídky přiloží příslušné certifikace pracovníka.
Kritérium č. 4: Způsob a metodika vývoje, tvorba dokumentace projektu
(viz bod 4.9)
U tohoto kritéria hodnocení budou u navrhovaného způsobu a metodiky vývoje včetně popisu tvorby dokumentace kladně hodnoceny zejména následující skutečnosti:
- detailnější rozsah dokumentace a udržitelnost ke skutečnosti,
- zvolená struktura členění dokumentace umožňující lepší přehlednost,
- lepší UX při práci s dokumentací – jednotnost prostředí, integrace s modely UML, ArchiMate apod., způsob navigace a vyhledávání, provázanost jednotlivých částí dokumentace pomocí interaktivních odkazů, provázání s datovým modelem,
- větší rozsah, účelnost a efektivita kontrolních mechanizmů pro tvorbu dokumentace a její kvality a kontrolu kvality kódu,
- stanovení podrobných Coding Standards and Naming Conventions7 a jejich vynucování a kontrola,
- účinnější způsob a četnost provádění Code Review8 (kontrola konvencí, designu, best- practices, závislostí apod.),
- lepší způsob zajištění kvality projektu a kontrolních mechanismů.
Nejvhodnější nabídce bude přiděleno 100 bodů. Ostatním nabídkám bude přidělen takový počet bodů, který bude vyjadřovat kvalitu zpracování navrhovaného řešení ve vztahu k nejvhodnější nabídce.
Kritérium č. 5: Technická kvalita řešení
U tohoto kritéria hodnocení bude hodnocen technický návrh řešení. Kladně budou hodnoceny zejména následující skutečnosti:
- koncepce/architektura řešení bude detailnější a srozumitelněji popsaná, včetně popisu komponent a vzájemných vazeb,
- architektura bude snadno škálovatelná a bude rozdělena do částí tak, aby se jednotlivé části co nejméně ovlivňovaly a byly odděleny pomocí interního API,
- návrh řešení umožňující co nejvíce bezodstávkové instalace,
- větší nezávislost řešení umožňující snadnější převod komponent/částí systému na obdobnou technologii jiného subjektu a tím snižuje vendor lock-in na produktech nebo službách konkrétního subjektu.
Nejvhodnější nabídce bude přiděleno 100 bodů. Ostatním nabídkám bude přidělen takový počet bodů, který bude vyjadřovat kvalitu zpracování navrhovaného řešení ve vztahu k nejvhodnější nabídce.
Celkové hodnocení nabídek bude provedeno tak, že jednotlivá bodová hodnocení nabídek dle jednotlivých kritérií hodnocení budou vynásobena vždy vahou příslušného dílčího kritéria.
7 xxxx://xx.xxxxxxxxx.xxx/xxxx/Xxxxxx_xxxxxxxxxx_(xxxxxxxxxxx)
8 xxxx://xx.xxxxxxxxx.xxx/xxxx/Xxxx_xxxxxx
Takto získané hodnoty budou sečteny pro každou nabídku a pořadí úspěšnosti Účastníků ZŘ bude následně stanoveno tak, že nejúspěšnější nabídkou se stane nabídka, která dosáhla nejvyššího bodového ohodnocení, na dalších místech se postupně umístí nabídky ostatních Účastníků zadávacího řízení podle bodového hodnocení od nejvyššího po nejnižší.
V případě, že dvě a více nabídek dosáhne stejného výsledného bodového ohodnocení, bude o konečném pořadí těchto nabídek rozhodnuto losem. O takovémto případném losování bude pořízen záznam, který bude součástí dokumentace o veřejné zakázce. Při losování bude umožněna přítomnost dotčených Účastníků zadávacího řízení.
Vysvětlení zadávací dokumentace
Zadavatel poskytl v této ZD veškeré potřebné informace a požadavky na veřejnou zakázku, které měl k dispozici v době zpracování této ZD. V případě, že Zadavateli bude doručen požadavek Účastníka ZŘ na vysvětlení ZD podle § 98 ZZVZ, uveřejní Účastníkům ZŘ Zadavatel toto vysvětlení, případně související dokumenty, na svém profilu zadavatele, v souladu s ustanoveními § 98 ZZVZ.
Zadavatel si vyhrazuje právo:
- nevracet Účastníkům ZŘ nabídky,
- ověřit deklarované skutečnosti z nabídek před výběrem vítězného Účastníka ZŘ,
- neposkytovat náhradu nákladů, které Účastník ZŘ vynaloží na účast v ZŘ na tuto VZ.
Příloha ZD01 – Seznam použitých pojmů a zkratek Příloha ZD02 – Globální architektura IS DMVS
Příloha ZD03 – Návrh vyhlášky o digitální technické mapě kraje Příloha ZD04 – Popis rozhraní a technické parametry IS DMVS Příloha ZD05 – Závazný harmonogram plnění VZ
Příloha ZD06 – Popis stávajícího stavu TI
Příloha ZD07 – Zadání pro modelový požadavek + data Příloha ZD08 – Popis standardních uživatelských testů Příloha ZD09 – Podmínky záruky
Příloha ZD10 – Zajištění bezpečnostních testů
Příloha ZD11 – Seznam bezpečnostních dokumentů ČÚZK
Příloha ZD12 – Seznam bezpečnostních dokumentů IS DMVS Příloha ZD13 – Propojení CA SDM Zadavatele s HD Dodavatele Příloha ZD14 – Požadavky na popis systému
Příloha ZD15 – Práva a povinnosti manažera a architekta kybernetické bezpečnosti Příloha ZD16 – Doporučená osnova pro zpracování nabídky
Příloha ZD17 – Závazný návrh smlouvy
V souladu s § 36 odst. 4 ZZVZ Zadavatel uvádí, že Příloha ZD02 a ZD04 byla vypracována ve spolupráci se společností NESS Czech s.r.o., XXX: 45786259.
Xxx. Xxxxx Xxxxxxx místopředseda