Werkzeugübergreifende Nachverfolgbarkeit: Referenzieren oder Synchronisieren?

Dass Nachverfolgbarkeit wichtig ist, wurde hier ja schon beleuchtet. Professionelle Werkzeuge im Systems Engineering Umfeld unterstützten dies auch in der Regel. Doch ein Werkzeug reicht in der Regel nicht aus (Siehe Frage 3 in Sieben Fragen für die richtige Werkzeugwahl für Systems Engineering). Und in dem Moment, wo mehr als ein Werkzeug gebraucht wird stellt sich die Frage, Wie Nachverfolgbarkeit über Werkzeuggrenzen realisiert werden kann. Dabei stößt man oft auf zwei Ansätze, Referenzieren und Synchronisieren.

Bevor wir uns diese Lösungen anschauen ist es natürlich wichtig, das Problem zu verstehen: Welche Anwendungsfälle sollen mit Hilfe einer werkzeugübergreifenden Nachverfolgbarkeit eigentlich realisiert werden, und warum? Das ist die erste Frage, die im Folgenden diskutiert wird. Dann schauen wir uns die möglichen Lösungen noch einmal genauer an.

Was soll erreicht werden?

Von den vielen Möglichkeiten für die Nutzung von Nachverfolgbarkeit stechen zwei heraus, die in der Praxis eine wichtige Bedeutung haben:

Abdeckung (Coverage): Über eine Nachverfolgung kann sichergestellt werden, dass „alles berücksichtigt wurde“. Konkret: Wenn es von jeder Stakeholderanforderung eine Verknüpfung zu mindestens einer Systemanforderung gibt, können wir davon ausgehen, dass alle  Stakeholderanforderungen berücksichtigt  wurden.

Umgang mit Änderungen: Eine Änderung markiert automatisch alle „abgeleiteten“ Anforderungen als „suspekt“.  Abgeleitet ist hier in Anführungszeichen, weil das Wort teilweise  sehr unterschiedlich eingesetzt wird. Wichtig ist hier jedoch, dass nur Änderungen auf einer Seite der Beziehungen  für das Setzen von „suspekt“ herangezogen werden.

Konkretes Beispiel ist die folgende Kundenanforderung: „Das Auto soll eine Reichweite von 250km haben“. Abgeleitete Systemanforderung: „Die Batterie hat eine Kapazität von mindestens 50 kWh“. Wenn nun aufgrund eines zusätzlichen Verbrauchers  die Kapazität auf 55 kWh erhöht wird, hat dies keinen Einfluss auf die Kundenanforderung. Wenn jedoch die Reichweite auf 300km erhöht wird, muss unbedingt die abgeleitete Systemanforderung überprüft und ggf. nachgebessert werden. In dem Fall würde also die  Systemanforderung als „suspekt“ markiert werden.

Die zwei wichtigsten Anwendungsfälle für Nachverfolgbarkeit sind Coverage und Änderungsmanagement. Twittern

Was können die Werkzeuge?

Bevor wir uns mit werkeugübergreifender Nachverfolgbarkeit beschäftigen muss sichergestellt werden, dass die Werkzeuge selbst diese Anwendungsfälle unterstützen. Ein typisches Beispiel wäre ein RE-Werkzeug und ein SysML-Modellierungswerkzeug. Ein Großteil der professionellen RE-Werkzeuge unterstützt Coverage und Suspekte Beziehungen. Modellierungswerkzeuge tun sich  in der Regel  etwas schwerer mit diesen Themen, und die günstigsten Editionen haben oft keine, oder nur eine sehr  rudimentäre Unterstützung von Coverage und Change Management.  Coverage kann in der Regel über entsprechende Filter realisiert werden, Änderungsmanagement gibt es wohl auch, habe ich in der Praxis allerdings noch nicht testen können (bspw.  unterstützt Magicdraw seit 18.3 „Suspect Links“).

Der wichtige Punkt ist jedoch: Bevor Anwendungsfälle Werkzeugübergreifend realisiert werden können, sollten sie im jeweiligen Werkzeug gelöst sein. Allerdings gibt es dazu eine Ausnahme.

Traceability im separaten Werkzeug?

