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

X 0160：2012 (ISO/IEC 12207：2008)

（1）

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

ページ

序文 ··································································································································· 1

1 概要······························································································································· 2

1.1 適用範囲 ······················································································································ 2

1.2 目的 ···························································································································· 3

1.3 制限 ···························································································································· 3

2 適合性···························································································································· 3

2.1 意図した用途 ················································································································ 3

2.2 完全適合 ······················································································································ 4

2.3 修整（tailor）適合 ········································································································· 4

3 引用規格 ························································································································· 4

4 用語及び定義 ··················································································································· 4

5 規格の適用 ····················································································································· 11

5.1 規格の重要な概念 ········································································································· 11

5.2 規格の構成 ·················································································································· 15

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

6.1 合意プロセス ··············································································································· 20

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

6.3 プロジェクトプロセス ··································································································· 32

6.4 テクニカルプロセス ······································································································ 42

7 ソフトウェア固有プロセス ································································································ 56

7.1 ソフトウェア実装プロセス······························································································ 56

7.2 ソフトウェア支援プロセス······························································································ 64

7.3 ソフトウェア再利用プロセス··························································································· 76

附属書A（規定）修整（tailoring）プロセス ············································································· 82

附属書B（規定）アセスメント目的のプロセス参照モデル（Process Reference Model: PRM） ············ 84

附属書C（参考）履歴及び理論的根拠 ····················································································· 94

附属書D（参考）この規格とISO/IEC 15288との間のプロセスの関係 ············································ 99

附属書E（参考）プロセスビュー··························································································· 100

附属書F（参考）プロセス記述の例 ························································································ 103

附属書G（参考）この規格とIEEE Std 12207及び他のIEEE規格との関係 ···································· 106

附属書H（参考）参考文献 ··································································································· 112

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

日本工業規格 JIS

X 0160：2012

(ISO/IEC 12207：2008)

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

Systems and software engineering−Software life cycle processes

序文

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

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

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

JIS X 0160は，1996年に発行された規格で，大きなシステムの一部であるソフトウェアに対して，かつ，

単独のソフトウェア製品及びソフトウェアサービスに対して，包括的な一連のライフサイクルプロセス，

アクティビティ及びタスクを規定する最初の規格である。1996年版のJIS X 0160に引き続いて，2004年6

月にシステムライフサイクルプロセスを規定するJIS X 0170が発行された。ソフトウェアの普遍性が意味

することは，ソフトウェア及びその設計プロセスはそれらのシステム（JIS X 0170の対象であるシステム）

から切り離して考えるのではなく，システム及びシステム設計プロセスの不可欠な部分であると考えるこ

とが望ましいということである。2007年に発行されたJIS X 0160追補1（これは，2002年及び2004年に

発行されたISO/IEC 12207の追補をまとめたものである。）では，プロセスの目的及びプロセスの成果を

追加し，JIS X 0145-2の要求事項に従って，プロセス参照モデルを設定している。

この規格（すなわち，追補を含めたJIS X 0160の改正版）は，システムライフサイクルプロセス及びソ

フトウェアライフサイクルプロセス並びにそれらの適合のための指針を完全に統合化した集合に到達する

ためのISO/IEC JTC1/SC7の調和戦略を進める第一歩である。

この改正版は，JIS X 0160:1996とJIS X 0160追補1:2007とを統合し，プロセス定義が整合性及び改善

されたユーザビリティを支援するようにISO/IEC JTC1/SC7の手引を適用している。統合プロジェクトの実

施においては，構造，用語並びに対応する組織のプロセス及びプロジェクトのプロセスと整合させるため

に，JIS X 0170:2004の並行的改正と注意深い調整とを行った。

この規格は，次の一つ以上の状況で使用できる。

− 組織で使用する場合：望まれるプロセスの環境の確立（整備）を支援するため。これらのプロセスは，

方法，手順，手法，ツール及び教育された個人という基盤によって支援することができる。そのとき，

組織は，システムのライフサイクル段階を通して，そのプロジェクトを実行し管理するため及びシス

テムを達成させるためにこの環境を採用してもよい。この状況では，この規格は，ライフサイクルプ

ロセスの宣言され，確立された集合の適合性をその規定に照らし合わせて，アセスメント（評価診断）

するために使用される。

− プロジェクトで使用する場合：ソフトウェア製品及びソフトウェアサービスを提供するために，ライ

フサイクルプロセスの確立された集合の要素の選択及び構造化を支援するため。この状況では，この

規格は，宣言され，確立された環境に対するプロジェクトの適合性をアセスメント（評価診断）する

ために使用される。

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

− 取得者及び供給者が使用する場合：プロセス及びアクティビティに関する合意の形成を支援するため。

合意によって，この規格の中のプロセス及びアクティビティを選択し，協議し，合意し，実行する。

この状況では，この規格は，合意形成のためのガイドとして使用される。

− 組織及びアセスメント担当者が使用する場合：組織のプロセス改善を支援するために使用できるアセ

スメントを実行するため。

この規格は，四つの箇条に要求事項を含んでいる。

箇条6では，システムライフサイクルプロセスに対する要求事項を規定している。箇条7では，特定の

ソフトウェアライフサイクルプロセスに対する要求事項を規定している。附属書Aでは，この規格の修整

のための要求事項を規定している。附属書Bでは，アセスメントの目的のために使用されるプロセス参照

モデルを規定している。

五つの参考の附属書は，この改正版で開始された調和戦略を裏付けている。

− 附属書Cは，変更の履歴及び理論的根拠を展開し，この改正版への入力として使用された国際規格の

間の高いレベルの追跡可能性を提供している。

− 附属書Dは，この改正版の重要な焦点である，ISO/IEC 15288のプロセスとJIS X 0160のプロセスと

の整合を記述している。

− 附属書Eは，特別の関心があるとして選択された製品特性の達成に注力するために，プロジェクトが

どのようにしてJIS X 0160のプロセス，アクティビティ及びタスクを組み立てることができるかを例

示することを意図して，ユーザビリティに対するプロセスビューの例を提供している。

− 附属書Fは，この規格の読者に有益だと思われるプロセス記述の事例を含んでいる（提供している。）。

− 附属書Gは，IEEEの利用者への支援を提供しており，この規格とIEEE規格との関係を記述してい

る。

この規格の読者は，使用された重要な概念について理解を得るために，箇条5を参考にすることを推奨

する。

注記現在作成中の技術報告書（ISO/IEC TR 24748）には，この規格とISO/IEC 15288:2008（邦訳JIS

X 0170:2012が発行される予定）との関係を記述することになる。

概要

1.1

適用範囲

この規格は，明確に定義された用語を使用し，ソフトウェアライフサイクルプロセスの共通枠組みを規

定しており，ソフトウェア産業界で参照することができる。この規格は，プロセス，アクティビティ及び

タスクから構成され，ソフトウェア製品及びソフトウェアサービスを取得するとき，並びにソフトウェア

製品の供給，開発，運用，保守及び廃棄をするときに，適用できる。ソフトウェアは，ファームウェアの

ソフトウェア部分を含む。

この規格は，次のことが組織に対して内部的に又は外部的に実施されるかどうかにかかわらず適用する。

− システム，ソフトウェア製品及びソフトウェアサービスの取得

− ソフトウェア製品及びシステムのソフトウェア部分の供給，開発，運用，保守及び廃棄

この規格は，ソフトウェア製品及びソフトウェアサービスについての文脈を示すために必要なシステム

定義の側面を含む。

この規格は，ソフトウェアライフサイクルプロセスを定義，制御及び改善する場合に採用できるプロセ

スをも規定している。

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

この規格のプロセス，アクティビティ及びタスクは，単独で又はISO/IEC 15288とともに，ソフトウェ

アを含むシステムを取得するときにも適用できる。

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

ISO/IEC 12207:2008，Systems and software engineering−Software life cycle processes（IDT）

なお，対応の程度を表す記号“IDT”は，ISO/IEC Guide 21-1に基づき，“一致している”こ

とを示す。

1.2

目的

この規格の目的は，ソフトウェア製品のライフサイクルにおける，取得者，供給者及び他の利害関係者

の間で円滑にコミュニケーションを行う場合に必要な定義されたプロセスの集合を提供することである。

この規格は，次の者を対象としている。

1) システム，ソフトウェア製品及びソフトウェアサービスの取得者

2) ソフトウェア製品の供給者，開発者，運用者，保守者，管理者，品質保証管理者及び利用者

この規格は，二者間の契約で使用することを想定しているが，この二者が，同じ組織に属している場合

でも同様に適用できる。この規格が適用される状況としては，非公式な合意から法的に拘束力がある契約

にまで及ぶ。単一の当事者は，一連のプロセスを自ら課して，この規格を適用してもよい。ここに記載し

たことは，市販のソフトウェアの供給者又は開発者がこの規格を使用することを妨げるものではない。

1.3

制限

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

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

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

同類又は同形式の文書の作成を要求することがある。各種の計画書は，その例である。しかしながら，こ

の規格は，何らかの形での文書作成，分冊化，又は合本化を意味しているわけではない。そのような判断

は，この規格の利用者に任されている。

注記ライフサイクルプロセスの情報項目（文書）の内容については，ISO/IEC 15289に規定されて

いる。

この規格は，特定のシステムライフサイクルモデル若しくはソフトウェアライフサイクルモデル，開発

方法論，方法，モデル又は手法を規定しない。この規格の当事者は，そのソフトウェアプロジェクトに適

したライフサイクルモデルを選択し，この規格で規定するプロセス，アクティビティ及びタスクを選択し

たモデルに割り付ける責任をもつ。また，この規格の当事者は，ソフトウェア開発方法を選択，適用して，

そのソフトウェアプロジェクトに適切なアクティビティ及びタスクを実行することにも責任をもつ。

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

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

適合性

2.1

意図した用途

この規格の要求事項は，箇条6，箇条7及び附属書Aに規定されている。この規格は，ソフトウェア製

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

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

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

に適した一そろいのプロセスを選定することを伴う。この規格を適用する場合，この規格に適合している

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

ことを主張する，二通りの方法がある。適合していることの主張は，次の二つの形態のどちらか一つで記

載される。

2.2

完全適合

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

合に対する要求事項の全てを満たしていることを，証拠となる成果を示して，立証することで達成される。

2.3

修整（tailor）適合

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

ないときは，附属書Aに規定された修整（tailor）プロセスに従って，この規格の箇条を選定するか又は修

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

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

することで達成される。

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

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

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

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

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

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

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

注記3 この規格では，“（し）なければならない”（shall）は，この規定の要求事項を表現するために

使用する。“することが望ましい”（should）は，推奨を表すために使用する。“してもよい”

又は“することができる”（may）は，この規格の限度内で許容される一連の行為であること

を示す。

引用規格

この規格には，引用規格はない。

用語及び定義

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

4.1

取得者（acquirer）

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

注記取得者は，納入先，顧客，所有者及び購入者のいずれであってもよい。

4.2

取得（acquisition）

システム，ソフトウェア製品又はソフトウェアサービスを得るためのプロセス。

4.3

アクティビティ（activity）

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

4.4

合意（agreement）

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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

4.5

監査（audit）

要求事項との適合を評価するために権限を与えられた者によって行われるソフトウェア製品及びプロセ

スの独立した評価。

4.6

ベースライン（baseline）

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

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

4.7

構成品目（configuration item）

決められた時点で実利用者が使用する機能を実現し，かつ，全体構成の中で一意に識別できる実体。

注記この規格では，“実体（entity）”という用語は，製品だけでなく，例えば，活動，プロセス，組

織又は人についても包含するように拡張している。

4.8

契約（contract）

拘束力のある，特に法的強制力のある二者間の合意。又は，全て一つの組織の中で行われる同様の内部

合意。

4.9

顧客（customer）

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

注記1 顧客は組織の内部又は外部であることができる。

注記2 JIS Q 9000:2006を編集。

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

4.10

開発者（developer）

ライフサイクルプロセスを通して，開発作業（要求事項分析，設計，受入れテストなどを含む。）を遂行

する組織。

注記この規格では，開発者と実装者とは同義語になる。

4.11

イネーブリングシステム（enabling system）

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

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

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

例えば，対象システムが自動車だとすると，イネーブリングシステムとは，ライフサイク

ルを通していえば，自動車のCAD，CAM，車体の組立工場，修理工場，リサイクル工場な

どを指す。

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

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

能である。

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

4.12

評価（evaluation）

実体が特定の基準を満たしている度合いを系統的に測定すること。

4.13

設備（facility）

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

4.14

ファームウェア（firmware）

ハードウェアデバイス上に読取り専用ソフトウェアとして組み込まれた計算機命令又はデータとハード

ウェアデバイスとの組合せ。

注記そのソフトウェアは，プログラム制御下で容易に修正（modify）できない。

4.15

実装者（implementer）

実装タスクを行う組織。

注記この規格では，開発者と実装者とは同義語である。

4.16

ライフサイクル（life cycle）

システム，製品，サービス，プロジェクト又は他の人工実体の，概念から廃止までの漸進的な変化。

4.17

ライフサイクルモデル（life cycle model）

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

ュニケーション及び理解のための共通に参照できる役割をもつもの。

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

である。最上位の作業のくくりが“プロセス”，その“プロセス”の構成要素が“アクティビテ

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

4.18

保守者（maintainer）

保守作業を実施する組織。

4.19

監視（monitoring）

取得者又は第三者による，供給者の作業の状況及び作業結果の検査。

4.20

非納入品目（non-deliverable item）

ソフトウェア製品の開発で必要となるハードウェア製品又はソフトウェア製品であるが，契約上は納入

する必要がないもの。

4.21

市販の製品（off-the-shelf）

（製品の場合）既に開発が終わり，使用できる製品。

4.22

運用者（operator）

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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

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

る。

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

4.23

組織（organization）

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

注記1 JIS Q 9000:2006を編集。

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

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

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

注記4 組織的実体の形態は，エンタープライズと呼ばれることが多いので，この規格の組織の見方

はエンタープライズにも同様に適用する。

4.24

当事者（party）

契約に関わる組織。

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

4.25

プロセス（process）

インプットをアウトプットに変換する，相互に関連する又は相互に作用する一連の活動（JIS Q

9000:2006）。

4.26

プロセス目的（process purpose）

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

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

4.27

プロセス成果（process outcome）

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

注記成果の記述書は，次の一つを記述する。

− 成果物の作成

− 状態の重要な変化

− 明示された制約事項への合致。例えば，要求事項，目標など。

4.28

製品（product）

プロセスの結果（JIS Q 9000:2006）

4.29

プロジェクト（project）

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

始日及び終了日がある取組み。

注記1 JIS Q 9000:2006を編集。

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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

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

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

4.30

プロジェクトポートフォリオ（project portfolio）

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

4.31

適格性確認（qualification）

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

4.32

適格性確認の要求事項（qualification requirement）

ソフトウェア製品を適格とするために満たす必要のある基準又は条件の集合。そのソフトウェア製品は，

仕様に適合し，かつ，実環境又はそれを含むシステムとの結合において利用可能である。

4.33

適格性確認テスト（qualification testing）

ソフトウェア製品が仕様に適合し，かつ，実環境又はそれを含むシステムとの結合において利用可能で

あることを実証するテスト。このテストは，開発者が行い，必要な場合には，取得者が立ち合い，確認す

る。

4.34

品質保証（quality assurance）

実体が品質要求事項を満たすことについての十分な自信を与えるために，品質システムの中で実施され，

必要に応じて実証される，全ての計画的かつ体系的な活動。

注記1 品質保証には，次に示す内部目的及び外部目的がある。

a) 内部品質保証組織内においては，品質保証は管理に対して信頼を与える。

b) 外部品質保証契約下では，品質保証は顧客又はその他に対して信頼を与える。

注記2 品質管理活動及び品質保証活動の一部は相互に関連している。

注記3 品質要求事項が利用者のニーズを完全に反映していないときは，品質保証が十分な信頼を与

えないこともある。

4.35

リリース（release）

特定の目的（例えば，テストリリース）のために用意された構成品目の特定の版。

4.36

提案依頼書［request for proposal (tender)］

指定されたシステム，ソフトウェア製品又はソフトウェアサービスを取得するために，取得者が入札希

望者に対しその意図を伝えるために用いる文書。

4.37

資源（resource）

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

注記1 資源には，要員，設備，資本設備，道具などの多様な実在物及び電力，水，燃料，通信基盤

などの公益物を含めてよい。

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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

ものでもよい。

4.38

廃止（retirement）

新システムに一部若しくは全体を置き換えするか，又は改定したシステムを導入することで，運用又は

保守組織が実施中の支援を中止すること。

4.39

セキュリティ（security）

権限を与えられていない者又はシステムが読み込んだり修正（modify）できないように，かつ，権限を

与えられている者又はシステムがアクセスを拒否されないように，情報及びデータを保護すること。

4.40

サービス（service）

製品に付随した活動，作業又は職務の遂行。

4.41

ソフトウェア品目（software item）

ソースコード，オブジェクトコード，制御コード，制御データ又はこれらの品目の集まり。

注記ソフトウェア品目は，ISO/IEC 15288:2008のシステム要素とみなすことができる。

4.42

ソフトウェア製品（software product）

計算機プログラム，手続並びにその関連する文書及びデータを含めたまとまり。

4.43

ソフトウェアユニット（software unit）

別々にコンパイル可能なコードのひとまとまり。

4.44

段階（stage）

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

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

ストーンに関係する。

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

4.45

利害関係者（stakeholder）

システムに，権利，持分，請求権又は関心をもっている個人又は組織。又は，ニーズ及び期待に合致す

る特性をシステムがもっていることに，権利，持分，請求権又は関心をもっている個人又は組織。

4.46

作業記述書（statement of work）

取得者が契約下で実施する作業を明確に記述するために使用する文書。

4.47

供給者（supplier）

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

注記1 “供給者”は，請負業者，生産者，販売者又はベンダ。

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

注記2 時には取得者及び供給者は，同一の組織に属する。

4.48

システム（system）

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

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

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

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

合は，例えば“航空機システム”を“航空機”という用語に置き換えられることができる。

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

4.49

システム要素（system element）

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

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

システム要素は，ハードウェア，ソフトウェア，データ，人間，プロセス（例えば，利用者に

サービスを提供するプロセス），手順（例えば，操作指示），施設，資材及び自然に発生する実

体（例えば，水，有機体，ミネラル）又はそれらの組合せであり得る。

4.50

タスク（task）

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

4.51

テスト網羅性（test coverage）

システム又はソフトウェア製品に対する要求事項について，テストケースを使用してテストできる程度。

4.52

テスト可能性（testability）

要求事項が満たされているかどうかを決定するために，客観的かつ実行可能なテストが設計できる程度。

注記 JIS X 0129-1では，“testability”を“テスト可能性”ではなく，ソフトウェアの品質特性の観点

から“試験性”と訳している。この場合は，修正したソフトウェアの妥当性の確認に必要な労

力に影響する，ソフトウェアの属性を意味する用語として使われている。この規格では，用語

の趣旨がJIS X 0129-1の趣旨と異なるので，訳語を変えている。

4.53

利用者（user）

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

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

4.54

妥当性確認（validation）

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

ることを確認すること（JIS Q 9000:2006）。

注記ライフサイクルの関連でいう妥当性確認とは，意図された用途，ゴール及び目標をシステムが

達成できることを確実にし，信任を得る一連のアクティビティである。

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

4.55

検証（verification）

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

9000:2006）。

注記ライフサイクルでいう検証とは，ライフサイクルにおける任意の成果をその成果に必要とされ

る特性と比較するという一連のアクティビティである。これには，特定の要求事項，設計記述

及びシステム自身を含めてもよく，それだけに限られるものでもない。

4.56

版（version）

ある品目の識別された実例。

注記ソフトウェア製品の版の修正（modify）を行って新しい版とする場合は，構成管理の処置をと

る必要がある。

規格の適用

ここでは，ソフトウェア製品及びソフトウェアサービスの取得，供給，開発，運用，保守及び廃棄に使

用できるソフトウェアライフサイクルプロセスの概要について規定する。この箇条は，この規格の利用者

が規格の中で自分の位置を確認し，規格を思慮深く適用できるように，道筋を提供することを目標とする。

5.1

規格の重要な概念

5.1では，この規格を読み，適用するに当たって役に立つ重要な概念を紹介する。この規格では，少数で

はあるが，普通に使われている単語を，特別な用法で使っていることがある。5.1では，これらの特別な用

法も説明する。これらの概念は，ISO/IEC TR 15271で詳しく説明している。

注記 ISO/IEC TR 24748（第1部〜第3部は発行済み。第4部は作成中）でも詳細を提供する。

5.1.1

ソフトウェア製品とソフトウェアサービスとの関係

一般に，この規格は，ソフトウェア製品及びソフトウェアサービスの両者に適用する。特定のプロセス

の規定は，それらの適用性を記述する。

注記 ISO/IEC 20000規格群は，サービス提供者が管理されたサービスを提供するためのプロセス，

要求事項及び手引を規定している。

5.1.2

システムとソフトウェアとの関係

この規格は，システムとそのソフトウェアとの間の強い結び付きを確立する。それは，システムエンジ

ニアリングの一般的な原理に基づいている。ソフトウェアは，全体システムを構成する不可欠の部分とし

て扱われており，そのシステムにおいて，ある機能を実行する。これは，システム要求事項及び設計から

ソフトウェア要求事項を抽出し，ソフトウェアを作り出し，それをシステムの中に統合することによって

実装される。たとえシステムがソフトウェアを実行する処理装置だけから構成されているとしても，ソフ

トウェアがシステムとの関連で常に存在することは，この規格の基本的な前提である。それゆえに，ソフ

トウェア製品又はソフトウェアサービスは常にシステムにおける一つの品目として扱われる。例えば，こ

の規格は，システム要求事項分析及びソフトウェア要求事項分析を区別している。なぜならば，一般的に

は，システム方式設計は，システム要求事項をシステムの様々な品目に割り当て，ソフトウェア要求事項

分析は，各ソフトウェア品目に割り当てられたシステム要求事項からソフトウェア要求事項を導出する。

もちろん，場合によっては，システムの非ソフトウェア品目が少な過ぎて，システム要求事項分析とソフ

トウェア要求事項分析とを区別することは不必要になることもある。

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

この規格は，ISO/IEC 15288:2008システムライフサイクルプロセスと強い関係をもっており，それとと

もに使用してもよい。多くの場合に，この規格のプロセスは，ISO/IEC 15288のプロセスに直接的に対応

しているが，ソフトウェア製品及びソフトウェアサービスについては若干の特化したものを含んでいる。

顕著な例としては，この規格のソフトウェア実装プロセスは，ISO/IEC 15288の実装プロセスに詳細を加

えて特化したものである。

システムが重要な非ソフトウェア要素を含んでいる場合，組織は，適切なライフサイクルプロセスを規

定するためにISO/IEC 15288の適用を希望してもよい。システムの各ソフトウェア要素に対して，組織は，

そのソフトウェア要素を作り出すために，この規格のソフトウェア実装プロセスを適用する。

システムの非ソフトウェア要素の部分が最小限である場合に，組織は，ISO/IEC 15288を参照すること

なくこの規格を適用してもよい。この規格では，ソフトウェアに対して最小限の適切なシステム関連を規

定するために，ソフトウェアのニーズに特化してはいるが，システムレベルのプロセスを幾つか追加して

いる。

この規格をISO/IEC 15288と併せて適用するときに，用語上の一つのさ（些）細な不一致を，考慮しな

ければならない。ISO/IEC 15288では，システムをシステム“要素”の集合に分解している。これらの要

素のあるものは，この規格を用いて実装されるソフトウェア製品であると決めることができる。この規格

は，システムの主要な要素を参照するために“品目”という用語を使用している。要するに，ISO/IEC 15288

で用語“ソフトウェアの要素”を使用しているところに，この規格では用語“品目”を使用している。

品目のあるものを，いずれは構成管理の対象として指定することがあるが，その場合は“構成品目”と

呼ぶ。ソフトウェア方式設計プロセスは，品目を“構成部品”に変換し，ソフトウェア詳細設計プロセス

は，構成部品を“ユニット”に精緻化する。

5.1.3

組織及び当事者

この規格では，“組織”と“当事者”とは密接に関係している。組織は，識別された責任及び権限をもつ

人々の集団であり，クラブ，組合，会社，学会など特定の目的のために構成されたものをいう。組織は，

全体か一部として契約に関わった場合には，それは当事者である。当事者は，同じ組織に属してもよいし，

又は別の組織に属してもよい。責任及び権限が与えられている場合には，個人は，組織の一例である。

組織又は当事者の名前は，それが責任をもつプロセスから導き出される。例えば，取得プロセスを行う

ときは，取得者と呼ばれる。それゆえに，この規格で取得者，供給者，実装者，保守者及び運用者という

用語が使われるときに，それらは，一般的な意味をもつのではなく，その代わりに，類似の名前をもつプ

ロセスを実行する責任がある組織又は当事者を指す。

この規格の中では，組織に対して他の用語が三つ使われている。“利用者”は，ソフトウェア製品又はサ

ービスの活用によって利益を得る組織のことである。“顧客”は，利用者と取得者とをひとまとめにして指

す。さらに，“利害関係者”は，プロジェクトの成功に関心をもつ組織を指す。

プロセス及び組織（又は当事者）は，機能的に関連しているだけである。この規格は，組織（又は当事

者）の構造を指示したり，暗示したりしない。

この規格は，様々な組織に役立つプロセスの包括的な集合を規定している。大小にかかわらず，組織は，

その業務目的又は取得戦略に従って，その目的を達成するために適切なプロセス（並びに関連したアクテ

ィビティ及びタスク）の集合を選ぶことができる。組織は，一つのプロセス又は二つ以上のプロセスを行

うことがある。一つの契約の下又はこの規格の適用の下で，任意の当事者は，取得プロセス及び供給プロ

セスの両方を行わない方がよいが，他のプロセス（複数）を行うことはできる。一つのプロセスを，一つ

の組織又は二つ以上の組織が行うことがある。二つ以上の組織が行うプロセスの例は，ソフトウェアレビ

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

ュープロセスである。

この規格は，二つ以上の組織が，内部的又は外部的に，適用することを意図している。内部的に適用す

る場合，二つの合意当事者は，通常は，異なる状況の下で手続の点で異なってもよいという合意条件の下

に行動する。外部的に適用されるときは，通常は，二つの合意当事者は契約の条件の下に行動する。内部

的か契約上かのいずれかで，この規格を容易に適用するために，タスクは，契約上の書き方で表されてい

る。内部的に適用されるときは，契約上の書き方は，自身に課した規律として解釈することになる。

この規格の目的のために，いかなるプロジェクトも組織を背景において行うと想定している。これは，

重要なことである。なぜならば，ソフトウェアプロジェクトは，組織（例えば，プロジェクトに配置する

従業員，プロジェクトメンバを収容する施設など）の業務プロセスによって生み出される様々な成果に依

存しているからである。この目的のために，この規格は，“組織のプロジェクトイネーブリング”プロセス

の集合を規定する。これらのプロセスは業務を運用するのに適切であるとは想定していないし，いかなる

個々のプロジェクトプロセスも完全に定義されているとは想定していない。そうではなく，プロセス（複

数）は，集まりとみなされ，プロジェクトが組織の上に置く最小の依存関係の集合を記述することを意図

している。

5.1.4

組織レベル及びプロジェクトレベルでの採用

現代のソフトウェア企業は，その企業のソフトウェアプロジェクトに繰返し適用するソフトウェアライ

フサイクルプロセスの強固な集合を作成するために努力している。それゆえに，この規格は，組織レベル

でもプロジェクトレベルでも採用すれば有効であるように意図している。組織は，この規格を採用し，そ

れを適切な手順，プラクティス，ツール及び方針で補う。組織のソフトウェアプロジェクトは，一般的に

は，この規格に直接適合するよりもむしろ組織のプロセスに適合することになる。

場合によっては，組織レベルで適切なプロセスの集合を定めていない組織がプロジェクトを実行するこ

とがあってもよい。そのような場合には，プロジェクトはこの規格の規定をプロジェクトに直接適用して

もよい。

5.1.5

修整（tailor）

附属書Aは，この規格の修整（tailor）を行うのに必要とされる基本的アクティビティを規定する。

修整（tailor）した結果，この規格に適合することの主張が受け入れられる程度が減少するかもしれない

ことに注目することが望ましい。その理由は，修整（tailor）した結果，望ましい規定をどの程度削除した

かを他の組織が理解することが難しいからである。単一の当事者として，この規格に適合していることを

主張する組織は，多数の修整（tailor）されたプロセスの一覧を挙げて適合を主張するよりも，少数の修整

（tailor）なしのプロセスの一覧に完全に適合していることを主張する方がより有利であることに気づくこ

ともある。

5.1.6

プロセス間の時間的関係

この規格では，プロセス，そのアクティビティ及びタスクは，説明しやすい順番に並べられている。こ

の説明の位置的関係は，時間依存の実施順序を規定したり，決定付けるものではない。普遍的な時間依存

の順序についての合意又は利用はなされていないので，この規格の利用者は，適切にかつ効果的になるよ

うに，プロセス，アクティビティ及びタスクを選び，順序付けてもよい。この規格は，アクティビティ及

びタスクの暗黙の順序に必ずしもこだわらなくてもよいので，アクティビティ間の繰返し及びタスク内の

反復を奨励する。この規格の当事者は，プロジェクトに使用するライフサイクルモデルを選択し，プロセ

ス，アクティビティ及びタスクをそのモデルに位置付ける責任がある。

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

5.1.7

評価対検証及び妥当性確認

ライフサイクルのいずれかのプロセスに関わる組織は，そのタスクの作成物の評価を行う。ソフトウェ

ア検証プロセス及びソフトウェア妥当性確認プロセスは，付加的な評価の機会である。これらのプロセス

は，プロジェクトに依存する深さで作成物を検証し，妥当性確認するために取得者，供給者又は独立の当

事者が行う。これらの評価は，他の評価と重複又は置換するものではなく，それらを補うものである。ソ

フトウェアレビュープロセス，ソフトウェア監査プロセス，ソフトウェア品質保証プロセス及びライフサ

イクルモデル管理プロセスは，評価のための追加の機会となる。

5.1.8

プロセスの基準

この規格は，ソフトウェアライフサイクルのための枠組みを確立する。ライフサイクルは，ソフトウェ

アによって全部又は一部を満たすことができるアイデア又はニーズに始まり，ソフトウェアの廃止で終わ

る。方式は，プロセスの集合とこれらプロセス間との相互関係によって構築される。ライフサイクルプロ

セスの決定は，まとまり及び責任という二つの基本原則に基づいて行われる。

まとまり：ライフサイクルプロセスは，実践的で実現可能とみなされる最適の範囲でまとまっており，

連動されている。

責任：プロセスは，ソフトウェアライフサイクルでは組織又は当事者の責任の下に置かれる。

5.1.9

プロセスの記述

単一の組織又はプロジェクトにおいて，この規格及びISO/IEC 15288の両方の使用を容易にするために，

この規格のプロセスは，ISO/IEC 15288と同様な方法で記述する。

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

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

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

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

− アクティビティは，成果を達成するために使用する一連の行動である。

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

記述についてのこの形式に関する付加的詳細は，ISO/IEC 24774に見ることができる。

5.1.10 プロセスの一般的特徴

5.1.9に規定された属性は，各プロセスの特性を特徴付ける。実施されたプロセスがこれらの属性に適合

するときは，プロセスの明確に定義された目的及び成果は，その定義されたアクティビティの実施を通じ

て達成される。

これらの基本的属性に加えて，プロセスは，全てのプロセスに共通の他の属性によって特徴付けられる

ことがある。JIS X 0145-2は，プロセス能力に対する測定枠組み内に六つの水準の達成を特徴付ける共通

のプロセス属性を特定している。この規格の附属書Bは，JIS X 0145-2に規定されている高水準のプロセ

ス能力の達成に寄与するプロセス属性一覧を記載している。

5.1.11 プロセスの分解

この規格の各プロセスは，5.1.8に規定された基準を満たしている。規定を明確にするために，プロセス

は，より小さい断片に分解されることもある。プロセスの中には，アクティビティ及び／又はより下位の

レベルのプロセスに分解されるものもある。プロセスの分解された一部分自体がプロセスとなる基準を満

たす場合に，下位のレベルのプロセスとして記述する。分解された単位がプロセスとして基準を満たして

いない場合には，アクティビティとしている。アクティビティは，単にタスクの集まりとみなすことがで

きる（次を参照）。

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

プロセスをより詳細に下位のレベルのプロセスに分解することは，有益なこともある。下位のレベルの

プロセスには，単にアセスメントの目的のために記述しているものがある。こうした下位のレベルのプロ

セスは，規格本体には記述していないが，附属書Bに記述している。いずれの場合にも，附属書Bに記述

している下位のレベルのアセスメントプロセスは，規格本体の中にある関連プロセスの一つのアクティビ

ティを詳述したものである。

タスクは，プロセスの成果の達成を支えることを意図した要求事項，推奨，又は許容行動の形態で表す。

この目的のために，この規格は，タスクの異なる形態の差異を区別するために，英語の助動詞shall，should

及びmayに対応する表現を注意深く使用している。“〜しなければならない（shall）”は，適合のために必

要な規定を表すために使われ，“することが望ましい（should）”は，他の可能性の中で推奨されることを

表すために使われ，“してもよい（may）”は，この規格の限度内で許容される一連の行為を示すために使

われる。追加の参考資料は，規定外の注記又は附属書（参考）の形態で提供されている。

5.1.12 ライフサイクルモデル及び段階

システム又はソフトウェア製品の一生は，段階から構成されているライフサイクルモデルでモデル化で

きる。ライフサイクルモデルは，構想から廃棄までの一生の全て又は現行プロジェクトに対応する一生の

一部を表現するために使用してもよい。ライフサイクルモデルは，プロジェクトの範囲，規模，複雑さ，

変化するニーズ及び機会に応じて適切に，重複し及び／又は繰り返す一連の段階から構成される。各段階

の記述は，目的及び成果を表す記述を含む。ライフサイクルのプロセス及びアクティビティは，その段階

の目的及び成果を満たすために段階の中で選択し，使用される。異なる組織は，ライフサイクルの中で異

なる段階に取り組んでもよい。しかしながら，各段階は，先行段階でのライフサイクルの計画及び決定に

ついての有効な情報に十分な考慮をして，その段階に責任を負う組織が行う。同様に，その段階に責任を

負う組織は，下された決定を記録し，ライフサイクルの後続の段階に関する想定事項を記録する。

この規格は，特定のライフサイクルモデルの使用を要求していない。しかしながら，各プロジェクトは，

適切なライフサイクルモデルで，できれば様々なプロジェクトで使用するように組織が定義しているモデ

ルを定義することを要求している。ライフサイクルモデルを適用することは，プロジェクト管理のために

必要な時間依存性の実行順序を確立する手段となる。

なお，この規格は，特定の段階の使用を要求していない。システムのライフサイクルに対する段階の集

合の例は，概念，開発，製造，利用，支援及び廃止を含んでいる。ソフトウェア製品のライフサイクルに

対する段階の集合の例は，開発，運用及び保守である。

様々な型又は種類のライフサイクルモデルが記述されてきた。これらの形式の例は，ウォーターフォー

ル，漸増開発，進展的開発，スパイラルなどの名前で知られている。単にモデルの型の名前を選ぶことで

は，この規格のプロセスを通じて達成する定義された目的及び成果を含む段階によって構成されるモデル

を定義するという要求事項を満たさないことに留意することが望ましい。

注記 ISO/IEC TR 24748（第1部〜第3部は発行済み。第4部は作成中）では，ライフサイクルモデ

ル及び段階に関する詳細を加える。

5.2

規格の構成

5.2.1

ライフサイクルプロセスの種類

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

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

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

列挙している。

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

a) 合意プロセス

