Vモデル

Vモデルは、システム開発ライフサイクルを図式的に表現したものです。厳密な開発ライフサイクルモデルやプロジェクト管理モデルを作成するために使用されます。Vモデルは、ドイツのVモデル、一般的なテストモデル、米国政府標準の3つのカテゴリに分類されます。 ^[2]

V モデルは、コンピュータ化されたシステム検証フレームワークまたはプロジェクト ライフサイクル開発内の対応する成果物と併せて実行される主な手順を要約したものです。製品開発中に実行されるアクティビティと生成される結果について説明します。

「V」の左側は、要件の分解とシステム仕様の作成を表しています。「V」の右側は、部品の統合とそれらの検証を表しています。^{[3] [4] [5] [6] [7]}ただし、要件は、まず上位レベルの要件またはユーザーのニーズに対して検証される必要があります。さらに、システムモデルの検証というものもあります。これは、左側でも部分的に行うことができます。検証は右側でのみ行われると主張するのは正しくない可能性があります。最も簡単な方法は、検証は常に要件（技術用語）に対して行われ、検証は常に現実世界またはユーザーのニーズに対して行われると言うことです。航空宇宙規格 RTCA DO-178Bでは、要件が検証され（真実であることが確認され）、最終製品がそれらの要件を満たしていることを確認するために検証されると規定されています。

検証は「正しいものを構築していますか?」というクエリで表現でき、検証は「正しく構築していますか?」というクエリで表現できます。

V モデルには一般的に 3 つのタイプがあります。

「Vモデル」はドイツ政府の公式プロジェクト管理手法です。これはPRINCE2とほぼ同等ですが、ソフトウェア開発により直接関連しています。^[8] 「V」表現を使用する主な特徴は、Vの左側の製品が、Vの右側を実装する適切なテストおよび統合組織によって受け入れられることを証明する必要があることです。^{[9] [10] [11]}

世界中のテストコミュニティでは、Vモデルは、国際ソフトウェアテスト資格委員会のソフトウェアテスター向け基礎シラバスに記載されているソフトウェア開発プロセスをより漠然と説明したものとして広く認識されています。^[12]このモデルには単一の定義はなく、Vモデル（ソフトウェア開発）に関する別の記事でより直接的に説明されています。

米国にも政府標準のVモデルがある。その範囲はシステム開発ライフサイクルモデルの範囲が狭いが、英国のほとんどの実務家やテスト担当者がVモデルで理解するよりもはるかに詳細で厳密である。^{[13] [14] [3] [4] [15] [16]}

検証は「正しいものを構築していますか?」という質問で表現され、検証は「正しく構築していますか?」という質問で表現されると言われることがあります。実際には、これらの用語の使用法はさまざまです。

PMBOKガイドはIEEEでも標準として採用されており（INCOSE、システムエンジニアリング研究評議会SERC、IEEEコンピュータ協会が共同で管理）、第4版では次のように定義されています。^[17]

• 「検証。製品、サービス、またはシステムが顧客およびその他の特定の利害関係者のニーズを満たしていることを保証すること。多くの場合、外部の顧客による承認と適合性が含まれます。検証と対照的。」
• 「検証。製品、サービス、またはシステムが規制、要件、仕様、または課せられた条件に準拠しているかどうかの評価。多くの場合、内部プロセスです。検証と対照的。」

V モデルは、プロジェクトの計画と実現のためのガイダンスを提供します。プロジェクトの実行によって達成される目標は次のとおりです。

• プロジェクト リスクの最小化: V モデルは、標準化されたアプローチを指定し、対応する結果と責任ある役割を記述することで、プロジェクトの透明性とプロジェクト管理を向上させます。これにより、計画の逸脱とリスクを早期に認識し、プロセス管理を改善して、プロジェクト リスクを軽減できます。
• 品質の向上と保証: 標準化されたプロセス モデルとして、V モデルは提供される結果が完全であり、望ましい品質であることを保証します。定義された中間結果は早い段階で確認できます。製品コンテンツが統一されると、読みやすさ、理解しやすさ、検証可能性が向上します。
• プロジェクト全体とシステムのライフサイクル全体にわたる総コストの削減: 標準化されたプロセス モデルを適用することで、システムの開発、製造、運用、保守にかかる労力を、透明性のある方法で計算、見積、管理できます。得られる結果は均一で、簡単に追跡できます。これにより、買収者のサプライヤーへの依存度が下がり、その後の活動やプロジェクトにかかる労力が軽減されます。
• すべての利害関係者間のコミュニケーションの改善: すべての関連要素と用語の標準化された統一された記述は、すべての利害関係者間の相互理解の基礎となり、ユーザー、買収者、サプライヤー、開発者間の摩擦損失が軽減されます。

システムエンジニアリングプロセス（SEP）は、システムの構想から廃止までの全ライフサイクルにわたってシステム所有者が経験する複雑なシステムの費用対効果を改善するための道筋を提供します。^[1]

これには、目標の早期かつ包括的な特定、ユーザーのニーズと運用環境を説明する運用コンセプト、徹底的かつテスト可能なシステム要件、詳細な設計、実装、実装されたシステムが規定の要件を満たしていることを確認するための厳格な受け入れテスト（システム検証）、目標に対処するための有効性の測定（システム検証）、継続的な運用と保守、時間の経過に伴うシステムのアップグレード、そして最終的な廃止が含まれます。^{[1] [3] [4] [7]}

