Příloha č. 1

Evidenční číslo smlouvy ČNB: 00-000-00 Příloha č. 1 smlouvy

Příloha č. 1

VĚCNÉ ZADÁNÍ

INFORMAČNÍHO SYSTÉMU RiskMS

Věcné zadání zahrnuje výchozí uživatelské požadavky na funkčnost informačního systému RiskMS v ČNB.

1. Cíle systému

Systém RiskMS je určen pro sekci řízení rizik a podpory obchodů, konkrétně pro podporu procesů týkajících se správy rizik spojených s obchody ČNB na finančních trzích, tj. zejména na řízení rizik a měření výkonnosti portfolií. Systém podporuje následující procesy:

• měření tržního rizika

• měření kreditního rizika

• definování limitů a sledování jejich dodržování

• oceňování instrumentů

• měření výkonnosti a atribuční rozklad výnosů

• definice benchmarku

• analýza a simulace portfolií

• operační riziko

Měření tržního rizika obnáší výpočet, sledování a reportování tržních rizik v souladu se standardy oboru na všech úrovních od jednotlivých instrumentů/transakcí až po agregovanou úroveň za celé portfolio. Požadované míry rizika zahrnují:

• durace

• effective duration (u callable a putteble dluhopisů)

• option adjusted duration and convexity

• spread duration (citlivost ceny bondu na změnu v option-adjusted spread)

• basis point value

• basis point value in time buckets

• convexity

• VaR

• marginal VaR

• component VaR

• Greeks

Následující míry tržního rizika nejsou požadovány, ale jsou vítanou funkcionalitou systému:

• key rate duration

• carry

• z-spread

• expected shortfall/conditional VaR

• diversified VaR

• undiversified VaR

• uncorrelated VaR

• incremental VaR

• expected loss

• alfa

• beta

Měření kreditního rizika zahrnuje výpočet a monitorování ukazatelů míry kreditního rizika v souladu se standardy v oboru na všech úrovních od jednotlivých obchodů po úroveň agregovaných portfolií.

Systém umožňuje definovat odvozené veličiny (expozice) a formulovat jejich omezení, tzv. limity. Číselnou hodnotu omezení (hodnotu limitu) systém importuje z interních systémů ČNB. Limity jsou definovány jak pro tržní tak i pro kreditní riziko a jejich expozice jsou vůči těmto limitům kontrolovány. Systém umožňuje definovat limity pro agregovaná portfolia, jednotlivá portfolia, sub-portfolia i jednotlivé obchody.

Cenou se rozumí obecně kotace ceny, úrokové sazby, výnosu, výnosové křivky, volatility a indexu. Zaznamenávání cen je potřebné z několika důvodů: oceňování portfolia a instrumentů, měření rizik, oceňování kolaterálu a pro účetní potřeby. Ceny se získávají ze standardních rozhraní externích poskytovatelů, jako jsou Reuters a Bloomberg, a z interní databáze, kde jsou uloženy interně stanovené ceny (např. fixingy kurzů). Ceny se získávají v sadách, které se ukládají do databáze denně v předem stanovených časech.

2. Charakteristika rolí uživatelů (skupiny rolí uživatelů)

• Administrátor systému RiskMS – 2 zaměstnanci sekce informatiky,

• Risk manager – až 4 zaměstnanci ČNB,

• Uživatel – až 20 zaměstnanců dealingu ČNB.

3. Popis požadavků

   1. Měření tržního rizika

      1. Obecné požadavky na měření tržního rizika

         1. Povinné

            ID	Popis požadavku	Popis realizace (doplní uchazeč)
            MR-01	Systém přebírá jednotlivé obchody a pozice tvořící devizové rezervy ČNB a jejich rozdělení do portfolií z interního informačního systému ČNB.
            MR-02	Systém zajišťuje, že míry durace, value-at-risk a ostatní míry tržního rizika se aktualizují/přepočítávají alespoň jedenkrát denně v určitý předem daný čas.
            MR-03	Systém umožňuje uživateli definovat sub-portfolia sloučením jednotlivých pozic na základě kritérií sestavených z atributů jednotlivých obchodů (např. protistrana, instrument, portfolio, měna, typ cenného papíru, datum vypořádání či trade-date), a k takto definovanému sub-portfoliu vypočítat všechny požadované druhy měr tržního rizika.
            MR-04	Na strategické úrovni systém umožňuje seskupovat jednotlivé pozice do sub-portfolií v souladu s jejich kontextem, s jakým byly obchody uzavřeny (hedging, collateral, pokryté forwardy), a k takto definovanému sub-portfoliu vypočítat všechny požadované druhy měr tržního rizika.
            MR-05	Systém počítá a uživateli zobrazuje duraci a VaR absolutně i relativně vůči benchmarku na všech uvažovaných úrovních, tj.: agregovaná portfolia (seskupení několika portfolií) jednotlivá portfolia sub-portfolia vytvořená podle zvolených kriterií strategická úroveň – sub-portfolia vytvořená seskupením jednotlivých pozic jednotlivé pozice
            MR-06	Systém měří riziko tržní likvidity instrumentů a také portfolií. Na úrovni instrumentů systém poskytuje informaci o pohybu v bid-offer spreadech. Na úrovni portfolia se likviditní riziko počítá v souladu se standardy v oboru dle dostupné odborné literatury.

         2. Vítané

            ID	Popis požadavku	Popis realizace (doplní uchazeč)
            MR-51	Systém zajišťuje, že durace se přepočítává po každém vložení obchodu do systému a po každé změně ceny. Rizikově upravené míry, volatility, směrodatné odchylky, bezrizikové sazby, beta a benchmark se aktualizují/přepočítávají pokaždé, když se změní portfolio nebo benchmark.

      2. Měření durace

         1. Povinné

            ID	Popis požadavku	Popis realizace (doplní uchazeč)
            MR-07	Systém počítá absolutně i relativně vůči benchmarku následující míry rizika: modifikovaná durace Macaulay duration effective duration (u callable a putteble dluhopisů) option adjusted duration spread duration (citlivost ceny bondu na změnu v option-adjusted spread) basis point value basis point value in time buckets convexity option adjusted convexity

         2. Vítané

            ID	Popis požadavku	Popis realizace (doplní uchazeč)
            MR-52	Systém počítá absolutně i relativně vůči benchmarku následující míry rizika: key rate duration duration contribution spread duration contribution (by sector)

      3. Ostatní míry tržního rizika

         1. Povinné

            ID	Popis požadavku	Popis realizace (doplní uchazeč)
            MR-08	Systém počítá následující míry tržního rizika: Greeks

         2. Vítané

            ID	Popis požadavku	Popis realizace (doplní uchazeč)
            MR-53	Systém počítá následující míry tržního rizika: carry z-spread alfa beta

      4. Value-at-Risk

         1. Povinné

            ID	Popis požadavku	Popis realizace (doplní uchazeč)
            MR-09	Systém počítá absolutně a relativně vůči benchmarku následující míry tržního rizika VaR: VaR marginal VaR component VaR
            MR-10	Systém počítá VaR pro úrokové riziko, FX riziko, akciové riziko, spread risk a komoditní riziko (zlato) a agreguje jej na úroveň tržního rizika.
            MR-11	Systém počítá absolutní a relativní VaR za použití parametrické metody (variance-covariance), Monte-Carlo simulace a historické simulace.
            MR-12	Systém uživateli umožňuje v případě parametrické metody výpočtu VaR modifikovat kromě variance-covariance matice následující parametry: confidence level time horizon decay factor volatility figures correlation figures currency
            MR-13	Systém uživateli umožňuje v případě výpočtu VaR metodou Monte-Carlo simulace modifikovat následující parametry: confidence level time horizon decay factor number of estimations method of generating random numbers period of data used
            MR-14	Systém uživateli umořňuje v případě výpočtu VaR metodou historické simulace modifikovat následující parametry: confidence level time horizon decay factor period of data used
            MR-15	Systém importuje variance-covariance matice z dat poskytovatelů cen.

         2. Vítané

            ID	Popis požadavku	Popis realizace (doplní uchazeč)
            MR-54	Systém počítá absolutně a relativně vůči benchmarku následující míry tržního rizika VaR: expected shortfall (conditional VaR) diversified VaR undiversified VaR uncorrelated VaR incremental VaR expected loss

   2. Měření kreditního rizika

      1. Obecné požadavky na měření kreditního rizika

         1. Povinné

            ID	Popis požadavku	Popis realizace (doplní uchazeč)
            CR-01	Systém importuje data potřebná k oceňování kreditního rizika protistran, emitentů a zemí z interního informačního systému ČNB.
            CR-02	Systém počítá kreditní expozici alespoň jedenkrát denně v určitý předem daný čas
            CR-03	Systém umožňuje uživateli sledovat expozici kreditního rizika ve všech úrovních: jednotlivých obchodech jím definovaném sub-portfoliu v portfoliu definovaném na strategické úrovni v portfoliích v agregovaných portfoliích

         2. Vítané

            ID	Popis požadavku	Popis realizace (doplní uchazeč)
            CR-51	Systém pro potřeby výpočtů kreditního rizika importuje z externích zdrojů ratingy protistran, emitentů, zemí a instrumentů.
            CR-52	Systém pro potřeby výpočtů kreditního rizika umožňuje uživateli vložit/změnit ratingy protistran, emitentů, zemí a instrumentů, hodnoty Probability of Default (PDs) a Loss Given Default (LGDs) protistran, emitentů, zemí a instrumentů.
            CR-53	Systém má model měření expozice vůči kreditnímu riziku, který obsahuje: přístup založený na ratinzích kombinovaný s korelačním modelem Monte Carlo simulaci k odhadu rozdělení ztráty z kreditního rizika jedním ze vstupů je matice pravděpodobností přechodů mezi ratingy
            CR-54	Systém počítá kreditní expozici a ostatní míry kreditního rizika při každém vložení nebo změně obchodu.
            CR-55	Systém umožňuje uživateli přepočítat všechny expozice a míry kreditního rizika (vč. kreditního VaR) na požádání.
            CR-56	Systém umožňuje uživateli sledovat míry kreditního rizika ve všech úrovních: jednotlivých obchodech jím definovaném sub-portfoliu v portfoliu definovaném na strategické úrovni v portfoliích v agregovaných portfoliích

      2. Expozice

         1. Povinné

            ID	Popis požadavku	Popis realizace (doplní uchazeč)
            CR-04	Systém měří expozici kreditního rizika vyjádřenou jako tržní hodnota i jako nominální hodnota obchodů.
            CR-05	Systém počítá expozici kreditního rizika jak se zahrnutím kolaterálu do výpočtů tak i bez zahrnutí kolaterálu do výpočtů.

         2. Vítané

            ID	Popis požadavku	Popis realizace (doplní uchazeč)
            CR-57	Systém měří potential future exposure (nebo-li sensitivity of risk) pro deriváty, reverzní repo, margin lending, securities lending/borrowing.
            CR-58	Systém umožňuje uživateli zvolit si simulační metodu (parametrická metoda, historická simulace, Monte Carlo simulace) pro odhad potenial future exposure.
            CR-59	Systém umožňuje uživateli změnit parametry metody pro výpočet potential future exposure před zahájením kalkulace, tj. decay factor, confidence level a time horizon.

      3. Měření kreditního rizika

         1. Povinné

Nejsou

2. Vítané

   ID	Popis požadavku	Popis realizace (doplní uchazeč)
   CR-60	Systém počítá následující míry kreditního rizika: credit VaR expected loss unexpected loss expected shortfall potential dev. of loss probability default založená na kreditním spreadu, kotacích CDS a cenách akcií no. of defaults cost of credit insurance (CDS spread times exposure size) variance of expected loss
   CR-61	Systém umožňuje uživateli před výpočtem měr kreditního rizika změnit následující parametry kalkulace: confidence level migration/default probabilities number of simulations horizon recovery assumptions correlation assumptions spread assumptions corporate action assumptions
   CR-62	Systém počítá ke každému instrumentu nebo emitentovi marginální příspěvek k následujícím mírám kreditního rizika: marginal Credit VaR marginal expected shortfall marginal expected loss

1. Definování limitů a sledování jejich dodržování

1. Obecné požadavky

   1. Povinné

ID	Popis požadavku	Popis realizace (doplní uchazeč)
LC-01	Systém vyjadřuje limit jak v absolutní formě (např. 10 mil. EUR) tak ve formě relativní/parametrické (např. x % z tržní hodnoty portfolia, durace benchmarku +/− 20 %).
LC-02	Limit je vyjádřen minimálně jako: číslo nebo vzorec pásmo kolem nějaké hodnoty vyjádřené v absolutní nebo relativní formě limit vzhledem k benchmarku limit založený na ratingu limit v jiné měně
LC-03	Systém umožňuje definovat limit na jakoukoliv veličinu (např. durace, VaR, tržní hodnota, nominální hodnota) dostupnou v systému.
LC-04	Systém počítá expozici vůči nějakému limitu alespoň jedenkrát denně v určitý předem daný čas.
LC-05	Systém umožňuje definovat limity pro agregovaná portfolia, jednotlivá portfolia, sub-portfolia i jednotlivé obchody, konkrétně na tyto skupiny: instrumentů emitentů protistran limity na mateřskou instituci (může být agregovaná na všech úrovních organizační struktury)

2. Vítané

Nejsou

2. Limity na kreditní riziko

   1. Povinné

      ID	Popis požadavku	Popis realizace (doplní uchazeč)
      LC-06	Systém umožňuje definovat limity na expozici kreditního rizika následujících skupin : protistrana emitent emise counterparty risk zemi settlement risk instrument instrument group

   2. Vítané

      ID	Popis požadavku	Popis realizace (doplní uchazeč)
      LC-51	Systém podporuje následující limity na kreditní riziko: potential future exposure credit VaR (založený na různých modelech výpočtu credit VaR) expected shortfall limits (založený na různých modelech)

3. Limity na tržní riziko

   1. Povinné

      ID	Popis požadavku	Popis realizace (doplní uchazeč)
      LC-07	Systém umožňuje definovat následující limity na tržní riziko a to absolutně i relativně vůči benchmarku: durace basis point value basis point value in time buckets VaR (založený na různých modelech)

   2. Vítané

      ID	Popis požadavku	Popis realizace (doplní uchazeč)
      LC-52	Systém podporuje následující limity na tržní riziko: key rate duration spread duration expected shortfall limits (based on selected models)

4. Limity na likvidní riziko

   1. Povinné

      ID	Popis požadavku	Popis realizace (doplní uchazeč)
      LC-08	Systém umožňuje definovat limity na likviditní riziko (cash flow likvidita). Konfigurace těchto limitů se liší v závislosti na portfoliu nebo typu instrumentu.
      LC-09	Systém měří cash flow likviditu jednotlivých portfolií jako čisté saldo očekávaných cash flow v měně portfolia minimálně týden dopředu po jednotlivých dnech.

   2. Vítané

Nejsou

5. Ostatní limity

   1. Povinné

      ID	Popis požadavku	Popis realizace (doplní uchazeč)
      LC-10	Systém umožňuje definovat limity na následující veličiny: short selling velikost transakcí stop loss obchodníka ratingy datum valuty datum maturity kontrola eligibility na kolaterál přijímaný od protistrany koncentrační limit na emisi koncentrační limit na zemi

   2. Vítané

Nejsou

