Design Freeze, Feature Freeze und Code Freeze Änderungen ab einem definierten Entwicklungsstand verbieten

Manage­ment-Zusam­men­fas­sung die­ses Bei­trags:
Design Free­ze, → Fea­ture Free­ze und Code Free­ze sind Begrif­fe, die im Sys­tems oder → Soft­ware Engi­nee­ring dazu ver­wen­det wer­den, um einen Ent­wick­lungs­stand so zu belas­sen, wie er ist und kei­ne Ände­run­gen mehr zu erlau­ben.
In die­sem Bei­trag wer­den die drei Begrif­fe beschrie­ben und gegenübergestellt.

Im Sys­tems oder Soft­ware Engi­nee­ring kön­nen defi­nier­te Ent­wick­lungs­stän­de “ein­ge­fro­ren” wer­den. Design Free­ze, Fea­ture Free­ze und Code Free­ze bezeich­nen sol­che Zustän­de (oder auch Zeit­punk­te), die typi­scher­wei­se vor­ab geplant und durch einen Mei­len­stein abge­bil­det wer­den. Ziel ist es gene­rell, durch die­se Free­zes einen sta­bi­len Ver­lauf in der (wei­te­ren) Ent­wick­lung zu erreichen.

1. Einleitung und Grundlagen

Die Begrif­fe Design, Fea­ture und Code Free­ze bei der → Soft­ware­ent­wick­lung / Pro­gram­mie­rung las­sen sich wie folgt charakterisieren:

  • Design Free­ze: Bei einem Design Free­ze wird die Sys­tem- oder → Soft­ware­ar­chi­tek­tur als nicht mehr ver­än­der­bar definiert
  • Fea­ture Free­ze: Nach einem Fea­ture Free­ze darf an einer Fea­ture-Spe­zi­fi­ka­ti­on kei­ne Ände­rung mehr durch­ge­führt wer­den, sodass direkt in die Umset­zung / Codie­rung über­ge­gan­gen wer­den kann
  • Code Free­ze: Der Pro­gramm-Code darf nach einem Code Free­ze nicht mehr ver­än­dert wer­den. Dies dient dazu, Releases für die Frei­ga­be fer­tig­zu­stel­len und einen sys­te­ma­ti­schen → Soft­ware­test (mit Inte­gra­ti­ons- und Sys­tem­test) zu ermöglichen

Abbil­dung 1.1 zeigt die Beschrei­bung der drei Begriffe. 

Design, Feature und Code Freeze in der Übersicht, (C) Peterjohann Consulting, 2022-2024

Abbil­dung 1.1: Design, Fea­ture und Code Free­ze in der Übersicht

Gene­rell sind Free­zes Ver­bo­te von spe­zi­fi­schen Wei­ter­ent­wick­lungs­tä­tig­kei­ten an ein­zel­nen Ver­sio­nen. Die­se Ver­bo­te wer­den aber benö­tigt, um nächs­te Schrit­te bei der Wei­ter­ent­wick­lung zu ermög­li­chen, so bei­spiels­wei­se um spe­zi­fi­zier­te Fea­tures als Code imple­men­tie­ren zu können.

1.1 Andere Freezes

Fol­gen­de Free­zes sind eben­falls im Kon­text mei­ner Tätig­keits­fel­der (“Pro­jek­te, Pro­zes­se und Requi­re­ments”) zu finden:

  • Spe­zi­fi­ka­ti­ons­free­ze: Bezeich­net einen abge­schlos­se­nen Stand von Requi­re­ments, die typi­scher­wei­se in einem Spe­zi­fi­ka­ti­ons­do­ku­ment wie dem → Las­ten­heft oder dem → Pflich­ten­heft zusam­men­ge­fasst werden
  • Soft­ware Free­ze: Ist in der Regel das Glei­che wie der Code Free­ze: Die Soft­ware darf nicht mehr ver­än­dert werden
  • String Free­ze: Die Strings (zur Beschrif­tung von Bedien­ober­flä­chen) dür­fen nicht mehr ver­än­dert wer­den. Dies ist ins­be­son­de­re bei Soft­ware­sys­te­men rele­vant, die mehr­spra­chig sind, da Zei­ten für Über­set­zun­gen ein­ge­plant wer­den müssen
  • → Glos­sar Free­ze: Hier­un­ter wird ver­stan­den, dass Gloss­ar­be­grif­fe nicht mehr ver­än­dert wer­den dür­fen, umso im → Requi­re­ments Engi­nee­ring Anfor­de­run­gen sta­bil ablei­ten zu können
  • Free­ze im → Chan­ge Manage­ment: Beim Vor­ge­hen nach Lewin wird ein Chan­ge-Pro­zess unter­teilt in die Pha­sen “Unfree­zing — Chan­ging — Refreezing”

