>サイトトップへ >このカテゴリの一覧へ

X 0170

:2013 (ISO/IEC 15288:2008)

(1)

目  次

ページ

序文

1

1

  概要

2

1.1

  適用範囲

2

1.2

  目的

3

1.3

  適用分野

3

1.4

  制限

3

2

  適合性

4

2.1

  意図した用途

4

2.2

  完全適合

4

2.3

  修整(tailor)適合

4

3

  引用規格

4

4

  用語及び定義

4

5

  基本概念及び適用

9

5.1

  システム概念

9

5.2

  ライフサイクルの概念

13

5.3

  プロセスの概念

14

6

  システムライフサイクルプロセス

18

6.1

  合意プロセス

18

6.2

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

21

6.3

  プロジェクトプロセス

27

6.4

  テクニカルプロセス

38

附属書 A(規定)修整(tailoring)プロセス

59

附属書 B(参考)アセスメント目的のプロセス参照モデル

61

附属書 C(参考)プロセスの統合及びプロセスの構成概念

63

附属書 D(参考)プロセスビュー

65

附属書 E(参考)この規格と JIS X 0160:2012 との間のプロセスの関係

69

附属書 F(参考)他の IEEE 規格との関係

71

附属書 G(参考)参考文献

72

附属書 H(参考)参加者一覧

74


X 0170

:2013 (ISO/IEC 15288:2008)

(2)

まえがき

この規格は,工業標準化法第 14 条によって準用する第 12 条第 1 項の規定に基づき,一般社団法人情報

処理学会情報規格調査会(ITSCJ/IPSJ)及び一般財団法人日本規格協会(JSA)から,工業標準原案を具し

て日本工業規格を改正すべきとの申出があり,日本工業標準調査会の審議を経て,経済産業大臣が改正し

た日本工業規格である。

これによって,JIS X 0170:2004 は改正され,この規格に置き換えられた。

この規格は,著作権法で保護対象となっている著作物である。

この規格の一部が,特許権,出願公開後の特許出願又は実用新案権に抵触する可能性があることに注意

を喚起する。経済産業大臣及び日本工業標準調査会は,このような特許権,出願公開後の特許出願及び実

用新案権に関わる確認について,責任はもたない。


日本工業規格

JIS

 X

0170

:2013

(ISO/IEC 15288

:2008

)

システムライフサイクルプロセス

Systems and software engineering-System life cycle processes

序文

この規格は,2008 年に第 2 版として発行された ISO/IEC 15288 を基に,技術的内容及び構成を変更する

ことなく作成した日本工業規格である。

なお,この規格で点線の下線を施してある参考事項は,対応国際規格にはない事項である。

人が作り出すシステムの複雑さは,かつてないほどに増大している。このことは,新しい機会を導くが,

システムを作り出し活用する組織に対して課題を増加させている。これらの課題は,システムのライフサ

イクルを通して及び構造のあらゆる水準の細部に存在している。

これらは,次の幾つかの原因から生じている。

−  システムを構築する,ハードウェア,ソフトウェア及び人的構成要素の間には固有の違いがある。

−  現在使用されている,ほとんど全てのシステムは,コンピュータに基づく技術を含んでいるか,又は,

コンピュータに基づく技術によってモデル化され,支援されている。

−  科学,エンジニアリング,マネジメント及び財務を含めて,関連する分野の調和及び統合が欠如して

いる。

それゆえに,現代的システムが統合された,首尾一貫したやり方で働くことができるように,現代的シ

ステムを作り出し,活用し,管理する当事者間で,意思伝達及び協調を促進するために共通の枠組みが必

要である。

この規格は,人が作ったシステムのライフサイクルを対象とする共通のプロセスの枠組みを提供する。

このライフサイクルは,システムの構想段階から廃止に至るまでに及んでいる。このライフサイクルは,

システムの取得及び供給のためのプロセスを提供している。それに加えて,この枠組みは,ライフサイク

ルプロセスのアセスメント及び改善を提供する。

改正されたこの規格は,システムライフサイクル及びソフトウェアライフサイクルのプロセス及び適用

の手引の完全に統合化した一組を作り上げる SC7 の調和化戦略における最初の段階である。

この改訂版は,

システムライフサイクルプロセスの文脈内で,JIS X 0160 への改訂と協調しており,プロセス定義につい

ての SC7 指針を適用して,一貫性を保ち,使用性を改善し,構造,用語並びに類似の組織に関するプロセ

ス及びプロジェクトプロセスを調整している。

この規格のプロセスは,包括的な集合を形成しており,それから組織はその製品及びサービスに適した

システムライフサイクルモデルを構築することができる。目的に応じて,組織は,その目的を満足させる

ために,適切な部分集合を選択し,適用できる。

この規格は,次の一つ以上の形態で使用することができる。


2

X 0170

:2013 (ISO/IEC 15288:2008)

−  組織によって:望まれるプロセスの環境の構築を支援するため。これらのプロセスは,方法,手順,

手法,道具及び訓練された要員のインフラストラクチャによって支援することができる。そのとき,

組織は,ライフサイクル段階を通して,プロジェクトを実行し管理し,システムを進めるためにこの

環境を採用してもよい。この形態では,この規格を,宣言され,確立された環境のその規定への適合

性をアセスメントするために使用する。

−  プロジェクトによって:製品及びサービスを提供するために,確立された環境の構成要素の選択,構

築及び採用を支援するため。この形態では,この規格を,宣言され,確立された環境に対するプロジェ

クトの適合性のアセスメントに使用する。

−  取得者及び供給者によって:プロセス及びアクティビティに関する合意の形成を支援するため。合意

を通じて,この規格のプロセス及びアクティビティを,選択し,協議し,合意し,実行する。この形

態では,この規格を,合意の形成における手引として使用する。

−  プロセスのアセスメントの担当者によって:組織のプロセス改善を支援するために行われることがあ

るプロセスアセスメントの実行において使用するプロセス参照モデルとして役に立つ。

この規格は,二つの箇条に要求事項を含んでいる。箇条 には,システムライフサイクルプロセスに対

する要求事項を規定しており,

附属書 には,この規格の修整に対する要求事項を提供している。この規

格は,次に挙げる幾つかの参考の附属書も含んでいる。

附属書 は,プロセスアセスメントを支援するため,プロセス参照モデルとしてシステムライフサイ

クルプロセスの使用について情報を提供している。

附属書 は,この規格で使用されるプロセス構成概念の記述を提供している。

附属書 は,スペシャリティエンジニアリングに対するプロセスビューの事例を提供している。それ

は,プロジェクトが,スペシャリティとして選択された製品特性の達成に着目するために,JIS X 0170

のプロセス,アクティビティ及びタスクを組み合わせる方法を解説することを意図している。

附属書 は,JIS X 0170 のプロセスと JIS X 0160 のプロセスとの関係を記述している。

附属書 は,他の IEEE 規格との関係を記述している。

注記 1  IEEE 規格との関係は,JIS としては必要ないと考え,附属書 は削除している。

注記 2  ISO/IEC TR 24748 は,この規格と JIS X 0160:2012 との関係を記述している。

1

概要

1.1

適用範囲

この規格は,人が作り出すシステムのライフサイクルを記述するための共通の枠組みを確立する。この

規格は,ひとそろいのプロセス及び関連する用語を定義する。これらのプロセスは,システムの階層構造

のどのレベルにも適用可能である。これらのプロセスから選定された集合は,システムのライフサイクル

の段階を管理,実行するために,ライフサイクルを通じて,適用することができる。これは,顧客満足を

達成するという最終目標をもつ,対象となる全ての当事者の参加を通して達成される。

この規格は,組織内又はプロジェクト内で使用するライフサイクルプロセスの定義,制御及び改善を支

援するプロセスも規定する。組織及びプロジェクトは,システムを取得及び供給する場合にこれらのライ

フサイクルプロセスを使用することができる。

この規格は,人が作ったシステム,すなわち,次に示す一つ以上のもので構成されるシステムに関する

ものである。それは,ハードウェア,ソフトウェア,データ,人,プロセス(例えば,利用者にサービス

を提供するプロセス)

,手順(例えば,操作指示書)

,設備,原材料及び自然に発生する実体を指す。


3

X 0170

:2013 (ISO/IEC 15288:2008)

システム要素がソフトウェアである場合は,そのシステム要素を実装するのに,JIS X 0160 で規定する

ソフトウェアライフサイクルプロセスを使用してもよい。この規格と JIS X 0160 とは,単一のプロジェク

ト又は単一の組織で併用できるように調和が取られている。システム要素がハードウェアである場合は,

該当する JIS 又は ISO/IEC 規格を参照。

注記  この規格の対応国際規格及びその対応の程度を表す記号を,次に示す。

ISO/IEC 15288:2008

,Systems and software engineering−System life cycle processes(IDT)

なお,対応の程度を表す記号“IDT”は,ISO/IEC Guide 21-1 に基づき,

“一致している”こ

とを示す。

1.2

目的

この規格の目的は,システムのライフサイクルにおける,取得者,供給者及び他の利害関係者の間で円

滑に情報伝達を行う場合に必要な定義されたプロセスの集合を提供することである。

この規格は,組織が取得者の役割を行う場合でも,供給者の役割を行う場合でも適用される。単一の組

織が,

自主的に計画し開発する状況又は複数の当事者で計画し開発する状況でも,

使用することができる。

当事者は,同じ組織又は異なる組織であってもよく,この状況は,非公式の合意から公式の契約にまで及

ぶ。

この規格の中のプロセスは,例えば,方法,手順,手法,道具及び訓練された要員といった,業務環境

を確立するための基礎として使用することができる。

附属書 は,これらのシステムライフサイクルプロ

セスの修整の仕方に関する基準を示す。

1.3

適用分野

この規格は,システムの構想,開発,生産,利用,支援及び廃止を含めて,システムの全ライフサイク

ルに適用され,組織の内外にかかわらず実行されるシステムの取得及び供給に適用される。この規格のラ

イフサイクルプロセスは,システム及びその要素に対して,並行的に,反復的に,及び再帰的に適用する

ことができる。

システムの目的,適用領域,複雑さ,規模,新規性,適応性,量,場所,寿命及び進化は,多種多様で

ある。

この規格は,

人が作ったいかなるシステムのライフサイクルを構成するプロセスをも記述している。

それゆえ,この規格は,一品ずつ作るシステム,量産されたシステム,及び特注の融通の利くシステムに

適用される。この規格は,単体で機能するシステムにも,より複雑で完全なより大きなシステムに組み込

まれて結合されるシステムにも適用される。

この規格は,

プロセスの目的,

及びアクティビティの実施に成功した結果得られるプロセスの成果によっ

て特徴付けられたプロセス参照モデルを規定する。それゆえ,この規格は,JIS X 0145-2:2006 で示された

プロセスアセスメントを支援する参照モデルとして使える。

附属書 は,プロセス参照モデルとしてシス

テムライフサイクルプロセスの使用に関する情報を提供している。

附属書 は,プロセス参照モデルとし

て使用する場合のプロセス構成を記述している。

1.4

制限

この規格は,特定のシステムライフサイクルモデル,開発方法論,方法,モデル,又は手法を規定しな

い。この規格は,プロセスの要求事項及び成果を満たすために要求される方法又は手順の観点でライフサ

イクルプロセスを詳述していない。

この規格は,文書の名称,様式,具体的な内容及び記録媒体については詳述していない。

この規格は,組織の方針,手順及び作業標準と矛盾すること,又は国の法律及び規制にも矛盾すること

を意図していない。矛盾がある場合には,この規格を使用する前に,それを解決することが望ましい。


4

X 0170

:2013 (ISO/IEC 15288:2008)

2

適合性

2.1

意図した用途

この規格の要求事項は,箇条 及び

附属書 に規定されている。この規格は,ソフトウェア製品又はソ

フトウェアサービスのライフサイクルで使用するのに適切な幾つかのプロセスに対する要求事項を規定す

る。特定のプロジェクト又は組織では,この規格で規定する全てのプロセスを利用しなくてもよいことが

認識されている。それゆえ,この規格を実施するには,一般的には,組織又はプロジェクトに適した一そ

ろいのプロセスを選定する。この規格を適用する場合,この規格に適合していることを主張する,二通り

の方法がある。適合していることの主張は,次の二つの形態のいずれか一つで記載される。

2.2

完全適合

完全適合の主張では,適合を主張する一連のプロセスを宣言する。完全適合は,宣言したプロセスの集

合に対する要求事項の全てを満たしていることを,

証拠となる成果を示して,

立証することで達成される。

2.3

修整(tailor)適合

当事者は,この規格をプロセスの集合を定める基礎として使用するがその集合が完全適合とはみなされ

ないときは,

附属書 に規定された修整(tailor)プロセスに従って,この規格の箇条を選定するか又は修

正(modify)する。修整(tailor)適合であると主張する修整(tailor)文章を明示する。修整(tailor)適合

は,修整(tailor)したプロセスに対する要求事項を満たしていることを,証拠となる成果を示して,立証

することで達成される。

注記 1  この規格を,取得者と供給者との間の合意形成に役立てるために使用する場合には,この規

格の箇条を修正(modification)して,又はそのまま変更せずに選定して,合意に組み入れる

ことができる。この場合,取得者及び供給者にとっては,この規格に適合していることより

も,合意に遵守していることを主張することがより適切である。

注記 2  商取引の条件として,この規格の使用を課す組織(例えば,国家機関,産業団体,企業など)

は,供給者がこの規格に適合していると認められるために必要なプロセス,アクティビティ

及びタスクについての最小限の集合を明示し,公開することが望ましい。

注記 3  この規格では,

“とする”又は“

(し)なければならない”

(shall)は,この規定の要求事項を

表現するために使用する。

“することが望ましい”

(should)は,推奨を表すために使用する。

“してもよい”

“すること(場合)がある”又は“することができる”

(may)は,この規格

の限度内で許容される一連の行為であることを示す。

3

引用規格

次に掲げる規格は,この規格に引用されることによって,この規格の規定の一部を構成する。この引用

規格は,記載の年の版を適用し,その後の改正版(追補を含む。

)は適用しない。

JIS X 0160:2012

  ソフトウェアライフサイクルプロセス

注記  対応国際規格:ISO/IEC 12207:2008,Systems and software engineering−Software life cycle

processes(IDT)

4

用語及び定義

この規格で用いる主な用語及び定義は,次による。


5

X 0170

:2013 (ISO/IEC 15288:2008)

4.1

取得者(acquirer)

供給者から,製品又はサービスを取得又は調達する利害関係者。

注記  取得者に対して通常使われている用語には,他に納入先,顧客,所有者又は購入者がある。

4.2

取得(acquisition)

システム製品又はシステムサービスを入手するプロセス。

注記  JIS X 0160 から編集。

4.3

アクティビティ(activity)

プロセスの構成要素で,関連の強いタスクの集合。

4.4

合意(agreement)

業務上の関係を実行するための取決めの相互確認。

4.5

アーキテクチャ(architecture)

システムの基本的な構成。その構成要素,それらの相互関係及び環境との関係,並びに,設計及び進化

を導く原則,を具体化したもの。

ISO/IEC 42010:2007)

4.6

監査(audit)

監査基準が満たされている程度を判定するために,監査証拠を収集し,それを客観的に評価するための

体系的で,独立し,文書化されたプロセス。

JIS Q 9000:2006)

4.7

ベースライン(baseline)

公式にレビューされ,合意された仕様又は製品で,以降の開発の根拠として使用されるもの。その変更

は,公式の変更管理手順を通してだけ認められる。

4.8

顧客(customer)

製品又はサービスを受け取る組織又は人。

注記 1  顧客は,組織の内部又は外部のいずれでもあり得る。

注記 2  JIS Q 9000:2006 から編集。

注記 3  顧客に対して通常使われる用語は,取得者,納入先又は購入者である。

4.9

イネーブリングシステム(enabling system)

ライフサイクル段階の期間中は対象システムを支援するが,運用の期間中はその機能に直接的に寄与す

るとは限らないシステム。

注記 1  例えば,対象システムが生産段階に入ると,生産イネーブリングシステムが必要となる。


6

X 0170

:2013 (ISO/IEC 15288:2008)

注記 2  各イネーブリングシステムは,それ自身のライフサイクルをもつ。イネーブリングシステム

自体を対象システムとして扱う場合には,この規格は,各イネーブリングシステムに適用可

能である。

4.10

設備(facility)

活動の実施を容易にする物理的手段又は装置。例えば,建物,器具,道具など。

4.11

ライフサイクル(life cycle)

システム,製品,サービス,プロジェクト又は人が作った他の実体の構想から廃止までの漸進的な変化。

4.12

ライフサイクルモデル(life cycle model)

段階に編成されることもあるライフサイクルに関係するプロセス及びアクティビティの枠組みで,情報

伝達及び理解のための共通に参照できる役割をもつもの。

注記  “プロセス”,“アクティビティ”及び“タスク”は,システム開発作業を階層化して表すもの

である。最上位の作業のくくりが  “プロセス”

,その“プロセス”の構成要素が“アクティビ

ティ”

,さらに,

“アクティビティ”の構成要素が“タスク”である。

4.13

運用者(operator)

システムの運用を行う実体。

注記 1  運用者及び利用者の役割は,同一の個人又は組織に対して,同時に又は順次的に,付与され

る。

注記 2  知識,スキル(技能)及び手順を備えた個々の運用者は,システムの一要素としてみなすこ

とができる。

注記 3  この用語定義の中で,実体という用語は,個人又は組織を意味する。

4.14

組織(organization)

責任,権限及び関係の取り合わせをもつ人又は人々の集団及び施設。

注記 1  JIS Q 9000:2006 から編集。

注記 2  クラブ,組合,会社,学会など特定の目的のために組織された人の一群。

注記 3  組織の識別された部分(たとえ単一個人のように小さくても)又は組織内の識別された群は

責任,権限及び関係をもてば組織とみなされる。

4.15

当事者(party)

契約に関わる組織。

注記  この規格では,合意する当事者は取得者及び供給者と呼ばれる。

4.16

プロセス(process)

インプットをアウトプットに変換する,相互に関連する又は相互に作用する一連のアクティビティ。

注記  この規格の内容に合うように,JIS Q 9000:2006 の定義を変更した。


7

X 0170

:2013 (ISO/IEC 15288:2008)

4.17

プロセス目的(process purpose)

プロセスを実行する高水準の目標及びプロセスの効果的実施によって見込まれる成果。

注記  プロセスの実施は,利害関係者に目に見える利益を提供することが望ましい。

JIS X 0160:2012)

4.18

プロセス成果(process outcome)

プロセスの目的の達成に成功することによって観察できる結果。

JIS X 0160:2012)

4.19

製品(product)

プロセスの結果。

JIS Q 9000:2006)

4.20

プロジェクト(project)

定められた資源及び要求事項に従って,製品又はサービスを作り出すために実施される,定義された開

始条件及び終了条件がある取組。

注記 1  JIS Q 9000:2006 から編集。

注記 2  プロジェクトを,調整され制御されたアクティビティからなる固有のプロセスとして見ても

よいし,この規格に定義されたプロジェクトプロセス及びテクニカルプロセスのアクティビ

ティで構成されるものとしてもよい。

4.21

プロジェクトポートフォリオ(project portfolio)

組織の戦略的目標に対応するプロジェクトの集まり。

4.22

適格性確認(qualification)

実体が規定要求事項を満たすことができるかを実証するプロセス。

JIS X 0160:2012)

4.23

品質保証(quality assurance)

品質管理の一部であり,とりわけ品質要求が充足されることへの信頼を提供する活動。

JIS Q 9000:2006)

4.24

(対応国際規格のこの項では,request for tender,proposal という用語を定義しているが,この規格中では

使用されていないので,不採用とした。

4.25

資源(resource)

プロセスの実行中に利用又は消費される資産。

注記 1  資源には,資金,要員,設備,資本設備,道具などの多様な実体,及び,電力,水,燃料,

通信基盤などの公益物を含めてよい。


8

X 0170

:2013 (ISO/IEC 15288:2008)

注記 2  資源は,再利用できるものでもよいし,再生できるものでもよいし,又は使い切ってしまう

ものでもよい。

4.26

廃止(retirement)

運用組織又は保守組織が実施中の支援を中止すること,新システムに一部分若しくは全体を置き換える

か,又は改定したシステムを導入すること。

JIS X 0160:2012)

4.27

セキュリティ(security)

システムの機密性,完整性(integrity)

,可用性,否認防止,説明責任,真正性,及び信頼性の定義付け,

達成及び維持に関する全ての側面。

4.28

段階(stage)

実体のライフサイクル内の期間で,実体記述又は実体の状態に関連するもの。

注記 1  この規格では,段階は,実体のライフサイクルを通して,実体の大きな進捗及び達成のマイ

ルストーンに関係する。

注記 2  段階は,重なってもよい。

4.29

利害関係者(stakeholder)

システムに,権利,持分,請求権若しくは関心をもっている個人若しくは組織,又は,ニーズ及び期待

に合致する特性をシステムがもつことに,権利,持分,請求権若しくは関心をもっている個人若しくは組

織。

4.30

供給者(supplier)

製品又はサービスの供給に関して取得者と合意を結ぶ組織又は個人。

注記 1  供給者に対して通常使用される用語は,請負業者,生産者,販売者又はベンダ。

注記 2  取得者及び供給者は,同一の組織に属してもよい。

4.31

システム(system)

一つ以上の明記された目的を達成するために組織された相互に作用する要素の組合せ。

注記 1  システムとは,それが提供する製品又はサービスとみなしてもよい。

注記 2  実際には,その意味の解釈は,例えば,航空機システムのように複合名詞の使用によってし

ばしば明確にされる。別の表現として,システムという言葉を使わずに,文脈が明らかな場

合は,例えば,

“航空機システム”を“航空機”という用語に置き換えることができる。その

場合は,システムという捉え方の観点が曖昧になる。

4.32

システム要素(system element)

システムを構成する要素の集合の一部分。

注記  システム要素とは,指定された要求事項を満たすように実装できるシステムの個別の部分であ

る。システム要素は,ハードウェア,ソフトウェア,データ,人間,プロセス(例えば,利用


9

X 0170

:2013 (ISO/IEC 15288:2008)

者にサービスを提供するプロセス)

,手順(例えば,操作指示)

,施設,資材及び自然に発生す

る実体(例えば,水,有機体,ミネラル)又はそれらの組合せであり得る。

4.33

対象システム(system-of-interest)

この規格の文脈においてライフサイクルが検討対象となるシステム。

4.34

タスク(task)

プロセスの一つ以上の成果の達成に貢献するように意図された要求事項,勧告又は許される行動。

4.35

トレードオフ(trade-off)

利害関係者にとっての実質利益に基づいて,様々な要求事項と代替解決策とから選定するという意思決

定行為。

4.36

利用者(user)

システムを利用する間,システムからの恩恵を受ける個人又はグループ。

注記  利用者又は運用者の役割は,同一の個人又は組織の中で,同時に又は順番に担う。

4.37

妥当性確認(validation)

客観的証拠を提示することによって,特定の意図された用途又は適用に関する要求事項が満たされてい

ることを確認すること。

JIS Q 9000:2006)

注記  システムライフサイクルでいう妥当性確認とは,意図された運用環境にて,意図された用途,

目標及び目的(例えば,利害関係者要求事項を満たす)をシステムが達成できることを確実に

し,信任を得る一連のアクティビティである。

4.38

検証(verification)

客観的証拠を提示することによって,規定要求事項が満たされていることを確認すること。

JIS Q 9000:2006)

注記  システムライフサイクルでいう検証とは,システム又はシステム要素と必要とされる特性とを

