Nástroje pro analýzu dopadu: Jak fungují a nejlepší možnosti pro podnikové týmy

Každá změna v produkčním systému s sebou nese důsledky, které sahají nad rámec změněné komponenty. Modifikace sdílené funkce naruší volající funkce, které závisely na jejím předchozím chování. Změna schématu databáze tiše zneplatní každý dotaz, který odkazoval na změněný sloupec. Aktualizace COBOL copybooku vyžaduje rekompilaci každého programu, který ji obsahuje, což může zahrnovat stovky programů napříč desítkami toků úloh, přičemž všechny je třeba otestovat před jakýmkoli přechodem do produkčního systému. Otázka, na kterou analýza dopadů odpovídá, nezní, zda má změna důsledky, ale přesně které komponenty jsou ovlivněny, jak jsou propojeny se změněným prvkem a jaký musí být úplný rozsah validace, než bude možné změnu bezpečně nasadit.

Bez analýzy dopadu se na tuto otázku odpovídá hádáním, dotazováním se vývojáře, který změnu provedl, spuštěním celé sady testů a doufáním, že se selhání seskupí kolem správných věcí, nebo nasazením a objevením dotčených komponent, když uživatelé nahlásí selhání. Nástroje pro analýzu dopadu nahrazují hádání strukturálními důkazy: analyzují zdrojový kód, mapují závislosti a generují výčtový seznam všech komponent, kterých se navrhovaná změna dotkne. Nástroje popsané v této příručce sahají od platforem pro statickou analýzu přes nástroje pro výběr testů až po mapovače závislostí v podniku, přičemž každý z nich pokrývá jiný rozměr problému analýzy dopadu.

Co je analýza dopadů v softwarovém inženýrství?

Analýza dopadů v softwarovém inženýrství je proces identifikace všech komponent systému, které jsou přímo či nepřímo ovlivněny navrhovanou změnou. Odpovídá na otázku: pokud změním toto, co dalšího se změní? Probíhá před implementací, během plánování, návrhu a schvalování změny, spíše než dodatečně, během testování nebo reakce na incident.

Tento termín zahrnuje několik souvisejících, ale odlišných činností, které se liší v tom, co analyzují a kdy:

Analýza dopadu změny určuje rozsah navrhované změny kódu před jejím provedením. Identifikuje, které moduly, funkce, databázové tabulky a závislé systémy bude nutné v důsledku navrhované změny upravit nebo znovu otestovat.

Analýza dopadu testu (TIA) je specifická aplikace analýzy dopadu změn, která identifikuje, které existující testy jsou relevantní pro danou změnu kódu. Místo spuštění celé sady testů vybírá TIA minimální podmnožinu testů, které pokrývají změněný kód a jeho závislé části, čímž se zkracuje doba provádění testů a zároveň se zachovává pokrytí dotčeného rozsahu.

Analýza dopadu požadavků identifikuje, které požadavky, prvky návrhu a výstupy jsou ovlivněny změnou požadavku. V regulovaných odvětvích to zajišťuje, že každý artefakt v následném procesu závislý na změněném požadavku je aktualizován a znovu ověřen.

Všechny tři sdílejí společný základ: model závislostí, který reprezentuje vzájemné vztahy komponent, a mechanismus pro procházení tímto modelem z výchozího bodu (změněné komponenty) za účelem výčtu všeho, co je z něj dosažitelné.

Tři typy analýzy dopadů

Techniky analýzy dopadů se klasifikují podle toho, jak shromažďují informace o závislostech:

Typ	Metoda	Co najde	Kdy použít
Statická analýza nárazu	Analyzuje zdrojový kód bez jeho spuštění	Všechny syntaktické odkazy: volání funkcí, importy, přístupy k polím, odkazy na schémata	Před implementací, během plánování změn; funguje na jakékoli kódové základně
Dynamická analýza dopadů	Nástroje spouštějící kód pro sledování skutečných cest provádění	Pouze komponenty skutečně procvičované během zkušebního provozu	Závislosti specifické pro běhové prostředí; identifikuje cesty, které statická analýza může přehlédnout
Založené na požadavcích (sémantické)	Sleduje vazby sledovatelnosti mezi požadavky, návrhy a kódem	Artefakty upstreamu a downstreamu ovlivněné změnou požadavků	Regulovaná odvětví; systémové inženýrství; bezpečnostně kritický software

