Tools zur Wirkungsanalyse: Funktionsweise und die besten Optionen für Teams in Unternehmen

Jede Änderung an einem Produktivsystem hat Folgen, die über die geänderte Komponente hinausgehen. Eine Modifikation einer gemeinsam genutzten Funktion führt dazu, dass Aufrufer, die auf deren vorheriges Verhalten angewiesen waren, nicht mehr funktionieren. Eine Änderung des Datenbankschemas macht stillschweigend alle Abfragen ungültig, die auf die geänderte Spalte verweisen. Ein COBOL-Copybook-Update erfordert die Neukompilierung aller Programme, die es enthalten – ein Umfang, der Hunderte von Programmen in Dutzenden von Jobstreams umfassen kann. All dies muss vor der Produktivsetzung getestet werden. Die Folgenabschätzung beantwortet nicht die Frage, ob eine Änderung Folgen hat, sondern welche Komponenten genau betroffen sind, wie sie mit dem geänderten Element verbunden sind und welcher Validierungsumfang vollständig sein muss, bevor die Änderung sicher bereitgestellt werden kann.

Ohne Folgenabschätzung wird diese Frage durch Raten beantwortet: Man befragt den Entwickler, der die Änderung vorgenommen hat, führt die gesamte Testsuite aus und hofft, dass die Fehler sich auf die richtigen Bereiche konzentrieren, oder man implementiert die betroffenen Komponenten und entdeckt sie erst, wenn Benutzer Fehler melden. Werkzeuge zur Folgenabschätzung ersetzen das Rätselraten durch strukturelle Beweise: Sie analysieren den Quellcode, bilden Abhängigkeiten ab und erstellen eine Liste aller Komponenten, die von der geplanten Änderung betroffen sind. Die in diesem Leitfaden vorgestellten Werkzeuge reichen von statischen Analyseplattformen über Testauswahl-Engines bis hin zu Enterprise-Dependency-Mappern und decken jeweils einen anderen Aspekt der Folgenabschätzung ab.

Was ist eine Wirkungsanalyse in der Softwareentwicklung?

Die Folgenabschätzung in der Softwareentwicklung ist der Prozess, alle Systemkomponenten zu identifizieren, die direkt oder indirekt von einer geplanten Änderung betroffen sind. Sie beantwortet die Frage: Wenn ich dies ändere, was ändert sich dann noch? Sie wird vor der Implementierung, während der Planung, des Designs und der Änderungsfreigabe durchgeführt, nicht erst im Nachhinein während des Testens oder der Reaktion auf Störungen.

Der Begriff umfasst mehrere verwandte, aber unterschiedliche Tätigkeiten, die sich darin unterscheiden, was und wann sie analysiert werden:

Die Änderungsfolgenabschätzung ermittelt den Umfang einer geplanten Codeänderung, bevor diese umgesetzt wird. Sie identifiziert, welche Module, Funktionen, Datenbanktabellen und abhängigen Systeme infolge der geplanten Änderung angepasst oder erneut getestet werden müssen.

Die Testauswirkungsanalyse (TIA) ist eine spezielle Anwendung der Änderungsfolgenanalyse, die ermittelt, welche bestehenden Tests für eine bestimmte Codeänderung relevant sind. Anstatt die gesamte Testsuite auszuführen, wählt die TIA die minimale Teilmenge der Tests aus, die den geänderten Code und seine Abhängigkeiten abdecken. Dadurch wird die Testausführungszeit verkürzt, während die Abdeckung des betroffenen Bereichs erhalten bleibt.

Die Folgenabschätzung von Anforderungen ermittelt, welche Anforderungen, Designelemente und nachgelagerten Ergebnisse von einer Anforderungsänderung betroffen sind. In regulierten Branchen stellt dies sicher, dass alle von einer geänderten Anforderung abhängigen nachgelagerten Artefakte aktualisiert und erneut verifiziert werden.

