システムライフサイクルプロセス説明（案）iso/iec/ieee 15288:2015及びiso/iec...

© 2017 IPA Software Reliability Enhancement Center

2017年10月12日

独立行政法人情報処理推進機構（IPA）

技術本部ソフトウェア高信頼化センター（SEC）

本プレゼンテーションパッケージは、日本規格協会の許可を得て、ISO/IEC/IEEE 15288:2015及びISO/IEC 24748-2のDIS版の抄訳を引用・転載しています。

システムライフサイクルプロセス説明（案）

システムズエンジニアリング推進WG 参考2(17-SEWG-2）

2© 2017 IPA Software Reliability Enhancement Center

トピックス

目次

1. ISO/IEC/IEEE 15288:2015システムライフサイクルプロセス概念と用語概要・・・・・・・・・・・・ 3

2. ISO/IEC/IEEE 15288:2015システムライフサイクル概念紹介・・・・・・・・・・・･･･････・･･･・・・ 6

3. ISO/IEC 24748-2 ISO/IEC/IEEE 15288適用へのガイドライン・・・・・・・・・・・・・・・・・・・・・・ 11

4. システムライフサイクルのどのプロセスが有効か？・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 18

5. ISO/IEC/IEEE 15288:2015の早期開発ステージ関連技術プロセス・・・・・・・・・・・・・・・・・・・ 21

本資料は、システムズエンジニアリングの実践のためのISO/IEC/IEEE１５２８８システムライフサイクルプロセスとその適用に関わるガイドラインISO/IEC 24748-2に基づき作成したものである。


1. ISO/IEC/IEEE 15288:2015システムライフサイクルプロセス

概念と用語概要

システムライフサイクルプロセス概念のコンテキストシステム概念

組織とプロジェクト概念

ライフサイクル概念

プロセス概念

用語概要


システムライフサイクルプロセス概念のコンテキスト

ISO/IEC/IEEE 15288:2015は、以下のコンテキストからなる。（用語は次頁）

システム概念組織がISO/IEC/IEEE 15288をシステムのライフサイクルに適用する時に、そのシステムをSoI（System of

Interests）という。

組織とプロジェクト概念プロジェクトでは、複数の組織及び人が協働することがある

プロジェクトは、要求される仕事のために、複数の要素（ハードウェア、ソフトウェア、人、プロセス、手順、設備、等）を使用する

ライフサイクル概念 SoI（System of Interests）は、ライフサイクルにより実現され、ライフサイクルは以下のステージからなる。

ステージ：概念、開発、製造、活用、支援、運用、廃止

順次のみに実施されるものではなく、全てが実施されるものでもなく、イテラティブにも再帰的にも実施される。

プロセス概念組織がプロジェクトを実施する時に、相互に関係・影響するあるまとまりで活動する。


用語概要

SEVOCABによる主要用語の説明,

https://pascal.computer.org/sev_display/index.action システム

一つあるいはそれ以上の意図された目的を達成するために構造化された相互に関係する要素の組み合わせられたもの

ライフサイクル

システム、製品、サービスあるいは他の人により作られるものの概念形成から使用停止までの進化

SoI（System of Interests）

ライフサイクルで対象として考慮しているシステム

ステークホールダーシステムが達成することに関心ある組織及び個人

プロセス

入力を出力に変換する活動で相互に関係するか影響しあうまとまり

イテラティブ

複数のプロセスにおいて、活動が繰り返すサイクルでなされること

再帰的

一つのプロセスにおいて、その中である活動がなされること

https://pascal.computer.org/sev_display/index.action


2. ISO/IEC/IEEE 15288:2015システムライフサイクルプロセス

概念紹介

システム概念



プロセス概念


システム概念

システムズ

当規格で考慮するシステムズとは、ユーザー及び他のステークホールダーの便益のために定義された環境で提供される製品あるいはサービスのための人工物で、創造され、活用されるもの。

システムズは、次の一つあるいはそれ以上のシステム要素からなる：ハードウェア、ソフトウェア、データ、人、プロセス、手順、施設、材料、自然に発生する要素

ある一つのシステム、そのアーキテクチャ、そして、そのシステム要素に対する認識と定義は、ステークホールダーの関心と責任に依存する。

あるステークホールダーの関心あるシステム（SoI, System of Interests）は、他のステークホールダーの関心あるシステムにおけるシステム要素と認識されることがある。

さらに、関心あるシステムは、他のステークホールダーの関心あるシステムの環境要素でもある。

システム構造

システムは、相互に関係するシステム要素から構成される。

システムとその要素の関係は、典型的には階層構造で示される。

現実的には、階層構造ではなく、ネットワークあるいは他の分散構造のシステムがある。

イネーブリングシステム

イネーブリングシステムは、関心あるシステムのライフサイクルを通した運用環境には直接関係しないが、その本質的なサービスには必要なもの、例：大量生産システム、訓練システム、保守システム、等。関心あるシステムのライフサイクルを通した進捗を促進する作用をすることから、イネーブリングシステムと呼称される。

システムライフサイクルを通して、適切なイネーブリングシステムと関心あるシステムは協働する。



組織組織は以下からなる。

パーティ：合意形成に当たって関与する組織全体あるいは部分は、パーティと称される。

パーティは同一の組織からかもしれないし、他の組織からかもしれない。

もし責任と権限が１個人に付与されるなら、パーティは１人のこともある。

ユーザー：製品あるいはサービスの活用により便益を受ける組織

顧客：ユーザーと発注者の総称

ステークホールダー：システムに関心を持つ組織あるいは個人

プロセスの実行において責任ある組織名としてプロセス名が使用されることがある。

例：購買、サプライヤー、実装者、保守者、運用者。

プロセスと組織は単に機能上関係するのみで、どのプロセスがどの組織でなされなければならないとはしない。

本規格におけるプロセスは、多様な組織の要求に包括的に対応するが、組織のビジネス上、あるいは購買戦略により、適切なプロセスを選択する。

プロセスの組織とプロジェクトレベルの適用現代的なビジネスにおいては、ビジネス上のプロジェクトに対してプロセスを繰り返し適用する努力がなされている。

プロセスを持っていない組織においてプロジェクトがなされる場合、本規格を使用することがある。



システムライフサイクルモデルすべてのシステムは、ライフサイクルを持つ。

ライフサイクルは、その機能上、システムニーズの概念化から廃棄までを分割して示される。

システムは、ライフサイクルを通して、組織内要員によるプロセスの実行により進化する。

プロセスの実行順番は、プロジェクトの目的と選択したライフサイクルモデルによる。

ライフサイクルモデルは、以下から記述される。

プロセス、成果、プロセス間関係、順序

本規格は、特定のライフサイクルモデルを規定するものではなく、プロセスの集合を定義し、実行順番は規定しない。

システムライフサイクルステージライフサイクルは、システムの性格、目的、使用環境により多様である。

各ステージは、明確な目的を持ち、ライフサイクル全体への寄与によりシステムライフサイクルの計画時に決められる。

ステージは、システムのライフサイクル上の期間を示すと共に、進捗の達成のマイルストーンでもある。これにより、ライフサイクルの決定ゲートを提供する。

システムライフサイクルステージの典型なものは、以下のようなものである。

概念、開発、製造、活用、支援、廃棄


プロセス概念

プロセスの基準

ライフサイクルプロセスの決定基準は以下の通り：プロセスは、その成果、アクティビティ、タスクと強い関係にある

プロセス間の依存性は、極力なくされている

プロセスの実行は、組織でなされる

プロセスの記述

プロセスは以下の属性で記述されるタイトル: スコープを示す

目的: プロセス実行のゴールを示す

成果: プロセスの成功裏の実行において観察できる結果

アクティビティ：プロセスのタスクの集合

タスク：成果を得るために実行されるアクション

テーラーリング

テーラーリングプロセスは、１５２８８国際規格の付属文書Aで定義されている。


3．ISO/IEC 24748-2 ISO/IEC/IEEE 15288適用への

ガイドライン

適用戦略

システム概念の適用

組織概念の適用

プロジェクト概念の適用

ライフサイクル概念の適用

プロセス概念の適用


適用戦略

ISO/IEC/IEEE 15288:2015は以下のごとき理由により適用される。プロジェクトに適用するプロセス、アクティビティ及びタスクを定義する

組織における複数のプロジェクトでプロセス改善を図る

よりおおきな組織上のプロセス（例：購買システム、保守システム）の中のシステムライフサイクル適用におけるガイダンスを提供する


システム概念の適用

当適用に関連するISO/IEC/IEEE 15288プロセスビジネスあるいはミッションの解析

ステークホールダーニーズと要求の明確化

システム要求の明確化

アーキテクチャの明確化

設計

システム解析

目的システム、境界、ユーザーと他のステークホールダーの認識が必要か理解する

上記理解をニーズと要求の記述に変換し、ステークホールダーの要求を満足させるシステムの要求に変換する

システムの要求を実際のシステムとしてどのように実現するか理解する

更に、システムの要素、それらの間の関係（アーキテクチャ）を理解した上で、システムの内部構造の仕様を作成する。（設計）

留意点最初の段階では、システムのアーキテクチャあるいは設計を考えない

システムライフサイクルを通して関係するステークホールダーを特定し、チームに関与させる

このプロセスにおいては、繰り返しが多発することを十分認識する


組織概念の適用

概要

組織は、システムの開発者であるとともに使用者でもある。組織によりISO/IEC/IEEE 15288が適用されるのは、種々の局面がある。

例：購入時、使用時、システムの任意の構造レベル等で組織が関与するとき。

ISO/IEC/IEEE 15288が社内的にあるいは社外と契約に基づく仕事に用いられる場合、契約の概念がタスクレベルで成立。

既に社内的に標準が存在している場合、ISO/IEC/IEEE 15288とハーモナイズさせることが重要である。

考慮事項

ISO/IEC/IEEE 15288は、プロセス能力度判定の規約を活用し、システム関連プロセスの改善に用いられる。

システムライフサイクルプロセスの導入理由

組織において、ISO/IEC/IEEE 15288が導入される理由には以下のものがある。

社内開発の開発方法の徹底性を検証する

新しいマーケットに進出するに従いリスクを回避するために厳密さが要求される場合に既存の方法論を活用する

新組織のために新しい方法論の採用を管理する。

新技術を使い始める時の管理手法

入札の評価をする一部として活用

プロセス改善の手法のベンチマーキング

経営層のコミットメント

実際に変化をもたらすどんな方法と同様に経営層のコミットメントが必要。


プロジェクト概念の適用

ISO/IEC/IEEE 15288は、以下の理由でプロジェクトレベルで活用できる。

合意プロセス：社内外を問わず関係者間で合意を得られるようにする

組織的プロジェクトイネーブリングプロセス：製品あるいはサービスの購入あるいは提供に当たって、組織がプロジェクトの開始、支援、あるいは管理の能力を持っていることを確実なものにする

技術管理プロセス：プロジェクト計画を作成。実施し、実績を評価し、進捗を管理し、プロジェクトの完了まで制御する

技術管理：一つ以上のライフサイクルステージにおける技術的な満足に貢献する

ISO/IEC/IEEE 15288を実施するための要求事項としては、サイズ、複雑性とは関係しない


ライフサイクル概念の適用

概要

ライフサイクルプロセスの実施のためには、ライフサイクルモデルを作成する

ライフサイクルモデルにおいて確立されるステージ毎に、その記述、目的及び成果を文書化する

ライフサイクルのステージを通して、関係する組織とライフサイクルプロセスをどのように関係づけるかをライフサイクルモデルで示す

決定ゲイト

ライフサイクルモデルにおいて、組織的観点からどのようにマイルストーン及び決定ゲイトを設定するかは、システムライフ

サイクルの計画時に決め、システムライフサイクルの実施時にフォローする。

適用へのアプローチ

システムライフサイクルの実施時には、以下の留意点から必要に応じアプローチを選択する。

組織の購買ポリシー

システムの性格及び複雑性

システム要求の安定性

技術上の機会

異なる時点での異なるシステムの要求への対応

リソースの制約

ライフサイクルモデルのアプローチ

組織のビジネス上の制約、リスク回避への対応策により、以下のアプローチがある。

順次型

インクリメンタル型

進化型（アジャイル）


プロセス概念の適用

概要

ここでは、プロセスを実行するにあたり、それが意図した成果を得るため、及び目的を達成

するためのガイドラインを提供する。

プロセスのグループ化合意プロセス

組織的プロジェウトイネーブリングプロセス

技術管理プロセス

技術プロセス


4. システムライフサイクルのどのプロセスが有効か？

“Leveraging Systems Engineering to Improve Program Performance”, SEI研究者によるNDIA 2010年7月22日プレゼンテーション

より引用して紹介する。

システムズエンジニアリングの重要性

適用効果と開発プロセスとのマッピング


Leveraging Systems Engineering to Improve Program Performance, SEI研究者による2010年7月22日プレゼンテーション

システムズエンジニアリングの重要性


適用効果と開発プロセスとのマッピング

Leveraging Systems Engineering to Improve Program Performance, SEI研究者による2010年7月22日プレゼンテーション


5. ISO/IEC/IEEE 15288:2015の早期開発ステージ関連技術プロセス

技術プロセス概観

早期開発ステージに関わるプロセスの考察


技術プロセス概観

ISO/IEC/IEEE 15288:2015においては、以下の３０プロセスが定義されているが、システムズエンジニアリング適用の有効性が調査の結果報告されている技術プロセスの中でも特に早期開発ステージに関わるプロセスを考察する。

合意プロセス（２プロセス）組織上のプロジェクトイネーブリングプロセス（６プロセス）技術管理プロセス（８プロセス）技術プロセス（１４プロセス）

＊：水色：今回対象のプロセスの位置づけを以下に示す。プロセス名の番号は１５２８８項番

6.4.1 ビジネスあるいはミッションの解析

6.3 技術管理プロセス

6.4 技術プロセス

6.4.10 移行

6.4.8 システム結合

6.4.6 システム解析6.4.2 ステークホールダーニーズと要求の明確化

6.4.3 システム要求の明確化

6.4.4 アーキテクチャの明確化

6.4.5 設計

6.4.12, 6.4.13

維持と運用

6.4.14 廃棄

6.4.11 妥当性確認

6.4.9 検証

6.4.7 実装


早期開発ステージに関わるプロセスの考察

早期開発ステージに関わる７プロセスにつき、次葉以降で個々に説明する。

以降の項番はISO/IEC/IEEE 15288:2015の項番で表す。


6.4.6 システム解析

6.4.2 ステークホールダーニーズと要求の明確化




6.4.9 検証


6.4.1 ビジネスあるいはミッションの解析目的：ビジネスあるいはミッションの問題あるいは機会を明確化し、解決策の範囲を特徴付け、問題に対応すると共に機会を生かす解決案を決める。

A)アクティビティ

