logo

TechCodeview

SDLC V モデル – ソフトウェア エンジニアリング

V モデルは次のタイプです。 SDLCモデル ここで、プロセスは V 字型に順次実行されます。これは、検証および検証モデルとしても知られています。これは、対応する各開発段階のテスト段階の関連付けに基づいています。各ステップの開発はテスト段階に直接関連付けられています。次のフェーズは、前のフェーズの完了後にのみ開始されます。つまり、開発アクティビティごとに、それに対応するテスト アクティビティが存在します。

目次



10の6乗

V モデルは、ソフトウェア開発プロセスを体系的かつ視覚的に表現するソフトウェア開発ライフ サイクル (SDLC) モデルです。これは、V 字のアイデアに基づいており、V の 2 本の脚が進行を表しています。 ソフトウェア開発プロセス から 要件の収集 分析から設計、実装、テスト、メンテナンスまで。

V モデルの設計

  1. 要件の収集と分析 : V モデルの最初のフェーズは要件の収集と分析のフェーズで、ソフトウェアに対する顧客の要件が収集および分析され、プロジェクトの範囲が決定されます。
  2. デザイン： 設計フェーズでは、上位設計と詳細設計を含むソフトウェアのアーキテクチャと設計が開発されます。
  3. 実装： 実装フェーズでは、設計に基づいてソフトウェアが構築されます。
  4. テスト: テスト段階では、ソフトウェアが顧客の要件を満たし、高品質であることを確認するためにテストされます。
  5. 導入: 導入フェーズでは、ソフトウェアが導入され、使用されます。
  6. メンテナンス： メンテナンス フェーズでは、ソフトウェアが顧客のニーズと期待を確実に満たし続けるようにメンテナンスされます。
  7. V モデルは安全のためによく使用されます。 徹底的なテストとソフトウェア開発プロセスに含まれるステップを明確に定義する能力に重点を置いているため、航空宇宙システムや防衛システムなどの重要なシステムに最適です。

SDLC V モデル

次の図は、SDLC の V モデルのさまざまなフェーズを示しています。



検証 フェーズ :

これには、コードを実行せずに実行される静的分析手法 (レビュー) が含まれます。製品開発段階において、指定された要件が満たされているかどうかを評価するプロセスです。

V モデルにはいくつかの検証フェーズがあります。

ビジネス要件の分析:



これは、顧客の観点から製品要件を解決する必要がある開発サイクルの指定の最初のステップです。これらのフェーズには、顧客の要件を理解するための顧客との適切なコミュニケーションが含まれます。これらは、適切に処理する必要がある非常に重要なアクティビティです。ほとんどの場合、顧客は自分が何を望んでいるのか正確にわかっておらず、その時点でもそれについて確信が持てないため、当社では 受け入れテストの設計 ビジネス要件の際に行われる計画は、 入力 受け入れテスト用。

システムデザイン：

システムの設計は、製品要件が全体的に明確になった時点で開始され、その後、システムを完全に設計する必要があります。この理解は、製品開発プロセスの開始時点で完了します。これらは、将来のテスト ケースの実行に役立ちます。

建築デザイン：

この段階では、アーキテクチャの仕様が理解され、設計されます。通常、いくつかの技術的アプローチが提案され、技術的および財務的実行可能性の両方を考慮した上で最終的な選択が行われます。システム アーキテクチャはさらに、それぞれが異なる機能を処理するモジュールに分割されます。これの別名は、ハイレベル デザイン (HLD) です。

この時点で、内部モジュールと外部システム間のデータ交換と通信は十分に理解され、定義されています。このフェーズでは、提供された情報を使用して統合テストを作成し、文書化できます。

モジュール設計:

ローレベル設計 (LLD) として知られるこのフェーズでは、すべてのシステム モジュールの包括的な内部設計を指定します。設計と他の外部システムおよびシステム アーキテクチャ内の他のモジュールとの間の互換性は非常に重要です。単体テストは、初期段階で大部分の間違いや欠陥を特定して取り除くのに役立つため、あらゆる開発プロセスの重要な要素です。内部モジュール設計に基づいて、これらの単体テストを作成できるようになります。

コーディングフェーズ:

コーディングのステップには、設計フェーズで作成されたシステム モジュールのコードを記述することが含まれます。システム要件とアーキテクチャ要件は、どのプログラミング言語が最も適切かを決定するために使用されます。

コーディングを実行するときは、コーディング標準と原則に従います。最終ビルドがリポジトリにチェックインされる前に、コードは多くのコード レビューを受け、最適なパフォーマンスが得られるように最適化されます。

検証 フェーズ :

これには、動的分析手法 (機能的および非機能的) と、コードを実行することによるテストが含まれます。検証は、開発フェーズの完了後にソフトウェアを評価し、ソフトウェアが顧客の期待と要件を満たしているかどうかを判断するプロセスです。

