Das Systems Engineering als interdisziplinärer Ansatz zur Entwicklung komplexer Systeme gewinnt immer mehr an Bedeutung. Die steigende Anzahl an Entwicklungsprojekten von komplexen und sehr unterschiedlichen, technischen Systemen bei zugleich immer kürzer werdenden Time-to-Market-Zeiten stellt Organisationen, insbesondere im Zeitalter der Globalisierung, vor immer größere Herausforderungen. Der Systems Engineer als eine zentrale Projektrolle, der das ganzheitliche Systemdenken beherrscht und für das System quasi “von der Wiege bis zur Bahre” verantwortlich ist, wird daher in der Industrie immer stärker nachgefragt.

Schaute man sich jedoch hierzulande nach entsprechenden Studiengängen oder Weiterbildungen zum Systems Engineer um, so war das Angebot bislang ausgesprochen gering. Das hat auch die Gesellschaft für Systems Engineering e.V. (GfSE), das deutsche Chapter des internationalen Dachverbands INCOSE, erkannt und daher vor zwei Jahren beschlossen, zusammen mit dem TÜV Rheinland das berufsbegleitende Weiterbildungsprogramm SE-ZERT ins Leben zu rufen. Am vergangenen Montag war es dann soweit: der deutschlandweit erste Vorbereitungskurs zum Certified Systems Engineer GfSE – Level C startete in unserem Hamburger Trainingscenter und war sogleich gut besucht. Ich bin ebenfalls als Teilnehmer dabei.

Der Level C “Systems Engineering verstehen” ist die erste Stufe des dreistufigen Zertifizierungsprogramms indem es darum geht, Systems Engineering in der Theorie zu erlernen und anhand von Fallstudien zu verstehen. Für den Level C müssen die Teilnehmer insgesamt 12 Schulungstage besuchen, diese sind aufgeteilt auf vier dreitägige Blöcke. Der 13. Tag ist der Prüfungstag, an dem die Teilnehmer nach bestandener Prüfung ein Personenzertifikat durch den TÜV Rheinland ausgehändigt bekommen.

Grundlage des Kurses ist die deutsche Übersetzung des INCOSE Systems Engineering Handbuchs, die Norm ISO/IEC 15288 “Systementwicklung – Der Systemlebenszyklus und seine Prozesse” sowie weitere, relevante Normen und Standards. Anhand eines durchgängigen Fallbeispiels, bei dem es um ein Start-Up-Unternehmen geht welches eine innovative Waschmaschine auf den Markt bringen möchte, können die Teilnehmer das Erlernte in Form von Übungen gleich praktisch ausprobieren. Da auch die soziale Kompetenz für einen Systems Engineer von hoher Bedeutung ist, ist eines der Module dem Thema Soft-Skills gewidmet.

Alle Teilnehmer haben zum Abschluß des ersten Blocks ein durchweg positives Feedback abgegeben. Selbst bei den eher trockenen Themen, wie den übergreifenden Schnittstellen, ist es den Trainern Axel Scheithauer und Dr. David Endler, freiberuflicher Systems Engineering Consultant und Partner von oose, gelungen, diese in äußerst interessanter Art und Weise zu vermitteln und durch Übungen aufzulockern. Das Finale des ersten Blocks hat heute unser Trainer Uwe Vigenschow bestritten, indem er uns auf eine sehr unterhaltsame wie auch interessante Reise durch die Grundlagen der Kommunikation, wertschätzender Feedbacks und den Code of Ethics mitgenommen hat.

In ca. einem Monat geht es dann mit dem nächsten Block und den Themen Projektmanagement und Anforderungsmanagement weiter.

Letzte Woche habe ich auf dem ESE-Kongress den Vortrag “Hart, aber agil – Agilität trotz starrer Rahmenbedingungen” gehalten. Ich war erfreut über die zahlreichen Teilnehmer und gespannt auf ihre Reaktion zu diesem Thema. Nach dem Vortrag konnte ich spannende Diskussionen zu meinen Themen führen:

• Wie geht Agilität in der Systementwicklung, wenn ein Großteil des Projekts in der Maschinenbau-Disziplin liegt?
• Wie kann agiles Vorgehen im Kontext von FDA-Audits durchgeführt werden?
• Wie kann ich agil Nicht-Software entwickeln?

Ich finde das Thema “Agilität in Nicht-Softwareprojekten” insbesondere daher spannend, da die trendigen agilen Vorgehen wie Scrum und Kanban aus diesen Bereichen stammen. Beispielsweise ist Scrum ein Vorgehen aus der Produktentwicklung von 1986 und ist in den neunziger Jahren für die IT u.a. von Ken Schwaber und Mike Beedle angepasst worden.

Auf dem ESE-Kongress konnte ich auch etlichen anderen Vorträgen zuhören: Von Lernmethoden für Erwachsene über Change Management und Gruppendynamik bis hin zu einem Vertriebsseminar. Natürlich gab es auch UML für Embedded, Testen und andere spannende Themen.

Hat Spaß gemacht,
Tim