Alle drei haben eine gemeinsame Grundlage: ein Abhängigkeitsmodell, das darstellt, wie Komponenten miteinander in Beziehung stehen, und einen Mechanismus, um dieses Modell von einem Startpunkt (der geänderten Komponente) aus zu durchlaufen und alles aufzulisten, was von dort aus erreichbar ist.

Die drei Arten der Wirkungsanalyse

Wirkungsanalysetechniken werden danach klassifiziert, wie sie Abhängigkeitsinformationen erfassen:

Typ	Methodik	Was es findet	Wann zu verwenden
Statische Wirkungsanalyse	Analysiert Quellcode, ohne ihn auszuführen.	Alle syntaktischen Referenzen: Funktionsaufrufe, Importe, Feldzugriffe, Schemaverweise	Vor der Implementierung, während der Änderungsplanung; funktioniert mit jeder Codebasis
Dynamische Wirkungsanalyse	Instrumente, die Code ausführen, um die tatsächlichen Ausführungspfade zu beobachten	Nur Komponenten, die während eines Testlaufs tatsächlich beansprucht wurden	Laufzeitspezifische Abhängigkeiten; identifiziert Pfade, die bei einer statischen Analyse möglicherweise übersehen werden.
Anforderungsbasiert (semantisch)	Stellt Rückverfolgbarkeitsverbindungen zwischen Anforderungen, Entwürfen und Code her.	Upstream- und Downstream-Artefakte, die von einer Anforderungsänderung betroffen sind	Regulierte Branchen; Systemtechnik; sicherheitskritische Software

Die statische Wirkungsanalyse ist die am weitesten verbreitete Methode, da sie ausschließlich mit Quellcode arbeitet und weder ein laufendes System noch eine Testinfrastruktur erfordert. Sie wird von den in diesem Leitfaden und von anderen Tools verwendeten Techniken eingesetzt. SMART TS XL Für die Analyse von Unternehmenscodebasen ergänzt die dynamische Analyse die statische Analyse, indem sie Laufzeitverhalten wie dynamisch erstellte Abfragen oder spät gebundene Funktionsaufrufe erfasst, die die statische Analyse allein aus dem Quellcode nicht ermitteln kann. In der Praxis kombinieren die meisten Programme zur Produktionsauswirkungsanalyse beides: Die statische Analyse liefert die grundlegende Abhängigkeitsübersicht, und das dynamische Profiling validiert diese anhand des beobachteten Laufzeitverhaltens.

Statische vs. dynamische Aufprallanalyse: Wesentliche Unterschiede

Die statische Wirkungsanalyse ist konservativ: Sie kann den betroffenen Bereich überschätzen, indem sie Abhängigkeiten einbezieht, die zwar im Code existieren, aber in der Praxis nie zum Tragen kommen. Die dynamische Wirkungsanalyse ist zwar präzise in Bezug auf die beobachteten Vorgänge, aber unvollständig. Sie erfasst nur, was während der instrumentierten Sitzung tatsächlich ausgeführt wurde, und lässt Pfade aus, die unter anderen Eingaben oder Konfigurationen ausgeführt werden. Für Produktionssysteme, in denen Vollständigkeit wichtiger ist als Präzision, ist die statische Analyse die sicherere Standardmethode.

Der Prozess der Wirkungsanalyse: Schritt für Schritt

Ein strukturierter Wirkungsanalyseprozess folgt unabhängig vom verwendeten Instrument einer einheitlichen Abfolge:

Schritt 1: Definieren Sie die Änderung. Ermitteln Sie genau, was sich ändert: die spezifische Funktion, das Feld, die Klasse, das Modul, das Copybook oder die Datenbankspalte. Die Präzision in diesem Schritt bestimmt die Genauigkeit aller nachfolgenden Schritte. Unpräzise Änderungsdefinitionen („Wir modifizieren das Zahlungsmodul“) führen zu ungenauen Ergebnissen.

