RÁMCOVÁ DOHODA

RÁMCOVÁ DOHODA

Technická podpora a rozvoj aplikace NS-VIS

Číslo smlouvy objednatele: PPR-20262-20/ČJ-2020-990656

Číslo smlouvy dodavatele: CWX036

Smluvní strany:

Česká republika – Ministerstvo vnitra

Sídlo: Nad Xxxxxx 000/0, XXX 000 00, Xxxxx

IČO: 00007064

DIČ: CZ00007064

Zastoupená: plk. Mgr. Xxxxxx Xxxxxxxx, ředitelem Ředitelství pro podporu

výkonu služby Policejního prezidia České republiky

Korespondenční adresa: Policejní prezidium ČR, Ředitelství pro podporu výkonu služby,

xxxxxxxx xxxxxxxx 00/ XXXX, 000 00 Xxxxx 0

(dále jen „Objednatel“) a

IBM Česká republika, spol. s.r.o.

Sídlo: V Xxxxx 0000/0, 000 00 Xxxxx 0

IČO: 14890992

DIČ: CZ14890992

Zastoupená: jednatelem společnosti

Bankovní spojení: ČSOB Xxxxx 0, Xx Xxxxxxx 00, Xxxxx 0

Číslo účtu: 56733/0300

Obchodní společnost zapsaná v obchodním rejstříku vedeném Městským soudem v Praze pod sp. zn C 692

(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“), a příslušnými ustanoveními 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“) a zákona č. 181/2014 Sb., o kybernetické bezpečnosti a o změně souvisejících zákonů (dále jen „zákon o kybernetické bezpečnosti“) a jeho prováděcích předpisů tuto

Rámcovou dohodu

- o poskytování technické podpory a rozvoje aplikace NS-VIS

(dále jen „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 “Technická podpora a rozvoj aplikace NS-VIS – rámcová dohoda“ č.j. PPR-20262/ČJ- 2020-990656 (dále též „Veřejná zakázka“).

2. Dílčí veřejné zakázky budou zadávány postupem dle ustanovení § 132 ZZVZ, na základě něhož budou s Dodavatelem uzavřeny jednotlivé Prováděcí smlouvy. Tato Rámcová dohoda vymezuje obecné obchodní podmínky v budoucnu uzavřených Prováděcích smluv. Tato Xxxxxxx dohoda se uzavírá s jedním Dodavatelem.

3. Účelem této Dohody je zejména zajištění technické podpory provozu NS-VIS, jeho rozvoje a nezbytného vývoje v rozsahu aplikační podpory, garance funkčnosti, rozvojových aktivit vynucených jak vnitřními změnami, tak vnějšími (např. požadavky vyplývající z členství v Evropské unii a schengenském prostoru).

1. VYMEZENÍ POJMŮ

Pro účely této Dohody a jednotlivých Prováděcích smluv se Smluvní strany dohodly na následujícím obsahovém vymezení jednotlivých pojmů:

„Člověkoden“ je základní měrnou jednotkou pro fakturaci plnění dle této Dohody. Jeden člověkoden představuje 8 člověkohodin, přičemž se účtuje každá započatá půlhodina, pokud není stanoveno jinak.

„NS-VIS“ Národní součást VIS (dále „NS-VIS“) je v provozu od 11. 10. 2011 a její využívání má přímý vliv na zajištění bezpečnosti ČR i celé EU. Proto byl systém NS-VIS v rámci zákona č. 181/2014 Sb., o kybernetické bezpečnosti, a v rámci návazných vyhlášek č. 82/2018 Sb., o kybernetické bezpečnosti, a č. 317/2014 o významných informačních systémech a jejich určujících kritériích, zařazen do seznamu informačních systémů kritické informační infrastruktury. Dostupnost systému NS-VIS je obecně definována na 99,7 % (HA – High Availability) s tím, že vybrané služby mají požadovanou dostupnost vyšší.

2. PŘEDMĚT DOHODY

2.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í:

I. Plnění A – Technická podpora aplikace NS-VIS

a) paušální služby technické podpory (A1)

b) variabilní služby technické podpory (A2)

(dále také jen „Plnění A1“ resp. „Plnění A2“), blíže definováno v Příloze č. 1;

II. Plnění B – Rozvojové aktivity aplikace NS-VIS

(dále také jen „Plnění B“), blíže definováno v Příloze č. 1;

III. Plnění C – Převzetí systému – řízený přechod při změně dodavatele

(dále také jen „Plnění C“), blíže definováno v Příloze č. 1; (souhrnně dále též „Předmět plnění“).

2.2. Podrobná specifikace Předmětu plnění je uvedena v Příloze č. 1 této Dohody.

2.3. Objednatel se za řádně poskytnuté plnění zavazuje Dodavateli zaplatit cenu sjednanou v této Dohodě a podrobně specifikovanou v Příloze č. 2 této Dohody.

3. POSTUP PŘI UZAVÍRÁNÍ PROVÁDĚCÍCH SMLUV

3.1. Na základě této Rámcové dohody budou zadány dílčí veřejné zakázky, jejichž výsledkem bude uzavření Prováděcí smlouvy, postupem stanoveným touto Dohodou, a to, následujícím postupem:

Objednatel písemně vyzve Dodavatele k podání nabídky. Výzva k podání nabídky musí obsahovat alespoň tyto náležitosti:

a) identifikační údaje Objednatele;

b) podrobnou specifikaci požadovaného plnění (V případě plnění A.2 může být podrobnou specifikaci plnění míněno stanovení konkrétního finančního limitu na čerpání variabilních služeb dle ceníku obsaženého v Dohodě v období stanoveném v příslušné Prováděcí smlouvě s detailní specifikací způsobu objednávání jednotlivých služeb. )

c) místo a dobu požadovaného plnění;

d) podpis a označení osoby oprávněné podat výzvu;

e) číslo výzvy;

f) lhůtu, způsob a místo pro podání nabídek.

3.2. Dodavatel je povinen na základě výzvy k podání nabídky doručit Objednateli ve lhůtě stanovené ve výzvě svou nabídku. Minimální lhůta stanovená pro doručení nabídky je 5 dní od doručení výzvy Dodavateli. Nabídka Dodavatele bude obsahovat vyplněný návrh Prováděcí smlouvy, jejíž vzor je uveden v Příloze č. 3 této Dohody.

3.3. 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.

4. CENA ZA PLNĚNÍ

4.1. Objednatel má povinnost zaplatit Dodavateli za řádně poskytnuté plnění sjednanou cenu.

4.2. Podrobné určení ceny pro Plnění A, Plnění B, Plnění C včetně rozpisu cen jednotlivých položek každého plnění, je uvedeno v Příloze č. 2 této Dohody.

4.3. Celková cena plnění dle Prováděcích smluv uzavřených dle této Dohody (tj. součet smluvních cen uzavřených prováděcích smluv) nesmí přesáhnout 241 876 800,- Kč bez DPH (dvě stě čtyřicet jedna milionů osm set sedmdesát šest tisíc osm set korun českých), 292 670 928,- Kč s DPH (dvě stě devadesát dva milionů šest set sedmdesát tisíc devět set dvacet osm korun českých).

4.4. Smluvní strany se dohodly, že cena za plnění dle konkrétní Prováděcí smlouvy je cenou konečnou, nejvýše přípustnou, nepřekročitelnou. Pokud není Rámcovou dohodou, nebo příslušnou Prováděcí smlouvou 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.

4.5. Cena plnění bude upravena o případnou zákonnou procentní změnu DPH, a to ode dne účinnosti změny.

4.6. Veškeré ceny dohodnuté v této Dohody a Prováděcích smlouvách jsou ceny v korunách

českých.

5. PLATEBNÍ PODMÍNKY

5.1. Dodavatel je povinen vystavit platební doklad (tzv. fakturu) do 10 dnů ode dne podpisu příslušného závěrečného akceptačního protokolu oběma Smluvními stranami, v příslušné Prováděcí smlouvě může být upraveno, že Dodavatel je oprávněn vystavit fakturu i za dílčí plnění, a to zejména v případě Plnění A, kdy je Dodavatel oprávněn vystavit fakturu za poskytnuté dílčí plnění, a to vždy za uplynulé kalendářní čtvrtletí, na základě dílčího akceptačního protokolu. V případě Plnění A 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 smlouvy, když datem uskutečnění zdanitelného plnění je poslední den poskytnutého plnění v daném čtvrtletí.

5.2. 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.

5.3. 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.

5.4. Adresa Objednatele pro doručení daňového dokladu je: Policejní prezidium ČR, Ředitelství pro podporu výkonu služby,

Strojnická 27, xxxxxxxx xxxxxxxx 00/XXXX, 000 00 Xxxxx 0

5.5. 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 Prováděcí smlouvě v prospěch bankovního účtu Dodavatele uvedeného v Prováděcí smlouvě.

5.6. Přílohou faktury za poskytnuté plnění je 1x originál a 1x kopie 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.

5.7. Akceptační protokol musí obsahovat alespoň:

- označení čísla Dohody a Prováděcí smlouvy;

- předmět poskytnutého plnění;

- datum převzetí, resp. akceptace;

- identifikace osob pověřených akceptační protokol za Smluvní strany podepsat;

5.8. Objednatel neposkytuje Dodavateli finanční zálohy na předmět plnění.

6. DOBA, MÍSTO A PODMÍNKY PLNĚNÍ DODÁVEK

6.1. Místem plnění dle této Dohody jsou lokality Objednatele umístněné zejména v Praze, které budou Dodavateli specifikovány v konkrétní Prováděcí smlouvě.

6.2. Řádně a včas dodaný Předmět plnění dle odst. 2.1. 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á Prováděcí smlouva 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é Prováděcí smlouvě, a to zejména v případě Plnění B a Plnění C.

6.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í a popisu adaptérů pro komunikaci, návody na obsluhu a údržbu, záruční listy, uživatelský manuál, a to v českém jazyce.

6.4. Termíny plnění budou upraveny v konkrétních Prováděcích smlouvách.

7. ZÁRUČNÍ PODMÍNKY A ODPOVĚDNOST ZA VADY

7.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.

7.2. Dodavatel poskytuje Objednateli záruku na předmět plnění na dobu, tak jak bude specifikováno v jednotlivých Prováděcích smlouvách a v zadávacích podmínkách veřejné soutěže, jinak po dobu 6 měsíců od řádného předání. 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 jednotlivých Prováděcích smlouvách.

7.3. 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í.

7.4. 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.

7.5. 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.

7.6. 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.

7.7. Objednatel uplatní požadavek na odstranění vady na helpdesk Dodavatele, pokud se Smluvní strany nedomluví jinak.

7.8. Uplatněním nároku z odpovědnosti za vady není dotčen nárok Objednatele na náhradu újmy.

7.9. 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.

7.10. 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.

7.11. Další podmínky záruky mohou být stanoveny v Příloze č. 1 Dohody.

8. SANKCE

8.1. V případě prodlení Dodavatele s poskytnutím plnění dle této Dohody vzniká Objednateli nárok na smluvní pokutu ve výši 0,15 % z celkové ceny nedodaného plnění s DPH dle příslušné Prováděcí smlouvy, a to za každý den prodlení, pokud není v Příloze č. 1 Dohody uvedeno jinak.

8.2. Pokud není v Dohodě, nebo v textu příloh, v příslušné Prováděcí smlouvě 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í. Příloha č. 1 stanoví další sankce za porušení povinností Dodavatele.

8.3. 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í.

8.4. 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 100 000 000,- Kč (sto 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.

8.5. Ú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ší.

9. PODDODAVATELÉ

9.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.

9.2. Za plnění poddodavatelů Dodavatel odpovídá jako za své plnění, včetně odpovědnosti za důsledky vzniklé.

10. MLČENLIVOST A DŮVĚRNÉ INFORMACE

10.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.

10.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 čl. 10 Dohody, o této skutečnosti Xxxxxxxxxx informuje.

10.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.

10.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í uvedených v článku 10 Dohody 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.

10.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.

10.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.

10.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.

10.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.

10.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.10. V případě porušení povinností dle tohoto článku č. 10 Dohody je Xxxxxxxxx povinen zaplatit Objednateli smluvní pokutu ve výši 500 000,- Kč za každé porušení.

11. ÚČINNOST DOHODY A ODSTOUPENÍ

11.1. Rámcová dohoda se uzavírá na dobu určitou, a to na osm (8) let od účinnosti Dohody, nebo do vyčerpání celkové ceny plnění ve výši 241 876 800 Kč bez DPH (vyčerpáním se rozumí součet jednotlivých smluvních cen dle uzavřených Prováděcích smluv) dle toho, která skutečnost nastane dříve. Skončení účinnosti této Dohody nemá vliv na účinnosti jednotlivých, již uzavřených Prováděcích smluv.

11.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.

11.3. Rámcovou dohodu, resp. Prováděcí smlouvu 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.

11.4. Každá ze smluvních stran může od této Dohody, resp. Prováděcí smlouvy 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 Prováděcí smlouvy nastávají dnem doručení oznámení o odstoupení příslušné Smluvní straně.

11.5. Smluvní strany jsou oprávněné odstoupit od této Dohody, resp. Prováděcí smlouvy 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.

11.6. Objednatel je dále oprávněn odstoupit od Dohody, resp. Prováděcí smlouvy, jestliže 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í; 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.

11.7. Objednatel má právo odstoupit od Dohody, resp. Prováděcí smlouvy také tehdy, pokud 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.

12. KOMUNIKACE SMLUVNÍCH STRAN, OPRÁVNĚNÉ OSOBY

12.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, resp. Prováděcí smlouvou nebo jimi pověřených zástupců. Osoby oprávněné podepsat příslušné akceptační protokoly budou určeny v konkrétní Prováděcí smlouvě.

12.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:

za Dodavatele:

za Objednatele:

12.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.

13. LICENCE

13.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 aplikace NS-VIS 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ň 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 NS- VIS 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 NS-VIS (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.

- Pro vyloučení pochybností Dodavatel bere na vědomí, že účelem této Dohody není dodávka standardního software, ani to Objednatel nepředpokládá.

g) Objednatel nemá povinnost licenci využít.

14. POJIŠTĚNÍ

14.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.

14.2. Dodavatel je povinen prokázat platnou pojistnou smlouvu, kdykoliv na požádání Objednatele v průběhu trvání této Dohody.

14.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.

14.4. Nesplnění povinnosti Dodavatele dle tohoto článku Dohody bude považováno za podstatné porušení této Dohody.

14.5. V případě porušení povinností dle tohoto článku je Dodavatel povinen zaplatit smluvní pokutu ve výši 1 000 000,- Kč.

15. INFLAČNÍ DOLOŽKA

15.1. S ohledem na skutečnost, že v případě Plnění A1 dle této Dohody se předpokládá plnění přesahující delší časové období, tak Smluvní strany se dohodly, že Dodavatel je v případě Plnění A1 dle této Dohody oprávněn upravit smluvní cenu plnění s účinností od 1. dubna každého kalendářního roku následujícího po roce, v němž uplynou tři (3) roky od účinnosti Dohody, o přírůstek průměrného ročního indexu spotřebitelských cen (dále jen „míra inflace“) vyhlášený Českým statistickým úřadem za předcházející kalendářní rok.

15.2. Smluvní strany pro vyloučení pochybností uvádí, že v případě záporné míry inflace se cena nesnižuje.

15.3. Zvýšení ceny dle předchozích odstavců je platné od okamžiku doručení písemného oznámení Dodavatele o zvýšení ceny Objednateli. Oznámení musí obsahovat míru inflace, zvýšenou cenu a podrobnosti výpočtu zvýšení. Nebude-li oznámení o zvýšení ceny doručeno Objednateli do 1 měsíce od oficiálního oznámení míry inflace v příslušném roce, právo na uplatnění zvýšení ceny v daném kalendářním roce zanikne.

16. PRAVIDLA PUBLICITY A POVINNOSTI DODAVATELE

16.1. Pokud je to uvedeno v příslušné Prováděcí smlouvě, plnění dle této Dohody může být spolufinancováno ze zdrojů Evropské unie. V takovém případě je nutné dodržovat podmínky stanovené v čl. 16 Dohody.

16.2. Na faktuře musí být uveden název projektu a registrační číslo, které je uvedeno v příslušné Prováděcí smlouvě.

16.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 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 této Dohody.

16.4. Dodavatel je povinen poskytnout součinnost oprávněným kontrolním orgánům při výkonu kontroly (auditu). Dodavatel je povinen archivovat dokumentaci související s plněním dle této Dohody po dobu 10 let od předání plnění dle této Dohody, nebo minimálně do konce roku 2031, a to zejména originální vyhotovení Dohody včetně jejích dodatků, originály účetních dokladů a dalších dokladů vztahujících se k realizaci předmětu Dohody 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, 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. Prodávající 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.

16.5. Dodavatel je povinen všechny písemné zprávy, písemné výstupy a prezentace opatřit vizuální identitou projektů. Pravidla vizuální identity vycházejí z Horizontálního nařízení a z Prováděcího nařízení Komise (EU) č. 1049/2014 ze dne 30. července 2014, o technických vlastnostech informačních a propagačních opatřeních, případně jiného relevantního dokumentu s ohledem na konkrétní projekt.

V případě, že projekt je financován z NP ISF, tak povinné prvky vizuální identity NP ISF jsou:

- znak EU a odkaz „Evropská unie“;

- odkaz „Fond pro vnitřní bezpečnost“;

- prohlášení, které zdůrazňuje přidanou hodnotu příspěvku Evropské unie, uvedením formulace „financováno Evropskou unií“ případně „spolufinancováno Evropskou unií“;

- odkaz na národní program Fondu pro vnitřní bezpečnost.

Splnění povinnosti vizuální identity příjemce dosáhne zejména využitím jednoho z logotypů uvedených v Příručce pro žadatele a příjemce Fondu pro vnitřní bezpečnost (který již obsahuje logo, odkaz na Evropskou unii, odkaz na fond i zdůraznění přidané hodnoty příspěvku EU) a zároveň uvedením věty „Projekt [Název projektu + jeho registrační číslo] je financován v rámci národního programu Fondu pro vnitřní bezpečnost“.

Povinné prvky vizuální identity jsou ke stažení na webových stránkách odpovědného orgánu:

xxxx://xxx.xxxx.xx/xxxxxx/xxxxxxxxxxx-x-xxxxxxxx.xxxx?xxX0xxxX00Xx%0x%0x.

V případě změny v oblasti podmínek publicity resp. jiných podmínek vyplývajících ze skutečnosti, že plnění ze smlouvy je financováno ze zdrojů z Evropské unie, Objednatel si vyhrazuje tyto podmínky uvést v příslušné Prováděcí smlouvě. Dodavatel je povinen stanovené podmínky dodržovat.

17. OBECNÁ USTANOVENÍ

17.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.

17.2. Smluvní strany se výslovně dohodly, že Dodavatel odpovídá Objednateli za újmu majetkovou i za újmu nemajetkovou, avšak maximálně do výše 200 000 000,- Kč (slovem dvě stě milionů korun českých).

17.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í.

17.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.

17.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.

17.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.

17.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.

17.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.

17.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.

17.10. Dodavatel se zavazuje, že při poskytování plnění dle této Dohody bude dodržovat bezpečnostní politiky Objednatele. Aktuálně platná verze bezpečnostních politik Objednatele bude Dodavateli předána při uzavření Dohody. Dodavatel bere na vědomí, že je vázán i dalšími, aktualizovanými verzemi těchto bezpečnostních politik, 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.

18. ZÁVĚREČNÁ USTANOVENÍ

18.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).

