V モデルは、検証および検証モデルとも呼ばれます。この場合、SDLC の各フェーズは、次のフェーズが開始される前に完了する必要があります。ウォーターフォール モデルと同じ一連の設計プロセスに従います。デバイスのテストは、開発の対応する段階と並行して計画されています。
検証: これには、コードを実行せずに実行される静的分析手法 (レビュー) が含まれます。製品開発プロセスにおいて、指定された要件を満たしているかどうかを評価するプロセスです。
検証: これには動的分析手法 (機能的、非機能的) が含まれ、テストはコードを実行することによって行われます。検証は、開発プロセスの完了後にソフトウェアを分類し、ソフトウェアが顧客の期待と要件を満たしているかどうかを判断するプロセスです。
したがって、V モデルには、一方の側に検証フェーズが含まれ、もう一方の側には検証フェーズが含まれます。検証と検証のプロセスは、V 字型のコーディング フェーズによって結合されます。したがって、それは V モデルとして知られています。
V モデルの検証フェーズにはさまざまなフェーズがあります。
ビジネス要件の分析: | これは、顧客側から製品要件を理解する最初のステップです。このフェーズには、顧客の期待と正確な要件を理解するための詳細なコミュニケーションが含まれます。
システムデザイン: | この段階では、システムエンジニアは、ユーザー要件文書を検討して、提案されたシステムのビジネスを分析および解釈します。
建築デザイン: | アーキテクチャを選択する際のベースラインは、通常、モジュールのリスト、各モジュールの簡単な機能、それらのインターフェイスの関係、依存関係、データベース テーブル、アーキテクチャ図、テクノロジーの詳細などで構成されるすべてを理解する必要があることです。統合テスト モデルが実行されます。特定のフェーズでアウトします。
モジュール設計: | モジュール設計段階では、システムは小さなモジュールに分割されます。モジュールの詳細な設計が指定されます。これは低レベル設計として知られています。
コーディングフェーズ: | 設計後、コーディングフェーズが開始されます。要件に基づいて、適切なプログラミング言語が決定されます。コーディングにはいくつかのガイドラインと標準があります。リポジトリにチェックインする前に、最終ビルドはパフォーマンスが向上するように最適化され、コードはパフォーマンスをチェックするために多くのコード レビューを受けます。
V モデルの検証フェーズにはさまざまなフェーズがあります。
単体テスト: | V モデルでは、単体テスト計画 (UTP) はモジュール設計段階で開発されます。これらの UTP は、コード レベルまたはユニット レベルでエラーを排除するために実行されます。ユニットとは、独立して存在できる最小の実体 (プログラム モジュールなど) です。単体テストでは、最小のエンティティが残りのコード/ユニットから分離されたときに正しく機能できることを検証します。
統合テスト: | 統合テスト計画は、アーキテクチャ設計フェーズで作成されます。これらのテストでは、個別に作成およびテストされたグループが共存し、グループ間で通信できることを検証します。
システムテスト: | システム テスト計画は、システム設計フェーズで作成されます。単体テスト計画や統合テスト計画とは異なり、システム テスト計画はクライアントのビジネス チームによって作成されます。システム テストは、アプリケーション開発者の期待が満たされていることを確認します。
受け入れ試験: | 受け入れテストはビジネス要件の分析部分に関連します。これには、ユーザー環境でのソフトウェア製品のテストが含まれます。受け入れテストにより、ユーザー環境内で利用可能なさまざまなシステムとの互換性の問題が明らかになります。実際のユーザー環境における負荷やパフォーマンスの欠陥などの非機能的な問題も同時に発見します。
V モデルはいつ使用するのですか?
- 要件が明確に定義されており、曖昧ではない場合。
- V 字型モデルは、要件が明確に定義され固定されている小規模から中規模のプロジェクトに使用する必要があります。
- V 字型モデルは、重要な技術的専門知識を備えたサンプル技術リソースが利用可能な場合に選択する必要があります。
V モデルの利点 (長所):
- わかりやすい。
- 計画やテスト設計などのテスト方法は、コーディングよりかなり前に行われます。
- これにより時間を大幅に節約できます。したがって、ウォーターフォール モデルよりも成功する可能性が高くなります。
- 欠陥の下方への流れを防ぎます。
- 要件が容易に理解できる小規模な計画に適しています。
V モデルの欠点 (短所):
- 非常に硬く、柔軟性はほとんどありません。
- 複雑なプロジェクトには適していません。
- ソフトウェアは実装段階で開発されるため、ソフトウェアの初期プロトタイプは作成されません。
- 途中で変更があった場合は、必要な書類とともに試験書類も更新する必要があります。