比較するという一連のアクティビティである。これには,規定要求事項,設計記述及びシステ

ム自身を含めてもよく,それだけに限られるものでもない。

5

基本概念及び適用

5.1

システム概念

5.1.1

はじめに

箇条 は,この規格の基礎となった本質的な概念を強調し,その説明に役立てるためのものである。こ

れらの概念は,ISO/IEC TR 24748 シリーズ(第 1 部∼第 3 部は発行済み。第 4 部は作成中)で詳細を提供

する。


10

X 0170

:2013 (ISO/IEC 15288:2008)

5.1.2

システム

この規格で考えるシステムとは,利用者及び他の利害関係者の利益のために,定義された環境において

製品及び/又はサービスを提供するために,人が作り,創出し,活用するものである。これらのシステム

は,次のシステム要素の一つ以上のもので構成されてもよい。すなわち,ハードウェア,ソフトウェア,

データ,人間,プロセス(例えば,利用者にサービスを提供するプロセス)

,手順(例えば,運用者向け使

用説明書)

,施設,原材料及び自然に発生する実体である。それらは,実際には,製品又はサービスと考え

られる。

特定のシステム,そのアーキテクチャ及びシステム要素の認識及び定義は,見る人の関心及び責任に依

存する。ある人の対象システムは,他の人の対象システムにおけるシステム要素と見ることができる。し

かも,一つの対象システムは,他の人の対象システムに対する運用の環境の一部と見ることができる。

対象システムの特性に関する要点を次に示す。

a)

対象システムを区切る,定義された境界によって,意味のあるニーズと現実的な解決策とが一つにま

とまる。

b)

システム要素間には階層的又は他の関係がある。

c)

対象システム内のどのレベルの実体もそれ自体一つのシステムと見ることができる。

d)

システムは,結合され定義された下位のシステム要素の集合からなる。

e)

システムの境界における特有な性質は,システム要素間の相互作用から生じる。

f)

人間は,システムの外部の利用者と見ることができるし,システム内のシステム要素(すなわち,運

用者)と見ることができる。

g)

システムは,製品のように,独立した実体として,又は一組のサービスのように,周囲の環境との相

互作用ができる機能の集合として見ることができる。

システムを定義するためにどのような境界を選んだとしても,この規格における概念及びモデルは一般

的であり,実践者がライフサイクルの個々の事例をそのシステムの原則に関連させ,又は適合させること

を可能にしている。

この規格において,人間は,システムの利用者とも,システムの要素ともみなされる。前者の場合,利

用者は,システムの運用の受益者である。後者の場合,指定されたシステム機能を遂行する運用者である。

一人ひとりが,同時に又は順次に,システムの利用者とシステムの要素との両者になることができる。

対象システム,システム及びシステム要素の概念,並びにライフサイクルを通じてのそれらの適用に関

する追加の詳細及び例は,ISO/IEC TR 24748 シリーズ(第 1 部∼第 3 部は発行済み。第 4 部は作成中)で

詳細を提供する。

5.1.3

システム構造

この規格においてシステムライフサイクルプロセスは,システムとの関連で規定される(

図 参照)。シ

ステムは,互いに影響し合うシステム要素の集合から構成され,各システム要素は,それぞれの指定され

た要求事項を実現するために実装される。そのため,どのシステム要素の実装の責任を合意を得た上で別

の当事者に委ねてもよい。


11

X 0170

:2013 (ISO/IEC 15288:2008)

図 1−システムとシステム要素との間の関係

システムとそのシステム要素の完全な集合との間の関係は,一般的には,最も単純な対象システムの場

合には 2 階層で表現される。より複雑な対象システムの場合,システム要素と思われるもの自体を一つの

システム(これは,また,複数のシステム要素からなる)とみなす必要がある。そうすることで,システ

ム要素の完全な集合が,確信をもって定義できるようになる(

図 参照)。このように,適切なシステムラ

イフサイクルプロセスは,対象システムに再帰的に適用してその構造を分解し,理解可能で,管理可能な

システム要素を実装(作成,購入又は再利用)するか,又は他の当事者から取得することを可能にする。

対象システムは,どの型のシステム又はシステムの組合せを含んでもよい。特定の階層的又は平面的な表

現を暗示するものではない。

システム

システム

要素

システム

要素

システム

要素

←  システム

←  完全に構成される

←  相互作用の組

←  システム要素


12

X 0170

:2013 (ISO/IEC 15288:2008)

図 2−対象システム構造

5.1.4

イネーブリングシステム

対象システムのライフサイクルを通じて,直接的には運用環境の一部とならないシステム(例えば,大

量生産システム,訓練システム,保守システム)から,不可欠なサービスが要求される。これらのシステ

ムの各々は,対象システムのライフサイクルの一部(例えば,段階)を実施できるようにする。

“イネーブ

リングシステム”と名付けられ,ライフサイクルを通じて対象システムの発展を促進する。

対象システムによって運用環境に供給されるサービスとイネーブリングシステムによって対象システム

に供給されるサービスとの間の関係を,

図 に示す。イネーブリングシステムは,対象システムによって

提供されるサービスに間接的に寄与するのが分かる。対象システムとイネーブリングシステムとの間の関

係は,双方向か一方通行の関係である。イネーブリングシステムとの相互作用に加えて,対象システムは,

システム A,システム B 及びシステム C で示されるように,運用環境の他のシステムとも相互作用するこ

とがある。運用環境において,イネーブリングシステムと他のシステムとのインタフェースに対する要求

事項は,対象システムに対する要求事項に含まれることが必要とされる場合がある。

対象

システム

システム

システム

システム

システム

システム

システム

システム

システム

要素

システム

要素

システム

要素

システム

要素

システム

要素

システム

要素

システム

要素

システム

要素

システム

要素

システム

要素

システム

要素

システム

要素

システム

要素

システム

要素


13

X 0170

:2013 (ISO/IEC 15288:2008)

運用環境内の

システムB

運用環境内の

システムA

運用環境内の

システムC

対象システム

イネーブリング

システムB

イネーブリング

システムA

イネーブリング

システムC

運用環境を構成するシステムの

相互作用

イネーブリングシステムによる

相互作用

図 3−対象システム,運用環境及びイネーブリングシステム

システムライフサイクルの段階の間に,関連したイネーブリングシステム及び対象システムが同時に考

慮される。イネーブリングシステム及び対象システムは,相互に依存しているので,それらはまた一つの

システムと見ることができる。したがって,対象システムのライフサイクイルの段階に対するプロジェク

トの責任は,関連したイネーブリングシステムからサービスを取得するための責任にまで及ぶ。適切なイ

ネーブリングシステムがまだ存在しないときは,対象システムに責任をもつプロジェクトは,また,イネー

ブリングシステムを創出し利用するための直接的責任がある。

イネーブリングシステムを創出することは,

別個のプロジェクトとして,かつ,その後でもう一つの対象システムと見ることができる。

イネーブリングシステムに関する追加の詳細は,ISO/IEC TR 24748 シリーズ(第 1 部∼第 3 部は発行済

み。第 4 部は作成中)で提供する。

5.2

ライフサイクルの概念

5.2.1

システムライフサイクルモデル

あらゆるシステムには,ライフサイクルがある。ライフサイクルは,そのシステムのニーズの概念化,

その実現,利用,進化及び廃棄を表現する,抽象的機能モデルを使って規定することができる。

システムは,組織内の人によって実行され,管理され,これらの活動の実行のためのプロセスを使用す

ることによって,活動の結果としてそのライフサイクルを通して進行する。ライフサイクルモデルの中の

詳細は,これらのプロセス,それらのプロセスの成果,プロセスの関係及びプロセスの順序に関して表現

される。この規格は,ライフサイクルプロセスと呼ばれる,システムのライフサイクルの定義に使用でき

るプロセスの集合を定義する。

5.2.2

システムライフサイクル段階

ライフサイクルは,そのシステムの性質,目的,利用及び支配的な周囲の事情によって異なる。各段階

は,ライフサイクル全体に対する明確な目的及び貢献があり,システムライフサイクルを計画し,実行す

るときに考慮される。

段階は,システムと関連したライフサイクルの主要期間を表し,システム記述の状態又はシステム自身

に関連する。段階は,そのライフサイクルを通してシステムの主要な進捗及び達成のマイルストーンを記

述する。段階は,ライフサイクルの主要な決定ゲートを生み出す。これらの決定ゲートは,システムを創


14

X 0170

:2013 (ISO/IEC 15288:2008)

出又は利用するときに,

コスト,

スケジュール及び機能性に関係する固有の不確実性及びリスクを理解し,

対処するために,組織によって利用される。それゆえ,段階は,その中で組織の管理者がプロジェクト及

びテクニカルプロセスの高いレベルの可視性及び制御をもつ枠組みを組織に提供する。

注記  決定ゲートは,プロジェクトが一つのフェーズから次のフェーズへ移るために使われる主要な

制御点を定義する。

組織によっては,

対照的な業務戦略とリスク緩和戦略とを満たすために,

段階を異なった形で使用する。

段階を並行的に使用したり,異なった順序で使用したりすることは,明確に異なる特性をもつライフサイ

クル形態に導く。ライフサイクルの概念及び段階に関する追加の詳細は,ISO/IEC TR 24748 シリーズ(第

1 部∼第 3 部は発行済み。第 4 部は作成中)で提供する。

5.3

プロセスの概念

5.3.1

プロセスの記述

この規格の各プロセスは,次の属性によって記述する。

−  タイトルは,プロセスの全体としての範囲を表す。

−  目的は,プロセスを実行する目標を記述する。

−  成果は,プロセスの実施に成功することによって期待される観察可能な結果を表す。

−  アクティビティは,プロセスの構成要素で,関連の強いタスクの集合である。

−  タスクは,成果の達成を支援することを意図した要求事項,推奨,又は容認された行動である。

記述についてのこの形式に関する付加的詳細は,ISO/IEC TR 24774 シリーズ(第 1 部∼第 3 部は発行済

み。第 4 部は作成中)に見ることができる。

5.3.2

この規格のプロセス

5.3.2.1

はじめに

この規格では,ソフトウェアシステムのライフサイクルで実行するアクティビティを四つのプロセスグ

ループに分けている。これらのグループ内のライフサイクルプロセスは,その目的及び望まれる成果に関

して記述しており,これらの成果を達成するために実施することが必要なアクティビティ及びタスクを列

挙している。

四つのプロセスグループ及び各グループに含まれるプロセスを

図 に示す。この規格で記述されたプロ

セスは,

組織が有用であるとした追加のプロセスの使用を排除又は阻止する意図はない。

各プロセスグルー

プの記述は,次の四つの細分箇条に含まれる。この規格と JIS X 0160 とを同時に使用する場合の便宜のた

めに,箇条 の対応するプロセスは,

6.x.x レベルで)同一の細分箇条番号にしている。


15

X 0170

:2013 (ISO/IEC 15288:2008)

図 4−システムライフサイクルプロセス

5.3.2.2

合意プロセス

組織は,システムの生産者であり利用者である。製品又はサービスに対して,

(取得者となる)一つの組

織は(供給者となる)他の組織に仕事を課すことができる。これは,合意を用いて達成される。

一般に,組織は,同時に又は順次にシステムの取得者及び供給者の両者として振る舞う。取得者及び供

給者が同一組織に属するときは余り形式張らないで合意プロセスが使える。同様に,組織,プロジェクト

及び技術部門のそれぞれの責任について同意するために合意プロセスが使える。

図 は,このプロセスグ

ループに含まれるプロセスを挙げている。

5.3.2.3

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

組織のプロジェクトイネーブリングプロセスは,組織の関心をもつ当事者のニーズ及び期待をプロジェ

クトが満たすことが可能になるように,必要な資源の充足を確実にすることに関係している。組織のプロ

ジェクトイネーブリングプロセスは,一般的に戦略レベルにおいて次の三つに関係している。

システムライフサイクルプロセス

合意プロセス

取得プロセス(6.1.1

供給プロセス(6.1.2

組織のプロジェクト

イネーブリングプロセス

ライフサイクルモデル管理

プロセス(6.2.1

インフラストラクチャ管理

プロセス(6.2.2

プロジェクトポートフォリ

オ管理プロセス(6.2.3

人 的 資 源 管 理 プ ロ セ ス

6.2.4

品質管理プロセス(6.2.5

テクニカルプロセス

利害関係者要求事項定義プロセ

ス(6.4.1

要求事項分析プロセス(6.4.2

方式設計プロセス(6.4.3

実装プロセス(6.4.4

結合プロセス(6.4.5

検証プロセス(6.4.6

移行プロセス(6.4.7

妥当性確認プロセス(6.4.8

運用プロセス(6.4.9

保守プロセス(6.4.10

廃棄プロセス(6.4.11

プロジェクトプロセス

プ ロ ジ ェ ク ト 計 画 プ ロ セ ス

6.3.1

プロジェクトアセスメント及

び制御プロセス(6.3.2

意思決定管理プロセス(6.3.3

リスク管理プロセス(6.3.4

構成管理プロセス(6.3.5

情報管理プロセス(6.3.6

測定プロセス(6.3.7


16

X 0170

:2013 (ISO/IEC 15288:2008)

−  組織の業務又は事業の管理及び改善

−  資源及び資産の準備及び配置

−  競合又は不確実な状況におけるリスク管理

組織のプロジェクトイネーブリングプロセスはプロジェクトが遂行される環境を確立する。組織は,次

のことを行う。

−  プロジェクトで使われるプロセス及びライフサイクルモデルを確立する。

−  プロジェクトを確立するか,方向変更するか,又は取り消す。

−  人的及び財政資源を含む必要資源を提供する。

−  内部顧客及び外部顧客のためにプロジェクトによって開発されるシステム及び他の納入品目に対して

品質尺度を設定し,監視する。

組織のプロジェクトイネーブリングプロセスは,多くの組織に対して,ビジネスのイメージを強く作り

上げ,商用で営利的動機を暗示している。しかしながら,利害関係者への説明責任があり,資源にも責任

があり,事業でのリスクにも遭遇するので,組織のプロジェクトイネーブリングプロセスは,同様に,非

営利組織にも関係している。したがって,この規格は,営利組織と同じように非営利組織にも適用できる。

図 は,このプロセスグループに含まれるプロセスを挙げている。

5.3.2.4

プロジェクトプロセス

プロジェクトプロセスは,組織の管理者によって割り当てられた資源及び資産を管理すること並びに一

つ以上の組織が締結する合意を果たすために資源及び資産を適用することに関係している。

それらは,プロジェクトの管理に関係するが,特に次に関係する。

−  コスト,タイムスケール及び成果に関しての計画

−  プロジェクトが計画及び達成基準を遵守していることを保証するための活動のチェック

−  進捗及び達成における不足を回復する是正措置の識別及び選択

一般的に,組織の中には,幾つかのプロジェクトが共存する。プロジェクトプロセスは,内部のニーズ

を満たすために法人レベルで使うことができる。

図 は,このプロセスグループに含まれるプロセスを挙

げている。

5.3.2.5

テクニカルプロセス

テクニカルプロセスは,ライフサイクルを通して技術的活動に関係する。利害関係者のニーズを最初に

製品に変換し,それからその製品を適用することによって,顧客満足を達成するために必要とされるとき

及び場所で持続できるサービスを提供する。システムがモデルの形態であるかそれとも完成品であるとき

に,テクニカルプロセスは,システムを創出し使用するために適用し,システム構造の階層のどのレベル

においても適用する。

図 は,このプロセスグループに含まれるプロセスを挙げている。

5.3.3

プロセスの適用

この規格に定義されたライフサイクルプロセスは,システムの取得,利用,創出又は供給において,ど

の組織でも使用できる。ライフサイクルプロセスは,システムの階層のどのレベルでも,かつ,ライフサ

イクルのどの段階でも適用できる。

ライフサイクルプロセスは,モジュール化の原理(プロセスの機能の凝集の最大化及びプロセス間の結

合の最小化)及び所有(プロセスは責任を伴う。

)の原理に基づいている。これらのプロセスが実行する機

能は,特定の目的,成果及びプロセスを構成するアクティビティ及びタスクの集合で構成される。


17

X 0170

:2013 (ISO/IEC 15288:2008)

図 の各ライフサイクルプロセスは,ライフサイクルを通して,必要に応じて呼び出すことができる。

この規格でプロセスが記述されている順序は,その利用上の事前に定められた順番を指定してはいない。

ただし,逐次的関係は,ライフサイクルモデルの定義によって決められている。ライフサイクルを通して

これらのプロセスの使用の詳細な目的及び時期は,システムの一生の間にいずれも変化し得る,社会的,

取引上,組織上及び技術上の考慮を含む複数の要因の影響を受ける。したがって,個別のシステムライフ

サイクルは,並行的,反復的,再帰的及び時間依存の特性を通常もつプロセスの複雑なシステムとなる。

プロセスの並行的使用は,一つのプロジェクト内(例えば,システム構築のための設計活動及び準備活

動が同時に実行される場合である。

)に存在することができる。また,複数プロジェクト間(例えば,複数

のシステム要素が異なるプロジェクトの責任の下で同時に設計される場合である。

にも存在することがで

きる。

同一のプロセス又は同一のプロセス集合が同じシステムに繰り返し適用された場合,その適用は反復的

と呼ぶ。プロセスの反復的使用は,プロセスの出力を漸進的に洗練するために重要である。例えば,連続

的な検証活動及び統合活動の間の相互作用は,製品の適合に関して信用を徐々に築くことができる。反復

は,適切であるだけでなく,予期されるものである。新しい情報は,プロセス又はプロセスの集合の適用

によって生まれる。通常は,この情報は,要求事項,分析されたリスク又は機会に関する質問の形態をと

る。このような質問は,プロセス又はプロセスの集合のアクティビティを完了する前に解決することが望

ましい。

プロセスの再帰的使用は,すなわち,システムの構造のシステム要素の連続的レベルでの,同一のプロ

セス又は同一のプロセス集合の繰返し適用は,この規格の適用の重要な側面である。どのレベルでもプロ

セスの出力は,情報,成果物又はサービスであるかどうかに関係なく,

(例えば,トップダウンの設計の場

合の)下のレベル又は(例えば,システム実現の場合の)上のレベルで使われる同じプロセスへの入力と

なる。一つの適用からの成果は,システム構造の中の次の下位(又は上位)のシステムの入力となり,よ

り詳細であるか又はより成熟している成果の集合に到達する。そのようなやり方は,システム構造の中の

連続するシステムへの付加価値となる。

システムへの影響の変化する性質(例えば,運用環境の変化,システム要素の実装に対する新しい機会,

組織内の変更された構造及び責任)は,プロセスの使用の選択及び時期の継続的なレビューを要求する。

したがって,ライフサイクル内のプロセスの使用は,システムに対する多くの外部的影響に応じて,動的

である。ライフサイクルのやり方は,次の段階の中に変化を組み込むことも可能にする。ライフサイクル

段階は,理解可能で認識可能な高水準の目的及び構成を提供することによって,ライフサイクルにおける

この複雑を前にしてライフサイクルプロセスの立案,実行及び管理の役に立つ。ライフサイクル段階内の

プロセスの集合は,その段階に対する完了基準及び/又はその段階内の公式な進捗レビューの開始基準を

満たす共通の目標を伴って適用される。

システムのライフサイクルプロセスの反復的及び再帰的使用に関するこの 5.3.3 の中の記述は,

特定の階

層的又は水平的システム構造を暗示することを意味しない。システムのライフサイクルプロセスの適用に

ついての追加の指針は,ISO/IEC TR 24748 に更なる詳細が記述されている。

5.3.4

プロセス修整(process tailoring

附属書 は,この規格の修整を行うために必要な基本的アクティビティを定義する。この規格への適合

の主張によって認められている価値を,修整することで減少させるかもしれないことに注意することが望

ましい。その理由は,修整によって望ましい規定が削除された度合いを他の組織が理解するのが難しいか

らである。この規格への適合を単独で主張を唱える組織はプロセスの大きなリストへの修整適合よりもむ


18

X 0170

:2013 (ISO/IEC 15288:2008)

しろプロセスの小さいリストへの完全適合を主張した方が有利であることを見いだしてもよい。

6

システムライフサイクルプロセス

6.1

合意プロセス

ここでは,組織内及び組織間の関係者による合意を確立するための要求事項を明記する。

合意プロセスは,次のプロセスから構成される。

a)

取得プロセス−製品又はサービスを取得する組織によって使用される。

b)

供給プロセス−製品又はサービスを供給する組織によって使用される。

これらのプロセスは,二つの組織の間での合意を確立するために必要なアクティビティを定義する。取

得プロセスが呼び出されると,取得プロセスは,運用システムとして使われる製品の供給者,運用システ

ムを支援するサービスの供給者又はプロジェクトで開発されるシステムの要素の供給者と共同して業務を

遂行する手段を提供する。供給プロセスが呼び出されると,供給プロセスは,結果が取得者に納入される

製品又はサービスとなるプロジェクトを遂行する手段を提供する。

6.1.1

取得プロセス

6.1.1.1

目的

取得プロセスは,取得者の要求事項に従って,製品又はサービスを得ることを目的とする。

6.1.1.2

成果

取得プロセスの実施に成功すると次の状態になる。

a)

取得戦略が確立されている。

b)

一つ以上の供給者が選定されている。

c)

供給者とのコミュニケーションが維持されている。

d)

定義された受入れ基準に基づいた製品又はサービスを取得する合意が確立されている。

e)

合意を遵守した製品又はサービスが受け入れられる。

f)

支払金又はそれに代わる対価が供給者に渡される。

6.1.1.3

アクティビティ及びタスク

取得者は,取得プロセスに関して,該当する組織の方針及び手順に従って,次のアクティビティ及びタ

スクを実施する。

注記  このプロセスのアクティビティ及びタスクは,一つ以上の供給者に適用できる。

a)

取得の準備

このアクティビティは,次のタスクからなる。

1)

取得をどのように行うかについて戦略を確立する。

注記  この戦略は,ライフサイクルモデルの参照,マイルストーンのスケジュール及び供給者が

取得組織外である場合の選定基準を含む。

2)

要求事項の記述を含む製品又はサービスの購買仕様を用意する。

注記  一つ以上の供給者に対して要求事項の定義を提供する。供給者が組織外である場合には,

その供給依頼は,供給者が遵守して欲しい商慣習及び供給者の選定基準を含むことがある。

b)

取得の通知及び供給者の選択

このアクティビティは,次のタスクからなる。

1)

識別された供給者に対して,製品又はサービスの供給の依頼を伝達する。


19

X 0170

:2013 (ISO/IEC 15288:2008)

注記  ここでは,技術面及び取引面の共通課題に対して,協調のとれた又は一体となった進め方

を実現するために,関連する供給者及び取得者と情報交換するようなサプライチェーンマ

ネジメント連携を含めてもよい。

2)

一つ以上の供給者を選定する。

注記  競争力のある提案書を手に入れるために,選定基準を適用して,供給者の提案書を評価し

比較する。その提案書に選定基準にない提供項目を含む場合には,提案書を相互に比較し,

適合の順位を決め,それに従って供給者の優先順位を決定する。個々の提案に対する評定

の理由を明らかにし,選定された理由又は選定されなかった理由を供給者に知らせること

がある。

c)

合意の着手

このアクティビティは,次のタスクからなる。

1)

供給者と合意を取り付ける交渉をする。

注記  この合意には,書面による契約から口頭での了解までの形式上の幅がある。形式の程度に

応じて,要求事項,開発及び納入のマイルストーン,検証,妥当性確認及び受入れの条件,

例外処理手順,変更管理手順並びに支払いスケジュールを合意で設定する。その結果,合

意する双方の当事者が,合意を実行するための基本的事項を理解することになる。技術デー

タ及び知的財産に関する権利及び制約は,合意事項として記載される。取得者が供給者か

ら提示された合意の条件を受け入れた時点で,交渉は完了する。

2)

供給者との合意を開始する。

d)

合意の監視

このアクティビティは,次のタスクからなる。

1)

合意の実行の総合評価を行う。

注記  これには,全ての当事者の合意に従って責任を果たしていることの確認を含む。見積もら

れたコスト,実績及びスケジュールのリスクは監視され,組織への望ましくない結果の影

響は定常的に評価される。合意の条件の変更は,必要に応じて交渉される。

2)

供給者が必要とするデータを提供し,時宜にかなった方法で課題を解決する。

e)

製品又はサービスの受入れ

このアクティビティは,次のタスクからなる。

1)

納入される製品又はサービスが合意を遵守していることを確認する。

注記  合意の実施中に生じた例外又は納入される製品若しくはサービスに起因する例外は,合意

で確立された手順に従って解決される。

2)

引き渡された製品又はサービスに対して,合意の終結に必要な支払金又はそれに代わる合意した対

価を供給者に渡す。

6.1.2

供給プロセス

6.1.2.1

目的

供給プロセスは,合意された要求事項に合致した製品又はサービスを取得者に提供することを目的とす

6.1.2.2

成果

供給プロセスの実施に成功すると次の状態になる。

a)

製品又はサービスの取得者が識別されている。


20

X 0170

:2013 (ISO/IEC 15288:2008)

b)

