Příloha č. 1 – Specifikace smlouvy

1 POPIS NABÍZENÉHO PLNĚNÍ VEŘEJNÉ ZAKÁZKY

Nabízené plnění bude Dodavatel poskytovat bez využití subdodavatelů.

1.1 Shrnutí nabídky

V následující tabulce je uvedeno shrnutí (výčet) plnění základních požadavků zadavatele kladených na realizaci „Registr IKP“ podle zadávací dokumentace. V tabulce je pro každý požadavek uveden odkaz do zadávací dokumentace (pokud není uvedeno jinak, jde o přílohu „Funkční specifikace“) a odkaz do konkrétní kapitoly/podkapitoly nabídky uchazeče.

Požadavek Zadavatele

Základní popis

Odkaz Zadávací dokumentace

Odkaz na kapitolu/podk apitolu

Uchazeče

Datová základna IKP,

Nahlížení na IKP

Vybudování datové základny registru IKP, aplikační a prezentační vrstvy pro provádění aktivních operací a následné zobrazování dat konkrétního konta pojištěnce.

Možnost přístupu přes zadané RČ/EČP nebo z hromadného výpisu kont.

Včetně zobrazování informací o NP, IVK, IOLDP, pobírání důchodu.

Klasifikace kont.

Podpora VIP.

Funkční specifikace 3.1.1

1.2.3

1.3.2.1.1

Nástroj pro hromadnou práci s konty

Universální nástroj pro hromadnou práci s konty s možnostmi

- vyhledávání kont dle dostupných kritérií

- uložení vyhledávacích podmínek pro pozdější využití

o tisk seznamu kont splňujících zadaná kritéria

o hromadná oprava UIP

Funkční specifikace 3.2.1, odst. 2

3.2.4, odst. 1

3.2.4, odst.

2, bod 4

1.3.2.1.1

ID	Požadavek Zadavatele	Základní popis	Odkaz Zadávací dokumentace	Odkaz na kapitolu/podk apitolu Uchazeče
		o hromadné přešetření UI45_INP o hromadné automatizované sestavení IVK o hromadný tisk a odeslání IVK o statistiky kont V seznamu kont lze proklikem vybrané položky přejít na detail konta konkrétního případu.
3	Automatizov ané sestavování IVK	Řízení a správa automatizovaného sestavení IVK u kont, které splňují definované podmínky. Integrace na související služby pro uložení výpisu do DB_IVK, včetně zajištění komunikace se systémem PReS v případě požadavku na zajištění odeslání výpisu pojištěncům.	Funkční specifikace 3.2.1, odst. 5 3.2.4, odst. 2 3.2.4, odst. 3	1.3.2.1.1 1.3.2.1.2
4	Zakládání požadavků ve Worku	Možnost vytváření požadavků Work pro zajištění opravných zpracování podle pokynů uživatelů registru IKP. Lze vyvolávat jednotlivě na konkrétní případ, nebo hromadně na vybranou množinu případů. Integrace se službami WORK Včetně automatického generování požadavků do Work v návaznosti provádění průběžných aktualizací kont.	Funkční specifikace 3.2.1, odst. 4 3.2.3 3.2.2	1.3.2.1.1 1.3.4.3
5	Sestavy spojené s průběžným automatizov aným vytvářením požadavků do WORK	Dostupnost sestav, které shrnují stav aktualizovaných kont a sestav, které určují, která konta jsou/nejsou předmětem průběžných aktualizací.	Funkční specifikace 3.2.2	1.3.2.1.1 1.3.4.3
6	Nepokrytá doba pojištění	Sledování a evidence atributu Nepokrytá doba pojištění u konta případu. Možnost využití tohoto kritéria (včetně parametru délky nepokryté doby pojištění) při hromadné práci s konty a všech	Funkční specifikace 3.2.1, odst. 6 3.2.4, odst. 2	1.3.2.1.1

ID	Požadavek Zadavatele	Základní popis	Odkaz Zadávací dokumentace	Odkaz na kapitolu/podk apitolu Uchazeče
		případných návazných hromadných akcí a statistik.
7	Hromadný tisk IVK (PReS)	Podpora zajištění hromadného tisku a odeslání připravených výpisů s využitím integračních vazeb na systémy IVK, PReS. Součástí je získání potřebných dat (adresní údaje, sestavený výpis), provedení případných dodatečných kontrol (např. ověření úmrtí) a řízení integrace se systémy IVK a PReS. Řízení provedení – sledování průběhu a výsledku, dostupnost přehledu výsledků zpracování za skupinu požadavků.	Funkční specifikace 3.2.1 odst. 7 3.2.4, odst. 2, bod 4	1.3.2.1.1 1.3.4.2
8	Statistiky	Statistiky shrnující aktuální i historické informace o stavu kont a počtu kont pojištěnců ve vztahu ke kritériím dostupným v registru IVK, včetně vazby na stav nárokových podkladů.	3.2.1, odst. 1	1.3.2.1.1
9	Podpora uživatelskýc h rolí	Podpora uživatelských rolí v systému AAA (předpokládá se Prohlížeč, Statistik, Work, Generování IVK, Odesílání IVK, Audit).	Funkční specifikace 3.2.1, odst. 9	1.3.2.1.1
10	Audit operací	Průběžné udržování informací o přístupech a akcích prováděných uživateli APV IKP v rozsahu: uživatel, typ operace, datum a čas. Zpřístupnění těchto auditních údajů pověřeným pracovníkům, podpora vyhledávání, třídění, tisku.	Funkční specifikace 3.1.1, odst. 7 3.2.1, odst. 8 Technické požadavky Kapitola 2.	1.3.2.1.1
11	Sledování změn v okolních systémech - KE	Aktualizace konta na základě změn v systému KE (v rozsahu změn RČ/EČP, úmrtí osoby)	Funkční specifikace 3.1.2	1.3.4.4
12	Sledování změn v okolních systémech - INP	Aktualizace konta na základě změn v systému INP (zejména nově příchozí doklady, změny atributů dokladů, změna obsahu JDV).	Funkční specifikace 3.1.2	1.3.4.1

ID	Požadavek Zadavatele	Základní popis	Odkaz Zadávací dokumentace	Odkaz na kapitolu/podk apitolu Uchazeče
13	Sledování změn v okolních systémech – IVK	Aktualizace konta na základě změn v systému IVK (zejména vytvoření a odeslání nového IVK/IOLDP).	Funkční specifikace 3.1.2	1.3.4.2
14	Sledování změn v okolních systémech - DA	Aktualizace konta na základě změn v systému pro sledování DA (zejména přírůstky a zániky důchodů, dostupnost dob v SRD-A).	Funkční specifikace 3.1.2	1.3.4.5
15	Prvotní naplnění IKP	Prvotní iniciace dat na základě údajů z integrovaných systémů. Pro založení konta pojištěnce v Registru IKP je rozhodné, zda je pro jeho RČ/EČP v DB_INP přítomen alespoň jeden NP.	Funkční specifikace 3.1.3	1.3.3.3
16	Podpora historie	Změny dat v Registru IKP jsou zaznamenávány do historické části databáze.	Funkční specifikace 3.1.1, odst. 6	1.3.3
17	Historizace údajů	Systém musí umožňovat historizaci údajů a práci s historií.	Technické požadavky Kapitola 2.	1.3.3
18	Práce s daty v dlouhých transakcích	Systém musí umožňovat práci v dlouhých transakcích – tj. umožnit modifikaci dat ve speciálních dlouhotrvajících transakcích za účelem přípravy, validace a verifikace budoucí vrze dat. Systém musí umožnit schválení dlouhé transakce a promítnutí změn do hlavní verze dat.	Technické požadavky Kapitola 2.	1.3.3
19	Komunikace s ostatními systémy pomocí sběrnice	Zadavatel preferuje komunikaci IKP s ostatními systémy pomocí integrační sběrnice	Technické požadavky Kapitola 2.	1.3.4.6
20	Preferované technologie	Dodávaný systém jako celek i technologie použité pro integraci musí odpovídat standardům IKT definovaným pro prostředí Zadavatele.	Technické požadavky Kapitola 3.	1.3.2.1.4
21	Dodávka tří	Zadavatel vyžaduje dodávku tří prostředí:	Technické	1.3.2.1.4

Požadavek Zadavatele

Základní popis

Odkaz Zadávací dokumentace

Odkaz na kapitolu/podk apitolu

Uchazeče

prostředí

- Produkční

- Integrační

- Školící/testovací

požadavky Kapitola 4.

Technicko- provozní parametry

řešení

Tecniko-provozní parametry řešení

Funkční specifikace Kapitola 4.2.

1.3.2.1.4

1.2 Funkční specifikace řešení

Hlavním přínosem tohoto projektu je zavedení mechanismů, které povedou k vyšší automatizaci konsolidace kont pojištěnců a umožní referentům správy údajové základny transparentnější pohled na aktuální stav jednotlivých kont.

Dalšími přínosy automatizované konsolidace kont pojištěnců jsou

• zkrácení nutné doby pro zpracování konsolidace, ta vychází z automatické klasifikace chybných nárokových podkladů (dáno automatickými výběry chybných údajů z databáze INP).

• možnost provádět konsolidace s nižšími nároky na personální zajištění.

Z pohledu současných informačních systémů oblasti nárokových podkladů bude registr IKP fungovat jako správce metadat jednotlivých nárokových podkladů a s tím souvisejících údajů evidovaných pro konkrétního pojištěnce.

Po základní dekompozici věcných požadavků na Registr IKP bude vlastní řešení rozděleno do implementace v několika systémech:

• Vytvoření nového Registru IKP

• Integrace na okolní systémy v návaznosti na potřeby informačního zajištění Registru IKP

o Integrace na oblast Správy nárokových podkladů DP (INP, IVK)

o Integrace na oblast Kmenových evidencí (informace o úmrtí)

o Integrace se zdrojem informací z důchodové agendy (poživatelé důchodů)

o Integrace se systémem procesního workflow DIGI aplikací (systém WORK)

Základními rysy řešení Registru IKP je centralizované řešení aplikační a databázové vrstvy s možností využití centralizovaného uživatelského rozhraní. Řešení budou postavena na principech třívrstvé architektury s maximálním využitím obecně platných standardů, moderních principů architektury informačních systémů a standardů Zadavatele. Použité návrhové principy zajistí dostupnost uživatelských funkcí poskytovaných na GUI rozhraní nejen ústřednímu pracovišti, ale i ostatním pracovištím v ČSSZ.

Veškeré komponenty navrhovaného řešení budou vyvinuty plně v souladu se standardy

ČSSZ.

Č.	Název souboru	Název dokumentu	Verze
1.	std_db_060803_v0.91.doc	Standard databází	0.91
2.	std_inet_1-10.doc	Standard připojení k Internetu	1.10
3.	std_pošta_1-00d.doc	Standard poštovního systému ČSSZ	1.00
4.	Std_AD_DNS_DHCP_NTP_1-34.pdf	Standard AD DNS DHCP	1.34
5.	Std_AVO1-10.doc	Standard Antivirové ochrany	1.10
6.	Standard systémové konfigurace pracovní stanice 2.0	Standard systémové konfigurace pracovní stanice	2.00
7.	Std_mgmt_v.0.54.doc	Standard Management	0.54
8.	std_metodikavyvoje_apv_1_0_19.doc	Standard metodiky vývoje	1.0.19
9.	std_pravidlareleasemanagementu_apv_1_2_6.pdf	Předávání APV a release	1.2.6
10.	std_net_1-92.doc	Standard síťové infrastruktury	1.92d
11.	Programatorskekonvence_1_0_17.doc	Programátorské konvence .NET 2.0, 3.0. a 3.5	1.0.17
12.	BizTalkDevelopmentStandard.v1.00.doc	Standardy pro tvorbu aplikací pro Microsoft BizTalk server	1.00
13.	AAA_Pozadavky_na_aplikace_7.01.pdf	Požadavky na nové aplikace při integraci do AAA portálu	7.01
14.	Standard_pro_tvorbu_skriptu_db_Oracle_0.2.doc	Standard pro tvorbu, předávání a spouštění skriptů v databázích Oracle	0.2
15.	CSSZ_DMS WS_API_DMA_v2 9_100212.doc	API ROZHRANÍ SYSTÉMU DMA: WS_API_DMA - Standard rozhraní pro ukládání dokumentů do DMS	2.9
16.	CSSZ_DU_STD_V011.1.doc	Standard provozu databáze Oracle	1.10
17.	std_srv_0.15	Standard systémové konfigurace aplikačních serverů - Standard Image	0.15
18.	std_PKI.pdf	Standard pro PKI	1.0

1.2.1 Obecný přístup k projektům se začleněním SOA

U projektů, které zahrnují zavedení služeb (v pojetí SOA), je nutno počítat s riziky, které vyplývají ze specifických charakteristik architektury orientované na služby a integrace se stávajícími systémy. V následujícím textu uvádíme vybrané klíčové aspekty, které je nutno mít na zřeteli, spolu s přístupy k omezení nejčastějších rizik a důvodů selhání SOA projektů. Níže uvedené principy a opatření jsou součástí našeho projektového přístupu k realizaci a prvky kontrolních mechanismů kvality projektu.

Stanovení cílů projektu zavedení služeb – cílového stavu po dokončení projektu. Zde je situace jednodušší, protože předmětem projektu není komplexní přepracování informačního systému nebo jeho budování od základů na zelené louce. Cíle jsou jasně stanoveny předmětem projektu zavedení Registru IKP. Při určitém zjednodušení se dají formulovat jako

• Vytvořit systém automatizovaného zpracování nárokových podkladů a konsolidace kont pojištěnců.

• Zpřístupnit informace o aktuálním stavu jednotlivých kont.

Určení měřítek úspěšnosti projektu zavedení nových služeb a integrace s původním informačním systémem. Pro vlastníky procesů, kterých se projekt dotkne nebo je ovlivní, musí existovat srozumitelná a měřitelná kritéria, jejichž pomocí bude možné vyhodnotit, zda se podařilo naplnit očekávané cíle a přínosy. Metriky by měly být stanoveny předem a měly by zahrnovat jak finanční kritéria (zisky respektive úspory ze zavedení proti stávajícímu stavu), tak kvalitativní (např.: menší počet oprav, stížností, kratší časy na vyřizování atp.).

Silná architektura projektu. V rámci projektu, který realizuje řešení založené na službách a jejich procesní integraci, je jednou z klíčových aktivit návrh celkové architektury. Nezbytným předpokladem je zpracování procesní analýzy a dekompozice na úroveň služeb. Součástí architektonického návrhu je nejen zpracování modelu nově vytvářených součástí systému, ale i stanovení způsobu integrace a začlenění do stávající architektury informačního systému organizace, kdy se předpokládá, že výsledné řešení je sestaveno z kombinace existujících aplikací a systému s nově doplněnými komponentami a službami. Architektura musí aktivně působit během celého životního cyklu: identifikace potřeb 🡪 analýza požadavků 🡪 modelování systému 🡪 vývoj řešení🡪nasazení technologií a produktů 🡪 monitoring provozu 🡪 vyhodnocení parametrů 🡪 identifikace možností k vylepšení / rozvoji. Pro tuto činnost využívá portfolio nástrojů, standardů, metodik, referenčních implementací a postupů (best practices). Jednou z kritických aktivit je průběžná komunikace architekta připravovaného řešení s vlastníky procesů, s architektem

