設計検証と検証プロセス

設計検証

設計検証 設計検証とは、検査と証拠の提示によって、設計されたソフトウェア製品の出力が入力仕様を満たしていることを確認する手法です。ソフトウェア開発における設計検証プロセスの目的は、設計されたソフトウェア製品が仕様どおりであることを保証することです。

設計入力とは、設計の基礎となる物理的および性能上の要件のことです。設計出力とは、各設計段階および設計作業全体の成果のことです。医療機器などの規制対象業界では、最終的な設計出力が機器マスターレコードの基礎となるため、検証文書には設計管理用語が頻繁に登場します。

実際には、検証とは、入力された仕様書、規格、制約事項と、出力された図面、コード、テスト手順書という2組の文書を比較することです。両者の間に不一致があれば、それは検証結果となります。

設計検証

検証は内部の一貫性を証明する。妥当性確認は、そもそも仕様書が正しい製品を記述していたかどうかという、より難しい問いを投げかける。

設計検証 設計検証とは、エンドユーザーまたは利害関係者の要求事項に照らし合わせてソフトウェア製品を評価するプロセスです。設計検証の目的は、開発後にソフトウェア製品をテストし、ユーザー自身の環境で使用された際に要求事項を満たしていることを確認することです。

検証とは、ユーザーニーズに関して設計の一貫性と完全性を実証することです。この段階では、実際に製品のバージョンを作成し、ユーザー要件に照らして検証を行います。

下のバナーは、設計記録で通常示されるように、活動の2つの部分を示しています。

以下の図は、ユーザーのニーズから検証済みの製品に至るまでの設計検証プロセスそのものを示しています。

その目的は、製品が文書化されたユーザーニーズを満たしていることを客観的な証拠で証明することです。客観的な証拠とは、手順が実際に実行されたことを示す、出力の物理的な証拠（画像、テキストファイル、音声ファイル、署名入りの報告書など）のことです。

その客観的な証拠を通して、プロセスは製品が事前に定義された要件を満たしているかどうかを一貫して検証します。テスト活動、検査、分析、および同様の技術が含まれるため、検証は通常、 システムテスト (NAIST) と ユーザー受け入れテスト ユニットレベルのチェックではなく。

設計検証と検証の違い

検証と妥当性確認は、常に誤解されがちです。これらは異なる活動であり、単一のマイルストーンではなく、開発プロセスのあらゆる段階で実施されます。

便利なショートカット: 検証はほとんどの場合 静的作業 文書に対して検証を行うが、検証は主に 動的テスト 実行中のビルドに対して。

設計検証プロセス

検証プロセスは5つの段階で実行され、各段階で次の段階の前提条件となる成果物が生成されます。

識別と準備:

• 仕様策定と並行して、検証活動も特定されます。これにより、設計者は仕様が実際に検証可能であることを確認でき、テストエンジニアは詳細なテスト計画と手順の作成に着手できます。仕様に変更が生じた場合は、必ず関係者に通知する必要があります。
• 検証を実施するための最適なアプローチを特定し、測定方法、必要なリソース、ツール、および設備を定義する。
• 完成した検証計画は、計画を最終決定する前に、設計チームとレビューして問題点を明らかにする。

計画：

• 検証計画は、コアチームおよび開発チームと並行して行われる活動です。プロジェクトのライフサイクル全体を通して実施され、設計入力に変更が生じるたびに更新されます。
• この段階では、テスト対象のソフトウェアまたはシステムの範囲が文書化されます。
• 予備的なテスト計画を作成し、その後、内容を精査する。この計画には、プロジェクトのリスクを軽減する重要なマイルストーンが盛り込まれている。
• ツール、テスト環境、開発戦略を選定し、検査または分析によって確認すべき要件を特定する。

開発ping:

• テストケース 開発は SDLC 方法論 プロジェクトチームは既に実装を完了している。この段階では、様々なテスト方法が特定されている。
• 設計入力は、最も単純な検証活動でさえも曖昧さがなく検証可能となるように開発されなければならない。
• 類似の概念を連続して検証すると、あるテストの出力を次のテストの入力として再利用できるため、検証時間が短縮される。
• Tracテストケースとそれに対応する設計入力との間に検証可能性のリンクが作成され、すべての要件がテストされ、設計出力が設計入力を満たすことが保証されます。

実行：

