Znalecký Posudek o Ceně Zakázky Na Elektronické Dálniční Známky

...
,; 99
ZNALECKÝ POSUDEK
č. ui týtýnuE
Účel posudku: Stanovení OwQ

x v místě a čase obvyklé implementace
a provozu ínřormačniho systému EDAZ
Objed natel: Státní fond dopravní infrastruktury
Sokolovská 1955/278
19 000 Praha 9 - Libeň
Česká republika
IČO: 70856508
ID datové schránky: e5qaihb
Zhotovitel: Znalecká kancelář Dr. Ludvika, s.r.o.

ústav kvalifikovaný pro znaleckou činnost
ž"rtná 562110
120 00 Praha 2 - Nové Město
česká repubUka
IČO: 02323001
ID Datové schránky: p4b9d8
Posudek Je vyhotoven ve dvou vyt,otoventch, z nichž každé má platnost
originálu. Jedno vyhotovení obdrží objednatel a jedno vyhotovení je uloženo
v archivu znaleckého ústavu.
Posudek obsahLt)e celkem -143- stran

Nedanou součástí posudku je DVD s íwgÍ,Vg íwÚÍťH•ťý· ~ Objednatelem.
V Praze dne 7. ledna 2020
z
-.( ·• .
1. NÁLEZ
1. 1. Znalecký úkol
Objednávkou ze dne 20.10.2019 byl osloven znalecký ústav - Znalecká kancelář

\
Et IČO: 02323001 se sfdlem Litná 562/10, 120 00 Praha 2 - Nové

Dr. Ludvika, s.rOv
Město, za účelem zpracováni znaleckého posudku v oboru KYBERNETIKA.

oboru EKONOMIKA odvětvi Ceny a odhady software, hardware, komplexní
řešeni v oblasti IT, telekomunikaci a duševního vlastnictví, elektrotechnika

zdravotní, laboratorní a obnovitelné zdroje energie a oboru ŠKOLSTVÍ A
KULTURA odvěM Distribuce a užívání autorských práv, posuzováni existence

práv duševního vlastnictví. uměleckohistorické památky ve stavebnictví.
Předmětem posuzované věci je vytvořeni IS EDAZ .Informačního systému pro
evidenci vozidel v systému časového zpoplatněnr a poskytováni souvisejícfch
služeb, a to v rámci projektu Elektronické dáµllční známky.
Pfedmět posuzované věci byl dále rozšířen v souladu s objednávkou dne

23.112019 o služby infrastruktury {platformy), na které má být projekt EDAZ
provozován.
Úkolem znaleckého ústavu je stanovení ceny v místě a čase obvyklé.
1. 2. ()tjzky Objednatele
Ot6zkač.1:
Jaká Je cena obvyklá na území české republiky v době zpracování posudku

za vytvofenf Informačního systému EDAZ a poskytnuti služeb, jak jsou
definovány v závazném návrhu smlouvy a její příloze l a $6 zohledněním
poskytnutých upřesňujfcich dokumentů.
Znalecký posudek č. 14/2/ZOl.9 3

-;iy j
L 3. Podklady pro vypracovánf posudku
8·] #w(!]L6Lé ú9<0·68L0Q0&(viz strana 143 posudku)

}w·! Q
13.l Smlouva
Závazný návrh smlouvy. Dále odkazováno také jen jako
f
Ov&QwK8
oO
13.2 Smlouva-Prioha_l
Specifikace EDAZ dokument obsahule tyto části:
l Základní požadavky - IS EDAZ

\,
2. Obecné požadavky- Systém EDAZ
3. Požadav ky - Služby provozu a technické podpory

4. Integrační standardy SFDI pro projekt Bektronická dálniční
známka
5. Standardy uživatelského rozhraní aplikací SFDI pro projekt
Elektronická dálniční známka
6. Součinnost SFDI
7. Tým poskytovatele
8. Požadované služby Call centra

9. Zpracováni listinných podáni
10. Zajištěni .Obchodních aktivit" v rámci provozu eShop
13.3. OO-Doplneni-20191127 - Doplněn í požadavků SFDI
Doplňující Informace k e.m Smlouva-Prlloha_l vzniklé na základě
konzultaci a workshopů v průběhu výběru řešitele Informačního
systému EDAZ
13.4. 012-struktura_ cenove_nabldky
Fonnulář předeplstúíci strukturu ceny Poskytovateli.
13.5. pozado vane_lnformace- 20191103_ v2
Dokument kterým byli osloveni potenciální dodavatelé požádání o
poskytnuti Indikativní cenové nabídky a dalších informací.
4
1.3.6. 01-dekompozlce - Dekompozice EDZ na základní celky
Přehledový dokument naznačující rozdělení požadovaného systému
do funkčních celků.
13.7. 02.1-UC-oz nameni_elektromobl l
Diagram průběhu procesu přípravy podání oznámení osvobození pro
elektromobil fyzickou osobou.
1.3.8. 02.2-UC-osvobozenUnstltuce
Diagram průběhu procesu přípravy podání oznámení osvobození pro
Instituci.
13.9. 02.3-UC-zpracovanl_oznameni
Diagram průběhu procesu zpracování oznámení osvobození
podatelnou.
13.10. 02.4-UC-faktura
Diagram průběhu procesu zakoupení elektronické dálniční známky
bankovním převodem s využitím zálohové faktury.
1.3.11 03.1-ePodatelna_a_vypravna
Komentované diagramy hrubě poplsujfcí ePodatelnu a eVýpravnu.
13.12. 05-BezpecnostnL pozadavky
Požadavky týkající se provozu platformy.
13.13. 011-KrycUist_nabldky
Formální dokument.
1.3.14. 013-Profesni_zívotopis
Struktura životopisu.
13.15. 014-Seznam_reaUzovanych_zakazek
Struktura referencí.
Znalecký posudek č. 14/2/2019 5

1.3.16. 03.2-Platform a-lS_EDAZ
Formulář pro spec ifikaci kompo nent platform y IS EDAZ .
1.3.17. 03.3-Platforma-lS_SFDI
Formulář pro spec ifikaci kompo nent platformy !S SFDI.
13.18. 06 -Souclnnost-SFDI
Rozsah součinnost! ze strany Objednatele.
1.3.19. 07-Pocty _u hrad
Měsíční statistika prodeje dálničních známek za rok 2019.
1.3.20. 08-Pocty_oznamenl
Odhadované počty oznámen! Osvobození.
1.3.21 09 -Model_hod noceni
Kritéria hodnoc ení nabídek.
Dalšípodklady
13.22. Prehled_cen_lCT_praci_201905
Zdroj ministerstvo vnitra ČR. https://www.mvcr.cz/clanek/prehled
obvyklych-cen-lct-praci.aspx
Upozornění:
Výše zmíněné dokumenty z/skal znalec od Objednatele a z veřejně dostupných
zdrojů. Znalec nezkoumal pravost, přesnost a autentičnost takto získaných
podkladů, a proto nepřebírá žádnou odpovědnost za pravdivost, přesnost a
úplnost}akýchhollv takto získaných informací. Znalec neprováděl žá 0n á šetření
sméiu;Ici k ověřeni pravosti, správnosti a úplnosti předložených dokumentů, ze
kterých v Y svém znaleckém posudku vycházel
Upozcrnént
Všechny známky a názvy produktů uvedené v tomto materiálu Jsou nebo
mohou být registrované obchodnf značky, obchodnf značky nebo ochranné
známkyJejich vlastnfkú.
------------------------------------ -
1. 4. Vysvětlení pojmů a zkratek
Aktivum - pojem vycházejici z VoKB, který rozlišuje primární a podpůrná aktiva.
Podpůrným aktivem Je technické aktivum, zaměstnanci a dodavatelé podflejici
se na provozu, rozvoji, správě nebo bezpečnosti lnformačnlho a komunikačního
systému. Primárním aktivem je informace nebo služba, kterou zpracovává nebo
poskytuls informační a komunikační systém.
Analýza rizik - pojem vycházející z Vo KB
ApUkační server - poskytuje běhové prostředí pro aplikaci, často nazývanou
jako servlet Aplikační server aplikaci nahraje z disku a inicializuje a následně
přijímá od klienta požadavky, parsqle Je a předává aplikaci. Aplikace vytvoří
odpověď a předá jí aplikačnímu serveru, kterýJI pošle zpět klientovi. V případě,
že se řešení skládá z více servletů, aplikační server napřlklad na základě URL
určí. který servlet pro obsloužení každého požadavku použije.
ApllkačnJ SW1 (zkráceně aplikace) - programové vybaveni počítače
(tj. software), které umožňuje provádět nějakou užitečnou činnost (řešení
konkrétního problému, interaktlvnf tvorbu uživatele - např. textový procesor
apod.). Aplikace využfvají pro interakci s uživatelem grafické nebo textové
rozhraní, případně příkazový řádek Aplikace se může skládat z několika
počftačových programů. Mezi aplikace neřadíme systémový software (tj.jádro a
další součásti operačního systému. např. služba Windows, démon).
Archivace dat2 - proces, který slouží k dlouhodobému uchování dat
Auditní záznam (log>3 - v Informatice obecné označení pro záznam nějaké
činnosti nebo pro soubor se záznamy (často s příponou .log), které některé
programy vytvářejí pro záznam Informaci o Své činnosti a běhu (typicky démon
1
https;//es.wiklpedla.org/wikVApUkačn%C3%AD_software
2
https://cs.wlklpedla.org/wlkl/Archfvace_dat
3
https://cs.wikipedía.org/wlki/Log

nebo služba). Logy slouží při zpětné analýze k rozpoznání. zda došlo k nějaké
chybě , a pakliže ano, pak pomáhají určit, kjaké chybě došlo a proč. Mohou také
obsahovat Informace o tom. Jak a kým byla daná aplikace či služba vyu žívána
(například zjaké IP adresy bylo přistupováno k webovému serveru).
Backend - Jedná se o část celého SW řešení. která pracuje s daty, vykonává nad
nimi požadované operace a implementule aplikační Logiku. S frontendem
komunikuje pomocí programového rozhraní, které není přímo použitelné pro
koncového uživatele, ale umožnuje nezávislost, oddělení funkcionality
i Implementace. a použití více nezávislých frontendů pro budoucí rozšiřování
aplikace.
BCP' (zkratka z anglického Buslness continulty planning) - plán zajištění
kontinuity provozu. BCP je plán. který pomůže zajistit provoz firmy a Jejího
fungování v situacích, kdy je firma ohrožena nebo čelí nějaké katastrofě. Jeho
cílem Je co nejrychlejší a nejhladší návrat do normálního stavu. Jeho klíčovou
součástí Je proces obnovy - tedy soupis všech aktivit a činností, které povedou
k rychlé obnově normálního stavu.
Bezpečnostní Incident' (z anglického Security Incident>- situace, při které došlo
ohrožení bezpečnosti informací nebo k porušeni pravidel. Bezpečnostnl Incident
vzniká v důsledku selhání čl nedodržení bezpečnostních opatření nebo porušení
bezpečnostní politiky. Jako bezpečnostní Incident může být vyhodnocený
I pouhý neúspěšný pokus o nějaké zcizení nebo Jiné znehodnocení informací. Při
bezpečnostním Incidentu může dojít k ohrožení, ztrátě, odcizení zneužití nebo
změně dat čl Informací.
◄ https://managementmania.com/cs/plan-zajisteni-kontinulty-provozu
5
https://managementmania.com/cs/bezpecnostni-incldent

Blade serve,-e - účelem blade serverů neboli blade systémů je maximalizace
výkonu a úspory místa při zachování možnostl rozšiřování a upgradu
serverového hardwaru. Díky této modulárnosti Jsou tyto ultratenké a výkonné
servery Ideálním řešením pro střední a velké firmy, jejichž nároky na výpočetní
výkon se často mění. Blade servery se od klasických serverů liší hardwarovou
konstrukcí. Jednotlivé serveryJsou vyráběny ve formě tzv. bladů (.žiletek", odtud
název), které se zasunuji do centrální skříně (šasi}. šasi zajlšťl!Je pro Jednotlivé
.žiíetky" napáleni a chlazení, poskytuje jim síťové rozhraní a propojení s ostatními
,žiletkami" pomocí ethernetu, nebo může obsahovat i switch. Hlavni výhody
blade serverů jsou především úspora prostoru v datovém centru, úspora energie
a redukce potřebné kabeláže. Dfky flexibilitě a snadné rozšiřitelnosti umožňuji
konsolidaci serverů.
Cloud7 - model založený na síťových technologiích. Lzejej také charakterizovat

jako poskytování služeb či programů servery dostupnými z prostřednictvím
počítačové sítě (v případě veřejného cloudu prostřednictvím Internetu) s tím, že
uživatelé k nim mohou přistupovat vzdáleně, kupř. pomoci webového
prohlížeče nebo klienta elektronické pošty. Za předpokladu, že služba Je
placená, uživatelé neplatí za vlastní software, ale zajeho užití. Principem u služeb
a produktů v cloud computlnguje to, že uživatelé sdílejí nejen výpočetní výkon
serverů, ale i další prostředky. V mnoha případech se tak děje formou
specializovaných aplikací.Jejichž nabídka se pohybuje od kancelářských aplikaci
přes systémy pro distribuované výpočty až po operační systémy provozované
v prohližečfch,Jakýmljsou např. eyeOS, Cloud čl ICloud.
Cluster' - seskupení volně vázaných počítačů, které spotu úzce spolupracují
tak. že se navenek mohou tvářit jako Jeden počítač. Obvykle Jsou propojeny
e https://en,wikipediaorg/wikl/Blade_server
7
https./ /cs.wikipedia.org/wlkVCloud_computlng
8
https:/O cs.wikípedia.org/wlkVPoč%C3%ADtačový .cluster

počítačovou sítí. Clustery jsou většinou nasazovány pro zvýšení výpočetní
rychlosti. nebo spolehlivosti s větší efektivitou než by mohl poskytnout jediný
počítač.
D89 (databáze) - systém souborů s pevnou strukturou záznamů. Tyto soubory
jsou mezi sebou navzájem propojeny pomocí klíčů. V širším smyslu jsou součásti
databáze I softwarové prostředky, které umožňují manipulaci s uloženými daty
a přístup k nim. Tento software se v české odborné literatuře nazývá systém

řízení báze dat (SŘBD), Běžně se označením databáze - v závislosti na kontextu
- mysli jak uložená data. tak I software (SŘBD),
Deduplikace1° - Je speciální technika komprese dat, která zabraňuje ukládání
stejných datových bloků na jednom úložišti. Deduplikační Jednotka ukládá
Informace (referenční Informace) o datové struktuře a díky tomu je schopná při
zpětném čtení deduplikovaných dat zpět obnovit původní, komplexní Informaci.
Účelem dedupUkaceje úspora místa na datovém úložišti. Kromě této varianty,
tzv. blokové dedupUkace, existuje Ještě dedupllkace na úrovni souborů, kdy Je

ukládána pouze jedna kopie Onstance) souboru/přílohy e-ma!lu. Příkladem
budiž ukládání e-mallových zpráv v systému Microsoft Exchange. nebo
Windows Single Instance Storage,
11 https://cs.wlkipedla.org/wlkVDatabáze
10
https:/ /cs.wikipedia.org/wlkVDedupUkace

Digitální certlflkát11 (zkráceně pouze certifikát) - v asymetrické kryptografii
digitálně podepsaný veřejný šifrovací klič. který vydává certifikační autorita.
Uchovává se ve formátu X509, který (kromě Jiného) obsahuje Informace
o majiteli veřejného kUče a vydavateli certifikátu (tvůrci dlgttálního podpisu,
tj. certlflkační autoritě). Certifikáty jsou použfvány pro Identifikaci protistrany při
vytvářeni zabezpečeného spojení (HTTPS, VPN atp.l. Na základě principu
přenosu důvěry Je možné důvěřovat neznámým certifikátům, které jsou
podepsány důvěryhodnou certiflkační autoritou. Certifikační autorita může
vydávat pod různými označeními různé druhy certifikátů, které se mohou lišit
v účelu použití, druhu majitele, úrovni důvěryhodnosti atd. (podmínkyjsou dány
politikou konkrétní certifikační autority). Různé označení však nemění podstatu
funkce digitálních certifikátů.
Disková pole - exlstuje více typů diskových polí. Pro účely tohoto posudku
diskovým polem rozumíme externí zařízeni s jedním nebo více (z důvodu
redundance) diskovými řadiči (controllery), které kornunlku]! zpravidla
prostřednictvím SAN čl !SCSI se servery či zálohovacími zařízenimi. Tato pole se
v angUckém jazyce označují pojmem Storage. Diskové pote v sobě nese disky
(různých Tlerů} a řadiče s logikou, která Je schopna tyto disky shlukovat do
RAIDů, POOLů a tím poskytovat ochranu dat a prezentaci kontinuálního
úložného prostoru serverům/aplikacím. Dále umožňuíe další funkcionality Jako
Snap, Clon, Mirroring, ....
DLJ>12 (zkratka z angUckého Data Loss Preventlon) - řešení sloužící k Identifikaci

a ochraně citlivých dat Takové řešení monltoru]e Jak přenos dat. tak data
uložená na koncových stanicích čl centrálních úložištich a řeší i problematiku
u https://cs.wlk!pedla.org/wikl/Dlgitáln%C3%AD_certlflkát
12 https.//en.wlklpedia.org/wlkVData_loss_prevention_software

externích zařízení Jako USB disky, FLASH apod. Cílem DLP Je v optimálním
případě zabránit úniku citlivých dat
DMZ13 (zkratka z anglického demiUtarlzed zone) - v počítačové bezpečnosti

fyzická nebo logická podsff. která Je z bezpečnostních důvodů oddělena od
ostatních zařízení. Jsou v ní umístěny služby, které jsou k dispozici většinou
z celého Internetu. Účelem DMZ Je přidání další bezpečnostní vrstvy v LAN
(lokální sítě). To znamená, že případný útočník získá přístup pouze k zařízení,
které je v DMZ, ale zbytek lokální sítě je v bezpečí Jméno Je odvozeno z terminu
.dernítítarízovaná zóna", což je oblast mezi státy, ve které nejsou povoleny žádné
vojenské akce. V počítačové sítí jsou nejvíce náchylní k útoku ti. kteří poskytuf
služby uživatelům mimo lokální síf,JakoJe e-mail. webové služby a DNS (Domaln
Name System). Vzhledem ke zvýšené pravděpodobnostl útoků na tyto
poskytovatele.Jsou jejich služby umístěny ve vlastních podsítích s cílem ochránit
zbytek sítě před případně úspěšným útokem. Počítače v DMZ mají omezené
připojení k vybraným počítačům ve vnltfnf síti. naopak komunikace s ostatními
počítači v DMZ a venkovní síti je povolena. To umožňuje počítačům v DMZ
poskytovat služby jak pro vnitřní, tak I pro vnější sítě, zatímco firewall kontroluje
provoz pouze mezi servery v DMZ a klienty vnitřní sftě.
Dodavatel - distributor dálničních známek na pobočkové síti. Prodává známky,
zasílá Jejich údaje do evidence, zasílá úhrady za prodané známky na účet SFDI a
dostává za službu provizi.
Dostupnost" - vyjadřuje se v procentech a lze Ji považovat za
pravděpodobnost, že systém poskytuje požadované funkce za určených
podmínek a v daném časovém okamžiku. Dostupnost Je dána jak spolehlivostí
systému samotného, tak i s časem kdy dojde k obnovení poskytování služby po
13 https://cs.wikipedla,org/wiki/DMZ
14 https://cs.wiklpedia.org/wlkl/Vysoká_dostupnost

po ruše. Dostupnost je vyjádřena poměrem doby kdy byl systém v daném
časovém období dostupný a celkového časového období.
DR16 (zkratka z anglického disaster recovery) - soubor postupů a opatřeni pro
obnovu provozu při výpadku systému nebo Jeho částí. Zahrnuje Jak obnovu
činnosti systému, tak dopady na obchodní procesy.
DRP16 (zkratka z anglického dlsaster recovery plan) - plán obnovy provozu IT
systémů po rozsáhlém výpadku. Plány obnovy by měly být zpracovány pro
nejpravděpodobnější havárie s největším dopadem na činnost společnosti. Při

výpadku bývají v důsledku stresu voleny postupy, které nejsou optlrnální
z hlediska spotřeby času ani kvality řešení. Předem a v klidu zpracovaný plán
obnovy tato nedostatky odstraňuje. Výrazně zkracuje dobu zásahu, snižuje
chybovost a rizika ze zanedbání důležitých souvislostí.
EDAZ čl EDZ - informační systém pro evidenci vozkíel v systému časového

zpoplatněni. Jehož vytvoření je předmětem Smlouvy a který je předmětem
tohoto posudku.
Fault tolerant systern17 (česky systém odolný proti selhání nebo systém odolný
proti chybám) - vlastnost, která umožňuje systému, aby nadále pracoval
správně I v případě selhání některé jeho součásti. Pokud se snl.žf kvalita služby,
je pokles úměrný závažnosti selhání - naopak u chybně navrženého systému
může I malé selhání způsobit úplné zhroucení. Odolnost proti chybám je velmi
žádoucí u systémů s vysokou dostupností nebo zaiištulicich životně kritické
funkce.
Frontenci - jedná se o část celého SW řešení, která zprostředkovává přímou
Interakci s uživatelem webové aplikace zpravidla pomoci webového rozhraní.
15https:/ /en.wiklpedla.org/wikVDlsaster_recovery
1~httpst//www.techopedia.com/deflnition/1074/disaster-recovery-plan-drp
v https:/ /cs.wlkipedia.org/wlki/Fauli-toleranLsystem

Garant aktiva - pojem vycházející z VoKB. Garant aktiva je bezpečnostní role
odpovědná za zajištění rozvoje, použití a bezpečnost aktiva.
Hardenlng OS18 - proces, při kterém se zvyšuje bezpečnost systému tím, že se
snižuje jeho povrchová zranitelnost. Systém bývá obecně zranltelnélší. pokud
nabízí více funkcí: v podstatě Je systém, který poskytuje Jednu funkci, méně
zranitelný, než systém s více funkcemL Snížení počtu způsobů útoku na systém
většinou obnáší odstranění nepotřebného softwaru odstranění zbytečných
přístupových účtů a vypnutí nepotřebných služeb.
HW (hardware) - fyzické součásti infrastruktury, tj. disková pole, zálohovací a
deduplikační jednotky, servery, swltche, routery, firewally, IPS, UPS a další
fyzické prvky nutné pro provoz informačního systému.
ICT19 (zkratka z anglického lnformation and Communlcatlon Technologles, česky
Informační a komunikační technologie) - pojem zahrnuje veškeré informační
technologie používané pro komunikaci a práci s Informacemi. Původní koncept
Informačních technologií on byl doplněn o prvek komunikace, kdy mezi sebou

začaly komunikovat jednotlivé počítače čl uzavřené sítě. ICT ovšem nejsou jen
hardwarové prvky (počítače, servery.). ale také softwarové vybavení (operační

systémy, sltové protokoly, Internetové vyhledávače.),
lnfrastruktura20 - kompozice všech složek v IT prostředí. Složkami máme na

mysli hardware, software, síťové zdroje a další služby, kompozice znamenájejich
správná struktura, rozdělení. hierarchie apod tak, aby efektivně a účelně sloužily
v daném prostředí.
18 https//en.m.wikipedla.org/wikl/Hardening_(computing)
19
httpsv' /cs.wiklpedla.org/wikVlnformačn%C3%AD_a_komunikačn%C3%AD_technologie
20
https:/ /1t-slovnlkcz/poJem/lnfrastrukt1.1a

IOPS21 (zkratka z anglického lnput/output operatlons per second) - jedná se
o vstupně/výstupní měření výkonu, které se používá k udávání výkonu

klasických pevných disků (HDD), SSD a diskových poli.
IP (zkratka z anglického Internet Protocol) - v Informatice základním protokolem
pracujícím na sřtové vrstvě používaným v počítačových sítích a Internetu.
Protokol IP poskytu]e datagramovou službu celé rodině protokolů TCP/IP. Sám
o sobě neposkyt4Je záruky na přenos dat a rozlišl!Je pomocí IP adresy pouze
Jednotlivá síťová rozhraní (doplňující služby Jsou poskytovány na vyšších
vrstvách, viz referenční model ISO/OSI). V současné době je stále ještě
používána starší verze protokolu 1Pv4, nově se přechází na 1Pv6.
IPS22 (zkratka z anglického lntruslon Preventlon Systems) - zařízení pro
počftačovou bezpečnost. které monitoruje síť a/nebo aktivity operačního
systému na škodlivou činnost Hlavní funkce IPS systémů Jsou Identifikace
škodlivé činnosti, zaznamenávání informaci o Jejím průběhu, následném
blokování této činnosti a také její nahlašování IPS systémy Jsou považovány za
rozšíření f DS systémů, protože monitorují jak provoz na síti, tak i aktivity
operačního systému, které by mohly vést k narušení bezpečnosti. Hlavní rozdíl
oproti 1OS systémům Je, že systém I PS Je zařazen přímo do sffové cesty (ln-Line),
a tak může aktivně předcházet, případně blokovat detekovaný nežádoucí a
nebezpečný provoz na síti. Konkrétněji, IPS může provádět takové akce Jako
vyvolání poplachu, filtrování škodlivých paketů, násilné resetováni spojení
a/nebo blokování provozu z podezřelé IP adresy. Všechny tyto úkony často
provádí ve spolupráci s firewallem. IPS také umí opravit chybný cyklický
redundantní součet (CRC), defragmentovat proudy paketů, předcházet
21 https:l/en.wikipedia.org/wlkVIOPS
22 https://cs.wikipedia.org/wiki/Systém_prevenca_průnlku

problémům s řazením TCP paketů, a čistit nežádoucí přenos včetně nastavení
síťové vrstvy.
ISCSl23 (zkratka z anglického Internet Smali Computer System Interface) -
v informatice síťový protokol. který umožňuje připojovat úložný prostor
(např. diskové pole) pomoci počftačové sítě. Koncepce ISCSI vychází ze dvou
technologií. SCSI rozhraní pro připojování disků v seNerech a protokolu TCP/IP.
Z rozhraní SCSI se použfvá pouze protokol, kterým spolu zařízení komunikují a
zcela opouští Jeho fyzickou vrstvu (kabely, konektory, elektrickou specifikaci).
Pro přenos paketů SCSI se použije Jejich zapouzdření do protokolu TCP/IP.
Norma ISCSI používá vlastní terminologii: Pokud u SCSi hovoříme o adaptéru a
disku, adaptér nám nahradl komponenta, která se Jmenuje lnltlator, a cílové
zařízení (disk/diskové pole, případně pásková jednotka) se nazývá Target
Rozhraní iSCSI Je běžně dostupné na většině platforem. Lze tak snadno ukázat
notebook s terabytovým diskem - disk připojený přes iSCSI se chová úplně
stejně, Jako disk připojený na lokální řadič. je vidět i ve Správci disků.
ISDS - lnformačni systém datových schránek.
Jádro CPU24 - výpočetní Jednotka, která je většinou vícekrát obsažena
v počítačovém procesoru. U vícejádrových procesorů je dobrá součinnostjader
důležitá. protože umožňuje využít celý systém v maximální možné míře.
Spolupráce jader se obecně (v rámci mlkropočftače) děje prostřednictvím
operační paměti.
Jádro 052' - v Informatice část operačního systému, která Je zavedena do
operační paměti při startu (bootovánl) počítače a je Jí předáno řízení.
23 https://cs.wikipedia.org/wlkVlnternet_SmalLComputer _SystemJnterface
24 https://cs.wikipedia.org/wiki/V%C3%ADcejádrový_procesor
2!:i https://cs.wikipedia.org/wiki/Jádro_operačn%C3%.ADho_systému

U pokročilých operačních systémů jádro nikdy neztrácí kontrolu nad počítačem
a po celou dobujeho běhu koordinuje činnost všech spuštěných procesů
KB (Kybernetická bezpečnost informačního systému) - kybernetická
bezpečnost dle požadavků ZoKB.
KBI (Incident KB) - stav narušení bezpečnosti. Dle ZoKB se jedná o narušení
bezpečnosti Informací v Informačních systémech nebo narušení bezpečnosti
služeb anebo bezpečnosti a Integrity sítí elektronických komunikací v důsledku
kybernetické bezpečnostní události.
KBU (Událost KB) - nestandardní stav nebo událost s ohledem na KB. Dle ZoKB
se jedná o událost. která může způsobit narušení bezpečnosti Informací v
Informačních systémech nebo narušení bezpečnosti služeb anebo bezpečnosti
a Integrity sítí elektronických komunikací.
Komprese28 - zpracování počftačových dat s cílem zmenšit Jejich objem
yednotka bajt) při současném zachování informací v datech obsažených.
Úkolem komprese dat Je zmenšit datový tok při Jejich přenosu nebo zmenšit
potřebu zdrojů při ukládání informací. Obecně seJedná o snahu zmenšit velikost
datových souborů, cožje výhodné pro Jejich archivaci nebo pro přenos přes síť
s omezenou rychlostí (snížení doby nutné pro přenos).
Licenční model - Jednotlivé SW mají různé způsoby licencováni. Licenční
model konkrétního produktu určuje způsob licencováni, tj. zda se Licencuje dle
počtu socketů, Jader, využitého přenosového pásma, množství RAM. počet
všech uživatelů. počet současně praculíclch uživatelů atd.
MO (zkratka z anglického Man-day. česky člověkoden) - čas odpovídající práci

jedné osoby po dobu Jednoho pracovního dne. V tomto dokumentu platí, že MD
odpovídá osmi pracovním hodinám.
20 https;//cs.wikipedia.org/wlki/Komprese_dat

MDM <zkratka z anglického Master Data Management, česky správa
referenčnfch lnformacO - zahrnu]e konfigurační číselníky, organizací a dalších
referenčních dat Pojem zahrnuje I mechanismy správy a možnost synchronizace
(master i slave režim) s jinými moduly uvnitř I vně prostředí SFDI.
MKB (Manažer kybernetické bezpečnosti) - dle VoKB:

a} Je MKB bezpečnostní role odpovědná za systém řízení bezpečnosti
Informací, přičemž výkonem této role může být pověřena osoba, která Je
pro tuto činnost vyškolena a prokáže odbornou způsobilost praxí s řízením
kybernetické bezpečnosti nebo s řízením bezpečnosti informaci
1 po dobu nejméně tří let, nebo
2. po dobu Jednoho roku, pokud absolvovala studium na vysoké škole,
b) odpovídá za pravidelné informování vrcholového vedení o
1 činnostech vyplývajících z rozsahu Jeho odpovědnostl a
2. stavu systému řízení bezpečnosti informací a
c) nesmí být pověřen výkonem rolí odpovědných za provoz Informačního a
komunikačního systému.
NGFW27 (zkratka z angUckého Next Generation Firewall. v překladu firewall další
generace} - na rozdíl od paketových filtrů pracujfcí na třetí či čtvrté vrstvě
ISO/OSI modelu "rozumí' určitým aplikacím a protokolům (například FTP,
Doma ln Name System (DNS} nebo Hypertext. Transfer Protocol (HTTP) a dokáže
tak rozpoznat, zda se nežádoucí aplikace nebo služba nepokouší obejft bránu
firewall pomocí protokolu na povoleném portu nebo zjistit. zda není protokol
zneužíván k nekalým účelům.
Objednatel čl SFDI - Objednatel dodávky Informačního systému EDAZ, který Je
předmětem tohoto posudku.
v https://cs.wlklpedia.org/wlki/Firewall

