RÁMCOVÁ DOHODA
RÁMCOVÁ DOHODA
o poskytování technické podpory a rozvoje softwaru systému hraniční kontroly
KODOX
JID: PCR99ETRpo43225769
Číslo smlouvy objednatele: PPR-22687-19/ČJ-2023-990656
Smluvní strany:
Česká republika – Ministerstvo vnitra
Sídlo: Nad Xxxxxx 000/0, XXX 000 00, Xxxxx
IČO: 00007064
DIČ: CZ00007064
Zastoupená: plk. Mgr. Xxxxxxxxxxx Xxxxxx, ředitelem Národního centra
informačních a komunikačních technologií Policejního prezidia České republiky
Bankovní spojení: 5504881/0710, Česká národní banka
Korespondenční adresa: Policejní prezidium ČR, Národní centrum informačních
a komunikačních technologií, poštovní schránka 62/NCIKT, Xxxxxxxxxx 00, 000 00 Xxxxx 0
Datová schránka: gs9ai55 (dále jen „Objednatel“ nebo „Zadavatel“) a
AUROTON COMPUTER, spol. s r.o.
Sídlo: Xxxxxxxx 000/00, 00000 Xxxxx 0
IČO: 43871437
DIČ: CZ43871437
Zastoupená:
Bankovní spojení: Unicredit bank, č.ú: 35102111/2700 Korespondenční adresa: Xxxxxxxx 000/00, 00000 Xxxxx 0 Xxxxxx schránka: hctn9ef
Obchodní společnost zapsaná v obchodním rejstříku vedeném Městským soudem v Praze, oddíl C, vložka 5013
(dále jen „Dodavatel“)
(společně dále také jen „Smluvní strany“, nebo jednotlivě „Smluvní strana“)
uzavřely v souladu s ustanoveními zákona č. 89/2012 Sb., občanský zákoník, (dále jen „občanský zákoník“) a zákona č. 134/2016 Sb., o zadávání veřejných zakázek (dále jen „ZZVZ“) tuto
Rámcovou dohodu o poskytování technické podpory a rozvoje softwaru systému hraniční
kontroly KODOX
(dále jen „Dohoda“ nebo „rámcová dohoda“)
PREAMBULE
1. Tato Dohoda je uzavřena na základě výsledků zadávacího řízení, které bylo uskutečněno dle ust. zákona č. 134/2016 Sb., o zadávání veřejných zakázek k veřejné zakázce s názvem “ Poskytování technické podpory a rozvoje softwaru systému hraniční kontroly KODOX - Rámcová dohoda“ č.j.: PPR-22687/ČJ-2023-990656 (dále též „Veřejná zakázka“).
2. Tato Rámcová dohoda vymezuje obecné obchodní podmínky v budoucnu uzavřených dílčích smluv (objednávek). Tato Xxxxxxx dohoda se uzavírá s jedním Dodavatelem.
1. PŘEDMĚT DOHODY
1.1. Dodavatel se zavazuje poskytnout Objednateli plnění specifikované touto Dohodou a jejími přílohami, dle podmínek a v rozsahu stanoveném touto Dohodou. Dodavatel na základě této Dohody dodá zejména následující plnění:
a) Plnění A – Poskytování technické podpory provozu IS KODOX
- Plnění A. 1 – Technická podpora provozu IS KODOX - fixní část, blíže definováno v Příloze č. 1 této Dohody (dále také jen „Plnění A. 1“);
- Plnění A. 2 – Technická podpora provozu IS KODOX - variabilní část, blíže definováno v Příloze č. 1 této Dohody (dále také jen „Plnění A. 2“);
(Plnění A. 1 a Plnění A. 2 dále společně také jen „Plnění A“).
b) Plnění B – Rozvoj IS KODOX, blíže definováno v Příloze č. 1 této Dohody (dále také jen
„Plnění B“);
c) Plnění C – Předání systému novému dodavateli nebo Zadavateli, blíže definováno v Příloze č. 1 této Dohody (dále také jen „Plnění C“)
(Plnění A až Plnění C souhrnně dále též „Předmět plnění“)
1.2. Podrobná specifikace Předmětu plnění je uvedena v Příloze č. 1 této Dohody.
1.3. Objednatel se za řádně poskytnuté plnění zavazuje Dodavateli zaplatit cenu specifikovanou v Příloze č. 4 této Dohody.
1.4. Objednatel se touto Rámcovou dohodou nezavazuje k objednávce v určitém rozsahu ani v určité minimální hodnotě a Objednatel bude vždy postupovat v souladu se svými potřebami, přičemž Dodavateli nevzniká touto Dohodou právní nárok na odběr určitého jím poskytovaného plnění ze strany Objednatele.
2. POSTUP PŘI UZAVÍRÁNÍ DÍLČÍCH SMLUV
2.1. Na základě této Rámcové dohody budou uzavírány dílčí smlouvy, a to postupem
stanoveným touto Dohodou a zákonem.
2.2. Tato Rámcová dohoda bude plněna na základě písemných výzev k poskytnutí. Objednávka je návrhem na uzavření dílčí smlouvy plnění (dále také jen „Objednávka"). Objednávka musí obsahovat minimálně tyto náležitosti:
a) identifikační údaje Smluvních stran;
b) označení Rámcové dohody;
c) číslo Objednávky;
d) podrobnou specifikaci požadovaného plnění;
e) místo a dobu požadovaného plnění;
f) specifikaci ceny;
g) podpis Objednatele.
2.3. Každá jednotlivá dílčí Objednávka bude Objednatelem odeslána Dodavateli prostřednictvím datové schránky nebo prostřednictvím Národního elektronického nástroje (NEN). Dodavatel odešle Objednateli potvrzení Objednávky či podnět k její úpravě nejpozději do pěti (5) pracovních dnů od jejího doručení. Potvrzení Objednávky Dodavatelem je přijetím návrhu dílčí smlouvy. Jednotlivé Objednávky budou uzavírány v souladu s touto Dohodou a jejími přílohami.
2.4. Objednatel je pro účely stanovení celkové ceny resp. pracnosti za požadované Plnění A. 2 a Plnění B nebo pro účely bližší specifikace požadovaného plnění oprávněn písemně vyzvat Dodavatele k podání nabídky nebo k doplnění požadovaných informací, a to prostřednictvím datové schránky nebo prostřednictvím Národního elektronického nástroje (NEN). Dodavatel je povinen na základě výzvy doručit Objednateli svou nabídku nebo požadované informace, a to ve lhůtě stanovené v předmětné výzvě. Nabídka Xxxxxxxxxx nesmí být v rozporu s touto Rámcovou dohodou. Dodavatel není oprávněn navrhnout ve své nabídce smluvní podmínky, které budou pro Objednatele méně výhodné v porovnání s jeho nabídkou v zadávacím řízení a touto Dohodou.
3. CENA ZA PLNĚNÍ
3.1. Objednatel má povinnost zaplatit Dodavateli za řádně poskytnuté plnění sjednanou cenu.
3.2. Celková cena plnění dle Objednávek uzavřených dle této Dohody (tj. součet smluvních cen uzavřených Objednávek) nesmí přesáhnout 107 946 068,00 Kč bez DPH (stosedmmilionůdevětsetčtyřicetšesttisícšedesátosm korun českých), 130 614 742,28 Kč s DPH (stotřicetmilionůšestsetčtrnácttisícsedmsetčtyřicetdva korun českých dvacetosm haléřů).
3.3. Podrobné určení jednotkových cen pro jednotlivá plnění je uvedeno v Příloze č. 2 této
Dohody.
3.4. Smluvní strany se dohodly, že cena za plnění dle konkrétní Objednávky je cenou nejvýše přípustnou a nepřekročitelnou. Pokud není Rámcovou dohodou, nebo příslušnou Objednávkou stanoveno jinak, sjednaná cena zahrnuje veškeré náklady, které Dodavateli v souvislosti s řádným poskytováním dohodnutého plnění vzniknou, vč. veškerých licenčních poplatků, nákladů na dopravu, cel, nákladů na balení, doručení apod., a jsou v nich zohledněna rizika, bonusy, slevy a další vlivy ve vztahu k celkové době plnění dle této Dohody.
3.5. Cena plnění bude upravena o případnou zákonnou procentní změnu DPH, a to ode dne
účinnosti změny.
3.6. Veškeré ceny dohodnuté v této Dohodě a dílčích Objednávkách jsou ceny v korunách českých.
4. PLATEBNÍ PODMÍNKY
4.1. Dodavatel je povinen vystavit platební doklad (tzv. fakturu) do 10 dnů ode dne podpisu příslušného akceptačního protokolu oběma Smluvními stranami. Vzor akceptačního protokolu tvoří Přílohu č. 7 této Dohody.
4.2. Dodavatel oprávněn vystavit fakturu po podpisu akceptačního protokolu oběma Smluvními stranami po dodání plnění dle příslušné Objednávky. Dodavatel je oprávněn vystavit fakturu za poskytnuté dílčí plnění, pouze pokud to stanoví příslušná Objednávka nebo tato Dohoda.
4.3. V případě Plnění A. 1 je Xxxxxxxxx oprávněn vystavit fakturu za poskytnuté dílčí plnění, a to za uplynulé kalendářní čtvrtletí, na základě dílčího akceptačního protokolu. V případě tohoto dílčího plnění je datem uskutečnění zdanitelného plnění poslední kalendářní den příslušného kalendářního čtvrtletí, to neplatí v posledním čtvrtletí, ve kterém je poskytováno plnění dle dílčí smlouvy, když datem uskutečnění zdanitelného plnění je poslední den poskytnutého plnění v daném čtvrtletí.
4.4. Splatnost faktury je 30 dnů od data jejího prokazatelného doručení Objednateli na adresu uvedenou v Dohodě, s výjimkou případu, kdy faktura doručená v termínu od 1. 12. daného roku do 31. 1. následujícího roku je splatná ve lhůtě 60 dnů od data jejího prokazatelného doručení Objednateli.
4.5. Faktura musí obsahovat číslo této Dohody a náležitosti řádného daňového dokladu podle příslušných právních předpisů, zejména pak zákona o dani z přidané hodnoty v platném znění a náležitosti obchodní listiny dle občanského zákoníku. V případě, že faktura nebude mít odpovídající náležitosti nebo nebude vystavena v souladu s touto Dohodou, je Objednatel oprávněn zaslat ji zpět k doplnění Dodavateli, aniž se dostane do prodlení se splatností, lhůta splatnosti počíná běžet znovu od opětovného doručení náležitě doplněné či opravené faktury Objednateli.
4.6. Adresa Objednatele pro doručení daňového dokladu je:
Policejní prezidium ČR, Národní centrum informačních a komunikačních technologií, Strojnická 27, poštovní schránka 62/NCIKT, 170 89 Praha 7.
4.7. Fakturovaná částka se považuje za uhrazenou okamžikem odepsání příslušné finanční částky z bankovního účtu Objednatele uvedeného v Objednávce ve prospěch bankovního účtu Dodavatele uvedeného v Objednávce.
4.8. Přílohou faktury za poskytnuté plnění je originál akceptačního protokolu podepsaného pověřenými zástupci obou Smluvních stran, jinak Objednatel nebude fakturu Dodavatele akceptovat. Akceptační protokol obsahuje přehled poskytnutého plnění, tak aby bylo možné poskytnuté plnění jednoznačně identifikovat.
4.9. Akceptační protokol musí obsahovat alespoň:
- označení čísla Dohody a Objednávky;
- předmět poskytnutého plnění včetně výrobních čísel, pokud to je aktuální;
- datum převzetí, resp. akceptace;
- identifikace osob pověřených akceptační protokol za Smluvní strany podepsat;
4.10. Objednatel je oprávněn od faktury Dodavatele odečíst své splatné pohledávky za Dodavatelem, které vzniknou v souvislosti s plněním dle této Dohody, resp. Objednávky.
4.11. Objednatel neposkytuje Dodavateli finanční zálohy na předmět plnění.
5. DOBA, MÍSTO A PODMÍNKY PLNĚNÍ
5.1. Místem plnění dle této Dohody jsou lokality Objednatele umístněné v České republice, které budou Dodavateli specifikovány v konkrétní Objednávce.
5.2. Řádně a včas dodaný Předmět plnění. Dohody je předán okamžikem akceptace, tj. podpisem závěrečného akceptačního protokolu oběma Smluvními stranami, resp. dílčího akceptačního protokolu, pokud to příslušná Objednávka nebo Dohoda stanoví. Podpisu akceptačního protokolu může předcházet akceptační řízení, tak jak je definováno v přílohách Dohody, nebo v příslušné Objednávce.
5.3. Dodavatel je povinen při předání Předmětu plnění Objednateli předat veškerou dokumentaci související s Předmětem plnění, a to zejména technickou dokumentaci, včetně detailního popisu dodaného řešení, návody na obsluhu a údržbu, záruční listy, uživatelský manuál, a to v českém jazyce, není-li v Přílohách této Dohody uvedeno jinak.
5.4. Termíny plnění budou upraveny v konkrétních Objednávkách.
5.5. Dodavatel je povinen poskytovat Plnění A. 2 a Plnění B dle této Dohody pouze prostřednictvím realizačního týmu, jejichž prostřednictvím prokázal v rámci zadávacího řízení na Veřejnou zakázku splnění kvalifikačních požadavků a jehož složení je uvedeno v Příloze č. 3 této Dohody. V případě změny člena realizačního týmu je Dodavatel povinen Objednatele o této změně předem informovat a vyžádat si předchozí písemný souhlas Objednatele, tento souhlas je oprávněna vydat příslušná osoba Objednatele uvedená v čl.
11. odst. 11.2. Dohody. Dodavatel je povinen zajistit, aby nový člen realizačního týmu splňoval minimálně stejné kvalifikační předpoklady jako nahrazovaný člen realizačního týmu, což je Dodavatel povinen Objednateli doložit odpovídajícími dokumenty, a to ve lhůtě nejméně 5 pracovních dnů před provedenou změnou. Na základě odsouhlasení změny člena realizačního týmu Objednatelem bude Smluvními stranami uzavřen písemný dodatek o této změně, a to v souladu s odst. 16.9. této Dohody.
6. ZÁRUČNÍ PODMÍNKY A ODPOVĚDNOST ZA VADY
6.1. Dodavatel zaručuje a odpovídá za to, že předané plnění:
a) odpovídá sjednané specifikaci;
b) je bez faktických vad;
c) je bez právních vad.
6.2. Dodavatel poskytuje Objednateli záruku na předmět plnění na dobu, tak jak je specifikováno v přílohách této Dohody. Zárukou přejímá Dodavatel závazek, že dodané plnění bude po tuto dobu způsobilé pro použití ke smluvenému, jinak k obvyklému účelu, a že si zachová smluvené, jinak obvyklé vlastnosti. Objednatel je povinen záruční vady oznámit Dodavateli neprodleně od jejich zjištění. Záruční doba neběží po dobu, po kterou trvá vada, za kterou odpovídá Dodavatel, a to od doby oznámení vady Objednatelem až do jejího úplného odstranění Dodavatelem. Dodavatel je povinen odstranit vadu dle podmínek specifikovaných v přílohách této Dohody.
6.3. Nebyla-li do okamžiku uplatnění reklamace vady plnění uhrazena celá smluvní cena za plnění, Objednatel není v prodlení s úhradou smluvní ceny až do úplného vyřešení reklamace.
6.4. Dodavatel odpovídá za to, že plněním této Dohody nebude zasaženo do práv třetích osob, a to včetně práv k předmětům duševního vlastnictví.
6.5. Záruka za plnění se nevztahuje na případy a situace, které potenciálně nastanou v důsledku legislativních nebo provozně-technických změn nezávislých na vůli Smluvních stran oproti podmínkám sjednaným touto Dohodou.
6.6. Dodavatel neodpovídá za vady plnění způsobené vyšší mocí, neoprávněným zásahem či opomenutím Objednatele nebo třetí osoby na straně Objednatele v rozporu s dokumentací, písemně prokazatelně předanými doporučeními výrobce nebo Dodavatele.
6.7. Plnění má vady, jestliže nebylo dodáno v souladu s touto Dohodou. Za vady se považují i
vady v návodech k použití, dokladech a dokumentech.
6.8. Objednatel uplatní požadavek na odstranění vady na helpdesk Dodavatele nebo prostřednictvím datové schránky, pokud se Smluvní strany nedomluví jinak.
6.9. Uplatněním nároku z odpovědnosti za vady není dotčen nárok Objednatele na náhradu újmy.
6.10. Veškeré činnosti související s odstraněním vady činí Dodavatel sám na své náklady (včetně nákladů na dopravu) v součinnosti s Objednatelem tak, aby svými činnostmi neohrozil nebo neomezil činnost Objednatele.
6.11. V případě opravy zařízení, které obsahuje paměťové médium, které bylo součástí předmětu plnění, tak jednotlivá paměťová média zůstávají po dobu opravy zařízení ve vlastnictví a v držbě Objednatele. V případě závady na paměťovém médiu se Dodavatel zavazuje nahradit nefunkční zařízení novým paměťovým médiem s tím, že vadné paměťové médium zůstává ve vlastnictví a v držbě Objednatele.
6.12. Další podmínky záruky a specifikace poskytování záručních oprav jsou stanoveny v přílohách této Dohody. Příloha č. 1 Dohody může definovat podmínky záruky odlišně od tohoto čl. 6 Dohody, v takovém případě má přednost ustanovení uvedené v Příloze č. 1 Dohody.
7. SANKCE
7.1. V případě prodlení Dodavatele s plněním závazků dle této Dohody a Objednávky vzniká Objednateli nárok na smluvní pokutu ve výši 0,15 % z ceny plnění s DPH dle příslušné Objednávky, a to za každý den prodlení, pokud není v přílohách této Dohody uvedeno jinak (např. sankce za nedodržení SLA).
7.2. V případě, že Xxxxxxxxx nepotvrdí Objednávku, resp. nepodá podnět k její úpravě, ve lhůtě stanovené v čl. 2 odst. 2.3 této Dohody vzniká Objednateli nárok na smluvní pokutu ve výši 1 000,- Kč, a to za každý den prodlení.
7.3. V případě porušení povinností dle článku č. 9 této Dohody je Xxxxxxxxx povinen zaplatit
Objednateli smluvní pokutu ve výši 500 000 Kč za každé porušení.
7.4. V případě porušení povinností dle článku č. 13 této Dohody je Xxxxxxxxx povinen zaplatit
smluvní pokutu ve výši 500 000,- Kč.
7.5. Pokud není v Dohodě, nebo v textu příloh, v příslušné Objednávce stanoveno jinak, Dodavatel je povinen zaplatit smluvní pokutu za každé porušení stanovených smluvních povinností ve výši 50 000,- Kč za každé jednotlivé porušení.
7.6. V případě prodlení Objednatele s úhradou řádně vystavených a doručených faktur, je Dodavatel oprávněn požadovat zákonný úrok z prodlení.
7.7. Smluvní strany se dohodly, že závazek zaplatit smluvní pokutu nevylučuje právo na náhradu újmy, a to v rozsahu, který přesahuje částku smluvní pokuty. Dodavatel odpovídá za způsobenou újmu maximálně do výše 200 000 000,- Kč (dvě stě milionů korun českých). Není-li stanoveno jinak, zaplacení jakékoliv sjednané smluvní pokuty nebo slevy z ceny nezbavuje povinnou Smluvní stranu povinnosti splnit své závazky.
7.8. Úrok z prodlení a Smluvní pokuta je splatná ve lhůtě 30 dnů od dne doručení písemné výzvy oprávněné Smluvní strany k její úhradě povinnou Smluvní stranou, není-li ve výzvě uvedena lhůta delší.
8. PODDODAVATELÉ
8.1. Dodavatel je oprávněn poskytovat plnění dle této Dohody prostřednictvím poddodavatele pouze v rozsahu, v jakém si toto právo vyhradil v rámci podání nabídky v zadávacím řízení na Veřejnou zakázku, a pouze prostřednictvím tam uvedených poddodavatelů. Ve všech ostatních případech je Dodavatel oprávněn poskytovat plnění prostřednictvím poddodavatele pouze s předchozím písemným souhlasem Objednatele.
8.2. Za plnění poddodavatelů Dodavatel odpovídá jako za své plnění, včetně odpovědnosti za důsledky vzniklé.
9. MLČENLIVOST A DŮVĚRNÉ INFORMACE
9.1. Smluvní strany se zavazují, že nezpřístupní třetí osobě důvěrné informace, okolnosti a údaje, které se dozvěděly nebo získaly v souvislosti s realizací předmětu plnění této Dohody, ani je neposkytnou jiným osobám bez předchozího výslovného souhlasu druhé Smluvní strany.
9.2. Za důvěrnou informaci se rovněž považuje obchodní tajemství ve smyslu občanského zákoníku. Pro vyloučení pochybností se za důvěrnou informací dle této Dohody považuje veškerá technická, provozní, bezpečností apod. dokumentace týkající se předmětu plnění dle této Dohody. Objednatel je rovněž oprávněn označit za důvěrnou taky informaci, dokument, zprávu, která není výslovně uvedena v tomto čl. 9 Dohody, o této skutečnosti Xxxxxxxxxx informuje.
9.3. Informace poskytnuté Dodavatelem Objednateli v souvislosti s realizaci předmětu plnění této Dohody se považují za důvěrné, pouze pokud na jejich důvěrnost Dodavatel Objednatele předem písemně upozornil a Objednatel Dodavateli písemně potvrdil svůj závazek zachovávat důvěrnost těchto informací. Pokud jsou důvěrné informace Dodavatele poskytovány v písemné podobě anebo ve formě textových souborů na elektronických nosičích dat (médiích), je Dodavatel povinen upozornit Objednatele na důvěrnost takového materiálu též jejím vyznačením alespoň na titulní stránce nebo přední straně média.
9.4. Smluvní strany se v této souvislosti zavazují poučit veškeré osoby, které se na jejich straně budou podílet na plnění této Dohody, o povinnostech mlčenlivosti a ochrany důvěrných informací a dále se zavazují vhodným způsobem zajistit dodržování těchto povinností všemi osobami podílejícími se na plnění této Dohody.
9.5. Za důvěrné informace Objednatele se dále bezpodmínečně považují veškerá data, která obsahuje informační systém Objednatele, která do něj mají být, byla nebo budou Dodavatelem, Objednatelem či třetími osobami vložena i data, která z něj byla získána. Bez ohledu na ostatní ustanovení této Dohody jsou za důvěrné informace Objednatele
považovány též zdrojové kódy systému Objednatele, jejichž poskytnutí třetí osobě by mohlo
ohrozit bezpečnost dat Objednatele v tomto systému.
9.6. Bez ohledu na výše uvedená ustanovení se za důvěrné nepovažují informace, které:
a) se staly veřejně známými, aniž by jejich zveřejněním došlo k porušení závazků Smluvní strany či právních předpisů;
b) měla přijímající Smluvní strana prokazatelně legálně k dispozici před uzavřením této Dohody, pokud takové informace nebyly předmětem jiné, dříve mezi Smluvními stranami uzavřené smlouvy o ochraně informací;
c) jsou výsledkem postupu, při kterém k nim přijímající Smluvní strana dospěje nezávisle a je to schopna doložit svými záznamy nebo důvěrnými informacemi třetí strany;
d) po podpisu této Dohody poskytne přijímající Smluvní straně třetí osoba, jež není
omezena v takovém nakládání s informacemi.
9.7. Právo užívat, poskytovat a zpřístupnit důvěrné informace mají Smluvní strany pouze v rozsahu a za podmínek nezbytných pro řádné plnění práv a povinností vyplývajících z této Dohody, a to způsobem definovaným v bezpečnostních politikách Objednatele.
9.8. Ujednání této Dohody upravující ochranu důvěrných informací se nevztahují na skutečnosti, které je nutno zveřejnit, poskytnout nebo sdělit dle platných právních předpisů včetně práva EU nebo závazného rozhodnutí oprávněného orgánu. Dodavatel výslovně souhlasí se zveřejněním celého textu Dohody, včetně všech Příloh.
9.9. Ukončení účinnosti této Dohody z jakéhokoliv důvodu se nedotkne ustanovení tohoto článku Dohody a účinnost včetně ustanovení o sankcích přetrvá bez omezení i po ukončení účinnosti této Dohody.
10. ÚČINNOST DOHODY A ODSTOUPENÍ
10.1. Rámcová dohoda se uzavírá na dobu určitou, a to na čtyři (4) roky od účinnosti Dohody, nebo do vyčerpání celkové ceny v Kč s DPH uvedené v čl. 3. odst. 3.2. této Dohody (vyčerpáním se rozumí součet jednotlivých smluvních cen uzavřených Objednávek) dle toho, která skutečnost nastane dříve. Skončení účinnosti této Dohody nemá vliv na účinnosti jednotlivých, již uzavřených Objednávek.
10.2. Ukončením účinnosti této Dohody nejsou dotčena ustanovení Dohody týkající se převodu vlastnického práva a užívacích práv, nároků z odpovědnosti za vady, nároků z odpovědnosti za újmu a nároků ze smluvních pokut, ustanovení o ochraně informací, ani další ustanovení a nároky, z jejichž povahy vyplývá, že mají trvat i po zániku účinnosti této Dohody.
10.3. Rámcovou dohodu, resp. Objednávku lze dále ukončit následujícími způsoby:
a) písemnou dohodou Smluvních stran, jejíž součástí bude i vypořádání vzájemných závazků a pohledávek;
b) písemným odstoupením jedné Smluvní strany doručeným druhé Smluvní straně
v souladu s touto Dohodou.
10.4. Každá ze smluvních stran může od této Dohody, resp. Objednávky odstoupit v případech stanovených touto Dohodou nebo zákonem, zejména pak dle ust. § 1977 a násl. a ust. §
2002 a násl. občanského zákoníku. Účinky odstoupení od Dohody, resp. Objednávky nastávají dnem doručení oznámení o odstoupení příslušné Smluvní straně.
10.5. Smluvní strany jsou oprávněné odstoupit od této Dohody, resp. Objednávky i pro nepodstatné porušení smlouvy dle příslušných ustanovení občanského zákoníku. V případě nepodstatného porušení smluvní povinnosti, může druhá Smluvní strana od Dohody odstoupit poté, co strana, která se dopustila nepodstatného porušení smluvní povinnosti, svoji povinnost nesplní ani v dodatečné přiměřené lhůtě, kterou jí druhá Smluvní strana poskytla.
10.6. Objednatel má právo odstoupit od Dohody, resp. Objednávky také tehdy, pokud:
a) bylo vydáno rozhodnutí o úpadku Dodavatele v insolvenčním řízení nebo Dodavatel sám podá dlužnický návrh na zahájení insolvenčního řízení;
b) Xxxxxxxxx vstoupí do likvidace nebo dojde k jinému byť jen faktickému podstatnému omezení rozsahu jeho činnosti, který by mohl mít negativní dopad na jeho způsobilost plnit závazky podle této Dohody;
c) Dodavatel přestane splňovat podmínky základní a profesní způsobilosti nebo technické kvalifikace stanovených v zadávacích podmínkách na realizaci této Veřejné zakázky;
d) je Dodavatel v prodlení s poskytnutím plnění o více než 30 dnů;
e) je Dodavatel v prodlení s provedením reklamace o více než 30 dnů nebo nedůvodně odmítá reklamaci provést;
f) je Dodavatel nespolehlivým plátcem dle § 106a zákona č. 235/2004 Sb., o dani z přidané
hodnoty;
g) Dodavatel nemá bankovní účet řádně registrován v databázi „Registru plátců DPH“.
11. KOMUNIKACE SMLUVNÍCH STRAN, OPRÁVNĚNÉ OSOBY
11.1. Veškerá komunikace mezi Smluvními stranami bude probíhat prostřednictvím oprávněných osob stanovených zákonem, touto Dohodou, Objednávkou nebo jimi pověřených zástupců.
11.2. Kromě zákonných zástupců Smluvních stran, další kontaktní osoby oprávněné jednat ve
věcech plnění poskytovaného dle této Dohody, včetně práva podepsat akceptační protokol:
za Dodavatele:
za Objednatele:
11.3. V případě, že dojde ke změně oprávněných osob nebo kontaktních údajů u nich uvedených, jako je e-mail, tel., apod., povinná strana doručí písemné oznámení o této změně druhé Smluvní straně bez zbytečného odkladu.
12. LICENCE
12.1. V případě, že předmětem plnění dle této Dohody je i plnění, které naplňuje znaky autorského díla dle zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících
s právem autorským a o změně některých zákonů (dále jen „autorský zákon“), Objednatel má k tomuto dílu jako celku i k jeho jednotlivým částem následující licenci:
a) Objednatel má nevýhradní, přenosné, časově a územně neomezené právo užít autorské dílo ke všem způsobům užití v neomezeném rozsahu. Objednatel má právo autorské dílo zpracovávat, upravovat či jinak měnit, a to i prostřednictvím třetích osob. Objednatel je oprávněn tuto licenci ve formě sublicence poskytnout třetí osobě, nebo ji na třetí osobu převést, a to v celém rozsahu, nebo jenom ohledně určitých práv vyplývajících z licence.
b) Účinek poskytnuté licence nastává okamžikem předání plnění dle této Dohody, do okamžiku předání je Objednatel oprávněn autorské dílo užít v rozsahu a způsobem nezbytným k provedení akceptace příslušného plnění.
c) V případě, že předmětem plnění je tzv. software vytvořený na zakázku, tedy software vytvořený pro účely plnění této Dohody, licence dle tohoto článku Dohody se vztahuje i na zdrojové kódy, včetně přípravných koncepčních materiálů k takovému software. Dodavatel je povinen při předání plnění dle této Dohody, tedy před podpisem akceptačního protokolu nebo protokolu o převzetí software vytvořeného na zakázku, předat Objednateli aktuální verzi komentovaných zdrojových kódů, včetně přípravných koncepčních materiálů v elektronické i tištěné formě, a to v takovém rozsahu a podobě, aby Objednatel sám, nebo prostřednictvím třetí osoby, mohl případně převzít další rozvoj takového software vytvořeného na zakázku. Pro vyloučení pochybností Smluvní strany uvádí, že IS KODOX a jeho rozvoj, se považuje za software vytvořený na zakázku dle tohoto článku Dohody;
d) Pro vyloučení pochybností se uvádí, že v případě, že Xxxxxxxxx je povinen dodat dokumentaci např. projektovou, analytickou, programátorskou, uživatelskou, provozní, technickou, bezpečnostní apod., tak se jedná o autorské dílo na zakázku a vztahuje se na ni licence dle tohoto článku Dohody, tj. Objednatel má kromě jiného právo takové dokumenty měnit a upravovat.
e) Udělení licence nelze ze strany Dodavatele vypovědět. Licence se poskytuje bezúplatně.
f) Je-li součástí plnění tzv. standardní software, u kterého Dodavatel nemůže udělit, nebo zajistit Objednateli licenci dle předchozích ustanovení, řídí se poskytovaná licence licenčními podmínkami dodaného softwarového produktu, ale s tím, že Objednatel má vždy nevýhradní, přenosné, časově a územně neomezené právo užít tento software v rozsahu stanoveném touto Dohodou. Objednatel je oprávněn licenci převést na třetí osobu. Pro vyloučení pochybností Smluvní strany uvádějí, že za standardní software se považuje pouze:
- softwarové produkty třetích stran, které v totožné verzi prokazatelně existovaly již před datem zahájení Výběrového řízení, nebylo a nebude do nich kvůli dodávce rozvoje IS KODOX zasahováno, přičemž se jedná pouze o produkty, které jsou dohledatelné ve veřejných cenících výrobců/prodejců a jejich prodej není limitován žádnými omezeními. Zároveň při uvažování všech myslitelných rozvojových aktivit IS KODOX (tj. při zachování účelu, k jakému byl vytvořen a zachování základní architektury systému), nesmí vzniknout potřeba zasahovat do jejich zdrojových kódů. Objednatel může odsouhlasit použití vyšších verzí vzniklých po zahájení Výběrového řízení, což nebude mít vliv na poskytnutou licencí k SW;
- softwarové produkty s GPL licencí;
- softwarové součásti dodávaného HW, které slouží pro zajištění jeho základní
- funkcionality - např. firmware;
g) Objednatel nemá povinnost licenci využít.
13. POJIŠTĚNÍ
13.1. Dodavatel je povinen být po celou dobu plnění dle této Rámcové dohody a plnění vzniklých na jejím základě, pojištěn z odpovědnosti za újmu způsobenou třetí osobě při výkonu podnikatelské činnosti se shodným předmětem plnění, jako je předmět této Dohody, a to ve výši minimální pojistné částky 20 000 000,- Kč se spoluúčastí maximálně 10% s tím, že pojistná smlouva musí zahrnovat odpovědnost Dodavatele za újmu způsobenou Objednateli nebo třetí osobě až do výše sjednané pojistné částky.
13.2. Dodavatel je povinen prokázat platnou pojistnou smlouvu, kdykoliv na požádání
Objednatele v průběhu trvání této Dohody.
13.3. Veškeré náklady související s pojištěním odpovědnosti Dodavatele za újmu dle výše uvedeného jsou nákladem Dodavatele.
13.4. Nesplnění povinnosti Dodavatele dle tohoto článku Dohody bude považováno za podstatné porušení této Dohody.
14. OBECNÁ USTANOVENÍ
14.1. Dodavatel je povinen postupovat s odbornou péčí, podle nejlepších znalostí a schopností, sledovat a chránit oprávněné zájmy Objednatele a postupovat v souladu s jeho pokyny nebo s pokyny jím pověřených osob. Dodavatel je povinen upozorňovat Objednatele v odůvodněných případech na případnou nevhodnost pokynů Objednatele.
14.2. Smluvní strany se výslovně dohodly, že Dodavatel odpovídá Objednateli za újmu majetkovou i za újmu nemajetkovou.
14.3. Dodavatel se zavazuje upozornit Objednatele na všechny okolnosti, které by mohly vést při plnění smlouvy k omezení činností nebo ohrožení chodu Objednatele, zejména pak ve vztahu k jím používaným produktům, zařízení, programovému vybavení a prostředí.
14.4. Dodavatel je povinen upozornit Objednatele na potenciální rizika vzniku škod a včas a řádně dle svých možností provést taková opatření, která riziko vzniku škod zcela vyloučí nebo (pokud je nelze zcela vyloučit) v maximální možné míře sníží. Jde-li o zamezení vzniku škod nezapříčiněných Dodavatelem, má Dodavatel právo na úhradu nezbytných a účelně vynaložených nákladů odsouhlasených předem Objednatelem.
14.5. Dodavatel je povinen upozorňovat Objednatele včas na všechny hrozící vady či výpadky svého plnění, jakož i poskytovat Objednateli veškeré informace, které jsou pro plnění Dohody nezbytné a neprodleně oznámit písemnou formou Objednateli překážky, které mu brání v plnění předmětu Dohody a výkonu dalších činností souvisejících s plněním předmětu Dohody.
14.6. Objednatel i Dodavatel se dále zavazují sdělit či poskytnout bez zbytečného odkladu druhé Straně veškeré nezbytné přístupy k věcným i technickým informacím, kterých je nezbytně zapotřebí k provedení řádného plnění ze strany Dodavatele.
14.7. Dodavatel je povinen po celou dobu plnění dle této Dohody mít v platnosti veškerá oprávnění, licence a certifikáty ke všem činnostem dle této Dohody.
14.8. Dodavatel při plnění této Dohody nebude mít přístup k reálným datům. Veškeré ladící a testovací práce musí být provedeny na testovacích datech, která Objednatel poskytne Dodavateli nebo si je Dodavatel zajistí a odsouhlasí jejich validitu pro účely testování s Objednatelem.
14.9. Dodavatel není oprávněn připojovat jakákoli vlastní zařízení nebo zprostředkovávat jakýkoli logický přístup do ICT infrastruktury Objednatele, pracující s reálnými daty. V případě stavu, kdy Objednatel a Dodavatel společně odstraňují závadu v předmětu díla nebo v datech, je možný přístup k reálným datům jen pod dohledem odpovědného pracovníka Objednatele a jen za účelem odstranění závady.
14.10. Dodavatel je povinen spolupůsobit jako osoba povinná při výkonu finanční kontroly ve smyslu § 2 písm. e) zákona č. 320/2001 Sb., o finanční kontrole ve veřejné správě a o změně některých zákonů (zákon o finanční kontrole), ve znění pozdějších předpisů, a poskytnout Objednateli i kontrolním orgánům při provádění finanční kontroly nezbytnou součinnost. Dodavatel se zavazuje zajistit, že práva výše uvedených kontrolních institucí provádět audity, kontroly a ověření se budou stejnou měrou vztahovat, a to za stejných podmínek a podle stejných pravidel na jakéhokoli poddodavatele či jakoukoli jinou stranu, která má prospěch z finančních prostředků poskytnutých v rámci Dohody.
14.11. Dodavatel se zavazuje při poskytování plnění dle Dohody, resp. Objednávky dodržovat zásady projektového řízení dle Přílohy č. 1 Dohody a dále standardy pro vývoj aplikací uvedené v Příloze č. 3 této Dohody. Jiné technologie je možné využít pouze s předchozím souhlasem Objednatele, a to v odůvodněných případech, kdy je jejich využití nezbytné a není možné využít technologie uvedené ve standardu.
14.12. Dodavatel se zavazuje po dobu platnosti této Dohody dodržovat bezpečnostní politiky Objednatele, povinnosti a součinnost plynoucí z bezpečnostního opatření uvedeného v Příloze č. 2 této Dohody. Dodavatel bere na vědomí, že je vázán i dalšími, aktualizovanými verzemi bezpečnostních politik a bezpečnostních opatření, za podmínky, že aktualizace vychází z příslušných, závazných, právních předpisů upravujících zejména kyberbezpečnost.
15. PRAVIDLA PUBLICITY A POVINNOSTI DODAVATELE
15.1. Plnění dle této Dohody může být spolufinancováno ze zdrojů Evropské unie. Pokud je v příslušné Objednávce uvedeno, že předmět plnění je spolufinancován ze zdrojů Evropské unie, je Dodavatel povinen dodržovat podmínky stanovené v tomto čl. 15 Dohody.
15.2. Dodavatel je povinen označit fakturu názvem a registračním číslem projektu, které je
uvedeno v příslušné Objednávce.
15.3. Dodavatel je povinen spolupůsobit jako osoba povinná při výkonu finanční kontroly ve smyslu § 2 písm. e) zákona č. 320/2001 Sb., o finanční kontrole ve veřejné správě a o změně některých zákonů (zákon o finanční kontrole), ve znění pozdějších předpisů, a poskytnout Objednateli i kontrolním orgánům při provádění finanční kontroly nezbytnou součinnost. Dodavatel se zavazuje zajistit, že práva kontrolních institucí provádět audity, kontroly a ověření se budou stejnou měrou vztahovat, a to za stejných podmínek a podle stejných pravidel na jakéhokoli poddodavatele či jakoukoli jinou stranu, která má prospěch z finančních prostředků poskytnutých v rámci této Dohody resp. Objednávky.
15.4. Dodavatel je povinen archivovat dokumentaci související s plněním dle této Dohody resp. Objednávky po dobu 10 let od předání plnění dle této Dohody resp. Objednávky nebo
minimálně do konce roku 2035 (pokud pravidla konkrétního dotačního titulu neuvádí lhůtu kratší; pokud je v českých právních předpisech stanovena lhůta delší, musí být použita pro úschovu delší lhůta), a to zejména originální vyhotovení Dohody a Objednávky včetně všech jejich dodatků, originály účetních dokladů a dalších dokladů vztahujících se k realizaci předmětu plnění za účelem ověřování plnění povinností vyplývajících z podmínek příslušného fondu, poskytovat požadované informace a dokumentaci zaměstnancům nebo zmocněncům pověřených orgánů (např. Odboru fondů EU v oblasti vnitřních věcí Ministerstva vnitra ČR, Ministerstvu financí ČR, Ministerstvu pro místní rozvoj ČR, Centru pro regionální rozvoj ČR, Evropské komise, Evropského účetního dvora, Nejvyššího kontrolního úřadu, příslušného finančního úřadu a dalších oprávněných orgánů státní správy) a je povinen vytvořit výše uvedeným osobám podmínky k provedení kontroly, vztahující se k realizaci veřejné zakázky a poskytnout jim při provádění kontroly součinnost. Dodavatel je povinen smluvně zajistit, aby tyto povinnosti ve vztahu k předmětu plnění plnili také poddodavatelé podílející se na této zakázce.
15.5. Dodavatel je povinen všechny písemné zprávy, písemné výstupy a prezentace opatřit povinnými prvky vizuální identity. Pravidla vizuální identity jsou uvedeny v příslušné Objednávce.
16. ZÁVĚREČNÁ USTANOVENÍ
16.1. Tato Xxxxxx nabývá účinnosti dnem uveřejnění v registru smluv dle zákona č. 340/2015 Sb., o zvláštních podmínkách účinnosti některých smluv, uveřejňování těchto smluv a o registru smluv (zákon o registru smluv).
16.2. Tato Xxxxxx nesmí být postoupena bez předchozího písemného souhlasu druhé Smluvní strany, nebo být součástí projektu přeměny dle Zákona č. 125/2008 Sb., o přeměnách obchodních společností a družstev, bez předchozího písemného souhlasu druhé Smluvní strany.
16.3. Smluvní strany nemají zájem, aby nad rámec výslovných ustanovení této Dohody byla jakákoliv práva a povinnosti dovozovány z dosavadní či budoucí praxe zavedené mezi stranami či zvyklostí zachovávaných obecně či v odvětví týkajícím se předmětu plnění dle těchto smluv, ledaže je stanoveno jinak. Vedle shora uvedeného si Smluvní strany potvrzují, že si nejsou vědomy žádných dosud mezi nimi zavedených obchodních zvyklostí či praxe.
16.4. Smluvní strany vylučují aplikaci ustanovení § 557 občanského zákoníku na tuto Dohodu.
16.5. Práva Objednatele vyplývající z této Dohody či jejího porušení se promlčují ve lhůtě 10 let ode dne, kdy právo mohlo být uplatněno poprvé.
16.6. Dodavatel přebírá podle § 1765 občanského zákoníku nebezpečí změny okolností, zejména v souvislosti s cenou za poskytnuté plnění, požadavky na poskytované plnění a licenčními podmínkami výrobce.
16.7. Ukáže-li se některé z ustanovení této Dohody zdánlivým (nicotným), posoudí se vliv této vady na ostatní ustanovení Dohody obdobně podle ust. § 576 občanského zákoníku.
16.8. Všechny spory vyplývající z právního vztahu založeného touto Dohodou a v souvislosti s ním, budou řešeny podle obecně závazných právních předpisů České republiky a soudy České republiky.
16.9. Tato Dohoda může být měněna pouze formou číslovaných písemných dodatků podepsaných oběma Smluvními stranami.
16.10. Zadávací podmínky zadané Veřejné zakázky a smluvní podmínky sjednané touto Dohodou jsou bezvýhradně závazné pro Objednávky, a to včetně technické specifikace uvedené v zadávací dokumentaci. Při uzavírání dílčích Objednávek na základě této Dohody Smluvní strany nesmí provádět podstatné změny v podmínkách stanovených v této Dohodě.
16.11. Tato Dohoda je podepsána oběma Smluvními stranami elektronickým podpisem.
16.12. Nedílnou součástí této Dohody jsou následující Přílohy: Příloha č. 1 – „Specifikace předmětu plnění“
Příloha č. 2 – „Bezpečnostní opatření pro smluvní vztahy“ Příloha č. 3 – „Požadavky na vývoj aplikací“
Příloha č. 4 – „Specifikace ceny za předmět plnění“ Příloha č. 5 – „Realizační tým“
Příloha č. 6 – „Vzor objednávky“
Příloha č. 7 – „Vzor akceptačního protokolu“
V Praze dne (dle el. podpisu) V dne (dle el. podpisu)
Objednatel: Dodavatel:
………………….. …………………..
Ministerstvo vnitra – Česká republika AUROTON COMPUTER, spol. s r.o. plk. Xxx. Xxxxxxxxx Xxxxx
ředitel NCIKT PP ČR obchodní ředitelka, jednatel
Specifikace předmětu plnění – podpora a rozvoj IS KODOX
Obsah
Společná ustanovení pro všechna plnění a detailní specifikace plnění
Slovník zkratek a pojmů 4
1 IS KODOX - kontext 6
1.1 Stručný úvod do problematiky 6
1.2 Právní základ 6
1.2.1 Nařízení Evropského parlamentu a Rady (EU) 2016/399 6
1.2.2 Nařízení Evropského parlamentu a Rady (EU) 2017/458 6
1.2.3 Nařízení Evropského parlamentu a Rady (EU) 2017/2225 6
1.2.4 Nařízení Evropského parlamentu a Rady (ES) č. 810/2009 7
1.2.5 Nařízení Evropského parlamentu a Rady (EU) č. 2019/1155 7
1.2.6 Nařízení Evropského parlamentu a Rady (ES) č. 767/2008 7
1.2.7 Nařízení Evropského parlamentu a Rady (EU) 2017/2226 7
1.2.8 Zákon č. 326/1999 Sb 7
1.2.9 Zákon č. 191/2016 Sb 7
1.2.10 Zákon č. 329/1999 Sb 7
1.2.11 Zákon č. 49/1997 Sb 7
1.2.12 Pokyn ředitele Ředitelství služby cizinecké policie č. 11/2019 7
1.2.13 Pokyn policejního prezidenta č. 120/2013 7
1.3 Cíl sledovaný uzavřením rámcové dohody 7
1.4 Popis požadovaných činností a systému KODOX 8
2 Rámcová dohoda 8
2.1 Rozsah výběrového řízení 8
2.1.1 Požadovaná plnění 8
2.1.2 Požadovaná doba trvání rámcové dohody 8
2.2 Plnění A - Technická podpora provozu IS KODOX 8
2.2.1 Plnění A.1 - Technická podpora provozu IS KODOX - fixní část 8
2.2.1.1 Služby Helpdesku 9
2.2.1.2 Služby poskytované jako součást fixní podpory 10
2.2.2 Plnění A.2 – Technická podpora provozu IS KODOX – variabilní část 11
2.2.2.1 Konzultace 11
2.2.2.2 Školení formou konzultace 11
2.2.3 Kapacity Dodavatele k realizaci Plnění A 11
2.3 Plnění B - Rozvoj IS KODOX 12
2.3.1 Závazek Dodavatele k realizaci dílčích rozvojových projektů 13
2.3.1.1 Předmět závazku 13
2.3.1.2 Předpokládaný soupis změn (navrhované projekty) 13
2.3.1.3 Předpokládaný orientační harmonogram již probíhajících projektů 14
2.3.2 Kapacity Dodavatele k realizaci Plnění B 14
2.4 Dokumentace systému (mimo projektové dokumentace) 15
2.5 Plnění C – Předání systému novému dodavateli nebo Zadavateli 15
2.5.1 Předpokládaná doba předávání systému 16
2.5.2 Součástí předání jsou nejméně tyto vstupy 16
2.5.3 Výstupy navržené Dodavatelem obsahují zejména 16
2.5.4 Akceptace Plnění C sestává zejména z 17
2.5.5 Kapacity Dodavatele k realizaci Plnění C 17
2.6 Projektové řízení 17
2.6.1 Základní dokument projektu 17
2.6.2 Certifikační požadavky na Dodavatele 18
2.7 SLA pro Plnění A. 1 18
2.7.1 SLA na garanci funkčnosti IS KODOX 18
2.7.2 On-line dotazování KODOX vůči externím systémům 19
2.7.3 SLA na doby odezev systému 19
2.7.4 SLA na Helpdesk garanci doby opravy a reakční doby 19
2.7.5 Sankce 20
2.7.5.1 Smluvní sankce za porušení doby dostupnosti 20
2.7.5.2 Smluvní sankce za porušení reakční doby a doby opravy vad systému 20
2.7.6 Definice termínů pro účely SLA 21
2.7.7 Kategorie vad 21
2.8 Akceptace 21
2.8.1 Akceptace „Plnění A.1 – Technická podpora provozu IS KODOX - fixní část“ 21
2.8.2 Akceptace „Plnění A.2 – Technická podpora provozu IS KODOX – variabilní část“ 21
2.8.3 Akceptace „Plnění B – Rozvoj IS KODOX“ 21
2.8.4 Akceptace Plnění C 22
2.8.5 Kategorie vad 23
2.8.5.1 Vada typu A 23
2.8.5.2 Vada typu B 23
2.8.5.3 Vadou typu C 23
2.8.6 Akceptace Dokumentace 23
2.9 Záruky 24
2.9.1 Záruky Plnění A.2 24
2.9.2 Záruky Plnění B 24
2.10 Další podmínky plnění 25
2.10.1 Místo výkonu prací 25
2.10.2 Mlčenlivost – NDA 25
2.10.3 Komunikační jazyk 25
2.10.4 Vývoj nových komponent 25
2.10.5 Specifikace vývojového a testovacího prostředí 25
Příloha A: Detailní specifikace služeb Plnění A 26
1 Technická podpora provozu IS KODOX - fixní část (Plnění A.1) 26
2 Technická podpora provozu IS KODOX - variabilní část (Plnění A.2) 28
Příloha B: Projektové řízení 30
1 Zásady projektového řízení 30
1.1 Projektová dokumentace 30
1.1.1 Životní cyklus projektu 31
1.1.2 Příprava 31
1.1.3 Realizace 32
1.1.4 Akceptační proces 33
1.1.5 Ukončení 33
1.1.6 Organizace projektu 33
1.1.6.1 Jednání 33
1.1.6.2 Organizační struktura projektu 33
1.1.7 Implementace metodiky PRINCE2 34
1.1.7.1 Principy 34
1.1.7.2 Témata 35
1.1.7.3 Procesy 36
Slovník zkratek a pojmů
Zkratka nebo pojem | Význam |
AFIS | Automated fingerprints identification system – systém rozpoznávání dle biometrických dat |
BCP | Business Continutity Plan - plán zajištění kontinuty provozu |
cBIS | centrální Biometrický informační systém – AFIS druhé generace |
CIS | Cizinecký informační systém, jedná se o IS PČR |
COTS | Commodity of the Shelf - v dokumentech se užívá ve smyslu programového vybavení dodávaného jako standardní komerční SW |
CS-EES | Central System – Entry-Exit System |
CS-VIS | Central System – Visa Information System |
DRP | Disaster Recovery Plan - plán obnovy provozu po havárii |
DSS | Digital Seal signer – digitální pečeť |
DWH | Data Warehouse, datový sklad |
EES | Systém vstup výstup (Entry-Exit System) |
eGATE | Zařízení pro odbavení cestujících systémem EasyGO – samoodbavení pro vybrané národnosti - Schengen |
EiO | Entry into operation – nasazení do provozu |
ETIAS | Evropský systém pro cestovní informace a povolení |
EU | Evropská unie |
eu-LISA | Evropská agentura pro provozní řízení rozsáhlých informačních systémů v prostoru svobody, bezpečnosti a práva (akronym z anglického „European Agency for the Operational Management of large-scale IT Systems in the Area of Freedom, Security and Justice“) |
ES | Evropské společenství |
EKIS | Ekonomický informační systém |
HA | High Availability, vysoká dostupnost |
ICD/DTS | Interface Control Document / Detailed Technical Specification |
ICIS | IS Interpol |
ICP | Inspektorát cizinecké policie |
ISOP | IS Opatření, jedná se o IS PČR |
IZ | Investiční záměr |
IS KODOX | Informační systém hraniční kontroly, o kterém se hovoří v této dokumentaci |
MOBLUST G2 | Mobilní lustrace druhé generace |
MS | Member state – členský stát |
MV (ČR) | Ministerstvo vnitra (České republiky) |
NDA EU | Non-disclosure Agreement – dohoda o mlčenlivosti |
NKA | Národní kontrolní autorita |
Zkratka nebo pojem | Význam |
NS-EES | Národní součást systému EES |
NS-IO | Národní součást projektu Interoperabilita |
NS-VIS | Národní Vízový informační systém |
NZVZ | Návrh na zadání veřejné zakázky |
NCIKT PP ČR | Národní centrum informačních a komunikačních technologií Policejního prezidia České republiky |
PČR | Policie České republiky |
Pre-CT | Pre Compliance tests |
PMP | The Project Management Profesional |
PSAT | Provisional System Acceptance Tests |
RD | Rámcová dohoda |
SDDC | softwarově definované datové centrum |
SIS II | Schengenský informační systém, jedná se o IS PČR |
SLA | Service Level Agreement – dohoda o úrovni poskytovaných služeb |
TDD | Test description document (v rámci kampaně Compliance testů) |
VIS | Vízový informační systém |
VKB | Vyhláška č. 82/2018 Sb., o kybernetické bezpečnosti |
VŘ | Výběrové řízení |
WS | Webová služba (web service) |
ZDP | Základní dokument projektů |
ZKB | Zákon č. 181/2014 Sb., o kybernetické bezpečnosti |
ZP | Změnový požadavek |
1 IS KODOX - kontext
1.1 Stručný úvod do problematiky
Informační systém hraniční kontroly KODOX (dále jen „IS KODOX" nebo „systém KODOX“)) představuje významný nástroj pro uplatňování ustanovení tzv. schengenského acquis, které je součástí právního rámce Evropské unie.
IS KODOX je v provozu od roku 2013 a jeho využívání má přímý vliv na zajištění bezpečnosti ČR i celé EU. IS KODOX je základním systémem při ověřování podmínek vstupu a vycestování osob, dopravních prostředků a věcí při hraniční kontrole prováděné na vnějších hranicích schengenského prostoru, inspektoráty cizinecké policie na mezinárodních letištích Ředitelství služby cizinecké policie (dále jen
„inspektorát'). S ohledem na úzkou provázanost systémů IS KODOX a systému vstupu a výstupu (EES) je IS KODOX neoddělitelnou součástí pro zajištění hraniční kontroly a požadavků stanovených evropskými legislativními akty upravujícími zřízení a provoz systému Entry-Exit (dále EES). Dostupnost systému KODOX by z uvedených důvodů měla cílit k 99,5 % (HA – High Availability).
V souvislosti s vývojem bezpečnostní situace a zajištěním vnitřní bezpečnosti EU, zejména ochranou občanů před terorismem a nelegální migrací, zefektivněním kontrol na vnějších hranicích a výměny informací mezi členskými státy, jsou připravována na úrovni EU nová nařízení k provozu informačních systémů schengenského acquis a zefektivnění výměny dat mezi členskými státy a EU prostřednictvím programu Interoperability. Povinnost postupné implementace uvedených nařízení s možnými dopady do IS KODOX budou rozložena na období let 2022-27. Tuto povinnost musí Dodavatel realizující rámcovou dohodu k zajištění provozu a rozvoje IS KODOX splnit, za předpokladu součinností Zadavatele, a to v souladu s termíny požadovanými harmonogramy EU (potažmo eu-LISA), pokud nejsou prokazatelně nesplnitelné či nereálné z objektivních důvodů, případně ze strany Dodavatele a Zadavatele není dohodnuto jinak. Povinností Dodavatele se zde myslí zejména povinnost zakázku přijmout a realizovat, pokud neexistují zásadní překážky v realizaci. Harmonogram je dojednáván u každé Objednávky individuálně.
1.2 Právní základ
Stávající právní základ provozu a využívání IS KODOX sestává z několika právních aktů EU, zákonů ČR a interních aktů řízení:
1.2.1 Nařízení Evropského parlamentu a Rady (EU) 2016/399
ze dne 9. března 2016, kterým se stanoví kodex Unie o pravidlech upravujících přeshraniční pohyb osob
(Schengenský hraniční kodex)
1.2.2 Nařízení Evropského parlamentu a Rady (EU) 2017/458
ze dne 15. března 2017, kterým se mění nařízení (EU) 2016/399 s ohledem na posílení kontrol na vnějších hranicích za použití příslušných databází
1.2.3 Nařízení Evropského parlamentu a Rady (EU) 2017/2225
ze dne 30. listopadu 2017, kterým se mění nařízení (EU) 2016/399, pokud jde o používání Systému vstupu/výstupu (EES)
1.2.4 Nařízení Evropského parlamentu a Rady (ES) č. 810/2009
ze dne 13. července 2009, o kodexu Společenství a o vízech (vízový kodex)
1.2.5 Nařízení Evropského parlamentu a Rady (EU) č. 2019/1155
ze dne 20. června 2019, kterým se mění nařízení (ES) č. 810/2009 o kodexu Společenství o vízech (vízový
kodex)
1.2.6 Nařízení Evropského parlamentu a Rady (ES) č. 767/2008
ze dne 9. července 2008, o Vízovém informačním systému (VIS) a o výměně údajů o krátkodobých vízech mezi členskými státy (nařízení o VIS)
1.2.7 Nařízení Evropského parlamentu a Rady (EU) 2017/2226
ze dne 30. listopadu 2017, kterým se zřizuje Systém vstupu/výstupu (EES) pro registraci údajů o vstupu a výstupu a údajů o odepření vstupu, pokud jde o státní příslušníky třetích zemí překračující vnější hranice členských států, kterým se stanoví podmínky přístupu do systému EES pro účely vymáhání práva a kterým se mění Úmluva k provedení Schengenské dohody a nařízení (ES) č. 767/2008 a (EU) č. 1077/2011
1.2.8 Zákon č. 326/1999 Sb.
ze dne 30. listopadu 1999, o pobytu cizinců na území České republiky a o změně některých zákonů
1.2.9 Zákon č. 191/2016 Sb.
ze dne 25. května 2016, o ochraně státních hranic České republiky a o změně souvisejících zákonů (zákon o ochraně státních hranic)
1.2.10 Zákon č. 329/1999 Sb.
ze dne 30. listopadu 1999, o cestovních dokladech
1.2.11 Zákon č. 49/1997 Sb.
ze dne 6. března 1999, o civilním letectví
1.2.12 Pokyn ředitele Ředitelství služby cizinecké policie č. 11/2019
ze dne 26. února 2019, o hraniční kontrole a zajišťování ochrany civilního letectví na mezinárodních letištích
1.2.13 Pokyn policejního prezidenta č. 120/2013
ze dne 11. června 2013, o informačním systému hraniční kontroly KODOX
1.3 Cíl sledovaný uzavřením rámcové dohody
Funkční, v souladu s právním základem provozovaný IS KODOX zajišťující plnohodnotnou podporu práce policistů ČR a návazně spolupracujících zemí schengenské spolupráce podle níže definovaných SLA a požadavků
1.4 Popis požadovaných činností a systému KODOX
Tento dokument popisuje IS KODOX obecně a popisuje požadovaný rozsah činností pro jednotlivá plnění. Detailní popis funkčnosti systému obdrží Účastník zadávacího řízení na základě podpisu Smlouvy o mlčenlivosti.
Detailní dokumentace k systému (analytická dokumentace, provozní dokumentace, popisy rozhraní, aj.) je k dispozici u Zadavatele k nahlédnutí na základě podpisu Smlouvy o mlčenlivosti a NDA EU (z důvodu vazeb na systémy VIS a EES).
2 Rámcová dohoda
2.1 Rozsah výběrového řízení
2.1.1 Požadovaná plnění
Část | Předmět |
Plnění A (tj. A1 až A.2) | Technická podpora provozu IS KODOX |
Plnění B | Rozvoj IS KODOX |
Plnění C | Předání systému novému dodavateli nebo Zadavateli |
2.1.2 Požadovaná doba trvání rámcové dohody
Požadovaná doba trvání rámcové dohody je 4 roky.
2.2 Plnění A - Technická podpora provozu IS KODOX
2.2.1 Plnění A.1 - Technická podpora provozu IS KODOX - fixní část
Korektivní, preventivní a adaptivní služby představují pravidelné činnosti, jejichž cílem je co největší prevence výskytu případného nestandardního stavu, respektive incidentu, který by vyústil v nefunkčnost systému nebo omezení služeb, které jsou součástí systému KODOX poskytovány rezortním a mezirezortním systémům a uživatelům. V případě výpadku pak uvedení systému do provozního stavu v souladu s parametry kapitoly č. 2.7 definovanými níže.
Nedílnou součástí podpory je zajištění Helpdesku formou webové aplikace (a min. jeden další náhradní způsob), ve kterém bude hlášení chyb, nestandartních stavů a komunikace mezi Dodavatelem a Zadavatelem zajištěna.
Součástí podpory je dále udržování všech prostředí IS KODOX (produkčního, testovacího a školního prostředí) v aktualizovaném stavu.
Plnění A.1 zahrnuje udržování vývojového prostředí IS KODOX (dále též „Plnění TP1a). Pokud vývoj neprobíhá přímo na vývojovém prostředí Zadavatele, zajistí Dodavatel aktualizaci vývojového prostředí u Zadavatele vždy s ukončením Objednávky, která v něm vyvolala změnu. Technickou podporou vývojového prostředí se rozumí náklady na údržbu HW infrastruktury a podporu SW licencí. Tato položka je naceněna zvlášť (samostatná položka TP1a) a bude objednávána, dokud bude mít Dodavatel vývojové prostředí plně ve své režii. V případě, že bude plnohodnotné vývojové prostředí vytvořeno v prostorách Zadavatele na
jeho infrastruktuře a budou mu přiděleny prostory, kde bude moci Dodavatel vyvíjet, nebude tato položka objednávána a v souvislosti s tím si Objednatel vyhrazuje právo vyjmout tuto část plnění (tj. Plnění TP1a) z Plnění A.1 kdykoliv v průběhu trvání rámcové dohody.
„Plnění A.1 (Technická podpora provozu IS KODOX - fixní část) je objednáváno vždy na celý rok (tj. 12 kalendářních měsíců) nebo jeho celé násobky a hradí se paušální platbou.
Položky, které jsou součástí korektivních, preventivních a adaptivních služeb jsou detailně rozepsány
v Příloze A tohoto dokumentu.
2.2.1.1 Služby Helpdesku
Služby reaktivní podpory představují stálou připravenost pracovníků Dodavatele pro řešení nestandardních stavů (viz též korektivní podpora), které nebylo možné odhalit v rámci proaktivních služeb. Dodavatel v návaznosti na proaktivní služby bude aktualizovat znalostní bázi tak, aby bylo možno na nahlášenou závadu operativně reagovat a odstranit ji v co nejkratším časovém úseku.
Dodavatel zajistí pro potřeby Zadavatele pro poskytování všech služeb z rámcové dohody a Objednávek či dalších požadavků po dobu trvání smluvního vztahu po celou dobu účinnosti rámcové dohody i po celou dobu záruky plnění zakoupených z rámcové dohody Helpdesk podle níže definovaných parametrů nebude-li dohodnuto jinak, tak aby byl splněn požadavek na možnost nahlášení závady.
Helpdesk má primárně podobu webové aplikace zřízené a provozované Dodavatelem a slouží jako jednotné kontaktní místo. Dodavatel zřídí určeným pracovníkům Zadavatele vzdálený přístup k Helpdesku. Kromě vzdáleného přístupu zajistí Dodavatel minimálně další 2 alternativní způsoby komunikace s Helpdeskem. Dodavatel zpracuje dokument k používání a vnitřnímu členění Helpdesku. Služba Helpdesk bude sloužit jak pro zaznamenávání případných závad a problémů, tak dotazů zodpovědných osob jmenovaných Zadavatelem.
Základní funkce/parametry této služby jsou:
• Příjem a řízení životního cyklu všech incidentů, vad, problémů a požadavků,
• Prvotní analýza incidentů, nahlášených vad, problémů a požadavků, přidělení k řešení a stanovení návrhu řešení (analytická podpora řešení problémů zadaných do Helpdesku).
• Řešení incidentů, problémů a požadavků a vad dle smluvních závazků (podpora, záruční oprava, pozáruční oprava, nutnost úpravy systému atd.).
• Monitoring a reportování stavů incidentů, vad, problémů a požadavků a plnění parametrů dle SLA.
• Dokumentace incidentů, vad, problémů, příčin vzniku a jejich řešení.
• Reakce na dotazy oprávněných uživatelů Zadavatele.
• Komunikace v českém jazyce.
• Dostupnost služby Helpdesk v režimu 24x7x365.
• Reakční doba pro započetí řešení nahlášeného požadavku dle specifikace SLA a definice kategorií
vad viz kapitoly 2.7.1 a 2.8.5.
• Definice chyb a požadavky na jejich odstranění – viz část SLA tohoto dokumentu.
Servisní záznam (Ticket) – nahlášení události typu incident/problém nebo požadavek sjednaným způsobem. Události jsou nahlašovány prostřednictvím Helpdesku. Servisní záznam může být registrován pouze prostřednictvím k tomu stanovených kontaktů a postupů. Servisní záznam musí být oprávněným zástupcem Zadavatele klasifikován z hlediska závažnosti. O řešení, odmítnutí, uzavření či jiných změnách
stavu a závažnosti servisního záznamu bude vždy informován oprávněný zástupce, kdy jednotlivá stádia, zejména pak odmítnutí a uzavření servisního záznamu, musí být oprávněným zástupcem Zadavatele odsouhlasena.
Priorita (Severita) – klasifikace naléhavosti incidentu/problému nebo požadavku, která je odvozena od úrovně nefunkčnosti nebo nedostupnosti systému. Klasifikace priorit bude rozdělena dle závažnosti v následujících úrovních (nízká, normální, vysoká a kritická).
Dodavatel vyhotoví a předá Zadavateli 1x měsíčně strukturovaný souhrnný report o stavu všech otevřených nebo v daném měsíci uzavřených incidentů, problémů a požadavků, z něhož budou zřejmé minimálně následující údaje:
• Klasifikace předmětu incidentu, problému nebo požadavku,
• jejich stav,
• čas nahlášení, registrace a autorizace,
• reakční doba dodavatele,
• doba řešení dodavatelem,
• čas a způsob uzavření a autorizace,
• doba a důvod nedostupnosti systému nebo jeho části (HW),
• doba a důvod nedostupnosti služby Helpdesk.
Dodavatel je dále Zadavateli povinen na vyžádání poskytnout ve lhůtě do 10 dnů veškerá data shromážděná v souvislosti s poskytováním shora uvedených služeb ve strojově zpracovatelné podobě (např. *.xml, *.csv apod.).
Zadavatel a Dodavatel vytvoří komunikační matici, která bude obsahovat všechny relevantní kontaktní osoby pro komunikaci mezi stranami včetně eskalačních mechanismů (viz vytvoření Základního dokumentu projektu kapitola Projektové řízení).
Doba vyřešení servisního případu se řídí specifikací uvedenou v popisu konkrétního objednaného plnění.
2.2.1.2 Služby poskytované jako součást fixní podpory
• Poskytování podpory takovým způsobem, který vyloučí přístup pracovníků Dodavatele k datům IS Policie ČR (zamezení přístupu k datům produkční databáze obsahující osobní údaje a přístup k datům lustračních databází PČR v případě, že jsou replikovány).
• Vytvoření a udržování plánu zajištění poskytované podpory v požadované kvalitě a testování systému.
• Údržba bezpečnostního managementu, vytvoření a udržování plánu udržitelnosti podpory a provozu (součástí je Business recovery a Business Continuity process).
• Obnova provozu systému po výpadcích.
• Předběžná analýza a předběžné oceňování prací objednávaných z Plnění A.2 a Plnění B.
• Ostatní nevyjmenované práce nutné pro garantování funkčnosti systému.
2.2.2 Plnění A.2 – Technická podpora provozu IS KODOX – variabilní část
Plnění A. 2 bude čerpáno na základě Objednávek obsahujících konkrétní specifikaci činností, předpokládaný počet MD a jejichž přílohou bude soupis objednávaných rolí. Z důvodu plynulé návaznosti aktivit se různé Objednávky na Plnění A. 2 mohou poskytováním plnění časově překrývat.
Služby jsou poskytovány provedením objednaných prací, na základě konkrétních plnění Zadavatele a dle jeho aktuálních potřeb. Služba A.2 je účtována na základě schváleného výkazu poskytnutých prací, nejmenší účtovací jednotkou je započatá ½ člověkohodiny.
Položky, které jsou součástí tohoto plnění, jsou detailně rozepsány v Příloze A tohoto dokumentu. Povinnou součástí Plnění A.2, které je Dodavatel povinen na vyžádání poskytnout, je následující:
2.2.2.1 Konzultace
Na základě požadavku Zadavatele může být Dodavatel požádán o poskytnutí asistence/konzultace Zadavateli, uživatelům nebo jiným subjektům ohledně služby či procesu IS KODOX:
• Business analýzy – analýzy procesů
• Analýzy dopadů změn okolí systému nebo systému
• Dohled nad pracemi prováděnými třetími stranami, které mají nebo mohou mít přímý nebo nepřímý dopad na provoz IS KODOX
• Příprava technických zpráv a implementačních postupů v technické oblasti
• Detailní technické poradenství nebo vysvětlení
• Pomoc zadavateli při diagnostice problémů
• Instalace a konfigurace software
2.2.2.2 Školení formou konzultace
Tato aktivita je určena k provedení školení formou konzultace nad rámec školení realizovaného v rámci rozvojových aktivit za účelem přenést potřebné vědomosti ohledně fungování, změn fungování, evoluce IS KODOX na správce systému či jiné relevantní subjekty (administrátory/školitele/třetí subjekty).
2.2.3 Kapacity Dodavatele k realizaci Plnění A
Dodavatel musí zajistit dostatečný počet lidských zdrojů pro realizaci všech požadavků a služeb v rámci Plnění A. Dodavatel dále musí zajistit, že jeho personální kapacity budou mít nezbytné znalosti a zkušenosti pro provedení všech požadovaných úprav. Také musí zabezpečit, že veškeré projekty budou realizovány v požadované kvalitě a čase.
2.3 Plnění B - Rozvoj IS KODOX
Cílem této části plnění je zajistit další rozvoj (evoluci) systému, který bude požadován tak, jak jsou vydávány regulace a nařízení Evropské komise k IS se kterými systém KODOX napřímo komunikuje a se kterými musí i nadále zajistit soulad ve výměně dat. IS KODOX je neustále se rozvíjející systém a je nutné zajistit soulad požadavků na výkonnost (především z pohledu zajištění zdroje dat pro EES) a funkcionality systému s legislativou a přijatými standardy.
Předmětem Plnění B jsou služby rozvoje, při kterých typicky dochází k zásahu do zdrojových kódů, buildu aplikace a jejího následného nasazení.
Pokud není dohodnuto jinak, je součástí Plnění B vždy:
• aktualizace analytické dokumentace;
• aktualizace (je-li již realizováno) vývojového prostředí – aktualizované vývojové prostředí bude předáno Zadavateli s ukončením Objednávky, která v něm vyvolala změnu;
• podpora při testování Zadavatele;
• nasazení nových verzí postupně na jednotlivá provozovaná prostředí (vývojové, testovací, produkční);
• otestování zdrojových kódů na výskyt škodlivých/potenciálně škodlivých částí kódu
• Uložení zdrojových kódů na repozitory Zadavatele a řízený deployment.
Plnění B je objednáváno uzavřením Objednávky. Každá smlouva musí obsahovat akceptační kritéria. Pokud je předmětem smlouvy programové dílo, musí být v rámci plnění navrženy testovací scénáře a podle nich provedeny testy ověřující funkcionalitu díla. Dílo je akceptováno oprávněným pracovníkem Zadavatele (manažerem projektu).
Dodavatel má povinnost realizovat všechny oprávněné požadavky Zadavatele na rozvoj systému, tj. požadavky, které jsou v souladu s účelem systému anebo které vyplývají z požadavků EU.
Jednotlivé Objednávky budou uzavírány na předpokládaný maximální rozsah prací odhadnutý Dodavatelem ve spolupráci se Zadavatelem na základě popisu Zadavatelem požadované funkcionality a tomu odpovídající cena dle RD. Fakturovány budou pouze skutečně vykonané činnosti.
Pokud nedojde mezi Dodavatelem a Zadavatelem ke shodě nad maximálním rozsahem prací, které jsou nutné pro provedení objednaného díla, je Zadavatel oprávněn požadovat po dodavateli, aby veškeré práce provedl v prostorách Zadavatele na vývojovém prostředí Zadavatele (resp. své vlastní technice) pod jeho dohledem, pokud budou na straně Zadavatele zajištěny adekvátní podmínky nezbytné pro práci v prostorách Zadavatele.
Na základě požadavku Zadavatele musí být všechny vývojové práce provedeny na vývojovém prostředí Zadavatele, pokud bude takové prostředí Zadavatelem poptáno a ve spolupráci s Dodavatelem realizováno. Pokud vývoj neprobíhá přímo na vývojovém prostředí Zadavatele, zajistí Dodavatel aktualizaci vývojového prostředí u Zadavatele vždy s ukončením vývojových prací Plnění B, která v něm vyvolala změnu.
S ukončením Objednávky Plnění B bude Zadavateli předána pokaždé aktuální verze vývojového prostředí a budou uloženy zdrojové kódy na repozitory Zadavatele k zachování integrity provedených změn.
2.3.1 Závazek Dodavatele k realizaci dílčích rozvojových projektů
2.3.1.1 Předmět závazku
V kapitole 1.2 Právní základ jsou uvedeny legislativní akty, které přímo ovlivňují provoz a vývoj systému. Tyto právní akty a jejich následné změny mohou vyvolat řadu zásadních změn, které mají přímý dopad na funkčnost a provoz IS KODOX.
Mezi tyto projekty řadíme projekty uvedené v kapitole 2.3.1.2. Připravenost členských zemí na včasnou implementaci změn ICD a DTS/ či komponenty NS-IO projektu Interoperability, změn rozhraní na centrální systémy CS-VIS a CS-EES a následné rozsáhlé testování je praktickou (bezpečnostní) i politickou prioritou. Účastník a budoucí Dodavatel se tedy ve své nabídce musí explicitně zavázat, že zajistí v součinnosti se Zadavatelem včasnou implementaci všech schválených změn dle harmonogramu uvedeného v kapitole Orientační harmonogram, pokud nenastanou z důvodů mimo dosah Dodavatele (prodlení orgánů EU, neposkytnutí součinnosti ze strany orgánů EU nebo ze strany Zadavatele). Dodavatel pro každý projekt v rámci nabídky na Objednávku k Plnění B předloží harmonogram s uvedením času potřebného k realizaci předmětu plnění (tj. změny systému), navržený harmonogram musí být realizovatelný v termínech odsouhlasených Dodavatelem i Zadavatelem za předpokladu, že dojde k podpisu Objednávky na příslušný rozvojový projekt do 6 týdnů od předložení nabídek veřejné zakázky na RD.
2.3.1.2 Předpokládaný soupis změn (navrhované projekty)
Do prací, které je možno objednat na základě Plnění B jsou činnosti související se změnou či rozšířením zdrojového kódu, vývoj funkcionalit a úprava systému nebo jeho částí. Mezi plánované projekty v době platnosti rámcové dohody je nutné realizovat:
• Kontinuální řešení změnových požadavků a jejich implementace po spuštění projektu EES (spuštění EES je předpokládáno k 05/2023)
• Připojení IS KODOX k NS-IO
Mezi plánované projekty v době platnosti je možné realizovat:
• Vybudování rozhraní a úpravy IS KODOX se spuštěním IS ETIAS
• Vybudování rozhraní a úpravy IS KODOX s AFIS/cBIS (úpravy systému a rozhraní, které umožní oboustranné odesílání WS včetně biometrických dat do cBIS)
• Projekt skartace a archivace dat
• Kybernetická bezpečnost I - projekt pro vytvoření bezpečnostní dokumentace k systému
o Očekávané výstupy: struktura a rozsah bezpečnostní dokumentace bude odpovídat požadavkům VKB, zavedenému systému řízení bezpečnostní MV a dalším relevantním předpisům.
• Kybernetická bezpečnost II - projekt pro implementaci bezpečnostních opatření (technických), které budou navrženy v plánu zvládání rizik, který bude zpracován v rámci Kybernetické bezpečnosti I.
Nejedná se o konečný soupis plánovaných projektů.
2.3.1.3 Předpokládaný orientační harmonogram již probíhajících projektů
Uvedený předpokládaný harmonogram realizace projektů je orientační a Zadavatel si vyhrazuje právo na možné úpravy harmonogramu dle realizace projektů na národní úrovni případně na základě součinnosti s projekty centrálních součástí informačních systémů spravovaných agenturou euLISA.
Projekt VIS-EES IO:
Task Name | Doba trvání | Zahájení | Dokončení |
Změny IS KODOX reflektující VIS-EES-IO - Implementace (včetně testů) | 607 dní | 01.08.20 | 30.3.22 |
Participace, zajištění součinnosti s testováním s orgány euLISA (VIS-EES-IO - Pre-CT) | 61 dní | 01.09.22 | 31.10.22 |
Participace, zajištění součinnosti s testováním s orgány euLISA (VIS-EES-IO – CT) | 46 dní | 01.11.22 | 16.12.22 |
Participace, zajištění součinnosti s testováním s orgány euLISA (EES-IO – PSAT) – volitelné | 23 dní | 09.01.23 | 31.01.23 |
End-to-end testy (business testování) s orgány PČR | 88 dní | 31.01.23 | 28.04.23 |
Nasazení změn IS KODOX se spuštěním projektu IO do provozu (EES-IO - MS EiO) | 1 dní | 01.05. 23 | 01.05.23 |
Projekt NS-IO:
Task Name | Doba trvání | Zahájení | Dokončení |
Změny IS KODOX reflektující EES-IO - Implementace (včetně testů) | 943 dní | 31.01. 22 | 30.08. 24 |
Participace, zajištění součinnosti s testováním s orgány euLISA (EES-IO - Pre-CT) | 760 dní | 31.10. 22 | 28.11. 24 |
Participace, zajištění součinnosti s testováním s orgány euLISA (EES-IO – CT) | 730 dní | 01.11. 22 | 30.10. 24 |
Participace, zajištění součinnosti s testováním s orgány euLISA (EES-IO – PSAT) – volitelné | 655 dní | 16.01. 23 | 31.10. 24 |
End-to-end testy (business testování) s orgány PČR | 640 dní | 16.03. 23 | 15.12. 24 |
Nasazení změn IS KODOX se spuštěním projektu IO do provozu (EES-IO - MS EiO) | 594 dní | 01.05. 23 | 15.12. 24 |
2.3.2 Kapacity Dodavatele k realizaci Plnění B
Dodavatel musí zajistit dostatečný počet lidských zdrojů pro realizaci všech projektů požadovaných objednatelem. Dodavatel dále musí zajistit, že jeho personální kapacity budou mít nezbytné znalosti a zkušenosti pro provedení všech požadovaných úprav. Také musí zabezpečit, že veškeré projekty budou realizovány v požadované kvalitě a čase.
2.4 Dokumentace systému (mimo projektové dokumentace)
Součástí systému musí být komplexní soubor dokumentace (v případě, že dokumentace nyní neexistuje, bude objednána v rámci Plnění A.2 či Plnění B), obsahující minimálně:
• Analytická dokumentace k IS KODOX;
• Provozní dokumentace IS KODOX – včetně architektury řešení, detailní analýzy všech procesů a funkcí systému;
• Instalační a konfigurační dokumentace;
• Návody k odstraňování známých problémů hlášených zainteresovanými subjekty IS KODOX (chybové stavy – již řešené, zadané Zadavatelem či odhalené dodavatelem, problémy s provozem či nastavením/konfigurací, které Dodavatel při své práci odhalil)
• Školící dokumentace;
• Uživatelská dokumentace;
• Testovací dokumentace a scénáře;
• Analýza a Registr rizik;
• Bezpečnostní dokumentaci včetně plánu Business Continuity a Disaster Recovery.
2.5 Plnění C – Předání systému novému dodavateli nebo Zadavateli (handover při ukončování RD)
Předmětem Plnění C je poskytnutí služby předání systému při ukončení rámcové dohody novému, resp. nastupujícímu dodavateli nebo Zadavateli. Plnění C je objednáváno samostatnou Objednávkou.
Cílem předání je převod podpory a schopnosti rozvoje systému na jiný subjekt bez degradace kvality poskytovaných služeb. Předáním systému je myšleno předání všech služeb podpory a rozvoje Zadavateli nebo třetí straně před koncem účinnosti rámcové dohody nebo při vynuceném konci rámcové dohody, a to v souladu s pokyny Zadavatele.
Aktivita zahrnuje zejména plán průběhu předání, s detailním soupisem všech nutných činností včetně parametrů umožňujících posoudit jejich korektní předání. Bude použit jako soupis, podle kterého bude ověřeno, zda aktivita korektně proběhla, a jen v případě úspěšného předání bude akceptováno, pokud Zadavatel nerozhodne jinak na základě známých skutečností. Plán bude předložen do 3 týdnů od objednání aktivity – účinnosti Objednávky, podléhá samostatné akceptaci.
Samotné předání všech potřebných dokumentů viz 2.5.2 a zaškolení přebírajícího subjektu (může podléhat samostatné akceptaci) je první fází projektu trvající nejvýše 3 měsíce.
Druhou fází projektu je 3 měsíční „stínování“ – tedy vykonávání činností spolu s přebírajícím včetně vykonání „Testovacích scénářů pro ověření reálných schopností nového Dodavatele adekvátně reagovat na události systému různé závažnosti“ dodaných v rámci první fáze plnění – tedy vykonávání činností spolu s přebírajícím, kdy aktivita je na straně přebírajícího a Dodavatel vykonává kontrolní a konzultační činnost (podléhá samostatné akceptaci). Celá aktivita je zakončena „Zprávou o předání systému“, ve které je přesně popsáno, jaké služby byly předány a jak, a případné upozornění na nedostatky.
2.5.1 Předpokládaná doba předávání systému
Požadovaná doba předávání systému je maximálně 6 měsíců od účinnosti Objednávky.
2.5.2 Součástí předání jsou nejméně tyto vstupy
• Relevantní procesy a procedury
• Seznam klíčových partnerů a jejich kontakty
• Architektonická dokumentace
• Instalační a konfigurační dokumentace
• Provozní, uživatelské a administrátorské manuály včetně soupisu stavů monitoringu, které mají
vyvolat akci podpory
• Návod k odstraňování problémů (chybové stavy, typické problémy, na které Dodavatel při své práci narazil)
• Nevyřešené problémy, které v systému přetrvávají, jsou-li
• Analytická dokumentace
• Provozní dokumentace
• Školící dokumentace
• Testovací dokumentace a scénáře
• Program/projekt „lessons learned“ – dokumentace zkušeností nabytých při řízení
programu/projektu
• Soupis rizik a registrovaných problémů
• Plán Business Continuity a Disaster Recovery
• Testovací scénáře pro ověření reálných schopností nového dodavatele adekvátně reagovat na události systému různé závažnosti
2.5.3 Výstupy navržené Dodavatelem obsahují zejména
• Plán předání (fáze 1)
• Plán/soupis akceptačních podmínek předání (jednotlivé služby, procesy, dokumentace atd.) (fáze 1)
• Zpráva o předání systému (fáze 2)
• Proškolení třetí strany (fáze 1)
• Zpráva o provedených proškoleních (fáze 1)
• Koučink a stínování (fáze 2)
• Zpráva o provedeném koučinku a stínování (fáze 2)
• Všechna živá a historická data a informace podporující předávané služby (fáze 1)
• Všechny podpůrné nástroje vytvořené Dodavatelem po dobu trvání smluvního vztahu za účelem kvalitního výkonu služeb, pokud byl jejich vývoj Zadavatelem schválen a proběhlo předání Zadavateli ať již za úplatu nebo v rámci Plnění A. (všechna práva jsou Zadavatele) (fáze 1)
• Formální předání práv na využívání všech licencovaných produktů třetích stran (fáze 1)
• Soupis nevyřešených problémů a rozpracovaných aktivit (fáze 1)
• Checklist předání provozu. (fáze 1)
2.5.4 Akceptace Plnění C sestává zejména z
• První fáze – ověření připravenosti všech výstupů předání fáze 1 a jasného postupu směřujícímu
k úspěšnému předání – viz 2.5.
• Druhá fáze – ověření reálných schopností nového Dodavatele adekvátně reagovat na události systému různé závažnosti. Ověření proběhne úspěšným splněním testovacích scénářů (z bodu 2.5.2) nebo prokázáním, že Dodavatel provedl nezbytné předání dokumentace, zaškolení, Hands on cvičení, která zadávala odůvodněný předpoklad, aby nový Dodavatel mohl uvedené splnit, a dále dodáním zbývajících výstupů z bodu 2.5.3.
.
Cena druhé fáze musí být min 30% Plnění C. Bez akceptace obou fází, nebude plnění uznatelné a proplacené. Na Plnění C se vztahuje proces akceptace, viz kapitola 2.8 Akceptace.
2.5.5 Kapacity Dodavatele k realizaci Plnění C
Dodavatel musí zajistit dostatečný počet lidských zdrojů pro realizaci předání (handoveru) IS KODOX jinému dodavateli nebo Zadavateli. Dodavatel dále musí zajistit, že jeho personální kapacity budou mít nezbytné znalosti a zkušenosti pro provedení požadovaného. Také musí zabezpečit, že předání bude realizováno v požadované kvalitě a čase.
2.6 Projektové řízení
Aktivity, jež jsou součástí rámcové dohody o technické podpoře a rozvoji IS KODOX (dále též „RD KODOX“) jsou natolik rozsáhlé, různorodé, komplexní a časově i technologicky náročné, že pro jejich úspěšnou realizaci a koordinaci je nutné tyto aktivity řídit projektově, tj. s použitím metod projektového řízení.
Pojmem „projekt“ Zadavatel rozumí jedinečnou sadu činností, procesů, nástrojů a lidí, jejichž cílem je vytvořit předem definovaný produkt (resp. výstup, předmět plnění). Projekt je ohraničen časem (má daný začátek a konec), náklady a kvalitativními požadavky. V kontextu RD KODOX je pro každý projekt zapotřebí uzavřít samostatnou Objednávku, s čímž je spojeno vytvoření rozsáhlé dokumentace a řada administrativních procesů, jež mají dopad na Zadavatele i Dodavatele a jež na řízení projektů kladou specifické nároky (popsané níže). Vzhledem k tomu, že jednotlivé projekty mohou probíhat paralelně a jsou mezi sebou provázané (a kromě projektů je navíc nutné řídit i služby technické podpory), je zapotřebí je navzájem koordinovat jako jeden celek, tj. „program“. Pro označení všech činností souvisejících s údržbou a rozvojem KODOX je proto užíván pojem „Program KODOX“.
2.6.1 Základní dokument projektu
Do 30 pracovních dnů od účinnosti rámcové dohody Dodavatel vytvoří draft Základního dokumentu projektů (dále též „ZDP“), který bude popisovat zásady řízení projektů (tj. veškeré projektové procesy, dokumenty, role, odpovědnosti, rizika ad.) – tyto zásady budou závazné pro celý Program KODOX, a to jak pro Dodavatele, tak pro Zadavatele. Draft ZDP Zadavatel zašle s připomínkami do 10 pracovních dnů od jeho doručení, Dodavatel tyto připomínky zapracuje ve lhůtě 10 dnů od jejich přijetí a zašle ZDP Zadavateli ke druhému čtení. Zadavatel ZDP připomínkuje ve lhůtě 10 dní. Pokud v rámci druhého čtení žádné připomínky nevzniknou, je dokument akceptován. Pokud připomínky vzniknou, budou vypořádány osobně mezi Zadavatelem a Dodavatelem na jednání k tomu svolanému. Vypořádáním připomínek je dokument akceptován.
Za účelem vyjasnění zadání při vytváření (resp. vypořádávání připomínek) ZDP mohou být svolána jednání mezi Zadavatelem a Dodavatelem, která se budou konat v prostorách Zadavatele. Vyplyne-li to z okolností jako nejúčelnější varianta, může vybrané kapitoly ZDP po vzájemné dohodě vytvořit Zadavatel.
Gestorem ZDP bude Dodavatel. Pojmem „gestor“ je míněn v projektovém smyslu (resp. ve smyslu řízení dokumentů), vlastník1 dokumentu. Zde však tento termín není použit z důvodu hrozící záměny pojmu vlastník s termíny smluvními. Tj. gestorem je označován subjekt, který je za dokument odpovědný (z věcného i formálního hlediska včetně pravopisu) v celém životním cyklu – vytváří jeho první verzi, zajišťuje jeho distribuci určeným osobám k připomínkám, vypořádává obdržené připomínky, zasílá zpět finální verzi dokumentu. Dodavatel bude ZDP pravidelně aktualizovat (dle potřeby, nejméně však 1× ročně).
ZDP musí pokrývat všechny relevantní principy, témata a procesy metodiky PRINCE2 a musí respektovat projektové zásady Zadavatele, které z metodiky PRINCE2 vycházejí a které jsou popsány níže. Tyto principy mohou být upřesněny v jednáních k tomu svolaných (viz výše). Dodavatel má povinnost sladit své procesy se zásadami uvedenými v odsouhlaseném ZDP.
2.6.2 Certifikační požadavky na Dodavatele
Projekty jsou řízeny na základě metodiky PRINCE2, která byla přizpůsobena potřebám Zadavatele. Projektový tým Dodavatele musí být s metodikou PRINCE2 dobře obeznámen. Projektový manažer Dodavatele musí být držitelem certifikace PRINCE2 (alespoň na úrovni Practitioner), příp. držitelem certifikace jiné světově uznávané metodiky obdobného stupně, např. PMP.
2.7 SLA pro Plnění A. 1
2.7.1 SLA na garanci funkčnosti IS KODOX
Součástí služeb je garance funkčnosti se spolehlivostí provozu systému dle níže definovaných SLA na vybrané služby a garance doby opravy – tedy služby nutné pro zajištění funkčnosti všech aplikací a modulů rozhraní na externí systémy.
Dodavatel je zavázán dodržením níže uvedených SLA za části systému, na které spadají do Plnění A. 1 nebo která byla poptána jinou Objednávkou na rozvoj systému, pokud nebylo v Objednávce uvedeno jinak.
Dodavatel neodpovídá za porušení SLA způsobené systémy mimo jeho správu (HW, síťová infrastruktura, systém Active Directory, systém EKIS, apod.). Dodavatel rovněž neručí za porušení SLA způsobené nečinností Zadavatele, který byl dle smluvních podmínek Dodavatelem upozorněn nebo vyplývá z nastavených procesů.
Pro systém KODOX je stanoveno obecné SLA 99,5 %, níže definované služby mají vyšší SLA. Obecné SLA je měřeno vždy za 3 (tři) po sobě jdoucí měsíce (čtvrtletí). Vyhodnocováno je do jednoho měsíce po skončení daného 3měsíčního období. Měření SLA je zajištěno pomocí produktu Zadavatele, který je již využíván pro další IS PČR – Zabbix. Uvedený produkt je již využíván a spravován Provozním gestorem systému- NCIKT PP ČR. Dodavatel ve spolupráci s Provozním gestorem připojí služby systému KODOX k PČR Zabbix k zajištění měření a vyhodnocení dostupnosti systému za uvedené období.
1 Z hlediska majetkoprávního je vlastníkem (majitelem) vytvořené dokumentace a držitelem autorských práv ke všem dokumentům Zadavatel.
Garancí funkčnosti se spolehlivostí provozu systému 99,5 % je myšlena skutečnost, že Dodavatel musí zajistit dostupnost systému na úrovni 99,5 %, tzn. maximální doba nedostupnosti, čímž je myšlena nahlášená/zjištěná a neodstraněná Vada A dle specifikace v kapitole 2.8.5.1 a) nesmí překročit 0,5 % doby, za kterou je dostupnost měřena. Do nedostupnosti nejsou započteny plánované odstávky systému za účelem upgradu či údržby.
2.7.2 On-line dotazování KODOX vůči externím systémům
On-line dotazováním je myšleno pokládání dotazů prostřednictvím klientské aplikace KODOX do národních DB či do DB CS-EES nebo CS-VIS, které je používáno uživateli (živými lidmi) nebo systémy, jejichž workflow bude zastaveno nebo výrazně zkomplikováno v případě, že KODOX neposkytuje uvedenou funkcionalitu (typicky proces hraniční kontroly na první kontrolní linii vnější schengenské hranice, proces hraniční kontroly eGATE, atd.).
Uvedená funkcionalita, tj. dostupnost KODOX pro online dotazování vůči externím systémům má
stanoveno SLA 99,5 %.
Dodavatel nezodpovídá za nedostupnost odpovědí způsobenou nedostupností externích systémů samotných (SIS2, ICIS, ISO, NS-EES/CS-EES či CS-VIS nebo infrastrukturou mimo systém KODOX, apod.), zodpovídá však za prokazatelné odeslání dotazů.
Do měření doby SLA se plánované odstávky nezapočítávají jako nedostupnost systému, pokud není se Zadavatelem odsouhlaseno jinak pro každý konkrétní případ. SLA je měřeno vždy za 3 (tři) po sobě jdoucí měsíce. Vyhodnocováno je do jednoho měsíce po skončení daného 3měsíčního období.
2.7.3 SLA na doby odezev systému
SLA na dobu odezvy systému je vyhodnocováno pravidelně 1 měsíčně za období, které uplynulo od posledního vyhodnocení. Pokud je porušeno SLA, jsou uplatněny sankce v souladu s příslušnou kapitolou
2.7.5. Pro dobu odezvy systému platí požadavky vydefinované v kapitole 2.7.1 SLA na garanci funkčnosti
IS KODOX.
2.7.4 SLA na Helpdesk garanci doby opravy a reakční doby
Služba Helpdesku je dostupná nepřetržitě jedním z definovaných kanálů.
Započetí řešení požadavku znamená zpětný kontakt pracovníka Dodavatele s cílem komunikovat s pracovníky Zadavatele jejich problémy a nabídnout řešení požadavku.
Dostupnost služby Helpdesk pro nahlášení problémů, závad v systému bude v režimu 24x7.
Vada A – oprava nebo workaround do 12h s reakční dobou do 1h, pokud nebude se Zadavatelem
dohodnuto jinak – na funkcionality definované v kapitole č. 2.8.5.1.
Vada B – oprava nebo workaround do 72h s reakční dobou do 4h s návrhem řešení do 24h, pokud nebude
se Zadavatelem dohodnuto jinak - na funcionality definované v kapitole č. 2.8.5.2.
Vada C – oprava nebo workaround do 30 dnů s reakční dobou do 4 h s návrhem řešení do 72h . Reakční dobou se u vady C dle kapitoly 2.8.5.3 rozumí potvrzení, že jde o vadu této kategorie, aby nedošlo ke zpoždění v případě, že by počáteční identifikace závažnosti chyby byla mylná, pokud nebude se Zadavatelem dohodnuto jinak.
2.7.5 Sankce
Zadavatel vyhodnotí vznik nároku na smluvní sankci vždy do 30 dnů od konce každého kalendářního čtvrtletí, kdy je služba poskytována. Výše slevy plnění se vyčísluje vždy na překročení reakční doby a doby opravy, přičemž Zadavatel přihlíží ke všem okolnostem, za kterých k porušení SLA došlo.
2.7.5.1 Smluvní sankce za porušení doby dostupnosti
V případě nedodržení výše stanovených parametrů SLA vzniká Zadavateli nárok na smluvní sankci
v následující výši:
Překročení povolené doby nedostupnosti pro služby KODOX (2.7.1. a vnořené podkapitoly) | Smluvní sankce |
Větší než 0 hodin, ale menší než nebo rovnající se 1 hodina za sledované období | 20 000 Kč |
Větší než 1 hodina za sledované období, ale menší než nebo rovnající se 6 hodin za sledované období | 50 000 Kč |
Za každé další započaté 4 hodiny nad 6 hodin za sledované období. | 100 000 Kč |
Překročení povolené doby nedostupnosti pro dotazy do DB KODOX | |
Větší než 0 hodin, ale menší než nebo rovnající se 3 hodiny za sledované období | 10 000 Kč |
Větší než 3 hodiny za sledované období, ale menší než nebo rovnající se 12 hodin za sledované období | 30 000 Kč |
Za každé další započaté 4 hodiny nad 12 hodin za sledované období. | 50 000 Kč |
2.7.5.2 Smluvní sankce za porušení reakční doby a doby opravy vad systému
V případě prodlení Dodavatele s dodržením reakční doby a doby opravy vad typu A, B nebo C (viz kapitola
2.8.5 Kategorie vad) je dle smlouvy Dodavatel povinen uhradit Zadavateli následující slevy plnění:
a) Kategorie A (Podstatná vada)
Smluvní sankce ve výši 1 000 Kč za každou započatou 1 hodinu překročení reakční doby.
Smluvní sankce ve výši 500 Kč za každou započatou 1 hodinu překročení doby opravy, pokud má vada
dopad na SLA nebo pokud prostřednictvím Helpdesku nebo náhradním kanálem – viz vada dle 2.8.5.1 c)
– nelze nahlásit vadu typu 2.8.5.1 a)
b) Kategorie B (Méně závažná vada)
Smluvní sankce ve výši 500 Kč za každou započatou 1 hodinu překročení reakční doby. Smluvní sankce ve výši 1 000 Kč za každých započatých 24 hodin překročení doby opravy.
c) Kategorie C (Ostatní)
Smluvní sankce ve výši 200 Kč za každou započatou 1 hodinu překročení reakční doby. Smluvní sankce ve výši 1 000 Kč za každých započatých 24 hodin překročení doby opravy.
2.7.6 Definice termínů pro účely SLA
Plánovaná odstávka – Zadavatelem schválený čas, po který nebude systém KODOX dostupný v jedné nebo více svých funkcích, např. kvůli upgrade SW, release klientské aplikace apod.
Oprava – doba od nahlášení incidentu do vyřešení incidentu, závady, problému nebo požadavku nahlášeného formou servisního záznamu na helpdesk. Do doby opravy není řazena (započtena) doba, kdy Dodavatel čeká na součinnost nutnou ze strany externích systémů.
Reakční doba – doba od nahlášení do zahájení řešení incidentu, závady, problému nebo požadavku nahlášeného formou servisního záznamu na helpdesk.
2.7.7 Kategorie vad
Viz kapitola „Akceptace“ podkapitola „Kategorie vad“.
2.8 Akceptace
2.8.1 Akceptace „Plnění A.1 – Technická podpora provozu IS KODOX - fixní část“
Plnění A.1 (Technická podpora provozu IS KODOX - fixní část) je akceptováno na základě podpisu dílčího akceptačního protokolu. Dílčí akceptační protokol musí zejména uvádět Objednávkou dojednaný souhrn všech aktivit v členění, v jakém bylo plnění poskytnuto a v jakém rozsahu, za jaké období k plnění došlo.
Dílčí akceptační protokoly budou podepisovány vždy za uplynulé kalendářní čtvrtletí. Ke dni podpisu dílčího akceptačního protokolu Zadavatelem nesmí být evidována žádná vada kategorie A, která je způsobena plněním Dodavatele a s jejímž odstraněním by byl Dodavatel v prodlení, v takovém případě může být dílčí akceptační protokol podepsán Zadavatelem až po odstranění těchto vad (to se nevztahuje na vady pozáruční, jejichž odstraňování je řešeno samostatnou Objednávkou Plnění A.2 nebo Objednávkou z Plnění B). Podkladem pro fakturaci jsou dílčí akceptační protokoly za předchozí kalendářní čtvrtletí, pokud se Smluvní strany v příslušné Objednávce nedohodnou jinak.
2.8.2 Akceptace „Plnění A.2 – Technická podpora provozu IS KODOX – variabilní část“
Plnění v rámci technické podpory A.2 je akceptováno na základě podpisu akceptačního protokolu. Akceptační protokol musí zejména přesně uvádět souhrn všech aktivit s členěním, jaké plnění bylo poskytnuto a v jakém rozsahu (počet MD a rozdělení podle rolí), kdy k plnění došlo, jak dlouho trvalo, kdo jej provedl (jméno a příjmení pracovníka), kdo jej objednal a kdy.
2.8.3 Akceptace „Plnění B – Rozvoj IS KODOX“
a) Před ukončením předmětného plnění musí Zadavatel provést za účasti Dodavatele oboustranně schválené akceptační testy, pokud je tento přístup aplikovatelný (nejedná se např. o samostatnou dodávku dokumentů).
b) Předmět akceptace je akceptován, pokud nebude Zadavatelem uplatněna žádná vada kategorie A nebo taková kombinace vad typu B a/nebo C, které by ve svém důsledku způsobily vadu A a byla předána veškerá relevantní nová a/nebo aktualizovaná dokumentace. Chyby B a C nebránící akceptaci musí být popsány v akceptačním protokolu a musí být dohodnut termín jejich odstranění. To není možné, pokud jde o poslední plnění z rámcové dohody, po jejím ukončení.
c) Jestliže předmětné plnění splní akceptační kritéria akceptačních testů specifikovaných a schválených v analytické dokumentaci nebo odsouhlasených zvlášť před započetím testů v souladu s bodem 2.8.3 b), podepíší k němu Smluvní strany Akceptační protokol. Podpisem Akceptačního protokolu oběma Smluvními stranami se má se za to, že předmětné plnění bylo řádně Dodavatelem poskytnuto a Zadavatelem převzato.
d) Jestliže předmětné plnění nesplňuje stanovená akceptační kritéria, zaznamenají tuto skutečnost Smluvní strany do Akceptačního protokolu tak, že zde budou uvedeny, popsány a prokázány veškeré zjištěné závady a nedostatky. Dodavatel se zavazuje napravit tyto nedostatky ve lhůtě, která bude Smluvními stranami dohodnuta, a příslušné akceptační testy budou provedeny znovu (termín odstranění vad nesmí překročit termín plnění uvedený v příslušné Objednávce včetně případných dodatků). Tento proces testování a následných oprav se bude opakovat, dokud Dodavatel nesplní veškerá akceptační kritéria.
e) Vadou se pro účely této Smlouvy rozumí rozpor mezi vlastností nebo funkčností plnění proti plné funkčnosti systému tak, jak bude specifikován v odsouhlasené analytické dokumentaci a skutečnou vlastností či funkčností plnění.
f) Zadavatel provede akceptaci (tj. podepíše akceptační protokol) nebo sdělí Dodavateli vady bez
zbytečného odkladu.
2.8.4 Akceptace Plnění C
Plnění C je akceptováno na základě podpisu akceptačního protokolu za obě fáze, a to v souladu s bodem
2.5.4 . Bez akceptace obou fází, nebude plnění uznatelné a proplacené.
U plnění C bude akceptována nejprve první fáze – ověření připravenosti všech výstupů předání a jasného postupu směřujícímu k úspěšnému předání viz 2.5.3.
Následně pokud bude akceptována první fáze, bude přistoupeno k druhé fázi. Druhá fáze plnění C bude akceptována na základě prokazatelného předání know-how novému Dodavateli, prokazatelnému zvládnutí procesů novým Dodavatelem nebo prokázání (původním Dodavatelem), že původní Dodavatel splnil všechny povinnosti související s předáním.
Ke dni podpisu akceptačního protokolu Zadavatelem nesmí být evidována žádná vada kategorie A, která je způsobena plněním Předávajícího subjektu, a ohrozila by proces Handoveru, a s jejímž odstraněním by byl Přebírající subjekt v prodlení, v takovém případě může být dílčí akceptační protokol podepsán Zadavatelem až po odstranění těchto vad a o dobu odstranění závad je prodlouženo plnění Handoveru bez jakýchkoliv nárok na vícepráce pro Předávající subjekt.
2.8.5 Kategorie vad
2.8.5.1 Vada typu A
se rozumí stav, kdy systém neposkytuje některou z funkcionalit systému specifikovaných
v Objednávce, technické dokumentaci nebo v akceptované analytické dokumentaci a dále:
a) systém nesplňuje účel, pro který byl vytvořen (definovaný v Objednávce, technické dokumentaci nebo v akceptované analytické dokumentaci), a uživatelé nemohou používat funkcionality, které k výkonu svých činností nutně potřebují, nebo zpracováním dat není naplňována legislativa, která již je v systému zapracována, přestože to bylo účelem plnění (Plnění A, Plnění B),
b) je znemožněno provedení požadovaných akceptačních testů nebo jinou akceptační proceduru
(Plnění A.2, Plnění B),
c) není funkční služba Helpdesk, pokud není zajištěn náhradní způsob hlášení chyb (Plnění A, Plnění B),
d) systém vykazuje nedostatek, kdy dílo zjevně neobsahuje části sjednané Smlouvou nebo
Zadávací dokumentací, či zcela chybí podstatná část řešení
e) nebo libovolná kombinace výše uvedených stavů.
2.8.5.2 Vada typu B
a) se rozumí stav, kdy je systém schopen omezeného provozu nebo neposkytuje některou z funkcionalit specifikovaných v Objednávce, technické dokumentaci nebo v akceptované analytické dokumentaci, ale přesto lze dokončit všechny nezbytné procesy pro plnění úkolů Zadavatele a plní povinnosti vyplývající z legislativy, které již byly v systému implementovány (Plnění A.2, Plnění B),
b) způsobuje, že některá z funkcionalit systému není plně činná nebo ztěžuje užívání u některého koncového uživatele, avšak tento stav má jen zanedbatelné dopady na provoz u Zadavatele (Plnění A, Plnění B, Plnění C),
c) způsobí nefunkční službu Helpdesk, pokud je zajištěn náhradní způsob hlášení chyb (Plnění A, Plnění B, Plnění C),
d) nebo libovolná kombinace výše uvedených stavů.
2.8.5.3 Vadou typu C
se rozumí vada, která nemá zásadní vliv na provoz nebo funkcionality systému, závada, která nespadá do
kategorie A ani B (u Plnění A, Plnění B, Plnění C).
2.8.6 Akceptace Dokumentace
Bude-li plnění Dodavatele spočívat ve vypracování dokumentu v listinné nebo elektronické podobě, bude
jeho akceptace provedena následovně:
a. Dodavatel předá v dohodnutém termínu první verzi dokumentu.
b. Zadavatel vznese své výhrady nebo připomínky k první verzi dokumentu obecně do tří (3), nejpozději do patnácti (15) pracovních dnů od jejího doručení (podle rozsahu dokumentace, do tří dnů u rozsahu do 30ti stran, nad 30 stran obecně nejpozději do 15ti dnů, nebude-li dohodou na vedení projektu stanoveno jinak); nevznese-li Zadavatel ve stanovené lhůtě k první verzi dokumentu žádné výhrady ani připomínky, považují Smluvní strany uplynutím této lhůty dokument ve znění jeho první verze za řádně akceptovaný a pro Smluvní strany závazný.
c. Vznese-li Zadavatel ve stanovené lhůtě své výhrady nebo připomínky k první verzi dokumentu, zavazuje se Dodavatel obecně do tří (3), nejpozději do pěti (5) pracovních dnů od jejich doručení (nebude-li dohodnuto na programovém výboru jinak) provést veškeré potřebné úpravy dokumentu dle výhrad a připomínek Zadavatele a takto upravený dokument předat jako jeho druhou verzi Zadavateli k akceptaci.
d. Zadavatel se zavazuje vznést své výhrady nebo připomínky k druhé verzi dokumentu obecně do tří (3), nejpozději do pěti (5) pracovních dnů od jejího doručení. Nevznese-li Zadavatel ve stanovené lhůtě k druhé verzi dokumentu žádné výhrady ani připomínky, považují Smluvní strany uplynutím této lhůty dokument ve znění jeho druhé verze za řádně akceptovaný a pro Smluvní strany závazný. K výhradám nebo připomínkám, které Zadavatel opomněl vznést již k první verzi dokumentu, se pro účely akceptace nebude přihlížet, Dodavatel však bude povinen takovéto výhrady nebo připomínky Zadavatele vypořádat do deseti (10) pracovních dnů od akceptace dokumentu.
e. Vznese-li Zadavatel ve stanovené lhůtě své výhrady nebo připomínky k druhé verzi dokumentu, zavazují se Smluvní strany zahájit společné jednání za účelem odstranění veškerých vzájemných rozporů a za účelem akceptace dokumentu, a to nejpozději do tří (3) pracovních dnů od výzvy kterékoliv Smluvní strany. Nepodaří-li se Smluvním stranám dojít ke shodě o akceptaci dokumentu ani ve lhůtě dvaceti (20) pracovních dnů od zahájení společného jednání dle předchozí věty, je kterákoli ze Smluvních stran oprávněna odstoupit od Objednávky, které se schvalovaný dokument týká.
2.9 Záruky
2.9.1 Záruky Plnění A.2
Na práce a služby dodané v rámci Plnění A.2 se vztahuje záruka 6 měsíců.
2.9.2 Záruky Plnění B
Na práce dodané v rámci rozvojových aktivit systému KODOX se vztahuje záruka po dobu 12 měsíců od doby jejich uvedení do provozu. Záruka se vztahuje na plnění, které bylo provedeno v souladu s akceptovanou analytickou dokumentací dané Objednávky. Pokud se bude chovat akceptované dílo v rozporu s akceptovanou analýzou, je Dodavatel povinen funkcionalitu v záruční době opravit, a to v termínech podle kategorie projevené chyby.
Dnem uvedením díla do provozu je myšleno protokolární předání/převzetí díla (akceptací) v souladu s procesem popsaným v kapitole Akceptace.
2.10 Další podmínky plnění
2.10.1 Místo výkonu prací
Plnění A.1 je poskytováno v místě určeném Zadavatelem v prostorách jeho datových center v Praze. Vzdálený přístup zásadně není možný. Za vzdálený přístup není považována práce v prostorách Objednatele na dedikovaném vývojovém prostředí zřízeném v prostorách Objednatele.
Plnění A.2, pokud nejde o práci na některém z prostředí Zadavatele, mohou být prováděna i mimo prostory Zadavatele, není-li Objednatelem v Objednávce stanoveno jinak.
Plnění B, pokud nejde o práci na některém z prostředí Zadavatele, mohou být prováděna i mimo prostory Zadavatele, není-li Objednatelem v Objednávce stanoveno jinak.
V případě výjimečných situací (nouzový stav a podobně) budou Objednatelem definována adHoc opatření.
2.10.2 Mlčenlivost – NDA
Každá osoba, která se seznamuje s informacemi o IS KODOX, musí podepsat smlouvu o mlčenlivosti a je jí vystaveno prohlášení o důvěrnosti.
2.10.3 Komunikační jazyk
Základním komunikačním jazykem se Zadavatelem a jazykem pro přípravu veškeré dokumentace je zásadně český jazyk.
Dodavatel musí být schopen zpracovávat dokumentaci předanou mu v anglickém jazyce, musí být schopen poskytovat komunikační podporu pro formulaci závad na systému nebo odpovědi pro orgány EU v anglickém jazyce. Musí být rovněž schopen zajistit efektivní účast na jednáních vedených v anglickém jazyce, které bude schopen vést na profesionální úrovni.
2.10.4 Vývoj nových komponent
Dodavatel se bude držet standardů pro vývoj aplikací pro externí dodavatele (příloha 1d požadavky na vývoj aplikací – externí dodavatelé). Jiné technologie je možné využít pouze v odůvodněných případech, kdy je jejich využití nezbytné a není možné využít technologie uvedené ve standardu.
2.10.5 Specifikace vývojového a testovacího prostředí
Dodavatel je povinen na základě požadavku Zadavatele vytvořit kopii vývojového prostředí na infrastruktuře Zadavatele. Dodavatel je povinen v případě zajištění potřebného pracovního prostoru Zadavatelem provádět vývoj přímo na vývojovém prostředí Zadavatele. Dodavatel je dále povinen na infrastruktuře Zadavatele udržovat testovací a školící prostředí.
Upřesnění k jednotlivým prostředím:
• K zajištění vývoje komponent IS KODOX slouží vývojové prostředí.
• K ověření funkčnosti provedených změn ze strany Dodavatele a Zadavatele bude sloužit testovací prostředí. Testovací prostředí musí být totožné s produkčním prostředím.
• Pro školení uživatelů je určeno školící prostředí.
•
A
Příloha A: Detailní specifikace služeb Plnění
1 Technická podpora provozu IS KODOX - fixní část (Plnění A.1)
Služby fixní technické podpory představují pravidelné činnosti, jejichž cílem je co největší prevence výskytu případného nestandardního stavu, respektive incidentu, který by vyústil v nefunkčnost systému nebo omezení služeb. V případě výpadku pak uvedení systému do provozního stavu v souladu s definovanými parametry.
Nedílnou součástí podpory je zajištění Helpdesku, ve kterém bude hlášení chyb, nestandartních stavů a komunikace mezi Dodavatelem a Zadavatelem zajištěna.
Dodavatel poskytne plnění technické podpory na veškeré součásti systému softwarové nebo hardwarové povahy všech komponent IS KODOX a bude provádět garanční opravy dle požadavků Zadavatele.
Plnění A.1 (Technická podpora provozu IS KODOX - fixní část) je objednáváno vždy na celý rok (tj. 12 kalendářních měsíců) nebo jeho celé násobky a hradí se paušální platbou.
Specifikace služeb |
Poskytování technické podpory HELPDESK (komplexní aplikace typu ServiceDesk) 24 hodin, 7 dní v týdnu s dobou odezvy uvedenou dále v textu. V případě naléhavé potřeby, či pro případ nedostupnosti HELPDESK, musí být zajištěna nepřetržitá služba, tzv. pohotovostní čísla s tím, že požadavek bude vždy dodatečně zadán na HELPDESK s výchozím časem nahlášení požadavku. |
Poskytování telefonické konzultace (HOTLINE): 1) SW konzultace na telefonním čísle určeném dodavatelem. 2) HW konzultace na telefonním čísle určeném dodavatelem. |
Pravidelná měsíční kontrola logů SW. |
Pravidelná měsíční kontrola logů centrálních serverů. |
Pravidelná měsíční kontrola výkonnosti SW s ohledem na HW. |
Pravidelná měsíční kontrola funkčnosti uživatelských aplikací v rámci IS KODOX. |
Detekce chybových stavů systému, ověření, zkoumání, provedení (re)testy případných problémů a nedostatků, zpracování návrhu k jejich odstranění. |
Ladění parametrů systému a odstraňování zjištěných výkonnostních problémů. |
Kontrola konzistence databázových schémat včetně úprav dokumentace. |
Specifikace změnových požadavků (ZP) Zadavatele, předběžná analýza a předběžné ocenění prací objednávaných z Plnění A2 a Plnění B. |
Údržba produkčních aplikačních vrstev (Software Assuarance) včetně kontroly a aktualizace číselníků a skriptů, dle aktuálních požadavků a potřeb, aplikace bezpečnostních aktualizací a doporučení, upgrade (povyšování na vyšší verzi) firmware, DB aj. |
Korektivní služby zahrnující podporu Zadavatele v případě potřeby eskalace anomálie, nestandardního nebo chybového stavu, tj. poskytnutí potřebných podkladů, případně na základě žádosti Zadavatele přímou komunikaci s třetí stranou. |
Preventivní ověřování (monitoring) – příprava a aktualizace skriptů pro tvorbu reportů, průběžné vyhodnocování výsledků monitoringu (úpravy hodnot metrik), zapracování nových metrik, vyřazování nepoužívaných metrik, návrh preventivních opatření v souladu s procesy a rozvojem systému IS KODOX (v současné době pouze ke komponentě DSS). |
Kontrola a podpora nástrojů pro monitoring infrastruktury a sledovaní dostupnosti systému a služeb. |
Kontrola integrity dat s ohledem na procesy IS KODOX. |
Zapínání a obnova běhu databáze po HW problémech nebo výpadcích síťových služeb včetně základního ověření probíhajících procesů IS KODOX. |
Provozní deník podpory Zadavateli se správou a vedením provozního deníku systému IS KODOX. |
Správa, úprava a aktualizace technické a provozní dokumentace IS KODOX, MOBLUST G2 – zpracování změn s ohledem na provoz a úpravy systému (Dodavatel proaktivně provede revizi, v min. rozsahu jednou ročně, aktuálnosti veškeré dokumentace k systému a provede její úpravu). |
Kontrola a podpora virtualizačních služeb. |
Detekce a proaktivní podpora k řešení latentních chyb dříve, než se mohou projevit selháním systému nebo jeho komponent. Činnosti spojené s úpravou konfigurací nebo nasazení aktualizací SW nebo firmware zařízení, které sníží šanci budoucích problémů systému a jednotlivých částí (SW, zařízení apod.). |
Kontrola datové komunikace a případné testy konektivity s externími systémy (EES, VIS, CIS, DWH, NKA, aj.). |
Údržba systémových SW částí infrastruktury (aplikace opravných fixů a patchů). |
Aktualizaci konfigurace systému (a jednotlivých komponent) s cílem zachování úrovně HW a SW podpory garantované Dodavatelem pro jednotlivé části systému a systému jako celku. |
Management kvality poskytovaných služeb - udržovat kvalitu poskytovaných služeb systému koncovým uživatelům. |
Expertní podpora vysoké dostupnosti služeb a konzultace při administraci aplikačních clusterů. Činnost přizpůsobovat konfigurace systému a jednotlivých součástí s cílem udržet systém na úrovni garantované dostupnosti, odezvy a dalších kvalitativních ukazatelů. |
Release management podpora při nasazení nových verzí systému či komponent. |
Údržba, konfigurace produkčního, testovacího, školního prostředí. |
Údržba, konfigurace vývojového prostředí (Plnění TP1a). |
Správa certifikátů a včasná reakce na potřebu jejich změny včetně vedení jejich přehledu. |
Reporting o stavu systému (hlášení o výpadcích systému-nedostupnosti, externích systémů), reporty z Helpdesku, Pravidelný měsíční monitoring dostupnosti (SLA) systému v uplynulém období. |
Poskytování souhrnného přehledu o zatížení systému z pohledu aplikačního a systémového. |
Detekce a analýza a odstranění případných nestandardních stavů a dlouhodobých trendů, které se doposud neprojevily vůči okolním systémům nebo uživatelům. Seznámení pracovníků Zadavatele s problémem, jeho příčinou a způsobem řešení. |
PM, koordinace, administrativa, řízení kvality produktů, provádění obvyklé administrace v rozsahu řízení a vedení projektu (např. pořizování zápisu z jednání, vytváření reportů a statistik o provozu systému, aj. administrativní činnosti). |
Činnosti k zajištění funkčnosti systému MOBLUST G2: Pravidelná měsíční kontrola stavu a funkčnosti. Pravidelná měsíční kontrola instalace aktualizací a aktuálního firmware. Pravidelná měsíční kontrola výkonnosti rozhraní MOBLUST G2. Činnosti k zajištění funkčnosti systému MOBLUST G2 (pokračování z předchozí strany): Odstranění chybových stavů a poruch systému v rámci měsíční kontroly. Podpora provozu informačního systému poskytovaná podle požadavků Správce. |
Ostatní nevyjmenované práce nutné pro garantování funkčnosti systému |
2 Technická podpora provozu IS KODOX - variabilní část (Plnění A.2)
Do prací, které je možno objednávat z Plnění A.2 služby technické podpory pro stávající provozní infrastrukturu systému IS KODOX – variabilní část, patří zejména činnosti související se změnou konfigurace systému nebo jeho části a činnosti s vazbou na rozvoj systému a školení formou konzultace.
Dodavatel je povinen zahájit požadované služby ve lhůtě od účinnosti Objednávky, pokud nebude v
Objednávce stanovena lhůta delší.
Plnění A.2 (Technická podpora provozu IS KODOX – variabilní část) bude čerpáno na základě Objednávek obsahujících konkrétní specifikaci činností, předpokládaný počet MD a jejichž přílohou bude soupis objednávaných rolí. Z důvodu plynulé návaznosti aktivit se různé Objednávky na Plnění A.2 mohou poskytováním plnění časově překrývat. Čerpání daného plnění je nenárokové, Zadavatel není povinen jej čerpat.
Specifikace služeb |
Práce experta na kyber-bezpečnost. |
Komplexní administrace systémových rolí a oprávnění. |
Úpravy Bezpečnostní dokumentace v závislosti na požadavcích Zadavatele a změnách spojených s provozem, rozvojem a úpravami systému. |
Poskytování podpory Zadavateli a podpora při testování s externími subjekty (EES, VIS, NKA, eu-LISA, aj.) |
Poskytnutí potřebného školení formou konzultace k poskytovaným službám. |
Poskytování podpory Zadavateli s tvorbou, úpravou dokumentů PČR s ohledem na provoz, rozvoj a úpravy systému IS KODOX v závislosti na úpravě systému či legislativního rámce EU. |
Poskytování podpory Zadavateli s reakcí na nutné změny zákonů či vyhlášek (právních předpisů ČR) na základě změn, rozvoje systému IS KODOX. |
Údržba bezpečnostního managementu, vytvoření a údržba plánu udržitelnosti podpory a provozu (součástí je Business Recovery a Business Continuity Process). |
Poskytování podpory Zadavateli, analýza technických dokumentací ke zpracování dopadů změn (ICD,DTS, TDD a rozhraní externích systémů). |
Poskytování podpory Zadavateli s diagnostikou problémů a generováním statistik a reportů. |
Příprava technických zpráv a implementačních postupů v technické oblasti. |
Dohled nad pracemi prováděnými třetími stranami, které mají nebo mohou mít přímý nebo nepřímý dopad na provoz IS KODOX. |
Diagnostika, optimalizace a řešení problémů, nedostatků. |
Analýza provozního stavu systému na vyžádání Zadavatele. |
Analytická podpora pro řešení problémů, vyplývajících z požadavků externích systémů, bezpečnostní podpory. |
Analytická podpora pro diagnostiku, prevenci a řešení problémů s externími subjekty. |
Ověření, zkoumání, (re)testy případných problémů, nedostatků. |
Kritické úpravy aplikací a drobnější rozvojové aktivity, které z časových důvodů nesnesou odkladu. |
Služby na odstranění závad zjištěných po uplynutí záruční doby. |
Záloha dat v neprodukčním prostředí (testovací a vývojové prostředí). |
Konzultace k výše uvedeným činnostem a detailní technické poradenství nebo vysvětlení. |
Migrace systému na nový HW. |
Podpora zadavatele při plánování a provedení testu obnovy. |
Podpora Zadavatele při plánování a provádění testování vysoké dostupnosti a udržitelnosti (například test přepnutí do záložní lokality, test BCP, DRP). |
Ostatní nevyjmenované práce , které se týkají změny konfigurace systému, nebo které mají vazbu na rozvoj systému. |
Příloha B: Projektové řízení
1 Zásady projektového řízení
1.1 Projektová dokumentace
Gestorem veškeré dokumentace, která bude vznikat v souvislosti s KODOX, je Dodavatel (pokud nebude dohodnuto jinak). Konkrétní způsob vznášení a vypořádávání připomínek (např. přes e-mail, Sharepoint apod.) bude dohodnut a popsán v ZDP – součástí ZDP budou komunikační pravidla, komunikační matice a seznam kontaktů na všechny členy projektového týmu.
Při vytváření projektové dokumentace bude Dodavatel používat vzory (šablony) Zadavatele nebude-li stanoveno jinak. Pokud bude zapotřebí vytvořit dokument, pro nějž dosud šablona neexistuje, bude Dodavatel na jeho vzhledu (vizuální stránka, formátování, struktura ad.) spolupracovat se Zadavatelem. Detailní aspekty řízení projektové dokumentace budou popsány v ZDP, který musí obsahovat zejména tato pravidla:
• název dokumentu – bude respektovat dohodnutý vzorec, např.:
system_typDokumentu_poradoveCislo_datumVzniku_nazev/predmet_verze.pripona;
• použité nástroje a formát dokumentu – pokud není dohodnuto jinak, všechny dokumenty jsou zasílány v editovatelném a recitovatelném formátu, ve formátu *.docx a nikoli PDF. Všechny dokumenty musejí být zasílány ve standardním, běžně dostupném formátu. Zadavatel má k dispozici tyto nástroje: Microsoft Word 2016, Microsoft Excel 2016, Microsoft PowerPoint 2016, Microsoft Project 2016, Visio 2016, Adobe Acrobat Reader 2015 (verze nástrojů budou průběžně povyšovány), finální verze budou ve formátu archivní pdf;
• struktura a vzhled dokumentu – bude dáno vzorem, který dodá Zadavatel, resp. který bude u dosud neexistujících dokumentů vypracován v součinnosti s Dodavatelem. Dokumenty nebudou obsahovat loga ani jiné identifikační údaje Dodavatele;
• gestor dokumentu – pro každý dokument musí být definován jeho gestor (v projektové terminologii vlastník) – tedy subjekt odpovědný za jeho životní cyklus;
• schválení dokumentu – pro každý dokument musí být definováno, jak proběhne jeho schválení – zda stačí odsouhlasení e-mailem či zanesením rozhodnutí do zápisu z jednání, anebo zda musí být dokument podepsán (pokud ano, tak kým), příp. zda bude uplatněno pravidlo tichého souhlasu po uplynutí definované lhůty apod.;
• stupeň utajení dokumentu – každý dokument musí mít vyznačený stupeň utajení a musí být dodržována bezpečnostní pravidla danému stupni odpovídající;
• velikost dokumentu – maximální velikost dokumentu zasílaného přes e-mail bude 10 MB;
• formální úprava dokumentu (textu) – text zarovnán do bloku, data psát ve formátu DD.MM.RRRR (např. 28.02.2018), finanční částky psát s tečkou mezi tisíci a vždy uvádět, zda se jedná o částku včetně anebo bez DPH (např. 3.500.000,- Kč bez DPH) ad.
Neúplný seznam projektové dokumentace je uveden v následující tabulce. Nejedná se o kompletní výčet
– účelem tabulky je pouze poskytnout rámcovou představu o množství dokumentů. Skladba dokumentů a jejich další atributy (gestor apod.) budou předmětem dohody. Dokumenty, jejichž gestorem není Dodavatel, však mohou být s Dodavatelem konzultovány, příp. může být Dodavatel požádán, aby vytvořil část dokumentu nebo pro jeho vytvoření dodal podklady.
Č. | Dokument | Navrhovaný gestor |
1 | investiční záměr | Zadavatel |
2 | stanovisko architekta kybernetické bezpečnosti MV ČR k investičnímu záměru | Zadavatel |
3 | návrh na zadání veřejné zakázky | Zadavatel |
4 | stanovisko architekta kybernetické bezpečnosti MV ČR k návrhu na zadání veřejné zakázky | Zadavatel |
5 | návrh Objednávky | Dodavatel |
6 | Objednávka | Dodavatel, Zadavatel |
8 | základní dokument projektů | Dodavatel |
9 | harmonogram projektu | Dodavatel |
10 | personální zajištění projektu | Dodavatel |
11 | zpráva o stavu projektu | Dodavatel |
12 | závěrečná zpráva z projektu | Dodavatel |
13 | zápis z jednání (vedení projektu, akceptační komise, eskalační komise, odborné schůzky ad.) | Dodavatel |
14 | akceptační protokol (měsíční akceptace technické podpory, akceptace celého projektu nebo jeho dílčích částí ad.) | Dodavatel |
15 | předávací protokol | předávající subjekt |
16 | výkaz činností | Dodavatel |
17 | změnový požadavek | Dodavatel |
18 | testovací scénáře | Dodavatel |
19 | protokol o provedení testů | subjekt, který testuje (dodavatel i zadavatel) |
20 | evidence změn | Dodavatel |
21 | evidence projektových rizik | Dodavatel |
22 | evidence úkolů | Dodavatel |
1.1.1 Životní cyklus projektu
Každý projekt IS KODOX má tyto fáze:
1.1.2 Příprava
Fáze přípravy zahrnuje aktivity od identifikace potřebnosti změny po uzavření Objednávky, která realizaci této změny smluvně ošetřuje. Identifikované změny jsou vedeny v evidenci změn. Iniciátorem změny může být řada subjektů – koncoví uživatelé, administrátoři, pracovníci Dodavatele, třetí strany (např. eu- LISA), legislativa ad. Evidence změn obsahuje mj. ohodnocení jejich priority, které vychází z aspektů bezpečnostních, technických, legislativních, finančních ad. Po vybrání změn, které budou realizovány, následuje tento proces:
• Vytvoření změnového požadavku (ZP) – slouží k analýze, specifikaci předmětu plnění požadované změny Zadavatele, včetně hrubého odhadu ceny a termínů plnění. Jedná se z pohledu projektu o vytvoření Charty projektu pro zadání Obchodního případu (investičního záměru)
• Vytvoření investičního záměru (IZ) – slouží k alokaci potřebných finančních prostředků. Vytváří jej Zadavatel na základě podkladů od Dodavatele (změnového požadavku/charty projektu);
• Vypořádání stanoviska architekta kybernetické bezpečnosti k IZ – má-li k investičnímu záměru připomínky architekt kybernetické bezpečnosti MV ČR, Zadavatel je vypořádá. Dodavatel může být konzultován, resp. požádán o dodatečné informace či podklady;
• Vytvoření návrhu Objednávky – slouží jako podklad pro uzavření smluvního vztahu s dodavatelem na konkrétní plnění projektu. Vytváří jej Zadavatel na základě investičního záměru a dodatečných podkladů od Dodavatele (zejména rozpad ceny na jednotlivé role a člověkodny a technický popis řešení);
• Vytvoření závazné Objednávky – Zadavatel odešle Dodavateli výzvu k plnění na základě návrhu Objednávky, tj. vyplněný vzor Objednávky. Objednávka je Dodavatelem připomínkována/upravena v případě nutnosti/nepřesnosti zadání, které by vedlo k nerealizovatelnosti projektu.
• Uzavření objednávky – Dodavatel potvrdí Objednávku. Potvrzením Objednávky Dodavatelem dojde k uzavření Objednávky, resp. vytvoření smluvního vztahu na dodávku požadovaného konkrétního plnění.
1.1.3 Realizace
Fáze realizace zahrnuje aktivity od zahájení prací na projektu po dodání a finální akceptaci všech výstupů/produktů projektů (celého předmětu plnění). Projekt je formálně zahájen kick-off meetingem, na kterém Dodavatel prezentuje Zadavateli Plán projektu (resp. je na tomto jednání upřesněn), jenž zahrnuje tyto dokumenty:
• Harmonogram projektu – obsahuje rozpad projektu na jednotlivé etapy (typicky se jedná o analýzu, vývoj, testování, nasazení do produkce, zvýšený monitoring), přičemž vždy alespoň aktuální etapa je rozpracována na vyšší úroveň detailu (jednotlivé činnosti), je-li to účelné. Harmonogram je dodán v tabulkové podobě i v grafickém vyjádření (Ganttův diagram). Na vyžádání Dodavatel poskytne Zadavateli zdrojový soubor Harmonogramu projektu (např. soubor ve formátu *.mpp – MS Project). Z harmonogramu musí být zřejmé, kdy jsou platební milníky a kdy bude svolána akceptační komise;
• Personální zajištění projektu – Dodavatel i Zadavatel jmenují do projektových rolí konkrétní pracovníky, kteří jsou vedeni v evidenci včetně kontaktních údajů (e-mail, mobilní telefon, příp. pevná linka);
• Rizika projektu – Dodavatel vede evidenci projektových rizik, která jsou průběžně aktualizována. Evidence obsahuje mj. název/předmět rizika, pravděpodobnost a dopad rizika, protiopatření;
• Úkoly – Dodavatel vede evidenci úkolů, které je zapotřebí splnit. Tuto evidenci pravidelně
aktualizuje;
• Získané zkušenosti (lessons learnt) – Dodavatel vede evidenci získaných lekcí/postřehů/znalostí, které vyplývají ze zkušeností (z praxe), a tyto zkušenosti průběžně uplatňuje/zohledňuje a učí se z nich;
• Akceptační kritéria – Dodavatel v součinnosti se Zadavatelem definuje akceptační kritéria, která budou předmětem testování, resp. akceptační komise. Akceptační kritéria mohou být upřesněna v analytické etapě projektu;
Dodavatel průběžně reportuje Zadavateli stav realizace projektu (postup prací) na pravidelných jednáních programového výboru (viz dále). Nedaří-li se některé problémy vyřešit na úrovni projektových manažerů
(programového výboru), je svolána eskalační komise, která tyto problémy řeší na úrovni ředitelů projektu.
V případě potřeby jsou svolávána ad hoc odborná jednání.
Etapa testování vždy zahrnuje nejprve testování na straně Dodavatele a poté na straně Zadavatele. Dodavatel je povinen vytvořit pro Zadavatele testovací scénáře, které komplexně prověří funkčnost předmětu plnění a které musejí zahrnovat akceptační kritéria stanovená v počáteční fázi projektu. Zadavatel vytvoří protokol o provedení testů, který slouží jako vstup pro akceptační řízení. V případě, že se konají povinné testy s centrálním systémem (organizované agenturou eu-LISA), vytvoří protokol o provedení testů Dodavatel.
Po dosažení milníků stanovených v Harmonogramu projektu dochází k akceptaci dílčích etap projektu (anebo projektu jako celku v jeho závěru). Detailní akceptační proces je popsán v kapitole této dokumentace „Akceptace“.
1.1.4 Akceptační proces
Viz kapitola „2.8 Akceptace“ dokumentu Příloha 1a veřejná část.
1.1.5 Ukončení
Fáze ukončení zahrnuje rekapitulaci celého projektu včetně konsolidace, kontroly a archivace veškeré projektové dokumentace. Projekt je formálně ukončen wrap-up meetingem, na kterém Dodavatel prezentuje Zadavateli závěrečnou zprávu z projektu, která obsahuje mj. shrnutí harmonogramu (příp. kdy a proč byl porušen), nákladů, nově identifikovaných rizik a protiopatření, získaných zkušeností apod.
1.1.6 Organizace projektu
1.1.6.1 Jednání
Pro všechna jednání, která se uskuteční v rámci Programu IS KODOX mezi Zadavatelem a Dodavatelem
(příp. i dalšími stranami), platí:
• Jednání se konají v prostorách Zadavatele ve vzájemně dohodnutém čase (Zadavatel zajistí patřičné prostory a případné vybavení – dataprojektor, flipchart ad.);
• jednání formálně svolává Dodavatel, není-li dohodnuto jinak, (po předchozí domluvě ohledně místa, času a účastníků) standardně vytvořením schůzky v kalendáři Outlook nebo s Exchange kompatibilním a jejím rozesláním určeným osobám, variantně je možné schůzku svolat mailem nebo obvoláním účastníků;
• Dodavatel pořizuje Zápis z jednání:
o draft zápisu z jednání zašle Dodavatel k připomínkám Zadavateli, a to do 2 pracovních dnů od konání daného jednání;
o zápis z jednání je vytvořen ve vzoru/šabloně Zadavatele;
1.1.6.2 Organizační struktura projektu
Každý projekt má tuto strukturu:
• Realizační týmy – jedná se o pracovní tým Zadavatele a pracovní tým Dodavatele, který na základě pokynů projektových manažerů realizuje jednotlivé aktivity směřující k vytvoření předmětu plnění. Určení jednotlivých rolí a jejich obsazení konkrétními osobami (včetně kontaktních údajů)
je uvedeno v Plánu projektu (viz výše) – typicky se jedná o programátory, analytiky, testery, architekty, databázové specialisty, bezpečnostní experty ad. Pracovní týmy se scházejí ad hoc dle potřeby, řeší odbornou problematiku. Na základě tematického zaměření může jít např. o jednání analytické, jednání testerů apod.;
• Programový výbor (Vedení projektu) – jedná se o hlavní řídicí orgán, který je tvořen projektovými manažery Zadavatele a Dodavatele a jimi přizvanými osobami. Schází se každý týden v pevně stanoveném dni a čase (případně jinak – dle aktuální potřeby). Na programovém výboru Dodavatel podává Zadavateli report o stavu projektu (včetně stavu nedostupnosti systému za uplynulý kalendářní měsíc), prezentuje aktualizovaný Plán projektu – postup prací, (ne)dodržování harmonogramu, stav rizik, získaných zkušeností, úkolů a jejich plnění, problémy a jejich řešení ad. Dodavatel také vytváří a prezentuje Zadavatelem definované reporty o stavu provozu systému a vývoji sledovaných ukazatelů;
• Eskalační komise (Řídící rada) – jedná se o vrcholový orgán, který je svoláván ad hoc na podnět projektového manažera Zadavatele či Dodavatele v případě, že nastane problém, který se nedaří vyřešit na úrovni programového výboru. Je tvořena řediteli projektů Zadavatele a Dodavatele, projektovými manažery Zadavatele a Dodavatele a případně dalšími jimi přizvanými osobami;
• Akceptační komise – jedná se o orgán, který je svoláván projektovým manažerem Zadavatele, když je zapotřebí akceptovat předmět plnění projektu nebo jeho dílčí etapu. Posuzuje (ne)splnění akceptačních kritérií a tím rozhoduje o (ne)akceptování předmětu plnění. Je tvořena projektovými manažery Zadavatele a Dodavatele a případně dalšími jimi přizvanými osobami. Detailní průběh akceptačního procesu bude rozpracován v ZDP, obecně je stanoven výše.
1.1.7 Implementace metodiky PRINCE2
Jak je uvedeno výše, při řízení projektů vychází Zadavatel z metodiky PRINCE2, jejíž zásady musejí být zahrnuty do ZDP. Pro přehlednost je způsob implementace PRINCE2 do prostředí Zadavatele shrnut v následujících podkapitolách:
1.1.7.1 Principy
Principy PRINCE2 jsou implementovány následujícím způsobem:
I. Nepřetržité zdůvodňování potřebnosti projektu
• Dodavatel vede evidenci změn, jejíž součástí je ohodnocení priority změn;
• Součástí NZVZ je povinné pole „Stručný důvod potřeby“, v němž je zdůvodnění potřebnosti projektu zdokumentováno a schváleno;
II. Učit se ze zkušeností
• Dodavatel vede evidenci získaných zkušeností, její aktualizace je součástí pravidelného reportingu a závěrečné zprávy z projektu;
III. Definované role a odpovědnosti
• Role (a jejich obsazení konkrétními osobami) a odpovědnosti jsou definovány v Plánu projektu
v části Personální zajištění projektu;
• Kromě projektových rolí je zapotřebí mít stanoveny i další povinné role (z hlediska
bezpečnosti, ochrany osobních údajů apod.) – zajišťuje Zadavatel;
IV. Řízení po etapách
• Na kick-off meetingu Dodavatel prezentuje mj. rámcový Harmonogram projektu, přičemž detailně je vždy rozpracována, monitorována a řízena aktuální etapa;
V. Řízení podle výjimek
• Cílem není zabývat se detailním monitoringem a řízením každého detailu a jednotlivého úkonu každého pracovníka, ale pouze aktivit/problémů, které danou úroveň řízení svou komplexitou přesahují. Dílčí problémy v projektu si primárně řeší každý pracovník sám, a teprve když je nedokáže vyřešit anebo potřebuje součinnost, je problém řešen s kolegy v rámci realizačního týmu. Pokud realizační tým problém nevyřeší, je postoupen programovému výboru. Pokud není vyřešen ani tam, je postoupen eskalační komisi;
VI. Zaměření na produkt
• Úspěšné projekty jsou zaměřeny na výstup, nikoli na dílčí aktivity. Cílem projektu je dodat výstup, který všem dotčeným subjektům (tzv. „stakeholderům“) přinese přidanou hodnotu. Proto je vždy zapotřebí při plánování projektu postupovat tímto způsobem: identifikace potřebnosti změny -> definice výstupu z pohledu všech stakeholderů -> dekompozice výstupu na dílčí subvýstupy -> identifikace etap, které vedou k vytvoření (sub)výstupů -> identifikace jednotlivých aktivit (úkolů), které vedou ke splnění etap;
VII. Přizpůsobení metodiky PRINCE2 danému prostředí
• Je realizováno tímto dokumentem, detailněji pak v ZDP.
1.1.7.2 Témata
Témata PRINCE2 jsou implementována následujícím způsobem:
I. Business case
• Roli business casu plní IZ a NZVZ;
II. Organizace
• Řídicí struktura projektu je třístupňová – realizační tým, programový výbor, eskalační komise. Akceptaci předmětu plnění zajišťuje akceptační komise;
III. Kvalita
• Řízení projektů vychází z celosvětově uznávaných standardů (viz tento dokument);
• Jsou stanovena akceptační kritéria, která musejí být splněna, aby byl výstup akceptován jako odpovídající požadované kvalitě;
• Součástí každého projektu je etapa testování, a to jak na straně Dodavatele, tak na straně Zadavatele (příp. i na straně eu-LISA). Dodavatel vytváří testovací scénáře, podle nichž Zadavatele ověřuje správnou funkčnost. Testovací scénáře jsou sladěny s akceptačními kritérii. Výsledek testování je uveden v protokolu o provedení testů;
• Stav projektu je průběžně monitorován a reportován;
IV. Plány
• V souladu s principem řízení po etapách vytváří Dodavatel na počátku projektu rámcový Plán projektu s úrovní detailu na jednotlivé etapy. Vyšší úroveň detailu s rozpadem na jednotlivé aktivity je rozpracována pro aktuální etapu. Plán projektu je průběžně aktualizován a prezentován na vedení projektu;
• Plán projektu je tvořen těmito dokumenty: Harmonogram projektu, Personální zajištění projektu, Rizika projektu, Úkoly, Získané zkušenosti, Akceptační kritéria;
V. Rizika
• Jsou součástí Plánu projektu;
VI. Změny
• Změny v rámci mantinelů daných Objednávkou jsou řešeny formou dohody na programovém výboru (resp. na eskalační komisi, pokud vedení programu nedospěje ke shodě). Změny přesahující Objednávku (např. změna termínu dodání výstupu, změna ceny apod.) musejí být řešeny eskalační komisí, a to formou dodatku k dané Objednávce.
VIII. Postup prací
• Postup prací v projektu je pravidelně monitorován a reportován na programovém výboru;
1.1.7.3 Procesy
PRINCE2 definuje tyto procesy:
• zahájení projektu (předprojektová příprava),
• nastavení (iniciace) projektu,
• směřování (strategické řízení) projektu,
• kontrola (řízení) etapy,
• řízení dodávky produktu,
• řízení přechodu mezi etapami,
• ukončení projektu;
Vzhledem ke specifickému prostředí, v němž se Zadavatel pohybuje, jsou jeho projektové procesy vysoce customizované a nelze je na procesy PRINCE2 mapovat jedna ku jedné. Všechny výše vyjmenované procesy PRINCE2 však Zadavatel i Dodavatel ctí a jejich zásady jsou porůznu rozptýlené v předchozích kapitolách.
Příloha č. 2 Dohody
BEZPEČNOSTNÍ OPATŘENÍ PRO SMLUVNÍ VZTAHY
1. Úvod
Tato příloha č. 2 (dále také jen „Příloha“) Rámcové dohody o poskytování technické podpory a rozvoje softwaru systému hraniční kontroly KODOX (dále také jen „Dohoda“) popisuje bezpečnostní požadavky projektu Poskytování technické podpory a rozvoje IS KODOX.
2. Bezpečnostní požadavky
2.1. Účel
1. Tato Příloha Dohody stanoví způsoby a úrovně realizace bezpečnostních opatření pro Dodavatele a určuje vzájemný vztah odpovědnosti za zavedení a kontrolu bezpečnostních opatření mezi Zadavatelem a Dodavatelem.
2. Smluvní strany se dohodly, že pokud to bude potřebné ke splnění požadavků právních předpisů z oblasti bezpečnosti informací, uzavřou bez zbytečného odkladu po výzvě kterékoli Smluvní strany písemný dodatek k Dohodě zohledňující takové požadavky.
2.2. Obecné bezpečnostně provozní požadavky
Dodavatel se při poskytování plnění pro Zadavatele zavazuje plnit následující
povinnosti:
1. postupovat v souladu s účinnými právními předpisy, zejména pak požadavky vyplývajícími pro Dodavatele, na základě bezpečnostních politik stanovených systémem řízení bezpečnosti informací (ISMS) Zadavatele dle specifikace předmětu veřejné zakázky;
2. jmenovat nejpozději do tří pracovních dnů po dni účinnosti Dohody zodpovědnou kontaktní osobu pro potřeby zajištění plnění bezpečnostních požadavků vyplývajících z Dohody a této Přílohy a související komunikace mezi Smluvními stranami (dále také jen „Kontaktní osoba pro bezpečnost na straně Dodavatele“). Kontaktní osobu pro bezpečnost na straně Dodavatele sdělí písemně Zadavateli v téže lhůtě;
3. zajistit, aby Kontaktní osoba pro bezpečnost na straně Dodavatele nejpozději do 30 dnů od uzavření Dohody potvrdila písemně Zadavateli, že všechny osoby podílející se na poskytování plnění této Dohody za stranu Dodavatele a/nebo jeho poddodavatelé byli prokazatelně seznámeni s těmito Bezpečnostními požadavky;
4. dodržovat příslušná ustanovení bezpečnostních politik, metodik a postupů předaných Dodavateli Zadavatelem, k jejímuž dodržování se Dodavatel zavázal, pokud byl Dodavatel s takovými dokumenty nebo jejich částmi seznámen, a to bez ohledu na způsob, jakým byl s takovou dokumentací Zadavatele seznámen (např. školením, protokolárním předáním příslušné dokumentace dodavateli, elektronickým předáním prostřednictvím e-mailu či datovou schránkou, zřízením přístupu Dodavateli na sdílené úložiště aj.);
5. rozvíjet bezpečnostní povědomí svých zaměstnanců a příp. dalších osob, které se podílejí na plnění dle Dohody a průběžně je seznamovat s prováděnými nebo
plánovanými změnami. Zaměstnanci a další osoby na straně Dodavatele podílející se na plnění dle Dohody musí být prokazatelně seznámeni s platnými předpisy a bezpečnostními požadavky Zadavatele, a to ještě před zahájením jakékoli činnosti ze strany těchto osob pro Zadavatele v souvislosti s plněním této Dohody;
6. zaznamenávat a na vyžádání Zadavateli poskytnout veškeré podstatné okolnosti související s poskytovaným předmětem plnění dle Dohody (technické záznamy, organizační záznamy o školení, pověření apod.);
7. přidělovat svým jednotlivým pracovníkům oprávnění k výkonu činností a přísně při tom dodržovat bezpečnostní zásadu tzv. „potřeba vědět“ (need-to-know principle), tedy zejména dbát o to, aby byla minimalizována rizika nežádoucího přístupu k aktivům Zadavatele;
2.3. Oprávnění užívat data
1. Dodavatel je při poskytování plnění pro Zadavatele oprávněn nakládat s daty předanými Dodavateli Zadavatelem výhradně za účelem plnění předmětu Dohody, avšak vždy pouze v rozsahu nezbytném ke splnění předmětu Dohody.
2. Dodavatel se při poskytování plnění pro Zadavatele zavazuje nakládat s daty pouze v souladu s Dohodou a příslušnými právními předpisy.
2.4. Kontrola souladu s požadavky bezpečnosti
1. Dodavatel je srozuměn s prováděním hodnocení rizik, kontrolou a auditem zavedených bezpečnostních opatření ze strany Zadavatele v souvislosti s poskytovanou službou Dodavatelem.
2. Hodnocení, kontrola a audit probíhají v intervalech stanovených Zadavatelem nebo v případě vzniku kybernetického bezpečnostního incidentu v rámci poskytované služby nebo v případě, že se vznik bezpečnostního incidentu jeví jako pravděpodobný. Kontrola nebo audit mohou být provedeny v prostorách Dodavatele nebo jeho poddodavatele a Dodavatel má povinnost tyto kontroly a audity Zadavateli či Zadavatelem pověřené osobě umožnit či možnost jejich provedení v prostorách poddodavatele zajistit, přispět k nim a poskytnout Zadavateli či Zadavatelem pověřené osobě k jejich provedení maximální možnou součinnost, kterou lze po Dodavateli rozumně požadovat. Počet a frekvence kontrol ani auditů nejsou nijak omezeny.
3. Dodavatel je povinen po zavedení opatření provést také vlastní hodnocení rizik a kontrolu zavedených bezpečnostních opatření. Tato kontrola probíhá v pravidelných intervalech stanovených Zadavatelem, na žádost Zadavatele nebo v případě vzniku kybernetického bezpečnostního incidentu v rámci poskytované služby nebo v případě, že se vznik bezpečnostního incidentu jeví jako pravděpodobný. O výsledku kontroly podá Dodavatel Zadavateli bez zbytečného odkladu písemnou kontrolní zprávu.
2.5. Řetězení a řízení dodavatelů
Dodavatel se při poskytování plnění pro Zadavatele zavazuje plnit následující
povinnosti:
1. Dodavatel nezapojí do poskytování plnění dle této přílohy Rámcové dohody žádného dalšího poddodavatele bez předchozího konkrétního písemného povolení Zadavatele;
2. Dodavatel se zavazuje, že se bude řídit požadavky Zadavatele na řízení bezpečnosti informací a poskytne Zadavateli veškerou nezbytnou součinnost v otázkách řízení bezpečnosti informací a pokud využívá při poskytování plnění poddodavatele, zajistí, že bude Zadavateli poskytnuta veškerá nezbytná součinnost v otázkách řízení bezpečnosti informací také od těchto poddodavatelů;
3. Dodavatel je povinen předat Zadavateli kontaktní údaje všech osob dodávajících systémovou a technickou podporu pro řešení;
4. Pokud Dodavatel využívá při poskytování plnění poddodavatele, zavazuje se, že budou dodržovat bezpečnostní požadavky vč. požadavků na ochranu osobních údajů vyplývající z této Dohody. Dodavatel se zavazuje bezodkladně doložit Zadavateli na základě jeho výzvy smluvní dokumenty se svými poddodavateli, ze kterých bude vyplývat závazek poddodavatele poskytovat plnění v souladu s bezpečnostními požadavky vyplývajícími z této Dohody;
5. Dodavatel odpovídá za to, že jeho poddodavatelé nebudou jednat v rozporu s bezpečnostními požadavky vyplývajícími z této přílohy Rámcové dohody; v případě, že dojde k nedodržení těchto požadavků ze strany poddodavatele Dodavatele, považuje se každé takové nedodržení požadavků za porušení povinnosti Dodavatele dle této Dohody;
2.6. Povinnosti v řízení změn
1. Dodavatel se zavazuje v rozsahu předmětu plnění aktivně podílet na splnění povinností v oblasti řízení změn dle ISMS, zejména při analýze souvisejících rizik, přijímání opatření za účelem snížení všech nepříznivých dopadů spojených se změnami, aktualizaci bezpečnostní dokumentace, souvisejícím testováním a zajištění možnosti navrácení do původního stavu.
2. Dodavatel se minimálně zavazuje v rozsahu předmětu plnění na své straně přiměřeně reagovat na změny a upravit na své straně technická a organizační opatření tak, aby odpovídala novému stavu po provedení změny.
3. Dodavatel se zavazuje aktivně spolupracovat při testování významné změny.
2.7. Zvládání bezpečnostních událostí a incidentů
Dodavatel se při poskytování plnění pro Zadavatele zavazuje, že:
1. stanoví činnosti, role a jejich odpovědnosti a pravomoci vedoucí k rychlému a účinnému zvládání bezpečnostních událostí a incidentů, podle takto stanovených a popsaných pravidel bude postupovat, a bude hlásit všechny bezpečnostní události a incidenty neprodleně po jejich detekci Zadavateli prostřednictvím ohlašovacích kanálů Zadavatele, v případech, kdy situace nestrpí odklad telefonicky. Dále se zavazuje vyhodnotit informace o bezpečnostních událostech a incidentech a o těchto informacích, vzniklých bezpečnostních incidentech, vč. krátkodobých a dlouhodobých nápravných opatřeních nad všemi částmi řešení, které jsou ve správě Dodavatele, a rizicích souvisejících s ohrožením kontinuity činností vést záznamy a tyto uchovat pro jejich budoucí použití s ohledem na požadavky Zadavatele a legislativy ČR. Nastavená pravidla a postupy podléhají schválení Zadavatelem;
2. nastavená pravidla pro zvládání bezpečnostních incidentů budou respektovat požadavek na legalitu zajištění stop, tj. jejich původ a oprávněnost jejich získaní musí
být v souladu s platnými zákony a standardy tak, aby bylo možné jejich následné využití
v rámci forenzní analýzy a eventuální použití jako důkazní materiál;
3. provede analýzu příčin bezpečnostního incidentu a navrhne opatření s cílem zamezit jeho opakování v případě, že Dodavatel bezpečnostní incident zapříčinil nebo se na jeho vzniku podílel.
2.8. Informační povinnost a povinnosti při výměně informací
1. Dodavatel se během poskytování plnění pro Zadavatele zavazuje Zadavatele informovat o:
a) způsobu řízení rizik, zbytkových rizicích souvisejících s plněním dle Dohody a bez
zbytečného odkladu také o změnách ve způsobu řízení rizik;
b) významné změně ovládání Dodavatele podle zákona o obchodních korporacích nebo změně vlastnictví zásadních aktiv, popřípadě změně oprávnění nakládat s těmito aktivy, využívaných Dodavatelem k plnění na základě smluvního vztahu se Zadavatelem.
2. Dodavatel se během poskytování plnění pro Zadavatele zavazuje dostatečně zabezpečit veškerý přenos dat a informací z pohledu bezpečnostních požadavků na jejich důvěrnost, integritu a dostupnost před hrozbami v kybernetické bezpečnosti pokud nebude dohodnuto jinak.
2.9. Bezpečnost lidských zdrojů
1. Dodavatel připraví poučení a zajistí poučení všech stran podílejících se na poskytování předmětu plnění, jež se musí v průběhu dodávky dodržovat a zajistí jejich dodržování nasazením kontrolních a vynucovacích mechanismů. Rozsah poučení podléhá schválení Zadavatele.
2. Dodavatel se zaváže zajistit dostatečnou míru zastupitelnosti pro technické aspekty řešení (zajištění kontinuity dodávky, zastupitelnost pracovníků, zejména Kontaktní osoba pro bezpečnost na straně Dodavatele).
2.10. Fyzická ochrana a bezpečnost prostředí
1. Dodavatel se zavazuje dodržovat provozní řády budov (režimová opatření) a využívaných prostor, zejména pak v oblasti fyzické ochrany bezpečnostních zón, kde jsou umístěny komponenty technologických a komunikačních systémů, anebo datové nosiče (dále také jen „Pracoviště“).
2. Dodavatel se zavazuje, že na Pracovišti neponechá volně dostupná instalační, záložní nebo archivní média ani dokumentaci k předmětu plnění dle této Dohody.
2.11. Požadavky na Řízení přístupu
1. Dodavatel bere na vědomí, že přístup k datům, informacím či zařízením souvisejícím s předmětem Dohody, resp. Objednávky je možné povolit pouze konkrétním fyzickým osobám / zaměstnancům Dodavatele / poddodavatele Dodavatele zaevidované, a to na základě požadavku Dodavatele na přístup.
2. Dodavatel bere na vědomí, že přidělení oprávnění zaměstnanci Dodavatele musí být řízeno zásadou tzv. „potřeba vědět“ (need-to-know principle) a není nárokové.
3. Dodavatel se zavazuje, že udělený přístup nesmí být sdílen více zaměstnanci
Dodavatele nebo poddodavatele Dodavatele.
4. Dodavatel se zavazuje, že nebude instalovat a používat žádné nástroje, které nebyly předem písemně odsouhlaseny Zadavatelem.
5. Dodavatel se zavazuje, že nebude vyvíjet, kompilovat a šířit v jakékoliv části technologického nebo komunikačního systému programový kód, který má za cíl nelegální ovládnutí, narušení, nebo diskreditaci technologického nebo komunikačního systému nebo nelegální získání dat a informací. Dodavatel bere na vědomí, že přístup do interní sítě Zadavatele a/nebo k technologickým a komunikačním systémům Zadavatele bude realizován výhradně s využitím zařízení Zadavatele.
6. Dodavatel se zavazuje zajistit, aby osoby podílející se na poskytování plnění Zadavateli, kteří přistupují do interní sítě a/nebo technologického nebo komunikačního systému chránili autentizační prostředky a údaje k systémům Zadavateli. Dodavatel bere na vědomí, že v případě neúspěšných pokusů o autentizaci uživatele může být příslušný účet zablokován a řešen jako bezpečnostní incident ve smyslu příslušné řídící dokumentace a mohou být uplatněny příslušné postupy zvládání bezpečnostního incidentu (např. okamžité zrušení přístupu k informačním aktivům fyzických osob externího subjektu platí pro Dodavatele, pokud byl s takovou řídící dokumentací Zadavatele seznámen).
7. Dodavatel bere na vědomí, že postup zvládání bezpečnostního incidentu či skutečnosti vzniklé v důsledku porušení Bezpečnostních požadavků nebude posuzována jako okolnost vylučující odpovědnost Dodavatele za prodlení s řádným a včasným plněním předmětu Dohody, resp. Objednávky a nebude důvodem k jakékoli náhradě případné újmy Dodavateli či jiné osobě ze strany Dodavatele. Ostatní ustanovení ohledně odpovědnosti Dodavatele za prodlení obsažená v Dohodě nejsou tímto ustanovením dotčena.
2.12. Monitorování činností
1. Dodavatel bere na vědomí, že veškerá aktivita Dodavatele a jeho plnění realizované v rámci plnění předmětu Dohody, resp. Objednávky nebo s ním úzce související budou Zadavatelem průběžně a pravidelně monitorovány a vyhodnocovány s ohledem na obsah Dohody a interních dokumentů Zadavatele.
2.13. Předání a převzetí plnění
1. Dodavatel se zavazuje dodržovat Bezpečnostní požadavky i při předání a převzetí plnění dle této přílohy Rámcové dohody.
2. Zadavatel je oprávněn z důvodu nedodržení Bezpečnostních požadavků včetně požadavku na předání Bezpečnostní dokumentace odmítnout převzetí (části) plnění Dohody, resp. Objednávky.
2.14. Likvidace dat
Dodavatel se zavazuje plnit požadavky Zadavatele v oblasti likvidace dat (ať už dat na papírových médiích, dat zpracovávaných elektronicky nebo prostřednictvím jakýchkoli dalších nosičů dat).
2.15. Sankce
Sankce za porušení povinností plynoucích z bezpečnostních opatření jsou uvedeny v hlavním
textu Dohody.
Standardy pro vývoj aplikací
− externí dodavatelé
2019
aplikací –
externí
dodavatelé
Požadavky na vývoj
Zpracoval
Útvar PČR, PP, OIPIT
Počet příloh 0
Verze Datum | Autor | Komentář | Stav |
1.0 15. 7. 2019 | Draft | ||
1.1 12. 2. 2020 | Doplnění, grafické úpravy | Draft | |
1.2 30. 4. 2020 | Doplnění kap. Webové aplikace | Draft | |
Požadavky na vývoj aplikací − externí dodavatelé
Obsah
1. Účel dokumentu 3
1.1 Zdrojový kód 3
1.1.1 Programovací jazyk 3
1.1.2 Předávání zdrojového kódu 3
1.1.3 Externí komponenty 3
1.2 Nasazení aplikace 4
1.3 Číselníky 4
1.4 Autentizace a autorizace 4
1.5 Testování 4
1.6 Aplikační logování 5
1.7 Logování osobních údajů 5
1.8 Zpracování výjimek 5
1.9 Persistence a datová vrstva 5
1.10 Prezentační vrstva − technologie 6
1.10.1 Webové aplikace 6
1.10.2 Webové služby 6
Požadavky na vývoj aplikací − externí dodavatelé
1. Účel dokumentu
Tento dokument popisuje požadavky na vývoj a nasazení aplikací dodávaných externím dodavatelem
do prostředí PČR.
1.1 Zdrojový kód
1.1.1 Programovací jazyk Požadované:
• Programovací jazyk C# pro prostředí Microsoft.Net Framework 4.6.2 či vyšší nebo Microsoft
.Net Core s platným LTS (Long Term Support). Jiné technologie je možné využít pouze v odůvodněných případech, kdy to není technologicky možné nebo účelné. Např. komponenty běžící na specifickém hardware.
• Využívání principu IoC/DI
Doporučené:
• IoC kontejner − DryIoC
• ASP.NET MVC případně ASP.NET Core
1.1.2 Předávání zdrojového kódu Požadované:
• Zdrojový kód bude předáván a importován dodavatelem do systému správy verzí zdrojového kódu Azure DevOps Server (dále jen ADOS). Je možné použít TFVC či GIT.
• Každá předaná verze musí být schopna buildu a projít aktuální sadou unit testů
• Zdrojový kód bude předáván minimálně ve větvi MAIN/master, případně TEST/test.
• Statická analýza kódu
Doporučené
• V systému pro správu verzí zdrojového kódu používat minimálně tyto větve:
o Vývojová větev − DEV (TFVC) či dev (Git)
o Testovací větev − TEST (TFVC) či test (Git)
o Produkční větev − MAIN (TFVC) či master (Git)
• Zdrojový kód bude předáván minimálně ve větvi MAIN/master, případně TEST/test.
1.1.3 Externí komponenty
Požadované:
• Používat balíčkovací službu pro referenci a aktualizaci externích komponent (NuGet, Npm, Bower,…) tam, kde je to možné.
• Balíčky nebudou verzovány v rámci správy verzí, ale budou v součinnosti s objednatelem
vloženy do interních feedů.
• Používat pouze „release“ verze balíčků tak, aby bylo možné kdykoliv provést build a nasazení.
Požadavky na vývoj aplikací − externí dodavatelé
• Dodavatel musí zajistit, aby použití externích komponent bylo v souladu s jejich licenčními podmínkami.
Doporučené:
• Používat balíčkovací službu NuGet
1.2 Nasazení aplikace
Požadované:
• Aplikace bude nasazena prostřednictvím ADOS. Dodavatel navrhne a připraví šablony pro
build a release.
• Každá nasazená verze musí být jednoznačně identifikovatelná
• Pro potřeby nasazení budou definovány tzv. náhrady, které umožní nahrazení např. konfiguračních hodnot v závislosti na prostředí (testovací, produkční,…) na které bude aplikace nasazována.
• Součástí nasazení je i provedení automatizovaných testů
Doporučené:
• Konfigurační parametry .Net komponent nastavovat pomocí .config souborů
1.3 Číselníky
Požadované:
• Aplikace musí využívat centrální číselníkovou službu pro číselníky, které jsou dostupné
• Aplikace musí být připravena na využití centrální číselníkové služby pro číselníky, které ještě nejsou dostupné.
1.4 Autentizace a autorizace
Požadované:
• Autentizace uživatelů oproti Active Directory PČR
• Přihlašovací údaje uživatele nesmí být předávány v otevřené podobě
Doporučené:
• Integrovaná autentizace aktuálně přihlášeného uživatele
1.5 Testování
Požadované:
• Zdrojový kód vytvořený dodavatelem bude pokryt automatizovanými testy (unit, integrační) minimálně v rozsahu 70%. K měření bude použito IDE Visual Studio 2019 či vyšší, měřeny budou bloky kódu (blocks). Do pokrytí nebude započítáván testovací projekt.
• Pro testy bud použit testovací Framework xUnit.
Požadavky na vývoj aplikací − externí dodavatelé
Doporučené:
• Generování dat − AutoFixture
• Moqovací framework − Moq
• Typy testů:
o Výkonnostní
o Uživatelské
o Integrační
o Bezpečnostní
1.6 Aplikační logování
Zadavatel disponuje centrální webovou službou, která umožnuje přímé napojené logovacího frameworku na NLog. Zadavatel poskytne konfigurační nastavení pro napojení NLogu na tuto webovou službu.
Požadované:
• Aplikace musí zajistit ukládání logů do centrální logovací služby.
• Aplikace musí kategorizovat záznamy dle úrovně závažnosti a umožnit zapínání/vypínání logování jednotlivých úrovní.
• Aplikace musí do logu zaznamenávat všechny chybové stavy.
Doporučené:
• Aplikace používá pro logování framework NLog verze 4.5 či vyšší.
1.7 Logování osobních údajů
Zadavatel disponuje centrální webovou službou pro logování osobních údajů (LogCentr)
Požadované:
• Pokud aplikace obsahuje dotazy na osobní údaje, budou logovány do LogCentr, pokud zadavatel neurčí jinak.
1.8 Zpracování výjimek
Požadované:
• Chybový stav nesmí vést k pádu aplikace. Musí dojít zápisu chybového stavu do logu a korektnímu ukončení.
• Výjimky nesmí být ignorovány (prázdný catch blok).
• Nepoužívat try...catch pro validaci vstupních dat.
1.9 Persistence a datová vrstva
Požadované:
• Databázový server MS SQL Server. V odůvodněných případech výjimečně Oracle, PostgreSQL.
Požadavky na vývoj aplikací − externí dodavatelé
• Pokud bude použit MS SQL Server schéma databáze bude součástí zdrojových kódů ve formě
Sql Server database project.
• Nepoužívat uložené procedury, jejich použití je možné pouze v odůvodněných případech.
Doporučené:
o Framework Dapper Micro ORM
1.10 Prezentační vrstva – technologie
Požadované:
• Barevné schéma musí odpovídat standardům PČR (zadavatel disponuje vzorovými šablonami pro webové aplikace)
Doporučené:
• Uživatelské rozhraní formou webové aplikace
1.10.1 Webové aplikace Požadované:
• Kompatibilita s webovými prohlížeči:
o Internet Explorer 11
o Edge
o Chrome
Doporučené:
• Technologie − ASP.NET MVC případně ASP.NET Core
• Bootstrap framework
1.10.2 Webové služby Požadované:
• Komunikace musí být šifrovaná (HTTPS, SSL,…)
Doporučené:
• Doporučená technologie − Windows Communication Foundation, SOAP
Specifikace ceny za předmět plnění
Plnění A.1 | Technická podpora fixní | ||||||
Kód | Plnění | ks | Jednotka | Jednotková cena bez DPH | Jednotková cena s DPH | celková cena bez DPH | celková cena s DPH |
TP1 | Technická podpora dle definovaných SLA (A. 1) | 4 | rok | 8 430 265,75 Kč | 10 200 621,56 Kč | 33 721 063,00 Kč | 40 802 486,23 Kč |
TP1a | Technická podpora Vývojového prostředí ** | 4 | rok | 1,25 Kč | 1,51 Kč | 5,00 Kč | 6,05 Kč |
33 721 068,00 Kč | 40 802 492,28 Kč | ||||||
** Technickou podporou vývojového prostředí se rozumí náklady na údržbu HW infrastruktury a podporu SW licencí. Tato položka bude objednávána zároveň s TP1, dokud bude mít Dodavatel vývojové prostředí plně ve své režii. V případě, že bude plnohodnotné vývojové prostředí vytvořeno v prostorách Zadavatele na jeho infrastruktuře a budou mu přiděleny prostory, kde bude moci Dodavatel vyvíjet, nebude tato položka objednávána. | |||||||
Plnění A.2 + B | Rozvoj systému KODOX a technická podpora na objednávku | ||||||
Kód | Plnění | ks* | Jednotka | Jednotková cena bez DPH | Jednotková cena s DPH | celková cena bez DPH | celková cena s DPH |
R1 | Architekt řešení IS KODOX (IT architekt) | 350 | MD | 17 500,00 Kč | 21 175,00 Kč | 6 125 000,00 Kč | 7 411 250,00 Kč |
R2 | Projektový manažer | 200 | MD | 17 500,00 Kč | 21 175,00 Kč | 3 500 000,00 Kč | 4 235 000,00 Kč |
R3 | Databázový specialista | 400 | MD | 17 000,00 Kč | 20 570,00 Kč | 6 800 000,00 Kč | 8 228 000,00 Kč |
R4 | Vedoucí analytik | 550 | MD | 17 000,00 Kč | 20 570,00 Kč | 9 350 000,00 Kč | 11 313 500,00 Kč |
R5 | Senior software developer | 1700 | MD | 16 500,00 Kč | 19 965,00 Kč | 28 050 000,00 Kč | 33 940 500,00 Kč |
R6 | Aplikační architekt | 550 | MD | 17 000,00 Kč | 20 570,00 Kč | 9 350 000,00 Kč | 11 313 500,00 Kč |
R7 | Test manažer | 400 | MD | 17 000,00 Kč | 20 570,00 Kč | 6 800 000,00 Kč | 8 228 000,00 Kč |
R8 | Bezpečnostní specialista | 100 | MD | 17 500,00 Kč | 21 175,00 Kč | 1 750 000,00 Kč | 2 117 500,00 Kč |
* Jedná o předpokládaný počet ks MD nezbytných pro nacenění plnění A2+B, skutečné čerpání plnění A2+B bude objednáváno Zadavatelem do celkové hodnoty Rámcové dohody KODOX | 71 725 000,00 Kč | 86 787 250,00 Kč | |||||
Plnění C | Převzetí a předání systému - Handover | ||||||
Kód | Plnění | ks | Jednotka | Jednotková cena bez DPH | Jednotková cena s DPH | celková cena bez DPH | celková cena s DPH |
C | Předání systému novému dodavateli nebo zadavateli (Handover) | 1 | ks | 2 500 000,00 Kč | 3 025 000,00 Kč | 2 500 000,00 Kč | 3 025 000,00 Kč |
2 500 000,00 Kč | 3 025 000,00 Kč |
130 614 742,28 Kč
107 946 068,00 Kč
Celková cena bez DPH
Sazba DPH je 21%. Celková cena s DPH
Příloha č. 5 RD: realizační tým
1. Expert 1 - projektový manažer:
2. Expert 2 - Specialista na databázové systémy:
3. Expert 3 - specialista inspekčních systémů elektronických dokladů:
4. Expert 4 - specialista systémů SBC / ABC
Všechny osoby splňují podmínku jazykových znalostí - český jazyk na úrovni rodilého mluvčího. Všichni experti dokládají v nabídce v kapitole Přílohy: Příloha č. 3 Kvalifikace členů týmu.
Příloha č. 6 –„Vzor objednávky“
Vzor Objednávky (lze upravit dle konkrétních podmínek)
Č.j……………………………………….
Objednávka č….
k Rámcové dohodě č.j……………………….
(dále jen „Objednávka“)
Smluvní strany:
Česká republika – Ministerstvo vnitra
Sídlo: IČ: DIČ: Zastoupená: | Nad Štolou 936/3, PSČ 170 34, Praha 00007064 CZ00007064 …………………….., |
Bankovní spojení: | ……………………… |
Korespondenční adresa: | ………………………. |
(dále jen „Objednatel“) | |
a | |
………………………. | |
Sídlo: | ………………. |
IČO: | ………………. |
DIČ: | ………………. |
Zastoupená: | ………………. |
Bankovní spojení: | ………………. |
Kontaktní osoba: | ………………. |
Obchodní společnost zapsaná v obchodním rejstříku vedeném………. pod sp. zn………..
(dále jen „Dodavatel“)
(společně dále také jen „Smluvní strany“, nebo jednotlivě „Smluvní strana“)
Tato Objednávka je uzavřena v souladu s Rámcovou dohodou č.j……………. ze dne………..
(dále jen „Rámcová dohoda“).
1. PŘEDMĚT PLNĚNÍ
1.1. Podrobná specifikace předmětu plnění je uvedena v Příloze č. 1 této Objednávky (dále též jen
„Plnění“).
2. TERMÍN, MÍSTO A PODMÍNKY PLNĚNÍ
2.1. Dodavatel je povinen dodat Plnění do od účinnosti této Objednávky (v období
od………. do… ), pokud v Příloze č. 1 není stanoveno jinak.
2.2. Místem plnění je: …………………
2.3. Osoba oprávněná podepsat akceptační protokol za Objednatele: ………………….
3. CENA ZA PLNĚNÍ
3.1. Cena za Plnění dle této Objednávky činí ……………,- Kč bez DPH, ,- Kč s DPH.
Cena za jednotlivé položky Plnění je uvedena v příloze č. 2 této Objednávky.
3.2. Platební podmínky: …………………
4. OSTATNÍ UJEDNÁNÍ
4.1. Ostatní podmínky neuvedené v této Objednávce se řídí Rámcovou dohodou.
4.2. Dodavatel akceptuje tuto Objednávku svým podpisem.
4.3. Tato Objednávka je vyhotovena a podepsána elektronicky.
4.4. Tato Objednávka nabývá účinnosti dnem jejího zveřejnění v Registru smluv podle zákona č. 340/2015 Sb. v platném znění.
4.5. Nedílnou součástí této Objednávky jsou následující přílohy: Příloha č.1 – „Specifikace předmětu plnění“
Příloha č.2. – „Specifikace ceny“
Objednatel: Dodavatel:
………………….. …………………..
Česká republika – Ministerstvo vnitra ……………………..
Zástupce: ………… Zástupce: …………
Příloha č. 7 –„Vzor akceptačního protokolu“
Akceptační protokol
PROJEKT
Název projektu | <doplnit> |
Název veřejné zakázky | <doplnit> |
Rámcová dohoda / Smlouva č. | <doplnit> |
Prováděcí smlouva / Objednávka č. | <doplnit> |
Zpracovatel protokolu | Za Objednatele: <doplnit> Za Dodavatele: <doplnit> |
Číslo protokolu | <doplnit> |
SMLUVNÍ STRANY
OBJEDNATEL | |
Název | Česká republika – Ministerstvo vnitra |
Adresa | Nad Štolou 936/3, 170 34 Praha |
IČO | 00007064 |
Odpovědná osoba | <doplnit> |
Funkce | <doplnit> |
DODAVATEL | |
Název | <doplnit> |
Adresa | <doplnit> |
IČO | <doplnit> |
Odpovědná osoba | <doplnit> |
Funkce | <doplnit> |
PŘEDMĚT AKCEPTACE
Předmět dodávky, plnění | Doplňte přesné znění předmětu dodávky dle smlouvy |
Cena akceptovaného plnění | xxx Kč bez DPH, xxx Kč s DPH |
AKCEPTAČNÍ KRITÉRIA
V rámci této tabulky vyplňte akceptační kritéria, která jsou detailněji popsána v Technické specifikaci, sekce Akceptace. Akceptačním kritériem může být předání díla do provozu, akceptační testy, předání výstupů atp. V případě existence výstupů k akceptačnímu kritériu, vyplňte číslo výstupu či výstupů z tabulky „seznam výstupů“, které jsou s daným akceptačním kritériem jakkoli spjaty. V případě, že výstup ke kritériu neexistuje (například jde o předání zařízení), ponechte pole prázdné. Odkaz na předávací protokol následně uveďte v seznamu dodaných zařízení.
Č. | Akceptační kritérium | Splněno | Odkaz na výstup |
1. | <doplnit> | <ano/ne/s výhradou> | <doplnit> |
2. | <doplnit> | <ano/ne/s výhradou> | <doplnit> |
Příloha č. 7 –„Vzor akceptačního protokolu“
3. | <doplnit> | <ano/ne/s výhradou> | <doplnit> |
ČERPÁNÍ ČLOVĚKODNŮ
Jméno | Role | Sazba | Akceptovaný počet ČD | Celkem Kč bez DPH |
<doplnit> | <doplnit> | <doplnit> | <doplnit> | <doplnit> |
<doplnit> | <doplnit> | <doplnit> | <doplnit> | <doplnit> |
PAUŠÁLNÍ (FIXNÍ) ČERPÁNÍ
Měsíc | Popis činnosti | Cena |
1. | <doplnit> | <doplnit> |
2. | <doplnit> | <doplnit> |
3. | <doplnit> | <doplnit> |
Celkem | <součet> |
SEZNAM DODANÝCH ZAŘÍZENÍ, ROZŠÍŘENÍ A PŘÍSLUŠENSTVÍ
Č. | Popis | Cena/ks | Počet ks | Číslo produktu | Celková cena | Číslo před. protokolu |
1. | <doplnit> | <doplnit> | <doplnit> | <doplnit> | <doplnit> | <doplnit> |
2. | <doplnit> | <doplnit> | <doplnit> | <doplnit> | <doplnit> | <doplnit> |
SEZNAM VÝSTUPŮ
Č. | Název a popis výstupu | Označení přílohy (číslo, název souboru) | Číslo před. protokolu |
1. | <doplnit> | <doplnit> | <doplnit> |
SEZNAM ZÁVAD
Č. | Typ závady | Popis závady | Požadovaný způsob a termín vyřízení | Odkaz na výstup č. | Zodpovědná osoba |
1. | <doplnit> | <doplnit> | <doplnit> | <doplnit> | <doplnit> |
2. | <doplnit> | <doplnit> | <doplnit> | <doplnit> | <doplnit> |
Po odstranění závady proběhne nová akceptační procedura.
TYPY ZÁVAD
A – Kritická závada
B – Významná závada
C – Ostatní závady a incidenty
Detaily k jednotlivým typům závad jsou popsány ve Specifikaci předmětu plnění.
ZÁVĚR AKCEPTACE (hodící se zaškrtne)
☐ | Akceptuji. |
☐ | Akceptuji s výhradou na základě závad uvedených v Seznamu závad. |
□ | Neakceptuji na základě závad uvedených v Seznamu závad. |
Příloha č. 7 –„Vzor akceptačního protokolu“
SCHVALOVACÍ TABULKA
OBJEDNATEL | Jméno a příjmení | Datum | Podpis |
<doplnit> | <doplnit> | ||
<doplnit> | <doplnit> |
DODAVATEL | Jméno a příjmení | Datum | Podpis |
<doplnit> | <doplnit> |