• 開発段階で作成されたテスト手順は、テスト計画に従って実行され、検証活動中も厳密に遵守される。
• 無効な結果が生じた場合、または手順の変更が必要な場合は、変更内容を文書化し、正式に承認を得なければならない。
• 発見された問題はすべて通常の方法で欠陥として記録されます 欠陥管理プロセス.
• A trac能力マトリックス これは、検証テスト計画で特定されたすべての設計入力がテストされたことを確認し、合格率を決定するために作成されます。

レポート：

• このアクティビティは、検証実行の各フェーズの終了時に実行されます。
• 設計検証レポートには、構成管理、各テストタイプの結果、検証活動中に発見された問題点など、検証結果の詳細な概要が記載されています。
• 設計検証 trac要件とそれに対応するテスト結果との間の整合性レポートは、すべての要件がテストされ、適切な結果が記録されたことを確認するために作成されます。
• 不適合事項はすべて文書化され、適切に対処されます。
• Rev設計検証活動の完了後、レビューが実施され、その成果物が正式に承認される。

設計検証プロセス

検証には、厳密な手順というものは存在しません。むしろ、少数の承認された手法に基づいて行われ、プロジェクトでは通常、それらの手法のうち複数が使用されます。

• 同等の設計との比較。 設計によっては、同様の目的で使用される類似機器と比較することで妥当性を検証できる場合があります。これは、既存のインフラストラクチャに対する構成変更を検証する場合や、新しいシステムやアプリケーションに組み込まれる標準設計を検証する場合に特に重要です。
• 実演および検査。 製品の要件やその他の機能を検証するために、どちらか一方、または両方を使用することができます。
• 分析。 設計は、数学的モデリングや、必要な機能を再現するシミュレーションによって分析することができる。
• テスト。 最終設計に対してテストを実施し、システムが仕様どおりに動作する能力を検証します。 機能テスト (NAIST) と 非機能テスト ユーザーの要求を満たす。
• ドキュメンテーション。 テスト計画、実行、および結果は、設計記録の一部として文書化および保管する必要があります。検証とは、最終的に、すべての検証活動の結果を集約したものです。
• 同等性の正当化。 最終設計検証において同等製品を使用する場合、製造業者は類似点および初期生産品との相違点を文書化しなければならない。

例:

簡単な例題を挙げれば、その違いが明確になる。

• 例えば、シンプルな製品である防水腕時計を例にとってみましょう。
• 製品要件書には、「時計は水泳中も防水でなければならない」と記載されているかもしれません。これがユーザーのニーズであり、検証の基準となります。
• 設計仕様書には、「ユーザーが長時間水泳をしても時計は正常に機能しなければならない」と記載されているかもしれません。これが設計上の入力であり、検証の基準となります。
• テスト結果によって、時計がこれらの要件を満たしていることが確認されるはずです。もし満たしていない場合は、満たすまで設計変更を繰り返します。

時計が検証を通過しても、妥当性確認に失敗する可能性がある点に注目してください。仕様で長時間水泳を15分と定義していて、実際の水泳選手が1時間水中に留まる場合、設計出力は入力と完全に一致していても、ユーザーにとっては不合格となる可能性があります。

設計の検証と検証の利点

両方の活動を最後に区切るのではなく、継続的に実行することで、以下のようなメリットが得られます。

• 設計は継続的に監視できるため、あらゆる段階でユーザーが定義した要件を満たすことが可能になります。
• 設計を検証することで、実際の機能の動作と期待される動作との違いが明らかになる。
• 検証手順を文書化しておくことで、後々変更や機能強化が行われた際に、その機能を容易に理解できるようになります。
• 開発期間が着実に短縮され、生産性が向上することで、期待通りの製品提供が可能になります。
• このプロセスでは、採用しなければならない各検証方法の範囲と適用範囲が定義されます。
• 検証は、最終ユーザーの要求事項を表す詳細な設計データを用いて実施できる。
• 結果とユーザーニーズ文書との間の差異は、失われることなく記録される。
• 検証済みの設計に変更が加えられると、再検証活動がトリガーされるため、記録が製品から乖離することはありません。
• 検証中に発生するすべての活動を文書化することが、設計がユーザー要件を満たしていることを適切に証明する。

したがって、設計検証と妥当性確認は、より広範な計画の中で行うのが最善である。 ソフトウェアテストのライフサイクル そして他のものとマッピングする ソフトウェアテストの種類個別のコンプライアンス活動として扱われるのではなく。

よくあるご質問