Was ist eine Impaktanalyse? (Und warum ist sie im SE wichtig?)

Wenn sich etwas ändert, dann wollen wir die Auswirkungen davon verstehen – idealerweise, bevor die Änderung vorgenommen wird. Die Impaktanalyse ist das richtige Werkzeug dabei. Was für den effizienten Einsatz zu beachten ist, erkläre ich im Folgenden.

Ein Beispiel

Im folgenden Bild ist eine einfache Impaktanalyse zu sehen. Orange umrandet ist die Anforderung, die untersucht werden soll (AIS-ASTK-2). Voraussetzung für eine Impaktanalyse ist eine gepflegte Traceability. In diesem Beispiel wurden zwei Verknüpfungen „nach unten“ gezogen. Zum einen wurde eine Systemanforderung verknüpft (AIS-ASYS-50). Weiterhin wurde auch ein Akzeptanztest angelegt (AIS-VAL-12).

Doch eines dieser Elemente hat ebenfalls eine Verknüpfung: Der Test wurde wohl nicht bestanden und ist daher mit einem Defekt verknüpft (AIS-BUG-4). In der Spalte „Path“ ist das zu sehen. Eine Impaktanalyse kann über beliebig viele Stufen laufen.

Die hier gezeigte Impaktanalyse wurde mit Jama Software generiert. Eine Impaktanalyse verändert nicht den Aufwand einer Änderungen – aber sie verhindert unschöne Überraschungen.

Atomare Elemente ein Muss

Damit eine Impaktanalyse funktioniert, ist es unumgänglich, mit einzelnen Elementen zu arbeiten. Natürlich ist grundsätzlich auch bei einer dokumentenbasierten Arbeit eine Impaktanalyse möglich; jedoch haben dann die Aussagen wenig Nutzen: Wir wissen dann lediglich, dass die Änderungen in einem Dokument Änderungen in einem anderen hervorrufen. Als sich das Systems Engineering in den 60ern entwickelte, wurde mit langen Iterationen (mehrere Monate) gearbeitet. Denn der Overhead für eine Iteration war extrem hoch.

Heute nehmen uns Werkzeuge die Arbeit ab, weshalb die Länge der Iterationen drastisch gekürzt werden kann und auch gekürzt werden sollte: Denn kurze Iterationen machen es wesentlich leichter, mit Veränderung umzugehen.

Traceability

Eine Impaktanalyse ist nur dann zuverlässig, wenn wir auch der Traceability trauen können. Daher ist es wichtig, diese konsequent und kontinuierlich zu pflegen. Auch das ist nur mit entsprechender Werkzeugunterstützung möglich.

Bevor es gute Werkzeuge gab, wurde die Pflege der Traceability als lästige Pflicht angesehen. Es gab sogar Produkte, bei denen die Traceability erst nach Fertigstellung angelegt wurde – um der Compliance Genüge zu tun! Das ist nicht weise, denn die Traceability kann an vielen Stellen sehr nützlich sein

Das ist mir suspekt!

Ein gutes Beispiel dabei ist ein Feature, dass sich in vielen Werkzeugen findet: Das „Suspect“-Flag. Dabei wird eine Verknüpfung als suspekt markiert, wenn sich das Quellelement ändert. Ein konkretes Beispiel: Wenn sich die Anforderung „Die Laufzeit des Gerätes beträgt mindestens 24 Stunden“ ändert, dann wird die Verknüpfung zum Test als suspekt markiert. Dadurch kann dann zu einem späteren Zeitpunkt der verknüpfte Test überprüft werden. Wenn die Laufzeit auf 48 Stunden erhöht wurde, muss der Test sicherlich angepasst werden.

Werkzeugübergreifende Nachverfolgbarkeit

Gerade im Systems Engineering stehen wir oft vor der Herausforderung, dass wir mit vielen spezialisierten Werkzeugen arbeiten. Doch die Analysewerkzeuge sind typischerweise im Werkzeug verbaut und können Werkzeuggrenzen nicht überbrücken. An solchen Stellen muss sorgfältig gearbeitet werden. Falls hier händisch gearbeitet werden muss, kann es Sinn machen, dass die Daten zwischen den Werkzeugen in einem längeren Abstand synchronisiert werden (bspw. in jeder 4. Iteration). Es macht auf jeden Fall Sinn, die Menge an Daten, die zwischen Werkzeugen ausgetauscht werden, klar zu definieren und so klein wie möglich zu halten.

Natürlich gibt es auch Lösungen für werkzeugübergreifende Impaktanalyse (wie zum Beispiel Syndeia). Diese sind aber in der Regel teuer, aufwendig zu konfigurieren und daher nur in Projekten entsprechender Größe und Komplexität sinnvoll.

Screenshot: Jama Software
Photo by JJ Ying on Unsplash