Contract

2Předmět plnění

3Popis Telematického majetku TSK

4Věcné požadavky na Systém

5Kvalitativní požadavky na Systém

Seznam zkratek a pojmů

Contract

2.1První (1.) etapa: Analýza současného nastavení a úvodní návrh nového Systému

2.2Druhá (2.) etapa: Vývoj Systému

2.3Třetí (3.) etapa: Vytvoření prototypu Systému

2.4Čtvrtá (4.) etapa: Testování prototypu Systému

2.5Pátá (5.) etapa: Nasazení Systému do reálného provozu

2.6Poskytování Podpory Systému

3.1Telematické zařízení TSK

3.2Nástroje aktuálně využívané pro správu telematického majetku

4.1Vstupní data a jejich získání (pasportizace)

4.2Technické vlastnosti a architektura Systému

4.3Funkční vlastnosti Systému

4.4Požadavky na Podporu Systému

5.1Požadavky na provedení realizace Projektu

5.2Testování, akceptační postupy a akceptační kritéria

Document Metadata

Table of Contents

Document Metadata

2.1.1Definice projektu

2.1.2Implementační studie

2.6.1Komplexní podpora

2.6.2Rozšířená podpora

3.2.1Omezení vyplývající ze současného stavu

3.2.2Aplikace SRD

3.2.3Další nástroje a pomocné evidence

4.4.1Obecné podmínky poskytování služeb Komplexní podpory

4.4.2Úrovně Komplexní podpory

4.4.3Provozní deník

4.4.4Výkazy poskytnutých Služeb Komplexní podpory

4.4.5 Měření a vyhodnocování poskytnutých Služeb Komplexní podpory

4.4.6 Kalendáře poskytování Služeb Komplexní podpory

4.4.7 Struktura katalogového listu Služby Komplexní podpory

4.4.8Lhůty pro reakci a pro obnovení při řešení incidentů a požadavků

4.4.9Koncepty katalogových listů požadovaných Služeb Komplexní podpory

4.4.10Slevy a sankce

5.1.1Řízení realizace a řízení součinnosti s dotčenými stranami a koordinace se souběžnými projekty

5.1.2Požadavky na systém řízení realizace

5.1.3Požadavky na Dokumentaci

5.2.1 Nasazení a testování Systému

5.2.2Obecné principy akceptačního řízení

5.2.3Kategorie defektů a vad

5.2.4Metody akceptace příslušné různým typům plnění

5.2.1.1Způsob nasazení Systému

5.2.1.2Testování

5.2.1.3Prostředí pro testování

5.2.1.4Testovací nástroje, prostředky a pomůcky

5.2.1.5Odstraňování chyb během testování

Hlavní město Praha v současné době vlastní velké množství Telematického majetku určeného primárně k organizaci dopravy na městských komunikacích. Telematický majetek, který je ve vlastnictví hl. m. Prahy, je spravován prostřednictvím akciové společnosti TSK (Technická správa komunikací), která je zřízena hlavním městem a mezi její agendy patří, mimo jiné, provoz a správa telematických zařízení. TSK v současné době spravuje rozsáhlé portfolio HW a SW v oblasti telematiky. Jedná se např. o světelná signalizační zařízení (SSZ), kamerové systémy, senzory, optické kabely, automatické detektory, proměnné dopravní značení a další telematická zařízení, která jsou svým početním i druhovým rozsahem, celkovým uspořádáním a vzájemnými vazbami unikátní. K podpoře organizace a vyhodnocování dopravy má TSK implementovány informační systémy (SW), které poskytují rozličné funkcionality a zajišťují pracovníkům TSK požadované informace na základě dopravních / telematických dat. Současné nastavení správy Telematického majetku obsahuje velké množství omezení, kdy TSK nedisponuje nástrojem, který by komplexní a jednotnou správu celého Telematického majetku nabízel v požadovaných parametrech. Ambicí TSK je takový nástroj vytvořit.

Z tohoto důvodů bylo přistoupeno k realizaci inovačního partnerství, jehož cílem je nalezení inovativního řešení správy Telematického majetku v Praze. K tomuto účelu je nezbytné vyvinout centrální IT systém pro pasportizaci HW i SW a pro funkcionality správy telematických zařízení, kterými TSK disponuje. V rámci inovačního partnerství tak Zhotovitel vyvine Systém, který poskytne komplexní přehled o disponibilních zařízeních, jejich vlastnostech, provozní dokumentaci a smluvních parametrech spolupráce s jejich dodavateli. Systém by měl rovněž sloužit jako ucelený nástroj správy telematických zařízení TSK, umožňovat jednotnou evidencí záruk, servisních parametrů a životnosti zařízení a poskytovat podklady pro plánování údržby.

Nový Systém správy Telematického majetku TSK by tak měl umožňovat:

Sjednocení způsobu evidence Telematického majetku.
Zrychlení informovanosti TSK o aktuálním stavu spravovaného Telematického majetku.
Zefektivnění plánování údržby a revizí spravovaného Telematického majetku.
Získání podkladů pro přesné stanovení požadovaných parametrů nově pořizovaného Telematického majetku.

Předmětem veřejné zakázky bude dále i následná Podpora inovativního Systému správy Telematického majetku.

Veřejná zakázka je realizována v souladu se strategií TSK v oblasti telematických systémů v hl. m. Praze definovanou v dokumentu Telematické systémy v hl. m. Praze - Stav telematických aplikací, analýza telematických zakázek, strategie rozvoje na roky 2020 až 2025. Tento dokument definuje potřebu vytvoření Systému správy a údržby telematických aplikací TSK.

Realizace inovačního partnerství pro nalezení inovativního řešení správy Telematického majetku v Praze je rovněž v souladu se strategií hl. m. Prahy popsanou v následujících dokumentech:

Realizace záměru přispěje k vývoji dopravně-technologického informačního systému, jehož vytvoření je jedním z opatření v rámci Plánu udržitelné mobility Prahy a okolí. Dle tohoto dokumentu optimalizace správy a funkce stávajícího systému řízení dopravy přinese v delším období zlepšení plynulosti dopravy, což je v souladu především se strategickými cíli Zvýšení výkonnosti a spolehlivosti, Zlepšení lidského zdraví a Snížení uhlíkové stopy.
Realizace záměru přinese spolupráci města, podniků a výzkumných organizací na přípravě a realizaci projektu rozvoje inovačního prostředí. Tím přispívá k podpoře spolupráce veřejného, podnikatelského a výzkumného sektoru na dosažení inovací pro rozvoj a naplňuje tak jeden z cílů Strategického plánu hl. m. Prahy.
Realizace je v souladu s přílohou k usnesení Zastupitelstva HMP č. 9/10 ze dne 10. 9. 2015, která definuje priority inovačního programu Praha – Pól růstu ČR. Záměr koresponduje především s Prioritní osou 1: Posílení výzkumu, technologického rozvoje a inovací.
Realizace inovačního partnerství je rovněž jedním z opatření pro splnění strategického cíle „Rozvíjet prostředí stimulující inovace a fungující partnerství“ definovaném v Regionální Inovační Strategii Hlavního Města Prahy.

Předmětem plnění veřejné zakázky je provést pro Objednatele Dílo spočívající v analýze a výzkumu, vývoji, vytvoření prototypu, testování prototypu a nasazení Systému a poskytování následné Podpory vytvořeného Systému.

Dílo se skládá z následujících pěti etap:

První (1.) etapa: Analýza současného nastavení a úvodní návrh nového Systému
Druhá (2.) etapa: Vývoj Systému
Třetí (3.) etapa: Vytvoření prototypu Systému
Čtvrtá (4.) etapa: Testování prototypu Systému
Pátá (5.) etapa: Nasazení Systému do reálného provozu

Po Akceptaci díla je v rámci předmětu plnění požadováno poskytování Podpory vytvořeného Systému.

Požadavky na realizaci Díla a poskytování Podpory jsou detailně definovány v následujících kapitolách.

Zhotovitel provede detailní analýzu současných nástrojů, procesů, datových toků a informačních systémů využívaných pro správu Telematického majetku a provede výzkum pro úvodní návrh nového Systému. Výstupem analýzy budou dokumenty Definice projektu a Implementační studie.

Zhotovitel zpracuje v dokumentu Definice projektu a jeho přílohách řídicí projektovou dokumentaci pro jednotlivé projektové postupy, pomůcky a techniky realizace Projektu, která bude založena na některé obecné metodice projektového řízení. Dokument bude obsahovat zejména:

Harmonogram Projektu - popis jednotlivých etap Projektu, jejich zaměření a cíle.
Plán výstupů a akceptací - zpracovávané výstupy v jednotlivých etapách, pro každou etapu samostatně její vstupní podmínky umožňující její zahájení, ukončení a přechod k etapě následující.
Postupy pro řízení harmonogramu, řízení výstupů a akceptací.
Postup řízení kvality, rizik a změn, způsob vedení projektových registrů, potřebné šablony dokumentů (např. pro vykazování stavu projektu, vedení úkolů atp.) a výstupů a další potřebné elementy řízení projektu.
Způsob realizace Projektu - způsob analýzy, vývoje, testování a nasazování Systému a jeho provozu.
Postupy plánování a koordinace s ostatními aktivitami a iniciativami Objednatele. Definice takového způsobu řízení Projektu a jeho výstupů, který umožní realizaci Projektu souběžně s běžným provozem Objednatele.
Přehled Dokumentace, která bude v průběhu Projektu vytvořena. Dokumentaci Zhotovitel popíše v členění etap či jiných vhodných časových úseků Projektu. V popisu obsahu dokumentu Zhotovitel uvede zaměření a účel dílčích dokumentů a ve srozumitelných bodech vymezí jeho obsah formou osnovy.
Organizační strukturu Projektu.
Definice rolí a jejich odpovědností v rámci Projektu. Činnosti budou popsány formou RACI matice.
Požadovanou, pro Projekt nezbytnou, součinnost Objednatele, případně dalších dotčených subjektů a třetích stran.
Plán přenosu znalostí a dovedností na Objednatele.
Komunikační plán - způsob a formu komunikace, kterou Zhotovitel bude během realizace Projektu uplatňovat. Popis základních komponent komunikačního plánu Projektu a jejich obsah. Zhotovitel ve svém návrhu rozpracuje profil zainteresovaných stran na realizaci projektu a navrhne základní obsah matice komunikace v Projektu.
Návrh a popis dalších jinde neuvedených metod a postupů zaručující splnění cílů Objednatele.

Definice projektu podléhá akceptační proceduře uvedené v kapitole 5.2.

Zhotovitel zdokumentuje navrhované řešení ve formě Implementační studie. Do Implementační studie promítne výsledky analýzy, kterou Xxxxxxxxxx v této etapě zpracuje za účelem rozpoznat a zpracovat všechny aspekty nezbytné pro realizaci všech částí Projektu souvisejících s vytvořením a nasazením Díla a zajištěním schopnosti poskytovat jeho Podporu. Analýzu a návrh řešení Zhotovitel provede a v Implementační studii popíše tak, aby podle Implementační studie Zhotovitel byl schopen vyvinout a implementovat Systém spolu s provedením všech souvisejících aktivit. Implementační studie musí rozpracovat požadavky Objednatele, bezezbytku naplnit cíle Objednatele definované kapitolou 1 a obsahovat základní popis řešení.

Zhotovitel vytvoří Implementační studii Systému s přehledem identifikovaných požadavků na jeho nové funkcionality a jejich technické parametry. Do Implementační studie promítne výsledky analýzy. Účelem této analýzy je rozpoznat a zpracovat všechny aspekty nezbytné pro realizaci všech částí plnění souvisejících s vytvořením a nasazením inovativního Systému pro správu Telematického majetku a zajištěním schopnosti poskytovat Podporu. Dokumentuje funkční a technické požadavky a požadavky Objednatele na užití inovativního Systému správy Telematického majetku (a to jak zjištěné, tak inherentní). Aktualizuje uživatele, jejich role a oprávnění. Zachytí zpracovávané objemy dat a výkonnostní parametry. Zpracuje architekturu ve všech potřebných vrstvách včetně vazeb na okolní systémy. Zachytí konceptuální modely, scénáře užití, základní části inovativního Systému, moduly a funkční celky, hlavní datové položky, informace a toky zpracování a další návrhové artefakty. Navrhne potřebná výpočetní prostředí a jejich parametry. Zdokumentuje analýzu rizik spolu s identifikací aktiv, hrozeb, zranitelností a její vyhodnocení spolu s požadavky na bezpečnostní funkce inovativního Systému správy Telematického majetku. Rozpracuje přístup k testování, školení a nasazení Systému formou strategií pro tyto oblasti. Zachytí koncept budoucího provozního modelu, provozování, správy, administrace, dohledu a servisování Systému. Uvede principy budoucího organizačního zajištění, nastíní dočasné a trvalé změny a uvede principy přechodu na používání nového Systému. Popíše zásadní předpoklady, omezení a rizika spolu s opatřeními pro jejich zvládnutí.

Implementační studii Zhotovitel vhodně strukturuje a uspořádá do sady navazujících kapitol nebo dokumentů, aby potřebné aspekty zachytila srozumitelným a přehledným způsobem ve všech potřebných vazbách a souvislostech a tak usnadnila její akceptaci Objednatelem ve vší celistvosti.

Součástí Implementační studie jsou také koncepční dokumenty, zejména Strategie zkoušek a testování či další koncepční materiály dle Zhotovitelova návrhu, které budou Xxxxxxxxxxxx následně v dalším průběhu Projektu rozpracovány do podrobných plánů a postupů.

Zhotovitel je povinen dodat Dílo i poskytnout služby Podpory v souladu s dotčenými dokumenty a vnitřními předpisy TSK. Analýzu vztahu dokumentů a vnitřních předpisů TSK k dodávce Díla a poskytnutí Podpory provede Zhotovitel v rámci Implementační studie.

Minimální požadavky Objednatele na obsah Implementační studie (mohou být po dohodě se Objednatelem upraveny/doplněny):

Úvod
1. Předmět a cíle Projektu
2. Předmět a cíle Implementační studie
Projektové řízení (v souladu s dokumentem Definice projektu)
1. Harmonogram Projektu
2. Organizační struktura Projektu
3. Požadavky na součinnost Objednatele
4. Řízení kvality Projektu
5. Řízení komunikace a dokumentace průběhu Projektu
6. Řízení změn a eskalační pravidla
7. Řízení rizik
Popis současného stavu prostředí Objednatele a připravenost prostředí i organizace Objednatele a dotčených subjektů na implementaci nového Systému z pohledu všech souvisejících aspektů, zejm. technické připravenosti, organizační připravenosti vč. znalostí a dovedností a početnosti personálu, provozního modelu vč. procesů, postupů, metodik a návodů.
Analýza business požadavků budoucích uživatelů Systému.
Analýza potřeb Systému přes všechny dotčené odbornosti. Analýza vychází z předpisů, metodik a praxe zajišťování správy Telematického majetku.
Popis fungování Systému (technický návrh Systému, který musí plně zohledňovat příslušné legislativní a technické předpisy platné v České republice a dodržení standardů TSK¹).
Analýzu vztahu dokumentů a vnitřních předpisů TSK k dodávce Díla a poskytnutí Podpory
Popis výsledků jednotlivých etap Díla:
1. První (1.) etapa: detailní specifikace Systému (Definice projektu, Implementační studie)
2. Druhá (2.) etapa: pokročilý vývoj Systému, a to v takovém rozsahu, že budou splněny podmínky pro vytvoření prototypu Systému – podmínky zpracuje Zhotovitel v rámci Implementační studie a schvaluje Objednatel
3. Třetí (3.) etapa: Zhotovitelem vytvořený a Objednatelem Schválený prototyp Systému
4. Čtvrtá (4.) etapa: funkční a plně otestovaný Systém se zapracováním všech připomínek uživatelů, který splňuje požadované parametry
5. Pátá (5.) etapa: Uvedení do provozu a předání Zdrojových kódů a Dokumentace Objednateli, čímž budou splněny předpoklady pro Akceptaci díla.
Popis architektury nového Systému, včetně modulů, funkčních celků, popisu a vazeb na okolní systémy. Dále také příslušných diagramů, specifikací a modelů pro:
1. Infrastrukturní a komunikační vrstvu,
2. Aplikační vrstvu,
3. Procesní vrstvu nového Systému vč. jeho integrací,
Popis jednotlivých součástí Systému, jejich funkčnost a vzájemné propojení.
Návrh funkčních a technických vlastností a parametrů Systému, který bude vycházet z funkčních a technických požadavků na Systém definovaných v katalozích požadavků uvedených v kapitolách 4.2 a 4.3
Návrh a popis datového modelu a jeho diagram. Návrh datových základen pro Systém (včetně analýzy disponibilních dat Objednatele a popisu způsobu zajištění/doplnění dat nezbytných pro funkci Systému), návrh datových struktur.
Specifikace průběhu migrace dat ze stávajících systémů Objednatele, popis všech datových zdrojů pro migraci, podetapy migrace a postupy vedoucí k ověření správnosti této migrace (migrační scénář).
Přehled integračních vazeb a způsob jejich realizace formou služeb a doporučený postup pro zavedení těchto služeb.
Detailní požadavky na součinnost Objednatele vč. případných požadavků na rozšíření existující infrastruktury, komunikací nebo jejich úpravy a doplnění stávajících komponent nebo dobudování nových prvků.
Definice SW a HW požadavků Systému, zpracovávané objemy dat, výkonnostní parametry Systému a výpočetní prostředí.
Procesní analýza a procesní model, stanovení případů užití a způsob koexistence současného způsobu provádění procesů a nově vytvářeného Systému. Procesy, principy, logika a zvyklosti ověřené používáním v nahrazovaných systémech budou využity pro procesní analýzu. Xxxxxxxxxx provede revizi a návrh sjednocení aktuálních procesů Objednatele a posoudí jejich případný přenos do nového Systému.
Principy budoucího organizačního zajištění, návrh dočasných a trvalých změn a postup přechodu na používání nového Systému.
Návrh uživatelů Systému, jejich rolí a oprávnění.
Popis plánu testování Systému dle požadavků v kapitole 5.2.
Popis školení zaměstnanců Objednatele.
Popis poskytnuté Dokumentace k vyvinutému Systému, minimálně:
1. Kompletní vývojářská dokumentace
2. Uživatelská dokumentace
3. Systémová a administrátorská dokumentace
4. Metodické materiály
5. Školící materiály
6. Provozní dokumentace
7. Strategie dohledu nad Systémem

Popis plánu pasportizace Telematického majetku dle požadavků definovaných v kapitole 4.1.
Popis zajištění integrací na informační systémy obsluhující jednotlivá zařízení, nebo vytvoření rozhraní dle požadavků definovaných v kapitole 4.2.
Popis integrací Systému na další aplikační řešení Objednatele, popis komunikace s externími systémy. Studie zachytí používané systémy a aplikace, které budou Systémem nahrazeny i ty, které zůstanou zachovány, a Zhotovitel provede datovou integraci se Systémem.
Popis konfigurace řešení pro prostředí Objednatele s ohledem na spolupracující dotčené subjekty.
Popis provozního modelu Systému ve vazbě na architekturu procesní vrstvy, tzn. ve formě popisu procesů a jejich diagramů pro provoz, údržbu a následné Podpory Systému, dokumentace služeb Komplexní podpory ve formě jejich katalogových listů.
Popis zajištění kontinuity provozu, bezpečnosti, monitoringu, zálohování a odolnosti proti havárii ve vazbě na popis architektury.
Popis poskytování Podpory Systému.
Popis výkonnostních a kapacitních parametrů Systému.
Popis výkonnostních a kapacitních omezení, na něž je Systém dimenzován a popis způsobu, jakým bude možno výkonnost Systému dále rozšiřovat formou rozšiřování technického vybavení, konfigurování či doplňování software, zaměňování či doplňování licencí apod.
Popis prezentační vrstvy a výstupů Systému.
Návrh grafického uživatelského rozhraní.
Návrh řešení a určení vybrané podmnožiny funkcí pro nativního mobilního klienta (aplikace určená pro podporu práce a sběr dat v terénu na mobilním zařízení).
Přehled možností budoucího škálování a rozšiřování Systému zejména s ohledem na jeho výkonnostní a kapacitní limity a podmínky, při nichž bude možno dále navyšovat výkon Systému za hranice jeho plánovaného výkonu (např. možnost rozšíření hardware vč. limitních omezení např. v podobě volných slotů, možnosti doplnění software a licencí).
Metodika, způsob a postup k doplnění chybějících dat v rámci realizace Xxxx Xxxxxxxxxxxx.
Popis exit plánu.

Výsledkem Implementační studie je zpracování samostatného uceleného dokumentu, který bude odsouhlasený Objednatelem dle akceptačních podmínek definovaných v kapitole 5.2.

Po dokončení první etapy bude Zhotovitel realizovat vývoj nového inovativního Systému. Zhotovitel vyvine úvodní řešení funkčních a technických vlastností a parametrů Systému dle schválené Implementační studie

Vývojové činnosti Zhotovitel realizuje v souladu s požadavky definovanými v kapitole 5.1., akceptace realizovaných prací se pak bude řídit podmínkami definovanými v kapitole 5.2.

Objednatel požaduje realizovat vývoj inovativního Systému správy Telematického majetku a jeho implementaci do prostředí Objednatele na základě Objednatelem odsouhlasené Implementační studie.

Výsledkem druhé etapy bude pokročilý vývoj Systému dle schválené Implementační studie, a to v takovém rozsahu, že budou splněny podmínky pro vytvoření prototypu Systému. Podmínky zpracuje Zhotovitel v rámci Implementační studie a schvaluje je Objednatel.

Zhotovitel na základě pokročilého vývoje vytvoří prototyp Systému. Vyvinutý prototyp rovněž Zhotovitel parametrizuje a kustomizuje a bude instalována jeho databáze. Funkční a technické vlastností a parametry prototypu budou vycházet z Implementační studie a výsledků druhé (2.) etapy.

Vytváření prototypu Zhotovitel realizuje v souladu s požadavky definovanými v kapitole 5.1, schválení finální podoby vytvořeného prototypu se pak bude řídit podmínkami definovanými v kapitole 5.2.

Zhotovitel rovněž zahájí fyzickou pasportizaci telematického majetku dle podmínek definovaných v kapitole 4.1. Získané údaje o telematickém majetku budou využity k úvodnímu testování vyvinutého prototypu Systému dle požadavků uvedených v kapitole 5.2.

Výsledkem třetí etapy bude Zhotovitelem vytvořený a Objednatelem schválený prototyp Systému.

Po akceptaci prototypu Systému ze strany Objednatele, vytvoří Zhotovitel testovací prostředí, ve kterém Zhotovitel důkladně otestuje vyvinutý prototyp Systému. Testování a akceptace jeho výsledků Zhotovitel realizuje v souladu s požadavky v kapitole 5.2. Zhotovitel bude rovněž pokračovat ve fyzické pasportizaci telematického majetku dle podmínek definovaných v kapitole 4.1. Funkčnost navržených prototypů pak bude Objednatelem ověřována na získaných pasportních datech se zapojením klíčových uživatelů budoucího Systému. Pro kontrolu splnění požadavků na Systém budou Objednatelem využívány seznamy funkčních a technických požadavků definované v kapitolách 4.2 a 4.3, schválená Implementační studie a výsledky třetí (3.) etapy.

Po otestování integruje Zhotovitel schválený Systém správy Telematického majetku do infrastruktury Objednatele.

Realizaci implementace Zhotovitel provede v souladu s požadavky definovanými v kapitole 5.1, akceptace etapy se pak bude řídit podmínkami definovanými v kapitole 5.2.

Součástí této etapy je rovněž školení uživatelů Objednatele v rozsahu max. 60 hodin ze strany Zhotovitele.

Součástí Implementace jsou i veškeré nezbytné a související konzultace ze strany Zhotovitele.

Výsledkem čtvrté etapy bude funkční a plně otestovaný Systém se zapracováním všech připomínek uživatelů, který splňuje požadované parametry.

Zhotovitel vytvoří produkční prostředí vyvinutého Systému a dokončí fyzickou pasportizaci Telematického majetku dle podmínek definovaných v kapitole 4.1 a uvede Systém do ověřovacího provozu. Před Uvedením do provozu provede Zhotovitel finální testy s využitím plného vzorku pasportních dat. Finální testování a akceptace jeho výsledků Xxxxxxxxxx realizuje v souladu s požadavky definovanými v kapitole 5.2.

Pro kontrolu splnění požadavků na Systém budou Objednatelem vyžívány výsledky (4.) etapy.

Po dokončení finálních testů a migraci dat Zhotovitel nový Systém uvede do reálného provozu. Duševní vlastnictví bude vypořádáno dle podmínek definovaných v příloze č. 5 této zadávací dokumentace. Součástí této etapy je dokončení předání veškeré Dokumentace Objednateli.

Výsledkem páté (5.) etapy bude Akceptace Díla a Uvedení do provozu.

Po Uvedení do provozu Objednatel požaduje poskytování Podpory Systému Zhotovitelem.

Zhotovitel je povinen poskytovat Podporu kontinuálně po celou dobu platnosti a účinnosti Smlouvy o podpoře. Detailní požadavky na Podporu jsou definovány v kapitole 4.4. Podpora znamená poskytování Komplexní podpory a Rozšířené podpory Zhotovitelem na základě Smlouvy o podpoře.

V rámci Smlouvy o podpoře je Zhotovitel zavázán poskytovat zejména následující Komplexní podporu:

Služba HelpDesk, resp. ServiceDesk Zhotovitele s možností integrace na HelpDesk Objednatele;
Uživatelská podpora ve třech úrovních – on-line a off-line služby zahrnující telefonickou a elektronickou komunikaci pomocí HelpDesk s uživateli;Aktualizace nastavení jednotlivých částí Systému;
Administrace uživatelů, správa rolí pro skupiny uživatelů;
Pravidelné kontroly - jedná se o soubor pravidelných služeb prováděných vždy 1x za měsíc. Služby Komplexní podpory zahrnují pravidelnou kontrolu, aktualizaci Systému a zálohování DB;
Servisní technická podpora (řešení incidentů);
Údržba Systému, přičemž údržba software a firmware produktů, které jsou součástí Systému, zahrnuje zejména poskytování a implementaci nových verzí těchto produktů, provádění update či upgrade těchto produktů, instalaci opravných patchů;
Odstraňování vad Systému, řešení zjištěných či hlášených incidentů a podporu při disaster recovery (obnově po pádu Systému);
Poradenství a konzultace;
Nastavení zálohování Systému a podporu správy uživatelů;
podpora licenčního software (SW maintenance)
Zpracování dat a správa dat;
Konverze dat, exporty/importy dat od externích zpracovatelů;
Zprovoznění Systému po havárii hardware, konfigurace Systému na vyžádání;
Specializované expertní služby související s nastavením parametrů Systému;
Doškolování uživatelů na pracovišti nad rámec plánu;
Aktualizace dokumentace Systému v závislosti na provedených úpravách.