současného informačního systému, se zástupci provozu, se sponzorem projektu, s vlastníky dat a dalšími zainteresovanými stranami, zejména pak s managementem IT.

Správná formulace a pojetí služeb. Příčinou mnohých problémů v projektech zavedení SOA je zúžené chápání služeb. Jejich redukce na technický prostředek integrace a komunikace aplikací na úrovni webových služeb. Klíčové je korektní pojetí zejména ze strany garantů služeb, kteří je budou provozovat a zajišfovat. Pokud při zavedení SOA budou převažovat technické aspekty, hrozí, že projekt nenaplní „obchodní“ cíle.

Vyvážená definice granularity služeb. Při návrhu je třeba korektně balancovat míru přidané hodnoty služby, hrozící její komplexností, na jedné straně a znovu-použitelnost služby směřující k jednoduchosti až k primitivnosti. Služby musí být dostatečně univerzální, aby je bylo možno využívat ve více procesech, respektive v kompozicích služeb, ale na druhou stranu nesmí být příliš elementární, aby sestavení služeb do procesu nebo vytvoření kompozitní služby nelimitovalo k základnímu návrhu a programování aplikace.

Integrace existujících aplikací. U existujících monolitických aplikací nebo tzv. „aplikačních sil“ je nutné provést „inventuru“ disponibilní funkcionality a identifikovat funkčnosti ve vztahu k procesům, zajišfovaným organizací, respektive k novým procesům, zaváděných projektem. Následně musí být provedena refaktorizace business funkcí do podoby znovu- použitelných služeb, poskytujících „obchodní“ hodnotu. Tyto služby je pak možné do nově nasazovaných procesů začlenit vytvořením adaptérů a překryvných modulů (wrapper).

Jednoznačné definování poskytovatelů a konzumentů služeb. Je nutné zdůraznit, že určení poskytovatelů (garantů) služeb, jejich zákazníků a podmínek využití, zde není pojímáno z čistě provozního pohledu – ten je pouze nutnou podmínkou fungování.

• Poskytovatele dílčích služeb je nutno chápat z pohledu koncepčního jako „nositele“ nebo „tvůrce“ obchodních hodnot, kteří jsou schopni služby rozvíjet a zlepšovat. Z toho důvodu by pro služby měli být stanoveni business analytici, kteří detailně rozumí jejich předmětu, podmínkám fungování a poskytovaným hodnotám a to i v širším kontextu procesů, do nichž je služba začleněna.

Jedním z důležitých hledisek je i to, že poskytovatelé služeb jsou vlastníci a správci dat a proto je jejich úzká spolupráce a zainteresování v projektu rozhodující.

• Stejně tak důležité je, aby služby měly stanoveny konzumenty. Pro návrh a zavedení služby musí být stabilní důvod, kterým je potřeba vyjádřená klienty služby. Je problematické zavádět služby, které vyplývají pouze z architektury a nebudou mít reálné odběratele, protože takové jsou často odsouzeny k zániku. Výjimkou může být pouze technická úroveň daná dekompozicí služeb, ale i zde je nutno obhájit jejich existenci a přidělit garanta. Protože se v těchto případech

pohybujeme na technické úrovni, může jím být IT oddělení. Klienty služby by však nakonec měli být business uživatelé a to alespoň zprostředkovaně přes jiné služby.

Zavedení prostředků a postupů pro řízení služeb (SOA/ service governance). Součástí tohoto procesu není pouze implementace technických nástrojů pro monitorování chodu služeb a vyhodnocování provozních záznamů. To je pouze nutným předpokladem. Jedním z klíčových prvků je stanovení podmínek poskytování jednotlivých služeb a zejména měřítek pro hodnocení kvality jejich poskytování.

1.2.2 Popis funkcí a procesů podpory Registru IKP

Oblast správy údajové základny ČSSZ patří mezi základní procesní oblasti, které vymezují nutné činnosti pro zajištění výkonu kompetencí související s hlavními agendami důchodového a nemocenské pojištění.

Jedním z procesů správy údajové základny je Evidence nárokových podkladů, který lze rozdělit na následující podprocesy:

• Příjem nárokových podkladů (z vnějších i vnitřních zdrojů)

• Klasifikace dokladu (identifikace, přiřazení)

• Vytěžení datových vět

• Uplatnění logických testů

• Konsolidace, opravná zpracování nárokových podkladů

• Sestavení informativního výpisu dob pojištění pro pojištěnce

• Poskytování podkladů pro rozhodování o dávkách důchodového pojištění

• Správa individuálního konta pojištěnce

V rámci této nabídky bude zajištěna aplikační podpora některých činností podprocesu Správy individuálního konta pojištěnce.

Popis dílčích činností, které jsou součástí podprocesu Správa Individuálního konta pojištěnce, jsou předmětem následujících kapitol.

Činnosti:

• Sledování změn nárokových podkladů

• Manuální zápis požadavků na opravu kont pojištěnců

• Sledování změn údajů v KE

• Sledování změn v důchodové agendě

• Sledování změn IVK

• Příprava podkladů pro automatizované generování individuálního výpisu dob pojištění z konta pojištěnce (IVK)

• Zobrazení dat o konkrétním případu

• Audit přístupů a operací v rámci individuálního konta pojištěnce

• Vytvoření sestav a statistik na základě údajů IKP

Činnosti mimo IKP, které ovlivňují NP

• Požadavek na přípravu NP na základě žádosti o důchod

• Požadavek na přípravu NP na základě žádosti o IOLDP

Jedná se požadavky, které jsou zpracovávány v rámci DIGI aplikací a mají přímý vliv na stav nárokových podkladů, resp. konsolidaci příslušných kont pojištěnců. Tyto požadavky nejsou přímo řešeny aplikací APV IKP, nicméně výsledek takových procesů bude v IKP zaznamenán, protože provedení změn na úrovni nárokových podkladů bude do IKP promítnuto.

1.2.2.1 Automatická aktualizace konta na základě změny nárokových podkladů

Cíl

činnosti

Automaticky aktualizovat stav individuálního konta na základě změny nárokových podkladů

Popis

Na základě změny (doplnění nového, zneplatnění, přeřazení a opravy stávajícího) nárokového podkladu jsou údaje o změně automaticky

činnosti

přeneseny do registru IKP a zapsány do konta pojištěnce. Poté je automaticky provedeno nastavení typu konta. Pokud doklad byl zařazen do klasifikační skupiny 1. je automaticky provedeno sestavení IVK.

Změny související s vygenerovanými IVK a nepokrytými dobami pojištění jsou do IKP přeneseny pomocí činnosti sledování změn IVK (kap. 1.2.2.9).

Pokud byl doklad zařazen do klasifikační skupiny č. 2 nebo 5 je automaticky předán požadavek na konsolidaci dokladů pro dané RČ prostřednictvím WORK.

act System sledov ani zmen v NP

Nárokové podklady

Registr IKP

IVK

Změna

dokladu v NP

Klasifikace změněného dokla du

Zpracování

v stupního podnětu o změně NP

Aktualizace konta pojištěnce o údaje NP

Nastavení typu konta

Doklad zařazen do skupiny 1?

[ano]

Požadav ek na

v ygenerování IVK

Sestav eni IVK

Zpracov ání výsledku

požadav ku na

vygenerov ání IVK

WORK

Doklad ve skupině 2 nebo 5?

Konec zpracování

[ne]

[ano]

Ov ěření existence požadav ku

v e WORK

(::)

Vytv oření požadav ku do Work

Existuje RČve WORK?

Konec zpracování

Požadavek již ve zpracování

Zařazení nového požadavku

1.2.2.2 Manuální zápis požadavků na opravu kont pojištěnců

Cíl

činnosti

Aktualizovat stav individuálního konta na základě manuálního požadavku uživatele.

Popis

činnosti

Systém umožní uživateli vytvářet sestavy požadavků na opravu kont pojištěnců na základě dotazů nebo filtrů vycházejících z aktuálního stavu kont pojištěnců.

Na základě těchto sestav jsou automaticky vygenerovány požadavky na opravy kont a po ověření duplicit předány do systému Work.

act Manuální zadání požadav ků na oprav u kont

Registr IKP

Work

Požadavek na opravu konta

Výběr kont k oprav ě

Audit operace

Xxxxxxxxx ání požadav ků na oprav u konta

Ověření existence požadav ku na stejné RČ v e Work

Vytvoření seznamu v ýsledku zařazení do zpracov ání WORK

Zpracov ání v ýsle dku zařazení do zpracov ání ve WORK

Jedná se o duplicitní požadavky?

[Ano]

[Ne]

Požadavek je j iž ve zpracování

Zažazení požadavků do zpracování

act Sledov ání změn v KE

Aktualizační soubor s referenčními údaji

Kmenov é ev idence (KZR)

1.2.2.3 Sledování změn v KE

Cíl

činnosti

Automaticky udržovat integritu spravovaných údajů o pojištěnci s vybranými kmenovými údaji ČSSZ.

Popis

činnosti

Pro předávání změněných údajů v kmenových evidencích navrhujeme využít mechanismu pro předávání změn, který je připraven pro mainframe. Tento soubor je generován systémem KZR při zápisu změn do KE.

Z pohledu klasifikace konta budou automaticky sledovány údaje o úmrtí pojištěnce a změna jmenných a adresních referenčních údajů, který bude mít vliv na přiřazení příslušného typu skupiny („konto zemřelého“).

Registr IKP
Automatický
podnět k
získání
aktualizací
	Aktualizace kont o
Zpracov ání	v ybrané kmenov é údaje
aktualizačního	údaj e
souboru
Mají změny vliv
na klasifikaci
konta? [ano]
[ne]	Klasifikace konta
	(přiřazení typu
	konta)
Konec
zpracování

1.2.2.4Sledování změn v důchodové agendě

Cíl

činnosti

Automaticky udržovat integritu spravovaných údajů o pojištěnci s vybranými údaji důchodové agendy.

Popis

činnosti

Údaje ze souborů SQ serveru důchodové agendy budou předávány do APV IKP

Z pohledu klasifikace konta budou automaticky sledovány údaje o přímých důchodech a informace o existenci OLDP uloženém v SRD_A. Tyto údaje mohou mít vliv na přiřazení příslušného typu skupiny.

act Sledov ani zmen DA

Registr IKP

Automatický podnět k získání aktualizací

Aktualizační soubor s v ybranými údaji z důchodov é agendy

Zpracov ání v ybranch údajů z důchodov é agendy

Aktualizace kont o v ybrané údaje

Mají změny vliv na typ konta?

[ne]

[ano]

Nastav ení nov ého typu konta

Konec zpracování

1.2.2.5 Automatizované generování individuálního výpisu dob pojištění z konta pojištěnce (IVK)

Cíl

činnosti

Umožnit pomocí registru IKP generovat individuální výpisy pojištění na základě zvolených sestav

Popis

činnosti

Oprávněný uživatel vytvoří pomocí APV IKP sestavu případů určených k automatizovanému generování.

Na základě sestavy pro automatizované generování IVK provede APV IKP vygenerování výpisů z kont pojištěnců, tyto výpisy budou uloženy v DB IVK a připraveny k odeslání klientům. Dalším výstupem

z generování je seznam odmítnutých případů při sestavování IVK.

Změny související s vygenerovanými IVK a nepokrytými dobami pojištění jsou do IKP přeneseny pomocí činnosti sledování změn IVK (kap. 1.2.2.9).

Na základě pokynu oprávněného uživatele APV IKP jsou předpřipravené výpisy hromadně vytištěny a připraveny k expedici klientům.

act Automatizované generování IVK

Požadavek na vytvoření sestavy pro generování IVK

APV IKP

IVK

Vytv oření sestav y případů pro generov ání IVK

Audit operace

Vygenerov ání IVK

Požadovány úpravy konta?

Vytvoření sestavy

případů, které vypadly při

generování IVK

[ne]

Uložení

v ygenerov aných IVK

Konec zpracování

Uložení sestav y

Zpracování v ýsledku sestavy pro

generov ání IVK

[ano]

Work

Požadavek na odeslání IVK klientům

Výběr z

připav ených IVK

Vytv oření požadav ku na zpracov ání v e Work

Požadavek zažazen do zpracování

Audit operace

Vytv oření požadavku na tisk

IVK v PreS

PreS

Tisk IVK a připrava na expedici

1.2.2.6 Zobrazení dat o konkrétním případu

Cíl

činnosti

Umožnit oprávněnému uživateli přístup k údajům spravovaných v APV IKP.

Popis

činnosti

Veškeré uživatelské přístupy (náhledy, výběry) k údajům APV IKP jsou auditovány. Dále při zpracování uživatelského požadavku na údaje je ověřeno, že příslušný uživatel má přístup k příslušnému kontu pojištěnce (kontrola na VIP).

act Zobrazení údaj ů o konkrétním případu

APV IKP

Požadavek na náhled na údaje

Výběr případu

Audit operace

Má uživatel právo pracovat s případem?

[Ne]

Ukončení náhledu na případ

[Ano]

Poskytnutí náhledu na údaje uživateli

1.2.2.7 Vytvoření sestav na základě údajů IKP

Cíl

činnosti

Umožnit uživateli vytváření sestav z údajů APV IKP

Popis

činnosti

Veškeré uživatelské přístupy k údajům APV IKP jsou auditovány. Dále při zpracování uživatelského požadavku na údaje je ověřeno, že příslušný uživatel má přístup k příslušnému kontu pojištěnce (kontrola na VIP).

Uživateli je nabídnuta možnost uložit sestavu pro další zpracování.

act Vytv oření sestav na základě údajů APV IKP

APV IVK

Požadavek na vytvoření sestavy

Výběr kritérii pro v ytv oření sestav y

Audit operace

Prov edení

v ýběru případů

Ov ěření

uživ atelských práv k j ednotliv ýcm případům

Zobrazení

výseldné sestavy uživateli

Bude sestava využita pro další použití?

[Ne]

Odstranění případů z v ýběru, na které

uživ atel nemá práv o

[Ano]

Uložení sestav y pro další použití

1.2.2.8 Audit přístupů a operací v rámci individuálního konta pojištěnce

Cíl

činnosti

Auditovat veškeré uživatelské operace a přístupy v rámci APV IKP

Popis

činnosti

Veškeré uživatelské operace a přístupy jsou auditovány. Audit jednotlivých činností je zahrnut již v rámci jejich popisu, viz „aktivity digram“ jednotlivých činností.

Přístup k auditním informacím je řešen stejně jako i k ostatním údajům spravovaných v rámci IPV IKP, viz popis činnosti „Zobrazení dat o konkrétním případu“.

Cíl

činnosti

Automaticky aktualizovat stav individuálního konta na základě změny v evidenci IVK.

Popis

činnosti

Na základě změny IVK( vytvoření nového IVK, odeslání IVK, atp.) jsou údaje o této změně automaticky přeneseny do registru IKP a zapsány do konta pojištěnce.

