システムエンジニアリングプロセスのVモデル。[ 1 ] Vモデルは、 システム開発ライフサイクル のグラフィカルな表現です。厳密な開発ライフサイクルモデルやプロジェクト管理モデルを作成するために使用されます。Vモデルは、ドイツのVモデル 、一般的なテストモデル、米国政府標準の3つの大きなカテゴリに分類されます。[ 2 ]
Vモデルは、コンピュータシステム検証 フレームワーク、すなわちプロジェクトライフサイクル開発において、対応する成果物と併せて実施すべき主要な手順を要約したものです。製品開発中に実施すべき活動と、生み出すべき成果を記述しています。
「V」の左側は、要求事項の分解とシステム仕様の作成を表します。「V」の右側は、部品の統合とそれらの検証を表します。[ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] DO-178B では、要求事項は検証され、真であることが確認され、最終製品は検証されて、それらの要求事項を満たしていることを確認すると規定されています。
検証は「正しいものを作っていますか？」という質問で表現でき、確認は「正しく作っていますか？」という質問で表現できます。
種類 V型モデルには大きく分けて3つの種類がある。
Vモデル 「Vモデル」は、ドイツ政府の公式プロジェクト管理手法です。これは、PRINCE2 とほぼ同等ですが、ソフトウェア開発により直接関連しています。[ 8 ] [ 9 ] [ 10 ] [ 11 ]
検証と妥当性確認 検証は「正しいものを作っていますか？」という問いで表現でき、確認は「正しく作っていますか？」という問いで表現できると言われることがある。しかし実際には、これらの用語の使い方は様々である。
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モデルは依然として標準的な手法となっています。
V型モデルの概念は、1980年代後半にドイツとアメリカで同時期に、しかし独立して開発された。
ドイツのV型は、もともとミュンヘン近郊のオットブルンにあるIABG社が、コブレンツにある連邦国防技術調達局と協力して、連邦国防省向けに開発したものです。1992年夏に連邦内務省が民間公共機関向けに引き継ぎました。[ 19 ] 米国Vモデルは、1991年の米国システム工学評議会 （NCOSE、1995年現在INCOSE）の議事録に記載されているように[ 7 ] V モデルは、 FAA 先進自動化システム (AAS) プログラムの事前提案作業の一環として、1982 年頃にヒューズ エアクラフト で初めて登場しました。これは最終的に、ヒューズ AAS 設計競争フェーズ (DCP) 提案のテスト戦略を形成しました。これは、ソフトウェアの潜在的な欠陥を明らかにするという新たな課題によって推進されたテストおよび統合アプローチを示すために作成されました。この新しいレベルの潜在的な欠陥検出の必要性は、自動航路航空交通管制 (AERA) プログラムで構想されているように、航空交通管制官の思考および計画プロセスを自動化し始めるという目標によって推進されました。V が非常に強力な理由は、すべてのテキストと分析を多次元画像に結び付けるというヒューズの文化にあります。これは、 1963 年にヒューズによって作成され、 1985 年にヒューズがハワード ヒューズ医学研究所 に売却されるまで使用された、出版物の逐次テーマ別組織 (STOP) [ 20 ]の基礎でした。 [ 21 ] 米国国防総省は、システムエンジニアリング プロセスの相互作用をVモデルの関係に位置づけている。[ 22 ] 現在では、商業プログラムだけでなく防衛プログラムでも広く応用されています。主な用途はプロジェクト管理[ 3 ] [ 4 ]
米国Vモデルの基本的な特徴の1つは、時間と成熟度が左から右に進み、時間を遡ることができないことです。すべての反復は、図に示すように、システム階層のより高いレベルまたはより低いレベルへの垂直線に沿って行われます。[ 3 ] [ 4 ] [ 7 ] [ 3 ]
Vモデルは一般に公開されているため、多くの企業でも利用されています。プロジェクト管理においては、PRINCE2 に匹敵する手法であり、プロジェクト管理手法とシステム開発 手法の両方を記述しています。Vモデルはプロセス自体は厳格ですが、特にシステム開発ライフサイクルの通常の範囲外の領域においては、非常に柔軟に適用できます。
利点 Vモデルが他のシステム開発モデルに比べて提供する利点は以下のとおりです。
Vモデルのユーザーは、Vモデルの開発と保守に参加します。変更管理委員会がVモデルを公的に保守します。変更管理委員会は、毎日から毎週まで会議を開催し、システム開発とテスト中に受け取ったすべての変更要求を処理します。[ 23 ] Vモデルは、アクティビティとその作業手順の実装方法について具体的な支援を提供し、作業手順を完了するために必要なイベントを明確に定義します。各アクティビティスキーマには、アクティビティの手順、推奨事項、詳細な説明が含まれています。[ 24 ]
制限事項 以下の側面はVモデルではカバーされていないため、追加で規制するか、Vモデルをそれに応じて調整する必要があります。[ 25 ] [ 26 ]
サービス契約の締結は規制されていない。 システムの運用、保守、修理、廃棄の組織化と実施はVモデルの対象外です。ただし、これらの作業に関する計画と構想の策定はVモデルで規定されています。 Vモデルは、組織全体ではなく、プロジェクト内でのソフトウェア開発を対象としています。
参考文献 1 2 3 4 Clarus 運用コンセプト 、 Wayback Machine に 2009-07-05 に アーカイブ済み、出版物番号 FHWA-JPO-05-072、連邦道路管理局 (FHWA)、2005 年。↑ 「危険で魅惑的なVモデル」Wayback Machine に2019年9月15日に アーカイブされ、2013年1月9日にアクセスされました。 1 2 3 4 5 6 7 8 Forsberg, K.、Mooz, H.、Cotterman, H.『Visualizing Project Management』 第3版、John Wiley and Sons、ニューヨーク、NY、2005年。108-116ページ、242-248ページ、341-360ページ。 1 2 3 4 5 国際システム工学評議会（INCOSE）、システム工学ハンドブック バージョン3.1、 2007年8月、3.3～3.8ページ ↑ Forsberg, K., Mooz, H. (1998). "System Engineering for Faster, Cheaper, Better" (PDF) . Center of Systems Management. 2003年4月20日にオリジナル(PDF)からアーカイブされました。 CS1 maint: 複数の名前: 著者リスト (リンク)が必要です ↑ 「SE VEE」 。SEOR、ジョージ・メイソン大学。 2007年10月18日の オリジナルからアーカイブ済み。 2007年 5月26日 取得 。 1 2 3 4 5 Forsberg, K. および Mooz, H.、「システムエンジニアリングとプロジェクトサイクルの関係」、Wayback Machine に 2009 年 2 月 27 日に アーカイブ済み、全米システムエンジニアリング協議会 (NCOSE) の第 1 回年次シンポジウム、1991 年 10 月 ↑ 「V-Modellサイト（ドイツ語）」、2020年7月10日アクセス。 2022年8月8日にWayback Machine に アーカイブ済み。 ↑ ドイツ連邦軍向けソフトウェア開発標準規格、Vモデル、ソフトウェアライフサイクルプロセスモデル、ドイツ指令250、1992年8月 ↑ 「Vモデルの基礎」 。 2016年3月8日に オリジナル からアーカイブ済み 。 2024年 11月17日に 取得。 ↑ 「V-Modell XT、パート 1: V-Modell の基礎」 (PDF) 。 2024 年 11 月 17 日 に取得 。 ↑ 「国際ソフトウェアテスト資格認定委員会 - 基礎レベルシラバス」Wayback Machine に2017年8月6日に アーカイブされ、2013年1月9日にアクセスされました。 ↑ 「インテリジェント交通システムのためのシステムエンジニアリング」 （PDF） 。米国運輸省。p. 10。 2008年6月3日に オリジナル （PDF） からアーカイブ 。 2007年 6月9日 に取得。 ↑ 「米国運輸省、連邦道路管理局。ITS向けシステムエンジニアリングガイドブック」、2013年1月9日アクセス。 ↑ 「レガシーの上に築く：防衛調達におけるシステムエンジニアリングへの新たな焦点」 (PDF) 。 2016年11月23日に オリジナル (PDF) からアーカイブ 。 2016年 4月14日 に取得。 ↑ 「テストにVモデルを使用する」 。2013年11月10日。 2016年 4月14日 取得 。 ↑ IEEEガイド - プロジェクトマネジメント協会 （ PMI®）標準の採用 - プロジェクトマネジメント知識体系ガイド（PMBOK®ガイド）--第4版 。2011年6 月 。p.452。doi : 10.1109 /IEEESTD.2011.6086685。ISBN 978-0-7381-6817-3 。↑ システム工学の基礎。国防調達大学出版局、2001年。 ↑ 「V-Modelライフサイクルプロセスモデル」 。v-modell.iabg.de。 2016年3月3日に オリジナルからアーカイブ済み 。 2015年 12月24日 に取得。 ↑ 「出版物のテーマ別順序付け（STOP）」 。 2008年2月3日に オリジナルからアーカイブ済み 。 2015年 12月24日 に取得。 ↑ ソブキウ、ウォルター (2008-01-01). 創造的なシステムエンジニアリングで持続可能な開発は可能 . Lulu.com. ISBN 978-0615216300 。↑ 「新しいシステムエンジニアリングモデルと古くからの馴染み深い友人；図2 V-9プロセス相互作用」 （PDF） 。国防AT&L。2006年4月。p.51。 2016年11月22日に オリジナル （PDF） からアーカイブ 。 2016年 4月7日 に取得。 ↑ 「Vモデルのさらなる開発（リンク切れ）」 。v-modell.iabg.de。 2011年4月23日に オリジナルからアーカイブ済み 。 2015年 12月24日 に取得。 ↑ 「Vモデルの活動モデルの概要（リンク切れ）」 。v-modell.iabg.de。 2011年7月19日に オリジナルからアーカイブ済み 。 2015年 12月24日 に取得。 ↑ 「Vモデルの限界」 。v-modell.iabg.de。 2011年5月21日に オリジナルからアーカイブ済み 。 2015年 12月24日 に取得。 ↑ クリスチャン・ブカナック著『Vモデル』
外部リンク ウィキメディア・コモンズには、Vモデル に関連するメディアがあります。
「INCOSE G2SEBOK 3.30: システムエンジニアリング設計と統合のVeeモデル」。g2sebok.incose.org 。国際システムエンジニアリング協議会 。2007年9月27日にオリジナルからアーカイブ 済み。 「Das V-Modell XT」 . cio.bund.de （ドイツ語）。連邦情報セキュリティ庁 （BMI）。2016年11月18日のオリジナルからアーカイブ。 2016年11月6日 取得 。 「テストのためのVモデルの使用」。insights.sei.cmu.edu 。ソフトウェア エンジニアリング研究所 、カーネギーメロン大学 。2013年11月11日。