On Premlse28 - výraz pro lokální řešení hardware i software. V případě on
premise instalace běží řešení na konkrétním HW i SW.
0S29 (operační systém) - základní programové vybavení počítače, které je
zavedeno do paměti počítače při Jeho startu a zůstává v činnosti až do Jeho
vypnutí. Operační systém se stará o následujíci:
• Organizuje přístup a využivání zdrojů počítače (čas procesoru,
přístup k datům na discích, přistup do paměti),
• Fyzicky zajlšfuje vstup a výstup dat podle požadavků ostatních
programů.
• Komunikuje s uživatelem a na základě jeho pokynů vykonává
požadované akce.
• Reaguje na chybové stavy programů a mylné požadavky
uživatelů tak. aby tyto chyby nezpůsobily zásadní destrukci
systému nebo poškození dat
• Spravuje komunikaci s periferiemi pomocí ovladačů (driverů).
• Eviduje využívání systémových zdrojů apod.
Osvobození - osvobození od zpoplatnění užlvání pozemní komunikace dle
zákona č.13/1997 o pozemních komunikacích ve znění od 1.12021 §20a.
OVM (orgán veřejné moci) - v kontextu tohoto dokumentu především subjekty
oprávněné oznamovat Osvobození.
Pásková Jednotka30 (též označována Jako streamer) - zařízení pro záznam dat.
které provádí čtení a zápis dat na magnetickou pásku. Záznam na magnetické
pásky se použfvá zejména pro archivaci a zálohování důležitých dat, typicky pro
vytváření záloh obsahu pevných disků Tento typ média Je oblíbený pro Jeho
28
https://www.webopedla.com/TERM/O/on-premlses.html
~ https://cs.wiklpedla.org/wiki/Operačn%C3%AD_systém
30 https://cs.wiklpedia.org/wlki/Paskovájednotl<a

relativně nízkou cenu a dlouhou (ověřenou) životnost. Vyplatí se tedy pro
ukládání velkého množství dat Pás ková jednotka Je vstupně-výstupní zařízení a
používá sekvenční přístup k datům. na rozdíl od pevného disku s přímým
přístupem (anglicky random access, česky též libovolný přistup, avšak
nesprávně náhodný přístup).
PCI D5S33. (zkratka z anglického Payment Card lndustry Data Security Standard)
- soubor mezinárodních bezpečnostních standardů (norem), jejichž cílem Je
zamezit únikům citlivých dat o držitelích platebních karet. V podstatě se jedná
o l2 požadavků, které Jsou přenášeny na organizace, které zpracovávají,
přenášejí nebo uchovávají data o držitelích platebních karet a transakcích
(zejména banky, autorizační centrály, obchodníci akceptující platební karty).
Platforma - HW a základní SW infrastruktura pro provoz systému EDAZ. Jedna
se zejména o databázové a aplikační servery včetně veškerého příslušného
vybaveni nutného k provozu a základní software nutný pro provoz Infrastruktury.
Poskytovatel - dodavatel EDAZ a souvisejících služeb, respektive kandidát na
Dodavatele.
Produkční prostfedl32 (nebo také .ostró" čl .živé" prostředf) - Jedná se o instanci
prostředí. která slouží k reálnému provozu. tedy poskytování služeb systému:
obsluhuje koncové uživatele, zpracovává reálné obchodní transakce a je
Integrováno výhradně s produkčními prostředí okolních systémů. Toto prostředí
je nejkritičtějším předmětem provozních služeb (platformy i provozní podpory),
Jsou nad nim sjednány nejvyšší SLA. Toto prostředí vyžaduje nejvíce
systémových prostředků, protože se jedná o prostředí s největší (reálnou) zátěží.
Zároveň jsou na toto prostfedí kladeny vysoké nároky na parametry RPO a RTO.
Přístup k produkčnímu prostředí musí být spolehlivě auditován. veškeré úpravy
31 https://cs.wlklpedla.org/wlkl/PCI_DSS
3! https.//en.wlklpedia.org/wiki/DeploymenLenvlronment

SW a HW vy baveni a konfigurace musí být neJdřfve ověřeny na Předprodukčním
prostřed í
PFedprodukční (testovacO prostředl33 - slouží k ověřován! funkčnosti systému,

výkonnostních parametrů a/nebo nasazovacích postupů. Veškeré operace
v něm probfhajfcl nejsou skutečné, nedochází zde k uzavírání obchodů. Systém
mohou používat i koncovf uživatelé, a to jak pro testy nových funkčností
(testovacf prostředO tak pro simulování nestandardních obchodních případů

(Předprodukční prostředů Systémyjsou Integrovány na testovací verze okolních
systémů, případně na simulátory rozhraní. záleží na konkrétních Integrovaných
systémech, jaké možnosti poskytují. V případě, že Je přístup k integrovanému
systému pouze pasivní (slouží pouze jako zdroj dat, nezaplsu]! se do něj žádná
data) Je možné, aby I testovací systém byl Integrován na ostrou protistranu
(například read-only přístup do rejstříků), pokud to protistrana přlpustf.
Předprodukční prostředí Je striktně udržováno v co neJbllžšf podobě k prostředí
produkčnímu, tak aby testy na něm prováděné co nejlépe odpovídaly
produkčnímu prostředí. V případě. že jsou na něm prováděny I zátěžové testy
odpovídající zátěži na produkci, musí být Jeho HW konfigurace obdobná
prostředí produkčnímu. Testovaci prostředí slouží zelména k funkčnímu a
Integračnímu testování. Jeho konfigurace obvykle může být méně výkonná než
produkční prostředí.
RAJD34 (zkratka z anglického Redundant Array of lndependent Dlsks) -
vícenásobné diskové pole nezávislých disků, dř1ve inexpensive disks, tj, levných
disků) Je v Informatice metoda zabezpečení dat proti selhání pevného disku.
Zabezpečení Je realizováno specifickým ukládáním dat na více nezávislých
disků, kdy jsou uložená data zachována I při selhání některého z nich. úroveň
33
https://en.wiklpedla.org/wik!/Deployment_environment
34
https://cs.wlklpedla.org/wlkVRAID

zabe zpečení se llšl podle zvoleného typu RA ID, které Je označováno čísly
(nejčastěji RAID O, RAID l RAID 5, RAID 6, RAID 10, RAJD 50, RAID 60 či RAID
100). RAID je často používán na serverech, avšak je nutné sl uvědomit, že RAID
nenahrazuje zálohování dat
RCA36 (zkratka z anglického Root Cause Analysls) - systematlcký proces
identifikace základní příčiny (příčin) problému nebo události a nalezení přístupu
pro adekvátní reakci. RCA Je založena na přesvědčení, že efektivní řízení

vyžaduje více nežjen "hašení ohně" pro problémy takjak přicházejí, ale že Je lépe
najít způsob, jak problémům předcházet. Při RC analýze se tedy identifikují
faktory přispfvajid ke konkrétní události, kteráje předmětem zájmu (významné
události). Analýza RCA Je zaměřena spíše na pochopení příčin selhání než na
bezprostředně zřejmé symptomy události. Cílem analýzy RCA je odhaLit
kořenové příčiny poruch a chyb tak, aby se snfžll Jejich budoucí výskyt nebo
dopad. Analýza hlavní přičlny (kořenových příčin) Je popsána v technických
normách IEC a ČSN.
Referenční model 150/05138 - model vypracovala organizace ISO Jako hlavní
část snahy o standardizaci počítačových síti nazvané OSI a v roce 1984 ho přijala
jako mezinárodní normu ISO 7498. Kompletní text normy přijala také CCITTJako
doporučení X.200. Referenční model ISO/OSI se používá Jako názorný příklad
řešení komunikace v počítačových a telekomunikačních sítích pomocí
vrstevnatého modelu, kde jsou Jednotlivé vrstvy nezávislé a snadno
nahraditelné. Referenčni model ISO/OSI - ISO/OSI model vypracovala
organizace ISO Jako hlavní část snahy o standardizaci počítačových sítí nazvané
OSI a v roce 1984 ho přijala jako mezinárodní normu ISO 7498. Kompletní text
normy přijala také CCITT Jako doporučení X200. Referenční model ISO/OSI se
315 https://cs.wlklped.la.org/wik!/Analýza_kořenových_př%C3%ADčin
30 https://cs.wlk1pedia.org/wikVReferenčn%C3%AD_modeLISO/OSI

používá jako názorný příklad řešení komunikace v počítačových a
telekomunikačních sítích pomocí vrstevnatého modelu, kde jsou Jednotlivé
vrstvy nezávislé a snadno nahraditelné.
Repozltáf37 - označení pro místo, odkud mohou být staženy a nainstalovány
softwarové balíčky. Označení repozltář se často používá v souvislosti
s baUčkovacími systémy unixových distribucí (Linuxová distribuce, BSD varianty),
kde Je repozitář nejčastěji server (může to ale také být lokální adresář nebo
vyměnitelný disk), na kterém Jsou fyzicky umístěny softwarové balíčky
připravené pro instalaci do systému. Dále se repozitáře používají pro rozsáhlé
aplikace vyvllené na míru.
Retenční lhůta - lhůta, po kterou Jsou vybrané dokumenty archivovány bez
možnosti Je změnit čl smazat.
RPO a RTO 38 (zkratka z anglíckého Recovery Point Objectlve a Recovery Tlme
ObJectlve) - Jedná se p nejdůležitější parametry pro Disaster-Recovery Plan
(DRP). RPO vyjadřL!.]e množství dat o které je možné přijít při havárii, vyJadřL!Je se
v čase. U transakčních systémů zpracovávajících obchodních operace Je

nezbytné cílit na RPO O, tj. žádná ztráta dat To znamená, že Jakmile systém
protistraně (užlvateU nebo Jinému systému) potvrdí provedení transakce, nesmí
se v důsledku havárie stát, že by došlo ke ztrátě informace o provedení
transakce. Jediné Informace o které Je přípustné přiJít jsou rozpracované
transakce v okamžiku havárie. RTO představuje maximální přípustnou dobu
obnovy dat. tento parametr přímo souvisí s maximální přípustnou dobou
výpadku systému. Oba parametry přfmo ovlivňují HW i SW architekturu
informačního systému.
RSV - registr silničních vozidel
37
https://es.wlklp edla.org/wik i/Softwarový_ repozltá ř
38
https://en.wiklpedla.org/wiki/Disaster_recovery#Recovery_potnt_objectlve

Řešitel - viz. Poskytovatel
Server39 - obecné označení pro počítač, který poskytuje nějaké služby, nebo
počltačový program, který tyto služby realizuje. V unixových systémech Je
případně označován jako démon (anglicky daemon), v Microsoft Windows
potom Jako služba (anglicky service).
SFDJ40 (Státní fond dopravní infrastruktury, dále takéJako Fond) - zřízen zákonem
č.104/2000 Sb., o Státním fondu dopravní Infrastruktury, ze dne 4. dubna 2000
s účinností k 1. červenci 2000. Účelem Fondu je financování výstavby,
modernizace, oprav a údržby silnic a dálnic, celostátních a regionálních drah a
dopravně významných vnitrozemských vodních cest v rozsahu stanoveném
citovaným zákonem. Fond v souladu se svým účelem vykonává činnosti
zprostředkujícího subjektu OP Doprava. Fond je služebním úřadem.
SIEM41 (zkratka z angllckého Secur!ty lnformatlon and Event Management) -
management bezpečnostních informací a událostí. SlEM Je schopen
shromažďovat analyzovat a prezentovat Informace ze sítě a bezpečnostních
zařízení, pomáhat spravovat Identity a přístupy, ohrožená místa, shody s
bezpečnostními politikami atd.
Současně řeší dříve různorodé kategorie:
SIM (Sec u rity í nformation Management), které se zabývá dlouhodobým
ukládáním událostí.Jejich analýzou a hlášením problémů.
SEM (Security Event Management), jež se zabývá monitoringem
infrastruktury, korelacemi události a alertováním v reálném čase.
Pojmy SIM, SEM a SIEM bývají často zaměňovány, přestožejsou významově I
přínosem rozdílné.
39
https://cs.wikipedia.org/wikl/Server
-40 https.//www.sfdi.cz
<11. https://cs,wikipedla.org/wlkl/Securlty Jnformation_and_EvenLManagement

Skartační Lhůta - lhůta pojejímž u plynutije archivovaný dokument automaticky
skartován.
SLA42 (zkratka z anglického Servlce-level agreement) - termín, který označuje
smlouvu sjednanou mezi poskytovatelem služby a jejím uživatelem. Většinou se
Sl.A týká oblasti IT, ale není to vždy podmlnkou. Poměrně obšírně se tématem
poskytování IT služeb zabývá metodika ITIL. Každé prodání (poskytnutíl
produktu (software, služby, výrobku, ..) Je provedeno zároveň s definicí toho
produktu. Tato definice by měla uživateU I výrobci vymezit jasná pravidla.Jak se
o produkt dále starat,jakjej použ/vat ajeho cenu. Například se jedná o záruku
na produkt, běžné užltl produktu, k čemu Je produkt určen, kolik produkt stojí
apod.
Služby platfonny - služby výpočetního výkonu (HW a SW platformy),
poskytované v rozsahu a způsobem který Je zapotřebí pro vytvoření a řádné
fungování EDAZ.
Smlouva - závazný návrh smlouvy o vytvoření IS EDAZ .Informačního systému

pro evidenci vozidel v systému časového zpoptatnšnř a poskytování
souvlsejídch služeb, vlz 1.3.1
SNMP43 (zkratka z anglického Slmple Network Management ProtocoO - součástí
sady internetových protokolů. Standardně využívá port udp. Slouží potřebám

správy sftf: Umožňuje průběžný sběr nejrůznějších dat pro potřeby správy sítě, a
Jejich následné vyhodnocováni. Na tomto protokolu je dnes založena většina
prostředků a nástrojů pro správu sítě. Protokol SNMP se vyvjlel postupně ve
třech verzíchprvnl verze (SNMPvl) zajišfLtie základní funkcionalitu SNMP, druhá
(SNMPv2) obsahuje navíc autentizaci a třetí (SNMPv3) šifrováni (zabezpečeni).
Nejvíce zařízení podporuje druhou verzi.
-12 https://cs.wlklpedia.org/wlki/Service-levelagreement
43
https://cs.wlkipedia.org/wiki/Slmple_Network_Management_Protocol

Socket-4-4 (česky patice čl slot) - konektor na základní desce určený pro připojení
procesorů. V roce 2007 patřila většina procesorů serverových a desktopových

počítačů k těm určeným do socketu, obzvlášt procesory architektury x86.
SPOF (zkratka z anglického Single Point Of Failure) - neredundantní část řešení.
které při závadě způsobí výpadek služby.
SŘB~5 (systém řízení báze dat, dle angUckého database management systém
(DBMS)) - softwarové vybavení. které zajišfuJe práci s databází. tzn. tvoří rozhraní
mezi apUkačnfmi programy a uloženými daty. Občas se pojem zaměňuje s
pojmem databázový systém. Databázový systém však Je SŘBD dohromady s
bází dat.
SŘBI (Systém řízení bezpečnosti informacD - soubor aktivit vycházejíci
z povinností definovaných ZoKB.
Standalone server48 (v překladu dedikovaný server) - pronaJatý hardware od
poskytovatele do užíváni zákazníka. Za funkčnost a opravy serveru ručí
poskytovatel (vlastník serveru; Obvykle dedikovaný server zůstává v datovém
centru poskytovatele a zákazník k němu nemá fyzický přístup. Poskytovatel
předá zákazníkovi tzv. holé železo nebo předinstalovaný operační systém a
předá přístupy. V případě bez instalace pak pflpojí externí CD-ROM nebo USB
Flash disk nebo využije některý z management systému jako ILO, iDRAC čl Jiný
lp mng - názvy se Uší podle výrobce serveru.
SW4 7 (software) - v Informatice sada všech počítačových programů použlvaných
v počítači. které provádějí nějakou činnost Software Lze rozdělit na systémový
software. který zajišťuje chod samotného počítače a jeho styk s okolím a na
""https://cs.wikipedla.org/wlkVPatlce_procesoru
,v; https://cs.wiklpedia.org/wiki/Systém_f%C3%ADzen%C3%AD_báze_dat
-1e htlps://es.wikipedia.org/wiki/Dedikovaný_server
,,., https://cs.wlkipedia.org/w!kVSoftware

aplikační softw are, se kterým buď pracuje uživatel počftače nebo zajlštuje řízení
nějakého stroje (viz embedded systém).
Syslog-48 - standard pro záznam programových zpráv. Syslog může sloužit ICT
systémovému managementu a bezpečnostnfmu auditu Jako zdroj Informaci pro
analýzu anebo Ladění systému. Proto syslog může sloužit pro Integraci
logovaných dat mnoha různých systémů. Syslogje protokol typu kllenl/server.
Logovad aplikace pošle textovou zprávu na syslog př1jfmač. Přijímač se obvykle
nazývá syslogd. syslog daemon nebo syslog server. Syslog zprávy můžou být
poslány přes User Datagram Protocol (UDP) nebo přes Transmlsslon Control
Protocol (TCP). Poslaná data Jsou v otevřeném textu, ačkoliv mimo syslog
protokol může být použit SSL wrapper pro zajištění šifrovací vrstvy skrze
SSL.íTLS. Syslog používá číslo portu 514.
Šifrovací kUč411 - v kryptografii je klíč informace, která určuje průběh
kryptografického algoritmu. Při šifrování klíč určuje transformaci zprávy do
šifrovaného textu, při dešifrování Je tomu naopak. V bezpečných algoritmech,
šifrováním zprávy pomocí různých klíčů dostaneme kompletně různé šifry a také
dešifrování nesprávným klíčem dá náhodně vypadající text (nicméně existují
také kryptosystémy, kde dešifrováni různými klíči může dát různé rozumně
vypadajíc! zprávy). Klíče se používají také v digitálních podpisových schématech
a hašovacích funkcích (také MAC - message authentication code), často
používaných na autentizaci. V praxi Je užitečné pfedpokládat, že kryptografický
algoritmus je útočníkovi znám a spoléhat sejenom na bezpečnost klíče, protože
je většinou Jednodušší uchovat v tajnosti relativně malý klíč, nežli detaily
algoritmu. Tento princip se nazývá Kerckhoffovo pravidlo- Jen bezpečnost klíče
zaručí bezpečnost systému·. nebo ,nepřítel zná tvůj systém'.
.+e https://cs.wil<ipedla.org/wlkl/Systog
-48 https://cs.wikipedia.org/wlkVK1%C3%ADč_(kryptografie)

Šifrování dat6° -proces, kterým se nezabezpečená elektronická data převádí za
pomoci kryptografie na data šifrovaná, čitelná pouze pro majitele dešifrovacího
kliče. Šifrováni dat slouží k jejich ochraně proti nežádoucímu zjištění cizí osobou
a uplatňL!.]e se při ukládání dat I při Jejich přenosu včetně telekomunikace. různé
přihlašovací údaje a jiné citLivé soubory, nebo jim lze chránit například
elektronické bankovnictví. nebo data posílaná internetem. Šifrování dat zamez I,
že se ke zprávě nedostane po cestě další osoba nebo zamezí přístup do vašich
dat při krádeži fyzického zařízení (například Notebooku. mobilu. USB flash disku,
externích disků. DVD, aj.). Jednoduše - jedná se o proces, kdy z čitelného textu
pomocí šifrovacího algoritmu a klíče vytvoříme text zašifrovaný.
TCP51 (zkratka z anglického Transmlsslon Control Protocol) - nejpoužívanějším
protokolem transportní vrstvy v sadě protokolů TCP/IP používaných v síti
Internet Použitím TCP mohou aplikace na počítačích propojených do sítě
vytvořit mezi sebou spojení, přes které mohou obousměrně přenášet data.
Protokol garantuje spolehlivé doručování a doručování ve správném pořadí. TCP
také umožňuje rozlišovat a rozdělovat data pro více aplikací (například webový
server a emailový server) běžících na stejném počítači.
TCP/IP62 <zkratka z anglického Transmlsslon Control Protocol/lnternet Protocol,
česky .prlrnárnř přenosový protokol/protokol síťové vrstvy") - obsahuje sadu
protokolů pro komunikaci v počítačové síti aJe hlavním protokolem celosvětové
sítě Internet. Komunikační protokol je množina pravidel. která určují syntaxi a
význam Jednotlivých zpráv při komunikaci.
UDP63 (zkratka z anglického User Datagram Protocol) - Jeden ze sady protokolů

Internetu. O protokolu UDP říkáme. že nedává záruky na datagramy, které
60https://cs.wlkipedia.org/wikVŠlfrován%C3%AD _dat
61https:/ /cs.wlklpedla.org/wlkí/Transmission_ControLProtocol
~ https://cs.wiklpedla.org/wikl/TCP/IP
~ https-.//cs.wiklpedla.org/wikVUser .DataqramProtocol
Znalecký posudek č. 14/2/2019

il~~~-·----------- 28
přenáší mezi počítači v síti. Někdy je označován jako nespolehlivý . ale správněji
by mělo být bez záruky doručení. což je hlavní rozdíl proti protokolu TCP.
Protokol UDP Je vhod ný pro nasaz ení, které vyž aduje Jednod uchost, malá režie
nebo pro apUkace pracující systémem otáz ka-odpo věď (např. DNS. sdílení
souborů v LA N). Jeho bezstavovost Je už itečná pro se rvery. které obsluhují
mnoho klientů nebo pro nas az ení. kde se po čítá se ztrá tami datagramů a není
vhodné, aby se ztráce l čas novým odesíláním (starých) nedoručených zpráv
(např. VolP. online hry).
Vícevrstvá archltektura" - označuje v softwarovém Inženýrství aplikace.jelichž
funkčnost netvoří Jeden celistvý program, ale více vzájemně spolupracuiiclch
vrstev, které běží zpravidla na různé výpočetní Infrastruktuře. Příkladem může
být internetový obchod.jehož klientská část běží v prohlížeči uživatele, aplikační
logika na webovém čl aplikačním serveru a data (např. popis prodávaných
produktů a objednávky) Jsou uložena v databázovém serveru. Sousedící vrstvy
spolupracull přes definovaná rozhraní a mohou proto být zaměňovány, aniž by
to mělo dopad na funkčnost celé aplikace. Přenos dat mezi vrstvamije součástí
architektury. Bývá založen na standardních protokolech a technologiích, Jako
Jsou CORBA, Java RMI. .NET Remotlng, sokety, UDP nebo webové služby. Ačkoli
počet vrstev není nijak definován, nejčastěji se používá třívrstvá architektura,

která se skládá z následulícřch vrstev:
Prezentačnf vrstva - zobrazuje Informace pro uživatele, většinou formou
grafického uživatelského rozhraní, může kontrolovat zadávané vstupy,
neobsahuje však zpracování dat
Aplikační vrstva (též Business Logic) - zde ležf Jádro aplikace, její logika a
funkce, výpočty a zpracování dat.
64
https://es.wlkipedla.org/wikVV%C3%ADcevrstvá_archl:ektura

Datová vrstva - tuto vrstvu tvoří nejčastěji databáze, která data uchovává,
zpřístupňuje a zaručuje jejich konzistenci. Může zde být ale také (síťový)
souborový systém, webová služba nebo Jiná aplikace.
Vlrtuallzace66 - označení postupů, technik a prostředků, které umožňult
v počítači přistupovat k dostupným zdrojům Jiným způsobem, než jakým fyzicky
existují, jsou propojeny atd. VirtuaLizované prostředí může být mnohem snáze
přizpůsobeno potřebám uživatelů, snáze se používat. případně před uživateli

zakrývat pro ně nepodstatné detaily ~ako např. rozmístění hardwarových
prostředků), Virtualizovat lze na různých úrovních, od celého počítače
(tzv. virtuální stroj), po Jeho Jednotlivé hardwarové komponenty (např. virtuální
procesory, virtuální paměť atd.), případně pouze softwarové prostředí
(virtualizace operačního systému).
Virtuální OS - Jedna Instance operačního systému v rámci virtualizace.
VI.J\N65 <zkratka z anglického Vlrtual LAN) - logicky nezávislá sít v rámci jednoho
nebo několika zařízení. Virtuální sřté lze definovat jako domény všesměrového
vysílání (stejně Jako LAN) s cílem učinit logickou organizaci sítě nezávislou na
fyzické vrstvě, čímž lze usnadnit správu sítě, zvýšit Její výkon a podpořit
bezpečnost. Obvykle bývá realizována na zařízeních zvaných přepínač, Jehož
porty se rozdělí na několik logicky samostatných částí. Jde o dělení sítě již na
úrovni 2. vrstvy ISO/OSI modelu. Přepínače je možné propojltjedlným spojem a
jejich software zajistí komunikaci samostatných sítí se stejnými klienty (Tag,
neboli značka Je součástí pouze Tag-Based VLAN, t]. IEEE 802.lQ). V principu se
Jedná o nadstavbu nad běžným ethernetovým protokolem. K běžným paketům
je připojena informace o čísle virtuální sítě (značka 4 B, takže rámec až 1520 B),
65 https.l/cs.wlklpedia.org/wiki/Virtualizace
an https://cs.w1klpedia.org/wikl/VLAN
Znalecký posudek č. 14/2/2019 - 30

kterou protější zařízení využije k rozpoznáni příslušnosti k síti. Nejrozšfřehějšf
normou VLA N je tagovací protokol IEEE 802.lQ.
VoKBli7 - Vyhláška č. 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áni
v oblasti kybernetické bezpečnosti a likvidaci dat (vyhláška o kybernetické
bezpečnosti).
Vývojové prostředi58 - prostředí sloužící pro potřeby Poskytovatele, na kterém
probíhá vývoj informačního systému. Jeho struktura a konfigurace je plně v režii
dodavatele a dynamicky se měniv průběhu vývojového cyklu. Prostředí se může
skládat z více instancí, které slouží Jednotlivým vývojovým týmům. Na toto
prostředí se obvykle kontinuálně nasazují aktuálně prováděné změny v aplikaci,
konfiguraci i ve verzích komponent třetích stran. Vývojové prostředi zahrnuje
také sadu vývojových testovacích a ladících nástrojů.
WAF6; (zkratka z anglického Web Appllcatlon Firewall) - chrání před útoky na
webové aplikace, které zneuživaji zranitelná místa aplikace či protokolů
kompromitaci cíle. WAF na rozdíl od běžných firewallů chrání před útoky na

webové aplikace a útoky typu odepření služby. Na rozdíl od tradičních sítových
firewallů, které bez hloubkové uinspekce propouštějí HTTP, HTTPS nebo FTP
provoz do webových aplikaci, Web Application Firewall fung4Je Jako
obousměrný proxy tohoto provozu. Kontroluje, zda provoz neobsahuje útoky,
Izoluje webové servery od přimého přístupu · hackerů. Kromě toho Web
Application Firewall elimim\je útoky prováděné záměrnými změnami dotazů

aplikaci (např. znemožňuje úpravy cookies).
51
https/ /www.zakonyprolldl.cz/cs/2018-82
68
https:/ /en.wlkipedla.org/wiki/DeploymenLenvlronment
~ https:/ /en.wlkipedla.org/wiki/Web_appUcatlon_flre\lí'aU

Webový server' 0 - systém odpovědný za vyřizování požadavků HTTP od klientů
(nejčastěji webových prohlížečů). Vyřízením požadavků se rozumí odeslání cíle
specifikovaného URL (typicky webová stránka, ale též statický text, obrázek či
jiný soubor). Webové stránkyjsou obvykle dokumenty v jazyku HTML
x8681 - v Informatice označení rodiny instrukčních sad pro procesory navazující
na 16bitový procesor Intel 8086. Označení x86 též definuje hardwarovou
počítačovou platformu (architekturu) označovanou jako IBM PC kompatibilní.
Protože byl termín .x86" zaveden až po uvedení procesoru Intel 80386, typicky
se při použití označení .x86" předpokládá, že daný procesorJe alespoň 32bltový
(tj. 80386 nebo novější, protože tyto procesory Jsou schopné zpracovávat
strojové instrukce původního 16bltového režimu pro zallšténl zpětné

kompatibility). Aby byla tato skutečnost zdůrazněna. používá se též označení
x86-32 (resp. IA-32) a pro současné 64bltové procesory pak x86-64 (též ,x64").
V současné době proto ,x86" označuje tři architektury s třemi různými sadami
strojových instrukcí, přičemž novější procesory jsou schopné pracovat v
režimech, které za Jistých podmínek dovolují zpracovávat strojový kód
předchozích architektur.
Základní SW - softwarové vybavení. které není součástí lnfomačního systému.
Informační systém tento základní software využfvá pro svoji činnost, Jedná se
zejména o operační systémy fyzických a virtuálních serverů. virtuallzační SW,
databázový englne. antivirus. nebo monitoring.
Záloha dať52 (někdy též záložní kopie- anglicky backup)- kopie dat uložená na
Jiném datovém nosiči (nebo I místě). Záložní datajsou využívána v případě ztráty,
poškození nebo jiné potřeby práce s daty uloženými v minulosti. Zálohování
00
https://cs.wlklpedia.org/wikl/Webový_server
ei https://cs.wikipedia.org/wiki/X86
C12 https://cs.wikipedia.org/wikVZálohován%C3%A D_dat

probíhá nepravidelně (např- v domácnostech) nebo pravidelně podle rozvrhu
(např. ve firmách).
ZoKBe3 - Zákon č. 181/2014 Sb. o kybernetické bezpečnosti a o změně

souvisejících zákonů (zákon o kybernetické bezpečnosti).
es https://W\\'Wzakonyprolidi.cz/cs/2014-181

2. POSUDEK
2.1, Vý chozí sta v
Znalec vychází z dokumentace poskytnuté okruhu řešitelů připravovaného
informačního systému EDAZ (viz seznam podkladů v kapitole 1 3. posudku).
Projekt EDAZ, resp, IS EDAZ si klade za cíl změnu způsobu úhrady časového
poplatku ve vazbě na registrační značku vozidla, Jakož i změnu způsobu
prokazování a kontrolu této úhrady. EDAZ plně nahradí existující systém úhrady
časového poplatku prostřednictvím zakoupení dálničních kupónů.
2.1.1. Kontext a předpoklady řešení
~ ~ PattaMer\tu ~ r~ttli(y ·byl~ k pt ~ ní
hit:str~ zákrma ~ - m~ z~or, č. Wm:9'7Sb., o pozeřhflfch ~ cích.
ve znerú~•m ~. a daW ~ ~kt>nv-
Hktvntm olmn ~rnM'to niw f hti e je ~ zpň6oou úJ,rady ~

:popll'ftlru i& t4W apopl~h ~ ~t~ l zm:Ěifta zpósobv
1iJf0~0VffiÍ ei ttontnity t8t$ ~- ~ ~- ·ea;O',)léht> ~t:k'U se
~k·~~-Om~něs.sayhni~s~~
~ 15 tut,y ~Jer\ .vo:Hil::o'l pflč..etmJf ~ ~dlá. kter&_Jsau
dle zátronfi3 od.zpc!)ptatněni~na.
V ~né: dPbi jie úhf&Ja ~ ~ provádí ~koupením ~nlčroho

~Je~ dli se~ M félnís~ ~a dru~dťl~ mft.f.íi;:flč
u seoe pn užtti ~ěné posemm ~ pro účen,y k-orw-oty. K.c,ntfQtu
úhrady čaS:ovéhe ~ ~~ ~ ~ poffdsW pftl;no na
~fFenýcti p02$ITI!itd\ ~tch. lide mus{ ~ .Z~lt
Pf.ed!oZilný névm ZékOna ~ ~ úpravu~ ~ po~k\.{ ~

I ~i na ~seru ~ ~. Úhfedu ~ m.~ provádě t 1
----· -
r· . - -
j bal.hO.rovostrnl pr.estf-ectrnct-vfm tntmmetu a FnQbHnkh apUkaci. Pr©°ll'.eeenf
ů.htadY b.ude zaznatnenánc v -evft:t~ncl v.ozldEi!l v systému časo'.ltého :zpop1atněnf.

tj. v tnf-oPM~im ~slému veřejné správy. kt~rýbude pro.vo.zovat Sffil. Do této
&tld~ btJd:ou zrui:namen-á'<tána r:ovně.t vozldte csvebcze né od zpoptatněnL a
J to na $:lkl:adi ~ámen í prevm:0~ ů taffe);lýoh vozidel a~ovahý:ch st:Dt.
Kontrola út:trad3/ éésového po.plátku bude pro.váděAa t ~ s využrtim
karn'Qf~o-sy$'tému, ktery bude r~ávat re,istfačnt Jnačky ~el a bude

tak ově~. mJe má vo~dio uh~ časový p~lat~ neb.o zda Je
00\lG tmzeoo Od -~ ipoplatn.ěm v pro.vozu tati! burtou prfl"!1árně
zpop'lat-něflé ~mni !<omunlkáte bez llhrad.y časového ?~ a ktera

~ v«llena v 'fivtaiand ~áfnu ~ ~ zpo~atr-iěni Jako vezlclta
O$VO~ftá od zpcplatněR1.
2.12. IS EDAZ
Znalec nlže uvádí základní popis Informačního systému EDAZ, resp. účel
smlouvy tak, jak je definován v závazném návrhu smlouvy. Vice dále uvedeno
v kapitole 2.2. Analýza předmětu smlouvy.
Účel smlouvy
a.1 Úhelerri teto Smlot.!Y'f je ,aattz~ ~ ts EOAZ. tj.. ~ nivthu a

sqwfsejicf ~. podpory e ~ ~ ~mu pro vl~r\í
evidenci VO~ 'V~ ~ého Z?opl.atnělli ~ jen· .ri ®s )l ýt véetné

HW a 5W ~y <dát-e jBt'1 ~") .p.ót~& pro Jěf16 provez, ~ EOAZ
oode Pe&li20Yén v náVal-rios:tl na ~ f zakena c. ii l /20:1# $b., kterým se mění
t ~ č. lJ/1007 $b., o po.remrneh k-om~acictl (dél-eJen „ZOW). e bude .dle 1
21c ň0,tE 2 ZOPK Fl1ťw.mačntm S)'stémem veř(ajné S?fá\ky, .který ~i k evldend

matm01/',?Cb ~x!del ~méně $lil étyf'rni Wy, j~ pb'$0l~mt ~ člnf
~še ::t5 tJJny, oprávněnych k použití zpopta~á ~ot!:minf kornurúkace il
z~f ~ ~oty ·fi3· ~ ko:~:ctch. ~o-st téilo oo\HJlyj

ZOR<J~stanovena na t leďfla aoz1
---
2.2. Analýza předmětu smlouvy
Struktura cenyje objednatelem požadována následovně (viz podklad 13.4. 01.2-
Strukt.ura_cenove_nabidky):
Platebnf mil.nik Cena v Kč 1D

bez DPH
Cena díl.a Návrh celkového řešení 5

Smlouva odst 3.1 Smlouva odst. 3.1 a)
Demoverze IS EDAZ ('Demoverze') 6

