7 Tipps für pragmatisches Systems Engineering

Gestern, am 17.6.2020, hielt ich im Rahmen der Webinarserie der GfSE einen Vortrag mit dem Titel „Pragmatisches Systems Engineering durch Modellierung“. Den Pragmatismus habe ich in der Form von 7 Tipps festgehalten, die hier zusammengefasst sind für diejenigen, die das Webinar verpasst haben.

Die Videoaufzeichnung und weiterführende Links habe ich auf einer eigenen Seite aufgenommen.

1. Das Beste von allen Ansätzen aussuchen

Über die vergangenen Jahrzehnte haben wir verschiedene Ansätze gefunden, um das Systems Engineering effizienter zu gestalten. Angefangen hat es in den 90ern mit Element-basiertem Anforderungsmanagement (statt wie bisher Dokumente zu benutzen. Anfang der 2000er kam dann Agilität als neuer Ansatz und Ende der 2000er dann MBSE.

Diese drei Ansätze schließen sich nicht gegenseitig aus, im Gegenteil. Daher ist es richtig und wichtig, die besten Ideen von den drei Ansätzen zu verwenden und diese auch zu kombinieren.

2. Richtung („Kompass“) + kleine Schritte

Das große Ziel von MBSE ist ein zentrales Modell, welches alle Aspekte der Entwicklung darstellt und von allen Stakeholdern benutzt wird. Doch wenige Teams haben die Reife dort in einem einzigen Schritt hinzukommen, egal, wo sie sich aktuell befinden. Daher ist es wichtig, ein klares Ziel vor Augen zu haben, den Kompass. Dieses Ziel muss unbedingt mit den Geschäftszielen des Unternehmens abgeglichen sein, sonst wird es schwer, die benötigten Ressourcen zu bekommen. Das SYSMOD Intensitymodel zeigt schön, wie man schrittweise MBSE ausbauen kann.

3. Kein Selbstzweck / Mehrwert für alle Stakeholder

Gerade wenn ein paar Mitarbeiter viel Begeisterung zeigen, kann die Modellierung leider schnell nach hinten losgehen. Solche Menschen überschätzen leicht die Fähigkeiten und das Interesse ihrer Kollegen. Daher ist es wichtig, dass alle Stakeholder erkennen, was ihnen Modellierung für die tägliche Arbeit bringt. Wenn der Mehrwert für jeden einzelnen klar ist, dann ist das Team auch motiviert.

4. Reizen Sie bestehende ER-Modelle voll aus

Ein Entity-Relationship-Modell ist eine einfache Datenstruktur, bei denen es Elementtypen und Verbindungen zwischen diesen gibt. Ein typisches Anforderungsmanagementwerkzeug benutzt ein ER-Modell, welches bspw. das Verknüpfen von User Needs und System Requirements ermöglicht. Das ist nichts neues und wird seit 30 Jahren in der Entwicklung eingesetzt. Weiterhin arbeitet jede Datenbank mit Entitäten (Tabellen) und Relationen, wodurch jedes datenbankbasiertes System ein ER-Modell nutzt.

Solche Systeme, insbesondere Anforderungsmanagementwerkzeuge, werden meiner Erfahrung nach oft nicht voll ausgenutzt. Selbst die offensichtlichsten Dinge, wie die Pflege einer Traceability, werden manchmal nur nachträglich und für die Compliance durchgeführt. Was man mit einer Traceability so machen kann habe ich hier zusammengefasst. Ob systematische Wiederverwendung oder ein Dashboard fürs Management, ER-Modelle haben extrem viele Anwendungsmöglichkeiten die nur darauf warten eingesetzt zu werden.

5. Nur den Teil einer Notation nutzen, der benötigt wird

Gerade wenn ein Team beginnt, eine formale Notation wie SysML zu benutzen, besteht die Versuchung, alles auszuprobieren. Aber gerade am Anfang ist es hilfreich, nur einen kleinen Teil einzusetzen. Welcher Teil das ist sollte vom geplanten Einsatz der Modellierung abhängen. Es sollte also zunächst ein Ziel definiert werden, zum Beispiel Redundanzen in der Spezifikation zu reduzieren. Basierend darauf kann der Teil der Sprache ausgewählt werden, der dieses Ziel unterstützt.

Wie das konkret aussehen kann habe ich in dieser Fallstudie festgehalten, wo ein IT-System mit UML dokumentiert wurde.

6. Stakeholder schulen, Lesen & Schreiben unterscheiden

Es sollte klar sein, dass neue Ansätze auch Schulung benötigen. Manchmal wird jedoch vergessen, dass nicht alle Stakeholder die selbe Schulung benötigen. Insbesondere ist es wesentlich aufwändiger, jemanden das Modellieren zu vermitteln als das Lesen von Modellen. In der Praxis jedoch müssen die meisten Stakeholder nur die Modelle verstehen, aber nicht selbst erstellen. Für diese reicht eine kurze, prägnante Schulung aus. Diese sollte aber auf jeden Fall durchgeführt werden, denn damit kann die Akzeptanz eines neuen Ansatzes drastisch erhöht werden.

7. Ein bestehendes Vorgehen/Methode nutzen und anpassen

Und zuletzt: Modellierung, und insbesondere MBSE, erfordern ein systematisches Vorgehen und Reife bezüglich Methodik im Team. Wenn nun bei der Einführung von MBSE der Bedarf eines entsprechenden Vorgehens besteht, sollten wir unbedingt der Versuchung widerstehen, etwas selbst zu entwickeln. Es gibt eine große Anzahl von fertigen Vorgehensmodellen, und diese können leicht angepasst werden. Ein leichtgewichtiges ist ICONIX, am anderen Ende des Spektrums die FAS-Methode.

Fazit

Der wichtigste Punkt ist: Im Unternehmen sind wir Praktiker, nicht Akademiker. Daher ist Pragmatismus angesagt. Was wir auch machen, wir müssen verstehen warum. Selbstzweck ist hier eine der größten Gefahren. Wenn wir das beherzigen, dann können wir mit wenig Aufwand viel bewegen.

Photo by Aron Visuals on Unsplash