Sondervorträge von Prof. Hiroaki Takada und David Hetherington, mit einem Vortrag von Kazuyuki Murakami und einem geselligen Beisammensein

Die wichtigsten Bausteine von SYSMOD

Was SYSMOD festlegt, lässt sich an der SYSMOD-Ontologie ablesen. Wer die Arbeit tut (Role), welche Arbeit es ist (Process), mit welcher Methode (Method). Was in diese Arbeit eingeht und was dabei herauskommt (Product). Eine Methodik (Methodology) ist die Verbindung dieser Elemente. Das Werkzeug (Tool) ist als etwas eingeordnet, das eine Method unterstützt.

Im Diagramm geht von Tool nur eine einzige Linie aus: facilitates zu Method. Bei Method laufen die Beziehungen zusammen.

Das Domänenwissensmodell von SYSMOD zeigt diesen Aufbau mit den wichtigsten Begriffen und ihren Beziehungen. Die einzelnen Begriffe sind wie folgt festgelegt.

• Role (Rolle): die Kompetenzprofile der Personen, die die Methoden ausführen und für die Produkte verantwortlich sind
• Method (Methode): eine Sammlung von Aufgaben, die für die Systementwicklung wesentliche Artefakte hervorbringen
• Product (Produkt): was in eine Methode eingeht und was aus ihr hervorgeht; die Verantwortung dafür trägt eine Rolle
• Process (Prozess): eine im Grundsatz sinnvolle logische Abfolge, in der die Methoden ausgeführt werden können

Fähigkeiten und Kompetenz je Rolle

In Abbildung 1.1 direkt darüber stand Role als einer der Bestandteile einer Methodik. SYSMOD legt auch fest, welche Kompetenz jede Rolle verlangt. Die folgende Abbildung legt die Kompetenz eines System Testers für neun Fähigkeiten fest, auf einer Skala von sechs Stufen ― sieben, wenn Stufe 0, keine Fähigkeit, mitgezählt wird.

Aus Tim Weilkiens, SYSMOD – Pragmatic MBSE with SysML, 3. Auflage. Mit freundlicher Genehmigung.

Testing sticht heraus, dahinter SYSMOD, SysML und die Ingenieurdisziplin; Programming und System Architecting liegen niedriger. Welche Gestalt die Kompetenz einer Rolle hat, lässt sich auf einen Blick ablesen.

Das ist die Grundlage des Kompetenzmanagements. Ohne es kann eine Organisation einem Projekt nicht die richtigen Ressourcen zuordnen. Wer gehört in welche Rolle: Setzt man Menschen ohne Grundlage für diese Entscheidung ein, gerät das Projekt ins Stocken. Ein Projekt durchzubringen hängt daran, Kompetenz zu steuern.

Die von SYSMOD definierten Prozesse

Eine Methodik funktioniert nicht, indem man sie unverändert hereinträgt. Eine Organisation wendet sie an, indem sie sie auf die eigene Gestalt zuschneidet. SYSMOD definiert diese Anwendung selbst als Prozess.

Die obere Hälfte des Diagramms zeigt die Arbeit der oberen Ebenen sowie der indirekten und unterstützenden Bereiche einer Organisation: den Adoption Process, der die Methodik in die Organisation bringt, und den Infrastructure Process, der sie trägt. Die untere Hälfte zeigt diejenigen, die nutzen, was die Organisation bereitgestellt hat: Projektleitung, Requirements Engineer und System Architect, die den Analysis Process und den Architecture Process durchlaufen.

Auf den ersten Blick sieht es aus wie ein Diagramm, das jede und jeder zeichnen könnte. Doch gerade solche Diagramme lassen eine kompliziert wirkende Struktur einfach darstellen. Weil sie einfach ist, lässt sie sich verstehen; und weil sie verstanden wird, kann man darüber sprechen. Genau in dieser Reihenfolge zahlt sich eine MBSE-Methodik in der Praxis aus.

Der SYSMOD Infrastructure Process

Das oben erwähnte Zuschneiden ist die erste Aktion dieses Prozesses: Tailor the MBSE Methodology. Von dort laufen drei Stränge parallel: das Ausrollen in der Organisation (Deploy the MBSE Methodology), das Bereitstellen von Schulung und Begleitung (Provide MBSE Training and Coaching) sowie das Einrichten und Pflegen der Modellierungsumgebung (Set up and maintain the SME).

Das Ergebnis (outcome) dieses Prozesses ist, dass eine auf die Organisation zugeschnittene MBSE-Methodik ausgerollt ist und sowohl die Umgebung, die sie trägt, als auch die Kompetenz, sie zu nutzen, vorhanden sind. Drei Arbeitsergebnisse (outputs) tragen dieses Ergebnis.

• Die MBSE-Methodik ― die auf die Organisation zugeschnittene Methodik selbst.
• Die Systemmodellierungsumgebung (SME: Systems Modeling Environment) ― das, womit sie tatsächlich betrieben wird.
• MBSE-Schulung ― das Programm, über das die Nutzenden die Kompetenz aufbauen.