Schritt 2: Erstellen oder Abfragen des Abhängigkeitsmodells. Das Abhängigkeitsmodell stellt die Beziehungen zwischen allen Systemkomponenten dar. Bei automatisierten Tools wird dieses Modell durch Parsen des Quellcodes erstellt. Für die manuelle Analyse kleiner Systeme kann es als Dokumentation gepflegt werden. Das Modell muss aktuell sein: Veraltete Abhängigkeitsdokumentation führt zu ungenauen Folgenabschätzungen.

Schritt 3: Durchlaufen Sie den Abhängigkeitsgraphen vom Änderungspunkt aus. Beginnen Sie bei der geänderten Komponente und folgen Sie allen eingehenden Abhängigkeitskanten (Komponenten, die von der geänderten Komponente abhängen) und ausgehenden Kanten (Komponenten, von denen die geänderte Komponente abhängt und die sich nach der Änderung möglicherweise anders verhalten). Fahren Sie transitiv fort, bis alle erreichbaren abhängigen Komponenten aufgelistet sind.

Schritt 4: Betroffene Komponenten nach Risiko klassifizieren. Nicht alle betroffenen Komponenten bergen das gleiche Risiko. Eine Komponente, die eine geänderte Funktion direkt aufruft, birgt ein höheres Risiko als eine, die fünf Abhängigkeitsebenen entfernt ist. Die Ergebnisse sollten nach Nähe, Kritikalität und Testabdeckung klassifiziert werden, um die Behebungsmaßnahmen gezielt auszurichten.

Schritt 5: Testumfang definieren. Die Liste der betroffenen Komponenten (im Folgenden: die vollständige Liste der betroffenen Komponenten) definiert den minimalen Testumfang. Jede Komponente in der Liste der betroffenen Komponenten, für die keine automatisierte Testabdeckung besteht, stellt ein Risiko dar, das entweder durch zusätzliche Tests oder durch manuelle Validierung behoben werden muss.

Schritt 6: Dokumentieren und prüfen. Die Folgenabschätzung wird dem Änderungsbeirat oder relevanten Interessengruppen als Grundlage für die Genehmigung der Änderung vorgelegt. Der aufgeführte Wirkungsbereich mit Risikoklassifizierung ersetzt die Schätzungen der Entwickler durch bauliche Nachweise.

Testauswirkungsanalyse: Wie sie in CI/CD funktioniert

Die Testauswirkungsanalyse (TIA) wendet die Wirkungsanalyse speziell auf das Testproblem an: Welche Tests müssen nach einer Codeänderung ausgeführt werden? Ohne TIA führen CI-Pipelines bei jedem Commit die gesamte Testsuite aus. In einer Codebasis mit 50,000 Tests und einer Testsuite, deren Ausführung 45 Minuten dauert, blockiert dies jeden Pull Request für 45 Minuten. Daher umgehen Entwickler diese Blockierung, pushen mehrere Commits, ohne auf die Ergebnisse zu warten, und verlieren so den Feedback-Loop, den Tests eigentlich liefern sollen.

TIA löst dieses Problem, indem es die Zuordnung zwischen Code und Tests verfolgt: Welche Codezeilen werden von welchen Tests abgedeckt? Wenn ein Commit bestimmte Zeilen ändert, wählt TIA nur die Tests aus, die diese Zeilen und ihre Abhängigkeiten abdecken. Eine Änderung, die drei von 50,000 Dateien betrifft, benötigt möglicherweise nur 200 statt 50,000 Tests. Die Pipeline läuft in Sekunden statt in Minuten.

Die Zuordnung erfolgt durch Instrumentierung der Testausführung zur Aufzeichnung von Abdeckungsdaten und anschließende Speicherung dieser Abdeckungsdaten, indiziert nach dem abgedeckten Code. Bei jedem neuen Commit:

1. Zeigt an, welche Dateien und Funktionen sich geändert haben (aus dem Git-Diff).
2. Prüft, welche Tests diese Dateien und Funktionen abdecken.
3. Fügt Tests hinzu, die jede Komponente im statischen Abhängigkeitsgraphen des geänderten Codes abdecken.
4. Führt die ausgewählte Teilmenge aus; alle übrigen Tests werden als unbeeinträchtigt angenommen und bestanden.

