ライフサイクルモデル

主な執筆者。 Kevin Forsberg、Rick Adcock、Contributing Author: Alan Faisandier

ライフサイクルモデルはシステムエンジニアリング（SE）の重要な概念の1つである。 システムシステムのライフサイクルは、一般に一連のステージで構成され、システムがあるステージを出て別のステージに入るのに十分成熟していることを確認する一連の管理決定により規制される。

Topics

SEBoKの各部分は、関連するテーマを持つ情報のグループである知識エリア（KA）に分割されています。 KAは順にトピックに分割される。 このKAには以下のトピックが含まれる。

• システムライフサイクルプロセスドライバと選択
• システムライフサイクルプロセスモデル。 Vee
• システムライフサイクル・プロセスモデル。 反復的
• プロセスモデルと製品モデルの統合
• リーンエンジニアリング

第7部に含まれるケーススタディやビネットを第3部で扱うトピックにマッピングするには、実装例のマトリクスという記事を参照してください。 付加価値（製品、サービス、またはその両方）は、公的または私的、営利または非営利を問わず、すべての企業で共有される目的である。 価値は、システムの説明に従って、システムの要素を製品やサービスに提供し、統合し、生産的な使用に移行させることによって生み出される。 このような価値の検討は、図1の一般的なライフサイクルマネジメントのアプローチを様々な形で実現することになる。 いくつかの例は次のとおりです (Lawson 2010)。

• ある製造企業がナット、ボルト、ロックワッシャー製品を生産し、その製品を付加価値要素として販売して、他の企業で使用させます。

• 卸売・小売企業は、顧客に製品を提供する。 その顧客（個人または企業）は製品を入手し、それをシステムの要素として使用します。

• 銀行のような商業サービス企業は、顧客にサービスとしてさまざまな製品を販売します。 これには、当座預金、普通預金、ローン、および投資管理などが含まれます。 これらのサービスは付加価値を与え、個人または企業の顧客システムに組み込まれる。

• 政府サービス企業は市民にサービスを提供するが、その内容は多岐にわたるが、医療、高速道路および道路、年金、法執行、または防衛などのサービスが含まれる。 適切な場合、これらのサービスは、個人および/または企業が関心を持つ、より大規模な包括的システムで利用されるインフラストラクチャ要素になります。 次世代航空管制システムや大都市圏危機管理システム（ハリケーン、台風、地震、津波、洪水、火災）などの主要な構想は、進化的な開発・実戦投入のアプローチをとるのに十分なほど複雑なものになる。

• 航空機および自動車システムの場合、最初のパスで初期の能力を活用するために、あらかじめ指定された複数のパスのライフサイクルがあると思われますが、後のパスではさらに付加価値を高める能力を追加するように設計されます。 それは、異なる顧客のライフサイクルアプローチで利用できるように調整できる能力と、同様の顧客のシステム開発に迅速かつ容易に適用できる製品ラインの能力を持つように開発される必要があります。 そのビジネスモデルは、顧客にシステムのライフサイクルサポートと進化機能を提供することも含まれるかもしれません。

これらの例の中には、適度に長い期間にわたって安定しているシステムと急速に変化するシステムがあります。 これらの例とそのプロセスが示す多様性は、特定のシステム ライフサイクルを定義するために使用できる画一的なプロセスが存在しない理由を示しています。 マネジメントとリーダーシップのアプローチは、関係するシステムの種類、その寿命、そして競争、技術、リーダーシップ、任務の優先順位など、予期せぬ変化への迅速な適応の必要性を考慮しなければならない。 さらに、管理およびリーダーシップのアプローチは、展開されるライフサイクルモデルの種類と数、および特定のライフサイクル内で使用されるプロセスに影響を与える。 ライフサイクルモデル知識エリアでは、多くのincrementalincrementalおよびevolutionaryevolutionaryライフサイクルモデルを要約し、それらの主な長所と短所を含め、また最も適合するアプローチを選択する基準について議論します。

Categories of Life Cycle Model