Statická analýza dopadu je nejrozšířenější, protože pracuje pouze se zdrojovým kódem, bez nutnosti běžícího systému nebo testovací infrastruktury. Je to technika používaná nástroji v této příručce a SMART TS XL pro analýzu podnikového kódu. Dynamická analýza doplňuje statickou analýzu zachycením chování za běhu, jako jsou dynamicky konstruované dotazy nebo volání funkcí s pozdní vazbou, které statická analýza nedokáže vyřešit pouze ze zdrojového kódu. V praxi většina programů pro analýzu dopadu na produkci kombinuje obojí: statická analýza poskytuje základní mapu závislostí a dynamické profilování ji ověřuje oproti pozorovanému chování za běhu.

Statická vs. dynamická analýza dopadu: klíčové rozdíly

Statická analýza dopadu je konzervativní: může nadhodnocovat ovlivněný rozsah zahrnutím závislostí, které existují v kódu, ale v praxi se nikdy nevyužijí. Dynamická analýza dopadu je přesná pro to, co pozoruje, ale neúplná, zachycuje pouze to, co skutečně probíhalo během instrumentované relace, a chybí cesty, které byly vykonávány za různých vstupů nebo konfigurací. Pro produkční systémy, kde je úplnost důležitější než přesnost, je statická analýza bezpečnějším výchozím nastavením.

Proces analýzy dopadů: krok za krokem

Strukturovaný proces analýzy dopadů se řídí konzistentní posloupností bez ohledu na použitý nástroj:

Krok 1: Definujte změnu. Přesně identifikujte, co se mění: konkrétní funkci, pole, třídu, modul, sešit nebo sloupec databáze. Přesnost v tomto kroku určuje přesnost všeho, co následuje. Nejasné definice změn („upravujeme platební modul“) mají neurčitý dopad.

Krok 2: Vytvořte nebo dotazujte model závislostí. Model závislostí představuje vztahy mezi všemi komponentami v systému. U automatizovaných nástrojů je tento model vytvořen analýzou zdrojového kódu. Pro manuální analýzu na malých systémech může být udržován jako dokumentace. Model musí být aktuální: zastaralá dokumentace závislostí vede k nepřesným posouzením dopadů.

Krok 3: Projděte graf závislosti od bodu změny. Počínaje změněnou komponentou sledujte všechny příchozí hrany závislostí (komponenty, které závisí na změněné komponentě) a odchozí hrany (komponenty, na kterých změněná komponenta závisí a které se po změně mohou chovat odlišně). Pokračujte tranzitivně, dokud nebudou vyjmenovány všechny dosažitelné závislé komponenty.

Krok 4: Klasifikujte postižené komponenty podle rizika. Ne všechny postižené komponenty nesou stejné riziko. Komponenta, která přímo volá změněnou funkci, představuje vyšší riziko než komponenta, která je o pět úrovní závislosti odstraněna. Pro zajištění nápravných opatření je nutné klasifikovat zjištění podle blízkosti, kritičnosti a pokrytí testy.

Krok 5: Definujte rozsah testování. Sada dopadů, kompletní seznam dotčených komponent, definuje minimální rozsah testování. Jakákoli komponenta v sadě dopadů, která postrádá automatizované testování, představuje riziko, které je třeba řešit buď přidáním testů, nebo ručním ověřením.

Krok 6: Dokumentace a kontrola. Předložte posouzení dopadů poradnímu výboru pro změny (CAB) nebo příslušným zúčastněným stranám jako podklad pro schválení změny. Výčet rozsahu dopadů s klasifikací rizik nahrazuje odhady vývojářů strukturálními důkazy.

Analýza dopadu testů: Jak to funguje v CI/CD

Analýza dopadu testů (TIA) aplikuje analýzu dopadu konkrétně na problém testování: které testy je třeba spustit při změně kódu? Bez TIA spouštějí CI pipeline celou sadu testů u každého commitu. V kódové základně s 50 000 testy a sadou testů, jejíž spuštění trvá 45 minut, to znamená, že každý pull request se blokuje po dobu 45 minut, a proto vývojáři tuto situaci obcházejí, odesílají více commitů bez čekání na výsledky a ztrácejí zpětnou vazbu, kterou má testování poskytovat.

