V字モデル (ソフトウェア開発)

**V字モデル**は、ソフトウェア開発において、ウォーターフォール・モデルの拡張と見なされる開発プロセスである。プロセスが直線的に下に進むのではなく、コーディングフェーズの後に上に向かって折り返され、典型的なV字型を形成する。V字モデルは、開発ライフサイクルの各フェーズと、それに関連するテストフェーズとの関係を示している。横軸は時間またはプロジェクトの完了度（左から右へ）、縦軸は抽象化のレベル（一番上が最も粗い抽象化）を表している。

## プロジェクト定義フェーズ

### 要件分析
検証プロセスの最初のステップである要件分析フェーズでは、ユーザーのニーズを分析することでシステムの要件が収集される。このフェーズでは、理想的なシステムが何を実行すべきかという方向性を決める。しかし、ソフトウェアがどのように設計・構築されるかについては決定しない。通常、ユーザーへのインタビューが行われ、要件定義書と呼ばれる文書が生成される。

要件定義書には、通常、ユーザーが期待するシステムの機能、インターフェース、パフォーマンス、データ、セキュリティなどの要件が記述される。これはビジネスアナリストがシステムに対する理解をユーザーに伝えるために使用される。ユーザーはこの文書を入念にレビューする。なぜなら、この文書はシステム設計フェーズにおいてシステム設計者のガイドラインとして機能するからである。ユーザー受入テストはこのフェーズで設計される。機能要件も参照のこと。

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

### システム設計
システム設計は、システムエンジニアが要件定義書を調査することで、提案されたシステムのビジネスを分析し理解するフェーズである。彼らは、ユーザー要件を実装するための可能性と技術を見つけ出す。要件のいずれかが実現不可能である場合、ユーザーにその問題が通知される。解決策が見つけられ、それに応じて要件定義書が編集される。

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

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

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

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

単体テストの設計はこの段階で開発される。

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

### 単体テスト
V字モデルでは、単体テスト計画（UTPs）はモジュール設計フェーズ中に作成される。これらのUTPは、コードレベルまたはユニットレベルでのバグを排除するために実行される。ユニットとは、独立して存在できる最小のエンティティ（例：プログラムモジュール）である。単体テストは、最小のエンティティが他のコードやユニットから分離された状態で正しく機能することを検証する。

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

### システムテスト
システムテスト計画は、システム設計フェーズ中に作成される。単体テスト計画や結合テスト計画とは異なり、システムテスト計画はクライアントのビジネスチームによって構成される。システムテストは、開発されたアプリケーションへの期待が満たされていることを保証する。アプリケーション全体について、その機能性、相互依存性、および通信がテストされる。システムテストは、機能要件および非機能要件が満たされていることを検証する。負荷およびパフォーマンスのテスト、ストレステスト、回帰テストなどは、システムテストのサブセットである。

### ユーザー受入テスト
ユーザー受入テスト（UAT）計画は、要件分析フェーズ中に作成される。テスト計画はビジネスユーザーによって構成される。UATは、本番環境に類似したユーザー環境で、現実的なデータを使用して実行される。UATは、納品されたシステムがユーザーの要件を満たしており、システムがリアルタイムで使用できる状態にあることを検証する。

## 批判
V字モデルは、アジャイルの支持者などから、ソフトウェア開発のモデルとして不適切であるとして、多くの理由で批判されている。 批判には以下が含まれる：

# ソフトウェア開発プロセスを正確に反映するには単純すぎて、管理者に誤った安心感を与える可能性がある。V字モデルはソフトウェア開発のプロジェクト管理的な視点を反映しており、ソフトウェア開発者やユーザーではなく、プロジェクト管理者、会計士、弁護士のニーズに合致している。
# 初心者には理解しやすいが、その初期の理解は、初心者が開発プロセスとV字モデルを実際にどのように適応・拡張すべきかについてより深い理解を得て初めて役立つものである。実務者がV字モデルに対する素朴な見方に固執すれば、それを適用して成功させることは非常に困難になるだろう。
# 柔軟性がなく、ソフトウェア開発に対する硬直的で直線的な見方を助長し、変化に対応する固有の能力を持たない。
# ウォーターフォール・モデルのわずかな変種にすぎず、したがってそのモデルと同じ批判の対象となる。テストに重点を置いており、特に早期のテスト計画の重要性を強調している。しかし、V字モデルに対する一般的な実務上の批判として、開発の初期段階が遅延しても実装日が固定されたままである場合、開発の最後にテストが厳しい期間に押し込められることにつながるという点がある。
# 非効率的で効果のないテストアプローチと整合しており、したがってそれを暗黙的に助長している。探索的テストではなく、事前のテストスクリプトの作成を暗黙的に推奨している。テスターに対し、実際にそこにあるものを発見するのではなく、見つけると期待しているものを探すように促している。また、テストを計画し実行するための最も効果的かつ効率的な方法をテスターに選択させるのではなく、両脚の同等のレベル間の硬直的なリンク（例：ユーザー要件定義書から派生するユーザー受入テスト計画）を推奨している。
# 一貫性と精度に欠けている。V字モデルが正確に何であるかについて、広範な混乱がある。ほとんどの人が同意する要素だけに絞り込むと、それはソフトウェア開発の陳腐で役に立たない表現になってしまう。V字モデルのメリットに関する不一致は、その定義に関する共通理解の欠如を反映していることが多い。

## 現状
V字モデルの支持者は、V字モデルは進化しており、開発プロセス全体を通じて柔軟性と敏捷性をサポートしていると主張している。 彼らは、規律あるアプローチであることに加えて、安定したソフトウェア製品を構築するために必要な綿密な設計、開発、および文書化を促進すると主張している。最近では、医療機器業界でも採用されている。

## 関連項目

* V字モデル
* 製品ライフサイクル管理
* システム開発ライフサイクル

## 脚注

## 関連文献

* Roger S. Pressman:*Software Engineering: A Practitioner's Approach*, The McGraw-Hill Companies, 
* Mark Hoffman & Ted Beaumont: *Application Development: Managing the Project Life Cycle*, Mc Press, 
* Boris Beizer: *Software Testing Techniques.* Second Edition, International Thomson Computer Press, 1990,