Specifikace p edm tu pln ní a technické požadavky

Transkript

1 íloha. 1 k Rámcové smlouv Specifikace pedmtu plnní a technické požadavky

2 Obsah 1 Úvod Pedmt veejné zakázky Specifikace APV APV ZDV (databáze zdrojových datových vt) Legislativní rámec Popis aplikace Architektura aplikace Použité technologie APV DMS (Document management systém) Legislativní rámec Popis aplikace Architektura aplikace Použité technologie APV DMS (ATV) Popis aplikace Architektura aplikace APV ATR (obecné ešení úloh ATT, ATT_INS, ATR_EXK) Popis aplikace Architektura aplikace Digitalizaní linka Legislativní rámec Popis aplikace Architektura aplikace Použité technologie Standardy IKT SSZ Výkonnostní požadavky Rozvoj aplikace APV ZDV, DMS (ATV), ATR a Digitalizaní linka Projektové ízení Analytická ást Vývojová ást Testovací ást Školení

3 4.6 Nasazování do produkce Požadované souinnosti Zajištní aplikaní podpory APV ZDV, DMS (ATV), ATR a Digitalizaní linka Pevzetí do servisu Rozsah pevzetí do servisu Poskytování aplikaní podpory APV ZDV, DMS, (ATV), ATR a Digitalizaní linka Návrh SLA Algoritmus vyhodnocení aplikaní podpory Rozsah služeb aplikaní podpory

4 1 Úvod 1.1 Smyslem a úelem Pílohy. 1 Rámcové smlouvy o vývoji a údržb aplikaního programového vybavení pro blok podprné systémy ZDV, DMS (ATV), ATR a Digitalizaní linka II (dále jen Rámcová smlouva ), uzavené v souladu s ustanovením 89 a následujícími zákona. 137/2006 Sb., o veejných zakázkách, ve znní pozdjších pedpis (dále jen ZVZ ), ustanovením 1746 odst. 2 zákona. 89/2012 Sb., obanský zákoník, ve znní pozdjších edpis (dále jen obanský zákoník ) a v souladu s ustanovením 2358 a následujícími obanského zákoníku, je zejména: a) podrobn a pehledn vymezit pedmt plnní Rámcové smlouvy, oddlen od ostatních ustanovení Rámcové smlouvy, b) stanovit technické specifikace pedmtu plnní, c) vymezit pedmt plnní prostednictvím návrh Zhotovitele. 1.2 Obchodní a technické podmínky a podmínky plnní dle Rámcové smlouvy stanovené Objednatelem není Zhotovitel oprávnn upravovat. 1.3 Zhotovitel je oprávnn a zárove povinen specifikovat v rámci této Pílohy. 1 Rámcové smlouvy pedmt plnní v rozsahu, který je mu dán Objednatelem (viz grafické znázornní a upozornní na povinnost doplnní píslušných informací, návrh apod.). 3

5 2 edmveejnézakázky Objednatel požaduje vypracování komplexní nabídky pro blok podprné systémy, která zajistí stabilní rozvoj APV ZDV, DMS (ATV), ATR a Digitalizaní linka, dále podporu stávající aplikace ZDV, DMS (ATV), ATR a Digitalizaní linka i nov dodaných produkt a poskytnutí souinnosti pi nasazování nových verzí aplikace do systému. Plnní bude sjednáno na dobu 4 let. Nabídnutá dodávka a služby tvoí: Rozvoj ZDV, DMS (ATV), ATR a Digitalizaní linka o Zapracování úprav stávajícího APV ZDV, DMS (ATV), ATR a Digitalizaní linka (legislativní zmny, úpravy v aplikacích ZDV, DMS (ATV), ATR a Digitalizaní linka na základ požadavk metodik a návrh uživatel), vývoj a sestavení nových komunikaních rozhraní se stávajícími i nov vytvoenými aplikacemi a vypracování íslušné dokumentace Poskytování aplikaní podpory o o evzetí do servisu Poskytování podpory APV ZDV, DMS (ATV), ATR a Digitalizaní linka 4

