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.

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.

Dieser Artikel erschien zuerst bei se-trends.de.

  • pica

    Hallo,

    (english version below)

    seit einiger Zeit beobachte ich dieses Forum (oder eher den Blog). Da ich den aktuellen Artikel kommentieren möchte, verlasse ich meinen Stealth-Modus.

    Ich möche mich jedoch kurz vorstellen bevor ich meinen ersten Kommentar schreibe.

    Als Enterprise- / Solution-Architekt mit 20 Jahren Berufserfahrung habe ich IT-Projekte von der Idee, über Konzeption, Umsetzung und Tests bis zur Abnahme geleitet. Hierbei hat sich mein Fokus von der Entwicklung hin zur kombinierten fachlich-architektonischen und Prozess Beratung (Enterprise- und Solution-Architektur) entwickelt.

    Ich nutze Architektur-Frameworks (TOGAF, NAF) und Vorgehens­modelle (SCRUM, V-Modell) implizit zur Strukturierung von Arbeits­schritten.

    Meinen ersten Kontakt mit UML hatte ich im Jahr 1997. Dann folgten EPK, BPMN, SysML und Archimate als weitere Notationen. Entsprechen bin ich eher ein Modellierungsgeneralist als ein System Engineering Spezialist.

    Wie zuvor beschrieben war mein erster Kontakt mit UML im Jahr 1997 als ich augewählt wurde ein SE Werkzeug auszuwählen. Und schon sind wir beim Thema.

    Mein Name ist Carsten Pitz. Und für Themen außerhalb dem Bereich des Forums könne Sie mich gerne unter carsten.pitz@gmx.de kontaktieren.

    Ach ja, ich lebe in Brühl nahe Köln, oder auch nahe Düsseldorf, dem Heimatsitz des Forumleiters.

    Hello,

    I followed this forum (or is it a blog?) completely passively for a quite a while now. Simply because I want to comment on this article I leave my stealth mode.

    Before posting my first comment on this forum I will introduce myself briefly.

    As software architect with some 20 years experience I know and have headed all stages of software development projects. I started and have a strong background as developer, but my main interest is architecture.

    I implicitly use architecture-frameworks (TOGAF, NAF) and process models (SCRUM, V-Model) structure work.

    Back in 1997 I started modelling with UML, later EPC, BPMN, SysML and Archimate completed the zoo. As a result I am a modelling generalist rather than a system engineering specialist.

    My first contact with UML was as mentioned before in 1997 when I was choosen to choose a SE tool. So here we are 😉

    My name is Carsten Pitz and please feel free to contact me via carsten.pitz@gmx.de if you have topics out of scope of this forum.

    Well, I live in Brühl which is next to Cologne and also next to Düsseldorf (the site owners residence) , even by european standards.

    Greetings,
    Carsten

    • Hallo Carsten,

      Danke für die Vorstellung!

      Gruß,

      – Michael

  • pica

    Danke, der Artikel spricht mir aus der Seele.

    Dennoch habe ich einige Anmerkungen:

    zu 1.)
    Ein SE Werkzeug nur für ein Projekt einzuführen, ist nur in Sonderfällen sinnvoll. Falls ein SE Werkzeug in einer Organisation sinnvoll ist, dann in der Regel nicht nur für ein Projekt. Eine Ausnahme ist, wenn ein Projekt ein Pilotprojekt darstellt mit dem Ziel ein SE Werkzeug zu testen.

    zu 2.)
    Der Scope (ich nenne es im Folgenden die Ziele) sollten zeitlich gestaffelt sein. Was sind „quick wins“? Was soll mittelfristig erreicht werden? Was sind strategische Ziele? Entlang dieser Roadmap kann dann Einführung und Ausbildung geplant werden.

    Ohne diese Orientierungshilfe führt eine Werkzeugeinführung zum Teil zu kreativer Verwendung des Werkzeugs. Ein Beispiel aus einem Projekt zu dem ich als Berater tätig war. In diesem Projekt wurde DOORS ausschließlich als Ablage für Word Dokumenten verwendet. Der QS Verantwortliche meckerte, weil DOORS leer war, jedoch genutzt werden sollte. Also wurde schnell mal geGoogelt was DOORS eigentlich macht und kann. Dabei ist einer darauf gestoßen, dass Word Dokumente in DOORS abgelegt werden können. Der QS Verantwortliche war zufrieden, hat sein Häckchen bei „DOORS verwendet“ gemacht und …

    zu 5.)
    nicht ganz zum Thema passend.
    Besser vorher prüfen, ob die vom Werkzeughersteller versprochenen Eigenschaften auch erfüllt sind. Bei einem beliebten, kommerziellen UML/SysML/etc-Modellierungswerkzeug ist mir, als ich es 2008 das erste mal nutzte aufgefallen, dass nach einfachen Refactoring Operationen das Modell nicht mehr integer war. Ein Blick in das — äußerst dreckige — XMI offenbarte, referenzierte Elemente werden teilweise nicht als Element referenziert sondern über den ursprünglich, vergebene Namen referenziert. Wird das referenzierte Element umbenannt oder gelöscht, bleiben die ursprünglichen „Referenzen“ bestehen. Den Fehler hatte ich 2008 umgehend an den Hersteller gemeldet. Bei der in 2015 aktuellen Version konnte ich diesen Fehler noch nachvollziehen.

    zu 7.)
    ja

    • Hallo Carsten,

      Danke für die Kommentare, die den Artikel gut ergänzen. Ich habe auch schon Projekte gesehen, wo DOORS „missbraucht“ wurde. Schon allein aus kostengründen ist das nicht sonderlich weise.

      Was 5) betrifft: Ich habe schon das Gefühl, dass Werkzeuge oft eingeführt werden, um die Effizienz zu steigern, was durch Automatisierung realisiert wird (wobei dabei nicht unbedingt die Effektivität gesteigert wird). Aber letzten Endes ist das auch wieder eine Frage der Ziele. Über das Thema könnte man wohl auch einen ganzen Artikel schreiben.

      Gruß aus Düsseldorf!

      – Michael