Systemkonzepte beschreiben mögliche Lösungen für System- bzw. Produktvarianten (Applikationen = Feature-Sets) und deren Anforderungen. Systemkonzepte realisieren dabei die System-Anforderungen innerhalb der Einschränkungen (Contraints) und balancieren die Qualitätsanforderungen (Quality Attributes) aus. Das P4-Framework sieht im System-Backlog explizit mehrere Systemkonzepte als Lösungsoptionen für die Umsetzung von Systemanforderungen vor. Dies bedeutet, dass möglicherweise mehrere Lösungen für ein Problem identifiziert und weiterentwickelt werden (Divergenz im Lösungsraum). Ziel der Produktentwicklung ist es, nur so viele unterschiedliche Systemkonzepte zu entwickeln (parallel oder nacheinander), bis einige Konzepte disqualifiziert und sich idealerweise ein klarer Favorit herausstellt. Je nach Innovationsgrad der Entwicklung können dies anfangs sehr viele Konzepte sein, oder es ergeben sich sogar neue Konzepte während der Produktentwicklung.
Systemarchitektur
Der statische Teil von Systemarchitekturen beschreibt die Aufteilung von Funktionen und Fähigkeiten auf Teilsysteme und Module des Systems, sowie deren Schnittstellen. Dies geschieht z.B. durch Nutzung der Blockdiagramme aus der SysML. Im dynamischen Teil wird das Verhalten der Teilsysteme und Module beschrieben, z.B. anhand von Sequenzdiagrammen, Aktivitätsdiagrammen, Diagrammen von Zustandsmaschinen der SysML und UML.
Die beschreibenden Dokumente des Systems (Spezifikationen, Beutzerhandbücher, etc.) werden ebenfalls häufig als „Komponenten“ oder Liefergegenstände behandelt. Dadurch wird gewährleistet, dass die Dokumentation synchron mit dem Funktionsumfang und dem Reifegrad des Systems wächst.
Bewertung und Auswahl von Systemkonzepten
Zur Auswahl von Systemkonzepten und Lösungsalternativen können im P4-Framework Methoden des klassischen Systems-Engineering eingesetzt werden, wie …
- Morphologischer Kasten
- Pugh-Matrix (gewichtete Bewertungstabelle)
- Entscheidungstabelle mit Bewertungskategorien (++/+/0/-/–)
- Balancierte Auslegungsgrafen
- Trade-off-Analysen
- Failure-Mode-and-Effects-Analysis (FMEA)
Auch Methoden aus dem Methodenwerzeugkasten von Design-for-Six-Sigma (DFSS) können zur Bewertung und Auswahl von Systemkonzepten eingesetzt werden:
- Design-Scorecard
- Poka Yoke
- QFD zur Auslegung
- Wirkkettenanalyse
- Statistische Versuchsplanung (Design-of-Experiments, DoE)
Plattformkonzepte
In der heutigen Produktentwicklung hat sich das Konzept der Wiederverwendung und das Denken in Baukästen, Produktlinien und Plattformen stark durchgesetzt. Dies wird im P4-Framework durch den Architekturaspekt dieser Ebene abgebildet. Die Anforderungen an die Plattform sind in den „Quality Attributes & Constraints“ enthalten (z.B. Modularität, Wiederverwendbarkeit, Märkte und Anwendungen).
Die Verantwortung für die Plattformen, ihre Module und Schnittstellen liegen bei den Modul- und Plattform-Teams oder bei größeren Plattformen, bei Modul- und Plattform-Clustern.
Fähigkeiten (Capabilities)
Die Verantwortung des Cluster-System-Engineers ist auch die Verteilung von sogenannten Fähigkeiten (Capabilities) auf Module, die in komplexeren Systemen als Dienste (Services, Micro-Services) beschrieben werden. Der Grundgedanke dabei ist, dass bestimmte Module Fähigkeiten zur Verfügung stellen, die von anderen Modulen genutzt werden können.
.
Passende und weiterführende Artikel:
Events | Rollen | Gruppen | Artefakte |
Cluster-Planning | Cluster-Product-Owner
. |
Team-Product-Owner-Gruppe
. |
Inspizierbare-Ergebnisse
. Nutzbares-Wissen & System-Inkrement . |