o úpravě a poskytování podpory Informačního Systému ArchIvu ČNB
Evidenční číslo smlouvy ČNB: 00-000-00
Smlouva
o úpravě a poskytování podpory Informačního Systému ArchIvu ČNB
uzavřená podle § 1746 odst. 2 zákona č. 89/2012 Sb., občanský zákoník, ve znění pozdějších předpisů (dále jen „o.z.“), mezi:
zastoupenou: Ing. Xxxxxxxxxx Xxxxxxxxx, ředitelem sekce informatiky
a
Ing. Xxxxxxx Xxxxxxxx, ředitelem sekce správní
IČO: 48136450
DIČ: CZ48136450
(dále jen „objednatel“)
a
.................................. (doplní dodavatel)
č. účtu: ......................./kód banky ……..
(plátce DPH uvede svůj účet, který zveřejněn podle § 98 zákona o DPH)
(dále jen „poskytovatel“)
Preambule
Následující smlouva je rozdělena na část A, která obsahuje smluvní ujednání o úpravě Informačního Systému ArchIvu a souvisejících službách, a na část B, která obsahuje smluvní ujednání o poskytování podpory Informačního Systému ArchIvu, včetně podpory budoucího rozvoje, a na společná ustanovení pro obě části.
ČÁST A
Specifikace úprav Informačního Systému ArchIvu
Poskytovatel se zavazuje v rámci provádění díla podle této smlouvy:
provést analýzu stávajícího IS ISAI;
modifikovat dva ze stávajících modulů Informačního Systému ArchIvu (dále též jako „ISAI“, „IS ISAI“);
modifikovat uživatelské rozhraní IS ISAI;
modifikovat datovou strukturu IS ISAI;
provést migraci části dat do upravené datové struktury IS ISAI;
modifikovat stávající vazby mezi jednotlivými moduly IS ISAI;
zajistit všechny softwarové komponenty a licence třetích stran potřebné k provozování IS ISAI po provedení modifikací dle písm. a) až e) tohoto odstavce (dále též jen „SW řešení“) v souladu s dalšími ustanoveními této smlouvy;
a případně též naprogramovat nutné nové součásti IS ISAI;
a to v souladu s Katalogem uživatelských požadavků, který tvoří přílohu č. 1 této smlouvy, a návrhem řešení, který tvoří přílohu č. 7 této smlouvy, s cílem uvést IS ISAI do souladu se stávající legislativou vztahující se k oblasti archivnictví a spisové služby (zejména s vyhláškou č. 645/2004 Sb., ve znění pozdějších předpisů).
Poskytovatel je povinen při provádění díla dle této smlouvy zejména:
realizovat SW řešení jako webovou aplikaci přístupnou minimálně z prostředí Microsoft Internet Explorer 11 a vyššího dle přílohy č. 1 této smlouvy;
nenarušit kompatibilitu se stávajícími moduly IS ISAI, popřípadě narušení kompatibility odstranit v rámci plnění podle části A této smlouvy;
nenarušit celkovou architekturu IS ISAI, jak je zobrazena v části 5 „Architektura IS ISAI“ přílohy č. 2 této smlouvy
nenarušit kompatibilitu IS ISAI se standardním systémovým prostředím objednatele, které je popsáno v části 1 „Systémové prostředí ČNB“ přílohy č. 2 této smlouvy, přičemž:
SW řešení musí dodržet koncept konsolidace datové základny v DB Oracle;
nebo poskytovatel musí dodat skripty (sadu příkazů), které uvedou SW řešení (jeho data) do konzistentního stavu vhodného k zálohování a zajistí ČNB zálohy určených souborů a dále dodá skripty (sadu příkazů), které na konci zálohy opět vrátí SW řešení do provozního stavu a stejně tak umožní jeho obnovu z uvedených záloh v případě havárie.
nenarušit SW řešením parametry bezpečnostního profilu objednatele (zachovat je na stávající úrovni) popsaného v potřebném rozsahu části 2 „Bezpečnost IT“ přílohy č. 2 této smlouvy, přičemž:
k funkcím pro správu, změnu, diagnostiku apod. SW řešení bude přístup pouze ze sítě ČNB (příp. prostřednictvím běžného vzdáleného přístupu zaměstnance ČNB do této sítě);
nenarušit SW řešením stávající vazby IS ISAI na ostatní informační systémy a softwarové vybavení používané v rámci ČNB, které jsou základním způsobem popsány v části 3 „Vazby na interní IS“ přílohy č. 2 této smlouvy;
připravit objednatelem určená data k migraci;
provést migraci objednatelem určených dat, vytvořených v původním IS ISAI, do datové struktury SW řešení v souladu s popisem tohoto procesu v části 4 „Migrace dat“ přílohy č. 2 této smlouvy, uživatelskými požadavky TRAxxx přílohy č. 1 této smlouvy a jím vypracovanou realizační studií dle odst. 5 písm. a) tohoto článku;
zajistit, aby SW řešení ke svému provozu užívalo pouze hardwarové komponenty popsané v části 1 „Systémové prostředí ČNB“ přílohy č. 2 této smlouvy;
instalovat SW řešení jako celek do testovacího prostředí objednatele a nastavit jej pro provedení akceptačních testů;
instalovat a zprovoznit SW řešení jako celek v systémovém (provozním) prostředí objednatele v souladu s touto smlouvou a poskytovatelem vypracovanou realizační studií, ohledně které bylo uzavřeno úspěšné akceptační řízení.
Součástí díla je rovněž:
Vypracování a poskytnutí realizační studie v souladu se šablonou realizační studie, která tvoří přílohu č. 5 této smlouvy, zahrnující návrh rozšíření IS ISAI na základě detailní analýzy uživatelských požadavků podle přílohy č. 1 této smlouvy a datového modelu včetně namapování současných dat na nová datová pole a návrhu jejich migrace (transformace). Realizační studie se předává v jednom vyhotovení v elektronické podobě a v českém jazyce.
Vypracování a poskytnutí testovacích scénářů, podle kterých budou prováděny akceptační testy SW řešení. Testovací scénáře musejí být navrženy tak, aby ověřili naplnění všech uživatelských požadavků podle přílohy č. 1 této smlouvy a všech povinností poskytovatele podle odst. 2 písm. a) až j) toho článku. Každý testovací scénář musí mít vyplněnou šablonu testovacího scénáře, která je přílohou č. 6 této smlouvy. Testovací scénáře nejsou při akceptačních testech SW řešení pro objednatele závazné. Testovací scénáře se předávají v jednom vyhotovení v elektronické podobě a v českém jazyce.
Zaškolení 2 administrátorů pro administraci a konfiguraci SW řešení a 4 koncových uživatelů v používání SW řešení před zahájením akceptačního řízení.
Podpora při řešení problematických situací, vzniklých při akceptačních testech SW řešení, zajištěná primárně telefonicky, e-mailem a v případě potřeby též v místě plnění podle části A této smlouvy.
Podpora při ověřovacím provozu SW řešení v provozním prostředí objednatele.
Vypracování, poskytnutí a předání technické, administrátorské a uživatelské dokumentace SW řešení, každá v jednom vyhotovení v elektronické podobě a v českém jazyce.
Předání čitelného a kompletního zdrojového kódu SW řešení a dalších podkladů potřebných ke správě, údržbě a úpravám SW řešení vč. dokumentace (např. datový model, programové knihovny), to vše v elektronické podobě na CD/DVD.
Poskytnutí licence k SW řešení v rozsahu dle této smlouvy.
Objednatel se zavazuje za poskytnuté plnění podle části A této smlouvy uhradit cenu dle čl. VI odst. 1.
Lhůty, místo a způsob plnění k úpravám IS ISAI
Nedohodnou‑li se smluvní strany jinak, jsou místem plnění podle části A této smlouvy, a to včetně předání díla, prostory objednatele sídla objednatele na adrese Česká národní banka, Xx Xxxxxxx 00, 000 00 Xxxxx 0.
Plnění podle části A této smlouvy bude prováděno v následujících lhůtách:
Realizační studii poskytne poskytovatel objednateli k provedení akceptačního řízení do 2 měsíců od podpisu této smlouvy.
Instalaci SW řešení do testovacího prostředí objednatele a jeho nastavení pro provedení akceptačních testů provede poskytovatel do 3 měsíců ode dne uzavření úspěšného akceptačního řízení ohledně realizační studie. Současně s uvedeným poskytne poskytovatel objednateli ty softwarové komponenty a licence třetích stran, které jsou nezbytné k provedení akceptačního řízení ohledně SW řešení.
Testovací scénáře, podle kterých budou prováděny akceptační testy SW řešení, poskytne poskytovatel objednateli do 3 měsíců ode dne uzavření úspěšného akceptačního řízení ohledně realizační studie.
Technickou, administrátorskou a uživatelskou dokumentaci SW řešení poskytne poskytovatel objednateli do 5 dnů ode dne instalace SW řešení do testovacího prostředí objednatele a jeho nastavení pro provedení akceptačních testů. Ve stejné lhůtě požádá objednatele o zahájení akceptačního řízení SW řešení.
Zaškolení 2 administrátorů pro administraci a konfiguraci SW řešení a 4 koncových uživatelů v používání SW řešení bude poskytovatelem provedeno do 5 dnů ode dne instalace SW řešení do testovacího prostředí objednatele a jeho nastavení pro provedení akceptačních testů.
Podporu podle čl. I odst. 3 písm. d) poskytuje poskytovatel objednateli po celou dobu akceptačního řízení.
Instalaci a zprovoznění SW řešení jako celku v provozním prostředí objednatele, provede poskytovatel do 7 dnů ode dne uzavření úspěšného akceptačního řízení ohledně SW řešení. Současně s uvedeným poskytne poskytovatel veškeré plnění dle čl. I odst. 1 písm. g) této smlouvy (softwarové komponenty a licence třetích stran).
Podporu podle čl. I odst. 3 písm. e) poskytuje poskytovatel objednateli po celou dobu ověřovacího provozu.
Dílo jako celek předá poskytovatel objednateli v den ukončení ověřovacího provozu podle čl. IV odst. 3 této smlouvy. Předání díla jako celku zahrnuje:
instalaci a zprovoznění SW řešení jako celku v provozním prostředí objednatele, je-li v nich třeba učinit změny oproti instalaci a zprovoznění provedenému podle písm. g) tohoto odstavce;
předáním bezvadné technické, administrátorské a uživatelské dokumentace SW řešení;
předání čitelného a kompletního zdrojového kódu bezvadného SW řešení a dalších podkladů potřebných ke správě, údržbě a úpravám SW řešení vč. dokumentace (např. datový model, programové knihovny), to vše v elektronické podobě na CD/DVD.
Předání díla proběhne podpisem předávacího protokolu pověřenými osobami smluvních stran.
Akceptační řízení je zahajováno a prováděno dle přílohy č. 3 této smlouvy a podléhají mu následující části díla poskytovatele:
realizační studie;
SW řešení; včetně technické, administrátorské a uživatelské dokumentace SW řešení.
Je-li akceptační řízení neúspěšné, je objednatel oprávněn jednostranně rozhodnout o:
opakování akceptačního řízení, nejvýše však třikrát pro každou část díla;
odstoupení od smlouvy; pro formu odstoupení platí ustanovení čl. XVII odst. 7 této smlouvy.
Ověřovací provoz je zahájen dnem instalace a zprovoznění SW řešení jako celku v provozním prostředí objednatele podle čl. II odst. 2 písm. g) této smlouvy a týká se SW řešení a technické, administrátorské a uživatelské dokumentace SW řešení.
Zahájením ověřovacího provozu se dílo ani žádná jeho část nepovažují za předané ani převzaté.
Ověřovací provoz probíhá 1 měsíc ode dne jeho zahájení. Ověřovací provoz je ukončen uplynutím stanovené doby.
V rámci ověřovacího provozu poskytovatel:
odstraňuje vady SW řešení a technické, administrátorské a uživatelské dokumentace SW řešení zjištěné během úspěšného akceptačního řízení, a to v termínech/lhůtách uvedených v protokolu o výsledku akceptačního řízení;
odstraňuje vady SW řešení a technické, administrátorské a uživatelské dokumentace SW řešení zjištěné během ověřovacího provozu.
Vady SW řešení a technické, administrátorské a uživatelské dokumentace SW řešení zjištěné v rámci ověřovacího provozu se kategorizují podle kapitoly 4. přílohy č. 3 této smlouvy.
Objednatel dílo převezme, bude-li bez vad nebo bude-li obsahovat nejvýše 5 vad kategorie B a 10 vad kategorie C. Vady budou odstraněny ve lhůtě stanovené v předávacím protokolu.
Další práva a povinnosti smluvní stran při úpravách IS ISAI
Objednatel do tří dnů ode dne uzavření této smlouvy poskytne poskytovateli zdrojový kód IS ISAI a doprovodnou dokumentaci.
Počínaje instalací a zprovozněním SW řešení jako celku v provozním prostředí objednatele poskytovatel ručí za to, že:
Dodané, instalované a zavedené SW řešení neobsahuje škodlivý software.
Dodané, instalované a zavedené SW řešení je funkční dle předané dokumentace vyjma vad známých z akceptačního řízení.
Dodané, instalované a zavedené SW řešení neporušuje práva duševního vlastnictví třetích stran.
Počínaje dodáním bezvadného díla poskytovatel ručí dále rovněž za to, že:
Dodané, instalované a zavedené SW řešení je schopno rutinního provozu ve standardním systémovém prostředí objednatele (viz část 1 přílohy č. 2) s daty objednatele, a to i za pravidelného nasazování aktualizací (update / upgrade / patch / hotfix) komponent systémového prostředí objednatele.
Dodané, instalované a zavedené SW řešení odpovídá vlastnostem a parametrům deklarovaným v dokumentaci, požadavkům objednatele této smlouvy (zejména dle přílohy č. 1 této smlouvy) a realizační studii.
V případě negativního dopadu SW řešení do stávajících provozovaných systémů ČNB upraví SW řešení takovým způsobem, aby tyto dopady vyloučil.
Ceny úprav IS ISAI a způsob úhrady
(účastník nedoplňuje, bude doplněno dle nabídky vybraného účastníka)
Cena díla dle čl. I této smlouvy činí ..................,- Kč bez DPH, z toho cena za zaškolení pracovníků činí ..................,- Kč bez DPH. K ceně bude připočtena DPH v sazbě platné v den uskutečnění zdanitelného plnění.
Sjednaná cena dle odst. 1 tohoto článku zahrnuje veškeré náklady poskytovatele spojené s plněním podle části A této smlouvy.
Cena plnění dle odst. 1 tohoto článku bude hrazena takto:
zálohovou fakturu k úhradě zálohy ve výši 10 % z ceny dle odst. 1 tohoto článku je oprávněn poskytovatel vystavit nejdříve v den ukončení úspěšného akceptačního řízení ohledně realizační studie.
zálohovou fakturu k úhradě zálohy ve výši 40 % z ceny dle odst. 1 tohoto článku je oprávněn poskytovatel vystavit nejdříve v den instalace SW řešení do testovacího prostředí objednatele a jeho nastavení pro provedení akceptačních testů podle čl. II odst. 2 písm. b) této smlouvy.
daňový doklad (fakturu) k úhradě ceny díla dle odst. 1 tohoto článku, v němž budou zúčtovány poskytnuté zálohy, je oprávněn poskytovatel vystavit nejdříve v den převzetí díla objednatelem podpisem předávacího protokolu.
ČÁST B
Článek VII
Specifikace podpory
Poskytovatel se tímto zavazuje poskytovat objednateli podporu informačního systému archivu ČNB (dále jen „IS ISAI“ nebo „ISAI“) jako k celku, a nikoliv pouze k těm jeho částem, které poskytovatel upravoval podle části A této smlouvy.
Poskytování podpory v sobě zahrnuje:
Podporu běžného provozu ISAI.
Vynucené aktualizace ISAI.
Budoucí rozvoj ISAI.
Řešení havarijních situací.
Podpora běžného provozu zahrnuje:
Podporu při řešení provozních problémů přímo souvisejících s ISAI ve formě konzultací věcnému i technickému správci, sloužících jako návody a rady jak použít ISAI v určité situaci a jak by mělo být nastaveno prostředí ISAI k optimálnímu fungování systému (Helpdesk).
Odstraňování vad ISAI vzniklých jako důsledek implementace vynucených aktualizací dle odstavce 4, implementací upgrade podle odstavce 5 písmen c) a d) nebo programátorských prací podle odstavce 5 písmene e) (dále jen „vada“).
Vynucené aktualizace zahrnují:
Aktualizace ISAI, jejichž potřeba vznikla v souvislosti se změnou právních předpisů.
Aktualizace ISAI a komponent aplikační vrstvy (middleware), zejména jejich upgrade, update, správu logů a instalace bezpečnostních záplat.
Budoucí rozvoj v sobě zahrnuje:
Vypracování písemných analýz a návrhů řešení nových uživatelských požadavků objednatele na úpravy ISAI.
Konzultace nových uživatelských požadavků objednatele na úpravy ISAI.
Upgrade ISAI, jehož potřeba vznikla na základě organizačních a technických změn u objednatele a změn vnitřních předpisů objednatele.
Upgrade ISAI spojený se změnou systémového prostředí objednatele.
Programátorské práce požadované objednatelem v souvislosti s ISAI a nezahrnuté v jiném typu podpory podle tohoto článku.
Řešení havarijních situací. Havarijní situací při provozu ISAI se rozumí stav, kdy se vyskytne vada ISAI jiná, než vada podle odst. 3 písm. b) tohoto článku, a objednatel takový stav za havarijní situaci označí (dále též jen „havarijní situace“). Objednatel je oprávněn označit za havarijní situaci každý výskyt vady ISAI jiné, než vady podle odst. 3 písm. b) tohoto článku.
Rozsah a kvalita poskytovaných služeb budou vyhodnocovány při společných jednáních objednatele a poskytovatele. Tato jednání proběhnou na základě výzvy objednatele.
Článek VIII
Místo a způsob poskytování podpory IS ISAI
Konzultace v rámci podpory běžného provozu a v rámci budoucího rozvoje budou poskytovány telefonicky nebo e-mailem mezi pověřenými osobami smluvních stran.
Zadání objednatele, písemné analýzy a návrhy v rámci budoucího rozvoje budou poskytovány e‑mailem mezi pověřenými osobami smluvních stran, nebude-li to jejich povaha vylučovat, jinak zasláním na adresu sídla poskytovatele Česká národní banka, Na Xxxxxxx 00, 000 00 Xxxxx 0, k rukám dohodnuté pověřené osoby objednatele.
Místem plnění je sídlo objednatele na adrese Česká národní banka, Xx Xxxxxxx 00, 000 00 Xxxxx 0, nedohodnou-li se pověřené osoby v konkrétním případě jinak.
Článek IX
Požadavky na podporu, kategorizace vad v rámci poskytování podpory a lhůty odstranění vad
Podpora běžného provozu bude poskytována v pracovních dnech v době od 8.00 do 16.00 hod., není-li dále stanoveno jinak.
O poskytnutých konzultacích v rámci budoucího rozvoje podle čl. VII odst. 5 písm. b) a řešení havarijních situací podle čl. VII odst. 6 je poskytovatel povinen průběžně vést výkaz práce, ve kterém podrobně specifikuje druh a rozsah jím vykonané práce. Výkaz bude obsahovat konkrétní jména pracovníků poskytovatele, kteří konkrétní úkol řešili a počet odpracovaných hodin. Výkaz práce průběžně schvaluje objednatel.
Vady ISAI budou podle závažnosti členěny do tří kategorií:
závažnost 1:
ISAI je kompletně nefunkční a svou činností ohrožuje chod systému, na kterém je provozován,
objednatel nepovažuje provoz ISAI za bezpečný, činnost ISAI generuje významné bezpečnostní riziko (typicky jde o nálezy kategorie 4-5 softwarového nástroje QualysGuard).
závažnost 2:
některé významné funkce ISAI nelze použít, nutno provést restart ISAI,
objednatel nepovažuje provoz systému za bezpečný, činnost ISAI generuje bezpečnostní riziko (typicky jde o nálezy kategorie 1-3 softwarového nástroje QualysGuard).
závažnost 3:
- ostatní vady.
Ohlášení vad ISAI, havarijní situace ISAI nebo zaslání požadavku na provedení jiné činnosti v rámci podpory poskytovateli musí být provedeno e-mailem na adresu ................. (doplní účastník), na které se poskytovatel zavazuje zajistit příjem ohlášení nepřetržitě. V oznámení vady musí být vada popsána a vymezena její závažnost. V oznámení havarijní situace musí být uvedeno, že jde o havarijní situaci.
Poskytovatel se zavazuje:
ve lhůtě do 24 hodin (v pracovních dnech) u „vad závažnosti 1“;
ve lhůtě do 72 hodin (v pracovních dnech) u „vad závažnosti 2“;
a ve lhůtě do 7 pracovních dnů u ostatních vad;
zahájit odstraňování vady a sdělit to e-mailem pověřené osobě objednatele ve věcech technické správy a odesílateli ohlášení vady spolu s oznámením lhůty na odstranění vady. V odstraňování vady se dále zavazuje poskytovatel pokračovat bez neodůvodněného přerušení až do jejího vyřešení. Poskytovatel se zavazuje vyřešit vadu závažnosti 1 do 5 pracovních dnů a vadu závažnosti 2 do 10 pracovních dnů nebo zajistit jejich workaround (dočasné řešení). V případě dočasného řešení je třeba vady vyřešit do 15 pracovních dnů od instalace dočasného řešení, není-li dohodnuto jinak. Ostatní vadu odstraní poskytovatel do 30 pracovních dnů.
Lhůty dle odst. 5 počínají plynout okamžikem odeslání e-mailového ohlášení objednatelem.
Poskytovatel se zavazuje zahájit řešení a odstraňování havarijní situace na místě ve lhůtě do 24 hodin od okamžiku odeslání e-mailového ohlášení objednatelem. V odstraňování havarijní situace bude poskytovatel pokračovat bez neodůvodněného přerušení až do jejího odstranění, a to i mimo pracovní dobu. Poskytovatel se zavazuje vyřešit havarijní situaci do 72 hodin od okamžiku odeslání e‑mailového ohlášení objednatelem.
Po odstranění vady závažnosti 1 a po odstranění havarijní situace bude poskytovatelem sepsán protokol, který podepíšou pověřené osoby smluvních stran. V ostatních případech potvrdí odstranění vady pověřená osoba objednatele e-mailem.
Plnění podle čl. VII odst. 4 písm. a) předá poskytovatel tak, aby aktualizace mohla být nainstalována nejpozději ke dni účinnosti příslušné právní normy, pokud se smluvní strany nedohodnou jinak. Plnění podle čl. VII odst. 4 písm. b) předá poskytovatel bez zbytečného odkladu poté, co nastala rozhodná okolnost vyvolávající potřebu aktualizace ISAI, a to v termínu stanoveném po dohodě s objednatelem.
Lhůty na plnění podle čl. VII odst. 5 písm. a), c), d) a e) sjednají smluvní strany dohodou pro každý případ samostatně.
Po uplatnění požadavku na konzultace podle čl. VII odst. 4 písm. a) a čl. VII odst. 6 písm. b) poskytovatel ve lhůtě do 24 hod. (v pracovní dny) kontaktuje objednatele a poskytne příslušnou konzultaci přímo nebo navrhne další postup řešení.
Článek X
Ceny podpory IS ISAI a způsob úhrady
(účastník nedoplňuje, bude doplněno dle nabídky vybraného účastníka)
Cena za služby v rámci podpory běžného provozu (dle čl. VII odst. 3) se platí paušálně a činí čtvrtletně .............. Kč bez DPH.
Cena za vynucené aktualizace ISAI (dle čl. VII odst. 4) se platí paušálně a činí čtvrtletně.............. Kč bez DPH.
Sjednává se hodinová sazba pro poskytování podpory dle čl. VII odst. 5 a 6 ve výši .............. Kč bez DPH za hodinu.
Ceny za plnění v rámci budoucího rozvoje (dle čl. VII odst. 5, vyjma konzultací dle písm. b)) budou sjednány vždy dohodou smluvních stran na základě odhadovaného počtu odpracovaných hodin a hodinové sazby podle odstavce 3 tohoto článku.
Ceny za konzultace dle čl. VII odst. 5 písm. b) a za řešení havarijních situací dle čl. VII odst. 6 budou stanoveny jako součin hodinové sazby podle odstavce 3 tohoto článku a počtu skutečně odpracovaných hodin.
Daňové doklady na ceny plnění podle odstavců 1 a 2 tohoto článku je poskytovatel oprávněn vystavit nejdříve poslední den uplynulého kalendářního čtvrtletí. Pokud smlouva vznikne nebo zanikne v průběhu kalendářního čtvrtletí, je poskytovatel oprávněn účtovat jen alikvotní část paušálních cen.
Daňové doklady na ceny plnění podle odst. 4 a 5 tohoto článku je poskytovatel oprávněn vystavit nejdříve v den předání příslušného plnění. Přílohou daňového dokladu na ceny plnění podle odstavce 5 tohoto článku bude objednatelem schválený výkaz práce.
Článek XI
Součinnost a odpovědnost
Objednatel se zavazuje poskytnout poskytovateli všechny informace, všechny podklady a písemnosti, které má k dispozici a které jsou nezbytné pro činnost poskytovatele v rámci podpory ISAI.
Poskytovatel neodpovídá:
za vady systému ISAI, které vznikly na základě chybných údajů sdělených poskytovateli objednatelem,
za vady systému ISAI způsobené vadnou funkcí spolupracujících programů třetích stran nebo závadnou funkcí hardware použitého pro provoz systému,
za vady systému ISAI způsobené nedodržením doporučení k provozu a používání systému poskytnutých poskytovatelem objednateli.
SPOLEČNÁ USTANOVENÍ
Článek XII
Doklady k úhradě a jejich splatnost
Doklady k úhradě budou obsahovat údaje podle § 435 občanského zákoníku, evidenční číslo smlouvy ČNB a bankovní účet, na který má být placeno a který je uveden v záhlaví této smlouvy nebo který byl později aktualizován poskytovatelem (dále jen „určený účet“). Daňový doklad bude nadto obsahovat náležitostí stanovené v zákoně o dani z přidané hodnoty. V případě, že doklad k úhradě bude postrádat některou ze stanovených náležitostí nebo bude obsahovat chybné údaje, je objednatel oprávněn jej vrátit poskytovateli, a to až do lhůty splatnosti. Nová lhůta splatnosti začíná běžet dnem doručení bezvadného dokladu k úhradě.
V případě, že bude v dokladu k úhradě uveden jiný než určený účet, je pověřená osoba poskytovatele povinna na základě výzvy objednatele sdělit na e-mailovou adresu, ze které byla výzva odeslána, zda má být zaplaceno na bankovní účet uvedený v dokladu k úhradě, nebo na určený účet. V tomto případě se doklad k úhradě nevrací s tím, že lhůta splatnosti začíná běžet až dnem doručení sdělení poskytovatele podle předchozí věty.
Doklady k úhradě budou zasílány elektronicky na adresu xxxxxxx@xxx.xx, přičemž každý doklad k úhradě (daňový doklad, faktura) musí být vložen jako příloha e-mailové zprávy ve formátu PDF. Mimo vlastní doklad k úhradě může být přílohou e-mailu jedna až tři přílohy k dokladu k úhradě ve formátech PDF, DOC, DOCX, XLS, XLSX. Nebude-li možné doklad k úhradě zaslat elektronicky, zašle poskytovatel daňový doklad v analogové formě na adresu ČNB:
Česká národní banka
sekce rozpočtu a účetnictví
odbor účetnictví
Na Příkopě 28
115 03 Praha 1
Splatnost dokladů k úhradě je 14 dnů ode dne jejich doručení objednateli. Povinnost zaplatit je splněna odepsáním příslušné částky z účtu objednatele ve prospěch účtu poskytovatele.
Smluvní strany se ve smyslu ustanovení § 1991 občanského zákoníku dohodly, že objednatel je oprávněna započíst jakoukoli svou peněžitou pohledávku za poskytovatelem, ať splatnou či nesplatnou, oproti jakékoli peněžité pohledávce poskytovatele za objednatelem, ať splatné či nesplatné.
Licenční ujednání
Objednatel prohlašuje, že disponuje licencemi k IS ISAI a doprovodné dokumentaci v rozsahu potřebném proto, aby mohl zdrojový kód IS ISAI a doprovodnou dokumentaci předat poskytovateli k jejich úpravám dle části A této smlouvy, a dále aby mohl poskytovateli poskytnout podlicenci za účelem poskytování plnění dle částí A i B této smlouvy. Objednatel uzavřením této smlouvy poskytuje poskytovateli podlicenci k IS ISAI a doprovodné dokumentaci v rozsahu potřebném pro plnění podle částí A i B této smlouvy. Poskytovatel není v žádném případě oprávněn IS ISAI, doprovodnou dokumentaci ani žádnou jejich část jakkoliv užívat mimo poskytování plnění dle této smlouvy. Licence se poskytuje na dobu platnosti a účinnosti této smlouvy.
Poskytovatel poskytuje objednateli na dobu trvání majetkových práv k dílu nevýhradní a místně neomezené licence k užívání programového vybavení vytvořeného podle této smlouvy včetně zdrojových kódů software a zdrojové verze dokumentace vzniklých plněním dle této smlouvy, a to bez omezení množství a typů počítačů objednatele.
Za den poskytnutí příslušné licence se považuje vždy den, kdy je příslušné plnění poskytnuto objednateli k prvnímu užití.
Objednatel není oprávněn SW řešení ani jiná autorská díla vzniklá plněním dle této smlouvy užívat tak, že by poskytoval za úplatu podlicence dalším osobám.
Objednatel je také oprávněn provádět sám nebo prostřednictvím třetí osoby změny, úpravy a doplnění programového vybavení a jeho dokumentace a jeho integraci do jiného systému.
Objednatel se dnem převzetí stává vlastníkem zdrojového kódu SW řešení nebo dalších úprav ISAI vytvořených na základě této smlouvy. Objednatel se dnem jejich poskytnutí podle čl. II odst. 2 písm. b) a g) stává vlastníkem softwarových komponent třetích stran.
Poskytovatel prohlašuje, že je licence dle tohoto článku objednateli oprávněn poskytnout a že na žádném z plnění dle této smlouvy neváznou žádná práva třetích osob, která by poskytnutí bránila. V případě porušení práv třetích osob chráněných autorským zákonem poskytovatel zajistí na své náklady náhradu škod uplatněných třetími osobami a nápravu vzniklého stavu tak, aby objednatel mohl programové vybavení oprávněně užívat.
Objednatel není licence získané podle této smlouvy povinen užít.
Odměna za poskytnutí licencí podle této smlouvy je součástí cen podle čl. VI a čl. X této smlouvy.
Pověřenými osobami smluvních stran jsou:
za objednatele ve věcech podle části A této smlouvy:
...................., tel.: ...................., e-mail: .................... , (bude doplněno před uzavřením smlouvy);
za objednatele ve věcech technické správy podle části B této smlouvy:
...................., tel.: ...................., e-mail: .................... , (bude doplněno před uzavřením smlouvy);
za objednatele ve věcech věcné správy podle části B této smlouvy:
...................., tel.: ...................., e-mail: .................... , (bude doplněno před uzavřením smlouvy);
za poskytovatele ve věcech podle části A této smlouvy:
...................., tel.: ...................., e-mail: .................... (doplní účastník);
za poskytovatele ve věcech technické správy podle části B této smlouvy:
...................., tel.: ...................., e-mail: .................... , (doplní účastník).
V případě změny v osobě nebo údajích uvedených v odst. 1 tohoto článku je změna účinná dnem doručení e-mailu pověřeným osobám druhé smluvní strany.
Článek XV
Mlčenlivost
Poskytovatel se zavazuje zajistit, že jeho pracovníci, jakož i jiné osoby, které se budou podílet na plnění dle této smlouvy, zachovají mlčenlivost o všech skutečnostech, se kterými se po dobu plnění smlouvy seznámí a které nejsou veřejně dostupné. Uvádění dodávky SW dle této smlouvy poskytovatelem jako referenční zakázky po převzetí SW objednatelem tímto není dotčeno, vyjma případu, že by objednatel od této smlouvy odstoupil.
Závazek mlčenlivosti trvá i po skončení plnění podle této smlouvy.
Článek XVI
Smluvní pokuty
V případě prodlení poskytovatele v kterékoliv ze lhůt stanovených v čl. II odst. 2 je objednatel oprávněn požadovat smluvní pokutu ve výši 2.000,- Kč za každý den prodlení.
V případě prodlení poskytovatele ve lhůtě (termínu) sjednané k odstranění vady v protokolu o výsledku akceptačního řízení nebo ve lhůtě poskytnuté k odstranění vady zjištěné v rámci ověřovacího provozu podle čl. IV odst. 6 je objednatel oprávněn požadovat smluvní pokutu ve výši 2.000,- Kč za každý den prodlení.
V případě prodlení poskytovatele v kterékoliv lhůtě pro zahájení odstraňování vady závažnosti 1 podle čl. IX odst. 5 nebo pro zahájení nebo dokončení odstraňování havarijní situace podle čl. IX odst. 7 je objednatel oprávněn požadovat smluvní pokutu ve výši 500,- Kč za každou započatou hodinu prodlení.
V případě bezdůvodného přerušení odstraňování vady závažnosti 1 nebo havárie je objednatel oprávněn požadovat smluvní pokutu ve výši 500,- Kč za každou takovou hodinu přerušení.
V případě prodlení poskytovatele ve lhůtě pro vyřešení vady závažnosti 1 podle čl. IX odst. 5 je objednatel oprávněn požadovat smluvní pokutu ve výši 5.000,- Kč za každý den prodlení.
V případě prodlení poskytovatele ve lhůtě pro zahájení odstraňování vady závažnosti 2 podle čl. IX odst. 5 je objednatel oprávněn požadovat smluvní pokutu ve výši 250,- Kč za každou započatou hodinu prodlení.
V případě bezdůvodného přerušení odstraňování vady závažnosti 2 je objednatel oprávněn požadovat smluvní pokutu ve výši 250,- Kč za každou takovou hodinu přerušení.
V případě prodlení poskytovatele ve lhůtě pro vyřešení vady závažnosti 2 podle čl. IX odst. 5 je objednatel oprávněn požadovat smluvní pokutu ve výši 2.500,- Kč za každý den prodlení.
V případě prodlení poskytovatele ve lhůtě pro zahájení nebo dokončení odstraňování ostatní vady podle čl. IX odst. 5 je objednatel oprávněn požadovat smluvní pokutu ve výši 1000,- Kč za každý pracovní den prodlení.
V případě prodlení poskytovatele v kterékoliv lhůtě pro poskytnutí aktualizace podle čl. IX odst. 9 nebo sjednané lhůtě plnění podle čl. IX odst. 10 je objednatel oprávněn požadovat smluvní pokutu ve výši 2 000,- Kč za každý den prodlení.
V případě prodlení poskytovatele ve lhůtě pro poskytnutí konzultace podle čl. IX odst. 11 je objednatel oprávněn požadovat smluvní pokutu ve výši 500,- Kč za každý pracovní den prodlení.
V případě prodlení objednatele s úhradou zálohové faktury nebo daňového dokladu je poskytovatel oprávněn požadovat úrok z prodlení podle předpisů občanského práva.
Smluvní pokuta a úrok z prodlení jsou splatné do 14 dnů od doručení dokladu k úhradě povinné smluvní straně. Povinnost zaplatit je splněna odepsáním příslušné částky z účtu povinného ve prospěch účtu oprávněného.
Smluvní strany výslovně vylučují aplikaci ustanovení § 2050 o.z. a sjednávají, že ujednáními o smluvní pokutě není dotčeno právo smluvních stran na náhradu škody.
Článek XVII
Výpověď smlouvy a odstoupení od smlouvy
Smluvní strany se v souladu s ustanovením § 1992 o.z. dohodly, že objednatel je oprávněn zrušit tuto smlouvu zaplacením odstupného ve výši 50 000 Kč na účet poskytovatele, a to pakliže ještě neproběhlo úspěšné akceptační řízení ohledně realizační studie. Zrušení smlouvy je účinné zaplacením sjednaného odstupného na bankovní účet poskytovatele číslo účtu: ..................... (doplní dodavatel), kód banky: ..................... (doplní dodavatel). Zaplacením odstupného zanikají všechna práva a povinnosti obou smluvních stran vyplývající ze zrušené smlouvy s výjimkou závazku mlčenlivosti poskytovatele.
Počínaje uplynutím jednoho roku ode dne předání díla podpisem předávacího protokolu pověřenými osobami smluvních stran je každá ze smluvních stran oprávněna smlouvu jednostranně písemně vypovědět bez udání důvodu s výpovědní dobou 6 měsíců, která začne plynout od prvního dne měsíce bezprostředně následujícího po doručení výpovědi druhé smluvní straně.
Smluvní strany se dohodly, že objednatel je oprávněn kdykoliv v průběhu insolvenčního řízení zahájeného na majetek poskytovatele vypovědět tuto smlouvu, a to ve 14 denní výpovědní době, která počíná běžet dnem následujícím po doručení písemné výpovědi poskytovateli.
V případě, že některá ze smluvních stran podstatným způsobem poruší smluvní povinnost vyplývající pro ni z této smlouvy, je druhá smluvní strana oprávněna od smlouvy odstoupit.
Odstoupení od smlouvy je účinné doručením písemného oznámení o odstoupení druhé smluvní straně.
Za podstatné porušení smluvní povinnosti se považuje:
ze strany poskytovatele:
prodlení v kterékoliv ze lhůt stanovených v čl. II odst. 2 písm. a), b) nebo písm. i) delší než 30 dnů;
prodlení ve kterékoliv ze lhůt stanovených v předávacím protokolu k odstranění vad díla podle čl. IV odst. 6 delší než 60 dnů.
ze strany objednatele:
prodlení s úhradou zálohové faktury nebo daňového dokladu delší než 30 dnů.
Smluvní strany se dále dohodly, že jakékoliv ukončené neúspěšné akceptační řízení nebo jakákoliv vada kategorie A zjištěná během ověřovacího provozu, opravňují objednatele odstoupit od této smlouvy.
Odstoupí-li objednatel oprávněně od této smlouvy přede dnem předání díla (čl. II odst. 2 písm. i)), nenáleží poskytovateli žádná náhrada za plnění podle této smlouvy již poskytnutá a provedená a je také povinen vrátit objednatelem poskytnuté zálohy.
Uveřejnění smlouvy a dalších souvisejících skutečností
Poskytovatel si je vědom zákonné povinnosti objednatele uveřejnit na svém profilu tuto smlouvu včetně všech jejích případných změn a dodatků, a výši skutečně uhrazené ceny za plnění této smlouvy.
Profilem objednatele je elektronický nástroj, prostřednictvím kterého objednatel, jako veřejný zadavatel dle zákona č. 134/2016 Sb., o zadávání veřejných zakázek, ve znění pozdějších předpisů (dále jen „ZZVZ“), uveřejňuje informace a dokumenty ke svým veřejným zakázkám způsobem, který umožňuje neomezený a přímý dálkový přístup, přičemž profilem objednatele v době uzavření této smlouvy je xxxxx://xxxx.xxx.xx/.
Povinnost uveřejňování dle tohoto článku je objednateli uložena § 219 ZZVZ.
Článek XIX.
Závěrečná ustanovení
Smlouva se uzavírá na dobu neurčitou.
Smlouva nabývá platnosti a účinnosti dnem jejího podpisu poslední ze smluvních stran s tím, že podporu podle části B začne poskytovatel poskytovat ode dne předání díla podpisem předávacího protokolu pověřenými osobami smluvních stran.
Závazkový vztah založený touto smlouvou, se řídí českým právním řádem, zejména zákonem č. 89/2012 Sb., občanský zákoník, ve znění pozdějších předpisů a dále rovněž příslušnými ustanoveními zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon), ve znění pozdějších předpisů.
Smluvní strany se dohodly, že případný spor, který vznikne z této smlouvy nebo v souvislosti s ní bude rozhodován výlučně podle českého práva obecnými soudy v České republice.
Veškerá komunikace mezi smluvními stranami vztahující se k této smlouvě bude probíhat v českém nebo slovenském jazyce, nebude-li smluvními stranami v konkrétním případě dohodnuto jinak.
Stane-li se některé ustanovení této smlouvy neplatné či neúčinné, nedotýká se to ostatních ustanovení této smlouvy, která zůstávají platná a účinná. Smluvní strany se v tomto případě zavazují dohodou nahradit ustanovení neplatné/neúčinné novým ustanovením platným/účinným, které nejlépe odpovídá původně zamýšlenému účelu ustanovení neplatného/neúčinného. Do té doby platí odpovídající úprava obecně závazných právních předpisů České republiky.
Smlouva je vyhotovena ve čtyřech vyhotoveních s platností originálu, z nichž objednatel obdrží tři a poskytovatel jedno vyhotovení.
Příloha č. 1 – Katalog uživatelských požadavků
Příloha č. 2 – Technická specifika
Příloha č. 3 – Akceptační řízení
Příloha č. 4 – Šablona akceptačního protokolu
Příloha č. 5 – Šablona realizační studie
Příloha č. 6 – Šablona testovacího scénáře
Příloha č. 7 – Návrh řešení (volně přiložená příloha) (bude připojeno před podpisem smlouvy z nabídky dodavatele)
V Praze dne: ............................. V ...................... dne: ..................
Za objednatele: Za poskytovatele:
………………………………. .....................................................
Xxx. Xxxxxxxx Xxxxxxxx (doplní účastník)
ředitel sekce informatiky
…………………….................
ředitel sekce správní
Katalog uživatelských požadavků
Základní požadavek
SW řešení musí být realizován jako webová aplikace přístupná minimálně z prostředí Microsoft Internet Explorer 11 a vyšší.
Funkční požadavky
ID |
Název |
Popis požadavku |
Úprava stávajících vazeb mezi moduly (VAZxxx) |
||
VAZ001 |
Vazba Modulu Pořádání na Modul Lokace |
Po úpravě systému budou zachovány stávající vazby modulu Pořádání na modul Lokace (unikátní v ČNB), kdy prostřednictvím unikátního ID jsou předávány informace o úložné jednotce z modulu Pořádání do modulu Lokace. Odtud pak po provedení alokačního procesu je naopak předána informace o uložení dané úložné jednotky do modulu Pořádání. |
VAZ002 |
Vazba Modulu Pořádání na Modul VadeMeCum |
Po úpravě systému budou zachovány stávající vazby modulu Pořádání na modul VadeMeCum, kdy prostřednictvím unikátního ID jsou předávány informace o inventární jednotce, úložné jednotce a jednotlivých úrovních popisu (fond, série, podsérie, složka, jednotlivost) z modulu Pořádání do modulu VadeMeCum. |
VAZ003 |
Vazba modulu Pořádání na Modul Repozitory |
Po úpravě systému bude zachována stávající vazba modulu Pořádání na modul Repozitory a tohoto modulu na modul VadeMeCum, kdy prostřednictvím unikátního identifikátoru je hromadně načítán digitalizát (digitalizované archivní dokumenty a digitalborn dokumenty) z modulu Pořádání do Repository, resp. Modulu VadeMeCum |
Tematické databáze - nová funkcionalita umožňující spravovat specifické typy archivních dokumentů (TDBxxx) |
||
TDB001 |
Tematické databáze |
Systém umožní vytváření tematických databází, jež budou evidovat archivní jednotliviny, které se nacházejí na definovaných úrovních popisu v rámci části navigátoru nebo úložných jednotek. Funkcionalita tak umožní prostřednictvím tematických databází definovat diplomatické kategorie a podkategorie archivních dokumentů/úložných jednotek při zpracovávání archivních souborů ve smyslu Základních pravidel pro zpracování archiválií Ministerstva vnitra v jejich aktuální verzi (blíže webové stránky Ministerstva vnitra pod odkazem xxxx://xxx.xxxx.xx/xxxxxx/xxxxxxxx.xxxx?xxX0xxxX00Xx%0X%0X) str. 25 - 35, resp. vyhlášky č. 645/2004 Sb., ve znění pozdějších předpisů. Jedna každá archivní jednotlivina tak bude zařazena v rámci tematické databáze, navigátoru a úložné jednotce. |
TDB002 |
Kapitoly v TDB |
Systém umožní vytvářet kapitoly v rámci tematické databáze. |
TDB003 |
Podkapitoly v TDB |
Systém umožní vytvářet podkapitoly v rámci tematické databáze. |
TDB004 |
Šablony TDB |
Každá položka tematické databáze (kategorie/podkategorie) bude vybavena specifickou šablonou (bude obsahovat univerzální a specifické prvky popisu), jež se bude nabízet uživateli k editaci při výběru dané jednotliviny. |
Doplnění a rozšíření datových entit pro evidenci dle požadavků Základních pravidel (ENTxxx) |
||
ENT001 |
Vytvoření samostatných datových entit |
Systém umožní vytvoření samostatných datových entit, které budou obsahovat atributy v číselné a textové podobě, nesoucí časovou informaci a reference na jiné entity. Jejich pomocí budou prezentovány všechny jednotky popisu. K charakteru požadovaných entit jako nejnižších prvků popisu v rámci umělého schématu třídění viz Základní pravidla pro zpracování archiválií Ministerstva vnitra v jejich aktuální verzi (blíže webové stránky Ministerstva vnitra pod odkazem xxxx://xxx.xxxx.xx/xxxxxx/xxxxxxxx.xxxx?xxX0xxxX00Xx%0X%0X), resp. vyhláška č. 645/2004 Sb., ve znění pozdějších předpisů. |
ENT002 |
Vztahy mezi entitami |
Systém umožní definovat vztahy mezi jednotlivými entitami za pomoci datových polí a hodnot číselníků v závislosti na diplomatické kategorie a podkategorie archivních dokumentů/úložných jednotek při zpracovávání archivních souborů ve smyslu Základních pravidel pro zpracování archiválií Ministerstva vnitra v jejich aktuální verzi (blíže webové stránky Ministerstva vnitra pod odkazem xxxx://xxx.xxxx.xx/xxxxxx/xxxxxxxx.xxxx?xxX0xxxX00Xx%0X%0X), resp. vyhlášky č. 645/2004 Sb., ve znění pozdějších předpisů. |
Nastavení validačních pravidel pro archivní zpracování (VALxxx) |
||
VAL001 |
Zpracování validačních schémat |
Systém umožní zpracovat základní validační schémata pro jednotlivé kategorie: 1) pravidla podle úrovně popisu, 2) pravidla dle typu pomůcky, 3) pravidla dle kategorie a podkategorie. |
VAL002 |
Editace validačních schémat |
Systém umožní, aby administrátor kombinací vytvořil ve smyslu Základních pravidel jednotlivá validační schémata. |
VAL003 |
Nastavení striktní validace |
Systém umožní administrátorovi nastavit tzv. striktní validaci, tj. určit pravidla, bez nichž není možné uzavřít příslušný typ archivní pomůcky. Viz Základní pravidla pro zpracování archiválií Ministerstva vnitra v jejich aktuální verzi (blíže webové stránky Ministerstva vnitra pod odkazem xxxx://xxx.xxxx.xx/xxxxxx/xxxxxxxx.xxxx?xxX0xxxX00Xx%0X%0X), str. 42 - 44. |
VAL004 |
Nastavení fakultativní validace |
Systém umožní administrátorovi nastavit tzv. validaci formou upozornění, tj. systém pouze upozorní autora pomocí dialogového okna na nedostatečně vyplněný formulář daného záznamu. |
VAL005 |
Export validačních pravidel |
Systém umožní administrátorovi exportovat aktuální nastavení zobrazení polí a validačních pravidel. |
Úprava uživatelského rozhraní ISAI – zobrazení dat (POHxxx) |
||
POH001 |
Pohled do úrovně série |
Navigátor archivních souborů bude zobrazovat data do úrovně série (vyššího typu složky). |
POH002 |
Tabulkový pohled |
V rámci archivních souborů systém umožní tabulkový pohled s hierarchickým rozpadem na složku a jednotlivost. |
POH003 |
Dynamické zobrazení polí |
Systém umožní, aby docházelo v rámci základní popisné části k dynamickým úpravám zobrazení datových polí dle úrovně popisu (složka, jednotlivost/typ jednotlivosti). |
POH004 |
Pohled přes navigátor |
Systém nabídne pohled na data prostřednictvím tzv. navigátoru (přehled archivních fondů). |
POH005 |
Pohled přes tematickou databázi |
Systém nabídne pohled na data prostřednictvím tematické databáze. |
POH006 |
Pohled přes úložné jednotky |
Systém zachová stávající pohled na data prostřednictvím úložných jednotek jednotlivých archivních fondů (nových signatur daných úložnou jednotkou). Jedná se o funkcionalitu vytvořenou speciálně pro ČNB (ISAI). |
POH007 |
Provázání práce s inventárními jednotkami napříč pohledy |
Systém umožní práci s daty prostřednictvím každého z pohledů. Dojde k propojení práce, kdy prostřednictvím tematických databází bude možné založit nový záznam, který bude propojen s úložnými jednotkami a navigátorem. Obdobně se bude nabízet na úrovni jiných pohledů zařazení do tematických databází. |
POH008 |
Synchronizace zobrazení |
Systém umožní provádět synchronizaci zobrazení mezi navigátorem (archivní pomůckou), tematickou databází a úložnou jednotkou. |
POH009 |
Vícenásobné zobrazení |
Systém umožní vícenásobné zobrazování datových polí za pomoci záložek. |
POH010 |
Prezentace časových údajů |
Systém umožní editaci a následnou prezentaci časových údajů v podobě intervalu, který umožní preciznější vyhledávání v časových údajích. Zároveň bude možné vyhledávat žádaný časový údaj tak, aby různě podrobný číselný zápis (rok, měsíc, den) byl dohledán i jen za využití nejméně podrobného údaje (např. jen rok). Více Základní pravidla pro zpracování archiválií Ministerstva vnitra v jejich aktuální verzi (blíže webové stránky Ministerstva vnitra pod odkazem xxxx://xxx.xxxx.xx/xxxxxx/xxxxxxxx.xxxx?xxX0xxxX00Xx%0X%0X), str. 50. |
Úprava rejstříků – přístupových bodů (REJxxx) |
||
REJ001 |
Rozšíření přístupových bodů |
Systém umožní rozšířit rejstříky – přístupové body – o věcné role (věcné definice rejstříkových hesel) dle Základních pravidel, čímž dojde k vytvoření kontextové informace k rejstříkovému heslu. Umožňuje se např. vytvoření věcné role „autor“ a zároveň „autor výtvarné předlohy“. |
REJ002 |
Editace přístupových bodů |
Systém umožní práci s přístupovými body – jejich zakládání a editaci. |
REJ003 |
Specifika ČNB při práci s přístupovými body |
Systém zakomponuje stávající funkcionality vytvořené pro ČNB, jež jsou užívány při práci s rejstříky (stávající ISAI). |
Práce s pomůckami (POMxxx) |
||
POM001 |
Vytváření archivních pomůcek |
Systém umožní vytvořit pomůcky definované dle Základních pravidel (manipulační seznam, inventář, katalog). Každá z nich bude vybavena jednoznačným identifikátorem. |
POM002 |
Vytváření sérií |
Systém umožní v rámci pomůcek vytvořit série/podsérie. |
Rozšiřující funkcionality (ROZxxx) |
||
ROZ001 |
Zobrazení nevalidních polí |
Systém umožní vyhledat a zobrazit nevalidní pole záznamu. |
ROZ002 |
Přepínání do nevalidních polí |
Systém umožní uživateli automatizovaně se přepínat do nevalidních polí. |
ROZ003 |
Přidávání polí |
Systém umožní přidávat datová pole pro vkládání dat mimo rámec Základních pravidel. |
ROZ004 |
Odlišení přidaných polí |
Systém umožní odlišit přidaná datová pole mimo rámec Základních pravidel systémové a nové. |
ROZ005 |
Administrátor-ská definice nepovinných datových polí |
Systém umožní administrátorovi upravit uživatelskou definici nepovinných datových polí. |
ROZ006 |
Uživatelská definice nepovinných datových polí |
Systém umožní uživateli upravit si rozsah nepovinných datových polí. |
Úprava funkce vyhledávání (VYHxxx) |
||
VYH001 |
Strukturovaný dotaz |
Systém nabídne možnost zadávat strukturovaný dotaz ve vyhledávání. Rozšířený výběr se bude nabízet podle úrovně, kategorie, či pole kontextu. |
VYH002 |
Najdi a nahraď |
Systém nabídne funkcionalitu „Najdi a nahraď“ umožňující vyhledání hesla a nahrazení jiným. |
VYH003 |
Vyhledávání dle sérií |
Systém nabídne možnost provádět vyhledávání v jednotlivých větvích navigátoru, archivním souboru (dle sérií). |
VYH004 |
Uložení definice výběru |
Systém nabídne uživateli možnost uložit si definici rozšířeného výběru a tuto následně zobrazit/vyvolat, tzn. provést výběr na základě definice. |
VYH005 |
Zpřístupnění příloh na vyšší úrovni |
Přílohy (obrázky) připojené k jednotlivým inventárním záznamům budou přístupné na úrovni celého fondu (popř. jednotlivé série). Bude proto možné zobrazit přílohy na vyšších úrovních archivního popisu (archivní fond, série, podsérie, složka) |
Specifické požadavky
ID |
Název |
Popis požadavku |
Použitelnost (USExxx) |
||
USE001 |
Ergonomie |
Často prováděné transakce systému musí být navrženy tak, aby je bylo možno provést malým počtem interakcí. |
USE002 |
Uživatelské nastavení |
Aplikace bude trvale (trvale = mimo PC uživatele) ukládat změny v nastavení uživatelského rozhraní, které uživatel provede během práce se systémem. Typicky se tímto myslí – pořadí sloupců v tabulce dat, velikost jednotlivých sloupců, výchozí řazení, ale i jiné preference uživatele. |
USE003 |
Indikace činnosti aplikace |
V případě, že systém provádí akci, jejíž výsledek není okamžitý (typicky ukládání dat), bude svou činnost indikovat stylem, kdy uživatel pozná, že aktuálně systém zpracovává jeho požadavek. Během této doby nebude uživateli umožněno, aby v systému prováděl jakékoli další akce. |
USE004 |
Ovládací prvky |
Všechny ovládací prvky aplikace budou po najetí kurzoru nad daný ovládací prvek: Demonstrovat uživateli, že se jedná o ovládací prvek změnou kurzoru myši. Zobrazí nápovědu k danému ovládacímu prvku formou tooltipu. |
USE005 |
Klávesové zkratky |
Aplikace umožňuje často prováděné akce realizovat pomocí klávesových zkratek. |
Transformace dat (TRAxxx) |
||
TRA001 |
Analýza a namapování dat |
|
TRA002 |
Nástroj pro transformaci |
Vytvoření jednorázového nástroje pro transformaci dat dle výsledků analýzy a namapování a následná transformace dat. |
TRA003 |
Validace transformace |
Validace správnosti provedené transformace dat. |
Administrace oprávnění (ADMxxx) |
||
ADM001 |
Definice, nastavení a dědičnost přístupových práv k archivním pomůckám |
Ke každé archivní pomůcce a jejím podřízeným položkám (archivní fond, série, podsérie) lze oprávněným uživatelem kdykoliv definovat/nastavit přístupová práva včetně zachování jejich dědičnosti u podřízených položek. |
ADM002 |
Přístupová práva k přílohám |
Systém umožní zohlednit přístupová práva v rámci úpravy příloh (digitalizátu, digitalborn dokumentů aj.). |
Audit logy (AUDxxx) |
||
AUD001 |
Doplnění audit logů |
Stávající auditní logy budou doplněny o logování nových funkcionalit, včetně historie změn, chybová hlášení aplikace a systému. |
SW řešení musí akceptovat standardní systémové prostředí ČNB a musí být snadno do tohoto prostředí implementovatelné.
Prostředí datové sítě
Klientské stanice připojeny rychlostí 1000 Mbps
Servery připojeny typicky rychlostí 1 až 10 Gb
Adresace dle RFC 1918 (10.x.y.z, 172.16-31.x.y, 192.168.x.y)
Serverová část
Serverové prostředí (databázový či aplikační server):
Platforma architektury x86 - MS Windows Server 2008R2 Server, cp 1250
Platforma Red Hat Linux ver. 6 nebo 7
Platforma VMware vSphere ver 5 a vyšší
Platforma Oracle VM 3.4 a vyšší
Databázové servery
Data standardních IS jsou uložena v databázích Oracle:
Oracle RDBMS 12c EE provozovaný na dvou Oracle Exadata Quatter Rack X6-2, v primární a záložní budově, každý vybavený licencemi pro 40 jader (Intel Core), 1,5 TB RAM, 85 TB HDD, technologií RAC, Partitioning, Diagnostic a Tunning Pack.
Protokol Oracle SQL Net
Databázová platforma ČNB je postavena na databázi ORACLE, pro jejíž správu má ČNB vyškolené specialisty a je možné využít Oracle nadstavbu Oracle Business Intelligence 12c Enterprise Edition pro tvorbu sestav.
Aplikační a WWW servery
Oracle Web Logic Server 12c,
Microsoft IIS v roli MS Server 2008R2
Apache Tomcat 8
Objednatel poskytne následující konfiguraci pro provoz virtuálních aplikačních a WWW serverů na platformě Oracle VM (v případě Oracle Web Logic) nebo VMware:
Primární aplikační server
2 VCPU (virtuálních CPU)
8 GB RAM
vzdálené úložiště prostřednictvím sítě SAN – 250 GB
konektivita min. 1 Gbps
operační systém RedHat nebo Windows Server (viz. odst. 1.2)
Záložní aplikační server
stejná konfigurace
data se synchronizují na úrovni diskového pole
Primární WWW server
2 VCPU (virtuálních CPU)
8 GB RAM
vzdálené úložiště prostřednictvím sítě SAN – 100 GB
konektivita min. 1 Gbps
operační systém RedHat nebo Windows Server (viz. odst. 1.2)
Záložní WWW server
stejná konfigurace
data se synchronizují na úrovni diskového pole
Monitoring systémů
System Center Operations Manager 2012 R2 – centrální sběr logů
QUALYS Guard – monitoring zranitelností
SIEM HP ArcSight– sběr bezpečnostních logů
Oracle Enterprise Manager (sledování provozu databázového prostředí a aplikačních serverů)
Oracle Diagnostic Pack, Tunning Pack, Partitioning
Datová základna je koncepčně konsolidována v prostředí DB Oracle. Pro tuto platformu jsou zajištěny návazné procesy zálohování dat a replikace do záložního střediska, monitoring zranitelností a pravidelné aktualizace SW.
Klientské stanice
Osobní počítače typu IBM-PC kompatibilní (x86) nebo virtuální desktop
OS:
MS Windows 7 Professional 64bitCZ, cp 1250, Service Pack 1 (8GB RAM). Nutno počítat i s budoucím upgradem na MS Windows 10.
Notebooky s MS Windows 10 Pro 64bit CZ
Citrix XenApp 6.5 na MS Windows 2008 Server R2 (virtuální desktop využívající MS terminálové služby).
Další SW na klientské části je:
TCP/IP síťové služby (DHCP klient, SNMP klient),
MS Office 2010 Professional Plus CZ + SP 2, nutno počítat i budoucím upgradem na MS Office 2016.
MS Internet Explorer 11 CZ (aktuální SP),
Adobe Acrobat Reader 10 CZ nebo vyšší.
Symantec EndPoint Protection v aktuální verzi.
Instalace programového vybavení na klientskou stanici je prováděna především prostřednictvím vzdálené automatické instalace. Instalace musí být kompatibilní se službou MS Installer (standardní služba operačního systému). Instalace programového vybavení na vDesktop je prováděna centrálně pomocí tzv. image z provisioning serverů.
Není přípustné ukládat na klientskou stanici/vDesktop data trvalé hodnoty, taková data je nutno ukládat na centrální diskové kapacity. Na klientské stanici nesmí být prováděno dávkové zpracování dat IS.
Dávkové zpracování centrálně uložených dat je přípustné spouštět a provádět pouze na databázovém serveru nebo případně na aplikačním serveru.
Uživatel nebo aplikace mohou ukládat na klientskou stanici dočasná data a programové komponenty, které jsou odvozeny z centrálně uložených dat, mohou také provádět lokální zpracování dat. Pro případné vytváření dočasných souborů a ukládání dat při činnosti komponent je třeba využívat předdefinované adresáře dostupné přes proměnné prostředí (USERPROFILE, TEMP, TMP, APPDATA). V případě vDesktop jsou data na lokálním disku po restartu serveru smazána.
Přístupová práva na klientských stanicích a vDesktop odpovídají defaultnímu nastavení od firmy Microsoft po instalaci MS Windows 7 Professional (v případě vDesktop se jedná o MS Windows 2008R2). Výjimky pro potřeby aplikací je v nezbytných případech možné povolit po přesném definování potřebných změn v adresářích a v registrech a po náležitém zdůvodnění požadovaných změn. Výjimky jsou centrálně řízeny a aplikovány na klientské stanice a vDesktop prostřednictvím GPO (politiky v Active Directory). Obdobné požadavky platí i pro registrování knihoven a vytváření nebo změny hodnot klíčů v registrech.
Na klientské stanici a vDesktop pracuje uživatel standardně pod právy přidělené skupině „Users“.
Systémové služby
Single Sign-On
U informačních systémů ČNB je realizována funkce Single Sign-On s využitím služby Microsoft Active Directory (autentizační protokol Kerberos) a OID Oracle Internet Directory. Uživatel se autentizuje pouze jednou do domény CNB (typicky s využitím certifikátu na čipové kartě), při vyvolání libovolné aplikace již pak není zadávání jména/hesla nutné, ani žádná další autentizace uživatele není požadována.
Další podmínky jsou uvedeny v části druhé 2 Bezpečnost IT.
Zálohování IS a dat
Zálohování SW řešení a jeho dat je v ČNB řešeno centrálně, pokud bude databáze SW řešení typu Oracle. Zálohována jsou pouze data uložená na centrálních kapacitách ve správě sekce informatiky. Zálohování databázového prostředí probíhá pomocí nástroje Oracle RMAN. Pro zálohování je určen zálohovací systém HP Data Protector 9.07.
SW řešení bude instalováno a provozováno v prostředí Microsoft Cluster Server (Windows 2008). Mimo jiné musí být schopno automatického zotavení po havárii serveru a zároveň po zotavení musí mít zajištěnu konzistenci dat. Instalaci do prostředí Microsoft Cluster Server zajišťuje poskytovatel.
Integraci do prostředí geografického clusteru (tj. start SW řešení na druhém node clusteru v jiné lokalitě) zajišťuje objednatel.
SIEM (Sběr bezpečnostních logů)
Sběr a vyhodnocování bezpečnostních logů je v ČNB řešen centrálně systémem SIEM ArcSight od firmy HP.
SW řešení musí podporovat některý z následujících způsobů logování a sběru logů:
zaznamenávat logy ve strojově čitelné a zpracovatelné podobě, tzn. logy musí mít jednotnou strukturu, do souboru v operačním systému a tento v realtime sdílet pro systém SIEM. Soubor může rotovat, ale musí být zachováno jeho jméno
zaznamenávat logy ve strojově čitelné podobě do DB a umožnit realtime přístup systému SIEM k daným tabulkám,
odesílat logy ve strojově čitelné podobě na vzdálený server např. syslogem.
Pro správnou interpretaci a syntaktickou analýzu (parsing) je nutný popis struktury logu.
Elektronická pošta
Server elektronické pošty - MS Exchange 2010
Klient elektronické pošty - MS Outlook 2010
Tisková zařízení
Síťová tisková zařízení,
Komunikační protokol – TCP/IP,
Podporované síťové služby – SNMP, DHCP, DNS.
Centrální diskové kapacity
K dispozici jsou „fault“ tolerantní disková pole pro ukládání dat spravovaných databázovými systémy, pro sdílení programového vybavení a dat organizačních útvarů ČNB. Zálohování dat centrálních diskových kapacit je zajištěno.
Internet (DMZ)
E-mail je povolen všem uživatelům prostřednictvím poštovny Exchange a MTA serverů. Maximální velikost zprávy je však omezena na 30 MB a může být zablokována antivirovým systémem.
Neaktivní spojení jsou po jedné hodině přerušena.
Služby provozované v rámci aplikací nebo IS jsou registrovány a povolovány zvlášť
v souladu se systémovou bezpečnostní politikou DMZ na základě schválené žádosti.Přístup z Internetu je omezen pouze na dedikované servery v určené části DMZ.
Synchronizace času
Čas na všech komponentách sítě ČNB mimo stanic uživatelů je synchronizován se zdrojem přesného času (pro zajištění správného vyhodnocení auditních záznamů) protokolem NTP.
Řízení přístupu k IT
Ke všem funkcím, programovému vybavení či službám systémového prostředí, a obvykle i DB rolím, je řízen přístup prostřednictvím interně vyvinuté aplikace „ŘDB – Řídicí databáze“ (aplikace nad DB Oracle), která uchovává seznam uživatelů a jejich skupin. Tyto informace jsou pak propagovány např. do Microsoft Active Directory nebo zpřístupněny přes LDAP z Active Directory či z tabulek aplikace ŘDB prostřednictvím views do jiných systémů a aplikací dle jejich potřeb. Ke každému aktivu (aplikace, zdroj, funkce, privilegium atd.) je vytvořena tzv. aplikační skupina, do které jsou pak zařazovány uživatelské účty či účty klientských stanic a tím jsou jim dané komponenty, služby či funkce systémového prostředí ČNB, zpřístupněny.
V souladu s bezpečnostní politikou České národní banky v oblasti informačních technologií je SW řešení zabezpečeno proti hrozbám ohrožujícím jeho dostupnost, důvěrnost, integritu a auditovatelnost.
Zajištění bezpečnosti v ČNB:
Dostupnost |
Dostupnost je zajišťována také prostřednictvím 2 geograficky vzdálených středisek v lokalitě Praha v režimu „split-site“. |
Důvěrnost |
Řízený přístup (práva přístupu dle rolí). |
Integrita |
Použití https protokolu a databázové transakce |
Autentizace |
Primárně užitím čipové karty, pouze ve výjimečných a řádně zdůvodněných případech jménem a heslem OS Windows (SSO ve spolupráci s Active Directory). |
Prokazatelnost |
Záznam v auditním logu. |
Servery a na nich instalované SW produkty jsou pravidelně monitorovány a skenovány produktem QUALYS (xxxx://xxx.xxxxxx.xxx/). Pokud jsou nalezeny zranitelnosti u instalovaných produktů hodnoty 4 a vyšší (hodnoty výstupu ze systému Qualys), jsou neprodleně odstraněny a to formou aplikací patchů či jiným doporučeným postupem.
Součástí akceptace systému je provedení penetračního testu a skenu známých zranitelností. Testována jsou rozhraní dostupná z internetu, interním uživatelům i případná další (propojení s jinými systémy).
Všechna datová média (především pevné disky) použitá v informačním systému jsou před přemístěním mimo prostory ČNB bezpečně smazána nebo zničena.
Vzdálený přístup k dokumentům v systému
ČNB připojuje uživatele do sítě prostřednictvím vzdálené plochy realizované pomocí klientského SW Citrix Receiver.
Seznam vazeb – základní přehled
Systém |
Popis využití |
MS Exchange |
Microsoft Exchange Server je SW produkt společnosti Microsoft, který bude využit pro zasílání e-mailových notifikací |
ŘDB |
Informační systém pro správu řízení přístupu uživatelů a skupin uživatelů domény xx.xxx.xx k IS ČNB a pro správu nastavení zařízení zapojených do LAN sítě ČNB. Systém pro podporu činností archivu ČNB denně aktualizuje z ŘDB/Active Directory uživatele a uživatelské a organizační skupiny. |
IS e-Spis |
Systém elektronické spisové služby, ve kterém jsou evidovány dokumenty v podatelně/výpravně ČNB a spisových uzlech jednotlivých sekcí. Systém splňuje všechny náležitosti spisové služby v souladu s Národním standardem (tvorba spisu, ukládání spisu, skartační řízení atd.) a zajišťuje také archivaci spisů v souladu se zákonem č. 499/2004 Sb. o archivnictví a spisové službě. |
SIEM |
Systém pro centrální sběr bezpečnostních logů (Security Information and Event Management), kde jsou ukládány detailní záznamy o přístupech uživatelů do systémů, popř. jejich dalších aktivitách v systému. |
Firewall |
Síťové zařízení, které slouží k řízení a zabezpečování síťového provozu mezi externími sítěmi a interní sítí ČNB. Zabezpečuje komunikaci pro domácí klientské stanice, mobilní zařízení uživatelů (zaměstnanců ČNB) přes VPN. |
Pod pojmem „migrace dat“ jsou zahrnuty tyto akce a procesy:
analýza zdrojové struktury, cílové struktury SW řešení a transformační mapování mezi oběma strukturami,
export objednatelem určených dat ze zdrojového systému pro SW řešení na základě namapování dat,
import vyexportovaných dat ze zdrojového systému do SW řešení.
ad a)
Analýzu a přípravu procesu uvedeného v bodu a) musí zajišťovat objednatel ve spolupráci s poskytovatelem. Poskytovatel musí poskytnout datové struktury nového systému a ve spolupráci s objednatelem navrhne namapování dat ze zdrojového systému a dat SW řešení. Popis namapování a následné migrace bude zdokumentován v realizační studii.
ad b)
Poskytovatel zajistí export určených dat ze zdrojového systému pro SW řešení na základě namapování dat.
ad c)
Poskytovatel musí připravit datové struktury a nástroje pro import vyexportovaných dat ze zdrojového systému. Po importu musí být provedeno otestování komplexnosti dat (dokumenty včetně metadat), jejich správnosti a přidělení přístupových oprávnění z hlediska metodiky nového SW řešení.
Objednatel předpokládá, že procesy b) a c) mohou být opakovány několikrát podle specifikace objednatele, vzhledem k typu dat uložených v současném IS. Detailní rozsah bude popsán v realizační studii.
AKCEPTAČNÍ ŘÍZENÍ
Akceptační řízení prověří, zda dodané SW řešení splňuje všechny požadavky na něj kladené ve smlouvě (zejména v příloze č. 1 smlouvy) a blíže specifikované v realizační studii (neplatí pro akceptační testy samotné realizační studie), vypracované poskytovatelem v souladu se smlouvou, a je tak SW řešení možné převzít objednatelem do ověřovacího provozu. Dále zahrnuje prověření realizační studie a technické, administrátorské a uživatelské dokumentace.
Při akceptačním řízení ohledně realizační studie a ostatní dokumentace se bude postupovat následovně:
Při akceptaci realizační studie se ověří obsah realizační studie oproti šabloně podle přílohy č. 5 smlouvy, oproti obsahu smlouvy a též po formální stránce (gramatické i logické chyby a nesprávnosti).
Akceptace realizační studie bude zahájena do 5 pracovních dnů ode dne splnění předpokladů pro provedení akceptace realizační studie podle kapitoly 3. této přílohy a bude probíhat po dobu 15 pracovních dnů, není-li dále uvedeno jinak.
Akceptační řízení ohledně realizační studie bude ukončeno vydáním protokolu o výsledku akceptačního řízení do 5 pracovních dnů ode dne ukončení akceptačních testů. Opakováno může být akceptační řízení pouze v souladu se smlouvou.
Při akceptaci technické, administrátorské a uživatelské dokumentace se ověří shoda obsahu dokumentace s reálnou podobou a fungováním SW řešení během akceptačního testování SW řešení.
Pro akceptaci platí přiměřeně, co je dále ve „Společné části postupu pro všechna akceptační řízení“ a kapitolách 4. a 5. této přílohy uvedeno o akceptačních testech.
Při akceptačním řízení SW řešení se bude postupovat následovně:
Akceptační testy se budou provádět zásadně na úrovni jednotlivých procesních rolí a nikoliv pod účtem systémového administrátora a takovým způsobem, při kterém se projeví případné nekonzistence z hlediska přístupových práv apod.
Testovací scénáře, u kterých objednatel potvrdí, že jsou v pořádku, se nemusí např. kvůli časové náročnosti provádět.
Testovací scénáře nejsou pro objednatele závazné.
Jednotlivé testovací scénáře a další testy, pro jejichž provedení se objednatel během akceptačního testování rozhodne, mohou být prováděny i zároveň.
Akceptační testy SW řešení budou zahájeny do 5 pracovních dnů ode dne splnění předpokladů pro provedení akceptačních testů SW řešení podle kapitoly 3. této přílohy a budou probíhat po dobu 15 pracovních dnů, není-li dále uvedeno jinak.
Akceptační řízení ohledně SW řešení bude zahájeno zahájením akceptačních testů a ukončeno vydáním protokolu o výsledku akceptačního řízení do 5 dnů ode dne ukončení akceptačních testů. Opakováno může být akceptační řízení pouze v souladu se smlouvou.
Společná část postupu pro všechna akceptační řízení:
Jednotlivým vadám, zjištěným během akceptačních testů, budou přidělovány kategorie A/B/C podle kapitoly 4. této přílohy.
V případě výskytu stejné vady v různých místech SW řešení budou tyto vady posuzovány jako jedna a táž vada.
Skutečnosti projevující se jako vady, avšak způsobené neodborným zásahem uživatele objednatele, nemohou být klasifikovány jako vady.
O tom, zda je určitá skutečnost vadou a o kategorizaci takové vady, rozhoduje za objednatele osoba provádějící akceptační testy, která tato rozhodnutí oznamuje buď na místě osobám přítomným za poskytovatele při akceptačních testech, nebo není-li takový postup možný, e-mailem pověřené osobě poskytovatele. Nesouhlasí-li poskytovatel s rozhodnutím podle předchozí věty, může proti němu do 1 pracovního dne vznést e-mailem, zaslaným pověřené osobě objednatele, písemně odůvodněnou námitku. O námitce rozhodne e-mailem, zaslaným pověřené osobě poskytovatele, s konečnou platností pověřená osoba objednatele.
Pokud bude při akceptačních testech zjištěna vada kategorie A, která zabraňuje pokračování a dokončení akceptačních testů, přerušují se akceptační testy na dobu 5 pracovních dnů, které budou poskytovateli poskytnuty k odstranění takové vady. Bude-li vada v uvedené lhůtě odstraněna, bude se v akceptačních testech pokračovat; nebude-li vada v uvedené lhůtě odstraněna, akceptační testy budou ukončeny.
Pokud bude při akceptačních testech opakovaně zjištěna vada kategorie A, která zabraňuje pokračování a dokončení akceptačních testů, jsou akceptační testy ukončeny.
Pokud bude při akceptačních testech zjištěna vada kategorie A, která nezabraňuje pokračování a dokončení akceptačních testů:
- může se poskytovatel pokusit veškeré takové vady odstranit již během akceptačních testů, nenaruší-li tím jejich průběh;
- může poskytovatel požádat pověřenou osobu objednatele o přerušení akceptačních testů za účelem odstranění kterékoliv z těchto vad, nejdéle však na dobu 5 pracovních dnů v součtu během celého akceptačního testování.
Pokud bude při akceptačních testech zjištěna vada kategorie B nebo C:
- může se poskytovatel pokusit veškeré takové vady odstranit již během akceptačních testů, nenaruší-li tím jejich průběh;
- může poskytovatel požádat pověřenou osobu objednatele o přerušení akceptačních testů za účelem odstranění kterékoliv z těchto vad, nejdéle však na dobu 5 pracovních dnů v součtu během celého akceptačního testování;
- mohou se poskytovatel s objednatelem dohodnout na termínu jejího odstranění během ověřovacího provozu, maximálně však u 5 vad kategorie B a 10 vad kategorie C.
Veškeré vady testované části díla, které zůstávají ještě v okamžiku ukončení akceptačních testů, se uvedou v protokolu o výsledku akceptačního řízení.
V případě akceptačních testů SW řešení se do protokolu o výsledku akceptačního řízení rovněž zaznamenají výsledky jednotlivých akceptačních testů podle testovacích scénářů „bez vady“ nebo „s vadou“.
Předpoklady pro provedení akceptace realizační studie jsou naplněny, jestliže:
Byla realizační studie poskytnuta poskytovatelem objednateli.
Předpoklady pro provedení akceptačních testů SW řešení jsou naplněny, jestliže:
Je k dispozici testovací prostředí s kompletně dokončeným nastavením SW řešení pro akceptační testy.
Byli zaškoleni pracovníci objednatele podle čl. I odst. 3 písm. c) smlouvy.
Byly poskytovatelem objednateli poskytnuty testovací scénáře podle čl. I odst. 3 písm. b) smlouvy.
Byla poskytovatelem objednateli poskytnuta technická, administrátorská i uživatelské dokumentace podle čl. I odst. 3 písm. f) smlouvy.
Jsou stanoveny tyto kategorie vad:
A – Kritická vada - velmi vážná vada, která znemožňuje práci se SW řešením (dále též „systém“) nebo nesplňuje funkční zadání, tzn. že splňuje alespoň jednu z níže uvedených charakteristik:
vada v požadovaném dokumentu:
chybějící textová část vyplývající z definované struktury,
textová část neodpovídá skutečnosti popisované entity (např. systému, procesu, chybové zprávě),
vada SW řešení:
způsobuje tak závažné problémy, že další vývoj ani dodržení dohodnutého časového plánu nejsou možné,
vyplývá z nedodržení závazných právních předpisů,
nedodržení či neprokázání realizace nebo jen částečná realizace požadavku uvedeného ve smlouvě a jejích přílohách,
znemožňuje používání dodaného SW řešení jako celku nebo znemožňuje používání základních funkcí dodaného SW řešení podle jeho dokumentace,
zapříčiňuje nemožnost používání nebo ovládání dodaného SW řešení,
zapříčiní ztrátu dat nebo úplně znemožní užití dodaného SW řešení,
způsobuje, že použití dodaného SW řešení by nebylo bezpečné nebo by plně neodpovídalo zásadám bezpečnostní politiky objednatele,
ohrožuje provoz nebo dostupnost ostatních aplikací i samotného dodaného SW řešení v provozním prostředí objednatele,
způsobuje, že dodané SW řešení není schopno zpracovat běžnou provozní zátěž,
za provozních podmínek vede k omezení funkcionality systému s dopadem na významný počet uživatelů,
projevuje se stále, občas nebo náhodně a splňuje některou z výše popsaných charakteristik.
B – Podstatná vada - vada, kterou je možno dočasně vyřešit organizačním či jiným opatřením, tzn. že splňuje alespoň jednu z níže uvedených charakteristik:
vada v požadovaném dokumentu:
nejednoznačnost textové části,
vada SW řešení:
je možné pro její překonání nalézt odpovídající alternativu, která je akceptovatelná objednatelem,
způsobuje, že dodané SW řešení není schopno zpracovat maximální provozní zátěž,
projevuje se stále, občas nebo náhodně a splňuje některou z výše popsaných charakteristik.
C – Nepodstatná vada - drobná vada, která nemá vliv na provoz systému, tzn. že splňuje alespoň jednu z níže uvedených charakteristik:
vada v požadovaném dokumentu:
je způsobena gramatickou chybou, nevhodným formátováním, překlepy apod.,
vada SW řešení:
je způsobená drobnými konstrukčními nedostatky,
je pouze „kosmetického“ charakteru,
projevuje se stále, občas nebo náhodně a splňuje některou z výše popsaných charakteristik.
5.1 Protokol o výsledku akceptačního řízení
Průběh akceptačních testů a další průběh akceptačního řízení bude uveden v protokolu o výsledku akceptačního řízení (dále jen „protokol“), jehož šablona je přílohou č. 4 smlouvy. Obsah protokolu se řídí touto přílohou; protokol obsahuje především:
Předmět akceptačního řízení.
Popis průběhu akceptačního testování.
V případě akceptačních testů SW řešení seznam provedených testovacích scénářů.
V případě akceptačních testů SW řešení výsledky jednotlivých dílčích akceptačních testů podle testovacích scénářů včetně dílčích hodnocení.
Veškeré vady testované části díla, které toto má ještě v okamžiku ukončení akceptačních testů.
Termín odstranění každé jednotlivé vady, na kterých se smluvní strany dohodly.
V protokolu mohou smluvní strany připomínkovat i další skutečnosti, které nejsou vadami testované části díla, a dohodnou se na jejich řešení.
Protokol vydává objednatel jeho zasláním na e-mail pověřené osoby poskytovatele, a to vždy do 5 pracovních dnů po skončení akceptačních testů testované části díla.
Proti obsahu protokolu může poskytovatel do 3 pracovních dnů vznést e-mailem, zaslaným pověřené osobě objednatele, písemně odůvodněnou námitku. O námitce rozhodne e-mailem, zaslaným pověřené osobě poskytovatele, s konečnou platností pověřená osoba objednatele.
Protokol za smluvní strany podepisují pověřené osoby smluvních stran. Odepření podpisu protokolu ze strany pověřené osoby poskytovatele nenarušuje jeho právní následky ani právní následky výsledku akceptačního řízení podle smlouvy.
5.2 Hodnocení
Akceptační řízení bude uzavřeno s výsledkem „neakceptováno“, pakliže:
byly akceptační testy ukončeny kvůli vadě kategorie A, která zabraňovala pokračování a dokončení akceptačních testů a nebyla odstraněna ani ve lhůtě 5 pracovních dnů, poskytnuté na její odstranění poskytovateli;
byly akceptační testy ukončeny kvůli opakovanému zjištění vady kategorie A, která zabraňovala pokračování a dokončení akceptačních testů;
má testovaná část díla ještě v okamžiku ukončení akceptačních testů jakoukoliv vadu kategorie A;
má testovaná část díla ještě v okamžiku ukončení akceptačních testů jakoukoliv vadu kategorie B nebo C, na jejímž termínu odstranění se smluvní strany nedohodly;
má testovaná část díla ještě v okamžiku ukončení akceptačních testů více než 5 vad kategorie B, byť by se i na termínu jejich odstranění smluvní strany dohodly;
má testovaná část díla ještě v okamžiku ukončení akceptačních testů více než 10 vad kategorie C, byť by se i na termínu jejich odstranění smluvní strany dohodly; nebo
pokud existovaly podmínky pro uzavření akceptačního řízení s výsledkem „akceptováno s výhradou“, avšak pověřená osoba poskytovatele odepřela podpis příslušného protokolu.
Akceptační řízení bude uzavřeno s výsledkem „akceptováno s výhradou“, pakliže:
má testovaná část díla ještě v okamžiku ukončení akceptačních testů 5 nebo méně vad kategorie B a smluvní strany se dohodly na termínech jejich odstranění;
má testovaná část díla ještě v okamžiku ukončení akceptačních testů 10 nebo méně vad kategorie C a smluvní strany se dohodly na termínech jejich odstranění;
nemá testovaná část díla již v okamžiku ukončení akceptačních testů žádné vady, avšak smluvní strany se v protokolu dohodly na řešení jiných skutečností týkajících se testované části díla, které nejsou vadami.
Akceptační řízení bude uzavřeno s výsledkem „akceptováno“, pakliže:
nemá testovaná část díla v okamžiku ukončení akceptačních testů žádné vady.
Akceptační řízení uzavřené s výsledkem „neakceptováno“ a ukončené příslušným protokolem se považuje za neúspěšné a dále se postupuje podle čl. III odst. 2 smlouvy.
Akceptační řízení uzavřené s výsledkem „akceptováno s výhradou“ nebo „akceptováno“ a ukončené příslušným protokolem se považuje za úspěšné.
Šablona akceptačního protokolu
|
Protokol o výsledku akceptačního řízení
Poskytovatel |
Objednatel |
IČO: DIČ: |
Česká národní banka
|
Evidenční číslo smlouvy v ČNB: |
|
Název smlouvy: |
|
Předmět akceptačního řízení: |
|
Závěr akceptačního řízení |
Shrnutí obsahu akceptačního řízení.
Z výše uvedených důvodů bylo akceptační řízení uzavřeno s výsledkem:
Neakceptováno/Akceptováno s výhradou/Akceptováno
Následné kroky, např.: Poskytovatel akceptoval uvedené vady s tím, že odstraní vady uvedené v příloze č.1 do ........ Fakturaci dle ........ smlouvy lze provést až po odstranění uvedených vad.
V Praze dne .....................
Za poskytovatele:
………………………………… (pověřená osoba poskytovatele) |
Za objednatele:
………………………………… (pověřená osoba objednatele)
|
|
Protokol o výsledku akceptačního řízení – Příloha č.1
Seznam vad |
ID |
Kategorie |
Popis vady |
Termín odstranění vady |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Šablona realizační studie
|
Projekt 7019/2018
„ISAI – Základní pravidla“
Realizační studie
Verze |
|
Datum verze |
|
Autor |
|
Vedoucí projektu poskytovatele |
|
Vedoucí projektu objednatele |
|
Tento dokument obsahuje informace důvěrného charakteru a informace v něm obsažené jsou vlastnictvím České národní banky. Žádná část dokumentu nesmí být kopírována, uchovávána v dokumentovém systému nebo přenášena jakýmkoliv způsobem včetně elektronického, mechanického, fotografického či jiného záznamu a uveřejněna či poskytnuta třetí straně bez předchozí dohody a písemného souhlasu vlastníků.
Některé názvy použité v tomto dokumentu mohou být registrovanými ochrannými známkami nebo obchodními značkami, které jsou majetkem svých vlastníků.
Historie změn
Verze |
Datum |
Autor |
Popis změny |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Obsah
Další práva a povinnosti smluvní stran při úpravách IS ISAI 6
Příloha č. 1 – Katalog uživatelských požadavků 17
Příloha č. 2 – Technická specifika 17
Zajištění bezpečnosti v ČNB: 6
Vzdálený přístup k dokumentům v systému 6
5. Výsledek akceptačního řízení 4
5.1 Protokol o výsledku akceptačního řízení 4
1.3 Přehled použitých symbolů 6
2.2 Mapování uživatelského rozhraní na klíčové procesy 7
2.4 Analýza vybraných požadavků 7
3 Technická realizace SW řešení 8
3.1 Výchozí situace a cílový stav 8
3.2 Návrh architektury technického řešení 8
3.5 Požadavky na systémové prostředí 8
3.6.2 Autentizace a autorizace 9
3.8 Instalace, podpora a údržba 9
4 Návrh projektové realizace 10
4.2 Detailní harmonogram realizace 10
4.3 Požadavky na součinnost 10
4.4 Akceptační testovací scénáře 10
Dokument realizační studie popisuje způsob realizace dodávaného softwarového řešení včetně mapování funkčních požadavků, softwarové architektury a systémových požadavků tak, aby byla prokázána realizovatelnost všech zadaných požadavků.
[Výčet klíčových zkratek a pojmů s jejich vysvětlením]
Termín/Zkratka |
Popis/Význam |
|
|
|
|
|
|
|
|
|
|
[Popis použitých grafických symbolů v dokumentu]
Grafický symbol |
Význam |
|
|
|
|
|
|
[Kapitola obsahuje analýzu procesů, pro jejich grafické znázornění lze použít buď UML Activity diagram, nebo BPMN (Business Process Model and Notation)].
[Kapitola obsahuje mapování grafického uživatelského rozhraní aplikace tak, aby šlo ověřit pracovní postup koncových uživatelů v rámci zadaného pracovního procesu resp. postupu a to ve všech uživatelských rozhraní].
Zobrazení jednotlivých formulářů a grafických obrazovek musí být doplněn o popis jednotlivých vstupně/výstupních polí a funkčních tlačítek (může být řešeno odkazem na existující dokumentaci)].
Název prvku |
Význam |
Příznak |
Formát |
Poznámka |
|
|
|
|
|
|
|
|
|
|
Legenda:
Název: Zobrazený název I/O atributu (vstupně/výstupní pole, tlačítko)
Význam: Slovní popis významu atributu
Příznak: RO - pouze pro čtení, P - povinná editovatelná, N - nepovinná editovatelná
Formát: popis zobrazeného formátu (např. dd.mm.yyyy)
Poznámka: popis upřesňující informace (např. odkaz na validace]
[Kapitole obsahuje mapování požadavků objednatele na cílové SW řešení. Popis tak ve stručné formě představuje způsob realizace jednotlivých uživatelských požadavků uvedených v příloze č. 1 smlouvy]
ID1 |
Popis požadavku |
Název funkcionality |
Poznámka |
|
|
|
|
|
|
|
|
|
|
|
|
[V této kapitole je detailně popsána analýza požadavků objednatele, které jsou částečně v dodávaném řešení realizovány nebo je nutné je v dodávaném řešení teprve vyvinout (viz příloha 1 smlouvy), například formou případů užití (Use Case) nebo návrhu grafického rozhraní, a to takovým stylem, aby byla jednoznačně prokázána realizovatelnost požadavků.]
[Kapitola stručně popisuje výchozí a cílový stav navrhované architektury řešení popsaný v následujících kapitolách.]
[Kapitola popisuje globální architekturu IS a fyzickou architekturu nasazení aplikace v infrastruktuře objednatele s ohledem na provoz, monitoring, zálohování a archivaci aplikace.]
[Kapitola obsahuje:
popis možností integrace SW řešení s jednotlivými stávajícími a budoucími aplikacemi ČNB
kompletní aplikační programové rozhraní (API), metody a příklady použití SW řešení.
detailní popis rozhraní pro pravidelné, automatizované předávání a přebírání dat z/do SW řešení IS do/z IS ČNB.]
[Kapitola obsahuje analýzu a namapování datových struktur – „stávající a nové“ podle metodiky užité v Základních pravidlech z hlediska jejich převoditelnosti a datové migrace (tj. jednoznačné srovnání datových objektů, které budou využívány při migraci dat mezi oběma systémy) a popis vlastní migrace.
Na analýze se podílejí jak zadavatel, tak poskytovatel obou systémů – viz požadavky TRA001 a TRA002 z přílohy smlouvy č. 1.]
[Kapitola obsahuje SW a HW specifikaci pro nasazení v prostředí ČNB. Součástí je i sizing HW prostředků pro účely implementace systému. V případě, kdy jsou řešeny různá prostředí provoz/test/vývoj/školení/atd. jsou tato prostředí popsána zvlášť]
Tabulka 1: HW specifikace
Prvek |
Typ |
Výkon |
RAM |
Disková kapacita |
Síťové rozhraní |
Poznámka |
APP1 |
Virtuální server |
2 – 4 virtuální CPU, 2 – 3 GHz |
4 – 8 GB |
15 GB |
100 Mbps |
|
|
|
|
|
|
|
|
Tabulka 2: SW specifikace
Prvek |
OS |
Databázové služby |
Aplikační služby |
Poznámka |
APP1 |
Windows Server 2008 R2 ENG x64 |
Oracle client 10g |
MS IIS 7.5 XXX.XXX 3.5 SP1 |
|
|
|
|
|
|
[Kapitola obsahuje popis aplikace z hlediska její bezpečnosti, integrity a důvěrnosti dat.]
[Podkapitola obsahuje analýzu rizik bezpečnosti informací včetně posouzení rizik podle § 13 odst. 3 zákona č. 101/2000 Sb., o ochraně osobních údajů.]
[V podkapitole je popsán princip řízení přístupů k informacím resp. informačním aktivům: jakým prostřednictvím přistupují interní a externí uživatelé, popis technických (aplikačních) účtů – bez časového omezení; způsob automatického blokování účtů uživatelů při ukončení zaměstnaneckého poměru v ČNB, povolené protokoly apod.]
[V podkapitole je popsán způsob logování a monitorování logů]
[Kapitola shrnuje identifikované standardy a normy používané při realizaci SW řešení.]
[Kapitola obsahuje:
postup nasazení SW řešení do cílového prostředí s ohledem na stanovení příslušné součinnosti ze strany ČNB,
popis podpory a údržby SW řešení ze strany poskytovatele.]
[Tabulka obsahuje seznam vytvářených klíčových výstupů s plánovaným termínem jejich odevzdání]
Název |
Popis |
Plánovaný termín dodání |
|
|
|
Legenda
Název: Název dokumentu např. Realizační studie
Popis: Stručný popis obsahu dokumentu
Plánovaný termín dodání: termín dodání
[Harmonogram realizace uvádí rozpad realizace projektu do jednotlivých přírůstků (dílčích plnění), etap, fází a činností s ohledem na dodržení smlouvou stanovených termínů/lhůt. Harmonogram musí obsahovat milníky pro předání díla nebo jeho částí k akceptačnímu řízení]
[V kapitole je uveden rozsah kapacit požadovaných poskytovatelem po objednateli]
ID |
Popis součinnosti |
Rozsah |
Čerpání |
|
|
|
|
Legenda:
ID: Jedinečný identifikátor požadované součinnosti
Popis součinnosti: popis aktivit, požadovaných poskytovatelem po objednateli
Rozsah: odhadovaný rozsah požadovaných kapacit v čld
Čerpání: četnost, způsob čerpání kapacit např. 1x týdně; 2hod v Pá
[V kapitole je popsán seznam všech připravovaných akceptačních testovacích scénářů, které kompletně ověří požadovanou funkcionalitu systému]
ID scénáře |
Testovaná oblast |
Testovací scénář |
ID požadavku |
|
|
|
|
Legenda
ID scénáře: Jedinečný identifikátor testovacího scénáře
Testovaná oblast: Oblast testování např.: Personalistika, ….
Testovací scénář: Popis testovacího scénáře
ID požadavku: Jedinečné identifikátory požadavků objednatele, které jsou daným testovacím scénářem ověřovány.
Šablona testovacího scénáře
Popis polí šablony testovacího scénáře
Název - název testovacího scénáře ve vazbě na testovanou oblast/proces
Verze - verze testovacího scénáře
ID scénáře - pořadové číslo scénáře ve formátu Txx
Popis - stručný popis testované oblasti/procesu
Testované požadavky – ID požadavku z přílohy č. 1 smlouvy
Vstupní podmínky - popis podmínek pro realizaci testovacího scénáře, např.: nastavení rolí, způsob přihlášení, dostupnost/připravenost dat apod.
Krok - popis jednotlivých kroků postupu, které bude provádět tester při testování ve struktuře A – požadovaná akce, R – předpokládaná reakce systému
Název |
|
||||||
ID scénáře |
|
Verze |
|
||||
Popis |
|
||||||
Testované požadavky |
|
||||||
Vstupní podmínky |
|
||||||
Popis kroků |
|||||||
Krok |
Činnost |
Výsledek2 |
|||||
|
|
A: |
|
|
||||
R: |
|
||||||
|
|
A: |
|
|
||||
R: |
|
||||||
|
|
A: |
|
|
||||
R: |
|
||||||
|
|
A: |
|
|
||||
R: |
|
||||||
|
|
A: |
|
|
||||
R: |
|
||||||
Hodnocení3 |
|
||||||
Odůvodnění |
|
||||||
Poznámka |
|
||||||
Datum |
|
Podpis testera |
|
||||
1 ID požadavku objednatele
2 Hodnota pole „výsledek“ nabývá hodnot „OK“, pokud systém provedl očekávanou reakci. V opačném případě je hodnotou jedinečný identifikátor chyby v aplikaci Redmine.
3 Nabývá hodnot „Bez vad“/“S vadou“. V případě hodnocení „S vadou“ se uvádí i kategorie vady A/B/C a Odůvodnění klasifikace chyby.
11