6 Wege, Modelle zu verknüpfen

Das V-Modell wird oft herangezogen um zu zeigen, wie die Artefakte der Systementwicklung in Relation zueinander stehen: Auf der linken Seite steht die Kette der immer konkreter werdenden Entwicklungsartefakte, von Anforderungen bis zur Implementierung. Auf der rechten Seite befinden sich die die entsprechenden Elemente der Verifizierung und Validierung, die entsprechend die Elementen auf der linken Seite verknüpfen.

Das sieht recht einfach aus und klingt auch gar nicht so schwer. Es ist auch leicht umzusetzen, solange das Werkzeug solche Elemente und Verknüpfungen unterstützt, und solche Werkzeuge gibt es inzwischen viele. Problematisch wird es in dem Moment, wo Elemente in einem anderen Werkzeug bearbeitet werden müssen. Dann stellt sich die Frage des werkzeugübergreifenden Arbeitens. Was nun?

Im Folgenden geht es nun darum wie man das Problem werkzeugübergreifende Traceability angehen kann.

Traceability muss genutzt werden

Viele Werkzeuge des Systems Engineering sind in der Lage, Elemente miteinander zu verknüpfen. Im Anforderungsmanagement ermöglicht beispielsweise ein DOORS, Ein „Modul“ mit Nutzeranforderungen zu erstellen, um dann einzelne Nutzeranforderungen mit Systemanforderungen zu verknüpfen, die in einem anderen Modul abgelegt wurden. DOORS bietet des Weiteren die Möglichkeit, diese Verknüpfung zu analysieren: Gibt es für jede Nutzeranforderung mindestens eine Systemanforderung? Welche Systemanforderungen sind betroffen, wenn sich eine Nutzeranforderung ändert?

Modellierung und MBSE wird auch im Bereich der Implementierung benutzt: Da gibt es CAD-Systeme wie OnShape, Spezialwerkzeuge für elektrische Schaltungen, und heutzutage natürlich überall Quellcode von Software. Aber mir ist kein Werkzeug bekannt, welches sowohl mit Anforderungen, als auch implementierungsnahen Modellen umgehen kann. Und dann gibt es einen Bruch in der Werkzeugkette. Und dies ist ein Beispiel mit nur zwei Modellen. Wenn man an alle Prozesse im Systems Engineering denkt, dann haben wir es schnell mit dutzenden von Modellen zu tun.

Die Wahrheit der Modellintegration: Es gibt keine Patentlösung

Um es vorweg zu nehmen: Es gibt keine Patentlösung. Es gibt verschiedene mehr oder weniger aufwändige Ansätze, mit denen dieses Thema in den Griff gebracht werden kann. Aber keiner der Ansätze ist ohne Schwächen.

1. Händische Pflege

Der Übergang von einem Werkzeug zum anderen kann selbst bei größeren Entwicklungen von Hand betrieben werden. So wurde übrigens auch in der Anfangszeit des Systems Engineerings gearbeitet, anders ging es damals gar nicht. Wichtig dabei ist, einen guten Prozess zu haben, damit sich beim händischen Abgleich keine Fehler einschleichen. Dieser Abgleich kann auch teilautomatisiert werden, zum Beispiel durch den Export und Import von Daten über primitive Formate wie CSV.

Die Modellintegration über händische Pflege erfordert gute Prozesse

Bei einer händischen Pflege ist es empfehlenswert, sich Gedanken zu machen, welche Daten wirklich ausgetauscht werden müssen, und diese zu optimieren. Beispiele sind:

• Im Quellcode können IDs in Kommentaren hinterlegt werden
• Aus einer Systembeschreibung kann eine Spezifikation als Dokument generiert werden
• Ergebnisse aus einem Testlauf können von Hand eingepflegt werden.

2. Individuelle Integrationen

Moderne Werkzeuge bieten heutzutage in der Regeln Schnittstellen für die automatisierte Integration an (Aplication Programming Interfaces, oder APIs). Bei der Auswahl eines neuen Werkzeuges sollte unbedingt darauf geachtet werden, dass eine API vorhanden ist! Ältere Werkzeuge, wie das bereits erwähnte DOORS, tun sich dabei oft schwer, während moderne Werkzeuge, wie Jama, auf Integration ausgelegt sind.

Eine API erfordert aktive Gestaltung. Zuerst sollten Sie die Architektur festlegen: Soll ein zentrales „Master-Werkzeug“ entstehen, in dem alle Verknüpfungen zusammenlaufen? Viele nutzen dafür ein Anforderungsmanagement-Tool. Für andere Artefakte, etwa Testläufe, legen sie dann Dummy-Elemente an. Alternativ können Sie eine Punkt-zu-Punkt-Integration umsetzen, die nur bei Bedarf Verknüpfungen herstellt.

