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 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.

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!

Auswahl der Appraisal Team Members

Für diejenigen, die an einem Appraisal mitarbeiten gab es schon immer gewissen Vorraussetzungen, die in v1.3 nun grob so aussehen:

• jedes ATM muss mind. zwei Jahre Erfahrung (field experience) haben; Ausnahmen müssen begründet werden
• im Schnitt haben die ATM’s je sechs Jahre Erfahrung (ohne den Lead Appraiser)
• insgesamt haben die ATM’s 25 Jahre Erfahrung (wieder ohne den Lead Appraiser)
• zusammen haben die ATM’s mind. zehn Jahre Management-Erfahrung, einer aber mind. sechs Jahre

Keine Indirect Artifacts mehr

Wer schon mal an Appraisals teilgenommen hat oder diese vorbereitet hat, weiß, man unterscheidet in Direct Artifacts, Indirects Artifacts und Affirmations. Das ist nun anders. Es gibt neuerdings nur noch Artifacts und Affirmations.

Es gibt somit keine Unterscheidung mehr zwischen Direct und Indirect Artifacts. Der zusammengefasste Begriff Artifact steht nun für die primären greifbaren Ergebnisse einer Praktik, aber auch für andere Arbeitsergebnisse, die durch die Ausführung der Praktik entstehen. Um eine Praktik zu belegen, müssen Artifacts herangezogen werden, die zeigen, das die entsprechende Arbeit getan wird.

Affirmations hingegen werden generischer definiert. Das sind mündliche oder auch schriftliche Aussagen, die die Implementierung einer Praktik bestätigen. Somit können auch Antworten auf Fragen in E-Mails als Affirmations gewertet werden. Auch Präsentationen zählen nun offiziell als Affirmations. In Zukunft können also durch Präsentationen, Demonstrationen oder auch ausgefüllte Fragebögen eine Reihe von Affirmations sehr zeitsparend abgehakt werden.

Keine Fokus-Projekte mehr

Da SCAMPI für die drei Modelle CMMI for Development, CMMI for Service und CMMI for Acquisition gilt, sind die Bemühungen gewesen, den “Projekt”-Begriff weitestgehend zu entfernen. Es gibt nun keine Fokus-Projekte mehr, die man für das Appraisal als Schwerpunkt-Betrachtung wählt, sondern man redet von Basic Units.

Was vorher ein Projekt war, ist also jetzt eine Basic Unit. Daneben gibt es noch Support Functions wie etwa eine übergreifende Qualitätssicherung, ein Projektbüro oder ähnliche Einrichtungen. Der Organizational Scope bezeichnet die Menge der Basic Units und Support Functions, die für das Appraisal Daten liefern. Er ist eine Teilmenge der betrachteten Organizational Unit.

Die Basic Unit werden in Subgroups eingeteilt. Die Kategorisierung kann nach verschiedenen Gesichtspunkten, sog. Sampling Factors, erfolgen wie etwa Anzahl der Standorte, Art der Kunden, Art der Finanzierung, Aufhängung im Unternehmen, Art der Arbeit. Somit enthält eine Subgroup Instanziierungen ähnlicher Prozessimplementierungen in Form der in ihr enthaltenen Basic Units.

Neu ist nun, dass die Anzahl der mindestens zu betrachtenden Projekte (Basic Units) durch eine Formel beschrieben ist.

wobei
: minimale Anzahl der auszuwählenden Basic Units der betrachteten Subgroup
: Anzahl aller Subgroups
: Anzahl der Basic Units der betrachteten Subgroups
: Anzahl aller Basic Units

Um eine Vorstellung zu bekommen, hier ein paar der Themenbereiche, denen die Präsentation typischerweise zuzuordnen sind:

• Arbeiten als Team
• Änderungsmanagement
• CMMI for Service
• Risikomanagement
• CMMI und Agile
• High Maturity
• Kombinieren von Referenzmodellen
• CMMI für kleinere Unternehmen
• Measurement

Watts Humphrey, quasi der Vater des CMMI, war Keynote Speaker am Mittwoch. Ein beeindruckender Mann; ich konnte ihn letztes Jahr auf der europäischen SEPG in Prag erleben.

An deutschen Referenten fiel mir bisher nur der Vortrag von Winfried Russwurm (und Kollegen) von Siemens auf. Wir werden bestimmt mehr treffen, wenn es Ende Juni für Europa soweit ist.

Die diesjährige SEPG Europe wird vom 28. Juni bis 1. Juli in Portugal stattfinden.
Weitere Details finden Sie auf der Website des SEI.