V rámci Smlouvy o podpoře je Zhotovitel zavázán poskytovat zejména následující Rozšířenou podporu:

školení dle požadavků Objednatele nad sjednaný rozsah;
řešení požadavků na úpravu provozních parametrů Systému a drobných úprav Systému; a
poskytování konzultací a metodické podpory, včetně implementace nových verzí Systému.

TSK v současné době spravuje rozsáhlé portfolio HW a SW v oblasti telematiky, která slouží pro monitoring, organizaci a vyhodnocování dopravy. Jedná se např. o světelná signalizační zařízení (SSZ), kamerové systémy, senzory, optické kabely, automatické detektory, proměnné dopravní značení a další telematická zařízení. Tato telematická zařízení jsou svým početním i druhovým rozsahem, celkovým uspořádáním a vzájemnými vazbami unikátní. Vzhledem k tomu, že jsou zařízení od různých dodavatelů, jejich nároky na správu a údržbu mají odlišné způsoby a parametry. TSK požaduje implementaci Systému, který umožní jednotnou komplexní správu Telematického majetku a případné nahrazení stávajících izolovaných řešení, ze kterých bude nutno vytěžit v nich uložená data a přenést je po překontrolování a vyčistění do budoucího centralizovaného Systému.

Pro názornost významu centralizace správy Telematického majetku TSK jsou níže uvedeny počty klíčových telematických HW zařízení, které TSK nyní na území hlavního města Prahy eviduje:

Tabulka 1: Počty klíčových telematických HW zařízení v evidenci TSK na území hl. m. Prahy

Typ zařízení	Počet zařízení	Aktuálně evidované parametry
Světelně řízení křižovatky (SSZ)	686	Externí inv.číslo Dokumenty Zámek Identifikátor křižovatky Název křižovatky Městský obvod Městská část Katastr Sektor Ulice Ul. úsek I Ul. úsek II Typ křižovatky Provizorní Vlastník Servisní organizace Datum realizace Datum převzetí Záruční doba do Datum obnovy Datum výměny řadiče Nadřazená ústředna Nadřazený řadič Napájení Adresa napájecího bodu Nepřetržitý provoz Datum zaměření Datum revize Historie revize Pozice
Koordinační kabely (KK)	710	Externí inv.číslo Číslo Městská část Katastr Sektor Identifikátor Počáteční křižovatka Koncová křižovatka Typ kabelu Servisní organizace Datum realizace Datum převzetí Záruční doba do Datum zaměření Délka Vlastník
Optické trubky (OT)	668	Externí inv.číslo Číslo Městská část Katastr Sektor Identifikátor Počáteční křižovatka Koncová křižovatka Typ trubky Servisní organizace Datum realizace Datum převzetí Záruční doba do Datum zaměření Délka Vlastník Počet trubek
Optické trubky v metru (OTM)	64	Externí inv.číslo Číslo Městská část Katastr Sektor Identifikátor Počáteční stanic Koncová stanice Typ trubky Servisní organizace Datum realizace Datum převzetí Záruční doba do Datum zaměření Délka Vlastník Počet trubek
Kamery televizního dohledu (TVD)	316	Externí inv.číslo Zámek Číslo Městská část Katastr Sektor Ulice Ul. úsek I Ul. úsek II Identifikátor Datum realizace Datum převzetí Umístění SSZ Napájení Druh kamery Výrobce a typ Servisní organizace Typ přenosu
Zařízení pro určení dojezdových dob (DD)	10	Externí inv.číslo Zámek Číslo Městská část Katastr Sektor Identifikátor Popis Od Do Napájení 1 Napájení 2 Výrobce a typ Servisní organizace Typ přenosu Datum převzetí Délka
Měření úsekové rychlosti (MÚR)	53	Externí inv.číslo Zámek Číslo Městská část Katastr Sektor Identifikátor Popis Od Do Napájení 1 Napájení 2 Výrobce a typ Servisní organizace Typ přenosu Datum převzetí Délka
Detekce jízdy na červenou (DJČ)	21	Externí inv.číslo Zámek Číslo Městská část Katastr Sektor Ulice Ul. úsek I Ul. úsek II Identifikátor Měřený směr Lokalita zápisu přestupků Napájení Datum převzetí Výrobce a typ Servisní organizace Typ přenosu
Měření okamžité rychlosti (MOR)	38	Externí inv.číslo Zámek Číslo Městská část Katastr Sektor Ulice Ul. úsek I Ul. úsek II Identifikátor Měřený směr Lokalita zápisu přestupků Napájení Datum převzetí Výrobce a typ Servisní organizace Typ přenosu
Telematický dohledový systém (TDS)	244	Externí inv.číslo Číslo Městská část Katastr Sektor Ulice Ul. úsek I Ul. úsek II Datum realizace Datum převzetí Umístění SSZ Napájení Výrobce a typ Servisní organizace Typ přenosu
Strategické dopravní detektory úsekové (SDDÚ)	22	Externí inv.číslo Zámek Číslo Městská část Katastr Sektor Identifikátor Od Do Napájení 1 Napájení 2 Výrobce a typ Servisní organizace Typ přenosu Datum realizace Datum převzetí Délka
Strategické dopravní detektory řezové (SDDŘ)	188	Externí inv.číslo Číslo Městská část Katastr Sektor Ulice Ul. úsek I Ul. úsek II Identifikátor Lokalita Napájení Datum převzetí Výrobce a typ Servisní organizace Typ přenosu
Klimatické vozovkové detektory (KVD)	28	Externí inv.číslo Číslo Městská část Katastr Sektor Ulice Ul. úsek I Ul. úsek II Identifikátor Lokalita Napájení Datum realizace Datum převzetí Výrobce a typ Servisní organizace Typ přenosu
Imisní monitorovací stanice (IMS)	30	Číslo Městská část Katastr Sektor Ulice Ul. úsek I Ul. úsek II Identifikátor Popis Lokalita Napájení Výrobce a typ Servisní organizace Typ přenosu
Zařízení pro provozní informace (ZPI)	65	Externí inv.číslo Zámek Číslo Městská část Katastr Sektor Ulice Ul. úsek I Ul. úsek II Identifikátor Lokalita Napájení Hodnota jističe Datum realizace Datum převzetí Výrobce a typ Servisní organizace Druh zobrazované informace Typ ovládání Typ přenosu
Proměnné dopravní znační (PDZ)	94	Číslo Městská část Katastr Sektor Ulice Ul. úsek I Ul. úsek II Identifikátor Popis Lokalita Napájení Výrobce a typ Servisní organizace Druh zobrazované informace Typ ovládání Typ přenosu
Radary a ukazatele rychlosti	128	Externí inv.číslo Číslo Městská část Katastr Sektor Ulice Ul. úsek I Ul. úsek II Identifikátor Lokalita Napájení Výrobce a typ Servisní organizace Druh zobrazované informace Typ ovládání Typ přenosu Režim provozu
LED dopravní značky	191	Externí inv.číslo Číslo Městská část Katastr Sektor Ulice Ul. úsek I Ul. úsek II Identifikátor Popis Lokalita Napájení Datum převzetí Výrobce a typ Servisní organizace Druh zobrazované informace Režim provozu
Blikače (BLK)	40	Externí inv.číslo ¨ Číslo Městská část Katastr Sektor Ulice Ul. úsek I Ul. úsek II Identifikátor Popis Lokalita Napájení Datum realizace Datum převzetí Výrobce a typ Servisní organizace Druh zobrazované informace Režim provozu
Parkovací systémy (PAR)	42	Externí inv.číslo ¨ Číslo Městská část Katastr Sektor Ulice Ul. úsek I Ul. úsek II Identifikátor Popis Lokalita Napájení Datum převzetí Výrobce a typ Servisní organizace Druh zobrazované informace Typ ovládání Typ přenosu Režim provozu
Parkovací čidla (ZTP)	95	Číslo Městská část Katastr Sektor Ulice Ul. úsek I Ul. úsek II Identifikátor Popis Lokalita Napájení Výrobce a typ Servisní organizace Druh zobrazované informace Typ ovládání Typ přenosu Režim provozu
Vážení vozidel (VAZ)	9	Externí inv.číslo Číslo Městská část Katastr Sektor Ulice Ul. úsek I Ul. úsek II Identifikátor Popis Lokalita Napájení Datum převzetí Výrobce a typ Servisní organizace Platnost certifikace
Optické kabely (OK)	98	Číslo Městská část Katastr Sektor Identifikátor Počátek Konec Typ kabelu Servisní organizace Datum realizace Datum převzetí Délka
Optické kabely v metru (OKM)	86	Číslo Městská část Katastr Sektor Identifikátor Počátek Konec Typ kabelu Servisní organizace Délka
Systémy řízení v tunelech (TUN)*	1	Externí inv.číslo Číslo Městská část Katastr Sektor Ulice Ul. úsek I Ul. úsek II Identifikátor Popis Umístění Výrobce a typ Servisní organizace
Bezdrátové trasy	235	Číslo Městská část Katastr Sektor Identifikátor Počáteční bod Koncový bod Sloupy VO Typ zařízení Servisní organizace Délka
Kontrola výšky vozidel (KVV)	2	Externí inv.číslo Číslo Městská část Katastr Sektor Ulice Ul. úsek I Ul. úsek II Identifikátor Popis Lokalita Napájení Datum realizace Výrobce a typ Servisní organizace
Oblastní dopravní řídící ústředna (ODŘÚ)	11	Externí inv.číslo Dokumenty Městská část Katastr Sektor Ulice Ul. úsek I Ul. úsek II Identifikátor Popis Umístění Pozice Výrobce a typ Servisní organizace

* V budoucím nastavení plánováno evidovat v nové kategorii Řídící centra.

Výše uvedené údaje jsou orientační a platné k 30. 4. 2020, jejich hodnoty se mohou v průběhu zadávacího řízení měnit. Zároveň se jedná o přehled jednotlivých druhů telematických zařízení, které TSK využívá. Každé zařízení je však tvořeno dalšími komponentami (např. kabely, kamerami, napájením), které jsou součástí zařízení. V řešení, které je v rámci této zadávací dokumentace poptáváno, tak budou evidována a pasportizována uvedená zařízení včetně jejich komponent v rozsahu dle požadavků uvedených v kapitole 4.1.

TSK v současné době nedisponuje uceleným nástrojem pro správu telematického majetku, který by umožňoval centrální pasportizaci a monitoring telematických zařízení (technické prvky, HW) a souvisejících informačních systémů (softwarové komponenty, SW). Část evidence telematických zařízení je dnes realizována v aplikaci SRD, ostatní zařízení jsou evidována pomocí tabulek v MS Excel. Pro správu jen některých telematických systémů jsou tak dnes pracovníkům mnohdy k dispozici jen dílčí izolované evidence, které mají povahu pouze základních inventárních seznamů a které jsou do jisté míry nesourodé. Nejsou vzájemně provázané, což ani od seznamů ve formě tabulek nelze očekávat, natož aby umožňovaly sdílení dat a informací. Pasportizace je neúplná a roztříštěná. Není pro ni zavedena jednotná platforma. Neexistuje jednotné prostředí, ani společná databáze pro ukládání a prezentaci dat.

TSK současně nemá ani vhodný prostředek, který by spolu s koncovými telematickými HW zařízeními umožňoval spravovat a evidovat související SW nástroje a aplikace, které jsou na tato četná telematická zařízení navázány. Příkladem je aplikace pro čtení registračních značek vozidel, která je implementována na určitém segmentu kamerových dohledových systémů.

Evidence a správa Telematického majetku je tak nyní neúplná a roztříštěná a probíhá v různých nástrojích bez vzájemného propojení s rozdílnou úrovní poskytovaných služeb. Současný způsob evidence s využitím kombinace systému SRD a XLS tabulek totiž nelze za plnohodnotný prostředek pro jakoukoliv evidenci považovat. Je to operativní a porůznu izolované řešení potřeb, k nimž doposud nebylo přistoupeno systémově. TSK nyní nemá možnost v reálném čase zjišťovat informace o spravovaném Telematickém majetku, jeho stavu a parametrech (záruky, termíny servisních prohlídek apod.). Správa Telematického majetku tak funguje s velmi omezenou efektivitou na úrovni různých operativních pomůcek.

Absence jednotného nástroje pro správu a monitoring Telematického majetku s informacemi o jeho aktuálním stavu rovněž omezuje rychlost reakce na vzniklé poruchové stavy telematických zařízení. Aktuálně využívané nástroje totiž neumožňují okamžité informování o poruchách a TSK tak nemůže efektivně reagovat na vzniklé poruchové stavy. Pomalejší reakční doba pak může omezovat plynulost a bezpečnost dopravy na pražských komunikacích.

Současné nastavení zároveň neumožňuje jednotné plánování údržby, revizí a výměn telematických zařízení s končící životností, čímž je dále snížena efektivita správy Telematického majetku a zajištění jeho bezproblémového fungování při dodržování technických a revizních parametrů jednotlivých zařízení.

Pro účely pasportní evidence TSK v současnosti využívá dva hlavní nástroje. Je to jednak aplikaci SRD a pak různé pomocné evidence vytvořených v nástrojích pro automatizaci kancelářských činností MS Office (především MS Excel).

Aplikace SRD představuje primární nástroj pro správu Telematického majetku TSK. Obsahuje informaci o většině spravovaných telematických zařízení. V aplikaci jsou evidovány počty zařízení a jejich klíčové parametry, které jsou pro každý druh telematického zařízení uvedeny v přehledu v kapitole 3.1. Informace jsou v aplikaci zobrazeny ve dvou hierarchiích vrstev.

Tabulka 2. Informační vrstvy aplikace SRD.

Vrstva	Informační obsah
Symbolické znázornění	zařízení řízení dopravy jsou zde zakreslena symbolickými značkami či čarami, k nimž jsou připojeny databázové záznamy
Detailní zobrazení	v těchto vrstvách jsou zaneseny jednotlivé prvky, z nichž se zařízení řízení dopravy skládají. K těmto prvkům nejsou připojeny databázové záznamy

Mezi hlavními funkcionalitami aplikace SRD lze uvést následující oblasti:

Vyhledávání definovaných telematických zařízení v několika mapových vrstvách a v různém měřítku i oblasti.
Výpis telematických zařízení v daném území zobrazeném na mapě.
Vyhledávání telematických zařízení a jejich informací (parametrů) v databázi seznamu objektů.
Tisk map, seznamu objektů a dalších tiskových sestav.
Vkládání a editace informací o telematických zařízeních.
Zobrazení dokumentace k telematickým zařízením.

Z dalších podstatných vlastností aplikace SRD lze uvést tyto její parametry:

Aplikace je napojena na mapové podklady systému GIS a umožňuje tak přesnou lokalizaci telematických zařízení.
Databáze aplikace vybudována na technologii NexusDB.
Použití aplikace v rámci TSK není nijak vázáno díky její neomezené licenci.
Aplikace slouží pouze pro autorizovaný přístup určeného počtu interních uživatelů. Pro veřejný přístup není aplikace nijak přizpůsobena.

Aplikace SRD bude TSK využívána i po implementaci nového inovativního Systému pro správu Telematického majetku ke správě ostatního (netelematického) majetku ve vlastnictví TSK. Inovativní Systém tak musí být na tuto aplikaci napojen pro umožnění sdílení informací a výměnu dat mezi systémy.

Pokud nejsou telematická zařízení a jejich parametry evidovány v aplikaci SRD, pak se pro jejich správu používají různé pomocné evidence, což jsou zejména

Soubory MS Excel
Dokumentace přímo k jednotlivým zařízením

Evidence vedená tímto způsobem je však soustředěná u jednotlivých správních techniků, není nijak navzájem propojená a tak celkové roztříštěná. Jakákoliv aktualizace, správa či vyhodnocování takto izolovaných údajů jsou pak velmi komplikované.

TSK rovněž v současnosti postrádá vhodný prostředek, který by spolu s koncovými telematickými HW zařízeními umožňoval spravovat a evidovat s nimi související SW nástroje a aplikace, které jsou na tato četná telematická zařízení navázány. Příkladem je aplikace pro čtení registračních značek vozidel, která je implementována na určitém segmentu kamerových dohledových systémů.

Žádný z výše uvedených nástrojů také neumožňuje sledování aktuálního stavu zařízení v reálném čase, ani aktivně neupozorňuje na potřebu revizních kontrol, ukončení záručních dob apod. Tyto údaje jsou tak zjišťovány přímo v terénu fyzickým zjišťováním, což předurčuje možnou efektivitu současné správy Telematického majetku TSK.

Součástí předmětu plnění je i realizace fyzické pasportizace Telematického majetku (realizovaná v průběhu etap 3 – 5), který bude v Systému evidován a spravován. Pasportizaci Telematického majetku Zhotovitel realizuje dle přehledu telematických zařízení k pasportizaci a jejich tzv. „hloubky pasportizace“, definované v tabulce č. 3.

Součástí pasportizace je i nezbytná digitalizace dat, která nejsou v současnosti digitalizovaná.

Pojmem „hloubka pasportizace“ se označuje výčet komponent či vlastnost, které musí být pro každé telematické zařízení v Systému evidovány. Uvedená „hloubka pasportizace“ je minimálním požadavkem Objednatele, který může být účastníky inovačního partnerství, v rámci jednání o předběžných nabídkách nebo při realizaci (např. v Implementační studii), dále vhodně rozšiřován.

Zhotovitel provede pasportizaci Telematického majetku v následujícím rozsahu:

Pasportizace celkem 4 000 komponent telematických zařízení dle definované „hloubky pasportizace“ podle tabulky č. 3.
Pro každý typ telematického zařízení, uvedeného v tabulce č. 3, Zhotovitel v definované „hloubce pasportizace“ pasportizuje alespoň 1 zařízení.
Zhotovitel vytvoří detailní metodiku pro provedení budoucí pasportizace zbývajících telematických zařízení (nad rámec požadovaných 4 000 komponent) a jejich zaevidování do Systému.

Výše uvedený rozsah pasportizace telematických zařízení představuje tzv. „plný pasportní vzorek“, který Xxxxxxxxxx využije během testování a implementace inovativního Systému pro správu Telematického majetku.

Přehled parametrů, které budou pro pasportizovaná zařízení a jejich komponenty evidovány, je uveden v kapitole 4.3.

Tabulka 3: Přehled telematických zařízení k pasportizaci a požadovaná „hloubka pasportizace“

Typ telematického zařízení	Požadovaná hloubka pasportizace (komponenty telematického zařízení k pasportizaci)
Světelně řízení křižovatky (SSZ)	Počet tlačítek a jejich typy Počet návěstidel a jejich typy Komunikační cesta Druh řadiče a řízení řadiče Počet sloupků a jejich typy Detekce, jejich typ a počet Preferenční jednotka a její typ Modul pro stmívání návěstidel Modul napájení
Koordinační kabely (KK)	Existence, typ a umístění spojek
Optické trubky (OT)	Existence, typ a umístění spojek
Optické trubky v metru (OTM)	Existence, typ a umístění spojek
Kamery televizního dohledu (TVD)	Rozvaděč a jeho typ Baterie, jejich typ, kapacita Komunikační cesta Modul napájení
Zařízení pro určení dojezdových dob (DD)	Rozvaděč a jeho typ Baterie, jejich typ, kapacita Komunikační cesta Modul napájení Typ scanneru
Měření úsekové rychlosti (MÚR)	Rozvaděč a jeho typ Baterie, jejich typ, kapacita Komunikační cesta Modul napájení Typy a počty kamer Typy a počty IR přisvícení
Detekce jízdy na červenou (DJČ)	Rozvaděč a jeho typ Baterie, jejich typ, kapacita Komunikační cesta Modul napájení Typy a počty kamer Typy a počty IR přisvícení
Měření okamžité rychlosti (MOR)	Rozvaděč a jeho typ Baterie, jejich typ, kapacita Komunikační cesta Modul napájení Typy a počty kamer Typy a počty IR přisvícení
Telematický dohledový systém (TDS)	Rozvaděč a jeho typ Baterie, jejich typ, kapacita Komunikační cesta Modul napájení Typy a počty kamer Typy a počty detektorů
Strategické dopravní detektory úsekové (SDDÚ)	Rozvaděč a jeho typ Baterie, jejich typ, kapacita Komunikační cesta Modul napájení Typy a počty kamer Typy a počty IR přisvícení
Strategické dopravní detektory řezové (SDDŘ)	Rozvaděč a jeho typ Baterie a jejich typ, kapacita Komunikační cesta Modul napájení Typy a počty kamer Typy a počty IR přisvícení
Klimatické vozovkové detektory (KVD)	Rozvaděč a jeho typ Baterie, jejich typ, kapacita Komunikační cesta Modul napájení Typ a počty čidel
Imisní monitorovací stanice (IMS)	Rozvaděč a jeho typ Baterie, jejich typ, kapacita Komunikační cesta Modul napájení Typ a počty čidel
Zařízení pro provozní informace (ZPI)	Rozvaděč a jeho typ Komunikační cesta Modul napájení Typ zobrazovací plochy
Proměnné dopravní znační (PDZ)	Rozvaděč a jeho typ Komunikační cesta Modul napájení Typ zobrazovací plochy
Radary a ukazatele rychlosti	Rozvaděč a jeho typ Baterie, jejich typ, kapacita Komunikační cesta Modul napájení
LED dopravní značky	Modul napájení Baterie, jejich typ, kapacita
Blikače (BLK)	Počet návěstidel a jejich typy Počet sloupků a jejich typy Rozvaděč a jeho typ Modul napájení
Parkovací systémy (PAR)	Počet návěstidel/detektorů a jejich typy Počet sloupků a jejich typy Rozvaděč a jeho typ Modul napájení Komunikační cesta
Parkovací čidla (ZTP)	Počet detektorů a jejich typy Rozvaděč a jeho typ Modul napájení Komunikační cesta
Vážení vozidel (VAZ)	Rozvaděč a jeho typ Baterie, jejich typ, kapacita Komunikační cesta Modul napájení Typy a počty kamer Typy a počty IR přisvícení Počty a typy vážících senzorů
Optické kabely (OK)	Obsazení vláken v členění na systém a organizaci
Optické kabely v metru (OKM)	Obsazení vláken v členění na systém a organizaci
Bezdrátové trasy	Rozvaděč a jeho typ Modul napájení Počty a typ antén Baterie, jejich typ, kapacita
Kontrola výšky vozidel (KVV)	Rozvaděč a jeho typ Baterie, jejich typ, kapacita Komunikační cesta Modul napájení Typy a počty kamer Typy a počty IR přisvícení
Oblastní dopravní řídící ústředna (ODŘÚ)	Typ serveru Diskové pole Komunikační modul Modul napájení Modul ÚPS
Řídící centra* (HDŘÚ, Malovanka, Strahov)	Dílčí technologické celky (provozní soubory)

* Nová kategorie telematických zařízení ke správě v rámci nového Systému. Bude obsahovat systémy řízení v tunelech a další řídící centra.

Budoucí Systém a jeho dílčí aplikace bude možné na úrovni kvalifikovaného uživatele administrovat a nastavovat, aby byly přizpůsobeny příslušnému typu pasportizovaných zařízení (např. nastavení vhodné struktury formulářů a jejich polí, které se budou plnit výběrem z příslušných číselníků, jejichž struktura a obsah budou rovněž uživatelsky nastavitelné).

Součástí pasportizace realizované Zhotovitelem je i evidence SW nástrojů a aplikací, které jsou na telematická zařízení navázány.

Údaje bude možno zadávat nejen prostřednictvím počítače jejím uživatelem v kanceláři, součástí plnění Zhotovitele bude také mobilní aplikace. Tato mobilní aplikace bude umožňovat sběr pasportizačních dat a provádění pasportizace přímo v terénu a bude spustitelná na obvyklých a běžných mobilních zařízeních typu chytrý telefon nebo tablet.

Aplikace bude sloužit nejen pro sběr pasportizačních údajů, ale také např. pro sběr informací o závadě daného zařízení a jejich nahlašování (tj. vytvořit uživatelsky vhodné formuláře a číselníky stavů).

Realizovaný Systém musí být schopen daný typ Telematického majetku evidovat a umožňovat jeho aktivní správu, což musí být prakticky ověřeno na funkčním prototypu pro daný typ majetku, do nějž budou vloženy pasportní údaje v dostatečně průkazném objemu, např. z celého území některé městské části či jinak vhodně vymezeného a Objednatelem odsouhlaseného území.

Budoucí pasportizaci zbylých telematických zařízení (nad rámec plného pasportního vzorku, tedy požadovaných 4 000 komponent) a jejich zaevidování do Systému provede Objednatel prostřednictvím vlastních zaměstnanců nebo s využitím třetích stran. Objednatel nebo jím pověřené třetí strany pro budoucí pasportizaci využijí specializované nástroje a funkce Systému a metodiku dodanou Zhotovitelem.

Systém pro správu Telematického majetku bude zajišťovat komplexní technickou a provozní evidenci zařízení dopravní telematiky. Zhotovitel Systém propojí se systémem HDŘÚ (Hlavní dopravní řídící ústředna Hlavního města Prahy), kam bude předávat technická data přijatá online z telematických zařízení. Systém bude také poskytovat stavové a provozní údaje.

Systém bude provozován na HW infrastruktuře TSK. Parametry HW infrastruktury TSK budou projednány v průběhu řízení o inovačním partnerství. Objednatel připouští i možnost využití cloudových služeb.

Zhotovitel Systém napojí na informační systémy obsluhující jednotlivá telematická zařízení, ze kterých bude získávat stavové a provozní údaje o zařízeních (pokud je zařízení informačním systémem obsluhováno). Přehled informačních systémů pro jednotlivá telematická zařízení, na které Zhotovitel zajistí integraci, je uveden v tabulce č. 4. Integrace bude Zhotovitelem realizována napojením na současné rozhraní jednotlivých informačních systémů nebo vytvořením nového rozhraní.

Tabulka 4: Přehled informačních systémů k zajištění integrace

