Kennen Sie das? Sie verpassen regelmäßig Release Termine. Ihre Entwickler klagen über die endlosen Meetings: Abstimmungen, Statusupdates, Lösungsfindung, Klärung der Umsetzung bestimmter Funktionen. Und trotz der vielen Meetings weiß der Entwickler am Ende nicht, was genau entwickelt werden soll. Die Folge: es kommt immer wieder zu Designänderungen, weil nicht das entwickelt wurde, was die Stakeholder wirklich benötigen.
Eins ist sicher, damit sind Sie sind nicht allein, denn:
- Ingenieure verbringen beinahe 30 % ihrer Arbeitszeit in Meetings (vgl. Clockwise 2022).
- Trotz der vielen Meetings, welche alle Fragen klären müssten, wird als einer der Hauptfaktoren für scheiternde Projekte ein mangelhaftes Anforderungsmanagement genannt (vgl. Standish Group 2015)
Produktentwicklung ist und war nie einfach und wird es auch in Zukunft nicht werden – im Gegenteil: Mit der fortschreitenden Digitalisierung und Vernetzung von Produkten steigt die Komplexität der zu entwickelnde Produkte. Eine reibungslose Abstimmung von der steigenden Anzahl an der Entwicklung beteiligten Disziplinen ist dabei notwendig, kostet aber gleichzeitig wertvolle Entwicklerzeit.
Wie gelingt also der Spagat zwischen weniger Meetings und mehr Klarheit über Anforderungen und Entwicklungsfortschritt, um die Produktentwicklung effizienter zu gestalten und Produkte schneller auf dem Markt zu bringen?
Eine Lösung kann Systems Engineering sein. Richtig umgesetzt reduziert es Meeting-Marathons, minimiert Fehlentwicklungen und sorgt für eine effizientere Produktentwicklung. Hierzu braucht es aus unserer Sicht im Wesentlichen zwei Dinge:
-
- Einen modellbasierten Ansatz mithilfe einer Application Lifecycle Management (ALM-) Software: Modellbasiertes Systems Engineering (MBSE)
- Ein methodisch konsistentes Vorgehen welches sich an den Funktionen des geplanten Systems orientiert: Funktionsorientiertes Systems Engineering
Systems Engineering … aber modellbasiert?
Systems Engineering ist ein interdisziplinärer Ansatz zur erfolgreichen Entwicklung und Management komplexer Systeme und in der ISO 15288 standardisiert. Durch den Einsatz verschiedener technischer, organisatorischer und analytischer Prozesse ermöglicht es die Spezifikation, Verifikation und Validierung komplexer Systeme. Durch Schaffung eines disziplinübergreifenden Verständnisses des Entwicklungsproblems bei allen an der Entwicklung beteiligten Parteien wird das Risiko von Fehlentwicklungen und daraus häufig folgende Designänderungen reduziert – Resultat: Die Qualität steigt und Entwicklungszeit sinkt.
Das klassische, dokumentenzentrierte Vorgehen im Systems Engineering, bei dem Textverarbeitungs- und Tabellenkalkulationsprogramme eingesetzt werden, führt jedoch zu veralteten Spezifikationen, mühsamen Änderungen in verschiedenen Dokumenten und Inkonsistenzen. Das kostet Zeit, erhöht den Abstimmungsaufwand und steigert das Risiko für Fehlentwicklungen, was die Qualität senkt, und die Entwicklungszeit verlängert.
Die Lösung ist ALM-Software mit MBSE-Fähigkeiten. Statt einzelnen Dokumenten wird ein digitales Systemmodell als zentrale Plattform verwendet, um Entwicklungsartefakte wie Anforderungen, Funktionen und Systemkomponenten konsistent zu verknüpfen und jederzeit aktuell abzurufen – eine Eigenschaft, die als Traceability bekannt ist. Dies fördert die Kollaboration, da alle Beteiligten auf denselben aktuellen Stand zugreifen können. Zusätzlich können Diagramme erstellt werden, um z.B. Systemfunktionen eindeutig zu spezifizieren. MBSE bedeutet dabei nicht zwingend die ausschließliche Nutzung einer Modell-Syntax wie SysML, sondern kann auch eine Mischung aus textuellen Artefakten und Diagrammen umfassen.
Große Unternehmen aus den Branchen Automotive sowie Luft- und Raumfahrt wenden bereits MBSE erfolgreich in der Entwicklung an oder befinden sich in der Einführungsphase.
Neben der digitalen Abbildung der Entwicklungsartefakte in einem Tool braucht es noch ein methodisches Vorgehen. Sowohl auf Seiten der Industrieunternehmen als auch ALM-Software Hersteller wurden bereits verschiedene Methoden zur Systemmodellierung entwickelt, z.B. die Methoden. Der Kern dieser Methoden besteht in der modellbasierten Dekomposition des Systems aus den Perspektiven-Anforderungen, Verhalten (Funktionen) und Struktur (logisch und physisch) – oftmals als RFLP-Ansatz (Requirement, Functional, Logical, Physical Viewpoint) bezeichnet sowie die digitale Verlinkung.
Warum genau funktionsorientiertes Systems Engineering?
Im Systems Engineering ist die Funktionsperspektive entscheidend, da hinter den Anforderungen der Stakeholder oft Funktionen stehen, die das System erfüllen muss. Funktionen ermöglichen eine lösungsneutrale Betrachtung und bieten Raum für die Bewertung alternativer Lösungen. Auf dieser Basis können erforderliche Systemkomponenten festgelegt werden.
Durch das Betrachten von Systemfunktionen als Entwicklungsauftrag (z.B. als Aufgabenpaket, Epic oder Story) und das Herunterbrechen der Systemfunktionen in Teilfunktionen sowie deren Zuordnung auf die Systemkomponenten (Allokation) können Teilaufträge für die jeweiligen Komponenten-Entwickler zur Implementierung der Funktion erstellt werden. Dies ermöglicht eine stärkere Parallelisierung in der Entwicklung und erzeugt Geschwindigkeit. Funktionen bestimmen auch den Austausch von Daten, Material und Energie zwischen Systemkomponenten und externen Systemen, was für die Definition von Schnittstellen essenziell ist.
Die Verknüpfung von Funktionen mit Anforderungen und Diagrammen in der ALM-Software sorgt für klare Spezifikationen, was das Risiko von Fehlentwicklungen und Änderungen minimiert. Ein modellbasiertes Vorgehen mit SysML wie in den weiter oben genannten Methoden ist für viele Unternehmen eine große Umstellung. Das hier vorgeschlagene fünfstufige Verfahren bietet eine weniger streng an SysML ausgerichtete, modellbasierte und funktionsorientierte Methode, die Prozesse wie Anforderungs-, Test- und Projektmanagement miteinander verknüpft und die Zusammenarbeit fördert.
Systems Engineering – modell- und funktionsorientiert in 5 Schritten
Die untenstehende Abbildung fasst ein mögliches Fünf-Schritt Vorgehen zusammen:
Schritt 1: Stakeholder und Kontextanalyse
Zunächst werden in der Stakeholder- und Kontextanalyse Anforderungen, Use Cases und Randbedingungen des Systems aus Sicht der unterschiedlichen Stakeholder erhoben. Das System wird dabei als Blackbox betrachtet. Sie sind Input der funktionalen Analyse auf Systemebene.
Schritt 2: Funktionale Analyse
In der funktionalen Analyse werden aus Schritt 1 identifizierte Use Cases und Anforderungen durch Aktivitätsdiagrammen verfeinert. Resultat auf Systemebene sind die notwendigen Systemfunktionen zur Realisierung der Stakeholder-Anforderungen. Die Systemfunktionen werden auf Komponentenebene in Teilfunktionen heruntergebrochen und deren Hierarchische Beziehung festgelegt und durch Anforderungen näher spezifiziert.
Schritt 3: Strukturelle Analyse
Nach der funktionalen Analyse werden die notwendigen Systemkomponenten zur Realisierung der Systemfunktionen definiert und ihre hierarchische Beziehung festgelegt. Die Blackbox wird zu einer Whitebox.
Schritt 4: Funktionale Komponenten-Allokation & Schnittstellenspezifizierung
Nachdem die Funktionen und Komponenten definiert sind, kommt die wichtige Architekturentscheidung, welche Funktion in welcher Komponente abgebildet werden soll, hier als Funktions-Allokation bezeichnet. Eine Funktion ist eine Umwandlung (Transformation) von Inputs (z.B. Energie) zu Outputs (z.B. Kraft, Bewegung). Mit der Funktions-Allokation auf eine Komponente ist klar welche Inputs und welche Outputs eine Komponente (mit ihrer inhärenten Funktion) benötigt bzw. erzeugt. Dies ist die Basis für die Schnittstellenspezifikation.
Schritt 5: Umsetzungsplanung (Tests und Releases)
Die spezifizierten Funktionen und Komponenten sowie die Allokation der Funktionen auf die Komponenten erlauben im fünften Schritt die Planung von Tests und Releases zur Sicherstellung der Einhaltung geforderter Termine und Qualität. Durch die klare Schnittstellendefinition ist es nun möglich Anforderungen und Arbeitsaufträge gut abzugrenzen und den verschiedenen Komponenten Teams zuzuweisen. Außerdem sind die Anforderungen die Grundlage für die Erstellung der Testspezifikation der Tester. Durch Dashboard und Reporting Funktionen der ALM – Software lässt sich transparent einsehen, welche Aufträge für ein Release bearbeitet werden und in welchen Bearbeitungszustand diese sich befinden.
Die Schritte der Methode können iterativ durchlaufen werden, da Erkenntnisse aus späteren Schritten Auswirkungen auf vorherige Schritte haben können. Die Schritte zwei, drei und vier sollten so oft durchlaufen werden, bis das System strukturell und funktional ausreichend heruntergebrochen und spezifiziert ist, so dass der Entwicklungsauftrag zur Implementierung der Funktion durch einen Entwickler, Entwicklerteam oder einem Zulieferer festgelegt werden kann. Dieser wird mit den zur Implementierung notwendigen Spezifikationsdaten verlinkt.
Fazit
Modelbasiertes Systems Engineering mit einem funktionsorientierten Vorgehen reduziert Fehler und minimiert den Abstimmungsaufwand in der Produktentwicklung – und steigert so maßgeblich die Entwicklungseffizienz.
Ein zentrales, digitales Systemmodell dient dabei als Single Source of Truth und schafft Konsistenz, Transparenz und eine nahtlose Zusammenarbeit über alle Disziplinen hinweg. Durch den Einsatz grafischer Diagramme werden Systemfunktionen klarer spezifiziert und damit Missverständnisse reduziert. Durch digitale Verlinkung sind Anforderungen, Funktionen und Testfälle nahtlos und nachvollziehbar miteinander verknüpft – so gehört das Rätselraten über gültige Spezifikationen der Vergangenheit an.
Die 5 Schritte der Methode geben Ihnen einen Vorgehensmodell – aber wie setzen Sie die Methode toolunterstützt um?
In unserem Whitepaper erfahren Sie anhand eines konkreten Praxisbeispiels, wie die 5 Schritte der Methode in der ALM – Software objectiF RPM umgesetzt werden können.