6 3 SpecifikaceAPV Blok podprné systémy tvoí tyto aplikace: ZDV, DMS (ATV), ATR a Digitalizaní linka. 3.1 APVZDV(databázezdrojovýchdatovýcht) Legislativnírámec Oblast ZDV podléhá interním pedpism a standardm SSZ Popisaplikace Databáze zdrojových datových vt se využívá jako úložišt vstupních datových vty (XML) azené k jednotlivým pípadm (klientm). Do ZDV jsou ukládána veškerá vstupní strukturovaná data a to jak poízená klienty a podaná v elektronické podob, tak rozpoznaná data z papírových podání i data poízená pracovníky eské právy sociálního zabezpeení (dále jen SSZ v jednotlivých agendách. Tato data jsou používána jako vstupní data pro jednotlivé agendy SSZ. Jednotlivé aplikace využívají komponentu pro zobrazení dat ZDV, která je souástí ZDV a dále je souástí klient ZDVBrowser. Dále aplikace využívají rozhraní aplikace službu wszdv Architekturaaplikace Interní architektura APV ZDV APV ZDV je tvoena moduly: DB vrstva Webová služba wszdv Klient Komponenta pro integraci klient Souástí APV jsou dále níže uvedené komponenty sdílené v rámci IIS SSZ: Scheduler (SCH) integraní komponenta pro plánování a ízení asynchronních úloh Dávkový procesor (DAP) integraní komponenta pro dávkový penos dat mezi APV/systémy IIS SSZ s definovanou transformací Application Status (APS) systémová komponenta pro identifikaci živosti APV/systému Spolupracující aplikace S aplikací komunikují tyto systémy: KL UI44 PKS VZT UI08 NEM POJ EXK ZDD DMS klienti KL TC2 5

7 SI2 DIS IPK Použitétechnologie Microsoft.NET Framework 3.5 Microsoft Windows Server 2003 Microsoft IIS Server 6 Oracle DB Driver 10g Oracle 10g 3.2 APVDMS(Documentmanagementsystém) Legislativnírámec Oblast Document management systém je v eské republice obecn legislativn vymezena tmito hlavními právními pedpisy: zákon. 499/2004 Sb. o archivnictví a spisové služb a jeho novelizace - zákon. 190/2009 Sb. s úinností od zákon. 300/2008 Sb. o elektronických úkonech a autorizované konverzi dokument ve znní pozdjších pedpis zákon. 227/2000 Sb. o elektronickém podpisu a o zm nkterých dalších zákon (zákon o elektronickém podpisu) ve znní pozdjších pedpis zákon. 365/2000 Sb. o informaních systémech veejné správy ve znní pozdjších pedpis vyhlášky. 191/2009 Sb., 192/2009 Sb., 193/2009 Sb. a 194/2009 Sb Popisaplikace DMS je systém, který zabezpeuje innosti související s pijímáním, zpracováváním, vydáváním a ukládáním elektronických dokument vetn zabezpeení jejich obhu. Do systému pistupují uživatelé pracovníci SSZ pes webové rozhraní po autorizaci a písné autentifikaci. Jednotlivým uživatelm jsou zpístupnny pouze ty funkní ásti (klientské aplikace) a píslušné informace (data), na která mají oprávnní definovaná prostednictvím pidlených rolí a pozic v AAA Portálu. Veškerý pístup k dokumentm uloženým v DMS je pln podízen kontrole práv ístupu nezávisle na tom, ze které klientské aplikace DMS k nim uživatel pistupuje. Každý dokument je v DMS uložen jako objekt s povinnou strukturovanou ástí tzv. profilem dokumentu (metadaty) a vlastním souborem dokumentu (tlo dokumentu). Tlo dokumentu edstavuje obecn binární soubor v libovolném formátu (nap.:.doc,.xls,.pdf,.dgw,.xml,.html,.tif a další) Architekturaaplikace Interní architektura APV DMS Systém DMS má k dispozici následující klientské aplikace: Klient Evidence podání evidence podání dokument Aktivní klient vyhledávání a úprava dokument DMS Univerzální klient vyhledávání a prohlížení dokument DMS Aplikaní podpora DMS dále zahrnuje komponentu DMSViewer (DMV, DMP) sdílenou v rámci IIS SSZ, která slouží pro zajištní náhledu na dokumenty uložené v DMS prostednictvím unifikovaného rozhraní. Na SSZ jsou vytvoena celkem ti prostedí systému DMS - integraní prostedí, testovací/školící prostedí a produkní prostedí. Ve všech tchto prostedích je nainstalován produkt IBM DB2 Content Manager for Multiplatforms, verze 8.4.2, FP2. 6

8 DMS Klienti (IE) ?? PC administrátora Klienti (IE) ws.cssz.cz/dms dms.cssz.cz:9081 dms.cssz.cz ws.cssz.cz/t-dms t-dms.cssz.cz WebSeal ws.cssz.cz/i-dms I-dms.cssz.cz WebSeal CSS / NAT CSS / NAT TCP Proxy Aplikaní Server RM Aplikaní Server RM-záložní Aplikaní Server API Aplikaní Server API Aplikaní Server API Aplikaní Server A Aplikaní Server B Aplikaní Server C Aplikaní Server RM, WF API Soubory Aplikaní Server A TCP Proxy Aplikaní Server, RM Soubory Aplikaní Server A, API, WF Databázový server CM - LS DB server DB server Soubory ORACLE Database ORACLE Database ORACLE Database Produkní Školící (Pilotní) Integraní Spolupracující aplikace Vzhledem k zaazení APV DMS jako prezového subsystému v rámci informaního systému SSZ, poskytuje DMS aplikaní a klientské rozhraní externím agendovým aplikacím a také uživatelm. Hlavním cílem systému DMS jsou innosti související s pijímáním, zpracováváním, vydáváním a ukládáním elektronických dokument vetn zabezpeení jejich obhu. Systém DMS dále využívá tchto APV implementovaných na SSZ: AAA portál DB ZDV Kmenové evidence Biz Talk Server Použitétechnologie IBM DB2 Content Manager for Multiplatforms, verze 8.4.2, FP2 Oracle 10g ( ) IBM WebSphere Application Server IBM HTTP Server Microsoft Windows Server 2003 Microsoft Word, Microsoft Excel 3.3 APVDMS(ATV) Popisaplikace Archiv tiskových výstup (ATV) je uren pro ukládání, správu a zpístupnní dokument, které jsou vytváeny jako výstupy z agendových aplikací SSZ. Tyto dokumenty, které jsou z aplikací 7

9 zpravidla pedány k vytisknutí a odeslání, jsou paraleln pedány i do ATV k uložení. Dokumenty pedávané na vstup ATV se skládají ze dvou ástí: lo = vlastní data dokumentu, Metadata = atributy dokumentu pedané ve formátu XML reprezentace. Pro archivaci dokument je implementována funkcionalita tzv. obecného tla dokumentu, tj. je možné do ATV ukládát jakýkoliv formát dokumentu podporovaný íselníkem formát DMS Architekturaaplikace Vnitní architektura ATV je založena na tívrstvém modelu lenném na datovou, aplikaní a prezentaní vrstvu. Tato architektura je podporována použitým produktem IBM Content Manager OnDemand (CMoD). Datová vrstva obsahuje technologie pro ukládání obecných datových objekt. Jedná se o systém ízení bází relaních dat, dokumentové i objektové báze a systémy pro dlouhodobé ukládání velkých objem dat. Aplikaní vrstva implementuje logiku systém pro správu dokument. V této vrstv jsou také realizovány vazby na agendové aplikace. Prezentaní vrstva realizuje rozhraní systém vi jejich uživatelm. Na úrovni prezentaní vrstvy mže být provedena integrace dílích aplikací do jednotného rozhraní (klienta), které zjednodušuje jejich používání a odstrauje nkteré opakované innosti jako je napíklad ihlašování k jednotlivým systémm. 3.4 APVATR(obecnéešeníúlohATT,ATT_INS,ATR_EXK) Popisaplikace V souasné dob jsou v produkním prostedí SSZ nasazeny ATR_EXK a ATT_INS vycházející ze spoleného základu. APV poskytuje služby obecného nástroje pro generování výstup: 1. lokální tisk, 2. centrální tisk. Tyto služby mají následující spolené vlastnosti: 1. generování náhledu, 2. integrace s AAA, 3. archivace v ATV, 4. tvorba výstupu na základ vstupní dat a pednastavitelné šablony, 5. zajištní transakního a dávkového zpracování výstup, 6. centrální správa tiskových šablon a použitých íselník. ATR_EXK je modul vycházející z SDD ATR, který je uzpsoben potebám subsystému EXK. Jedná se edevším o doplnní o lokální tisky. Tento modul umožuje tvorbu výstup v podob rozhodnutí a oznámení, zprostedkuje referentovi možnost náhledu na výstupní dokumenty, zajistí jeho tisk a následnou archivaci pro pípad dohledání. ATR_EXK má realizovanou vazbu na systémy PRES, DMS Viewer, DAP, ATV. Práce se šablonami v rámci ATR_EXK je pomrn složitá, v nkterých pípadech specifická a pizpsobena situaci bez dodržení základních architektonických princip. 8

10 ást ATT_INS je urena a vyvíjena pro agendu INS pro tiskové výstupy. Pro archivaci využívá vazbu na aplikaci ATV. V souasné dob jsou pomocí tohoto systému generovány výstupy pro aplikaci PVO generování platebních vým OSV Architekturaaplikace Základní koncepce a jádro systému je stejné pro všechny provozované ATT, resp. ATR aplikace. Front end ešení je tlustý klient pomocí, kterého uživatel spravuje systém a vytváí tiskové úlohy. Hlavní inností stední vrstvy je generování výstupních imag a s tím spojených inností (ukládání, enos do PRESu a ATV, ). Spodní vrstva poté ešení ukládání dat. ešení je postaveno na technologii MS.NET 2.0 s využitím komponety Active Reports 2.0 nebo 6.0 (použito v ATT INS). Tato komponenta je použita ve dvou režimech: Generování náhled a tisk použití na stední vrstv. Editor tiskových úloh použití v klientské aplikaci Ob provozovaná ešení mají spolené následující ásti: 1) shodnou architekturu ešení, 2) stejnou množinu funkcí pro tvorbu šablon (v obou dvou aplikacích lze docílit stejných výsledk; mají shodnou sadu nástroj), 3) implementují stejný princip transakního tisku, 4) jsou integrovány na stejné okolní systémy ATV, AAA, SDD-íselníky, pomocí DAP na PRES. 5) pro ob dv aplikace platí shodné administrátorské postupy. Veškerá komunikace s navazujícími systémy, resp. se systémy využívajících služeb ATT je pomocí webových služeb. Subsystémy EXK a INS jsou postaveny na JAVA technologiích a jsou pln integrovány na rozhraní ATR EXK, resp. ATT INS. Aplikace PVO je samostatná lokální aplikace vytvoená na technologii.net a je pln integrovaná na rozhraní ATT INS. Z tohoto pohledu již souasné ešení umožuje snadnou integraci nezávislou na cílové platform navazující aplikace (.NET a JAVA). Základní kamenem ešení tisková úloha. Tiskovou úlohou se v rámci ATT rozumí soubor nkolika dokument ve formátu XML, pop. XSD. Tisková úloha se skládá: XSD pro validaci vstupní datové vty, XML definici vlastního tiskového reportu tisková šablona, po. pedloha, XML definici všech použitých íselník v tiskové šablon. Vstupní datová vta se skládá ze tí element: metadata obsahuje obecné informace pro ízení zpracování vstupního požadavku, údaje pro generování výstupu a penos do ATV, pop. PRESu. Dále obsahuje pesnou definici tiskové úlohy, v. Její verze. adresní data obsahuje údaje pro adresní ást tiskové pedlohy data pro tisk obsahuje ostatní údaje vyžadované tiskovou úlohou definovanou v metadatech. Na základ vstupní datové vty, definovaných íselník a tiskové úlohy je sestaven konený výstupní report, který je poté transformován do píslušného image. Systémy ATT podporují image ve formátech TIFF a PDF. 9

