以前、あるべきV字モデルについて整理し、そのV字モデルにおいてどのような分業をすべきかを整理した。開発をするうえでは、各開発工程における成果物が、意図した出来栄えになっているのかどうかを、レビューという形でチェックを行う。今回は、あるべきV字モデル開発におけるレビューのタイミングについて紹介する。
あるべきV字モデルに関しては下記記事を参照されたい。
あるべきV字モデルにおける分業方法について下記記事を参照されたい。
あるべきV字モデルにおけるレビューの実施タイミング
上図に、あるべきV字モデルにおけるレビューのタイミングを示す。レビューを実施すべきタイミングに、黄色の番号を振った。レビューのタイミングは全部で7回存在する。
- ①：要件定義書作成完了後
- ②：要件定義書に対応するテスト仕様書作成完了後
- ③：設計書作成完了後
- ④：設計書に対応するテスト仕様書作成完了後
- ⑤：実装完了後
- ⑥：設計書通りに動くか確認した後
- ⑦：要件定義書通りに動くか確認した後
順に説明する。
①：要件定義書作成完了後
最初のレビュータイミングは、要件定義書作成完了後だ。要件定義書作成完了後は、この内容で設計ができるか？この内容でテスト仕様書が作成できるか？という観点でレビューを実施する。
②：要件定義書に対応するテスト仕様書作成完了後
①のレビューが完了したら、①で作成した要件定義書をインプットとして、テスト仕様書を作成する。このタイミングでは、要件定義書をすべて確認できる内容か？という観点でレビューを実施する。
③：設計書作成完了後
①のレビューが完了したら、①で作成した要件定義書をインプットとして、設計書を作成する。このタイミングでは、要件定義書をすべて実現できる内容か？この内容で実装ができるか？という観点でレビューを実施する。
④：設計書に対応するテスト仕様書作成完了後
③のレビューが完了したら、③で作成した設計書をインプットとして、テスト仕様書を作成する。このタイミングでは、設計書をすべて確認できる内容か？という観点でレビューを実施する。
⑤：実装完了後
③のレビューが完了したら、③で作成した設計書をインプットとして、プログラムを作成する。このタイミングでは、設計書通りに実装しているか？という観点でレビューを実施する。
⑥：設計書に対応するテスト仕様書作成完了後
⑤のレビューが完了したら、システムを動かし、④で作成したテスト仕様書をインプットとして、動作確認を行う。このタイミングでは、テスト仕様書に記載のテストはすべて実行され、結果はすべてOKか？という観点でレビューを実施する。
⑦：要件定義書に対応するテスト仕様書作成完了後
⑥のレビューが完了したら、システムを動かし、②で作成したテスト仕様書をインプットとして、動作確認を行う。このタイミングでは、テスト仕様書に記載のテストはすべて実行され、結果はすべてOKか？という観点でレビューを実施する。
プロセス(工程)があるところには、必ずレビューがある
いかがであろうか？あるべきV字モデルで開発をする場合は、少なくとも7回のレビューを実施する必要がある。レビューを経験した者ならわかるが、レビューを受ける側にとっては、レビューというのは、あまり楽しいものではない。レビューを受けるということは、宿題が増えることを意味する。しかしながら、レビューをしなければ、成果物の品質を確保することができない。心構えとしては、レビュー指摘ゼロを目指して日々の開発に臨みたいところだ。
システム開発というのは、いろいろなプロセス(工程)があり、各工程における成果物が、後工程のインプットとして利用される。インプットの品質が良くないと、その工程のアウトプットの品質も良くなることはない。後工程に迷惑をかけないよう、各工程で成果物の品質を確保しなければならないのだ。そのためにレビューというものが存在する。積極的にレビューを実施し、品質を確保していきたいものだ。
