ソフトウェアの検証と検証

ソフトウェア プロジェクト管理、ソフトウェア テスト、ソフトウェア エンジニアリングにおいて、検証と妥当性確認は、ソフトウェア エンジニア システムが仕様と要件を満たし、意図した目的を達成しているかどうかを確認するプロセスです。ソフトウェア品質管理とも呼ばれます。通常、ソフトウェア開発ライフサイクルの一部としてソフトウェア テスターが担当します。簡単に言えば、ソフトウェア検証とは、「X を構築する必要があると仮定した場合、ソフトウェアはバグやギャップなしで目標を達成しますか?」ということです。一方、ソフトウェア妥当性確認とは、「X は構築すべきものだったでしょうか? X は高レベルの要件を満たしていますか?」ということです。

検証と妥当性確認はよく混同されますが、同じものではありません。ボームは簡潔にその違いを次のように表現しました^[1]

• 検証: 製品を正しく構築していますか?
• 検証: 適切な製品を構築していますか?

「製品を正しく構築する」とは、仕様がシステムによって正しく実装されていることを確認することですが、「適切な製品を構築する」とは、ユーザーのニーズに目を向けることです。状況によっては、両方について要件を文書化し、準拠を判断するための正式な手順やプロトコルを用意する必要があります。理想的には、正式な方法は、ソフトウェアが仕様を満たしていることを数学的に保証します。

製品を正しく構築するには、開発プロセスの次の段階である設計プロセスへの入力として要件仕様を使用する必要があり、その出力は設計仕様です。次に、設計仕様を使用して構築プロセスにフィードすることも必要です。プロセスの出力が入力仕様を正しく実装するたびに、ソフトウェア製品は最終検証に一歩近づきます。プロセスの出力が正しくない場合、開発者はそのプロセスの一部のコンポーネントを正しく実装していません。この種の検証は、「成果物または仕様の検証」と呼ばれます。

これは、ソフトウェアを実行して仕様が満たされているかどうかを確認することを意味しますが、これは不可能です (たとえば、ソフトウェアを実行してアーキテクチャ/設計などが正しく実装されているかどうかを誰が知ることができるでしょうか)。関連する成果物をレビューすることによってのみ、仕様が満たされているかどうかを結論付けることができます。

各ソフトウェア開発プロセス段階の出力は、入力仕様と照合して検証することもできます (以下の CMMI による定義を参照)。

アーティファクト検証の例:

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

ソフトウェア検証では、ソフトウェア製品が意図された用途を満たしているか、または適合しているか (高レベルのチェック) を確認します。つまり、ソフトウェアがユーザー要件を満たしているかを確認します。これは、仕様成果物として、またはソフトウェアを操作する人だけのニーズとしてではなく、すべての利害関係者 (ユーザー、オペレーター、管理者、マネージャー、投資家など) のニーズとしてです。ソフトウェア検証を実行するには、内部と外部の 2 つの方法があります。内部ソフトウェア検証中は、利害関係者の目標が正しく理解され、要件成果物に正確かつ包括的に表現されていると想定されます。ソフトウェアが要件仕様を満たしている場合、内部で検証されています。外部検証は、ソフトウェアがニーズを満たしているかどうかを利害関係者に尋ねることによって実行されます。ソフトウェア開発方法論によって、ユーザーと利害関係者の関与とフィードバックのレベルが異なります。したがって、外部検証は、離散的または継続的なイベントになる可能性があります。最終的な外部検証が成功すると、すべての利害関係者がソフトウェア製品を受け入れ、それがニーズを満たしていると表明します。このような最終的な外部検証では、動的テストである受け入れテストを使用する必要があります。

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

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

アーティファクト検証の例:

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

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

• ソフトウェア検証: 開発プロセス中または開発プロセスの最後にソフトウェアを評価し、指定された要件を満たしているかどうかを判断するプロセス。[IEEE-STD-610]
• ソフトウェア検証: 特定の開発フェーズの製品がそのフェーズの開始時に課された条件を満たしているかどうかを判断するためにソフトウェアを評価するプロセス。[IEEE-STD-610]

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

言い換えると、ソフトウェア検証は、ソフトウェア開発プロセスの各フェーズの出力が、対応する入力成果物で指定された内容 (要件 -> 設計 -> ソフトウェア製品) を効果的に実行していることを確認する一方で、ソフトウェア検証は、ソフトウェア製品がすべての関係者のニーズを満たしていることを確認します (したがって、要件仕様は最初から正しく正確に表現されています)。ソフトウェア検証は、「正しく構築された」ことを確認し、提供された製品が開発者の計画を満たしていることを確認します。ソフトウェア検証は、「正しいものを構築した」ことを確認し、提供された製品が関係者の意図した用途と目標を満たしていることを確認します。

この記事では、検証の厳密な定義または狭義の定義を使用しています。

テストの観点から:

• 障害 – コード内の機能が間違っているか、欠落しています。
• 失敗 – 実行中に障害が発生したことを表します。ソフトウェアは効果的ではありませんでした。本来行うべき動作を実行しません。
• 故障 – 仕様によると、システムは指定された機能を満たしていません。ソフトウェアは効率的ではありません (CPU サイクルなどのリソースを過剰に消費する、メモリを過剰に使用する、I/O 操作を過剰に実行するなど)、使用できない、信頼性がないなどです。想定どおりに動作しません。