2個のプロセス（5.2.2.1.1及び6.1）

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

5個のプロセス（5.2.2.1.2及び6.2）

c) プロジェクトプロセス

7個のプロセス（5.2.2.1.3及び6.3）

d) テクニカルプロセス

11個のプロセス（5.2.2.1.4及び6.4）

e) ソフトウェア実装プロセス

7個のプロセス（5.2.2.2.1及び7.1）

ソフトウェア支援プロセス

8個のプロセス（5.2.2.2.2及び7.2）

g) ソフトウェア再利用プロセス

3個のプロセス（5.2.2.2.3及び7.3）

ライフサイクルプロセスの目的及び成果は，プロセス参照モデルを構成する。この規格の中では，細分

箇条番号は，次のようになっている。

− 6.a及び7.aは，プロセスグループの名称である。

− 6.a.b及び7.a.bは，そのグループ内のプロセス（又は下位のレベルのプロセス）の名称である。

− 6.a.b.1及び7.a.b.1は，プロセスの目的を記述する。

− 6.a.b.2及び7.a.b.2は，プロセスの成果を記述する。

− 6.a.b.3.c及び7.a.b.3.cは，プロセスのアクティビティ及び細分箇条を列挙する。

− 6.a.b.3.c.d及び7.a.b.3.c.dは，アクティビティ'c'のタスクを列挙する。

次に，これらのライフサイクルプロセスグループを紹介し，図1に示す。

ソフトウェア廃棄

プロセス（6.4.11）

ソフトウェア保守

プロセス（6.4.10）

ソフトウェア運用
プロセス（6.4.9）

ソフトウェア受入れ支援

プロセス（6.4.8）

ソフトウェア導入
プロセス（6.4.7）

システム適格性確認テスト

プロセス（6.4.6）

システム結合

プロセス（6.4.5）

実装プロセス（6.4.4）

システム方式設計
プロセス（6.4.3）

システム要求分析
プロセス（6.4.2）

利害関係者要求定義

プロセス（6.4.1）

テクニカルプロセス

測定プロセス（6.3.7）

情報管理プロセス（6.3.6）

構成管理プロセス（6.3.5）

リスク管理プロセス

（6.3.4）

意思決定プロセス（6.3.3）

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

プロジェクト計画
プロセス（6.3.1）

プロジェクトプロセス

品質管理プロセス（6.2.5）

人的資源管理

プロセス（6.2.4）

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

管理プロセス（6.2.3）

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

プロセス（6.2.2）

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

プロセス（6.2.1）

組織プロジェクト

イネーブリングプロセス

供給プロセス（6.1.2）

取得プロセス（6.1.1）

合意プロセス

再利用資産管理

プロセス（7.3.2）

ドメイン（領域）

エンジニアリングプロセス

（7.3.1）

再利用プログラム管理

プロセス（7.3.3）

ソフトウェア再利用プロセス

ソフトウェア問題解決管理

プロセス（7.2.8）

ソフトウェア監査
プロセス（7.2.7）

ソフトウェアレビュー

プロセス（7.2.6）

ソフトウェア妥当性確認

プロセス（7.2.5）

ソフトウェア検証
プロセス（7.2.4）

ソフトウェア品質保証

プロセス（7.2.3）

ソフトウェア構成管理

プロセス（7.2.2）

ソフトウェア文書化管理

プロセス（7.2.1）

ソフトウェア支援プロセス

ソフトウェア適格性確認
テストプロセス（7.1.7）

ソフトウェア結合
プロセス（7.1.6）

ソフトウェア構築
プロセス（7.1.5）

ソフトウェア詳細設計

プロセス（7.1.4）

ソフトウェア方式設計

プロセス（7.1.3）

ソフトウェア要求事項
分析プロセス（7.1.2）

ソフトウェア実装プロセス

ソフトウェア実装
プロセス（7.1.1）

システム関連プロセス

ソフトウェア固有プロセス

図1−ライフサイクルプロセスグループ

プロセス参照モデルは，特定のプロセス実施の進め方を表現するものではないし，システムライフサイ

クルモデル及びソフトウェアライフサイクルモデル，方法論又は手法を規定するものでもない。その代わ

再利用施策管理

プロセス（7.3.3）

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

りに，参照モデルは，組織がその事業のニーズ及び適用領域に基づいて採用することを意図している。組

織の定義されたプロセスは，顧客の要求事項との関連で組織のプロジェクトが採用する。

プロセスの成果は，プロセスの目的の達成に成功したことを示すために使用する。これは，プロセスア

セッサが組織の実施されたプロセスの能力を決定し，組織のプロセス改善を計画するための元となる資料

を提供するのに役立つ。

5.2.2

ライフサイクルプロセスの要約

この規格には，二つの主要な箇条がある。箇条6は，単独のソフトウェア製品，ソフトウェアサービス

又はソフトウェアシステムを取り扱うためのシステムとの関連を規定する。箇条7は，より大きなシステ

ムの要素であるソフトウェア製品又はソフトウェアサービスの実施において使用するためのソフトウェア

固有のプロセスを含んでいる。

ISO/IEC 15288及びこの規格を同時に使用する場合の便宜のために，箇条6の対応するプロセスは，

（6.a.bレベルで）同一の細分箇条番号にしている。

一般的に，この規格に規定するプロセスの集まりは，ソフトウェアに適切なように特化したもの，又は

ISO/IEC 15288で規定するプロセスの成果に寄与するものである。ISO/IEC 15288で規定するプロセスの

多くは，ソフトウェア固有のプロセスの実施と類似しているように見えるが，それらは目的，成果及び読

者について決定的な違いがある。ISO/IEC 15288及びこの規格の両者の利用者は，各固有プロセスにおい

てはっきりと分かる説明及び備考を必ず考慮することが望ましい。

5.2.2.1

システム関連プロセス

注記 5.1.2で規定したシステムとソフトウェアとの強い結び付きの中でソフトウェア開発を行うプ

ロセスのことをいう。

5.2.2.1.1

合意プロセス

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

プロセスを呼び出すと，取得プロセスは，運用システムとして使用する製品の供給者，運用システムを支

援するサービスの供給者又はプロジェクトで開発するシステム要素の供給者とともに業務を遂行する手段

を提供する。供給プロセスを呼び出すと，供給プロセスは，取得者に納入する製品又はサービスを成果と

してもたらすプロジェクトを遂行する手段を提供する。

一般的には，この規格で規定する合意プロセスは，ISO/IEC 15288で規定する合意プロセスをソフトウ

ェアに適切なように特化したものである。

5.2.2.1.2

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

組織のプロジェクトイネーブリングプロセスは，プロジェクトの開始，支援及び制御によって，製品又

はサービスを取得及び供給するための組織の能力を管理する。このプロセスは，プロジェクトを支援する

ために必要な資源及び基盤を提供し，組織目標及び確立された合意を満足させることを確実にする。この

プロセスは，組織の業務を管理できるようにする業務プロセスの包括的集合を意図してはいない。

組織のプロジェクトイネーブリングプロセスは，次のとおりである。

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

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

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

d) 人的資源管理プロセス

e) 品質管理プロセス

一般的に，この規格に規定された組織のプロジェクトイネーブリングプロセスは，ISO/IEC 15288に規

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

定されたプロセスの対応する集合をソフトウェアに適切であるように特化したものである。

5.2.2.1.3

プロジェクトプロセス

この規格では，計画，アセスメント及び制御に関係しているプロセスを記述するためのまとめ方として，

プロジェクトを選んでいる。これらのプロセスに関連する原則は，組織が行う管理のどの分野にも適用で

きる。

プロジェクトプロセスを二つの種類に分ける。プロジェクト管理プロセスは，プロジェクトの進捗を計

画し，実行し，アセスメントし，制御するために使用する。プロジェクト支援プロセスは，特化した管理

目標を支援する。両者を次に記述する。

プロジェクト管理プロセスは，プロジェクト計画を確立して進展させ，計画に対する実績及び進捗のア

セスメントを行い，プロジェクトの実行を完了時まで制御するために使用する。個別のプロジェクト管理

プロセスは，プロジェクト計画又は予期せぬ事象によって要求された場合，ライフサイクルのどの時点で

も，プロジェクトの階層のどこから呼び出してもよい。プロジェクト管理プロセスを適用する場合の厳密

さ及び形式的手続の度合いは，プロジェクトのリスクの大きさ及び複雑さに依存して決まる。

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

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

プロジェクト支援プロセスは，特化した管理目標を実行するためのタスクの特定の絞り込んだ集合を提

供する。それらは，組織全体から単一のライフサイクルプロセス及びそのタスクにわたる，どの取組みの

管理においても全て存在する。

a) 意思決定管理プロセス

b) リスク管理プロセス

c) 構成管理プロセス

d) 情報管理プロセス

e) 測定プロセス

一般的には，この規格で規定されたプロジェクト支援プロセスは，書式上の若干の差異を除けば，

ISO/IEC 15288で規定するプロジェクト支援プロセスと同一である。幾つかの場合に，ソフトウェア支援

プロセスは，プロジェクト支援プロセスに関連することがある。

5.2.2.1.4

テクニカルプロセス

テクニカルプロセスは，次のことを実施するために使用する。

− システムに対する要求事項を定義する。

− その要求事項を有効な製品に変換する。

− 必要な場合には製品の一貫性のある再生産を可能にする。

− 製品を使用する。

− 要求されたサービスを提供する。

− そのサービスの提供を持続させる。

− サービスを廃止するときにはその製品を廃棄する。

テクニカルプロセスは，組織及びプロジェクトの担当部門が技術的な決定及び行動の結果生じる利益を

最適化し，リスクを軽減できるようにするアクティビティを定義する。これらのアクティビティは，製品

及びサービスが適時性及び可用性，費用対効果，並びに取得組織及び供給組織に要求される機能性，信頼

性，保守性，生産可能性，使用性及びその他の品質を可能にする。また，それらのアクティビティは，製

品及びサービスが，健康，安全，セキュリティ及び環境上の要因を含めた，社会の期待又は社会の法制化

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

された要求事項に適合することを可能にする。

テクニカルプロセスは，次のプロセスから構成される。

a) 利害関係者要求事項定義プロセス（ISO/IEC 15288の利害関係者要求事項定義プロセスの特化）

b) システム要求事項分析プロセス（ISO/IEC 15288の要求事項分析プロセスの特化）

c) システム方式設計プロセス（ISO/IEC 15288の方式設計プロセスの特化）

d) 実装プロセス（ISO/IEC 15288の実装プロセスの特化したものであり，ソフトウェア実装プロセスと

してこの規格の箇条7に詳述されている。）

e) システム結合プロセス（ISO/IEC 15288の結合プロセスの特化）

システム適格性確認テストプロセス（ISO/IEC 15288の検証プロセスの成果を達成するのに寄与する

プロセス）

g) ソフトウェア導入プロセス（ISO/IEC 15288の移行プロセスの成果を達成するのに寄与するプロセス）

h) ソフトウェア受入れ支援プロセス（ISO/IEC 15288の移行プロセスの成果を達成するのに寄与するプ

ロセス）

ソフトウェア運用プロセス（ISO/IEC 15288の運用プロセスの特化）

ソフトウェア保守プロセス（ISO/IEC 15288の保守プロセスの特化）

k) ソフトウェア廃棄プロセス（ISO/IEC 15288の廃棄プロセスの特化）

一般的には，この規格で規定したテクニカルプロセスは，ISO/IEC 15288で規定したテクニカルプロセ

スをソフトウェアに適切なように特化したもの，又はその成果に寄与するものである。多くの場合に，ソ

フトウェア実装プロセスと類似しているように見えるが決定的な違いがある。例えば，システム要求事項

分析及びソフトウェア要求事項分析は，異なる点から始まり，それぞれの読者が異なる。

5.2.2.2

ソフトウェア固有プロセス

5.2.2.2.1

ソフトウェア実装プロセス

ソフトウェア実装プロセスは，ソフトウェアの中に実装することになった，仕様で指定されたシステム

要素（ソフトウェア品目）を作り出すのに使用する。これらのプロセスは，仕様で指定された振る舞い，

インタフェース及び実装制約条件を実装行動に変換し，システム要求事項から導出された要求事項を満た

すシステム要素に帰着する。

統括プロセスは，ソフトウェア実装プロセスであり，ISO/IEC 15288の実装プロセスをソフトウェア固

有の特性に合わせて特化したものである。

ソフトウェア実装プロセスは次のソフトウェア固有の下位プロセスを含んでいる。

a) ソフトウェア要求事項分析プロセス（Software Requirements Analysis Process）

b) ソフトウェア方式設計プロセス（Software Architectural Design Process）

c) ソフトウェア詳細設計プロセス（Software Detailed Design Process）

d) ソフトウェア構築プロセス（Software Construction Process）

e) ソフトウェア結合プロセス（Software Integration Process）

ソフトウェア適格性確認テストプロセス（Software Qualification Testing Process）

5.2.2.2.2

ソフトウェア支援プロセス

ソフトウェア支援プロセスでは，特化したソフトウェアプロセスを実行するためのアクティビティの特

定の絞り込んだ集合を提供する。支援するプロセスは，明確な目的をもつ不可欠な部分としてソフトウェ

ア実装プロセスを助け，ソフトウェアプロジェクトの成功及び品質に寄与する。これらには，次の8プロ

セスがある。

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

a) ソフトウェア文書化管理プロセス（Software Documentation Management Process）

b) ソフトウェア構成管理プロセス（Software Configuration Management Process）

c) ソフトウェア品質保証プロセス（Software Quality Assurance Process）

d) ソフトウェア検証プロセス（Software Verification Process）

e) ソフトウェア妥当性確認プロセス（Software Validation Process）

ソフトウェアレビュープロセス（Software Review Process）

g) ソフトウェア監査プロセス（Software Audit Process）

h) ソフトウェア問題解決プロセス（Software Problem Resolution Process）

5.2.2.2.3

ソフトウェア再利用プロセス

ソフトウェア再利用プロセスグループは，プロジェクトの境界を越えてソフトウェア品目を再利用する

組織の能力を支援する三つのプロセスから構成される。これらのプロセスは，その性格上，特定のプロジ

ェクトの境界の外側で働く他と異なるプロセスである。

ソフトウェア再利用プロセスは，次のとおりである。

a) ドメイン（領域）エンジニアリングプロセス（Domain Engineering Process）

b) 再利用資産管理プロセス（Reuse Asset Management Process）

c) 再利用施策管理プロセス（Reuse Program Management Process）

5.2.3

プロセス参照モデル

附属書Bは，この規格の本文の中に含まれる詳細な要求事項のレベルよりも高い抽象レベルでプロセス

参照モデルを規定している。プロセス参照モデルは，これらのプロセスの能力を測定するためにプロセス

をアセスメントする組織に適用可能である。その目的及び成果は，各プロセスの遂行目標の記述である。

目標の記述があるので，単純な適合性評価とは異なるやり方でのプロセスの効果の程度をアセスメントで

きる。例えば，新規のプロセス定義は，この規格の本文の詳細な規定ではなくて附属書Bの中の目的及び

成果の記述に照らして評価することができる。

注記1 この規格では，“プロセス参照モデル”という用語をJIS X 0145-2と同じ意味で使用する。

注記2 プロセス参照モデルは，JIS X 0145-2を使用してプロセスをアセスメントするためにアセス

メントモデルを開発するときに利用することを意図している。

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

6.1

合意プロセス

6.1.1

取得プロセス

6.1.1.1

目的

取得プロセスは，取得者が表明したニーズを満たす製品及び／又はサービスを得ることを目的とする。

そのプロセスは，顧客のニーズの識別で始まり，取得者が必要とする製品及び／又はサービスの受入れで

終わる。

6.1.1.2

成果

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

a) 取得ニーズ，目標，製品及び／又はサービスの受入れ基準並びに取得戦略が定義されている。

b) 取得者及び供給者両者の期待，責任及び義務を明確に表した合意書が作成されている。

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

d) 取得者が記述したニーズを満たす製品及び／又はサービスが取得されている。

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

e) コスト，スケジュール，品質などの指定された制約が満たされるように，取得が監視されている。

供給者の納入品が受け入れられている。

g) 識別された未決定事項については，取得者及び供給者が合意した満足な結論が得られている。

6.1.1.3

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

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

する。

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

6.1.1.3.1

取得の準備

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

6.1.1.3.1.1

取得者は，システム，ソフトウェア製品又はソフトウェアサービスを取得，開発又は強化す

るための構想又はニーズを記述することによって取得プロセスを開始する。

6.1.1.3.1.2

取得者は，システム要求事項を定義し，分析する。システム要求事項は，関連する設計，テ

スト，適合標準及び手順と一緒に，事業，組織及び利用者の要求事項に加えて，安全性，セキュリティ及

び他の重大要求事項を含むことが望ましい。

6.1.1.3.1.3

取得者は，自分自身でシステム又はソフトウェア要求事項の定義及び分析を行ってもよいし，

このタスクを実行するために供給者を雇っておいてもよい。

6.1.1.3.1.4

取得者がシステム又はソフトウェアの要求事項の分析を供給者に委託したとしても，要求事

項の分析結果を承認する権限は取得者がもっている。

6.1.1.3.1.5

テクニカルプロセス（6.4）は，6.1.1.3.1.2及び6.1.1.3.1.4を実行するために使用することが望

ましい。取得者は，顧客の要求事項を確立するために利害関係者要求事項定義プロセスを使用してもよい。

6.1.1.3.1.6

取得者は，各選択肢に対するリスク，コスト及び利点を含めるために，適切な基準に照らし

て分析することで，取得のための選択肢を検討する。選択肢は，次を含む。

a) 要求事項を満たす市販のソフトウェア製品を購入する。

b) 内部的にソフトウェア製品を開発するか，又はソフトウェアサービスを得る。

c) 契約してソフトウェア製品を開発するか，又はソフトウェアサービスを得る。

d) 上記のa)，b)及びc)を組み合わせる。

e) 既存のソフトウェア製品又はソフトウェアサービスを強化する。

6.1.1.3.1.7

市販のソフトウェア製品を購入するときは，取得者は，次の条件が満たされることを確実に

する。

a) そのソフトウェア製品に対する要求事項が満たされている。

b) 必要な文書が入手できる。

c) 専有権，使用権，所有権，保証及びライセンス付与権が満たされている。

d) ソフトウェア製品に対する今後の支援が計画されている。

6.1.1.3.1.8

取得者は，取得計画を用意し，文書化し，実行することが望ましい。その計画は，次を含む

ことが望ましい。

a) システムに対する要求事項

b) システムの利用計画

c) 使用される契約の形態

d) 関係する組織の責任

e) 使用される支援の構想

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

考慮されたリスクのほかにそのリスクを管理する方法

6.1.1.3.1.9

取得者は，受入れ戦略及び条件（基準）を定義し，文書化する。

6.1.1.3.1.10 取得者は，取得の要求事項を文書化することが望ましい（例えば，提案依頼書）。その内容は，

6.1.1.3.1.6で選んだ取得選択肢によって決まる。取得文書には，該当する次のものを含むことが望ましい。

a) システム要求事項

b) 範囲記述

c) 入札者への指示

d) ソフトウェア製品の一覧

e) 契約条件

外部委託管理

g) 技術的制約（例えば，実環境）

6.1.1.3.1.11 取得者は，その取得のためにこの規格のどのプロセスが適切か決定し，それらのプロセスを

修整（tailor）するために取得要求事項を指定することが望ましい。取得者は，プロセスのいずれかが供給

者以外の当事者によって行われる場合には，指定することが望ましい。そうすれば，供給者は，その提案

書の中で，他の当事者の作業を支援するやり方を定義できる。取得者は，その契約に関係するタスクの範

囲を定義する。

6.1.1.3.1.12 取得文書では，供給者の進捗を取得の監視の一部としてレビューし，監査する時点である契

約の節目も定義する（7.2.6及び7.2.7参照）。

6.1.1.3.1.13 取得要求事項は，取得アクティビティを実行するために選ばれた組織に提示することが望ま

しい。

6.1.1.3.2

取得の通知

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

6.1.1.3.2.1

取得者は，識別された供給者に，製品又はサービスの供給依頼を伝達する。

注記ここでは，技術面及び取引面の共通課題に対して，協調のとれた進め方を実現するために，関

連する供給者及び取得者と情報交換するようなサプライチェーンマネジメント（SCM）提携を

含めてもよい。

6.1.1.3.3

供給者の選定

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

6.1.1.3.3.1

取得者は，提案の評価基準及び要求事項適合への重み付けを含めた，供給者選定の手順を確

立することが望ましい。

6.1.1.3.3.2

取得者は，供給者の提案及び能力の評価に基づき，かつ，取得者自身の受入れ戦略及び条件

に沿うように，供給者を選定することが望ましい。

6.1.1.3.4

契約の合意

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

6.1.1.3.4.1

取得者は，契約を結ぶ前に，そのプロジェクトに対してこの規格を修整（tailor）するための

取得者の要求事項を決定するに当たって，他の当事者を含めてもよい。その当事者は，供給者候補又は必

要な（規制者などの）第三者を含む。この決定において，取得者は，修整（tailor）の要求事項が供給者の

組織的に採用したプロセスに及ぼす影響を考慮する。取得者は，契約の中に修整（tailor）の要求事項を含

めるか又は参照する。

6.1.1.3.4.2

取得者は，納入されるソフトウェア製品又はソフトウェアサービスのコスト及びスケジュー

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

ルを含めた，取得要求事項を示した契約書を用意し，供給者と交渉する。その契約は，再利用可能な市販

のソフトウェア製品に関連した専有権，使用権，所有権，保証及びライセンス付与権に対応している。

6.1.1.3.4.3

契約に基づいた作業が進められていれば，取得者は，供給者との交渉を通して，変更管理の

仕組みの一部として，契約の変更を管理する。契約の変更がプロジェクトの計画，コスト，利益，品質及

びスケジュールに影響しないか調査する。

注記1 取得者は，この規格を適用する場合に，“契約”又は“合意”のどちらの用語を使用するかを

決める。

注記2 取得者と供給者との間の合意は，両者の期待，責任及び義務を明確に表現することが望まし

い。

注記3 契約の変更管理の仕組みは，変更管理の役割及び責任，提案された変更要請及び契約再交渉

の正式さの度合い，並びに影響される利害関係者へのコミュニケーションに対応することが

望ましい。附属書Fは，これを説明するために利用してもよい契約変更管理プロセスの例を

掲載している。

6.1.1.3.5

合意の監視

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

6.1.1.3.5.1

取得者は，ソフトウェアレビュープロセス（7.2.6）及びソフトウェア監査プロセス（7.2.7）

に従って，供給者のアクティビティを監視する。取得者は，必要に応じて，ソフトウェア検証プロセス（7.2.4）

及びソフトウェア妥当性確認プロセス（7.2.5）で，監視を補うことが望ましい。

6.1.1.3.5.2

取得者は，全ての必要な情報を適切な時期に提供し，全ての未解決事項を解決できるように，

供給者に協力する。

6.1.1.3.6

取得者の受入れ

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

6.1.1.3.6.1

取得者は，定義した受入れ戦略及び基準に基づき，受入れを準備することが望ましい。テス

トケース，テストデータ，テスト手順及びテスト環境の準備を含むことが望ましい。供給者の参加の度合

いを，定義することが望ましい。

6.1.1.3.6.2

取得者は，納入ソフトウェア製品又はソフトウェアサービスの受入れレビュー及び受入れテ

ストを行い，全ての受入れ条件を満たしたときに，供給者から納入品を受領する。その受入れ手順は，

6.1.1.3.1.9の規定に従うことが望ましい。

6.1.1.3.6.3

受入れ後，取得者は，納入されたソフトウェア製品の構成管理の責任をもつことが望ましい

（7.2.2参照）。

注記取得者は，供給者が定義した指示に従って，ソフトウェア製品の導入を行うか，又はソフトウ

ェアサービスを行ってもよい。

6.1.1.3.7

取得プロセスの終了

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

6.1.1.3.7.1

取得者は，引き渡された製品又はサービスに対して，供給者に支払いを行うか，又は他の合

意した対価を提供する。

注記1 供給された製品又はサービスが合意条件を満たしており，未決定事項が満足に解決している

場合には，取得者は，支払いを行うか又は他の合意された対価を渡し，合意の終了の通知を

出すことによって，合意を終了する。

注記2 製品又はサービスは，複数回に分割して供給されてもよいし，供給者に複数回に分割して支

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

払いを行うか又は他の合意した対価を提供してもよい。

6.1.2

供給プロセス

6.1.2.1

目的

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

6.1.2.2

成果

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

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

b) 取得者の要求に対応する応答が行われている。

c) 取得者と供給者との間で，製品及び／又はサービスの開発，保守，運用，こん（梱）包，納入及び導

入についての合意が，確立されている。

d) 合意された要求事項を満たす製品及び／又はサービスが，供給者によって開発されている。

e) 合意された要求事項に従って製品及び／又はサービスが，取得者へ納入されている。

合意された要求事項に従って製品が，導入されている。

6.1.2.3

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

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

する。

6.1.2.3.1

供給の機会の判別

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

6.1.2.3.1.1

供給者は，製品又はサービスのニーズをもっている取得者，又はニーズをもっている一つ以

上の組織を代表する取得者の存在及び身元を確認することが望ましい。

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

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

6.1.2.3.2

供給者の提案依頼

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

6.1.2.3.2.1

供給者は，組織の方針及び他の規制を考慮に入れて，提案依頼書の中の要求事項をレビュー

することが望ましい。

6.1.2.3.2.2

供給者は，入札するという決定又は契約を受け入れるという決定を行うことが望ましい。

6.1.2.3.2.3

供給者は，提案依頼書に応じて提案書を用意する。

6.1.2.3.3

契約の合意

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

6.1.2.3.3.1

供給者は，ソフトウェア製品又はソフトウェアサービスを提供するために，取得者と交渉を

し，契約に入る。

6.1.2.3.3.2

供給者は，変更管理の仕組みの一環として契約の修正（modificatio）を要請してもよい。

6.1.2.3.4

契約の実行

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

6.1.2.3.4.1

供給者は，取得要求事項をレビューし，プロジェクトの管理及び保証を行うため，並びに納

入ソフトウェア製品又はソフトウェアサービスの品質保証を行うための枠組みを定義する。

6.1.2.3.4.2 契約に規定されていない場合には，供給者は，プロジェクトの範囲，規模及び複雑度に適した

ライフサイクルモデルを定義又は選択する。ライフサイクルモデルは，複数の段階並びに各段階の目的及

び成果から構成される。この規格のプロセス，アクティビティ及びタスクを選択し，そのライフサイクル

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

モデルに当てはめる。

注記理想的には，このアクティビティは，組織で定義したライフサイクルモデルを使用して行う。

6.1.2.3.4.3 供給者は，プロジェクトの管理及び保証を行うため，並びに納入可能なソフトウェア製品又は

ソフトウェアサービスの品質を保証するための計画に対する要求事項を確立する。計画に対する要求事項

は，資源のニーズ及び取得者の関与を含むことが望ましい。

6.1.2.3.4.4 計画のための要求事項が確立した場合，供給者は，各選択肢に関連したリスク分析を考慮して，

ソフトウェア製品を開発するか又はソフトウェアサービスの提供を行うかの選択肢を検討する。選択肢は

次を含む。

a) 内部の資源を使用して，ソフトウェア製品を開発するか，又はソフトウェアサービスの提供を行う。

b) 下請負契約によって，ソフトウェア製品を開発するか，又はソフトウェアサービスの提供を行う。

c) 内部又は外部の供給源から市販のソフトウェア製品を調達する。

d) 上記a)，b)及びc)を組み合わせる。

6.1.2.3.4.5

供給者は，計画についての要求事項及び6.1.2.3.4.4で選ばれた選択肢に基づいて，プロジェク

ト管理計画を作成し，文書化する。

注記計画に含まれる項目は，次を含むが，それに限定されない。

a) 外部組織を含めた，プロジェクトの組織構造，並びに各組織単位の権限及び責任。

b) テスト環境，ライブラリ，機器，設備，作業標準，手順，ツールなどを含めた（適用できる開発，運

用又は保守のための）技術環境。

c) ソフトウェア製品，ソフトウェアサービス及び非納入品目を含む，ライフサイクルプロセス及びアク

ティビティの作業構成明細（WBS）。これらは，予算，要員配置，物理資源，ソフトウェア規模及び

タスク関連のスケジュールで実行されるもの。

d) ソフトウェア製品又はソフトウェアサービスの品質特性の管理。品質に対する計画をプロジェクト管

理計画とは別に作成してもよい。

e) ソフトウェア製品又はソフトウェアサービスの安全性，セキュリティ及び他の重大性に関する要求事

項の管理。安全性及びセキュリティに対する計画をプロジェクト管理計画とは別に作成してもよい。

下請負契約者の選定及び，もしある場合には，下請負契約者と取得者との間の関与を含む下請負契約

者管理。

g) 品質保証（7.2.3参照）。

h) 検証（7.2.4参照）及び妥当性確認（7.2.5参照），指定がある場合には，検証及び妥当性確認の代行者

との協調作業も含める。

レビュー（7.2.6参照），監査（7.2.7参照），非公式の会議，報告，修正（modification），変更などによ

る取得者の関与，及び実施，承諾，受入れ及び施設への立入りなどの手段による取得者の関与。

要求事項の設定，プロトタイプの実演及び評価などによる利用者の関与。

k) リスク管理。すなわち，技術，コスト又はスケジュールに関する潜在的危険度を含んだプロジェクト

の対象領域の管理。

セキュリティの方針。すなわち，各プロジェクトの組織レベルにおける“知る必要性”及び“情報へ

のアクセス”に関する規則。

m) 各種の規制，必要な証明，専有権，使用権，所有権，保証，ライセンス付与権などから発生する承認。

n) スケジュールの作成，追跡及び報告のための手段。

o) 要員の教育訓練（6.2.4参照）。

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

6.1.2.3.4.6

供給者は，6.1.2.3.4.5で作成されたプロジェクト管理計画を具体化し，実施する。

6.1.2.3.4.7

供給者は次のことを行う。

a) テクニカルプロセス（6.4）に従ったソフトウェア製品の開発。

b) ソフトウェア運用プロセス（6.4.9）に従ったソフトウェア製品の運用。

c) ソフトウェア保守プロセス（6.4.10）に従ったソフトウェア製品の保守。

6.1.2.3.4.8

供給者は，契約したライフサイクルを通じてプロジェクトのソフトウェア製品又はソフトウ

ェアサービスの進捗及び品質を監視し，制御する。これは継続的な，繰返しタスクで，次を提供する。

a) 技術的実績，コスト及びスケジュールの進捗の監視並びにプロジェクトの状態の報告。

b) 問題の識別，記録，分析及び解決。

6.1.2.3.4.9

供給者は，取得プロセス（6.1.1）に従って，下請負業者を管理し，制御する。供給者は，主

契約要求事項に従って，取得者に納入されるソフトウェア製品が開発されていること又はソフトウェアサ

ービスが行われることを確実にするために必要な，全ての契約要求事項を下請負業者へ伝える。

6.1.2.3.4.10 供給者は，契約及びプロジェクト計画で指定する独立した検証確認者，妥当性確認者又はテ

スト代行者と協調して作業を進める。

6.1.2.3.4.11 供給者は，契約及びプロジェクト計画で指定する他の当事者と協調して作業を進める。

6.1.2.3.4.12 供給者は，取得者の組織との契約レビュー活動，折衝及びコミュニケーションを調整するこ

とが望ましい。

6.1.2.3.4.13 供給者は，契約及びプロジェクト計画に指定されているように，取得者との非公式会議，受

入れレビュー，受入れテスト，共同レビュー及び監査を行うか又は支援する。共同レビューは，7.2.6に従

って行い，監査は，7.2.7に従って行う。

6.1.2.3.4.14 供給者は，ソフトウェア製品又はソフトウェアサービス及びプロセスがそれぞれの要求事項

を十分満たすことを示すために，検証及び妥当性確認をそれぞれ7.2.4及び7.2.5に従って行うことが望ま

しい。

6.1.2.3.4.15 供給者は，契約に指定されているように，評価，レビュー，監査，テスト，及び問題解決の

報告書を取得者が利用できるようにする。

6.1.2.3.4.16 供給者は，契約及びプロジェクト計画に指定されているように，ソフトウェア製品又はソフ

トウェアサービスのレビューのために，供給者の施設及び下請負業者の施設に，取得者が立ち入れるよう

にする。

6.1.2.3.4.17 供給者は，7.2.3に従って品質保証の活動を行う。

6.1.2.3.5

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

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

6.1.2.3.5.1

供給者は，契約に指定されているように，ソフトウェア製品又はソフトウェアサービスを納

入する。

注記合意によって必要な場合，供給者は，確立された要求事項に従って製品を導入することが望ま

しい。

6.1.2.3.5.2

供給者は，契約に指定されているように，納入されたソフトウェア製品又はソフトウェアサ

ービスの支援において，取得者に援助を提供する。

6.1.2.3.6

供給プロセスの終了

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

6.1.2.3.6.1

供給者は，支払い又は他の合意に基づいた対価を受け取り，受取の通知をする。

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

6.1.2.3.6.2

供給者は，ソフトウェア製品又はソフトウェアサービスの責任を，合意で指示されたように，

取得者又は他の当事者へ移す。

注記合意は，プロジェクトの供給プロセスの終了を始める条件及び承認を取り決めることが望まし

い。

6.2

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

6.2.1

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

6.2.1.1

目的

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

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

とする。

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

− 組織目標と整合がとれている。

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

れている。

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

6.2.1.2

成果

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

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

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

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

d) プロセスの改善が順位付けられて行われている。

6.2.1.3

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

組織は，ライフサイクルモデル管理プロセスに関して，該当する組織の方針及び手順に従って，次のア

クティビティを実施する。

6.2.1.3.1

プロセスの確立

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

6.2.1.3.1.1

組織は，その事業活動に適用するに当たって，全てのソフトウェアライフサイクルプロセス

及びライフサイクルモデルに対して組織の一連のプロセスを確立する。プロセス及びそれらの特定の場合

の適用を組織の文書として残す。プロセスを開発し，監視し，制御し及び改善するために，必要に応じて，

プロセスを制御する仕組みを，確立することが望ましい。

注記プロセス制御の仕組の確立は，ライフサイクル管理のための責任，説明責任及び権限の定義を

含む。

6.2.1.3.2

プロセスのアセスメント

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

6.2.1.3.2.1

組織は，プロセスアセスメントの手順を作成し，文書化し，適用することが望ましい。アセ

スメントの記録を作り，保守することが望ましい。

6.2.1.3.2.2

組織は，アセスメントの結果に照らして，適切性及び有効性の継続を確実にするために，適

切な間隔で行うプロセスのレビューを計画し，実行する。

6.2.1.3.3

プロセスの改善

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

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

6.2.1.3.3.1

組織は，プロセスアセスメント及びレビューの結果からプロセス改善の必要性を決めて，そ

のプロセスを改善する。プロセスの文書は，組織のプロセスにおける改善を反映して更新することが望ま

しい。

6.2.1.3.3.2

使用プロセスの強み及び弱みの理解を得るために，履歴，技術及び評価のデータを，収集し，

分析することが望ましい。これらの分析は，プロセスを改善し，プロジェクト（又は後続のプロジェクト）

の方向転換を勧告したり，高度技術化のニーズを決めるためのフィードバックとして使うことが望ましい。

6.2.1.3.3.3

品質コストデータは，管理活動として組織のプロセスを改善するために，収集し，保守し，

使用することが望ましい。これらのデータは，ソフトウェア製品又はソフトウェアサービスにおける問題

及び不適合の防止及び解決の両者のコストを明確にする目的に役立つ。

6.2.2

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

6.2.2.1

目的

インフラストラクチャ管理プロセスは，ライフサイクルにわたって組織及びプロジェクトの目標を支援

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

とする。

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

産を定義し，提供し，保守する。

