¶ 1. Úvod
Tento dokument stanovuje strukturovaný rámec pro navrhování digitálních služeb/systémů a nabízí životní cyklus vývoje systému/softwaru (dále jen rámec), a založený na mezinárodních standardech ISO/IEC/IEEE 12207 a ISO/IEC/IEEE 15288 v nejnovější dostupné verzi.
Rámec podporuje komplexní, interdisciplinární přístup k vývoji softwarových systémů. Cílem je doporučit jednotný pohled pro všechny zainteresovaný strany a zajistit sladění s obchodními cíli, potřebami každé zainteresované strany a technickými požadavky.
Rámec definuje standardizované procesy návrhu systému/softwaru; cíle jednotlivých procesů; definované výstupy; role a odpovědnosti; aktivity a úkoly; pro podporu efektivní komunikace mezi všemi zúčastněnými stranami. Tyto standardizované procesy jsou přizpůsobeny specifickým potřebám veřejné správy a využívají moderní ale jíž ověřené nástroje a metody.
Přístup k vývoji systému/softwaru je založen na evolučním modelu životního cyklu přizpůsobeném agilním metodologiím. Zahrnuje iterativní a souběžné procesy, které řeší neúplné požadavky, usnadňují jejich zpřesňování a umožňují průběžné dodávky ověřeného a provozuschopného systému anebo softwaru.
Procesy a výstupy životního cyklu
Diagram: Procesy a výstupy životního cyklu navrhování digitálních služeb/systémů
Rámec zahrnuje následující procesy návrhu systému/softwaru a definované výstupy:
1. Návrh požadavků: Definuje požadavky na systém/software, rozhraní, kritické výkonnostní ukazatele a zajišťuje jejich sledovatelnost vůči potřebám zainteresovaných stran.
2. Architektonický návrh: Vytváří pohledy na architekturu, definuje hranice systému/softwaru a rozhraní a sladí architekturu s požadavky pro efektivní integraci životního cyklu.
3. Technický návrh: Specifikuje charakteristiky návrhu, přiděluje požadavky a zajišťuje sledovatelnost návrhových artefaktů vůči architektuře.
4. Vývoj: Realizuje a balí prvky systému, identifikuje omezení implementace a zajišťuje sledovatelnost vyvinutých komponent.
5. Integrace systému: Sestavuje prvky systému, ověřuje rozhraní, řeší nesrovnalosti a zajišťuje funkční integritu integrovaného systému/softwaru.
6. Zajištění kvality (QA): Ověřuje, že systém/software splňuje požadavky, identifikuje nesrovnalosti a poskytuje důkazy o souladu s návrhem a architekturou.
7. Nasazení: Připravuje provozní prostředí, školí zainteresované strany a zajišťuje, že je systém připraven k aktivaci a provoznímu použití.
8. Uživatelské akceptační testování (UAT): Ověřuje, že systém splňuje potřeby zainteresovaných stran, a zajišťuje připravenost na provoz prostřednictvím definovaných kritérií a validačních aktivit.
Zainteresované strany
Tento dokument definuje zúčastněné strany formou pojmenovaní týmu (nikoliv počtem osob, z důvodu zachovávaní škálovatelnosti projektu), jejich role a odpovědnosti pro každý proces. Všichni zúčastnění experti mají byt rozděleni do tzv. „pracovních týmů“ a uvedeni v samostatném dokumentu. Odpovědný „pracovní tým“ bude přiřazen k vykonání procesu podle názvu tohoto procesu.
Vizualizaci organizace zainteresovaných stran na základě jejich rolí, vlivu a zapojení do jednotlivých procesů je doporučeno evidovat v samostatném dokumentu – Mapa zainteresovaných stran.
Aplikace metodiky Agile
Tento dokument je určen k aplikaci v projektech využívajících agilní přístupy a metody, stejně jako interpretace požadavků procesů, které jsou vhodné pro běžně používané agilní techniky. Sekvence procesů je určena cíli projektu a výběrem evolučního modelu životního cyklu, navrženého pro metodiky „Agile“. Výběr „evolučního modelu“ má za cíl řešit neúplné znalosti požadavků. Zajišťuje počáteční plánování a definici počáteční architektury, ale přiděluje analýzu požadavků, návrh, konstrukci, verifikaci, validaci a dodávku do série fází. Dodané schopnosti, které nevyhovují potřebám uživatelů, mohou být přepracovány v následujících fázích evoluce. Namísto stanovení hlavních kontrolních bodů na přechodu mezi fázemi nebo procesy, agilní přístup používá méně formální kontrolní body nebo retrospektivní přehledy na konci časově ohraničeného cyklu, kde se dohodnou vylepšení pro následující cyklus. Každá iterace zahrnuje aktivity návrhu, vývoje a testování (test-driven development). Po každé iteraci jsou nové funkční prvky softwaru přijaty jako „hotové“ — zcela vyvinuté, verifikované (testované) a validované. Identifikují se získané zkušenosti a vylepšení procesů, a poté se zahajuje další iterace.
Iterace procesů, rekurze a souběžnost
Když je aplikace stejného procesu nebo souboru procesů opakována na stejné úrovni struktury systému, tato aplikace se označuje jako iterativní. Iterativní použití procesů je důležité pro postupné zpřesňování výstupů procesů. Iterace není pouze vhodná, ale také očekávaná. Nové informace vznikají aplikací procesu nebo souboru procesů. Tyto informace mají formu otázek týkajících se požadavků, analyzovaných rizik nebo příležitostí. Iterativní aplikace procesu nebo souboru procesů by měla pokračovat, dokud tyto otázky nebudou vyřešeny.
¶ 2. Návrh požadavků
Diagram 1: Proces a výstupy procesu návrhu požadavků digitálních služeb/systémů
¶ 2.1 Účel
Účelem procesu návrhu požadavků je převést pohled zainteresovaných stran a uživatelů na požadované schopnosti do technického hlediska řešení, které splňuje provozní potřeby uživatele. Jakmile je softwarový systém rozdělen na jednotlivé prvky, každý prvek je dále analyzován jako systém, funkce nebo soubor funkcí. Tento postup se následně používá k dalšímu zpřesnění požadavků.
¶ 2.2 Výstupy a odpovědné týmy
| Výstupy/Milníky | Název týmu |
| 1) Popis systému nebo prvku, včetně rozhraní, funkcí a hranic, pro systémové řešení je definován. | Analytický tým Product owner |
| 2) Požadavky na systém/software (funkční, výkonnostní, procesní, nefunkční a rozhraní) a návrhová omezení jsou definována. | Analytický tým Product owner |
| 3) Požadavky na systém/software jsou analyzovány. | Datový tým |
| 4) Kritické výkonnostní ukazatele jsou definovány. | Analytický tým Product owner |
¶ 2.3 Aktivity a úkoly
¶ 2.3.1 Příprava na definici požadavků pro systém/software
Tato aktivita zahrnuje následující úkoly:
a) Definice funkčních hranici softwarového systému nebo prvku z hlediska chování a vlastností, které poskytuje.
ROZSAH: Funkční hranice systému vychází z kontextu použití, inženýrských potřeb a požadavků stakeholderů. Zahrnuje vstupy systému, reakce na uživatele/externí systémy a interakce s prostředím (postupy, pořadí, formáty dat, propustnost, časování). Definuje očekávané kvantitativní chování na hranici, typicky přes API, GUI nebo služby včetně formátů dat.
¶ 2.3.2 Definování požadavků na systém/software
Tato aktivita zahrnuje následující úkoly:
a) Definice každé funkci, kterou musí softwarový systém nebo prvek vykonávat.
ROZSAH: Softwarové funkce mohou být popsány v use cases, user stories nebo scénáři; a zahrnují transformaci dat pro splnění požadavků stakeholderů. Někdy vycházejí z kvalitativních charakteristik (výkon, bezpečnost, dostupnost).
b) Určeni požadovaných stavů nebo režimů provozu softwarového systému.
c) Definice nezbytných implementačních omezení.
ROZSAH: Implementační omezení zahrnují podmínky, za kterých musí systém vykonávat funkci, podmínky, za kterých systém začne vykonávat tuto funkci (vstup), a podmínky, za kterých systém přestane vykonávat tuto funkci (výstup).
d) Identifikace požadavků souvisejících s riziky, kritičností systému nebo zásadními kvalitativními charakteristikami.
ROZSAH: Nezbytné požadavky a klíčové kvalitativní charakteristiky obvykle zahrnují ty, které se týkají zdraví, bezpečnosti, zabezpečení a zajištění, spolehlivosti, dostupnosti a udržovatelnosti, a časových omezení pro propustnost a výkon.
e) Definice požadavků na systém/software a atributy požadavků, včetně následujících:
ROZSAH:
i) Datové prvky, datové struktury a formáty, požadavky na databáze nebo uchovávání dat;
ii) Uživatelská rozhraní a uživatelskou dokumentaci (informace pro uživatele) a školení uživatelů;
iii) Rozhraní s jinými systémy a službami;
iv) Funkční a nefunkční charakteristiky, včetně kvalitativních charakteristik a cílů nákladů;
v) Přechod operačních procesů a dat z existujících systémů, přístup k migraci a harmonogram, instalace softwaru a akceptace produktu;
vi) Atributy požadavků, jako je zdůvodnění; priorita; sledovatelnost na prvky systému, testovací případy a informační položky; metody ověření; zařazení do schválených výchozích základů; a vyhodnocené riziko.
POZNÁMKA (ITERACE): Definování požadavků je iterativní proces prováděný paralelně s dalšími životními cykly.
¶
2.3.3 Analýza požadavků na systém/software
Tato aktivita zahrnuje následující úkoly:
a) Analýza kompletního souboru požadavků na systém/software.
ROZSAH: Potenciální charakteristiky analýzy zahrnují, že požadavky jsou nezbytné, bez implementačních překážek, jednoznačné, konzistentní, úplné, singulární, realizovatelné, sledovatelné, ověřitelné, finančně dostupné a ohraničené. V některých případech se hodnotí technická a ekonomická proveditelnost a ověřování alternativních formulací požadavků. POZNÁMKA: Některé požadavky mohou být realizovány postupně, případně mohou být odloženy nebo zrušeny. Z tohoto důvodu je nezbytné stanovit priority jednotlivých požadavků.
b) Definice klíčových ukazatelů výkonu, které umožní hodnocení technického dosažení.
ROZSAH: Tento proces zahrnuje definování technických a kvalitativních ukazatelů a kritických výkonnostních parametrů souvisejících s každým měřítkem účinnosti uvedeným v požadavcích na prvky systému, jako jsou například měření výkonu a technické výkonnostní ukazatele.
c) Předáni analyzovaných požadavků relevantním zainteresovaným stranám ke kontrole.
ROZSAH: Proces zpětné vazby na tomto etapu určen pro zjištěni, že specifikované požadavky byly dostatečně zachyceny a adekvátně vyjádřeny. Potvrzuje, že představují nezbytnou a dostatečnou odpověď na požadavky všech zainteresovaných stran, a jsou také nezbytným a dostatečným vstupem pro následné procesy.
d) Identifikace a řešení problémů, nedostatků, konfliktů a slabin v kompletním souboru požadavků.
ROZSAH: To zahrnuje požadavky, které nelze ověřit, jsou nejednoznačné, nesplňují charakteristiky jednotlivých požadavků nebo jsou v rozporu s jinými požadavky ve sbírce.
POZNÁMKA (ITERACE): Řešení problémů s požadavky může být iterativní proces.
¶
2.3.4 Správa systémových a softwarových požadavků.
Tato aktivita zahrnuje následující úkoly:
a) Získaní souhlasu s požadavky na systém/software.
ROZSAH: Údržba požadavků zahrnuje definování, zaznamenávání a kontrolu základní verze (baseline), spolu s řízením změn vyplývajících z aplikace jiných procesů životního cyklu, jako je architektura nebo návrh.
b) Poskytovaní klíčových artefaktů a informace vybrané pro základní verzi.
¶ 3. Architektonický návrh
Diagram 2: Proces a výstupy návrhu architektury digitálních služeb a systémů
¶ 3.1 Účel
Proces architektonického návrhu systému má za účel vytvořit a vybrat architekturu, která splňuje požadavky a obavy zainteresovaných stran a představit ji v konzistentních pohledech a modelech. Architektura definuje logicky propojené a konzistentní řešení na základě principů a konceptů.
¶
3.2 Výstupy a odpovědné týmy
| Výstupy/Milníky | Název týmu |
| 1) Kontext, hranice a externí rozhraní systému jsou definovány. | Product owner |
| 2) Koncepty, vlastnosti, charakteristiky, chování, funkce nebo omezení, které jsou významné pro architektonická rozhodnutí systému, jsou přiřazeny k architektonickým entitám. | Vývojový tým Datový tým |
| 3) Architektonické pohledy a modely systému jsou vytvořeny. | Vývojový tým Datový tým |
| 4) Systémové prvky a jejich rozhraní jsou identifikovány. | Vývojový tým Datový tým |
¶ 3.3 Aktivity a úkoly
¶ 3.3.1 Příprava na definici architektury
Tato aktivita zahrnuje následující úkoly:
a) Analýza relevantní informace a identifikace klíčových faktorů ovlivňujících architektonické rozhodování.
ROZSAH: Klíčové faktory jsou určeny analýzou následujících oblastí jako projekce trendů v průmyslu a vědeckých poznatků; organizační strategie, koncepce operací na úrovni organizace, organizační politiky a směrnice, regulační a právní omezení, a požadavky zainteresovaných stran; mise nebo obchodní koncepty operací, systémy a jejich operační koncepty, operační prostředí, technologické mapy a požadavky na systém; a další faktory ovlivňující vhodnost systému během jeho životního cyklu.
b) Určeni obav zainteresovaných stran.
ROZSAH: Obavy zúčastněných stran se často týkají životního cyklu systému, jako je např. dostupnost, bezpečnost, účinnost, použitelnost, interoperabilita s existujícími systémy, dostupnost nebo rizika pro data v systému, distribuce, testovatelnost a odstavení (např. eradikace nebo uchovávání citlivých dat); podpory, např. podpora systému během jeho očekávané životnosti, řízení zastarávání; evoluci (informačního/softwarového) systému a jeho prostředí, např. adaptabilita, škálovatelnost, přežití;
c) Stanoveni plánu, přístupů a strategii pro definici architektury.
ROZSAH: Plán ukazuje, jakým způsobem se architektura bude vyvíjet k zamýšlenému konečnému stavu. Přístup definuje metody, jakými bude práce vykonána, například komunikační postupy se zúčastněnými stranami, ověřování výsledků nebo místo výkonu práce. Strategie se týká systematického plánu akcí pro implementaci přístupu v souladu s plánem.
d) Definovaní kritérií pro hodnocení architektury podle zájmů zúčastněných stran a klíčových požadavků.
¶ 3.3.2 Vytvořeni architektonických pohledů
Tato aktivita zahrnuje následující úkoly:
a) Vyber, přizpůsobeni nebo vývoj pohledů a typy modelů na základě požadavků zúčastněných stran.
b) Stanoveni nebo identifikace potenciálních architektonických rámců, které budou použity při vývoji modelů a pohledů.
c) Zaznamenaní důvodů pro výběr rámců, perspektiv a typů modelů.
d) Zvoleni nebo vývoj vhodných technik modelování a nástroje.
¶ 3.3.3 Vytvořeni modelů a pohledů na alternativní (kandidátské) architektury
Tato aktivita zahrnuje následující úkoly:
a) Definice kontextu a hranic systému včetně rozhraní a interakcí s externími entitami.
ROZSAH: Tento úkol spočívá v identifikaci entit externích k danému systému (tj. existujících a plánovaných systémů, produktů a služeb, které tvoří kontext systému) a definování hranic softwarového systému (tj. interakcí s těmito externími entitami prostřednictvím rozhraní, která tyto hranice překračují). Proces návrhu architektury rozhraní definuje do té míry, jak je to potřeba pro podporu klíčových architektonických rozhodnutí a porozumění, a následně upřesněna technickým návrhem.
b) Identifikace architektonických entit a vztahů mezi těmito entitami, které řeší zásadní obavy a klíčové požadavky na systém.
ROZSAH: Architektura se zaměřuje na požadavky systému/softwaru, které ovlivňují architekturu, zatímco technický návrh zohledňuje všechny požadavky.
POZNÁMKA (ITERACE): Řešení problémů nevhodných nebo neefektivních požadavků může být iterativní proces a řeší se iterací procesu návrhu požadavků.
c) Alokace pojmů, vlastností, charakteristik, chování, funkce nebo omezení důležité pro architektonická rozhodnutí softwarového systému na příslušné architektonické entity.
ROZSAH: Předměty alokace mohou být fyzické, logické nebo koncepční povahy.
d) Vyber, přizpůsobeni nebo vývoj modelů kandidátských architektur softwarového systému. ROZSAH: Vhodné modely jsou ty, které nejlépe řeší klíčové obavy a požadavky zúčastněných stran.
e) Sestaveni pohledů z modelů podle identifikovaných pohledových bodů, aby se ukázalo, jak architektura řeší obavy a splňuje požadavky zúčastněných stran.
f) Sladěni architektonických modelů a perspektiv pro zajištění jejich vzájemné konzistence.
¶ 3.3.4 Integrace architektury a návrhu
Tato aktivita zahrnuje následující úkoly:
a) Identifikace prvků informačního/softwarového systému, které odpovídají architektonickým entitám, a povahu těchto vztahů.
b) Definice rozhraní a interakce mezi prvky softwarového systému a externími entitami.
ROZSAH: Toto je definováno na úrovni detailu potřebného k vyjádření architektonického záměru a může být dále upřesněno v procesu technického návrhu.
c) Rozděleni, sladěni a přiděleni požadavků jednotlivým architektonickým entitám a prvkům systému.
d) Zmapovaní prvků softwarového systému a architektonické entity na charakteristiky návrhu.
e) Definice principů pro návrh a vývoj informačního/softwarového systému.
ROZSAH: Principy mohou zahrnovat interoperabilitu, použití specifických návrhových vzorců, snadnost nahrazování a aktualizace systémových prvků nebo úrovně bezpečnosti.
¶ 3.3.5 Posouzení kandidátských architektur
Tato aktivita zahrnuje následující úkoly:
a) Posouzení každé kandidátské architektury z hlediska omezení a požadavků.
b) Posouzení každé navržené architektury z pohledu zájmů zainteresovaných stran s použitím hodnotících kritérií.
c) Zvoleni preferované architektury a zaznamenaní klíčových rozhodnutí spolu s odůvodněním.
d) Stanoveni základní (baseline) architekturu (baseline).
ROZSAH: Základní (baseline) architektura se skládá z modelů, pohledů a dalších relevantních popisů architektury.
¶ 3.3.6 Správa vybrané architektury
Tato aktivita zahrnuje následující úkoly:
a) Formalizovaní přístupu k řízení architektury a specifikovat role a odpovědnosti spojené s řízením, včetně odpovědností a pravomocí týkajících se návrhu, kvality, bezpečnosti a ochrany.
b) Zajištění souhlasu zainteresovaných stran s architekturou.
c) Zajištění shody a úplnosti architektonických entit a jejich charakteristik.
ROZSAH: Kromě technických je třeba zkontrolovat také právní, ekonomické, organizační a provozní entity dle obav a požadavků zainteresovaných stran.
d) Organizovaní, hodnocení a řízení vývoje architektonických modelů a pohledů s cílem zajistit, že architektonický záměr bude splněn a architektonická vize a klíčové koncepty budou správně implementovány.
e) Udržovaní strategii pro definici a hodnocení architektury.
ROZSAH: To zahrnuje aktualizaci architektury na základě technologických změn (např. zastarání), implementačních nebo provozních zkušeností, správu externích a interních rozhraní, která jsou definována na této úrovni dekompozice systému.
f) Poskytovaní klíčové artefakty a informace vybrané pro základní verze.
¶ 4. Technický návrh
Diagram 3: Proces a výstupy technického návrhu digitálních služeb a systémů
¶ 4.1 Účel
Účelem procesu technického návrhu je poskytnout dostatečně podrobné údaje a informace o systému a jeho komponentech, které umožní implementaci v souladu s architektonickými entitami definovanými v modelech a pohledech systémové architektury. Návrhové aktivity mohou být iterativní a mohou probíhat souběžně s aktivitami v procesech definice systémových a softwarových požadavků a definice architektury. Definice návrhu může být aplikována iterativně a inkrementálně k rozvoji podrobného návrhu, zahrnujícího softwarové komponenty, rozhraní, databáze a uživatelskou dokumentaci.
¶ 4.2 Výstupy a odpovědné týmy
| Výstupy/Milníky | Název týmu |
| 1) Systémové/softwarové požadavky jsou přiřazeny systémovým prvkům. | Vývojový tým |
| 2) Jsou definovány konstrukční charakteristiky každého prvku systému. | Vývojový tým |
| 3) Rozhraní mezi prvky systému tvořícími systém jsou definována nebo zpřesněna. | Vývojový tým |
| 4) Vyvíjejí se designové artefakty. | Vývojový tým |
| 5) Kdispozici jsou jakékoli aktivační systémy nebo služby potřebné pro definici návrhu. | Vývojový tým |
¶ 4.3 Aktivity a úkoly
¶ 4.3.1 Příprava na definici návrhu softwarového systému
Tato aktivita zahrnuje následující úkoly:
a) Definovaní návrhové strategii, která je v souladu s vybraným modelem životního cyklu a předpokládanými návrhovými artefakty.
ROZSAH: Strategie návrhu může zahrnovat počáteční nebo postupné rozdělení na prvky systému, vytvoření různých pohledů na automatizované procedury, datové struktury a řídicí systémy, výběr návrhových vzorců nebo postupné podrobnější definování objektů a jejich vztahů.
b) Vyber a stanoveni priorit návrhových principů a vlastností.
ROZSAH: Návrhové principy zahrnují klíčové koncepty, jako jsou abstrakce, modularizace a enkapsulace, oddělení rozhraní od implementace, paralelismus a perzistence dat. Bezpečnostní úvahy zahrnují zásadu nejmenších privilegií, vrstvenou obranu, omezený přístup k systémovým službám a další opatření zaměřená na minimalizaci a ochranu proti útokům na systém. Mezi návrhové charakteristiky patří například dostupnost, odolnost proti chybám a robustnost, škálovatelnost, použitelnost, kapacita, výkon, testovatelnost, přenositelnost a cenová efektivnost.
c) Identifikace a naplánovaní potřebné podpůrné systémy nebo služby k podpoře definice návrhu.
ROZSAH: To zahrnuje identifikaci požadavků a rozhraní pro podpůrné systémy. Podpůrné systémy pro definici návrhu zahrnují výběr softwarových a systémových platforem, programovacích jazyků, návrhových notací a nástrojů pro spolupráci a vývoj návrhu, úložiště pro opětovné použití návrhů (pro produktové řady, návrhové vzory a návrhové artefakty) a návrhové standardy.
d) Získaní nebo zajistit přístup k podpůrným systémům nebo službám, které budou využity.
¶ 4.3.2 Vytváření návrhů souvisejících s jednotlivými prvky softwarového systému
Tato aktivita zahrnuje následující úkoly:
a) Transformace architektonických a návrhových charakteristik do návrhu prvků softwarového systému.
ROZSAH: Charakteristiky se vztahují k fyzickým a logickým prvkům systému, zahrnujícím struktury databází, přidělení paměti a úložiště, softwarové procesy a řízení, jakož i externí rozhraní, například uživatelská rozhraní nebo služby.
b) Definování a zajištění nebo příprava nezbytných podpůrných nástrojů pro návrh.
ROZSAH: Podpůrné nástroje pro návrh zahrnují modely, rovnice, algoritmy, výpočty, formální výrazy a parametrové hodnoty, vzory a heuristiky, které jsou spojeny s návrhovými charakteristikami vhodnou reprezentací. Těmito reprezentacemi mohou být výkresy, logické diagramy, vývojové diagramy, konvence kódování, logické vzory, informační modely, obchodní pravidla, uživatelské profily, scénáře, případy použití nebo uživatelské příběhy a tabulky metrik a jejich hodnot, například funkční body nebo body uživatelských příběhů.
c) Prozkoumání alternativ návrhu a proveditelnosti implementace.
ROZSAH: Pro softwarový systém a jeho prvky se běžně zkoumá opětovné použití, adaptace, outsourcingová služba nebo nový vývoj.
d) Upřesnění nebo definování rozhraní mezi prvky softwarového systému a externími entitami.
ROZSAH: Rozhraní identifikována a definována na etapě architektonického návrhu jsou dále upřesněna v procesu technického návrhu na základě návrhových charakteristik, rozhraní a interakcí prvků softwarového systému s ostatními složkami tvořícími software a s externími entitami.
e) Tvorba návrhových artefaktů.
ROZSAH: Tento úkol formalizuje návrhové charakteristiky prvků softwarového systému prostřednictvím dedikovaných artefaktů v závislosti na technologii implementace. Příklady artefaktů zahrnují prototypy, datové modely, pseudokód, diagramy entit a vztahů, případy použití, matice uživatelských rolí a oprávnění, specifikace rozhraní, popisy služeb a procedury.
¶ 4.3.3 Hodnocení alternativ pro získání prvků softwarového systému
Tato aktivita zahrnuje následující úkoly:
a) Identifikace technologií potřebných pro každý prvek tvořící informační/softwarový systém.
ROZSAH: Pro konkrétní prvek informační/softwarový systému je občas využíváno více technologií, například internetová přítomnost, vestavěné systémy, adaptace open source softwaru nebo role lidských operátorů.
b) Identifikace kandidátských alternativ pro prvky informační/softwarový systému.
ROZSAH: Alternativy zahrnují nově navržené a vyrobené položky; adaptace stávajících produktových řad, komponent, objektů nebo služeb; či pořízení nebo znovupoužití položek jako nakup již existující komerčního nebo open source balíčků či prvků, znovupoužití předchozího návrhu nebo existujících aktiv včetně položek poskytnutých kupujícím.
c) Hodnoceni každé kandidátské alternativy podle kritérií vyvinutých na základě očekávaných návrhových charakteristik a požadavků na prvek, aby se určila její vhodnost pro zamýšlenou aplikaci.
ROZSAH: Rozhodnutí o výrobě nebo koupi a související přístup k implementaci a integraci zahrnují kompromisy návrhových kritérií, včetně nákladů. Návrhové volby zohledňují systémy potřebné k testování kandidátské alternativy (návrh a vývoj řízený testy) a udržitelnost během životního cyklu systému, včetně nákladů na údržbu. Proces údržby určuje vhodnost návrhu pro dlouhodobou údržbu a udržitelnost.
d) Vyber preferované alternativy z kandidátských návrhových řešení pro jednotlivé prvky softwarového systému.
¶ 4.3.4 Správa návrhu
Tato aktivita zahrnuje následující úkoly:
a) Dokumentace návrh a jeho odůvodnění.
ROZSAH: Obvykle zaznamenávané informace zahrnují prvky systému a související požadavky a návrhová data, například pro softwarové prvky, interní a externí rozhraní, datové struktury, požadavky na implementaci a testování, agregovaná data jednotek pro integraci a testovací případy. Odůvodnění obvykle obsahuje informace o hlavních implementačních možnostech a podpůrných systémech. Výsledný návrh je řízen v souladu se stanovenou strategií.
b) Zajištění sledovatelnosti mezi podrobnými návrhovými prvky, systémovými a softwarovými požadavky a architektonickými entitami v architektuře softwarového systému.
ROZSAH: Tento úkol může zjednodušit provedeni možných úprav, jako je například změna alokace prvků softwarového systému za účelem dosažení požadovaných architektonických vlastností; nebo případně pro úpravu očekávaných architektonických vlastností vzhledem k faktorům zjištěným během návrhového procesu, či pro informování zúčastněných stran o možných dopadech.
c) Určení stavu návrhu informačního/softwarového systému a jeho komponent.
POZNÁMKA (ITERACE): Toto zahrnuje pravidelné hodnocení návrhových vlastností během vývoje systému a jeho architektury, stejně jako předpovědi potenciální zastaralosti komponent a technologií; jejich náhradu jinými v průběhu životního cyklu softwarového systému a důsledky pro definici návrhu.
d) Poskytovaní klíčových artefaktů a informačních položek, které byly vybrány pro základní verze.
¶ 5. Vývoj
Diagram 4: Proces a výstupy vývoje digitálních služeb a systémů
¶ 5.1 Účel
Účelem procesu vývoje je realizace specifikovaného prvku systému. Tento proces přetváří požadavky, architekturu a návrh, včetně rozhraní, do akcí vedoucích k vytvoření prvku systému podle praktik zvolené implementační technologie, využívajících vhodné technické specializace nebo disciplíny. Tento postup má za výsledek vytvoření prvku systému, který splňuje stanovené systémové požadavky (včetně alokovaných a odvozených požadavků), architekturu a návrh.
¶ 5.2 Výstupy a odpovědné týmy
| Výstupy/Milníky | Název týmu |
| 1) Všechna potřebná podporující systémová řešení nebo služby pro implementaci jsou k dispozici. | Vývojový tým Product owner |
| 2) Implementační omezení, která ovlivňují požadavky, architekturu nebo návrh, jsou identifikována. | Vývojový tým |
| 3) Prvek systému je realizován. | Vývojový tým |
| 4) Prvek systému je zabalen nebo uložen. | Vývojový tým |
¶ 5.3 Aktivity a úkoly
¶ 5.3.1 Příprava na implementaci
Tato aktivita se skládá z následujících úkolů:
a) Definice strategii implementace s ohledem na následující aspekty:
i) Politiky a standardy pro vývoj, zahrnující normy týkající se bezpečnosti, ochrany soukromí a environmentálních praktik; standardy programování a kódování; směrnice pro jednotkové testování a specifické standardy pro implementaci bezpečnostních funkcí v jednotlivých programovacích jazycích.
ii) Pro opětovně použité nebo upravené softwarové komponenty metody pro určení úrovně, zdroje a vhodnosti těchto systémových prvků, včetně zajištění bezpečnosti dodavatelského řetězce.
iii) Postupy a metodiky pro vývoj softwaru a vytváření jednotkových testů, včetně použití kolegiálních recenzí, jednotkových testů a průchodů během procesu implementace.
iv) Implementace řízení změn (Change Management) během vývoje systému.
v) Zohlednění řízení změn pro manuální procesy.
vi) Priority implementace podporující migraci dat a softwaru, přechodová opatření a vyřazování zastaralých systémů.
vii) Vytvoření manuálních nebo automatizovaných testovacích procedur k ověření, že softwarová jednotka splňuje své požadavky před jejím vytvořením (testováním řízený vývoj).
viii) Zavedení komplexního nebo specializovaného prostředí pro vývoj životního cyklu a podporu realizace a řízení požadavků, modelů a prototypů, dodávaných systémových nebo softwarových prvků, specifikací testů a testovacích případů.
b) Identifikace omezení vyplývající ze strategie implementace a implementační technologie na systémové nebo softwarové požadavky, charakteristiky architektury, charakteristiky návrhu nebo implementační techniky.
ROZSAH: Omezení zahrnují aktuální nebo očekávaná omezení zvolené implementační technologie, např. operační systém pro software, databázový systém, webové služby, materiály nebo systémové prvky poskytnuté zákazníkem pro adaptaci, a také omezení vyplývající z použití požadovaných podpůrných systémů pro implementaci.
c) Identifikace a plánovaní potřebných softwarových prostředí, včetně podpůrných systémů nebo služeb nezbytných pro podporu vývoje a testování.
ROZSAH: Software se obvykle implementuje v oddělených prostředích, která jsou konfiguračně oddělena od operačního (produkčního) prostředí. Mezi běžné podpůrné systémy a služby pro proces vývoje patří komplexní nebo specializovaná prostředí pro celkový životní cyklus vývoje a podporu realizace a správy požadavků, modelů a prototypů. Zahrnuje také dodávané prvky, testovací prostředí, specifikace a testovací případy; simulátory externích systémů, tréninkové systémy; a systémy pro správu obsahu uživatelské dokumentace.
d) Získání přístupu k softwarovým prostředím a dalším podpůrným systémům či službám.
ROZSAH: Tento úkol je určen primárně k zabezpečeni procesu uživatelského akceptačního testování (User Acceptance Testing - UAT) slouží k objektivnímu ověření, že integrační podpůrný systém plní své zamýšlené podpůrné funkce.
¶ 5.3.2 Implementace
Tato aktivita se skládá z následujících úkolů:
a) Implementace nebo modifikace komponent systému v souladu se strategií, omezeními a stanovenými implementačními postupy.
ROZSAH: Systémové prvky mohou být získány, identifikovány pro opětovné použití z organizačních aktiv nebo vyvinuty (konstruovány) anebo z nákupu již hotového produktu Implementace může zahrnovat kódování softwaru, adaptivní opětovné použití a integraci stávajících jednotek, refaktoring, vývoj databáze a konstrukci manuálních nebo automatizovaných testovacích procedur pro každou jednotku.
Modifikace zahrnuje konfiguraci softwarových prvků, které jsou znovu použity nebo upraveny.
Softwarové prvky, které jsou vyvíjeny jako spustitelné softwarové jednotky, mohou zahrnovat přidružené datové struktury, aplikační programovací rozhraní, popisy služeb, uživatelskou dokumentaci, testovací případy nebo jiné prvky. Jsou řízeny, zpřístupněny autorizovaným rolím a ukládány podle procedur řízení konfigurace pro vývojové artefakty.
b) Implementace nebo úprava servisních komponent softwarových systémů.
ROZSAH: Servisní komponenty zahrnují seznam služeb, které mají být poskytovány.
c) Posouzeni softwarových jednotek a souvisejících dat či další informace v souladu s implementační strategií a stanovenými kritérii.
ROZSAH: Kritéria pro vyhodnocení obvykle zahrnují splnění požadavků na jednotku a testovací kritéria, pokrytí jednotkovými testy, požadavky na sledovatelnost, konzistenci s požadavky na softwarové prvky nebo návrh, vnitřní konzistenci požadavků na jednotky a proveditelnost pro další procesní aktivity, jako jsou integrace, ověřování, validace, provoz a údržba.
d) Vytvářeni softwarových balíčků (popř. kontejnerizace) a ukládání komponent systému.
ROZSAH: Zajištěni softwarových prvku tak, aby byly zachovány všechny jejich charakteristiky. Přeprava, přesun a ukládání, včetně jejich trvání, mohou ovlivnit specifikovanou ochranu. Hlavní kopie implementovaného softwaru (elektronicky nebo na fyzických médiích) musí být uložena na řízeném místě a přístupná pouze autorizovaným osobám, např. pro použití při procesech integrace a nasazení. Informace o konfiguraci a produktu jsou zaznamenávány procesy řízení konfigurace a řízení informací při ukládání prvku.
e) Dokumentace objektivních důkazů, že softwarová komponenta systému splňuje stanovené požadavky.
ROZSAH: Důkazy zahrnují úpravy prvků provedené v důsledku změn zpracování nebo neshod zjištěných během procesů ověření a validace. Objektivní důkazy jsou součástí základní konfigurace prvku, která je stanovena prostřednictvím procesu řízení konfigurace, a zahrnují výsledky jednotkových testů, analýz, inspekcí, demonstrací, produktových nebo technických revizí či jiných ověřovacích cvičení.
¶ 5.3.3 Řízení výsledků implementace
Tato aktivita se skládá z následujících úkolů:
a) Zaznamenaní výsledků implementace a identifikovaných anomálií.
ROZSAH: Zahrnuje registrace anomálie způsobené implementační strategií, implementačními systémovými nástroji nebo nesprávnou definicí softwarového systému.
b) Poskytovaní základních artefaktů a informací vybraných pro výchozí verze (baseline).
¶ 6. Integrace systému
Diagram 5: Proces a výstupy integrace systémových prvků digitálních služeb a systémů
¶ 6.1 Účel
Účelem procesu integrace systému je syntetizovat soubor systémových prvků do funkčního systému (produktu nebo služby), který splňuje technické a softwarové požadavky, architektonické specifikace a designové koncepty. Tento proces zahrnuje sestavení implementovaných systémových prvků. Rozhraní jsou identifikována a aktivována tak, aby umožnila vzájemnou spolupráci jednotlivých komponent podle jejich zamýšleného účelu.
¶ 6.2 Výstupy a odpovědné týmy
| Výstupy/Milníky | Název týmu |
| 1) Jsou identifikována omezení integrace, která ovlivňují systémové požadavky, architekturu nebo design, včetně rozhraní. | Vývojový tým Datový tým |
| 2) Jednotlivě implementované systémové prvky jsou sestaveny a kombinovány do kompletního, funkčního systému. | Vývojový tým Datový tým |
| 3) Rozhraní mezi implementovanými systémovými prvky, které tvoří systém, jsou ověřena. | Vývojový tým |
| 4) Rozhraní mezi systémem a vnějším prostředím jsou ověřena. | Vývojový tým |
¶ 6.3 Aktivity a úkoly
¶ 6.3.1 Příprava na integraci
Tato aktivita se skládá z následujících úkolů:
a) Stanovení integrační strategii.
ROZSAH: Integrace vytváří postupně úplnější konfigurace systémových prvků softwaru nebo softwarových položek. Tento proces závisí na dostupnosti příslušných systémových prvků softwaru a řídí se strategií izolace závad a diagnostiky. Implementace systémových prvků softwaru během integrace je založena na prioritách souvisejících požadavků a definici architektury, přičemž se obvykle zaměřuje na rozhraní a minimalizuje čas, náklady a rizika spojená s integrací. Během tohoto procesu je správa verzí zachována prostřednictvím správy konfigurací pro výběr konfiguračních položek určených k integraci.
b) Stanovení a definice kritérií pro integraci, jakož i identifikovat mezníky, ve kterých bude ověřována správná funkčnost a integrita rozhraní a vybraných funkcí softwarového systému.
c) Určení omezení integrace, která by měla být zohledněna v požadavcích na systém/software, architekturu nebo design.
ROZSAH: To zahrnuje požadavky na přístupnost, bezpečnost dodavatelského řetězce, bezpečnost pro integrátory, požadovaná propojení pro sady implementovaných systémových prvků softwaru a umožňující systémy, a omezení rozhraní.
¶ 6.3.2 Provedení integrace. Postupně integrujte konfigurace systémových prvků softwaru až do úplné syntézy celého systému.
Tato aktivita se skládá z následujících úkolů:
a) Zajištění, aby prvky softwarového systému byly implementovány v souladu s dohodnutými harmonogramy.
b) Integrace implementovaných prvků.
ROZSAH: Integrace implementovaných prvků může zahrnovat propojení objektového kódu nebo metodické spojení jednotlivých implementovaných částí, které tvoří součást softwarové konfigurace. Softwarové komponenty se kompilují do sestavy (build), aby bylo zajištěno správné propojení nebo sloučení větvených jednotek v jediné sestavě. V případech, kdy nejsou softwarové funkce dostupné pro integraci, lze použít emulovanou funkcionalitu (stub nebo scaffolding) jako dočasnou podporu pro integraci softwarových prvků nebo pro simulaci vstupu z externích rozhraní.
c) Ověřeni, že integrovaná softwarová rozhraní nebo funkce provádějí své úkoly od začátku do konce v rámci předpokládaných hodnot dat.
ROZSAH: Vybrané prvky softwarového systému jsou kontrolovány jako součást akceptace implementovaných prvků, aby byla zajištěna jejich shoda s akceptačními kritérii uvedenými v integrační strategii a příslušných dohodách. Kontrola zahrnuje ověření shody s dohodnutou konfigurací, kompatibility rozhraní a přítomnosti povinných informačních položek.
¶ 6.3.3 Správa výsledků integrace
Tato aktivita se skládá z následujících úkolů:
a) Zaznamenaní výsledků integrace a identifikovaných anomálii.
ROZSAH: Toto zahrnuje anomálie způsobené integrační strategií, integračními podpůrnými systémy, provedením integrace nebo nesprávnou definicí systému či jeho prvků. Pokud existují nesrovnalosti na rozhraní mezi systémem, jeho specifikovaným operačním prostředím a systémy, které umožňují fázi využívání, tyto odchylky vedou k nápravným opatřením.
b) Poskytovaní klíčových artefaktů a informací, které byly vybrány pro základní verze (baseline).
¶ 7. Zajištění kvality (Quality Assurance - QA) nebo Testování (Verifikační proces)
Diagram 6: Proces a výstupy zajištění kvality návrhu digitálních služeb a systémů
¶ 7.1 Účel
Účelem zajištění kvality (QA) je poskytnout objektivní důkazy, že systém nebo jeho prvky splňují specifikované požadavky a charakteristiky. Proces QA identifikuje anomálie, jako jsou chyby, závady či poruchy, v jakékoli informační položce, například v systémových/softwarových požadavcích nebo popisu architektury, stejně jako ve implementovaných prvcích systému nebo životních cyklech procesů. K tomu využívá vhodné metody, techniky, standardy nebo pravidla.
POZNÁMKA:
• Verifikace (QA) zajišťuje, že „produkt je postaven správně“;
• Validace (UAT) zajišťuje, že „správný produkt je postaven“.
¶ 7.2 Výstupy a odpovědné týmy
| Výstupy/Milníky | Název týmu |
| 1) Jsou identifikována omezení verifikace, která mají vliv na požadavky, architekturu nebo design. | Testovací tým |
| 2) Systém nebo jeho prvky jsou ověřovány. | Testovací tým |
| 3) Byla nahlášena data poskytující informace pro nápravná opatření. | Testovací tým Vývojový tým |
| 4) Jsou poskytnuty objektivní důkazy, že implementovaný systém splňuje stanovené požadavky, architekturu a designové specifikace. | Testovací tým Analytický tým |
| 5) Byly identifikovány výsledky verifikace a anomálie. | Testovací tým Vývojový tým |
¶ 7.3 Aktivity a úkoly
¶
7.3.1 Příprava na verifikaci
Tato aktivita se skládá z následujících úkolů:
a) Návrh strategii testovaní, která zahrnuje následující kroky:
i) Identifikace rozsahu testovaní, který zahrnuje softwarový systém, prvek nebo artefakt, vlastnosti, které mají být verifikovány, a očekávané výsledky.
ROZSAH: Celkový rozsah verifikace zahrnuje softwarový systém nebo prvky systému, včetně rozhraní. Pro každou verifikační akci rozsah identifikuje softwarový systém, prvek nebo artefakt, který má být verifikován (např. skutečný systém, model, maketa, prototyp, kód, postup, plán nebo jiný dokument) a očekávané výsledky, jako je shoda, výkon, odolnost proti chybám a obnova po přerušení služby. Vlastnosti, které mají být verifikovány, mohou zahrnovat požadavky, charakteristiky architektury a designu, integraci a přesnost dokumentace. Charakteristiky designu mohou zahrnovat bezpečnostní aspekty designu v kontextu plánovaného operačního prostředí a dosažení kritických kvalitativních charakteristik uvedených v požadavcích.
ii) Identifikace omezení, která mohou potenciálně omezit proveditelnost verifikačních akcí. Omezení mohou zahrnovat technickou proveditelnost, náklady, čas, dostupnost verifikačních nástrojů či kvalifikovaného personálu, smluvní omezení a charakteristiky, jako je kritičnost úkolu. Tato omezení často ovlivňují stanovení verifikační strategie, například zda je nutné nebo oprávněné provést nezávislou verifikaci.
iii) Identifikace verifikačních priorit. U softwarových systémů je obvykle neproveditelné ověřit všechny možné scénáře (100% pokrytí kódu). Verifikační strategie obvykle zahrnuje vyvážení toho, co bude ověřeno (rozsah) vůči omezením, a určení, jaké verifikační akce provést a kolik iterací verifikačních akcí a oprav je třeba provést, aby se snížilo riziko. Přístup založený na modelovém testování může umožnit generování a správu více scénářů. Potenciální verifikační akce, které jsou kandidáty na zrušení, jsou vyhodnoceny podle rizik, která jejich zrušení přinese.
b) Identifikace omezení vyplývající z verifikační strategie, která mají být zohledněna v požadavcích na systém/software, architekturu nebo design.
Poznámka: Toto zahrnuje praktická omezení přesnosti, nejistoty, opakovatelnosti, jež jsou uložena verifikačními nástroji, související měřicí metodiky, potřebu integrace softwarového systému a dostupnost, přístupnost a propojení s verifikačními nástroji.
c) Stanovení účelu, podmínek a kritérii shody pro každou ověřovací akci.
d) Vyber vhodných metod nebo technik verifikace a související kritéria pro verifikační akce, jako je inspekce, analýza, demonstrace nebo testování.
ROZSAH: Výběr metod nebo technik verifikace závisí na typu systému, účelu verifikace, cílech projektu a přijatelných rizicích. Metody nebo techniky verifikace zahrnují inspekci (včetně procházek kódem a peer review), analýzu (včetně modelování a simulace, a analýzu/srovnání), demonstraci a dynamické a statické testování.
¶ 7.3.2 Provést verifikaci
Tato aktivita se skládá z následujících úkolů:
a) Definice verifikačních postupů, z nichž každý podporuje jednu nebo více verifikačních akcí.
ROZSAH: Verifikační postupy, které mohou být prováděny automatizovanými skripty, zahrnují požadavky, které mají být ověřeny, typ softwarového systému nebo artefaktu, který má být ověřen (např. skutečný systém, model, maketa, prototyp, kód, postup, plán nebo jiný informační artefakt), a očekávané výsledky (kritéria úspěchu), jako je shoda nebo výkon funkce nebo kapacity v termínech doby odezvy nebo propustnosti. Postupy identifikují účel verifikace s kritérii úspěchu (očekávané výsledky), verifikační techniku, kterou je třeba aplikovat, potřebné podpůrné systémy (zařízení, vybavení) a podmínky prostředí pro provedení každého verifikačního postupu (zdroje, kvalifikovaný personál, specializované postupy nebo pracovní pokyny). Verifikační postupy zahrnují také to, jak budou výsledky verifikačních postupů zaznamenány, analyzovány, uloženy a reportovány.
b) Provedení verifikačních postupů.
ROZSAH: Verifikace probíhá v souladu s verifikační strategií v příslušném čase v plánu, v definovaném prostředí, s definovanými podpůrnými systémy a zdroji. Výkon verifikační akce spočívá v zachycení výsledku z provedení verifikačního postupu; porovnání získaného a zaznamenaného výsledku s očekávaným výsledkem; a dedukování stupně správnosti (nebo úspěchu/neúspěchu) odevzdaného prvku.
¶ 7.3.3 Správa výsledků verifikace
Tato aktivita se skládá z následujících úkolů:
a) Analýza výsledků verifikace a identifikovaných anomálií s cílem určení následných kroků. ROZSAH: Tento proces zahrnuje anomálie způsobené verifikační strategií, podpůrnými systémy pro verifikaci, provedením verifikace nebo nesprávnou definicí systému.
b) Zaznamenávání incidentů a problémů během verifikace a sledování jejich vyřešení.
ROZSAH: Během verifikace softwaru jsou dokumentovány podmínky, za kterých k problému došlo, aby bylo možné problém replikovat a identifikovat kořenovou příčinu softwarové chyby, pokud je to možné. Změny v požadavcích, architektuře, návrhu nebo systémových prvcích jsou prováděny pomocí jiných technických procesů.
c) Získání souhlasu zainteresovaných stran, že softwarový systém nebo jeho komponenta splňuje stanovené požadavky.
d) Poskytovaní vybraných klíčových artefaktů a informačních položek pro základní verze (baseline).
¶ 8. Nasazení
Diagram 7: Proces a výstupy nasazení digitálních služeb a systémů
¶ 8.1 Účel
Účelem procesu nasazení je zajistit schopnost systému poskytovat služby v souladu s požadavky zainteresovaných stran v provozním prostředí. Tento proces přenáší systém do provozního stavu organizovaným a plánovaným způsobem tak, aby byl funkční, provozuschopný a kompatibilní s ostatními provozními systémy. Instaluje se validovaný systém spolu s relevantními podpůrnými systémy. Proces nasazení se rovněž používá k opakovanému nasazování softwaru do různých prostředí, jako jsou například vývojové, testovací nebo údržbové prostředí, mezi různými testovacími prostředími, nebo při migraci z jednoho provozního prostředí do jiného (např. rehosting nebo využívání cloudových služeb).
¶ 8.2 Výstupy a odpovědné týmy
| Výstupy/Milníky | Název týmu |
| 1) Jsou identifikována omezení, která ovlivňují požadavky, architekturu nebo návrh systémů/software. | Vývojový tým |
| 2) Podpůrné systémy a služby pro nasazeni jsou zajištěny. Prostředí je připraveno. | Vývojový tým |
| 3) Systém, instalovaný na provozním místě, je schopen poskytovat specifikované funkce. Po instalaci je systém aktivován a připraven k použití. | Vývojový tým |
| 4) Operátoři, uživatelé a další zainteresované strany nezbytné pro provoz a podporu systému jsou řádně proškoleni. | Vývojový tým |
| 5) Byly identifikovány výsledky nasazení a zjištěny anomálie. | Product owner |
¶ 8.4 Aktivity a úkoly
¶ 8.4.1 Příprava na nasazení
Tato aktivita se skládá z následujících úkolů:
a) Definice strategii řízení verzí softwaru a dalších nasazení softwarového systému, která zahrnuje následující aspekty:
i) určení typu přechodu a kritérií pro jeho úspěšnost;
ii) stanovení frekvence opakovaných nasazení, jako jsou aktualizace a upgrady vývojových, testovacích a provozních systémů;
iii) minimalizace bezpečnostních rizik, narušení a výpadků během nasazení;
iv) archivace, zničení nebo konverzi a validaci dat z předchozích systémů do nového systému, včetně dat přijatých prostřednictvím externích rozhraní;
v) plánování pro případ problémů, zálohování a návrat k poslední funkční verzi systému;
vi) plánování nasazení v souladu s probíhajícími podnikatelskými činnostmi, s fázovaným nebo synchronizovaným nasazením systémů;
vii) řízení změn pro zainteresované strany, včetně partnerů rozhraní, lidských operátorů, administrátorů systémů a uživatelů softwarového systému nebo služby;
viii) související strategie pro validaci přecházejícího systému nebo prvku;
ix) zahájení podpory uživatelů a údržby se zajištěním přenosu a aktualizace systémové dokumentace, uživatelských příruček a testovacích procedur; a
x) současné provádění procesů přechodu, provozu a vyřazování starého systému při zavádění nového systému.
ROZSAH: Strategie by měla zahrnovat role a odpovědnosti, schvalovací pravomoci, využívání revizí připravenosti a školení.
b) Identifikace a definice změn ve vybavení, lokalitě, komunikační síti nebo cílovém prostředí potřebné pro instalaci nebo nasazeni softwarového systému.
ROZSAH: Pro každé nasazeni je třeba identifikovat a definovat jakékoliv potřebné změny v infrastruktuře nebo podpůrných systémech.
c) Identifikace informačních potřeb a zajištění uživatelské dokumentace a školení pro operátory, uživatele a další zainteresované strany nezbytné pro používání a podporu systému.
ROZSAH: Nasazeni zahrnuje migraci nebo aktivaci přístupu uživatelů k softwarovému systému. Stanovují se role uživatelů a implementují se uživatelské účty a přístupové kontroly.
d) Příprava podrobné informace o nasazeni, jako jsou plány, harmonogramy a procedury. Harmonogramy nasazeni ověřují, že jsou k dispozici dostatečné prostředky a infrastruktura pro podporu nasazeni, aby byly aktivity prováděny v přiměřeném časovém rámci a minimalizovala se případná přerušení.
e) Identifikace omezení systému vyplývajících z nasazeni, které by měly být zahrnuty do požadavků, architektury nebo návrhu softwarového systému.
f) Identifikace a plánovaní potřebných podpůrných systémů nebo služeb k podpoře nasazeni. ROZSAH: To zahrnuje identifikaci požadavků a rozhraní pro podpůrné systémy.
g) Získání nebo zajištění přístupu k nezbytným podpůrným systémům nebo službám.
¶ 8.4.2 Realizace nasazení
Tato aktivita se skládá z následujících úkolů:
a) Příprava virtuálního prostředí probíhá v souladu s požadavky na instalaci.
ROZSAH: Virtuální prostředí a nové komunikační prostředky jsou inicializovány a ověřeny. Zajišťuje se přeprava a příjem fyzických komponent systému a podpůrných systémů.
b) Instalace produktu na virtuální provozní místo a propojí s prostředím.
ROZSAH: Instalace produktu zahrnuje jeho konfiguraci s požadovanými provozními daty, úpravy v prostředí nebo změny podnikových procesů. Databáze se inicializují a provádí se migrace dat, pokud je to relevantní. Licence a údržbové smlouvy pro prvky systému a další duševní vlastnictví jsou převedeny podle dohod.
c) Zajištění uživatelské dokumentaci a školení pro operátory, uživatele a další zainteresované strany nezbytné pro efektivní využívání a podporu produktu.
d) Provedení aktivaci a kontroly, včetně následujících činností, jak bylo dohodnuto:
i) Prokázání správné instalace softwarového systému.
ROZSAH: Tento úkol může zahrnovat kontroly integrity dat a operací, například že software a datové reprezentace správně inicializují, vykonávají a ukončují operace podle specifikace.
ii) Prokázání toho, že nainstalovaný nebo přecházející produkt je schopen plnit požadované funkce.
ROZSAH: Toto je úkol připravenosti na provoz, který zkoumá připravenost funkčních schopností pro provozní stav. Zvláštní pozornost je věnována datovým rozhraním a bezpečnostním otázkám: zajištění informací a funkce interoperability jsou prováděny.
iii) Prokázání toho, že funkce poskytované systémem jsou udržitelné podpůrnými systémy.
ROZSAH: Toto je úkol připravenosti na provoz, který zkoumá připravenost podpůrných systémů pro provozní stav. Například se demonstruje aktivace monitorování, hlášení problémů, kontrola přístupu, zálohování a obnovení a uživatelská podpora (podpora zákazníků).
iv) Kontrola připravenosti softwarového systému pro provoz.
ROZSAH: To zahrnuje výsledky funkčních demonstrací, validačních aktivit a demonstrací udržitelnosti. Může být provedena revize připravenosti. Nedostatky, rizika a problémy, které mohou ovlivnit úspěch přechodu, jsou vyřešeny, přijaty pro výjimku nebo uzavřeny.
v) Uvedení softwarového systému do provozu.
ROZSAH: To zahrnuje poskytování podpory uživatelům, administrátorům a operátorům během zahájení provozu systému (komise).
¶ 8.4.3 Správa výsledků nasazení
Tato aktivita se skládá z následujících úkolů:
a) Zaznamenaní výsledků nasazeni a identifikujte případné anomálie.
ROZSAH: Toto zahrnuje anomálie způsobené strategií nasazeni, podpůrnými systémy nasazeni, realizací nasazeni nebo nesprávnou definicí softwarového či databázového systému. Pokud existují nesrovnalosti mezi systémem, jeho provozním prostředím a podpůrnými systémy, jsou odchylky řešeny nápravnými opatřeními, včetně úpravy požadavků.
b) Zaznamenaní incidentů a problém během nasazeni a monitorovat jejich řešení.
c) Zajištění klíčových artefaktů a informačních položek, které byly vybrány pro základní verze (baseline).
¶ 9. Uživatelské akceptační testování (UAT) (Proces validace)
Diagram 8: Proces a výstupy akceptačního testování digitálních služeb a systémů
¶ 9.1 Účel
Účelem procesu akceptačního testování je poskytnout důkaz, že systém při provozu splňuje obchodní nebo misijní cíle a požadavky zainteresovaných stran, a dosahuje svého zamýšleného použití v plánovaném provozním prostředí. Cílem validace systému nebo jeho prvku je získat jistotu o jeho schopnosti dosáhnout zamýšlené mise nebo použití za specifických provozních podmínek. Validaci potvrzují zainteresované strany.
POZNÁMKA:
• Verifikace (QA) zajišťuje, že „produkt je postaven správně“;
• Validace (UAT) zajišťuje, že „správný produkt je postaven“.
¶ 9.2 Výstupy a odpovědné týmy
| Výstupy/Milníky | Název týmu |
| 1) Byla stanovena kritéria validace pro požadavky zainteresovaných stran. |
Product owner, Analytický tým |
| 2) Dostupnost služeb požadovaných zainteresovanými stranami je potvrzena. |
Analytický tým UAT Testovací tým |
| 3) Identifikovaná omezení validace ovlivňují požadavky, architekturu nebo návrh. | Analytický tým UAT Testovací tým |
| 4) Systém nebo jeho komponenty byly podrobeny procesu validace. |
Product owner, Analytický tým |
| 5) Byly identifikovány výsledky validace a zaznamenány vzniklé anomálie. | UAT Testovací tým |
| 6) Je poskytnut objektivní důkaz, že realizovaný systém nebo systémový prvek splňuje potřeby zainteresovaných stran. |
Product owner Analytický tým |
¶ 9.3 Aktivity a úkoly
¶ 9.3.1 Příprava na validaci
Tato aktivita zahrnuje následující úkoly:
a) Definice strategii validace zahrnující následující kroky:
i) Identifikace rozsahu validace, včetně charakteristik softwarového systému, prvku nebo artefaktu, který má být validován, a očekávaných výsledků validace.
ROZSAH: Validace softwarového systému se obvykle provádí jak v oddělených kontrolovaných prostředích, která neovlivňují provozní software nebo probíhající vývoj, tak v provozních prostředích, obvykle před plným provozním nasazením (např. beta testování nebo akceptační testování na stanovenou dobu s dohodnutými kritérii). Rozsah zahrnuje požadavky zainteresovaných stran, včetně souvisejících pohledů na systém (např. scénáře nebo koncepty provozu), které mají být vyhodnoceny. Rozsah závisí na fázi životního cyklu systému: systém zájmu nebo systémový prvek či inženýrský artefakt, jako je popis konceptu, dokument, operační scénář, model, maketa nebo prototyp. Rozsah také zahrnuje ověření, že softwarový produkt nebo služba je použitelná ve svém určeném prostředí pro hlavní nebo kritické funkce. Další charakteristiky, které je třeba validovat, mohou zahrnovat použitelnost dokumentace, toleranci k chybám, odolnost a funkce obnovy softwaru.
ii) Identifikace omezení, která mohou omezit proveditelnost validačních činností.
ROZSAH: Omezení zahrnují praktická omezení přesnosti, nejistoty, opakovatelnosti, která jsou uvalena na nástroje pro validaci, související metody měření a dostupnost, přístupnost a propojení s těmito nástroji. Strategie validace je omezena pokrokem projektu; zejména plánované validační akce jsou redefinovány nebo přeloženy, pokud dojde k neočekávaným událostem nebo evoluci systému. Validace může být rozšířena o zahrnutí pokračujících měření spokojenosti uživatelů a stížností zákazníků.
iii) Identifikace priorit validace.
ROZSAH: Pro efektivní využití času a odbornosti zainteresovaných stran se validace obvykle zaměřuje na priority těchto stran, zatímco verifikace je využívána pro nefunkční požadavky. Potenciální validační akce, které jsou kandidáty pro zrušení, jsou vyhodnoceny z hlediska rizik, která jejich stažení přináší.
b) Identifikace systémových omezení na základě strategie validace, která budou zahrnuta do požadavků zainteresovaných stran.
c) Definice účelu, podmínek a kritérií pro každou validační akci.
d) Vyber vhodné metody nebo techniky validace a příslušná kritéria pro každou validační akci.
ROZSAH: Metody nebo techniky validace softwarového systému zahrnují inspekce, analýzy, analogie/podobnosti, demonstrace, simulace, recenze kolegů a testování. Techniky validace softwaru obvykle zahrnují demonstrace, inspekce, přezkoumání a prohlídky kódu, testy použitelnosti a zkušební použití softwaru (např. beta testování, operační testování, testování uživatelského rozhraní nebo akceptační testování s dohodnutými kritérii). Výběr metod nebo technik validace je prováděn podle typu systému, účelu validace, cílů projektu, právních a regulačních požadavků a přijatelných rizik validační akce. U softwarových systémů s lidskou interakcí se běžně používají testy použitelnosti k validaci toho, zda reprezentativní uživatelé mohou dosáhnout stanovených cílů s efektivitou, účinností a spokojeností v určeném kontextu použití.
¶ 9.3.2 Provádění validace
Tato aktivita zahrnuje následující úkoly:
a) Definice validačních postupů, každý podporující jednu nebo sadu validačních akcí.
ROZSAH: Validační postupy identifikují požadavky zainteresovaných stran, které mají být validovány, související artefakt softwarového systému (např. skutečný systém, model, maketu, prototyp, kód, soubor pokynů nebo jiný informační artefakt) a očekávané výsledky (kritéria úspěchu), jako je dokončený a včasný výkon funkce. Postupy definují účel validace s kritérii úspěchu (očekávané výsledky), validační techniku, která bude aplikována, potřebné podpůrné systémy (zařízení, vybavení), a podmínky prostředí pro provedení každého validačního postupu (zdroje, kvalifikovaný personál, zúčastněné strany a specializované pracovní pokyny nebo instrukce).
b) Realizace validačních postupů v definovaném prostředí.
ROZSAH: Validace se provádí v souladu se strategií validace, ve stanoveném čase dle plánu, v definovaném prostředí (např. provozní prostředí, podobné testovací prostředí nebo jiné reprezentativní prostředí), s použitím definovaných nástrojů a zdrojů. Proces provedení validačních aktivit obvykle zahrnuje zaznamenání výsledků, porovnání získaných výsledků s kritérii úspěchu a vyvození míry shody či spokojenosti zainteresovaných stran se softwarovým systémem, komponentou, službou nebo inženýrským artefaktem.
¶ 9.3.3 Správa výsledků validace
Tato aktivita zahrnuje následující úkoly:
a) Provádění kontroly (hodnocení) výsledků validace a identifikovat případné anomálie a potřebné následné kroky.
ROZSAH: Hodnocení výsledků validace a následné akce mohou zahrnovat přijetí anomálie jako nízkorizikového jevu. Opravy závisí na dopadu výsledků validace. U softwarových komponent může jít například o jednoduchou opravu chyby, dodatečné školení uživatelů, opravy a upřesnění dokumentace či zásadní přesměrování projektu v případě neúspěchu při dosažení klíčového milníku, jako je například neúspěšné testování akceptace softwarového systému.
b) Zaznamenáni incidentu a problém během validace a sledovaní jejich řešení.
ROZSAH: Během validace softwaru je dokumentována mezera mezi očekáváními zainteresovaných stran a výkonností systému, aby bylo možné identifikovat základní příčinu rozdílu, pokud to bude možné. Řešení problémů obvykle zahrnuje určení závažnosti a dopadu problému a rozhodnutí, zda a kdy bude nesrovnalost v softwaru opravena nebo přijata jako známá chyba na určitou dobu.
c) zajištění souhlas všech zainteresovaných stran, že software nebo systémová komponenta splňuje veškeré jejich požadavky.
d) Poskytnutí klíčových artefaktů a informací pro základní stanovení.