したがって、V モデルには、一方の側に検証フェーズが含まれ、もう一方の側には検証フェーズが含まれます。検証フェーズと検証フェーズは、コーディング フェーズによって V 字型に結合されます。したがって、それは V モデルと呼ばれます。
いくつかあります 検証 V モデルのフェーズ:

単体テスト:

単体テスト計画は、モジュール設計段階で作成されます。これらの単体テスト計画は、コードまたは単体レベルのバグを排除するために実行されます。

Javaのバブルソート

統合テスト:

単体テスト終了後、結合テストを実施します。統合テストでは、モジュールが統合され、システムがテストされます。統合テストはアーキテクチャ設計段階で実行されます。このテストは、モジュール間の通信を検証します。

システムテスト:

システム テストでは、アプリケーション全体の機能、相互依存性、通信をテストします。開発されたアプリケーションの機能要件と非機能要件をテストします。

ユーザー受け入れテスト (UAT):

UAT は、運用環境に似たユーザー環境で実行されます。 UAT は、提供されたシステムがユーザーの要件を満たしていること、およびシステムが現実世界で使用できる状態にあることを検証します。

設計段階:

  • 要件分析: このフェーズには、顧客の要件と期待を理解するための顧客との詳細なコミュニケーションが含まれます。この段階は要件収集として知られています。
  • システムデザイン： このフェーズには、製品開発のためのシステム設計と完全なハードウェアおよび通信セットアップが含まれます。
  • 建築デザイン： システム設計は、さまざまな機能を担うモジュールにさらに分割されます。内部モジュール間および外部 (他のシステム) とのデータ転送と通信が明確に理解されています。
  • モジュール設計: このフェーズでは、システムは小さなモジュールに分割されます。モジュールの詳細な設計が指定されており、ローレベル設計 (LLD) とも呼ばれます。

テスト段階:

  • 単体テスト: 単体テスト計画は、モジュール設計段階で作成されます。これらの単体テスト計画は、コードまたは単体レベルでバグを排除するために実行されます。
  • 統合テスト: 単体テスト終了後、結合テストを実施します。統合テストでは、モジュールが統合され、システムがテストされます。統合テストはアーキテクチャ設計段階で実行されます。このテストは、モジュール間の通信を検証します。
  • システムテスト: システム テストでは、アプリケーション全体の機能、相互依存性、通信をテストします。開発されたアプリケーションの機能要件と非機能要件をテストします。
  • ユーザー受け入れテスト (UAT): UAT は、運用環境に似たユーザー環境で実行されます。 UAT は、提供されたシステムがユーザーの要件を満たしていること、およびシステムが現実世界で使用できる状態にあることを検証します。

産業上の課題:

業界が進化するにつれて、テクノロジーはより複雑になり、ますます高速になり、永遠に変化していますが、IT の初期の頃と同様に現在でも適用できる一連の基本原則と概念が依然として残っています。

  • ユーザー要件を正確に定義し、調整します。
  • 許可されたユーザーの要件に従ってアプリケーションを設計および構築します。
  • 構築したアプリケーションが承認されたビジネス要件に準拠していることを検証します。

V モデルの重要性

1. 欠陥の早期特定

V モデルは、検証および検証タスクを開発プロセスのあらゆる段階に組み込むことで、早期のテストを促進します。これにより、障害の早期検出と解決が容易になり、開発ライフサイクルの後半で問題を解決するために必要なコストと労力が削減されます。

2. 開発とテストのフェーズの決定

V モデルには、開発プロセスの各段階に対応するテスト フェーズが含まれています。テストと開発のプロセスを明確に計画することにより、この明確なマッピングにより、ソフトウェア エンジニアリングへの系統的かつ秩序あるアプローチが促進されます。

3. ビッグバンテストの防止

従来の開発モデルでは、テストは開発ライフサイクルの最後に行われることが多く、その結果、すべてのテスト操作が一度に集中するビッグバン アプローチになります。 V モデルは、テスト活動を開発プロセスに統合し、より進歩的で規制されたテスト アプローチを奨励することで、これを防ぎます。

4. 協力関係の改善

V モデルはあらゆるレベルで、テスト チームと開発チーム間の協力を促進します。このコラボレーションを通じて、プロジェクトの要件、設計の選択、およびテスト方法がよりよく理解され、開発プロセスの有効性と効率が向上します。

5. 品質保証の向上

全体的な品質保証は、あらゆるレベルでのテスト操作を組み込んだ V モデルによって強化されます。プログラムが最終展開段階に到達する前に、要件を満たしていることを確認し、厳格な検証と検証プロセスを経ます。

