{"id":1197,"date":"2017-08-24T08:00:02","date_gmt":"2017-08-24T06:00:02","guid":{"rendered":"https:\/\/se-trends.de\/?p=1197"},"modified":"2017-08-19T14:56:07","modified_gmt":"2017-08-19T12:56:07","slug":"cross-tool-traceability","status":"publish","type":"post","link":"https:\/\/www.se-trends.de\/en\/werkzeuguebergreifende-nachverfolgbarkeit\/","title":{"rendered":"Cross-tool traceability: referencing or synchronization?"},"content":{"rendered":"

Dass Nachverfolgbarkeit<\/a> wichtig ist, wurde hier ja schon beleuchtet. Professionelle Werkzeuge im Systems Engineering Umfeld unterst\u00fctzten dies auch in der Regel. Doch ein Werkzeug reicht in der Regel nicht aus (Siehe Frage 3 in Sieben Fragen f\u00fcr die richtige Werkzeugwahl f\u00fcr Systems Engineering<\/a>). Und in dem Moment, wo mehr als ein Werkzeug gebraucht wird stellt sich die Frage, Wie Nachverfolgbarkeit \u00fcber Werkzeuggrenzen realisiert werden kann. Dabei st\u00f6\u00dft man oft auf zwei Ans\u00e4tze, Referenzieren und Synchronisieren.<\/p>\n

Bevor wir uns diese L\u00f6sungen anschauen ist es nat\u00fcrlich wichtig, das Problem zu verstehen: Welche Anwendungsf\u00e4lle sollen mit Hilfe einer werkzeug\u00fcbergreifenden Nachverfolgbarkeit eigentlich realisiert werden, und warum? Das ist die erste Frage, die im Folgenden diskutiert wird. Dann schauen wir uns die m\u00f6glichen L\u00f6sungen noch einmal genauer an.<\/p>\n

Was soll erreicht werden?<\/h2>\n

Von den vielen M\u00f6glichkeiten f\u00fcr die Nutzung von Nachverfolgbarkeit stechen zwei heraus, die in der Praxis eine wichtige Bedeutung haben:<\/p>\n

Abdeckung (Coverage):<\/strong> \u00dcber eine Nachverfolgung kann sichergestellt werden, dass „alles ber\u00fccksichtigt wurde“. Konkret: Wenn es von jeder Stakeholderanforderung eine Verkn\u00fcpfung zu mindestens einer Systemanforderung gibt, k\u00f6nnen wir davon ausgehen, dass alle\u00a0 Stakeholderanforderungen ber\u00fccksichtigt\u00a0 wurden.<\/p>\n

Umgang mit \u00c4nderungen:<\/strong> Eine \u00c4nderung markiert automatisch alle „abgeleiteten“ Anforderungen als „suspekt“.\u00a0 Abgeleitet ist hier in Anf\u00fchrungszeichen, weil das Wort teilweise\u00a0 sehr unterschiedlich eingesetzt wird. Wichtig ist hier jedoch, dass nur \u00c4nderungen auf einer Seite der Beziehungen\u00a0 f\u00fcr das Setzen von „suspekt“ herangezogen werden.<\/p>\n

Konkretes Beispiel ist die folgende Kundenanforderung: „Das Auto soll eine Reichweite von 250km haben“. Abgeleitete Systemanforderung: „Die Batterie hat eine Kapazit\u00e4t von mindestens 50 kWh“. Wenn nun aufgrund eines zus\u00e4tzlichen Verbrauchers\u00a0 die Kapazit\u00e4t auf 55 kWh erh\u00f6ht wird, hat dies keinen Einfluss auf die Kundenanforderung. Wenn jedoch die Reichweite auf 300km erh\u00f6ht wird, muss unbedingt die abgeleitete Systemanforderung \u00fcberpr\u00fcft und ggf. nachgebessert werden. In dem Fall w\u00fcrde also die\u00a0 Systemanforderung als „suspekt“ markiert werden.<\/p>\n

Die zwei wichtigsten Anwendungsf\u00e4lle f\u00fcr Nachverfolgbarkeit sind Coverage und \u00c4nderungsmanagement. [tweetthis]Die zwei wichtigsten Anwendungsf\u00e4lle f\u00fcr Nachverfolgbarkeit sind Coverage und \u00c4nderungsmanagement.[\/tweetthis]<\/p><\/blockquote>\n

Was k\u00f6nnen die Werkzeuge?<\/h2>\n

Bevor wir uns mit werkeug\u00fcbergreifender Nachverfolgbarkeit besch\u00e4ftigen muss sichergestellt werden, dass die Werkzeuge selbst diese Anwendungsf\u00e4lle unterst\u00fctzen. Ein typisches Beispiel w\u00e4re ein RE-Werkzeug und ein SysML-Modellierungswerkzeug. Ein Gro\u00dfteil der professionellen RE-Werkzeuge unterst\u00fctzt Coverage und Suspekte Beziehungen. Modellierungswerkzeuge tun sich\u00a0 in der Regel\u00a0 etwas schwerer mit diesen Themen, und die g\u00fcnstigsten Editionen haben oft keine, oder nur eine sehr\u00a0 rudiment\u00e4re Unterst\u00fctzung von Coverage und Change Management.\u00a0 Coverage kann in der Regel \u00fcber entsprechende Filter realisiert werden, \u00c4nderungsmanagement gibt es wohl auch, habe ich in der Praxis allerdings noch nicht testen k\u00f6nnen (bspw.\u00a0 unterst\u00fctzt Magicdraw seit 18.3 „Suspect Links“<\/a>).<\/p>\n

Der wichtige Punkt ist jedoch: Bevor Anwendungsf\u00e4lle Werkzeug\u00fcbergreifend realisiert werden k\u00f6nnen, sollten sie im jeweiligen Werkzeug gel\u00f6st sein. Allerdings gibt es dazu eine Ausnahme.<\/p>\n

Traceability im separaten Werkzeug?<\/h2>\n

Es gibt auch Werkzeuge, die die Traceability „auslagern“. Das hat zwei Vorteile: Zum einen ist man pl\u00f6tzlich nicht mehr auf die M\u00f6glichkeiten des Werkzeugs angewiesen. Und zum anderen wird die Nachverfolgbarkeit dann konsistent und werkzeugunabh\u00e4ngig realisiert. Das erm\u00f6glicht dann sogar\u00a0 das Einbeziehen von\u00a0 Datenformaten, die gar keine Nachverfolgung kennen, wie bspw. Word oder sogar PDF. Vertreter dieser Kategorie sind Reqtify<\/a> oder SmartFacts<\/a>. Die Nachteile liegen aber auch auf\u00a0 der Hand: Die Qualit\u00e4t der Integration spielt f\u00fcr die t\u00e4gliche Benutzbarkeit eine gro\u00dfe Rolle,\u00a0 und die ist bei manchen L\u00f6sungen nicht ad\u00e4quat. In welchem Werkzeug wird bspw. die Traceability\u00a0 angelegt? Weiterhin ist die Frage, wie genau \u00c4nderungen erkannt werden, und wie damit\u00a0 umgegangen wird.<\/p>\n

Aber um auf das Thema zur\u00fcckzukommen: Wer\u00a0 sich f\u00fcr so eine L\u00f6sung entscheidet, der muss sich \u2013 theoretisch \u2013 nicht mehr um die werkzeug\u00fcbergreifende Nachverfolgbarkeit k\u00fcmmern. Nat\u00fcrlich muss das Traceability-Werkzeug f\u00fcr die einzelnen Trace-Quellen konfiguriert werden, was sehr aufw\u00e4ndig sein kann.<\/p>\n

Meiner Erfahrung nach macht diese L\u00f6sung nur Sinn bei einer sehr umfangreichen Werkzeuglandschaft und einer kompetenten IT-Abteilung, die das Ganze konfiguriert\u00a0 und am Laufen h\u00e4lt.<\/p>\n

Und nun: Werkzeug\u00fcbergreifende Nachverfolgbarkeit<\/h2>\n

F\u00fcr eine werkzeug\u00fcbergreifende Nachverfolgbarkeit gibt es, wie gesagt, im Wesentlichen die Ans\u00e4tze Referenzieren und Synchronisieren:<\/p>\n

Beim Referenzieren<\/strong> wird lediglich eine ID gespeichert, mit der das verkn\u00fcpfte Element gefunden werden kann. Das kann h\u00e4ndisch oder automatisiert erfolgen. Moderne Werkzeuge erm\u00f6glichen es oft, per URL ein Element zu referenzieren. Die URL per Hand einzuf\u00fcgen 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 \u00c4nderungen schwer m\u00f6glich.<\/p>\n

Beim Synchronisieren<\/strong> werden die eigentlichen Informationen kopiert. Das bedeutet, dass die Informationen veralten k\u00f6nnen, und ist ohne einen funktionierenden Synchronisierungsmechanismus gef\u00e4hrlich, weil aus Versehen auf veralteten Daten gearbeitet werden k\u00f6nnte.<\/p>\n

Was hier vielleicht schon klar wird: Beide\u00a0 Ans\u00e4tze l\u00f6sen das selbe Problem auf unterschiedliche Weisen. Die Gefahren sind einfach nur leicht unterschiedlich gelagert. Zum Beispiel besteht bei beiden Ans\u00e4tzen die Gefahr, aus Versehen mit zu alten \u2013 oder zu aktuellen \u2013 Daten zu arbeiten.<\/p>\n

Ich sehe allerdings bei der Synchronisierung einige Vorteile, die bei der Referenzierung nicht immer leicht zu realisieren sind. Dazu geh\u00f6rt:<\/p>\n