by John J. Popovic

Three Freezes: REQUIREMENTS, Design and Code Freezes
-----------------------
Requirements freeze
-----------------------
In some big software as a service solutions the needs of the business almost always prevail over the development team's concerns and convenience about how they'll do their work.

Requirements freezes usually don't work because they don't address the real causes of creep, which are:
(1) project budgets and schedules routinely are set in stone without meaningful documentation regarding the work that needs to be accomplished;
(2) people misunderstand what scope really is and thus define it in ways that cannot help but creep, or even gallop; and
(3) most creep is actually not new or changed requirements but rather new or changed awareness of requirements that have been there all along but haven't been identified adequately.
(4) road-map is to vague, time plan is too tight, and development schedule is frustratingly risky

On the other hand when you work for the customer then Requirements freeze is not optional it is COMPULSORY.

A major reason estimates and requirements are often wrong is related to common misunderstanding of what scope is. Most project scope statements are not scope at all but rather merely objectives or even wishes or hopes.

The first step toward developing accurate and complete specifications is to establish correct requirements. As easy as this sounds, establishing correct requirements is extremely difficult and is more of an art than a science.
------------------------------------
Mockup of production data sets
------------------------------------
One of the biggest requirements issues is "lack of testability," which is largely due to unclear or ambiguous requirements. When a software requirement specification is unclear, software to meet it is likely to be designed and developed incorrectly; and tests to confirm that the code meets the unclear requirements also are likely to be wrong. It is important in this stage to obtain input data sets which produces expected output, and also corrupted data sets which produce expected errors.
Write positive and negative tests that demonstrate whether the code works as it should to satisfy the requirements as you interpret them. If your interpretation is correct, your tests are all set. Without this data sets and test cases requirements freeze can not be accomplished successfully.

..............................................................................
Frozen requirements, Frozen design and Code freeze
..............................................................................
Three common types of freezes are:

- A complete requirements freeze, in which all work on adding new requirements or refining old is suspended, shifting the effort towards fixing design specifications and improving the requirement definition.

- A (complete) feature freeze, in which all work on adding new features is suspended, shifting the effort towards fixing bugs and improving the user experience. The term "Feature Complete" means all the features are coded and functional, but we're heading into a QA stage to confirm that there are no bugs. ALPHA version code contains all intended functionality of the desired version, but is not yet FROZEN due to bugs, performance, unreadable code, or stability issues.

- A (complete) "code freeze" is achieved when no changes whatsoever are permitted to a portion or the entirety of the program's source code. If there are some bugs found by QA team, they must be fixed. After we're satisfied with the result, all user acceptance test pass, we're "Code Complete".

----------------------
QA Acceptance testing
----------------------
Acceptance testing is a testing with respect to user needs, requirements, and business processes conducted to determine whether or not a system satisfies the acceptance criteria of a given use case. It is usually performed by the QA expert-user, customer or other authorized entity to determine whether or not the system is acceptable.
If all user acceptance test pass, we have "Code Complete".

A test pilot is an aviator who tests new aircraft by fling specific maneuvers. In aeronautics top pilots, navigators and engineers conduct flight tests and at the end of the test missions they will provide evaluation and certification data.

------------------
Code freeze
------------------
A complete code freeze, when no changes whatsoever are permitted to a software solution source code. Sometimes, any change to the source code may have unintended consequences, potentially introducing new bugs. A code freeze is a practice among developers to STOP making changes and pushing new code commits to ensure site or app stability during a certain period of time, while testing is performed.

A feature complete fluid version of a source-code in development stage is an advance ALPHA version, which contains all intended functionality of the final version, but is not yet FROZEN due to bugs, performance, unreadable code, or stability issues.

A code freeze helps ensure that a module of the software system that is known to work correctly will continue to do so. Code freezes are often employed in the final stages of development, when a particular release or iteration is being tested, but may also be used to prevent changes to one portion of a program while another is undergoing development.

Code freeze is often employed in the final stages of development of a particular release or iteration which is being tested.
If known bugs still persist in code you can not declare the "Code Freeze". Sometimes we still have known bugs and declare a "Code Freeze" -- and this is wrong.

DO NOT ADD NEW FEATURES to code base if there are some known bugs, glitches or code-readability issues.

-------------------
"feature freeze"
-------------------
Requirements + Design = FEATURES

Do not confuse "code freeze" with "feature freeze". During the feature freeze period, no new features or additions are made in order to prevent what's called "feature creep". Instead, the focus is on fixing bugs, finishing and fine tuning the features that is already in the application and user experience. The application should be stable and in theory bug free. The idea is to the get the critical and visible bugs fixed.
Only when is reached stable and in theory bug free readable code base, you can consider adding the new features in application.