11 3.5 Digitalizanílinka Legislativnírámec Oblast aplikací Digitalizaní linky je v souasné dob urena pedevším pro digitalizaci a vytžování doklad a nárokových podklad dchodového pojištní. Zpracovávají nárokové podklady obsahující informace o dobách a výdlcích pojištnc dchodového pojištní: Ve smyslu zákona. 582/1991 Sb., o organizaci a provádní sociálního zabezpeení ve znní pozdjších pedpis. V souladu s pedpisem upravujícím nároky na dchody, zpsob stanovení výše dchod a podmínky pro jejich výplatu je zákon. 155/1995 Sb., o dchodovém pojištní, který nabyl innosti 1. ledna Popisaplikace Jedná se o nkolik aplikací, které zajišují digitalizaci píchozích informací o nárocích pojištnc. V rámci digitalizace jsou dokumenty naskenovány, indexovány a vytvoena za pomoci OCR datová ta. Poizovací linka slouží pedevším v procesu zpracování nových žádostí o dchodovou dávku, kde je ízena aplikací Work a spouštna je souborem avíz. Pržn píchozí nárokové podklady jsou zpracovány ze zásob a zpracování se ídí hodnotou stavu. Skenování doklad o ídní dokument o procesing (uložení obrazu dokumentu), filtrace, pedindexace o tisk prvodek o Kontrola nárokových podklad o Indexace o Opravy Tvorba datových vt (zdrojových datových vt) o rozpoznávání doklad, o vytžování nárokových podklad ELDP (platných ped r. 2004), o vytžování nárokových podklad RELDP, o vytžování nových žádostí, o POCR (ZOCR,DOCR) zásobování OCR. Kontrola, testy zdrojových datových vt o o v rámci vytžovacího profilu OCR aplikace ZOCR volá modul INP01 (není souástí APV Digitalizaní linka), který pi úspšné kontrole vytváí JDV (JDV01.) Architekturaaplikace Digitalizaní linku tvoí aplikace, které se specializují na tvorbu datové vty z digitálních obraz nárokových podklad (scan). V každé ásti zpracování nabývá elektronický záznam nárokového podkladu specifického stavu (statusu), který vyznauje, která ást zpracování byla provedena. Elektronické obrazy nárokových podklad jsou ke zpracování pedkládány zásobovacími aplikacemi a v pípad nových žádostí jsou ízeny workflow (aplikace Work). Zásobování a workflow je spouštno na základ asového harmonogramu. 10