Poté je provedeno ověření typu kontu konta a případné nastavení nového typu.

1.2.2.9 Sledování změn v evidenci IVK

act Sledov ání změn IVK

IVK

Registr IKP

Změna v IVK

Zpracov ání

v stupního podnětu z IVK

Aktualizace konta poj ištěnce o údaj e IVK a

nepokrytých dobách poj ištění

Má změna v IVK vliv na typ konta?

[ano]

Nastav ení nov ého typu konta

[ne]

Konec zpracování

1.2.3 Návrh konceptuálního datového modelu IKP

1.2.3.1 Konceptuální datový model v UML notaci

Následující schéma popisuje konceptuální datový model registru IKP. Schéma lze z logického pohledu rozdělit na dvě části. V jedné části jsou spravovány údaje konta. Konto je jednoznačně navázáno na pojištěnce a jeho jednoznačnou identifikaci. Pro účely optimalizace poskytovaných údajů předpokládáme v rámci entity „pojištěnec“ základní údaje k identifikaci pojištěnce – RČ/EČP, jméno a příjmení, atp. viz detailní popis v následující kapitole. Dále jsou v této části udržovány vazby na nárokové podklady, IVK výpisy, údaje z DA a vlastní historie změn konta pojištěnce.

class Konceptuální datov ý model

IKP audit Poj ištěnec

Fronty

Interní

Externí

Nárokov ý podklady

Seznamy Work

1..*

Konto

Seznamy

Výpis IVK

0..*

Generov ání IVK

0..*

Údaje z EDS-A

Historie konta

Statistiky

Vrácené IVK

Druhá část konceptuálního modelu obsahuje entity nutné pro zajištění uživatelských funkcí registru IKP a entity nutné pro asynchronní integraci s okolními systémy. Jedná se o entity „Seznamy“ a „Fronty“. Jedná se o „technologické“ entity, které budou rozpracovány v rámci detailní analýzy projektu.

Samostatnou entitou v rámci konceptuálního modelu je „IKP audit“. Tato entita bude využívána pro ukládání auditních informací o uživatelských přístupech a operacích nad kontem pojištěnce.

1.3 Architektura, technická specifikace a integrace řešení

1.3.1 Začlenění Registru individuálních kont pojištěnců do IIS ČSSZ

ZDV

DMS klienti

UIP2

VZT klient

ZDD

Příjem podání

DUCH

UI3001 UI42

EXK

EDS

Správa dat

VZT

SI2 IPK

IKP DIGI

Infrastruktura

DAP

AAA

Základní model „big picture“ IIS ČSSZ ukazuje následující schéma. Schéma popisuje základní rozdělení systémů a APV do jednotlivých procesních oblastí. Ve schématu je žlutě zvýrazněno zasazení registru IKP do IIS ČSSZ.

pkg Big Picture

Průřezové procesy INS

MKV

KOC

Výběr pojistného

VPO

POJ

SPRIZ

DPOSVČ

DOPOJ

Průchozí subsystémy, docházkové subsystémy

Legenda

Oblast nasazení APV na ČSSZ

Aplikace Aplikace ATOS nasazená v produkčním prostředí

Modul APV

Oblast

UI08

VZT

UI44

Integrace

Elektronická spisová služba

Platforma pro říze ní a kontrolu proce sů

/PŘKPS/

Podpůrné systémy DMS ATV

Výplaty dávek

VYP

Výplaty dávek důchodového pojištění

Výplaty dávek nemocenského pojištění

Výkon agend

NEM LPS

Podpora rozhodování SAP BW

Statistiky

MIS

Správně ekonomické procesy EKIS

HR, Evid. majetku

Komunikace ČSSZ s vnějšími subjekty

OUT

Tisk ATT

TiskPres

INF

1.3.2 Celková architektura řešení

1.3.2.1 Konceptuální návrh řešení APV IKP

Konceptuální návrh architektury vychází z funkční dekompozice požadovaného řešení APV IKP a je reprezentován následujícím modelem. Jednotlivé funkční bloky jsou rozděleny do jednotlivých vrstev standardního třívrstvého modelu.

APV IKP

Datová vrstva

Auditní informace

Fronty OUT

Fronty IN

Konto pojištěnce

Aplikační vrstva

Integrace KE

Integrace s DB IVK

Integrace s DB INP

Správa interních front

Audit operací

Číselníky

Integrace EDS-Z

Zakládání

požadavků do Work

Požadavky na hrom. tisk IVK

Správa

generování IVK

Automatizované opravy konta

Klasifikace konta

Integrace DA

Poskytování

údajů okolním systémům

Aplikační

logika práce nad IKP

Klientská vrstva

Zobrazení

auditních informací

Hromadné akce

Náhled na

konto pojištěnce

1.3.2.1.1 APV IKP Návrh klientské aplikace

V rámci APV IKP budou vytvořeny dvě klientské aplikace:

• IKP Klient

Seznam komponent/modulů klientské aplikace IKP Klient:

• Integrace s AAA

• Náhled na konto pojištěnce

• Hromadné akce (správa seznamu případů, statistiky)

• Audit

Náhled na konto pojištěnce

Klientská aplikace IKP umožní oprávněnému uživateli náhled na konto pojištěnce. Jednotlivé informace jsou zobrazeny buď na základě:

• Dotazu na konkrétní případ (prostřednictvím RČ/EČP).

• Výběru konkrétního případu ze seznamu vybraných případů na základě zvolených kritérií.

Mezi zobrazované údaje patří:

• údaje evidované v rámci APV IKP - přehledné shrnutí vybraných atributů konta pojištěnce. Viz např. návrh obrazovky níže (stav konta, informace o očištění, nepokrytá doba pojištění, datum aktualizace konta, počty chybných NP v jednotlivých klasifikačních skupinách, výpis dávek, do nichž konto spadalo).

• jednotlivé nárokové podklady získané z DB_INP, jedná se např. o údaje:

o datum poslední aktualizace,

o datum uložení dokladu do DB_INP

o id_np (identifikátor nárokového podkladu)

o pořizovací, skenovací linka pro papírové doklady

o způsob přijetí nebo zápisu

o informace o tom, že se jedná o doklad určený k přešetření v rámci PA - povyměřovací

o …

• údaje evidované v DB_IVK, jedná se o seznam dostupných IOLDP a IVK, včetně typu (IOLDP/IVK), datumu a způsobu vytvoření (ref./aut.) a datum poslední aktualizace.

• údaje z důchodových agend, jedná se o údaje:

o datum poslední aktualizace,

o druh důchodu,

o datum přiznání a zániku,

o existence doby v SRD-A.

• identifikační údaje pojištěnce (vypisováno na základě aktuálního stavu v KE):

o RČ, EČP

o jméno

o příjmení

o rodné příjmení

o datum narození

o informace o úmrtí pojištěnce (ano;ne) + případné datum úmrtí

o informace o účasti v II. pilíři

Zobrazování nárokových podkladů z DB_INP a výpisů z konta pojištěnce z DB_IVK je provedeno obdobným způsobem jako v aplikaci PNP. K jednotlivým nárokovým podkladům je dostupné zobrazení zdrojové datové věty, jednotné datové věty, skenovaného obrázku a základního přehledu metadat. Dále je dostupné zobrazení seznamu realizovaných výpisů z konta pojištěnce, včetně informací o způsobu vytvoření a odeslání výpisu. Jednotlivé výpisy je možné zobrazit.

Specifickým případem jsou VIP případy. Pro tyto případy je zobrazena informace, že se jedná o VIP osobu a jednotlivé nárokové podklady nejsou přístupné.

Další dostupné funkce náhledu na konto pojištěnce, resp. klientské aplikace, jsou:

• „Historie aktualizací“ - zobrazí, jak a kdy bylo konto aktualizováno.

• „Akce“ - možnost vyvolání akcí nad kontem (založení Work požadavku, vytvoření IKP, tisk a odeslání).

Hromadné akce

Tato funkcionalita slouží pro hromadnou práci s konty. Nabízí možnost vyhledávání v kontech za pomoci všech dostupných vyhledávacích kritérií. Konkrétní nastavené vyhledávací podmínky lze uložit pro pozdější využití jako předdefinovaný výběr. S výsledkovou množinou kont lze provádět hromadné akce (např. oprava v UIP).

Vyhledávací kriteria

Pro usnadnění vyhledávání kont bude využita komponenta pro dynamické doplňování podmínek, která ulehčí práci s více konty najednou.

Základem konstrukce podmínky je výběr parametru a určení jeho požadované hodnoty. Jednotlivá kritéria mohou mít různé typy zadávaných hodnot, např. číslice, výběr (číselník), datumový rozsah.

Mezi podporovaná vyhledávací kritéria patří:

• ročník narození pojištěnce

• typ konta

• datum poslední aktualizace konta

• stav dokladu – zařazení dokladu do klasifikační skupiny

• důvod zařazení dokladu do klasifikační skupiny (např. informace o existenci JDV,

číslu chyby DV, typů dokladu, počtu dokladů bez vytvořené JDV apod.)

• muži x ženy

• informace o úmrtí osoby

• informace o pobírání důchodu

• informace o IVK, IOLDP

• informace o stavu zpracování ve WORKu

• informace o nepokryté době pojištění a její celkové délce

Konkrétní nastavení vyhledávacích kriterií lze uložit jako předefinovaný výběr pro pozdější využití.

Samotný výpis individuálních kont pojištěnců, který odpovídá zadaným kritériím, lze využít k několika účelům, např. zobrazení jednotlivých IKP, exportu, vyvolání dávky (hromadné akce – např. oprava v UIP), tisk nebo vyvolání statistiky.

Statistiky

Možnost vyvolání předdefinované statistiky z kont, která byla vybrána na základě definovaných kritérií. V samotné statistice jsou uvedena výběrová kritéria, za pomoci kterých byla konta pro statistiku vybrána.

Výsledné statistky budou sloužit k podání informace o aktuálním nebo historickém stavu kont a nárokových podkladů.

Klientská aplikace umožní export statistik a seznamu RČ/EČP do vybraného datového formátu pro další využití.

Příklady statistik:

a. Přehled počtů kont s rozdělením podle počtu chyb

Počet chyb	Celkem	Očištění
0	xxx	xxx
1	xxx	xxx
…	…	…
3	xxx	xxx

b. Rozdělení počtů dokladů podle skupin a důvodů

Skupina	Důvod	Celkem	Očištěno	Důvod - text
1	1000	xxx	xxx	popis
1	1010	xxx	xxx	popis
…	…	…	…	…
2	2010	xxx	xxx	popis
…	…	…	…	…
3	3010	xxx	xxx	popis
…	…	…	…	…
…	…	…	…	…

c. Počet kont

Celkem	Očištěno
xxx	xxx

Integrace s AAA

Klientská aplikace IKP Klient bude plně integrována se systémem AAA. Pro tyto účely bude využito komponenty vytvořené již v rámci realizace předešlých APV v prostředí IIS ČSSZ.

V rámci definice uživatelských rolí předpokládáme následující členění (detailněji navrhujeme specifikovat v rámci detailní analýzy):

• IKP Prohlížeč – náhled na konto pojištěnce

• IKP Statistiky – generování přehledových statistik pro sledování stavů kont pojištěnců

• IKP Work – správa požadavků na zpracování případu ve Work

• IKP IVK – generování sestav případů pro automatizované vytváření IVK

• IKP Odesílání IVK - generování sestav případů pro hromadné odesílání sestav IVK

• IKP Audit – prohlížení auditních informací

Zobrazení auditních informací

Klientská aplikace umožní vybraným uživatelům přístup k auditním informacím, které budou vytvářeny v rámci auditu operací v APV IKP.

Auditní informace budou uživateli zobrazeny v samostatném okně, které mu umožní náhled, třídění, filtrování a lokální tisk vybraných případů.

Veškeré operace s auditními údaji budou také auditovány.

1.3.2.1.2 APV IKP - Komponentní model aplikační vrstvy

V rámci střední vrstvy APV IKP budou implementovány následující serverové komponenty, jejich členění odpovídá věcnému rozdělení funkcionality:

• zakládání požadavků do Work,

• správa generování IVK,

• předávání požadavků na centrální tisk,

• aplikační logika nad kontem pojištěnce,

• klasifikace konta,

• audit operací,

• automatizované opravy konta,

• poskytování údajů okolním systémům

• číselníky.

Dále střední vrstva APV IKP bude integrována na:

• DB_IVK,

• údaje z DA,

• EDS-Z,

• KE,

• PreS

• SEC (číselníky DIGI)

• INP

• WORK

Výše zmíněné integrace jsou popsány v samostatné kapitole 1.3.4.

Aplikační logika nad kontem pojištěnce

Základní komponenta střední vrstvy IKP, která zpřístupňuje konto pojištěnce pro klientskou vrstvu aplikace. Jedná se o komponentu implementující serverovou logiku klientských funkcí a řízením přístupu k databázové vrstvě, mj. v rozsahu:

• provádění výběrů nad kontem pojištěnce,

• spouštění automatických dotazů (scheduler),

• řízení manuálních zápisů na konto pojištěnce.

Klasifikace konta

Komponenta provádějící automatickou klasifikaci konta při jakékoliv změně atributů příslušného konta nebo na základě uživatelského požadavku na provedení nové klasifikace.

V rámci klasifikace je kontu přiřazen typ konta podle specifických algoritmů a podmínek. Tyto algoritmy budou detailně analyzovány v průběhu analytické fáze projektu.

V návaznosti na provedení klasifikace konta bude provedeno automatizované rozhodnutí dalšího zpracování. V úvahu přichází možnost zadat požadavek na provedení opravy nárokových podkladů, nebo zajištění automatizovaného sestavení IVK.

Automatizované opravy konta

Jedná se o komponentu sledující změny ve zdrojových systémech, které mají vliv na klasifikaci konta.

Automatizované sestavení IVK

V rámci této kompotenty bude zajištěno řízení sestavení IVK, případně dále realizace tisku (předání k hromadným tiskům a archivace) pro následnou distribuci klientům. Vlastní vytváření IVK bude prováděno prostřednictvím příslušné služby systému IVK, ze strany registru IKP bude prováděno řízení a rozhodování o dalším postupu při zpracování. APV IKP bude technicky odpovědné za vyřízení každého požadavku na zpracování (řízení front podnětů, opakování integrace při zjištění technických problémů nebo nedostupnosti příslušných rozhraní).

Pro automatizované sestavení IVK budou stanoveny podmínky možného provedení.

Předpokládaný rozsah těchto podmínek:

• Ověření konta, ze kterého je IVK generováno, že je zařazeno do klasifikační skupiny 1.

• Vstupní datová věta odpovídá formátu JDV/IDV, resp. lze úspěšně dosáhnout tvaru IDV.

• IVK je generováno pouze z dob uložených DB INP (doby uloženy x XXXX jsou ignorovány).

• Do IVK budou doplněny součty dosažených dob pojištění.

• Do IVK budou doplněny intervaly neprokázaných dob pojištění.

Tato komponenta bude vytvářet i seznam odmítnutých případů z generování IVK, který bude zařazen do následného zpracování (viz popis klientské vrstvy). Součástí seznamu, bude i důvod odmítnutí jednotlivých případů.