Zu den Tools, die TIA implementieren, gehören Microsofts Test Impact Analysis in Visual Studio, Parasofts TIA-Engine, Gradles Testauswahl und verschiedene CI-integrierte Plugins für Jest, pytest und andere Test-Runner. Die Genauigkeit von TIA hängt von der Genauigkeit des Abhängigkeitsmodells ab. Ein Tool, das nur die direkte Codeabdeckung ohne Abhängigkeitsanalyse verfolgt, erfasst beispielsweise keine Tests, die Komponenten abdecken, die drei Ebenen von der Änderung entfernt sind.

TIA in der Praxis: Vorher und Nachher

In einem typischen Backend-Service eines Unternehmens reduziert die Aktivierung von TIA die Testausführungszeit pro Pull Request um durchschnittlich 60–80 %. Der Nachteil besteht darin, dass sehr große Änderungen, die gemeinsam genutzte Hilfsprogramme, Basisklassen oder weit verbreitete Konfigurationen betreffen, weiterhin umfangreiche Test-Subsets auslösen können. TIA bietet den größten Nutzen bei der Feature-Entwicklung und Fehlerbehebung, wenn die Änderungen lokal begrenzt sind. Für übergreifende Änderungen wie Framework-Upgrades oder Änderungen am gemeinsamen Schema bleibt ein vollständiger Testlauf die sicherere Wahl.

Auswirkungsanalyse im Anforderungs- und Änderungsmanagement

In der Systementwicklung und der regulierten Softwareentwicklung erstreckt sich die Folgenabschätzung über den Code hinaus auf die gesamte Artefaktkette: Anforderungen, Designspezifikationen, Testfälle, Risikobewertungen und Nachweise. Eine geänderte Anforderung betrifft nicht nur den Code, sondern jedes Designelement, das diese Anforderung implementiert hat, jeden Testfall, der sie verifiziert hat, jede Risikobewertung, die sie zugrunde gelegt hat, und jede Compliance-Dokumentation, die darauf verweist.

Die anforderungsbasierte Wirkungsanalyse nutzt Rückverfolgbarkeitsbeziehungen, um diesen nachgelagerten Umfang zu ermitteln. Eine Rückverfolgbarkeitsmatrix, die jede Anforderung mit ihren implementierenden Designelementen, Testfällen und Verifizierungsnachweisen verknüpft, ermöglicht es, den gesamten Umfang der erforderlichen erneuten Verifizierung bei jeder Anforderungsänderung zu identifizieren. In regulierten Branchen – Medizinprodukte gemäß FDA 21 CFR Part 11, Luftfahrtsoftware gemäß DO-178C und Automobilsoftware gemäß ISO 26262 – ist dieser Umfang der erneuten Verifizierung eine regulatorische Anforderung und keine optionale Qualitätspraxis.

Die Verbindung zwischen Anforderungs- und Codeauswirkungsanalyse liegt in der Rückverfolgbarkeit: Lässt sich eine Anforderung auf eine bestimmte Softwarekomponente zurückführen und wird diese Komponente in einer Codeauswirkungsanalyse identifiziert, können die Ergebnisse der Auswirkungsanalyse genutzt werden, um den erneuten Verifizierungsaufwand auf die spezifischen Testfälle zu konzentrieren, die diese Komponente verifizieren. Moderne Anforderungsmanagement-Plattformen wie Jama Connect und IBM DOORS unterstützen diese Rückverfolgbarkeit und bieten integrierte Funktionen zur Auswirkungsanalyse auf Anforderungsebene.

Folgenabschätzung für große und veraltete Codebasen

