Suchen

Model Based Systems Engineering: So führen Sie MBSE erfolgreich ein

| Autor / Redakteur: Bernd Busam * / Sebastian Gerstl

Wenn es um die Einführung modellbasierten Systemdesigns geht, scheinen Unternehmen manchmal etwas blauäugig vorzugehen: Tool kaufen, Mitarbeiter schulen, fertig. So einfach ist die Sache nicht. Wer nicht bedacht an MBSE herangeht, beraubt die Systemmodellierung um einige ihrer stärksten Eigenschaften

Firmen zum Thema

Modell-basiertes Systems Engineering (MBSE) verspricht, komplexe Software-Architekturen nachvollziehbar und beherrschbar zu machen. Doch manche Unternehmen finden den Umstieg auf modellbasiertes Design schwierig. Eine klare Zielsetzung und gründliche Strukturen sind Schlüsselfunktionen für die erfolgreiche MBSE-Einführung.
Modell-basiertes Systems Engineering (MBSE) verspricht, komplexe Software-Architekturen nachvollziehbar und beherrschbar zu machen. Doch manche Unternehmen finden den Umstieg auf modellbasiertes Design schwierig. Eine klare Zielsetzung und gründliche Strukturen sind Schlüsselfunktionen für die erfolgreiche MBSE-Einführung.
(Bild: Clipdealer)

Im Gespräch mit Anwendern von Model Based Systems Engineering (MBSE) hört man oft dieselben Gründe, warum MBSE nicht so recht die Erwartungen erfüllt. Das läuft meist auf Dinge heraus wie „Anforderungen betrachten wir erstmal losgelöst vom Modell“. Oder: „wir wollen nur die statische Architektur beschreiben“. Oder: „das Tool ist eine Vorgabe, da wir einen Rahmenvertrag mit dem Hersteller haben“.

In diesen Momenten sollte man sich aber die folgenden Fragen stellen: Warum verzichtet man auf eine der mächtigsten Eigenschaften von MBSE, der Traceability von Anforderungen zur Architektur? Warum spart man alles, was Architektur begründet und komplex macht, ein? Das wäre, als gäbe man den Ingenieuren keinen Zimmermannshammer, weil sie schon einen Schmiedehammer haben.

Die falschen Ziele stehen dem Potenzial von MBSE im Weg

Fragt man nach den Gründen, fällt auf, dass die Erstellung von Systemmodellen häufig dazu eingesetzt wird einzelne Disziplinen der Systementwicklung zu ergänzen, zu formalisieren oder auch zu standardisieren. Das sind für sich genommen gute Ziele. Diese Ziele scheinen jedoch die Sicht für die Potenziale von MBSE zu verstellen. Die Komplexität von Produktentstehungsprozessen (PEP) wächst mit der Komplexität der zu entwickelnden Produkte. In vielen Brachen ist die Beherrschung des PEP von mindestens so großer Bedeutung wie die Beherrschung der zugrundeliegenden Technik.

Es scheint also ratsam den Prozessen, Methoden und Werkzeugen die gleiche Wertschätzung zukommen zulassen wie den Produkten, die damit entwickelt werden sollen. Es liegt also nahe, den PEP als ein komplexes System mit inhärentem verhalten zu sehen, also ein System, dass man am besten mit den Methoden des Systems Engineering entwickelt. Die Einführung von MBSE ist nichts anderes, als ein komplexes System zu entwickeln und zu betreiben. Wie geht man am besten vor?

Klare Formulierung der Ziele

Unabhängig davon, ob MBSE in einem überschaubaren Projekt oder in großem Maßstab in einer Organisation ausgerollt werden soll, ist es wichtig, Ziele klar zu definieren. In einem isolierten Projekt kann es ausreichend sein kurzfristige Ziele zu formulieren. Bei der Einführung von MBSE auf Unternehmensebene sollten langfristige Visionen entwickelt und auf mittel- und kurzfristige Ziele abgebildet werden. Die identifizierten Ziele sollten hinsichtlich Aufwand, Priorität und Synergie bewertet werden. Das sind wichtige Metriken, um die Integration von MBSE in den PEP bewerten und steuern zu können. Metriken helfen aber auch einzelne Modellierungsaspekte und deren Intensität zur planen. Ein zählbarer Nutzen ist möglicherweise erst spät im Projekt feststellbar. In einer von Skeptikern geprägten Umgebung können die definierten Metriken helfen die Investition in MBSE zu verteidigen.

Unabhängig davon, ob man beabsichtigt in einem Standalone-Werkzeug Systemanalyse und -design durchzuführen, oder das Modellierungstool in eine komplexe Werkzeugkette eingebunden werden soll, ist die Bestimmung des Systemkontextes der nächste Schritt. Der Systemkontext definiert die Anwender, angrenzende Werkzeuge und hilft dabei weitere Stakeholder zu identifizieren.

Anwendungsfälle