Smlouva odst 3.1 b)
Vytvoření dodání a zprovozněni IS 7

EDAZ ("Implementace")
Smlouva odst 3.1 c}
Dokumentace k IS EDAZ ('Finální 8
dokumentace IS EDAZ')
Smlouva odst 31 d)
Zkušební provoz IS EDAZ ('Zkušební 9
provoz')
Smlouva odst 31 e)
Celková cena Díla o 10
S m l ouva odst uela w. S elb w
. 3elecé .
uel dw . uelew
-
Jednotková cena Služeb Cena za 1 měsíc 11
provozní podpory IS EDAZ.
vyjma dalších požadovaných
činnosti uvede ných níže
Smlouva odst 32
I --

Plate bní mltnik Cena vKč IO
bez DPH
.___
Celková cena Služeb provozn f Celková cena Služeb provozní o 12
podpory IS EDAZ vyjma podpory IS EDAZ. vyjma dalších
dalších požadovaných činnosti požadovaných činnosti uvedených
uvedených níže po dobu 48 nlže za dobu 48 měsíců
měsíců
Smlouva odst 32
Jednorázová cena za zřízení Cena za zřízeni Služeb platformy 13
Služeb platformy
Smlouva odst 32 ...
Jednotková cena Služeb Cena za 1 měsíc 14
platformy
Smlouva odst 3.2 ->--
Celková cena Služeb Celková cena Služeb platformy po o 15
platformy po dobu 52 měsíců dobu 62 měsíců
Smlouva odst 32 ...
Jednotková cena Rozvoje, Cena za lMD 16
konzultaci a dalších
souvisejícich služeb
Smlouva odst 3.3
Celková cena Celková cena předpoktédaného o 17
předpokládaného rozsahu rozsahu 2000 MD Rozvoje,
Rozvoje, konzultací a dalších konzultací a dalších služeb
služeb
Smlouva odst 3.3
Oalšl poiadované člnnostf 18
Jednotková cena za zajištění Cena za 1 měsíc 19
provozu Call centra (CZ.ENG)
Smlouva odst 3.2 a PI čl 2.5.1
Celková cena za zajištění I Celková cena za zajištěni provozu o 20
provozu Call centra (CZ.ENG) Call centra (CZ,ENG) po dobu 48
po dobu 48 měsíců měsřeů
Smlouva odst 3.2 a PI čl 2.51 -
Jednotková cena za Cena za 1 měsfc 21
zpacování Listinných podání
Smlouva odst 32 a PI čl 2.52
Celková cena za zpracování Celková cena za zpracování o 22

listinných podáni po dobu 48 Ustlnných podání po dobu 48
měsíců měsíců
Smlouva odst 32 a PI čl 2.52

Platební milník Cena v Kč I 1D
bez DPH
Jednotková cena za zajištění Cena za 1 měsíc 23

.obchodních aktiviť v rámci
provozu eShop
Smlouva odst 32 a PI čl 2.5.3
Celková cena za zajištění Celková cena za zajištěni 01 24
.obchodnřch aktivit' v rámci „obchodních aktivitu v rámci
provozu eShop po dobu 48 provozu eShop po dobu 48 měsíců
měsíců
Smlouva odst 3.2 a PI čl 2.5.3
Cel.kowl nabJdk ová cena v Kč bez DPH