18.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.

18.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.

18.4. Smluvní strany vylučují aplikaci ustanovení § 557 občanského zákoníku na tuto Dohodu.

18.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é.

18.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.

18.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.

18.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.

18.9. Tato Dohoda může být měněna pouze formou číslovaných písemných dodatků. Za písemnou formu nebude pro tento účel považována výměna e-mailových či jiných elektronických zpráv.

18.10. Zadávací podmínky zadané Veřejné zakázky a smluvní podmínky sjednané touto Dohodou jsou bezvýhradně závazné pro Prováděcí smlouvy. Při zadávaní zakázek formou Prováděcích smluv 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ě.

18.11. Tato Xxxxxx je vyhotovena tak, že je podepsána oběma Smluvními stranami elektronickým podpisem s tím, že zároveň Objednatel obdrží 1 (jeden) stejnopis s platností originálu podepsaný oběma Smluvními stranami vlastnoručně a Dodavatel obdrží 1 (jeden) stejnopis s platností originálu podepsaný oběma Smluvními stranami vlastnoručně, tj. ne elektronicky.

18.12. Nedílnou součástí této Dohody jsou následující Přílohy:

Příloha č. 1 – „Specifikace Plnění“

Příloha č. 2 – „Specifikace ceny za předmět plnění“ Příloha č. 3 – „Vzor prováděcí smlouvy“

Příloha č. 4 – „Bezpečnostní opatření MV“

V Praze dne …………. V Praze dne …………….

D Xxxxx

Objednatel:

OSVAL

Digitálně podepsal XXXXXX Xxxxx

Dodavatel:

Datum: 2020.11.13

…

11:06:41 +01'00'

………………….. …………

Ministerstvo vnitra – Česká republika IBM Česká republika, spol. s.r.o.

Zástupce: plk. Xxx. Xxxxx Xxxxxx Xxxxxxxx:

Funkce: ředitel Ředitelství pro podporu Funkce: jednatel výkonu služby Policejního prezidia ČR

Příloha č.1: Specifikace plnění

Slovník zkratek a pojmů

Zkratka nebo pojem	Význam
BCP	Business Continutity Plan - plán zajištění kontinuty provozu
BIA	Business Impact Analysis - analýza dopadů
CA	Centrální aplikace
CIS	Cizinecký informační systém, jedná se o IS PČR
CMS	Centrální místo služeb
COTS	Commodity of the Shelf - v dokumentech se užívá ve smyslu programového vybavení dodávaného jako standardní komerční SW
CSML	Centrální server mobilní lustrace
CS-VIS	Central System – Visa Information System.
CSL	Centrální systém lustrace
Dossier	Virtuální složka centrální části VIS, ve které jsou po určitou dobu uloženy všechny žádosti o udělení schengenského víza jednoho žadatele
DRP	Disaster Recovery Plan - plán obnovy provozu po havárii
EES	Systém vstup výstup (Entry-Exit System)
ETIAS	Systém pro cestovní informace a povolení
EU	Evropská unie
euLISA	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“)
ESB	Enterprise aplikací	Service	Bus,	infrastruktura	pro	integraci
EVC2	Evidence cizinců v.2. Systém pro zpracování a vydávání víz na MZV ČR. Bývá označován také jako MZV-EVC2 nebo Víza ČR v.2. Oficiální název na MZV ČR je Víza ČR v. 2.
HA	High Availability, vysoká dostupnost
IAŘ	interní akty řízení - soubor interních norem PČR
IZ	Investiční záměr
ICD/DTS	Interface Control Document / Detailed Technical Specification – soubor dokumentů definujících komunikační rozhraní mezi NS-VIS a CS-VIS.
ICIS	IS Interpol, jedná se o IS PČR
ISOP	IS Opatření, jedná se o IS PČR
KA	Klientská aplikace

Zkratka nebo pojem	Význam
KII	Kritická informační infrastruktura ve smyslu ZKB a VKB
LBC	Level of Business Continuity - určuje minimální úroveň funkčnosti procesu poté, co je po přerušení (např. v důsledku selhání zařízení) obnoven
MDTL	Maximum Tolerable Data Loss - maximální přijatelná ztráta
MRSL	Minimal Required Service Level - minimální úroveň poskytování služeb
MTO	Maximum Tolerable Outage - maximální přijatelný interval výpadku
MRZ	Xxxxxxxx čitelná zóna dokladu
MV (ČR)	Ministerstvo vnitra (České republiky)
MZV	Ministerstvo zahraničních věcí
NS-VIS	Národní Vízový informační systém
NZVZ	Návrh na zadání veřejné zakázky
OIPIT PP ČR	Odbor informatiky a provozu informačních technologií Policejního prezidia České republiky
PATROS	Pátrání po osobách, jedná se o IS PČR
PČR	Policie České republiky
RPO	Recovery Point Objective - cíl obnovy činností
RTO	Recovery Time Objective - doba obnovy činnosti
SIS II	Schengenský informační systém, jedná se o IS PČR
SOA	Service Oriented Architecture. Architektura založená na sestavení systému ve formě spolupracujících služeb
SPOC	Single point of contact - jediný kontaktní bod (např. při komunikaci centrum-MS nebo při komunikaci v rámci helpdesku mezi Dodavatelem a Objednatelem)
TESTA-NG	Šifrovaná síť zprostředkující mimo jiné komunikaci mezi národními součástmi a centrální součástí VIS
VIS Mail	národní součást evropského systému zasílání zpráv a doplňkových informací k žádosti o udělení víza
VKB	vyhláška č. 82/2018 Sb., o kybernetické bezpečnosti
ZKB	zákon č. 181/2014 Sb., o kybernetické bezpečnosti
ZS	Zpravodajské služby
ZU	Zastupitelský úřad

1 Vízový informační systém - kontext

1.1 Právní základ

Stávající právní základ provozu a využívání VIS sestává z několika právních aktů EU:

1.1.1 Rozhodnutím Rady 2004/512/ES

ze dne 8. června 2004 „O zřízení Vízového informačního systému“.

1.1.2 Nařízením Evropského parlamentu a Rady (ES) č.767/2008

ze dne 9. července 2008 „O Vízovém informačním systému a o výměně údajů o krátkodobých vízech mezi členskými státy (nařízení o VIS)“

1.1.3 Rozhodnutím Rady 2008/633/SVV

„O konzultačním přístupu určených orgánů členských států a Europolu do Vízového informačního systému pro účely prevence, odhalování a vyšetřování teroristických trestných činů a jiných závažných trestných činů“

1.1.4 Nařízení Evropského parlamentu a Rady č. 810/2009

ze dne 13. července 2009 „O kodexu Společenství o vízech (vízový kodex)“

1.1.5 Nařízení Evropského parlamentu a Rady č. 1155/2019

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.1.6 Připravované evropské legislativní akty

V souvislosti s vývojem (aktualizací) legislativních aktů bude v době trvání Rámcové dohody schválen a vydán nový právní základ nahrazující Nařízení Evropského parlamentu a Rady (ES) č.767/2008 ze dne 9. července 2008 „O Vízovém informačním systému a o výměně údajů o krátkodobých vízech mezi členskými státy (nařízení o VIS)“

1.2 Cíl sledovaný uzavřením rámcové dohody

Funkční, v souladu s právním základem provozovaná, národní součást Vízového informačního systému 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.3 Koncepce systému NS-VIS

Informační systém pro správu národního vízového procesu je koncipován pomocí architektury SOA a je složen z nezávislých služeb v souladu s architekturním řešením centrálního systému CS-VIS. Integrační vrstva poskytuje vysokou míru interoperability a umožňuje tak vzájemnou integraci komponent a služeb stávajících informačních systémů s vízovými informačními systémy Evropské unie.

Komponenty systému VIS

Komponenta	Lokace	Popis
CN_KLIENT_VIZA	L_RSCP, L_OCP_KR, L_ICP_LETIS TE	Klientská aplikace Víza. Pořízení krátkodobých víz na území (OCP), prodloužení doby pobytu krátkodobého víza, zpětvzetí žádosti o krátkodobé vízum, zrušení krátkodobého víza – annul visa, zrušení platnosti krátkodobého víza – revoke visa, vydání výjezdního příkazu v NS-VISu, vydání pobytového štítku, vytištění nového (duplikátu) vízového štítku krátkodobého víza.
CN_KLIENT_VYCKAT	L_RSCP, L_ZS, L_OAMP	Klientská aplikace Vyčkat. Podpůrný nástroj v procesu rozhodování o žádostech o vízum pořízených na území ČR, ZÚ MZV ČR a také k vytváření odpovědí v rámci VISION konzultací. Pomocí aplikace Vyčkat bude obsluha kompletovat konečné stanovisko k žádosti v těch případech, kdy nemohlo být vydáno konečné stanovisko jako výstup automatizované bezpečnostní prověrky a je nutné posouzení obsluhy.
A_TENKY_KLIENT (KA ADMINISTRACE, VISMAIL-CLIENT)	L_RSCP,	Klientská aplikace Administrace běžící v prostředí NS- VIS ESB poskytující administraci kódovníků, lokálních a centrálních parametrů pro KA, systémových parametrů, správu Ad hoc dotazů, administraci lustračních evidencí, administraci statistik, administraci auditních záznamů, blokace uživatelů. Klientská aplikace Vismail-Client běžící v prostředí VIS MAIL poskytuje administraci kódovníků a přehled zpracování vismailových zpráv.
CN_NS-VIS_WEB	L_HC_NS- VIS, L_ZC_NS-VIS	Přístupové body webových služeb systému NS-VIS, nápověda pro KA VYČKAT, KA VIZA a KA ADMINISTRACE.
CN_NS-VIS_ESB	L_HC_NS- VIS, L_ZC_NS-VIS	Společná platforma služeb systému NS-VIS, ve které běží komunikační a integrační adaptéry vůči všem spolupracujícím externím systémům. Systém NS-VIS poskytuje pro systémy ČR vysoce dostupný přípojný bod s centrálními systémy Evropské komise pro CS-VIS a CS- VISMAIL.
CN_NS-VIS_CA	L_HC_NS- VIS, L_ZC_NS-VIS	Centrální aplikace systému NS-VIS realizující obchodní logiku zpracování vízových procesů.
CN_NS-VIS_DB	L_HC_NS- VIS, L_ZC_NS-VIS	Databázové služby systému VIS a VIS MAIL.
CN_VISMAIL_APP	L_HC_NS- VIS, L_ZC_NS-VIS	Aplikační server prostředí VIS MAIL, ve kterém běží klientské aplikace, aplikace serverové logiky a aplikace rozhraní na spolupracující systémy.

Komponenta	Lokace	Popis
CN_VISMAIL_SMTP	L_HC_NS- VIS, L_ZC_NS-VIS	Poštovní server národního systému VIS MAIL s nativní podporou SMTP, MIME, S/MIME, POP3 a IMAP.

Systémy spolupracující se systémem VIS

Aktér	Lokace	Popis
A_KLIENT_EVC2_VIZA	L_MZV	Klientská část systému EVC2 pro pořízení žádosti o vízum a vydání víz na zastupitelských úřadech nebo konzulárním oddělení MZV.
A_EVC2	L_MZV	Informační systém MZV pro řešení vízové problematiky komunikující se systémem NS-VIS a CS-VIS.
A_ZS_MAIL_Klient	L_ZS	Klientská část mail serveru Zpravodajských služeb (ZS) pro udání předběžného stanoviska zpravodajských služeb k udělení víza.
A_ZS_MAIL	L_ZS	Mail server ZS pro výměnu dat mezi BIS a ŘSCP.
A_MAIL_CCPC	L_HC_OIPIT_ PPCR	Mailový server PČR pro odesílaní notifikací ze systému NS-VIS pověřeným pracovníkům ŘSCP.
X_XXXX.XXX.XX	L_HC_OIPIT_ PPCR	Klastr mailových serverů PČR poskytující systému NS- VIS stanoviska zpravodajských služeb k udělení víza.
A_CIS_APP	L_HC_OIPIT_ PPCR	Aplikační servery informačního systému cizinecké policie CIS. Aplikační servery CISu vytěžují ze systému NS-VIS data v rámci procesů EVIC2.
A_CIS_DB	L_HC_OIPIT_ PPCR	Databázové servery informačního systému cizinecké policie CIS poskytující pro systém NS-VIS lustrační evidence ENO, ENO-FOTO, PZR, ZZD, PRE, POZ. XXX/XXX-FOTO - Evidence nežádoucích osob, PZR - Evidence pozorka, ZZD - Evidence ztracených a zcizených dokladů, PRE - Evidence přestupků, POZ - Evidence pozvání.
A_KLIENT_CIS	L_OCP_KR, L_OAMP	Klientská část systému CIS. Zobrazují data ze systému NS-VIS v rámci procesů PROC_OCP_CIS_1_1A, PROC_RSCPP_CIS_2_1A, PROC_RCP_CIS_5_1.
A_CSML_G2	L_RSCP	Centrální systém mobilní lustrace druhé generace. Systém NS-VIS provádí pro CSML-G2 exporty aktuálních dat z vybraných databází (VIS, VIZ), stahuje auditní záznamy hitů z mobilních lustrací a zpřístupňuje webové služby: pro zápis nalezených hitů do systému ISOP, pro zápis

Aktér	Lokace	Popis
		průjezdu hranic a pro vyhledávání v zapsaných průjezdech.
A_LSML_G2	L_ICP_LETIS TE, L_MZ	Lokální servery mobilní lustrace G2. Replikační servery pro klienty mobilní lustrace a klientů KODOX.
A_KLIENT_MOBILNI_ LUSTRACE	L_ICP_LETIS TE, L_MZ,	Klientská aplikace pro mobilní zařízení umožňující mobilní lustraci. Ověření totožnosti cizince, vyhledání víza, provedení mobilní bezpečnostní prověrky.
A_KLIENT_KODOX	L_ICP_LETIS TE	Klienti systému KODOX. Pro řešení vízové problematiky (kontroly dokladů) na letištích komunikují se systémem NS-VIS a CS-VIS.
A_eISY_MBP	L_RSCP	Centrální server mobilní bezpečnostní platformy. Produkční instance MBP volá webové služby produkčního NS-VISu (služby konektoru CSVIS). Provádí služby identifikace a ověření osob v CSVISu v rámci území ČR.
A_ISOP_CDI2_DATA	L_RSCP	Informační Systém Opatření na hraničních přechodech (Blokace) poskytující pro systém NS-VIS data této lustrační evidence Policie ČR.
A_X00_SERVICES	L_HC_OIPIT_ PPCR	Služba Informačního Systému Opatření na hraničních přechodech (Blokace) zpřístupňující webové služby: pro zápis nalezených hitů do systému ISOP.
A_ICIS_GW	L_ZC_OIPIT_ PPCR	Hraniční síťové prvky (GW) pro zabezpečenou komunikaci serverů NS-VIS s centrálním systémem INTERPOL Criminal Information System (ICIS).
A_FIND_FLAG_DB	L_HC_OIPIT_ PPCR	Replika dodatkové databáze, která obsahuje poznámky Interpolu k zájmovým záznamům (hitům) včetně číselníků ICIS a českých překladů, které jsou použity pro zobrazení významu kódů.
A_ PATROS_DB	L_HC_OIPIT_ PPCR	Databáze policejní evidence Pátraní po osobách Policie ČR (PATROS).
A_CSL	L_HC_OIPIT_ PPCR	Centrální logovací systém (CLS) vytěžující ze systému NS-VIS auditní záznamy všech vyhledání a výsledky vyhledání v evidenci PATROS.
X_XXX_XXX.XX	L_HC_OIPIT_ PPCR, L_ZC_OIPIT_ PPCR	Systémy provozovatele poskytující pro řešení NS-VIS správu uživatelů (MS Active Directory domény XXX.XX) a služby DNS.
A_BACKUP_HPDP	L_HC_OIPIT_ PPCR, L_ZC_OIPIT_ PPCR	Systémy provozovatele poskytující pro řešení NS-VIS služby zálohování (HP DataProtector Backup Server).
A_ILMT	L_HC_OIPIT_ PPCR	Systém provozovatele poskytující pro systém NS-VIS a VISMAIL služby IBM Licence Metric Tool pro dohlížení

Aktér	Lokace	Popis
		spotřeby licencí spadajících do kategorie sub-kapacitního licencování (WebSphere ND, Lotus Domino).
