113
X 0170 : 2020 (ISO/IEC/IEEE 15288 : 2015)
管理を容易にすることである。
成果 :
a) インタフェースに関連するビジネス又はミッションのニーズが識別されている。
b) インタフェースに関係する利害関係者のニーズが識別されている。
c) インタフェース要求事項が定義されている。
d) システム要素間のインタフェースが識別され,定義されている。
e) システムと外部システムとの間のインタフェースが識別され,定義されている。
f) インタフェース要求事項の実現範囲が継続的に監視されている。
g) インタフェース要求事項の達成度が識別され,開発されている。
プロセス,アクティビティ及びタスク :
このプロセスビューは,JIS X 0170の次のプロセス,アクティビティ及びタスクを使用して実施できる。
注記 インタフェース管理についての説明及び詳細は,INCOSEシステムエンジニアリングハンドブ
ックに記載がある。
a) ビジネス又はミッション分析プロセス(6.4.1)は,問題空間の定義,環境及び利用状況の記述,並び
に予備的なシステムレベルの運用概念を含むソリューション空間の特徴付けを提供する。これは,対
象システムとのインタフェースをもたなければならない外部システムを識別することがよくある。関
連するアクティビティ及びタスクには,6.4.1.3のb) 1)及び2)並びにc) 1)を含む。
b) 利害関係者ニーズ及び利害関係者要求事項定義プロセス(6.4.2)は,システムレベルの運用概念の定
義,並びにシステムと利用者及び意図された環境(他のシステムを含む。)との相互作用を定義する。
これは,対象システムとのインタフェースをもたなければならない外部システムを識別することがよ
くある。関連するアクティビティ及びタスクには,6.4.2.3のc) 1)及び2)並びにd) 1)及び3)を含む。
c) システム要求事項定義プロセス(6.4.3)は,インタフェース要求事項の定義を提供する。関連するア
クティビティ及びタスクには,6.4.3.3のa) 1),b)の全タスク,c)の全タスク及びd)の全タスクを含む。
d) アーキテクチャ定義プロセス(6.4.4)は,アーキテクチャモデルが発展するにつれて,アーキテクチ
ャの観点からインタフェースの識別を提供する。このプロセスは,アーキテクチャ記述に必要な範囲
でインタフェースを更に記述し定義する。関連するアクティビティ及びタスクには,6.4.4.3のa) 2)及
び4),c) 1)4),d)の全タスク並びにf) 3)6)を含む。
e) 設計定義プロセス(6.4.5)は,インタフェースの洗練された完全な定義及び必要な情報項目の作成を
提供する。関連するアクティビティ及びタスクには,6.4.5.3のb) 5)及び6)並びにd) 1)3)を含む。
f) システム分析プロセス(6.4.6)は,数学的分析,モデリング,シミュレーション,実験及び他の技法
の実施を通じて,インタフェース要求事項及び定義に関するトレードオフ空間を理解するために必要
な分析のレベルを提供する。分析結果は,他のテクニカルプロセスを支援する意思決定プロセスを通
じて行われるトレード分析への入力となる。関連するアクティビティ及びタスクには,6.4.6.3のa)の
全タスク及びb)の全タスクを含む。
g) 実装プロセス(6.4.7)は,インタフェースの開発,及び実装されたシステム要素に対するインタフェ
ース要求事項が満たされているという証拠の記録を提供する。関連するアクティビティ及びタスクは,
6.4.7.3のb) 3)を含む。
h) インテグレーションプロセス(6.4.8)は,システム要素間のインタフェースに関する考慮事項を含む,
インテグレーションの計画を提供する。また,システム又はシステム要素及びインタフェースの統合
も含まれる。関連するアクティビティ及びタスクには,6.4.8.3のa) 1),b)の全タスク及びc) 1)を含む。
――――― [JIS X 0170 pdf 116] ―――――
114
X 0170 : 2020 (ISO/IEC/IEEE 15288 : 2015)
i) 検証プロセス(6.4.9)は,システムによって提供されるサービスがインタフェース要求事項を含むシ
ステム要求事項を満たすという証拠を提供する。このプロセスは,インタフェースの要求事項を含む
検証を実行する戦略の計画及び実行を提供する。選択された検証戦略は,それらの達成に影響を与え
る可能性のあるインタフェースの制約を導入してもよい。関連するアクティビティ及びタスクは,
6.4.9.3のa) 1)及び3),b) 1)及び2)並びにc) 1)を含む。
j) 移行プロセス(6.4.10)は,システムを運用環境に導入するためのものである。これには,制約の識別,
インタフェースの導入及び動作状態の確認が含まれる。関連するアクティビティ及びタスクは,
6.4.10.3のa) 4)並びにb) 3),4),6)及び7)を含む。
k) 妥当性確認プロセス(6.4.11)は,システムによって提供されるサービスが,インタフェース要求事項
を含む利害関係者のニーズを満たすという証拠を提供する。選択された検証戦略は,その成果に影響
を与える可能性のあるインタフェース制約を導入してもよい。関連するアクティビティ及びタスクは,
6.4.11.3のa) 1),2)及び3),b) 1)及び2)並びにc) 1)及び2)を含む。
l) 運用プロセス(6.4.12)は,システムの使用方法を提供する。また,操作のためのインタフェースに制
約がある場合がある。インタフェース要求事項が適切に達成されることを保証するには,システムの
動作を監視する必要がある。関連するアクティビティ及びタスクは,6.4.12.3のa) 2),b) 3)及び4)並
びにc) 1)及び2)を含む。
m) 保守プロセス(6.4.13)は,システムの機能を維持し,インタフェースを含む機能を提供する継続的な
アベイラビリティを確保するのに役立つ。これには,システムの継続的な運用を保証するために必要
な障害分析,保守タスク,及びロジスティクスのタスクが含まれる。また,保守のためにインタフェ
ースに制約がある場合がある。関連するアクティビティ及びタスクは,6.4.13.3のa) 2),b)の全タス
ク並びにd) 1)及び2)を含む。
n) 廃棄プロセス(6.4.14)は,システムの存在を終了させる。インタフェースを解除するためのアクティ
ビティが必要な場合がある。廃棄を予定する固有の必要性は,インタフェースに制約を課す場合があ
る。関連するアクティビティ及びタスクは,6.4.14.3のa) 2)並びにb) 1)及び2)を含む。
o) プロジェクトアセスメント及び制御プロセス(6.3.2)は,インタフェースを含む要求事項の達成度を
監視し,その結果を利害関係者及び意思決定者に伝えるためのものである。関連するアクティビティ
及びタスクは,6.3.2.3のb) 6),7),9)及び10)を含む。
p) 意思決定管理プロセス(6.3.3)は,インタフェースを含む決定基準に対する選択肢となる代替要求事
項,アーキテクチャ特性及び設計特性をアセスメントすることを提供する。これらの比較の結果は,
適切な選択モデルを介してランク付けされ,次いで,最適なソリューションを決定するために使用さ
れる。関連するアクティビティ及びタスクは,6.3.3.3のb)の全タスク及びc) 1)を含む。
q) リスク管理プロセス(6.3.4)は,全体として,インタフェースに関連するものを含め,システムのリ
スクの識別,評価及び対処を提供する。
r) 情報管理プロセス(6.3.6)は,全体として,達成度を文書化し,伝達するための情報項目の仕様,開
発及び維持を規定する。
s) 測定プロセス(6.3.7)は,要求されたインタフェースの情報ニーズに測定量を関連付け,識別された
インタフェース情報ニーズに取り組むためにこれらの測定量を生成し,使用する方法を定義する。
t) 品質保証プロセス(6.3.8)は,識別された,インタフェース要求事項の達成に関連する不具合(イン
シデント及び問題)を取り扱う。
――――― [JIS X 0170 pdf 117] ―――――
115
X 0170 : 2020 (ISO/IEC/IEEE 15288 : 2015)
附属書F
(参考)
アーキテクチャのモデル化
F.1
序文
この附属書は,この規格のアーキテクチャ定義及び設計定義プロセスに関して,旧規格のJIS X
0170:2013(ISO/IEC/IEEE 15288:2008)のアーキテクチャ設計プロセスとの関連についての情報を提供す
るものである。
この規格におけるアーキテクチャ及び設計のアクティビティは,複雑なシステムを扱うシステムエンジ
ニアリングのコミュニティにおける異なる実践方法を反映し,二つのプロセスに分割される。一つの例と
して,一つのアーキテクチャから,プロダクトラインにおいては,異なるシステムのための異なる設計へ
と続くこともある。この場合は,これらアーキテクチャ定義及び設計という二つのプロセスを区別された
方法で実施することが重要である。さらに,アーキテクチャはしばしば設計の基礎というより,もっと別
の理由から実施されることがある。例えば,技術面での投資を推進する,複数のプロジェクトを集約した
ポートフォリオを調整する,入札する又は入札しない決定を手引きする,などである。
システムのアーキテクチャは,機能,機能フロー,インタフェース,資源フロー項目,情報・データ要
素,物理的なコンポーネント,コンテナ,ノード,リンク,通信資源などの,構造化された実体要素であ
るアーキテクチャ エンティティ及びそれらの関係の集合として理解することができる。これらのアーキテ
クチャ エンティティは,次元,環境の復元性,アベイラビリティ,堅ろう(牢)性,実行効率,ミッショ
ンに対する有効性などの特性をもち得る。
F.2 アーキテクチャで利用されるビューポイント,ビュー及びモデル種類
アーキテクチャ定義プロセスでは,F.3に列挙するモデルの例を含む様々なモデルを利用する(伝統的
なシステムエンジニアリングの実践では,それらのモデルを“論理モデル”,“物理モデル”などと分類す
るが,この規格の適用においては,分類学的な区別は不要である。)。
ビューの多様性は,システムのアーキテクチャがいかに利害関係者のシステムについての関心事を扱う
かを表現するために利用される。ビューはモデルによって構成される。アーキテクチャに関する用語,並
びにより詳細なアーキテクチャに関する概念及びモデルの定義は,ISO/IEC/IEEE 42010を参照。
F.3 論理モデル及び物理モデル
F.3.1 機能モデル
システムの機能モデル(Functional model)は,そのミッション又は目的を達成するためにシステムによ
って実行される入力から出力への変換を定義する機能の集合を表現したものである。これらの機能は,シ
ステムが利用されたときに,どのように振る舞うことが意図に合うものとして期待されているかによって
決定される。結果として,全てのシステムの機能は,システム及びその環境の間の相互作用に対応付けら
れる。機能要求事項,実行性能要求事項,非機能要求事項,及び制約に関する要求事項が,通常,機能及
び入力から出力への流れを決定するために分析される。機能がシステム要素と対応付けられるとき,設計
定義プロセスは,それぞれのシステム要素が,それを構築する又は購入するために,十分に規定されてい
るかを決定するために必要になる。システム要素がこの十分性の達成のために更に分析が必要ならば,そ
――――― [JIS X 0170 pdf 118] ―――――
116
X 0170 : 2020 (ISO/IEC/IEEE 15288 : 2015)
のシステム要素に関連付けられている機能についても,更なる分析,及び厳密な部分要素への対応付けが
必要となる。典型的には,複数のアーキテクチャの候補の定義に貢献するような機能の分解は,複数の方
法が存在する。
F.3.2 振る舞いモデル
システムの振る舞いモデル(Behavioral model)は,順次実行及び並行実行,振る舞いが変化する条件,
並びにシステムの遂行能力・性能・運用時の実績を含む運用シナリオを維持するための条件下で,システ
ム又はその要素がどのように振る舞うかを定義する,機能及びインタフェース(内部及び外部)の取決め
である。振る舞いモデルは,シナリオ間の関係の集合によって記述することができる。これは,ライフサ
イクルを通じた振る舞いの要素(モード又は状態,遷移,発動イベント,運用シナリオなど)を識別する
ことを含む。
F.3.3 時相モデル
システムの時相モデル(Temporal model)は,機能の実行頻度のレベル(戦略レベル,戦術レベル,運
用監視レベル,統制レベルなど)を示すシステム又はその要素において,時間が振る舞いの中でいかに考
慮に入れられているかを表す表現である。ここで,機能の実行レベルは,人及びプログラムの論理がシス
テムの運用を監視及び制御することを決定するレベルに対応する。これは,システムレベルの運用概念及
びシステム要求事項から,時相的要素(期間,頻度,応答時間,トリガー,タイムアウト,停止条件など)
を識別することを含む。
F.3.4 構造モデル
システムの構造モデル(Structural model)は,他の要素との関係についての要素の配置,並びに要素間
及び外部実体とのインタフェースを必要に応じて示す表現である。そのようなモデルは,システム階層の
あるレベルにおける,及びシステム階層のレベル間におけるシステム要素間の物理的インタフェースを明
確化又は識別することができる。外部実体から当該システム(その環境及び利用状況において)への物理
インタフェースについても同様である。
F.3.5 質点モデル
システムの質点モデル(Mass model)は,システム要素の物理体積,又はそれらが地理的に分散してい
る場合には,それらの部分の位置を示す表現である。システムの質点モデルは,重心及び運動の動的な振
る舞いなどの質点の性質の決定を支援するために,期待する質点の性質又は実際の性質を記録することが
できる。システムの質点モデルは,また,システムの総質量をその要素に割り当てることを支援するため
にも利用することができる。
F.3.6 レイアウトモデル
システムのレイアウトモデル(Layout model)は,システム要素が他のシステム要素に対して地理的に
どこに配置されているかを表現するものである。鉄道のモデルにおいては,レイアウトモデルは運行する
列車のための縮尺線路を含むジオラマである。自動車レイアウトは,エンジン及び駆動輪が車両上のどこ
にあるかを記述する。
F.3.7 ネットワークモデル
システムのネットワークモデル(Network model)は,資源が一つのノードから他のノードへどのように
移動するかを理解することを助けるための,ノード及びリンクの配置を定義する。ネットワークモデルは,
スループット,待ち時間,ふくそう(輻輳)点などを決定するために使用できる。ネットワークモデルは,
ネットワーク内の階層がいかに上位及び下位のスタックと垂直に相互作用するかを理解するために,しば
しばプロトコルスタックとともにモデル化される。
――――― [JIS X 0170 pdf 119] ―――――
117
X 0170 : 2020 (ISO/IEC/IEEE 15288 : 2015)
F.3.8 他のモデルの考慮すべき事柄
保守,発展,廃棄,潜在的な環境の変化,又は陳腐化管理,及び非機能要求事項といった利害関係者の
ライフサイクルに関する関心事は,モジュール性,相対的な独立性,アップグレード可能性,複数の環境
への適合,有効性のレベル,信頼性,堅ろう(牢)性(robustness),拡張可能性(scalability),環境条件に
対する抵抗などといったアーキテクチャ特性を定義することによって扱われる。
他の必要なモデルは,これらの特性又は他の重大な品質特性の幾つかを含み得る。例えば,信頼性モデ
ルは,重大な関心事及び機能に関連する運用上のリスク(ミッションの損失,安全性又はセキュリティ)
の最小化を目的とする潜在的なアーキテクチャによる緩和の導出を支援するため,故障モード及び影響解
析(FMEA又はFMECA)の機能レベルを決めることができる。
システム定義において,どのモデルを使うかを決定することは,利害関係者の関心事の検討に基づくこ
とができる。モデル及び得られたビューは,システムアーキテクチャ及び設計が,利害関係者らの関心事
を扱うかを表現するための方法,並びに利害関係者らの実際の必要性,欲求及び期待のより良い理解を得
るための方法として利用することができる。
さらに,モデルは,アーキテクチャ定義及び設計定義プロセス以外のライフサイクルプロセスにおいて
も利用できることがある。モデルに基づくシステムエンジニアリング(MBSE,Model-Based Systems
Engineering)は,ライフサイクルにおけるシステム要求事項,アーキテクチャ,設計,分析,検証,及び
妥当性確認に関する作業を支援するための,形式性を高めたモデル化の系統的な適用である。
――――― [JIS X 0170 pdf 120] ―――――
次のページ PDF 121
JIS X 0170:2020の引用国際規格 ISO 一覧
- ISO/IEC/IEEE 15288:2015(IDT)