You are on page 1of 141

...

,; 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(!]L6­Lé ú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&Qw­K8
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ú.
------------------------------------ -
Znalecký posudek č. 14/2/2019 6
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

Znalecký posudek č. 14/2/2019 7


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

Znalecký posudek č. 14/2/2019 8


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

Znalecký posudek č. 14/2/2019 9


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

Znalecký posudek č. 14/2/2019 10


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

Znalecký posudek č. 14/2/2019 11


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

Znalecký posudek č. 14/2/2019 12


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

Znalecký posudek č. 14/2/2019 13


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

Znalecký posudek č. 14/2/2019 14


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

Znalecký posudek č. 14/2/2019 15


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

Znalecký posudek č. 14/2/2019 16


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

Znalecký posudek č. 14/2/2019 17


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

Znalecký posudek č. 14/2/2019 18


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

Znalecký posudek č. 14/2/2019 19


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

Znalecký posudek č. 14/2/2019 20


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

Znalecký posudek č. 14/2/2019 21


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

Znalecký posudek č. 14/2/2019 22


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

Znalecký posudek č. 14/2/2019 23


Ř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

Znalecký posudek č. 14/2/2019 24


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

Znalecký posudek č. 14/2/2019 25


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

Znalecký posudek č. 14/2/2019 26


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)

Znalecký posudek č. 14/2/2019 27


Š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

Znalecký posudek č. 14/2/2019 29


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

Znalecký posudek č. 14/2/2019 31


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

Znalecký posudek č. 14/2/2019 32


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

Znalecký posudek č. 14/2/2019 33


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

----· -
Znalecký posudek č. 14/2/2019 34
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

Znalecký posudek č. 14/2/2019 35


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

Znalecký posudek č. 14/2/2019 36


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

Znalecký posudek č. 14/2/2019 37


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)

Znalecký posudek č. 14/2/2019 39


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.

Znalecký posudek č. 14/2/2019 40


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

Znalecký posudek č. 14/2/2019 41


■ 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

Znalecký posudek č. 14/2/2019 42


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

Znalecký posudek č. 14/2/2019 43


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

Znalecký posudek č. 14/2/2019 44


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.

Znalecký posudek č. 14/2/2019 45


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

Znalecký posudek č. 14/2/2019 46


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

Znalecký posudek č. 14/2/2019 47


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

Znalecký posudek č. 14/2/2019 48


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

Znalecký posudek č. 14/2/2019 50


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

Znalecký posudek č. 14/2/2019 51


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

Znalecký posudek č. 14/2/2019 52


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

Znalecký posudek č. 14/2/2019 53


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

Znalecký posudek č. 14/2/2019 54


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

Znalecký posudek č. 14/2/2019 55


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

Znalecký posudek č. 14/2/2019 56


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

Znalecký posudek č. 14/2/2019 57


• 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:')

Znalecký posudek č. 14/2/2019 58


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

Znalecký posudek č. 14/2/2019 59


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

Znalecký posudek č. 14/2/2019 60


Oblaat/Podobhlst
- --
I Kód - Nél!ev -- -
Ty.p- stan.
ModuUKo,nponenta POZl'lémka Rozs, MO
ln~ ce ~Bazp.
Portál/Správa Profilu
-~ - - ---
POR - 3/2 - Práce s profilem
-- --
F-1-0 2,0
eShop (externí částl/Profll Zobrazení historie obchodů,
I
I
Integrace: Evidence
Portál/Správa Profilu
eShop (externí část)/Profil
POR - 3/3 - Práce s profilem
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

Znalecký posudek č. 14/2/2019 61


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

Znalecký posudek č. 14/2/2019 62


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

Znalecký posudek č. 14/2/2019 63


[=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
Portál/Správa obsahu
mutace
POR - 36 - Navigační menu -F-2-0 5,0
Společné/Základ webu
Portál/Správa obsahu
Společné/Základ webu
POR - 37 - Custom atributy I F-2-0 5,0

Portál/Správa obsahu POR - 38 - Worl<flow F-3--0 15,0


Společné/Základ webu
- ._ ---k2-o-
-
Portál/Správa obsahu POR - 39 - PubUkace 5,0
Společné/Základ webu
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
Společné/Základ webu
---- POR - 42 - Dokumenty a F-2-0
-
5,0
Portál/Správa obsahu
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
Společné/Základ webu
·-
Portál/Správa obsahu POR- 47 -Vyhledávání F-2-0 5,0
Společné/Základ webu
Portál/Správa obsahu POR- 48 - Znalostní databáze F-2--0 5,0
Společné/Základ webu
Portál/Správa Web site POR - 49 - Správa Web site F-2--0 5,0
Společné/Základ webu
- -

Znalecký posudek č. 14/2/2019 64


~
--
Obtut/Pociloli,lest
Modul/Kompotlenta
~

L~- -
JKód-~
Pornámka
lmagrace
--
-- -
- r::1-~ Roza.
-Beep,
MD

-
PortáVSpráva Web slte
Společné/Základ webu
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
Společné/Základ webu
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
Společné/Základ webu
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
Společné/Základ webu
- --
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
Společné/Základ webu

Znalecký posudek č. 14/2/2019 65


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
nebudou duplikovány.
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
nebudou duplikovány.
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. ___._ __

Znalecký posudek č. 14/2/2019 66


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 _

Znalecký posudek č. 14/2/2019 67


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

Znalecký posudek č. 14/2/2019 68


-
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
eShop/Úhrada časového poplatku
- 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
Integrace: Platební brána
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

eShop/Úhrada časového poplatku


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

Integrace: Platební brána

Znalecký posudek č. 14/2/2019 69


- ~ --- - -- -~- - -- -
Oblast./Podoblut Kód- Niuev Typ- Stan.
MGduVKomponenta

- ---
eShop/Úhrada časového poplatku
-
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
eShop/Úhrada časového poplatku
- ESH - 36 - Zpracování výplsu F-1-1 2,2
eShop Cbackofflcel/Platebn í brána
I

eShop/Úhrada časového poplatku


Integrace: Platební brána
--
ESH - 37 - Rozpory výpisů
--· - F-2-1 5,5
eShop (backofflce)/Platebn i brána
Integrace: Platební 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
--
eShop/Úhrada časového poplatku
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/Úhrada časového poplatku
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

eShop/Úhrada časového poplatku


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

Znalecký posudek č. 14/2/2019 70


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

Znalecký posudek č. 14/2/2019 71


-
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, _)

Znalecký posudek č. 14/2/2019 72


- 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

Znalecký posudek č. 14/2/2019 73


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_

Znalecký posudek č. 14/2/2019 74


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

Znalecký posudek č. 14/2/2019 75


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

Znalecký posudek č. 14/2/2019 76


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

Znalecký posudek č. 14/2/2019 77


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
doplněn na základě 'Doplnění
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
doplněn na základě 'Doplnění
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

Znalecký posudek č. 14/2/2019 78


- -~
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
doplněn na základě 'Doplnění
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
doplněn na základě 'Doplnění
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
doplněn na základě 'Doplněni
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
doplněn na základě 'Doplněni
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
doplněn na základě 'Doplnění
požadavků SFDI'. I
Jen předénl přes APi a př[iem
odpovědi.
lnteorace: Výpravna <listinná)

Znalecký posudek č. 14/2/2019 79


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.

Znalecký posudek č. 14/2/2019 81


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

Znalecký posudek č. 14/2/2019 82


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

Znalecký posudek č. 14/2/2019 83


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ů

Znalecký posudek č. 14/2/2019 84


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,

Znalecký posudek č. 14/2/2019 85


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.

Znalecký posudek č. 14/2/2019 86


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.

Znalecký posudek č. 14/2/2019 87


'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

Znalecký posudek č. 14/2/2019 88


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

Požadavek Objednatele:

~ $)'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