12 3.5.4 Použitétechnologie Klient Windows XP, Windows 7, C++, OCR Vytžovací profily Serverová ást: o Linux, o Windows server 2003, o Visual Basic 6 o Databázové scripty, o Databáze pervasiv, OCR Engine Teleform Spolupracující systémy jsou na platform: o Microsoft Windows Server 2000, 2003 o Moduly Windows Basic 6, o Microsoft IIS Server 5.0 a 6.0, Apache o DB Oracle o Microsoft Excel 2003/ StandardyIKTSSZ Vývoj, rozvoj a údržba aplikaního programového vybavení realizovaného v rámci pedmtného plnní musejí být provedeny v souladu se standardy IKT SSZ platnými v dob realizace. Seznam aktuáln platných standard je uveden v následující tabulce:. Název souboru Název dokumentu Verze 1. std_db_060803_v0.91.doc Standard databází std_inet_1-10.doc Standard pipojení k Internetu std_pošta_1-00d.doc Standard poštovního systému SSZ std_ad_dns_dhcp_ntp_1-34.pdf Standard AD DNS DHCP std_avo1-10.doc Standard Antivirové ochrany Standard systémové konfigurace Standard systémové konfigurace pracovní 2.20 pracovní stanice 2.20 stanice 7. Std_mgmt_v.0.54.doc Standard Management std_metodikavyvoje_apv_1_0_19.doc Standard metodiky vývoje 1_0_19 9. std_pravidlareleasemanagementu_apv _1_2_6.pdf etn formulá edávání APV a repase 1_2_6 10. std_net_1-92d.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_ BizTalkDevelopmentStandard.v1.00.do c 13. AAA_Pozadavky_na_aplikace_v8.doc 14. Standard_pro_tvorbu_skriptu_db_Orac le_0.2.doc 15. CSSZ_DMS_WS_API_DMA_v3_3_ doc Standardy pro tvorbu aplikací pro Microsoft BizTalk server 1.00 Požadavky na nové aplikace pi integraci do AAA portálu 8.00 Standard pro tvorbu, pedávání 0.2 a spouštní skript v databázích Oracle API ROZHRANÍ SYSTÉMU DMA: WS_API_DMA - Standard rozhraní pro ukládání dokument do DMS 16. CSSZ_DU_STD_V011.1.doc Standard provozu databáze Oracle std_srv_0.23.doc Standard systémové konfigurace

