Fortlaufende Änderung ohne erneute Erstvorbereitung
Sobald ein Produkt über eine freigegebene technische Grundlage, gepflegte Spezifikationen und eine bekannte Gestaltungsrichtung verfügt, kann die weitere Entwicklung einem kürzeren Zyklus folgen. Der Product Engineer bleibt für Änderungen innerhalb eines begrenzten Anwendungsportfolios verantwortlich.
Phase 1. Erweiterung von Spezifikation und Implementierung
Der Product Engineer erfasst die gewünschte Änderung, klärt deren Auswirkungen auf Benutzer und bestehendes Verhalten und aktualisiert oder ergänzt Funktionsspezifikationen. Der Coding-Agent implementiert die vereinbarte Änderung innerhalb der bestehenden Projektanweisungen, freigegebenen Bibliotheken und Architektur. Der Product Engineer prüft das Ergebnis und iteriert bei Bedarf.
Korrekturen, die das vorgesehene Benutzererlebnis ändern, müssen im Spezifikationsbestand abgebildet werden. Wartung ohne Verhaltensauswirkung erfordert weiterhin angemessene Qualitätsprüfungen, sollte jedoch nicht als neue fachliche Funktion dargestellt werden.
Phase 2. Unabhängiges spezifikationsbasiertes Testen
Ein gesonderter Verifikationskontext untersucht relevante eingecheckte Spezifikationen, leitet Tests ab und prüft die geänderte Anwendung. Er sollte die Änderung und wesentliche Regressionsrisiken angrenzenden Verhaltens abdecken. Befunde werden behoben oder ausdrücklich behandelt; geändertes Verhalten wird erneut getestet.
Phase 3. Architektenprüfung nach Bedarf
Der Architekt prüft Änderungen, die Risiko- oder Richtlinienschwellen der Organisation erreichen. Beispiele sind neue Integrationen, Berechtigungsänderungen, wesentliche Architekturänderungen oder Änderungen gemeinsamer Unternehmensbibliotheken. Routineanpassungen innerhalb freigegebener Muster können weniger Prüfung erfordern. Der Product Engineer verzichtet nicht nach persönlichem Ermessen auf verpflichtende Prüfungen.
Phase 4. UAT
Fachliche Stakeholder nehmen die Abnahme nach den bestehenden Praktiken der Organisation vor. Der Product Engineer koordiniert Probleme und erfasst akzeptiertes Verhalten in den gepflegten Spezifikationen. Release und Betrieb liegen weiterhin außerhalb des SHAPE-Entwicklungszyklus.
Wann der kurze Zyklus nicht ausreicht
Eine grundlegende Neugestaltung, eine neue Systemgrenze oder eine wesentliche Änderung der Sicherheitsverantwortung kann zusätzliche Discovery, UX-Arbeit, Vorbereitung und Prüfung ähnlich Zyklus 1 rechtfertigen. Das Framework soll unnötige Wiederholung vermeiden, keine realen technischen oder geschäftlichen Risiken ignorieren.