Auch zu fin­den sind die Begrif­fe Defi­ni­ti­on Free­ze, Request Free­ze, Resour­ce Free­ze, die in die­sem Bei­trag nicht erläu­tert wer­den. Wei­te­re Free­zes fin­den sich in der Wiki­pe­dia /#Wiki-Freeze/.

1.2 Freezes im Projektmanagement

Im → Pro­jekt­ma­nage­ment die­nen Free­zes gene­rell dazu, Stän­de von Arte­fak­ten und Lie­fer­ge­gen­stän­den (Deli­ver­a­bles) zu fixie­ren. Hier­un­ter fal­len auch Pla­nungs­stän­de, die in Base­lines über­ge­hen. Wenn Ände­run­gen an Base­lines vor­ge­nom­men wer­den sol­len, so geschieht dies in der Regel im Ände­rungs­ma­nage­ment über → Chan­ge Requests.

Wenn man im Pro­jekt Beschaf­fungs­vor­gän­ge hat, so sind Free­zes ver­pflich­tend, um Ange­bo­te von poten­zi­el­len Lie­fe­ran­ten einzuholen.

2. Requirements Freezes und Code Freezes

Design und Fea­ture Free­ze kön­nen sich auf Requi­re­ments oder auf pro­gram­mier­ten Code bezie­hen. Dies muss unter­schie­den wer­den, auch wenn die Begrif­fe eng mit­ein­an­der ver­bun­den sind.

3. Zeitliche Abfolge bei den Code Freezes

Design und Fea­ture Free­ze kön­nen sich auf Spe­zi­fi­ka­tio­nen oder auf pro­gram­mier­ten Code bezie­hen. In die­sem Kapi­tel sind die drei Free­zes auf den Pro­gramm­code bezogen.

Eine zeit­li­che Abfol­ge der drei Free­zes ist in Abbil­dung 3.1 in Form von Mei­len­stei­nen auf einem Zeit­strahl dargestellt.

Design, Feature und Code Freeze: Zeitliche Einordnung, (C) Peterjohann Consulting, 2022-2024

Abbil­dung 3.1: Design, Fea­ture und Code Free­ze: Zeit­li­che Einordnung

Die Dar­stel­lung der Abstän­de der drei Free­zes ist in Abbil­dung 2 zwar gleich, in der Rea­li­tät kön­nen die Zeit­ab­stän­de aber belie­big sein.

Um zu ver­deut­li­chen, dass nach den ein­zel­nen Free­zes an einer neu­en Ver­si­on gear­bei­tet wer­den darf, kann Abbil­dung 3.2 her­an­ge­zo­gen wer­den. Die oran­gen, gestri­chel­ten Pfei­le deu­ten den zeit­li­chen Über­gang zwi­schen zwei Ver­sio­nen mit den ent­spre­chen­den Free­zes an. Wann die Free­zes an der Ver­si­on 2 erfol­gen, ist hier nicht ein­ge­zeich­net / festgelegt.

Design, Feature und Code Freeze: Zeitliche Einordnung bei zwei Versionen, (C) Peterjohann Consulting, 2022-2024

Abbil­dung 3.2: Design, Fea­ture und Code Free­ze: Zeit­li­che Ein­ord­nung bei zwei Versionen

Es ist zu beach­ten, dass der zeit­li­che Abstand zwi­schen zwei Ver­sio­nen genü­gend groß ist, damit → Feh­ler aus den zuge­hö­ri­gen Tests beho­ben wer­den kön­nen. Wird zu eng getak­tet, so kann es sein, dass die Ver­si­on 1 noch nicht fer­tig­ge­stellt ist, obwohl Ver­si­on 2 schon test­be­reit ist. Dies führt zu unge­woll­ten Ressourcenengpässen.

