Sdlc-v-model
SDLC-Vモデル
Vモデルは、プロセスの実行がVシェイプで連続的に発生するSDLCモデルです。 *検証と検証モデル*とも呼ばれます。
Vモデルはウォーターフォールモデルの拡張であり、対応する各開発段階のテストフェーズの関連付けに基づいています。 これは、開発サイクルの各フェーズごとに、直接関連付けられたテストフェーズがあることを意味します。 これは高度に規律化されたモデルであり、次のフェーズは前のフェーズの完了後にのみ開始されます。
Vモデル-デザイン
Vモデルの下では、開発フェーズの対応するテストフェーズが並行して計画されます。 そのため、「V」の一方には検証フェーズがあり、もう一方には検証フェーズがあります。 コーディングフェーズは、Vモデルの2つの側面を結合します。
次の図は、SDLCのVモデルのさまざまなフェーズを示しています。
Vモデル-検証フェーズ
Vモデルにはいくつかの検証フェーズがあり、それぞれについて以下で詳しく説明します。
ビジネス要件分析
これは開発サイクルの最初のフェーズであり、製品の要件が顧客の観点から理解されます。 このフェーズでは、顧客との詳細なコミュニケーションを行い、顧客の期待と正確な要件を理解します。 これは非常に重要なアクティビティであり、ほとんどの顧客は正確に何が必要かわからないため、適切に管理する必要があります。 ビジネス要件を受け入れテストの入力として使用できるため、*受け入れテスト設計計画*はこの段階で行われます。
システム設計
明確で詳細な製品要件を取得したら、完全なシステムを設計します。 システム設計には、開発中の製品の完全なハードウェアおよび通信セットアップの理解と詳細が含まれます。 システムテスト計画は、システム設計に基づいて作成されます。 より早い段階でこれを行うと、後で実際のテストを実行する時間が長くなります。
建築デザイン
アーキテクチャ仕様は、このフェーズで理解および設計されます。 通常、複数の技術的アプローチが提案され、技術的および財務的な実現可能性に基づいて最終決定が行われます。 システム設計は、さまざまな機能を使用するモジュールにさらに分割されます。 これは、* High Level Design（HLD）*とも呼ばれます。
内部モジュール間および外部世界（他のシステム）とのデータ転送および通信は、この段階で明確に理解および定義されています。 この情報を使用して、この段階で統合テストを設計および文書化できます。
モジュール設計
この段階では、すべてのシステムモジュールの詳細な内部設計が指定され、*低レベル設計（LLD）*と呼ばれます。 設計がシステムアーキテクチャの他のモジュールおよび他の外部システムと互換性があることが重要です。 単体テストは開発プロセスの重要な部分であり、非常に早い段階で最大の障害とエラーを排除するのに役立ちます。 これらの単体テストは、内部モジュールの設計に基づいて、この段階で設計できます。
コーディング段階
設計段階で設計されたシステムモジュールの実際のコーディングは、コーディング段階で行われます。 システムとアーキテクチャの要件に基づいて、最適なプログラミング言語が決定されます。
コーディングは、コーディングのガイドラインと標準に基づいて実行されます。 コードは多数のコードレビューを経て、最終ビルドがリポジトリにチェックインされる前に最高のパフォーマンスが得られるように最適化されます。
検証フェーズ
Vモデルのさまざまな検証フェーズについて、以下で詳しく説明します。
単体テスト
モジュール検証段階で設計された単体テストは、この検証段階でコードに対して実行されます。 ユニットテストはコードレベルでのテストであり、バグを早期に排除するのに役立ちますが、ユニットテストではすべての欠陥を発見することはできません。
統合テスト
統合テストは、アーキテクチャ設計段階に関連付けられています。 統合テストは、システム内の内部モジュールの共存と通信をテストするために実行されます。
システムテスト
システムのテストは、システムの設計段階に直接関連付けられています。 システムテストは、システム全体の機能と、開発中のシステムと外部システムとの通信をチェックします。 このシステムテストの実行中に、ソフトウェアとハードウェアの互換性の問題のほとんどが明らかになります。
受け入れ試験
受け入れテストはビジネス要件分析フェーズに関連付けられており、ユーザー環境での製品のテストが含まれます。 受け入れテストは、ユーザー環境で利用可能な他のシステムとの互換性の問題を明らかにします。 また、実際のユーザー環境での負荷やパフォーマンスの欠陥など、機能しない問題も検出します。
V-モデル─アプリケーション
V-Modelアプリケーションは、両方のモデルがシーケンシャルタイプであるため、ウォーターフォールモデルとほぼ同じです。 プロジェクトを開始する前に、要件を明確にする必要があります。通常、戻って変更を加えるのは費用がかかるためです。 このモデルは、厳密に統制されたドメインであるため、医療開発分野で使用されます。
以下のポインターは、V-Modelアプリケーションを使用するのに最も適したシナリオの一部です。
- 要件は明確に定義され、明確に文書化され、修正されています。
- 製品の定義は安定しています。
- 技術は動的ではなく、プロジェクトチームがよく理解しています。
- あいまいな要件や未定義の要件はありません。
- プロジェクトは短いです。
Vモデル-長所と短所
V-Modelメソッドの利点は、理解と適用が非常に簡単なことです。 このモデルのシンプルさにより、管理も容易になります。 欠点は、モデルが変更に対して柔軟ではないことと、今日のダイナミックな世界で非常に一般的な要件の変更がある場合に、変更を行うのに非常に費用がかかることです。
V-Modelメソッドの利点は次のとおりです-
- これは高度に規律化されたモデルであり、フェーズは1つずつ完了します。
- 要件が十分に理解されている小規模プロジェクトに適しています。
- シンプルで理解しやすく使いやすい。
- モデルの剛性により管理が簡単です。 各フェーズには、特定の成果物とレビュープロセスがあります。
V-Modelメソッドの欠点は次のとおりです-
- 高いリスクと不確実性。
- 複雑でオブジェクト指向のプロジェクトには適したモデルではありません。
- 長く進行中のプロジェクトの貧弱なモデル。
- 要件が変更されるリスクが中程度から高いプロジェクトには適していません。
- アプリケーションがテスト段階に入ると、戻って機能を変更することは困難です。
- ライフサイクルの後半まで動作するソフトウェアは作成されません。
