Prozessblog

Diese Woche findet in Hamburg die Konferenz der Gesellschaft für Systems Engineering statt. Am heutigen Tag startete das Event mit halbtägigen Tutorials. Den Vormittag hielt Tim Weilkiens zum Thema “Modellbasiertes Systems Engineering erleben”.

Auch wenn ich durch Tims Consulting-Tätigkeiten bei uns das Vorgehensmodell schon kenne, habe ich ich doch wieder einige Best Practices und Infos notieren können. Teilweise waren es Details, die mir noch nicht so klar waren, teilweise aber auch nur Dinge, die ich vielleicht noch deutlicher in unserer eigenen MBSE-Guideline klarstellen könnte.

Nach einem zügigen Durchlaufen über den Sinn und Zweck von MBSE (schließlich war es ein Anfänger-Tutorial), haben wir als Beispiel ein Waldbrandmelde-System in MagicDraw modelliert.

Hier mal in Kurzform meine Notizen, vielleicht hilft es jemandem:

• Um Pakete global unterscheidbar zu machen, sollten sie immer den Systemnamen enthalten. Für das Forest Fire Detection System (FFDS) also bspw.  FFDS_Requirements, FFDS_Structure usw.
• So wie ein Buch ein Inhaltsverzeichnis hat, sollte jedes Paket ein Content-Diagramm haben. Das ist ein Package-Diagramm, das den Inhalt des Pakets aufzeigt. In MagicDraw gibt es übrigens ein spezielles Content Diagram, das auch Inhalte der eingebunden Diagramme anzeigen kann.
• SysML kennt als Akteur nur die Strichmännchen. Man sollte sich eigene Kategorien (Akteur-Stereotypen) definieren, mindestens aber «External System», um zwischen menschlichen und nicht-menschlichen Akteuren unterscheiden zu können.
• Bei der Definition des Systemkontextes ist es oft schwierig abzugrenzen, ob es zum System gehört oder zum Systemkontext, also als Akteur modelliert wird. Als Faustregel kann gelten: Alles, was im Verantwortungsbereich des Systems liegt, gehört zum System. So wird klar, dass dies unabhängig von der Tatsache ist, ob eine Komponente extern entwickelt wird oder nicht.
• Es ist zu beachten, dass es sich bei der Modellierung des Systemkontexts um eine logische Systemgrenze handelt, nicht um eine physikalische.
• Als Akteure modelliert man die eigentlichen Fachadressaten, also im Beispiel das Fire Department und nicht etwa Internet.
• Stakeholder werden in der Regel nicht als Akteure des Systemkontextes modelliert, da sie nicht mit dem System interagieren. Dennoch kann es Sinn machen, wichtige Stakeholder zu modellieren, dann aber als Akteure in einem eigenen Diagramm.
• Die «include»-Beziehung zwischen Use Cases sollte nur verwendet werden, wenn der referenzierte Anwendungsfall von mehr als einem Anwendungsfall eingebunden wird, wenn als Redundanz vermieden wird.
• Beim Modellieren von Anwendungsfällen identifiziert man zunächst alle Anwendungsfälle zu einem bestimmten Akteur und assoziiert dann zu jedem gefundenen Anwendungsfall die anderen beteiligten Akteure.
• Das Modellieren von Aktivitätsdiagrammen ist eine Gradwanderung der Abstraktionsebene. Gewisse Design-Entscheidungen sind an dieser Stelle schon notwendig, damit die Aktivitäten nicht zu abstrakt und somit nutzlos bleiben. Andererseits befindet man sich bei der Modellierung von Anwendungsfällen immer noch in der Analyse, so dass die Aktivitäten nicht zu konkret werden dürfen, um sich spätere Design-Entscheidungen nicht zu verbauen.
• Nicht jeder Use Case muss durch ein Aktivitätsdiagramm verfeinert werden. Überlegen, was wirklich hilft!
• Anwendungsfälle können in Ausnahmefällen auch durch Zustandsdiagramme beschrieben werden. In der Regel passen aber Aktivitätsdiagramme besser. Zustandsdiagramme nur verwenden, wenn der Use Case sehr zustands-fokusiert ist.
• Use Cases sind eine Verfeinerung von funktionalen Anforderungen, so dass man eine «refine»-Beziehung vom Use Case zum Requirement zieht.
• Die SysML hat drei Abstraktionsebenen: (1) die Typebene in den Blockdefinitionsdiagrammen, (2) die Rollenebene in den Internen Blockdiagrammen, (3) die Instanzebene in den Parametrischen Diagrammen.
• In den bald erscheinenden SysML 1.3 sind einige Verbesserungen zum Einheitensystem (bspw. Umrechnung zwischen Einheiten) sind zu erwarten.
• In SysML sind für Anforderungen nur Name, ID und Text definiert. Alles andere (wie Priorität und dergleichen) wären Vorgaben, die dem SysML-Standard nicht zustehen.
• Im Produktbaum stellt man die Blöcke, aus denen das System besteht, mit einer gerichteten Kompositionsbeziehung dar. Im internen Blockdiagramm des System-Blocks werden diese Blöcke dann als Part Properties dargestellt. Diese entsprechen im bdd den Pfeilen (Assoziationsende) der gerichteten Komposition und bedeutet, dass das Part Property  nach dem Bauplan des entsprechenden Blocks gebaut ist.
• Die Konnektoren im Internen Blockdiagramm (ibd) stehen für Kommunikation im weitesten Sinne zwischen den beteiligten Parts.
• Man sollte für jeden Aspekt (information, electrical, mechanical) ein Internes Blockdiagramm erstellen.
• Der Name “Standard Port” ist eigentlich unglücklich, “Service Port” wäre netter gewesen, denn die Ports bieten Dienste an.
• Das SysML-Interface (Lolli-Darstellung) steht für eine Liste von Funktionen und hängt an einem Standard-Port.
• Um die drei Aspekte (information, electrical, mechanical) entsprechend darzustellen, erhält man auch drei Ports. Damit man weiß, dass diese zusammen gehören, sollten diese alle auf einem Standard Port liegen. Solche Nested Ports sind in SysML explizit erlaubt.
• In SysML 1.3 sind die Interfaces (Lollies) nicht mehr notwendig. Funktionen stehen dann in der Port-Definition selbst.

