変更(バージョン/リビジョン)管理
本件は、製品の生まれから成長過程をキチンと管理することで開発段階から出荷後のトラブル対応までキチンと対応できハードウェアと同様に基本動作の一つである。
バージョン/リビジョン管理の徹底による無駄なテストの防止を図ることが重要である。
品質の早期見極めの為にシステム未完成の状況からテストを開始すると言っても、ある程度機能がまとまっていなければテストにならないので、被テストシステムのバージョン/リビジョン管理をキチンとする必要がある。
せっかく新機能を追加しても関係モジュール全体に対して、整合がとれた状態で追加修正が行われないとテストは無駄な工数を食うだけである。
被テストライブラリが整然とラインアップし、更新されているためには、厳密な変更管理システムの整備と変更管理責任者が任命されていなければならない。
ここでベースとなる「モジュールの大きさ」について、
開発言語等によっていろいろな考え方があるが基本は次のように考えるとよい。
「2~3時間で机上デバッグが完了する程度の大きさが望ましい。
とは言っても、
入り口は原則一ヶ所、
他モジュールを参照せずに開発・保守ができること、
他モジュールをリコンパイルせずに、
当該モジュールだけで修正・変更ができる等の原則論は守らねばならない。」
本件は、製品の生まれから成長過程をキチンと管理することで開発段階から出荷後のトラブル対応までキチンと対応できハードウェアと同様に基本動作の一つである。
バージョン/リビジョン管理の徹底による無駄なテストの防止を図ることが重要である。
品質の早期見極めの為にシステム未完成の状況からテストを開始すると言っても、ある程度機能がまとまっていなければテストにならないので、被テストシステムのバージョン/リビジョン管理をキチンとする必要がある。
せっかく新機能を追加しても関係モジュール全体に対して、整合がとれた状態で追加修正が行われないとテストは無駄な工数を食うだけである。
被テストライブラリが整然とラインアップし、更新されているためには、厳密な変更管理システムの整備と変更管理責任者が任命されていなければならない。
ここでベースとなる「モジュールの大きさ」について、
開発言語等によっていろいろな考え方があるが基本は次のように考えるとよい。
「2~3時間で机上デバッグが完了する程度の大きさが望ましい。
とは言っても、
入り口は原則一ヶ所、
他モジュールを参照せずに開発・保守ができること、
他モジュールをリコンパイルせずに、
当該モジュールだけで修正・変更ができる等の原則論は守らねばならない。」
※コメント投稿者のブログIDはブログ作成者のみに通知されます