Typ zařízení	Název informačního systému	Dodavatel	Existence rozhraní pro integraci
Světelně řízení křižovatky (SSZ)	SW Scala	Siemens, s.r.o.	Zhotovitel prověří možnost integrace na stávající rozhraní ODŘÚ
	SW VRS5000	SWARCO TRAFFIC CZ, s.r.o.	Zhotovitel prověří možnost integrace na stávající rozhraní ODŘÚ
	Přibližně 120 SSZ není napojeno na žádné SW řešení	-	-
Koordinační kabely (KK)	SW Scala	Siemens, s.r.o.	Zhotovitel prověří možnost integrace na stávající rozhraní ODŘÚ
Koordinační kabely (KK)	SW VRS5000	SWARCO TRAFFIC CZ, s.r.o.	Zhotovitel prověří možnost integrace na stávající rozhraní ODŘÚ
Optické trubky (OT)	Bez napojení na SW řešení
Optické trubky v metru (OTM)	Bez napojení na SW řešení
Kamery televizního dohledu (TVD)	SW Watchcam pro hlídání dostupnosti obrazu	Colsys s.r.o.	Zhotovitel vytvoří rozhraní pro integraci
Kamery televizního dohledu (TVD)	SW GscView/G - View pro sběr toku obrazových dat z kamer a jejich distribuci na zobrazovače	Geutebruck	Zhotovitel vytvoří rozhraní pro integraci
Zařízení pro určení dojezdových dob (DD)	SW Unicam Discoverer	CAMEA, spol. s r. o.	Zhotovitel prověří možnosti využití stávajícího rozhraní
Měření úsekové rychlosti (MÚR)
Detekce jízdy na červenou (DJČ)
Měření okamžité rychlosti (MOR)
Telematický dohledový systém (TDS)	SW Unicam Discoverer	CAMEA, spol. s r. o.	Zhotovitel prověří možnosti využití stávajícího rozhraní
	SW Watchcam pro hlídání dostupnosti obrazu	Colsys s.r.o.	Zhotovitel vytvoří rozhraní pro integraci
	SW GscView/G - View pro sběr toku obrazových dat z kamer a jejich distribuci na zobrazovače	Geutebruck	Zhotovitel vytvoří rozhraní pro integraci
Strategické dopravní detektory úsekové (SDDÚ)	SW Unicam Discoverer	CAMEA, spol. s r. o.	Zhotovitel prověří možnosti využití stávajícího rozhraní
Strategické dopravní detektory řezové (SDDŘ)	Servisní webová stránka	ELTODO, a.s.	Zhotovitel prověří možnosti využití stávajícího rozhraní
Klimatické vozovkové detektory (KVD)	Servisní webová stránka	ELTODO, a.s.	Zhotovitel prověří možnosti využití stávajícího rozhraní
Imisní monitorovací stanice (IMS)	SW Unicam Discoverer	CAMEA, spol. s r. o.	Zhotovitel prověří možnosti využití stávajícího rozhraní
Zařízení pro provozní informace (ZPI)	ŘS HDŘÚ	VARS BRNO, a.s.	Existuje servisní webová aplikace, Zhotovitel vytvoří rozhraní pro integraci
Proměnné dopravní znační (PDZ)	SW Scala	Siemens, s.r.o.	Zhotovitel prověří možnost integrace na stávající rozhraní ODŘÚ
	SW VRS5000	SWARCO TRAFFIC CZ, s.r.o.	Zhotovitel prověří možnost integrace na stávající rozhraní ODŘÚ
	ŘS HDŘÚ	VARS BRNO, a.s.	Existuje servisní webová aplikace, Zhotovitel vytvoří rozhraní pro integraci
	ŘS příslušného tunelu	ELTODO, a.s.	Zhotovitel prověří možnosti využití stávajícího rozhraní
Radary a ukazatele rychlosti	SW Unicam Discoverer	CAMEA, spol. s r. o.	Zhotovitel prověří možnosti využití stávajícího rozhraní
Radary a ukazatele rychlosti	Část zařízení není napojena na žádný SW
LED dopravní značky	Bez napojení na SW
Blikače (BLK)	Bez napojení na SW
Parkovací systémy (PAR)	SW GP WEB interface	GREEN Center s.r.o.	Zhotovitel prověří využití stávajícího webového rozhraní pro integraci
Parkovací čidla (ZTP)	Mobilní aplikace ZTP Parking	Astat	Zhotovitel vytvoří rozhraní pro integraci
Vážení vozidel (VAZ)	SW Unicam Discoverer	CAMEA, spol. s r. o.	Zhotovitel prověří možnosti využití stávajícího rozhraní
Optické kabely (OK)	Bez napojení na SW
Optické kabely v metru (OKM)	Bez napojení na SW
Bezdrátové trasy	Bez napojení na SW
Kontrola výšky vozidel (KVV)	SW Unicam Discoverer	CAMEA, spol. s r. o.	Zhotovitel prověří možnosti využití stávajícího rozhraní
Oblastní dopravní řídící ústředna (ODŘÚ)	SW Scala	Siemens, s.r.o.	Zhotovitel prověří možnost integrace na stávající rozhraní ODŘÚ
Oblastní dopravní řídící ústředna (ODŘÚ)	SW VRS5000	SWARCO TRAFFIC CZ, s.r.o.	Zhotovitel prověří možnost integrace na stávající rozhraní ODŘÚ
Řídící centra* (HDŘÚ, Malovanka, Strahov)	ŘS HDŘÚ	VARS BRNO, a.s.	Existuje servisní webová aplikace, Zhotovitel vytvoří rozhraní pro integraci
Řídící centra* (HDŘÚ, Malovanka, Strahov)	SW Kerberus pro řídicí systém a vizualizaci dopravních a technologických stavů.	ELTODO, a.s.	Zhotovitel prověří možnosti využití stávajícího rozhraní

* Nová kategorie telematických zařízení ke správě v rámci nového Systému. Bude obsahovat aktuálně evidované systémy řízení v tunelech a další řídící centra.

Pokud nebude možné Systém na některý z výše uvedených informačních systémů plnohodnotně integrovat, ať již z jakýchkoli důvodů neležících na straně Zhotovitele (např. vzhledem k nedostupnosti dokumentace integrovaného prvku, nemožnosti zajistit nutnou spolupráci některé z třetích stran prostřednictvím Objednatele, nepřekonatelným překážkám technického, licenčního či obdobného charakteru atp.), vytvoří Zhotovitel příslušné rozhraní do nejširší možné míry, kterou mu dané omezení nebo překážka umožní. Zhotovitel vždy vypracuje technickou a procesní analýzu a zpracuje systémové funkční a nefunkční požadavky na rozhraní a vypracuje návrh rozhraní včetně způsobu a pomůcek (záslepky, simulátory, nástroje atp.) pro jeho otestování a rozhraní včetně souvisejících nástrojů realizuje. Další postup funkčního a integračního či jiného testování a způsob vlastního napojování a zprovozňování dohodne konkrétně s Objednatelem pro každý takový jednotlivý případ. Postup navržený Xxxxxxxxxxxx vždy podléhá odsouhlasení Objednatelem. Nebudou-li realizační činnosti vůbec možné ani v přiměřené a rozumně využitelné míře technického vyhotovení, pak Zhotovitel po dohodě a odsouhlasení Objednatele zpracuje alespoň analytickou a návrhovou dokumentaci spolu s podrobným popisem kroků a činností, jejichž realizace povede k dokončení daného rozhraní (i třetí stranou), jakmile to uvolnění omezení nebo odstranění překážek dovolí. Systém bude koncipován jako škálovatelné řešení používající webové a mobilní klienty. Bude to modulární řešení založené na servisně orientované architektuře. Systém bude rozdělen do tří hlavních částí, jimiž budou interní část, veřejná část a mobilní aplikace s možností off-line provozu. Systém bude vybudován jako řešení pracující s vysokou dostupností a bude zajišťovat odpovídající bezpečnost dat a jejich důvěryhodnost. Bude jej možné provozovat na sdílené technické infrastruktuře TSK.

Systém bude pracovat s prostorovými a popisnými daty. Bude uživatelsky konfigurovatelný formou metadat pro snadnou modifikovatelnost jakékoliv jeho vrstvy. Konfigurace budou moci samostatně provádět vyškolení uživatelé, kteří budou takto nastavovat uživatelské formuláře, datové struktury, atributy a vztahy mezi entitami. Systém bude obsahovat uživatelsky konfigurovatelné řízení pracovních toků (workflow). Bude možno uživatelsky nastavovat validační pravidla a kontroly ve vstupních formulářích, nastavovat texty dialogů a dalších podobných prvků interakce s uživateli. Systém bude zajišťovat vhodnou úroveň bezpečnosti a nastavení rolí a oprávnění. Přístup k datům bude řiditelný s ohledem na datové entity, jejich logické celky, databázové řádky až na jednotlivé atributy.

Systém bude obsahovat prvky pro správu dokumentů a obsahu pro správu strukturovaných i nestrukturovaných dat. Součástí bude i komponenta řízení pracovních toků a oběhu dokumentů a případně také nástroje pro podporu týmové spolupráce.

Systém umožní pracovat s pasportizovanými objekty promítnutými do geografického informačního systému a bude schopen si vyměňovat geografická i zvolená provozně-technická data s okolím či je publikovat pro využití laickou i odbornou veřejností. Zhotovitel umožní využívat dostupná data z prostředí internetu, např. mapy, datové sady apod. při využití obvyklých standardů.

Mobilní aplikaci bude možné provozovat na běžných mobilních platformách a zařízeních s responzivním designem a možností práce s gesty a dotykovou obrazovkou. Aplikace umožní překlenovat krátkodobé výpadky spojení při práci v terénu.

Kompletní přehled technických požadavků je definován v katalogu technických požadavků uvedeném níže. V tomto katalogu je rovněž indikováno, které požadavky jsou považovány za minimální ve smyslu § 72, odst. 3 zákona o zadávání veřejných zakázek a není je tak možné v rámci jednání o předběžných nabídkách inovačního partnerství modifikovat. Ostatní požadavky bude možné, na základě výstupů jednání o předběžných nabídkách inovačního partnerství, modifikovat.

Zhotovitelé ve svých nabídkách přiměřeně, avšak dostatečně podrobně a pochopitelně popíší, jakým způsobem navrhují zajistit požadavky uvedené v katalogu technických požadavků.

Katalog technických požadavků na Systém

Detailní parametry Systému dle uvedeného katalogu Zhotovitel podrobně analyzuje a rozpracuje do větší míry detailu (např. provede rozklad technických požadavků na detailní požadavky systémového, procesního, výkonnostního, bezpečnostního či obdobného charakteru apod.) v Implementační studii.

Záměrem TSK je nalezení inovativního řešení pro Systém správy Telematického majetku v Praze. K naplnění požadovaného záměru je nezbytné vyvinout centrální informační Systém pro správu Telematického majetku, který poskytne evidenční přehled všech typů technických koncových zařízení a souvisejících softwarových nástrojů. Systém bude umožňovat zejména evidenci dat, vyhledávání a filtrování informací, ukládání dokumentace a všech originálních příloh (např. DSPS), automatické kontroly validity, tvorbu manažerských reportů a sestav. Systém bude fungovat na mapovém podkladu, kde budou zanesena všechna dostupná telematická zařízení, včetně všech důležitých a dostupných údajů. Telematický majetek bude podroben úvodní fyzické pasportizaci v terénu v rozsahu definovaném v kapitole 4.1, čímž budou sjednoceny pasporty jednotlivých zařízení a částečně nahrazeny (obnoveny) také stávající nesourodé pasporty.

Zamýšlený informační Systém bude představovat ucelený nástroj pro správu majetku (cizím termínem Asset Management) telematických systémů (zařízení a souvisejících SW nástrojů) ve vlastnictví hl. m. Prahy, jež jsou provozovány TSK. Funkcionality Systému budou umožňovat jednotnou evidenci záruk, servisních parametrů, servisních kontaktů, výkonů údržby a notifikovat uživatele při blížícím se konci životnosti či potřeby pravidelné revize zařízení. Výstupy a údaje uložené v Systému poslouží jako podklad pro údržbu zařízení a plánování servisních zásahů. Systém vedle vedení evidence potřebné pro správu majetku současně umožní sledování stavu zařízení formou jejich monitoringu, sledování provozních stavů za účelem předcházení poruch a výpadků, provádění jejich diagnostiky a bude aktivně upozorňovat obsluhu v případě poruchového chování. Systém bude vyhodnocovat vývoj stavu telematických zařízení a bude obsahovat funkce pro optimalizaci životního cyklu telematických zařízení. Objednateli tak poskytne komplexní podklady pro plánování údržby a revizí stávajících telematických zařízení a pro stanovení požadavků na nově pořizovaný Telematický majetek.

V Systému budou evidovány všechny parametry jednotlivých telematických zařízení, které TSK aktuálně eviduje. Tyto parametry jsou uvedeny v tabulce č. 1 v kapitole 3.1. Nad rámec aktuálně evidovaných parametrů pak budou nově pro všechna telematická zařízení evidovány minimálně tyto další údaje:

Servisní kontakt
Parametry SLA
Předpoklad budoucí obnovy
Datum revize*
Historie revize*
Plánovaná revize*
Deník servisních zásahů
Deník incidentů
Smluvní vztah definující parametry napájení (u telematických zařízení, která jsou napájena)
Informační systém obsluhující dané zařízení

* Není požadováno evidovat pro optické kabely, optické kabely v metru, optické trubky a optické trubky v metru.

Aktuální i nové parametry budou v Systému evidovány pro všechna pasportizovaná telematická zařízení i jejich komponenty, jež jsou definovány dle „hloubky pasportizace“ v kapitole 4.1, za předpokladu, že bude parametr pro danou komponentu relevantním.

V tabulce č. 5 jsou pak uvedeny další parametry, které Objednatel požaduje nově evidovat pro vybraná telematická zařízení. Objednatel požaduje, aby všechny parametry evidované pro telematická zařízení a jejich komponenty byly detailně specifikovány v Implementační studii.

Tabulka 5: Další parametry vybraných telematických zařízení k evidenci

Typ zařízení	Další parametry k evidenci
Světelně řízení křižovatky (SSZ)	Typ připojení (protokol) Smluvní vztah definující parametry napájení Doba provozu Preference BUS Preference tramvají Preference IZS
Měření úsekové rychlosti (MÚR)	Platnost certifikace
Měření okamžité rychlosti (MOR)	Platnost certifikace
Optické kabely (OK)	Počet vláken
Optické kabely v metru (OKM)	Počet vláken
Bezdrátové trasy	Druh a typ přenosu Způsob povolení ČTÚ (pásma / registrace)
Řídící centra* (HDŘÚ, Malovanka, Strahov)	Externí inv.číslo Číslo Městská část Katastr Sektor Ulice Ul. úsek I Ul. úsek II Identifikátor Popis Umístění Servisní organizace Servisní kontakt Parametry SLA Předpoklad budoucí obnovy Datum revize Historie revize Plánovaná revize Deník servisních zásahů Deník incidentů Rozloha [m2] Počty rackových skříní Napájení Smluvní vztah definující parametry napájení Chlazení Smluvní vztah definující parametry chlazení Zálohování napájení Velkoplošné zobrazení

* Nová kategorie telematických zařízení ke správě v rámci nového Systému. Bude obsahovat aktuálně evidované systémy řízení v tunelech a další řídící centra.

Pro správu telematických zařízení a zadávání aktualizovaných údajů (automatizovaně i manuálně) Zhotovitel rovněž vytvoří aplikaci (webovou i mobilní), jejímž prostřednictvím mohou být zadávány údaje o aktuálním stavu či funkčnosti zařízení nebo jejich případném poškození, a to přímo z terénu. Aplikace poskytne jednotné rozhraní pro zjištění aktualizovaných údajů o evidovaných zařízeních, jejich zobrazení a filtraci dle definovaných parametrů a umožní zadávání parametrů a stavů výběrem z předdefinovaných číselníků a seznamů hodnot.

Systém se celkově stane hlavním nástrojem pro pasportizaci a správu Telematického majetku TSK, umožní úvodní i následnou pasportizaci HW zařízení a souvisejících SW nástrojů, migraci dat z aktuálních evidenčních systémů či pravidelnou aktualizaci dat.

Kompletní přehled funkčních požadavků je definován v katalogu funkčních požadavků uvedeném níže. V tomto katalogu je rovněž indikováno, které požadavky jsou považovány za minimální ve smyslu § 72, odst. 3 zákona o zadávání veřejných zakázek a není je tak možné v rámci jednání o předběžných nabídkách inovačního partnerství modifikovat. Ostatní požadavky bude možné, na základě výstupů jednání o předběžných nabídkách inovačního partnerství, modifikovat.

Zhotovitelé ve svých nabídkách, resp. předběžných nabídkách, přiměřeně, avšak dostatečně podrobně a pochopitelně popíší, jakým způsobem navrhují zajistit požadavky uvedené v katalogu funkčních požadavků.

Katalog funkčních požadavků na Systém

Detailní návrh funkčních parametrů Systému vypracuje Zhotovitel po analýze funkčních požadavků uvedených v katalogu a jejich rozpracování do větší míry detailu (např. rozpadem do soustavy podrobnějších požadavků) v Implementační studii.

Zhotovitel jako součást realizace budoucího Systému rovněž zajistí všechny technické a organizační podmínky spolu s vytvořením potřebných nástrojů, pomůcek nebo integrací, provedením potřebných školení, nastavením procesů a kontrolních mechanismů, které jsou nezbytné pro hladké zahájení poskytování Služeb Komplexní podpory následně po Uvedení systému do provozu.

Obecné podmínky poskytování Služeb Komplexní podpory jsou určeny několika základními prvky. Jednak to jsou kalendáře poskytování Služeb Komplexní podpory, určující časový režim jejich poskytování. Dále to je 5ti stupňová škála definující různou závažnost incidentů a požadavků. K jednotlivým stupňům závažnosti jsou přiřazeny lhůty pro reakci a lhůty pro vyřešení příslušného incidentu či požadavku. A konečně pro jednotlivé stupně závažnosti jsou definována pravidla pro určení výše slevy pro případ neplnění stanovených podmínek.

Služby Komplexní podpory budou Zhotovitelem poskytovány v souladu definicí Služeb Komplexní podpory uvedených v katalogovém listu příslušné Služby Komplexní podpory a tamtéž uvedenými kvalitativními atributy a vlastnostmi dané Služby Komplexní podpory, které představují sjednanou úroveň poskytované Služby Komplexní podpory. Kontrolu poskytovaných Služeb Komplexní podpory bude pravidelně provádět Objednatel. Hodnoceným vyhodnocovacím obdobím je jeden kalendářní měsíc.

Zhotovitel je povinen se řídit zákonnými, technickými a jinými požadavky, pravidly a doporučeními, souvisejícími s poskytovanými Službami Komplexní podpory, spravovanou nebo využívanou infrastrukturou a využívanými nebo poskytovanými službami Objednatele či třetích stran.

Zpracování informací, podkladů a dat pro hodnocení Služeb Komplexní podpory je součástí plnění Zhotovitele. Absence takových informací, podkladů a dat je považována za prokázanou nedostupnost Systému. Veškeré výkazy, podklady a dokumenty musí být ve formě umožňující přezkoumatelnost a auditovatelnost Objednatelem a kontrolními institucemi, což jsou veškeré subjekty oprávněné provádět kontrolu jakkoliv se týkající plnění Zhotovitele na základě právního předpisu. Zhotovitel je povinen bezplatně poskytnout součinnost Objednateli související s odbornými, zákonnými a jinými kontrolami a audity, které mohou být uplatňovány vůči Objednateli v souvislosti s poskytnutím Služeb Komplexní podpory a Systémem jako takovým. Zhotovitel je také povinen po předchozím upozornění umožnit kdykoliv fyzickou kontrolu v místech, která souvisejí s poskytováním Služeb Komplexní podpory. Je-li nějaký dokument, výkaz nebo jiný podklad související s jiným dokumentem zpochybněn kontrolní organizací, je Zhotovitel povinen poskytnout podklady, které budou kontrolním orgánem akceptovány. Pokud nebude Zhotovitel schopen takové podklady dodat či takové podklady nebudou kontrolním orgánem akceptovány a bude-li jejich absence důvodem k udělení postihu vůči Objednateli, jedná se podstatné porušení povinnosti Zhotovitele.

Prokázání, že k nedostupnosti Systému či přerušení či zhoršení kvality poskytování Služeb Komplexní podpory došlo vinou vnějšího vlivu (mimo působnost Zhotovitele) nebo nesoučinností Objednatele je povinností Zhotovitele. Nejsou-li doklady prokazující příslušné skutečnosti doručeny jako součást podkladů pro hodnocení Služeb Komplexní podpory za příslušné vyhodnocovací období, je nedostupnost přerušení či zhoršení kvality poskytování Služeb Komplexní podpory přičítána k tíži Xxxxxxxxxxx.

Pokud Zhotovitel dodal v rámci svého řešení i nějaký standardní komerční software nebo otevřený software, pro nějž Zhotovitel poskytuje komerční podporu jejich výrobce, pak je Zhotovitel zodpovědný za řešení incidentů či požadavků bez zbytečných prodlev v rozsahu jejich analýzy, návrhu variant řešení, zajištění komunikace s útvarem podpory příslušného produktu (jeho výrobce, distributora atp.) a pokud je to požadováno Objednatelem, pak také zajištění dočasného náhradního řešení a zajištění jeho schválení Objednatelem. Podpora produktů bez uvedené komerční podpory je považována za nedílnou součást Komplexní podpory Systému vytvořeného Zhotovitelem a tudíž i tato podpora musí splňovat sjednané parametry kvality.

V případě dopadu nefunkčnosti jednoho či více spolupracujících systémů na funkčnost Systému je výsledné omezení sjednané úrovně Služeb Komplexní podpory vyloučeno z hodnocení úrovně Zhotovitelem poskytovaných Služeb Komplexní podpory. Nicméně i v tomto případě je Xxxxxxxxxx povinen na vyžádání Objednatele zajistit vhodné dočasné náhradní řešení.

Ve všech uvedených případech je Zhotovitel spoluzodpovědný za řešení incidentů a záznamu o provedených činnostech, je povinen spolupracovat při analýze incidentů, a v případě požadavku schváleného Objednatelem také spolupracovat na řešení nebo přípravě dočasného náhradního řešení. Dokud není jednoznačně určena příčina incidentu ležící mimo oblast odpovědnosti Zhotovitele, analyzuje a řeší Zhotovitel incident jako by to byl incident spadající plně do jeho sféry řešení v rámci sjednaných úrovní Služeb Komplexní podpory.

V rámci poskytování Služeb Komplexní podpory je Zhotovitel odpovědný za kontroly a návrhy změn konfigurace, kontroly a analýzy žurnálů a logů, ladění a optimalizaci Systému, preventivní a proaktivní údržbu potřebnou k předcházení incidentům a veškeré další administrátorské činnosti na aplikační úrovni potřebné pro Komplexní podporu Systému. Zhotovitel je povinen na základě analýzy incidentů navrhovat, a po schválení Objednatelem na úrovni Systému implementovat nové způsoby monitorování a bezpečnostního dohledu s cílem zrychlit detekci incidentů. Zhotovitel je dále povinen navrhovat a po schválení Objednatelem provádět aktualizace, aplikovat bezpečnostní záplaty či povyšovat verze použitých programů, nástrojů a softwarových komponent s cílem udržet aktuálnost a bezpečnost Systému.

Zhotovitel není zodpovědný za řešení incidentů souvisejících s nefunkčností infrastruktury nebo některých jejích částí v odpovědnosti Objednatele.

Objednatel požaduje, aby Komplexní podpora byla organizována podle obvyklého tříúrovňového modelu, jak je uvedeno spolu s rozdělením odpovědností v následující tabulce.

Tabulka 6: Úrovně Komplexní podpory

Úroveň podpory	Popis	Zajišťuje
Úroveň podpory	Popis	Objednatel	Zhotovitel
L1	Pracoviště HelpDesk, které zabezpečuje příjem hlášení všech incidentů či požadavků a jejich vstupní zpracování a prvotní kontrolu. Jsou-li schopnosti na této první úrovni podpory dostačující, pak incident či požadavek vyřeší. Pokud řešení incidentu či požadavku převyšuje schopnosti této úrovně podpory, pak je incident či požadavek předán řešitelům z řad autorizovaných interních uživatelů (tzn. pracovníků Objednatele nebo Objednatelem zmocněných osob). Pokud řešení incidentu či požadavku nelze vyřešit autorizovanými interními uživateli, pak je incident či požadavek předán na vyšší úroveň podpory. První úroveň podpory zajišťovaná Objednatelem funguje přiměřeně i pro externí uživatele (např. pro autorizované uživatele spolupracujících systémů).	Objednatel
L2	První vrstva podpory zajišťovaná pracovníky Zhotovitele. Pracovníci této úrovně mají hlubší znalosti a větší specializaci ve svěřené oblasti. Jsou schopni řešit složitější problémy a hledat jejich řešení. Jsou schopni již pracovat s různými technickými prostředky a diagnostickými nástroji, vyhledávat a identifikovat chyby v datech a systémech. V případě metodické podpory mají již podrobnější znalosti z oblasti metodiky a legislativy. Pracovníci této úrovně provádějí diagnózu a vyšetření incidentu a posuzují incident z hlediska dopadu na ostatní systémy. Zároveň spolupracují s provozovateli spolupracujících či návazných systémů, portálů a aplikací při řešení incidentů napříč těmito systémy. Rozhodují o předání incidentu či servisního požadavku k řešení dalším řešitelským skupinám. Ověřuje získané informace a stav řešení na úrovni podpory L1. Provádějí vyšetření a diagnózu incidentu na své úrovni. Pokud není incident možno vyřešit na této 2. úrovni, je předán na 3. úroveň podpory dle závažnosti incidentu.		Zhotovitel
L3	Druhá vrstva podpory zajišťovaná pracovníky Zhotovitele, kteří provádějí vysoce specializované činnosti, např. metodicko-technické analýzy složitých problémů. Jedná se o technické specialisty či řešitelské týmy ZhotoviteleZhotovitelZhotovitel. Zodpovídá za zpracování a vyřešení nejtěžších incidentů a požadavků. Podpora úrovně L3 přejímá zpracované problémy z podpory úrovní L1 a L2. S koncovými uživateli komunikuje jen ve zcela výjimečných případech, typicky v případech, nejsou-li znalosti na úrovni podpory L1 a L2 dostatečné pro analýzu. Zodpovídá za finální vyřešení incidentu či požadavku, ať už řešení zahrnuje komunikaci s výrobci software, hardware či jiných prvků nebo Zhotoviteli služeb atp., ať jde o opravu nebo výměnu hardwaru, opravu či doprogramování kódu, instalaci nezbytných programů apod. Specialisté na této úrovni podpory provádějí vyšetření, diagnózu a odstraňování incidentů. Zároveň spolupracují s provozovateli spolupracujících či návazných systémů, portálů a aplikací při řešení incidentů napříč těmito systémy. Zajišťují odbornou pomoc nižším úrovním podpory. Tvoří strategie podpory a servisu. Mají vliv na další rozvoj ve svěřených oblastech nebo tento rozvoj přímo řídí. Do podpory na této úrovni vstupuje jako jeden subjekt také útvar ICT Objednatele a dále metodičtí pracovníci Objednatele, kteří řídí rozvoj, zpracovávají požadavky na nové funkce či změny nebo připravují koncepce a plány.		Zhotovitel