A_SIEM	L_HC_OIPIT_ PPCR	Systém provozovatele poskytující pro systém NS-VIS a VISMAIL služby detekce kybernetických bezpečnostních událostí v souladu s VoZKB.
A_NS-SISII	L_HC_NS-SIS, L_ZC_NS-SIS	Národní část systému Schengen Information System II (NS-SISII) poskytující systému NS-VIS rozhraní webových služeb pro pokládání dotazů, jež jsou součástí bezpečnostních prověrek za účelem prověřování osob a jejich dokladů a to jak v případě procesů pořízení žádosti o vízum, tak při vstupních/výstupních kontrolách na hranicích Schengenského prostoru.
A_RWIN_FWSM_ACE	L_HC_OIPIT_ PPCR	Řešení vysoce dostupné síťové topologie CISCO Systems pro prostředí NS-VIS v lokalitě HC založeno na integrovaném modulárním řešení síťových a bezpečnostních technologiích poskytujících vysokokapacitní LAN switchig/routing, firewalling a aplikační a kontrolní řízení. Primární přístupový bod všech webových služeb systému NS-VIS (xxxxx://xxxxx.xxx.xx)
A_RWIN_BGP	L_HC_OIPIT_ PPCR	Primární BGP router zprostředkující lokální národní interface na centrální systémy VIS a VIS MAIL v lokalitě HC.
A_LNI	L_STESTA_L NI	Local National Interface S3-CZPRG01 - Lokální národní interface na centrální systémy VIS a VIS MAIL.
A_RSTR_FWSM_ACE	L_ZC_OIPIT_ PPCR	Řešení vysoce dostupné síťové topologie CISCO Systems pro prostředí NS-VIS v lokalitě ZC založeno na integrovaném modulárním řešení síťových a bezpečnostních technologiích poskytujících vysokokapacitní LAN switchig/routing, firewalling a aplikační a kontrolní řízení. Záložní přístupový bod webových služeb systému NS-VIS.
A_RSTR_BGP	L_ZC_OIPIT_ PPCR	Záložní BGP router zprostředkující lokální národní interface na centrální systémy VIS a VIS MAIL v lokalitě ZC.
A_BLNI	L_STESTA_B LNI	Backup Local National Interface S3-CZPRG02 - Záložní lokální národní interface na centrální systémy VIS a VIS MAIL.
A_CS-VIS	L_EC_CU	Centrální vízový systém CS-VIS.
A_CS-VISMAIL	L_EC_CU	Centrální systém VIS MAIL.
A_BCS-VIS	L_EC_BCU	Záložní část centrálního vízového systému CS-VIS.
A_BCS-VISMAIL	L_EC_BCU	Záložní část centrálního systému VIS MAIL.

Aktér	Lokace	Popis
A_KLIENT_EVC2_VIZA	L_MZV	Klientská část systému EVC2 pro pořízení žádosti o vízum a vydání víz na zastupitelských úřadech nebo konzulárním oddělení MZV.
A_EVC2	L_MZV	Informační systém MZV pro řešení vízové problematiky komunikující se systémem NS-VIS a CS-VIS.
A_ZS_MAIL_Klient	L_ZS	Klientská část mail serveru Zpravodajských služeb (ZS) pro udání předběžného stanoviska zpravodajských služeb k udělení víza.
A_ZS_MAIL	L_ZS	Mail server ZS pro výměnu dat mezi BIS a ŘSCP.

2 Rámcová dohoda

2.1 Předmět plnění:

• část A – Poskytování technické podpory provozu NS-VIS - fixní část a variabilní část

• část B – Rozvojové aktivity

• část C – Řízený přechod mezi Dodavateli při změně smlouvy - převzetí systému, pokud je vybrán jiný než stávající Dodavatel

2.2 Plnění A. Technická podpora provozu NS-VIS

2.2.1 Plnění A.1 - Poskytování technické podpory provozu NS-VIS - 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í NS-VIS 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 a SW řešení, ve kterém bude hlášení chyb, nestandartních stavů a komunikace mezi Dodavatelem a Objednatelem zajištěna.

Součástí podpory je udržování všech prostředí Objednatele (testovacího a produkčního) v aktualizovaném stavu, (udržování taktéž vývojového prostředí NS-VIS). Pokud vývoj neprobíhá přímo na vývojovém prostředí Objednatele, zajistí Dodavatel aktualizaci vývojového prostředí u Objednatele vždy s ukončením prováděcí smlouvy, která v něm vyvolala změnu.

„Plnění A.1 - Poskytování technické podpory provozu NS-VIS - 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.

2.2.1.1 Korektivní služby podpory zahrnují zejména:

• Reaktivní podporu zaměřenou na detekci příčin zjištěných či nahlášených anomálií, nestandardních a chybových stavů (dále problém) ve fungování systému během jeho provozu a implementaci odpovídajících oprav nebo dočasných řešení v souladu s SLA, s jasným cílem zprovoznit systém, odstranit příčinu problému a navrhnout, otestovat a nasadit trvalé řešení.

• Vedení záznamů o výskytu anomálií během provozu systému.

• Podporu Objednatele 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 Objednatele přímou komunikaci s třetí stranou.

Korektivní služby jsou uvedeny v Příloze A: Detailní specifikace služeb A1.

2.2.1.2 Preventivní služba podpory zahrnuje zejména:

• Proaktivní podporu zaměřenou na detekci a předcházení anomáliím, nestandardním a chybových stavů (dále problém) ve fungování systému během jeho provozu a implementaci odpovídajících oprav nebo dočasných řešení s jasným cílem přesně definovat příčinu problému a navrhnout, otestovat a nasadit trvalé řešení

• Detekovat a odstraňovat latentní chyby dříve, než se mohou projevit selháním systému nebo jeho komponent. Provádět úpravy nastavení nebo nasazovat úpravy komponent, které sníží šanci budoucích problémů systému.

• Prověřování možností optimalizace systému prostřednictvím analýzy technických, procesních i organizačních aspektů systému a návrhu úprav technických, procesních nebo organizačních směřujících k vyšší spolehlivosti a efektivitě systému a práce s ním.

Preventivní služby jsou uvedeny v Příloze A: Detailní specifikace služeb A1.

2.2.1.3 Adaptivní služby podpory představují zejména následující oblasti činností:

• Aktualizace konfigurace systému (a jednotlivých komponent) s cílem zachování úrovně HW a SW podpory garantované Dodavateli jednotlivých složek systému a systému jako celku.

• Přizpůsobovat systém s cílem udržet ho na úrovni garantované dostupnosti, odezvy a dalších kvalitativních ukazatelů.

• Udržovat kvalitu poskytovaných služeb systému NS-VIS jeho uživatelům, resp. souvisejícím systémům, mimo jiné předvídáním ukončení podpory hardware, firmware komponent systému, dále použitých operačních systémů, SW produktů (COTS) a aplikací stejně jako problémů, které mohou vyplývat z nepodporovaných komponent systému.

• Sledování dlouhodobých trendů využívaní služeb, zátěže a struktury zátěže systémů, analýzu trendů a včasnou reakci na ně formou úprav parametrů, změn architektury, nebo doporučení posílení technického a programového vybavení.

• Správa certifikátů a včasná reakce na potřebu jejich změny včetně vedení jejich přehledu.

Adaptivní služby jsou uvedeny v Příloze A: Detailní specifikace služeb A1.

2.2.1.4 Služby Helpdesku

Služby reaktivní podpory představují 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 Objednatele pro poskytování všech služeb z rámcové dohody a prováděcích smluv č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 Objednatele 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 Objednatelem.

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ů SLA.

• Dokumentace incidentů, vad, problémů, příčin vzniku a jejich řešení.

• Reakce na dotazy oprávněných uživatelů Objednatele.

• 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 Smluvni sankce a Kategorie vad

• Přístup prostřednictvím webové služby, e-mailu, telefonu nebo dalšími navrženými způsoby.

• 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 Objednatele 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 Objednatele odsouhlasena.

Závažnost (Severita) – klasifikace naléhavosti incidentu, problému nebo požadavku, která je odvozena od úrovně nefunkčnosti nebo nedostupnosti systému.

Dodavatel vyhotoví a předá Objednateli 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:

• předmět incidentu, problému nebo požadavku,

• jejich stav,

• čas nahlášení, registrace a autorizace,

• reakční doba,

• doba řešení,

• čas a způsob uzavření a autorizace,

• doba a důvod nedostupnosti systému NS-VIS nebo jeho části,

• doba a důvod nedostupnosti služby Helpdesk.

Dodavatel je dále Objednateli 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.).

Objednatel a Dodavatel vytvoří komunikační matici, která bude obsahovat všechny relevantní

kontaktní osoby pro komunikaci mezi stranami včetně eskalačních mechanismů.

Doba vyřešení servisního případu se řídí specifikací uvedenou v popisu konkrétního objednaného plnění.

2.2.1.5 Služby poskytované jako součást fixní podpory

• Kontrola konzistence databázových schémat a číselníků NS-VIS (dokumentace a release

management, úprava skriptů v souladu s procesy NS-VIS).

• Ladění výkonnosti - ověřování databázově intenzivních a pomalých dotazů (časté nebo náročné operace), dle business procesů designu NS-VISu, hledání optimalizací v databázi i v business procesech systému NS-VIS, doplňování indexů, nutné úpravy konfigurací.

• Údržba produkčních databází, tabulek NS-VIS, kontrola a aktualizace číselníků, skriptů, dle aktuálních požadavků a potřeb, aplikace bezpečnostních aktualizací a doporučení, upgrade DB.

• Údržba testovacích databází, tabulek NS-VIS, kontrola a aktualizace číselníků, skriptů, anonymizace dat, udržování reálného obrazu produkce, dle aktuálních požadavků na ladění výkonu NS-VIS.

• 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 NS-VIS.

• Plánování úložišť – optimalizace fyzického designu, rozložení I/O v ASM, sledování trendů růstu, Oracle Partitioning - činnosti a akce na základě minulých trendů růstu velikosti databáze NS-VIS a plánových změn rozvoje systému NS-VIS. Návrhy odmazávání dat dle procesů a požadavků na uchování dat v systému NS-VIS).

• Údržba kódu PL/SQL a SQL pro zlepšení výkonnosti, drobné vylepšení ve funkcionalitě. PL/SQL kódů.

• Kontrola logů Oracle a jejich posouzení na dopad funkčnosti (kritičnosti) systému NS-VIS, indikace problémů včetně klasifikace ve kterém modulu a procesu NS-VIS problém nastává, návrh řešení.

• Kontrola integrity nastavení Oracle s ohledem na procesy NS-VIS včetně kontroly funkcí

Oracle DataGuard

• 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ů NS-VIS.

• Provozní deník support Objednateli se správou a vedením provozního deníku systému NS-VIS

• Technická a provozní dokumentace vytvoření, zpracování změn s ohledem na provoz rozvoj a

úpravy systému

• Návrh architektury a rozvoje vytvoření či úpravy arch. řešení s ohledem na provoz rozvoj a

úpravy systému

• Diagnostika hardwarového vybavení a systémových událostí prostředí NS-VIS pomocí

management nástrojů

• Kontrola operačního systému RedHat Enterprise Linux s ohledem na prostředí a procesy NS- VIS

• Kontrola a podpora KVM/VMware virtualizačních služeb

• Kontrola LAN – status ACE sond, vyhodnocení a revize FWSM access listů, stav BGP směrování CS-VIS s ohledem na komunikační matici NS-VIS

• Kontrola SAN - logů a integrity konfigurace aktivních prvků SAN

• Kontrola datové komunikace a případné testy konektivity NS-VIS a VIS Mail na centrální systémy EU ( CSVIS a CVISMAIL)

• Expertní podpora a konzultace propojení NS-VIS s externími systémy (EVC2, ZS, SISII, ICIS, CIS, CSML G2, ZC-CIS, PATROS, ISOP, CSL, CMS) s ohledem na specifikace rozhraní systému NS-VIS

• Údržba systémových SW částí infrastruktury (aplikace opravných fixů a patchů, upgrade

firmware)

• Optimalizace systémů a případné HW rekonfigurace prvků technologické infrastruktury centrální části NS-VIS a VIS Mail

• Expertní podpora s integrací se službami ICT PČR (AD, DNS, NTP aj.)

• Optimalizace a údržba administračních skriptů NS-VIS (včetně spouštěcích a nastavovacích) pro IBM WebSphere Aplikačních servery a IBM WebSphere HTTP servery NS-VIS

• Monitoring, optimalizace a rekonfigurace WebSphere pluginů po změnách v nastavení pro aplikační moduly centrální části NS-VIS

• Diagnostika a výkonnostní optimalizace parametrů IBM WebSphere Aplikačních serverů a IBM WebSphere HTTP serverů

• Expertní podpora vysoké dostupnosti a konzultace při administraci WebSphere aplikačních clusterů CA a ESB dle procesů NS-VIS

• Diagnostika a optimalizace WebSphere Integration Service Bus pro transakční zpracování

(JMS messaging) dle procesů NS-VIS

• Podrobná expertní kontrola systémových logů WebSphere dle procesů NS-VIS a VIS Mail

• Konzultace a pomoc při aktualizaci fix packů IBM WebSphere Aplikačních serverů a IBM WebSphere HTTP serverů

• Kontrola nastavení monitorovacích skriptů NS-VIS a VIS Mail, podpora při integraci a

realizace rozvoje monitoringu

• Support při nefunkčnosti základních (nikoli aplikačních) služeb IBM WebSphere Aplikačních serverů a IBM WebSphere HTTP serverů a při obnovení provozu v případě výpadku či poruchy externího systému

• Release management podpora při nasazení nových verzí aplikačních modulů NS-VIS a VIS

Mail, údržba, konfigurace produkčního, testovacího a vývojového prostředí

• Podrobná kontrola systémových logů Lotus Domino dle procesů VISMAIL (běh housekeeping agentů, běh mail routeru, replikačních služeb, aktualizace Symantec LiveUpdate)

• Kontrola složky vmError v poštovní databází VISMAIL aplikace, kontrola schránky

Administrátora na zprávy serveru a CVISMAIL

• Monitoring, optimalizace a rekonfigurace SMTP služeb prostřednictvím administračního rozhraní dle procesů VISMAIL

• Kontrola a podpora nástrojů pro monitoring infrastruktury a analýzu logů NS-VIS (Nagios, LogStash, ElasticSearch, Kibana)

• Týdenní reporting o stavu systému (na týdenní bázi součástí programového výboru hlášení o výpadcích systému-nedostupnosti, externích systémů, stav aktuálnosti KA,aj.), reporty z Helpdesku

• Poskytování souhrnného přehledu o zatížení systému z pohledu aplikačního a systémového

• Detekce a analýza 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

• Helpdesk

• Pravidelný měsíční reporting s přehledem významných událostí (reporting a statistiky)

• Specifikace změnových požadavků (ZP) Objednatele, Předběžná analýza a předběžné ocenění prací objednaných z plnění A2 a B

• Analytická podpora pro řešení problémů, vyplývajících z požadavků podpory pro CA, ESB (modulů rozhraní), KA a VIS Mail

• PM, koordinace, administrativa, řízení kvality

• Podpora služeb nutných k zajištění funkčnosti všech modulů a aplikací v případě změn na

externí systémy

• Řešení dopadů Autentizace a autorizace, certifikace, ochrana prvků KII, podpora Objednatele na reakce KBI, zvládání mimořádných událostí

• Podpora Objednatele při plánování a provedení testu obnovy

2.2.2 Plnění A.2 - Poskytování technické podpory provozu NS-VIS – variabilní část

Do prací, které je možno objednávat z plnění A.2, patří zejména činnosti související se změnou konfigurace systému nebo jeho části, činnosti s vazbou na rozvoj systému a školení. Dále může být požadována zejména podpora s ohledem na aktivity organizované centrální stranou systému (Evropská komise nebo agentura eu-LISA), které vyžadují aktivní účast členských států v rámci zajištění reakce na nové funkční a provozní požadavky, podpora řízení a správy změn vyvolaných změnami ve funkční specifikaci VIS, podpora a realizace předepsaných testovacích kampaní v rozsahu stanoveném eu- LISA a dalších činností uvedených v této kapitole níže.

Příklad služeb, které mohou být v rámci požadavků Objednatele objednány nad rámec plnění A.1:

• Expertní podpora a konzultace při administraci a optimalizaci WebService rozhraní na externí systémy dle procesů NS-VIS

• Konzultace nastavení systémových parametrů centrální části NS-VIS

• Komplexní administrace aplikačních rolí NS-VIS a VIS Mail jejich mapování na MS Active

Directory, podpora organizačních změn (přesuny organizačních jednotek/zrušení/vytvoření)

• Tvorba a úprava sond pro monitoring a analýzu

• Úpravy Bezpečnostní dokumentace v závislosti na změnách spojených s provozem, rozvojem

a úpravami systému

• Support Objednateli a analýza dokumentů EU s přímým dopadem na provoz, rozvoj a úpravy

systému NS-VIS

• Support Objednateli s tvorbou, úpravou dokumentů PČR s ohledem na provoz, rozvoj a úpravy

systému NS-VIS v závislosti na úpravě KA či legislativního rámce EU

• Support Objednateli 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 NS-VIS

• Ú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) systému NS-VIS

• Support Objednateli, analýza Interface Control Document, Detailed Technical Specification, Test Design Description (ICD,DTS,TDD)

• Support Objednateli s generováním statistik a reportů pro národní a EU účely

• Podpora komunikace s EU, ČR

• Diagnostiku aplikačních logů

• Diagnostika a řešení problémů, nedostatků

• Monitoring databází, replikací lustračních databází

• Optimalizace výkonnosti

• Monitoring datových výměn s externími systémy

• Monitoring aplikací, běhu timerů a zpracování asynchronních služeb

• Analýza provozního stavu na vyžádání Objednatele

• Analytická podpora pro řešení problémů, vyplývajících z požadavků provozní podpory

• Analytická podpora pro řešení problémů, vyplývajících z požadavků podpory databáze, řešení problémů s číselníky

• 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 EU

• Ověření, zkoumání, (re)testy případných problémů, nedostatků

• Vývoj, testování, úprava/doplňování dokumentace, která není uvedena v plnění v rámci fixního

supportu dokumentace uvedené v Příloze 1a kapitoly 2.4 Dokumentace systému

• Analýza požadavků Objednatele pro vývoj a analýza požadavků pro drobné změny

