Systems Engineering Camps in Erlangen

Über den Beitrag diese Woche freue ich mich besonders, denn es geht um eine neue Veranstaltung, die zum ersten Mal stattgefunden hat. Heute berichtet Goran Madzar vom ersten Systems Engineering Camps in Erlangen. Dies ist eine Veranstaltung, die nun alle 2-3 Monate stattfinden wird.

Im Folgenden werden Veranstaltung und Ergebnisse vorgestellt – gespickt mit vielen Flipchart-Bildern und anderen analogen Materialien. Die Camps werden sowohl über den MedTech-Blog veröffentlicht, als auch über die üblichen Kanäle bei Xing, etc. Das nächste Camp wird voraussichtlich im Oktober stattfinden. Viel Spaß beim Lesen!

Gastbeitrag von Goran Madzar

Am 28.06.2018 hat das erste Systems Engineering Camp in Erlangen stattgefunden und war ein voller Erfolg. In diesem Artikel gibt es eine kurze Zusammenfassung für alle, die das Event verpasst haben.

Die Idee zum Camp

Der Grundgedanke bei der Veranstaltung war es, einen regelmäßigen, regionalen Austausch zum Thema Systems Engineering in der Region Nordbayern zu etablieren. Dazu wurde das Format des Barcamps genutzt. Im Gegensatz zu den bisherigen Systems Engineering Barcamps, wurde anstelle einer ganztägigen Veranstaltung auf eine Abendveranstaltung gesetzt. Damit war es den Teilnehmern möglich die Veranstaltung ohne Urlaub oder Inanspruchnahme des Wochenendes zu besuchen. Die Idee für das Camp ist, wie soll es anders sein, auf einem anderen Systems Camp entstanden. Daniela Kaiser (Krones AG), Jan Vollmar (Siemens AG) und ich (Goran Madzar) wollten uns gerne regelmäßiger austauschen ohne dazu weite Fahrten in Kauf zu nehmen. Gemeinsam haben wir das Event organisiert.

Die Teilnehmer

Mit 23 Teilnehmern war das erste Systems Camp in Erlangen gut besucht. Auf einem Flipchart konnten die Teilnehmer Informationen über sich notieren.

Die Agenda

Der offizielle Teil der Veranstaltung ging von 18:00 – 21:00 Uhr. Nach der Begrüßung mit den organisatorischen Aspekten wurden anschließend gemeinsam die Themen für die Sessions definiert. Die erste Session war dafür reserviert vorzustellen, wie der regelmäßige regionale Austausch zum Systems Engineering gedacht ist. Die anderen beiden Sessions wurden von den Teilnehmern ermittelt. Zum Schluss gab es noch eine Retrospektive und Verabschiedung.

Die Themen für die Sessions

Die Teilnehmer hatten die Gelegenheit Vorschläge zu machen und diese wurden an einer Wand gesammelt und gruppiert. Anschließend konnte jeder Teilnehmer abstimmen, welche zwei Themen am meisten interessieren und so wurden die zwei Sessions ausgewählt.

Session 1 – Arbeitskreis Systems Engineering Bayern Nordost

Ein regelmäßiger Austausch über Systems Engineering ohne weite Anfahrtswege und auf regelmäßiger Basis. Diese Idee stand bei der ersten Session im Vordergrund. Eine solche Veranstaltung könnte 4-6 Mal pro Jahr stattfinden. Die Teilnehmer haben sich für eine Abendveranstaltung ausgesprochen. Als Uhrzeit für den Beginn wurde mehrheitlich 17:00 – 18:00 genannt.

Session 2 – Umgang mit Änderungen / Inkonsistenz Management

Der Themenblock Umgang mit Änderungen am System und Konsistenz-Prüfungen wurde von den Teilnehmern als sehr interessant eingestuft. Deswegen beschäftigten wir uns in Session 2 mit diesem Thema. Zuerst wurde festgestellt, dass es gewollte und ungewollte Änderungen am System gibt. Gewollte Änderungen sind planbar und können somit gut nachvollzogen werden, z. B. durch Test-Cases, Use-Cases und Misuse-Cases, durch das Implementieren von interdisziplinären Teams und eine ausreichend gute Definition des System Engineering Systems. Als gutes Beispiel für interdisziplinäre, agil arbeitende Teams wurde Wikispeed genannt. Ungewollte Änderung sind nicht planbar und müssen somit beherrschbar gemacht werden, um die Auswirkungen auf Prozesse und technische Komponenten sichtbar zu machen. Eine wichtige Vorbereitung darauf ist die Anpassung der Infrastruktur des Unternehmens. Auch sollten die Möglichkeiten zur Traceability genutzt werden und ein gutes Stakeholder-Management aufgebaut werden.

Um die Änderungen handhaben zu können, ist das A&O, zu Beginn eines Projektes Anforderungen aufzunehmen und zu validieren und verifizieren. Eine Änderung kann sich auf verschiedene Systeme des Unternehmens auswirken – auf technisch-physikalische oder organisatorische Systeme.

Session 3 – Entwurfstechniken des Systems Engineerings

In der Session 3 wurden Entwurfstechniken für System Modelle diskutiert. Es bestand bei den Teilnehmern der Wunsch nach einem Baukasten für Modelle mit bewährten Lösungsansätzen. Eine gute Möglichkeit solche Pattern zu visualisieren und in dem Unternehmen zu etablieren sind Poster, auf denen die Baukasten-Bestandteile gesammelt werden. Ein wichtiger Aspekt war es, dass die Modelle nicht nur in den Tools (z.B. Enterprise Architect) bleiben dürfen, sondern als Ausdruck auf die Wände gehören.

Modelle raus aus den Tools und rauf auf die Wände (SE Camp Erlangen) Twittern

Modelle sind kein Selbstzweck und am besten, wenn Sie im Team entstehen und vom Team genutzt werden. Es gibt dazu auch Methodiken den Kunden einzubinden, ohne dass dieser einen SysML-Hintergrundwissen benötigt.

Es wurde aber auch festgestellt, dass ausführliche Modelle eine Gefahr beinhalten. Der Architekt verliebt sich in seine Architektur und empfindet den Kunden oder die Entwickler als Störgröße, wenn diese Änderungen vorbringen, die die Architektur betreffen. Die Gefahr besteht darin, dass das Modell als die “Wahrheit” angesehen wird und ungern hinterfragt wird.

Diskutiert wurde auch der Zusammenhang von Architektur und Agilität. Insbesondere bei agilen Projekten ist die Architektur sehr wichtig. Denn auch bei einem agilen Vorgehen muss man sicherstellen, dass sich die Architektur möglichst nicht ändert. Denn dann beginnt man in der Entwicklung ggf. von vorne (z.B. Flugzeug statt Auto). Daher ist es wichtig, dass sich die Architektur mit den Aspekten befasst, die nur schwer wieder geändert werden können.

In der Session gab es zwei Literaturempfehlungen:

• Design It!: From Programmer to Software Architect von Michael Keeling
• arc42 in Aktion: Praktische Tipps zur Architekturdokumentation von Gernot Starke und Peter Hruschka

Das Feedback der Teilnehmer

Das Feedback der Teilnehmer wurde mit Hilfe eines Starfish Diagramms eingesammelt.