Das Hamburger Systems Engineering GetTogether
Am 22.9. fand das von OOSE in deren Räumlichkeiten veranstaltete SE GetTogether statt. Diese Abendveranstaltung sind eine großartige Möglichkeit für Systems Engineers im Hamburger Raum, um sich gegenseitig auszutauschen. Die kostenlosen SE Get Togethers werden über Xing bekanntgegeben.
Interessante Veranstaltungen
Dieses Get Together war mit ca. 25 Teilnehmern gut besucht und war als Word-Café organisiert. Für diejenigen, die es nicht kennen: ein World-Café ist eine Art von Workshop, bei dem an verschiedenen Tischen verschiedene Themen diskutiert werden. Die Themen kommen von den Teilnehmern. In diesem Fall waren genug Teilnehmer für vier Gruppen da, und alle vorgeschlagenen Themen drehten sich in irgendeiner Form um Modellierung. Ich selbst moderierte einen Tisch zum Thema „Modellierung von Anforderungen“. Mich freut, dass das Thema Modellierung wieder ein bisschen in Fahrt kommt. Auch das Interesse an dem von mir mitorganisierten Modeling Craftmanship Barcamp in Hannover bestätigt dies.
Der oose Campus
Die Räumlichkeiten bei oose sind hervorragend für solche GetTogethers geeignet: Das große, einladende Atrium konnte problemlos alle Teilnehmer aufnehmen. Moderationsmaterialien waren reichlich vorhanden, und die Tische bereits mit großen Papierblättern versorgt. Im ooses Campus findet auch das von mir mitorganisierte Hamburger SE Barcamp im Dezember statt.
Modellieren von Anforderungen
Ich habe schon oft gesagt, dass Modellierung meiner Meinung nach den größten Mehrwert bei den Anforderungen bringt, was auch empirisch von Daniel M. Berry belegt wurde. Insofern drehte sich an meinem Tisch alles um Anforderungsmodellierung: Was genau ist es, was ist zu beachten, wie realisiert man den größten Mehrwert? Dabei erarbeiteten wir insgesamt drei Ergebnisse. Diese sind zwar nicht überraschend, jedoch für Einsteiger zu dem Thema sicher hilfreich:
Modelle werden zum Verifizieren und Erweitern von Anforderungen eingesetzt; oder sie ersetzen Anforderungen komplett.
Es gibt zwei Einsatzmöglichkeiten von Anforderungsmodellierung: (1) Das Modell ergänzt die Anforderungen, oder (2) Das Modell ersetzt die Anforderungen. Im ersten Fall können durch das Modell die Anforderungen Verifiziert und verbessert werden. Insbesondere können auch neue Anforderungen vom Modell abgeleitet werden. Im zweiten Fall fallen traditionelle Anforderungen komplett weg, da das Modell die Rolle der Anforderungen vollständig erfüllen kann.
Es ist hilfreich, das Ausdrücken der Anforderungen von der Modellierungssprache zu trennen.
Es war gar nicht leicht, die Frage zu beantworten, was Modellierung von Anforderungen eigentlich bedeutet. Insbesondere kann der selbe Sachverhalt mit dem selben Ausdruck in unterschiedlichen Sprachen ausgedrückt werden. ein einfaches Beispiel (vereinfacht): „Wann Schalter A und B geschlossen sind, leuchtet die Lampe L“. Dies ist bereits ein Modell in natürlicher Sprache. Es könnte mit den Symbolen der Logik folgendermaßen geschrieben werden: A ∧ B ⇒ L. (Natürlich müssen A, B und L auch modelliert werden.)
In der Praxis ist dies wichtig, da schnell gesagt wird: „Wir modellieren in SysML“. Damit steht zwar die Sprache, es wird aber nichts über die Ausdrucksweise gesagt. Und die wiederum hat viele Aspekte, die zu zahlreich sind, um sie hier aufzuzählen. Stichworte hier sind Architektur, Design Pattern, Auswahl der Sprachelemente, usw.
Richtig eingesetzte Anforderungsmodellierung schafft einen großen Mehrwert.
Auch in dieser Erkenntnis sind wieder zwei Aussagen zu finden. Erstens muss Modellierung richtig eingesetzt werden. Auch wenn das offensichtlich erscheint: Ich bin überzeugt davon, dass dies einer der Hauptgründe für die Akzeptanzprobleme der Modellierung ist. Zu viele Menschen haben sich frustriert von Modellierung abgewandt, weil sich die erhofften Vorteile nicht materialisierten. Aber Modellierung ist schwierig. Auch dies ist einer der Gründe für das Veranstaltung des Modeling Craftsmanship Camp.
Der zweite Punkt ist, dass es ein großes Potential für die Modellierung gibt, wenn sie richtig eingesetzt wird. Die in der Session identifizierten Punkte waren:
- Grafisch/Visuell Informationen erfassen
- Redundanzen eliminieren
- Kommunizieren, insbesondere auf einer hohen Flugebene
- Problemstellung präzise erfassen
- Systematischer „Breakdown“ von Problemen
- Traceability, und zwar „horizontal“ und „vertikal“
- Verschiedene Sichten auf das Modell
- Systematische Verifizierung
Die hier angesprochenen Themen können problemlos Material für ein paar Dutzend Artikel liefern.
Danke an oose
Einer der Teilnehmer, Piotr Malecki, brachte es auf den Punkt: Der Grad an Community-Unterstützung, den oose hier leistet, ist bei weitem nicht selbstverständlich. An dieser Stelle noch einmal ein dickes Dankeschön an oose für die Unterstützung. Das muss ich in diesem Fall erst recht unterstreichen, da oose auch für das GfSE-Barcamp im Dezember die Räumlichkeiten zur Verfügung stellt.
GetTogether oder Barcamp?
Ich kam ja nicht umhin, das Modeling Craftsmanship Camp und das Systems Engineering Barcamp Nord zu erwähnen. Das liegt unter anderem daran, dass Barcamp und GetTogether vieles gemeinsam haben: Beide Formate nehmen den Einfluss von den Veranstaltern weg und geben die Kontrolle an die Teilnehmer. Das ermöglicht ein Engagement mit den Teilnehmern, welches in klassischen Konferenzen selten realisiert wird. Hinzu kommt, dass GetTogethers und Barcamps in der Regel sehr günstig (oder umsonst) sind. Außerdem finden diese oft außerhalb der Arbeitszeiten statt. Dadurch finden sich dort echte Enthusiasten, die sich auch in ihrer Freizeit gern mit dem Thema beschäftigen. Der wesentliche Unterschied zwischen den Formaten ist eigentlich nur die Länge: Während das GetTogether einen Abend füllt, dauert ein Barcamp in der Regel einen Tag.