• Realizace drobných změn, úprav nutných integrovat adHoc,bez možnosti odkladu

• Podpora a realizace předepsaných testovacích kampaní v rozsahu stanoveném eu-LISA, včetně jejich vyhodnocení a případného opakování

• Podpora řízení a správy změn vyvolaných změnami ve funkční specifikaci VIS, stanovenými

agenturou eu-LISA

• Zajištění reakce na nové funkční a provozní požadavky (Požadavek na změnu) kladené na ČR

ze strany agentury eu-LISA

• Analytická podpora rozborů AF, tedy procesů, případů užití, datového modelu, rozbor rozhraní

• Údržba, konfigurace testovacího a vývojového prostředí, příprava a optimalizace dat pro

testovaní a vývoj, synchronizace číselníků

• Podpora Objednatele při plánování a provádění testování vysoké dostupnosti (například test přepnutí do záložní lokality, test BCP, DRP) v intervalu alespoň 1x ročně

• 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í)

• Podpora při evaluacích NS-VIS v ČR

• Zajištění průběžného školení pracovníků Objednatele

Plnění A. 2 bude čerpáno samostatnými prováděcími smlouvami na definovaný finanční objem, jejichž přílohou bude soupis objednávaných rolí. Čerpání ze smlouvy není povinné a služby budou čerpány postupně až do vyčerpání prostředků nebo ukončení účinnosti dané prováděcí smlouvy. Z důvodu plynulé návaznosti aktivit se různé prováděcí smlouvy 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í. Služba A.2 je poskytována na základě konkrétních objednávek Objednatele 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.

Povinnou součástí plnění A.2, které je Xxxxxxxxx povinen na vyžádání – na základě objednávky poskytnout, je:

2.2.2.1 Konzultace

Na základě požadavku/objednávky Objednatele může být Dodavatel požádán o poskytnutí asistence/konzultace Objednateli, uživatelů nebo jiným subjektům ohledně libovolné komponenty nebo služby či procesu NS-VIS zejména, ale ne jen:

• 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 NS-VIS

• Příprava technických zpráv a implementačních postupů v technické oblasti

• Detailní technické poradenství nebo vysvětlení

• Pomoc při diagnostice problémů, které mají nebo mohou mít přímý nebo nepřímý dopad na

NS-VIS

• Instalace a konfigurace software

2.2.2.2 Školení

Tato aktivita je určena k provedení školení 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 NS-VIS nebo změny konfigurace apod. na všechny relevantní subjekty (administrátory/školitele/třetí subjekty).

2.2.2.3 Vývoj

Na základě požadavku Objednatele musí být všechny vývojové práce provedeny na vývojovém prostředí Objednatele, pokud bude takové prostředí Objednatelem poptáno a ve spolupráci s Dodavatelem realizováno. Pokud vývoj neprobíhá přímo na vývojovém prostředí Objednatele, zajistí Dodavatel aktualizaci vývojového prostředí u Objednatele (pokud takové existuje) vždy s ukončením vývojových prací plnění A či B, která v něm vyvolala změnu.

S ukončením prováděcí smlouvy plnění A či B bude Objednateli předána pokaždé aktuální verze vývojového prostředí a budou uloženy zdrojové kódy na repozitory Objednatele k zachování integrity provedených změn.

2.3 Plnění B Rozvojové aktivity NS-VIS

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 (potažmo technické specifikace agentury eu-LISA). Vízový informační systém je neustále se rozvíjející systém a je nutné zajistit soulad požadavků na výkonnost a funkcionality systému s legislativou a přijatými standardy.

Předmětem Plnění B jsou služby rozvoje NS-VIS, při kterém typicky dochází k zásahu do zdrojových kódů (pro nasazení je nutná jejich nová kompilace), ale není to podmínkou (např. vývoj komponenty stojící mimo hlavní komponenty systému nebo analýza dopadů nových požadavků zákona o kybernetické bezpečnosti apod.)

Pokud není dohodnuto jinak, je součástí plnění B vždy:

• aktualizace dokumentace;

• aktualizace (je-li již realizováno u objednatele) vývojového prostředí – aktualizované vývojové prostředí bude předáno Objednateli s ukončením prováděcí smlouvy, která v něm vyvolala změnu;

• otestování;

• 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 (viz zákon o kybernetické bezpečnosti č. 141/2014 Sb. A Vyhláška č. 82/2018 Sb.);

• analýza rizik (na základě analýzy rizik Objednatel rozhodne o potřebě a rozsahu penetračních testů nebo testů zranitelností, které budou z analýzy rizik vyplývat);

• Uložení zdrojových kódů na repozitory Objednatele a řízený deployment.

Plnění je objednáváno uzavřením prováděcí smlouvy. 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 Objednatele.

Dodavatel má povinnost realizovat všechny oprávněné požadavky Objednatele na rozvoj systému, tj.

požadavky, které jsou v souladu s účelem systému anebo které vyplývají z požadavků EU.

Jednotlivé Prováděcí smlouvy budou uzavírány na předpokládaný maximální rozsah prací odhadnutý Dodavatelem ve spolupráci s Objednatelem na základě popisu Objednatelem požadované funkcionality a tomu odpovídající cena dle RD, fakturovány budou pouze skutečně vykonané činnosti.

Pokud nedojde mezi Dodavatelem a Objednatelem ke shodě nad maximálním rozsahem prací, které jsou nutné pro provedení objednaného díla, je Objednatel oprávněn požadovat po dodavateli, aby veškeré práce provedl v prostorách Objednatele na vývojovém prostředí Objednatele (resp. své vlastní technice) pod jeho dohledem, pokud budou na straně Objednatele zajištěny adekvátní podmínky nezbytné pro práci v prostorách Objednatele.

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.1 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 vyvolají řadu zásadních změn, které mají přímý dopad na funkcionality CS-VIS jako celku a bezprostředně pak na všechny národní součásti – včetně NS-VIS ČR.

Mezi tyto projekty se řadí projekty uvedené v kapitole 2.2.1.2. Připravenost jednotlivých zemí na včasnou implementaci změn ICD a DTS a následné rozsáhlé testování je praktickou (bezpečnostní) i politickou prioritou.

Dodavatel se zavazuje, že zajistí v součinnosti s Objednatelem 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 Objednatele). Dodavatel pro každý projekt 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 Objednatelem za předpokladu, že

dojde k podpisu prováděcí smlouvy na příslušný rozvojový projekt do 6 týdnů (nebo v pozdějším termínu, v harmonogramu vyznačeném jako nutný předpoklad splnění zadání) od předložení nabídek veřejné zakázky na RD.

2.3.1.2 Orientační harmonogram

Implementace ICD VIS-EES:

• říjen 2019 schválení ICD a DTS VIS-EES (garant EU) řídící dokumentace pro započetí

implementace

• září 2020 dodání dokumentace pro testování (Pre-CT/ CT TDD)

• prosinec 2020 dostupné PGD prostředí pro započetí testů NS-VIS

• září 2021 CT testy současně s EES

• únor 2022 EiO současně s EES

VIS Recast:

• září 2020 schválení evropské legislativy (řídícího dokumentu pro započetí analýzy)

• červen 2021 schválení ICD a DTS řídící dokumentace pro započetí implementace

• březen 2022 dodání dokumentace pro testování (PreCT/CT TDD)

• duben/květen 2022 CT testy CZ

• srpen 2022 EiO

2.3.1.3 Orientační 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 zdrojového kódu, vývoj funkcionalit a úprava systému nebo jeho částí. Mezi plánované projekty v době platnosti rámcové dohody patří:

• Vybudování rozhraní a úpravy systému NS-VIS se spuštěním EES (spuštění systému EntryExit do roku 2023 se změnami procesů NS-VIS souvisejících s kontrolou na hranicích a území)

• Úprava systému dle EU legislativy, především s plánovanou změnou vízového kodexu (reflektující změny legislativy s dopadem na NS-VIS a komunikační kanál VisMail1, úpravy spojené s implementací změn dle aktualizované EU legislativy)

• Úprava systému na základě ICD projektu Interoperability

• Úprava rozhraní (konektoru s CS-VIS) a úpravy systému NS-VIS se změnami nařízení o Vízovém informačním systému - projekt VISRecast (změny/rebuild procesů NS-VIS souvisejících s aktualizací nařízení o vízovém informačním systému)

• Optimalizace aplikací a systému s přechodem na OS Windows 10

plánovaný projekt na optimalizaci aplikací se spuštěním na x64 s W10 a spojenými službami s úpravami ovladačů k periferiím VIS

• Úprava národního rozhraní s Informačním systémem Opatření (ISO),ICIS a CIS (územní zákaz

pobytu (UZP)

• Řešení posílení HW NS-VIS migrací NS-VIS do privátního cloudu

Úprava systému a rozhraní (konektoru s CS-VIS) s doplněním operací CS-VIS, které doposud nejsou

NSVIS využívány (fáze 2)

Mezi plánované projekty v době platnosti, které je možné realizovat:

• Implementace rozhraní a úpravy systému na evropský projekt Interoperabilita

• Vybudování rozhraní a úpravy systému NS-VIS nutné ke zvýšení spolehlivosti rozhraní s BIS

• Vybudování rozhraní a úpravy systému NS-VIS se spuštěním IS ETIAS (analýza míry integrace obou systému s případnými změnami na úrovni národního rozhraní, CA a KA)

• Projekt digitální skartace dat (Služby spojené s úpravami systému NS-VIS k naplnění legislativních požadavků s vytvořením algoritmu pro zálohování, skartaci a filtrování žádostí v KA (nedostupnost archivovaných informací)). Z toho vyplývá i potřeba revidovat vedení identity v systému a jejích úprav. Úzce souvisí s úpravami týkajícími se AFIS.

• Vybudování rozhraní a úpravy systému NS-VIS s AFIS (úpravy systému a rozhraní, které umožní oboustranné odesílání WS včetně biometriky. Úpravy pro jednoduché a rozšířené dotazování, kdy dotazování do AFIS bude zahrnuto do ABP)

• Úprava rozhraní s CIS se změnami EES-VIS (úprava rozhraní NS-VIS a CIS tak aby sdílely

potřebné informace a došlo k možnosti dotazování se na data EES)

• Migrace dat z CIS (zajištění přenosu dat k procesům, které byly dříve realizovány v jiných

systémech a nyní jsou v NS-VIS)

• Rozšíření možností vyhledávaní v SIS II do procesů, kde to zatím není realizováno (především KA VYČKAT), rozšíření možností zobrazování informací ze SIS, především týkající se více identit, provázání záznamů a zobrazení akcí, které mají být vykonány.

• Error management (Doplnění error managementu klasifikace chyb, do klientských aplikací)

• Kybernetická bezpečnost fáze 3

o Revize, aktualizace a v případě potřeby doplnění stávající bezpečnostní dokumentace VIS a její uvedení do souladu s legislativními požadavky ČR (zejména ZoKB, VoKB, GDPR, z.č. 110/2019) a interními požadavky (resortní politiky ISMS MV, IAŘ…)

o Zpracování BIA (analýzy dopadů), revize a aktualizace RPO, RTO, LCB, MTO, MTDL a

MRSL v případě chybějících ukazatelů jejich stanovení

o Revize a aktualizace technického posouzení (dodáno IBM) dle požadavků aktualizované bezpečnostní dokumentace VIS

o Penetrační testy s cílem identifikovat zranitelnosti v infrastruktuře

o Ověření BCP a DRP, simulace výpadku lokality, test přepnutí lokalit

o Revize a aktualizace seznamu aktiv a rizik (dodáno MV)

o Po posouzení rizik (identifikace, analýze a hodnocení rizik) s ohledem na plán zvládání rizik navrhnout a implementovat opatření, které uvedou VIS do souladu s požadavky vyplývajícími z aktualizované Bezpečnostní dokumentace VIS)

2.4 Dokumentace systému (mimo projektové dokumentace)

Součástí systému musí být komplexní soubor dokumentace, obsahující minimálně:

• uživatelskou dokumentaci;

• Provozní dokumentace systému VIS obsahující administrátorskou dokumentaci včetně soupisu stavů monitoringu, které mají vyvolat akci podpory, ucelený soubor technické dokumentace – včetně architektury řešení, detailní analýzy všech procesů a funkcí systému;

• uživatelské příručky klientských aplikací;

• programátorskou dokumentaci;

• Instalační a konfigurační dokumentace

• Návody k odstraňování problémů (chybové stavy – již řešené, zadané Objednatelem či odhalené dodavatelem, problémy s provozem či nastavením/konfigurací, na které Dodavatel při své práci narazil)

• Školící dokumentace

• Testovací dokumentace a scénáře

• Soupis rizik a registrovaných problémů

• Plán Business Continuity a Disaster Recovery

• Bezpečnostní dokumentaci – rozsah požadovaný vyhláškou č. 82/2018 Sb., včetně popisu obnovy systému po různých druzích výpadků (Disaster recovery plan, Business Recovery Plan).

Dokumentace musí být udržována aktuální průběžně po celou dobu platnosti rámcové dohody

s ohledem na plnění A a B.

2.5 Plnění C – Předání systému

2.5.1 C.1 - Předání systému novému dodavateli – handover při ukončování RD

Plnění C.1 je plnění Dodavatele při předávání systému při ukončování rámcové dohody nastupujícímu dodavateli. Plnění C je objednáváno samostatnou prováděcí smlouvou.

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 Objednateli nebo třetí straně před koncem účinnosti rámcové dohody v souladu s pokyny Objednatele. 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 Objednatel nerozhodne jinak na základě známých skutečností (plán bude předložen do 3 týdnů od objednání aktivity, podléhá samostatné akceptaci), samotné předání a zaškolení přebírajícího subjektu (může podléhat samostatné akceptaci) a 3 měsíční „stínová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.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ů.

2.5.1.2 Součástí předání jsou nejméně tyto vstupy:

• Relevantní procesy a procedury

• Seznam klíčových partnerů a jejich kontakty

• 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é Xxxxxxxxx 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.1.3 Výstupy obsahují zejména:

• Plán předání

• Plán/soupis akceptačních podmínek předání (jednotlivé služby, procesy, dokumentace atd.)

• Zpráva o předání systému

• Proškolení třetí strany

• Zpráva o provedených proškoleních

• Koučink a stínování

• Zpráva o provedeném koučinku a stínování

• Všechna živá a historická data a informace podporující předávané služby

• Všechny podpůrné nástroje vytvořené po dobu kontraktu Dodavatelem za účelem kvalitního výkonu služeb, pokud byl jejich vývoj Objednatelem schválen a proběhlo předání Objednateli ať již za úplatu nebo v rámci plnění A. (všechna práva jsou Objednatele)

• Formální předání práv na využívání všech licencovaných produktů třetích stran

• Soupis nevyřešených problémů a rozpracovaných aktivit

• Checklist předání provozu.

2.5.1.4 Akceptace plnění sestává zejména z:

• 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í

• 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.4.2.2) nebo prokázáním, že Xxxxxxxxx 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

• Cena druhé fáze musí být min 30% plnění C.. Každá fáze je proplacena zvlášť po akceptaci. Jinak se na plnění C vztahuje obecný proces akceptace, viz kapitola Akceptace.

2.6 Projektové řízení

Aktivity, jež jsou součástí rámcové dohody o technické podpoře a rozvoji NS-VIS (dále též „RD NS- VIS“) 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“ Objednatel 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 NS-VIS je pro každý projekt zapotřebí uzavřít samostatnou prováděcí smlouvu, s čímž je spojeno vytvoření rozsáhlé dokumentace a řada administrativních procesů, jež mají dopad na Objednatele i Dodavatele a jež na řízení projektů kladou specifické nároky (Je detailně popsáno v příloze B tohoto dokumentu.). 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 NS- VIS je proto užíván pojem „Program NS-VIS“.

2.6.1 Základní dokument projektu

Do 30 pracovních dnů od podpisu 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 NS-VIS, a to jak pro Dodavatele, tak pro Objednatele. Draft ZDP Objednatel 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 Objednateli ke druhému čtení. Objednatel 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 Objednatelem 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 Objednatelem a Dodavatelem, která se budou konat v prostorách Objednatele. Vyplyne- li to z okolností jako nejúčelnější varianta, může vybrané kapitoly ZDP po vzájemné dohodě vytvořit Objednatel.

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 Objednatele, 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.7 SLA pro A. 1

2.7.1 SLA na garanci funkčnosti NS-VIS

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 prováděcí smlouvou na rozvoj systému. Dodavatel neodpovídá za porušení SLA způsobené systémy mimo jeho správu (HW, síťová infrastruktura, systém Active Directory apod.). Dodavatel rovněž neručí za porušení SLA způsobené nečinností Objednatele, který byl dle smluvních podmínek Dodavatelem upozorněn nebo vyplývá z nastavených procesů.

Pro systém NS-VIS je obecné SLA 99,7%, 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í.

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 Objednatel.

Garancí funkčnosti se spolehlivostí provozu systému 99,7 % je myšlena skutečnost, že Dodavatel musí zajistit dostupnost systému na úrovni 99,7 %, 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.4.1 a) nesmí překročit 0,3 % 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.1.1 On-line dotazování NS-VIS (synchronní operace)

On-line dotazováním je myšleno pokládání dotazů prostřednictvím klientských aplikací VÍZA či VYČKAT do národní DB NS-VIS či do DB 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 NS-VIS neposkytuje uvedenou funkcionalitu (typicky mobilní lustrace, CIS, EVC2 systém Ministerstva zahraničních věcí atd.). Uvedená funkcionalita, tj. dostupnost NS-VIS pro online dotazování má SLA 99,9 %. Dodavatel nezodpovídá za nedostupnost odpovědí způsobenou nedostupností CS-VIS nebo infrastrukturou mimo systém NS-VIS, 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 Objednatelem 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.1.2 On-line dotazování (asynchronní operace)