T)タスク I)成果情報記録 O)プロセスの実行完了時の状態（成果）

A1) ビジネスあるいはミッション解析の準備をする

T1.1) 要望されている組織目標と目的に関連する組織

戦略における特定された問題と機会をレビューする

T1.2) ビジネスあるいはミッション解析戦略を明確化する

T1.3) 必要なイネーブリングシステムあるいはサ

ービスを識別する

T1.4) イネーブリングシステムあるいはサービスを使用可能にする

I1) 予備的なライフサイクルにおける諸概念

SoIがよって立つライフサイクルをビジネスの要求の実現の観点から記述。以下の考え方の内容を含む。

購入、展開、OpsCon、支援、製品サイクル終了

I2) 問題あるいは機会の記述

組織戦略に立脚し、それと実装しようとしている能力とのギャップあるいは機会を説明する

I3) 解決案及び推奨

問題あるいは機会に対応する解決策

I4) トレーサビリティマップ

O1) 問題あるいは機会が明確化されている

O2) ビジネスあるいはミッション解析に必要なイネーブリングシステムあるいはサービスが利用可能である

O3) 解空間は特徴付けられ

ている

O4) 予備的な運用概念やライフサイクルにおける他の概念は明確化されている

O5) 候補となる代替案は特定され、解析されている

