WEBSERVER2
CORE8
1.2.0.1
2026-04-23 20:09
Upozornění: Text přílohy byl získán strojově a nemusí přesně odpovídat originálu. Zejména u strojově nečitelných smluv, kde jsme použili OCR. originál smlouvy stáhnete odsud
o Česká televize 1091502
Česká televize
IČO: 00027383
a
ADASTRA, s.r.o.
IČO: 26202981
SMLOUVA O DÍLO
č. 1091502/2234
Předmět smlouvy: Televizní poplatky - datový sklad a reporting - realizace
Cena, případně hodnota: 1.815.000, 00 Kč bez DPH
Datum uzavření:
2 6 -09- 2018
109150220180912125541SD232081PRO400
O Česká televize DMSS: 1091502/2234
SMLOUVA O DÍLO
„Televizní poplatky - datový sklad a reporting - realizace II“
uzavřená podle § 2586 a násl. zákona č. 89/2012 Sb., občanský zákoník (dále jen „občanský
zákoník“), mezi
Česká televize
IČO: 00027383
DIČ: CZ00027383
se sídlem: Kavčí hory, Na Hřebenech II 1132/4, 140 70 Praha 4
zřízená zákonem č. 483/1991 Sb. o České televizi, nezapisuje se do obchodního rejstříku
bankovní spojení: Česká spořitelna, a.s.
č. účtu: 1540252/0800
zastoupená: Petrem Dvořákem, generálním ředitelem
(dále jen „Objednatel“)
a
ADASTRA, s.r.o.
IČO: 26202981
DIČ: CZ26202981
se sídlem: Benešovská 1926/8, Praha 10, 101 00
zapsán v obchodním rejstříku, Městským soudem v Praze sp. zn. C 79377
bankovní spojení: Komerční banka
č. účtu: 27-7734050287/0100
zastoupen: Pavlem Kyselou, jednatelem
(dále jen “Poskytovatel“)
Objednatel a Poskytovatel dále společně též „smluvní strany“.
Tato smlouva dále také jen „Smlouva“.
Preambule
Smlouva se uzavírá na základě veřejné zakázky malého rozsahu s názvem „Televizní
poplatky - datový sklad a reporting - realizace - II“.
Smlouva se uzavírá v souladu se zadávací dokumentací ČT jako zadavatele ze dne 24. 7.
2018 a nabídkou Poskytovatele ze dne 15. 8. 2018.
1. Předmět a účel Smlouvy
1.1. Účelem této smlouvy je zlepšení evidence a správy televizních poplatků.
1.2. Předmětem Smlouvy je vytvoření datového skladu pro účely evidence a správy
televizních poplatků v souladu s přílohami této smlouvy, zejména Přílohou č. 1 -
Specifikace předmětu plnění a Přílohou č. 2 - Rozpad odhadů pracnosti (dále také
jako „dílo“). Součástí plnění je také zprovoznění datového skladu na HW objednatele
a vytvoření dokumentace skutečného provedení díla, včetně dodání administrátorské
a uživatelské příručky v češtině objednateli.
Objednávka v SAP č.: 4500853658
109150220180912125541SD232081PRO400
C D Česká televize
DMSS: 1091502/2234
Výsledné dílo musí obsahovat:
• Funkční datový sklad - dle obvyklého konceptu třívrstvé architektury datového skladu
(L0, L1, L2)
• Funkční ETL vrstvu - pro správu a řízení ETL procesů budou využity nástroje SSIS
(Microsoft) a vybraného nástroje ETL Framework.
• Business Intelligence prostředí
• Přístupovou vrstvu Bl
• Reporty (2 reporty)
• Školení super uživatelů (max. 10) v rámci dodávaného řešení (maximální rozsah 3
dny) - školení proběhne v pracovní době objednatele, tj. mezí 8:00 a 17:00; čas bude
upřesněn objednatelem.
• Dokumentaci skutečného provedení, Admínístrátorskou příručku, Uživatelskou
příručku.
1.3. Poskytovatel se zavazuje provést dílo v nejvyšší možné kvalitě a za podmínek
uvedených v této Smlouvě, v souladu s platnými právními předpisy, technickými
normami a dle dalších pokynů Objednatele. Poskytovatel prohlašuje, že pří plnění této
smlouvy použije software, jehož je výrobcem nebo autorizovaným prodejcem.
1.4. Dílo zhotoví Poskytovatel pro potřeby Objednatele. Součástí díla je i předání
dokumentů v souladu s touto smlouvou a jejími přílohami.
1.5. Dílo bude předáno objednateli implementací do virtuálního prostředí Objednatele
v místě jeho sídla a integrací s příslušnými systémy Objednatele v souladu
s vymezením dle Přílohy č. 1 Smlouvy.
1.6. Objednatel se zavazuje zpřístupnit Poskytovateli věci dle odst. 1.6. nezbytné
k řádnému provedení díla způsobem uvedeným v Příloze č. 1 Smlouvy, pokud si
smluvní strany vzájemně nedohodnou jiný způsob a termín (např. fyzické předání
serverů určených k instalaci na základě oboustranně podepsaného předávacího
protokolu).
Poskytovatel se zavazuje spolupracovat s Objednatelem, případně s třetí osobou, při
uvedení díla do provozu dle čl. 3 této Smlouvy. Objednatel se zavazuje pro potřeby
implementace díla umožnit Poskytovateli nezbytný vzdálený přístup do svých
systémů.
1.7. Objednatel se zavazuje dílo, které bude prosté vad, včetně právních vad a
nedodělků, převzít za podmínek sjednaných v této smlouvě a zaplatit Poskytovateli
dohodnutou cenu.
1.8. Smluvní strany konstatují, že Objednatel je majitelem a pořizovatelem veškerých
databází, dat a programového kódu vytvořených za pomoci díla vytvořeného na
základě této smlouvy.
Objednávka v SAP č.: 4500853658
109150220180912125541SD232081PRO400
G Česká televize
DMSS: 1091502/2234
1.9. Poskytovatel se zavazuje, že při plnění smlouvy pro Objednatele neumožní výkon
nelegální práce vymezený v ustanovení § 5 písm. e) zákona č. 435/2004 Sb., o
zaměstnanosti, v platném znění.
2. Doba a místo plnění
2.1. Dílo vymezené v článku 1. této Smlouvy bude Poskytovatelem předáno Objednateli
nejpozději do 6 měsíců od prvního dne účinnosti Smlouvy.
2.2. Místem plnění díla je sídlo Objednatele a sídlo Poskytovatele. Místem zprovoznění a
předání díla je sídlo Objednatele.
3. Předání díla, zkušební provoz
3.1. Poskytovatel splní svou povinnost provést dílo jeho řádným dokončením a předáním
Objednateli včetně dokladů a dokumentů vztahujících se dílu a včetně odstranění vad
a nedodělků, a to na základě předávacího protokolu.
3.2. Před vlastním předáním díla předá Poskytovatel dílo do zkušebního provozu
(testování podle Přílohy č. 1), a to po provedení instalace hlavního a záložního
serveru Objednatelem a tak, aby zkušební provoz byl ukončen a dílo bylo předáno
Objednateli.
3.3. Poskytovatel předá funkční dílo do produkčního prostředí ke zkušebnímu provozu
spolu s dokumenty uvedenými v čl. 1.2. (v elektronické podobě ve formátu doc,
.docx nebo .pdf). Předání bude provedeno prostřednictvím předávacího protokolu,
který bude obsahovat přinejmenším:
a) označení smluvních stran;
b) datum a místo převzetí díla do zkušebního provozu;
c) údaj o tom, že dílo bylo implementováno do prostředí Objednatele, případně že
byl Objednateli fyzicky předány servery instalované v souladu se čl. 1.7.
d) IDEO: 213/229/37904/5000
e) označení díla, případné výhrady Objednatele k přebíranému dílu;
f) případný důvod Objednatele pro odmítnutí převzetí díla;
g) podpisy smluvních stran, resp. jimi pověřených osob.
3.4. Testování ve zkušebním provozu dle předchozího odstavce bude probíhat způsobem
uvedeným v Příloze č. 1. Projeví-li se v této době vada, vyzve Objednatel
Poskytovatele k jejímu neprodlenému odstranění. Po odstranění závady bude
probíhat nové testování, a to v případě potřeby i opakovaně.
3.5. Objednatel převezme dílo teprve po odstranění veškerých vad a nedodělků na
základě protokolu o převzetí díla bez vad a nedodělků, který bude obsahovat
přinejmenším:
a) označení smluvních stran;
Objednávka v SAP č.: 4500853658
109150220180912125541SD232081PRO400
C D Česká televize
DMSS: 1091502/2234
b) datum a místo převzetí díla;
h) IDEC: 213/229/37904/5000
c) označení díla, údaje o provedeném zkušebním provozu (datum zahájení a
ukončení, přehled zjištěných závad a údaje o jejich odstranění), případné
výhrady Objednatele k přebíranému dílu;
d) případný důvod Objednatele pro odmítnutí převzetí díla;
e) podpisy smluvních stran, resp. jimi pověřených osob.
3.6. Teprve po odstranění všech nedostatků a řádném ukončení testů bude systém (Dílo)
považován objednatelem za dokončený a bude objednatelem převzatý. Po převzetí
dokončeného díla se objednatel stává vlastníkem díla.
4. Cena díla
4.1. Cena Díla byla stanovena jako cena smluvní, nejvýše přípustná, pevná a platná po
celou dobu provádění Díla; celková cena Díla činí 1.815.000,- Kč (slovy: jeden
milion osm set patnáct tisíc korun českých) bez DPH, tj. celkem 2.196.150,- Kč
(slovy: dva miliony jedno sto devadesát šest tisíc jedno sto padesát korun
českých) včetně DPH, při sazbě DPH 21 %. K částce bude připočtena DPH podle
platných předpisů.
4.2. Cena za dílo zahrnuje veškeré náklady Poskytovatele spojené s vytvořením díla, mj.
odměnu za poskytnutí veškerých licencí a implementaci díla. Sjednanou cenu díla vč.
DPH lze překročit pouze v případě, že se ke dni zdanitelného plnění změní předpisy
pro výpočet sazby DPH.
4.3. Snížení rozsahu požadovaných prací (méněpráce) je možné pouze po předchozím
písemném souhlasu Objednatele.
5. Platební podmínky J
5.1. Objednatel nebude poskytovat zálohy. Objednatel uhradí cenu za dílo na základě
faktury - daňového dokladu (dále jen „faktura“), která bude vystavena
Poskytovatelem po předání a převzetí díla bez vad a nedodělků dle čl. 3 Smlouvy.
5.2. Faktura musí obsahovat číslo této Smlouvy, IDEC a ostatní pro fakturaci stanovené
údaje (dle zákona o DPH a § 435 občanského zákoníku). Přílohou faktury musí být
kopie podepsaného předávacího protokolu o předání a převzetí díla bez vad a
nedodělků. V případě, že faktura nebude obsahovat požadované náležitosti, je
Objednatel oprávněn vrátit ji Poskytovateli k opravě/doplnění. V takovém případě se
přeruší plynutí lhůty splatnosti, která znovu začne plynout doručením opravené
(bezvadné)/doplněné faktury Objednateli.
5.3. Splatnost faktury byla dohodnuta Smluvními stranami na 30 kalendářních dnů ode
dne doručení faktury Objednateli. V případě, že datum splatnosti faktury připadne na
sobotu, neděli, 31.12., státem uznaný svátek či den, který není pracovním dnem ve
Objednávka v SAP č.: 4500853658
109150220180912125541SD232081PRO400
O Česká televize
DMSS: 1091502/2234
smyslu zákona č. 284/2009 Sb., o platebním styku, v platném znění, posouvá se
datum splatnosti faktury na nejbližší další pracovní den.
5.4. Sjednává se, že bude-li Poskytovatel zasílat nebo v průběhu účinnosti této
smlouvy využije možnosti zasílat faktury (daňové doklady) elektronickou poštou je
povinen je zasílat v PDF formátu ze své emailové adresy na emailovou adresu
Objednatele faktury@ceskatelevize.cz.
Za den doručení faktury (daňového dokladu) Objednateli se považuje den doručení
na e-mailovou adresu Objednatele, což je zároveň považováno za souhlas s
využitím této formy komunikace. Stejný způsob elektronického doručení se použije i v
případě, nebude-li faktura obsahovat stanovené náležitosti nebo v ní nebudou
správně uvedeny údaje a také v případě zasílání opravných daňových dokladů.
5.5. V případech, kdy objednateli může vzniknout ručení za nezaplacenou DPH ve smyslu
zákona o DPH, je objednatel bez dalšího oprávněn odvést za poskytovatele DPH
z fakturované ceny plnění přímo příslušnému správci daně ve smyslu zákona o DPH
(tj. na účet správce daně). Tímto postupem zanikne objednateli jeho smluvní závazek
zaplatit poskytovateli částku odpovídající DPH. O takové úhradě bude objednatel
informovat poskytovatele bez zbytečného odkladu, nejpozději do dvou pracovních
dnů od jejího provedení.
5.6. Práce, dodávky a služby, které nebudou během provádění díla realizovány, nebudou
Poskytovatelem účtovány a cena za tyto práce, dodávky a služby bude od ceny díla
odečtena.
5.7. Práce nebo dodávky, které provede Poskytovatel mimo ujednání ve Smlouvě v
důsledku svévolného odklonu od smluvních podmínek, Objednatel nezaplatí.
Poskytovatel musí na vyžádání Objednatele ve stanoveném termínu výsledek těchto
prací odstranit a uhradit Objednateli náhradu škody, která mu tím vznikne.
6. Záruční doba, odpovědnost za vady
6.1. Dílo má vady, jestliže provedení díla neodpovídá výsledku určenému v této Smlouvě,
není provedeno v souladu s pokyny Objednatele, má právní vady, nemá vlastnosti
stanovené platnými technickými normami, je zhotoveno v rozporu s platnými právními
předpisy a/nebo nevykazuje vlastnosti pro něj obvyklé.
6.2. Ode dne předání díla bez vad a nedodělků uvedeného v předávacím protokolu
počíná běžet záruční doba na dílo v délce 12 m ěsíců.
6.3. Případná práva z odpovědnosti za vady díla uplatní Objednatel na následujících
kontaktních místech:
Adresa: Benešovská 1926/8, Praha 10, 101 00
tel:
e-mail:
Objednávka v SAP č.: 4500853658
109150220180912125541SD232081PRO400
G Česká televize
DMSS: 1091502/2234
Kontaktní údaje dle tohoto odstavce Smlouvy je možné měnit písemným oznámením
doručeným druhé smluvní straně, s účinnosti ode dne doručení takového oznámení,
a to bez nutnosti uzavírat dodatek ke Smlouvě. Poskytovatel prohlašuje, že
dorozumívacím jazykem kontaktního místa je jazyk český.
6.4. Poskytovatel je povinen zahájit odstranění vady nejpozději do 5 dnů ode dne
nahlášení vady Objednatelem. Poskytovatel je povinen odstranit vadu díla, za kterou
se považuje mj. i nejasnosti/chyby obslužného manuálu, nejpozději do 10 dnů ode
dne, kdy byla vada nahlášena/uplatněna objednatelem nebo se o nich Poskytovatel
jinak dozvěděl, nedojde-li po projednání kjin é dohodě. Poskytovatel projedná s
Objednatelem nejpozději do 5 dnů ode dne, kdy se o reklamaci vady dozvěděl,
způsob a lhůtu pro odstranění vad.
6.5. Poskytovatel neodpovídá za vady, jejichž původ spočívá ve výchozích podkladech,
které mu poskytl Objednatel. Podklad se považuje za vadný i tehdy, pokud dojde
k jeho úpravě v průběhu práce na předmětu díla. Na žádost Objednatele je však
Poskytovatel povinen dohodnout s ním opatření k co nejrychlejšímu odstranění závad
takových závad způsobených podklady Objednatele za úplatu.
7. Smluvní pokuty, odstoupení od smlouvy
7.1. Smluvní strana není za prodlení se splněním svých závazků vyplývajících z této
Smlouvy odpovědna, nemůže-li plnit v důsledku prodlení druhé smluvní strany.
7.2. Je-li Objednatel v prodlení s úhradou ceny dle této smlouvy, je Poskytovatel oprávněn
požadovat úrok z prodlení ve výši 0,03 % z dlužné částky denně.
7.3. V případě prodlení s předáním díla (včetně zdrojových kódů a dokumentace/dokladů
vztahujících se k dílu) ve lhůtě uvedené v čl. 2 této Smlouvy je Objednatel oprávněn
požadovat po Poskytovateli smluvní pokutu ve výši 0,5% z celkové ceny díla za
každý i započatý den prodlení.
7.4. V případě prodlení s odstraněním vad ve lhůtě podle čl. 6 odst. 4 Smlouvy je
Objednatel oprávněn požadovat po Poskytovateli smluvní pokutu ve výši 1.000,- Kč
za každý i započatý den, a to za každou vadu zvlášť.
7.5. V případě porušení kterékoliv povinnosti vyplývající ze čl. 10 a 11 Smlouvy je
Poskytovatel povinen zaplatit Objednateli smluvní pokutu ve výši 100.000,- Kč (jedno
sto tisíc korun českých) za každé jednotlivé prokázané porušení povinností.
7.6. Veškeré smluvní pokuty dle Smlouvy jsou splatné do 15 (patnácti) kalendářních dnů
ode dne doručení výzvy oprávněné smluvní strany k jejich zaplacení. Úhradu smluvní
pokuty lze provést započtením smluvní pokuty proti splatným pohledávkám
Objednatele vůči Poskytovateli z jakéhokoli smluvního stranu uzavřeného mezi nimi.
Objednávka v SAP č.: 4500853658
109150220180912125541SD232081PRO400
G Česká televize
DMSS: 1091502/2234
7.7. Nedotčena zůstávají práva objednatele i poskytovatele na náhradu škody a ušlý zisk
nad rámec smluvní pokuty podle příslušných ustanovení Občanského zákoníku.
Poskytovatel má v případě prodlení objednatele podle čl. 7 odst. 1 Smlouvy nárok na
náhradu škody a ušlý zisk pouze v případě, není-li tato náhrada škody kryta úroky z
prodlení.
7.8. Obě smluvní strany jsou oprávněny písemně odstoupit od této Smlouvy v případě
podstatného porušení povinností druhou smluvní stranou s účinky ex nunc. V tom
případě je smluvní strana odstupující od Smlouvy povinna oznámit odstoupení od
Smlouvy druhé smluvní straně bez zbytečného odkladu poté, co se o jejím
podstatném porušení smluvních povinností dozvěděla. Za podstatné porušení
smluvních povinností se rozumí zejména:
a) prodlení Objednatele se zaplacením ceny dle čl. 4 o více než 30 (slovy: třicet)
kalendářních dnů, byl-li Poskytovatelem k úhradě písemně vyzván;
b) prodlení Poskytovatele s odevzdáním díla o více než 30 dnů;
c) jestliže zkušební provoz nebyl ukončen ani do 3 měsíců ode dne předání díla do
zkušebního provozu;
d) jestliže bylo vůči Poskytovateli zahájeno řízení podle zákona č. 182/2006 Sb.,
o úpadku a způsobech jeho řešení, ve znění pozdějších předpisů nebo dle
obdobného předpisu dle místa jeho sídla;
e) jestliže Poskytovatel vstoupil do likvidace;
f) případ, kdy Poskytovatel uvedl v nabídce do výběrového řízení, na základě
kterého byla uzavřena tato Smlouva, informace nebo doklady, které neodpovídají
skutečnosti a měly nebo mohly mít vliv na výsledek výběrového řízení;
g) pokud předané Dílo nebo jeho část není kompatibilní se zařízeními objednatele
a/nebo Dílo nebo jeho část nefunguje; v takovém případě nemá zhotovitel nárok na
náhradu škody ani na náhradu účelně vynaložených nákladů
7.9. Odstoupením od Smlouvy zanikají v rozsahu jeho účinků práva a povinnosti
smluvních stran. Odstoupení od Smlouvy se nedotýká, práva na zaplacení smluvní
pokuty nebo úroku z prodlení, pokud již dospěl, práva na náhradu škody vzniklé z
porušení smluvní povinnosti, ujednání o mlčenlivosti ani ujednání, které má vzhledem
ke své povaze zavazovat smluvní strany i po odstoupení od Smlouvy, zejména
ujednání o způsobu řešení sporů. Byl-li dluh zajištěn, nedotýká se odstoupení od
Smlouvy ani zajištění.
8. Oprávnění k užití díla a SW
8.1. Vlastníkem díla vytvořeného na základě této smlouvy je od předání objednatel.
8.2. V případě, že je výsledkem činnosti Poskytovatele dle této Smlouvy dílo, které
podléhá ochraně podle autorského zákona, získává úplným zaplacením ceny dle této
Smlouvy Objednatel k takto vytvořenému dílu jako celku i kje h o jednotlivým částem
nevýhradní přenosné oprávnění k výkonu práva jej užít, a to na území celého světa
bez časového omezení, zejména, nikoli však výhradně, bez množstevního,
technologického a územního omezení, pořizovat kopie díla nebo jakékoli jeho části,
Objednávka v SAP č.: 4500853658
109150220180912125541SD232081PRO400
□ Česká televize
DMSS: 1091502/2234
provádět změny, doplňky a/nebo úpravy díla (či jakékoliv její části), včetně jeho
rozmnoženin, pro jakékoliv účely, včetně provádění změn a úprav díla. Objednatel je
oprávněn užívat takto vytvořené dílo za jakýmkoliv účelem. To platí i ohledně
veškerých technických řešení, koncepcí, know-how, postupů či metod zpracování dat,
analytických nástrojů, software, pracovní dokumentace, diagramů, schémat a
konceptů, pokud jsou vyvinuty Poskytovatelem v rámci plnění na základě této
Smlouvy a nemají charakter autorského díla. Objednatel má právo výsledek činnosti
Poskytovatele (dílo i jeho část) dle této Smlouvy neomezeně měnit či upravovat a to
i prostřednictvím třetích osob. Poskytovatel má povinnost poskytnout Objednateli
veškeré zdrojové kódy k výsledku činnosti Poskytovatele dle Smlouvy, která má
charakter počítačového programu, a to nejpozději do 10 dnů ode dne doručení
související písemné výzvy Objednatele, případně při převzetí zákaznické úpravy,
pokud byl požadavek na poskytnutí zdrojových kódů součástí objednávky
Objednatele na zákaznické úpravy. Odměna za poskytnutí oprávnění dle tohoto
ustanovení je součástí ceny za dílo dle této Smlouvy. Objednatel je oprávněn
udělovat licence a podlicence k užití díla.
8.3. Poskytovatel tímto uděluje Objednateli nevýhradní oprávnění k užití veškerého SW
použitého v rámci díla, a to bez množstevního i časového omezení (tj. na celou dobu
trvání majetkových práv k autorskému dílu) a bez jiného omezení, zejména územního
(licence).
8.4. Oprávnění dle čl. 8 je poskytnuto ode dne předání díla objednateli.
8.5. Podpisem předávacího protokolu se Objednatel stává také vlastníkem předané
dokumentace, plánů, náčrtů, výkresů, grafických zobrazení a textových určení
(specifikací) se všemi právy s tím souvisejícími.
8.6. Poskytovatel prohlašuje, že užitím díla způsobem uvedeným v tomto článku Smlouvy
Objednatel neporuší oprávněné zájmy nositelů a vykonavatelů autorských práv a práv
souvisejících dle zákona č. 121/2000 Sb„ o právu autorském, o právech souvisejících
s právem autorským a o změně některých zákonů (autorský zákon), v platném znění.
Budou-li vůči Objednateli vzneseny oprávněné nároky třetích osob, zavazuje se
Poskytovatel, že tyto nároky uspokojí a uhradí objednateli veškeré skutečně vzniklé
náklady spojené s tím, že tyto nároky byly uplatněny.
9. Kontaktní osoby
9.1. Pověřenými kontaktními osobami Objednatele v souvislosti s plněním předmětu
Smlouvy jsou:
i. ve věcech obchodních:
, vedoucí centrálního nákupu
ii. ve věcech technických:
Objednávka v SAP č.: 4500853658
109150220180912125541SD232081PRO400
C D Česká televize DMSS: 1091502/2234
vedoucí informačních technologií
, vedoucí aplikačního vývoje
9.2. Pověřenými kontaktními osobami Poskytovatele v souvislosti s plněním předmětu
Smlouvy jsou:
i. ve věcech obchodních:
ii. ve věcech technických:
9.3. Pověřené osoby a kontakty dle předchozích dvou odstavců Smlouvy, případně i údaje
dalších kontaktních nebo oprávněných osob uvedené v této smlouvě, je možné měnit
písemným oznámením doručeným druhé smluvní straně, s účinnosti ode dne
doručení takového oznámení, a to bez nutnosti uzavírat dodatek ke Smlouvě.
10.1. 10. Důvěrnost informací
Veškeré skutečnosti obchodní, výrobní, ekonomické či technické povahy související
se smluvními stranami, které nejsou běžně dostupné v obchodních kruzích a se
kterými při plnění této smlouvy přijdou smluvní strany do styku, jsou považovány za
důvěrné informace. S těmito důvěrnými informacemi budou smluvní strany nakládat
jako s vlastním obchodním tajemstvím, aniž by bylo nutné takové informace jako
důvěrné vždy jednotlivě označovat.
10.2. Smluvní strany se dohodly, že žádné ustanovení tohoto článku Smlouvy nebude
považováno ani vykládáno jako poskytnutí či přenechání jakýchkoli licencí či práv
k informacím (včetně důvěrných informací), které si smluvní strany poskytly. Tímto
ustanovením nejsou dotčena případná odchylná ustanovení týkající se dokončeného
díla podle této smlouvy.
10.3. Poskytovatel prohlašuje, že s důvěrnými informacemi jsou oprávněny disponovat
výhradně jeho následující zaměstnanci:
10.4. Poskytovatel se zavazuje, že veškeré důvěrné informace, které od Objednatele získal
/získá, budou použity výhradně pro plnění účelu, ke kterému budou Objednatelem
určeny a že osoby uvedeny v předchozím odstavci Smlouvy budou s poskytnutými
důvěrnými informacemi zacházet v souladu s touto Smlouvou.
10.5. Poskytovatel se zavazuje používat k ochraně před neoprávněným užíváním,
poskytnutím, zveřejněním nebo šířením důvěrné informace přiměřené péče, avšak v
Objednávka v SAP č.: 4500853658
109150220180912125541SD232081PRO400
C D Česká televize
DMSS: 1091502/2234
žádném případě ne v menší míře než je míra péče, kterou využívá k ochraně svých
důvěrných informací, které jsou podobného významu. Poskytovatel může poskytnout
či zpřístupnit jakoukoli důvěrnou informaci třetí straně, která nebyla adresátem
důvěrné informace, pouze po obdržení písemného souhlasu Objednatele.
Poskytovatel se zavazuje vynaložit maximální úsilí, které po něm lze spravedlivě
požadovat, aby tajnost důvěrných informací byla důsledně dodržována jeho
zaměstnanci i osobami, které případně, v souladu s dohodou uzavřenou s
Objednatelem, k plnění účelu spolupráce použije.
10.6. Závazky obsažené v tomto článku Smlouvy se nevztahují na důvěrné informace,
které jsou v době jejich poskytnutí veřejně dostupné nebo které se po jejich
poskytnutí smluvní stranou stanou oprávněně a bez porušení této Smlouvy
dostupnými veřejnosti. Závazky obsažené v tomto článku Smlouvy se nevztahují na
důvěrné informace, které byly písemným souhlasem obou smluvních stran z těchto
závazků vyjmuty. Smluvní strany výslovně konstatují, že uveřejněním informací
z důvodu povinnosti vyplývající z právních předpisů není porušen závazek chránit
důvěrné informace v souladu s tímto článkem Smlouvy.
10.7. Na základě písemné žádosti Objednatele je Poskytovatel povinen:
a) odevzdat Objednateli veškeré důvěrné informace poskytnuté Objednatelem,
všechny dokumenty nebo média obsahující důvěrné informace a veškeré jejich
kopie či zápisy, nebo
b) zničit důvěrné informace poskytnuté Objednatelem, všechny dokumenty nebo
média obsahující důvěrné informace a veškeré jejich kopie či zápisy a dodat
Objednateli písemné osvědčení o jejich zničení podepsané oprávněným
zástupcem Poskytovatele.
11.1. 11. Ochrana osobních údajů
V případě, že při plnění této Smlouvy budou zpracovávány osobní údaje podle
právních předpisů upravujících ochranu osobních údajů, zavazuje se Poskytovatel
plnit všechny povinnosti stanovené právními předpisy, zejména nařízením
Evropského parlamentu a rady (EU) 2016/679, o ochraně fyzických osob v souvislosti
se zpracováním osobních údajů a o volném pohybu těchto údajů a o zrušení
směrnice 95/46/ES (obecné nařízení o ochraně osobních údajů), a informovat
Objednatele bez zbytečného odkladu o všech okolnostech významných pro plnění
povinností vyplývajících z ochrany osobních údajů. Poskytovatel je povinen zejména
přijmout taková opatření, aby nemohlo dojít k neoprávněnému nebo nahodilému
přístupu neoprávněných osob k osobním údajům, ke změně, zničení či ztrátě
osobních údajů, k neoprávněným přenosům osobních údajů, k jinému
neoprávněnému zpracování osobních údajů či zneužití osobních údajů. Poskytovatel
se zavazuje zachovat mlčenlivost o všech osobních údajích a o bezpečnostních
opatřeních přijatých k zabezpečení ochrany osobních údajů u objednatele, a to i po
skončení smluvního vztahu. Poskytovatel je povinen poskytnout Objednateli veškerou
potřebnou součinnost a podklady zejména v případě jednání s Úřadem pro ochranu
osobních údajů nebo s jinými veřejnoprávními subjekty. Poskytovatel se zavazuje
Objednávka v SAP č.: 4500853658
109150220180912125541SD232081PRO400
C D Česká televize
DMSS: 1091502/2234
nahradit Objednateli a třetím osobám újmu, která vznikne v důsledku porušení
povinností vyplývajících z ochrany osobních údajů, a to včetně škody způsobené
uložením pokuty Úřadem pro ochranu osobních údajů Objednateli. V případě
porušení tohoto závazku Poskytovatelem je Objednatel oprávněn požadovat smluvní
pokutu ve výši 100.000,- Kč za každé porušení povinnosti, přičemž uhrazením
smluvní pokuty není dotčen nárok na náhradu škody. Povinnosti a odpovědnost dle
tohoto odstavce dopadají na Poskytovatele i v případě, že škodu způsobil jeho
zaměstnanec nebo smluvní partner či s ním spolupracující osoby.
11.2. Ustanovení předchozího odstavce Smlouvy se nevztahuje na skutečnosti nebo
informace označované jako obchodní tajemství nebo důvěrné informace, pokud je
jejich poskytnutí třetím stranám nebo zveřejnění nutné na základě požadavků
právního řádu České republiky.
12.1. 12. Vyšší moc
Obě Smluvní strany jsou zproštěny v přiměřeném rozsahu smluvních závazků, pokud
jejich plnění brání vyšší moc. Za vyšší moc pro účely této Smlouvy bude považována
zejména živelná pohroma a válečný konflikt v místě Staveniště nebo v místě sídla
Zhotovitele. V tomto případě je možno plnění dotčených smluvních závazků Smluvní
strany zastavit na dobu nezbytně nutnou na základě písemného oznámení druhé
Smluvní straně.
13.1. 13. Závěrečná ujednání
Jakékoliv změny či doplňky k této Smlouvě je možné provádět výlučně číslovanými
písemnými dodatky podepsanými zástupci obou smluvních stran.
13.2. Tato smlouva se řídí právním řádem České republiky, zejména příslušnými
ustanoveními Občanského zákoníku.
13.3. Poskytovatel se zavazuje jako postupitel nepřevést svá práva a povinnosti ze
Smlouvy nebo z její části třetí osobě.
13.4. V případě, že se ke kterémukoli ustanovení této Smlouvy či k jeho části podle
Občanského zákoníku jako ke zdánlivému právnímu jednání nepřihlíží, nebo že
kterékoli ustanovení této Smlouvy či jeho část je nebo se stane neplatným,
neúčinným a/nebo nevymahatelným, oddělí se v příslušném rozsahu od ostatních
ujednání této Smlouvy a nebude mít žádný vliv na platnost, účinnost a vymahatelnost
ostatních ujednání této Smlouvy. Smluvní strany se zavazují nahradit takové
zdánlivé, nebo neplatné, neúčinné a/nebo nevymahatelné ustanovení či jeho část
ustanovením novým, které bude platné, účinné a vymahatelné a jehož věcný obsah a
ekonomický význam bude shodný nebo co nejvíce podobný nahrazovanému
ustanovení tak, aby účel a smysl této Smlouvy zůstal zachován.
13.5. Smluvní strany se dohodly, že § 577 Občanského zákoníku se nepoužije. Určení
množstevního, časového, územního nebo jiného rozsahu v této Smlouvě je pevně
Objednávka v SAP č.: 4500853658
109150220180912125541SD232081PRO400
C D Česká televize
DMSS: 1091502/2234
určeno autonomní dohodou smluvních stran a soud není oprávněn dohodu smluvních
stran v tomto smyslu měnit.
13.6. Dle § 1765 Občanského zákoníku na sebe Poskytovatel převzal nebezpečí změny
okolností. Před uzavřením Smlouvy smluvní strany zvážily hospodářskou,
ekonomickou i faktickou situaci a jsou si plně vědomy okolností Smlouvy.
Poskytovatel není oprávněn domáhat se změny Smlouvy v tomto smyslu u soudu.
13.7. Veškerá oznámení podle této Smlouvy musí být učiněna písemně a zaslána kontaktní
osobě druhé smluvní strany prostřednictvím elektronické pošty, faxu nebo
doporučenou poštou, případně předána osobně, není-li ve Smlouvě výslovně
uvedeno jinak.
13.8. Smluvní strany se dohodly, že zvyklosti nemají přednost před ustanoveními této
Smlouvy ani před ustanoveními zákona.
13.9. Smluvní strany se dohodly, že smluvním jazykem je jazyk český, a že v českém
jazyce bude probíhat veškerá komunikace ve všech věcech týkající se této Smlouvy.
13.10. Smluvní strany se dohodly, že veškeré sporné záležitosti, které se vyskytnou a budou
se týkat závazků vyplývajících z této Smlouvy, budou řešeny dohodou. Případnému
soudnímu sporu z této Smlouvy bude předcházet snaha smluvních stran o řešení
sporu smírem. Smluvní strany se dohodly ve smyslu ustanovení § 89a zákona č.
99/1963 Sb., občanský soudní řád, v platném znění, že v případě řešení sporů soudní
cestou bude místně příslušným soudem Obvodní soud pro Prahu 4, popřípadě
Městský soud v Praze. Pro zamezení jakýchkoli pochyb smluvní strany konstatují, že
pro řešení sporů sjednávají výlučnou jurisdikci českých soudů.
13.11. Tato Smlouva je vypracována v 5 (pěti) stejnopisech, z nichž 3 (tři) stejnopisy obdrží
Objednatel a 2 (dva) stejnopisy obdrží Poskytovatel.
13.12. Tato smlouva nabývá platnosti dnem podpisu poslední smluvní strany. Účinnosti pak
tato smlouva nabývá dnem jejího uveřejnění podle zákona č. 340/2015 Sb., o
zvláštních podmínkách účinnosti některých smluv, uveřejňování těchto smluv a o
registru smluv (zákon o registru smluv), ve znění pozdějších předpisů. Smluvní strany
berou na vědomí, že v souladu s ustanovením § 219 zákona č. 134/2016 Sb., o
zadávání veřejných zakázek, v platném znění, budou Smlouva a další skutečnosti dle
uvedeného ustanovení uveřejněny na profilu zadavatele.
13.13. Smluvní strany prohlašují, že vymezení předmětu Smlouvy a ceny, případně hodnoty
předmětu Smlouvy na titulní straně této Smlouvy nemá normativní význam a uvádí se
zde pouze pro účely provedení uveřejnění této Smlouvy v registru smluv.
Objednávka v SAP č.: 4500853658
109150220180912125541SD232081PRO400
C D Česká televize
DMSS: 1091502/2234
13.14. Poskytovatel tímto prohlašuje, že ke dni podpisu této smlouvy plní veškeré povinnosti
vyplývající ze zákona č. 348/2005 Sb., o rozhlasových a televizních poplatcích, ve
znění pozdějších předpisů (dále jen „ZRTVP“), zejména § 7 a 9 ZRTVP, a zavazuje
se tyto povinnosti plnit po celou dobu účinnosti této smlouvy. Poskytovatel se
zavazuje poskytnout ČT na vyžádání součinnost a informace k prokázání plnění
povinnosti podle tohoto odstavce, a to zejména sdělením variabilního symbolu nebo
jiného identifikátoru, pod nímž zhotovitel hradí televizní poplatek či uvedením
zákonného důvodu osvobození od úhrady televizního poplatku.
13.15. Nedílnou součástí této smlouvy jsou následující Přílohy:
Příloha č. 1 - Specifikace předmětu plnění,
Příloha č. 2 - Rozpad odhadů pracnosti.
Smluvní strany souhlasně prohlašují, že si tuto smlouvu pozorně přečetly, že je ji obsah je
srozumitelný a určitý, a že jim nejsou známy žádné důvody, pro které by tato smlouva
nemohla být smluvními stranami uzavřena a závazky z ni řádně plněny a nejsou jim známy
žádné důvody, které by způsobovaly neplatnost této smlouvy. Na znamení toho, že
s obsahem této smlouvy bez výhrad a ze své svobodné a vážné vůle souhlasí, a že smlouva
nebyla uzavřena v tísni ani za jinak jednostranně nevýhodných podmínek, připojují smluvní
strany své podpisy níže.
V Praze dne ...ít:? .:...................2018 V Praze d n e../? ? .^:...^...... 2018
Za Objednatele: Za Poskytovatele:
Čes ADASTRA, s.r.o.
Petr Dvořák Pavel Kysela
Generální ředitel Jednatel
Objednávka v SAP č.: 4500853658
109150220180912125541SD232081PRO400
G Česká televize
SPECIFIKACE POŽADOVANÉHO ŘEŠENÍ
stránka 1/41
OBSAH
OBSAH.............................................................................................................................................................. 2
1 ÚVOD.......................................................................................................................................................... 3
1.1 CÍL DOKUMENTU....................................................................................................................................3
1.2 Související dokumenty.......................................................................................................................3
1.3 Použité pojmy a zkratky....................................................................................................................3
2 DEFINICE PROJEKTU...............................................................................................................................5
2.1 Důvod realizace projektu.................................................................................................................5
2.2 CÍL PROJEKTU.......................................................................................................................................5
2.3 Požadované Výstupy Projektu....................................................................................................... 5
2.4 Bezpečnostní požadavky.................................................................................................................. 5
3 SPECIFIKACE POŽADAVKŮ NA ŘEŠENÍ..............................................................................................6
3.1 Business architektura..................................................................................................................... 6
3.1.1 Reportíng.....................................................................................................................................6
3.2 Aplikační a datová architektura.....................................................................................................6
3.2.1 Požadavky na Aplikační architekturu........................................................................................7
3.2.2 Požadavky na Datovou architekturu řešení a integrace........................................................ 20
3.2.3 Požadavky na Přístup uživatele...............................................................................................21
3.3 Požadavky na Technologickou architekturu........................................................................... 23
4 POŽADAVKY NA REALIZACI A NASTAVENÍ......................................................................................24
4.1 Aplikace............................................................................................................................................24
4.1.1 Autentizace a autorizace........................................................................................................... 26
4.1.2 Požadavky na Migraci dat........................................................................................................ 26
4.1.3 Popis release aplikace............................................................................................................. 26
4.2 Požadavky na Infrastrukturu......................................................................................................26
4.2.1 Technologické komponenty.....................................................................................................26
5 POŽADAVKY NA TESTOVÁNÍ A ŠKOLENÍ..........................................................................................27
5.1 Nástroj pro řízení testování......................................................................................................... 27
5.2 DEFINICE TESTOVACÍCH SCÉNÁŘŮ..................................................................................................27
5.2.1 Uživatelské aplikační testy.......................................................................................................27
5.2.2 Testy infrastruktury.................................................................................................................. 31
5.2.3 Bezpečnostní a penetrační testy.............................................................................................31
5.3 ŠKOLENÍ.............................................................................................................................................31
5.4 POŽADAVKY NA DOHLED ŘEŠENÍ...................................................................................................... 32
5.4.1 Aplikační dohled....................................................................................................................... 32
5.4.2 Infrastrukturní dohled............................................................................................................... 34
5.5 Požadovaná Součinnosi................................................................................................................ 34
5.6 Požadavky na Akceptačn! kritéria................................................................................................39
6 PŘÍLOHY..................................................................................................................................................41
stránka 2/41
1 UVOĎ
1.1 CÍL DOKUM ENTU
Cílem dokumentu je detailní zadání pro realizaci ICT řešení. Dokument v sobě zahrnuje požadavky na
funkční, technickou, bezpečností a architektonickou specifikaci včetně akceptačních kritérií.
1.2 SOUVISEJÍCÍ DOKUMENTY
1.3 POUŽITÉ POJMY A ZKRATKY
Pojem / Popis
Zkratka
AD Active Directory (adresářová služba)
ALE Application Link Enabling, technologie SAP pro integraci.
API Aplikační programové rozhraní
APM Access Policy Manager
AS-IS současný stav
BE Best effort - Obnova dle možností provozovatele. Není stanoven čas obnovy.
Bl Business Intelligence
BK+(X,Y,Z)
BLOB Bezpečnostní klasifikace, hodnoty X, Y, Z jsou hodnoty výsledné klasifikace z pohledu
CBIS dostupnosti, důvěrnosti a integrity v uvedeném pořadí.
Binary Large Object - označení pro datový typ blíže nespecifikovaných binárních dat
v databázi
Centrální bezpečnostní informační systém
CK Cílový koncept
CO NT Continuous backup - Kontinuální zálohování, použití např. transakčních logů.
CPU Central Processing Unit (procesor serveru)
CSOM Client Object Model
CSV Označení pro textový soubor, v němž jsou jednotlivé hodnoty oddělovány znakem čárky
ČT Česká televize
DB Database
DDP Definiční dokument projektu
DEV vývojové prostředí
DLL Dynamic-link library, dynamicky linkovaná knihovna
DMS Document Management System - systém pro správu dokumentů
DNS Domain Name System
DT Datový tým
DTC Microsoft Distributed Transaction Coordinator
stránka 3/41
DWH Data Warehouse
EE Enterprise Edition
Zákazník Koncový uživatel řešení, pro nějž se řešení realizuje.
stránka 4/41
2 DEFINICE PROJEKTU
2.1 DŮVOD REALIZACE PROJEKTU
Business uživatelé ČT na základě analýzy požadavků na inovace a na základě stanovení strategie
modernizace informačních systémů poskytující silnější podporu business uživatelům identifikovali potřebu
zavést jednotný Datový sklad České Televize a jeho nadstavby formou Business Intelligence platformy pro
poskytování reportingových a analytických služeb uživatelům. Důraz je kladen na standardní řešení
s referenční architekturou, které je možné dále rozšiřovat a integrovat s dalšími systémy.
2.2 CÍL PROJEKTU
Jednotné reportingové řešení pro Bl v ČT. Řešení Bl bude integrovat dva datové zdroje PN26 a databáze
poplatníků.
2.3 POŽADOVANÉ VÝSTUPY PROJEKTU
Výstup dodávky musí zahrnovat:
• Funkční ETL vrstva - pro správu a řízení ETL procesů budou využity nástroje SSIS (Microsoft) a
vybraného nástroje ETL Framework.
• Funkční datový sklad - dle obvyklého konceptu třívrstvé architektury datového skladu (LO, L1, L2)
• Business Intelligence prostředí
• Přístupová vrstva Bl
• Reporty (2 reporty)
• Školení super uživatelů (max. 10) v rámci dodávaného řešení (maximální rozsah 3 dny).
• Dokumentace skutečného provedení, Administrátorská příručka, Uživatelská příručka
2.4 BEZPEČNOSTNÍ POŽADAVKY
Projekt musí být dodán v souladu se stávajícími pravidly IT bezpečnosti ČT.
Oblast řízení přístupu:
• Autentizace bude probíhat prostřednictvím účtu z Active Directory s využitím jednotného přihlášení.
• Přístupy musí být řízeny pomocí business rolí a aplikačních rolí přiřazených uživateli.
• Přenos hesel musí být vždy šifrován.
• Systém musí mít popsanou autorizační politiku v samostatném dokumentu autorizační koncept dle
pravidel IT oddělení ČT.
Oblast infrastrukturní bezpečnosti:
• Každý pokus (úspěšný i neúspěšný) o použití identifikačních a autentizačních údajů by měl být
zaznamenán. Pokud počet neúspěšných pokusů o autentizaci překročí za určitou časovou jednotku
určitý počet pokusů, musí být toto považováno za bezpečnostní incident.
Oblast vývoje:
• Vývojové, testovací a produkční prostředí musí být odděleno.
stránka 5/41
3 SPECIFIKACE POŽADAVKŮ NA ŘEŠENÍ
3.1 BUSINESS A R C H ITEK TU R A
3.1.1 REPORTING
Projekt definuje novou Bl platformu, která bude nově využívána pro tvorbu a zpřístupňování sestav,
formulářů a tiskových výstupů.
V rámci řešení DWH/BI platformy musí být definována a zprovozněna technologická infrastruktura a
vytvořeny 2 vzorové sestavy pro stávající dva reporty:
• Počet TV a poplatníků
• Rozdělení pohledávek podle stáří
Definice reportů je uvedena v dalších kapitolách.
3.2 APLIKAČNÍ A DATOVÁ ARCHITEKTURA
Datové zdroje Datový sklad České Televize - TVP Uživatelé
Metadata management ¡IÜ MS Internet
Case to o l (PowerDesigner, Enterprise Architect), Explorer
SQL Server 2016 Database Engine. SQL Server 2016 A nalysis Services Prezentace dat
Reports Metadata %
Transformation metadata management
DWH Log MS Excel 2013+
Získáváni dat Datový sklad %
MS SQL Server 2016 MS Report Designer
A nalysis services API
*
MS SQL Server 2016
Integration Services, MS SQL
Klientské nástroje
Database Engine
*
MS SQL Server 2016 MS SQL Server 2016 Další nástroje
A nalysis Services Reporting Services
Report Builder 3
Power Bl Tools ^
f it
A dm in istra ce Vývoj
SQL Agent Database Tuning Advisor MS Business intelligence Studio 2016 Adm inis trsce
Database Mail SQL Server Client Tools
Management Studio Resource Governor ^3 MS Visual Studio 2013+ %
Policy management Other
Profiler Windows Server 2012 ■ éS í Vývoj
Active Directory tjjjP IH
Backup
_J
Obrázek 1: Požadavek na konceptuální logické schéma
V rámci dodávky je požadováno, aby řešení DWH/BI bylo založeno na stavbě klasického třívrstvého
datového skladu s podporou OLAP vrstvy, nad kterým bude postavena standardní multifunkční Bl
platforma podporující různé formy a účely výstupů. Datová integrace musí být postavena na univerzálním
řídícím workflow podporovaném vhodným ETL nástrojem poskytujícím standardizované ETL/ELT rozhraní
pro načítání dat do DWH.
Bl vrstva musí mít zároveň i information delivery funkci pro data zdrojových systémů, které DWH nebude
dočasně nebo trvale obsahovat.
stránka 6/41
3.2.1 POŽADAVKY NA APLIKAČNÍ ARCHITEKTURU
Oblast BI/DWH
Podstatou dodaného řešení musí být zprovoznění Bl platformy, která umožní oprávněným uživatelům
získávat informace potřebné pro jejich práci.
Jednotlivé Bl nástroje (viz níže) musí čerpat data z datového skladu (DWH), který bude v rámci řešení za
tímto účelem pro definované věcné oblasti vybudován. Je požadováno, aby přístup Bl nástrojů byl pouze
do vrstev L1 a L2 datového skladu, přímý přístup do primárních systémů bude pouze v situacích nutnosti
zobrazovat reporty nad aktuálními daty.
Celé řešení musí být koncipováno jako BI/DWH prostředí, které je ze své podstaty otevřené pro rozšiřování
o další primární (zdrojové) systémy, zpracovávání jejich dat a integraci těchto dat s daty z jiných systémů.
Návrh jednotlivých logických komponent Česká Televize - Datový sklad & Bl platforma
Aplikační servery
Zdrojová data
Reporty DWH
Databázové servery
Stage dbs Multidimenzionální mód
DWH (L1 + 12)
ETL Server
IR Síil
Obrázek 2: Požadavek na fyzickou architekturu řešení
Následující tabulka popisuje jednotlivé logické komponenty, které by měly být součástí dodaného řešení
vybudované na dodávané platformě. Z tohoto pohledu jsou proto jednotlivými komponentami i „reporty“.
stránka 7/41
Tab: Seznam aplikací, které je nutné upravit/nově vytvořit a stručný popis funkčnosti těchto změn/nových
aplikací.
Aplikace Popis funkčností (změna/nová) Uživatel aplikace
(stávající/nová) (zákazník/ICTS)
Relační databáze využívaná pro načítání
DWH LO - Stage dat do DWH ze zdrojových systémů ČT IT
vrstva (SS14)
DWH L1 - Relační Relační databáze využívaná pro ČT IT
vrstva (SS14) udržování transformovaných dat DWH
v normalizované podobě
DWH L2 - Relační Relační databáze využívaná pro efektivní ČT IT
datamarty (SS14) distribuci dat DWH pro vybrané věcné ČT IT
oblasti
DWH L2 - OLAP
datamarty (SSAS) OLAP databáze (kostky) pro efektivní
distribuci dat DWH pro vybrané věcné
oblasti (např. nákladové ukazatele pro
reporty údržby, KPI datamart)
ETL server (SSIS) Server pro řízení běhu loadů dat ze ČT IT
zdrojových systému do jednotlivých
Bl - Reporty SSRS vrstev DWH. Uživatel (zobrazování), ČT
nad DWH IT (vytváření)
Pixel-perfect reporty vytvářené
v Reporting Services z dat uložených
v DWH
DWH - Vývojové Vývojové prostředí, ve kterém vývojáři ČT IT (vytváření)
prostředí pro návrh definují databázové struktury DWH a ČT IT (vytváření)
relačních databází které používají psaní a spouštění SQL
LO, L1, L2 dotazů do těchto dat
DWH - Vývojové Vývojové prostředí, ve kterém vývojáři
prostředí pro návrh definují OLAP struktury L2 DWH (kostky)
OLAP datamartů L2 -
SSAS
DWH - Vývojové Vývojové prostředí, ve kterém vývojáři ČT IT (vytváření)
prostředí pro návrh
ETL transformací dat definují ETL transformace OLAP struktury
L2 DWH (kostky)
Bl - Vývojové Vývojové prostředí, ve kterém vývojáři ČT IT (vytváření)
prostředí pro tvorbu definují reporty SSRS a ze kterého tyto
reportů SSRS reporty také nasazují (deploy) na Report
Server
Definice datových Definice datových zdrojů, které jsou ČT IT (vytváří i využívá při
zdrojů využívány v jednotlivých reportech SSRS tvorbě ostatních prvků
řešení)
Zdrojová data ZIS Stávající systém V rámci projektu bude
využíván pouze pro čtení
dat
Zdrojová data PN26 Stávající systém V rámci projektu bude
využíván pouze pro čtení
dat
stránka 8/41
3.2.1.1 Požadavky na nastavení systému
V této kapitole jsou popsány požadavky na systémové nastavení (konfigurace) komponent (viz dále kap.
3.3) pro jejich výše popsané využití.
3.2.1.1.1 Požadavky na oblast databází DWH
Pro zprovoznění databází DWH je požadováno, aby byla provedena tato standardní nastavení/instalace:
Instalace relačního databázového serveru datového skladu (MS SQL Server 2016 Enterprise
Edice), kde bude umístěná databáze nebo více databází DWH. Požaduje se oddělit databáze pro
Stage vrstvu a databáze pro L1 a/nebo L2 vrstvu
Server a databáze musí být nakonfigurovány pro účely DWH workloadu, nikoliv OLTP workloadu.
Instalace OLAP databázového serveru (MS Analysis Services 2016) v multidimenzionálním módu
pro tvorbu datových kostek
Dále musí být provedena instalace vývojových nástrojů pro správu těchto serverů
Vývojové prostředí pro správu relačního databázového serveru (MS SQL Server Management
Studio)
Vývojové prostředí pro správu OLAP serveru (Data Tools for Bl for Visual Studio)
3.2.1.1.2 Požadavky na oblast ETL
Pro zprovoznění ETL jsou požadována tato standardní nastavení/instalace:
Instalace relačního databázového serveru datového skladu (MS SQL Server 2016 Enterprise
Edice)
Instalace ETL funkcionality (Integration Services 2016) pro řízení loadů dat
Implementace a nastavení ETL, které musí čerpat mappingy z metadat uložených v relační
databázi, stejně jako nastavení workflow.
Implementované ETL musí obsahovat správu monitorovací rozhraní pro sledování běhu ETL, jeho
spolehlivosti a výkonnosti. Monitorovací rozhraní jednoduchým způsobem musí poskytnout
uživateli informaci o konkrétních chybách na úrovni popsané v kapitole zabývající se požadavky na
monitorování ETL.
Dále musí být provedena instalace vývojových nástrojů pro správu těchto serverů
Vývojové prostředí pro správu integračních služeb (Data Tools for Bl for Visual Studio)
Vývojové prostředí pro správu OLAP serveru (Data Tools for Bl for Visual Studio)
3.2.1.1.3 Požadavky na Bl Portál obecně
V rámci projektu je požadována následující konfigurace služeb:
Pro zobrazení Bl dat (KPI, reporty v Excelu nebo reporty pomocí SSRS) se budou aktivovány následující
funkce:
Report Server (Reporting Services v standalone módu)
3.2.1.1.4 Požadavky na oblast reportingu a dashboardů
Pro zprovoznění reportingu v prostředí portálu jsou požadována tato standardní nastavení/instalace:
Instalace report serveru (Reporting Services 2016)
Dále je požadována instalace vývojových nástrojů pro tvorbu a publikaci reportů na report server
Vývojové prostředí pro tvorbu reportů (Data Tools for Bl for Visual Studio)
Vývojové prostředí pro správu OLAP serveru (Data Tools for Bl for Visual Studio)
3.2.1.1.5 Požadavky na návrh a implementaci struktur DWH L0, L1, L2
Popis této kapitoly se týká následujících oblastí:
oblast pro Offline reporty ze vzorových 2 reportů
stránka 9/41
Požadavky na struktury DWH LO - databáze Stage_PN26
Do LO vrstvy je požadováno plnění následujících tabulek ze systému PN26. Model databáze Stage_PN26
se jmenuje STAGE_PSDT.
Název tabulky Schéma Orientační Popis
VSOP TRI počet řádků
Tabulka slouží k uložení
NEW_STAT TRI 8000 stavu soudních
ZAL, ZAL3, ZAL5, ... až ZAL28 TRI poplatků
FILE3P TRI 854000
FILE_D TRI 126000 Tabulka slouží k uložení
221000 stavů žalovaných
případů
12000
Tabulka slouží k uložení
žalovaných případů.
Tabulka slouží k uložení
Data od AK - soubor P.
Tabulka slouží k uložení
Data od AK - soubor D.
class PN26 /
SOP_STATI ŠTIKA Q DATA_AK_P Q
«column» «oolumn*
* VS VS
DATUM * JMÉNO
TYP * JISTINA
TEXT1
TEXT2 ÚROK
CASTKA SOP
* VYLOHY
PŘEPLATEK
* OBDOBÍ
VLNA
DATUM
ID
S O U O _ZALO B_PR IPADY Q
«column»
* VS
" JMÉNO
PŘEDÁNO
ZALOVANO
ZNACKA1
2NACKA2
Obrázek 3: Požadavek na podobu LO Stage_PN26
V rámci implementace je požadováno, aby do databáze Stage_ZIS byly nahrávány následující objekty,
jejich model se jmenuje Stage_ZIS
stránka 10/41
Název tabulky Schéma Orientační Popis
PARTNER počet řádků
POPLATNÍK Tabulka slouží k uložení
partnera.
př ijím ač e
Tabulka slouží
PREDCHOZI_VS k evidenci poplatníka.
OSLOVENY
PŘEDPIS Tabulka slouží
PREDPIS_PRIJIMACE k evidenci počtu
PLATBA přijímačů u poplatníka.
PLATBA_P RIRAZEN I
Tabulka slouží
ZRUSENA_PRIRAZENI k evidenci změn VS u
AKCE poplatníka
Tabulka slouží
AKCE_PRI POJENI k evidenci oslovených
UPOMÍNKA
UPOMINKA_PREDPISY subjektů
Tabulka slouží
NEPRIRAZENE_PLATBY
NEVYROVANANE_POLOZKY k evidenci
předepsaných úhrad
Tabulka slouží
k evidenci vazby
předpis a přijímač
Tabulka slouží
k evidenci plateb
Tabulka slouží
k evidenci přiřazení
platby k poplatníku
Tabulka slouží
k evidenci změn
přiřazení plateb u
poplatníka
Tabulka slouží
k evidenci obesílacích
akcí
Tabulka slouží
k evidenci vazby akce
na poplatníka resp.
partnera
Tabulka slouží
k evidenci upomínek
Tabulka slouží
k evidenci vazby mezi
upomínkou a
předpisem
Tabulka slouží
k evidenci
nepřiřazených plateb
Tabulka slouží
k evidenci
nevyrovnaných položek
stránka 11/41
PRAVNI_RESENI Tabulka slouží
RESENI_PREDPISY k evidencí právních
případů
Tabulka slouží
k evidencí vazby
předpisů na právní
případ
Obrázek 4: Požadavky na podobu LO Stage_ZIS
Požadavky na struktury DWH L1 - databáze DWH
V L1 vrstvě je požadováno, aby byly tabulky, které budou vycházet z dat LO vrstvy. Na základě analýzy
v rámci projektu musí být vytvořena integrovaná vrstva DWH založená na tabulkách, které jsou potřeba pro
vytipované offline reporty. Návrh musí splňovat následující požadavky:
Umožnit tvorbu dalších adhoc reportů z dat, která jsou ve vytipovaných reportech používána.
Nastínit další směry rozšiřování L1 vrstvy.
stránka 12/41
Požadavek na vytvoření jednotlivých dimenzionálních a faktových tabulek je popsán níže v tabulce.
Schéma DWH musí definovat, že se jedná o sdílené dimenze, které budou moci využít i jiné části datového
skladu a přes tyto dimenze potom musí být možné spojit hodnoty ostatních částí datového skladu.
Dimenzionální tabulky musí být označeny předponou TD_, faktové tabulky musí označit předponou TF_.
Název tabulky Schéma Popis
TD DATUM DWH Časová dimenze
TD_PARTNER TVP Tabulka slouží k uložení partnera.
TD_POPLATNIK TVP Tabulka slouží k evidenci poplatníka.
TVP Tabulka slouží k evidenci počtu přijímačů u
TF_PRIJIMACE poplatníka.
Tabulka slouží k evidenci změn VS u poplatníka
TD_PREDCHOZI_VS TVP Tabulka slouží k evidenci oslovených subjektů
Tabulka slouží k evidenci předepsaných úhrad
TD_OSLOVENY TVP Tabulka slouží k evidenci vazby předpis a přijímač
Tabulka slouží k evidenci plateb
TF_PREDPIS TVP Tabulka slouží k evidenci přiřazení platby k
poplatníku
TF_PREDPIS_PRIJIMACE TVP Tabulka slouží k evidenci změn přiřazení plateb u
poplatníka
TF_PLATBA TVP Tabulka slouží k evidenci obesílacích akcí
Tabulka slouží k evidencí vazby akce na poplatníka
TVP resp. partnera
TD_PLATBA_PRIRAZENI Tabulka slouží k evidenci upomínek
Tabulka slouží k evidenci vazby mezi upomínkou a
TVP předpisem
TD_ZRUSENA_PRI RAZENI Tabulka slouží k evidenci nepřiřazených plateb
Tabulka slouží k evidenci nevyrovnaných položek
TD_AKCE TVP Tabulka slouží k evidenci právních případů
Tabulka slouží k evidenci vazby předpisů na právní
TVP případ
TD_AKCE_PRI POJENI Tabulka slouží k uložení stavu soudních poplatků
Tabulka slouží k uložení Stavy soudních případů
TFJJPOMINKA TVP Tabulka slouží k uložení stavu soudních/žalovaných
případů.
TVP Tabulka slouží k uložení stavu soudních poplatků
TF_UPOMINKA_PREDPISY Tabulka slouží k uložení Data od AK - soubor D.
Tabulka slouží k uložení Data od AK - soubor P.
TD_NEPRIRAZENE_PLATBY TVP
TF_NEVYROVANANE_POLOZKY TVP
TD_PRAVNI_RESENI TVP
TVP
TF_RESENI_PREDPISY
TF_SOP TVP
TD SOP STATISTIKA TVP
TF_VLNA_ZALOBY TVP
TF_SOUD_ZALOB_PRIPADY TVP
TF_DATA_AK_D TVP
T F_DATA_AK_P TVP
Je požadováno, aby výběr a definice tabulek v modelu vycházela primárně ze 2 off-line reportů s důrazem
na to, aby se mohl dále rozšiřovat v rámci skupiny . Faktové tabulky musí být navrženy tak, aby mohli být
použitelné i v dalších reportech.
Transformace do L1 vrstvy musí probíhat pomocí nástroje ETL Frameworku. V rámci této transformace je
požadováno, aby byly přiřazovány primární klíče, cizí klíče a implementovány transformace, které jsou ve
zdrojových systémech naprogramovány pomocí databázových funkcí.
stránka 13/41
d -
i*yrrr ca
s»r.*.
* tvr’ -
¡ÜÈüSl
„~
----- «
»It««
VrWMfG
■¿¡ížSST—«
Obrázek 5: Požadavek na podobu L1
Požadavky na struktury DWH L2 - OLAP
Je požadováno, aby L2 vrstva DWH byla vystavěna v prostředí SSAS včetně sémantické vrstvy. SSAS
musí data z L1 vrstvy načítat prostřednictvím databázových views, která budou všechna vytvořena
v dedikovaném schématu OLAP v databázi DWH.
Název viewu Schéma Popis
VD DATUM OLAP
VD DŮVOD ODHLÁŠENI OLAP
VD DŮVOD VYSTAVENI OLAP
VD PARTNER POPLATNÍK OLAP
VD PŘEDPIS OLAP
VD SAZBA OLAP
VD STAV PRÁVNÍ ŘEŠENI OLAP
VD_ TYP PODANÍ OLAP
VD TYP PŘEDPISU OLAP
VD TYP UPOMÍNKY OLAP
VD UČET OLAP
VD ZDROJ PLATBY OLAP
stránka 14/41
Název viewu Schéma Popis
VD ZPŮSOB ODHLÁŠENI OLAP
VF NEVYROVNANÉ POLOŽKY OLAP
VF PLATBA OLAP
VF PRÁVNÍ ŘEŠENI OLAP
VF PŘEDPIS OLAP
VF PŘIJÍMAČ OLAP
VF UPOMÍNKA OLAP
*7~ V F .P L A T B A VD.OATUM
«coium n»
□ VO_PARTH E R .P O P L A T N iK «coiumn» *PK DATUM
* CASTKA.PLATBY
«oolumn» * DATUM.DOKLADU PRVNI_DATUM_MESICE
* DATUM.PLAT6Y POSLEDNl.DATUM.MESfCE
©.PARTNERA D E N .N A Z E V
TYP.PARTNERA DEN_NAZEV_ZKRACENY
POHLAVÍ CISLO_DNE_V_MESICl
DATUM_NAROZENI C IS L O .D N E .V .T Y D N U
ICO CISLO_QN£_V_ROCE
STÁT R R R R .M M
KRAJ RRRR.CC
OKRES PRACOVNI_DEN_ZNACKA
OBEC S V A T E K .Z N A C K A
OSEC_UIR_KOD «PK»
CAST.OBCE -* PK.TD.DATUM O
ULICE
ULICE.UIP._KOO □ VD ZDROJ PLATBY
PSC
C IS L O .P O P IS N E «column»
CISLO_ORIENTACN! Z D R O J.P L A T B Y JO
POCET.DS ZDROJ_PLATBY_NAZEV
POCET_WOfi
POCET.TEL
POCET.EMAIL
ZRUŠENY
k o n takt. emajl
KONTAKT.TEL
KONTAKT_WOB
KONTAKT_DBOX
JMÉNO
QSLOVENY_SK
PRUMENI
NÁZEV
*PK PARTHE R_SK
PO PLAT NI K_SK
VS.POPLATNIKA
PE R IO D IC lT A _ P L A T B Y
D A TU M .P R IH L A S E N I
ĎATUM_VZNlKU_POPLATNtKA
P O C E T .P R IJ IM A C U
SAZBA
OSLOVÉ NI_DAT UM
O S L O V E N I. Z F U S O B
í. o d h lasen i
ÜUVOO.OHLASEN!
TD.PARTNERQ
Obrázek 6: Požadavky na podobu L2 OLAP z pohledu entity PLATBA
stránka 15/41
dm Předpis ^
V D _PAR TN ER _ PO PLATN ÍK n VDDATUM n
«column» VF_PREDPIS □ «oo lu m n »
10_PAR T NERA "PK DATUM
TYP_PART NERA «oolum n*
POHLAVÍ - OBDOBÍ VYSTAVENI P R V N I_D A T U M _M E S IC E
D AT UM_NAROZ£NI * CAST KA_P RE DPISU P O S LE D N I_D A T U M _M E S IC E
ICO DEN_NAZEV
STÁT SPLATNOST D E N _ N A Z E V _ Z K R A .C E N Y
KRAJ C IS LO _D N E _V _M E S IC I
OKRES C IS L O _ D N E _ V _ T Y D N U
OBEC CtSLO_DNE_V_ROCE
OBEC UIR KOO R P .R R _ M M
CAST_OBCE RRRR_CC
ULICE PPACOVNI_DEN_ZNACKA
ULICE UIR KOD SVATEK_ZNACKA
PSC
CISLO POPISNÉ •P K .
C IS L O _ O R IE N T A C N I > PK_TD_DATUMO
* POC£T_MOB
’ POCET_TEL
' ROCE T_E MAIL
ZRUŠENY
* k o n t a k t _ e m a il
* KONT AKT_TEL
* KONTAKT_MOB
* KONTAKT_DBOX
JMÉNO
OSLOVÉMY_SK
PRUMENI
NÁZEV
"PK PARTN£R_SK VD TYP PŘEDPISU □
POPLATNIK_SK
V S _P O P LA T NIKA
P E R IO D IC IT A _ P L A T B Y «column»
TYP_PREDPISU_tD
D A T U M _P R !H LA S E N I TYP_PREDPISU_NAZEV
DAT UM_VZN!KU_POPLAT NIKA «column»
ZPU SOB_VY ROV N A N IJ D
p o c e t _p r ijim a c u ZPUSOB_VYROVNANI_NAZEV
SAZBA
O S LO V E N I_D A T U M
O SLO VÉNl_2PUSO B
OSVOBOZENI VD_DUV O D V Y STAVEN I
ZPUSOB_ODHLASENI «column »
DUVOD_VY STAVENIJO
OUVOD_OHLASENI DUVOO_VYSTAVENI_NAZEV
•P K ,
PK_TD_PARTNER{)
Obrázek 7: Požadavky na podobu L2 OLAP z pohledu entity PŘEDPIS
stránka 16/41
dm Pocty přijímačů ^
VD_PARTNER_POPLATN«K □
« c o lu m n » VF PŘIJÍMAČ □ V D _ S A Z B A
' ID_PARTNERA
- TY P_PAR T NERA «COlumn»
SAZSAJD
POHLAVÍ SAZBA_NAZEV
DATUM_NAROZENl
ICO □ VD_ZPU SOB_OOH LA SEN 1
STÁT
KRAJ « oo lu m n »
OKRES ZPUSOB_ODHLASENI_ID
OBEC Z P U S O B _ pD H LA S E N I_N A Z E V
OBEC_UIR_KOD
CAST_OBCE VDDUVODOOHLASENl □
ULICE
ULICE_UIR_KOD «colum n*
PSC DUVOD_ODHLASENI_JO
C lS L O _ P O P IS N E D 'J V O D _ Q D H LA S E N !_H A Z E V
CISLO_OR!ENTACNI
* POCET_DS
* POCET_MOB
* POCET_TEL
* POC£T_EMA!L
* ZRUŠENY
* KONT AKT_EMAIL
* KONTAKT_TEL
* KONTAKT_MOB
* KONTAKT_DB OX
JMÉNO
OSLOVÉ NY_SK
PR UMĚNI
NÁZEV
*PK PARTNER_SK
POPLATNIK_SK
V S _ P O P L A T N lK A
PERIODfClTA _P LAT BY
DA TUM _PR IHLASENI
DAT UM _VZNIKU_POPLATNIKA
P O C E T _ P R U IM A C U
SAZBA
OSLO VENI_DATOM
OSLOVENI_ZFUSOB
OSVOBOZENI
ZPUSOB_G OH LASEM!
DUVOD_OHLASENI
«PK»
V ,>-fK_TD_PARTNER()
Obrázek 8: Požadavky na podobu L2 OLAP z pohledu entity PŘIJÍMAČ
stránka 17/41
T7~
VD_DATUM □
VD_PAfiTNER_POPlATHIK O VFUPO M IH KA «oolum n»
*PK DATUM
«oolumn» «o o lu m n »
• ID_PAR TMERA DATUM_VY STAVENI PRVNI_DATUM_MESICE
• TYP_PARTNERA DATUM_SPLAT NOSTI POSLEDNI_DATUM_MESICE
UPOMENUTA_CASTKA DEN_NAZEV
POHLAVÍ U H R A Z E fiA _ C A S T K A DE N_NAZEV_ZKRACENY
DATUM_NARQZ£NI CI SLO_ON E_V_M E SICI
IC O CISLO_DN£_V_TYDNU
STÁT CISLO_DNE_V_ROCE
KRAJ RRRR_MM
OKRES RRRR_CC
OBEC PPACOVN!_DEN_ZNACKA
O B E C _ U IR _ K O C SVATEK_ZNACKA
CAST_OBCE
ULICE «PK,
U LIC E _U IR _K O O K pK_TD_DATUMj)
PSC
C IS L O _ P O P lS N E VO TYP UPOMÍNKY □
C IS LO _O R IE N T ACNI
• POCET_DS «oolumn» VD PR ED PIS
• POCET_MOB T Y P _U P O M !N K Y JD
• POCET^TEL TY P _U P O M IN K Y _N A Z E V «oolumn»
• POCET_EMAlL
- ZRUŠENY * OBDC6l_VYSTAVENt
• KONTAKT_EM AlL
• KONTAKT_TEL * CASTKA_PPE OPISU
• KONTAKT_MOB
’ KONTAKT_DBOX SPLATNOST |
JMÉNO
OSLOVENY_SK
P Ř ÍJ M E N Í
NÁZEV
*PK PARTNER_SK
P O P L A T N IK _ S K
V S_P O P LA T NIKA
PE R IO D IC IT A _ P L A T B Y
DATUM_PRIHLASENI
D A T U M _V Z N IK U _P O P LA T N IK A
POCET_PRIJIMACU
SAZBA
O SLO VENl_DATL'M
O S LO V E N I_Z P U S O B
OSVOBOZENI
ŽPU SO B jO O H LA S E N l
CUVOD_OHLASENI
«PK>
t P K_T D_P AR TNE R0
Obrázek 9: Požadavky na podobu L2 OLAP z pohledu entity UPOMÍNKA
stránka 18/41
dm N evyrovn an é položky / VF_NEVYROVANE POLOŽKY □ VDDATU M
□ VD__PARTNER_POPl_ATNiK «oolum n* «oolum n*
CASTKÁ *PK DATUM
« o o lu m n » NEVYROVNANÁ CASTKA
ID_PARTNERA PR V N I_D A TU M _M ES IC E
P O S L E D N I_D A T U M _M E S lC E
* TYP_PARTNERA DEN_NAZEV
POHLAVÍ DEN_NAZEV_ZKRACENY
DA T UM _NAROZENI C IS LO _ D N E _V _ M E S IC I
ICO CIS LQ_DNE _V _TYDNU
STÁT CISLO_DNE_V_ROCE
KRAJ RRRR_MM
OKRES RRRR_CC
OBEC P R A C O V N I_ D E N _ Z N A C K A
OB EC_U IR_KOD SVATEK_ZNACKA
CAST_OBCE
ULICE «PK x-
ULICE_UIR_KOD f PK_TD_DATUM|)
PSC
C lS L O _P O P IS N £ VDUCET
C tS L O _ O R IE N T A C N I
« oo lu m n »
* POCET_DS UCETJD
* POCET_MOB UCET_NAZEV
* POCET_TEL
* POCET_EMAIL VDPREDPIS
* ZRUŠENY
* KONTAKT_EMAIL «oolum n*
* KONTAKT_T EL OBDCBI_VYSTAVENI
* KONTAKT_MOB CASTKA_PR EDPISU
* KONTAKT_DBCX
' SPLATNOST
JMÉNO
OSLOVÉNY_SK
PŘÍJMENÍ
NÁZEV
”PK PARTNER_SK
P O P L A T N IK _ S K
V S _ P O P L A T N IK A
PERIOD ICITA_PLATBY
D A TU M _P R IH LAS E N l
D A T U M _V Z N IK U _P O P LA T N IK A
P O C E T _ P R IJIM Á Č u
SAZBA
OSLOVENI_DAT UM
CSLOVENI_ZPUSOB
OSVOBOZENI
ZPUSOB_ODHLASENI
DŮVOD OHLÁŠENI
«PK*
► PK_TD_PARTNERQ
Obrázek 10: Požadavky na podobu L2 OLAP z pohledu entity NEVYROVNANÁ POLOŽKA
stránka 19/41
dm Pravni řešeni
VD_PARTN ER_PO P LATNIK n □
« o o lu m n » V F P R A V N IR E SENI □ « oo lu m n »
* ID_PARTNERA ‘ PK DATUM
* TYP_PARTNE RA « o o lu m n »
D A TU M _V ZN IK U P R V N I_D A T U M _M ES IC E
POHLAVÍ DATUM PODANÍ P O S LED N I_D AT U M _M ES IC E
DATUM_NAROZENI DATUM ŽALOBY DEN_NAZEV
ICO DEN_NAZEV_ZKRAC ENY
STÁT - ŘEŠENA CASTKA C IS LO _ D N E _V _ M E S IC I
KRAJ DAT UM _STAVU C IS LO _ D N E _V _ T Y D N U
OKRES CISLO_DNE_V_ROCE
OBEC RRRR_MM
OB EC_UIR_KCD RRRR_CC
CAST_OBCE P R A C O V N I_ D E N _ Z N A C K A
ULICE SVATEK_ZNACKA
ULICE_UIR_KOO
PSC «PK»
CISLO_POPISNE F PK_TD_DATUMO
CISLO_ORlENT ACNI
* POCET_DS VD TYP POOANI □ VD STAV PRAVNI ŘEŠENI
* POCET_MOB
* POCET_TEL «oolum n* «oolum n*
* POCET_EMAIL T Y P _ P O D A N I_ lD S T A V _ P R A V N I_ R E S E N IJD
* ZRUŠENY T Y P _ P O D A N I_ N A Z E V STAV_PRAVNI_RESENI_NAZEV
* KONTAKT_E MAIL
* KONTAKT_TEL
* KONTAKT_MOB
* KONTAKT_DBOX
JMÉNO
OSLOVÉNY_SK
PŘÍJMENÍ
NÁZEV
*PK PARTNER_SK
P O P L A T N IK _ S K
V S _ P O P L A T N IK A
PERIODICITA_P LATB Y
DA TU M _P P .IH L A S E N I
D A TU M _V Z N IK U _P O P LA T N IK A
POCET_PRUIMACU
SAZBA
O S L O V E N l_D A T U M
OSLOVENI_ZPUSOB
OSVOBOZENI
ZPUSC6_ODHLASENJ
. DUVOD_OHLASENI
► PK_TD_PARTNERi)
Obrázek 11: Požadavky na podobu L2 OLAP z pohledu entity PRA VNI ŘEŠENI
3.2.2 POŽADAVKY NA DATOVOU ARCHITEKTURU ŘEŠENÍ A INTEGRACE
V této kapitole jsou popsány požadavky na datovou strukturu, se kterým řešení bude pracovat a požadavky
na způsob datové integrace.
3.2.2.1 Datová architektura
3.2.2.1.1 Datové zdroje
V rámci poptávaného řešení DWH/BI je požadováno připojení dvou datových zdrojů:
• systém PN26
• databáze poplatníků ZIS
3.2.2.1.2 Datová architektura DWH
Datový sklad musí být vnitřně členěn do několika samostatných datových úložišť se specifickým použitím a
vlastnostmi. O přesuny dat mezi těmito úložišti (LO > L1 > L2) je požadováno, aby se staraly ETL/ELT
načítací pumpy.
Stage vrstva (nebo také staging area či vrstva LO) bude relační databáze, ve kterých je udržován obraz
definované množiny dat ze zdrojového systému, která je předmětem načítání do DWH
stránka 20/41
Integrovaná vrstva (nebo také vrstva L1) bude relační databáze, ve které jsou data z různých zdrojů
propojována do společných či vzájemně provázaných datových struktur, čímž je definována tzv. jediná
pravda napříč celou firmou. Tato integrovaná vrstva DWH bude tvořena jednou databází s názvem DWH.
V rámci této databáze musí být definovány dílčí databázová schémata seskupující jednotlivé tabulky do
věcně souvisejících oblastí:
DWH pro tabulky sdílených dimenzí propojující jednotlivé oblasti mezi sebou
TVP pro tabulky z oblasti agenda TV poplatníků
Vrstva datamartů (nebo také vrstva L2, vrstva datových tržišť či reportovací vrstva) bude buďto relační
nebo OLAP databáze či exportní soubory různého formátu (TXT, CSV), jejímž cílem bude efektivní způsob
poskytování dat jednotlivým odběratelům. Motivem vrstvy L2 bude optimalizace doby odezvy při získávání
těchto dat. Dosahuje se toho různými způsoby - pomocí předpočítaných agregovaných hodnot (OLAP
kostky), denormalizací dat (relační datamarty) nebo exportem do souboru vhodného formátu (TXT/CSV
exporty).
Vrstva OLAP datamartů musí zároveň plnit funkci sémantické vrstvy, tj. popisné vrstvy, která bude
srozumitelná jazyku koncových uživatelů.
3.2.2.1.3 Datová architektura reportů SSRS
Je požadováno, aby v okamžiku, kdy uživatel spouští/generuje report SSRS, je proti nadefinovanému
datovému zdroji poslán SQL dotaz zajišťující materializaci datového setu. S daty takového datového setu
pak po dobu práce uživatele s reportem pracuje prezentační vrstva Report Serveru, jak je popsáno dále.
Reporty Reporting Services se musí skládat z několika datových prvků, které mohou být vzájemně
provázaný (datové zdroje, datasety, parametry) hierarchicky pak (datový zdroj > dataset > tabulka, graf,
parameter). Definice reportů se nastavuje v aplikaci SQL Server Data Tools, alternativně v Report Builderu.
Reporty budou deployovány (nasazovány), buď na Report Server, nad kterým je postavena webová
aplikace Report Manager. K ukládání obsahu definic reportů, odběrů reportů (subscriptions), plánování
úloh, apod. tento nástroj bude používat databázi SQL Serveru.
Každý jednotlivý report Reporting Service musí být definován ve vlastním souboru s příponou .rdi, sdílené
datové zdroje pak příponou .rds a sdílené datasety příponou .rsd. Obsah všech těchto souborů bude
definován ve formátu XML.
3.2.3 POŽADAVKY NA PŘÍSTUP UŽIVATELE
Základní požadavky na přístupu uživatelů k Bl resp. datům v DWH
Přístup pro vývoj a testování
o Vývojové nástroje nainstalované na 1 lokální stanici přístupné přes VPN.
o Vývojový tým dodavatele bude mít přístup k serverům řešení prostřednictvím VPN
z vlastních stanic s nainstalovanými vývojovými nástroji,
o Vývojové a testovací prostředí - vývojový tým bude mít lokální admin práva, včetně
sysadmin pro databáze DWH a olap admin pro OLAP instance.
Přístup pro koncového uživatele
o Požaduje se, aby uživatel přistupuval k reportům, dashboardům primárně pomocí
internetového prohlížeče, případně dalšími nástroji kancelářské práce jako například
Microsoft Office. Primárně se počítá s použitím Internet Explorer 10 a Microsoft Office 2010
či novějším. Detailní informace o podporovaných internetových prohlížečích je k dispozici
zde:
http://technet.microsoft.com/en-us/library/cc263526(v=office.15).aspx
o Přístup do OLAP databáze prostřednictvím Analysis Services API
o Z technického a síťového pohledu se přístup uživatele bude lišit podle jeho síťového
umístění:
■ uživatel z vnitřní sítě přistupuje k řešení přímo
■ přístup uživatelů z internetu není plánován.
Požadavek na základní koncept řízení přístupových práv
o Integrace se SSO
stránka 21/41
o Předávání identity uživatele mezi volanými systémy (navázání na Active Directory)
o Role a skupiny v jednotlivých aplikacích (relační DWH, OLAP, Reporty, atp) musí být
navázány na AD skupiny. Správa aplikačních rolí DWH/BI a AD skupin musí být oddělená.
3.2.3.1 Řízení přístupu uživatelů v prostředí DWH/BI
V prostředí DWH/BI je požadováno, aby řízení přístupů bylo na úrovni datové vrstvy, která se bude chovat
persistentně vůči všem nástrojům, které do ní přistupují a dále na úrovni výstupů, které lze uživatelům
zpřístupnit. Na úrovni datové vrstvy bude možné řídit přístup k objektům i jejich obsahu. Na úrovni výstupů
je bude možné standardně řídit přístup k jednotlivým výstupním objektům.
3.2.3.1.1 Řízení přístupu na úrovni relační databáze DWH
Jednotlivé oblasti DWH musí být zařazeny do vlastních schémat. Pokud bude vhodné, aby uživatelé
(power uživatelé, analytici) přistupovali k relačnímu datovému obsahu DWH, pak budou jejich loginy, příp.
Active Directory skupiny (Business role) přiřazeny schématům.
3.2.3.1.2 Řízení přístupu na úrovni sémantické vrstvy DWH
Je požadováno v rámci dodávaného řešeni, aby hlavní část dat DWH (data ZIS a PN26) byla
obsahem OLAP databáze v multidimenzionálním módu. Z tohoto důvodu bude kladen důraz na
detail při popisu řešení v tomto prostředí.
3.2.3.1.3 Řízení obsahu výstupů
Řízení oprávnění v reportech (Reportíng Services)
Jako dodatečný způsob řízení oprávnění nad obsahem reportů musí být možné použít funkce nad datovým
zdrojem, který aplikuje potřebný filtr nad datovým zdrojem reportu.
stránka 22/41
3.3 POŽADAVKY NA TECHNOLOGICKOU ARCHITEKTURU
Základní požadavky na rozvržení serverů jsou patrné z následujícího schématu
SQL Server 2016 SQL Server 2016
Standard E n te rp ris e
4 cores, 128 GB RAM 4 cores, 128 GB RAM
SQL Server 2016
Standard
4 cores, 16 GB RAM
Obrázek 1 2 - Požadavky na rozvržení serverů
DWH DB Server:
Může být virtualizován
SQL Server 2016 SE (Database Engine + SQL Agent pro systémové joby + SS Management
Studio + SQL Server Profiler)
DWH OLAP Server:
Může být virtualizován
SQL Server 2016 EE (Analysis Services v multidimenzionálním módu)
SQL Server 2016 EE (Integration Services)
Report Server:
SQL Server 2016 SE (Reporting Services v standalone módu)
Lokální stanice v doméně
Klientské aplikace s vývojovými nástroji:
stránka 23/41
o SQL Server 2016 Data Tools for Bl
o SQL Server 2016 Management Studio
o SQL Server Profiler
o SQL Server Databaze Tuning Advisor
OS: Windows 7 a vyšší - 64-bit
Diskové pole pro umístění databází:
Počítá se s využitím stávající infrastruktury
4 POŽADAVKY NA REALIZACI A NASTAVENÍ
1 APLIKACE
Je požadováno, aby vzorová implementace aplikací v rámci zprovozněné BI/DWH platformy zahrnovala
následující funkcionalitu.
A) 2 vzorové reporty
V rámci implementace musí být vytvořeny 2 vzorové reporty v SSRS. K těmto reportům budou vytvořeny
nejprve sdílené datové zdroje, které definují připojovací řetězec do různých systémů a databází pod
uživatelským jménem a heslem. Na tyto zdroje se pak budou odkazovat zdroje jednotlivých reportů dle
potřeby.
Ke vzorové implementaci byly vybrány následující reporty:
Počet TV a poplatníků
Pohledávky podle stáří
a. Společné prvky definované u všech reportů
U každého reportu pak budou popsány jednotlivé datasety, které znázorňují jednotlivé dotazy do databází
s jejich parametry, které omezují záznamy v těchto dotazech. Každý parametr, který má nabízet pro filtraci
seznam možných zadávaných hodnot, bude mít definován dataset, který bude načítaný nejlépe z číselníků
zdrojové databáze.
Parametry (filtry)
• Vytvoření parametrů pro filtraci dle dostupných sloupců v hlavním datasetu, které budou použity
v reportu. Může být použita většina sloupců nebo jen vybrané, které se budou filtrovat. Zde bude
definováno, jaké sloupce budou dostupné pro filtraci.
Třídění podle sloupců
• U reportů, kde jsou použity tabulky, bude na vybraných sloupcích nastavena možnost třídění, vždy
v závislosti na datovém typu tohoto sloupce, u textu (A-Z, Z-A), datum (od nejstaršího, od
nejmladšího), a jiné.
Skrývání a zobrazování sloupců
• Bude vytvořen parametr typu combobox, kde budou vypsány jako hodnoty názvy sloupců, které se
mohou skrýt/zobrazit. U každého takového sloupce se pak vytvoří „expression“, kde se upraví
parametr v této „expression“ s názvem tohoto sloupce, aby se daná expression vztahovala jen na
tento sloupec.
b. Reportl - Počet TV a poplatníků
Popis reportu: Počet TV a poplatníků - sestava obsahuje celkové počty poplatníků po měsících a změny
objemů oproti předchozímu období. Objemy jsou rozděleny podle typu poplatníka do těchto skupin:
1. Fyzická osoba
a. SIPO poplatník
b. Přímý poplatník
2. Podnikatelé
stránka 24/41
Dále pak report obsahuje počty sumární údaj TV přijímačů podle typu poplatníka.
Dostupnost: OFFLINE
Implementace:
• Vytvoření vloženého datasetu odkazující se na OLAP schéma
• Objekty
o Vytvoření tabulky se sloupci vrácených z datasetu
• Specifické vlastnosti
• Primární zdroj agregovaných hodnot jsou tabulky:
o PARTNER POPLATNÍK
Sestavy počtů TVP
201705_vzor.xls
c. Report2 - Pohledávky podle stáří
Popis reportu: Sestava zobrazuje pohledávky podle stáří v rozdělení na žalované a nežalované poplatník.
V časovém rozdělení do těchto skupin:
• DO 90 DNŮ PO SPLATNOSTI
• 91 AŽ 180 DNŮ PO SPLATNOSTI
• 181 DNŮ AŽ 1 ROK PO SPLATNOSTI
• 1 AŽ 2 ROKY PO SPLATNOSTI
• 2 AŽ 3 ROKY PO SPLATNOSTI
• NAD 3 ROKY PO SPLATNOSTI
Dostupnost: OFFLINE
Implementace:
• Vytvoření vloženého datasetu odkazující se na OLAP schéma
• Objekty
o Vytvoření tabulky se sloupci vrácených z datasetu
• Specifické vlastnosti
• Primární zdroj agregovaných hodnot jsou tabulky:
o PREDPIS_POPLATNIK
o UPOMÍNKA
o PLATBA
PoplatkyVymahani
2016_vzor.xlsx
B) Tvorba metadat pro naplnění ETL pro loady dat do DWH
Na základě návrhu struktur L0, L1 a L2 vrstvy DWH budou nadefinována metadata pro ETL pro plnění
těchto struktur:
Načítání dat ze zdrojových systémů do tabulek L0 vrstvy.
Transformace dat z L0 tabulek do tabulek L1 vrstvy, včetně definice primárních klíčů a navázání na
odpovídající číselníky.
Transforamce dat z L1 tabulek do relačních datamartů L2 vrstvy
Plnění OLAP kostek z dat L1 tabulek.
Metadata zahrnují také definici návazností zpracování jednotlivých transformací, včetně časování a
paralelizace jejich spouštění.
Tvorba metadat bude předmětem implementační fáze projektu.
stránka 25/41
4.1.1 AUTENTIZACE A AUTORIZACE
Je požadováno, aby přístup uživatele byl definovaný právy pomocí rolí (skupin) z Active Directory.
o OLAP musí definovat omezení na jednotlivé metriky resp. prvky vybraných dimenzí dle rolí
z AD
Pro jednotlivé aplikace/komponenty musí být vydefinované uživatelské role (uživatel, vývojář, admin).
Řešení musí využívat standardní bezpečnostní architekturu systémů Windows Server, Active Directory,
Microsoft SQL Server. Řešení musí mít zejména následující vlastnosti:
• používá principy „least privilege“
• používají se standardní metody autentizace (AD + z vnitřní sítě Kerberos) a autorizace
• důvěryhodnost systému směrem k uživatelům je zaručena použitím důvěryhodných certifikátů
• na síťové úrovni jsou jednotlivé subsystémy řešení umístěny do VLÁN, mezi kterými jsou
otevřeny pouze nezbytné prostupy
• přístup ze serverů do internetu není primárně předpokládán
• řešení je chráněno proti ztrátě dat dvěma způsoby zálohování - na úrovní databázi a na úrovni
aplikační
4.1.1.1 Autorizační koncept
Autentizace uživatelů
Kautentizaci uživatelů se musí používat účty v Active Directory. Autentizace uživatelů z vnitřní sítě musí
probíhat primárně technologií Kerberos, v případě selhání je nutné využít záložní autentizační technologií
NTLM.
Systém oprávnění pro OLAP
Na základě definice musí být vytvořeny role, které budou mít přístup k požadovaným:
Metrikám
Dimenzím
Prvkům dimenzí
Identity
Řešení musí používat identity uživatelů výlučně z produkční AD.
4.1.2 POŽADAVKY NA MIGRACI DAT
Prvotní naplnění DWH
Je požadováno, aby součástí zprovozněného řešení bylo i prvotní naplnění struktur DWH (L1, L2, OLAP)
aktuálními daty pro podporu 2 převedených stávajících reportů. Prvotní naplnění se týká dat detailněji
popsaných v kap. 3.2.1.1.5.
Toto prvotní naplnění musí být realizováno standardními prostředky, tj. s využitím nadefinovaných ETL
transformací spouštěných v rámci ETL nástroje.
4.1.3 POPIS RELEASE APLIKACE
Je požadováno, aby dodavatel řešení psal postup jak aplikace vyvíjené na platformě přenášet z vývoje do
produkce - obecný popis práce, detaily musí být v provozní dokumentaci.
4.2 POŽADAVKY NA INFRASTRUKTURU
4.2.1 TECHNOLOGICKÉ KOMPONENTY
Je požadováno, aby řešení DWH/BI bylo postaveno na technologické platformě Microsoft SQL Server.
stránka 26/41
5 POŽADAVKY NA TESTOVÁNÍ A ŠKOLENÍ
5.1 NÁSTROJ PRO ŘÍZENÍ TESTO VÁ N Í
Pro řízení testů není požadován speciální nástroj. K řízení bude využita sdílená tabulka s rozpisem.
5.2 DEFINICE TESTOVACÍCH SCÉNÁŘŮ
5.2.1 UŽIVATELSKÉ APLIKAČNÍ TESTY
Označení testovacích scénářů bude následující:
TCA-xx-yy-zzz
kde xx je označení oblasti, yy je číslování skupin testů v rámci oblasti a zzz je číslování jednotlivých
testovacích scénářů
Označení Význam
TCA-01-yy-zzz 2 vzorové reporty,
yy = označení reportu,
TCA-05-yy-zzz zzz = číslování jednotlivých test-case pro daný report
ETL
Testy připojení na datové zdroje
Výkonové testy při prvotním loadu
Výkonové testy při inkrementálnín loadu
Test identifikace přírůstků z načítaných zdrojů
5.2.1.1.1 TCA 2 vzorových reportů
Společné testy pro všechny reporty
Je požadováno, aby u všech reportů se testovaly následující vlastnosti vždy stejných reportů oproti sobě
z původního excelu a nových reportů vytvořených v Reporting Services, jestli jsou dané funkcionality, data,
apod. stejné nebo jinak alternativně podobné. Pokud se budou testovat vždy dva reporty z původního
formátu excel a nového Reporting Services, tak se dané reporty otevřou vedle sebe a budou se kontrolovat
následující body, které jsou psány z pohledu Reporting Services.
Číslo testu Oblast testu Kroky testu Očekávané výsledky
TCA-01 -00-001 Testování 1. V SQL Server Data Tools si
datasetů otevřete projekt, kde máte Dotaz vrací minimálně
TCA-01-00-002 vytvořeny reporty a otevřete
Test na stejný poklepáním vybraný report. hlavičky sloupců bez dat
počet řádků na Pak u něj otevřete dataset
s dotazem do databáze v závislosti na zadaných
2. Klikněte na Query Designér
3. Klikněte na vykřičník a ve parametrech, jestli
vyskakovacím okně Query
Parameters zadejte hodnoty hodnoty v parametru
existující parametrů při
dotazování do databáze v databázi existují nebo
1. Zobrazte vybraný report a po
ne
Po zobrazení reportů se
získá stejný počet
stránka 27/41
nefiltrovaných jeho zobrazení neměňte záznamů při stejných
datech žádné filtry, kromě
defaultních hodnot filtrů, podmínkách jako
které mohou být explicitně
nastaveny v původním excel reportu
1. Zobrazte vybraný report a
TCA-01-00-003 Test na stejné neměňte žádné filtry, kromě Po zobrazení jsou vidět
defaultních hodnot filtrů,
hodnoty v které mohou být explicitně stejné hodnoty
nastaveny
záznamech 2. Seřaďte data v reportu ve zobrazených řádků.
vybraných sloupcích stejně
podle řazení v původním Důležité je použít stejné
excel reportu
3. Zkontrolujte hodnoty řazení hodnot ve
vypsaných dat
1, Zobrazte si vybraný report sloupcích
2. Zkontrolujte, jestli se
TCA-01-00-005 Objekty zobrazují v tabulce stejné Rozložení sloupců
reportu typu sloupce a jestli se tyto
tabulka sloupce nacházejí ve v tabulce je stejné a
stejném pořadí. Všechny
sloupce musíte zobrazit, tak zobrazí se stejné sloupce
aby nebyly skryté
TCA-01-00-007 Parametry, 1. Zobrazte si vybraný report Na stránce se zobrazí
2. Zkontrolujte stejný počet stejné parametry se
jejich typ, parametrů a jejich název, ale stejným názvem a jsou
jen ty, které jsou stejného/alternativního
počet a názvy podporovány v Reporting typu
Services. Ty, které nemohly
TCA-01-00-010 Filtrování být alternativně vytvořeny, Vždy se zobrazí stejný
neuvažujte seznam řádků a jejich
objektů v 3. Zkontrolujte, jestli jsou dané hodnoty
parametry
reportu stejného/alternativního typu
prvku jako combobox,
pomocí datetime picker, apod.
1. Zobrazte si vybraný report
2. Postupně filtrujte vybrané
hodnoty v parametrech a
stránka 28/41
Číslo testu Název reportu Oblast testu Kroky testu Očekávané
výsledky
parametrů porovnávejte vrácené
záznamy v objektech reportu
TCA-01-00-011 Sloupce a pří tomto výběru Setříděné záznamy jsou
1. Zobrazte sí vybraný report
jejich třídění 2. Postupně otestujte, že při stejné jak při
kliknutí na hlavičku sloupce
se setřídí stejné záznamy za jednoduchém třídění
sebou
3. Otestujte třídění podle více podle jednoho sloupce,
sloupců najednou, zda
vracejí stejné hodnoty tak podle více sloupců
najednou
5.2.1.1.2 TCAETL
Seznam akceptačních testů pro část řešení na nástroj ETL Framework:
Číslo Oblast testu Kroky testu Očekávané
testu výsledky
TCA- Test správnosti 1. Pro všechny Oracle zdroje zadat do příkazového „OK"
05-01- připojení řádku příkaz TNSPING a název zdroje a dát
01 TNS_NAMES ENTER
Cmd\tnsping
TCA- Test MSSQL 1. Spustit SQL Server 2016 Management Studio Pokud se v okně
05-01- Připojení 2. Vybrat Server type (Database Engine, Analysis Object Explorer
02 Services, Reporting Services, Integration Services ) zvolená databáze
3. Zadat Server name tak je test splněn
TCA- Test SSIS 4. Vybrat správnou autentifikaci (Windows
05-01- Připojení Authentication, SQL Server Authentication) Test connection
03 5. Pro SQL Server Authentication je nutné zadat succeeded
jméno a heslo
6. Zmáčknout tlačítko Connect.
1. Zapnout Visual Studio
2. Kliknout na File Open Project/Solution vybrat
složku s řešením SSIS a v ní kliknout na zvolené
řešení
3. V okně Solution Explorer kliknout na Connection
Manager pravým tlačítkem kliknout na New
Connection Manager
4. Vyberou se zdroje (Microsoft Connector for
Oracle by Attunity, Connection Manager for OLE
DB connections - MSSQL) podle typu zdroje, na
který se má SSIS napojovat, klinout na tlačítko ADD
5. - Microsoft Connector for Oracle zadat TNS
server name shodné s tns_names.ora jméno a
heslo
- Connection Manager for OLE DB connections,
kliknout na tlačítko NEW zvolit Server name,
Autentifikaci, případně databázi, pro SQL Server
Authentication zadat ještě jméno a heslo
6. Zmáčknout tlačítko Test connection
stránka 29/41
Číslo Oblast testu Kroky testu Očekávané
testu výsledky
Test SSAS 1. Zapnout Visual Studio
TCA- Připojení 2. Kliknout na Filé Open Project/Solution vybrat Test connection
05-01- složku s řešením SSAS a v ní kliknout na zvolené succeeded
04 Test SSRS řešení
Připojení Visual 3. V okně Solution Explorer kliknout na Data Test connection
TCA- Studia Sources pravým tlačítkem kliknout na New Data succeeded
05-01- Sources pokud se objeví uvítací okno tak kliknout
05 Test SSRS na Next Zobrazí se
Připojení do 4. Kliknout na New Connection created
TCA- databáze 5. Zvolit Server name, Autentifikaci, případně successfully
05-01- databázi, pro SQL Server Authentication zadat ještě
06 Výkonové testy jméno a heslo
při prvotním 6. Zmáčknout tlačítko Test connection
TCA- loadu
05-01- 1. Zapnout Visual Studio
08 2. Kliknout na Filé Open Project/Solution vybrat
složku s řešením SSRS a v ní kliknout na zvolené
řešení
3. V okně Solution Explorer kliknout na Shared
Data Source pravým tlačítkem, pak kliknout na Add
New Data Source
4. Vyberou se zdroje (Microsoft SQL Server,
Microsoft SQL Server Analysis Services, Oracle)
podle typu zdroje, na který se má SSRS napojovat
5. Zvolit Server name, Autentifikaci, případně
databázi, pro SQL Server Authentication zadat ještě
jméno a heslo
6. Kliknout na tlačítko Edit vybrat jméno serveru
7. - Microsoft SQL Server Analysis Services zadat
Server name
- Microsoft SQL Server zvolit Server name,
Autentifikaci, případně databázi, pro SQL Server
Authentication ještě jméno a heslo
- Oracle zadat Server name shodné s
tns_names.ora jméno a heslo
8. Zmáčknout tlačítko Test connection
1. Jít na sharepoint server a najít si datové zdroje,
které byly deployované pro reporty SSRS a mají
zdroj databáze
2. Kliknout na "tři tečky" vedle datového zdroje a
kliknout na Edit Data Source Definition
3. Kliknout na Test Connection na konci formuláře
Účelem zátěžového testu při prvotním loadu je Hodnoty se
monitoring celého procesu prvotního loadu, jestli se nepohybují na
hodnoty níže popsaných komponent neblíží kritických hodnotách
maximální hodnotám, neboje dokonce nepřetěžují.
- Využití procesoru
- Využití diskového pole
-Velikost paměti
- Propustnost sítě
TCA- To samé jako To samé jako test při prvotním loadu, ale pro Hodnoty se
05-01- test při prvotním inkrementální load z testovacího scénáře nepohybují na
09 loadu, ale pro TCA-05-01-08 kritických hodnotách
inkrementální
load
stránka 30/41
Číslo Oblast testu Kroky testu Očekávané
testu výsledky
TCA- Test identifikace Vrámci Stage vrstvy ověřit load od loadu Hodnoty se shodují
05-01- přírůstků z
10 načítaných
zdrojů
TCA- Test ETL plnění 1. Počty řádků ve zdrojové tabulce Počty se shodují
05-01- vše je v pořádku
13 počty řádků 2. Počty řádků v cílové tabulce
TCA- Test ETL plnění 1. Ověřit, že sloupec zdrojové tabulky, který by měl
05-01- primární klíč být primárním klíčem, se správně plní do cílové
12 tabulky - Vzít záznam zdrojové tabulky a
zkontrolovat ho v cílové tabulce
TCA- Test ETL plnění 1. Ověřit, že se záznamy v zdrojové tabulce shodují vše je v pořádku
05-01- se záznamy v cílové tabulce.
13
TCA- Test SSRS 1. Jít na SharePoint server a najít si datové zdroje, Zobrazí se
05-01- Připojení do které byly deployované pro reporty SSRS a mají Connection created
14 Analysis zdroj Analysis Services successfully
Services 2. Kliknout na "tři tečky" vedle datového zdroje a
kliknout na Edit Data Source Definition
3. Kliknout na Test Connection na konci formuláře
TCA- Test SSRS Nelze přímo otestovat přes datový zdroj, ale je
05-01- Připojení na možné jej otestovat přes dataset viz scénář
15 XML TCA-01 -03-001
5.2.2 TESTY INFRASTRUKTURY
Projekt nepožaduje testy infrastruktury, projektem se nebudou zavádět nové infra technologie.
5.2.3 BEZPEČNOSTNÍ A PENETRAČNÍ TESTY
Penetrační nejsou požadovány.
Bezpečnostní testy sibdue provádět interně IT ČT.
5.3 ŠKOLENÍ
Součástí dodávky je požadováno 2 denní školení super nebo power uživatelů Bl. Cílem je naučit tyto
uživatele přistupovat a pracovat s jednotlivými komponentami DWH/BI. Školení musí být zaměřeno na:
Prezentaci DWH řešení - integrace dat
Přístup a práci s reporty
Přístup a práci s OLAP vrstvou DWH
stránka 31/41
5.4 POŽADAVKY NA DOHLED ŘEŠENI
5.4.1 A PLIK A Č N Í DOHLED
Je požadováno, aby dodávané řešení obsahovalo monitoring a logování veškerých ETL procesů a
transformační skriptů.
K tomuto účelu musí být použít nástroj fungující na bázi metadat, kde je každá informace o probíhajícím
procesu detailně logována.
Každý řádek v cílové tabulce L1 a L2 si s sebou musí nést informaci, při kterém běhu byl vytvořen a kdy byl
naposledy modifikován.
Je požadováno, aby logování se provádělo ve třech úrovních
• Balíček
o Načtené soubory
o Proces
■ Detail procesu
Níže je souhrn funkcí, které musí umět ETL nástroj podporovat.
Balíček
Odpovídá jednomu naplánovanému běhu sady ETL procesů (např. načtení dat ze ZIS).
Ke každému běhu balíčku se ukládá informace o počátečním a koncovém čase a o koncových časech
jednotlivých fází v rámci balíčku (fáze LO, L1 atd.).
Procesy balíčku a zpracované soubory
Každý balíček je monitorován na úrovni jednotlivých ETL procesů.
K jednotlivým procesům se ukládá informace o počtu nových/změněných/smazaných záznamů.
Report obsahuje také seznam nahraných souborů, pokud se jedná o balíček, který načítá data ze
souborového systému.
Detail procesu
Každý proces v rámci balíčku je detailně logován pro snadné ladění a rychlou identifikaci případného
problému.
Monitorování pak probíhá třemi způsoby.
• Zaprvé monitorujeme průběh ETL procesů probíhajících v systému a jejich věcnou správnost.
• Zadruhé monitorujeme logickou (obsahovou) správnost probíhajících ETL procesů, jejich
uspořádání v rámci jednotlivých logických celků včetně jejich návazností.
• Zatřetí monitorujeme výkon jednotlivých ETL procesů a jejich logických celků.
Pro všechny zmíněné úrovně monitorování se bude využívat sady předdefinovaných administrátorských
reportů v SSRS.
5.4.1.1 Monitorování věcné správnosti ETL procesů
Věcnou správností se rozumí správně napsaný nebo vygenerovaný SQL kód neobsahující syntaktickou
chybu popř. samotná existence objektu nebo procedury.
Tento typ chyby musí být v reportu indikován červeným podbarvením a popisem odpovídajícím chybové
hlášce SQL serveru např. „ P r o c e d u ř e e n d e d w i t h e r r o r : 1 0 2 - I n c o r r e c t s y n t a x n e a r
1 I j
''
5.4.1.2 Monitorování obsahové správnosti
Obsahovou správností rozumíme správné datové typy, konzistenci dat a datovou kvalitu.
Z hlediska obsahu musí být monitorovány závažné a méně závažné chyby, např. červeným a oranžovým
podbarvením.:
• červeně jsou označeny závažné chyby v datech, které ukončí daný proces
př.: ve vstupních datech není vyplněn povinný atribut
stránka 32/41
• oranžově označené chyby značí varování a mohou mít za následek nekvalitu výstupních
dat
př.: chybí faktová data za předchozí měsíc => možný problém s extrakty z primárního
systému
5.4.1.3 Monitorování výkonu
Ke každému běhu balíčku se je požadováno, aby se ukládaly informace o počátečním a koncovém čase a
o koncových časech jednotlivých fází v rámci balíčku (fáze LO, L1 atd.).
V implementační fázi musí být naimplementována sada monitorovacích reportů zobrazující průměrné časy
trvání jednotlivých balíčků za zadaný interval a počet jejich spuštění v jednotlivých dnech.
Průměrné časy budou zobrazovány zvlášť za fázi nahrávání dat do relační vrstvy, zvlášť za fázi
procesování OLAP kostky a dohromady za obě fáze.
Obrázek 1 3 - Požadavek na report - Průměrná doba trváníjednoho balíčku za poslední měsíc
Dále musí být k dispozici přehledový report zobrazující celkovou dobu trvání všech balíčků za vybraný
interval a počet jejich spuštění v jednotlivých dnech.
'" ‘»»V*1§£....... ........... _ __ ] ÍV^WFUP»^
Obrázek 14 - Požadavek na report - Celková doba trvání všech balíčků
Oba grafy musí obsahovat lineární trend, ze kterého je na první pohled patrný vývoj průměrné doby trvání
v čase.
Dalším monitorovacím reportem musí být celkový pohled na historii běhu SSIS balíčků s možností filtrování
na konkrétní časový úsek, řazení dle doby spuštění nebo dle názvu SSIS balíčku a s množstvím
dodatečných informací.
• Počet souběžně běžících balíčku v každé minutě z vybraného intervalu
• Doba trvání běhu balíčku
• Indikace překročení průměrné měsíční doby trvání o 50%
• Indikace chyby
• Proklik na detail konkrétního běhu balíčku
stránka 33/41
5.4.2 INFRASTRUKTURNÍ DOHLED
DWH/BI nemá vlastní požadavky na infrastrukturní dohled. Předpokládá se využití již existujících
mechanismů a nástrojů na monitorování CPU, RAM, lOPs, prostupnosti sítě databázových a aplikačních
serverů.
5.5 POŽADOVANÁ SOUČINNOST
1) Součinnost po celou dobu průběhu projektu
Předpokládaná součinnost uvedená v této kapitole je pouze rámcová.
Činnost Zhotovitel Objednatel
• Zabezpečení místnosti se 3 až 6 pracovními místy (dle aktuálních potřeb X
Zhotovitele) v době trvání projektu. X
• Zabezpečení místnosti vybavené patřičnou technikou pro vzdálené X
X
videokonference s pracovníky Objednatele (dle aktuálních potřeb Zhotovitele). X
X
• Naplánování interview. Včasná akceptace či připom ínkování zaslaných zápisů X
X
z realizovaných interview (do 2 pracovních dnů). X
X
• Ve spolupráci s konzultanty Zhotovitele provádět a vyhodnocovat interview X
X
s uživateli a definovat uživatelské požadavky.
X
• Ve spolupráci s konzultanty Zhotovitele provést zhodnocení dostupnosti dat ve
X
zdrojových systémech. X
X
• Včasné připomínkování nebo odsouhlasení mezivýstupů projektu (do 2
X
pracovních dnů). X
• Zajištění průběžných konzultací v případě potřeby
• Další součinnost dohodnutá projektovými managery na projektových schůzkách.
• Zajištění zálohování.
• Instalace a konfigurace veškerých antivirů a ostatních nástrojů nebo aplikací
potřebných pro provoz, které nejsou popsané jako součást řešení.
• Průběžná validace řešení oproti standardům.
• Přístup k testovacím a produkčním serverům souvisejícím s řešením, (k
produkčním serverům pouze ve fázi Realizace a Příprava produktivního prostředí
a to omezený přístup)
• Případná aktualizace (instalace Service packů nebo updatů) na doporučené
verze již provozovaných systémů, které budou souviset s navrženým řešením a
v rámci projektu to bude vyžadováno.
• Zajištění případných úprav na straně souvisejících systémů nebo aplikací (které
budou poskytovat data), pokud tyto nejsou součástí dodávaného řešení.
• Zajištění případných konzultací na straně stávajících Zhotovitelů souvisejících
systémů nebo aplikací (které budou poskytovat data).
• V rámci architektury mohou být vyspecifikovány další požadavky na konfiguraci
resp. úpravu konfigurace technologií na již provozovaných, na kterých bude
řešeni závislé, nebo které budou s řešením souviset. Tyto úpravy budou v
architektuře vyspecifikovány a předpokládáme, že jejich naplnění bude
provedeno v součinnosti s Objednatelem.
• Zálohování DWH/BI řešení a včetně dat
• Objednatel vytváří a udržuje kompletní konzistentní zálohu DWH/BI řešení,
včetně dat za účelem obnovy dat, která může být použita ve spolupráci se
Zhotovitelem ¡ako ¡eden ze způsobů odstranění vady typu A, B nebo C v
stránka 34/41
Činnost Zhotovitel Objednatel
případech, kdy nebude možné vadu jiným způsobem opravit, a to po dobu
projektu a záruční doby
• Součinnost při tvorbě Autorizačního konceptu, Dokumentace skutečného X
provedení, Administrátorská příručka a Uživatelské dokumentace
2) Fáze: Realizace
Cíl: Nastavit, otestovat a předat Objednateli Informační systém tak, aby splňoval všechny podmínky
kladené na jeho funkčnost, definované v dokumentech oboustranně odsouhlasených ve fázi Cílový
koncept.
Činnost Zhotovitel Objednatel
• Vývoj funkcionality Informačního systému. X X
X X
• Příprava testovacích scénářů. X
X X
• Příprava testovacích dat. X X
X
• Včasné a řádné testování dodaných řešení. X X
X
• Instalace a zprovoznění prostředí pro školení uživatelů a administrátorů. X
X
• Poskytnutí create scríptů zdrojových systémů a zajištění součinnosti osob
X
znalých datového modelu zdrojových systémů dle požadavků Zhotovitele X
• Kvalita zdrojových dat X
• Vyjasněná terminologie z důvodu tvorby Datového slovníku X
X
• Ověření kvality výstupů s business uživateli X
X
• Vývoj, testování a dokumentace reportů.
• Vývoj, testování a dokumentace programů pro trvalá rozhraní s jiným i IT systémy
Objednatele na straně Informačního systému.
• Vývoj, testování a dokumentace programů pro trvalá rozhraní s jiným i IT systémy
Objednatele na straně IT systémů Objednatele.
• Zajištění potřebného hardwarového vybavení pro vývojové, testovací a produkční
informační systémy pro užívání počítačového programu dle parametrů (sizingu)
podle podkladů Zhotovitele.
• Příprava HW prostředí a sizingu.
• Instalace SW na HW Objednatele a vytvoření prostředí včetně případného
transportního režimu mezi vývojovým, testovacím a produktivním či dalším
prostředím.
• Podpora při instalaci SW na HW Objednatele a vytvoření prostředí včetně
případného transportního režimu mezi vývojovým, testovacím a produktivním
prostředím.
• Součinnost pracovníků zodpovědných za provoz Informačního systému při
instalaci Informačního systému.
• Nastavení Informačního systému a tvorba dokumentace nastavení.
• Součinnost při nastavení Informačního systému
• Úvodní vytvoření autorizačních profilů (na základě předložené koncepce
oprávnění (autorizační koncept).
• Správa a aktualizace autorizačních profilů.
• Zajištění procesních změn
stránka 35/41
Činnost Zhotovitel Objednatel
• Nastavení nástrojů, aby byly procesy podporované i z pohledu funkcionality X X
X
• Tvorba dokumentace X X
X
• Konzultační podpora při tvorbě dokumentace X
X
• Školení projektového týmu - detailní školení funkčnosti počítačového programu, X X
X X
(včetně nastavování parametrů) v prostorách Objednatele. X X
X
• Návrh nezbytných podmínek v prostředí Objednatele pro provedení ověřovacích X X
X
testů Informačního systému Zhotovitelem. X X
• Schválení a realizace podmínek v prostředí Objednatele pro provedení X
ověřovacích testů Informačního systému Zhotovitelem a poskytnutí veškeré X
X
součinností potřebné pro provedení ověřovacích testů Zhotovitelem X
X
• Příprava a provedení ověřovacích testů Informačního systému (včetně nezbytné
externí a interní integrace Informačního systému) v prostředí Objednatele
• Řešení zjištěných nedostatků ve funkčnosti Informačního systému
• Vypracování Protokolu o provedení ověřovacích testů
• Příprava akceptačních testů Informačního systému Objednatelem:
• definice testů Informačního systému;
• vytvoření testovacích scénářů;
• Příprava akceptačních testů Informačního systému Objednatelem:
• příprava a zavedení testovacích dat
• naplánování akceptačních testů Informačního systému;
• provedení akceptačních testů.
• Příprava akceptačních testů Informačního systému Zhotovitelem:
• součinnost při tvorbě testovacích scénářů;
• součinnost při přípravě a zavedení testovacích dat;
• součinnost při naplánování testů;
• součinnost pří provedení testů.
• Vypracování Protokolu o provedení akceptačních testů.
• Doplnění předloženého Protokolu o provedení akceptačních testů o návrh řešení
zjištěných nedostatků ve funkčnosti počítačového programu.
• Součinnost při tvorbě dokum entace koncového uživatele a školicích materiálů
pro koncové uživatele.
• Vytvoření Dokumentace pro koncové uživatele a školicích materiálů pro koncové
uživatele.
• Příprava správných a úplných dat ve stávajících systémech Objednatele pro
následnou migraci do Informačního systému.
• Administrace Informačního systému.
• Spolupráce při administraci Informačního systému.
• Management změnového řízení projektu.
• Podpora při managementu zm ěnového řízeni.
• Rozhodování v procesu změnového řízení.
• Projektové řízení fáze na straně Objednatele
• Projektové řízení fáze na straně Zhotovitele
• Podpora projektového řízení fáze pro Objednatele
stránka 36/41
Činnost Zhotovitel Objednatel
• Revize úplnosti a kvality fáze Realizace. X X
• Podpora při revizi úplnosti a kvality fáze Realizace. X X
X
• Předložení dokumentů k akceptaci fáze Realizace Řídicímu výboru ke schválení.
Specifikace je nedílnou součástí této Smlouvy.
• Podpora při kompletaci a sběru podkladů pro předložení ŘV k akceptaci fáze
Realizace.
• Vypracování návrhu Předávacího protokolu fáze
3) Fáze: Příprava produktivního provozu
Cíl: Uzavřít všechny přípravné činnosti a připravit tak Informační systém pro zahájení produktivního
provozu.
Činnost Zhotovitel Objednatel
• Školení superuživatelů v rozsahu m aximálně 3 dny pro m aximálně 10 uživatelů. X
• Instalace produktivního prostředí X
X
• Podpora při instalaci produktivního prostředí
X
• Provedení akceptačních testů Informačního systému. X
X
• Příprava prostředí pro školení klíčových uživatelů (zkušební data, atd.).
X
• Naplánování a provedení školení uživatelů (expertní) Informačního systému
X
potřebných pro zahájení produktivního provozu. X
X
• Naplánování a provedení školení provozních pracovníků (administrátorské) pro
X
provozování Informačního systému.
X
• Naplánování a provedení školení koncových uživatelů Informačního systému. X
X
• Instalace pracovních stanic klíčových uživatelů.
X
• Návrh nezbytných podmínek pro provedení akceptačních testů Informačního X
systému Zhotovitelem. X
X
• Schválení a realizace podmínek v prostředí Objednatele pro provedení
X
akceptačních testů Informačního systému Zhotovitelem a poskytnutí veškeré X
X
součinnosti potřebné pro provedení akceptačních testů Zhotovitelem
X
• Provedení akceptačních testů Informačního systému.
stránka 37/41
• Sestavení Protokolu o provedení akceptačních testů.
• Vyladění Informačního systému po akceptačních testech.
• Podpora případného vyladění Informačního systému po akceptačních testech.
• Sestavení kompletní Dokumentace Informačního systému, vývoje a rozhraní
v rozsahu CK. Předání dokumentace Objednateli jako součást schválené a
předávané dokumentace v písemné a elektronické formě.
• Administrace Informačního systému.
• Spolupráce při administraci Informačního systému.
• Příprava na migraci
• Podpora přípravy migrace
• Sestavení plánu přechodu do produktivního provozu (plán migrace dat).
• Podpora při sestavení plánu přechodu do produktivního provozu (plán migrace
Činnost Zhotovitel Objednatel
dat).
• Provedení zkušební migrace dat dle plánu přechodu do produktivního provozu X
X
• Podpora při provedení zkušební migrace dat X
• Ověření správnosti přenesených dat zkušební migrace. X
X
• Provedení ostré migrace dat X
• Podpora pří provedení ostré migrace dat X
• Ověření správnosti přenesených dat ostré migrace. X
• Oprava migrací dat způsobených chybou migračních nástrojů nebo postupů X
dodaných Zhotovitelem na základě této Smlouvy X
X
• Předložení dokumentů k akceptaci fáze Příprava produktivního provozu
X
• Podpora pří kompletací a sběru podkladů pro předložení ŘV k akceptaci fáze X
X
Příprava produktivního provozu
X
• Revize úplnosti a kvality fáze Příprava produktivního provozu X
• Podpora pří revizi úplnosti a kvality fáze Příprava produktivního provozu X
X
• Projektové řízení fáze X
• Projektové řízení fáze na straně Zhotovitele X
• Podpora projektového řízení fáze pro Objednatele.
• Management změnového řízení projektu.
• Podpora při managementu změnového řízení.
• Rozhodování v procesu změnového řízení
• Zajištění procesních změn
• Předání kompletní dokumentace Objednateli jako součást schválené a
předávané dokumentace v písemné a elektronické formě.
• Vypracování návrhu Předávacího protokolu fáze
4) Fáze: Produktivní provoz a podpora
Cíl: Podpora provozu Informačního systému a koncových uživatelů, během prvních kritických dnů a
týdnů produktivního provozu Informačního systému.
Činnost Zhotovitel Objednatel
• Odstraňování vad. X X
X X
• Konzultace adm inistrátorům , super uživatelům platform y Bl, stejně tak í X X
kontinuální podpora provozovatele při řešení troubleshooting nestandardního X
chování, řešení nestandardních odezev apod. v rozsahu 80 hodín/měs.
• Aktualizace kompletní dokumentace nastavení Informačního systému, vývoje a
rozhraní o změny realizované v rámci fáze Produktivní provoz a podpora.
Předání kompletní finální dokumentace Objednateli jako součást schválené a
předávané dokumentace v písemné a elektronické formě.
• Předání zdrojového kódu Informačního systému včetně dokumentace
zdrojového kódu
• Provedení kontroly kvality dodávaného zdrojového kódu Informačního systému
• Administrace Informačního systému.
• Zajištěni procesních změn.
stránka 38/41
Činnost Zhotovitel Objednatel
• Revize úplnosti a kvality fáze Produktivní provoz a podpora. X X
X
• Podpora při revizi úplnosti a kvality fáze Produktivní provoz a podpora. X X
X
• Projektové řízení fáze na straně Objednatele X X
X
• Projektové řízení fáze na straně Zhotovitele
• Podpora projektového řízení fáze pro Objednatele.
• Předložení dokumentů k akceptaci fáze Produktivní provoz a podpora.
• Podpora při kompletaci a sběru podkladů pro předložení ŘV k akceptaci fáze
Produktivní provoz a podpora.
• Vypracování návrhu Předávacího protokolu fáze Produktivní provoz a podpora
5) Fáze: Záruční doba - vyžadovaná součinnost objednatele
Činnost Zhotovitel Objednatel
• Zálohování DWH/BI řešení, včetně dat (Objednatel vytváří a udržuje kompletní X
konzistentní zálohu DWH/BI řešení, včetně dat za účelem obnovy dat, která
může být použita ve spolupráci se Zhotovitelem jako jeden ze způsobů
odstranění vady typu A, B nebo C v případech, kdy nebude možné vadu jiným
způsobem opravit, a to po dobu projektu a záruční doby)
5.6 POŽADAVKY NA AKCEPTAČNÍ KRITÉRIA
ve fázi Realizace
implementace Business Intelligence na základě zadávací dokumentace obsažené ve Smlouvě;
implementace do prostředí testu, ověření funkčnosti aplikace.
dodané dílo odpovídá specifikaci uvedené ve Smlouvě
byly provedeny následující testy
dodavatelské ověřovací (včetně nezbytné interní integrace)
integrační: interní integrace
uživatelské akceptační (UAT) s výsledky uvedenými ve smlouvě
byla dokončena dokumentace
školící dokumentace
dokumentace pro koncové uživatele (Uživatelská dokumentace) a školící materiály
podklady pro sizing
ve fázi Příprava produktivního provozu
Implementace do produkčního prostředí
byly naplněny funkční a nefunkční požadavky dle Smlouvy
byly provedeny všechny výkonové testy bez výskytu vad kategorie A a B a pro všechny kategorie
C, které mohou být maximálně 2 na jeden modul a maximálně 6 celkem, byl stanoven a
odsouhlasen termín jejich odstranění,
byla namigrována data nezbytná pro zahájení produktivního provozu,
byli v odsouhlaseném rozsahu proškoleni všichni super uživatelé systému,
stránka 39/41
byla přiřazena uživatelská oprávnění v rozsahu potřebném pro zahájení produktivního provozu,
byla dokončena dokumentace:
o dokumentace skutečného provedení
o administrátorská příručka
bylo provedeno školení provozních pracovníků pro provozování systému dle specifikace stanovené
v této smlouvě. Potvrzení o provedení tohoto školení je v působnosti vedoucího projektu
Objednatele.
ve fázi Produktivního provozu a podpory:
byly naplněny funkční a nefunkční požadavky dle Smlouvy
k datu ukončení této fáze v systému nejsou po dobu delší než 4 týdny žádné vady kategorie A a B,
v systému jsou maximálně 2 vady kategorie C na 1 modul a maximálně 4 celkem a byl stanoven a
odsouhlasen termín jejich odstranění,
za vady plnění se nepovažuje chyba způsobená kvalitou, chybou, vadou nebo nesprávností
zdrojových dat Objednatele.
byla dokončena kompletní dokumentace změn nastavení systému vyvolaných plněním dle této
smlouvy:
dokumentace skutečného provedení
administrátorská příručka
zdrojový kód informačního systému včetně dokumentace zdrojového kódu
stránka 40/41
6 PŘÍLOHY
stránka 41/41
Příloha č. 2 Smlouvy - Rozpad odhadů pracnosti
P rojekt D W H - T e levizní po platky - Im p lem en tace dle analýzy
P řed p o klá d a n á časová n á ro č n o s t N abízená časo vá do tace
Fáze p ro je k tu Č á st p ro je ktu Počet MDs Počet MDs Z toh o požadovaných pro Počet MDs Počet MDs Z to h o pro sch ů zky s
(člo v ě k o d n ů ) d le fází s c h ů z k y s im p. tý m e m (člo vě ko d n ů ) d le fá zí im p . tý m e m za d a va te le
z a d a va te le M Ds
MDs
M obilizace K ickoff, přístupy, práva, organizace projektu 2 2 2 2 2 2
Instalace D E V prostředí N astavení vývojového prostředí
Instalace kom ponent D W H /B I do vývojového prostředí (součinnost) 3 2
Vývoj K onfigurace kom ponent D W H /B I do vývojového prostředí
Im plem entace přenosu dat do DW H 3 3
D okum entace Im p le m e n ta c e LO, v č e tn ě E T L
P rojektové řízení Im plem entace L 1 , včetně E TL 10 16 5 7 12 5
Instalace PR O D prostředí Im plem entace L2 včetně ETL a OLAP
Nasazení do PROD Im p lem en tace E TL (nastave ní w orkflow ) 8 10
P roduktivní provoz N astavení re portingové kom pone nty
C elkem : Tvorba 2 reportů 5 4
D EV testování
P odpora U A T testů 15 12
D okum entace
P rojektové řízení 10 8
Instalace kom pone nt D W H /B I do produkce (součinnost)
K onfigurace kom ponent D W H /B I do produkce 10 10
N asazení do produkce a ověření funkčnosti
S upport na první 3 m ěsíce produktivního provozu 5 3
P rojektové řízení v rám ci sup portu produktivn ího provozu
10 63 5 8 55 5
15 17
10 25 15 15 32 15
7 7 2 5 5 2
17 17 8 19 19 8
2 2
8 10 3 6 8 3
10 10 5 14 14 5
15 15
3 18 14 3 18 14
168 59 165 59