Funkční mapa aplikace: funkce, pravidlo a test

Představte si, že programátor změní zaokrouhlení srážkové daně ve sdíleném výpočtu, protože to potřebovala obrazovka výplat. Testy výplat projdou. Za týden se ozve investor, že výpis, který si stáhl, ukazuje u lednové výplaty jinou daň, než mu emitent tehdy srazil. Výpis totiž daň počítá znovu stejným kusem kódu a nikdo nevěděl, že na něm závisí. Takovým překvapením se dá z velké části předejít, když má aplikace funkční mapu: seznam funkcí, jejich pravidel a testů, ve kterém má každý kus kódu svého vlastníka. Popíšu, jak mapa vypadá, jak se z ní čte dopad změny a co z ní má zákazník.

Co je funkční mapa a čím se liší od specifikace

Funkční specifikace softwaru je dokument, který popisuje, co má aplikace dělat [1]. Obvykle vznikne na začátku projektu, schválí se a pak stárne, protože kód se mění rychleji než text. Funkční mapa je specifikace, která se mění spolu s kódem. Tvoří ji tři vrstvy:

• katalog funkcí, kde má každá funkce číslo, modul, oprávnění a obrazovky,
• pravidla ke každé funkci, každé se zdrojem a s testem, který ho ověřuje,
• vlastnictví, tedy u každé obrazovky, akce, části databáze a testu informace, ke které funkci patří.

Rozdíl proti dokumentu je v tom, že mapu kontrolují testy. Když vznikne nová obrazovka bez záznamu v katalogu, nebo kus kódu bez vlastníka, test neprojde a změna se do aplikace nedostane. Mapa proto nemůže zastarat, aniž by si toho někdo všiml.

Proč u finanční aplikace musí mít každý kus kódu vlastníka

Programátor, který mění sdílený kód (třeba zaokrouhlení částky), potřebuje vědět, kde všude se používá. U běžné aplikace se to často zjistí až podle toho, co přestane fungovat. U finanční evidence je horší, že nic nepřestane fungovat: výplata proběhne, výpis se vytiskne, jen v jednom z nich je jiná částka.

Vlastníkem kódu je funkce, ne programátor. U funkce totiž víme, kdo ji používá a jaká pravidla musí dodržet. U „pomocného výpočtu“ bez vlastníka to neví nikdo. Kód, který opravdu potřebují dvě funkce, má jednoho vlastníka a druhá funkce ho jen volá. Z měření, které testy kódem procházejí, je vidět i tuto druhou funkci, a změnu proto ověřují testy obou.

V praxi platí, že nejvíc nepříjemných chyb nevzniká v nové funkci, ale v té, na kterou změna sáhla mimochodem. Novou funkci všichni zkoušejí pečlivě, sousední nikdo, protože se „neměnila“.

Katalog funkcí: funkce se zapíše dřív, než vznikne kód

Katalog funkcí je seznam všeho, co aplikace umí, a vývoj ho doplní dřív, než začne psát kód. Katalog Bondie zahrnuje i plánované funkce, od emitentů a emisí přes objednávky a platby až po výplaty a odvod daně. U každé funkce je zapsané:

• číslo a název (např. F11 Výplaty úroků a jistiny),
• modul, do kterého patří,
• oprávnění, které uživatel potřebuje, a obrazovky, na kterých funkci najde,
• situace průvodce, která ji vysvětluje, a oblast testů,
• stav (hotovo, rozpracováno, plán).

Katalog je jediný zdroj odpovědi na otázku „co produkt umí“. Modul každé funkce se bere jen z katalogu a test hlídá, že každá stránka z menu aplikace má v katalogu svou funkci, takže menu a katalog si nemohou odporovat. Je to stejná zásada, kterou popisuji v článku Jeden zdroj pravdy, jen použitá na samotný popis aplikace.

Na katalog navazuje i plán práce. Každý úkol nese číslo funkce, kterou mění, a každý commit (uložená změna kódu) nese úkol a funkci. Commit bez nich kontrola při ukládání odmítne. Změny jedné funkce se proto dají dohledat v historii a je vidět, kdy a proč se měnila. Změny, které se týkají celé aplikace (např. vzhled nebo provoz), nesou místo čísla funkce označení celku.

Pravidla funkce: co musí platit a odkud to víme