Eine Methodik bloß auszuteilen bewegt eine Organisation nicht. Die zugeschnittene Methodik, die Umgebung, die sie trägt, und die Schulung derer, die sie nutzen: Das Diagramm zeigt die drei nebeneinander laufen.

Der SYSMOD Analysis Process

Er hat weitgehend dieselbe Gestalt wie der Adoption Process. Der Unterschied liegt im System, auf das er angewendet wird. Der Adoption Process nimmt die MBSE-Methodik selbst als System; der Analysis Process nimmt das Produkt, das entwickelt werden soll. Dieselbe Form, auf einen anderen Gegenstand gerichtet.

Das betrachtete System heißt System of Interest (SoI). Ein SoI ist nicht auf ein Engineered System beschränkt: eine Organisation, ein Organisationsverbund, ein Managementsystem – alles, was aus Bestandteilen besteht, ist ein System. Auch eine Methodik besteht aus Teilen: Rollen und Verantwortlichkeiten, geforderte Kompetenzen, Methoden, Prozesse und Ergebnisse. Bei einer MBSE-Methodik kommen eine Modellierungssprache und ein Modellierungswerkzeug hinzu. Da eine Methodik selbst ein System ist, lässt sie sich als solches analysieren und zu einem System formen, das zur Organisation passt.

Das Ergebnis (outcome) dieses Prozesses ist, dass Problem und Ziele geklärt sind und mit den Stakeholdern Einigkeit darüber besteht, was gebaut wird und auf wessen Anforderungen es antwortet. Die Arbeitsergebnisse (outputs), die dieses Ergebnis tragen:

• Base Architecture
• Domain Knowledge
• Requirements
• Risks
• Stakeholders
• System Context
• System Idea
• System Objectives
• System Processes
• System Use Cases
• Use Case Activities

Das sind keine getrennten Dokumente. Sie hängen innerhalb eines einzigen Modells zusammen, und genau das macht das Ganze auf Konsistenz prüfbar. Dass das Diagramm dicht wirkt, liegt daran, dass jede dieser Beziehungen eingezeichnet ist.

Der SYSMOD Architecture Process

Während der Analysis Process festlegt, was gebaut werden soll, legt der Architecture Process fest, wie es zusammengesetzt wird. Die Artefakte des Analysis Process, nämlich Systemkontext, Anforderungen, Base Architecture und System Use Cases, werden zu seinen Eingaben.

Das Ergebnis (outcome) dieses Prozesses ist, dass eine Struktur feststeht, die die Anforderungen erfüllt, und dass sich die Gründe für diese Struktur bis zu den Anforderungen zurückverfolgen lassen. Die Arbeitsergebnisse (outputs), die dieses Ergebnis tragen:

• Logical Architecture
• Product Architecture
• Scenario
• System State

FAS (Functional Architectures for Systems) ergänzt SYSMOD. Die im Diagramm links mit «Optional» gekennzeichnete funktionale Architektur ist das, was FAS hervorbringt. Konzept und Einzelheiten der FAS-Methode sind im Buch Model-Based System Architecture, Second Edition beschrieben.

Von welcher Architektur ist die Rede?

Base Architecture, Logical Architecture, Product Architecture, Test Architecture, Functional Architecture: Inzwischen sind etliche „Architekturen“ vorbeigekommen. Kennen Sie die Situation, dass in einer Besprechung von „der Architektur“ die Rede ist und unklar bleibt, welche gemeint ist?

SYSMOD hält sie als Typen auseinander.

System Architecture und Physical Architecture stehen kursiv: Sie sind abstrakt, es gibt nichts, was eine von ihnen wäre. Wer bloß „die Architektur“ sagt, hat nichts benannt. Entscheidend ist, klar zu benennen und sauber zu trennen, von welcher Architektur konkret die Rede ist.

Das allgemeine SysML auf die eigene Organisation zuschneiden

SysML ist eine Allzwecksprache. Gerade weil sie jedes beliebige System beschreiben können soll, ist sie so, wie sie ist, nicht die Sprache der Arbeit, die vor Ihnen liegt. Also ergänzt man Vokabular passend zur eigenen Organisation. SYSMOD legt dafür Erweiterungen (Stereotypen) wie die folgenden fest. Es gibt weitere; Einzelheiten finden Sie im SYSMOD-Buch.

Zuerst die Akteure. Der SysML-Actor bekommt Namen: Benutzer, externes System, Sensor, Aktor, mechanisches System, Randsystem. Auch Wirkungen auf die Umwelt sind typisiert.

Dann die Disziplinen. Ob ein Element Software, Mechanik oder Elektrik ist, wird als Typ mitgeführt. Wer MBSE für eine Softwareangelegenheit gehalten hat, dürfte hier überrascht sein.

Mit den Blöcken verhält es sich ebenso: System, Subsystem, Systemkontext, Domänenblock, Dokumentblock, Benutzerschnittstelle. Die Kennzeichnungen «domainBlock» und «systemUseCase», die in den Abbildungen oben immer wieder auftauchten, sind hier definiertes Vokabular.

Eine Allzwecksprache bloß auszuhändigen bewegt niemanden. Sie muss auf die eigene Organisation zugeschnitten werden. Genau das stand am Anfang des Infrastructure Process.