Management-Zusammenfassung dieses Beitrags:
Design Freeze, → Feature Freeze und Code Freeze sind Begriffe, die im Systems oder → Software Engineering dazu verwendet werden, um 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 erreichen.
1. Einleitung und Grundlagen
Die Begriffe Design, Feature und Code Freeze bei der → Softwareentwicklung / Programmierung lassen sich wie folgt charakterisieren:
- Design Freeze: Bei einem 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 Umsetzung / Codierung ü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 (mit Integrations- und Systemtest) zu ermöglichen
Abbildung 1.1 zeigt die Beschreibung der drei Begriffe.
Abbildung 1.1: Design, Feature und Code Freeze in der Übersicht
Generell sind Freezes Verbote von spezifischen Weiterentwicklungstätigkeiten an einzelnen Versionen. Diese Verbote werden aber benötigt, um nächste Schritte bei der Weiterentwicklung zu ermöglichen, so beispielsweise um spezifizierte Features als Code implementieren zu können.
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
- String Freeze: Die Strings (zur Beschriftung von Bedienoberflächen) dürfen nicht mehr verändert werden. Dies ist insbesondere bei Softwaresystemen relevant, die mehrsprachig sind, da Zeiten für Übersetzungen eingeplant werden müssen
- → 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. Requirements Freezes und Code Freezes
Design und Feature Freeze können sich auf Requirements oder auf programmierten Code beziehen. Dies muss unterschieden werden, auch wenn die Begriffe eng miteinander verbunden sind.
3. Zeitliche Abfolge bei den Code Freezes
Design und Feature Freeze können sich auf Spezifikationen oder auf programmierten Code beziehen. In diesem Kapitel sind die drei Freezes auf den Programmcode bezogen.
Eine zeitliche Abfolge der drei Freezes ist in Abbildung 3.1 in Form von Meilensteinen auf einem Zeitstrahl dargestellt.
Abbildung 3.1: 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.
Um zu verdeutlichen, dass nach den einzelnen Freezes an einer neuen Version gearbeitet werden darf, kann Abbildung 3.2 herangezogen werden. Die orangen, gestrichelten Pfeile deuten den zeitlichen Übergang zwischen zwei Versionen mit den entsprechenden Freezes an. Wann die Freezes an der Version 2 erfolgen, ist hier nicht eingezeichnet / festgelegt.
Abbildung 3.2: Design, Feature und Code Freeze: Zeitliche Einordnung bei zwei Versionen
Es ist zu beachten, dass der zeitliche Abstand zwischen zwei Versionen genügend groß ist, damit → Fehler aus den zugehörigen Tests behoben werden können. Wird zu eng getaktet, so kann es sein, dass die Version 1 noch nicht fertiggestellt ist, obwohl Version 2 schon testbereit ist. Dies führt zu ungewollten Ressourcenengpässen.
Wenn ein zeitlicher Mindestabstand zwischen den Freezes festlegt ist, so ergibt sich daraus eine (minimale) Durchlaufzeit und damit ein Releasezyklus (bei Softwareprodukten). Sind etwa zwei Wochen als Abstand festgelegt, so ergibt sich ein minimaler Releasezyklus von acht Wochen, da zwei Wochen Vorlauf zum Start der Entwicklung und zwei Wochen zur Fehlerbehebung / Releasefreigabe hinzugefügt werden müssen (Abbildung 3.4).
Abbildung 3.3: Design, Feature und Code Freeze: Zeitliche Einordnung mit Release
4. Häufig gestellte Fragen und Antworten (FAQ) zu den Freezes
Einige Fragen zu den Freezes werden häufig gestellt – diese werden hier wiedergegeben.
- F: Müssen Freezes immer bei Systems- oder Software-Engineering-→ Vorhaben eingesetzt werden?
A: Ja, das ist zumindest empfehlenswert. - F: Schränken Freezes die dynamische Entwicklung nicht zu sehr ein?
A: Wenn man auf Freezes verzichtet und entsprechend späte Ä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: Wie “hart” müssen Freezes sein? Dürfen sie auch aufgeweicht werden?
A: Normalerweise sind Freezes “hart”, d.h. verbindlich. Manche Autoren schlagen vor, “Slushes” oder “Chills” einzuführen. Dahinter steckt die Idee, doch noch kleinere Änderungen zuzulassen, wenn man sich sicher ist, dass dadurch das übrige Verhalten nicht verändert wird. - F: Braucht man bei agilem Vorgehen Freezes?
A: Generell hilft das agile Vorgehen dabei, Ä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 nicht ganz ohne Freezes auskommen, um (abschließende) System- oder Abnahmetests durchzuführen.
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äsentation
- -
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 (allgemein)
/*/ Verweis auf eine Website, die als Ergänzung zu einem Buch dient
/#/ Verweis auf ein einzelnes Thema auf einer Website
/#V/ Verweis auf ein Video auf einer Website
Letzte Aktualisierung: 14.03.2023 © Peterjohann Consulting, 2005–2025
