Deutsche BlogsRequirements EngineeringValidation und Verifikation

Traceability – Aber bitte mit Köpfchen und nicht Alles zu Allem verlinken!

Traceability Strategien

Standen Sie auch schon mal vor folgender Situation: Ihr sicherheitsgerichtetes Projekt steht kurz vor dem Abschluss, und Sie haben nahezu alle Teilprodukte untereinander in Beziehung gesetzt („verlinkt“). Es wurde erheblicher Aufwand in die Traceability gesteckt!
In einem Audit (z.B. interne QS, Kunde, Behörde) sollen Sie aufzeigen, welche Software Requirements sich aus welchen System Requirements herleiten. Jedes Software Requirement ist auf eines oder mehrere System Requirements verlinkt und auch jedes System Requirement ist auf ein oder mehrere Software- oder Hardware Requirements verlinkt.

Traceability und Audits

Trotzdem wird im Audit festgestellt, dass viele Software Requirements, zwar schon „irgendwie“ mit den verlinkten System Requirements zusammenhängen, eine durchgängige Strategie ist aber nicht erkennbar. Spätestens, wenn dann bei weiteren auditierten Beispielen festgestellt wird, dass manche Aspekte von System Requirements gar nicht in der Software (oder Hardware) umgesetzt sind wird das Audit stressig.
Nach so einer Audit-Erfahrung stellt man sich fast zwangsläufig die Frage, was den Einsatz von (teuren) Tools rechtfertigt und vor allem, ob man beim nächsten Mal den Aufwand für die Traceability nicht drastisch reduzieren sollte.
Statt dies zu tun, sollte man aber die (echten) Ursache für das Problem ausfindig machen.
Grundsätzlich ist der Einsatz von Tools sehr sinnvoll und es gibt auch den Mehrwert der Traceability.

Traceability “Alles zu Allem”

Eine wesentliche Ursache für die beschriebenen Probleme ist oft das sogenannte „Verlinken von Allem zu Allem“, als Ersatz für die Anwendung einer projektspezifischen Traceability Strategie. Bevor es die komfortable Toolunterstützung bei der Erstellung der Traceability gab, war dieses Problem aber schlicht nicht vorhanden. Der Aufwand für unüberlegte und von Hand zu erstellender Traceability war viel zu groß. Aus diesem Aspekt heraus war man gezwungen, sich sehr intensive Gedanken zu folgenden Herausforderungen zu machen und es musste eine effiziente Lösung gefunden werden:

  1. Welche Maßnahmen zur Risikominimierung aus der Gefahren- und Risikoanalyse, werden in welchem(n) Requirement(s) umgesetzt?
  2. Welche Software Requirements implementieren (wirklich!) welche Systemfunktionalität (=System Requirements)?
  3. Welches Software Requirement leitet sich nicht aus System Requirements ab, sondern entsteht als Konsequenz von Architekturentscheidungen und sollte daher als „Derived“ Requirement (= kein Link zu einem anderen funktionalen Requirement) stehen bleiben?
  4. Welcher Source Code leitet sich nicht aus funktionalen Requirements ab, sondern z.B. aus der Schnittstelle zur Hardware?
  5. Welcher Source Code entsteht z.B.: auf Grund von angewandten Prinzipien wie Defensives Programmieren und nicht aufgrund von funktionalen Requirements?
  6. Welche Tests verifizieren wirklich welches Requirement?
  7. In welchem Architekturblock sind welche Requirements umgesetzt?

Diese Liste an Fragestellungen erhebt keinen Anspruch auf Vollständigkeit.
Sie bildet aber eine sehr gute Grundlage um das zu Beginn beschriebene Problem gar nicht erst entstehen zu lassen. Heutzutage ist es wesentlich einfacher, die einzelnen Artefakte im Software Entwicklungsprozess zu einander in Beziehung zu setzen. Es gibt eine Vielzahl von datenbankgestützten Tools die den Aufwand und die Fehleranfälligkeit für die Erstellung einer Traceability dramatisch reduzieren. Wenn man dann sich die oben beschriebenen Fragestellungen bewusst macht und entsprechende Lösungen erarbeitet, ist man auf einem guten Weg den gewünschten Mehrwert der Verlinkung einzelner Artefakte zu erzielen.

Fazit:

Der Mehrwert einer guten Traceability liegt im Wesentlichen in folgenden Aspekten:

  1. Sehr effektives Mittel zur Sicherstellung, dass das vom Kunden gewünschte Produkt auch entsprechend gebaut wurde.
  2. Einfache und schnelle Nachvollziehbarkeit des Weges vom System Requirement zum Source Code.
  3. Unterstützung von Einflussanalysen im Falle von Änderungen.
  4. Unterstützung/Vereinfachung einer Vollständigkeitsprüfung bezüglich Implementierung.
  5. Unterstützung/Vereinfachung einer Vollständigkeitsprüfung bezüglich Verifikation.

Gerne unterstütze ich Sie auch bei individuellen Fragen zu Ihrem Projekt. Senden Sie eine Mail an: martin.heininger[at]heicon-ulm.de
Einen unverbindlichen Überblick über die Leistungen finden sie auch auf der
HEICON Homepage.

4 Gedanken zu „Traceability – Aber bitte mit Köpfchen und nicht Alles zu Allem verlinken!

  1. hi! , Everyone loves a persons writing quite definitely! promote many of us keep up a correspondence more info on your own document for Yahoo? I need a pro for this dwelling to unravel this dilemma. Could be that is definitely a person! Looking forward to search an individual.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.