Ich werde bestimmt einige der Punkte in Zukunft nochmal aufgreifen.

Wir bleiben noch etwas beim Thema Entscheidungsfindung. Heute geht es darum, wie ich zu einer Gewichtung von Kriterien komme, nach denen ich dann verschiedene Optionen bewerten kann.

Wir wissen bereits, eine strukturierte Entscheidung besteht aus fünf Schritten:

1. Kriterien festlegen für die Bewertung der möglichen Optionen
2. Mögliche Lösungen identifzieren
3. Verfahren zur Bewertung der Lösungen auswählen
4. Identifizierte Lösungen mit dem gewählten Verfahren anhand der festgelegten Kriterien bewerten
5. Auf Grundlage der Bewertung die beste Lösung auswählen

Ich habe zuvor gezeigt, dass eine Entscheidungsmatrix den Prozess schon recht vollständig abdecken kann. Offen bleibt jedoch, wie man sinnvoll die Kriterien gewichtet.

Dazu eignet sich ein Tool namens Paarvergleichsanalyse (Paired Comparison Analysis). Bei der Paarvergleichsanalyse werden verschiedene Optionen (bspw. eben Kriterien einer Entscheidungsmatrix) paarweise miteinander verglichen, um die Wichtigkeit untereinander zu bestimmen.

• 0: kein Unterschied in der Wichtigkeit der zu vergleichenden Optionen
• 1: etwas wichtiger
• 2: wichtiger
• 3: bedeutend wichtiger

Nach Vergleich aller Optionen untereinander, kann man für jede Option eine Punktzahl als Gewichtungsfaktor ermitteln. Die Paarvergleichsanalyse ist insb. sinnvoll, wenn objektive Daten zur Bewertung fehlen oder “Äpfel mit Birnen” verglichen werden.

Anbei eine Excel-Vorlage zum Ausprobieren.

Vorlage_Paarvergleichsanalyse.xlt

Die Anleitung zum Ausfüllen befindet sich im how-to Sheet.

Viele Entscheidungen im Projekt werden aus dem Bauch heraus getroffen. Eine Entscheidung argumentativ zu begründen, fällt im Nachhinein schwer. Warum man sich für die eine und nicht für andere Option entschieden hat, lässt sich später oft nur schwer nachvollziehen. Entscheidungen werden anfechtbar und der “Entscheider” steht schlecht da.

In CMMI gibt es einen ganzen Prozessbereich Entscheidungsfindung (engl. Decision Analysis and Resolution), der Organisationen anleiten soll, bestimmte Entscheidungen formal zu treffen. Wie schon in einem vorhergehenden Artikel erwähnt, besteht eine solche strukturierte Entscheidung aus fünf Schritten:

1. Kriterien festlegen für die Bewertung der möglichen Optionen
2. Mögliche Lösungen identifzieren
3. Verfahren zur Bewertung der Lösungen auswählen
4. Identifizierte Lösungen mit dem gewählten Verfahren anhand der festgelegten Kriterien bewerten
5. Auf Grundlage der Bewertung die beste Lösung auswählen

Es gibt diverse Bücher, die Methoden vorstellen, um Entscheidungen zu treffen. Ein nettes Online-Werk nennt sich Mind Tools von der gleichnamigen Firma.

Eine Methode, die die obigen Punkte quasi alle in einem Tool abdeckt, ist die Entscheidungsmatrix. Man zeichnet eine Tabelle. Die Zeilen enthalten die Bewertungskriterien. Die Spalten listen die verschiedenen Lösungen. Nun vergibt man Punkte (bspw. 0 bis 4) für den Erfüllungsgrad jedes Kriteriums für alle Lösungsoptionen. Idealerweise definiert man vor der Bewertung noch für jedes Kriterium, wann es 0, 1, 2, 3 oder 4 Punkte gibt. Die Option mit den meisten Punkten wird ausgewählt.

Anbei mal eine Excel-Vorlage einer Entscheidungsmatrix zum Download:

Vorlage_Entscheidungsmatrix.xlt

Die Matrix zeigt Kriterien für eine Lieferantenauswahl, wie sie bspw. getroffen werden soll, wenn eine bestimmte Software-Komponente von einem Unterauftragnehmer entwickelt werden soll.

• Die Kriterien sind in vier Kategorien eingeteilt, die sich in Spalte D gewichten lassen. Spalte E zeigt die errechnete prozentuale Wichtung der Kategorien.
• Innerhalb einer Kriterien-Kategorie lässt sich die Gewichtung der Kriterien ebenfalls in Spalte D einstellen. Spalte E zeigt die prozentuale Wichtung über alle Kriterien.
• Sie müssen die Kriterien an ihre Entscheidung anpassen. Falls Sie weniger Kriterien in einer Kategorie benötigen, setzen Sie die Gewichtung einfach auf Null! Notfalls müssen Sie weitere Zeilen hinzufügen. Kopieren Sie eine bestehende Zeile, um alle Formeln mitzunehmen!
• In die blauen Felder setzen Sie ihre Bewertung für die einzelnen Optionen.

In dem Arbeitsblatt “how-to” ist die Verwendung der Entscheidungsmatrix-Vorlage näher erläutert. Viel Erfolg bei Ihren Entscheidungen!