図1の一般システムライフサイクルモデルがすべての状況に明示的に適合するわけではありません。 単純で、先行する、追随するシステムは、定義段階で1つのフェーズしか必要ないかもしれないが、複雑なシステムは、2つ以上のフェーズが必要かもしれない。 ビルドアップシステム（対使い捨て）プロトタイプでは、開発のかなりの部分が定義段階で行われるかもしれません。 システム統合システム要素の実装または取得の後に、統合、検証、および妥当性確認が行われる場合がある。 ソフトウェアの場合、特にテストファーストやデイリービルドでは、統合、検証、妥当性確認は要素の実装に織り込まれている。 また、3次元印刷やデジタルマニュファクチャリングによる第3次産業革命（Whadcock 2012）を控えて、初期開発だけでなく初期生産もコンセプトの段階で行われる可能性があります。

ソフトウェアは、システムの純粋に物理的なコンポーネントでは通常不可能なほど、反復的な分析、設計、構築、検証、および妥当性確認を容易にする柔軟で可鍛性のある媒体である。 反復開発モデルの各反復は、拡大するソフトウェア ベースに材料 (コード) を追加し、拡大したコード ベースはテストされ、必要に応じて作り直され、ベースラインの要件を満たすことが実証される

ソフトウェアは、デジタル通信が届く範囲なら世界のどこでも電子的に購入、販売、配送、アップグレードでき、ハードウェアとは大幅に異なる物流とコスト効率を実現する。 ソフトウェアは消耗せず、修正によってコンテンツや動作が変わるため、回帰テストはハードウェアの修正よりも複雑になります。 離散的な性質があるため、ハードウェアのように分析の継続性に頼ったテストができない。 15ビットレジスタの32767に1を加えても32768にはならず、パトリオットミサイルの使用のような深刻な状況で経験したように0になってしまうのだ。 それらは 3 つの主要なカテゴリに分類されます。