取得者の依頼への返答が行われている。

c)

定義された受入れ基準に従って製品又はサービスの供給についての合意が確立されている。

d)

取得者とのコミュニケーションが維持されている。

e)

合意に適合した製品又はサービスが,合意された納入手順及び条件に従って供給される。

f)

合意によって指示されたとおり,取得された製品又はサービスの責任が移される。

g)

支払金又はそれに代わる合意された対価が受け取られる。

6.1.2.3

アクティビティ及びタスク

供給者は,供給プロセスに関して,該当する組織の方針及び手順に従って,次のアクティビティ及びタ

スクを実施する。

a)

機会の識別

このアクティビティは,次のタスクからなる。

1)

製品又はサービスへのニーズをもつ取得者,又はニーズをもつ一つ以上の組織を代表する取得者の

存在及び身元を決定する。

注記  消費者のために開発される製品又はサービスについては,代理者,例えば,供給組織内の

マーケティング部門が,取得者を代表してもよい。

b)

入札への対応

このアクティビティは,次のタスクからなる。

1)

実現可能性及び対応の仕方を決定するため,製品又はサービスの供給依頼を評価する。

2)

要請を満たす回答の準備をする。

c)

合意の着手

このアクティビティは,次のタスクからなる。

1)

取得者と合意を取り付ける交渉をする。

注記  この合意には,書面契約から口頭での了解までの形式上の幅がある。妥当の場合は,取得

依頼又は作業記述書と回答に表現された能力との差について話し合う。供給者は,次を確

認する。

−  要求事項,納入マイルストーン及び受入れ条件が達成可能である。

−  例外処理手順,変更管理手順及び支払いスケジュールが受入れ可能である。

−  不要なリスクを伴わずに合意を実施できる基礎を確立する。

合意又はプロジェクト計画において,供給者は,プロジェクトの範囲,規模及び複雑度

に適したライフサイクルモデルを定義又は選択することが望ましい。理想的には,これら

のことは,組織で定義したライフサイクルモデルを使用して行う。

2)

取得者との合意を開始する。

d)

合意の実行

このアクティビティは,次のタスクからなる。

1)

確立したプロジェクト計画及び合意したやり方に従って供給者は合意を実行する。

注記 1  供給者は,取得者のプロセスを採用してもよいし,又は使用することに合意してもよい。

注記 2  取得者とのコミュニケーションは,合意の実行を通して維持される。

2)

合意の実行の総合評価を行う。

注記  見積もりしたコスト,実績及びスケジュールにおけるリスクは監視され,適宜取得者に伝

達される。望ましくない結果の組織への影響が評価される。


21

X 0170

:2013 (ISO/IEC 15288:2008)

e)

製品又はサービスの納入及び支援

このアクティビティは,次のタスクからなる。

1)

合意基準に従って製品又はサービスを納入する。

2)

合意基準に従って,納入した製品又はサービスを支援して,取得者を援助する。

f)

合意の終結

このアクティビティは,次のタスクからなる。

1)

支払金又はそれに代わる合意された対価を受け取り,受取りの通知をする。

2)

合意の終結のために合意によって指示されたように,製品又はサービスへの責任を取得者又は他の

当事者へ引き渡す。

6.2

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

組織のプロジェクトイネーブリングプロセスは,プロジェクトの立上げ,支援及び制御を通じて,製品

又はサービスを取得又は供給するための組織の能力を管理する。

プロジェクトイネーブリングプロセスは,

プロジェクトを支援するために必要な資源及び基盤を提供し,組織の目標及び確立された合意を確実に満

たすようにする。このプロジェクトイネーブリングプロセスは,組織の業務を戦略的に管理できるように

する広範な業務プロセスを意図するものではない。

組織のプロジェクトイネーブリングプロセスは,次のものから構成される。

a)

ライフサイクルモデル管理プロセス

b)

インフラストラクチャ管理プロセス

c)

プロジェクトポートフォリオ管理プロセス

d)

人的資源管理プロセス

e)

品質管理プロセス

6.2.1

ライフサイクルモデル管理プロセス

6.2.1.1

目的

ライフサイクルモデル管理プロセスは,この規格の適用範囲に関して,組織によって使われる方針,ラ

イフサイクルプロセス,ライフサイクルモデル及び手順を定義し,維持し,可用性を保証することを目的

とする。

このプロセスは,次の内容をもつライフサイクルの方針,プロセス及び手順を提供する。

−  組織の目標と整合している。

−  組織の文脈内で個々のプロジェクトのニーズを支えるために,定義,適用,改善,及び保守がなされ

ている。

−  効果的で,証明済みの方法及びツールを使用して適用できる。

6.2.1.2

成果

ライフサイクルモデル管理プロセスの実施に成功すると次の状態になる。

a)

ライフサイクルモデル及びプロセスの管理及び展開のための方針及び手順が提供されている。

b)

ライフサイクル管理のための責任,説明責任及び権限が定義されている。

c)

組織が使用するライフサイクルプロセス,モデル及び手順が定義され,維持され,改善されている。

d)

プロセス,モデル及び手順の改善が順位付けられて行われている。

6.2.1.3

アクティビティ及びタスク

組織は,ライフサイクルモデル管理プロセスに関して,適用可能な組織の方針及び手順に従って,次の

アクティビティ及びタスクを実施する。


22

X 0170

:2013 (ISO/IEC 15288:2008)

a)

プロセスの確立

このアクティビティは,次のタスクからなる。

1)

組織の戦略と整合したプロセス管理及び展開のための方針及び手順を準備する。

注記  プロジェクト内のシステムライフサイクル実施における実際の範囲及び詳細度は,作業の

複雑さ,用いられる方法,作業遂行に参加する要員のスキル(技術)及び教育訓練などの

複雑さに依存する。プロジェクトは,要求事項及びニーズに応じて方針及び手順を修整す

る。

2)

この規格の要求事項を実施し,組織の戦略と整合したプロセスを確立する。

3)

ライフサイクルのプロセスの実施及びライフサイクルの戦略的管理を可能にする役割,責任及び権

限の定義,統合及び伝達を行う。

4)

ライフサイクルを通して進捗を制御する業務基準を定義する。

注記  各ライフサイクル段階及び他の主要なマイルストーンの開始及び終了に関する意思決定基

準を確立する。業務達成という観点でこれらを表現する。

5)

段階並びに各段階の目的及び成果から構成される標準のライフサイクルモデルを組織のために確立

する。

注記  ライフサイクルモデルは,必要に応じて,一つ以上の段階モデルから構成される。ライフ

サイクルモデルは,対象システムの範囲,規模,変化するニーズ及び機会に対して適切で

あるように重複/反復する一連の段階として組み立てられる。近く発行される技術報告書

ISO/IEC TR 24748)に,ライフサイクルモデルの通常見られる例を用いて,段階は説明

されている。システムに対する特定の例は,ISO/IEC TR 19760 に掲載されている。ライフ

サイクルプロセス及びアクティビティは選択され,適宜に修整されて,その段階の目的及

び成果を満たすように段階で使われる。

b)

プロセスのアセスメント

このアクティビティは,次のタスクからなる。

注記  ISO/IEC 15504 シリーズは,アクティビティ及びタスクのより詳細な集合を記述しており,

次に示されるタスクはそれに沿っている。

1)

業務基準に照らして,プロセスの実行を監視し,プロセスの測定値を分析し,傾向を判別する。

注記  この実施に当たっては,プロセスの有効性及び効率に関してプロジェクトからのフィード

バックを含むことが望ましい。

2)

プロジェクトで使用されるライフサイクルモデルの定期的なレビューを実施する。

注記  各プロジェクトで使用されるライフサイクルモデルの継続的な適合性,妥当性及び有効性

を確認し,適切に改善する。上記のことは,段階,プロセス及び達成基準を含み,ライフ

サイクルを通じての進捗を制御する。

3)

アセスメントの結果から改善の機会を識別する。

c)

プロセスの改善

このアクティビティは,次のタスクからなる。

1)

改善の機会を優先順位付け,計画する。

2)

改善の機会を実施し,結果を組織全体に伝達する。

6.2.2

インフラストラクチャ管理プロセス


23

X 0170

:2013 (ISO/IEC 15288:2008)

6.2.2.1

目的

インフラストラクチャ管理プロセスは,ライフサイクルを通して組織及びプロジェクトの目標を支援す

るために,イネーブリングインフラストラクチャ及びサービスをプロジェクトに提供することを目的とす

る。

このプロセスは,この規格の適用範囲に関して,組織の業務に対して必要な施設,ツール及び情報通信

技術の資産を定義し,提供し,維持する。

6.2.2.2

成果

インフラストラクチャ管理プロセスの実施に成功すると次のようになる。

a)

組織のプロジェクトを支援するインフラストラクチャに対する要求事項が定義されている。

b)

インフラストラクチャ要素が識別され,指定されている。

c)

インフラストラクチャ要素が開発されているか又は取得されている。

d)

インフラストラクチャ要素が実装されている。

e)

安定し,信頼できるインフラストラクチャが維持され,改善されている。

注記  インフラストラクチャは,開発,運用又は保守のためのハードウェア,ソフトウェア,サー

ビス,方法,ツール,手法,作業標準及び施設を含めてもよい。

6.2.2.3

アクティビティ及びタスク

組織は,インフラストラクチャ管理プロセスに関して,適用可能な組織の方針及び手順に従って,次の

アクティビティ及びタスクを実施する。

a)

インフラストラクチャの確立

このアクティビティは,次のタスクからなる。

1)

プロジェクトに対するインフラストラクチャの資源及びサービスの手配に影響し,制御するプロ

ジェクトインフラストラクチャの要求事項及び業務制約条件を定義する。

注記  組織の方針及び戦略的計画と同様に,プロジェクトに対するインフラストラクチャの資源

のニーズを組織内の他のプロジェクト及び資源との関連で考慮する。プロジェクト計画及

び将来の業務ニーズは,必要とされる資源のインフラストラクチャの理解に寄与する。作

業環境における施設などの物理的要因及び作業環境における周囲の音響レベルなどの人的

要因を定義する。

2)

プロジェクトを実施し,支援するのに必要なインフラストラクチャの資源及びサービスの識別,取

得及び提供を行う。

b)

インフラストラクチャの維持

このアクティビティは,次のタスクからなる。

1)

納入されたインフラストラクチャ資源がニーズを満たす度合いを定めるためにプロジェクトと連続

的に又は定期的にコミュニケーションを行う。

2)

プロジェクトの要求事項が変化するに従ってインフラストラクチャの資源への改善又は変更を識別

し,提供する。

6.2.3

プロジェクトポートフォリオ管理プロセス

6.2.3.1

目的

プロジェクトポートフォリオ管理プロセスは,組織の戦略的目標を満たすために必要十分かつ適切なプ

ロジェクトを開始し,維持することを目的とする。

このプロセスは,適切な組織の資金及び資源の投入を確約し,選ばれたプロジェクトの確立に必要な権


24

X 0170

:2013 (ISO/IEC 15288:2008)

限を認可する。このプロセスは,プロジェクトが継続的に投入することに値すること,又は値するように

軌道修正できることを確認するために,プロジェクトの適格性確認を継続する。

注記  このプロセスは,システムとの関連で適用される。ここで話題としているプロジェクトは,組

織での対象システムに焦点を当てている。

6.2.3.2

成果

プロジェクトポートフォリオ管理プロセスの実施に成功すると次の状態になる。

a)

ベンチャ事業機会,投資又は必要性が認められ,優先順位付けられ,選択される。

b)

各プロジェクトに対して資源及び予算が,識別され,割り当てられている。

c)

プロジェクト管理の説明責任及び権限が,定義される。

d)

合意及び利害関係者要求事項を満たすプロジェクトは,継続される。

e)

合意及び利害関係者要求事項を満たさないプロジェクトは,軌道修正又は中止される。

6.2.3.3

アクティビティ及びタスク

組織は,プロジェクトポートフォリオ管理プロセスに関して,該当する組織の方針及び手順に従い,次

のアクティビティ及びタスクを実施する。

a)

プロジェクトの開始

このアクティビティは,次のタスクからなる。

1)

組織の業務戦略及び活動計画と整合性のとれたやり方で,新規業務機会,ベンチャ事業又は請負事

業を識別し,優先順位付けし,選択し,確立する。

注記  開始すべきプロジェクトの優先順位付けを行い,実行すべきプロジェクトを決めるしきい

(閾)値を確立する。

2)

プロジェクト,説明責任及び権限を定義する。

3)

プロジェクトの期待される目標,目的,成果を識別する。

4)

プロジェクト目標及び目的の達成に向けた資源を識別し,割り当てる。

5)

プロジェクトによって管理又は支援されなければならない複数のプロジェクト間のインタフェース

及び依存関係を識別する。

注記  このことは,二つ以上のプロジェクトによって使われるイネーブリングシステムの使用及

び二つ以上のプロジェクトによって使われる共通システム要素の使用を含む。

6)

プロジェクトの実行を統治するプロジェクト報告の要求事項及びレビューのマイルストーンを明示

する。

7)

技術的な計画を含む,承認済みプロジェクト計画の実行を開始する権限をプロジェクトに与える。

b)

プロジェクトポートフォリオの評価

このアクティビティは,次のタスクからなる。

1)

進行中のプロジェクトを評価し,次の項目を確認する。

1.1)

プロジェクトは,確立された目標及び目的の達成に向かって進展している。

1.2)

プロジェクトは,プロジェクト指示書を遵守している。

1.3)

プロジェクトは,システムライフサイクル方針,プロセス及び手順に従って実行されている。

1.4)

プロジェクトは,存続可能である。それは,例えば,サービスの継続的ニーズ,実用的な製品の

実装,受入れ可能な投資利益などで示されている。

2)

満足に進展しているか又は適切な軌道修正によって満足に進展すると期待できるプロジェクトを,

継続するか又は軌道修正を行う。


25

X 0170

:2013 (ISO/IEC 15288:2008)

c)

プロジェクトの終結

このアクティビティは,次のタスクからなる。

1)

合意によって取消し又は中断することが認められている場合には,組織が被る不利益又はリスクが

継続投資の便益を上回るプロジェクトを,取り消すか又は中断する。

2)

製品及びサービスの合意が完了した後,

組織は,

組織の方針及び手順並びに合意に基づいてプロジェ

クトを終了する。

注記  プロジェクトの終了は,プロジェクト終了後に組織による文書保存が行われることを確実

にする。

6.2.4

人的資源管理プロセス

6.2.4.1

目的

人的資源管理プロセスは,組織に必要な人的資源を提供し,事業ニーズに見合った能力を要員が維持す

ることを確実にすることを目的とする。

このプロセスは,組織,プロジェクト及び顧客の目的を達成するために,ライフサイクルプロセスを実

行する資格のある,スキル及び経験のある要員の供給を行う。

6.2.4.2

成果

人的資源管理プロセスの実施に成功すると次の状態になる。

a)

プロジェクトによって必要とされるスキルが識別される。

b)

プロジェクトに必要な人的資源が供給される。

c)

要員のスキルが,開発され,維持され,又は強化される。

d)

複数プロジェクト間の資源要求の競合が解決される。

e)

個々の知識,情報及びスキルが,組織を通じて収集され,共有され,再利用され,改善される。

6.2.4.3

アクティビティ及びタスク

組織は,人的資源管理プロセスに関して,該当する組織の方針及び手順に従って,次のアクティビティ

及びタスクを実施する。

a)

スキルの識別

このアクティビティは,次のタスクからなる。

1)

現在及び予期されるプロジェクトに基づくスキルのニーズを識別する。

2)

要員のスキルを識別し,記録する。

b)

スキルの開発

このアクティビティは,次のタスクからなる。

1)

スキルの開発計画を確立する。

注記  この計画は,訓練の種類及び水準,要員の区分,スケジュール,資源の要求事項及び訓練

のニーズを含む。

2)

訓練,教育又は個人指導を行う資源を入手するか又は開発する。

注記  これらの資源は,組織又は外部当事者によって開発される教材,外部の供給者から提供さ

れる訓練コース,コンピュータ使用の個別学習などを含む。

3)

計画されたスキル開発を手配する。

4)

スキル開発の記録を維持する。

c)

スキルの取得及び提供


26

X 0170

:2013 (ISO/IEC 15288:2008)

このアクティビティは,次のタスクからなる。

注記  このアクティビティは,次を含む。

−  プロジェクトの適切な要員配備に必要な経験の水準及びスキル(技術)を備えた人員の

採用及びその保持

−  例えば,熟練度,やる気,チーム環境で働く力,さらに,再訓練,配置転換又は再配置

のニーズなど要員のアセスメント及びレビュー

1)

スキルの欠陥が計画に基づいて識別されたときは有資格の要員を入手する。

注記  これには外部委託先の人的資源を含む。

2)

進行中のプロジェクトに配置するのに必要なスキルのある要員をリストアップし,そのリストを維

持し管理する。

3)

プロジェクト及び要員開発のニーズに基づいてプロジェクトの配属を行う。

4)

例えば,キャリア開発及び報奨制度によって,要員を動機づける。

5)

複数プロジェクト管理インタフェースを制御して,次のような複数プロジェクト間のスケジュール

の問題を解決する。

5.1)

組織インフラストラクチャ内の容量並びに進行中のプロジェクト間での支援サービス及び資源に

関する問題

5.2)

プロジェクト要員への限度を超えた割当てに関する問題

d)

知識管理の遂行

このアクティビティは,次のタスクからなる。

1)

組織全体の共通的及び領域の情報を共有するインフラストラクチャを確立し,維持する。

2)

適切な知識管理戦略を選択する。

3)

戦略ごとに組織によってアクセスされる情報を把握し,維持する。

6.2.5

品質管理プロセス

6.2.5.1

目的

品質管理プロセスは,製品,サービス及びライフサイクルプロセスの実施が組織の品質目標に合致し,

顧客満足を達成することを保証することを目的とする。

6.2.5.2

成果

品質管理プロセスの実施が成功すると次の状態になる。

a)

組織の品質管理方針及び手順が定義されている。

b)

組織の品質の目標が定義されている。

c)

品質管理の説明責任及び権限が定義されている。

d)

顧客満足の状態が監視されている。

e)

品質目標が達成されないときには適切な処置がとられている。

6.2.5.3

アクティビティ

組織は,品質管理プロセスに関して,該当する組織の方針及び手順に従って,次のアクティビティ及び

タスクを実施する。

a)

品質管理の計画

このアクティビティは,次のタスクからなる。

1)

品質管理の方針,標準及び手順を確立する。


27

X 0170

:2013 (ISO/IEC 15288:2008)

注記 1  品質管理システムのプロセスモデルは,JIS Q 9001:2000 で参照可能である。JIS Q 

9001:2000

を超えて,性能の継続的改善の追及を望む組織は,JIS Q 9004:2000 に掲載さ

れている指針を参照。

注記 2  JIS Q 9001:2000 は 2008 年版が,JIS Q 9004:2000 は 2010 年版が発行されている。

2)

顧客満足に対する業務戦略に基づき,組織の品質管理目標を確立する。

3)

品質管理実施のための責任及び権限を定義する。

b)

品質管理のアセスメント

このアクティビティは,次のタスクからなる。

1)

顧客満足度を調査し,報告する。

注記  この規格の実施によって,顧客満足を達成する進め方を得ることができる。

2)

プロジェクトの品質計画の定期的なレビューを行う。

注記  利害関係者要求事項に基づく品質目標が各プロジェクトに対して確立されていることを保

証する。

3)

製品及びサービスの品質改善状態を監視する。

c)

品質管理の是正措置の実施

このアクティビティは,次のタスクからなる。

1)

品質管理目標が達成されないときは是正措置を計画する。

2)

是正措置を実施し,結果を組織全体に伝達する。

6.3

プロジェクトプロセス

プロジェクトプロセスは,プロジェクト計画を確立し進展させ,プロジェクト計画を実行し,計画に対

する実績及び進捗のアセスメントを行い,プロジェクトの実行を達成するまで,制御するために用いられ

る。個々のプロジェクトプロセスは,プロジェクト計画又は予期せぬイベントによって必要とされれば,

ライフサイクルのどの時点でも,また,プロジェクトの従属するどのレベルにおいても呼び出してよい。

プロジェクトプロセスを,プロジェクトのリスク及び複雑性に従属する厳密さ及び形式で適用する。

プロジェクトプロセスは,二つの区分に分けられる。それらは,プロジェクト管理プロセス及びプロジェ

クト支援プロセスである。これらのプロセスの区分は,次のプロセスからなる。

注記  プロジェクトプロセスは,より細かな区分に分けられていても,

“技術的でないプロセス”の単

なる集合に過ぎず,プロジェクトの責任範囲内で実行される。そのプロジェクトプロセスとは,

システム特有なテクニカルプロセスが効果的に実行されるように定義される必要がある。この

二つのプロセスは,プロジェクト管理の包括的集合と解釈されないことが望ましく,このこと

は,この規格の適用範囲外である。

a)

プロジェクト管理プロセス

この区分は,次のプロセスからなる。

1)

プロジェクト計画プロセス

2)

プロジェクトアセスメント及び制御プロセス

b)

プロジェクト支援プロセス

この区分は,次のプロセスからなる。

1)

意思決定管理プロセス

2)

リスク管理プロセス

3)

構成管理プロセス


28

X 0170

:2013 (ISO/IEC 15288:2008)

4)

情報管理プロセス

5)

測定プロセス

プロジェクト管理プロセス(計画,並びにアセスメント及び制御)は,あらゆる管理実践の鍵となって

いる。これらのプロセスは,プロジェクト又はプロセスを管理するための一般的な進め方を確立する。プ

ロジェクト支援プロセスは,特定化した管理目標を実施するために特定の焦点を当てた一組のタスクを提

供する。それらは,組織全体から単一ライフサイクルプロセス及びそのタスクに至るまでのあらゆる取組

の管理において全て明らかである。この規格においては,プロジェクト(という言葉を選んだの)は,計

画,実行並びにアセスメント及び制御に関係したプロセスを記述するためである。

6.3.1

プロジェクト計画プロセス

6.3.1.1

目的

