Prozessblog

Als eingetragener Verein (e.V.) organisiert bildet die Gesellschaft für System Engineering (GfSE) das deutsche Chapter von INCOSE. Ich habe mich vorhin mit Sven-Olaf Schulze, Vorsitzender der GfSE, unterhalten. Stolz präsentierte er mir die druckfrischen Flyer für die neue Ausbildung zum Certified Systems Engineer (GfSE).

Das Zertifikat wurde in den letzten zwei Jahren von der GfSE in Anlehnung an das INCOSE SE Handbook entwickelt. Es ist komplett auf deutsch und soll dem Berufsbild des System-Ingenieurs ein neues Profil geben.

Inhaltlich beinhaltet die Zertifizierung neun Trainingsmodule:

• Grundlagen des Systems Engineering
• Übergreifende SE-Schnittstellen
• Schnittstellen zum Projektmanagement
• Systems Engineering Management
• Anforderungsmanagement und V&V
• Realisationsprozesse
• Querschnittsfunktionen
• Operationelle Aspekte des SE
• SE Soft Skills

Ab sofort kann man sich bei rücker+schindele (München) oder bei oose (Hamburg) zum Level C (“Verstehen”) ausbilden lassen. Für 2012 ist Level B (“Anwenden”) geplant; irgendwann folgt Level A (“Beherrschen”), für das schon eine eigene Studienarbeit geschrieben werden muss.

Aber auch Level C hat es schon in sich und hat dadurch aber auch einen gewissen Wert.

• Gesamtdauer etwa fünf Monate
• Schulungsdauer je nach Anbieter etwa 12 Präsenztage
• 2 Stunden Prüfung (durch TÜV Rheinland und GfSE-Assessoren)

Wie ich von Sven-Olaf Schulze erfahre, lassen sich Level C und Level B in die internationalen INCOSE-Zertifikate ASEP und entsprechend CSEP übertragen. Level A wird allerdings nicht für ESEP anerkannt werden. Für ESEP sind 25 Jahre Berufserfahrung notwendig. Die GfSE ist hier bewusst einen anderen Weg gegangen, da diese Anforderung nicht angemessen schien.

Weitere Informationen gibt es zukünfitg unter http://sezert.de.

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.

Besonders in jungen Start-Ups ist es nichts Ungewöhnliches; eher konservative Firmen tun sich meist schwerer. Die Rede ist von der Einführung eines Enterprise Wikis wie Atlassian Confluence.

Ich hatte heute Kontakt mit einem Berater von Seibert-Media, eine in Wiesbaden ansässige Firma, die viel Erfahrung aufweisen kann mit der Einführung firmenweiter Wikis.

Dabei ist der Begriff Wiki noch zu wenig und für viele ein vorbelegtes Unwort, denkt man doch zu leicht an Wikipedia. Confluence ist eigentlich eine komplette Kollaborations-Platform, die es ermöglicht, verschiedene Bereiche (Spaces) zu definieren, in denen man sich austauschen kann. Der entscheidende Unterschied in der Denkweise des Informationsaustausches ist der Übergang vom Push- zum Pull-Prinzip.

Während ich mit E-Mails jeden belästigen muss, der vielleicht an der Information interessiert sein könnte (push), kann man sich in einem Wiki bestimmte Inhalte abonnieren und erhält somit die Informationen, die für mich relevant sind (pull). Kommentare an Wiki-Seiten bieten einen direkten Austausch und bewirken einen enormen Mehrwert.

Durch diese Art der Informationsbereitstellung bin ich besser darüber informiert, wer sich mit welchen Themen auskennt oder welches Projekt gerade welches Problem gelöst hat. Gerade in verteilten Standorten ermöglicht dies erst die Zusammenarbeit. Microblogging (Statusmeldungen á la Facebook) informieren darüber, woran ein Mitarbeiter gerade arbeitet.

Die oberste Prämisse dabei ist natürlich, dass ein solcher Wissensaustausch auch vom Unternehmen gewollt ist. Manche Firmen müssen hier erst einen Kulturwandel durchlaufen – das ist nicht einfach und erfordert Zeit und viel Fingerspitzengefühl bei der Einführung.

Die folgenden zwei Bücher seien nach Meinung des Experten äußerst wertvolle Quellen zu dem Thema:

• Martin Seibert et al.: Enterprise Wikis
• Stewart Mader: Wikipatterns, siehe auch wikipatterns.com