Upozornění: Text přílohy byl získán strojově a nemusí přesně odpovídat originálu. Zejména u strojově nečitelných smluv, kde jsme použili OCR. originál smlouvy stáhnete odsud
H EVROPSKÁ UNIE
Evropský fond pro regionální rozvoj
Operační program Podnikání
a inovace pro konkurenceschopnost
2.5 Technologická architektura
Zadavatel požaduje v maximální možné míře využít stávající vlastní technickou infrastrukturu (datové centrum,
klimatizační technika, síťová infrastruktura, virtualizační prostředí) a neplánuje pro DTM budovat nové
Obrázek 22 - Schéma technologické architektury IS DTM ŘSD
Technologické prostředí bude umožňovat provoz Systému ve dvou nezávislých a geograficky oddělených
lokalitách spolu s redundancí HW a SW komponent v primární lokalitě. Záložní lokalita bude umožňovat obnovu
provozu v případě havárie primární lokality alespoň pro komponentu „Správa ZPS, Dl, TI a ostatních dat RSD“
a funkcionality, které jsou potřebné k jejímu běhu. Požadovaná dostupnost v rámci primární lokality musí splňovat
minimálně následující vlastnosti:
• Active-Passive clustering na všech SW vrstvách (prezentační/aplikační/databázová),
• řešení musí být na SW úrovni horizontálně škálovatelné,
• výpadek jednoho HW prostředku (serveru, síťového prvku. SAN infrastruktuiy) nesmí znamenat výpadek
řešení v primární lokalitě,
• v případě Wpadku jedné komponenty, nesmí být výkon z pohledu uživatelů významně omezen tak, aby bylo
oliroženo dodržení stanoveného SLA,
• řešení musí podporovat průběžnou replikaci dat v plném rozsahu do záložní lokality (použití synchronní prip.
asynchronní replikace dat vyplyne z provedené Úvodní analýzy a návrhu IS DTM ŘSD),
• replikace dat do záložní lokality nenahrazuje zálohování dat celého Systému.
Zadavatel poskytne Zhotoviteli HW a SW technologie dle přílohy č. lc tohoto dokumenňi pro realizaci a provoz
IS DTM ŘSD. Zadavatel garantuje, že výše uvedené technologické vybavení, které má k dispozici ve svém
majetku, poskytne bezplatně včetně zajištění maintenance Zhotoviteli pro realizaci Projektu.
2.6 Úvodní analýza a řízení projektu
2.6.1 Úvodní analýza a Definice Projektu
Před zahájením vývoje, dodávky a implementace Systému provede Zhotovitel nezbytnou Úvodní analýzu, která
bude vycházet z požadavků této technické specifikace a během které odborní konzultanti Zhotovitele zanalyzují a
popíší stávající prostředí a procesy Zadavatele, upřesní funkční i nefunkční požadavky na jednotlivé komponenty
Stránka 61
H EVROPSKÁ UNIE
Evropský fond pro regionální rozvoj
Operační program Podnikání
a inovace pro konkurenceschopnost
IS DTM ŘSD s odbornými pracovníky Zadavatele a navrhnou postup a detailní technické specifikace pro
implementaci IS DTM ŘSD včetně návrhu způsobů akceptace plnění a nastavení celkových hodnot výkonnostních
indikátorů.
Základní technologický rámec Projektu, jako výstup Úvodní analýzy Zhotovitele, bude definován v dokumentu
„Definice Pro jektu , který bude zpracován v rámci 1. Etapy realizace IS DTM ŘSD a který bude následně
výchozím bodem pro zpracování detailních Cílových konceptů každé z Etap.
Dokument Definice Projektu musí obsahovat popis minimálně následujících oblastí:
• popis současného stavu prostředí Zadavatele a připravenost prostředí i organizace Zadavatele a dotčených
subjektů na implementaci IS DTM ŘSD
• popis základní architektury řešení IS DTM ŘSD včetně komponent/modulů, funkčních celků, popisu a vazeb
na okolní systémy.
• výčet funkčních i nefunkčních požadavků a určení jejich realizace/splnění do 3 Etap.
• popis rozdělení vývoje do 3 Etap dle harmonogramu realizace.
• 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í.
• popis koncepce členění uživatelů Systému, jejich rolí a oprávnění.
• popis koncepce datového modelu.
2.6.2 Definice a řízení Projektu
Nedílnou součástí nabídky Zhotovitele byl Popis navrhované metodiky projektového řízení a způsobu řízení
projektu, který popsal návrh govemance a způsobu projektového řízení celého projektu a který musí vycházet
z některé obecné metodiky projektového řízení (Zadavatel prefemje metodiku PRINCE2). Metodika projektového
řízení, použitá v Popisu navrhované metodiky projektového řízení a způsobu řízení projektu Zhotovitele, se
zároveň musí shodovat s certifikací metodiky v oblasti projektového řízení prokazované u projektového manažera.
Po zahájení realizace 1. Etapy projektu Zhotovitel na základě Popisu navrhované metodiky projektového řízení a
způsobu řízení projektu v nabídce předloží návrh Základního dokumentu Projektu (ZDP) a společně
se Zadavatelem ustaví řídící orgány projektu, které následně schválí projednané řídící projektové dokumenty pro
nastavení principů a pravidel řízení celého projektu (dle standardní projektové metodiky, např. PRINCE2).
Základní dokument Projektu musí obsahovat popis minimálně následujících oblastí:
• způsob metodiky řízení a realizace projektu - způsob analýzy, vývoje, testování a nasazování SW části
systému, govemance projektu.
• postupy plánování a koordinace s ostatními aktivitami a iniciativami Zadavatele (definice takového způsobu
řízem projektu a jeho výstupů, který množní realizaci projektu souběžně s běžným provozem Zadavatele).
• organizační struktura projektu, definice rolí a jejich odpovědností.
• komunikační plán - řízení, způsob a forma komunikace, základní komponenty komunikačního plánu a jejich
obsah, komunikační matice.
• postup řízení kvality, rizik a změn. eskalační pravidla, způsob vedení projektových registrů, výměny dat.
potřebné šablony dokumentů (např. pro vykazování stavu projektu, vedení úkolů atp.) a výstupů a další
potřebné elementy řízení projektu.
• harmonogram projektu - popis jednotlivých Etap a fází projektu, jejich zaměření a cíle. postupy pro řízení
harmonogramu, řízení výstupů a akceptací.
• přehled dokumentů, které budou v průběhu projektu vytvořeny (dokumenty Zhotovitel popíše v členění Etap,
fází či jiných vhodných časových úseků projektu a v popisu obsahu dokumentu bude vždy uvedeno zaměření
a účel dokumentu a ve srozumitelných bodech vymezen jeho obsah formou osnovy).
• základní návrh strategie testování.
• akceptační procedura pro všechny projektové výstupy.
• plán přenosu znalostí a dovedností na Zadavatele.
• požadovanou, pro projekt nezbytnou, součinnost Zadavatele, případně dalších dotčených subjektů a třetích
stran.
• návrh a popis dalších jinde neuvedených metod a postupů zaručující splnění cílů Zadavatele.
Stránka 62
H EVROPSKÁ UNIE
Evropský fond pro regionální rozvoj
Operační program Podnikání
a inovace pro konkurenceschopnost
2 .6 .3 C ílové ko n cepty
Pro každou ze 3 Etap realizace IS DTM ŘSD zpracuje Zhotovitel návrh řešení ve fonně Cílového konceptu, do
kterého promítne výstupy Úvodní analýzy, kterou Zhotovitel po zahájení 1. Etapy realizace 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 dané Etapy IS DTM ŘSD a zajištěním schopnosti poskytovat Služby podpory.
V rámci Cílového konceptn pak Zhotovitel detailně rozpracuje pro každou Etapu realizace výše uvedené teze pro
obsah a funkcionalitu dané Etapy. Analýzu a návrh řešení Zhotovitel v Cílovém konceptu popíše v takové míře
detailu, aby podle něj byl schopen vyvinout, implementovat, testovat a akceptovat SW spolu s provedením všech
souvisejících aktivit. Cílové koncepty musí rozpracovat požadavky Zadavatele tak, aby byly beze zbytku naplněny
cíle Zadavatele definované touto teclmickou specifikací a Smlouvou.
Cílový koncept bude vhodně strukturován a uspořádán do sady navazujících kapitol či dokumentů tak, aby
potřebné aspekty zachytil srozumitelným a přehledným způsobem ve všech potřebných vazbách a souvislostech a
usnadnil tak její akceptaci Zadavatelem ve vší celistvosti. Součástí Cílového konceptu jsou také koncepční
dokumenty, zejména strategie testování či další koncepční materiály dle návrhu Zhotovitele, které budou
Zhotovitelem následně v Cílovém konceptu a v případě potřeby i v dalším průběhu Projektu rozpracovány do
podrobných plánů a posúipů.
Minimální požadavky Zadavatele na obsah Cílových konceptů:
• V ývo j IS
o popis současného stavu prostředí Zadavatele a připravenost prostředí i organizace Zadavatele a
dotčených subjektů na implementaci nového IS z pohledu všech souvisejících aspektů, zejm. technické
a organizační připravenosti vč. znalostí a dovedností a početnosti personálu, provozního modelu vč.
procesů, postupů, metodik a návodů.
o analýza business požadavků budoucích uživatelů IS.
o analýza potřeb IS přes všeclmy dotčené odbornosti (analýza musí vycházet z předpisů, metodik a praxe).
o popis fungování Systému (technický návrh Systému, který musí plně zohledňovat příslušnou stávající
platnou právní úpravu v České republice včetně resortních předpisů Ministerstva dopravy ČR,
souvisejících norem ČSN/ISO a dodržení standardů ŘSD vyjmenovaných v kapitole 1.7 tohoto
dokumentu).
o způsob zajištění splnění funkčních a nefunkčních požadavků na Systém.
o popis architektury řešení IS DTM ŘSD včetně komponent/modulú, funkčních celků, popisu a vazeb na
okolní systémy.
o popis jednotlivých součástí IS DTM ŘSD. jejich funkčnost a vzájemné propojení.
o procesní analýza a procesní model, stanovení případů užití (UseCase) a způsob koexistence současného
způsobu provádění procesů a nově vytvářeného Systému.
o popis principů 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ám nového Systému.
o návrh uživatelů IS DTM ŘSD. jejich rolí a oprávnění.
o návrh datových základen pro Systém (včetně analýzy disponibilních dat Zadavatele a popisu způsobu
zajištění/doplněm dat nezbytných pro funkci Systému), návrh datových struktur, datový model.
o popis zpracovávaných objemů dat, výkonnostních parametrů Systému a výpočetního prostředí.
o popis výkonnostních a kapacitních parametrů Systému.
o 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.
o popis integrací Systému na další aplikační řešení Zadavatele, popis komunikace s externími systémy.
o popis konfigurace Systému pro prostředí Zadavatele.
o popis zajištění kontinuity, bezpečnosti, monitoringu a zálohování v návaznosti na popis architektury.
o návrh metodik pro sběr, aktualizaci, zpracování, ukládání a zálohování dat (v souladu s dostupnými
výsledky od Zadavatele v době zpracování Cílového konceptu).
o popis použitých výpočetních metod.
Stránka 63
H EVROPSKÁ UNIE
Evropský fond pro regionální rozvoj
Operační program Podnikání
a inovace pro konkurenceschopnost
o popis prezentační vrstvy a výstupů Systému,
o návrh grafického uživatelského rozhraní.
o návrh na změny v organizační struktuře Zadavatele v souvislosti se zavedením a využíváním IS DTM
ŘSD, doporučení na změny ve způsobu práce Zadavatele v souvislosti s novým Systémem.
o popis zabezpečení komunikace, bezpečnostní požadavky a opatření, popis dostupnosti, redundance.
o návrh HW infrastruktury IS DTM ŘSD včetně výčtu dalších HW a SW komponent technologické
infrastruktury nad rámec HW a SW komponent, posky tnutých pro realizaci plném Zadavatelem (návrh
nesmí obsahovat žádné nové komponenty nad rámec těch, které jsou uvedeny v nabídce Zhotovitele).
• Implementace Systému
o popis nasazení Systému včetně požadované součinnosti Zadavatele.
o popis strategie testování, průběhu testování a akceptace včetně výstupů, testovacích scénářů a nastavení
hodnot výkonnostních indikátorů.
o popis strategie školení včetně přehledu školení, doby trvání, osnovy, školících materiálů a osob. pro
které jsou jednotlivá školení určena.
o popis průběhů migrace dat.
o návrh katalogových listů s definicí příslušných služeb podpory minimálně v rozsahu dle kap. 3.1.5.
o další informace potřebné pro zajištění řádné implementace, testováni a provozu.
Všeclmv Cílové koncepty podléhají akceptační proceduře.
2.7 Realizace jednotlivých Etap IS DTM ŘSD
Realizace každé z Etap bude rozdělena do jednotlivých fází:
• Vývoj a implementace
• Integrační testy
• Uživatelské a akceptační testy
• Ověřovací provoz
• Optimalizace Systému, akceptace, nasazení do ostrého provozu
Nedílnou součástí realizace každé z Etap je projektové řízení Projektu Zhotovitelem v souladu se schváleným
Základním dokumentem Projektu.
2.7.1 Vývoj a implementace
Zhotovitel postupně v navazujících aktivitách provede vývojové a implementační práce, které povedou ke splnění
požadavků na Systém pro danou Etapu, a tím bude umožněno testování a ověřovací provoz v dalších fázích
realizace Etapy. Fázi vývoje a implementace SW může Zhotovitel v rámci Cílového konceptu rozdělit na další
dílčí úlohy.
Každá dílčí úloha musí být ukončena akceptací způsobilosti části Systému pro zahájení testování. Pň akceptaci
dílčí úlohy musí být všechny funkční a nefunkční požadavky na Systém Zhotovitelem splněny. V případě nutnosti
může Zhotovitel v rámci Cílového konceptu navrhnout i dílčí testování nově navržených dílčích úloh.
Všeclmv koncové milníky dílčích úloh fáze Vývoj a implementace podléhají akceptační proceduře.
2.7.2 Integrační testy
V rámci Cílového konceptu pro danou Etapu navrhne Zhotovitel hlavní scénáře integračních testů. Ve 2. Etapě
realizace IS DTM ŘSD budou navrženy testovací scénáře integračních tesúi v souladu s testovacími scénáři IS
DMVS navrženými ČÚZK. Integrační testy podléhají akceptační proceduře.
2.7.3 Uživatelské a akceptační testy
V rámci této fáze probělme testování Systému a jeho způsobilosti pro akceptaci dle předem definovaných
testovacích scénářů v Cílovém konceptu pro příslušnou Etapu. Uživatelské a akceptační testy provádí Zadavatel,
Zhotovitel v průběhů testování poskytuje nezbytnou součinnost.
Stránka 64
H EVROPSKÁ UNIE
Evropský fond pro regionální rozvoj
Operační program Podnikání
a inovace pro konkurenceschopnost
2.7.4 Ověřovací provoz
Cílem ověřovacího provozuje poskytnout metodické vedení a prostor uživatelům pro ověření funkcionalit a vlastní
funkčnosti dodaného řešení, pro cvičnou práci se Systémem a prostor pro Zhotovitele pro identifikaci a opravu
případných chyb a neshod. Dalším cílem ověřovacího provozuje možnost případné definice změnových
požadavků ze strany Zadavatele.
Ověřovací provoz proběhne po dobu dle schváleného harmonogramu realizace, a to se zvýšeným dohledem a
podporou ze strany Zhotovitele.
Zadavatel požaduje, aby v rámci ověřovacího provozu zajistil Zhotovitel zvýšený dohled a podpora uživatelů a
dále individuální seznámení vybraných klíčových uživatelů a administrátorů s realizovanou formou předmětu
plném v podobě fyzické přítomnosti u Zadavatele (a to bez nároku na navýšení ceny plnění, resp. v ceně Díla),
v celkovém rozsahu 0,5 člověkodne týdně po celou dobu trvání ověřovacího provozu ze strany každé osoby
v následujících klíčových projektových rolích:
• Architekt řešení
• Konzultant
• Implementátor
• Datový analytik
V době ověřovacího provozu bude možné ze strany Zhotovitele provedení případné nutné doplňující migrace dat
(např. počáteční stav) s ohledem na zahájení ostrého provozu.
Zhotovitelem musí být zajištěn minimálně 1 měsíc ověřovacího provozu, přičemž počínaje 2. Etapou plnění platí,
že v případě výskytu Incidentu kategorie A během ověřovacího provozu se tento prodlouží o další měsíc.
Přesáhne-li doba ověřovacího provozu 1 měsíc, budou činnosti shora uvedených osob v klíčových rolích hrazeny
cenou za MD Služby rozvoje.
Úspěšný průběh ověřovacího provozu, jehož výstupem bude faktické uživatelské ověření schopnosti nasazení
nového IS DTM ŘSD v prostředí určeném pro provoz tohoto Systému na základě schváleného Cílového konceptu.
Smlouvy a této technické dokumentace včetně jejích příloh, je jednou z nezbytných podmínek Zadavatele pro
možnost akceptace plnění příslušné Etapy.
2.7.5 Optimalizace Systému, akceptace, nasazení do ostrého provozu
Na základě vyhodnocení ukončeného a akceptovaného ověřovacího provozu Zadavatelem Zhotovitel provede
případnou optimalizaci Systému a jeho přípravu na finální akceptaci příslušné Etapy realizace jako celku. Po
úspěšné akceptaci realizace příslušné Etapy Zadavatelem bude Systém nasazen do ostrého provozu.
2.8 Migrace dat a podpora při nahrávání a editaci dat
Součástí realizace Projektu Zhotovitelem je i podpora, resp. zajištění migrace dat pro prv otní naplnění IS DTM
ŘSD daty. Procesní vazba na práce Zadavatele zahrnující pořízení dat, jejich kontrolu, průběžnou aktualizaci a
editaci do doby spuštění IS DTM ŘSD je popsána v kapitole 1.6. Tyto práce budou rozděleny do následujících
plnění:
1. V rámci realizace SW v 1. Etapě Projektu budou Zhotovitelem do IS DTM ŘSD natírána veškerá doposud
odevzdaná data od dodavatelů pořizování dat. Zhotovitel poskytne nezbytnou součinnost Zadavateli při
nahrání dat pro potřeby testování a ověřovacího provozu a následně provede veškerou migraci těchto dat a
zajistí součinnost pro činnosti kontroly a editaci dat.
2. V rámci realizace SW ve 2. Etapě Projektu budou Zhotovitelem připravena data pro potřeby testování a
ověřovacího provozu včetně integračních testů. Dále Zhotovitel shromáždí v datovém meziskladu veškerá
pořízená data a provede kompletní migraci před spuštěním IS DTM ŘSD do ostrého provozu v legislativním
termínu dle Výzvy OP PIK včetně doplnění popisných atributů získaných prostřednictvím definovaných
integrací.
3. V rámci realizace SW ve 3. Etapě Projektu bude Zhotovitelem provedena migrace ostatních dat nutných resp.
vyplývajících z požadavků na komponenty obsažené ve 3. Etapě realizace Projektu.
Pro všeclmv 3 Etapy realizace Projektu budou Zhotovitelem v rámci příslušných Cílových konceptů navrženy
detailní migrační scénáře, které budou odsouhlaseny Zadavatelem a budou podkladem pro akceptaci těchto prací.
Současně s tím bude pro všechny 3 Etapy realizace IS DTM ŘSD Zhotovitel zajišťovat podpora definovanou
v kapitole 1.6 a 3.1.
Stránka 65
EVROPSKÁ UNIE
Evropský fond pro regionální rozvoj
Operační program Podnikání
a inovace pro konkurenceschopnost
2.9 Dokumentace IS DTM RSD
2.9.1 Obecné požadavky na dokum entaci
Zadavatel požaduje, aby Zhotovitel vytvářel, aktualizoval a kontroloval dokumentaci IS DTM ŘSD podle
následujících principu:
• dokumentace celého Systému bude komplexní, kompaktní a konzistentní,
• dokumentace bude vytvářena strukturovaně podle podrobnosti, každá úroveň struktmy bude obsahovat
přiměřenou úroveň detailů k popisované problematice,
• navigace a orientace v dokumentaci musí být jednoduchá a srozumitelná,
• v dokumentaci musí jit vyhledávat a musí obsahovat rejstřiky pojmů,
• v dokumentaci musí být integrovány všeelmy části, včetně datového modelu, UVIL. ArclůMate apod.
Zadavatel požaduje použití standardních modelovacích nástrojů, např. Enterprise Arclútect. Volba vhodného
analytického nástroje musí být konzultována a schválena Zadavatelem.
• dokumentace musí být provázána aktivními odkazy, umožňujícími jednoduchou navigaci mezi jejími částmi,
• dokumentace musí být průběžně aktualizovaná (v rámci Služeb podpory, případně v návaznosti na konkrétní
rozvoj Systému) a verze dokmnentace budou uvedeny v úvodní části dokumentu (včetně data, autora a popisu
změny) a jednotlivé verze budou zálohovány.
2.9.2 Forma a předání dokumentace
Zadavatel požaduje předám veškeré dokumentace pro příslušnou Etapu realizace v českém jazyce v rozsahu dle
Smlouvy a akceptovaného Cílového konceptu v elektronické podobě, a to vždy nejpozději 5 pracovních dnů před
termínem zahájení akceptace fáze Vývoj a implementace a/nebo školení příslušné Etapy realizace, není-li uvedeno
nebo nevyplývá-li z jednotlivého typu dokumentace jinak (toto ustanovení není v rozpora s přílohou č. 1 Smlouvy
bod 8 písm. f)- Dokmnentace musí být dodána v takové podobě a formátu, aby byla připravena bez potřeby
jakýchkoliv dalších úprav k tisku.
Veškerá dokumentace musí pokiývat celý IS DTM ŘSD včetně platformního software a musí být v souladu
s právními předpisy ČR a EU, pod které IS DTM ŘSD spadá.
2.9.3 Dokumentace architektury řešení
Popis architektury Systému bude vytvářen ve všech vrstvách architektury dle platné metodiky OHA MV ČR a
s použitím prakticky ověřených a uznávaných standardů: mezinárodně uznávaného rámce pro řízení tvorby
enterprise architektury TOGAF, jazyka ArclůM ate#pro modelování architektonického obsahu a dále jazyka UML
užitého pro detailní návrh řešení. Dále bude popsáno, jakým způsobem a přes jaké protokoly spolu jednotlivé
vrstvy komunikují.
2.9.4 Dokumentace datového modelu
Pro Systém Zhotovitel předá dokumentaci s aktuálním a platným úplným popisem položek obsažených
v databázích a popisem základní struktury databází. Dokumentace bude zároveň obsahovat i seznamy a stručné
popisy všech uložených procedur, funkcí, sekvencí a dalších důležitých elementů definovaných v databázi.
Datový model bude předán elektronicky, a to v souladu s požadavky přílohy la tohoto dokumentu.
Datový model bude Zadavatelem využíván zejména pro interní potřeby oddělení/odbora IT a pro potřeby realizace
rozšiřujících integrací na další aplikace a informační systémy.
V případě úprav datového modelu prováděných Zadavatelem bez schválení Zhotovitelem není Zhotovitel povinen
k odstraňování takovým způsobem vzniklých vad a nekonzistentností.
2.9.5 Dokumentace popisu rozhraní
Zhotovitel dodá aktuální a platný popis veškerých rozhraní IS DTM ŘSD na systémy a databáze, se kterými je
provázán. Tato dokumentace musí být vedena až na úroveň popisu konkrétního způsobu práce rozhraní s daty s
uvedením všech jednotlivých datových typů a jednotlivých položek, se kterými rozhraní pracuje. Popis
jednotlivých rozhraní musí být zpracován tak detailně, aby umožňoval Zadavateli jeho předám třetí straně, která na
základě popisu bude schopna vytvořit bez jakékoliv součinnosti Zhotovitele odpovídající protikus rozhraní
v plném rozsahu a jeho spuštění musí záviset pouze na povolení komunikace ze strany aplikace/infonnačního
systému Zhotovitele.
Stránka 66
H EVROPSKÁ UNIE
Evropský fond pro regionální rozvoj
Operační program Podnikání
a inovace pro konkurenceschopnost
Popis rozhraní musí tedy obsahovat minimálně technologii, kterou je rozhraní realizováno, popis jednotlivých
datových typu a struktur, se kterými rozhraní pracuje, a způsob, kterým má být prostřednictvím rozhraní
komunikováno.
Dokumentaci rozhraní musí Zhotovitel udržovat aktuální po celou dobu účinnosti Smlouvy a v rámci ní udržovat
platný popis veškerých rozhraní Systému a databází, se ktetými je provázán.
2.9.6 Popis testovacího a produkčního prostředí IS DTM ŘSD
Tato dokumentace musí obsahovat popis implementace řešení do testovacího a produkčního prostředí Zadavatele
se stručným popisem rozdílů obou režimů. Bude zpracována minimálně v rozsahu síťového, datového a
aplikačního schématu včetně integrací, popisu procesu nasazení Systému včetně zpřesněného harmonogramu a
požadavků na součinnost ze strany Zadavatele. Bez předložení dokumentace s popisem navrženého provedení
implementace v prostředí Zadavatele v průběhu fáze Vývoj a implementace dané Etapy realizace nebude
umožněno Zhotoviteli instalovat a implementovat Systém do určeného prostředí. Předložení dokumentace je
povinností Zhotovitele a v případě jejího nepředložení a z tohoto důvodu neumožnění implementace Systému do
definovaného prostředí se bude jednat o prodlení s plněním na straně Zhotovitele.
Na základě provedení implementace a nasazení Systému do určeného prostředí bude následně dokumentace
Zhotovitelem aktualizována tak, aby plně odpovídala skutečnému způsobu nasazení Systému a bude k ní
zpracováno technologické schéma realizovaného Systému.
2.9.7 Programátorská dokumentace
Zhotovitel předá Zadavateli zdrojový kód a související programátorskou dokumentaci v souladu s požadavky
dokumentu „Pravidla pro SW a jeho dodání do prostředí ŘSD“ (viz příloha la) a Smlouvou.
2.9.8 Uživatelská dokumentace
Zhotovitel předá uživatelskou dokumentaci pro IS DTM ŘSD, která bude obsahovat minimálně základní popis
práce s jednotlivými komponentám a rozhraními, postupy a bude popisov al jejich funkcionality pro potřebu řádné
orientace uživatelů v Systému a řádné práce uživatele v Systému. Slovní popis bude pro snadnější porozumění
doplněn ilustrujícími schématy a screenshoty.
2.9.9 Administrátorská dokumentace
Zhotovitel předá administrátorskou dokumentaci pro Zadavatele, která bude obsahovat detailní popis správy a
údržby aplikací a informačních systémů dodávaných v rámci plnění této Smlouvy.
2.10 Školení adm inistrátorů a klíčových uživatelů
Zhotovitel zrealizuje v sídle Zadavatele prezenční zaškolení pro administrátory Systému a klíčové uživatele
Zadavatele tak, aby tyto osoby byly schopny Systém řádně užívat, testovat, nastavovat jej na adnunistrátorské
úrovni a školit další uživatele Systému. Školení bude provedeno pro každou ze tří Etap realizace IS DTM ŘSD
vždy v rozsahu odpovídajícím realizovaným funkčnostem každé z Etap. Školeni musí pokrývat všeelmy aspekty
práce s realizovanou Etapou IS DTM ŘSD. jeho uživatelské a technické obsluhy, provozování procesů a
souvisejících činností vykonávaných pracovníky Zadavatele, případně pracovníky dotčených organizací. Všechna
školení musí být dokončena před zahájením testování a akceptační procedury realizace příslušné Etapy.
Po dohodě se Zadavatelem může být školení případně provedeno i formou on-line video konference. Zadavatel
si vyhrazuje právo pořídit ze školení obrazový a zvukový záznam pro potřeby dalšího využití.
Zadavatel pro účely zaškolení zajistí a zpřístupní vhodnou školící učebnu vybavenou notebooky' nebo PC
sestavami a jedním lektorským pracovištěm, prezentační teelmikou (ve smyslu projektor, tabule pro psaní /
kreslení) a dále zajistí konektivitu do vnitřní sítě Zadavatele (s ohledem na možnost práce s produkční a testovací
databází Systému během školení). Veškerá školení budou probíhat v testovacím (školícím) prostředí Systému.
Minimální požadovaný rozsah školení pro jednotlivé Etapy je následující:________________________________
Etapa Školení pro administrátory Školení pro klíčové uživatele
1. lx školení v rozsahu 30 hodin, pro max. 7 osob 4x školení v rozsahu 16 hodin, každé pro max. 25
osob
2. lx školení v rozsahu 30 hodin, pro max. 7 osob 4x školení v rozsahu 16 hodin, každé pro max. 25
osob
3. lx školení v rozsahu 30 hodin, pro max. 7 osob 4x školení v rozsahu 16 hodin, každé pro max. 25
osob
Stránka 67
H EVROPSKÁ UNIE
Evropský fond pro regionální rozvoj
Operační program Podnikání
a inovace pro konkurenceschopnost
Zadavatel je oprávněn objednat tato školení nad výše uvedený počet. Takové školení bude hrazeno jednotkovou
cenou dle přílohy č. 4 Smlouvy.
Uvedený rozsah školení je Zadavatelem považován za minimální s tím, že se jedná o časový rozsah školení nutný
pro zvládnutí samostatné práce se Systémem. Uživatel musí po absolvování školení zvládat minimálně následující
dovednosti:
• užívání, nastavování a testování Systému.
• ovládám aplikací Systému,
• zadávám a editace dat,
• znalost procesů souvisejících se školenou částí Systému,
• znalost vazeb mezi jednotlivými komponentami Systému.
Zhotovitel předá Zadavateli před školením následující dokumentaci:
• uživatelská dokumentace,
• administrátorská dokumentace,
• metodické materiály související s realizovaným Systémem,
• školící materiály.
3 POSKYTOVÁNÍ SLUŽEBPODPORY, DALŠÍCH PO VINNO STÍ ZHOTOVITELE,
SLUŽEB EXITU A SLUŽEB ROZVOJE
Tato kapitola definuje požadavky na další Služby poskytované Zhotovitelem, které sestávají z následujících
čimiostí:
• Služby podpory (servisní podpora, údržba a provoz Systému - viz kap. 3.1)
• Další povinnosti Zhotovitele (viz kap. 3.2)
• Služby Exitu (viz kap. 3.3)
• Služby rozvoje (Ad-hoc rozvoj Systému - viz kap. 4)
3 .1 S lužb y podpory
Obecné podmínky poskytování Služeb podpory jsou určeny několika základními prvky:
• Doba pokrytí = (časový režim doby poskytování služeb) doba 5x12, ve které jsou poskytovány Služby
podpor, a lze během ní uplatňovat požadavky na smluvní plnění.
• 5x12 = časový režim doby poskytování Služeb podpory v rozsahu od 07:00 do 19:00 hod. ve všeclmy
pracovní dny v České republice v kalendářním roce.
• Doba odezvy = doba, která uběhne od prokazatelného zaregistrování požadavku Zadavatele v HelpDesk
Zadavatele do momentu, kdy Zhotovitel zahájí přípravné práce vedoucí k řešení požadavku. V rámci doby
odezvy je prováděna (pře)klasifikace závažnosti a přiřazení záznamu o požadavku v HelpDesk zodpovědné
osobě nebo týmu Zhotovitele, který'je schopen provést úvodní diagnostiku.
• Reakční doba = doba, která uběhne od prokazatelné registrace požadavku Zadavatele v HelpDesk
Zadavatele do okamžiku, kdy pracovník Zhotovitele zahájí kvalifikované řešení vzneseného požadavku. Do
reakční doby se nezapočítává doba mimo dobu pokrytí a mimo dobu pokrytí doba k zahájení řešení požadavku
neběží. Reakční doba off-site znamená zahájení řešení požadavku pomocí vzdáleného přístupu k Systému a
reakční doba on-site pak znamená zahájení řešení požadavku Zhotovitelem v sídle Zadavatele. Reakční doba
na požadavek kategorie CR znamená zpracování výchozí rámcové kvalifikace vzneseného změnového
požadavku v rozsahu do 1 člověkodne (tzv. QuickScan). Do reakční doby se nezapočítávají přerušení
poruchy.
• Doba řešení = doba, která ubělme od prokazatelné registrace požadavku Zadavatelem z HelpDesk Zadavatele
do okamžiku eliminace poruchy Systému. Eliminace je provedena buď fonnou trvalého vyřešení, nebo
náhradním způsobem. Do doby řešení se nezapočítávají přerušení poruchy.
• Přerušení poruchy = pokud je při servisním zásahu nutný přístup pracovníků Zhotovitele k zařízení
umístěnému v prostorách Zadavatele nebo prostorách třetí osoby, kam Zadavatel zajišťuje přísůip. je
Zadavatel povinen tento přístup umožnit. Pokud Zadavatel přístup neumožní, je pozastaveno načítám času
Stránka 68
H EVROPSKÁ UNIE
Evropský fond pro regionální rozvoj
Operační program Podnikání
a inovace pro konkurenceschopnost
poruchy. Zhotovitel o pozastavení načítám času a jeho důvodů uvědomí Zadavatele dohodnutým způsobem
a zároveň se Zadavatelem dohodne čas, kdy bude přístup pracovníkům Zhotovitele umožněn. Od okamžiku
umožnění přísůipu pracovníkům Zhotovitele k zařízení je pak načítám času poruchy obnoveno. Taktéž se
jedná o časový úsek, kdy je Zhotoviteli z důvodů na straně Zadavatele nebo třetí strany znemožněno nebo
značně ztíženo provedení servisního zásahu, či odepření poskytnutí relevantních informací nebo souhlasu s
dalším postupem. Přerušení poruchy je možné i na základě vzájemné prokazatelné dohody mezi kontaktními
osobami Zadavatele a Zhotovitele, zaznamenané u předmětného požadavku v HelpDesk Zadavatele.
• Incident = jakákoliv událost (chyba, vada, porucha, havárie nebo problém) dle ITIL metodiky, která není
součástí standardní uživatelské operace nebo pracovního postupu a která působí nebo může způsobit poruchu
Systému nebo snížení kvality Systému. Kde se ve Smlouvě a jejích přílohách hovoří o poruše, rozumí se tím
i snížení kvality Systému.
Dále je to třístupňová škála definující různou závažnost poruch Systému (incidentů) (viz kap. 3.1.6.1).
K jednotlivým stupňům závažnosti jsou přiřazeny Doby zahájení řešení incidentu / Doby zahájení řešení
požadavku a Doby řešení incidentu / Doby řešení požadavku. A konečně pro jednotlivé stupně závažnosti jsou
definována pravidla pro určení výše sankce pro případ neplnění stanovených podmínek (SLA).
Služby podpory budou Zhotovitelem poskytovány v souladu s definicí služeb uvedených v katalogovém listu
příslušné služby a tamtéž uvedenými kvalitativními atributy a vlastnostmi dané služby, které představují sjednanou
úroveň poskytované služby. Kontrolu poskytovaných služeb bude pravidelně provádět Zadavatel. Hodnoceným
vyhodnocovacím obdobím je jeden (1) kalendářní měsíc.
Zhotovitel je povinen se řídit (pod)zákonnýnú, technickými a jinými požadavky, pravidly a doporučeními,
souvisejícími s poskytovanými službami, spravovanou nebo využívanou infrastrukturou a využívanými nebo
poskytovanými službami Zadavatele či třetích stran.
Zpracování informací, podkladů a dat pro (vy)hodnocení Služeb podpory je součástí plnění Zhotovitele. Veškeré
výkazy, podklady a dokumenty musí být předloženy ve formě umožňující přezkoumatelnost a auditovatelnost
Zadavatelem a kontrolními institucemi, což jsou veškeré subjekty oprávněné provádět kontrolu, jakkoliv se
tykající plném Zhotovitele na základě právního předpisu. Zhotovitel je povinen bezplatně poskytnout součinnost
Zadavateli související s odbornými, zákonnými a jinými kontrolami a audity, které mohou být uplatňovány vůči
Zadavateli v souvislosti s dodávkou Služeb 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 dodávkou Služeb
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 doplňující podklady. Pokud nebude Zhotovitel schopen takové
podklady dodat či takové podklady nebudou kontrolním orgánem akceptovány a bude-h jejich absence důvodem
k udělení postihu vůči Zadavateli, přičemž se jedná o podklady, kterými Zhotovitel má disponovat v souladu
s touto Smlouvou, 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 podpory došlo vinou
vnějšího vlivu (mimo působnost Zhotovitele) nebo nesoučinností Zadavatele, je povinností Zhotovitele. Nejsou-li
doklady prokazující příslušné skutečnosti doručeny jako součást podkladů pro hodnocení služeb za příslušné
vyhodnocovací období, je nedostupnost přerušení či zhoršení kvality poskytování Služeb podpory- přičítána k tíži
Zhotovitele (tj. neprokáže-li Zhotovitel opak v rámci podkladů pro hodnocení služeb, považuje se nedostupnost
Systému či přerušení či zhoršení kvality poskytování Služeb podpory za zpúsobené/zaviněné Zhotovitelem;
Zadavatel však může dodatečně uznat, že se jednalo o příčiny nezpůsobené Zhotovitelem).
Pokud Zhotovitel dodal v rámci svého řešení i nějaký proprietámí software nebo otevřený software (open source),
pro nějž Zhotoviteli posky tuje 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 v případě kritické chyby Systému
(kategorie A) nebo pokud je to požadováno Zadavatelem, pak také zajištění návrhu dočasného náhradního řešení a
zajištění schválení jeho nasazení Zadavatelem. Podpora SW produktů, realizovaná Zhotovitelem, bez uvedené
komerční podpory (viz výše), je považována za nedílnou součást Služeb podpory Systému vytvořeného
Zhotovitelem, a tato podpora musí splňovat sjednané parametry- kvality.
V případě dopadu nefunkčnosti jednoho či více spolupracujících systémů, které nejsou součástí IS DTM ŘSD, na
funkčnost Systému je výsledné omezení sjednané úrovně služeb vyloučeno z hodnoceni úrovně Zhotovitelem
posky tovaných Služeb podpory.
Ve všech uvedených případech je Zhotovitel spoluzodpovědný za řešení incidentů a požadavků na základě jejich
záznamu v ITelpDesku Zadavatele a záznamech o provedených činnostech při řešení incidentů a požadavků rovněž
v HelpDesku Zadavatele, je povinen spolupracovat při analýze incidentů, a v případě požadavku, schváleného
Zadavatelem, také spolupracovat na jeho ř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 tak, jako by to byl incident spadající plně do jeho sféry řešení v rámci sjednaných úrovní Služeb podpory.
Stránka 69
H EVROPSKÁ UNIE
Evropský fond pro regionální rozvoj
Operační program Podnikání
a inovace pro konkurenceschopnost
V rámci poskytování Služeb 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 IS DTM ŘSD. 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 provoz
Systému. Zhotovitel je dále povinen navrhovat a po schválení Zadavatelem 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šeni incidentů souvisejících s nefunkčností infrastruktury nebo některých jejích
částí v odpovědnosti Zadavatele.
3.1.1 Rozsah Služeb podpory
Služby podpoiy spočívají zejména v poskytování následujících služeb:
• řízem Služeb podpory,
• udržování aktuální dokumentace IS DTM ŘSD včetně aktualizace dokumentace IS DTM ŘSD v závislosti
na provedených úpravách a rozvoji,
• lokalizaci a řešení incidentů a požadavků, zejména dodržení Doby zahájení řešení incidentu a Doby zahájení
řešení požadavku. Doby řešení incidentu a Doby řešení požadavku odpovídající kategorii vzniklého incidentu
či požadavku a specifikované v kapitole 3.1.6,
• poskytování podpoiy IS DTM ŘSD a zajištění plnění podmínek SLA dle Servisního modelu specifikovaného
v kapitole 3.1.6,
• údržba (maintenance) IS DTM ŘSD, 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ří IS DTM ŘSD,
• navrhování optimalizace aplikačních serverů, databází, komunikačních nastavení a dalších komponent
technického řešení IS DTM ŘSD,
• zajištění podpory a správy proprietámích i open-source SW. které jsou předmětem plnění Zhotovitele a jsou
součástí IS DTM ŘSD, sestávající z řešení incidentů spojených s provozem takového SW,
• zajištěni a udržování maintenance proprietámího i open-source SW, které jsou předmětem plnění Zhotovitele
a jsou součástí IS DTM ŘSD, instalace, implementace a integrace aktualizací takového SW a poskytnutí
podpory tomuto SW, včetně poskytnutí nejnovějších verzí tohoto SW Zadavateli a dalších služeb v souladu
s jeho standardními obchodními podmínkami, na dobu trvání Smlouvy,
• zajištění a udržování maintenance případných dodatečných HW technologií nad rámec technologického
vybavení poskytnutého Zadavatelem, instalace, implementace a integrace aktualizací takového HW a
poskytnutí podpory tomuto HW a dalších služeb v souladu sjeho standardními obchodními podmínkami, na
dobu trvání Smlouvy, s dodržení následujících parametrů:
o časové pokrytí (doba, ve které lze uplatňovat požadavky na servisní podpora, tj. nahlašovat závady
Systému): 5x9,
0 reakční doba (doba od nahlášení závady Zhotoviteli do započetí prací na diagnostice a odstranění
závady): on-site NBD.
• 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 Zadavatele,
• provádění činností údržby 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ú atd. Součástí je dále pravidelná profylaxe Systému min.
1 x ročně. Součástí údržby Systému je:
o zajištění provozu, dosůrpnosti a funkčnosti Systému,
o řešení chybových stavů.
o 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.).
o pravidelná kontrola aplikačních a systémových žurnálů serverů.
o pravidelná kontrola podpůrných komponent, nástrojů a systémů z pohledu funkčnosti Systému jako
celku.
Stránka 70
ŘEDITELSTVÍ SILNIC A DÁLNIC ČR H EVROPSKÁ UNIE
Evropský fond pro regionální rozvoj
Operační program Podnikání
a inovace pro konkurenceschopnost
o úpravy parametru a konfigurací vyplývající z provozních potřeb či jejich návrhy směrem
k provozovatelům příslušných částí.
o vyhodnocování skutečných parametru funkčních celků, modulů či systémů (odezvy aj.) v rámci
nahlášených incidentů, jejichž předmětem jsou problémy s těmito parametry.
o součinnost pň analýze incidentů a problémů v připojených systémech Zadavatele či spolupracujících
subjektů a předkládám návrhů na optimalizaci.
o definice či úpravy v nastavení směrování, dočasných pamětí, rozhraní, adaptérů s ohledem na připojení
systémů Zadavatele či spolupracujících subjektů.
o 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, Microsoft Edge. Google
Chromé. 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
Zadavatel neurčí jinak.
- pro části přístupné interním uživatelům Zadavatele to je kompatibilita s konfigurací standardního
výpočetního prostředí Zadavatele (tzn. konfigurace klientských počítačů).
o součiímost s dodavateli připojených systémů Zadavatele či spolupracujících subjektů, poskytnutí
podkladů a informací pro připojení, součinnost pň testování a pn nasazování do provozního prostředí a
definice požadavků na tyto systémy.
o součiímost pn testech po úpravách či zásazích do infrastruktury,
o definice nastavení databází.
o definice požadavků na zálohování a posky tnutí součinnosti provozovateli služby zálohování.
o 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í Zadavateli, instalace a provedení změn dle
Zadavatelem schválených návrhů opatření, implementace schválených požadavků na změnu nejpozději
do 30 dnů nebo dle dohody se Zadavatelem.
o podpora na úrovni L2 a L3 a poskytování odborných konzultací, provozní podpora, služby HelpDesku
Zhotovitele, dohledové služby, bezpečnostní dohled, součimiost s útvarem ICT Zadavatele zajišťujícího
provoz inTrastruktury,
o součinnost pň implementaci systému Zadavatele pro monitoring dostupnosti služby.
o zajištění podpory u výrobců Zhotovitelem dodaných a použitých komponent pocházejících od třetích
stran.
o správa a aktualizace provozní dokumentace.
o aktualizace Provozního deníku (zejména záznam prováděných činností, popis servisních úkonů apod.)
o účast na jednám provozních a pracovních týmu Zadavatele a týmů přizvaných třetích stran.
o poskytování součinnosti 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ů.
o příprava výkazů a podkladů pro vyhodnocení služby a zajištění administrativní činnosti související
s prováděním dílčích čůmostí v rámci posky tování služby.
sledování souladu 1S DTM ŘSD s obecně závaznými právními předpisy a informování Zadavatele
o případném nesouladu IS DTM ŘSD s obecně závaznými právními předpisy a konzultace případně návrhy
změnových požadavků Zadavateli v tomto směru k dosažení souladu IS DTM ŘSD s právními předpisy, a to
ve smyslu kap. 1.7 této přílohy Smlouvy,
podávám pravidelných Výkazů o plnění SLA, poskytování Služeb podpory a reportů o provozu IS DTM
ŘSD; tyto budou zasílány na elektronickou adresu Kontaktní osoby Zadavatele pro věcné plnění
v elektronické podobě umožňující editaci a vyhledávám, a též v podobě neumožňující další editaci,
uživatelská podpora, kdy se jedná o on-line a off-line služby zahrnující telefonickou a elektronickou
komunikaci pomocí HelpDesk Zhotovitele dle definice v kap. 3.1.7,
Stránka 71
H EVROPSKÁ UNIE
Evropský fond pro regionální rozvoj
Operační program Podnikání
a inovace pro konkurenceschopnost
• pravidelná údržba testovacího prostředí Systému, přičemž na provoz tohoto prostředí se nevztahují lhúty a
parametry dle SLA.
• možnost integrace HelpDesk Zhotovitele na HelpDesk Zadavatele dle definice v kapitole 3.1.7.
3 .1 .2 Provozní d en ík
Zhotovitel povede při poskytování Služeb podpory tzv. 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ý IS DTM ŘSD a všeclmy jeho součásti. Bude technicky realizován v prostředí Zhotovitele
v technologii schválené Zadavatelem, který do něj bude mít přístup. Každý záznam v provozním deníku bude
obsahovat alespoň datum a čas jeho pořízem, identifikaci osoby, která záznam pořídila, označení dotčené služby
(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 rozvoje, pokud Zhotovitel provádí nějaký zásah v souvislosti s činnostmi podle zadání Zadavatele. Do
provozního deníku budou zaznamenávány všeclmy 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.
• Odstavem služeb, byť dočasné.
• Zprovoznění nové služby.
• Výměny či aktualizace programových komponent či jiných prvku Systému.
• Anomálie a nestandardní stavy Systému s dopady na plném parametrů kvality poskytovaných služeb.
• Spuštění, vypnutí či restart služeb.
• Obnova dat ze zálohy.
3 .1 .3 V ý k a zy p o skytn u tých S lužeb podpory
Pň poskytování Služeb 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ám, účast na jednání apod.) ve fonně Výkazu poskytnutých Služeb podpory v digitální podobě. Tento výkaz
bude Zhotovitel předávat Zadavateli spolu s ostatními podklady specifikovanými výše za uplynulé vyhodnocovací
období.
3 .1 .4 M ěřen í a vy h o d no co vání poskytn u tých S lužeb podpory
Kontrolu poskytovaných Služeb podpory provádí Zadavatel podle kvalitativních atributů a vlastností služeb
uvedených v katalogový ch listech příslušných služeb. Nebyla-li služba poskytnuta v souladu sjejí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 Zadavatel může uplatnit své právo na odpovídající smluvní pokuút nebo slevu
z ceny za hodnocené vyhodnocovací období.
3.1.5 Struktura katalogového listu služby
Zadavatel požaduje, aby Zhotovitel v rámci Cílových konceptů definoval každou službu ze Služeb podpory svým
katalogovým listem minimálně v následující struktuře:_______________________________________________
K a ta lo g o v ý list slu žb y
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
K valitativn í in d ikáto r služby
Identifikátor indikátoru Jednoznačné kódové označení kvalitativního indikátoru
Definice Definice kvalitativního parametru služby
Stránka 72
H EVROPSKÁ UNIE
Evropský fond pro regionální rozvoj
Operační program Podnikání
a inovace pro konkurenceschopnost
K a ta lo g o v ý list slu žby
P aram etry kv alitativn íh o ind ikáto ru služby
Kalendář služby Vymezení časového období 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 Jednotlivé proměnné a jejich definice, které vstupují do vzorce výpočtu dostupnosti
parametrů indikátoru
kvality služby
Způsob výpočtu Vzorec výpočtu dostupnosti spolu sjeho definicí a popisem způsobu výpočtu
Měřicí bod Místo v IS (např. rozhraní), kde se param etry indikátoru kvality služby zjišťují
Způsob dokladování Definice podkladů, z nichž se berou indikátory pro výpočet
Doplňující inform ace
Smluvní pokuta / sleva z Odkaz na obecně platné požadavky na smluvní pokutu nebo specifické hodnoty
ceny a způsob stanovení / výpočtu smluvní pokuty /slevy z ceny
Platební podmínky Odkaz na obecná smluvní ustanovení nebo definice specifického režimu
poskytování služby (zvláštní platební podmínky)
Poznámka Doplňující poznámky a vysvětlení
Zadavatel požaduje, aby přiřazení funkčních oblastí Systému ke katalogu služeb odpovídalo tomuto schématu a
toto přiřazení musí být koncepčně definováno v rámci Cílových konceptů. Zadavatel pňpouští, jelikož v tomto
okamžiku ještě nezná přesnou strukturu funkčních oblastí IS DTM ŘSD, kterou teprve Zhotoviteli v rámci
Cílových konceptů navrhne, že schéma přiřazení může být vhodně doplněno o řádky, v nichž Zhotovitel uvede jím
navrhnuté funkční oblasti, nicméně pn zachovám principů přiřazení ke katalogu služeb na základě tohoto
schématu. Katalogový list musí schválit Zadavatel.
3.1.6 Servisní model a parametry SLA
Zadavatel požaduje posky tování Služeb podpory dle následujícího servisního modelu a parametrů SLA. Za
nedodržení níže stanovených parametrů SLA je stanovena sleva z ceny Služeb podpory v níže uvedené výši.
Případnou úpravu parametrů SLA na základě zkušeností z provozu IS DTM ŘSD nelze provést drive než
po dokončení a akceptaci 2. Etapy plnění.
Pro potřeby stanovení plnění metrik SLA se za zahájení doby odezvy vždy považuje čas po registraci požadavku
v HelpDesk Zadavatele a jeho prokazatelného domčení Zhotoviteli a lhúty, stanovené v příslušných SLA, se
počítají od tohoto okamžiku (viz kap. 3.1.7). Za vyřešení incidentu (doba řešení) se považuje okamžik nahlášení
ukončení řešení incidentu Zhotovitelem změnou stavu incidentu v HelpDesk Zadavatele na stav „Vyřešeno“.
Uzavření požadavku provádí Zadavatel v HelpDesk Zadavatele.
3.1.6.1 Klasifikace požadavků HelpDesk
Požadavek na poskytnutí Služby podpory prostřednictvím HelpDesk Zadavatele v případě poruchy Systému
klasifikuje odpovědný pracovník Zadavatele z hlediska závažnosti vad. Vedle požadavku pro případ řešení
poruchy Systému je zaveden i požadavek na změnu Systému, kteiý nijak nesouvisí s poruchou Systému. Pro
stanovém závažnosti požadavku se používá níže uvedený způsob klasifikace ve 3 kategoriích závažnosti +
změnový požadavek:_________________________________________________________________________
Kategorie Popis klasifikace vad
Systém je nedostupný - kritická chyba, havárie Systému.
Funkcionalita hlavních částí Systému je nedostupná všem (100%) uživatelům. Jedná se o
A havárii, poruchy, chyby, vady vedoucí k přerušení provozu nebo jeho kritickému omezení a
znemožňující používám a využívám Systému. Za kritickou chybuje považována zejména
nefunkčnost komponenty Správa ZPS, Dl, TI a ostatních dat ŘSD nebo neschopnost přijímat,
vydávat a garantovat data IS DTM ŘSD.
Stránka 73
H EVROPSKÁ UNIE
Evropský fond pro regionální rozvoj
Operační program Podnikání
a inovace pro konkurenceschopnost
Systém je částečně nedostupný - hlavní chyba.
Funkcionalita některých částí Systému je nedostupná a nedostupnost má dopad na celorr
B skupinu uživatelů definovanou shodným pracovním postupem nebo rolí (např. Uživatel A) a
kteří tak nejsou schopni pracovat se Systémem. Jedná se o poruchy, chyby, vady, které
způsobují provozní problémy, ale neznernožňují používání a využívám Systému jako celku k
účelu, k němuž je určen, a lze je dočasně řešit organizačními nebo technickým opatřením.
Bez dopadu na dostupnost Systému - vedlejší chyba.
C Jedná se o poruchy, chyby nebo vady nízké závažnosti jednotlivých komponent Systému a
chyby slučitelné s možností vykonávat většinu úkolů s minimálním omezením nebo je řešit
vhodným alternativním postupem.
Změnový požadavek - bez dopadu na dostupnost Systému, nejedná se o incident.
CR
Změnový požadavek Zadavatele, týká se Služby rozvoje a nevztahuje se na něj doba řešení.
3.1.6.2 Parametry SLA dle kategorie požadavků HelpDesk
Pro řešení požadavku jsou nastaveny následující parametry Služeb podpoiy:
• Doba odezvy pro požadavky kategorie A. B a C: do 60 minut.
• Doba odezvy pro požadavek kategorie CR: do 12 hodin.
• Reakční doba a doba řešení jednotlivých kategorií požadavků:
Kategorie Reakční doba Produkční prostředí Školicí/testovací prostředí
A do 4 hodin
B do 12 hodin doba řešení incidentu do 12 hodin doba řešení incidentu do 36 hodin
C do 24 hodin
CR do 36 hodin doba řešení incidentu do 24 hodin doba řešení incidentu do 72 hodin
doba řešení incidentu do 60 hodin doba řešení incidentu do 180 hodin
doba řešení není specifikována doba řešení není specifikována
Vyřešením požadavku je míněno i opatření, které převede incident o kategorii níž, přičemž dochází k nastavení
SLA nižší kategorie při současném započítám již proběhlé doby nefunkčnosti pro vyšší kategorii.
3.1.6.3 Sankce za nedodržení SLA při řešení požadavků HelpDesk
Sankcí se v tomto případě rozumí poskytnutí slevy Zhotovitelem z paušální měsíční ceny Služeb podpory.
Požadovaný prvek smluvního plněni Výše sankce v Kč bez DPH za nedodržení parametru SLA
Doba odezvy Sleva ve výši 0,5 % za každou započatou hodinu zpoždění.
Reakční doba pro požadavky kategorie A, B a Sleva ve výši 1 % za každou započatou hodinu zpoždění.
C ‘ '
Reakční doba pro požadavek kategorie CR Sleva ve výši 0,5% za každých započatých 8 hodin
zpoždění.
Doba řešení požadavku kategorie A Sleva ve výši 2 % za každou započatou hodinu zpoždění.
Doba řešení požadavku kategorie B Sleva ve výši 1 % za každé započaté 2 hodiny zpoždění.
Doba řešení požadavku kategorie C Sleva ve výši 1 % za každých započatých 8 hodin zpoždění.
3.1.6.4 RTO
RTO (Recovery Time Objective) je požadováno 60 hodin.
V případě nedodržení SLA pro RTO Zhotovitel poskytne slevu z paušální měsíční ceny Služeb podpory ve výši
5% za každých započatých 24 hodin zpoždění.
3.1.6.5 RPO
RPO (Recovery Point Objective) je požadováno 60 minut.
V případě nedodržení SLA pro RPO Zhotovitel poskytne slevu z paušální měsíční ceny Služeb podpory ve výši
2% za každých započatých 60 minut zpoždění.
Stránka 74
H EVROPSKÁ UNIE
Evropský fond pro regionální rozvoj
Operační program Podnikání
a inovace pro konkurenceschopnost
3.1.7 Helpdesk Zadavatele
V rámci IS DTM ŘSD je využíván centrální HelpDesk Zadavatele, který je provozován jako standardní pracoviště
HelpDesku pro evidenci a správu veškerých požadavků. HelpDesk Zadavatele je také rozhodným nástrojem pro
měření parametrů příslušných SLA. Pracovní doba centrálního HelpDesk Zadavatele je v pracovní dny od 06:00
hod do 22:00 hod.
Požadavek musí obsahovat minimálně tyto informace:
• Identifikaci kontaktní osoby, která požadavek zadala,
• Identifikaci komponenty Systému, zařízení nebo služby, které se požadavek týká,
• Klasrfikaci požadavku dle specifikace bodu 3.1.6.1 výše,
• U změnového požadavku také datum a čas, ve kterém je jeho realizace požadována,
• Stměný, výstižný a úplný popis chyby nebo požadavku, případně další související detaily.
V intervalu doby pokrytí v případě nedostupnosti aplikace HelpDesk Zadavatel zajistí bez zbytečného odkladu
oznámení požadavku Zhotoviteli. Má-li požadavek charakter hlášení vady. Zadavatel předá Zhotoviteli již pň
registraci požadavku maximum informací, které mohou napomoci při jeho řešení. Má-li požadavek charakter
incidentu kategorie A, Zadavatel oznámí vznik takového požadavku na krizovou linku Zhotovitele. Služby
centrálního HelpDesk Zadavatel jsou současně vystaveny na ESB Zadavatele, prostřednictvím kterého si může
Zhotovitel integrovat svůj vlastní HelpDesk Zhotovitele.
3.1.8 Monitoring a odstávky Systému
3.1.8.1 Monitoring
Zhotovitel musí zajistit trvalý sběr a logování stavů jednotlivých komponent, které jsou potřebné pro poskytování
služeb IS DTM ŘSD, včetně zajištění poskytování notifikací formou SysLogu.
3.1.8.2 Odstávky obecně
Odstávkou se rozumí doba, ve které je omezen, popř. přerušen provoz IS DTM ŘSD. V průběhu odstávky
zabezpečuje Zhotovitel čimiosti nezbytné k zachovám dalšího provozu IS DTM ŘSD, tj. provádění zálohování
systémů údržby, plánovaných oprav, které není možné žádným způsobem provést za provozu apod. Doba
schválených odstávek se nezapočítává do doby nedostupnosti Systému. Odstávky jsou prioritně Zhotovitelem
zařazovány mimo vyhrazenou dobu, definovanou kalendářem služby v jejím katalogovém listu a každá musí být
předem schválena Zadavatelem.
3.1.8.3 Pravidelné plánované odstávky
Pravidelné plánované odstávky, jejichž rozsah je uveden v Plánu odstávek Odboru informatiky, který je vedený
na smluvené období. Zadavatel může požádat v naléhavých zdůvodněných případech o přesunutí tohoto typu
odstávky a Zhotovitel je povinen tomuto požadavku vyhovět, nebrání-li tomu závažné důvody. Pň plánování
odstávek se vyhodnocují a porovnávají rizika na straně Zhotovitele i Zadavatele.
3.1.8.4 Nepravidelné plánované odstávky
Schválení těchto odstávek musí být vy žádáno Zhotovitelem u Zadavatele min. 5 dní před požadovaným tennínern
odstavem Systému. V případě, že délka trvání takové odstávky přesahuje 24 hodin, musí být požadována min. 14
dní před požadovaným tennínern odstavem. Zadavatel může v naléhavých zdůvodněných případech a po vzájemné
dohodě se Zhotovitelem tento typ odstávky zamítnout pouze v případě, že jejich zamítnutím není zvýšeno provozní
riziko Zhotovitele, které může vést k havárii Systému.
3.1.9 Podpora komponent třetích stran
Obsahem je zajištění podpory' pro Zhotovitelem dodaných komponent třetích stran (proprietámí nebo open source
SW použity za podmínek Smlouvy), kterou poskytují jejich výrobci. Jeji 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 rňj,:
• 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.
Stránka 75