Sieben Fragen für die richtige Werkzeugwahl für Systems Engineering

Um es gleich vorwegzunehmen: Die Wahl eines Werkzeugs für System Engineering sollte nicht an erster Stelle kommen. Werkzeuge sollen unterstützen, und für die richtige Werkzeugwahl müssen wir erst einmal entscheiden, bei welchen Aktivitäten das Werkzeug unterstützen soll.

Das V-Modell ist eine gute „Landkarte“ um zu diskutieren, in welchen Bereichen der Entwicklung Werkzeuge eingesetzt werden sollen. Zur Erinnerung: Beim V-Modell befinden sich „links oben“ im V die Anforderungen, die über mehrere Schritte (Architektur, Design…) zur Implementierung an der „unteren Spitze“ des V führen. Auf dem rechten Ast des V befinden sich die V&V-Elemente beispielsweise Tests, die die Elemente im linken Ast auf den selben Ebenen prüfen.

Ein Werkzeug allein ist selten die Lösung. Aber das falsche Werkzeug im Systems Engineering kann zum Scheitern führen

Die folgenden Fragen sollen bei der Entscheidungsfindung helfen:

1. Um was für ein Projekt handelt es sich?

Mögliche Antworten auf diese Frage sind:

• Akademisches Projekt oder „Spielprojekt“
• Komplette Neuentwicklung ohne bestehende Werkzeugumgebung
• Komplette Neuentwicklung mit bestehender Werkzeugumgebung
• Weiterentwicklung (offenbar mit bestehender Werkzeugumgebung)

Wenn es bereits eine Werkzeugumgebung gibt, dann sollte gut überlegt werden, ob hier etwas geändert werden sollte. Insbesondere der Wechsel eines Werkzeugs kann signifikante Kosten und Probleme erzeugen, selbst wenn es theoretisch kein Problem sein sollte. Beispiele hierfür wäre bspw. der Wechsel des UML-Werkzeugs. Auch wenn es einen Standard für UML-Modelle gibt (XMI), heißt dies noch lange nicht, dass sich UML-Modelle problemlos von einem Werkzeug ins andere überführen lassen.

Für akademische Projekte oder Lernprojekte sollte klar das Lernziel herausgearbeitet werden. Hier kann es sinnvoll sein, Werkzeuge einzusetzen, die quelloffen sind (oder zumindest eine mächtige Skriptsprache unterstützen), damit die für das Lernziel relevanten Aspekte ausgebaut werden können.

2. Was ist der Scope der Werkzeugunterstüztung?

Das V-Modell gibt einen guten Überblick über die Bereiche, die von einem Werkzeug abgedeckt werden könnten. Diese reichen von Anforderungen über Design bis zur Hardware und Softwarecode. Zunächst muss entschieden werden, für welche dieser Bereiche ein Werkzeug ausgewählt werden soll. Es ist durchaus möglich, dass für manche Bereiche die Entscheidung bereits gefallen ist (bspw. die Wahl der Programmiersprache und des Compilers).

Weiterhin gibt es zwar integrierte Werkzeuge, die viele Bereiche abdecken, aber das ist keine grundsätzliche Anforderung. Im Gegenteil: Mit einem integrierten Werkzeug kann man sich schnell in die Abhängigkeit eines einzigen Herstellers begeben („Vendor Lock-In“), was zu vielen anderen Problemen führen kann. Zu Beispielen für integrierte Werkzeuge zählen Scade Systems oder IBM Jazz (wobei mit Jazz auch über OSLC auch andere Werkzeuge integriert werden können).

Der Vorteil eines integrierten Werkzeugs ist allerdings, das die Artefakte der Entwicklung eng miteinander verzahnt werden können. Dadurch ergibt sich eine mächtige Nachverfolgbarkeit (Traceability). Allerdings gib es auch mächtige externe Werkzeuge für die Traceability, die die unterschiedlichsten Tools zusammenbringen, wie Reqtify.

3. Wie sieht die Werkzeug-Architektur aus?