Es gibt auch Werkzeuge, die die Traceability „auslagern“. Das hat zwei Vorteile: Zum einen ist man plötzlich nicht mehr auf die Möglichkeiten des Werkzeugs angewiesen. Und zum anderen wird die Nachverfolgbarkeit dann konsistent und werkzeugunabhängig realisiert. Das ermöglicht dann sogar  das Einbeziehen von  Datenformaten, die gar keine Nachverfolgung kennen, wie bspw. Word oder sogar PDF. Vertreter dieser Kategorie sind Reqtify oder SmartFacts. Die Nachteile liegen aber auch auf  der Hand: Die Qualität der Integration spielt für die tägliche Benutzbarkeit eine große Rolle,  und die ist bei manchen Lösungen nicht adäquat. In welchem Werkzeug wird bspw. die Traceability  angelegt? Weiterhin ist die Frage, wie genau Änderungen erkannt werden, und wie damit  umgegangen wird.

Aber um auf das Thema zurückzukommen: Wer  sich für so eine Lösung entscheidet, der muss sich – theoretisch – nicht mehr um die werkzeugübergreifende Nachverfolgbarkeit kümmern. Natürlich muss das Traceability-Werkzeug für die einzelnen Trace-Quellen konfiguriert werden, was sehr aufwändig sein kann.

Meiner Erfahrung nach macht diese Lösung nur Sinn bei einer sehr umfangreichen Werkzeuglandschaft und einer kompetenten IT-Abteilung, die das Ganze konfiguriert  und am Laufen hält.

Und nun: Werkzeugübergreifende Nachverfolgbarkeit

Für eine werkzeugübergreifende Nachverfolgbarkeit gibt es, wie gesagt, im Wesentlichen die Ansätze Referenzieren und Synchronisieren:

Beim Referenzieren wird lediglich eine ID gespeichert, mit der das verknüpfte Element gefunden werden kann. Das kann händisch oder automatisiert erfolgen. Moderne Werkzeuge ermöglichen es oft, per URL ein Element zu referenzieren. Die URL per Hand einzufügen ist eine simple Umsetzung der Referenzierung. Interessant wird es, wenn eine Version Teil der URL ist. Ohne den Bezug auf eine konkrete Version ist der Umgang mit Änderungen schwer möglich.

Beim Synchronisieren werden die eigentlichen Informationen kopiert. Das bedeutet, dass die Informationen veralten können, und ist ohne einen funktionierenden Synchronisierungsmechanismus gefährlich, weil aus Versehen auf veralteten Daten gearbeitet werden könnte.

Was hier vielleicht schon klar wird: Beide  Ansätze lösen das selbe Problem auf unterschiedliche Weisen. Die Gefahren sind einfach nur leicht unterschiedlich gelagert. Zum Beispiel besteht bei beiden Ansätzen die Gefahr, aus Versehen mit zu alten – oder zu aktuellen – Daten zu arbeiten.

Ich sehe allerdings bei der Synchronisierung einige Vorteile, die bei der Referenzierung nicht immer leicht zu realisieren sind. Dazu gehört:

• Bei der Synchronisierung handelt es sich um eine 1:1 Beziehung, die zwischen den Werkzeugen verwaltet werden muss. Dies ist aus Prinzip einfacher als eine 1:n oder n:m-Beziehung.
• Bei der Synchronisierung können Daten bei Bedarf in beide Richtungen bewegt werden. Es kann also bspw eine Änderung einer Anforderung im SysML-Werkzeug ins RE-Werkzeug zurücksynchronisiert werden. Bei der Referenzierung würde die Anforderung im RE-Werkzeug referenziert werden, und müsste auch dort geändert werden. Hier natürlich die Anmerkung, dass eine unidirektionale Synchronisierung weniger fehleranfällig ist.
• Die Daten stehen in beiden Werkzeugen für die Analyse in den entsprechenden Werkzeugen zur Verfügung.

Fazit

Aus dem Artikel geht wohl hervor, dass ich  zur Synchronisierung tendiere – natürlich nur, wenn die Werkzeuge das auch ordentlich unterstützen. Das Vorgehen hat sich für mich auch in der Praxis bewährt. Ich kenne allerdings genug kompetente Kollegen, die Daten-Duplizierung scheuen wie der Teufel das Wasser. Ich sehe da insofern keine große  Gefahr, solange die Werkzeuge damit umgehen können. Ich lasse mich aber auch gern eines besseren belehren.

Manche Kollegen scheuen Daten-Duplizierung wie der Teufel das Wasser. Wenn die Werkzeuge damit umgehen können, sehe ich da kein Problem.  Twittern

Ich habe mich vor kurzem im Auftrag von Jama Software mit dem Datenaustausch zwischen Jama (Anforderungen) und MagicDraw (SysML) auseinandergesetzt. Wer daher eine bidirektionale Synchronisierung zwischen zwei Werkzeugen sehen möchte, kann sich entweder die Zusammenfassung anschauen (5 Minuten) oder das Webinar (55 Minuten).