TIA tento problém řeší sledováním mapování mezi kódem a testy: které řádky kódu jsou pokryty kterými testy. Když commit změní konkrétní řádky, TIA vybere pouze testy, které tyto řádky a jejich závislé soubory pokrývají. Změna, která se dotkne tří souborů z 50 000, může vyžadovat 200 testů místo 50 000. Pipeline běží během několika sekund místo minut.

Mapování se vytváří instrumentací provádění testů pro zaznamenávání dat pokrytí a následným ukládáním těchto dat pokrytí indexovaných kódem, který pokrývá. Při každém novém potvrzení (commitu) TIA:

1. Identifikuje, které soubory a funkce se změnily (z rozdílu v gitu)
2. Vyhledá, které testy pokrývají dané soubory a funkce
3. Přidává testy, které pokrývají jakoukoli komponentu ve statickém grafu závislostí změněného kódu.
4. Spustí vybranou podmnožinu; všechny zbývající testy projdou, jako by nebyly ovlivněny.

Mezi nástroje, které implementují TIA, patří Test Impact Analysis od Microsoftu ve Visual Studiu, TIA engine od Parasoftu, Gradle Test Selection a několik pluginů integrovaných s CI pro Jest, pytest a další testovací běhače. Přesnost TIA závisí na přesnosti modelu závislostí. Nástroj, který sleduje pouze přímé pokrytí kódu bez procházení závislostí, vynechá testy, které pokrývají komponenty o tři úrovně vzdálené od změny.

TIA v praxi: Před a po

V typické podnikové backendové službě povolení TIA zkracuje dobu provádění testů o 60–80 % u průměrného pull requestu. Nevýhodou je, že i velmi velké změny, ty, které se dotýkají sdílených utilit, základních tříd nebo široce používané konfigurace, mohou stále spouštět velké podmnožiny testů. TIA poskytuje největší hodnotu pro vývoj funkcí a opravy chyb tam, kde jsou změny lokalizovány. U průřezových změn, jako jsou upgrady frameworku nebo úpravy sdíleného schématu, zůstává bezpečnější volbou kompletní testovací běh.

Analýza dopadů v požadavcích a řízení změn

V systémovém inženýrství a regulovaném vývoji softwaru se analýza dopadů rozšiřuje nad rámec kódu na celý řetězec artefaktů: požadavky, specifikace návrhu, testovací případy, posouzení rizik a ověřovací důkazy. Změněný požadavek neovlivňuje pouze kód, ale ovlivňuje každý prvek návrhu, který daný požadavek implementoval, každý testovací případ, který jej ověřil, každé posouzení rizik, které jej předpokládalo, a každou dokumentaci o shodě, která na něj odkazovala.

Analýza dopadu založená na požadavcích využívá odkazy na sledovatelnost k vyjmenování tohoto následného rozsahu. Matice sledovatelnosti, která propojuje každý požadavek s jeho implementačními konstrukčními prvky, testovacími případy a ověřovacími důkazy, umožňuje identifikovat plný rozsah opětovného ověření vyžadovaného jakoukoli změnou požadavku. V regulovaných odvětvích, zdravotnických prostředcích podle FDA 21 CFR Part 11, leteckém softwaru podle DO-178C a automobilovém softwaru podle ISO 26262, je tento rozsah opětovného ověření regulačním požadavkem, nikoli volitelným postupem kvality.

Spojení mezi analýzou dopadu požadavků a analýzou dopadu kódu spočívá v sledovatelnosti: když požadavek odkazuje na konkrétní softwarovou komponentu a tato komponenta je identifikována v analýze dopadu na úrovni kódu, lze výsledky analýzy dopadu použít k zaměření úsilí o opětovné ověření na konkrétní testovací případy, které danou komponentu ověřují. Moderní platformy pro správu požadavků, včetně Jama Connect a IBM DOORS, tuto sledovatelnost podporují a poskytují vestavěné funkce pro analýzu dopadu na úrovni požadavků.

Analýza dopadu pro rozsáhlé a starší kódové báze