O6) 望ましい代替案が選択されている

O7) ビジネスあるいはミッション解析のトレーサビリティは確立されている

A2) 問題あるいは機会の範囲を明確化する

T2.1) 関連するトレードオフ解析の文脈から問題と機会を解析する

T2.2) ミッション、ビジネスあるいは問題あるいは機会を明確化する

A3) ソリューションの範囲を明確化する

T3.1) 予備的な運用概念やライフサイクルにおける他の概念を明確化する

T3.2) 可能解の中で候補となる代替案を特定する

A4) 代替案を評価する

T4.1) 各代替案を評価する

T4.2) 望ましい代替案を選択する

A5) ビジネ

スあるいはミッション解析を管理する

T5.1) ビジネスあるいはミッション解析のトレーサビリティを維持する

T5.2) ベースラインとして選択された主要成果記録を整備する



成果情報記録事例としての文書類成果

I1) 予備的なライフサイクルにおける諸概念

I2) 問題あるいは機会の記述

I3) 解決案及び推奨


用語の説明

・問題 (4.1.29)

困難、不確実、その反対に実現されるが期待していない出来事、条件、あるいは状況で調査および是正処置を必要とするもの

・機会

・イネーブリングシステム (4.1.18)

ライフサイクルを通して、SoIを支援するシステムであるが、運用時に果たされる機能には直接貢献しないもの