Die Folgenabschätzung für große Codebasen, insbesondere für Unternehmenssysteme, die über Jahrzehnte gewachsen sind, unterscheidet sich qualitativ von der Folgenabschätzung für einen Dienst mit nur 10,000 Zeilen. Die Unterschiede im Umfang sind nicht nur quantitativer Natur. Große, bestehende Codebasen weisen Abhängigkeitsstrukturen auf, die kein aktives Teammitglied vollständig durchschaut: Tausende von Programmen mit impliziter Kopplung durch gemeinsam genutzte Datensätze, Copybooks, die von Hunderten von Programmen gleichzeitig eingebunden werden, und JCL-Jobstreams mit komplexer bedingter Ausführungslogik, die Laufzeitabhängigkeiten erzeugt.

Mehrere Merkmale großer Codebasen machen die manuelle Auswirkungsanalyse unzuverlässig:

Implizite Abhängigkeiten. In COBOL-Systemen erzeugt ein Copybook, das von 300 Programmen eingebunden wird, eine Abhängigkeit, die für Entwickler, die nicht gezielt danach suchen, unsichtbar ist. Eine Änderung an einem Copybook-Element, die wie eine Feldumbenennung aussieht, kann die Neukompilierung und das erneute Testen aller 300 Programme erforderlich machen. Ohne automatisierte Analyse wird dieser Bereich schrittweise entdeckt; jeder neue Fehler deckt eine weitere übersehene Abhängigkeit auf.

Sprachübergreifende Abhängigkeiten. Ein COBOL-Programm schreibt in eine DB2-Tabelle. Ein Java-Dienst liest aus derselben Tabelle. Eine Python-Pipeline verarbeitet die Ausgabe des Java-Dienstes. Eine Änderung am DB2-Schema wirkt sich auf alle drei Schichten aus. Kein statisches Analysetool für eine einzelne Sprache kann diese sprachübergreifende Kette nachverfolgen; es bedarf eines Tools, das alle drei Sprachen versteht und in einem einheitlichen Abhängigkeitsmodell verbindet.

Indirekte Abhängigkeiten durch Daten. Zwei Programme, die sich nie gegenseitig aufrufen, können dennoch über eine gemeinsame Datei gekoppelt sein. Programm A schreibt in Datensatz X; Programm B liest aus Datensatz X. Eine Änderung am Layout von Datensatz X betrifft beide Programme, aber die Abhängigkeit ist kein Funktionsaufruf, sondern ein Datenvertrag, der durch JCL-DD-Anweisungen und COBOL-FD-Definitionen ausgedrückt wird. Eine Strukturanalyse, die nur Funktionsaufrufe verfolgt, erfasst diese Art von Abhängigkeit nicht.

Toter Code und Erreichbarkeit. Große Codebasen sammeln definierten, aber nie aufgerufenen Code, Funktionen aus entfernten Features und Prozeduren an, die ersetzt, aber nicht gelöscht wurden. Eine Folgenabschätzung, die toten Code miteinbezieht, überschätzt den Änderungsumfang und konzentriert den Testaufwand auf Komponenten, die in der Produktion nie erreicht werden.

Die Legacy-Modernisierungsanalyselösung für diese Umgebungen muss all diese Fälle abdecken: Sie muss die tatsächlich verwendeten Sprachen (einschließlich COBOL, JCL, PL/I, RPG, Assembler und DB2) analysieren, implizite Abhängigkeiten über gemeinsame Datenstrukturen auflösen, sprachübergreifende Ketten verfolgen und erreichbaren von nicht erreichbarem Code unterscheiden.

Instrumente zur Wirkungsanalyse: Ein Vergleich

Die folgenden Tools decken die wichtigsten Kategorien der Wirkungsanalyse in der Softwareentwicklung ab. Jedes Tool wird danach bewertet, was es analysiert, welche Programmiersprachen es unterstützt und für welche Art von Wirkungsanalyseproblem es sich am besten eignet.

