「ライフサイクル」の版間の差分
編集の要約なし |
編集の要約なし |
||
| (同じ利用者による、間の2版が非表示) | |||
| 1行目: | 1行目: | ||
Life Cycleとは、[[ミッション]]の創出から、[[要求定義]]、[[設計]]、[[製造]]、[[試験]]、[[運用]]、[[廃棄]]に至るサイクルであり、段階的プロジェクト計画法の全[[フェーズ]]を包含している。<ref>システムズエンジニアリングの基本的な考え方 初版 JAXA 2007年4月B改訂</ref> | Life Cycleとは、[[ミッション]]の創出から、[[要求分析と要求定義|要求定義]]、[[設計]]、[[製造]]、[[試験]]、[[運用]]、[[廃棄]]に至るサイクルであり、段階的プロジェクト計画法の全[[フェーズ]]を包含している。<ref>システムズエンジニアリングの基本的な考え方 初版 JAXA 2007年4月B改訂</ref> | ||
== システムモデルで明確にすること == | == システムモデルで明確にすること == | ||
*ライフサイクルステージ:コンセプト⇒開発⇒製造⇒運用と保守⇒廃棄(それぞれについて検討する必要がある。さもなければ、システムは実現しない。) | *ライフサイクルステージ:コンセプト⇒開発⇒製造⇒運用と保守⇒廃棄(それぞれについて検討する必要がある。さもなければ、システムは実現しない。) | ||
*それぞれのステージについてコンテキスト(文脈、脈略)を最初に考え、抜け漏れがないことを確認する。その際、利害関係者の要求や懸念事項をすべて洗い出す。その上で、対象システムの境界、[[ユースケース]]、機能性を明確にする。 | *それぞれのステージについてコンテキスト(文脈、脈略)を最初に考え、抜け漏れがないことを確認する。その際、利害関係者の要求や懸念事項をすべて洗い出す。その上で、対象システムの境界、[[ユースケース図|ユースケース]]、機能性を明確にする。 | ||
*次に対象システムの内部を分析し、総合する。最初に機能を分解して、その分解された機能をシステム構成要素に割り当てる。これにより、システム構成要素間のインタフェースが定義され、アーキテクチャの候補が導出できる。 | *次に対象システムの内部を分析し、総合する。最初に機能を分解して、その分解された機能をシステム構成要素に割り当てる。これにより、システム構成要素間のインタフェースが定義され、アーキテクチャの候補が導出できる。 | ||
*要求や懸念事項に応じてView(観点)を設定し、トレードオフ分析によりいくつかの候補の中から適切な[[アーキテクチャ]]を選定する。 | *要求や懸念事項に応じてView(観点)を設定し、トレードオフ分析によりいくつかの候補の中から適切な[[アーキテクチャ]]を選定する。 | ||
<ref>慶應義塾大学大学院システムデザイン・マネジメント研究科 教授 西村秀和</ref> | |||
== 出典 == | == 出典 == | ||
<references /> | <references /> | ||
== 関連項目 == | |||
[[モデル]]<br> | |||
[[モデルベース開発]] | |||
2017年5月12日 (金) 04:28時点における最新版
Life Cycleとは、ミッションの創出から、要求定義、設計、製造、試験、運用、廃棄に至るサイクルであり、段階的プロジェクト計画法の全フェーズを包含している。[1]
システムモデルで明確にすること
- ライフサイクルステージ:コンセプト⇒開発⇒製造⇒運用と保守⇒廃棄(それぞれについて検討する必要がある。さもなければ、システムは実現しない。)
- それぞれのステージについてコンテキスト(文脈、脈略)を最初に考え、抜け漏れがないことを確認する。その際、利害関係者の要求や懸念事項をすべて洗い出す。その上で、対象システムの境界、ユースケース、機能性を明確にする。
- 次に対象システムの内部を分析し、総合する。最初に機能を分解して、その分解された機能をシステム構成要素に割り当てる。これにより、システム構成要素間のインタフェースが定義され、アーキテクチャの候補が導出できる。
- 要求や懸念事項に応じてView(観点)を設定し、トレードオフ分析によりいくつかの候補の中から適切なアーキテクチャを選定する。