Talk:Freeze (software engineering)

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Low	This article has been rated as Low-importance on the project's importance scale.
	This article is supported by WikiProject Software (assessed as Low-importance).

Totally bogus?

1. Deferring UX after feature freeze as documented is totally bogus. User interface and experience work is part of the feature design process, not a "bug" to be fixed later on. Only bugs are fixed later on.

2. A feature freeze is pretty much coupled with a (semi-)official roadmap, as it implies to setup a list of features that will be contained in the upcoming release of a software, and the release date is effectively deferred to whatever-point-in-time the features are completed.

3. Compared to a code freeze (usually date-based), a feature freeze allows to setup clear metrics for what the state of the software must be in before a new release can be considered. As such, a feature freeze is either very specific in the features it lists, or alternatively, it is represented as a list of (rough) "user stories" (see Scrum (development)).

4. In complex software projects, a feature freeze may imply that missing functionality is determined only after the feature freeze during alpha/beta testing. In that case, the new software release is delayed until the missing functionality has been incorporated to make the product work as intended - or - a new feature may be removed prior to the new release, to target for it again in the second to next release.

sun (talk) 23:04, 6 August 2011 (UTC)[reply]