On-line dotazováním je myšleno pokládání dotazů prostřednictvím klientské aplikace VÍZA do národní DB NS – VIS či do DB 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 NS-VIS neposkytuje uvedenou funkcionalitu (typicky mobilní lustrace, CIS, EVC2 systém Ministerstva zahraničních věcí atd.). Dodavatel zodpovídá za odeslání dotazu na CS-VIS, nezodpovídá však za nedostupnost CS-VIS ať z důvodů infrastrukturních problémů mimo jeho dosah nebo z důvodů nedostupnosti samotného CS-VIS. Nezodpovídá ani za dobu odezvy CS-VIS. Uvedená funkcionalita, tj. dostupnost NS-VIS pro operace se žádostmi o vízum má SLA 99,9 %. Do měření doby SLA se plánované odstávky nezapočítávají jako nedostupnost systému, pokud není se Objednatelem 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 3-měsíčního období.

2.7.1.3 Dostupnost modulu/rozhraní NS-VIS – CS-VIS (konektor CS-VIS)

Dostupností modulu ESB NS-VIS – CS-VIS je myšleno umožnění externím systémům pokládání dotazů prostřednictvím modulu systému NS-VIS do centrální DB 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 nebude dodržena uvedená dostupnost (typicky kontrola dat v CS-VIS systémem KODOX systémem hraniční kontroly nebo EVC2 systém Ministerstva zahraničních věcí atd.). Dodavatel zodpovídá za dostupnost modulu, nezodpovídá však za nedostupnost CS-VIS ať z důvodů infrastrukturních problémů mimo jeho dosah nebo z důvodů nedostupnosti samotného CS-VIS. Nezodpovídá ani za dobu odezvy CS-VIS.Uvedená funkcionalita, tj. dostupnost modulu pro operace využívající konektor s CS-VIS má SLA 99,9 %. Do měření doby SLA se plánované odstávky nezapočítávají jako nedostupnost systému, pokud není se Objednatelem 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.1.4 Zpracování konzultací VISMail 2

Zpracováním konzultací VISMail 2 je myšleno provádění jakýchkoli operací systémem či koncovým uživatelem, které má dopad na příjem, vytvoření či zasílání zpráv VISMail 2 a zpracování tak příchozích a odchozích konzultací systémem NS-VIS. Uvedená funkcionalita má SLA 99,3 %. Do měření doby SLA se plánované odstávky nezapočítávají jako nedostupnost systému, jejichž délka však kumulativně za 3 měsíce nesmí přesáhnout 4 hodiny, pokud nebude Objednatelem povolena delší doba. 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.1.5 Vytváření, operace se žádostmi o vízum

Zpracováním či vytvářením žádostí je myšleno provádění jakýchkoli operací koncovým uživatelem, které má dopad na vytvoření, úpravu záznamů v národní či centrální databázi. Uvedená funkcionalita má SLA 99,3 %. Do měření doby SLA se plánované odstávky nezapočítávají jako nedostupnost systému, jejichž délka však kumulativně za 3 měsíce nesmí přesáhnout 4 hodiny, pokud nebude Objednatelem povolena delší doba. 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.2 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 Objednatele jejich problémy a nabídnout řešení požadavku.

Dostupnost služby Helpdesk pro nahlášení problémů, závad v systému NS-VIS bude v režimu 24x7, zajištění reaktivních služeb podpory Dodavatele zaměřených na řešení problémů a závad, které nebylo možné odhalit v rámci proaktivních služeb podpory v režimu 5x9 (v pracovní dny 8:00 – 17:00 hod).

Vada A – oprava nebo workaround do 24h s reakční dobou do 1h, pokud nebude se Objednatelem dohodnuto jinak – na funkcionality definované v kapitole č. 2.7.4.1 a).

Vada B – oprava nebo workaround do 72h s reakční dobou do 4h s návrhem řešení do 24h, pokud

nebude se Objednatelem dohodnuto jinak.

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 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 Objednatelem dohodnuto jinak.

2.7.3 Smluvní sankce

Objednatel 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ž Objednatel přihlíží ke všem okolnostem, za kterých k porušení SLA došlo.

2.7.3.1 Smluvní sankce za porušení doby dostupnosti

V případě nedodržení výše stanovených parametrů SLA vzniká Objednateli nárok na smluvní sankci v následující výši:

Překročení povolené doby nedostupnosti pro dotazování (2.7.1.1 a 2.7.1.2)	Smluvní sankce
Větší než 0 hodin, ale menší než nebo rovnající se 1 hodina za sledované období	10 000 Kč
Větší než 1 hodina za sledované období, ale menší než nebo rovnající se 6 hodin za sledované období	40 000 Kč
Za každé další započaté 4 hodiny nad 6 hodin za sledované období.	50 000 Kč
Překročení povolené doby nedostupnosti pro CUD (2.7.1.3)
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í	40 000 Kč
Za každé další započaté 4 hodiny nad 12 hodin za sledované období.	50 000 Kč

2.7.3.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.7.4 Kategorie vad) je dle smlouvy Dodavatel povinen uhradit Objednateli 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.7.4.1 c) – nelze nahlásit vadu typu 2.7.4.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.4 Definice termínů pro účely SLA

Plánovaná odstávka – Objednatelem schválený čas, po který nebude systém NS-VIS dostupný v jedné

nebo více svých funkcích, např. kvůli upgrade SW a nasazování nové verze 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.5 Kategorie vad

Viz kapitola 2.7 „Akceptace“ podkapitola 2.7.4 „Kategorie vad“.

2.8 Akceptace

2.8.1 Akceptace „Plnění A.1 - Poskytování technické podpory provozu NS-VIS - fixní

část“

Plnění A.1 - Poskytování technické podpory provozu NS-VIS - 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 prováděcí smlouvou 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í (3 měsíce). Ke dni podpisu dílčího akceptačního protokolu Objednatelem 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 Objednatelem 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 prováděcí smlouvou 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é Prováděcí smlouvě nedohodnou jinak.

2.8.2 Akceptace „Plnění „A.2 - Poskytování technické podpory provozu NS-VIS – 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

a) Před ukončením předmětného plnění musí Objednatel 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 Objednatelem 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.7.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 Objednatelem 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é prováděcí smlouvě 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 NS-VIS tak, jak bude specifikován v odsouhlasené analytické dokumentaci předmětného akceptovaného projektu a skutečnou vlastností či funkčností plnění (funkčnosti, která je předmětem plnění).

f) Objednatel provede akceptaci (tj. podepíše akceptační protokol) nebo sdělí Dodavateli vady

bez zbytečného odkladu.

2.8.4 Kategorie vad

2.8.4.1 Vada typu A

Vadou typu A se rozumí stav, kdy systém neposkytuje některou z funkcionalit systému specifikovaných v prováděcí smlouvě, technické dokumentaci nebo v akceptované analytické dokumentaci a dále:

a) systém nesplňuje účel, pro který byl vytvořen (definovaný v prováděcí smlouvě, 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 NS-VIS, která již je v systému zapracována, přestože to bylo účelem plnění (plnění A, B),

b) je znemožněno provedení požadovaných akceptačních testů nebo jinou akceptační proceduru (plnění A.2, B),

c) není funkční služba Helpdesk, pokud není zajištěn náhradní způsob hlášení chyb (plnění A,

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í (plnění A.2, B),

e) nebo libovolná kombinace výše uvedených stavů.

2.8.4.2 Vada typu B

Vadou typu B se rozumí stav

a) kdy je systém schopen omezeného provozu nebo neposkytuje některou z funkcionalit specifikovaných v prováděcí smlouvě, technické dokumentaci nebo v akceptované analytické dokumentaci, ale přesto lze dokončit všechny nezbytné procesy pro plnění úkolů

Objednatele a plní povinnosti vyplývající z legislativy, které již byly v systému

implementovány (plnění A.2, B),

b) který 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 Objednatele (plnění A, B, C),

c) jenž způsobí nefunkční službu Helpdesk, pokud je zajištěn náhradní způsob hlášení chyb (plnění A, B, C),

d) nebo libovolná kombinace výše uvedených stavů.

2.8.4.3 Zá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, B, C).

2.8.5 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. Objednatel 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 30-ti stran, nad 30 stran obecně nejpozději do 15-ti dnů, nebude-li dohodou na vedení projektu stanoveno jinak); nevznese-li Objednatel 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 Objednatel 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 Objednatele a takto upravený dokument předat jako jeho druhou verzi Objednateli k akceptaci.

d. Objednatel 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 Objednatel 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é Objednatel 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 Objednatele vypořádat do deseti (10) pracovních dnů od akceptace dokumentu.

e. Vznese-li Objednatel 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 prováděcí smlouvy, 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 NS-VIS 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é prováděcí smlouvy. 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í A1 je poskytováno v místě určeném Objednatelem 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 Dodavatele na dedikovaném vývojovém prostředí zřízeném v prostorách Dodavatele.

Plnění A2, pokud nejde o práci na některém z prostředí Objednatele, mohou být prováděna i mimo

prostory Objednatele, není-li Objednatelem v prováděcí smlouvě stanoveno jinak.

Plnění B, pokud nejde o práci na některém z prostředí Objednatele, mohou být prováděna i mimo

prostory Objednatele, není-li Objednatelem v prováděcí smlouvě 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 Vízovém informačním systému, musí podepsat

závazek o mlčenlivosti.

2.10.3 Komunikační jazyk

Základním komunikačním jazykem se Objednatelem 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 bude vyvíjet v technologii .NET klientské aplikace systému a nové komponenty systému podle specifikace Objednatele, pokud nebude v konkrétní prováděcí smlouvě specifikováno jinak.

Ostatní komponenty systému, které jsou již integrované a využívané budou rozvíjeny primárně v platformě JAVA a JEE, pokud nebude v konkrétní prováděcí smlouvě možné použít vývoj v platformě .NET nebo nebude specifikováno jinak.

Příloha A: Detailní specifikace služeb A1

1 Procesní analýza NS-VIS

Zde jsou uvedeny procesy, které budou v rámci řešení realizovány v klientských aplikacích NS-VIS

(KA VÍZA, KA VYČKAT, KA ADMINISTRACE, KA VISMail).

1.1 Přehled procesů NS-VIS – stručný popis

Přehled procesů definuje u každého procesu jednoznačné označení procesu (Pxxx, kde xxx je pořadové číslo), název procesu, typ procesu.

Označen í	Název procesu	Typ procesu
P001	Proces krátkodobých víz pořízených na ZÚ	Proces krátkodobých víz
P002	Proces krátkodobých víz pořízených na území	Proces krátkodobých víz
P003	Proces krátkodobých víz pořízených na hranicích v 2. linii	Proces krátkodobých víz
P004	Proces krátkodobých víz pořízených ČR v zastoupení jiného státu (zastupujícím státem je ČR)	Proces krátkodobých víz
P005	Proces krátkodobých víz pořízených ČR v zastoupení jiného státu za ČR	Proces krátkodobých víz
P006	Prodloužení doby pobytu krátkodobého víza	Proces krátkodobých víz
P007a	Zpětvzetí žádosti o krátkodobé vízum	Proces krátkodobých víz
P007b	Prohlášení víza za neplatné – annull visa	Proces krátkodobých víz
P007c	Zrušení víza – revoke visa	Proces krátkodobých víz
P007d	Invalidace štítku z důvodu úřední chyby	Proces krátkodobých víz
P008	Proces dlouhodobých víz pořízených na ZÚ	Proces dlouhodobých víz
P012	Proces zpracování konzultací VISMail 2 požadované jinými státy schengenské dohody	Proces VISION/VIS Mail 2
P013	Zpracování zprávy 26 při udělení VLTV víza jiným státem	Proces VISION/VIS Mail 2
P017	Proces statistické dotazy	Pomocné procesy
P018	Proces dotazů na žádosti	Pomocné procesy
P019a	Proces mobilní kontroly	Proces mobilní kontroly
P019b	Proces mobilní kontroly – aktualizace dat mobilního zařízení	Proces mobilní kontroly
P020	Proces administrace	Proces administrace
P022	Zrušení platnosti dlouhodobého víza z CIS	Proces dlouhodobých víz
P023	Zneplatnění dlouhodobého víza z CIS	Proces dlouhodobých víz
P026	Ověření totožnosti na území	Proces kontrola
P033	Oprava linkování žádosti	Proces krátkodobých víz
P037	Kontrola totožnosti Bezpečnostní důvody	Proces kontrola
P038	Přiřadit množinu žádosti do jedné Skupiny (Group)	Proces krátkodobých víz
P039	Vyřadit žádost ze Skupiny (Group)	Proces krátkodobých víz

P040	Kontrola totožnosti na hranicích – 2. linie	Proces kontrola
P041	Zpracování dlouhodobých diplomatických a zvláštní víz a pobytů pro diplomaty	Proces diplomatických víz
P042	Proces lustrace z CIS v žádostech a vízech uložených v NS- VIS	Proces lustrace z CIS
P043	Proces lustrace z CIS v záznamech o průjezdu hranice uložených v NS-VIS	Proces lustrace z CIS
P044	Proces lustrace z UBY CIS ve vízech v NS-VIS	Proces lustrace z CIS
P045	Smazání žádosti o krátkodobé vízum založené na území	Proces krátkodobých víz
P047	Opravení důvodu revokace vízového štítku	Proces krátkodobých víz

1.1.1 P001 Proces krátkodobých víz pořízených na ZÚ

Procesem krátkodobých víz pořízených na ZÚ je vydáváno schengenské vízum bez omezené územní působnosti nebo s omezenou územní působností. Proces krátkodobých víz pořízených na ZÚ se skládá ze subprocesů: pořízení žádosti, bezpečnostní prověrky a rozhodnutí o vydání víza. Pořízení žádosti a rozhodnutí o vydání víza je realizováno v systému EVC2 na MZV. Do NS-VIS MV je žádost předána k bezpečnostní prověrce. Bezpečností prověrka ŽOV je složená z automatické bezpečnostní prověrky v definovaných lustračních databázích, která obsahuje ve stanovených případech požadavek na automaticky vytvářenou konzultaci systémem VIS Mail 2 a prověrky u zpravodajských služeb. Bezpečnostní prověrka se řídí sadou definovaných pravidel. V případě pozitivní lustrace nebo rozporů v bezpečnostní prověrce jsou situace řešeny na spec. pracovišti v KA VYČKAT. Zpracování na tomto pracovišti je vícestupňové. Pokud nastane v automatické bezpečnostní prověrce chyba, je umožněno ruční nastavení celkového stanoviska k žádosti, na spec. pracovišti v KA VYČKAT. Celkového stanovisko k žádosti je předáváno do systému EVC2 na MZV. V procesu je možné zasílat požadavky na doplňkové dokumenty a doplňkové dokumenty na MZV a přijímat doplňkové dokumenty z MZV. V procesu je možné zasílat textové zprávy na MZV a přijímat textové zprávy z MZV. Data žádosti jsou předávána do CS-VIS. Ve vybraných případech je odeslána informace ostatním nebo vybraným zemím schengenského prostoru prostřednictvím systému VIS Mail 2. Do NS-VIS MV je předávána informace o vydání víza na MZV. Součástí žádosti jsou biometrická data žadatele.

1.1.2 P002 Proces krátkodobých víz pořízených na území

Procesem krátkodobých víz pořízených na území je vydáváno schengenské vízum bez omezené územní působnosti nebo s omezenou územní působností. Proces krátkodobých víz pořízených na území se skládá ze subprocesů: založení žádosti o vízum na území, vyhledání předchozích žádostí žadatele v CS-VIS nebo NS-VIS, provedení bezpečnostní prověrky v definovaných lustračních databázích, vydání rozhodnutí o žádosti. Postup vytvoření žádosti o vízum obsahuje sled předepsaných operací v CS-VIS.

Informace o vydání žádosti a víza je předávána zpravodajským službám a do CS-VIS. Ve vybraných případech je automaticky odeslána informace ostatním nebo vybraným zemím schengenského prostoru prostřednictvím systému VIS Mail 2. Proces je realizován v KA VÍZA, pro vydávání víz. Součástí žádosti jsou biometrická data žadatele.

1.1.3 P003 Proces krátkodobých víz na hranicích v 2. linii

Postup je shodný s procesem krátkodobých víz na území ČR viz. P002 vyjma rozdílu v osobě uživatele

a v pracovišti, na kterém je proces realizován.

1.1.4 P004 Proces krátkodobých víz pořízených ČR v zastoupení jiného státu (Česká

republika zastupuje)

Procesem krátkodobých víz pořízených ČR v zastoupení jiného státu je vydáváno schengenské vízum bez omezené územní působnosti nebo s omezenou územní působností. Pořízení žádosti a rozhodnutí o vydání víza je realizováno v systému EVC2 na MZV. Při předání žádosti do NS-VIS je vyhodnoceno

o jaký typ zastupování se jedná. Dle toho pokračuje další zpracování dle popisu P001 nebo P004. Do NS-VIS MV je žádost předána k bezpečnostní prověrce v definovaných lustračních databázích. Bezpečnostní prověrka se řídí sadou definovaných pravidel. V případě pozitivní lustrace nebo rozporů v bezpečnostní prověrce jsou situace řešeny na spec. pracovišti v KA VYČKAT. Zpracování na tomto pracovišti je vícestupňové. Pokud nastane v automatické bezpečnostní prověrce chyba, je umožněno ruční nastavení celkového stanoviska k žádosti, na spec. pracovišti v KA VYČKAT. Dle výsledku bezpečnostní prověrky systém vytváří automaticky VIS Mail 2 zprávu, kterou žádá členský stát, který zastupuje o stanovisko. Celkového stanovisko k žádosti je předáváno do systému EVC2 na MZV. V procesu je možné zasílat požadavky na doplňkové dokumenty a doplňkové dokumenty na MZV a přijímat doplňkové dokumenty z MZV. V procesu je možné zasílat textové zprávy na MZV a přijímat textové zprávy z MZV. Data žádosti jsou předávána do CS-VIS. Ve vybraných případech je odeslána informace ostatním nebo vybraným zemím schengenského prostoru prostřednictvím systému VIS Mail

2. Po přijetí stanoviska členského státu prostřednictvím spec. druhu VIS Mail 2 zprávy, systém automaticky vytvoří stanovisko pro systém MZV. Informace o založení žádosti a vydání víza jsou předávány na zpravodajské služby. Do NS-VIS MV je předávána informace o vydání víza na MZV. Součástí žádosti jsou biometrická data žadatele.