13 aplikaních server 18. std_pki.pdf Standard pro PKI Výkonnostnípožadavky Níže jsou popsány standardní výkonnostní požadavky na fungování aplikace. Tato pravidla jsou obecnými standardy, pro konkrétní píklady je možné definovat delší doby odezvy, tyto výjimky ovšem musí být vždy definovány ve funkní specifikaci a podléhají schválení Objednatele. Obecné požadované výkonnostní požadavky jsou: Výkonnostní požadavek Požadovaná doba odezvy Požadované procento splnní Uživatelská odezva z front-endu aplikace (odezva pro jednu konkrétní aktivitu vyhledání, založení, ) Odezva online rozhraní (doba zpracování ) 1 sekunda 95% 5 sekund 99% 0,5 sekund 95% 3 sekund 99% V pípad rozvoje aplikace musí všechna nov vznikaná rozhraní i uživatelská volání splovat tyto požadavky. Potencionální nová rozhraní musí zaznamenávat dobu bhu konkrétních volání (staí zápisem do logu). U uživatelských volání musí být Zhotovitel schopen na požádání zmit a prokázat plnní výkonnostních parametr. 12

14 4 RozvojaplikaceAPVZDV,DMS(ATV),ATRDigitalizanílinka Úvod: V rámci rozvoje aplikace Objednatel pedpokládá poskytování služeb na implementaci rozvojových požadavk a požadavk na zmny v APV ZDV, DMS (ATV), ATR a Digitalizaní linka. V rámci této innosti musí Zhotovitel pro každou rozvojovou aktivitu, zajistit následující oblasti: Popis ešení a ocenní požadavk definovaných Objednatelem: o Zhotovitel se zavazuje dodat návrh ešení a ocenní konkrétních požadavk do 10 pracovních dní od data pedání požadavku Objednatelem. o Zhotovitel se dále zavazuje, že je schopen dodat kapacity potebné pro implementaci rozvojového požadavku okamžit po schválení návrhu ešení. Zajištní projektového vedení. Vytvoení funkní dokumentace, pípadn aktualizace stávající funkní dokumentace, pokud existuje. Zajištní implementace schváleného požadavku. Aktualizace technické dokumentace. íprava testovacích scéná a testovacích dat. Provedení test systémové, integraní, akceptaní, výkonnostní a penetraní: o Pro konkrétní požadavek nemusí být po dohod provádny všechny typy test. o V pípad, že velikost požadavku pesáhne 50 D, budou navíc provedeny regresní testy aplikace, pokud nebude dohodnuto jinak. o Objednatel mže rozporovat pechod mezi jednotlivými koly test, v pípad že kvalita dodávky nebude splovat dohodnutá kritéria. Aktualizace automatizovaných test (pokud existují). íprava reportu o provedení test. Aktualizace provozní dokumentace. íprava produkního balíku a postupu nasazení. Podpora nasazení do produkce. Zvýšená podpora bezprostedn po nasazení do produkce. Aktualizace logického a fyzického datového modelu (v pípad provádných zmn). 13