Poskytování údajů okolním systémům

Zapojení registru IKP mezi ostatní systémy ČSSZ předpokládá také zpřístupnění informací o kontu pojištěnce dalším aplikacím. Za tímto účelem je definována vrstva služeb, které podporované aplikaci poskytnou informace o kontu pojištěnce. O poskytnutí informací je proveden auditní záznam. Pro realizaci registru IKP je předpokládána integrace s aplikacemi UIP, PNP.

Číselníky

Komponenta číselníky bude zprostředkovávat číselníky uložené a spravované modulem SEC, který je standardně využíván pro správu číselníku v rámci DIGI aplikací.

Audit operací

Vybrané operace nad kontem pojištěnce budou auditovány. V rámci integraci s AAA bude zajištěn audit uživatelských operací probíhající mezi klientskou aplikací a střední vrstvou. Audit operací mezi střední vrstvou APV IKP a databázovou vrstvou bude vytvořen nově. Veškeré operace (databázová volání) budou doplněna o jméno uživatele a jeho roli. Tyto údaje budou získány z komunikace mezi klientskou a střední vrstvou, která prochází skrz AAA portál.

Auditem sledované operace se týkají:

- prohlížení informací o konkrétním případu (včetně zahrnutí a rozlišení snahy

přístupu k informacím VIP osob).

- generování statistik

- generování a zapisování sestav případů pro zpracování do WORKu

- generování sestav případů pro automatizované sestavení IVK

- generování sestav případů pro hromadné odesílání připravených IVK

Pokud se bude jednat o technologickou komunikaci, např. různé dávkové úlohy, bude použit technologický uživatel specifický vždy pro danou operaci.

Pro záznam auditních informací bude použita komponenta log4net, která umožňuje ukládat logované informace buď na souborový systém nebo do vybrané databázové tabulky.

1.3.2.1.3 IKP - Konceptuální návrh db vrstvy

Konceptuální datový model je zachycen v samostatné kapitole. Pro datové zajištění přístupu k datům z okolních aplikací je dále navrženo řešení interních front, které společně s řešením dávkových přenosů na db vrstvě zajistí řízení zpracování

přicházejících podnětů z okolních systémů (zajištění perzistence, mechanismy opakování pokusu o zpracování/předání dat). V některých případech budou tyto prostředky využity také pro zajištění předání dat okolním aplikacím.

1.3.2.1.4 Návrh technologické architektury APV IKP

Architektura APV IKP je založena na základních principech SOA architektury, jakožto základním stavebním kamenu IIS ČSSZ.

Návrh třívrstvé architektury vychází mimo jiné i z Cílového konceptu. Na následujícím obrázku jsou vrstvy v pořadí shora dolů: klientská vrstva (IKP klient), aplikační vrstva (Web service, popř. Windows service) a databázová vrstva (Schéma IKP). Součástí aplikační vrstvy jsou poté i komponenty pro specifickou integraci s okolními systémy.

Klientská vrstva

SOAP/HTTP

IKP klient

Webové služby

Windows služby

Okolní aplikace

SOAP/HTTP

Aplikační vrstva

SQL .NET

Schéma IKP

Databázová vrstva

V klientské aplikaci budou použity technologie:

• Microsoft .NET 3.5,

• WinForms/WPF,

• Programovací jazyk C#, vývojové prostředí MS Visual Studio 2010. V rámci aplikační vrstvy budou použity technologie:

• Microsoft .NET 3.5,

• programovací jazyk C#, vývojové prostředí MS Visual Studio 2010,

• komponenta Log4net

V rámci databázové vrstvy:

• RDBMS Oracle 10g,

• programovací jazyk PLSQL.

Řešení registru IKP bude nasezeno v následucích prostředích ČSSZ:

- Produkční

- Integrační

- Školící/testovací

Navržené řešení bude splňovat technicko-provozní požadavky uvedené v zadávací dokuemntaci.

1.3.3 Popis principů a způsobu technického řešení Registru IKP

Individuální konto pojištěnce je v rozsahu informací o dobách a výdělcích tvořeno množinou evidovaných nárokových podkladů pojištěnce z databáze INP.

Pro evidenci kont pojištěnců bude vytvořen Registr IKP. Registr IKP obsahuje zejména metadata o zařazených dokladech a informace z dalších systémů, ze kterých lze jednoznačně odvodit zařazení konta v rámci sledovaných skupin.

Hlavní rozdělení kont je odvozeno podle výsledku klasifikace obsažených nárokových podkladů pojištěnce (použitím tzv. klasifikačního algoritmu). Klíčová metadata nárokových podkladů jsou dostupná i v registru IKP.

Pro úplné zařazení konta jsou dále zohledněny informace ze systémů KE, informace z DA, WORK, IVK. Sledované údaje z těchto systémů jsou vyhodnocovány a po identifikované změně dochází k promítnutí dopadů do Registru IKP.

Mechanizmus zajištění aktuálnosti registru IKP spočítá ve sledování a pravidelném vyhodnocování změn, které se odehrávají v integrovaných systémech (INP, KE, informace z DA, WORK). Sledovány jsou všechny změny, které ve svém důsledku působí na stav IKP a jeho datový obsah.

Při promítání zjištěných změn do registru IKP bude systém ukládat historii změn a při ukládání historického záznamu se budou v rámci konta dopočítávat hranice platnosti jednotlivých záznamů. Tím bude umožněno efektivní vytváření časových snímků konta k libovolnému okamžiku.

Systém je navržen tak, aby co nejvíce omezil dlouhé transakce nad provozními daty. Transakce nad ostatními daty budou navrženy tak, aby optimálně pokryly věcné požadavky a zároveň představovaly co nejmenší zátěž pro databázi.

1.3.3.1 Konsolidace kont pojištěnců

V rámci řešení Registru IKP navrhujeme navázat na předchozí projekty související s konsolidací kont pojištěnců, kdy byly prováděny výběry založené na klasifikaci nárokových podkladů a zakládání vzniklých požadavků na konsolidaci do systému WORK manuálním způsobem. Tímto způsobem docházelo k postupné konsolidaci kont pojištěnců.

Základním nedostatkem byla nutnost manuálního spuštění klasifikace nárokových podkladů k odvození informace o stavu kont. Z tohoto důvodu je vhodné uvažovat o zavedení automatického sledování změn v INP (a souvisejících systémech) a jejich okamžité klasifikace. Tímto způsobem lze zajistit dostupnost aktuálního stavu kont v uživatelsky akceptovatelné podobě.

Automatické sledování změn v evidenci nárokových podkladů, resp. DB_INP se bude týkat následujících operací:

• nově zapsaný doklad (ze všech podporovaných zdrojů)

• změna vybraného atributu dokladu (status, platnost, znak kvality, typ dokladu, zahrnutí do VDPE, skenovací větev, poznámka, existence JDV),

• změna obsahu JDV,

• změna přiřazení dokladu,

Sledování bude prováděno pouze pro aprobované změny dokladů (ne rozpracované).

Aktualizace v registru IKP budou prováděny automaticky interaktivně na základě výše uvedených podnětů.

Kromě změn v evidenci nárokových podkladů budou v registru IKP automaticky aktualizovány údaje z následujících souvisejících systémů:

• Kmenové evidence – změna RČ/EČP, úmrtí

• Informace z DA – přiznání a zánik důchodové dávky, přírůstky OLDP (SRD-A)

• DB_IVK – vytvoření a odeslání nového IVK nebo IOLDP

• DB_WORK – nové požadavky na zpracování, změny stavů zpracování požadavků

1.3.3.2 Technické řešení sledování změn v okolních systémech

Cílem sledování změn v okolních systémech je vyhodnocování identifikovaných změn pro následnou aktualizaci IKP a zajištění dalších akcí (např. požadavek na konsolidaci konta, sestavení IVK).

Jde o integraci registru IKP s několika okolními systémy, kdy je pro každou konkrétní integraci definován protokol předání a převzetí rozhodných informací. Konkrétní způsoby

zpracování přicházejících změn jsou pro jednotlivé systémy specifické, ale technické zajištění těchto integrací je jednotné.

Technické zajištění integrace se spolupracujícími systémy je navrženo s využitím řešení vstupních a výstupních front.

Obecné vlastnosti použitých front:

• Evidence požadavků pro asynchronní zpracování s podporou paralelního zpracování

• Požadavky se zpracovávají podle priority. Požadavky se stejnou prioritou se zpracovávají se zachováním pořadí, v jakém byly zaevidovány (FIFO)

• Schopnost evidovat řádově desetitisíce požadavků pro zpracování

• Stavy požadavků: Evidován, Ve frontě, Ve zpracování, Odložen, Zpracován

Využití tohoto přístupu přináší zejména jednoznačnost ve smyslu řízení průběhu zpracování vstupujících podnětů a požadavků na zajištění externích zpracování (vytvoření tisk IVK, zápis požadavku do WORK). Řešení vstupních a výstupních front také podporuje ad-hoc ověření stavu konkrétních požadavků v případě řešení nestandardních situací na úrovni integrace s okolními systémy (např. dohledání zda a případně jak byl určený požadavek přijat a odbaven).

Na následujícím schématu je znázorněn mechanismus zpracování požadavku ve frontě.

stm StateMachine

Zaev idov án

Vložení požadavku

[putQueue]

Ve frontě

lockQueueWait

Odložen

lockQueueWait

[queueWait] [getQueue]

[lockQueueWait]

Ve zpracov ání

QueueRequestProcessed

Zpracov án

Zpracování je

dokončeno

Řešení předpokládá, že fronty budou použity pro vstupní a výstupní komunikaci registru IKP se systémy pro sledování změn v jednotlivých zdrojových agendách.

Věcně jsou jednotlivé integrace popsány v kapitole 1.3.4.

1.3.3.3 Prvotní naplnění registru IKP

Zprovoznění registru IKP spočívá v zajištění potřebné infrastruktury a zejména v provedení prvotního naplnění registru IKP. Jde o jednorázové získání a vyhodnocení dat z okolních systémů.

Informace budou do registru promítnuty v souladu s principem ETL (Export, Transform, Load), neboli postupnými kroky sestavení dat ze zdrojových systémů, jejich transformace do patřičného významu a promítnutí do registru IKP.

Pro prvotní naplnění je klíčové provést toto zpracování pro systémy INP, IVK, Informace z DA a KE.

Pro provedení prvotního naplnění registru IKP bude v rámci etapy „Realizace“ připraven konkrétní plán provedení. Půjde o definování jednotlivých kroků, sestavení itineráře provedení těchto kroků včetně definice kontrolních bodů, kritérií a podmínek provedení.

O průběhu a výsledku provedení bude připravena Zpráva o provedení prvotního naplnění registru IKP.

1.3.4 Propojení Registru IKP s okolím

Integrace registru IKP na okolní systémy spočívá z významné části ve zpracování velkého množství podnětů z okolních systémů (dodávání informací majících vliv na obsah a stav IKP). Dalším prvkem integrace je naopak předávání podkladů pro hromadné zakládání požadavků pro opravná zpracování nárokových podkladů a vytváření a tisk IVK. Pro systémy INP, IVK, WORK je integrace technicky zajištěna pomocí řešení interních front a využití dávkových přenosů. Pro systémy KE a Informace z DA jde o převzetí a zpracování datových souborů s využitím řešení interních front pro další podporu zpracování v registru IKP. Se systémy KE, IVK, INP, WORK je také zajištěna integrace na příslušné webové služby pro zpřístupnění aktuálních informací pro potřeby zobrazení dat (zejména v uživatelské aplikaci IKP). Registr IKP naopak zpřístupní webové služby pro zpřístupnění dat IKP okolním aplikacím.

Použití řešení interních front pro zajištění technické podpory zpracování vstupujících dat z okolních systémů do značné míry sjednocuje postupy řízení a evidence zpracování a přináší také jednotné přístupy pro administraci a dohled provozu registru IKP.

1.3.4.1 Integrace na systém INP

Informace o nárokových podkladech představují klíčový zdroj dat z pohledu obsahu konta pojištěnce. Podstata integrace se systémem INP spočívá ve sledování změn prováděných v INP, průběžném vyhodnocování dopadů těchto změn a návazném provádění aktualizace informací v registru IKP.

Jedním z kroků zpracování změn INP v registru IKP je aktualizace celkového stavu konta pojištěnce, včetně vyhodnocení změny klasifikace celého konta. Výsledkem může být zajištění zpětné vazby do systémů INP a IVK. V případě INP jde o založení požadavku na konsolidaci nárokových podkladů pojištěnce. To se děje prostřednictvím systému WORK, který přijme požadavek na konsolidaci dokladů. Provedená konsolidace, resp. změna nárokového podkladu zajistí opět aktualizaci registru IKP prostřednictvím sledování a vyhodnocení příslušných změn.

V databázi INP jsou evidovány změny nárokových podkladů, tyto změny jsou vkládány do fronty, ze které jsou pravidelně (např. denně) hromadně předány příslušnému modulu IKP. Jde o použití řešení front popsané v kapitole 1.3.3.2. Pro přenos změn se předpokládá využití dávkového procesoru, popřípadě specializovaného modulu.

Stručný mechanismus integrace s INP:

1) Změna INP (např. zápis nového dokladu, doplnění nebo úprava JDV, aktualizace metadat, změna přiřazení)

2) Zaznamenání změny (funkcionalita INP – sledování změn)

3) Dodání informace na příslušné rozhraní registru IKP (hromadné dávkové přenosy)

4) Zpracování změn - vyhodnocení dopadu změny, aktualizace IKP, včetně možných navazujících akcí (např. vyžádání konsolidace dat, vytvoření IVK, konkrétní činnosti a chování je předmětem analytické fáze projektu)

Dalším typem integrace je napojení na služby poskytující aktuální data nárokových podkladů pro jednotlivé pojištěnce. Taková funkcionalita je využívána při zobrazení nárokových podkladů v uživatelské aplikaci IKP.

1.3.4.2 Integrace na systém IVK

Integraci s IVK lze rozdělit na zpracování změn na straně IVK a využití služeb IVK pro provádění hromadných akcí.

Z pohledu návaznosti na provedené změny je integrace s IVK je řešena obdobným způsobem jako u INP. Informace o změnách, tj. o každém nově založeném výpisu do IVK jsou ze strany IVK evidovány a pravidelně předávány na příslušné rozhraní registru IKP (pomocí hromadných dávkových přesunů). Na straně registru IKP jsou tyto informace průběžně zpracovávány. Výsledkem je doplnění sledovaných informací, případně ještě změna klasifikace konta pojištěnce.

V případě hromadných akcí, které vycházejí z požadavků uživatelů APV IKP jde o integraci se službami IVK za účelem vytvoření, nebo předání k tisku již vytvořených výpisů z konta pojištěnce. Ze strany IKP je prováděno řízení procesu hromadného vytváření výpisů, nebo jejich předání k tisku tzn. pro jednotlivé položky seznamu z hromadných akcí IVK jsou volány příslušné služby IVK, výsledek zpracování je v registru IKP uložen a je možné zobrazit výsledek zpracování jednotlivý součástí i celé dávky. Jednou z vlastností této integrace je zajištění perzistence zpracování na straně registru IKP, pomocí interních front je zajištěno opakované volání příslušných rozhraní a služeb v případě jejich dočasné nedostupnosti.

