Vモデル（ソフトウェア開発）

ソフトウェア開発において、Vモデル^[2]はウォーターフォールモデルの拡張と見なすことができる開発プロセスを表し、より一般的なVモデルの例です。プロセスステップは、直線的に下に移動するのではなく、コーディングフェーズの後に上方に曲がって、一般的なV字型を形成します。Vモデルは、開発ライフサイクルの各フェーズとそれに関連するテストフェーズとの関係を示しています。水平軸と垂直軸は、それぞれ時間またはプロジェクトの完了度（左から右）と抽象化のレベル（最も粗い粒度の抽象化が上）を表します。

検証プロセスの最初のステップである要件分析フェーズでは、ユーザーのニーズを分析してシステムの要件を収集します。このフェーズでは、理想的なシステムが実行する必要があるものを確立します。ただし、ソフトウェアの設計方法や構築方法は決定しません。通常、ユーザーにインタビューを行い、ユーザー要件ドキュメントと呼ばれるドキュメントが生成されます。

ユーザー要件ドキュメントには通常、ユーザーが期待するシステムの機能、インターフェース、パフォーマンス、データ、セキュリティなどの要件が記載されます。ビジネス アナリストは、このドキュメントを使用して、システムに関する理解をユーザーに伝えます。このドキュメントは、システム設計フェーズでシステム設計者向けのガイドラインとして機能するため、ユーザーはこのドキュメントを注意深く確認します。ユーザー受け入れテストはこのフェーズで設計されます。機能要件も参照してください。

インタビュー、アンケート、ドキュメント分析、観察、使い捨てプロトタイプ、ユースケース、ユーザーとの静的および動的ビュー など、ソフトおよびハード方法論の両方の要件を収集するためのさまざまな方法があります。

システム設計は、システム エンジニアがユーザー要件ドキュメントを研究して、提案されたシステムのビジネスを分析して理解するフェーズです。システム エンジニアは、ユーザー要件を実装できる可能性と手法を見つけ出します。要件のいずれかが実現不可能な場合は、ユーザーにその問題が通知されます。解決策が見つかり、それに応じてユーザー要件ドキュメントが編集されます。

開発フェーズの青写真となるソフトウェア仕様書が作成されます。この文書には、一般的なシステム構成、メニュー構造、データ構造などが含まれます。また、理解を助けるために、ビジネス シナリオの例、サンプル ウィンドウ、レポートが含まれる場合もあります。エンティティ ダイアグラムやデータ ディクショナリなどのその他の技術文書もこのフェーズで作成されます。システム テスト用の文書が準備されます。

コンピュータアーキテクチャとソフトウェアアーキテクチャの設計段階は、高レベル設計とも呼ばれます。アーキテクチャを選択する際の基準は、通常、モジュールのリスト、各モジュールの簡単な機能、それらのインターフェース関係、依存関係、データベース テーブル、アーキテクチャ図、技術の詳細などで構成されるすべてを実現することです。統合テスト設計は、特定の段階で実行されます。^[3]

モジュール設計フェーズは、低レベル設計とも呼ばれます。設計されたシステムは、より小さなユニットまたはモジュールに分割され、それぞれが説明されるため、プログラマーはすぐにコーディングを開始できます。低レベル設計ドキュメントまたはプログラム仕様には、モジュールの詳細な機能ロジックが疑似コードで含まれます。

• データベーステーブル、そのタイプとサイズを含むすべての要素
• 完全なAPIリファレンスを含むすべてのインターフェースの詳細
• すべての依存関係の問題
• エラーメッセージ一覧
• モジュールの完全な入力と出力。

この段階でユニットテストの設計が開発されます。

Vモデルでは、検証フェーズの各段階には、検証フェーズの対応する段階があります。^[4]以下は、Vモデルにおける検証の典型的な段階ですが、他の名前で呼ばれることもあります。

V モデルでは、ユニット テスト プラン (UTP) はモジュール設計フェーズで開発されます。これらの UTP は、コード レベルまたはユニット レベルでバグを排除するために実行されます。ユニットとは、独立して存在できる最小のエンティティ (プログラム モジュールなど) です。ユニット テストでは、最小のエンティティが残りのコード/ユニットから分離されたときに正しく機能するかどうかを検証します。