Pravidlo funkce (v naší mapě se značkou BR podle anglického business rule) je jedna věta o tom, co musí funkce dodržet. Každé pravidlo má tři části: znění, zdroj a test. Zdrojem je zákon, emisní podmínky nebo zapsané rozhodnutí majitele produktu. Testem je konkrétní automatický test, který pravidlo ověřuje.

Vezměme pravidlo výplaty úroků: výplata patří tomu, kdo je vlastníkem dluhopisu na konci rozhodného dne, a převod účinný až po rozhodném dni příjemce výplaty nezmění. Zdrojem je zákon o dluhopisech (§ 17), konkrétní rozhodný den určují emisní podmínky [2]. Test založí převod den po rozhodném dni a ověří, že výplatu dostane dosavadní vlastník. Celý řetěz od modulu po test ukazuje schéma:

Pravidlo, které nikdo neověřuje, je v aplikaci jen popsané. Proto kontrola nepustí pravidlo, ke kterému neexistuje test. Výjimkou je jen pravidlo, u kterého je test výslovně zapsaný jako plánovaný, protože jeho funkce ještě není hotová. Pravidlo bez zdroje je naopak podezřelé z toho, že ho autor odhadl, a vrací se k ověření (u daní a lhůt k zákonu). Jak se ověřují samotná čísla, tedy úrok, AÚV a daň, popisuji v článku Testování finančních výpočtů.

Sledovatelnost od pravidla k testu a zpět

Sledovatelnost (anglicky traceability) znamená, že od požadavku dojdeme k testu a kódu, který ho plní, a od kódu zpátky k požadavku [3]. Dopředu se mapa čte, když se ptáme „je tohle pravidlo ověřené?“. Zpětně se čte před každou změnou.

Zpětný směr vychází z měření pokrytí kódu testy. Při běhu testů se zaznamená, které testy procházejí kterým kódem. Když programátor mění výpočet daně, mapa vrátí testy, které tímto kódem procházejí, z nich pravidla a z pravidel funkce. Výsledkem je seznam funkcí, kterých se změna týká, včetně těch, na které by autor nepomyslel (výpis pro investora z úvodu). Tyto testy musí projít a změnu zkontroluje AI agent v roli revizora, který ji nepsal. O nálezech pak rozhoduje člověk.

Stejný seznam se hodí, když se chyba najde. Oprava začne testem, který chybu zopakuje, a mapa ukáže, kde všude se stejný kód nebo pravidlo ještě používá. Opravuje se jednou u zdroje, místo aby se opravovala každá obrazovka zvlášť.

Mapa ale nezaručí, že je aplikace bez chyby. Ukáže, kde hledat, a hlídá, aby nic nezůstalo bez vlastníka a bez testu. Kdyby výpis z úvodu neměl test, který sdíleným výpočtem prochází, ukázalo by měření pokrytí tento kód jako neotestovaný. Jestli test ověřuje správnou věc, posuzuje revize a nezávislý přepočet.

Moduly a hranice mezi nimi

Moduly jsou části aplikace, které si zákazník volí podle toho, jak pracuje. Aplikace má Platformu, která je v každé instalaci (role, historie změn, průvodce, zálohy), dále Základ se zákonnou evidencí emise a sedm volitelných modulů: Banka, Schvalování, Závěrky, Deník, Komunikace, Provize a Online prodej. Přehled je na stránce Funkce. S mapou moduly souvisí přímo: modul každé funkce se bere z katalogu, takže je vždy jasné, které obrazovky, akce a data k modulu patří.

Aby šel modul vypnout, aniž by rozbil zbytek, platí mezi moduly pevná pravidla:

1. Volitelný modul smí používat Platformu a Základ, opačně to neplatí. Data Základu nesmí záviset na datech volitelného modulu.
2. Na jiný modul se nevolá napřímo, jen přes událost. Když back office stornuje objednávku, Základ ohlásí událost a modul Komunikace na ni připraví e-mail klientovi, pokud je zapnutý. U vypnutého modulu se spustí jen pravidla, která chrání peníze, a storno proběhne stejně.
3. Výjimkou z předchozího bodu jsou reakce, které mění peníze. Ty běží vždy, i když je jejich modul vypnutý. Provize ze stornované objednávky se zruší i při vypnutém modulu Provize, aby po jeho pozdějším zapnutí nečekala k výplatě.
4. Vypnutí modulu nemaže data. Když má modul rozpracované položky (např. žádost čekající na schválení), aplikace vypnutí odmítne a ukáže jejich seznam.