Dalším typem integrace je napojení na služby poskytující data IVK k jednotlivým pojištěncům. Jde o přehled evidovaných výpisů včetně metadat a poskytnutí dat konkrétních výpisů pro zobrazení v uživatelské aplikaci IKP.

1.3.4.3 Integrace s APV Work

Systém WORK poskytuje nástroje pro správu a řízení požadavků na zpracování v agendách správy nárokových podkladů a rozhodování o dávkách důchodového pojištění. Integrace se systémem WORK spočívá v doručení skupiny požadavků na konsolidaci nárokových podkladů pojištěnce na příslušné rozhraní. Tato integrace počítá s využitím řešení interních front, což mj. zajistí doručení požadavků i v případě nedostupnosti některých komponent (resp. po obnovení jejich dostupnosti). Ze strany registru IKP je dostupný

přehled dávek a jednotlivých požadavků, které byly do WORK směrovány (automatizovaně i na pokyn uživatele) včetně potvrzení předání požadavků.

Pro založení požadavku do WORKu je možné na základě určených pravidel definovat požadovaný typ zpracování (např. pro určité situace lze vyžádat konsolidaci částečnou a pro jiné konsolidaci úplnou, nebo zpracování v režimu OSVČ – konkrétní chování bude upřesněno v rámci analýzy).

Ze strany registru IKP je zajištěna také integrace na služby WORK, prostřednictvím kterých lze zjistit aktuální přehled a zobrazení požadavků evidovaných ve worku k jednotlivým pojištěncům.

1.3.4.4 Integrace se systémem KE

Integrace se systémem KE zpřístupňuje informace o pojištěncích (zejména identifikační údaje, vazbu klíčů OID-AID, informace o úmrtí etc.). Technicky je integrace realizována na úrovni:

a) Přebírání informací o úmrtí – napojení na souhlas vytvářený systémem KZR pro potřeby SQ serveru, ze kterého jsou zpracovávány informace o úmrtí

b) Přístup k rozhraním SI2 – poskytování aktuálních informací o pojištěncích

c) přístup k db rozhraní DRC_AKTUALNI – podpora hromadných operací, využití pro realizace výběrů se zahrnutím vazby na rodná čísla

Tyto způsoby integrace umožní fungování registru IKP podle očekávání (v souladu s Funkční a Technickou specifikací) s minimalizací dopadů na systémy KE a KZR.

1.3.4.5 Integrace na Informace z DA

Pro datové zajištění registru IKP a následné poskytování požadovaných funkcionalit je navržena integrace na zdroj vybraných informací z důchodových agend. Jde o vymezenou skupinu informací (např. poživatel důchodu, druh důchodu, přítomnost dob v SRD-A etc.). Předpokládáme dodávání informací prostřednictvím přenosového souboru, ve kterém budou aktualizace informací za určitou dobu. Jednotlivé soubory na sebe budou navazovat. Formát, přesný obsah a struktura dat bude upřesněna v průběhu analýzy řešení, včetně popisu způsobu předání souborů ze zdrojového systému. Obecně lze předpokládat uložení souboru na dohodnuté úložiště a jeho převzetí ze strany registru IKP.

1.3.4.6 ESB

Návrh technického řešení komunikace s navazujícími nebo zdrojovými systémy je řešen pomocí vlastních technologických komponent, které jsou využívány v rámci ATOS enterprise řešení pro zajištění integrace systémů. Tyto komponenty zaručují bezpečné doručení událostí a údajů včetně případného plánování spouštění jednotlivých akcí. Jedná se o klíčové funkcionality integrace registru IKP s okolními systémy. Integrační

komponenty registru IKP jsou navrženy plně v soulady s principy SOA, tento návrh nevylučuje budoucí využití standardních produktů ESB jako integračního prvku v rámci systémů pro zpracování nárokových podkladů.

1.3.5 Změny mimo rozsah nabízeného řešení

Součástí projektu na realizaci řešení registru IKP podle této nabídky nejsou následující součásti:

- Změny v procesu dosavadního zpracování nárokových podkladů na úrovni workflow.

- Automatizovaný zápis požadavků na opravu kont pojištěnců.

- Úprava stávajících APV (UIP, PNP, DB_WORK, DB_INP, DB_IVK, KE, progamů mainframe).

- Vytvoření systému pro sledování aktuálních údajů z důchodových agend.

1.3.6 Otevřenost řešení ke změnám

Navržené řešení plně respektuje pravidla definovaná pro IIS ČSSZ včetně obecných postupů pro návrh systémů založených na principech SOA.

Navržené systémy budou vytvořeny pomocí standardních produktů a nástrojů. Systémy budou vytvořeny na platformě MS .NET s využitím nástrojů MS Visual Studia a SVN pro správu zdrojových kódů.

Součástí navrhovaného hřešení je i dokumentace projektu. Z pohledu otevřenosti řešení k dalším změnám je především důležitá analytická, návrhová a programátorská dokumentace, která je standardní součástí dodávky.

Důsledným dodržováním principů SOA a třívrstvé architektury bude zaručena škálovatelnost systému.

Při návrhu a implementaci systému bude důsledně využíván rozpad funkčnosti na jednotlivé komponenty systému. Vztah mezi jednotlivými komponentami se bude řídit vhodnými návrhovými vzory. Tímto způsobem bude systém připraven pro potenciální rozvoj s minimálními dopady do již implementované funkcionality.

1.3.7 Identifikace klíčových dat

Označení	Význam
RC	RČ nebo EČP - významový identifikátor konta pojištěnce
JMENO	Jméno pojištěnce
PRIJMENI	Příjmení pojištěnce
RODNE_PRIJMENI	Xxxxx příjmení pojištěnce
DATUM_NAROZENI	Datum narození pojištěnce
DATUM_UMRTI	Datum úmrtí pojištěnce
XXXXXXX	Xxxxxxx pojištěnce
DRUHY_PILIR	Účast pojištěnce v II. Pilíři
IS_VIP	Konto VIP osoby
DATUM_ZMENY	Datum poslední aktualizace konta
OCISTENE	Informace, zda se jedná o konto osoby zemřelé nebo konto osoby pobírající přímý důchod
POCET_SK1	Počet dokladů konta zařazených do klasifikační skupiny 1
POCET_SK2	Počet dokladů konta zařazených do klasifikační skupiny 2
POCET_SK3	Počet dokladů konta zařazených do klasifikační skupiny 3
POCET_SK4	Počet dokladů konta zařazených do klasifikační skupiny 4
POCET_SK5	Počet dokladů konta zařazených do klasifikační skupiny 5
IOLDP_VYTVORENO	Datum posledního vytvoření OLDP
IOLDP_ODESLANO	Datum posledního odeslání IOLDP
AUT_IVK_VYTVORENO	Datum posledního vytvoření automatického IVK
REF_IVK_VYTVORENO	Datum posledního vytvoření referentského IVK

Označení	Význam
AUT_IVK_ODESLANO	Datum posledního odeslání automatického IVK
REF_IVK_ODESLANO	Datum posledního odeslání referentského IVK
PRIMY_DUCHOD	Pojištěnec pobírá přímý důchod
SRD_A	Pojištěnec má v SRD-A uloženo OLDP
PA	Informace, je-li konto určeno pro zpracování v rámci povyměřovací agendy
IDENTIFIKACE_UZIVATELE	Identifikace uživatele – technické označení uživatele
TYP_OPERACE	Typ prováděné operace v registru IKP - např. prohlížení případu, generování statistiky atd. - včetně metadat k rekonstrukci dotčených kont
CASOVE_RAZITKO	Datum a čas prováděné operace
Historické údaje	Množiny záznamů tvořících historii

1.3.8 Požadavky na HW vybavení k zajištění rutinního provozu pro

předpokládaný počet uživatelů

Na obrázku je schematické znázornění HW architektury, na které bude provozováno řešení APV IKP. Řešení odpovídá třívrstvé architektuře v podmínkách ČSSZ, vrstvy jsou v pořadí shora dolů: klientská (IKP Klient), aplikační (virtualizované aplikační servery) – IKP aplikační vrstva, vrstva podpory integrace na okolní systémy, databázová vrstva IKP (Oracle RAC). Mezi klientskou a aplikační vrstvou jsou vřazené technologické prvky: AAA portál zabezpečující přístup z klientské vrstvy (autentizaci a autorizaci uživatelů podle nastavení přístupových rolí) a Content switch zajišfující rozkládání zátěže klientů mezi jednotlivé aplikační servery (Loadbalancing).

Content switch

Lokalita 1

IKP databázová vrsva

ORA10g

Node1

ORA10g

Node2

Oracle RAC

VMWARE

server Lokalita 2

IKP aplikační vrstva

VMWARE

server

Lokalita 1

VMWARE

AAA

AAA Portál

Diskové pole

Load balancing

HTTP

Aplikační servery

Pro zahájení pilotního provozu APV IKP je potřeba zajistit 2x Virtuální server (každý v jedné lokalitě) s následujícími vlastnostmi:

- 2 jádra

- 4GB RAM

- 100 GB HDD

o Operační systém: Widows2008R2 64 bit

Databázové servery

Standard ČSSZ definuje minimální parametry hardware a určuje systémový software dle druhů užití jednotlivých serverů.

Klientské stanice

Standard ČSSZ definuje minimální parametry hardware a určuje systémový software dle druhů užití jednotlivých klientských stanic.

1.4 Způsob testování a zajištění kvality

1.4.1 Popis způsobu a metodiky testování

Tato kapitola obsahuje podrobný popis přístupu k provádění ověřování shody, akceptačních testů, kdy Dodavatel uvede zejména metodiku testování, plánovaný rozsah testů, způsob zajištění dohledu nad prováděním testů, strukturu výstupů z testování.

Cílem testování je ověření a validace požadovaných vlastností předávaného díla, kdy v případě nalezení chyby je potřeba co nejdříve zajistit její nápravu. V průběhu projektu plánuje Atos IT Solution and Services nasazení testování jako jednoho z nástrojů pro zajištění kvality dodávaného díla a ověření jeho parametrů.

V průběhu realizace projektu budou realizovány zejména:

• Testy funkcionality (funkční testy)

• Integrační testy

Příprava, realizace a zaznamenání prováděných testů bude obsahem Testovací dokumentace. Hlavními součástmi jsou:

• Plán testování

• Testovací scénáře

• Testovací dokumentace

1.4.1.1 Funkční testy

Funkční testování slouží k ověření funkčnosti dodávané aplikace. Uchazeč je schopen zajistit kompletní provedení níže uvedeného funkčního testování, pro něž 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í.

Plánování testů

Tato fáze zahrnuje tvorbu plánu testů, podle kterého bude prováděno funkční testování realizovaného APV. Dokument obvykle zejména:

• návrh struktury a rozsahu testů, včetně způsobu provedení (manuální, automatizované),

• definice metodických postupů pro jednotlivé kroky testování,

• akceptační kritéria pro funkční testování konkrétní aplikace,

• organizační struktura testovacího týmu,

• definice odpovědností a pravomocí účastníků testování,

• způsob evidence neshod/chyb, sledování řešení chyb, způsob vyhodnocení testů,

• definice zdrojů (testovací tým, popis testovacích prostředí),

• návrh formulářů používaných v průběhu testů. Návrh a příprava testů

Příprava je stěžejní částí celého funkčního testování, protože v závislosti na kvalitě přípravy lze pak sledovat kvalitu celým procesem testování, případně chybovost. Příprava testů se skládá zejména z přípravy testovacích případů a scénářů, testovacího prostředí, testovací dokumentace a testovacích dat.

V této fázi je nejprve vytvořena strategie testování na základě rozboru analytických podkladů, jsou hledána vhodná místa pro testování a plánovány postupy efektivního otestování realizovaného APV.

Na základě strategie provede analytik testování návrh testů, rozdělení testů do skupin a pro příslušné skupiny zpracuje testovací scénáře. Pro každý scénář je stanoven postup přípravy testovacích dat (testovací situace), které budou naplňovat zadání testovacího scénáře.

Příprava testovacích scénářů

Jednotlivé testovací scénáře budou vznikat pro jednotlivé vyvíjené funkčnosti souběžně s tvorbou zadání pro programování.

Součástí testovacích scénářů bude také návrh testovacích dat pro prokázání potřebné funkčnosti. Vytvořené testovací scénáře bude potom možné opakovaně používat při následném regresním testování v pozdějších fázích vývoje systému.

Příprava testovacího prostředí

V prostředí ČSSZ bude testování prováděno v Integračním prostředí (IP ČSSZ) a ve Školícím a testovacím prostředí (TP ČSSZ). Testovací prostředí bude zajištěno také na straně uchazeče.

Příprava testovacích dat

Testování v jednotlivých prostředích bude vycházet z dat dostupných ve spolupracujících systémech. Jde zejména o IP ČSSZ a TP ČSSZ, v těchto prostředích budou používány prostředky spolupracujících systémů (rozhraní, data). V prostředí uchazeče budou používány simulace okolních rozhraní a vytváření specifických sad testovacích dat.

Před zahájením testovacího provozu bude provedeno naplnění systému počátečními daty.

Vstupními informačními zdroji pro vyhledání vhodných testovacích dat jsou testovací scénáře a projektová dokumentace testovaného APV. Testovací data musí být dostupné v dostatečném množství a struktuře, která vychází z koncepce testovacích scénářů. Důležitým faktorem je ověření správnosti a konzistence testovacích dat před jejich použitím a zajištění opakovatelnosti jejich vytvoření v definované podobě.

Provedení testů

Samotná fáze testování je prováděna testerem, který provádí předpřipravené testovací scénáře a testovací skripty a zaznamenává jejich výsledky. V případě nálezu chyby nebo nestandardního chování toto pak hlásí vedoucímu testování nebo do příslušného evidenčního nástroje, který zajistí klasifikaci chyby a určení postupu k vyřešení.

Vyhodnocení testů

Po dokončení funkčních testů je prováděno vyhodnocení dosažených výsledků a posouzeno, zda testovaná aplikace vyhovuje stanoveným kritériím pro funkční testování.

Ve fázi akceptačních testů pak na základě tohoto posouzení rozhodne zodpovědná osoba zadavatele o tom, zda bude testovaná aplikace nasazena do provozu nebo zda se budou testy opakovat po odstranění nalezených chyb.

1.4.1.2 Integrační testy

Provádí se obdobně jako funkční testování, testy však probíhají na testovacím prostředí zákazníka, kde jsou připravena rozhraní na prostředí okolních spolupracujících systémů. Testy jsou zaměřeny na operace, které jsou považovány za hlavní body funkčnosti při integraci dílčích komponent celého systému včetně všech rozhraní spolupracujících systémů.

Testy integrace s jednotlivými systémy bude probíhat postupně, testování bude vždy zaměřeno na definovanou skupinu rozhraní a využívaných metod.

Při provádění integračních testů je potřebná součinnost zadavatele zejména v oblastech:

• Přípravy testovacího prostředí

• Zajištění součinnosti třetích stran