Celková nabídková cena v Kč Součet ceny uvedené na ř. 10, 12. o
bez DPH 13, 15, 17, 20. 22 a 24.
I
Poznámka: do tabulky byl doplněn sloupec ID pro usnadnění odkazováni na jednotlivé
řádky
Definice obsahu plnění jednotlivých bodů dle Smlou
1D 5 Návrh celkového řešení Smlouva odst 3.1 a)
a) provedení podrobné analýzy a vytvofenf detailního návrhu IS EDAZ
včetně provedeni celkové analýzy funkcionalit a jejich integračních
vazeb, tj. návrh vytvoření IS EDAZ, specifikace požadavků na
odpovídající hardwarovou Infrastrukturu a návrh Demoverze IS EDAZ,
a souvisejícf Implementace IS EDAZ na Infrastruktuře Objednatele (dále
jen ,Návrh celkového řešeni projektu"). Návrh celkového řešeni
projektu musí navazovat na popis návrhu řešení vyplývaj[cí z nabídky
Poskytovatele, který tvoří Přílohu č. 2 této Smlouvy (dále Jen .Nabídka
Poskytovatele - technická specifikace projektu") a bude respektovat
Znalecký posudek č. 1.4/2/2019 38

všechny závazné požadavky a specifikace Objednatele na funkčnost a
parametry IS EDAZ uvedené v rámci Přílohy č. 1 této Smlouvy (dále Jen
"Požadavky Objed natele"):
1D 6 Demoverze IS EDAZ ("Demoverze') Smlouva odst 3.1 b)
b) vytvoření, dodávka a vlastní zprovoznění Demoverze IS EDAZ
v prostředí Objednatele včetně udělení příslušných užívacích a
souvisejících oprávnění dle čl 16 této Smlouvy (dále jen .Demoverze"),
včetně úvodní migrace dat. Výsledky akceptačního řízení Demoverze
se Poskytovatel zavazuje zahrnout do Návrhu celkového řešení
projektu IS EDAZ a předatjej Objednateli k akceptaci;
1D 7 Vytvoření. dodání a zprovoznění IS EDAZ ("Implementace") Smiouva
odst 3.1 c)
c) vytvofení, dodání a zprovoznění IS EDAZ v prostředí Objednatele, a
to v plném rozsahu funkcionalit IS EDAZ a v Interakci se zdroji dat
Objednatele čl třetích osob, a dále v souladu s aktualizovaným
Návrhem celkového řešení projektu a schválenou Demoverzí, včetně
kompletní migrace dat do IS EDAZ, včetně udělení příslušných
užívacích práv a souvisejících oprávnění dle čl 16 této Smlouvy (dále
jen .Implementace");
IO 8 Dokumentace k IS EDAZ ('Finální dokumentace IS EDAZ'} Smlouva
odst 3.1 d)
d) vytvoření a dodání kompletní dokumentace IS EDAZ, zahrnulícl
admlnlstrátorské, uživatelské, provozní. školící a další směrnice

vztahující se k IS EDAZ (dálejen .Flnální dokumentace IS EDAZ')
IO 9 Zkušební provoz IS EDAZ ('Zkušební provoz") Smlouva odst 3.1 e)

e) provedení a podpora zkušebního provozu IS EDAZ vč. závěrečné
kompletni migrace dat po akceptaci Implementace v rozsahu a dle
podmínek uvedených Příloze č. 1 této Smlouvy (dále jen .Zkušební
provoz")
1D 11 - 15 a 18 - 24 Smlouva odst 3.2

3.2 Dále se Poskytovatel zavazuje poskytnout Objednateli služby
navazujícího provozu a technické podpory IS EDAZ, včetně podpory
Jeho užřvatelů po uvedení do provozu, v rozsahu a způsobem
popsaným v této Smlouvě a Jejích přílohách včetně aktualizovaného
Návrhu celkového řešení projektu (dále též jen jako .Služby provozní
podpory IS EDAZ"). V rámci poskytování Služeb provozní podpory IS
EDAZ se Poskytovatel zavazuje poskytovat rovněž další požadované
činnosti přímo nesouvisející s IS EDAZ, kterými jsou zajištění pro~ozu
call centra, zpracování Ustlnných podání a zajištění „obchodnlch
aktivit" v rámci provozu. Služby provozní podpory zahrnuj' rovněž
plnou součinnost Poskytovatele při Integraci IS EDAZ do jiných
systémů Objednatele a/nebo dalších zúčastněných subjektů provozu
IS EDAZ. BLižší požadavky na Služby provozní podpory IS EDAZ Jsou
uvedeny v Příloze č. 1 této Smlouvy. Poskytovatel se dále zavazuje
zajistit Platformu a dále poskytovat ObjednateU služby výpočetního
výkonu (HW a SW platformy), v rozsahu a způsobem kterýJe zapotřebí
pro vytvoření a řádné fungování Díla a naplňování níže definovaných
SLA (dáleJen .Služby platformy"). Bližší požadavky na Služby platformy
jsou uvedeny v Příloze č. l této Smlouvy.

1D 16 - 17 cena Rozvoje, konzultací a dalších souvisejících služeb Smlouva
odsl 3.3
3.3 Součástí plněni dle této Smlouvy Je také rozvoj IS EDAZ,
konzultační služby a další činnosti v rámci součinnosti a podpory (dále
jen ,Rozvoj, konzultace a další související služby'). a to v rozsahu
maximálně 2.000 člověkodnů čerpaných podle požadavků
Objednatele postupem stanoveným v této Smlouvě.
1D 19 - 21 zajištění provozu Call centra (CZ.ENG) Smlouva odst 3.2 a PI čl 2.5.1
Informace z 13.5. pozadovane_informace-20191103_v2
Uveďte, jakým způsobem Jste schopni zajistit poskytování podpory
koncovým uživatelům službou caLL centrum v nejméně následuJídch
jazykových možnostech: čeština, angličtina, němčina, polština.
Předmětem poskytovaných Informací jsou následující oblasti:
Informace o časovém zpoplatnění (ceny, podmínky), helpdesk pro
řešeni problémů při úhradě v eShop.
Poznómka: Znalec vychózí z předpokladu, že platná je novější Informace a Cali
centrum bude poskytovat služby pouze v češtině a angličtině.
1D 21- 22 zpracováni Listinných podání Smlouva odst 3.2 a PI čl 2.52. Informace
z 13.5. pozadovane_lnformace-20191103_v2
-SFDI požaduje, aby v rámci činností provozu systému a poskytováni
podpory koncovým uživatelům byla zajištěna také podpůrná činnost
zpracování Ustlnných podáni souvisejících s agendou EDAZJedná se
o následuJíci agendy:
• Ustlnná podání oznámení o Osvobozeni u provozovatel.Cl dle§
20a 1) písm. o) - zadání do EDAZ, kontrola náležitostí (podpis,
přílohy.~>:

■ Zpracováni Listinného podání nebo elektronicky doručené
žádosti o změnu SPZ (z důvodu změny SPZ na témže vozidle z
Jakéhokoliv důvodu).
1D 23 - 24 zajištěni ,obchodních aktivit" v rámci provozu eShop Smlouva odst. 3.2
a PI čl. 2.5.3 Informace z 13.5. pozadovane_!nformace-20191103_v2

SFDI požaduje. aby v rámci činností provozu systému byly zajištěny
také následulící člnnostl:
■ Zajištění správy a zpracováni přehledu kartových platebních
transakci provedených pro úhradu časového poplatku v eShop
- kontrola úplnosti a správnosti, fešenl neshod přímo s
bankou poskytující služby platební brány (na základě zmocnění
od SFDI).
2.3. Metodika určení ceny obvyklé
Předmět smlouvy Je komplexní, zahrnuje návrh, Implementaci a zprovoznění
Informačního systému, poskytnutí HW platformy a provozních služeb a další
služby.
Na základě výše uvedených Informacíje pro určení ceny obvyklé struktura ceny
stanovena následovně:
A Vytvoření Díla - IS EDAZ
Zahrnuje položky 5 -9, odpovídá řádku 10
B. Provoz IS EDAZ
Odpovídá řádku 12. Provoz a technická podpora IS EDAZ včetně podpory
jeho uživatelů po dobu 48 měsíců.
C. Zřízeni služeb platformy

Od povídá řádku 13. Zajištěni a příprava infrastr uktury (HW) pro provoz IS
EDAZ .
D. Služby platformy
Odpovídá řádku 15. Poskytování infrastruktury po dobu 52 měsíců.
E Rozvoj, konzultace a další služby

Odpovídá řádku 17. Poskytování služeb v celkovém rozsahu do 2000 MD
do 48 měsíců od zahálení provozu.
F. Dalšf provozní činnosti

Zahrnuje řádky 20, 22 a 24. Poskytováni služeb catl centra, zpracování
Listinného podání a zajištění .obchcdních' aktivit po dobu 48 měsíců.
Účelem tohoto rozdělen[Je seskupit předmět Smlouvy do co nejmenšího počtu
• homogenních položek" t;J. takových, u kterých je možné stanovit cenu obvyklou
stejným způsobem ajsou si věcně blízké.
Obvyklá cena pro položky B. Provoz IS EDAZ. E. Rozvoj, konzultace a další služby
a F. Další provozní činnosti je určena na základě určeni počtu MD v jednotLivých
rolích a jednotkové ceny.
Položka C Zřízení služeb platformy Je stanovena na základě odhadu na výkon
platformy a z určení počtu MD v jednotlivých rolích pro zřízení Implementace.
Položka D vychází jednak z výkonu platformy a typu SW určeném v bodě Ca
Jednak z určeni počtu MD v jednotUvých rolích, které částečně vyplývají z
požadavků na provoz.
Určení ceny obvyklé pro položku A Je nejkomplexnější. jedná s~ o specifické
dílo, které musí být vytvořeno na zakázku a způsob dosažení může mít mnoho

po dob. Znalec pro určení obvy klé ceny po stupuje násled ovn ě (dále více
v kapitole 2.6. Popis technického řešenD:
1) Doplněni seznamu funkčnlch požadavků o požadavky na ePodatelnu a
eVýpravnu dle podkladu 13.3. 00-Doplnenl-20191127 - Doplnění
požadavků SFDI.
2) Analýza funkčních požadavků a jejich rozdělení do logických modulů a
komponent.
3) Klasifikace požadavků. Dle jejich popisu a kontextu v rámci
Identifikovaného modulu a komponenty Je stanovena Implementační
složitost a jako doplňkový faktor Jsou zohledněny bezpečnostní aspekty.
4) Jsou určeny nestandardní faktory ovlivňující cenu Implementace a ty Jsou
zohledněny ve výpočtech. Jedná se zejména o nefunkční požadavky,
které nejsou zcela obvyklé a implikují dopad na cenu díla nebo jiné
faktory, například vyplývající z podmínek ve Smlouvě.
Viz kapitola 24. Faktory ovlivňujlcí cenu implementace.
5) Určení obvyklé ceny za MD pro jednotUvé role.
Viz kapitola 2.5. Kategorizace rolí a cena za MD
6) Určení celkové ceny Díla. Z Implementační složitosti (programovánD Jsou
odvozeny objemy souvisejících činnosti (Analýza, testy, Management, .. .).
Dále Jsou stanoveny další náklady vyplývající z předpokládaného postupu
Implementace projektu (Demoverze. migrace, zavedení, ...). Na výsledné
údaje jsou aplikována rizika a plánovaný zisk Dodavatele. Detailní postup
a výpočet viz kapitola 2.8.1. A Vytvoření Díla - IS EDAZ.
Zisk Poskytovatel není kalkulován samostatně, je zahrnut již v sazbách za MD.
viz kapitola Určení ceny pro JednotUvé kategorie rolí.

2.4. Faktory ovllvňujlcí cenu implementace
Rozsah a cenu implementace informačního systému na zakázku primárně určují
funkční požadavky. které jsou uvedeny v 1.32. Smlouva-Priloha.L část 1
1. Základní požadavky - IS EDAZ.
Složitost implementace však ovlivňují. a to někdy v podstatné míře, takzvané
.nefunkčnl požadavky" (Non-functlonal requirements), ty se zabývají těmi
vlastnostmi informačního systém, které sice nejsou funkčností. ale přesto jsou
důležité. Jedná se zejména o požadavky na použitelnost, spolehlivost, výkon a
podporovatelnosl Tato skupina požadavků se označuje URPS (Usability,
Reliability, Performance, Supportabllltyl. Kromě toho jsou v konkrétním případě
systému EDAZ podstatné také požadavky na bezpečnost, protože se Jedná a
důležitý systém státní správy s veřejným př/stupem.
Významné nefunkční požadavky byly identlflkovány v těchto podkladech:
• 13.2. Smlouva-Priloha_l část 2 Obecné požadavky- Systém EDAZ
• 13.2. Smlouva-Priloha_l část 5 Standardy uživatelského rozhraní apUkad

SFDI pro projekt Elektronická dálniční známka
Poskytovatel musí požadavky, Jejichž rozsah lze Interpretovat různě, vykládat
spíše maxlmaUstickým způsobem, protože smlouva mu nedává prostor jejich
rozsah omezil
2.4.1. Pfehled faktoru ovlivňujících cenu Implementace
Tato kapitola obsahuje přehled faktorů, které znalec vyhodnotlljako významné
a ovLivňující stanovení ceny obvyklé (resp. majících dopad na cenu obvyklou).
Dále znalec uvádí způsob,jakjsou v určení ceny zohledněny.

·-- - -
l
Faktor ovtfvněná část ceny Dopad
Deklarovaná volnost
- ~
Implementace EDAZ -
-
až10%
- - j
zadání položka riziko
I -
Požadavek na osvědčení - Odhad ceny lidských
NBÚ stupně ,D' nebo vyšší zdrojů.
--
+15 %
--- ---- -
--
Harmonogram ---Implementace EDAZ - až10 %
položka riziko
IP&adaveknapodporu Webová část aplikace +15%

Internet Explorer
-
Nároky na bezpečnost Zohledněno v odhadu Zohledněno v odhadu
požadavků jednotlivých požadavků.
-
Výkonnostní parametry Zohledněno v odhadu Zařazení do vyšší skupiny
požadavků implementační složitosti.
Standardy uživatelského Komponenta Základ Zohledněno v odhadech

rozhraní webu implementace
Kompetence Dodavatele Implementace EDAZ - až5%

za testy položka celkové riziko
Omezená flexibilita Implementace EDAZ - až5%

---
I
součinnosti položka celkové riziko I
Deklarovaná volnost zadání
Objednatel deklaruje následující (Podklad 1.32. Smlouva-Prlloha.L část
1. Základní požadavky - IS EDAZ, Kapitola 2):
, Uvedené požadavkyJsou pouze demonstrativním výčtem zókladnfch požadavků
na/SEDAZ.
Objednatel požadule dodat IS EDZ ve funkcionalitě plně vyhovujfcíplatnému znění
zákona č.13/199'7Sb. ve znění pozdějších předpisů a další související legislativy.·
Z pohledu Poskytovatele tímto Objednatel ze sebe částečně snímá
zodpovědnost za správnost a úplnost zadání a přenáší ji na něj. Zároveň nejsou

ve smlouvě definována žádná protiopatření. která by dopad při zjištěn!
významné nesprávnosti či neúplnosti zadání kompenzovala. Z toho vyplývá, že
určeni ceny musí s touto okolností počítal
Znalec odhaduje dopad na riziko implementace až 10 %.
Požadavek na osvědčeni NBÚ stupně .o• nebo vyšš!

IT trh v české republice se dlouhodobě potýká s nedostatkem kvalifikovaných a
schopných pracovníků. Jakýkoliv nadstandardní požadavek na kvaliřlkaci.jako je
v tomto případě osvědčení NBÚ stupně .D" nebo vyšši. zvyšuje cenu těchto
zdrojů.
Znalec odhaduje zvýšení ceny za MD v souvislosti s požadavkem na osvědčení
NBU o 15 %. To Je zohledněno v určení sazeb v kapitole 2.5.2. Určeni ceny pro
jednotlivé kategorie rolí.
Harmonogram
Podpis smlouvy se předpokládá 15.1.2020.
V podkladu 1.3.3. OO-Doplnenl-20191127 - Doplnění požadavků SFDI v kapitole 7
Harmonogram se uvádí:
.SFDI předpokládá následující harmonogram realizace projektu. Součástí
návrhu a nabídky Řešitele je však předložení návrhu harmonogramu z Jeho,
který bude podkladem pro dalšíjednání.
152.2020 detailní analýza
132020 detallnl analýza 'Dodavatel"
5.4.2020 MockAPI
15.2020 prototyp

30.6.2020 zahájení integračních testů
19.2020 zahájení UAT
15.112020 spuštění rutinního provozu"
Je zřejmé, že harmonogram Je podřízen nutnosti uvést systém do provozu v
souladu s legislativou.
Z pohledu Poskyt ovatele Je nutné chápat harmonogram Jako velmi náročný,
například na dod ání .detallní analýzy" je v harmonogramu prostor pouhý měsíc.
Splněni takového harmonogramu vyžadule vysokou míru paralelizace prací, což
s sebou nese vyšší nároky na koordinaci a rizika.
Znalec odhaduje dopad na riziko implementace až 10 %.
Požadavek na podporu Internet Explorer
Internet Explorer je zastaralá technologie, která se přestala funkčně rozvíjet v
roce 2015. MlcrosoftJeJ sice stále podporule a není oznámeno datum ukončení
podpory, nicméně pro operační systém Windows 10 doporučuje použití EDGE
Jako výchozího prohlížeče a Internet Explorer používat Jen pro zpětnou
kompatlblUtu, tou se mysli podpora historických podnikových Implementací
{obvyklým případem je starší verze SAP). Viz
https://support.mi crosoflcom/en-us/help/17454/llfecycle-faq-l nternet
explorer
Dopady požadavku na Implementaci:
• Nutnost přlzpůsobování webové aplikace zastaralému prohlížeči
omezuje možnost použití moderních frameworků, které usnadňují vývoj a
poskytují lepší možnost! Interakce uživatelského rozhraní. Zároveň se
zvyšují nároky na testy.
Znalec odhadule dopad na Implementaci základu webové aplikace 15 %.

Dopad je aplikován v kapitole Implementační složitost dle modulů a komponent
Nároky na bezpečnost
Vzhledem k výz namu bezpečnostních aspektů, jsou tyto zohledněny přímo v
posouzeni Jednotlivý ch poža davků, viz kapitola 2.6.2. Klasifikace požadavků.
Výkonnostní parametry
Tam, kde jsou na komponenty kladeny vysoké výkonnostní požadavky (eShop,
Evidence,...), Je tato skutečnost zohledněna přímo v ohodnocení jednotlivých
požadavků, viz kapitola 2.62. Klasifikace požadavků.
Standardy uživatelského rozhranf
Standardy uživatelského rozhraní jsou popsány v podkladu 132. Smlouva
Priloha_l, část 5. Standardy uživatelského rozhraní apUkací SFDI pro projekt
Elektronická dálniční známka.
Dokument předepisuje velmi konkrétní řešení funkce uživatelského rozhraní v
někoUka vybraných aspektech. Zejména se podrobně zabývá zobrazováním a
práci s daty v tabulkových seznamech a tvorbou interaktivních sestav.
Toto zadání je poměrně sofistikované a přesahuje běžnou funkčnost
uživatelského rozhraní pro transakční systémy. Bude nutné vytvořit speciální
sadu komponent podporujících popsané funkčnosti (respektive nalézt a upravit

komponenty s podobnou funkčnosti).
Dopad je zohledněn v ohodnoceni požadavků spadajících do komponenty
,Základ webu" , viz kapitola 2.6.2. Klasifikace požadavků.
Znalecky posudek č. 14/2/2019 49

Kompetence Dodavatele za testy
Viz 13.2. Smlouva-Priloha_l část Obecné požadavky - Systém EDAZ , kapitola
2.8., OP0-76:
,Pro potřeby provedení test ů v rámci akce ptace díla připraví Poskyt ovatel
Test ovací Plán. Poskytovatel připraví do prostředí Objednatele sadu

testovacích scénářů včetně testovacích dat vážících se ke každému z
Implementovaných případů. Testovací scénáře budou odrážet buslness model
Před každým kolem testů připraví Poskytovatel pro každý použitý testovací
scénář testovací data v samotné aplikaci a v navázaných systémech. Provedení
testů v rámci akceptace bude na základě připravených scénářů a dat realizovat
Objednatel čijím pověřená třetí strana. Případné chyby nalezené při testován[Je
Poskytovatel povinen na své náklady odstranit Popis a řízenf odstranění chyby

(bug tracking) je prováděn v prostředí Objednatele."
Rozsah scénářů není nijak omezen, proto je nutné předpokládat. že je
požadováno vytvořit testovací scénáře pro veškerou funkčnost jak v základních,
tak alternativních případech.
Z formulace požadavku vyplývá zodpovědnost Poskytovatele za kvalitu
testovacích scénářů. Vzhledem k tomu. že testovací scénáře nebude navrhovat
Objednatel (či Jim sjednaná třetí strana) vzniká riziko. že návrh testů bude
ovlivněn způsobem interpretace zadání realizačního týmu Poskytovatele.
Znalec odhaduje dopad na riziko implementace v rozsahu až 5%.

Omezená flexibilita součinnosti
V podkladu 13.3. 00-Doplneni-20191127 - Doplnění požadavků SFDI v kapitole

8.3 Součinnost se uvádí:
•SFDI poskytne Řešiteli pro každou etapu dodávky součinnost v maximálním
rozsahu dle přílohy 13.5.
Vzhledem k časovým možnostem odborných pracovníků SFDI musí Řešitel
vyžádat součinnost minimálně 5 pracovních dní předem. Požadavek na
poskytnutí součinnosti musí obsahovat konkrétní předmět požadavku a termfn.
Poskytnutí součinnosti v požadovaném termínu bude ze strany SFDI potvrzeno
do 3 pracovních dnů. nebo bude navržen Jiný nejbližší možný termín."
Znalec odhaduje dopad na riziko implementace v rozsahu až 5 %.
2.4.2. Souhrn rizik implementace
Faktor Dopad
Standardní riziko 30%
Deklarovaná volnost zadáni až10%
Harmonogram až 10 %
Kompetence Dodavatele za testy I až s%

Omezená flexibilita součinnosti I až s%
Celkové rlziko implementace je znalcem stanoveno v rozsahu 30 - 60 %, to Je
zohledněno ve výpočtu v kapitole 2.8.1. A Vytvoření Díla - IS EDAZ

2.5. Kategorizace rolí a cena za MD
2.5.1. Pfehled rolí
Následující tabulka obsahuje role definované v dokumentaci rozšířené o další
standardní projektové role,
Pro zjednodušení stanovení ceny obvyklé jsou role rozděleny do tří kategorlf:
• Senior:
• Standard
• Junior.
Role Poěet z toho s 09Vědčemm Kategorie r.oie

N8Ú swpRě .o- nebo
VYŠŠI
Role vyjmenované v dokumentaci
Projektový vedoud 1 1 Senior

Architekt informačních systémů 2 1 Senior
Integrační architekt zkušenosti WS - 2 1 Senior
SOAP, REST
Bezpečnostní architekt 1 1 Senior
Analytik pro oblast Finance+ 1 o Senior
Ekonomie
Analytik pro oblast Portálová řešení 1 o Standard
Analytik pro správu uživatelů 1 1 Standard
UIP/KAAS, N!A.J
Databázovv soeciaUsta 1 1 Senior
Vedoucí testování a školení 1 o Senior
Vedoucí podpory IS 1 o Senior
Vedoucí provozu !S 1 1 Senior
Ostatní standardní role
Analytik Uunior) Junior

V~ojář Standard
Tester Junior
Dokumentarista Junior

2.5.2. Určení ceny pro Jednotlivé kategorie roU
Jako zdroj pro určení sazeb byl použit podklad 13.22. Prehled_cen_lCT_pracl_
201905, dále ,Přehled cen"
Vzhledem k tomu, že tento podklad analyzuje smluvní ceny rolí, tak tyto cenyJiž
obsahují obchodní zisk Poskytovatele, proto se zisk nevyskytuje ve výpočtech
cen.
Junior Uunior analytik. Tester, Dokumentarista, Administrátor infrastruktura)
V Přehledu cen vycházíme z typu práce ,analytik" (medián 10.400,-l. relevantní
štítek (viz str. 6 Přehledu cen)Jejunlor - medián 8.000,-
Druhý relevantní typ práceje .tsster' (medián 7.912,-).
Třeli relevantní typ práce Je .Admlntstrátor", relevantní štítky (viz str. 5 Přehledu
cen)jsou Infrastruktura (medián 8.000,-, horní kvartil 10.000,- ), server (medián
8.000,-.horní kvartil 10.000,-) a hardware (medián 9.520,-,horní kvartil 12.000.-).
Na základě těchto údajů bylo stanoveno rozpěU ceny za MD pro roU kategorii
Junior na 7.000 - 9.000 Kč.
Standard (Analytik, Vývojář, Podpora - provoz platformy)
V Přehledu cen vycházíme z typu práce .analytik" (medián 10.400,-), relevantní
štítky (viz str. 6 Přehledu cen) Jsou senior (medián 12.288,-l a software (medián
12.000,-),
Druhý relevantní typ práce je ,programátor" (medián 9.600.-). podrobnější
rozklad dle štítků neposkytuje vodítko pro přesnější specifikaci sazby. Vzhledem
k tomu. že se Jedná z větší části o specifickou implementaci. přikláníme se k
sazbě dle horního kvartilu - 11.940,-.

Třetí relevantní typ práce je ,podpora", relevantní štítky (viz str.to Přehledu cen)
jsou data (medián 11200,-, horní kvartil 13.600,-) a server (medián 11200,-, horní
kvartil 13.600,-).
Na základě těchto údajů bylo stanoveno rozpětí ceny za MD pro roll kategorii
Standard na 11.000 - 13.000 Kč.
Senior (Projektový vedoucí, Architekt - SW I HW, Integrační, bezpečnostní,
Databázový administrátor, Vedoucí testování, Vedoucí provozu a podpory)
Přehled cen pro senlorní role obsahuje poměmě málo podkladů. navíc je nutné
zohlednit požadavek na bezpečnostní prověrku vybraných roU, tento

.doplňkový" požadavek cenu ovllvňule,
V Přehledu cen vycházime z typu práce ,architekt" (medián 11920,-), relevantní
štítek (viz str. 7 Přehledu cen) je senior (medián 14.500,-) .
Druhý relevantní typ práce Je .vedoucí projektu" (medián 12.000.-), podrobnější
rozklad dle štítků neposkytuje vodítko pro přesnější specifikaci sazby.
Střední hodnota těchto dvou sazeb Je 13.250.-. Požadavek na bezpečnostní
prověrku významné části senlorních rolí zohledňl.tjeme navýšením sazby o 15 %.
Výsledný střed sazby je 15.200,-.
Na základě těchto údajÍI bylo stanoveno rozpěti ceny za MD pro roll kategorii
Senior na 14.200 - 16.200 Kč.

2.5.3, Přehled a průměrná sazba
Tabulka níže obsahuje přehled kategorií roll a výpočet průměrné sazby na
základě předpokládaného zastoupení rolí projektových činností,
Kategerle Cenai/MDod Cena/MO do .5tted Zastou pen{

Senior 14.200 16.200 15.200 40"/4
- -
Standard 11.000 13,000 12.000 40%
--
Junior 7.000 9,000 8.000 20%
Prťlměrná RZba 11.480 13.480 12.48-0
Uvedené sazby Jsou použity pro výpočet částí ceny A Vytvoření Díla - IS EDAZ,
8. Provoz IS EDAZ a E. Rozvoj, konzultace a další služby.
2.6. Popis technického řešeni
Na základě obdržených informací znalec vytvořil zjednodušenou hypotetickou
dekompozici EDAZ. Jejímž účelem je určení ceny obvyklé. Tato dekompozice
není míněna jako návrh skutečného fešení a nemůže tak být chápána.
Dekompozice pro tento účel není .architektonicky čistá". záměrně nerespektuje
přesně rozdělení implementace do vrstev. V případech, kdy Je logika střední
vrstvy sdílena více komponentami nejvyšší vrstvy (např. Zápis do evidence), je
uváděna samostatně.Jinak ne.
Dále jsou v samostatné podkapitole klasifikoványJednotlivé funkční požadavky.
Výsledek z této klasifikaceje pak klíčovým vstupem pro určení ceny za vytvoření
díla.
2.6.1. Logické moduly a komponenty
Na základě posouzení funkčních požadavků byla výhradně pro účely určení
provedena dekompozice do logických modulů komponent V mnoha případech

je tato dekompozice podobná struktuře požadavků, ale v některých případech
se významně liší.
Významné příklady:
• Dekompozice pro nacenění nerozUš4]e Portál a eShop a naopak odUšuje
Základ webové apLikace, Externí funkce eShopu a Interní funkce eShopu;
• Notifikace - tato komponenta není v původni struktuře identifikována, její
vyčíeněnrurnožňuje přesnější nacenění.
Clearing
• Jáciro
• Párováni plateb
• Párování plateb na proforma fakturu
• Vypořádání Dodavatel
• Vypořádání eShop
■ Zajištění dodavatel
Enforcement
• Integrace brány
• Integrace PČR/CS
• Kontrola vozidel
eShop (backoffice)
• Interní správa uživatelů
• Platební brána
• Správa externích uživatelů
• Správa organizací
• Správa SPZ

eShop (externí část)
• Anonymní přístup
• Evidence obchodů
• Nákup
• Notifikace
• Osvobození
• Platební brána
• Profil
• Souvisej Id služby
• Správa externích uživatelů
• Správa SPZ
Evidence
• Integrace RSV
• Poskytování Informací
• Zápis
Osvobození
• Evidence
Společné
• Integrace
• MDM
• Notifikace
• Statistiky
• Základ webu
• ePodatelna

• eVýpravna
2.6.2. Klasifikace požadavků
Základem pro určeni ceny obvyklé je posouzení a klasifikace funkčních
požadavků do skupin dle Implementační složitosti, ta Je provedena v této
kapitole.
Legenda
Sleupe.c Popis
OblasVPodoblast Horní řádek Kapitola druhé a třetí úrovně v dokumentu
MoctuVKomponenta funkčních požadavků (podklad 13.2 Srnlouva-PrilohaL část
1 Základní požadavky- IS EDAZ)
Spodní řádek Modul a Komponenta dle logického rozčleněni
v předcházejícf kapitole.
Kód-Název První řádek Kód a název požadavku z dokumentu funkčních
Poznámka požadavků.
Integrace
Druhý řádek Poznámka znalce upřesňující význam
požadavku (nepovinné).
Třetí řádek Znalcem odvozený seznam jiných modulů
(případně komponent} a/nebo externích systémů se kterými
funkčnost komunikuje (nepovinné, v případě vyplnění začiná
řádek textem .Integrace:')

Popis
Typ-Rozs.-Bezp. Údaje odvozen e znalcem
Typ požadavku
• F - Funkční
• U - Usability - požadavek na použltelnost
Rozsah
1 Rozsah implementace 2 MD - Jednoduchý formulář,
zobrazení seznamu dat.jednoduchá aktlvní funkčnost
a podobně.
2. Rozsah implementace 5 MO- Složitější funkčnost

s více variantami chováni, integrace na jiné moduly
Příklad ESH - 26 Úhrada proforma fakturou.jehož
součástí je komunikace s Clearingem.
3, Rozsah implementace 15 MD - Rozsáhlý a/nebo ne
zcela zřejmý požadavek Např. POR - 4 Notifikace,
zde se za požadavkem skrývá vybudování celého
notitikačního mechanismu.
4. IND - rozsah stanov en individuálně- viz konkrétní

požadavky.
Bezpečnost
O. Požadavek nemá bezpečnostní aspekt, který by
zvyšoval rozsah implementace.
1 Nižšř bezpečnostnf aspekt navyšující rozsah
implementace o 10 %. Např. POR - 10 Zrušení
registrace správcem portálu. Vyžaduje definici
podmínek, za jakých okolnostije možné takovou akci

------ ---------------
Sloupec Popis
provést a způsobu jak bude zaznamenána a
notifikována.
2. Střední bezpečnostní aspekt navyšuje! rozsah
implementace o 20 %, Např. POR - 5 Spojeni profilů,
účtů. Nutné řádně ošetřit legitimitu takového kroku.
3. Vyšší bezpečnostní aspekt navyš4líd rozsah
implementace o 30 %. Použito pouze pro POR -1
Registrace zákazníka - externl uživatel kde je nutné
řešit integraci s autentizačními autoritami.
Stanoveni MD Odvozeno z Rozsahu a Bezpečnostního aspektu.
Na konci seznamu jsou přidány požadavky v oblasti .ePodatelna a eVýpravna·
odvozené znalcem na základě Informací z podkladů 13.3. 00-Doplnenl-
20191127 - Doplnění požadavků SFDI, kapitola 9.1 Přuem a vypravení dokumentů
a 13.11. 03.1-ePodatelna_a_vypravna.
Kód-Nálev I
I:,.
Oblastn odobl:aat I Typ- stan.
MecluVKempo,wnta l'omámka
Integrace MO
Portál/Správa Profilu POR -1- Registrace zákazníka F-2-3 6,5

eShop (externí část)/Správa externích - externí uživatel
uživatelů Samoobslužná správa
extemich uživatelů: využití
Identit 3. stran
Portál/Správa Profilu POR - 2 - Souhlas se F-1-1 2,2
eShop (externí část)/Správa externích zpracováním osobních údajů
uživatelů Potvrzení+ tlsk potvrzení:
~
Portál/Správa Profilu
podmlnka vytvoření profilu
--
POR - 3/1 - Práce s profilem
-F-2-0 5,0
eShop (externí části/Prořlí Správa údajů profilu, včetně
nastavení notifikací
lntecrace: Notifikace

Oblaat/Podobhlst
- --
I Kód - Nél!ev -- -
Ty.p- stan.
ModuUKo,nponenta POZl'lémka Rozs, MO
ln~ ce ~Bazp.
-~ - - ---
-- --
F-1-0 2,0
eShop (externí částl/Profll Zobrazení historie obchodů,
I
I
Integrace: Evidence
eShop (externí část)/Profil
Správa SPZ. ověřování v RSV
I F-2-0 5,0
Integrace: Evidence, RSV

Portál/Správa Profilu POR - 4 - Notifikace F-3-2 18,0
eShop (exteml částl/Notiflkace Podpora notifikací: pfedpoklad
kolem 20 typů notifikaci
(podpora i zavedeno
~race: Notifikace I
Portál/Správa Profilu POR - 5 - Spojení profilů, účtů I F-3-2 18,0
eShop (externí část)/Správa externích KompUkované dopady buď do
uživatelů apUkačnf logiky (pokud by se
účty spojovaly Jen virtuálně)
nebo do historie evidence
(pokud by změna proběhla v
datech). I
lnteorace: Evk::lence
Portál/Správa Profilu POR - 6 - Převod úhrad do F-2-1 5,5
eShop (externí část)/Evidence obchodů jiného účtu, kjiné identitě
Dle zadání by v systému
neměly vznikat úhrady bez
jednoznačného vztahu k
obchodu. Buď seJedná o
dupUcltu s pf'edchozfm bodem,
nebo se za požadavkem skrývá
další funkčnost
Integrace: Evidence
Portál/Správa Profilu POR - 7 - Pflřazení předchozí F-2-2 6,0
Clearing/Párování plateb úhrady (bez autentizace) k
účtu, Identitě uživatele
Nejednoznačný požadavek
podle popisu směřttjící do
..-- clearlnou
Portál/Správa Profilu POR - 8 - Zrušení registrace F-1-0 2,0
eShop (externí éást)/Správa externích zákazníkem - extemf uživatel
uživatelů
Portál/Správa Profilu POR - 9 - Přihlášení/Odhlášení F- 0,0
eShop (externí část)/Správa externích do Portálu - externí uživatel N/A-0
uživatelů zahrnuto v POR - 1
Portál/Správa Profilu POR -10 - Zrušení registrace F-1-1 2,2
eShop (backoffice)/Správa externích správcem Portálu
uživatelů I

st Kód-Název Typ- stan.
iffl8 Po:známk21 Rozs. MD
1 Jnteg race
-BEgp.
vatelůeShop (externí
-
POR - 11 - Použití Portálu bez
~
F-1-1 22
část)/Anonymní přístup přihlášení - externí užlvate\Zde
Jen umožnění anonymních
funkčnosti Konkrétní funkce
(Informace., úhrada, formuláře)
-Portál/Správa uživatelů
eShop (backoffice)/lnterní správa uživatelů
samostatné oožadavk_y. _
POR -12 -
Přihlášení/Odhlášení do
-
F-1-2
-
2.4
Portálu ....: Interní uživatel/

úředník
-
Portál/Správa uživatelů POR -13 - Přístupnost webu U- o.o
eShop (externí část)/N/A Požadavek na použitelnost , N/A-
zohledněno v odhadech N/A
funkčních cožadavkú
Portál/Správa uživatelů POR - 14 - Uživatelské rozhraní F- o.o
Společné/Základ webu Externí anonymní a N/A-
registrovaná část, backoffice N/A
aplikace+ systém rolí - je
zohledněno v jiných
požadavcích
také POR - 57
I
----t
Portál/Správa uživatelů POR - 15 - Správa uživatelů F-1-1 2.2
eShop (backoffice)/lntemí správa uživatelů Interní uživatelé+ externí
Portál/Správa uživatelů
uživatelé - kUentl
POR -16 - Správa organizaci F-2-0
L- 5,0
eShoo {backofflce)/Správa organizaci
Portál/Správa uživatelů POR -17 - Skupiny uživatelů F-1-1 I 2,2
eShop Cbackofficel/lnterní správa uživatelů
Portál/Správa uživatelů POR -18 - Správa apUkačnlch F-2-1 5,5
eShop (backoffice)/lntemf správa uživatelů roli a oprávnění
Portál/Správa uživatelů POR - 19 - Oddělení pravomoci F-1-1 2,2
eShop (backoffice)/lntemi správa uživatelů Umožnění definice kolize rolí
Portál./Práce s formuláfl POR - 20 - Vytvofení a správa F-3-0 15,0
Společné/Základ webu formulářů
Portál/Práce s formuláfl POR - 2Vl - Avfzo o změně F-2-1 5.5
eShop (externí část}/Správa SPZ SPZ
Varianty česká a zahraniční
SPZ
lntearace: Evidence
Portál./Práce s formuláři POR - 2V2 - Avizo o změně F- o.o
eShop (backoffice)/Správa SPZ SPZ N/A-O
Varianty česká a zahraniční
SPZ 0mplementace v rámci
POR-2VD
lnteorace: Evidence -
- ~

ObLast/ Pocloblast Kód-Há»v Typ
Mod uV Kom s,one nta Poznámka R ozs,
;Jezp.
--
áři -IND-
f )svobození
Portál/Práce s formuláři POR - 23 - Ukládáni - lf-1-2 2.4

eShop (externí části/Osvobození rozpracovaného oznámeni na
lokální PC. J
Serializace a deserlallzace dat
- Portál/Práce s formuláfl
eShop (externí částl/Osvobození
formuláře do souboru na PC
POR - 24 - Splnění náležitosti
oznámeni
I
F-2-0 5.0
Vyhodnocení úplnosti zadání

lnteurace: Osvobození
I
Portál/Práce s formulář! POR - 25 - Načítání základních F-2-0 5,0
eShop (externí částl/Profll Informací
Použití Informací z profilů a
předchozích obchodů pro další I
činnost
Portál/Práce s formulářlSpolečné/Základ POR - 26 - Zadávání F-2-0 5,0
webu adresKontrola adres ČR proti
RUIANlntegrace: EXT: RUIAN
Portál/Práce s formuláři POR - 27 - Kontrola správnosti U-
I
o.o
Společné/Základ webu a úplnosti úclaJj formuláře N/A-
Požadavek na použitelnost N/A
Obecný popis vyplňování a
valldace požadavků,
zohledněno ve funkčních
- oožadavcfch
Portál/Práce s formuláfi POR - 28 - Storno oznámení F-1-1 22
eShop (externí části/Osvobozeni
Integrace: Osvobození ,._...
Portál/Práce s formuláři POR - 29 - Podání oznámení F-2-1 5,5
eShop (exteml část)/Osvobozenl Zřejmě podání oznámení ve
strukturované podobě - ISDS,
emalL elektronický podpis+
vygenerování dokumentu
Integrace: ePodatelna,
eVýpravna, Osvobození
-
Portál/Práce s formuláři
- - POR - 30 - Převzetí odpovědi F-2-1
-- 5,5
eShop (externí části/Osvobození na podané oznámení
Integrace: Osvobození,
Notifikace I

[=v-.-,
Modul/Komponenta
-~ ~
Kód Nálev
Poznámka
lntegtase
----~----- -,Tyf>-
Roz.s.
~BEliZI).
I MD
staFL
Portál/Práce s formuláři POR - 31- Evidence F-1-0 2,0

eShop (externí část)/Osvobozeni odeslaných oznámení
lnta.race: Osvobození
--
Portál/Práce s formuláři POR - 32 - Tisk F-1-0 2,0
eShop (externí část)/Osvobození
Portál/Práce s formuláři POR - 33/1 - Generováni F-1-0 2,0
aShop (externí část)/Osvobození předtisků formulářů
-
Portál/Práce s formuláři POR - 33/2 - Generováni F-1-0 2,0
eShop (externí část)/Správa SPZ předtisků formulářů
-
Portál/Správa obsahu POR - 34 - Správa obsahu F-3-1 16,5
Společné/Základ webu 'redakčn!_systém'
Portál/Správa obsahu
- POR- 35 -Volba jazykové
- F-2-0 5,0
Společné/Základ webu
mutace
POR - 36 - Navigační menu -F-2-0 5,0
POR - 37 - Custom atributy I F-2-0 5,0
Portál/Správa obsahu POR - 38 - Worl<flow F-3--0 15,0

- ._ ---k2-o-
-
Portál/Správa obsahu POR - 39 - PubUkace 5,0
Portál/Správa obsahu POR - 40 - Web obsah I F-2-0 5,0
Společné/Ztiklad webu
Portc\l/Správa obsahu POR - 41 - Blogy F-2-0 5,0
---- POR - 42 - Dokumenty a F-2-0
-
5,0
Společné/Základ webu media
Portc\l/Správa obsahu POR - 43 - Ůložlště F-2-0 5,0
Společné/Základ webu dokumentů a medii
Portál/Správa obsahUSpolečné/Notlfikace POR - 44 - Zasíláni F-3--0 15,0
zprávNotifikaceje nutné řešit
jako samostatnou komponentu
( mimo rámec portálu)
Portál/Správa obsahu POR - 45 - Ankety F-2--0 5,0
Soolečné/Základ webu
-
Portál/Správa obsahu POR - 46 - WIid F-2--0 5,0
·-
Portál/Správa obsahu POR- 47 -Vyhledávání F-2-0 5,0
Portál/Správa obsahu POR- 48 - Znalostní databáze F-2--0 5,0
Portál/Správa Web site POR - 49 - Správa Web site F-2--0 5,0
- -

~
--
Obtut/Pociloli,lest
Modul/Kompotlenta
~
L~- -
JKód-~
Pornámka
lmagrace
--
-- -
- r::1-~ Roza.
-Beep,
MD
-
PortáVSpráva Web slte
POR - 50 - Správa šablon F-2-0 I 5,0
--'---
PortáVSpráva Web site POR - 51 - Správa stránek F-2-0 5,0
PortáVSpráva Web slte POR - 52 Kolekce
-- F-2-0 5,0
Společné/Základ webu I
- -
PortáVSpráva Web site POR - 53 - Kategorizace I F-2-0 5,0
Společné/Základ webu obsahu
PortáVSpráva Web site POR - 54 - Správa statlckých
<
o.o
Společné/Základ webu stránek -
Zahrnuto POR - 51 ~ A
Portál/Správa Web slte
POR - 55 -Analytické nástroje F-2-0 I 5,0
Portál/Prezentace dat POR - 56 - WEB prohlížeče U- o.o

Společné/Základ webu Požadavek na použitelnost N/A-
Požadavek na použiti IE bude N/A
zohledněn v nákladech
Jednotlivých funkčností.
Portál/Prezentace dat POR - 57 - Veřejná a nevei'ejná F- o.o
Společné/Základ webu část N/A-
Také POR -14, odhad v N/A
lednotliwch částech webu
Portál/Prezentace dat POR - 58 - Geografické F-2-2 6,0
Společné/Integrace zobrazení vybraných údajů
Integrace RUIAN. Zobrazování
těchto údajů ve formě
geografického zobrazení
(kartogramu) realizovaného
pomocí dílčího portálu
OpenData.
lnteorace: RUIAN
PortáVPrezentace dat POR - 59 - PubUkovánl statistik F-2-0 5,0
- --
Portál/Prezentace dat POR - 60 - PubUkování F- o.o
Společné/Základ webu dokumentů, sestav a reportů N/A-
zahmuto v POR - 59 N/A
Portál/Prezentace dat POR - 61 - Životní situace a F- 0,0
Společné/Základ webu úřední postupy N/A-
'redakční svstém' viz POR - 34 N/A
Portál/Prezentace dat POR - 62 - Zobrazováni F- 0,0
Společné/Základ webu relevantních dat N/A-
zohledněno v systému N/A
apUkačnfch roli
PortáVPrezentace dat POR - 63 - Polltlky hesel F-1-2 2.4

Kód-Název Typ.- I Stan.
Poznámka ROZ5. jMD
Portá l/Pre ze ntace da tspolečn é/Z áklad

,~~-
POR - 64 - Monitoring aktivit
I
f~---4 ----
2.4
w e bu uživatelů
I--
Portál/Návazné agendy POR - 65 - Návazné agendy N/A 0,0
Společné/Základ webu Použití portálu jako základu pro N/A
Implementaci jednotlivých N/A
agend. Nejedná se o
lmr,lementačnf 1)ožadavek
Portál/Návazné agendy POR - 66 - Reporting a F-2-0 5,0
Společné/Základ webu Statistiky
APi pro data portálu pro
statistiky - tedy uživatelé, role
a pod,0lná data portál
nevlastni)
f-- ---+-- --1- --
eShop/Přístup k eShopu ESH -1- Přihlášení F o.o
eShop (externí části/Správa externích eShop je vytvořen nad N/A
uživatelů portálem. sdlU s ním společné N/A
části, funkčnosti portálu
nebudou duplikovány.
Duplicita s POR - 1
eShop/Přístup k eShopu ESH - 2 - Odhlášeni F 0,0
eShop (externí částí/Správa externích eShop Je vytvořen nad N/A
uživatelů portálem, sdílí s nm společné N/A
části, funkčnosti portálu
Dupllclta s POR - 1
eShop/Přístup k eShopu ESH - 3 -Anonymní zákazník F 0,0
eShop (externí část)/Správa externích eShopje vytvoFen nad N/A
uživatelů portálem, sdílí s ním společné N/A
části, funkčnost] portálu
Duplicita s POR - 11
Anon_yrnní nákup
eShop/Přlstup k eShopu ESH - 4 - Pffstup U- o.o
Společné/Základ webu prostřednlcMm moblnlho N/A-
zařlzení N/A
Požadavek na použitelnost,
Bude zohledněno v odhadu
I ljednoillvých funkčností I I _
eShop/Úhrada časového poplatku ESH - 5 - Úhrada časového F-2-0 5,0
eShop (extem i část)/Nákup poplatku
Výběr produktu a vyplnění
údajů. Komponenta úhrady
není součástí. Anonymní i
registrovaný zákamik.
Transakční zápis do evidence a
clearing. ___._ __

Oblast/Podoblast Kód-Název Sten.
ModuVKomponenta Pclznámka MO
l~
·-l ~--·
Integrace: Evidence, Clearing,
Platební brána
---- --
eShop/Úhrada časového poplatku ESH - 6 - Zobrazení seznamu F-1-0 I 2,0
eShop (externí částl/Nákup typů časových poplatků, které
lze uhradit I
Obdoba seznamu produktů. I
eShop/Úhrada časového poplatku ffi1 - 7 - Ověfenf časového F-1-2 I 2.4
eShop (externí část)/Souvisejk:í služby poplatku pro kód země a SPZ
ověřeni existence záznamu v
evidenci
lnte_g__race: Evidence
eShop/Úhrada časového poplatku ESH - 8 - Zobrazeni detailu I F-1-0 2,0
eShop (externí částl/Nákup objednávky- úhrady časového
poplatku
eShop/Úhrada časového poplatku ESH - 9 - Zobrazení a I F-2-0 5,0
eShop (externí část)/Nákup manipulace s obsahem
nákupnlho košíku
Nahráni položek objednávky ze
souboru, editace položek
objednávky: SPZ. typy
poplatků, počátek platnosti
eShop/Úhrada časového poplatku ESH -10 - Vymazání košíku F-1-0 2,0
eSh<JP (externí částl/Nákup_
eShop/Úhrada časového poplatkueShop ESH -11 - Kontrola obsahu F-2-0 5,0
(externí část)/Nákup košíku na dupíicitni úhrady
(časové překryvy) a zobrazení
výsledku kontroly a kontrola na
exlstencl SPZlntegrace: RSV
eShop/Úhrada časového poplatku ESH - 12 - Exprace nákupu F-1-0 2,0
eShop (externí částl/Nákup během platby - tlme out
platební metody
Integrace: Platební brána

eShop/Úhrada časového poplatku ESH - 13 - Vypořádání úhrady F-2-0 5,0
eShop (extem f částl/Nákup při problému s platbou
Integrace: Platební brána,

Clearing
eShop/Úhrada časového poplatku ESH -14- Zobrazení F-1-0 2,0
eShop (externí částl/Nákup obchodních podmínek
Statická stránka, Implementace
zejména umístěnt odkazu na
I 1vhoooýmmf~och _

,- --
Oblasl/Podoblut Kód- Název Typ- stan.
Mooul/Kompon enta Peznámka Ro2:s. MD
I~ -Bazp.
eShop/Úhrada časového poplatku ESH -15 - Platební metody F-2-2 6,0
eShop (externí částl/Nákup Obecný mechanismus úhrady
a následného zapsáni do
evidence. JednoWvé metody
viz ESH - 26 a ESH - 31
eShop/Úhrada časového poplatku ESH - 16 - Zobrazeni seznamu I F-2-0 5,0
eShop (externí část)/Nákup potvrzení k aktuálně, nebo v
budoucnu píatným časovým
poplatkům
Integrace: Evidence
eShop/Úhrada časového poplatku ESH -17 - Zobrazení detailu F-1-0I 2,0
eShop (extem f část)/Nákup potvrzeni - přlhlášený zákazník
Integrace: Evidence
eShop/Úhrada časového poplatku ESH -18 - Zobrazení detailu I F-1-0 2,0
eShop (externí částí/Nákup potvrzení - anonym ni zákaznlk
Integrace: Evidence
eShop/Úhrada časového poplatku ESH -19 - Distribuce dokladu F-1-0 2,0
eShop (externí částl/Nákup potvrzuJfcf úhradu časového
poplatku
lnte_grace: Evidence
eShop/LR-lrada časového poplatku ESH - 20 - Kontrola Limitu na F-1-0 2,0
eShop (externí část)/Nákup počet. celkovou cenu
zakoupených položek v rámci
Jednoho nákupu (obchodnfho
případu)
r- ,
eShop/Uhrada časového poplatku ESH - 21 - Zopakování nákupu F-1-0 2,0
eShop {externí část)/Nákup (obchodniho případu)
export a Import položek
t---
objednávky
eShop/Úhrada časového poplatku ESH - 22 - Zrněna SPZ u 2,0
eShop(externfčást)/Nákup uhrazeného časového
poplatku před datem platnosti
Integrace: Evidence
eShop/Úh rada časového poplatkueShop ESH - 23 - Posun platnost] 1 F-1-0 2,0
(externí část>/Nákup uhrazeného časového
poplatkulntegrace: Evidence I
eShop/Ůhrada časového poplatku ESH - 24 - Změna typu F o.o
eShop (externí část>/Nákup časového poplatku N/A
....._ ______ Negativní požadavek -nelze N/A

-
Obla.st/Podoblalt
MGdw' Komp<me ma
- -- - -
Kód- Ná7.ev
Poznámka
- -
l Ty;p-
Rozs.
-
Stan.
I
MD
-BQp .
- -- -- . -
- - ~ -
změnit typ již uhrazeného

poplatku
eShop/Úhrada časového poplatku

eShop (externí část)/Nákup
----
ESH - 25 - Hromadná úhrada
Možnost nákupu pro více SPZ
F-
N/A-
--L o:0
a typů poplatků. Zahrnuto v N/A
ESH -9
- ESH - 26 - Úhrada proforma F-2-0 5,0
eShop !extem í části/Nákup fakturou
Zálohová faktura. Viz také ESH
-15
lnteqrace: Clearino ~ - ,._ -
eShop/Úhrada časového poplatku ESH - 27 - Zobrazeni proforma F-1-0 20
eShop (externí částí/Nákup faktury
eShop/Úhrada časového poplatku ESH - 28 - Faktura po F-2-2 6,0
Clearing/Párování plateb na proforma zaplaceni proforma faktury
fakturu Vygenerováni, odesláni
notifikace, Informace do
eShopu
lnteqrace: eShoo, Notifikace
I
eShop/Úhrada časového poplatku ESH - 29 - Storno expirované F-2-2 6,0
Clearing/Párování plateb na proforma objednávky <v terminu
fakturu neuhrazená proforma faktura)
Integrace: eShop, Notifikace

eShop/Úhrada časového poplatku ESH - 30 - Storno objednávky F-1-0 2,0
eShop(extemíčásU/Nákup zákazníkem, před uhrazením
proforma faktury
Integrace: Clearina
eShop/Úhrada časového poplatku ESH - 31- Platba kartou on-Line F-2-2 B.O
eShop (externí část)/Platebni brána Viz také ESH -15
I
eShop/Úhrada časového poplatku ESH - 32 - Evidence nákupů F-2-0 5,0
eShop (externí částí/Nákup (obchodnlch přfpadůl
Včetně vazby na mechanismy
úhrad a stav úhradv
eShop/Úhrada časového poplatku ESH - 33 - Výpis platebních F-2-1 5,5
eShop (backofflce}/Platební brána transakci
Evidence transakci
provedených platebnl branou

- lnteorace: Platební brána
ESH - 34- Žurnál výpisů F-2-1 5,5
eShop (backoffice}/Platebnf brána platebních transakcí

- ~ --- - -- -~- - -- -
Oblast./Podoblut Kód- Niuev Typ- Stan.
MGduVKomponenta
- ---
-
Poznámka
Jntegmce
- c--
ESH - 35 - Protokol výpisu
j"""''
-Beq). MD
F-1-1 f 2.2
eShop (backoffice)/Platebni brána
I
_0tegrace: Platebn i brána
- ESH - 36 - Zpracování výplsu F-1-1 2,2
eShop Cbackofflcel/Platebn í brána
I

--
ESH - 37 - Rozpory výpisů
--· - F-2-1 5,5
eShop (backofflce)/Platebn i brána
--
eShop/Úhrada časového poplatku ESH - 38 - Rozporné F-3-1 16.5
eShop (backoffice)/Platební brána položkyVčetně procesu
nápravy a evidence Informací o
vyřešení Integrace: Platební
brána
--
r---
ESH - 39 - Notifikace rozporů
--
F-2-1
-
5,5
eShop (backofflce}/Platební brána
eShop/Úhrada časového poplatku ESH - 40 - Evidence nákupů F- o.o
eShop (externí čásO/Nákup (obchodních přfpadů) NIA-
- ~ Zahrnuto v ESH - 32 N/A
eShop/Úhrada časového poplatku ESH - 41 - Uložení údajů F-1-0 2,0
eShop (externí část}/Nákup nákupu (obchodn iho případu)
Serializace dat objednávky (v
podobě zpracovatelné v
požadavku ESH - 9)
ESH - 42 - Nahrání údajů F-
-
0,0
eShop (exteml část)/Nákup nákupu (obchodního pll)adW N/A-
Zahrnuto v ESH - 9 N/A
eShop/Úhrada časového poplatku ESH - 43 - Generování nového F-1-0 2,0
eShop (externí částl/Nákup nákupu obchodního přpadu

Vytvoření nákupu z
předchozího
ESH - 44 - Seznam platných F-
I
I
o.o
eShop (externí část)/Nákup časových poplatků N/A- I
Zahrnuto v ESH - 16 N/A
eShop/Úhrada časového poplatku ESH - 45 - Zobrazení detailu F- o.o
eShop (externí část>/Nákup časového poplatku N/A-
Zahrnuto v ESH -17 a ESH -18 N/A
eShop/Úhrada časového poplatku ESH - 46 - Zobrazení seznamu F- o.o
eShop (externí část)/Nákup uhrazených časových poplatků N/A-
Zahrnutu v ESH - 32 N/A
eShop/Úhrada časového poplatku ESH - 47 - Reporting a F-2-1 5,5
eShop (externí část)/Nákup Statistiky
APi pro statistiky - tedy o
nákUPOCh
- - - -

--- --
Obwt./PodGblut ,Kód-Nlb:ev Typ- stan.
ModuVKomponenta Pornán:lka Ron. MD
~!.... -B81lp.
Clearing/Zpracování údajů od Dodavatele
--
CLR - 1- Evidence jednotlivých F-2-1
-
5,5
Clearing/Vypořádáni Dodavatel obchodních případů -
I pohledávky
Evid;nce nákupů u Dodavatele
ce:DS
-
Clearing/Zpracování údajů od Dodavatele - Vytvoření podkladů F-2-0 5,0
Clearing/Vypořádání Dodavatel pro výzvu k úhradě
Integrace: DS
Clearing/Zpracování údajů od Dodavatele CLR - 3 - Vytvoření podkladů F-2-0 5,0
Clearing/Vypořádáni Dodavatel pro fakturaci provize
Integrace: DS
-
Clearing/Zpracování údajů od Dodavatele CLR - 4 - Pfevzetf Informace o F-2-0 5,0
Clearing/Vypořádání Dodavatel vystavené faktuře a evidence
fakturace
SFDI - Dodavatel
I
Clearing/Zpracováni údajů od Dodavatele CLR - 5 - Zpracování výpisu z F-2--0 5,0
Clearing/Vypořádáni Dodavatel banky - účet Dodavatele
(sběrný b.ú. EDAZ)
Včetně párováni plateb
lntearace: Banka
Clearing/Zpracování údajů od Dodavatele CLR - 6 - Správa Zajištěni F-3--0 15,0
Clearing/Zajištění dodavatel (bankovní záruky a dalšlch
prostředků zajlštěn0
Kompletní funkčnost zajištění
I
Clearing/Zpracování údajů od CLR - 7 - Odeslání urgence k F-2--0 5.0
DodavateleClearlng/Vypořádánl Dodavatel doplacení faktury - neúplné
platbylntegrace: Notifikace
Clearing/Zpracování údajů od Dodavatele CLR - 8 -Vytvoi'ení F-2-0 5,0
Clearng/Vypořádán í Dodavatel ,Mimořádné výNý k úhradě"
Clearing/Zpracování údajů. od Dodavatele CLR - 9 - Podklad pro zadání F-1--0 2,0
Clearing/Vypořádán I Dodavatel vráceni platby (pfeplatku)
Clearlng/Zpracování údajů z eshop CLR - 10 - Evidence F-1-1 22

Clearing/Vypofádání aShop Jednotlivých obchodních
případů - pohledávky
Nižší složitost- společnéjádro
řešeníjako pro pohledávky
Dodavatele
Clearing/Zpracování údajů z eShop CLR - 11 - Zpracování výpisu z F-1--0 2.0
Clearing/Vypořádání eShop banky - provozní účet eShop
Nižší složitost - společné jádro
řešeníjako pro pohledávky
Dodavatele

-
Oblast/Podoblast tcód- Název Typ- Stan.
Modul/Kompo11181'1ta Peznámka Rozs. MD
Integrace -Bezp.
-
Clearing/Zpracování údajů z eShop
- . ----- ...
CLR -12 -Zpracováni
-- F-2-0 5,0
Clearing/Vyporádání eShop .zálohové faktury"
lnte, race: eShOI

-
Clearilg/Zpracování údajů z eShop CLR - 13 - Report o aktuálním F-1-0 2,0
Clearing/Vypořádáni eShop stavu Pohledávek za eShop
--
Clearing/Zpracování údajů z eShop
-- -
CLR - 14 - Náhled na report o
-
F-1-0
--
z.o
Clearing/Vypořádání eShop Jednotlivých kartových
transakcích
Clearing/Zpracování údajů z eShop CLR - 15 - Report o Zálohových F-1-0 2.0
Cleartng/VypořádáníeShop fakturách před splatností
Clearing/Zpracování společných aktivit CLR - 16 - Ruční párování F-3-2 18,0

Clearing/Párování plateb plateb
Clearing/Zpracování společných aktivit CLR - 17 - Report F-1-0 2.0
Clearing/Párování plateb nespárovaných plateb
Clearing/Zpracování společných aktMt CLR -18 - Platební příkaz pro F-2-2 6,0
Clearing/Párování plateb vráceni platby (celé nebo části)
Clearng/Zpracování společných aktMt CLR -19 - Upozorněni na F-1-0 2.0

Clearing/Párováni plateb neprovedené vrácení platby
Clearing/Zpracování společných aktivit CLR - 20 - Nastaveni - F-2-0
--
5,0
Clearing/Jádro parametrizace pro vypracování
souhrnů. - struktura účtování
Clearing/Zpracování společných aktivit CLR - 21 - Report o aktuálním F-2-0 5,0
Clearng/Jádro stavu Pohledávek a Závazků
Jako celku
--
·Clearing/Zpracování společných aktivit CLR - 22 - Zaúčtováni do F-2-0 5,0
Clearing/Jádro Hlavni knihy - předání dat do
SFDI / MIS
Clearing/Zpracování společných CLR - 23 - Přlfazení rolí F-2-0 5,0
aktivitClearing/Jádro uživatelů a integrace s interní
správu uživatelů EDAZ
Cleartng/Zpracování společných aktlvlt CLR - 24 - Náhled na aktuální F-2-0 5,0
Clearing/Jádro Saldo - Docfavatele I eShop ~
Clearing/Zpracován[ společných aktivit CLR - 25 - Definice období pro F-2-0 s.o
Clearing/Jádro jednotUvé souhrny
Clearing/Zpracováni společných aktivit CLR - 26 - vvtváření před- F-3-0 15,0
Clearing/Jádro definovaných reportů v
časovém i věcném rozUšení
(čas. typ poplatku, místo
úhradv, _)

- Kc.xt Ná5V JTyp-
-
Stan.
rOblasl/Podoblast
Modul/l<ompo,iema Pelnámha Ron. MO
J-
lmegrace 1-Bezp.
-
Rozsah reportů není
specifikován
-
Clearing/Zpracování společných aktivit ,_Cl.R - Zl - Vytvářenl ad- F-3-0 15,0
ClearlriglJádro reportů v časovém I věcném
rozlišení (čas, typ poplatku,
místo úhrady,_.) za zvolené
období
Reportlnq tool
Clearing/Zpracování společných aktivit CLR - 28 - Správa účtů - F-3-0 15.0
Clearng/Jádro číselník účtů
Včetně nastavení čfselniků
f--- -
Clearing/Zpracování společných aktivit CLR - 29 - Podklady pro F-2-1 5,5
Clearing/Jádro manuální zadání převodu z
účtu (sběrný b.ú. EDAZl
Clearing/Zpracování společných aktívlt CLR - 30 - Schválení a odeslání F-3-2 18,0
Clearing/Jádro příkazů do banky
Včetně shlukování do dávek,
schvalovacího worktl.ow a
svstému oddělení rolí
Clearing/Zpracování společných aktivit CLR - 31 - Reporting a F-2-2 6,0
Clearing/Jádro Statlstlky
-
AP1 pro statlstlky
Evidence uhrazených poplatků/Informace z EVI - 1 - Informace o SPZ I F-3-1 16,5
I Evidencí Kllčová funkčnost Provozně
Evidence/Poskytování Informací kritické.
Integrace: RSV, eShop,
Dodavatel Enforcament
Evidence uhrazenýdl poplatků/Informace z EV! - 2 - Údaje z RSV F-2-1 5,5
Evidenci Nejen dotaz do RSV, ale také
Evidence/Integrace RSV zohlednění výsledku v
evidencích EDAZ
I nteorace: RSV
Evidence uhrazených poplatků/Evidence EVI - 3 - Zápis do Evidence F-3-2 18,0
uhrazených časových poplatků uhrazených časových poplatků
Evidence/Zápis Klíčová funkčnost Provozně
kritické.
Integrace: eShop, Clearing_
·-
Evidence uhrazených poplatků/Evidence EVI - 4 - Aktualizace WL F-3-0 15,0
uhrazených časových poplatků Správa cache aktuálních dat
Evidence/Zápis evidence - klíčové pro
Enforcement
Evidence uhrazených poplatků/Evidence EVI - 5 - Výmaz z WL F- 0,0
uhrazených časových poplatků Zahrnuto v EVI - 4 N/A-
Evidence/Zápis N/A

Oblasl/Podoblast
Modul/Komponenta
--~-
[ Kód - Název
Pemémka
- ~ -- Typ-
Rozs .
I ""';. l
MD
-- lmegraca f-Bmp.
Evidence uhrazených poplatků/Evidence EVl - 6 - Posun data platnosti F-2-0 5,0
uhrazených časových poplatků již uhrazeného časového
Evidence/Zápis poplatku
I-
Evidence uhrazených poplatků/Evidence EVI - 7 - Změna SPZ u / F-2-0 I 5,0
uhrazených časových uhrazeného časového
poplatkůEvidence/Zápis poplatku před datemplatnostl
Evidence uhrazených poplatků/Evidence
uhrazených časových poplatků
Evidence/Zápis
EVI - 8 - Změna SPZ na
D
základě avíza z důvodu ztráty /
_odcizení/výměny
Zvláštní postup pro zahranlčnl
vozidla
lnte race: RSV
j F-3-0
I
15,0
Evidence uhrazených poplatků/Evidence EVI - 9 - Vyhledání, ověření F-3-2 18,0

uhrazených časových poplatků údajů u vozidla a případná
Evidence/Zápis oprava údajů
Komplexní funkčnost
manuálrnho zásahu do
evidence.
Integrace: RSV
-
Evidence uhrazených poplatků/Evidence EVI -10 - Reporting a Statistiky I F-2-2 I 5,0
uhrazených časových poplatků APi pro reporting I
Evidence/Zápis I -
Kontrola a statlstlky/Mobllní enforcement KON -1- Informace o F.-3-il 16,5
Enforcement/Kontrola vozidel Identifikované SPZ - mobilní
enforcement
Výkonnostně kritická I
funkčnost.
Integrace: Evidence, VZ
I
Kontrola a statistiky/Mobilní enforcement
Enforcement/Kontrola vozidel
I KON - 2 - Údaje z RSV
Výkonnostně kritická
F-3-1 I 16,5
funkčnost
Kontrola a statistiky/Mobilní enforcement I

Integrace: RSV. Evidence
KON - 3 - Údaje ze systému
I F-3-1 I 16,5
Enforcement/Kontrola vozidel výkonového zpoplatněni NZJ
Výkonnostně kritická
funkčnost. I
lnte race: VZ
Kontrola a statistiky/Mobilní enforcement KON - 4 - Informace o I F-2-1 I 5,5
Enforcement/Kontrola vozidel výsledku kontroly vozidla
Zápis výsledku kontrol do
evidenci.
--
Kontrola a statistiky/Data ze statlckých bran KON - 5 - Informace o stavu lF-2-1 I 5,5
Enforcement/lntegrace brány statických bran
._ ___ -- ---- - Integrace: Statická brán_r_

Obtast/Podobles t K.ód -Nállev
-- ----- T)IF)- Stan.
Modul/KOll'lpon&Ria Pomá f'Aka Rozs. MD
t- -- ln~e __ -~
Kontrola a statistiky/Data ze statických bran KON - 6 - Pří]em dat ze F-3-1 16,5
Enforcement/lntegrace brány statických bran
lnteurace: Statické brán 1

Kontrola a statistiky/Data ze statických bran KON - 7 - Přihlášení k odběru F-2-1
I 5.5
EnforcemenVlntegrace PČR/CS dat z vybraných statických
bran
lntearace: PČR/GS
Kontrola a statistiky/Data ze statických bran KON - 8 - Odhlášení odběru
--
F-1-0
.,__
2.0
Enforcement/lntegrace PČR/GS dat z vybraných statických
bran '
lntearace: PČR/CS I
Kontrola a statistiky/Data ze statických bran KON - 9 - Prioritizace odběru F-2-0 5,0
EnforcemenVlntegrace PČR/GS dat z vybraných statických
bran
lntearace: PČR/GS
I
Kontrola a statistiky/Data ze statických KON -10 - Ukončení F-1-0 2,0
branEnforcemenVlntegrace PČR/GS prloritlzace odběru dat ze
statické bránylntegrace:
- PČR/GS
Kontrola a statistiky/Data ze statických bran KON -11-Vyhodnocenf F-2-0 5,0
EnforcamenVKontrola vozidel Identifikované SPZ - statické
brány
-
Kontrola a statlstlky/Data ze statických bran KON -12 - Předání Informace o F-2-0 5,0
EnforcemenVKontrola vozidel ldentlňkované SPZ
enforcementu
Kontrol.a a statistiky/Data ze statických bran KON - 13 - Předáni obrazové F-1-0 2,0
EnforcemenVKontrola vozidel Informace o Identifikované SPZ
enforcementu
Kontrola a statistiky/Data ze statických bran KON - 14 - Informace o F- 0,0
EnforcemenVKontrola vozidel výsledku kontroly vozidla N/A-
Zahrnuto v KON - 4 N/A
Kontrol.a a statlstlky/Data ze statických bran KON - 15 - Reportlng a F-2-0 5,0
EnforcemenVKontrola vozidel Statistiky I
I
APi Reporting
-
Statistiky/Statistiky STA -1- Vytváření před-
- ~
15,0
F-3-0
společné/Statistiky definovaných výstupů
Jádro statistik I
Statlstlky/Statistiky STA - 2 - Vytváření ad-hoc F-3-0 15,0
Společné/Statlstlky výstupů
Jádro statistik
Statistiky/Statistiky STA - 3 -. Vytvářen! F-3-0 15.0
Společné/Statistiky periodických výstupů
I

- -- -
Oblast/ Podoblast
M1Miut/Kcmponenta
---- ~ -
Kód-~
Poznámka
-
Typ-
Rozs.
stan,
MD
l
. _ lntetJraee ~Bezp.
~ - --------- --
Scheduler
-- - :=!:..:....L ___
Integrace: Notifikace
-
Statlstiky/Statistiky
-- ---- STA - 4 - I ntemf reporting F-3-0 15,0
Společné/Statistiky Výčet statlstlk napřlč
S):'.Stémem
I
Statistiky/Statistiky
--- ---- STA - 5 - Externí reporting 1 F-3-0 I 15,0
Společné/statistiky Výčet statistlk nepřič
I
---
Sdílené funkce/Správa subjektů
Společné/MDM
svstérnern
SDF - 1 - Správa subjektů -
vedení evidence
F-3-0 15,0
Souvislost s POR - 16
lnte , race: eShop <backofflce)
I
Sdílené funkce/Správa subjektů SOF - 2 - Správa subjektů -
-F-2-0 5,0
~polečné/MDfv1 grafické rozhraní
Sdílené funkce/Správa subjektů
--
SDF - 3 - Správa subjektů - 5,0
F-2-0
Společné/MDM vyhledávání
Požadavky na vyhledávání
mohou mít dopady na
I
I
strukturu datového úložiště,
Sdílené funkce/Správa subjektů SOF - 4 - Správa subjektů - F-2-0 5,0
Společné/MDM kontrola adres
Integrace: RUIAN
I
Sdllené funkce/Správa subjektů
-- SOF - 5 - Správa subjektů - F-2-2 6,0
Společné/MDM kontrola přístupu
Definice roU a apUkačních práv,
neslučitelné role
--
Sdilené funkce/Správa číselníků SOF - 6 - Správa číselníků - I F-3-0 15.0
Společné/MDM verzování
Sdilené funkce/Správa číselníků SOF - 7 - Správa číselníků - F-2-0 5,0
Společné/Mot,,1 grafické rozhranf
Sdllené funkce/Správa číselníků SDF - 8 - Správa čiselníků - F-2-0 5,0
Společné/Mot,,1 hierarchie
Sdllené funkce/Správa SOF - 9 - Správa číselníků - F-3-0 15,0
čiselníkůSpolečné/MDM import a export
Sdllené funkce/Správa číselníků SDF - 10 - Správa číselníků - F-2-1 5.5
Společné/MDM
--
poskytování člselníků
Přístup pro externí systémy l
Sdílené funkce/Správa číselniků SOF - 11 - Správa číselníků -
vzájemné vazby
F-3-0 I 15,0
Společné/MOM
včetně vícenásobných vazeb a
správy historie
l
-
Sdilené funkce/Správa člselnlků SOF - 12 - Správa člselníků - F-2-0 5,0
Společné/MDM komentáře

--
Oblast/P'odobt.Mt Kód -Námv Typ- stan.
MGdul/Komponenta Pomémka Rolzs. MO
--- --
ln\egPace
_,_._ .......... -Be7p.
Sdílené funkce/Správa číselníků SOF -13 - Správa číselníků - F~2-0 ) 5,0
Společné/MOM vazba na datová pole
- - -
Sdílené funkce/Správa číselní~ SDF -14 - Správa číselníků - F-2-0 5,0
Společné/MDM verzování
řízení uvolnění nové verze
obsahu komponentám
--
Sdílené funkce/Správa číselníků SOF -15 - Správa číselníků - F-3-0 15,0
Společné/MDM oprávnění
práva pro zápis - do úrovně
ooložek a abibutů
Sdílené funkce/Správa číselníků SOF -16 - Reportlng a F-2-0 ' 5,0
Společné/MDM Statistiky
Osvobozeni/Use Gase - zpracováni OSV - O - Use Gase - F-IND- 50,0
Oznámení zpracování Oznámení o
Osvobozenl/Evk:lence Jednotlivé scénáře zpracování
osvobození
Osvobozen i/Podání v Ustln né formě osv - 1- Pfevzetl prvotní F-3-0 15,0
Osvobození/Evidence ldentlflkace Listinného
oznámení
lnteorace: SFDI/SE
Osvobozen[/Podání elektronická OSV - 2 - Převzetí oznámení z F-3-0 15,0
Osvobozen I/Evidence ePodatelny
lntearace: SFDI/SE
Osvobozeni/Podání elektronická OSV - 3 - Kontrola .Formátu' F-3-0
·-
15,0
Osvobozen i/Evidence oznámení
lnteQrace: SFDI/SE
Osvobození/Podáni elektronická OSV - 4 - Kontrola Náležitostí F-2-0 5,0
Osvobozen i/Evidence oznámení - podpis
Osvobozeni/Zpracování - společné aktivity OSV - 5 - Kontrola F-3-0 15,0
Osvobozeni/Evidence Provozovatele na právo
osvobození
-Osvobození/Zpracování - společné aktivity lnt~race: Různé registry

OSV - 6 - Kontrola Náležitosti F-3-0 15,0
OsvobozenVEvidence oznámení - vozidla
lnteorace: RSV
Osvobození/Zpracování - společné aktivity OSV - 7 - Kontrola Náležitosti F-2-0 5,0
Osvobozeni/Evidence oznámení - zrušení
Integrace: Evidence I

Oblas l/Podob\ast - - -- !Kód - Náav --- Typ- I Stan. l
ModuVKomponel'lta Poznámka Rozs. MD I
lntesJrace I -Bez:p.
I
Osvobozeni/Zpracování - společné aktMty OSV- 8 - Kontrola Náležitosti F-2-0 - 5,0
Osvobození/Evidence I oznámení - manuální
t---
Osvobození/Zpracování - společné aktivity OSV - 9 - Zápis do Evidence F-2-2 6,0
Osvobození/Evidence osvobození
Osvobození/Zpracování - společné OSV - 10 - Zaznamenání F-2-2 6,0
aktivityOsvobození/Evldence výsledku kontroly na pozemní
komunikaci
OsvobozenVZpracování - společné aktivity OSV - 11 - Vytvoření reportu o F-3-0 15,0
Osvobození/Evidence zpracování --f--
Osvobození/Zpracování - společné aktivity OSY - 12 - Odeslání/ F-2-1 1 5,5
Osvobození/Evidence zpřístupnění reportu o
zpracováni
ln race: ISDS, email, SFDI

-
Osvobozeni/Zpracování - společné aktivity OSV - 13 - Kontrola trvání I F-3-0 I 15,0
Osvobozeni/Evidence platnosti podmínek osvobození
Mechanismus pro periodickou
kontrolou trvání důvodů pro
osvobození
Osvobození/Zpracování - společné aktivity OSV - 14 - Zápis údajů do I F-2-0 I 5,0
Osvobozeni/Evidence Whitellst
Osvobození/Zpracování - společné aktivity OSY - 15 - Reporting a-- IF-2-0 l -
5,0
Osvobozeni/Evidence Statistiky
ePodatelna a eVýpravna/ePodatelna POD - 1- Prnmový kanál ISDS I F-2-0 I 5,0
Spol.ečné/ePodatelna Požadavek není z přílohy 1.je
doplněn na základě 'Doplnění
požadavků SFDI',
Integrace: ISDS
ePodatelna a eVýpravna/ePodatelna I POD - 2 - Příjmový kanál e-mall I F-2-0 I 5,0
Spol.ecné/ePodatelna Požadavek není z přílohy 1.je
požadavků SFDI',
-- Inte ace: e-rnall
ePodatelna a eVýpravna/ePodatelna POD - 3 - Tfíděnf došlých zpráv I F-2-2 I 6,0
Spol.ečné/ePodatelna Požadavek není z prflohy l Je
požadavků SFDI'.
Logika vybírající zprávy EDAZ a
ePodatelna a eVýpravna/ePodatelna
Společné/ePodatelna
~
l ldentlfi~py zpráv
POD - 4 - Zpracování došlých I F-3-2
zpráv
I 18,0
Požadavek nenfz přílohy lje

doplněn na základě 'Doplněni
µožadavků SFDI'. I

- -~
Oblast/Podoblast Kód-Název !Typ- stan.
Modt.ll/Kompg11enta PG;známJca llozs. MO
" - - -
lnteqrace -~. -
Zpracovánfjednotlivých zpráv
dle typu I
ePodatelna a eVýpravna/eVýpravna
- VYP -1- Generování výstupů F-3--0 15,0
Společné/eVýpravna Požadavek nen/ z přfl.ohy 1,Je
požadavků SFDI',
Na základě datových vstupů a
šablon
ePodatelna a eVýpravna/eVýpravna VYP - 2 - Určeni výstupního F-3-0 15,0
Společné/eVýpravna kanálu
Požadavek není z přílohy l,je
požadavků SFDI".
Logika určující způsob odeslání
(způsob přijmu vstupu,
dostupné kontaktní údaje, typ
zprávy)
ePodatelna. a eVýpravna/eVýpravna VYP - 3 - Výstupní kanál ISDS F-2-0 5,0
Společné/eVýpravna Požadavek není z přílohy l,je
požadavků SFDI'.
lnteorace: ISDS
ePodatelna a VYP - 4 - Výstupnf kanále- F-2-0 5,0
eVýpravna/eVýpravnaSpolečné/eVýpravna mallPožadavek není z přílohy 1.
je doplněn na základě
'Doplnění požadavků I
SFDl'.ln~ace: e-mail
ePodatelna a eVýpravna/eVýpravna VYP - 5 - Registr odchozích F-2-0 5,0
Společné/eVýpravna zpráv
Požadavek nenf z přílohy 1.Je
doplněn na základě 'Doplněn[
požadavků SFDI',
ePodatelna a eVýpravna/eVýpravna VYP - 6 - Elektronický podpis F-2-0 5,0
Společné/eVýpravna Požadavek není z přílohy Lje
požadavků SFDI',
Zahrnuje I mechanismus pro
sorávu certlfl<átů.
I
ePodatelna a eVypravna/eVýpravna VYP - 7 - Výstupní kanál I F-2-0 5,0
Společné/eVýpravna listinný
Požadavek není z pfllohy 1.Je
požadavků SFDI'. I
Jen předénl přes APi a př[iem
odpovědi.
lnteorace: Výpravna <listinná)

2.6.3. lmplementa čnl složitost dle modulů a komponent
Následující tabulka obsahuje určení lmplementačni složitosti v členění na
moduly a komponenty. Složitost modulu Základ webu je zvýšena o 15 %
v důsledku požadavku na podporu Internet Explorer. viz kapitola 2.4. Faktory

ovtlvňuííct cenu implementace.
- - ---- -~ ~ ~--
SoMčetz
Doplňllo vý MO
Poplskyi'ádk(i Po.latiaYkl) stanoveni
faktor ~
ND -
Clearing 34 218,2 218,2
Jádro ]2 104,5 104.5
Párováni plateb 5 34 34
Párování plateb na proforma 2 ]2 12
fakturu
Vvoořádání Dodavatel 8 37,5 37,5
Vvpořádánl eShop 6 15,2 15.2
Zaiištěnl dodavatel 1 15 15
Enforcement 15 108,5 108,5
lnteqracs brány 2 22 22
Integrace PČR/CS 4 14.5 14.5
Kontrola vozidel 9 72 72
eShop Cbackofftce) 15 64,6 64,6
-- -t- -- -
Interní správa uživatelů 5 14,5 --~~- 14,5
--
Platební brána 7 42,9 42,9
~~ -- 2,2
-
2,2
Správa externích uživatelů
---1 -- - -
Správa organizací 1 5 5
Správa SPZ 1 o o
eShop(externfčást} 60 242,4 242,4
Anonvmní přístup 1 22 22
Evidence obchodů 1 5,5 5.5
Nákup 32 785 78.5
Notifikace 1 18 -- 18
-- -- - -
Osvobození 9 76,6 76,6
Platební brána 1 6 6
Profil 4 17 _1Z]
Související služby 1 24 2,4
Správa externích uživatelů 8 28,7 28,7,
Správa SPZ 2 7,5 7,5!
Evidence 10 104 104
lntearace RSV 1 5,5 s.sl
-----
Znalecký posudek č. '14/2/2019
------- 80
--- ~- -
Poptsky fádku Požadavků
.souéetz
Stanoveni
I Doplňkový
faktor
MO
výsledné
I
- --~ MO
--
Posk ,továni informaci lt 16,5 16,5
~is 8 82 82
-
Osvobození 16 197,5 197,5
- -~ ~.
-
Evidence 16 197,5 197,5
----
Společné 66 472,8 496,2
- -
Integrace 1 6 6
MDM 16 1315 131,5
NotJflkace 1 15
- 15
Statistiky 5 75 75
Základ webu 32
- 156.3 15% 179,7
ePodatelna 4 34 34
eV)pravna 7 55
--
55
- _..,
Celkcwý iGUéet 216 1408 1431
2.7. Specifikace platformy
Klíčovým parametrem pro určení ceny zřízení a provozu platformy je Její výkon,
který vyplývá z předpokládané zátěže IS EDAZ, ten je odvozen v následující
podkapitole. V následltjících podkapitolách jsou uvedeny dále významné
obecné požadavky, které ovLivňují související služby.
2.7.1. Výkon platfonny
Stanovení potřebného počtu virtuálnich serverů pro produkční prostředí Je
založen na odhadu výpočetní složitosti prováděných operací. Pro stanovení je

použit zjednodušený abstraktní model zpracování, který používá následulícl
pravidla a principy:
• Struktura virtuálních aplikačních serverů Je homogenní, všechny maji
pouze Jeden virtuální procesor.
• Jako klíčový parametr pro stanoveníje použit procesorový čas.

■ Odhady výpočetní složitosti Jsou uvedeny v milisekundách
procesorového času.
Příklad: Pokudje výpočetní složitost typu operace odhadnuta na 500ms,
tak Jeden vlrtuální procesor za Jednu sekundu zpracuje dvě takové

operace při 100% využltí.
■ V odhadu výpočetní složitosti (procesorového času)Je zanedbán i dle tlme
(čas, kdy procesor čeká na odezvu paměti, zápisu na disk a podobně). To
znamená, že operace,Jejlž výpočetní složltostje lOOms, reálně trvá déle,
ale během tohoto času není procesor využit na 100% a může paralelně
zpracovávat Jiné operace. Toto zjednodušeni tedy nezpůsobuje chybu
kapacitního odhadu.
■ Není samostatně odhadnuta výpočetní složitost pro databázový server,
složitost Interakce s datovým úložištěmje zohledněna v odhadu složitosti
aplikační vrstvy.
■ Pro stanovení byty analyzovány vybrané operace nákupu přes web a

nákupu prostřednictvím Dodavatele, jakožto předpokládané nelčetnělšl
operace, pro odhad celkové kapacity byl použit předpoklad, že nákup
představuje 50% celkové zátěže systém u.
Postup výpočtu Je následujfcf:
■ Odhad výpočetní složitosti nákupu pomoci webu a prostřednictvím
dodavatele (složitost těchto dvou základních metod je významně odlišná.
proto je odhadnuta odděleně).
■ Odhad maximálního počtu operací za sekundu. Tento výpočet navazuje
na odhad potřebné kapacity Call centra, viz kapitola F. Další provozní
činnosti.
■ Z předchozích údajůje odvozen počet potřebných aplikačních serverů.

Níže je uveden detailní výpo čet s komentáři.
#1 Mod elová ~nákup eShop
Akce Složitost Složitost Poznámka

web BL• DB
Zobrazeni web 1
Přihlášení 1 1
-
Vložení do košíku 1 2 Zápis do DB eShop
- Potvrzeni 1 1
-~-
Zobrazeni košíku 1 1
Potvrzení objednávky 1 2 Zápis do DB eShop
Platba 1 3 Platební brána, asynchronní
integrace
Záris evidence
-- 2
Zobrazení potvrzeni 1 1
Nákup na eShopu je v tabulce rozdělen na JednotUvé Interakce mezi klientem
(webovým prohlížečem) a aplikaci EDAZ. Zpracováni na serveru probíhá ve vice
vrstvách, v tomto zjednodušeném modelu Je rozUšena vrstva webového serveru,
který poskytuie statický i dynamický obsah a vrstvy aplikační logiky, která je
spojena i s interakci s databázovým serverem.
Pro odhad byly stanoveny následující stupně výpočetní složitosti:
1 50ms - ne.lJednoclušší Interakce serveru, která často pracuJe s
informacemi. které Jsou v cache (mezlpaměO aplikačního serveru
(případně v cache databáze). Pokud načítá data z DB tak pouze v
jednotkách záznamů (např, Informace o uživateli),
2. 100ms - aktivniJednoduché operace, zápis do databáze.
3. 200ms - složitější operace, které například interagují s jinými systémy.
#2 Výpočetnl sl.offlost e-shop

Složitost Počet Počet Počet Procesorová zátěž Procesorová zátěž
web BL•DB Celkem operace Irnsl [msl
1 8 4 12 50 600
2 . o 3 3 100 300
3 o 1 1 200 200
Csikem 1.100

V tabulce jsou shrnuty počty elementárních serverových ope rací dle Jejich
kategorie složitost a Je vypočtena celková výpočetní složitost nákupu na
eShopu. Jed ná se o mod el ne_[Jednod uššfho .happy day" scénáře, Jedná se o

hypotetický model pouze pro výpočet kapacity, reálně nákup trvá minimálně
několik minut. jednotlivé operace nenásledují najednou, ale jsou vyvolávány
interakcí koncového uživatele. Nicméně toto zjednodušení výpočet

nepoškozuje.
Následuje obdobný výpočet pro Dodavatele. Postup výpočtu Je stejný, ale
významně jednodušší.
#l M<>de1evé transak ce Dodavatel

Akce Složitost Složitost Poznámka
web BL•DB
Zápis evidence+ 3 Složitost zvyšule webová služba a
evidence pohledávky zabezpečí - integrace s externím
systémem
.14 v, - - - . '.: složftost.Dodevatel

Složitost Počet Počet Počet Procesorová zátěž Procesor ová zátěž
operace [ms] [ms]
- 1 o o o 60 o
2 o o o 100 o
3 o 1 1 200 200
Celken1 zoo
Důvodem podstatně nižší složitostije to, že převážná část Interakce s koncovým
uživatelem {zákazníkem) probíhá v systému Dodavatele, do IS EDAZ se zasilá až
informace o uskutečněném nákupu. Proto Je celková složitost zpracování (na

straně EDAZ) významně nižší.
Na základě informace z podkladů o poměru mezi obchody uskutečněnými u

Dodavatele a na eShopu (viz 13.3. 00-Doplnenl-20191127 - Doplnění požadavků

SFDI. Kapitola 4 Provozní požadavky)Je odhadnuta průměrná výpočetní složitost
nákupní transakce.
H Výpočelnl sleiltest kombinace

ProdeJnr kanál Zastoupeni Výpočetní Poměrná
složitost zátěž [msl
eShC>f>i 40% 1100 440
- -
Dodavatel -- - 60% 200 120
- ·--
#f, Pmměmá prQCesol"OY á zátěž nákupu [msJ 560
Následuje odhad maximálního počtu transakcí a výpočet počtu virtuálních
serverů.
Počet trerlsakd
Popis Počet Převodní Navýšeni
I
úhrad koeflclent špička
#7 Počet úhrad za hodinu e shop 1.974

#8 Počet úhrad za hodinu celkem 4,935
#9 Počet úhrad za minutu 411 60 5
#10 Počet úhrad za .sek-undu 34,3 60
Pooet ~ serveru
#11 Průměrná procesorová zátěž nákupu lrnsl 560
/s
#12 Podíl operace nákup ve všech operacích 60%
(odhad}
#13 Potřebný čas CPU lrnsl pro nákup / s 38.416
#14 Počet vtrtu6lltlch i8lV8l'Ů {affigle vCPU ) 38,4
#7 - odhad maximální zátěže eShopu. Údaj je odvozen v kapitole F Další
provozní činnosti.
#8 - údaj v #7 představuje 40 % nákupů, zde je vypočten celkový počet
(eShop + Dodavatel).
#9 - odhad špičkové zátěže pro minutu - přepočtem poměrem délky časového
úseku (minuta / hodina) a navýšeno koeficientem zohledňujícím výskyt špiček,

ten Je oproti převodům měsíc -> den a den -> hodina (viz kapitola F. Další
provozní činnosti) vyšší:Je zde větši páka převodu a fluktuace v kratších úsecích
jsou vyšší.
#10 - odhad špičkové zátěže pro sekundu - stejný princip jako předchozí řádek.
Objednatel požaduje odezvy ve špičkách do dvou sekund. Pro splnění tohoto
požadavku Je nutné použít vyšší koeficient zohledňuJíci špičky,
#11 - odhad odvozený v předchozí části
plo j odhad, že kUčové operace nákupu představu]! 50 % zátěže
#13 - #10 x #11 / plo j koli k procesorového časuje ve špičkách potřeba vjedné
sekundě
#14 - počet virtuálních serverů potřebných pro pokryti špičkové zátěže - #13 /
1000
Pro zajištěni potřebného výkonu včetně odhadovaných špiček Je stanoven
výkon odpovídající 39-tl virtuálním aplikačním serverům s garantovaným
výkonem jednoho vlrtuálnfho procesoru.
2.7.2. Bezpečnost
Níže jsou posouzeny požadavky na bezpečnost uvedené v 1.3.2. Smlouva
Prlloha_l část Obecné požadavky - Systém EDAZ, kapitola 2.3. Požadavky na
bezpečnost Z těchto požadavků Jsou vybrány ty, které se přímo dotýkají
Implementace HW platformy v širším slova smyslu, tj. fyzické servery a fyzická
architektura, ale také vlrtuální infrastruktura, základní SW, jeho konfigurace,
mechanismy zálohování a monitoringu.

OPO - 020 Podpora zabezpečení sítě)
Požadavek Objednatele:
! ~ Á'll.Jsl byt koncif,)~ tak, aby $lfová ko:mvrnka!:e ~ pmw,tačrn,
~hl' a~~ WSWotl ~ výAreňně ~ TCP, přitet'tlŽ na

atrane ~emv ~ici $1l4by ~, ~ s«rtlc~h. ~ém
~ portů. ~ p~ t.JDP je rnomé výhradně pro ~not.I
}2)~tVJ tšmc! ool'ltsdu net»~~~eata ?OdJ-~~r
unioinlt po~ šffi,ov~né ~~
K t~ cairamy ~ ~ sitt P~&těl:
~ NawhM &~~c1 šfié i ~ ne i,s~ ~ ~ ~
toktt NéWt-i · ~ ~ o®aleffl ~ w~ ~Hkace,

~ ~ p~éffi lrlt'$lvy a J~ tntegračrn rO'lhrart! ~
ffivfstvé art:hrotkt~ ~ s ~ ~ ha ~ ~
~acnfch sm.
b) Pokud budtlf ~ doo~ ·t cl&dénf od~ Wr~ {at,;;tlvnf
~. FW apod.} ~ mff~ je tnmino ~ -ď clQ~ ~.
vy-pr~ Po~ dolwf'rumt ~ kortcepd ~ a ~

~ ~ ~~ PAAIQR! tak. ®V ~e ncWmtt i deišt
~ ~ ~ pqtfma1 «orii~ ffyt~ ff. ~lftí
fwewaly, ~ ·VS. ~ sw!tdil;e, edilené VS. dm~é J!OZ~
flrew~.
c) Pflpra"t ~ 6' sou<1tnnostni ~ ~ ~ sítě -(pr~.
bez~ 8 'ěeohnotog!cioo µ$$~
dl~ že togk:ká sllové ~ budou M w-cwrn ~ tow-··

pr~rry s tim. ~ ~uci k~e bude aklwně bloko¼ffla.

'Mf.no~ prověfO\lérnJe iíÍ'$).ud-~~--to-.errcl t}fréMáttl ~toV')th j
toků S1GuviseJ!cich s r;,Nmámíml aktiVy všude, kd& toJe mo.žr-ré. I

e$~f5N oanranu ~ce v podobě vaHctece e ffltrace vawpních ctAt ria
pubt:llí:ii:érn vrstvě a ~ ·tak ·rte vf:Stv~ wrt.~.
:O Zaj\stí ~ pr«! KBU at KBl Cftemje ~~k,klhll0 &Jméno
typu útdru,JSJ1c~ citem Je xat'nQZ.em, ·nebe omsmrú dostuptmsi;i ~pWkace.
Předpokládaný způsob řešení
Pro zallšténl zabezpečeni sftí je nezbytné oddělit jednoillvé sítové segmenty.
Při současném stavu technologií lze doporučit technologii Virtuální LAN CVLAN).
Vzhledem k velkým propustnostem, kterých fyzická síťová propojeni dosahují
nenf použití technologie VLAN výkonnostním omezením. Zároveň je tato
technologie považována za dostatečně bezpečnou. Oddělení jednotlivých typů

síťového provozu technologii VLAN v Jednom sřřovérn kabelu dostatečně
zabezpečuje provoz proti nežádoucímu úniku dat mezi datovými sítěmi. Dále
pak zabraňuje nechtěné kolizi na síti a ochrání tak provoz na dalších virtuálních
sítích, aniž by Incident na Jedné virtuální sftl ovlivnil další virtuální sltě, které jsou
provozovány na stejném datovém nosiči. V rámci obvyklého scénáře návrhu
obdobných řešení Je předpokládáno použiti samostatné virtuální sltě pro
jednotlivé typy síťového provozu (např.: virtualizační vrstva, iSCSI {disková
úložiště, zálohování, servery apod), management síť, DMZ, Front end nebo Back
end aplikace, apod),
Pro dobře navrženou segmentaci sltě Je zapotřebí Jak spolehUvý hardware, tak
i kvaUtnf podpora VLAN ze strany vlrtuallzačnf platformy, případně operačních
systémů. Všem těmto prerekvizrtám musí předcházet detailní návrh sífové
topologie, který bude reflektovat výše zmfněné předpoklady. Dalším neméně
důležitým předpokladem Je kontrola jednotlivých toků na datových sitich. Pro

dosažení maximální kontroly Je nutné vyžadovat bez peč nostní řešení s
podporou Inspekce a řízení provozu až do vrstvy L7 ISO/OSI modelu. Pro tato

řešení Lze s výhodou použít technologii NGFW (Next-generatlon firewall), Jejíž
použití je možné Jak v prostředí "on premis Infrastruktury" tak I v cloudovém
prostředí. Vzhledem ke skutečnosti. že se Jsou uvažovány Jak Interní. tak externí
přístupy, je nutné implementovat systém automatické blokace v přfpadě

nestandardního chování a samozřejmě nezbytný reporting do centrálního
monitoringu celého systému. Použiti výše zmíněných mechanizmů snlžqle riziko
úniku dat Dalším nesporným přínosem oddělení Jednotlivých typů datových
toků Je skutečnost, že v případě konfigurační chyby, která způsobí zahlcení
sítového segmentu nežádoucím provozem nedojde k pádu celé síťové
infrastruktury, ke kterému by mohlo dojít při neoddělení datových toků ze všech
možných datových zdrojů. V rámci podpory zabezpečení sítě Je nutné zavedení
mechanizmů, které budou umožňovat zpětnou analýzu Jednotlivých Incidentů,
čl konfiguračních chyb. Při nasazení tohoto typu softwaru je možné
vyhodnocovat chování například na Jednotlivých serverech a zapisovat všechny
kroky do souborů v podobě metadat, nebo nahrávat Jednotlivé sessions v
podobě video záznamů. Tento typ softwaru zaručuje nejenom vyšší bezpečnost
na Jednotlivých serverech, ale I možnost při vytvoření konfigurační chyby vrátit
se do počátečního bodu a napravit tak chybu, čl špatné nastavení.
OPO 26 - Monitoring
~ $)'stém musí ~owt po~ pro pr~ monl'tmlng na úrWflt SNMP
v3 );!Četně~~ M;aOO ~ l'řfl prMtní MM3. kt&ré umožní

monltor-QVání výko_N,j s,yst.ém~
b)~-et~tí sběf" a ~ l~ monftorlngi.t

..
ci V pflpadě íden:Uf-ikovfiltého Výpadku ét ~ndardniho $.ta\l~ z J;JO~
provminmo monitoringu Posk~o~l ~i mf~ osťb pověřených
l_ ·ad~ f.ešeni. tak aby~ liJWŽ1'<i ~tni stav GlfMavfil v rámci 'SLA I
Pfedpokládaný způsob řešeni
Pro zajištění dostatečné bezpečnosti a možnosti vyhodnocování provozu
jednotlivých komponent hardwaru, nebo bezpečnosti je nutné implementovat
centrální sběrné rnísto, které bude vyhodnocovat Logy ze všech vyjmenovaných
kategorií. Logy budou získávány z Jednotlivých kategorií například pomocí log
serveru ve formátu syslog nebo prostřednictvím protokolu SNMP.
Tyto informace Jsou odesílány do centrálního sběrného místa, kde Jsou
vyhodnocovány pomocí SIEM serveru, Při správném nastavení dochází nejenom
k vyhodnocování již nastalých Incidentů, ale i k možné predikci Incidentů, které
potenciálně nastanou. Pro kvalitní Implementaci SIEM řešení je důležitý správný
návrh a implementace celého řešení. Řešeni musí být dostatečně flexibilni, aby
umožňovalo dodatečné rozšiřování a úpravy. Vybrané řešeni bude sloužit I pro
RCA (Root cause analysls) v případě vyhodnocování Již nastalých Incidentů.
Pomocí všech těchto metodje možné automatizovat některé úkony, napřiklad
upozornit obsluhu na výskyt možného Incidentu, který bude potřebovat
zvýšenou pozornost, čl manuální zásah a zabránit tak daleko vyšším škodám,
které by mohly vzniknout. pokud by byla situace řešena ex post Všechna tato
provozní data musf být indexována, aby bylo možné zpětně prohledávat mezi
jednotlivými Incidenty a mít tak možnost zpětně vyhodnocovat provoz I několik
měsíců čl let zpátky. Tyto nástroje pomohou nejenom v rámci bezpečnosti. ale
I např. při vyhodnocení zátěže systému v krizových situacich. Data je možné též
s výhodou využit pro vyhodnocen[ provozních dat z hlediska výpočtu
potřebného pro vyúčtování provozu na měsíční bázi. V této kategorii přichází

standardně v úvahu Sl// na bázi komerčních produktů typu COTS (Commerdal
ofť-the-shelf - používá se také pojem .krablcový softw are"), který Je výrazně
jednodušší na implementaci, většinou obsahu]e přednastavené profily a jeho

správaje méně náročná na kvalifikaci správce. COTS software ve většině případů
není možné dále rozšiřovat o moduly, čl služby, které neobsahuje, Pro
monitoring takto robustního a rozsáhlého řešeníje vhodnější komerční software,

který obsahuje placenou podporu a podporu posledních verzí dostupného
softwaru na trhu. Licenční modely tohoto software se liší produkt od produktu,
nicméně většinou se jedná o licencování počtu socketů, či jader v
monitorovaných systémech. Produkty jako jsou např. HPE OneView, Veeam
One, vRealize apod. nabízejí jednoduché a přehledné rozhraní pro monitoring
celé Infrastruktury a nabízí možnost predikce vývoje Infrastruktury. Správce
systému tak může v předstihu reagovat na možné problémy.
OP0-27 Zálohování
1'y~ bude~at~~v ~P&aS. ~~je
p~ dedévl<y ~. v .nímcf ~ ~ ~
funkční~~
~:zaijtgtj ntisteduj:fct
. ~a~upy~.
· P~~ a p_oat~ Qlouhodobéhe ~
·Aavld& ~,hs~ía ~ooobéhQ ~í ~
. Pr~ a pOd\Jpy ~.
· Pravtdla il poaupy !$Stov$rtJ 2~~ ai ~.
Znalecký posudek č. lA/2/2019 91

· 'P~ přlmupu it: zalotiam. ~ tAfnrmacfm.
· la~ ~upr,oml Zák.)h WU;;!$ de;filnovanvm rolrn.
~~ ~ a Od,0ovfdá za Rě ~rovczovsilet api.lkecelapijksernho

cetxu.
Předpokládaný způsob fešen/
Preferováno je řešení. které podporule zálohování do někoUka vrstev

(odstupňovaná pohotovost zálohy versus objem dat- od neJmenši rychlé vrstvy
až po rozsáhlé pomalejší úložiště} a tím poskytnuti Jak okamžité dostupnosti dat
v pfípadě potfeby rychlé obnovy dat, ale I offslte zálohy například na páskovém
řešení a ochrany data v případě živelné pohromy, či jiné nepredikovatelné
události. Protože se bude návrh celého řešen! skládat z konsistentních šablon
Jednotlivých operačních systémů je vhodné, aby řešení zálohování podporovalo

dedupllkaci zálohovaných dat. čímž výrazně ušetří kapacitu nutnou pro uložení
záloh. Funkce komprese zefektJvní zálohování velkých databází. Napojení na
cloudová řešení usnadní offsite zálohování. Zálohovací řešení musí být možné
provozovat jak na cloudové, tak v on premise Infrastruktuře, a to včetně
standalone serverů. Zálohování musí mimo jiné disponovat podporou
konzlstentniho zálohování DB systémů a možností selektlvnl obnovy dat
Vzhledem k výše uvedeným požadavkům Je zřejmé, že bude nutné využít
enterprise zálohovací systém. který se většinou Licencuje pro virtualizační vrstvu
a jeho licenčnl model se odvlií od počtu socketů, Jader, nebo počtu vlrtuálnfch
serverů. Protože je předpoklad pro více provozovaných lokalit. tak bude
software zároveň podporovat zálohovací repozitáře, pomocí kterých Jej bude
možné provozovat napříč lokaLitami s možností naplánování distribuce záloh.
Znalecký posudek č, 14/2/2019 92

OP0 -28 Šifrování
a<) ~ ~ pó~ mťt~. jm( ~t Š'tfrovéní ~teci li
~znsmw na a,ptibčtri úre-vnt

bt Veě~ré ~ni ~ oi;t. !©~R>Va.tetné ne ~ kom:unika&rn
$'1Qjsn:t. ~ t$Ut!<y a p~. ~ š:Wrovárn nem~ ~m na
všechrtatdi!lta iliéjef-i na-ta u~ to oode ~ .
c) Šifro.wnl bude pml/'áděn o ~ aktuálně odolných ~ltýctl

a!Oarlk:nů .a 14t-iái
-cGPoskytc.w&te1 ~f po.uiw éni ·~ lll.1lO sprétAI ·kMč(t a ~ 1rterý
~ ~fOMffi.f. ~ ~dám. :m,my, ~f ~

~něni ~~a~~-' ~a~ audttrn. ko~vo!\.t.
e)-~at$ ~ ~~ mo-mGSti k l~ OO?QM.CČení v
cbl.!mM ~ a~ ~ ~ úfadeff't a zve~ na ]etl©
~ m~ ~~:1~,gevcertwcs1~~
~~/)
ft:Všechna ~ d:eta· ~ ~ ud~ ,v ~-enťtttm st.atN. ti. ~
~~. je ctt:vde ~ k<imfiguračni zmáni ~ l- nei11'e ~ Rtii

jffi'~ nebo~ fflUSi se ·této: 1,-f!něna prominout ne ~ ~
~ v této po.l<é:s off--iine ~-
L g) S:cutá6tf ~ bude~ Wostetp pro~ šřfrcwéni
Šifrováni Je důležitým aspektem v rámci nasazen! celého řešení. Šifrování musí
být vyřešené od nejnlžš[ datové vrstvy až po nejvyšší. U nejnižší vrstvy bude
zašifrováno datové úložiště na úrovni JednotUvých datových nosičů. Datový

přenos mezi storage částí a dalšími systémy by bylo vhodné také šifrovat. v
připadě IX)UŽití síťového stacku pro přenos dat OSCS I) za použití CHAP protokolu.
Další vrstvy mají šifrování dle použitých protokolů (např. vlrtuallzace, aplikační. či
webové servery, apod), Šifrování na aplikační úrovnl by mělo být realizováno tak.
aby vlastník kllče mohl i v případě havárie rozšifrovat data zašifrovaná tímto
klíčem. Parametry šifrováni jsou popsány v odkazu dokumentace dle
doporučení Již Jednou zmíněného. Šifrování bude pravděpodobně realizováno
formou master key privátního klíče a bude možné udílet různé dešifrovaci klíče
dle rozlišení přístupu jednotlivých uživatelů systému, čímž bude zajištěno. že
vlastnik aktiva (části dat) bude schopen tato data obnovit ze zálohy a nebude
závislý na člověku zodpovědném za šifrování.
OP0-30 Bezpečnostní dohled

--- - -
Systém mwi mft v sobě ~ mecha nismus. biizpečnQWlího dtmleth;t
-~ nástroj pro~ a za?~ KYbe~cti ~

udá!c-st( a nástroj: pro ~ f a ~. kyoornetlci(ýdl ~
lnddenttJ: V ~ ~ ~ v ~ éVún, :měnl vyhtéiky G
~g~~
V ~ ~ dohiedu ~vat-el od ~ prod~

provoiu~;
• AdHoe feš9nt ~ rut;h irtcictent&.
• SMr. koretac:é a ~ ru ~kýd'l bei~ · 1,!dátQstt.
· ~Wfflm'lttOfwěnia ~ oovárri kyoernt!t~ b.ezp.~

tmtostf za ~m tdentfflii:ace ~net~ bm.~cll tncid@ifftů
v re!imu 24x7 a rnfbrmtWánf ~sdiftidl rmí o udét~cl'f.

t..
o \lyhtedá"ÁWÚ a S'est<upwfffl'Í súU\.4~ofch ~-
e FDo~<.Wám Zffl!namu pro určené bezpeónoatni ·row o ~kovaných

~ $ bm-pe;Čr'lo$'tíeh ~-
o Orr=lMEmf pNpam\ ~o vynosn:ooera ~oo koPltMoU

e ~ prmAde.l prei vyhod~ Wýbe~ri -~b a
~11ictl· inc~rttti
6 ~ ~mettckýc~ ~ ~- k @Ft~
Aa~í ba:zpeč~ opati'$rn lnfor~ .a, J<QmwnlkaWffhc
Pro splnění tohoto požadavku Je zapotřebí vyřešit oblasti WAF (Web AppUcatlon
Firewall), IPS (lntruslon Prevention System), DLP (Data Loss Prevention), sběr
logů a proaktivní monitoring Infrastruktury.
IPS a DLP řešení
Bezpečnostní dohled v sobě komblnuJe několik již vyJmenovaných částí
Jsou to zejména monitoring a podpora zabezpečení sftě pomocí IPS a DLP

řešení. Detekce anomáLií bude probíhat jak za pomoci IPS. tak I pomocí
specializovaného software pro DLP řešení. Tato Jsou dostatečně ověřena
Jakožto efektivní řešení pro detekci nežádoucího chování Jak na vnitřní, tak
na vněJší sftl, případně DMZ Bezpečnostní dohled se tedy bude skládat Jak
z monitorovacích zařízení. která nahrávají Jednotlivé sesslons, tak z řešení,

které Je schopno automaticky vyhodnotit nestandardní chování a vyvolat
další předdefinované kroky, které zamezují tomuto chování a/nebo
notifikací správce daného systému. Nasazení a provoz DLP v optimálním
případě zajlstf, že citlivá čl Jinak důležitá data neopustí vnltřnl perlmetr sítě

a nedojde tak k Jejich zcizení, či Jinému nežádoucímu úniku. Zároveň budou
všechny bezpečnostní Incidenty zaznamenávány do společného logu.
Všechna tato řešení vyžadují vysokou výkonnost a malý výskyt "false
pozitive" nálezů tak, aby byla dostatečně efektivní. Jedná se o enterprise
řešení, která zah mují nejen velmi kvalitní systém, ale též vysoké know-how
v podobě podpory a neustále aktualizovaných signatur a dalších informací,
které systém k detekci a prevenci útoků využívá. Tyto systémy Jsou též
možné přizpůsobit na míru konkrétnímu prostředí a provozovateU. Jejich
Implementace vyžaduje pokročilou odbornou znalost a musí být
dodržovány dostupné standardy v oblasti bezpečnostního dohledu.
Sběr logů a DLP
Chod firemních procesů a zpracování počítačových dat Je z velké míry
automatizován prostřednictvím IT. Chod ITje monitorován prostřednictvím
záznamů o událostech (logů). Doposud byly tyto údaje využívány Jen na
kontrolu činnosti IT a pro zpětnou diagnostiku provozních stavů. Avšak

důkladnější analýzou a vytěžováním relevantních írrřorrnacl Lze získávat
nejen Informace o stavu fT, ale I o chování ostatních systémů a zařlzenlch v
síti. Každá akce uživatelů i případných útočníků totiž zanechá ve firemním
IT svůj obraz právě v podobě záznamů o událostech. Princip
bezpečnostního dohledu spočívá ve vyhodnocování relevantních údajů z
doposud autonomně vystupulíclch zdrojů (souborový systém, aplikace,

pošta, sřř, web apod). Je tak možné vyhodnocovat chod firemních procesů
a identifikovat bezpečnostní události a incidenty a zahájit včasnou reakci.
Cílemje zabránit případnému útoku na slabá místa ve firemní Infrastruktuře.
Klasický útok na nechráněná místa probíhá v několika fázich, útočnik tak
zanechává v sledovaném systému mnoho stop v záznamech o událostech

(logy). Rovněž Je možné sledovat komunikaci a automatizovaně odhalovat
zranitelnosti. častým problémem je vysoký objem dat nutných pro analýzu,
rozličná struktura dat a nároky na rychlost zpracování. Tyto Informace nelze
zpracovat lidskou silou. Proto kvalitní a strukturované zpracování probíhá
automatizovaně.
Získané bezpečnostní informace (datové toky, logy a zranitelnosti) Jsou
analyzovány v centrálním monitoringu celého řešení. Typicky se vyu žívají
nástroje, které patří trvale k top leaderům v každoročním hodnocení
společnosti Gartner (typicky IBM Sec urlty QRadar). Pokud dojde k detekci
bezpečnostního Incidentu, Jsou kompetentní osoby ze strany objednatele
notifikovány, a s jejich součinností je zahájeno řeše ní incidentu.
Výstupy formou přehledů, výpisů. reportů, statistik a grafů jsou dostupné
v centrálním dohledovém monitoringu bezpečnostních Incidentů. Odsud sl
většinou zákazník sám řídí další postup při řešení bezpečnostní události.
V případě, že se Jedná o komplexnější incident, může ad-hoc požádat
o bezodklad nou pomoc v rámci smluvních lhůt Případně může
provozovatel služeb zahájit pomoc automaticky Ihned po Identifikaci
události v závislosti na povaze Incidentu. Preventivní opatření
bezpečnostního dohledu snižují rizika, jejich účinnost Je však efektivní
pouze do určité míry. To Je Jedna z motivací k přijetí opatření, aby byla
skutečná hrozba rozpoznána co nejrychleji, a aby na nf bylo co nejrychleji
reagováno, nejlépe téměř v reálném čase. Bezpečnostní dohled nejen
urychluje detekci narušení, ale také umožnu]e určení původu incidentu,
Jeho dopadů a rozsahu. Díky zjištěným informacím Je možné urychlit
nápravu a obnovit tak důvěryhodnost IT zdrojů firmy.

OP0-37 Bezpečnostní dokumentace
•.P~zajfsti~~fr'1J$P.~&~~b'$:zp.rečoostn'ia
;Pf0VOZni d~entaoe 'tf souladu s ~~ ZQKa a ~. ~ ~

~\.!kO- .uved~eh v pftlole č. 5. k této \loKll.
k¾lmel'l't;.ac@ t1ude p~ relf!QOvené s ~~vaná -Qtjpe~ ·

rty aktiv pfip. ódp(wědílými OSQbami :aa je.ti~offiiilé ~ti á do~Ci
· PtDVf»nf ~n1 dokumentace je ZpJ;aoověná na ~ ~d.íiEů
~ itlJk, ~bije organiza6nf a tacllrltcká ~enf

-~l!'aflýoh l'lz1k v solJtadY se~~ r~ ~-
r f'.lrovcZř\1 bGi{M!éflfitRi d0kurntm$'ee !1)h;Jt1tipf~ čirm.OOl bet,peooostnich

sp~ ~ ~mu v~ rouch, ~-.tn:lenýeh pro,
-~Art.r ------ -~ ,,.,,.,.,;. ~ ..-w
-V, D1'Wt.·r,, ~~ ~ 1'"" ~ ..-,
řj
y· 'ff jjj_ ;jjjjtj _ Hj;,,j -~.::.i
ffµf-'j'l1UU'lifrt,:I ,iry;~ffiLJ,
• B~ rl~e musí ~ všechny ~wantm ·eb!asU-.
~~ W©rMaci vybid~Aé \/QKB., a/ Mb@ vyplMfcl ~ \/j$tedw0

a~r12ik.
· ~raa ~ bal~ do~ musf ~eházet ze ~
~ ?1'<4l bEapeen0&W ~ 8 dffií ~~

dokutrt~ ~ ě v př-íloze č. s~
A 5~~~~~joou ~í~•
1 f~ aktlV P'eft!)k.1 a ~
• uflferl a evt~ ~ hpr~ a pocip 1ffl)\Í',Ch -alill>I•

\ttetné Yt'ooní je)Wl .garantů,
· ur~ ~ a ~viSlostt~· tlf~ a~ aktwy.

2.?~atet ~ ~rn ~o&tnlch potruldE?~ p:v[p.jedné EW, · '
bud'$ otJsahQvart tyto b~-nf poEruky pot:íte J).~ VoKIS':
A. Pot!Wm S1/~ ~ bwpQěnostt infon=rmti
H. Potttlka řfz-Elmf mrt'w
C.~ oc~ ri~
O, POLlí&a řfzenf ntlk
€, ~ ~ změft
F. Potitlkii ťlreRf ~
Q PGl!t.llGl ~eěf'tostl Mds~ i~
H. ~ rfzffl ~ a keml.ffl~
L Polltika ř±iieťi ptbtup~
J. p~ ~ chovilnl. wžlv&tety
K POiitM ~vánf a obnovy a dlol\$h~ ~
L P~b~~avym.ooyW~
M. ~ neem ~~ ~-
N. ~-~. vývóje a ů$.tby
Q. ~ ·QC'ffl'aflY 0$.Qbm;h ~
P. Paiitlka~ be-~
Q Pot• ~i t<omurnkačni-~
R Pomlka O'Ghre:f\Y ~~kódem

S. PoOOka ~ a ~ ~ pfG ~ kyb.ar~
~~h~

..
T. PoMttka. vyui1tí a ú.dr:áh-y némoje pro aoor a 'r)'hodnc.oěl1f
k}tb$metiéký'ctl bezp.oonootních udatostf
V. PQUt«a bezp~ ~ kryptag raf>!Cké ochrany
W. Potiú1f.Bt nzenf ~~-

3. Poskytovatel izagsti -vyh,'eieru nav.tit1-ujicich bezp~O$tnlch -a, pro~
~ ~ po$tu~ pro 2~ ~fa pr~ po-41e ~$Ilků

ZoKBIV ~ JJ~ a poswpy pro a ~ a ~ní identity ut~.
~fistráttm.l i~ !nf~ a t(~ ~
li ~a ít .ptl),Stupy pro Mzení p:ř~h opťÉIVn3rrí uífVat$li a
amntnk:tratoru
loo ~ $. ~ pFO-řfl!0N & $cl\V~ Ul'l0f'I: a~ V tS/tC"f
e. $fpthcich WihmLOici f da~~
-d Post~y pro pra~ pfe.2~ ~h o.práwnimf m
tírovr1li tS vč-etnš ~- ~ ~ v pňst-upQ~

$kUplnách.
dl~ pre adVarlt.1 ~maci a dat v ~ -éeiétlo ~raho

tykru
91 Prsvtdla a~~ ~ní
h) PQstupy pre ~ pravtdst~ z~ dat a ~

~no,tf -!Iď~ moo

n) P~ pro p~ testcwání ~ti p!a:nů fS/FCT a aptlkaci
a· obhovy dt:n pre1 ~ajiitěnf Nzenf ktmtinwty provor.ru !SACT' a ~ci
•QH.rf?tány~
p) ~ a ~PV nasaz.enf né&troje pro -detekd ~oké
~ od'\I~
q} p~ ~~~I~~~ nootroje
~ sběr• vyhotioo: á:2fll ff.)'ber~ ~tJdatbstí
r1 ~ a-~ -pro fmru fet:fm1ekýeh zralll'WMStf tiS/ICT a
:zanrl"IUtf ~~ ~ do pr('.)jel(w ~- ~ a
l,idržby
·Pr~pto~~prog,~~
· ?nwtdta e post~ v,<~ ~ pr~~

~-
~~a~~ OprtN f>fU9rame>wéha ~ -
• Pr~ a1)0'6'tupy~ opmvprogrmm.Q<Vého -~
g,} P&stupv ~ prBViidlW.pr~ ~a~~

mmftetl'wsti s é~ st$bm ff lr\fra~ adfnfmstrétoretm (tzv.
~.gt;niha,r.'~,

'U Postupy ~ nf~ balíóků baµlat) OQ doaawhe kiJ tS/1CT a
aptlM$cí
wJ Pokyny pro ooklitdáru a :z-~ -chybových stavu a srt.uacr. k\eré
~ nastat, n~M, Jin.jeh Vjj~ podfT'»nek, kt.ef:é ~,
vzrnknol.lt pfl ~
i.ft ~ pro motnt.wovlflnf přístupů a &ntlSti užw~ ~

~.átmť.l
w>Pmvfdkl a po~ pro ~flf beizpeóno9« sfti ~ tJfaení prév.

ap~~ ~p.ečt\ý ~ 5i:teo/
y) Posupy a techfrlcká ~nf pro. ochranu !nf0rmaét1lhm proatředi a

lSltCT před iked11~ kódem ťnapf. servery . konc;ové stanice,
mob1mf~.s1tě)
l1 ~py GVldettoe a m;ěny évtdence ~ h 21ktiv. ta ~

odpov ídá, ~ sw sprilvě , ~ ~MQr IMCT
~ Prav«ít.a a ~ pro ~· bEi!i:~ ~ swieb.
~ a prevw ~ ~
ct} Pravda P ~ pro ~u sM a ~~ ~mtcll
zá2.ffll,mŮ
~~ a ~ p!!8.11idia ~ a ~ffl
kyb$mettcký.ch I.i~ ~ ~ Cl(~Mí ~%h
~1th-~ů.

ffi Pr~a a ~st;ttf)Y pro lnm-afsti. t«,:nftgtJ~i t~ch a:k:ti ··
~ystérr\O. ínfr~ruktury al zaň~
g~ Pravldia a postupy pro r$SQil't Mebo 0000\/00f chodl.l systému po

~~ a prn ,ošetřeni ~ ~o nwo ~~ jew:ů,
~ a I.RWFnČérn chadU· ~térrlu
m ~stl.ipy PfO ~ Bběru a ~ ~f fS/iCf,
čin:rwstf ~ a ~áte.1'.t
w ~ pra s~ ocnrarn. a 'v)'UŽ ltí ~ ~amů a lQgt,

5.lfCT
IISk) ~ pro ~ apr&-y k1H!ů a ~
~ ~ ~ ~ ~ánf $ ~ ~
mnit ~ pre ~ ~ ii o~ ~ l',}
im?~an;cn rw.troju pro zajit'tiní ~ Mffii.
~cié~
Ml P~ ij p09WpY pro ~sni ~dít po~ ~~
~~ p:rawiei u s!rlfflY IS&'~, ~ a o.sob

~~t~
-4.. Plény abnevy po h$várli {IT OFtflO
5. Plerty obt70YY kamUn4tt.y ~ ~ tBCP> nutnýdl .k ~
~- Sf'Ot (f'itAn ·~ čmQsti doda\7at~ ~ mťtnýd'I k·

~c~ sw1eb ~ ~~ w smk.}wět
e. Pw, rQZYQJe ~ pc.véctomi

,.
9. Zprá\.la e hoonocenf !fktw a t'gtk
13. -Evidence z.min
14. ~ kontaktnf ů(taje
15. Pfmltect ob.e-Oně z~ pnívn1d'l p.~sů. vntt:fnfcil p~sů a JmýCh

-~ a smt~-h $a~
a) T~itfl"raS\flŇll.WY .
b) ~ al&wých taf&!ffl-i,
Bezpečnostní dokumentace je velmi široké téma, při Jehož zpracování musí být
vzato v úvahu mnoho parametrů a mimo jiné musí být zmapována infrastruktura
zákazníka Proto zpracování bezpečnostní dokumentace zabere mnoho času a
Je nepoměrně delší než implementace ostatních řešení zmíněných v tomto
dokumentu. Požadavky na tuto oblastJsou uvedeny velmi detailně ve velkém
rozsahu. Pro vytvoření bezpečnostní dokumentace Je vyžadována součinnost ze
strany Objednatele, protože musí být vytvořená tak, aby odpovk:lala na míru
zákazníkovým potřebám (hlavně jeho provozu), zároveň rnusl reflektovat
všechna nařízeni a normy, a musí také brát v úvahu nařizeni, která teprve přijdou
v platnost Dokumentace počítá s promítnutim nejenom směrnic a pravidel. ale
i provozního know-how ze strany dodavatele.
Znalecký posudek č, 14/2/2019 104

OP0-39 Legíslatlvnf požadavky
~atQl :lajlstf M~ -~ P~tev&mtnfch techntci(ýd, a Ofga1'lli~

I psžadar·Jkťt ~ýctl ~ č. l'SV201:4 Slb„ o ~éli~ t,ea~
e (i& změr-lě St)~l"t t~ ~ o ~ ~ ~t - ~.
~OU ·82/2018 Sb,. O ~ ~h~ kygernetiekýc:ti

~ lflcidmteoh, ~Ch ~. ffiit0žlt05.t~ pg:ctar,t v
I t:Jbtast-i .kybemettcl'@ be:qJQčrto.atl a ~ dat ~ o kyb~
;.~et~ - ~v~ plamém pro tnformační sy!Rém výlnewnné
~mvas~.
R)s~l ~ ~ s ~ s Naff"zmftr\ -®J} 2016/679 ~ achraně
~~ asdb v souv,hilbJtt ~ :&pra~ ~fch ~ a e 'IOitlém po~u

těohte ~ a o ~ smimieG 0&146/ES ~ neft:zení o ochraniít
osobt4d'l úd@Ů }-00PR
~\tatet taše,ij es~ mroven z,ajtstt, že ~ sp~ bezpe~
pol&dswy. tJ. Je v ~ i bezpač~rnrn standa~ PCt oos ro O$ta

~ ~. všude tam, kse jsst.i. ZpracovéváAe, ~ anebe
UGhowwna -data o ~h pla1lebn{ch kartrt a kartovýc'A tr~Qtch Gde tf;dy
~ G ~ a't(t~ci Jt7latebnt karty, ~~~ Pftrt.tlaty

~ ~hi f ~él.Ske !Ub~ ~ci'l ~ é ~
~~~-
_PO DS6 ~vky' pdeit1 pro~ e~. ~~ .zprac~ a I
nebo Jlferájf!i data: drffieKI ~et. V~e ~ na t~ a~~
5~, kt9ťé Jseu ~f ~ ~ karét f1ébo jsols4 k nim ~Y
Pokud jaxékG.tw c;s&t ~ P~~ ~ l'\'eb-9 ur.noi:~ zprac.o\&éva-t

~-karty.~sp~-~PCt DSS,

l ~ at a udr'iov-a:t konfrg\Jr~ci f'lreWQttů k ocfitiiaoo dat dr~ karet. .
2. Nepouilvat výťlh~ ~i od ~ié pro ~á hes!:fi a. .}mé- I

~pečnoM panmaby.
4. Z~ovat ~ dat držftatť! ~ pe ot~ýéh-v~ých ~
& ~ vŠ$Chfl~ ~ -proti n-,at,,wa rea ~ ~ ovetootMmvý

~are nebo programy.
f, Om6!il.it fyzlt.ký ~=k~ dťEtt.el.ť! ~
10. ~ tt- m~ v~y pitm-w t< ~ ~~m ~ datí.sťn

~ 'kl,ret.
li1. fD'rwicte1ně t~ ~ $,'stértl;y s~ -
l2. Udd4vat ~ ~ na :lnfomlatro b@pečnest pro ~ -
L~·
Předpokládaný způso b řešení
Legislativní požadavky jsou dělené do několika skupin z nichž Jedna je
infrastrukturní část Infrastruktura pro provoz systému poptávaného typu by se
měla skládat ze špičkových komponent, které neobsahují žádné SPOF
komponenty a celé řešení musí být "fault toleranť. Toto musí být aplikováno v
každém typu infrastruktury, ať už se jedná o on-premise Instalaci a nebo cloud
(hybrldnL privátni či veřejný).

Deta ilní požadavky se vážou na provoz systému a Jsou součás tí řešení
příslušného požadavku.
2.7.3. Výkonnostní požadavky
OP0-50 Ověřování výkonnosti
r----------
~lmusfptovést~ ll ~~ a~ ~y
• .a sou~ pro ~ a tt\~ ~ Systému trati ~
~ mů!e ~• ~ F~ě:né ti8tť etl1Snoo opa~ v
~ pre.NG:IU v mmlméln.ím ~ S měak;ú, ~é ~nf~
ot:t~e výkot1rr1~J9Q'U ~typu c.
I~ ~jQ~ v Mvmt.l 3rn!al,Wy
Pfedpohládaný způsob řešení
Výkonnostní a zátěžové testy budou provedeny jak na aplikační vrstvě, tak i na
Infrastrukturní vrstvě.
V případě infrastrukturní vrstvy musí být Infrastruktura nakonfigurována tak, aby

vyhověla požadavkům, které jsou definovány objednatelem. Příprava
zátěžových testů se bude skládat z vytvoření testovacího scénáře a jeho
následného ověfení.
Na nejnižší vrstvě. tj. datového úložiště, bude ověřena výkonnost pomocí
nástrojů pro měření propustnosti diskových polí. Budou změřeny IO operace,

zda odpovídají standardům, které Jsou dané pro aplikace obdobného typu.jako
je IS EDAZ. Výkonnost datového úložiště musí dosahovat minimálně 250 000
IOPS při náhodném čtení a zápisu uložených dat v poměru 60:40 (čteni-zápis).
Celé řešení musí být fault tolerant a pokud dojde k výpadku Jednoho řadiče
Znalecký posudekč. 14/2/2019 107

nesmí poklesnout výk onnost celé aplikace. Architektura řeše ní musí být
navržena tak. aby přf výpadku virtuallzačního hostu byla aplikace nadále funkční
a uživatel tak ne:zaznamenal výpadek. Tato vlast nost bude zajištěna nejen
správným návrhem plně red undantního hardw are, ale také korektním návrhem
vlrtu allzační vrstvy, která v takovém případě dotčené vlrtuálnf servery přesune,
či přepne na Jiné vlrtuallzační hosty a výpa dek nebude znamenat nutnost :zásahu
ze strany provozovatele aplikace. Platform a musí být navržena tak, aby ji v
případě x86 architektu ry bylo možné provo:zovat nezávisle na výrobci hardwaru.
Ce lkově bude posuzováno ověření výkonnosti spíše z pohledu aplikace, kde se
měří její celková odezva a Je na Poskyt ovatell,Jak zajistí po žadované časy odezvy
aplikace.
2.7.4. Provozní požadavky
OP0-52 Archivace dat

---------------------------------
SVS1ém bude mU ~modul~. ktet-y \ffi'reliffi nammNtt ~é

~ c:tf-h ~~ pQdi~ ~ ~rO@ •erl"lfho ~
~ ~ uWédan á dQ- ~nlw ~ ~ ~•ání m.idGu mptt~ _
: W!-ovené JI$ ~mým~ pro 0f'Chi\/€ici .®dffliR'ýffiod~ kliéGl){'o
-~data.
Nedílnou součástí práce s daty je l Jejich archivace, V některých případech Je
archivace předepsána zákonem, nebo slouží Jako prostředek k redukci nákladů
za uložená data na hlavním úložišti a v kombinaci s garancí pravosti a také co by
ochrana společností v případných soudních sporech.

Na rozdíl od zálohování. kde se pracuje se sekundární kopií dat a data primární
jsou stá le zpracovávána a modifikována, archivace pracuje s prlmárnimi daty,
kterájsou. dle definovaných pravldel, přesouvána do archivu a dále se nemění.
Například archivace projektu po Jeho dokončeni. Data Již není zap otřebí ukládat
na výkonná disková pole, není zapotřebí zá lohovat jEajlch změny a udržovat
okamžitou dostu pnost dat. Větší důraz je kladen na zajištění autenticity a
neměnnosti a na dlouhod obou čitelnost a srozumitelno st archivu.
Dlouhodobá čitelnost neznamenájen dlouhou životnost méd ií. ale i archivaci dat
v takovém tvaru, aby Je bylo možné i po dlouhé době Interpretovat. Například

přečíst deset let staré soubory databázového systému nenítakjednoduché,jako
jejich export do XML
Srozumitelnost archivu závlsi na správné organizaci archivovaných dat. Jejich
vhodného popisu čl Jiných metadat. Archivované záznamy, např. SPZ Jsou bez
vhodné indexace sice čitelné, ale dohledání konkrétního záznamu může být bez
vhodných metadat obtížné,
Archivace tedy spočívá v přemisťováni předmětných dat mezi určitými
rychlostními hladinami datových oblastí. Jakožto nultou úroveň lze považovat
oblast rychlých pevných disků. Nevýhodou je jejich poměrně vysoká cena a
proto omezená kapacita. Proto dochází u dat. jejichž priorita Již nedosahuje
nejvyššího stupně k takzvanému přesunu na vyšší úroveň. Sem se data umlsťL!Jf
na delší období s nižšími náklady. Základním kritériem pro přesun dat na vyšší
úroveň Je odhad, jak často budeme s daty manipulovat - čím méně, tím vyšši
úroveň je přiřazena. Pokud tedy časem budeme se souborem chtít pracovat.
bude muset být nejprve nalezen na příslušné vyšší hladině, vhodným způsobem
přesunut na hladinu nultou, tedy systémové pevné disky, a zde s nímJiž můžeme
libovolně pracovat Aby mohl být soubor efektivně nalezen, jsou vytvářeny
takzvané katalogy. Ty uchovávají informaci, kde Jsou soubory umistěny
Znalecký posudek č. 1.4/2/2019 109

Archivace dat je vhodné rea lizovat pomocí specializovaného softwa re, který Je
schopen archivovat data na externí úložiště spo lečně s archivačním příznakem
a vy hovět tak zákonným poža davkům, které Jso u kladeny na tato řešení. Jed ná
se zejména o nemožnost smaz at data před expirací archivačního příznaku.
Podobná řešení se zakládají většinou na archivační appllance, která je kombinací
spec ializovaného hardware a softw are. Tato řeše ní se skládají ze storage části,
která chráni data standardními mec hanismy pro ochranu diskového prostoru
typ u RA ID a z procesní čás ti, která obsa ht.{ie spec ializovaný software pro
archivaci dat a spo lupráci s dalšími systémy a proces y. Archivační so ftw are
většinou obsahuíe komunikační APi, které bude Integ rováno s osta tním
softwa rem, aby mohlo dojít k automatizovaným úkonům, které nebude nutné
ručně ovládat. Implementace tohoto řešení není náročná a pro větší projekty
tohoto typu se pohybuje v řádu nlžšfchjednotek týdnů.
Provoz archivačního řešení
Provoz archivačního řešení Je kontinuální službou, která Je Integrována do
všech důležitých systémů. aby archtvace dat probíhala automaUzovaně a
hlavně kontinuálně a vyhověla tak všem požadavkům, které Jsou na toto
řešení kladené. Při provozu archivačního řešení sejedná o kontinuální dohled
nad archivační službou, který zabezpečuje bezproblémový provoz a
predikuJe vývoj v rámci archivace dat. Provozovatelje tak schopen dopředu
reagovat na příchozí situace (napřfklad náhlý enormnf nárůst dat) a řešit
možný problémještě před jeho vznikem. Provozovatelje zároveň schopen

pomoci s případnou Integraci archtvačního řešení do nově vznikajících
systémů, čl nových komponent stávajícího systému. Provoz může být
realizován Jak na klasické HW appllance, která se vyznačuje modularitou
celého řešení, protože HW vrstva je nezávislá na software na nf běžící (a
naopak) a/nebo na specializovaném řešení. které bude provozováno jako

hotový ,box" řunquilcl Jako archivační Jednotka. V případě appllance může
dohledový operátor modulárně zvyšovat kapacitu celého řešení dle potřeby
a předejít tak případnému zaplnění datové vrstvy archivačního řešení. U HW
boxu sleduje aktuální stav HW a při zaplnění rozšíří kapacitu přidáním dalších
pevných disků, či přidáním celých rozslřullclch boxů ke stávajíc!mu HW boxu,
které obsahují jednotllvé sloty pro pevné disky a většinou Jsou již pevnými
disky osazeny. Provoz Je tak dostatečně zabezpečený a pod dohledem a
splňuje tak nejnáročnější požadavky, které Jsou kladeny na dlouhodobou
archivaci dat
Provoz systému
Předpoklódaný způsob řešení
Provoz systému se skládá z mnoha částí, které Jsou realizovány pomocí
odlišných týmů. Pro korektní provoz systému je nezbytná implementace
monitorovacího řešení. které bude nedílnou součástí provozu celého řešení..
Protože je primárně monitorovaná dostupnost systému jakožto aplikace, tak je
na dodavateli, aby sestavil svůj tým tak, aby byl schopen obsáhnout celé řešení.
Celý systém musí být postaven tak, aby většina incidentů nebyla vážného
charakteru a nezpůsobila výpadek celé apUkace, čl kriticky důležitý komponent
To je možné docílit granularitou celého řešení a fault tolerant komponentami.
Provoz celého řešení se bude skládat z Windows čl Linux operačních systémů,
kde bude nutné zohlednit veškeré Licenční náklady, které se týkají provozu
tohoto řešení, např. uživatelské CALy, devlce CAL, apod. V případě aplikačnřho
řešení tohoto typu bude vyžadováno alespoň 40 virtuálních OS pro produkční
prostředí. které se bude skládat z frontendových serverů pro weblnterface a
loadbalanclng, aplikační servery, databázové servery, management prostředí a
vývojové komponenty, a alespoň z 40 virtuálních OS pro předprodukční

prostřed í. V připadě produkčního a předprodukčního prostředí je HW i SW
konfigurace zcela totožná včetně red undance, aby testování v předprodukčnfm
prostřed í od po vídalo reálnému provozu, a bylo tak možné používat různé
testovací scénáře, které prověř! následný provoz. Nižší počet virtuálních strojů
bude nutný pro provoz testovacího prostředí, a to alespoň 20 . Testovací
prostředí určené na vývoj je totiž zpravidla poloviční. protože nejsou kladené

nároky na redundanci tohoto prostředí, proto stačí single Instance Jednotlivých
systémů. skladba jednotlivých serverů Je stejná mimo redundanci a v případě
potřebyJe možné sdružovat některé servery dohromady. Všechna tato prostředí
je nutné provozovat, zallcencovat. monitorovat a zálohovat
Kapacita potřebná k ukládání provozních dat a pro archivaci a zálohování bude
několik stovek terabajtů dat Data určená pro provoz budou v obdobné veLikostl.
Stanovení ceny provozu doporučujeme pro transparentnost rozdělit do ceny za
1 operační systém. který v sobě bude zahrnovat veškeré poplatky za HW, SW,
Licence, ceny databáze a provoz najeden měsíc.
Všechny systémy Je vhodné průběžně udržovat za pomocí centrálního patch
managementu, který Je součástí cenové kalkulace zajeden OS. V rámci provozu
bude nutné sledovat aktuální bezpečnostní hrozby a Jejich mltlgace bude
promitnuta do aktuálniho provozního plánu.
V rámci služby Provoz Je zajišťováno. aby Informační systémy a Jejich
Infrastruktura byly dostupné, připravené pro použiti a funkční v souladu s
dohodnutými parametry Service Level Aqreernent (SLA). Součástí služby by
měly být následujfcí činnosti:
• Pravidelné a ad-hoc provozní činnosti
• Správa uživatelů Informačních systémů
• Monitoring
• Správa serverů
Znalecký posudek č. 14/2/2019 1U

• Správa databází
• Správa sítě, firewallu, antivirové ochrany
• Správa komunikace a konektivity
• Insta lace a konfigurace nových verzí SW
• Správa a údržba hardware
• Zálohování a obnova dat

• Pravidelné profylaxe
• Schopnost predikce v rámci celé Infrastruktury
• Sestavování souhrnných reportů za kvartál kde se řešf, Jak proběhlé
incidenty, tak věci budoucí, které byly odhaleny v rámci precfl kce.
Všechny výše vyjmenované činnosti se t.ykaJí Jak on premise, tak cloudového
provozu celé Infrastruktury.
Systém pro podporu provozu
Při provozu Informačního systému musí být dostupný i systém pro podporu
provozu a pro komunikaci a řízení nastalých situací v nepřetržitém provozu a
tzv. end-to-end monitoring poskytovaných služeb, dohled hardwaru, fyzických
a virtuálních operačních systémů, databází. aplikací I okolního prostředí. Na
základě Informaci přenášených do dohledového střediska s provozem v režimu
24/7/365 a v závislosti na kritičnosti událostí by se měla aktivovat odpovídajícÍ

podpora.
OP0-59 Návrh Implementace
1 ~ .l>udw ~~etelr!é 8 bUdoo mlt yYl'IOkmi de~ - ,tráfy I

adatv~~-
... ~- •• •• ---. ~ ,. "'->- ···• -~ .

Neuz avfené I nep~ trenaak-ce moheu být 2:'l:raoony s tim, )8 umva~
budGl- .upoi:er~n rra hedei'kon~.v amiVJw a vy.t\®'1 k~~
Předpokládaný způsob tešenl
Návrh Implementace je vhodné rozdělit na několik kroků. které následně
usnadní celkovou Implementaci řešení a zrychli celý Implementační proces.
Budou vytvořené šablony pro základní operační systémy dle Jejich určení, které
pak budou rozkopírovány pro účely provozu celého aplikačního řešeni. Na
těchto v šablonách bude proveden hardening operačních systémů a tfm bude
zajištěno, že systémy budou aktuální včetně všech bezpečnostních aktualizací a
budou korektně nastaveny. Implementace bude probíhat dle předem
navrženého projektového plánu a bude v sobě zahrnovat všechny výše popsané
kroky. Vše by mělo být vypracováno do technického projektu kde bude vidět
návrh nastaveníjednotlivých OS.jejich hardening a nastavení dalších použitých

operačních systémů.
2.8. Stanoveni ceny obvyklé
Tato kapitola obsahuje určení ceny obvyklé všech částí dodávky dle struktury
určené v kapitole 2.3. Metodika určení ceny obvyklé.
Společná legenda k tabulkám:
■ Modře podbarvené údaje - vstupni údaje a parametry, které se objevuji
poprvé jako vstup a n~sou odvozené zjlných údajů:
• Podbarvené údaje - klíčové výstupy.

2.8.1. A. Vytv oření Dlla - IS EDAZ
Určení celkové ceny implementace a zavedení IS EDAZ vychází ze stanovení
složitosti Implementace, která vyplývá z kapitoly 2.6.2. Klasifikace požadavků.
Následná tabulka obsahuje odvozeni stanovení ceny, Jednotlivé kroky odvození
Jsou popsány v legendě pod tabulkou.

# MD -
-
#1 Jlp~ _ -- --
~e~;,:::.~mptementačnlho vývoje
-~
L _
~ametr
-
l ~31
Odvozené odhady (základem

Implementační vývoj)
---- - --
#2 Analýza - --
30% 429
#3 Testy 35% 501
#4 Konřlquračru manaqement 15% 215
#5 Dokumentace 30% 429
~
#6 Mezisoučet (#1 • #2 - #5) _J_ Tioos
#7 Management (Základem #6 objem
výkonné činnostD l 20% 601
#8 Implementace funkčnfch požadavků 3,606

ceU<em (#6 • in
Další položky vyplývajlci z projektového
postupu
#9 Demoverze 200
#10 Podoora bezpečnostních testů 80
#11 Miqrace 100
#12 Zkušební provoz 270
-
#13 Záruka (základem #1 rozsah 20% 290
implementace)
Cenaff<č)
#14 VývQJ a mvedenf 0l!Mkem (#6 • p1 ~• #13) 4.548 56.734.080
li!~ I Průměrná sazba - Kč/ MD I 12.~

Rlzfko a;;!.:..-.... ,;- zisk- ""'T"'_,.; odhad
#16 Riziko (zákla dem celkový odhad Vývoje a 30% 1364 17.020.224
zavedení #14}
#17 CeUcevý součet spodnl edhad (#l4 + #11 5.910 73,754.304
+#ln
Rlztko a pt.:.. ,., --nÝ zisk - hernf odhad

#18 Riziko (základem celkový odhad Vývoje a 60% 2.728 34.040.448
zavedení #14}
#19 Celkový součet homl odhad (#14 + 7.274 ,o.n4.528
#19• #20)

Legenda
#1 - MD náročnost implementace určená v kapitole 2.6.3. Implementační
složitost dle modulů a komponent, výchozí údaj pro celý výpočet
#2 - Analýza (a design) odvozena poměrem 30 % z #1 Vychází z úvahy, žeJeden

analytik obvykle zvládne připravovat zadání pro tři programátory.
#3 - Testy. Příprava testů vychází z výstupů analýzy a implementace, takže 35 %
z objemu implementace pro přípravu a provedení testů Lze považovat za
přiměřený. i když spíš konzervativní.
#4 - 15 % z objemu Implementace Je stanoveno pro průběžnou konfiguraci
prostředí (vývojových. testovacích, produkčního). Vzhledem k poměrně
ambicióznímu harmonogramu je nutné předpokládat vyšší míru paralelního
vývoje, a s tím spojených vyšších nákladů na konfiguraci, proto Je koeficient
stanoven výše než obvyklých 10 %.
#5 - 30 % z obJemu Implementace pro vytvoření dokumentace Je stanoven nad
obvyklejší míru 20 %. Koeficient je zvýšen kvůli náročnějším požadavkům na
dokumentaci (viz kapitola 2.11 podkladu 13.2. Smlouva-Prítoha.L část 2. Obecné
požadavky - Systém EDAZ), zejména pak požadavek na Exit dokumentaci (viz
kapitola 2. 14 podkladu 1.3.2. Smlouva-Prlloha_l, část 2. Obecné požadavky -
Systém EDAZ>.
#6 - Mezisoučet #1- #5 - .výkonná činnost'.
#7 - Management- 20 % z #6 - Jeden manažer řídí 5 osob.
#8 - Součet #6 a #7 - Implementace funkčních požadavků celkem.
#9 - Náklady spojené se specifikací, konsoUdací, vydáním. podporou.
konzultacemi s klíčovými uživateli a zpracováním zpětné vazby. Stanoveno
paušálně na činnost 5-tl osob po dobu dvou měsíců. Tedy 5 x 2 x 20- 200 MD.

#10 - Náklady spojené s podporou nezávislých bezpečnostních testů
zpracování jejích výsledků. Stanoveno paušálně na 2 osoby po dobu dvou
měsíců, tj2 x 2 x 20 - 80 MD.
#11 - Migrace - činnosti spojené s konfiguraci systému a Jeho zavedení do
provozu, stanoveno na 100 MO.
plo j Zkušebni provoz. Vzhledem k tomu, že není blíže specifikováno,
předpokládáme stejný režim provozu jako produkční. Podle harmonogramu
v podkladu 13.3, OO-Doplnenl-20191127 - Doplněni požadavků SFDI. Kapitola 7.
Harmonogram realizace má zkušební provoz trvat 11 týdnů. Podle odhadu
v následující kapitole je týdenní odhad MD zajištění provozních služeb 24,8 MD,
tedy pro jedenáct týdnů po zaokrouhlení 270 MD.
#13 - Záruka. Rezerva pro pokrytí záručních oprav, 20 % z rozsahu
Implementace #1.
#14 - Vývoj a zavedení systému celkem, tj. součet #8 až #13.
#15 - Průměrná sazba určená v kapitole 2.5.3. Přehled a průměrná sazba.
#16 a #18 - Odhadovaná rizika (neúplnost zadání, rizika implementace,
Integrace, součinnosti) - 30 % pro spodní odhad, 60 % pro horní odhad.
#17 a #19 - Výsledná cena - spodní a horní odhad.
2.8.2. B. Provoz IS EDAZ
Pfedmětem provozu je podle podkladu 13.2. Smlouva-Prlloha_l, část
3. Požadavky - Služby provozu a technické podpory zejména zajišťování
dostupností, a dalších provozních parametrů dle katalogových Listů v provozním
režimu 24/7. Dále pak profylaktické a konfigurační činnosti.
Doba poskytování služby jsou 4 roky.

Pro účely stanoveni ceny obvyklé je servisnl režim nastaven následovně:
■ Pracovni dny 8 hodin čtyři osoby on-slte.
■ Zbývajíci doba vzdálená pohotovost Iniciovaná automatickými alarmy
monitoringu systému, případně Call centrem či Servlce deskem
Objednatele. Předpokladem je umožnění vzdáleného přístupu k systému.
Cena za pohotovostje stanovena jako 30 % standardní sazby
Komponenta swžby Hodin MD Role Cena Cena

týdně týdně cetk9mod oetkemdo
{Kč) ff<č)
Vedoucí Provozní podporv 8/5 40 ... 5 PMS 14.768.000 16.848.000
Provozní podpora v režimu 8/5, 80 10 PSS 22.880.000 27.040.000
senior 2x
Provozní podpora 8/5, iunior 40 5 PSJ 7.280.000 9.360.000
Pohotovostní režim - hotline 38,4 4,8 PSS 10.982.400 12.979.200
(mimo pracovní dobu): 16/5 +
24/2, (168 - 40) X 30%
ceLk&m 198,4 24,8 11.QlOAOO 66.227.200
Níže je uvedena tabulka se zařazením rolí do kategorií (viz kapitola 2.5.3. Přehled
a průměrná sazba}.
Kód Role Kategol1&

PMS Proíektovv vedoucí servis Senior
PSS Seniomí pracovník servisu Standard
PSJ Juniomi pracovník servisu Junior
2.8.3. c. Zff zenf služeb platformy
Cena zřízení služeb platformy Je stanovena na základě odhadu složitosti Jejího
návrhu, zřtzení, konfigurace a otestováni.
Zúčastněné role:
• Architekt - kategorie Senior stfední odhad ceny 15 200,- Kč / MO
viz kapitola 2.5.3. Přehled a průměrná sazba.

• Podpora - kategorie Standard střední odhad ceny 12 000,- Kč / MD
víz kapitola 2.5.3. Přehled a průměrná sazba.
• Administrátor Infrastruktura - kategorie Junior střední odhad ceny 8 000,
Kč I MD viz kapitola 2.5.3. Přehled a průměrná sazba.
Oblast Popis Role MO Cenaod C&nado

h<čl IKčl
Podpora Návrh sltě na základě běžně Architekt 8 113.600 129.600
zabezpečení apUkovaných Administrátor 20 140.000 180.000
sítě bezpečnostních zásad při Infrastruktura
vytváření jednotUvých
síťových segmentů.
Sít bude segmentována tak.
aby od sebe byly oddělené
veškeré dúležtté datové toky
I
a nemohlo tak dojít ke
vzájemnému ovl.l\/něn/, čl
zahlceni.
Monltorng Implementace monitoringu v Architekt 1 14200 16.200
rámci SNMP protokolu, který Administrátor 6 42.000 54.000
je přímo specifikován pro infrastruktura
sběr Informaci o stavu
jednollivých systémů, čl
zafízeních.
Bude zajištěn sběr
provozních dat přes SNMP
v3 do centrálního syslog /
SIEM serveru a následné
vvhodnocování stavu.
Zálohování Návrh zálohovacího Architekt 4 56.800 64.800
schématu, který bude Administrátor 6 42.000 54.000
odrážet použité technologie, Infrastruktura
operační systémy, databáze
a bude zaručovat konzistenci
takto uložených dat
Jedná se o Implementaci
zálohování pro cca 50
virtuálních OS, DB a tomu
přiřazených systémů.
Implementace bude
obsahovat otestování
veškerého nastavení a
prověřeni správné obnovy ze
záloh.
Defnlce zálohovacích polltlk
a Procedur, včetně
Znalecký posudek č. 14/2/2019 l20

Olidast I Popis
obnovovacích scénářů,
Role MO Cena od
U<ěl
cena do
IKčJ
definice pravidelného
testování záloh, vytvoření
Jednotlivých poLitik a retencl
Šifrování
- Nastavení šifrování dle Architekt 6
-
85.200 97200
doporučení z
https://www.govcert.cz/cs/
doporucenl-v- oblasti-
kryptog rafickych-p rostredku
, včetně nastaveni
granularity oprávnění pro
možnost definice
jednotlivých úrovní přístupů,
pro dešifrováni pouze
vybraného obsahu. Včetně
certiflkačnfautority.:_ --
Bezpečnostní Systém bude obsahovat Architekt 4 56.800 64.800
dohled bezpečností mechanismus a Administrátor 4 28.000 36.000
dohled nad črmostl v infrastruktura
dodáveném systému
schopném detekovat
anomáUe chování a bude
umět vyhodnocovat
bezoečnostnl Incidenty.
Bezpečnostní Zpracování a vytvofení Architekt 120 1.704.000 1944.000
dokumentace bezpečnostní dokumentace
a provozní dokumentace v
souladu s požadavky ZoKB a
VoKB dle požadavků v
Legislativní
-- říloze č. 5 VoKB.
Legislativní požadavky dle Architekt 4 56,800 64,800
požadavky dokumentace vztahující se Administrátor 6 42.000 54.000
hlavně na infrastrukturní Infrastruktura
čéstí.
Návrh konfigurace FW a Jej!
aollkace.
ověřováni Příprava zátěžových a Architekt o 85.200 97.200
výkonnosti výkonnostních testů pro Administrátor 2 14.000 18.000
vyhovění požadavků na Infrastruktura
dobu ode-zvy celého
systému
Týká se pouze infrastrukturní
části.
Archivace dat Vyhovění požadavků na Architekt 6 85.200 97.200
archivaci dal data budou Administrátor 8 56.000 72000
ukládána do samostatného Infrastruktura
úložiště včetně šlfrovaclho
klfče. lm~lementace

Oblast I Popi s Role
-
,eenaoo
[KčJ
1Ce~de -
D<t:J
archivačního mechanismu
bude včetně archivačního
příznaku a z toho plynoucfch '
Návrh
-
mechanismů.
Bude vytvořena instalačn I
-
Architekt 4 64.800
implementace Image a ta bude následně Administrátor 6 -~
42.000 54.000
využita pro instalaci Infrastruktura
jednotlivých virtuálních
strojů
Následná Instalace 100 Administrátor 24 168.000 216.000
virtuálních OS Infrastruktura
J
Bezpečnostní Součlnnost při Podpora 4 44.000 52.000
testy bezpečnostnich testech,
které bude reaUzovat
odborná tfetí strana
---
Výkonnostní Součinnost při Podpora 4 44.000 52.000
testy výkonnostních testech, které
bude realizovat odborná třetí
strana
Celkem lm~ lnfrastruktwy 253 2.971.500 J.48!.800
2.8.4. D. Služby platformy
Stanovení měsíční ceny služeb po dobu poskytování služeb platformy v délce
52 měsíců.
Oblast Popls Typ MO CenaodQ(č) Cenado(Kč)

polož1<y
arote
Monitoring Provoz monitoringu na sw 30.000 35.000
měsíční bázi s predikcí
provozního stavu
Stanovení vychází z ceny
obvyklé za provoz
monitorovacího řešení
pro cca 100 aktivních
zařízeních.
Zálohováni Provoz zálohovadho sw 60.000 65.000
software pro on premise
a cloudové řešení.
--- - ~ --

Oblast Popfs Typ MO Ceneod fl<č} Cena do (Kč) I
pelolky
č1 ro\e
Zálohování Provoz zálohování a Podpora 2 22.000 26.000
pravidelné testování
zálohovaných dat dle
~notg~scénářů. -
Bezpečnostní Systém bude obsahovat sw 190.000 240,000
dohled bezpečností
mechanismus a dohled
nad činností v
dodávaném systému
schopném detekovat
anomálie chování a bude
umět vyhodnocovat
bezpečnostní incidenty
Provoz software pro
sledování chování přes
RDP a SSH sessions.
Cena je odhadnuta za
produkční prostředí 40
virtuálních strojů včetně
Jump serveru pro
případný servis. Dále Je
do kalkulace započítáno
SIEM řešení.
- - ,-
Bezpečnostní Pravidelný dohled nad Podpora 2 22.000 26.000
dohled bezpečnostními
incidenty a reakce na
aktuální hrozby
Legislativní Legislativní požadavky Podpora 2 22.000 26,000
požadavky dle dokumentace
vztahující se hlavně na
infrastrukturní části.
-
Archivace dat Provoz archivačního sY1./ 90.000 130.000
řešení v rámci vyhovění
požadavků na OP0-57 a
pokryti archivace
požadovaných datových
částí. Stanoveno dle
běžně dostupného SW
na trhu na bázi
měsíčního předplatného.
- - -- -

-- ----,
Oble.t Popis Typ I
MO Cena od ťKe> Cena do {Kč}
p&lc>~ I
č1 rote
Archivace dat Provoz archivačního Podpora 41 44.000 52.000
řešení v rámci vyhovění
\
požadavků na OP0-57 a
pokryti archivace I
požadovaných datových
částí.
Jedná se o údržbu
archivačního řešení.
kontrolu funkčnosti,
patching řešeni,
implementaci a úpravu
arch ivacfjedn ollivých
I
- částí oožadavků.
Provoz Předpokládaná cena pro HW 700000 760.000
systému provoz 100 virtuálních
operačních systémů za
měsíc včetně licencí za
operační systém a
licencí za DB svstémv
Provoz Provoz za storage vrstvu HW 470,000 510,000
systému Celková kapacita je
stanovena na 160TB dat
v SSD. KonektMta přes
FC. Cena započítána
včetně SAN switchů.
... Storace včetně Licencí.
Návrh Měsíční údržba 100 Podpora 40 440.000 520.000
Implementace virtuálních OS
souvisejících s provozem
a souvisejících
komoonent
Celkem provor: / mi8fc Z,090.000 2.390 .000
Cena celkem za 62 měsrct& provozu 108.580.000 124.2:SC).000
2.8.5. E. Rozvoj, konzultace a další služby
Předmětem je poskytnutí 2 000 MD pro .rozvoj IS EDAZ. konzultační služby a
další činnosti·

Způsob poskytování této služby je popsán ve Smlouvě v 8. ZPŮSOB
POSKYTOVÁNÍ ROZVOJE, KONZULTACf A DALŠÍCH SOUVISEJICÍCH SLUŽEB.
l(ategwle Cena/M O I Cena/MD

od do
I Z astoeupenl MO Cena od
(Kč)
Cenado
(Kč)
Senior 14,200 16.200 50% 1000 14200,000 16,200.000
Standard 11000 13,000 40% 800 8,800.000 10.400,000
9,000
- 1800,000
Junior 7.000 10% 200 1400.000
Ceikem I I I 24.400.000 28.400.000
Pro určení ceny obvyklé byly použity sazby stanovené v kapitole
2.5. Kategorizace rolí a cena za MD.
V rámci průběžného rozvoje převažuje zpracování spíše požadavků menšího
rozsahu, které Je ale nutné bezpečně integrovat do běžícího systému. S každou
změnou nelze vždy provést kompletní testy celého řešení, respektive by to bylo
velmi neefektivní a neúměrně by to zvyšovalo cenu implementace menších
změnových požadavků. Proto je oprotJ rozložení týmu pro implementaci
navýšeno zastoupeni seniorních zdrojů ze 40 % na 50 % na úkorjuniomích zdrojů.
To zajistí vyšší efektivitu a bezpečnost provádění změn.
Riziko není ve stanovení zohledněno: bude stanovováno až přl realizaci
požadavků v rámci plněnl
2.8.6. F. Dalšl provozní činnosti
Tato položka zahrnuje Poskytování služeb Call centra, zpracování Listinného
podání a zajištění .obchodních" aktivit po dobu 48 měs/ců, viz kapitola 2.3.
Metodika určení ceny obvyklé. Důvodem spojeníje, že lze předpokládat využití
synergie těchto činností. Tyto činnosti lze společně řídit a Je možné sdílet i
pracovníky v rámcljednoho poolu pracovníl<ů. V připadě provozních anomálií lze
tak lépe zvládat špičky.

KUčovou službou z pohledu rozsahu Je Call centrum, následující tabulka
obsahuje určeni potřebné maximální a průměrné kapacity Call centra. Pod
tabulkou je uveden postup odvození.
l
# Popis metriky !Rok ~ Den Hodina
Vstupní Informace
- -- -
#1
#2
Počet úhrad celkem (špičková
hodnota)
Počet úhrad e-shop (40 % ze všech
± 7.000.00
2.800.000
1100.000
440.000
- --
prodejů)
#3 Poměr vhledem k časovému 12 30 24
intervalu vlevo
Odvozené údaje
#4 Počet úhrad odvozený průměrným 14.670 1.039
rozložením ze špičky v, ššl iednotk„ -
#5 Koeficient zohledňující špičky 1.89 1,70 1,90
#6 Špička 440.000 24.933 1974
'#7 Počet havorQ (,špička) prt 44.000 2.4"3 197
pf- . . _,_ -~ -- ·--::~t 10 %
Kapacita Cali centra
-
#8 Průměrná doba hovoru (sekundy) 160
#Q Potřebný počet ope,étorO. pn, 8,2
mmdmáJ.n f h~zá\H
#10 PrťJměmý počet q,erátonl - pro j, IJ
ši,,lčkOvÝ měek:
#11 Hypotetická kapacita CaU centra 86.400 2.880
(průměrný počet operátorů)
Legenda
#1 - Počet zakoupených časových známek Skutečné historické údaje
poskytnuté Objednatelem, viz podklad 13.19. 07-Pocty_uhrad. Údaj za celý rok
a maximální měsíční hodnota.
#2- Odhad počtu úhrad prostřednictvím eShop - 40 % z #1 Jedná se o odhad
Objednatele, viz 13.3. OO-Doplnenl-20191127 - Doplnění požadavků SFDI,

Kapitola 4 Provozní požadavky.

#3 - Poměr pro převod počtů obchodů z měsíčního Intervalu na denní a
hodinový.
#4 - Prostý (rovnoměrný) převod počtu obchodů ze špičkové hodnoty hrubšího
časového intervalu. Vstupem je tedy údaj z řádku #6. Tedy pro výpočet údaje
pro den je použita hodnota 440.000 (špičkový měsíc) a pro hodinu 24.933
(špičkové hodnota dne).
#5 - Koeficient zohledňující šplčky. Pro převod z roku na měsíce je vypočten z
reálných dat poskytnutých Objednavatelem (12 x 440.000 / 2.800 000). Pro
převody měsíc- den a den - hodlnaJe odhadnut tak, že:
• špičkový měsíční počet obchodů může hypoteticky proběhnout za 18 dni:
• špičkový denní výkon může hypoteticky proběhnout během 13 hodin.
#6 - Historické (měsíc) a odhadnuté maximální počty obchodů pro Jednotlivé
časové Intervaly.
#7 - Odhad počtu hovorů Call Centra. Odhadnuto Jako 10 % transakcí, na základě
odhadu poskytnutého Objednatelem, viz 1.3.3. OO-Doplnenl-20191127 -
Doplnění požadavků SFDI. Kapitola 4 Provozní požadavky.
#8 - Odhad průměrné délky hovoru. Vzhledem k tomu, že samotný nákup není
příliš složitý. Lze předpokládat. že drtivá většina dotazů bude řešit standardní
situace.
#9 - Na základě odhadu počtu hovorů a jejich délky je vypočten nutný počet
operátorů pro špičky.
#10 - Průměrný počet operátorů je stanovena tak, aby byla bezpečně zajištěna
denní zátěž.
#11- ověření správnosti nastavení průměrného počtu operátorů.

Závěry pro Q_astav~ní ~cip~city_C~LL centra:
• Maximální kapacita pro špičky je odhadnuta na 9 osob.
• Průměrná kapacita 5 osob.
Poznámka: z #U vyplvvá, že průměrná utilizace v rámci městce je kolem
50%
• Je nutné předpokládat vyšší zátěž Call Centra v době zavádění systému.
Navíc systém bude zaváděn v období maximálních prodejů. Proto Je pro
období prvních 6-tl měsíců navržena navýšená kapacita Call Centra
030%.
Kaµacita pro další činnosti
• Zpracován! listinných podáníJe odhadnuto najednu osobu v režimu 10/5,
pro období zavádění navíc osoba v režimu 4/5.
• "Obchodní aktivity" Jsou odhadnuty na Jednu osolJu v režimu 4/5 + 2/2,

pro období zavádění navíc osoba v režimu 4/7.
Stanoveni ceny Dalších provozních činností
Znalec níže uvádí MD sazby relevantních rolí a způsob určení.
l(ód Role MO od (Kč) MOdo(Kt)

CCM Vedoucí Cali centra 10,000 11000
CCl Pracovník Call Centra, provozní činnost. 4.500 5.500
senior - '-
CC2 Pracovník Call Centra. provozní činnost, 3.500 4,500
junior
Jako zdroj pro určení sazeb byl použit podklad 13.22.
Prehled_cen_lCT_pracl_201905, dále .Přehled cen"

Vedouci Call centra
Jedná se o kombinaci řídfcí a odborné role. Pracovník organiz4le chod Call centra
a zároveň upravuje metodiku a pracovnf postupy. V Přehledu cen vycházíme z
typu práce .speclallsta" (medián 10.000}, relevantní štítky (viz str. 13 Přehledu
cen) jsou Vedoucí, provoz, senior a řízení služeb - medián 8.400 - 12.000.
Na základě těchto údajů bylo stanoveno rozpětí ceny za MO pro roU Vedoucí
Call centra na 10.000 - 11.000 Kč.
Řadový pracovník Call centra
Jedná se o rutinní činnost. která je rozdělena do dvou úrovní:
• CC1 - senior - Komunikace CZ a EN. případně zpracování Listinných
podkladů nebo obchodní činnost;
• CC2 - Junior - Komunikace pouze CZ
V přehledu cen vycházíme z typu práce .rutinní práce' v dolním rozsahu,
relevantní štítek (viz str. 12 Přehledu cen) je operátor, mediánová hodnota 4.600.
Na základě vstupů byla stanoven střední odhad sazby pro CC1 na 5.000 a pro
CC2 na 4.000.
Na základě těchto údajO bylo stanoveno rozpětl ceny za MD pro uvedenou

roU Junior na 3.500 - 4.500 Kč a pro uvedenou roli senior 4.500 - 5.500 Kč.

1) Trvale poskytované služby
Výpočet na základě týdenni kapacity (sloupec Hodin týdně) pro dobu
poskytován! služeb 208 týdnů.
Komponenta služby Činnost Hodin ŠpiEtca MO I

Role t Cena celkem Cena celkem
týdně týdně od~ doQ(č}
Vedoucí Call centra CC 40 40 5 CCM 10.400.000 11.440.000

8/5
- -
Pokrytí ca lL centra CC 168 H~S 21 CCl 19.656.000 24.024.000
Jednou osobou (CZ+
ENG) v režimu 24/7
Druhá osoba CZ+ENG CC 140 140 17,5 CCl 16.380.000 20.020.000
v režimu 20/7 (4:00-
24:00)
Třetí osoba pouze CZ CC 80 80
-
10 CC2 7280.000 9.360.000
v režimu 16/5
(Dopolední a
odoolední směna)
čtvrtá osoba pouze CZ CC 60 60 7,5 CC2 5.460.000 7.020.000
v režimu 12/5 .___
Pátá osoba pouze CZ CC 60
-
60
- 5.460.000
7.5 CC2 7.020.000
v režimu 12/5
šestá osoba pouze CZ I CC 60 60 7,5 CC2 5.460.000 7.020.000
v režimu 12/5
Sedmá osoba pro CC 56 112 7 CCl 6,552.000 8,008.000
špičky CZ+ ENG (50 %)
- režim 16/7 (. 112hod)
x50 %
Osmá osoba pro CC 34 112 4,25 CC2 3.094.000 3.978.000
špičky C:Z. (30 %) -
režim16/7 ť• 112hod) x
30%
Zpracování llstlnných List 50 60 6,25 CCl 5.850.000 7150.000
podání v režimu 10/5
(Dopolední směna) 1
osoba
--
'obchodní aktivity' v Obch 2 ◄ 24 3 CCl 2.808.000 3.432.000
režimu 4/5 + 2/2
ledna osoba
Celkem n2 908 88.400.000 10IA72.000

Legenda sloupců (společná I pro následující části cen, tedy pro 2) Navýšeni
kapacit v době náběhu - 24 týdnů, 3) Zavedeni služby a 4) Celkový odhad za
další provozní činnosti).
• Komponenta služby - popis poskytované služby.
Pojem .osoba" pfedstavuje virtuální osobu, položka je ve skutečnosti
realizována různými pracovníky z poolu Cali Centra, Jedná se o
zjednodušení pro provedení odhadů.
• Činnost - zařazení do kategorie činnosti - CC - Call centrum. List -
zpracováních listinných podání, Obch - Obchodní aktivity.
• Hodin týdně - týdenní kapacita komponenty služby v hodinách.
• Špička - sedmá a osmá osoba je koncipována pro pokryti ve špičkových
měsících (Prosinec, Leden, Únor), tento sloupec obsahuje kapacitu při
aktivaci těchto zdrojů.
• MD týdně - přepočet průměrné hodinové kapacity na MD.
• Role - identifikace role, viz MO sazby roll výše.
• Cena Celkem od (Kč) - spodní hranice odhadu (sloupec MD týdně x počet
týdnů poskytování služby x sazba od role).
• Cena Celkem do (Kč) - horní hranice odhadu {sloupec MD týdně x počet
týdnů poskytování služby x sazba do role).
Pokrytí potřebné kapacity Call centra
• Průměrné obsazeni call centra je navrženo na 698 hodin týdně (40 + 168 +
140 + 80 + 60 + 60 + 60 + 56 + 34).
• Maximální obsazení 9 osob pro hodinové špičky Je dosaženo za těchto
podmínek:

o je nutné aktivovat zdroje pro špičky (sedmá a osmá osoba);
o v hodinových špičkách obstuhule klienty I vedoucí, případně
pracovníci pro zpracování listinných podkladů a pro obchodní
činnost;
o bez realokace směn je možné maximální kapacity dosáhnout v
pracovní dny mezi 8:00 - 17:00.
• Průměrné týdenní obsazení Call centra je navrženo (pro špičkové měsíce)
na 832 hodin, což prakticky odpovídá kontinuálnímu (2417) obsazení pěti
osobami.
Navržené obsazení Call centra tedy odpovídá výše určeným požadavkům
odvozeným z nyní známých potřeb. Nicméně navržený způsob konfigurace

provozuje nutné chápat výhradně jako model pro určení ceny obvyklé. Reálné
uspořádání budou ovlivňovat další provozní faktory, které nejsou a nemohou být
v současné době známé.
2) Navýšení kapacit v době náběhu - 24 týdnů
Je nutné předpokládat vyšší zátěž Call Centra v době zavádění systému.
Navíc systém bude zaváděn v období maximálních prodejů (prosinec -
leden). Proto je pro období prvních 6-tl měsíců navržena navýšená

kapacita cau Centra o 30 %.
Komponentasl.u!by Hodlfl MD Role CenaG&lk&m
lčtnnost týdně týdně
Cena ceU<em
od(Kč) do {ké)
Vedoucí CaU centra CC 20 2,5 CCM 600.000 660.000

4/5
Pokrytí Cali centra CC 168 21 CCl 2.268.000 2.772.000
jednou osobou (CZ +
ENG) v režimu 24/7 I I

neu osoba pouze cz v CC I 40 5 CC2 420.000 540.000
režimu 8/5 (Dopoledni
směna)
-- -
Zpracování Listinných List 20 2,5 CCl 270.000 330,000
podání v režimu 4/5
(Dopolední směna) 1 I
J
osoba
- - -
'obchodní aktivity' v Obch 28 3,5 CCl 378.000 462.000
režimu 4n jedna
osoba
CeUtem J.93e.OOO 4.764.000
Navýšeni týdenní náběhové kapacity Call centra je o 228 {20 + 168 + 40) hodin,
týdně tedy 33 % oproti průměrné kapacitě přl běžném provozu uvedené v bodě
1 698 hodin týdně.
3) Zavedení služby
Náklady související s přípravou pracovních postupů a zaškolením
pracovníků.
AJdMta Čfnnost MO Rol.e Cenacat.kenl Cena G:9U<em

0d g(č) do (Kč)
Příprava pracovních postupů CC 20 CCM 200.000 220.000
Vyškoleni (22 osob 2 dny) CC 46 CC2 161000 207.000
Příprava pracovních postupů List 20 CCM 200.000 220,000
Vyškoleni (3 osoby 2 dny) List 8 CCl 36,000 44.000
Příprava pracovních postupů Obch 20 CCM 200.000 220.000
Vyškoleni (2 osoby 2 dny) Obch 6 CC1 27.000 33.000
CelkM, &N.000 944.000

4) Celkový od had za další pro vozní činno sti
Součet cen z předchozích třech částí.
Celkové součty Činnost , Cena c-etkem od (Kč) Cena celkem do O<č)

1
Call Centrum
._ CC I 83.391000 . - 102,289.000
6,356,000
-
l,g',racování Listinni_ch i: odání List 7.744.000
"Obchodní aktívity' Obch 3.413.000 4.147.000
Cel:kem 13.160.000 114.180.000
2.8.7. Souhrn ceny obvyklé
Následující tabulka shrnu]e ceny jednotlivých částí určené v předchozích
kapitolách.
Pol.ocmmceny Cena eeUc:em od oce Ce,,a celkem do (Kč}
f..:._'{~oření Díla - IS EDAZ 73.754.304 --~ 90,774.528

B. Provoz IS EDAZ 55,910.400 66227.200
C. Zřízení služeb olatformv 2.976.600 3,482.600
D. Služby platforl'!}Y 108.680.000 124.280,000
E. Rozvoj, konzultace a další služby 24.400.000 28.400.000
F. Další provozní činnosti 93.160.000 114180.000
CeU<em 358.88L304 427.344.328
2.9. Autorská právft v rámci IS EDAZ
Pro zajištění řádného fungování systému EDAZjako celku Je nezbytné posoudit
nejen soulad navrhované architektury a konfigurace Jednotlivých dodavatelů,
ale rovněž řádné zajištění nabízených řešení z hlediska autorského práva a práv
příbuzných.
Samostatným předmětem práv jsou zejména jednotlivé komponenty
SW architektury nabízeného řešení.

Z hlediska autorských práv je EO AZ nutné považovat za tzv dílo na objednávku
dle ust. § 61 zákona č.121/2000 Sb., autorský zákon.
§ dl g S
lo vytvořené na o b j edn áv k u a s ou t éžnS dl o
(1) Je-LI dllo autorem vytvofené na základě smlouvy o dílo (dl1o vytvořené na
objednávku), platí, že autor poskytl. licenci k účelu vyplývajíc/mu ze smlouvy, není
li sjednáno jinak. K užití díla nad rámec takového účelu Je objednatel oprávněn
pouze na základě licenčnt smlouvy, nevyplývá-li z tohoto zákonajlnak.
(2) Není-li sjednáno Jinak, autor může dílo vytvořené na objednávku užít a
poskytnout Ucenc/jlnému, není-li to v rozporu s oprávněnými zájmy objednatele.
(3) Ustanovení odstavců 1 a 2 platí obdobně pro dllo vytvořené autorem Jako
soutěžídm ve veřejné soutěži tsouiéinl dílo).
Celý systém však fakticky bude obsahovat větší množství samostatných děl
složených do tzv. souborného díla, když součástí plnění bude programové
vybaveni od úrovně firmware, přes OS až po aplikační vrstvu. Jednotlivá díla
přitom mohou být z hlediska autorských práv vlastnictvím většího počtu
dodavatelů.
Pro definici takových děl a režim nakládání s nimi jsou rozhodující následuJfcí
ustanovení autorského zákona:
§ da Obecná ustanovení
(1) Poéftaéový program. bez ohledu na formu jeho vyjádření, včetně přípravných
koncepčních mater!ólů,Je chráněnjako dno Uterární, ne\l'jplývá-l/ z tohoto zákona
jinak.

(2) Myšlenky a principy, na nichžje založenjakýkoU prven počttačového programu.
včetně těch, kteréjsou podklademJeho propojenísjiným programem. nejsou podle
tohoto zákona chráněny.
§ 66 Omezenirozsahu práv autora h počltačovému programu
(1) Do práva autorského nezasahuje oprávněný uživatel rozmnoženiny
počftačového programu,JesWže
a) rozmnožuje, překládá, zpracovává, upravuje člJinak mění počítačový program.
je-U to nezbytné k využití oprávněně nabyté rozmnoženiny počítačového programu,

činl-ll tak při zavedeni a provozu počítačového programu nebo opravuje-U chyby
počiiačovébo programu,
b) Jinak rozmnožuje, překládá, zpracovává, upravule či Jinak mění počitačovy
program,je-U to nezbytné k využiti oprávněně nabyté rozmnoženiny počítačového

programu v souladu sjeho určenfm, není-U dohodnutojinak,
c) zhotoví si záložní rozmnoženinu počitačovéno proqtomu.je-li nezbytná proJeho
užívání,
d) zkoumá, studuje nebo zkoušf sóm nebo Jím pověřená osoba funkčnost
počítačového programu za účelem zjištění myšlenek a principů, na nichžje založen
kterýkoli prvek počftačového programu, činí-U tak při takovém zavedení, uložení
počítačového programu do paměti počítače nebo při Jeho zobrazení, provozu čl
přenosu, k němuž]e oprávněn,
e) rozmnožuje kód nebo překládá jeho formu pří rozmnožováni počítačového
programu nebo přijeho překladu čiliném zpracováni. úpravě číjíné změné.je-U k

ní oprávněn, a to samostatně nebo prostřednictvím Jim pověřené osoby, Jsou-li
tahové rozmnožováni nebo překlad nezbytné k z/skáni informací potřebných k
dosažení vzájemného funkčnfho propojení nezávisle vytvofeného počítačového

programu sjinými počitačovymi programy,jestliže informace potřebné k dosažení
vzájemného funkčního propojení nejsou pro takové osoby dříve jinak snadno a
rychle dostupné a tato činnost se omezuje na ty čóstl počítačového programu,
kteréjsou potřebné k dosažení vzájemného funkčního propojení.
(2) Za rozmnožování počitačového programu podle tohoto zákona se považuje i
zhotovení rozmnoženiny, je-lJ nezbytná k zavedení a uložení počítačového
programu do poměti počítače,Jakož I pro jeho zobrazení, provoz a přenos. ·
(3) Za pronájem čl pifjčování podle tohoto zákona se nepovažuje pronójem nebo
půjčování rozmnoženiny počítačového programu, kde samotný program není
podstatným předmětem pronáimu nebo půjčování.
(4) Informace z/skané při činnosti podle odstavce 1 písm. e) nesmějí být posk'ýtnuty
Jiným osobám, ledaže Je to nezbytné k dosažení vzaiemnéro funkčnfho propojení
nezávisle vytvořeného počftačového programu, ani využity k Jiným účelům než k
dosažení vzájemného funkčního propojení nezávisle vytvořeného počítačového
programu Dále nesměji být tyto informace využity ani k vyvcft, zhotovení nebo k
obchodnímu využíti počítačového programu podobného tomuto počttačovému

programu vJeho vyjádření nebo k jinémujednánf ohrožujícímu nebo porušujícímu
právo autorské.
(5) Pro omezení autorských práv k počítačovému programu podle odstavce 1 platí
ustanoveni§ 29 odst 1
(6) Oprávněným ut/vatelem rozmnoženiny počltačového programu je oprávněný
nabyvatel rozmnoženiny počítačového programu, který má vlastnické čiJiné právo
k rozmnoženině počítačového programu, a to za účelem Jejího využiti, nlkoU za
účelem Jejího dalšího převodu, dále oprávněný nabyvatel licence nebo Jiná osoba
oprávněná užívat rozmnoženinu počiiačového programu. Takový uživote! může
utrt oprávněně nabytou rozmnoženinu počítačového programu v rozsahu
stanoveném v odstavci 1 (minimální rozsah), pokud neni smlouvou dohodnut

rozsah šlršf,· minimální rozsah nelze s výjimkou oprávněni uvedeného v odstavci 1
písm. b) dohodou zúžit
(7) Ustanovení§ 30a až 33, § 34 pfsm. b) až d), § 35 až 38, § 38a odst 1 ptsrn. b), §
38a odst 2, § 38b až 39, § 43 odst. 1 a 4 až 6 a ustanovení občanského zákoníku o
odstoupení od smlouvy pro změnu přesvědčení autora se na počítačový program
nevztahují.
(8) Právní ochranou technických prostředků podle § 43 nejsou dotčena ustanoveni
odstavce 1 písm. d) a e) v rozsahu nezbytném h využit! těchto omezení. Autor, který
pro své dílo použil technické prostředky podle § 43 odst 3, je povinen zpřístupnit
počítačový program oprávněnému uživateli v rozsahu podle odstavce 1 a je
povinen označit počftačový program chróněný technickými prostředky uvedením
Jména a adresy osoby, na kterou se má oprávněný uživatel za tím účelem obrátit
Předmětná ustanoveni autorského zákona Jsou pro potřeby real!zace EDAZ
modifikována závaznými ujednáními čl. 17 závazného vzoru smlouvy, která Je
přílohou dokumentace. Dle smlouvyJsou rozlišovány de facto tři typy autorských
děl. a to:
• Autorská díla dodavatele:

• Proprietám! díla třetlch osob;
• Díla v režimu open source.
Autorská díla, ke kterým náleží práva přímo dodavateU, . jsou bez výjimek
regulována ustanoveními navržené smlouvy, zbylé dvě kategorie autorských děl
se však vůči objednateU ffdí U cen čníml podmínkami svých původců a v případě
chybného vypořádání (čl užiti) autorských práv ze strany dodavatele tak může
dojít k významným komplikacím pro objednatele.

Proto, aby bylo možné potvrdit, že Je nabídka z hlediska autorských práv
konstruována správně, tj. zda je nabízené řešení proveditelné.je zejména nutné
ldentifikovatjednotllvá dílčí díla, která tvoří součást nabízené architektury EDAZ
a posoudit, zdali Jsou Licenční podmfnky, které původci těchto děl standardně
poskytulí v souladu s požadavky objednatele VY.Jádřenými v dokumentaci.

3. ODPOVĚĎ NA OTÁZKU (VÝROK ZNALCE)
Otázka č.1:
Jaká je cena obvyklá na území České republiky v době zpracování posudku za
vytvoření Informačního systému EDAZ a poskytnuti služeb, Jak Jsou definovány
v závazném návrhu smlouvy a její příloze 1. a se zohledněním poskytnutých
upřesňujfcfch dokumentů?
Odpověď.
Znalec konstatuje, že celkovou cenu obvyklou v České republice v době
zpracování posudku za vytvořeni Informačního systému EDAZ a poskytnutí
služeb, Jak Jsou definovány v závazném návrhu smlouvy a její příloze 1. a se
zohledněním poskytnutých upřesňujících dokumentů, stanovL!]e ve výši
od 358.881304,- Kč bez DPH do 427.344.328,- Kč bez DPH, a to v závislosti na
faktorech popsaných a uvedených v kapitole 2 posudku.
Datum: 07.01.2020
podpis znalce podpis znalce

DVD s podklady poskyt nutými Objednatelem

Znalecký Posudek o Ceně Zakázky Na Elektronické Dálniční Známky

Uploaded by

Document Information

Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Description:

Copyright:

Available Formats

Znalecký Posudek o Ceně Zakázky Na Elektronické Dálniční Známky

Original Title:

Uploaded by

Description:

Copyright:

Available Formats

...

Účel posudku: Stanovení OwQ

ID datové schránky: e5qaihb

Zhotovitel: Znalecká kancelář Dr. Ludvika, s.r.o.

ID Datové schránky: p4b9d8

Posudek Je vyhotoven ve dvou vyt,otoventch, z nichž každé má platnost

originálu. Jedno vyhotovení obdrží objednatel a jedno vyhotovení je uloženo

v archivu znaleckého ústavu.

Posudek obsahLt)e celkem -143- stran

V Praze dne 7. ledna 2020

Objednávkou ze dne 20.10.2019 byl osloven znalecký ústav - Znalecká kancelář

Et IČO: 02323001 se sfdlem Litná 562/10, 120 00 Praha 2 - Nové

Město, za účelem zpracováni znaleckého posudku v oboru KYBERNETIKA.

řešeni v oblasti IT, telekomunikaci a duševního vlastnictví, elektrotechnika

KULTURA odvěM Distribuce a užívání autorských práv, posuzováni existence

Předmětem posuzované věci je vytvořeni IS EDAZ .Informačního systému pro

evidenci vozidel v systému časového zpoplatněnr a poskytováni souvisejícfch

služeb, a to v rámci projektu Elektronické dáµllční známky.

Pfedmět posuzované věci byl dále rozšířen v souladu s objednávkou dne

Úkolem znaleckého ústavu je stanovení ceny v místě a čase obvyklé.

Jaká Je cena obvyklá na území české republiky v době zpracování posudku

definovány v závazném návrhu smlouvy a její příloze l a $6 zohledněním

poskytnutých upřesňujfcich dokumentů.

Znalecký posudek č. 14/2/ZOl.9 3

L 3. Podklady pro vypracovánf posudku

8·] #w(!]L6­Lé ú9<0·68L0Q0&(viz strana 143 posudku)

l Základní požadavky - IS EDAZ

3. Požadav ky - Služby provozu a technické podpory

5. Standardy uživatelského rozhraní aplikací SFDI pro projekt

Elektronická dálniční známka

8. Požadované služby Call centra

10. Zajištěni .Obchodních aktivit" v rámci provozu eShop

13.3. OO-Doplneni-20191127 - Doplněn í požadavků SFDI

Doplňující Informace k e.m Smlouva-Prlloha_l vzniklé na základě

konzultaci a workshopů v průběhu výběru řešitele Informačního

13.4. 012-struktura_ cenove_nabldky

Fonnulář předeplstúíci strukturu ceny Poskytovateli.

13.5. pozado vane_lnformace- 20191103_ v2

Dokument kterým byli osloveni potenciální dodavatelé požádání o

poskytnuti Indikativní cenové nabídky a dalších informací.

Přehledový dokument naznačující rozdělení požadovaného systému

13.7. 02.1-UC-oz nameni_elektromobl l

Diagram průběhu procesu přípravy podání oznámení osvobození pro

elektromobil fyzickou osobou.

Diagram průběhu procesu přípravy podání oznámení osvobození pro

Diagram průběhu procesu zpracování oznámení osvobození

Diagram průběhu procesu zakoupení elektronické dálniční známky

bankovním převodem s využitím zálohové faktury.

Komentované diagramy hrubě poplsujfcí ePodatelnu a eVýpravnu.

13.12. 05-BezpecnostnL pozadavky

Požadavky týkající se provozu platformy.

Znalecký posudek č. 14/2/2019 5

Formulář pro spec ifikaci kompo nent platform y IS EDAZ .

Formulář pro spec ifikaci kompo nent platformy !S SFDI.

Rozsah součinnost! ze strany Objednatele.

1.3.19. 07-Pocty _u hrad

Měsíční statistika prodeje dálničních známek za rok 2019.

Odhadované počty oznámen! Osvobození.

1.3.21 09 -Model_hod noceni

8·] #w(!]L6Lé ú9<0·68L0Q0&(viz strana 143 posudku)

Zdroj ministerstvo vnitra ČR. https://www.mvcr.cz/clanek/prehled