・ソリューション

・運用概念（Consept of operations) (4.1.11)

組織においてシステムの運用あるいは一連の活動における仮定あるいは意図を大まかに記述あるいは図示したもの

・ライフサイクル (4.1.23)

システム、製品、サービス、プロジェクトあるいは他の人工物の概念から利用停止までの進化

・SoI (System-of-Interest) (4.1.48)

本規格のコンテキストで考察対象とするライフサイクルを通して関心あるシステム

・可能解

・解空間

・トレーサビリティとトレーサビリティマップ

考慮事項


6.4.2 ステークホールダーニーズと要求の明確化目的:ユーザーおよび他のステークホールダーに必要とされる能力を提供するシステムの要求を明確化する

A)アクティビティ T)タスク I)成果情報記録 O)プロセスの実行完了時の状態（成果）

A1) ステークホール

ダーニーズと要求の明確化の準備をする

T1.1) ライフサイクルを通して関心を持つステークホールダーを識別するT1.2) ステークホールダーニーズと要求事項を明確化する戦略を明確化するT1.3) 必要なイネーブリングシステムとサービスを識別するT1.4) イネーブリングシステムとサービスを利用できるようにする

I1) 運用概念

経営層のために企業の全体的あるいは連続する業務における仮定あるいは意図を記述するもの。

