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.

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 wird auch im Bereich der Implementierung benutzt: Da gibt es CAD-Systeme wie AutoCAD, 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 Twittern

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 Twittern

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 allerdings, dass Hand angelegt wird. Dabei sollte zunächst eine Architektur definiert werden: Soll es bspw. ein „Master-Werkzeug“ für die Traceability definiert werden, in dem alle Verknüpfungen zusammenlaufen? Das wird oft mit Anforderungswerkzeugen gemacht, wobei dann für andere Artefakte (bspw. Testläufe) jeweils Dummy-Elemente angelegt werden. Oder soll nach Bedarf eine Punkt-zu-Punkt-Integration realisiert werden?

Integrationen können auch dateibasiert durchgeführt werden. Da scheint in vielen Bereichen das CSV-Format immer noch das Arbeitspferd zu sein, aber immer mehr werden auch Standardformate benutzt, wenn es sie denn gibt (bspw. ReqIF für Anforderungen).

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

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 haben typischerweise Adapter für die verschiedenen Werkzeuge, und ziehen die Verlinkungen von allen Quellen im Werkzeug zusammen, wo sie analysiert und teilweise auch bearbeitet werden können. Dabei wird natürlich berücksichtigt, dass manche Werkzeuge eine interne Traceability ermöglichen (wie das DOORS-Beispiel oben). 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 auch Anbieter, die einem eine Lösung versprechen, mit der alles gemacht werden kann – oder zumindest der größte Teil der SE-aktivitäten. Kandidaten in diesem Bereich sind Siemens (Teamcenter) und Esterel (Scade). Hier ist Vorsicht angeraten: Zum einen ist „alles“ ein relativer Begriff, und früher oder später muss dann doch integriert werden. Das zweite Problem ist das, was man mit den meisten Multifunktionsgeräten hat: Ja, es geht alles, aber manches nicht sonderlich gut. Und zuletzt: Man gibt sich in eine klare Abhängigkeit zum Anbieter, die bei den anderen Ansätzen zumindest etwas realtiviert werden. Das ist vielleicht nicht problematisch für eine schnellebige Entwicklung; wenn jedoch ein langlebiges, vieleicht sogar sicherheitskritisches System entwickelt werden soll, würde ich mir gut überlegen ob ich mich wirklich so eng mit einem einzigen Anbieter binden möchte.

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.