Werkzeug	Primärer Ansatz	Sprachen	Am besten geeignet für
SMART TS XL	Statische + sprachübergreifende Abhängigkeitszuordnung	COBOL, JCL, Java, Python, .NET, RPG, SQL	Auswirkungsanalyse für mehrsprachige Systeme in Unternehmen und Mainframes
Verstehen von SciTools	Statische Analyse, Aufrufdiagramme, Abhängigkeitsvisualisierung	Über 70 Sprachen	Mehrsprachige Code-Verständnis- und Wirkungssets
Struktur101	Architekturanalyse, Abhängigkeitsgraphen	Java, C#, JVM/.NET	Strukturelle Auswirkungen in Java/C#-Unternehmensanwendungen
CAST AIP	Anwendungsintelligenz, technische Schulden, Auswirkungen	Java, .NET, COBOL, SQL	Analyse der geschäftlichen und technischen Auswirkungen auf Portfolioebene
Axivion Suite	Semantische Abhängigkeitsgraphen für C/C++	C, C ++	Sicherheitskritische Systeme, MISRA-Konformität, eingebettet
Parasoft	Testauswirkungsanalyse, CI/CD-Integration	Java, C/C++, .NET	TIA in regulierten Branchen, sicherheitskritische Prüfungen
Jama Connect	Rückverfolgbarkeit von Anforderungen, Auswirkungen von Artefakten	Sprachunabhängig (Anforderungsniveau)	Systemtechnik, regulierte Branchen, DO-178C/ISO 26262
SonarQube	Codequalität, Abhängigkeitsanalyse innerhalb einer Sprache	Über 30 Sprachen	Codequalitätskontrollen; begrenzte systemübergreifende Wirkungsanalyse
IntelliJ IDEA / Eclipse	IDE-Aufrufhierarchie, Referenzanalyse	Java, Kotlin, Python	Lokale Auswirkungsanalyse auf Entwicklerebene innerhalb eines Projekts

Understand von SciTools ist das umfassendste Tool zur Wirkungsanalyse für Softwareteams, die mit modernen Programmiersprachen arbeiten. Die Funktion „Impact Sets“ berechnet die transitive Hülle aller Codeelemente, die von einer bestimmten Änderung betroffen sind – jede Funktion, Klasse und Variable, die über den Abhängigkeitsgraphen vom Ausgangspunkt aus erreichbar ist. Es unterstützt über 70 Programmiersprachen und erstellt detaillierte Aufrufgraphen, Datenflussdiagramme und Entity-Relationship-Maps.

Structure101 ist das leistungsstärkste Werkzeug für die Architektur-Auswirkungsanalyse von Java und C#. Es visualisiert die Paket- und Klassenabhängigkeitsstruktur als interaktive Karten und identifiziert Stellen, an denen vorgeschlagene Änderungen Architekturgrenzen verletzen oder neue Zyklen im Abhängigkeitsgraphen erzeugen.

CAST AIP arbeitet auf Portfolioebene und analysiert die gesamte Anwendungslandschaft, einschließlich COBOL, Java, .NET, SQL und anderer Sprachen, um neben technischen Auswirkungsanalysen auch Geschäftsauswirkungsbewertungen zu erstellen. Es wird häufig bei Due-Diligence-Prüfungen im Rahmen von Fusionen und Übernahmen sowie bei Portfoliooptimierungsprogrammen eingesetzt.

Axivion Suite zielt auf die sicherheitskritische C- und C++-Entwicklung ab, bei der die Wirkungsanalyse regulatorischen Anforderungen (ISO 26262, DO-178C, MISRA) genügen und einen formalen Nachweis über die Vollständigkeit der Analyse erbringen muss.

Parasoft ist die leistungsstärkste TIA-Lösung für regulierte Branchen mit einer CI/CD-integrierten Testauswahl-Engine, die die Testabdeckung bis auf Anweisungsebene verfolgt und Test-Subsets auf Basis einer präzisen Abhängigkeitsanalyse auswählt.