I2) ライフサイクル概念SoI(System of Interest)が基

礎とし、評価し、選択するライフサイクルを記述する文書

I3) ステークホールダーニーズ

I4) ステークホールダー要求

I5) ステークホールダー要求報告

I6) 重要なパーフォーマンス測定値

I7) トレーサビィティマップ

O1) システムのステーク

ホールダーは識別されているO2) 運用概念を含むライフサイクルの概念において、要求される特性と能力が明確化されているO３）システムの制約事項は明確化されているO4) ステークホールダーニーズは明確にされているO5) ステークホールダー

ニーズは優先付けられ明確にされたステークホールダー要求に変換されているO６) 重要なパーフォーナンス測定値は明確化されているO７) ステークホールダー

ニーズと期待が適切に反映されているという合意が得られているO８) ステークホールダーニーズと要求のためのイネーブリングシステムとサービスが入手可能であるO９) ステークホールダー

要求とニーズのトレーサビリティが得られている

A2)ステークホールダーニーズを明確化する

T2.1) 運用概念と予備的なライフサイクル概念の範囲で使用する内容を明確化するT2.2) ステークホールダーニーズを識別するT2.3) ニーズに優先位をつけるT2.4) ステークホールダーニーズと論拠を明確化する

A3) 運用の基本的

考え方および他のライフサイクルの考え方を明確化する

T3.1) 予想され運用及び他のライフサイクル概念に対応する要求される能力を識別するための代表的なシナリオを明確化するT3.2) ユーザーとシステムの相互作用を識別する

A4) ステークホールダーニーズをステークホールダー要求に変換する

T4.1)システム解における制約事項を識別するT4.2) 重要な品質特性、例えば、保証、安全、セキュリティ、環境、あるいは健康、に関連するステークホールダー要求と機能を識別するT4.3) ライフサイクル概念、シナリオ、相互作用、制約、重要な品質要求と整合性あるステークホールダー要求を明確化する

A5) ステークホールダー要求を解析する

T5.1)ステークホールダー要求一式を解析するT5.2) 技術上の達成を評価できる重要なパフォーマンス測定値を明確化するT5.3) 要求を解析した結果を要求者にフィードバックし、ニーズと期待値を適切に反映していることの妥当性確認するT5.4) ステークホールダー課題を解決する

A6) ステークホールダーニーズと要求の明確化を管理する

T6.1) ステークホールダー要求の細部にわたって合意を得るT6.2) ステークホールダーニーズと要求のトレーサビリティを維持するT6.3) ベースラインとして選択された主要成果記録を準備する


6.4.2 ステークホールダーニーズと要求の明確化


I1) 運用概念

I2) ライフサイクル概念

I3) ステークホールダーニーズ

I4) ステークホールダー要求

I5) ステークホールダー要求報告

I6) 重要なパーフォーマンス測定値

I7) トレーサビィティマップ

用語の説明

・ステークホールダー（4.1.44)

個人あるいは組織で、システムにおいて、あるいは、その特性の保有によりニーズと期待に対応する権利、共有、主張あるいは関心を持つ者

・要求（4.1.37)

ニーズおよびそれに関連する制約と条件を表明する記述

・システム解

・パフォーマンス測定値

・課題（４．１．１２）

一人かそれ以上のステークホールダーに関わるシステム中の関心事

考慮事項


6.4.3 システム要求の明確化目的: ステークホールダー、ユーザー指向で要望される能力をユーザーの運用ニーズに合致する解決策の技術

観点に変換する


A1) システム要求の明確化のための準備をする

T1.1) 提供される振る舞い及び特性の観点からシステムの機能境界を明確化するT1.2) システム要求を明確にする戦略を明確化するT1.3) システム要求を明確にすることを支援するたに必要なイネーブリングシステムとサービスを識別し入手の計画をするT1.4) 使用するイネーブリングシステムあるいはサービスを入手するか利用可能にする

I1) システム記述