6.2.2.2

成果

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

a) プロセスを支援するインフラストラクチャの要求事項が定義されている。

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

c) インフラストラクチャ要素が取得されている。

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

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

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

方法，ツール，手法，作業標準及び施設を含んでもよい。

6.2.2.3

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

組織は，インフラストラクチャ管理プロセスに関して，該当する組織の方針及び手順に従い，次のアク

ティビティを行う。

6.2.2.3.1

プロセスの実施

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

6.2.2.3.1.1

インフラストラクチャは，適用可能な手順，作業標準，ツール及び手法を考慮して，このプ

ロセスを用いるプロセスの要求事項を満たすように定義し，文書化することが望ましい。

6.2.2.3.1.2

インフラストラクチャの確立を計画し，文書化することが望ましい。

6.2.2.3.2

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

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

6.2.2.3.2.1

インフラストラクチャの構成を計画し，文書化することが望ましい。機能性，性能，安全性，

セキュリティ，可用性，必要なスペース，装置，コスト及び時間的制約を考慮することが望ましい。

6.2.2.3.2.2

インフラストラクチャは，関連プロセスの実行に間に合うように導入する。

6.2.2.3.3

インフラストラクチャの保守

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

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

6.2.2.3.3.1

インフラストラクチャは，このプロセスを用いるプロセスの要求事項を満たし続けることを

確実にするために，必要に応じて，保守し，監視し，修正（modify）する。インフラストラクチャの保守

の一部として，インフラストラクチャが構成管理の下にある範囲を，定義する。

6.2.3

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

6.2.3.1

目的

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

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

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

限を認可する。このプロセスは，継続投資に値すること，又は値するように軌道修正できることを確認す

るために，プロジェクトの適格性確認を継続する。

6.2.3.2

成果

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

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

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

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

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

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

6.2.3.3

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

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

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

6.2.3.3.1

プロジェクトの開始

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

6.2.3.3.1.1

組織は，組織の事業戦略及び行動計画に整合性のとれたやり方で，新規事業機会，ベンチャ

事業又は請負事業を識別し，優先付けし，選択し，確立する。

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

値を確立する。

6.2.3.3.1.2

組織は，各プロジェクトに対して説明責任及び権限を定義する。

6.2.3.3.1.3

組織は，プロジェクトの期待される成果を識別する。

6.2.3.3.1.4

組織は，プロジェクト目標達成に向けた資源を割り当てる。

6.2.3.3.1.5

組織は，プロジェクトによって管理又は支援されなければならない複数プロジェクト間のイ

ンタフェースを識別する。

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

プロジェクトによる共通のシステム要素の使用を含む。

6.2.3.3.1.6

組織は，プロジェクトの実行を統治するプロジェクト報告の要求事項及びレビューのマイル

ストーンを指定する。

6.2.3.3.1.7

組織は，技術的な計画を含む，承認済みプロジェクト計画の実行を開始する権限をプロジェ

クトに与える。

6.2.3.3.2

ポートフォリオの評価

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

6.2.3.3.2.1

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

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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

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

c) プロジェクトは，システムライフサイクル計画及び手順に従って実行されている。

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

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

6.2.3.3.2.2

組織は，満足に進展しているか又は適切な軌道修正によって満足に進展すると期待できるプ

ロジェクトを，継続するか又は軌道修正を行う。

6.2.3.3.3

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

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

6.2.3.3.3.1

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

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

6.2.3.3.3.2

製品及びサービスの合意が完了した後，組織は，組織の方針及び手順並びに合意に基づいて

プロジェクトを終了する。

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

を確実にする。

注記2 プロジェクトの終了後，組織は，プロジェクトポートフォリオからそのプロジェクトを除く

ことを承認してもよい。

6.2.4

人的資源管理プロセス

6.2.4.1

目的

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

ることを目的とする。

そのプロセスは，組織，プロジェクト及び顧客の目標を達成するために，ライフサイクルプロセスを行

う資格を備え，スキル及び経験のある要員を供給することを保証する。

6.2.4.2

成果

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

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

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

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

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

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

6.2.4.3

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

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

実施する。

6.2.4.3.1

スキルの識別

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

6.2.4.3.1.1

組織及びプロジェクトの要求事項のレビューを行い，管理及び技術スタッフとして必要とさ

れる資源の確保及びスキルの開発を適時に行うようにする。これらのニーズを，教育，採用又は他の要員

開発の仕組みによって満たしてもよい。

6.2.4.3.1.2

組織及びプロジェクト要求事項を満たすために必要な種類及び水準の教育訓練及び知識を決

定する。

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

6.2.4.3.2

スキルの開発

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

6.2.4.3.2.1

実施スケジュール，資源の要求事項及び教育訓練のニーズに対応した教育計画を作成し，文

書化することが望ましい。

6.2.4.3.2.2

教育するときに使うプレゼンテーション資料を含む教育訓練マニュアルを作成するか，又は

取得することが望ましい。

6.2.4.3.2.3

教育計画は，要員の教育訓練のために作成される。教育訓練の記録を維持することが望まし

い。

6.2.4.3.3

スキルの取得及び提供

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

6.2.4.3.3.1

組織及びプロジェクトのニーズを満たす資格がある要員を採用するために組織的な計画を確

立する。既存の要員にキャリア開発の機会を提供する。

6.2.4.3.3.2

要員の業績評価に使える目標基準を定義する。

6.2.4.3.3.3

組織又はプロジェクトの目標に対する貢献に関して要員の業績を評価する。

6.2.4.3.3.4

実施した評価の結果は，確実に要員にフィードバックする。

6.2.4.3.3.5

スキル，終了した教育訓練及び業績評価を含む要員の実績を適切に記録したものを維持する。

6.2.4.3.3.6

プロジェクトチームに対する組織及びプロジェクトのニーズを定義する。チームの構造及び

運用規則を定義する。

注記複数プロジェクトによる資源要求における競合を解決することが望ましい。

6.2.4.3.3.7

次のことをチームが確実にもつことによって，チームにその役割を果たす力を与える。

a) プロジェクトにおける役割の理解

b) プロジェクトの成功に関する共通の関心のビジョン又はセンスを共有

c) チーム間のコミュニケーションのための適切な仕組み又は設備

d) プロジェクトの要求事項を達成するための適切な管理者層からの支援

6.2.4.3.3.8

計画されたアクティビティ及びタスクに対して，業務分野に関して適切に教育され，正しく

組み合わされた要員が，適時に編成可能な状態にしておくことを確実にすることが望ましい。

6.2.4.3.4

知識管理

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

6.2.4.3.4.1

組織は，組織の知識資産を管理するための要求事項を計画する。計画は，組織の知識資産の

提供者及び利用者を支えるインフラストラクチャ及び教育訓練の定義，その資産に対する分類方法及びそ

の資産の基準を含む。

6.2.4.3.4.2

組織は，組織内に専門家のネットワークを確立する。ネットワークは，組織の専門家の識別，

専門分野の一覧及び分類スキーマ（例えば，知識分野）内の入手可能情報の識別を含む。組織は，そのネ

ットワークが最新の状態を反映していることを確実にする。

6.2.4.3.4.3

組織は，専門家間の情報交換及び組織のプロジェクトへの専門的情報の流れを支援する仕組

みを確立する。その仕組みは，組織のアクセス，格納及び検索の要求事項を支援する。

6.2.4.3.4.4

組織は，6.3.5で指定された構成管理プロセスに従って資産の構成管理を行う。

6.2.4.3.4.5

組織は，計画ごとに組織によるアクセスの情報を把握し，維持する。

6.2.5

品質管理プロセス

6.2.5.1

目的

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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

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

6.2.5.2

成果

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

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

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

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

d) 顧客満足度が監視されている。

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

6.2.5.3

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

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

タスクを実施する。

6.2.5.3.1

品質管理

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

6.2.5.3.1.1

組織は，品質管理の方針，作業標準及び手順を確立する。

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

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

参照。

注記2 ISO 9001:2000のソフトウェアへの適用の指針は，ISO/IEC 90003:2004に記載している。

6.2.5.3.1.2

組織は，顧客満足に対する事業戦略に基づき，組織の品質管理ゴール及び品質管理目標を確

立する。

6.2.5.3.1.3

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

6.2.5.3.1.4

組織は，顧客満足度を調査し，判定して記録する。

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

6.2.5.3.1.5

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

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

する。

6.2.5.3.1.6

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

6.2.5.3.2

品質管理の是正処置

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

6.2.5.3.2.1

組織は，品質管理目標が達成されないとき是正処置をとる。

6.2.5.3.2.2

組織は，是正処置を実施し，結果を組織全体に伝達する。

6.3

プロジェクトプロセス

6.3.1

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

6.3.1.1

目的

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

する。

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

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

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

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

6.3.1.2

成果

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

a) プロジェクトの作業範囲が定義されている。

b) 利用可能な資源及び制約をもつプロジェクトの目標を達成することの実現可能性が評価されている。

c) 作業を完了するために必要な，タスク及び資源の規模が調べられ，見積もられている。

d) プロジェクト内の要素間インタフェース並びに他のプロジェクト及び組織の構成単位とのインタフェ

ースが識別されている。

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

プロジェクト実行のための計画プロセスが実行に移されている。

6.3.1.3

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

管理者は，プロジェクト計画プロセスに関して，該当する組織の方針及び手順に従って，次のアクティ

ビティを実施する。

6.3.1.3.1

プロジェクトの開始

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

6.3.1.3.1.1

管理者は，開始するプロジェクトの要求事項を確立する。

注記要求事項の確立は，プロジェクトの目標，動機及び境界を確認することを含む。

6.3.1.3.1.2

プロジェクトの要求事項が確立された時点で，管理者は，次の点を調べることによって，プ

ロジェクトの実現可能性を明確にする。

− そのプロジェクトを実行し，管理するために必要な資源（人員，資材，技術及び環境）が，確保でき，

適切でかつ適当であること。

− そのプロジェクトが完成までのタイムスケールで達成可能であること。

6.3.1.3.1.3

必要に応じて，かつ，全ての関係当事者の合意によって，この時点で，完了基準を達成する

ために，プロジェクトの要求事項を修正（modify）してもよい。

6.3.1.3.2

プロジェクト計画

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

6.3.1.3.2.1

管理者は，プロジェクト実行のための計画を作成する。プロジェクトの実行に関連する計画

は，関連するアクティビティ及びタスクの記述，並びに提供されるソフトウェア製品の識別を含む。これ

らの計画は次を含むが，それに限定されない。

a) タスクの適時な完了のためのスケジュール

b) 作業量見積り

c) タスクの実行のために適切な資源

d) タスクの割当て

e) 責任の付与

ここで計画した全タスクすなわちプロセス自体に関連したリスクの定量化

g) プロジェクトの全期間を通して使用される品質保証測定量

h) プロセスの実行に関連したコスト

環境及びインフラストラクチャの提供

ライフサイクルモデルの定義及び保守

そのライフサイクルモデルは，組織がプロジェクト用に定義したライフサイクルモデルの段階で構成さ

れている。

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

注記プロジェクトで使用する組織内モデルは，ライフサイクルモデル管理プロセスによって提供さ

れる。

6.3.1.3.3

プロジェクトの始動

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

6.3.1.3.3.1

管理者は，プロジェクトに対する承認を得る。

6.3.1.3.3.2

管理者は，プロジェクトの実施に必要な資源を依頼する。

6.3.1.3.3.3

管理者は，プロジェクトを統括して，その目標及び基準の集合を満たすためにプロジェクト

計画の実施を開始する。

6.3.2

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

6.3.2.1

目的

プロジェクトアセスメント及び制御プロセスは，プロジェクトの状態を見定め，プロジェクトを計画及

びスケジュールに従って，予測された予算内で，遂行すること及びそれが技術目標を満足することを確実

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

このプロセスには，他のプロジェクト管理プロセス又は技術プロセスから既知の差異又はばらつきを是

正するため，必要に応じて，プロジェクトアクティビティを，軌道修正することを含む。軌道修正には，

必要に応じて，再計画を含んでもよい。

6.3.2.2

成果

プロジェクトアセスメント及び制御プロセスの実施に成功すると次の状態になる。

a) プロジェクトの進捗が，監視され，報告されている。

b) プロジェクト内の要素間のインタフェース，及び他のプロジェクトと組織単位とのインタフェースが，

監視されている。

c) プロジェクト目標が達成されていないときに，計画からの差異を是正し，プロジェクトで識別された

問題の再発を防止する行動が，取られている。

d) プロジェクト目標が，達成され，記録されている。

6.3.2.3

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

管理者は，プロジェクトアセスメント及び制御プロセスに関して，該当する組織の方針及び手順に従っ

て，次のアクティビティを実施する。

6.3.2.3.1

プロジェクトの監視

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

6.3.2.3.1.1

管理者は，プロジェクトの実行全体を監視し，プロジェクトの進捗の内部報告を行うととも

に，契約に従い取得者への外部報告を行う。

注記管理者は，プロジェクト内部の要素間のインタフェースと同様に他の関連プロジェクトと組織

単位とのインタフェースがこのアクティビティの間に監視されることを確実にする。

6.3.2.3.2

プロジェクトの制御

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

6.3.2.3.2.1

管理者は，実行中のプロジェクトで発見された問題を調査し，分析し，解決する。問題解決

は，結果として計画の変更になってもよい。いかなる変更の影響も見定め，制御し，監視するのを確実に

するのは，管理者の責任である。問題及びその解決案を文書化する。

6.3.2.3.2.2

管理者は，合意された時点で，計画に合っていること及び進捗の遅れをどのように解決する

かということのプロジェクトの進捗を報告する。これらの報告は，組織の手順及び契約によって要求され

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

ている内部報告及び外部報告を含む。

6.3.2.3.3

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

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

6.3.2.3.3.1

管理者は，ソフトウェア製品及び計画の要求事項をどの程度満たしているかが評価されるこ

とを確実にする。

6.3.2.3.3.2

管理者は，目標の達成及び計画の完了に向かって，プロジェクトの実行中に，完了したもの

から，ソフトウェア製品，アクティビティ及びタスクの評価結果のアセスメントを行う。

注記管理者は，プロジェクトで識別された問題について今後の再発防止の手段を講じるために，プ

ロジェクトアセスメントの結果を用いる。

6.3.2.3.4

プロジェクトの終了

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

6.3.2.3.4.1

全てのソフトウェア製品が完成し，全てのアクティビティ及びタスクが完了したとき，管理

者は，契約に指定された基準，又は組織の手順の一部としての基準を考慮に入れて，プロジェクトが完了

したかどうかを決定する。

6.3.2.3.4.2

これらの結果及び記録は，契約に指定されたように適切な環境に保管する。

6.3.3

意思決定管理プロセス

6.3.3.1

目的

意思決定管理プロセスは，代替手段が存在する場合に，プロジェクト行動に最も有益な進路を選定する

ことを目的とする。

このプロセスは，指定された，望ましい又は最適の成果に到達するために，特質又は発生源が何であっ

ても，システムライフサイクルの間に遭遇した意思決定の要求に応えることである。取り得る複数の行動

を分析し，行動方針を選定し，指示する。決定及びその論理的根拠は，将来の意思決定を支援するために，

記録する。

6.3.3.2

成果

意思決定管理プロセスの実施に成功すると次の状態になる。

a) 意思決定の戦略が，定義されている。

b) 行動の代替案が，定義されている。

c) 代替案の中から好ましい行動が，選定されている。

d) その解決，意思決定の論理的根拠及び前提が，把握され，報告されている。

6.3.3.3

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

プロジェクトは，意思決定管理プロセスに関して，該当する組織の方針及び手順に従って，次のアクテ

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

6.3.3.3.1

意思決定の計画

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

6.3.3.3.1.1

プロジェクトは，意思決定の戦略を定義する。

注記これは，意思決定のカテゴリ及び優先順位の付け方を識別し，責任ある当事者を識別すること

を含む。意思決定者は，識別され，決定する責任及び権限を与えられる。次の結果として意思

決定がなされてもよい。

− 有効性のアセスメント

− 技術的トレードオフ

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

− 解決する必要がある問題

− 容認可能なしきい（閾）値を上回るリスクへの対応としての必要な行動

− 次のライフサイクル段階へプロジェクトを進めるための新しい機会又は承認。

意思決定の戦略は，意思決定を行う責任及び権限を識別し，割り当てることを含む。

6.3.3.3.1.2

プロジェクトは，経験及び知識を利用するために，関係ある当事者を意思決定に参加させる。

6.3.3.3.1.3

プロジェクトは，意思決定の状況及びニーズを識別する。

注記問題又は機会及びそれらの結果を解決する行動の取り得る複数の進路を記録し，分類し，速や

かにかつ客観的に報告する。

6.3.3.3.2

意思決定の分析

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

6.3.3.3.2.1

プロジェクトは，それぞれの決定状況に対して意思決定の戦略を選定し，表明する。望まれ

る結果及び測定可能な達成基準を識別する。

6.3.3.3.2.2

プロジェクトは，識別された決定状況の最適化又は改善を達成するために，定義済みの意思

決定戦略を使って，代替行動の影響の大きさの差異を評価する。

6.3.3.3.3

意思決定の追跡

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

6.3.3.3.3.1

プロジェクトは，問題が効果的に解決されており，望ましくない傾向が改善されており，機

会を生かしていることを確認するために，意思決定の結果を記録し，追跡し，評価し，報告する。

6.3.3.3.3.2

プロジェクトは，合意又は組織の手順に定められているように，かつ，監査及び経験学習を

可能にするやり方で，問題及び機会並びにそれらの決着についての記録を保存する。

6.3.4

リスク管理プロセス

6.3.4.1

目的

リスク管理プロセスは，リスクを継続的に識別し，分析し，取り扱い，監視することを目的とする。

リスク管理プロセスは，システムのライフサイクル，又はソフトウェア製品若しくはソフトウェアサー

ビスのライフサイクルを通してリスクに系統的に対応する継続的プロセスである。それは，システムの取

得，開発，保守又は運用に関連したリスクに適用できる。

6.3.4.2

成果

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

a) リスク管理の範囲が，決定されている。

b) 適切なリスク管理戦略が，定義され，実施されている。

c) リスクは，発生の都度及びプロジェクトの遂行の間に識別されている。

d) リスクは，分析され，これらのリスクの取扱いに資源を適用する優先度が決められている。

e) リスク測定量が，リスクの状態の変化及びリスクに対して取った処置の進捗を判断するために，定義

され，適用され，アセスメントされている。

優先度，確率及び重大さ，又は他の定義されたリスクしきい（閾）値に基づいて，リスクの影響を是

正又は回避するために，適切な処置がなされている。

6.3.4.3

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

プロジェクトは，リスク管理プロセスに関して，該当する組織の方針及び手順に従って，次のアクティ

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

注記 JIS X 0162:2008は，次に示されたアクティビティ及びタスクに対応するアクティビティ及びタ

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

スクのより詳細な集合を規定している。

6.3.4.3.1

リスク管理の計画

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

6.3.4.3.1.1

リスク管理を行うためのガイドラインを示したリスク管理方針を定義する。

6.3.4.3.1.2

実施するリスク管理プロセスの記述を文書化する。

6.3.4.3.1.3

リスク管理プロセスを行う責任を負う当事者及びその役割と責任とを識別する。

6.3.4.3.1.4

その責任を負う当事者には，リスク管理プロセスを行うのに適切な資源を与える。

6.3.4.3.1.5

リスク管理プロセスを評価し，改善するためのプロセスの記述を，提供する。

注記この記述には，経験から学んだ教訓も含まれる。

6.3.4.3.2

リスクプロファイル管理

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

6.3.4.3.2.1

リスク管理プロセスの背景を定義し，文書化する。

注記これには，利害関係者の視点，リスクの種類，並びに技術的及び管理上の目標，仮定及び制約

の記述（恐らく参照することによって）を含む。

6.3.4.3.2.2

あるレベルのリスクを容認できる条件を定義したリスクしきい（閾）値を文書化する。

6.3.4.3.2.3

リスクプロファイルを確立し，保持する。

注記1 リスクプロファイルには，次を記録する。

− リスク管理の背景

− 発生確率，重大さ及びリスクしきい（閾）値を含む各リスクの状態の記録

− 利害関係者から提供されたリスク基準に基づく各リスクの優先度

− それらの処置状態に応じたリスク対応行動の要請

リスクプロファイルは，個々のリスクの状態に変化があるときに更新される。リスクプロ

ファイルの中の優先度は，処置のための資源の適用を決めるのに使用する。

注記2 “リスク処置”の原語は，“risk treatment”で，一つ以上の高度のリスクにさら（曝）されて

いるときに取られるステップ又は実施される手順をいう。“リスク対策処置”とすれば分かり

やすい。

6.3.4.3.2.4

関係するリスクのプロファイルを，それらのニーズに基づいて定期的に利害関係者に伝達す

る。

6.3.4.3.3

リスク分析

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

6.3.4.3.3.1

リスクは，リスク管理の関連にて記述された種類別に識別する。

6.3.4.3.3.2

識別した各リスクの発生確率及び影響を見積もる。

6.3.4.3.3.3

各リスクをリスクしきい（閾）値に対して評価する。

6.3.4.3.3.4

リスクしきい（閾）値を超える各リスクに対し，推奨する処置の戦略を定義し，文書化する。

処置の代替案の有効性を示す測定量を，定義し，文書化する。

注記リスク処置の戦略は，リスクの除去，発生の確率若しくは影響度の減少，又はリスクの容認を

含むが，これらに限定されない。

6.3.4.3.4

リスク処置

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

6.3.4.3.4.1

利害関係者は，リスク行動の要請の中にリスク処置のための推奨される代替手段の提示を受

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

ける。

6.3.4.3.4.2

利害関係者がリスクを容認可能にするために行動することが望ましいと決定した場合，リス

ク処置の代替手段を実施する。

6.3.4.3.4.3

利害関係者がしきい（閾）値を超えるリスクを容認する場合，そのリスクは，優先度が高い

とみなされ，継続的に監視されて，その後のリスク処置行動が必要かどうかを判断する。

6.3.4.3.4.4

リスク処置が決まると，この規格の6.3.2又はISO/IEC 15288:2008に規定されたアセスメント

及び制御のアクティビティに従って，問題に対して実施されるのと同様の管理行動が実施される。

6.3.4.3.5

リスク監視

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

6.3.4.3.5.1

全てのリスク及びその管理状況について，変化がないか否か継続的に監視する。その状態が

変化したリスクは，リスク評価を受ける。

6.3.4.3.5.2

リスク処置の有効性を評価するための手段を，実施し，監視する。

6.3.4.3.5.3

プロジェクトは，そのライフサイクルを通して，新しいリスクと発生源とを継続的に監視す

る。

6.3.4.3.6

リスク管理プロセス評価

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

6.3.4.3.6.1

リスク管理プロセスを改善し，得られた教訓を把握する目的で，プロジェクトのライフサイ

クルを通して情報を収集する。

注記リスク情報は，識別されたリスク，発生源，原因，処置，選ばれた処置の成果を含む。

6.3.4.3.6.2

リスク管理プロセスを，その有効性及び効率について，定期的にレビューする。

6.3.4.3.6.3

識別されたリスク，それらに対する処置及び処置の成果に関する情報を，プロジェクト及び

組織の制度的リスクを識別する目的で，定期的にレビューする。

6.3.5

構成管理プロセス

6.3.5.1

目的

構成管理プロセスは，プロジェクト又はプロセスの全ての識別された出力の完整性（integrity）を確立し，

維持し，かつ，関係する当事者が利用できるようにすることを目的とする。

注記 “integrity”を“完整性［完全にととのっていること。（広辞苑）］”とした。

6.3.5.2

成果

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

a) 構成管理戦略が，定義されている。

b) 構成管理を必要とする品目が，定義されている。

c) 構成のベースラインが，確立されている。

d) 構成管理下の品目の変更が，制御されている。

e) リリースされた品目の構成が，制御されている。

構成管理下の品目の状態が，ライフサイクルを通して利用可能になっている。

注記ソフトウェア構成管理プロセスは，構成管理プロセスの特化したもので，ソフトウェア支援プ

ロセスグループに含まれる。

6.3.5.3

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

プロジェクトは，構成管理プロセスに関して，該当する組織の方針及び手順に従って，次のアクティビ

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

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

6.3.5.3.1

構成管理計画

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

6.3.5.3.1.1

プロジェクトは，構成管理戦略を定義する。

注記これには，次のことを含む。

− 構成品目の保管，アクセス，リリース及び変更制御に対する権限の定義

− 完整性（integrity），セキュリティ及び安全性についての指定の水準に従って，保管場所及

び保管条件，それらの環境，並びに，情報の場合には，保管媒体についての定義

− 構成制御を開始し，変わりゆく構成のベースラインを維持するための基準又は事象の定義

− 構成定義情報の継続的な完整性（integrity）及びセキュリティを確実にするための監査戦略

及び責任の定義

構成管理のアクティビティは，ISO 10007に規定された指針と互換性があることが望ましい。

6.3.5.3.1.2

プロジェクトは，構成制御の対象となる品目を識別する。

注記品目は，必要に応じて，一意で，永続性のある識別子又は印（しるし）によって区別される。

識別子は，構成制御下の品目がそれらの仕様書又は同等の文書化された記述に，曖昧さを残さ

ずに追跡できるように，関連する作業標準及び製品分野の規則に従って決められている。

6.3.5.3.2

構成管理の実行

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

6.3.5.3.2.1

プロジェクトは，適切な水準の完整性（integrity）及びセキュリティを保って，構成に関する

情報を維持する。

注記これは，構成制御下の品目の特質を考慮することを含む。構成の記述は，可能な場合には，製

品又は技術の作業標準に適合する。構成情報によって，他のベースラインの構成状態への前方

及び後方の追跡が可能になることを確実にする。指定された時点又は定義された状況の下で，

構成品目の進化する構成状態を統合して，文書化されたベースラインを作成する。ベースライ

ンのための論理的根拠及び関連する承認を構成ベースラインのデータに記録する。構成記録を，

システムライフサイクルを通じて維持し，かつ，合意し，関連する法令又は業界のベストプラ

クティスに従って，保管する。

6.3.5.3.2.2

プロジェクトは，構成ベースラインの変更が適切に識別され，記録され，評価され，承認さ

れ，組み入れられ，かつ，検証されることを確実にする。

注記指定された時点又は定義された状況の下で，構成品目の進化する構成状態を集約して，文書化

されたベースラインを形成する。構成のステップ，ベースラインのための論理的根拠及び関連

する承認を構成ベースラインのデータに記録する。構成記録を，システムライフサイクルを通

して維持し，かつ，合意し，関連する法令又は業界のベストプラクティスに従って，保管する。

現在の構成状況及び以前の全ての構成状況の記録，検索，集約を管理して，情報の正確さ，適

時性，完整性（integrity）及びセキュリティを確認する。ベースラインが図面，インタフェース

制御文書及び他の合意要求事項に対して適合することを検証するために監査を行う。

6.3.6

情報管理プロセス

6.3.6.1

目的

情報管理プロセスは，システムライフサイクルの期間中，及び該当する場合は，システムライフサイク

ルの後に，指定された当事者に，関連する，適時の，完全な，妥当な，及び，必要な場合に，機密の情報

を提供することを目的とする。

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

このプロセスは，情報を生成し，収集し，変換し，保持し，検索し，配信し，廃棄する。このプロセス

は，指定された情報を管理する。それは，技術，プロジェクト，組織，合意及び利用者の情報を含む。

6.3.6.2

成果

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

a) 管理すべき情報が，識別されている。

b) 情報の表現の形式が，定義されている。

c) 情報は，要求に応じて，変換され，廃棄されている。

d) 情報の状態が，記録されている。

e) 情報は，最新で，完全で，妥当である。

情報は，指定された当事者が利用できるようになっている。

注記ソフトウェア文書管理プロセスは，情報管理プロセスを特化したもので，ソフトウェア支援プ

ロセスグループに含まれる。

6.3.6.3

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

プロジェクトは，情報管理プロセスに関して，該当する組織の方針及び手順に従って，次のアクティビ

ティ及びタスクを実行する。

注記 ISO/IEC 15289は，情報項目（文書）の要求事項を要約し，それらの開発の指針を提供してい

る。

6.3.6.3.1

情報管理計画

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

6.3.6.3.1.1

プロジェクトは，システムライフサイクルの間に管理され，組織の方針又は法令に従って，

それ以降の定義された期間に保持される情報の項目を定義する。

6.3.6.3.1.2

プロジェクトは，情報の項目の発生，生成，保存，保管及び廃棄に関連しての権限及び責任

を指定する。

6.3.6.3.1.3

プロジェクトは，情報項目の保有，伝達及びアクセスに関連する権利，義務及び確約を定義

する。

注記情報及びデータに関する法令，並びにセキュリティ及びプライバシ，例えば，所有権，合意制

限事項，アクセス権，知的財産及び特許に対し，当然の配慮を払う。制限又は制約が該当すれ

ば，情報は，それに応じて識別される。これらの情報に関する知識をもっている要員には，自

らの義務及び責任を通知する。

6.3.6.3.1.4

プロジェクトは，情報の内容，意味論，書式，表現媒体，保有，伝達及び検索を定義する。

注記情報は，どのような形態（例えば，口頭，テキスト，図表，数字）で発生し，終了してもよい。

さらに，どのような媒体（例えば，電子媒体，印刷物，磁気媒体，光媒体）にも蓄えられ，加

工され，複製され，伝達されてもよい。組織の制約（例えば，インフラストラクチャ，組織間

の情報伝達，分散プロジェクト作業）に対して当然の配慮を払う。関連情報の保管，変換，伝

達及び表示の作業標準及び慣例を，方針，合意及び法令の制約に従って使用する。

6.3.6.3.1.5

プロジェクトは，情報保守の行動を定義する。

注記これは，完整性（integrity），妥当性及び可用性並びに代替媒体への複製又は変換のニーズに対

して，蓄えられた情報の状態をレビューすることを含む。技術の変更があっても，保管された

媒体を読み取れるように，インフラストラクチャを保持するニーズ，又は新しい技術を利用し

て，保管されている媒体から記録し直すニーズのいずれかを考慮する。

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

6.3.6.3.2

情報管理の実行

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

6.3.6.3.2.1

プロジェクトは，識別された情報項目を手に入れる。

注記これは，情報を生成させること又は適切な発生源から情報を収集することを含んでもよい。

6.3.6.3.2.2

プロジェクトは，完整性（integrity），セキュリティ及びプライバシの要求事項に従って，情報

項目及びそれらの保管記録を維持する。

注記情報項目の状態（例えば，版の記載，配布の記録，セキュリティ区分）を記録する。情報は，

判読可能であり，しかも，適切な環境を提供していて，かつ，破損，劣化及び紛失を防止する

設備で，すぐに検索可能な形で，蓄えられ，保持されることが望ましい。

6.3.6.3.2.3

プロジェクトは，合意したスケジュール又は定義した状況によって要求されたときに，指定

された当事者に対して，情報を検索し，配布する。

注記情報を適切な形式で指定された当事者に提供する。

6.3.6.3.2.4

プロジェクトは，要求されたときに正式な文書を提供する。

注記一般的な正式な文書の例としては，証明書，認定書，免許証及びアセスメント評定である。

6.3.6.3.2.5

プロジェクトは，監査，知識保持及びプロジェクト終了の目的に従って，指定された情報を

保管する。

注記指定された保管及び検索期間並びに組織の方針，合意及び法令に従って，情報の媒体，場所及

び保護を選定する。プロジェクト終了後必要な文書を保持する取り決めがあることを確認する。

6.3.6.3.2.6

プロジェクトは，組織の方針並びにセキュリティ及びプライバシの要求事項に従って，不必

要な，妥当でない，又は検証できない情報を廃棄する。

6.3.7

測定プロセス

6.3.7.1

目的

測定プロセスは，組織単位内で開発した作成物及び実施されたプロセスに関するデータを収集し，分析

し，報告すること，プロセスの効果的管理を支援すること，並びに作成物の品質を客観的に示すことを目

的とする。

6.3.7.2

成果

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

a) テクニカルプロセス及び管理プロセスの情報ニーズが識別されている。

b) 情報ニーズから引き出された適切な測定量が，識別されている及び／又は開発されている。

c) 測定アクティビティが識別され，計画されている。

d) 要求されたデータが収集され，蓄えられ，分析されていて，その結果が解釈されている。

e) 情報としての作成物は，意思決定を支援し，コミュニケーションの客観的根拠を提供するために使用

されている。

測定プロセス及び尺度が評価されている。

g) 改善が測定プロセスの責任者へ伝達されている。

6.3.7.3

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

プロジェクトは，測定プロセスに関して，該当する組織の方針及び手順に従って，次のアクティビティ

及びタスクを実行する。

注記1 JIS X 0141は，次のアクティビティ及びタスクに対応する，より詳細なアクティビティ及び

タスクを規定している。

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

注記2 ISO 9001:2000は，プロセス及び作成物の測定及び監視のための品質管理システムの要求事項

を規定している。

6.3.7.3.1

測定計画の策定

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

6.3.7.3.1.1

プロジェクトは，測定に関連している組織の特性を記述する。

6.3.7.3.1.2

プロジェクトは，情報ニーズを識別し，優先順位付けをする。

6.3.7.3.1.3

プロジェクトは，情報ニーズを満たす測定量を選択し，文書化する。

6.3.7.3.1.4

プロジェクトは，データ収集，分析，報告手順を定義する。

6.3.7.3.1.5

プロジェクトは，情報としての作成物及び測定プロセスを評価するための基準を定義する。

6.3.7.3.1.6

プロジェクトは，測定タスクに対する資源をレビューし，承認し，提供する。

6.3.7.3.1.7

プロジェクトは，支援する技術を取得し，展開する。

6.3.7.3.2

測定の実行

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

6.3.7.3.2.1

プロジェクトは，データの生成，収集，分析及び報告の手順を関連するプロセスに統合する。

6.3.7.3.2.2

プロジェクトは，データを収集し，格納し，検証する。

6.3.7.3.2.3

プロジェクトは，データを分析し，情報としての作成物を開発する。

6.3.7.3.2.4

プロジェクトは，結果を文書化し，測定の利用者へ伝える。

6.3.7.3.3

測定の評価

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

6.3.7.3.3.1

プロジェクトは，情報としての作成物及び測定プロセスを評価する。

6.3.7.3.3.2

プロジェクトは，改善の余地を識別し，伝達する。

6.4

テクニカルプロセス

6.4.1

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

注記1 この規格の利害関係者要求事項定義プロセスは，ISO/IEC 15288の利害関係者要求事項定義

プロセスをソフトウェアライフサイクルプロセスに特化したものである。利用者は，この規

格のプロセスではなく，ISO/IEC 15288のプロセスとの適合を主張することを考慮してもよ

い。

注記2 ISO/IEC 15288:2002（JIS X 0170:2004が対応）とISO/IEC 15288:2008（対応JISなし）とは，

規格本文部分はほぼ同じで，附属書C及び附属書Dが追加されている。

6.4.1.1

目的

利害関係者要求事項定義プロセスは，定義された環境において，利用者及び他の利害関係者が必要とす

るサービスを提供できるシステムに対する要求事項を定義することを目的とする。

このプロセスでは，システムのライフサイクルを通じて，システムに関わり合いをもつ利害関係者又は

利害関係者の種類を識別し，そのニーズ及び要望を識別する。このプロセスは，これらを分析し，次のよ

うな利害関係者要求事項定義の共通集合へ変換する。

− システムがその運用環境との間で行う意図された相互作用を表現する。

− 結果として得られた各運用サービスを，システムがニーズを満たすことを確かめるために，妥当性確

認するときに対比となる。

6.4.1.2

成果

利害関係者要求事項定義プロセスの実施に成功すると次の状態になる。

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

a) サービスに要求されている特性及びサービスの利用場面が指定されている。

b) システムソリューション上の制約条件が定義されている。

