Poptat vývojPoptat vývoj

    ↑ ↓ výběrEnter otevřeEsc zavře

    Celý návod k tisku: vyvoj.solutia.cz/navod/tisk

    Část III Vývoj: jak projekt uřídit

    Co se od vás čeká, co kontrolovat, jak řídit změny a jak převzít hotové dílo.

    Analýza: co přesně má software umět

    ~7 min čteníAktualizováno Lukáš Mikula

    Co není napsané, nebude dodané, a co je napsané navíc, zaplatíte. Každý požadavek musí jít ověřit: u scénářů stanovte akceptační kritéria a obecná slova jako „rychlý a bezpečný“ nahraďte konkrétními hodnotami a požadavky. Stejně důležitý je podepsaný seznam toho, co dodáno nebude, a jeden člověk na vaší straně, který specifikaci schvaluje.

    Nejdřív problém a uživatelé, potom funkce

    Zadání pro výběr dodavatele (kapitola 6) popisuje, co potřebujete a proč. Analýza s vybraným dodavatelem z něj udělá specifikaci: kdo bude systém používat, v jakých situacích a podle čeho poznáte, že funguje. Britská i australská státní správa tomu říkají discovery a vláda Nového Jižního Walesu pro ni obvykle vyhrazuje 4–8 týdnů NSW Government, 2026. U menšího a jasnějšího systému stačí kratší úvodní analýza, proto kapitola 8 uvádí rozpětí 2–8 týdnů. Výsledkem může být i rozhodnutí, že vývoj nového systému nemá smysl.

    Nejčastější chyba je převést papírový formulář na obrazovku 1:1. NKÚ státu vytýká „digitalizaci na úrovni formulářů“: po investicích přes 50 mld. Kč v letech 2020–2024 bylo plně digitálních jen 18 % služeb NKÚ, 2026. Nejdřív zjednodušte proces, pak ho digitalizujte.

    Mluvte s lidmi, kteří budou systém denně používat, ne jen s vedením. U digitalizace stavebního řízení vznikly požadavky podle technického auditu bez zapojení klíčových budoucích uživatelů Audit DSŘ, technická část, 2025 (jak dopadlo spuštění, popisuje kapitola 20).

    Nejlevnější test je klikací prototyp. Pro první ověření ho vyzkoušejte s 5–8 lidmi z provozu. Většinu chyb v procesu tak můžete najít dřív, než vznikne první řádek kódu. Přepsat obrazovku v prototypu stojí hodiny, v hotovém systému týdny.

    Každý požadavek musí jít ověřit

    Podle průzkumu PMI z roku 2014 nesplnilo 47 % neúspěšných projektů své cíle kvůli špatnému řízení požadavků PMI, 2014. Jde o podíl projektů, ne organizací jako u 37 % v kapitole 6. Základní jednotkou specifikace je proto uživatelský scénář: Jako [role] chci [co], abych [proč]. K němu patří akceptační kritéria ve tvaru Dáno / Když / Pak. Dodavatel podle nich připraví testy. Při převzetí pak místo sporu o dojmy ověříte, zda systém kritéria splňuje. Scénář bez kritérií do vývoje nepouštějte.

    Neověřitelný požadavekKonkrétní a ověřitelný požadavek
    Neověřitelný požadavek„Systém umožní evidenci žádostí.“Konkrétní a ověřitelný požadavek„Jako referent chci vidět nové žádosti seřazené podle data podání, abych je vyřídil ve lhůtě.“ Dáno: 3 nové žádosti z různých dní. Když: otevřu přehled. Pak: vidím je od nejstarší, s počtem dní do konce lhůty, a žádost po lhůtě je označená textem „Po lhůtě“ a červeně.
    Neověřitelný požadavek„Systém bude rychlý.“Konkrétní a ověřitelný požadavek„95 % odpovědí do 2 s, 99 % do 5 s při 200 souběžných uživatelích; ověří výkonový test v prostředí podobném ostrému provozu před převzetím.“
    Neověřitelný požadavek„Systém bude bezpečný a v souladu s legislativou.“Konkrétní a ověřitelný požadavek„Splní OWASP ASVS 5.0 úroveň 2, doloženo nezávislým ověřením se seznamem kontrolovaných požadavků; před spuštěním penetrační test bez kritických a vysokých nálezů; záznamy přístupů umožní prvotní hlášení incidentu do 24 h.“
    Neověřitelný požadavek„Data půjdou exportovat.“Konkrétní a ověřitelný požadavek„Správce kdykoli exportuje všechna data do CSV nebo JSON s popsaným datovým modelem, bez součinnosti dodavatele a bez poplatku.“

    Čísla v ukázkách jsou ilustrační, vlastní hodnoty stanovte podle počtu uživatelů a dopadu výpadku. ASVS je katalog ověřitelných bezpečnostních požadavků OWASP ASVS 5.0, 2025, lhůty hlášení incidentů stanoví zákon o kybernetické bezpečnosti Zákon č. 264/2025 Sb.. Obojí rozebírá kapitola 15.

    Šablona

    Šablona uživatelského scénáře a akceptačního kritériaJeden scénář = jedna potřeba jednoho typu uživatele. Kontrolní seznam na konci určuje, kdy je scénář připravený k vývoji.
    UŽIVATELSKÝ SCÉNÁŘ
Název: [krátký název]
Jako [role uživatele]
chci [co potřebuji udělat],
abych [jaký to má přínos].

