Nachverfolgbarkeit – warum eigentlich?

(Traceability) ist ein wichtiges Konzept im Systems Engineering. Schon das V-Modell mit seinen Pfeilen suggeriert eine Traceability, und Standards aus dem Systems Engineering, wie die ISO 15288, fordern diese an vielen Stellen ein. Auch da, wo auf funktionale Sicherheit geachtet wird, spielt Nachverfolgbarkeit eine  große Rolle. Ob ISO 26262 (Fahrzeuge) oder ISO 13485 (Medizinprodukte), überall wird auf Nachverfolgbarkeit Wert gelegt.

Aber  wie bei vielen anderen Dingen darf die Erstellung und Pflege der Nachverfolgbarkeit kein Selbstzweck sein. Es soll Firmen geben, die eigene Abteilungen haben, die nichts anderes tun als die Traceability zu pflegen. Selbst wenn diese für Analysen herangezogen wird stellt sich die Frage, ob bei mehreren Vollzeitkräften das Kosten-Nutzen-Verhältnis gegeben ist. Aber selbst bei geringerem Aufwand ist dieser nur dann gerechtfertigt, wenn die Nachverfolgbarkeit auch effektiv eingesetzt wird. Worauf man dabei achten sollte, wird im Folgenden beleuchtet.

Die Anmeldung für das systems.camp Nord der GfSE am 7.10. in Hamburg läuft. Details und Anmeldung >>

Was ist ein Trace eigentlich?

Ein Trace ist zunächst einfach eine verfolgbare Beziehung. Diese muss noch nicht einmal explizit sein: Wenn zwei Dateien im selben Ordner liegen, könnte das die Beziehung zum selben Projekt darstellen. Wenn ein Begriff im Text auch im Glossar aufgeführt wird (und nachgeschlagen werden kann), so ist auch das eine Beziehung.

Im Systems Engineering wird in der Regel formaler gearbeitet. Professionelle Werkzeuge legen viele Traces automatisch ab: Dazu gehört zum Beispiel die Versionshistorie, die es Nutzern ermöglicht zu untersuchen, wie sich das Element über die Zeit verändert hat, und wer diese Änderungen durchgeführt hat.

Doch in der Regel denken wir bei Traces an explizit gesetzte Beziehungen, zum Beispiel zwischen Nutzeranforderung und Systemanforderung.

Was bedeutet die Beziehung?

Ein großes Problem bei der Nachverfolgbarkeit ist, dass oft nicht explizit definiert wird, was ein Trace eigentlich bedeutet. Dazu ein konkretes Beispiel:

In welche Richtung sollte der Pfeil zwischen „Functional Requirement“ und „Test Case“ gehen? Und was bedeutet der Trace?

Laut V-Modell ist (a) richtig: Der Test testet die Anforderung. Die Bedeutung der Beziehung ist „testet“.

Man kann aber auch für (b) argumentieren. Zum Beispiel, wenn der Pfeil eine Abhängigkeit darstellen soll: Die Anforderung hat das abhängige Element Test. Die Bedeutung der Beziehung ist „hat das abhängige Element“. Weiter unten zeige ich, wie diese Interpretation den Umgang mit Änderungen verbessern kann.

Hier zeichnet sich schon ab, dass es Probleme geben kann, wenn im Team nicht klar ist, was die Traces bedeuten. Und das ist vor allem  dann wichtig, wenn die Traces benutzt werden sollen, zum Beispiel für das Umgehen mit Änderungen.

Wenn die Bedeutung von Traces nicht klar ist und diese nicht konsistent eingesetzt werden, dann ist die Traceability weitgehendst wertlos. Twittern

Nachverfolgbarkeit nutzen

Mit modernen Werkzeugen kann die Traceability problemlos in beide Richtungen genutzt werden. Das ist ohne Werkzeug nicht so ohne weiteres der Fall. Um noch einmal das Beispiel Glossar aufzugreifen: Mit einem händisch gepflegten Glossar ist die Traceability von Anforderung nach Glossar einfach (im Glossar nachschlagen). Umgekehrt hingegen schwierig, und möglicherweise ungenau (wo überall wird dieser Begriff aus dem Glossar eingesetzt?).