6. Sledování limitů

   1. Povinné

      ID	Popis požadavku	Popis realizace (doplní uchazeč)
      LC-11	Systém sleduje všechny limity, příslušné expozice, kontroluje dodržování limitů a umožňuje modifikaci nebo import jejich hodnot z interních systémů ČNB.
      LC-12	Systém zobrazuje pouze limity založené na předem definovaných kritériích, např. limity jednoho z následujících typů: instrument/skupina instrumentů emitent/skupina emitentů obchody a jejich kombinace měna země maturita asset class custodian kredit rating sektor grid point

   2. Vítané

Nejsou

7. Varování a zprávy

   1. Povinné

      ID	Popis požadavku	Popis realizace (doplní uchazeč)
      LC-13	Systém přepočítává, aktualizuje a kontroluje všechny limity a expozice alespoň jedenkrát denně v určitý předem daný čas.
      LC-14	Systém zasílá oznámení o překročeném limitu příslušným uživatelům okamžitě poté, co je překročení limitu zjištěno.
      LC-15	Systém zasílá varování o překročení 80 % limitu příslušným uživatelům okamžitě poté, co je toto překročení limitu zjištěno.
      LC-16	Oznámení o překročeném limitu obsahuje všechny relevantní informace, vč. typu limitu, překročeném objemu, příčině překročení, v případě vložení obchodu identifikaci a typ obchodu způsobujícího překročení, obchodníka atp.
      LC-17	V určitou předem danou denní dobu systém zasílá příslušným uživatelům zprávu se seznamem existujících překročených limitech.

   2. Vítané

      ID	Popis požadavku	Popis realizace (doplní uchazeč)
      LC-53	Systém přepočítává, aktualizuje a kontroluje všechny limity a expozice vždy když: do systému byl vložen obchod nebo byl modifikován změní se cena změní se rating importovaná data se změní předdefinovaná skupina je vložena nebo se mění jakákoliv data vstupující do kontroly limitů se změní

8. Kontrola přiměřenosti ceny

   1. Povinné

      ID	Popis požadavku	Popis realizace (doplní uchazeč)
      LC-18	Systém kontroluje přiměřenost ceny, za kterou byl uskutečněn obchod, vůči tržním cenám aktuálním v okamžiku uzavření obchodu alespoň jedenkrát denně v určitý předem daný čas.
      LC-19	Systém umožňuje zadat toleranční pásmo pro ceny vložených obchodů v absolutním i relativním vyjádření vůči tržní ceně.
      LC-20	Systém informuje příslušné uživatele vždy, když cena vloženého obchodu přesáhne povolené pásmo.
      LC-21	Systém umožňuje provést historickou kontrolu cen vložených obchodů vůči uloženým tržním cenám.

   2. Vítané

Nejsou

4. Oceňování instrumentů

   1. Obecné požadavky na oceňování portfolií a instrumentů

      1. Povinné

         ID	Popis požadavku	Popis realizace (doplní uchazeč)
         PR-01	Systém umožňuje importovat ceny jednou nebo víckrát denně z alternativního rozhraní externích poskytovatelů cen ve formě souborů, tj. ze souborů Excel nebo csv.
         PR-02	Systém umožňuje importovat ceny jednou nebo víckrát denně z generického rozhraní externích poskytovatelů cen.
         PR-03	Systém umožňuje uživateli specifikovat, a v případě potřeby modifikovat, jeden nebo více zdrojů cen pro každý instrument (cenný papír, výnosová křivka, FX kurz, akcie) pro potřeby oceňování instrumentu.
         PR-04	Systém umožňuje importovat ke každému instrumentu různé typy cen (tj. bid, mid, ask, closing price, price %, FX Rate, yield, volatility atp.).
         PR-05	Systém importuje ceny pro intra-denní výpočty a kontroly od daných poskytovatelů tržních cen.
         PR-06	Systém umožňuje uživateli vložit cenu instrumentu v různých formátech (tj. cena/výnos, výnos do maturity, diskontní margin, 32nd atp.) a podle konvencí dané měny.
         PR-07	Systém umožňuje uživateli zadat, který zdroj cen se přednostně použije při výpočtech tržní hodnoty portfolia, pozic, limitů a rizikových měr a umožňuje mu změnit tento zdroj dat.

      2. Vítané

Nejsou

2. Skladování cen

   1. Povinné

      ID	Popis požadavku	Popis realizace (doplní uchazeč)
      PR-08	Systém ukládá a archivuje importované ceny jednou nebo vícekrát denně na základě předdefinovaného časového rozvrhu.
      PR-09	Ke každému instrumentu je dostupná právě jedna cena se stejným časem a datumem stažení, důvody stažení, typu (cena, výnos atp.) a zdrojem.
      PR-10	Pokud daný den není poskytovatelem cen dodána nová cena nějakého instrumentu, potom systém uloží cenu z předchozího dne.
      PR-11	Systém zpřístupňuje a zobrazuje uložené ceny uživatelům a umožňuje jim jejich změnu.
      PR-12	Při vkládání a modifikaci cen je aplikován princip kontroly čtyř očí.
      PR-13	Systém uchovává ceny platné za poslední 1,25 roku.

   2. Vítané

Nejsou

3. Kontrola integrity cen

Tato kapitola kvalifikuje/kodifikuje požadavky na správné a nenarušené vztahy mezi jednotlivými záznamy v databázi.

1. Povinné

   ID	Popis požadavku	Popis realizace (doplní uchazeč)
   PR-14	Systém zajišťuje/vytváří/uchovává auditovatelný záznam o změně uložené ceny. Ke každé uložené ceně jsou dostupné informace o tom, kdy byla cena uložena a kdo ji uložil (u automaticky ukládaných cen to může být technický uživatel).
   PR-15	Systém umožňuje uživateli pomocí reportu identifikovat, ke kterému instrumentu není vložena cena.

2. Vítané

Nejsou

4. Kontrola kvality ceny

   1. Povinné

      ID	Popis požadavku	Popis realizace (doplní uchazeč)	Realizováno v referenci (doplní uchazeč)
      PR-16	Systém kontroluje kvalitu uložené ceny, např. porovnáním ceny s její předchozí hodnotou nebo s cenou od jiného poskytovatele.
      PR-17	Systém umožňuje uživateli nastavit kritéria kontroly kvality ceny, tj. šířku pásma maximální povolené odchylky pro každý druh instrumentu.
      PR-18	Systém reportuje výsledek kontroly kvality ceny a identifikuje všechny odlehlé ceny.

   2. Vítané

Nejsou

5. Výpočet výnosové křivky a teoretických cen

   1. Povinné

      ID	Popis požadavku	Popis realizace (doplní uchazeč)
      PR-19	Systém počítá teoretické ceny za použití následujících výnosových křivek: zero coupon libor swaps
      PR-20	Systém počítá výnosové křivky různými metodami, vč. metodou bootstrapping.
      PR-21	Systém interpoluje výnosové křivky různými metodami interpolace, vč. lineární interpolace.

   2. Vítané

      ID	Popis požadavku	Popis realizace (doplní uchazeč)
      PR-51	Systém počítá teoretické ceny za použití následujících výnosových křivek: swap other curves derived from bond prices, money market futures, forwards
      PR-52	Systém počítá výnosové křivky různými metodami, vč. následujících: download of a curve plus interpolation Xxxxxx-Xxxxxx Xxxxxx-Xxxxxx-Svensson method
      PR-53	Systém interpoluje výnosové křivky různými metodami interpolace, vč. etně: cubic spline geometrická interpolace

6. Oceňování

   1. Povinné

      ID	Popis požadavku	Popis realizace (doplní uchazeč)
      PR-22	Systém používá různé druhy metod oceňování, včetně: mark-to-market (on value or trade date) present value method (e.g. zero-coupon, yield to maturity) mark-to-model (e.g. Black Xxxxxxx) amortised prices
      PR-23	Systém oceňuje metodou trade date.
      PR-24	Systém počítá teoretickou cenu instrumentu pomocí jemu přiřazené výnosové křivky a spreadu alespoň jedenkrát denně v určitý předem daný čas.
      PR-25	Při oceňování instrumentu systém umožňuje uživateli výběr mezi teoretickou cenou a mark-to-market cenou, je-li dostupná.
      PR-26	Při oceňování instrumentu formou mark-to-market systém umožňuje uživateli výběr, zda se má v případě chybějící tržní ceny doplnit teoretická cena nebo cena z předchozího dne.
      PR-27	Systém pracuje s nezainvestovanými finančními prostředky a umožňuje je zahrnout do výpočtů měření rizika, výkonnosti a oceňování portfolia.

   2. Vítané

ID	Popis požadavku	Popis realizace (doplní uchazeč)
PR-54	Systém oceňuje metodou value date.

5. Měření výkonnosti a atribuční rozklad výnosů

   1. Obecné požadavky

      1. Povinné

         ID	Popis požadavku	Popis realizace (doplní uchazeč)
         PL-01	Systém počítá výnosy metodou časově váženého měření výnosu (Time Weighted (rate) of Return (TWR) method) podle standardu GIPS (Global Investment Performance Standards) pro zpracování extrních cash flows (z hlediska portfolia) na denní bázi, a to jak v absolutním tak i relativním vyjádření. Výnos pro delší období (týdně, měsíčně, ročně a mezi jakýmikoliv daty) je založen na geometrickém výpočtu denních výnosů.
         PL-02	Systém počítá výnosy a výkonnost pro instrumenty, sub-portfolia, portfolia, agregovaná portfolia a benchmark alespoň jedenkrát denně v určitý předem daný čas.
         PL-03	Systém počítá výnosy a výkonnost portfolií v měně portfolia a v CZK.
         PL-04	Systém nemusí zahrnovat náklady na obchod do výpočtů výnosů a výkonnosti.
         PL-05	Systém zahrnuje stržené daně do výpočtů výnosů a výkonnosti.

      2. Vítané

         ID	Popis požadavku	Popis realizace (doplní uchazeč)
         PL-51	Systém používá také metodu MWR (Money Weighted Return) podle standardu GIPS pro výpočet absolutních a relativních výnosů.

   2. Měření výkonnosti

      1. Povinné

         ID	Popis požadavku	Popis realizace (doplní uchazeč)
         PL-06	Systém počítá výkonnost portfolia, což odpovídá relativnímu výnosu portfolia vůči benchmarku počítanému jako rozdíl mezi výnosem portfolia a výnosem benchmarku, v absolutním i procentním vyjádření.
         PL-07	Systém umožňuje uživateli zobrazit výsledky výpočtu výkonnosti výběrem následujících parametrů: instrument, sub-portfolio, portfolio, agregované portfolio benchmark datum měna

      2. Vítané

         ID	Popis požadavku	Popis realizace (doplní uchazeč)
         PL-52	Systém počítá rizikově upravené míry výnosů, včetně: return standard deviation (také annualisovaně) beta tracking error (také annualisovaně) alpha (také annualisovaně) R-squared information ratio xxxxxx ratio Modigliani-Modigliani Treynor ratio Xxxxxx'x alpha
         PL-53	Systém počítá downside risk a upside risk portfolia, včetně: Xxxxxxx ratio Omega ratio Upside potential ratio

   3. Backtesting

      1. Povinné

         ID	Popis požadavku	Popis realizace (doplní uchazeč)
         PL-08	Systém vykonává backtesting měr tržního rizika, jako jsou VaR, volatility a korelace použité k hypotetickým výnosům.
         PL-09	Systém reportuje o výsledcích backtestingu.

      2. Vítané

Nejsou

4. Atribuční rozklad výkonnosti

   1. Povinné

      ID	Popis požadavku	Popis realizace (doplní uchazeč)
      PL-10	Systém měří absolutní a relativní expozici vůči benchmarku pro všechny datumy, klíčové splatnosti (key rates) výnosové křivky, instrumenty, měny, portfolia a sub-portfolia.
      PL-11	Systém umožňuje definovat ke každému portfoliu referenční výnosovou křivku, vůči které se bude měřit spread.
      PL-12	Systém provádí rozklad následujících tržních efektů: změna sazeb: durace (paralelní posun) vůči výnosům referenční výnosové křivky, kreditní spread vůči referenční křivce, spread země vůči referenční křivce a vliv konvexity. carry (time decay effect, roll-down, cross and alternative costs effect carry credit spread and carry government effect)
      PL-13	Systém provádí rozklad vlivu změny sazeb výnosové křivky, tj. vliv změny úrovně, sklonu a hrbolu.
      PL-14	Systém provádí rozklad intradenních efektů na výkonnost, které pramení z intradenních aktivit porovnáním obchodních cen s oceňovacími cenami na konci dne, následovně: intraday rebalancing effect – v dny rebalancingu se objevuje podobný efekt jako na konci dne při porovnávání obchodních cen a oceňovacích cen intraday rest effect – vyskytuje se v ostatních dnech
      PL-15	Systém počítá zbytkovou výkonnost způsobenou: výběrem instrumentu šumem modelu
      PL-16	Systém počítá kurzové vlivy a vliv aktiv pro více-měnová portfolia nebo agregovaná portfolia.
      PL-17	Systém počítá atribuční rozklad na denní bázi
      PL-18	Systém provádí rozklad následujících tržních efektů: akcie regiony, země a sektory fixed income versus akcie cenový vliv dividendové výnosy intraday securities lending
      PL-19	Systém agreguje výsledky denního fixed income atribučního rozkladu do jakéhokoliv období (např. týden, měsíc, čtvrtletí, rok a jiné) za použití zdokumentovaných mechanizmů, např. geometric attribution, dollar attribution, Xxxxxx, Manchero or Frongello smoothing algorithms.

   2. Vítané

      ID	Popis požadavku	Popis realizace (doplní uchazeč)
      PL-54	Systém provádí rozklad vlivu kreditního spreadu na jednotlivé sektory nebo sub-sektory, přičemž pro každé portfolio může být definována jiná skupina sub-sektorů.
      PL-55	Systém zahrnuje do atribučního rozkladu výkonnosti nerealizované P&L pro deriváty.
      PL-56	Systém agreguje výsledky denního akciového atribučního rozkladu do jakéhokoliv období (např. týden, měsíc, čtvrtletí, rok a jiné) za požití zdokumentovaných mechanizmů, např. Multi-currency Karnosky a Singer 'geometric multi-currency' model.

1. Definice benchmarku

   1. Obecné požadavky

      1. Povinné

         ID	Popis požadavku	Popis realizace (doplní uchazeč)
         BM-01	Systém udržuje in-house benchmarky a benchmarky založené na upravených indexech (např. o spread), cenových indexech nebo jejich kombinaci.
         BM-02	Systém umožňuje uživateli měnit váhy jednotlivých komponent benchmarku.
         BM-03	Při změně benchmarku systém aktualizuje všechny pozice, limity a rizikové míry. Při případném překročení limitů systém generuje report o technickém překročení limitů způsobeném změnou benchmarku.

      2. Vítané

Nejsou.

2. In-house benchmarky

   1. Povinné

      ID	Popis požadavku	Popis realizace (doplní uchazeč)
      BM-04	Systém udržuje benchmarky složené z instrumentů používaných při správě DR.
      BM-05	Systém umožňuje tvorbu cash flows v benchmarkovém portfoliu, aby benchmark obsahoval změnu ve velikosti aktuálního portfolia.
      BM-06	Systém udržuje minimálně dva typy benchmarků: plně reinvestovaný benchmark (re-investice kupónů a zmaturovaných instrumentů) benchmark bez reinvestic

   2. Vítané

Nejsou.

