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

ソフトウェアプロジェクト管理、ソフトウェアテスト、ソフトウェアエンジニアリングにおいて、検証と妥当性確認は、ソフトウェアシステムが仕様と要件を満たし、意図された目的を達成しているかどうかを確認するプロセスです。ソフトウェア品質管理とも呼ばれます。通常、ソフトウェア開発ライフサイクルの一環として、ソフトウェアテスターが担当します。簡単に言えば、ソフトウェア検証とは、「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は現実の近似値であり、その近似度が意図された用途において許容できるかどうかを判断することが通常重要だからです。これはソフトウェアバリデーションとは対照的です。

V&Vメソッド

フォーマル

ミッションクリティカルなソフトウェアシステムでは、システムの正しい動作を保証するために形式手法が用いられることがあります。しかし、これらの形式手法はコストが高く、ソフトウェア設計コスト全体の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で正式化されています。

ESAで

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

2008年に欧州宇宙機関は、欧州宇宙ISVVの様々な関係者からの意見を取り入れて第2版をリリースした。[ 10 ]

方法論

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

計画

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

要件検証

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

設計検証

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

コード検証

検証

規制環境

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

参照

さらに読む

参考文献

  1. ^ Pham, H. (1999).ソフトウェアの信頼性. John Wiley & Sons, Inc. p. 567. ISBN 9813083840ソフトウェア検証。ソフトウェアが正しいプロセスを実行していることを確認するプロセス。ソフトウェア検証。ソフトウェアが正しいプロセスを実行していることを確認するプロセス。」同様に、また次の点も挙げられます。「要するに、Boehm (3) はソフトウェア検証とソフトウェア検証の違いを次のように表現しています。検証：製品を正しく構築していますか？検証：正しい製品を構築していますか？
  2. ^ 「CMMI for Software Engineering, Version 1.1, Staged Representation (CMMI-SW, V1.1, Staged)」 . resources.sei.cmu.edu . 2002年7月31日. 2021年3月20日閲覧。
  3. ^ a b c国防総省モデルおよびシミュレーションの検証、妥当性確認、認定（VV&A）に関する文書、ミサイル防衛局、2008年
  4. ^ Rogers, R. (1981-10-26). 「独立したソフトウェアの検証と妥当性確認のための計画」 .第3回Computers in Aerospace Conference . Computers in Aerospace Conference. サンディエゴ、カリフォルニア州、米国：アメリカ航空宇宙学会. doi : 10.2514/6.1981-2100 .
  5. ^ Ambrosio, Ana; Mattiello-Francisco, Fátima; Martins, Eliane (2008-05-12). 「宇宙アプリケーションのための独立したソフトウェア検証および妥当性確認プロセス」 . SpaceOps 2008 カンファレンス. ハイデルベルク（ドイツ）: アメリカ航空宇宙学会. doi : 10.2514/6.2008-3517 . ISBN 978-1-62410-167-0。
  6. ^ Lewis, Robert O. (1992). 『独立検証と妥当性確認：高品質ソフトウェアのためのライフサイクルエンジニアリングプロセス』ニューヨーク: Wiley. ISBN 0-471-57011-7. OCLC  74908695 .
  7. ^ a b Asbury, Michael (2015年3月9日). 「NASA​​のIV&Vプログラムについて」 NASA . 2021年3月20日閲覧。
  8. ^ Balci, O. (2010). 「モデリングおよびシミュレーションアプリケーションの検証、妥当性確認、テスト、および認証の黄金律」S2CID 61476570 . {{cite web}}:欠落または空|url=(ヘルプ)
  9. ^ 「フライトソフトウェアシステムセクション（TEC-SWF）」www.esa.int . 2021年3月20日閲覧。
  10. ^ a b lavva.pt. 「Space in the Works向けの新しいISVVガイド」 www.criticalsoftware.com . 2021年3月20日閲覧。
  11. ^ 「ソフトウェア検証の一般原則：業界およびFDA職員向け最終ガイダンス」（PDF）。米国食品医薬品局。2002年1月11日。 2009年6月17日時点のオリジナル（PDF）からアーカイブ。 2009年7月12日閲覧。
  12. ^ 「業界向けガイダンス：パート11、電子記録、電子署名 — 範囲と適用」（PDF）。食品医薬品局。2003年8月。2009年7月9日時点のオリジナル（PDF）からアーカイブ。 2009年7月12日閲覧。
  13. ^ 「業界向けガイダンス：市販ソフトウェア（OTS）を搭載したネットワーク医療機器のサイバーセキュリティ」（PDF）。米国食品医薬品局。2005年1月14日。 2009年7月10日時点のオリジナル（PDF）からアーカイブ。 2009年7月12日閲覧。

注記

「 https://en.wikipedia.org/w/index.php?title=Software_verification_and_validation&oldid=1332080497」より取得