Management-Zusammenfassung zu diesem Beitrag:
Design Freeze, Feature Freeze und Code Freeze sind Begriffe, die bei dem Systems oder → Software Engineering dazu verwendet werden, einen Entwicklungsstand so zu belassen, wie er ist und keine Änderungen mehr zu erlauben.
In diesem Beitrag werden die drei Begriffe beschrieben und gegenübergestellt.
Im Systems oder Software Engineering können definierte Entwicklungsstände “eingefroren” werden. Design Freeze, Feature Freeze und Code Freeze bezeichnen solche Zustände (oder auch Zeitpunkte), die typischerweise vorab geplant und durch einen Meilenstein abgebildet werden. Ziel ist es generell, durch diese Freezes einen stabilen Verlauf in der (weiteren) Entwicklung zu erhalten.
1. Einleitung und Grundlagen
Die Begriffe Design, Feature und Code Freeze können wie folgt charakterisiert werden:
- Design Freeze: Beim Design Freeze wird die System- oder → Softwarearchitektur als nicht mehr veränderbar definiert
- Feature Freeze: Nach einem Feature Freeze darf an einer Feature-Spezifikation keine Änderung mehr durchgeführt werden, sodass direkt in die Entwicklung übergegangen werden kann
- Code Freeze: Der Programm-Code darf nach einem Code Freeze nicht mehr verändert werden. Dies dient dazu, Releases für die Freigabe fertigzustellen und einen systematischen → Softwaretest zu ermöglichen
Abbildung 1 zeigt die Beschreibung der drei Begriffe.
Abbildung 1: Design, Feature und Code Freeze in der Übersicht
Generell sind Freezes Verbote von Weiterentwicklungen, die aber benötigt werden, um nächste Schritte bei der Weiterentwicklung zu ermöglichen.
1.1 Andere Freezes
Folgende Freezes sind ebenfalls im Kontext meiner Tätigkeitsfelder (“Projekte, Prozesse und Requirements”) zu finden:
- Spezifikationsfreeze: Bezeichnet einen abgeschlossenen Stand von Requirements, die typischerweise in einem Spezifikationsdokument wie dem → Lastenheft oder dem → Pflichtenheft zusammengefasst werden
- Software Freeze: Ist in der Regel das Gleiche wie der Code Freeze: Die Software darf nicht mehr verändert werden
- → Glossar Freeze: Hierunter wird verstanden, dass Glossarbegriffe nicht mehr verändert werden dürfen, um so im → Requirements Engineering Anforderungen stabil ableiten zu können
- Freeze im → Change Management: Beim Vorgehen nach Lewin wird ein Change-Prozess unterteilt in die Phasen “Unfreezing — Changing — Refreezing”
Auch zu finden sind die Begriffe Definition Freeze, Request Freeze, Resource Freeze, die in diesem Beitrag nicht erläutert werden. Weitere Freezes finden sich in der Wikipedia /#Wiki-Freeze/.
1.2 Freezes im Projektmanagement
Im → Projektmanagement dienen Freezes generell dazu, Stände von Artefakten und Liefergegenständen (Deliverables) zu fixieren. Hierunter fallen auch Planungsstände, die in Baselines übergehen. Wenn Änderungen an Baselines vorgenommen werden sollen, so geschieht dies in der Regel im Änderungsmanagement über → Change Requests.
Wenn man im Projekt Beschaffungsvorgänge hat, so sind Freezes verpflichtend, um Angebote von potenziellen Lieferanten einzuholen.
2. Zeitliche Abfolge
Eine zeitliche Abfolge der drei Freezes ist in Abbildung 2 in Form von Meilensteinen auf einem Zeitstrahl dargestellt.
Abbildung 2: Design, Feature und Code Freeze: Zeitliche Einordnung
Die Darstellung der Abstände der drei Freezes ist in Abbildung 2 zwar gleich, in der Realität können die Zeitabstände aber beliebig sein.
3. Häufige Fragen und Antworten (FAQ) zu den Freezes
Einige Fragen zu den Freezes werden häufig gestellt – diese werden hier wiedergegeben.
- F: Müssen immer Freezes bei Systems- oder Software-Engineering-→ Vorhaben eingesetzt werden?
A: Ja, das ist zumindest ratsam. - F: Schränken Freezes nicht zu sehr die dynamische Entwicklung ein?
A: Wenn man auf Freezes verzichtet und entsprechend späte Veränderungen zulässt, so können die Kosten der Entwicklung dramatisch ansteigen. Dies zu abzuwägen: Wenn das Risiko der Verteuerungen und Verzögerungen getragen werden kann, so können Freezes eingeschränkt werden. - F: Braucht man bei agilem Vorgehen Freezes?
A: Generell wird das agile Vorgehen dazu, Änderungen möglichst lange zu erlauben, also nach Möglichkeit Freezes so spät wie möglich durchzuführen. Dennoch wird man in der Praxis um Freezes nicht ganz herumkommen.
Haben Sie noch weitere Fragen oder möchten Sie Ergänzungen an der FAQ vornehmen? Am besten schreiben Sie mir hierzu eine E‑Mail an: kontakt@peterjohann-consulting.de.
A. Präsentationen, Literatur und Weblinks
A.1 Meine öffentliche Präsentationen
- -
A.2 Literatur
- /Ludewig23/ Jochen Ludewig, Horst Lichter: Software Engineering. Grundlagen, Menschen, Prozesse, Techniken, dpunkt, Heidelberg 4. Auflage 2022, ISBN 978–3‑86490–598‑8
- /Sommerville20/ Ian Sommerville: Modernes Software-Engineering: Entwurf und Entwicklung von Softwareprodukten, Pearson Studium, München 2020, ISBN 978–3‑86894–396‑2
A.3 Weblinks
Folgende Weblinks liefern Informationen zu den Freezes im Systems oder Software Engineering:
- /#Wiki-Freeze/ Freeze in der deutschen Wikipedia
Legende zu den Weblinks
/ / Verweis auf eine Website (generell)
/*/ Verweis auf eine Website, die als Buch-Ergänzung dient
/#/ Verweis auf einzelnes Thema auf einer Website
/#V/ Verweis auf ein Video auf einer Website
Letzte Aktualisierung: 14.03.2023 © Peterjohann Consulting, 2005–2023