AKCEPTAČNÍ KRITÉRIA (aspoň 2)
1. Dáno [výchozí stav], když [akce], pak [očekávaný výsledek].
2. Dáno …, když …, pak …

Příklad:
Jako referent chci vidět seznam nových žádostí seřazený podle data podání,
abych je vyřídil v zákonné lhůtě.
1. Dáno: 3 nové žádosti z různých dní. Když: otevřu přehled.
   Pak: vidím je od nejstarší a u každé počet dní do konce lhůty.
2. Dáno: žádost po lhůtě. Když: otevřu přehled. Pak: je označená textem „Po lhůtě“ a červeně.

Vazba na nefunkční požadavky: [výkon, bezpečnost, přístupnost…]
Priorita (MoSCoW): Must / Should / Could / Won't
Mimo rozsah tohoto scénáře: […]
Schválil: [vlastník produktu], datum, verze

PŘIPRAVENO K VÝVOJI, KDYŽ
[ ] má roli a přínos
[ ] má aspoň 2 akceptační kritéria Dáno / Když / Pak
[ ] má uvedenou vazbu na nefunkční požadavky
[ ] má prioritu
[ ] schválil ho vlastník produktu

    „Rychlý a bezpečný“ se přepíše na čísla

    Nefunkční požadavky říkají, jak dobře má systém fungovat. Splnění obecných slov jako „rychlý“ nebo „spolehlivý“ těžko ověříte a vymůžete. Konkrétní hodnoty a normy vám to umožní. Do specifikace patří aspoň tyto oblasti:

    Nefunkční požadavky: co napsat a jak to ověřit
    OblastCo napsatJak se ověří
    Výkondoba odezvy při daném počtu souběžných uživatelůvýkonový test před převzetím
    Dostupnostprovozní doba a povolený výpadekměření v provozu
    Bezpečnostúroveň OWASP ASVS, záznamy přístupůnezávislé ověření shody s ASVS a penetrační test
    PřístupnostWCAG 2.2 AAaudit, i ruční se čtečkou
    Provozmonitoring, logy, zálohy a obnovazkouška obnovy ze zálohy
    Dataexport všech dat v otevřeném formátuzkušební export
    LegislativaGDPR, kybernetická bezpečnost, AI Actkontrola s pověřencem a bezpečností

    Hodnoty jsou příklady. Úroveň zabezpečení a verzi WCAG vysvětluje kapitola 15, dostupnost a výpadky kapitola 21.

    MVP je nejmenší užitečná verze, ne polovina všeho

    MVP je nejmenší verze, kterou skuteční uživatelé opravdu použijí. Do MVP patří jen požadavky s prioritou Must (kapitola 6). Etapy plánujte podle toho, kdy přinesou užitek: pilot na jednom pracovišti, rozšíření, plné nasazení. Krátké etapy jsou nejlepší pojistka proti prodražení, protože s každým rokem trvání překročení nákladů roste (kapitola 10).

    Stejně důležité je napsat, co dodáno nebude. Seznam „mimo rozsah“ je samostatná část specifikace a podepisuje se s ní. Třeba takto:

    • migrace dat starších než rok 2015,
    • napojení na docházkový systém,
    • mobilní aplikace (stačí web, který funguje i v telefonu),
    • anglická verze.

    Specifikace funguje jako objednávka ve stavebninách: co na ní není, nepřivezou, a co připíšete u pokladny, zaplatíte zvlášť. Všechno nevyjasněné se později změní ve spor o vícepráce (kapitola 18).

    Kdo specifikaci schvaluje?

    Za specifikaci odpovídá váš vlastník produktu. Dodavatel mu ji pomáhá formulovat a ověřit. Každý schvaluje svou část:

    Schválení doložte číslem verze nebo zápisem.

    Jak to dopadá špatněJak to dělat dobře
    Jak to dopadá špatněSpecifikaci napíše dodavatel a vy ji podepíšete, „aby se začalo“.Jak to dělat dobřeZa specifikaci odpovídá váš vlastník produktu, dodavatel pomáhá s formulací a ověřením.
    Jak to dopadá špatněPapírový formulář převedený na obrazovku 1:1.Jak to dělat dobřeNejdřív jednodušší proces, pak digitalizace.
    Jak to dopadá špatněAkceptační kritéria „doplníme později“.Jak to dělat dobřeŽádný scénář bez kritérií nejde do vývoje.
    Jak to dopadá špatněMVP je první polovina všech funkcí.Jak to dělat dobřeMVP je nejmenší verze, kterou uživatelé použijí v pilotu.
    Jak to dopadá špatněUživatelé uvidí systém poprvé u převzetí.Jak to dělat dobřeUživatelé zkoušejí prototyp dřív, než se začne programovat.
    Jak to dopadá špatněCo v zadání není, se „nějak dořeší“.Jak to dělat dobřeSeznam „mimo rozsah“ podepsaný spolu se specifikací.

    Otázky

    Otázky pro dodavatele

    1. Jak ověříte, že scénáře odpovídají realitě? Kolik rozhovorů nebo testů s uživateli plánujete?
    2. Kdo z vašeho týmu bude mluvit přímo s lidmi, kteří budou systém používat?
    3. Jak bude vypadat prototyp a s kým ho vyzkoušíme před vývojem?
    4. Jak převedete akceptační kritéria na automatické testy?
    5. Které nefunkční požadavky považujete za rizikové a jak je ověříte?
    6. Co navrhujete dát mimo rozsah MVP a proč?

    Spot Solutia