íloha. 1 k Rámcové smlouv Specifikace pedmtu plnní a technické požadavky
Obsah 1 Úvod... 2 2 Dodávka nového aplikaního programového vybavení Aplikace pro rozhodování ve správním ízení... 3 2.1 Popis stávajícího stavu a popis cílového ešení... 3 2.1.1 Použité technologie... 3 2.1.2 Standardy IKT SSZ... 5 2.1.3 Výkonnostní požadavky... 7 2.1.4 Požadavky na infrastrukturu... 7 2.2 Popis dodávaného ešení nového aplikaního programovéhovybavení... 7 2.2.1 Popis návrhu ešení... 8 2.2.2 Projektové ízení... 9 2.2.3 Analytická ást projektu... 10 2.2.4 Vývoj, implementace a testování... 11 2.2.5 Migrace dat... 12 2.2.6 Školení... 13 2.2.7 Nasazení do produkce... 14 2.2.8 Požadované souinnosti... 15 3 Zajištní aplikaní podpory a rozvoje aplikace... 16 3.1 Požadavky na aplikaní podporu... 16 3.1.1 Návrh SLA... 17 3.1.2 Algoritmus vyhodnocení aplikaní podpory... 18 3.1.3 Rozsah služeb aplikaní podpory... 19 3.2 Požadavky na rozvoj aplikace... 20 3.2.1 edpokládaný rozsah rozvoje... 20 3.2.2 Rozsah služeb v oblasti rozvoje aplikace... 21 1
1 Úvod 1.1 Smyslem a úelem Pílohy. 1 Rámcové smlouvy o vývoji a údržb nového aplikaního programového vybavení Aplikace pro rozhodování (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 edpis (dále jen ZVZ ), ustanovením 1746 odst. 2 zákona. 89/2012 Sb., obanský zákoník, ve znní pozdjších pedpis (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 edmt 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.). 2
2 Dodávka nového aplikaního programového vybavení Aplikace pro rozhodování ve správním ízení 2.1 Popis stávajícího stavu a popis cílového ešení V souasnosti není rozhodování ve správním ízení ve vtšin agend podporováno žádnou aplikací. Pouze ástenou podporu agendy ízení o námitkách ve vcech dchodového pojištní zajišuje Aplikace Rozhodování o námitkách (dále jen RON ). Dalšími podprnými aplikacemi jsou Aplikace Soudní (dále jen APV Soudní ), aplikace pro agendu posudkové služby (dále jen APV PSL a historická aplikace urená pouze pro náhled dále jen APV EPOZ ), modul LPS aplikace NEM a Aplikace pro evidenci správního ízení v agend osob zdravotn znevýhodnných (dále jen APV Evidence SR OZZ ): 2.1.1 Použité technologie APV RON Pro vývoj APV RON byly využity následující platformy: COBOL SQL SESAM Windows server 2008 K výše uvedenému centrálnímu aplikanímu programovému vybavení existuje dokumentace, Zhotovitel bude mít k dispozici analytickou dokumentaci a datový model. APV RON je vytvoena a spravována v rámci SSZ. Tlustý klient je vytvoen v prostedí MS.NET VB (.NET framework 3.5). Tenký klient aplikace pracuje v prostedí Internet Explorer, je naprogramován v MS.NET (.NET framework 4.0). Pro persistentní uložení dat je využíván databázový stroj SQL SESAM verze 70 (mainframe). Business logika je na mainframe v jazyce COBOL. APV Soudní Pro vývoj APV Soudní byly využity následující platformy: COBOL program je tvoen 1342 ádky SQL SESAM Transakní monitoring UTM Operaní systém BS 2000 3
APV Soudní je vytvoena a spravována v rámci SSZ. K výše uvedenému aplikanímu programovému vybavení neexistuje dokumentace. APV Evidence SR OZZ Access (MS SQL Server) Windows 7-32 bit Windows server Vývoj a správa APV Evidence SR OZZ je v rámci SSZ. K výše uvedenému aplikanímu programovému vybavení neexistuje dokumentace. APV NEM modul LPS Pro vývoj APV NEM modul LPS byly využity následující platformy: Programovací jazyk Java 1.5 Windows server 2003 Internet Explorer 8 Oracle 10g APV NEM modul LPS je provozován v rámci SSZ. K výše uvedenému aplikanímu programovému vybavení existuje dokumentace. APV PSL Pro vývoj APV PSL byly využity následující platformy: Datové uložištssz na platform Oracle 10g. Windows server 2003 Standart Visual Studio 2003 Rozšiující hardware pro práci smluvních léka, data na flash jsou šifrována AES256 algoritmem implementovaným aplikací TrueCrypt Moduly aplikace byly vyvíjeny na platform VB6 a.net APV PSL je provozováno v rámci SSZ. SSZ není vlastníkem zdrojových kód k výše uvedenému aplikanímu programovému vybavení. K výše uvedenému aplikanímu programovému vybavení existuje dokumentace. APV EPOZ Pro vývoj APV EPOZ byly využity následující platformy: Operaní systém Solaris (operaní systém unixového typu) Databáze Informix Informix SQL jazyk pístupu k databázi 4
APV EPOZ je provozováno v rámci SSZ a OSSZ decentralizovan. K výše uvedenému aplikanímu programovému vybavení neexistuje dokumentace. Popis požadavk na nové aplikaní programové vybavení jsou uvedeny v následujícím dokumentu: Název souboru 6_Vecny_zamer_Aplikace pro rozhodování.rar (jsou souástí zadávací dokumentace) Obsah dokumentu Popis požadovaných funkcionalit pro zajištní agendy Aplikace pro rozhodování Nové aplikaní vybavení musí umožovat parametrizaci. 2.1.2 Standardy IKT SSZ Nové aplikaní programové vybavení musí splovat požadavek na maximální parametrizovatelnost ešení. Veškeré nastavení systému musí být uloženo v parametrizacích tak, aby bylo možné mnit nastavení výpo bez zásahu do kódu aplikace. 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 eské správy sociálního zabezpeení (dále jen SSZ ) platnými v dob realizace. 5
Seznam aktuáln platných standard je uveden v následující tabulce: íslo 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 pipojení 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.20 Standard systémové konfigurace pracovní stanice 2.20 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 - vetn formulá edávání APV a release 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_17 12. 13. BizTalkDevelopmentStandard.v1.00.doc AAA_Pozadavky_na_aplikace_7.01.pdf Standardy pro tvorbu aplikací pro Microsoft BizTalk server 1.00 Požadavky na nové aplikace pi integraci do AAA portálu 8.00 14. Standard_pro_tvorbu_skriptu_db_Oracle _0.2.doc Standard pro tvorbu, pedávání a spouštní skript v databázích Oracle 0.2 15. CSSZ_DMS_WS_API_DMA_v3_3_131031. doc API ROZHRANÍ SYSTÉMU DMA: WS_API_DMA - Standard rozhraní pro ukládání dokument do DMS 3.3 16. CSSZ_DU_STD_V011.1.doc Standard provozu databáze Oracle 1.10 17. std_srv_0.23.doc Standard systémové konfigurace aplikaních server 0.23 18. std_pki.pdf Standard pro PKI 1.0 6
(jsou souástí zadávací dokumentace) 2.1.3 Výkonnostní požadavky Vyvíjená aplikace musí splovat 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 Uživatelská odezva z front-endu aplikace (odezva pro jednu konkrétní aktivitu vyhledání, založení, ) Odezva online rozhraní (doba zpracování) Požadovaná doba odezvy Požadované procento splnní 1 sekunda 95% 5 sekund 99% 0,5 sekund 95% 3 sekund 99% Vyvíjená aplikace musí pro všechna rozhraní 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. 2.1.4 Požadavky na infrastrukturu Navrhovaná infrastruktura musí respektovat standardy Objednatele a mla by efektivn využívat stávající infrastrukturu. Zárove zadavatel požaduje napojení na helpdesk SSZ, a to k úelu hlášení incidentu. 2.2 Popis dodávaného ešení nového aplikaního programového vybavení Úvod: V rámci této kapitoly jsou popsány jednotlivé oblasti poptávané Objednatelem. Nabídka Zhotovitele jako uchazee musí respektovat navrhovanou strukturu požadovaných oblastí plnní. 7
2.2.1 Popis návrhu ešení Nová aplikace musí být implementována v rámci aktuálních uznávaných standard, pedpokládáme využití ívrstvé architektury. Uživatelé k aplikaci budou pistupovat pes webového klienta. Aplikace musí být schopná nahradit aplikace RON, OZZ, PSL, EPOZ, modul LPS aplikace NEM a Soudní uvedené v odst. 2.1 a podporovat požadovanou funkcionalitu popsanou v píloze uvedené v tabulce v odst. 2.1.1. Zárove musí splovat všechny požadavky popsané v odst 2.1. Zhotovitel také popíše: Požadavky na hardware pro zajištní produkních i neprodukních prostedí Požadavky na software pro zajištní produkních i neprodukních prostedí které bude požadovat Zhotovitel zajistit od Objednatele. 8
2.2.2 Projektové ízení Zhotovitel zajistí ešení všech disciplín projektového ízení po celou dobu trvání Rámcové smlouvy, vetn ízení potencionálních subdodávek dalších aplikací SSZ. 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; Organizaní strukturu projektu; Návrh projektového plánu. (doplní Zhotovitel) 9
2.2.3 Analytická ást projektu V rámci analytické ásti projektu Zhotovitel zajistí: Katalog požadavk; Vytvoení kompletní funkní dokumentace; Popis testovací strategie; ípravu a popis testovacích scéná pro jednotlivé typy test; Popis cílové aplikaní a datové architektury v. datových model (logických a fyzických) 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; Popis cílové aplikaní a datové architektury; Definici požadavk na infrastrukturu, odpovídající standardm IKT SSZ. (doplní Zhotovitel) 10
2.2.4 Vývoj, implementace a testování Úvod: V rámci této ásti projektu Objednatel pedpokládá implementaci jednotlivých komponent a celkové testy celého ešení. Zhotovitel se zavazuje dodat: Okomentovaný programový kód; Instalaní skripty; Konfigurace veškerých ástí dodávky; Kompletní technickou/programátorskou dokumentaci; Kompletní uživatelskou dokumentaci (uživatelská píruka atd.) Poskytovat pípadné konzultace návrhu ešení na úrovni business, architektury, analýzy, designu, implementace, integrace a testování. 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í). Objednatel plnní dle tohoto odstavce (2.2.4 Vývoj, implementace a testování) 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) 11
2.2.5 Migrace dat Úvod: Migrace dat je nedílnou souástí plnní. Data budou migrována ze souasného aplikaního vybavení RON, OZZ, PSL, EPOZ, modulu LPS aplikace NEM a APV Soudní. Objednatel požaduje, aby bylo migrováno 100% dat ze souasných systém. Zhotovitel musí zajistit konsolidaci dat ze všech lokálních aplikací ze všech poboek SSZ, stejn tak z aktuálních centrálních aplikací. Následn musí zabezpeit konsolidaci a vyištní tchto dat a migraci do cílové aplikace. Dále Zhotovitel zajistí metodiku kontrol datových typ a jednotlivých typ test pi migraci. Objednatel plnní dle tohoto odstavce (2.2.5 Migrace dat) akceptuje na základ akceptaního ízení.. Zhotovitel jako souást své nabídky pedloží podrobný závazný návrh, jak bude realizovat migraci dat, etn jejich konsolidace. Zhotovitel minimáln popíše: Podrobný návrh migraní strategie; Popis migraního nástroje (pokud již má tento nástroj Zhotovitel k dispozici); íklad pedpokládaných dokumentací a akceptaních report. (doplní Zhotovitel) 12
2.2.6 Školení Zhotovitel musí zabezpeit vyškolení 900 pracovník, kteí budou pracovat s nov dodávanou aplikací. Stejn tak musí zajistit zaškolení 10 pracovník IT SSZ, kteí budou následn pro aplikaci intern zajišovat podporu uživatel. Aplikaci ASR bude používat velké množství uživatel na všech OSSZ, pracovištích SSZ a na ústedí SSZ. Pedpokládaný poet aktivních uživatel je cca 5000, nkteré moduly aplikace však budou využívat pouze desítky pracovník. Objednatel plnní dle tohoto odstavce (2.2.6 Š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í; íklad školících materiál (školící píruka, pípady, scénáe). (doplní Zhotovitel) 13
2.2.7 Nasazení do produkce Úvod: Poslední fází projektu implementace nového aplikaního programového vybavení bude nasazení nového ešení do produkce. Zhotovitel musí zajistit následující aktivity: Naplánování nasazení do produkce; ípravu provozní dokumentace; uživatelské píruky; Definovat finální konfiguraci pro produkní prostedí; ípadn otestování nasazení do produkce; Koordinace finálního produkního nasazení. Objednatel plnní dle tohoto odstavce (2.2.7 Nasazení 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 nasazení do produkce; Popis dokumentace pro nasazení do produkce; Popis provozní dokumentace. (doplní Zhotovitel) 14
2.2.8 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 programového vybavení. Zhotovitel definuje potebnou souinnost v následující struktue: Popis souinnosti; Popis role na stranssz; Rozsah oekávané souinnosti (v lovkodnech dále jen D ). hem dodávky aplikaního programového vybavení musí Zhotovitel na msíní bázi reportovat využití interních zdroj Objednatele (a vypoítávat již použité a ješt dostupné interní kapacity Objednatele pro dodávku aplikaního programového vybavení). Další popis souinností Požadavky na hardware pro zajištní produkních i neprodukních prostedí Požadavky na software pro zajištní produkních i neprodukních prostedí ípadné další požadavky na souinnost (doplní Zhotovitel) 15
3 Zajištní aplikaní podpory a rozvoje aplikace Podpora aplikace bude zajištna na odstraování chyb na základ SLA definovaných níže. Rozvoj bude sloužit pro implementaci nových funkností do spravované aplikace. Maximální objem pro rozvoj aplikace je popsán v Píloze. 2, Objednatel však negarantuje minimální objem erpaných služeb v rámci této ásti plnní. Aplikaní podpora je poskytována po dobu trvání Rámcové smlouvy poínaje od data zahájení ostrého provozu. 3.1 Požadavky na aplikaní podporu 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. 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. 16
o Realizace školení uživatel. o Vyhodnocení zptné vazby. Zhotovitel se zavazuje v pípad ukonení Smlouvy poskytnout Objednateli nezbytnou souinnost spoívající v pedání potebných informací (napíklad dokumentace, zdrojové kódy a další relevantní data, viz povinnosti Zhotovitele) nezbytných k pesunu služby na Objednatele nebo tetí osobu, a zajistit tím bezproblémový pesun poskytovaných služeb. Zhotovitel je povinen vytvoit harmonogram pesunu, vetn seznamu pedávaných vcí tak, aby byla zcela zachována funknost poskytovaných služeb. Zhotovitel je povinen dodat harmonogram pesunu služeb Objednateli do 90 (devadesáti) dn ode dne zahájení aplikaní podpory. Zhotovitel je povinen aktualizovat harmonogram pesunu nejpozdji do 20 (dvaceti) dn ped ukonením Smlouvy. 3.1.1 Návrh SLA Zhotovitel se zavazuje dodržovat definovanou úrove služeb: 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í. 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 h lhty se pozastavuje na konci každého pracovního dne a obnovuje na poátku pracovní doby 17
následujícího pracovního dne. Pracovní doba se pro tento pípad definuje od 7:00 do 17:00 hodin. 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é prokazateln nebyly jim 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. 3.1.1.1 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žadovaly nestandardní zásah provozu IT (nešly nasadit podle dodaného postupu). Vyhodnocení dodržování vývojových standard. 3.1.2 Algoritmus vyhodnocení aplikaní podpory Úvod: Tato kapitola popisuje zpsob, jakým bude vyhodnocována definovaná úrove služeb v oblasti aplikaní podpory. 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é úrovn 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. 18
SLA reakní doby pro ešení chyb A, B, C je definováno v odst. 3.1.1. Pro úely hodnocení se vyhodnocuje splnní reakních dob 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í. 3.1.3 Rozsah služeb aplikaní 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) 19
3.2 Požadavky na rozvoj aplikace 3.2.1 edpokládaný rozsah rozvoje Úvod: V rámci rozvoje aplikace Objednatel pedpokládá implementaci rozvojových požadavk. 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ího požadavku do 10 pracovních dní od data pedání požadavku Objednatelem, pemž ocenní bude provedeno dle Rámcové smlouvy, pílohy. 2. o Zhotovitel se dále zavazuje, že je schopen dodat kapacity potebné pro implementaci rozvojového požadavku tak, aby mohl zaít 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 testu (pokud existují). íprava reportu o provedení test. Aktualizace provozní dokumentace, uživatelské píruky. íprava produkního balíku a postupu nasazení. Podpora nasazení do produkce. Zvýšená podpora bezprostedn po nasazení do produkce. 20
3.2.2 Rozsah služeb v oblasti rozvoje aplikace V rámci této kapitoly Zhotovitel závazn popíše: Metodiku rozvoje aplikace; Popis nabízených služeb v rámci rozvoje aplikace; Popis požadované souinnosti rozvoje aplikace; Organizaní zajištní. (doplní Zhotovitel) 21