• Přípravy dat v externích systémech nebo emulace jejich rozhraní

1.4.2 Předávaná dokumentace

Celková dokumentace k dodávanému produktu se bude skládat z více různých typů dokumentů s rozdílnými cílovými okruhy uživatelů těchto. Typově se jedná zejména o:

• Dokumenty související s realizací projektu a jeho správou – projektové dokumenty, zápisy jednání, harmonogramy, rozhodnutí projektového týmu, prováděcí dokumenty, předávací a akceptační protokoly, dokumentace provedených testů, řízení neshod a jejich odstraňování atp.

• Dokumentace řešení z hlediska požadavků, návrhu a způsobu realizace – dokumentace díla (podrobněji popsaná v textu dále).

• Standardy a referenční modely použité pro tvorbu systému.

• Uživatelská dokumentace – uživatelské příručky, nápovědy, školící a tréninková dokumentace.

• Technická dokumentace – na úrovni standardních technologií, provedených zákaznických úprav, zakázkově vytvořených modulů, dokumentace programových rozhraní, vývojářská dokumentace komponent a objektových modelů.

• Provozní dokumentace – instalační příručky, popisy konfigurací a nastavení, instrukce provozního dohledu a údržby.

• Zdrojové kódy – informace na úrovni zdrojového kódu, jako jsou dokumentační komentáře, lze také považovat za specifickou formu dokumentace, která bude k dispozici.

Atos IT Solutions and Services používá pro tvorbu poskytovaného díla vlastní jím celosvětově používanou metodiku Global Delivery Process, jejíž součástí je mj. také sada standardně dodávané dokumentace vytvářeného produktu, respektive služby. Jejími klíčovými součástmi jsou:

• Architektura na úrovni obchodních služeb a procesů

• Katalog požadavků a popis jejich pokrytí dodávaným řešením

• Detailní funkční návrh

• Návrh systémové architektury

• Detailní technický návrh

• Plán systémové integrace

• Kritéria a plán uživatelských a systémových akceptační testů

• Uživatelská příručka

• Školící materiály

• Plán nasazení systému

• Instalační postupy

• Plán přechodu do produkčního prostředí

• Příručka provozní správy včetně definice provozních hlášení

Dokumentace obsahuje strukturovaný popis dodávaného řešení včetně klíčových diagramů s vizualizací dílčích modelů systému podle různých aspektů. Mezi nejdůležitější modely, zahrnuté v dokumentaci, patří zejména následující:

• Procesní model

• Informační model

• Model datových entit (konceptuální datový úroveň, logický datový model)

• Model uživatelského rozhraní

• Komponentový model.

• Model integračních vazeb.

1.5 Projektové řízení, organizace a harmonogram projektu

1.5.1 Popis způsobu a metodiky projektového řízení

1.5.1.1 Metodika projektového řízení

Při realizaci projektů vychází Atos IT Solutions and Services, s.r.o. z interní metodiky Global Delivery Platform (GDP), která je kompatibilní s ostatními uznávanými metodikami pro podporu projektového řízení (například PRINCE2, PMI) a standardy (např. CMMI).

Naši projektoví manažeři jsou certifikováni nejméně podle jedné obecně uznávané metodiky.

GDP obsahuje postupy a nástroje pro řízení všech fází realizace projektu od plánování a návrhu až po implementaci a odbornou podporu provozu systému.

Část metodiky GDP nazvaná „Atos Integrated Development Process“ člení životní cyklus projektu do jednotlivých fází, každá fáze je ukončena milníkem.

Fáze životního cyklu projektu dle Atos Integrated Development Process:

ID fáze	Název fáze	Další procesy GDP (řídící a inženýrské)	Vazba na hlavní fáze projektu.
L1	Business architektura	M1 – Zahájení projektu E1 – Řízení požadavků	Fáze 1
L2	Analýza požadavků	M2 – Řízení projektu E1 – Řízení požadavků	Fáze 1
L3	Softwarová architektura	M2 – Řízení projektu E1 – Řízení požadavků E3 – Testování	Fáze 1
L4	Detailní návrh	M2 – Řízení projektu E2 – Softwarové inženýrství	Fáze 1

ID fáze	Název fáze	Další procesy GDP (řídící a inženýrské)	Vazba na hlavní fáze projektu.
		E3 - Testování
L5	Vývoj a unit testy	M2 – Řízení projektu E2 – Softwarové inženýrství	Fáze 2
L6	Integrace	M2 – Řízení projektu E2 – Softwarové inženýrství E3 – Testování	Fáze 2
L7	Systémové testování	M2 – Řízení projektu E2 – Softwarové inženýrství E3 – Testování	Fáze 2
L8	Příprava dokumentace	M2 – Řízení projektu E4 – Instalace	Fáze 2
L9	Akceptační testování	M2 – Řízení projektu E3 – Testování E4 – Instalace	Fáze 3
L10	Příprava provozu	M5 – Ukončení projektu E3 – Testování E4 – Instalace	Fáze 3
L11	Podpora provozu	M5 – Ukončení projektu E4 – Instalace	Fáze 3

Podpůrné procesy probíhají skrz celý životní cyklus projektu: S1 – Konfigurační management

S2 – Řízení jakosti

S3 – Řízení projektových metrik (ve smyslu sledování definovaných KPI/SLA) S4 – Řízení rizik

S5 – Řízení odhadů rozsahu projektu

Přehled fází životního cyklu projektu a jejich milníků:

Metodika GDP počítá se svým přizpůsobením názvosloví a zvyklostem zákazníka, proto již zde používáme pojmy obvyklé v českém prostředí.

Na začátku je v souladu s GDP (proces M2) zpracován a Řídícím výborem schválen základní řídící dokument projektu, definující řídící a podpůrné procesy v projektu. Jedná se o dokument s názvem „Operational Delivery Plan“, který obsahuje následující informace:

• Plán řízení projektu

o Definici cíle, rozsahu a výstupů projektu

o Organizační strukturu projektu

o Projektové postupy (řízení požadavků, změn, reporting, pravidla komunikace, eskalační procedury)

o Harmonogram projektu

o Plán školení

o Použité metody, techniky a nástroje

o Součinnost zákazníka

o Omezující podmínky a předpoklady realizace projektu

• Plán řízení rizik

• Plán kvality

• Plán testování

• Plán akceptací

• Plán pilotního provozu

1.5.1.2 Metodika vývoje aplikačního programového vybavení

Vývoj (konstrukce) programového vybavení bude probíhat s využitím postupů uchazeče ověřených na mnoha projektech obdobného charakteru. Společnost ATOS má implementovány celosvětově ověřené postupy vývoje označené jako GDP (Global Delivery Platform). Základem těchto postupů je jednotné řízení všech vývojových procesů. Soubor těchto procesů zobrazuje schéma GDP:

Všechny tyto procesy jsou plně integrovány a všichni pracovníci společnosti absolvují školení na jejich plné zvládnutí. To umožňuje řídit kvalitu vývoje a tedy dodávek jednotným způsobem a zákazníkovi to přináší jistotu, že dostane to co požadoval.

Základními pilíři vývoje, které napomáhají dosahovat kvalitních výstupů a omezovat projektová rizika, jsou:

• Iterační vývoj

• Řízený životní cyklus realizace požadavků

• Průběžné ověřování vyvíjeného systému

• Definovaná pravidla tvorby programového kódu

• Správa programového kódu a jeho verzí

• Automatická kontinuální integrace

Interní iterační vývoj a životní cyklus realizace požadavků

Interní iterační vývoj na projektu tohoto typu je nástroj k zajištění průběžné kontroly nad stavem vývojových prací. Celé období vývoje je rozděleno do krátkých časových intervalů s konstantní délkou (iterací), které trvají typicky 1 či 2 týdny. Na začátku každé iterace probíhá plánování a výběr požadavků, které budou v dané iteraci naprogramovány. Pokud je potřeba, je před vlastním programování připraven detailní programátorský návrh, jak daný požadavek začlenit do stávajícího kódu. Rovněž probíhá příprava testovacích scénářů, které mohou být také užitečným podkladem pro programátory. Následně proběhne vlastní konstrukce požadavků vybraných do dané iterace. Po skončení iterace se uvolní nová verze, která je předána do interního testování. Zjištěné chyby se evidují a průběžně (současně s realizací nových požadavků) probíhá jejich oprava.

Hlavní výhody uvedeného přístupu jsou:

• průběžná kontrola skutečného postupu prací na projektu,

• minimalizace množství neotestovaného (a tudíž potenciálně chybného softwaru),

• možnost uvolnit průběžné verze do dílčích integračních testů, popř. zákaznických funkčních testů,

• možnost prezentovat průběžný stav vývoje zákazníkovi a získat uživatelskou zpětnou vazbu k již vytvořeným částem řešení.

Pro podporu uvedeného operativního řízení se používá nástroj, ve kterém jsou evidovány jak požadavky k realizaci, tak dílčí úkoly pro členy týmu a rovněž zjištěné chyby.

Po skončení každé iterace probíhá krátká interní (v rámci realizačního týmu) prezentace nově vytvořených funkcí, což napomáhá k šíření všeobecného povědomí o vytvářeném systému.

Průběžné ověřování vyvíjeného systému

V předchozím textu již byly zmíněny důležité formy průběžného ověřování správnosti dosud vytvořeného programového vybavení:

• kontinuální integrace – průběžná kontrola kvality zdrojových kódů. Atos má nastaveny tyto druhy kontinuální integrace

o hodinový build – kontroluje zda je ze zdrojových kódů apliakce sestavitená

o noční build

▪ spouští statickou analýzu kódu, která zajišfuje shodu zdrojových kódů s definovanými konvencemi a tím zajišfuje kvalitu vytvářených kódů

▪ spouští unit testy, které kontrolují funkčnost vyvinutých fragmentů systému

▪ vytváří verzi systému

▪ tuto vytvořenou verzi nasazuje na aplikační servery pro další testování a ověřování

o vytvoření instalace – ručně spouštěné vytvoření instalace, zajišfuje opakovatelné vytvoření instalační sady vždy dle naprosti identických postupů a za stejných podmínek

o vytvoření programátorské dokumentace – automatické vytvoření tzv. JavaDoc

• průběžné integrační testy, jejichž hlavním cílem je ověřit shodu v pochopení návrhu a správnost implementace datových rozhraní různými dodavateli, z nichž každý realizuje některý z komunikujících systémů,

• průběžné funkční testy realizované zástupci zadavatel (pokud bude tato forma ověřování dohodnuta) 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 zadavatele a koncových uživatelů, což je pro zadavatele časově méně náročnou, ale z pohledu realizace projektu také méně přínosnou alternativou k zákaznickým funkčním testům; samozřejmě je možné kombinovat zákaznické testy, které provádí úzká skupina zástupců zadavatele, 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áklady je třeba vynaložit na její odstranění.

Při plánování projektu jsou navrženy termíny dílčích integračních, popř. zákaznických testů a prezentací a je rámcově určeno, jaká část řešení bude k daným termínům implementována. Toto rozhodnutí je třeba zohlednit rovněž na straně externích systémů, které se mají zúčastnit daných integračních testů.

Na základě zkušeností uchazeče je vhodné plánovat tyto dílčí testy a prezentace v časovém odstupu cca 6 týdnů, což je doba, za kterou dojde k významnému pokroku v množství implementovaných funkcí. Doba trvání testů je pak vždy cca 2 týdny.

Definovaná pravidla tvorby 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).

Základem pro tvorbu kvalitního programového kódu jsou jednotné programátorské konvence, které definují množinu pravidel, která musí každý programátor dodržovat. Společnost ATOS má zavedeno množství kontrolních mechanismů, které dodržování pravidel ověřují. Jedná se zejména o:

• statickou analýzu kódu, její pravidelné spouštění a vyhodnocení je zajištěno automatickou kontinuální integrací. Pro statickou analýzu zdrojových kódů využíváme nástroj PMD.

code review – křížová kontrola kvality zdrojových kódů mezi vývojářiMezi techniky, které jsou definovány programátorským konvencem a které vedou k zajištění těchto vlastností, patří vhodné 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.

Správa programového kódu

Programový kód je udržován centrálně v systé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.

Systém pro správu a verzování zdrojových kódů je důležitou součástí efektivního řízení verzí.

Implementace vytvořeného a interně otestovaného programové vybavení do cílového prostředí (testovacího či provozního) spočívá v následujících krocích:

• vytvoření, popř. aktualizace databázového schématu,

• nahrání či zadání potřebných iniciálních dat do tabulek databáze,

• instalace programového vybavení do běhového prostředí (aplikační server),

• nastavení konfiguračních parametrů specifických pro dané prostředí,

• ověření správnosti implementace (např. provedením vybraných funkčních testů).

Pro analýzu, návrh a vývoj APV Registru IKP bude použit standardní SASE nástroj EnterpriseArchitect.

1.5.1.3 Organizační struktura projektu

Pro řízení projektu Atos IT Solutions and Services, s.r.o. navrhuje následující organizační strukturu:

Řídící výbor:

• Rozhoduje o koncepčních věcech projektu, stanovuje jeho rozsah a priority.

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

• Rozhoduje o změnách projektu (rozsah plnění, harmonogram, cena), jsou-li v daném

případě přípustné.

• Řeší krizové situace projektu a rozhoduje o mimořádných opatřeních k jejich odstranění.

• Podporuje vedení projektu.

• Je eskalační úrovní pro vedení projektu.

• Je složen ze zástupců managementu zákazníka a dodavatele s potřebnými pravomocemi.

Jednání řídícího výboru projektu:

• Jednání řídícího výboru bude směřováno k akceptačním milníkům projektu.

• Další mimořádné termíny jednání řídícího výboru k řešení závažných nebo eskalovaných situací.

Garanti projektu:

• Zajišfují součinnost zákazníka.

• Řídí zdroje dedikované zákazníkem, k čemuž mají delegovánu odpovídající pravomoc.

• Xxx přidělené zdroje se účastní aktivit jednotlivých projektových týmů, např.:

- Metodici jsou součástí analytického týmu

- ICT pracovníci jsou součástí technického týmu

- Klíčoví uživatelé jsou součástí týmu kvality

• Přenášejí do řešitelských týmů know – how v konkrétní řešené oblasti zákazníka.

• Posuzují shodu navrženého řešení s požadavky a potřebami zákazníka, definovanými ve smlouvě.

• Účastní se testování výstupů etap projektu.

• Účastní se akceptačního řízení k výstupům etap projektu.

• Eskalují k řešení problémy, jejichž řešení je mimo jejich rozhodovací pravomoci.

• Jsou součástí vedení projektu

Vedoucí projektu Atos:

• Provádí operativní řízení projektu a odpovídá za dosažení cílů projektu (realizaci

předmětu smlouvy).

• Řídí zdroje přidělené na projekt.

• Řídí a koordinuje projektové týmy.

• Sestavuje a průběžně aktualizuje harmonogram projektu.

• Sleduje postup prací na projektu, kontroluje dosažené výsledky.

• Řídí rizika projektu.

• Zabezpečuje řízení požadavků a změn v projektu.

• Plánuje a zajišfuje školení uživatelů systému.

