Lead System Engineer

9-2016 bis 12-2016

• interdisziplinäres System Engineering (Elektronik, Software, Mechanik) für verteiltes Aktuatorensystem
• Moderation der System-Workshops
• Modellierung der Architektur
• Mapping der Requirements zur Architektur
• Support der SCRUM / KANBAN Einführung auf Systemebene

Projektbeschreibung

Nachdem ich mit dem Kunden bereits im Bereich Requirement Engineering mehr Systematik erzielen konnte sollte nun durch System Engineering Methodik der Rahmen für effizientere Produktentwicklungen geschaffen werden. Das RE war mittlerweile gut aufgestellt jedoch fehlte die architekturelle Seite (zumindest formell). Als Pilotprojekt wurde ein verteiltes Aktuatorensystem gewählt. (Elektromechanik, verteilte embedded Elektronik, verteilte Software). Das Projekt stellt eine Innovation am Markt dar. Es wurden im Rahmen des Innovationsmanagement bereits mehrere Konzepte evaluiert. Es fehlte jedoch vor allem an Dokumentation und Übersichtlichkeit. Welche Konzepte passen zu welchen Requirements? Welche Konzepte stehen zueinander in Konflikt? Gibt es überhaupt Requirements die diese Technologie erfordern? Und natürlich starker Preisdruck am

Aufgabenstellung

Als Lead System Architekt die Methodiken aufzeigen wie Requirements, Systemarchitektur, Subsystem-Requirements und Modul-Architekturen ineinander übergehen. Hierbei wurde Wert darauf gelegt nicht die schönste formale Methode oder das beste Tooling einzuführen sondern pragmatische, verständliche Ansätze aufzuzeigen.

Projektablauf

Schritt 1 – Requiremets von Architektur befreien

In den Spezifikationen fanden sich immer noch Architekturentscheidungen und Anforderungen an Lösungen. Dies ist verständlich, da ja keine niedergeschriebene Architektur existierte jedoch den Projektbeteiligten klar war das gewisse Architekturelle Entscheidungen niedergeschrieben werdern müssen.
Deshalb lage es nahe diese Architektrellen Artefakte erstmal aus den Spezifikationen herauszuösen.

Schritt 2 – Architekturdokumentation

Die gewonnen Architekturentscheidungen wurden nun gesondert in Architekturdokumenten niedergeschrieben. Hiebei wurde der Fokus nochmal auf die Ebentrennung (System / Modul / Komponente) gesetzt. Bereits getroffene Entscheidungen wurden dokumentiert und versucht die Verbindung zu den System Requirement herzustellen (Traceability). Zusätzlich wurden grobe Blockdiagramme verwendet um die Systemarchitektur auch grafisch darzustellen. Hierfür wurde einfach der bereits bestehende Diagramm Editor des ALM Tools Polarion verwendet.

Schritt 3 – Einführung von Konzepten

Nach wie vor gab es Requirments für die noch keine Architekturlösung gefunden wurde. Jedoch gab es unzählige Konzepte. Zum Teil nur Ideen, zum Teil bereits technisch evaluiert und einige auch wirtschaftlich durchgerechnet. Es wurde viel probiert. Die Entscheidungen für Lösungen vielen zumeist aus dem Bauch raus durch die Architektenrunde. Es kam jedoch immer mehr vor das wiedersprüchliche Ideen erst später zu Konflikten führten. Das Projekt war schlicht zu komplex um diese Aufgabe einfach so zu bewältigen.
Ich führte deshalb den Archifakt Typ „Konzept“ ein. Dieser sollte standartisiert die Konzeptideen dokumentieren.

Konzept: XYZ	ID: 123
Konzeptowner
Bezug zu Anforderung
Beschreibung der Idee:
Geschätze Kosten:
Technische Machbarkeit / Evaluierung
Tatsächliche Kosten:
In konflikt stehende alternative Lösungen
Alternative Konzepte
Risiko

Tooltechnisch wurde dies wieder einfach in Polarion gelöst. Insbesondere wurde Wert darauf gelegt das die verlinkung zu den Requirement hergestellt wurde. So konnte schnell aufgezeigt werden welche Requirements die kostentreiber oder komplexitätstreiber sind. Welche Requirements können bisher nicht erfüllt werden? Welche Konzepte stehen sich gegenseitig im Weg?

Schirtt 4 – systematische Auflösung der Komplexität

Als Lead Architekt versuchte ich nun mit den anderen Architekten die Konzepte zu bewerten und zu priorisieren. Hier ging es vor allem darum die Evaluierungen durch die einzelnen Fachabteilungen zu koordinieren. Da es in einem Embedded System eben meist nicht nur eine Disziplin betrifft. (Elektronik, Software, Standards, Einkauf, Logisik, Mechanik, Elektromechanik, Marketing, Plasik).
Durch den System Engineering Trick Traceablitiy (alle Konzepte sind mit Anforderungen verlinkt) war es nun möglich diese Komplexität auch übersichtlich grafisch darzustellen. Diese Darstellungsform machte es für die Stakeholder nochmal viel einfacher die wichtigsten Entscheidungen zu priorisieren.

Retrospektive

Einen zusätzlichen externen Lead System Architek einzusetzen war eine kluge Idee. Das eh schon unter Zeitdruck stehende Team wurde so erstmal nicht zusätzlich belastet. System Engineering as a Service könnte man das auch nennen. Jemand der all die Informationsstreams kombiniert, aufbereitet und so plötzlich einen ganz anderen Einblick in das zu entwickelnde System schafft.

Kundenfeedback

Wir hatten noch nie in einem Projekt so schnell eine Übesicht über unsere Ideen und Konzepte. Zum ersten Mal hatten die Requirements auch tatsächliche einen nachvollziehbaren Bezug zu dem was wir entwickeln.