Zhotovitel povede při poskytování Služeb Komplexní podpory provozní deník, do něhož budou zaznamenávány příslušné události bez zbytečného odkladu, a to nejdéle do 1 pracovního dne od výskytu dané události. Provozní deník bude jeden společný pro celý Systém a všechny jeho součásti. Bude technicky realizován v prostředí Objednatele (např. vhodně strukturovanými záznamy v HelpDesku, jako dokument uložený ve sdíleném úložišti či jinak dle návrhu Zhotovitele). Každý záznam v Provozním deníku bude obsahovat alespoň datum a čas jeho pořízení, identifikaci osoby, která záznam pořídila, označení dotčené služby Komplexní podpory (tzn. identifikátor služby podle příslušného katalogového listu služby), datum a čas začátku události a datum a času vyřešení v případě událostí, jejichž řešení přesáhlo jednu hodinu, popis události, popis provedených úkonů v rámci řešení události s vyznačením času jejich provedení a příp. také délky jejich provádění, označení zadávacího listu služby rozšířené podpory, pokud Zhotovitel provádí nějaký zásah v souvislosti s činnostmi podle zadání Objednatele. Do provozního deníku budou zaznamenávány všechny významné události, např.:

Provedení úkonů předepsaných definicemi jednotlivých služeb tak, jak budou uvedeny v jejich katalogových listech
Havarijní stavy, opravy, servisní zásahy
Odstavení služeb, byť dočasné
Zprovoznění nové služby
Výměny či aktualizace programových komponent či jiných prvků Systému
Anomálie a nestandardní stavy Systému s dopady na plnění parametrů kvality poskytovaných služeb
Spuštění, vypnutí či restart služeb
Obnova ze zálohy

Při poskytování Služeb Komplexní podpory povede Zhotovitel záznamy o všech provedených pracích (a to i těch, které byly provedeny a nezaznamenávají se do provozního deníku, např. aktualizace dokumentace, poskytnutí konzultace na vyžádání, účast na jednání apod.) ve formě výkazu poskytnutých Služeb Komplexní podpory. Tento výkaz bude Zhotovitel předávat Objednateli spolu s ostatními podklady za uplynulé vyhodnocovací období. Jednotlivé záznamy ve výkazu poskytnutých Služeb Komplexní podpory budou obsahovat, datum a čas provedené činnosti, délku provádění činnosti (v hodinách nebo člověkodnech), identifikaci pracovníka, který činnost provedl, stručný a výstižný popis provedené činnosti.

Kontrolu poskytovaných Služeb Komplexní podpory provádí Objednatel podle kvalitativních atributů a vlastností Služeb Komplexní podpory uvedených v katalogových listech příslušných služeb Komplexní podpory. Nebyla-li služba Komplexní podpory poskytnuta v souladu s jejími kvalitativními atributy a vlastnostmi, ať již pro danou službu specificky uvedenými v příslušném katalogovém listu nebo obecně stanovenými ve smlouvě, pak Objednatel může uplatnit své právo na odpovídající slevu (a příp. též na sankci) za hodnocené vyhodnocovací období.

Objednatel požaduje, aby Služby Komplexní podpory byly poskytovány v kalendářním režimu podle charakteru a priorit služeb Komplexní podpory. Struktura a náplň služeb Komplexní podpory včetně zařazení do kalendářů s ohledem na požadavky uživatelů a provozní i nákladovou efektivnost bude navržena Zhotovitelem. Výchozí základní kalendář je uveden v následující tabulce.

Tabulka 7: Kalendář poskytování služeb Komplexní podpory

Kalendář	Režim kalendáře
8x5	Pracovní dny od 8:00 do 16:00

Uvedený režim kalendáře se použije pro stanovení počtu dnů v týdnu či měsíci (příp. hodin či minut) pro potřeby výpočtů dostupnosti služeb. Pracovní dny jsou dny mimo sobot, nedělí a státních svátků a ostatních svátků dle příslušného právního předpisu.

Objednatel požaduje, aby Zhotovitel v rámci návrhu a zajištění technických a organizačních podmínek potřebných pro poskytování Služeb Komplexní podpory (v rámci Implementační studie) definoval každou službu Komplexní podpory svým katalogovým listem podle uvedeného vzoru.

Tabulka 8: Katalogový list služby Komplexní podpory

Katalogový list služby Komplexní podpory
Identifikátor služby	Jednoznačné kódové označení služby
Název služby	Krátký, ale výstižný název služby
Popis služby	Výstižný popis náplně služby
Kvalitativní indikátor služby Komplexní podpory
Identifikátor indikátoru	Jednoznačné kódové označení kvalitativního indikátoru
Definice	Definice kvalitativního parametru služby
Parametry kvalitativního indikátoru služby Komplexní podpory
Kalendář služby	Označení kalendáře poskytování služby
Obnovení služby	Odkaz na obecně platné požadavky na obnovu služby nebo specifické hodnoty obnovy
Definice dílčích parametrů indikátoru kvality služby	Jednotlivé proměnné a jejich definice, které vstupují do vzorce výpočtu dostupnosti
Způsob výpočtu	Vzorec výpočtu dostupnosti spolu s jeho definicí a popisem způsobu výpočtu
Měřicí bod	Místo v Systému (např. rozhraní), kde se parametry indikátoru kvality služby zjišťují
Způsob dokladování	Definice podkladů, z nichž se berou indikátory pro výpočet
Sleva z ceny	Odkaz na obecně platné požadavky na slevu nebo specifické hodnoty a způsob stanovení slevy
Doplňující informace
Poznámka	Doplňující poznámky a vysvětlení
Platební podmínky	Odkaz na obecná smluvní ustanovení nebo definice specifického režimu

Při řešení incidentů a požadavků je Zhotovitel povinen dodržet stanovené lhůty. Lhůty pro reakci a pro obnovení se řídí podle závažnosti incidentu.

K řešení incidentů a požadavků je možno využít servisního okna. Plánované činnosti nebo jiné předvídatelné úkony musí být koordinovány s Objednatelem v dostatečném předstihu. Lhůty platné pro řešení incidentů jsou souhrnně v následující tabulce.

Tabulka 9: Lhůty pro řešení incidentů a požadavků

Závažnost incidentu / požadavku	Definice závažnosti incidentu / požadavku v provozním prostředí	Lhůty pro řešení incidentu / požadavku
Závažnost incidentu / požadavku		Reakce	Obnovení
Priorita 1 Kritická	Užívání Systému nebo jeho důležité a ucelené části není možné Některé nebo všechny části Systému selhaly a jsou zcela nedostupné, poskytují vyšší než povolenou odezvu, jsou nefunkční nebo je jejich funkčnost omezena tak, že je kritickým způsobem ovlivněna činnost Systému Provoz Systému je zastaven	30 min	8 hodin
Priorita 2 Vysoká	Činnost Systému je podstatně omezena, některé části jsou nedostupné, poskytují zhoršenou odezvu, selhaly a jsou zcela nefunkční nebo je jejich funkčnost omezena tak, že je zásadním způsobem ovlivněna činnost Systému; není dostupná jedna instance Systému	1 hodina	12 hodin
Priorita 3 Střední	Systém je funkční pouze částečně, Systém je ovlivněn selháním nebo omezením některé ze systémových funkcí podporujících důležité činnosti Systému Některá ze služeb Systému vykazuje funkční vady, pouze některé funkce nejsou plně funkční Provoz Systému je sice incidentem omezen, ale činnosti mohou pokračovat určitou dobu stanoveným náhradním způsobem Některé napojené systémy a agendy vykazují zhoršenou odezvu, některé jejich funkce nejsou dostupné	90 minut	24 hodin
Priorita 4 Nízká	Systém je funkční, incident nemá vliv na činnost Systému Vyskytují se nedostatky nepodstatné povahy, které způsobují například nižší komfort obsluhy nebo zvýšenou pracnost činností nad rámec pracnosti obvyklé v běžném provozu Provoz je ovlivněn, ale může pokračovat jiným způsobem, např. za pomoci vhodných organizační opatření Závažnost zároveň odpovídá situacím, kdy sice některé funkce selhaly, ale nejsou v daný moment využívány nebo nemají žádný vliv na řádný chod Systému nebo je mírně zvýšena odezva Systému	2 hodiny	5 dnů
Priorita 5 Ostatní	Závažnost situace není vázána na incident Systému, ale jedná se o žádost na získání informací ohledně Systému, podání nějaké informace, požadavek na vysvětlení, informace o parametrech, nastavení Systému či jeho funkcích Závažnost také zahrnuje situace, kdy některé funkce sice prokazatelně selhaly, ale nejsou v daný moment využívány nebo nemají žádný vliv na řádný chod Systému, za předpokladu, že řešení požadavku závisí na součinnosti třetí strany mimo vliv Zhotovitele	2 hodiny	7 dnů

Jako součást návrhu a zajištění technických a organizačních podmínek potřebných pro poskytování Služeb Komplexní podpory Zhotovitel zpracuje závazné definice každé jím navrhované služby Komplexní podpory ve formě katalogového listu podle uvedeného vzoru. Dále uvedený popis současně obsahuje minimální požadavky, které navrhované Služby Komplexní podpory musí obsáhnout.

Provoz a údržba funkčních celků (modulů) Systému

Náplní je poskytování Sužeb Komplexní podpory, které představují aktivity spojené s údržbou Systému a opravami, poskytování služeb centra podpory a poskytování konzultací a školení. Součástí jsou mj.

Zajištění provozu, dostupnosti a funkčnosti.
Řešení chybových stavů.
Lokalizace a odstraňování incidentů.
Údržba (maintenance) Systému, včetně zajištění, implementace a instalace aktualizací, záplat a opravných balíčků (patch) či jiných modernizací (update) Software, které tvoří Systém.
Provádění servisních zásahů, a to v plánovaných termínech nebo i jindy na základě vlastních poznatků, nebo na výzvu Objednatele.
Pravidelná kontrola vytížení aplikačních, databázových či jiných serverů (např. využití procesorů, paměti, místa na disku apod.).
Pravidelná kontrola aplikačních a systémových žurnálů serverů.
Pravidelná kontrola podpůrných komponent, nástrojů a systémů z pohledu funkčnosti Systému jako celku.
Úpravy parametrů a konfigurací vyplývající z provozních potřeb či jejich návrhy směrem k provozovatelům příslušných částí.
Vyhodnocování skutečných parametrů funkčních celků, modulů či systémů (odezvy, doba zpracování aj.) v rámci nahlášených incidentů, jejichž předmětem jsou problémy s těmito parametry.
Součinnost při analýze incidentů / požadavků a problémů v připojených systémech Objednatele či spolupracujících subjektů. Předkládání návrhů na optimalizaci.
Definice či úpravy v nastavení směrování, dočasných pamětí, rozhraní, adaptérů s ohledem na připojení systémů Objednatele či spolupracujících subjektů.
Reakce na vnější změny, zejména zajištění kompatibility webových rozhraní a klientských komponent

Pro části přístupné veřejnosti či spolupracujícím subjektům to je kompatibilita s nejméně 3 nejnovějšími verzemi prohlížečů Mozilla Firefox, Internet Explorer, Google Chrome, případně dalších určených dominantních prohlížečů s významným postavením na trhu, které budou předem dohodnuty a specifikovány v provozní a systémové dokumentaci. Přizpůsobení nové verzi prohlížeče musí být připraveno k nasazení do produkčního prostředí nejpozději do 3 měsíců od vydání nové verze daného prohlížeče jeho výrobcem, pokud Objednatel neurčí jinak.
Pro části přístupné interním uživatelům Objednatele to je kompatibilita s konfigurací standardního výpočetního prostředí Objednatele (tzn. konfigurace klientských počítačů).

Součinnost s dodavateli připojených systémů Objednatele či spolupracujících subjektů, poskytnutí podkladů a informací pro připojení. Součinnost při testování a při nasazování do provozního prostředí. Definice požadavků na tyto systémy.
Součinnost při testech po úpravách či zásazích do infrastruktury.
Definice nastavení databází.
Definice požadavků na zálohování a poskytnutí součinnosti provozovateli služby zálohování.
Kontrola dostupnosti záplat, opravných balíčků, oprav atp. od výrobců použitých platforem (dále jen balíček), analýza vhodnosti a potřebnosti implementace balíčku, návrh potřebných opatření a postupů s ohledem na implementace balíčku ke schválení Objednateli, instalace a provedení změn dle Objednatelem schválených návrhů opatření, implementace schválených požadavků na změnu.
Podpora na úrovni L2 a poskytování odborných konzultací, provozní podpora, služby HelpDesku, resp. ServiceDesku poskytovatele služeb Komplexní podpory, dohledové služby, bezpečnostní dohled, součinnost s IT útvarem Objednatele zajišťujícího provoz infrastruktury.
Udržování aktuální Dokumentace Systému včetně aktualizace dokumentace Systému v závislosti na provedených úpravách.
Součinnost při implementaci Objednatelova monitoringu dostupnosti Systému.
Zajištění podpory u výrobců použitých komponent pocházejících od třetích stran.
Správa a aktualizace provozní dokumentace.
Aktualizace provozního deníku.
Účast na jednání provozních a pracovních týmů Objednatele a týmů přizvaných třetích stran.
Součinnost v rámci procesů projektového řízení souvisejících s návrhem a realizací změn či jiných aktivit majících povahu projektů.
Příprava výkazů a podkladů pro vyhodnocení Služeb Komplexní podpory. Administrativní činnosti související s prováděním dílčích činností v rámci poskytování Služeb Komplexní podpory.
Sledování souladu Systému s obecně závaznými právními předpisy a informování Objednatele o případném nesouladu Systému s obecně závaznými právními předpisy a udělování rad Objednateli v tomto směru k dosažení souladu Systému s legislativou.
Aktualizace Systému způsobené změnami obecně závazných právních předpisů (legislativní update); v rámci legislativního update Zhotovitel zajistí aktualizace Systému tak, aby vyhovovaly aktuálnímu znění a účinným právním předpisům České republiky anebo vyhovoval jiným požadavkům Objednatele, přičemž legislativní update musí být dodán nejpozději do 1 měsíce poté (případně v jiném termínu dostatečně předem schváleným Objednatelem), co příslušná změna legislativy vstoupí v platnost (jedná se hlavně o změnu technických předpisů).
Uživatelská podpora – jedná se o on-line a off-line služby zahrnující telefonickou a elektronickou komunikaci pomocí HelpDesk s uživateli:
- Telefonická podpora on-line – telefonickou podporou on-line se rozumí odpovídání na dotazy uživatelů v režimu 8x5,
- Podpora off-line – podpora off-line zahrnuje rady, doporučení a informace, které pomohou vyřešit problémy s používáním Systému přístupná 24/7 s reakcí do dalšího pracovního dne.
Konverze dat, exporty/importy dat od externích zpracovatelů.
Drobné úpravy exportů a jiných výstupů Zhotovitelem, aktualizace a synchronizace aplikačních částí Systému.
Aktualizace nastavení parametrů a konfigurací jednotlivých částí Systému.
Administrace uživatelů, správa rolí a oprávnění pro skupiny uživatelů.
Zajišťování automatizovaného exportu/importu dat do Systému mimo běžné úkony.

Dostupnost je hodnocena na základě příslušných nahlášených incidentů podle jejich kategorií závažnosti.

Odezva uživatelského rozhraní

Odezvou uživatelského rozhraní se rozumí veškeré funkce, aktivity a činnosti přístupné uživatelům prostřednictvím aplikací, webového uživatelského rozhraní či jiné formy uživatelského rozhraní. Všechny požadavky vznesené prostřednictvím uživatelského rozhraní jsou odpovězeny v požadovaném čase, který je nižší nebo se rovná času standardní odezvy, resp. času maximální odezvy, přičemž počet požadavků zodpovězených v čase standardní odezvy vůči všem zodpovězeným požadavkům musí být větší nebo roven procentnímu poměru danému hodnotou minimálního výskytu standardní odezvy.

Popis jednotlivých měřených rozhraní, přístupových či měřících bodů a scénáře měření navrhne Zhotovitel. Klíčové údaje budou součástí nefunkčních požadavků, které budou Zhotovitelem analyzovány a zpracovány v úvodní části realizace během první etapy projektových prací (v rámci Implementační studie). Stanou se posléze vstupy do přípravy testování a budou použity při jeho vyhodnocení. Budou též zapracovány do provozní dokumentace, kde budou představovat jednu skupinu z cílových měřených provozních parametrů Systému. Scénáře měření budou navrženy tak, aby řádně prověřily odezvu příslušného rozhraní. Pokud se scénář měření nepodaří kompletně dokončit nebo doba provádění scénáře měření (či libovolného z měřených kroků, které jsou měřeny v rámci daného scénáře) překročí čas maximální odezvy, bude provedení tohoto scénáře měření považováno na neúspěšné. Pokud dojde k neúspěšnému provedení dvou bezprostředně po sobě následujících scénářů měření, bude časový úsek od konce provedení prvního scénáře měření až do konce provedení druhého scénáře měření považován za dobu nedostupnosti rozhraní.

Ukončení nedostupnosti je dáno okamžikem prvního následujícího úspěšného scénáře měření. Doba nedostupnosti se v rámci vyhodnocovacího období celkově načítá. Na začátku každého vyhodnocovacího období se celková doba nedostupnosti vynuluje.

Odezva uživatelského rozhraní bude vyhodnocována v 15minutových intervalech monitorovacím systémem Objednatele, bude-li v době realizace vhodný monitorovací systém Objednatelem k dispozici. Nebude-li vhodný systém Objednatele pro automatizované měření k dispozici, bude odezva uživatelského rozhraní vyhodnocována alternativním způsobem podle návrhu Zhotovitele, např. formou zjišťování zpětné vazby od uživatelů a pravidelně prováděným ručním měřením v dohodnutém režimu. Objednatel požaduje, aby základní odezva Systému vůči uživateli (application response time) se pohybovala do 3 sekund.

Dostupnost rozhraní dosažená v rámci vyhodnocovacího období bude vypočtena jako souhrnná provozní doba rozhraní v minutách v rámci vyhodnocovaného období, kdy mělo být rozhraní dostupné, mínus souhrnná doba výpadků rozhraní v minutách, která je dána součtem všech jednotlivých nedostupností rozhraní, děleno souhrnnou provozní dobou rozhraní krát 100 %, aritmeticky zaokrouhleno na 1 desetinné místo (tzn., že 0, 1, 2, 3 nebo 4 se zaokrouhluje dolů, 5, 6, 7, 8 nebo 9 se zaokrouhluje nahoru).

Tabulka 10: Vzor zpracování parametrů dostupnosti prostředí

Typ prostředí a kalendář služby		Dostupnost rozhraní [%]	Čas standardní odezvy [s]	Čas maximální odezvy [s]	Minimální výskyt standardní odezvy [%]
Provozní prostředí
	85	95	3	10	70
Jiné prostředí než provozní (např. testovací)
	85	90	6	20	70

Řízení dílčích vyžádaných služeb Rozšířené podpory

Náplní je poskytování řídicích a koordinačních činností souvisejících s realizací jednotlivých dílčích plnění služby Rozšířené podpory na jejich vyžádání Objednatelem. Služba Rozšířené podpory je poskytována na vyžádání Objednatele a podle specifikace zachycené v zadávacím listu této služby. Služby rozšířené podpory budou poskytovány v maximálním rozsahu 80 člověkodnů pracovníků Zhotovitele ročně. Poskytování řídicích a koordinačních činností pokrývá především následující činnosti:

Projektové řízení dodávky vyžádaného dílčího plnění služby Rozšířené podpory, které zahrnuje koordinaci a řízení dodávky plnění služby, plánování a provádění plánu, řízení rizik a omezení, řízení testů a přejímek, příprava řídicí dokumentace přiměřené rozsahu povaze dílčího plnění služby Rozšířené podpory (např.: záměr, studie, analýza, řízení kvality, specifické postupy a metody apod.), stanovení milníků a kontrolních bodů a definice měřitelných znaků kvality v jednotlivých bodech, průběžné vyhodnocování průběhu plnění a jeho vykazování, řízení kvality dodávky, řízení rizik dodávky.
Organizační zajištění dodávky vyžádaného dílčího plnění služby Rozšířené podpory, které zahrnuje zajištění porad a jednání přiměřených jejich zaměřením a rozsahem povaze dílčího plnění služby Rozšířené podpory, zajištění pozvánek na porady všem zúčastněným, přiřazení a kontrola úkolů a odpovědností, řízení průběhu jednání, pořizování a distribuce zápisů z jednání, rozeslání zápisů k připomínkám zúčastněných a vypořádání připomínek, včasné oznámení případných změn v organizaci, příprava a kompletace podkladů pro jednání i pro plnění služeb, vedení projektového úložiště (ukládání projektové dokumentace, kontrola atp.), správa seznamu kontaktů a komunikační matice, vedení pomocných projektových registrů a evidencí.
Příprava podkladů a výkazů o provedených službách Rozšířené podpory.

Podpora komponent třetích stran

Obsahem je zajištění podpory pro Zhotovitelem dodané komponenty třetích stran, kterou poskytují jejích výrobci. Její náplní je technická podpora (maintenance) a podpora těchto komponent včetně aktualizací a zajištění přístupu k dalším službám poskytovaných výrobci, tedy mj.:

Přístup k opravám a záplatám nabízených řešení.
Přístup k novým verzím nabízených produktů, které mají souvislost s dodanými komponentami.
Přístup do znalostní báze příslušných výrobců a k oddělení podpory příslušných výrobců, např. pro dotazy při řešení problémových stavů, konzultace při administraci a konfiguraci, dotazy k licenční politice, plánovaných funkcích v nových verzích apod.
Obnova podpory u výrobce (provedení platby, uzavření smlouvy s výrobcem aj.), např. ke konci období, když je podpora uzavírána na určitou dobu (třeba rok), aby nenastal stav nezajištěné podpory výrobce.
Informování o stavu komponenty a příslušného produktu, např. platnosti podpory a doby jejího trvání, zařazení do plánu podpory, označení verze apod.
Zajištění všech informací a poskytnutí součinností vyžadovaných výrobci příslušných komponent v souvislosti s poskytováním jejich podpory
Vykazování zajištěné podpory vhodnou průkaznou formou, např. odpovědi od výrobců, doklady o registraci podpory, licenční klíče atp.

Kalendář služby je 85. V případě výpadku služby, tzn. nikoliv řádně zajištěné podpory, se jedná o incident se závažností s prioritou 5 (ostatní) a výše slevy se určí podle pravidel uvedených v kapitole 4.4.10.

Podklady pro měření a vykazování služeb

Náplní je předávání údajů a podkladů, které jsou potřebné pro sledování služeb, jejich měření a vykazování, analyzování jejich kvality a průběhu poskytování a vyhodnocování, využívání Systému, jeho součástí či podpůrných komponent využívaných Systémem včetně stavových, výkonnostních, bezpečnostních či provozních údajů, mj.:

Neagregované údaje o všech provedených jednotlivých transakcích, operacích či úkonech provedených k určitému okamžiku či během vyhodnocovacího období.
Neagregované údaje a podklady pro vyhodnocení kvalitativních parametrů poskytovaných služeb a pro související výpočty za vyhodnocovací období.
Agregované údaje o provozním stavu, výkonnosti, bezpečnostních aspektech apod. v online režimu formou datových řezů (nebo jiných dohodnutých způsobů) či jejich předávání na dohodnutá rozhraní (např. systému dohledu).

Data budou předávána v Objednatelem požadované struktuře, formátu, frekvenci, umístění či rozhraní, které budou definovány v technické dokumentaci. Data budou ukládána do datového úložiště Objednatele, odkud je bude moct načítat vhodnými nástroji, nebo budou předávána na dohodnuté rozhraní.

Kalendář služby je 85. V případě výpadku služby, tzn. nikoliv řádně zajištěných podkladů, se jedná o incident se závažností s prioritou 3 (střední).

Neagregované údaje a podklady použité pro vyhodnocení kvalitativních parametrů poskytovaných služeb za určité vyhodnocovací období budou úplné a budou předány nejpozději v okamžiku předání výkazu poskytnutých služeb v tomto vyhodnocovacím období.

Neagregované údaje o transakcích, operacích či úkonech provedených k určitému okamžiku budou úplné a budou k dispozici nejpozději 12 hodin po tomto okamžiku.

Data poskytovaná v online režimu budou úplná a mohou být nejvýše 5 minut stará.

Slevy v případě nedostupnosti služby, tzn. nevyřešení incidentu ve lhůtě podle jeho závažnosti, se určují podle pravidel uvedených v kapitole 4.4.10.

Slevu tvoří celkový součet všech slev dílčích poskytovaných Služeb Komplexní podpory. Cexxxxx xleva se odečítá od Paušálu. Pokud by celková sleva za dané vyhodnocovací období byla vyšší než Paušál, bude neuplatněný nárok na slevu z ceny uplatněn v prvním následujícím měsíci nebo případně dalších měsících. K danému vyhodnocovacímu období může Objednatel uplatnit slevu i později např. z důvodu dodatečně zjištěného nároku na slevu, z důvodu administrativní prodlevy s výpočtem ceny, nepřesností výpočtu slevy apod., přičemž vždy je rozhodné právě jen to, zda Objednateli vznikl nárok na slevu z ceny a pro vyloučení pochybností se uvádí, že případně i pozdější uplatnění slevy z ceny nemá za následek zánik nároku na slevu z ceny. Pokud výše neuplatněné slevy z ceny služeb převýší jejich zbývající dosud nezaplacenou částku až do konce poskytování služeb, jedná se o podstatné porušení povinností Zhotovitele.