Pravidla hlídá automatický test: nová vazba přes hranici modulu neprojde a počet starých vazeb, které vznikly před zavedením pravidel, smí jen klesat. Že vypnutí opravdu nic nerozbije, dokazuje kontrola celé aplikace před vydáním verze: celá sada testů běží s každým volitelným modulem vypnutým zvlášť. Jak moduly vypadají v aplikaci, ukazuje snímek z ukázky:

U každého modulu je krátce popsané, co se stane po vypnutí (bez Banky se platby zapisují ručně, bez Komunikace se nic neposílá).

Co z funkční mapy má zákazník

Zákazník mapu přímo nevidí, ale využije ji ve třech situacích:

• Dohledatelnost. Auditor se zeptá, proč dubnovou výplatu dostal dosavadní vlastník, přestože dluhopis mezitím převedl. Dodavatel odpověď z mapy doloží: funkce Výplaty, pravidlo o rozhodném dni, jeho zdroj a test, který pravidlo hlídá. Spolu s auditní stopou (kdo kdy co změnil) auditor dohledá, co se stalo i podle jakého pravidla.
• Vypnutelné moduly. Emitent s pár investory nepotřebuje Banku ani Komunikaci. Vypnuté moduly nemají obrazovky ani oprávnění, takže aplikace je přehlednější a uživatel nemá k čemu sáhnout omylem. Když je později zapne, aplikace hlásí jen položky ode dne zapnutí (např. nespárované řádky výpisu nebo kontakty po termínu), takže emitent nedostane stovky upozornění za dobu, kdy modul nepoužíval.
• Aktualizace. Seznam změn ve verzi odděluje novinky, změny chování a opravy. Každá změna kódu nese číslo funkce, takže u každé položky je známé, kterých obrazovek a pravidel se týká, a back office ví, co si po aktualizaci projít.

Souhrnná čísla o testech a jejich pokrytí kódu průběžně ukazuje stránka Vývoj v číslech.

Když emitent vybírá dodavatele evidence dluhopisů, ověří si funkční mapu pěti otázkami. Dodavatel by na ně měl odpovědět ukázkou. Otázky k obecným principům vývoje jsou v článku Zásady vývoje software.

1. Máte seznam funkcí, ze kterého se bere menu i rozdělení do modulů? Ukažte mi ho.
2. Ukažte jedno pravidlo výpočtu (třeba sazbu daně), jeho zdroj a test, který ho hlídá.
3. Jak před změnou zjistíte, kterých dalších funkcí se týká?
4. Co se stane, když vypnu modul, který nepoužívám? Přijdu o data?
5. Podle čeho poznám v seznamu změn verze, jestli se změnilo pravidlo výpočtu?

Když dodavatel na třetí otázku odpoví „programátor to ví“, záleží celá aplikace na paměti jednoho člověka.

Závěr

Funkční mapa propojuje katalog funkcí, pravidla se zdrojem a testem a vlastníka každého kusu kódu. Před změnou se čte zpětně, od kódu přes testy a pravidla k funkcím, takže změna zaokrouhlení daně ukáže i výpis pro investora dřív, než si ho všimne investor. Moduly mají pevné hranice hlídané testem, a proto jdou vypnout, aniž by rozbily zbytek aplikace. Data vypnutého modulu zůstávají. Mapa chybu sama neodstraní, ale díky ní je vidět, kde ji hledat. Jak s ní souvisí kontrola v rolích AI agentů, popisuje článek Oponentura v rolích.

Reference

1. ISO/IEC/IEEE 29148:2018, Systems and software engineering – Life cycle processes – Requirements engineering [on-line]. [cit. 2026-10-10]. Dostupné z WWW: https://www.iso.org/standard/72089.html
2. Zákon č. 190/2004 Sb., o dluhopisech, § 17 [on-line]. [cit. 2026-10-11]. Dostupné z WWW: https://www.zakonyprolidi.cz/cs/2004-190
3. ISTQB, Glossary: traceability [on-line]. [cit. 2026-10-10]. Dostupné z WWW: https://glossary.istqb.org/en_US/term/traceability