V モデルの原理

  • 大から小まで: V-Model では、プロジェクト チームによって特定された要件、高レベル設計の作成、およびプロジェクトの詳細設計フェーズなど、階層的な観点でテストが実行されます。これらの各フェーズが完了するにつれて、要件の定義はますます洗練され、詳細になっていきます。
  • データ/プロセスの整合性: この原則は、プロジェクトの設計を成功させるには、データとプロセスの両方を組み込み、統合する必要があると述べています。プロセス要素は要件ごとに特定する必要があります。
  • スケーラビリティ: この原則は、V モデルの概念には、その規模、複雑さ、期間に関係なく、あらゆる IT プロジェクトに対応できる柔軟性があることを示しています。
  • 相互参照: 要件と対応するテスト アクティビティ間の直接の相関関係は、相互参照として知られています。

有形の文書:

この原則は、すべてのプロジェクトがドキュメントを作成する必要があることを示しています。この文書はプロジェクト開発チームとサポート チームの両方に必要であり、適用されます。ドキュメントは、アプリケーションが運用環境で利用可能になった後、アプリケーションを保守するために使用されます。

なぜ好まれるのでしょうか？

  • 剛性の高いモデルなので扱いやすいです。 V モデルの各フェーズには、特定の成果物とレビュー プロセスがあります。
  • 積極的な欠陥追跡 – つまり、欠陥は初期段階で発見されます。

いつ使用するか の Vモデル ?

  • 要件のトレーサビリティ: V モデルは、要件とそれに関連するテスト ケースの間で正確なトレーサビリティを作成することが不可欠な状況で有益であることが証明されています。
  • 複雑なプロジェクト: V モデルは、テスト活動を管理し、高度な複雑さとシステム コンポーネント間の相互依存性を伴うプロジェクトの統合やインターフェイスの問題に関連するリスクを軽減する体系的な方法を提供します。
  • ウォーターフォールのようなプロジェクト : V モデルは、開発のあらゆるレベルでテスト活動を組織、実行、監視するための親しみやすい構造を提供するため、ウォーターフォール モデルと同様に、開発に逐次的なアプローチを使用するプロジェクトに適しています。
  • セーフティクリティカルなシステム: これらのシステムは、航空宇宙、自動車、医療業界で使用されています。彼らは、必須のシステム要件が満たされていること、および開発プロセスの早い段階で潜在的なリスクが発見され排除されていることを保証するのに役立つ厳格な検証および妥当性確認手順に重点を置いています。

利点 Vモデルの

  • これは高度に規律あるモデルであり、フェーズは一度に 1 つずつ完了します。
  • V-Model は、プロジェクト要件が明確な小規模プロジェクトに使用されます。
  • シンプルで理解しやすく、使いやすい。
  • このモデルは、ライフサイクルの初期段階での検証と妥当性確認の活動に焦点を当てており、それによってエラーのない高品質の製品を構築する可能性が高まります。
  • これにより、プロジェクト管理が進捗状況を正確に追跡できるようになります。
  • 明確で構造化されたプロセス: V モデルは、明確で構造化されたプロセスを提供します。 ソフトウェア開発 、理解しやすくなり、フォローしやすくなります。
  • テストの重視: V モデルはテストを重視しており、ソフトウェアの品質と信頼性の確保に役立ちます。
  • トレーサビリティの向上: V モデルは要件と最終製品の間に明確なリンクを提供し、ソフトウェアへの変更の追跡と管理を容易にします。
  • コミュニケーションの向上: V モデルの明確な構造は、顧客と開発チーム間のコミュニケーションの向上に役立ちます。

Vモデルのデメリット

  • 高いリスクと不確実性。
  • 複雑なオブジェクト指向のプロジェクトには適していません。
  • 要件が明確でなく、変更のリスクが高いプロジェクトには適していません。
  • このモデルはフェーズの反復をサポートしていません。
  • 同時発生するイベントを簡単に処理することはできません。
  • 柔軟性のなさ: V モデルは線形かつ逐次的なモデルであるため、要件の変化や予期せぬ出来事に適応することが困難になる可能性があります。
  • 時間がかかる: V モデルは多くの文書化とテストが必要なため、時間がかかる場合があります。
  • ドキュメントへの過度の依存: V モデルはドキュメントに重点を置いているため、実際の開発作業を犠牲にしてドキュメントへの過度の依存につながる可能性があります。

結論

ソフトウェア開発ライフ サイクル (SDLC) に対する科学的かつ組織的なアプローチは、ソフトウェア エンジニアリング V モデルによって提供されます。 V モデルを含む SDLC モデルを選択するときは、選択した方法論に関するチームの専門知識、プロジェクトの独自の機能、要件の性質をすべて考慮する必要があります。

参考書：

『Software Engineering: A Practitioner’s Approach』Roger S. Pressman 著、McGraw-Hill Education 発行、2017 年。