ソフトウェアの検証と妥当性確認

ソフトウェアの検証と妥当性確認（V&V）は、ソフトウェアがその仕様に従って正しく構築されていること、およびユーザーのニーズを満たす適切なソフトウェアが構築されたことを確認する、相補的なプロセスです。

Definition

検証とは、開発フェーズの成果物がその開始時に課された条件を満たしているかどうかの評価であり、妥当性確認とは、最終製品が意図された用途とユーザーのニーズを満たしているかどうかの評価です。

Scope

このトピックでは、レビュー、ウォークスルー、形式的インスペクションなどの静的V&V手法、実行なしで欠陥を検出するための静的プログラム解析、テストによる動的V&V、V&V活動の計画と独立性、およびV&Vプロセスと厳格さのレベルを規定するISO/IEC/IEEE 1012などの標準について説明します。

Core questions

• 検証と妥当性確認は、質問と方法においてどのように異なりますか？
• レビューとインスペクションは、テストでは見逃されるどのような欠陥を検出しますか？
• 静的解析は動的テストをどのように補完しますか？
• V&Vの厳格さは、ソフトウェアの重要度とどのように対応付けられますか？

Key theories

検証と妥当性確認

検証は、仕様に対して製品を正しく構築しているか（are we building the product right）を問い、妥当性確認は、ユーザーにとって適切な製品を構築しているか（are we building the right product）を問います。この2つは異なる証拠を必要とし、ライフサイクル全体にわたります。

ソフトウェアインスペクション

Faganインスペクションは、設計とコードの欠陥を早期かつ安価に検出する、構造化された役割ベースのレビュープロセスであり、最も効果的な欠陥除去技術の1つであり続けています。

Clinical relevance

V&V活動、特に初期のレビューと静的解析は、欠陥が後のフェーズに到達する前に除去し、後のフェーズでははるかにコストがかかります。安全性が重要でミッションクリティカルなソフトウェアの場合、独立したV&Vは標準や規制当局によって義務付けられることがよくあります。

Evidence & guidelines

ISO/IEC/IEEE 1012はV&Vプロセスと整合性レベルを定義しており、DO-178C（航空電子工学）やIEC 61508（機能安全）などのドメイン標準は、リスクに応じてV&V要件を課しています。

History

形式的インスペクションは1976年にIBMのFaganによって導入され、非常に費用対効果が高いことが繰り返し示されました。静的解析ツールは1990年代から成熟し、V&Vは安全性が重要な分野で規制された規律となり、IEEE 1012などの標準で成文化されました。

Key figures

• Michael Fagan
• Barry Boehm
• Roger Pressman

Seminal works

• fagan1976
• ieee1012
• pressman2014

Frequently asked questions

検証と妥当性確認はどのように異なりますか？

検証は、各ステップで仕様への適合性をチェックします。これは「製品を正しく構築しているか」を確認することです。一方、妥当性確認は、完成した製品が実際にユーザーのニーズを満たしているか、つまり「適切な製品を構築しているか」を確認します。要件自体が間違っていた場合、システムは検証されていても妥当性確認に失敗する可能性があります。

コードレビューは本当に労力に見合う価値がありますか？

Faganの研究に始まる実証研究は、構造化されたレビューとインスペクションが、テストでは見逃される可能性のある多くの欠陥を早期かつ安価に発見し、最も費用対効果の高い品質技術の1つであることを一貫して示しています。