検証と妥当性確認はどちらも、品質とソフトウェア品質保証の概念に関連しています。検証と妥当性確認だけではソフトウェアの品質は保証されません。計画、トレーサビリティ、構成管理、およびソフトウェア エンジニアリングの他の側面が必要です。

モデリングおよびシミュレーション(M&S) コミュニティ内では、検証、妥当性確認、認定の定義は似ています。

• M&S検証は、コンピュータモデル、シミュレーション、またはモデルとシミュレーションの実装の連合とそれらに関連するデータが開発者の概念的な説明と仕様を正確に表現しているかどうかを判断するプロセスです。 ^[3]
• M&S検証とは、モデル、シミュレーション、またはモデルとシミュレーションの連合、およびそれらに関連するデータが、意図された用途の観点から現実世界をどの程度正確に表現しているかを判断するプロセスです。^[3]
• 認定とは、モデルやシミュレーションが特定の目的に使用することが許容されるという正式な証明です。^[3]

M&S 検証の定義は、M&S が現実世界の意図された用途をどの程度正確に表しているかに焦点を合わせています。すべての M&S は現実の近似値であるため、M&S の精度の程度を判断する必要があり、通常、近似の程度が意図された用途に許容できるかどうかを判断することが重要です。これはソフトウェア検証とは対照的です。

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

独立ソフトウェア検証および妥当性確認（ISVV）は、安全性が重要なソフトウェアシステムを対象としており、ソフトウェア製品の品質を向上させ、ソフトウェアの運用寿命全体にわたってリスクとコストを削減することを目的としています。ISVVの目標は、ソフトウェアが指定された信頼性レベルで、設計されたパラメータと定義された要件の範囲内で動作することを保証することです。^{[4] [5]}

ISVV アクティビティは、ソフトウェア開発プロセスに関与していない独立したエンジニアリング チームによって実行され、プロセスと結果として得られる製品を評価します。ISVV チームの独立性は、財務、管理、技術の 3 つの異なるレベルで実行されます。

ISVV は、開発チームが適用する「従来の」検証および妥当性確認の手法を超えています。後者は、ソフトウェアが公称要件に対して適切に機能することを保証することを目的としていますが、ISVV は、堅牢性や信頼性などの非機能要件と、ソフトウェアの障害につながる可能性のある条件に重点を置いています。

ISVV の結果と調査結果は、修正と改善のために開発チームにフィードバックされます。

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で正式化されています。

2004年から2005年にかけて、欧州宇宙機関が主導し、DNV、Critical Software SA、Terma、CODA SciSys plcで構成される欧州コンソーシアムが、他の組織の支援を受けて、ISVV専用のガイドの最初のバージョン「ESA Guide for Independent Verification and Validation」を作成しました。^[10]このガイドでは、ISVVに関するすべてのソフトウェアエンジニアリングフェーズに適用可能な方法論を取り上げています。

2008年に欧州宇宙機関は、欧州宇宙ISVVのさまざまな関係者からの意見を受けて第2版をリリースしました。^[10]

ISVV は通常 5 つの主要フェーズで構成され、これらのフェーズは順番に実行することも、調整プロセスの結果として実行することもできます。

• ISVV活動の計画
• システム重要度分析: 一連のRAMSアクティビティ (費用対効果)による重要なコンポーネントの特定
• 適切な方法とツールの選択

• 検証: 完全性、正確性、テスト可能性

• ソフトウェア要件とインターフェースへの設計の適切性と適合性
• 内部と外部の一貫性
• 実現可能性とメンテナンスの検証

• 検証：完全性、正確性、一貫性
• コードメトリクス分析
• コーディング標準準拠の検証

• 不安定なコンポーネント/機能の特定
• エラー処理に重点を置いた検証: 開発チームが実行した検証を補完する（同時ではない）検証
• ソフトウェアおよびシステム要件への準拠
• ブラックボックステストとホワイトボックステストの手法
• 経験に基づく技術

ソフトウェアは、法的に規制されている業界のコンプライアンス要件を満たす必要があることが多く、これは政府機関^{[11] [12]}や産業行政当局によって指導されることが多い。たとえば、FDAはソフトウェアのバージョンとパッチの検証を要求している。^[13]

• コンパイラの正確性
• クロス検証
• 形式検証
• 機能仕様
• 独立した検証および検証施設
• 国際ソフトウェアテスト資格委員会
• ソフトウェア検証
• ソフトウェア要件仕様
• 検証（医薬品製造）
• 検証と妥当性確認– 一般
• コンピュータシミュレーションモデルの検証と妥当性確認
• 独立した検証システム
• ソフトウェアテスト
• ソフトウェアエンジニアリング
• ソフトウェアの品質
• 静的コード分析
• 要件エンジニアリング
• 安全性が重要なシステム
• キャサリン・ジョンソン独立検証施設

• ソフトウェア品質に関する章 (VnV を含む) 2014-12-08 にSWEBOKのWayback Machineにアーカイブされました