3. Indexové benchmarky

   1. Povinné

      ID	Popis požadavku	Popis realizace (doplní uchazeč)
      BM-07	Systém importuje indexy od externích poskytovatelů tržních dat, aby mohly být vytvořeny a udržovány benchmarky založené na tržních indexech.
      BM-08	Systém zobrazuje detailní složení indexového benchmarku na indexy a jednotlivé cenné papíry.
      BM-09	Systém automaticky realizuje všechny transakce potřebné při rebalancingu indexového benchmarku.

   2. Vítané

Nejsou.

7. Analýza a simulace portfolií

   1. Simulace tržního a kreditního rizika a stress testing

      1. Povinné

         ID	Popis požadavku	Popis realizace (doplní uchazeč)
         AN-01	Systém umožňuje uživateli konfigurovat citlivostní testy určující dopad okamžité změny jednoho nebo více rizikových faktorů na tržní riziko (např. změna výnosové křivky, spreadu, kurzů, volatilit).
         AN-02	Systém umožňuje uživateli konfigurovat multi-period stress test scénáře daných rizikových faktorů, aby se určil potenciální budoucí vývoj portfolia v tomto časovém horizontu.
         AN-03	Systém importuje potřebná tržní data od externích poskytovatelů, aby mohl vytvořit scénáře historických stress testů.
         AN-04	Systém počítá odliv hotovosti za podmínek daných stress testy a umožňuje uživateli třídit instrumenty do likvidních kategorií (vysoce likvidní, nelikvidní, likvidní v nějakém maximálním objemu za den bez dodatečných nákladů).

      2. Vítané

         ID	Popis požadavku	Popis realizace (doplní uchazeč)
         AN-51	Systém umožňuje uživateli konfigurovat citlivostní testy určující dopad okamžité změny jednoho nebo více rizikových faktorů na kreditní riziko (např. pravděpodobnosti defaultu, korelace v přechodové matici, loss-given default).
         AN-52	Systém podporuje reverzní stress test portfolia nebo agregovaného portfolia pro vybrané rizikové faktory a danou cílovou funkci (např. ve smyslu hodnoty nebo poklesu hodnoty).
         AN-53	Systém obsahuje relevantní množinu scénářů historických stres testů pro tržní a kreditní riziko, založených na extrémních minulých událostech na finančních trzích.

   2. Udržování časové řady a export

      1. Povinné

         ID	Popis požadavku	Popis realizace (doplní uchazeč)
         AN-05	Systém umožňuje vytváření časových řad určením rozsahu datumů, typem dat a hodnot absolutních nebo relativních vůči benchmarku.
         AN-06	Systém vytváří časové řady z parametrů portfolií, rizikových parametrů, výkonnosti a atribučního rozkladu výkonnosti, vč. celkových nebo částečných součtů založených na všech typech dat použitých k agregování instrumentů do portfolia.
         AN-07	Systém umožňuje uživateli vytvářet časové řady ze všech dat v systému, včetně: údaje o pozici transakční údaje míry tržního rizika míry kreditního rizika výnosové křivky výsledky oceňování výnosy tržní data (např. ceny) limity
         AN-08	Systém umožňuje uživateli monitorovat časové řady po instrumentech, portfoliích, sub-portfoliích, měnách, emitentech, maturitách a jiných typech kategorií v závislosti na portfoliu.
         AN-09	Systém umožňuje uživateli monitorovat časové řady následujících parametrů portfolií za libovolné období a to jak absolutně, tak i relativně vůči benchmarku. nominální objem tržní hodnota účetní hodnota tržní cena rizikové míry (např. modifikovaná durace pro fixed income) absolutní a relativní VaR spread duration basis point value (BPV) basis point value in time buckets výkonnost atribuční rozklad výkonnosti limity
         AN-10	Systém exportuje všechny časové řady v různých formátech (minimálně csv).

      2. Vítané

Nejsou.

8. Operační riziko

   1. Obecné požadavky

      1. Povinné

         ID	Popis požadavku	Popis realizace (doplní uchazeč)
         OR-01	Systém rozlišuje obecného uživatele od risk managera a umožňuje ke každému uživateli přidělit organizační útvar s rozlišením na jednotlivé referáty (business area).
         OR-02	Systém uživateli umožňuje vkládat údaje o události operačního rizika.
         OR-03	Systém umožňuje risk managerovi kategorizaci událostí a určit, které organizační útvary provedou výpočet nákladů spojených s událostí a rozhodnutí o akčním plánu.
         OR-04	U jednotlivých událostí systém umožňuje ukládat následující kategorie: druh události příčina události proces, ve kterém se událost stala (business line)
         OR-05	Systém umožňuje uživateli uložit výsledek výpočtu nákladů spojených s událostí.
         OR-06	Systém umožňuje uživateli uložit výsledek rozhodnutí o akčním plánu a v případě pozitivního výsledku také konkrétní údaje o akčním plánu.
         OR-07	Systém umožňuje vložit údaje o identifikovaných operačních rizicích, např. v rámci procesu control-self-assessment, vč. odhadu frekvence jejich výskytu (inherentní i zbytková) a finančního dopadu (založeného např. na worst case scenario).
         OR-08	Systém generuje týdenní zprávu o operačním riziku složenou z nových, otevřených, nevyřízených událostí, nedokončených akčních plánech, identifikovaných rizicích a vybraných key risk indikátorech.

      2. Vítané

Nejsou.

9. Rámcový rozsah spravovaných portfolií

Následující tabulka obsahuje základní informace o portfoliích, která budou systémem spravována v době implementace (v dalším období budou uvedené počty kontinuálně stoupat), a přibližné hodnoty některých jeho parametrů:

Požadovaná frekvence reportování	denně
Počet portfolií (interně / externě spravované)	22 (7/15)
Počet otevřených pozic v jednom portfoliu (neagregováno přes cenné papíry)	1 000
Počet agregovaných portfolií	16
Počet měn	7

Následující tabulka uvádí seznam požadovaných nástrojů a jejich přibližné zastoupení ve všech portfoliích v typickém případě:

Instrument	# pozic	# cen. papírů	Objem [$ mil.]
Nákup, prodej – Bond, Bill (pouze vládní)	3 600	260	27 000
Nákup, prodej – Certificate of Deposit	10	10	200
Nákup, prodej – Commercial Paper	10	10	200
Nákup, prodej – Inflační linkery	10	10	200
Repo a triparty repo-operace	100	100	5 000
Depozita a zlatá depozita	10	10	200
Forex – Spot, Forwards a FX Swap	100	100	1 500
Fixed Income Futures	4	4	400
Interest Rate Swap	10	10	1 000
Cross Currency Swap	4	4	400
Equity Swap	4	4	400
Options	4	4	400

10. Seznam pojmů

Termín	Definice
Alfa	Rizikově upravená míra výnosnosti investice. Měří se jako dodatečný výnos nad predikci modelů jako je např. CAPM (Capital asset pricing model).
Beta	Míra korelace akcie nebo portfolia akcií s celým akciovým trhem. Pro jednoduchost se jako benchmark používá tržní index (např. S&P 500).
Basis point value	BPV, neboli „Price Value of a basis Point“ (PVBP), je hodnota, o kterou portfolio klesne nebo vzroste, při paralelní změně křivky úrokových sazeb o jeden basis point (0,01 %).
Basis point value in time buckets	Hodnota, o kterou se změní hodnota cenného papíru/portfolia, při změně úrokové sazby v dané splatnosti o 1 basis point.
Carry	Výnos cenného papíru/portfolia pocházející z držení cenného papíru po určitý časový úsek za předpokladu, že se nezmění cena ani úrokové sazby.
Component VaR	Měří změnu VaR portfolia, jestliže danou pozici zrušíme.
Conditional VaR	viz Expected shortfall
Credit VaR	Míra kreditního rizika pocházející ze změn v kreditní kvalitě aktiva (např. default, změna ratingu) používající míru spolehlivosti a časový horizont.
Diversified VaR	VaR portfolia zohledňující diverzifikační efekty portfolia přes všechny druhy aktiv (FX, IR, kredit...).
Xxxxxx	Xxxx citlivosti cenného papíru/portfolia na změnu úrokových sazeb.
Effective duration	Xxxxxx vypočtená pro dluhopisy se zabudovanou opcí.
Expected loss	Průměrná ztráta z poklesu tržní ceny aktiva pocházející z kreditní události během investičního horizontu.
Expected shortfall	Neboli conditional VaR (CVaR) – míra potenciální ztráty portfolia v případě, že ztráta je větší než VaR. Zohledňuje tvar distribuční funkce výnosů portfolia, zvlášť tzv. fat tail.
Greeks	Citlivost opcí na různé rizikové faktory, na kterých je závislá cena opce, vyjádřené tradičně řeckými písmeny.
Incremental VaR	Měří změnu VaR portfolia po přidání nové pozice, rovná se rozdílu VaR portfolia s pozicí mínus VaR portfolia bez pozice.
Information ratio	Měří schopnost správce portfolia generovat dodatečný výnos relativně vzhledem k benchmarku s ohledem na to, jak blízko sleduje benchmark; je vyjádřena jako podíl nadvýnosu a tracking error.
Xxxxxx'x alpha	Měří dodatečný výnos portfolia nad jeho teoreticky očekávanou hodnotou.
Key rate duration	Míra citlivosti hodnoty cenného papíru/portfolia vyjádřená v procentech na změnu úrokové sazby v dané splatnosti o 1 %, za předpokladu, že ostatní sazby výnosové křivky ve všech splatnostech zůstanou konstantní.
Konvexita	Měří změnu durace v závislosti na paralelní změně úrokových sazeb výnosové křivky, vliv na změnu hodnoty portfolia druhého řádu.
Xxxxxxxx duration	Vážený průměr časů do výplaty dluhopisu. Váhy každého cash flow jsou dány podílem jeho současné hodnoty a ceny dluhopisu.
Marginal VaR	Udává, o kolik se zvětší VaR portfolia, jestliže se přidá dodatečný dolar k dané pozici.
Modifikovaná durace	Vyjadřuje procentní změnu v hodnotě cenného papíru v případě paralelní změny úrokových sazeb o 1 %.
Modigliani-Modigliani	Míra rizikově upravených výnosů portfolia, která zohledňuje odchylku portfolia vzhledem k benchmarku.
Option adjusted duration	Xxxxxx vypočtená pro dluhopisy se zabudovanou opcí.
Option adjusted convexity	Konvexita vypočtená pro dluhopisy se zabudovanou opcí.
Option-adjusted spread	Pokud má bond opcionalitu, OAS vyjadřuje spread, za který by se bond pravděpodobně obchodoval nad benchmarkem, kdyby tuto opcionalitu neměl.
Relative VaR	VaR po zohlednění výnosů benchmarku.
Xxxxxx ratio	Míra dodatečného výnosu nad benchmark vzhledem k přijímanému riziku; měří se jako podíl nadvýnosu a směrodatné odchylky výnosů portfolia.
Spread duration	Citlivost ceny bondu na změnu jeho option-adjusted spreadu o 100 bp.
Trade date valuation method	In the trade date method the market value already on the trade date is equal to the value of the position side of the transaction, and consequently, the cash flow term on the trade date is equal to the settlement payment. Thus, the trade date method can be seen as trading with immediately delivery and payment.
Trade date approach	In the trade date approach for return calculations, financial instruments are included in the instrument and portfolio valuation on the date the trader agrees the transaction, as opposed to the date they are settled, or exchanged for cash.
Tracking error	Ukazuje, jak těsně sleduje portfolio svůj benchmark. Měří se standardní směrodatnou odchylkou rozdílů mezi výnosy portfolia a benchmarku.
Treynor ratio	Měří výnos získaný dodatečně nad bezrizikovou investici (úplně diverzifikované portfolio) vzhledem k dodatečně přijímanému riziku (beta).
Uncorrelated VaR	Při výpočtu se zanedbávají korelace mezi tržními veličinami, tj. všechny korelace jsou nastaveny na nulu. Umožňuje měřit, jak by se snížilo riziko, kdyby bylo portfolio dokonale diverzifikováno.
Undiversified VaR	Na rozdíl od diversified VaR, součet jednotlivých VaR přes jednotlivá aktiva, neboli VaR portfolia, které nemá krátké pozice a všechny korelace mezi aktivy jsou rovny jedné.
Unexpected loss	Xxxxxxx ztráta z poklesu tržní ceny aktiva přesahující průměr na určité úrovni spolehlivosti.
Value date valuation method	In the value date method the market value during the period between trade and value date is the netted value of the position and the settlement payment. On the value day the cash flow term is equal to the settlement payment and the market value is equal to the value of the position side.
VaR	Var (Value at Risk) je definovaný jako hodnota, kterou překročí ztráta portfolia během daného časového horizontu s danou pravděpodobností.
Z-spread	Spread konstantní podél celé výnosové křivky státních dluhopisů, jehož přičtením se současná hodnota cash-flow cenného papíru rovná jeho tržní ceně.

Příloha č. 2

TECHNICKÉ ZADÁNÍ

INFORMAČNÍHO SYSTÉMU RiskMS A ORGANIZAČNÍ STANDARDY

1. Úvod

V této části jsou popsány jednotlivé komponenty standardního systémového prostředí ČNB a dále jsou specifikovány požadavky na implementaci systému RiskMS do tohoto prostředí.

1. Přehled systémového prostředí ČNB

Systém RiskMS musí podporovat standardní systémové prostředí ČNB a musí být snadno do tohoto prostředí implementovatelný.

Serverová část:

Serverová část systému RiskMS (databáze či aplikační server) bude provozována na operačním systému MS Windows Server 2008 R2 (Standard či Enterprise Editon) nebo RedHat Enterprise Linux 5. Tyto uvedené operační systémy jsou provozovány na standardní HW platformě x86/x64 serverů (obvykle značek HP a DELL typu např. HP DL380G7 či DELL PowerEdge R710) nebo jsou provozovány ve virtualizovaných verzích na platformách VMWare vSphere server 4.x nebo Oracle VM 3.x.

• Monitoring standardních serverových platforem a sběr logů je zabezpečen systémem MS SCOM 2007 SP1.

• Standardní platformy jsou pravidelně skenovány na zranitelnosti systémem QUALYS.

Databázová platforma:

Standardní databázová platforma ČNB je postavena na databázi ORACLE, pro jejíž správu má ČNB své vyškolené specialisty a navíc je možné využít Oracle nadstavbu Oracle Business Intelligence 10g Enterprise Edition pro tvorbu sestav.

Databázově servery:

• Oracle RDBMS 11g Standard Edition (Enterprise jen v nutných případech)

• Protokol Oracle Net

Aplikační a WWW servery:

• Oracle Web Logic Server 11,

Klientská část:

Klientská část systému RiskMS musí být provozovatelná jako tzv. plná/„rich“ Windows aplikace (MS Windows XP + SP3 + Office 2003 SP3) nebo jako webový klient za využití MS IE8.

V současné době v ČNB probíhá nasazení nové verze klientské stanice založené na platformě MS Windows 7 Pro + MS Office 2010 Professional. Předpokládaný termín dokončení realizace je konec roku 2013. Z tohoto důvodu:

• Klientská část aplikace/systému RiskMS musí být instalovatelná a provozovatelná na fyzickém PC s MS Windows 7 + Office 2010 Professional.

• Poněvadž v ČNB také jako součást upgradu klientské stanice probíhá její migracetaké za využití klientské virtualizace založené na publikovaném desktopu prostřednictvím Citrix XenApp 6.5 na MS Windows 2008 Serveru R2, je velice žádoucí, aby klientská část aplikace/systému RiskMS byla instalovatelná a provozovatelná také v tomto prostředí / platformě.

