Quo vadis SysML

Dieser Artikel stammt aus unserem Blog, der nicht mehr betreut wird. Für Neuigkeiten zu oose und interessante Inhalte zu unseren Themen, folgt uns gerne auf LinkedIn.

Die INCOSE sagt:

„Model-Based Systems Engineering will become the norm for systems engineering“.

Damit etwas zur Norm wird, muss es in der Regel standardisiert sein und über eine breite Akzeptanz verfügen. Die von der Object Management Group (OMG™) standardisierte Systems Modeling Language (SysML) ist aktuell die Sprache mit dem größten Potenzial komplexe Systeme disziplinübergreifend zu beschreiben. Standardisiert ist die SysML seit mittlerweile 10 Jahren. Aber wie sieht es mit der breiten Akzeptanz aus?

Die kann nur überwältigend sein, denn: SysML verbessert die Kommunikation im Unternehmen. SysML beschreibt Systeme ganzheitlich. Mit SysML kann man Systeme simulieren. Aus SysML Modellen werden automatisiert Dokumente erzeugt. SysML integriert die verschiedenen Engineering Disziplinen. Das Systemmodell dient als zentrale Quelle der Wahrheit. Soviel zu den gängigsten Marketing-Phrasen, Vorurteilen und anderen unrelativierten Sichtweisen in Bezug auf Model-Based Systems Engineering (MBSE).

Warum wird SysML dann noch nicht großflächig in der Entwicklung von multidisziplinären Systemen eingesetzt? Ist die Industrie zu träge? Mangelt es an der Qualifikation der Anwender? Fehlt es der SysML an Praxisnähe? Sind die Tools nicht smart genug? Wie sieht es mit deren Integration in den Gesamtprozess aus?

So schwierig es ist den Nutzen von MBSE vorherzusagen, so sicher sind sich mittlerweile viele Unternehmen, dass sie von interdisziplinären Systemmodellen profitieren werden. Aber wovon genau? Welche Ziele versprechen schnellen oder großen Nutzen? Und wie kommt man dahin? Die Antworten darauf fallen ja nach Anwendungsdomäne sicher unterschiedlich aus. Schauen wir uns die gefühlten Top 6 aus optimistischen Blickwinkeln an.

Zum gesunden Optimismus gehören motivierende Ziele wie bessere Produkte, Wettbewerbsvorteile oder die Rückkehr von Investitionen. Wir wollen nicht modellieren weil es gerade modern ist. Wir wollen Modelle weil sie uns nutzen.

1. MBSE verbessert die Kommunikation zwischen den technischen (z.B. Hardware, Software, Mechatronik), unterstützenden (z.B. Konfigurations- oder Risikomanagement) und übergeordneten (z.B. Qualitätsmanagement, Vertragsprozesse) Disziplinen und reduziert das Potenzial für Missverständnisse.
2. Die Möglichkeit Systemdetails einfach aber präzise zu definieren steigert die Aussagekraft der Systembeschreibung und hilft Widersprüche zu entdecken.
3. Die Nutzung der Traceability-Features hilft Lücken in der Systembeschreibung zu vermeiden.
4. Im Rahmen des Änderungsmanagements unterstützt die Auswertung von Traceability-Features die Analyse von Auswirkungen.
5. Die Nutzung von Beziehungen zwischen textuellen Anforderungen und Design steigern deren Qualität.
6. Die Trennung zwischen Modell und Sicht steigert die Konsistenz der Systembeschreibung.

 

Das klingt doch schon mal alles so als hätte man das auch gern. Leider ist es mit MBSE so wie mit den meisten schönen Dingen im Leben. Das Unternehmen als Ganzes muss sich ordentlich ins Zeug legen. Man muss Widerstände überwinden und Rückschläge einstecken. Nur so meistert man die  größten Herausforderungen.

