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

これは、ソフトウェアを実行して仕様が満たされているかどうかを確認することを意味しますが、これは不可能です（例えば、ソフトウェアを実行するだけで、アーキテクチャや設計などが正しく実装されているかどうかを知ることは誰にもできません）。仕様が満たされているかどうかを判断するには、関連する成果物をレビューするしかありません。

ソフトウェア開発プロセスの各段階の出力は、入力仕様と照合することで検証の対象となる場合もあります（下記のCMMIによる定義を参照）。

成果物検証の例：

• 設計仕様と要求仕様の照合：アーキテクチャ設計、詳細設計、およびデータベース論理モデルの仕様は、機能要件および非機能要件の仕様を正しく実装しているか？
• 設計仕様に対する構築成果物について：ソースコード、ユーザーインターフェース、データベースの物理モデルは、設計仕様を正しく実装しているか？

ソフトウェア検証は、ソフトウェア製品が意図された用途を満たしているか適合しているか（高レベルのチェック）を確認します。つまり、ソフトウェアがユーザー要件を満たしているかどうかを確認します。これは、仕様書やソフトウェアを操作する人だけのニーズとしてではなく、すべてのステークホルダー（ユーザー、オペレーター、管理者、マネージャー、投資家など）のニーズとしてです。ソフトウェア検証には、内部検証と外部検証の2つの方法があります。内部ソフトウェア検証では、ステークホルダーの目標が正しく理解され、要件成果物に正確かつ包括的に表現されていると想定されます。ソフトウェアが要件仕様を満たしていれば、内部検証は完了です。外部検証は、ステークホルダーにソフトウェアがニーズを満たしているかどうかを尋ねることで行われます。さまざまなソフトウェア開発手法では、ユーザーとステークホルダーの関与とフィードバックのレベルが異なるため、外部検証は個別のイベントにも継続的なイベントにもなり得ます。すべてのステークホルダーがソフトウェア製品を受け入れ、ニーズを満たしていると表明したときに、最終的な外部検証が成功します。このような最終的な外部検証には、動的テストである受け入れテストの使用が必要です。

しかし、ソフトウェアが要件仕様を満たしているかどうかを確認するために内部静的テストを実行することも可能だが、これはソフトウェアが実行されていないため、静的検証の範囲に含まれる。

ソフトウェア製品全体が完成する前に、要件を検証する必要があります（ウォーターフォール開発プロセスでは、設計開始前に要件を完全に定義する必要がありますが、反復開発プロセスではそうする必要はなく、継続的な改善が可能です）。

成果物検証の例：

• ユーザー要件仕様の検証：ユーザー要件仕様書と呼ばれる文書に記載されているユーザー要件は、利害関係者の意思と目標を真に反映しているかどうかを確認することで検証されます。これは、利害関係者に直接インタビューして質問する（静的テスト）か、プロトタイプを公開してユーザーと利害関係者に評価してもらう（動的テスト）ことによって行うことができます。
• ユーザー入力の検証：ユーザー入力（キーボード、生体認証センサーなどの周辺機器によって収集される）は、ソフトウェアオペレーターまたはユーザーによって提供された入力がドメインのルールと制約（データ型、範囲、フォーマットなど）を満たしているかどうかを確認することによって検証されます。

能力成熟度モデル（CMMI-SW v1.1）によれば、 ^{[ 2 ]}

• ソフトウェア検証：開発プロセス中または開発終了時に、ソフトウェアが規定された要件を満たしているかどうかを評価するプロセス。[IEEE-STD-610]
• ソフトウェア検証：特定の開発フェーズの成果物が、そのフェーズの開始時に課せられた条件を満たしているかどうかを判断するために、ソフトウェアを評価するプロセス。[IEEE-STD-610]

ソフトウェア開発プロセスにおける検証は、ユーザー要求仕様の検証の一形態と見なすことができ、開発プロセスの最後には、内部および／または外部ソフトウェア検証に相当するものとなる。CMMIの観点から見ると、検証は明らかに成果物に関するものである。

言い換えれば、ソフトウェア検証は、ソフトウェア開発プロセスの各フェーズの出力が、対応する入力成果物（要件→設計→ソフトウェア製品）で指定された内容を効果的に実行することを保証する一方、ソフトウェア妥当性確認は、ソフトウェア製品がすべてのステークホルダーのニーズを満たしていることを保証します（したがって、要件仕様がそもそも正しく正確に表現されていることを保証します）。ソフトウェア検証は、「正しく構築された」ことを保証し、提供された製品が開発者の計画を満たしていることを確認します。ソフトウェア妥当性確認は、「正しいものが構築された」ことを保証し、提供された製品がステークホルダーの意図した用途と目標を満たしていることを確認します。

本稿では、検証という言葉を厳密な、あるいは狭義の定義で用いている。

テストの観点から：

• エラー – コード内の関数が間違っているか、または欠落している。
• 失敗とは、実行中に発生した不具合のことです。ソフトウェアが正常に動作せず、本来の機能を果たしませんでした。
• 不具合 – 仕様書によれば、システムは指定された機能を満たしていません。ソフトウェアが過剰なリソース（時間やCPUサイクルの過剰使用、メモリの過剰使用、I/O操作の過剰など）を使用したり、副作用（システムへの熱/電圧/振動リスク、ユーザーへの熱/電流/力リスクなど）が発生したり、使用不能、信頼性が低いなどの問題が発生しました。本来の動作どおりに機能しません。

ミッションクリティカルなソフトウェアシステムでは、システムの正常な動作を保証するために形式手法が用いられることがある。しかし、これらの形式手法はコストがかさむ場合があり、ソフトウェア設計コスト全体の80%を占めることもある。

ISVVは、ソフトウェアへのIV&V（独立検証および妥当性確認）の適用から派生したものです。今日知られているISVVの初期適用は、1970年代初頭に米国陸軍がセーフガード弾道ミサイル迎撃システムに関するIV&Vに関連する最初の重要なプログラムを後援したことに遡ります。^{[ 6 ]}もう1つの例は、1993年に設立されたNASAのIV&Vプログラムです。^{[ 7 ]}

1970年代末までに、独立検証・妥当性確認（IV&V）は急速に普及し始めた。ソフトウェアの複雑性、規模、重要性が絶えず増大するにつれ、ソフトウェアへのIV&Vの適用に対する需要も高まっていった。

一方、IV&V（およびソフトウェアシステムの場合はISVV）は統合され、現在では国防総省、FAA ^{[ 8 ]} 、NASA ^{[ 7 ]}、ESA ^{[ 9 ]}などの組織で広く使用されています。IV &VはDO-178B、ISO/IEC 12207で言及され、 IEEE 1012で形式化されています。

ISVVは通常、5つの主要なフェーズで構成され、これらのフェーズは順次実行することも、カスタマイズプロセスの結果として実行することもできます。