Konfigurace standardní klientské stanice:

• MS Windows XP Professional Eng., cp 1250, Service Pack 3 (operační systém) + aktuální aktualizace

  • v budoucnu se počítá s MS Windows 7Professional nebo virtuálním desktopem (Citrix Xenpp 6.5 an MS Windows Serveru 2008 R2)

• TCP/IP síťové služby (DHCP klient, SNMP klient)

• MS Office 2003 Eng. Standard (je možno nasadit i Professional) + Service Pack 3 – sada kancelářského SW obsahující textový editor "MS Word", tabulkový editor "MS Excel", prezentační program "MS PowerPoint", klient elektronické pošty a plánovač "MS Outlook"

  • V budoucnu bude standardem MS Office 2010 Professional Plus

• MS Access Runtime 2003 (v případě edice Office Professional i plná verze Accesu)

  • v budoucnu se počítá s MS Office 2010 Professional Plus

• MS Internet Explorer 8 Eng. (aktuální SP)

  • V budoucnu se počítá s MS XX0 či 10.

• Adobe Acrobat Reader X Eng. – prohlížeč souborů ve formátu PDF

• Symantec Endpoint Protection

Instalace další provozní platformy na klientskou stanici není preferována. 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).

Není přípustné ukládat na klientskou stanici 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).

Přístupová práva na klientských stanicích odpovídají defaultnímu nastavení od firmy Microsoft po instalaci MS Windows XP Professional. 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 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 pracuje uživatel standardně pod právy přidělené skupině „Users“.

Při realizaci informačního systému je nutné zajistit, aby programové komponenty realizovaného IS nebyly v rozporu s komponentami dalších provozovaných IS. Realizovaný IS tedy musí být provozovatelný v systémovém prostředí ČNB a současně nesmí narušovat funkčnost ostatních IS.

Síťová konektivita:

• Klientské stanice připojeny rychlostí typicky 100 Mbsec-1 100Base-T

• Servery připojeny typicky rychlostí 1 Gb 1000Base-T

• Mezi servery a klientskými stanicemi pouze L3 konektivita, mezi servery možná L2 nebo L3 konektivita

• Adresace dle RFC 1918 (10.x.y.z)

• Plně přepínaná síť s redundantním jádrem

Zálohování dat:

Zálohování informačních systémů a dalších dat je v ČNB řešeno centrálně. Zálohována jsou pouze data uložená na centrálních kapacitách ve správě sekce informatiky. Pro zálohování je určen zálohovací systém HP Data Protektor 6.0 nebo vyšší.

Archivace dat:

Pro ukládání archivních dat a výstupních dokumentů IS je určen elektronický archivační systém IBM OnDemand/TSM. Umožňuje ukládat data v podobě dokumentů MS Office, souborů vytvořených ve standardním prostředí, výstupních sestav IS. Archivační systém umožňuje manuální i automatizované ukládání dat, indexaci ukládaných objektů a řízený přístup uživatelů. Archivační systém je postaven na produktu IBM - OnDemand 8.4.1.4, TSM 5.5.0.2

Funkcionalita Single Sign-On:

U IS ČNB je standardně realizována funkce Single Sign-On s využitím služby Microsoft Active Directory – MS AD (autentizační protokol Kerberos). Tj. uživatel se přihlašuje pouze jednou do své klientské stanice, při vyvolání aplikací již pak není jméno/heslo či identifikace uživatele požadována.

Řízení rolí a přístupu uživatelů:

Standardně je ke všem funkcím, programovému vybavení či službám systémového prostředí a obvykle i DB rolím řízen přístup prostřednictvím interně vyvinuté aplikace (aplikace nad DB Oracle), která uchovává seznam uživatelů a jejich skupin a tyto informace jsou pak propagovány např. do Active Directory nebo zpřístupnění přes LDAP z Active Directory či z tabulek aplikace 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živatelé či účty jejich klientských stanic a tím jsou jim i dané komponenty či funkce systémového prostředí ČNB zpřístupněny.

2. Vazby na externí zdroje a služby systémového prostředí

Systém RiskMS musí dále umožnit propojení na  následující provozované IS a služby systémového prostředí:

Název systému	Popis integrace
ISFO	Interně vyvinutý informační systém ČNB sloužící pro evidenci a vypořádání všech uzavřených obchodů v rámci správy devizových rezerv ČNB. Nyní je databáze aplikace provozována v DB Oracle 11.2.x na platformě RHEL 5.
MS Exchange 2010 (MS Outlook 2003/2010)	Systém pro e-mailové notifikace (rozhraní elektronické pošty). Případně je možné využít komunikaci se standardním MTA (sendmail) za využití protokolu SMTP.
AD Windows domény	Windows doména založená na platformě MS Windows Server 2008 R2, autentizační protokol Kerberos – využití pro Single Sign-On
Bloomberg	Externí poskytovatel dat

Rozhraní interní informační systém ISFO je tvořeno jako databázové pohled (či pohledy) - View(s) - nad tabulkami databáze Oracle, které ve sloupcích obsahují údaje o statických datech ( země, protistrany, účty, uživatelé, kalendáře ), aktivech ( měny, cenné papíry, kovy, deriváty ) , cenách a uzavřených obchodech.

3. Bezpečnost

V souvislosti s bezpečnostní politikou informačních systémů musí být systém RiskMS zabezpečen proti hrozbám ohrožujícím jeho dostupnost, důvěrnost, integritu a auditovatelnost.

Bezpečnostní požadavky jsou uvedeny v následující tabulce:

Požadavek	Jeho realizace
Dostupnost	5 x 10 hodin 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	databázová transakce
Autentizace	Primárně užitím čipové karty, alternativně jménem a heslem OS Windows (SSO ve spolupráci s Active Directory),
Prokazatelnost	personifikovaná databázová seance (Oracle), záznam v audit 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), je nutno je odstranit a to formou aplikací patchů či doporučeným workaroundem. Systém RiskMS tam musí počítat s kontinuálním procesem patchování jeho komponent – není možné v řádu týdnů až měsíců oddalovat aplikaci bezpečnostních patchů z důvodu potenciální nefunkčnosti systému RiskMS po jejich aplikaci.

.

K serverům a na nich instalovaným aplikacím není externím subjektům povolen vzdálený přístup!

V případě poruch či vyřazování výpočetní techniky se disky obsahující interní data bezpečně mažou (např. v magnetické peci) nebo se nevracejí vůbec.

4. Standardy

Od systému RiskMS je požadováno, aby při jeho implementaci byly respektovány interní předpisy ČNB v oblasti IS/IT (zejména – Pokyny o rozvoji IT/IS v ČNB, Pokyny o provozování a správě produktů a služeb IS/IT v ČNB, Pokyny o bezpečnostní politice ČNB v oblasti IT).

5. Technické požadavky

   1. Obecné požadavky

      1. Povinné

         ID	Popis požadavku	Popis realizace (doplní uchazeč)
         OBE-PO-00	Systém RiskMS musí podporovat standardní systémové prostředí ČNB a musí být snadno do tohoto prostředí implementovatelný. Pokud systém RiskMS používá i jiné komponenty než obsahuje standardní systémové prostředí ČNB, je uchazeč povinen zajistit potřebné licence a provozní podporu (oprava chyb, patchování, provozní monitoring a kapacity management) těchto doplňovaných komponent.
         OBE-PO-01	Systém RiskMS bude navržen a implementován pro konkurenční možnost užívání 7 uživatelů z maximálního počtu 20. V případě přístupu administrátorů do systému RiskMS nesmí být výše uvedené počty uživatelských licencí čerpány těmito administrátorskými přístupy. Pokud se zadavatel rozhodne rozšířit okruh uživatelů systému RiskMS a nakoupí příslušné SW licence, navýší se počet konkurenčních přístupů k aplikaci a zároveň maximální počet uživatelů, kteří budou moci aplikaci současně využívat.
         OBE-PO-02	Pro návrh výpočetní kapacity uchazeč použije v ČNB standardně používané servery (viz kapitola 1.1, Serverová část) s tím, že servery budou mít tyto parametry: server v rackovém provedení o velikosti 2U (typicky HP Proliant DL380/385Gen8 či DELL PowerEdge R720), 4 roky záruky, Režim podpory „fix NBD“, aktivní port pro vzdálenou správu (ILO či iDRAC) umožňující instalaci serverů přes tento port z virtuální CD/DVD mechaniky, redundantní osazení napájecími zdroji a větráčky, potřebnou velikost RAM a HDD s tím, že HDD budou zapojeny do vhodné RAID skupiny (např. RAID1,5). Mimo serverů výše uvedených je povolena výpočetní kapacita ve formě appliance, která bude plně pod správou uchazeče (instalace, údržba, kapacity a change management). I v tomto případě platí délka záruky 4 roky a oprava v režimu „fix NBD“. ČNB (Objednatel) nabízí Poskytovateli k využití z jeho interních kapacit pro zabezpečení potřebné výpočetní kapacity 2 instance virtuálního serveru na platformě VMware (viz též požadavek ROZ-PO-52), kdy nabízený stroj v ČNB pro aplikační potřeby systému RiskMS může disponovat následující maximální konfigurací: CPU 2x vCPU (3GHz) RAM max 12 GB HDD OS: 32 GB HDD swap: 16 GB HDD data: 100 GB Pro zajištění migrace virtuálního stroje do záložního výpočetního střediska je možno využít funkcionalitu SRM. Současně se serverovou kapacitou je k serveru dispozici licence operačního systému MS Windows Server 2008 R2 (kryto licencí edice Datacenter) či Red hat Enterprise Linux 5. Pokud je nabízený systém RiskMS postaven na databázi Oracle Standard Edition (viz též vítaný požadavek SYS-PO-51) a systém je určen pro interní uživatele zadavatele (viz požadavek OBE-PO-01) a systém RiskMS je provozován na serverech s maximálně dvěma procesorovými paticemi (dle požadavku OBE-PO-02), tak potřebnými licencemi databáze Oracle Standard Edition již disponuje zadavatel a uchazeč je nedodává. Pokud je pro provoz systému RiskMS vyžadována databáze Oracle Enterprise Edition či databáze jiných výrobců (nebo použití option, které jsou možné pouze u Oracle Enterprise Edition), pak uchazeč musí jako součást dodávky dodat i potřebný počet licencí této edice databáze (pravděpodobně CPU licence). Kapacita musí být navržena tak, aby splňovala požadavek OBE-PO-05!
         OBE-PO-03	Poskytovatel akceptuje technické zadání s požadavky na integraci realizovaného systému RiskMS do standardního systémového prostředí ČNB a garantuje provoz informačního systému ve specifikovaném standardním systémovém prostředí ČNB. Pokud bude nezbytné využít SW produkty a službu nad rámec standardního systémového prostředí, poskytovatel musí zajistit technickou a uživatelskou podporu systémového prostředí tak, aby jej bylo možno provozovat bez nutnosti zásahů a specielních znalostí technické správy ČNB.
         OBE-PO-04	Při návrhu nabídky, postupu implementace atd. musí poskytovatel svou nabídku koncipovat tak, že bude počítat s limitovanými kapacitami objednatele, které může vyhradit pro tvorbu realizační studie, implementaci systému RiskMS a jeho ověřovací provoz. V oblasti věcné (viz kapitola 2 přílohy č. 1 této smlouvy) je možno využít kapacity v maximálním rozsahu 120 čld implementace (tj. cca 10% kapacity po dobu 15 měsíců) a 60 čld testování. V oblasti technické (instalace a vazby na systémové prostředí ČNB a interní zdroje dat) je možno využít maximálně 100 čld.
         OBE-PO-05	Systém RiskMS a implementovaná výpočetní kapacita (poskytovatele či nabízená objednatelem) a procesy spojeného s jeho správou musí být koncipovány tak, aby bylo v případě úplného výpadku tohoto systému obnovit jeho funkčnost do 2 pracovních dnů a to jak v místě instalace, tak i v lokalitě záložního pracoviště. Zprovoznění obnoví data do stavu platného v den před vlastním úplným výpadkem systému RiskMS.

      2. Vítané

Nejsou

2. Podpora standardního systémového prostředí ČNB

   1. Povinné

      ID	Popis požadavku	Popis realizace (doplní uchazeč)
      SYS-PO-01	Klientská část systému RiskMS musí být provozuschopná ve standardním systémovém prostředí ČNB.
      SYS-PO-02	Bezobslužná instalace klientské části systému RiskMS – pokud se klientská část systému RiskMS instaluje na klientské stanice, pak musí existovat možnost bezobslužné instalace klienta na dálku, nejlépe prostřednictvím GPO a MSI.
      SYS-PO-03	Serverová část musí podporovat následující komponenty standardního systémového prostředí ČNB serverové operační systémy, síťová komunikace, mailová komunikace, aplikační a www servery zálohování a archivace
      SYS-PO-04	Správa uživatelů – systém RiskMS podporuje správu uživatelů systému a jejich rolí. Minimálně musí podporovat jejich vytváření, rušení, změnu a nastavení jejich atributů (např. jméno, heslo), nastavení rolí. Pro tento účet disponuje vhodným aparátem, popř. podporuje volitelná požadavek SYS-PO-54.
      SYS-PO-05	Systém RiskMS se napojí na zdroje dat a externí systémy specifikované v kapitole 1.2.
      SYS-PO-06	Lokalizace/jazyková mutace – systém RiskMS musí být v anglickém jazyce, případně může být klientská část dostupná i v českém jazyce.
      SYS-PO-07	Import z/do externích zdrojů dat (viz kapitola 1.2 této přílohy). Systém RiskMS umožní programově řídit importy dat z těchto systémů – čas, volba dat, konverze, kontrola atd.
      SYS-PO-08	Export souborů/složek Systém RiskMS musí zajistit pro koncového uživatele snadnou a intuitivní funkcionalitu exportu výstupu ve formě jednotlivého souboru, nebo u množiny výstupů pak jako množinu souborů Export musí být dostupný u definovaných formátů (viz požadavek AN-11).
      SYS-PO-09	Logování Systém RiskMS musí umožnit logování všech změn a všech významných událostí (např. bezpečnostních) v systému. Systém RiskMS umožňuje nadefinovat si, co se bude logovat, tj. filtry z logovaných události.
      SYS-PO-10	Automatizované zálohování Systém musí umožnit automatické postupy zálohování a obnovy SW řešení, jeho konfigurace a dat.
      SYS-PO-11	Obnova ze zálohy Systém RiskMS musí obsahovat funkcionalitu obnovy ze zálohy při zachování stejného OS nezávisle na použitém HW.
      SYS-PO-12	Množství uchovávaných dat Systém musí umožnit uchovat data o celkové velikosti alespoň 5 GB s další možností rozšíření úložiště dat.

   2. Vítané

      ID	Popis požadavku	Popis realizace (doplní uchazeč)
      SYS-PO-51	Aplikace podporuje databázovou platformu Oracle a ta je použita pro implementovaný systém RiskMS.
      SYS-PO-52	Systém RiskMS disponuje API rozhranním: Systém RiskMS má programové rozhraní (API) v JAVA nebo některém jazyce platformy Microsoft .NET nebo Windows COM, jehož pomocí lze zajistit přinejmenším obdobné akce jako s klientskou částí systému RiskMS, např. že API rozhraní umožní editaci předefinovaných funkcí a případné doprogramování vlastní funkcionality a jednorázové nebo dávkové úpravy nebo vytvoření dat. API rozhraní musí být plně zdokumentované. API rozhraní lze použít na propojení s externími zdroji dat –viz kapitola 1.2.
      SYS-PO-53	Dokumentovaný DB model Datový model databáze celého systému musí být zdokumentován, aby bylo možné vytvořit dotaz na konkrétní data obsažená v databázi. Na úrovni datového modelu musí být řešeny i vazby mezi entitami. Veškeré sestavy nebo přehledy budou na úrovni datového modelu optimalizovány tak, že bude u výběrových kritérii použita indexace. Jedinečné údaje budou kryty dle své povahy primárním nebo unikátním klíčem a vazby mezi jednotlivými entitami budou provedeny přes cizí klíče. Systém bude obsahovat postup nebo automatizovanou rutinu na přepočet databázových statistik. Přílohy k položkám jednotlivých entit budou uloženy ve struktuře databázového modelu.
      SYS-PO-54	Pro tvorbu sestav může systém RiskMS využít OBI EE.
      SYS-PO-55	Je zajištěn Single Sign-On. Systém RiskMS musí podporovat Single Sign-On  funkcionalitu pomocí Integrated Windows Authentication přes Kerberos ověřování využívající standardní účty uživatelů v AD platformy MS Windows Server 2008 R2 či interní aplikace ČNB přes databázová views
      SYS-PO-56	Inteligentní mailer pro doručování notifikací: V případě, že se nepodaří maileru navázat komunikaci s MTA či poštovním serverem ČNB (např. při výpadku tohoto serveru), mailer se pokusí o opětovné doručení mailu (kterým bude typicky notifikace pro řešitele či zákazníky) později nebo musí vygenerovat notifikaci na administrátora, že se mu nepodařilo navázat spojení pro doručení mailu. Mailer musí odpovídat internetovým standardům, zejména RFC 5321 a 5322, pokud posílá i MIME-zprávy (texty v jiné znakové sadě než US-ASCII, resp. tzv. přípojky), tak RFC 2045, 2046, 2047 a jejich aktualizace, posílá-li automaticky generované zprávy, tak ještě RFC 3834.