プロジェクト計画プロセスは,効果的で実行可能なプロジェクト計画を作成し,伝達することを目的と

する。

このプロセスは,プロジェクト管理及び技術的活動の範囲を決定し,プロセスの出力,プロジェクトの

タスク及び納入物を識別し,達成基準を含むプロジェクトのタスク実施のスケジュール及びプロジェクト

のタスクを達成するために必要な資源を確立する。

6.3.1.2

成果

プロジェクト計画プロセスの実施が成功すると次の状態になる。

a)

プロジェクト計画が利用できる。

b)

役割,責任,説明責任及び権限が定義されている。

c)

プロジェクト目標を達成するのに必要な資源及びサービスが正式に依頼され,確約されている。

d)

プロジェクト要員は,プロジェクト計画に従って方向付けられている。

e)

プロジェクト実行のための計画が作成されている。

6.3.1.3

アクティビティ及びタスク

プロジェクトは,計画プロセスに関して,該当する組織の方針及び手順に従って,次のアクティビティ

及びタスクを実施する。

a)

プロジェクトの定義

このアクティビティは,次のタスクからなる。

1)

プロジェクト目標及び制約条件を識別する。

注記  目標及び制約条件は,性能及び他の品質側面,コスト,時間並びに利害関係者の満足を含

む。各目標は,適切なプロセス及びアクティビティの選定,修整及び実施が可能な程度の

詳細に識別される。

2)

合意において確立されたプロジェクト範囲を定義する。

注記  プロジェクトには,業務意思決定基準を満たしプロジェクトを成功裏に完了させるのに必

要な全ての関連アクティビティを含む。プロジェクトは,完全なシステムライフサイクル

の一つ以上の段階の責任をもつことができる。計画には,プロジェクト計画を維持し,ア

セスメントを実施し,プロジェクトを制御するための適切な行動を含む。

3)

組織の定義されたライフサイクルモデルを用いた段階から構成されるライフサイクルモデルを定義

し,維持する。

4)

進化するシステム体系に基づき作業構成明細(Work Breakdown Structure,WBS)を確立する。


29

X 0170

:2013 (ISO/IEC 15288:2008)

注記  システム体系の各要素並びに適切なプロセス及びアクティビティは,識別されたリスクと

同じ水準の詳細さで記述される。作業構成明細における関連タスクは,組織の責任に応じ

てプロジェクトタスクにグループ分けされる。プロジェクトのタスクは,開発又は生成さ

れる全ての作業項目及びその関連タスクを識別する。

b)

プロジェクト資源の計画

このアクティビティは,次のタスクからなる。

1)

プロジェクト目標及び作業見積に基づいてプロジェクトスケジュールを定義し維持する。

注記  これは,プロジェクトの適時の完了を達成するために必要なプロジェクトアクティビティ,

達成のマイルストーン,使用資源並びにリスク管理のためのレビュー及びリスク管理を考

慮したスケジュールの確保についての期間,関係,依存性及び順序の定義を含む。

2)

ライフサイクル段階決定ゲート,納入日及び外部入出力への主要依存性に対するプロジェクト達成

基準を定義する。

注記  内部プロジェクトレビューの時間間隔は,業務及びシステムの重要性,スケジュール並び

に技術的リスクといった問題に対する組織の方針に従って定義される。

3)

プロジェクトコストを定義し,予算を計画する。

注記  コストは,例えば,プロジェクトスケジュール,作業量見積,インフラストラクチャコス

ト,購入品目,取得したサービス及びイネーブリングシステム見積並びにリスク管理のた

めに確保された予算に基づく。

4)

プロジェクト作業のための権限及び責任の体制を確立する。

注記  これは,プロジェクトの組織,要員の確保,要員スキル(技術)の開発及びチーム作業の

手法の定義を含む。責任は,人的資源の効果的利用を含み,システムライフサイクルの全

ての段階に貢献する組織の機能を生かす。法的に責任ある役割及び個人に権限構造が,例

えば,設計の認可,安全性の認可,証明書又は認定の判定など法的に責任ある役割及び個

人を適宜含む体制構造が選定される。

5)

プロジェクトに必要なインフラストラクチャ及びサービスを定義する。

注記  これは,必要な能力,その可用性及びプロジェクトタスクへの割当てを含む。さらに,施

設,ツール及び情報通信技術資産を含む。プロジェクトの範囲内の各ライフサイクル段階

に対するイネーブリングシステムの要求事項も指定する。

6)

プロジェクトの外部から供給される原材料,物品及びイネーブリングシステムサービスの取得を計

画する。

注記  これは,必要ならば,要請,供給元選定,受入れ,契約管理及び契約締結の計画を含む。

合意プロセスは,計画された取得に使われる。

c)

プロジェクトの技術管理及び品質管理

このアクティビティは,次のタスクからなる。

1)

レビューも含めてプロジェクトの技術管理及びプロジェクトの実行のための計画を作成し伝達する。

2)

プロジェクト品質計画を作成する。

注記  これは,組織の品質管理方針及び手順が達成されることを保証するプロジェクト品質目標

の定義及び文書化を含む。JIS Q 9001:2000 又は他の品質規格に従って計画する。

d)

プロジェクトの起動

このアクティビティは,次のタスクからなる。


30

X 0170

:2013 (ISO/IEC 15288:2008)

1)

プロジェクトに対する承認を得る。

2)

プロジェクトの実施に必要な資源を要求し,確約を得る。

3)

プロジェクトを統括して,その目的及び基準の集合を満たすためにプロジェクト計画の実施を開始

する。

6.3.2

プロジェクトアセスメント及び制御プロセス

6.3.2.1

目的

プロジェクトアセスメント及び制御プロセスは,プロジェクトの状態を決定すること及びプロジェクト

計画実行を方向付け,プロジェクトが計画及びスケジュールに従って予測された予算内で遂行され,技術

目標を満足することを確実にすることを目的とする。

このプロセスには,定期的に及び主要な出来事において,要求事項,計画及び全体的業務目標に対する

進捗及び達成を評価する。大きな差異が検出されたとき,情報は,管理活動のために伝達される。

このプロセスには,他のプロジェクト管理プロセス又は技術プロセスから既知の差異又はばらつきを是

正するため,必要に応じて,プロジェクトアクティビティ及びタスクを,軌道修正することも含む。軌道

修正には,必要に応じて,再計画を含んでもよい。

6.3.2.2

成果

プロジェクトアセスメント及び制御プロセスの実施に成功すると次の状態になる。

a)

プロジェクト遂行能力の測定値又はアセスメントの結果が利用できる。

b)

役割,責任,説明責任,権限並びにプロジェクトの達成に必要な資源及びサービスの適切さのアセス

メントが行われている。

c)

プロジェクト遂行能力指標における偏りが分析されている。

d)

影響を受ける当事者にプロジェクトの状態が知らされている。

e)

プロジェクト達成度が計画目標を満足しないとき,是正処置を定義し,実行を指示する。

f)

プロジェクト目標若しくは制約が変更されたとき,又は計画の前提が正しくないことが示されたとき

には,プロジェクト再計画が開始される。

g)

あるスケジュールされたマイルストーン又は出来事から次へ進める(又は進めない)というプロジェ

クト行動が承認されている。

h)

プロジェクト目標が達成される。

6.3.2.3

アクティビティ

プロジェクトは,プロジェクトアセスメント及び制御プロセスに関して,該当する組織方針及び手順に

従って,次のアクティビティ及びタスクを実施する。

a)

プロジェクトのアセスメント

このアクティビティは,次のタスクからなる。

1)

コスト,スケジュール及び品質の実績と計画との差異を決定するために,適切なプロジェクト計画

に対するプロジェクト状態のアセスメントを行う。

2)

プロジェクト計画に従って品質保証を実施する。

3)

プロジェクトチーム構成,役割,責任,説明責任及び権限の有効性のアセスメントを行う。

注記  これには,プロジェクトの役割を担いプロジェクトのタスクを達成するためのチーム要員

の力量の適切さのアセスメントを含む。可能な場合はいつでも,例えば,資源利用効率,

プロジェクト達成度などの客観的測定量を使う。

4)

プロジェクトの支援インフラストラクチャの適切さ及び可用性のアセスメントを行う。


31

X 0170

:2013 (ISO/IEC 15288:2008)

注記  これには,組織内の約束事が満足されていることの確認を含む。

5)

測定した達成度及びマイルストーン完了を用いてプロジェクト進捗のアセスメントを行う。

注記  計画した時期に労務費,原材料費及びサービス費の実績又は推定を収集し評価する。定義

されたプロジェクトの達成度を表す測定量と比較する。これには,要求事項に対する作成

中のシステムの適切さを決定するため,有効性のアセスメントの実施を含む。さらに,必

要なときにサービスを提供するイネーブリングシステムの準備ができていることを含む。

6)

システムライフサイクル又はプロジェクトのマイルストーンの次の段階に進む準備ができているか

どうかを決定するために必要な管理レビュー及び技術レビュー,監査並びに検査を実施する。

7)

重大なプロセス及び新技術を監視する。

注記  これには,プロジェクト計画に従って,技術が組み入れられたかどうかの識別及び評価を

含む。

8)

計画された値又は状態からの逸脱又はばらつきを識別するため,測定結果を分析し,是正のための

適切な勧告を行う。

注記  これには,適切な場合には,傾向を示す測定値の統計的分析を含む。測定値には,例えば,

成果物の品質を示す欠陥密度,プロセス反復可能性を示す測定されたパラメタの分布など

がある。

9)

合意,方針及び手順において指定された定期的な状況報告書及び必要な逸脱報告書を提供する。

b)

プロジェクトの制御

このアクティビティは,次のタスクからなる。

1)

プロジェクト計画に従ってプロジェクト要求事項及び要求事項への変更を管理する。

2)

許容可能な範囲又は定義された範囲から逸脱したプロジェクトタスクに対して,目標及び成果を達

成するために必要な是正処置を開始する。

注記  是正処置には,不適切さ又は非可用性が検出された場合,人員,ツール及びプロジェクト

インフラストラクチャ資産の再計画又は再配備及び再割当てを含んでもよい。

3)

プロジェクトの目標及び成果の達成を確実にするために予防措置を適宜起こす。

4)

不適合事項を是正するために問題解決行動を開始する。

注記  これには,不適合がライフサイクルプロセスの実施及び実行まで追跡された場合に,それ

らに対する是正処置の実施を含む。是正処置は,その適切さ及び適時性を確認するために

文書化され,レビューされる。

5)

実施することを決定した是正処置及び是正によってもたらされる変更量の見積に対応して,プロ

ジェクトによって実行される作業の範囲,定義及び関連した作業項目を時間とともに展開する。

6)

取得者又は供給者の依頼の影響で,コスト,時間又は品質について契約変更があった場合,変更行

動を開始する。

7)

供給者との建設的なやり取りを通じて,取得品及びサービスの欠陥を是正するよう働きかける。

注記  これには,供給の諸条件修正の考慮又は新しい供給者の選定開始を含めてもよい。

8)

正当な理由がある場合は,次のマイルストーン又は出来事に向かって進行することをプロジェクト

に許可する。

c)

プロジェクトの終結

このアクティビティは,次のタスクからなる。

1)

全てのアクティビティ及びタスクが完了したとき,合意に指定されている基準又は組織の手順の一


32

X 0170

:2013 (ISO/IEC 15288:2008)

部としての基準を考慮に入れて,プロジェクトが完了したかどうかを決定する。

2)

合意に指定されたように適切な環境に結果及び記録を収納する。

6.3.3

意思決定管理プロセス

6.3.3.1

目的

意思決定管理プロセスは,代替手段が存在する場合に,プロジェクト行動の最も有利な進路を選定する

ことを目的とする。

このプロセスは,指定された,望ましい成果又は最適の成果に到達するために,特質又は発生源が何で

あっても,システムライフサイクルの間に遭遇した意思決定の要求に応えることである。取り得る複数の

行動を分析し,行動方針を選定し,指示する。決定及びその論理的根拠は,将来の意思決定を支援するた

めに,記録する。

6.3.3.2

成果

意思決定管理プロセスの実施に成功すると次の状態になる。

a)

意思決定管理の戦略が定義されている。

b)

行動の代替案が定義されている。

c)

代替案の中から好ましい行動が選定されている。

d)

その解決,意思決定の論理的根拠及び前提が把握され,報告されている。

6.3.3.3

アクティビティ

プロジェクトは,意思決定管理プロセスに関して,該当する組織の方針及び手順に従って,次のアクティ

ビティ及びタスクを実施する。

a)

意思決定の計画及び定義

このアクティビティは,次のタスクからなる。

1)

意思決定管理の戦略を定義する。

注記  意思決定管理の戦略は,意思決定並びに意思決定のカテゴリ及び優先順位の付け方の識別

に対する責任及び行う権限を明確にして,割り当てることを含む。次の結果として意思決

定がなされる。

−  有効性のアセスメント

−  技術的トレードオフ

−  解決する必要がある問題

−  容認可能なしきい(閾)値を上回るリスクへの対応としての必要な行動

−  次のライフサイクル段階へプロジェクトを進めるための新しい機会又は承認

意思決定の分析に適用される厳密さ及び形式の度合いは,組織又はプロジェクトの

指針に従って決めることが望ましい。

2)

意思決定の状況及びニーズを識別する。

注記  問題又は機会及びそれらの結果を解決する行動の取り得る複数の進路を記録し,分類し,

速やかにかつ客観的に報告する。

3)

経験及び知識を生かすために関連する当事者を意思決定に参加させる。

b)

意思決定の情報を分析

このアクティビティは,次のタスクからなる。

1)

それぞれの決定状況に対して意思決定管理の戦略を選定し,表明する。

2)

望まれる結果及び測定可能な達成基準を識別する。


33

X 0170

:2013 (ISO/IEC 15288:2008)

3)

識別された決定状況の最適化又は改善を達成するために,定義済みの意思決定戦略を使って,代替

行動の影響の大きさの差異を評価する。

c)

意思決定の追跡

このアクティビティは,次のタスクからなる。

1)

問題が効果的に解決されており,望ましくない傾向が改善されており,機会を生かしていることを

確認するために,意思決定の結果を記録し,追跡し,評価し,報告する。

2)

合意又は組織の手順に定められているように,かつ,監査及び経験学習を可能にするやり方で,問

題及び機会並びにそれらの決着についての記録を保存する。

6.3.4

リスク管理プロセス

6.3.4.1

目的

リスク管理プロセスは,リスクを継続的に識別し,分析し,取り扱い,監視することを目的とする。

リスク管理プロセスは,システム製品又はシステムサービスを通して,リスクに系統的に対応する継続

的プロセスである。それは,システムの取得,開発,保守又は運用に関連したリスクに適用できる。

6.3.4.2

成果

リスク管理プロセスの実施に成功すると次の状態になる。

a)

リスク管理プロセスの範囲が決定されている。

b)

適切なリスク管理戦略が定義され,実施されている。

c)

リスクは,発生の都度及びプロジェクトの遂行の間に識別されている。

d)

リスクは,分析され,これらのリスクの取扱いに資源を適用する優先度が決められている。

e)

リスク測定量が,リスクの状態の変化及びリスクに対して取った処置の進捗を判断するために,定義

され,適用され,アセスメントされている。

f)

優先度,確率及び重大さ,又は他の定義されたリスクのしきい(閾)値に基づいて,リスクの影響を

是正又は回避するために,適切な処置がなされている。

6.3.4.3

アクティビティ及びタスク

プロジェクトは,リスク管理プロセスに関して,該当する組織の方針及び手順に従って,次のアクティ

ビティ及びタスクを実施する。

注記  JIS X 0162:2008 は,次に示されたアクティビティ及びタスクに対応するアクティビティ及びタ

スクのより細かい集合を記述している。

a)

リスク管理の計画

このアクティビティは,次のタスクからなる。

1)

リスク管理方針を定義する。

2)

実施されるリスク管理プロセスを文書化する。

3)

責任ある当事者並びにその役割及び責任を識別する。

4)

責任ある当事者にリスク管理を行うのに適切な資源を提供する。

5)

リスク管理プロセスを評価し,改善するプロセスを定義する。

注記  このタスクには,経験から学んだ教訓も含まれる。

b)

リスクプロファイルの管理

このアクティビティは,次のタスクからなる。

1)

リスク管理プロセスの文脈を定義し,文書化する。

注記  これには,利害関係者の視点,リスクの種類,並びに技術的及び管理上の目標,仮定及び


34

X 0170

:2013 (ISO/IEC 15288:2008)

制約条件の記述(おそらく参照することによって)を含む。

2)

リスクのレベルが受け入れられるリスクしきい(閾)値及び条件を定義し,文書化する。

3)

リスクプロファイルを確立し,維持する。

注記  リスクプロファイルには,次を記録する。

−  リスク管理の背景

−  発生確率,重大さ及びリスクしきい(閾)値を含む各リスクの状態の記録

−  利害関係者から提供されたリスク基準に基づく各リスクの優先度

−  それらの処置状態に応じたリスク対応行動の要請

リスクプロファイルは,個々のリスクの状態に変化があったとき更新される。リス

クプロファイルの中の優先度は,処置のための資源の適用を決めるのに使用する。

4)

関連するリスクプロファイルは,ニーズに基づき定期的に利害関係者に伝達される。

c)

リスクの分析

このアクティビティは,次のタスクからなる。

1)

リスク管理の関連に記述された種類別に識別する。

2)

識別した各リスクの発生確率及び影響を見積もる。

3)

各リスクをリスクしきい(閾)値に対して評価する。

4)

リスクしきい(閾)値を超える各リスクに対し,推奨する処置の戦略を定義し,文書化する。処置

の代替案の有効性を示す測定量を定義し,文書化する。

注記  リスク処置の戦略は,リスクの除去,発生の確率若しくは影響度の減少,又はリスクの容

認を含むが,これらに限定されない。

d)

リスクの処置

このアクティビティは,次のタスクからなる。

1)

リスク行動の要請の中にリスク処置のための推奨される代替手段を利害関係者に提供する。

2)

利害関係者がリスクを容認可能にするために行動することが望ましいと決定した代替案を実施す

る。

3)

利害関係者がしきい(閾)値を超えるリスクを容認する場合,そのリスクは,優先度が高いとみな

され,継続的に監視されて,その後のリスク処置行動が必要かどうかを判断する。

4)

リスク処置が決まると,この規格の 6.3.2.3 に規定されたアセスメント及び制御アクティビティに

従って,管理行動を確実にする。

e)

リスクの監視

このアクティビティは,次のタスクからなる。

1)

変更に対する全てのリスク及びリスク管理状況を継続的に監視し,リスクの状態が変化したときに

リスクを評価する。

2)

リスク処置の有効性を評価するための手段を実施し,監視する。

3)

ライフサイクルを通して,新しいリスク及び発生源を継続的に監視する。

f)

リスク管理プロセスの評価

このアクティビティは,次のタスクからなる。

1)

ライフサイクルを通して,リスク管理プロセスを改善し,得られた教訓を把握する目的でリスク情

報を収集する。

注記  リスク情報は,識別されたリスク,発生源,原因,処置,及び選択された処置の成否を含


35

X 0170

:2013 (ISO/IEC 15288:2008)

む。

2)

有効性及び効率について,リスク管理プロセスを定期的にレビューする。

3)

プロジェクト及び組織の制度的リスクを識別する目的で,識別されたリスク,それらに対する処置

及びその処置の成否に関するリスク情報を定期的にレビューする。

6.3.5

構成管理プロセス

6.3.5.1

目的

構成管理プロセスは,プロジェクト又はプロセスの全ての識別されたアウトプットの完整性(integrity)

を確立し,維持し,関係する当事者が利用できるようにすることを目的とする。

6.3.5.2

成果

構成管理プロセスの実施に成功すると次の状態になる。

a)

構成管理戦略が定義されている。

b)

構成管理を必要とする品目が定義されている。

c)

構成の基準線が確立されている。

d)

構成管理下の品目の変更が制御されている。

e)

リリースされた品目の構成が制御されている。

f)

構成管理下の品目の状態が,ライフサイクルを通して知ることができるようになっている。

6.3.5.3

アクティビティ及びタスク

プロジェクトは,構成管理プロセスに関して適用可能な組織の方針及び手順に従って次のアクティビ

ティ及びタスクを実施する。

a)

構成管理の計画

このアクティビティは,次のタスクからなる。

1)

構成管理戦略を定義する。

注記  これには,次のことを含む。

−  構成品目の解除,アクセス,リリース及び変更の制御の権限を定義する。

−  明示されたリスク抑制のための完整性(integrity)レベル,セキュリティレベル及び安

全性レベルに従って,保管場所及び保管条件,それらの環境並びに情報の場合は保管

媒体について定義する。

−  構成制御を始めるための,及び進化する構成の基準線を維持するための基準又は事象

を定義する。

−  構成定義情報の連続的なリスク抑制のための完整性(integrity)及びセキュリティを確

実にするための監査戦略及び責任を定義する。

構成管理のアクティビティに関する追加の指針は,ISO 10007 に見られる。

2)

構成制御の対象となる品目を識別する。

注記  品目は,適切な場合に,一意で,永続性のある識別子又は印によって区別される。識別子

は,構成制御下でその品目がそれらの仕様書又は同等の記述物に,明白に追跡できるよう

に,関連する標準及び製品分野の規則に従っている。

b)

構成管理の実施

このアクティビティは,次のタスクからなる。

1)

完整性(integrity)及びセキュリティの適切なレベルで,構成に関する情報を維持する。

注記  これは,構成制御下の品目の性格を考慮することを含む。構成記述は,可能な場合に,製


36

X 0170

:2013 (ISO/IEC 15288:2008)

品又は技術標準に適合する。構成情報が,他の基準線の構成の状態への前後の追跡ができ

ることを確認する。指示された時間又は定義された状況下で文書化された基準線を作成す

るために,構成品目の進化している構成状態を統合する。基準線のための論理的根拠及び

関連する認可を構成基準線のデータに記録する。合意,関連する法令又は業界のベストプ

ラクティスに従って,システムライフサイクルを通して構成記録を維持し,保管する。

2)

構成基準線への変更が適切に識別され,記録され,評価され,承認され,取り入れられ,かつ,検

証されることを確実にする。

注記  指定された時期又は定義された状況下で,構成品目の進化している構成状態を統合して,

文書化された基準線を形成する。構成基準線のデータに,構成のステップ,基準線のため

の論理的根拠及び関連する認可を記録する。合意,関連する法令又は業界のベストプラク

ティスに従って,システムライフサイクルを通して構成記録を維持し,保管する。情報の

正確さ,適時性,リスク抑制のための完整性(integrity)及びセキュリティを確認するため,

現在の構成状況及び以前の全ての構成の状況が記録され,検索され,かつ,統合されてい

ることを管理する。監査をして,図面,インタフェース制御資料及び他の合意された要求

事項に対する基準線との適合性を検証する。

6.3.6

情報管理プロセス

6.3.6.1

目的

情報管理プロセスは,システムライフサイクルの期間中及び必要に応じてシステムライフサイクルの後

に,指定された当事者に,関連する,適時の,完全な,有効な,かつ,必要ならば,機密の,情報を与え

ることを目的とする。

このプロセスは,情報を生成し,収集し,変換し,保持し,検索し,配信し,処分する。

このプロセスは,技術情報,プロジェクト情報,組織の情報,合意情報及び利用者情報を含む指定され

た情報を管理する。

6.3.6.2

成果

情報管理プロセスの実施に成功すると次の状態になる。

a)

管理すべき情報が識別されている。

b)

情報の表現の形式が定義されている。

c)

情報は,変換され,要求に応じて処分されている。

d)