Wenn ein zeit­li­cher Min­dest­ab­stand zwi­schen den Free­zes fest­legt ist, so ergibt sich dar­aus eine (mini­ma­le) Durch­lauf­zeit und damit ein Release­zy­klus (bei Soft­ware­pro­duk­ten). Sind etwa zwei Wochen als Abstand fest­ge­legt, so ergibt sich ein mini­ma­ler Release­zy­klus von acht Wochen, da zwei Wochen Vor­lauf zum Start der Ent­wick­lung und zwei Wochen zur Feh­ler­be­he­bung / Releas­e­frei­ga­be hin­zu­ge­fügt wer­den müs­sen (Abbil­dung 3.4).

Design, Feature und Code Freeze: Zeitliche Einordnung mit Release, (C) Peterjohann Consulting, 2022-2024

Abbil­dung 3.3: Design, Fea­ture und Code Free­ze: Zeit­li­che Ein­ord­nung mit Release

4. Häufige gestellte Fragen und Antworten (FAQ) zu den Freezes

Eini­ge Fra­gen zu den Free­zes wer­den häu­fig gestellt – die­se wer­den hier wiedergegeben.

  • F: Müs­sen Free­zes immer bei Sys­tems- oder Soft­ware-Engi­nee­ring-→ Vor­ha­ben ein­ge­setzt wer­den?
    A: Ja, das ist zumin­dest empfehlenswert.
  • F: Schrän­ken Free­zes die dyna­mi­sche Ent­wick­lung nicht zu sehr ein?
    A: Wenn man auf Free­zes ver­zich­tet und ent­spre­chend spä­te Ände­run­gen zulässt, so kön­nen die Kos­ten der Ent­wick­lung dra­ma­tisch anstei­gen. Dies zu abzu­wä­gen: Wenn das Risi­ko der Ver­teue­run­gen und Ver­zö­ge­run­gen getra­gen wer­den kann, so kön­nen Free­zes ein­ge­schränkt werden.
  • F: Braucht man bei agi­lem Vor­ge­hen Free­zes?
    A: Gene­rell hilft das agi­le Vor­ge­hen dabei, Ände­run­gen mög­lichst lan­ge zu erlau­ben, also nach Mög­lich­keit Free­zes so spät wie mög­lich durch­zu­füh­ren. Den­noch wird man in der Pra­xis nicht ganz ohne Free­zes aus­kom­men, um (abschlie­ßen­de) Sys­tem- oder Abnah­me­tests durchzuführen.

Haben Sie noch wei­te­re Fra­gen oder möch­ten Sie Ergän­zun­gen an der FAQ vor­neh­men? Am bes­ten schrei­ben Sie mir hier­zu eine E‑Mail an: kontakt@peterjohann-consulting.de.

A. Präsentationen, Literatur und Weblinks

A.1 Meine öffentliche Präsentation

  • -

A.2 Literatur

  1. /Ludewig23/ Jochen Lude­wig, Horst Lich­ter: Soft­ware Engi­nee­ring. Grund­la­gen, Men­schen, Pro­zes­se, Tech­ni­ken, dpunkt, Hei­del­berg 4. Auf­la­ge 2022, ISBN 978–3‑86490–598‑8
  2. /Sommerville20/ Ian Som­mer­ville: Moder­nes Soft­ware-Engi­nee­ring: Ent­wurf und Ent­wick­lung von Soft­ware­pro­duk­ten, Pear­son Stu­di­um, Mün­chen 2020, ISBN 978–3‑86894–396‑2

A.3 Weblinks

Fol­gen­de Web­links lie­fern Infor­ma­tio­nen zu den Free­zes im Sys­tems oder Soft­ware Engineering:

  • /#Wiki-Freeze/ Free­ze in der deut­schen Wikipedia

Legen­de zu den Weblinks
/ / Ver­weis auf eine Web­site (all­ge­mein)
/*/ Ver­weis auf eine Web­site, die als Ergän­zung zu einem Buch dient
/#/ Ver­weis auf ein ein­zel­nes The­ma auf einer Website
/#V/ Ver­weis auf ein Video auf einer Website