3. Notifikace

   1. Povinné

Nejsou

2. Vítané

   ID	Popis požadavku	Popis realizace (doplní uchazeč)
   NOT-PO-01	Odesílání notifikací uživatelům v případě změny vlastností výstupu, exportu, správa notifikací uživatelem. Systém musí umožnit automatické odeslání notifikace formou emailové zprávy (formát „Text“ či „HTML“) o změně vlastností objektu (např. export/graf/analýzy) – tj. změna obsahu, vložení/odstranění objektu.
   NOT-PO-02	Správa notifikací uživatelem Systém musí umožnit uživateli registraci k odběru notifikací, vč. volitelného nastavení/filtru notifikované operace.
   NOT-PO-03	Konfigurace obsahu notifikace Systém musí umožnit vybraným uživatelům modifikovat obsah notifikačního emailu.
   NOT-PO-04	Hromadné nastavení notifikace uživatelům: Systém musí umožnit vybraným uživatelům hromadné nastavení notifikace více uživatelům současně.

1. Výkon

   1. Povinné

      ID	Popis požadavku	Popis realizace (doplní uchazeč)
      VYK-PO-01	Doba odezvy systému RiskMS je okamžitá. Doba výpočtu jednotlivých procedur odpovídá počtu zpracovávaných obchodů, dní a opakování výpočtů (např. v případě Monte Carlo simulací) a nesmí přesáhnout dobu výpočtu obdobné úlohy naprogramované v některém uživatelském programovacím jazyku (např. Visual Basic v MS Excel).

   2. Vítané

Nejsou

5. Použitelnost systému RiskMS pro uživatele

   1. Povinné

      ID	Popis požadavku	Popis realizace (doplní uchazeč)
      USR-PO-01	On-line nápověda Systém RiskMS musí při používání systému zajistit on-line nápovědu. Tato on-line pomoc v systému musí být konstruována kontextuálně a být lokalizována do českého nebo anglického jazyka.
      USR-PO-02	Kvalita chybových hlášení Všechna chybová hlášení vydaná systémem musí dávat smysl tak, aby podle nich mohli přiměřeně jednat ti uživatelé, kteří je uvidí.
      USR-PO-03	Ergonomie Často prováděné transakce a operace systému musí být navrženy tak, aby je bylo možné provést malým počtem interakcí.
      USR-PO-04	Snadná konfigurovatelnost systému Systém musí správci umožnit, aby snadno a řízeným způsobem vyhledával, zobrazoval a rekonfiguroval jeho parametry.
      USR-PO-05	Uživatelská nápověda a dokumentace K systému RiskMS musí existovat kompletní elektronická uživatelská nápověda/dokumentace, popisující způsob použití aplikace. Tato nápověda musí být v českém jazyce nebo anglickém jazyce.
      USR-PO-06	Administrátorská nápověda/dokumentace K systému musí existovat kompletní elektronická administrátorská nápověda/dokumentace, popisující způsob administrace aplikace. Tato nápověda musí být v českém jazyce nebo anglickém jazyce.
      USR-PO-07	Rozsah školení – administrace a konfigurace Školení administrace a konfigurace systému RiskMS je zaměřeno především na samostatné provádění výkonnostní analýzy, prevence nedostupnosti služby, způsob plnění logů a jejich vyhodnocení, konfigurace parametrů serverů, nastavení autorizace a autentizace, auditní logování.
      USR-PO-08	Rozsah školení – používání systému RiskMS Školení v používání systému RiskMS je zaměřeno především uživatelské ovládání systému, práci s daty a tvorbu výstupů ze systému.

   2. Vítané

      ID	Popis požadavku	Popis realizace (doplní uchazeč)
      USR-PO-51	Přizpůsobení grafického rozhraní koncovému uživateli Tam, kde systém RiskMS využívá uživatelské grafické rozhraní, musí být uživatelům umožněno jeho přizpůsobení. Vlastní úprava by měla zahrnovat následující změny, ale neomezovat se pouze jen na ně: obsah menu, uspořádání obrazovky, barvy, písmo a velikost písma na obrazovce, sloupce v zobrazovaných seznamech či exportech.
      USR-PO-52	Rozsah školení – používání programového rozhraní (API) Školení používání programového rozhraní (API) je zaměřeno především na způsob použití API při integraci s aplikací třetí strany, hromadnou manipulaci s daty, vyhledávání, správa rolí, integrace s interními systémy a komponentami standardního systémového prostředí ČNB.
      USR-PO-53	Integrovatelnost s elektronickou poštou Systém musí být integrován se systémem elektronické pošty, aby uživatelé mohli posílat dokumenty elektronicky, aniž by opustili systém.

6. Bezpečnost

   1. Povinné

      ID	Popis požadavku	Popis realizace (doplní uchazeč)
      SEC-PO-01	Autentizace: Uživatel prokazuje svou identitu pomocí uživatelského účtu systému RiskMS a hesla.
      SEC-PO-02	Autorizace Systém musí umožnit autorizaci na základě skupin a rolí definovaných v systému RiskMS.
      SEC-PO-03	Omezení/přiřazení přístupu uživatelům Systém RiskMS musí umožnit, aby konkrétním uživatelům nebo uživatelským skupinám omezil/přiřadil přístup k analýzám, datům a operacemi nad nimi.

   2. Vítané

      ID	Popis požadavku	Popis realizace (doplní uchazeč)
      SEC-PO-51	Autentizace Uživatel prokazuje svou identitu pomocí Active Directory a SSO (Single Sign On) na základě přihlášení k desktopu nebo pomocí platného certifikátu.
      SEC-PO-52	Autorizace (vazba na Active Directory a IS ŘDB) Systém RiskMS by měl umožnit vazbu mezi interními rolemi systému a skupinami uživatelských účtů v active directory Windows domény ČNB. Autorizace by pak probíhala na základě existence aplikačních skupin a v nich zařazených uživatelských účtů v Active Directory, které jsou plněny z ŘDB. Dle provedené autorizace systém umožní provádět koncovému uživateli příslušné operace.
      SEC-PO-53	Zpracování informací mimo ČNB Systém RiskMS nesmí zpracovávat data, informace ani jejich části mimo systémové prostředí ČNB a nesmí obsahovat jakoukoliv SW/HW část provozovanou mimo systémové prostředí ČNB.

7. Auditovatelnost systému RiskMS

   1. Povinné

      ID	Popis požadavku	Popis realizace (doplní uchazeč)
      AUD-PO-01	Obsah auditního logu Systém RiskMS musí udržovat auditní log, schopný automaticky zachytit a uložit údaje o: všech operacích provedených s prvkem systému např. import dat, spuštění analýzy a její prezentace, správa uživatelských účtů a rolí, uživateli, který operaci iniciuje nebo provádí, datu a času této události.
      AUD-PO-02	Čitelnost a exportovatelnost auditního logu Systém RiskMS musí zajistit, aby údaje z auditního logu byly na požádání dostupné/exportovatelné pro kontrolu uživatelům, kteří se systémem nejsou obeznámeni vůbec nebo jen málo. Výstupní formát bude některý z: TXT, XML, PDF, DOC či DOCX, XLS či XLSx, CSV. Export musí být v kódování podporující české národní znaky.
      AUD-PO-03	Auditní události (přiřazení přístupu) Systém RiskMS musí zaznamenávat auditní události řízení přístupu: Přidání oprávnění (např. přidáním elektronického identifikátoru role/skupiny), Odebrání oprávnění (např. odstraňování zjištěných elektronické z role/skupiny).

   2. Vítané

      ID	Popis požadavku	Popis realizace (doplní uchazeč)
      AUD-PO-51	Auditní události (řízení přístupu) Systém musí zaznamenávat auditní události související s řízením přístupu: Logování přístupu do systému RiskMS vč. generování reportů pro následný monitoring, Přístup k datům/reportům/analýzám: Povolení přístupu (vč. toho, jaká akce byla provedena u daného objektu), Zamítnutí přístupu (vč. toho, jaká akce byla zamítnuta u daného objektu a z jakého důvodu), Změna ACL (Access Control List).

8. Rozšiřitelnost systému RiskMS

   1. Povinné

      ID	Popis požadavku	Popis realizace (doplní uchazeč)
      ROZ-PO-01	Rozšiřitelnost Systém musí podporovat škálovatelnost a rozšiřitelnost aplikace.
      ROZ-PO-02	Přístup k datovému úložišti SW řešení Poskytovatel zajistí oprávnění přístupu ke čtení uložených informací v datovém úložišti (DB modelu) a proškolení vybraných zaměstnanců ČNB za účelem kontroly integrity dat.

   2. Vítané

ID	Popis požadavku	Popis realizace (doplní uchazeč)
ROZ-PO-51	Webový prohlížeč Systém musí umožnit provoz alespoň v prohlížečích Internet Explorer 8+.
ROZ-PO-52	Virtualizace Všechny části systému musí být možné nasadit a provozovat ve virtualizovaném prostředí. Klientská část – publikovaný desktop prostřednictvím Citrix XenApp 6.5 Serverová část: VMWare vSphere 4.x, 5.x

Seznam pojmů