SonarQube bietet Abhängigkeitsanalyse innerhalb von Projekten und Code-Smell-Erkennung, ist aber nicht für die system- oder sprachübergreifende Wirkungsanalyse konzipiert. Sein Wert im Rahmen der Wirkungsanalyse liegt eher in der Qualitätssicherung, die identifiziert, welche geänderten Komponenten neue Qualitäts- oder Sicherheitsprobleme verursachen, als in der Abhängigkeitsabbildung.

IDE-basierte Tools (IntelliJ-Aufrufhierarchie, Visual Studio-Referenzanalyse, Eclipse-Aufrufgraph) bieten Entwicklern eine lokale Auswirkungsanalyse innerhalb eines Projekts. Sie eignen sich gut, um zu verstehen, welche Auswirkungen eine Änderung auf ein Modul hat, können aber keine projekt-, sprach- oder mainframeübergreifenden Abhängigkeiten nachverfolgen.

Wie SMART TS XL Führt Wirkungsanalysen durch

SMART TS XL Die Auswirkungsanalyse wird durchgeführt, indem jede Quelldatei in der Umgebung – COBOL-Programme, JCL-Jobstreams, Copybooks, SQL-Schemas, Java-Klassen, Python-Module, RPG-Programme usw. – analysiert und ein einheitliches Abhängigkeitsmodell erstellt wird, das alle strukturellen Beziehungen über alle Sprachen hinweg abbildet. Dieses Modell bildet die Grundlage: Die Auswirkungsanalyse ist eine Abfrage darauf, die von einer beliebigen Komponente ausgeht und den Abhängigkeitsgraphen durchläuft, um alle betroffenen Komponenten aufzulisten.

Wenn ein Team vorschlägt, ein COBOL-Copybook-Mitglied zu ändern, SMART TS XL Wirkungsanalyse Antworten: Welche Programme verwenden dieses Copybook? Welche dieser Programme werden von welchen JCL-Jobschritten aufgerufen? Welche DB2-Tabellen lesen oder schreiben diese Programme? Welche Java-Dienste greifen auf diese Tabellen zu? Welche Testfälle decken diese Programme ab? Die Antwort ist keine Schätzung, sondern eine vollständige, nummerierte Liste, die aus der tatsächlichen Codestruktur abgeleitet wurde und Dateinamen, Programmnamen, Jobnamen und Zeilennummern enthält.

Die Funktion zur Abbildung von Anwendungsabhängigkeiten generiert visuelle Diagramme des Abhängigkeitsgraphen, zentriert auf die geänderte Komponente. Dabei werden direkte und indirekte Abhängigkeiten farblich unterschieden und die Verbindungen mit dem höchsten Risiko hervorgehoben. Diese Diagramme dienen als Grundlage für die Überprüfung durch das Change Advisory Board (CAB) und als Leitfaden für die Testplanung.

Die JCL-Erweiterungsfunktion löst die symbolische Parameterersetzung in PROCs vor der Analyse auf und stellt so sicher, dass das Abhängigkeitsmodell die tatsächliche Laufzeitausführung und nicht unaufgelöste Template-Referenzen widerspiegelt. Eine PROC, die abhängig von symbolischen Parametern unterschiedliche Programme aufruft, wird zu allen Programmen aufgelöst, die sie tatsächlich über alle ihre Aufrufer aufruft – eine vollständige Abdeckung, die symbolunabhängigen Tools fehlt.

Für Unternehmensteams, die technische Due-Diligence-Prüfungen durchführen, die Modernisierung von Altsystemen planen oder Änderungen in Systemen managen, die mehrere Sprachen und Plattformen umfassen, SMART TS XL Unternehmenssuche Die Fähigkeit ermöglicht es, das Abhängigkeitsmodell abzufragen: Jede Verwendung eines bestimmten Feldes, jedes Programm, das eine bestimmte Funktion aufruft, jeder JCL-Job, der einen bestimmten Datensatz erzeugt, kann in Sekundenschnelle in einer Codebasis beliebiger Größe gefunden werden.

Best Practices für die Wirkungsanalyse

