主執筆者。 Dick Fairley、Kevin Forsberg、コントリビューティング オーサー。 Ray Madachy
ライフサイクル・プロセス・モデルは数多く存在します。 システムライフサイクルプロセスの推進要因と選択」の記事で述べたように、これらのモデルは大きく3つのカテゴリーに分類されます。 (1) 主に事前指定された順次プロセス、(2) 主に進化的および同時進行プロセス (たとえば、合理的統一プロセスおよび Vee およびスパイラル モデルのさまざまな形態)、および (3) 主に対人および無制限プロセス (たとえば、アジャイル開発、スクラム、エクストリーム プログラミング (XP) 、動的システム開発法、および革新ベースのプロセス) です。
この記事は特に事前指定および順次プロセスの主要例として Vee モデルに焦点を当てます。 この議論では、VeeモデルおよびVeeモデルのバリエーションはすべて、システムエンジニアリング（SE）活動の同じ基本セットを扱っていることに注目することが重要である。 これらのモデルの重要な違いは、前述のSE活動をどのようにグループ化し、表現するかである。
システム設計および開発に Vee モデルを使用することの一般的な意味を以下に説明します。このライフサイクル モデルがシステム工学の活動にどのように影響するかについてのより具体的な理解については、パート 3 の他の知識エリア (KA) を参照してください。 Veeモデル
Veeモデルの逐次版は図1に示されている。 その核心は、ベースライン化され構成管理の下に置かれた計画、仕様、および製品の順次進行にある。 垂直の両頭矢印は、プロジェクトが機会分析とリスク分析を同時に行い、プロセス内の検証を継続的に行うことを可能にする。 Veeモデルは、INCOSE Systems Engineering Handbookの「Generic Life Cycle Stages」の表にある最初の3つのライフサイクルステージ（探索研究、コンセプト、開発）を包含しています（INCOSE 2012）。
Veeモデルは、以下の図2に示すように、ライフサイクル ステージとその目的または活動のINCOSE Systems Engineering Handbook (INCOSE 2012) の定義を支持している。
INCOSE Systems Engineering Handbook 3.2.2 には、より一般的な Vee モデルにライフサイクル活動を組み込んだ Vee ダイアグラム (2012, Figures 3-4, p.27) の詳細版も含まれています。 米国国防調達大学（DAU）で開発された同様のダイアグラムは、以下の図3に見ることができる。
Application of the Vee Model
Lawson (Lawson 2010) は、各ライフサイクルステージにおける活動について詳しく述べ、図4に描かれているように、あらゆる種類のSoI（system-of-interest）に対する汎用ライフサイクルステージモデルの構造を検討すると有用だと指摘している。 この（T）モデルは、1つ以上の定義段階が、2つ以上のシステム要素の実装（取得、提供、または開発）が達成された生産段階（複数可）に先行することを示している
図 5 は、標準化団体 (ISO/IEC) から商業および政府組織まで、さまざまな利害関係者のための汎用ライフ サイクル段階を示しています。 これらのステージは詳細には異なりますが、いずれも図 2 (定義、生産、および使用/廃棄) で指摘したような中核活動を強調する、同様の連続的な形式を持っています。
ライフサイクル全体を通して、多くの活動が反復されることに注目することが重要です。 これは、第3部序論で説明した再帰（用語集）recursion（用語集）の例です。
ライフサイクルステージとプログラム管理段階の基礎
この議論では、次のことに注意することが重要です：
- ステージステージという言葉は、ライフサイクル中のシステムの異なる状態を指し、利用段階とサポート段階など、時間的に重なっている段階もあります。 ステージ」という用語は、ISO/IEC/IEEE 15288.
- フェーズという用語は、システムの寿命をサポートし管理するプログラムの異なるステップを指し、フェーズは通常重なりません。 フェーズ」という用語は、「ステージ」という用語に相当するものとして、多くの確立されたモデルで使用されています。
プログラム管理プログラム管理は、フェーズ、マイルストーンmilestones、および決定ゲートdecision gatesを使用し、さまざまな段階を通じてシステムの発展を評価するために使用されます。 ステージには、目標を達成するために行われる活動が含まれ、ステージの順序や各ステージ間の遷移を制御・管理する役割を果たす。
典型的なプログラムプログラムは以下のフェーズで構成される。
- 事前調査フェーズでは、ビジネス的に意味のある新しいソリューションでユーザーニーズに対応する潜在的な機会を特定する。 実現可能性の段階では、利害関係者の要件とシステム要件が特定され、実行可能なソリューションが特定および研究され、仮想プロトタイプ（用語集）プロトタイプ（用語集）を実装することができます。 この段階では、
- コンセプトが実現可能で、特定された脅威に対抗したり機会を利用したりできると考えられるかどうか、
- コンセプトが新製品または製品ラインの開発継続を保証するほど成熟しているかどうか、
- 提案依頼に応えて作成した提案を承認するかどうかに基づいて前進するかどうかが決定される。
- 実行フェーズには、システムのライフサイクルの4つの段階（開発、生産、利用、サポート）に関連する活動が含まれる。 通常、実行活動に関連した2つの決定ゲートと2つのマイルストーンが存在する。 最初のマイルストーンは、ゴーサインを出す前に、経営陣が実行計画を見直す機会を提供する。 2つ目のマイルストーンは、生産開始を決定する前に、進捗状況を確認する機会を提供する。 実行中の意思決定ゲートは、開発されたSoIを生産するかどうか、それを改善するか引退させるかを決定するために使用できる。
これらのプログラム管理見解は、SoIだけでなくその要素や構造にも適用される。
Life Cycle Stages
Veeモデルのバリエーションは、ライフサイクルの同じ一般的な段階を扱っている：
- 新しいプロジェクトは、一般的にコンセプト定義の活動、特にビジネスまたはミッション分析、利害関係者のニーズと要求の理解を含む探索研究段階から始まる。
- 生産段階には、システム定義およびシステム実現の活動、ならびにシステム要件（用語集）およびアーキテクチャ（用語集）の開発から検証および妥当性確認までの活動が含まれます。
- サポート段階には、システム保守、ロジスティクス、製品およびサービス寿命管理の活動が含まれ、これにはサービス寿命の延長または能力の更新、アップグレード、および近代化などの活動が含まれる場合がある。
- 引退段階には、廃棄および引退の活動が含まれますが、一部のモデルでは、耐用年数の延長または能力の更新、アップグレード、および近代化のような活動は「引退」段階にまとめられます
これらの各段階に関する追加情報は、以下のセクションでご覧いただけます（さらなる詳細については上記の追加のパート 3 記事へのリンクを参照）。 4425>
探索研究段階
ユーザー要求分析および合意は探索研究段階の一部であり、成功するシステムの開発にとって重要である。 ユーザーのニーズを適切に理解しなければ、どんなシステムでも間違った問題を解決するために構築される危険性があります。 探索研究の段階では、まずユーザー（およびステークホルダー）の要求と制約を定義します。 このプロセスの重要な部分は、ユーザー要件を満たすための実現可能性を確立することであり、技術的な準備の評価も含まれます。 多くのSE活動と同様に、これはしばしば反復的に行われ、利害関係者のニーズと要件は、新しい情報が利用可能になると再検討されます。
National Research Councilによる最近の研究（National Research Council 2008）では、米空軍のプロジェクトの開発期間短縮に焦点が当てられています。 この報告書では、「簡単に言えば、システムズエンジニアリングとは、効果的なシステム設計をもたらす反復プロセスを通じて、ユーザーのニーズをシステムおよびそのアーキテクチャの定義に変換することである」と指摘しています。 利害関係者との反復的な関わりはプロジェクトの成功に欠かせない。
プロジェクトの最初と最後の決定ゲートを除いて、ゲートは同時に実行される。 以下の図6を参照されたい。
コンセプトステージ
コンセプトステージでは、利害関係者のニーズを満たすための最良のアプローチを決定するために、代替コンセプトを作成する。 代替案を想定し、適切なプロトタイプを含むモデルを作成することにより、利害関係者のニーズが明確になり、推進課題が浮き彫りになる。 これは、システム開発への漸進的または進化的なアプローチにつながる可能性がある。 4425>
開発段階
コンセプト段階で特定された選択されたコンセプトは、利害関係者の要求を満たすソリューションを生み出すために、最低レベルまで詳細に練り上げられる。 この段階では、プロセス内バリデーション（Veeモデルの上向き矢印）を通じて、ユーザーの関与を継続することが重要である。 ハードウェアの場合、これは頻繁なプログラムレビューと（適切であれば）顧客常駐の担当者によって行われる。 アジャイル開発では、顧客代表を開発チームに統合することが実践されている。
生産段階
生産段階は、SoIが建設または製造される場所である。 生産上の問題を解決するため、生産コストを削減するため、あるいは製品またはSoIの能力を強化するために、製品の修正が必要とされる場合がある。 これらの修正のいずれもがシステム要件に影響を及ぼし、システムの再確認qualification、再検証verification、または再検証validationを必要とするかもしれない。 4425>
Utilization Stage
製品ライフサイクル管理の重要な側面は、製品の運用を維持する上で不可欠な支援システムの提供である。 供給された製品またはサービスが買収者にとっての狭義のシステムオブインタレスト（NSOI）と見なされるかもしれませんが、買収者はサポートシステムをより広義のシステムオブインタレスト（WSOI）に組み込まなければなりません。 これらの支援システムは、NSOIの運用に関して発生した状況に対応して、必要なときに起動されるシステム資産と見なされるべきです。 支援システムの集合の総称は、統合後方支援（ILS）システムである。
システムの製品やサービスを定義し、生産し、運用する際には、全体的な視点を持つことが重要である。 図 7 では、システムの設計と開発、および ILS 要件の関係が描かれている
保守性とテスト容易性の必要性をもたらす信頼性の要件は、推進要因である。
サポートステージ
サポートステージでは、SoIは継続運用できるようサービスを提供される。 サポート性の問題を解決するため、運用コストを削減するため、あるいはシステムの寿命を延ばすために、修正が提案されることがある。 これらの変更には、運用中のシステム能力の喪失を避けるためのSE評価が必要である。 4425>
引退段階
引退段階では、SoIとその関連サービスは運用から取り外される。 この段階でのSE活動は、廃棄の要求が満たされることを保証することに主に焦点が置かれる。 実際、廃棄のための計画は概念段階でのシステム定義の一部である。 20世紀の経験では、システムの老朽化と廃棄が最初から考慮されていなかった場合の結果が繰り返し示されました。 21世紀初頭には、多くの国で、SoIの作成者にシステムの適切な耐用年数終了後の廃棄について責任を負わせるよう、法律が改正された。 最もよく使われるものを以下に挙げるが、名称は普遍的ではない。
- システム要求レビュー（SRR）は、詳細設計活動を始める前にシステム要求の集合を検証し、妥当性を確認するために計画される。
- 予備設計レビュー予備設計レビュー（PDR）は、最初のエンジニアリングループ（「デザインツー」ゲートとしても知られる）の終了時にシステム要件一式、設計成果物、および正当化要素を検証および妥当性確認するために計画される。
- 重要設計レビュー重要設計レビュー（CDR）は、最後のエンジニアリングループの最後に、システム要件のセット、設計成果物、および正当化要素を検証および妥当性確認するために計画される（「ビルドトゥ」および「コードトゥ」設計は、このレビュー後にリリースされる）
- 統合統合、検証、および妥当性確認レビューは、コンポーネントがより高いレベルのサブシステムおよび要素に組み立てられるように計画される。 一連のレビューは、すべてが適切に統合され、すべての要件が満たされているという客観的な証拠があることを確認するために行われる。 また、進化するシステムが利害関係者の要求を満たすかどうかのプロセス内検証も行わなければならない（図7参照）。
- 最終検証レビューは統合段階の最後に行われる。
- 作業の正しい進行を制御するために、システムの種類と関連するリスクに基づいて、他の管理関連レビューを計画・実施できる。
Works Cited
Eichmueller, P. and B. Foreman. 2010. S3000LTM. Brussels, Belgium: システム・アーキテクチャと設計. Belberaud, France:
Forsberg, K., H. Mooz, and H. Cotterman. 2005. プロジェクトマネジメントの可視化、第3版、ニューヨーク、ニューヨーク、アメリカ：J. Wiley & Sons.
INCOSE. 2012. システムエンジニアリング・ハンドブック: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.
Lawson, H. 2010. A Journey Through the Systems Landscape. London, UK: College Publications, Kings College, UK.
Primary References
Beedle, M., et al.2009.を参考にした。 “アジャイルマニフェスト”。 アジャイルマニフェストの背後にある原則」.in The Agile Manifesto . Accessed December 04 2014 at www.agilemanifesto.org/principles.html
Boehm, B. and R. Turner. 2004. アジリティと規律のバランス. New York, NY, USA: Addison-Wesley.
Fairley, R. 2009. ソフトウェアプロジェクトを管理・指導する。 2005. プロジェクト管理の可視化. 第3版.ニューヨーク, NY, USA: J. Wiley & Sons.
INCOSE. 2012. システムエンジニアリング・ハンドブック: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.
Lawson, H. 2010. A Journey Through the Systems Landscape. キングスカレッジ、英国：カレッジ出版.
Pew, R., and A. Mavor (eds.) 2007. システム開発プロセスにおける人間-システム統合: A New Look. ワシントンDC, USA: The National Academies Press.
Royce, W.E. 1998. ソフトウェアプロジェクトマネジメント: 統一されたフレームワーク.
Additional References
Anderson, D. 2010. Kanban. Sequim, WA, USA: Blue Hole Press.
Baldwin, C. and K. Clark. 2000. デザインルール。 2000. Design Rules: The Power of Modularity. このような場合、「このような場合、どのようにすればよいのか？
Beck, K. 1999. Extreme Programming Explained. 米国ニューヨーク州ニューヨーク：アディソンウェスリー。
Beedle, M., et al.2009年. “アジャイルマニフェスト”。 アジャイルマニフェストの背後にある原則」. in アジャイルマニフェスト. Accessed 2010. で入手可能。 www.agilemanifesto.org/principles.html
Biffl, S., A. Aurum, B. Boehm, H. Erdogmus, and P. Gruenbacher (eds.). 2005. バリューベースド・ソフトウェア・エンジニアリング. 4425>
Boehm, B. 1988.バリューベースド・ソフトウェア・エンジニアリング.ニューヨーク, NY, USA: Springer. “ソフトウェア開発のスパイラルモデル”. IEEE Computer 21(5): 61-72.
Boehm, B. 2006. “システムおよびソフトウェアエンジニアリングプロセスのいくつかの将来の傾向と影響”. システムズ・エンジニアリング. 9(1): 1-19.
Boehm, B., A. Egyed, J. Kwan, D. Port, A. Shah, and R. Madachy. 1998. “WinWinスパイラルモデルの使用。 ケーススタディ”. IEEEコンピュータ． 31(7): 33-44.
Boehm, B., R. Turner, J. Lane, S. Koolmanojwong.の項参照。 2014 (in press). スパイラルモデルを取り入れる インクリメンタル・コミットメント・スパイラル・モデルによる成功するシステムの構築. Boston, MA, USA: Addison Wesley.
Castellano, D.R. 2004. “トップファイブ品質ソフトウェアプロジェクト”. CrossTalk. 17(7) (2004 年 7 月): 4-19. で利用可能。 http://www.crosstalkonline.org/storage/issue-archives/2004/200407/200407-0-Issue.pdf
Checkland, P. 1981. システムシンキング、システムプラクティス。 New York, NY, USA: Wiley.
Crosson, S. and B. Boehm. 2009. “Adjusting Software Life cycle Anchorpoints: システムオブシステムズコンテキストにおける教訓”. Proceedings of the Systems and Software Technology Conference, 20-23 April 2009, Salt Lake City, UT, USA.
Dingsoyr, T., T. Dyba. and N. Moe (eds.). 2010. “アジャイルソフトウェア開発。 Current Research and Future Directions.”. B. Boehm, J. Lane, S. Koolmanjwong, and R. Turner, Architected Agile Solutions for Software-Reliant Systemsにおける章。 4425>
Dorner, D. 1996. The Logic of Failure. “‘If I Could Do That, Then I Could…’ System Engineering in a Research and Development Environment.”（研究開発環境におけるシステム工学）。 第5回国際システム工学評議会(INCOSE)国際シンポジウムの議事録。 1995年7月22日-26日。 St. Louis, MO, USA.
Forsberg, K. 2010. “プロジェクトは要求から始まらない”. Proceedings of the IEEE Systems Conference, 5-8 April 2010, San Diego, CA, USA.
Gilb, T. 2005. Competitive Engineering. 米国ミズーリ州メリーランドハイツ: Elsevier Butterworth Heinemann.
Goldratt, E. 1984. The Goal. システムズ・エンジニアリング: 21世紀のシステム方法論. 米国ニューヨーク州ニューヨーク: Wiley.
Holland, J. 1998. エマージェンス. 米国ニューヨーク州ニューヨーク: ペルセウス・ブックス.4425>
ISO/IEC. 2010. システムおよびソフトウェアエンジニアリング，パート1． ライフサイクルマネジメントのためのガイド. スイス、ジュネーブ。 国際標準化機構（ISO）/国際電気標準会議（IEC）, ISO/IEC 24748-1:2010.
ISO/IEC/IEEE. 2015. システム及びソフトウェアエンジニアリング–システムライフサイクルプロセス． スイス、ジュネーブ。 国際標準化機構／国際電気標準会議／電気電子学会. ISO/IEC/IEEE 15288:2015.
ISO/IEC. 2003. システムズエンジニアリング – ISO/IEC 15288システムライフサイクルプロセスの適用に関する手引書． スイス、ジュネーブ。 International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 19760:2003 (E).
Jarzombek, J. 2003.日本経済新聞社, 2003. “品質ソフトウェアプロジェクト トップ5”. CrossTalk. 16(7) (2003 年 7 月): 4-19. で利用可能。 http://www.crosstalkonline.org/storage/issue-archives/2003/200307/200307-0-Issue.pdf.
Kruchten, P. 1999. ラショナル・ユニファイド・プロセス(The Rational Unified Process). 米国ニューヨーク州ニューヨーク：Addison Wesley.
Landis, T. R. 2010. ロッキード・ブラックバード・ファミリー（A-12, YF-12, D-21/M-21 & SR-71）。 米国ミネソタ州ノースブランチ: Specialty Press.
Madachy, R. 2008. ソフトウェア・プロセス・ダイナミクス. Hoboken, NJ, USA: Wiley.
Maranzano, J.F., S.A. Rozsypal, G.H. Zimmerman, G.W. Warnken, P.E. Wirth, D.W. Weiss. 2005. 「建築レビュー。 実践と経験”. IEEE Software. 22(2): 34-43.
National Research Council of the National Academies (米国). 2008. Pre-Milestone A and Early-Phase Systems Engineering. ワシントン DC, USA: The National Academies Press.
Osterweil, L. 1987. “ソフトウェアプロセスもソフトウェアである”. Proceedings of the SEFM 2011: 9th International Conference on Software Engineering. Monterey, CA, USA.
Poppendeick, M. and T. Poppendeick. 2003. リーンソフトウェア開発：アジャイルツールキット. また，このような場合にも，「ソフトウェア・エンジニアリング」 の重要性を再認識することができる。 システムアーキテクト: 1991. System Architecting: Creating and Building Complex Systems. このような場合、「アジャイル開発」と呼ばれる。 1997. システムアーキテクトの技法. 米国フロリダ州ボカラトン: CRC Press.
Schwaber, K. and M. Beedle. 2002. スクラムによるアジャイルソフトウェア開発. 米国ニューヨーク州アッパーサドルリバー: プレンティスホール.
Spruill, N. 2002. “トップ5の高品質ソフトウェアプロジェクト”. CrossTalk. 15(1) (January 2002): 4-19. Available at: http://www.crosstalkonline.org/storage/issue-archives/2002/200201/200201-0-Issue.pdf.
Stauder, T. 2005. “国防総省のプログラム賞トップ5”. CrossTalk. 18(9) (2005 年 9 月): 4-13. http://www.crosstalkonline.org/storage/issue-archives/2005/200509/200509-0-Issue.pdf.
Warfield,J.1976で利用可能。 Societal Systems: 計画・政策・複雑性. New York, NY, USA: Wiley.
Womack, J. and D. Jones. 1996. リーン・シンキング. New York, NY, USA: Simon and Schuster.
関連動画=
- システム工学（V方式）基礎入門
- システム工学（V方式）基礎入門 Part2 of 2