このプロセスでは、要件主導の設計とテストを重視しています。すべての設計要素と受け入れテストは、1 つ以上のシステム要件に追跡可能でなければならず、すべての要件は少なくとも 1 つの設計要素と受け入れテストによって対処されなければなりません。このような厳密さにより、不必要なことは何も行われず、必要なことはすべて達成されます。^{[1] [3]}

仕様ストリームは主に次のものから構成されます。

• ユーザー要件仕様
• 機能要件仕様
• 設計仕様

テスト ストリームは通常、次の要素で構成されます。

• 設置適格性（IQ）
• 運用適格性確認 (OQ)
• パフォーマンス適格性 (PQ)

開発ストリームは、（システムの種類と開発範囲に応じて）カスタマイズ、構成、またはコーディングで構成されます。

V モデルは、ドイツ連邦政府内のソフトウェア開発プロセスを規制するために使用されています。現在でも^{[いつから? ]、}ドイツ連邦政府の行政および防衛プロジェクト、ならびに地域内のソフトウェア開発者にとっての標準となっています。

V モデルの概念は、1980 年代後半にドイツと米国で同時に、しかし独立して開発されました。

• ドイツのV型はもともとミュンヘン近郊のオットーブルンにあるIABG社が連邦国防省のためにコブレンツの連邦防衛技術調達局と協力して開発したもので、1992年夏に連邦内務省が民間公共機関の領域に引き継いだ。^[19]
• 米国のVモデルは、1991年の米国システム工学評議会（NCOSE、1995年からはINCOSE）の議事録に記載されているように、^[7]ハードウェア、ソフトウェア、および人間の相互作用を含む衛星システム用に開発されました。
• V モデルは、1982 年頃、FAA の高度自動化システム (AAS) プログラムの事前提案の一環としてヒューズ エアクラフト社で初めて登場しました。最終的には、ヒューズ AAS 設計競争フェーズ (DCP) 提案のテスト戦略となりました。ソフトウェアの潜在的な欠陥を表面化させるという新しい課題によって推進されたテストおよび統合アプローチを示すために作成されました。この新しいレベルの潜在的な欠陥検出の必要性は、自動航路航空交通管制 (AERA) プログラムによって構想された航空交通管制官の思考および計画プロセスの自動化を開始するという目標によって推進されました。V モデルが非常に強力な理由は、すべてのテキストと分析を多次元画像に結合するヒューズの文化に由来しています。これは、 1963 年にヒューズによって作成され、 1985 年にヒューズがハワード ヒューズ医学研究所に売却されるまで使用されたSequential Thematic Organization of Publications (STOP) ^{[20]の基礎でした。 [21]}
• 米国国防総省は、システムエンジニアリングプロセスの相互作用をVモデルの関係に組み込んでいます。^[22]

現在では、民間および防衛プログラムで広く応用されています。主な用途はプロジェクト管理^{[3] [4]}とプロジェクトライフサイクル全体です。

米国のV字型モデルの基本的特徴の1つは、時間と成熟度が左から右へ進み、時間を遡ることはできないという点です。すべての反復は、図に示すように、システム階層の上位または下位レベルへの垂直線に沿って行われます。^{[3] [4] [7]} これは、モデルの重要な側面であることが証明されています。モデルのデュアルV字型コンセプトへの拡張については、参考文献で取り上げています。^[3]

V モデルは公開されているため、多くの企業でも使用されています。プロジェクト管理では、PRINCE2に匹敵する手法であり、プロジェクト管理の方法とシステム開発の方法を説明しています。V モデルは、プロセスは厳格ですが、特にシステム開発ライフサイクルの通常のパラメータの範囲外の範囲に関係する場合は、非常に柔軟に適用できます。

V モデルが他のシステム開発モデルに比べて優れている点は次のとおりです。

• Vモデルのユーザーは、Vモデルの開発と保守に参加します。変更管理委員会がVモデルを公開的に保守します。変更管理委員会は毎日から毎週まで会議を開き、システムの開発とテスト中に受け取ったすべての変更要求を処理します。^[23]
• Vモデルは、アクティビティとその作業ステップを実装する方法について具体的な支援を提供し、作業ステップを完了するために必要なイベントを明示的に定義します。各アクティビティスキーマには、アクティビティの指示、推奨事項、詳細な説明が含まれています。^[24]

以下の側面はVモデルではカバーされていないため、追加で規制するか、Vモデルをそれに応じて適応させる必要がある。^{[25] [26]}

• サービスに関する契約の締結は規制されていません。
• システムの運用、保守、修理、廃棄の組織と実行は V モデルではカバーされていませんが、これらのタスクの計画とコンセプトの準備は V モデルで規定されています。
• V モデルは、組織全体ではなくプロジェクト内のソフトウェア開発に対処します。

• エンジニアリング情報管理(EIM)
• ARCADIA（支援システムモデリング手法として）
• IBM Rational Unified Process (サポートソフトウェアプロセスとして)
• ソフトウェア開発のウォーターフォールモデル
• システムアーキテクチャ
• システム設計
• システムエンジニアリング
• モデルベースシステムエンジニアリング
• 理論U

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

• 「INCOSE G2SEBOK 3.30: システム エンジニアリングの設計と統合の Vee モデル」。g2sebok.incose.org。国際システム エンジニアリング評議会。2007 年 9 月 27 日のオリジナルからアーカイブ。
• 「Das V-Modell XT」。cio.bund.de (ドイツ語)。連邦情報セキュリティ庁(BMI)。
• 「テストに V モデルを使用する」。insights.sei.cmu.edu 。カーネギーメロン大学ソフトウェアエンジニアリング研究所。2013年 11 月 11 日。