AKCEPTAČNÍ ŘÍZENÍ
|
Příloha č. 5 Xxxxxxx |
AKCEPTAČNÍ ŘÍZENÍ
1Úvod
Akceptační řízení u druhého a třetího dílčího plnění prověří, zda dodané řešení splňuje všechny funkční a nefunkční požadavky objednatele uvedené v příloze č. 1 smlouvy a další požadavky uvedené v technickém zadání (příloha č. 2 smlouvy) a parametry/funkce popsané zhotovitelem v příloze č. 10 smlouvy, které jsou blíže specifikovány v dokumentu Realizační studie. Dále akceptační řízení prověřuje, zda byly splněny i ostatní požadavky uvedené v této smlouvě a systém je možné převzít objednatelem do ověřovacího provozu. Akceptační řízení též zahrnuje formální prověření předávané technické a provozní dokumentace, tzn. uživatelské příručky, administrátorské příručky, příručky technického správce.
2Metoda
Při akceptačním řízení se bude postupovat následovně:
Testování se bude provádět v zásadě na úrovni jednotlivých procesních rolí a nikoliv pod účtem systémového administrátora a takovým způsobem, při kterém se projeví případné nekonzistence z hlediska přístupových práv apod.
Testovací scénáře u opakovaných testů, u kterých objednatel potvrdí, že jsou v pořádku, se nemusí např. kvůli časové náročnosti provádět.
Testy budou klasifikovány buď „bez vad“ nebo „s vadou typu A/B/C“ (viz. kapitola č. 4 této přílohy).
Pokud dojde při testování k závadě, která zabrání pokračování testů, budou akceptační testy ukončeny, a po odstranění vady zopakovány.
U vad typu B a C, u kterých došlo k dohodě mezi poskytovatelem a objednatelem, že je možné v akceptačních testech pokračovat.
3Předpoklady
Akceptační testy lze provádět pouze tehdy, budou-li splněny následující předpoklady.
Na začátku akceptačního řízení bude k dispozici:
Testovací prostředí s kompletně dokončeným nastavením SW řešení SDAT pro akceptační testy daného dílčího plnění.
Následující dokumenty:
Akceptovaná realizační studie.
Uživatelská příručka obsahující popis pro dané dílčí plnění.
Administrátorská příručka obsahující popis pro dané dílčí plnění.
Testovací scénáře pro dané dílčí plnění (viz kap. 8).
Zároveň bude provedeno školení uživatelů a administrátorů v rozsahu nutném pro akceptaci daného dílčího plnění.
4Kategorizace vad
Kategorizaci vad provádí objednatel. Pokud poskytovatel nebude souhlasit se zařazením vady do určité kategorie a vznese námitku proti jejímu zařazení, rozhoduje o námitce s konečnou platností vedoucí projektu objednatele. Proti rozhodnutí vedoucího projektu objednatele může vedoucí projektu poskytovatele podat námitku – v takovém případě o kategorizaci vady definitivně rozhodne Řídicí komise projektu.
Pro kategorizaci vady není určující, zda se vada projevuje stále, občas nebo náhodně. Kategorie vad jsou stanoveny takto:
A – Kritická vada - velmi vážná vada, která znemožňuje práci se systémem nebo nesplňuje funkční zadání, tzn., že splňuje alespoň jednu z níže uvedených charakteristik:
vada v požadovaném dokumentu:
chybějící textová část vyplývající z definované struktury,
textová část neodpovídá skutečnosti popisované entity (např. systému, procesu, chybové zprávě),
vada SW:
způsobuje tak závažné problémy, že další vývoj ani dodržení dohodnutého časového plánu nejsou možné,
vyplývá z nedodržení závazných právních předpisů,
nedodržení či neprokázání realizace nebo jen částečná realizace požadavku uvedeného ve smlouvě a jejích přílohách,
znemožňuje používání dodaného řešení jako celku nebo znemožňuje používání základní funkce/funkcí dodaného řešení podle jeho dokumentace,
znemožňuje používání nebo ovládání dodaného řešení
zapříčiní ztrátu dat,
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,
ohrožuje provoz nebo dostupnost jiné aplikace nebo samotného dodaného řešení v provozním prostředí objednatele,
způsobuje, že dodané řešení není schopno zvládat běžnou provozní zátěž,
za provozních podmínek vede k omezení funkcionality systému s dopadem na významný počet uživatelů.
B – Podstatná vada - vada, kterou je možno dočasně vyřešit organizačním či jiným opatřením a která splňuje alespoň jednu z níže uvedených charakteristik:
vada v požadovaném dokumentu:
nejednoznačnost textové části,
vada SW:
je možné pro její překonání nalézt odpovídající alternativu, která je akceptovatelná objednatelem,
způsobuje, že dodané řešení není schopno zvládat maximální provozní zátěž.
C – Nepodstatná vada - drobná vada, která nemá vliv na provoz systému, tzn., že splňuje alespoň jednu z níže uvedených charakteristik:
vada v požadovaném dokumentu:
je způsobena gramatickou nebo pravopisnou chybou, nevhodným formátováním, překlepy apod.,
vada SW:
je způsobená drobnými konstrukčními nedostatky,
je pouze „kosmetického“ charakteru – tj. taková vada, jejíž výskyt neovlivňuje zásadním způsobem aktivity uživatelů a výstupy z těchto aktivit.
5Akceptační testy
Zahájení akceptačních testů, předání a převzetí plnění je definováno v Článku IV. Smlouvy
5.1Hodnocení
Výsledky jednotlivých testů budou hodnoceny dvěma možnými kategoriemi:
Bez vad
S vadou
Kategorie „s vadou“ bude klasifikována dle kapitoly č. 4 této přílohy, tzn.:
A – Kritická
B – Podstatná
C – Nepodstatná
V případě výskytu stejné vady v různých místech SW řešení SDAT budou tyto vady posuzovány jako jedna a táž vada.
Vady způsobené neodborným zásahem uživatele objednatele nemohou být klasifikovány jako závady.
Kromě toho je možné oznámit/připomínkovat poskytovateli případné vedlejší efekty SW řešení SDAT a nedostatky zjištěné mimo akce popsané v akceptačních testech. Tyto nedostatky je objednatel oprávněn klasifikovat podle kategorie vad.
5.2Akceptace
Akceptační řízení bude považováno za ukončené pouze tehdy, pokud nebude obsahovat žádnou vadu, nerozhodne-li se objednatel přijmout předmět akceptace s výhradami.
Akceptaci s výhradami nelze provést, pokud existuje alespoň 1 vada kategorie A nebo více jak 10 vad kategorie B nebo více jak 50 vad kategorie C. V případě akceptace s výhradami bude přílohou akceptačního protokolu seznam vad včetně lhůty k odstranění každé jednotlivé vady.
5.3Náležitosti akceptačního protokolu
Po ukončení akceptačního řízení bude vytvořen akceptační protokol, který vystaví objednatel. Akceptační protokol musí obsahovat:
Předmět akceptace.
Seznam akceptačních scénářů (pokud v rámci dané etapy/dílčího plnění existují).
Výsledky jednotlivých testů včetně dílčích hodnocení.
Závěr s celkovým hodnocením.
K akceptačnímu protokolu vyhotovenému objednatelem vyjádří poskytovatel své stanovisko nejpozději do 3 pracovních dnů od jeho obdržení. Pokud tak neučiní, má se za to, že s uvedeným závěrem souhlasí.
6Šablona akceptačního protokolu
|
Akceptační protokol
Poskytovatel |
Objednatel |
IČO: DIČ: |
Česká národní banka Na Příkopě 28 115 03 Praha 1
IČO: 48136450 DIČ: CZ48136450 |
Evidenční číslo smlouvy v ČNB: |
|
Název smlouvy: |
|
Předmět akceptace: |
|
Závěr akceptačního řízení |
Shrnutí obsahu akceptačního řízení.
Z výše uvedených důvodů bylo akceptační řízení uzavřeno s výsledkem:
Neakceptováno/Akceptováno s výhradami/Akceptováno
Následné kroky, např.: Poskytovatel akceptoval uvedené vady s tím, že odstraní vady uvedené v příloze č.1 do ........ Fakturaci dle ........ smlouvy lze provést až po odstranění uvedených vad.
Poskytovatel prohlašuje, že poskytl veškeré potřebné licence pro …. …( SW řešení SDAT).
V Praze dne .....................
Za poskytovatele: ...................................., vedoucí projektu
………………………………… Podpis |
Za objednatele: ...................................., věcný zadavatel
………………………………… Podpis
...................................., vedoucí projektu
………………………………… Podpis |
|
Akceptační protokol – Příloha č.1
Seznam vad |
ID |
Kategorie |
Popis vady |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
7Šablona předávacího protokolu
|
Předávací protokol
Poskytovatel |
Objednatel |
IČO: DIČ: |
Česká národní banka Na Příkopě 28 115 03 Praha 1
IČO: 48136450 DIČ: CZ48136450 |
Evidenční číslo smlouvy v ČNB: |
|
Název smlouvy: |
|
Důvod předání: |
|
Předmět předání |
Dnešního dne poskytovatel předal a objednatel převzal za účelem .............................. dle smlouvy (s evidenčním číslem ČNB: .....................) následující dokumenty:
V Praze dne .......................................
Za poskytovatele:
...................................., vedoucí projektu
………………………………… Podpis |
Za objednatele:
...................................., věcný zadavatel
………………………………… Podpis
...................................., vedoucí projektu
………………………………… Podpis
|
8Šablona testovacích scénářů
|
Projekt 7006/2014
“SW ŘEŠENÍ SDAT“
Testovací scénáře
Verze |
|
Datum poslední modifikace |
|
Autor |
|
Vedoucí projektu poskytovatele |
|
Vedoucí projektu objednatele |
|
Tento dokument obsahuje informace důvěrného charakteru a informace v něm obsažené jsou vlastnictvím České národní banky. Žádná část dokumentu nesmí být kopírována, uchovávána v dokumentovém systému nebo přenášena jakýmkoliv způsobem včetně elektronického, mechanického, fotografického či jiného záznamu a uveřejněna či poskytnuta třetí straně bez předchozí dohody a písemného souhlasu vlastníků.
Některé názvy použité v tomto dokumentu mohou být registrovanými ochrannými známkami nebo obchodními značkami, které jsou majetkem svých vlastníků.
Historie změn
Verze |
Datum |
Autor |
Popis změny |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Zdroje
Firma
Jméno
Role
Termín
Akceptační testy budou zahájeny dne ……. a ukončeny dne…..
Příprava a podmínky testů
Testovací prostředí
Testovacím prostředí je testovací prostředí SW řešení SDAT instalované v ČNB dle specifikace uvedené v akceptované realizační studii.
Obsah testovacích scénářů
Testovací scénáře musí obsahovat všechny závazné požadavky uvedené v přílohách č. 1 a 2 smlouvy a vítané požadavky, které se dodavatel v rámci smlouvy zaváže realizovat. Jeden testovací scénář může obsahovat více požadavků.
Provedení testu a jeho vyhodnocení
Scénáře akceptačních testů budou prováděny v pořadí, ve kterém jsou uvedeny v „Seznamu testovacích scénářů“. Z provozních důvodů je možné toto pořadí změnit. Tester provede testy dle testovacích scénářů, vyhodnotí je, zapíše výsledky a případné chyby specifikuje a popíše. Dle potřeby vytvoří k danému testovacímu scénáři přílohu obsahující opisy obrazovek a chybových logů.
Testy budou probíhat pokud možno paralelně, s výjimkou testů administrace a dalších testů, které mohou ovlivnit průběh ostatních testů. Tyto testy budou provedeny samostatně na závěr.
Účast poskytovatele
Testy proběhnou za účasti dostatečného počtu pracovníků poskytovatele.
Seznam testovacích scénářů
Vytvoří poskytovatel v rámci realizační studie.
ID scénáře |
Testovací scénář |
Testované požadavky |
Výsledek1 |
|
|
|
bez vad/s vadou |
|
|
|
|
Jednotlivé testovací scénáře
Vytváří poskytovatel, schvaluje objednatel.
Popis polí testovacího scénáře, která vyplňuje poskytovatel
Název – název testovacího scénáře ve vazbě na testovanou oblast/proces
Verze – verze testovacího scénáře
ID scénáře – pořadové číslo scénáře ve formátu Txx
Popis – stručný popis testované oblasti/procesu
Testované požadavky – seznam testovaných uživatelských požadavků (ID požadavku z příloh č.1 a 2 smlouvy)
Vstupní podmínky - popis podmínek pro realizaci testovacího scénáře, např.: nastavení rolí, způsob přihlášení, dostupnost/připravenost dat apod.
Krok - popis jednotlivých kroků postupu, které bude provádět tester při testování ve struktuře A – požadovaná akce, R – předpokládaná reakce systému
Šablona testovacího scénáře
Název |
|
||||||
ID scénáře |
|
Verze |
|
||||
Popis |
|
||||||
Testované požadavky |
|
||||||
Vstupní podmínky |
|
||||||
Popis kroků |
|||||||
Krok |
Činnost |
Výsledek2 |
|||||
|
|
A: |
|
|
||||
R: |
|
||||||
|
|
A: |
|
|
||||
R: |
|
||||||
|
|
A: |
|
|
||||
R: |
|
||||||
|
|
A: |
|
|
||||
R: |
|
||||||
|
|
A: |
|
|
||||
R: |
|
||||||
Hodnocení3 |
|
||||||
Odůvodnění |
|
||||||
Poznámka |
|
||||||
Datum |
|
Podpis testera |
|
||||
1 Klasifikaci provede objednatel na základě výsledků jednotlivých testů.
2 Hodnota pole „výsledek“ nabývá hodnot „Ok“ pokud systém provedl očekávanou reakci. V opačném případě je hodnotou jedinečný identifikátor chyby v aplikaci Redmine.
3 Nabývá hodnot „Bez vad“/“S vadou“. V případě hodnocení „S vadou“ se uvádí i kategorie vady A/B/C a Odůvodnění klasifikace chyby.
SDAT – Akceptační řízení |
|
11/11 |