Znalecký posudek č. 14/2/2019 89


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

Znalecký posudek č. 14/2/2019 90


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í

Požadavek Objednatele:

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í

Požadavek Objednatele:

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

Předpokládaný způsob řešení

Š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ý

Znalecký posudek č. 14/2/2019 93


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


--- - -
Požadavek Objednatele:

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..
Znalecký posudek č. 14/2/2019 94
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

Předpokládaný způsob řešení

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ě

Znalecký posudek č. 14/2/2019 95


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

Znalecký posudek č. 14/2/2019 96


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

Znalecký posudek č. 14/2/2019 97


OP0-37 Bezpečnostní dokumentace

Požadavek Objednatele:

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

Znalecký posudek č. 14/2/2019 98


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~

Znalecký posudek č. 14/2/2019 99


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

Znalecký posudek č. 14/2/2019 100


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.'~,

Znalecký posudek č. 14/2/2019 101


'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-~ů.

Znalecký posudek č. 14/2/2019 102


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

Znalecký posudek č. 14/2/2019 103


,.

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,

Předpokládaný způsob řešení

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

Požadavek Objednatele:

~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,

Znalecký posudek č. 14/2/2019 105


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

Znalecký posudek č. 14/2/2019 106


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

Požadavek Objednatele:
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


---------------------------------
Požadavek Objednatele:

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.

Předpokládaný způsob řešení

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.

Znalecký posudek č. 14/2/2019 108


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

Znalecký posudek č. 14/2/2019 110


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í

Znalecký posudek č. 14/2/2019 111


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

Požadavek Objednatele:

1 ~ .l>udw ~~etelr!é 8 bUdoo mlt yYl'IOkmi de~ - ,tráfy I


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

Znalecký posudek č. 14/2/2019 113


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.

Znalecký posudek č. 14/2/2019 114


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.

Znalecký posudek č. 14/2/2019 115


# 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)

Znalecký posudek č. 14/2/2019 116


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.

Znalecký posudek č. 14/2/2019 117


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

Znalecký posudek č. 14/2/2019 118


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.

Znalecký posudek č. 14/2/2019 119


• 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

Znalecký posudek č. 14/2/2019 121


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

Znalecký posudek č. 14/2/2019 122


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

Znalecký posudek č. 14/2/2019 123


-- ----,
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·

Znalecký posudek č. 14/2/2019 124


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.

Znalecký posudek č. 14/2/2019 125


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.

Znalecký posudek č. 14/2/2019 126


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

Znalecký posudek č. 14/2/2019 127


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"

Znalecký posudek č. 14/2/2019 128


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

Znalecký posudek č. 14/2/2019 129


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

Znalecký posudek č. 14/2/2019 130


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:

Znalecký posudek č. 14/2/2019 131


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

Znalecký posudek č. 14/2/2019 132


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

Znalecký posudek č. 14/2/2019 133


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

Znalecký posudek č. 14/2/2019 134


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.

Znalecký posudek č. 14/2/2019 135


(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

Znalecký posudek č. 14/2/2019 136


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

Znalecký posudek č. 14/2/2019 137


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.

Znalecký posudek č. 14/2/2019 138


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.

Znalecký posudek č. 14/2/2019 139


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

Znalecký posudek č. 14/2/2019 140


DVD s podklady poskyt nutými Objednatelem

Znalecký posudek č. 14/2/2019 143