Letzte Woche war ich auf dem Tag des Systems Engineerings 2010 der GfSE. Ein Highlight war das Social-Event. Wir haben die Brauerei Weihenstephan besichtigt und wurden kompetent vom Braumeister persönlich herumgeführt. Die Fragen aus der Runde an ihn waren disziplinengerecht: Wie sehen die Zulieferketten aus? Wie ist der Lebenszyklus des Bieres? Welche Prozesstechniken werden eingesetzt? Ich war insgesamt erstaunt, wie komplex der Bierbrauprozess gestaltet ist. Eine echte Systems-Engineering-Aufgabe!

Auf der Konferenz habe ich einen Vortrag gemeinsam mit Andreas Korff von Atego über die “Toolgestützte Kombination von Modellierungsnotation und Prozess anhand von SysML und SYSMOD” und einen Vortrag gemeinsam mit Jesko Lamm von Bernafon über “Funktionale Architekturen mit SysML”. Zu beiden Vorträgen habe ich sehr schönes Feedback erhalten und konstruktive Diskussionen geführt.

Sehr schön fand ich, dass das Thema Soft-Skills und Systems-Engineering nun einen festen Platz auf der Konferenz eingenommen hat. Als ich 2007 mit Uwe Vigenschow auf dem TdSE den Vortrag “Wege zu einer erfolgreichen interdisziplinären Kommunikation – SysML ist nur eine Sprache” gehalten habe, war das Thema noch ein Einzelfall.

Insgesamt war der TdSE wieder eine sehr gelungene Veranstaltung. Ein reger Austausch, viele Ideen und Impulse und nette Gespräche. Nächstes Jahr muss ich nicht so weit reisen. Der TdSE findet dann vom 9.-11.11.2011 in Hamburg statt.

Seit vielen Jahren setzen sich agile Vorgehensweisen wie z.B. XP und Scrum immer weiter in der Softwareentwicklung durch. Unsere Projektmanagementstudie zeigt, dass selbst in wasserfallartig durchgeführten Projekten ausgewählte agile Methoden hohen Nutzen bringen. Doch die embedded Software- und Hardwareentwicklung, ganz zu schweigen von der Disziplin Systems Engineering, tut sich nach wie vor schwer, sich die agilen Vorzüge zu Nutze zu machen. Aber warum nur?

Machen nicht gerade die erhöhten Qualitätsansprüche an embedded Software und die damit einhergehenden Constraints wie z.B. Ressourcenknappheit, hohe Anforderungen an Sicherheit und Echtzeit und der oft gewünschte „first time right“ Ansatz es zwingend notwendig, die derzeitigen Entwicklungsmethoden zu überdenken?

Gibt es wirklich keine Möglichkeiten, Hardware iterativ und kostengünstig (weiter) zu entwickeln?
Ich denke da nur an meinen Kollegen Markus Klink, der vorgestern Abend auf seinem Abendvortrag seinen Makerbot vorgestellt hat. Zumindest für die mechanischen „Hardwerker“ eine Option.

Und Rapid Prototyping ist auch keine wirklich neue Erfindung. Ganz zu schweigen von Simulationen oder ausführbaren Modellen, deren Ergebnisse je nach Definition of Done den Projektfortschritt durchaus messbar machen können oder zum Einholen von Kundenfeedback geeignet sind.
Verbauen Sie sich nicht den Weg, sich auch mit den anderen agilen Ideen auseinanderzusetzen, sondern kombinieren Sie diese mit Ihren bewährten Methoden!

Wenn wir so früh genug wissen, dass unsere embedded Software tut was sie soll, haben wir ggf. noch genügend Zeit und Ruhe, uns um die Workarounds für die Hardware zu kümmern

Worauf warten Sie noch? Was sind Ihre Sorgen und Bedenken, wenn Sie über die Einführung agiler Vorgehensweisen in Ihren embedded Softwareprojekten nachdenken?

Mein Vortrag auf der REConf 2011 zum Zickzack-Muster für Anforderungen ist angenommen worden. Das Zickzack-Muster stellt den Zusammenhang zwischen Anforderung und Lösung dar und erklärt, warum Anforderungen nicht lösungsfrei sind.

Ich habe das Muster im Rahmen meiner Systementwicklungsmethodik SYSMOD entwickelt und setze es seit vielen Jahren erfolgreich in Projekten ein. Es ist ein theoretisches Modell, dass immer wieder zu Aha-Effekten führt und viel Transparenz in die praktische Arbeit bringt. Die Kernaussage ist: Jeder Anforderung wohnt eine Annahme inne. D.h., es gibt eigentlich keine lösungsfreien Anforderungen. Die strikte Trennung zwischen dem Was? und dem Wie?, wie sie gerne in der Literatur gefordert wird, muss man viel differenzierter betrachten.

Werfen Sie mal einen Blick auf die Anforderungen in Ihrem Projekt. Sind sie lösungsfrei?