1. 主に事前指定された逐次プロセス (たとえば、シングルステップのウォーターフォール モデル)
2. 主に進化的および並行プロセス (たとえば、リーン開発、合理的統一プロセス、さまざまな形式の Vee およびスパイラル モデル)
3. 主に対人および出現プロセス (たとえば、… 続きを読む アジャイル開発、スクラム、エクストリーム プログラミング (XP)、動的システム開発手法、およびイノベーション ベースのプロセス）

統合されたインタラクティブなハードウェア-ソフトウェア システムの出現により、事前に特定されたプロセスが潜在的に有害となり、その使用により最も有効な人間-システム インターフェイスが出現し、ソフト SE (Warfield 1976、 Checkland 1981) や人間-システム統合プロセス (Booher 2003、Pew and Mavor 2007) など、さらなるプロセスバリエーションを生み出す傾向があったためである。 最近まで、プロセス標準と成熟度モデルは、あらゆる事態をカバーしようとしてきた。 これらのプロセスには、取得管理、調達先選定、レビューと監査、品質保証、構成管理、文書管理などの広範なプロセスが含まれており、多くの場合、過度に官僚的で非効率的なものとなってしまいます。 このため、コンカレントVeeモデル（Forsberg 1991; Forsberg 2005）やインクリメンタルコミットメントスパイラルモデル（Pew and Mavor 2007; Boehm and Lane 2007）など、ハードウェア・ソフトウェア・ヒューマンファクターの同時並行的アプローチに、よりリーン（大野 1988; Womack et al.1990; Oppenheim 2011）やアジャイル（Beck 1999; Anderson 2010）のアプローチを導入することになったのである。

次回の「システム ライフサイクル プロセスの推進要因と選択」では、ライフサイクル モデルのテーマに関するこれらのバリエーションを識別および提示します。

システムズ エンジニアの責任

展開されるライフサイクル モデルにかかわらず、システムズ エンジニアの役割は、対象システムのライフサイクル全体を包含しています。 システムエンジニアは、要件定義から運用、そして最終的にはシステムの廃棄に至るまで、ソリューションの開発と進化を指揮する。 システムエンジニアは、専門家が適切に関与し、すべての有利な機会が追求され、すべての重大なリスクが特定され、可能であれば軽減されることを保証します。 システムエンジニアは、プロジェクトマネージャーと密接に連携し、主要な意思決定ゲートや意思決定ゲートを含む一般的なライフサイクルを、特定のプロジェクトのニーズに合わせて調整します。

システムズエンジニアリングのタスクは通常ライフサイクルの初期に集中するが、商業組織と政府組織の両方が、システムのライフサイクルを通してのSEの必要性を認識している。 多くの場合、この継続的な努力は、システム、製品、またはサービスが生産に入った後、または運用に移された後に修正または変更することである。 その結果、SEはライフサイクルの全段階において重要な役割を担っている。 例えば、生産、サポート、利用（PSU）の段階では、SEは性能分析、インターフェース監視、故障分析、物流分析、追跡、変更案の分析などを実行する。 これらの活動はすべて、システムの継続的なサポートに不可欠である。

すべてのプロジェクトマネージャーは、プロジェクトサイクルのビジネス面（コスト、スケジュール、価値）と技術面の同期が保たれていることを確認しなければならない。 多くの場合、技術的な側面がプロジェクトを推進する。 検討されている技術的なソリューションがコストとスケジュールの目標と一致していることを確認するのは、システムエンジニアの責任である。 そのためには、ユーザーや顧客と協力し、ビジネスの範囲内に収まるように目標を修正することが必要になる場合もあります。 このような問題から、プロジェクトサイクルを通じて適切な間隔でディシジョンゲートを設置する必要があります。 これらのディシジョンゲートの内容は、上記の大分類によって異なりますが、いずれも開発者とエンドユーザーとの間のインプロセスバリデーションin-process validationを伴います。 インプロセス検証では、次のような質問をする。 「企画・制作しているものがステークホルダーのニーズを満たすか？ インプロセス検証は、プロジェクトの初期段階であるユーザーニーズの発見から始まり、日々の活動、正式な意思決定ゲートレビュー、最終製品またはソリューションの提供、運用、そして最終的にはシステムの閉鎖と廃棄に至るまで続きます。 Kanban. Sequim, WA: 504>

Beck, K. 1999. エクストリームプログラミングの説明. ボストン，マサチューセッツ州． このような場合，「このような場合，どのようにすればよいのか？ 2007. “システム取得、システムエンジニアリング、およびソフトウェアエンジニアリングを統合するためのインクリメンタルコミットメントモデルの使用”. CrossTalk. 2007年10月。 4-9.

Booher, H. (ed.) 2003. ヒューマンシステムインテグレーションハンドブック. Hoboken, NJ, USA: Wiley.

Checkland, P. 1999. 504>

Cusumano, M., and D. Yoffie.「システム思考、システム実践、第2版」, Hoboken, NJ, USA: Wiley. 1998. このような場合、「インターネット時間での競争」、米国ニューヨーク州ニューヨーク。 The Free Press.

Forsberg, K. and H. Mooz.は、「インターネット時間での競争」、New York, NY, USA: The Free Press.を参照してください。 1991. また、このような場合、「プロジェクト・サイクルとシステムエンジニアリングの関係」、INCOSE、1991年10月、

Forsberg, K., H. Mooz, and H. Cotterman. 2005. Visualizing Project Management, 3rd ed. Hoboken, NJ: J. Wiley & Sons.

ISO/IEC/IEEE. 2015.Systems and software engineering – system life cycle processes.Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), Institute of Electrical and Electronics Engineers.ISO/IEC 15288:2015.

Lawson, H. 2010.システムおよびソフトウェアエンジニアリング-システムライフサイクルプロセス.International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), Institute of Electrical and Electronics Engineers. A Journey Through the Systems Landscape（システムランドスケープの旅）. London, UK: College Publications.

Ohno, T. 1988. トヨタ生産方式. ニューヨーク, NY:

Oppenheim, B. 2011. システムエンジニアリングのためのリーン. Hoboken, NJ: Wiley.

Pew, R. and A. Mavor (eds.). 2007. システム開発プロセスにおける人間-システム統合: A New Look. また，このような場合，「震災の影響」を考慮する必要がある。 システムズ・エンジニアリング. ワシントンDC, USA: US Department of Commerce (DoC).

Whadcock, I. 2012. “第三次産業革命”. The Economist. 2012年4月21日。