c) 利害関係者要求事項がどの利害関係者のものか，及びどのニーズに対応しているかが追跡可能である。

d) システム要求事項を定義するための基礎が記述されている。

e) サービスの適合の妥当性を確認するための基礎が定義されている。

サービス又は製品を供給するための交渉及び合意の基礎が提供されている。

6.4.1.3

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

プロジェクトは，利害関係者要求事項定義プロセスに関して，該当する組織の方針及び手順に従って，

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

6.4.1.3.1

利害関係者の識別

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

6.4.1.3.1.1

プロジェクトは，システムのライフサイクルの全期間を通して，システムに正当な利害関係

をもつ個々の利害関係者又は利害関係者の種類を識別する。

注記これは，利用者，運用者，支援者，開発者，製作者，教育訓練者，保守者，廃棄者，取得者及

び供給者の組織，外部に対して対応の責任を負う当事者，規制機関並びに社会の構成員を含む

が，それだけに限定はされない。直接のコミュニケーションが非現実的である場合，例えば，

消費者向けの製品及びサービスでは，代表者又は指名された代理の利害関係者を選定する。

6.4.1.3.2

要求事項の識別

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

6.4.1.3.2.1

プロジェクトは，利害関係者要求事項を引き出す。

注記利害関係者要求事項は，識別された利害関係者のニーズ，欲求，要望，期待及び認識された制

約条件を記述する。利害関係者要求事項は，文章又は形式的表現によるモデルを使用して表現

する。そのモデルは，システムの目的及び振る舞いに焦点を合わせており，運用上の環境及び

条件との関連において記述されている。JIS X 0129-1及びISO/IEC 25030で規定されている製

品の品質モデル及び品質要求事項は，このアクティビティを助けるために有益かもしれない。

利害関係者要求事項は，社会によって課されるニーズ及び要求事項，取得する組織によって課

される制約条件，並びに利用者及び運用要員の能力及び運用特性を含んでいる。要請文書又は

合意，それらの正当性及び理論的根拠，並びに利害関係者の前提及び利害関係者が彼らの要求

事項の達成から得られる価値を含めて，情報源を列挙することは，有益である。重要な利害関

係者のニーズについては，有効性の測定量を定義して，運用上の性能を測定し，アセスメント

を実施できるようにする。次の事柄から重大なリスクが生じる可能性がある場合，人間対シス

テムとの問題を識別して，取り扱うための推奨事項は，ISO PAS 18152に見いだすことができ

る。

− 人々（利用者及び他の利害関係者）に関連する問題（例えば，ニーズ，欲求，制約，限界，

心配事，障壁，要因又は考慮すべき事柄）

− システムのライフサイクルのいずれかの時点でのシステムへの関与又はシステムとのやり

取りをする場合

6.4.1.3.2.2

プロジェクトは，既存の合意，管理上の決定及び技術上の決定の避けられない影響からもた

らされるシステムソリューション上の制約条件を定義する。

注記これらは，次に示すものから，結果としてもたらされる場合がある。

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

− 利害関係者が定義したソリューションの事例又は分野

− システム階層構造の上位レベルでなされた実装上の決定

− 定義されたイネーブリングシステム，資源及び要員の必要な利用

6.4.1.3.2.3

プロジェクトは，予想される運用シナリオ及び支援シナリオ，並びに環境に対応する全ての

要求されるサービスを識別するために，代表的な活動順序を定義する。

注記シナリオは，意図された環境におけるシステムの運用を順々に分析するために，かつ，利害関

係者の誰からも公式には指定されていないかもしれない要求事項（例えば，法規，規制及び社

会的な義務）を識別するために利用する。システムの利用のコンテキストを，識別し，解析す

る。そのコンテキスト解析の中に，システムの目標を達成するために利用者が実施する活動，

システムの最終利用者の関連特性（例えば，期待される教育訓練，疲労の程度など），物理的な

環境（例えば，明るさ，温度など）及び利用される機器（例えば，保護装置又は通信機器）の

いずれをも含める。該当する場合に，システムの利用に影響を及ぼす又はその設計を制約する，

利用者に対する社会及び組織の影響力を分析する。

6.4.1.3.2.4

プロジェクトは，人間の能力及びスキルの限界を考慮して，利用者とシステムとの間の相互

作用を識別する。

注記1 使用性の要求事項を決定し，少なくとも，最も効果的で，効率的で，信頼できる人間の行動

及び人とシステムとの間の相互作用を確立する。可能な場合には，該当する規格（例えば，

JIS Z 8512）及び受け入れた専門的プラクティスを，次の定義のために用いる。

a) 身体能力，知能及び習得された能力

b) 作業場，環境及び設備（利用の関連での他の装置を含む。）

c) 正常条件，異常条件及び緊急条件

d) 運用者及び利用者の採用，教育訓練及び文化

注記2 使用性が重要である場合，使用性の要求事項を計画し，明記し，ライフサイクルプロセスを

通じて実施することが望ましい。望ましい水準の使用性を得るために，次の規格又は技術報

告書を適用してもよい。JIS Z 8521:1999，JIS Z 8530:2000，ISO/TR 18529及び附属書Eは，

使用性に焦点を当てたプロセスの観点を記載している。

6.4.1.3.2.5

プロジェクトは，健康，安全，セキュリティ，環境及び他の利害関係者要求事項並びに重大

な品質に関係する機能を指定し，人間の健康及び安全に対する，システムの使用が及ぼす悪影響の可能性

に対処する。

注記安全性リスクを識別し，その安全を保証しなければならない場合は，安全を提供するための要

求事項及び機能を明記する。これは，運用及び支援の方法，健康及び安全，財産への脅威並び

に環境への影響に関連するリスクを含む。該当する規格（例えば，JIS C 0508）及び一般に認

められた専門的プラクティスを利用する。セキュリティのリスクを識別し，その安全を保証し

なければならない場合は，物理的，手続的，通信，コンピュータ，プログラム，データなどを

含め，システムのセキュリティに関する全ての該当する分野を明記する。保護された人員，資

産及び情報に対するアクセス及び損傷，機密情報の漏えい並びに資産及び情報に対する承認ア

クセスの拒否を含め，システムのセキュリティに影響を与える可能性がある機能を識別する。

必須又は関連する場合に，該当する規格及び一般に認められた専門的プラクティスを参照して，

要求されるセキュリティの機能を明記する。それには軽減及び抑制が含まれる。

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

6.4.1.3.3

要求事項の評価

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

6.4.1.3.3.1

プロジェクトは，導出された要求事項の全集合を分析する。

注記分析には，矛盾している，漏れている，不完全な，曖昧な，一貫性のない，調和がとれていな

い又は検証できない要求事項を識別すること及び優先順位を付けることを含む。

6.4.1.3.4

要求事項の合意

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

6.4.1.3.4.1

プロジェクトは，要求事項に関する問題を解決する。

注記これは，実現できない要求事項又は達成が非現実的な要求事項を含む。

6.4.1.3.4.2

ニーズ及び期待が適切に把握され，表現されていることを確実にするために，分析された要

求事項を該当する利害関係者へフィードバックする。

注記矛盾した，非現実的な，実現不可の利害関係者要求事項を解決するための提案を説明し，合意

を得る。

6.4.1.3.4.3

プロジェクトは，利害関係者要求事項が正確に表現されていることを，利害関係者とともに

確立する。

注記これは，利害関係者要求事項は，発信元に分かりやすいこと，及び要求事項の中の矛盾の解決

が利害関係者の意図を改悪していないこと，又は妥協していないことの確認を含む。

6.4.1.3.5

要求事項の記録

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

6.4.1.3.5.1

プロジェクトは，ライフサイクルを通して及びその後も，要求事項管理に適した形式で，利

害関係者要求事項を記録する。

注記これらの記録は，利害関係者要求事項のベースラインを確立し，システムライフサイクルを通

して，ニーズの変更及びその発生源を保持する。これらは，システム要求事項の追跡可能性の

根拠となり，後続システムに対する要求事項及び要求事項の状態について利害関係者との情報

伝達のための知見の元となる。

6.4.1.3.5.2

プロジェクトは，利害関係者のニーズの源への利害関係者要求事項の追跡可能性を維持する。

注記利害関係者要求事項は，ニーズのいかなる変更も考慮されることを確実にするために，ライフ

サイクル中の重要な意思決定時点において，レビューする。

6.4.2

システム要求事項分析プロセス

注記この規格のシステム要求事項分析プロセスは，ISO/IEC 15288の要求事項分析プロセスを特化

したものである。利用者は，この規格のプロセスではなくISO/IEC 15288のプロセスとの適合

を主張することを考慮してもよい。

6.4.2.1

目的

システム要求事項分析プロセスは，定義された利害関係者要求事項を，システムの設計を導くことにな

る望まれるシステムの技術的要求事項の集合へ変換することを目的とする。

6.4.2.2

成果

システム要求事項分析プロセスの実施に成功すると次の状態になる。

a) 解決することが望ましい問題を記述したシステムの機能要求事項及び非機能要求事項の定義された集

合が確立されている。

b) 選択されたプロジェクトソリューションを最適化するために適切な手法が実行されている。

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

c) システム要求事項が正確性及びテスト可能性について分析されている。

d) 運用環境でのシステム要求事項の影響が理解されている。

e) 必要に応じて，要求事項が優先順序付けられ，承認され，更新されている。

一貫性及び追跡可能性がシステム要求事項と顧客の要求事項のベースラインとの間に確立されてい

る。

g) ベースラインの変更は，コスト，スケジュール及び技術的影響に対して評価されている。

h) システム要求事項は，影響のある全ての当事者へ伝えられ，ベースラインとなっている。

6.4.2.3

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

プロジェクトは，システム要求事項分析プロセスに関して，該当する組織の方針及び手順に従って，次

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

6.4.2.3.1

要求事項の仕様化

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

6.4.2.3.1.1

開発すべきシステムの意図された具体的用途を分析し，システム要求事項を明記する。シス

テム要求事項仕様は，次のことを文書化する。

− システムの機能及び能力

− 事業，組織及び利用者の要求事項

− 安全，セキュリティ，人間工学，インタフェース，運用及び保守の要求事項

− 設計制約及び適格性確認の要求事項

システム要求事項仕様を文書化する。

注記1 選択された解決策を最適化するために，適切な手法を用いることが望ましい。

注記2 システム要求事項が運用環境に及ぼす影響を理解することが望ましい。

注記3 システム要求事項は，優先順序付けられ，承認され，ベースラインが設定され，影響の及ぶ

全ての当事者に伝達されることが望ましい。要求事項のベースラインを更新するときは，コ

スト，スケジュール及び技術的影響を評価することが望ましい。

6.4.2.3.2

要求事項評価

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

6.4.2.3.2.1

システム要求事項は，次の基準を考慮して評価する。評価の結果を文書化する。

a) 取得ニーズの追跡可能性

b) 取得ニーズとの一貫性

c) テスト可能性

d) システム方式設計の実現可能性

e) 運用及び保守の実現可能性

注記取得ニーズは，利害関係者要求事項のベースラインを含む。

6.4.3

システム方式設計プロセス

注記この規格のシステム方式設計プロセスは，ISO/IEC 15288の方式設計プロセスの特化したもの

である。利用者は，この規格ではなくISO/IEC 15288のプロセスとの適合を主張することを考

慮してもよい。

6.4.3.1

目的

システム方式設計プロセスは，システム要求事項のどれをシステム要素のどれに割り当てることが望ま

しいかを識別することを目的とする。

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

6.4.3.2

成果

システム方式設計プロセスの実施に成功すると次の状態になる。

a) システムの要素を識別し，定義された要求事項を満たすシステム方式設計が定義されている。

b) システムの機能及び非機能要求事項が取り扱われている。

c) 要求事項がシステムの要素に割り当てられている。

d) 各システム要素の内部及び外部のインタフェースが定義されている。

e) システム要求事項とシステム方式との間の検証が行われている。

システムの要素及びそれらのインタフェースに割り当てられた要求事項は，顧客の要求事項ベースラ

インへ追跡可能である。

g) システム要求事項とシステム方式設計との一貫性及び追跡可能性が維持されている。

h) システム要求事項，システム方式設計及びそれらの関係にベースラインが設けられていて，全ての影

響される当事者に伝えられている。

人的要因並びに人間工学知識及び人間工学手法がシステム設計に組み込まれている。

人間中心設計の活動が識別され，実施されている。

6.4.3.3

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

プロジェクトは，システム方式設計プロセスに関して，該当する組織の方針及び手順に従って，次に示

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

6.4.3.3.1

システム方式の確立

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

6.4.3.3.1.1

システムの最上位の方式を確立する。方式は，ハードウェア，ソフトウェア及び手作業の品

目を識別する。全てのシステム要求事項が品目に割り当てられていることを確実にする。それに続いて，

ハードウェア構成品目，ソフトウェア構成品目及び手作業を，これらの品目から識別する。システム方式

及び品目に割り当てたシステム要求事項を文書化する。

注記1 各システム要素の内部及び外部のインタフェースがシステム方式の中で定義されることが望

ましい。

注記2 人間中心の設計活動が識別され，実行されていることが望ましい。さらに，人的要因並びに

人間工学知識及び人間工学手法がシステム設計に組み込まれていることが望ましい。

注記3 システム方式設計及びシステム方式設計とシステム要求事項との関係は，ベースラインとな

っており，全ての影響する当事者に伝えられることが望ましい。

6.4.3.3.2

システム方式の評価

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

6.4.3.3.2.1

システム方式及び品目に対する要求事項は，次の基準に基づいて評価する。評価の結果を文

書化する。

a) システム要求事項への追跡可能性

b) システム要求事項との一貫性

c) 使用する設計標準及び方法の適切さ

d) 割り当てられた要求事項を満たすソフトウェア品目の実現可能性

e) 運用及び保守の実現可能性

注記システム要求事項へのシステム方式の追跡可能性は，利害関係者要求事項のベースラインへの

追跡可能性をも導くことが望ましい。

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

6.4.4

実装プロセス

6.4.4.1

目的

実装プロセスは，指定されたシステム要素を実現することを目的とする。

注記この規格の利用者は，ソフトウェア製品又はより大きいシステムのソフトウェア要素を扱うこ

とを意図する。ソフトウェア実装プロセス（7.1.1）は，ISO/IEC 15288の実装プロセスの適合

例で，ソフトウェア製品又はソフトウェアサービスを実装するという特定のニーズに特化した

ものである。ソフトウェア実装プロセスは，この規格の実装プロセスに置き換わる。

6.4.5

システム結合プロセス

注記この規格のシステム結合プロセスは，ISO/IEC 15288の結合プロセスの特化したものである。

利用者は，この規格のプロセスではなくてISO/IEC 15288のプロセスとの適合を主張すること

を考慮してもよい。

6.4.5.1

目的

システム結合プロセスは，システム設計及びシステム要求事項に表現された顧客の期待を満たす完全な

システムを作り出すためにシステム要素（ソフトウェア構成品目，ハードウェア構成品目，手作業及び必

要に応じて他のシステム）を結合することを目的とする。

6.4.5.2

成果

システム結合プロセスの実施に成功すると次のような状態になる。

a) システム要求事項の優先度に従ってシステムを結合するための戦略が，作成されている。

b) システム要素間のインタフェースを含め，システム要素に割り当てられたシステム要求事項との適合

性を検証する基準が，作成されている。

c) システム結合が，定義された基準を使用して検証されている。

d) 変更が行われたときにシステムを再テストするために回帰戦略が作成され，適用されている。

e) システム設計と結合されたシステム要素との間の一貫性及び追跡可能性が，確立されている。

システム設計との適合を示す結合したシステムが，構築されている。

g) 使用できる納入可能なシステム要素の完全な集合が存在することを示す結合したシステムが，構築さ

れている。

6.4.5.3

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

プロジェクトは，システム結合プロセスに関して，該当する組織の方針及び手順に従って，次に示すア

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

6.4.5.3.1

結合

このアクティビティは，次のタスクから構成される。

6.4.5.3.1.1

ソフトウェア構成品目は，ハードウェア構成品目，手作業，及び必要に応じて，他のシステ

ムとともに，システムに結合する。その集合体は，開発の進捗に従って，要求事項に対してテストされる。

結合結果及びテスト結果を文書化する。

注記1 システム結合アクティビティは，システム要求事項の優先順位を考慮に入れた所定の結合方

針に従って，実行することが望ましい。

注記2 結合方針は，システム設計と結合したシステム構成要素との間の一貫性及び追跡可能性に対

応することが望ましい。

6.4.5.3.2

テスト準備

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

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

6.4.5.3.2.1

システムの適格性確認の各要求事項に対して，システム適格性確認テストを行うために，一

連のテスト，テストケース（入力，出力，テスト基準など）及びテスト手順を作成し，文書化する。開発

者は，結合したシステムに対してシステム適格性確認テストの準備が終わっていることを確実にする。

注記変更したときにシステムを再テストするために適用する回帰テスト戦略を作成することが望ま

しい。

6.4.5.3.2.2

結合したシステムは，次の基準を考慮して評価する。評価の結果を文書化する。

a) システム要求事項のテスト網羅性

b) 使用されたテスト方法及び作業標準の適切性

c) 期待した結果への適合性

d) システム適格性確認テストの実現可能性

e) 運用及び保守の実現可能性

6.4.6

システム適格性確認テストプロセス

注記この規格のシステム適格性確認テストプロセスは，ISO/IEC 15288の検証プロセスの成果を導

き出す一助になる。利用者は，この規格のプロセスではなくISO/IEC 15288のプロセスとの適

合を主張することを考慮してもよい。

6.4.6.1

目的

システム適格性確認テストプロセスは，各システム要求事項について，実装の適合性がテストされ，シ

ステムの納入準備ができていることを確実にすることを目的とする。

6.4.6.2

成果

システム適格性確認テストプロセスの実施に成功すると次のような状態になる。

a) システム要求事項への適合を評価するための基準が作成されている。

b) 定義された基準を使用して結合されたシステムがテストされている。

c) テスト結果が記録されている。

d) システムの納入準備が保証されている。

6.4.6.3

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

プロジェクトは，システム適格性確認テストプロセスに関して，該当する組織の方針及び手順に従って，

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

6.4.6.3.1

適格性確認テスト

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

6.4.6.3.1.1

システムに対して指定された適格性確認要求事項に従って，システム適格性確認テストを行

う。各システム要求事項について実装の適合性をテストし，システムの納入準備ができていることを確実

にする。適格性確認テストの結果を文書化する。

注記システムに対する適格性確認要求事項は，システム要求事項への適合を評価する基準を含む。

6.4.6.3.1.2

システムは，次の基準を考慮して評価する。評価の結果を文書化する。

a) システム要求事項のテスト網羅性

b) 期待した結果への適合性

c) 運用及び保守の実現可能性

注記評価基準は，システムの納入準備ができているかを対象とすることが望ましい。

6.4.6.3.1.3

開発者は，7.2.7に従って監査を支援する。監査の結果を文書化する。

注記これは，以前に監査が行われたソフトウェア構成品目には適用しない。

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

6.4.6.3.1.4

監査を実施し，望ましい結果であった場合には，開発者は，ソフトウェア導入及びソフトウ

ェア受入れ支援プロセスのために，納入可能なソフトウェア製品を更新し，用意する。

注記システム適格性確認テストプロセスは，ソフトウェア検証プロセス（7.2.4）又はソフトウェア

妥当性確認プロセス（7.2.5）で使用してもよい。

6.4.7

ソフトウェア導入プロセス

注記この規格のソフトウェア導入プロセスは，ISO/IEC 15288の移行プロセスの成果を導き出す一

助になる。規格の利用者は，この規格のプロセスではなくISO/IEC 15288のプロセスとの適合

を主張することを考慮してもよい。

6.4.7.1

目的

ソフトウェア導入プロセスは，合意した要求事項を満たすソフトウェア製品を実環境に導入することを

目的とする。

6.4.7.2

成果

ソフトウェア導入プロセスの実施に成功すると次のような状態になる。

a) ソフトウェア導入戦略が作成されている。

b) ソフトウェア導入要求事項との適合を示すソフトウェア導入の基準が作成されている。

c) ソフトウェア製品が実環境に導入されている。

d) 意図した環境でソフトウェア製品を使用する準備が保証されている。

6.4.7.3

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

プロジェクトは，ソフトウェア導入プロセスに関して，該当する組織の方針及び手順に従って，次に示

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

6.4.7.3.1

ソフトウェア導入

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

6.4.7.3.1.1

実装者は，契約に指定されたように，実環境にソフトウェア製品を導入する計画を作成する。

ソフトウェア製品の導入に必要な資源及び情報を決定し，利用可能にする。契約に指定された場合，実装

者は，セットアップ作業について取得者を支援する。導入されるソフトウェア製品で既存のシステムを置

き換えるときは，実装者は，契約で要求されている並行運用の作業を支援する。導入計画を文書化する。

注記1 ソフトウェア導入戦略は，顧客及び運用組織との合意を得た上で作成されることが望ましい。

注記2 ソフトウェア導入戦略の作成に当たって重要なことは，直前の稼働システムの版に戻す戦略

を作成することである。直前の稼働システムの版に戻すことができるように，導入を始める

前に，システムの完全なバックアップをとることが望ましい。

注記3 導入者は，導入要求事項に基づいて，ソフトウェアが導入される環境に対する基準を作成す

ることが望ましい。

注記4 導入者は，意図された環境に対してシステムを適応させるための要求事項を指定することが

望ましい。

注記5 導入者は，運用の要求事項を満たすようにシステムを適応させることが望ましい。

6.4.7.3.1.2

開発者は，導入計画に従ってソフトウェア製品を導入する。ソフトウェアコード及びデータ

ベースを契約で指定されたとおりに，初期化し，実行し，終了することを確実にする。導入中に起きたこ

と及び結果を文書化する。

注記導入者は，ソフトウェア製品が意図された環境で使える状態であることを保証することが望ま

しい。

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

6.4.8

ソフトウェア受入れ支援プロセス

注記この規格のソフトウェア受入れ支援プロセスは，ISO/IEC 15288の移行プロセスの成果を導き

出す一助になる。この規格のソフトウェア受入れ支援プロセスは，ISO/IEC 15288の検証プロ

セスの成果を導き出す一助になるかもしれない。この規格の利用者は，この規格のプロセスで

はなくISO/IEC 15288のプロセスとの適合を主張することを考慮してもよい。

6.4.8.1

目的

ソフトウェア受入れ支援プロセスは，製品が要求事項を満たしているという確信を取得者がもつことを

助けることを目的とする。

6.4.8.2

成果

ソフトウェア受入れ支援プロセスの実施に成功すると次のような状態になる。

a) 製品は，完成し，取得者に納入されている。

b) 取得者の受入れテスト及びレビューが支援されている。

c) 顧客の環境で製品の運用が開始されている。

d) 受入れで検出された問題が識別され，解決の責任を負う人たちに伝達されている。

注記段階的に追加分を納入する場合は，追加分が出来上がるごとに納入が行われることになる。

6.4.8.3

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

プロジェクトは，ソフトウェア受入れ支援プロセスに関して，該当する組織の方針及び手順に従って，

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

6.4.8.3.1

ソフトウェア受入れ支援

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

6.4.8.3.1.1

開発者は，取得者のソフトウェア製品受入れレビュー及びテストを支援する。受入れレビュ

ー及びテストは，ソフトウェアレビュープロセス（7.2.6），ソフトウェア監査プロセス（7.2.7），ソフトウ

ェア適格性確認テストプロセス及び（実行する場合には）システム適格性確認テストプロセスの結果を考

慮する。受入れレビュー及びテストの結果を文書化する。

注記これには，受入れテストの間に検出された問題を文書化すること及び解決を責任者へ伝達する

ことを含む。

6.4.8.3.1.2

開発者は，契約に沿って，ソフトウェア製品を完成し，納入する。

注記開発者が顧客の環境で製品を動作させることを契約で要求してもよい。

6.4.8.3.1.3

開発者は，契約に沿って，初期に及び継続的に，教育訓練及び支援を取得者に提供する。

注記初期の支援には，受入れの間に検出された問題を識別し，解決の責任者に伝達することを含む。

6.4.9

ソフトウェア運用プロセス

この規格のソフトウェア運用プロセスは，ISO/IEC 15288の運用プロセスの特化である。利用者は，こ

の規格のプロセスではなくISO/IEC 15288のプロセスとの適合を主張することを考慮してもよい。

6.4.9.1

目的

ソフトウェア運用プロセスは，意図された環境でソフトウェア製品を運用し，ソフトウェア製品の顧客

への支援を提供することを目的とする。

6.4.9.2

成果

ソフトウェア運用プロセスを成功裏に実施すると次の状態になる。

a) 運用の戦略が定義されている。

b) 意図された環境でのソフトウェアの正しい運用の条件が識別され，評価されている。

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

c) ソフトウェアは，意図された環境でテストされ，運用することが決定されている。

d) ソフトウェアは，意図された環境で運用されている。

e) 合意に従って，ソフトウェア製品の顧客に対して，支援及びコンサルティングが提供されている。

6.4.9.3

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

プロジェクトは，ソフトウェア運用プロセスに関して，該当する組織の方針及び手順に従って，次のア

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

6.4.9.3.1

運用の準備

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

6.4.9.3.1.1

運用者は，このプロセスのアクティビティ及びタスクを実施するための計画を作成し，運用

標準を設定する。計画は，文書化し，実行する。

6.4.9.3.1.2

運用者は，問題を受け取り，記録し，解決し，追跡し，フィードバックを提供する手順を確

立する。問題が発生したときはいつでも，それを記録し，ソフトウェア問題解決プロセス（7.2.8）に引き

渡す。

6.4.9.3.1.3

運用者は，次を確立する。

a) ソフトウェア製品をその運用環境においてテストするための手順

b) 問題の報告及び修正（modification）依頼をソフトウェア保守プロセス（6.4.10）に引き渡すための手

順

c) 実運用のためにソフトウェア製品をリリースするための手順

6.4.9.3.2

運用の開始及び終了

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

6.4.9.3.2.1

ソフトウェア製品の各リリースに対して，運用者は，運用テストを行い，指定された基準を

満たした場合に，ソフトウェア製品を実運用のためにリリースする。

6.4.9.3.2.2

運用者は，ソフトウェアコード及びデータベースが，計画に記述されているとおりに，初期

化され，実行され，終了されていることを確実にする。

6.4.9.3.2.3

運用者は，意図された運用の状況の中でシステムを作動させ，意図された目的に従って，個々

のサービス又は継続したサービスを提供する。

注記合意がある場合は，そのシステムが廃止される既存システムと置き換わるとき，継続したサー

ビスの能力及び品質を維持する。運用切替え又は並行運用の指定期間中，利害関係者の持続的

ニーズへの適合を継続することが達成されるように，サービスの移行を管理する。

6.4.9.3.3

実運用

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

6.4.9.3.3.1

利用者用文書に従って，意図する環境でシステムを運用する。

注記1 意図する環境での運用は，合意された要求事項との適合を明示できるように実運用のための

基準を作成し，指定された基準を満たすことのアセスメントを行って，製品の各リリースの

運用テストを実行することを含む。

注記2 製品運用へのリスクが識別され，監視される。

注記3 運用者は，必要に応じて，定義された基準に照らして，運用上のサービスを定期的に監視す

る。

6.4.9.3.4

顧客支援

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

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

6.4.9.3.4.1

運用者は，依頼に基づいて，利用者に支援及びコンサルティングを提供する。これらの依頼

及びそれに伴う行動を記録し，監視する。

注記援助及び相談サービスは，製品の効果的な使用を支援するための教育訓練，文書化，及び他の

支援サービスを含む。

6.4.9.3.4.2

運用者は，必要に応じて，解決するためにソフトウェア保守プロセス（6.4.10）へ利用者の依

頼を引き渡す。これらの依頼を取り扱う。計画され，実施された行動は，依頼元へ報告する。全ての解決

作業は，終結まで監視される。

6.4.9.3.5

運用上の問題解決

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

6.4.9.3.5.1

運用者は，解決のためにソフトウェア問題解決プロセスへ識別された問題を引き渡す。

6.4.9.3.5.2

恒久的な解決がリリースできる前に，報告された問題に一時的な回避策がある場合，問題を

報告した者には，それを使うという選択肢が与えられる。恒久的修正，以前に抜けていた機能又は特徴を

含むリリース，及びシステム改善は，ソフトウェア保守プロセス（6.4.10）を使用して，運用ソフトウェア

製品に適用される。

6.4.10 ソフトウェア保守プロセス

注記1 この規格のソフトウェア保守プロセスは，ISO/IEC 15288の保守プロセスの特化である。利

用者は，この規格のプロセスではなくISO/IEC 15288のプロセスとの適合を主張することを

考慮してもよい。

注記2 この規格のソフトウェア保守プロセスは，JIS X 0161:2008と互換性がある。

6.4.10.1 目的

ソフトウェア保守プロセスは，納入されたソフトウェア製品に対して費用対効果が高い支援を提供する

ことを目的とする。

注記納入前のソフトウェア保守活動には，納入後の運用，支援可能性及び後方支援の決定のための

計画を含む。納入後の活動には，ソフトウェア修正（modification），及び教育訓練又はヘルプ

デスクの運用のような運用支援を含む。

6.4.10.2 成果

ソフトウェア保守プロセスの実施に成功すると次の状態になる。

a) リリース戦略に従って，製品の修正（modification）及び移行を管理するために，保守戦略が作成され

ている。

b) 既存のシステムの変更が組織，運用又はインタフェースに及ぼす影響が識別されている。

c) 影響を受けるシステム及びソフトウェアの文書が，必要に応じて更新されている。

d) 要求事項が損なわれていないことを示す関連テストを使用して，修正（modify）された製品が開発さ

れている。

e) 製品のアップグレード版が顧客の環境に移行されている。

システムソフトウェアの修正（modification）が，影響を受ける全当事者に伝達されている。

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

保守者は，ソフトウェア保守プロセスに関して，該当する組織の方針及び手続に従って，次のアクティ

ビティを実行する。

6.4.10.3.1 プロセスの実施

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

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

6.4.10.3.1.1 保守者は，このソフトウェア保守プロセスのアクティビティ及びタスクを行うための計画及

び手続を作成し，文書化し，実行する。

6.4.10.3.1.2 保守者は，利用者からの問題報告及び修正（modification）依頼を受領し，記録し，追跡し，

利用者へのフィードバックを提供する手続を確立する。問題が発生したときにはいつでも，それらを記録

し，ソフトウェア問題解決プロセス（7.2.8）に引き渡す。

6.4.10.3.1.3 保守者は，既存システムへの修正（modification）を管理するためにソフトウェア構成管理プ

ロセス（7.2.2）を実施（又は構成管理プロセスと組織としてのインタフェースを確立）する。

6.4.10.3.2 問題及び修正（modification）の分析

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

6.4.10.3.2.1 保守者は，次のことに対して，組織，既存システム及びインタフェースしているシステムに

及ぼす影響について，問題報告又は修正（modification）依頼を分析する。

a) 種類：例えば，是正，改善，予防又は新しい環境への適応

b) 範囲：例えば，修正（modification）量，修正費用，修正（modify）時間

c) 重大性：例えば，性能，安全性又はセキュリティへの影響

6.4.10.3.2.2 保守者は，問題を再現するか又は検証する。

6.4.10.3.2.3 保守者は，分析に基づいて，修正（modification）を実施するための選択肢を作成する。

6.4.10.3.2.4 保守者は，問題又は修正（modification）依頼，分析結果及び実施の選択肢を文書化する。

6.4.10.3.2.5 保守者は，契約の指定に従って，選ばれた修正（modification）の選択肢に対する承認を得る。

6.4.10.3.3 修正（modification）の実施

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

6.4.10.3.3.1 保守者は，分析を行い，文書，ソフトウェアユニット及びそれらの版の中のどれに修正（modify）

の必要があるかを決める。これらを文書化する。

6.4.10.3.3.2 保守者は，修正（modification）を実施するためにテクニカルプロセス（6.4）を実行する。テ

クニカルプロセスの要求事項に次を補足する。

a) システムの修正（modify）した部分及び修正（modify）していない部分（ソフトウェアユニット，ソ

フトウェアコンポーネント及びソフトウェア構成品目）をテストして，評価するテスト及び評価基準

を定義し，文書化する。

b) 新しい要求事項及び修正（modify）された要求事項が完全にかつ正しく実装されていることを確実に

する。元の修正（modify）していない要求事項は，影響されていないことを確実にする。テスト結果

を文書化する。

6.4.10.3.4 保守レビュー及び／又は受入れ

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

6.4.10.3.4.1 保守者は，修正（modification）を承認する組織とともにレビューを行い，修正（modify）さ

れたシステムの完整性（integrity）を確かめる。

6.4.10.3.4.2 保守者は，契約に指定されたとおりに修正（modification）が満足に完了していることに対し

て承認を受ける。

6.4.10.3.5 移行

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

6.4.10.3.5.1 システム又はソフトウェア製品（データを含む。）が古い運用環境から新しい運用環境へ移行

する場合は，移行中に作成又は修正（modify）した，ソフトウェア製品又はデータがこの規格に従ってい

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

ることを確実にする。

6.4.10.3.5.2 移行計画を作成し，文書化し，実行する。計画立案に利用者を参加させる。計画には，次の

項目を含む。

a) 移行の要求事項分析及び要求定義

b) 移行ツールの開発

c) ソフトウェア製品及びデータの変換

d) 移行の実施

e) 移行の検証

移行後の旧環境の支援

6.4.10.3.5.3 次の事項を含む移行計画及び活動について，利用者に通知する。

a) 旧環境が今後支援されない理由の記述

b) 新環境の記述及びその利用可能日付

c) 旧環境に対する支援が除かれた時点で，他の利用可能な支援選択肢がある場合は，その記述

6.4.10.3.5.4 新環境への円滑な移行のために新旧環境での並行運用を行ってもよい。この期間に，契約で

指定された必要な教育訓練を提供する。

6.4.10.3.5.5 予定した移行の時期が来たら，全ての関係者に通知する。旧環境に関連した文書，ログ及び

コードは，保管することが望ましい。

6.4.10.3.5.6 新環境への変更の影響をアセスメントするために運用後レビューを行う。レビューの結果を

情報，指導及び行動のために適切な権限保持者に伝える。

6.4.10.3.5.7 旧環境で使用されていた又は関連したデータは，データ保護及びデータに適用される監査の

ために契約要求事項に従ってアクセス可能とする。

6.4.11 ソフトウェア廃棄プロセス

注記この規格のソフトウェア廃棄プロセスは，ISO/IEC 15288の廃棄プロセスの特化である。利用

者は，この規格のプロセスではなくISO/IEC 15288のプロセスとの適合を主張することを考慮

してもよい。

6.4.11.1 目的

ソフトウェア廃棄プロセスは，システムのソフトウェア実体の存在を終了することを目的とする。この

プロセスは，運用及び保守の組織によって実施中の支援を終えるか，又は影響を受けるソフトウェア製品

を最終の状態にし，かつ，その（運用）環境を好ましい状態にして，起動不能にしたり，解体したり，取

り除いたりする。このプロセスは，法令，合意，組織の制約及び利害関係者要求事項に従って，健全なや

り方で，システムのソフトウェア要素及び関連製品を破棄又は保管する。必要な場合は，監視される可能

性がある記録を維持する。

注記組織の運用の完整性（integrity）を保ちながら，システムの既存ソフトウェア製品又はソフトウ

ェアサービスを廃止にすることを目標とする。

6.4.11.2 成果

ソフトウェア廃棄プロセスの実施に成功すると次の状態になる。

a) ソフトウェアの廃棄戦略が，定義されている。

b) 廃棄の制約条件が，要求事項の入力として提供されている。

c) システムのソフトウェア要素が破棄又は保管されている。

d) 環境が，合意された状態である。

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

e) 廃棄作業についての知識保持及び長期的な影響分析を可能にする記録が利用可能になっている。

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