Mit Werkzeugen sieht das anders aus. In einem professionellen Werkzeug würden „Requirement“ und „Test“ jeweils eigene Elemente sein, mit einem navigierbaren Trace dazwischen. Ein gutes Werkzeug sollte in der Lage sein, Die Testabdeckung zu bestimmen, egal, in welche Richtung die Traces laufen. Also konkret: Wie viele Anforderungen (und welche) werden von keinem Test abgedeckt? Diese Frage kann eigentlich jedes professionelle Anforderungs-Werkzeug beantworten. Zum Beispiel, indem ein entsprechender Filter oder ein entsprechender Report definiert wird.

Mit Änderungen umgehen

Ein weiterer Bereich, wo Traces extrem wichtig und hilfreich sind, ist beim Umgang mit Änderungen. Schauen wir uns dazu das Beispiel mit Anforderung und Test an. Hier spielt nun die Richtung eine Rolle: Wenn der Test angepasst wird, so hat dies keine Auswirkungen auf das Requirement. Denn es wird immer noch das selbe Requirement getestet. Wenn sich hingegen die Anforderung ändert, dann kann es sein, dass der Test nicht mehr dazu passt, und muss überprüft werden. Für diesen Zweck haben viele Werkzeuge die Möglichkeit ein sogenanntes „Suspekt“-Flag zu setzen. Wenn sich also im konkreten Beispiel das Requirement ändert, so würde der Trace zum Test suspekt: Ein Mensch muss untersuchen, ob der Test in der aktuellen Form auch für die veränderte Anforderung noch gültig ist. Wenn ja, dann kann das Suspekt-Flag zurückgesetzt werden. Wenn nein, dann muss der Test angepasst werden. Dies kann dann weitere suspekte Beziehungen auslösen.

Es hat sich in der Praxis bewährt, dass die Richtung der Nachverfolgbarkeit universell für das Setzen des Suspekt-Links genutzt wird. So ein Vorgehen hat zum einen den Vorteil, dass sofort klar ist, was die Richtung bedeutet. Es macht auch eine Traceability-Analyse intuitiv verständlich. Also konkret: Welche Lawine von suspekten Links würde eine Änderung auslösen?

Es hat sich bewährt, die Richtung der Nachverfolgbarkeit zu nutzen, um bei Änderungen „suspekte“ Elemente zu finden. Twittern

Noch eine letzte Anmerkung zum Thema „Suspekt“: Nicht jede Änderung sollte ein Suspekt auslösen. Wenn zum Beispiel die Priorität eines Requirements sich ändert, so sollte dies keine Auswirkungen auf den Test haben.

Nicht alles darf verknüpft werden

Zuletzt sollte nicht jede Beziehung erlaubt sein. Statt dessen sollte im Vorwege sorgfältig überlegt werden, welche Beziehungen es gibt, und welche verpflichtend sind (für Vollständigkeitsanalysen). Hier ist ein Beispiel für ein einfaches Datenmodell:

Dabei bedeutet ein durchgezogener Pfeil, dass die Beziehung bestehen muss, gestrichelte Linien zeigen optionale Beziehungen. Ein gutes Werkzeug würde nur das Anlegen der gezeigten Beziehungen erlauben.

Weiter oben fragten wir uns, welche Richtung zwischen „Functional Requirement“ und „Test Case“ die richtige ist. Mit der Semantik der suspekten Elemente macht Lösung (b) mehr Sinn als Lösung (a), welche das V-Modell suggerieren würde.

Fazit

Eine gute Nachverfolgbarkeit sorgt für robuste, vollständige Systembeschreibungen und hilft im Umgang mit Änderungen. Damit das funktioniert, muss es ein verständliches Traceabilitymodell geben. Und man braucht ein gutes Werkzeug um die Traceability auch effektiv nutzen zu können. Wenn aber beides gegeben ist, dann hat man eine solide Basis für jedes Entwicklungsprojekt.