Führen Sie die Folgenabschätzung vor dem Schreiben des Codes durch, nicht danach. Ziel der Folgenabschätzung ist es, die Entscheidung für eine Änderung zu fundieren und den Umfang der anfallenden Arbeiten festzulegen, nicht aber, nach der Implementierung Fehler zu erklären. Eine Folgenabschätzung, die erst nach Beginn einer Änderung erstellt wird, ist eine nachträgliche Rechtfertigung, kein Planungsinstrument.

Definieren Sie den Umfang der Folgenabschätzung explizit. Folgenabschätzungsdiagramme in großen Systemen können nahezu alles umfassen. Legen Sie daher vor der Durchführung der Analyse den Analyseumfang, die maximale Abhängigkeitstiefe, den auszuschließenden toten Code und die nicht berücksichtigten Systeme fest. Eine unbeschränkte Traversierung liefert zwar technisch korrekte, aber operativ nutzlose Ergebnisse.

Unterscheiden Sie zwischen unbedingt notwendigen und zu überwachenden Tests. Nicht jede Komponente im Wirkungsbereich erfordert die gleiche Testreaktion. Eine Komponente, die die geänderte Funktion direkt in einem häufig aufgerufenen Pfad aufruft, muss erneut getestet werden. Eine Komponente, die die geänderte Funktion über fünf Ebenen selten ausgeführten Codes erreicht, kann im Produktivbetrieb überwacht werden. Die Risikoklassifizierung wandelt eine Wirkungsliste in einen Testplan um.

Halten Sie das Abhängigkeitsmodell aktuell. Eine Folgenabschätzung anhand eines veralteten oder unvollständigen Abhängigkeitsmodells ist schädlicher als gar keine Folgenabschätzung, da sie ein falsches Vertrauen in einen unkorrekten Geltungsbereich erzeugt. Abhängigkeitsmodelle müssen bei jeder wesentlichen Änderung am Quellcode neu generiert oder inkrementell über eine CI/CD-Integration aktualisiert werden, die geänderte Dateien automatisch neu analysiert.

Kombinieren Sie die Folgenabschätzung mit dem Änderungsmanagement. Die Folgenabschätzung entfaltet ihren vollen Nutzen, wenn ihre Ergebnisse in einen formalen Änderungsmanagementprozess einfließen. Ein Folgenabschätzungsbericht, der Umfang, Risikoklassifizierung und Testanforderungen dokumentiert, liefert den Änderungsbeiräten die notwendigen strukturellen Belege, um Genehmigungsentscheidungen auf Basis des tatsächlichen Systems und nicht auf Grundlage von Entwicklerschätzungen zu treffen.

Bei Altsystemen muss die implizite Datenkopplung berücksichtigt werden. Jede Abhängigkeitsanalyse eines Altsystems, die lediglich Funktionsaufrufe verfolgt, ist unvollständig. Programme, die über gemeinsam genutzte Dateien, Datensätze, Datenbanken und Message Queues gekoppelt sind, sind in Mainframe-Umgebungen üblich und bleiben bei einer reinen Funktionsaufrufanalyse unsichtbar. Das Abhängigkeitsmodell muss die Kopplung auf Datenebene berücksichtigen, um den gesamten Wirkungsbereich abzubilden.

Die Investition in die Infrastruktur zur Wirkungsanalyse, sei es durch ein spezielles Tool wie SMART TS XLDie Kosten für eine Testauswirkungsanalyse-Engine wie Parasoft oder eine Anforderungsrückverfolgbarkeitsplattform wie Jama amortisieren sich durch die Kosten von Änderungen, die keine unerwarteten Probleme verursachten, Tests, die nicht die gesamte Testsuite benötigten, und Bereitstellungen, die keine Vorfälle auslösten. Diese Amortisation ist nicht hypothetisch. Jeder Produktionsvorfall, der durch eine unentdeckte Abhängigkeit verursacht wird, verursacht direkte Kosten für die Analyse, die vor der Änderung nicht durchgeführt wurde.