Analýza dopadu pro rozsáhlé kódové báze, zejména pro podnikové systémy, které rostly po celá desetiletí, se kvalitativně liší od analýzy dopadu pro službu s 10 000 řádky. Rozdíly v rozsahu nejsou jen kvantitativní. Velké starší kódové báze mají struktury závislostí, kterým žádný žijící člen týmu plně nerozumí: tisíce programů s implicitním propojením prostřednictvím sdílených datových sad, sešity zahrnuté stovkami programů současně, toky úloh JCL se složitou logikou podmíněného provádění, která vytváří závislosti pouze za běhu.

Několik charakteristik velkých kódových základen činí manuální analýzu dopadu nespolehlivou:

Implicitní závislosti. V systémech COBOL vytváří sešit úloh (copybook) zahrnutý 300 programy závislost, která je neviditelná pro každého vývojáře, který neví, kde ji hledat. Změna člena sešitu úloh, která vypadá jako přejmenování pole, může vyžadovat rekompilaci a opětovné testování všech 300 programů. Bez automatizované analýzy se tento rozsah odhaluje postupně, každé nové selhání odhalí další přehlédnutou závislost.

Mezijazykové závislosti. Program v COBOLu zapisuje do tabulky v DB2. Služba Java čte ze stejné tabulky. Výstup služby Java zpracovává kanál Pythonu. Změna schématu DB2 ovlivňuje všechny tři vrstvy. Žádný nástroj pro statickou analýzu v jednom jazyce nedokáže tento řetězec mezi jazyky sledovat; vyžaduje nástroj, který rozumí všem třem jazykům a propojuje je v jednotném modelu závislostí.

Nepřímé závislosti prostřednictvím dat. Dva programy, které se nikdy navzájem nevolají, mohou být stále propojeny prostřednictvím sdíleného souboru. Program A zapisuje do datové sady X; program B čte z datové sady X. Změna rozvržení datové sady X ovlivní oba, ale závislost není voláním funkce, je to datový kontrakt vyjádřený pomocí příkazů JCL DD a definic COBOL FD. Strukturální analýza, která sleduje pouze volání funkcí, tuto třídu závislostí zcela opomíjí.

Mrtvý kód a dosažitelnost. Velké kódové základny hromadí kód, který je definován, ale nikdy nebyl volán, funkce, které zůstávají z odstraněných funkcí, procedury, které byly nahrazeny, ale nebyly odstraněny. Analýza dopadu, která zahrnuje mrtvý kód v dotčeném rozsahu, nadhodnocuje rozsah změn a zaměřuje testovací úsilí na komponenty, které nebudou v produkčním prostředí nikdy dosaženy.

Jedno starší modernizace Analytické řešení pro tato prostředí musí zvládat všechny tyto případy: musí analyzovat skutečně používané jazyky (včetně COBOLu, JCL, PL/I, RPG, Assembleru a DB2), řešit implicitní závislosti prostřednictvím sdílených datových struktur, sledovat řetězce mezi jazyky a rozlišovat dosažitelný kód od nedosažitelného.

Nástroje pro analýzu dopadů: Jak se srovnávají

Níže uvedené nástroje pokrývají hlavní kategorie analýzy dopadu ve vývoji softwaru. Každá z nich je posuzována podle toho, co analyzuje, jaké jazyky podporuje a jakou třídu problémů analýzy dopadu nejlépe řeší.

Nástroj	Primární přístup	Jazyky	nejlepší
SMART TS XL	Statické + mezijazykové mapování závislostí	COBOL, JCL, Java, Python, .NET, RPG, SQL	Analýza dopadu na vícejazyčné podnikové a mainframové systémy
Porozumět pomocí SciTools	Statická analýza, grafy volání, vizualizace závislostí	70+ jazyků	Vícejazyčné porozumění kódu a sady dopadů
Struktura101	Analýza architektury, grafy závislostí	Java, C#, JVM/.NET	Strukturální dopad v podnikových aplikacích Java/C#
CAST AIP	Aplikační inteligence, technický dluh, dopad	Java, .NET, COBOL, SQL	Analýza obchodního a technického dopadu na úrovni portfolia
Apartmá Axivion	Grafy sémantických závislostí pro C/C++	C, C ++	Bezpečnostně kritické systémy, shoda s MISRA, vestavěné systémy
Parasoft	Analýza dopadu testů, integrace CI/CD	Java, C/C++, .NET	TIA v regulovaných odvětvích, testování kritické z hlediska bezpečnosti
Jama Connect	Sledovatelnost požadavků, dopad artefaktů	Jazykově nezávislý (úroveň požadavků)	Systémové inženýrství, regulovaná odvětví, DO-178C/ISO 26262
soundQube	Kvalita kódu, analýza závislostí v rámci jazyka	30+ jazyků	Brány kvality kódu; omezená analýza dopadu napříč systémy
IntelliJ IDEA / Eclipse	Hierarchie volání IDE, analýza referencí	Java, Kotlin, Python	Analýza lokálního dopadu na úrovni vývojáře v rámci projektu

