**Toto je starší verze dokumentu!**
| informace | |
|---|---|
| Použití |
Orgány veřejné správy toto mohou využít pro lepší poznání co se musí ve které fázi životního cyklu udělat. Připraví si z toho checklist a připraví si třeba i vzory zde uvedené obecné dokumentace. |
| Zodpovědný | Michal Rada |
Obsah
Detailnější rozpad přípravných fází životního cyklu IS/ICT řešení
V této části je detailně uvedeno, to co požaduje vyhláška o dlouhodobém řízení splnit v prvních (přípravných) fázích přípravy či rozvoje ICT řešení. Orgán veřejné správy musí učinit všechny zde uvedené kroky a pořídit všechny zde uvedené formální výstupy.
fáze životního cyklu IS
Životní cyklus informačního systému a defacto i jakéhokoliv řešení je dle vyhlášky 360/2023 Sb. (vyhláška o dlouhodobém řízení) dělen do šesti fází:
- fáze:Strategické plánování vytvoření a rozvoje řešení
- fáze:Plánování a příprava vytvoření a rozvoje řešení
- fáze:Realizace vytvoření a rozvoje řešení
- fáze:Produkční provoz řešení
- fáze:Vyhodnocení životního cyklu řešení
- fáze: Ukončení životního cyklu řešení
Rozpad prvních fází - přípravná část
Životní cyklus ICT řešení a informačního systému má celkem 6 fází. Tyto fáze jsou určeny v § 15 vyhlášky 360/2023 Sb. (vyhláška o dlouhodobém řízení) a následné paragrafy udávají k jednotlivým fázím podrobnosti. Pro přípravu a správnou tvorbu informačního systému či ICT řešení jsou zcela klíčové první tři fáze, které se obvykle neřeší dostatečně podrobně.
Cílem je podrobnější rozpad fází tak, abychom rozuměli, co se v jednotlivých fázích děje a jaké jsou výstupy.
První diagram zobrazuje první dvě fáze životního cyklu ICT řešení. Tyto dvě fáze jsou dost propojené a vzájemně se ovlivňují.
Druhý diagram zobrazuje třetí fázi životního cyklu ICT řešení. Tato fáze je klíčová pro vytvoření kvalitního řešení, které bude splňovat požadavky zadavatele, ale i požadavky EG legislativy. Fáze má velice složitý rozpad.
Řada věcí musí být pochopitelně jasná již z prvních dvou fází. Výstupy počátku třetí fáze jsou již určeny pro zadání a tedy musí být vystavěny na dobré architektuře, konceptu a na správně formulovaných požadavcích.
Shrnuto, je třeba nejprve:
- Posoudit, zda a jaké řešení vlastně budu potřebovat a rámcově vědět, co bude muset umět.
- Zanést včas příslušný záměr do svojí informační koncepce OVS a teprve pak pokračovat v přípravách.
- Vytvořit si dokument se základním záměrem, včetně alespoň rámcové architektury a podle tohoto dokumentu dále postupovat, přičemž v případě změn rámcového zadání také tento dokument aktualizovat.
- Co nejdřív začít připravovat formulář pro stanovisko OHA (viz 💡 TIP: Začněte dělat formulář OHA co nejdříve) a tím také samotný systém bude postupně dostávat detailnější obrysy.
- Připravit investiční záměr a ten v OVS/OVM řádně projednat.
- Mít seznam funkčních požadavků na příslušný systém a řešení a teprve z něj pak sestavovat zadávací dokumentaci (viz 💡 TIP: Nejdřív požadavky a pak z nich teprve zadávací dokumentace).
Hlavně je ale důležité si nastavit správně vlastní vnitřní procesy a nastavit si i správně seznam a rozsah interních dokumentů, řada z nich se totiž pak stane součástí Provozní dokumentace.