Textová podoba smlouvy - Hlídač státu.

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

č %ýZ/ďfďďďq

CR - Cssz

Křížová 25, 225 08 Praha 5

Rámcová smlouva

o vývoji a údržbě aplikačního programového vybavení pro pojistné dávky a statistiky - II

(dále jen „Smlouva“ nebo „Rámcová smlouva“)

uzavřená v souladu se zákonem č. 89/2012 Sb.,
občanský zákoník, v platném a účinném znění (dále jen „Občanský zákoník“)
a v souladu 5 § 89 a násl. zákona č. 137/2006 Sb., o veřejných zakázkách, ve znění pozdějších

předpisů (dále jen „ZVZ“)

Smluvní strany:

Česká republika - Česká správa sociálního zabezpečení
Sídlo: Křížová 25, 225 08 Praha 5

Statutární zástupce Objednatele: prof. JUDr. Vilém Kahoun, PhD., ústřední ředitel ČSSZ
Osoba oprávněná jednat jménem Objednatele: Ing. Milan Shrbený, ředitel sekce informačních
a komunikačních technologií
Kontaktní osoba: Ing. Milan Shrbený, ředitel sekce informačních a komunikačních technologií
tel:
e-mail:

IČO: 00006963

(dále jen „Objednatel“)
na straně jedné

KOMIX s.r.o.

Sídlo: Holubova 1, 150 00 Praha
Zastoupená/Jednající: Ing. Tomáš Rutrle, jednatel společnosti
Zápis v OR: v obchodním rejstříku u Městského soudu v Praze, oddíl C, vložka 12440
Kontaktní osoba:

Bankovní spojení: UniCredit Bank Czech Republic, a.s., č.ú.:—

IČO: 47117087

DIČ: CZ4711708

(dále jen „Zhotovitel“)
na straně druhé

(Objednatel a Zhotovitel budou v této Smlouvě označováni jednotlivě jako „Strana/Smluvní strana“
a společně jako „Strany/Smluvní strany“)

Strana 1 (celkem 16)
F...-lii- Preambule

Objednatel je organizační složkou státu a správním orgánem, který zabezpečuje výběr
pojistného na sociální zabezpečení a příspěvku na státní politiku zaměstnanosti, dále provádí
zejména důchodové pojištění a zajišťuje agendu nemocenského pojištění. Aplikační
programové vybavem’ pro nemocenské pojištění (dále jen „NEM“) slouží k evidenci nemocí a
výplatě dávek nemocenského pojištění (nemocenské, peněžitá pomoc v mateřství, ošetřovně a
vyrovnávací příspěvek v těhotenství a mateřství). Aplikační programové vybavení pro

důchodové statistiky (dále jen „D_STAT“) slouží jako statistická databáze pro vytváření

přehledů o přiznaných, zaniklých a vyplácených důchodech.

Objednatel k výše uvedeným účelům v oblasti pojistných dávek a statistik užívá aplikační

programové vybavení NEM, D_STAT (dále jen „APV“). Uvedené APV se skládá z modulů

speciňkovaných v Příloze č. 1 smlouvy.

Objednatel má v úmyslu dále vyvíjet, rozšiřovat, upravovat a zajistit údržbu a podporu
provozu uvedeného APV. Objednatel má zájem zejména o rozvoj, podporu, údržbu a úpravy

APV v návaznosti na legislativní změny, metodické postupy a změny v organizaci práce při

zpracování výše uvedených agend. Cílem výše uvedených úprav a rozvoje APV je urychlení
výplaty dávek nemocenského pojištění a zkvalitnění provozu aplikace, přehledy výplat
důchodových dávek, a evidence insolvenčních řízení.

Tato Smlouva je uzavírána na základě výsledků užšího zadávacího řízení na uzavření Rámcové

smlouvy v režimu nadlimitní veřejné zakázky s názvem „Rámcová smlouva o vývoji a údržbě

aplikačního programového vybavení pro pojistné dávky a statistiky — II“. Veškeré případné
úpravy této Smlouvy budou uskutečněny v souladu s příslušnými právními předpisy, mj. též se
zákonem č. 137/2006 Sb., o veřejných zakázkách, ve znění pozdějších předpisů.

Jmenované řízení bylo konáno za účelem zajištění rozvoje a aplikační podpory současného

aplikačního vybavení pro oblast pojistných dávek a statistik.

I. Výklad pojmů

1.1 Pro účely této Smlouvy, jednotlivých Dílčích smluv a Dílčích objednávek a pro účely jednání
mezi Stranami, se tímto Strany dohodly na následujícím obsahovém vymezení jednotlivých

pojmů a podmínkách s nimi souvisejících:

1.1.1 „Dílčí smlouvou“ se rozumí písemná smlouva uzavřená mezi Objednatelem
a Zhotovitelem, na jejímž základě jsou realizována Dílčí plnění;

1.1.2 „Dílčí objednávkou“ se rozumí objednávka vystavená Objednatelem a doručená

Zhotoviteli, která obsahuje podrobný požadavek na realizaci konkrétního Dílčího plnění včetně
podrobného popisu tohoto Dílčího plnění;

1.1.3 „Dílčím plněním“ se rozumí realizace části plnění dle této Smlouvy na základě Dílčí
smlouvy nebo Dílčí objednávky;

1.1.4 „Dílem“ se rozumí Dílo ve smyslu § 2586 a nésl. Občanského zákoníku vzniklé nebo
prováděné na základě Dílčích smluv nebo Dílčích objednávek, nestanoví-Ii Dílčí smlouva jinak;

1.1.5 „Člověkodnem“ se rozumí objem práce, vykonané jedním specialistou Zhotovitele za
dobu jednoho pracovního dne, tj. za 8 pracovních hodin;

Strana 2 (celkem 16)
1.1.6 „Pracovištěm“ se rozumí jednotlivá Pracoviště České správy sociálního zabezpečení a
Okresní správy sociálního zabezpečení;

1.1.7. „Zadávacím řízením“ se rozumí řízení uvedené v Preambuli této Smlouvy, na základě
kterého byla uzavřena tato Smlouva mezi Objednatelem jako zadavatelem veřejné zakázky
a Zhotovitelem jako vybraným uchazečem v rámci předmětného řízení.

11. Účel a předmět Smlouvy

Účelem této smlouvy je sjednání vzájemných práv a povinností Objednatele a Zhotovitele při
dalším vývoji, rozšiřování, úpravách, údržbě a podpoře provozu APV podle potřeb a na základě
požadavků ze strany Objednatele, jak je uvedeno dále.

Předmětem této Smlouvy je závazek Zhotovitele pro Objednatele provést a zajišťovat
následující plnění:

2.2.1 analytickou činnost a návrhy řešení jednotlivých úprav APV;
2.2.2 vývojové a konzultační práce;
2.2.3 úpravu modulů uvedených v příloze č. 1 této Smlouvy;
2.2.4 vytváření nových verzí APV, upgrade APV a update APV;
2.2.5 údržbu a podporu provozu APV;
2.2.6 zpracování uživatelské, vývojové či jiné technické dokumentace;
2.2.7 školení uživatelů APV;
2.2.8 podporu testování, podporu nasazení do produkčního prostředí, záruční uživatelskou
podporu zahrnující zejména odstranění programových chyb APV a expertní podporu.

to vše na základě jednotlivých Dílčích smluv a v rozsahu a za podmínek sjednaných v této
Smlouvě a závazek Objednatele každé jednotlivé Dílčí plnění převzít a zaplatit za něj
Zhotoviteli cenu dle této Smlouvy.

Podrobný popis předmětu plnění je uveden v Příloze č. 1 této Smlouvy.

Objednatel se za poskytnutá plnění zavazuje zaplatit Zhotoviteli cenu konkrétního plnění na
základě a v souladu s podmínkami, uvedenými v Příloze č. 2 této Smlouvy.

Oprávnění k výkonu práva Objednatele užít počítačové programy a díla vytvořená na základě
Dílčích smluv jsou upravena v čl. X. Smlouvy. Bude-Ii Dílo, které bude vytvořeno na základě
Dílčích smluv, splňovat znaky autorského díla ve smyslu 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), ve znění pozdějších předpisů (dále jen „autorský zákon“), pak podléhá
ochraně dle tohoto zákona.
Tato Smlouva představuje závaznou úpravu práv a povinností Stran při uzavírání Dílčích
smluv/Dílčích objednávek na poskytování Dílčích plnění, není-li vtěchto Dílčích
smlouvách/Dílčích objednávkách stanoveno jinak. Právní vztahy vzniklé na základě Dílčí
smlouvy/Dílčí objednávky se řídí touto Rámcovou smlouvou a Dílčí smlouvou/Dílčí
objednávkou, v otázkách neupravených ani touto ani Dílčí smlouvou/Dílčí objednávkou pak
příslušnými právními předpisy
Dílčí smlouvy, resp. Dílčí objednávky, musejí být uzavírány v souladu s principy a podmínkami
plnění, ke kterým se Zhotovitel zavázal v rémci předmětného zadávacího řízení, a které jsou
obsaženy vPříloze č. 1 této Smlouvy. Dílčí smlouvy, resp. Dílčí objednávky, nesmějí být
uzavírány v rozporu se skutečnostmi, které měly vliv na výsledek zadávacího řízení nebo které
by znamenaly takovou úpravu podmínek plnění, která by byla v rozporu se ZVZ.

Strana 3 (celkem 16)
2.8 Strany se zavazují, že se smluvní podmínky sjednané v Dílčí smlouvě neodchýlí od smluvních
podmínek sjednaných touto Smlouvou.

III. Realizace Díla

3.1 Zhotovitel se zavazuje poskytovat Objednateli služby uvedené v čl. II. odst. 2.2 Smlouvy na
základě věcných a časových potřeb Objednatele a dle jednotlivých požadavků Objednatele,a
to vždy na základě řádně uzavřených Dílčích smluv, resp. Dílčích objednávek. Strany se
zavazují realizovat veškerá Dílčí plnění výhradně na základě výše uvedených způsobů zadání.

3.2 Podrobný popis způsobu uzavírání jednotlivých Dílčích smluv a Dílčích objednávek je uveden
v Přílozec. 3 této Smlouvy.

3.3 Zhotovitel je povinen poskytovat předmětná plnění v rozsahu prací jednotlivých členů jeho
realizačního týmu, a to v přepočtu na Člověkodny. Maximální počet Člověkodnů ve vztahu
k jednotlivým pozicím členů týmu po celou dobu plnění dle této Smlouvy je uveden v Příloze č.
2 této Smlouvy. Akceptací Dílčí objednávky nebo uzavřením Dílčí smlouvy se Zhotovitel
zavazuje dodržet stanovený maximální počet Člověkodnů ve vztahu ke konkrétnímu plnění
a konkrétní pozici člena týmu a je povinen plnění v těchto limitech poskytnout.

3.4 Uvedené počty Člověkodnů jednotlivých specialistů Zhotovitele ve vztahu kjednotlivým
plněním jsou uvedeny jako počty maximální a nepřekročitelné. Zhotovitel tímto bere na
vědomí,ze Objednatel není povinen tyto Člověkodny v uvedeném rozsahu vyčerpat, Zhotovitel
je však povinen tyto kapacity Objednateli poskytnout, resp. jejich poskytnutí garantovat.

IV. Místo plnění a způsob předání plnění

4.1 Místem plnění je sídlo ústředí Objednatele na adrese Křížová 1292/25, 225 08 Praha 5, není--li
Dílčí smlouvou/Dílčí objednávkou stanoveno jinak, vždy však v rámci České republiky a
jednotlivých Pracovišť Objednatele.

4.2 Předání plnění ad hoc vytvořeného v souladu stouto Smlouvou a na základě Dílčí smlouvy
nebo Dílčí objednávky Objednateli bude provedeno v souladu s konkrétními způsoby akceptací
dle jednotlivých plnění, uvedených v Přílohách této Smlouvy.

4.3 Pokud není stanoveno jinak, Zhotovitel předává plnění Objednateli k akceptaci prostřednictvím
předávacího protokolu. Předávací protokol musí být podepsán odpovědnými osobami ve
smyslu Smlouvy.

4.4 Při akceptaci jakéhokoliv Díla nebo části plnění bude sepsán akceptační protokol, který bude

obsahovat zejména popis splnění Stranami v Dílčí smlouvě nebo Dílčí objednávce dohodnutých
akceptačních kritérií.

4.5 Objednatel se zavazuje do 15 (patnácti) pracovních dnů ode dne předání plnění toto plnění
akceptovat či neakceptovat. V případě, že Objednatel neakceptuje plnění (Dílo) předané mu
Zhotovitelem, je Objednatel povinen uvést výčet všech vad a nedostatků, které brání řádnému
užívání plnění (Díla) vrutinním provozu, spolu se závazným termínem jejich odstranění.
Objednatel obecně není povinen akceptovat ani převzít Dílo, plnění nebo jejich část, které
nebudou splňovat podmínky stanovené touto Smlouvou, Dílčí smlouvou, Dílčí objednávkou,
jejich přílohami nebo závaznými pokyny Objednatele.

. Strana 4 (celkem 16)
Akceptací vyjadřuje Objednatel svůj souhlas s kvalitou a obsahem Dílčího plnění. Plnění je
považováno za akceptované a řádně splněné dnem, kdy je odpovědnými osobami dle této
Smlouvy podepsán akceptační protokol, ve kterém je výslovně uvedeno „Akceptováno“.

V případě poskytování pravidelného Dílčího plnění se Zhotovitel zavazuje předat Objednateli ke
schválení protokol o rozsahu služeb poskytnutých na základě a v souladu s řádně uzavřenou
Dílčí smlouvou, a to vždy nejpozději kpátému dni kalendářního měsíce zpětně, za
předcházející kalendářní měsíc poskytování služeb. Vtgmto protokolu uvede rozsah
poskytnutých služeb dle jednotlivých specialistů a počet Clověkodnů poskytnutých služeb
vztahujících se k danému specialistovi.

V případě, že protokol o rozsahu poskytnutých služeb dle čl. IV. odst. 4.7 této Smlouvy bude
v rozporu s rozsahem skutečně poskytnutých služeb, v rozporu se Smlouvou nebo Dílčí
smlouvou, případně pokud bude vykazovat jiné vady, je Objednatel oprávněn tento protokol
neakceptovat a vrátit jej s uvedením výčtu vad Zhotoviteli. Zhotovitel je povinen předložit
opravený protokol nejpozději do 2 (dvou) pracovních dní Objednateli. V ostatních případech je
Objednatel povinen akceptovat tento protokol, a to do 15 (patnácti) pracovních dní ode dne
doručení tohoto protokolu Objednateli Zhotovitelem, a to podpisem odpovědné osoby.

V. Cena a platební podmínky

Objednatel je povinen za řádné poskytnutí jednotlivých Dílčích plnění dle této Smlouvy, Dílčích
objednávek a Dílčích smluv uhradit Zhotoviteli odměnu ve výši a za podmínek stanovených
v Příloze č. 2 této Smlouvy.

Ceny za jednotlivá Dílčí plnění jsou konečné, úplné, závazné a nejvýše přípustné. Jestliže v
této Smlouvě nebo jejích součástech není stanoveno jinak, platí, že ceny již v sobě obsahují
veškeré související náklady, jsou v nich zohlednéna rizika, bonusy, slevy a další vlivy ve vztahu
k celkové době plnění dle této Smlouvy.

Cenu plnění je možno navýšit pouze na základě a ve výši změny sazeb DPH dle platných a
účinných právních předpisů Ceské republiky.

DPH bude vypočteno dle příslušných platných právních předpisů České republiky.

Není-li Zhotovitel registrovaným plátcem DPH při podpisu této Smlouvy, potom tuto daň
nevyčíslí. Skutečnost, že není plátcem DPH, bude uvedena v hlavičce této Smlouvy. Smluvní
strany berou na vědomí, že pokud se Zhotovitel stane plátcem DPH až po uzavření této
Smlouvy, platí, že ceny uvedené v Příloze č. 2 této Smlouvy v sobě již DPH zahrnovaly.
Zhotovitel, který v Zadávacím řízení vystupoval jako uchazeč, je tedy povinen příslušnou část
nabídkové ceny odvést jako DPH a nemá vůči Objednateli, který v Zadávacím řízení
vystupoval jako zadavatel, z titulu DPH nárok na další plnění nad rámec nabídkové ceny.

Celkové ceny jednotlivých druhů plnění za celou dobu trvání této Smlouvy nesmí přesáhnout
částky příslušných plnění, uvedené v Příloze č. 2 této Smlouvy, a to ani jejich jednotkovou ani
celkovou výši, kterými je Zhotovitel vázán.

Ceny za jednotlivá Dílčí plnění dle čl. 3 a 4 Přílohy č. 1 Smlouvy jsou stanoveny jako násobky
množství řádně poskytnutého skutečného plnění jednotlivých specialistů Zhotovitele a
jednotkových cen za práci jednotlivých specialistů dle sazeb tam uvedených.

Celková cena plnění Poskytovatele dle této Smlouvy nepřesáhne:

Strana 5 (celkem 16)
rrrrrrrrrm-t- částku 17 545 500,- Kč (slovy:sedmnáct miliónů pět set čtyřicet pět tisíc pět set korun
českých) bez DPH, tj. 21 230 055,- Kč (slovy:dvacet jedna miliónů dvě stě třicet tisíc
padesát pět korun českých) vč. DPH za plnění dle čl. 1.3 Přílohy č. 2, a částku 55 564 500,-
Kč (slovy:padesát pět miliónů pět set šedesát čtyři tisíc pět set korun českých) bez DPH, tj.
67 233 045,- Kč (slovy:šedesát sedm miliónů dvě stě třicet tři tisíc čtyřicet pět korun
českých) vč. DPH za plnění dle čl. 1.4 Přílohy č. 2

kdy tyto ceny za jednotlivá Dílčí plnění v Kč bez DPH jsou konečné a nepřekročitelné.

Jestliže není ve vztahu k jednotlivým Dílčím plněním dle této Smlouvy nebo v jejích přílohách
stanoveno jinak, budou ceny za jednotlivá Dílčí plnění Zhotovitelem vyúčtována po dokončení
tohoto Dílčího plnění, jeho převzetí a akceptaci ze strany Objednatele vsouladu stouto
Smlouvou. Dnem zdanitelného plnění je v takovém případě den, kdy bylo předmětné plnění
objednatelem akceptováno.

5.10 V případě opakujících se plnění, konkrétně plnění dle čl. II. odst. 2.2.5. Smlouvy, budou ceny
za jednotlivá Dílčí plnění účtována (fakturována) Zhotovitelem Objednateli vždy zpětně za
uplynulý kalendářní měsíc, vněmž bylo toto Dílčí plnění poskytnuto, a to na základě
odsouhlaseného protokolu o rozsahu služeb dle rozsahu plnění stanovených Smlouvou. Dnem
zdanitelného plnění je vtakovém případě den, kdy bylo předmětné Dílčí plnění Díla
Objednatelem akceptováno.

5.11 Zhotovitel je povinen za každé řádně převzaté a akceptované Dílčí plnění vystavit daňový
doklad (fakturu), který bude vystaven snáležitostmi daňového dokladu dle zákona č.
235/2004 Sb., odani z přidané hodnoty, ve znění pozdějších předpisů. Nedílnou součástí
daňového dokladu (faktury) je vždy příslušný akceptační protokol vyhotovený v souladu s
touto Smlouvou.

5.12 Cena bude splatná bezhotovostním převodem na účet Zhotovitele uvedený v záhlaví této
Smlouvy, a to do 30 (třiceti) dnů ode dne doručení řádně vystaveného daňového dokladu
(faktury) Objednateli. Cena bude považována za uhrazenou dnem odeslání příslušné částky
z účtu Objednatele na účet Zhotovitele.

5.13 Objednatel je oprávněn vrátit Zhotoviteli přede dnem splatnosti příslušný daňový doklad
(fakturu) bez zaplacení, pokud takový daňový doklad (faktura) nemá náležitosti stanovené
zákonem nebo touto Smlouvou, a to suvedením důvodu vrácení. Zhotovitel je povinen
v případě vrácení faktury vyhotovit fakturu novou. Důvodným vrácením faktury přestává běžet
původní lhůta splatnosti. Nová lhůta v původní délce splatnosti běží znovu ode dne doručení
opravené nebo nově vystavené faktury Objednateli.

5.14 Zálohy na cenu jednotlivých plnění nebudou Objednatelem poskytovány.

VI. Záruční doba a odpovědnost za vady

6.1 Není-li stanoveno v jiných částech této Smlouvy nebo vjejích přílohách jinak, Zhotovitel se
zavazuje poskytnout Objednateli na každé Zhotovitelem poskytnuté plnění záruku za jakost,
ato vdélce záruky obvykle poskytované za obdobné plnění, nejméně však vdélce 24
kalendářních měsíců. Záruční doba začíná běžet ode dne akceptace každého jednotlivého
Dílčího plnění dle příslušných ustanovení této Smlouvy.

6.2 Zhotovitel odpovídá za řádné a kvalitní provedení Díla dle jednotlivých Dílčích smluv/Dílčích
objednávek (včetně podrobných detailních zadání k němu) a za funkčnost výsledků jeho plnění
vymezenou v zadání.

Strana 6 (celkem 16)
Zhotovitel se zavazuje zhotovit Dílo s odbornou péčí a předat ho Objednateli ve stavu, kdy
splňuje veškeré požadavky uvedené v zadání a v jednotlivých Dílčích smlouvách/Dílčích
objednávkách a bude plně způsobilé k jeho užívání Objednatelem pro účely uvedené v zadání
a Dílčí smlouvě/Dílčí objednávce a bude bez vad, přičemž Dílo má vady zejména pokud:

6.3.1 nesplňuje požadavky dílčího zadání nebo je jinak vrozporu spožadavky, právy
a povinnostmi vyplývajícími ze Smlouvy, Dílčích smluv nebo Dílčích objednávek;

6.3.2 Zhotovitel při vytváření porušil některou ze svých povinností vyplývající 2 čl. VII. odst.
7.3 Smlouvy;

6.3.3 nedojde k poskytnutí práv k užití Díla nebo jeho části Objednateli v rozsahu uvedeném
v čl. X. Smlouvy;

6.3.4 plnění bude mít jiné vady bránící jeho řádnému užití nebo užití Díla vzniklého na
základě plnění Zhotovitele.

V případě výskytu skrytých vad existujících v dobé akceptace Díla nebo záruční vady na Díle,
je zhotovitel povinen nejpozději do konce pracovního dne následujícího po dni, ve kterém
došlo k vytčení vady nebo vytčení záruční vady, zahájit práce na odstraňování vytčených vad.
Délka této lhůty pro odstranění skrytých a záručních vad bude Objednatelem stanovena
sohledem na konkrétní povahu vyskytnuvších se vad a sohledem na dopady na klienty
Objednatele a legislativním lhůtám finančního a věcného plnění vůči těmto klientům. Záruční
opravy Díla budou prováděny v pracovní dny od 7. 00 hod. do 17:00 hod. V případě
neodstranění vytčené vady Díla Zhotovitelem v Objednateiem stanovené lhůtě, je Objednatel
oprávněn uplatnit sankce v souladu s příslušnými ustanoveními této Smlouvy.

Objednatel je povinen oznámit Zhotoviteli výše uvedenou vadu bez zbytečného odkladu po
zjištění některým z následujících způsobů:

6.5.1 prostřednictvím provozovatele poštovních služeb na adresu sídla Zhotovitele, nebo

6.5.2 e-mailem opatřeným uznávaným elektronickým podpisem na e-mailovou adresu
zodpovědné osoby Zhotovitele dle čl. XI. odst. 11.1.2 Smlouvy, nebo

6.5.3 prostřednictvím modulu pro hlášení chyb (např. Helpdesk), nebo

6.5.4 prostřednictvím datové schránky.

Voznámení vady je Objednatel povinen podrobně popsat vadu Díla a den, kdy byla vada
zjištěna, včetně uvedení jména osoby, která vadu zjistila.

6.6 Objednatel se zavazuje během záruční lhůty dodržovat veškeré pokyny Zhotovitele uvedené
v příslušné projektové a provozní dokumentaci vztahující se k předmětnému plnění, definující
rozsah, použití a základní funkční vlastnosti plnění či Díla na základě plnění vzniklého.

6.7 Zhotovitel neodpovídá za vady způsobené:

6.7.1 nevhodnými pokyny Objednatele při realizaci Dílčího plnění, jestliže Zhotovitel na
6.7.2 nevhodnost pokynů Objednatele předem upozornil;
zásahem do Dílčího plnění ze strany Objednatele bez předchozího písemného souhlasu
Zhotovitele;

6.7.3 neodborným zacházením ze strany Objednatele nebo nedodržením jeho povinností
vyplývajících ze Smlouvy;

. Strana 7 (celkem 16)
6.7.4 poškozením živelními událostmi;

6.7.5 poruchou způsobenou počítačovými viry či jinými vlivy třetích stran;

6.7.6 vadou programového či technického vybavení Objednatele, které nebyly předmětem
Dílčího plnění ze strany Zhotovitele;

6.7.7 nedodržením podmínek pro provoz v provozním prostředí, které jsou specifikovány
v příslušné projektové a provozní dokumentaci k Dílčímu plnění.

VII. Práva a povinnosti stran

í..:- I‘II“ - ‘1‘?" I“‘ Objednatel se, vedle povinností stanovených v jiných článcích této Smlouvy, zavazuje:
7.1.1 k poskytování potřebné součinnosti podle požadavků Zhotovitele;

7.1.2 zajistit potřebné technicko-o-rganizační podmínky a informace nezbytné pro řádnou
a včasnou realizaci Dílčího plnění Zhotovitelem;

7.1.3 předávat veškeré potřebné podklady pro realizaci Díla prosté jakýchkoli právních
a jiných vad;

7.1.4 na žádost Zhotovitele zajistit konzultace k vyjasnění obsahu předmětu Dílčího plnění.

Objednatel má právo přerušit bez sankcí ze strany Zhotovitele realizaci Dílčího plnění po
skončení všech probíhajících prací na daném Dílčím plnění nebo po vzájemné dohodě
a obnovit plnění podle svých potřeb a finančních možností.

Zhotovitel se, vedle povinností stanovených v jiných článcích této Smlouvy zavazuje:

7.3.1 zabezpečit provádění činností z jeho strany v profesionální kvalitě a s odbornou péčí
tak, aby odpovídaly všeobecně uznávanému standardu a ustanovením § 2631 a nás|.
Občanského zákoníku, a aby Dílo realizované na základě Dílčí smlouvy/Dílčí
objednávky bylo splněno v souladu s požadavky Objednatele v této Dílčí smlouvě/Dílčí
objednávce uvedenými;

7.3.2 řádně dokončit a předat Dílo na svůj náklad a nebezpečí a ve sjednané době;

7.3.3 poskytnout další relevantní součinnost za účelem splnění této Smlouvy;

7.3.4 spolupůsobit jako osoba povinná při výkonu finanční kontroly ve smyslu § 2 písm. e)
zákona č. 320/2001 Sb.,o finanční kontrole ve veřejné správě a o změně některých
zákonů (zákon o finanční kontrole), ve znění pozdějších předpisů, a poskytnout
Objednateli i kontrolním orgánům při provádění finanční kontroly nezbytnou
součinnost;

7.3.5 poskytovat Objednateli nebo jím pověřené třetí straně součinnost při prověřování
plnění povinností a závazků vyplývající z této Smlouvy.

VIII. Povinnost mlčenlivosti

8.1 Strany se zavazují, že neposkytnou třetím osobám jakékoliv informaceci skutečnosti finanční,
výrobní, technické, organizační nebo ekonomické povahy (dále jen „důvěrné informace“),

Strana 8 (celkem 16)
W

které v souvislosti stouto Smlouvou či v rámci vzájemných jednání v souvislosti s ni nebo
jednotlivými Dílčími smlouvami/Dílčími objednávkami dozví, ani je samy nepoužijí k jiným, než
touto Smlouvou stanoveným účelům, bez souhlasu druhé Strany. Za důvěrné jsou považovány

vvv

ty informace, které nejsou bezne dostupné z jiných zdrojů.

8.2 Strany souhlasí s tím, aby byla tato Smlouva zveřejněna na profilu zadavatele a na
internetových stránkách Objednatele www.cssz.cz. Souhlas se zveřejněním podle předchozí
věty se nevztahuje na údaje, které jsou obchodním tajemstvím podle Občanského zákoníku,
na údaje, jejichž zveřejnění brání zákon č. 101/2000 Sb., o ochraně osobních údajů a o změně
některých zákonů, ve znění pozdějších předpisů, jakož i na údaje, které jsou chráněny před
zveřejněním podle jiných právních předpisů. Zhotovitel jako uchazeč ve své nabídce uvede,
jaká konkrétní ustanovení smlouvy (včetně příloh) a z jakého právního důvodu není možno
označené ustanovení Smlouvy zveřejnit. Pokud Zhotovitel žádné ustanovení této Smlouvy
postupem podle předchozí věty neoznačí, bude Objednatel jako zadavatel za předpokladu
dodržení obecně závazných předpisů oprávněn zveřejnit Smlouvu jako celek včetně všech
jejích příloh.

8.3 Zhotovitel je oprávněn poskytovat potřebné informace subdodavatelům a je povinen
subdodavatelé zavázat k mlčenlivosti v rozsahu daném tímto článkem.

8.4 Objednatel je povinen k ochraně důvěrných informací zavázat všechny osoby a subjekty, které
mají k plnění přístup nebo kterým poskytl či sdělil důvěrné informace dle ujednání uvedených
dále.

8.5 Strany jsou povinny zachovávat mlčenlivost ohledně všech důvěrných informací souvisejících
s touto Smlouvou či se zájmy druhé Strany. Povinnost mlčenlivosti se nevztahuje na případy,
kdy:

8.5.1 předmětná důvěrná informace je obecně známa a vobecnou známost vešla bez
zavinění příslušné Strany;

8.5.2 existuje zákonná povinnost sdělit příslušnou důvěrnou informaci;

8.5.3 předmětná důvěrná informace je uplatněna vrámci soudního řízení (včetně řízení
o výkon rozhodnutí či řízení 0 nařízení exekuce) mezi Stranami (včetně jejich právních
nástupců), případně mezi Stranou a třetí osobou, jedná-li se o spor vyplývající z této
Smlouvy, Dílčích smluv a v případě dalších vztahů s těmito Smlouvami souvisejícími;

8.5.4 důvěrná informace je sdělována osobě, která je vázána stejnou či přísnější povinností
mlčenlivosti, zejména je-Ii sdělována advokátovi ;

8.5.5 je důvěrná informace nezbytně nutná k užívání plnění pro účely výkonu předmětné

agendy;

8.5.6 je důvěrná informace sdělována subjektu, na nějž přechází zákonné kompetence
Objednatele, v souvislosti s nimiž je plnění užíváno.

8.6 Součástí povinnosti mlčenlivosti je povinnost Stran učinit vše, co je v jejich silách, aby důvěrné
informace nevešly ve známost nepovoleným osobám.

IX. Ochrana osobních údajů

9.1 Zhotovitel se zavazuje, že při veškerých činnostech souvisejících stouto Smlouvou a/nebo
Dílčími smlouvami/Dílčími objednávkami přijme taková opatření, aby nemohlo dojít

Strana 9 (celkem 16)
kneoprévnénému nebo nahodilému přístupu kosobním údajům, kjejich změně, zničení či

ztrátě nebo jejich jinému neoprávněnému zpracování.

9.2 Zhotovitel je povinen informovat Objednatele o přijatých opatřeních kzamezení

neoprávněného nebo nahodilého přístupu k osobním údajům, k jejich změně, zničení čí ztrátě

nebo jejich jinému neoprávněnému zpracování. Zhotovitel je rovněž povinen informovat

Objednatele, pokud kvýše uvedeným skutečnostem dojde, a to bezprostředně po zjištění

takovéto skutečnosti. '

x. Licenční ujednání

10.1 V případě, že při realizaci Dílčích plnění na základě Dílčích smluv nebo Dílčích objednávek
vznikne Dílo nebo jeho část, které má charakter autorského díla, pak jako takové podléhá

režimu autorského zákona. Objednatel se zavazuje užívat předmět autorského díla pouze

v souladu s touto Smlouvou, v rozsahu práv na něj Zhotovitelem převedených.

10.2 K předmětu Smlouvy, který bude mít charakter autorského díla (s výjimkou standardních

softwarových produktů třetích stran) poskytne Zhotovitel Objednateli právo k užívání tohoto

Díla a veškerých jeho součástí (dále jen „licence“), a to na dobu trvání majetkových práv

autora anebo kteréhokoliv ze spoluautorů.

10.3 Licence bude Zhotovitelem udělena z prostorového hlediska minimálně na všechna Pracoviště
Objednatele na území Ceské republiky, a co do množstevního rozsahu bude počet uživatelů

licencí neomezený, nebude-Ii v Dílčí smlouvě/Dílčí objednávce ujednán odlišný rozsah
poskytnutí licence.

10.4 Zhotovitel se zavazuje poskytnout licence bezúplatně.

10.5 Oprávněným užitím autorského díla se zejména rozumí:

10.5.1 instalace, spuštění, testování a běžná práce (provozování v rutinním prostředí) s dílem

jako výsledkem plnění dle této Smlouvy a s jeho výsledky na prostředcích výpočetní

techniky Objednatele;

10.5.2 vytvoření záložních kopií kompletního dila jako výsledku plnění dle této Smlouvy pro
potřeby Objednatele;

10.5.3 kopírování manuálů a další nezbytné uživatelské dokumentace pouze pro potřeby
Objednatele.

10.6 Součástí plnění Zhotovitele dle Dílčích smluv/Dílčích objednávek je předání školící uživatelské,
instalační, administrátorské a vývojové dokumentace (včetně předání zdrojových kódů)
k výsledkům předmětu plnění Objednateli.

10.7 Zhotovitel prohlašuje, že má po dobu trvání majetkových práv autora nebo kteréhokoliv ze

spoluautorů na základě příslušných uzavřených smluv se svými subdodavateli právo užívat

autorské dílo, ke kterému poskytl Objednateli právo k užívání dle ustanovení odst. 10.2 tohoto

článku Smlouvy, v plném rozsahu za účelem poskytování Dílčího plnění Objednateli na základě
této Smlouvy a jednotlivých Dílčích smluv včetně Dílčích objednávek.

10.8 Zhotovitel se zavazuje poskytnout Objednateli možnost zcela nebo zčásti poskytnout
oprávnění tvořící součást licence třetí osobě, vždy však pouze pro potřeby související s činností
Objednatele.

. Strana 10 (celkem 16)
10.9 Zhotovitel tímto bezplatně uděluje Objednateli písemný souhlas s užitím autorského díla nad
rozsah oprávnění uvedený v čl. 10.5. tohoto článku Smlouvy. Užitím nad rozsah oprávnění se
rozumí zejména právo Objednatele vzniklé autorské dílo (resp. jeho zdrojový a/nebo strojový
kód, který je Zhotovitel povinen Objednateli poskytnout) zcela nebo zčásti měnit či upravovat,
a to i prostřednictvím třetích osob, využívat vzniklé autorské dílo zcela nebo zčásti k vytváření
samostatných funkčních aplikací či funkčních celků a užívat technickou a uživatelskou
dokumentaci vztahující se k vzniklému autorskému dílu nad rámec oprávnění uvedený v odst.
10.5 tohoto článku Smlouvy. Současně stakto poskytnutým souhlasem Zhotovitele získává
Objednatel právo poskytnout právo k modifikaci a úpravě vzniklého autorského díla nebo jeho
části třetí osobě za účelem odstranění konkrétních vad nebo jeho rozvoje.

10.10 Budou-li součástí poskytovaných služeb ve smyslu Smlouvy či případně vytvořeného Díla jiná
Díla nebo jiné předměty ochrany práv duševního vlastnictví vytvořená třetími osobami,
zavazuje se Zhotovitel udělit Objednateli právo užívat (nebo zajistit udělení takového práva
Objednateli) takové Dílo nebo jiný předmět ochrany práv duševního vlastnictví v rozsahu
nezbytném pro řádné užívání Díla vytvořeného dle této Smlouvy, Dílčí smlouvy nebo Dílčí
objednávky a pro splnění účelu této Smlouvy, Dílčí smlouvy nebo Dílčí objednávky. Práva
užívat Díla či předměty ochrany dle předchozí věty tohoto odstavce jsou Zhotovitelem
poskytnuta bezúplatně.

XI. Odpovědné osoby
Pro účely jednání ve věcech souvisejících s touto Smlouvou jsou odpovědnými osobami:
11.1.1 na straně Objednatele:

ředitel odboru implementace aplikačního programového vybavení

11.1.2 na straně Zhotovitele:

11.2 Strany se zavazují jednostranně určit v Dílčí smlouvě a Dílčí objednávce odpovědné osoby
oprávněné jednat za Strany a rozsah jejich oprávnění jednat za tu kterou Stranu ve věcech
Dílčích smluv a Dílčích objednávek. Tyto osoby jsou oprávněny zejména k podpisu předávacích
a akceptačních protokolů ve smyslu této Smlouvy.

11.3 Bude-li v konkrétní věci oprávněno jednat více odpovědných osob, je každá oprávněna jednat
za danou Stranu samostatně.

11.4 Objednavatel a Zhotovitel jsou oprávněni jednostranně měnit odpovědné osoby a rozsah jejich
oprávnění jednat za Strany. O změně jsou povinni vždy písemně informovat druhou Stranu.
Změna je vůči druhé Straně účinná od okamžiku doručení písemného oznámení o změně
odpovědné osoby. Objednatel je oprávněn písemně požádat Zhotovitele o změnu odpovědné
osoby, a to s odůvodněním této žádosti. Zhotovitel se zavazuje navrženou změnu odpovědné
osoby projednat s Objednatelem a dle možností při realizaci Díla přijmout potřebná opatření,
včetně případné změny odpovědné osoby, tak, aby nedošlo ke snížení kvality realizací Díla.

Strana 11 (celkem 16)
11.5 Shora uvedeným vymezením odpovědných osob není dotčeno oprávnění statutárních orgánů
jednat za Objednatele a Zhotovitele.

XII. Sankční ujednání a náhrada škody

12.1 V případě, že se Zhotovitel dostane do prodlení s plněním (a to i Dílčím plněním), resp.
předáním Díla vterrnínu určeném v Dílčí smlouvě/Dílčí objednávce, je Objednatel oprávněn
požadovat na Zhotoviteli zaplacení smluvní pokuty ve výši 400.000,- Kč (slovy: čtyři sta tisíc
korun českých) za každý i započatý den prodlení s předáním Díla. Uplatněním smluvní pokuty
nezaniká právo Objednatele na náhradu škody.

12.2 V případě, že se Zhotovitel dostane do prodlení s odstraněním řádně vytčené skryté vady Díla
nebo záruční vady oproti termínu stanovenému dle čl. VI. odst. 6.4 Smlouvy, je Objednatel
oprávněn požadovat na Zhotoviteli zaplacení smluvní pokuty ve výši 400.000; Kč (slovy: čtyři
sta tisíc korun českých) za každý i započatý den prodlení s odstraněním reklamované vady.
Uplatněním smluvní pokuty nezaniká právo Objednatele na náhradu škody.

12.3 V případě, že se Zhotovitel dostane do prodlení s odstraněním kteréhokoli incidentu ve smyslu
Přílohy č. 1 Smlouvy, je Objednatel oprávněn požadovat na Zhotoviteli zaplacení smluvní
pokuty ve výši 50.000,- Kč (slovy: padesát tisíc korun českých) za každou i započatou hodinu
prodlení s odstraněním incidentu. Uplatněním smluvní pokuty nezaniká právo Objednatele na
náhradu škody.

12.4 V případě, že Zhotovitel neposkytne řádnou součinnost ve smyslu svých povinností dle čl. VII.
odst. 7.3 této Smlouvy, je Objednatel oprávněn požadovat na Zhotoviteli zaplacení smluvní
pokuty ve výši 500.000,- Kč (slovy: pět set tisíc korun českých) za každý jednotlivý případ.
Uplatněním smluvní pokuty nezaniká právo Objednatele na náhradu škody.

12.5 Poruší-li Zhotovitel svůj závazek přijmout taková opatření, aby nemohlo dojít
k neoprávněnému nebo nahodilému přístupu kosobním údajům, kjejich změně, zničení či
ztrátě, anebo dojde-li k neoprávněným přenosům citlivých dat a/nebo osobních údajů nebo
k jejich jinému neoprávněnému zpracování ve smyslu této Smlouvy, jakož i k jinému zneužití
osobních údajů, nebo poruší-Ii Zhotovitel své závazky podle čl. VIII. Smlouvy, je Objednatel
oprávněn požadovat zaplacení smluvní pokuty ve výši 500.000,- Kč (slovy: pět set tisíc korun
českých) za každé jednotlivé porušení daného závazku. Uplatněním smluvní pokuty nezaniká
právo Objednatele na náhradu škody.

12.6 Zhotovitel se zavazuje nahradit veškerou škodu způsobenou Objednateli při jakémkoli plnění
na základě této Smlouvy a/nebo jakékoliv Dílčí smlouvy a/nebo jakékoliv Dílčí objednávky,
která byla způsobena porušením povinností Zhotovitele vyplývajících z této Smlouvy a/nebo
Dílčí smlouvy a/nebo Dílčí objednávky nebo z právních předpisů, ledaže prokáže, že škoda byla
způsobena okolnostmi vylučujícími protiprávnost.

12.7 Škodou se rozumí skutečná škoda, ušlý ziskva náklady, které Objednatel musel vynaložit
v důsledku porušení povinnosti Zhotovitelem. Skoda se hradí v penězích nebo, je-li to možné
a obvyklé, uvedením v předešlý stav podle volby Objednatele v konkrétním případě.

12.8 Zhotovitel se zavazuje, že bude mít po celou dobu trvání smluvního vztahu sjednáno pojištění
odpovědnosti za škodu způsobenou Objednateli nebo třetí osobě při výkonu podnikatelské
činnosti na základě této Smlouvy a/nebo jakékoliv Dílčí smlouvy a/nebo jakékoliv Dílčí
objednávky s limitem pojistného plnění ve výši nejméně 50.000.000,- Kč (slovy: padesát
milionů korun českých), přičemž spoluúčast Zhotovitele nebude vyšší než 5 (pět) % z limitu

I Strana 12 (celkem 16)
pojistného plnění. Tuto skutečnost je Zhotovitel povinen prokázat kdykoliv po dobu trvání této
Smlouvy k výzvě Objednatele tím, že doručí a předá Objednateli pojistnou smlouvu (originál či
úředně ověřenou kopii) či podobný doklad o trvání pojištění do 7 (sedmi) kalendářních dnů od
doručení této výzvy. Porušení této povinnosti bude považováno za podstatné porušení
Smlouvy.

XIII. Doba trvání Smlouvy a jednotlivých Dílčích smluv

13.1 Rámcová smlouva bude uzavřena na dobu určitou, a to do doby vyčerpání maximálních limitů
pro čerpání služeb dle čl. 1.3 a 1.4 Přílohy č. 2 k Rámcové smlouvě, nejdéle však na dobu 48
měsíců od podpisu Rámcové smlouvy.

13.2 Strany se dohodly, že před okamžikem zániku této Smlouvy uplynutím doby dle odst. 13.1.
tohoto článku Smlouvy lze Smlouvu ukončit výhradně:

13.2.1 na základě písemné dohody Stran;

13.2.2 na základě písemné výpovědi podané Objednatelem i bez udání důvodů, a to
s výpovědní lhůtou v délce 1 (jednoho) měsíce, která začíná běžet od prvního dne
kalendářního měsíce následujícího po měsíci, ve kterém byla písemná výpověď
doručena Zhotoviteli;

13.2.3 na základě odstoupení Objednatele od Smlouvy zdůvodu podstatného porušení
smluvních povinností Zhotovitele, na které byl písemně upozorněn Objednatelem,
přičemž ve lhůtě do 30 (třiceti) dnů po obdržení písemného upozornění k nápravě
nedošlo. Písemné upozornění je Zhotovitel povinen si převzít osobně po telefonické
výzvě, a to do 24 (čtyřiadvaceti)hodin od doby, kdy mu tato skutečnost byla
oznámena. Pokud si Zhotovitel písemné upozornění nevyzvedne podle předchozí věty,
bude mu zasláno prostřednictvím elektronické pošty (e-mail) nebo datové schránky v
souladu s čl. XIV této Smlouvy. Důvodem k výše uvedenému odstoupení od Smlouvy
bude zejména nesplnění předání jakéhokoliv Dílčího plnění dle čl. II. odst. 2.2. této
Smlouvy.

13.3 Ukončením této Smlouvy nejsou dotčena práva a povinnosti Stran vzniklé na základě Dílčích
smluv/Dílčích objednávek, nebude-li mezi Stranami písemně v Dílčích smlouvách/Dílčích
objednávkách dohodnuto jinak.

13.4 Dílčí smlouvy/Dílčí objednávky jsou sjednány na dobu určitou, a to na dobu realizace Dílčího
plnění, s výjimkou Dílčích smluv/Dílčích objednávek, jejichž předmětem je závazek Zhotovitele
poskytovat opakující se plnění. Tyto Dílčí smlouvy/Dílčí objednávky jsou sjednány na dobu
určitou, a to na dobu 1 (jednoho) roku ode dne nabytí platnosti a účinnosti Dílčí smlouvy/Dílčí
objednávky, pokud není v samotných Dílčích smlouvách/Dílčích objednávkách uvedeno jinak.

13.5 Objednatel má právo odstoupit od Dílčí smlouvy/Dílčí objednávky vpřípadě podstatného
porušení této Dílčí smlouvy/Dílčí objednávky Zhotovitelem. Pro účely Dílčích smluv/Dílčích
objednávek je porušení podstatné zejména tehdy, jestliže Zhotovitel porušující tuto Dílčí
smlouvu/Dílčí objednávku věděl vdobě uzavření Dílčí smlouvy/Dílčí objednávky nebo vtéto
době bylo rozumné předvídat spřihlédnutím kúčelu této Smlouvy a Dílčí smlouvy/Dílčí
objednávky, který vyplývá zjejich obsahu, že Objednatel nebude mít zájem na plnění
povinností při takovém porušení Dílčí smlouvy/Dílčí objednávky. To se týká i případů
poskytnutí vadného plněni ze strany Zhotovitele.

13.6 Ukončením této Smlouvy zanikají všechna práva a povinnosti stran ze Smlouvy. Strany jsou si
však povinny uhradit v dohodnutém termínu vzájemné pohledávky za plnění uskutečněná ke

Strana 13 (celkem 16)
dni zániku Smlouvy. Ukončením této Smlouvy a/nebo Dílčích smluv/Dílčí objednávky však
nejsou dotčena práva Stran na náhradu škody a smluvní pokutu, resp. úrok zprodlení.
Závazky obsažené v této Smlouvé týkající se zachovávání důvěrnosti zůstanou v plném
rozsahu platné a účinné ještě po dobu 5 (pěti) let od zániku této Smlouvy.

13.7 Zhotovitel se zavazuje vpřípadě ukončení Smlouvy poskytnout Objednateli nezbytnou
součinnost spočívající v pFedénI’ potřebných informací (například dokumentace, zdrojové kódy
a další relevantní data, viz povinnosti Zhotovitele) nezbytných k přesunu služby na
Objednatele nebo třetí osobu, a zajistit tím bezproblémový přesun poskytovaných služeb.
Zhotovitel je povinen vytvořit harmonogram přesunu, včetně seznamu předávaných věcí tak,
aby byla zcela zachována funkčnost poskytovaných služeb. Zhotovitel je povinen dodat
harmonogram přesunu služeb Objednateli do 90 (devadesáti) dnů ode dne zahájení prvního
Dílčího plnění. Zhotovitel je povinen aktualizovat harmonogram přesunu nejpozději do 20

(dvaceti) dnů před ukončením Smlouvy.

XIV. Závěrečná ustanovení

14. 1 Tato Smlouva nabývá platnosti a účinnosti dnem podpisu obou Stran.

14.2 Jakékoli oznámení, žádost, či jiné sdělení, jež má být učiněno či dáno Straně dle této Smlouvy
budu učiněno či dáno písemně. Toho oznámení, žádost či jiné sdělení bude, pokud ztéto
Smlouvy nevyplývá jinak, považováno za řádně dané či učiněné druhé straně, bude-li
doručeno osobně, doporučenou poštou, kurýrní službou, datovou schránkou nebo emailem
opatřeným uznávaným elektronickým podpisem na dále uvedenou adresu příslušné Strany:

14.2.1 Objednatei:

Adresa: Česká s ráva sociálního zabezpečení, Křížová 25, 225 08 Praha 5

K rukám:_ ředitel odboru implementace aplikačního programového

vybavení
E-mail:
ID datové schránky: 49kaiq3

14.2.2 Zhotovitel:

Adresa: KOMIX s.r.o., Holubova 1, 150 00 Praha 5
K rukám:
Email:
ID datové schránky: Ssqgaah

14.3 Jakékoliv oznámení podle této Smlouvy bude považováno za doručené:

14.3.1 dnem, o němž tak stanoví zákon č. 300/2008 Sb.,o elektronických úkonech
a autorizované konverzi dokumentů, ve znění pozdějších předpisů (dále jen „ZDS“) ve
svém ustanovení § 17, nebo

14..32 dnem fyzického předání oznámení, je-li oznámení zasíláno prostřednictvím kurýra
nebo doručováno osobně, nebo

143.3 dnem doručení potvrzeným na doručence, je--|i oznámení zasíláno doporučenou
poštou; nebo

Strana 14 (celkem 16)
14.3.4 dnem, kdy bude, vpřípadě, že doručení výše uvedeným způsobem nebude
zjakéhokoli důvodu možné, oznámení zasláno doporučenou poštou na adresu
určenou shora uvedeným způsobem, avšak k jeho převzetí zjakéhokoli důvodu
nedojde, a to ani ve lhůtě 3 (tří) pracovních dnů od jeho uložení na příslušném
poštovním úřadu.

14.4 Výše uvedené adresy a telekomunikační spojení mohou být měněna jednostranným písemným
oznámením doručeným příslušnou Stranou druhé Straně stím, že taková změna se stanou
účinnou uplynutím 10 (deseti) pracovních dnů ode dne doručení takového oznámení.

14.5 Strany se dohodly, že mohou komunikovat elektronickou poštou, přičemž sdělení bude
považováno za řádně doručené pouze, pokud (i) bude opatřeno uznávaným elektronickým
podpisem a (ii) bude doručeno. Nebude-Ii druhou Smluvní stranou doručení sdělení potvrzeno
do 5 (pěti) pracovních dnů od jeho odeslání, považuje se sdělení tímto pátým (5) pracovním
dnem za doručené.

14.6 Pokud není v této Smlouvě nebo v Dílčích smlouvách/Dílčích objednávkách výslovně stanoveno
něco jiného, může být tato Smlouva (včetně jejích příloh) nebo Dílčí smlouvy/Dílčí objednávky
(včetně jejich příloh) doplňovány nebo měněny pouze ve formě písemných číslovaných
dodatků podepsaných oběma Stranami.

14.7 Je-Ii nebo stane—li se některé ustanovení této Smlouvy nebo Dílčích smluv/Dílčích objednávek
neplatným, nevymahatelným nebo neúčinným, nedotýká se tato neplatnost, nevymahatelnost
či neúčinnost ostatních ustanovení této Smlouvy nebo Dílčích smluv/Dílčích objednávek. Strany
se zavazují nahradit do 5 (pěti) pracovních dnů po doručení výzvy druhé Strany neplatné,
nevymahatelné nebo neúčinné ustanovení ustanovením platným, vymahatelným a účinným se
stejným nebo obdobným obchodním a právním smyslem.

14.8 Strany se tímto dohodly, že Zhotovitel není bez předchozího výslovného souhlasu Objednatele
oprávněn postoupit či převést jakákoliv práva či povinnosti vyplývající z této Smlouvy nebo
Dílčích smluv/Dílčích objednávek na jakoukoliv třetí osobu.

14.9 Zhotovitel bere na vědomí a souhlasí stím, aby subjekty oprávněné dle zákona č. 320/2001
Sb., o finanční kontrole ve veřejné správě a o změně některých zákonů (zákon o finanční
kontrole), ve znění pozdějších předpisů, provedly finanční kontrolu závazkového vztahu
vyplývajícího z této Smlouvy a/nebo Dílčích smluv/Dílčích objednávek s tím, že se Zhotovitel
podrobí této kontrole, a bude působit jako osoba povinná ve smyslu ustanovení § 2 písm. e)
citovaného zákona.

14.10 Zhotovitel na sebe přebírá nebezpečí změny okolností ve smyslu ustanovení § 1765
Občanského zákoníku.

14.11 Nedílnou součástí Smlouvy jsou její přílohy, a to:

Příloha č. 1 k Rámcové smlouvě — „Specifikace předmětu plnění a technické požadavky“

Příloha č. 2 k Rámcové smlouvě — „Cena plněnl“

Příloha č. 3 k Rámcové smlouvě — „Podrobný popis způsobu uzavírání Dílčích smluv“

Příloha č. 4 k Rámcové smlouvě — „Vzor Dílčí smlouvy“

14.12 Tato Smlouva je vyhotovena v 5 (pěti) stejnopisech, z nichž každý bude považován za prvopis.
Zhotovitel obdrží po 2 (dvou) stejnopisech této Smlouvy a Objednavatel obdrží po 3 (třech)

. Strana 15 (celkem 16)
stejnopisech této Smlouvy. Úprava a množství stejnopisů se užije obdobně rovněž pro Dílčí

smlouvy/Dílčí objednávky, nebude-Ii v této Dílčí smlouvě/ Dílčí objednávce sjednáno jinak.

14.13 Tato Smlouva je vyhotovena v českém jazyce a tato verze bude rozhodující bez ohledu na

jakýkoli její překlad, který může být pro jakýkoli účel pořízen.

14.14 Tato Smlouva se řídí právem České republiky. Veškeré spory mezi Stranami vzniklé z této
Smlouvy nebo Dílčích smluv/Dílčích objednávek nebo v souvislosti s nimi budou řešeny pokud
možno nejprve smírně. Spory, které se nepodaří vyřešit smírně, budou řešeny před příslušným
obecným soudem CR. Rozhodčí řízení je vyloučeno.

14.15 Strany prohlašují, že si tuto Smlouvu přečetly, s jejím obsahem souhlasí, že byla sepsána

podle jejich svobodné a vážné vůle, což stvrzují svými podpisy.

Zhotovitel:

Jméno: Ing. Tomáš Rutrle
Funkce: Jednatel společnosti
Datum: Z2. 6, 207;
Místo:Praha

KOMIX s.r„o.

Holubova l, l$l) 0(1 l'mhn 5

IČO: 47117037, ou" (747117037

tela—fax

. Strana 16 (celkem 16)
% ČR - ČSSZ

ÚSTŘEDI

Křížová 25, 225 08 Praha 5

Příloha č. 1 k Rámcové smlouvě

Specifikace předmětu plnění
a technické požadavky
W ČR - Cssz
Obsah
Osment

Křížová 25, 225 08 Praha 5

1 Úvod ................................................................................................................................................ 3

2 Předmět plnění ................................................................................................................................ 4
2.1 Popis modulů APV NEM a D_STAT ............................................................................................ 5

2.2 Standardy IKT čssz ................................................................................................................... 5

2.3 Výkonnostní požadavky ............................................................................................................ 6
3 Rozvoj aplikace APV NEM a D_STAT.................................................................................................. 7

3.1 Projektové řízení ....................................................................................................................... 8
3.1.1 Metodika projektového řízení ........................................................................................... 8
3.1.2 Metodika řízení rizik ........................................................................................................ 11
3.1.3 Metodika řízení změn ...................................................................................................... 15
3.1.4 Metodika release managementu ..................................................................................... 16
3.1.5 Organizační struktura projektu ........................................................................................ 19

3.2 Analytická část ........................................................................................................................ 26
3.2.1 Metodika tvorby dokumentace ....................................................................................... 26
3.2.2 Analytické výstupy .......................................................................................................... 33
3.2.3 Příklady všech předpokládaných výstupů ........................................................................ 39

3.3 Vývojová část .......................................................................................................................... 61
3.3.1 Metodika softwarového vývoje ....................................................................................... 61
3.3.2 Metodika přípravy nasazování balíčků ............................................................................. 65
3.3.3 Příklady předpokládaných výstupů .................................................................................. 66

3.4 Testovací část ......................................................................................................................... 71
3.4.1 Příklady předpokládaných výstupů .................................................................................. 71
3.4.2 Úvodní návrh testovací strategie ..................................................................................... 73
3.4.3 Obecná metodika jednotlivých typů testů ....................................................................... 77

3.5 Školení.................................................................................................................................... 82

3.5.1 Návrh způsobu školení .................................................................................................... 82
3.5.2 Příklady školicích materiálů ............................................................................................. 84
3.6 Nasazování do produkce ......................................................................................................... 86
3.6.1 Návrh způsobu nasazování do produkce .......................................................................... 86
3.6.2 Příklady relevantní dokumentace .................................................................................... 88
3.6.3 Popis provozní dokumentace .......................................................................................... 90
rrrp—I % ČR-ČSSZ
USTŘEDI

Křížová 25, 225 08 Praha 5

3.7 Požadované součinnosti ......................................................................................................... 93

3.7.1 Popis součinnosti ............................................................................................................ 93

3.7.2 Popis role na straně ČSSZ ................................................................................................ 94

3.7.3 Rozsah očekávané součinnosti (v ČD) .............................................................................. 95

. 4 Zajištění aplikační podpory APV NEM a D_STAT .............................................................................. 96

4.1 Převzetí do servisu .................................................................................................................. 96

— 4.1.1 Rozsah převzetí do servisu .............................................................................................. 96

. 4.2 Poskytování aplikační podpory APV NEM a D_STAT ................................................................ 97

_ 4.2.1 Návrh SLA ....................................................................................................................... 98

_ 4.2.2 Algoritmus vyhodnocení aplikační podpory ..................................................................... 99

4.2.3 Rozsah služeb aplikační podpory ................................................................................... 100

I .
w ČR - ČSSZ

ÚSTŘEDI

Křížová 25, 225 08 Praha 5

1 Úvod

Závazné podmínky:

1.1 Smyslem a účelem Přílohy č. 1 Rámcové smlouvy o vývoji a údržbě aplikačního programového
vybavení pro pojistné dávky a statistiky — II (dále jen „Rámcová smlouva“), uzavřené v souladu s
ustanovením § 89 a následujícími zákona č. 137/2006 Sb., o veřejných zakázkách, ve znění
pozdějších předpisů (dále jen „ZVZ"), ustanovením § 1746 odst. 2 zákona č. 89/2012 Sb., občanský
zákoník ve znění pozdějších předpisů (dále jen „občanský zákoník") a v souladu s ustanovením §
2358 a následujícími občanského zákoníku, je zejména:

a) podrobně a přehledně vymezit předmět plnění Rámcové smlouvy, odděleně od ostatních
ustanovení Rámcové smlouvy,

b) stanovit technické specifikace předmětu plnění,
c) vymezit předmět plnění prostřednictvím návrhů Zhotovitele.

1.2 Obchodní a technické podmínky a podminky plnění dle Rámcové smlouvy stanovené
Objednatelem není Zhotovitel oprávněn upravovat.

1.3 Zhotovitel je oprávněn a zároveň povinen specifikovat v rámci této Přílohy č. 1 Rámcové smlouvy
předmět plnění v rozsahu, který je mu dán Objednatelem (viz grafické znázornění a upozornění na

povinnost doplnění příslušných informací, návrhů apod.).
% ČR - Cssz

ÚSTŘEDI

Křížová 25, 225 08 Praha 5

2 Předmět plnění

Závazné podmínky:

Aplikační programové vybavení pro nemocenské pojištění (APV NEM) slouží k evidenci nemocí a výplatě
dávek nemocenského pojištění (nemocenské, peněžitá pomoc v mateřství, ošetřovně a vyrovnávací
příspěvek v těhotenství a mateřství). Aplikační programové vybavení pro důchodové statistiky (APV
D_STAT) slouží jako statistická databáze pro vytváření přehledů o přiznaných, zaniklých a vyplácených
důchodech.

Aplikace NEM je modulárně členěna na části EPN (Evidence práce neschopných), KLR (Kontrola
léčebného režimu), LPS (Lékařská posudková služba), NV (Náhradní výplaty), EXE (Exekuce), INS
(Insolvence), DNP (Dávky nemocenského pojištění). Aplikace D_STAT se skládá z modulů IDA (Import
dat), ADA (Agregace dat), EVI (Evidence případů), EDA (Evidence importů). Součástí aplikace D_STAT je
prezentační vrstva QIikView s exporty. Aplikaci NEM využívá cca 6 500 uživatelů na všech OSSZ, PSSZ a
MSSZ Brno. Aplikaci D_STAT používá 13 licencí.

Aplikace NEM byla vytvořena v rámci zakázkového vývoje. Aplikace je vytvořena primárně v prostředí
Java a tenký klient aplikace pracuje v prostředí Internet Explorer. Pro persistentní uložení datje využíván
databázový stroj Oracle 10g. Aplikace NEM je integrována na další APV v rámci informačního systému
ČSSZ prostřednictvím webových služeb, buď „napřímo" nebo s využitím integrační platformy MS Biztalk.
Integrace se týká především systémů Kmenové evidence (KE2), Pojistné vztahy (VZT), Výběr pojistného
(POJ) a Konto příjemce (VYP).

Vzhledem k tomu, že Zadavatel již dlouhodobě využívá APV NEM a APV D_STAT a v nich zabudované
moduly, je nutné metody, postupy a nástroje při zavádění dalších změn přizpůsobit stávajícímu software
při dodržení stanovených standardů ČSSZ. Zadavatel požaduje řešení, které bude brát ohled na co
nejnižší náklady jak při implementaci změn, tak i pro vlastní provoz a údržbu aplikace za jednoznačně
definované kvality, bude minimalizovat náklady na vývoj systému, jeho údržbu, minimalizovat náklady na
integraci s již zavedenými systémy a predikovat možnosti budoucí funkcionality s ohledem na nástup
nových technologií a zařízení.

Zadavatel požaduje vypracování komplexní nabídky, která zajistí Zadavateli stabilní rozvoj APV NEM a
D_STAT, dále podporu stávajících aplikací NEM a D_STAT i nově dodaných produktů a poskytnutí
součinnosti při nasazování nových verzí aplikace do systémů Zadavatele dle kapitol 3 a 4.

Plnění bude sjednáno na dobu 4 let. Nabídnutá dodávka a služby musí tvořit jeden celek, kterýje složen
z:

0 Rozvoj APV NEM a D_STAT
o Zapracování úprav do stávajícího APV NEM a D_STAT (legislativní změny, úpravy v
aplikaci NEM a D_STAT na základě požadavků metodiků a návrhů uživatelů), vývoj a
sestavení nových komunikačních rozhraní se stávajícími i nově vytvořenými aplikacemi a
vypracování příslušné dokumentace.

. Poskytování aplikační podpory, v rámci které bude realizováno:
o Převzetído servisu,
o Poskytování podpory APV NEM a D_STAT.
W ČR - Cssz

Usrksot

Křížová 25, 225 08 Plaha 5

2.1 Popis modulů APV NEM a D_STAT

Závazné podmínky:
Níže uvedená tabulka popisuje přehled aplikací a modulů, které jsou předmětem předpokládaného
plnění.

NEM Evidence práce neschopných

Kontrola léčebného režimu

Lékařská posudková služba

Náhradní výplaty

Exekuce
Insolvence
Dávky nemocenského pojištění

D_STAT Import dat
Agregace dat
Evidence případů

Evidence importů
Prezentační vrstva QlikView s exporty

2.2 Standardy IKT čssz

Závazné podmínky:

Vývoj, rozvoj a údržba aplikačního programového vybavení realizovaného v rámci předmětného plnění
musejí být provedeny vsouladu se standardy IKT ČSSZ platnými vdobě realizace. Seznam aktuálně
platných standardů je uveden v následující tabulce:

_ Název souboru Název dokumentu

1. std_db_060803_v0.91.doc Standard databází 0.91

2. std_inet_110.doc Standard připojení k Internetu 1.10

3. std_pošta_1—00d.doc Standard poštovního systému ČSSZ 1.00
1.34
4. std_AD_DNS_DHCP_NTP_1-34.pdf Standard AD DNS DHCP 1.10
2.20
s. std_AV01-10.doc Standard Antlvlrové ochrany
0.54
6. Standard systémové konfigurace pracovní Standard systémové konfigurace pracovní 1_0__1

stanice 2.20 stanice 9

. Std__mgmtv.O.54.doc Standard Management 1__2_6

8. std__metodikavyvoje_apv_1__0_19.doc Standard metodiky vývoje 1.92d
1_0_1
9. std_pravldlareleasemanagementu_apv_1_ Předávání APV a repase
2_6.pdf 7
Standard síťové infrastruktury
včetně formulářů Programátorské konvence .NET 2.0, 3.0. a 3.5
10. std_net__1—92d.doc
11. Programatorskekonvence_1_0_17.doc
ČR-ČSSZ

Křížová 25, 225 08 Praha 5

12. BizTalkDeveloprnentStandard ..v100.doc Standardy pro tvorbu aplikací pro Microsoft 1.00
BizTalk server

13- . Požadavky na nové aplikace při integraci

AAA_Pozadavky_na_apllkace_v8.doc do AAA portálu 8.00

14. Standard__pro__tvorbu_skrlptu_db_OracIe_0 Standard pro tvorbu, předávání a spouštění 0.2

.2.doc skriptů v databázích Oracle

15. AM ROZHRANÍ SYSTÉMU DMA:

CSSZ_DMS_WS_API_DMA_v3_3_13103 WS_API_DMA - Standard rozhraní pro 3.3

1.doc ukládání dokumentů do DMS

16. CSSZ_DU_STD_V011.1.doc Standard provozu databáze Oracle 1.10

17. std__srv_0.23.doc Standard systémové konfigurace 023
18. std_PKl.pdf aplikačních serveru 1.0
Standard pro PKl

2.3 Výkonnostní požadavky

Závazné podmínky:

Níže jsou popsány standardní výkonnostní požadavky na fungování aplikace NEM. Tato pravidla jsou
obecnými standardy, pro konkrétní příklady je možné definovat delší doby odezvy, tyto výjimky ovšem
musí být vždy definovány ve funkční specifikaci a podléhají schválení Objednatele. Obecné požadované
výkonnostní požadavkyjsou:

Výkonnostní požadavek Požadovaná doba Požadované procento
odezvy splnění

Uživatelská odezva z front— endu aplikace 1 sekunda 99%
(odezva pro jednu konkrétní aktivitu — vyhledání 5 sekund

založení, ...)

Odezva online rozhraní 0,5 sekund 95%
(doba zpracování )
3 sekund 99%

V případě rozvoje aplikace musí všechna nově vznikaná rozhraní či uživatelská volání splňovat tyto
požadavky. Potencionální nová rozhraní musí zaznamenávat dobu běhu konkrétních volání (stačí zápisem
do logu). U uživatelských volání musí být Zhotovitel schopen na požádání změřit a prokázat plnění
výkonnostních parametrů.
% ČR - tssz

USTREDI

Křížová 25, 225 08 Praha 5

3 Rozvoi aplikace APV NEM a D_STAT

Úvod:

V rámci rozvoje aplikace Objednatel předpokládá poskytování služeb na implementaci rozvojových
požadavků a požadavků na změny v APV NEM a D_STAT.

Závazné podmínky:

V rámci této činnosti musí Zhotovitel pro každou rozvojovou aktivitu, zajistit následující oblasti:

0 Popis řešení a ocenění požadavků definovaných Objednatelem:
o Zhotovitel se zavazuje dodat návrh řešení a ocenění konkrétních požadavků do 10
pracovních dní od data předání požadavku Objednatelem.
o Zhotovitel se dále zavazuje, že je schopen dodat kapacity potřebné pro implementaci
rozvojového požadavku okamžitě po schválení návrhu řešení.

. Zajištění projektového vedení.
Vytvoření funkční dokumentace, případně aktualizace stávající funkční dokumentace, pokud
existuje.
Zajištění implementace schváleného požadavku.
Aktualizace technické dokumentace.
Příprava testovacích scénářů a testovacích dat.
Provedení testů — systémové, integrační, akceptační, výkonnostní a penetrační:
0 Pro konkrétní požadavek nemusí být po dohodě prováděny všechny typy testů.

o Vpřípadě, že velikost požadavku přesáhne 50 ČD (dále jen "CD", 1 ČD odpovídá 8
člověkohodinám), budou navíc provedeny regresní testy aplikace, pokud nebude
dohodnutojinak.

o Objednatel může rozporovat přechod mezi jednotlivými koly testů, v případě že kvalita
dodávky nebude splňovat dohodnutá kritéria.

Aktualizace automatizovaných testů (pokud existují).
Příprava reportu o provedeni testů.
Aktualizace provozní dokumentace.
Příprava produkčního balíčku a postupu nasazení.
Podpora nasazení do produkce.
Zvýšená podpora bezprostředně po nasazení do produkce.
% tR-Cssz

OSTREDI

Křížová 25, 225 08 Praha 5

3.1 Projektové řízení

Závazné podmínky:

Zhotovitel zajistí řešení všech disciplín projektového řízení celého projektu, včetně řízení potencionálních
subdodávek dalších aplikací ČSSZ, které budou dodávat změny vynucené projektem.

Zhotovitel před/ožízávazný popis projektového řízení dle výše uvedeného.

Popis projektového řízení musí minimálně obsahovat:
. Metodiku projektového řízení;
. Metodiku řízení rizik;
. Metodiku řízení změn;
. Metodiku release managementu;
. Organizačnistrukturu projektu.

(dop/ní Zhotovitel) — Zhotovitel doplnil, viz kapitoly níže.

3.1.1 Metodika projektového řízení

Společnost KOMIX má dlouholeté zkušenosti sdodávkami či realizací rozsáhlých projektů Objednatele.
Jsme rutinně seznámeni s procesy dle standardů IKT ČSSZ, které je nutné dodržovat pro každou realizační
fázi projektu. Na mnoha projektech KOMIX spolupracoval i sdodavateli třetích stran pro odladění
vstupních a výstupních rozhraní okolních aplikací. Při realizaci projektů byla důležitá i získaná znalost o
portfoliu aplikací a jejich funkční synergie. KOMIX tak ke každému projektu přistupuje co
nejefektivnějším způsobem s důrazem na dosažení nejvyšší uživatelské spokojenosti v co nejkratším čase
a s minimálními náklady.

KOMIX používá pro zákaznické dodávky propracovanou projektovou metodiku, která vychází
zcelosvětově uznávané metodiky PRINCEZ, hlavně pro oblast softwarových projektů. Jak už bylo
zdůrazněno v předchozím odstavci, KOMIX vždy volí rozsah nasazení metodiky s ohledem na charakter
konkrétního projektu nebo činnosti ve spolupráci s objednatelem.

Procesy, na které je společnost KOMIX certifikována dle normy ČSN EN ISO 9001:2001 pokrývají procesy
životního cyklu software (od akvizice, přes vývoj, dodání až po údržbu SW) definované v normě ČSN
ISO/IEC 12207. Požadované standardy budou zajištěny v souladu s udělenou certifikací. Další
absolvované certifikace jsou uvedeny zde: http://www.komix.cz/certifikace/

Níže jsou sepsány základní části metodiky projektového řízení společnosti KOMIX, která je pravidelně
certifikována.
% ČR - ČSSZ

ÚSTŘEDI

Křížová 25, 225 08 Piaha 5

3.1.1.1 Vznik projektu
Projektem se rozumí dočasná organizace, která je vytvořena za účelem poskytnutí produktů (výstupů).
Produkty jsou předem definovány v dokumentu Popis projektu.

Projektové řízení se zaměřuje především na plánování, delegování, monitorování a efektivní řízení všech
aspektů projektu. Projektem se rozumí souhrn postupů, který zajistí realizaci dila (produktů) co
nejefektivněji v nejkratším čase, s minimálními náklady a v nejvyšší kvalitě.

3.1 .1.2 Aspekty projektu
K měření výkonnosti projektu slouží tzv. aspekty projektu. Jsou to

0 Náklady

. Čas

0 Kvalita
. Rozsah
. Rizika
. Přínosy

Pro jednotlivé aspekty musí být definovány tzv. tolerance (rozpětí, povolená odchylka) určené pro
jednotlivé úrovně řízení projektu. Pokud například vedoucí projektu identifikuje změnu některého
aspektu vyšší, než je jeho povolená tolerance, musí tuto výjimku popsat a předat k řízení nadřízenému
orgánu např. Řídícímu výboru, včetně návrhu jeho eliminace.

3.1.1.3 Základní principy metodiky projektového řízení
Základními principy metodikyjsou:

. Průběžná kontrola projektu

Odůvodnění projektu je rozpracováno v dokumentu Popis projektu. V každé etapě, respektive na
jejím konci, je tento dokument znovu kontrolován, popř. upřesňován.

. Definované role a odpovědnosti

Na začátku projektu jsou definovány role, které definují zájmy businessu, uživatelů a dodavatelů,
případně dalších zájmových stran. Role a jejich odpovědnosti podléhají schválení příslušným
orgánem.

. Řízení pomocí etap

Projekt je plánován, monitorován a řízen na základě definice etap. Základním pravidlem je, že
následující etapa nemůže být řádně naplánována a započata bez řádného ukončení předchozí

etapy.

. Řízení na základě výjimek

Minimálně ke každému aspektu projektu jsou stanoveny tolerance sjasně definovanými
pravomocemi pro každou projektovou rolí. Pokud dojde kpřekročení tolerance, nastává tzv.
W ČR - ČSSZ

ÚSTŘEDI

Křížová 25, 225 08 Praha 5

výjimka, kterou musí řídit a schvalovat nadřízený orgán (Řídící výbor) v organizační struktuře,
která má nastaveny vyšší tolerance.

. Zaměření na produkty

Podstatou každého projektu je dodávka produktu. Popis očekávaných produktů je popsán
Objednatelem vdokumentu Popis produktu projektu (Návrhu řešení). Zde jsou specifikovány
očekávané požadavky Objednatele na kvalitu každého produktu, popř. akceptační kritéria, která
musí Zhotovitel splnit při odevzdávání produktu.

3.1.1.4 Plánování projektu
Naše metodika doporučuje užití 3 základních druhů plánů:

Projektový plán
Poskytuje přehled o celém projektu. Ukazuje hlavní aktivity, zdroje a výstupy. Pro dokument Popis
projektu poskytuje hlavní milníky a náklady projektu. Na konci každé etapy musí být aktualizován. Je
připravován projektovým vedoucím.

Plán etapy
Pokrývá kratší období, než Projektový plán. Slouží pro denní řízení prací projektovým vedoucím. Je
vytvořen na základě výkonu předchozí etapy a Je připravován projektovým vedoucím a musí být
vyhodnocen na konci každé etapy.

Týmový plán
Je vytvářen Týmovým manažerem a je nepovinný. V rámci jedné etapy vedoucí projektu může zadat práci
rozdělenou do několika tzv. „balíků práce". Zpracování takového balíku práce pak týmový manažer
popíše v týmovém plánu.

3.1.1.5 Řízení projektu

Vlastní řízení projektu pak zahrnuje tři základní fáze projektového řízení:

0 Příprava a naplánování
. Realizace a monitorování
' Uzavření a vyhodnocení

Příprava a Realizace a Uzavření a
na plá nováni monitorování vyhodnocení

10
w ČR - ČSSZ

USTREDI

Křížová 25, 225 08 Praha 5

MM-

Obrázek 1 - Fáze projektu

Ve fázi realizace a monitorování cyklicky probíhají hlavní činnosti vycházející zprincipů projektové
metodologie, jejichž cílem je vést k úspěšnému ukončení projektu.

Řízení
komunikace

Řízení kvality Řízení rozsahu

Řízení rizik Řízení zdroju

Řízení nakladu Řízení
harmonogramu

Obrázek 2 - Řízení projektu

3.1.2 Metodika řízení rizik
Rizikoje jakákoli nejistá událost, která pokud k ní dojde, ovlivňuje dosažení cílů. Může mít negativní, ale i
pozitivní dopad (příležitost).

Aby byl risk management efektivní, je nutné riziko nejdříve identifikovat - tím, že se následně riziko
popíše, je zabezpečeno porozumění dané hrozbě. Dále musí být riziko ohodnoceno. Nejlépe tak, že se
zvolí vhodná číselná stupnice a na základě hodnotících kritérií se každému riziku přisoudíjeho hodnota.

Řídit rizika znamená vykonávat odpovídající reakce a monitorovat je. Přístup k řízení je nutné popsat
v dokumentu Strategie řízení rizik.

Jednotlivá rizika se pak identifikují, hodnotí a řídí pomocí „Registru rizik".

11
% ČR-ČSSZ

Osment

Křížová 25, 225 08 Praha 5

Proces řízení rizik obsahuje tyto základní procesy:

0' ‘0

c .

0—0

Obrázek 3 - Proces řízení rizik

3.1.2.1 Identifikace rizik
Identifikace obsahu
Základním cílem identifikace je popsat riziko takovým způsobem, aby mu každý rozuměl. Jak zacházet s
riziky musí být sepsáno na začátku projektu do dokumentu Strategie řízení rizik. Dokument vzniká ve fázi
Přípravy a plánování projektu a měl by být na konci každé etapy revidován.

Identifikace rizik
. Riziko se zaeviduje v Registru rizik
. Definují se indikátory včasného varování, které monitorují potenciální zdroje rizika
. Publikace a vysvětleníjednotlivých rizik pro Řídící výbor

Pro vyjádření rizika je dobré zvážit následující aspekty:

. Příčina rizika. Jde o popsání spouštěčů rizika (na straně dodavatele, na straně zákazníka, externí
riziko, ...)

. Míra nejistoty, zda riziko nastane
. Dopad, jaký bude mít nastalé riziko na projekt

3.1.2.2 Analýza rizik
Kritérii pro hodnocení rizika jsou:

12
% ČR - (552

ÚSTŘEDI

Křížová 25, 225 08 Praha 5

. odhad pravděpodobnosti, že riziko skutečně nastane
. odhad jeho dopadů na projekt
. blízkost — časový údaj, kdy se riziko projeví

Pro každé kritérium se stanoví číselná stupnice (např.1=nejnižší až 3=nejvyšší hodnota).
Pravděpodobnost a Dopad se pak vynesou do 2 rozměrného grafu.

Hodnota rizika — je vypočtený ukazatel, HR = P x D (pravděpodobnost x dopad), nabývá hodnot

v-vl

rozčleněna do tří pásem dle níže uvedeného schématu:

VysokáPravdépodobnos

(3)

Střední

(2)

Nízká

(1)

Nízká Střední Vysoká

(l) (2) (3)

Dopad _,

Obrázek 4 — Hodnota rizika
Ve strategii řízení rizik je určen postup, na základě kterého se vyberou rizika, která vyžadují řízení na
základě vypočtené hodnoty rizika.
U těchto rizikjsou pak prováděny následující kroky:

o Preventivní opatření - opatření vedoucí ke snížení pravděpodobnosti aktivace rizika
. Krizový scénář - opatření vedoucí ke snížení dopadů rizika pojeho aktivaci
3.1.2.3 Plánování rizik
Připraví se plán specifických reakcí na zjištěná rizika. Možné plánované reakce na hrozbyjsou:
. Vyvarovat se hrozbě
. Snížit pravděpodobnost nebo dopad

13
III-IIIIIIIIITII~1II~r-' W ČR-ČSSZ

asmat

Křížová 25, 225 08 Praha 5

0 Náhradní řešení — při změně rizika na problém lze realizovat náhradní řešení
. Sdílet dopady (mezi Zhotovitelem a Objednatelem)
. Akceptovat (smířit se s dopady)

3.1.2.4 Opatření rizik

Cílem tohoto kroku je zajištění, aby odezvy byly řízeny a monitorovány, aby zvolené korekce byly
maximálně efektivní. Pro každé zidentifikovaných aanalyzovaných rizik je projektovým manažerem
určen způsob, jakým bude dané riziko řízeno. Za tímto účelem musí být každému identifikovanému riziku
striktně stanoveny následující role, včetně přiřazení zodpovědnosti těmto rolím:

Role _“ , I zodpovědnost

Vlastník rizika - Řídí a sleduje svěřená rizika

Řešitel rizika Je přiřazen vlastníkem pro řešení daného rizika

Úlohou těchto rolíje následně přiřadit každému řízenému riziku nápravná opatření.

3.1.2.5 Monitoring rizik
Aby plán řízení rizik zůstával stále aktuální, je třeba jej upravovat na základě posouzení aktuálního stavu.
Podmínky, které mohou ovlivnit následky a jejich pravděpodobnosti, se mohou změnit, stejně jako
okolnosti, které ovlivňují náklady nebo vhodnost různých přístupů ke zvládání rizik. Proto je nutné cyklus
řízení rizik pravidelně opakovat. Sledování a posuzování přinášejí také poučení z probíhajícího procesu
řízení rizik prostřednictvím hodnocení událostí, plánů zvládání rizik a jejich výsledků.

Evidovaná rizika se průběžně monitorují. Z průběžného monitorování mohou vyvstat následné kroky:

. Vyřazení evidovaného rizika
' Evidence nově vzniklého rizika
' Přehodnocení rizika a stím spojená následná opatření

3.1.2.6 Výměna informací o rizicích na projektu
Informace o rizicích či hrozbách projektu musí být správně a efektivně komunikovány uvnitř projektu i
mezi všemi zúčastněnými stranami. Stav rizik se vyhodnocuje vnásledujících oficiálních reportech
projektu podle rozsahu projektu a nastavené organizační struktury:

. Zpráva o stavu projektu
0 Zpráva o stavu etapy
. Zpráva o výjimce (např. změnovém požadavku)

Důležitými dokumenty, kde se na začátku projektu popisuje komunikace na projektu (tedy i při řízení
rizik)jsou opět podle rozsahu projektu a nastavené organizační struktury:

. Strategie řízení rizik

14
W ČR - Cssz

Osment

Křížová 25, 225 08 Praha 5

. Strategie řízení komunikace

3.1.3 Metodika řízení změn
Změny jsou přirozenou součástí každého projektu. Snahou není se jim vyhýbat, ale stanovit proces
efektivního schvalování relevantními orgány před jejich realizaci. Základním předpokladem je popis
požadavků, vůči kterému se posuzují změny.

Metodika řízení změn obsahuje tuto základni posloupnost kroků:

Identifikace opodnét
-zpracovaní a předložení
-analy'za
'schvaleni / neschválení

Implementace 4 qavedeni zmeny
-momiorovani změny

Ukončení % -vyhodnoceni
-uzavřeni

Obrázek 5 — Metodika řízeni změn

3.1.3.1 Typy změn
Základnítypy změn (otevřených bodů) jsou:

. Požadavek na změnu - změna proti oboustranně odsouhlasenému zadání
. Odchylka od specifikace — bod k doplnění funkčnosti na projektu
. Problém — ostatní otevřené body, které vedoucí projektu řeší nebo eskaluje

3.1.3.2 Proces řešení změn

Postup řešení změn je popsán následujícím způsobem:

Zachycení změnového požadavku
Projektový vedoucí nejdříve zváží, o který typ změnového požadavku jde a určí způsob formálního nebo
neformálního řešení. Neformálně (bez zápisu do registru, reportingu) lze řešit ty změny, které se řeší
okamžitě. Formální řešení předpokládá zápis do Registru otevřených bodů. Dále je bod popsán ve Zprávě
o změnovém požadavku, kterýje zasílán na projektový tým.

15
Ill-III-Ilm M ČR - Cssz

Osman:

Křížová 25, 225 08 Praha 5

Prošetření
Vedoucí projektu provede analýzu dopadů vzhledem kvýkonnostním aspektům projektu (čas, náklady,
kvalita, rozsah, rizika a benefity). Dále navazuje provedení analýzy z pohledu obchodního, uživatelského i
dodavatelského (např. zdali cena za dodání a implementaci vyváží nové požadavky na produkt).

Návrh

Navrhne se více alternativ řešení. Tyto se poté poměřují porovnáním získaných výhod řešení proti
dopadům dané alternativy řešení.

Analýza možností

m,.„i
..:,„n „„ „mr .

Zpráva o .

Zpráva o vyjlmce

Obrázek 6 - Proces řešení změn

Rozhodnutí o provedení změny
Vedoucí projektu zváží, zdali eskalovat problém rizikovosti provedení změny na vyšší rozhodovací instanci
nebo řešit problém na své úrovni. Pokud musí, eskaluje problém na Řídící výbor.

Implementace změn
Vedoucí projektu dá pokyn zapracovat změnu podle připraveného postupu a dále sleduje přídavná
změnová rizika na projektu. Na rozsáhlém projektu je i potřeba zdokumentovat změnu v tzv. Systému
řízení konfigurace, který je popsán vdokumentu Strategie řízen/' konfigurace (popis procesu řízení
otevřených bodů a změn, nástroje a techniky, způsob reportování, role a zodpovědnosti).

Záznam konfiguračních položek — uchovává záznamy stavů, verzí a variant jednotlivých konfiguračních
položek a vztahů mezi nimi.

3.1.4 Metodika release managementu

Release management je proces zajišťující dohled nad vývojem, testováním, nasazením a bezprostřední
podporou uvolněných softwarových verzi.

16
W ČR - čssz

Osment

Křížová 25, 225 08 Praha 5

Tato činnost v sobě zahrnuje několik základních procesů, které se pro každou uvolňovanou verzi vždy
opakují.

Vytvoření Zvýšena Vyhodnoce
verze podpora ni

Obrázek 7 - Release management

Plánování

Zařazení odsouhlasených změn a funkčností to uvolňované verze vsouladu s dohodnutým rozsahem a

harmonogramem projektu.

Vytvoření verze
Přiřazení všech potřebných programových komponent do verze vsouladu splánem této verze a
v souladu sjejich technologickou a funkční připraveností pro provedení testů.

Testování
Ověření funkčností vytvořené verze z řady pohledů (technická funkčnost, business funkčnost, integrační
funkčnost,...). Toto testování se provádí nejprve u zhotovitele a následně i na testovacím prostředí
Objednatele (ve spolupráci sním). Úspěšné absolvování všech testů (splnění akceptačních kritérií)
umožní následné nasazeníverze.

Nasazení
Uvolnění všech otestovaných a akceptovaných komponent do produkčního prostředí Objednatele. Tento
proces je také závislý na zaškolení uživatelů systému na funkčnosti uvolněné verze a uvolnění
odpovídající dokumentace k této verzi.

Zvýšená podpora
Zajištění rychlého řešení provozních problémů, které se po nasazení nové verze mohou vyskytnout.

Vyhodnocení
Po ukončení zvýšené podpory je provedeno vyhodnocení releasu dané verze a jsou případně přijata
nápravná opatření, která budou využita pro zkvalitnění procesu Release Managementu následujících
verzí.

3.1.4.1 Úzká vazba na další metodiky projektového řízení

Metodika Release Managementu se prolíná celou metodikou projektového řízení, jelikož má vazbu na
řadu procesů. Mezi hlavní provázané procesy pak patří:

Proces evidence a řešení chyb
Proces řízení změn
Proces řízení rizik
Proces řízení vývoje, testování a příprava verzí

17
% ČR-ČSSZ

Osman:

Křížová 25, 225 08 Praha 5

3.1.4.2 Hlavní principy release managementu

Cílem je zajistit, aby se pozornost soustředila na dodání produktů etapy v rámci stanovených tolerancí.

Z tohoto důvodu se průběžně:

. Sledujíjakékoliv odchylky od směřování produktů dohodnutých na začátku etapy s cílem vyhnout
se nekontrolovaným změnám
Zajišťuje kontrola rizik a otevřených bodů
Přehodnocuje zdůvodnění projektu
Kontroluje dodání produktů v souladu s dohodnutými standardy (kvality, náklady, úsilí, čas)
Podporuje dosažení definovaných přínosů

V souladu s metodologií je každá etapa projektu rozdělena do balíků práce a průběžně monitorována již
na úrovni těchto balíků práce (BP). Balíkem práce se rozumí např. uzavřený soubor požadavků pro dílčí
modul APV, realizovaný v rámci jedné etapy projektu

,, ,, Vyhodnocení Přijetí
VytvorenI BP Schvalenl BP stavu BP dokončeného

Obrázek 8 — Fáze release managementu

Schematický postup v Release Managementu dané etapy:

T T

Oprávnění dodat BP Dom-mien? BP

lrIIIIIIIIIIIIIIIIIII
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
.
I
I
I
I
I
I
I
I
I
I
I
I IIIIIIIIIIIIIIII
RELEASE MANAGEMENT

Obrázek 9 - Schematicky postup v Release Managementu dané etapy

Každý Balík práce je následně vyhodnocován podle rozsahu projektu Zprávou o stavu balíku práce a
obsahuje tyto základní informace, které se dále v rámci Release Managementu evidují a řídí:

18
M ČR - ČSSZ

úsrREDI

Křížová 25, 225 08 Praha 5

Produkty, které tým dokončil
Provedené aktivity řízení kvality
identifikované poznatky
Produkty, které bude tým vytvářet v následujícím období
Produkty, které plánuje tým dokončit v následujícím období
Aktivity řízení kvality naplánované
Stav tolerancí balíku práce
Otevřené body, rizika

3.1.4.3 Víceúrovňové testování

Zásadní vliv na kvalitu uvolňované verze produktu má pak testování. Pro zvýšení kvality se provádí
testování na několika stupních a s různými zaměřeními.

Testování se provádí v rámci Release Managementu jak na úrovni zhotovitele, tak v poslední fázi před
nasazením do produkčního prostředíi na úrovni Objednatele.

Testování se provádí pro každou uvolňovanou verzi produktu, bez ohledu na to, zda jejím obsahem je
Balík práce, Etapa projektu či Komplexní produkt v rámci dodávky.

3.1.4.4 Hlavní prováděné testy na straně Zhotovitele

. Unit testy — testování vývojového týmu.
. Funkční testy — testování verze dle testovacích scénářů a testovacích případů.
. Interní ověření verze k uvolnění Objednateli — kompletní ověření verze z businessu pohledu a

z pohledu úplnosti. V případě regresních testů se využívá automatické testování.
. Zátěžové testy — testování odezev systému v reálné zátěži s množstvím dat odpovídajícím

standardnímu provozu.
. Penetrační testy — testování síťového zabezpečení pomocí simulace možných útoků jak zevnitř,

tak zvenčí.

3.1.4.5 Hlavní prováděné testy na straně Objednatele

. Integrační testy - testování systému na kopii (z hlediska SW i HW) rutinního prostředí
Objednatele a případné návaznosti na spolupracující systémy třetích stran.

0 Uživatelské akceptační testy — podkladem pro tyto testy jsou vzájemně odsouhlasené testovací
scénáře, testovací vzorek dat a plán pro akceptační testování. Tento typ testu je rozhodující pro
nasazení verze do rutinního prostředí a podléhá akceptaci Objednatele.

. Regresní testy — testování všech funkcionalit systému APV.

3.1.5 Organizační struktura projektu

Organizační struktura projektu je dočasná, vzniká vokamžiku schválení projektu a zaniká vokamžiku
ukončení projektu. Organizační struktura projektu je vytvořena za účelem dosažení cílů projektu tak, aby
byl zajištěn co možná nejefektivnější průběh projektu bez zbytečných prodlev.

Konkrétní organizační struktura projektu bude upřesněna při zpracování plánu projektu. Po dohodě
svedoucím projektu Objednatele budou stanovena také pravidla aformy komunikace členů

19
% (ČR-ČSSZ
Usriiizol

Křížová 25, 225 08 Praha 5

projektového týmu tak, aby se minimalizovaly časové prodlevy a zároveň se zabezpečila odpovídající
dostupnost sdílených informací a možnost průběžné kontroly stavu a postupu projektu.

Předpokládáme účast jednotlivých specialistů týmu v rozsahu dle potřeb a průběhu realizace projektu
vjednotlivých etapách. V případě operativní potřeby předpokládáme možnost účasti dalších specialistů
ze strany Objednatele i Zhotovitele.

Předpokládáme vysokou míru součinnosti odpovídající průběhu realizace projektu.

Účast jednotlivých rolí v projektovém týmu se bude dynamicky měnit v souladu s potřebami jednotlivých

etap projektu.

Řídicí výbor
Vrcholným orgánem projektu je Řídicí výbor projektu, kterýje tvořen zástupci Objednatele a Zhotovitele.

Řídicí výbor má rozhodovací pravomoc:
. Rozhoduje o základních záležitostech projektu, stanovuje jeho priority.
0 Je informován o průběhu a postupu projektu a v případě změn s vlivem na základní parametry
projektu (tj. časový harmonogram, náklady, dostupnost zdrojů) rozhoduje o dalším postupu
projektu na základě předložených variant řešení.
. Schvaluje důležité projektové dokumenty předložené vedoucími projektu (např. Plán projektu,
Organizační strukturu projektu, Zpráva o splnéni dílčího požadavku projektu, Závěrečná zpráva

projektu, atd.).
. Kontroluje stav a průběh projektu a vydává rozhodnutí za účelem podpory plnění cílů projektu.

Rozhoduje na základě předložených variant 0 postupech při prevenci a řešení rizik projektu.
Řeší krizové situace projektu a rozhoduje o mimořádných opatřeních kjejich odstranění.
Potvrzuje akceptaci jednotlivých etap na základě Zprávy o stavu projektu.
Potvrzuje akceptaci dílčích výstupů (požadavků) na základě Zprávy o splnění dílčího požadavku.
Podporuje vedení projektu.
Je eskalační úrovní pro vedení projektu.
Rozhoduje o ukončení projektu na základě zpráv o průběhu a zajištění projektu a na základě
Závěrečné zprávy o projektu.

Předpokládáme následující složení Řídícího výboru projektu:

o zástupce (zástupci) sponzora (sponzorů) řešení Objednatele,
. zástupce vrcholového managementu Zhotovitele,
. vedoucí projektu Objednatele,
. vedoucí projektu Zhotovitele.

Vedoucí projektu
Vlastní řízení projektu provádí vedoucí projektu, který má výkonnou pravomoc. Vedoucí projektu je role
obsazovaná jak Objednatelem, tak Zhotovitelem tj. existuje vedoucí projektu Zhotovitele, který řídí a
koordinuje tým Zhotovitele a vedoucí projektu Objednatele, který řídí a koordinuje pracovníky
Objednatele, kteří poskytují Zhotoviteli součinnost. Oba vedoucí projektu připravují podklady pro

rozhodování Řídícího výboru.

20
W ČR - ČSSZ

USTREDI

Křížová 25, 225 08 Praha 5

. Vedoucí projektu Objednatele: pověřený pracovník, který je oficiálním zástupcem Objednatele. Je
odpovědný za realizaci projektu aje vybaven příslušnými pravomocemi pro řízení a koordinaci
pracovníků Objednatele, kteří poskytují řešiteli součinnost.

. Vedoucí projektu Zhotovitele: pověřený pracovník, který je oficiálním zástupcem Zhotovitele. Je
odpovědný za zabezpečování řízení, realizaci a jakost projektu.

Oba vedoucí projektu připravují podklady pro rozhodování Řídícího výboru. Návrhy dokumentů řízení
projektu vypracovává vedoucí projektu Zhotovitele a doplňuje je na základě konzultací svedoucím
projektu Objednatele.

Vedoucí projektu obou stran:
. Provádí operativní řízení projektu a odpovídají za dosažení cílů projektu (realizaci předmětu
smlouvy).
Řídí zdroje v oblasti své působnosti přidělené na projekt.
. Řídí a koordinují projektové týmy v oblasti své působnosti.
Sestavují, sledují a vyhodnocují stav projektu dle Plánu projektu a průběžně aktualizují Plán
projektu a časový harmonogram projektu.
Sledují postup prací na projektu, kontrolují dosažené výsledky.
Sleduji, vyhodnocují a řídí rizika projektu.
Zajišťují realizaci opatření vedoucí k minimalizaci rizik.
Zabezpečují řízení požadavků a změn v projektu.
Vedou projektové výkaznictví.
Připravují podklady pro jednání Řídícího výboru.
Připravují návrhy na změny a opatření pro Řídící výbor.

Po dohodě svedoucím projektu Objednatele budou stanovena pravidla aformy komunikace členů
projektového týmu tak, aby se minimalizovaly časové prodlevy a zároveň se zabezpečila odpovídající
dostupnost sdílených informací a možnost průběžné kontroly stavu a postupu projektu.

Řešitelské týmy
Výkonnou činnost dle zadání vedoucího projektu provádějí Řešitelské týmy. Řešitelské týmyjsou tvořeny
členy projektového týmu Zhotovitele případně subdodavatelů Zhotovitele, v odůvodněných případech
může být součástí řešitelského týmu i specialista Objednatele.

. Zpracovávají analýzu a návrh řešení vymezeného předmětu plnění podle harmonogramu

projektu.
. Realizují řešení podle schváleného návrhu včetně zpracování požadované dokumentace.

. Provádí testování řešení spolu se zdokumentováním výsledků testování.
. Zástupci řešitelského týmu se účastníjednání vedení projektu na vyžádání vedoucího projektu.

Konkrétní řešitelské týmy stanoví vedoucí projektu při zahájení projektu.

3.1 .5.1 Organizační struktura realizace projektu na straně Zhotovitele
Realizace dodávaného řešeníje opřena převážně o tyto základní role:

Vedoucí projektu za Zhotovitele
. řídí projekt dodávky a integrace APV či jiného systému,

21
I..-Il-rII—rrrrITrlTl-l % CR - ČSSZ
UsrREoI

Křížová 25, 225 08 Praha 5

vypracovává a udržuje v aktuálním stavu celkový plán projektu včetně milníků,
koordinuje na denní bázi práce na implementaci Systému,
formuluje dostatečně předem operativní požadavky na Objednatele, vyplývající z realizace,
projektu; tyto požadavky musí být v souladu se závazky Objednatele (uvedenými ve Smlouvě),
vedoucímu projektu za Objednatele předává požadavky na činnosti řešitelských týmů,

navrhuje Řídícímu výboru změnové řízení,

udržuje změnovou dokumentaci,
připravuje podklady pro Řídící výbor a pro schůzky vedoucích projektů,
odpovídá za řádné a úplné vedení dokumentace projektu,
na schůzkách, kterých se účastní (schůzky vedoucích projektů, řešitelských týmů), zodpovídá za
pořízení zápisů,
odpovídá za věcnou správnost vyhotovených faktur,
na své straně odpovídá za distribuci podkladů předaných Objednatelem,
definuje strategii zajištění kvality projektu a zajistí její projednání s dalšími subjekty,
zodpovídá za posouzení kvality dílčích požadavků (včetně dokumentace), dodávaných
Objednateli,
podílí se na tvorbě plánů projektových milníků,
vypracovává Zprávy o stavu projektu pro Řídící výbor,
vypracovává závěrečnou zprávu o ukončení projektu,

je primární kontaktní osobou za zhotovitele a musí být informován o veškeré komunikaci mezi

stranami, pokud nestanovíjinak.

Architekt

odpovídá za návrh řešení a datový model i s ohledem na okolní systémy,
je povinen se zúčastnit důležitých jednání s Objednatelem, týkajících se návrhu architektury a
datového modelu systému.

V rámci realizace projektu podléhá Architekt vedoucímu projektu Zhotovitele.

Odborný analytik/konzultant oblasti
odpovídá za řešení všech typů požadavků na systém a jejich jednotlivé části/moduly,
odpovídá za parametrizaci systému,
definuje stanovisko k předkládaným návrhům řešení Objednatele,
vytváří projektovou dokumentaci včetně plánu přejímek,
účastní se při předání díla a jejich části (ve své oblasti) a posuzování věcné správnosti funkcí
systému,
posuzuje věcnou správnost a předává podepsané dokumenty „Zápis z jednání", „Požadavek na
změnové řízení", resp. „Vyjádření ke změnovému řízení" a další dokumenty vztahující se
k problematice projektu vedoucímu projektu,
připravuje plán testování,
je povinen se zúčastnit důležitých jednání s Objednatelem, týkajících se dané odborné oblasti.

V rámci realizace projektu podléhá odborný analytik/konzultant vedoucímu projektu Zhotovitele.

22
WH ČR - Cssz

ÚSTŘEDÍ

Křížová 25, 225 08 tha 5

Kancelář projektu
Zajišťuje řádné vedení a ukládání dokumentace a další administrativu projektu, archivaci a distribuci
všech dokumentů projektu. Pracovníka odpovědného za kancelář projektu jmenuje vedoucí projektu
Zhotovitele.

3.1.5.2 Organizační struktura realizace projektu na straně Objednatele
Realizace dodávaného řešeníje opřena převážně o tyto základní role:

Vedoucí projektu za Objednatele

koordinuje práce na projektu na straně Objednatele, zejména práce řešitelského týmu a
vytváření podmínek pro jeho činnost,

odpovídá za jednání se Zhotovitelem,
na denní bázi komunikuje s vedoucím projektu na straně Zhotovitele a projednává s ním všechny
podstatné otázky, které se týkají projektu,
odpovídá za zajištění součinnosti třetích stran, jejichž služby nebo dodávky ovlivňují Systém na
straně Objednatele,
schvaluje vytvořené projektové dokumenty (předávací protokoly, akceptační protokoly apod.),
schvaluje veškeré závazné dokumenty (mj. zadání, požadavky, protokoly o předání, informace,
atd.), které Objednatel poskytuje Zhotoviteli a zodpovídá jménem Objednatele za jejich

správnost,

koordinuje formulaci požadavků Objednatele,

zadává úkoly realizačnímu týmu Objednatele,

zajišťuje podmínky (technické, organizační, personální) pro zajištění prací na projektu na straně

Objednatele,

zabezpečuje rozsah přístupu pracovníků Zhotovitele do ostatních informačních systémů

Objednatele dle pravidel ČSSZ,

navrhuje Řídícímu výboru změnové řízení,
navrhuje změny vnitřních předpisů Objednatele, pokud vyplynou z řešení projektu,
na základě doporučení odborných garantů rozhoduje o schválení, nebo odmítnutí podkladů,
které Zhotovitel předloží Objednateli, zejména návrhů řešení, projektové dokumentace, plánů
přejímek, přejímacích protokolů, atd.,
na své straně odpovídá za distribuci podkladů předaných Zhotovitelem,
vjednotlivém případě může změnit rozhodnutí či doporučení odborného garanta a dalších členů
řešitelského týmu. Proti rozhodnutí vedoucího projektu je možno se odvolat k Řídícímu výboru,
je primární kontaktní osobou za Objednatele a musí být informován o veškeré komunikaci mezi

stranami, pokud nestanovíjinak.

Odborný garant APV
odpovídá za formulaci všech typů požadavků na Systém a jejich jednotlivé části/moduly,
odpovídá za posuzování funkčnosti a parametrizaci systému,
definuje stanovisko k předkládaným návrhům řešení Zhotovitele,
schvaluje projektovou dokumentaci včetně plánu přejímek,
věcně schvaluje a spolupodepisuje přejímací protokoly,
odpovídá za přidělování a kontrolu úkolů členů řešitelského týmu ve své organizaci,

23
WE? ČR - tssz

ÚSTŘEDI

Křížová 25, 225 08 Praha 5

. zabezpečuje uvolnění podřízených členů řešitelského týmu zobvyklých pracovních činností
v určených termínech podle potřeb projektu,

. posuzuje věcnou správnost a předává podepsané dokumenty „Zápis z jednání", „Požadavek na

změnové řízení", resp. „Vyjádření ke změnovému řízení" a další dokumenty vztahující se

k problematice projektu vedoucím projektu,
o je povinen se zúčastnit důležitých jednání se Zhotovitelem, týkajících se dané funkčnosti,
. koordinace evidence chyb z provedených testů v produkčním a testovacím prostředí,
o je hlavní komunikační osobou mezi řešitelskými týmy obou stran po uvedení systému do

provozu.

V rámci realizace projektu podléhá odborný garant vedoucímu projektu Objednatele.

Výkonným článkem realizace projektu je řešitelský tým složený z odborných garantů jednotlivých oblastí
(kompetentních zástupců odborných útvarů) a členů týmu, kterých se zaváděný projekt pracovně týká.
Realizační tým připravuje rutinní provoz systému.

Člen řešitelského týmu

. podílí se na pilotním provozu,
. účastní se a provádí akceptační přejímky,
. spolupracuje s odbornými garanty — zejména při formulaci požadavků, při ověřování Systému a

přejímkách a předávání připomínek k Systému,
. předává své připomínky k Systému formou „Požadavku na změnové řízení",
. předává výsledky testování pilotního provozu.

Uživatel
. účastní se rutinního provozu,
. předává své připomínky k Systému formou Požadavku na změnové řízení,
. případně vytváří Hlášenívad systému.

Administrátor systému
' zajišťuje schválenou technologickou infrastrukturu pro chod Systému,
. účastní se příslušných školení,
. účastní se přejímek,
. účastní se, případně napomáhá instalaci a reinstalaci systému, kterou do předání systému jako
celku provádí Zhotovitel,
. provádí kontroly zálohování,
. napomáhá praktické distribuci změn Systému,
. řeší kolizní stavy při komunikaci Systému,
. zabezpečuje bezproblémový provoz hardwarového vybavení,
. zabezpečuje bezproblémový chod základního softwarového vybavení.

Metodický garant (Metodik APV)
. účastní se nasazováni a parametrizace systému společně se zástupci Zhotovitele,
. napomáhá prakticky plnit číselníky, udržovat parametrizaci systému v souladu s rozvojem APV,
. řeší s uživateli drobné dotazy na obsluhu systému,
. účastní se přejímek,

24
% ČR - Cssz

ÚSTŘEDI

Křížová 25, 225 08 Praha 5

zpracovává a doplňuje Požadavky na změnové řízení a Hlášení vad systému,
účastní se přejímání hlavních etap projektu,
pomáhá se zajištěním vazeb na jiné aplikace,
navrhuje práva pro přístup do systému a podílí se na definicích profilů — přístupových práv
k jednotlivým funkcím systému,
účastní se přejímek Systému a jejich částí (ve své oblasti) a posuzuje věcnou správnost funkcí
systému,
účastní se všech školení,
účastní se testovacího a rutinního provozu jednotlivých modulů.

25
% ČR - ČSSZ

USTREDI

Křížová 25, 225 08 Praha 5

3.2 Analytická část

Závazné podmínky:

V rámci analytické části projektu Zhotovitel zajistí:

Katalog požadavků a jeho aktualizaci;
Konsolidaci a ukotvení zadání;
Ocenění pracnosti jednotlivých požadavků;
Provedení analýzy požadavků;
Návrh architektury jednotlivých úprav APV;
Vytvoření detailního návrhu řešení úprav APV včetně návrhů dopadů do aplikační i databázové
vrstvy (v závislosti na rozsahu požadavků a dopadů realizovaných úprav aktualizace příslušných
dokumentů popisující procesní a funkční specifikaci, datovou architekturu, architekturu HW a
SW, rozhraní a integraci s okolními APV a systémy) a zapracování změn do stávající
dokumentace;
. Analýza a návrh integrace dotčených APV a systémů do IS ČSSZ;
. Přípravu a popis testovacích scénářů projednotlivé typy testů.

Zhotovitel předloží závazný popis plnění dle výše uvedeného.

Zhotovitel minimálně popíše:
. Metodiku tvorby dokumentace;
' Příklady všech předpokládaných výstupů.

(doplní Zhotovitel) - Zhotovitel doplnil, viz kapitoly níže.

3.2.1 Metodika tvorby dokumentace

3.2.1.1 HIavm’ analytické dokumenty (konsolidace a ukotvení zadání)
Vanalytické části projektu budeme při tvorbě dokumentace vycházet z níže popsané struktury
dokumentů Úvodní studie a Realizační projekt. Jedná se o osvědčený postup, který byl použit i na
ostatních projektech pro ČSSZ, na kterých se společnost KOMIX účastnila vroli dodavatele nebo
subdodavatele (NEM, SPR, INS, MKV apod.) Obdobnou strukturu těchto dokumentů používají i ostatní
dodavatelé ČSSZ, proto chceme zachovat tento jednotný způsob popisu návrhu řešení vanalytické
dokumentaci. Tento způsob analytické dokumentace je výhodný i pro pracovníky ČSSZ, protože jsou na
něj zvyklí a snadněji se vněm budou orientovat. Vprůběhu vytváření těchto dokumentů dochází
k postupné konsolidaci a ukotvení zadání, které je před vlastní realizací schváleno zákazníkem. V případě
řešení dílčích změnových požadavků budou tyto požadavky řešeny následujícím postupem:

. Provedení aktualizace katalogu požadavků.
. Vyjasnění a popis návrhu cílového stavu, který obsahuje zejména:

o Výčet dotčených případů užití a popis zmén v těchto případech užití.

26
w ČR - ČSSZ
ÚSTŘEDÍ

Křížová 25, 225 08 Praha 5

o Výčet a detailní popis nových případů užití.00000 0
Popis změn uživatelského rozhraní — změny obrazovek, nové obrazovky, dopady

do screenflow.

Změny datového modelu, zpravidla jeho rozšíření.
Změny stavových diagramů sledovaných entit.
Návrh architekturyjednotlivých úprav APV.
Změny rozhraní poskytovaných aplikací.
Požadavky na součinnost okolních aplikací, definice požadovaných změn okolních
aplikací a jejich rozhram’.

Schválení návrhu cílového stavu.

Realizace (naprogramování) funkcionality, a aktualizace související dokumentace.
Nasazení do integračního a testovacího prostředí.
Akceptace požadavku.

Nasazení do produkčního prostředí.

V případě většího množství, nebo rozsahu požadavků bude analýza rozdělena na 2 části:

Úvodní studie

Realizační projekt (Detailní návrh)

3.2.1.1.1 Úvodní studie
Úvodní studie bude zaměřena na definici a popis požadavků a vytvoření procesního pohledu, globálního
návrhu modulů a jejich vazeb, určení rozsahu spravovaných dat jednotlivými moduly a aplikacemi. Dále
se studie zaměří na identifikaci projektových rizik, které vyplývají mj. ze skutečnosti, že projekt má
mnoho vazeb na okolní systémy a bude tedy nutné koordinovat postup sdalšími projekty. Součástí
studie bude i návrh eliminace rizik. Další řešenou oblastí bude strategie migrace dat a postup nasazování.

V rámci úvodní studie bude dále provedeno:

sjednocení pojmů používaných Objednatelem a Zhotovitelem - tím bude zajištěno i shodné
porozumění řešené problematice a budou minimalizována rizika s tím spojená;
identifikace zainteresovaných osob na straně Objednatele, kterých se týká návrh uvažovaného
informačního systému;
detailní identifikace očekávání Objednatele v otázce čemu má požadovaný systém sloužit a co
má dělat a jaká jsou jeho případná omezení;
identifikace a řešení případných konfliktních požadavků;
upřesnění definice hranic požadovaného systému vymezením rozsahu spravovaných dat, rozsahu
ICT funkcí a služeb, které budou podporovat obchodní procesy, identifikace rozhraní na existující

aplikace;

identifikace dopadů souvisejících s nasazením systému na stávající obchodní procesy i dopadů na
organizační strukturu společnosti;
poskytnutí srozumitelných a spolehlivých podkladů pro zpracování detailní analýzy (tj.
Realizačního projektu) a návrhu systému;

vytvoření podkladu pro ověřování v rámci akceptace, zda dodaná aplikace splňuje všechny

deklarované potřeby Objednatele.

27
ma CR—Cssz

USTREDI

Křížová 25, 225 08 Praha 5

Struktura dokumentu Úvodní studie

1 Manažerské shrnutí

1.1. Zásadní závěry

Současný stav

2.1 Současný stav řešení

2.2 Rozsah současné aplikační podpory
2.3 Organizační struktura a role

2.4 Cíle a odůvodnění projektu

Návrh budoucího stavu

3.1 Koncepční popis cílového stavu

3.1.1.Funkční dekompozice

3.1.2. Datová architektura

3.1.3.Procesní architektura

3.1.4. Služby poskytované systémem
3.1.5.Zdroje dat a způsobyjejich naplnění
3.1.6 Návrh hlavních technologických komponent
3.2 Koncepce migrace a přechodu na nový systém
Katalog pojmů/Pojmový model
4.1 Prezentace hlavních pojmů

4.2 Katalog pojmů

4.3 Diagram pojmů

4.4 Stavy hlavních pojmů

Katalog organizačních rolí a spolupracujících systémů
5.1 Organizační role

5.2 Přehled okolních spolupracujících aplikací
Katalog procesů

6.1 Seznam procesů

6.2 Popis procesu 1

6.3 Popis procesu 2

28
my] ČR - ČSSZ

ÚSTŘEDI

Křížová 25, 225 08 tha 5

7 Katalog požadavků

7.1 Základní potřeby a očekávání

7.2 Požadavky na funkcionality systému / Funkční požadavky
7.2.1 Logický modul A

7.2.2 Logický modul B

7.3 Požadavky na rozhraní se spolupracujícími aplikacemi
7.3.1 Rozhraní s XY

7.3.2 Rozhraní s ZA

7.4 Požadavky na tiskové výstupy

7.5 Požadavky na data

7.6 Požadavky na migraci dat a na náběh nového systému
7.7 Požadavky na vlastnosti systému

7.8 Požadavky na bezpečnost

8 Popis projektu a jeho etap, upřesnění harmonogramu, rozpočet projektu

9 Upřesnění součinnosti

10 Závěry analýzy

10.1ldentifikace rizik a návrh opatření kjejich eliminaci
10.2 Podrobné závěrečné zhodnocení
10.3 Upozornění a doporučení dalšího postupu

11 Použité zdroje, zkratky a pojmy

12 Přílohy

3.2.1.1.2 Realizační projekt (Detailní návrh)

Realizační projekt zahrnuje detailní analýzu, dále podrobný návrh „drátěného modelu" obrazovek,
funkční specifikaci formou scénářů use case, fyzický datový model, podrobný popis algoritmů, definici
workflow, definici podoby tisků, popis rozhraní, popis a definici číselníků včetně jejich hodnot a popis
parametrů systému. Realizační projekt bude vznikat postupně (inkrementálně) pro jednotlivé moduly a
předpokládáme i jeho postupné schvalování ze strany Objednatele. Tento postup umožní plynulý
přechod od analýzy kvývoji pro všechny aplikace. Realizační projekt (detailní návrh) se bude realizovat
pouze v případě větších rozvojových a změnových požadavků. V případě realizace požadavků menšího
rozsahu bude vytvářen pouze návrh cílového řešení, který bude obsahovat pouze vybrané kapitoly

realizačního projektu v závislosti na rozsahu plnění a povaze jednotlivých změnových, nebo rozvojových

požadavků (viz výše).

29
W ČR - ČSSZ

USTŘEDI

Křížová 25, 225 08 Praha 5

Struktura dokumentu

1 Manažerské shrnutí

2 Upřesnění rozsahu projektu

2.1 Rozsah projektu

2.2. Předpoklady a omezení

2.3. Návaznost na předcházející dokumenty

2.4 Související projekty

Analýza současného stavu

(lze odkazem na dokument Úvodní analýzy, pokud neby/y zjištěny nové zásadní skutečnosti)
Seznam aktorů / organizačních rolí

4.1 Organizační role

4.2 Přehled okolních spolupracujících aplikací

Katalog požadavků

5.1 Základní potřeby a očekávání

(lze odkazem na dokument Úvodní analýzy, pokud neby/y zjištěny nové zásadní skutečnosti)
5.2 Požadavky na funkcionality systému / Funkční požadavky

5.2.1 Logický modul A

5.2.2 Logický modul B

5.3 Požadavky na rozhraní se spolupracujícími aplikacemi

5.3.1 Rozhraní s XY

5.3.2 Rozhraní s ZA

5.4. Definice

5.4 Požadavky na tiskové výstupy

5.5 Požadavky na data

5.6 Požadavky na vlastnosti systému (výkon, dostupnost, auditovatelnost apod.)
Detailní specifikace řešení

6.1 Procesní model

6.1.1 Seznam procesů

6.1.2 Proces 1

30
W ČR - čssz

USTREDI

Křížová 25, 225 08 Praha 5

6.1.3 Proces 2
6.2 Funkční specifikace a use case

6.2.1 Logický modul A
6.2.2 Logický modul B
6.3 Pravidla a algoritmy
6.4 Datová architektura
6.4.1 Logický datový model
6.4.2 Klasiﬁkace dat
6.4.3 Fyzický datový model
6.4.4 Zdroje data způsob jejich naplnění
6.5 Uživatelské rozhraní a výstupy
6.5.1 Návrh obrazovek
6.5.2 Specifikace tištěných výstupů
6.6 Popis vnitřních a vnějších rozhraní
6.6.1 Externí rozhraní
6.6.2 Interní rozhraní
6.7 Návrh integrace dotčených APV a systémů do IS ČSSZ
6.8 Shrnutí rozdílů oproti aktuálně provozované verzi
Návrh SW architektury včetně návrhu architekturyjednotlivých úprav APV
Upřesnění plánu
8.1 Harmonogram realizace návrhu
8.2 Plán vytvoření testovacího prostředí a databáze testovacích dat
8.3 Plán testů
8.3.1 Interní testování
8.3.2 Integrační testování
8.3.3 Akceptační testování
8.3.4 Zátěžové testy
8.4 Plán školení
8.5 Pilotní provoz v produkčním prostředí

31
W CR-Cssz

Osman:

Křížová 25, 225 08 Praha 5

9 Akceptační kriteria

10 Návrh zajištění provozu

10.1 Plán a podminky nasazení

10.2 Administrace APV

10.2.1 Podmínky provozu

10.2.2 Podpora provozu (HelpDesk)

10.2.3 Způsob zálohování dat a archivace

10.2.4 Monitoring APV

11 Rizika

12 Závěr

13 Použité zdroje, zkratky a pojmy

14 Přílohy

Některé kapitoly mohou být zpracovány formou samostatné přílohy.

3.2.1.2 Metodika vývoje
Při tvorbě dokumentace vycházíme z metodiky ICONIX proces. Jedná se o standardní metodiku
založenou na Rational Uniﬁed Process společnosti IBM. Kjejím hlavním principům patří:

. přizpůsobení procesu vývoje konkrétnímu projektu,
. vyvážení uživatelských požadavků ve vztahu k rozhodování o vývoji na míru/znovupoužití

komponent,
posílení spolupráce a komunikaci v týmu,
iterativní vývoj, zpětná vazba a snížení rizika nespokojenosti zákazníka,
zvýšení úrovně abstrakce (pro zjednodušení a zvýšení produktivity),
průběžný důraz na kvalitu.

Hlavním motivem firemní metodiky vývoje SW je snaha o co nejpřímější cestu od požadavků kfunkční
aplikací. Firemní metodika vývoje klade důraz na přípravu projektového rámce. Cílem projektového
rámce je zajistit stejný vzhled a ovládání aplikací, stejné řešení typových situací, využití
znovupoužitelných komponent, umožnit vývojovému týmu soustředit se na business logiku.

Metodika pracuje pouze se základními UML diagramy a snaží se o maximální přímost cesty od požadavků
k nasazení funkční aplikace.

Základní rámec metodikyje ilustrativně znázorněn následujícím obrázkem.

32
W? ČR - Cssz

ÚSTŘEDÍ

Křížová 25, 225 08 Praha 5

Požadavky Detallní
analýza
Design Implementace

“33:21:13 23323517 \\— Í Sg.—1:3;— unc"-
.š
QJ
Prototype
/ “arm" '

& —>š$—É .. _.%:

Pulu-"l mod-' Domain Hod-l annual Clan Model

=—

— ..—
..:—...

___—_—
Du!" haun-

Framework

Obrázek 10 —Základni rámec metodiky

3.2.2 Analytické výstupy

Vnásledujících kapitolách upřesníme metodický popis jednotlivých analytických modelů. Diagramy
budou vytvořeny podle standardu UML a BPMN. Příklady konkrétních výstupů jsou potom uvedeny
v kapitole 3.2.3 Příklady všech předpokládaných výstupů.

3.2.2.1 Katalog požadavků a jeho aktualizace
Kompletní katalog požadavků je základem pro společný výklad požadovaných funkčností mezi

dodavatelem a zákazníkem. Nekompletní seznam může být příčinou zvýšených nákladů při následných

změnách informačního systému, protože systém neplní očekávané funkce. Proto prvním krokem na cestě
k realizaci změnových požadavků informačního systému je kvalitně zpracovaný Katalog uživatelských
požadavků, který pomůže zajistit, že při rozvoji IKT budeme postupovat správným směrem, a že
vynaložené prostředky budou účelně využity k naplnění očekávání a potřeb zákazníka.

Definice změnových požadavků na aplikaci vychází zprocesního modelu a zidentifikace uživatelů a
zainteresovaných osob. Vsoučinnosti s Objednatelem budou zhlavních cílů procesu specifikovány
konkrétní požadavky na funkcionalitu SW řešení. Tyto požadavky budou formalízovány podle níže
popsané metodiky katalogu uživatelských požadavků. Požadavkům budou přiřazeny atributy, které
umožníjejich správu v průběhu vývoje systému. Příklad typických atributů požadavků:

. identifikátor,

. priorita,

. zdroj,

. komentář,

odhad pracnosti,

33
% ČR - ČSSZ
asmat

Křížová 25, 225 08 Praha 5

. status.OOOO

Do katalogu požadavků jsou zařazovány požadavky podle kategorizace FURPS+ (Functionality, Usability,
Reliability, Performance, Supportability, + Constraints, tj. funkční požadavky, požadavky na použitelnost,
spolehlivost, výkonnostní požadavky, požadavky na podporovatelnost a další omezení).

Základními vlastnostmi požadavků jsou:

jednoznačnost,
srozumitelnost,
úplnost,
konzistentce,
trasovatelnost,
požadavek neobsahuje návrh vlastního řešení.

Katalog požadavků bude primárním zdrojem pro ocenění pracnosti požadavků Zhotovitelem, jejich
prioritizaci Objednatelem a stanovení rozsahu jednotlivých dílčích plnění.

3.2.2.2 Konsolidace a ukotvení zadání (Návrh řešení)
Návrh řešení je změnový dokument pro požadavek/požadavky v rámci jednotlivých etap rozvoje aplikace.
Respektuje všechny ostatní pravidla pro tvorbu jednotlivých dokumentů a shrnuje dopad změn
požadavku do jednotlivých vrstev, modulů a procesu podporovaných aplikací.

Návrh řešení z pravidla obsahuje:

. identifikátor požadavku z Katalogu požadavků
. zadání- popis požadavku,
. popis současného stavu dotčených komponent a funkčnosti aplikace, tzn. výchozího stavu pro

realizaci požadavku,
. návrh řešení- cílového stavu aplikace, obsahuje zejména

o výčet dotčených případů užití a popis změn v těchto případech užití,
o výčet a detailní popis nových případů užití,
o popis změn uživatelského rozhraní — změny obrazovek, nové obrazovky, dopady do

screenflow,
změny datového modelu, zpravidla jeho rozšíření,
změny stavových diagramů sledovaných entit,
dopady do architektury aplikace,
změny rozhraní poskytovaných aplikací,
0 dopady na okolní aplikace
0 základní způsob ověřenífunkčnosti požadavku,
. požadavky na součinnost okolních aplikací, definice požadovaných změn okolních aplikací a jejich
rozhraní.

3.2.2.3 Ocenění pracnostijednotlivých požadavků
Na základě katalogu požadavků jako vstupu a analytických schůzek zástupců zhotovitele a příslušných
metodických a IT útvarů Objednatele kvyjasnění detailů a konsekvencí těchto požadavků dojde ke
konsolidaci a ukotvení zadání.

34
tw ČR — ČSSZ

ÚSTŘEDI

Křížová 25, 225 08 Praha 5

Na základě těchto zpřesněných informací provádí Zhotovitel ocenění pracnosti požadavků.

3.2.2.4 Návrh architektury jednotlivých úprav APV
Přístup zhotovitele ktomuto tématu je blíže specifikován dále vdokumentu v kapitole 3.3.1.2 Návrh
architektury.

3.2.2.5 Provedení analýzy požadavků a vytvoření detailního návrhu úprav APV
V rámci analýzy bude vytvořen detailní návrh úprav APV NEM, D_STAT včetně dopadů do aplikační i
databázové vrstvy. V závislosti na rozsahu požadavků a dopadů realizovaných úprav budou aktualizovány
příslušné dokumenty popisující procesní a funkční specifikaci, datovou architekturu, architekturu HW a
SW, rozhraní a integraci s okolními APV a systémy.

Procesní model
Procesní analýza je důležitou etapou při návrhu změn softwaru. Procesní analýza definuje jaké činnosti,
vjakém pořadí a sjakými vstupy/výstupy vykonávají uživatelé dotčeného systému a spolupracující
subjekty a systémy, aby dosáhli konkrétních měřitelných cílů. Kvalitně zpracovaný popis procesu je
základem pro společnou komunikaci všech stran, které se na průběhu procesu podílí, při identifikaci
problémů a hledání příležitostí pro zlepšováníjeho průběhu.

Stávající procesní diagramy budou aktualizovány a v případě nových procesů vytvořeny v notaci podle
standardu BPMN.

Popis procesu bude obsahovat:

název,
popis procesu,
cíl procesu,
vstupy,

výstupy,
sled jednotlivých činností a kdo je vykonává.

Popis jednotlivých činností bude zahrnovat:

název,
popis činnosti,
vstupy,

Výstupy,

očekávaná zátěž,
popis kroků nebo odkaz na detailní scénář funkčního požadavku.

Očekávaná zátěž bude důležitým podkladem pro specifikaci požadavků na výkonnost navrhovaných změn
systému.

Dále budou navrženy metriky a indikátory procesů, aby bylo možné procesy řídit a vyhodnocovat.

Kvalitně zpracovaný popis procesu je základem pro společnou komunikaci všech stran, které se na
průběhu procesu podílí, při identifikaci problémů a hledání příležitostí pro zlepšováníjeho průběhu.

35
W? ČR - Cssz

USTREDI

Křížová 25, 225 08 Praha 5

Popis procesu je důležitým vstupem pro stanovení funkčních požadavků pro informační podporu, kterou
má poskytnout tj. je to jeden z podkladů pro stanovení use case.

Funkční specifikace
Funkční specifikace bude udržována ve formě use case (případů užití). Případy užití jsou popisovány
diagramem sjednotlivými případy užití a každý případ užitíje pak podrobně popsán textovým scénářem.

Každý případ užití musí mít svou uživatelskou roli (tzv. aktora) Primární aktor (doporučeno vlevo od
případu užití) činnost v případu užití spouští. Sekundární aktor (doporučeno vpravo od případu užití) je
nezbytný pro úspěšné dokončení činnosti — sdílí potřebnou funkčnost a /nebo data. Každý případ užití má

jednoznačný identifikátor a stručný, ale výstižný název. Pro zvýšení přehlednosti popisu je vhodné

používat vazby typu:

. include pro případy užití, které jsou společné pro několik případů užití (nebo pro izolaci
specifických činností),

. extend pro činnost, kterou uživatel může, ale nemusí spouštět (nebo pro ošetření výjimečných
situací).

Ve fázi detailní analýzy jsou zpodrobňovány případy užití do úrovně popisu scénářů ve vazbě na prototyp
navržených obrazovek a na doménový model (logický datový model). Funkční specifikace je hlavním
zdrojem informací pro tvorbu testovacích scénářů, i pro pracovníka vytvářejícího uživatelskou
dokumentaci, protože popisuje způsob použití aplikace z hlediska uživatele.

Mis funkčního požadavku specifikovaného formou případu použití (use case) bude obsahovat:

. identifikátor případu použití,

0 název,

o odkaz na činnost procesního modelu, kterýje případem použití podporován,
. výchozí podmínky,

. aktor — uživatelská role nebo okolní systém, který zajišťuje splnění cíle a je za něj zodpovědný,
. cíl,

. základní scénář (seznam kroků),
. alternativní scénáře (seznam kroků),
. další nefunkční požadavky a omezení.
Funkční požadavky budou z důvodu přehlednosti a srozumitelnosti rozčleněny do logických skupin. Use
case model je podkladem pro konstrukci, přípravu testů a tvorbu uživatelské dokumentace.

Návrh obrazovek (drátěný model)
Návrh zahrnuje:

. drátěný model obrazovek (včetně html linků pro přechod mezi obrazovkami),
. diagram přechodů obrazovek (screen flow).

Na model případů použití bude navázán návrh obrazovek. Drátěný model schematicky definuje datové
položky na obrazovce a výčet ovládacích prvků, nikoli detailní grafický návrh obrazovky. Jeho účelem je
ověření, že obrazovka umožňuje splnění cílů činnosti use case, tzn., že obsahuje všechny potřebné údaje

36
% ČR - čssz

ÚSTŘEDI

Křížová 25, 225 08 Plaha 5

a ovládací prvky a že vše je rozmístěno logicky a vsouladu scílem use case, kterému (nebo kterým)

obrazovka slouží.

Prototyp obrazovek pro schválení zákazníkem je vytvářen co nejjednodušeji — v prvním kroku obvykle
pouze schematicky ve Wordu nebo jako jednoduché schematické html pomoci wireframe nástroje. Toto
schéma obrazovky definující obsah a rozvržení dat potom slouži (společně stzv. Grafickým manuálem)
jako zadání k programování.

Jedna funkčnost aplikace může vyžadovat práci postupně na více obrazovkách. V takovém případě je
nezbytné v průběhu návrhu popsat návaznosti obrazovek pomocí tlačítek (nebo jiných ovládacích prvků)
a přechodů mezi obrazovkami.

Datový model
Nejprve je vytvářen a dokumentován logický datový model, který popisuje co nejpodrobněji datovou
základnu aplikace, ale stále nezávisle na budoucím konkrétním implementačním prostředí.

Logický datový model obsahuje:

. přehled entit
0 název,
0 význam,

. diagramy entit a jejich vztahů
. přehled atributů entit

0 název atributu,
o význam,
o logický datový typ.

Logický datový model bude následně převeden na fyzický datový model, který přesně specifikuje
zakládací skript databáze (schématu) v konkrétnim databázovém prostředí. Pro generování DDL (data
definition language) lze použít generátorů ve zvoleném UML nástroji.

Fyzický datový model vznikne z logického datového modelu:

. normalizací vazeb mezi entitami,
. konverzí datových typů atributů na datové typy cílové databáze,
. tvorbou číselníků,
. doplněním constraints (primární a cizí klíče, doménové typy, obory hodnot, kaskádové akce, ...),
o definici indexů.
Fyzický datový model je popsán pomocí SQL DDL a pomocí class diagramu.

Stavy entit
Pro vybrané entity se složitým životním cyklem je vhodné vytvořit stavový diagram. | v tomto případě je
vhodné doplnit podrobnější popis s uvedením názvů případů užití na přechody mezi stavy (přechod mezi
stavy je vyvolán funkčností— prvkem chování).

37
w tR-Cssz
USTREDI

Křížová 25, 225 08 Praha 5

Stavový diagram je doplněn tabulkou uvádějící:

. název stavu,
. význam stavu,
. přechody do tohoto stavu ve vazbě na use case.

Specifikace rozhraní na okolní SW aplikace
Pokud má dodávané SW řešení (aplikace) komunikovat sjinými okolními SW aplikacemi, je nutné
specifikovat a popsat rozhraní na tyto aplikace. Služby jsou děleny na poskytované (kdy dodávané SW
řešení poskytuje data okolním aplikacím) a požadované (kdy z okolních aplikací jsou přenášena
požadovaná data — zde je obvyklé popsat, do jakých databázových tabulek dodávaného SW budou
přijímaná data zapisována). Pro každou službu jsou popsány její vstupní a výstupní parametry včetně
specifikace datových typů, příp. výjimky, které služba může vracet v případě vzniku chyby.

Popis zahrnuje (na logické úrovni):

0 název rozhraní,
. spolupracující systém,
. iniciátor,
. tok dat,
. vstupy

0 popisdatové struktury
' název prvku,

' popis,
' tYP,
. výstupy

o popis datové struktury
' název prvku,

' napis,
- typ.

Popis rozhraní na fyzické úrovni závisí na fyzické implementaci.

Transformace z logického rozhrani je podobná transformaci datového modelu:

. jednotlivé službyjsou pojmenovány na fyzické úrovni,
. vstupním a výstupním parametrům jsou přiřazeny fyzické datové typy.

Rozhraní na fyzické úrovnije popsáno pomocí WSDL.

Specifikace požadovaných tiskových výstupů
Obsahuje specifikaci navrhovaných tiskových výstupů a reportů. Tato speciﬁkace je vrámci rozvoje
aplikace aktualizována dle navrhovaných změn. Obsahuje obvykle:

» kód sestavy,
. účel,
0 pro koho je určeno,

38
W ČR - ČSSZ

ÚSTŘEDÍ

Křížová 25, 225 08 Praha 5

požadavky na data z okolních systémů,
přístupová práva,
periodicita,
popis sestavy,
výběrová kritéria

0 způsob třídění,
0 výstup,

I hlavička,
' tělo sestavy.

3.2.2.6 Analýza a návrh integrace dotčených APVa systémů do IS ČSSZ
APV NEM i D_STAT jsou existující aplikace, které jsou integrovány do IS ČSSZ. Pokud v rámci vývoje
nastane potřeba integrace s dalšími IS ČSSZ, bude tato integrace probíhat podle standardů ČSSZ.

3.2.2. 7 Příprava a popis testovacích scénářů pro jednotlivé typy testů
Téma je blíže vysvětleno dále v dokumentu zejména v kapitole 3.4 Testovací část.

3.2.3 Příklady všech předpokládaných výstupů

3.2.3.1 Příklady výstupů dokumentace požadavků
Všechny požadavky budou přehledně shrnuty do jediného seznamu. Výhodou tohoto seznamu je
možnost třídění — například podle priority.

Funkční požadavky (FUNxx) obsahuji hIavni požadavky na chování systému. Požadavky na data (DATxx)
popisují datová pole a jejich skupiny, které jsou potřebné pro podporu chování systému. Požadavky na
rozhraní (ROZxx) identifikují uživatelské role a externí systémy, které jsou nezbytné pro realizaci
požadovaného chování.

Příklad seznamu požadavků

ID Požadavek Autor Priorita Etapa
FUN01 1
Hromadný převod LPS na posudkového lékaře zákazník (1 nelvvššíl

Hromadný převod řeší situaci, kdy lékař 3
posudkové služby ukončí svoji činnost a jeho
případy LPS dostane jiný lékař. Na obrazovce
OBDZO Výběr případu uživatel využije záložku
LPS (zde zvolí posudkového lékaře). Systém
zobrazí obrazovku 08021Seznam případů, kde
bude možnost zvolit jednotlivé záznamy.
Obrazovka bude rozšířena o tlačítko
[Hromadný převodj. Po jeho stisku systém
zobrazí novou obrazovku, na které uživatel
vybere nového posudkového lékaře a tlačítkem
[Potvrdit] provede hromadný převod záznamů

39
IIII-IÍÍ-m W ČR-ČSSZ

ůsrlíEoI

Křížová 25, 225 08 Praha 5

LPS na nového posudkového lékaře.

DAT01 Sestava SEK12 — aktualizace PSČ zákazník 1 1

PSČ adresy vdobě pracovní neschopnosti je

použito pro vytipování kontrol léčebného

režimu práce neschopného. PSČ bude v NEM

vdohodnutých intervalech aktualizováno

2 kmenových evidencí.

R0201 Rozšíření rozhraní NEM-LOK zákazník 2 1

Výstup existující webové služby

NemPojistneDleZmeny bude rozšířen o nové

pole „Stav dávky". Systém předá údaje o

vybraných případech a dávkách NP do

lokálních aplikací (LOK).

Tabulka 1 - Příklad seznamu požadavků

3.2.3.2 Příklady konsolidace a ukotvení zadání (Návrh řešení)

Název požadavku: R0201 Rozšíření rozhraní NEM-LOK
Zadání

NEM předává LOK údaje 0 pracovních neschopnostech OSVČ přes webovou službu
NemPojistneDleZmeny. Na rozhraní budou provedeny tyto úpravy:
1. Jednotlivé 0552 budou dostávat data, která jsou jim určená. Toho bude dosaženo

nevyplněním vstupního pole „kodPracoviste". NEM vrátí LOK data za celou ČR. Přerozdělení
pracovních neschopností pro jednotlivé OSSZ se bude provádět na straně LOK.
2. LOK se dotazuje denně na pracovní neschopnosti do NEM. Bude dohodnut konkrétní čas,
kdy se bude LOK dotazovat. NEM zajistí, aby před tímto časem byla předpřipravena data
(max. 30 dní zpětně). Cílem je zrychlení komunikace NEM-LOK.
Popis současného stavu

Přenos dat zNEM do LOK probíhá denně. Komunikace mezi NEM a LOK je synchronní tj.
celková doba komunikace nesmí překročit 2 minuty. NEM při výběru dat používá složitý dotaz,
který (v závislosti na datech) může trvat déle, než komunikace umožňuje. Ztohoto důvodu

může docházet k tomu, že NEM ve stanoveném časovém intervalu nedokáže odpovědět.

Návrh řešení

LOK se bude existující webovou službou NemPojistneDleZmeny dotazovat NEM na pracovní
neschopnosti všech OSSZ za jeden den. NEM umožní na vstupu nevyplňovat pole

„kodPracoviste“ (pole bude nově nepovinné).

Základní způsob ověření požadavku

Ověřit, zda se výsledek dotazu bez zadání položky „kodPracoviste" rovná sumě dotazů za
jednotlivé OSSZ. Ověřeno bude dotazem do db.

40
% ČR - ČSSZ

asmat

Křížová 25, 225 08 Praha 5

K potvrzení

ČSSZ zajistí součinnost pro oblast LOK.

Tabulka 2 - Příklad konsolidace a ukotvení zadání

3.2.3.3 Příklady výstupů dokumentace pojmů

Následující tabulka znázorňuje hlavní pojmy týkající se řešené problematiky. Přesná definice pojmů a

jejich synonym je důležitá pro správné porozumění mezi zákazníkem a dodavatelem. Umožňuje správné

a jednotné pojmenování prvků uživatelského rozhraní a tím přispívá ke zlepšení ergonomie aplikace.

Katalog pojmů Popis Způsob evidence dat
Název

Případ pojištění Případ evidovaného výskytu sociální Evidovánojako entita.

Nárokové události nemocenského pojištění
podklady
Dávka (nemocenské, peněžitá pomoc

Výplata vmateřství, ošetřovné nebo vyrovnávací

příspěvek). Případ může být evidován i v

situaci kdy pojištěný žadatel nežádá o

dávku.

Rozšíření případu o nárokové podklady Evidovánojako entita.
(vyloučené dny, vyměřovací základ a jiné).

Žádost o dávku za určité období. Obsahuje Evidováno jako entita.
údaje nezbytné pro rozhodování o dávce
(Období od-do, příjemce dávky,
vypočtenou částku a jiné). Dávka se
vztahuje vždy kjednomu případu. K
případu může být evidováno nula až n
dávek.

Požadavek na výplatu dávky, obsahuje Evidovánojako entita.
datovou větu zasílanou do Výplat (VYP).

Tabulka 3 - Příklad definice pojmů

3.2.3.4 Příklady výstupů dokumentace procesů

Popis procesu pomáhá při identifikaci okolí systému (uživatelské role a exterm’ systémy). Při popisu

činností v procesu jsou postupně odhalovány základní pojmy.

Přehledný výčet procesů definovaných v rámci popisované oblasti je uveden v tabulce:

Čislo / kód Název procesu
procesu
NEMO3 Rozhodování o dávce a její výplata
Vyhledánídávky
NEM03.01

41
% ČR - ČSSZ
USTREDI

Křížová 25, 225 08 Praha 5

číslo I kód Název procesu
procesu
Rozhodnutí o dávce
NEM03.02 Založení dávky
NEM03.03 Aprobace
NEM03.04 Uvolnění k výplatě
NEM03.05 Zastavení výplaty
NEM03.06 Spouštění generování dávek PPM
NEM03.08 Generování dávek PPM
NEM03.09 Kontrola generování
NEM03.10 Kontrola procesu rozhodování a výplaty dávek
NEM03.11 Zpracování informací o stavu výplaty
NEM03.12
Tabulka 4 - Příklad seznamu procesů

Procesní model bude znázorněn procesním diagramem v notaci BPMN, která je uznávaným standardem
pro procesní modelování. U jednotlivých činností budou znázorněny vstupy a výstupy.

“pro
"nhl

513 S čím? Winf—.
Hmm k VM .

uvozen-.

Obrázek 11 - Příklad diagramu procesu (NEM03 Rozhodování o dávce a její výplata)
42
% ČR - ČSSZ

[ISTREDI

Křížová 25, 225 08 Praha 5

Příklad popisu procesu (NEM03 Rozhodování o dávce a její výplata)
POPIS PROCESU
Název: Rozhodování o dávce a její výplata

Proces je iniciován vznikem dávky. Ta vzniká automaticky při zpracování dokumentu v INNP, VIZ činnost NEM01.01
Zpracování dokumentu.

Referent provádí rozhodnutí o dávce. Referent může dávku předat k řešení jine'mu referentovi nebo na jiné pracoviště.
V případě neúplných podkladů referent označí za došetřovanou a v rozhodnutí pokračuje až po doplněni podkladů.

Navazuje Aprobace. Aprobant může zamítnout rozhodnutí referenta a vrátit dávku referentovi, aprobant však nemůže
jakkoli dávku měnit.

Dávka vzniká automaticky zpracováním dokumentu z INNP.
Výplata je automaticky založena uvolněním dávky k výplatě systém.

Odbor ABC

.„ ;1 _ ..“
dix-W

Rozhodnutí o dávce, výplata dávky na základě žádosti o dávku
Kvalitativní parametry produktu a měřitelné ukazatele kvality a výkonu procesu
Kvalitativní parametry produktu:

. Je evidována dávka, je předána k výplatě nebo je vydáno zamítavého rozhodnuti informující žadatele.
Měřitelné ukazatele kvality a výkonu procesu:

I Doba vyřízení žádostí

0 Počet zpracovaných žádostí

0 Počet přiznaných dávek

- Procentní podíl došetřovaných žádostí

0 Doba došetření žádosti

. Procentní podíl žádostí které aprobant neschválil

we 1:; .

Typ podnětu:

. Žádost o dávku
. Vratka dávky
- Odmítnutí požadavku výplaty
. Informace o stavu výplaty
Předpokládané počty:
. cca 15 mil. dávek ročně
Termín pro zpracování:

43
W ČR-ČSSZ

ÚSTŘEDI

Křížová 25, 225 08 Praha 5

POPIS PROCESU
Název: Rozhodování o dávce a její výplata

jg... Wmmw „

vw Výstupů=

. Rozhodnutí o dávce
. Výplata dávky
Předpokládané počty:
. Odpovídají vstupům

SCI—il

03.01 Vyhledání dávky
03.02 Rozhodnutíodávce
03.03 Založení dávky
03.04 Aprobace
03.05 Uvolněníkvýplatě
03.06 Zastavení výplaty
03.08 Spuštění generování dávek PPM
03.09 Generování dávek PPM
03.10 Kontrola generování
03.11 Kontrola procesu rozhodování a výplaty dávek
03.12 Zpracování informací o stavu výplaty

Tabulka 5 - Příklad popisu procesu (NEM03 Rozhodování o dávce a jeji výplata)

Jednotlivé subprocesy a činnosti jsou dále podrobněji specifikovány formou karty:

POPIS SUBPROCESU

Název: Aprobace

w, . “32.4. w. uš

Aprobant provádí aprobací dávek, o kterých rozhodl referent. Může potvrdit nebo zamítnout rozhodnutí referenta, nemůže

však dávku jakkoliv ménit.

Subproces zahrnuje i aprobací vzniklého přeplatku (vzniká v procesu NEM04) a exekuce (vzniká v procesu NEMOS).

44
W ČR - Cssz

ÚSTŘEDI

Křížová 25, 225 08 Praha 5

POPIS SUBPROCESU

Název: Aprobace

Pokud je aprobován přeplatek a jedná se o odejmutí dávky, tj. částka dávky, ke které byl evidován přeplatek je shodná
s částkou přeplatku, provádí se informování oblasti POJ o odejmutí dávky. Informování je prováděno automaticky při
každé aprobaci takovéhoto přeplatku.

2s- ' .a,

Dávka k uvolnění, aprobovaný přeplatek, exekuce

Kvalitativní parametry produktu a měřitelné ukazatele kvality a výkonu subprocesu
Kvalitativní parametry produktu:

' Je evidována dávka, je předána k výplatě nebo je vydáno zamítavého rozhodnutí informující žadatele.
Měřitelné ukazatele kvality a výkonu procesu:

0 Doba vyřízení žádosti

. Procentní podíl žádostí které aprobant neschválil

Typy doldadu a datových vstupů:
. Dávka k aprobací

Předpokládané počty:
. 15 mil dávek ročně

Termín pro zpracování:
Zákonná lhůta není definována, požadavek na maximální aktuálnost předpoklad spouštění 3x denně

Typy dokladů a datových výstupů:
. Dávka k výplatě

Předpokládané počty:
. Odpovídajívatupům

m- . .. . ......an

Odbor ABC

03.05.01 Vyhledaní dávky

03.05.02 Kontrola aprobované dávky

03.05.03 Zamítnutí

03.05.04 Potvrzení

03.05.05 Aprobace exekuce

03.05.06 Aprobace přeplatku

Tabulka 6 - Příklad popisu činnosti/subprocesu

45
W ČR-ČSSZ
Usrktnt

Křížová 25, 225 08 Praha 5

3.2.3.5 Příklady výstupů dokumentace případů užití
Funkční modul sdružuje funkční požadavky spolu související, často podporující stejný proces nebo
subproces.

Případy užití podrobně popisují interakci mezi systémem (externími systémy) a uživatelem. Popis případu
užití se odkazuje na entity a atributy logického datového modelu -je popsán na uživatelské úrovni —
jazykem uživatele (nejde o technický popis poplatný technologii realizace). Každý případ užití popisuje

jednu uživatelskou transakci — řadu kroků, která je již z hlediska práce uživatele dále nedělitelná (na

jednotlivé případy užití).

Číslo Název Související procesy

06 Aprobace NEM03 Rozhodování o dávce a

její výplata

Tabulka 7 — Příklad seznamu modulů

Logický modul 06 Aprobace

Číslo Název Souvisejíci činnost procesu

PP06.01 Kontrola aprobované Proces: NEM03 Rozhodování o dávce jeji
dávky výplata.

PP06.01.0 Potvrzeníaprobantem Subproces: NEM03.04 Aprobace.
1
Proces: NEM03 Rozhodování o dávce její
výplata.

PP06.01.0 Zamítnutíaprobantem Subproces: NEM03.04 Aprobace.
2
Proces: NEM03 Rozhodování o dávce její
výplata.

PP06.01.0 Aprobace přeplatku Subproces: NEM03.04 Aprobace.
3
Proces: NEM03 Rozhodování o dávce její
výplata.

PP06.01.0 Aprobace exekuce Subproces: NEM03.04 Aprobace.
4 Proces: NEM03 Rozhodování o dávce její
výplata.

Subproces: NEM03.04 Aprobace.

PP05.02.0 Vyhledání dávky pro Proces: NEM03 Rozhodování o dávce její

2 aprobaci výplata.

PP06.02 Storno aprobace Subproces: NEM03.04 Aprobace.
Proces: NEM03 Rozhodování o dávce její
výplata.

Subproces: NEM03.05 Uvolnění k výplatě.
Tabulka 8 - Seznam případů užití v modulu 06 Aprobace

46
W ČR - ČSSZ

ÚSTŘEDI

Křížová 25, 225 08 Praha 5

00.01 Kontrol- aprobmně divky —_—— 00.01.01 Potvrzení aprobantem

‘ — -«gdend»

\\\ \ —_

75E \ \ \ \ \ «extend» * —

„mb-"t \ \ \ \ «extend» 06.01.02 ernítnutíaprobmtcm

% \\ \

Vedouc \ \ \\

\ \ \«extend» \ \

\ \ \
\

\ \

\ \ \ osm ”Apron-ca přeplatku

00.02 Storno aprobace \
,\
cinclude»\ \
\
\ \
\

\ 06 01 04 Apron-cc exekuce

\
\
\
\

Obrázek 12 - Příklad diagramu případů užití (Aprobace)

Příklad popisu případu užití
PP 06.01 Kontrola aprobované dávky

Uživatel zkontroluje dávku, nemůže však žádný údaj změnit. V rámci kontroly dávky ověří Excelový výstup připravený
Referentem DNP, obsahující detailní údaje o výpočtu dávky (viz PP 05.03).
Aprobant může pouze potvrdit (PP06.01.01) nebo zamítnout rozhodnutí referenta o dávce (PP06.01.02), ktomu může doplnit
vysvětlující poznámku. V případě zamítnutí rozhodnutí se dávka vrací referentovi, v případě potvrzení je dávka připravena pro
uvolnění k výplatě. O změně stavu dávky informuje služba
Pokud referent rozhodl tak, že žádost o dávku zamítl tj. schválená částka je nulová a aprobant toto rozhodnutí potvrdí, potom
dávka zůstane ve stavu Neproplácí se. APV NEM v tomto případě nepodporuje zaslání vysvětlujícího dopisu žadateli.

Uživatel vyhledá dávku k aprobaci viz PP05.02.02.
Zobrazí obrazovku Dávka — Stav dávky.

47
ČR - ČSSZ

Křížová 25, 225 08 Praha 5
2_ PP006.01.1 Potvrzení aprobantem

Uživatel zvolí [Potvrdlt rozhodnutíl
3. Systém zobrazí obrazovku pro zápisu komentáře řešitele tj. Aprobanta

Potvrdlt rozhodnu
Poměr-da řešitele

4. Uživatel může zapsat poznámku a vložené údaje potvrdí [Odeslat]
O změně stavu dávky informuje služba

5. Systém zméni stav dávky na Potvrzeno aprobantem a zobrazí obrazovku Dávka — Stav dávky, na které je vidět kdo a
kdy aproboval dávku.
Dále pokračuje zpracováni dávky v logickém modulu 07 Výplata a to uvolněním k výplatě.

PP06.01.02 Zamítnutí aprobantem
Uživatel zvolí [Zamítnout rozhodnutíl a doplní komentář se zdůvodněním, potom systém změní stav dávky
Zamítnuto aprobantem a dávka je vrácena znovu k rozhodnutí referentem DNP.
O změně stavu procesu dávky informuje služba:

kud nelze provést aprobaci dávky, zkontrolujte, zda přihlášený uživatel je jiný než uživatel který provedl rozhodnutí o dávce.

„„ __ u..> »

Tabulka 9 - Příklad popisu případu užití

3.2.3.6 Příklady výstupů dokumentace logického datového modelu
Logický datový model popisuje datovou strukturu aplikace na uživatelské úrovni — jazykem uživatele
(nejde o technický popis poplatný technologii realizace). Tento model slouží k ověření úplnosti datových
struktur a k ověření správnosti vazeb mezi těmito strukturami. Používá se při popisu funkčnosti aplikace v
případech užití (i ty jsou popsány na uživatelské úrovni — jazykem uživatele (nejde o technický popis
poplatný technologii realizace).

48
W ČR - Cssz

05mm

Křížová 25, 225 08 Praha 5

na:-o- mull-om”

W
Quantum”

-m¢uihm:&atas_moox

n.-

1 o- u mm
* nivu .mmmwm:mwumxu
wan-m:“
" WM:!— a

mmm .

.r M:!maymm

&“"
dot”

on» mun

m : mm

Gali—AW “rmutu—h

luh: čini-

&'.:

.mwmunyzeummsm

autama.-ius nom

among-hehe

.wumnm;w

w os osminy mm“.

Šaman—a' má“ „mm:MUSJWVAWVKY

“hymnou-Mun- \ 0‘

-vadebiFN mm .WM:Mo$_zAvmm Ill-In
mnu-uluumm on“ .
mmmumm :Dnun avant-mcéufaouvmr “M..“llmůím
www-u 'i- h_

awry
k ' ili Wolni na k výplní
vyp

VYP

mms VY Gavi" m7 06 VYF Naval k
vyplnil! diw výplní

Odmítnuh Převzal: k výplatě

po uplynul! czsonho :ﬁt'mv‘I-ﬁ: “- “kl Storno vratky
mu doncuje \
H117.“ VYF pot-tra
. mmm/iní požadavk: k FN7DB
výplň Smrno
vraky

Obrázek 14 - Příklad diagramu stavů entity (Dávka)

Příklad popisu stavů entity (Dávka)

Stav Popis
Evidována Dávka je evidována, referent dosud nerozhodl
Došetřována Referent odložil rozhodnutí o dávce, probíhá došetřova'ní
W ČR - Cssz
ÚSTŘEDI

Křížová 25, 225 08 Praha 5

Referent rozhodl Referent rozhodl, dávka je určena Aprobantovi ke schválení
rozhodnutí

Rozhodnutí Aprobant potvrdil, dávka je připravena k uvolnění do WP.
potvrzeno

aprobantem

Storno aprobace Vedoucí provedl storno potvrzení aprobanta.

Rozhodnutí Aprobant zamítl, referent musí znovu rozhodnout podle pokyny

zamítnuto aprobanta.

aprobantem

Nevyplácí se Aprobant potvrdil dávku, částka dávka je nulová, dávka se
nevyplácí.

Souběh Dávka v souběhu, je vyplácena v rámci souběžné dávky
Uvolněna k výplatě Dávka odeslána do WP, WPještě nepotvrdil její přijetí
Stornována Referent stomoval dávku.

Zneplatněna Referent zneplatnil dávku založenou omylem

Převzata k výplatě WP potvrdil přejetí dávky.

Odmítnuta Požadavek na výplatu dávky byl odmítnut WP, referent musi
znovu rozhodnout (např. opravit adresu)

Vratka WP zaslal informaci o vratce (dávku nebylo možné doručit),
referent musí znovu rozhodnout (např. opravit adresu)

Storno vratky Referent WP stomoval vratku.
Tabulka 12 - Příklad popisu stavů entity (Dávka)

3.2.3.8 Příklady výstupů dokumentace obrazovky

K dokumentaci stávajících obrazovek jsou použity otisky obrazovek a popis jednotlivých polí. Při návrhu
nové obrazovky zákazník obdrží navrhované rozmístění datových polí, popis jednotlivých polí na
obrazovce. Výsledný vzhled obrazovky bude v souladu s grafickým manuálem ČSSZ.

Dávka

iomnm: m Gisow: v 0900000374 \ bm? Amago:

m » _mu wm: _ mm.: _

can divky: mm:-m sm: mdo—ina 35:33: 25.2009 - mmm
my“ as
WM: 99999900000005 \ mm: nada maminku: m.zono

mc mm "m' mum doručení: 23.0.2009

Obrázek 15 - Příklad dokumentace obrazovek (OBD12 Dávka - hlavička obrazovky)

52
% ČR - ČSSZ

ÚSTŘEDI

Křížová 25, 225 08 Praha 5

Druh dáVkY možností:!nemocenské, ošetřovně, peněžitá pomoc v mateřství, vyrovnávací

příspěvek v těhotenství a mateřství)

Číslo případu číslo případu

Ikona [Detail připadal zobrazí detail případu (obrazovka OBDll-Případ)

ČPN číslo pracovní neschopnosti

Účastník sekce (Trtul, Jméno Přijmení, Titul zajménem, R/N)

Přijmení jméno účastníka
Jméno příjmení účastníka
Rodné čislo/ECP rodné čislo/evidenční číslo pojištěni účastníka

Trvalá adresa Sekceru1ice.č.p..Psč,0beq5tát)

Číslo dávky číslo dávky

Stav stav dávky
Výplata za období od výplata za období od a do
Podpůrči doba započteno započítaná délka podpůrčí doby

Druh dokladu možnosti:(dávka, přeplatek, doplatek)

Datum vzniku datum vzniku případu

Žádost číslo intemí čislo žádosti

(nezobrazuje se na dávkách, které byly vytvořeny ručně referentem, nebo
vygenerovaný systémem)

lkona [Detail dokumentu] zobrazí detail dokumentu (obrazovka OBDOS-Dokument)
(nezobrazuje se na dávkám, které byly vytvořeny ručně referentem, nebo
vygenerovány systémem)

Typ typ dokumentu zakládající nárok na dávku

(nezobrazuje se na dávkách, které byly vytvořeny ručně referentem, nebo
vygenerovány systémem)

Datum doručení datum doručení dokumentu
(nezobrazuje se na dávkách, které byly vytvořeny ručně referentem, nebo
vygenerovaný systémem)
Tabulka 13 - Příklad popisu obrazovek (OBD12 Dávka — hlavička obrazovky)

3.2.3.9 Příklady výstupů dokumentace tiskového výstupu
Uvedený příklad tiskového výstupu obsahuje tabulky se strukturovaným textem popisu a šablonu vzoru
dokumentu. Součástí dokumentace je fyzické mapování na zdroj dat.

53
W CR-Cssz
USTREDI

Křížová 25, 225 08 Praha 5

TISKOVÁ SESTAVA
SEDOZ Seznam DNP pro vnější kontrolní činnost

SEDOZ

Sestava slouží jako přehled případů sociálních událostí za jednotlivé pojištěnce zadaného zaměstnavatele v
zadávaném časovém období, je podkladem pro kontrolní činnost.
Sestava je určena pro kontrolní odbor na ústředí ČSSZ.
KE — Vyhledání osoby

Referent DNP (NEM_Z), Aprobant (NEM_3), Vedoucí pracovník (NEM_4)
Na vyžádání
Tiskové sestavy / Sestavy dávek
Záložka Sestava SEDOZ — obsahuje seznam sociálních událostí, ke každé události jsou připojeny
informace o nárokových podkladech (pokud jsou v systému).

wam'nh-1'4”";va

Normanem mm m nun-unum) mmm

"M"""“ maurus-l

W“ " jen

mm L „ ,;jom

1. Období od — DD.MM.RRRR, nepovinný údaj- počáteční datum pro výběr případů za zvolené časové
54
W ČR - ČSSZ

asmat

Křížová 25, 225 08 Praha 5

období
2. Období do — DD.MM.RRRR, nepovinný údaj- konečné datum pro výběr případů za zvolené časové
období. (Poznámka: při nevyplněném poli "Období do" bude vložen do tohoto pole plus jeden rok od
hodnoty pole "Období od").
3. Zaměstnavatel (dle VS ) -vyh|edávací pole, nepovinný údaj (uživatel where
' zaměstnavatele dle VS mzdové účtárny)
4. Osoba - vyhledávací pole, nepovinný údaj (uživatel vybere osobu )
Výchozí třídění:
Číslo případu

Stiksia rozdělena do záložek
Sestava SEDOZ
Hlavička:
- Variabilní symbol — zadáno na vstupní obrazovce
- Název zaměstnavatele — zadáno na vstupní obrazovce
- Sídlo zaměstnavatele - zadáno na vstupní obrazovce
Tělo sestavy:
- Tabulka:

RČ

Příjmení a jméno
Případ od
Případ do
Počet dnů DPN
Úhrn vyměřovacích základů

další položky
SED02_sqI.doc

Tabulka 14 - Příklad tiskového výstupu

3.2.3.10 Příklady výstupů dokumentace rozhraní
Popis rozhraní je členěn podle externích systémů. Pro každý systém je uveden seznam služeb. U každé
službyje dokumentován seznam vstupních a výstupních parametrů.

F‘“
W ČR - ČSSZ

ÚSTŘEDI

Křížová 25, 225 08 Plaha 5

Název rozhraní: Rozhraní NEM-INS

Služby iniciované systémem NEM do systému INS.

Název služby Význam služby

Informování 0 Oblast NEM na vyžádání inicializuje službu, která na základě OID
příznaku pojištěnce (resp. seznamu OID pojištěnců) vrátí informaci o příznaku
Insolvence (resp. seznam příznaků).
Tabulka 15 - Příklad seznamu služeb rozhraní

Vstupní parametry

vstup

Název [ Popis lm

Seznam:

OID pojištěnce | Jednoznačný identifikátor pojištěnce [ OID

Tabulka 16 - Příklad seznamu vstupních parametrů služby (Informování o příznaku)

Výstupní parametry
Služba vrací seznam OID pojištěnce a jeho aktuální příznak insolvence.

Výstup

Název Panis TVP

Seznam:

OID pojištěnce Jednoznačný identifikátor pojištěnce OID
Příznak dle OID
Příznak pro dané OID. Může být hodnota: Řetězec
NENI — osoba v INS existuje, ale nemá aktivní ins. řízení,

PROBIHA- osoba v INS existuje a má aktivní ins. řízení,

NEUVE — osoba v INS neexistuje,

NOTAVAlLABLE — rozhraní INS není dostupné,

DISABLED - rozhrani INS vrátilo kód, který NEM neumí
interpretovat
Tabulka 17 - Příklad seznamu výstupních parametrů služby (Informování o příznaku)

3.2.3.11 Příklady výstupů dokumentace fyzického datového modelu
Dokumentace fyzického datového modelu slouží ke generaci databázového schématu pro uložení dat
aplikace. Jmenné konvence a datové typy odpovídají standardu ČSSZ.

56
W ČR - ČSSZ

USTREDI

Křížová 25, 225 08 Praha 5

P01PRPAD TAB
mum W15

DMM mm
mom VAN-WW) (ISM)

”‘5‘" ,_ 3%me

WAVIN: Mm

_ Lawmxgmmywa i ]

Obrázek 16 - Příklad diagramu fyzického datového modelu

CREATE TABLE DO1DAVKA_TAB (

|D_PRIJEMCE NUMBER(15) NULL,

|D_DO1DAVKA NUMBER(15) NOT NULL,

PORADI_DAVKY VARCHAR2(3) NOT NULL,

CASTKA NUMBER(12,2) NOT NULL,

DAVKA_OD DATE NULL,
PORADIDNE NUMBER(4,0) NULL,

SUMA_SOUBEH NUMBER(12,2) NOT NULL,

DAVKA_DO DATE NULL.

KOD_SPLATNOST VARCHAR2(18) NULL,

PROCENTOKRACENI NUMBER(3) NULL,

|D_SPOJEN|__KE NUMBER(15) NULL,

KOD_ZPUSPLAT VARCHAR2(5) NULL,

DAT_UKON DATE NULL,

KOD_TYPUCAST VARCHAR2(5) NULL,

57
% 9-an
máma

xmwoš Nm. mmm cm 1.15 u.

xoolšmz> <>mox>x~§ ch
xooušmz>|<<3 <>mox>x~§ ch.

xoolmdﬂc <>moz>m~§ zc_._._

o>m4x>|mx>Nmzo zcšmmxcpe ch.

uoIrN>< <>moz>m~3 zc_._._

ax> zcgmme ch

XOU|N><_ZmZ_ <>WOI>xNA$ ZCF.

XOU|._.<_u_u_»m_ur>._. <>NOI>NN8V ZCE..

_uONZ <>mOI>mN3009 ZCCJ

_Ul_uo.:u_»:u>_u ZCmemﬁmv 20... ZCF.

O>._.C_uU U>4m ZO.—. ZC_._.._

XOOIUICIUOX.. <>m01>x~§ ZCrF

>C4CUU <>xOI>mN3 : ZO.—. ZC_._._

_U|_u_»00mmC|<<_u <>WOI>NNÍS ZCrr.

<<_uOO|O>m._.X> zcšmeSNNv 204. ZCF.

_U|_oa UOXCŠmZ... Zcšwmmúmv ZCrF

.uOH_4 zcgwmmﬁv ZCrr.

„_mIZbŽO—A Zcšwmžc Umm>Cr4 a ZCEJ

_uONZIUCrmN_._.> ZCšmeSV ZCF.

0>mHX>IUmUOZO<>ZO zcšmeGNNVZCE..

XOUIM4>m4ŠIXšOmZ_ zcšmmmšmbv ZCE..

N>O>._.m_A|N_ux>OO<>Z_ U>._.m ZCE.

mm
W ČR - Cssz

ÚSTŘEDÍ

Křížová 25, 225 08 Praha 5

z minu maul 301 mu
v, >.. '$ .. . ...-

hm».- '

Knut.. Q&Q-n “u_om

mu’vl ‘ll AL 41 Juluíl Jul ..: uv . * 1.3K i tun-.Lu-nl-r Úv-

F7 '$ _3 :- _ _: '$ _ ,) 'a . ___: k 3* J h _ J:; A, a :. E: „:
„mam my»: ' Max-u '
m5)»; ' «any! ' mama : mu“

Ruti vin 0
mm, MM..: m an.“ u_n-„' cun-.
1.01.4:me m... ...—mi . «an v; .“
mw

Jul): q mm_... :—"_u‘ hr_dudnxJ "

Obrázek 17 - Příklady výstupů dokumentace ETL procesu (APV D_STAT)

59
% ČR _ Cssz

ÚSTŘEDI

Křížová 25, 225 08 Praha 5

3.2.3.13 Příklady výstupů dokumentace návrhů uživatelského rozhraní QIíkview (APVD_STA T)

„ \ WM —n <> m I,‘ .. ...a-|

'nuumwmwwuwm—u _ax

ua‘rmqma m- .0 a anga 99p] un- Iquow amu—ml
"1.121.351ILWMEIJIULYJHKA'SUM‘@°‘\“’K1§-H33A+WUW"'f“ taxace

uk Worm-v1 nut-$0019 zm- zszv \

u ln zadání
výběrových kritérii
mu Í
V
u In
p re n os
Mx An D Io
dělicí čára
n

'mn>=n aaa

(n3
('n
(17

„„ primas nLASTAVENI

am n..—mm wan ml! *'H'

zimu-u hm ale! , '

u. „'"—" om nun: va..— - cnd—u nun-u 1m '
nu 1 mnoh-
mmm xm
unu-. AIM

Em Ans

20” I'm A39 Mb 0—17 luhu——

| In“.
\ *"
zon Lau-u an M 049 | m
__
mnm Aun ru, cm I ::
'
zon Luann. m hny EH9 1

\ minim mý nit , mg :

hump-m , „ _- , _

“mm-ta! nvm nm .

Obrázek 18 - Příklady výstupů dokumentace návrhů uživatelského rozhraní Qlikview (APV D_STAT)

60
W ČR - ČSSZ

ÚSTŘEDI

Křížová 25, 225 08 Praha 5

3.3 Vývojová část

Závazné podmínky:

V rámci vývojové části projektu Zhotovitel zajistí:

Okomentovaný programový kód požadovaných změn, se zapracováním požadovaných úprav ve
zdrojových kódech příslušných APV (aplikační i databázová vrstva);
Řízení a koordinace participace dotčených a souvisejících týmů a aplikací;
Proces vývoje a přípravy nasazení, vytvoření instalačních balíčků pro cílovou platformu;
Instalační skripty;
Návrh úpravy konfigurace veškerého částí dodávky;
Zapracování změn v technické/programátorské dokumentaci (případně vytvoření);
Zapracování změn v uživatelské dokumentaci (pokud existuje);
Poskytovat případné konzultace návrhu řešení na úrovni, architektury procesů odborných agend,
analýzy, designu, implementace, integrace a testování;
Zajištění a správa vývojového prostředí;
V případě potřeby provedení revize zdrojových aplikačních (programových) a databázových
kódů.

Zhotovitel předloží závazný popis plnění dle výše uvedeného.

Zhotovitel minimálně popíše:

Metodiku vývoje;
Metodiku přípravy nasazovacích balíčků případně používané nástroje;
Příklady předpokládaných výstupů.

(doplní Zhotovitel) - Zhotovitel doplnil, viz kapitoly níže.

3.3.1 Metodika softwarového vývoje
Metodika vývoje softwaru, kterou dlouhodobě používáme, vychází zklasických a široce rozšířených
metodik, mezi něž patří zejména Rational Unified Process (RUP), V—Model, agilní techniky (Scrum) popř.
další. Metodika je založena na těchto základních principech:

Životní cyklus vývoje softwaru se skládá zanalýzy požadavků, návrhu architektury, detailního
návrhu implementace požadavků, vlastního programování a několika úrovní testování —
programátorské, funkční, integrační (příp. další typyjako zátěžové, bezpečnostní atd. dle potřeby
daného projektu). Navazujícími činnostmi, které již stojí mimo vlastní softwarový vývoj, jsou
tvorba dokumentace, školení uživatelů a administrátorů, příprava pilotního prostředí.

61
ČR - ČSSZ

Křížová 25, 225 08 Praha 5

. Vývoj kompletního díla je rozdělen do dílčích časových úseků, typicky ve dvou úrovních — delších
etap/fází (typicky o délce nékolik měsíců) a kratších iterací/sprintů (typicky 1-2 týdny). Toto
rozdělení napomáhá efektivnímu plánování a řízení projektu softwarového vývoje. Je rovněž
základem pro včasné získání zpětné vazby k vytvářenému dílu.

. Testování je rozděleno do několika úrovní a je snahou získat ověření a zpětnou vazbu
k vytvořeným funkcionalitám s co nejmenším zpožděním po té, cojsou naprogramovány.

Vdalším textu budou podrobněji popsány jednotlivé aspekty vývoje softwaru. Jedná se o metodický
rámec, kterýje pro každý projekt v konkrétních detailech přizpůsoben specifikům daného projektu.

Obecně platí, že metodika vývoje použitá vrámci dodávek pro ČSSZ bude vsouladu se všemi
relevantními standardy v tomto prostředí, případně s obecně uznávanými standardy:

. „Standard metodiky vývoje"
. „Java Code Conventions" vydané firmou Sun Microsystems (Oracle)

3.3.1.1 Analýza požadavků
Tato část je součástí analytického návrhu systému a je popsána vkapitole Katalog uživatelských
požadavků.

3.3.1.2 Návrh architektury
Nefunkcíonální požadavkyjsou vstupem zejména do návrhu systémové a aplikační architektury, protože
určují použité technologie a průřezové vlastnosti a mechanizmy, které ovlivňují všechny či většinu částí
vytvářeného softwaru. Patří sem standardně požadavky z oblasti bezpečnosti, společných rysů
uživatelských a datových rozhraní, podpory pro provoz a monitoring aplikací (konfigurace, logování,
audit, správa chyb), způsobu nasazení, zajištění škálovatelnosti a vysoké dostupnosti, volby použitých
technologií atd. Do oblasti aplikační architektury lze zařadit i definování pravidel tvorby kódu, jejichž
cílem je zajistit kvalitně napsaný zdrojový kód.

Významná část návrhu architektury se provádí v počátečních fázích vývoje (zejména stanovení celkového
rámce a všeobecně používaných principů a mechanizmů), nicméně není snahou vyřešit na počátku vše
do posledního detailu. Aplikační architektura se doplňuje a upřesňuje v průběhu vývoje s ohledem na to,
která část vytvářeného softwaru se právě implementuje, a rovněž s přihlédnutím ke zkušenostem, které

tým získal v průběhu dosavadní realizace. Na návrhu architektury se typicky podílí specializovaný

softwarový architekt ve spolupráci svedoucím programátorem, popř. u větších projektů s dalšími
seniorními členy programátorského týmu.

3.3.1.3 Detailní návrh
Pro jednotlivé funkcionální požadavky postupně (s ohledem na jejich naplánování do programování a
celkový harmonogram projektu) vzniká detailní návrh realizace. Patří sem aktivity voblasti detailního
návrhu uživatelského rozhraní, detailní specifikace datových rozhraní (poskytovaných, využívaných),
návrhu datového modelu použitého pro uložení dat, specifikace aplikačních algoritmů a způsoby
výpočtů, návrhu kontroly vstupů atd. Detailní návrh realizace standardně provádějí analytici, příp. ve
spolupráci se seniorními programátory.

62
% ČR - ČSSZ

ÚSTŘEDÍ

Křížová 25, 225 08 Praha 5

Některé části detailního návrhu mohou být řešeny interně v rámci týmu Zhotovitele, některé části ovšem
musí být diskutovány a schvalovány ze strany Objednatele (např. návrhy uživatelského rozhraní) popř. i
třetích stran, typicky realizátorů / provozovatelů okolních systémů, se kterými vytvářený software
komunikuje (specifikace datových rozhraní).

3.3.1.4 Programování

Vlastní programování probíhá vkrátkých iteracích, typicky o délce 1-2 týdny. Každá iterace začíná
výběrem požadavků, které budou v dané iteraci zrealizovány. Pořadí realizace požadavků vychází jednak
zdefinovaného seznamu funkčních požadavků, kde je zohledněna logická návaznost jednotlivých
funkcionalit, jednak ztechnologických potřeb vývoje. Typicky se velká část vývoje v prvních iteracích
soustředí na vytvoření základního rámce vytvářeného softwaru a implementaci průřezových
mechanizmů.

Naplánování požadavků do iterace se provádí společně vcelém týmu, přičemž tvůrci požadavků (u
funkčních požadavků typicky analytici), vysvětlují zadání požadavků a v celém týmu probíhá diskuze o
způsobu řešení požadavků a dopadech do jednotlivých částí softwaru. Pro vybrané požadavky jsou
definovány dílčí programátorské úkoly, které jsou rozděleny mezi jednotlivé programátory. Pro každý
úkol je určen hlavní programátor.

Vprůběhu iterace programátoři realizují jednotlivé úkoly scílem dokončit vdané iteraci naplánované
požadavky. Průběžně probíhá intenzivní komunikace mezi programátory a analytiky scílem vyjasnit a
upřesnitjednotlivé aspekty realizovaných požadavků. Na práci jednotlivých programátorů dohlíží vedoucí
programátor, který ověřuje, zda způsob realizaci odpovídá celkové koncepci vytvářeného softwaru, zda
se dodržují definovaná pravidla tvorby kódu, pomáhá při řešení nejasností a sleduje postup
programování s ohledem na plán dané iterace. Programátoři průběžně vykazují čas strávený na realizaci
úkolů. Tyto informace vztažené k definované velikosti (náročnosti) požadavků pak pomáhají upřesnit
odhad zbývající pracnosti vývoje, se kterými pracuje projektový manažer při upřesňování svého

harmonogramu projektu.

3.3.1.5 Programátorské testy

Nedílnou součástí realizace požadavků je také programátorské ověření správnosti implementace. Toto
se děje jednak ručním ověřením souladu vytvořené funkčnosti se zadáním a ve většině případů též
vytvářením „unit" či jiných automatizovaných testů. Tyto testy jsou trvalou součástí vytvářeného kódu,
průběžně se udržují a lze je kdykoliv použít i pro zpětné ověření funkčnosti např. při změnách již
vytvořeného kódu.

Po implementaci daného požadavku následuje jeho ověření u jiného člena týmu. Toto ověření spočívá
jednak v základním funkčním přetestování a jednak ke vzájemné kontrole vytvořeného kódu, což přispívá
k šíření znalostí o vytvořeném kódu mezi programátory, zvýšení zastupitelnosti a rovněž to napomáhá ke
zvyšování kvality kódu.

3.3.1.6 Uvolnění verze a testování

Na konci iterace je vytvořena nová verze vytvářeného softwaru, kde jsou zaneseny nově
implementované požadavky. Zrealizované požadavkyjsou předány na testery. Nová verzeje nasazena do
interního testovacího prostředí, kde je podrobena důkladnému funkčnímu testování (příp. integračnímu
či jinému). Pro tento účel jsou typicky vdobě realizace dané verze paralelně připravovány testovací
scénáře, které se následně využijí pro testování.

63
W ČR - Cssz

UsrREoI

Křížová 25, 225 08 Praha 5

V případě nalezení chyb jsou tyto chyby zaevidovány a předány k opravě programátorskému týmu. Dle
závažnosti nalezených chyb se oprava provádí okamžitě (týká se kritických chyb, které znemožňují
pokračovat vdalším testování) nebo až vprůběhu právě pobíhající popř. některé budoucí iterace.

Záznam o opravené chybě je opět předán na testera k ověření správnosti opravy.

Uvolňování verzí do prostředí Objednatele kvůli zákaznickým testům se typicky děje na konci
jednotlivých etap, popř. může probíhat i častěji. Předchází mu vždy kratší období (např. jedna iterace)
intenzivního testování a průběžného opravování chyb, aby kvalita předaného softwaru byla na
dostatečné úrovni pro použití Objednatelem.

3.3.1. 7 Nástroje pro podporu vývoje
Pro efektivní implementaci výše uvedeného životního cyklu vývoje softwaru používáme specializovaný
nástroj typu ALM (Application Lifecycle Management). Tento nástroj umožňuje evidovat jednotlivé typy
položek, jako jsou požadavky, úkoly, chyby. Rovněž podporuje celý životní cyklus položek včetně jejich
časového plánování a přidělováni řešitelům. Nástroj má dále přímou vazbu na zdrojové kódy, takže je
zajištěna snadná trasovatelnost mezi požadavky, úkoly a způsobem jejich realizace ve zdrojovém kódu.
Pro efektivní řízení projektu je možné si definovat přehledné grafy znázorňující různé pohledy na stav
vývoje (např. počty požadavků v různých stavech, počty chyb, množství úkolů přidělených jednotlivým
řešitelům apod.).

Pro tvorbu analytických a návrhových modelů a specifikací použijeme modelovací nástroje umožňující
tvořit modely ve standardních notacích jako je UML, BPMN, ArchiMate apod. Tyto modely budou
doplněny strukturovaným textem vytvářeným v běžných nástrojích pro tvorbu textových či tabulkových
dokumentů.

Programování je standardně podpořeno nástroji typu IDE (Integrated Development Environment),
nástroji pro správu programového kódu (viz níže), nástroji pro generování standardizovaných částí kódu
(např. ve vrstvě objektově-relačního mapování, na datových rozhraních apod.), nástroji pro
automatizované překlady a sestavování softwarových balíčků včetně spouštění „unit" testů a provádění
automatizované kontroly vybraných vlastností kódu (povinné komentáře, duplicitní kód apod.).

Pro podporu testování zejména u větších projektů používáme specializované nástroje pro řízení

testování, tvorbu a údržbu testovacích sad, scénářů, běhů testů.

Jednotlivé výše uvedené nástroje jsou větší či menší měrou integrovány s „centrálním" nástrojem ALM,
čímž vzniká jednotné prostředí pro řízení vývojového projektu, což významnou měrou zefektivňuje
proces softwarového vývoje.

3.3.1.8 Správa programového kódu
Programový kód je udržován centrálně vsystému pro správu a verzování zdrojových kódů. Jednotliví
programátoři pracují nad svými lokálními kopiemi zdrojového kódu a po dokončení přiděleného úkolu

ukládají změny do centrálního úložiště. Zde je uchovávána historie jednotlivých souborů, je možné

provádět verzování celého balíku zdrojových souborů a v případě potřeby lze dokonce vytvářet paralelní
instance zdrojových souborů, tzv. větve, kde jedna slouží např. pro vývoj nových funkcí a druhá pro
opravy chyb a uvolnění opravných verzí.

Centrální úložiště zdrojových souborů je pravidelně automaticky zálohováno, čímž se omezují rizika

projektu.

64
W ČR - tssz

Osman:

Křížová 25, 225 08 Praha 5

3.3.1 .9 Kvalita programového kódu
Kvalita programového kódu souvisí nejen s množstvím chyb, které v něm existují, ale také s jeho vnitřní
podobou, tj. jak zdrojový kód „vypadá". Kvalitní kód by měl splňovat 3 hlavní vlastnosti:

. srozumitelnost (pro programátory),
. robustnost (vůči nestandardním situacím),
. přizpůsobitelnost (vůči požadovaným změnám).

Mezi techniky, které vedou k zajištění těchto vlastností, patří komentování a jednotné formátování kódu,
jednotné a srozumitelné názvosloví, dekompozice kódu na malé části, logování, ošetřování chybových
stavů, nekopírování kódu, tvorba nezávislých modulů, používání konfiguračních parametrů atd.

Základem pravidel tvorby kódu na každém námi realizovaném projektu jsou obecná projektové a
technologicky nezávislá pravidla, která vznikla na základě zkušeností z mnoha projektů. V rámci každého
projektu jsou pak definována projektové specifická pravidla tvorby kódu, která zohledňují potřeby
konkrétního projektu, zvolené technologie a také např. programátorské standardy deﬁnované
Objednatelem a uplatňovaná na veškerýjemu na míru vyvíjený software.

3.3.1.10 Průběžné ověřování vyvíjeného systému
Průběžné ověřování (testování) vyvíjeného softwaru je základem pro efektivní zajištění kvality
dodávaného díla. Toto testování má několik úrovní, některé z nich již byly zmíněny výše:

. automatizované programátorské testy, které vznikají současně s vývojem nové funkcionality.
. automatizované pravidelné sestavování a pouštění automatizovaných testů.
. interní revize vytvořeného kódu vedoucím programátorem nebo mezi programátory navzájem.
. interní funkční testy po dokončení jednotlivých iterací v prostředí Zhotovitele.
. průběžné funkční testy realizované zástupci Objednatele (pokud bude tato forma ověřování

v rámci projektu potřebná) s cílem prakticky ověřit použitelnost vytvořeného řešení pro budoucí
uživatele.
. průběžné prezentace vytvořeného programového vybavení pro vybrané zástupce, což je pro
Objednatele časově méně náročnou, ale z pohledu realizace projektu také méně přínosnou
alternativou kzákaznickým funkčním testům; samozřejmě je možné kombinovat zákaznické
testy, které provádí úzká skupina zástupců Objednatele, s prezentacemi, které jsou určené pro
širší fórum účastníků projektu.
Hlavní motivací tohoto průběžného ověřování je všeobecně známá a potvrzená zkušenost, že čím dříve
se odhalí chyba v implementaci, tím menší nákladyje třeba vynaložit na její odstranění.

Při plánování projektu jsou navrženy termíny dílčích testů a prezentací a je rámcově určeno, jaká část
řešení bude k daným termínům implementována.

3.3.2 Metodika přípravy nasazování balíčků

Metodika přípravy a nasazeni balíčků vychází ze standardního procesu RELEASE AND DEPLOYMENT
MANAGEMENT, který je součástí ITIL 2011. Balíček release, respektive release představuje jednu,
případně více změn služeb, které jsou sestaveny, testovány a nasazeny najednou. Release tak může

65
% čR-čssz
Osment

Křížová 25, 225 08 Praha 5

zahrnovat změny softwaru, dokumentace, procesů a dalších komponent. Proces odpovídá za dodávku
nové funkčnosti požadované businessem a současně chrání integritu stávajících služeb IT. Proces je
odpovědný také za to, že nasazení všech změn do produkčního prostředí bude řízeno a organizováno
efektivně, a to jak po nákladové, tak po organizační stránce.

Vzhledem ke skutečnosti, že popsaná metodika je náročná na součinnost, metodickou připravenost, a
zároveň má také značné časové požadavky, bude možno přípravu a nasazování balíčků provádět ve
zjednodušeném režimu, který bude vycházet z principů uvedených v této kapitole.

3.3.3 Příklady předpokládaných výstupů

3.3.3.1 Okomentovaný zdrojový kód
Vhodným způsobem okomentovaný zdrojový kód je vedle dobrého názvosloví a přehledného
strukturování kódu základním předpokladem pro zajištění srozumitelnosti a rychlé orientace v kódu.
Komentáře nemají opisovat programový kód, ale vysvětlovat myšlenky, které jsou programovým kódem
realizovány. U veřejných metod třídy musí komentáře vysvětlit správný, příp. i upozornit na chybný
způsob použití, objasnit význam vstupních a výstupních parametrů a popsat efekty, které způsobí volání
dané metody. U jednoduchých a privátních metod není třeba podrobně popisovat logiku, která je na
první pohled zřejmá z názvu či programového kódu dané metody (typicky např. metody get/set pro
získání/nastavení hodnoty atributů objektu).

Komentáře isou ve zdrojovém kódu na 3 úrovních:

» Na úrovni celé třídy vysvětlují smysl / poslání dané třídy a zasazujíjejí použití do kontextu dalších
tříd.

0 Na úrovni jednotlivých metod definují účel dané metody, popisují její parametry, návratové
hodnoty, možné výjimky a chybové stavy, efekty použití dané metody.

0 Na úrovni jednotlivých řádků / konstrukcí uvnitř programového kódu vysvětlují logiku
implementovaných algoritmů, význam složitějších podmínek apod.

66
W ČR - (5552

ÚSTŘEDI

Křížová 25, 225 08 Praha 5

' Scheduie' p'o joby. Singleton beam “32ou; wtc :Hdn, new pounnt jen mm «mm, presny nad je
' YARGELCLASS rulimvuný pomoci (glib.

I'!

EMM/íce
ýsmpchulue - wlicnzimxmtenxvgszssm, We - Semaruyﬂodeluﬂhtuss)
Ml“ do“ Quortócntonsútduhr hol—ent: Sort-Hutla (

private suck “ml long “duller-steam!) - zaasomauseuosut;

Sautcmoed
prints Scheduler quartzkhtduhr;

' Seinu apuštčných jobu. facma't »jcblun, t'iggtr;

privat: Haydn-tn.. JebOcntlHtthSmn "nut-«Jobs;

' Z'Iiciblizact

ﬁmtx’nmtwu

mu: vou init() (

eucutedlobs - neu mam—usum., Joaoeuuutthsutenn

!
' líbph'wjg 70b, pand ještě diru soustavy.

. job!-au
‘ :'th jomscršprion
Myﬂtkh
schedultchcgption

jct— je ji.“ »— “mnu spuštěny-nh 39be nebo nastala jiná chyba,

pólu vola (fluor-zabavu. jobu-u, String joboescripuon, mym-.la: nyndoa) throws Scheduler-Exception (
H (txuuttdkbiqﬂqmm) í- null) (

(hm neu Scheduleruceptlonťiob ' . jobNue . ' already Hunted“);

)

Triu" trigger - 1r£uomtllz.uh£-diate7rígper(0. l); .-‘/ spustí hned a tic/u:: jednou
loboetúlutthStatl job . m lobbﬂoﬂilkhstuﬂjobm, this.wstrinu), jcbourdption, uyndob, Rigger);

Obrázek 19 - Příklad komentování zdrojového kódu

3.3.3.2 lnstaIac'm’skripty

Instalační skripty usnadňují správci systému proces instalace nových verzí programového vybavení.
Typickv sdružuií následuiící akce:

. Aktualizaci databázového schématu
. Nahrání nových instalačních balíčků programového vybavení do správného umístění
. Nahrání konfiguračních souborů do správného umístění

Je-Ii to technologicky a věcně možné, mohou instalační skripty provádět i automatické zastavení běžící
aplikace (lze podmínit dotazem na administrátora, který spouští daný skript, zda má být aplikace
ukončena) a jeji znovuspuštění po dokončení instalace nové verze.

Instalační skripty udržuje Zhotovitel jako součást programového kódu včetně společného verzování a
zajištění provázanosti instalačních skriptů na správné verze ostatních artefaktů.

3.3.3.3 Deﬁnice finální konfigurace

Součástí dodávky bude instalační balíček se třemi sadami konfiguračních souborů, pro každé prostředí
jedna sada (tj. konfigurační soubory pro integrační, pro testovací a pro provozní prostředí).
Administrátor, který bude instalovat aplikaci, si zvolí instalaci v závislosti na prostředí, kterou spustí
příslušným skriptem pro vybrané prostředí.

67
% ČR - ČSSZ
ÚSTŘEDÍ

Křížová 25, 225 08 Praha 5

Položky konfiguračních souborů (u kterých to má smysl) budou popsány vadministrátorské příručce.
Hodnoty jednotlivých položek budou vyplněny v konfiguračních souborech Zhotovitelem s ohledem na
prostředí, pro kteréjsou určeny.

3.3.3.4 Technická / programátorská dokumentace
Technickou dokumentaci lze rozdělit do několika úrovní:

Detailní programátorská dokumentace, která vzniká 2 komentářů uvedených přímo ve zdrojovém
kódu. Obsahově je popsáno výše v kapitole o komentování zdrojového kódu. Důležitým
předpokladem je dodržování správného formátu komentářů, které následně umožní
vygenerování dokumentace do samostatného dokumentu.
Přehledová systémová dokumentace, která popisuje architekturu systému ijednotlivých aplikací,
průřezové aplikační mechanizmy a další informace, které jsou vhodné pro pochopení fungování
softwaru jako celku. Základem této dokumentace jsou návrhové dokumenty, které vznikají před
a v průběhu vývoje a které jsou po dokončení vývoje zaktualizovány, aby popisovaly skutečný
finální stav vytvořeného díla.
Administrátorská dokumentace, určená pro provozovatele a správce systému, podrobněji
popsaná níže.

Administrátorskárgříručka bude obsahovat tvto informace:

začlenění aplikace do kontextu celkové IT infrastruktury a vazby na okolní systémy
komponenty aplikace
popis instalace
požadavky na vyškolení a odborný výcvik uživatele
popis zabezpečení aplikace a rozsahu oprávněníjednotlivých skupin uživatelů a jejich správy
postup zálohování a obnovení dat aplikace
seznam konfiguračních parametrů aplikace a aktuální hodnoty jejich nastavení pro ostrý provoz
přehled notifikací pro administrátora
auditní záznamy aplikace
popis známých chybových stavů
postup řešení mimořádných stavů
pokyny pro zpětnou vazbu (hlášení neshod, reklamací apod.)

3.3.3.5 Uživatelská dokumentace
Uživatelská příručka nepopisuje pouze statickou strukturu aplikace a obsah obrazovek, jejím cílem je
popsat způsoby použití, tj. jaké kroky má uživatel provést při plnění konkrétního cíle. Uživatelská
dokumentace proto vychází z analytického modelu případů užití.

Uživatelská příručka bude obsahovat zejména:

úvod (základní popis aplikace, informace o příručce),
popis aplikace,

68
W ČR - Cssz

ÚSTŘEDI

Křížová 25, 225 08 Praha 5

. postup přihlášení do aplikace a její ukončení,
o popis ovládání aplikace (uživatelského rozhraní),
. popis funkcí SW produktu,
o popis výstupů.

Kapitoly popisující případ užití budou zahrnovat:

. popis cíle aktivity uživatele,
. detailní popis akcí uživatele při plnění daného cíle,
. na příkladu je uveden postup provedeníjedné aktivity,
. nejčastější problémy, se kterými se může uživatel při práci setkat, ajejich řešení.

Uživatelská příručka bude členěna podle uživatelských rolí.
Vedle Uživatelské příručky mají uživatelé kdispozici ještě Školicí prezentaci s doprovodnými materiály,
jakje uvedeno v kapitole 3.5.1 Návrh způsobu školení.

Příklad obsahu dodávané Uživatelské příručky:

*.'.w ““Z—" —-—» ---—--- _ _ W .f
- .. „..—__ ..„. ._.... _.. .

'
.llilll' . um.-um mwmmuw

Wanna—www.—
_ „„ _, . .I“u,m»_

_. v . „mu—„au-.uwu

I‘UM- m “u_n—ubuntu...— '
u unmask...

lvu—|- l. mnu—annuu— '

TSm—aw :r' ta— --—- "

“FW-. „Šp. „!!!—""— .“

na.—||) _g, , , Juan-unmana- 3-

yl—HW‘ . , ‘u-I-mm-m , f

v_n-q. , mo...—„___— '

_nm-r-;9-_„„_ „_ 1995—2-59; „„ ,"

Don-- uuu—ob, unu-uu— '

, _" . „“;“-„„j A;„„ _,6.„„ m“.

__" ., 4.7.. ; ...... ..

Mn - mun—nu-

luau-nu.— inu—

,u- . . , _—„ I .. - „ — „ — I„”...m„.„, '

Obrázek 20 — Příklad obsahu dodávané Uživatelské příručky

69
int--II-Í—I—I—l—I—m—I—l—m W ČR - ČSSZ

asmat

Křížová 25, 225 08 Praha 5

. Komu je “huh:.......... 5'.’

3.3 Jů pm'n'vx m“? ............. SB

3.4 Rauma použité v p'n'xučce ..... 59

4.1 Rámce .............................. 60

6 Mb ................. 61

6.1 L'il'vldshé m1! ............. 61

6.2 Piacbokláthé HIM ................ 61
6.3 Uvuluí pnmviitě do duh...

7.1 Pwky imam max-i......................

8 Mini ovliů'm' qalikxe

u Muni mm Explom .......
12.1 Ukl'xl'an' dat ve můové Q1111: .
12.2 Mikr.: pivaři - výtěrmu
13.1 SMT-xi mihne AFV-m! ......

Obrázek 21 - Příklad obsahu dodávané Uživatelské příručky

3.3.3.6 Zajištění vývojového prostředí
Vývojové prostředí se standardně nachází v prostorách Zhotovitele. Většinu složek vývojového prostředí
si zajišťuje Zhotovitel: stanice pro členy realizačního týmu, vývojové nástroje již předpřipravené v podobě
umožňující rychlé zapojení nových členů týmu, servery pro umístění vývojových databází a aplikačních
serverů, potřebnou síťovou infrastrukturu.

Důležitou částí vývojového prostředí je též řešení vazeb na okolní systémy, které standardně nejsou
v prostředí Zhotovitele kdispozici. Může se jednat o vývojové prostředí přímo u výrobce/dodavatele
okolního systému nebo o prostředí pro tento účel zřízeném u Objednatele. Pokud není k dispozici žádná
možnost napojení vytvářeného softwaru ve vývojovém prostředí na skutečnou instanci okolního
systému, může vzniknout na straně Zhotovitele simulátor okolního systému, který implementuje
odpovídající rozhraní a simuluje chování okolního systému. Poskytování případných konzultaci řešení na
úrovni business, architektury, analýzy, designu, implementace, integrace a testování.

3.3.3.7 Poskytování případných konzultací řešení na úrovni business, architektury, analýzy,
designu, implementace, integrace a testování

Zhotovitel je připraven vrámci plnění Smlouvy poskytovat konzultace ke všem částem vytvořeného

programového vybavení, jakož i dalším oblastem, které s dodávkou souvisí.

70
% ČR - tssz

ÚSTŘEDI

Křížová 25, 225 08 Praha 5

3.4 Testovaci část

Závazné obchodní podmínky:

V rámci testovací fáze Zhotovitel minimálně zajistí:

Podporu při přípravě testovacích prostředí;
Funkční testy;
Integrační testy;
Akceptační testy (provádí Zhotovitel, Objednatel akceptuje na základě akceptačního řízení);
Technické testy (penetrační, výkonnostní);
Přípravu zpráv z testování.

Objednatel plnění dle tohoto článku (3.4 Testovací část) akceptuje na základě akceptačního řízení.

Zhotovitel předloží závazný popis plnění dle výše uvedeného.

Zhotovitel minimálně popíše:

' Příklady předpokládaných výstupů;
. Úvodní návrh testovací strategie;
. Obecnou metodiku jednotlivých typů testů.

(dop/ni Zhotovitel) - Zhotovitel doplnil, viz kapitoly níže.

3.4.1 Příklady předpokládaných výstupů
Za hlavní výstupy testování považujeme testovací případy. Testovací případ je dokument, který popisuje:

. podmínky pro provedení konkrétního testu,
. kroky provádění konkrétního testu,
. očekávané výsledky po provedeníjednotlivých kroků konkrétního testu,
. celkové vyhodnocení výsledku konkrétního testu.
Uvádíme vzorový příklad testovacího případu vytvořeného pro aplikaci NEM:

Testovaci případ

Název: PP06.01-01 — Kontrola aprobované dávky — Potvrzení aprobantem

71
W ČR _ tssz
05mm!

Křížová 25, 225 08 Praha 5

Ověřit funkčnost kontroly o rozhodnutí referenta o dávce a potvrzeníjeho rozhodnutí
Role: Přihlášení pod jiným uživatelem než referentem, který provedl rozhodnutí
odávce.

_ Další předpoklady: Referent provedl rozhodnutí o dávce
= Existující dávka pro aprobaci

" = uc PP06.01

_ ‘ TS PP06.01 — Kontrola aprobované dávky

Krok Popis Očekávaný stav Výsledek
1.
2. Uživatel vyhledá dávku k aprobaci a Dávka nalezena a uživateli je
3.
zobrazí pro níobrazovku Dávka-Stav zobrazena obrazovka Dávka -
4.
5. dávky Stav dávky
6.
Uživatel zvolí[Potvrdit rozhodnutí] Systém zobrazí obrazovku pro
zápis komentáře řešitele

Uživatel bez zápisu poznámky stiskne Odeslání proběhne úspěšně.

tlačítko [Odeslat] Systém změní stav dávky na

Potvrzeno aprobantem.

Uživateli je zobrazena obrazovka

Dávka - Stav dávky. Na

obrazovce je aktuální informace

o čase a osobě, která dávku

aprobovala.

Uživatel vyhledá dávku k aprobaci a Dávka nalezena a uživateli je

zobrazí pro níobrazovku Dávka-Stav zobrazena obrazovka Dávka -

dávky Stav dávky

Uživatel zvoIí[Potvrdit rozhodnutíl Systém zobrazí obrazovku pro
zápis komentáře řešitele

Uživatel zapíše poznámku a stiskne Odeslání proběhne úspěšně.

tlačítko [Odeslat] Systém změní stav dávky na

Potvrzeno aprobantem.

Uživateli je zobrazena obrazovka

Dávka - Stav dávky. Na

obrazovce je aktuální informace

72
W ČR - ČSSZ

ÚSTŘEDI

Křížová 25, 225 08 Praha 5

o čase a osobě, která dávku
aprobovala.

3.4.2 Úvodní návrh testovací strategie

Navrhovaná testovací strategie navazuje na návrh analytické dokumentace a přístup k testováníje volený
s ohledem na předpokládanou existenci seznamu požadavků a případů užití.

V rámci testování na projektu budou využity následující tvpv testů:

. Funkční
. Integrační
. Akceptační testy (provádí Zhotovitel, Objednatel akceptuje na základě akceptačního řízení)
0 Technické Výkonnostní (konkrétně pak Zátěžové)
. Technické Bezpečnostní (Penetrační)

Obecná metodika těchto typů testů je upřesněna v kapitole 3.4.3.

Testování bude probíhat v následuiících úrovních/fázích testování:

Systémové testování
Ověřuje funkčnost systému jako celku po kompletní integraci komponent. Podkladem jsou analyticky
zpracované uživatelské požadavky a testovací případy postavené na jejich základě. Cílem je nalezení
neshod oproti požadavkům na systém.

Integrační testování
Ověřuje funkčnost jednotlivých částí systému v návaznosti na okolí. V procesu testování se zaměříme
konkrétněji na integrační testování komponent a systémově integrační testování větších vyvíjených celků
a jejich komunikaci jak s dalšími vyvíjenými částmi, tak s existujícími okolními systémy a aplikacemi. Při
integračním testování se bude postupovat od menších integrovaných celků květším. Integrační testy
budou probíhat ideálně postupně spolu stím, jak budou integrovány další části systému tak, aby se
neshody nacházely průběžně a jejích odhalení bylo snadnější.

Regresní testování
Ověřuje funkčnost systému nebo jeho částí v pravidelných intervalech nebo po tom, co byla část systému
změněna, nebo byly vykonány změny na testovacím prostředí (v tomto případě na jakémkoliv testovacím
prostředí, dle aktuální fáze testování). Probíhá na základě podkladu v podobě regresních testovacích
scénářů pokrývajících klíčovou funkčnost v kombinaci s namátkovými testy ověřujícími funkčnost v méně
důležitých, ale změnami ohrožených případech.

Akceptační testování
Je ověřením funkčnosti oproti předem definovaným akceptačním kritériím podle akceptačních
testovacích scénářů. Probíhá v závěrečné fázi vývoje dané části systému. Může mít jak podobu testů na
straně Zhotovitele tak na straně Objednatele. Úspěšný přechod akceptačním testováním je jedním
z předpokladů pro akceptaci produktu. Samotná akceptační kritéria budou stanovena v dílčí smlouvě.

73
mii .“ % ČR—ČSSZ

Osment

Křížová 25, 225 08 Praha 5

3.4.2.1 Průběh testování
Průběh testování bude závislý na vývoji jednotlivých částí systému a jednotlivé úrovně testování budou
vykonávány opakovaně v každé následující iteraci. Průběh testováníje znázorněn následujícím obrázkem.
Počet opakování jednotlivých bloků testů bude závislý na celkovém počtu vývojových iterací.

Regresní testování pak zahrnuje také rozšíření vytvářené regresní testovací sady. Bude vždy uplatněno
při pracnosti nad 50 člověkodnů při úpravách APV.

Obrázek 22 — Schematické znázornění průběhu testováni systému

3. 4.2.2 Testovací data

U většiny testů předpokládáme využití dat zjednotlivých fází migrace. Vnestandardních případech a
v případě, kdy to bude nutné, bude pak popis přípravy testovacích dat součástí konkrétního testovacího

případu.

3.4.2.3 Testovací prostředí
Ve fázi systémového testování předpokládáme využití vlastního testovacího prostředí Zhotovitele a v
míře, ve které to charakter testů umožní, bude naše testovací prostředí využito také v počátku interních
integračních testů. Hlavní fáze integračních, bezpečnostních a výkonnostních testů budou probíhat na
integračním a testovacím prostředí Objednatele, které bude odpovídat produkčnímu (provoznímu)
prostředí. Postup bude upřesněn v projektovém Test plánu, podle povahy a rozsahu projektu.

3.4.2.4 Vstupy a výstupy testování
Vstupem pro tvorbu testů bude analytické zadání v podobě požadavků a případů užití.

Základní testovací případy budou vytvářeny v návaznosti na příslušné výstupy analýzy. V průběhu vzniku
testovacích případů bude revidována a rozšiřována regresní testovací sada 0 důležité testovací případy a
tyto budou současně i na základě akceptačních kritérií zařazovány do akceptačních testovacích scénářů.
Přednostně budou zpracovávány testy ověřující oblasti s největší hodnotou pro objednatele a s
největším dopadem na uživatele systému. Cílem je ale pokrytí všech funkčních požadavků příslušnými

74
W ČR - Cssz

ÚSTŘEDI

Křížová 25, 225 08 Praha 5

testovacími případy a v opodstatněných případech také zahrnutí těchto testů do pravidelně ověřované
regresní testovací sady.

Potřebná testovací dokumentace bude primárně vznikat vnástroji ALM (Application Lifecycle
Management), a to jak na úrovni jednotlivých testovacích případů, tak také ucelených testovacích sad.
Spomocí ALM také zabezpečíme monitoring a reporting o průběhu testování a o množství a stavu
defektů. Pro uživatelské testování (případné akceptační testy) na straně objednatele bude potřebná
testovací dokumentace vytvořena pokud možno exportem zALM tak, aby byla zabezpečena její co
nejjednodušší přenositelnost. Nebude-li dohodnuto jinak, export bude kdispozici ve formátech MS
Ofﬁce.

Mimo tuto dokumentaci vznikne na počátku testování dokument plánu testů. Vpříslušných fázích
testování budou vytvářeny dílčí dokumenty, především protokol o výsledku výkonnostních testů,
protokol o výsledku bezpečnostních a penetračních testů, scénáře pro akceptační testy a protokol o
výsledku akceptačních testů.

3.4.2.5 Nástroje pro evidenci a správu testování
Pro správu testů a nalezených neshod a chyb bude podobně jak pro vývoj využit jednotný nástroj pro
Application Lifecycle Management (ALM). V něm bude udržována aktuální podoba testů (jak na úrovni
testovacích případů, tak i scénářů a testovacích sad) a zaznamenávány neshody a chyby. Nástroj rovněž
zabezpečuje sledování testovacích případů v průběhu celého jejich životního cyklu a poskytuje
prostředky pro reporting.

Metodika použití ALM nástroje na projektu bude upřesněna v rámci projektového Test plánu.

Pro výkonnostní testova'ní a případnou automatizaci regresních testů bude volba konkrétních nástrojů
popsána v projektovém Test plánu. Předběžně ale předpokládáme u výkonnostních testů použití nástrojů
JMeter a využití možností nástroje SoapUl.

3.4.2.6 Kritéria ukončení testování

Testování ve fázích systémových a integračních testů bude probíhat paralelně na vícero podúrovních.
Spolu s dokončováním vývoje jednotlivých částí a modulů systému budou vytvářeny testovací případy na
úrovni těchto menších celků a aplikace bude podle nich testována. Spolu se začleňováním těchto
menších celků do vznikajícího systému budou probíhat integrační testy, jejichž úlohou bude ověřovat
funkčnost přidávaných částí v návaznosti na systém. Testy spadající do těchto úrovní budou přítomny po
většinu času vývoje systému a testování v této fázi bude považováno za ukončené po dokončení vývoje
funkčních požadavků a případů užití a splnění výstupních kritérií definovaných vtest plánu projektu.
Podobně testování na úrovni Integračních testů bude probíhat až do úspěšné integrace systému na
okolní systémy.

Kritériem pro ukončení výkonnostního testování bude úspěšné ověření funkčnosti a stability systému při
předem definované předpokládané zátěži.

Ve všech případech platí, že pro ukončení testování nesmí aplikace obsahovat chyby Vysoké a Kritické

závažnosti. (popis závažnosti chyb viz níže v části „Defekty a neshody"). Řešení dalších typů chyb bude

řešeno souhrnně projektovým týmem.

75
!:

W ČR-ČSSZ

Osman!

Křížová 25, 225 08 Praha 5

3.4.2. 7 Evidence, správa, vyhodnocení a řešení defektů a neshod
U defektů bude sledováno a evidováno několik hlavních parametrů, kromě samotného popisu defektu
především Závažnost (Severity) a Priorita. Dále by pak nalezené defekty měly, pokud je to možné,
navazovat na konkrétní testovací případ, vjehož rámci byla neshoda nalezena. Formát popisu defektu je
částečně dán použitým nástrojem a vazbou na konkrétní test — používaný ALM nástroj zaznamenává
konkrétní krok testu, kde k problému došlo, a umožňuje defekt popsat při tomto kroku. Pro případy, kdy
defekt nebude nalezen v přímé souvislosti s konkrétním testovacím případem, bude použita šablona pro
co nejpřesnější popis defektu.

Pro určení priorit prací na defektech jsou klíčové parametry Závažnosti a Priority. Priorita se stanovuje při
nalezení defektu a aktualizuje při zařazení defektu do řešení. Závažnost pak určuje test analytik při
nalezení defektu po případné konzultaci s analytiky a vývojovým týmem.

Priorita je interním ukazatelem popisujícím časovou prioritu opravy defektu.

Pro kategorizaci závažnosti nalezených defektů (chvb) bude použitá následuiící stupnice:

. „Kritická“ — chyba splňuje alespoň jednu z níže uvedených podmínek:
o Několik nebo všechny funkce systému, které obhospodařují obchodní a technické
procesy, nejsou v provozu nebo mají omezenou funkci, aplikace neumožňuje pokračovat
v činnosti a neexistuje náhradní akceptovatelné řešení, které umožňuje dále pracovat s
funkčností aplikace bez opravy defektu aplikace.
0 Defekt má významný dopad na realizaci testu - testovací činnosti (realizace jednoho
nebo více testovacích případů/scénářů) nemohou pokračovat bez opravy defektu.
o Zjištěný defekt má podstatný dopad (okamžitý nebo finanční) na obchodní funkční
činnost Objednatele v případě uvolnění aplikace do provozu s touto chybou.

. „Velká" - chyba neodpovídá charakteristice chyby se závažnosti „Kritická“. Ke stanovení této
závažnosti bude nutné splnění první nebo druhé, níže uvedené, podmínky:
0 Chyba znemožňuje plně využít požadovanou funkčnost aplikace a má významný dopad
na proces podporovaný funkčností aplikace a tím způsobuje významný nebo negativní
dopad na konečného uživatele nebo klienta.
o Chyba způsobuje zakrytí některé dílčí funkčnosti, která nemůže být prověřena.
0 Pro využití funkčnosti aplikace s touto chybou existuje akceptovatelné náhradní řešení —
pouze po omezenou časovou dobu, než bude chyba opravena.
o Chyba se vyskytuje v omezeném množství při práci s aplikací ve vztahu k dopadu na
realizaci testů.

. „Střední" — chyba neodpovídá charakteristice chyby se závažnosti „Kritická" nebo „Velká" a:
o Chyba se vyskytuje v obchodně kritickém procesu, ale bude možné ji obejít využitím jiné
funkce systému (v rozsahu, který vážně neohrožuje činnost Objednatele), nebo omezuje
či znemožňuje nekritické obchodní procesy.
o Akceptovatelné náhradní řešení chyby umožní dokončit realizaci všech naplánovaných
testovacích skriptů daného kola.

. „Malá" — chyba neodpovídá charakteristice chyby se závažnosti „Kritická", „Velká" nebo
„Střední" a:
0 Má zanedbatelný dopad na proces podporovaný funkčností aplikace nebo na obchodní
(funkční) činnost Objednatele.

76
W ČR - (552

USTREDI

Křížová 25, 225 oa Plaha 5

o Chyba způsobuje odchylku požadovaného uživatelského rozhraní od implementovaného

řešení (jiný text tlačítka, poloha tlačítek atd.).
0 Nebo se účastníci procesu shodnou, že chyba může být akceptována bez opravy, řešena i

po nasazení akceptované verze nebo neřešena.

3.4.3 Obecná metodika jednotlivých typů testů

3.4.3.1 Funkční testování
Funkční testování slouží k ověření funkčnosti dodávané aplikace. Zhotovitel zajistí kompletní provedení
níže uvedeného funkčního testování. Pro jeho provedení má dostatečné odborné znalosti a zkušenosti a
zároveň disponuje testovacím týmem, který je schopen kapacitně pokrýt všechny níže uvedené fáze
funkčního testování. Funkční testování je v níže uvedené podobě součástí systémových, integračních i
akceptačních testů.

Hindu Provedení

mm 1:> testů

testů

Obrázek 23 - Fáze testování

Plánování testů
Fáze Plánování testů zahrnuje tvorbu test plánu projektu, podle kterého bude funkční testování aplikace
prováděno. Podle konkrétního projektu pak plán testování obsahuje odpovídající části:

0 Návrh struktury a rozsahu testů, včetně způsobu provedení.
0 Definice metodických postupů pro jednotlivé kroky testování.
. Akceptační kritéria pro funkční testování konkrétní aplikace.
0 Popis konkrétní organizační struktury testovacího týmu.
0 Definice odpovědnosti a pravomoci účastníků testování.

. Konkrétní popis způsobu evidence nalezených neshod, sledování řešení chyb, způsob

vyhodnocení testů.
' Definice zdrojů.

. Návrh konkrétních formulářů, které budou použity v průběhu testů (zápis neshod, protokoly

o výsledcích, ...).

Návrh a příprava testů
Příprava testovacích případů
Testovací případy a scénáře budou vznikat souběžně s tvorbou zadání pro programování pro jednotlivé
navrhované části systému. Na správu testovacích případů bude použitý modul Test systému Microsoft
TFS. Testovací případy budou tvořeny na úrovni podrobnosti potřebné k otestování dané části systému —
od podrobného popisu kroků a očekávaných výsledků až po odkazy na už připravené testy v nástrojích
pro automatizaci testování (např. SoapUI).

77
ill-l-llm W CR-čssz
ÚSTŘEDI

Křížová 25, 225 08 Praha 5

Příprava testovacích dat
Vstupními informačními zdroji pro přípravu a úpravu namigrovaných testovacích dat budou testovací
scénáře a projektová dokumentace testované aplikace. Testovací data musí být pořízena v dostatečném
množství a struktuře, která vychází z koncepce testovacích scénářů. Zvelké části by dostatečný vzorek
testovacích dat měl být pokryt právě migrací. Důležitým krokem bude ověření testovacích dat před jejich
použitím.

Příprava testovacího prostředí
Testovací prostředí bude zřízeno na straně Zhotovitele i Objednatele. Dodavateli slouží pro interní testy
před nasazením systému do testovacího prostředí Objednatele, druhé jmenované pak pro účely
integračních a akceptačních testů v prostředí Objednatele. Toto prostředí bude sloužit pro ověření nové
funkčnosti před jejím nasazením do prostředí produkčního. Předpokládáme, že testovacím prostředím na
straně Objednatele pro účely projektu bude Integrační prostředí Objednatele. Instalace se budou
provádět dle instrukcí distribuovaných s instalačními balíčky a technické a provozní dokumentace.

Provedení testů
Funkční testy budou prováděny jak nad interním testovacím prostředím Zhotovitele, tak nad testovacím
prostředím Objednatele, test analytikem podle předem připravených testovacích scénářů svyužitím
testovacích dat připravených v předešlé fázi.

Vyhodnocení testů
Součásti vyhodnocení testů bude záznam o provedení testu. Výsledky testů a případné neshody budou
evidovány vsystému pro správu testů. Defekty pak budou průběžně podle stanovené závažnosti a
priority opraveny a test analytik bude systémem informován o vyřešení defektu a o možnosti ověřeníjejí
opravy.

Po dokončení testování celé sady testů probíhá vyhodnocení proběhnutého testu a zvážení dopadů
nalezených defektů na další testovací sady.

Po ukončení testování bude vytvořený protokol o výsledku testu a vzniká seznam testů, které je nutné
opakovat po vyřešení problémů tak, aby daná část systému mohla být nasazena do provozu.

Automatizované funkční testování
V případě, kdy dochází kneustálému vývoji dílčích částí SW s malými dopady na uživatelské rozhraní
(mění se například algoritmy složitých výpočtů apod.) a přitom je potřeba přetestovat podstatnou část
aplikace, je výhodné vytvořit automatizované testy řízené daty, které je pak možno opakovaně spouštět.
U testů Web Services je pak výhodou relativně nízká náročnost na přípravu automatizovaných testů
oproti náročnosti přípravy manuálních testů.

Pro zvýšení kvality výsledného systému předpokládáme využití automatizace u části funkčních testů pro

nejkritičtější části systému a automatizaci smoke testů (namátkových testů ověřujících základní

funkčnost, vycházejících z testovacích případů systémových testů).

3.4.3.2 Integrační testy
Smyslem integračních testů je ověření funkčnosti testovaného systému v návaznosti na okolní systémy, s
kterými vyvíjený systém komunikuje. U rozsáhlých systémů jejejich úloha zásadní a tak jejich provádění
bude věnován dostatek času a budou v základní podobě vykonávány podle možností co nejdříve.

78
W ČR - Cssz

ÚSTŘEDÍ

Křížová 25, 225 O8 Praha 5

Integrační testy budou probíhat na několika úrovních: integrační testování komponent a jejich začlenění
do systému, systémově integrační testy ověřující komunikaci s okolními systémy a v závěru pak
integrační testy nad celým vyvíjeným systémem ověřující celkovou integraci do prostředí Objednatele.

Integrační testy budou probíhat spolu s dokončováním modulů komunikujících s jinými systémy
vomezené míře už na testovacím prostředí Zhotovitele. Vplné míře pak na integračním prostředí
Objednatele podle harmonogramu, který bude dohodnutý v průběhu projektu.

Jejich provádění je vkompetenci Zhotovitele, ale jejich komplexnost vyžaduje součinnost ze strany
Objednatele a dodavatelů okolních systémů. Míra této součinnosti bude podrobněji specifikována v Test

plánu projektu.

3.4.3.3 Technické Výkonnostní testy
Tyto testy obecně zjišťují, jak systém uspokojí požadavky na odezvu a stabilitu vodpovídajících
podmínkách. Dělí se většinou na testy zátěžové, které zkoumají chování při očekávaných provozních
podmínkách (zejména z pohledu množství požadavků, které systém paralelně zpracovává), a stress testy,
které zkoumají, jak se systém chová při extrémním zatížení (např. útoky na webové aplikace nebo
zatížení v čase silnějšího provozu). Zoblastí výkonnostních testů využijeme především zátěžové testy,
jejichž popis následuje dále.

Zátěžové testování ověřuje výkonnost testované aplikace vzhledem kdefinovaným požadavkům. Tým
Zhotovitele zajistí provedení níže uvedeného zátěžového testování, pro něž má dostatečné odborné

znalosti a zkušenosti.

Celková koncepce realizace řešeníje rozdělena do následujících fází:

WP” Fiﬁ-an vm

km W

Obrázek 24 —- Fáze zátěžového testování00000

Plánování zátěžového testu
. Příprava plánu testů

Tvorba definičního dokumentu (základní dokument zátěžového testu), podle kterého bude

prováděno zátěžové testování aplikace. Tento dokument vypracovává Objednatel ve spolupráci
se Zhotovitelem a schvaluje jej Objednatel. Některé části tohoto dokumentu je možno vynechat,
pokud jsou zpracovány v metodice testování. Dokument obvykle obsahuje tyto části:

organizační struktura testovacího týmu,
definice odpovědností a pravomoci účastníků testování,
definice milníků zátěžového testu,
definice zdrojů (testovací tým, HW, SW atd.),
návrh cílů a rozsahu testu,

79
“III..-m m CR-Cssz
USTREDI

Křížová 25, 225 08 Praha 5

o návrh akceptačních kritérií zátěžového testu.
. Příprava testovacího prostředí

Na základě projektové dokumentace vytvoří projektový tým společně stestovacím týmem testovací

prostředí, které bude využíváno v průběhu zátěžového testu. Zátěžový test obvykle probíhá vjiném

testovacím prostředí než funkční testy. V našem případě předpokládáme využití integračního testovacího
prostředí Objednatele. Parametry prostředí využitého pro zátěžový test by měli byt co nejbližší
produkčnímu prostředí.

Analýza pro zátěžový test
V této fázi je vytvořen analytický dokument, ve kterém jsou podrobně rozepsány testované oblasti,
proveden výběr uživatelských transakcí použitých pro zátěžový test a navrženy scénáře zátěžového testu,
které vycházejí z provozních statistik testované aplikace a analytického odhadu další prognózy jejího
využití v provozu. Součástí analýzyje také specifikace testovacích dat pro zátěžový test.

Příprava zátěžového testu
. Příprava zátěžových skriptů

Provedení této fáze je možné až po dokončení vývoje testované aplikace a úspěšném dokončení
funkčních testů. Aplikace musí být pro zátěžový test od zahájení tvorby zátěžových skriptů
zamražená — neměly by na ní být vykonávány změny. Vybrané transakce (části procesů zvolené
pro test) jsou nahrány do zátěžových skriptů, které jsou dále laděny a parametrizovány pro
víceuživatelské spouštění zátěžových skriptů. Je vytvořen scénář zátěžového testu a proveden
zkušební běh.

Příprava testovacích dat

Vstupními informačními zdroji pro přípravu testovacích dat je specifikace testovacích dat pro
zátěžový test, která je vytvořena vanalýze. Testovací data musí být pořízena vdostatečném
množství a struktuře, která vychází z koncepce scénářů pro zátěžový test. Důležitým krokem je
ověření testovacích dat před jejich použitím (zkušební běh).

Provedení zátěžového testu
. Realizace testů

Vtéto fázi jsou spouštěny jednotlivé běhy zátěžového testu dle navržených scénářů a výsledků

předchozích běhů.

Vyhodnocení zátěžového testu
. Vyhodnoceníjednotlivých běhů zátěžového testu

Každý běh je vyhodnocován formou prezentace výsledků pro pracovníky realizačního týmu (tým
je složen jak : pracovníků Zhotovitele, tak z pracovníků Objednatele). Následně je určen postup
a měřené parametry pro další běh zátěžového testu. V průběhu celého tohoto kroku jsou
vypracovávány reporty pro vedení projektu, které sledují vývoj výkonnosti aplikace adefinice
úzkých míst testované aplikace.

. Závěrečné vyhodnocení zátěžového testu

80
% ČR - Cssz

USTREDI

Křížová 25, 225 08 Praha 5

Po dokončení všech plánovaných běhů zátěžového testu je zpracována závěrečná zpráva, kde je zátěžový
test vyhodnocen z hlediska úspěšnosti splnění cílů zátěžového testu, které byly definovány v analýze pro
zátěžový test. Zároveň jsou zde uvedeny výsledky významných běhů a definice nalezených úzkých míst ve
výkonnosti testované aplikace.

Zhotovitel disponuje, na základě dlouholetých zkušeností, potřebnými znalostmi v oblasti přípravy,
provedení a vyhodnoceni zátěžového testu s využitím profesionálního software i s využitím freewarových
nástrojů. V tomto případě předpokládáme využití nástrojů JMeter a SoapUI.

Při větším množství opakování těchto testů je možné vytvořit výkonnostní benchmark vzávislosti na
implementovaném hardware. Předpokladem pro testy ověření výkonu je plná funkčnost systému v rámci
funkčního testování a plná integrace v rámci integračního testování.

Hodnoty získané z tohoto testu se využijí pro ladění a optimalizaci aplikace, popř. jako výchozí bod pro
změnu konfigurace stávajícího hardware.

Testy ověření výkonu je potřeba sohledem na jejich náročnost dobře projektové plánovat avěnovat
jejich přípravě dostatečnou pozornost. Testyjsou připravovány specialisty, kteří s tímto typem testů mají
již zkušenosti a jsou schopni predikovat možné výsledky testu.

Zátěž aplikace bude v průběhu testu simulována pomocí zátěžových skriptů, které vzniknou dle
vybraných uživatelských transakcí (funkcí aplikace). Výběr transakcí pro zátěžový test vznikne na základě
dohody Zhotovitele a Objednatele. Při zátěži testované aplikace bude prováděný monitoring dob odezev
vybraných transakcí testované aplikace a sledování vytížení CPU, paměti, I/O operací a dalších
potřebných zdrojů. Dosažené výsledky budou při vyhodnocení ZT porovnávány proti stanoveným
výkonnostním Iimitům.

3.4.3.4 Technické Bezpečnostní (Penetrační) testy
Cílem penetračních testů je prověření a posouzeni technické úrovně zabezpečení implementovaného
systému.

Penetrační testy proběhnou nad testovacím prostředím Obiednatele, a to v následuiícím členění:

. Penetrační test Webservíces (webových služeb)
0 Otestování WS/SOAP rozhraní systému
0 Poznámka: do této fáze testu byla zařazena rovněž rozhraní „souborového typu" (tj.
případy kdy dochází pouze ke generování a následnému publikování souborů
v definovaných datových formátech)

. Penetrační test www rozhraní
o Otestování www rozhraní dostupného uživatelům systému

Postupy používané při testování webových aplikací se opírají o průběžně aktualizovanou interní
metodiku, dlouhodobě vycházející z doporučení a „de-facto" standardů OWASP, http://www.owasp.org.

Při testech je v prvé řadě zapotřebí kombinačních schopností a zkušenosti testera, nicméně existuje
množství nástrojů (i volně dostupných), které postup testování značně usnadňují a zefektivňují.

81
% ČR-ČSSZ

asmat

Křížová 25, 225 08 Praha 5

Pro testování budou využity různé nástroje pro analýzu a následné ověření různých specifických slabin
systému. Penetrační test je prováděn v konečné fázi testování, před započetím uživatelských
akceptačních testů.

3.4.3.1 Akceptační testy
Akceptační testy budou prováděny v závěrečné fázi projektu. Plný rozsah akceptačních testů bude
stanoven až v průběhu testování, v základní podobě ale bude pokrývat předem definovaná akceptační
kritéria. Akceptační testy budou vytvářeny na základě testovacích scénářů ze systémových a integračních
testů. Vytvořená sada akceptačních testů pak podléhá schválení Objednatele. Výstupem provedení
akceptačních testů bude závěrečný Protokol o výsledku akceptačních testů se seznamem nalezených
neshod a jejich závažnosti.

3.5 Školení

Závazné podmínky:

Vpřípadě potřeby Objednatele musí Zhotovitel zabezpečit vyškolení všech určených pracovníků
pracujících s aplikací.

Objednatel plnění dle tohoto článku (3.5 Školení) akceptuje na základě akceptačního řízení.

Zhotovitel jako součást své nabídky předloží závazný podrobný popis plnění dle shora uvedeného:
Zhotovitel minimálně popíše:

. Návrh způsobu školení;
. Příklady školících materiálů.
(doplní Zhotovitell- Zhotovitel doplnil, viz kapitoly níže.

3.5.1 Návrh způsobu školení
Školení APV NEM

Vzhledem ke skutečnosti, že APV NEM představuje existující aplikaci, budou školení realizovaná v rámci
plnění této Smlouvy pojímána jako školení rozdílová, zaměřená na nově zapracovávané úpravy z titulu
legislativnich změn, požadavků metodiků a návrhů uživatelů.

Protože aplikaci NEM využívá cca 6 500 uživatelů na všech OSSZ, PSSZ a MSSZ Brno a sohledem na
dosavadní zkušenosti Zhotovitele s rozvojem aplikace a na něj navazující osvědčený způsob seznamování
uživatelů 5 realizovanými úpravami, předpokládá Zhotovitel školení uživatelů primárně formou distribuce
aktualizované Uživatelské příručky doplněné průvodní informací o účelu a rozsahu změn.

Tato forma školení je ověřená v praxi a představuje, zejména sohledem na Objednatele, nákladově
efektivní způsob předávání potřebného know-how. Distribuce probíhá cestou intranetu ČSSZ a umožňuje
velmi flexibilně reagovat na potřeby koncových uživatelů (např. upřesnit text návodu, pokud se vyskytne

82
% ČR - ČSSZ

USTREDI

Křížová 25, 225 08 Praha 5

větší počet dotazů k dílčímu tématu). Uživatelé mají možnost ověřit si nové nebo upravené postupy /
funkčnosti aplikace na školícím prostředí.

Bude-Ii rozsah implementovaných změn nasazovaných do produkčního prostředí v rámci jedné release

vyhodnocen ze strany ČSSZ jako mimořádný, poskytne Zhotovitel plnění ve formě školení školitelů.
Zhotovitel předpokládá využití této možnosti čtyřikrát v průběhu trvání Smlouvy.

Zhotovitel v rámci plnění vytvoří následuíící školicí materiály:

. Aktualizovaná Uživatelská příručka — proběhne vždy, v případě školení školitelů bude uživatelská
příručka uvedena jako doplňkový materiál pro účastníky školení, ve kterém si účastnící mohou
dohledat další informace.

. Prezentace funkcí aplikace — pro školení školitelů. Bude vytvořena ve formátu PowerPoint. Bude
zahrnovat vysvětlení funkcionalit aplikace a vazeb mezi nimi.

. Zadání příkladů pro účastníky školení — pro školení školitelů. Bude součástí prezentace
PowerPoint včetně popisu základních kroků formou sledu se zvýrazněním vstupních polí,
schémat apod. Vlastní předvedení funkcionality provede školitel v aplikaci ve školícím prostředí.

' Příprava dat pro praktická cvičení — pro školení školitelů. Účastnící školení provedou praktická
cvičení se zadáním dat. Každému účastníkovi školení nebo skupině účastníků budou přiděleny
identifikátory (interval) dat, aby si účastnící omylem vzájemně nepřepisovalí data a aby výsledky
praktických cvičení bylo možné zkontrolovat.

Dále se Zhotovitel bude podílet na přípravě textu průvodní informace kaktualizované uživatelské
příručce určené uživatelům aplikace NEM, bude-Ii oto požádán. Průvodní informaci vytváří Objednatel.

Školení APV D_STAT

Vpřípadě APV D_STAT předpokládá Zhotovitel jako primární formu školení uživatelů využívat opět
distribucí aktualizované Uživatelské příručky doplněnou průvodní informací o účelu a rozsahu změn.
Vzhledem ke specializovanému účelu a počtu uživatelů této aplikace Ize na výzvu Objednatele provést
přímo i standardní školení uživatelů aplikace s využitím obdobných školicích materiálů, jako je uvedeno
výše. Počet těchto školení Zhotovitel nelímituje.

Vedle školení školitelů, bude-Ii to povaha implementovaných úprav vyžadovat, proběhne také zaškolení
správců a provozovatelů dodávaných aplikací. Oba typy školeníjsou blíže charakterizovány níže.

3.5.1.1 Školení školitelů
Školení školitelů bude provedeno ve školícím prostředí Objednatele. Vjedné učebně bude maximálně 20
účastníků. Obsah školení bude zaměřen na:

. seznámení s účelem aplikace,
. seznámení se strukturou uživatelské příručky a návod jak s ní pracovat,
o popis vazeb na spolupracující aplikace,
. popis datových toků,
. popis procesů objednatele, které aplikace podporují,
. základní pravidla ovládání aplikace,

83
I-liilillm-l-m % ČR-ČSSZ
ÚSTŘEDI

Křížová 25, 225 08 Praha 5

. jednotlivé funkce aplikace a její výstupy,
o provedení praktického cvičení pro každou školenou funkci,
. dotazy školenců k dané funkcionalitě,
. postup v případě nestandardních situací a chyb.

Jednotlivé funkce aplikace budou demonstrovány školitelem, poté budou následovat praktická cvičení,
kdy si každý účastník školení vyzkouší použití dané funkcionality aplikace.

Za Zhotovitele se zúčastní vkaždé učebně vždy 2 školitelé. Jeden přednáší a demonstruje příklady
postupů, druhý pomáhá účastníkům školení 5 prováděním praktických příkladů.

Požadovaná součinnost: požadujeme zajistit účast odpovědných osob Objednatele (školitelů -
metodických garantů aplikací apod.) pro zodpovídání dotazů účastníků školení na metodické postupy.
Dále požadujeme zajistit učebnu vybavenou technikou pro příslušný počet účastníků připojenou na
školicí prostředí.

3.5.1.2 Školení správců a provozovatelů IKT

Školení správců a provozovatelů bude provedeno ve školícím prostředí Objednatele.

Školení bude zaměřeno na:

. celkový stručný popis aplikace a jejich vzájemných vazeb se zaměřením na popis rozhraní,
. základní softwarové komponenty,

. popis toků dat,

o popis činnosti administrátora databáze,
. popis činnosti administrátora aplikačních serverů,
. kontrola logů,

. instalace aplikace,

. seznam parametrů a jejich nastavení pro různá prostředí (testovací, školicí, provozní),

. restart aplikace,

. nástroje monitoringu,
. postupy pro známé nebo očekávané problémové situace,
. organizační struktura podpory, způsob komunikace, role a odpovédnosti.

3.5.2 Příklady školicích materiálů

3.5.2.1 Školicí prezentace

Ukázka školící prezentace v nástroji PowerPoint:

84
w ČR - ČSSZ

USTREDI

Křížová 25, 225 08 Praha 5

mm . a!» „ *\

, \.

ll/l „psu M \ \\

loan-u / \ř ? \\

| m \

Kmtmlydivky &

. mmm

-mmuw

- mu.—“
- Mad—“*umva—ÚM

. m“
' Mn.—nh..—

. mmm
- u—M—wůn—M

. - wan—““Mo“

. WII!

- D““ I!

o M.-

- Mn.—___“

M whatnot.“ """"

Obrázek 25 - Ukázka školící prezentace

3.5.2.2 Další školicí materiály
Mezi další školicí materiály lze zahrnout uživatelskou a provozní dokumentaci. Dokumenty budou dodány
elektronicky ve formátu MS Word pro připomínkování, výsledné akceptované verze dokumentů budou
dodány ve formátu PDF. Obsah a příklady těchto dokumentů jsou uvedeny v kapitolách 3.3.3.5
Uživatelská příručka a 3.6.2 Popis a příklady provozní dokumentace.

85
W ČR-ČSSZ

Osman

Křížová 25, 225 08 Praha 5

3.6 Nasazování do produkce

Závazné podmínky:

Zhotovitel musí zajistit následující aktivity:

Naplánování nasazení do produkce;
Přípravu instalačního postupu;
Úpravu provozní dokumentace;
Definovat finální konfiguraci pro produkční prostředí;
Podporu finálního produkčního nasazení.

Objednatel plnění dle tohoto článku (3.6 Nasazování do produkce) akceptuje na základě akceptačního

řízení.

Zhotovitel předloží podrobný závazný popis plnění dle výše uvedeného.
Zhotovitel minimálně popíše:

. Návrh způsobu nasazování do produkce;
. Příklady relevantní dokumentace;
. Popis provozní dokumentace.

(dop/ní Zhotovitel) - Zhotovitel doplnil, viz kapitoly níže.

3.6.1 Návrh způsobu nasazování do produkce

Instalace a testování proběhne dle předem schváleného harmonogramu. Harmonogram bude obsahovat
jednotlivé činnosti, milníky a zodpovědné osoby.

Vytvořené řešení bude postupně (v závislosti na harmonogramu jednotlivých činností) umístěno do tří
běhových prostředí Objednatele: integračního, testovacího (školicího) a produkčního (provozního).
Vintegračním (resp. testovacím) prostředí proběhnou příslušné testy, než bude rozhodnuto o
nainstalování do testovacího (resp. produkčního) prostředí.

3.6.1.1 Postup instalací a testů
Instalace a testy budou probíhat v následujícím pořadí:

. prostředí Zhotovitele
o jedná se o interní testy Zhotovitele, nevyžaduje součinnost s ČSSZ.

. integrační prostředí Objednatele
o vyžaduje součinnost administrátorů Objednatele v souvislosti s instalací aplikace,
0 je třeba zajistit přístup testerů Zhotovitele k otestování aplikací, pokud nebude
provedeno přímo zaměstnanci ČSSZ,
0 po odzkoušení funkčnosti aplikace bude předáno do testovacího prostředí Objednatele
k dalším testům.

86
% ČR - ČSSZ

Osment

Křížová 25, 225 08 Praha 5

testovací (školicí) prostředí Objednatele - zde dojde v závěrečné fázi i k otestování zaměstnanci
Objednatele

o instalaci aplikace provádí administrátoři Objednatele,
o je třeba zajistit přístup testerů Zhotovitele k otestování aplikací, pokud nebude

provedeno pouze zaměstnanci Objednatele,
0 po odzkoušení funkčnosti aplikace se předá do produkčního prostředí.
produkční prostředí objednatele
o instalaci aplikace provádí administrátoři Objednatele,
0 pro kontrolu funkčnosti aplikace a správného nasazení do produkce proběhne

vyhodnocení běhu aplikace na základě dodaných logů (viz níže).

3.6.1.2 Otestování nasazení do produkce
Do produkčního prostředí bude nainstalovaná Objednatelem akceptovaná aplikace, která projde všemi
definovanými testy na integračním a testovacím prostředí.

Po nasazení do produkce bude ověřeno, zda ie aplikace nainstalovaná správně, a to minimálně v rozsahu:

Ověření běhu aplikace pomocí dodavatelem implementovaného standardního rozhraní (viz
standardy ČSSZ: „Pravidla pro ověření živosti aplikací" dokument
std_metodikavyvoje_apv_1_0_19.doc — provedou administrátoři Objednatele).
Ověření vybraných hlavních funkčností (garantem APV za Objednatele nebo jím pověřenou
osobou).
Vyhodnocení běhu dle zaslaných logů za definované obdobi Zhotovitelem.

Bližši podrobnosti budou součásti harmonogramu pro nasazení do produkce.

87
W ČR - Cssz
USTŘEDI

Křížová 25, 225 08 Praha 5

3.6.2 Příklady relevantní dokumentace
3.6.2.1 Příklad obsahu dodávané Administrátorské příručky

1. Úvod .....................................................

1.1. Co pěkní-la obuhuje ahomnje min..
1.2. Jak pěšina-.n pmů'va ......................

1.3. Pojmy linky .....................................................................................................

2. Popi: Emba: qﬂikxe včetně zamění do Micha synům .....................

2.1. cmmmeMv—m .....................................................

2.2. Spolwaxující směny ...........................................................................

2.2.1. Nmné vy‘udwné obi-ni.......................................................................

2.3. Sem-m tvý—jednotlivým mírní . ..................... .

2..4. Ovlívňwmé mian)- ..................................................

2.1 Ovlivňujídaynény ................................................
2..6 Dulšíobluů .....................................................

3. Alchitekmn synům ...........................................

3.1. zklidní komponenty udúneknuy... .....................

.4..1 Popúzwnmulmjedn..
4.2.vaýnwhcí1euloďnn

--Í-Í6.1. Pmshnmwkxeapdňůaqaoml.. ..................

aJ112.11.191.996.2. Sladovim'pn'banaqwm ...........................................

6..3 Návodmpměšaíapúvmúmom ..............................

6.4. KmunihmsávkmýmpwcmCDAF) ..................... ..

6...41 Loguv'ui ....................................................................................................

s a *! vyzvali-.. ...-......

Obrázek 26 - Příklad obsahu dodávané Administrátorské příručky

88
ma ČR - Cssz
ÚSTŘEDÍ

Křížová 25, 225 08 Praha 5

3.6.2.2 Příklad obsahu dodávané Instalační příručky

M .............................................................................................................................. 3
Sanga: obxiﬁn'l ................

1. Uvod ........................................................

1.1. Copíínůaobuhuje abnmujemčm..„
1.2. III: pšírnů'upmňvn .............................................................................

1.3. Pojmy luky ..............................................................
2. Sym'unm‘é poč.-davky inn-lm: .........

2.1. Ziudxňbompomyudúmhmy.. ...8

3. Imm ............................................................................................. 10

3.1. Maeda-bb! ............. .. ................................................. 10

3.1.1. DoplňbuviimulxeDB .. .11

3.2. WWW meu ..................... ...12

3.2.1. mmmmmmm... ....................... ...12

3.2.2. KMM instancí J'Bou................................... 15

3.2.3. Manipulace ................................ 16

3.2.4. Wai Wilma mun J'Bou .. 17

3.2.5. Upgrde mlíka'm'ho unreal IBN—t .................... 20

3.3. Knuﬁgunm Qh'kace .......................................... 20

3.3.1. Knnňgmaoepíipqianíkdlmán 21

3.3.2. Konﬁmoeobnlnichtodaﬂni... 22

Dohá ................................................................... ...24

4.1. Divknvé mm ........................................ ..24

4.1.1. imullSevicebct ............ 24

4.1.2. Mám—101191:.............. 25

4.1.3. sm autehuuncebn..„ 25

4.1.4. 5m mmdmtmcebn ..... 27

4.2. Legend minty ......................... 29

4.2.1. impugnllog ....... ..29

4.3. logování do Muňky. ........................................................................... „33

4.4. Emmi MS Manet Emlera na Kuben: martina vůči WebSealu ...... ...34

4.4.1. PW počít-četlo důvěry-hnaném ......................................... ...35

4.4.2. Katmai Negev—né ovšqu' eminem WW1 ........................................... 36

Obrázek 27 - Příklad obsahu dodávané Instalační příručky

89
% ČR - ČSSZ

USTREDI

Křížová 25, 225 08 Praha 5

3.6.2.3 Příklad obsahu dodávaného dokumentu Release notes

Release NEM.004.005.015

Projekt: APV-NEM

Prior—vi:—

Dneí W

PRODUCTCODE:
Obsah adresářů

DOC

Release _ _004_005_015.doc

NEM_'nstdmi_pthlcka_v_4_5_15.doc

NEM _priucka_v 4_5_15.doc

v doc

NEM _ _ v 4 5_15.doc

NEM v_4_5 15.600

Popis_vern v_4_5_15.xls

Popis _v_ _ _

NEM_INNP Prooesy_v_4_5_13.dnc

DOC!

NEM uzlv_skol_pvi\u:h_ v_4_5_15.pdf dokumentaceoblsti INNP
dokunemaeeoblasﬁ NEM
NEM v mehsti NEM

NEMZtlziv_skol_ptwoka_dopH—kyPPMZOIO_v/_4
5 l5

DOClFunlu'a-li

specificaogvj 5 151‘»

DOC!

NEM _ model_ _0_NEM.doc

v_4_5_15.z'p

DOC/Dokumentace rozhrani

Dokumemaoe_ v_4_5_15.w

DOC! Testovací 4.5.I5_doc
Testovaci v 4 5 15.doc
DOC!

NEM_ WS

Pr'ůoha A — WSDL
DOC!

Obrázek 28 — Příklad obsahu dodávaného dokumentu Release notes

3.6.3 Popis provozní dokumentace
Při nasazení do produkce bude stěžejním dokumentem harmonogram nasazení do produkce. Ostatní
dokumentace bude ve stejném rozsahu, vjakém byla již dodána při nasazování do testovacího a
integračního prostředí objednatele.

Harmonogram nasazení do produkce obsahuje minimálně:

. předpoklady nasazení,
. časový rozvrh,

90
W ČR - ČSSZ

ÚSTŘEDI

Křížová 25, 225 08 Praha 5

. odhady potřebných zdrojů,
. jednotlivé činnosti,
. návaznosti činnosti,
. milníky,
. Role a konkrétní osoby za jednotlivé činnosti a události zodpovědné.
Ostatní dokumentace bude minimálně v následujícím rozsahu:

. Provoznídokumentace:
. Administrátorská příručka
. Instalačnípříručka
. Release notes (obsah uvolňované verze)

. Programátorská dokumentace
. Uživatelská dokumentace

Popisjednotlivých dokumentů je součástí dalších kapitol.

Dokumenty budou dodány elektronicky ve formátu MS Word pro připomínkování, výsledné akceptované
verze dokumentů budou dodány ve formátu PDF.

3.6.3.1 Administrátorská příručka
Administrátorská příručka je určena především pro správce a operétory dodávaného systému, kteří jej
provozují, dohlíží na jeho provoz a udržujíjej.

Administrátorská příručka bude obsahovat zejména:

. seznámení s účelem aplikace,
' začlenění aplikace v kontextu aplikační architektury, rozhraní systému,
. komponenty aplikace,
. požadavky na vyškolení a odborný výcvik uživatele,
o popis zabezpečení aplikace a rozsahu oprávněníjednotlivých skupin uživatelů a jejich správy,
. postup zálohování a obnovení dat aplikace,
. seznam parametrů aplikace a aktuální hodnotyjejich nastavení pro rutinní provoz,
. pokyny pro zpětnou vazbu (hlášení neshod, reklamací apod.),
- postup řešení mimořádných stavů,
. popis známých chybových stavů,
. přehled notifikaci pro administrátora,
. auditní záznamy aplikace.

3.6.3.2 Instalační příručka
Instalační příručka je určena administrátorům systému a slouží jako manuál při počáteční instalaci
systému ijeho aktualizaci.

Příručka obsahuje minimálně:

91
% ČR-ČSSZ
ÚSTŘEDI

Křížová 25, 225 08 Praha 5

. předpoklady instalace,
. instalační postupy,
. přípravu databáze,
. samotnou instalaci aplikace,
. konfigurace logování,
. základní ověření funkčnosti aplikace.

3.6.3.3 Release notes
Dokument Release notes je průvodní dokument sloužící jako stručný přehled toho, co dodávaný balíček
s aplikací obsahuje.

Release notes obsahuje minimálně:

0 název aplikace,
0 číslo verze,
. seznam dodávaných souborů v dodávce.

92
%] ČR - ČSSZ

USTREDI

Křížová 25, 225 08 Praha 5

3.7 Požadované součinnosti

Vrámci této kapitoly Zhotovitel závazně definuje požadované součinnosti ze strany ČSSZ pro vývoj a

nasazení nového aplikačního vybavení.

Zhotovitel def/nuje potřebnou součinnost v následující struktuře:

. Popis součinnosti;

. Popis role na straně ČSSZ;
. Rozsah očekávané součinnosti (v ČD - dále jen „ČD", 1 ČD odpovídá 8 člověkohodinám).

Další popis součinnosti
. Případné další požadavky na součinnost

(dopln/Zhotovitel)- Zhotovitel doplnil, viz kapitoly níže.

3.7.1 Popis součinnosti

Požadovaná součinnost se liší dle jednotlivých etap / činností v rámci plnění Dílčích smluv. Dáleje uveden
seznam dílčích fázi projektu a konkrétních požadavků.

3. 7.1.1 Zahájení projektu
. Určení zodpovědných pracovníků na straně Objednatele (obsazení rolí).
. Schválení podrobného harmonogramu projektu.
. Účast na zahajovací schůzce projektu.

3. 7.1.2 Řízení projektu
. Účast na pravidelných jednáních o stavu projektu (1x za 2 týdny).
. Účast na pravidelných řídících poradách projektu (1x měsíčně, pokud budou dohodnuty).
. Plnění součinnosti v rozsahu a termínech dohodnutých na jednáních projektových týmů (dle
požadavků ze zápisu zjednání).

3. 7.1.3 Analýza a návrh řešení
. Spolupráce odborných garantů při definici procesů, funkční specifikaci, návrhu uživatelských
rozhraní.
. Poskytnutí dokumentace k relevantním existujícím datovým rozhraním.
. Schválení podrobného plánu a harmonogramu analytické části projektu.
. Provedení finální revize a akceptace výstupů týmů.

93
W ČR - ČSSZ

ÚSTŘEDÍ

Křížová 25, 225 08 Praha 5

3. 7.1.4 Implementace a integrace s ostatními APV
. Zajištění implementace definovaných datových rozhraní na straně okolních systémů.
. Zajištění integračního a testovacího prostředí včetně testovacích dat.

3. 7.1.5 Testování
. Schválení podrobného plánu a harmonogramu testů.
. Zajištění integračního / testovacího prostředí.
. Provedení uživatelských testů.

3. 7.1.6 Dokumentace
. Provedení finální revize a akceptace výstupu.

3. 7.1. 7 Školení
. Zabezpečení účasti školených osob ve stanovených termínech.
. Zajištění přípravy a provozu školicího prostředí.

3. 7.1.8 Příprava provozu APV
. Spolupráce při nasazování APV do produkčního prostředí.

3.7.2 Popis role na straně ČSSZ

Vedoucí projektu Objednatele
Vedoucí projektu Objednatele spravuje proces plnění povinností Objednatele vyplývajících ze smlouvy.
Jako vedoucí pracovník má zodpovědnost za kontrolu a správu projektu. Musí zajistit zejména zdroje a
koordinaci sdalšími dotčenými útvary organizace Objednatele, aby v daném časovém rámci mohly
vzniknout dohodnuté podklady. Podrobný popis činnostíje uveden v kapitole 3.1 Projektové řízení.

Datový specialista
Jeho úkolem je:

o poskytnutí informací o struktuře dat stávajícího systému ČSSZ,
. vytváření podpory bezpečnosti informací,
. připravuje podklady a požadavky na nový systém z pohledu datového obsahu, podílí se na

přípravě podkladů pro rozhodnutí o akceptaci.

Administrátor systému
Podílí se na:

o návrhu technické a aplikační architektury systému,
o přípravě podkladů pro funkční i nefunkční požadavky Objednatele,
. instalaci systému v prostředí Objednatele,
' instalaci a implementaci nových verzí systému (ve spolupráci se zhotovitelem).

94
W ČR - ČSSZ

05mm

Křížová 25, 225 08 Praha 5

Odborní garanti jednotlivých APV
Podílí se na:

0 Úvodní analýze projektu,
. schvalujíjednotlivé fáze Realizačních projektů,

. podílí se na testování APV.

Klíčový uživatel systému
Jeho hlavní úkolyjsou:

. Podílí se na návrhu řešení, provádítestování systému.

3.7.3 Rozsah očekávané součinnosti (v ČD)
Součinnost je uvedena jako maximální pro období plnění veřejné zakázky.

. Vedoucí projektu objednatel:
. Datový specialista:
. Odborní garanti jednotlivých APV:
. Klíčový uživatel systému:

95
W ČR - Cssz
05mm

Křížová 25, 225 08 Praha 5

4 Zajištění aplikační podpory APV NEM a D_STAT

Úvod:

Poskytování aplikační podpory zahrnuje následující dílčí plnění:

. Převzetí do servisu
. Poskytování podpory APV NEM a D_STAT

4.1 Převzetí do servisu
Závazné podmínky:

V rámci převzetí aplikační podpory do servisu se Zhotovitel seznámí s APV NEM a D_STAT a proškolí své
členy realizačního týmu před začátkem poskytování aplikační podpory APV NEM a D_STAT takovým
způsobem, aby byl schopen zajistit poskytování veškerých služeb dle předmětu plnění této Smlouvy.
Zhotovitel v rámci této oblasti předloží podrobný návrh, jak bude převzetí do servisu realizovat. Zároveň
v této části vydefinuje požadavky na součinnost Objednavatele. Objednavatel není povinen při převzetí
do servisu zajistit součinnost 3. stran — např. dodavatelů Objednavatele.

4.1.1 Rozsah převzetí do servisu

V rámci této kapitoly Zhotovitel závazně popíše:

. Podrobný návrh převzetí do servisu;
. Potřebnou součinnost v následujícístruktuře:

0 Popis součinnosti;
0 Popis role na straně ČSSZ;
0 Rozsah očekávané součinnosti (v ČD).
. Organizační zajištění.

(doplní Zhotovitel) - Zhotovitel doplnil, víz kapitoly níže.

4.1.1.1 Podrobný návrh převzetí do servisu
Vzhledem ke skutečnosti, že je Zhotovitel vsoučasné době dodavatelem a zároveň poskytovatelem
aplikační podpory jak APV NEM, tak APV D_STAT, není pro potřeby zajištění aplikační podpory obou
aplikací potřeba činit žádné kroky, což představuje významnou úsporu na straně Objednatele.

Členové realizačního týmu jsou tak již nyní schopni zajistit poskytování veškerých služeb dle předmětu
plnění této Smlouvy. Vsouvislosti smožným maximálním objemem plnění předpokládá Zhotovitel
rozšíření realizačního týmu, které bude probíhat vrežii Zhotovitele a nevyvolá tak žádné zásadní
požadavky na součinnost ze strany Objednatele svýjimkou možných organizačně technických opatření
kzajištění přístupu nových členů na pracoviště Objednatele (zavedení nového uživatele, nastavení

96
my] ČR - Cssz

UsrREnt

Křížová 25, 225 08 Praha 5

přístupových práv a vydání karty). Zadavatel předpokládá rozsah těchto součinnostních požadavků (tj.
počet nových členů týmu) v řádu jednotek za celou dobu trvání kontraktu.

4.1.1.2 Potřebná součinnost
Není nutná další součinnost.

4.1.1.3 Organizační zajištění
Nejsou kladeny žádné nároky na organizační zajištění.

4.2 Poskytování aplikační podpory APV NEM a D_STAT

Závazné podmínky:

Podpora aplikace bude zajištěna na odstraňování chyb na základě SLA definovaných níže.

. Zhotovitel řeší všechny nalezené chyby v aplikaci pod domluvenými SLA (všechny časy jsou
počítány na pracovní dny a čas v České republice):
0 Zodpovídá za analýzu, opravu a test chyb.
0 Zodpovídá za plánování oprav do balíčků v návaznosti na SLA — Finální termín nasazení
potvrzuje ČSSZ.
o Předává opravenou chybu s průvodkou popisující — kdo, jak provedl test, jak byla chyba
opravena a co bylo její příčinou.
0 Je povinen opravovat příčinu i následek chyby (opravy pouze následků a neopravování
příčin budou negativním kritériem hodnocení).
0 Je povinen dodat testovací data pro případný retest chyby Objednatelem.
0 Je povinen dodržovat standardy vývoje definované Objednatelem.

. Zodpovídá za úplnost a korektnost opravných balíčků dodávaných na provoz.
. Zodpovídá za včasné informování ČSSZ o možných dopadech opravy na součinné aplikace.
. Zodpovídá za aktualizaci automatizovaných testů (pokud existují).
. Musí poskytnout plnou součinnost pro nasazení oprav na produkci a zvýšenou podporu po

nasazení pro provoz IT.
. Zodpovídá za aktualizaci veškeré dokumentace ovlivněné opravou.
. Zajišťuje podporu uživatelů.
. Řeší management defektů v nástroji na sledování chyb a eskalaci problémů.
. Připravuje podklady na status meetingy.
. Reportuje plnění SLA na měsíční úrovni (připravuje podklady pro vyhodnocení kontrolních

parametrů).
. Účastní se a vede aktivity v procesech problém managementu.
. Poskytuje součinnost pro opravy v ostatních aplikacích.
. Školení uživatelů:

0 Příprava školících materiálů pro školení uživatelů.
0 Příprava dat a prostředí pro školení uživatelů.
0 Realizace školení uživatelů.
0 Vyhodnocení zpětné vazby.

97
w ČR — ČSSZ

ÚSTŘEDI

Křížová 25, 225 08 Praha 5

. Předání aplikační podpory v případě ukončení Smlouvy se řídí ustanovením Smlouvy.

4.2.1 Návrh SLA
Závazné podmínky:

Zhotovitel se zavazuje dodržovat definovanou úroveň služeb pro řešení chyb (incidentů):

„ Kategorie c

— Reakce Odstranění Reakce Odstranění Reakce Odstranění

1 hod 12 hod 5 hod so hod 20 hod 1oo hod

doba

Reakční dobou v tomto případě Objednatel rozumí převzetí chyby, provedení úvodní analýzy problému a
předání informaci o důvodu chyby a předpokládaném řešení.

Pro účely dodržování výše uvedených parametrů reakční doby a doby odstranění závady (dobou pro
odstranění závady se rozumí doba, která započne běžet časem předání incidentu Zhotoviteli a bude
ukončena v čase předání vyřešeného incidentu zpět Objednateli) je dále uvedeno rozdělení závad do
kategorií:

0 za závady kategorie A budou považovány kritické chyby, kterými se rozumí zejména havárie,
poruchy, chyby, vady vedoucí k přerušení provozu nebo jeho kritickému omezení a znemožňující
používání a využívání APV nebo databází nebo systémového vybavení nebo hardware k účelu, k
němuž je určeno,

. za závady kategorie B budou považovány hlavní chyby, kterými se rozumí poruchy, chyby, vady,
které způsobují provozní problémy, ale neznemožňují používání a využívání APV nebo databází
nebo systémového vybavení nebo hardware k účelu, k němuž je určeno, a lze je dočasně řešit
organizačními nebo technickými opatřeními,

. za závady kategorie C budou považovány vedlejší chyby, kterými se rozumí méně závažné
poruchy, chyby, vady nebo diference APV, které nemají vliv na používání a využívání APV nebo
databází nebo systémového vybavení nebo hardware k účelu, k němuž je určeno.

Lhůty se ve věcech reakčních dob pro řešení incidentů počítají v rámci pracovní doby Objednatele, tedy
běh lhůty se pozastavuje na konci každého pracovního dne a obnovuje na počátku pracovní doby
následujícího pracovního dne. Pracovní doba se pro tento případ definuje od 7:00 do 17:00. Pozastavení
počítání lhůty s koncem pracovní doby neplatí pro řešení chyby kategorie A.

Není-Ii vzájemně dohodnuto jinak, lhůta pro měření doby reakce a doby odstranění incidentu započne
běžet časem předání incidentu Zhotoviteli a bude ukončena v čase předání vyřešeného incidentu zpět
Objednateli. Celková doba odstranění je pak součet všech časových dob, po které byl incident v řešení na
straně Zhotovitele. Zcelkové doby odstranění incidentu jsou vyloučeny časové doby, kdy Zhotovitel
prokazatelně nemohl pokračovat v řešení incidentu z důvodů, které nebyly jím způsobené (např.
Zhotovitel čeká na doplnění relevantních informací k incidentu od Objednatele apod.). Pro výpočet lhůt
jsou určující časové záznamy v systému Helpdesk Objednatele k danému incidentu.

98
w ČR - Cssz

ÚSTŘEDI

Křížová 25, 225 08 Praha 5

Předávání incidentů bude probíhat dle požadavku Objednatele prostřednictvím helpdesku Objednatele,
přičemž Zhotovitel je povinen incidenty z helpdesku Objednatele automaticky přijímat.

4.2.1.1 Dodatečné metriky
Závazné podmínky:

Hodnocení aplikační podpory musí dále zohledňovat následující kritéria:

0 Vyhodnocení procenta chyb, u kterých nebyla opravena příčina.
Vyhodnocení opravy chyb, kde nedošlo k úspěšné opravě, nebo byla zavlečena nová chyba.

. Vyhodnocení počtu nekorektních balíčků — chybně dodané balíčky, nebo balíčky které vyžadovali
nestandardní zásah provozu IT (nešli nasadit podle dodaného postupu).

0 Vyhodnocení dodržování vývojových standardů.

4.2.2 Algoritmus vyhodnocení aplikační podpory
Úvod:

Tato kapitola popisuje způsob, jakým bude vyhodnocována definovaná úroveň služeb v oblasti aplikační
podpory.

Závazné podmínky:

Vyhodnocování bude probíhat na měsíční bázi.

Vpřípadě neplnění vyhodnocovaných kritérií, můžou být uplatněny definované sankce na platbu za
aplikační podporu. V případě hrubého neplnění SLA je možné odstoupení od Rámcové smlouvy nebo
Dílčí smlouvy. Hrubým neplněním SLA je například neplnění definované úroveň služeb v oblasti aplikační
podpory u kategorie závady A, a to v rozsahu minimálně dvakrát v kalendářním měsíci nebo například
opakované nedodržování dodatečných SLA metrik.

SLA reakční doby pro řešení chyb A, B, C je definováno vkapitole 4.2.1. Pro účely hodnocení se
vyhodnocuje splnění reakční doby a doby vyřešení chyby pro každý jednotlivý případ a penalizace za
nesplnění časových limitů probíhá dle ustanovení Rámcové smlouvy.

Vyhodnocení dodatečných metrik:

. V případě, že procento chyb, u nichž nebude opravena příčina, přesáhne 10%, bude v měřeném
období nastaven parametr — SLApříčina : -5 %.

o V případě, že procento chyb, u nichž po nasazení do produkce bude konstatováno, že nedošlo
kopravě, nebo že došlo kzavlečení další chyby, přesáhne 20%, bude vměřeném období
nastaven parametr — SLAzavleč : -5 %.

. Vpřípadě, že počet nekorektních produkčních balíčků přesáhne počet jednoho nekorektního
nasazení za měsíc, bude nastaven parametr—SLAbalíček = -5 %.

. Vpřípadě, že ze strany Objednatele bude vrámci hodnocení aplikační podpory eskalováno
nedodržování vývojových standardů a tato situace se nezmění ani následující měsíc, bude
nastaven parametr — SLAstandardy : -5 %.

99
“\

% ČR-ČSSZ
ÚSTŘEDI

Křížová 25, 225 08 Praha 5

Celkový parametr vvhodnocení aplikační podporv definuieme iako:

SLACelkem = 100% + SLApříčina + SLAzavleč + SLAbalíček + SLAstandardy

Spočítané SLAce'kem bude využito ke snížení měsíční ceny za aplikační podporu podle pravidel
popsaných v Příloze č.2 — Cena plnění.
4.2.3 Rozsah služeb aplikační podpory

V rámci této kapitoly Zhotovitel závazně popíše:

Metodiku řízeni aplikační podpory;
Definici předpokládaných procesů aplikační podpory;
Popis nabízených služeb v rámci aplikační podpory;
Popis požadované součinnosti v rámci aplikační podpory;
Návrh předání aplikační podpory a rozvoje případnému novému dodavateli;
Organizačnizojištěni.

(doplní Zhotovitel) - Zhotovitel doplnil, viz kapitoly níže.

4.2.3.1 Metodika řízení aplikační podpory
Pro zajištění požadovaných služeb aplikační podpory budou definovány a implementovány procesy dle
normy ISO 20000-1 svyužitím postupů a praktik popsaných v rámci ITIL ‘9 2011. Jedná se zejména o
hlavní ITSM (IT Service Management) procesy vymezené voblasti Provoz služeb (Service Operation),
částečně budou využívány též procesy z oblastí Přechod služeb (Service Transition) a Neustálého
zlepšování služeb (Continual Service Improvement), které zajistí dosažení požadované kvality služeb, její
měřitelnost a průběžné zlepšování.

Kvalita služeb bude pravidelně (na měsíční bázi) hodnocena, podkladem pro hodnocení bude reporting z
jednotlivých služeb obsahující výsledky měření klíčových indikátorů jejich kvality. Vývoj hodnot
indikátorů bude sledován v čase a v případě negativních trendů budou navrhována opatření k nápravě.

Pro každý proces potřebný pro zajištění ITSM budou stanovený ieho:

. cíle, vstupy a výstupy a aktivity,
. vazby na ostatní procesy,
. metriky pro měření kvality poskytovaných IT služeb a efektivity ITSM procesů a kvalitativní

hodnoty (Key Performance Indicators),
. zásady auditu a reportingu každého procesu,
. role a odpovědnosti, které role v procesu zastávají.

4.2.3.2 Definice předpokládaných procesů aplikační podpory
V souladu s rámcem ITIL * 2011 by v obecné rovině mělo být v rámci aplikační podpory implementováno
minimálně pět základních procesů: Řízení událostí, Řízení incidentů, Plnění požadavků, Řízení problémů

100
W ČR — ČSSZ

ÚSTŘEDI

Křížová 25, 225 08 Praha 5

a Řízení přístupů. Za účelem sledování a zvyšování kvality poskytovaných služeb je třeba dále
implementovat procesy Měření služeb a Vykazování služeb.

ZObjednateIem specifikovaných požadavků na aplikační podporu a dalších podkladů vyplývá, že
Objednatel nepožaduje implementaci následujících procesů:

Řízení událostí: cílem procesu je zajistit sledování událostí, jejich vyhodnocování a zajištění
odpovídající reakce na ně. Typicky se jedná o implementaci a provozování dohledového a
monitorovacího systému. Zhotovitel předpokládá, že proces zajišťuje Objednatel vlastními
prostředky v souladu se svým Standardem management vrstvy. Zhotovitel očekává, že jedním
zvýstupů procesu řízení událostí budou na základě vyhodnocení událostí identifikované
incidenty, které budou vstupovat do procesu Řízení incidentů.
Řízení přístupů: cílem procesu je vybavit uživatele přístupovými právy tak, aby na jedné straně
měli oprávnění uživatelé přístup k aplikačním funkcím a datům dle svých oprávnění, a naopak,
aby neoprávnění uživatelé přístup neměli. Typicky se jedná o implementaci a provozování
systému pro řízení identit (IDM). Zhotovitel předpokládá, že proces zajistí Objednatel vlastními
prostředky, konkrétně aplikace AAA portál, k němuž bude aplikace připojena vsouladu
s příslušným standardem.

Zhotovitel předpokládá implementaci následuiících procesů aplikační podpory:

Řízení incidentů
Řízení problémů
Plnění požadavků

Měření služeb
Vykazování služeb

Definice těchto procesů uvádíme v následujících tabulkách:

Proces: Řízení incidentů
Cíle:
- minimalizace nepříznivých dopadů detekovaných incidentů
Vstupy: - obnovení normálního fungování systému v nejkratší možné době
Výstupy: - dodržování stanovených podmínek SLA
— incident detekovaný uživatelem nebo v procesu Řízení událostí
- navrhovaná kategorie závady
- potvrzení/ přehodnocení kategorie závady
- příčina incidentu
- náhradnířešení
- finální řešení
- metrikya indikátory

101
.=,

w ČR - čssz

ÚSTŘEDI

Křížová 25, 225 08 Praha 5

Služby a aktivity: HelpDesk Objednatele:
- příjem a zaevidování incidentů od uživatelů a dohledového systému
Vazby na ostatní - návrh kategorizace incidentu Objednatelem
procesy: - předávání incidentů do ServiceDesku Zhotovitele
Metriky a indikátory: ServiceDesk a HotLine Zhotovitele:
- automatický příjem incidentů od HelpDesku Objednatele a jeho

potvrzení
- sledování životního cyklu incidentu a dodržování požadované odezvy
- předávání informací do HelpDesku Objednatele
- eskalace incidentu, pokud je potřebná

Řešení incidentů:
- základnívyhodnocení incidentu a potvrzení/ přehodnocení navrhované

kategorie závady
přiřazení náhradního řešení, pokud existuje
řešení přímých dopadů incidentu (např. příprava DB skriptu pro opravu
dat v databázi)
vyšetření příčiny incidentu — rozhodnutí, zda je příčinou vada aplikace
posouzení vady aplikace — zda se jedná o nový / existující problém
- přiřazení incidentu kexistujícímu problému, nebo specifikace nového
problému a jeho předání do procesu Řízení problémů
- ověření spokojenosti uživatele se způsobem vyřešení incidentu
- vyhodnocení a uzavření incidentu
Řízení událostí:
- přebírání detekovaného incidentu
Řízení problémů:
- vyhledání mezi známými chybami
- vyhledání odpovídajícího náhradního řešení
- založení nového problému
Plnění požadavků
- přeměna incidentu na požadavek, pokud je tak vyhodnocen
Měření služeb:
- předání vstupnich hodnot pro výpočet metrik a indikátorů
Vykazování služeb:
- předání podkladů potřebných pro výkaz služeb

Měsíčně vyhodnocované metriky a indikátory:
- počet a procento nahlášených incidentů dle kategorie závady
- minimální, maximální a průměrná doba reakce dle kategorie závady

102
w ČR - Cssz

DsrREnI

Křížová 25, 225 08 Praha 5

Audit a reporting: - minimální, maximální a průměrná doba odstranění dle kategorie závady
Role a odpovědnosti: - počet incidentů, u nichž nebyla dodržena doba reakce dle kategorie

závady
- počet incidentů, u nichž nebyla dodržena doba odstranění dle kategorie

závady
- počet a procento incidentů, dle příčiny a způsobu jejich řešení:

0 nejednalo se o incident, chování aplikace bylo vysvětleno
o příčina incidentu byla mimo podporovanou aplikací
0 příčinou incidentu byla již dříve známá chyba aplikace zaevidovaná

v rámci Řízení problémů
o příčinou incidentu byla nově identifikovaná chyba aplikace
0 incident byl vyřešen náhradním řešením
o incident byl vyřešen opravou chyby aplikace

Odpovědný pracovník Objednatele:
- zajištění potřebných funkcí HelpDesku Objednatele a jeho integrace na

ServiceDesk Zhotovitele
- metodické vedení uživatelů při účasti na procesu
Uživatelé Objednatele
- nahlášení incidentu a jeho přesná speciﬁkace
- návrh kategorizace závady
- upřesnění specifikace incidentu na výzvu Zhotovitele
- potvrzení úspěšného vyřešení incidentu
Odpovědný pracovník Zhotovitele:
- zajištění dostupnosti ServiceDesku Zhotovitele a jeho integrace na

HelpDesk Objednatele
Pracovník aplikační podpory Zhotovitele:
- kompletní zajištění aktivit při řešení konkrétního incidentu

Proces: Řízení problémů
Cíle: - identifikovat a evidovat problémyjako příčiny incidentů
- evidovat ostatní problémy detekované např. při testech nebo

profylaktických zásazích
- vést unikátní evidenci aktuálně známých chyb a odpovídajících

náhradních řešení, pokud existují

103
ČR - ČSSZ

Křížová 25, 225 08 Praha 5

Vstupy: zajišťovat odstraňování problémů vsouladu sjejich kategorizací a
Výstupy:
Služby a aktivity: prioritami

Vazby na ostatní předcházet opakování incidentů a narušení provozu aplikace
procesy: identifikované problémy jako výsledek analýzy incidentů
kategorie problému (převzatá z kategorie incidentu)
priority řešení problémů

aktuální seznam známých chyb a odpovídajících náhradních řešení
finální odstranění problému
opravné balíčky

ServiceDesk a HotLine Zhotovitele:

příjem a zaevidování problémů z procesu Řízení incidentů
příjem a zaevidování problémů z jiných zdrojů (např. testování)
sledování životního cyklu problému
sledování vazby na incidenty
podpora pro kategorizaci a prioritizaci problémů
sledování dodržování požadované doby opravy
eskalace incidentu, pokud je požadována
vyhodnocení řešení a uzavření problému
vydávání seznamu známých chyb a odpovídajících náhradních řešení
propagování problémů, jejich postupu řešení a seznamu známých chyb
do HelpDesku Objednatele
HelpDeskObjednatele
přebírání komunikace ze ServiceDesku Zhotovitele

zpřístupnění problémů uživatelům

zpřístupnění seznamu známých chyb uživatelům
Vydávání opravných balíčků

naplánování opravného balíčku a jeho obsahu (zahrnuté problémy)

realizace opravného balíčku

testování opravného balíčku

nasazení opravného balíčku

vyhodnocení úspěšnosti odstranění problémů začleněných do balíčku

vyhodnocení celkové úspěšnosti opravného balíčku
aktualizace seznamu známých chyb
aktualizace navázaných nevyřešených incidentů

Řízení incidentů:
přebírání incidentů pro založení nového problému

Měření služeb:

104
w ČR - ČSSZ

USTREDI

Křížová 25, 225 08 Praha 5

Metriky a indikátory: - předání vstupních hodnot pro výpočet metrik a indikátorů
Vykazování služeb:
Audit a reporting: — předání podkladů potřebných pro výkaz služeb
Role a odpovědnosti: Řízení release a nasazení:
- koordinace vydávání opravných balíčků svydáváním nových verzí

aplikace
- využití zavedených postupů pro nasazení opravných balíčků
Ověřování a testování:
- využití zavedených postupů pro testování opravných balíčků

- počet a procento identifikovaných problémů dle kategorie závady
- minimální, maximální a průměrná doba odstranění dle kategorie závady

počet problémů, u nichž nebyla dodržena doba odstranění dle
kategorie závady
počet a procento problémů dle příčiny a stavu jejich řešení:

0 nejednalo se o problém, chování aplikace bylo vysvětleno nebo
příčina byla mimo podporovanou aplikací

0 problém doposud čeká na zařazení do opravného balíčku
o problém je řešen v aktuálně realizovaném opravném balíčku
o problém byl již minimálně jednou řešen vjiž nasazeném balíčku,

ale oprava nebyla úspěšná
o problém byl vyřešen opravou chyby
- počet a procenta vyřešených problémů dle počtu pokusů o opravu
problému

Audit procesu bude umožněn na základě auditních možností systémů pro
podporu služeb HelpDesk Objednatele a ServiceDesk Zhotovitele.
Reporting procesu bude prováděn na měsíční bázi vrámci procesu
Vykazování služeb.
Kromě sledování hodnot metrik a indikátorů na měsíční bázi budou
pravidelně reportovány následující výstupy:
- plán realizace opravných balíčků a jejich obsahu
- aktuální seznam známých chyb a náhradních řešení

Odpovědný pracovník Objednatele:
- zajištění potřebných funkcí HelpDesku Objednatele a jeho integrace na

ServiceDesk Zhotovitele
- metodické vedení uživatelů při účasti na procesu
- schvalování plánu opravných balíčků
— schvalování výsledků testování a nasazení opravných balíčků
Uživatelé Objednatele

105
$k

W ČR - Cssz

ÚSTŘEDI

Křížová 25, 225 08 Praha 5

- účast na přejímacím testování opravného balíčku
- potvrzení úspěšného vyřešení problému
Odpovědný pracovník zhotovitele:
- zajištění dostupnosti ServiceDesku Zhotovitele a jeho integrace na

HelpDesk Objednatele
- sestavování a plánování opravných balíčků
- udržování seznamu známých chyb a náhradních řešení
Pracovník aplikační podpory Zhotovitele:
- zajištění správy problémů v ServiceDesku Zhotovitele

Proces: Plnění pdadavků

Cíle: - zajištění plnění požadovaných služeb poskytovaných na vyžádání
Vstupy: - zajištění plnění služeb poskytovaných automaticky v definovaných
Výstupy:
Služby a aktivity: intervalech

Vazby na ostatní - požadavek na plnění služeb aplikační podpory
procesy:
- priorita požadavku

- časová událost:je třeba poskytnout periodické plnění
- poskytnutí služby
- podklady pro výkaz služeb (např. zápis o vykonaném profylaktickém

zásahu)

ServiceDesk a HotLine zhotovitele:
- sběr požadavků na poskytnutí plnění dohodnutých služeb aplikační

podpory

- vyhodnocování a prioritizace požadavků

- sledování postupu plnění

- zjišťování spokojenosti zástupců objednatele
- vyhodnocení a uzavření požadavků
Seznam poskytovaných služeb:
- na vyžádání:

o Poskytování vyžádaných konzultací a součinnosti
— průběžně dle potřeby Objednatele:

o Školení na bázi e—Iearningových kurzů
— v pravidelných intervalech:

o Profylaktické zásahy

o Reporting

Řízení incidentů

106
W ČR - ČSSZ

Usmev!

Křížová 25, 225 08 Praha 5

Metriky a indikátory: - přebírání nových požadavků z incidentů, pokud jsou tak vyhodnoceny
Audit a reporting: Měření služeb:
Role a odpovédnosti: — předání vstupních hodnot pro výpočet metrik a indikátorů
Vykazování služeb:
- předání podkladů potřebných pro výkaz služeb

- počet otevřených požadavků na začátku a na konci měsíce
- počet nově zaevidovaných požadavků v průběhu měsíce
- počet a procento přijatých, odmítnutých, odložených a vyřešených

požadavků
- počet a procento úspěšně a neúspěšně splněných požadavků

Odpovědný pracovník Objednatele:
- zajištění potřebných funkcí HelpDesku Objednatele a jeho integrace na

ServiceDesk Zhotovitele
- metodické vedení uživatelů při účasti na procesu
Uživatelé Objednatele
- nahlášení požadavku a jeho přesná specifikace
- zajištění potřebných podkladů (aplikační logy, printscreen obrazovek)

návrh priority požadavku
- upřesnění požadavku na výzvu Zhotovitele

potvrzení úspěšného vyřešení požadavku
Odpověd ný pracovník Zhotovitele:
- zajištění dostupnosti ServiceDesku Zhotovitele a jeho integrace na

HelpDesk Objednatele
Pracovník aplikační podpory Zhotovitele:
- kompletní zajištění aktivit při řešení konkrétního požadavku

Proces: Měření služeb
Cíle: - zajistit monitoring a měření poskytovaných služeb aplikační podpory
- zajistit podklady pro hodnocení kvality poskytovaných služeb
Vstupy: - ověřit dopady dřívějších rozhodnutí a prokázatjejich správnost
- zajistit podklady pro rozhodování o dalším směřování

- metriky a indikátoryjednotlivých procesů
požadovaná periodicita měření

107
,“

W ČR - ČSSZ
ÚSTŘEDI

Křížová 25, 225 08 Praha 5

Výstupy: - metodika a další požadavky na provádění měření
Služby a aktivity: -primární vstupní hodnoty (např. časy záznamů událostí do

Vazby na ostatní ServiceDesku)
procesy: - naměřené a spočtené hodnoty metrik a indikátorů
Reporting:
Metriky a indikátory: - sběr primárních vstupních hodnot
Audit a reporting: - výpočet hodnot metrik a indikátorů
Role a odpovědnosti: Všechny měřené procesy:
- přebírání zaznamenaných vstupních hodnot
Vykazování služeb:
- poskytnutí podkladů pro tvorbu výkazů
- žádné, aplikují se na měřené procesy
- žádný, aplikuje se na měřené procesy
Odpovědný pracovník Zhotovitele:
- zajistit provádění měřenív souladu s definovanými pravidly

Proces: Vykazování služeb
Cíle: - informovat Objednatele o kvantitě a kvalitě poskytnutých služeb

Vstupy: v uplynulém období
Výstu py: poskytnout podklad pro akceptaci poskytnutého plnění
Služby a aktivity: - vyhodnocovat kritické aspekty služeb a vyvozovat opatření pro budoucí
Vazby na ostatní předcházení problémům
procesy: - směřovat k neustálému zlepšování služeb

Metriky a indikátory: naměřené a spočtené hodnoty metrik a indikátorů
Audit a reporting: další podklady z jednotlivých procesů
- výkaz poskytnutých služeb
Reporting:
- příprava výkazu poskytnutých služeb
Všechny měřené procesy:
- přebírání dalších podkladů pro vykazování
Měření
- přebírání hodnot metrik a indikátorů
- žádné, aplikují se na základní procesy
- žádný, proces sám o sobě realizuje reporting

108
w ČR - ČSSZ

ÚSTŘEDI

Křížová 25, 225 08 Praha 5

Role a odpovědnosti: Odpovědný pracovník Zhotovitele:
- zajistit vykazování služeb v souladu s definovanými pravidly
— předat výsledný výkaz služeb objednateli
Odpovědný pracovník Objednatele:
- podílet se na definování pravidel pro vykazování služeb
- přebírat a akceptovat výkazy služeb

4.2.3.3 Popis nabízených služeb v rámci aplikační podpory
Naplnění procesů aplikační podpory bude zajištěno následujícími službami:

. ServiceDesk a HotLine Zhotovitele

. Řešení incidentů
. Vydávání opravných balíčků
o Profylaktické zásahy
. Poskytování konzultací a další vyžádaná součinnost
. Školení

. Reporting

Popis služeb uvádíme v tabulkách níže.

Služba: ServiceDesk a HotLine Zhotovitele
Popis:
Služba slouží pro příjem, evidenci a řízení životního cyklu incidentů,
Funkce: problémů a požadavků Objednatele na straně Zhotovitele.
Pro zjednodušení vrámci popisu této služby se dále hovoří obecně o
požadavcích, ale míněnyjsou též incidenty a problémy.
Na straně Objednatele je provozována obdobná služba, nazvaná
HelpDesk Objednatele. SW aplikace obou služeb jsou již integrovány tak,
aby byly jednotlivé záznamy o požadavcích oboustranně
synchronizovány.

- příjem požadavku včetně vydání potvrzení o příjmu a jeho zaevidování

- analýza a kategorizace požadavku (incident, problém, požadavek na

poskytnutí služby, požadavek na rozvoj aplikace)
- kategorizace závady (A, B, C), pokud se jedná o závadu
- prioritizace požadavku

- řízení front požadavků dle kategorií
- sledování postupu plnění požadavku
- možnost ukládání souborových příloh
- předávání požadavku k doplnění zadání pracovníku Objednatele

109
45—

W (ČR-ČSSZ
ÚSTŘEDI

Křížová 25, 225 08 Praha 5

Dostupnost: eskalace požadavku, pokud je zapotřebí
Omezení rozsahu: - informování Objednatele o vyřešení požadavku
- vyjádření spokojenosti objednatele se způsobem vyřešení
- uzavření požadavku
- sledování a záznam času všech události
- poskytování přehledů a statistik

ServiceDesk integrovaný na HelpDesk:
- provoz v režimu 7 x 24
- případné plánované odstávky budou oznamovány Objednateli alespoň

3 dny předem
- možnost též přímého přístupu na adrese http://servicedesk.komix.cz
HotLine:
- provoz v režimu 5 x 10, dostupnost v pracovní dny od 7 do 17 hodin

- provoz na Čísle—

Služba je považována za dostupnou, pokud alespoň jedno z uvedených
rozhraníje funkční.

Neomezený — dle potřeby

Služba: Řešení incidentů

Popis: Služba slouží pro okamžitou reakci na nahlášené incidenty. Cílem je
Funkce: zprovoznění aplikačního vybavení v maximální možné míře a v nejkratším
možném čase.
Dostupnost: - základní vyhodnocení incidentu a potvrzení/ přehodnocení navrhované

kategorie závady
- přiřazení náhradního řešení, pokud existuje
- řešení přímých dopadů incidentu (např. příprava DB skriptu pro opravu

dat v databázi)
- vyšetření příčiny incidentu — rozhodnutí, zda je příčinou vada

podporované aplikace
- posouzení vady aplikace — zda se jedná o nový / existující problém
- přiřazení incidentu kexistujícímu problému, nebo specifikace nového

problému a jeho předání do procesu Řízení problémů
- ověření spokojenosti uživatele se způsobem vyřešení incidentu
- vyhodnocení a uzavření incidentu

Pro závady kategorie A:
- zahájení řešení incidentu v pracovní době
- dokončení řešení incidentu v režimu 7 x 24

110
% ČR - Cssz

ÚSTŘEDÍ

Křížová 25, 225 08 Praha 5

Omezení rozsahu: Pro závady kategorie B a C:
- řešení incidentu v pracovní době
Neomezený — dle potřeby

Služba: Vydávání opravných balíčků
Popis:
Funkce: Služba slouží pro trvalé fixování vad programového vybavení. Opravné
balíčky se vyznačují tím, že zachovávají původní rozsah funkčnosti
Dostupnost: aplikace, ale odstraňují vady, jejichž oprava byla do opravného balíčku
Omezení rozsahu: zahrnuta. Balíček prochází obdobním procesem vydání, testování a
schvalování k nasazení, podobně jako nová verze aplikace.

- výběr problémů dlejejich kategorie a priority pro zařazení do balíčku
- stanovení plánu realizace balíčku

realizace balíčku, jeho distribuce do testovacího prostředí Objednatele
- akceptační testování
- nasazení do produkčního prostředí
- vyhodnocení úspěšnosti oprav
- promítnutí oprav do případné vyvíjené nové verze aplikace

Pro závady kategorie A:
- zahájení realizace opravného balíčku v pracovní době
- dokončení započatého opravného balíčku v režimu 7 x 24
Pro závady kategorie B a C:
- realizace opravného balíčku v pracovni době

Služba se vztahuje pouze na vady, které mají původ uvnitř aplikace.
Vyloučeny jsou vady způsobené vnějším prostředím (např. změnami
rozhraní, úpravou legislativy apod.).
Vyloučeno je využití této služby pro požadavky na rozvoj / změny aplikace
— tedy realizované opravy by neměly žádným způsobem měnit dosavadní
funkčnost aplikačního vybavení v souladu s příslušnou dokumentací.

Služba: Profylaktlcké Why
Popis: Cílem služby je zajistit prevenci vad a optimalizaci výkonu aplikace.
Služba zahrnuje pravidelnou kontrolu a vyhodnocení chodu aplikačního
Funkce: vybavení a v případě potřeby provádění potřebných preventivních
zásahů. Profylaktický zásah bude prováděn 1x měsíčně vpředem
naplánovaných termínech.
- plánováníprofylaktických zásahů

111
% ČR-ČSSZ

asmat

Křížová 25, 225 08 Praha 5

000000- výkon profylaktických zásahů:
o kontrola vazeb
Dostupnost: kontrola kvality dat v aplikacích
Omezení rozsahu: řešení problémových stavů v datech
mapování vytížení programového vybavení
návrhy možné optimalizace výkonu
mapování zalogovaných chyb aplikace a jejich vyhodnocení
zahájení řešení problémů, pokud budou odhaleny
o realizace preventivních zásahů, pokud nastane jejich potřeba

- vyhodnocení profylaktického zásahu a vytvoření reportu

V definovaných termínech a časovém intervalu na základě předem
schváleného plánu.

Jeden profylaktický zásah měsíčně.

Služba: Poskytování konzum: a dam mum součinnost

Popis: Služba slouží pro naplnění požadavků Objednatele v oblasti konzultací a
další vyžádané součinnosti Zhotovitele. Bude se jednat např. o řešení
Funkce: systémových problémů, hledání příčin nestandardního chování, pokud se
prokáže, že příčina leží mimo podporovanou aplikaci, implementaci
Dostupnost: systémů třetích stran a jejich rozhraní na podporovanou aplikaci,
Omezení rozsahu: vytváření DB skriptů za účelem ad-hoc analytických výstupů, hromadných
změn dat, oprav chyb v datech zavlečených z jiných systémů apod.

- sběr a analýza požadavků
- upřesnění zadání a podmínek pro poskytnutí konzultace či součinnosti
- odhad pracnosti a jeho odsouhlasení
- poskytnutí konzultace či součinnosti konkrétního typu
- ověření naplnění požadavku Objednatelem
- vyhodnocení a uzavření požadavku

- v definované pracovní době

Rozsah bude stanoven v následných dílčích smlouvách

Služba: školení
Popis: Služba slouží pro školení pracovníků Objednatele v průběhu poskytování
aplikační podpory. Cílem je umožnit objednateli:
- proškolení nových pracovníků,
- proškolení stávajících pracovníků vjiné oblasti, než ve které působili,
- opakování školení pro oživení znalostí.

112
% ČR - (5552
ÚSTŘEDI

Křížová 25, 225 os Praha 5

Funkce: - trvalé zpřístupnění aktuálních školicích materiálů
Dostupnost: - údržba a podpora testovacího prostředí
- příprava a údržba testovacích dat
Omezení rozsahu: - v pracovní době zaručená

- v mimopracovní době s možnými výpadky
Služba školenív rámci aplikační podpory nezahrnuje:
- úvodní hromadné školení, které je součástí dodávky nového aplikačního

programového vybavení
- promítání nových funkcionalit, realizovaných v rámci aplikačního

rozvoje, do e-learningových kurzů a školicích materiálů; to bude
součástí realizace rozvoje

Služba: Reporting
Popis:
Služba bude zajišťovat pravidelný reporting o poskytování aplikační
Funkce: podpory. Reporting bude probíhat na měsíční bázi — vždy za ukončený
kalendářní měsíc svýstupem nejpozději v pátém pracovním dni měsíce
Dostupnost: následujícího. V případě zahájení / ukončení poskytování aplikační
Omezení rozsahu: podpory uprostřed měsíce bude reporting proveden i za tuto dílčí část
samostatně.
Cílem bude též vyčíslení konkrétních hodnot stanovených metrik a
indikátorů a výpočet a vyhodnocení dodatečných metrik, tak aby byl
známý celkový parametr vyhodnocení aplikační podporyjako podklad pro
aplikaci případných sankcí.

- realizace procesu Měření služeb na definované metriky všech procesů
aplikační podpory

— sestavení výstupních reportů ve formátu MS Excel
- připojenívýsledků profylaktických zásahů

- předání výkazu o poskytovaných službách Objednateli

- jednou měsíčně vždy do 5. pracovního dne v měsíci za uplynulý měsíc

Reporting zahrne všechny definované a schválené metriky, indikátory a
výstupy.

4.2.3.4 Popis požadované součinnosti v rámci aplikační podpory

Požadovaná součinnost vrámci aplikační podpory zahrnuje požadavky na součinnost pracovníků
Objednatele dle jejich roli, dále požadavky na HW a SW prostředí pro provoz aplikací, zajišťované
Objednatelem a další požadavky na součinnost. Jejich přesná specifikace je uvedena vnásledujících
dílčích kapitolách.

113
W ČR - Cssz
Osman

Křížová 25, 225 08 Praha 5

4.2.3.4.1 Požadovaná součinnost pracovníků dle rolí
Zhotovitel očekává následující role na straně Objednatele angažované v procesech aplikační podpory a
jejich odpovědnosti v rámci tohoto procesu:

. Odpovědný pracovník Objednatele:
zajištění Koordinační součinnosti:
O metodicky vede uživatele Objednatele při jejich účasti na procesech aplikační

podpory,

O koordinuje činnosti uživatelů Objednatele v souladu s nastavenými procesy,
O dbá na fungování komunikace uživatelů Objednatele,
O koordinuje sběr požadavků na vyžádané služby od uživatelů.
zajištění Věcné součinnosti:
O odpovídá za komplexní zajištění procesů podpory, které nejsou požadovány po

zhotoviteli, konkrétně procesů Řízení událostí a Řízení přístupů,
odpovídá za zajištění všech potřebných funkčností HelpDesku Objednatele pro

podporu koncových uživatelů,
odpovídá za funkčnost automatizovaného propojení HelpDesku Objednatele na
ServiceDesk Zhotovitele pro oboustrannou synchronizaci požadavků prostřednictvím
dohodnutého rozhraní,
dohlíží na návrhy kategorií závad v incidentech hlášených uživateli, případně je
koriguje,
O schvaluje priority požadavků na poskytnutí služeb na vyžádání,
O schvaluje navržený postup realizace požadavků.
zajištění Součinnosti při reportingu:
O schvaluje přesné postupy reportingu a vzory konkrétních výstupů,
O přebírá výstupy 2 reportingu, zajišťuje jejich schválení, příp. vznáší připomínky a
požadavky na doplnění nebo úpravu reportů.

. Klíčový uživatel systému:
zajištění Testování opravných balíčků:
O provádí akceptační testování opravných balíčků před jejich produkčním nasazením,
O ve spolupráci suživateli systému zajišťuje otestování výsledků opravy problémů
zahrnutých v opravném balíčku.

. Uživatel systému:
zajištění Řízení incidentů : pohledu uživatelů:
O nahlašují zjištěné incidenty do HelpDesku,
O popisují přesnou specifikaci incidentu,
O navrhují kategorizaci závady, na vyžádání upřesňují popis incidentu a okolností a
postup jeho navození,
O schvalují způsob řešeníjimi nahlášených incidentů.
zajištění Řízení problémů : pohledu uživatelů:

114
Bi—

W ČR - tssz

ÚSTŘEDÍ

Křížová 25, 225 08 Praha 5

o účastní se na testování opravných balíčků vrozsahu problémů svázaných sjimi
hlášenými incidenty,

o prověřují odstranění příčinyjimi hlášených incidentů po nasazení opravného balíčku,
o schvalují způsob řešeníjimi nahlášených incidentů.

. zajištění Řízení požadavků z pohledu uživatelů:
0 nahlašují požadavky na poskytnutí služeb aplikační podpory na vyžádání,
o navrhují prioritu požadavku, na vyžádání upřesňují specifikaci požadavku,
o schvalují způsob vyřešeníjimi nahlášených požadavků.

Lze očekávat, že v prvních měsících provozu bude potřebná součinnost vyšší, v průběhu času se bude
snižovat v souladu s tím, jak bude klesat počet chyb v systému.

4.2.3.5 Návrh předání aplikační podpory a rozvoje případnému novému dodavateli
V případě přechodu aplikační podpory a rozvoje na nového dodavatele se Zhotovitel zavazuje poskytnout
Objednateli nezbytnou součinnost tak, aby byla zajištěna maximální možná kontinuita všech
poskytovaných služeb, a zejména kontinuita provozu podporovaného aplikačního vybavení.

4.2.3.5.1 Plán předání aplikační podpory a rozvoje novému dodavateli

Zhotovitel se zavazuje nejpozději do 90 dní od zahájení poskytování aplikační podpory vypracovat a
předložit Objednateli Plán předání aplikační podpory a rozvoje novému dodavateli. Jeho součástí bude:

. harmonogram ukončování aplikační podpory a rozvoje a jejich přesunu na Objednatele resp.

nového dodavatele,

. seznam potřebných kroků a jejich přesná specifikace (rozpracování následujících dílčích kapitol),
. seznam všech předávaných součástí (zdrojové kódy, dokumentace, instalační skripty,

konfigurační soubory apod.),
. návrh organizačních opatření pro zajištění bezproblémového přechodu,
. specifikace požadované součinnosti Objednatele a nového dodavatele pro zajištění

bezproblémového přechodu.
Plán předání aplikační podpory bude podléhat schválení Objednatele (Zhotovitel před schválením zahrne
připomínky Objednatele). Plán předání aplikační podpory bude dle potřeby udržován průběžnými
aktualizacemi. Poslední aktualizace zohlední konkrétní podmínky přechodu služeb a bude vydána
nejpozději 20 dní před ukončením Smlouvy.

4.2.3.5.2 Předání aplikační podpory
Za účelem předání aplikační podpory se Zhotovitel zavazuje ke dni ukončeníjejího poskytování:

. vytvořit kompletní statistiky a reporting ke dni ukončení poskytování podpory, a to iv případě, že
by se nejednalo o konec kalendářního měsíce,

. zajistit aktualizaci stavu řešení všech záznamů v ServiceDesku k okamžiku ukončení poskytování

podpory,

115
W ČR-ČSSZ

ÚSTŘEDÍ

Křížová 25, 225 08 Praha 5

. zajistit synchronizaci aktuálního stavu všech záznamů vServiceDesku sHeIpDeskem tak, aby
nový dodavatel mohl čerpat všechny podklady z HelpDesku Objednatele a plynule navázat na
poskytování podpory a dořešit rozpracované incidenty, problémy a požadavky,

. synchronizovat vydávání opravných balíčků s plánovaným termínem ukončení poskytování
aplikační podpory tak, aby byl balíček vydán, nainstalován do testovacího prostředí Objednatele,
otestován a nasazen do produkčního prostředí před koncem poskytování aplikační podpory,
případně zajistit, aby bylo nasazení dokončeno i po ukončení poskytování podpory.

4.2.3.5.3 Předání rozvoje aplikací
Za účelem předání rozvoje aplikací se Zhotovitel zavazuje ke dni ukončení jejího poskytování:

. vytvořit kompletní statistiky a reporting ke dni ukončení poskytování rozvoje, a to i v případě, že
by se nejednalo o konec kalendářního měsíce,

' zajistit aktualizaci stavu řešení všech požadavků na rozvoj v ServiceDesku kokamžiku ukončení
poskytování rozvoje,

. zajistit synchronizaci aktuálního stavu všech záznamů vServiceDesku sHeIpDeskem tak, aby
nový dodavatel mohl čerpat všechny podklady z HelpDesku Objednatele a plynule navázat na
poskytování rozvoje aplikací, zejména převzít evidované požadavky na rozvoj spolu sjejich
prioritami a dalšími atributy,

. synchronizovat vydávání nových verzí splánovaným termínem ukončení poskytování rozvoje
aplikací tak, aby poslední nová verze byla vydána, nainstalován do testovacího prostředí
Objednatele, otestována a nasazena do produkčního prostředí před koncem poskytování rozvoje
aplikací, případně zajistit, aby bylo nasazení dokončeno i po ukončení poskytování služby,

. zajistit, aby novému dodavateli byly předány aktuální zdrojové kódy a veškerá dokumentace ve
stavu odpovídajícímu poslední vydané verzi aplikace.

4.2.3.6 Organizační zajištění aplikační podpory
Organizaci aplikační podpory zajišťují pracovníci vklíčových rolích na základě jejich definovaných
pravomocí. Využívají přitom nadefinovaných pravidel komunikace a vpřípadě potřeby též eskalace
problémů, které nelze řešit na základní úrovni komunikace. Na nejvyšší úrovni pak probíhá jednání na
úrovni řídicích orgánů aplikační podpory.

4.2.3.6.1 Role 3 odpovědnosti
Role přímo zapojené do procesů aplikační podpory předpokládané na straně Objednatele jsou
specifikovány včetně jejich základních úkolů v kapitole 4.2.3.4. V rámci organizačního zajištění budou
působit zejména následující role na straně Objednatele:

. Odpovědný pracovník Objednatele:
. je partnerem pro odpovědného pracovníka Zhotovitele,
0 zajišťuje dodržování definovaných podmínek spolupráce na straně Objednatele,
0 schvaluje návrhy Zhotovitele, příp. je ke schválení eskaluje,
' schvaluje plány nasazení opravných balíčků,

116
tw ČR - ČSSZ

ÚSTŘEDI

Křížová 25, 225 08 Praha 5

. akceptuje a schvaluje k produkčnímu nasazení opravné balíčky,
. akceptuje poskytování služeb aplikační podpory.

Klíčový uživatel systému:
. je partnerem pro hlavního analytika Zhotovitele v konkrétní oblasti aplikace,
' schvaluje analytický popis návrhu řešení problémů v dané oblasti aplikace.

Na straně Zhotovitele předpokládáme následující role, které se významněji podílejí na organizačním
zajištění aplikační podpory:

Odpovědný pracovník Zhotovitele:
. je partnerem pro odpovědného pracovníka Objednatele,
0 zajišťuje dodržování definovaných podmínek spolupráce na straně Zhotovitele,
. předkládá návrhy Zhotovitele,
. schvaluje návrhy Objednatele, příp. je ke schválení eskaluje,
. připravuje a předkládá plány nasazení opravných balíčků,
. schvaluje opravné balíčky k nasazení do testovacího prostředí Objednatele,
. připravuje podklady k akceptaci poskytování služeb aplikační podpory.

4.2.3.6.2 Dokumentace a komunikace
Pro oblast komunikace budou nastavena následující pravidla:

Oficiální dokumentace ohledně aplikační podpory - zahrnuje zejména:
0 zápisy z kontrolnich dní,
. schválené plány realizace opravných balíčků,
. výkazy poskytnutých služeb,
. akceptační protokoly opravných balíčků,
. závěrečné zprávy o testování opravných balíčků,
. apod.
bude po předchozím ověření v elektronické podobě vytištěna a osobně předkládána ke schválení
podpisem pracovníků odpovídající úrovně za obě smluvní strany vzávislosti na charakteru
dokumentu.

Pracovní verze oficiálních dokumentů ohledně průběhu aplikační podpory (zahrnuté
dokumenty jsou specifikovány v předchozím odstavci) budou vytvářeny vždy v elektronické
podobě, ve které budou dokumenty předávány e-mailem za účelem přípravy oboustranně
přijatelného finálního znění.

Další dokumentace průběhu aplikační podpory — zahrnuje zejména:
. seznamy známých chyb,
. reporty z jednotlivých procesů podpory aplikací,
. reporty o provedené profylaxi,

117
W ČR - ČSSZ

ÚSTŘEDI

Křížová 25, 225 08 Praha 5

' vyhodnocení stanovených metrik,
0 analytické návrhy řešení problémů,
. testovací protokoly,
' apod.
bude vytvářena v elektronické podobě a předávána e-mailem. Touto cestou bude možné uplatnit
též případné připomínky k obsahu předložených dokumentů.

Sběr a řízení incidentů, problémů a požadavků na poskytnutí dalších služeb aplikační podpory a
veškerá komunikace stímto související bude zajišťována prostřednictvím systémů HelpDesk
objednatele a ServiceDesk Zhotovitele, mezi nimiž bude zajištěna automatická oboustranná
synchronizace požadavků.

Operativní komunikace bude podle charakteru a potřeby realizována některým z následujících
způsobů, případnějejich kombinací:
. e-mailem,
0 telefonicky,
' osobním jednáním.

118
% ČR - Cssz '
Příloha č. 2 k Rámcové smlouvě
Osment

Křížová 25, 225 08 Praha 5

Cena plnění
W

1 Cena

Zhotovitel se zavazuje dodržovat níže uvedené ceny a cenové principy za služby definované v Příloze

č. 1 této Smlouvy.

1. 1 Jednotkové ceny za člověkoden

Pro veškeré dodávané služby dle této Smlouvy platí následující jednotkové ceny za člověkoden (dále
jen „ČD“, „Člověkodnem“ se rozumí objem práce, vykonané jedním specialistou Zhotovitele za dobu
jednoho pracovního dne, tj. za 8 pracovních hodin) rozdělené podle rolí:

Sazba za ČD bez Sazba za ČD s DPH
DPH

Projektový manažer

Procesní analytik

Architekt informačního systému

Tester

Vývojář

Ostatní

1. 2 Cena za Převzetí do servisu

Cena služby Převzetí do servisu (dle definice v Přílozec. 1) je Zhotovitelem zohledněna v jednotkových
cenách za ČD. Zhotovitel nebude nad rámec takto stanovené ceny nárokovat další odměnu nebo jinou
platbu za službu Převzetí do servisu.

1.3 Cena za Poskytování aplikační podpory APV NEM a D_STAT

Objednatel definuje čtyřletý maximální limit pro čerpání služby Poskytování aplikační podpory APV
NEM a D_STAT definované v Příloze č. 1, který je stanoven v rozsahu 4500 ČD.

Platby za poskytování této služby se uskutečňují na pravidelné měsíční bázi, dle odpracovaných
člověkodnů, po odsouhlasení výkazu činností a akceptaci Objednatelem. Přičemž v každém roce, je
možné celkem účtovat maximálně 1125 člověkodní. Pokud Poskytování aplikační podpory překročí
roční limit člověkodní (1125 ČD), Zhotovitel se zavazuje danou službu dále vykonávat (bez možnosti
nároku na úhradu).

Celkový rozsah účtovaných člověkodnů dle rolí nesmí také překročit stanovené hodnoty dle tabulky
„Maximálnícasová náročnost během následujících čtyř let pro aplikační podporu“.

Cena za poskytování této služby je stanovena jako počet čerpaných a odsouhlasených člověkodnů za
kalendářní měsíc, které se násobí pevně stanovenou denní sazbou dle role a Dopadem na platbu za
W

daný měsíc. Dopad na platbu je definovaný níže v tabulce, Parametr SLAce‘ke’" je definovaný v Příloze
c. 1.

\\!
Měsíční platba je tedy rovna: Ill. "„lj uji
Dopad na platbu X Z(poéet élovékodnﬁmle X sazbamle)

100% 100%
95% 95%
90% 90%
< 90% 80% je považováno za podstatné porušení
této smlouvy

Pokud cena za Poskytování aplikační podpory v daném měsíci bude nulová (z důvodu dosažení ročního
limitu čerpání ČD), bude pro případný výpočet sankce za porušení SLA využita průměrná měsíční cena
za všechny předcházející měsíce Poskytování aplikační podpory APV NEM a D_STAT a bude uplatnéna
smluvní pokuta ve výši:

100° — D d 2 cena za Poskytování aplikační podporu APV NEM a D — STATměsíc
[ tb x

( A) opa na p a u) počet měsíců Poskytování aplikační podpory APV NEM a D — STAT

Maximální objem ČD pro Poskytování aplikační podpory APV NEM a D_STAT

Maximální počet Cena za maximální Cena za maximální

člověkodnů (ČD) počet ČD bez DPH počet ČD s DPH

Projektový manažer 2 376 000 Kč 2 874 960 Kč

Procesní analytik 3 915 000 Kč 4 737 150 Kč

grits? informačního 1 935 000 Kč 2 341 350 kč

Tester 3 937 500 kč 4 764 375 kč

Vývojář 4 050 000 Kč 4 900 500 Kč
Ostatní 1 332 000 kč 1 611 720 Kč

Celkem 4 500 17 545 500 kč 21 230 055 Kč

Pro výpočet cen jsou použityjednotkové ceny definované v čl. 1.1

1.4 Cena za Rozvoj APV NEM a D_STAT

Cena za poskytování služby požadavky na Rozvoj APV NEM a D_STAT definované v Příloze č. 1 je

vypočtena dle skutečně odpracovaných a schválených člověkodnů Objednatelem a dané denní sazby
pro konkrétní roli.
W

Objednavatel předpokládá objem plnění dle tabulky níže. Objednatel negarantuje minimální objem
čerpání těchto služeb.

Platby se uskutečňují na základě odpracovaných člověkodní po akceptaci Dílčího plnění Objednatelem.

Rozsah účtovaných člověkodnů dle rolí, nesmí překročit stanovené hodnoty dle tabulky: “Maximální
objem služeb za Rozvoj APV NEM a D_Sl'A :“

Maximální objem služeb za Rozvoj APV NEM a D_STAT

Celkový maximální Maximální cena za Rozvoj APV NEM a
počet ČD na Rozvoj D_STAT

Projektový manažer 7 524 000 Kč 9 104 040 Kč
Procesní analytik 12 397 500 Kč 15 000 975 Kč
7 440 290 Kč
332“ infomaě'ího 6 149 000 Kč

Tester 12 460 000 Kč 15 076 600 Kč
Vývojář
Ostatní 12 816 000 Kč 15 507 360 Kč
Celkem
4 218 000 Kč 5 103 780 Kč

14 250 55 564 500 Kč 67 233 045 Kč

Pro výpočet cen jsou použityjednotkavé ceny definované V čl. 1.1
W

2 Přehled cen plnění

Tabulka uvedená níže zobrazuje rekapitulaci cen této Smlouvy:

Cega$21;:oskytovém' aplikační podpory APV NEM 17 545 500 Kč 21 230 055 Kč

a __

Cena za Rozvoj APV NEM a D_STAT 55 564 500 Kč 67 233 045 Kč

Pro výpočet cen jsou použityjednotkové ceny definované V čl. 1.1
M ČR - Cssz .
USTREDI
Příloha č. 3 k Rámcové smlouvě
Křížová 25, 225 08 Praha 5

Podrobný popis způsobů
uzavírání Dílčích smluv
I. --------_--í
Postup Stran

V souladu se ZVZ, a v souladu s Rámcovou smlouvou, jejíž přílohou je tento dokument, se
Strany zavazují provádět jakákoliv Dílčí plnění dle této Smlouvy výhradně na základě uzavřené
Dílčí smlouvy,r.esp akceptované Dílčí objednávky. Způsob uzavírání jednotlivých Dílčích smluv
je vymezen níže.

II.
Plnění do 500.000,- Kč bez DPH

V případě plnění do 500. 000,- Kč (slovy: Pětsettisíc korun českých) bez DPH bude Dílčí plnění
realizováno na základě písemné Dílčí objednávky Objednatele a písemného potvrzení takové
Dílčí objednávky Zhotovitelem.

VDílčí objednávce Objednatel specifikuje požadované plnění, rozsah v člověkodnech (dále jen
„ČD“) a termín plnění v souladu s Rámcovou smlouvou, případně další relevantní skutečnosti,
s nimiž by měl být Zhotovitel seznámen.

Zhotovitel je povinen do 10 (deseti) pracovních dnů od doručení písemné Dílčí objednávky
Zhotoviteli tuto Dílčí objednávku písemně potvrdit nebo upravit rozsah požadavku na Dílčí
plnění. Při úpravě rozsahu je povinen stanovit termín realizace požadovaného Dílčího plnění
a jeho cenu, to vše na základě skutečností uvedených v Rámcové smlouvě a jejích přílohách.
Zhotovitel je rovněž povinen v tomto potvrzení stanovit akceptační kritéria pro akceptaci Díla
v souladu s čl. IV. Smlouvy.

Objednatel je povinen do 15 (patnácti) pracovních dnů navržený termín realizace
požadovaného Dílčího plnění a jeho cenu určenou v souladu s čl.V. Smlouvy potvrdit,
v případě odlišně navrženého rozsahu plnění ze strany Zhotovitele a navržených akceptačních
kritérií potvrdit nebo odmítnout.

V případě zjištění překročení částky 500.000,- Kč (pětsetitisíc)"za realizaci Dílčího plnění je
Zhotovitel povinen Objednateli doručit návrh Dílčí smlouvy dle níže uvedených ustanovení této
přílohy.

Okamžikem doručení potvrzení Objednatele Zhotoviteli se stává písemná Dílčí objednávka pro
Strany závaznou. Zhotovitel se zavazuje zahájit realizaci Dílčího plnění neprodleně po doručení
potvrzení Objednatele, není— li v Dílčí objednávce stanoven jiný termín realizace.

III.

Plnění nad 500.000,— Kč bez DPH

V případě plnění nad 500. 000,- Kč (slovy: Pětsettisíc korun českých) bez DPH Objednatel
uzavře se Zhotovitelem Dílčí smlouvu tak, že Objednatel zašle Zhotoviteli písemnou výzvu, ve
které specifikuje požadované plnění, jeho rozsah v ČD a termín, případně další skutečnosti
nezbytné pro zpracování návrhu Dílčí smlouvy.

Zhotovitel je povinen písemnou výzvu Objednatele potvrdit nejpozději do 10 (deseti)
pracovních dnů ode dne jejího doručení Zhotoviteli, s výjimkou případů, kdy (i) Zhotovitel
oznámí Objednateli nezbytnost prodloužení této lhůty, a to zejména s ohledem na objektivní
složitost požadovaného předmětu Dílčího plnění, (ii) Zhotoviteli brání v potvrzení výzvy vážné
důvody, které není schopen objektivně překonat, přičemž je Zhotovitel povinen tyto důvody
Objednateli neprodleně oznámit.
ll

Za potvrzení písemné výzvy Objednatele se považuje doručení podepsaného návrhu Dílčí
smlouvy Zhotovítelem Objednateli. Zhotovitelem předložený návrh Dílčí smlouvy musí být
v souladu s Rémcovou smlouvou, požadavky Objednatele uvedenými v zaslané písemné výzvě
a v souladu se zadáním, které bylo nedílnou součástí písemné výzvy Objednatele a stane se
nedílnou součástí uzavřené Dílčí smlouvy. Cena za realizaci Dílčího plnění Díla bude určena
v souladu se zadáním a s ustanovením Rámcové smlouvy o ceně. Návrh Dílčí smlouvy bude
rovněž obsahovat návrh akceptačních kritérií pro akceptaci Díla v souladu se Smlouvou.

Objednatel se zavazuje Zhotovitelem doručený návrh Dílčí smlouvy nejpozději do 15 (patnácti)
pracovních dnů od dne jeho doručení odsouhlasit a podepsat nebo oznámit Zhotoviteli, že
s předloženým návrhem Dílčí smlouvy nesouhlasí a z jakých důvodů.

Podpisem Objednatele se Dílčí smlouva stává platnou a účinnou. Zhotovitel se zavazuje zahájit
realizaci Dílčího plnění neprodleně po nabytí platnosti a účinnosti Dílčí smlouvy, není-Ii v Dílčí
smlouvě stanoveno jinak.
mg] ČR-ČSSZ '

ÚSTŘEDI -

Křížová 25, 225 08 Praha 5

Dílčí smlouva k Rámcové smlouvě
o vývoji a údržbě aplikačního programového vybavení pro

pojistné dávky a statistiky — II

číslo IIIIIIIIIIIIIIIIIIIIIIIIII

Smluvní strany

Česká republika - česká správa sociálního zabezpečení
Sídlo: Křížová 25, Praha 5, PSČ 225 08

Statutární zástupce Objednatele: prof. JUDr. Vilém Kahoun, PhD., ústřední ředitel ČSSZ
Osoba oprávněná jednat jménem Objednatele: ...................................
Kontaktní osoba: ...................................
tel: ...................................

IČO: 00006963

(dále jen „0bjednatel“)
na straně jedné

Zastoupená: ...................................
Zápis v OR: ...................................
Kontaktní osoba: ...................................
tel.: ...................................
e-mail: ...................................
Bankovní spojení: ...................................

IČO: ...................................
DIČ: ...................................

(dále jen „Zhotovite|“)
na straně druhé
(Objednatel a Zhotovitel budou v této smlouvě označováni jednotlivě jako „Strana“ a společně jako „Strany“)

Parafováno: Zhotovitel: Objednatel: strana 1/1

(
-
W .

Strany se dohodly na realizaci dílčí veřejné zakázky „ ....................................“ za podmínek uvedených
v Rámcové smlouvě o Vývoji a údržbě aplikačního programového vybavení pro po'istné dávky a statistiky —
II, ze dne ............... (dále též „RS“), a za podmínek uvedených níže v této smlouvě (dále též „Smlouva“):

Článek 1

Předmět Smlouvy

1.1 Předmětem této Smlouvy je ............................................. (dále jen „Dílo“). Specifikace Díla je uvedena

v Příloze č. 1 této Smlouvy.

1.2 Zhotovitel touto Smlouvou uděluje Objednateli oprávnění k výkonu práva vytvořené Dílo užít za

odměnu a za podmínek uvedených v RS. Právem užít Dílo se ve smyslu této Smlouvy rozumí právo
nerušeného užívání Díla v souladu s omezeními stanovenými RS po celou dobu autorské ochrany Díla.

Článek 2

Ceny a platební podmínky

2.1 Cena za provedení Díla dle specifikace v Příloze č. 1 této Smlouvy činí:
.................. ,- Kč bez DPH

(slovy .......................................... korun českých)

tj. .................. ,- Kč vč. DPH

(slovy ....................................... korun českých)

2.2. Cena bude uhrazena v souladu se způsobem úhrady dle RS.

2.3. Zhotovitel má právo za řádně a včas provedené Dílo Objednateli fakturovat za podmínek stanovených
v RS a v Příloze č. 1 této Smlouvy.

2.4. Všechny ceny uvedené v této Smlouvě jsou konečné a lze je překročit pouze v případě změny sazeb

příslušné daně z přidané hodnoty.

2.5. Fakturace za plnění poskytnuté Zhotovitelem bude provedena způsobem uvedeným v RS.

2.6. Daň z přidané hodnoty bude fakturována v zákonem stanovené výši dle platných právních předpisů
vdobě uskutečnění zdanitelného plnění. Faktury jsou splatné do 30 (třiceti) dnů od data jejich
doručení Objednateli.

Článek 3

Trvání Smlouvy, ukončení Smlouvy a místo plnění

3.1. Smlouva se uzavírá na dobu od jejího podpisu do předání Díla a akceptace plnění vsouladu

s harmonogramem plnění dle čl. 3 Přílohy č. 1 této Smlouvy. Nároky Objednatele z vad Díla tím nejsou
dotčeny.

3.2. Místem plnění je sídlo Objednatele na adrese Křížová 25, 225 08 Praha 5 a déle všechna jednotlivá
pracoviště Objednatele.

Parafováno: Zhotovitel: Objednatel:

strana 1/5
Článek 4

Sankční ujednání

Sankce za neplnění Díla podle specifikace uvedené v Příloze č. 1 Smlouvy se řídí podle příslušných
ustanovení RS.

Záruka je poskytována v souladu s příslušnými ustanoveními RS.

Článek 5

Oprávněné osoby

Každá ze Stran jmenuje oprávněnou osobu. Oprávněná osoba bude zastupovat Stranu ve smluvních a
obchodních záležitostech souvisejících s plněním této Smlouvy.

Osoby oprávněné zastupovat Strany ve smluvních a obchodních záležitostech:

Za Objednatele:
tel.:
e-mail:

Za Zhotovitele:
tel. :
email:

Osoby oprávněné zastupovat Strany ve věcném plnění:

Za Objednatele:
tel.:
e-mail:

Za Zhotovitele:
tel. :
e-mail:

Strany jsou oprávněny změnit výše uvedené oprávněné osoby, jsou však povinny na takovou změnu
písemně upozornit druhou Stranu, a to bez zbytečného odkladu. Taková změna nabývá účinnosti až
okamžikem, kdy je druhé Straně doručeno písemné upozornění o změně.

Všechny dokumenty mající vztah k plnění této Smlouvy, zápisy z jednání a dodatky ke smlouvě, musí
být podepsány oprávněnými osobami obou Stran nebo jejich zástupci.

Článek 6

Závěrečná ujednání

Tato Smlouva nabývá platnosti ke dni podpisu Smlouvy Stranami. V případě akce hrazené
z investičních prostředků Objednatele nabývá Smlouva účinnosti ke dni, kdy bude Zhotoviteli ze strany
Objednatele doručeno oznámení, že Objednateli bylo schváleno Stanovení výdajů financování akce ze
státního rozpočtu ze strany příslušného správce rozpočtové kapitoly, tedy ze strany Ministerstva práce
a sociálních věcí. Nedojde--|i k tomuto Stanovení výdajů na financování předmětné akce, a to ani do
120 (jednostodvaceti) kalendářních dnů od dne nabytí platnosti Smlouvy, Smlouva se od svého
počátku ruší. Strany nejsou v takovém případě povinny hradit si navzájem účelně vynaložené náklady

Parafováno: Zhotovitel: Objednatel: strana 2/5

.„
W .

a prohlašují, že mezi Stranami neexistují žádné závazky a/nebo néroky, jejichž uplatnění by mohla

druhá Strana požadovat.

6.2. Objednatel se zavazuje dodat Zhotoviteli veškeré podklady pro potřeby plnění Díla dle této Smlouvy v
českém jazyce. V případě potřeby jakýchkoliv dalších podkladů je Zhotovitel povinen takovéto
podklady od Objednatele včas písemně vyžádat.

6.3. Veškeré dodatky ke Smlouvě a její změny musí být vyhotoveny písemnou formou.

6.4. Smlouvou neupravené skutečnosti se řídí příslušnými ustanoveními RS.

6.5. Smlouva je vyhotovena v 5 (pěti) stejnopisech, z nichž 3 (tři) obdrží Objednatel a 2 (dva) Zhotovitel.

6.6. Obě Strany svým podpisem stvrzují, že Smlouva nebyla ujednána v tísni ani za jednostranně
nevýhodných podmínek.

6.7. Nedílnou součástí Smlouvy jsou přílohy:

Příloha č. 1 — Specifikace Díla

Příloha č. 2 — Podmínky plnění

6.8. Strany prohlašují, že si tuto Smlouvu, včetně jejich příloh, přečetly, jejímu obsahu porozuměly a že je
projevem jejich pravé a svobodné vůle prosté jakéhokoliv omylu, na důkaz čehož tuto Smlouvu

vlastnoručně podepisují.

Objednatel: Zhotovitel:

Jméno: Jméno:

Funkce: Funkce:
Datum: Datum:
Místo: Místo:

Parafováno: Zhotovitel: Objednatel:

strana 3/5
NPříloha č. 1 — Specifikace Díla
Předmětem plnění dle této Smlouvy je ...................................
1 Specifikace předmětu plnění
Předmětem realizace je ....................................
Součástí dodávky bude především

Specifikace ceny

3 Harmonogram plnění
Níže uvedený harmonogram plnění je relativní vůči okamžiku, kdy Smlouva nabyde účinnosti (níže
označeném T).
Projektové milníky:

T+
T+

Parafováno: Zhotovitel: Objednatel: strana 4/5

-a
W .

Příloha č. 2 - Podminky plnění

Součinnost Objednatele
Nutným předpokladem pro řádné plnění dle Smlouvy je zajištění součinnosti Objednatele a dalších externích

subjektů zodpovědných za realizaci a úpravy informačních systémů, které s plněním Díla bezprostředně
souvisejí.

Technická součinnost

Analytická součinnost

Legislativní součinnost

Personální předpoklady a role

Projektové předpoklady

Parafováno: Zhotovitel: Objednatel: strana 5/5

10 000+

2020-22

600+

rok 2020 zdarma

Textová podoba smlouvy Smlouva č. 2013914: Dodatek č. 1 Dílčí smlouvy č.RS/DS_PDS II/07 k rámcové smlouvě (APV

Příloha 150050009.pdf

Přehledy

K-IndexIndex klíčových rizik úřadů

Žebříčky K-Indexu

Platy v nejdůležitějších úřadech

Firmy / subjekty

Speciální reporty

Rady pro uživatele Registru smluv

Statistiky smluv

Speciální reporty

Smlouvy uveřejněné konkrétní den

Zakázky podle oborů

Zakázky podle zadavatelů

10 000+

2020-22

600+

rok 2020 zdarma

Hlídač státu

Podpořte nás!

Textová podoba smlouvy Smlouva č. 2013914: Dodatek č. 1 Dílčí smlouvy č.RS/DS_PDS II/07 k rámcové smlouvě (APV

Příloha 150050009.pdf

K-Index
Index klíčových rizik úřadů