15 4.1 Projektovéízení Zhotovitel zajistí ešení všech disciplín projektového ízení celého projektu, vetn ízení potencionálních subdodávek dalších aplikací SSZ, které budou dodávat zmny vynucené projektem. Zhotovitel pedloží závazný popis projektového ízení dle výše uvedeného. Popis projektového ízení musí minimáln obsahovat: Metodiku projektového ízení; Metodiku ízení rizik; Metodiku ízení zmn; Metodiku release managementu; Organizaní strukturu projektu. (doplní Zhotovitel) 14

16 4.2 Analytickáást V rámci analytické ásti projektu Zhotovitel zajistí: Katalog požadavk a jeho aktualizaci; Konsolidace a ukotvení zadání; Ocenní pracnosti jednotlivých požadavk; Provedení analýzy požadavk; Návrh architektury jednotlivých úprav APV; Vytvoení detailního návrhu ešení úprav APV vetn návrh dopad do aplikaní i databázové vrstvy (v závislosti na rozsahu požadavk a dopad realizovaných úprav aktualizace íslušných dokument popisující procesní a funkní specifikaci, datovou architekturu, architekturu HW a SW, rozhraní a integraci s okolními APV a systémy) a zapracování zmn do stávající dokumentace; Analýza a návrh integrace dotených APV a systém do IS SSZ; ípravu a popis testovacích scéná pro jednotlivé typy test. Zhotovitel pedloží závazný popis plnní dle výše uvedeného. Zhotovitel minimáln popíše: Metodiku tvorby dokumentace; íklady všech pedpokládaných výstup. (doplní Zhotovitel) 15

17 4.3 Vývojováást V rámci vývojové ásti projektu Zhotovitel zajistí: Okomentovaný programový kód požadovaných zmn, se zapracováním požadovaných úprav ve zdrojových kódech píslušných APV (aplikaní i databázová vrstva); ízení a koordinace participace dotených a souvisejících tým a aplikací; Proces vývoje a pípravy nasazení, vytvoení instalaních balí pro cílovou platformu; Instalaní skripty; Návrh úpravy konfigurace veškerého ástí dodávky; Zapracování zmn v technické/programátorské dokumentaci (pípadn vytvoení); Zapracování zmn v uživatelské dokumentaci (pokud existuje); Poskytovat pípadné konzultace návrhu ešení na úrovni, architektury proces odborných agend, analýzy, designu, implementace, integrace a testování; Zajištní a správa vývojového prostedí; V pípad poteby provedení revize zdrojových aplikaních (programových) a databázových kód. Zhotovitel pedloží závazný popis plnní dle výše uvedeného. Zhotovitel minimáln popíše: Metodiku vývoje; Metodika pípravy nasazovacích balí pípadn používané nástroje; íklady pedpokládaných výstup. (doplní Zhotovitel) 16

18 4.4 Testovacíást Závazné obchodní podmínky: V rámci testovací fáze Zhotovitel minimáln zajistí: Podporu pi píprav testovacích prostedí; Funkní testy; Integraní testy; Akceptaní testy (provádí Zhotovitel, Objednatel akceptuje na základ akceptaního ízení); Technické testy (penetraní, výkonnostní); ípravu zpráv z testování. Objednatel plnní dle tohoto lánku (4.4 Testovací ást) akceptuje na základ akceptaního ízení. Zhotovitel pedloží závazný popis plnní dle výše uvedeného. Zhotovitel minimáln popíše: íklady pedpokládaných výstup; Úvodní návrh testovací strategie; Obecnou metodiku jednotlivých typ test. (doplní Zhotovitel) 17

19 4.5 Školení V pípad poteby Objednatele musí Zhotovitel zabezpeit vyškolení všech urených pracovník pracujících s aplikací. Objednatel plnní dle tohoto lánku (4.5 Školení) akceptuje na základ akceptaního ízení. Zhotovitel jako souást své nabídky pedloží závazný podrobný popis plnní dle shora uvedeného: Zhotovitel minimáln popíše: Návrh zpsobu školení; íklady školících materiál. (doplní Zhotovitel) 18

20 4.6 Nasazovánídoprodukce Zhotovitel musí zajistit následující aktivity: Naplánování nasazení do produkce; ípravu instalaního postupu; Úpravu provozní dokumentace; Definovat finální konfiguraci pro produkní prostedí; Podporu finálního produkního nasazení. Objednatel plnní dle tohoto lánku (4.6 Nasazování do produkce) akceptuje na základ akceptaního ízení. Zhotovitel pedloží podrobný závazný popis plnní dle výše uvedeného. Zhotovitel minimáln popíše: Návrh zpsobu nasazování do produkce; íklady relevantní dokumentace; Popis provozní dokumentace. (doplní Zhotovitel) 19

21 4.7 Požadovanésouinnosti V rámci této kapitoly Zhotovitel závazn definuje požadované souinnosti ze strany SSZ pro vývoj a nasazení nového aplikaního vybavení. Zhotovitel definuje potebnou souinnost v následující struktue: Popis souinnosti; Popis role na stranssz; Rozsah oekávané souinnosti (v D). Další popis souinností ípadné další požadavky na souinnost (doplní Zhotovitel) 20