Womack, J.P., D.T. Jones, and D. Roos 1990. The Machine That Changed the World: The Story of Lean Production. New York, NY, USA: ローソン・アソシエイツ

主な参考文献

Blanchard, B.S., and W.J. Fabrycky. 2011. システムエンジニアリングと分析, 第 5 版. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.

Forsberg, K., H. Mooz, H. Cotterman.日本学術振興会特別研究員（PD）。 2005. プロジェクトマネジメントの可視化, 第3版. Hoboken, NJ: J. Wiley & Sons.

INCOSE. 2012. システムエンジニアリング・ハンドブック，バージョン3.2.2. 米国カリフォルニア州サンディエゴ: 国際システムエンジニアリング評議会 (INCOSE). INCOSE-TP-2003-002-03.2.2.

Lawson, H. 2010. A Journey Through the Systems Landscape. London, UK: College Publications.

Pew, R. and A. Mavor (Eds.). 2007. システム開発プロセスにおける人間-システム統合: A New Look. 2003. CMMI。 プロセス統合と製品改良のためのガイドライン. 米国ニューヨーク州ニューヨーク: アディソンウェスリー.

Larman, C. and B. Vodde. 2009. 2009. Scaling Lean and Agile Development. New York, NY, USA: Addison Wesley.

以下の3冊の本は、SEBoKのテキストでは参照されておらず、システム工学の「テキスト」でもありませんが、重要なシステム工学の教訓が含まれており、本SEBOKの読者はそれらを読むことが推奨されます。 ディープ・ブルー・シーに浮かぶ黄金の船. New York, NY, USA: Grove Press.

これは、あるアイデアの発案から最終的に成功する実装までを追った優れた本です。 システムエンジニアリングは議論されていませんが、初期のプロジェクト定義から代替コンセプトの開発、段階的な探査と「思考実験」、途中の課題への対処に至る全過程が明確に説明されています。 また、通常のプロジェクトやエンジニアリングの範囲外の重大な問題を予期していなかったという問題も示されています。 水深2,500mの海に沈んだ船から24トンの金の延べ棒とコインを発見し回収するのに約5年かかったが、1857年に金の所有者に発行した130年前の保険に基づいて所有権を主張する保険会社の代表弁護士との法廷闘争に勝つまでに10年を要したのである。

McCullough, D. 1977. The Path Between the Seas: The Creation of the Panama Canal (1870 – 1914). New York, NY, USA: Simon & Schuster.

「システムズエンジニアリング」は言及されていないが、本書は多くのシステムズエンジニアリングの問題を強調し、学問としてのSEの必要性を示している。 また、以前に成功したコンセプト（10年前にスエズで使われた海面水路）を、似ているが異なる状況に適用することの危険性をも示しています。 フェルディナン・ド・レセップスは、スエズとパナマの両プロジェクトを主導した。 これは、事実に基づくプロジェクトサイクルと、プロジェクトサイクル全体を通して意味のある意思決定ゲートを欠いていることの危険性を示している。 また、プロジェクトの状況を可視化することなく提供することの危険性も浮き彫りにしている。 10年間のプロジェクトで5年後、投資家はプロジェクトが50％以上完成したと言われたが、実際には10％しか完成していなかった。 1904年、スティーブンスのもとで行われた第2次開発は、運河を掘ることよりも「土を動かす」ことに重点が置かれ、運河完成の鍵を握るシステムエンジニアリングのコンセプトが示された。 The Path Between the Seasは、National Book Award for history (1978), Francis Parkman Prize (1978), Samuel Eliot Morison Award (1978), Cornelius Ryan Award (1977)を受賞した。 (原著：William Heinemann, London, 1919). South: シャクルトンとエンデュランス号の最後の南極探検. Guilford, CT, USA: Lyons Press.

1914年から1917年にかけてのシャクルトンとエンデュランス号による最後の南極探検の驚くべき物語です。 システムエンジニアリングの教訓は、18ヶ月間北極の氷に閉じ込められた船長、探検隊長、乗組員による毎日の継続的なリスクアセスメントにあります。 28人の乗組員全員が生き残った。

関連動画

• NASA’s Approach to Systems Engineering- Space Systems Engineering 101 w/ NASA