Porozumět pomocí SciTools je nejkomplexnější specializovaný nástroj pro analýzu dopadů pro softwarové týmy pracující v moderních jazycích. Jeho funkce Impact Sets vypočítává tranzitivní uzavření všech entit kódu ovlivněných konkrétní změnou, každé funkce, třídy a proměnné dosažitelné prostřednictvím grafu závislostí od počátečního bodu. Podporuje více než 70 jazyků a vytváří detailní grafy volání, diagramy datových toků a mapy vztahů mezi entitami.

Struktura101 je nejsilnějším nástrojem pro analýzu dopadu na úrovni architektury Javy a C#. Vizualizuje strukturu závislostí balíčků a tříd jako interaktivní mapy a identifikuje oblasti, kde navrhované změny porušují architektonické hranice nebo vytvářejí nové cykly v grafu závislostí.

CAST AIP Pracuje na úrovni portfolia a analyzuje kompletní aplikační prostředí včetně COBOLu, Javy, .NET, SQL a dalších jazyků, aby vytvořil skóre dopadu na podnikání spolu s analýzou technického dopadu. Běžně se používá v programech due diligence fúzí a akvizic a racionalizace portfolia.

Apartmá Axivion zaměřuje se na vývoj v jazyce C a C++, který je kritický z hlediska bezpečnosti, kde analýza dopadů musí splňovat regulační požadavky (ISO 26262, DO-178C, MISRA) a poskytovat formální důkazy o úplnosti analýzy.

Parasoft je nejsilnějším řešením TIA pro regulovaná odvětví s integrovaným enginem pro výběr testů CI/CD, který sleduje pokrytí až na úroveň příkazů a vybírá podmnožiny testů na základě přesného procházení závislostí.

soundQube poskytuje analýzu závislostí v rámci projektu a detekci zápachu kódu, ale není určen pro analýzu dopadu napříč systémy ani jazyky. Jeho hodnota v zásobníku analýzy dopadů spočívá spíše jako ukazatel kvality, který identifikuje, které změněné komponenty přinášejí nové problémy s kvalitou nebo zabezpečením, než jako mapovač závislostí.

Nástroje založené na IDE (Hierarchie volání IntelliJ, analýza referencí Visual Studia, graf volání Eclipse) poskytují analýzu lokálního dopadu v rámci projektu pro vývojáře. Jsou efektivní pro pochopení toho, co změna ovlivňuje v rámci modulu, ale nemohou sledovat závislosti mezi projekty, jazyky ani mainframy.

Jak SMART TS XL Provádí analýzu dopadů

SMART TS XL provádí analýzu dopadu analýzou každého zdrojového souboru v prostředí, programů COBOL, toků úloh JCL, sešitů, schémat SQL, tříd Java, modulů Pythonu, RPG programů a dalších a vytváří jednotný model závislostí, který reprezentuje všechny strukturální vztahy napříč všemi jazyky. Tento model je základem: analýza dopadu je dotaz na něj, počínaje libovolnou komponentou a procházející grafem závislostí, aby vyjmenoval vše, čeho se to dotklo.

Když tým navrhne změnu člena sešitu COBOL, SMART TS XLJe analýza dopadu Odpovědi: Které programy obsahují tuto sešitovou knihu? Které z těchto programů jsou volány kterými kroky úlohy JCL? Které tabulky DB2 tyto programy čtou nebo zapisují? Které služby Java tyto tabulky využívají? Které testovací případy pokrývají tyto programy? Odpověď není odhad, je to úplný, vyjmenovaný seznam odvozený ze skutečné struktury kódu, s názvy souborů, názvy programů, názvy úloh a čísly řádků.

Jedno mapování závislostí aplikací Capability generuje vizuální diagramy grafu závislostí se středem na změněné komponentě a pomocí barevného kódování odlišuje přímé a nepřímé závislosti a zvýrazňuje spojení s nejvyšším rizikem. Tyto diagramy slouží jako důkazní základna pro kontrolu CAB a jako plán pro plánování testování.