22 5 ZajištníaplikanípodporyAPVZDV,DMS(ATV),ATR Digitalizanílinka Úvod: Poskytování aplikaní podpory zahrnuje následující dílí plnní : evzetí do servisu Poskytování podpory APV ZDV, DMS (ATV), ATR a Digitalizaní linka 5.1 evzetídoservisu V rámci pevzetí aplikaní podpory do servisu se Zhotovitel seznámí s APV ZDV, DMS (ATV), ATR a Digitalizaní linka a proškolí své leny realizaního týmu ped zaátkem poskytování aplikaní podpory APV ZDV, DMS (ATV), ATR a Digitalizaní linka takovým zpsobem, aby byl schopen zajistit poskytování veškerých služeb dle pedmtu plnní této Smlouvy. Zhotovitel v rámci této oblasti pedloží podrobný návrh, jak bude pevzetí do servisu realizovat. Zárove v této ásti vydefinuje požadavky na souinnost Objednavatele. Objednavatel není povinen i pevzetí do servisu zajistit souinnost 3. stran nap. dodavatel Objednavatele Rozsahevzetídoservisu V rámci této kapitoly Zhotovitel závazn popíše: Podrobný návrh pevzetí do servisu; Potebnou souinnost v následující struktue: o Popis souinnosti; o Popis role na stranssz; o Rozsah oekávané souinnosti (v D). Organizaní zajištní. (doplní Zhotovitel) 5.2 PoskytováníaplikanípodporyAPVZDV,DMS,(ATV),ATR Digitalizanílinka Podpora aplikace bude zajištna na odstraování chyb na základ SLA definovaných níže. 21

23 Zhotovitel eší všechny nalezené chyby v aplikaci pod domluvenými SLA (všechny asy jsou poítány na pracovní dny a as v eské republice): o Zodpovídá za analýzu, opravu a test chyb. o Zodpovídá za plánování oprav do balí v návaznosti na SLA finální termín nasazení potvrzuje SSZ. o edává opravenou chybu s prvodkou popisující kdo, jak provedl test, jak byla chyba opravena a co bylo její pinou. o Je povinen opravovat pinu i následek chyby (opravy pouze následk a neopravování in budou negativním kritériem hodnocení). o Je povinen dodat testovací data pro pípadný retest chyby Objednatelem. o Je povinen dodržovat standardy vývoje definované Objednatelem. Zodpovídá za úplnost a korektnost opravných balíku dodávaných na provoz. Zodpovídá za vasné informování SSZ o možných dopadech opravy na souinné aplikace. Zodpovídá za aktualizaci automatizovaných test (pokud existují). Musí poskytnout plnou souinnost pro nasazení oprav na produkci a zvýšenou podporu po nasazení pro provoz IT. Zodpovídá za aktualizaci veškeré dokumentace ovlivnné opravou. Zajišuje podporu uživatel. eší management defekt v nástroji na sledování chyb a eskalaci problém. ipravuje podklady na status meetingy. Reportuje plnní SLA na msíní úrovni (pipravuje podklady pro vyhodnocení kontrolních parametr). astní se a vede aktivity v procesech problém managementu. Poskytuje souinnost pro opravy v ostatních aplikacích. Školení uživatel: o íprava školících materiál pro školení uživatel. o íprava dat a prostedí pro školení uživatel. o Realizace školení uživatel. o Vyhodnocení zptné vazby. edání aplikaní podpory v pípad ukonení Smlouvy se ídí ustanovením Smlouvy NávrhSLA Zhotovitel se zavazuje dodržovat definovanou úrove služeb pro ešení chyb (incident): Oblast Kategorie A Kategorie B Kategorie C ekávaná doba Reakce Odstranní Reakce Odstranní Reakce Odstranní 1 hod 12 hod 6 hod 50 hod 20 hod 100 hod Reakní dobou v tomto pípad Objednatel rozumí pevzetí chyby, provedení úvodní analýzy problému a pedání informaci o dvodu chyby a pedpokládaném ešení. 22