Pokud Zhotovitel poruší stanovené smluvní povinnosti tím, že v kterémkoliv vyhodnocovacím období kterékoliv služby poskytované podle jejího katalogového listu bude tato služba nebo její část nedostupná po dobu delší než je pro ni stanoveno v daném katalogovém listu nebo maximální přípustný počet kritických incidentů (označení závažnosti „1“ nebo také „A“) překročí maximální přípustný počet takových kritických incidentů podle příslušného katalogového listu, nebo nebudou dodrženy obecně definované parametry řešení kritických incidentů, jedná se podstatné porušení povinností Zhotovitele.

Není-li kterákoliv služba v kterémkoliv vyhodnocovacím období poskytována podle jejího katalogového listu a současně se nejedná o případ uvedený v předchozím odstavci, pak má Objednatel právo na slevu z ceny služeb, které jsou definovány takto, přičemž podrobnosti mohou být upraveny v příslušných katalogových listech pro danou službu.

Tabulka 11: Slevy dle závažnosti incidentu

Závažnost incidentu	Sleva	Výpočet slevy
1 Kritická	0,1 %	Z Paušálu za každou započatou minutu po uplynutí lhůty na obnovení řádného fungování Systému
2 Vysoká	0,5 %	Z Paušálu za každou započatou hodinu po uplynutí lhůty na obnovení řádného fungování Systému
3 Střední	1,0 %	Z Paušáluza každých započatých 24 hodin po uplynutí lhůty na obnovení řádného fungování Systému
4 Nízká	1,5 %	Z Paušáluza každých započatých 5 dní po uplynutí lhůty na obnovení řádného fungování Systému
5 Ostatní	2,0 %	Z Paušáluza každých započatých 10 dní po uplynutí lhůty na obnovení řádného fungování Systému

Platí, že sleva z ceny je definována v závislosti na prioritě incidentu či požadavku v souladu s kalendářem pro danou závažnost.

Slevy za nedostupnost uživatelského rozhraní se počítají za každých započatých 15 minut nedostupnosti rozhraní, které je nad limitem požadované dostupnosti rozhraní. V každém takovém případě se uplatní sleva 0,1 % z Paušálu. V případě nedostupnosti rozhraní přesahujícího jednu celou nepřerušenou hodinu se tento stav považuje za jeden souvislý incident se střední prioritou závažnosti (3) a nastanou-li podmínky pro uplatnění příslušné slevy, pak se tato sleva uplatní ještě dodatečně.

Absence podkladů používaných pro vyhodnocení poskytovaných služeb a jejich kvality se považuje za výpadek služby, jejíž dostupnost a kvalitu měla chybějící data dokládat. Absence podkladů pro vyhodnocení každé jednotlivé poskytované služby za každou chybějící, byť započatou hodinu představuje uplatnění slevy 0,1 % z Paušálu, přičemž tato sleva se přičítá k jiným již uplatněným slevám v souvislosti s touto službou.

Pro účely výpočtu slevy se měsíční cenou Služeb Komplexní podpory rozumí výše Paušálu dle Smlouvy o podpoře.

Zhotovitel navrhne a v Implementační studii popíše způsob řízení realizace, metodu projektového řízení, kterou bude uplatňovat, hloubku a šířku jejího uplatnění s ohledem na rozsah realizace. Popíše zejména elementy metody řízení, které Zhotovitel považuje za nutné oproti běžným standardům či obvyklé praxi vyzdvihnout nebo naopak potlačit vzhledem k charakteru realizace, prostředí či podmínkám Objednatele. Rozsah zde uvedeného popisu řízení se musí soustředit na uvedené významné aspekty řízení a nesmí obsahovat generické texty a diagramy, které jsou všeobecně platné a musely by teprve být pro potřeby nabízených aktivit příslušně aplikovány či interpretovány.

Zhotovitel popíše řízení součinnosti dotčených subjektů a třetích stran, její zadávání, koordinaci, přebírání jejích výstupů, mechanismy uplatňování vad součinnosti atp. Způsoby upozorňování, eskalace a alternativních návrhů řešení pro případy, kdy tato součinnost nebude poskytnuta řádně, včas a v požadované kvalitě. Součinnost dotčených subjektů a třetích stran bude Zhotovitel uplatňovat prostřednictvím Objednatele. Při popisu součinnosti třetích stran se soustředí hlavně na dodavateletelematických zařízení, které budou pasportizovány a pro něž bude nutno prozkoumat a navrhnout způsoby a prostředky pro jejich aktivní řízení a sledování jejich provozních stavů.

Zhotovitel popíše způsob koordinace realizace s ostatními projekty či aktivitami probíhajícími u Objednatele tak, aby zabránil kolizním stavům, účinně zvládal jejich dopady a vzájemné vlivy.

Zhotovitel popíše způsob řízení realizace ve vhodném členění, které odpovídá logickému členění Zhotovitelem navrhované metody řízení. Musí však být pokryty všechny základní skupiny procesů řízení Projektu nezbytné k vytvoření jeho výstupů a výsledků. Popis způsobu řízení realizace bude obsahovat způsob, formy a metody, procesy a postupy řízení, které musí být uzpůsobeny prostředí Objednatele a musí vyhovovat svým zaměřením, přiměřeností a účelem rozsahu plnění veřejné zakázky. Zhxxxxxxxxxx xvolený přístup musí zohlednit:

Schopnost dodat celkový rozsah realizovaného plnění v požadovaném čase, rozpočtu a kvalitě.
Jednotlivé realizační etapy či časové úseky musí být nastaveny realisticky.
Zhotovitel stávajícího systému SRD a dodavatelé telematických zařízení musí být schopni respektovat navrhovaný způsob řízení realizace (nebo se mu přizpůsobit bez nutnosti vynaložit mimořádné úsilí).
Schopnost řídit vzájemná propojení, vazby či závislosti mezi realizací a ostatními aktivitami a projekty Zhotovitele prováděné při výkonu jeho běžných činností, přičemž tyto projekty mohou být prováděna různými agilními či neagilními metodami a styly.
Schopnost Objednatele přijmout Zhotovitelem navrhovaný způsob řízení realizace, zejména s ohledem na počet jeho disponibilních zdrojů, jejich znalostí, zkušeností a dovedností, nezbytné součinnosti a možností jejího poskytnutí v požadované kvalitě a potřebném čase, a počet dostupných výpočetních prostředí či jiné infrastruktury a materiálních prostředků.
Faktické zkušenosti navrhovaného realizačního týmu s navrhovaným způsobem řízení realizace.

Zhotovitel zpracuje způsob, formy a metody, procesy a postupy řízení realizace takovým způsobem, aby z jejich popisu v Implementační studii bylo zřejmé a srozumitelné, že navrhovaný způsob řízení je realistický v prostředí Objednatele a že Objednatel bude schopen poskytnout požadovanou nezbytnou součinnost. Zhotovitel v takto zpracovaném přístupu k řízení realizace zohlední dále tyto Objednatelem požadované principy:

Zhotovitel zavede organizační strukturu řízení, která bude pokrývat nejméně Zhotovitele, Objednatele a dotčené třetí strany.
Zhotovitel sestaví seznam rolí podílejících se na realizaci s vyznačením jejich příslušnosti k organizaci Zhotovitele, Objednatele a třetích stran.
Zhotovitel definuje aktivity řízení pro jednotlivé role, které budou zpracovány formou RACI matice.
Zhotovitel sestaví matici dodávek a rozdělení odpovědností za související činnosti formou RACI matice.
Zhotovitel definuje postup řízení zdrojů.
Zhotovitel navrhne vhodné a účinné metody řízení Projektu a pomůcek, nástrojů či šablon, jejich účel a způsob použití.
Zhotovitel popíše přístup k řízení realizace, klíčové zásady, hlavní postupy a procedury (zejména sledování a vykazovaní stavu a průběhu prací, aktualizace plánu realizace, plánování a obsazování zdrojů, řízení součinnosti). Uvedené komponenty musí být popsány stručně avšak výstižně.
Zhotovitel zajistí nepřerušované každodenní řízení realizace včetně administrativní podpory řízení (mj. způsob rezervace jednacích místností a pracovních prostor, pořizování zápisů z jednání, správu dokumentů aj.).
Zhotovitel definuje dále uvedené procedury formou definice jejich postupů, zúčastněných rolí a odpovědnosti, používaných pomůcek a nástrojů, vstupů a výstupů jednotlivých kroků:

Eskalační proces pro řešení situací, kdy není možno dosáhnout řešení na úrovni jeho vzniku, ale řešení je nutno posunout na vyšší úroveň rozhodování.
Řízení rizik.
Řízení změn vč. vedení jejich registru, provádění analýz, hodnocení dopadů a nákladů, sledování a vykazování realizace jednotlivých změn.
Řízení problémů a otevřených otázek.

Objednatel požaduje od Zhotovitele průběžné, nepřerušované a včasné řízení realizace Projektu v její úplné celistvosti (tzn. všech součástí realizace ve všech souvislostech a vazbách a s ohledem na dotčené strany a systémy). Řízení realizace musí být Zhotovitelem poskytováno počínaje jejím prvním dnem až do posledního dne Projektu. Řízení prováděné Zhxxxxxxxxxx xahrnuje minimálně tyto činnosti:

Plánování, organizování, dohlížení, monitorování a vykazování všech aspektů realizace.
Poskytování všech služeb s vysokou odbornou péčí osobami, které mají potřebnou kvalifikaci, znalosti a zkušenosti pro plnění svých úkolů.
Nastavení organizace a jejích dílčích oblastí, řídicích orgánů, struktur, rolí, odpovědností a činnosti včetně vazeb na organizační strukturu Objednatele.
Efektivní řízení provádění realizace s ohledem na její rozsah, čas, rozpočet, lidské zdroje, změny a rizika a také s ohledem na dosažení účelu a cílů realizace.
Pravidelné informování o postupu a průběžných výsledcích realizace, zejména podávání zpráv o odchylkách skutečného stavu (času, rozsahu, rozpočtu či kvality) oproti plánu či jeho dílčích oblastí a nastavení odpovídajících nápravných opatření.
Řízení vzájemných vazeb a závislostí výstupů, které jsou součástí výsledného řešení, řízení vzájemné provázanosti poskytovaných činností a služeb, integrace jednotlivých komponent do komplexního propojeného řešení, řízení potřebné součinnosti;
Zajištění organizace a vzájemných závislostí (tzn. integrace) průběžných, dílčích nebo finálních plnění (či jejich části), které jsou nezbytné pro realizaci.
Příprava, nastavení a sledování plánu realizace a jejích dílčích oblastí, které definují, jak bude každá oblast během realizace řešena a jaké postupy, metody a techniky budou použity. Plán může obsahovat vzájemně logicky uspořádané dílčí plány pro jednotlivé oblasti. Tyto plány musí obsahovat detailní rozpad prací (angl. work breakdown structure), které tvoří příslušné pracovní bloky a činnosti uspořádané do časového harmonogramu s milníky a kontrolními body, a jsou propojeny s rozpočtem, aby tím bylo zajištěno, že všechny pracovní bloky a úkoly do sebe navzájem zapadají a to způsobem, jehož výsledkem bude vytvoření integrovaného a plně funkčního Systému. Zhotovitel
Koordinace aktivit a úkolů zúčastněných stran nebo realizací dotčených stran, jakož i koordinaci činností a úkolů Zhotovitelů stávajících systémů Objednatele.
Řízení vazeb a rozhraní realizace, tzn. rozpoznávání, dokumentování, plánování, komunikování a monitorování vnitřních a vnějších rozhraní ve vztahu k výstupům realizace, což zahrnuje:
- řízení vazeb mezi lidmi v rámci organizace Objednatele nehledě na to, zda jsou či nejsou přímo zapojeni do realizace,
- řízení rozhraní a vazeb mezi částmi organizace, které nepředstavují pouze vztahy mezi lidmi, ale také různé dílčí cíle, styly řízení, aspirace či zvláštnosti, které mohou být i protichůdné,
- řízení systémových rozhraní, technického vybavení, infrastrukturního zázemí či dalších typů vazeb, které jsou obsaženy ve vytvářeném Systému nebo jsou během realizace budovány.
Správa vnitřní integrace realizace, což představuje plánování, operativní řízení a manažerské vedení realizace, včetně koordinování a sledování úkolů a činností při realizaci.
Zajištění řádné komunikace a jejího řízení napříč všemi stranami zúčastněnými na realizaci a vytváření pozitivního vnímání realizace.
Nastavení vhodného způsobu řízení realizace a jeho dokumentovaný popis včetně příslušných postupů, šablon a nástrojů platných pro všechny oblasti realizace.
Poskytování služeb projektové kanceláře projektu a s ní souvisejících procesů jako je řízení změn, řízení incidentů, řízení problémů a otevřených otázek, řízení rizik, řízení releasů, řízení bezpečnosti, řízení konfigurace, řízení kvality, řízení poptávky, zajištění kontinuity provozu a dalších souvisejících procesů řízení realizace s ohledem na průběžné řízení a koordinaci s ostatními projekty či aktivitami.
Správa knihovny průběžných i finálních realizačních výstupů jako systému pro ukládání, distribuování a archivaci dokumentace, plánů, šablon, registrů a nástrojů včetně zajištění postupů řízení dokumentů.
Motivace personálu a zainteresovaných stran, aby cíle realizace byly dosaženy v čase, rozsahu a rozpočtu a byly splněny dohodnuté ukazatele úspěšnosti.
Takové využití znalostí, dovedností, nástrojů a technik, aby realizační aktivity vedly ke splnění všech požadavků kladených na realizaci.
Řádné plánování zdrojů Objednatele a třetích stran, které jsou zapojeny do realizace, a jejich včasné přiřazení k plánovaným činnostem (tzn. nejméně 2 týdny dopředu). Komunikování změn v přiřazení a plánech s příslušnými manažery Objednatele a s řídicími orgány realizace.
Vedení společného registru úkolů platného pro celou realizaci a její dílčí oblasti, který obsahuje nejméně identifikátor úkolu, název úkolu, odpovědnou osobu, prioritu, datum zadání úkolu, požadované datum splnění úkolu, stavové příznaky a popis.
Získávání či vyžadování všech informací od všech pracovníků Objednatele nebo třetích stran, které mohou nějak ovlivňovat realizaci.
Postupovat v souladu s pokyny vydanými Objednatelem, které nejsou v rozporu se Smlouvou o dílo nebo Smlouvou o podpoře, a dále v souladu s informacemi a materiály poskytnutými subjekty, které se Objednatelem spolupracují (partneři, dodavatelé nebo různé dotčené strany).
Zajištění správné komunikace a její řízení napříč všemi stranami zúčastněnými na realizaci a vůči celé organizaci Objednatele.
Konzultace k návrhům a doporučením Objednatele a třetích stran.
Neprodlené upozorňování na jakékoliv ohrožení poskytovaného plnění nebo jeho částí.
Bez zbytečného odkladu oznamovat řídicím orgánům jakákoliv zjištění či poznatky, že informace, instrukce nebo vstupy poskytnuté některým pracovníkem Objednatele nebo partnera Objednatele jsou nevhodné, nezpracované správně nebo nedostatečně kvalitní, a pokud se jedná o informace poskytnuté třetí stranou, pak také neprodlené oznámení této straně.
Zajištění nezbytné asistence Objednateli při jednání se třetími stranami a vystupování v takových jednání v pozici technického poradce Objednatele;
Zajištění souladu se souběžně běžícími projekty Objednatele, které jsou obsaženy ve výhledu připravovaných projektů a plánu realizovaných projektů.

Zhotovitel navrhne a podrobně popíše v Implementační studii způsob realizace. Popíše způsob provádění výzkumu, analýz, vývoje, prototypování, ověřování, zkoušení, testování a nasazování Systému. Popíše také činnosti, které budou muset provést dotčené subjekty a třetí strany. Popíše jednotlivé etapy projektu, jejich zaměření a cíle, zpracovávané výstupy a výstupy dodávané v jednotlivých etapách, pro každou etapu samostatně její vstupní podmínky umožňující její zahájení, ukončení a přechod k etapě následující, požadavky na součinnost Objednatele a třetích stran.

Zhotovitel navrhne hlavní milníky realizace, kterými budou mj. začátky a konce etap, kontrolní body a kontrolní dny, integrační milníky pro dosažení určitých systémových, projektových organizačních nebo jiných vazeb, termíny dodávek nebo skupin souvisejících dodávek atd. Hlavní milníky budou zpracovány ve formátu dle přiloženého vzoru tabulky.

Tabulka 12: Návrh struktury seznamu hlavních realizačních milníků

Označení milníku	Popis milníku	Plánovaný termín dosažení

Označení milníku musí být krátký a výstižný název, např. konec uživatelských akceptačních testů nebo průběžný kontrolní bod kvality číslo N. Popis bude obsahovat stručnou charakteristiku, co je k danému milníku vztaženo, jaké činnosti budou provedeny ve fázi, kterou milník zakončuje atp. Plánovaný termín bude udávat termín realizačního harmonogramu, ke kterému budou všechny související činnosti podle plánu řádně provedeny a dokončeny. Budou-li v dané etapě nějaké výstupy, které jsou předmětem akceptace, k tomuto plánovanému datu musí být všechny související činnosti (např. příslušné testy, akceptační postupy atp.) rovněž provedeny.

Zhotovitel v Implementační studii navrhne a popíše seznam realizačních výstupů (dodávek, poskytnutých služeb) ve formátu dle přiloženého vzoru následující tabulky. Označení výstupu musí být krátké a výstižné, aby z názvu byl jasně srozumitelný účel a obsah výstupu. Součástí názvu výstupu bude jeho jedinečný kód (ideálně označující příslušnou etapu Projektu a pořadové číslo výstupu), aby bylo možno se odkazovat na výstup v ostatní projektové dokumentaci pouze tímto kódem. Popis výstupu stručně, ale úplně vystihuje náplň daného výstupu v rozsahu a detailu obdobném, jako Objednatel vymezil minimální požadavky na základní projektové dokumenty. Metoda akceptace výstupu bude označovat některý z Objednatelem určených postupů akceptace, viz kapitola 5.2. Akceptační kritérium upřesňuje použité kritérium úspěšné akceptace v souladu s příslušnou akceptační metodou, není-li již plně určeno touto metodou.

Tabulka 13: Návrh struktury seznamu hlavních realizačních výstupů

Označení výstupu	Popis výstupu	Metoda akceptace výstupu	Akceptační kritérium

Všechny informace uvedené v seznamu milníků a seznamu výstupů musí být plně v souladu se Zhotovitelem navrhovaným plánem a harmonogramem realizace, přístupem k realizaci a k jejím dílčím oblastem, řídicí a prováděcí dokumentací a vůči další dokumentaci zpracované Xxxxxxxxxxxx.

Zhotovitel navrhne a popíše organizaci realizace včetně specifikace požadované součinnosti podle vzoru následující tabulky.

Tabulka 14: Návrh organizační struktury realizace

Projektová role	Počet pracovníků v dané roli celkem	Požadovaná kapacita (0-100%)
Řídicí výbor
Sponzor
Člen Řídicího výboru
Vedení projektu
Vedoucí realizačního projektu
Podpora administrace realizačního projektu
Projektové týmy
Vedoucí projektového týmu
Člen projektového týmu
Technický tým
Vedoucí technického týmu
Člen technického týmu
Specialista na rozhraní

Zhotovitel popíše v Implementační studii všechny další požadavky na součinnost Objednatele, která není spojena s konkrétními rolemi, např. materiální součinnost, přístup na pracoviště Objednatele atp., zejména jejich rozsah, formu a obsah i oblast součinnosti.

Tabulka 15: Návrh seznamu požadované součinnosti

Požadavky na součinnost Objednatele

Popis požadované součinnosti 1.

Popis požadované součinnosti 2.

Popis požadované součinnosti n.

Zhotovitel navrhne způsob a formu komunikace, kterou bude během realizace uplatňovat. Popíše základní komponenty komunikačního plánu a navrhne jejich obsah. Xxxxxxxxxx ve svém návrhu rozpracuje profil zainteresovaných stran na realizaci a navrhne základní obsah matice komunikace.

Tabulka 16: Vzor matice komunikace

Zhotovitel navrhne způsob a postupy řízení problémů a otevřených otázek. Detailně popíše příslušné postupy v souvislosti s použitými nástroji a pomůckami. Součástí popisu bude definice rolí a jejich zodpovědnosti. Činnosti budou popsány formou RACI matice. Zhotovitel v návrhu procesu bude respektovat Objednatelem závazná pravidla řízení rizik, problémů a otevřených otázek.

Odpovědnost za identifikaci problému či otevřené otázky a za jejich evidenci má každý účastník Projektu. Odpovědnost za řešení problému (tzn. přidělení odpovědnosti za odstranění, sledování, potvrzení odstranění problému, údržba databáze problémů atd.) má vedoucí projektu či jeho zástupce.

Každý problém, který není možné řešit v rámci realizačního týmu, bude písemně předložen týmu vedení realizace.
Vedení realizace následně problém buď:
- Zamítne. Problém není vůči realizaci relevantní, nemá k ní vztah a neohrožuje její průběh, nebo
- akceptuje (přijme k řešení). Problém bude mít vliv na průběh realizace.
Vedení realizace určí:
- prioritu při řešení problému na základě vlivu problému na průběh realizace
- a člena týmu odpovědného za návrh řešení a odstranění problému.
Vedení realizace provádí v pravidelných intervalech sledování odstranění problému.
Pokud problém není odstraněn do příslušného termínu a nadále ovlivňuje průběh realizace, tým vedení realizace posoudí důvod, proč nedošlo k odstranění problému, a definuje nápravná opatření.
V případě, že problém je mimo kompetenci týmu vedení realizace nebo proces jeho odstranění není efektivní a vážně ohrožuje průběh realizace, musí vedení realizace problém okamžitě předložit řídicímu výboru spolu s návrhem řešení, za účelem provedení konečného rozhodnutí.
Vedení realizace musí provést, ve vazbě na problém, revizi realizačních plánů, harmonogramu atd., a pokud problém ovlivní realizační harmonogram, pak předložit jeho změnu ke schválení řídicímu výboru. Tento krok může být spojen s provedením změnového řízení.

Zhotovitel navrhne způsob a postupy řízení změn. Detailně popíše příslušné postupy v souvislosti s použitými nástroji a pomůckami. Součástí popisu bude definice rolí a jejich zodpovědnosti. Činnosti budou popsány formou RACI matice. Zhotovitel v návrhu procesu bude respektovat Objednatelem uvedená závazná pravidla změnového řízení.

Změnové řízení realizace je proces povinně spouštěný v okamžiku, kdy je požadována změna, která ovlivňuje tři základní parametry realizace: čas, náklady a rozsah. Závazná pravidla změnového řízení jsou tato:

Žadatel o změnu předloží písemně svou žádost vedoucímu projektu na straně Objednatele či jeho zástupci, včetně zdůvodnění požadované změny.
Vedoucí projektu na straně Objednatele či jeho zástupce změnový požadavek zaeviduje a předá vedoucímu projektu na straně Zhotovitele k doplnění informací.
Vedoucí projektu na straně Zhotovitele doplní do změnového požadavku, nejpozději do 7‑14 dnů (podle rozsáhlosti požadované změny) po jeho obdržení, seznam dopadů, které bude mít zahrnutí této změny na realizaci (časový plán, zdroje Objednatele i Zhotovitele, cena vyjádřená v penězích nebo nepřímo formou odhadu pracnosti).
Takto doplněný změnový požadavek předloží vedoucí projektu na straně Objednatele či jeho zástupce členům řídicího výboru v dostatečném předstihu tak, aby na své nejbližší řádné nebo mimořádné schůzi mohl rozhodnout, že:
- Akceptuje předložený změnový požadavek – v tom případě vedoucí projektu na straně Objednatele či jeho zástupce a vedoucí projektu na straně Zhotovitele zabezpečí zapracování změny do řídicí a prováděcí dokumentace a případně také připraví eventuální návrh dodatku smlouvy zohledňující všechny dopady změny na realizaci.
- Neakceptuje předložený změnový požadavek – v tom případě vedoucí projektu na straně Objednatele či jeho zástupce informuje žadatele o rozhodnutí Řídicího výboru projektu a rozsah realizace zůstane beze změny.
- Předá k rozhodnutí řídicímu výboru.
Navrhování a provádění všech změn musí být v souladu se zákonem o zadávání veřejných zakázek.

Objednatel požaduje vytvoření Dokumentace Zhotovitelem v následujícím minimálním rozsahu. Zhotovitel popíše v Implementační studii strukturu dodávané dokumentace podle požadovaných typů, doplní dalšími dokumenty podle jím navrhovaných výstupů a služeb a způsobu realizace. Konkrétní vytvářené dokumenty uvede v seznamu výstupů v návaznosti na etapy realizace a její harmonogram. Současně definuje způsob aktualizace Dokumentace.

Veškerá Dokumentace musí být zpracována ve formátech MS Office (Word, Excel, Visio) nebo PDF, obrázky ve formátech JPG, PNG, komprese ZIP. Dokumentace zpracovávaná návrhářskými či vývojářskými nástroji bude ve formátu příslušných nástrojů. Vytvářená Dokumentace musí být v českém jazyce. Objednateli bude předána v elektronické i tištěné podobě. Formáty, jmenné konvence, způsob řízení dokumentů popíše Zhotovitel v Implementační studii.

Provozní část dokumentace připravené Zhotovitelem během realizace musí být zpracovaná v míře podrobnosti umožňující následující správu Systému Objednatelem bez přímého zapojení Zhotovitele.

Tabulka 17: Hlavní požadované dokumenty zpracované Xxxxxxxxxxxx