I2) システム要求プロジェクト及び設計の

制約に合致するどのようなものをシステムとして作るか。これには、要求の型、例えば、機能、パフォーマンス、インターフェース、振る舞い、運用条件、運搬、倉庫、等を含む

I3) システム要求の報告書

I4) 重要なパフォーマンス測定値


O1) システム解として、インターフェース、機能と境界を含むシステム記述がされている

O2) システム要求（機能、パ

フォーマンス、プロセス、非機能及びインターフェース）と設計の制約は明確にされている

O3) 重要なパフォーマンス測定値は明確にされている

O4) システム要求は解析されている

O5) イネーブリングシステム及びサービスは利用可能である

O6) システム要求のステークホールダー要求へのトレーサビリティは開発されている

A2) システム要求を明確化する

T2.1) システムが要求されたように実行するための各機能を明確化するT2.2)必要な実装制約を明確化するT2.3) リスク、システムの臨界性、あるいは重要な品質特性に関連するシステム要求を識別するT2.4) システム要求及び論拠を明確化する

A3) システム要求を解析する

T3.1) システム要求一式を解析するT3.2) 技術上の達成を評価するため測定値を明確化するT3.3) 要求を解析し関係するステークホールダーにフィードバックしレビューを受けるT3.4) システム要求の課題事項を解決する

A4) システム要求を管理する

T4.1) システム要求に関する細部の合意を得るT4.2) システム要求のトレーサビリティを維持するT4.3) ベースラインとして選択された主要な成果記録を準備する




I1) システム記述

I2) システムの要求

I3) システム要求の報告書

I4) 重要なパフォーマンス

の測定値


用語の説明

・システム (4.1.46)

一つあるいはそれ以上の記述された目的を達成するように組織化された要素の相互に関係する組み合わせ

・システム要求

・システムの機能境界

・システム要求の課題

・システムの臨界性

・システム記述

・ベースライン (4.1.10)

その形式を問わず構成管理のライフサイクルにおいてある時点で正式に認められた版

考慮事項



A1) アーキテクチャの明確化のための準備をする(タスク：3/6)

T1.1) 適切な情報をレビューし、アーキテクチャの主要な要素を識別するT1.2) ステークホールダーの関心事を識別するT1.3) アーキテクチャを明確化するためのロードマップ、アプローチ及び戦略を明確化する

I1) アーキテクチャの構成要素

I2) アーキテクチャ観点とモデル

I3) アーキテクチャ報告における論拠

I4) インターフェースの明確化（予備的）

I5) アーキテクチャの評価報告


O1）ステークホールダー関心事はアーキテクチャにより対応されている

O2) アーキテクチャの構成要素は展開されている

O3) システムのコンテキスト、境界及び外部とのインターフェースは明確化されている

O4) システムのアーキテクチャ観点及びモデルが展開されている

O5) システムのアーキテクチャを決定する概念、特性、特質、振る舞い、機能あるいは制約条件はアーキテクチャ＾要素に配置されている

O6) システム要素とそれらのインターフェースは特定されている

O7) アーキテクチャ候補は評価されている

O8) ライフサイクルを通してプロセスのアーキテクチャ上のベースは達成されている

O9) 要求と設計の特性をアーキテクチャとが結び付けられている

O10) アーキテクチャの明確化のために必要なイネーブリングシステムあるいはサービスは利用可能である

O11) アーキテクチャ要素からステークホールダー及びシステム要求へのトレーサビリティは展開されている

A2)アーキテクチャの構成要素を展開する(タスク：3/4)

T2.1)ステークホールダーの関心事に基づく構成要素とモデルの種類を選択、適用あるいは展開するT2.2) モデルと観点を展開するために、アーキテクチャフレームワークを確立するか明確化するT2.3) フレームワーク、構成要素およびモデルの種別を選択するための根拠を獲得する

A3) アーキテクチャ候

補のモデルと観点を展開する

(タスク：3/6)

T3.1) 外部要素とのインターフェースと相互作用の観点でシステムコンテキスト及び境界を明確化するT3.2) アーキテクチャ要素と主要なステークホールダーの関心事と重要なシステム要求に対応する要素間の関係とを識別するT3.3) システムのアーキテクチャ決定からアーキテクチャ要素の決定に重要な概念、特性、特質、振る舞い、機能あるいは制約条件の割り当てを行う

A4) アーキテクチャと設計を結びつける

(タスク：3/5)

T4.1) アーキテクチャ要素とこれらの間の関係性に関連するシステム要素を識別するT4.2) システム要素間および外部要素とのインターフェース及び相互関係を明確化するT4.3) 要求事項からアーキテクチャ要素およびシステム要素に分割し、整合させ、そして割り当てる