1. Die Einführung von MBSE erfordert das Erlernen einer neuen Sprache, teils neuer Methoden und Tools. Eine solche Sprachbarriere kennt jeder aus dem Urlaub. Es ist anstrengend, beschneidet vorübergehend die Ausdruckskraft des Einzelnen und ist manchmal frustrierend.
2. MBSE entfaltet seinen vollen Wert erst mit einer guten Integration in die Kernprozesse des Engineerings. Dazu gehören Disziplinen wie Konfigurations-, Änderungs- und Anforderungsmanagement mit ihren Abteilungen, Mitarbeitern, Methoden und Kulturen.
3. Historisch gewachsene Toolketten, etablierte Prozesse und die mangelhafte Interoperabilität machen es aufwändig gute Lösungen zu schaffen und bergen die Gefahr sich von einem Toolanbieter abhängig zu machen.
4. Der Nutzen von MBSE lässt sich nicht seriös prognostizieren, ist nur schwer zu messen und wird daher teils mit viel Skepsis betrachtet. So ging es der Textverarbeitung und dem agilen Projektmanagement auch einmal.
5. Modellbasiert entwickeln bedeutet in der Regel, früh im Projekt viel in „Virtuelles“ zu investieren. Es erfordert die Kollaboration aller Betroffenen und Vertrauen in die Methode diese Investition in die Zukunft zu machen.
6. Die Einführung neuer Methoden und Arbeitsweisen geht immer mit einem mehr oder weniger starken Kulturwandel einher. Es gibt Befürworter, Unentschlossene aber auch vehemente Gegner eines solchen Entwicklungsschritts. Alle Beteiligten von Anfang an ins Boot zu holen wird wahrscheinlich nicht gelingen. Rückendeckung von oben hilft.

 

Um erfolgreich zu sein, muss man nicht nur viele Dinge tun, manches muss man einfach lassen.  Die Erde wurde in 6 Tage erschaffen, leider war das Ergebnis eine Scheibe. Damit die Einführung von MBSE aus allen Perspektiven rund läuft vermeiden Sie bitte folgende Bad Practices.

1. Die Anschaffung eines Tools bevor man sich mit Methode und Sprache vertraut gemacht hat.
2. Die Ziele und Erwartungen an MBSE werden nicht klar formuliert und verfolgt.
3. MBSE wird als reines Engineering-Werkzeug betrachtet. Dadurch bleiben große Potenziale zur Verbesserung der Kommunikation ungenutzt.
4. Die Modellierungsprotagonisten gehen früh ins Detail. Damit werden die Modelle extern des eigenen Organisationsperimeters nicht gut verstanden, akzeptiert und verlieren ihren Wert.
5. Mangelhafte Integration von MBSE in bestehende Prozesse und Tool wie Konfigurations-, Änderungs- und Anforderungsmanagement
6. Alle Potenziale von MBSE auf einmal heben wollen. Mit der Erwartungshaltung, von Beginn an vertragssicher zu Spezifizieren und Modelle zu simulieren liegt die Latte für den Erfolg sehr hoch.

 

Da ich grad so schön optimistisch bin, sei es erlaubt ein wenig zu träumen. Wie sollte die heile modellbasierte Welt aussehen? Bevor ich jetzt wegen Visionen zum Arzt geschickt werde, nenne ich lieber meine größten Wünsche.

1. Ein zentrales, disziplinübergreifendes Modell unter voller Konfigurationskontrolle.
2. Nahtlose Integration des MBSE-Authoring-Tools auf Systemebene mit den disziplinspezifischen Tools. Workarounds wie die manuelle Pflege von Links sollten überflüssig werden. Die Integration von domänenspezifischen Sprachen in das Gesamtmodell soll für den Nutzer transparent sein.
3. Nahtlose Integration von Tools zum Konfigurations-, Änderungs-, Anforderungs- und Qualitätsmanagement. Workarounds wie die Erklärung eines Repositories zum „Master“ sollten überflüssig werden.
4. Die Beschreibung von Interfaces, Übertragungswegen, Objekt-, Informations- und Energieflüssen sollte standardisiert und einfach in Modelle zu integrieren sein.
5. Für fertige Zukaufteile sollte ein Modell beschrieben in einer Standardsprache so selbstverständlich sein wie ein Datenblatt.
6. Proprietäre Abweichungen vom Sprachstandard sind Vergangenheit und Modelle lassen sich verlustfrei zwischen Tools und Disziplinen austauschen.

 

Diese Sammlung von Thesen ist das Ergebnis einer unwissenschaftlichen, subjektiven, bauchgesteuerten Einordnung von Eindrücken. Mein Ziel ist eine Diskussion darüber, welche Maßnahmen MBSE auf Basis von SysML in der eigenen Organisation zum Erfolg führen und welche das Gegenteil bewirken. Ich freue mich über weitere Thesen, Phrasen und Einschätzungen im Kommentar.