Dabei sind auch dateibasierte Integrationen möglich. Da scheint in vielen Bereichen das CSV-Format immer noch das Arbeitspferd zu sein, aber immer setzen Teams auch Standardformate ein, wenn es sie denn gibt (bspw. ReqIF für Anforderungen).

Von einer bidirektionalen Integration ist abzusehen – diese sind sehr fehleranfällig

Auch wichtig: Ist die Integration Unidirektional oder Bidirektional? Wenn es nicht unbedingt erforderlich ist, sind Unidirektionale Integrationen vorzuziehen. Es darf also nur an einem Ende bearbeitet werden, während am anderen Ende die Daten schreibgeschützt zur Verfügung stehen, aber nicht verändert werden können.

3. Service-Modell

Das Service-Modell ist mit der individuellen Integration vergleichbar, mit einem Unterschied: Die Werkzeuge bedienen sich gegenseitig „bei Bedarf“ bezüglich der Daten, die diese brauchen. Das wird in der Regel mit Webdiensten realisiert, also Webseiten für Maschinen.

Daten können generisch angeboten werden, was eine entsprechende Anpassung erfordert. Aber langsam fäng sich OSLC an, für diesen Zweck zu etablieren. Bei Open Services for Lifecycle Collaboration handelt es sich um eine offene Technologie, bei der standardisierte Spezifikationen für bestimmte Datentypen eingesetzt werden. Es gibt zum Beispiel eine Spezifikation für Anforderungen. Ein Anforderungswerkzeug kann dann Anforderungen per OSLC anbieten, während ein anderes Werkzeuge diese per OSLC abfragen kann.

4. Selbst bauen

Heutzutage würde ich es mir gut überlegen, eine integrierte Werkzeugkette selbst zu entwickeln. Allerdings gibt es inzwischen viele Firmen (meistens Konzerne), die sich strategisch für diesen Weg entschieden haben. Natürlich sollte man nicht vom Nullpunkt beginnen, sondern auf einer soliden Plattform aufsetzen. Dabei versucht Eclipse seit einigen Jahren, sich hier zu etablieren. Firmen wie Airbus, Thales, Bosch oder Ericsson setzen dabei insbesondere auf den Bereich Systemmodellierung.

Eclipse macht insofern Sinn, da es viele Elemente bereits gibt, wie RMF für Anforderungsmanagement oder Papyrus für UML/SysML-Modellierung. Eclipse bietet eine weitere Technologie, das Eclipse Modeling Framework (EMF), welches die Integration von Eclpse-basierten Werkzeugen drastisch vereinfacht.

5. Externe Traceability

Es gibt mehrere Werkzeuge am Markt, die nur für die Traceability zuständig sind. Diese Werkzeuge besitzen meist Adapter für verschiedene Systeme. Sie sammeln alle Verlinkungen aus den Quellen und führen sie in einem zentralen Tool zusammen. Dort können Sie die Daten analysieren und oft auch bearbeiten. Das Tool berücksichtigt dabei, dass manche Systeme bereits eine interne Traceability bieten, wie zum Beispiel DOORS. Auch solche im Werkzeug erstellten Traces werden dann dargestellt. Ein Oldtimer dieser Gattung ist Reqtify. Ein Modernes Beispiel für eine externe Traceability ist Smart Facts.

6. All-in-One Lösung

Es gibt Anbieter, die eine Komplettlösung versprechen. Damit soll man fast alle SE-Aktivitäten abdecken können. Beispiele sind Siemens (Teamcenter) und Esterel (Scade). Hier ist jedoch Vorsicht geboten.

Erstens: „Alles“ ist ein dehnbarer Begriff. Früher oder später müssen Sie trotzdem integrieren. Zweitens gilt das bekannte Problem vieler Multifunktionsgeräte: Es funktioniert zwar vieles, aber oft nicht besonders gut. Drittens: Sie machen sich stark abhängig vom Anbieter. Bei anderen Ansätzen bleibt diese Abhängigkeit wenigstens etwas geringer. Das ist vielleicht unkritisch in einer schnelllebigen Entwicklung. Wenn Sie jedoch ein langlebiges oder sicherheitskritisches System bauen, sollten Sie genau prüfen, ob Sie sich so eng an einen einzigen Anbieter binden wollen.

Fazit

Es gibt viele Wege, die Artifakte der Systementwicklung zu integrieren. Leider gibt es keine klare Empfehlung: Die Werkzeuge verschiedener Industrien sind einfach zu vielfältig, die Anforderungen zu unterschiedlich.

Meine Empfehlung ist es, zunächst das Gesamtbild nicht zu verlieren, also eine klare Architektur zu verfolgen. Weiterhin ist auf gute Prozesse zu achten, bevor in eine Integration (egal welcher Art) investiert wird. Wenn sich herausstellt, dass ein händischer Prozess oft ausgeführt wird, hat man einen guten Kandidaten für eine erste Integration.