68
X 0170 : 2020 (ISO/IEC/IEEE 15288 : 2015)
識別を支援する。プロセスが進むにつれ,システムに対して指定された要求事項と,システ
ム要素間の相互作用及び関係から生じて,システムに発現する特性である創発性(emergent
properties)及びシステムの振る舞いとの間の関係について洞察が得られる。
一方,設計定義プロセス(6.4.5)は,アーキテクチャ及び実現可能性についてのより詳細
な分析によって入念に精査された要求事項によって駆動される。アーキテクチャは,システ
ムの目的に適合できる特性,実行可能性,及び望ましさの特性に焦点を当て,一方で設計は,
技術及び他の設計要素との互換性,並びに構築及びインテグレーションの実現可能性に焦点
を当てている。効果的なアーキテクチャは,可能な限り設計にとらわれることなく,設計ト
レードオフ空間の中で最大限の柔軟性をもったものである。
効果的なアーキテクチャは,また,設計定義プロセスに対して,トレードオフの所在を強
調し,支援する。ほかにもポートフォリオ管理,プロジェクト計画,システム要求事項定義,
検証などのプロセスに対して,同様にトレードオフの所在を示す可能性がある。
注記3 プロダクトラインアーキテクチャでは,アーキテクチャは幾つかの設計にまたがっている必
要がある。アーキテクチャはプロダクトラインをまとまりのあるものにし,プロダクトライ
ンにわたって互換性及び相互運用性を確実なものにすることを支援する。一つの製品のシス
テムに対しても,アーキテクチャが一定で変わらない一方で,時間の経過とともに製品の設
計が変化する可能性がある。
6.4.4.2 成果
アーキテクチャ定義プロセスの実施に成功すると次の状態になる。
a) 識別された利害関係者の関心事がアーキテクチャで取り組まれている。
b) アーキテクチャ ビューポイントが作成されている。
c) システムが利用される状況,境界及び外部インタフェースが定義されている。
d) システムのアーキテクチャ ビュー及びモデルが作成されている。
e) システムのアーキテクチャの決定に重要な概念,性質,特性,振る舞い,機能又は制約が,アーキテ
クチャの要素となる実体(architectural entities,以下,アーキテクチャ エンティティという。)に割り
当てられている。
f) システム要素及びシステム要素間のインタフェースが識別されている。
g) アーキテクチャ候補のアセスメントが行われている。
h) ライフサイクル全体にわたるプロセスに対するアーキテクチャの基礎の構築が達成されている。
i) アーキテクチャの,要求事項と設計特性との整合が達成されている。
j) アーキテクチャ定義の実施を可能にするために必要な全てのイネーブリングシステム又はサービスが
利用可能になっている。
k) アーキテクチャ要素と,利害関係者要求事項及びシステム要求事項との間のトレーサビリティが構築
されている。
6.4.4.3 アクティビティ及びタスク
プロジェクトは,アーキテクチャ定義プロセスに関する,適用可能な組織の方針及び手順に従って,次
に示すアクティビティ及びタスクを実施しなければならない。
a) アーキテクチャ定義の準備を行う。このアクティビティは,次のタスクからなる。
1) システムの核心に関する情報をレビューし,アーキテクチャを駆動する重要な事項を識別する。
注記 次に示す,アーキテクチャ定義を駆動する重要事項をレビューによって識別する。
――――― [JIS X 0170 pdf 71] ―――――
69
X 0170 : 2020 (ISO/IEC/IEEE 15288 : 2015)
− 市場調査,産業予測,競合製品計画,及び科学的発見
− 組織の戦略,組織レベルの運用概念,組織の方針及び指示,規制及び法令による制約,
並びに利害関係者要求事項
− ミッション又はビジネスの組織レベルの運用概念,システムレベルの運用概念,運用
環境,技術ロードマップ,及びシステム要求事項
− ライフサイクル全体を通じてシステムの目的への適合性に影響を与える他の要因
2) 利害関係者の関心事を識別する。
注記 利害関係者は,利害関係者ニーズ及び利害関係者要求事項定義プロセスで最初に識別され,
通常は,アーキテクチャ定義プロセスを実施する間に追加の利害関係者が識別される。ア
ーキテクチャに関連する利害関係者の関心事には,次のようなシステムのライフサイクル
に関係する期待及び制約がある。
− 利用(例えば,アベイラビリティ,セキュリティ,有効性,使用性),運用・保守の支
援(例えば,修復性,陳腐化の管理)
− システム及び環境の発展的な開発(例えば,適応性,拡張性,生存性)
− 生産(例えば,生産可能性・製造性,テスト容易性),廃棄(例えば,環境への影響,
輸送性)など。
これには,意図の有無に関係なく,脅威を与え得る者によって,又は安全性を脅かすハ
ザードによって偶発的に,システムが侵害される懸念についての関心事も含まれる。
3) アーキテクチャ定義ロードマップ,取組方法及び戦略を定義する。
注記 これには,利害関係者が参加して合意する機会の識別,アーキテクチャのレビューをする
アクティビティの定義,評価の取組方法及び評価基準の定義,測定の取組方法,並びに測
定手法(測定プロセスを参照)を含める。ロードマップでは,アーキテクチャをどのよう
に目指す最終の状態へと発展させるのかを示す。このため,その時点での当面の対象シス
テムに対する時間枠よりも,更に長い時間枠をもつことがよくある。取組方法は,利害関
係者と共同作業して合意する方法,結果の入念な精査方法,作業を行う場所など,作業を
達成するための方法である。戦略は,ロードマップとの一貫性をもった取組方法を実施す
るための系統的な行動計画を扱う。
4) 利害関係者の関心事及び重要な要求事項に基づく評価指標を定義する。
5) アーキテクチャ定義プロセスを支援するために必要なイネーブリングシステム又はサービスを識別
し計画する。
注記 これには,アーキテクチャ定義を有効なものにするよう支援するイネーブリングシステム
のための要求事項及びインタフェースの識別を含む。アーキテクチャ定義のためのイネー
ブリングシステムは,共同作業及びアーキテクチャを開発するためのツール及びアーキテ
クチャの再利用リポジトリ(アーキテクチャ パターン,アーキテクチャ成果物,参照アー
キテクチャなどのためのもの)を含む。
6) 利用されるイネーブリングシステム若しくはサービスを,獲得する又はそれらへのアクセスを取得
する。
注記 アーキテクチャ定義の実現を支援するイネーブリングシステムの支援機能が,意図された
ように利用できるかを客観的に確認するために,妥当性確認プロセスが用いられる。
b) アーキテクチャ ビューポイントを開発する。このアクティビティは,次のタスクからなる。
――――― [JIS X 0170 pdf 72] ―――――
70
X 0170 : 2020 (ISO/IEC/IEEE 15288 : 2015)
1) 利害関係者の関心事に基づくビューポイント及びモデルの種別を選定するか,適応させるか,又は
策定する。
2) モデル及びビューを策定するために用いられる可能性のあるアーキテクチャ フレームワークを確
立又は識別する。
注記 幾つかのアーキテクチャ フレームワークは,利害関係者及びそれらの関心事,並びにそれ
らの関心事を取り上げた関心事に関連するビューポイントを識別する。一方で,他のアー
キテクチャ フレームワークは,より一般的な手引となる。ビューポイントは,用いられる
モデルの種別を規定し,結果として得られるモデルを用いてアーキテクチャ ビューを作り
出すための方法を規定する。アーキテクチャ フレームワーク及びアーキテクチャ記述の実
践に関する詳細情報については,ISO/IEC/IEEE 42010を参照。
3) フレームワーク,ビューポイント及びモデル種別の選定の根拠を捕捉して形あるものに記録する。
4) モデルの策定を支援する技法及びツールを選定又は開発する。
c) 候補となるアーキテクチャのモデル及びビューを策定する。このアクティビティは,次のタスクから
なる。
1) システム外部エンティティとのインタフェース及び相互作用によって,システムが利用される状況
及びシステムの境界を定義する。
注記1 このタスクは主にビジネス又はミッション分析プロセスの成果に基づいて実施し,利害
関係者ニーズ及び利害関係者要求事項定義プロセスと同時並行させて遂行する。タスク
は,システム外部エンティティ(システムが利用される状況を構成する,既存及び将来
に存在することが予測されるシステム,製品及びサービス)を識別し,システムの境界
(境界を横切るインタフェースを通じて行う,これらのシステム外部エンティティとの
相互作用)を定義することからなる。システム外部エンティティには,必要となるイネ
ーブリングシステムを含められる。アーキテクチャ定義プロセスは,重要なアーキテク
チャの決定及び理解を支援するために必要な範囲に対してインタフェースを定義する。
さらに,これらのインタフェース定義は,設計定義プロセスによって詳細化される。
注記2 システム外部エンティティ(external entities, entities external to the system)とは,対象シ
ステムの外部に存在する複数の実体で,対象システムの外部を構成する要素であり,対
象システムと相互作用する。対象システムの外部に現時点で存在しているか,又は将来
には存在する可能性があると判断されるシステム,製品及びサービスを指す。
2) 重要な利害関係者の関心事及び重大なシステム要求事項を取り扱うアーキテクチャ エンティティ
及びそれらのエンティティ間の関係を識別する。
注記 アーキテクチャは必ずしも全ての要求事項に関係するのではなく,アーキテクチャを駆動
する要求事項と関係する。逆に,設計定義プロセスは全ての要求事項を考慮する。場合に
よっては,アーキテクチャ定義プロセスを通して,不適切か,費用面で引き合わないか,
又はシステムの目的に適合するものではないとみなされる要求事項があるが,それらはシ
ステム要求事項定義プロセスの反復を通して解決する要求事項の課題となる。重要な利害
関係者の関心事の全てが,要求事項として捕捉されて形あるものに記録されるとは限らな
いため,アーキテクチャが重要な利害関係者の関心事を取り扱うことも重要である。
3) システムのアーキテクチャの決定に重要な概念,性質,特性,振る舞い,機能又は制約を,アーキ
テクチャ エンティティへ割り当てる。
――――― [JIS X 0170 pdf 73] ―――――
71
X 0170 : 2020 (ISO/IEC/IEEE 15288 : 2015)
注記 割り当てられる項目は,物理的,論理的又は概念的なものである場合もある。
4) 候補となるシステムのアーキテクチャを選定するか,適応させるか又は開発する。
注記 一般的にはアーキテクチャ定義でモデルを用いる。用いられるモデルは利害関係者の関心
事を取り扱うのに最も適したモデルにする。どのように行うかはISO/IEC/IEEE 42010に
記載がある。アーキテクチャ定義の中で論理モデル及び物理モデルを用いることが,これ
まで一般的である。論理モデル,物理モデル及びその他のモデルに関する情報は附属書F
に記載している。
5) アーキテクチャがどのように利害関係者の関心事を取り上げ,利害関係者及びシステム要求事項に
合致するかを表すため,識別したビューポイントに従ってモデルからビューを構成する。
6) アーキテクチャ モデルとアーキテクチャ ビューとを互いに調和させる。
注記 アーキテクチャ フレームワークからの対応規則は,ビュー間の調和を確立する一つの方法
である。ISO/IEC/IEEE 42010を参照。
d) アーキテクチャを設計に関係付ける。このアクティビティは,次のタスクからなる。
1) アーキテクチャ エンティティ及びそれらのエンティティ間の関係がもつ性質に関わる,システム要
素を識別する。
注記 システム要素は,実際に行われる設計に依存するため,設計定義を行うまで,当初は概念
的であることがよくある。アーキテクチャの意図を伝え,設計の実現可能性をチェックす
る方法として,概念的なシステム要素を用いて“参照アーキテクチャ”を作ることがよく
ある。
2) システム要素とシステム外部エンティティとの間のインタフェース及び相互作用を定義する。
注記 これはアーキテクチャの意図を伝えるのに必要な詳細度で定義され,設計定義プロセスで
更に詳細化される。
3) アーキテクチャ エンティティ及びシステム要素に対して要求事項を分割し,互いに整合するように
して,割り当てる。
4) システム要素及びアーキテクチャ エンティティと設計特性とを対応付ける。
5) システムの設計及び発展に対する原則を定義する。
e) アーキテクチャ候補のアセスメントを行う。このアクティビティは,次のタスクからなる。
1) 各アーキテクチャ候補を,制約及び要求事項に対してアセスメントする。
2) 評価基準を用いて,各アーキテクチャ候補を,利害関係者の関心事に対してアセスメントする。
注記 このタスクを支援するため,システム分析プロセス及びリスク管理プロセスが用いられる。
3) 好ましいアーキテクチャを選定し,重要な決定及び根拠を捕捉して形あるものとして記録する。
注記 このタスクを支援するため,意思決定管理プロセスが用いられる。
4) 選定されたアーキテクチャのアーキテクチャ ベースラインを確立する。
注記 アーキテクチャ ベースラインは,モデル,ビュー,及び他の関係するアーキテクチャ記述
からなる。
f) 選定されたアーキテクチャを管理する。このアクティビティは,次のタスクからなる。
1) アーキテクチャを統括する取組方法を正式なものとし,統括に関係する役割及び責任,説明責任,
並びに権限(設計,品質,セキュリティ,安全などに関係する。)を規定する。
2) アーキテクチャについての利害関係者による明示的な受入れを獲得する。
注記1 アーキテクチャ モデル及びビューが,利害関係者及びシステム要求事項を反映している
――――― [JIS X 0170 pdf 74] ―――――
72
X 0170 : 2020 (ISO/IEC/IEEE 15288 : 2015)
ことを確認するために,検証及び妥当性確認プロセスが用いられる。
注記2 アーキテクチャを認証することが必要となるシステムの応用分野がある。認証で確認す
ることは,アーキテクチャの意図に合致し,アーキテクチャがもつ展望及び重要な概念
が正しく実装され,利害関係者の関心事が正しく取り扱われていることである。また,
学習するプロセスを支援し,アーキテクチャを将来にわたって反復して設計することで,
利害関係者の関心事をより確実に取り扱ったアーキテクチャにすることを支援するため,
アーキテクチャ定義プロセスにとって重要なフィードバックを提供する。
3) アーキテクチャ エンティティ及びそれらのアーキテクチャ特性の調和性及び完全性を維持する。
注記 チェックするべきアーキテクチャ エンティティは技術面だけではない。例えば,通常では
利害関係者の要求事項及び関心事の一部として,法律面,経済面,組織面及び運用面のア
ーキテクチャ エンティティもある。
4) アーキテクチャ モデル及びビューの発展を体系化し,アセスメントし,制御する。
5) アーキテクチャ定義及び評価戦略を保守する。
注記 これには,システムを分解したレベルで定義される外部及び内部インタフェースの管理と
ともに,技術面,実装面及び運用面の経験に基づくアーキテクチャの更新を含む。
6) アーキテクチャのトレーサビリティを維持する。
注記 ライフサイクルを通じて,要求事項(割り当てられ,分解され,導出された要求事項を含
む。),インタフェース定義,分析結果,及び検証の手法又は技法に対し,アーキテクチャ エ
ンティティ(モデル,ビュー及びビューポイント)との間で,双方向のトレーサビリティ
を維持する。可能ならば,トレーサビリティは,アーキテクチャ エンティティと利害関係
者の関心事との間でも維持される。
7) ベースラインに対して選定された重要な情報項目を提供する。
注記 構成管理プロセスは,構成品目及びベースラインを確立し維持するために用いられる。こ
のプロセス(アーキテクチャ定義)は,このベースラインに対してアーキテクチャ候補を
識別し,そしてその情報項目をCMへ提供する。
6.4.5 設計定義プロセス(Design Definition process)
6.4.5.1 目的
設計定義プロセスは,システムアーキテクチャのモデル及びビューで定義されるアーキテクチャ エンテ
ィティとの一貫性をもった実装を可能にするために,システム及びその構成要素に関する十分に詳細なデ
ータ及び情報を提供することを目的とする。
注記1 アーキテクチャ定義プロセスでは,利害関係者の識別及び利害関係者の関心事の識別を支援
する。アーキテクチャ プロセスを用いることで,システムに対して指定された要求事項と,
システム要素間の相互作用及び関係から生じて,システムに発現する特性である創発性及び
システムの振る舞いとの関係についての洞察が得られる。一方,設計定義プロセスは,アー
キテクチャ及び実現可能性についてのより詳細な分析によって入念に精査された要求事項に
よって駆動される。アーキテクチャでは,システムの目的に適合できる特性,実行可能性,
及び望ましさの特性に焦点を当て,設計は,技術及び他の設計要素との互換性,並びに構築
及びインテグレーションの実現可能性に焦点を当てる。設計トレードオフ空間の中で最大限
の柔軟性を備え,可能な限り設計にとらわれないアーキテクチャが有効なアーキテクチャで
ある。
――――― [JIS X 0170 pdf 75] ―――――
次のページ PDF 76
JIS X 0170:2020の引用国際規格 ISO 一覧
- ISO/IEC/IEEE 15288:2015(IDT)