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

  1. fáze:Strategické plánování vytvoření a rozvoje řešení
  2. fáze:Plánování a příprava vytvoření a rozvoje řešení
  3. fáze:Realizace vytvoření a rozvoje řešení
  4. fáze:Produkční provoz řešení
  5. fáze:Vyhodnocení životního cyklu řešení
  6. fáze: Ukončení životního cyklu řešení
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

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

Fáze 1: Strategické plánování vytvoření a rozvoje řešeníFáze 2: Plánování a příprava vytvoření a rozvoje řešeníVznik a analýza potřebyPrvní architektonické posouzení potřeby a souladupotřeby s architekturouZáměr v IK OVS Architektonický záměr nebo koncept Investiční záměr Formulář OHATohle není jednoduché v téhle fázi Stanovisko OHASeznam požadavků na řešeníz nich se pak tvoří požadavky do ZD Studie proveditelnostiNávrhy řešení a výběr řešenímá být součástí studie proveditelnosti v ideálním případěFormalizovaný exit plánArchitektura řešeníPlán uchovávání dat             

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.

Fáze 3: Realizace vytvoření a rozvoje řešeníZpůsob pořízení či změnyZadávací dokumentaceVeřejná zakázka nebo vývojVýběr dodavateleSmluvní zajištění dodávekRealizacePosouzení výsledku s požadavkyVytvoření provozní dokumentaceUchování a řízení zdrojového kóduZveřejnění zdrojového kóduZkušební provozNahlašuje se DIAAkceptace produkčního prostředíStanoviska OHA k zahájení provozuvydává DIA po žádostiProvozŘízení požadavků a změnchange management ale ten věcnýZajištění BCPZajištění a vyhodnocování testůŠkolení uživatelůPodpora uživatelů              povinnost     

Ř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:

  1. Posoudit, zda a jaké řešení vlastně budu potřebovat a rámcově vědět, co bude muset umět.
  2. 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.
  3. 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.
  4. 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.
  5. Připravit investiční záměr a ten v OVS/OVM řádně projednat.
  6. 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.