Termín	Definice
API	Application Programming Interface (xxxx://xx.xxxxxxxxx.xxx/xxxx/Xxxxxxxxxxx_xxxxxxxxxxx_xxxxxxxxx)
GPO	Group Policy Object (xxxx://xx.xxxxxxxxx.xxx/xxxx/Xxxxx_Xxxxxx_Xxxxxx)
JAVA	Java – programming language (xxxx://xx.xxxxxxxxx.xxx/xxxx/Xxxx_(xxxxxxxxxxx_xxxxxxxx))
MSI	File extension for Microsoft installer package (xxxx://xx.xxxxxxxxx.xxx/xxxx/Xxxxxxx_Xxxxxxxxx)
MTA	Message Transfer Agent (xxxx://xx.xxxxxxxxx.xxx/xxxx/Xxxxxxx_xxxxxxxx_xxxxx)

2. Komponenty či služby systémového prostředí požadované poskytovatelem nad rámec poskytovaným objednatelem

V případě, kdy systém RiskMS nabízené poskytovatelem vyžaduje SW služby nad rámec standardního systémového prostředí ČNB, uvede níže parametry těchto služeb. Cenové náklady na tyto služby musí být zahrnuty v cenové kalkulaci.

Komponenty či služby k doplnění do systémového prostředí ČNB
Jméno komponenty / služby	Podrobný technický popis komponenty / služby
(doplní uchazeč)	(doplní uchazeč)

Příloha č. 3

ORGANIZACE A ŘÍZENÍ PROJEKTU

V této příloze jsou uvedeny organizační standardy uplatňované ve standardním systémovém prostředí zadavatele a platné tedy i pro nový systém RiskMS.

1. Organizace

   1. Projekční tým

Pro realizaci daného softwarového řešení smluvní strany ustanoví společný Projekční tým, který má následující kompetence:

• řídit realizaci daného softwarového řešení;

• posuzovat průběh realizace plnění, zejména s ohledem na dodržování harmonogramu realizace obsaženého v jednotlivých etapách;

• projednávat připomínky každé ze smluvních stran k dodržování smluvních povinností druhé smluvní strany podle uzavřené smlouvy;

• řešit případné spory vznikající v souvislosti s uzavřenou smlouvou

Projekční tým - bude ustaven ve složení:

Projekční týmy
Za poskytovatele
Řídící pracovník projektu	.............................................................................
Vedoucí projektu	.............................................................................
Členové projekčního týmu1 (Garanti SW řešení)	............................................................................. ............................................................................. ............................................................................. (doplní uchazeč)
Za objednatele	Česká národní banka
Řídící pracovník projektu	.............................................................................
Vedoucí projektu	.............................................................................
Hlavní zadavatel	.............................................................................
Členové projekčního týmuError: Reference source not found (Garanti SW řešení)	............................................................................. ............................................................................. ............................................................................. ............................................................................. (bude doplněno z nabídky vybraného uchazeče před uzavřením smlouvy )

Projekční tým jedná pravidelně, obvykle jednou za 2 týdny, případně dle potřeby, na základě výzvy vedoucího projektu objednatele, a to po celou dobu realizace příslušné etapy. Jednání se musí zúčastnit nejméně jeden člen projekčního týmu za každou smluvní stranu. Písemné usnesení z jednání projekčního týmu obsahuje zhodnocení dosavadního průběhu smluvního vztahu, zejména posouzení dodržování harmonogramu realizace dle jednotlivých etap a plnění povinností obou smluvních stran, a dohodnuté datum a místo příštího jednání projekčního týmu. Dále může obsahovat připomínky, požadavky a komentáře obou smluvních stran.

Funkce řídicích pracovníků projektu představuje úroveň tzv. Koordinační komise, ostatní funkce pak vlastní výkonný projekční tým a realizační úroveň. Tomu pak odpovídá i pravomoc jednotlivých členů.

Vedoucí projektu objednatele je oprávněn požádat o odůvodněnou změnu vedoucího projektu poskytovatele. Poskytovatel, na základě uvedené písemné žádosti, zajistí výměnu vedoucího projektu poskytovatele do 5 pracovních dnů od obdržení žádosti.

2. Odpovědnost objednatele

Vedoucí projektu a členové projekčního týmu objednatele jsou odborní pracovníci s metodickými znalostmi resp. znalostmi IT/IS, kteří garantují, že zadání SW řešení vyhovuje všem legislativním a metodickým potřebám praktického využití u objednatele.

• Odpovídají za formulaci požadavků na funkčnost a za správnost zadání systému RiskMS a stvrzují shodnost dodaného řešení (s případným výčtem chyb a návrhů) se  zadáním/specifikací.

• V průběhu celého projektu jsou odpovědní za včasné a úplné odevzdání všech dohodnutých podkladů v dohodnutých termínech vedoucímu projektu poskytovatele.

• Vedoucí projektu objednatele má rozhodovací pravomoc při formulaci specifikací / analytických zadání dílčích úloh směrem ke poskytovateli, a to v rámci konkrétní uzavřené smlouvy.

• Objednatel se zavazuje urychleně ve vzájemné spolupráci se poskytovatelem vyvíjet maximální úsilí k odstranění jakýchkoli překážek bránících splnění předmětu této smlouvy.

• Objednatel zajistí zástupcům poskytovatele vytvoření nezbytných pracovních podmínek v místě objednatele a za přítomnosti zástupce objednatele, pokud je to nezbytné.

• Objednatel poskytne poskytovateli veškeré podklady nezbytné pro realizaci softwarového řešení nebo jeho části vč. údajů o standardním systémovém a databázovém prostředí objednatele, dokumentů a směrnic nebo jejich částí, které jsou klíčové pro realizaci softwarového řešení nebo jeho části.

• Objednatel má právo kontrolovat postup všech prací prováděných poskytovatelem.

3. Odpovědnost poskytovatele

Vedoucí projektu poskytovatele je odpovědný za koordinaci činností související s projektem, tak aby výsledkem bylo včas realizované softwarové řešení, které bude obsahovat veškeré požadované vlastnosti. Každý vedoucí projektu může určit svého zástupce.

Poskytovatel:

• Odpovídá za to, že jeho členové projekčního týmu jsou certifikovaní, příp. proškolení pracovníci v oblasti zajištění IT služeb, popř. věcné oblasti, kteří garantují, že dodaný aplikační SW odpovídá požadovanému rozsahu projektu.

• Odpovídá za správnou implementaci uživatelských požadavků objednatele na funkčnost softwarového řešení.

• Řádně povede písemnou dokumentaci, ve které bude zaznamenávat postup plnění této smlouvy; bude spolupracovat se zaměstnanci objednatele určenými vedoucím projektu objednatele. Poskytovatel se zavazuje pověřit plněním předmětu této smlouvy pouze ty své zaměstnance, kteří k tomu mají dostatečnou odbornou způsobilost.

• Odpovídá za včasné a úplné odevzdání všech dohodnutých prací v dohodnutých termínech vedoucímu týmu objednatele v průběhu celého projektu.

• Urychleně ve vzájemné spolupráci s objednatelem vyvíjí maximální úsilí k odstranění jakýchkoli překážek bránících splnění předmětu této smlouvy.

• Při plnění předmětu smlouvy bere na zřetel provozní potřeby objednatele a v úzké součinnosti s objednatelem provádí jednotlivá plnění této smlouvy.

• Informuje bezodkladně objednatele o jakýchkoliv zjištěných překážkách plnění, byť by za ně poskytovatel neodpovídal a o uplatněných nárocích třetích osob, které by mohly plnění této smlouvy ovlivnit.

2. Řízení projektu

   1. Plánování projektu

Cílem je vypracování detailního plánu a přiřazení disponibilních zdrojů k definovaným aktivitám s možností následného řízení a sledování postupu projektu. Na začátku projektu je v rámci tvorby realizační studie vytvořen poskytovatelem plán realizace projektu, který je postupně poskytovatelem aktualizován v rámci následujících etap a vždy akceptován objednatelem.

2. Řízení projektu

Tento proces zahrnuje vlastní realizaci projektu resp. provádění plánu projektu, tj. sledování, kontrolování, monitorování a dokumentování činností projektu a řízení změn. Hlavními aktivitami jsou koordinace postupu prací na projektu, přijímání rozhodnutí při vzniku problémů atd.

Průběh projektu je řízen podle plánu realizace projektu. Průběh projektu je pravidelně sledován a kontrolován vedoucími projektu.

3. Dokumentace projektu

Dokumentace průběhu projektu a projektových výstupů je vedena v souladu se vzájemně dohodnutou metodikou.

4. Změnové řízení

I po podpisu smlouvy a vytvoření realizační studie může dojít k potřebě změn (identifikace dalších požadavků, přehodnocení priority stávajících požadavků, změna dohodnutého rozsahu prací, změna termínu apod.). V takovém případě je nutno vypracovat žádost o změnu a zahájit změnové řízení. Poskytovatel zhodnotí důsledky těchto změn na projekt podle pravidel popsaných v následujících odstavcích. Řídící pracovník projektu objednatele pak podle doporučení vedoucích projektu rozhodne o realizaci či zamítnutí požadované změny.

Změnové řízení se týká zejména:

• Rozšíření původně schváleného rozsahu prací mezi poskytovatelem a objednatelem.

• Změn termínů dodávek prací nebo distribucí verzí aplikačního SW.

• Změn v řešení vyvolané změnami legislativy, které mají dopad do řešení.

Existují dva typy změn:

• Zásadní změny – jsou takové změny, které mohou vyvolat změnu nákladů (cen) nebo harmonogramu projektu (podstatné změny termínu).

• Ostatní změny – změny, které nemají zásadní vliv na rozsah a výsledek projektu.

Posouzení závažnosti změn provádí vedoucí projektu zadavatele na základě podkladů vypracovaných projekčním týmem zadavatele.

Změnové řízení může být iniciováno jak objednatelem, tak poskytovatelem a realizováno jedině na základě společného písemného rozhodnutí smluvních stran s okamžitou účinností pro obě strany. V případě změn, které by měly dopad do již sjednaných smluvních podmínek, je nutné dojednat mezi objednatelem a poskytovatelem příslušný dodatek smlouvy.

Pro řešení realizovaná v rámci změnového řízení platí všechna ustanovení uzavřených smluv, popř. jejích dodatků mezi objednatelem a poskytovatelem.

Žádost o změnu

Žádost o změnu může předložit kterýkoliv člen projekčního týmu. Každá žádost o změnu bude zapsána do nového formuláře „Žádost o změnu“ a stává se součástí projektové dokumentace. Žádost bude předána vedoucímu projektu. Všechny žádosti o změnu jsou archivovány v elektronické i písemné podobě.

Vyhodnocení žádosti o změnu

Vedoucí projektu poskytovatele ve spolupráci s vedoucím projektu objednatele přehodnotí, a je-li to nezbytné, revidují potřebu žádosti o změnu, a určí její prioritu a cílové datum řešení.

Během vyhodnocení bude zkoumán dopad změny a úkoly nezbytné k jejímu provedení. Bude určeno, jak změna ovlivní projekt z hlediska rozsahu, výstupů a nákladů, budou definovány požadované zdroje na její realizaci na straně poskytovatele a na straně objednatele, termín realizace změny nebo dílčí smlouvy vč. změn termínů souvisejících nebo návazných úloh. Rovněž bude posouzen dopad případného neprovedení změny. Závěry vyhodnocení budou zdokumentovány ve formuláři „Žádost o změnu“.

Vyřešení žádosti o změnu

Vedoucí projektu vypracují doporučení ke každé žádosti o změnu. Pokud změna neovlivní zásadním způsobem rozsah projektu, rozhodnou o provedení nebo zamítnutí změny.

V případě, že se jedná o zásadní změnu, připraví podrobný odhad skutečných nákladů a dopadů na rozvrh plánu projektu a se svým doporučením předají žádost k rozhodnutí řídícímu pracovníkovi projektu objednatele.

Po realizaci změny bude objednateli předána upravená dokumentace a nová verze aplikačního SW v elektronické podobě na dohodnutém médiu.

5. Předání a akceptace dodávek

Proces je popsán v článku IV smlouvy.

3. Kategorizace vad a termíny odstranění

   1. Kategorizace vad

Vady podstatné – kategorie A

• Vadou kategorie A se rozumí taková vada, která splňuje alespoň jednu z níže uvedených charakteristik:

  • nedodržení či neprokázání realizace nebo jen částečné realizace požadavku uvedené ve smlouvě a jejích přílohách,

  • 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ů,

  • znemožňuje používání systému RiskMS jako celku nebo znemožňuje používání základních funkcí systému RiskMS podle jeho dokumentace,

  • zapříčiňuje nemožnost používání nebo ovládání systému RiskMS,

  • zapříčiní ztrátu dat nebo úplně znemožní užití systému RiskMS,

  • způsobuje, že použití dodaného řešení by nebylo bezpečné nebo by plně neodpovídalo zásadám bezpečnostní politiky objednatele,

  • znemožňuje používání systému RiskMS jako celku nebo znemožňuje používání jeho základních funkcí podle jeho dokumentace,

  • ohrožuje provoz nebo dostupnost ostatních aplikací i samotného systému RiskMS v provozním prostředí objednatele,

  • způsobuje, že dodané řešení není schopno zpracovat běžnou provozní zátěž,

  • za provozních podmínek vede ke ztrátě funkce s dopadem na významný počet uživatelů,

  • projevuje se stále, občas nebo náhodně a má výše popsanou charakteristiku.

Vady nepodstatné – kategorie B a C

• Vadou kategorie B se rozumí taková vada, která splňuje alespoň jednu z níže uvedených charakteristik:

  • je možné pro její překonání nalézt odpovídající alternativu, která je akceptovatelná objednatelem,

  • způsobuje, že dodané systém RiskMS není schopen zpracovat maximální provozní zátěž,

  • projevuje se stále, občas nebo náhodně a má výše popsanou charakteristiku.

• Vadou kategorie C se rozumí taková vada, která splňuje alespoň jednu z níže uvedených charakteristik:

  • je způsobená drobnými konstrukčními nedostatky,

  • je pouze „kosmetické“ povahy,

  • je způsobena gramatickou chybou, nevhodným formátováním, překlepy,

  • projevuje se stále, občas nebo náhodně a má výše popsanou charakteristiku.

Kategorizaci vad provádí v průběhu plnění a po dobu podpory objednatel. O námitkách poskytovatele proti zařazení kterékoliv vady do určité kategorie rozhoduje s konečnou platností vedoucí projektu objednatele a v jeho nepřítomnosti jeho zástupce. V době záruční a pozáruční podpory kontaktní osoba dle článku IX odst. 2 smlouvy.

2. Oznamování vad

Zjištěné vady se hlásí mechanismem uvedeným v článku VIII smlouvy.

3. Lhůty odstranění vad

Lhůty pro odstranění vad platí jak pro vady oznámené v průběhu plnění podle čl. II odst. 2 a 3 smlouvy, tak i v průběhu sjednané technické a uživatelské podpory.

Kat. vad	Převzetí oznámení	Akce / Dočasné řešení	Lhůta pro odstranění vady
A	Poskytovatel potvrdí příjem oznámení o vadě v pracovní dny do 4 hodin od nahlášení vady.	n/a	Poskytovatel odstraní vadu nejpozději do 2 pracovních dnů od jejího nahlášení. Dohodou smluvních stran může být tato lhůta prodloužena v případě, kdy poskytovatel prokáže objektivní důvody, které mu brání v odstranění vady.
B	Poskytovatel potvrdí příjem oznámení o vadě do 8 hodin od nahlášení vady.	Poskytovatel zajistí vhodné opatření k odstranění vady systému RiskMS nebo nalezne a implementuje dočasné řešení bez zbytečného odkladu a to nejpozději do 2. pracovního dne od obdržení oznámení o vadě. Dočasné řešení se nevztahuje na vady zjištěné v rámci první etapy (analýza).	Poskytovatel odstraní vadu nejpozději do 7 pracovních dnů od jejího nahlášení. Dohodou smluvních stran může být tato lhůta prodloužena v případě, kdy poskytovatel prokáže objektivní důvody, které mu brání v odstranění vady.
C	Poskytovatel potvrdí příjem oznámení o vadě do 2 pracovních dnů od nahlášení vady	n/a	Poskytovatel odstraní vadu nejpozději do 20 pracovních dnů od jejího nahlášení. Dohodou smluvních stran může být tato lhůta prodloužena v případě, kdy poskytovatel prokáže objektivní důvody, které mu brání v odstranění vady.

Poskytovatel může písemně (elektronickou poštou) požádat objednatele o prodloužení lhůty pro odstranění vad kategorie B a C, a to nejméně dva (2) pracovní dny před uplynutím běžné lhůty pro odstranění vad. Objednatel je povinen na tuto žádost odpovědět do konce prvního (1) pracovního dne následujícího po obdržení žádosti. Neučiní-li tak, má se za to, že žádosti poskytovatele vyhovuje.

Příloha č. 4

Technická a uživatelská podpora systému RiskMS

Poskytovatel se zavazuje zajišťovat technickou a uživatelskou podporu kompletního systému RiskMS v tomto rozsahu

1. Technická a uživatelská podpora

1. Udržuje metodickou a technologickou jednotnost a konzistentnost všech prvků systému RiskMS.

2. Informuje v předstihu objednatele o všech připravovaných a realizovaných změnách v daném systému.

3. Provádí opravy detekovaných vad v celém systému RiskMS v dohodnutých reakčních časech závislých na kategorizaci vad dle přílohy č. 3.

4. Poskytuje ke všem aktualizacím a změnovým verzím dokumentaci v rozsahu dle čl. II odst. 2 písm. e) smlouvy.

5. Pro všechny prvky systému RiskMS, které nejsou součástí systémového prostředí objednatele a byly dodány jako součást systému RiskMS, poskytovatel se souhlasem objednatele implementuje a otestuje též všechny aktualizace (nové verze/update/upgrade/patch/hotfix) systému RiskMS.

6. Poskytne instrukce pro plnou funkční konfiguraci všech prvků systému RiskMS (zejména databázového systému, aplikačního serveru, klientské části apod.) po aplikaci aktualizace provedené objednatelem.

7. Poskytovatel předá k instalaci nové verze systému RiskMS vč. nezbytných souvisejících úprav doprogramovaných částí (např. napojení na interní datový interface) do 2 měsíců po jejich uvedení na český trh. Objednatel umožní poskytovateli ověření úprav doprogramovaných částí v prostředí objednatele.

8. Zajišťuje podporu a změny aplikace v souvislosti s pravidelným procesem implementace aktualizací (tj. update/upgrade/patch/hotfix) akceptovaného provozního systémového prostředí systému RiskMS (aplikace bezpečnostních aktualizací vydávaných výrobcem Operačního systému nebo aplikace, provozních komponent aplikačního prostředí atd.; včetně jejich „major“ aktualizací).

2. Poskytování nových verzí

Dodává v celém systému RiskMS všechny úpravy (aniž musí být objednatelem využity) včetně dokumentace poskytované výrobcem, tj. zejména:

• aktualizace (tj. nové verze/update/upgrade/patch/hotfix) vyvolané zejména změnami legislativního prostředí ČR či EU,

• všechny aktualizace (nové verze/update/upgrade/patch/hotfix) systému RiskMS v reálném předstihu s ohledem na provoz objednatele.

3. Helpdesk/Hotline

K provozování systému RiskMS poskytuje poskytovatel službu Hotline nebo Helpdesku;

1. Služby, informace a konzultace poskytuje prostřednictvím služby Hotline, nebo Helpdesk, která zahrnuje:

• evidenci a vyřizování požadavků na odstraňování vad systému RiskMS,

• konzultační podporu v oblasti používání dodaného systému RiskMS,

• evidenci požadavků na konzultace v místě objednatele;

2. Služba Hotline nebo Helpdesk je objednateli k dispozici v pracovních dnech od 7:30 do 17:30;

3. Poskytovatel poskytne koncovým uživatelům a zástupcům objednatele pověřených údržbou a rozvojem systému RiskMS pro zajišťování služby Hotline nebo Helpdesk nástroje pro efektivní poskytování dané služby:

........................................................

........................................................(doplní uchazeč)

(např.: portálové řešení, vyčleněnou telefonní linku, elektronickou adresu, jinou platformu);

4. Poskytovatel poskytuje v rámci sjednané podpory systému RiskMS přístup ke službám Hotline nebo Helpdesk nejméně pro dva zástupce objednatele. Odpovědné osoby objednatele jsou:

........................................................

........................................................(bude doplněno z nabídky vybraného uchazeče před uzavřením smlouvy)

4. Konzultace v místě objednatele

Poskytovatel zajišťuje službu konzultační podpory systému RiskMS v místě objednatele a to na vyžádání objednatele prostřednictvím telefonu nebo elektronické pošty v pracovní dny od 7:30 do 17:30 hodin.

Poskytovatel potvrdí příjem požadavku a na základě zadání objednatele předloží nabídku s výpočtem pracnosti na požadované práce. V případě, že objednatel nabídku akceptuje, sdělí pověřená osoba objednatele uvedená v příloze č. 3 tuto skutečnost e-mailem poskytovateli. Poskytovatel provede zadané úpravy ve lhůtě stanovené v zadání objednatele. Úpravy objednatel převezme po provedení zkoušky funkčnosti, předání a převzetí upravené dokumentace, a to na základě podpisu předávacího protokolu.

5. Podmínky odstraňování vad

1. Případné závady bude objednatel hlásit poskytovateli telefonicky na poskytnutý hot-line na telefonním čísle: ................. nebo na poskytnutý helpdesk na e-mail: ......................... či portálové řešení s HTTP adresou: ..................(doplní uchazeč). Poskytovatel potvrdí příjem hlášení o vadě elektronickou poštou na adresu osoby, která danou závadu nahlásila, s kopií na elektronickou adresu odpovědné osoby objednatele. Závada nahlášená mimo provozní dobu Helpdesk/Hotline se považuje za nahlášenou následující pracovní den v 7:30 hod.

2. Odpovědné osoby objednatele jsou:

..........................................................

........................................................... (bude doplněno před uzavřením smlouvy)

Odpovědné osoby za poskytovatele jsou:

......................................................................

...................................................................... (doplní uchazeč)

3. Kategorizace vad a lhůty převzetí oznámení, lhůty akce/náhradní řešení, lhůty odstranění vad se řídí přílohou č. 3.

4. Kategorizaci vad provádí v průběhu sjednané podpory objednatel. O námitkách poskytovatele proti zařazení kterékoliv vady do určité kategorie rozhoduje s konečnou platností odpovědná osoba za objednatele a v její nepřítomnosti její zástupce.

Příloha č. 5

BEZPEČNOSTNÍ POŽADAVKY OBJEDNATELE

1. Poskytovatel odpovídá za to, že do objektů objednatele (dále jen „ČNB“) budou vstupovat nebo vjíždět pouze jeho pracovníci, kteří jsou jmenovitě uvedeni v písemném seznamu, schváleném ČNB (dále jen „seznam“). Tato povinnost se vztahuje i na posádky vozidel poskytovatele vjíždějících do garáží ČNB za účelem složení a naložení nákladu. Seznam poskytovatel předloží ČNB nejpozději v den podpisu smlouvy.

2. Seznam bude obsahovat tyto položky: jméno, příjmení a číslo průkazu totožnosti pracovníků poskytovatele. Součástí seznamu je ,,Prohlášení o získání souhlasu subjektů osobních údajů se zpracováním osobních údajů v ČNB ve smyslu zákona č.101/2000 Sb., o ochraně osobních údajů“. Poskytovatel v něm prohlásí a nese odpovědnost za to, že jeho pracovníci uvedení v seznamu vydali souhlas se zpracováním osobních údajů Českou národní bankou v rozsahu: jméno, příjmení a číslo průkazu totožnosti. Důvodem předání těchto osobních údajů je zajištění evidence osob vstupujících do objektu ČNB a správy přístupového systému ČNB.

3. Požadavky na případné doplňky a změny schváleného seznamu pracovníků poskytovatele je nutno neprodleně oznámit ČNB. Případné doplňky a změny podléhají schválení ČNB. Osoby neschválené ČNB nemohou vstupovat do objektů ČNB, přičemž ČNB si vyhrazuje právo neuvádět důvody jejich neschválení.

4. Při příchodu do objektů ČNB pracovníci poskytovatele sdělí důvod vstupu, prokáží se osobním dokladem a podrobí se bezpečnostní kontrole. Osoby, které nejsou uvedeny na seznamu, nebudou do objektu ČNB vpuštěny.

5. Schválení pracovníci poskytovatele musí dbát pokynů bankovních policistů, které se týkají režimu vstupu, pohybu a vjezdu do objektu ČNB. Pracovníci poskytovatele budou do prostorů ČNB vstupovat a v těchto prostorách se pohybovat v režimu návštěv, to znamená vždy pouze v doprovodu zaměstnance ČNB nebo zaměstnance referátu bankovní policie ČNB.

6. V případě mimořádné události se pracovníci poskytovatele musí řídit pokyny bankovních policistů nebo dozorujícím zaměstnancem ČNB a dále instrukcemi vyhlašovanými vnitřním rozhlasem.

7. Pracovníci poskytovatele nesmí vnášet do prostor ČNB nebezpečné předměty, jako jsou střelné zbraně, výbušniny apod. O tom co je a není nebezpečný předmět, rozhodují bankovní policisté v souladu s vnitřními předpisy ČNB.

8. ČNB si vyhrazuje právo nevpustit do objektů ČNB pracovníka poskytovatele, který je zjevně pod vlivem alkoholu, drog nebo jiné omamné látky.

9. Bez písemného povolení ČNB je zakázáno fotografování a pořizování videozáznamů z interiéru objektů ČNB.

10. Ve všech prostorech objektů ČNB je přísný zákaz kouření a používání otevřeného ohně. O povolení práce se zvýšeným požárním nebezpečím požádá poskytovatel písemnou formou vždy nejpozději jeden pracovní den před zahájením prací, dozorujícího zaměstnance ČNB. Dále se pracovníci poskytovatele musí zdržet poškozování či zcizení majetku ČNB, a dále zdržet se nevhodného chování vůči zaměstnancům a návštěvníkům ČNB.

11. Pracovníci poskytovatele uvedení na seznamu se musí před započetím výkonu práce v objektech ČNB prokazatelně seznámit, ve smyslu předpisů o požární ochraně, bezpečnosti a hygieně práce, se specifikami daných objektů ČNB (např. způsob vyhlášení požárního poplachu, určení ohlašovny požáru, seznámení s únikovými cestami, poplachovými směrnicemi, evakuačním plánem, umístěním věcných prostředků požární ochrany apod.). ČNB je oprávněna kdykoliv podrobit kontrole kterékoliv pracovníka poskytovatele uvedeného na seznamu z dodržování těchto předpisů a ustanovení.

Příloha č. 6

POŽADAVKY NA GRAFICKÝ VZHLED SW ŘEŠENÍ

Vzhled systému RiskMS by měl mít minimalistickou, nadčasovou grafiku vycházející z firemních barev v souladu s následnými požadavky na vzhled. Zároveň musí být navrženo tak, aby bylo možné snadno vzhled modifikovat v závislosti na změnách požadovaných objednatelem.

Jelikož aplikace bude mít zcela specifický účel, nepožaduje ČNB, aby kopírovala grafický vzhled hlavního webu ČNB. Z tohoto důvodu bude vhodné uplatnit na aplikaci nadčasový minimalistický design, který bude pouze vycházet z firemních barev ČNB a použije správně logotyp ČNB.

Grafický vzhled RiskMS musí respektovat všechna pravidla dostupnosti a přístupnosti v souladu s Web Content Accessibility Guidelines, Blind Friendly Web, vyhláškou č. 64/2008 Sb. (vyhláška o přístupnosti) a v rozumné míře i se zákonem č. 365/2000 Sb., o informačních systémech veřejné správy.

1. Logotyp

Aplikace může obsahovat logotyp ČNB. Zásady použití logotypu ČNB, jeho barevnost, velikost, základní a doplňkové barvy, používané fonty písma i nepovolené způsoby použití apod. upravuje „Grafický manuál logotypu České národní banky 2011“, který poskytovatel v případě potřeby obdrží v elektronické podobě ve formátu PDF. Pokud se strany nedohodnou, jinak bude zvolený (vybraný) logotyp ČNB poskytnut poskytovateli v požadovaném grafickém formátu v souladu s příslušným vnitřním předpisem ČNB (Pokyny České národní banky č. 47, které stanovují jednotné užívání logotypu České národní banky a jednotnou úpravu dokumentů v ČNB).

1) Základními typy logotypu ČNB jsou:

a) Šedomodrý logotyp (barva šedá, odstín Pantone 424, a barva modrá, odstín Pantone 2736). Tento logotyp může být používán pouze na bílém podkladu; přípustné je rovněž jeho umístění na světle šedé ploše, jejíž sytost nepřesáhne 20% černé. Na tmavší šedé nebo černé ploše ani na barevné ploše nebo jakémkoliv černobílém či barevném strukturovaném podkladu nesmí být tento logotyp umístěn.

b) Černý/bílý logotyp (barva černá, odstín Pantone Process Black). Používá se při jednobarevném černobílém tisku nebo při umístění na barevném či černobílém strukturovaném podkladu. Může být používán podle sytosti v negativní nebo pozitivní podobě. Pozitivní varianta je přípustná na podkladové ploše, která nepřesáhne sytost 50% černé. Od této hodnoty je nutné použít negativní bílou variantu. Na velmi členitých nebo barevných plochách je vhodné použít logotyp v jeho negativní verzi a umístit jej do černé plochy. Velikost této černé plochy se odvozuje stejně jako ochranná zóna z velikosti písmene B v názvu banky.

2) Základní typy logotypů ČNB jsou ve variantě jednořádkové, dvouřádkové a třířádkové v české a anglické verzi:

a) Jednořádkový logotyp (zkratka ČNB a název banky umístěné do jednoho řádku) se může používat buď samostatně, jako grafický celek, nebo může být doplněn dalšími texty vztahujícími se přímo k České národní bance. U jednořádkového logotypu je rovněž povolena jeho modifikace, kdy je zkratka ČNB umístěna před názvem banky. Tato modifikace však nesmí být použita samostatně a její výjimečné použití se omezuje na případy, kdy je nutné k logotypu umístit další informace a není možné zároveň použít dvouřádkový logotyp.

b) Dvouřádkový logotyp (zkratka ČNB a název banky rozdělený do dvou řádků) se může používat buď samostatně, jako grafický celek, nebo může být doplněn dalšími texty vztahujícími se přímo k České národní bance.

c) Třířádkový logotyp (zkratka ČNB a název banky rozdělený do tří řádků) představuje základní variantu logotypu ČNB. Musí být používán výhradně samostatně, jako grafický celek, a nesmí se jakýmkoliv způsobem upravovat ani kombinovat s dalšími texty.

3) Okolo každého logotypu musí být vždy zachována ochranná zóna, kam není možné umístit žádný další informativní nebo výtvarný prvek. Velikost ochranné zóny se odvozuje z velikosti písmene B v názvu banky a její velikost je přesně definovaná v grafickém manuálu.

4) V logotypu je jako základní použit soubor písem typu Xxxxxxx (Book, Italic, Medium, Medium Italic, Bold, Bold Italic, Medium Bold a Medium Bold Italic), které vytváří vizuální styl logotypu ČNB. Jako doplňková je možné použít pouze písma typů Xxxxxxxxxxx, Frutiger, Times New Roman a Verdana.

5) Logotyp ČNB by měl být umístěn v levém horním rohu a tvořit odkaz na hlavní web ČNB xxx.xxx.xx a být opatřen alternativním textem „Úvodní stránka webu ČNB“.

2. Barvy

Barvy použité na jednotlivé grafické prvky aplikace, tj. např. tlačítka formulářů, ovládací prvky, podbarvení menu apod., by měly vycházet ze základních barev Grafického manuálu 2011 logotypu ČNB. Barva písma a podkladu musí být navzájem dostatečně kontrastní, aby výsledek vyhovoval požadavkům na přístupnost webu.

P říloha č. 7

ŠABLONA REALIZAČNÍ STUDIE

[Kód projektu - vlastní vlastnosti souboru]
[Název projektu - vlastní vlastnosti souboru]

Realizační studie

Verze:

Stav:

Datum poslední modifikace:

Autor:

Vedoucí projektu:

Sekce:

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ů.

Odsouhlasení

Jméno Útvar Datum Podpis

Adresáti dokumentu

Útvar ČNB / Společnost Jméno

Historie změn

Verze Datum Autor Popis změny

Obsah

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

1.1. Účel dokumentu...................................................................................................

1.2. Seznam pojmů a zkratek......................................................................................

1.3. Přehled použitých symbolů..................................................................................

1.4. Struktura dokumentu ..........................................................................................

2. Realizace uživatelských požadavků........................................................................................

2.1. Mapování požadavků...........................................................................................

2.2. Analýza požadavků - procesy..............................................................................

2.3. Mapování uživatelského rozhraní na procesy......................................................

2.4. Celkový přehled funkcionalit dodávaného systému RiskMS..............................

3. Technická realizace systému RiskMS..............................................................

3.1. Výchozí situace a cílový stav................................................................................

3.2. Návrh architektury technického řešení.................................................................

3.3. Integrace s aplikacemi třetích stran.......................................................................

3.3.x jednotlivé systémy

3.4. Požadavky na systémové prostředí ČNB..............................................................

3.5. Bezpečnostní profil................................................................................................

3.6. Logování ...............................................................................................................

3.7. Autentizace a autorizace .......................................................................................

3.8. Normy a standardy................................................................................................

3.9. Instalace, správa a údržba systému........................................................................

3.10. Popis napojení na zdroj primárních dat a postupu importu či nahrání primárních dat do RiskMS .................................................................................

3.11. Aplikační programovací rozhraní..........................................................................

4. Organizační řešení.....................................................................................................................

4.1. Výstupy projektu ..................................................................................................

4.2. Detailní harmonogram realizace ...........................................................................

4.3. Požadavky na součinnost.......................................................................................

4.4. Akceptační testovací scénáře.................................................................................

4.5. Školení...................................................................................................................

1. Úvod

1.1. Účel dokumentu

Dokument realizační studie popisuje způsob realizace dodávaného softwarového řešení „[Název projektu]“ dále jen [Kód projektu] včetně mapování funkčních požadavků, softwarové architektury a systémových požadavků tak, aby byly prokázána realizovatelnost všech zadaných požadavků.

1.2. Seznam pojmů a zkratek

[Výčet klíčových zkratek a pojmů s jejich vysvětlením]

Termín/Zkratka Popis/Význam

1.3. Přehled použitých symbolů

[Popis použitých grafických symbolů v dokumentu]

Grafický symbol Význam

1.4. Struktura dokumentu

[Tato podkapitola popisuje strukturu dokumentu, jak je dokument organizován]

2. Realizace uživatelských požadavků

V této kapitole je detailně popsána analýza požadavků objednatele.

2.1. Mapování požadavků