情報の状況が記録されている。

e)

情報は,最新で,完全でかつ有効になっている。

f)

情報は,指定された当事者が利用できるようになっている。

6.3.6.3

アクティビティ及びタスク

プロジェクトは,情報管理プロセスの観点から,適用可能な組織の方針及び手順に従って次のアクティ

ビティ及びタスクを実施する。

a)

情報管理の計画

このアクティビティは,次のタスクからなる。

1)

組織の方針,合意又は法令に従って,システムライフサイクルの間に管理され,それ以降の定義さ

れた期間で,維持される情報の項目を定義する。

2)

情報の項目の発生,世代,把握,保管及び廃棄に関連しての権限及び責任を明示する。

3)

情報項目の保有,伝達及びアクセスに関連する権利,義務及びコミットメントを定義する。


37

X 0170

:2013 (ISO/IEC 15288:2008)

注記  情報及びデータに関する法令,セキュリティ及びプライバシ(例えば,所有権,合意条件,

アクセス権,知的財産及び特許)に対し,当然の配慮を払う。条件又は制約が当てはまれ

ば,情報は,それに応じて識別される。情報のこのような項目の知識をもっている要員は,

義務及び責任を通知される。

4)

情報の表現,保有,伝達及び検索のための内容,意味論,形式及び媒体を定義する。

注記  情報は,どのような形式(例えば,口頭,テキスト,図表,数字)で発生及び終了しても

よい。そして,どのような媒体(例えば,電子媒体,印刷物,磁気媒体,光媒体)にも蓄

えられ,加工され,複製され,伝達されてもよい。組織の制約(例えば,基盤構造,組織

間のコミュニケーション,分散プロジェクト作業)に対して当然の配慮を払う。関連情報

の保管,変換,伝達及び表示の標準及び表示の慣例は,方針,合意及び法令の制約に従っ

て使われる。

5)

情報維持活動を定義する。

注記  これは,リスク抑制のための完整性(integrity),妥当性及び利用可能性に対して蓄えられ

た情報並びに代替媒体への複製又は変換に対するニーズに対しての状態レビューを含む。

技術の変更があっても,保管された媒体を読むことができるように,基盤を保持するニー

ズ又は新しい技術を利用して保管した媒体を再度記録するニーズのいずれかを考慮する。

b)

情報管理の実施

このアクティビティは,次のタスクからなる。

1)

情報の識別された項目を得る。

注記  これは,情報の生成又は適切な発生源からの収集を含んでもよい。

2)

リスク抑制のための完整性(integrity)

,セキュリティ及びプライバシの要求事項に従って,情報項

目及びこれらの保管記録を維持する。

注記  情報項目の状態,例えば,改訂の記述,配布記録,セキュリティ区分を記録する。情報は,

容易に読めるもので,ふさわしい環境を提供し,損害,劣化及び損失を防止する設備に,

すぐに取り出せる方法で,蓄えられ,保持されることが望ましい。

3)

合意されたスケジュール又は定義された状況によって要求されたときに,指定された当事者に対し

て,情報を検索し配布する。

注記  指定された当事者に対して適切な形式で情報が提供される。

4)

要求されたときに公式の文書を提供する。

注記  公式の文書の例は,認定,認可,ライセンス及びアセスメント評定である。

5)

監査,知識保有及びプロジェクト終結の目的に従って,指定された情報を保管する。

注記  指定された保管及び検索期間並びに組織の方針,合意及び法令に従って,情報の媒体,場

所及び保護を選定する。プロジェクト終結後必要な文書を保管する取決めが存在すること

を確実にする。

6)

組織の方針並びにセキュリティ及びプライバシの要求事項に従って,不必要な,妥当でない又は検

証不可の情報を処分する。

6.3.7

測定プロセス

6.3.7.1

目的

測定プロセスは,プロセスの効果的管理を支援し,製品の品質を客観的に示すために,組織内で開発さ

れる製品及び実施されるプロセスに関するデータの収集,分析及び報告を目的とする。


38

X 0170

:2013 (ISO/IEC 15288:2008)

6.3.7.2

成果

測定プロセスの実施に成功すると次の状態になる。

a)

技術的及び管理プロセスの情報ニーズが識別されている。

b)

情報ニーズから生じる尺度の適切な集合の識別及び/又は開発が行われている。

c)

測定アクティビティが識別され,計画されている。

d)

必要なデータが収集され,蓄えられ,分析され,かつ,結果が解釈されている。

e)

情報伝達のための意思決定を支援し,目標の基礎を提供するのに情報製品が使われている。

f)

測定プロセス及び尺度が評価されている。

g)

改善が測定プロセスの所有者に伝達されている。

6.3.7.3

アクティビティ及びタスク

プロジェクトは,

測定プロセスの観点から,

適用可能な組織の方針及び手順に従って次のアクティビティ

及びタスクを実施する。

注記 1  JIS X 0141 は,次に示されるアクティビティ及びタスクと連係したアクティビティ及びタス

クのより細かい集合を記述している。

注記 2  JIS Q 9001:2000 の 8.はプロセス及び製品の測定及び監視のための品質管理システム要求事項

を規定している。

a)

測定の計画

このアクティビティは,次のタスクからなる。

1)

測定と関連する組織の性格を記述する。

2)

情報ニーズを識別し,優先順位付けする。

3)

情報ニーズを満たす尺度を選択し,文書化する。

4)

データ収集,分析及び報告手順を定義する。

5)

情報製品及び測定プロセスを評価する基準を定義する。

6)

測定タスクに対する資源をレビューし,承認し,提供する。

7)

支援する技術を取得し,展開する。

b)

測定の実施

このアクティビティは,次のタスクからなる。

1)

データ発生,収集,分析及び関連するプロセスへの報告の手順を統合する。

2)

データを収集し,蓄積し,照合する。

3)

データを分析し,情報製品を開発する。

4)

結果を分析し,測定の利用者に伝達する。

c)

測定の評価

このアクティビティは,次のタスクからなる。

1)

情報製品及び測定プロセスを評価する。

2)

改善の可能性を識別し,伝達する。

6.4

テクニカルプロセス

テクニカルプロセスは,システムに対する要求事項を定義し,その要求事項を効果的な製品に変換し,

必要な場合には製品の一貫した再生産を可能にし,

要求されたサービスを提供する製品を使用し,

そのサー

ビスの提供を持続させ,サービスから撤退するときにはその製品を処分するために利用される。

テクニカルプロセスは,組織の機能及びプロジェクトの機能が利益を最適化できるようにするためのア


39

X 0170

:2013 (ISO/IEC 15288:2008)

クティビティ並びに技術的な決定及び行動から発生するリスクを軽減するためのアクティビティを定義す

る。これらのアクティビティは,製品及びサービスが次のものを備えられるようにする。

−  適時性及び可用性

−  コスト効果性

−  機能性,信頼性,保守性,生産に対する設計の適応性,使用性並びに取得する組織及び供給する組織

によって要求されるその他の品質

また,それらのアクティビティは,製品及びサービスが,健康,安全性,セキュリティ及び環境上の要

因を含めた,社会の期待又は法令の要求事項に適合できるようにする。

テクニカルプロセスは,次に示すプロセスからなる。

a)

利害関係者要求事項定義プロセス

b)

要求事項分析プロセス

c)

方式設計プロセス

d)

実装プロセス

e)

結合プロセス

f)

検証プロセス

g)

移行プロセス

h)

妥当性確認プロセス

i)

運用プロセス

j)

保守プロセス

k)

廃棄プロセス

注記  ソフトウェア及びハードウェアのシステム要素に対して,これらのプロセスは,システム設

計のために下位レベルへ再帰的に適用できるし,システム実現のために上位レベルへ再帰的

に適用できる。そうすることで,利害関係者要求事項定義,要求事項分析,方式設計,結合

及び検証(適格性確認の試験)のための別個の,秩序だった特有のプロセスをもたなくても

よいようにしている。

6.4.1

利害関係者要求事項定義プロセス

6.4.1.1

目的

利害関係者要求事項定義プロセスは,定義された環境において,利用者及び他の利害関係者によって必

要とされるサービスを提供できるように,あるシステムに対して要求を定義することを目的とする。

利害関係者要求事項定義プロセスでは,システムのライフサイクルを通じて,システムに関係している

利害関係者又は利害関係者のクラス並びに彼らのニーズ,期待及び要望を識別する。利害関係者要求事項

定義プロセスでは,これらを分析し,利害関係者要求事項の共通集合に変換する。利害関係者要求事項は,

システムがその運用環境との間にもつ意図された相互作用を表現する。利害関係者要求事項は,システム

がニーズを満たすことを確かめるために,結果として生まれた各運用サービスの妥当性を確認する場合に

参照される。

6.4.1.2

成果

利害関係者要求定義事項プロセスの実施に成功すると次の状態になる。

a)

サービスで要求される特性及びサービスで要求される利用の文脈(内容,状況及び背景)が明示され

ている。

b)

システムソリューションにおける制約が定義されている。


40

X 0170

:2013 (ISO/IEC 15288:2008)

c)

利害関係者要求事項から,利害関係者及び利害関係者ニーズへの追跡可能性が樹立されている。

d)

利害関係者要求事項が定義されている。

e)

妥当性確認のための利害関係者要求事項が識別されている。

6.4.1.3

アクティビティ及びタスク

プロジェクトは,利害関係者要求事項定義プロセスの観点から,適用可能な組織の方針及び手順に従っ

て,次に示すアクティビティ及びタスクを実施する。

a)

利害関係者要求事項引出し

このアクティビティは,次のタスクからなる。

1)

システムのライフサイクルを通じて,システムに正当な関係をもつ個々の利害関係者又は利害関係

者のクラスを識別する。

注記  これには,利用者,運用者,支援者,開発者,製作者,教育訓練者,保守者,廃棄者,取

得者及び供給者の組織,外部とインタフェースをもつ責任ある当事者,規制団体並びに社

会の構成員を含むが,それだけに限定はされない。直接のコミュニケーションが実際的で

ない場合には,代表者又は指名された代理の利害関係者が選定される。例えば,消費者向

けの製品及びサービスでは,マーケティング部門が選定される。

2)

識別された利害関係者から利害関係者要求事項を引き出す。

注記  利害関係者要求事項は,識別された利害関係者のニーズ,欲しい物,望ましい物,期待さ

れる物及び感知した制約といった形態で表現される。利害関係者要求事項は,文章又は形

式的なモデルで表現されてもよい。利害関係者要求事項は,システムの目的及び振る舞い

に焦点を当てたモデル並びに運用上の環境及び条件の文脈で記述されるモデルといった形

態で表現される。例えば,JIS X 0129-1 及び JIS X 25030 にある製品の品質モデルは,この

アクティビティを助けるために役立つ。利害関係者要求事項は,社会によって課されるニー

ズ及び要求,取得する組織によって課される制約並びに運用要員の能力の限界特性を含む。

要請文書又は合意を含む情報源を列挙することが役立つ。可能な場合には,情報源の正当

性及び理論的根拠を列挙し,利害関係者の前提及び彼らが要求事項が満足されることで得

る価値を列挙することが役立つ。重要な利害関係者のニーズについては,有効性の尺度を

定義して,運用上の性能を測定し,アセスメントを行えるようにする。重大なリスクが,

そのシステムのライフサイクルのいずれかの時点において,人間(利用者及び他の利害関

係者)に関する問題(すなわち,ニーズ,欲しい物,制約条件,限界,懸案事項,障害,

要因又は配慮)及びそれらのシステムの中への関与又はシステムとの相互反応から生じる

可能性があるときは,人間対システム問題を識別し,取り扱うための勧告は ISO PAS 18152

に見いだすことができる。

b)

利害関係者要求事項定義

このアクティビティは,次のタスクからなる。

1)

システムソリューション上の制約事項,すなわち,既存の合意,管理上の決定及び技術上の決定の

結果がもたらす不可避な影響を定義する。

注記  これらは,次に示すものから結果としてもたらされる場合がある。

1.1)

利害関係者が定義したソリューションの事例又は領域

1.2)

システム階層構造の上位レベルでなされた実装上の決定

1.3)

定義されたイネーブリングシステム,資源及び要員に対して要求された利用


41

X 0170

:2013 (ISO/IEC 15288:2008)

2)

予想される運用及び支援のシナリオ並びにそれらの環境に合致して,要求される全てのサービスを

識別するために,そのアクティビティの順序の代表的な集合を定義する。

注記  シナリオは,意図された環境におけるシステムの運用を分析するために,かつ,利害関係

者の誰からも公式に明示されていない要求事項,例えば,法規,規制及び社会的な義務を

識別するために利用される。システムの利用の文脈は,識別され,分析される。文脈の分

析の中に,システムの目標を達成するために利用者が行う活動,システムの最終利用者の

関連する特性(例えば,期待される訓練,疲労の程度)

,物理的な環境(例えば,自然光,

温度)及び利用されるいかなる機器(例えば,保護装置,通信機器)も含める。システム

の利用に影響を及ぼす又はその設計を制約する利用者への社会的及び組織的な影響は,適

用できる場合に,分析される。

3)

利用者とシステムとの間の相互作用を識別する。

注記  使用性に対する要求事項は,最小限で,最も効果的,効率的で確実な人間の能力及び人間

対システムの相互作用を確立する要求事項として決定される。可能な場合には,適用可能

な標準,

例えば JIS Z 8512 及び受け入れた専門的な実践が,

次の定義のために用いられる。

3.1)

身体的能力,精神的能力及び学習した能力

3.2)

利用文脈の中の他の装置を含め,仕事場,環境及び施設

3.3)

正常条件,異常条件及び緊急な条件

3.4)

運用者及び利用者の採用,教育訓練及び文化

使用性が重要である場合,使用性の要求事項を計画し,明示し,ライフサイクルプロセスを通

じて実施することが望ましく,次の規格又は技術報告書を適用することができる。

−  JIS Z 8521:1999  人間工学−視覚表示装置を用いるオフィス作業−使用性についての手引

−  JIS Z 8530:2000  人間工学−インタラクティブシステムの人間中心設計プロセス

4)

健康,安全性,セキュリティ,環境及び他の利害関係者要求事項及び重大な品質に関する機能を明

示する。

注記  安全性に対するリスクを識別する。契約で保証されている場合は,安全性を提供するため

の要求事項及び機能を明示する。このリスクには,運用及び支援の方法,健康及び安全性

並びに資産への脅威及び環境への影響に関するリスクを含む。適用可能な標準,例えば,

JIS C 0508

規格群,及び受け入れた専門的な実践を利用する。セキュリティのリスクを識

別する。契約で保証されている場合は,身体,手順,通信,コンピュータ,プログラム,

データ及び排出物質を含め,システムのセキュリティに関する全ての適用可能な領域を明

示する。保護される人員,資産及び情報に対するアクセス及び損傷,機密情報を危うくす

ること並びに資産及び情報に対して認められたアクセスへの拒否を含め,システムのセ

キュリティに影響を与える可能性がある機能を識別する。軽減及び抑制を含め,必須又は

適切な場合に,適用可能な標準及び受け入れた専門的な実践を参照し,要求されたセキュ

リティの機能を明示する。

c)

利害関係者要求事項の分析及び維持

このアクティビティは,次のタスクからなる。

1)

引き出された要求事項の完全な集合を分析する。

注記  分析には,対立する,欠如している,不完全な,曖昧な,整合性のない,不合理な又は検

証できない要求事項の識別及び優先順位付けを含む。


42

X 0170

:2013 (ISO/IEC 15288:2008)

2)

要求事項に関する問題を解決する。

注記  これには,実現できない要求事項又は達成するのが実際には不可能な要求事項を含む。

3)

ニーズ及び期待が適切に捉えられ,表現されていることを確実にするために,分析された要求事項

を該当する利害関係者へフィードバックする。

注記  利害関係者の間で対立していたり,実施できなかったり,現実的でなかったりする要求事

項を解決するための提案を説明し,合意を得る。

4)

利害関係者要求事項が正確に表現されていることを,利害関係者とともに確立する。

注記  これには,利害関係者要求事項が,各発案者からみて包括的なものになっていることを確

認し,かつ,要求事項同士の対立に対する解決が利害関係者の意図を改悪していないし損

なっていないことの確認を含む。

5)

ライフサイクルを通して,及びその後も,要求事項の管理に適した形式で利害関係者要求事項を記

録する。

注記  これらの記録は,利害関係者要求事項のベースラインを確立し,システムライフサイクル

を通して,ニーズの変更及びその発生源を保持する。これらは,システム要求への追跡可

能性の基本事項となり,次に続くシステム実体に対する要求事項のための知識の源を形成

する。

6)

利害関係者要求事項から利害関係者のニーズの源への追跡可能性を維持する。

注記  利害関係者要求事項は,ニーズのいかなる変更も考慮されることを確実にするために,ラ

イフサイクル中の重要な決定時期において,レビューされる。

6.4.2

要求事項分析プロセス

6.4.2.1

目的

要求事項分析プロセスは,望まれたサービスの利害関係者要求事項主導の視点を,これらのサービスを

提供できる要求された製品の技術的な視点へ変換することを目的とする。

このプロセスは,利害関係者要求事項を満たす将来のシステムで,制約が許す限り,いかなる特定の実

装も示さない,将来のシステムの表現を作り上げる。それは,利害関係者要求事項を満たすために,供給

者の観点から,将来のシステムがもつべき特性及び規模を明示する測定可能なシステム要求事項を作成す

ることになる。

6.4.2.2

成果

要求事項分析プロセスの実施に成功すると次の状態になる。

a)

製品ソリューションに対して要求される特性,属性並びに機能及び性能への要求事項が明示されてい

る。

b)

システムの方式設計及びそれを実現する手段に影響を及ぼす制約が明示されている。

c)

システム要求事項から利害関係者要求事項への完整性(integrity)及び追跡可能性が備わっている。

d)

システム要求事項が満たされていることを検証する基礎が定義されている。

6.4.2.3

アクティビティ及びタスク

プロジェクトは,要求事項分析プロセスの観点から,適用可能な組織の方針及び手順に従って,次に示

すアクティビティ及びタスクを実施する。

a)

システム要求事項の定義

このアクティビティは,次のタスクからなる。

1)

提供される振る舞い及び性質の観点から,システムの機能的な境界を定義する。


43

X 0170

:2013 (ISO/IEC 15288:2008)

注記  これには,利用者及び環境の振る舞いに対するシステムへの刺激及びその反応を含む。そ

して,機械的,電気的,質量,熱,データ及び手順的な流れのようなインタフェース上の

制約の観点からの,システムとその運用環境との間に要求される相互作用の分析及び記述

を含む。これは,システムの境界で,量的な用語で表現された,期待されるシステムの振

る舞いを確立する。

2)

システムが実行を要求されている各機能を定義する。

注記 1  この定義は,システムが運用者を含めてどのように良好に機能を実行することが要求さ

れているか,システムが機能を実行することができる条件,システムが機能の実行を開

始する条件及びシステムが機能の実行を停止する条件を含む。

注記 2  機能の性能に対する条件は,システムの運用の要求された状態及びモードへの参照を組

み入れてもよい。システム要求事項は,提案されたシステム特性の抽象的な表現に大き

く依存し,望まれるシステム要求事項の十分に完全な記述を与える,複数のモデル化の

手法及び見方を採用してもよい。

3)

利害関係者要求事項によってもち込まれるか,又は回避できないソリューションの制限である,必

要な実装制約条件を定義する。

注記  これには,システム構造の高いレベルの設計から割り当てられる実装上の決定を含む。

4)

技術的な達成度のアセスメントを可能にする,技術的な測定量及び利用時の品質についての測定量

を定義する。

注記  これには,利害関係者要求事項の中で識別された効果の測定量に関連付けられた,重大な

性能パラメタを定義することを含む。重大な性能測定量は,利害関係者要求事項が満たさ

れることを確実にするために,プロジェクトのコスト,スケジュール又は何らかの非遵守

に関連する性能リスクの識別を確実にするために,分析され,レビューされる。JIS X 0141

は,適切な測定量を識別し,定義し,利用するためのプロセスを規定する。JIS X 0129 

格群は,関連する品質測定量を規定する。

5)

システムのリスクの識別又は重大性によって正当化されるので,健康,安全性,セキュリティ,信

頼性,可用性及び支援可能性のような,重大な品質に関係のあるシステム要求事項及び機能を明示

する。

注記  このタスクには,運用及び保守の方法,環境上の影響並びに人員の損傷に関係するものを

含めた安全性への考慮事項の分析及びその定義を含む。また,必要なリスク軽減の観点か

ら 表 現 さ れ た 安 全 性 に 関 す る 各 機 能 及 び そ れ に 関 連 す る 安 全 性 に つ い て の 完 整 性

(integrity)が明示され,指定された安全性に関するシステムに割り当てられることを含む。

機能的な安全性に関して適用可能な規格,例えば,JIS C 0508,及び環境保護に関して適

用可能な規格,例えば,JIS Q 14001,が利用される。機密の情報,データ及び原材料を危

険にさらすこと及び保護することに関連するものを含めたセキュリティの考慮事項を分析

する。該当する場合には,適用できるセキュリティ規格を利用して,管理,人員,身体,

コンピュータ,通信,ネットワーク,排出物質及び環境の要素を含めて,セキュリティに

関連するリスクを定義する。ただし,これらに限定するものではない。

b)

システム要求事項の分析及び維持

このアクティビティは,次のタスクからなる。

1)

各要求事項,要求事項の対又は要求事項の集合が,全体的完整性(integrity)をもつことを確実にす


44

X 0170

:2013 (ISO/IEC 15288:2008)

るために,システム要求事項の完整性(integrity)を分析する。

注記  各システム要求事項の記述文は,一意で,完全で,曖昧性がなく,他の全ての要求事項と

矛盾がなく,実装可能で,検証可能であることを確立するためにチェックされる。欠陥,

矛盾点及び弱点は,システム要求事項の完全な集合内で識別され,解決される。その結果

であるシステム要求事項は分析され,それらが完全で,一貫していて,

(現在の技法又は技

術的進歩の知識を仮定すれば)達成可能で,適切な詳細度で表現されていることを確認す

る 。 良 い 要 求 事 項 の 属 性 及 び 品 質 に 関 す る 追 加 の 詳 細 な 指 針 に つ い て は ISO/IEC 

26702:2007

,IEEE Standard for Application and Management of the Systems Engineering Process

を参照。

2)

指定されたシステム要求事項がニーズ及び期待に対応して利害関係者要件事項を適切に反映してい

ることを保証するために,分析された要求事項を該当する利害関係者にフィードバックする。

注記  それらが利害関係者要求事項への必要十分な応えであり,他のプロセス,特に方式設計へ

の必要十分な入力であることが確認される。

3)

システム要求事項と利害関係者要求事項との間の追跡可能性を示す。

注記  システム要求事項と利害関係者要求事項との間の双方向の追跡可能性を維持する。すなわ

ち,全ての達成可能な利害関係者要求事項は,一つ以上のシステム要求事項で満たされる。

全てのシステム要求事項は,少なくとも一つの利害関係者要求事項を満たすか又は満たす

ことに寄与する。システム要求事項は,利害関係者のニーズ及び方式設計への追跡可能性

を可能にする適切なデータリポジトリに,保持される。

4)

システムライフサイクルを通して付随する論理的根拠,決定及び前提とともに,システム要求事項

の集合を維持する。

6.4.3

方式設計プロセス

6.4.3.1

目的

方式設計プロセスは,システム要求事項を満たすソリューションをまとめあげることを目的とする。

このプロセスは,管理可能な,概念的な,究極的には実現可能な粒度の個別の問題を集合としてまとめ

