System-Konzepte, -Architekturen und -Fähigkeiten

ist einBacklog-Item-Typ
beschreibtSystem-Inkrement
wird eingeschränkt durchQualitätsattribute & Einschränkungen (QA&C)

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.

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 …

Auch Methoden aus dem Methodenwerzeugkasten von Design-for-Six-Sigma (DFSS) können zur Bewertung und Auswahl von Systemkonzepten eingesetzt werden:

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.

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-Sync

Cluster-Backlog-Refinement

Cluster-Review

Cluster-Product-Owner

Cluster-System-Engineer

.

Portfolio-Owner

Portfolio-Architekt

Team-Product-Owner-Gruppe

Team-System-Engineer-Gruppe

Managementkreis des Clusters

.

Cluster-Product-Owner-Gruppe

Cluster-System-Engineer-Gruppe

Managementkreis der Organisation

Inspizierbare-Ergebnisse

Team-DoD

.

Cluster-Backlog

Nutzbares-Wissen & System-Inkrement

Cluster-DoD

.

Portfolio-Backlog

Systeme & Applikationen

System-Plattformen & Varianten

Organisations-DoD