V字モデル
システム開発ライフサイクルを「V」の字の形で視覚的に表現したもの
From Wikipedia, the free encyclopedia
V字モデル（英: V-model）は、システム開発ライフサイクルを「V」の字の形で視覚的に表現したものである。Vモデルは大きく分けて、ドイツ政府標準の「V-Modell」、システム開発のおけるテストモデル、そして米国政府標準という3つのカテゴリに分類される。特にコンピュータ化システムバリデーション（CSV）やプロジェクト開発において、工程と成果物を対比させるための重要なフレームワークとして機能する[1]。
このモデルの「V」の字は、開発の流れを表す。左側は「要件の分解」と「システム仕様の作成」へと進む下降プロセスを、右側は「部品の統合」と「妥当性確認（バリデーション）」を行う上昇プロセスを表す[2][3][4][5][6] 。
一般に妥当性確認は、Vモデルの右側工程に位置付けられる。しかし、要件定義の段階で上位要件やユーザーニーズとの整合性を確認する必要があるほか、システムモデルを用いた検証も左側工程で実施可能であるため、右側でのみ発生するというのは必ずしも正確ではない。検証が常に技術的な要件を対象とし「正しく作っているか（正しく構築されているか）」を問うのに対し、妥当性確認は常に現実世界やユーザーのニーズを対象とし「正しいものを作っているか（要求通りの製品か）」を問う概念であると定義される。
例えば、航空宇宙規格のRTCA DO-178Bにおいても、要件自体は妥当性確認の対象であり、最終製品はその要件への適合を保証するために検証されるものであると規定されている。
種類
V字モデルには一般的に3つのタイプがある。
ドイツの「V-Modell」
「V-Modell」は、ドイツ政府の公式プロジェクト管理手法である。特にドイツ政府のプロジェクトや軍関連のプロジェクトで標準として採用されており、公共調達における必須要件となっている[8]。 「V」字型表現を使用する主な属性は、Vの左側からの成果物が、Vの右側を実装する適切なテスト・統合組織によって受け入れ可能であるという証拠を要求することにあった[9][10][11]。
システム開発のおけるテストモデル
世界中のシステム開発のテストコミュニティにおいて、V字モデルは、国際ソフトウェアテスト資格認定委員会（ISTQB）の基礎シラバスで説明されているソフトウェア開発プロセスを、図解したものとして広く見なされている。[12] しかし、このテストモデルにはバリデーションがあり、統一的な定義はない。
米国政府標準モデル
米国にも政府標準のV字モデルがある。その適応範囲は、限られたシステム開発ライフサイクルモデルである。一方、一般的なテスターがV字モデルとして理解しているものよりも詳細で厳密な定義がある[13][14][2][3][15]。
妥当性確認と検証
目的
V字モデルは、プロジェクトの計画と実現のためのガイダンスを提供する。プロジェクトの実行によって、以下の目的が達成されることが意図されている。
- プロジェクトリスクの最小化: 標準化されたアプローチを規定し、対応する結果と責任ある役割を記述することにより、プロジェクトの透明性と管理を向上させる。これにより、計画の逸脱やリスクの早期認識が可能になり、プロセス管理が改善され、プロジェクトのリスクが低減される。
- 品質の向上と保証: 標準化されたプロセスモデルとして、V字モデルは提供される結果が完全であり、望ましい品質であることを保証する。定義された中間結果は、早い段階でチェックすることができる。製品内容が統一されることで、可読性、理解性、検証可能性が向上する。
- プロジェクト全体にわたる総コストの削減: 標準化されたプロセスモデルを適用することで、システムの開発、生産、運用、保守にかかる労力を透明性のある方法で計算、見積もり、管理することができる。得られる結果は統一されており、容易に追跡可能である。これにより、調達者の供給者への依存度や、その後の活動やプロジェクトにかかる労力が軽減される。
- 利害関係者間のコミュニケーション改善: すべての関連要素と用語の標準化された統一的な記述は、すべての利害関係者間の相互理解の基礎となる。したがって、ユーザー、調達者、供給者、開発者間の摩擦による損失が低減される。
Vモデルとシステムエンジニアリングプロセス
システムエンジニアリングと検証
システムエンジニアリングプロセス（SEP）は、構想から廃棄に至るまで、システム所有者が経験する複雑なシステムの費用対効果を向上させるための道筋を提供するものである。[7]
これには、目的の早期かつ包括的な特定、ユーザーニーズと運用環境を記述する運用コンセプト、徹底的かつテスト可能なシステム要件、詳細設計、実装、実装されたシステムが規定の要件を満たしていることを確認するための厳格な受け入れテスト、目的に対する有効性の測定、継続的な運用と保守、長期にわたるシステムアップグレード、そして最終的な廃棄が含まれる[7][2][3][6]。
このプロセスでは、「要件主導」が強調され、無駄と漏れを完全に防ぐための厳格なルールが適用される。具体的には、すべての設計やテストが必ず何らかの要件に紐付いていることを求めるトレーサビリティの確保と、逆にすべての要件が漏れなく設計やテストに反映されていることを求める網羅性の確認を徹底する。このような厳格さにより、不必要なことは行われず、必要なことはすべて達成されることが保証される[7][2]。
2つのストリーム
開発プロセスは、大きく分けて仕様を定める流れ（仕様ストリーム）と、テストを行う流れ（テストストリーム）、そして実際の開発の流れ（開発ストリーム）に分類される。
仕様ストリーム
- ユーザー要件仕様
- 機能要件仕様
- 設計仕様
テストストリーム
- 据付時適格性確認（IQ）
- 運転時適格性確認（OQ）
- 性能適格性確認（PQ）
開発ストリーム
- カスタマイズ
- 構成
- コーディング
適用と歴史的背景
V字モデルは、ドイツ連邦行政におけるソフトウェア開発プロセスを規制するために導入され、現在でも同国の行政および防衛プロジェクト、さらには地域のソフトウェア開発者にとっての標準規格としての地位を確立している。このモデルの概念は1980年代後半、ドイツと米国において同時期かつ独立して開発された経緯を持つ。ドイツ版Vモデルは当初、連邦国防省の委託を受けたIABG社がコブレンツの連邦国防技術調達庁と協力して開発したものであり[18]、1992年夏には連邦内務省によって民間公的機関の領域にもその適用範囲が拡大された。
米国におけるV字モデルの展開は、ハードウェア、ソフトウェア、および人間による対話を含む衛星システムのために開発された[6]。1991年の全米システムエンジニアリング評議会（NCOSE）の議事録に文書化されている[6]。その原型はさらに古く、1982年頃にヒューズ・エアクラフト社がFAA（連邦航空局）の高度自動化システム（AAS）プログラム提案活動において、テストおよび統合のアプローチを示すために作成したものが最初とされる。これは航空管制の自動化に伴う潜在的な欠陥検出という課題に対応するためのものであり、テキストと分析を多次元画像に統合するという同社独自の「出版物の順次主題構成（STOP）」手法を基盤として設計された[19][20]。
現在、V字モデルは米国国防総省のシステムエンジニアリングプロセスに採用されるなど、防衛のみならず商業プログラムのプロジェクト管理手法としてライフサイクル全体で広く利用されている[2][21][3]。特に米国流モデルの基本的な特徴は、時間と成熟度が左から右へと不可逆的に進行し、反復（イテレーション）はシステム階層の上下方向（垂直線）においてのみ行われるという点にある。本モデルはPRINCE2に匹敵するプロジェクト管理手法でありながらシステム開発手法も包含しており、プロセスとしての厳格さを持ちつつも、適用においては高い柔軟性を有していることから多くの企業で採用されている。
利点
制限
関連項目
- ARCADIA (支援システムモデリング手法として)
- ラショナル統一プロセス (支援ソフトウェアプロセスとして)
- ウォーターフォール・モデル (ソフトウェア開発)
- システムアーキテクチャ
- システム設計
- システムエンジニアリング
- ウォーターフォール・モデル
- ソフトウェア開発工程
- システム開発ライフサイクル
- ラショナル統一プロセス（異なる手法の例）
- ISO/IEC 12207 (JIS X 0160) - 共通フレーム