Verification そして 検証 検証と妥当性確認は、それぞれ異なるプロセスです。検証は、製品が規定の要件を満たしていることを確認します（「正しく製造されていますか？」）。妥当性確認は、製品がユーザーの実際のニーズと意図された用途を満たしていることを確認します（「正しいものを作っていますか？」）。これらは品質管理における相互補完的な活動であり、正確性と有用性の両方を確保するために、多くの場合、順次または並行して実行されます。
検証と妥当性確認
1980
- Barry Boehm
（画像はイメージです）
検証と妥当性確認の区別は、あらゆる複雑な工学分野、特にソフトウェアおよびシステム工学における品質保証の基本です。検証は、仕様への準拠に焦点を当てた内部品質プロセスです。これには、設計文書、コード、要件のレビュー、検査、ウォークスルーなどの活動が含まれます。目標は、開発ライフサイクルの早い段階で欠陥を発見することです。たとえば、コードレビューでは、ソフトウェアがコーディング標準に準拠し、設計文書に記載されている特定のアルゴリズムを正しく実装していることを検証します。
一方、検証は、目的適合性に焦点を当てた外部品質プロセスです。最終製品が、意図された運用環境で効果的であるかどうかを評価します。これには通常、実際のユーザーまたはシミュレーションされた実世界環境で製品をテストすることが含まれます。たとえば、ユーザー受け入れテスト（UAT）は検証活動であり、エンドユーザーがソフトウェアをテストして、タスクを効率的かつ効果的に実行するのに役立つかどうかを確認します。システムは完全に検証済み、つまりバグがなく、文書化されたすべての仕様を満たしている場合でも、仕様に欠陥があったり、ユーザーの真のニーズを正確に捉えていなかったりすると、検証に失敗する可能性があります。
バリー・ボームの研究は、これら2つの活動が異なる問いに答えるものであり、成功する製品を提供するために不可欠であることを強調している。検証を怠ると、バグだらけで信頼性の低い製品になり、妥当性確認を怠ると、技術的には問題なくても、最終的には想定されるユーザーにとって役に立たない製品になってしまう。この2つのプロセスは連携して機能することで、正確性と有用性の両方を保証する。
UNESCO Nomenclature: 1203
コンピュータサイエンス
タイプ
抽象システム
混乱
実質的な
使用法
広く普及している
前駆物質
- 製造業における品質管理の初期概念
- 形式論理学と証明論
- 構造化プログラミングの原則
- 初期のソフトウェアテスト手法
アプリケーション
- アジャイルソフトウェア開発手法
- システムエンジニアリングのライフサイクルモデル（例：vモデル）
- 医薬品開発プロトコル
- 航空宇宙システム認証（例：DO-178C）
- medical device approval processes (e.g., FDA regulations)
特許:
NA
潜在的なイノベーションのアイデア
ボットによるトラフィック（現在1日あたり4万件以上）を排除するため、このコンテンツはコミュニティメンバー限定となっています。
> ログイン < または > 登録 < （100%無料）でこれにアクセスできます。他のすべての制限付きコンテンツとツールも同様です。
関連事項: 検証、妥当性確認、品質保証、ソフトウェアエンジニアリング、システムエンジニアリング、要件、仕様、テスト。
歴史的背景
検証と妥当性確認
（日付が不明または関連性がない場合、例えば「流体力学」などでは、その注目すべき出現時期の概算値が提示されます。）
