フリーズ（ソフトウェアエンジニアリング）

ソフトウェアエンジニアリングにおいて、フリーズとは、開発プロセスにおいて、ソースコードや関連リソースへの変更ルールがより厳格になる時点、またはそのルールが適用される期間を指します。^[1]フリーズは、変更の規模や頻度を減らすことで、プロジェクトをリリースやイテレーションの終了に向けて前進させるのに役立ち、ロードマップの達成にも役立ちます。

正確なルールは、フリーズの種類と、使用されている特定の開発プロセスによって異なります。たとえば、バグを修正する変更のみを許可する、または開発チームの他のメンバーによる徹底的なレビュー後にのみ変更を許可する、などが含まれます。また、ルールに反する変更が必要な場合、フリーズ期間を再開するなど、何が起こるかを指定することもできます。一般的なフリーズの種類は次のとおりです。

• コーディング作業を開始するために、関係者がソフトウェア プロジェクトの機能リストに新しい要件、仕様、または機能を追加しないことを決定する (完全な) 仕様凍結。
• 機能の (完全な) 凍結。新機能の追加作業はすべて一時停止され、バグの修正とユーザー エクスペリエンスの向上に取り組みが移行されます。新機能の追加は、新しいテストされていないソース コードやリソースの導入と他の機能との相互作用の両方により、プログラムの他の部分に混乱をもたらす可能性があります。そのため、機能の凍結はプログラムの安定性の向上に役立ちます。たとえば、「ユーザー インターフェイス機能の凍結」は、コードのユーザー インターフェイス部分にこれ以上の機能が許可されないことを意味します。ただし、バグは引き続き修正できます。
• プログラムのソース コードの一部または全体に対する変更を一切許可しない (完全な) コード フリーズ。特に大規模なソフトウェア システムでは、ソース コードを変更すると予期しない結果が生じ、新しいバグが生じる可能性があります。そのため、コード フリーズは、正常に動作することがわかっているプログラムの一部が引き続き正常に動作することを保証する上で役立ちます。コード フリーズは、特定のリリースまたは反復がテストされている開発の最終段階でよく使用されますが、プログラムのある部分に対する変更を、別の部分の開発中に禁止するためにも使用できます。たとえば、「物理フリーズ」は、コードの物理部分に一切の変更が許可されないことを意味します。

バージョン管理を使用する開発環境では、ブランチを使用すると、フリーズによる開発の遅延を軽減できます。たとえば、プロジェクトには、ソフトウェアの新しいバージョンがリリースされる「安定」ブランチと、開発者が新しいコードを追加する別の「開発」ブランチがあります。フリーズの効果は、開発ブランチから安定ブランチへの変更の一部またはすべてのプロモーションを防ぐことです。つまり、フリーズは安定ブランチにのみ適用され、開発者は開発ブランチで作業を継続できます。

• 機能完了
• ソフトウェアリリースライフサイクル