A5) アーキテクチャ候補を評価する(タスク：2/4)

T5.1) アーキテクチャ候補のそれぞれにつき制約と要求に対して評価するT5.2) アーキテクチャ候補のそれぞれにつき評価基準に基づきステークホールダーの関心事で評価する

A6) 選択したアーキテクチャを管理する(タスク：2/7)

T6.1) アーキテクチャのガバナンスアプローチを決め、ガバナンスに関連する役割と責任、説明責任と権限を明確にするT6.2) ステークホールダーによるアーキテクチャの受入れを明確に獲得する

6.4.4 アーキテクチャの明確化目的：システムアーキテクチャの代替案を生成し、ステークホールダーの関心事をカバーす

る一つあるいはそれ以上の代替案を選択し、これを整合性ある観点で表現する。




I1) アーキテクチャの構成要素

I2) アーキテクチャ観点とモデル

I3) アーキテクチャ報告における論拠

I4) インターフェースの明確化（予備的）

I5) アーキテクチャの評価報告


用語の説明

・アーキテクチャ (4.1.5)

システムの基本的概念あるいは特性で、要素、要素間関係およびその設計と進化の原則を取り組んでいるもの

・アーキテクチャフレークワーク (4.1.6)

アーキテクチャの記述のための取り決め、原則、プラクティス出、ある特定

のアプリケーション分野あるいはステークホールダーのコミュニティにおいて確立されているもの

・アーキテクチャ観点 (4.1.7)

特定のシステムの関心事の視点からシステムのアーキテクチャを表現する

中間成果物

・アーキテクチャの構成要素 (4.1.8)

アーキテクチャ観点を創生、解釈、および利用して特定のシステムの関心事を構成する中間成果物

・アーキテクチャのガバナンス

考慮事項

・ISO/IEC/IEEE 42010 アーキテクチャ記述参照のこと


6.4.6 システム解析目的: ライフサイクルを通して意思決定を支援する技術上の理解のためのデータと情報の厳密な基礎を提供する。


A1) システム解析の準備をする

T1.1) システム解析を必要とする問題あるいは質問を識別するT1.2) システム解析のステークホールダーを識別するT1.3) システム解析のスコープ、目的、及び忠実さのレベルを決めるT1.4) システム解析手法を選択するT1.5) システム解析戦略を決めるT1.6) システム解析を支援するイネーブリングシステムあるいはサービスを識別し計画する

T1.7) 使用するイネーブリングシステムあるいはサービスを利用可能にするT1.8) 解析のためのデータ及び入力情報を集める

I1) システム解析報告書関係者のためにシステム解析

活動の状態、結果、及び成果をコミュニケートするために準備されたものコスト解析、リスク解析、有効

性解析、及び他の重要な特性解析を含む

O1) 必要とされるシステム解析は識別されている

O2) システム解析の仮定と結果の妥当性は確認されている

O3) 決定のためにシステム解析結果は準備されている

O4) システム解析のためのイネーブリングシステムとサービスは利用可能である

O5) システム解析結果のトレーサビリティは確立されている

A2) システム解析を実施する

T2.1) 仮定を識別し妥当性確認をするT2.2) 要求されるシステム解析を実施するために選択された手法を適用するT2.3) 品質と妥当性のために解析結果をレビューするT2.4) 結論と推奨を確立するT2.5) システム解析の結果を記録する

A3) システム解析を管理する

T3.1) システム解析結果のトレーサビリティを維持するT3.2) ベースラインとして選択された成果情報項目を準備する


6.4.6 システム解析


I1) システム解析報告書

用語の説明

・システム解析

考慮事項



A1) 検証の準備をする

T1.1) 検証のスコープと対応する検証の活動を識別するT1.2) 検証を制限するような制約項目を識別するT1.3) 各検証活動に適切な検証手法あるいは技法を選択するT1.4) 検証の戦略を明確化するT1.5) システム要求、アーキテクチャあるいは設計に組み込まれている検証の戦略からシステムの制約を識別するT1.6) 検証に必要なイネーブリングシステムあるいはサービスの内、必要なものを識別し計画するT1.7) 検証に必要なイネーブリングシステムあるいはサービスの内必要なものを入手あるいは利用可能にする

I1) 検証されたシステム提供あるいは運用可能なシス

テム

I2) 検証の記録

検証に関連する恒久的で、読解可能な形式のデータ、成果情報及び知識

I3) 検証報告書

検証活動の状況、結果、及び成果で関係者とのコミュニケ―

ションのために準備されたもの