プロジェクトは，ソフトウェア廃棄プロセスに関して，該当する組織の方針及び手続に従って，次のア

クティビティを実施する。

6.4.11.3.1 ソフトウェア廃棄計画

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

6.4.11.3.1.1 ソフトウェア廃棄戦略を定義し，文書化する。運用及び保守の組織による実施中の支援を除

くための計画を作成し，文書化する。計画の活動には利用者を参加させる。ソフトウェア廃棄計画は，次

の項目に対処する。

a) 一定期間後に支援の全部又は部分停止

b) ソフトウェア製品及びそれと関連した文書の保管

c) 以後の残存する支援課題に対する責任

d) 該当する場合に，新しいソフトウェア製品への移行

e) データの保管されたコピーのアクセス可能性

注記1 計画には，次のことを実行するスケジュール，行動及び資源を定義する。

− ソフトウェアサービスの提供の終了。

− 社会的及び物理的に受入れ可能な状態へのシステム形態の変換又はシステムの保持。そ

れによって利害関係者，社会及び環境へのその後の悪影響を回避する。

− 廃棄活動に適用でき，かつ，結果がもたらす物理的資材及び情報の長期的状態に適用で

きる健康，安全，セキュリティ及びプライバシの考慮。

注記2 計画された廃棄活動のための要求事項への入力として廃棄上の制約を規定することが望まし

い。

6.4.11.3.2 ソフトウェア廃棄の実行

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

6.4.11.3.2.1 ソフトウェア廃棄計画を実行する。

6.4.11.3.2.2 ソフトウェア製品及びソフトウェアサービスの廃止のための計画及び活動について，利用者

に通知する。通知には，次を含む。

a) 交換品又は更新（アップグレード）版の記述及び更新版の発効日

b) ソフトウェア製品が今後は支援されない理由の記述

c) 支援停止後の入手可能な他の支援選択肢の記述

6.4.11.3.2.3 廃止するソフトウェア製品及び新ソフトウェア製品の並行運用が，新システムへの円滑な移

行のために行われることが望ましい。この期間に，契約の指定に従って，利用者の教育訓練を提供する。

6.4.11.3.2.4 予定した廃止する時期が来れば，全ての関係者に通知する。適切な場合，全ての関連開発文

書，ログ及びコードは，保管することが望ましい。

6.4.11.3.2.5 廃止したソフトウェア製品で使用されたデータ又はそれに関連するデータは，データ保護及

びデータに適用される監査のための契約要求事項に従って，アクセス可能とする。

ソフトウェア固有プロセス

7.1

ソフトウェア実装プロセス

7.1.1

ソフトウェア実装プロセス

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

注記ソフトウェア実装プロセス（7.1.1）は，ISO/IEC 15288の実装プロセスに適合する例で，ソフ

トウェア製品又はソフトウェアサービスを実現するという特定のニーズに特化したものである。

7.1.1.1

目的

ソフトウェア実装プロセスは，ソフトウェア製品又はソフトウェアサービスとして実現される指定のシ

ステム要素を作り出すことを目的とする。

このプロセスでは，指定された動作，インタフェース及び実装上の制約条件を，ソフトウェア製品又は

ソフトウェアサービスとして実現されたシステム要素，別名では“ソフトウェア品目”とされているシス

テム要素を作り出すことに変換する。このプロセスは，検証を通じて方式設計の要求事項を満足し，妥当

性確認を通じて利害関係者の要求事項を満足するソフトウェア品目を結果としてもたらすものである。

7.1.1.2

成果

ソフトウェア実装プロセスの実施に成功すると次の状態になる。

a) 実装戦略が定義されている。

b) 設計に当たって実装技術の制約条件が識別されている。

c) ソフトウェア品目が実現されている。

d) ソフトウェア品目が，供給についての合意に従って，包装され，保管されている。

ソフトウェア実装プロセスは，そのアクティビティに加えて，次の下位レベルのプロセスをもつ。

− ソフトウェア要求事項分析プロセス*

− ソフトウェア方式設計プロセス*

− ソフトウェア詳細設計プロセス

− ソフトウェア構築プロセス

− ソフトウェア結合プロセス*

− ソフトウェア適格性確認テストプロセス*

注記 ISO/IEC 15288の利用者は，上記の一覧中の星印（*）が付いたプロセスは，システムのソフト

ウェア要素についても，ISO/IEC 15288を再帰的に適用することによって提供することを決め

てもよい。

7.1.1.3

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

プロジェクトは，ソフトウェア実装プロセスに関して，該当する組織の方針及び手順に従って，次のア

クティビティを実行する。

7.1.1.3.1

ソフトウェア実装戦略

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

7.1.1.3.1.1

契約に書かれていない場合には，開発者は，プロジェクトの範囲，規模及び複雑さに応じた

ライフサイクルモデルを定義又は選択する。ライフサイクルモデルは，段階並びに各段階の目的及び成果

によって構成される。ソフトウェア実装プロセスのアクティビティ及びタスクを選択し，そのライフサイ

クルモデルに対応付ける。

注記1 これらのアクティビティ及びタスクは，重複して又は相互に作用し，繰り返して又は再帰的

に実行されてもよい。

注記2 理想的には，これは組織で定義されたライフサイクルモデルを使用して行われる。

7.1.1.3.1.2

開発者は，次のことを行う。

a) ソフトウェア文書化管理プロセス（7.2.1）に従って作り出したものを文書化する。

b) 作り出したものをソフトウェア構成管理プロセス（7.2.2）の管理下に置き，それに従って変更制御を

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

行う。

c) ソフトウェア問題解決プロセス（7.2.8）に従って，ソフトウェア製品及びタスクの中に発見された問

題及び非適合性を文書化し，解決する。

d) 契約で指定されたように，支援プロセスを行う。

e) 取得者及び供給者が取り決めたように，適切な時点で，ベースラインを確立し，構成品目を組み込む。

7.1.1.3.1.3

開発者は，（契約に書かれていない場合には）ソフトウェア実装プロセス及び支援プロセスを

行うために組織によって，文書化され，適切であり，確立されている，作業標準，方法，ツール及び計算

機プログラム言語を選択し，修整（tailor）し，使用する。

注記設計上の実装技術の制約条件は，ソフトウェア実装戦略の一部として識別されることが望まし

い。

7.1.1.3.1.4

開発者は，ソフトウェア実装プロセスのアクティビティを行うための計画を作成する。計画

は，安全性及びセキュリティを含む全ての要求事項の作成及び適格性確認に関係した特定の作業標準，方

法，ツール，行動及び責任を含むことが望ましい。必要な場合に，別の計画を作成してもよい。これらの

計画を文書化し，実行する。

7.1.1.3.1.5

ソフトウェア製品の開発又は保守に非納入品目を使用してもよい。しかし，取得者への納入

後は納入ソフトウェア製品の運用及び保守を非納入品目に依存しないで，独立して行えることを確実にし

なければならない。そうでない場合には，これらの品目は納入品目とみなされることが望ましい。

7.1.2

ソフトウェア要求事項分析プロセス

注記この規格の中のソフトウェア要求事項分析プロセスは，ソフトウェア実装プロセスの下位レベ

ルのプロセスである。ISO/IEC 15288の利用者は，このプロセスをISO/IEC 15288の再帰的適

用において，ISO/IEC 15288の要求事項分析プロセスによって提供することを決めてもよい。

7.1.2.1

目的

ソフトウェア要求事項分析プロセスは，システムのソフトウェア要素の要求事項を確立することを目的

とする。

7.1.2.2

成果

ソフトウェア要求事項分析プロセスの実施に成功すると次の状態になる。

a) システムのソフトウェア要素及びそれらのインタフェースに割り当てられた要求事項が定義されてい

る。

b) ソフトウェア要求事項が正確さ及びテスト可能性について分析されている。

c) ソフトウェア要求事項の運用環境への影響が理解されている。

d) ソフトウェア要求事項とシステム要求事項との間の一貫性及び追跡可能性が確立されている。

e) ソフトウェア要求事項を実装する優先順位付けが定義されている。

ソフトウェア要求事項が承認され，必要に応じて更新されている。

g) ソフトウェア要求事項の変更がコスト，スケジュール及び技術的影響に対して評価されている。

h) ソフトウェア要求事項のベースラインが定められ，全ての影響ある当事者に伝えられている。

7.1.2.3

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

プロジェクトは，ソフトウェア要求事項分析プロセスに関して，該当する組織の方針及び手順に従って，

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

7.1.2.3.1

ソフトウェア要求事項分析

各ソフトウェア品目（識別されている場合，ソフトウェア構成品目）に対して，このアクティビティは，

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

次のタスクからなる。

7.1.2.3.1.1

開発者は，次のソフトウェア要求事項（品質特性仕様を含む。）を確立し，文書化する。

a) 性能，物理特性及びソフトウェア品目が動作する環境条件を含む機能及び能力の仕様

b) ソフトウェア品目の外部インタフェース

c) 適格性確認の要求事項

d) 運用及び保守の方法，環境への影響並びに要員の傷害に関するものを含む安全性仕様

e) 機密情報の漏えい（洩）に関するものを含むセキュリティ仕様

人的エラー及び教育訓練に配慮した人間工学仕様。それには，手作業，人間と装置との相互作用，要

員への制約及び人の注意を集中させることを必要とする分野に関係するものを含む。

g) データの定義及びデータベースの要求事項

h) 運用現場及び保守の現場における納入ソフトウェア製品の導入及び受入れに対する要求事項

利用者用文書の要求事項

利用者の運用要求事項及び実行要求事項

k) 利用者の保守要求事項

注記1 品質特性を指定するための指針は，JIS X 0129-1に規定されている。

注記2 ソフトウェア要求事項の実装優先順位を決定することが望ましい。

注記3 ユーザビリティが重要な要求事項である場合に，望むレベルのユーザビリティを得るための

勧告は，ISO/TR 18529に記述されている。附属書Eは，ユーザビリティに焦点を当てたプ

ロセスの見方を含んでいる。

7.1.2.3.1.2

開発者は，次の基準を考慮して，ソフトウェア要求事項を評価する。評価結果を文書化する。

a) システム要求事項及びシステム設計への追跡可能性

b) システム要求事項との外部一貫性

c) 内部一貫性

d) テスト可能性

e) ソフトウェア設計の実現可能性

運用及び保守の実現可能性

7.1.2.3.1.3

開発者は，7.2.6に従ってレビューを行う。

注記評価及びレビューに合格すると，ソフトウェア要求事項が承認され，ベースラインが定められ，

全ての関係する当事者に伝達される。その後のソフトウェア要求事項のベースラインへの変更

は，コスト，スケジュール及び技術面への影響に対して評価されることが望ましい。

7.1.3

ソフトウェア方式設計プロセス

注記この規格のソフトウェア方式設計プロセスは，ソフトウェア実装プロセスの下位レベルのプロ

セスである。ISO/IEC 15288の利用者は，このプロセスをISO/IEC 15288の再帰的適用におい

て，ISO/IEC 15288の方式設計プロセスによって提供することを決めてもよい。

7.1.3.1

目的

ソフトウェア方式設計プロセスは，要求事項を実装し，それに対して検証できるソフトウェアの設計を

提供することを目的とする。

7.1.3.2

成果

ソフトウェア方式設計の実施に成功すると次の状態になる。

a) ソフトウェア要求事項を実装するソフトウェア品目を表現するソフトウェア方式設計が作成され，ベ

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

ースラインが定められている。

b) 各ソフトウェア品目の内部及び外部インタフェースが定義されている。

c) ソフトウェア要求事項とソフトウェア方式設計との間の一貫性及び追跡可能性が確立されている。

7.1.3.3

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

プロジェクトは，ソフトウェア方式設計プロセスに関して，該当する組織の方針及び手順に従って，次

のアクティビティを実行する。

注記このアクティビティを，各ソフトウェア品目に対して，システム方式設計と矛盾せずに，実施

する。

7.1.3.3.1

ソフトウェア方式設計

各ソフトウェア品目（識別されている場合，ソフトウェア構成品目）に対して，このアクティビティは，

次のタスクからなる。

7.1.3.3.1.1

開発者は，ソフトウェア品目に対する要求事項を，最上位レベルの構造を表現する方式で，

かつ，ソフトウェアコンポーネントを識別する方式に変換する。ソフトウェア品目に対する全ての要求事

項がソフトウェアコンポーネントに割り当てられ，更に詳細設計を容易にするために細分化されることを

確実にする。ソフトウェア品目の方式を文書化する。

注記ソフトウェア方式設計は，ソフトウェア品目，ソフトウェア品目間相互の結合，及びソフトウ

ェア品目とシステム品目の残りとの結合を検証する基礎も提供する。

7.1.3.3.1.2

開発者は，ソフトウェア品目の外部インタフェース及びソフトウェア品目のソフトウェアコ

ンポーネント間のインタフェースについての最上位レベルの設計を行い，文書化する。

7.1.3.3.1.3

開発者は，データベースについての最上位レベルの設計を行い，文書化する。

7.1.3.3.1.4

開発者は，利用者用文書の暫定版を作成し，文書化することが望ましい。

7.1.3.3.1.5

開発者は，ソフトウェア結合のために暫定的なテスト要求事項及びスケジュールを定義し，

文書化する。

7.1.3.3.1.6

開発者は，次の基準を考慮して，ソフトウェア品目の方式並びにインタフェース設計及びデ

ータベース設計を評価する。評価結果を文書化する。

a) ソフトウェア品目の要求事項への追跡可能性

b) ソフトウェア品目の要求事項との外部一貫性

c) ソフトウェアコンポーネント間の内部一貫性

d) 使用した設計方法及び作業標準の適切さ

e) 詳細設計の実現可能性

運用及び保守の実現可能性

7.1.3.3.1.7

開発者は，7.2.6に従ってレビューを行う。

7.1.4

ソフトウェア詳細設計プロセス

注記この規格のソフトウェア詳細設計プロセスは，ソフトウェア実装プロセスの下位レベルのプロ

セスである。

7.1.4.1

目的

ソフトウェア詳細設計プロセスは，要求事項及びソフトウェア方式に対して実装し，検証でき，コーデ

ィング及びテストを可能にするために十分に詳細である設計をソフトウェアのために提供することを目的

とする。

7.1.4.2

成果

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

ソフトウェア詳細設計の実施に成功すると次の状態になる。

a) 構築するソフトウェアユニットを表現する各ソフトウェアコンポーネントの詳細設計が行われてい

る。

b) 各ソフトウェアユニットの外部インタフェースが定義されている。

c) 一貫性及び追跡可能性が詳細設計と要求事項及び方式設計との間に確立されている。

7.1.4.3

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

プロジェクトは，ソフトウェア詳細設計プロセスに関して，該当する組織の方針及び手順に従って，次

のアクティビティを実行する。

7.1.4.3.1

ソフトウェア詳細設計

各ソフトウェア品目（識別されている場合，ソフトウェア構成品目）に対して，このアクティビティは，

次のタスクからなる。

7.1.4.3.1.1

開発者は，ソフトウェア品目の各ソフトウェアコンポーネントに対して詳細設計を行う。ソ

フトウェアコンポーネントをコーディングし，コンパイルし，テストできるソフトウェアユニットを含む

ような下位のレベルまで詳細化する。全てのソフトウェア要求事項は，ソフトウェアコンポーネントから

ソフトウェアユニットへ割り当てられていることを確実にする。詳細設計を文書化する。

7.1.4.3.1.2

開発者は，ソフトウェア品目の外部インタフェース，ソフトウェアコンポーネント間のイン

タフェース，及びソフトウェアユニット間のインタフェースの詳細設計を行い，文書化する。インタフェ

ースの詳細設計は，それ以上の情報なしでコーディングが可能になる。

7.1.4.3.1.3

開発者は，データベースの詳細設計を行い，文書化する。

7.1.4.3.1.4

開発者は，必要に応じて利用者用文書を更新する。

7.1.4.3.1.5

開発者は，ソフトウェアユニットをテストするためにテスト要求事項及びスケジュールを定

義し，文書化する。テスト要求事項は，要求事項の限界においてソフトウェアユニットに負荷をかけるこ

とを含んでいることが望ましい。

7.1.4.3.1.6

開発者は，ソフトウェア結合のためにテスト要求事項及びスケジュールを更新する。

7.1.4.3.1.7

開発者は，次の基準を考慮して，ソフトウェアの詳細設計及びテスト要求事項を評価する。

評価結果を文書化する。

a) ソフトウェア品目の要求事項への追跡可能性

b) 方式設計との外部一貫性

c) ソフトウェアコンポーネントとソフトウェアユニットとの間の内部一貫性

d) 使用した設計方法及び作業標準の適切さ

e) テストの実現可能性

運用及び保守の実現可能性

7.1.4.3.1.8

開発者は，7.2.6に従って，レビューを行う。

7.1.5

ソフトウェア構築プロセス

注記この規格のソフトウェア構築プロセスは，ソフトウェア実装プロセスの下位レベルのプロセス

である。

7.1.5.1

目的

ソフトウェア構築プロセスは，ソフトウェア設計を適切に反映した実行可能なソフトウェアユニットを

作り出すことを目的とする。

7.1.5.2

成果

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

ソフトウェア構築プロセスの実施に成功すると次の状態になる。

a) 検証基準が，要求事項に対して，全てのソフトウェアユニットに定義されている。

b) 設計によって定義されたソフトウェアユニットが作られている。

c) ソフトウェアユニットと要求事項及び設計との間に一貫性及び追跡可能性が確立されている。

d) 要求事項及び設計に対してソフトウェアユニットの検証が達成されている。

7.1.5.3

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

プロジェクトは，ソフトウェア構築プロセスに関して，該当する組織の方針及び手順に従って，次のア

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

7.1.5.3.1

ソフトウェア構築

各ソフトウェア品目（識別されている場合，ソフトウェア構成品目）に対して，このアクティビティは，

次のタスクからなる。

7.1.5.3.1.1

開発者は，次を作成し，文書化する。

a) 各ソフトウェアユニット及びデータベース

b) 各ソフトウェアユニット及びデータベースをテストするためのテスト手順及びデータ

7.1.5.3.1.2

開発者は，要求事項を満たすことを確実にする各ソフトウェアユニット及びデータベースを

テストする。テスト結果を文書化する。

7.1.5.3.1.3

開発者は，必要に応じて利用者用文書を更新する。

7.1.5.3.1.4

開発者は，ソフトウェア結合のためのテスト要求事項及びスケジュールを更新する。

7.1.5.3.1.5

開発者は，次の基準を考慮して，ソフトウェアコード及びテスト結果を評価する。評価結果

を文書化する。

a) ソフトウェア品目の要求事項及び設計への追跡可能性

b) ソフトウェア品目の要求事項及び設計との外部一貫性

c) ソフトウェアユニットの要求事項間の内部一貫性

d) ソフトウェアユニットのテスト網羅性

e) 使用したコーディング方法及び作業標準の適切さ

ソフトウェア結合及びテストの実現可能性

g) 運用及び保守の実現可能性

7.1.6

ソフトウェア結合プロセス

注記この規格の中のソフトウェア結合プロセスは，ソフトウェア実装プロセスの下位レベルのプロ

セスである。ISO/IEC 15288の利用者は，このプロセスをISO/IEC 15288の再帰的適用におい

て，ISO/IEC 15288の結合プロセスによって提供することを決めてもよい。

7.1.6.1

目的

ソフトウェア結合プロセスは，ソフトウェアユニット及び構成部品を組み合わせ，結合されたソフトウ

ェア品目を作り出すことを目的とする。それは，ソフトウェア設計と一貫性があり，機能及び非機能ソフ

トウェア要求事項を同等の又は完備した運用プラットフォームの上で満たすことを示すものである。

7.1.6.2

成果

ソフトウェア結合プロセスの実施に成功すると次の状態になる。

a) ソフトウェア設計及び優先順位付けられたソフトウェア要求事項との一貫性があるソフトウェアユニ

ットのための結合戦略が作成されている。

b) ソフトウェア品目に割り当てられているソフトウェア要求事項との適合を確認するソフトウェア品目

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

のための検証基準が作成されている。

c) ソフトウェア品目を定義された基準を使用して検証している。

d) ソフトウェア結合戦略によって定義されたソフトウェア品目が作られている。

e) ソフトウェア結合テストの結果が記録されている。

ソフトウェア設計とソフトウェア品目との間に一貫性及び追跡可能性が確立されている。

g) 回帰戦略が作成され，ソフトウェアユニット（関連する要求事項，設計及びコードを含む。）に変更が

生じたときにソフトウェア品目を再検証するために適用されている。

7.1.6.3

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

プロジェクトは，ソフトウェア結合プロセスに関して，該当する組織の方針及び手順に従って，次のア

クティビティを実施する。

7.1.6.3.1

ソフトウェア結合

各ソフトウェア品目（識別されている場合，ソフトウェア構成品目）に対して，このアクティビティは，

次のタスクからなる。

7.1.6.3.1.1

開発者は，ソフトウェアユニット及びソフトウェアコンポーネントをソフトウェア品目に結

合するために結合計画を作成する。計画は，テスト要求事項，手順，データ，責任及びスケジュールを含

む。計画を文書化する。

7.1.6.3.1.2

開発者は，結合計画に従って，ソフトウェアユニット及びソフトウェアコンポーネントを結

合し，集合体が作成されるごとに，テストする。そうすれば，各集合体がソフトウェア品目の要求事項を

満たしていること及び結合作業の終わりにソフトウェア品目が結合されていることが確実になる。結合及

びテスト結果を文書化する。

注記回帰戦略が作成され，ソフトウェアユニット（関連する要求事項，設計及びコードを含む。）に

変更が生じたときにソフトウェア品目を再検証するために適用されることが望ましい。

7.1.6.3.1.3

開発者は，必要に応じて利用者用文書を更新する。

7.1.6.3.1.4

開発者は，ソフトウェア品目の各適格性確認要求事項に対して，ソフトウェア適格性確認テ

ストを行うために，テストの集合，テストケース（入力，出力，テスト基準），及びテスト手順を作成し，

文書化する。開発者は，結合されたソフトウェア品目がソフトウェア適格性確認テストの準備ができてい

ることを確実にする。

7.1.6.3.1.5

開発者は，次の基準を考慮して，結合計画，設計，コード，テスト，テスト結果及び利用者

用文書を評価する。評価結果を文書化する。

a) システム要求事項への追跡可能性

b) システム要求事項との外部一貫性

c) 内部一貫性

d) ソフトウェア品目の要求事項のテスト網羅性

e) 使用したテスト標準及び方法の適切さ

期待された結果への適合

g) ソフトウェア適格性テストの実現可能性

h) 運用及び保守の実現可能性

注記評価基準は，ソフトウェア設計とソフトウェア品目との間の一貫性及び追跡可能性を含むこと

が望ましい。

7.1.6.3.1.6

開発者は，7.2.6に従ってレビューを行う。

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

7.1.7

ソフトウェア適格性確認テストプロセス

注記この規格の中のソフトウェア適格性確認テストプロセスは，ソフトウェア実装プロセスの下位

レベルのプロセスである。ISO/IEC 15288の利用者は，このプロセスをISO/IEC 15288の再帰

的適用において，ISO/IEC 15288の検証プロセスによって提供することを決めてもよい。

7.1.7.1

目的

ソフトウェア適格性確認テストプロセスは，結合されたソフトウェア製品がその定義された要求事項を

満たすことを確認することを目的とする。

7.1.7.2

成果

ソフトウェア適格性確認テストプロセスの実施に成功すると次の状態になる。

a) 結合ソフトウェアに対してソフトウェア要求事項への適合を示す基準が，作成されている。

b) 結合ソフトウェアが，定義された基準を使って検証されている。

c) テスト結果が記録されている。

d) 回帰戦略が作成され，ソフトウェア品目に変更が生じたときに結合ソフトウェアを再テストするため

に適用されている。

注記回帰戦略が作成され，ソフトウェア品目が変更されるとき，結合ソフトウェアを再テストする

ために適用されることが望ましい。

7.1.7.3

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

プロジェクトは，ソフトウェア適格性確認テストプロセスに関して，該当する組織の方針及び手順に従

って，次のアクティビティを実行する。

7.1.7.3.1

ソフトウェア適格性確認テスト

各ソフトウェア品目（識別されている場合，ソフトウェア構成品目）に対して，このアクティビティは，

次のタスクからなる。

7.1.7.3.1.1

開発者は，ソフトウェア品目に対して，適格性確認要求事項に従って，適格性確認テストを

行う。各ソフトウェア要求事項の実装は，適合性に対してテストされることを確実にする。適格性確認テ

ストの結果を文書化する。

7.1.7.3.1.2

開発者は，必要に応じて利用者用文書を更新する。

7.1.7.3.1.3

開発者は，次の基準を考慮して，設計，コード，テスト，テスト結果及び利用者用文書を評

価する。評価結果を文書化する。

a) ソフトウェア品目の要求事項のテスト網羅性

b) 期待した結果に対する適合性

c) 実施する場合は，システム結合及びテストの実現可能性

d) 運用及び保守の実現可能性

7.1.7.3.1.4

開発者は，7.2.7に従って監査を支援する。監査結果を文書化する。ハードウェア及びソフト

ウェアの両方が開発中又は結合中である場合，システム適格性確認テストまで監査を延期してもよい。

7.1.7.3.1.5

監査が行われた場合に，監査が問題なく完了した後に，該当するシステム結合，システム適

格性確認テスト，ソフトウェア導入又はソフトウェア受入れ支援のために，開発者は納入ソフトウェア製

品を更新し，準備する。

注記ソフトウェア適格性確認テストプロセスは，ソフトウェア検証プロセス（7.2.4）又はソフトウ

ェア妥当性確認プロセス（7.2.5）の中で使われてもよい。

7.2

ソフトウェア支援プロセス

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

注記 7.2に記述された支援プロセスは，ソフトウェアに特有であり，ソフトウェア支援プロセスと呼

ばれている。ソフトウェア支援プロセスは，ソフトウェア実装プロセスを助けるのに不可欠な

役割を果たし，合意プロセス，システム適格性確認テストプロセス，ソフトウェア受入れ支援

プロセス，ソフトウェア運用プロセス，ソフトウェア保守プロセスなどの他のプロセスにもサ

ービスを提供することがある。

7.2.1

ソフトウェア文書化管理プロセス

注記ソフトウェア文書化管理プロセスは，この規格のプロジェクトプロセス群に含まれる情報管理

プロセスを特化したものである。

7.2.1.1

目的

ソフトウェア文書化管理プロセスは，プロセスによって作成されるソフトウェア情報の記録を作成し，

維持することを目的とする。

注記 ISO/IEC 15289は，ライフサイクルプロセス情報製品（文書）のより詳細な内容を含んでいる。

7.2.1.2

成果

ソフトウェア文書化管理プロセスの実施に成功すると次の状態になる。

a) ソフトウェア製品又はソフトウェアサービスのライフサイクルの間に作成される文書を識別する戦略

が作成されている。

b) ソフトウェア文書の作成に適用する作業標準が識別されている。

c) プロセス又はプロジェクトで作成される文書が識別されている。

d) 全ての文書の内容及び目的が指定され，レビューされ，承認されている。

e) 文書が識別された作業標準に従って作成され，利用できるようになっている。

文書が定義された基準に従って維持されている。

7.2.1.3

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

プロジェクトは，ソフトウェア文書化管理プロセスに関して，該当する組織の方針及び手順に従って，

次のアクティビティを実施する。

7.2.1.3.1

プロセスの実施

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

7.2.1.3.1.1

ソフトウェア製品のライフサイクルの期間に作成される文書を識別できる計画を作成し，文

書化し，実施する。識別した文書について，次のことを取り上げる。

a) 表題又は名称

b) 目的及び内容

c) 対象とする読者

d) 入力，作成，レビュー，修正（modification），承認，文書発行，保管，配布，保守及び構成管理に関

する手順及び責任

e) 中間版及び最終版に関するスケジュール

7.2.1.3.2

設計及び作成

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

7.2.1.3.2.1

識別した各文書は，適応可能な文書標準に従って設計する。その文書標準には，媒体，様式，

記述内容，ページ番号付け，図・表の配置，所有権・セキュリティ表示，包装及びその他の表示項目が含

まれる。

注記文書の発生及び終了の形態（例えば，口頭，テキスト，図形，数値）は任意でよいし，使用，

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

蓄積，処理，複製及び伝送に任意の媒体（例えば，電子媒体，印刷媒体，磁気媒体，光学媒体）

を使用してもよい。

7.2.1.3.2.2

文書の入力データの発生源及び適切性を確かめる。自動文書作成ツールを使用してもよい。

7.2.1.3.2.3

作成した文書を，その様式，技術的内容及び表現形式が文書標準に従っているかどうかをレ

ビューし，編集する。その文書は，発行に先立って，権限をもった者が妥当であることを承認する。

7.2.1.3.3

文書発行

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

7.2.1.3.3.1

文書は，計画に従って，作成し，提供する。文書発行及び配布には，紙，電子媒体又は他の

媒体を使用してもよい。原本の資料は，記録保持，セキュリティ，保守及びバックアップの要求事項に従

って保管する。

7.2.1.3.3.2

ソフトウェア構成管理プロセス（7.2.2）に従って，管理を実施する。

7.2.1.3.4

保守

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

7.2.1.3.4.1

文書を修正（modify）するときに必要となるソフトウェア保守プロセスのタスクを実行する

（6.4.10参照）。構成管理されている文書に対しては，ソフトウェア構成管理プロセスに従って修正

（modification）を管理する（7.2.2参照）。

7.2.2

ソフトウェア構成管理プロセス

注記ソフトウェア構成管理プロセスは，この規格のプロジェクトプロセス群に含まれる構成管理プ

ロセスを特化したものである。

7.2.2.1

目的

ソフトウェア構成管理プロセスは，プロセス又はプロジェクトのソフトウェア品目の完整性（integrity）

を確立し，維持すること，及びそれらを関係当事者が利用できるようにすることを目的とする。

7.2.2.2

成果

ソフトウェア構成管理プロセスの実施に成功すると次の状態になる。

a) ソフトウェア構成管理戦略が作成されている。

b) プロセス又はプロジェクトによって生成される品目が識別され，定義され，ベースライン化されてい

る。

c) 品目の修正（modification）及びリリースが制御されている。

d) 関係当事者が修正（modification）及びリリースを利用できるようになっている。

e) 品目及び修正（modification）の状態が記録され，報告されている。

品目の完全さ及び一貫性が確保されている。

g) 品目の保管，取扱い及び納入が制御されている。

7.2.2.3

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

プロジェクトは，ソフトウェア構成管理プロセスに関して，該当する組織の方針及び手順に従って，次

のアクティビティを実施する。

7.2.2.3.1

プロセスの実施

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

7.2.2.3.1.1

ソフトウェア構成管理計画を作成する。計画には，次のことを記述する。

− 構成管理アクティビティ

− 構成管理アクティビティを遂行するための手順及びスケジュール

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

− 構成管理アクティビティを遂行する責任を負う組織

− ソフトウェア開発，保守などの他の組織との関係

その計画を文書化し，実施する。

注記ソフトウェア構成管理の計画は，システム構成管理計画の一部となることもある。

7.2.2.3.2

構成識別

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

7.2.2.3.2.1

プロジェクトで管理されるソフトウェア品目及びそれらの版を識別する構想を確立する。各

ソフトウェア品目及びその版に対して，次のものを識別する。

− ベースラインを確立する文書

− 版の参照番号

− その他の識別の詳細

7.2.2.3.3

構成制御

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

7.2.2.3.3.1

次のことを遂行する。

− 変更依頼の識別及び記録

− 変更の分析及び評価

− 変更依頼の承認又は不承認

− 修正（modify）されたソフトウェア品目の実装，検証及びリリース

各修正（modification），その修正（modification）理由及び修正（modification）の承認が追跡できるよう

に，監査証跡を残す。安全性又はセキュリティが要求される重大な機能を取り扱う構成制御されたソフト

ウェア品目に対する全てのアクセスを制御し，監査する。

注記ソフトウェア問題解決管理プロセスは，このアクティビティを支援することができる。

7.2.2.3.4

構成状態の記録

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

7.2.2.3.4.1

管理された構成制御されたソフトウェア品目の状態及び履歴を示す管理記録及び状態報告書

を，ベースラインを含め，準備する。状態報告書には，プロジェクトにおける変更回数，最新のソフトウ

ェア品目の版，リリースの識別子，リリースの回数及びリリース間の比較を記載することが望ましい。

7.2.2.3.5

構成評価

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

7.2.2.3.5.1

要求事項に対するソフトウェア品目の機能的な完全さ及びソフトウェア品目の物理的な完全

さ（その設計及びコードが最新の技術的記述を反映しているかどうか）を決定し保証する。

7.2.2.3.6

リリース管理及び納入

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

7.2.2.3.6.1

ソフトウェア製品及び文書のリリース及び納入を公式に管理する。コード及び文書の原本は，

ソフトウェア製品の寿命のある間，保守する。特に，安全性又はセキュリティの重大な機能を含んだコー

ド及び文書は，関係する組織の方針に従って，取り扱い，保管し，こん（梱）包し，納入する。

7.2.3

ソフトウェア品質保証プロセス

7.2.3.1

目的

ソフトウェア品質保証プロセスは，作業成果物及びプロセスがあらかじめ定義された条件及び計画に従

っていることを保証することを目的とする。

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

7.2.3.2

成果

ソフトウェア品質保証プロセスの実施に成功すると次の状態になる。

a) ソフトウェア品質保証を行うための戦略が作成されている。

b) ソフトウェア品質保証の裏付けの証拠が作成され，維持されている。

c) 問題及び／又は要求事項との不適合が識別され，記録されている。

d) 製品，プロセス及びアクティビティが，適用される作業標準，手順及び要求事項に対して遵守されて

いることが検証されている。

7.2.3.3

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

プロジェクトは，ソフトウェア品質保証プロセスに関して，該当する組織の方針及び手順に従って，次

のアクティビティを実施する。

7.2.3.3.1

プロセスの実施

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

7.2.3.3.1.1

プロジェクトに適合した品質保証プロセスを確立する。品質保証プロセスの目標は，ソフト

ウェア製品及びそれらのソフトウェア製品を作り出すために採用したプロセスが，確立された要求事項に

適合し，確立された計画を遵守することを保証することである。

7.2.3.3.1.2

品質保証プロセスは，関連するソフトウェア検証プロセス（7.2.4），ソフトウェア妥当性確認

プロセス（7.2.5），ソフトウェアレビュープロセス（7.2.6）及びソフトウェア監査プロセス（7.2.7）と連

携することが望ましい。

7.2.3.3.1.3

品質保証プロセスのアクティビティ及びタスクの実施計画を作成し，文書化し，実施し，契

約が有効である間維持する。実施計画には，次の項目を含む。

a) 品質保証活動を実行するための，品質標準，方法論，手順及びツール（又は組織内の正式文書内のこ

れらについての引用）

b) 契約レビュー及びその調整のための手順

c) 品質記録の識別，収集，保管，維持及び処分のための手順

d) 品質保証活動を実施するための資源，スケジュール及び責任

e) ソフトウェア検証（7.2.4），ソフトウェア妥当性確認（7.2.5），ソフトウェアレビュー（7.2.6），ソフト

ウェア監査（7.2.7），ソフトウェア問題解決（7.2.8）などの支援プロセス群から選択したアクティビテ

ィ及びタスク

7.2.3.3.1.4

スケジュールされていて進行中の品質保証プロセスのアクティビティ及びタスクを実行す

る。問題又は契約上の要求事項との不適合が発見された場合，それらを文書化し，ソフトウェア問題解決

プロセス（7.2.8）への入力とする。これらのアクティビティ及びタスク，それらの実施，問題点及び問題

解決について記録を作成し，維持する。

7.2.3.3.1.5

品質保証のアクティビティ及びタスクの記録は，契約に書かれたとおり取得者が利用できる