• Vede projektové výkaznictví.

• Připravuje podklady pro jednání řídícího výboru.

• Eskaluje k řešení problémy, jejichž řešení je mimo jeho rozhodovací pravomoci. Jednání vedení projektu:

• Je organizováno vedoucím projektu

• Uskutečňuje se pravidelně podle pravidel uvedených v Plánu řízení projektu.

• Termíny jednání vedení projektu lze upřesňovat s obsahem prací.

Architekt projektu:

• Řídí zpracování návrhu architektury projektu.

• Posuzuje dopad požadavků a změn na navrženou architekturu projektu.

• Koordinuje činnost projektových týmů po technické stránce tak, aby jejich výstupy byly v souladu s navrženou architekturou projektu.

• Eskaluje k řešení problémy, jejichž řešení je mimo jeho rozhodovací pravomoci.

Projektové týmy:

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

• Eskalují k řešení problémy, jejichž řešení je mimo jejich rozhodovací pravomoci. Jednání projektového týmu:

• Jednání projektového týmu probíhá operativně podle potřeb řešení úkolů podle harmonogramu projektu.

Analytický tým

• Vypracovává analýzu a návrh řešení pod vedením Hlavního architekta

• Podporuje vývojový tým formou konzultací a dodatečných detailních specifikací

• Vypracovává uživatelskou a školící dokumentaci

• Školí klíčové uživatele a podporuje je při školení koncových uživatelů

• Zodpovídá za konfigurační management produktové dokumentace

Technický tým

• Zodpovídá za vytvoření odpovídajících provozních prostředí aplikace

• Podporuje vývojový tým při nastavování vývojového prostředí

• Podporuje pracovníky provozu zákazníka při nasazování SW a předává jim know-how

• Vypracovává administrátorskou dokumentaci

• Zodpovídá za konfigurační management infrastruktury

Vývojový tým

• Programuje zákaznické komponenty aplikace

• Zodpovídá za tzv. Unit testy

• Zahrnuje vývojáře a DB specialisty

• Zodpovídá za vývojovou dokumentaci v souladu s metodikou dodavatele

• Zodpovídá za konfigurační management zdrojových kódů

Tým kvality

• Připravuje testovací dokumentaci

• Řídí a provádí testování aplikace v souladu s metodikou dodavatele

• Zakládá a udržuje tzv. tickety v systému pro sledování chyb

Řešení projektu budou za Atos IT Solutions and Services zabezpečovat následující klíčoví specialisté:

Titul, jméno a příjmení	Role v projektu
Xxx. Xxxxx Xxxxx	Projektový manažer
Xxx. Xxxxxx Xxxxxxx	Architekt informačního systému
Xxx. Xxxxx Xxxxxxx	Procesní analytik
Xxxxx Xxxxxxxxx	Systémový specialista

1.5.1.4 Eskalační procedura

V rámci řešení úkolů jednotlivé prvky organizační struktury řeší úkoly, které spadají do jejich pravomoci.

Jednotlivé prvky organizační struktury nejsou oprávněny na své úrovni činit rozhodnutí, která mění rozsah plnění, konečné termíny a milníky podle harmonogramu projektu a cenu za dodávku. Tato pravomoc přísluší pouze Řídícímu výboru projektu.

Jednotlivé prvky organizační struktury eskalují řešení problémů mimo jejich kompetenci podle hierarchie řízení projektu:

- Projektový tým -> vedení projektu

- Architekt projektu -> vedení projektu

- Vedení projektu -> řídící výbor

1.5.1.5 Řízení kvality

Řízení kvality při řízení projektu je nedílnou součástí řízení projektů v rámci jeho celého životního cyklu.

K zajištění řízení kvality bude zpracován Plán kvality jako jeden ze základních řídících dokumentů.

Koncepce řízení kvality bude založena na následujících principech:

• Závaznost definovaných principů řízení kvality pro celý životní cyklus projektu

• Definování cílů jakosti

• Dodržování stanovených projektových postupů a standardů

• Testování funkcionality řešení na základě definovaných testovacích scénářů (Plán testů):

o testy funkcionality

o integrační testy

• Definování kontrolních bodů v rámci projektu, ve kterých bude provedena kontrola dodržování výše uvedených principů

Popis role vedoucího týmu kvality:

- Je dedikován k zajištění řízení kvality v projektu

- Odpovídá za stanovení cílů kvality, návrh a implementaci systému řízení kvality v projektu

- Řídí kontrolu dodržování stanovených pravidel pro řízení kvality

- Navrhuje opatření k odstranění zjištěných nedostatků

- Eskaluje nevyřešené neshody na vedení projektu

1.5.1.6 Řízení rizik

Riziko je potenciální událost, která pokud nastane, ovlivní nepříznivě projekt z pohledu naplnění jeho cílů.

Řízení rizik je soubor postupů a nástrojů sloužících k identifikaci rizik, jejich vyhodnocení a přijetí opatření k jejich omezení z pohledu vyhodnocení událostí, které mohou mít nepříznivý vliv na jakékoli události, které jsou předmětem řízení projektu.

Koncepce řízení rizik

Postupy řízení rizik projektu zahrnují aktivity spojené s identifikací, vyhodnocením a zvládnutím rizik ohrožujících projekt:

1. Výchozí identifikace rizik projektu se provádí v období přípravy projektu. Výsledky této identifikace, včetně návrhu opatření k omezení rizik existujících již v okamžiku zahájení projektu, jsou součástí dokumentu Plán řízení projektu.

2. Vytvoření procesů sloužících k identifikaci a řízení rizik po celou dobu trvání projektu. Jejich popis včetně plánu řízení rizik projektu je obsahem dokumentu Plán řízení projektu, zpracovaného v období přípravy projektu.

3. Identifikace rizik v průběhu projektu probíhá za pomoci k tomu určeného nástroje v termínech stanovených v Plánu řízení projektu. Východiskem je metodikou GDP

stanovený seznam možných rizik pro dílčí oblasti projektu. Možná rizika v každé oblasti jsou vyhodnocena podle míry, kterou ohrožují projekt a váženým průměrem je zjištěna míra rizika pro každou oblast. Současně je analogickým způsobem vyhodnoceno, do jaké míry působí prostředí v jednotlivých oblastech proti možným projevům identifikovaných rizik nebo jak jsou efektivní dříve přijatá opatření k jejich omezení.

4. Všechna identifikovaná rizika jsou evidována a jejich řízení je evidováno v Registru rizik.

5. Vedení projektu odpovídá za průběžné sledování rizik projektu, za přijímání opatření k jejich omezení, která jsou v jeho kompetenci

6. Rizika, k jejichž omezení jsou zapotřebí opatření nad rámec kompetencí vedení projektu, jsou eskalována na řídící výbor projektu.

7. Zpráva o aktuálním stavu rizik je součástí zprávy o stavu projektu, předkládané vedením projektu v termínech stanovených v Plánu řízení projektu. Vedení projektu navrhuje v tomto dokumentu opatření k jejich vyloučení nebo omezení podle oblastí v nichž jsou rizika sledována.

8. Pokud se projeví nečekané riziko, reaguje vedení projektu okamžitě.

Seznam možných oblastí rizika:

1 Zákazník

1.1 Zákazník má malé technické znalosti v oboru

1.2 Požadováno další vzdělávání/školení

1.3 Nedosažitelnost klíčových uživatelů

1.4 Instalace systému ve více geograf. oblastech

1.5 Je třeba postihnout vysoký počet funkčních oblastí

1.6 Požadovány organizační změny

1.7 Nízká spoluúčast uživatele při implementaci

1.8 Nedostatečná součinnost zákazníka

1.9 Nedostatečná komunikace mezi zákazníkem a dodavatelem/subdodavatelem

1.10 Další nestandardní chování zákazníka

2 Dodavatelé / Subdodavatelé / Partneři

2.1 Kritická závislost na dodavatelích/partnerech

2.2 Technické nedostatky partnerů/dodavatelů/subdodavatelů

2.3 Datum dodání není v termínu

2.4 Mnoho dodavatelů

2.5 Nedostatečná součinnost partnerů/subdodavatelů

3 Legislativa, podmínky

3.1 Nutnost ochrany dat

3.2 Existence důvěrných dat

3.3 Legislativní změny

3.4 Patenty

3.5 Ostatní zákonné podmínky

4 Kontrakt

4.1 Neexistence back-to-back smluv

4.2 Nedostatečně specifikované požadavky

4.3 Změna smluvních podmínek

4.4 Licence

4.5 Nedodržení termínů

4.6 Technické problémy přesahující rámec smlouvy

4.7 Akceptace neuskutečněna

4.8 Reengineering v neadekvátní výši

4.9 Záruky/plnění

5 Technologie

5.1 Použití nové technologie/řešení

5.2 Nestandardní architektura

5.3 Technologie a postupy nejsou v souladu s metodikou SIS

5.4 Použití technologie/produktů neověřených SIS

5.5 Velký počet implementovaných produktů/komponent/prostředí

5.6 Velmi složité funkce

5.7 Velmi rozsáhlé databáze

5.8 Nevhodný vývojový/implementační nástroj

5.9 Malá zkušenost pracovního týmu

5.10 Nekompatibilita hardwaru a dalších technologií

5.11 Neexistence dohody se zákazníkem na kriteriích akceptačního testu

5.12 Xxxxxxx s normami a standardy

6 Procesy v projektu/ Organizace projektu/ Obsazení a role v projektu

6.1 Není využívána standardní metodika řízení projektů

6.2 Nestabilita vývojového/implementačního týmu

6.3 Nízká kvalita dodávky

6.4 Meziprojektové závislosti

6.5 Změny uživatelských požadavků

6.6 Nedostatek zdrojů nebo jejich nízká kvalifikace

6.7 Závislost na externích klíčových osobách

6.8 Nestabilita v projektové organizaci

7 Infrastruktura/logistika

7.1 Cestovní/dopravní podmínky

7.2 Komunikační podmínky/bariéry

7.3 Škody při přepravě

7.4 Krádež/odcizení majetku

8 Rizika plánování

8.1 Malá věrohodnost projektových podkladů

8.2 Velký vliv neformálních řídících struktur

8.3 Malé zkušenosti vedoucího projektu

8.4 Nejsou stanoveny klíčové termíny

8.5 Špatná dostupnost plánovaných zdrojů

8.6 Příliš dlouhý/krátký termín na dokončení projektu

8.7 Složité závislosti mezi úkoly

8.8 Špatný odhad rozpočtu/náklady na projekt stanoveny chybně

1.5.1.7 Změnové řízení

Změnové řízení je proces, který je zahájen v případě vzniku požadavku na změnu v projektu v rozsahu, který může potenciálně vyžadovat změnu smluvních podmínek, na základě kterých je projekt realizován. Jedná se zpravidla o změnu rozsahu projektu vyžadující závažnější změny funkcionality, vedoucí ke zvýšené potřebě finančních či časových zdrojů potřebných k jeho realizaci.

V průběhu projektu je veden registr požadavků na změnu, za jeho vedení je odpovědný vedoucí projektu Atos IT Solutions and Services, s.r.o.

Proces řízení změn:

1. V rámci jednání na některé z úrovní řízení projektu je identifikován požadavek na změnu.

2. Požadavek za změnu je reportován na vedení projektu a registrován v projektovém registru změn.

3. Vedení projektu požadavek vyhodnotí, pokud je požadavek vyhodnocen jako přínosný pro projekt, snaží se nejprve nalézt řešení, které je realizovatelné v rámci smluvně dohodnutých termínů plnění, způsobu provedení díla a ceny, přičemž v takovém případě je vedení projektu kompetentní o takovém požadavku rozhodnout.

4. Pokud není požadavek na změnu řešitelný na úrovni vedení projektu, je požadavek eskalován na vyšší úroveň řízení projektu (řídící výbor projektu).

5. Řídící výbor projektu vyhodnotí požadavek na změnu a pokud realizace požadavku vyžaduje změnu smluvních podmínek, zahájí osoby pověřené jednáním ve věcech smluvních jednání o příslušném dodatku smlouvy.

6. Změna je provedena podle dodatku Smlouvy.

1.5.1.8 Monitorování a reportování průběhu projektu

Projektové týmy

Z jednání projektových týmů budou pořízeny zápisy, které budou obsahovat shrnutí o:

• smluvených činnostech (včetně činností pro vyřešení problémů),

• učiněných rozhodnutích,

• stanovení úkolů a termínů plnění,

• odsouhlasených dílčích plněních,

• problémových oblastech.

Za zpracování zápisů z jednání projektových týmů je odpovědný jeho vedoucí. Tyto zápisy budou sdíleny a předávány vedení projektu elektronickou poštou.

Vedení projektu

Z jednání vedení projektu budou pořízeny zápisy, které budou obsahovat informace o:

• stavu řešení projektu,

• učiněných rozhodnutích,

• stanovení úkolů a termínů plnění,

• řešení otevřených otázek a změn,

• řízení rizik,

• požadavcích na součinnost.

Vedení projektu dále připravuje podklady pro jednání řídícího výboru projektu.

Řídící výbor

Z jednání řídícího výboru projektu budou pořízeny zápisy, které budou obsahovat informace o:

• stavu řešení projektu,

• učiněných rozhodnutích.

Za zpracování zápisů z řídícího výboru projektu jsou odpovědní vedoucí projektu za Atos a objednatele.

1.5.1.9 Řízení rozpočtu projektu

Principy řízení rozpočtu:

• Cena za realizaci díla a jeho jednotlivých etap je uvedena ve smlouvě.

• Cena za realizaci díla je konečná a obsahuje všechny náklady dodavatele, spojené s realizací projektu.

• Platba za realizaci jednotlivých etap je uskutečněna na základě akceptačního protokolu, který bude přílohou faktury.

• Požadavky na změny, mající vliv na cenu za realizaci jsou řešeny podle zásad změnového řízení.

• Za řízení rozpočtu projektu je jsou odpovědni vedoucí projektu dodavatele a objednatele.

1.5.1.10 Schvalování výstupů

1. Dílo bude objednateli předáno postupně po jednotlivých etapách podle zpracovaného harmonogramu projektu.

2. Předání a převzetí Etapy Díla bude provedeno za použití smluvní akceptační procedury a

těchto principů1:

a) Xxxxxxxxx navrhne akceptační kritéria tak, aby mohla být projednána a odsouhlasena osobou odpovědnou ve věcech technických za objednatele nejpozději 5 kalendářních dnů před plánovaným termínem předání příslušné Etapy Díla k akceptaci.

b) Předání příslušné Etapy Díla k akceptaci Dodavatelem bude potvrzeno podpisem objednatele na předávacím protokolu. Dodavatel zpracuje i návrh akceptačního protokolu a předkládá jej objednateli současně s předávacím protokolem. Akceptační protokol bude obsahovat akceptační kritéria dohodnutá způsobem dle předchozího písm. a) tohoto odstavce.

c) Podpisem předávacího protokolu a předložením návrhu akceptačního protokolu začíná akceptační období v délce 10 kalendářních dní. Akceptační období může být po dohodě smluvních stran zkráceno na méně než 10 kalendářních dní.

