検証と妥当性確認
V&V（Verification and Validation）検証と妥当性確認の意味を少し勘違いしていたのでメモ。
定義とか
検証（Varification）
客観的証拠を提示することによって，規定要求事項が満たされていることを確認すること。
ISO9000:2005（JISQ9000:2006）より
検証の例を示す。
- 結果が期待通りであることを確認する。
- 例えば、ユニットテストを実行して、期待通りであることを確認する
- 例えば、別の方法で計算した結果と突き合わせて、結果が一致することを確認する
- 例えば、新システムの結果を現行システムの結果と突き合わせて、結果が一致することを確認する
- ソフトウェア要求定義書がをレビューして、システム要求仕様書で抽出したソフトウェア要求が正しく反映されていることを確認する。アウトプットが期待通りであることを確認する。
「頼まれたことをきちんとやっていること」を確認するイメージでいいのかな？イメージで適当なこというと怒られるかな？（誰に？）
妥当性確認（Validation）
客観的証拠を提示することによって，特定の意図された用途又は適用に関する要求事項が満たされていることを確認すること。
ISO9000:2005（JISQ9000:2006）より
最終製品が顧客の二ーズをきちんと反映しているかどうかを確認すること。
最終製品のαテスト（テスト実施する人が限られている）とか、βテストなどにより確認する。
＃多分、製品のリリース後も、顧客の二ーズを満たしているかどうかの確認は続くので、「妥当性確認」は続くのではないかと思うのだが・・・例えば、生産性向上を目指して作ったシステムが、本当に生産性向上に寄与しているのか、とか。
＃私が誤解していたのは、「最終製品が・・・しているか・・」という点。
開発の途中であっても、ニーズ（ゴール）を外していないかという観点で常にウォッチする必要があり、各開発プロセスのレビュー時には、この「妥当性」を確認する観点が入っているべきだと思っているのだが。また、要求／仕様変更を検討する際にも「妥当性」を意識すべきだと思うのだが。
なんだか、「客観的証拠を提示することによって，・・・確認すること」という観点が抜けているのかな。
妥当性を各局面で意識すべき点は多分あっているのだが、ここで言っているのはそういうことではなく、最終製品で「確認」すること、ということかな。