Dokument či sada dokumentace	Obsah
Definice projektu	Dokument tvoří základ řídicí a prováděcí dokumentace. Konkrétní požadavky na Definici projektu jsou vymezeny v kapitole 2.1.1.
Implementační studie	Dokument detailně formou cílového konceptu popisuje materiální, funkční, organizační, integrační, procesní a všechny další aspekty realizace Projektu a následné provozní části plnění Zhotovitele. Přesně a určitě definuje podrobný rozsah plnění. Na základní celkovou Implementační studii mohou navazovat dílčí detailní cílové koncepty, které mohou určitou tematicky vymezenou oblast rozpracovávat do větší hloubky. Konkrétní požadavky na Implementační studii jsou vymezeny v kapitole 2.1.2.
Bezpečnostní dokumentace	Bezpečnostní dokumentace se musí skládat nejméně z těchto dílčích dokumentů: Bezpečnostní politika. Obsahuje popis bezpečnostních opatření, která budou v rámci pilotního provozu i následného provozu Systému uplatňována při zajišťování bezpečnosti Systému. Bezpečnostní směrnice. Obsahuje podrobný popis bezpečnostních funkcí, které budou provozovatelem Systému používány pro provádění určených činností v Systému, a návod na použití těchto funkcí. Bezpečnostní dokumentace bude popisovat zejména: Stav bezpečnosti vycházející z analýzy rizik Systému, v jejímž rámci bude provedena identifikace aktiv, hrozeb, zranitelností a budou stanovena rizika Systému. Klasifikace a řízení aktiv, jejich evidenci v návaznosti na vlastnictví informačních prvků a celků. Platnost bezpečnostní politiky a její závaznost bude vedena platnou legislativou. Pravidla organizace bezpečnosti v oblastech rolí a odpovědností schvalovacích procesů, spolupráce s příslušnými úřady a odbornými skupinami, bezpečnosti v otázce externích přístupů. Bezpečnost lidských zdrojů. Fyzickou bezpečnost a zabezpečení prostředí. Řízení provozu, především pak ochranu proti škodlivým kódům, zálohování, správu sítě, výměnu informací s jinými systémy a monitorování. Řízení přístupu, evidenci uživatelů, stanovení pravidel a odpovědností pro přístupy, řízení přístupu k sítím a k Systému. Vývoj a údržbu Systému s důrazem na zvyšování úrovně bezpečnosti, resp. i vhodné metriky na vybrané měřitelné atributy a následná pravidelná vyhodnocování úrovně bezpečnost. Management bezpečnostních incidentů. Soulad Systému s požadavky plynoucími z platné interní/externí legislativy, soulad se standardy bezpečnosti a hlediska provádění auditu Systému. Bezpečnostní dokumentace musí být zpracována v souladu s prováděcí vyhláškou k zákonu o kybernetické bezpečnosti a také v souladu s normou ISO 27 000-27 005 a ISO 27 035.
Migrační strategie	Migrační strategie je součástí Implementační studie a popisuje přístup Zhotovitele k provedení migrace ze stávajícího systému SRD a pomocných evidencí a dalších dotčených systémů nebo technologií do Systému nového (tzn. hlavně naplnění Systému příslušnými daty ze stávajících informačních systémů Objednatele či spolupracujících subjektů), přístup k čistění dat, synchronizaci dat a všechny další aspekty vztahující se k datům. Popisuje posloupnost jednotlivých migračních aktivit, jejich návaznosti a způsob provedení, mj. vždy kdo, kdy, s jakými daty, přes jaká rozhraní. Také definuje způsob identifikace datových chyb, postupy a mechanismy čistění dat, vykazování a hlášení chyb v datech včetně způsobu jejich odstraňování. Definuje cvičné a ostré migrační běhy. Definuje způsob migrace a čistění dat, která budou příp. migrována až během nasazování Systému nebo příp. až po jeho nasazení (např. externí data, která do Systému nemohla být díky jiným aktivitám nahrána). Definuje přístup k migraci otevřených transakcí (tzn. datového obrazu procesů, které započaly ve stávajícím systému, ale ještě nebyly plně dokončeny). Součástí migrační strategie je přístup k plánování návratu a záložnímu plánování návratu (follback/fallback), přístup k jejich sestavení a způsobu realizace. Musí pokrývat všechny technické, organizační a procesní aspekty. Migrační strategie dále popisuje přístup k nasazení Systému (postupný náběh, najednou, po modulech atp.) a způsob jeho provedení, potřebné technické zázemí, migrační nástroje, pomůcky a reporting.
Migrační plán	V návaznosti na Migrační strategii bude vytvořen detailní plán a harmonogram popisující detailně jednotlivé kroky migrace a nasazení Systému a obsahující detailní časový harmonogram aktivit, jejich návazností, milníky a kontrolní body. Obsahuje technicky i manuálně prováděné činnosti. Zahrnuje činnosti prováděné v prostředí Objednatele i v prostředí subjektů, které budou migrací a nasazením dotčené. Představuje detailní věcný plán a časový harmonogram úvodního naplnění Systému příslušnými daty ze stávajících informačních systémů Objednatele. Detailně popisuje časovou posloupnost jednotlivých migračních aktivit, tj. vždy kdo, kdy, jakými daty, přes jaká rozhraní a jak dlouho bude naplňovat Systém tak, aby bylo dosaženo plánovaného termínu nasazení Systému do provozu. Rovněž obsahuje způsob identifikace datových chyb, které vznikly po nasazení Systému do provozu, jejich vykazování a hlášení včetně způsobu jejich odstraňování. Součástí je detailní plán návratu a záložní plán návratu. Součástí migračního plánu jsou jeho přílohy, které popisují: Návrh technické infrastruktury potřené pro provedení migrace Návrh pomůcek, nástrojů, software včetně migračních skriptů pro provedení migrace (mj. extrakce dat ze zdrojových systémů, jejich transformace, uložení do cílových systémů, čistění dat – reporting a chybovníky) Technická dokumentace pro instalaci, konfiguraci, nastavení aj. nasazovaného Systému (a jeho dílčích komponent)
Strategie zkoušek a testování	Dokument je součástí Implementační studie a vymezuje typy prováděných testů jednotlivých plnění, tzn. výstupů a služeb, a způsob ověření jejich parametrů. Pro software to jsou zejména funkčnost, provozní vlastnosti, kapacitní nároky, bezpečnost ap. Popisuje také ověřování výstupů jiného charakteru než software, např. dokumentace, školení atd. Obsahuje nejméně definice těchto oblastí: Cíle a rozsah zkoušek a testování – definuje komponenty a požadavky na software a technologie či plnění jiného charakteru, které mají být zkoušeny nebo testovány, ale i ty, které jsou ze zkoušek a testování vyňaty Konceptuální přístup k jednotlivým typům zkoušek a testů, jak budou zkoušky a testy prováděny, typy prováděných zkoušek a testů Způsob zkoušení a testování požadavků a očekávaných vlastností, pokrytí, trasování Celkový časový postup zkoušek a testů, návaznosti, rámcový harmonogram a milníky Organizace zkoušek a testování, zodpovědné osoby a jejich role a jim příslušné činnosti Způsob řízení zkoušek a testování Podklady pro zkoušky, testovací data a jejich příprava Způsob komunikace a reportingu průběhu a výsledků zkoušek a testů Rizika a závislosti související se ykou3kami a testováním Prostředí (jedno či více), které je potřebné pro provedení ykou3ek a testů Nástroje využívané na podporu zkoušek a testování Standardy a normy, které je nutno dodržet Vstupní kontroly a kritéria nezbytná pro zahájení jednotlivých typů zkoušek a testů Výstupní kritéria indikující možnost ukončení jednotlivých typů zkoušek a testů
Plán zkoušky/testu [pro daný typ zkoušky/testu]	Dokument je zpracován pro každý jednotlivý typ prováděných zkoušek a testů. Upřesňuje v návaznosti na Strategii zkoušek a testování konkrétní vlastnosti ověřovaného plnění a způsob jejich ověření. Obsahuje posloupnost zkušebních a testovacích případů, scénářů a vymezení testovacích dat (např. formou samostatné přílohy nebo odkazem do příslušného nástroje) tak, aby zkušební a testovací případy zahrnovaly všechny požadavky a prověřované vlastnosti daného výstupu. V rámci uvedených vlastností jsou pro danou zkoušku nebo test rozepsány jednotlivé zkušební nebo testovací případy, způsob provádění, očekávané výsledky a zdroje, to znamená lidské kapacity v určitém čase, potřebná testovací data a prostředky výpočetní techniky. Obsahuje zejména: Časový harmonogram realizace dané zkoušky nebo testu Organizační zajištění dané zkoušky nebo testu včetně externích dotčených subjektů Předpoklady, omezení, závislosti a rizika pro danou zkoušku nebo test Fáze provádění zkoušky nebo testu a zaměření těchto fází Hlavní milníky jednotlivých fází zkoušky nebo testu, podrobný harmonogram provádění zkoušky nebo testu Vstupní a výstupní kontroly a kritéria jednotlivých fází dané zkoušky nebo testu Podrobný popis způsobu provádění zkoušky nebo testu v jeho jednotlivých fázích Definice výstupů zkoušky nebo testu v jeho jednotlivých fázích Detailní popis prostředí pro provedení zkoušky nebo testu, způsob jeho správy, řízení a provozování Specifikace zkušebních a testovacích dat, jejich řízení, správa, konkrétní způsob jejich zajištění, vytvoření či přípravy Upřesnění odpovědných osob a jejich rolí a odpovědností, potřebné dovednosti a znalosti, proškolení prováděná před zahájením zkoušky nebo testu Řízení konfigurace a řízení verzí, řízení změn v požadavcích, verzování komponent a verzí uvolňovaných do zkoušek nebo testování Způsob návrhu zkušebních a testovacích případů Řízení provádění zkoušky nebo testu Evidování a sledování defektů, sledování mezi vývojovým a zkušebním či testovacím prostředím a mezi vývojovým a zkušebním či testovacím týmem Komunikace, reporting a eskalační proces Podrobný popis jednotlivých případů a scénářů včetně iniciálních stavů a hodnot a očekávaných stavů a hodnot po provedení jednotlivých kroků scénářů
Protokol o připravenosti k nasazení Systému	Protokol vzniká jako výstupní dokument poslední zkušební fáze před nasazením Systému a konstatuje připravenost Systému a všech jeho součástí (HW, SW, sítě, aktivní a pasivní prvky atp.), jeho uživatelů, správců a administrátorů, technického personálu, externích subjektů a všech dotčených stran k Uvedení systému do provozu. Tento protokol se vystavuje na základě úspěšně provedených předcházejících zkoušek a testů, migrace dat a dalších kroků dle Migračního plánu, všech předchozích řádně provedených činností, akceptace všech předchozích souvisejících výstupů podléhajících akceptaci, výsledků úspěšného provedení všech příslušných zkoušek a testů Systému a splnění všech vzájemně dohodnutých akceptačních kritérií.
Protokol o dokončení	Protokol o dokončení slouží k potvrzení, že Objednatel schválil určitý výstup nebo část projektupodléhající akceptaciO úspěšné akceptaci a předání etapy se vyhotovuje Protokol o předání příslušné etapy. O úspěšné akceptaci a předání Díla jako celku se vyhotovuje Protokol o předání páté (5.) etapy.
Protokol o provedeném školení	Slouží k potvrzení, že školení bylo řádně provedeno. Vystavuje ho Xxxxxxxxxx, který školení provádí a za Objednatele podepisuje vedení projektu. Šablonu protokolu si strany odsouhlasí nejpozději 10 pracovních dnů před zahájením prvního školení v Projektu. Návrh šablony předkládá Zhotovitel k připomínkování a odsouhlasení Objednateli.
Protokol o provedení zkoušky/testu	Výsledkem každého zkoušení nebo testování je Protokol o provedení zkoušky/testu, který obsahuje dokumentaci realizovaných zkoušek či testů a jejich výsledek pro zkušební nebo testovací scénáře jednotlivě i souhrnně a případně také seznam zbývajících neodstraněných chyb či nedostatků s jejich popisem, klasifikací závažnosti a dohodnutý způsob jejich odstranění, spolu s termíny odstranění. Průběh zkoušení nebo testování a výsledky provedených případů a scénářů se zaznamenávají do protokolu průběžně ke konci každého dne provádění zkoušky či testu. Výsledný Protokol o provedení zkoušky/testu zpracovává Zhotovitel a předkládá ho Objednateli k připomínkování a odsouhlasení. Protokol potvrzují vedoucí projektu Zhotovitele a Objednatele. Je přikládán jako nedílná příloha k Protokolu o předání, pokud je příslušné akceptované plnění ověřováno zkouškou či testem. Šablona protokolu je součástí dokumentu Strategie zkoušek a testování, který popisuje rovněž všechny druhy zkoušek a testů, jež během realizace proběhnou za účelem ověření provedeného Díla ze všech pohledů, a způsob jejich provádění. Typy prováděných zkoušek a testů jsou popsány ve Strategii zkoušek a testování.
Zpráva o stavu realizace	Zprávu o stavu realizace připravuje vedoucí projektu Xxxxxxxxxxx a předkládá ji vedoucímu projektu Objednatele k připomínkování. Zpráva o stavu realizace obsahuje informaci o aktuálním stavu a výhledu na nadcházející období a slouží jako podklad pro pravidelné jednání řídicího výboru. Zpráva o stavu realizace obsahuje informace min. v následujících oblastech: Souhrnná informace o realizaci (aktuální stav realizace) Současný stav a přehled splněných termínů a úkolů Plánované činnosti včetně termínů Součinnost Objednatele a dotčených stran (stav poskytování, požadavky na zajištění budoucí součinnosti) Problematické body Vyvolané aktivity či projekty Změnové požadavky Rizika Finance Kompetence, zdroje Body k rozhodnutí
Zpráva o úplnosti a kvalitě etapy	Zprávu zpracovává Zhotovitel před koncem každé etapy Projektu a předkládá ji Objednateli k připomínkování a odsouhlasení. Obsahuje doklad o úplnosti dané etapy, tzn. o provedení všech prací, které měly být provedeny, dále obsahuje rekapitulaci všech výstupů a jejich stavu. Současně zpráva obsahuje přehled cílů kvality, míru jejich naplnění, zjištěné případné nedostatky a jim příslušná nápravná opatření spolu s jejich vlastníky (nedostatků) a termíny provedení, zjištěnou zpětnou vazbu a reflexi Zhotovitele na tato zjištění, návrhy na zlepšení.
Registry	Zhotovitel povede v průběhu svého plnění vhodnou formou projektové registry. Způsob jejich vedení, jejich konkrétní technickou podobu atp. upřesní nejdéle do 2 týdnů po zahájení projektu formou návrhu, který předloží Objednateli k připomínkování a schválení. Takto schválený návrh se stane součástí řídicí a prováděcí dokumentace. Případné navrhované pomůcky či softwarové nástroje spolu s jejich provozováním zajišťuje plně Zhotovitel. Registr úkolů obsahuje nejméně identifikátor úkolu, název úkolu, odpovědnou osobu, prioritu, datum zadání úkolu, požadované datum splnění úkolu, stavové příznaky a popis. Registr problémů/otevřených otázek/rozhodnutí obsahuje problémy, otevřené otázky k řešení či rozhodnutí, které mají podstatný dopad na projekt. Registr rizik obsahuje rozpoznaná rizika, vlastníky, termíny, opatření ke zvládnutí atp. Slouží k dokumentování rizik a jejich sledování.
Zápis z jednání	Z každého jednání (schůzky) každého týmu během realizace je pořizován oboustranně odsouhlasený písemný zápis. Slouží k popisu obsahu jednání a přijatých rozhodnutí a k zápisu uložených úkolů a jejich plnění. Vytvoření zápisu z jednání, vložení do projektového úložiště, jeho distribuce zúčastněným stranám, sběr a vypořádání připomínek a distribuce finální verze je úkolem Zhotovitele, neurčí-li Objednatel celkově či jednotlivě jinak.
Harmonogram	Sumarizuje přehled prací a potřebných kapacit pro jejich provedení. Obsahuje hlavní milníky projektu. Důležité práce jsou mezi sebou provázány. Je vypracován vhodným způsobem, např. v nástroji MS Project. Aktualizuje se podle potřeby, nejméně však vždy před etapy, aby zpodrobnil aktuální plán pro následující období.
Školící materiály	Jsou to podpůrné materiály pro provádění školení daného typu, např. prezentace, konkrétní ukázkové či procvičovací cvičení na základě reálných situací a dat. Tento materiál může být používán nejen zaškolení, ale také proškolení nových zaměstnanců. Vytvoření školících materiálů je úkolem Zhotovitele.
Administrátorská příručka	Musí být zpracována v souladu s normou ISO 20000 a ISO 27001 a musí obsahovat zejména následující součásti: Základní funkční specifikace informačního Systému. Cílem této části administrátorské dokumentace je poskytnout pracovnímu týmu systémové podpory IT provozu Objednatele základní informace o Systému, o jeho účelu a o parametrech garantovaných koncovým uživatelům v organizaci i mimo ni. Obsahuje mj. rekapitulaci analýzy požadavků a návrhu a popis architektury, rozhraní, procesů a užití Systému. Technologický postup práce s informačním Systémem. Tato část administrátorské dokumentace seznamuje pracovní tým systémové podpory IT provozu Objednatele se základy provozní technologie Systému. Technický návrh informačního Systému. Cílem této části administrátorské dokumentace je seznámení pracovního týmu systémové podpory IT provozu Objednatele s architekturou Systému a některými detaily řešení v oblasti aplikační, datové a v oblasti technické do hloubky nutné ke kvalitnímu zajištění systémové podpory provozu. Organizačně provozní zajištění informačního Systému. Cílem této části administrátorské dokumentace je seznámení pracovního týmu systémové podpory IT provozu Objednatele s principy a zásadami nutnými pro budování a provoz jak pracovišť koncových uživatelů, tak pracovišť systémové podpory provozu. Plán Podpory Systému. Základní procesy řízení provozu včetně parametrů pro jednotlivé činnosti, návrh organizace a rolí. Konfigurace bezpečnostních prvků v Systému. Cílem této části administrátorské dokumentace je poskytnout pracovnímu týmu systémové podpory IT provozu Objednatele garanci souladu mechanizmu práce informačního Systému s platnými bezpečnostními předpisy podniku, seznámit s principy realizace těchto bezpečnostních prvků v Systému a poskytnout informace nutné k parametrizaci Systému tak, aby bezpečnostní prvky zabudované v Systému byly účinné (viz též bezpečnostní dokumentaci). Popis bezpečnostního zálohování dat a programů Systému. Cílem této části administrátorské dokumentace je stanovit zásady bezpečnostního zálohování dat a aplikačních programových modulů informačního Systému. Popis provozního archivování dat v provozní databázi. Cílem této části administrátorské dokumentace je stanovit pravidla pro archivaci dat na předepsaná archivní média (resp. do archivního systému Objednatele) a pravidla pro úschovu a používání. Dohled a prověřování stavu Systému. Cílem této části je poskytnout informace nutné k organizaci rutinního sledování funkčnosti a bezpečnosti Systému. Řešení nestandardních stavů Systému, scénáře řešení. Cílem této části administrátorské dokumentace je stanovit scénáře postupů při řešení mimořádných (nestandardních, havarijních) situací, uvést předpoklady, za kterých je možno dané scénáře aplikovat. Nástroje pro testování, správu, aplikaci záplat a aktualizací.
Instalační příručka	Instalační příručka bude obsahovat zejména následující součásti: Instalace a konfigurace serverových komponent - cílem této části instalační dokumentace je poskytnout pracovnímu týmu systémové podpory IT provozu v organizaci dostatečné informace pro správnou instalaci, konfiguraci a kontrolu funkčnosti všech serverových komponent Systému. Instalace a konfigurace klientských komponent - cílem této části instalační dokumentace je poskytnout pracovnímu týmu systémové podpory IT provozu v organizaci dostatečné informace pro správnou instalaci, konfiguraci a kontrolu funkčnosti všech komponent Systému umístěných na klientských stanicích. Organizace práce v etapě zavádění Systému do provozu - cílem této části administrátorské dokumentace je informovat o pravidlech, zásadách, postupech, požadavcích a omezení platných v etapě zavádění Systému do provozu.
Uživatelská dokumentace	Uživatelská příručka včetně kompletního popisu funkcionality zpracovaná pro jednotlivé uživatelské role. Součástí uživatelské dokumentace bude uživatelská nápověda obsahující alespoň: Aplikační nápovědu Metodickou nápovědu Uživatelská dokumentace musí splňovat náležitosti dané § 10 až § 12 vyhlášky č. 529/2006 Sb. Uživatelská dokumentace Systému musí být přístupná v celém Systému konzistentním způsobem (tj. bude označena jednotným ovládacím prvkem a bude vždy umístěna na stejném, či stejně voleném místě obrazovky Systému).
Dokumentace nastavení Systému	Souhrnná dokumentace veškerých aplikačních nastavení, nastavení všech podpůrných systémů, nástrojů či komponent.

Zhotovitel v Implementační studii zpracuje přehled dokumentů, které dodá v průběhu realizace. Dokumenty popíše v členění etap Projektu, viz vzor podle následující tabulky. V popisu obsahu dokumentu Zhotovitel uvede zaměření a účel dokumentu a ve srozumitelných bodech vymezí jeho obsah formou osnovy.

Tabulka 18: Návrh struktury přehledu zpracovaných dokumentů v rámci realizace

Etapa	Kód dokumentu	Dokument	Popis obsahu dokumentu
[Označení fáze]	[kód dokumentu]	[název dokumentu]
[Označení fáze]	[kód dokumentu]	[název dokumentu]
[Označení fáze]	[kód dokumentu]	[název dokumentu]

Objednatel požaduje, aby nasazení Systému proběhlo úspěšně. Z tohoto důvodu požaduje, aby nasazení Systému nebylo připravováno, řízeno a provedeno pouze z technického pohledu, ale obsahovalo také složku řízení organizační změny. Objednatel požaduje, aby součástí realizace Projektu bylo také zvládnutí nezbytných změn, a to jak změn dočasných, které souvisejí s realizací Projektu, tak změn trvalých, které souvisejí se stavem rutinního používání Systému. Zhotovitel musí být schopen:

Účinně minimalizovat pokles výkonnosti, který lze očekávat v období po nasazení Systému až do okamžiku jeho ustáleného používání;
Připravit komunikační strategii a komunikační plán vůči organizaci Objednatele a ostatním dotčeným stranám;
Rozpoznat Projektem dotčené osoby a organizace, definovat přístup k řízení
jejich očekávání a být nápomocen Objednateli při řízení očekávání těchto subjektů;
Zajistit správnou, včasnou a účinnou komunikaci Projektu a jeho výstupů a výsledků směrem dovnitř organizace Objednatele;
Nastavit vhodné způsoby a prostředky zjišťování zpětné vazby od Projektem dotčených subjektů, být nápomocen Objednateli při zjišťování zpětné vazby, při jejím vyhodnocování a navrhování a realizaci opatření reagujících na poznatky zjištěné zpětnou vazbou;
Navrhovat potřebné změny v organizaci Objednatele, které budou vyvolány nasazením Systému;
Navrhovat potřebné změny v procesech a postupech Objednatele, které budou vyvolány nasazením Systému;
Provést test připravenosti organizace Objednatele před nasazením Systému.

Objednatel požaduje, aby před Uvedením do provozu byly splněny tyto minimální předpoklady:

Systém a všechny jeho součásti (moduly, komponenty, rozhraní atd.) budou nainstalovány na všech příslušných počítačích a souvisejících technických prvcích;
Spojení Systému s ostatními systémy bylo otestováno, akceptováno a je stabilní;
Interní i externí uživatelé jsou připraveni používat nový Systém. Připojené systémy mají připraveny otestované, akceptované a funkční integrační vazby;
Dokumentace je dokončena a akceptována. Je příslušným uživatelům dostupná;
Všechna školení řádně proběhla, uživatelé i technický personál jsou proškolení a jsou připraveni pracovat se Systémem;
Funkční, uživatelský a další testy byly řádně provedeny a Systém byl akceptován;

Plněním Zhotovitele v oblasti testování je celkové řízení testování, které mj. zahrnuje zpracování dokumentu Strategie zkoušek a testování, plánů jednotlivých testů, řízení a organizování testování přes celý jeho životní cyklus od strategie (mj. plánování, příprava, návrh testu, příprava testovacích dat, provádění testu, vykazování a sledování defektů, vyhodnocení a ukončení aj.), definování a řízení potřebné součinnosti Objednatele při uplatňování požadavků vůči třetím stranám (např. příprava testovacích dat, technické kontroly, modifikace jimi dodávaných systémů atp.), řízení a koordinace všech stran zapojených do testování, koordinace a řešení chyb, incidentů a problémů navzájem mezi stranami zapojenými do testování.

Objednatel požaduje, aby Zhotovitel celý průběh testování logicky rozčlenil a provedl ve čtyřech navazujících částech:

Strategie, tzn. návrh konceptu testování. Je součást analýzy prováděné v rámci úvodní Implementační studie. Obsahuje návrh testů pro každý funkční celek dodávaného Systému. Návrh testů obsahuje vymezení typů prováděných testů (funkční, uživatelský, integrační, komplexní, výkonnostní či zátěžové aj.) s jejich popisem. Testovací strategie pokládá základy celého testování. Základními atributy testování, které musí Zhotovitel důsledně zohlednit, jsou principy měřitelnosti, transparentnosti, trasovatelnosti a auditovatelnosti. Výstupem je Strategie zkoušek a testování.
Příprava, tzn. příprava artefaktů testování. Příprava testovacích scénářů a testovacích skriptů vychází z funkčních a technických požadavků. Pro každý typ testu Zhotovitel vypracovává detailní plán testování. Dále testovací scénáře jako podrobný návod pro testery, jak testovat daný funkční celek Systému pro jednotlivé případy jeho užití (různé uživatelské postupy, různé typy zpracovávaných dat apod.) a pro dané typy testů. Připravuje se testovací prostředí a testovací data. Testovací prostředí a data připravuje Zhotovitel za součinnosti Objednatele. Součástí přípravy je také příprava technologií a dat pro testování a v případě uživatelského akceptačního testu pak zejména příprava testerů. Výstupy jsou plány testování, testovací případy, scénáře a skripty, testovací data a testovací prostředí. Testování podle příslušného typu testu provádějí vývojáři, konzultanti, příp. další testeři Xxxxxxxxxxx a v některých typech testů i příslušní pracovníci Objednatele a jeho uživatelé (příp. také pracovníci a uživatelé dotčených stran). Testovaní v rámci testů navazujících na iniciální testy (jakými jsou jednotkové testy či systémové testy) se již vývojáři a konzultanti Zhotovitele smí účastnit jen v omezeném a jasně předem definovaným způsobem, aby byl eliminován konflikt zájmů. Provedení testů příslušného funkčního celku Systému podle platného plánu zajistí vždy stanovení testeři Xxxxxxxxxxx nebo Objednatele, příp. třetích stran podle dříve vypracovaného plánu testování a testovacích scénářů. Všechny testy jsou realizovány na základě Zhotovitelem připravených a Objednatelem odsouhlasených testovacích scénářů a akceptačních kritérií testování. Konkrétní způsob provedení daného typu testu jednotlivých funkčních celků a celého Systému je součástí jeho detailního plánu testování a je v rámci tohoto detailního plánu odsouhlasen Objednatelem. Testeři ověřují celkovou funkčnost funkčních celků a celého Systému způsobem a v příslušných rolích Objednatele podle toho, jak bude cílově provozován v reálném provozu. Odstranění závad, resp. provedení nezbytných úprav z akceptačních testů provede Zhotovitel (příp. třetí strany
a nebude-li odstranění závady proveditelné bez součinnosti Objednatele, pak i s jeho součinností) v dohodnutém termínu. Bezodkladně po odstranění závad budou testy pro tyto závady přiměřeně zopakovány.
Realizace, tzn. provádění testování a řízení testerů, sledování a vyhodnocování defektů, řízení odstraňování chyb, koordinace třetích stran a nasazování systémů a oprav. Při provádění jednotlivých testovacích scénářů dochází k porovnání skutečné reakce Systému s reakcí očekávanou podle daného scénáře. Pokud se skutečná reakce Systému od očekávané reakce liší, je tento fakt označen jako defekt. Dalšími možnými důvody nesprávné očekávané reakce nebo nesprávné skutečné reakce Systému jsou defekty vyplývající z chyby testovacího scénáře, chyby testovacích dat, chyby v nastavení prostředí atd. Klasifikaci defektu provádí a zaznamenává tester při evidenci defektu. Defekt buď indikuje chybu (očekávaná reakce Systému je správná, ale skutečná reakce Systému se od ní liší), nebo změnu (Systém reaguje vzhledem k zadání správně, nesprávná je v tomto případě očekávaná reakce, kdy hlavním důvodem nesprávné očekávané reakce je nepřesná znalost zadání ze strany testera či pracovníka, který testovací případy/scénáře navrhoval) – defekt může vyústit v požadavek na změnu.
Ukončení, tzn. shrnutí výsledků testování. Důkladné zdokumentování realizovaných testů. Identifikace zbývajících neodstraněných chyb a akceptace daného typu testu. Test je možno ukončit, pokud byly provedeny všechny testovací případy a testovací scénáře, proběhla všechna naplánovaná kola (běhy) testů. Dokumentace o průběhu a výsledcích testu byla Xxxxxxxxxxxx připravena a schválena Objednatelem a byly stanoveny termíny oprav zbylých chyb a releasy, do nichž budou zahrnuty případné změnové požadavky. Výsledkem každého testování je Protokol o provedení testu, který obsahuje seznam případných závad s jejich popisem a klasifikací závažnosti spolu s dohodnutým způsobem a termíny jejich odstranění. Protokol o provedení testů vypracovává manažer testování za Zhotovitele a odsouhlasuje ho pověřený pracovník Objednatele (např. vedoucí projektu nebo vedoucí testování). Je předmětem projednávání a odsouhlasení řídicím výborem projektu. Protokol o provedení testu obsahuje dokumentaci realizovaného testu a jeho výsledek pro testovací scénáře jednotlivě i souhrnně a případně také seznam zbývajících neodstraněných chyb či nedostatků s jejich popisem, klasifikací závažnosti a dohodnutý způsob jejich odstranění spolu s termíny odstranění. Průběh testování a výsledky provedených případů a scénářů se zaznamenávají do protokolu průběžně nejlépe ke konci každého dne provádění testu. Výsledný Protokol o provedení testu zpracovává Zhotovitel a předkládá ho Objednateli k připomínkování a odsouhlasení a následnému potvrzení vedoucími projektu obou stran. Je přikládán jako nedílná příloha Protokolu o předání, je-li příslušné akceptované plnění ověřováno testem.

Objednatel požaduje, aby proběhly v rámci testování minimálně následující testy Systému, které mají za účel ověřit jeho různé vlastnosti.

Tabulka 19: Požadované typy testů

Typ testu

Obsah testu

Odpovědnost za provedení

Výstup

Jednotkový

Testují se funkce a jejich interakce; toto testování probíhá v simulovaném testovacím prostředí Zhotovitele.

Testovací prostředí musí umožňovat volání jednotlivých funkcí Systému, kontrolu výsledků a simulování vlivu jiných systémů. Tento test je interním testem vývoje a nebude směrem k Objednateli detailně komunikován.

Cílem je odhalení případných rozporů mezi implementací a specifikací funkcí Systému.

Po dohodě s Objednatelem mohou být některé části Systému vyjmuty z jednotkového testu.

Vývojáři Zhotovitele

Vývojáři dodavatelů systémů třetích stran

Protokol o provedení testu

Systémový funkční

Reálný test funkčnosti dodávaného řešení.

Provádí se ve vyvinutém Systému, který prošel jednotkovými testy.

Jedná se o testování jednotlivých subsystémů; za subsystém je v tomto případě považován modul, kombinace jednotlivých modulů
či ucelená funkční oblast, které byly v předchozích testech individuálně testovány

Simulovaně se testuje i správná funkce rozhraní mezi subsystémy (jednotlivými dílčími informačními systémy (vnitřními i externími)
či vlastním software) pomocí záslepek či simulátorů, které zastupují funkce okolních systémů.

Cílem tohoto testu je otestovat správnost a funkčnost řešení software a dále správnost ukládání a vyhledávání dat.

Zhotovitel (osoby odlišné od vývojářů)

dodavatelé systémů třetích stran (osoby odlišné od vývojářů)

Aktualizovaný dokument Strategie zkoušek a testování

Plán testu

Testovací případy a scénáře

Testovací data

Záslepky
či simulátory okolních systémů

Protokol o provedení testu

Integrační

Testování celého Systému (integrace modulů do celého Systému a okolních systémů)

Testuje se integrace všech subsystémů (jednotlivých informačních systémů či vlastní software).

Jedná se o test jednotlivých nastavených procesů z pohledu jejich celistvého provádění.

Test je prováděn Xxxxxxxxxxxx
a za omezené součinnosti Objednatele.

Cílem je najít a odstranit odchylky mezi vyvinutým Systémem a jeho skutečným chováním vytvořeného Systému jako integrovaného celku.

Zhotovitel (osoby odlišné od vývojářů) za úzké součinnosti všech dodavatelů integrovaných systémů třetích stran (osoby odlišné od vývojářů)

Aktualizovaný dokument Strategie zkoušek a testování

Plán testu

Testovací případy a scénáře

Testovací data

Protokol o provedení testu

Předintegrační

Může předcházet integračním testům, je to jejich zjednodušená forma, která slouží k ověření základních integračních vazeb, vzájemné komunikace, prostupů atp.

Předintegrační test je zařazen
či vyjmut z celkového konceptu testování v dohodě mezi Objednatelem a Zhotovitelem.

Cílem je ověřit, že Systém
jako celek správně pracuje, spolupracuje s okolními systémy, fungují základní integrační scénáře a všechna rozhraní jsou přístupná všemi příslušnými systémy

Zhotovitel (osoby odlišné od vývojářů) za úzké součinnosti všech dodavatelů integrovaných systémů třetích stran (osoby odlišné od vývojářů)

Aktualizovaný dokument Strategie zkoušek a testování

Plán testu

Testovací případy a scénáře

Testovací data

Protokol o provedení testu

Izolovaný výkonnostní

Testuje odezvy Systému
při simulované zátěži definované počtem uživatelů či připojených subjektů a testuje odezvy a doby zpracování Systému
při uchovávání, zpracovávání a přístupu k různým definovaným objemům dat. Výkonnostní testy slouží k ověření výkonových charakteristik, příp. k jejich doladění nebo posílení Systému. Objemy dat a počty testovaných uživatelů budou definovány.

Jedná se o test v simulovaném režimu pro ověření celkové výkonnosti software při provozu
se simulovaným počtem uživatelů plánovaných jako aktivně současně pracujících.

Je realizován Zhotovitelem.

Jeho úspěšné dokončení je podmínkou celkového převzetí dodávaného Systému.

Pro provádění tohoto testu
se obvykle využívají technické prostředky, které umožňují automatizovaně simulovat používání Systému velkým počtem uživatelů.

Následně po automatickém testování bývá tento test proveden i uživatelsky.

Cílem tohoto testu je ověřit chování Systému jako celku při plném provozu a zatížení jeho klíčových částí. Tyto parametry budou definovány během přípravy Implementační studie.

Zhotovitel (osoby odlišné od vývojářů)

dodavatelé systémů třetích stran (osoby odlišné od vývojářů)

Aktualizovaný dokument Strategie zkoušek a testování

Plán testu

Testovací případy a scénáře

Testovací data

Nastavené nástroje a pomůcky pro provádění testu

Protokol o provedení testu

Integrovaný výkonnostní

Integrovaný zátěžový (výkonnostní) test má podobné vlastnosti jako izolovaný výkonnostní s tím, že se uskutečňuje v produkčním prostředí.

Aktuální počet reálných údajů a dokumentů vzniklých z dat importovaných pro účel testu je doplněn simulovanými údaji a dokumenty na celkový Objednatelem stanovený počet údajů a dokumentů.

Zhotovitel (osoby odlišné od vývojářů) odpovídá za celkové řízení a faktické provedení testu za úzké součinnosti všech dodavatelů integrovaných systémů třetích stran (osoby odlišné od vývojářů)

Zhotovitel zajišťuje, řídí a provozuje všechny potřebné nástroje a pomůcky

Aktualizovaný dokument Strategie zkoušek a testování

Plán testu

Testovací případy a scénáře

Testovací data

Nastavené nástroje a pomůcky pro provádění testu

Protokol o provedení testu

Infrastrukturní

Testuje infrastrukturu a všechny její komponenty z pohledu jejich funkčnosti, spolupráce, dostupnosti a dalších souvisejících vlastností.

Ověřuje funkčnost infrastruktury jako celku i její funkčnost v různých situacích,
např. při poruše některých částí, výpadku některého nebo všech uzlů či celé lokality.

Součástí je test součinnosti produkční a záložní lokality,
vč. přenosu provozu z produkční na záložní lokalitu v případě nezbytnosti obnovení provozu
po havárii a zpět při obnovení pokojného normálního stavu.

Zhotovitel odpovídá za celkové řízení a faktické provedení testu za úzké součinnosti všech dodavatelů HW (třetích stran)

Aktualizovaný dokument Strategie zkoušek a testování

Plán testu

Testovací případy a scénáře

Protokol o provedení testu

Obnovy

Testuje se provedení obnovy
po havárii, čili provedení plánu obnovy po havárii obnovením Systému v záložní lokalitě a spuštění takto zajišťovaného náhradního provozu.

Zhotovitel (osoby odlišné od vývojářů) odpovídá za celkový dohled a případně také i řízení a faktické provedení testu za úzké součinnosti všech dotčených subjektů (osoby odlišné od vývojářů) a dodavatelů technologií)

Aktualizovaný dokument Strategie zkoušek a testování

Aktualizovaný dokument Plán obnovy po havárii

Testovací případy a scénáře

Protokol o provedení testu

Bezpečnostní a penetrační

Testuje bezpečnost Systému a všech jeho součástí, mj. počítačové sítě, formou simulovaného útoku na Systém a síť.

Jsou simulovány vnitřní a vnější hrozby.

Součástí přípravy testu je analýza zranitelností.

Předpokládá se, že bezpečnostní
a penetrační test zajistí Objednatel zčásti nebo celkově s pomocí vlastních zdrojů nebo prostřednictvím třetí strany. Konkrétní způsob provedení bude možno potvrdit až v průběhu projektu, když budou zpracovány informace, které umožní bezpečností test plánovat.

Celkové řízení (koordinace) je nadále součástí plnění Zhotovitele.

Aktualizovaný dokument Strategie zkoušek a testování

Testovací případy a scénáře

Analýza zranitelností

Bezpečnostní rizika a návrh na jejich odstranění

Protokol o provedení testu

Připravenosti k nasazení

Ověřuje připravenost k nasazení Systému a jeho běžného rutinního používání. Vedle technických a systémových aspektů se také zaměřuje se na proškolenost, připravenost vnitřních i vnějších uživatelů, technického personálu aj., nastavení procesů servisu a údržby, připravenost třetích stran, funkčnost nástrojů a pomůcek (např. interní HelpDesk, externí HelpDesk, resp. ServiceDesk třetích stran apod.)

Zhotovitel odpovídá za celkové řízení a faktické provedení testu

Test je prováděn zejm. určenými pracovníky Objednatele

Aktualizovaný dokument Strategie zkoušek a testování

Plán testu

Testovací případy a scénáře

Protokol o provedení testu

Uživatelský akceptační

Jedná se o test celé implementace na reálných datech podle předem schválených akceptačních scénářů.

Testuje se plně integrovaný Systém, který prošel úspěšně všemi předchozími typy testů.

Testují se vybrané funkce a vybrané procesy simulujících běžný provoz prováděných Objednatelem.

Cílem testu je odhalení zbývajících chyb a vytvoření podkladů pro předání vytvořeného a implementovaného Systému.

Zhotovitel odpovídá za celkové řízení a faktické provedení testu za úzké součinnosti všech dotčených subjektů, , uživatelů, třetích stran atp. (osoby odlišné od vývojářů) a dodavatelů technologií)

Test je prováděn zejm. určenými pracovníky Objednatele

Aktualizovaný dokument Strategie zkoušek a testování

Plán testu

Testovací případy a scénáře

Testovací data

Protokol o provedení testu

Protokol o dokončení

Regresní

Provedení vhodné kombinace výše uvedených typů testů v přiměřeném rozsahu za účelem ověření, zda dříve vyvinutý a otestovaný Systém po nějaké změně (např. po provedené opravě, aktualizaci, změně konfigurace aj.) má stále stejné vlastnosti jako původně otestovaný Systém.

Zhotovitel (osoby odlišné od vývojářů) v úzké součinnosti s Objednatelem,

dodavatelé systémů třetích stran (osoby odlišné od vývojářů)

Plán testu

Testovací případy a scénáře

Testovací data

Protokol o provedení testu

Objednatel požaduje, aby testy byly prováděny v prostředích příslušných danému typu testu. Zhotovitel v rámci dokumentu Implementační studie navrhne skladbu jím dodávaných testovacích prostředí podle následující tabulky, která obsahuje minimální požadavky Objednatele.

Zhotovitel zajistí potřebná prostředí pro provádění testů, přičemž bude respektovat Objednatelem požadovanou skladbu výpočetních prostředí.

Tabulka 20: Skladba výpočetních prostředí

	Jednotkový	Systémový funkční	Integrační předintegrační	izolovaný výkonnostní	Integrovaný výkonnostní	Infrastrukturní	bezpečnostní a penetrační	Připravenosti k nasazení	Uživatelský akceptační
Testovací u Zhotovitele	x			x
Vývojové (je-li Zhotovitelem zřízeno)		x
Testovací			x		x			x	x
Produkční						x	x

Objednatel požaduje, aby všechny nástroje, prostředky a pomůcky potřebné pro řízení a provádění testů kompletně poskytl Zhotovitel (vč. všech potřebných licencí, zajištění provozu a údržby, zaškolení pracovníků Objednatele a pracovníků subjektů zapojených do testování) a aby veškeré související ceny, poplatky či jiné náklady a výdaje byly zohledněny v nabídkové ceně Zhotovitele.

Objednatel poskytne Zhotoviteli pro účely testování součinnost v rozsahu odsouhlaseném v Implementační studii.

Zhotovitel v rámci dokumentu Implementační studie navrhne a popíše přístup k testování. Takto navržené a popsané postupy následně v souladu s harmonogramem projektu také zavede. Zhotovitel zejm. popíše:

Způsob testování a ověřování kvalitativních charakteristik na výstupy a Zhotovitelovo plnění s ohledem na ně specifikované požadavky a očekávané vlastností, pokrytí testů, trasování požadavků;
Celkový časový postup testů, návaznosti, rámcový harmonogram a milníky;
Způsob řízení testování a jeho organizaci, zodpovědné osoby a jejich role a jim příslušné činnosti;
Potřebná testovací data pro jednotlivé typy testů a způsob jejich přípravy;
Způsob komunikace a reportingu průběhu a výsledků testů;
Rizika a závislosti související s testováním;
Prostředí (jedno či více), které je potřebné pro provedení testů;
Nástroje využívané na podporu testování a způsob jejich správy (řízení, provoz, zaškolení atp.);
Standardy a normy, které je nutno dodržet;
Vstupní kontroly a kritéria nezbytná pro zahájení jednotlivých typů testů;
Výstupní kritéria indikující možnost ukončení jednotlivých typů testů.

Zodpovědnosti za provádění jednotlivých aktivit pro jednotlivé typy testů budou zpracovány formou RACI matice za využití přiloženého vzoru podle Tabulka 21: Aktivity v oblasti testování. Ke každé aktivitě musí být uvedena strana zodpovědná za úspěšné provedení dané aktivity spolu s vyznačením strany, která danou aktivitu fyzicky zajišťuje. Objednatel pro vyloučení pochybností připomíná, že testování (plánování, příprava, provedení a vyhodnocení) je součástí plnění Zhotovitele, přičemž Zhotovitel provede plánování, přípravu a řízení či koordinaci i těch testů či souvisejících aktivit, které bude provádět Objednatel či dotčené strany (např. uživatelské akceptační testy).

Tabulka 21: Aktivity v oblasti testování

Oblast / Test	Aktivita	Činnost	Zodpovídá za úspěšnost provedení	Zajišťuje
Oblast / Test	Aktivita	Činnost	Zodpovídá za úspěšnost provedení	Zhotovitel	Objednatel	Třetí strany
Celkové řízení testování	Řízení a vykazování průběhu provádění testů (probíhá průběžně po dobu testování)	[činnost 1.1]	[subjekt]
Celkové řízení testování		[činnost 1.2, Zhotovitel doplní další řádky dle potřeby]	[subjekt]
Označení testu [Zhotovitel zopakuje pro jednotlivé typy testů]	Příprava	[činnost x.1]	[subjekt]
	Příprava	[činnost x.2, Zhotovitel doplní další řádky dle potřeby]	[subjekt]
	Provádění testu	[činnost y.1]	[subjekt]
	Provádění testu	[činnost y.2, Zhotovitel doplní další řádky dle potřeby]	[subjekt]
	Řízení testu a vykazování stavu	[činnost z.1]	[subjekt]
	Řízení testu a vykazování stavu	[činnost z.2, Zhotovitel doplní další řádky dle potřeby]	[subjekt]

Zhotovitel v dokumentu Strategie zkoušek a testování uvede pro každý test jeho rámcovou specifikaci, kterou následně rozpracuje do plánů jednotlivých testů.

Tabulka 22: Parametry rámcové specifikace testů

Vlastnost testu	Detailní popis
Popis
Cíl
Rozsah
Zdroje
Lokalita
Systémové prostředí
Typ testovacích dat
Způsob testu
Vstupní kritéria
Výstupní kritéria

Zhotovitel uvede soupis všech navrhovaných nástrojů, prostředků a pomůcek potřebných pro řízení a provádění testů. Definuje potřebnou součinnost Objednatele v této oblasti, např. specifikaci potřebného výpočetního prostředí.

Zhotovitel v rámci návrhu testování uvede role osob zapojených do testování, jejich zodpovědností a součinnosti podle vzoru Tabulka 23: Role osob zapojených do testování.

Tabulka 23: Role osob zapojených do testování

Role	Zodpovědnost na straně Zhotovitele	Zodpovědnost na straně Objednatele

Zhotovitel navrhne, v Implementační studii popíše a v Projektu zavede postupy řešení chyb, které se vyskytnou během implementace Systému, zejm. během testování. Zhotovitel popíše tyto hlavní kroky, které vhodně doplní o další nezbytné činnosti:

Jak bude rozesílat požadavky na opravy chyb.
Jak bude konsolidovat a prioritizovat požadavky na opravy chyb.
Jak bude předávat požadavky na opravy chyb jejich řešiteli.
Jak budou požadavky na opravy chyb řízeny a sledovány vč. jejich kvalitativních a časových hledisek.
Jak bude subjekt, který uplatnil požadavek na opravu chyby, informován o průběhu opravy a jejím provedení.

Popis činností bude také obsahovat popis interakce s pomůckami, nástroji či aplikacemi, které budou v daném kroku používány. Činnosti budou řešeny ve své celistvosti od jejich začátku do konce. Budou též pokryty třetí strany, které budou do testování zapojeny, budou se ho účastnit nebo jím budou nějak dotčeny. Role a odpovědnosti budou zpracovány formou RACI matice.

Výstupy a výsledky realizace Projektu budou předávány Objednateli po jednotlivých etapách ve formě výstupů realizace představujících dílčí plnění. Akceptační řízení prověří shodu výstupů realizace se zadáním, které je definované v tomto technickém rámci a bude Zhotovitelem rozpracované v Implementační studii, případně dalších navazujících dokumentech schválených Objednatelem.

Pokud není stanoveno v Implementační studii jinak, pak jsou strany povinny se písemně dohodnout na termínu provedení akceptačního řízení s tím, že Zhotovitel oznámí, a to písemně nebo elektronicky, Objednateli připravenost k akceptačnímu řízení a Objednatel po přijetí tohoto oznámení oznámí Zhotoviteli termín akceptačního řízení, který Objednatel stanoví ve lhůtě minimálně 2 pracovní dny a maximálně 7 pracovních dnů od data sdělení připravenosti Zhotovitelem. Objednatel vyvine potřebnou součinnost pro zahájení akceptačního řízení v oznámeném termínu. Pokud Objednatel termín nemůže akceptovat, dojedná se Zhotovitelem nejbližší možný termín.
Zhotovitel poskytuje plnění Objednateli v požadované kvalitě a ve sjednaných termínech. Zhotovitel vždy připraví k akceptačnímu řízení veškeré součásti předávaného plnění, resp. částí plnění, a to v konečné podobě. Plnění musí být předáno ve stavu, aby umožňovalo provádění příslušného typu zkoušky nebo testu dle dohodnutého harmonogramu. Zhotovitel rovněž v rámci přípravy zkoušek či testů zajišťuje služby instalace a prezentace funkčnosti v příslušném zkušebním či výpočetním prostředí, školení týmu pro provedení zkoušky či testu apod., podle specifikace uvedené ve Strategii zkoušek a testování, resp. v příslušném Plánu zkoušky/testu.
Technický seznam položek zkoušek či testů bude vytvořen Zhotovitelem po předchozí dohodě s Objednatelem a odsouhlasen Objednatelem jako součást plánu příslušného zkoušky nebo testu, nejpozději však před zahájením realizace dílčího plnění, které bude těmito zkouškami nebo testy prověřováno.
K akceptaci každého dílčího plnění (etapy) Zhotovitel vyhotoví Protokol o dokončení podepsaný oběma stranami.
Další navazující etapu či je Zhotovitel oprávněn zahájit pouze po akceptaci aktuální etapy (resp. po akceptaci všech dílčích plnění náležících do této etapy a všech dílčích plnění spadajících do předchozích etap). Není-li tato podmínka splněna, může Zhotovitel zahájit následující etapu pouze s výslovným souhlasem Objednatele a za podmínek jím stanovených.
K úspěšné akceptaci a předání Díla jako celku Zhotovitel vyhotoví Protokol o dokončení podepsaný oběma stranami. Systém jako celek bude akceptován, pokud jsou úspěšná všechna předcházející akceptační řízení, je provedeno úspěšné akceptační řízení za pátou (5.) etapu realizace a jsou podepsány všechny Protokoly o dokončení.
Součástí akceptace je mimo jiné i akceptace správnosti dat a naplnění pasportizovaných údajů, tzn., že probíhá bez provozních problémů komunikace mezi všemi spolupracujícími systémy, je funkční aktivní správa telematických zařízení a probíhá sběr údajů o jejich provozním stavu. Zhotovitel sice negarantuje věcnou správnost dat v případě, kdy tato je převážně závislá na třetí straně (není-li tato třetí strana subdodavatelem Zhotovitele) nebo na Objednateli, ale i pro tento případ se Zhotovitel ve spolupráci s Objednatelem zavazuje vyvinout maximální úsilí k zajištění věcné správnosti dat, když se o existenci takového problému dozvěděl, nebo při odborné péči měl dozvědět, a bez zbytečného odkladu navrhne Objednateli účinné řešení problému.
V případě, že Objednatel neuvede do Protokolu o dokončení Zhotoviteli seznam vad a výsledkem akceptace bude „akceptováno bez výhrad“, je daná etapa akceptována a považuje se ze strany Zhotovitele za řádně předanou a ze strany Objednatele za převzatou a schválenou.
Danou etapu je možné, po dohodě obou stran, akceptovat s výhradami, pokud obsahuje určité předem stanovené množství nepodstatných vad, které nebrání zásadně v užití Systému nebo jeho části. V takovém případě uvedou strany do Protokolu o dokončení v rámci akceptačního řízení seznam výhrad, které je Zhotovitel povinen odstranit ve lhůtě, která je sjednána stranami.
V případě neakceptování dané etapy Objednatelem jsou smluvní strany povinny uvést do Protokolu o dokončení v rámci akceptačního řízení seznam vad, které je Zhotovitel povinen odstranit ve lhůtě, která bude sjednána stranami, přičemž tato sjednaná lhůta nemá vliv na původní termín a případné prodlení Zhotovitele.
V případě výsledku akceptačního řízení „akceptováno s výhradou“ se považuje daná etapa ze strany Zhotovitele za řádně předanou a ze strany Objednatele za převzatou a schválenou okamžikem odstranění identifikovaných vad, uvedených v Protokolu o dokončení a podpisem nového Protokolu o dokončení, v němž je uvedena skutečnost, že došlo k odstranění identifikovaných vad.
V případě výsledku akceptačního řízení "neakceptováno a je vráceno k přepracování" oznámí Zhotovitel po odstranění vad, které bránily akceptaci dané etapy,Objednateli nejpozději ve stranami sjednané lhůtě připravenost k opakovanému akceptačnímu řízení.
Akceptace je dokončena podpisem Protokolu o dokončení, ve kterém bude výslovně uvedeno, že příslušná etapa je bez vad a nedodělků.
Akceptační řízení proběhne na systémech a prostředí Objednatele (není-li stranami dohodnuto jinak) a za součinnosti zástupců obou smluvních stran.
Objednatel má právo v rámci akceptačního řízení si vyžádat fyzickou přítomnost oprávněných zaměstnanců Zhotovitele v sídle Objednatele.