Auch wenn nur ein kleiner Bereich der Systementwicklung mit Werkzeugen abgedeckt werden soll, so müssen diese Werkzeuge in den Gesamtkontext der Systementwicklung passen. Daher muss eine Werkzeugarchitektur ausgewählt werden. Das ist nicht aufwendig und die Architekturbeschreibung sollte sich in wenigen Sätzen zusammenfassen lassen. Mögliche Architekturen könnten sein:

• Dateibasiertes Arbeiten mit händisch vergebenen IDs
• Verknüpfen aller Werkzeuge über OSLC
• Arbeiten mit einer integrierten Umgebung

Dies ist natürlich nur eine beispielhafte Liste, es gibt noch viele andere Architekturen, die alle die Werkzeugwahl beeinflussen.

4. Gibt es wichtige Anforderungen, die berücksichtigt werden müssen?

Wie bei vielem im Systems Engineering sind Anforderungen wichtig. Hier müssen keine großen Geschütze aufgefahren werden: Für ein kleines Projekt können die Anforderungen sicher auf einer halben Seite festgehalten werden.

Zu berücksichtigen sind Vorschriften, insbesondere bei sicherheitskritischen Entwicklungen. Aber auch die Nutzer müssen einbezogen werden. Wichtig ist, hier pragmatisch zu bleiben und nicht über Bord zu gehen.

5. Wie hoch muss der Automatisierungsgrad sein?

Werkzeuge sind mächtig, weil sie uns Arbeit abnehmen, also unter anderem auch Automatisierung zulassen. Dabei sollten aber zwei Dinge unbedingt beachtet werden:

• Die Automatisierung muss verstanden werden. Eine falsch konfigurierte (oder falsch verstandene) Automatisierung kann unter Umständen mehr schaden als nutzen. Ein klassisches Beispiel ist Codegenerierung, also die Erstellung von Softwarecode aus Modellen heraus. Das funktioniert, ist aber aufwändig. Und wenn diese nicht richtig verstanden ist, dann kann unter Umständen toter Code in der Software zurückbleiben, der fehlerhaftes Verhalten verursacht.
• Händische Prozesse dürfen Teil der Werkzeugkette sein. Wenn es keine saubere Schnittstelle zwischen zwei Werkzeugen gibt, dann muss vielleicht händisch gearbeitet werden. Das wird manchmal als negativ angesehen, kann aber mit sauber beschriebenen Prozessen leicht in den Griff bekommen werden. Auch sollte beachtet werden, dass die händischen Prozesse nicht unbedingt von einer Fachkraft durchgeführt werden müssen. Ein Beispiel für leistungsfähige händische Unterstützung sind Checklisten.

6. Gibt es ein Budget für Support und Anpassungen?

Diese Frage wird oft vergessen, ist jedoch sehr wichtig: Das beste Werkzeug hilft nichts, wenn die Nutzer nicht damit umgehen können. Die folgende Aussage mag kontrovers erscheinen: Aber Word kann geeigneter für die Anforderungen sein als Rational DOORS, wenn die Nutzer noch nie mit DOORS gearbeitet haben und es kein Budget für Schulung und Support gibt.

Auch Anpassung ist ein wichtiges Thema. Alle ernstzunehmende Werkzeuge im Systems Engineering haben Anpassungsmöglichkeiten, von Dokumenten-Templates bis zu Skript-Engines. Wenn für die Anpassung kein Budget vorhanden ist, dann kann ein großer Mehrwert der Werkzeuge einfach verpuffen.

7. Fühlt es sich richtig an?

Und zuletzt: selbst wenn rational ein oder mehrere Werkzeuge gefunden wurden, sollten alle relevanten Stakeholder gefragt werden, ob ihnen die Werkzeugwahl richtig erscheint, also wirklich aus dem Bauch heraus. Wenn das nicht der Fall ist, dann sollte zumindest versucht werden, den Grund für dieses Unwohlgefühl zu verstehen. Natürlich kann die Entscheidung dann trotzdem für das Werkzeug gefällt werden, aber es sollte verstanden werden, warum das so ist.