たソリューションのかたまりを,ひとまとまりにして,定義する。それは,システムの技術的及び商業的

な要求事項並びにリスクと整合する詳細度で,一つ以上の実装戦略を識別し探求する。これから,方式設

計ソリューションは,システムを構成するシステム要素の集合に対する要求事項に関して定義される。こ

のプロセスから生じる明示された設計要求事項は,

実現されたシステムの検証のための基礎となり,

かつ,

組立及び検証の戦略の考案のための基礎となる。

6.4.3.2

成果

方式設計プロセスの実施に成功すると次の状態になる。

a)

方式設計のベースラインが確立されている。

b)

システムに対する要求事項を満足するシステム要素記述の実装可能な集合が明示されている。

c)

インタフェース要求事項が,方式設計ソリューションに組み込まれている。

d)

方式設計からシステム要求事項への追跡可能性が確立されている。

e)

システム要素を検証するための基礎が定義されている。

f)

システム要素の結合のための基礎が確立されている。


45

X 0170

:2013 (ISO/IEC 15288:2008)

6.4.3.3

アクティビティ及びタスク

プロジェクトは,方式設計プロセスについて,該当する組織の方針及び手順に従って,次に示すアクティ

ビティ及びタスクを実施する。

注記  方式表現についての更なる情報に対しては,ISO/IEC 42010 を参照。

a)

方式の定義

このアクティビティは,次のタスクからなる。

1)

適切な論理方式設計を定義する。

注記  このタスクには,機能及び性能についての要求事項,サービス及び属性,時系列要求事項,

データフロー要求事項などを,論理方式設計の必要に応じて,記述するために派生要求事

項を識別し,定義することを含む。論理的な方式を物理的な要素に分割することに先だっ

て,様々な論理的記述の間での矛盾が解決され,各論理方式が,定義されたシステム要求

事項との双方向の追跡可能性がチェックされることで,完全であり,首尾一貫しているこ

とが示される。

2)

要求事項分析で識別されたシステム機能を分割し,システム方式の要素にそれらを割り当てる。割

当てのために必要となる派生要求事項を作り出す。

3)

システム要素間のインタフェース及び外部システムとのシステム境界でのインタフェースを定義し,

文書化する。

注記  定義は,システム実体の作成,利用及び進化に適した詳細さの水準及び制御の水準で作ら

れ,外部のインタフェースをもつ実体に対して責任がある当事者からのインタフェース文

書を基に作られる。人間対システム及び人間対人間のインタフェースも定義され,制御さ

れる。インタフェース定義は,存在する場合に,公認された製品分野又は国際規格に適合

する。例えば,人間対コンピュータのインタフェースのための ISO 9241 又は ISO/IEC 

7498-1

におけるデータ通信のための開放型システム間相互接続の 7 層モデルに適合する。

b)

方式の分析及び評価

このアクティビティは,次のタスクからなる。

1)

各要素に対して,結果として生じる方式設計を分析して,設計基準を確立する。

注記  設計基準には,物理的,性能,振る舞い,耐久性及び持続可能なサービスの特性を含む。

一般的には,利害関係者要求事項定義プロセス,要求事項分析プロセス及び方式設計プロ

セスは,要素が,ソフトウェアの JIS X 0160:2012 などの開発規格を用いて,購入,再利用

又は構築できるまで,システム方式の中の逐次の詳細さの水準に対して,再帰的に適用さ

れる。

2)

どのシステム要求事項が運用者に割り当てられるかを決定する。

注記  この決定は,利用要因の文脈を考慮し,最も有効で,効率的で,信頼できる人対機械の相

互作用のために,次に示す要因を最小限考慮する。

2.1)

人間の能力の限界

2.2)

安全性に対して重大な人間の行動及び誤りの結果への対応

2.3)

人間の仕事ぶりのシステム及び運用への結合

注記  利用者中心設計の手引は,JIS Z 8530 で与えられる。

3)

設計及びインタフェースの基準を満たすハードウェア及びソフトウェアの要素が利用可能な市販品

があるか否かを見定める。


46

X 0170

:2013 (ISO/IEC 15288:2008)

注記  このタスクには,要素を開発することにするか,又は既存のシステム要素を再利用若しく

は適応させるかを決定するために,すぐに入手できる状態ではない設計要素を評価するこ

とを含む。作成,修正又は購入の判断に関連したコスト,スケジュール及び技術的なリス

クを確立する。

4)

設計ソリューションの選択肢を,システム要求事項の中で表現された仕様並びに利害関係者要求事

項の中で表現された性能,コスト,期間及びリスクに対する比較を可能にする詳細さの水準までそ

れらをモデル化し,評価する。

注記  このタスクには,次のことを含む。

4.1)

候補となるシステム要素の相互作用から又はシステム要素の変化から起因する不利なシステムプ

ロパティの出現を見定め,通知を行う。

注記  “プロパティ”とは,“そのものの情報のことで,品質,属性又は代表的な特徴”のこと

をいう。

4.2)

イネーブリングシステムの制約が設計の中で考慮されることを確実にする。

4.3)

実現可能で,効果的で,安定していて,最適化された設計の実現に導く有効性の評価,トレード

オフ分析及びリスク分析を実行する。

c)

方式の文書化及び維持

このアクティビティは,次のタスクからなる。

1)

選択された物理設計ソリューションを機能,性能,振る舞い,インタフェース及び不可避の実装上

の制約の観点から,方式設計のベースラインと指定する。

注記  これらの仕様は,受入れ基準も含め,システムソリューションの基礎であり,システム要

素の取得合意のための源泉(原点,根幹)である。それらは,開発作業の成熟度に適した,

スケッチ,図面又は他の記述,例えば,実現可能性設計,概念設計又は製作事前設計とい

う形態で存在してもよい。それらは,システム要素を検証するために,及びシステムに対

する結合戦略を定義するために,システム要素を生産する,再利用する,又は取得するか

を決定する基礎である。

2)

方式設計の情報を記録する。

注記  このタスクでは,要求事項のベースラインへの追跡可能性をもたせて,構造的及び機能的

な分割,インタフェース及び制御の定義並びに設計事項の決定及び結論を記録する。方式

設計のベースラインは,ライフサイクルを通して変更があった場合には,レビューを可能

にし,以後の方式の再利用のいずれに対しても,情報を提供する。方式設計のベースライ

ンは,結合のときに行うテストを定義するときの情報源でもある。

3)

指定された設計要求事項とシステム要求事項との間の,双方向の追跡可能性を維持する。

6.4.4

実装プロセス

6.4.4.1

目的

実装プロセスは,指定されたシステム要素を実現することを目的とする。

このプロセスでは,指定されたシステムの振る舞い,インタフェース及び実装上の制約を,選択された

実装技術のやり方に従ってシステム要素を製作する組立活動に変換する。選択された実装技術に適した資

材及び/又は情報を処理し,

適切な専門性又は技術的規律を用いて,

システム要素が構築又は適応される。

このプロセスは,検証を通じて指定された設計要求事項を満足し,妥当性確認を通じて利害関係者要求事

項を満足するシステム要素を結果としてもたらすものである。


47

X 0170

:2013 (ISO/IEC 15288:2008)

6.4.4.2

成果

実装プロセスの実施に成功すると次の状態になる。

a)

実装戦略が定義されている。

b)

設計上の実装技術の制約が識別されている。

c)

システム要素が実現されている。

d)

システム要素が供給についての合意に従って,まとめられ,保管されている。

6.4.4.3

アクティビティ及びタスク

プロジェクトは,実装プロセスについて,該当する組織の方針及び手順に従って,次のアクティビティ

及びタスクを実施する。

a)

実装の計画

このアクティビティは,次のタスクからなる。

1)

実装戦略を作り出す。

注記  このタスクは,実装手順,製作プロセス,ツール・設備,実装の許容範囲及び検証の予測

不確実性を含む。システム要素の実装が繰り返される場合(例えば,大量生産)

,交換シス

テム要素,実装手順及び組立てプロセスは,整合性がとれており,繰返しできる生産可能

性を達成するように定義される。

2)

実装戦略及び実装技術が設計ソリューションに課す制約を識別する。

注記  このタスクは,選択された実装技術,取得者が供給した資材又は適用のためのシステム要

素の現時点での又は予測される制限及び必要な実装用イネーブリングシステムを使用する

結果からもたらされる制限を含む。

b)

実装の遂行

このアクティビティは,次のタスクからなる。

1)

ハードウェア製作,ソフトウェア作成及び/又は運用者の教育訓練のために,定義された実施手順

に従って,実装のためのイネーブリングシステム及び指定された資材を使用するシステム要素を実

現又は適応する。

注記  適応は,再利用又は取得されたハードウェア要素及びソフトウェア要素の構成を含む。実

現又は適応は,該当する安全性,セキュリティ,プライバシ及び環境に関する指針又は法

令,並びに関連する実装技術のやり方に従って実施される。

1.1)

ハードウェア製作

選択された物理的な実装技術及び資材に関する調節,成型及び組立て製作の手法を用いて,ハー

ドウェア要素を製作する。必要に応じて,ハードウェア要素は,指定された製品品質特性を確認

するためにテストされる。

1.2)

ソフトウェア作成

設計基準への適合を保証するために,ソフトウェア要素を作成し,必要に応じて,コンパイル

し,検査し,テストする。JIS X 0160:2012 をソフトウェアで実現するシステム要素に適用する。

1.3)

運用者の教育訓練

必要な能力基準及び運用手順に従ってタスクを実行できるように運用者を準備するため,適切

な教育訓練を提供する。必要に応じて,運用者が指定された範囲及び水準の能力に到達している

ことを確認する。このタスクには,適切な故障検出・分離の指示を含めて,運用環境の認識を含

めることがある。


48

X 0170

:2013 (ISO/IEC 15288:2008)

2)

システム要素が供給者合意,法令及び組織の方針に合致している証拠を記録する。

注記  このタスクは,方式設計からの要求事項が実装されたシステム要素によって満足されてい

るという客観的な証拠を提供する。証拠は,供給者合意,法令及び組織の方針に従って提

供される。

3)

必要に応じて,システム要素をまとめて,保管する。

注記  その特性が維持されるように,システム要素を格納する。運搬及び格納媒体並びにそれら

の期間が,格納の仕方に影響を与える。

6.4.5

結合プロセス

6.4.5.1

目的

結合プロセスは,方式設計と整合性がとれたシステムを組み立てることを目的とする。

このプロセスは,システム要求事項で指定された製品を作り出すために,完全な又は部分的なシステム

構成を形成するようにシステム要素を組み合わせる。

6.4.5.2

成果

結合プロセスの実施に成功すると次のような状態になる。

a)

システム結合戦略が定義されている。

b)

要求事項に影響する,不可避の結合制約が定義されている。

c)

方式設計からの指定された要求事項に対する検証が可能なシステムが組み立てられて結合されてい

る。

d)

結合作業によって起こる不適合が記録されている。

6.4.5.3

アクティビティ及びタスク

プロジェクトは,結合プロセスに関する該当する組織の方針及び手順に従って,次のアクティビティ及

びタスクを実施する。

a)

結合の計画

このアクティビティは,次のタスクからなる。

1)

システム結合の時間,コスト及びリスクを最小にする組立て順序及び戦略を定義する。

注記  その戦略では,システム要素構成を次第に完全なものにしながら,順次に検証することを

可能にしてもよい。それは,システム要素の可用性に依存しており,障害を分離して診断

する戦略と整合性がとれている。可能な限り,結合した構成に運用者を含める。結合プロ

セス及び検証プロセス,並びに適切な場合には妥当性確認プロセスも含めて,それらの逐

次の適用が,対象システムが実現されるまで逐次の水準でシステムに対して繰り返される。

2)

結合戦略から生じる設計上の制約を識別する。

注記  これには,中間組立て部品構成のための,利用可能性,結合用イネーブリングシステム及

び,インタフェース接続及び/又は相互接続のような要因を含む。

b)

結合の実施

このアクティビティは,次のタスクからなる。

1)

定義された結合手順に従って結合用イネーブリングシステム及び指定された資材を入手する。

注記  結合のためのイネーブリングシステムは,結合用施設,ジグ,調節用施設及び組立て装置

を含んでもよい。結合用イネーブリングシステムの要求事項,制約及び他の制限が定義さ

れる。


49

X 0170

:2013 (ISO/IEC 15288:2008)

2)

合意されたスケジュールに従ってシステム要素を入手する。

注記  システム要素は,供給者から受け取られるか,又は保管場所から取り出される。システム

要素は,関係のある健康,安全性,セキュリティ及びプライバシを配慮した上で取り扱わ

れる。

3)

合意で指定された受入れ基準に対してシステム要素が検証され,適格性確認がなされていることを

確実にする。

注記  検証に合格しないシステム要素は,不合格として識別され,定義された手順に従って扱わ

れる。

4)

指定された結合用施設を使用して,該当するインタフェース制御記述及び定義された組立て手順に

従ってシステム要素を結合する。

5)

結合情報を分析し,記録し,報告する。結合作業の結果,不適合及び実施された是正処置を含む。

注記  これは,結合戦略,結合用イネーブリングシステム又は手作業の組立て誤りによって起こっ

た問題の解決を含む。データは,結合戦略及びその実行に対して是正処置又は改善活動が

できるように解析される。学んだ教訓も記録されることが望ましい。

6.4.6

検証プロセス

6.4.6.1

目的

検証プロセスは,指定された設計要求事項がシステムによって満足されていることを確認することを目

的とする。

このプロセスは,実現されたシステム又はそのシステム上で実行されるプロセスにおける不適合を正す

是正処置を,効果的なものにするために必要な情報を提供する。

6.4.6.2

成果

検証プロセスの実施に成功すると次の状態になる。

a)

検証戦略が定義されている。

b)

検証制約が要求事項に対する入力として提供されている。

c)

是正処置のための情報を提供するデータが報告されている。

d)

実現された製品がシステム要求事項及び方式設計を満足することを示す客観的な証拠が提供されてい

る。

6.4.6.3

アクティビティ及びタスク

プロジェクトは,検証プロセスに関する該当する組織の方針及び手順に従って,次のアクティビティ及

びタスクを実施する。

a)

検証の計画

このアクティビティは,次のタスクからなる。

1)

ライフサイクルを通して,システム実体を検証するための戦略を定義する。

注記  この戦略は,システム及びその記述,例えば,要求事項,設計定義に対して適用する。こ

の戦略には,例えば,設計の検証,設計されたものを正しく構築する能力,システムを再

製作する能力,発生した障害を正す能力,故障を予測する能力などの検証作業の各事例の

文脈及び目的を含む。検証は,製品の評価を通じて,システムが“正しく”作られている

ことを示す。すなわち,製品の実現のための指定された設計をシステムが満足しているこ

とを実証する。

検証の間,

可能な限り,

システムに人間の運用者を含める。

例えば,

レビュー,

検査,監査,比較,静的テスト,動的テスト,実証(又はこれらの組合せ)という検証作


50

X 0170

:2013 (ISO/IEC 15288:2008)

業の性格及び範囲は,モデル,プロトタイプ又は実際の製品のいずれが検証中かどうかに

依存し,例えば,安全性,商業上の臨界(限度)のような想定されるリスクに依存する。

2)

システム要求事項に基づく検証計画を定義する。

注記  その計画は,結合戦略で定義された構成の順序の説明となる。必要に応じて,障害診断の

ための分解戦略を考慮に入れる。スケジュールでは,一般的には,完全に構成された製品

に応じて信頼を次第に築いていく,リスクを管理した検証ステップを定義する。

3)

設計決定における潜在的な制約は,識別され伝達される。

注記  これは,検証用イネーブリングシステムによって課せられる正確性,不確定性,反復性の

実際的な制限,付随する測定方法,システム結合のニーズ,並びにイネーブリングシステ

ムの可用性,利用可能性及び相互接続性を含む。

b)

検証の実施

このアクティビティは,次のタスクからなる。

1)

検証のためのイネーブリングシステムが利用可能であることを保証し,付随した施設,装置及び運

用者が検証するために準備されていることを確実にする。

2)

指定された設計要求事項に対する遵守を示すために検証を行う。

注記  不適合は,無作為の障害及び/又は設計の誤りの存在を識別し,是正処置が必要に応じて

開始される。検証は,組織の制約と整合性がとれており,検証作業,条件及び結果の再現

における不確定性を最小にするような方法で実行される。検証作業及び検証結果の承認さ

れた記録が作られる。

3)

システムに関する検証データを利用可能にする。

注記  これは,合意及び法律,規制又は製品分野の要求事項に従って実施される。

4)

検証,不整合及び是正処置の情報を分析,記録及び報告する。

注記  合意条項又は組織目標に従って,不適合を引き起こすシステムの部分を分離するために検

証を行う。欠陥修正に続く再検証を含めた費用対効果のある是正処置及び/又は組織の品

質改善活動と整合するような解決の水準で障害診断を実施する。検証データは,検証戦略

で定義された基準に従って収集され,分類され,照合される。これによって,発生源及び

是正処置所有者に従って不適合を分類する。検証データは,故障の傾向及び故障パターン,

設計誤りの証拠及びサービスに対して新たに現れつつある脅威などの本質的な特徴を検出

するために分析される。

6.4.7

移行プロセス

6.4.7.1

目的

移行プロセスは,運用環境において,利害関係者要求事項によって指定されたサービスを供給する能力

を確立することを目的とする。

このプロセスは,例えば,合意によって定められた,オペレーティングシステム,支援システム,運用

者教育訓練システム,利用者訓練システム,といった関連するイネーブリングシステムとともに検証済み

システムを導入する。このプロセスは,段階の終了に対して確立されている基準を完了するために,シス

テム構造の中の各水準及び各段階で使用される。それには,該当する保管,取扱い及び出荷のイネーブリ

ングシステムの準備を含む。

6.4.7.2

成果

移行プロセスの実施に成功すると次の状態になる。


51

X 0170

:2013 (ISO/IEC 15288:2008)

a)

システム移行戦略が定義されている。

b)

システムが運用場所に導入されている。

c)

運用されたとき,システムは,指定されたサービスを提供する能力がある。

d)

導入された構成が記録されている。

e)

是正処置の報告が記録されている。

f)

サービスは,イネーブリングシステムによって維持可能である。

6.4.7.3

アクティビティ及びタスク

プロジェクトは,移行プロセスに関する該当する組織の方針及び手順に従って次のアクティビティ及び

タスクを実施する。

a)

移行の計画

このアクティビティは,次のタスクからなる。

1)

移行戦略を準備する。

注記  移行戦略は,合意に従ってシステムの導入及び試運転を含む。可能な限り,移行戦略に運

用者を含める。

2)

導入要求事項に従って運用場所を準備する。

注記  運用場所の準備は,該当する健康,安全性,セキュリティ及び環境に関する規則に従って

実施される。

b)

移行の実施

このアクティビティは,次のタスクからなる。

1)

適正な場所及び時間に導入するために,システムを納入する。

注記  納入する前の中間時点の保管についても説明が必要になる場合がある。

2)

システム仕様に従ってシステムを運用場所に導入し,その環境とインタフェースで接続する。

注記  システムは,必要な運用データとともに構成される。

3)

システムの適切な導入を示す。

注記  納入に関する合意で定義された受入れテストを行うことによって,導入が満足のいくもの

であったことを示す。運用の正確な場所又は環境が利用できない場合には,代表的な例が

選ばれる。

4)

システムを起動させる。

5)

導入されたシステムがその必要なサービスを供給する能力があることを示す。

注記  合意で指定された受入れテストでは,システムが運用場所に導入されて運用者が要員配置

されているときに,システム実体が必要なサービスを供給する能力があることを示す基準

を定義することができる。

6)

システムによって提供されるサービスはイネーブリングシステムによって持続可能であることを示

す。

7)

移行情報を分析し,記録し,報告する。移行活動の結果,非適合及び行われた是正活動を含む。

注記  実装後報告は,システム要求事項の欠陥も技術的な特徴も含んでいる。システム及びその

指定された運用環境と,利用段階を可能にするどれかのシステムとの間のインタフェース

に不整合が存在する場合には,逸脱は是正処置及び/又は要求事項の変更につながる。学

んだ教訓も記録されることが望ましい。


52

X 0170

:2013 (ISO/IEC 15288:2008)

6.4.8

妥当性確認プロセス

6.4.8.1

目的

妥当性確認プロセスは,

システムによって提供されるサービスが利用中に利害関係者要求事項を遵守し,

意図された運用環境で,意図された利用を達成していることを示す,客観的な証拠を提供することを目的

とする。

このプロセスは,

相対比較の評価を行い,

利害関係者要求事項が正しく定義されていることを確認する。

差異が識別された場合には,これらは記録され,是正処置を導く。システム妥当性確認は,利害関係者に

よって承認される。

6.4.8.2

成果

妥当性確認プロセスの実施に成功すると次の状態になる。

a)

妥当性確認戦略が定義されている。

b)

利害関係者によって必要なサービスの可用性が確認されている。

c)

妥当性確認データが提供されている。

d)

是正処置のための情報を提供できるデータが報告されている。

6.4.8.3

アクティビティ及びタスク

プロジェクトは,妥当性確認プロセスに関する該当する組織の方針及び手順に従って次のアクティビ

ティ及びタスクを実施する。

a)

妥当性確認の計画

このアクティビティは,次のタスクからなる。

1)

運用環境におけるサービスの妥当性確認のための戦略を確認し,利害関係者の満足を達成するため

の戦略を定義する。

注記  サービスの評価を利害関係者に提供することによって,妥当性確認は,

“正しい”システム

実体が作成されていること,すなわち,その目的に合致しており顧客を満足させることを

示す。妥当性確認は,ライフサイクルの最も早い段階から行われる。例えば,その環境と

同等とみなし得る場において,開発中のシステムについての机上のプロトタイプ,シミュ

レーション又は実物大模型を概念段階で妥当性確認のために使用してもよい。妥当性確認

作業の性格及び範囲は,次の各事項に依存している。

−  モデル,プロトタイプ又は,実際のシステムの妥当性確認がなされているかどうか。

−  リスク(例えば,新規性,安全性,技術的及び商業的臨界の問題)

−  合意及び組織の制約

−  利害関係者要求事項

供給者,取得者又は取得者の代理人が実現された製品の妥当性確認をしてもよい。責任

は,合意に明示されている。

2)

妥当性確認計画を準備する。

注記  妥当性確認は,利害関係者要求事項に基づいている。必要に応じて,導入したシステムの

適合性に確信を次第に築いていき,食い違いの診断を助けるような,例えば,様々な運用

状態,シナリオ及び任務といった,妥当性確認ステップを定義する。各妥当性確認の目的,

条件及び適合基準が指定されるに従って,妥当性確認戦略を実施するのに必要な技法及び

手法が指定される。利害関係者要求事項が,包括的に指定できないか,又はしばしば変わ

る場合には,システム進化の(しばしば速く開発される)増分について繰返し妥当性確認


53

X 0170

:2013 (ISO/IEC 15288:2008)

することによって,利害関係者要求事項を洗練化し,ニーズの正しい識別におけるリスク

を低減してもよい。例えば,JIS Z 8530 では利用者を関与させる反復のライフサイクルを

記述している。

b)

妥当性確認の実施

このアクティビティは,次のタスクからなる。

1)

妥当性を確認するために,運用者,妥当性確認用のイネーブリングシステム及び付随する施設が準

備されていることを確実にする。

2)

利害関係者要求事項に対するサービスの適合性を示すために妥当性確認を実施する。

注記  妥当性確認は,組織の制約と整合性がとれており,妥当性確認の作業,条件及び結果の再