Akceptační řízení probíhá tímto postupem:

Zhotovitel předloží Objednateli výstup (výsledek etapy), který je předmětem akceptačního řízení současně s návrhem příslušného Protokolu o dokončení včetně všech jeho příloh (např. Protokol o provedení testu), který si předtím vedoucí projektu Zhotovitele a Objednatele vzájemně odsouhlasili.
Zhotovitel je povinen zajistit, aby zkouška či test dané etapy byl kompletně proveden nejpozději v příslušném termínu stanoveném harmonogramem.
V případě, že výstup neobsahuje žádnou vadu, výsledkem akceptace je „akceptováno bez výhrad“.
Obsahuje-li výstup určité předem stanovené množství nepodstatných vad, může být výsledkem akceptace po dohodě obou stran „akceptováno s výhradou“. Objednatel může v Protokolu o dokončení s výsledkem „akceptováno s výhradou“ určit, že Xxxxxxxxxx je do doby odstranění vytčených vad a nedodělků oprávněn pokračovat v plnění předmětu Smlouvy v rámci následující etapy.
V ostatních případech je výsledkem akceptace „neakceptováno a je vráceno k přepracování“. Celý postup se opakuje. Výstup nadále nesplňuje akceptační kritérium a Zhotovitel se tímto může ocitnout s jeho předáním v prodlení.
Pokud se ani ve druhém opakování akceptačního řízení nepodaří splnit akceptační kritérium (tzn., že výstup nesplní akceptační kritérium ani napotřetí) jedná se o závažné porušení povinnosti Zhotovitele. Vedoucí projektu na straně Objednatele navrhne další postup a předloží jej řídicímu výboru ke schválení a současně zahájí příslušný postup (např. podle eskalačního procesu).

Pro potřeby hodnocení výsledů zkoušek a testů a stanovení příslušných akceptačních kritérií jsou všechny defekty, chyby, vady, nedostatky a nedodělky zařazeny a kategorizovány podle své závažnosti do jedné ze čtyř kategorií A, B, C a D. Pro upřesnění v této souvislosti Objednatel uvádí, že popis defektu či vady musí obsahovat relevantní informace, aby z tohoto popisu bylo zřejmé zařazení do určité kategorie.

Tabulka 24: Kategorizace defektů a vad plnění typu software

Úroveň závažnosti

Stručný popis

Podrobný popis

Kritická

Selhání Systému

Nelze v testu dále postupovat

Kritický dopad na chování celého Systému jako funkčního celku. Systém je buď zcela nefunkční, nebo neumožňuje využívat zásadní jeho funkce. Došlo k nenahraditelné ztrátě dat nebo k jejich neopravitelnému poškození. Neexistuje žádné náhradní řešení. Systém nelze nasadit. Systém havaruje a je nepoužitelný. Situace způsobuje vážné provozní problémy. Ve zkouškách nebo testování nelze pokračovat.

Vysoká

Omezená funkčnost určité části Systému

Nelze v testu dále postupovat v části Systému, u některých funkcí

Taková degradace funkce či výkonnosti Systému nebo jeho funkčního celku, že tento stav omezuje běžné užívání Systému nebo jeho provoz. Činnosti poskytované Systémem jsou výrazně ovlivněny z důvodu omezení funkcí některého z funkčních celků Systému. Systém nebo jeho významnou část není možné spustit nebo používat.

Systém jako celek může být funkční, ale některá jeho část nepracuje vůbec nebo pracuje v podstatných aspektech v rozporu s jeho stanovenými vlastnostmi. Se Systémem jako celkem je sice možné pracovat, ale pro ovlivněnou část neexistuje žádné náhradní řešení.

V případě současného výskytu více vad kategorie B může nastat situace, kdy vzájemné působení těchto vad způsobí kumulaci negativního dopadu tak, že závažnost dopadu bude odpovídat podmínkám kategorie A.

Lze pokračovat ve zkouškách nebo testování jiné části Systému.

Střední

Omezená funkčnost

Lze v testu dále postupovat při určitých omezeních

Část Systému není plně funkční nebo část Systému funguje v rozporu se stanovenými vlastnostmi. Existuje určité dočasné náhradní řešení. Malé dopady na funkčnost Systému jako celku či na jeho funkční celky. Ve zkouškách nebo testování lze pokračovat s vynecháním dotčené části.

Nízká

Malé nebo kosmetické chyby

Lze v testu dále postupovat

Neovlivňuje výrazně některou funkci Systému. Nepoškozuje data. Neznamená žádné uživatelské omezení uživatelských funkcí Systému ani významné prodlužování časů zpracování oproti standardnímu časovému nastavení příslušných funkcí. V zásadě se jedná o kosmetické chyby. Použitelnost může být jistým způsobem omezena, ale bez dopadu na funkčnost Systému. Existuje náhradní řešení bez výrazného dopadu na funkčnost i použitelnost.

Ve zkouškách nebo testování lze pokračovat.

Kategorii defektu či vady vždy posoudí pracovník Objednatele odpovědný za provedení příslušné zkoušky nebo testu s pracovníkem Zhotovitele, který odpovídá za danou zkoušku nebo test. Neshodnou-li se na kategorii vad, posoudí a rozhodnou o kategorii vady oba vedoucí projektu. Neshodnou-li se ani tito na kategorii vad, platí až do dalšího rozhodnutí stanovisko Objednatele.

Hlavní pravidla pro odstraňování defektů jsou stanovena takto:

Chyby s kritickou závažností musí být opraveny a přetestovány ještě ve stejném testovacím cyklu (běhu).
Chyby s vysokou a střední závažností musí být opraveny a přetestovány do konce provádění daného typu testu.
Chyby s nízkou závažností musí být odstraněny podle určení Vedoucího projektu Objednatele, přičemž k plánovanému termínu ukončení daného typu testu musí být stanoven termín pro jejich odstranění.
Změnové defekty jsou postoupeny jako vstup do změnového řízení.

Specificky pro potřeby hodnocení výsledů ověřování Dokumentace, které je prováděno způsobem jejího revidování a připomínkování, jsou pro tento účel samostatně definovány typy defektů Dokumentace podle závažnosti vznesených připomínek.

Tabulka 25: Kategorizace defektů a vad Dokumentace podle jejich závažnosti

Závažnost připomínky	Popis
A Kritická připomínka	Kritická připomínka, která znamená, že bez jejího zapracování nelze považovat výstup za řádně zpracovaný. Výstup by obsahoval podstatné chyby či nedostatky, nebyl by použitelný, nemohl by být použit jako vstup pro následné aktivity Projektu.
B Podstatná připomínka	Podstatná připomínka, která významným způsobem ovlivňuje připomínkovanou problematiku. Pokud by tato připomínka nebyla řádně vypořádána, mohlo by to způsobit významný dopad do návrhu řešení, výslednou podobu Systému, provoz Objednatele, jím vykonávané agendy nebo agendy jeho partnerů atp. Pokud se nepodaří tuto připomínku zapracovat během připomínkového řízení, musí být způsob a termín jejího zapracování oběma stranami schválen, samostatně sledován a evidován (např. v registru problémů a otevřených otázek).
C Nezávažná připomínka	Připomínka je evidována, je schválen způsob jejího zapracování (např. úprava či doplnění dokumentu), ale tuto úpravu není nutno provádět bezprostředně. Zhotovitel připomínku zapracuje do výstupu v termínu, který je uveden v Protokolu o dokončení

Tabulka 26: Akceptační kritérium plnění typu software – limitní počty přípustných defektů v jednotlivých kategoriích testů

Test	Počty přípustných defektů v jednotlivých kategoriích
Test	A	B	C	D
Jednotkový test	Nesleduje se, Zhotovitel pouze poskytne protokoly o provedení testů
Systémový funkční test	0	0	50	Není rozhodné
Integrační test	0	0	35	Není rozhodné
Výkonnostní test	Vyhodnocuje specificky, nikoli podle počtu chyb
Uživatelský akceptační test	0	0	25	Není rozhodné
Test vysoké dostupnosti	0	0	5	Není rozhodné
Bezpečnostní test	0	0	5	Není rozhodné
Připravenost k nasazení	0	0	8	Není rozhodné

Tabulka 27: Akceptační kritérium plnění typu dokument – limitní počty přípustných defektů (otevřených připomínek) v jednotlivých kategoriích

Limitní počty otevřených připomínek	Počty přípustných otevřených připomínek v jednotlivých kategoriích
Limitní počty otevřených připomínek	A	B	C
Počet	0	15	30

Objednatel uvádí následující přehled vyžadovaných metod akceptace pro příslušné typy plnění.

Tabulka 28: Metody akceptace různých typů plnění

Název metody (kódové označení)	Popis metody
Akceptace plnění typu software	Plnění mající charakter software se ověřuje příslušnými typy testů, které jsou vymezeny v dokumentu Strategie zkoušek a testování. Akceptačním kritériem je výsledný počet chyb podle jejich kategorie A, B, C a D platný pro daný typ testu.
Akceptace výkonnostních parametrů	Chování Systému z pohledu jeho výkonnosti je součástí ověřování během uživatelského akceptačního testu, samostatně během integrovaného výkonnostního testu a izolovaného výkonnostního testu. Předmětem hodnocení jsou časy odezev či doby zpracování procesů od jejich začátku až po jejich ukončení, tedy Systému plně integrovaného do prostředí Objednatele. Požadované celkové hodnoty výkonnostních indikátorů jsou takto koncipovány – bude upřesněno v Implementační studii. Součástí některých indikátorů je rovněž čas pro zpracování souvisejících činností uživateli nebo čas pro obdobné zpracování, přičemž čas pro zpracování souvisejících činností uživateli nebo čas pro obdobné zpracování není součástí hodnocení výkonnostních indikátorů během ověřovacího provozu. Výkonnost je akceptována, pokud je dosaženo nejméně 90 % stanovených výkonnostních indikátorů měřených v procesech či transakcích od jejich začátku až po jejich ukončení a pro zbývajících 10 % výkonnostních indikátorů není jejich hodnota překročena o více než 30 % (viz popis níže). Vyhodnocování výkonnostních indikátorů se provádí na hodinových / denních / týdenních vzorcích, jak je pro každý výkonnostní indikátor stanoveno podle jeho povahy příslušného měřeného procesu či transakce. Výkonnostní procesní indikátor, který nebude možno změřit či vyhodnotit vzhledem k chybě standardního software třetí strany, nebude v hodnocení zvažován. Akceptační kritérium výkonnostního testu je definováno takto: Je vyhodnoceno splnění hodnot 90 % stanovených výkonnostních indikátorů a hodnota každého jednotlivého ze zbývajících 10 % indikátorů není překročena o více než 30 % hodnoty tohoto indikátoru. Hodnocení výkonnosti prováděné jako součást uživatelského akceptačního testu se provádí na bázi sledování týdenních / denních či hodinových vzorků podle povahy sledované aktivity, která odpovídá danému indikátoru. Indikátory, které byly z hodnocení vyloučeny nebo se staly neměřitelnými (např. z důvodu chyby v Systému či komponentě některé třetí strany), nejsou do hodnocení zahrnuty. Předmětem akceptace jsou pouze doby odezvy nebo jiné určené výkonnostní charakteristiky Systému či jeho modulů (funkčních celků), které jsou předmětem dodávky Zhotovitele, a to s odečtením časů odpovídajících interakci uživatelů (např. délka zadání některého vstupního údaje) a s odečtením časů zpracování v jiných systémech (např. další systémy připojené přes integrační vazby). Indikátory, které souvisejí s aktivitami uživatelů, a výkonnostní charakteristiky, které budou těmito indikátory takto vyhodnocovány, musí mít obvyklá trvání uživatelských interakcí v sobě zohledněny tak, aby indikátorem bylo možno postihnout celkové obvyklé trvání aktivity od jejího spuštění uživatelem až do jejího ukončení. Měření indikátorů, které v sobě zohledňují interakce uživatelů a které bude prováděno během pilotního provozu, nebude zavdávat příčinu pro případnou penalizaci Zhotovitele pro neplnění výkonnostních parametrů či jiných hodnot daných dohodou o úrovni služeb (SLA).
Akceptace ověřovacího provozu	Způsob akceptace ověřovacího provozu je definován takto: Pro akceptaci ověřovacího provozu se budou vyhodnocovat stanovené limitní počty defektů spolu s dalšími pravidly, které nahlížejí na stabilitu a bezchybovost Systému. Nevyřešené defekty a chyby, jejichž řešení je v kompetenci Objednatele (např. chyby v připojených stávajících systémech Objednatele nebo v systémech dotčených stran) neovlivňují celkové hodnocení ověřovacího provozu a do výpočtů vstupují jako by byly vyřešeny a odstraněny. Ověřovací provoz je možno ukončit a akceptovat, pokud se během dvou nepřerušených kalendářních týdnů předcházejících plánovanému konci ověřovacího provozu nevyskytne ani jeden defekt typu A a současně ani jeden defekt typu B a současně zůstane maximálně 20 otevřených defektů typu C. V případě, že během ověřovacího provozu se nepodaří dosáhnout tohoto stavu, ověřovací provoz se prodlužuje o další 2 týdny. Objednatel může během ověřovacího provozu používat obvyklé testovací prostředky a pomůcky určené pro ověřování v provozním prostředí, např. různá testovací zařízení. Vyskytnou-li se nějaké závady na některém z těchto zkušebních či testovacích zařízení, bude se během ověřovacího provozu postupovat už podle standardních provozních postupů. Vytvoří se standardní incident, který bude řešen standardními postupy. Řešení tohoto incidentu bude současně vstupovat do příslušných charakteristik hodnocených při ověřovacím provozu. Vady, které byly Zhotovitelem odsouhlaseným způsobem opraveny a otestovány, ale jejichž opravy nejsou ještě promítnuty do provozního prostředí Objednatele, jsou považovány za vyřešené.

Akceptace dokumentů	Tímto postupem se akceptují pouze výstupy, které mají povahu dokumentů či dokumentace. Výstup typu dokumentace musí být nejprve předán v podobě finální pracovní verze určené k připomínkování. Oprávněná osoba Zhotovitele zašle Objednateli výstup typu dokumentace (jeden dokument či jejich sadu), který je připraven k akceptaci, předem domluveným způsobem, např. zasláním dokumentu elektronickou poštou nebo zasláním odkazu do úložiště dokumentace atp. Objednatel pošle Zhotoviteli nejpozději do 10 pracovních dnů po zaslání finální pracovní verze určené k připomínkování své písemné připomínky. U každé připomínky uvedené v protokolu bude uvedena její závažnost. V případě nutnosti může Objednatel dohodnout se Zhotovitelem na prodloužení lhůty pro připomínkování. Prodloužení lhůty si potvrdí oba vedoucí projektu vhodnou písemnou formou, např. emailem. Nejdéle do 5 pracovních dnů po zaslání připomínek zapracuje Zhotovitel připomínky do výstupu a zašle aktualizovanou verzi výstupu se zapracovanými připomínkami spolu s protokolem o vypořádání připomínek, v němž uvede způsob, jakým byla připomínka vypořádána, např. text v dokumentu byl upraven, připomínka byla vysvětlena, připomínka byla zapracována zcela nebo částečně zohledněno apod. Nejdéle do 5 pracovních dnů po zaslání aktualizované verze výstupu a doplněného protokolu o vypořádání připomínek zkontroluje Objednatel řádnost vypořádání jeho připomínek v aktualizované verzi výstupu a zkontroluje protokol. V protokolu o vypořádání připomínek Objednatel vyznačí, které připomínky jsou řádně vypořádané a které jsou nadále otevřené. Při kontrole aktualizovaného výstupu může Objednatel doplnit další připomínky zejména k aktualizovaným či doplněným částem výstupu. Dosáhne-li počet otevřených připomínek limitního počtu, viz Tabulka 27, kritérium akceptace tohoto výstupu typu dokumentace bylo splněno. Vedoucí projektu Objednatele o této skutečnosti informuje vedoucího projektu Xxxxxxxxxxx. Vedoucí projektu na straně Xxxxxxxxxxx připraví návrh příslušného Protokolu o dokončení a zašle jej vedoucímu projektu na straně Objednatele k revizi. Nedosáhne-li počet otevřených připomínek limitního počtu, celý postup se opakuje. Výstup nadále nesplňuje akceptační kritérium a Zhotovitel se tímto může ocitnout s jeho předáním v prodlení. Pokud není počet otevřených připomínek v přípustném limitu ani po druhém opakování tohoto postupu, tzn., že výstup nesplní akceptační kritérium ani napotřetí, jedná se o závažné porušení povinnosti Zhotovitele. Vedoucí projektu na straně Objednatele navrhne další postup a předloží jej řídicímu výboru ke schválení a současně zahájí příslušný postup (např. podle eskalačního procesu). Dokumentace se má za akceptovanou ke dni, kdy Objednatel schválil aktualizovanou verzi výstupu společně s upraveným protokolem o vypořádání připomínek. Objednatel je povinen pro připomínkování výstupu a následnou kontrolu jeho aktualizované verze vynaložit potřebnou součinnost, zejména zajistit dostupnost příslušných pracovníků. Závažnost připomínky určuje Objednatel. Pokud se nad označením závažnosti připomínky nepodaří najít shodu, postupuje se dále podle eskalačního procesu s cílem najít shodu nad závažností připomínky. Než bude taková shoda nalezena, považuje se stupeň závažnosti připomínky za takový, jak jej určil Objednatel. Bude-li ve výsledku eskalačního procesu závažnost připomínky snížena, má toto snížení kategorie účinnost k původnímu datu uplatnění připomínky Objednatelem (tzn. i zpětně) se všemi důsledky s tím spojenými. V případě, že se mezi Zhotovitelem a Objednatelem nepodaří dosáhnout shody nad způsobem vypořádání určité připomínky a autor připomínky její vypořádání nepovažuje nadále za řádné, postupuje se dále podle eskalačního procesu s cílem najít vhodný způsob vypořádání připomínky.
Akceptace migrace dat	Xxxxxxx se považuje za úspěšnou, pokud bylo způsobem určeným v Migrační strategii a dále rozpracovaných v příslušných plánech přemigrováno nejméně 99,7 % dat určených k migraci, přičemž správnost a úplnost dat přemigrovaných do nového Systému byla úspěšně validována stanoveným způsobem validace a rekonciliace a současně byl stanoven termín a způsob přenesení a dat, které se nepodařilo takto přemigrovat.
Akceptace školení	Školení je považováno za akceptované jeho provedením, kdy byla současně účastníky podepsána prezenční listina, a od všech účastníků byl převzat dotazník zjišťující zpětnou vazbu k danému školení. Školící materiály a pomůcky se akceptují metodou akceptace výstupních dokumentů projektu.
Akceptace provedeného úkolu	Provedený úkol je považován za akceptovaný, pokud příjemce výsledku tohoto úkolu (např. technický tým Objednatele instaluje předávaný software) písemně potvrdí, že Xxxxxxxxxx provedl zadaný úkol v dohodnutém rozsahu, čase a místě, a že úkol byl proveden personálem Zhotovitele s potřebnými schopnostmi.
Akceptace dodávky prostředí	Prostředí je považováno za akceptované, pokud zodpovědná osoba Objednatele písemně potvrdí, že příslušné výpočetní prostředí bylo úspěšně naistalováno a zprovozněno. Tento postup se použije rovněž pro nastavování, konfigurování či podobné administrátorské zásahy prováděné Zhotovitelem.
Akceptace předávaných položek	Předávané položky, které nejsou předmětem specifického typu zkoušky nebo testu či akceptace, se předávají a přebírají na základě předávacího protokolu podepsaného odpovědnými osobami obou smluvních stran, ve kterém je uveden soupis předávaných položek (spolu s jejich stručným popisem, pokud ze samotného textu předávané položky není plně zřejmý její obsah).

SEZNAM ZKRATEK
Zkratka	Vysvětlení
BLK	Blikače
DB	Databáze
DD	Zařízení pro určení dojezdových dob
DJČ	Detekce jízdy na červenou
DŘÚ	Dopravní řídící ústředna
DSPS	Dokumentace skutečného provedení stavby
GIS	Geografický informační systém
HDŘÚ	Hlavní dopravní řídící ústředna
IMS	Imisní monitorovací stanice
IOT	Internet of Things
KK	Koordinační kabely
KVD	Klimatické vozovkové detektory
KVV	Kontrola výšky vozidel
MÚR	Měření úsekové rychlosti
MOR	Měření okamžité rychlosti
MV	Městská vybavenost
NBD	Next business day
OK	Optické kabely
OKM	Optické kabely v metru
OT	Optické trubky
OTM	Optické trubky v metru
PAR	Parkovací systémy
PDZ	Proměnné dopravní znační
ŘS	Řídicí systém
SSDÚ	Strategické dopravní detektory úsekové
SSDŘ	Strategické dopravní detektory řezové
SSZ	Světelná signalizační zařízení
TDS	Telematický dohledový systém
TSK	Technická správa komunikací hl. m. Prahy, a.s.
TUN	Systémy řízení v tunelech
TVD	Kamery televizního dohledu
XXX	Xxxxxx vozidel
ZD	Zadávací dokumentace
ZPI	Zařízení pro provozní informace
ZTP	Parkovací čidla

SEZNAM POJMŮ
Zkratka	Vysvětlení
Akceptace díla	znamená převzetí Díla Objednatelem po úspěšném Uvedení do provozu v souladu s požadavky Smlouvy o dílo. Je provedeno podepsáním Protokolu o dokončení, vyhotoveného v souladu se Smlouvou o dílo.
Dílo	znamená souhrn dodávek Zboží, poskytnutí práv z duševního vlastnictví, provedení prací a služeb, které mají být Zhotovitelem provedeny podle podmínek Xxxxxxx o dílo včetně jejích příloh a které v souhrnu směřují k vytvoření kompletního, provozuschopného, bezpečně a plynule provozovatelného Systému, který dosahuje parametrů požadovaných Smlouvou o dílo a jejími přílohami. Dílo se skládá z pěti Etap.
Dokumentace	znamená jakoukoliv dokumentaci, zejména dokumentaci programovou, technickou, testovací, vývojářskou, produktovou, výrobní, provozní, řídící, prováděcí a realizační, týkající se provádění Díla.
Etapy	znamenají jednotlivé fáze provádění Díla v souladu s odst. 6.1 Smlouvy o dílo.
Komplexní podpora	znamená souhrn veškerých služeb, dodávek zboží, podpory, údržby a servisu Systému prováděných Zhotovitelem na základě Smlouvy o podpoře. Součástí Komplexní podpory je i odstraňování případných vad Systému.
Licence	znamenají licence poskytnuté Zhotovitelem Objednateli podle odst. 12.4 Smlouvy o dílo.
Objednatel	znamená právnická osoba uvedená v článku 1 Smlouvy o dílo jako „Objednatel“ a v článku 1 Smlouvy o podpoře také jako „Objednatel“
Paušál	znamená částku odpovídající jedné šedesátině (1/60) ceny, která je blíže specifikována v odst. 6.1.1 Smlouvy o podpoře.
Podpora	znamená poskytování Komplexní podpory a Rozšířené podpory Zhotovitelem na základě Smlouvy o podpoře.
Projekt	znamená projekt, který má vést k nalezení inovativního řešení správy Telematického majetku v Praze. Pro potřeby tohoto technického rámce se jedná o souhrnné označení pro realizaci Díla a poskytování Podpory Zhotovitelem.
Rozšířená podpora	znamená souhrn veškerých služeb prováděných Zhotovitelem dle odst. 4.3 Smlouvy o podpoře.
Služby	znamenají veškeré činnosti Zhotovitele nezbytné pro provedení Komplexní podpory.
Xxxxxxx o dílo	Znamená smlouvu o dílo provedení výzkumu a vývoje, jíž se Zhotovitel zavazuje k řádnému a včasnému provedení Díla a Objednatel se zavazuje k zaplacení smluvní ceny za řádné a včasné provedení Díla.
Smlouva o podpoře	znamená smlouvu o poskytování podpory systému, která je uzavřena mezi Objednatelem a Zhotovitelem současně se Smlouvou o dílo, za účelem zajištění Podpory. Smlouva o podpoře je závislou smlouvou na Smlouvě o dílo.
Smluvní pokuta	znamená smluvní pokutu sjednanou ve Xxxxxxx o dílo mezi Objednatelem a Xxxxxxxxxxxx, kterou Xxxxxxxxxx Objednateli zaplatí v případě, že Xxxxxxxxxx nesplní své povinnosti uvedené ve Xxxxxxx o dílo.
Systém	znamená Zhotovitelem vytvořený centrální IT systém uceleného moderního řešení, který poskytne Objednateli komplexní a efektivní možnost správy Telematického majetku. Systém je předmětem Díla.
Telematický majetek	znamená majetek uvedený v kapitole 3 tohoto technického rámce, který je ve vlastnictví hlavního města Prahy a který je spravován Objednatelem. Telematický majetek tvoří telematické zařízení a s nimi související SW nástroje a aplikace, které jsou na tato telematická zařízení navázány.
Uvedení do provozu	znamená uvedení Systému do reálného provozu. Uvedení do provozu bude provedeno v rámci páté (5.) Etapy a je předpokladem pro Akceptaci díla.
Zboží	znamená vybavení, zařízení, hardware, materiály, samostatné výrobky a dodávky materiálů všeho druhu, které mají být zajištěny, dodány, instalovány a přezkoušeny Zhotovitelem v souladu se Smlouvou o dílo.
Zdrojové kódy	znamenají kódy a související konfigurační soubory k veškerému programovému vybavení Systému vytvořené Zhotovitelem při plnění Smlouvy o dílo, které vytvářejí kompletní programovou dokumentaci.
Zhotovitel	znamená právnická osoba uvedená v článku 1 Smlouvy o dílo jako „Zhotovitel“ a v článku 1 Smlouvy o podpoře také jako „Zhotovitel“

1 xxxx://xxx.xxx-xxxxx.xx/xxx/xxxxxx/xxxx/x-xxxxxxxxxxx/x-xxxxxxxxxxx-XXX-Xxxxx/#xxxx

Subjekt komunikace

(Komu)

Informace

(Co)

Důvod

(Proč)

Časový údaj

(Kdy)

Způsob komunikace

(Jak)

Zodpovědná osoba/role/ skupina

(Kým)