Das gesamte Konferenzprogramm auf einem Blick? Kein Problem, alle Programminhalte finden Sie hier jetzt auch als praktische PDF-Broschüre ganz bequem zum durchscrollen, downloaden oder ausdrucken:
Zur PDF-Broschüre
Komplexität beherrschbar machen – Ein Denkmodell für Strukturen im Systems Engineering
Eine der größten Herausforderungen im Systems Engineering ist die viel beschworene Beherrschung der Komplexität. Bisher in der Praxis etablierte Ansätze betrachten die Strukturierung von Anforderungen und die Dokumentation der Realisierung durch die entsprechenden Architekturelemente. Aber was ist mit den Testfällen, dem Feature-Tree für Produktvarianten und der Organisationsstruktur? Diese Strukturen gilt es im Rahmen der Systementwicklung angemessen zu berücksichtigen und nachvollziehbar mit anderen Arbeitsergebnissen in Beziehung zu setzen.
Zielpublikum: Entwickler:innen, Architekt:innen, Requirements-Engineers, Systems Engineers
Voraussetzungen: Verständnis zum Zusammenspiel der Entwicklungsdisziplinen
Schwierigkeitsgrad: Experte
Extended Abstract:
Bei der Entwicklung von komplizierten technischen Systemen treffen unterschiedliche Disziplinen wie Anforderungs- und Architekturentwicklung, Test und Abnahme etc. aus verschiedenen Gewerken (Software- und Hardwareentwicklung) aufeinander. Trotz unterschiedlicher Ausrichtungen und Schwerpunkte leisten alle Beteiligten einen Beitrag in Form von Arbeitsergebnissen zum fertigen Produkt. Jedoch unterscheiden sich diese Arbeitsergebnisse häufig in ihrer Darstellung, betrachten aber letztlich doch das gleiche System und stehen dadurch inhaltlich in einem Zusammenhang.
Eine wesentliche Herausforderung ist es, diese Zusammenhänge in den Arbeitsergebnissen (Anforderungen, Architekturdokumentation, Testfälle etc.) transparent zu machen und zu nutzen, um dadurch disziplinen- und gewerkübergreifend eine durchgängige Systementwicklung zu gewährleisten. Für Anforderungen und Architekturdokumentationen haben sich dafür sowohl das Twin-Peaks-Modell als auch das SPES 2020-Framework mit dem RFLP-Ansatz etabliert. Beide Modelle vernachlässigen allerdings weitere Disziplinen der Systementwicklung wie z. B. Integration, Test und Abnahme oder das Produkt- und Portfoliomanagement und verzichten auf eine Betrachtung der dabei erzeugten Arbeitsergebnisse. Und wie sind diese Disziplinen eigentlich in der Organisation verortet? Welche Abteilung oder welches Team leistet welchen Beitrag am Gesamtprodukt?
Ziel dieses Vortrages ist es, ein Denkmodell zu vermitteln, das unterschiedliche, graphen- oder baumartige Strukturen und Sichten miteinander in Beziehung setzt, um dadurch typische Probleme in der Systementwicklung wie z. B. unklare Verantwortlichkeiten transparent zu machen und zu lösen. Anhand eines durchgängigen Beispiels erfahren Sie, welche weiteren Sichten neben den Anforderungen und der Architekturdokumentation auf unterschiedlichen Abstraktionsebenen in der Systementwicklung (System, Subsysteme, Komponenten) sinnvoll sein können. Neben einer Motivation, den Inhalten dieser Sichten und deren Wechselwirkungen erhalten Sie einen Einblick, welche Probleme mithilfe dieses Denkmodells gelöst werden können.
Als Berater und Product Owner ist Alexander Barth schon lange im Thema Requirements Engineering tätig. Die Lösungen für den Automotive, Fashion und Sport Bereich beinhalteten immer auch Systeme, die den Workflow der Nutzer:innen unterstützen, Prozesse automatisierten und Daten verarbeiteten.
Der Weg zu diesen Lösungen insbesondere in direkter Zusammenarbeit mit den Kunden:innen und den Teams macht ihm sehr viel Spaß: Problem- oder Zielbeschreibung zu erarbeiten und daraus die Anforderungen zu erstellen; technische Lösungen mit dem Entwicklungsteam zu erarbeiten; Präsentation, und Abnahmen von Spezifikationen, Lieferung von Meilensteinen und finalen Lösungen sowie Trainings sind nur ein paar Punkte auf dem Weg zum Ziel.
Die letzten fünf Jahre in der Projektarbeit gingen einher mit der Transformation zu agileren Arbeitsmethoden. Kern dieser Veränderung war zunächst sein kleines Scrum Team. Nach und nach hat er aber auch die verschiedenen Geschäftsteams an die agile Arbeitsweise, Rollen und Werkzeuge herangeführt und trainiert. Neben diesen praktischen Erfahrungen, ist Alexander Barth auch zertifiziert als Product Owner, Scrum Master und Certified Professional for Requirements Engineering - Foundation Level.