1.1.5 P005 Proces krátkodobých víz pořízených ČR v zastoupení jiného státu za ČR (Česká republika je zastupována)

Procesem krátkodobých víz pořízených ČR v zastoupení jiného státu za ČR je vydáváno schengenské vízum bez omezené územní působnosti nebo s omezenou územní působností. Žádost je pořízena jiným členským státem. Tento členský stát zašle do NS-VIS prostřednictvím spec. VIS Mail2 zprávy požadavek na stanovisko ČR k žádosti. Systém NS-VIS získá automaticky data o žadateli z CS-VIS, provede automatickou bezpečnostní prověrku. Bezpečností prověrka takové žádosti je složená z automatické bezpečnostní prověrky v definovaných lustračních databázích a prověrky u zpravodajských služeb. Bezpečnostní prověrka se řídí sadou definovaných pravidel. V případě pozitivní lustrace nebo rozporů v bezpečnostní prověrce jsou situace řešeny na spec. pracovišti v KA VYČKAT. Zpracování na tomto pracovišti je vícestupňové. Pokud nastane v automatické bezpečnostní prověrce chyba, je umožněno ruční nastavení celkového stanoviska k žádosti, na spec. pracovišti v KA VYČKAT. Po vytvoření stanoviska ČR k žádosti systém automaticky zpracuje odpověď ve formě spec. typu zprávy VIS Mail 2 a odešle ji zpět do zastupujícího členského státu. Vydání nebo zamítnutí víza dochází mimo systém NS-VIS. Oprávnění přijetí tohoto typu zpráv ke zpracování do NS-VIS se řídí spec. definovanými pravidly.

1.1.6 P006 Prodloužení doby pobytu krátkodobého víza

Procesem prodloužení doby pobytu krátkodobého víza je vydáváno schengenské vízum bez omezené územní působnosti nebo s omezenou územní působností. Proces je složen ze subprocesů: vyhledání prodlužované žádosti v CS-VIS, vytvoření nové prodloužené žádosti s vazbou na předchozí žádost, možností více způsobů pro získání fotografie žadatele, provedení bezpečnostní prověrky v definovaných lustračních databázích cizince, vydání rozhodnutí o žádosti. Informace o vydání žádosti a víza je předávána zpravodajským službám. Informace o prodloužení vízového štítku je předávána do CS-VIS k původní žádosti. Ve vybraných případech je automaticky odeslána informace ostatním nebo vybraným zemím schengenského prostoru prostřednictvím systému VIS Mail 2. Proces je realizován v KA VÍZA, pro vydávání víz. Součástí žádosti jsou biometrická data žadatele.

1.1.7 P007a Zpětvzetí žádosti o krátkodobé vízum

Proces Zpětvzetí žádosti o krátkodobé vízum může být realizován na ZÚ, na hranicích i na území. Informace o zpětvzetí je zaznamenána v NS-VIS. Informace o zpětvzetí žádosti je předávána do v CS- VIS a zpravodajským službám. Proces je realizován v KA VÍZA. Pokud je proces realizován v systému EVC2 na MZV, je informace předávána z EVC2 do NS-VIS, CS-VIS a zpravodajským službám.

1.1.8 P007b Prohlášení víza za neplatné – annull visa

Proces Prohlášení víza za neplatné – annull visa je realizován na ZÚ, na hranicích i na území.

Skládá se ze subprocesů: vyhledání žádosti v CS-VIS, zrušení krátkodobého víza. Informace o zrušení víza je uložena v NS-VIS a předávána do v CS-VIS a zpravodajským službám. Proces je realizován v KA VÍZA. Pokud je proces realizován v systému EVC2 na MZV, je informace předávána z EVC2 do NS-VIS, CS-VIS a zpravodajským službám.

1.1.9 P007c Zrušení víza – revoke visa

Proces Zrušení víza – revoke visa je realizován na ZÚ, na hranicích i na území. Skládá se ze subprocesů: vyhledání žádosti v CS-VIS, zrušení krátkodobého víza. Informace o zrušení víza je uložena v NS-VIS a předávána do v CS-VIS a zpravodajským službám. Proces je realizován v KA VÍZA. Pokud je proces realizován v systému EVC2 na MZV, je informace předávána z EVC2 do NS- VIS, CS-VIS a zpravodajským službám.

1.1.10 P007d Invalidace štítku z důvodu úřední chyby

Proces Invalidace štítku z důvodu úřední chyby je realizován na ZÚ, na hranicích nebo na území. Skládá se ze subprocesů: vyhledání žádosti v CS-VIS, provedení invalidace štítku v NS-VIS a smazání štítku v CS-VIS. Informace o invalidaci štítku je předávána zpravodajským službám. Proces je realizován v KA VÍZA. Pokud je proces realizován v systému EVC2 na MZV, je informace předávána z EVC2 do NS-VIS, CS-VIS a zpravodajským službám.

1.1.11 P008 Proces dlouhodobých víz pořízených na ZÚ

Pořízení žádosti a vydání víza je realizováno v systému EVC2 na MZV. Data žádosti jsou předána do NS-VIS. Data žádosti jsou předávána k posouzení zpravodajským službám. Data žádosti jsou stahována do systému CIS, kde jsou v OAMP lustrována a prověřována. V KA VYČKAT vytváří pracovníci OAMP stanovisko k žádosti, které je předáváno do systému EVC2 MZV. V procesu je možné zasílat požadavky na doplňkové dokumenty a doplňkové dokumenty na MZV a přijímat doplňkové dokumenty z MZV. V procesu je možné zasílat textové zprávy na MZV a přijímat textové zprávy z MZV. V současné době je realizován projekt, který umožní uživateli tyto činnosti provádět přímo v klientu CIS bez nutnosti přepínat do klientu KA VYČKAT. Do NS-VIS je předávána informace o vydání víza na MZV. Informace o dlouhodobých vízech nejsou přenášeny do CS-VIS. Součástí žádosti jsou biometrická data žadatele.

1.1.12 P012 Proces zpracování konzultací VISMail 2

Proces zpracování konzultací VISION požadované jinými státy schengenské dohody byl nahrazen procesem zpracování VIS Mail 2 konzultací. V procesu jsou systémem VIS Mail 2 přijímány do NS- VIS spec. zprávy s žádostí jiných členských států o konzultaci při procesu vydání víza. V NS-VIS je ověřováno dle specifikovaných pravidel, zda je možné tyto konzultace zpracovat. Při zpracování konzultací jsou z CS-VIS automaticky získávána data potřebná pro vyřízení konzultace a nad žádostí je prováděna automatická bezpečnostní prověrka.

Bezpečností prověrka je složená z automatické bezpečnostní prověrky v definovaných lustračních databázích a prověrky u zpravodajských služeb. Bezpečnostní prověrka se řídí sadou definovaných pravidel. V případě pozitivní lustrace nebo rozporů v bezpečnostní prověrce jsou situace řešeny na spec. pracovišti v KA VYČKAT. Zpracování na tomto pracovišti je vícestupňové. Pokud nastane v automatické bezpečnostní prověrce chyba, je umožněno ruční nastavení celkového stanoviska k žádosti, na spec. pracovišti v KA VYČKAT. Pro vyřízení konzultace jsou definována pravidla a lhůty pro vyřízení. Dle výsledku bezpečnostní prověrky systém vytváří automaticky spec. VIS Mail 2 zprávu s odpovědí, kterou odesílá členskému státu.

1.1.13 P013 Proces zpracování zprávy 26 při udělení VLTV víza jiným státem

Proces zpracování formuláře C při udělení VLTV víza jiným státem byl nahrazen procesem zpracování spec. Vis Mail 2 zprávy pro přijetí VLTV notifikace. V procesu jsou systémem VIS Mail 2 přijímány do NS-VIS spec. zprávy s informací jiných členských států o vydání VLTV víza. Při zpracování

informací jsou z CS-VIS automaticky získávána data potřebná pro provedení automatické bezpečnostní prověrky v definovaných lustračních databázích. Bezpečnostní prověrka se řídí sadou definovaných pravidel. V případě pozitivní lustrace v bezpečnostní prověrce jsou situace řešeny na spec. pracovišti v KA VYČKAT. Informace o přijetí notifikace o vydání VLTV víza je předávána na zpravodajské služby.

1.1.14 P017 Proces statistické dotazy

V procesu statistické dotazy jsou vytvářeny hierarchické a nehierarchické statistiky a časové snímky. Statistiky je možné zobrazovat v KA VYČKAT a v KA VÍZA.

1.1.15 P018 Proces dotazů na žádosti

Proces dotazů na žádosti umožní provádění:

• Jednoduchých dotazů do NS-VIS

• Rozšířených dotazů do NS-VIS

• Dotazů do CS-VIS

V procesu dotazů uživatel vyplní položky vyhledávacího formuláře a spustí dotaz. Aplikace provede vyhledání ve všech povolených typech dat a zobrazí nalezené záznamy a umožní uživateli zobrazit další podrobnosti o záznamu. Na detailu žádosti lze zobrazovat informace o žádosti, konzultacích VISMail 1 a VISMail 2, doplňkových dokumentech, textových zprávách, linkování, skupině, historii žádosti a nastavených rozhodnutích. Pro Dotazy do CS-VIS jsou nabízeny typy hledání a jednotlivé varianty dotazů dle nastavení authorit uživatele. Na detailu žádosti je možné zobrazovat informace o linkování žádosti a zařazení žádosti do skupiny. Dotazy je možné provádět v KA VYČKAT a v KA VÍZA.

1.1.16 P019a Proces mobilní kontroly

Proces mobilní kontroly umožňuje lustrovat osoby, doklady a vozidla na základě zadaných vyhledávacích kritérií v lokálních kopiích databází uložených v NS-VIS. Zařízení pro mobilní lustraci umožní načíst údaje o cizinci ze strojově čitelné zóny cestovního dokladu nebo pomocí ručního zadání.

1.1.17 P019b Proces mobilní kontroly – aktualizace dat mobilního zařízení

Proces mobilní kontroly – aktualizace dat mobilního zařízení provede aktualizaci dat lokální kopie databází mobilního zařízení. Pro aktualizaci je nutné zařízení připojit k síti.

1.1.18 P020 Proces administrace

Proces administrace umožňuje realizovat subprocesy:

• Databázové dotazy

• Databázové dotazy CS-VIS

• Parametry pro klienty

• Výčtové typy pro klienty

• Parametry pro server

• Nastavení parametrů stanic

• Tiskové a snímací definice

• Tisková a snímací zařízení

• Správa statistických dotazů

• Aktualizace lustračních databází

• Prohlížení logů

• Prohlížení notifikací

• Správa vyhrazených informací

• Správa kódovníků zemí

• Správa kódovníků systému

• Správa mapování

• Správa Karet uživatelů

• Typ a znak víza

• Správa organizační struktury

• Nezařazené útvary

• Správa bublinkové nápovědy

Procesy jsou realizovány KA ADMINISTRACE NS-VIS.

1.1.19 P022 Zrušení platnosti dlouhodobého víza z CIS

Proces Zrušení platnosti dlouhodobého víza z CIS je realizován na území v KA CIS. CIS zašle podnět ke zrušení víza do NS-VIS. Dlouhodobé vízum je zrušeno v NS-VIS.

1.1.20 P023 Zneplatnění dlouhodobého víza z CIS

Proces Zneplatnění dlouhodobého víza z CIS je realizován na území v KA CIS. CIS zašle podnět ke

zneplatnění víza do NS-VIS. Dlouhodobé vízum je zneplatněno v NS-VIS.

1.1.21 P026 Ověření totožnosti na území

V procesu P026 Ověření totožnosti na území umožňuje zadat data o ověřované osobě (ruční editací nebo načtením dat z MRZ nebo sejmutím otisků), provedení lustrace osoby v definovaných lustračních databázích (alfanumerické či biometrické), vyhledání žádostí prověřované osoby v NS-VIS i v CS- VIS. Pro žádosti vyhledané v CS-VIS umožňuje zobrazit obsah dossieru, zobrazit obsah skupiny a ověřit totožnost žadatele dle otisků prstů (ověření platnosti krátkodobého víza či lustrace dle otisků prstů v SIS2). Pro vyhledání žádostí v CS-VIS jsou nabízeny jednotlivé varianty dotazů dle nastavení authorit uživatele.

Proces je realizován v KA VÍZA.

1.1.22 P033 Oprava linkování žádosti

Proces Oprava linkování žádosti se skládá z vyhledání žádosti v NS-VIS, zobrazení seznamu žádostí, které jsou se zvolenou žádostí v jednom dossieru, odlinkování zvolené žádosti z dossieru, nalezení seznamu všech žádostí žadatele v CS-VIS, výběru vhodného kandidáta pro linkování a provedení linkování v CS-VIS. Proces je realizován v KA VÍZA.

1.1.23 P037 Kontrola totožnosti Bezpečnostní důvody

Proces Kontrola totožnosti - bezpečnostní důvody je využíván pro speciální případy, za účelem vyšetřování a předcházení terorizmu nebo závažné trestné činnosti. Proces umožňuje vybraným pracovníkům krajských ředitelství odboru cizinecké policie a útvarům se zařazením bezpečnostní orgány vyhledávat v CS-VIS a NS-VIS. Pro žádosti vyhledané v CS-VIS umožňuje zobrazit obsah dossieru, zobrazit obsah skupiny a ověřit totožnost žadatele dle otisků prstů, stažení binárního souboru otisků prstů, spustit mimořádnou bezpečnostní prověrku v SIS2 dle otisků prstů na definovanou množinu žádostí nalezených dle alfanumerických údajů v NS-VIS nebo CS-VIS. V procesu je možné vyhledání v CS-VIS dle otisků prstů získaných z NIST souboru, načteného z definovaného datového úložiště. Jako důvod dotazu do CS-VIS je přednastavena varianta bezpečnostní orgány. V procesu musí uživatel povinně vyplňovat Důvod dotazu, který je zaznamenáván do logu systému NS-VIS. Proces je dostupný pouze pro vybrané pracovníky s autoritou bezpečnostní orgány, přístup k tomuto procesu je řízen spec. definovanou rolí. Proces je realizován v KA VÍZA.

1.1.24 P038 Přiřadit množinu žádosti do jedné Skupiny (Group)

Proces Vytvořit novou skupinu umožňuje přiřazení množiny žádosti do jedné skupiny v CS-VIS. Proces umožní uživateli postupně vyhledat všechny žádosti, které budou následně přiřazeny do jedné skupiny v CS-VIS. Proces je realizován v KA VÍZA.

1.1.25 P039 Vyřadit žádost ze Skupiny (Group)

Proces Vyřadit žádost ze skupiny umožňuje vyřazení žádosti ze skupiny v CS-VIS. Proces je realizován v KA VÍZA.

1.1.26 P040 Kontrola totožnosti na hranicích – 2. linie

Proces Kontrola totožnosti na hranicích – 2. linie umožňuje pracovníkům hranice vyhledávat v CS- VIS a vyhledávat v NS-VIS a zobrazovat detail žádosti. Pro žádosti vyhledané v CS-VIS umožňuje zobrazit obsah dossieru, zobrazit obsah skupiny a ověřit totožnost žadatele dle otisků prstů, spustit mimořádnou bezpečnostní prověrku dle alfanumerických údajů či biometrických údajů v SIS2. Jako důvod dotazu je přednastavena varianta kontrola na hranicích. Tento proces umožňuje zobrazení podoby otisků připojených k žádostem vyhledaným v CS-VIS. Proces je realizován v KA VÍZA.

1.1.27 P041 Zpracování dlouhodobých diplomatických a zvláštní víz a pobytů pro

diplomaty

Proces Zpracování dlouhodobých diplomatických a zvláštní víz a pobytů pro diplomaty umožňuje zpracovat diplomatická a zvláštní víza a pobyty pro diplomaty v samostatném procesu. Pořízení žádosti a rozhodnutí o vydání víza je realizováno v systému EVC2 na MZV. Nad žádostmi zpracovanými v tomto procesu je prováděna automatická bezpečnostní prověrka v definovaných lustračních databázích. V případě záchytu hitů v automatické bezpečnostní prověrce je pracovníkům, se speciální rolí, umožněno ruční vyhodnocení výsledků bezpečnostní prověrky, potvrzení stanoviska a řešení rozporů při kompletaci stanovisek na spec. pracovišti v KA VYČKAT. Pokud nastane v automatické bezpečnostní prověrce chyba, je pracovníkům, se speciální rolí, umožněno ruční nastavení celkového stanoviska k žádosti. V procesu je možné zasílat požadavky na doplňkové dokumenty a doplňkové dokumenty na MZV a přijímat doplňkové dokumenty z MZV. V procesu je možné zasílat textové zprávy na MZV a přijímat textové zprávy z MZV. Do NS-VIS MV je předávána informace o vydání víza na MZV. Součástí žádosti jsou biometrická data žadatele.

1.1.28 P042 Proces lustrace z CIS v žádostech a vízech uložených v NS-VIS

Proces lustrace z CIS v žádostech a vízech uložených v NS-VIS je realizován na území v KA CIS. CIS zašle podnět k vyhledání, podle výběrových kritérií, v žádostech a vízech v NS-VIS (hledání bude provedeno v dlouhodobých žádostech, krátkodobých žádostech, v udělených schengenských vízech a VLTV vízech).

1.1.29 P043 Proces lustrace z CIS v záznamech o průjezdu hranice uložených v NS-VIS Proces lustrace z CIS v záznamech o průjezdu hranice uložených v NS-VIS je realizován na území v KA CIS. CIS zašle podnět k vyhledání, podle výběrových kritérií, v záznamech o průjezdu v NS-VIS.

1.1.30 P044 Proces lustrace z UBY CIS ve vízech v NS-VIS

Proces lustrace z UBY CIS ve vízech v NS-VIS je realizován na území systémem CIS – jedná se o

automatické zpracování. CIS zašle podnět k vyhledání, podle čísla štítku, ve vízech v NS-VIS.

1.1.31 P045 Smazání žádosti o krátkodobé vízum založené na území