ようになっている。

7.2.3.3.1.6

契約上の要求事項に適合していることを保証する責任者が客観的な評価を行えるようにし，

かつ，問題解決の開始，達成，決定及び検証を行えるように，組織上の自由，資源及び権限をもたせるこ

とを保証する。

7.2.3.3.2

製品の保証

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

7.2.3.3.2.1

契約で要求された全ての計画は，文書化し，契約に適合し，相互に矛盾なく，要求どおり実

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

行されていることを保証する。

7.2.3.3.2.2

ソフトウェア製品及び関連文書は，契約に適合し，計画を遵守することを保証する。

7.2.3.3.2.3

ソフトウェア製品の出荷の準備において，そのソフトウェア製品が契約上の要求事項を完全

に満たし，かつ，取得者が受入れ可能なものであることを保証する。

7.2.3.3.3

プロセスの保証

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

7.2.3.3.3.1

プロジェクトで使用するソフトウェアライフサイクルの各プロセス（供給，開発，運用，保

守及び品質保証を含む支援プロセス）が契約に適合し，計画を遵守していることを保証する。

7.2.3.3.3.2

組織内のソフトウェア工学の実践，開発環境，テスト環境及びライブラリが，契約に適合し

ていることを保証する。

7.2.3.3.3.3

該当する主契約の要求事項が下請負会社に伝えられていること及び下請負会社のソフトウェ

ア製品が主契約の要求事項を満たすことを保証する。

7.2.3.3.3.4

取得者及び他の当事者が，契約，折衝及び計画に従って，必要な支援及び協力を得られるこ

とを保証する。

7.2.3.3.3.5

ソフトウェア製品及びプロセスの測定方法が，確立された作業標準及び手順に従っているこ

とを保証する。

7.2.3.3.3.6

配置された要員が，プロジェクトの要求事項を満たすために必要なスキル及び知識をもち，

必要な教育訓練を受けることを保証する。

7.2.3.3.4

品質システムの保証

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

7.2.3.3.4.1

追加の品質管理活動は，JIS Q 9001の箇条に従って保証されてもよい。

7.2.4

ソフトウェア検証プロセス

7.2.4.1

目的

ソフトウェア検証プロセスは，プロセス又はプロジェクトのそれぞれのソフトウェア作業成果物及び／

又はソフトウェアサービスが指定の要求事項を適切に反映していることの確認を目的とする。

7.2.4.2

成果

ソフトウェア検証プロセスの実施に成功すると次の状態になる。

a) 検証戦略が作成され，実施されている。

b) 全ての要求されたソフトウェア作業成果物の検証基準が識別されている。

c) 要求された検証のアクティビティが実施されている。

d) 欠陥が識別され，記録されている。

e) 顧客及び他の関係当事者が検証のアクティビティの結果を利用できるようになっている。

7.2.4.3

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

プロジェクトは，ソフトウェア検証プロセスに関して，該当する組織の方針及び手順に従って，次のア

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

7.2.4.3.1

プロセスの実施

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

7.2.4.3.1.1

検証作業及びその作業が必要とする組織上の独立性の度合いを正当化するかどうかをプロジ

ェクトが決定する。プロジェクト要求事項を重大性の点から分析する。重大性は，次の観点で判断される

ことがある。

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

a) システム要求事項又はソフトウェア要求事項に内在する未検出の誤りの可能性。これによって，死亡

若しくは負傷，任務の失敗，金銭的損失，又は壊滅的な装置の損失若しくは損害を引き起こされるこ

とがある。

b) 使用するソフトウェア技術の成熟度及び関連するリスク

c) 資金及び資源の可用性

7.2.4.3.1.2

プロジェクトが検証作業を正当化する場合，ソフトウェア製品を検証するために検証プロセ

スを確立する。

7.2.4.3.1.3

プロジェクトが独立した検証作業を正当化する場合，検証を実施する責任をもつ権限を与え

られた組織を選択する。この組織には，検証アクティビティを遂行するための独立性及び権限を保証する。

7.2.4.3.1.4

範囲，規模，複雑度及び上記の重大性分析に基づいて，検証を必要とする対象ライフサイク

ルアクティビティ及びソフトウェア製品を決める。対象とするライフサイクルアクティビティ及びソフト

ウェア製品に対応して，7.2.4.3.2で規定する検証アクティビティ及びタスクを，そのタスクを実施するた

めに関連する方法，手法及びツールを含めて，選択する。

7.2.4.3.1.5

確定した検証タスクに基づいて，検証計画を作成し，文書化する。検証計画は，検証を必要

とするライフサイクルアクティビティ及びソフトウェア製品，各ライフサイクルアクティビティ及びソフ

トウェア製品に必要な検証タスク，並びに関連する資源，責任及びスケジュールを取り上げる。検証計画

は，取得者及び他の関連組織への検証報告書の配布のための手順を取り上げる。

7.2.4.3.1.6

検証計画を実施する。検証作業で検出された問題点及び不適合は，ソフトウェア問題解決プ

ロセス（7.2.8参照）に引き渡す。問題点及び不適合は全て解決する。取得者及び他の関連組織が検証アク

ティビティの結果を利用できるようにする。

7.2.4.3.2

検証

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

7.2.4.3.2.1

要求事項の検証

次に示す基準を考慮して，要求事項を検証する。

a) システム要求事項に一貫性があり，実現可能であり，テスト可能である。

b) 設計基準に従って，システム要求事項をハードウェア品目，ソフトウェア品目及び手作業に適切に割

り当てている。

c) ソフトウェア要求事項に一貫性があり，実現可能であり，テスト可能であり，システム要求事項を正

確に反映している。

d) 安全性，セキュリティ及び重大性に関係するソフトウェア要求事項が，適切に厳密な方法で示すよう

に正確である。

7.2.4.3.2.2

設計の検証

次に示す基準を考慮して，設計を検証する。

a) 設計は正確で，要求事項と一貫性があり，要求事項に対して追跡可能である。

b) 設計は，事象，入力，出力，インタフェース，論理の流れ，予算の執行時期及びその規模，並びに誤

りの定義，分離及び回復について，適切な順序で実装している。

c) 選ばれた設計は，要求事項から導き出すことができる。

d) 設計は，適切に厳密な方法で示すように，安全性，セキュリティ及びその他の重大な要求事項を正し

く実装している。

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

7.2.4.3.2.3

コードの検証

次に示す基準を考慮して，コードを検証する。

a) コードは，設計及び要求事項へ追跡可能であり，テスト可能で，正確であり，要求事項及びコーディ

ング標準に適合している。

b) コードは，適切な事象の順序，一貫性があるインタフェース，正確なデータ及びコントロールの流れ，

完全さ，予算の執行時期及びその規模，並びに誤りの定義，分離及び回復を実装している。

c) 選択されたコードは，設計又は要求事項から導き出される。

d) コードは，適度に厳密な方法で示されるように，安全性，セキュリティ及び他の重大要求事項を正し

く実装している。

7.2.4.3.2.4

結合の検証

次に示す基準を考慮して，結合を検証する。

a) 各ソフトウェア品目のソフトウェア構成要素及びユニットが完全にかつ正確にソフトウェア品目に結

合されている。

b) システムのハードウェア品目，ソフトウェア品目及び手作業が完全にかつ正確にシステムに結合され

ている。

c) 結合タスクが，結合計画に従って実施されている。

7.2.4.3.2.5

文書の検証

次に示す基準を考慮して，文書を検証する。

a) 文書が適切で，完全で，一貫性がある。

b) 文書化の準備が時宜を得ている。

c) 文書の構成管理が指定された手順に従っている。

7.2.5

ソフトウェア妥当性確認プロセス

7.2.5.1

目的

ソフトウェア妥当性確認プロセスは，ソフトウェア作業成果物の特定の意図された用途に対する要求事

項が満たされていることを確認することを目的とする。

7.2.5.2

成果

ソフトウェア妥当性確認プロセスの実施に成功すると次の状態になる。

a) 妥当性確認戦略が作成され，実施されている。

b) 要求された全ての作業成果物の妥当性確認の基準が識別されている。

c) 要求された妥当性確認のアクティビティが実施されている。

d) 問題が識別され，記録されている。

e) 開発したソフトウェア作業成果物が意図した用途に適しているという証拠が提供されている。

顧客及び他の関係当事者が妥当性確認のアクティビティの結果を利用できるようになっている。

7.2.5.3

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

プロジェクトは，ソフトウェア妥当性確認プロセスに関して，該当する組織の方針及び手順に従って，

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

7.2.5.3.1

プロセスの実施

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

7.2.5.3.1.1

妥当性確認作業及びその作業が必要とする組織上の独立性の度合いをプロジェクトは正当化

するかどうかを決定する。

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

7.2.5.3.1.2

プロジェクトが妥当性確認作業を正当化する場合，システム又はソフトウェア製品を妥当性

確認するために妥当性確認プロセスを確立する。次に定義する妥当性確認タスクを，そのタスクを遂行す

るための関連する方法，手法及びツールを含めて，選択する。

7.2.5.3.1.3

プロジェクトが独立した作業を正当化する場合，作業を行う責任をもつ適格な組織を選択す

る。この作業の実施者には，妥当性確認タスクを実施するための独立性及び権限を保証する。

7.2.5.3.1.4

妥当性確認計画を作成し，文書化する。計画には，次の項目を含むが，これに限定するもの

ではない。

a) 妥当性確認の対象である品目

b) 実行する妥当性確認タスク

c) 妥当性確認のための資源，責任及びスケジュール

d) 取得者及び他の当事者への妥当性確認報告書を配布する手順

7.2.5.3.1.5

妥当性確認計画を実行する。妥当性確認作業によって検出された問題点及び不適合箇所は，

ソフトウェア問題解決プロセス（7.2.8参照）に引き渡す。問題点及び不適合箇所を全て解決する。取得者

及び他の関連組織が妥当性確認アクティビティの結果を利用できるようにする。

7.2.5.3.2

妥当性確認

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

注記テストに加えて他の手段（分析，モデル化，シミュレーションなど）を妥当性確認のために使

用してもよい。

7.2.5.3.2.1

テスト結果を分析するために，選択されたテスト要求事項，テストケース及びテスト仕様を

準備する。

7.2.5.3.2.2

これらのテスト要求事項，テストケース及びテスト仕様は，特定の意図された用途に対応し

た特有の要求事項を反映していることを確実にする。

7.2.5.3.2.3

次のものを含めて，7.2.5.3.2.1及び7.2.5.3.2.2のテストを行う。

a) 高負荷状態テスト，境界テスト及び異常入力テスト

b) 誤りの影響を分離し，最小化する能力についてのソフトウェア製品のテスト。すなわち，故障時の緩

やかな機能縮退，負荷状態時・境界状態時・異常状態時における操作員への支援要請についてのテス

ト

c) 典型的利用者がソフトウェア製品を使用し，意図した業務を成功裏に達成できるかどうかのテスト

7.2.5.3.2.4

ソフトウェア製品が，意図した用途を満足しているかどうかを妥当性確認する。

7.2.5.3.2.5

必要に応じて，実環境の部分を選定し，ソフトウェア製品をテストする。

7.2.6

ソフトウェアレビュープロセス

7.2.6.1

目的

ソフトウェアレビュープロセスは，合意目標に対する進捗，及び利害関係者を満足させる製品の開発を

確実にするために実施が望ましいことについて利害関係者と共通理解を維持することを目的とする。ソフ

トウェアレビューは，プロジェクト管理レベル及び技術レベルの双方で行われ，プロジェクトが存在する

間実施されている。

7.2.6.2

成果

ソフトウェアレビュープロセスの実施に成功すると次の状態になる。

a) 管理面及び技術面のレビューがプロジェクトのニーズに基づいて行われている。

b) プロセスのアクティビティの状況及び成果物がレビューのアクティビティを通して評価されている。

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

c) 影響を受ける全ての当事者にレビューの結果が知らされている。

d) レビューの結果生じる行動項目が終結まで追跡されている。

e) リスク及び問題が識別され，記録されている。

7.2.6.3

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

プロジェクトは，ソフトウェアレビュープロセスに関して，該当する組織の方針及び手順に従って，次

のアクティビティを実施する。

7.2.6.3.1

プロセスの実施

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

7.2.6.3.1.1

プロジェクト計画で指定された所定のマイルストーンで，定期的なレビューを実施する。利

害関係者は，合意している当事者が参加してもよい臨時のレビューのニーズを決めることが望ましい。

7.2.6.3.1.2

レビューの実施に必要な全ての資源を提供する。これらの資源には，人員，場所，施設，ハ

ードウェア，ソフトウェア及びツールを含む。

7.2.6.3.1.3

レビューに参加する当事者は，レビューごとに，次の事項について合意することが望ましい。

− 議題

− レビュー対象となるソフトウェア製品（アクティビティの成果）及び問題点

− レビューの範囲及び手順

− レビューの開始及び終了の基準

7.2.6.3.1.4

レビュー時に検出された問題点を記録し，必要に応じてソフトウェア問題解決プロセス

（7.2.8）に引き渡す。

7.2.6.3.1.5

レビュー結果を，文書化し，配布する。この伝達は，レビュー結果のレビューの妥当性（例

えば，承認，不承認又は条件付承認）を含む。

7.2.6.3.1.6

参加当事者は，レビュー成果，並びに対処する必要がある項目の責任の所在及び終結基準に

合意する。

7.2.6.3.2

プロジェクト管理レビュー

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

7.2.6.3.2.1

プロジェクトの状況を，該当するプロジェクト計画，スケジュール，作業標準及び指針に照

らし合わせて評価する。レビューの成果は，適切な管理者によって検討され，次の事項をもたらすことが

望ましい。

a) 活動又はソフトウェア製品の状態の評価に基づいて，計画に従って活動が進むようにする。

b) 資源の適切な配分を通じて，全般的なプロジェクトの管理を維持する。

c) プロジェクトの方向を変える，又は代替計画のニーズを決定する。

d) プロジェクトの成功を危うくする可能性のあるリスク問題を評価し，管理する。

7.2.6.3.3

技術レビュー

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

7.2.6.3.3.1

検討中のソフトウェア製品又はソフトウェアサービスを評価し，次の事項を明らかにするた

めに，技術レビューを実施する。

a) ソフトウェア製品又はソフトウェアサービスが，完全である。

b) ソフトウェア製品又はソフトウェアサービスが，作業標準及び仕様に沿っている。

c) ソフトウェア製品又はソフトウェアサービスに対する変更が適切に実施され，ソフトウェア構成管理

プロセス（7.2.2参照）で識別された部分だけに影響する。

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

d) ソフトウェア製品又はソフトウェアサービスが，該当するスケジュールに沿っている。

e) ソフトウェア製品又はソフトウェアサービスが，次に計画されている活動の準備ができている。

開発，運用又は保守は，プロジェクトの計画，スケジュール，作業標準及び指針に従って実行されて

いる。

7.2.7

ソフトウェア監査プロセス

7.2.7.1

目的

ソフトウェア監査プロセスは，選ばれた製品及びプロセスが，該当する要求事項，計画及び合意に対し

て，適合しているかどうかを独立に決定することを目的とする。

7.2.7.2

成果

ソフトウェア監査プロセスの実施に成功すると次の状態になる。

a) ソフトウェア監査戦略が作成され，実施されている。

b) 要求事項，計画及び合意に対する，選択されたソフトウェア作業成果物及び／又はソフトウェアサー

ビス又はプロセスの適合性が監査戦略に従って決定されている。

c) 独立した適切な組織によって監査が実施されている。

d) 監査で検出された問題が識別され，是正処置及び解決の責任者に伝達されている。

7.2.7.3

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

プロジェクトは，ソフトウェア監査プロセスに関して，該当する組織の方針及び手順に従って，次のア

クティビティを実施する。

7.2.7.3.1

プロセスの実施

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

7.2.7.3.1.1

プロジェクト計画に指定された所定のマイルストーンにおいて，監査を実施する。

7.2.7.3.1.2

監査人は，監査対象となるソフトウェア製品及び活動に，いかなる直接的責任ももってはな

らない。

7.2.7.3.1.3

監査の実施に必要な全ての資源は，当事者間で合意する。これらの資源には，要員，場所，

施設，ハードウェア，ソフトウェア及びツールを含む。

7.2.7.3.1.4

当事者は監査ごとに，次の事項について合意することが望ましい。

− 議題

− 監査対象となるソフトウェア製品（及び活動の成果）

− 監査の範囲及び手順

− 監査の開始及び終了の基準

7.2.7.3.1.5

監査時に検出された問題点を記録し，必要に応じてソフトウェア問題解決プロセス（7.2.8）

に引き渡す。

7.2.7.3.1.6

監査終了後，監査結果を文書化し，監査を受けた当事者に提供する。監査を受けた当事者は，

監査で見付けられた問題点，及び計画した関連する問題解決策を監査者に知らせる。

7.2.7.3.1.7

当事者は，監査成果並びに対処すべき項目の責任の所在及び終結基準に合意する。

7.2.7.3.2

ソフトウェア監査

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

7.2.7.3.2.1

次の事項を保証するために，ソフトウェア監査を実施する。

a) コーディングに示されたとおり，ソフトウェア製品（例えば，ソフトウェア品目）が設計文書を反映

している。

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

b) 文書で指定された受入れレビュー及びテストの要求事項がソフトウェア製品の受入れに十分である。

c) テストデータが仕様に従っている。

d) ソフトウェア製品は，成功裏にテストが完了し，仕様を満足している。

e) テスト報告書が正確であり，実際の結果と予想の結果との食い違いが解決されている。

利用者用文書が，指定された作業標準に従っている。

g) 該当する要求事項，計画及び契約に従って，活動が実行されている。

h) コスト及びスケジュールが，確立された計画に沿っている。

7.2.8

ソフトウェア問題解決プロセス

7.2.8.1

目的

ソフトウェア問題解決プロセスは，発見された全ての問題を解決するために識別し，分析し，管理し，

制御することを目的とする。

7.2.8.2

成果

ソフトウェア問題解決プロセスの実施に成功すると次の状態になる。

a) 問題管理戦略が作成されている。

b) 問題の記録，識別及び分類がなされている。

c) 受入れ可能な解決法を識別するために，問題が分析され，アセスメントされている。

d) 問題解決が実施されている。

e) 間題が終結するまで追跡されている。

報告された全ての問題の状態が知らされている。

注記ソフトウェア問題解決プロセスは，ソフトウェア変更要求を管理し，追跡し，制御するために

使用されるか，又は容易に適応される。

7.2.8.3

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

プロジェクトは，ソフトウェア問題解決プロセスに関して，該当する組織の方針及び手順に従って，次

のアクティビティを実施する。

7.2.8.3.1

プロセス開始の準備

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

7.2.8.3.1.1

ソフトウェア製品及びアクティビティの中で検出された全ての問題（不適合を含む。）を取り

扱うために，問題解決プロセスを確立する。このプロセスは，次の要求事項に従う。

a) このプロセスは閉ループになっており，次の事項を確実にする。

− 検出された全ての問題を，迅速に報告し，問題解決プロセスに引き渡す。

− 行動を開始する。

− 必要がある場合には，関係当事者に問題が存在することを通知する。

− 原因を識別し，分析し，可能な場合，除去する。

− 解決及び処分を達成する。

− 状況を追跡し，報告する。

− 契約に明記されたとおりに，問題の記録を維持する。

b) このプロセスは，問題の種類分け及び優先順位付けの構想を含むことが望ましい。傾向分析及び問題

解決を容易にするために，それぞれの問題を種類及び優先順位によって分類することが望ましい。

c) 報告された問題の傾向を見付けるために分析する。

d) 問題解決及び処分は，次のとおりに評価する。

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

− 問題が解決し，悪化傾向が逆転し，適切なソフトウェア製品及び活動において，変更が正しく実現

されたことを評価する。

− 新たな問題が持ち込まれたかどうかを調査する。

7.2.8.3.2

問題解決

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

7.2.8.3.2.1

ソフトウェア製品又はアクティビティに（不適合を含め）問題が検出された場合，検出され

た各問題を記述するために，問題報告書を作成する。問題報告書は，上述の閉じたループのプロセスの一

部分として，問題の検出から，問題及びその原因の調査，分析並びに解決を通して，問題を横断して傾向

を検出することに用いる。

7.3

ソフトウェア再利用プロセス

注記組織としてソフトウェアの再利用を実践することを望むこの規格の利用者は，この規格の規定

（条項）とともにIEEE Std 1517-1999のソフトウェア再利用プロセスの規定で補足することも

考えられる。

7.3.1

ドメイン（領域）エンジニアリングプロセス

7.3.1.1

目的

ドメインエンジニアリングプロセスは，ドメインモデル，ドメイン方式及びドメインのための資産を作

成し，維持することを目的とする。

7.3.1.2

成果

ドメインエンジニアリングプロセスの実施に成功すると次の状態になる。

a) ドメインモデル及びドメイン方式の表現様式が選択されている。

b) ドメインの境界及び他のドメインとの関係が確立されている。

c) ドメインの中で本質的な共通特性及び異特性，能力，概念並びに機能を捉えたドメインモデルが作成

されている。

d) ドメイン内のシステムの集まりを表現した，共通性及び変動性を含めドメイン方式が作成されている。

e) ドメインに属する資産が指定されている。

ドメインに属する資産が取得又は作成され，ライフサイクルを通して維持されている。

g) ドメインモデル及びドメイン方式がライフサイクルを通して維持されている。

注記1 ドメインエンジニアリングは，システム，サブシステム又はアプリケーションの一つのクラ

スに対して範囲（すなわち，ドメイン定義）の定義，構造（すなわち，ドメイン方式）の仕

様，及び資産（例えば，要求事項，設計，ソフトウェアコード，文書）の構築への再利用を

ベースとしたアプローチである。

注記2 ドメインエンジニアリングプロセスは，ドメインエンジニアリングプロセスによって生成さ

れた資産を使用する開発及び保守プロセスと重複してもよい。

7.3.1.3

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

プロジェクトは，ドメインエンジニアリングプロセスに関して，該当する組織の方針及び手順に従って，

次のアクティビティを実施する。

注記 IEEE Std 1517は，次に示すアクティビティ及びタスクを調整したアクティビティ及びタスクで

更に詳細なものの集合を提供する。

7.3.1.3.1

プロセスの実施

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

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

7.3.1.3.1.1

ドメインエンジニアは，ドメインエンジニアリング計画を作成し，実行する。

7.3.1.3.1.2

ドメインエンジニアは，ドメイン方式及びドメインモデルに使用する表現形式を選択する。

7.3.1.3.1.3

ドメインエンジニアは，ドメインエンジニアによって作成された資産に対する問題又は変更

要求が起こるたびに，受領し，解決し，資産管理者にフィードバックを提供する手順を確立する。

7.3.1.3.2

ドメインの分析

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

7.3.1.3.2.1

ドメインエンジニアは，ドメインの境界及びこのドメインと他のドメインとの関係を定義す

る。

7.3.1.3.2.2

ドメインエンジニアは，このドメイン内のソフトウェア製品の利害関係者の現在及び予想さ

れるニーズを識別する。

7.3.1.3.2.3

ドメインエンジニアは，このプロセスに対するプロセス実施アクティビティで選択した表現

形式を用いてドメインモデルを構築する。

7.3.1.3.2.4

ドメインエンジニアは，重要なドメイン概念，及び，ドメインの類似又は共通の資産の間の

関係を表現するための専門用語を集めた用語集を作成する。

7.3.1.3.2.5

ドメインエンジニアは，ドメインモデルを分類し，文書化する。

7.3.1.3.2.6

ドメインエンジニアは，選択されたモデル化手法の規定に従い，かつ，組織の資産受入れ手

順及び認証手順に従って，ドメインモデル及びドメイン用語集を評価する。

7.3.1.3.2.7

ドメインエンジニアは，ドメイン分析のレビューを実施する。そのレビューには，ソフトウ

ェア開発者，資産管理者，ドメインの専門家及び利用者が参加する。

7.3.1.3.2.8

ドメインエンジニアは，ドメインモデルを資産管理者へ提出する。

7.3.1.3.3

ドメインの設計

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

7.3.1.3.3.1

ドメインエンジニアは，ドメインモデルに一貫性があり，組織の作業標準に従った，ドメイ

ン方式を作成し，文書化する。

7.3.1.3.3.2

ドメイン方式は，選択された方式設計手法の規定，並びに組織の資産受入れ手順及び認証手

順に従って評価される。

7.3.1.3.3.3

再利用のために設計するように選択された各実体に対して，ドメインエンジニアは，資産の

仕様書を作成し，文書化する。

7.3.1.3.3.4

指定された各資産に対して，組織の資産受入れ手順及び認証手順に従って，仕様を評価する。

評価結果を文書化する。

7.3.1.3.3.5

ドメインエンジニアは，ドメイン設計のレビューを実施する。ソフトウェア開発者，ドメイ

ンの専門家及び資産管理者がレビューに参加する。

7.3.1.3.3.6

ドメインエンジニアは，ドメイン方式を資産管理者へ提出する。

7.3.1.3.4

資産の準備

作成又は取得された各資産に対して，このアクティビティは，次のタスクからなる。

7.3.1.3.4.1

ドメインエンジニアは，取得又は開発によって資産を入手する。

7.3.1.3.4.2

ドメインエンジニアは，資産を文書化し，分類する。

7.3.1.3.4.3

ドメインエンジニアは，組織の資産受入れ手順及び認証手順に従って，資産を評価する。

7.3.1.3.4.4

ドメインエンジニアは，資産のレビューを実施する。ソフトウェア開発者及び資産の管理者

がレビューに参加する。

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

7.3.1.3.4.5

ドメインエンジニアは，資産を資産管理者へ提出する。

7.3.1.3.5

資産の保守

次の再利用関連のタスクは，資産の保守に適用されるときに，このソフトウェア保守プロセスへ加えら

れる。

7.3.1.3.5.1

資産の修正（modification）要求を分析し，実施の選択肢を選ぶ場合には，ドメインエンジニ

アは，次のことを考慮する。

a) ドメインモデル及びドメイン方式との適合

b) 資産を利用しているシステム及びソフトウェア製品への影響

c) 資産の将来の利用者への影響

d) 資産の再利用性への影響

7.3.2

再利用資産管理プロセス

7.3.2.1

目的

再利用資産管理プロセスは，構想から廃止までの再利用資産の存続期間を管理することを目的とする。

7.3.2.2

成果

再利用資産管理プロセスの実施に成功すると次の状態になる。

a) 資産管理戦略が文書化されている。

b) 資産分類の構想が確立されている。

c) 資産の受入れ，認証及び廃止の基準が定義されている。

d) 資産の保管及び検索の仕組みが運用されている。

e) 資産の利用が記録されている。

資産への変更が制御されている。

g) 資産の利用者は，次のことを通知されている。

− 検出された問題

− 実施された修正（modification）

− 作成された新版

− 保管及び検索の仕組みからの資産の削除

7.3.2.3

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

プロジェクトは，再利用資産管理プロセスに関して，該当する組織の方針及び手順に従って，次のアク

ティビティを実施する。

7.3.2.3.1

プロセス実施

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

7.3.2.3.1.1

資産管理者は，資産を管理するための資源及び手順を定義するために，資産管理計画を作成

する。

7.3.2.3.1.2

資産管理者は，計画を実行する。

7.3.2.3.1.3

資産管理計画をソフトウェアレビュープロセスに従ってレビューする。ドメインエンジニア

及び再利用施策管理者がレビューに参加する。

7.3.2.3.2

資産の保管及び検索の定義

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

7.3.2.3.2.1

資産管理者は，資産保管及び検索の仕組みを作成し，維持する。

7.3.2.3.2.2

資産管理者は，資産分類に使われる分類構想を作成し，文書化し，維持する。

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

7.3.2.3.2.3

資産管理者は，資産保管及び検索の仕組みをソフトウェアレビュープロセスに従ってレビュ

ーする。再利用施策管理者及びドメインエンジニアがレビューに参加する。

7.3.2.3.3

資産管理及び制御

各資産に対して，このアクティビティは，次のタスクからなる。

7.3.2.3.3.1

資産管理者に提出された各資産を資産受入れ基準及び認証基準に基づいて評価する。

7.3.2.3.3.2

受け入れられた各資産は，資産の保管及び検索の仕組みを通じて再利用ができるようになる。

7.3.2.3.3.3

資産は，再利用分類構想がある場合は，それに従って分類される。

7.3.2.3.3.4

資産管理者は，ソフトウェア構成管理プロセスを使用して，資産の構成管理を実施する。

7.3.2.3.3.5

資産管理者は，資産の各再利用の経過を追い，資産の実際の再利用についての情報をドメイ

ンエンジニアに報告する。

7.3.2.3.3.6

資産管理者は，資産の再利用者から受け取った資産の修正（modification）要求及び問題報告

をレビューし，是正・修正（modification）計画を作成し，措置するために，ドメインエンジニアに送付す

る。

7.3.2.3.3.7

資産管理者は，これらの資産に対する要求・報告及びそれに続く実施された措置を監視し，

記録する。

7.3.2.3.3.8

資産管理者は，全ての資産再利用者及びドメインエンジニアに次のことを通知する。

− 資産から検出された問題

− 資産に対して実施された修正（modification）

− 資産の新しい版

− 資産の保管及び検索の仕組みから資産の削除

7.3.2.3.3.9

資産管理者は，資産廃止の手順及び基準に従って，資産の保管及び検索の仕組みから資産を

停止する。

7.3.3

再利用施策管理プロセス

7.3.3.1

目的

再利用施策管理プロセスは，組織の再利用施策を計画，確立，管理，制御及び監視すること並びに再利

用の機会を体系的に活用することを目的とする。

7.3.3.2

成果

再利用施策管理プロセスの実施に成功すると次の状態になる。

a) 目的，範囲，ゴール及び目標を含む組織の再利用戦略が定義されている。

b) 再利用の機会が潜在するドメインが特定されている。

c) 組織の体系的な再利用の能力がアセスメントされている。

d) ドメインごとの再利用の潜在的な可能性がアセスメントされている。

e) 再利用の提案が評価されて，再利用製品が提案されたアプリケーションに適切であることを確認され

ている。

組織内で再利用戦略が実施されている。

g) 影響を受ける当事者の間でのフィードバックの仕組み，コミュニケーションの仕組み及び伝達の仕組

みが確立されている。

h) 再利用施策が監視され，評価されている。

注記影響を受ける当事者には，再利用施策管理者，資産管理者，ドメインエンジニア，開発者，運

用者及び保守者を含んでもよい。

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

7.3.3.3

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

プロジェクトは，再利用施策管理プロセスに関して，該当する組織の方針及び手順に従って，次のアク

ティビティを実行する。

7.3.3.3.1

開始

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

7.3.3.3.1.1

組織のための再利用施策は，再利用のゴール，目的，目標及び範囲を含む組織の再利用戦略

を確立することによって開始される。

7.3.3.3.1.2

再利用スポンサ（後援者）が指名されることが望ましい。

7.3.3.3.1.3

再利用施策への関与者が識別され，役割が割り当てられる。

7.3.3.3.1.4

再利用運営部門が，組織の再利用施策に対する権限及び責任を果たすために設立される。

7.3.3.3.1.5

再利用施策支援部門を設立する。

7.3.3.3.2

ドメインの識別

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

7.3.3.3.2.1

再利用施策管理者は，適切な管理者，ドメインエンジニア，利用者及びソフトウェア開発者

から支援を受けて，再利用機会を調査するドメイン又は組織が再利用の実践を意図するドメインを識別し，

文書化する。

7.3.3.3.2.2

再利用施策管理者は，適切な管理者，ドメインエンジニア，利用者，及びソフトウェア開発

者から支援を受けて，ドメインが組織の再利用戦略を正確に反映していることを保証するためにドメイン

を評価する。

7.3.3.3.2.3

再利用施策管理者は，ソフトウェアレビュープロセスに従ってレビューを実行する。ソフト

ウェア開発者，ドメインエンジニア及び利用者がそのレビューに参加する。

7.3.3.3.2.4

将来のソフトウェア製品に対する組織のドメイン及び計画に関するより多くの情報が利用可

能となるに従い，又はドメインが分析されたとき，ドメインは，再利用施策管理者によって見直しされた

り，範囲が変更されてもよい。

7.3.3.3.3

再利用アセスメント

このアクティビティの目的は，次のとおりである。

7.3.3.3.3.1

再利用施策管理者は，組織の体系的な再利用能力をアセスメントする。

7.3.3.3.3.2

再利用施策管理者は，ドメインにおける再利用が成功する可能性を判断するために，再利用

が考慮されている各ドメインをアセスメントする。

7.3.3.3.3.3

再利用施策管理者は，再利用アセスメントの結果に基づいて，組織の再利用戦略及び再利用

施策実施計画を見直すために勧告を行う。

7.3.3.3.3.4

再利用施策管理者は，適切な取得者，供給者，開発者，運用者，保守者，資産管理者，及び

ドメインエンジニアと協力して，再利用インフラストラクチャを一緒に構成するスキル，技術，再利用プ

ロセス，組織構造，及びメトリクスを段階的に改善する。

7.3.3.3.4

計画

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

7.3.3.3.4.1

再利用施策実施計画は，再利用施策を実施することに対する資源及び手順を定義するために，

作成され，文書化され，維持される。

7.3.3.3.4.2

計画は，次の基準を考慮してレビューされ，評価される。

a) 完全さ

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

b) 実施の実現可能性

c) 組織の再利用戦略を実現する能力

計画を評価する人たちには，再利用運営部門の構成員を含むことが望ましい。

7.3.3.3.4.3

再利用施策実施計画は，再利用運営部門及び適切な管理者から承認され，支援される。

7.3.3.3.4.4

再利用施策管理者は，ソフトウェアレビュープロセスに従ってレビューを実施する。再利用

運営部門の構成員及び適切な管理者は，そのレビューに参加する。

7.3.3.3.5

実行及び制御

このアクティビティは，次のタスクからなる。組織の再利用戦略及び戦略を実現するために計画に必要

な調整である。

7.3.3.3.5.1

再利用施策実施計画におけるアクティビティは，その計画に従って実施される。

7.3.3.3.5.2

再利用施策管理者は，組織の再利用戦略に対して再利用施策の進捗を監視し，戦略を実現す

るために計画に必要な調整を行う。

7.3.3.3.5.3

再利用施策実施計画の実行中に発生する問題及び不適合を記録し，解決する。

7.3.3.3.5.4

再利用施策管理者は，再利用施策に対するマネジメントによる資金援助，後援，及び確約を

定期的に再確認する。

7.3.3.3.6

レビュー及び評価

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

7.3.3.3.6.1

再利用施策管理者は，再利用施策による組織の再利用戦略の達成度，並びに再利用施策の継

続した適切性及び有効性について，再利用施策を定期的にアセスメントする。

7.3.3.3.6.2

再利用施策管理者は，再利用運営部門及び適切な管理者に，アセスメントの結果及び学んだ

教訓を提供する。

7.3.3.3.6.3

再利用施策管理者は，再利用施策への変更を勧告し，変更を行い，再利用施策を拡張し，そ

れに従って再利用施策を改善する。

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

附属書A

（規定）

修整（tailoring）プロセス

A.1 序文

この附属書Aは，修整（tailor）プロセスを実施する場合の要求事項を規定する。

注記修整（tailor）は，規格に適合させるための要求事項ではない。事実上，“完全な適合”を主張

する場合は，修整（tailor）は許されない。“修整（tailor）された適合”を主張する場合は，こ

のプロセスによって要求されるように修整（tailor）を行うこととなる。

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.2.3.1 修整（tailor）に影響を与える状況を識別し，文書化する。これらの影響は，次を含むが，それに

限定するものではない。

a) 運用環境の安定性及び多様性

b) 当事者の懸念である商業リスク又は業績リスク

c) 新規性，規模及び複雑さ

d) 利用開始日及び利用期間