d) Objednatel je povinen do konce akceptačního období provést buďto akceptaci předaného plnění formou podpisu akceptačního protokolu (bez výhrad nebo s výhradami) nebo akceptaci odmítnout a v předloženém akceptačním protokolu uvést, v čem vidí objektivní příčinu nesplnění dohodnutých akceptačních kritérií, pro které tento předmět plnění neakceptuje.

e) Objednatel může akceptaci odmítnout pouze v případě, že předaná Etapa Díla vykazuje na základě vyhodnocení akceptačních kritérií natolik vážné vady, že nemůže sloužit svému účelu vůbec nebo s výraznými omezeními. V případě méně vážných vad se použije akceptace s výhradami. V případě akceptace s výhradami se Etapa Díla považuje za řádně akceptované.

1 tyto principy mají za cíl zpřesnit akceptační proceduru oproti jejímu popisu v odst. VII smlouvy. V případě rozporu platí ustanovení odst. VII smlouvy.

f) Po marném uplynutí akceptačního období, aniž objednatel koná dle písm. d) tohoto odstavce či písemně požádá o odklad nebo začne předmět Etapy Díla nebo jeho část užívat, aniž by bylo z jeho strany řádně akceptováno, bude předmět plnění považován smluvními stranami za akceptovaný (tzv. fikce akceptace).

g) V případě, že akceptace byla provedena s výhradami objednatele, je Xxxxxxxxx povinen zjednat nápravu do 14-ti kalendářních dní, nebude-li dohodou obou smluvních stran stanoveno jinak.

3. V případě, že objednatel neakceptuje plnění, pro která bylo započato akceptační období dle písm. c) tohoto odstavce z důvodu nesplnění akceptačních kritérií, nebo nepředání předmětu plnění k akceptování ve stanoveném termínu dle harmonogramu plnění, je Dodavatel povinen zjednat nápravu a předat dílčí plnění k opakované akceptaci v tzv. odkladném období 14-ti kalendářních dní, pokud nebude dohodou obou smluvních stran sjednáno jinak.

4. Autorizované osoby pro podpis výše uvedených protokolů jsou za obě smluvní strany:

▪ Předávací protokoly – oprávněné osoby ve věcech technických nebo jejich zástupci.

▪ Akceptační protokoly – oprávněné osoby ve věcech obchodních nebo jejich zástupci.

5. Osoby oprávněné ke schvalování výstupů:

▪ podpisu předávacích protokolů

▪ podpisu akceptačních protokolů pro plnění dle této smlouvy a

▪ podpisu Protokolu o provedení služby nebo jeho části (modulu) do produkčního provozu

projektový manažer Xxx. Xxxxx Xxxxx.

6. Pro předání a převzetí díla se používají následující formuláře:

Předávací protokol

Zákazník:		Název projektu:
Zpracoval:		Požadované datum akceptace:
Smlouva:	č.

Popis
K akceptaci k milníku projektu <Název milníku dle smlouvy> jsou předávány následující výstupy projektu: 1.
Předložil:		Datum:
Podpis:
Za zákazníka převzal:		Datum:
Podpis:

Výhrady / Omezení / Poznámky / Komentáře
Výhrady k předávanému plnění:
□ Převzato s výhradami		□ Nepřevzato
Jméno:		Datum:
Podpis:

Akceptační protokol

Zákazník:		Název projektu:
Zpracoval:		Akceptační milník:
Smlouva:	č.

Popis
K akceptaci k milníku projektu <Název milníku dle smlouvy> byly předány následující výstupy projektu: 1.
Předložil:		Datum:
Podpis:
Za zákazníka akceptoval:		Datum:
Podpis:

Kritéria akceptace / Výhrady
Akceptační kritéria: Výhrady k akceptovanému plnění:
□ Akceptováno s výhradami		□ Neakceptováno
Jméno:		Datum:
Podpis:

1.5.2 Rámcový harmonogram rozhodných a měřitelných událostí, milníků nebo předávaných výstupů

Poř. číslo	Měřitelná událost/milník	Předávaný výstup	Datum předání
1	- Analýza a návrh řešení - Platební milník	- Realizační projekt - Dokumentace popisující analýzu řešení Registru IKP	Do 6 týdnů od zahájení projektu
2	- Realizace - Platební milník	- Instalační balíčky souvisejících webových služeb - Instalační balíčky pro nové APV zajišfující obsluhu Registru IKP - Vyplněné testovací protokoly - Testovací dokumentace - Dokumentace APV Registru IKP • Uživatelská příručka • Bezpečnostní dokumentace • Instalační dokumentace	Do 4 měsíců od zahájení projektu
3	- Pilotní provoz - Platební milník	- Testy	Do 5 měsíců od zahájení projektu
4	- Realizace služeb a související dodávka APV - Platební milník	- Zdrojové kódy příslušných APV - Instalační, uživatelská a školící dokumentace - Administrátorská a provozní dokumentace - Instalační balíčky dodávaného APV	Do 6 měsíců od zahájení projektu

1.5.3 Popis identifikace možných rizik v souvislosti s realizací projektu a návrh jejich eliminace a vypořádání

Poř. číslo	Riziko	Návrh eliminace a vypořádání rizika
1	Pevná cena za celé řešení.	- Pravidelné projednání dosaženého stavu prací vedením projektu, důraz na soulad se zadáním. - Definovaná pravidla řízení rozpočtu projektu. - Definovaná procedura řízení změn.
2	Předepsaný časový rámec řešení.	- Zpracování a schválení detailního harmonogramu řešení. - Pravidelná kontrola dosaženého stavu prací vůči harmonogramu. - Přijímání opatření při zjištěných odchylkách. - Eskalace problému podle definované eskalační procedury.
3	Vysoká míra integrace řešení na okolní systémy, zejména na oblast informací z důchodové agendy.	- Aktivní spolupráce ČSSZ zejména v oblasti zpřístupnění informací z důchodové agendy.
4	Nutné úpravy aplikací, které nebude zajišfovat Atos.	- Pravidelná kontrola dosaženého stavu prací na vedení projektu. - Eskalace eventuálních problémů.
5	Integrace s aplikacemi, které nesplňují standardy ČSSZ.	- Definování a schválení nezbytného rozsahu požadovaných úprav těchto aplikací.

Poř.

číslo

Riziko

Návrh eliminace a vypořádání rizika

Spolupráce s ČSSZ

v celém průběhu řešení.

- Definování požadované součinnosti ve smlouvě.

- Upřesňování potřebné součinnosti provádět v rámci vedení projektu.

- Eskalace eventuálních problémů.

V současnosti neexistuje integrační prostředí pro systémy spolupracující

s registrem IKP.

- Vyžádání součinnosti ČSSZ.

1.5.4 Požadavky na součinnost zadavatele.

Oblast součinnosti	Požadavek na součinnost	Etapa projektu
Technická	- HW a SW vybavení v integračním, testovacím a produktivním prostředí dle akceptovaných požadavků dodavatele.	Etapa 2,3,4
	- Zajištění realizace rozhraní na spolupracující systémy a produkty třetích stran v termínech uvedených v harmonogramu dle akceptovaných požadavků zadavatele.	Etapa 1,2,3,4
	- Technické zajištění systémových a akceptačních testů, poskytnutí potřebné infrastruktury a testovacích dat dle akceptovaných požadavků zadavatele a v součinnosti s vlastníkem APV.	Etapa 2,3,4
	- Zajištění nezbytných instalací a pokrytí souvisejících administrativních postupů při instalacích APV.	Etapa 2,3,4
	- Potřebné prostory k zajištění požadovaných činností.	Etapa 1,2,3,4
	- Správa, administrace a provozování dodaného a upraveného APV, včetně správy, administrace a provozování produkčního, testovacího/školícího a	Etapa 2,3,4

Oblast součinnosti	Požadavek na součinnost	Etapa projektu
	integračního prostředí APV.
	- Umožnění vstupu a pohybu v prostorách Odběratele pracovníkům Dodavatele a jeho subdodavatelů v rozsahu nezbytném pro poskytování plnění.	Etapa 1,2,3,4
Analytická	- Poskytnutí dalších nezbytných podkladů a konzultací doplňujících podklady obsažené v zadávací dokumentaci, aktivní účast na schůzkách.	Etapa 1,2,3,4
	- Specifikace zadání a požadavků na úpravy APV v rámci zpracování dílčího plnění Dodavatele.	Etapa 1,2,3,4
	- Spolupráce na tvorbě a oponentuře jednotlivých výstupů v průběhu celého projektu.	Etapa 1,2,3,4
Legislativní	- Vymezení legislativního rámce, právní a metodická podpora při výkladu a posouzení správnosti implementace platné legislativy a připravovaných legislativních změn.	Etapa 1,2,3,4
	- Identifikace možné potřeby legislativních opatření nebo jejich signalizaci příslušnými odborníky.	Etapa 1,2,3,4
	- Průběžné sledování výstupů projektu z důvodu předcházení problémům legislativního charakteru.	Etapa 1,2,3,4
	- Schválení a vydání odpovídajících směrnic a pracovních postupů.	Etapa 2,3,4
Personální	- Jmenování projektového týmu a jeho dekompozice na jednotlivé řešitelské týmy (např. analytický, školicí, tým bezpečnosti a podobně).	Etapa 1
	- Jmenování garantů APV, klíčových uživatelů, školitelů a správců.	Etapa 1
	- Dostupnost těchto pracovníků pro práci v rámci projektu v rozsahu nezbytném pro plnění úkolů vyplývajících z jejich role, kvantifikovaná po jednotlivých etapách.	Etapa 1,2,3,4
	- Vybavení těchto pracovníků nezbytnou odpovědností a jí odpovídajícími pravomocemi.	Etapa 1,2,3,4

Oblast součinnosti	Požadavek na součinnost	Etapa projektu
Projektová	- Vedení projektu jako celku a organizace spolupráce všech subdodavatelů a projektových týmů Zadavatele neřízených Dodavatelem.	Etapa 1,2,3,4
	- Realizace souvisejících projektů, realizovaných ČSSZ nebo třetími stranami v termínech harmonizovaných s tímto projektem (konkrétní výčet a požadovaný obsah realizace), pokud je to relevantní.	Etapa 1,2,3,4
	- Odpovědnost za testování aplikací v součinnosti s vlastníkem APV včetně spolupráce při vytváření akceptačních testů a jejich vyhodnocení.	Etapa 2,3,4
	- Součinnost ČSSZ při přípravě pilotního a produktivního provozu.	Etapa 3,4
	- Připomínkování a schvalování výstupů projektu v přiměřených termínech a lhůtách, aby nedocházelo k narušení harmonogramu projektu.	Etapa 1,2,3,4
	- Účast na školení klíčových a koncových uživatelů.	Etapa 2,3,4
	- Podpora při identifikaci příčin zjištěných chyb a při jejich odstraňování, zajištění potřebných logů a chybových hlášení poskytovaných jednotlivými prvky infrastruktury, poskytnutí nástrojů pro vyhledávání příčin chybových stavů aplikací a nahlášených problémů.	Etapa 2,3,4
	- Řešení chyb a odstranění jejich příčin v případě zavinění třetí stranou.	Etapa 2,3,4

Požadavky na součinnost budou upřesňovány v rámci jednání vedení projektu podle konkrétních potřeb v jednotlivých etapách projektu.

1.6 Technická podpora a podpora rozvoje

1.6.1 Popis způsobu poskytování technické podpory a rozvoje systému

Rozsah a způsoby poskytování technické podpory lze samostatně popsat pro jednotlivé fáze realizace projektu.

1.6.1.1 Analytická a realizační fáze projektu

V průběhu projektových etap „Analýza a návrh řešení“ a „Realizace“ je předmětem technické podpory zejména zajištění konzultačních a koordinačních činností pro vymezení konkrétních pravidel a postupů integrace APK IKP na okolní systémy. To se týká zejména systémů, které budou vzhledem k zapojení registru IKP upravovány.

1.6.1.2 Pilotní provoz

V průběhu projektové etapy „Pilotní provoz“ bude poskytovanou technickou podporu tvořit zejména:

• Poskytnutí nástroje Issue manager pro hlášení a správu záležitostí vyplývajících z průběhu testování pro projekt IKP. Zpřístupnění a provoz nástroje Issue manager bude plně zajišfovat dodavatel (správa přístupových oprávnění, předvedení aplikace, provozní infrastruktura a administrace provozu). Nástroj bude dostupný jako tenký klient přímo z počítačového vybavení koncových uživatelů ČSSZ (členů projektového týmu IKP).

• Podpora a koordinační činnosti při nastavení technické infrastruktury pro provoz APV registru IKP v integračním a testovacím prostředí ČSSZ.

• Podpora provádění instalací APV IKP do prostředí ČSSZ, konfigurace APV Registru IKP v prostředí ČSSZ. Jde o koordinační činnosti spojené s nasazování APV Registru IKP do prostředí ČSSZ, poskytování technických konzultací spojených s tímto nasazováním a souvisejícím provádění konfigurací a zprovozňování jednotlivých součástí řešení.

• Podpora administrace provozu dodávaného řešení APV registru IKP v integračním a testovacím prostředí ČSSZ, zejména s ohledem na integraci na okolní systémy (ověření konfigurace, dostupnosti integračních rozhraní a služeb, ověření datové připravenosti, zjištění příčin a řešení nestandardních situací souvisejících v rozsahu řešení registru IKP a integračních vazeb).

• Podpora poskytovaná členům realizačního týmu ČSSZ se zaměřením na testování dodávaných částí APV v prostředí ČSSZ (předvedení aplikace, konzultační podpora členům projektového týmu ČSSZ).

1.6.1.3 Uvedení do produkčního provozu

V průběhu projektové etapy „Uvedení do produkčního provozu“ bude poskytovanou technickou podporu tvořit zejména:

• Podpora a koordinační činnosti při nastavení technické infrastruktury pro provoz APV registru IKP v produkčním prostředí ČSSZ.

• Podpora instalace a konfigurace APV registru IKP do produkčního prostředí ČSSZ (např. koordinační činnosti, vysvětlení pokynů, ověření připravenosti instalovaného APV a souvisejících integračních vazeb na okolní systémy).

• Podpora provedení jednorázového prvotního naplnění registru IKP daty z okolních systémů (ověření připravenosti, provedení, kontrola výsledků, řešení neočekávaných situací, potvrzení dalšího postupu k zahájení pravidelných aktualizací, zvýšený dohled).

• Poskytnutí služeb centrálního helpdesk (CHD) systému společnosti Atos pro hlášení a správu incidentů a požadavků spojených s nasazením a provozem realizovaného APV v produkčním prostředí ČSSZ.

• Poskytnutí tříměsíční technické podpory provozu APV registru IKP v produkčním prostředí ČSSZ.

1.6.1.4 Záruční lhůta

V průběhu záruční lhůty spočívá technická podpora zejména v:

• Připravenost reagovat na požadavky ČSSZ týkající se rozvoje APV registru IKP (spolupráce při hledání možných řešení, vytvoření návrhu řešení) a připravenost řešit rozvojové požadavky v rámci samostatných projektů.

Document Metadata

Table of Contents

Příloha č. 1 – Specifikace smlouvy

Document Metadata