Es gibt viele Dinge, die man mit Modellen tun kann, die für sich einen Nutzen stiften. Alle relevanten Anwendungsfälle sollten erhoben und priorisiert werden. Bereits eine abstrakte Beschreibung des Anwendungsfälle mit groben Abläufen sowie wesentlichen Inputs und Outputs liefert Hinweise auf mögliche Synergien zwischen den Anwendungsfällen oder Informationen, die wertvoll für den PEP sind. Die Anwendungsfälle sind einer der wichtigsten Bezugspunkte für Architekturentscheidungen am MBSE-System.

Womit beginnen?

Der Wert von MBSE ist häufig nicht für alle betroffenen ersichtlich. Ein wichtiger Motor bei der Einführung von MBSE sind spürbare oder besser noch messbare Verbesserungen im PEP. Im besten Fall profitieren alle, die auf Modelle „einzahlen“. In der Praxis ist es aber so, dass einzelne Betroffene zunächst einmal eine negative Leistungsbilanz erwarten oder verspüren. Die oft nicht unbegründeten Vorbehalte von Betroffenen sollten bewusst adressiert und bestenfalls durch das modellbasierte Vorgehen berücksichtigt werden. Überzeugte Kritiker sind die besten Fürsprecher.

Dennoch, die beteiligten Akteure werden unterschiedlich von MBSE profitieren. Demgegenüber kann man nur mit einer positiven Gesamtbilanz argumentieren. Daher sollte man sich zu Beginn auf die Big Points konzentrieren.

Was weglassen?

Big Points zu machen geht häufig nur, wenn man bestimmte Aspekte zu Lasten zukünftiger Bedarfe abstrahiert oder weglässt. Solch grundsätzliche Entscheidungen stellen sich in Bezug auf die gesamte MBSE-Umgebung genauso wie auf einzelne Modelle oder Modellteile. Die Entscheidungen sind immer ein Abwägen von Flexibilität zur Realisierung künftiger Anforderungen gegenüber Aufwänden, die nicht kurzfristig belohnt werden. Gerade in einer frühen Phase der Einführung von MBSE sollte man sich vergegenwärtigen, dass dieses Vorhaben sich nicht vollständig planen lässt und damit per Definition explorativen Charakter hat. Auch, oder gerade, wenn die Vision ein umfassendes, bereichsübergreifendes und integriertes Modell anstrebt ist es manchmal besser, Lehren zu ziehen und Dinge zu verwerfen.

Um neue Aspekte mit Modellen betrachten zu können kann es nötig werden, diese umfassend zu überarbeiten. Das kann sehr aufwändig sein und die Akzeptanz von MBSE beschädigen. Eine gute Strategie beim Aufsetzen von Modellen ist, diese in geeignete Abstraktionsstufen zu gliedern und bestimmte Aspekte von Modellen zu verallgemeinern bzw. auf dieser Basis zu spezialisieren. Auf diese Weise können betroffene Bereiche eingeschränkt und der Änderungsaufwand minimiert werden.

Informationen bereitstellen

Wir leben in einer Zeit in der es sehr einfach ist, an Informationen zu gelangen. Trifft das auch auf ihre Organisation zu? Systemmodelle stellen einen großen Schatz an Informationen dar, der in der Regel weit über den Inhalt von Diagrammen hinaus geht. De facto sind diese Informationen auch ohne Diagramme vorhanden. Selbstverständlich sind Diagramme eine benutzerfreundliche Form der Darreichung von Informationen. Das gilt jedoch nur, wenn Diagramme entsprechend den Bedürfnissen ihrer Leser angefertigt werden. Ein Fachexperte verlangt einen anderen Detailgrad oder andere Aspekte als ein Benutzer. Grundsätzlich ist es immer sinnvoll die Komplexität von Diagrammen gering zu halten. Eine gute Heuristik dafür ist die 7 +- 2-Regel, die sich an den kognitiven Fähigkeiten des Menschen orientiert.

Viele Aspekte von System lassen sich am besten tabellarisch zeigen und bearbeiten. Beispiele hierfür sind Beziehungen zwischen Modellelementen oder die Attribuierung von Modellelementen. Tabellen bzw. die Abfragen auf Modellen, die Tabellen generieren, lassen sich einfach filtern und sind damit ein Mittel, um mit geringem Aufwand benutzerspezifische Sichten auf ein Modell zu generieren. Solche Abfragen ermöglichen Sichten auf die Modelldaten, die vom Ersteller des Modells nicht zwingend vorgesehen werden müssen. Ein Modell, dass Aspekte wie Anforderungen, Architektur und Tests umfasst, ermöglicht Einsichten, die sich bei klassischer Trennung dieser Disziplinen nur mit großem Aufwand erreichen lassen. Das bedeutet nicht zwingend, dass die genannten Disziplinen modellbasiert arbeiten müssen. Es ist durchaus möglich diese Informationen in ihren angestammten Biotopen zu belassen und über Integrationslösungen mit dem Modell zu verknüpfen.

Der Wert eines Modells steigt mit seinem Informationsgehalt. Das gilt aber nur, wenn der Zugriff auf diese Informationen dem Informationsgewinn angemessen ist. Kurz gesagt, einfache und benutzerfreundliche Modellabfragen steigern die Akzeptanz von MBSE und generieren Fürsprecher, die sich möglicherweise nicht als Nutzer von Modellen sehen.