e) 安全性，セキュリティ，プライバシ，ユーザビリティ，可用性などの完整性（integrity）に関する課題

新たな技術の機会

g) 利用可能な予算及び組織の資源のプロファイル（概要）

h) イネーブリングシステムのサービスの可用性

システムのライフサイクル全体における役割及び責任

他の作業標準に適合する必要

A.2.3.2 特性がシステムに対して重大な場合，重大性の側面に関連する作業標準が推奨する，又は要求す

るライフサイクルの構造を十分に考慮する。

A.2.3.3 修整（tailor）の決定によって影響を受ける全ての当事者から意見を聞く。当事者には，次のもの

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

を含むが，それに限定するものではない。

a) システムの利害関係者

b) その組織による合意に関心をもつ当事者

c) 寄与する組織の部門

A.2.3.4 選択されたライフサイクルモデルの目的及び成果を達成するため，意思決定管理プロセスに従っ

て修整（tailor）の決定を下す。

注記1 組織は，ライフサイクルモデル管理プロセスの一部として作業標準のライフサイクルモデル

を設定する。設定するライフサイクルモデルの段階の目的及び成果を達成するために，組織

がこの規格のプロセスを修整（tailor）することが適切な場合がある。

注記2 プロジェクトは，組織で設定したライフサイクルモデルを，プロジェクト計画プロセスの一

部として，そのプロジェクトのために選択する。選択されたライフサイクルモデルの段階の

目的及び成果を達成するために，組織が採用したプロセスを修整（tailor）することが適切な

場合がある。

注記3 プロジェクトがこの規格を直接的に適用する場合，適切なライフサイクルモデルの段階の目

的及び成果を達成するために，この規格のプロセスを修整（tailor）することが適切な場合が

ある。

A.2.3.5 修整（tailor）を必要とするライフサイクルプロセスを選択し，選択された成果，アクティビティ

又はタスクを削除する。

注記1 修整（tailor）に関わりなく，組織及びプロジェクトは，この規格に適合するために要求され

る成果又はアクティビティ及びタスクのほかに，追加の成果を達成するか又は追加のアクテ

ィビティ及びタスクを実施するプロセスを実施することは常に許される。

注記2 組織又はプロジェクトは，この規格の規定を修正（modify）したい状況に遭遇することがあ

る。他のプロセス，成果，アクティビティ又はタスクに予測できない結果に至る可能性があ

るので，修正（modification）を避けることが望ましい。必要な場合は，［修整（tailor）され

た適合性を適切に主張して］規定を削除することによって修正（modification）が実行され，

かつ，影響に注意深く配慮して，修整（tailor）された規格の成果又はアクティビティ及びタ

スクのほかに，追加の成果を達成するか又は追加のアクティビティ及びタスクを実行するプ

ロセスを実施することによって修正（modification）が実行される。

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

附属書B

（規定）

アセスメント目的のプロセス参照モデル（Process Reference Model: PRM）

B.1

序文

この規格の利用者の中には，実施されたプロセスをJIS X 0145-2に従ってアセスメントを実施したいと

思っている人がいることが知られている。この附属書Bは，JIS X 0145-2との関連において使用すると適

切なプロセス参照モデルを提供する。

このモデルのプロセスの元は，この規格の本文中のプロセスである。各々のプロセスにおいて，この規

格の本文中の各プロセスの名称，目的の記述及び成果の記述をこの附属書Bの中で参照して使用している。

場合によっては，規格の本文中のプロセスの範囲は，効果的にアセスメントを行うには大き過ぎるとみな

される。それゆえに，これらの場合には，アセスメントの目的のために，この附属書Bには下位のレベル

のプロセスが加えられている。これらの追加の下位レベルのプロセスの各々は，この規格の本文中の関連

プロセスのアクティビティの一つの詳細を示すものである。

B.2

JIS X 0145-2との適合

B.2.1 概要

この附属書Bに含まれるプロセス参照モデルは，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) プロセス参照モデルの領域の宣言

これは，箇条1に規定されている。

b) JIS X 0145-2の6.2.4の要求事項を満足するプロセス参照モデルの適用範囲内のプロセスの記述

これは，B.3に規定されている。

c) プロセス参照モデルとそれを利用しようとしている背景との間の関係の記述

これは，箇条5に規定されている。

d) プロセス参照モデル内に定義しているプロセスの間の関係の記述

これは，各プロセス記述においてB.3に規定されている。例えば，この附属書Bの中のプロセスの

記述の中には，そのプロセスは下位のプロセスであり，上位の特定のアクティビティに置き換わると

いう記述を含むものがある。

プロセス参照モデルは，そのモデルに関心をもっている人たち及びその人たちの中で合意を得るための

行動を，次のように文書化する。

1) 直接的に関心のある人たちを特徴付けるか，指定する。直接的に関心のある人たちは，ISO/IEC 15288

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

及びこの規格の利用者である。

2) 合意の達成度合いを文書化する。ISO/IEC 15288及びこの規格は，ISO/IEC JTC 1の合意の要求事項を

満たす規格である。

3) 合意達成のための行動をとらない場合，その影響を文書化する（該当なし）。

プロセス参照モデルで定義されたプロセスは，一意のプロセス記述及び識別情報をもっていなければな

らない。プロセスの記述は一意であり，識別は一意の名前及びこの附属書Bの箇条番号による。

B.2.3 プロセスの記述

プロセス参照モデルの基本的な構成要素は，そのモデルの適用範囲内でのプロセス記述である。プロセ

ス参照モデルでのプロセス記述は，プロセスの目的の十分な達成を実証する一連の成果とともに，プロセ

スを実施する全体的な目標を高い水準で記載したプロセスの目的の記述から成り立っている。これらのプ

ロセス記述は，次の要求事項を満足しなければならない。

a) プロセスは，プロセスの目的及びプロセスの成果で記述する。

b) どのプロセス記述においても，一連のプロセスの成果はプロセスの目的を達成するために必要十分で

ある。

c) プロセス記述は，JIS X 0145-2の箇条5の水準1を超えたところの測定の枠組みの側面を含んでいな

いし，また，暗示もしていない。

成果の記述の項目には，次のいずれか一つを記述する。

− 作業生産物の生産

− 状態の重要な変化

− 特定の制約条件（例えば，要求事項，目標など）を満たすこと

これらの要求事項は，この附属書Bの中のプロセスの記述によって満たされる。成果の中にはレベル2

以上のレベルの能力へ寄与すると解釈されるものもある。しかしながら，関連プロセスの適合した実施は

これらの上位レベルの能力の達成を要しない。

B.2.4 能力決定のための共通プロセス属性

この規格の5.1.9の中の属性は，各プロセスの特殊性を示している。実施されたプロセスがこれらの属性

に適合するとき，プロセスの具体的に定義された目的及び成果は，定義されたアクティビティの実施を通

じて達成される。

これらの基本的属性に加えて，プロセスは全てのプロセスに共通な他の属性によって特徴付けられる。

これらの共通な属性は，JIS X 0145-2に定義されている高水準のプロセス能力の達成に寄与する。JIS X

0145-2の測定の枠組みには，表B.1に記述されているように，六つのレベルのプロセス能力がある。

表B.1−プロセス能力の六つのレベル

能力のレベル

プロセス能力

不完全なプロセス

実施されたプロセス

管理されたプロセス

確立されたプロセス

予測可能なプロセス

最適化しているプロセス

上位の属性及び能力の達成は，そのプロセスと文書化管理プロセス，構成管理プロセス，品質保証プロ

セスなどの支援及び組織のプロセスとの相互作用によって可能となる。

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

JIS X 0145-2は，上位のプロセス能力の達成に関連する次の共通のプロセス属性（PA）を識別する。

− 実行管理属性（PA 2.1）

この属性は，プロセスの実行が管理される度合いを決める。この属性の達成は，プロセスの実行を計画

し，監視し，調整することを含む。

− 作業生産物管理属性（PA 2.2）

この属性は，プロセスによって作り出された作業生産物が適切に管理される度合いを決める。この属性

の達成は，作業作成物が適切に確立され，制御され，保守されることを確実にする。

− プロセス定義属性（PA 3.1）

この属性は，プロセスが組織内で標準プロセスとして確立されている度合いを決める。この属性の達成

は，プロセスを実行するために必要とされる能力及び役割，必要とされるインフラストラクチャ及び作業

環境，その有効性及び適合性を監視する方法，並びに修整（tailor）の指針に関してプロセスの定義を含む。

− プロセス展開属性（PA 3.2）

この属性は，プロセスが標準プロセスの修整（tailor）の事例として効果的に展開されている度合いを決

める。この属性の達成は，標準プロセスへの忠実度，プロセスの実施への資源の効果的展開，及びプロセ

スの振る舞いを理解し，詳細化するためのデータの収集及び分析に反映される。

− プロセス計測属性（PA 4.1）

この属性は，定義された事業目標の達成を支援することを確実にするのに，プロセスの計測が使用され

る度合いを決める。この属性の達成は，プロセスの実施及び作業作成物の品質に関する測定量の収集のた

めの効果的なシステムの存在に関係している。測定量は，組織の事業目標の達成の度合いを決めるために

適用される。

− プロセス制御属性（PA 4.2）

この属性は，定義された範囲内で安定し，能力があり，予測可能であるプロセスを作り出すために，プ

ロセスが定量的に管理される度合いを決定する。この属性の達成は，プロセスが定義された範囲内で実行

されること，及び逸脱に対処するための是正処置が取られることを確実にするために分析及び制御手法の

適用を意味する。

− プロセス革新属性（PA 5.1）

この属性は，実施の変動の分析並びにプロセスの定義及び実施の革新的アプローチの調査から，プロセ

スの変更が識別される度合いを決める。この属性の達成は，現行及び将来の事業目標の両者の成就におけ

る連続的改善への積極的な着目の存在に関係している。

− プロセス最適化属性（PA 5.2）

この属性は，プロセスの定義，管理及び実行に対する変更が，結果として関連するプロセス改善目標を

達成する効果的影響をもたらす程度を決める。この属性の達成は，望ましくない中断を最小限にし，変更

の有効性を評価し，必要に応じて調整を行う適切なプロセス変更を識別し，導入することへの規則的及び

積極的アプローチに関係している。

B.3

プロセス参照モデル

プロセス参照モデルは，この規格の箇条6及び箇条7に含まれる各プロセスの目的及び成果の記述によ

って構成されている。これらは，表B.2に挙げられている。

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

表B.2−この規格のプロセス

JIS X 0160の箇条番号

及び細分箇条番号

この規格のプロセス名

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

6.1

合意プロセス

6.1.1

取得プロセス

6.1.2

供給プロセス

6.2

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

6.2.1

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

6.2.2

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

6.2.3

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

6.2.4

人的資源管理プロセス

6.2.5

品質管理プロセス

6.3

プロジェクトプロセス

6.3.1

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

6.3.2

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

6.3.3

意思決定管理プロセス

6.3.4

リスク管理プロセス

6.3.5

構成管理プロセス

6.3.6

情報管理プロセス

6.3.7

測定プロセス

6.4

テクニカルプロセス

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

ソフトウェア廃棄プロセス

ソフトウェア固有プロセス

7.1

ソフトウェア実装プロセス

7.1.1

ソフトウェア実装プロセス

7.1.2

ソフトウェア要求事項分析プロセス

7.1.3

ソフトウェア方式設計プロセス

7.1.4

ソフトウェア詳細設計プロセス

7.1.5

ソフトウェア構築プロセス

7.1.6

ソフトウェア結合プロセス

7.1.7

ソフトウェア適格性確認テストプロセス

7.2

ソフトウェア支援プロセス

7.2.1

ソフトウェア文書化管理プロセス

7.2.2

ソフトウェア構成管理プロセス

7.2.3

ソフトウェア品質保証プロセス

7.2.4

ソフトウェア検証プロセス

7.2.5

ソフトウェア妥当性確認プロセス

7.2.6

ソフトウェアレビュープロセス

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

表B.2−この規格のプロセス（続き）

JIS X 0160の箇条番号

及び細分箇条番号

この規格のプロセス名

7.2.7

ソフトウェア監査プロセス

7.2.8

ソフトウェア問題解決プロセス

7.3

ソフトウェア再利用プロセス

7.3.1

ドメイン（領域）エンジニアリングプロセス

7.3.2

再利用資産管理プロセス

7.3.3

再利用施策管理プロセス

箇条6及び箇条7のプロセスのアクティビティの中には対応する下位のプロセスで置き換えられるアク

ティビティがある。これらの下位のプロセスの記述は，次に示すとおりである。

B.3.1 取得プロセスの下位プロセス

B.3.1.1 取得準備プロセス

このプロセスは，取得プロセスの下位プロセスであり，取得準備アクティビティ（6.1.1.3.1）と置き換わ

る。

B.3.1.1.1 目的

取得準備プロセスの目的は，取得のニーズ及び目標を確立し，これらを供給者の候補に伝えることであ

る。

B.3.1.1.2 成果

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

a) 取得，開発又は改良のための概念又はニーズが確立されている。

b) 利害関係者の要求事項が定義されている。

c) 取得戦略が作成されている。

d) 供給者選定基準が定義されている。

B.3.1.2 供給者選定プロセス

このプロセスは，取得プロセスの下位プロセスであり，供給者選定アクティビティ（6.1.1.3.3）と置き換

わる。

B.3.1.2.1 目的

供給者選定プロセスは，プロジェクトの要求事項を満たすものを納入する責任がある組織を選定するこ

とを目的とする。

B.3.1.2.2 成果

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

a) 供給者選定基準が確立され，供給者の候補の評価に使用されている。

b) 供給者による提案の評価，プロセス能力の評価及び他の要因の評価に基づいて供給者が選定されてい

る。

c) 取得者と供給者との間で合意が協議され，確立している。

B.3.1.3 合意監視プロセス

このプロセスは，取得プロセスの下位プロセスであり，合意監視アクティビティ（6.1.1.3.5）と置き換わ

る。

B.3.1.3.1 目的

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

合意監視プロセスの目的は，合意した要求事項に対して供給者の実行を追跡し，アセスメントを行うこ

とである。

B.3.1.3.2 成果

合意監視プロセスの実施に成功すると次の状態になる。

a) 必要に応じて取得者と供給者との間で共同の活動が行われている。

b) 技術的進歩の情報を定期的に供給者と交換している。

c) 供給者の実行が合意された要求事項に対して監視されている。

d) 必要な場合，合意の変更が取得者と供給者との間で交渉され，合意が文書化されている。

B.3.1.4 取得者受入れプロセス

このプロセスは，取得プロセスの下位プロセスであり，取得者の受入れアクティビティ（6.1.1.3.6）と置

き換わる。

B.3.1.4.1 目的

取得者受入れプロセスの目的は，全ての受入れ基準が満たされたときに，供給者の納品物を承認するこ

とである。

B.3.1.4.2 成果

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

a) 納入されたソフトウェア製品及び／又はソフトウェアサービスが合意に基づき評価されている。

b) 取得者の受入れは，合意された受入れ基準に基づいている。

c) ソフトウェア製品及び／又はソフトウェアサービスは，取得者によって受け入れられている。

B.3.2 供給プロセスの下位プロセス

B.3.2.1 供給者の提案依頼プロセス

このプロセスは，供給プロセスの下位プロセスであり，供給者の提案依頼アクティビティ（6.1.2.3.2）と

置き換わる。

B.3.2.1.1 目的

供給者の提案依頼プロセスの目的は，取得者の問合せ及び提案依頼書に応じ，提案書を用意し，提出す

るためのインタフェースを確立することである。

B.3.2.1.2 成果

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

a) 取得者の問合せ及び提案依頼書に応じるためにコミュニケーションのインタフェースが確立され，維

持されている。

b) 提案依頼書は，提案書を提出するかどうかを決めるために定義された基準に従って評価されている。

c) 暫定的調査又は実現可能性の検討を行う必要性が決められている。

d) 提案された作業を行う適切な資源が識別されている。

e) 取得者の依頼に応じて供給者の提案書が用意され，提出されている。

B.3.2.2 契約の合意プロセス

このプロセスは，供給プロセスの下位プロセスであり，契約の合意アクティビティ（6.1.2.3.3）と置き換

わる。

B.3.2.2.1 目的

契約の合意プロセスは，供給者及び取得者の両者の期待，責任，作業生産物・納入可能物及び義務を明

確にかつ曖昧ではなく指定する契約・合意について交渉し，承認することを目的とする。

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

B.3.2.2.2 成果

契約の合意プロセスの実施に成功すると次の状態になる。

a) 契約・合意が交渉され，レビューされ，承認され，供給者に渡されている。

b) 供給者の能力及び実行の監視並びに識別されたリスクの軽減のために，仕組みがレビューされ，契約

条件に含めることが考慮されている。

c) 提案者・入札者に提案・入札の結果が伝えられている。

d) 合意の公式な確認が得られている。

注記契約の合意プロセスは，供給者の見積依頼プロセスの間に提案された割当ての公式の確認を得

るために使用されている。

B.3.2.3 製品・サービス納入及び支援プロセス

このプロセスは，供給プロセスの下位プロセスである。それは，製品・サービス納入及び支援アクティ

ビティ（6.1.2.3.5）と置き換わる。

B.3.2.3.1 目的

製品・サービス納入及び支援プロセスは，要求事項が満たされているという確信を得るのに適切な支援

を伴う指定の製品又はサービスを取得者に提供することを目的とする。

B.3.2.3.2 成果

製品・サービス納入及び支援プロセスの実施に成功すると次の状態になる。

a) 製品リリースの内容が決められている。

b) そのリリースは構成された品目から集められている。

c) リリース文書が定義され，作成されている。

d) リリースの納入の仕組み及び媒体が決められている。

e) 定義された基準に対してリリースの承認が有効になっている。

製品リリースが取得者に利用可能となっている。

g) リリースの確認が得られている。

h) 製品が完成し，取得者に納入されている。

取得者受入れテスト及びレビューが支援されている。

製品が顧客の環境で運用開始の状態にある。

k) 受入れで検出された問題は，識別され，解決に責任をもつ関係者に伝えられている。

注記段階的に納入する部分は，出来上がるごとに納入する。

B.3.3 ライフサイクルモデル管理プロセスの下位プロセス

B.3.3.1 プロセスの確立プロセス

このプロセスは，ライフサイクルモデル管理プロセスの下位プロセスであり，プロセスの確立アクティ

ビティ（6.2.1.3.1）と置き換わる。

B.3.3.1.1 目的

プロセスの確立プロセスは，組織の事業活動に適用されるように，全てのライフサイクルプロセスに対

して組織の一連のプロセスを確立することを目的とする。

B.3.3.1.2 成果

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

a) 各プロセスの適用性の表示とともに，プロセスの定義されたかつ維持された一組の作業標準が確立さ

れている。

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

b) 標準プロセスの詳細なタスク，アクティビティ及び関連する作業生産物が，期待される実行特性とと

もに識別されている。

c) プロジェクトのニーズに従って，製品又はサービスの標準プロセスを修整（tailor）するための戦略が

作成されている。

d) 特定プロジェクトに対する標準プロセスの使用に関係した情報及びデータが存在し，維持されている。

B.3.3.2 プロセスアセスメントプロセス

このプロセスは，ライフサイクルモデル管理プロセスの下位プロセスであり，プロセスのアセスメント

アクティビティ（6.2.1.3.2）と置き換わる。

B.3.3.2.1 目的

プロセスアセスメントプロセスは，組織の標準プロセスがその事業目標の達成に寄与する度合いを決め，

継続的なプロセス改善についてのニーズに組織が焦点を当てる助けとなることを目的とする。

B.3.3.2.2 成果

プロセスアセスメントプロセスの実施に成功すると次の状態になる。

a) 特定プロジェクトに対する標準プロセスの使用に関係した情報及びデータが存在し，維持されている。

b) 組織の標準プロセスの相対的強み及び弱みが理解されている。

c) 正確でかつアクセス可能なアセスメントの記録が保管され，維持されている。

B.3.3.3 プロセスの改善プロセス

このプロセスは，ライフサイクルモデル管理プロセスの下位プロセスであり，プロセスの改善アクティ

ビティ（6.2.1.3.3）と置き換わる。

B.3.3.3.1 目的

プロセスの改善プロセスは，使用され，維持され，かつ，事業ニーズと連携しているプロセスを通して

継続的に組織の有効性及び効率を改善することを目的とする。

B.3.3.3.2 成果

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

a) 改善活動を維持するために資源を提供する確約が得られている。

b) 組織の内部環境・外部環境から生じる問題が改善の機会として識別され，変更の理由として正当化さ

れている。

c) 改善の刺激が生じるプロセスに焦点を当て，既存のプロセスの現状分析が行われている。

d) 改善目標が識別され，優先順位が付けられ，結果としてのプロセスの変更が定義され，実施されてい

る。

e) プロセス実施の効果が監視され，定義された改善目標に対して確認されている。

改善から得られた知識が，組織内に伝達されている。

g) 行われた改善が評価され，組織内の他所での解決に使用することが考慮されている。

注記1 変更の入力を提供する情報源は，プロセスアセスメントの結果，監査報告，顧客満足度の報

告書，組織の有効性・効率，品質のコストを含めてもよい。

注記2 プロセスの現状は，プロセスアセスメントによって決めてもよい。

B.3.4 人的資源管理プロセスの下位プロセス

B.3.4.1 スキル開発プロセス

このプロセスは，人的資源管理プロセスの下位プロセスであり，スキル開発アクティビティ（6.2.4.3.2）

と置き換わる。

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

B.3.4.1.1 目的

スキル開発プロセスは，役割を効果的に行うために必要とされるスキル及び知識をもつ人を，組織及び

プロジェクトに，提供することを目的とする。

B.3.4.1.2 成果

スキル開発プロセスの実施に成功すると次の状態になる。

a) 組織及びプロジェクトの教育ニーズに対応するために教育訓練が開発されているか又は取得されてい

る。

b) 教育訓練の戦略，教材などの仕組みを使用して，全ての人が職務を果たすために必要とされるスキル

をもつことを確実にするために，教育訓練が行われる。

B.3.4.2 スキル取得及び提供プロセス

このプロセスは，人的資源管理プロセスの下位プロセスであり，スキル取得及び提供アクティビティ

（6.2.4.3.3）と置き換わる。

B.3.4.2.1 目的

スキル取得及び提供プロセスは，職務を効果的に果たすのに必要とされるスキル及び知識をもち，まと

まったグループの一員として働ける人を組織及びプロジェクトに提供することを目的とする。

B.3.4.2.2 成果

スキル取得及び提供プロセスの実施に成功すると次の状態になる。

a) 必要なスキル及び能力をもった個人が識別され，採用されている。

b) 個人とグループとの間の効果的相互作用が支援されている。

c) 作業要員は情報を共有し，その活動を効率的に調整するスキルをもっている。

d) 実績をフィードバックし，かつ，実績を向上させるべくグループ及び個々の人の実績が監視されるた

めの客観的基準が定義されている。

B.3.4.3 知識管理プロセス

知識管理プロセスは，人的資源管理プロセスの下位プロセスであり，知識管理アクティビティ（6.2.4.3.4）

と置き換わる。

B.3.4.3.1 目的

知識管理プロセスは，組織を通じて個人の知識，情報及びスキルが収集され，共有され，再利用され，

改善されることを確実にすることを目的とする。

B.3.4.3.2 成果

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

a) 組織をまたがって共通の情報及びドメインの情報を共有するインフラストラクチャが確立し，維持さ

れている。

b) 組織を通じて知識が容易に利用可能で共有されている。

c) 組織が適切な知識管理戦略を選定している。

B.3.5 ソフトウェア運用プロセスの下位プロセス

B.3.5.1 実運用プロセス

このプロセスは，ソフトウェア運用プロセスの下位プロセスであり，実運用アクティビティ（6.4.9.3.3）

と置き換わる。

B.3.5.1.1 目的

実運用プロセスは，意図された使用期間の間，導入された環境で，製品の正しい，効率的な運用を確実

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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

B.3.5.1.2 成果

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

a) 製品の導入及び運用に対する運用リスクが識別され，監視されている。

b) 製品は，要求事項に従って意図された環境で，運用されている。

c) 合意された要求事項に適合することを示す実運用のための基準が作成されている。

B.3.5.2 顧客支援プロセス

このプロセスは，ソフトウェア運用プロセスの下位プロセスであり，顧客支援アクティビティ（6.4.9.3.4）

と置き換わる。

B.3.5.2.1 目的

顧客支援プロセスは，製品の効果的使用を支援するために顧客への援助及びコンサルティングを通じて，

受入れ可能なレベルのサービスを確立し，維持することを目的とする。

B.3.5.2.2 成果

顧客支援プロセスの実施に成功すると次の状態になる。

a) 顧客支援のためのサービスのニーズが識別され，継続的に監視されている。

b) 提供中の支援サービス及び製品自体の両者についての顧客満足度が継続的に評価されている。

c) 運用支援が顧客の問合せ及び依頼を処理し，運用上の問題を解決することによって提供されている。

d) 顧客支援のニーズは，適切なサービスの納入によって満たされている。

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

附属書C
（参考）

履歴及び理論的根拠

C.1 序文

この附属書Cは，この規格及びこの規格の基となったISO/IEC 12207についての履歴及び理論的根拠を

記述し，文書の構造を説明するものである。

C.2 履歴

ISO/IEC 12207の初版は，1995年に発行されている。その規格の開発者は，ソフトウェア開発における

二者間の問題の解決を手助けするために，プロセス並びにそれらのアクティビティ及びタスクを記述する

必要性を見いだした。ISO/IEC 12207:1995は，“何が”なされるべきかを指向しており，プロセスをアク

ティビティ及びタスクに関して記述している。

同じ時期に，ソフトウェア産業は，プロセス改善及び供給者選定中のリスクの軽減を支援するために比

較可能で，繰返し可能な方法で，連続的尺度でプロセス能力を評価する必要性が，同様に重要であること

を認識した。継続的なプロセス改善，組織成熟度及び能力アセスメントの概念は，今やかなり確立され，

認識されていて，ISO/IEC 15504シリーズとして規格化されている。

プロセスの能力判定には，その記述がそのプロセスの目的の明確な記述及び期待される成果の記述を含

むことを必要とする。目的及び成果の記述は，ISO/IEC 12207:1995には欠けており，2002年及び2004年

に発行されたISO/IEC 12207の追補によって補われた。これらの追補は，完全なソフトウェアライフサイ

クルプロセスの適切なアセスメントを容易化するために多くの詳細レベルのプロセスも追加している。

ISO/IEC 12207は，システムコンテキスト内におけるソフトウェアライフサイクルプロセスを対象とし

ているが，システム領域でも同様な規格が必要なことは明らかであった。2002年11月に発行された

ISO/IEC 15288は，その必要性を満たした。この規格の開発者は，ISO/IEC 12207の追補の作成において

得られた経験から助けを得て，ISO/IEC 15504に表されたニーズを理解し，それゆえに，ISO/IEC 15288

の中のプロセスは，成果を達成するために必要とされるアクティビティの記述を含み，目的及び成果に関

して表現されている。

ISO/IEC 15288とともにISO/IEC 12207の追補の作成が停滞し，ISO/IEC 12207の当初の焦点が異なっ

ていたので，改正ISO/IEC 12207を適用することも，ソフトウェアライフサイクル規格及びシステムライ

フサイクル規格を一緒に適用することも，やや困難となった。ISO/IEC JTC 1/SC 7内の調和化プロジェク

ト（すなわち，ISO/IEC 12207及びISO/IEC 15288の並行した，注意深く制御された改正及びこれら両国

際規格のガイドラインとなるISO/IEC TR 24748の作成）は，システムライフサイクル及びソフトウェア

ライフサイクルを記述している統合化された一組の規格への最初の大きな一歩である。

C.3 目標

この規格及びこの規格の基となったISO/IEC 12207は，アセスメント分野からの要求事項を支援しなが

ら，ソフトウェアライフサイクル及びシステムライフサイクルの完全な調和化に向かう第一歩である。こ

の規格は，次の目標をもって開発された。

− ISO/IEC 12207/Amd.1:2002及びAmd.2:2004という二つの追補を組み込み，正当化する。

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

− ISO/IEC 15288の改正版とこの規格との間で共通の用語を提供する。

− 適用可能な箇所では，ISO/IEC 15288の改正版とこの規格との間で共通のプロセス名を提供する。

− 利用者たちが完全に調和された規格の方に徐々に進むことを可能にし，安定した規格を提供すること

を可能にする。

− ISO/IEC 12207及びISO/IEC 15288の作成及び使用の10年間の経験をい（活）かす。

C.4 プロセス構造及びその用途

この規格の中のプロセスの記述は，明確に定義された規則に従う。まず第一に，それらは，論理的形態

でグループにまとめられている。これらのグループ分けは，次によって決められている。

− プロセス間の論理的関係

− プロセスの実行に対する責任

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

ループに分けている。これらのグループの最上位の記述は，5.2.2に見いだされる。これらのグループ内の

ライフサイクルプロセスは，その目的及び望まれる成果に関して記述されており，これらの成果を達成す

るために実施することが必要なアクティビティ及びタスクを列挙している。

a) 合意プロセス

2個のプロセス（5.2.2.1.1及び6.1）

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

5個のプロセス（5.2.2.1.2及び6.2）

c) プロジェクトプロセス

7個のプロセス（5.2.2.1.3及び6.3）

d) テクニカルプロセス

11個のプロセス（5.2.2.1.4及び6.4）

e) ソフトウェア実装プロセス

7個のプロセス（5.2.2.2.1及び7.1）

ソフトウェア支援プロセス

8個のプロセス（5.2.2.2.2及び7.2）

g) ソフトウェア再利用プロセス

3個のプロセス（5.2.2.2.3及び7.3）

プロセス記述規則の矛盾のない適用によって，正規化した細分箇条の番号付けが可能となる。この規格

の中では，細分箇条番号は，次のようになっている。

− 6.a及び7.aは，プロセスグループの名称である。

− 6.a.b及び7.a.bは，そのグループ内のプロセス（又は下位のレベルのプロセス）の名称である。

− 6.a.b.1及び7.a.b.1は，プロセスの目的を記述する。

− 6.a.b.2及び7.a.b.2は，プロセスの成果を記述する。

− 6.a.b.3.c及び7.a.b.3.cは，プロセスのアクティビティ及び細分箇条を列挙する。

− 6.a.b.3.c.d及び7.a.b.3.c.dは，アクティビティ'c'のタスクを列挙する。

図C.1は，この規格及びISO/IEC 15288:2008の中で使用されているプロセス構造のUML表現である。

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

図C.1−ISO/IEC 12207及び15288:2008のプロセス構成概念

C.5 規格の版の間の関係

上記のように，この規格は，元となる四つの文書間の調和化の結果である。図C.2は入力となった文書

のプロセス構造間の関係を表している。

この規格とJIS X0160: 1995，JIS X 0160追補: 2007，JIS X 01070: 2004
及びISO/IEC 15288: 2008のプロセス構成の関係

プロセス

下位レベルの
プロセス

リスト

タスク

アクティビティ

プロセス

下位レベルの
プロセス

アクティビティ

タスク

注記

PRM附属書

構成の選択

JIS X 0160追補:
2007

JIS X0160: 1995

＝

P+O

この規格：
JIS X12207:2011

ISO/IEC 15288:
2008

JIS X 01070:
2004

＝

は，等しいことを意味する

新しい“グループ
化”

図C.2−プロセス構造間の関係

プロセス
名称，目的，成果

アクティビティ

名称

タスク

注記

1

1*

1

0*

プロセスは，目的及び成果を必要とする。全てのプロセス
は少なくとも一つのアクティビティをもつ。目的及び成果
の記述を伴って，プロセスは，プロセス参照モデルを構成
する。プロセス参照モデルは，附属書Bに記載されている。

アクティビティは，関連するタスクをまとめるための構成
概念である。アクティビティは，プロセスの理解と伝達を
向上するためプロセス内の関連するタスクを調べる手段を
提供する。アクティビティが十分にまとまりがあるならば，
アクティビティは，目的及び一組の成果を定義することに
よって，（下位の）プロセスに変換できる。

タスクは，プロセスの実施のための詳細な情報を提供して
いる。タスクは，要求事項（“shall”），推奨（“should”）又
は許容（“may”）であってもよい。

注記は，プロセスの意図又は仕組みをよりよく記述するた
めの説明のための情報が必要である場合に使用される。注
記は，可能性のある実装方法又は適用分野に関する，一覧，
例，他の考慮事項などの洞察を提供する。

この規格とJIS X 0160:1996，JIS X 0160追補1:2007，JIS X 0170:2004
及びISO/IEC 15288:2008のプロセス構造間の関係

JIS X 0160
追補1:2007

JIS X 0160:1996

この規格：
JIS X 0160:2012

ISO/IEC 15288:
2008

JIS X 0170:
2004

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

ISO/IEC 12207の旧版，その追補及びISO/IEC 15288の旧版の利用者の便宜のために，ISO/IEC

12207:2008の調整プロセスの規定の出所に関する情報を，表C.1は提供する。この表の中の情報は，次の

理由から注意して使用することが望ましい。

− 表の項目は，正確というよりむしろおおよそであり，作業項目の新提案の意図を反映したものである。

− 規定は，新しい状況によりよく合うように，ときには広範囲にわたって，適合されていることがある。

− 規定の文章は，意見の一致を得る過程で変更されてもよい。

表の中に挙げられた出典は，次のとおりである。

− “0160:1996”は，JIS X 0160:1996を参照。

− “追補1”は，JIS X 0160追補1:2007を参照。

− “0160:2007”は，JIS X 0160:1996及びJIS X 0160追補1:2007を参照。

− “0170:2004”は，JIS X 0170:2004を参照。

− “15939”は，ISO/IEC 15939:2002を参照。

− “16085”は，ISO/IEC 16085:2004を参照。

表C.1−ISO/IEC 12207:2008のプロセス定義の出典

細分箇条

プロセス

目的及び成果の出典

アクティビティ及び

タスクの出典

6.1

合意プロセス

6.1.1

取得プロセス

追補1のF.1.1

0160:1996の5.1，0170:2004の
5.2.2.3

6.1.2

供給プロセス

追補1のF.1.2

0170:2004の5.2.3.3 (a，h，i)
及び0160:1996の5.2

6.2

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

6.2.1

ライフサイクルモデル管理プロセス 0170:2004の5.3，追補1のF.3.3 0160:1996の7.3

6.2.2

インフラストラクチャ管理プロセス 0170:2004の5.3，追補1のF.3.2 0160:1996の7.2

6.2.3

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

0170:2004の5.3，追補1のF.3.1.1 0170:2004の5.3.3

6.2.4

人的資源管理プロセス

0170:2004の5.3.5，追補1のF.3.4 0160:2007の7.4

6.2.5

品質管理プロセス

0170:2004の5.3.6，追補1の
F.3.1.4

0170:2004の5.3.6

6.3

プロジェクトプロセス

6.3.1

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

0170:2004の5.4.2，追補1の
F.3.1.3

0160:1996の7.1.1，7.1.2及び
7.1.3.1

6.3.2

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

0170:2004の5.4.3及び5.4.4，追
補1のF.3.1.3 (4)，(6)，(7)

0160:1996の7.1.3.2〜7.1.3.4，
7.1.4及び7.1.5

6.3.3

意思決定管理プロセス

0170:2004の5.4.5

6.3.4

リスク管理プロセス

16085の5，追補1のF.1.3.5

16085の箇条5

6.3.5

構成管理プロセス

0170:2004の5.4.7

6.3.6

情報管理プロセス

0170:2004の5.4.8

6.3.7

測定プロセス

15939の4.1，追補1のF.1.3.6

15939の箇条4及び箇条5

6.4

テクニカルプロセス

6.4.1

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

追補1のF.1.3.1

0170:2004の5.5.2

6.4.2

システム要求事項分析プロセス

追補1のF.1.3.2

0160:1996の5.3.2