24 Pro úely dodržování výše uvedených parametr reakní doby a doby odstranní závady (dobou pro odstranní závady se rozumí doba, která zapone bžet asem pedání incidentu Zhotoviteli a bude ukonena v ase pedání vyešeného incidentu zpt Objednateli) je dále uvedeno rozdlení závad do kategorií: za závady kategorie A budou považovány kritické chyby, kterými se rozumí zejména havárie, poruchy, chyby, vady vedoucí k perušení provozu nebo jeho kritickému omezení a znemožující používání a využívání APV nebo databází nebo systémového vybavení nebo hardware k úelu, k nmuž je ureno, za závady kategorie B budou považovány hlavní chyby, kterými se rozumí poruchy, chyby, vady, které zpsobují provozní problémy, ale neznemožují používání a využívání APV nebo databází nebo systémového vybavení nebo hardware k úelu, k nmuž je ureno, a lze je doasnešit organizaními nebo technickými opateními, za závady kategorie C budou považovány vedlejší chyby, kterými se rozumí mén závažné poruchy, chyby, vady nebo diference APV, které nemají vliv na používání a využívání APV nebo databází nebo systémového vybavení nebo hardware k úelu, k nmuž je ureno. Lhty se ve vcech reakních dob pro ešení incident poítají v rámci pracovní doby Objednatele, tedy bh lhty se pozastavuje na konci každého pracovního dne a obnovuje na poátku pracovní doby následujícího pracovního dne. Pracovní doba se pro tento pípad definuje od 7:00 do 17:00. Pozastavení poítání lhty s koncem pracovní doby neplatí pro ešení chyby kategorie A. Není-li vzájemn dohodnuto jinak, lhta pro mení doby reakce a doby odstranní incidentu zapone žet asem pedání incidentu Zhotoviteli a bude ukonena v ase pedání vyešeného incidentu zpt Objednateli. Celková doba odstranní je pak souet všech asových dob, po které byl incident v ešení na stran Zhotovitele. Z celkové doby odstranní incidentu jsou vyloueny asové doby, kdy Zhotovitel prokazateln nemohl pokraovat v ešení incidentu z dvod, které nebyly jím zpsobené (nap. Zhotovitel eká na doplnní relevantních informací k incidentu od Objednatele apod.). Pro výpoet lht jsou urující asové záznamy v systému Helpdesk Objednatele k danému incidentu. edávání incident bude probíhat dle požadavku Objednatele prostednictvím helpdesku Objednatele, emž Zhotovitel je povinen incidenty z helpdesku Objednatele automaticky pijímat Dodatenémetriky Hodnocení aplikaní podpory musí dále zohledovat následující kritéria: Vyhodnocení procenta chyb, u kterých nebyla opravena pina. Vyhodnocení opravy chyb, kde nedošlo k úspšné oprav, nebo byla zavleena nová chyba. Vyhodnocení potu nekorektních balí chybn dodané balíky, nebo balíky které vyžadovali nestandardní zásah provozu IT (nešli nasadit podle dodaného postupu). Vyhodnocení dodržování vývojových standard Algoritmusvyhodnoceníaplikanípodpory Úvod: Tato kapitola popisuje zpsob, jakým bude vyhodnocována definovaná úrove služeb v oblasti aplikaní podpory. 23

25 Vyhodnocování bude probíhat na msíní bázi. V pípad neplnní vyhodnocovaných kritérií, mžou být uplatnny definované sankce na platbu za aplikaní podporu. V pípad hrubého neplnní SLA je možné odstoupení od Rámcové smlouvy nebo Dílí smlouvy. Hrubým neplnním SLA je napíklad neplnní definované úrove služeb v oblasti aplikaní podpory u kategorie závady A, a to v rozsahu minimáln dvakrát v kalendáním msíci nebo napíklad opakované nedodržování dodatených SLA metrik. SLA reakní doby pro ešení chyb A, B, C je definováno v kapitole Pro úely hodnocení se vyhodnocuje splnní reakní doby a doby vyešení chyby pro každý jednotlivý pípad a penalizace za nesplnní asových limit probíhá dle ustanovení Rámcové smlouvy. Vyhodnocení dodatených metrik: V pípad, že procento chyb, u nichž nebude opravena pina, pesáhne 10%, bude v meném období nastaven parametr SLApina = -5 %. V pípad, že procento chyb, u nichž po nasazení do produkce bude konstatováno, že nedošlo k oprav, nebo že došlo k zavleení další chyby, pesáhne 20%, bude v meném období nastaven parametr SLAzavle = -5 %. V pípad, že poet nekorektních produkních balí pesáhne poet jednoho nekorektního nasazení za msíc, bude nastaven parametr SLAbalíek = -5 %. V pípad, že ze strany Objednatele bude v rámci hodnocení aplikaní podpory eskalováno nedodržování vývojových standard a tato situace se nezmní ani následující msíc, bude nastaven parametr SLAstandardy = -5 %. Celkový parametr vyhodnocení aplikaní podpory definujeme jako: = 100% Spoítané bude využito ke snížení msíní ceny za aplikaní podporu podle pravidel popsaných v Píloze. 2 Cena plnní Rozsahslužebaplikanípodpory V rámci této kapitoly Zhotovitel závazn popíše: Metodiku ízení aplikaní podpory; Definici pedpokládaných proces aplikaní podpory; Popis nabízených služeb v rámci aplikaní podpory; Popis požadované souinnosti v rámci aplikaní podpory; Návrh pedání aplikaní podpory a rozvoje pípadnému novému dodavateli; Organizaní zajištní. (doplní Zhotovitel) 24