設計検証と検証プロセス

設計検証

設計検証 エンドユーザーまたは利害関係者の要件を正確に満たすようにソフトウェア製品を評価するプロセスです。 設計検証の目的は、開発後にソフトウェア製品をテストして、ユーザー環境のアプリケーションに関する要件を満たしていることを確認することです。

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

下の画像は、設計検証プロセスを表しています。

その目的は、製品がユーザーニーズの文書を満たしていることを客観的な証拠で証明することです。 客観的証拠とは、手順が完了したことを示す画像、テキスト、音声ファイルなどの出力の物理的証拠に他なりません。

このプロセスでは、客観的な証拠を通じて、製品が事前に定義された要件を満たしているかどうかを一貫して検査します。 このプロセスには、テスト活動、検査、分析などが含まれます。

設計検証

設計検証 設計されたソフトウェア製品の出力が入力仕様を満たしているかどうかを、証拠を調べて提供することによって確認する方法です。 ソフトウェア開発における設計検証プロセスの目標は、設計されたソフトウェア製品が指定されたものと同じであることを確認することです。

設計入力は、設計目的の基礎として使用される物理的要件とパフォーマンス要件です。 設計出力は、各設計フェーズの結果であり、設計作業全体の終了時に得られます。 最終的な設計出力は、デバイスのマスター記録の基礎となります。

設計検証と検証の違い

検証と検証の間には常に誤解があります。 これらは、開発プロセスのあらゆる段階で実行されるさまざまなアクティビティです。

設計検証プロセス

識別と準備:

• 仕様の開発段階では、検証アクティビティの特定が並行して行われます。 これにより、設計者は仕様が検証可能であることを確認できます。 そのため、テスト エンジニアは詳細なテスト計画と手順を開始できます。 仕様の変更はすべて通知する必要があります。
• 検証を実施するための最適なアプローチを特定し、測定方法、必要なリソース、ツール、設備を定義します。
• 完成した検証計画は、計画を最終決定する前に設計チームとレビューされ、問題が特定されます。

計画：

• 検証の計画は、コア チームと開発チームが同時に行う作業です。 これはプロジェクトのライフサイクル全体を通じて発生します。 これは、設計入力に変更が加えられると随時更新されます。
• このフェーズでは、テスト対象のソフトウェアまたはシステムを範囲内で文書化する必要があります。
• 予備的なテスト計画とテスト計画の改良はこの段階で行われます。 テスト計画は、プロジェクトのリスクを軽減する重要なマイルストーンを捉えます。
• ツール、テスト環境、開発戦略、検査または分析による要件の特定。

現像：

• テストケースの開発は次の時期と一致します。 SDLC 方法論 プロジェクトチームによって実装されました。 この段階では、さまざまなテスト方法が特定されます。
• 設計入力は、明確で検証可能な最も単純な検証アクティビティを含めて開発する必要があります。
• 同様のコンセプトを連続して実行すると、検証時間が短縮されます。1 つのテストの出力を後続のテストの入力として使用することもできます。
• すべての要件がテストされ、設計出力が設計入力を満たしていることを確認するために、テスト ケースと対応する設計入力の間に扱いやすさのリンクが作成されます。

実行：

• 開発フェーズ中に作成されたテスト手順は、テスト計画に従って実行され、検証アクティビティで厳密に従います。
• 無効な結果が発生した場合、または手順の変更が必要な場合は、変更内容を文書化し、適切な承認を得ることが重要です。
• この段階で問題が特定され、欠陥として記録されます。
• 扱いやすさマトリックス 検証テスト計画で特定されたすべての設計入力がテストされたことを検証し、合格率を決定するために作成されます。

レポート：

• このアクティビティは、検証実行の各フェーズの終了時に実行されます。
• 設計検証レポートには、構成管理、各種テストのテスト結果、検証活動中に見つかった問題など、検証結果の詳細な概要が示されます。
• 設計検証トレーサビリティ レポートは、要件と対応するテスト結果の間で作成され、すべての要件がテストされ、適切な結果が得られたことを検証します。
• 不適合はすべて文書化され、適切に対処されます。
• Rev設計検証活動の完了時にレビューが行われ、それぞれ承認されます。

設計検証プロセス

• 一部の設計は、同様の目的を実行する同様の機器と比較することによって検証される場合があります。 この方法は、既存のインフラストラクチャの構成変更、または新しいシステムやアプリケーションに組み込まれる標準設計の検証に特に関連します。
• 製品の要件やその他の機能を検証するために、デモンストレーションや検査が使用される場合があります。
• 設計の分析は、数学的モデリングや、必要な機能を再現できるシミュレーションなどを行うことができます。
• 最終設計に対してテストが実行され、指定された設計どおりにシステムが動作する能力が検証されます。
• テスト計画、実行、結果は文書化され、設計記録の一部として維持される必要があります。 したがって、検証はすべての検証アクティビティの結果の集合です。
• 最終的な設計検証で同等の製品が使用される場合、製造業者は、初期生産との類似性、および相違点がある場合にはそれを文書化する必要があります。

例

• シンプルな製品である防水時計を例に考えてみましょう。
• 製品要件文書には、「時計は水泳時の防水性を備えていなければなりません」と記載されている場合があります。
• 設計仕様には、「ユーザーが長時間泳いでも時計が機能する必要がある」と記載されている場合があります。
• テスト結果により、時計がこれらの要件を満たしていることが確認されます。そうでない場合は、要件を満たすまで再設計が繰り返されます。

設計の検証と検証の利点

• 設計を継続的に監視できるため、あらゆる段階でユーザー定義の要件を満たすことができます。
• 設計を検証すると、機能の動作方法と期待される動作の違いが指摘されます。
• 検証手順を文書化すると、将来的に変更や機能強化が行われた場合に、どの段階でも機能を簡単に理解できるようになります。
• 開発時間が継続的に短縮され、生産性が向上し、期待どおりの製品を提供できるようになります。
• このプロセスには、採用する必要がある各検証方法の範囲と適用範囲が含まれます。
• 検証は、最終的なユーザー要件を表す詳細な設計データを使用して実行できます。
• 結果とユーザーが必要とする文書との間の差異をすべて記録する必要があります。
• 検証設計の変更により、再検証アクティビティが発生します。
• 検証中に発生するすべてのアクティビティを文書化することが重要です。これにより、設計がユーザーの要件を満たしていることが適切に証明されます。