以前のバージョンとの整合性を確認するドキュメントレビューの方法
既存バージョンのソフトウェアを拡張して新しいバージョンのソフトウェアを開発する際のソフトウェアレビューでは、レビューで確認する場所が大きく2種類あります。一つは、今回のバージョンアップで新しく追加、修正した部分で、ここに欠陥がないことを確認します。もう一つは、修正した部分がこれまでのバージョンで動いていた部分に悪影響を与えていないか整合性を確認します。
2種類のレビューは同時にやると混乱しがちなので、別々に実施します。別々のレビューアが手分けして実施してもよいでしょう。手分けするならば既存バージョンとの整合性の確認は、開発の経緯をよく知るレビューアが担当したほうが効果的です。一人のレビューアで担当する場合には手間が大きい方を後にレビューしたほうが効率化につながります。既存バージョンのほうが規模が大きい場合には、先に新しく追加、修正した部分をレビューして、その後既存バージョンとの整合性を確認します。
また、新しいバージョンの設計ドキュメントのレビューであっても、既存バージョンとの整合性の確認は既存バージョンの設計ドキュメントである必要は必ずしもありません。利用可能なコストや今後のバージョンアップの予定に応じて、設計ドキュメントのかわりに既存バージョンのソースコードを確認してもかまいません。
もちろん既存ソースコードから設計ドキュメントを最新の状況に更新したり、ドキュメントがない場合にはソースコードをもとに新たに作ったりすることは、今後の保守や既存ソースコードの理解を助けますので、コスト等の状況が許せばそちらのほうが適切と言えます。
既存バージョンから新しいバージョンを開発する際のレビューの手順を日経SYSTEMS 2013年3月号の連載で解説しています。2012年10月号からのレビューの解説記事の連載の最終回になります。お手元にあれば、ご参照ください。こちらからPDFを購入することもできます。
また、既存バージョンから新しいバージョンを開発する際の課題や解決策を紹介、議論するアフォード フォーラムにパネリストとして招待いただきました（2013/3/5 @ 東京）。詳細はこちら。参加申込みはこちら（申込み締切り2013/3/3）。