現における不確定性を最小にするような方法で実行される。妥当性確認作業及び結果を客

観的に記録し承認する。妥当性確認は,全ての運用上の要求事項,機能的な要求事項及び

使用性の要求事項を満足することだけでなく,顧客の満足度を構成する,しばしば非公式

的に表現されるが,時には最も重要である,態度,経験及び主観的テストをも満足するこ

とを確認するために行われることがある。

3)

法律,規制又は製品分野の要求事項に従ってシステムに関する妥当性確認データを利用可能にする。

4)

合意条項又は組織目標に応じて,不適合を引き起こすシステムの一部を分離するために妥当性確認

を実施する。

注記  欠陥修正に続く再度の妥当性確認を含む費用対効果のある是正処置及び/又は組織の品質

改善活動と整合するような解決の水準で障害診断を実施する。

5)

妥当性確認計画で定義された基準に従って妥当性確認データの分析,記録及び報告を行う。

注記  このアクティビティは,不適合の発生源及び是正処置所有者に従って不適合を分類する。

妥当性確認データを分析し,故障の傾向及び故障パターン,設計誤りの証拠及びサービス

に対しての新たな脅威などの本質的な特徴を検出する。

6.4.9

運用プロセス

6.4.9.1

目的

運用プロセスは,そのサービスを提供するためにシステムを利用することを目的とする。

このプロセスは,システムを運用する要員を割り当て,サービス及び運用者−システム間の性能を監視

する。サービスを持続するために,運用上の問題を,合意,利害関係者要求事項及び組織の制約に関して

で識別し,分析する。

6.4.9.2

成果

運用プロセスの実施に成功すると次の状態になる。

a)

運用の戦略が定義される。

b)

利害関係者要求事項に合致したサービスが提供される。

c)

承認された是正処置の依頼が満足に完了している。

d)

利害関係者の満足度が維持されている。

6.4.9.3

アクティビティ及びタスク

プロジェクトは,運用プロセスに関する該当する組織の方針及び手順に従って,次のアクティビティ及

びタスクを実施する。

a)

運用の準備

このアクティビティは,次のタスクからなる。


54

X 0170

:2013 (ISO/IEC 15288:2008)

1)

運用戦略を作成する。

注記  このタスクは,次の事項を定義する。

1.1)

サービスが導入され,日常的に運用され,廃止されるにつれての可用性。必要に応じて,同一又

は類似したサービスを提供している他のシステムが提供する,既存か,同時並行か又は継続のサー

ビスとの調整を行うことを含める。

1.2)

運用者を要員配置する戦略及びスケジュール。

1.3)

必要に応じて,既存又は強化されたサービスを維持する修正を可能にするためのシステムのリ

リース及び再受入の基準及びスケジュール。

2)

システムの運用に関係する他のサービスを入手する。

3)

教育訓練された有資格の要員を運用者として任命する。

注記  このタスクには,運用環境でのシステムの認識及び適切な故障の検出・分離の指示を伴う

定義された習熟プログラムを含めてもよい。運用者の知識,スキル(技術)及び経験につ

いての要求事項をもとに要員選定基準を導き出し,関連がある場合は,運用許可を確認す

る。運用システムを用いた教育訓練を実施する教官の選定及び教育訓練は,要員配置の観

点から行われる場合がある。運用システムの教育訓練のやり方は,サービスの可用性に影

響を与える場合がある。

b)

運用開始及びテストの実施

このアクティビティは,次のタスクからなる。

1)

意図された運用の状況の中でシステムを作動させ,意図された目的に従ってサービスの事例又は継

続したサービスを提供する。

注記  合意がある場合,新システムが廃止される既存のシステムと置き換わるとき,継続したサー

ビスの能力及び質を維持する。運用切替え又は並行運用の指定期間中,利害関係者の持続

的ニーズへの適合を継続することが達成されるように,サービスの移行を管理する。

c)

運用のためのシステムの利用

このアクティビティは,次のタスクからなる。

1)

サービスを維持するため,必要に応じて資材を消費する。

注記  ハードウェアのためのエネルギ源及び運用者のための生活物資を含む。

2)

システムの運用が運用計画に従って,安全な方法で行われ,職業安全性及び環境保護に関する法制

化された指針に適合して行われることを確実にするために運用を監視する。

3)

システム運用を監視し,サービス性能が受入れ可能な範囲内であることを確認する。

注記  ハードウェア内に実装されているシステム要素がその耐用年数を超過しているとき又はシ

ステムの運用環境が運用要員及び保守要員に影響を与えているとき(要員の配置転換,運

用者の過負荷及び疲労を含めて)

,システムは,受入れできない性能を示すことがある。

d)

運用上の問題解決の実施

このアクティビティは,次のタスクからなる。

1)

提供されているサービスに不適合が発生したとき,故障の識別活動を実施する。

2)

変更されたニーズによって生じた欠陥を直すために是正処置が要求されたとき,適切な活動指針を

決定する。

注記  これには限定はされないが,適切な活動指針は,次の事項の導入を含むことがある。

−  小規模なハードウェア若しくはソフトウェアの適応,又は運用者の活動の修整の導入


55

X 0170

:2013 (ISO/IEC 15288:2008)

−  利害関係者要求事項の変更

−  システムの設計及び/又は実装の変更

−  サービスの縮小を許容すること

3)

人的誤りが故障につながる場合は,必要に応じて,運用手順,運用環境,マンマシンインタフェー

ス及び運用者の教育訓練に対して,改善の変更を導入する。

e)

顧客の支援

このアクティビティは,次のタスクからなる。

1)

継続的又は定常的に利用者との意思疎通をはかり,提供されているサービスが利用者のニーズをど

の程度満たしているかを判断する。

注記  結果は,分析され,利害関係者の満足を継続して提供するために,サービスを修復又は修

正するのに必要な活動が識別される。可能な限り,常時そうした活動の有益さについて,

利害関係者又はそれらの代表者と合意しておく。

6.4.10

保守プロセス

6.4.10.1

目的

保守プロセスは,サービスを提供するためにシステムの能力を維持することを目的とする。保守プロセ

スでは,サービスを提供するシステムの能力を監視し,分析のために問題を記録し,是正・適応・完全化・

予防処置を行い,修復された能力を確認する。

6.4.10.2

成果

保守プロセスの実施に成功すると次の状態になる。

a)

保守の戦略が作成されている。

b)

要求事項への入力として保守に関する制約が提供されている。

c)

交換するシステム要素が利用可能になっている。

d)

利害関係者要求事項に合致しているサービスが持続されている。

e)

是正のための設計変更のニーズが報告されている。

f)

故障及び寿命時間データが記録されている。

6.4.10.3

アクティビティ及びタスク

プロジェクトは,保守プロセスに関する該当する組織の方針及び手順に従って,次のアクティビティ及

びタスクを実施する。

a)

保守の計画

このアクティビティは,次のタスクからなる。

1)

保守の戦略を準備する。

注記  このタスクは,運用の可用性についての要求事項に適合するように是正保守及び予防保守

を実施するのに必要なスケジュール及び資源を定義する。これには,次のものを含めるの

が望ましい。

1.1)

顧客満足を達成するために,運用環境下におけるサービスを持続するための是正保守及び予防保

守戦略。

1.2)

例えば,サービスの中止又は制限といったサービスの顕著な低下を招くことなく,システム故障

の可能性を減らす計画された予防保守活動。

1.3)

保管される交換システム要素の数量及び種別,保管の場所及び条件,それらの交換率の期待値,

それらの保管寿命及び更新される頻度。


56

X 0170

:2013 (ISO/IEC 15288:2008)

1.4)

保守要員の要求事項並びに健康,安全性,セキュリティ及び環境に関連する法令に対して説明す

るような,修理及び交換を遂行するために必要なスキル(技術)及び要員の水準。これらの手順

には,解体戦略,障害診断技法,再組立て及びテスト順序を含む。

2)

保守戦略の不可避な影響である,システム要求事項上の制約を定義する。

注記  こうした制約は,次のようなニーズから結果としてもたらされる場合がある。

2.1)

既存の保守用イネーブリングシステムを再利用する。

2.2)

既に確保している交換可能なシステム要素を再利用し,再供給の制限に対応する。

2.3)

特定の場所又は環境における保守を実施する。

b)

保守の実施

このアクティビティは,次のタスクからなる。

1)

システムの保守中に利用するイネーブリングシステム,システム要素及びサービスを入手する。

2)

将来の改良保守,適応保守,完全保守及び予防保守を支援するために,個々の出来事及び履歴の分

析を指導するため,問題報告及び事故記録を実施する。

3)

無作為の障害の是正及び/又はスケジュールされたシステム要素交換のために手順を実施する。

注記  偶発的に発生するシステム故障に対処して,障害をシステム要素の交換が可能になる程度

にまで分離し,システム要素を交換して,正しいシステム性能を検証する。劣化するシス

テム要素の有効寿命を見積もるために実施内容を記録する。

4)

以前に検出されなかった設計の誤りを直すための是正処置を開始する。

注記  開発(例えば欠陥)及び/又は生産活動への潜在的な是正処置のニーズを記録し,関係す

る当事者に伝達する。これは,関連するイネーブリングシステムに影響する場合がある。

5)

貯蔵保管されているシステム要素が,修理率及び計画されたスケジュールに合うように,必要な補

充の水準を補給活動が満たせることを確認する。

注記  保管期間中に補充品の品質及び可用性,それらの輸送及び継続的な完整性(integrity)を監

視する。必要に応じて,運用者の人数及びスキル(技術)を維持するために要員の確保,

教育訓練及び認定を行う。

6)

計画されたスケジュール及び保守手順に従い,故障発生前にシステム要素を交換又は補修すること

によって予防保守を実施する。

7)

不適合がシステムに発生したとき,故障識別活動を実施する。

8)

問題報告,是正処置及び傾向に関する履歴を維持して,運用要員,保守要員及び類似したシステム

実体を作成又は利用する他のプロジェクトへ情報提供する。

6.4.11

廃棄プロセス

6.4.11.1

目的

廃棄プロセスは,システム実体の存在を終了させることを目的とする。廃棄プロセスは,システム及び

いろいろな廃棄物を不活性化し,解体し,除去して,それらを最終状態にし,環境を元の状態又は受入れ

可能な状態に戻す。廃棄プロセスは,法令,合意,組織の制約及び利害関係者要求事項に従って,環境的

に健全な方法で,システム実体及び廃棄物を破棄,保管又は再生利用(回収)する。必要な場合には,運

用者及び利用者の健康並びに環境への安全性を監視できるようにするため,記録を維持する。

6.4.11.2

成果

廃棄プロセスの実施に成功すると次の状態になる。

a)

システムの廃棄戦略が定義されている。


57

X 0170

:2013 (ISO/IEC 15288:2008)

b)

廃棄の制約が要求事項への入力として提供されている。

c)

システム要素が破棄,保管,回収又は再生利用されている。

d)

環境が元の状態又は合意した状態に戻っている。

e)

廃棄活動に関する知識保持及び長期的な危機の分析を可能にする記録が利用可能になっている。

6.4.11.3

アクティビティ及びタスク

プロジェクトは,廃棄プロセスに関する該当する組織の方針及び手順に従って,次のアクティビティ及

びタスクを実施する。

a)

廃棄の計画

このアクティビティは,次のタスクからなる。

1)

各システム要素及び結果として生じるいろいろな廃棄物を含めるため,システム廃棄戦略を定義す

る。

注記  このタスクは,次のようなスケジュール,活動及び資源を定義する。

1.1)

システムのサービス提供を恒久的な終了。

1.2)

社会的及び物理的に受入れ可能な状態へのシステム形態の変換及びシステムの保持。それによっ

て,利害関係者,社会及び環境へのその後の悪影響を回避する。

1.3)

廃棄活動に適用でき,かつ,その結果がもたらす物理的な資材及び情報の長期的状態に適用でき

る健康,安全性,セキュリティ及びプライバシの考慮。

2)

廃棄戦略から生じる,システム設計上の不可避な制約が伝達される。

注記  このタスクには,付随するイネーブリングシステムを含めて,解体の課題,保管場所への

アクセス及び可用性の課題並びに利用可能なスキル(技術)水準の課題を含む。

3)

システムを保管する場合は,格納施設,保管場所,検査基準及び保管期間を指定する。

b)

廃棄の実施

このアクティビティは,次のタスクからなる。

1)

システムを廃棄する期間中に利用するイネーブリングシステム又はサービスを取得する。

2)

システムを不活性化して,運用からの除去に対して準備する。

注記  他のシステムとのインタフェース,例えば,電力,燃料,が考慮され,解体指示及び関連

する健康,安全性,セキュリティ及びプライバシの法令に従って切り離される。

3)

システムから運用要員を引き上げ,関連する運用の知識を記録に残す。

注記  関連する安全性,セキュリティ,プライバシ及び環境に関する規格,指示書及び法律に従っ

て,これは,実施される。

4)

再利用,再生利用,再調整,分解修理(オーバーホール)

,保管又は破壊のために除去が容易になる

ようにシステムを扱いやすい要素にまで解体する。

5)

再利用,再生利用,再調整,分解修理(オーバーホール)又は破壊のために運用環境からシステム

を除去する。

注記  関連する安全性,セキュリティ,プライバシ及び環境に関する規格,指示書及び法律に従っ

て,これは,実施される。現行条件下又は分解修理後のいずれかで,役に立つ寿命が残存

するシステム要素は,他の対象システム又は組織に移される。必要に応じて,システム要

素を再調整して役に立つ寿命を延ばす。運用者を再配置,移動又は引退させる。

6)

廃棄物処理の量を削減するため又は廃棄物を扱いやすくするために,必要に応じて,システムの破

壊を実施する。


58

X 0170

:2013 (ISO/IEC 15288:2008)

注記  このアクティビティには,必要に応じて,システム又はそのシステム要素を溶解,破砕,

焼却又は粉砕するために,破壊サービスの入手も含む。運用者がもっている予防対策及び

安全性に関する知識及びスキル(技術)に働きかける。

c)

廃棄の終了

このアクティビティは,次のタスクからなる。

1)

健康,安全性,セキュリティ及び環境に有害な要因が廃棄後に存在しないことを確認する。

2)

システムの寿命を通じて集めた情報を保存して,健康,安全性,セキュリティ及び環境への長期に

わたって危険である場合には,監査及びレビューできるようにし,将来のシステムの作成者及び利

用者が過去の経験から知識ベースを構築できるようにする。


59

X 0170

:2013 (ISO/IEC 15288:2008)

附属書 A

規定)

修整(tailoring)プロセス

A.1

序文

この

附属書 は,修整(tailor)プロセスを実施する場合の要求事項を規定する。

注記 1  修整(tailor)は,規格に適合させるための要求事項ではない。事実上,“完全な適合”を主

張する場合は,修整(tailor)は許されない。

“修整(tailor)された適合”を主張する場合は,

このプロセスは,修整(tailor)を実施するために適用される。

注記 2  修整(tailor)についての追加のガイド(説明)は,技術報告書 ISO/IEC TR 24748 に記載し

ている。

A.2

修整(tailor)プロセス

A.2.1

修整(tailor)プロセスの目的

修整(tailor)プロセスは,次のような特定の状況又は要因に対応するために,この規格のプロセスを適

応させることを目的とする。

a)

合意において,この規格を用いる組織を取り巻く状況又は要因

b)

この規格を参照している合意を満たすために要求されるプロジェクトに影響する状況又は要因

c)

製品又はサービスを供給するために組織のニーズを反映する状況又は要因

A.2.2

修整(tailor)プロセスの成果

修整(tailor)プロセスの実施に成功すると次の状態になる。

a)

ライフサイクルモデルの目的及び成果を達成するために,修正(modify)されたライフサイクルプロ

セス又は新しいライフサイクルプロセスが定義されている。

A.2.3

修整(tailor)プロセスのアクティビティ及びタスク

この規格を修整(tailor)する場合,組織又はプロジェクトは,必要に応じて,修整(tailor)プロセスに

関して適用可能な方針及び手順に従って,次のタスクを実施する。

a)

修整(tailor)に影響を与える状況を識別し,文書化する。これらの影響は,次を含むが,それに限定

するものではない。

1)

運用環境の安定性及び多様性

2)

当事者の懸念である商業リスク又は業績リスク

3)

新規性,規模及び複雑さ

4)

利用開始日及び利用期間

5)

安全性,セキュリティ,プライバシ,ユーザビリティ,可用性などの完整性(integrity)に関する課

6)

新たな技術の機会

7)

利用可能な予算及び組織の資源のプロファイル(概要)

8)

イネーブリングシステムのサービスの可用性

b)

特性がシステムに対して重大な場合,重大性の側面に関連する作業標準が推奨する,又は要求するラ

イフサイクルの構造を十分に考慮する。


60

X 0170

:2013 (ISO/IEC 15288:2008)

c)

修整(tailor)の決定によって影響を受ける全ての当事者から意見を聞く。当事者には,次のものを含

むが,それに限定するものではない。

1)

システムの利害関係者

2)

その組織による合意に関心をもつ当事者

3)

寄与する組織の部門

d)

選択されたライフサイクルモデルの目的及び成果を達成するため,意思決定管理プロセスに従って修

整(tailor)の決定を下す。

注記 1  組織は,ライフサイクルモデル管理プロセスの一部として作業標準のライフサイクルモデ

ルを設定する。設定するライフサイクルモデルの段階の目的及び成果を達成するために,

組織がこの規格のプロセスを修整(tailor)することが適切な場合がある。

注記 2  プロジェクトは,組織で設定したライフサイクルモデルを,プロジェクト計画プロセスの

一部として,そのプロジェクトのために選択する。選択されたライフサイクルモデルの段

階の目的及び成果を達成するために,組織が採用したプロセスを修整(tailor)することが

適切な場合がある。

注記 3  プロジェクトがこの規格を直接的に適用する場合,適切なライフサイクルモデルの段階の

目的及び成果を達成するために,この規格のプロセスを修整(tailor)することが適切な場

合がある。

e)

修整(tailor)を必要とするライフサイクルプロセスを選択し,選択された成果,アクティビティ又は

タスクを削除する。

注記 1  修整(tailor)に関わりなく,組織及びプロジェクトは,この規格に適合するために要求さ

れる成果又はアクティビティ及びタスクのほかに,追加の成果を達成するか又は追加のア

クティビティ及びタスクを実施するプロセスを実施することは常に許される。

注記 2  組織又はプロジェクトは,この規格の規定を修正(modify)したい状況に遭遇することが

ある。他のプロセス,成果,アクティビティ又はタスクに予測できない結果に至る可能性

があるので,修正(modification)を避けることが望ましい。必要な場合は,

[修整(tailor)

された適合性を適切に主張して]規定を削除することによって修正(modification)が実行

され,かつ,影響に注意深く配慮して,修整(tailor)された規格の成果又はアクティビティ

及びタスクのほかに,追加の成果を達成するか又は追加のアクティビティ及びタスクを実

行するプロセスを実施することによって修正(modification)が実行される。


61

X 0170

:2013 (ISO/IEC 15288:2008)

附属書 B

参考)

アセスメント目的のプロセス参照モデル

B.1

序文

この規格の利用者の中には,実施されたプロセスを JIS X 0145-2:2008 に従ってアセスメントを実施した

いと思っている人がいることが知られている。この

附属書 は,JIS X 0145-2 との関連において使用する

と適切なプロセス参照モデルを提供する。

注記  附属書 で引用する“JIS X 0145-2”は,全て 2008 年版のことである。

プロセス参照モデルは,各プロセスの名称,目的の記述及び成果の記述を含めて,この規格の本文中の

プロセスから構成されている。B.3 は,プロセス参照モデルの中のプロセス及び自身を定義する箇条を識

別している。

B.2

JIS X 0145-2

との適合

B.2.1

概要

この

附属書 に含まれるプロセス参照モデルは,JIS X 0145-2 に従ったプロセスアセスメントに使用す

るのに適している。

JIS X 0145-2

の 6.2 は,

その規格によるアセスメントに適しているプロセス参照モデルに対する要求事項

を示している。B.2.2 は,プロセス参照モデルに対する要求事項を引用し,この規格がどのようにこれらの

要求事項を満たしているかを記述する。B.2.2 及び B.2.3 の斜体の文章は,JIS X 0145-2 の文章から要求事

項を引用したものであり,斜体でない文章は,要求事項がこの規格によってどのように満たされるかを記

述している。

B.2.2

プロセス参照モデルに対する要求事項

プロセス参照モデルは,次を含む。 

a)

プロセス参照モデルの領域の宣言

これは,箇条 に規定されている。

b)  JIS X 0145-2

の 6.2.4 の要求事項を満足するプロセス参照モデルの適用範囲内のプロセスの記述 

これは,B.3 に規定されている。

c)

プロセス参照モデルとそれを利用しようとしている背景との間の関係の記述 

これは,箇条 に規定されている。

d)

プロセス参照モデル内に定義しているプロセスの間の関係の記述 

これは,各プロセス記述において B.3 に規定されている。例えば,プロセスの記述の中には,プロ

セスが下位のプロセスを含むという記述を含むものがある。

プロセス参照モデルは,そのモデルに関心をもっている人たち及びその人たちの中で合意を得るた

めの行動を,次のように文書化する。 

1)

直接的に関心のある人たちを特徴付けるか,指定する。直接的に関心のある人たちは,この規格及

び JIS X 0160 の利用者である。

2)

合意の達成度合いを文書化する。この規格及び JIS X 0160 は,ISO/IEC JTC 1 の合意の要求事項を

満たす規格である。


62

X 0170

:2013 (ISO/IEC 15288:2008)

3)

合意達成のための行動をとらない場合,このような趣旨のことを文書化する(該当なし)

プロセス参照モデル内で定義されたプロセスは,一意のプロセス記述及び識別情報をもっている。プロ

セスの記述は一意であり,識別は一意の名前及びこの

附属書 の箇条番号による。

B.2.3

プロセスの記述

プロセス参照モデルの基本的な構成要素は,そのモデルの適用範囲内でのプロセス記述である。プロセ

ス参照モデルでのプロセス記述は,プロセスの目的の十分な達成を実証する一連の成果とともに,プロセ

スを実施する全体的な目標を高い水準で記載したプロセスの目的の記述から成り立っている。これらのプ

ロセス記述は,次の要求事項を満足する。 

a)

プロセスは,プロセスの目的及びプロセスの成果で記述する。 

b)

どのプロセス記述においても,一連のプロセスの成果はプロセスの目的を達成するために必要十分で

ある。 

c)

プロセス記述は,JIS X 0145-2 の箇条 の水準 を超えたところの測定の枠組みの側面を含んでいな

いし,また,暗示もしていない。 

成果の記述の項目には,次のいずれか一つを記述する。 

成果物の作成

状態の重要な変化

明示された制約事項への合致。例えば,要求事項,目標など

これらの要求事項は,この

附属書 の中のプロセスの記述によって満たされる。成果の中にはレベル 2

以上のレベルの能力へ寄与すると解釈されるものもある。しかしながら,関連プロセスの適合した実施は

これらの上位レベルの能力の達成を要しない。

B.3

プロセス参照モデル

プロセス参照モデルは,この規格の箇条 に含まれる各プロセスの目的及び成果の記述によって構成さ

れている。システムライフサイクルに対するプロセス参照モデルは,

図 のプロセス集合から構成されて

いる。


63

X 0170

:2013 (ISO/IEC 15288:2008)

附属書 C 

参考)

プロセスの統合及びプロセスの構成概念

C.1

序文

ISO/IEC JTC 1/SC 7 内の調和化プロジェクト(すなわち,ISO/IEC 12207 及び ISO/IEC 15288 の並行した,

注意深く調整された改正及びこれら両国際規格のガイドラインとなる ISO/IEC TR 24748 の作成)は,シ