Informationen sind jedoch nur von Wert, wenn sie aktuell und zuverlässig sind. Diagramme, die nur zur Befriedigung eines Meilensteins erstellt werden oder Abhängigkeitsmatrizen, die bei Anforderungsänderungen nicht aktualisiert werden, führen zu veralteten Modellen. Das gleiche gilt für importierte Informationen, die nicht mit der Quelle synchronisiert werden. Ein Modell, dass unzuverlässige Informationen enthält gilt schnell als Datengrab und verliert damit seine Akzeptanz. Es ist also von entscheidender Bedeutung mit der Systementwicklung zu pflegen. Nur Modelle, die wertvolle Informationen enthalten werden gern gepflegt.

Standardisieren

Modelle haben erstaunliche Analogien mit gemeinsam genutzten File-Servern. Sie tendieren zum Chaos. Das erste Mittel der Wahl sind geeignete Standards und Richtlinien. Namenskonventionen, genormte Paketstrukturen und angemessene Stereotypisierung haben sich als sehr hilfreich erwiesen. Aber auch die Reglementierung der Verwendung bestimmter Sprachelemente hilft Modellen ein einheitliches Look & Feel zu geben und erleichtert den Benutzern die Orientierung. Bestimmte Sprachelemente nicht zu verwenden kann auch zu diesem Ziel beitragen.

Eine Modellierungsrichtlinie sollte im Umfang limitiert werden. Eine Mehrere hundert Seiten lagen Richtline wird mit großer Wahrscheinlichkeit nur in Teilen berücksichtigt, eine Überprüfung auf Konformität ist nur schwer zu realisieren. Dort wo es möglich ist, sollte man in anstreben die Einhaltung einer Richtlinie automatisiert zu prüfen.

Rollen und Verantwortlichkeiten klären

Eine eingehaltene Modellierungsrichtlinie ist jedoch kein Garant für ein gutes Modell. Selbstverständlich sollten auf Modellen geeignete Qualitätssicherungsmaßnahmen durchgeführt werden. Die Verifikation und Validierung von Systemen auf Basis von Modellen kann mit den üblichen Verfahren wie Reviews durchgeführt werden. Mit Modellabfragen und Prüfregeln kann der Prozess effizient unterstützt werden. In komplexen Umgebungen kann es Sinn machen diese Aufgaben in einer Rolle zu bündeln.

Die Modellierer nehmen natürlich eine Schlüsselrolle für die Qualität der Informationen ein. Ihre Rollen im Rahmen des PEP decken die gesamte Bandbreite vom Requirements Engineer über den Systemarchitekten bis zum Tester ab. In einem vollständig modellbasierten Szenario arbeiten diese Rollen direkt auf dem Modell. Es gibt aber durchaus Konstellationen in denen einem Fachexperten ein Modellierer zu Seite gestellt wird. Ziel sollte sein möglichst viele aktive PEP-Teilnehmer zu Modellierern zu machen.

Eine Modellierungssprache stellt aber immer erst mal eine Sprachbarriere dar. Das ist auch nach einem Intensivtraining noch der Fall. Eine Sprache lernt man nur indem man sie kontinuierlich anwendet. Im Gegensatz zu natürlichen Sprachen hilft ein Coach die Lernkurve deutlich steiler zu gestalten als beim weitverbreiteten Learning-by-Doing.

Um große Multi-Modell-Umgebungen konsistent, wartbar und benutzbar zu halten empfiehlt es sich, wie bei realen Systemen auch, die Rolle des Modell-Architekten zu besetzen. Die Weiterentwicklung von MBSE hat unweigerlich Anpassungen and der Architektur von Modellen zur Folge. Ein Modell-Architekt muss diese Anpassungen unter Berücksichtigung des Gesamtsystems vornehmen und definiert entsprechende Referenzmodelle und Richtlinien. Dem Aufbau und der Wartung von Bibliotheken und Profilen kommt ebenfalls eine übergeordnete Bedeutung zu, die durch eine integrierende Rolle wie den Modellarchitekten gesteuert werden sollte.

Die Strategie im Auge behalten

Der Aufbau von MBSE und einer entsprechenden Umgebung ist das Resultat der Entscheidungen einiger Weniger, betroffen sind aber Viele. Die Erstellung von Modellen ist Resultat vieler Entscheidungen vieler Personen. Einige Entscheidungen haben negative Effekte auf kritische Faktoren, die teils schwer vorhersehbar sind. Daher ist es wichtig explorativ vorzugehen und Risiken zu minimieren.

Kurz gesagt: Groß denken, klein anfangen, inkrementell vorgehen.

(Dieser Beitrag wurde mit freundlicher Genehmigung des Autors dem Tagungsband Embedded Software Engineering Kongress 2018 entnommen.)

* Bernd Busam ist Trainer und Berater bei der oose Innovative Informatik eG, mit Schwerpunkt im Systems Engineering mit modellbasierten Methoden und Sprachen wie SysML und UML.

(ID:45849427)