Proces Smazání žádosti o krátkodobé vízum založené na území umožní převedení žádosti v NS-VIS do stavu Smazána (deleted). Žádost bude smazaná v CS-VIS.

1.1.32 P047 Opravení důvodu revokace vízového štítku

Proces opravení důvodu revokace vízového štítku umožní změnit důvod revokace vízového štítku.

1.2 Přehled procesů VIS Mail

Označení	Název procesu	Typ procesu
ADM-100	Spravovat číselníky	Proces administrace
ADM-110	Aktualizovat číselník Orgán	Proces administrace
ADM-111	Prohlížet notifikace k číselníku Orgán	Proces administrace
ADM-20	Prohlížet zprávy pro administrátora	Xxxxxx administrace
DOT-100	Provést SQL dotaz	Proces administrace
OPE-10	Vytvořit novou zprávu	Proces Vis Mail
OPE-20	Prohlížet zprávy pro operátora	Proces Vis Mail
OPE-30	Získat data vybrané záložky Detailu žádosti NS-VIS	Proces Vis Mail
MZI-10	Odeslat zprávu z MZV	Systémový proces
VII-10	Odeslat zprávu z NS-VIS	Systémový proces
SYS-10	Automatické zpracování	Systémový proces

1.2.1 ADM-100 - Spravovat číselníky

Scénář umožní spravovat číselníky VIS Mail: Země, Typ orgánu, Orgán, Typ dokumentu, Typ přílohy, Útvar, ZÚ, Oprávněnost příchozího zastupování.

1.2.2 ADM-110 - Aktualizovat číselník Orgán

Scénář umožní aktualizovat číselník Orgán z CS-VIS. Scénář zobrazí report provedených změn a chyb vzniklých při aktualizaci a seznam vazeb na organizační jednotky a ZÚ.

1.2.3 ADM-111 - Prohlížet notifikace k číselníku Orgán

Scénář umožní prohlížet notifikace k číselníku Orgán.

1.2.4 ADM-20 - Prohlížet zprávy pro administrátora

Scénář umožní prohlížet zprávy pro administrátora:

• Prohlížet odeslaná potvrzení přijatých chybných zpráv.

• Prohlížet všechny odeslané chybné zprávy.

• Prohlížet přijaté zprávy Handshake

• Prohlížet odeslané zprávy Handshake

• Vytvořit zprávu Handshake

1.2.5 DOT-100 - Provést SQL dotaz

Scénář umožní provést SQL dotaz v DB VISMail.

1.2.6 OPE-10 - Vytvořit novou zprávu

Scénář umožní vytvořit novou VIS Mail 1 zprávu v KA VYČKAT i v KA VÍZA.

• Vytvořit požadavek na spolupráci z VIS Mail.

• Vytvořit požadavek na podpůrné dokumenty z VIS Mail.

• Vytvořit požadavek na opravu údajů ze žádosti z VIS Mail.

• Vytvořit informaci o spolupráci z VIS Mail.

• Vytvořit informaci o získání státní příslušnosti z VIS Mail.

1.2.7 OPE-20 - Prohlížet zprávy pro operátora

Scénář umožní prohlížet VIS Mail 1 zprávy pro operátora v KA VYČKAT i v KA VÍZA.

• Prohlížet příchozí nevyřízené zprávy.

• Prohlížet historii zpráv.

• Prohlížet odeslané nevyřízené chybné zprávy.

• Prohlížet odeslané požadavky a informace.

1.2.8 OPE-30 - Získat data vybrané záložky Detailu žádosti NS-VIS

Scénář umožní získat data vybrané záložky Detailu žádosti NS-VIS.

• Zobrazit obsah záložky VIS Mail 1 v KA VYČKAT i v KA VÍZA

• Zobrazit obsah záložky VIS Mail 2 v KA VYČKAT.

1.2.9 MZI-10 - Odeslat zprávu z MZV

Scénář umožní odeslat zprávu z MZV

• požadavek na spolupráci z MZV.

• odpověď na spolupráci z MZV.

• informaci o spolupráci z MZV.

• požadavek na podpůrné dokumenty z MZV.

• odpověď na podpůrné dokumenty z MZV.

• požadavek na opravu údajů ze žádosti z MZV.

• odpověď na opravu údajů ze žádosti z MZV.

• informaci o získání státní příslušnosti z MZV.

1.2.10 VII-10 - Odeslat zprávu z NS-VIS

Scénář umožní odeslat zprávu z NS-VIS

• požadavek na konzultaci z NS-VIS do VIS Mail.

• odpověď na konzultaci z NS-VIS do VIS Mail.

• požadavek na konzultaci při zastupování z NS-VIS do VIS Mail.

• odpověď na konzultaci při zastupování z NS-VIS do VIS Mail.

• informaci o udělení víza z NS-VIS do VIS Mail.

• informaci o udělení VLTV víza NS-VIS do VIS Mail.

• potvrzení o výsledku zpracování zprávy VIS Mail2 v NS-VIS do VIS Mail.

1.2.11 SYS-10 - Automatické zpracování

Scénář umožní automatické zpracování

• Přijmout zprávu z VIS Mail.

• Opakovaně odeslat nedoručené zprávy.

• Najít zprávy VIS Mail2 ve stavu čeká na odpověď NS-VIS.

• Najít odchozí zprávy VISMail2 (typu 21, 23, 25, 26) ve stavu čeká na zápis dat do CS-VIS.

2 Technická podpora fixní část

Služby představující pravidelné činnosti, jak je definováno v kapitole 2.1.1 Plnění A+ - Poskytování podpory provozu systému – fixní část

Poskytování technické podpory provozu NS-VIS - 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	Dohodnutá frekvence	Orientační počet hodin/měsíc
Bude poskytována služba Helpdesku – Single Point Of Contact. Helpdesk bude sloužit jak pro zaznamenávání případných závad, problémů, tak dotazů zodpovědných osob jmenovaných zákazníkem. Dostupnost systému, systém pro nahlášení problémů, závad v režimu 24x7, zajištění reaktivních služeb podpory zaměřených na řešení problémů a závad, které nebylo možné odhalit v rámci proaktivních služeb supportu v režimu 5x9 (v pracovní dny 8:00 – 17:00 hod).	Kontinuálně v časech dle specifikace	Nelze jednoznačně kvantifikovat. cca 96 pro 1st level support, plus údržba , kontrola systému
Databáze NS-VIS + VIS Mail:		86
Kontrola konzistence databázových schémat a číselníků NS-VIS (dokumentace a release management, úprava skriptů v souladu s procesy NS-VIS).	kontinuálně
Ladění výkonnosti - ověřování databázově intenzivních a pomalých dotazů (časté nebo náročné operace), dle business procesů designu NS-VISu, hledání optimalizací v databázi i v business procesech systému NS-VIS, doplňování indexů, nutné úpravy konfigurací.	kontinuálně
Údržba produkčních databází, tabulek NS-VIS, kontrola a aktualizace číselníků, skriptů, dle aktuálních požadavků a potřeb, aplikace bezpečnostních aktualizací a doporučení, upgrade DB.	kontinuálně
Údržba testovacích databází, tabulek NS-VIS, kontrola a aktualizace číselníků, skriptů, anonymizace dat, udržování reálného obrazu produkce, dle aktuálních požadavků na ladění výkonu NS-VIS.	kontinuálně
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 NS-VIS.	kontinuálně
Plánování úložišť – optimalizace fyzického designu, rozložení I/O v ASM, sledování trendů růstu, Oracle Partitioning - činnosti a akce na základě minulých trendů růstu velikosti databáze NS- VIS a plánových změn rozvoje systému NS-VIS. Návrhy odmazávání dat dle procesů a požadavků na uchování dat v systému NS-VIS).	kontinuálně

Údržba kódu PL/SQL a SQL pro zlepšení výkonnosti, drobné vylepšení ve funkcionalitě. PL/SQL kódů.	kontinuálně
Kontrola logů Oracle a jejich posouzení na dopad funkčnosti (kritičnosti) systému NS-VIS, indikace problémů včetně klasifikace ve kterém modulu a procesu NS-VIS problém nastává, návrh řešení.	kontinuálně
Kontrola integrity nastavení Oracle s ohledem na procesy NS- VIS včetně kontroly funkcí Oracle DataGuard	kontinuálně
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ů NS-VIS.	kontinuálně
Provozní deník support Objednateli se správou a vedením provozního deníku systému NS-VIS	kontinuálně
Technická a provozní dokumentace vytvoření, zpracování změn s ohledem na provoz rozvoj a úpravy systému	čtvrtletně / při změnách	24
Návrh architektury a rozvoje vytvoření či úpravy arch. řešení s ohledem na provoz rozvoj a úpravy systému	kontinuálně	8
Infrastruktura NS-VIS + VIS Mail:	Kontinuálně / cca 1x týdně	40
Diagnostika hardwarového vybavení a systémových událostí prostředí NS-VIS pomocí management nástrojů:
• IBM Flex Chassis Management Console
• IBM Flex System Fabric Scalable Switch Management Console
• IBM Flex System SAN Scalable Switch Management Console
• IBM BladeCenter Disk Storage Module Console
• IBM BNT Ethernet Switch Module Console
• Expertní podpora a konzultace při řešení HW závad s ohledem na topologii systému a procesy NS-VIS
Kontrola operačního systému RedHat Enterprise Linux s ohledem na prostředí a procesy NS-VIS (1x týdně):
• podrobná kontrola systémových a chybových logů
• expertní kontrola spuštěných procesů
• kontrola zaplnění souborových systémů a zajištění požadovaných volných kapacit nutných pro provoz 24x7 na základě provozních charakteristik NS-VIS
• kontrola stavu skupin disků a vyhodnocení automatického monitorování pomocí smartd
• pravidelná systémová aktualizace RHEL s ohledem na aplikační moduly NS-VIS

• sledování a vyhodnocování zatížení systémových zdrojů serverů pomocí NMON Performance Monitor for Linux
Kontrola a podpora KVM/VMware virtualizačních služeb
Kontrola LAN – status ACE sond, vyhodnocení a revize FWSM access listů, stav BGP směrování CS-VIS s ohledem na komunikační matici NS-VIS
Kontrola SAN - logů a integrity konfigurace aktivních prvků SAN
Kontrola datové komunikace a případné testy konektivity NS-VIS a VIS Mail na centrální systémy EU ( CSVIS a CVISMAIL)
Expertní podpora a konzultace propojení NS-VIS s externími systémy (EVC2, ZS, SISII, ICIS, CIS, CSML G2, ZC-CIS, PATROS, ISOP, CSL, CMS) s ohledem na specifikace rozhraní systému NS-VIS
Údržba systémových SW částí infrastruktury (aplikace opravných fixů a patchů, upgrade firmware)
Optimalizace systémů a případné HW rekonfigurace prvků technologické infrastruktury centrální části NS-VIS a VIS Mail
Expertní podpora s integrací se službami ICT PČR (AD, DNS, NTP aj.)
WebSphere, aplikační vrstva NS-VIS:	Kontinuálně / cca 1x týdně	58
Optimalizace a údržba administračních skriptů NS-VIS (včetně spouštěcích a nastavovacích) pro IBM WebSphere Aplikačních servery a IBM WebSphere HTTP servery NS-VIS
Monitoring, optimalizace a rekonfigurace WebSphere pluginů po změnách v nastavení pro aplikační moduly centrální části NS-VIS
Diagnostika a výkonnostní optimalizace parametrů IBM WebSphere Aplikačních serverů a IBM WebSphere HTTP serverů
Expertní podpora vysoké dostupnosti a konzultace při administraci WebSphere aplikačních clusterů CA a ESB dle procesů NS-VIS
Diagnostika a optimalizace WebSphere Integration Service Bus pro transakční zpracování (JMS messaging) dle procesů NS-VIS
Podrobná expertní kontrola systémových logů WebSphere dle procesů NS-VIS a VIS Mail
Konzultace a pomoc při aktualizaci fix packů IBM WebSphere Aplikačních serverů a IBM WebSphere HTTP serverů
Kontrola nastavení monitorovacích skriptů NS-VIS a VIS Mail, podpora při integraci a realizace rozvoje monitoringu
Support při nefunkčnosti základních (nikoli aplikačních) služeb IBM WebSphere Aplikačních serverů a IBM WebSphere HTTP serverů a při obnovení provozu v případě výpadku či poruchy externího systému

Release management podpora při nasazení nových verzí aplikačních modulů NS-VIS a VIS Mail, údržba, konfigurace produkčního, testovacího a vývojového prostředí
VISMail:		8
Podrobná kontrola systémových logů Lotus Domino dle procesů VISMAIL (běh housekeeping agentů, běh mail routeru, replikačních služeb, aktualizace Symantec LiveUpdate)	1x měsíčně
Kontrola složky vmError v poštovní databází VISMAIL aplikace, kontrola schránky Administrátora na zprávy serveru a CVISMAIL	1x týdně
Monitoring, optimalizace a rekonfigurace SMTP služeb prostřednictvím administračního rozhraní dle procesů VISMAIL	1x měsíčně
Monitoring infrastruktury, analýza logů NS-VIS:		28
Kontrola a podpora nástrojů pro monitoring infrastruktury a analýzu logů NS-VIS (Nagios, LogStash, ElasticSearch, Kibana)	kontinuálně
Týdenní reporting o stavu systému (na týdenní bázi součástí programového výboru hlášení o výpadcích systému-nedostupnosti, externích systémů, stav aktuálnosti KA,aj.), reporty z Helpdesku	1x týdně
Poskytování souhrnného přehledu o zatížení systému z pohledu aplikačního a systémového	měsíčně
Detekce a analýza 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.	Kontinuálně / dle potřeby
Reakce na dotazy uživatelů, Objednatele, Helpdesk	reaktivně	32
Pravidelný měsíční reporting s přehledem významných událostí (reporting a statistiky)	Měsíčně a reaktivně na základě nové verze	32
Specifikace změnových požadavků (ZP) Objednatele, Předběžná analýza a předběžné ocenění prací objednaných z plnění A2 a B	Dle potřeby / požadavku Objednatele	80
Support doplňkových částí:
Analytická podpora pro řešení problémů, vyplývajících z požadavků podpory pro CA, ESB (modulů rozhraní), KA a VIS Mail	reaktivně	20
PM, koordinace, administrativa, řízení kvality	kontinuálně	48
Podpora služeb nutných k zajištění funkčnosti všech modulů a aplikací v případě změn na externí systémy	kontinuálně	80
Bezpečnost (zákon,vyhlášky)		14
Řešení dopadů Autentizace a autorizace, certifikace, ochrana prvků KII, podpora Objednatele na reakce KBI, zvládání mimořádných událostí	kontinuálně
Podpora Objednatele při plánování a provedení testu obnovy	Reaktivně dle požadavku Objednatele

3 Technická podpora variabilní část

Do prací, které je možno objednávat z plnění A.2 Poskytování technické podpory provozu NS-VIS – variabilní část, patří zejména činnosti související se změnou konfigurace systému nebo jeho části, činnosti s vazbou na rozvoj systému a školení. Dále může být požadována zejména podpora s ohledem na aktivity organizované centrální stranou systému (Evropská komise nebo agentura eu-LISA), které vyžadují aktivní účast členských států (jakými jsou například reakce na nové funkční a provozní požadavky, realizace předepsaných testovacích kampaní v rozsahu stanoveném eu-LISA a další činnosti).

A.2 Poskytování technické podpory provozu NS-VIS – variabilní části bude čerpáno samostatnými prováděcími smlouvami na definovaný finanční objem, jejichž přílohou bude soupis objednávaných rolí. Čerpání ze smlouvy není povinné a služby budou čerpány postupně až do ukončení účinnosti dané prováděcí smlouvy. Z důvodu plynulé návaznosti aktivit se různé prováděcí smlouvy na plnění A. 2 mohou poskytováním plnění časově překrývat.

Specifikace služeb	Dohodnutá frekvence	Orientační počet hodin/měsíc
WebSphere, aplikační vrstva NS-VIS:
Expertní podpora a konzultace při administraci a optimalizaci WebService rozhraní na externí systémy dle procesů NS-VIS	Reaktivně - na základě objednávky Objednatele	2
Konzultace nastavení systémových parametrů centrální části NS- VIS	Reaktivně - na základě objednávky Objednatele	2
Komplexní administrace aplikačních rolí NS-VIS a VIS Mail jejich mapování na MS Active Directory, podpora organizačních změn (přesuny organizačních jednotek/zrušení/vytvoření)	Reaktivně - na základě objednávky Objednatele	3
Monitoring infrastruktury, analýza logů NS-VIS:
Tvorba a úprava sond pro monitoring a analýzu	Reaktivně - na základě objednávky Objednatele	8
Technická a ostatní dokumentace systému
Úpravy Bezpečnostní dokumentace v závislosti na změnách spojených s provozem, rozvojem a úpravami systému	Reaktivně - na základě objednávky Objednatele	8
Support Objednateli a analýza dokumentů EU s přímým dopadem na provoz, rozvoj a úpravy systému NS-VIS	Reaktivně - na základě objednávky Objednatele	16

Support Objednateli s tvorbou, úpravou dokumentů PČR s ohledem na provoz, rozvoj a úpravy systému NS-VIS v závislosti na úpravě KA či legislativního rámce EU	Reaktivně - na základě objednávky Objednatele	8
Support Objednateli 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 NS- VIS	Reaktivně - na základě objednávky Objednatele	1
Ú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) systému NS-VIS	Reaktivně - na základě objednávky Objednatele	Nelze kvantifikovat za měsíc: rozdíl je pracnost vytvoření a pak pracnost údržby
Support Objednateli, analýza Interface Control Document, Detailed Technical Specification, Test Design Description (ICD,DTS,TDD)	Reaktivně - na základě objednávky Objednatele	20
Support Objednateli s generováním statistik a reportů pro národní a EU účely	Reaktivně - na základě objednávky Objednatele	8
Podpora komunikace s EU, ČR	Reaktivně - na základě objednávky Objednatele	8
CA, ESB moduly, KA support:
Diagnostiku aplikačních logů	Reaktivně - na základě objednávky Objednatele	12
Diagnostika a řešení problémů, nedostatků	Reaktivně - na základě objednávky Objednatele	8
Monitoring databází, replikací lustračních databází	Reaktivně - na základě objednávky Objednatele	4
Optimalizace výkonnosti	Reaktivně - na základě objednávky Objednatele	6
Monitoring datových výměn s externími systémy	Reaktivně - na základě	4

	objednávky Objednatele
