この規格ページの目次
53
X 0170 : 2020 (ISO/IEC/IEEE 15288 : 2015)
注記2 問題の分類及び優先度の分類についての,更なる情報及び例は,ISO/IEC/IEEE
24748-1:2018を参照。
1) インシデントを記録し,分析し,分類する。
2) インシデントを解決するか,又は問題へと格上げする。
3) 問題を記録し,分析し,分類する。
注記 分析結果に,可能性のある処置の選択肢を含める。
4) 問題の処置を優先順位付け,処置の実施を追跡する。
注記 処置の実施は,プロジェクトアセスメント及び制御プロセスが始動させるテクニカルプロ
セスの中で遂行する。
5) インシデント及び問題の傾向を確認し分析する。
6) 利害関係者へインシデント及び問題の状況について通知する。
7) インシデント及び問題を終了まで追跡する。
6.4 テクニカルプロセス(Technical processes)
テクニカルプロセスは,システムに対する要求事項を定義し,要求事項を製品を利用したときに効果の
ある製品へ変換し,必要に応じて,一貫性をもたせた再製品化・再生産を可能にし,要求されたサービス
を提供するために製品を利用し,そうしたサービス提供を維持し,かつ,製品がサービスにおいて利用さ
れなくなったときには製品を廃棄するために用いる。テクニカルプロセスは,組織及びプロジェクトの機
能が便益を最適化するためのアクティビティ,並びに技術的な決定及び行動から発生するリスクを軽減す
るためのアクティビティを定義する。これらのアクティビティは,製品及びサービスが次に示す事項を備
えられるようにする。
− 適時性及びアベイラビリティ(可用性)
− コストに対する効果の高さ(費用対効果)
− 機能性,信頼性,保守性,生産可能性,使用性,並びに取得する組織及び供給する組織によって要求
される,その他の品質
これらのアクティビティは,製品及びサービスが,人の健康,安全性,セキュリティ及び環境上の要因
を含めた,社会の期待又は法令の要求事項に適合できるようにもする。
テクニカルプロセスは,次によって構成される。
a) ビジネス又はミッション分析プロセス(Business or Mission Analysis process)
b) 利害関係者ニーズ及び利害関係者要求事項定義プロセス(Stakeholder Needs and Requirements Definition
process)
c) システム要求事項定義プロセス(System Requirements Definition process)
d) アーキテクチャ定義プロセス(Architecture Definition process)
e) 設計定義プロセス(Design Definition process)
f) システム分析プロセス(System Analysis process)
g) 実装プロセス(Implementation process)
h) インテグレーションプロセス(Integration process)
i) 検証プロセス(Verification process)
j) 移行プロセス(Transition process)
k) 妥当性確認プロセス(Validation process)
l) 運用プロセス(Operation process)
――――― [JIS X 0170 pdf 56] ―――――
54
X 0170 : 2020 (ISO/IEC/IEEE 15288 : 2015)
m) 保守プロセス(Maintenance process)
n) 廃棄プロセス(Disposal process)
注記1 ソフトウェア及びハードウェアのシステム要素に対して,これらのプロセスは,システム定
義のために下位レベルへ再帰的に適用し,かつ,システム実現のために上位レベルへも再帰
的に適用する。利害関係者ニーズ及び利害関係者要求事項の定義,システム要求事項定義,
アーキテクチャ定義,設計定義,システム分析,インテグレーション,検証及び妥当性確認
のために,これらのプロセスをそれぞれのレベルで適用する。
注記2 要求事項,重大なシステムの遂行能力・性能・運用時の実績についての測定量,及び重大な
品質特性の間でバランスさせたソリューションを確立するため,これらのプロセスを,互い
に同時並行し,反復して,実施することがよくある。いずれの抽象度レベルであっても,シ
ステムの要求事項とモデルとの間は,テクニカルプロセスを反復して適用することによって
一貫性をもたせる。要求事項及びモデルがそのまま直接的に実装されるものではないときは,
例えば,システムの階層の一段下位レベルのような,より詳細なレベルで同じプロセスを再
帰的に繰り返す。
注記3 ライフサイクル段階の概念,及び各段階における,これらのプロセスの適用についての詳細
は,ISO/IEC/IEEE 24748-1:2018に記述されている。そこには,システムライフサイクル内
でテクニカルプロセスを制定するときの段階の例及び段階ごとの成果の例がまとめられてい
る。
注記4 インタフェース管理は,システムエンジニアリングプロセスを横断するアクティビティの集
合となる。これらのアクティビティは,テクニカルプロセス及びテクニカルマネジメントプ
ロセスを横断しているアクティビティで,特定のプロセスビュー及びシステムビューとして
適用され,追跡される。インタフェース管理プロセスビューの例は,附属書Eを参照。より
詳細な情報はINCOSEシステムエンジニアリングハンドブック第4版の9.6を参照。
注記5 INCOSEはThe International Council on Systems Engineering(国際システムエンジニアリング協
議会)を指す。
6.4.1 ビジネス又はミッション分析プロセス(Business or Mission Analysis process)
6.4.1.1 目的
ビジネス又はミッション分析プロセスは,ビジネス又はミッションにおける問題又は機会を定義し,ソ
リューション空間を特徴付け,問題を取り上げ解決できる又は機会を有益にいかすことができるような,
一つ以上の潜在的な可能性をもつソリューションの集まりを決定することを目的とする。
注記1 ビジネス又はミッションの分析は,システムライフサイクルのアクティビティに関与する全
ての利害関係者を包含する組織に関係する。このプロセスは,一般的にはこの規格の適用範
囲外となる組織の戦略と相互に連携するものである。
組織の戦略分析結果は,組織における組織レベルの運用概念(ConOps),戦略的な最終目
標であるゴール及び計画,新規市場又はミッション要素,並びに識別された問題(problems)
及び機会(opportunities)を含む。組織の戦略は,指定した状況の範囲内でビジネス又はミッ
ションの分析を実施するように,その状況を確立する。
組織における組織レベルの運用の概念は,組織で指導的役割をもった者の意図する組織の
運用方法に関係する。それは,ビジネスの運用全体又は連携した運用を支援する中で,組織
が想定している前提,並びに開発されることになるシステム,既存システム,及び実現する
――――― [JIS X 0170 pdf 57] ―――――
55
X 0170 : 2020 (ISO/IEC/IEEE 15288 : 2015)
可能性のある将来のシステムをどのようにして用いることを意図しているのかを記述したも
のになる。組織が対象システムである場合には,組織の戦略はシステム定義の一部分となる。
注記2 このプロセスは,システムのソリューションが有効な期間を通して適用され,環境,ニーズ
又は他の駆動要因に変更があれば再度行われる。
注記3 幾つかの領域において,これは組織が必要としているか又は要望している能力を,識別及び
分析するという概念に関係する。このプロセスは,能力を取り扱うことが可能なトレードオ
フ空間を識別するために行う,ポートフォリオ管理プロセスとの必要な連携,及びトレード
オフ空間内で調整して得られる必要な能力に焦点を当てている。
識別された問題又は機会は,どのようなことがどの程度まで可能になることを目標とする,
という目標能力に変換されることがよくある。所与の領域内において適用可能なときには,
問題又は機会の空間には目標能力が含まれる。
6.4.1.2 成果
ビジネス又はミッション分析プロセスの実施に成功すると次の状態になる。
a) 問題又は機会が存在し得る範囲を表す,問題又は機会の空間が定義されている。
b) ソリューションが存在し得る範囲を表す,ソリューション空間が特徴付けられている。
c) ライフサイクル段階における,予備的な,システムレベルの運用概念(OpsCon)及び他の概念が定義
されている。
d) 複数の,選択候補となる代替ソリューションの集まりが識別及び分析されている。
e) 一つ以上の,好ましい代替ソリューションの集まりの候補が選定されている。
f) ビジネス又はミッション分析の実施を可能にするために必要な全てのイネーブリングシステム又はサ
ービスが利用可能になっている。
g) ビジネス又はミッションの問題及び機会と,好ましい代替ソリューションの集まりとの間のトレーサ
ビリティが確立されている。
6.4.1.3 アクティビティ及びタスク
プロジェクトは,ビジネス又はミッション分析プロセスに関する,適用可能な組織の方針及び手順に従
って,次に示すアクティビティ及びタスクを実施しなければならない。
a) ビジネス又はミッション分析の準備を行う。このアクティビティは,次のタスクからなる。
1) 組織が要望しているゴール及び目標の観点から,組織の戦略において識別された問題及び機会をレ
ビューする。
注記 これには,組織のビジネス又はミッション,展望,組織レベルの運用概念,並びに組織の
戦略的な最終目標であるゴール及び当面の目標に関する問題及び機会を含む。これは,現
在の能力,システム,製品又はサービスにおける欠如又はギャップも含む。
2) ビジネス又はミッション分析の戦略を定義する。
注記 これには,問題空間を識別及び定義し,ソリューション空間を特徴付けし,かつ,ソリュ
ーションの集まりを選定するために用いる取組方法を含む。
3) ビジネス又はミッション分析を支援するために必要とする,イネーブリングシステム又はサービス
を識別し計画する。
注記 これには,イネーブリングシステムに対する要求事項及びインタフェースの識別を含む。
ビジネス又はミッション分析のためのイネーブリングシステムには,組織のビジネスで用
いているシステム及びリポジトリも含む。
――――― [JIS X 0170 pdf 58] ―――――
56
X 0170 : 2020 (ISO/IEC/IEEE 15288 : 2015)
4) 利用されるイネーブリングシステム若しくはサービスを,獲得する又はそれらへのアクセスを取得
する。
注記 ビジネス又はミッション分析の実現を支援するイネーブリングシステムの支援機能が,意
図されたように利用できるかを客観的に確認するために,妥当性確認プロセスが用いられ
る。
b) 問題又は機会の空間を定義する。このアクティビティは,次のタスクからなる。
1) トレードオフ空間の要因に関係付けられた状況の中で,問題及び機会を分析する。
注記1 この分析は,問題又は機会の,範囲,基盤又は駆動要因を理解することに焦点を当てた
ものである。この分析は,トレードオフ分析に必要なシステム分析及び意思決定管理に
焦点を当てた総合化とは反対方向のものである。ここで焦点を当てる対象は,ミッショ
ンの要求事項の変更,ビジネスにおける機会,能力,既存システムの遂行能力・性能・
運用時の実績の改善又は不足,セキュリティ及び安全性の改善,コスト及び有用性のよ
うな要因,規則の変更,利用者の不満足,並びにPESTEL要因[政治(Political),経済
(Economic),社会(Social),技術(Technological),環境(Environmental)及び法律(Legal)]
を含む。これは外部からの分析,内部での分析,又はSWOT分析[強み(Strengths),
弱み(Weaknesses),機会(Opportunities)及び脅威(Threats)]によって達成される場合
がある。
注記2 分析の出力は,ポートフォリオ管理の意思決定の一部分とも考えられる。
2) ミッション,ビジネス又は運用における問題又は機会を定義する。
注記 この定義には,特定のソリューションを考慮することなく,状況及び全ての主要パラメー
タを含める。その理由は,運用上の変更,既存の製品若しくはサービスの変更,又は新シ
ステムのいずれもがソリューションとなる可能性があるからである。
c) ソリューション空間を特徴付ける。このアクティビティは,次のタスクからなる。
1) ライフサイクルの段階における,予備的な,システムレベルの運用概念及び他の概念を定義する。
注記1 これには,顧客,利用者,運営管理者,規制機関,システムの所有者などの,主要な利
害関係者のグループの識別を含む。これら主要な利害関係者は,利害関係者ニーズ及び
利害関係者要求事項定義プロセスで定義されることになる。
注記2 ライフサイクルを構想した予備的なライフサイクル概念には次を含める。予備的な取得
概念,予備的な展開概念,予備的なシステムレベルの運用概念,予備的な支援概念,及
び予備的な廃棄概念。システムレベルの運用概念には,抽象度の高いレベルでの運用モ
ード若しくは状態,運用シナリオ(operational scenarios),可能性のあるユースケース,
又は提案されているビジネス戦略における利用法を含む。これらの概念は,実現可能性
の分析及び代替案の評価を可能にする。これらの概念は,利害関係者ニーズ及び利害関
係者要求事項定義プロセスで更に詳細化される。
注記3 運用中の環境は,特定のセキュリティへの脅威及び安全性へのハザード(危害の潜在的
な源,潜在危険 hazard)に関する,ぜい弱性があると考えられる場合がある。このよ
うな,ぜい弱性は,開発中の製品に関係付けて理解される必要がある。システムと人間
とのインタフェースは,システムのアシュアランスを実現する状況における一つの要素
であり,インタフェースに関連するぜい弱性は重大なミッションが連鎖する状況におい
て詳細に調査される。
――――― [JIS X 0170 pdf 59] ―――――
57
X 0170 : 2020 (ISO/IEC/IEEE 15288 : 2015)
2) 潜在的な可能性をもったソリューション空間を広げる,複数の,代替ソリューションの集まりの候
補を識別する。
注記 これらは,単に運用上の変更から様々なシステムの開発又は変更までに範囲が広がる場合
がある。ソリューション空間は,その運用又は機能の変更へのニーズを取り上げて解決で
きるような,既存システム,製品,サービスを識別することを含めることができる。これ
には,必要とされるであろう,潜在的に望まれているサービスには何があるかを推定する
ことも含む。ソリューション空間に特性を付与するときは,アーキテクチャ ビュー(例え
ば,能力ビュー,プログラムビュー及び運用ビュー)にした利用者のアーキテクチャ ビュ
ーポイントに対して,アーキテクチャ定義プロセスを実行することもよくある。これは
ISO/IEC/IEEE 42010によって提案されている。
d) 複数ある代替ソリューションの集まりを評価する。このアクティビティは,次のタスクからなる。
1) 代替ソリューションの集まりそれぞれのアセスメントを行う。
注記1 代替ソリューションの集まりそれぞれを,組織の戦略に基づいて確立され,定義された
基準に対してアセスメントを行う。ソリューションの集まりの実現可能性は重要な意思
決定基準の一つとなる。ポートフォリ管理プロセスから考慮の対象となる幾つかの基準
が提供される。
注記2 システム分析プロセスが,代替ソリューションの集まりの各集合に対する各基準につい
て,アセスメントを行って値を決めるために用いられる。構造化されているトレードオ
フ分析が推奨される。コストを基準に含めると,無理のない費用で利用しやすい意思決
定を助けることになる。複数ある代替ソリューションの集まりがもつリスク,実現可能
性及び基準についての値を理解するために,代替案のアセスメントでは,モデル化,シ
ミュレーション,分析技法又は専門家による判断を含めることができる。
2) 一つ以上の,好ましい代替ソリューションの集まりを選定する。
注記 意思決定管理プロセスが,代替案を評価し,選定方法を手引きするために用いられる。選
定された代替案について組織の戦略における状況の中で妥当性確認が実施される。リスク,
実現可能性,市場の要因及び代替案へのフィードバックが,組織の戦略の更新に使用する
ために提供される。
e) ビジネス又はミッション分析を管理する。このアクティビティは,次のタスクからなる。
1) ビジネス又はミッション分析のトレーサビリティを維持する。
注記 ライフサイクルを通じて,ビジネス及びミッションの問題及び機会と,好ましい代替ソリ
ューションの集まりとの間で,双方向のトレーサビリティを維持する。これには,組織の
戦略,利害関係者のニーズ及び利害関係者要求事項,並びに意思決定を助けたシステム分
析結果も付加する。
2) ベースラインのために選定された重要な情報項目を提供する。
注記 構成管理プロセスが,構成品目及びベースラインを確立し維持するために用いられる。こ
のプロセス(ビジネス又はミッション分析プロセス)で,ベースラインのための候補とな
る情報項目を識別し,CM(構成管理)へ情報項目を提供する。
6.4.2 利害関係者ニーズ及び利害関係者要求事項定義プロセス(Stakeholder Needs and Requirements
Definition process)
6.4.2.1 目的
――――― [JIS X 0170 pdf 60] ―――――
次のページ PDF 61
JIS X 0170:2020の引用国際規格 ISO 一覧
- ISO/IEC/IEEE 15288:2015(IDT)