O1) 検証の拘束条件で要求、アーキテクチャ、設計に影響をあたえるものが特定されている。

O2) 検証に必要とされるイネーブリングシステムあるいはサービスは利用可能である。

O3) システムあるいはシステム要素は検証されている。

O4) 是正処置のための

データを準備することが報告されている。

O5) 実現されたシステムが要求、アーキテクチャ、および設計を満足している客観的な証拠が準備されている。

O6) 検証の結果と不具合は特定されている。

O7) 検証されたシステム要

素のトレーサビリティが取れている。

A2) 検証を実施する

T2.1) 検証の一つあるいはそれ以上のまとめた活動に対応する検証の手順を明確化するT2.2) 検証の手順を実施する

A3) 検証の結果を管理する

T3.1) 検証の結果及び遭遇したどんな不具合も記録するT3.2) 運用上の事故および問題を記録しその解決を追跡するT3.3) システムあるいはシステム要素が指定された要求に合致していることの同意をステークホールダーから得るT3.4) 検証がされている要素のトレーサビリティを維持するT3.5) ベースラインとして選択された主要な成果項目を準備する

6.4.9 検証目的：システムあるいはシステム要素が指定された要求と特性を満足することを客観的な証拠で示すことである。



I1) 検証されたシステム

I2) 検証の記録

I3) 検証報告書


用語の説明

・検証 (4.1.54)

客観的な証拠によりある要求が満足されていることの確認

・検証を制限するような制約事項

考慮事項

6.4.9 検証


6.4.11 妥当性確認目的: システムが使用される時に、ビジネスあるいはミッション目的とステークホールダーの要求を満足しているこ

とを客観的に示し、意図された運用環境において意図したことを達成していることを示す


A1) 妥当性確認の準備をする

T1.1) 妥当性確認のスコープと対応する妥当性確認の活動を識別するT1.2) 妥当性確認活動を制限する制約項目を識別するT1.3) 各妥当性確認に適切な妥当性確認手法あるいは技法を選択するT1.4) 妥当性確認の戦略を明確化するT1.5) ステークホールダー要求に組み込まれている妥当性確認の戦略からシステムの制約事項を識別するT1.6) 妥当性確認に必要なイネーブリングシステムあるいはサービスの内、必要なものを識別し計画するT1.7) 妥当性確認に必要なイネーブリングシステムあるいはサービスの内、必要なものを入手あるいは利用可能にする

I1) 妥当性確認がされたシステム

提供あるいは運用可能なシステム

I2) 妥当性確認の記録妥当性確認に関連する恒久

的で、読解可能な形式のデータ、成果情報及び知識

I3) 妥当性確認報告書妥当性確認の活動の状況、結

果、及び成果で関係者とのコミュニケ―ションのために準備されたもの


O1) ステークホールダー要求のための妥当性確認規範は決められているO2) ステークホールダーに要求されているサービスの入手は確認されているO3) 妥当性確認の制約で

要求、アーキテクチャあるいは設計に影響するものは識別されているO4) システムあるいはシステム要素の妥当性確認はされているO5) 妥当性確認に必要とさ

れるイネーブリングシステムあるいはサービスは利用可能になっているO6) 妥当性確認の結果および不具合は識別されているO7) 実現されたシステムあ

るいはシステム要素がステークホールダーニーズを満足しているとの客観的証拠が準備されているO8) 妥当性確認がされてい

る要素のトレーサビリティが確立している

A2) 妥当性確認を実施する

T2.1) 妥当性確認の一つあるいはまとめた活動に対応する妥当性確認の手順を明確化するT2.2) 決められた環境での妥当性確認の実施をするT2.3) ステークホールダーに求められているシステムのサービスが可能であることを確認するように妥当性確認の結果をレビューする

A3) 妥当性確認の結果を管理する

T3.1) 妥当性確認の結果及び遭遇したどんな不具合も記録するT3.2) 運用上の事故および問題を記録しその解決を追跡するT3.3) システムあるいはシステム要素がステークホールダーニーズに合致していることの同意をステークホールダーから得るT3.4) 妥当性確認がされている要素のトレーサビリティを維持するT3.5) ベースラインとして選択された主要な成果項目を準備する




I1) 妥当性確認がされたシステム

I2) 妥当性確認の記録

I3) 妥当性確認報告書


用語の説明

・妥当性確認 (4.1.53)

客観的な証拠によりある要求が特定の意図された使用あるいは適用が満足されていることの確認

・妥当性確認を制限する制約事項

考慮事項

システムライフサイクルプロセス説明（案）iso/iec/ieee 15288:2015及びiso/iec...

Documents