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
• 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 (např. 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 infonnací 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 fonnou, např. odpovědi od výrobců, doklady o registraci
podpory, licenční klíče atp.
Tato podpora je Zhotovitelem zajišťována v režimu 5x9. V případě výpadku služby, tzn. nikoli řádně zajištěné
podpory, se jedná o incident kategorie C (nízká - standardní řešení v efektivním režimu), přičemž reakční doba
zůstává zachována dle této TS, ale doba (vy)řešení (požadavku/incidentu) bude stanovena dohodou smluvních
stran
3.1.10 Podklady pro měření a vykazování služeb
Náplní je předávám údajů a podkladů, které má Zhotovitel k dispozici. Zadavateli pro potřeby sledování služeb,
jejich měření a vykazování, analyzování jejich kv ality a průběhu poskytování a vyhodnocování, využívám IS DTM
ŘSD, jeho součástí či podpůrných komponent využití IS vč. 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 on-line režimu formou
datových řezů (nebo jiných dohodnutých způsobů) či jejich předávám na dohodnutá rozhraní.
Data budou předávána v Zadavatelem odsouhlasené struktuře, formátu, frekvenci, umístění či rozhraní, které
budou definovány v Cílovém konceptu. Data budou ukládána do datového úložiště Zadavatele, odkud je bude
moct Zhotovitel načítat vhodnými nástroji, nebo budou předávána na dohodnuté rozhraní.
Zhotovitel zajišťuje tuto službu v režimu 5x12. Absence podkladů používaných pro vy hodnocení poskytovaných
služeb a jejich kv ality se považuje za výpadek služby, jejíž dostupnost a kvalitu měla chybějící data dokládat.
Tento stav se považuje zajeden souvislý incident se střední prioritou závažnosti (kategorie B).
Neagregované údaje a podklady použité pro vyhodnocení kvalitativních parametrů posky tovaných služeb za určité
vyhodnocovací období budou úplné a budou předány nejpozději v okamžiku předám výkazu poskytnutých Služeb
podpory 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 posky tovaná
v on-line režimu budou úplná a mohou být nejvýše 5 minut stará.
3.2 Další povinnosti Zhotovitele
Vyžaduje-li jakákoliv část IT prostředí Zadavatele jakoukoliv akci, která by mohla mít dopad na IS DTM ŘSD,
nebo na IT prostředí Zadavatele napojené na IS DTM ŘSD, nebo je-li nezbytná aktualizace, upgrade či jiná změna
ve standardním software, včetně standardního software, který je součástí IS DTM ŘSD a není při tom součástí
plnění Zhotovitele (tj. upgrade či změna, které nejsou součástí poskytování Služeb podpory a reprezentují
technologické komponenty Systému poskytnuté Zadavatelem) (dále jen ..Akce"), zavazuje se Zhotovitel o potřebě
provedení Akce do tri pracovních dnů od jejího proaktivního zjištění písemně vyrozumět kontaktní osobu
Zadavatele. Součástí vyrozumění je uvedení případných důsledků zamítavého rozhodnutí Zadavatele, zejména
pokud by neprovedení konkrétní Akce mělo mít negativní dopad na dohodnuté SLA ěi na funkce systému,
popřípadě na IT prostředí Zadavatele. Sledování potřeb Akcí a vyrozumívám o nich je zahrnuto v ceně Služeb
podpory. Vlastní realizace Akce patří do poskytování Služeb rozvoje.
Odmítne-li Zadavatel provedení Akce, pak Zhotovitel není oprávněn k jejímu provedení. Schválí-]i Zadavatel
provedení Akce, provede ji Zhotovitel zpravidla bezodkladně poté, co obdrží Zadavatelův souhlas nebo obdrží od
Zadavatele potřebné podklady či software (včetně standardního software), který za účelem provedení Akce
Zadavatel pořídí. Při provádění Akce se Zhotovitel zavazuje postupovat dle svého nejlepšího vědomí a v souladu
s pokyny Zadavatele.
Aktivity spadající do rámce Služeb podpory (tj. úkony, které nepředstavují Akce a Služby rozvoje), je Zhotovitel
povinen provádět proaktivně bez nutnosti získat souhlas Zadavatele.
Stránka 76
H EVROPSKÁ UNIE
Evropský fond pro regionální rozvoj
Operační program Podnikání
a inovace pro konkurenceschopnost
Je-li součástí poskytování Služeb rozvoje rozvoj Systému, je Zhotovitel povinen poskvtovat Služby podpory dle
této Smlouvy rovněž k výstupům takového rozvoje ode dne provedení a nasazení poskytnutých Služeb rozvoje.
Zhotovitel se zavazuje poskytovat Zadavateli veškerou součinnost pro zajištění komunikace a vzájemné
interoperability s dalšími počítačovými programy či infonnačními systémy nezbytnými pro plnohodnotné
fungování IS DTM ŘSD. a při provádění legislativních změn IS provázaných s IS DTM ŘSD anebo jiných změn
provázaných IS.
Provede-li Zadavatel nebo jím určená třetí osoba modifikaci, úpravu nebo změnu Díla (dále jen ,,Zásah“ ), přičemž
důsledkem Zásahu bude vada Díla či incident, není Zhotovitel odpovědný za takovou vadu či incident, pokud
s ním Zadavatel takový Zásah předem neprojednal, případně projednal a výsledkem takového projednání bylo
jednoznačný a odůvodněný nesouhlas Zhotovitele se Zásahem.
3.3 Služby Exitu
Zhotovitel se zavazuje dle pokynů Zadavatele ve lhútách dle odst. 6.7 Smlouvy, poskytnout činnosti spočívající v:
• zpracování Exitového plánu.
• přípravě a předám IS DTM ŘSD, resp. předám Služeb IS DTM ŘSD Zadavateli či novému dodavateli (jiné
třetí osobě), nebo
• přípravě na migraci dat z IS DTM ŘSD do nástupnických systémů;
a dále v poskytování veškeré potřebné součinnosti, dokumentace a infonnací a v účasti na jednáních
se Zadavatelem a třetími osobami, a to dle pokynů Zadavatele.
Tato čimiost pn ukončení plnění předmětu Smlouvy (Služby Exitu) je Zhotovitelem poskytována za cenu (sazbu)
člověkodnú Služeb rozvoje. Doba poskytování Služeb Exitu se nezapočítává do maximálního rozsahu pro
poskytování Služeb rozvoje.
Zhotovitel se zavazuje součinnost pn ukončení poskytovat s odbornou péčí, bez zbytečného odkladu
a zodpovědně, a to až do doby úplného převzetí plnění těchto služeb Zadavatelem či novým dodavatelem, které
bude potvrzeno podpisem předávacího protokolu nebo úspěšné migrace dat z IS DTM ŘSD na nástupnický
systém/systémy, jež bude potvrzena podpisem protokolu o migraci dat.
Zhotoviteli vzniká nárok na zaplacení ceny pouze za dobu skutečně a efektivně strávenou pn poskytování
součinnosti při ukončení, přičemž Zadavatel předpokládá, že rozsah poskytování součinnosti pn ukončení
nepřesáhne 100 člověkodnú.
Zhotovitel se zavazuje ve lhútách dle odst. 6.7 Smlouvy vypracovat dle pokynů Zadavatele, v souladu se zásadami
best practice a právními předpisy, zejm. ZoKB Exitový plán vymezující veškeré podmínky' pro:
• převedení plnění či jejich příslušné části na Zadavatele či nového dodavatele, či
• migraci dat do nového systému a poskytnout plnění nezbytná k této migraci.
Zhotovitel se zavazuje ve lhútách dle odst. 6.7 Smlouvy předat Zadavateli minimálně:
• kompletní aktualizovanou Dokumentaci;
• předat úplný a aktuální zdrojový kód IS DTM ŘSD v souladu s požadavky přílohy la nebo se Smlouvou;
• seznam platných administrátorských účtů k Systému a platných hesel k nim;
• úplnou knowledge base týkající se poskytování Služeb podpory (včetně popisu uzavřených požadavku
v HelpDesku Zhotovitele);
• aktuální seznam standardních provozních úkonů pro údržbu IS DTM ŘSD;
• aktuální seznam nedokončených Služeb rozvoje;
• veškerá data Zadavatele, která má Zhotovitel ve svých systémech a taková data na výzvu Zadavatele
v taliových systémech smazat, nebrání-li tomu právní předpisy;
• soupis nedokončených servisních zásahů zahájených na základě Smlouvy ke dni zániku smluvního vztahu a
návrh postupu potřebného pro jejich dokončení;
• seznam platných Zhotovitelových uživatelských účtu a souvisejících technických prostředků týkajících se
jeho plnění;
• vypořádání případných vzájemných finančních závazků a pohledávek souvisejících s ukončením smluvního
vztahu.
Stránka 77
H EVROPSKÁ UNIE
Evropský fond pro regionální rozvoj
Operační program Podnikání
a inovace pro konkurenceschopnost
4 SLUŽBY ROZVOJE
Součástí Služeb rozvoje jsou jak úpravy (konfigurační či jiné) a další rozvoj IS DTM ŘSD. tak i úpravy v rámci
změnového řízení Projektu, služby projektového řízení, poskytování školení a konzultace nebo rozšíření Systému
o nové SW komponenty. K plném vzniklému Službami rozvoje mohu být po jejich akceptaci poskytovány služby
podpory a údržby, a jiné činnosti, které nejsou součástí Služeb podpory' definovaných v kap. 3.1.1., respektive
mohou být Služby podpory o tyto činnosti rozšířeny. Služby rozvoje budou poskytovány v rozsahu člověkodnň
uvedených v příloze č. 4 Smlouvy. Nevyčerpané člověkodny se bez omezení převádějící do následujících let,
přičemž pro účely fakturace a využití nevyčerpaných člověkodnú jsou vždy čerpány člověkodny „nejstarší".
Zhotovitel je povinen na základě analýzy incidentů navrhovat, a po schválení Zadavatelem na úrovni Systému
v rámci Služeb rozvoje implementovat nové způsoby monitorování a bezpečnostního dohledu Systému s cílem
zrychlit detekci incidentů.
Služby rozvoje budou Zadavatelem poptávány za následujících podmínek:
a) Zadavatel je od okamžiku účinnosti Smlouvy oprávněn kdykoli zaslat Zhotoviteli standardní fonnou
změnového řízení Projektu požadavek na poskytnutí Služeb rozvoje (dálejen „Požadavek“). Požadavek musí
být podepsán či zadán k tomu oprávněnou osobou Zadavatele a musí obsahovat minimálně:
i. konkrétní označení, zdůvodnění a bližší specifikaci plnění, které je zadáváno;
ii. termín realizace plnění.
Požadavek může dále obsahovat Zadavatelem předpokládaný rozsah plnění, základní akceptační kritéria
požadovaného plnění, případně předpokládanou cenu za plnění stanovenou v souladu s cenovými
podmínkami uvedenými v této Smlouvě. Požadavek není návrhem na uzavření dílčí smlouvy (k
poskytování Služeb rozvoje se neuzavírají dílčí smlouvy).
b) Zhotovitel musí do 10 pracovních dnů od obdržení Požadavku ze strany Zadavatele, nedohodnou-li se
smluvní strany jinak, doručit kontaktní osobě Zadavatele nabídku na realizaci Požadavku (dále jen „Analýzu
požadavku"), která musí obsahovat minimálně:
i. odkaz na uzavřenou Smlouvu;
ii. návrh řešení Požadavku a specifikace předmětu Služeb rozvoje včetně analýzy dopadů na Systém;
ůi. termíny plnění (časový harmonogram) Služeb rozvoje včetně analýzy dopadů na harmonogram
Projektu;
iv. požadavky na součimiost Zadavatele a třetích osob;
v. cenový návrh realizace Požadavku vycházející z rolí, nutných pro jeho realizaci v souladu
s předloženým návrhem řešení, jejich ceny za 1 člověkoden a ceny případných dalších souvisejících
dodávek a služeb, která bude určena na základě poctivé a dobré víry Zhotovitele posouzením
pracnosti poptávaných Služeb rozvoje a případného dalšího plnění;
ví. specifikace počtu a konkrétních pozic/rolí členů Realizačního týmu, prostřednictvím kterých
Poskytovatel plánuje Služby rozvoje dle návrhu řešení Požadavku realizovat; není-li mezi smluvními
stranami výslovně dohodnuto něco jiného, je Zhotovitel povinen realizovat předmětné Služby
rozvoje v talcovém složení Realizačního týmu, které na základě poctivé a dobré vity Zhotovitele co
nejlépe napomůže řádnému, včasnému a co nejefektivnějšímu a nejkvalitnějšímu posky tnutí daných
Služeb rozvoje Zadavateli; a
vii. návrh konkrétních akceptačních kritérií realizovaného řešení Požadavku vycházející ze základních
akceptačních kritérií určených Zadavatelem v Požadavku.
Vyžaduje-li zpracování Analýzy požadavku jednám Zhotovitele se Zadavatelem, je Zhotovitel takové
jednám písemně navrhnout nejpozději do 5 pracovních dnů od doručení Požadavku. Zadavatel takové
jednám bez vážného důvodu neodmítne. V rámci jednání bude sjednán závazný termín předání Analýzy
požadavku (v případě, že se smluvní strany nebudou schopny dohodnout na takovém termínu, bude činit 10
pracovních dnů ode dne jednání Zhotovitele se Zadavatelem).
Zpracování jakékoliv Analýzy požadavku a případná jednám dle předchozího odstavce jsou součástí Služeb
podpory v rozsahu 50 člověkodnú ročně, přičemž pracnost vypracování jedné Analýzy požadavku by se
měla pohybovat v rozsahu do 5 člověkodnú. Činnosti v rozsahu převyšujícím rozsah 50 člověkodnú ročně
budou hrazeny sazbou za člověkoden Služeb rozvoje podle kategorie rolí pro pozice, realizující předmětné
Služby rozvoje, a to v rozsahu Zhotovitelem skutečně poskytnutých a Zadavatelem akceptovaných
člověkodnú. Počet čerpaných člověkodnú v každém kalendářním měsíci bude součástí výkazu plnění
Stránka 78
H EVROPSKÁ UNIE
Evropský fond pro regionální rozvoj
Operační program Podnikání
a inovace pro konkurenceschopnost
Služeb podpory. V případě, že se jednám uskuteční na území města Ostravy a/nebo hlavního města Prahy,
nelze čas na cestě na případná jednání zahrnovat do čerpaných člověkodnú v žádném rozsahu.
Vyžaduje-li realizace Služeb rozvoje pořízem licencí nebo rozšíření licencí stávajících, je Zhotovitel
povinen tuto skutečnost uvést v Analýze požadavku, a to včetně uvedení předpokládané ceny takového
plnění.
V případě, že realizace Služeb rozvoje bude mít objektivně za důsledek zvýšení pracnosti pn poskytování
Služeb podpory, je Zhotovitel povinen v Analýze požadavku na to Zadavatele upozornit a vyčíslit dopady
na navýšení ceny Služeb podpory, a to v souladu s odst. 5.8 Smlouvy.
V případě, že realizace Služeb rozvoje vyžaduje pořízem a poskytnutí dalších plnění, které nelze vymezit
v člověkodnech (zejména pořízení HW, SW, nová maintenance) je Zhotovitel povinen v Analýze
požadavku na to Zadavatele npozonut a vyčíslit jejich hodnotu. Zhotovitel bere na vědomí, že pořízení
takového plnění může být novou veřejnou zakázkou, k níž bude mít Zadavatel povinnost postupovat
v souladu se ZZVZ, a je povinen posky tnout Zadavateli potřebnou součinnost k pořízem takového plnění,
nebude-li možné jej pořídit přímo od Zhotovitele (např. definovat technické podmínky ). Hodnota těchto
dalších plnění se nezapočítává do ceny konkrétní Služby rozvoje, z níž je případně počítáno navýšení ceny
Služeb podpory dle předchozího odstavce a odst. 5.8 Smlouvy.
c) V případě, že Zadavatel souhlasí s navrženou Analýzou požadavku, bude Zhotovitele o této skutečnosti bez
zbytečného odkladu písemně informovat. Zadavatel je oprávněn i bez udám důvodu Zhotovitelem
předloženou Analýzu požadavku odmítnout, nebo se k ní nevyjádřit, nebo si vyžádat její úpravu dle svých
odůvodněných požadavků.
d) V případě, že si Zadavatel vyžádá úpravu Analýzy požadavku, je Zhotovitel povinen tuto úpravu provést bez
zbytečného odkladu za obdobného použití písm. b).
e) Zhotovitel se zavazuje na základě oboustranně schválené Analýzy požadavku realizovat jakékoliv zadání
Požadavku nebo požadavek vznesený Zadavatelem v souladu s touto Smlouvou.
f) Zadání Požadavku se stává součástí odsouhlasené Analýzy požadavku v rozsahu, v jakém ustanovením
Analýzy požadavku neodporuje, a pro výklad ustanovení Analýzy požadavku se použije společně s touto
Smlouvou subsidiámě.
g) Pro vyloučení pochybností se stanoví, že Zadavatel není v průběhu trvání této Smlouvy povinen poptat žádné
Služby rozvoje.
h) Řádné provedení Služeb rozvoje bude oběma smluvními stranami písemně potvrzeno podpisem
Akceptačního protokolu po ukončení akceptačmho řízení poskytnutých Služeb rozvoje. Jsou-li Služby
rozvoje plněny po částech, které rnají být postupně předávány Zadavateli, použijí se ustanovení pro
Akceptační řízení přiměřeně vždy na každou takovou dílčí část plnění, nedohodnou-li se smluvní strany
výslovně jinak.
i) Provádění Služeb rozvoje a stavjejich plněníje Zhotovitel povinen evidovat zpětně za každý měsíc provádění
Služeb rozvoje v rámci výkazu plnění předávaného Zadavateli.
5 AKCEPTACE PLNĚNÍ
Akceptace realizovaného plném bude probíhat na základě Akceptačního řízení. Tato kapitola upřesňuje postup
Akceptace, definuje akceptační kritéria a stanovuje požadavky na akceptaci výstupů plnění Smlouvy.
Proces akceptačmho řízem bude třístupňový a bude zahrnovat vytvoření návrhu na akceptaci a následnou akceptaci
na řídících úrovních Projektu. Podrobný postup akceptační procedury definuje Základní dokument Projektu (viz
kap. 2.6.2), který musí respektovat níže uvedené principy a pravidla akceptace.
5 .1 P ravidla a k c e p ta c e
Předám a převzetí bude probíhat postupně formou předání a převzetí výstupů připravovaných v jednotlivých
Etapách a fázích Projektu a podpisem Akceptačmho protokolu pro každou Etapu. Akceptační řízení zahrnuje
porovnám skutečných vlastností realizovaných plnění se specifikací plnění dle Smlouvy a Akceptačními kritérii.
V souladu s touto Smlouvou nebo dohodou smluvních stran mohou být akceptovány i dílčí části plnění (nejen celé
Etapy nebo fáze Projektu, přičemž však akceptace celé Etapy proběhne vždy), v takovém případě se postupuje dle
této kapitoly přiměřeně i pro takové dílčí části.
Pokud bude příslušná Etapa splněna drive, než je uvedený nejzazší termín podle harmonogramu, proběhne
akceptace ve skutečném termínu dodání výstupu.
Zhotovitel vyzve Zadavatele k zahájení Akceptačmho řízení za příslušnou Etapu nejpozději 10 dní před
stanoveným milníkem pro akceptaci dané Etapy. V den předám výstupu plnění, který je předmětem Akceptačmho
Stránka 79
H EVROPSKÁ UNIE
Evropský fond pro regionální rozvoj
Operační program Podnikání
a inovace pro konkurenceschopnost
řízení počíná Zadavateli běžet lhúta pro realizaci testování a vyjádření akceptačních výhrad nebo připomínek. Tato
lhúta činí maximálně 30 pracovních dnů, nedohodnou-li se smluvní strany jinak.
5.2 Akceptační kritéria
Akceptační kritéria pro příslušnou část předmětu plnění budou mezi Zadavatelem a Zhotovitelem upřesněna
v rámci Základního dokumentu Projektu (viz kap. 2.6.2). Níže je uvedena minimální definice akceptačních kritérií
Zadavatele. Seznam akceptačních kritérií a způsob provedení akceptační procedury pro jednotlivé části plnění
musí být upřesněn nejpozději v okamžiku, kdy mají být práce na předmětné části předmětu plnění započaty dle
schváleného harmonogramu. Strategie testování a testovací scénáře budou odsouhlaseny mezi Zadavatelem a
Zhotovitelem v rámci Cílového konceptu příslušné Etapy plnění.
Pro potřeby hodnocení výsledků akceptace a stanovení příslušných akceptačních kritérií jsou stanoveny následující
možné výsledky:
• Bez vad/připonůnek,
• S vadou/připomínkou,
• Nevvhovělo/neakceptováno.
Pro akceptaci Služby rozvoje a Služby Exitu se předchozí odstavec i další ustanovení tohoto článku použijí
přiměřeně s tím, že Akceptační kritéria pro Služby rozvoje budou stanovena v akceptované Analýze požadavku a
Akceptační kritéria pro Služby Exitu budou stanovena v Exitovém plánu, nedohodnou-li se smluvní strany jinak.
5.2.1 Akceptační kritéria pro sořtware/Systém
Akceptace dodávek a realizace SW probíhá v testovacím (školícím) prostředí Zadavatele. Pro potřeby hodnocení
výsledku testů „s vadou“ jsou definovány následující klasifikace vad:
• „Vadou kategorie AI se rozumí vada, která vylučuje užívám Systému jako celku nebo jeho podstatné či
ucelené části, vyplývá z nedodržení závazných právních předpisů, zapříčiní ztrátu dat, způsobuje, že použití
Systému by nebylo bezpečné nebo by plně neodpovídalo zásadám bezpečnostní politiky Zadavatele, ohrožuje
provoz nebo dostupnost jiné aplikace nebo samotného Systému v provozním prostředí Zadavatele, způsobuje,
že Systém není schopen zvládat běžnou provozní zátěž nebo za provozních podmínek vede k omezení
funkcionality Systému s dopadem na významný počet uživatelů.
• „Vadou kategorie B1 se rozumí vada. omezující provoz, která způsobuje problémy při užívám
a provozování Systému nebo jeho části, ale umožňující provoz, nemá vliv na kvalitu dat a výsledky
zpracování a jí způsobené problémy lze dočasně řešit např. organizačními opatřeními nebo je možné pro její
překonám nalézt odpovídající alternativu, která je akceptovatelná Zadavatelem.
• „Vadou kategorie C l“ se rozumí ostatní vady, nespadající do kategorie AI ani B1 a mající povahu
..kosmetického" charakteru - tj. taková vada, jejíž výskyt neovlivňuje zásadním způsobem aktivity uživatelů
a výsůipy z těchto aktivit.
Povaha či celkový počet vad. zjištěných při akceptaci, nesmí zásadním způsobem omezovat provádění
ověřovacího provozu.
Kategorii vady vždy posoudí pracovník Zadavatele odpovědný za provedení příslušného testu s pracovníkem
Zhotovitele, klen odpovídá za daný test. Neshodnou-li se na kategorii vady, eskalují tuto neshodu v souladu
s ustanoveními Základního dokumentu Projektu. Do rozhodnutí platí stanovisko Zadavatele.
Akceptační řízem bude považováno za ukončené jako „Akceptované", pokud nebude obsahovat žádnou vadu.
Zadavatel přijme závěr „Akceptováno s výhradami", bude-li plnění obsahovat vady, avšak nedosálme níže
uvedený počet vad.
Akceptaci s výhradami nelze provést, pokud existuje alespoň 1 vada kategorie AI nebo více jak 12 vad kategorie
B1 nebo více jak 60 vad kategorie Cl. V průběhu akceptačmho řízení bude každá zjištěná vada evidována v
seznamu vad včetně lhůty k odstranění každé jednotlivé vady, který je přílohou akceptačmho protokolu.
Nebude-li v maximální lhůtě 30 pracovních dnů ode dne předání výstupu plnění, který je předmětem Akceptačmho
řízení, dosaženo stavu umožňujícího alespoň přijmout předmět akceptace s výhradami, je výsledek Akceptačmho
rizení „Něvyhověl/neakceptován".
Pokud uplynul stanovený milník pro Akceptační rizení příslušného plnění, má se zato, že je Zhotovitel s tímto
plněním v prodlení.
Stránka 80
H EVROPSKÁ UNIE
Evropský fond pro regionální rozvoj
Operační program Podnikání
a inovace pro konkurenceschopnost
5.2.2 Akceptační kritéria pro dokumentaci
Cílem akceptace dokumentů je věcně správný a pravdivý dokument (projektový výstup) zachycující dohodu obou
smluvních stran na konkrétní výsledné podobě předmětného plnění. Vzniku a akceptaci dokumentu bude
předcházet dohoda o jeho charakteru, struktuře (osnově) a rámcovém obsahu. Zhotovitel je oprávněn požádat
Zadavatele o projednám a odsouhlasení úrovně detailu dokumentu a pokud je taková úroveň detailu Zadavatelem
předem odsouhlasena, stává se závaznou.
Hodnocení a akceptace předané dokumentace bude prováděno způsobem jejího revidování a připomínkování
postupem: předložení návrhu dokumentu Zhotovitelem - vznesení připomínek Zadavatelem - vypořádání
připomínek Zhotovitelem - kontrola vypořádám Zadavatelem - rozhodnutí o výsledku akceptace. Pro výsledek
akceptace ,,s připomínkou "jsou definovány následující klasifikace připomínek k dokumentaci podle jejich
závažnosti:
• „Připomínka kategorie A2“ se rozumí připomínka, kdy v požadovaném dokumentu chybí textové části,
vyplývající z definované struktury dokumentu, nebo textová část neodpovídá skutečnosti pro popisovanou
problematiku.
• „Připomínka kategorie B2“ se rozumí připomínka, kdy v požadovaném dokumentu je nejednoznačnost
textové části.
• „Připomínka kategorie C2“ se rozumí ostatní připomínky, nespadající do kategorie A2 ani B2 a mající
povahu gramatické nebo pravopisné chyby, nevhodného formátování, překlepů apod.
Akceptační řízení bude považováno za ukončené jako „Akceptovaném pokud nebude obsahovat žádnou
připomínku. Zadavatel přijme závěr „Akceptováno s výhradami'', bude-li plnění obsahovat připomínky, avšak
nedosálme níže uvedený počet připomínek.
Akceptaci s výhradami nelze provést, pokud existuje alespoň 1 připomínka kategorie A2 nebo více jak
10 připomínek kategorie B2 nebo více jak 30 připomínek kategorie C2. V případě akceptace s vý hradami bude
přílohou akceptačního protokolu seznam připomínek včetně ihúly k odstranění každé jednotlivé připomínky.
Nebude-li v maximální lhútě 30 pracovních dnů ode dne předání výstupu plnění, který je předmětem Akceptačního
řízení, dosaženo stavu umožňujícího alespoň přijmout předmět akceptace s výhradami, je výsledek Akceptačního
řízení „Nevyhověl/neakceptovárik
Pokud uplynul stanovený milník pro Akceptační řízení příslušného plnění, má se za to, že je Zhotovitel s tímto
plněním v prodlení.
5.2.3 Společná ustanovení pro akceptační kritéria
Plnění bude akceptováno bez výhrad, pakliže nebude vykazovat žádné vady kategorie AI, B1 a Cl nebo otevřené
připomínky7kategorie A2, B2 nebo C2 dle výše uvedených definicí. Výrok „akceptováno bez výhrad“ je
podmínkou pro vystavení faktury pro takové plnění.
Za předpokladu, že nebudou překročeny shora stanovené počty přípustných vad nebo přípustných otevřených
připomínek, bude plnění akceptováno s vý hradou. Výrok “akceptováno s výhradou" znamená, že Zhotovitel
je povinen odstranit vady nebo připomínky, avšak od okamžiku předám k akceptaci není v prodlení s plněním.
Prodlení počíná běžet v případě neodstranění vad nebo připomínek ve stanovené lhútě. Nárok na fakturaci ceny za
plnění však vzniká až v okamžiku odstranění všech vytčených vad a připomínek.
Budou-li překročeny shora stanovené počty přípustných vad v jednotlivých kategoriích, nebude plnění
akceptováno.
5.3 Testy a nasazení Systému do provozního prostředí
Výchozím podkladem všech testů Systému je definice strategie testování (metodika testování, klasifikace vad,
proces oznamování a odstraňování vad, proces přerušení a opětovné zahájení testů, fonnát dokumentu Testovací
protokol atd.) a schválené dokumentace testování (testovací případy, testovací scénáře, testovací data), které jsou
nedílnou součástí dokumentů Definice Projektu a Cílových konceptů pro každou Etapu realizace Systému,
vy pracovaných Zhotovitelem.
5.3.1 Systémové funkční testy
Systémové funkční testy (FAT) zastřešují testování Systému podle připravených testovacích případů a scénářů.
Testy ověřují funkčnost Systému dle specifikovaných požadavků a probíhají na základě schválené dokumentace
testování. Testování provádí Zhotovitel ve spolupráci s pracovníky Zadavatele a probíhá v testovacím prostředí
Zadavatele.
Procedura funkčních testů obsahuje následující klíčové aktivity:
Stránka 81
EVROPSKÁ UNIE
Evropský fond pro regionální rozvoj
Operační program Podnikání
a inovace pro konkurenceschopnost
• definice požadavků na funkční testování v souladu s Cílovým konceptem,
• nasazení Systému na testovací prostředí Zadavatele (definované prostředí pro funkční testy),,
• příprava a naplánování funkčních testů (testy prováděné Zhotovitelem):
o příprava a odsouhlasení testovacích scénářů,
o příprava a odsouhlasení testovacích dat pro funkční testy,
o příprava a odsouhlasení testovacího plánu jednotlivých částí Systému,
• vyhodnocení výsledků testů, odstraňování nedostatků zjištěných pn testování, správa vad a připomínek,
příprava potřebných podkladů a akceptace funkčních testů.
5.3.2 Integrační testy
Integrační testy provádí Zhotovitel ve spolupráci s dodavateli integrovaných systémů v testovacím prostředí
Zadavatele. Součinnost dodavatelů integrovaných systémů a další nezbytnou součinnost pro integrační testování
zajistí Zadavatel.
Procedura integračních testů obsahuje následující klíčové aktivity:
• definice požadavků na integrační testování v souladu s Cílový m konceptem,
• nasazení Systému na cílovou infrastrukturu Zadavatele (definované prostředí pro integrační testy),
• příprava a naplánování integračních testů (testy prováděné Zhotovitelem):
o příprava a odsouhlasení integračních scénářů,
o příprava a odsouhlasení testovacích dat pro integraci,
o příprava a odsouhlasení testovacího plánu jednotlivých částí integrací,
• vy hodnocení výsledků testů, odstraňování nedostatků zjištěných pn testování, správa vad a připomínek,
příprava potřebných podkladů a akceptace integračních testů.
5.3.3 Uživatelské akceptační testy
Uživatelské akceptační testy (UAT) provádí Zadavatel za nezbytné podpory Zhotovitele.
Procedura UAT obsahuje následující klíčové aktivity:
definice požadavků na testování v souladu s Cílovým konceptem,
příprava a naplánování uživatelský ch akceptačních testů,
podpora uživatelů při provádění uživatelských akceptačních testů,
vyhodnocení výsledků testů,
odstraňování nedostatků zjištěných při testování, správa vad a připomínek,
podpora uživatelů při re-testu odstraněných nedostatků,
příprava potřebných podkladů a akceptace UAT,
vytvoření detailního harmonogramu nasazení Systému do ověřovacího a ostrého provozu a další činnosti
související se zahájením ostrého provozu.
5.3.4 Penetrační a bezpečnostní testy
Před nasazením do provozního prostředí provede Zadavatel nebojím pověřená třetí osoba penetrační
a bezpečnostní testy v testovacím prostředí Zadavatele. Výsledkem těchto testů nesmí být bezpečnostní nález.
V případě nálezu je nutné zjištěnou vadu odstranit a test opakovat. Bez úspěšně provedeného penetračního testu
není možné plnění akceptovat.
5.3.5 Připravenost k nasazení do provozního prostředí
Nasazení do provozního prostředí provádí Zadavatel. Podklady pro provedení nasazení zajistí Zhotovitel. Nutnou
podmínkou je úplná finální migrace dat do IS DTM ŘSD.
Procedura nasazení do provozního prostředí obsahuje následující klíčové aktivity:
• nastavení prostředí pro provoz IS DTM ŘSD a nasazení Systému do tohoto prostředí,
• příprava a provedení školení interních školitelů, uživatelů a administrátorů.
Stránka 82
H EVROPSKÁ UNIE
Evropský fond pro regionální rozvoj
Operační program Podnikání
a inovace pro konkurenceschopnost
• příprava a schválení dokumentu Release Management.
5.4 Metody akceptace
Zadavatel níže uvádí přehled vyžadovaných metod akceptace.
5.4.1 Akceptace plnění typu software
Plnění mající charakter software se ověřují příslušnými typy testu (viz kap. 5.2.3), které budou dále upřesněny a
vymezeny ve strategii testování ve schváleném Cílovém konceptu. Akceptačním kritériem je výsledný počet vad
podle jejich závažnosti A, B, C a D platný pro daný typ testu (viz kap. 5.2.1 a 5.2.3).
5.4.2 Akceptace výkonnostních parametrů
Chovám Systému z pohledu jeho výkonnosti je součástí ověřování během uživatelského akceptačního testu
a 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
IS DTM ŘSD plně integrovaného do prostředí Zadavatele. Požadované celkové hodnoty výkonnostních indikátoru
budou takto koncipovány - bude navrženo Zhotovitelem na základě výstupů úvodní analýzy a schváleno
Zadavatelem v rámci Cílového konceptu příslušné Etapy.
Součástí někteiých indikátorů je rovněž čas pro zpracování souvisejících čiímostí uživateli nebo čas pro obdobné
zpracování, přičemž čas pro zpracování souvisejících čimiostí uživateli nebo čas pro obdobné zpracování není
součástí hodnocení výkonnostních indikátorů během akceptace.
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.
5.4.3 Akceptace dokumentů (včetně Základního dokumentu Projektu a Cílových konceptů)
Akceptace výstupů, které mají povahu dokumentů či dokumentace, se řídí podmínkami stanovenými v kap. 5.2.2,
5.2.3 a případně ve Smlouvě.
Doplňující podmínky pro akceptaci dokumentů:
• Připomínkování dokumentu bude probíhat ve 2 fázích:
o V první fázi budou Zadavatelem předány kompletní konsolidované připomínky k celému dokumentu do
5 pracovních dnů od data zahájení připomínkování, ve fonně tabulky, společně s uvedením autora
připomínky, data vytvoření a kategorizací připomínky v souladu s kapitolou 5.2.2;
o Zhotovitel připomínky vypořádá do 3 pracovních dnů do dokumentu i do tabulky, nedohodnou-li se
smluvní strany na lhůtě delší. V této fázi poskytne Zadavatel požadovanou efektivní součinnost na
žádost Zhotovitele;
o Ve druhé fázi Zadavatel zkontroluje způsob vypořádání evidovaných připomínek a v případě potřeby
do 3 pracovních dnů označí neakceptované připomínky. Následně proběhne stejná procedura
vypořádám ze strany Zhotovitele až do vypořádám všech připomínek kategorie A a B.
• Po vypořádám připomínek A a B Zhotovitel připraví návrh příslušného akceptačního protokolu a zašle jej
Zadavateli k revizi, jakmile obě strany schválí výsledné znění akceptačního protokolu, může být daný výstup
postoupen k jeho akceptaci.
• Pokud nejsou vypořádány připomínky' kategorie A a B 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.
Zadavatel v takovém případě navrhne v souladu se Smlouvou další postup a předloží jej Zhotoviteli ke
schválení.
• Zadavatel 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ů Zadavatele.
• Kategorii připomínky' určuje Zadavatel. Pokud se nad označením kategorie připomínky nepodaří najít shodu,
postupuje se dále podle eskalačního procesu s cílem najít shodu.
• Než bude taková shoda nalezena, považuje se kategorie připomínky za takovou, jak ji určil Zadavatel. Bude-
li ve výsledku eskalačního procesu kategorie připomínky' snížena, má toto snížení kategorie účinnost k
původnímu datu uplatnění připomínky Zadavatelem (tzn. i zpětně) se všemi důsledky s tím spojenými.
Stránka 83
H EVROPSKÁ UNIE
Evropský fond pro regionální rozvoj
Operační program Podnikání
a inovace pro konkurenceschopnost
5.4.4 Akceptace migrace dat do IS DTM ŘSD
Zhotovitel dodá protokol o provedené migraci. Migrace se považuje za úspěšnou, pokud bylo způsobem určeným
v migračních strategiích, schválených v Cílovém konceptu a dále rozpracovaných v příslušných plánech,
přemigrováno nejméně 90 % dat určených k migraci, přičemž správnost a úplnost dat přemigrovaných do Systému
byla úspěšně ověřena stanoveným způsobem validace a rekonciliace a současně byl stanoven termín a způsob
přenesení dat, které se nepodařilo takto přemigrovat.
5.4.5 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í, přičemž všeclmy připomínky
byly vypořádány. Školící materiály a pomůcky se akceptují metodou akceptace výsúipních dokumentů Projektu.
5.4.6 Akceptace provedeného úkolu
Provedený úkol je považován za akceptovaný, pokud příjemce výsledku tohoto úkolu (např. tým Zadavatele
instaluje předávaný software) písemně potvrdí, že Zhotovitel řádně provedl zadaný úkol v dohodnutém rozsahu,
čase a místě.
5.4.7 Akceptace předávaných položek
Předávané položky, které nejsou předmětem specifického typu testu nebo 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 stměným popisem, pokud ze samotného textu předávané položky není
plně zřejmý její obsah).
Stránka 84