統合テスト計画は、アーキテクチャ設計フェーズ中に作成されます。これらのテストでは、個別に作成およびテストされたユニットが共存し、相互に通信できることを検証します。テスト結果は、顧客のチームと共有されます。

システム テスト プランは、システム設計フェーズで作成されます。ユニット テスト プランや統合テスト プランとは異なり、システム テスト プランはクライアントのビジネス チームによって作成されます。システム テストでは、開発されたアプリケーションからの期待が満たされていることを確認します。アプリケーション全体の機能、相互依存性、および通信がテストされます。システム テストでは、機能要件と非機能要件が満たされていることを確認します。負荷テスト、パフォーマンス テスト、ストレス テスト、回帰テストなどは、システム テストのサブセットです。

ユーザー受け入れテスト (UAT) 計画は、要件分析フェーズで作成されます。テスト計画はビジネス ユーザーによって作成されます。UAT は、実際のデータを使用して、実稼働環境に似たユーザー環境で実行されます。UAT は、提供されたシステムがユーザーの要件を満たし、システムがリアルタイムで使用できる状態にあることを確認します。

Vモデルは、アジャイル支持者やその他の人々から、さまざまな理由からソフトウェア開発の不適切なモデルであると批判されてきた。^{[5] [6] [7]}批判には次のようなものがある。

1. このモデルはソフトウェア開発プロセスを正確に反映するには単純すぎるため、管理者に誤った安心感を与える可能性があります。V モデルはソフトウェア開発のプロジェクト管理の視点を反映しており、ソフトウェア開発者やユーザーではなく、プロジェクト マネージャー、会計士、弁護士のニーズに適合します。
2. 初心者でも簡単に理解できますが、その初期の理解が役立つのは、初心者が開発プロセスと、実践で V モデルをどのように適応および拡張する必要があるかについてのより深い理解を習得した場合のみです。実践者が V モデルに対する素朴な見方に固執すると、それをうまく適用することが非常に難しくなります。
3. これは柔軟性に欠け、ソフトウェア開発に対する硬直的かつ直線的な見方を助長し、変化に対応する能力が本質的に備わっていません。
4. これはウォーターフォール モデルにわずかにバリエーションを加えただけなので、ウォーターフォール モデルと同じ批判を受けます。テスト、特に早期のテスト計画の重要性をより重視しています。ただし、V モデルに対する一般的な実際的な批判は、以前の段階が遅れているのに実装日が固定されている場合、開発の終わりの厳しい期間にテストが押し込まれることになるというものです。
5. これは、非効率的で効果のないテスト手法と一致しており、暗黙的にそれを奨励しています。暗黙的に、探索的テストではなく事前にテスト スクリプトを作成することを奨励しています。テスト担当者が、実際に存在するものを発見するのではなく、期待するものを探すことを奨励しています。また、テスト担当者がテストを計画して実行するための最も効果的で効率的な方法を選択することを奨励するのではなく、どちらかのレッグの同等のレベル間の厳格なリンク (ユーザー要件ドキュメントから派生したユーザー受け入れテスト プランなど) を奨励しています。
6. 一貫性と正確さに欠けています。V モデルが正確に何であるかについては、広く混乱が生じています。ほとんどの人が同意する要素に絞り込むと、ソフトウェア開発の陳腐で役に立たない表現になります。V モデルのメリットに関する意見の相違は、多くの場合、その定義に対する共通の理解が欠如していることを反映しています。

Vモデルの支持者は、Vモデルは進化しており、開発プロセス全体を通じて柔軟性と俊敏性をサポートしていると主張しています。^[8]彼らは、Vモデルは高度に規律されたアプローチであるだけでなく、安定したソフトウェア製品を構築するために必要な綿密な設計、開発、およびドキュメント化を促進すると主張しています。最近では、医療機器業界で採用されています。^{[9] [10]}

• 製品ライフサイクル管理
• システム開発ライフサイクル

• Roger S. Pressman:ソフトウェアエンジニアリング: 実践者のアプローチ、The McGraw-Hill Companies、ISBN 0-07-301933-X 
• Mark Hoffman & Ted Beaumont:アプリケーション開発: プロジェクトライフサイクルの管理、Mc Press、ISBN 1-883884-45-4 
• Boris Beizer:ソフトウェアテストテクニック。第 2 版、International Thomson Computer Press、1990 年、ISBN 1-85032-880-3 

ウィキメディア・コモンズには、V モデルに関連するメディアがあります。