ソフトウェアの品質保証の考え方であるV&Vについて、少し考えてみました。
「V&V」で検索すれば、電気通信大学の西先生の記事があり、これで十分でしょうが、自分の理解の整理のために書いておきます。
ソフトウェア工学の用語集であるIEEE Std 610.12-1990によると、V&VのVerificaion（検証）とValidation（妥当性確認）は以下のように定義されています。
Validation
The process of evaluating a system or component during or at the end of the development process to determine whether it satisfies specified requirements.
Validationは、「開発の途中または最後の段階で、特定された要求を満たしているか」とあります。原典を当たることができませんでしたが、IEEE Std 610.12-1990の前身にあたるStd 729-1983では、「最後の段階で」と定義されていたとのことです。最終的にできたものが、正しいか。
Verification
1. The process of evaluating a system or component to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase.
2. Formal proof of program correctness.
一方Verificationは、「ある開発フェーズにおいて、フェーズ当初に与えられた条件を満足しているか」ということで、開発全体を構成する各部分の正しさに注目していることがわかります。
ここで、西先生はこのようなことをおっしゃっています。
理詰めでモノを考える人は、ここで疑問を感じると思います。verificationを全てきちんとやっておけば、ソフトウェア開発の一番最初の入力である要求と、一番最後の出力であるソフトウェアが合っているかどうかチェックできるのではないでしょうか。すなわち、verificaitonがあれば validationはいらない、と思いませんか。
わたしもまさに、そう思いました。
そこで、わたしなりの理解として、ソフトウェア開発を「洋書の翻訳本を出版する」という作業と比較して考えてみました。
ソフトウェア開発と翻訳本の出版には、少なくとも5つの共通点があります。（ちょっとちょっとくどいですが）
さて、Verificationが完璧であってもなお、Validationが必要となる理由は、まず(3)です。
数学の証明であれば、
の2つが言えれば、確実に
が言えます。これは数学の等号に、曖昧なところがないからです。
しかし、自然言語や人の解釈というものは、厳密には変換しがたい。「I'm dressing」という英文を、「わたしは着替え中です」と訳しても、「わたしはドレッシングです」と訳しても、おそらく単体テストは通ってしまいます。
もっと後の結合テスト・システムテストで、明らかにおかしな訳文は欠陥として検出されるでしょうが、微妙な間違いは残存してしまいます。
誤訳以外にも、テストで検出しがたい欠陥があります。検出を困難にする要素は、(4)です。
1文1文は何とか理解できるけれど、全体として何を言っているかさっぱりわからず頭に入ってこない、そんな訳本に出会ったことがないでしょうか。そういう翻訳をした人は、中身をあまりによく知っているばかりに、自分の翻訳の何がわかりづらいのかもわからなくなってしまっているのかも知れません。そもそも原書の内容をちゃんと理解できなかったのかも知れません。
翻訳本は、たくさんの人による検証の末に出版にこぎつけるでしょうが、その「たくさんの人」の中に、「実際の読者」は含まれていないことが普通です。でも、その翻訳が妥当かどうかを判断するのは、結局のところ読者。なので、「ユーザが求めるものに本当になっているか」のValidationが必要になるということです。
このアナロジーで考えると、VerificationとValidationのそれぞれを必要と見なす理由が見えやすくはないでしょうか。
とはいえ、IEEE Std 610.12-1990ではValidationを「開発の途中または最後の段階」としており、上流工程段階での妥当性確認も視野に入れていることから、いよいよもってVerificationとの棲み分けが微妙ですねえ。
