Vモデル

読み：ぶいもでる　／　英語表記：V-model

要求や設計を具体化する工程と、その内容を確かめるテスト工程を対応付けるモデル。部品を組み立てて全体を確認する順序を表し、各段階で何を根拠に試すかを明確にする。

イマシルちゃんの解説

模型を作るときは、完成した姿を考えてから、部品の形を決めていくよね。
作ったあとは、まず部品が正しいか、次につなげて動くかを確かめるんだ。

最後は、最初に欲しかったものができたかを確かめる。
調べる内容は、作る前に決めた約束と組にしておくとわかりやすいよ。

Vモデルでは、要求から詳細へ進む側と、部品から全体へ確認する側を対応付ける。設計の各段階で、対応するテスト工程の観点も用意することに意味がある。完成後に初めて合否の基準を考えるのではない。

工程の呼び方や分け方は開発標準によって異なる。名前だけで暗記せず、「何を定めた文書に対し、何を組み合わせて確認するか」を見る。

定義・設計の内容	対応するテスト	主な確認対象
システム方式設計	システム結合テスト	ハードウェアとソフトウェアなど、システム構成要素の組合せ
ソフトウェア方式設計	ソフトウェア結合テスト	ソフトウェアの部品間の接続・呼出し
ソフトウェア詳細設計	ソフトウェアユニットテスト	個々の部品の内部処理

たとえば、部品内の条件分岐が正しいかを見るのはソフトウェアユニットテストである。部品単独では正しくても、引数の順序やデータ形式が食い違えば、結合後に不具合が発生する。そのためソフトウェア結合テストが必要になる。

さらに、装置と制御ソフトウェア、通信機器と業務サーバなどを組み合わせた確認がシステム結合テストである。確認の範囲が大きくなるほど、単独の内部ロジックだけでは発見できない不具合を扱う。

設計に沿って組み上がったことと、利用者の目的を満たすことは同じではない。要求に対して機能、性能、信頼性などを確認する活動も必要である。

合否の根拠となる要求事項が曖昧なら、テスト結果だけでは完成を判断できない。要求・設計・テスト項目を追跡できるよう、対応関係を管理する。

運用テストは、利用や運用の現場で必要な手順・体制が成立するかを確認する。バックアップ、復元、監視、ジョブ運用、障害連絡などが対象になる。

ソフトウェア詳細設計の内部ロジックだけを根拠に、運用全体の合否を決めることはできない。利用者や運用担当者が必要とする運用要件と、実際の手順を照合する必要がある。

テストを設計すると、「この条件では何を返すべきか」「失敗をどう通知するか」といった未定義の点が見つかる。実装前に確認すれば、後工程での手戻りを減らせる。

Vモデルは工程間の関係を表す考え方であり、一度進んだら戻ってはいけないという規則ではない。不具合の原因が要求や設計にあれば、対応する成果物へ戻って修正し、影響するテストを再実施する。