Jedno Expanze JCL Funkce řeší symbolickou substituci parametrů v PROC před analýzou a zajišťuje, že model závislostí odráží skutečné běhové spuštění, a nikoli nevyřešené odkazy na šablony. PROC, který volá různé programy v závislosti na symbolických parametrech, je rozpoznán pro všechny programy, které skutečně volá napříč všemi svými volajícími, což je kompletní pokrytí, které nástroje bez znalosti symbolů opomíjejí.

Pro podnikové týmy provádějící technickou due diligence, plánující modernizaci starších systémů nebo řídící změny v systémech, které zahrnují více jazyků a platforem, SMART TS XLJe podnikové vyhledávání Tato schopnost umožňuje dotazování v modelu závislostí: nalezení každého použití konkrétního pole, každého programu, který volá konkrétní funkci, každé úlohy JCL, která vytváří konkrétní datovou sadu, během několika sekund v kódové základně libovolné velikosti.

Nejlepší postupy pro analýzu dopadů

Začněte s analýzou dopadu před psaním kódu, ne až po něm. Účelem analýzy dopadů je informovat o rozhodnutí o provedení změny a vymezit rozsah výsledné práce, nikoli vysvětlovat, co se po zavedení pokazilo. Posouzení dopadů provedené poté, co je změna již probíhá, je post-hoc racionalizací, nikoli nástrojem plánování.

Explicitně definujte hranice posouzení dopadů. Grafy dopadů ve velkých systémech se mohou rozrůstat a zahrnout téměř cokoli. Před spuštěním analýzy definujte hranice analýzy, maximální hloubku závislostí, vyloučený nefunkční kód a systémy mimo rozsah analýzy. Neomezený průchod vytváří výsledky, které jsou technicky správné, ale provozně nepoužitelné.

Rozlišujte mezi povinným opakovaným testováním a doporučeným monitorováním. Ne každá komponenta v sadě dopadů vyžaduje stejnou testovací odezvu. Komponenta, která přímo volá změněnou funkci v aktivní cestě, musí být znovu otestována. Komponenta, která se dostane ke změněné funkci přes pět úrovní zřídka používaného kódu, může být monitorována v produkčním prostředí. Klasifikace rizik promění seznam dopadů v plán testování.

Udržujte model závislostí aktuální. Analýza dopadu provedená na zastaralém nebo neúplném modelu závislostí je horší než žádná analýza dopadu, protože vytváří falešnou jistotu v nesprávný rozsah. Modely závislostí musí být regenerovány při každé významné změně kódové základny nebo inkrementálně aktualizovány prostřednictvím integrace CI/CD, která automaticky znovu analyzuje změněné soubory.

Spojte analýzu dopadů s řízením změn. Analýza dopadů dosahuje plné hodnoty, když její výstupy vstupují do formálního procesu řízení změn. Zpráva o dopadech, která dokumentuje rozsah, klasifikaci rizik a požadavky na testování, poskytuje poradním výborům pro změny strukturální důkazy, které potřebují k přijímání autorizačních rozhodnutí založených na skutečném systému, a nikoli na odhadech vývojářů.

U starších systémů zohledněte implicitní propojení dat. Jakákoli analýza závislostí pro starší systém, který sleduje pouze volání funkcí, je neúplná. Programy propojené prostřednictvím sdílených souborů, datových sad, databází a front zpráv jsou v prostředí mainframe běžné a pro analýzu pouze volání funkcí jsou neviditelné. Model závislostí musí zohledňovat propojení na úrovni dat, aby se dosáhlo úplného rozsahu dopadu.

Investice do infrastruktury pro analýzu dopadů, ať už prostřednictvím specializovaného nástroje, jako je SMART TS XL, engine pro analýzu dopadu testů jako Parasoft nebo platforma pro sledovatelnost požadavků jako Jama, se zotavuje z nákladů na změny, které nezpůsobily neočekávané problémy, testy, které nemusely spustit celou sadu, a nasazení, která nezpůsobila incidenty. Toto zotavení není hypotetické. Každý produkční incident způsobený nezjištěnou závislostí je přímým nákladem na analýzu, která se nestala před provedením změny.