Vモデル
システムエンジニアリングプロセスのVモデル。[ 1 ]

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

Vモデルは、コンピュータ化されたシステム検証フレームワーク、またはプロジェクトライフサイクル開発において、対応する成果物と併せて実行されるべき主要なステップを要約したものです。製品開発中に実行される活動と、達成されるべき結果を記述します。

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

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

種類

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

Vモデル

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

一般検査

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

米国政府規格

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

検証と検証

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

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

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

目的

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

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

Vモデルのトピック

システムエンジニアリングと検証。[ 18 ]

システムエンジニアリングと検証

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

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

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

2つの流れ

仕様ストリーム

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

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

テストストリーム

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

  • 設置適格性評価（IQ）
  • 運転適格性確認（OQ）
  • パフォーマンス適格性評価（PQ）

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

アプリケーション

オフコア代替案（上方反復と下方反復、および時間と成熟度の次元を示す）。出典 - K. ForsbergとH. Mooz 2004 [ 3 ] [ 7 ]

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字型モデルの基本的特徴の一つは、時間と成熟度が左から右へと進行し、時間を遡ることはできないという点である。図に示すように、すべての反復はシステム階層の上位または下位レベルへの垂直線に沿って行われる。[ 3 ] [ 4 ] [ 7 ] これはこのモデルの重要な側面であることが証明されている。このモデルをデュアルV字型概念に拡張する方法については、参考文献で説明されている。[ 3 ]

Vモデルは公開されているため、多くの企業で活用されています。プロジェクトマネジメントにおいては、PRINCE2に匹敵する手法であり、プロジェクトマネジメント手法とシステム開発手法の両方を規定しています。Vモデルは、プロセス自体は厳格ですが、適用範囲は非常に柔軟で、特にシステム開発ライフサイクルの標準パラメータの範囲外に適用することができます。

利点

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

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

制限事項

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

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

参照

参考文献

  1. ^ a b c d Clarus Concept of Operations Archived 2009-07-05 at the Wayback Machine、Publication No. FHWA-JPO-05-072、Federal Highway Administration (FHWA)、2005年。
  2. ^「危険で魅惑的なVモデル」Wayback Machineで2019年9月15日にアーカイブ、2013年1月9日にアクセス。
  3. ^ a b c d e f g h Forsberg, K., Mooz, H., Cotterman, H. Visualizing Project Management、第3版、John Wiley and Sons、ニューヨーク、NY、2005年。108-116、242-248、341-360ページ。
  4. ^ a b c d e国際システム工学会議（INCOSE）、システム工学ハンドブックバージョン3.1、 2007年8月、3.3～3.8ページ
  5. ^ Forsberg, K., Mooz, H. (1998). 「より速く、より安く、より良くするためのシステムエンジニアリング」(PDF) . Center of Systems Management. 2003年4月20日時点のオリジナル(PDF)からのアーカイブ。{{cite journal}}:ジャーナルを引用するには|journal=（ヘルプ）が必要ですCS1 maint: 複数の名前: 著者リスト (リンク)
  6. ^ 「The SE VEE」 SEOR、ジョージ・メイソン大学。2007年10月18日時点のオリジナルよりアーカイブ。2007年5月26日閲覧。
  7. ^ a b c d e Forsberg, K. and Mooz, H., "The Relationship of Systems Engineering to the Project Cycle" Archived 2009-02-27 at the Wayback Machine、First Annual Symposium of the National Council On Systems Engineering (NCOSE)、1991年10月
  8. ^「V-Modellサイト（ドイツ語）」、2020年7月10日アクセス。2022年8月8日アーカイブ、 Wayback Machine
  9. ^ドイツ指令250、ドイツ連邦軍向けソフトウェア開発標準、Vモデル、ソフトウェアライフサイクルプロセスモデル、1992年8月
  10. ^ “Fundamentals of the V-Modell” . 2016年3月8日時点のオリジナルよりアーカイブ。2024年11月17日閲覧。
  11. ^ 「V-Modell XT、パート 1: V-Modell の基礎」(PDF) 。2024 年11 月 17 日に取得。
  12. ^「International Software Testing Qualifications Board – Foundation Level Syllabus」Wayback Machineで2017年8月6日にアーカイブ、2013年1月9日にアクセス。
  13. ^ 「高度道路交通システムのためのシステムエンジニアリング」（PDF）。米国運輸省。p. 10。2008年6月3日時点のオリジナル（PDF）からアーカイブ。 2007年6月9日閲覧。
  14. ^「米国運輸省、連邦道路局。ITS 向けシステムエンジニアリングガイドブック」、2013 年 1 月 9 日にアクセス。
  15. ^ 「レガシーの構築：防衛調達におけるシステムエンジニアリングへの新たな焦点」(PDF) 。 2016年11月23日時点のオリジナル(PDF)からアーカイブ。 2016年4月14日閲覧。
  16. ^ 「テストにVモデルを使用する」 2013年11月10日。 2016年4月14日閲覧。
  17. ^ IEEEガイド - プロジェクトマネジメント協会（PMI(R)）標準の採用、プロジェクトマネジメント知識体系ガイド（PMBOK(R)ガイド） - 第4版。2011年6月。p. 452。doi : 10.1109/IEEESTD.2011.6086685。ISBN 978-0-7381-6817-3。
  18. ^システムエンジニアリングの基礎。国防調達大学出版局、2001年。
  19. ^ 「Vモデルライフサイクルプロセスモデル」 v-modell.iabg.de. 2016年3月3日時点のオリジナルよりアーカイブ。 2015年12月24日閲覧。
  20. ^ 「Sequential Thematic Organization of Publications (STOP)」 2008年2月3日時点のオリジナルよりアーカイブ。2015年12月24日閲覧。
  21. ^ソブキウ、ウォルター（2008年1月1日）『創造的システムエンジニアリングによる持続可能な開発』Lulu.com. ISBN 978-0615216300。
  22. ^ 「新しいシステムエンジニアリングモデルと古くから馴染みのある友人：図2 V-9プロセスの相互作用」（PDF） 。国防AT&L。2006年4月。p. 51。 2016年11月22日時点のオリジナル（PDF）からアーカイブ。 2016年4月7日閲覧。
  23. ^ 「V-Modellのさらなる開発（リンク切れ）」 v-modell.iabg.de。2011年4月23日時点のオリジナルよりアーカイブ。2015年12月24日閲覧。
  24. ^ 「Vモデルのアクティビティモデルの概要（リンク切れ）」 v-modell.iabg.de。2011年7月19日時点のオリジナルよりアーカイブ。2015年12月24日閲覧。
  25. ^ 「VModelの限界」 v-modell.iabg.de. 2011年5月21日時点のオリジナルよりアーカイブ。2015年12月24日閲覧。
  26. ^クリスチャン・ブカナック、「Vモデル」
ウィキメディア コモンズには、 V モデルに関連するメディアがあります。
「 https://en.wikipedia.org/w/index.php?title=V-model&oldid=1315297048」から取得