Letzte Woche hatten wir unser Kickoff-Meeting der neuen Arbeitsgruppe mit dem langen Titel “Agiles Projektmanagement für Systeme im reguliertem Umfeld” – kurz APS. Es ist eine Arbeitsgruppe der Gesellschaft für Systems Engineering e.V. (GfSE).

Die Arbeitsgruppe hat primär Mitglieder aus der Medizintechnikbranche. Alles erfahrene Entwickler und Projektmanager, die sich mit der Entwicklung komplexer Systeme (nicht nur Software) und den strengen Regulatorien von Behörden wie beispielsweise der FDA beschäftigen.  Vor uns liegen viele Fragen, die wir beantworten möchten, z.B.

• Welche agilen Techniken funktionen in diesem Umfeld?
• Wie müssen die Techniken angepasst werden?
• Welche Hürden gibt es?
• Welche Hürden sind fachlich begründet und welche sind nur im Kopf?
• Wie führt man agile Techniken in diesen Projekten ein?

Am 9.12. halte ich auf dem ESE-Kongress einen Vortrag, der sich auch mit diesem Thema beschäftigt: Hart, aber agil.

Wenn jemand positive oder negative Erfahrungen zum agilen Projektmanagement im Systementwicklungsbereich gesammelt hat, freue ich mich über einen Austausch: tim.weilkiens@oose.de.

Am Freitag, den 24.9.2010, war ich beim 5. deutschen Model-Based-Systems-Engineering-Anwenderforum (MBSE) der Gesellschaft für Systems Engineering e.V. (GfSE). Standesgemäß fand die Veranstaltung auf dem Airbus-Gelände in Hamburg statt.

Es gab viele spannende Vorträge und vor allem wieder eine tolle ca. 1,5-stündige Abschlußdiskussion. Wenn ich diese Veranstaltung mit den ersten MBSE-Foren (damals hiessen sie noch SysML-Forum) vergleiche, merke ich, dass wir bei dem Thema schon große Fortschritte gemacht haben. MBSE und auch SysML haben sich etabliert und es geht weniger um das Warum? und Was?, sondern mehr um das Wie?.

Was mich ganz besonders freut ist, dass es nicht die Technik ist, die im Mittelpunkt steht, sondern der Mensch. MBSE bedeutet Veränderung. Und diese muß von den Menschen mitgetragen werden. Ohne Überzeugung hilft auch die beste Modellierungssprache oder das beste Tool nichts. Und umgekehrt spielt die Sprache und das Tool nur eine untergeordnete Rolle, wenn die Menschen von MBSE überzeugt sind. Das wurde in der Diskussion deutlich. In diesem Zusammenhang wurde auch das Thema Agilität im Systems Engineering angesprochen.

Unsere MBSE-Arbeitsgruppe der GfSE hat auch Hausaufgaben mit nach Hause genommen. Wir werden uns den Fragen stellen, was eigentlich MBSE genau ist und welche Rolle es im Systems-Engineering spielt.

Wenn Sie mitreden und die Entwicklung von MBSE aktiv mitgestalten wollen, dann setzen Sie sich mit mir in Verbindung. Wir freuen uns über jede neue Meinung und Unterstützung.

Heute habe ich bei oose den ersten Vorbereitungskurs zur neuen OMG-Zertifizierung OMG Certified Systems Modeling Professional (OCSMP) – Model User durchgeführt. Der Prüfung konnten sich die Teilnehmer direkt im Anschluss stellen, da wir im Hause ein Pearson-VUE-Testcenter haben.

Es haben alle bestanden! Herzlichen Glückwunsch.

Das Thema Agilität erfährt im Systems-Engineering-Umfeld zunehmend an Aufmerksamkeit. Insbesondere in einem Umfeld, dass durch harte Regulatorien (z.B. FDA) geprägt ist, ist es schwierig, agile Vorgehensweisen einzuführen.

In der Gesellschaft für Systems Engineering e.V. (GfSE) habe ich nun gemeinsam mit Gerhard Buchholtz, Pro F&E GmbH, die Arbeitsgruppe Agiles Projektmanagement für Systeme im regulierten Umfeld gegründet. Zu den Mitgliedern zählen Vertreter der Industrie, die genau aus diesem Umfeld stammen. Gemeinsam wollen wir unsere Erfahrungen austauschen und Best Practices herausarbeiten. Ich bin sehr gespannt und freue mich auf die Treffen der Arbeitsgruppe.

Das Systems Engineering wird gerne als Metadisziplin bezeichnet, da sie eine Abstraktionsebene über den konkreten Disziplinen wie Software Engineering steht. Ähnlich verhält es sich mit dem Konzept des Meta-Scrums, das eine Ebene über den “normalen” Scrums steht. Meta-Scrum ist die Art und Weise, wie Scrum im Systems Engineering eingeführt werden kann.

Im Meta-Scrum-Team sind jeweils ein Repräsentant der konkreten Entwicklungsdisziplinen, sowie die Rollen Product Owner, Systems Engineer und Systems Tester vertreten. Interessant ist natürlich nun, wie die Backlogs und Sprints der einzelnen Scrum-Teams zusammenspielen.