Monitoring aplikací, běhu timerů a zpracování asynchronních služeb	Reaktivně - na základě objednávky Objednatele	6
Analýza provozního stavu na vyžádání Objednatele	Reaktivně - na základě objednávky Objednatele	8
Support doplňkových částí:
Analytická podpora pro řešení problémů, vyplývajících z požadavků provozní podpory	Reaktivně - na základě objednávky Objednatele	8
Analytická podpora pro řešení problémů, vyplývajících z požadavků podpory databáze, řešení problémů s číselníky	Reaktivně - na základě objednávky Objednatele	8
Analytická podpora pro řešení problémů, vyplývajících z požadavků externích systémů, bezpečnostní podpory	Reaktivně - na základě objednávky Objednatele	8
Analytická podpora pro diagnostiku, prevenci a řešení problémů s EU	Reaktivně - na základě objednávky Objednatele	8
Ověření, zkoumání, (re)testy případných problémů, nedostatků	Reaktivně - na základě objednávky Objednatele	8
Vývoj, testování, úprava/doplňování dokumentace, která není uvedena v plnění v rámci fixního supportu dokumentace uvedené v Příloze 1a kapitoly 2.4 Dokumentace systému	Reaktivně - na základě objednávky Objednatele	64
Analýza požadavků Objednatele pro vývoj a analýza požadavků pro drobné změny	Reaktivně - na základě objednávky Objednatele	42
Realizace drobných změn, úprav nutných integrovat adHoc,bez možnosti odkladu	Reaktivně - na základě objednávky Objednatele	32
Podpora a realizace předepsaných testovacích kampaní v rozsahu stanoveném eu-LISA, včetně jejich vyhodnocení a případného opakování	Reaktivně - na základě objednávky Objednatele	nelze kvantifikovat, záleží na TDD

Podpora řízení a správy změn vyvolaných změnami ve funkční specifikaci VIS, stanovenými agenturou eu-LISA	Reaktivně - na základě objednávky Objednatele	Nelze kvantifikovat, záleží na konkrétním případu
Zajištění reakce na nové funkční a provozní požadavky (Požadavek na změnu) kladené na ČR ze strany agentury eu- LISA	Reaktivně - na základě objednávky Objednatele	Nelze kvantifikovat, záleží na konkrétním případu
Ostatní support (koordinace, administrativa, testy, analýza):
Analytická podpora rozborů AF, tedy procesů, případů užití, datového modelu, rozbor rozhraní	Reaktivně - na základě objednávky Objednatele	35
Údržba, konfigurace testovacího a vývojového prostředí, příprava a optimalizace dat pro testovaní a vývoj, synchronizace číselníků	Reaktivně - na základě objednávky Objednatele	14
Podpora Objednatele při plánování a provádění testování vysoké dostupnosti (například test přepnutí do záložní lokality, test BCP, DRP) v intervalu alespoň 1x ročně	Reaktivně - na základě objednávky Objednatele	Nelze určit/rozpočítat na měsíc
Služby na odstranění závad zjištěných po uplynutí záruční doby.	Reaktivně - na základě objednávky Objednatele	Nelze kvantifikovat
Záloha dat v neprodukčním prostředí (testovací a vývojové prostředí)	Reaktivně - na základě objednávky Objednatele	Nelze kvantifikovat
Podpora při evaluacích NS-VIS v ČR	Reaktivně - na základě objednávky Objednatele	24
Zajištění průběžného školení pracovníků Objednatele	Reaktivně - na základě objednávky Objednatele	Nelze kvantifikovat

* V tabulce uvedené hodiny jsou čistě orientační, jsou uvedeny na základě zkušeností dodavatele a nejsou v souladu, nezohledňují počet MD, který Objednatel požaduje nacenit v „NOVÁ Příloha č. 3 - Specifikace ceny za předmět plnění.xlsx“ ZD - v Příloze č.2 této RD „Specifikace ceny za předmět plnění “Plnění A.2 + B, Rozvoj systému NS-VIS a technická podpora na objednávku. A nejsou tedy zohledněny v ceně plnění A2+B.

4 Specifikace vývojového a testovacího prostředí

Nedílnou součástí rozvojových aktivit plnění A a B je zajištění vývoje komponent NS-VIS řešení na vývojovém prostředí (skládajícího se z vývojového prostředí - obrazu testovacího prostředí, vývojového prostředí - obrazu produkčního prostředí) a testovacím prostředí Objednatele k ověření funkčnosti provedených změn.

Vývojové prostředí musí splňovat kritéria pro vývoj systému spadajícího do KII a musí obsahovat:

• kompletní topologii centrální části řešení NS-VIS ESB, CA

• dedikované prostředí pro provádění systémových testů, kompletní topologii řešení systémového testování serverových částí NS-VIS ESB, CA

• dedikované prostředí pro simulaci a řešení provozních problémů - kompletní topologie pro

simulaci provozních problémů - řešení serverové části NSVIS ESB, NSVIS CA

• simulátory externích systémů

• source code management systém

• systém pro release management

• systém pro provádění statické analýzy zdrojových kódů

• dedikovaný databázový systém pro vývoj a testy

Prostředí by mělo být uzpůsobeno pro automatizované integrační testování – kompletní topologie řešení pro automatizované nasazování a automatizované integrační testování – řešení serverové části NSVIS ESB, CA.

V současné době je vývoj systému NS-VIS (vývojové prostředí s obrazem produkčního i testovacího

prostředí) provozován na 43 (virtuálních images) serverech s dedikovanou diskovou kapacitou 1TB.

Dodavatel je povinen na základě požadavku Objednatele vytvořit kopii vývojového prostředí na infrastruktuře Objednatele. Dodavatel je povinen v případě splnění prostorových podmínek provádět vývoj přímo na vývojovém prostředí Objednatele.

Pro účely specifikace a určení ceny podpory vývojového prostředí je v Příloze 1d Specifikace vývojového prostředí k určení ceny podpory, uvedena stávající konfigurace SW a HW vývojového prostředí. Dodavatel určí cenu podpory vývojového prostředí dle záložky „Vývojové prostředí konfig“.

Příloha B: Projektové řízení

1 Zásady projektového řízení

1.1.1 Projektová dokumentace

Gestorem veškeré dokumentace, která bude vznikat v souvislosti s Programem NS-VIS, 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) Objednatele 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 Objednatelem.

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. Objednatel 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á Objednatel, 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	Objednatel
2	stanovisko architekta kybernetické bezpečnosti MV ČR k investičnímu záměru	Objednatel
3	návrh na zadání veřejné zakázky	Objednatel
4	stanovisko architekta kybernetické bezpečnosti MV ČR k návrhu na zadání veřejné zakázky	Objednatel
5	návrh prováděcí smlouvy	Dodavatel
6	prováděcí smlouva	Dodavatel, Objednatel
8	základní dokument projektů	Dodavatel
9	harmonogram projektu	Xxxxxxxxx
10	personální zajištění projektu	Xxxxxxxxx
11	zpráva o stavu projektu	Xxxxxxxxx
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 Objednatel)
20	evidence změn	Xxxxxxxxx
21	evidence projektových rizik	Dodavatel
22	evidence úkolů	Xxxxxxxxx

1.1.2 Životní cyklus projektu

Každý projekt NS-VIS má tyto fáze:

Příprava

Fáze přípravy zahrnuje aktivity od identifikace potřebnosti změny po uzavření prováděcí smlouvy, 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 Objednatele, včetně hrubého odhadu ceny a termínů plnění.

• Vytvoření investičního záměru (IZ) – slouží k alokaci potřebných finančních prostředků. Vytváří jej Objednatel na základě podkladů od Dodavatele (změnového požadavku);

• 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, Objednatel je vypořádá. Dodavatel může být konzultován, resp. požádán o dodatečné informace či podklady;

• Vytvoření návrhu na zadání veřejné zakázky (NZVZ) – slouží jako podklad pro vyhlášení veřejné zakázky. Vytváří jej Objednatel na základě investičního záměru a dodatečných podkladů od Dodavatele (zejména rozpad ceny na jednotlivé role a mandaye/člověkodny a technický popis řešení);

• Vypořádání stanoviska architekta kybernetické bezpečnosti k NZVZ – má-li k NZVZ připomínky architekt kybernetické bezpečnosti MV ČR, Objednatel je vypořádá. Dodavatel může být konzultován, resp. požádán o dodatečné informace či podklady;

• Vyhlášení veřejné zakázky – v reakci na výzvu Objednatele zašle Dodavatel nabídku, tj. vyplněný vzor prováděcí smlouvy. Nabídka je schválena/rozporována hodnoticí komisí, kterou tvoří zástupci Objednatele;

• Uzavření prováděcí smlouvy – po schválení nabídky Dodavatele je podepsána prováděcí

smlouva;

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 Xxxxxxxxx prezentuje Objednateli 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 Objednateli 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 Objednatel 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 Objednatelem 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 Objednateli 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ě Objednatele.

Dodavatel je povinen vytvořit pro Objednatele 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. Objednatel 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“.

Akceptační proces Viz kapitola „2.78 Akceptace“.

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 Xxxxxxxxx prezentuje Objednateli 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.3 Organizace projektu

Jednání

Pro všechna jednání, která se uskuteční v rámci Programu NS-VIS mezi Objednatelem a Dodavatelem

(příp. i dalšími stranami), platí:

• Jednání se konají v prostorách Objednatele ve vzájemně dohodnutém čase (Objednatel 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 Xxxxxxxxx k připomínkám Objednateli, 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ě Objednatele;

Organizační struktura projektu Každý projekt má tuto strukturu:

• Realizační týmy – jedná se o pracovní tým Objednatele 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 Objednatele 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á Objednateli 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 Objednatelem 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 Objednatele č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ů Objednatele a Dodavatele, projektovými manažery Objednatele 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 Objednatele, 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 Objednatele 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.2 Implementace metodiky PRINCE2

Jak je uvedeno výše, při řízení projektů vychází Objednatel z metodiky PRINCE2, jejíž zásady musejí být zahrnuty do ZDP. Pro přehlednost je způsob implementace PRINCE2 do prostředí Objednatele shrnut v následujících podkapitolách:

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 Objednatel;

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.

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ě Objednatele (příp. i na straně eu-LISA). Dodavatel vytváří testovací scénáře, podle nichž Objednatele 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 prováděcí smlouvou 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í prováděcí smlouvu (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é prováděcí smlouvě.

VIII. Postup prací

• Postup prací v projektu je pravidelně monitorován a reportován na programovém výboru;

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 Objednatel 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 Objednatel i Dodavatel ctí a jejich zásady jsou porůznu rozptýlené v předchozích kapitolách, zejména Error! Reference source not found. – Error! Reference source not found. a Error! Reference source not found. – Error! Reference source not found. projektu.

Příloha č. 2

Specifikace ceny za předmět plnění

PŘÍLOHA Č. 3 RÁMCOVÉ DOHODY Č.J.: PPR-20262-20/ČJ-2020-990656

Vzor návrhu na uzavření Prováděcí smlouvy o poskytnutí plnění dle Rámcové dohody (lze upravit dle konkrétních podmínek)

Prováděcí smlouva č. ……… č.j…………..…..

k Rámcové dohodě č.j.………………………

Smluvní strany:

Česká republika – Ministerstvo vnitra

Sídlo: Nad Xxxxxx 000/0, XXX 000 00, Xxxxx

IČ: 00007064

DIČ: CZ00007064

Zastoupená: ,

Bankovní spojení: Česká národní banka, Praha 1

č.ú. 5504881/0710

Korespondenční adresa: Policejní prezidium ČR, Ředitelství pro podporu výkonu služby,

xxxxxxxx xxxxxxxx 00/ XXXX, 000 00 Xxxxx 0

(dále jen „Objednatel“) a

……………………………..

……………………………..

……………………………..

(dále jen „Dodavatel“)

(společně dále také jen „Smluvní strany“, nebo jednotlivě „Smluvní strana“)

uzavřely tuto Prováděcí smlouvu (dále jen „Prováděcí smlouva“) k Rámcové dohodě

………………….., ze dne………… (dále jen „Rámcová dohoda“) 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) k veřejné zakázce s názvem ……………….

č.j……………..

1. PŘEDMĚT SMLOUVY

1.1. Předmětem této Prováděcí smlouvy je závazek Dodavatele poskytnout Objednateli plnění v souladu se specifikací uvedenou v Příloze č. 1 této Prováděcí smlouvy (dále též jen

„Plnění“).

1.2. Objednatel se zavazuje řádně dodané Plnění převzít a zaplatit za něj dohodnutou cenu, a to způsobem definovaným v této Prováděcí smlouvě a v Rámcové dohodě.

2. CENA

2.1. Celková cena za Plnění dle této Prováděcí smlouvy činí ……………,- Kč bez DPH,

……………,- Kč s DPH. Cena za jednotlivé položky Plnění je uvedena v Příloze č. 2 této Prováděcí smlouvy.

3. TERMÍN PLNĚNÍ A MÍSTO PLNĚNÍ

3.1. Dodavatel je povinen dodat předmět plnění do od účinnosti smlouvy (v období

od………. do ), pokud v Příloze č. 1 není stanoveno jinak.

3.2. Místem plnění je………..

3.3. Adresa Objednatele pro doručení daňového dokladu je:

Policejní prezidium ČR, Ředitelství pro podporu výkonu služby, Strojnická 27, poštovní schránka 62/ŘPVS, 170 89 Praha 7

4. OSTATNÍ UJEDNÁNÍ

4.1. Veškerá ujednání této Prováděcí smlouvy navazují na Rámcovou dohodu a podmínkami uvedenými v Rámcové dohodě se řídí, tj. práva a povinnosti či skutečnosti neupravené v této Prováděcí smlouvě se řídí ustanoveními Rámcové dohody. V případě, že ujednání obsažené v této Prováděcí smlouvě se bude odchylovat od ustanovení obsaženého v Rámcové dohodě, má ujednání obsažené v této Prováděcí smlouvě přednost před ustanovením obsaženým v Rámcové dohodě, ovšem pouze ohledně plnění sjednaného v této Prováděcí smlouvě.

4.2. Tato Prováděcí smlouva 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).

4.3. Tato Smlouva je vyhotovena tak, že je podepsána oběma Smluvními stranami elektronickým podpisem s tím, že zároveň Objednatel obdrží 1 (jeden) stejnopis s platností originálu podepsaný oběma Smluvními stranami vlastnoručně a Dodavatel obdrží 1 (jeden) stejnopis s platností originálu podepsaný oběma Smluvními stranami vlastnoručně, tj. ne elektronicky.

4.4. Nedílnou součástí této Smlouvy jsou následující přílohy: Příloha č. 1 – „Specifikace předmětu plnění“

Příloha č. 2 – „Rozpočet ceny“ (další přílohy )

V ……….. dne …………. V ………… dne …………….

Objednatel: Dodavatel:

………………….. …………………..

Ministerstvo vnitra – Česká republika …………………………

Zástupce: …………….. Zástupce: ………………..

BEZPEČNOSTNÍ OPATŘENÍ PRO SMLUVNÍ VZTAHY

1. Úvod

Tato příloha zadávací dokumentace popisuje bezpečnostní požadavky projektu Poskytování technické podpory a rozvoje aplikačního software NS-VIS , zejména pro naplnění požadavků vyplývající se zákona č. 181/2014 Sb., o kybernetické bezpečnosti a o změně souvisejících zákonů (zákon o kybernetické bezpečnosti), ve znění pozdějších předpisů (dále jen „ZKB“), a vyhlášky č. 82/2018 Sb., o bezpečnostních opatřeních, kybernetických bezpečnostních incidentech, reaktivních opatřeních, náležitostech podání v oblasti kybernetické bezpečnosti a likvidaci dat (vyhláška o kybernetické bezpečnosti (dále jen „VKB“)) pro systém kritické informační infrastruktury resortu MV.

2. Bezpečnostní požadavky

2.1. Účel

1. Tato příloha Smlouvy 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ů ZKB, VKB, či souvisejících 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 Smlouvy 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, jakožto budoucího významného dodavatele systému kritické informační infrastruktury, ze ZKB a VKB a reflektovat případné novely dotčených právních předpisů či novou právní úpravu, a bezpečnostními politikami stanovenými 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 Smlouvy zodpovědnou kontaktní osobu pro potřeby zajištění plnění bezpečnostních požadavků vyplývajících ze Smlouvy 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í Smlouvy potvrdila písemně Zadavateli, že všechny osoby podílející se na poskytování plnění této Smlouvy 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í Smlouvy 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í Smlouvy 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 Smlouvy;

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 Smlouvy (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 Smlouvy, avšak vždy pouze v rozsahu nezbytném ke splnění předmětu Smlouvy.

2. Dodavatel se při poskytování plnění pro Zadavatele zavazuje nakládat s daty pouze v souladu se Smlouvou a příslušnými právními předpisy, zejména ZKB, VKB a dalšími související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 Smlouvy. 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 Smlouvy;

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 Smlouvy;

2.6. Povinnosti v řízení změn dle ZKB a VKB

1. Dodavatel se zavazuje v rozsahu předmětu plnění aktivně podílet na splnění povinností v oblasti řízení změn dle ZKB a VKB, 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 Smlouvy 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 s 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 v souladu s ZKB a VKB, nebo 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 Smlouvy.

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 Smlouvy 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 Smlouvy 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 Smlouvě 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 Smlouvy nebo s ním úzce související budou Zadavatelem průběžně a pravidelně monitorovány a vyhodnocovány s ohledem na obsah Smlouvy 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í Smlouvy.

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) dle přílohy č. 4 VKB.

2.15. Sankce

Sankce za porušení povinností plynoucích z bezpečnostních opatření a ZKB a VKB jsou uvedeny v hlavním textu smlouvy.