Produktentwicklung

Aktivitäten, Cluster-Ebene, Referenzprozess
hatDefintion-of-Done (allgemein)

Das P4-Dev-Framework gibt es in zwei Ausprägungen. Beide Ausprägungen verwenden iterativ-inkrementelle Methoden und zeitlich stabile Teams:

  1. In seiner Minimalform beschreibt P4-Dev die minimal nötigen Entwicklungstätigkeiten, ohne externe Vorgaben.
  2. In der prozessorientierten Form beschreibt P4-Dev die nötigen Entwicklungstätigkeiten, um den Prozessanforderungen regulierter Prozess zu genügen. Dabei sind die Prozessaktivitäten in das iterativ-inkrmentelle Vorgehensmodell integriert, so dass sie von den Akteuren zum optimalen Zeitpunkt ausgeführt werden. Die Darstellung der Abfolge der „Prozessthemen“ mit ihren Einzelaktivitäten geht dadurch verloren. Die Verbindung der Prozessthemen mit dem Arbeitsprozess erfolgt über das Conformity-Mapping. Zur Übersicht haben wir im unteren Kapitel eine Übersicht erstellt.

Iterativ-inkrementeller Arbeitsprozess

Die Beschreibung einer Produktentwicklung erfolgt hier in stark vereinfachter Form.

Zeitpunkt Normal      zusätzlich, wenn reguliert
Start der Entwicklung 1. Systemfunktionen und -merkmale ermitteln
  • Ableitung und Anpassung des Entwicklungsprozesses
  • Initiale Gefährdungsanalyse
  • Ermittlung der Sicherheitsanforderungen
2. Eine grobe Systemarchitektur & ein grobes Systemkonzept modellieren, einschließlich Test- und Produktionssystemen (möglicherweise sind mehrere Optionen erforderlich)

  • Ergebnis: Komponenten und Schnittstellen
  • Zuordnung der Sicherheitsfunktionen auf Module
  • Risikoanalyse über Architektur und Schnittstellen
3. Ermittlung des Reifegrades von Konzepten, Module und Schnittstellen durch Erfassung von K-Gaps (unbekannte Konzepte, offene Entscheidungen, fehlendes Wissen, Probleme, Fragestellungen)

  • Konsequenzen/Risiken (relative Einschätzung durch PO & Systemteam)
  • Aufwand (Einschätzung durch Produktteam)
  • Risikoanalyse der Module
  • Verifikations- und Validierungsplanung (insbesondere für kritische Funktionen und Module)
Jeden Cycle 4. Planen, erstellen und testen der „Samples“ (Konzepte, Simulationen, Prototypen usw.), um K-Gaps durch Entscheidungen zu schließen

  • Planen der Abhängigkeiten zu Lieferanten und Meilensteine
  • Planung und Durchführung der Integration und Integrationstests
  • Ergebnis: Spezifikationen, Verifizierungspläne und Berichte
  • Planung der Qualitätssicherung bei Lieferanten
  • Ermittlung des Reifegrads des Systems anhand der Produkt-QA&Cs und K-Gaps
Jede Iteration 5. Verfeinern der Ergebnisse zu geeigneten Teamzielen, die in Iterationen passen (im Rahmen des Backlog-Refinement-Meetings)
  • Dokumentation der Verantwortung und Planung auf Team-Ebene
6. Veröffentlichen, wenn das Verhältnis von Risiken und K-Gaps zu Wert und Chancen niedrig genug ist.
  • Risikobewertung anhand der Liste der verbleibenden Abweichungen

Übersicht der Prozessthemen

tbd