[Kapitole obsahuje mapování požadavků objednatele na cílové řešení. Popis tak ve stručné formě představuje způsob realizace jednotlivých požadavků. Předpokládá se využití přílohy č.1a 2 z nabídky poskytovatel, přičemž dojde k vybrání pouze relevantních požadavků a podrobní se proces jejich implementace.]

ID² Popis požadavku Název funkcionality Poznámka

2.2. Analýza požadavků - procesy

[V této kapitole je detailně popsána analýza požadavků objednatele ve vazbě na vybrané základní procesy,které budou v systému RiskMS realizovány, a to například formou případů užití (Use Case), a to takovým stylem, aby byla jednoznačně prokázána realizovatelnost požadavků.

2.3. Mapování uživatelského rozhraní na procesy

[Kapitola obsahuje případné mapování grafického uživatelského rozhraní aplikace na stanovené procesy v předchozí kapitole 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í. Taktéž takto bude ověřována uživatelská přívětivost systému RiskMS pro uživatele.

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.

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)

2.4. Celkový přehled funkcionalit dodávaného systému

[Kapitola obsahuje přehled všech funkcionalit dodávaného řešení nebo odkaz na příslušnou uživatelskou dokumentaci. Jednotlivé funkcionality jsou rozděleny do kapitol dle logických oblastí například: správa dat, definice reportů, realizace analýz, administrátorské činnosti, monitoring chodu systému atd.]

3. Technická realizace systému RiskMS

3.1. Výchozí situace a cílový stav

[Kapitola stručně popisuje výchozí a cílový stav navrhované architektury řešení popsaný v následujících kapitolách.]

3.2. Návrh architektury technického řešení

[Kapitola popisuje globální architekturu IS a fyzickou architekturu nasazení systému v systémovém prostředí objednatele s ohledem na správu uživatelů, import/export dat, provoz, monitoring, zálohování a archivaci aplikace.]

3.3. Spolupráce s aplikacemi třetích stran

[Kapitola obsahuje popis integrace s jednotlivými stávajícími službami a komponentami systémového prostředí ČNB a aplikacemi poskytujícím systému RiskMS data. Níže je uveden pouze příklad takovýchto systémů.]

3.3.1. Microsoft Active Directory (single sign-on) a IS Řídicí databáze

3.3.2. Microsoft Exchange/ MS Outlook

3.3.3. IS ISFO + <Popis napojení na interní datový interface>

3.3.4 Bloomberg

3.3.5 Zálohování

3.3.6 Monitoring a správa logů

3.3.7 <Další aplikace / systémy / služby>

3.4. Požadavky na systémové prostředí ČNB

[Kapitola obsahuje SW a HW specifikaci pro nasazení v prostředí zadavatele. Součástí je i schéma nasazení. 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
APP1	Windows Server 2008 R2 ENG x64	Oracle client 10g	MS IIS 7.5 XXX.XXX 3.5 SP1

3.5. Bezpečnostní profil

[Kapitola obsahuje popis aplikace z hlediska její bezpečnosti, integrity a důvěrnosti dat např. neoprávněnému přístupu k datům. Obsahuje odpovědi na otázku personálního a fyzického zajištění bezpečnosti aplikace]

3.6. Logování

[V kapitole je popsán způsob logování a monitorování logů]

3.7. Autentizace a autorizace

[V kapitole je popsán princip řízení přístupů k informacím resp. informačním aktivům: jakým prostřednictvím přistupují interní uživatelé, popis technických (aplikačních) účtů – bez časového omezení; definice distribučních emailových seznamů, politika hesel, bezpečnostní zamykání přístupů (např. 3 nekorektní přihlášení) a jejich následné odemknutí, způsob automatického blokování účtů uživatelů při ukončení zaměstnaneckého poměru v ČNB, povolené protokoly, zabezpečený vzdálený přístup pro řešení havárií, vazby na další IS/IT]

3.8. Normy a standardy

[Kapitola shrnuje identifikované standardy a normy používané při realizaci požadavku v IT.]

3.9. Instalace, správa a údržba systému

[Kapitola obsahuje postup nasazení systému do cílového prostředí s ohledem na stanovení příslušné součinnosti.]

3.10. Popis napojení na zdroj primárních dat a postupu importu či nahrání primárních dat do RiskMS

[Kapitola popisuje postup automatizovaného importu či nahrání primárních dat do implementovaného systému.]

3.11. Aplikační programovací rozhraní

[Je-li volitelný požadavek SYS-PO-52 akceptován, pak kapitola popisuje kompletní aplikační programovací rozhraní (API), jejich metody a příklady použití SW řešení. Kapitola může obsahovat odkaz na externí dokumentaci]

4. Organizační řešení

4.1. Výstupy projektu

[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í

4.2. Detailní harmonogram realizace

[Harmonogram realizace uvádí rozpad realizace projektu do jednotlivých fází a činností s ohledem na dodržení stanovených termínů. Harmonogram musí obsahovat milníky pro předání díla nebo jeho části k akceptačnímu řízení.]

4.3. Požadavky na součinnost

[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 zhotovitelem 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á

4.4. Akceptační testovací scénáře

[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 Testovaná oblast Testovací scénář REQ

Legenda

ID: Jedinečný identifikátor testovacího scénáře

Testovaná oblast: Oblast testování např.: práce s metadaty, vyhledávání atd.

Testovací scénář: Popis testovacího scénáře

REQ: Jedinečné identifikátory požadavků objednatele, které jsou daným testovacím scénářem ověřovány

4.5. Školení

[Kapitola detailněji popisuje způsob zajištění školení a proškolení příslušných pracovníků]

Příloha č. 8

ŠABLONA TESTOVACÍHO SCÉNÁŘE

<Název projektu>

Testovací scénáře

Verze:

Stav:

Datum poslední modifikace:

Autor:

Vedoucí projektu:

Sekce:

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ů.

Odsouhlasení

Jméno Útvar Datum Podpis

Adresáti dokumentu

Útvar ČNB / Společnost Jméno

Historie změn

Verze Datum Autor Popis změny

Obsah

1 Účel dokumentu..............................................................................................................

2 Testovací scénáře............................................................................................................

3 Detailní popis testovacích případů..................................................................................

3.1 <Testovací oblast>..............................................................................................

3.1.1 <ID> - <název scénáře>..........................................................................

3.1.2 <ID> - <název scénáře>..........................................................................

3.2 <Testovací oblast>..............................................................................................

3.2.1 <ID> - <název scénáře>..........................................................................

1 Účel dokumentu

[ V této kapitole je vhodné velice stručně uvést, k čemu SW, který se bude testovat, slouží, kdo ho používá a z jakých hlavních částí se skládá. Na jaké HW a SW konfiguraci systém bude běžet a na jaké HW a SW konfiguraci se bude testování provádět. Kdo, kde, kdy a jak bude testování provádět]

2 Testovací scénáře

[Kapitola obsahuje stručný přehled testovacích scénářů ]

Souhrnný přehled testovacích scénářů
ID	Testovací scénář	Výsledek testu
		vyhovuje  nevyhovuje

3 Detailní popis testovacích případů

3.1 <Testovací oblast>

3.1.1 <ID> - <název scénáře>

Testovací scénář
Název scénáře		ID
Testovaná oblast
Účel testu/Kriteria
Testovací prostředí
Podmínky pro provedení testu / přípravné kroky

Testovací pokyn
Komentář
Krok	Vstupní data/operace prováděné testerem		Očekávané výsledky	Komentář

Testovací pokyn
Komentář
Krok	Vstupní data/operace prováděné testerem		Očekávané výsledky	Komentář

3.1.2 <ID> - <název scénáře>

......................................................

3.2 <Testovací oblast>

3.2.1 <ID> - <název scénáře>

......................................................

Příloha č. 9

POJMY A ZKRATKY

Zkratka	Popis
Akceptační zkušební prostředí	SW/HW prostředí, ve kterém je implementováno požadované SW řešení s vazbami na zdroje dat a na systémové prostředí objednatele. Toto prostředí umožňuje přístup libovolnému počtu koncových uživatelů za účelem ověření funkcionality celého SW řešení. V rámci tohoto prostředí se využívají data odpovídající v omezené podobě provoznímu prostředí. Toto prostředí existuje po dobu akceptace SW řešení.
API	Application Programming Interface představuje soubor procedur, funkcí či tříd nějaké knihovny/systému/jádra operačního systému, které může programátor využívat k přístupu k funkcionalitám daného systému a tím zajisti iteraci mezi daným SW řešením a aplikací třetí strany. API určuje, jakým způsobem jsou funkce volány ze zdrojového kódu programu třetí strany.
Autentifikace	viz Autentizace
Autentikace	viz Autentizace
Autentizace	Autentizací je myšlen proces ověření proklamované identity subjektu.
Autorizace	Proces ověření oprávnění koncového uživatele pro přístup k objektu SW nebo pro provedení určité akce. Tato kontrola se provádí na základě členství uživatele v různých uživatelských skupinách, přístupových seznamech apod.
Cluster	Seskupení volně vázaných počítačů, které spolu úzce spolupracují za účelem zajištění (anglicky High-availability nebo failover) nepřetržitého poskytování SW služby i při výpadku počítače z důvodu hardwarové závady nebo plánované údržby. Službu poskytuje jeden počítač, který je v případě výpadku automaticky zastoupen jiným počítačem.
Digitální	Pojem „digitální“ vyjadřuje způsob zpracování entity představovaný numerickým řetězcem tvořeným čísly „1“ a „0“ (proud bitů) interpretovatelný pomocí výpočetní techniky. Pojem „elektronický“ se užívá obdobně.
Elektronický	Pojem „elektronický“ je použít obdobně jako pojem „digitální“.
Export	Export je proces vytvoření kopie entity včetně všech jejich metadat za účelem převedení vzniklé kopie do jiného systému, při zachování její primární funkce. Exportované entity zůstávají zachovány v původním systému, nejsou tedy z něj smazána.
Export souborů	Proces vytvoření kopie úplných elektronických souborů včetně jejich metadat obsažených v systému RiskMS pro jiný systém.
Formát souboru	Formátem souboru je myšlena elektronická struktura souboru.
GUI	Grafické uživatelské rozhraní (Graphical User Interface) je uživatelské rozhraní, které umožňuje ovládat SW aplikaci pomocí interaktivních grafických ovládacích prvků.
Helpdesk	Služba Helpdesk obsahuje komunikační portál přes který objednatel zadává své požadavky na servis a zároveň zde má ucelený přehled o svých požadavcích a o průběhu jejich řešení.
Hostované služby	Správa aplikace v prostředí poskytovatele služeb mimo systémové prostředí ČNB
Hotfix	Opravy výrobku nasazované za běhu cílového systému.
Hotline	Služba Hotline poskytuje možnost objednateli telefonické komunikace mezi s IT poskytovatele odborníkem pro řešení drobných problémů.
IS	Informační systém
IS ŘDB	Informační systém pro řízení uživatelů a skupin uživatelů domény xx.xxx.xx a pro řízení nastavení zařízení zapojených do LAN sítě ČNB.
Jediná (jedna) operace	Posloupnost činností aplikace vyvolaná jedním iniciačním úkonem uživatele.
Koordinační komise	Koordinační komise na manažerské úrovni zatupuje zájmy projektu a skládá se ze zástupců poskytovatele a objednatele. Slouží jako eskalační mechanismus pro řešení případných problémů či rozporů.
Metadata	Strukturované nebo semistrukturované informace umožňující vytvoření, správu a používání souborů v průběhu času
Patch	Opravy výrobku nasazované při odstavení/vypnutí cílového systému.
Produkční prostředí	viz Provozní prostředí
Projekt	Činnosti související se zhotovením SW řešení
Projektová dokumentace	Dokumentace vývoje, implementace a testování SW řešení, včetně popisu dalších činností souvisejících s projektem implementace SW řešení
Provozní dokumentace	Návod k zajištění instalace a provozu SW řešení, včetně popisu dalších činností souvisejících s provozem SW řešení
Provozní prostředí	SW/HW prostředí, ve kterém je implementováno požadované SW řešení s vazbami na zdroje dat a na systémové prostředí objednatele a které umožňuje přístup koncovým uživatelům za účelem užití SW řešení.
Xxxxxx	Xxxxxxxx je myšlena každá zaznamenaná elektronická informace uložitelná samostatně na datové médium např. dokument, obrázek, hudba
Testovací scénář	Testovací scénář je tvořen sadou návodných testovacích pokynů, jejichž vykonáním koncový uživatelem ověří funkcionalitu dodávaného SW řešení. Může se jednat o testovací pokyny, které na sebe navazují a musí být vykonány v přesně uvedeném pořadí, nebo na pořadí, v jakém jsou jednotlivé testovací případy prováděny, nezáleží.
Update	Aktualizace hlavní verze softwarového produktu, která obsahuje balík oprav stávající hlavní verze produktu a její drobná vylepšení.
Upgrade	Přechod na novější, samostatnou verzi téhož produktu, která obsahuje řadu významných vylepšení softwaru oproti původní verzi.
URI	Uniform Resource Identifier jedná se o jednotný identifikátor zdroje složený z řetězce znaků s definovanou strukturou, který slouží k přesné specifikaci zdroje informací (ve smyslu dokument nebo služba), hlavně za účelem jejich použití pomocí počítačové sítě, zejména Internetu. URI je definovaný standardem RFC3986
URL	URL - Uniform Resource Locator, jedná se o jednotný lokátor zdroje, který je složen z řetězce s definovanou strukturou, který slouží k přesné specifikaci umístění zdrojů informací (ve smyslu dokument nebo služba) na Internetu.URL definuje doménovou adresu serveru, umístění zdroje na serveru a protokol, kterým je možné zdroj zpřístupnit. URL je definovaný standardem RFC1738
Uživatelská dokumentace	Úplný popis ovládání SW řešení a uživatelského rozhraní.
Uživatelský akceptační test	Test ověřující požadované funkcionality systému po jeho instalaci. Test lze provádět na základě testovacích scénářů, kdy testy resp. testovací scénáře jsou připraveny tak, aby zástupci objednatele mohli provést test funkcionality dodávaného SW bez detailní znalosti testovaného SW. Výsledkem akceptačního testu je schválení nebo zamítnutí převzetí díla nebo jeho části.
Vedoucí projektu	Vedoucími projektu se rozumí ti zaměstnanci Objednatele a Poskytovatele, kteří budou odpovědní za koordinaci činností souvisejících s projektem, tak aby výsledkem bylo včas realizované SW řešení, které bude obsahovat veškeré požadované vlastnosti. Každý vedoucí projektu má svého zástupce
Verze (souboru)	Stav souboru v některé z jeho fází životního cyklu. Soubor v systému má alespoň jednu verzi
Životní cyklus SW	Jedná se o sled činností se Analýza – Návrh – Realizace – Test – Rutinní provoz – Update – Upgrade pokrývající životnost aplikace

Příloha č. 10

POJISTNÁ SMLOUVA, POJISTNÝ CERTIFIKÁT

(bude doplněno z nabídky vybraného uchazeče před uzavřením smlouvy)

Příloha č. 11

DETAILNÍ SPECIFIKACE SYSTÉMU RiskMS

(bude doplněno z nabídky vybraného uchazeče před uzavřením smlouvy)

Příloha č. 12

CENOVÁ TABULKA

(bude doplněno z nabídky vybraného uchazeče před uzavřením smlouvy)

1 Jedná se o klíčové členy projekčního týmu garantující kvalitu systému RiskMS

2 ID požadavku objednatele