6.4.3

システム方式設計プロセス

追補1のF.1.3.3

0160:1996の5.3.3

6.4.4

実装プロセス

該当なし

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

表C.1−ISO/IEC 12207:2008のプロセス定義の出典（続き）

細分箇条

プロセス

目的及び成果の出典

アクティビティ及び

タスクの出典

6.4.5

システム結合プロセス

追補1のF.1.3.9

0160:1996の5.3.10

6.4.6

システム適格性確認テストプロセス追補1のF.1.3.10

0160:2007の5.3.11

6.4.7

ソフトウェア導入プロセス

追補1のF.1.3.11

0160:1996の5.3.12

6.4.8

ソフトウェア受入れ支援プロセス

追補1のF.1.2.4

0160:1996の5.3.13

6.4.9

ソフトウェア運用プロセス

0170:2004の5.5.10，追補1の
F.1.4

0160:1996の5.4

6.4.10

ソフトウェア保守プロセス

追補1のF.1.5

0160:1996の5.5.1〜5.5.5

6.4.11

ソフトウェア廃棄プロセス

0170:2004の5.5.12，追補1の
F.1.5 (6)

0160:1996の5.5.6

7.1

ソフトウェア実装プロセス

7.1.1

ソフトウェア実装プロセス

0170:2004の5.5.5.1

0160:2007の5.3.1

7.1.2

ソフトウェア要求事項分析プロセス追補1のF.1.3.4

0160:2007の5.3.4

7.1.3

ソフトウェア方式設計プロセス

追補1のF.1.3.5

0160:1996の5.3.5

7.1.4

ソフトウェア詳細設計プロセス

追補1のF.1.3.5

7.1.5

ソフトウェア構築プロセス

追補1のF.1.3.6

0160:1996の5.3.7

7.1.6

ソフトウェア結合プロセス

追補1のF.1.3.7

0160:1996の5.3.8

7.1.7

ソフトウェア適格性確認テストプロ
セス

追補1のF.1.3.8

0160:1996の5.3.9

7.2

ソフトウェア支援プロセス

7.2.1

ソフトウェア文書化管理プロセス

追補1のF.2.1

0160:1996の6.1

7.2.2

ソフトウェア構成管理プロセス

追補1のF.2.2

0160:1996の6.2

7.2.3

ソフトウェア品質保証プロセス

追補1のF.2.3

0160:2007の6.3

7.2.4

ソフトウェア検証プロセス

追補1のF.2.4

0160:1996の6.4

7.2.5

ソフトウェア妥当性確認プロセス

追補1のF.2.5

0160:1996の6.5

7.2.6

ソフトウェアレビュープロセス

追補1のF.2.6

0160:1996の6.6

7.2.7

ソフトウェア監査プロセス

追補1のF.2.7

0160:1996の6.7

7.2.8

ソフトウェア問題解決プロセス

追補1のF.2.8

0160:1996の6.8

7.3

ソフトウェア再利用プロセス

7.3.1

ドメイン（領域）エンジニアリング
プロセス

追補1のF.3.7

追補1のG.6

7.3.2

再利用資産管理プロセス

追補1のF.3.5

追補1のG.4

7.3.3

再利用施策管理プロセス

追補1のF.3.6

追補1のG.5

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

附属書D
（参考）

この規格とISO/IEC 15288との間のプロセスの関係

この附属書Dは，この規格とISO/IEC 15288との間のプロセスの関係を記述している。

次の細分箇条のプロセスの関係は，単純明快である。この規格及びISO/IEC 15288は，個々のプロセス

に対して，同一のプロセス名及び同一の細分箇条番号を使用している。

− 6.1 合意プロセス

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

− 6.3 プロジェクトプロセス

それぞれの場合に，この規格のプロセスは，ISO/IEC 15288の一般的なプロセスをソフトウェアに特化

することを意図している。

各規格の6.4は，“テクニカルプロセス”を含んでいる。二つの規格は，これらのプロセスに対して少々

異なる名前を使用している。ある場合には，この規格のプロセスは，ISO/IEC 15288のプロセスをソフト

ウェアに特化したものである。他の場合には，この規格のプロセスは，ISO/IEC 15288の対応するプロセ

スの一つ以上の成果の達成に単に寄与するだけである。表D.1は，プロセスを列挙し，それらの関係の性

質を注記するものである。

表D.1−この規格とISO/IEC 15288とのテクニカルプロセスの関係

細分箇条

ISO/IEC 15288のプロセス名

この規格のプロセス名

関係

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

廃棄

ソフトウェア廃棄

特化

最後に，この規格の箇条7は，ソフトウェアに特有なプロセスだけを含む。

注記1 この規格では，ソフトウェア検証プロセスは，支援プロセスとして割り当てられたままにな

っていて，箇条7のソフトウェア支援プロセス群に置かれているが，そのプロセスがソフト

ウェアのシステム要素（ソフトウェア品目）のために実施される場合，そのプロセスは，

ISO/IEC 15288の検証プロセスの一つ以上の成果に寄与することがある。

注記2 この規格では，ソフトウェア妥当性確認プロセスは，支援プロセスとして割り当てられたま

まになっていて，箇条7のソフトウェア支援プロセス群に置かれているが，そのプロセスが

ソフトウェアのシステム要素（ソフトウェア品目）のために実施される場合，そのプロセス

は，ISO/IEC 15288の妥当性確認プロセスの一つ以上の成果に寄与することがある。

100

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

附属書E

（参考）

プロセスビュー

E.1

序文

特定のエンジニアリングの関心を代表している人たちが，彼らの関心事に直接的にかつ端的に対応した

一組のプロセスアクティビティを1か所に集めて見たいという場合がある。そのような人たちに対して，

ライフサイクルの全部又は一部を横断する形態で，特定の関心に焦点を当てるために，この規格又は

ISO/IEC 15288から選ばれたプロセス，アクティビティ及びタスクを編成して，プロセスビューを作成す

ることができる。この附属書Eは，これらの場合にプロセスビューを定義するために使用してもよいプロ

セスのビューポイントを提供する。

E.2

定義

ビュー：関連する一組の関心事の視点からのシステム全体の表現（ISO/IEC 42010:2007）

ビューポイント：ビューを組み立て，使用するための表現法の仕様。ビューに対する目的及びビューの

読者並びに生成及び分析の手法を確立することによって個々のビューが作成される元となるパターン又は

テンプレート（ISO/IEC 42010:2007）

注記附属書の他の部分ではなく，この定義の中で参照される“システム”は，ISO/IEC 15288及び

この規格で規定されているライフサイクルプロセスを集めたものである。

E.3

プロセスビューの概念

ライフサイクルプロセスをまたがって使われるプロセスを貫く重要な概念又は脈絡を目に見えるように

するために全く異なるプロセスから選ばれたアクティビティ及びタスクに対して，統一した焦点が必要と

される場合があってもよい。特定の関心事に対応する単一のプロセスを見付けられなくても，使用するた

めにアクティビティをどのようにして識別し，定義するかを，作業標準の利用者に助言することは有用で

ある。

この目的のために，プロセスビューの概念が公式化された。プロセスのように，プロセスビューの記述

は目的及び成果の記述を含む。プロセスとは異なり，プロセスビューの記述は，アクティビティ及びタス

クを含まない。その代わりに，その記述は，この規格及びISO/IEC 15288の様々なプロセスのアクティビ

ティ及びタスクを用いてどのようにして成果を達成できるかを説明する指針を含んでいる。

プロセスビューは，E.3.1に見いだされるプロセスビューポイントテンプレートを使用して構成できる。

E.3.1 プロセスビューポイント

プロセスビューは，プロセスビューポイントに適合している。ここに挙げられたプロセスビューポイン

トは，プロセスビューを生成するために使用できる。E.4は，このビューポイントを適用する例を含んで

いる。

プロセスビューポイントは，次によって定義される。

− その利害関係者：作業標準の利用者

− それが枠組みとなる関心事：特定のエンジニアリングの関心事を反映するために必要なプロセス

− 結果であるプロセスビューの内容には，次を含んでいる。

101

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

− プロセスビューの名称

− プロセスビューの目的

− プロセスビューの成果

− プロセスビューを実施するプロセス，アクティビティ及びタスクの識別及び記述，並びにこれらの

プロセス，アクティビティ及びタスクの元が他の作業標準のどこにあるかを示す参照。

注記ビューポイントの文書化に対する要求事項は，ISO/IEC 42010:2007の5.3に含まれている。こ

の記述は，それらの要求事項と矛盾がない。

E.4

ユーザビリティに対するプロセスビュー

ここでは，ユーザビリティに対するプロセスビューを生み出すためにプロセスビューポイントを適用す

る例を示す。それは，使用可能な製品の完成に注目するために，プロジェクトがこの規格のプロセス，ア

クティビティ及びタスクをどのように組み立てるかを解説することを意図している。

この例は，ユーザビリティ，利用者中心設計又は人間中心設計（JIS Z 8530:2000に記載）と一般に呼ば

れる一群の関心事を取り扱う。これらは，次のことを可能にするものである。

− 支援及び教育訓練の最適化

− 作業生産性及び作業品質の向上

− 人についての作業環境の改善

− システムの利用拒絶の機会の減少

名称：ユーザビリティプロセスビュー

目的：ユーザビリティプロセスビューの目的は，最適化支援及び教育，作業生産性及び作業品質の向上，

人についての作業環境の改善及びシステムの利用者による拒絶の機会の減少を可能にするために，利害関

係者の関心事及びニーズへの配慮を確実にするためである。

利用性プロセスビューの実施に成功すると次のような状態になる。

a) システムは，利用者のニーズを満たし，人間能力及びスキルの限界を考慮する。

b) 人間要因及び人間工学的な知識及び手法は，システム設計に組み込まれている。

c) 人間中心設計活動が識別され，行われる。

d) システム設計は，人間の健康，安全及び性能に対する使用上の悪影響に配慮している。

e) システムは，利用者の効果度，効率及び満足度を向上させている。

注記利用者の参画が人間中心設計の原則であるが，その成果は，望まれる特性が直接測定できず，

測定可能な他の製品又はプロセス特性に基づいて議論され，推断されるかもしれないことを許

容する。

プロセス，アクティビティ及びタスク

このプロセスビューは，この規格の次のプロセス，アクティビティ及びタスクを使用して実施できる。

1) プロジェクトポートフォリオ管理プロセス（6.2.3），特にプロジェクトの開始アクティビティ（6.2.3.3.1）

は，人間中心のアプローチを支持して，市場，概念，開発及び支援を取り扱う組織の部分における利

用者の問題に焦点を当てることを確立し，維持することを提供する。

2) インフラストラクチャ管理プロセス（6.2.2）は，人間中心の設計活動をシステムライフサイクルプロ

セス全体及び組織に当てはめる方法についての仕様を提供する。

3) プロジェクト計画プロセス（6.3.1）は，人間中心の方法及び手法の選択，利用者及び他の利害関係者

の参加の計画作成，並びに人間中心の設計活動の計画作成を提供する。

102

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

4) プロジェクトアセスメント及び制御プロセス（6.3.2）は，要求事項の達成の度合いを監視し，その結

果を利害関係者及び管理者に伝達し，設計チームの中に人間中心のアプローチを確実にすることを提

供する。関連するタスクは6.3.2.3.3.1及び6.3.2.3.3.2を含んでいる。

5) 利害関係者要求事項定義プロセス（6.4.1）は，次のことを考慮して，使用のコンテキストの識別及び

文書化並びに利用者とシステムとの間の相互作用の識別及び文書化を提供する。

− 人間の能力及びスキルの限界

− 健康，安全性，セキュリティ，環境，教育訓練，支援，並びにシステムの使用が人間の健康及び安

全性に及ぼす可能性がある悪影響に対処する他の利害関係者の要求事項及び機能の仕様書

注記可能な場合，適用可能な規格，例えば，JIS Z 8530，ISO 9241-11及びISO 9241並びに受

け入れられた専門的実践が使用される。

6) システム要求事項分析プロセス（6.4.2）は，使用のコンテキストの仕様及び評価並びにユーザビリテ

ィ及び人間中心設計の要求事項を提供する。

7) システム方式設計プロセス（6.4.3）は，ユーザビリティ及び人間工学的な要求事項に目標を置いた設

計基準の取り込みを提供する。

8) システム結合プロセス（6.4.5）は，結合の計画作成を提供する。それには，利用者教育訓練の配慮及

びユーザビリティの目標の達成及び人間工学的な要求事項に従っていることが検証され，記録される

という保証を含んでいる。

9) 情報管理プロセス（6.3.6）は，全体として，達成の度合いの文書化及び伝達のための作成物の仕様，

開発及び保守を提供する。ユーザビリティについては，ISO/IEC 25062及びISO/IEC 25000シリーズ

の関連する今後発行される規格に詳細が含まれる。

10) 測定プロセス（6.3.7）は，全体として，望まれる特性に測定量を関連付けるアプローチの定義を提供

する。ソフトウェアに対しては，これらは，ISO/IEC 25020に詳述されている。

11) ソフトウェア要求事項分析プロセス（7.1.2）は，ユーザビリティ及びソフトウェアの人間工学的な要

求事項の仕様を規定する。関連するタスクは，7.1.2.3.1.1 f)及び注記3である。

12) ソフトウェア運用プロセス（6.4.9）は，システムの使用を規定する。ユーザビリティの要求事項が適

切に達成されたことを保証することには，システム運用の監視を含む。関連するタスクは，6.4.9.3.3.1

の注記2，6.4.9.3.4.1及び6.4.9.3.5.1を含む。

13) ソフトウェア保守プロセス（6.4.10）は，ユーザビリティの特性を含め，システムの能力を保つもので，

全体として使用できる。

103

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

附属書F

（参考）

プロセス記述の例

次のプロセスの例は，この規格の読者によっては大いに有用であると考えられるので，この附属書Fに

含まれている。そのような利用者の組織のプロセスの文書にこれらの例を組み入れてもよい。

F.1

組織の調整プロセス

F.1.1

目的

組織の調整プロセスは，提供されたソフトウェア製品及びソフトウェアサービスに対して，組織によっ

て必要とされるソフトウェアプロセスをその事業目標と矛盾がないようにすることを目的とする。

F.1.2

成果

組織の調整プロセスの実施に成功すると次の状態になる。

a) 組織の事業目標が識別されている。

b) 組織の事業目標を達成するために必要とされるソフトウェアプロセスの集合を含むプロセスの枠組み

が識別され，定義されている。

c) プロセスの定義，実施及び改善のための戦略が定義されている。

d) この戦略を可能にするために支援が提供されている。

e) 組織の使命，本質的価値，ビジョン，ゴール及び目標が全ての従業員に知らされている。

組織の中の個人個人は，効果的に働くことができるように，共通のビジョン，文化及び事業目標の理

解を共有している。

g) 組織の中の各自が事業目標の達成におけるその役割を理解しており，その役割を行うことができる。

F.2

組織管理プロセス

F.2.1

目的

組織管理プロセスは，ソフトウェア製品及びソフトウェアサービスを提供するために必要とされるプロ

セスの遂行の間に，その組織の事業目標と矛盾がない，ソフトウェア管理のプラクティスを確立し，遂行

することを目的とする。

注記組織の運用は，一般にソフトウェアプロセスの適用分野よりも一層広い適用分野をもつが，ソ

フトウェアプロセスは，事業コンテキストの中で実施され，かつ，効果的であるために，適切

な組織環境を要求する。

F.2.2

成果

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

a) 組織は，適切な管理インフラストラクチャに投資する。

b) 効果的な組織管理及びプロジェクト管理の実施を支援するためのベストプラクティスが識別されてい

る。

c) これらの管理のプラクティスに基づいた組織の事業目標の達成を評価する根拠が提供されている。

104

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

F.3

契約変更管理プロセス

F.3.1

目的

契約変更管理プロセスは，合意した契約の内容に影響がある変更依頼が提案されたときに，取得者及び

供給者の両者によって合意される新契約内容を作成することを目的とする。このプロセスは，供給者又は

取得者のいずれかによる変更依頼の提案で始まり，取消し又は変更依頼の全面的・部分的承認という，両

当事者に受入れ可能な結末で終わる。

F.3.2

成果

契約変更管理プロセスの実施に成功すると次の状態になる。

a) 契約の変更依頼は，明示的にかつ公式に提案されている。

b) 契約変更管理のため取得者及び供給者の両者の役割及び責任が確立されている。

c) プロジェクト計画，コスト，恩恵，品質及びスケジュールに契約の変更依頼が及ぼす影響が評価され

ている。

d) 取得者及び供給者の両者の合意及び満足を得るため，変更依頼に対して処置が取られている。

e) 各変更依頼の結果は，全ての影響される当事者に知らされている。

F.3.3

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

取得者及び供給者は，契約の変更管理プロセスに関して，適用可能な組織の方針及び手順に従って，次

のアクティビティを実行する。

F.3.3.1

プロセスの準備

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

F.3.3.1.1

取得者及び供給者は，契約の変更要求を協議する場の設置を両者間の契約書に定め，この協議

の場を開発作業の着手前に設置する。

F.3.3.1.2

取得者及び供給者は，契約の変更の管理手順を定義し，文書化する。

F.3.3.2

契約変更依頼

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

F.3.3.2.1

契約の中のベースラインとなっている項目の変更を依頼する場合，取得者又は供給者は，その

仕様，理由及び背景を文書化し，それを他方に説明する。契約の修正（modify）においては，供給者は，

プロジェクト計画，コスト，品質及びスケジュールへの影響について文書化し，取得者に説明する。

F.3.3.3

変更の影響の調査及び分析

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

F.3.3.3.1

取得者からの契約の変更依頼に対して，供給者は，プロジェクト計画，コスト，便益，品質及

びスケジュールへの影響について調査し，文書化し，取得者に説明する。説明に当たっては，供給者は根

拠を明らかにすることが望ましい。

F.3.3.4

協議の実施及び合意の形成

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

F.3.3.4.1

協議の場において，取得者及び供給者は，変更内容，理由及び背景と同様にプロジェクト計画，

コスト，便益，品質及びスケジュールへの影響も考慮することによって，最も適切な結論に達する。

F.3.3.4.2

取得者及び供給者は，特にコスト負担の取扱いに関わる協議に当たっては，必要に応じて，問

題を上層管理者に上げて，適切な合意形成・決着を図る。

F.3.3.5

契約の修正（modification）

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

106

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

附属書G
（参考）

この規格とIEEE Std 12207及び他のIEEE規格との関係

この規格と他のISO/IEC規格との関係は，この規格の本文に記載されている。この附属書Gの目的は，

他のIEEE規格との関係を記述することである。表G.1は，この規格のプロセスを一覧表示している。そ

れらのプロセスの多くに対して，この表は，プロセスを実現又は実行において役立つ可能性があるIEEE

規格を示唆している。いずれの場合にも，備考にその関係を記述している。特定のプロセスに対して規格

を一くく（括）りしているが，おおよそのことに過ぎない。IEEE規格の多くは，単一のプロセスより大

きな範囲をもっている。

表G.1−この規格とIEEE Std 12207及び他のIEEE規格との関係

分類

細分箇条

プロセス

関係のある

IEEE規格

備考

6.1
合意プロ
セス

6.1.1

取得プロセス

1062

この文書は，ソフトウェアの取得中に選択し，適
用することができる有用な一組の実践を推奨して
いる。

6.1.2

供給プロセス

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

6.2.1

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

1074

この規格は，ソフトウェアライフサイクルプロセ
スの定義の進め方を載せている。

6.2.2

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

1175
1462

IEEE Std 1175の現行及び計画中の部分は，生産的
なソフトウェアエンジニアリング環境にCASEツ
ールを結合することを記述している。IEEE Std
1462は，CASEツールの評価及び選択のための指
針を載せている。この部分は，ISO/IEC 14102に
よく似ている。

6.2.3

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

6.2.4

人的資源管理プロセス

6.2.5

品質管理プロセス

90003

この規格は，ISO 9001:2000をソフトウェアに適用
する場合，組織に対する手引となる。ISO/IEC
90003の採用である。

6.3
プロジェ
クトプロ
セス

6.3及びそ
の細分箇条

1490

この文書は，PMBOKの2000年版をIEEEが採用
したものである。

6.3.1

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

1058
(16326)
1228

IEEE Std 1058は，ソフトウェアプロジェクト管理
計画の様式及び内容を記載している。ISO/IEC
16326及びIEEE Std 16326によって置き換えるこ
とを期待している。IEEE Std 1228は，安全性につ
いて重大なシステムの開発，調達，保守及び廃止
についてソフトウェア側面に対する計画の内容に
ついて記載している。

6.3.2

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

6.3.3

意思決定管理プロセス

107

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

表G.1−この規格とIEEE Std 12207及び他のIEEE規格との関係（続き）

分類

細分箇条

プロセス

関係のある

IEEE規格

備考

6.3
プロジェ
クトプロ
セス
（続き）

6.3.4

リスク管理プロセス

1540
(16085)

IEEE Std 1540は，ソフトウェアリスクを管理する
ためのプロセスを記載している。これは，システ
ムとソフトウェアのレベルにおけるリスクを取り
扱っているISO/IEC 16085及び IEEE Std 16085に
よって置き換えられることが期待されている。

6.3.5

構成管理プロセス

6.3.6

情報管理プロセス

6.3.7

測定プロセス

982.1
1045
1061
14143.1

IEEE Std 982.1は，ソフトウェア製品の信頼性を
予測し，評価するための測定量の集合を記載して
いる。IEEE Std 1045は，ソフトウェアの生産性の
測定量について矛盾のない専門用語を記載してい
る。IEEE Std 1061は，ライフサイクルにわたって，
品質要求事項を確立するため，かつ，対応する測
定量を識別し，実装し，妥当性を確認するための
方法論を記載している。IEEE Std 14143.1は，集
合的に機能規模（FP）として知られている測定量
の基本的な概念を記載している。

6.4
テクニカ
ルプロセ
ス

6.4.1

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

1362

ここでは，利用者ビューポイントから提供された
システムの特性を記述している運用の概念の文書
についての様式及び内容の助言を記載している。

6.4.2

システム要求事項分析
プロセス

1233
1320.1
1320.2

IEEE Std 1233は，システム要件の仕様の作成並び
に要求事項の特性及び品質について指針を提供す
る。IEEE Std 1320.1及び1320.2は，要求事項の表
現を含めて，概念のモデル化に使用することがで
きるIDEF0及びIDEF1X97という二つの言語を定
義している。

6.4.3

システム方式設計プロ
セス

1471
(42010)

IEEE Std 1471は，ソフトウェア中心システムの方
式記述のための概念枠組み及び内容を提言してい
る。ISO/IEC規格及びIEEE Std 42010の改正によ
って置き換えられることが予想されている。

6.4.4

実装プロセス

6.4.5

システム結合プロセス

6.4.6

システム適格性確認テ
ストプロセス

6.4.7

ソフトウェア導入プロ
セス

6.4.8

ソフトウェア受入れ支
援プロセス

6.4.9

ソフトウェア運用プロ
セス

6.4.10

ソフトウェア保守プロ
セス

14764

この規格は，ISO/IEC 14764と同一で，この規格
のソフトウェア保守プロセスを実施するための指
針を記載している。

6.4.11

ソフトウェア廃棄プロ
セス

108

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

表G.1−この規格とIEEE Std 12207及び他のIEEE規格との関係（続き）

分類

細分箇条

プロセス

関係のある

IEEE規格

備考

7.1
ソフトウ
ェア実装
プロセス

7.1.1

ソフトウェア実装プロ
セス

7.1.2

ソフトウェア要求事項
分析プロセス

830

ここでは，ソフトウェア要求事項の仕様書の内容
及び特性を推奨している。

7.1.3

ソフトウェア方式設計
プロセス

1471
(42010)

IEEE Std 1471は，ソフトウェア中心システムの方
式記述のための概念枠組み及び内容を推奨してい
る。ISO/IEC規格及びIEEE Std 42010の改正によ
って置き換えられることが予想されている。

7.1.4

ソフトウェア詳細設計
プロセス

1016

ここでは，ソフトウェア設計記述の内容及び組織
を推奨している。

7.1.5

ソフトウェア構築プロ
セス

1008

ここでは，ソフトウェアユニットテストへの進め
方を記載している。

7.1.6

ソフトウェア結合プロ
セス

829

この規格は，ソフトウェア結合を計画し，実行し，
報告するための資料の基本セットの様式及び内容
を記載している。

7.1.7

ソフトウェア適格性確
認テストプロセス

829

この規格は，ソフトウェアテストを計画し，実行
し，報告するための資料の基本セットの様式及び
内容を記載している。

7.2
ソフトウ
ェア支援
プロセス

7.2.1

ソフトウェア文書化管
理プロセス

1063
12207.1
(15289)

IEEE Std 1063は，利用者用文書の構造，内容及び
様式に対する要求事項を記載している。IEEE Std
12207.1は，この規格のライフサイクルプロセスの
実行から得られたデータを記録するための指針を
提供している。ISO/IEC 15289のIEEE採用によっ
て置き換えられることが期待されている。

7.2.2

ソフトウェア構成管理
プロセス

828

この規格は，特定の計画活動のための要求事項と
ともにソフトウェア構成管理計画の内容を指定し
ている。

7.2.3

ソフトウェア品質保証
プロセス

730
1061
1465
(25051)

IEEE Std 730は，ソフトウェア品質保証計画の様
式及び内容を指定している。IEEE Std 1061は，ラ
イフサイクルにわたって，品質要求事項を確立す
るため，かつ，対応する測定量を識別し，実装し，
妥当性を確認するための方法論を記載している。
IEEE Std 1465は，特にパッケージソフトウェアに
適した品質要求事項を記載している。ISO/IEC
25051のIEEE採用によって置き換えられること
が予想されている。

7.2.4

ソフトウェア検証プロ
セス

1012

この規格は，ソフトウェア検証アクティビティ及
びソフトウェア妥当性確認アクティビティを記載
している。

7.2.5

ソフトウェア妥当性確
認プロセス

1012

この規格は，ソフトウェア検証アクティビティ及
びソフトウェア妥当性確認アクティビティを記載
している。

7.2.6

ソフトウェアレビュー
プロセス

1028

この規格は，ソフトウェアレビューの五つの形式
及びそれの実行の手順を記載している。

7.2.7

ソフトウェア監査プロ
セス

1028

この規格は，ソフトウェアレビューの五つの形式
及びそれの実行の手順を記載している。

109

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

表G.1−この規格とIEEE Std 12207及び他のIEEE規格との関係（続き）

分類

細分箇条

プロセス

関係のある

IEEE規格

備考

7.2
ソフトウ
ェア支援
プロセス
（続き）

7.2.8

ソフトウェア問題解決
プロセス

1044

この規格は，ソフトウェア及びその文書に発見さ
れる不具合の分類に対する統一的アプローチを記
載している。

7.3
ソフトウ
ェア再利
用プロセ
ス

7.3及びそ
の細分箇条

1420.1
1517

IEEE Std 1420.1及びその補足は，資産を交換する
ためにソフトウェア再利用ライブラリが交換でき
ることが望ましい情報を記載している。IEEE Std
1517は，体系付けられたソフトウェア再利用に対
してライフサイクルプロセスを記載している。

7.3.1

ドメイン（領域）エン
ジニアリングプロセス

7.3.2

再利用資産管理プロセ
ス

7.3.3

再利用施策管理プロセ
ス

IEEE規格の規格名称を，次に記載する。

IEEE Std 730™-2002

IEEE Standard for Software Quality Assurance Plans

IEEE Std 828™-2005

IEEE Standard for Software Configuration Management Plans

IEEE Std 829™-1998

IEEE Standard for Software Test Documentation

IEEE Std 830™-1998

IEEE Recommended Practice for Software Requirements Specifications

IEEE Std 982.1™-1988

IEEE Standard Dictionary of Measures to Produce Reliable Software

IEEE Std 1008™-1987 (R2003)

IEEE Standard for Software Unit Testing

IEEE Std 1012™-2004

IEEE Standard for Software Verification and Validation

IEEE Std 1016™-1998

IEEE Recommended Practice for Software Design Descriptions

IEEE Std 1028™-1997 (R2002)

IEEE Standard for Software Reviews

IEEE Std 1044™-1993 (R2002)

IEEE Standard Classification for Software Anomalies

IEEE Std 1045™-1992 (R2002)

IEEE Standard for Software Productivity Metrics

110

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

IEEE Std 1058™-1998

IEEE Standard for Software Project Management Plans

IEEE Std 1061™-1998 (R2004)

IEEE Standard for a Software Quality Metrics Methodology

IEEE Std 1062™-1998 (R2002)

IEEE Recommended Practice for Software Acquisition

IEEE Std 1063™-2001

IEEE Standard for Software User Documentation

IEEE Std 1074™-1997

IEEE Standard for Developing Software Life Cycle Processes

IEEE Std 1175.1™-2002

IEEE Guide for CASE Tool Interconnections−Classification and Description

IEEE Std 1228™-1994 (R2002)

IEEE Standard for Software Safety Plans

IEEE Std 1233™，1998 Edition (R2002)

IEEE Guide for Developing System Requirements Specifications

IEEE Std 1320.1™-1998 (R2004)

IEEE Standard for Functional Modeling Language−Syntax and Semantics for IDEF0

IEEE Std 1320.2™-1998 (R2004)

IEEE Standard for Conceptual Modeling Language−Syntax and Semantics for IDEF1X 97 (IDEF object)

IEEE Std 1362™-1998

IEEE Guide for Information Technology−System Definition−Concept of Operations (ConOps) Document

IEEE Std 1420.1™-1995 (R2002)

IEEE Standard for Information Technology−Software Reuse−Data Model for Reuse Library Interoperability: Basic

Interoperability Data Model (BIDM)

IEEE Std 1420.1a™-1996 (R2002)

Supplement to IEEE Standard for Information Technology−Software Reuse−Data Model for Reuse Library

Interoperability: Asset Certification Framework

IEEE Std 1420.1b™-1999 (R2002)

IEEE Trial-Use Supplement to IEEE Standard for Information Technology−Software Reuse−Data Model for

Reuse Library Interoperability: Intellectual property Rights Framework

IEEE Std 1462™-1998 (R2004)

IEEE Standard: Adoption of International Standard ISO/IEC 14102:1995，Information Technology−Guideline for

the Evaluation and Selection of CASE tools

IEEE Std 1465™-1998 (R2004)

IEEE Standard: Adoption of International Standard ISO/IEC 12119:1994(E)，Information Technology−Software

Packages−Quality Requirements and Testing

IEEE Std 1471™-2000

IEEE Recommended Practice for Architectural Description of Software Intensive Systems

111

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

IEEE Std 1490™-2003

IEEE Guide: Adoption of PMI Standard, A Guide to the Project Management Body of Knowledge (PMBOK®

Guide)

IEEE Std 1517™-1999 (R2004)

IEEE Standard for Information Technology−Software Life Cycle Processes−Reuse Processes

IEEE Std 1540™-2001

IEEE Standard for Software Life Cycle Processes−Risk Management

IEEE/EIA 12207.1™-1996

Industry Implementation of International Standard ISO/IEC 12207:1995，Standard for Information Technology−

Software Life Cycle Processes−Life Cycle Data

IEEE Std 14143.1™-2000

IEEE Adoption of ISO/IEC 14143-1:1998, Information Technology−Software Measurement−Functional Size

Measurement−Part 1: Definition of Concepts

IEEE Std 14764™-2006

Software Engineering−Software Life Cycle Processes−Software Maintenance

IEEE 90003-2008

Software Engineering−Guidelines for the Application of ISO 9001:2000 Computer Software

112

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

附属書H
（参考）
参考文献

[1]

IEEE Std 1517-1999，IEEE Standard for Information Technology−Software Life Cycle Processes−Reuse

Processes

[2]

IEEE/EIA 12207.0-1996，Industry Implementation of International Standard ISO/IEC 12207:1995,

Standard for Information Technology−Software Life Cycle Processes

[3]

JIS Q 9000:2006 品質マネジメントシステム−基本及び用語

注記対応国際規格：ISO 9000:2005，Quality management systems−Fundamentals and vocabulary

（IDT）

[4]

ISO 9001:2000，Quality management systems−Requirements

[5]

ISO 9004:2000，Quality management systems−Guidance for performance improvement

[6]

ISO 10007:2003，Quality management systems−Guidelines for configuration management

[7]

JIS Z 8530:2000 人間工学−インタラクティブシステムの人間中心設計プロセス

注記対応国際規格：ISO 13407:1999，Human-centred design processes for interactive systems（IDT）

[8]

JIS X 0129-1:2003 ソフトウェア製品の品質−第1部：品質モデル

注記対応国際規格：ISO/IEC 9126-1:2001，Software engineering−Product quality−Part 1: Quality

model（IDT）

[9]

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）

[10] 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）

[11] 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）

[12] JIS Z 8521:1999 人間工学−視覚表示装置を用いるオフィス作業−使用性についての手引

注記対応国際規格：ISO 9241-11:1998，Ergonomic requirements for office work with visual display

terminals (VDTs)−Part 11: Guidance on usability（IDT）

[13] ISO/IEC TR 9294:2005，Information technology−Guidelines for the management of software

documentation

[14] JIS X 0161:2008 ソフトウェア技術−ソフトウェアライフサイクルプロセス−保守

注記対応国際規格：ISO/IEC 14764:2006，Software Engineering−Software Life Cycle Processes−

Maintenance（IDT）

[15] ISO/IEC TR 15271:1998，Information technology−Guide for ISO/IEC 12207 (Software Life Cycle

Processes)

[16] JIS X 0170:2004 システムライフサイクルプロセス

113

X 0160：2012 (ISO/IEC 12207：2008)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

注記対応国際規格：ISO/IEC 15288:2002，Systems engineering−System life cycle processes（IDT）

[17] ISO/IEC 15288:2008，Systems and software engineering−System life cycle processes

[18] ISO/IEC 15289:2006，Systems and software engineering−Content of systems and software life cycle

process information products (Documentation)

[19] ISO/IEC 15504 (all parts)，Information technology−Process assessment

注記この国際規格の第1部〜第4部に対応する日本工業規格：JIS X 0145-1〜-4（IDT），情報技

術−プロセスアセスメント

[20] JIS X 0141:2009 システム及びソフトウェア技術−測定プロセス

注記対応国際規格：ISO/IEC 15939:2007，Systems and software engineering−Measurement process

（IDT）

[21] JIS X 0162:2008 システム及びソフトウェア技術−ライフサイクルプロセス−リスク管理

注記対応国際規格：ISO/IEC 16085:2006，Systems and software engineering−Life cycle processes

−Risk management（IDT）

[22] ISO/IEC 18019:2004，Software and system engineering−Guidelines for the design and preparation of user

documentation for application software

[23] ISO/PAS 18152:2003，Ergonomics of human-system interaction−Specification for the process assessment

of human-system issues

[24] ISO/TR 18529:2000，Ergonomics−Ergonomics of human-system interaction−Human-centred lifecycle

process descriptions

[25] ISO/IEC TR 20000:2005 (multi-part)，Information technology−Service Management

[26] ISO/IEC 24774:2007，Systems and software engineering−Life cycle management−Guidelines for process

description

[27] JIS X 25000:2010 ソフトウェア製品の品質要求及び評価（SQuaRE）−SQuaREの指針

注記対応国際規格：ISO/IEC 25000:2005，Software Engineering−Software product Quality

Requirements and Evaluation (SQuaRE)−Guide to SQuaRE（IDT）

[28] ISO/IEC 25030:2007，Software engineering−Software product Quality Requirements and Evaluation

(SQuaRE)−Quality requirements

[29] ISO/IEC 25062，Software engineering−Software product Quality Requirements and Evaluation (SQuaRE)

−Common Industry Format (CIF) for usability test reports

[30] ISO/IEC 90003:2004，Software engineering−Guidelines for the application of ISO 9001:2000 to computer

software