ステムライフサイクル及びソフトウェアライフサイクルを記述している統合化された一組の規格への最初

の大きな一歩である。継続的なプロセス改善及び能力アセスメントの概念は,今やかなり確立され,認識

されていて,ISO/IEC 15504 シリーズとして規格化されている。この規格及び JIS X 0160 

附属書 で規

定されたプロセス参照モデルは,ライフサイクルプロセスの能力アセスメントに対して,ISO/IEC 15504

シリーズとともに使用されることを意図している。プロセスの能力判定には,プロセス記述がそのプロセ

スの目的の明確な記述及び期待される成果の記述を含むことを必要としている。プロセスの矛盾のない実

施は,アクティビティ,タスク及び定義された実施の注記をもつことによって支援されている。それゆえ,

システムライフサイクル及びソフトウェアライフサイクルの両ライフサイクル規格におけるライフサイク

ルプロセスは,C.2 に記述されるように,共通のプロセス構成概念に適用されており,ISO/IEC TR 24774

に含まれるプロセス定義の手引と調和している。

C.2

プロセス構成概念及びその使用

この規格の中のプロセスの記述は,明確に定義された規則に従う。まず第一に,それらは,論理的形態

でグループにまとめられている。これらのグループ分けは,次によって決められている。

−  プロセス間の論理的関係

−  プロセスの実行に対する責任

この規格では,システムのライフサイクルで実行するアクティビティを四つのプロセスグループに分け

ている。これらのグループの最上位の記述は,5.3.2 に見いだされる。これらのグループ内の各ライフサイ

クルプロセスは,その目的及び望まれる成果に関して記述されており,これらの成果を達成するために実

施することが必要なアクティビティ及びタスクを列挙している。

a)

合意プロセス

2 個のプロセス(6.1

b)

プロジェクトイネーブリングプロセス

5 個のプロセス(6.2

c)

プロジェクトプロセス

7 個のプロセス(6.3

d)

テクニカルプロセス 11 個のプロセス(6.4

プロセス記述規則の矛盾のない適用によって,正規化した細分箇条の番号付けが可能となる。この規格

の中では,細分箇条番号は,次のようになっている。

−  6.x は,プロセスグループの名称である。

−  6.x.y は,そのグループ内のプロセスの名称である。

−  6.x.y.1 は,プロセスの目的を記述する。

−  6.x.y.2 は,プロセスの成果を記述する。

−  6.x.y.3 は,プロセスのアクティビティ及びタスクを記述する。

−  6.x.y.3.z は,プロセスのアクティビティを列挙する。


64

X 0170

:2013 (ISO/IEC 15288:2008)

−  6.x.y.3.z.α は,アクティビティ内のタスクを列挙する。

図 C.1 は,この規格及び ISO/IEC 15288:2008 の中で使用されているプロセス構成の UML 表現である

図 C.1JIS X 0160 及びこの規格のプロセス構成  

プロセスには,目的及び成果が必要である。全てのプロセスは,少なく

とも一つのアクティビティをもつ。プロセスは,目的及び成果の記述を

伴って,プロセス参照モデル(PRM)を構成する。PRM については,

属書 で説明している。

アクティビティは,関連するタスクをまとめる構造をしている。アクティ

ビティは,プロセスの理解及び伝達を向上するために,プロセス内の関

連するタスクを調べる方法を提供する。アクティビティの凝集度が十分

に高い場合は,目的及び成果の集合を定義することによって,

(より下位

の)プロセスに昇格することができる。

タスクは,プロセスを実行するための詳細な規定である。タスクは,要

求事項(shall)

,推奨事項(should)又は許容事項(may)のいずれかで

ある。

JIS X 0160

及び JIS X 0170 のプロセス構成

プロセス

名称,目的,成果

アクティビティ

名称

タスク

注記

1

1

1

1

1..*

1..*

0..*

0..*

プロセスの意図及び構造をよりわかりやすく説明するために解説的な情

報を必要とするとき,注記を使用する。注記は,潜在的な実施又は適用可

能な領域(例えば,一覧表,例,その他の検討事項など)に関する洞察を

提供する。


65

X 0170

:2013 (ISO/IEC 15288:2008)

附属書 D 

参考)

プロセスビュー

D.1

序文

特定のエンジニアリングの関心を代表している人たちが,彼らの関心事に直接的に,かつ,端的に対応

した一組のプロセスアクティビティを 1 か所に集めて見たいという場合がある。そのような人たちに対し

て,ライフサイクルの全部又は一部を横断する形態で,特定の関心に焦点を当てるために,この規格又は

JIS X 0160

から選ばれたプロセス,アクティビティ及びタスクを編成して,

プロセスビューを作成するこ

とができる。この

附属書 は,これらの場合にプロセスビューを定義するために使用してもよいプロセス

のビューポイントを提供する。

D.2

定義

ビュー:関連する一組の関心事の視点からのシステム全体の表現(ISO/IEC 42010:2007,IEEE Std 

1471-2000

ビューポイント:ビューを組み立て,使用するための表現法の仕様。ビューに対する目的及びビューの

利用者並びに生成及び分析の手法を確立することによって個々のビューを創出する元となるパターン又は

テンプレート(ISO/IEC 42010:2007,IEEE Std 1471-2000

注記  この場合,定義の中で参照される“システム”は,この規格及び JIS X 0160 で規定されたライ

フサイクルプロセスを集めたものである。

D.3

プロセスビューの概念

ライフサイクルプロセスにわたって使われるプロセスにまたがる重要な概念又は脈絡を分かりやすくす

るために,全く異なるプロセスから選ばれたアクティビティ及びタスクに対して,統一した焦点が必要と

される場合があり得る。特定の関心事に対応する単一のプロセスを見付けられなくても,使用するために

アクティビティをどのようにして識別し,

定義するかを,

作業標準の利用者に助言することは有用である。

この目的のために,プロセスビューの概念が公式化された。プロセスのように,プロセスビューの記述

は目的及び成果の記述を含む。プロセスとは異なり,プロセスビューの記述は,アクティビティ及びタス

クを含まない。その代わりに,その記述は,この規格及び JIS X 0160 の様々なプロセスのアクティビティ

及びタスクを用いてどのようにして成果を達成できるかを説明する指針を含んでいる。

プロセスビューは,D.3.1 に見いだされるプロセスビューポイントテンプレートを使用して構成できる。

D.3.1

プロセスビューポイント

プロセスビューは,プロセスビューポイントに適合している。ここに挙げられたプロセスビューポイン

トは,プロセスビューを生成するために使用できる。

プロセスビューポイントは,次によって定義される。

−  その利害関係者:作業標準の利用者

−  それが枠組みとなる関心事:特定のエンジニアリングの関心事を反映するために必要なプロセス

−  結果であるプロセスビューの内容には,次を含んでいる。

−  プロセスビューの名称


66

X 0170

:2013 (ISO/IEC 15288:2008)

−  プロセスビューの目的

−  プロセスビューの成果

−  プロセスビューを実施するプロセス,アクティビティ及びタスクの識別及び記述,並びにこれらのプ

ロセス,アクティビティ及びタスクの元が他の作業標準のどこにあるかを示す参照

注記 1  ビューポイントの文書化に対する要求事項は,ISO/IEC 42010 の 5.3 に含まれている。こ

の記述は,それらの要求事項と矛盾がない。

注記 2  D.4 は,このビューポイントを適用する事例を含んでいる。

D.4

スペシャルティエンジニアリングに対するプロセスビュー

ここでは,スペシャルティエンジニアリングに対するプロセスビューを生み出すためにプロセスビュー

ポイントを適用する例を示す。それは,特に興味深いものとして選択された製品特性の達成に注目するた

めに,プロジェクトがこの規格のプロセス,アクティビティ及びタスクをどのように組み立てるかを解説

することを意図している。

注記  “スペシャルティエンジニアリング”は,システムエンジニアリングにおける主要なエンジニ

アリング(例えば,ハードウェアエンジニアリング,ソフトウェアエンジニアリング,人間工

学など)を除くエンジニアリングドメイン(領域)のことをいう。電磁障害,電気接地(アー

ス)

,安全性,セキュリティ,電力フィルタ・無停電電源などのエンジニアリングドメイン,及

び環境エンジニアリングをシステムエンジニアリングに含めるとき,これらのものを“スペシャ

ルティエンジニアリング”とみなす。

この例は,一般にスペシャルティエンジニアリングと呼ばれる一群の関心事を取り扱う。これには,次

のものに限定はしないが,可用性,保守性,信頼性,安全性,セキュリティ,人的要因,ユーザビリティ

などの領域を含んでいる。これらの“∼性”という語は,時には,

“品質特性”として参照される。これら

の特性は,焦点を当てるために選択された領域内で,指定された要求事項を製品がどの程度うまく満たし

ているかを決定する。

この例は,説明用に提供された一般的な事例で,機能的な特性及び非機能的な特性の幅広い集合を網羅

する一般的な事例であることに注目されたい。それは,プロセスをまたがった幅広いビューを提供する。

実際の利用において,プロセスビューは,特定のスペシャルティエンジニアリングの関心事に対して生成

されることが望ましい。

名称:スペシャルティエンジニアリングプロセスビュー

目的:スペシャルティエンジニアリングプロセスビューの目的は,特に関心のある選択された幾つかの特

性について満足できる水準をシステムが達成することの客観的な証拠を提供することである。

成果:

a)

製品の品質特性は,特別な注目のために選択されている。

b)

特性の達成のための要求事項は,定義されている。

c)

要求事項に対する測定量は,選択され,求められる特性に関係付けられている。

d)

求められる特性を達成するための進め方が設計され,実施されている。

e)

要求事項の達成の範囲は,継続的に監視され,利害関係者及び管理者に連絡されている。

f)

達成度について,文書化及び連絡するための成果物は,指定され,作成され,保守される。

注記  成果は,望まれる特性が直接測定できず,測定可能な他の製品又はプロセス特性に基づいて

議論され,推断されるかもしれないことを許容する。


67

X 0170

:2013 (ISO/IEC 15288:2008)

プロセス,アクティビティ及びタスク 

このプロセスビューは,この規格の次のプロセス,アクティビティ及びタスクを使用して実施できる。

1)

利害関係者要求事項定義プロセス(6.4.1)は,品質特性を含めた特性の選択及び定義並びにそれらを

文書化するための成果物を提供する。アクティビティ及び文書化は,特別の特性についての要求事項

を定義し記録するには有効である。関連のあるアクティビティ及びタスクは,6.4.1.3 の a)  1)及び 2),

b) 2)

及び 4)並びに c) 5)を含む。

注記  JIS X 25030 は,ソフトウェア製品の品質要求事項を明記するのに有効であるかもしれない。

2)

要求事項分析プロセス(6.4.2)は,スペシャルティ要求事項についての測定量の選択を提供する。関

連するアクティビティ及びタスクは,6.4.2.3 の a) 4)及び 5)を含む。

注記  JIS X 25030 は,ソフトウェア製品の品質要求事項を明記するのに有効であるかもしれない。

3)

方式設計プロセス(6.4.3)は,スペシャルティ特性についての設計基準の生成及びそれらの基準に関

して代替設計の評価を提供する。

関連するアクティビティ及びタスクは,

6.4.3.3

の b) 1)及び 4)を含む。

4)

実装プロセス(6.4.4)は,スペシャルティ要求事項が満たされている証拠の記録を提供する。関連す

るアクティビティ及びタスクは,6.4.4.3 の b) 2)を含む。

5)

結合プロセス(6.4.5)は,スペシャルティ要求事項についての配慮を含めて,結合の計画及び特性の

達成が検証され,記録されているという保証を提供する。関連するアクティビティ及びタスクは,

6.4.5.3

の a) 1)並びに b)の 3)及び 5)を含む。

6)

検証プロセス(6.4.6)は,スペシャルティプロパティを含め,検証を実施するための方針の計画及び

実行を提供する。選択された検証方針は,プロパティの達成に影響を及ぼす設計の制約を導入しても

よい。関連するアクティビティ及びタスクは,6.4.6.3 の a) 1)及び 3)並びに b) 2),3)及び 4)を含む。

7)

移行プロセス(6.4.7)は,その運用環境にシステムを導入することを提供する。幾つかのスペシャル

ティプロパティは,設計の制約と運用の制約とのトレードオフを伴うので,導入での注意が重要にな

ることが多い。関連するアクティビティ及びタスクは,6.4.7.3 の b) 2),3),5)及び 6)を含む。

8)

妥当性確認プロセス(6.4.8)は,スペシャルティプロパティを含め,システムの提供するサービスが

利害関係者のニーズに合致している証拠を提供する。関連するアクティビティ及びタスクは,6.4.8.3

の b) 3)及び 5)を含む。

9)

運用プロセス(6.4.9)は,システムの利用を提供する。スペシャルティ要求事項が適切に達成されて

いることを保証することは,システムの運用を監視することを含む。関連するアクティビティ及びタ

スクは,6.4.9.3 の c) 2)並び d) 1)及び 2)を含む。

10)

保守プロセス(6.4.10)は,そのスペシャルティプロパティを含め,システムの能力を維持する。関連

するアクティビティ及びタスクは,6.4.10.3 の b) 3),4)及び 8)を含む。

11)

廃棄プロセス(6.4.11)は,システムの存在を終わらせる。廃棄を予測する固有のニーズは,システム

開発に制約を課することがある。実際,これらの制約は,それ自身スペシャルティエンジニアリング

の対象であってもよい。関連するアクティビティ及びタスクは,6.4.11.3 の a) 2)及び c) 2)を含む。

12)

プロジェクトアセスメント及び制御プロセス(6.3.2)は,要求事項の達成の度合いの監視,及び利害

関係者及び管理者への結果の通知を提供する。関連するアクティビティ及びタスクは,6.3.2.3 の a) 8)

及び 9)を含む。

13)

情報管理プロセス(6.3.6)は,全体として,達成の度合いの文書化及び伝達のための作成物の仕様,

開発及び保守を提供する。スペシャルティエンジニアリングの目的のために使用される成果物は,そ

の性質から,スペシャルティ成果物となることがあるということを書きとめておくことが望ましい。


68

X 0170

:2013 (ISO/IEC 15288:2008)

これらの成果物の記述のための情報源は,工業団体,監視官及び特定の標準を含んでいる。

14)

測定プロセス(6.3.7)は,全体として,望まれるスペシャルティ特性に測定量を関連付けるアプロー

チの定義を提供する。


69

X 0170

:2013 (ISO/IEC 15288:2008)

附属書 E

参考)

この規格と JIS X 0160:2012 との間のプロセスの関係

注記  附属書 で引用する“JIS X 0160”は,全て 2012 年版のことである。

E.1

序文

この

附属書 は,この規格と JIS X 0160 との間のプロセスの関係を記述している。

E.2

関係の記述

次の細分箇条のプロセスの関係は,単純明快である。この規格及び JIS X 0160 は,個々のプロセスに対

して,同一のプロセス名及び同一の細分箇条番号を使用している。

−  6.1  合意プロセス

−  6.2  組織のプロジェクトイネーブリングプロセス

−  6.3  プロジェクトプロセス

それぞれの場合に,JIS X 0160 の中のプロセスは,この規格の中で一般的なプロセスをソフトウェアに

特化することを意図している。

それぞれの規格の 6.4 は,

“テクニカルプロセス”を含んでいる。二つの規格は,これらのプロセスに対

して少々異なる名前を使用している。ある場合には,JIS X 0160 のプロセスは,この規格のプロセスをソ

フトウェアに特化したものである。他の場合には,JIS X 0160 のプロセスは,この規格の対応するプロセ

スの一つ以上の成果の達成に単に寄与するだけである。

表 E.1 は,プロセスを列挙し,それらの関係の性

質を注記するものである。

表 E.1−この規格と JIS X 0160 のテクニカルプロセスとの関係

細分箇条

この規格のプロセス名

JIS X 0160

のプロセス名

関係

6.4 

テクニカルプロセス

テクニカルプロセス

特化

6.4.1 

利害関係者要求事項定義

利害関係者要求事項定義

特化

6.4.2 

要求事項分析

システム要求事項分析

特化

6.4.3 

方式設計

システム方式設計

特化

6.4.4 

実装

実装

特化

6.4.5 

結合

システム結合

特化

6.4.6 

検証

システム適格性確認テスト(

注記 1

成果に寄与

6.4.7 

移行

ソフトウェア導入 
ソフトウェア受入れ支援

成果に寄与 
成果に寄与

6.4.8 

妥当性確認

ソフトウェア受入れ支援(

注記 2

成果に寄与の可能性あり

6.4.9 

運用

ソフトウェア運用

特化

6.4.10 

保守

ソフトウェア保守

特化

6.4.11 

廃棄

ソフトウェア廃棄

特化

最後に,JIS X 0160 の箇条 は,ソフトウェアに固有なプロセスだけを含む。

注記 1  JIS X 0160 では,ソフトウェア検証プロセスは,支援プロセスとして割り当てられたままに


70

X 0170

:2013 (ISO/IEC 15288:2008)

なっていて,箇条 のソフトウェア支援プロセス群に置かれているが,そのプロセスがソフ

トウェアのシステム要素(ソフトウェア品目)のために実施される場合,そのプロセスは,

ISO/IEC 15288

の検証プロセスの一つ以上の成果に寄与することがある。

注記 2  JIS X 0160 では,ソフトウェア妥当性確認プロセスは,支援プロセスとして割り当てられた

ままになっていて,箇条 のソフトウェア支援プロセス群に置かれているが,そのプロセス

がソフトウェアのシステム要素(ソフトウェア品目)のために実施される場合,そのプロセ

スは,この規格の妥当性確認プロセスの一つ以上の成果に寄与することがある。


71

X 0170

:2013 (ISO/IEC 15288:2008)

附属書 F

参考)

他の IEEE 規格との関係

注記  附属書 は,IEEE 規格との関係を記述しているだけで,JIS として必要のない記述であるので,

削除した。


72

X 0170

:2013 (ISO/IEC 15288:2008)

附属書 G 

参考)

参考文献

ANSI/PMI 99-001-2004

,A Guide to the Project Management Body of Knowledge: PMBOK Guide−Third Edition

ISO 6385:2004

,Ergonomic principles in the design of work systems

ISO/IEC 7498-1:1994

,Information technology−Open Systems Interconnection−Basic Reference Model: The

Basic Model

JIS Q 9000:2006

  品質マネジメントシステム−基本及び用語

注記  対応国際規格:ISO 9000:2005,Quality management systems−Fundamentals and vocabulary(IDT)

JIS Q 9001:2000

  品質マネジメントシステム−要求事項

注記 1  対応国際規格:ISO 9001:2000,Quality management systems−Requirements(IDT)

注記 2  JIS Q 9001 及び ISO 9001 は,2008 年版が発行されている。

JIS Q 9004:2000

  品質マネジメントシステム−パフォーマンス改善の指針

注記 1  対 応 国 際 規格 : ISO 9004:2000 , Quality management systems − Guidelines for performance

improvements(IDT)

注記 2  JIS Q 9004 は 2010 年版が,ISO 9004 は 2009 年版が発行されている。

JIS X 0129-1:2003

  ソフトウェア製品の品質−第 1 部:品質モデル

注記  対応国際規格:ISO/IEC 9126-1:2001, Software engineering−Product quality−Part 1: Quality model

(IDT)

TS X 0111-2:2009

  ソフトウェア製品の品質−第 2 部:JIS X 0129-1 による外部測定法

注記  対応国際規格:ISO/IEC TR 9126-2:2003,Software engineering−Product quality−Part 2: External

metrics(IDT)

TS X 0111-3:2009

  ソフトウェア製品の品質−第 3 部:JIS X 0129-1 による内部測定法

注記  対応国際規格:ISO/IEC TR 9126-3:2003,Software engineering−Product quality−Part 3: Internal

metrics(IDT)

TS X 0111-4:2009

  ソフトウェア製品の品質−第 4 部:JIS X 0129-1 による利用時の品質測定法

注記  対応国際規格:ISO/IEC TR 9126-4:2004,Software engineering−Product quality−Part 4: Quality in

use metrics(IDT)

JIS Z 8512:1995

  人間工学−視覚表示装置を用いるオフィス作業−仕事の要求事項についての指針

注記  対応国際規格:ISO 9241-2:1992,Ergonomic requirements for office work with visual display

terminals (VDTs)−Part 2: Guidance on task requirements(IDT)

ISO 10007:2003

,Quality management systems−Guidelines for configuration management

JIS Z 8502:1994

  人間工学−精神的作業負荷に関する原則−用語及び定義

注記  対応国際規格:ISO 10075:1991,Ergonomic principles related to mental work-load−General terms and

definitions(IDT)

JIS Z 8530:2000

  人間工学−インタラクティブシステムの人間中心設計プロセス

注記  対応国際規格:ISO 13407:1999,Human-centred design processes for interactive systems(IDT)

JIS Q 14001:2004

  環境マネジメントシステム−要求事項及び利用の手引


73

X 0170

:2013 (ISO/IEC 15288:2008)

注記  対応国際規格:ISO 14001:2004,Environmental management systems−Requirements with guidance

for use(IDT)

ISO/IEC 15026:1998

,Information technology−System and software integrity levels

注記  この規格は,廃止されている。

ISO/IEC TR 15271:1998

,Information technology−Guide for ISO/IEC 12207 (Software Life Cycle Processes)

注記  この規格は,廃止されている。

ISO/IEC 15289:2006

,Systems and software engineering−Content of systems and software life cycle process

information products (Documentation)

注記 2011 年版が発行されている。

ISO/IEC 15504:2004

,Information technology−Process assessment (multiple parts)

注記  この国際規格の第 1 部∼第 4 部に日本工業規格:JIS X 0145-1:2008,JIS X 0145-2:2008,JIS X 

0145-3:2011

及び JIS X 0145-4:2010,情報技術−プロセスアセスメントが対応。

JIS X 0141:2009

  システム及びソフトウェア技術−測定プロセス

注記  対応国際規格:ISO/IEC 15939:2007,Systems and software engineering−Measurement process(IDT)

JIS X 0162:2008

  システム及びソフトウェア技術−ライフサイクルプロセス−リスク管理

注記  対応国際規格:ISO/IEC 16085:2006,Systems and software engineering−Life cycle processes−Risk

management(IDT)

ISO PAS 18152:2003

,Ergonomics of human-system interaction−Specification for the process assessment of

human-system issues

ISO/TR 18529:2000

,Ergonomics−Ergonomics of human-system interaction−Human-centred lifecycle process

descriptions

ISO/IEC TR 19760:2003

,Systems engineering−A guide for the application of ISO/IEC 15288 (System life cycle

processes)

ISO/IEC TR 24774

, Software and systems engineering− Life cycle management− Guidelines for process

description

JIS X 25030:2012

  ソフトウェア製品の品質要求及び評価(SQuaRE)−品質要求事項

注記  対応国際規格:ISO/IEC 25030,Software engineering−Software product Quality Requirements and

Evaluation (SQuaRE)−Quality requirements(IDT)

ISO/IEC 26702:2007

,Systems engineering−Application and management of the systems engineering process

JIS C 0508

規格群  電気・電子・プログラマブル電子安全関連系の機能安全

注記  対 応 国 際 規 格 : IEC 61508 , Functional safety of electrical/electronic/programmable electronic

safety-related systems (multiple parts)(IDT)


74

X 0170

:2013 (ISO/IEC 15288:2008)

附属書 H 

参考)

参加者一覧

注記  附属書 は,JIS として必要ない記述であるので削除した。