X 0161：2008 (ISO/IEC 14764：2006)
（1）
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
目 次
ページ
序文 ··································································································································· 1
1 概要······························································································································· 2
1.1 適用範囲 ······················································································································ 2
1.2 目的 ···························································································································· 2
1.3 適用分野 ······················································································································ 2
1.4 制限 ···························································································································· 3
1.5 適合性 ························································································································· 3
2 引用規格························································································································· 3
3 用語及び定義 ··················································································································· 3
4 規格の適用 ······················································································································ 5
4.1 保守プロセス ················································································································ 5
4.2 規格の構成 ··················································································································· 5
5 保守プロセス ··················································································································· 6
5.1 プロセス実装 ················································································································ 7
5.2 問題分析及び修正の分析 ································································································· 8
5.3 修正の実施 ·················································································································· 12
5.4 保守レビュー及び受入れ ································································································ 13
5.5 移行 ··························································································································· 15
5.6 ソフトウェア廃棄 ········································································································· 18
6 実施時の考慮事項 ············································································································ 21
6.1 はじめに ····················································································································· 21
6.2 保守の型 ····················································································································· 21
6.3 保守の段取り ··············································································································· 22
6.4 保守ツール ·················································································································· 23
6.5 ソフトウェア保守の測定 ································································································ 23
6.6 プロセスの文書化 ········································································································· 23
6.7 開発への早期参加 ········································································································· 23
6.8 保守性 ························································································································ 24
6.9 ソフトウェアの引継ぎ ··································································································· 26
6.10 文書化 ······················································································································· 27
7 ソフトウェア保守の戦略 ··································································································· 27
7.1 はじめに ····················································································································· 27
7.2 保守概念 ····················································································································· 27
7.3 保守計画立案 ··············································································································· 29
7.4 資源分析 ····················································································································· 32
X 0161：2008 (ISO/IEC 14764：2006) 目次
（2）
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
ページ
附属書A（参考）JIS X 0161と，JIS X 0160:1996及びJIS X 0160追補1との参照関係 ······················ 34
附属書B（参考）略語 ·········································································································· 35
附属書C（参考）参考文献 ···································································································· 36
X 0161：2008 (ISO/IEC 14764：2006)
（3）
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
まえがき
この規格は，工業標準化法に基づき，日本工業標準調査会の審議を経て，経済産業大臣が改正した日本
工業規格である。
これによって，JIS X 0161:2002は改正され，この規格に置き換えられた。
この規格は，著作権法で保護対象となっている著作物である。
この規格の一部が，特許権，出願公開後の特許出願，実用新案権又は出願公開後の実用新案登録出願に
抵触する可能性があることに注意を喚起する。経済産業大臣及び日本工業標準調査会は，このような特許
権，出願公開後の特許出願，実用新案権又は出願公開後の実用新案登録出願に係る確認について，責任は
もたない。
X 0161：2008 (ISO/IEC 14764：2006) 目次
（4）
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
白 紙
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
日本工業規格 JIS
X 0161：2008
(ISO/IEC 14764：2006)
ソフトウェア技術−
ソフトウェアライフサイクルプロセス−保守
Software Engineering-Software Life Cycle Processes-Maintenance
序文
この規格は，2006年に第2版として発行されたISO/IEC 14764を基に，技術的内容及び対応国際規格の
構成を変更することなく作成した日本工業規格である。
なお，この規格で点線の下線を施してある“注記”は，対応国際規格にはない事項である。
この規格は，ソフトウェア保守プロセスのための要求事項を明確にする。ソフトウェア保守は，JIS X
0160で規定されているように，ソフトウェア製品のライフサイクルにおける主プロセスの一つである。保
守プロセスは，保守者のアクティビティ及びタスクを含んでいる。この規格は，JIS X 0160関連規格の一
つであって保守プロセスの手引となる。この規格は，JIS X 0160に含まれる保守プロセスを詳しく定める
ものである。この規格における必す（須）条項は，JIS X 0160から原文のまま引用したものだけであり，
枠で示している。枠で示したJIS X 0160の“…する”(shall)文の後には，関連するJIS X 0160の箇条番号
が示されている。
保守は，ソフトウェアライフサイクルの財政的資源のほとんどの部分を消費するので，プロジェクトの
主要な考慮事項である。
ソフトウェアの運用時に，検証及び受入れにおいて検知されなかった問題が検知されるかもしれない。
それゆえ，保守活動は，これらの問題に対応するために必要となる。また，この保守活動は，顧客の新規
要求又は修正要求を満たすために必要となるソフトウェア改善に及んでいる。一般的には，ソフトウェア
保守は，ソフトウェア及びシステムの外部インタフェースに修正がなされる場合と同様に，システム構成
要素（例えば，オペレーティングシステム及びデータベース）の更新時に必要となる。ソフトウェア保守
は，ライフサイクル費用のかなりの部分を占めるかもしれない。
ソフトウェア保守者は，幾つかの特有のツール，手法及び技法を使用している。ソフトウェア保守プロ
セスのアクティビティ及びタスクを，どのように実現し，実施するかについては，合意及び組織に依存す
ることから，この規格では規定しない。ソフトウェア保守の要求事項は，ソフトウェア保守を実現するツ
ールとは無関係に成り立つ。
1.1では，この規格の適用範囲を定める。1.5では，適合性の情報を定める。箇条2では，引用規格につ
いて定める。箇条3では，用語及び定義を定める。箇条4では，この規格の適用について定める。箇条5
では，保守プロセスの詳細について定める。箇条6では，実施時の考慮事項について定める。箇条7では，
ソフトウェア保守の戦略について定める。附属書Aでは，この規格とJIS X 0160の各箇条との参照関係を
示す。附属書Bでは，この規格で使用する略語一覧を示す。附属書Cでは，参考文献を示す。
2
X 0161：2008 (ISO/IEC 14764：2006)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
1
概要
この規格は，JIS X 0160に規定した保守プロセスを更に詳細に定める。また，この規格は，様々なタイ
プの保守を定義している。この規格は，保守プロセスの計画，実行及び制御，レビュー及び評価，並びに
終了の要領を示す。この規格の適用範囲には，同一の保守資源を用いる複数のソフトウェア製品の保守も
含まれている。この規格における“保守”は，特に規定しない限り，ソフトウェア保守を意味している。
1.1
適用範囲
この規格は，ソフトウェア保守活動を管理し，実行するための繰り返しのプロセスを定める。この規格
は，ソフトウェア製品の規模，複雑度，完全性又は適用対象にかかわらず，使用される。この規格は，ソ
フトウェア保守の各局面を検討し，表現するためのプロセスモデルを使用している。設定された基準は，
ソフトウェア製品を存続させるためのソフトウェア保守活動の計画及び遂行と同様に，開発中のソフトウ
ェアに対する保守計画にも適用される。理想としては，保守計画はソフトウェア開発を計画している段階
で開始するのが望ましい。
この規格は，与えられたソフトウェア製品の保守範囲及び規模に対応して，はん（汎）用的及び特殊な
ソフトウェア保守計画が実行され，評価され，修整される枠組みを提供する。
この規格は，ソフトウェア保守に対して一貫した技術（ツール，技法及び手法）の適用を可能にするた
めの枠組み，正確な用語及びプロセスを定める。
この規格では，ソフトウェアの保守のための要領を定める。保守プロセス及びそのアクティビティの基
本は，JIS X 0160の定義を受け継いでいる。この規格は，ソフトウェア保守のアクティビティ及びタスク
を定義し，保守計画の要求事項を定める。この規格では，ソフトウェアの運用及び運用上の諸作業，例え
ば，ソフトウェアを操作する人たちによって通常行われるバックアップ，回復及びシステム管理は扱わな
い。
この規格は，主にソフトウェアの保守者を対象としているが，開発責任者及び品質保証責任者も対象と
している。また，保守計画の入力を担うソフトウェアを含むシステムの取得者及び利用者が利用してもよ
い。
注記 この規格の対応国際規格及びその対応の程度を表す記号を，次に示す。
ISO/IEC 14764: 2006，Software Engineering−Software Life Cycle Processes−Maintenance (IDT)
なお，対応の程度を表す記号(IDT)は，ISO/IEC Guide 21に基づき，一致していることを示す。
1.2
目的
この規格は，保守プロセスの管理（又は実施方法）の要領を定める。また，受入れ及び運用の期間にお
ける保守プロセスの始め方を明らかにする。この規格は，保守プロセスにおける次の事項にも重点を置い
ている。
− ソフトウェア製品の保守性
− 保守サービスモデルの必要性
− 保守の戦略及び計画の必要性
1.3
適用分野
この規格は，組織の内部又は外部で実行するかどうかにかかわらず，ソフトウェア製品又はサービスの
計画及び保守のための要領を示すことを意図している。ソフトウェアの運用への適用は，意図していない。
この規格は，取得者及び供給者のような二者間への適用を意図したものである。当該二者が，同じ組織
に属している場合でも等しく適用してよい。またこの規格は，自前で保守を行う当事者が自らを律するた
めに用いることも意図している（JIS X 0160を参照）。
3
X 0161：2008 (ISO/IEC 14764：2006)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
この規格は，“使い捨て”のソフトウェア製品又は“短期間使用”のソフトウェア製品への適用は，意図
していない。
この規格は，既製ソフトウェア製品の開発者が，製品を保守するに当たり己に課す義務を提示すること
を意図している。しかし，利用者によってカスタマイズされたソフトウェア製品及びエンドユーザアプリ
ケーションとして使用されている製品は，対象としない。保守は，計算機プログラム，コード，データ及
び文書に適用される。保守は，対象製品の開発時に作成したソフトウェアにも適用することを意図してい
る。これらのソフトウェアには，テストソフトウェア，テストデータベース，ソフトウェアテスト環境 (STE)，
ソフトウェアエンジニアリング環境 (SEE)などを含んでもよい。
この規格は，ライフサイクルモデル（例えば，段階的，ウォータフォール, 進化的）にかかわらず，す
べての保守作業で使用することを意図している。この規格は，ソフトウェア製品の大きさ，複雑さ，重要
さ又は用途によって制限されない。この規格は，ソフトウェア製品の保守性を改良するために，保守プロ
セスからの成果を，次の開発への入力として利用するための案内となるよう意図している。
1.4
制限
この規格は，ソフトウェア保守プロセスの枠組みを定めているが，そのプロセスに含まれるアクティビ
ティ及びタスクをどのように実現し，また実行するかの細部については指定していない。
この規格には，多くの（タスクステップの）一覧があるが，どの一覧も例を示すことを目的としたもの
であって，すべてを網羅しようとしたものでない。
1.5
適合性
この規格は，JIS X 0160の保守プロセス実行のための手引を提供する。この規格の手引の枠で示す部分
は，JIS X 0160と完全に整合している。この規格の枠で示すJIS X 0160の保守プロセス及び関連する修整
は規定である。
2
引用規格
次に掲げる規格は，この規格に引用されることによって，この規格の規定の一部を構成する。これらの
引用規格は，記載の年の版を適用し，その後の改正版（追補を含む。）には適用しない。
JIS X 0129-1: 2003 ソフトウェア製品の品質−第1部：品質モデル
注記 対応国際規格：ISO/IEC 9126-1: 2001，Software engineering−Product quality−Part 1: Quality
model (IDT)
JIS X 0141: 2004 ソフトウェア測定プロセス
注記 対応国際規格：ISO/IEC 15939: 2002，Software engineering−Software measurement process (IDT)
JIS X 0160:2007 ソフトウェアライフサイクルプロセス
注記1 対応国際規格：ISO/IEC 12207: 1995，Information technology−Software life cycle processes,
Amendment 1:2002及びAmendment 2:2004 (IDT)
注記2 JIS X 0160は，1996年にISO/IEC 12207: 1995を基づき第１版が発行された。その後，対応
国際規格がAmendmentを発行したのを受け，2007年に追補1が発行された。この規格では，
第１版又は追補1を区別して引用する場合，発行年又はʻ追補1ʼを付記して区別している。
3
用語及び定義
この規格で用いる主な用語及び定義は，次による。
3.1
4
X 0161：2008 (ISO/IEC 14764：2006)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
適応保守 (adaptive maintenance)
引渡し後，変化した又は変化している環境において，ソフトウェア製品を使用できるように保ち続ける
ために実施するソフトウェア製品の修正。
注記 適応保守は，必す（須）運用ソフトウェア製品の運用環境変化に順応するために必要な改良を
提供する。これらの変更は，環境の変化に歩調を合わせて実施する必要がある。例えば，オペ
レーティングシステムの更新が必要になったとき，新オペレーティングシステムに適応するた
めには，幾つかの変更が必要かもしれない。
3.2
是正保守 (corrective maintenance)
ソフトウェア製品の引渡し後に発見された問題を訂正するために行う受身の修正 (reactive modification)。
注記 この修正によって，要求事項を満たすようにソフトウェア製品を修復する。
3.3
緊急保守 (emergency maintenance)
是正保守実施までシステム運用を確保するための，計画外で一時的な修正。
注記 緊急保守は，是正保守の一部である。
3.4
保守性 (maintainability)
修正のしやすさに関するソフトウェア製品の能力。 修正には，環境における変化，要求事項・機能仕様
における変化に対するソフトウェアの是正，改善又は適応を含めてもよい（JIS X 0129-1を参照）。
3.5
改良保守 (maintenance enhancement)
新しい要求を満たすための既存のソフトウェア製品への修正。
注記 改良保守には，適応保守及び完全化保守の二つのタイプがある。改良保守は，ソフトウェアの
訂正ではない。
3.6
修正依頼 (Modification Request，MR)
保守対象となるソフトウェア製品への変更提案を特定するために使われる総称用語。
注記 修正依頼は，後で訂正と改良とに分類できる。さらに，是正保守，予防保守，適応保守又は完
全化保守に分けられる。修正依頼は，変更依頼ということもある。
図1−修正依頼
修正依頼
訂正
完全化
適応
予防
是正
改良
保守のタイプ
分類
5
X 0161：2008 (ISO/IEC 14764：2006)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
3.7
完全化保守 (perfective maintenance)
引渡し後のソフトウェア製品の潜在的な障害が，故障として現れる前に，検出し訂正するための修正。
注記 完全化保守は，利用者のための改良，プログラム文書の改善を提供し，ソフトウェアの性能強
化，保守性などのソフトウェア属性の改善に向けての記録を提供する。
3.8
予防保守 (preventive maintenance)
引渡し後のソフトウェア製品の潜在的な障害が運用障害になる前に発見し，是正を行うための修正。
3.9
問題報告 (Problem Report，PR)
ソフトウェア製品に発見された問題を特定し，記述するために使用する用語。
注記 問題報告は，障害を指摘するために直接提出されるか，又は，修正依頼と発見した障害との影
響分析で確定されるかのいずれかである。
3.10
ソフトウェア保守 (software maintenance)
ソフトウェアシステムへの費用対効果の高い効率的な支援の提供を要求するあらゆる活動。活動は，引
渡し後と同様に引渡し前にも実施される。
注記 引渡し前の活動としては，引渡し後の運用，支援性及び配送決定についての計画策定が挙げら
れる。引渡し後の活動には，ソフトウェア修正，訓練及びヘルプデスクの運営が挙げられる。
3.11
ソフトウェアの引継ぎ (software transition)
最初に開発を行った組織から，保守を行う組織にソフトウェア開発を受け渡すための，制御され，調整
された一連の活動。
4
規格の適用
ここでは，ソフトウェア製品の保守に必要な保守プロセスについて定める。
4.1
保守プロセス
ソフトウェアの“保守”は，ソフトウェアのライフサイクル (JIS X 0160)の中で実行される五つの主ラ
イフサイクルプロセス（取得プロセス，供給プロセス，開発プロセス，運用プロセス，保守プロセス）の
一つである。JIS X 0160の取得プロセス及び供給プロセスでは，合意又は契約によって，保守プロセスに
おけるプロセス実装アクティビティを始めてもよい。JIS X 0160の運用プロセスでは，修正依頼又は問題
報告の提出によって，保守プロセスを開始してもよい。保守プロセスは，JIS X 0160の開発プロセスを呼
び出す。JIS X 0160の文書化，構成管理 (CM)，品質保証，検証，妥当性確認，共同レビュー，監査及び
問題解決の各支援プロセスが，保守プロセスで使用される。
4.2
規格の構成
次の箇条では，保守者が対応すべき順に規定している。
箇条5では，保守プロセスを実装するのに必要であるタスク及びタスクステップを含む保守プロセスの
詳細を示す。箇条6では，実施のときの考慮事項，及び保守の計画を立てるときに考慮すべき事柄につい
て示す。箇条7では，包括的な計画情報について示す。
6
X 0161：2008 (ISO/IEC 14764：2006)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
5
保守プロセス
ここでは，ソフトウェア保守の主ライフサイクルプロセスのためのアクティビティ及びタスクを定める。
保守プロセスは，既存ソフトウェア製品の完全性を維持しつつ，修正を行うために必要なアクティビテ
ィ及びタスクを含む。これらのアクティビティ及びタスクは，保守者の責務である。この規格では，保守
アクティビティ及びタスクを実行するために何を行うかの例として，タスクステップを与える。保守者は，
ソフトウェア製品の開発に先立ち，保守プロセスが存在し，かつ，機能することを確実にしておくことが
望ましい。ソフトウェア製品を保守するという要求事項が存在する場合に，保守プロセスを開始すること
が望ましい。
プロセスが起動されたら直ちに，保守計画及び手続を策定し，かつ，保守のために特別に資源を割り当
てることが望ましい。ソフトウェア製品の引渡し後に，保守者は，修正依頼又は問題報告を受けて，コー
ド及び関連文書の修正を行う。ソフトウェア保守の全般的な目的は，既存製品の完全性を維持しつつ修正
することである。このプロセスは，ソフトウェア製品の使用開始から，新環境への移行，廃棄までを支援
する。プロセスは，ソフトウェア製品が最終的に廃棄されるときに終了する。
保守プロセスを構成するアクティビティは，次のとおりである。
a) プロセス実装
b) 問題分析及び修正の分析
c) 修正の実施
d) 保守レビュー及び受入れ
e) 移行
f)
廃棄
入力は，出力を作り出すための保守アクティビティによって，変換又は使用される。保守アクティビテ
ィが正しい出力を作り出すことを確実にするための手引を与えるものである。出力とは，保守アクティビ
ティで作られたデータ又は対象物である。支援では，保守アクティビティで使用するJIS X 0160の支援ラ
イフサイクルプロセスを明示する。
図2は，保守プロセスの全体像を表している。
図2−保守プロセス
プロセス実装 1
問題分析及び
修正の分析 2
保守レビュｰ及
び受入れ 4
修正の実施 3
廃棄 6
移行 5
7
X 0161：2008 (ISO/IEC 14764：2006)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
5.1
プロセス実装
プロセス実装中，保守者は，保守プロセス内で実行されるべき計画及び手続を確立する。保守計画（7.3.2
を参照）は，開発計画と並行して策定することが望ましい。保守者は，この活動中に，必要な組識上のイ
ンタフェースを確立することが望ましい。
5.1.1
入力
プロセス実装アクティビティの入力は，次を含むことが望ましい。
− 関連するベースライン
− システム文書（もしあれば）
− 修正依頼又は問題報告（もしあれば）
5.1.2
タスク
保守者は，保守プロセスを効果的に実現するため，保守を行うための戦略を策定し，文書化することが
望ましい。作業を達成するため，保守者は，次のタスクを実行するのがよい。
− 保守計画及び保守手続を策定する。
− 修正依頼及び問題報告手続を確立する。
− 構成管理を実施する。
− 構成管理計画を策定する（修正依頼・問題報告については，不要であるかもしれない。）。
5.1.2.1
保守計画及び保守手続
保守者は，保守プロセスのアクティビティ及びタスクを実行するための，計画及び手続を作成し，文書
化し，実行する（JIS X 0160の5.5.1.1を参照）。
保守計画では，システムを保守するために利用する戦略を文書化することが望ましい。同時に，保守手
続では，保守を実際に成し遂げる方法として，より詳細な対処方法を与えることが望ましい。効果的な保
守計画及び保守手続を作成するために，保守者は，次のタスクステップを実施することが望ましい。
a) 保守概念の作成をするときに取得者を援助する。
b) 保守の適用範囲の決定をするときに取得者を援助する。
c) 保守組織の代替案の分析をするときに取得者を援助する。
d) ソフトウェア製品の保守者の指名が明文化されることを確実にする。
e) 資源分析を行う。
f)
保守費用を見積る。
g) システムの保守性評価を実施する。
h) 移行要件を決定する。
i)
移行の節目を決定する。
j)
利用する保守プロセスを明確にする。
k) 業務手続形式で保守プロセスを文書化する。
5.1.2.2
修正依頼手続及び問題報告手続
保守者は，利用者からの問題報告及び修正依頼の受理，記録，追跡並びにそれらの状況を利用者に通知
するための手続を確立する（JIS X 0160の5.5.1.2を参照）。問題が生じる都度，それらを記録し，問題解
決プロセス（JIS X 0160の6.8を参照）に引き渡す。
保守者は，次のタスクステップを実施することが望ましい。
a) 修正依頼・問題報告の識別番号体系を作成する。
8
X 0161：2008 (ISO/IEC 14764：2006)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
b) 修正依頼・問題報告の分類分け及び優先付けの体系を作成する。
c) 傾向分析を決定する手続を作成する。
d) 運用者が修正依頼・問題報告を提出する手続を決定する。
e) 運用者又は利用者に対し，最初にフィードバックする方法を教える。
f)
運用者又は利用者に対し，当面の回避策を提供する方法を検討する。
g) データを，状況記録データベースに入力する方法を決定する。
h) 運用者又は利用者に対し，追跡結果のフィードバックとして何を提供するかを決定する。
5.1.2.3
構成管理
保守者は，現行システムの修正作業を管理するために，構成管理プロセス（JIS X 0160の6.2を参照）
を実施する（又は組織として構成管理プロセスとインタフェースをとる。）（JIS X 0160の5.5.1.3を参照）。
保守者は，JIS X 0160の構成管理プロセスを呼び出す必要がある。
5.1.3
制御
プロセス実装アクティビティの出力を制御するために，共同レビュー（JIS X 0160の6.6を参照）を行
うことが望ましい。
5.1.4
支援
プロセス実装アクティビティは，次のJIS X 0160の支援ライフサイクルプロセスを利用する。
− 文書化プロセス
− 構成管理プロセス
− 品質保証プロセス
− 共同レビュープロセス
5.1.5
出力
このアクティビティの出力は，次による。
− 保守計画
− 訓練計画
− 保守手続き
− プロジェクト管理計画
− 問題解決手続き
− 測定計画
− 保守マニュアル
− 利用者フィードバック計画
− 引継ぎ計画
− 保守性アセスメント
− 構成管理計画
すべての出力は，構成管理下に置かれることが望ましい。
5.2
問題分析及び修正の分析
これ及びこれに続くアクティビティは，ソフトウェアの引継ぎ後活性化され，かつ，修正のニーズが生
じるたびに繰り返し呼び出される。
保守者は，問題分析及び修正の分析アクティビティを通じて，次のことを行う。
− 修正依頼・問題報告を分析する。
9
X 0161：2008 (ISO/IEC 14764：2006)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
− 問題を再現又は検証する。
− 修正実施に関する選択肢を用意する。
− 修正依頼・問題報告，結果及び修正実施の選択肢を文書化する。
− 選択した修正選択肢の承認を得る。
問題分析及び修正の分析アクティビティの入力は，妥当性を確認された修正依頼又は問題報告，システ
ム文書又はプロジェクト文書，及び要求事項文書であることが望ましい。
5.2.1
入力
問題分析及び修正の分析アクティビティの入力は，次のものであることが望ましい。
− 修正依頼及び問題報告
− ベースライン
− ソフトウェアリポジトリ
− システム文書
システム文書は，次を含む。
− 構成状況の情報
− 機能要求事項
− インタフェース要求事項
− プロジェクト計画立案データ
− プロセス実装アクティビティからの出力
5.2.2
タスク
保守者は，システムを修正する前に組織，現行システム及び相互関係のあるシステムへ与える影響を明
らかにするため，MR/PR（修正依頼・問題報告）を分析することが望ましい。可能な解決策の勧告を作成
し文書化すること，及び希望する解決策を実施するための承認を得ることが望ましい。
5.2.2.1
修正依頼・問題報告の分析
保守者は，組織，現行システム及び関連するシステムへ与える影響について，次の観点から問題報告又
は修正依頼の内容を分析する（JIS X 0160の5.5.2.1を参照）。
a) 種類：例えば，是正，改善，予防又は新環境への適応。
b) 範囲：例えば，修正量，修正費用，修正時間。
c) 重大性：例えば，性能，安全性又はセキュリティへの影響。
保守者は，要求された修正依頼・問題報告が実施可能であることを確実にするため，次のタスクステッ
プを実施することが望ましい。
a) 提案された修正を実施するために，保守者が適切に配置されていることを判定する。
b) 提案された修正を実施するために，適切な予算が組まれていることを判定する。
c) 十分な資源が利用可能であり，かつ，この修正が継続中又は計画されたプロジェクトに影響があるか
どうかを判定する（問題報告には，必要ないかもしれない。）。
d) 検討すべき運用上の問題点を決定する。例えば，システムインタフェース要求事項への予想される修
正，システムの予想有効寿命，運用上の優先順位，安全性，セキュリティ，セキュリティの影響，こ
れらが実行されなかった場合どうなるか（問題報告のためには，必要ないとしてもよい。）。
e) 取り扱う優先順位の判定を行う。
f)
保守のタイプを分類する。
10
X 0161：2008 (ISO/IEC 14764：2006)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
g) 現在及び将来の利用者への影響度を判定する。
h) 安全性及びセキュリティの予測できない影響を判定する（問題報告のためには，必要ではないとして
もよい。）。
i)
波及効果を特定する。
j)
修正によって生じる可能性のあるソフトウェア又はハードウェアの制約を評価する。
k) 短期的及び長期的な費用を判定する（問題報告のためには，必要ではないとしてもよい。）。
l)
修正することによって得られる利点を判定する。
m) 現行スケジュールへの影響を判定する。
n) 影響分析の結果による何らかのプロジェクト又はソフトウェアのリスクを文書化する。
o) 要求されるテスト及び評価の水準を判定する。
p) 修正を実施するための見積もられた管理費用を判定する（問題報告のためには，必要ではないとして
もよい。）。
q) 開発した成果物を構成管理の管理下に置く。
5.2.2.2
検証
保守者は，問題を再現又は検証する（JIS X 0160の5.5.2.2を参照）。
保守者は，要求された問題報告が有効であることを確実にするため，次のタスクステップを実施するこ
とで，問題を再現又は検証することが望ましい。
a) 問題を検証するためのテスト戦略を作成する。
b) 構成管理から影響を受けるソフトウェアの版を入手する。
c) 影響を受ける版を導入する。
d) なるべくならば，影響を受けるデータの複製を利用し，問題検証のためテストを行う。
e) テスト結果を文書化する。
もし，何らかの理由（例えば，データの機密性によって）で問題が再現できなければ，組織規定，方針，
文書化などを検査することが望ましい。
注記 検証作業は，適応保守及び完全化保守には要求されていない。
5.2.2.3
選択肢
保守者は，分析に基づき修正実施にかかわる選択肢を用意する（JIS X 0160の5.5.2.3を参照）。
保守者は，次のタスクステップを実施することが望ましい。
a) 修正依頼及び問題報告に作業優先順位を割り当てる。
b) 問題に対する回避策があるかどうかを判定する。もし，あるならば，運用者又は利用者に回避策を提
供する（このタスクステップは，適応保守及び完全化保守には必要ない。）。
c) 修正に必要な確かな要求事項を定義する。
d) 修正の量及び規模を見積る。
e) 修正を実施するための異なる選択肢を作成する。
f)
これらの選択肢がシステムハードウェア及び利用者に与える影響を判定する。
g) 特定した選択肢のそれぞれのリスク分析を実施する。
h) 提案された選択肢の採用又は却下を記録する。
i)
修正を実施するための合意した計画を作成する。
11
X 0161：2008 (ISO/IEC 14764：2006)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
5.2.2.4
文書化
保守者は，問題・修正依頼，分析結果及び修正実施の選択肢を文書化する（JIS X 0160の5.5.2.4を参照）。
次のタスクステップを実施することが望ましい。
a) すべての適切な分析及びプロジェクト文書の更新が行われていることを検証する。もし，存在しない
ならば，文書を作成する。
b) 提案されたテスト戦略及びスケジュールの正確さをレビューする。
c) 資源見積りの正確さをレビューする。
d) 状況記録データベースを更新する。
e) 修正依頼・問題報告を，承認するか又は否認するかを示す決定勧告の検討を含める。
5.2.2.5
承認
システムを修正する前に，保守者は，契約の指定に従って，選択した修正案の承認を得る（JIS X 0160
の5.5.2.5を参照）。
保守を開始するための合意書が利用できない状況で保守を実施する場合にも，承認を得ることが望まし
い。保守者は，次のタスクステップを実施することで，承認を得てもよい。
a) 適切な構成管理グループによる承認を得るため，分析結果を提供する。
b) 修正に関する討議に参加する。
c) 承認に基づいて，修正依頼の状況を更新する。
d) 承認に基づいて，要求が改良（改善）されたら，要求事項を更新する。
5.2.3
制御
制御は，共同レビュー（JIS X 0160の6.6を参照）を通して維持される。
このアクティビティの最後に，リスク分析を実施することが望ましい。保守プロセスの問題分析及び修
正の分析アクティビティの出力を用いて，暫定資源見積りを変更することが望ましく，修正実施アクティ
ビティに進むかどうかを利用者（顧客）を含めて決定する。
5.2.4
支援
問題分析及び修正の分析アクティビティは，次のJIS X 0160の支援ライフサイクルプロセスを使用する。
− 文書化プロセス
− 品質保証プロセス
− 問題解決プロセス
5.2.5
出力
問題分析及び修正の分析アクティビティの出力は，次による。
− 影響分析
− 勧告された選択肢
− 承認された修正内容
− 更新された文書
影響分析には，次を含むことが望ましい。
− 問題又は新しい要求事項の報告書
− 問題又は要求事項の評価
− 要求された保守のタイプの分類
− 初期の優先順位
12
X 0161：2008 (ISO/IEC 14764：2006)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
− 検証データ（是正修正の場合）
− 現行システムを修正するために必要な資源の初期見積り
更新された文書には，次を含むことが望ましい。
− テスト戦略
− テスト計画，テスト手順及びテスト報告を含むテスト文書の更新
− ソフトウェア文書
− 更新済みの要求事項
5.3
修正の実施
保守者は，修正の実施アクティビティを通じて，ソフトウェア製品の修正の作成及びテストを行う。
5.3.1
入力
修正の実施アクティビティの入力は，次による。
− ベースライン
− 承認された修正依頼・問題報告
− 承認された修正文書
ベースラインは，次を含むことが望ましい。
− システム方式の定義
− 修正依頼の記録
− ソースコード
承認された修正要求文書は，次を含むことが望ましい。
− 影響分析報告
− 問題分析及び修正の分析アクティビティからの出力
5.3.2
タスク
保守者は，分析を行い，修正を成し遂げるためにJIS X 0160の開発プロセスを開始する。
5.3.2.1
分析
保守者は，分析を行い，修正を必要とする文書，ソフトウェアユニット及び版を決定する。決定結果は，
文書化する（JIS X 0160の5.5.3.1を参照）。
さらに，分析された結果は，ソフトウェア文書として文書化されることが望ましい。この作業は，次の
タスクステップを含む。
a) 現行システムの中で修正される要素を特定する。
b) 修正によって影響を受けるインタフェース要素を特定する。
c) 更新対象となる文書を特定する。
d) ソフトウェア文書を更新する。
13
X 0161：2008 (ISO/IEC 14764：2006)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
5.3.2.2
開発プロセス
保守者は，修正を行うために開発プロセス（JIS X 0160の5.3を参照）の実施に移る。開発プロセスに
対する要求事項（JIS X 0160の5.5.3.2を参照）に，次を追加する。
a) システムの修正部分及び非修正部分（ソフトウェアユニット，コンポーネント，及び構成品目）をテ
ストし評価するための基準を定義し，文書化する［JIS X 0160の5.5.3.2 a)を参照］。
b) 新しい要求事項及び修正のあった要求事項は，完全に，かつ，正しく実現しなければならない。当初
の修正が入らない要求事項に対しては，影響を与えてはならない。テスト結果は，文書化する［JIS X
0160の5.5.3.2 b)を参照］。
JIS X 0160の開発プロセスのアクティビティは，修正作業のニーズを満たすように修整することが望ま
しい。
JIS X 0160追補1の開発プロセスの要求引出しサブプロセスは，保守プロセスの“プロセス実装”及び
“問題分析及び修正の分析”アクティビティによって満足される。
5.3.3
制御
修正実施の制御は，共同レビューを含むことが望ましい（JIS X 0160の6.6を参照）。
5.3.4
支援
修正の実施アクティビティは，次のJIS X 0160の支援ライフサイクルプロセスを使用する。
− 文書化プロセス
− 品質保証プロセス
− 共同レビュープロセス
5.3.5
出力
修正の実施アクティビティの出力は，次を含むことが望ましい。
− 更新されたテスト計画及びテスト手順
− 更新された文書
− 修正されたソースコード
− テスト報告
− 測定値
更新された文書は，次を含むことが望ましい。
− 更新された修正記録
− 詳細な分析報告
− 更新された要求事項
− 更新されたテスト計画，テスト手順及びテスト報告
− 更新された教材
5.4
保守レビュー及び受入れ
このアクティビティでは，システムの修正が正しく，かつ，正しい方法を用いて承認された標準に従い，
完了していることを確実にする。
5.4.1
入力
保守レビュー及び受入れアクティビティの入力は，次による。
− 修正されたソフトウェア
− 修正テストの結果
14
X 0161：2008 (ISO/IEC 14764：2006)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
5.4.2
タスク
レビューは，修正が正しく，かつ，修正が問題なく完了していることの承認が得られることを確実にす
るために行われる。
5.4.2.1
レビュー
保守者は，修正を承認する権限をもつ組織と共同でレビューを行い，修正されたシステムの完全性を確
認する（JIS X 0160の5.5.4.1を参照）。
次のタスクステップを実施することが望ましい。
a) 要求事項から設計へ，コードへと，修正依頼・問題報告を追跡する。
b) コードのテスト容易性を検証する。
c) コーディング標準に適合していることを検証する。
d) 必要なソフトウェアコンポーネントだけが修正されたことを検証する。
e) 新しいソフトウェアコンポーネントが，適切に統合されたことを検証する。
f)
文書が更新されていることを確実にするために検査する。
g) 構成管理要員は，テストのためのソフトウェア品目を構築する。
h) 独立したテスト組織によってテストを実施する。
i)
完全に統合されたシステム上でシステムテストを実施する。
j)
テスト報告を作成する。
5.4.2.2
承認
保守者は，契約で指定するように修正が完了したことに対して承認を受ける（JIS X 0160の5.5.4.2を参
照）。
もし，保守が合意なしに実施されている場合にも，承認を得ることが望ましい。次のタスクステップが
実行されることが望ましい。
a) QA（品質保証）ライフサイクル支援プロセス(JIS X 0160)を通して承認を得る。
b) プロセスに従っていることを検証する。
c) 構成管理が配布パッケージを用意し，運用者の施設に送付する。
d) 機能的構成及び物理的構成の監査を行う。
e) 運用者に通知する。
f)
運用者の施設で導入及び教育訓練を実施する。
5.4.3
制御
制御は，共同レビュー（JIS X 0160の6.6を参照）を通して行われる。
5.4.4
支援
保守レビュー及び受入れアクティビティは，次のJIS X 0160の支援ライフサイクルプロセスを利用する。
− 品質保証プロセス
− 検証プロセス
− 妥当性確認プロセス
− 共同レビュープロセス
− 監査プロセス
5.4.5
出力
保守レビュー及び受入れアクティビティの出力は，次による。
15
X 0161：2008 (ISO/IEC 14764：2006)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
− 受け入れられた修正を組み込んだ新ベースライン
− 却下された修正
− 受入れ報告
− 監査及びレビュー報告
− ソフトウェア適格性確認テスト報告
5.5
移行
システムの寿命が続く間，異なる環境の中で稼働させるために，変更が必要となるかもしれない。新し
い環境にシステムを移行するためには，保守者は，移行を成し遂げるために必要な処置を決定し，次に，
移行を遂げるために必要なステップを策定し，文書化する必要がある。
5.5.1
入力
移行アクティビティの入力は，次による。
− 旧環境
− 新環境
− 旧ベースライン
− 新ベースライン
5.5.2
タスク
保守者は，JIS X 0160に従って移行を行う。移行計画を策定し，利用者に移行を知らせ，教育訓練を行
い，完了の通告を行い，新しい環境の影響を評価し，データを保管する。移行アクティビティからのすべ
ての成果物を，構成管理の制御下に置く。
5.5.2.1
移行
システム又はソフトウェア製品（データを含む。）を新しい運用環境に移行する場合，移行のために作成
又は修正した，いかなるソフトウェア製品又はデータも，JIS X 0160を遵守しなければならない（JIS X 0160
の5.5.5.1を参照）。
次のタスクステップを実施することが望ましい。
a) すべての追加又は修正されたソフトウェア製品及びデータを明らかにする。
b) タスクがJIS X 0160に従っていることを検証する。
5.5.2.2
移行計画
移行計画を作成し，文書化し，それを実行する。計画立案には，利用者を参加させる。計画には，次の
項目を含める（JIS X 0160の5.5.5.2を参照）。
a) 移行のための要求分析及び要求定義
b) 移行のためのツールの開発
c) ソフトウェア製品及びデータの変換
d) 移行の実施
e) 移行の検証
f)
移行後の旧環境の支援
移行計画の策定は，利用者からの入力を含むことが望ましい。このタスクの一部として，保守者は，次
のタスクステップを実施することが望ましい。
a) 移行要求事項を分析する。
b) ソフトウェア製品の移行の影響を判定する。
16
X 0161：2008 (ISO/IEC 14764：2006)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
c) 移行実施のスケジュールを確立する。
d) 運用後レビューのためにデータ収集要求事項を明確にする。
e) 移行作業を定義し，文書化する。
f)
リスクを判定し，軽減する。
g) 必要な移行ツールを明確にする。
h) 旧環境に必要な支援を明確にする。
i)
移行ツールを開発及び／又は取得する。
j)
変換のためにソフトウェア製品及びデータを細分化する。
k) ソフトウェア製品及びデータの変換の優先順位を付ける。
l)
ソフトウェア製品及びデータを変換する。
m) ソフトウェア製品及びデータを新しい環境に移行する。
n) 並行運用を行う。
o) テストを通して移行の検証を行う。
p) 旧環境に対して支援を提供する。
5.5.2.3
目的の通告 (Notification of intent)
移行計画及び実施内容について，利用者に通知する。この通知には，次の項目を含める（JIS X 0160 の
5.5.5.3を参照）。
a) 旧環境の支援を停止する理由
b) 新しい環境の説明及び利用開始日
c) もし，あるならば， 旧環境への支援停止後に利用者が選択できる，その他の支援策の説明
保守者は，計画，手続及びスケジュールを利用者に対しても提供することが望ましい。このタスクの一
部として，保守者は，次のタスクステップを実施することが望ましい。
a) 影響するすべての関連部署を明確にする。
b) 現場からのフィードバックに対処する。
c) 現場に固有な問題を明確にする。
d) スケジュールを伝達する。
5.5.2.4
運用及び教育訓練の実施
新しい環境への切替えを円滑にするために，新旧環境の並行運用を行ってもよい。この期間中に，契約
で指定するように利用者への教育訓練を行う（JIS X 0160の5.5.5.4を参照）。
このタスクの一部として，保守者は，並行運用のために次のタスクステップを実施してもよい。
a) 現場の調査を実施する。
b) 機器を設置する。
c) ソフトウェアを導入する。
d) ハードウェア及びソフトウェアの導入が確実に成功するように，事前にテストを実施する。
e) 旧システムと並行して，運用の負荷がかかった状態でソフトウェアを実行する。
f)
新旧製品からデータを収集する。
g) データの整理及び分析を実施する。
保守者は，教育訓練のために次のタスクステップを実施することが望ましい。
a) 移行教育訓練の要求事項を明確にする。
17
X 0161：2008 (ISO/IEC 14764：2006)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
b) 移行教育訓練の要求事項のスケジュールを立てる。
c) 移行教育訓練のレビューを行う。
d) 教育訓練計画を更新する。
5.5.2.5
完了の通告 (Notification of completion)
予定する移行時期が来たならば，関係者全員に通知する。旧環境に関するすべての文書，ログ及びコー
ドは保管することが望ましい（JIS X 0160の5.5.5.5を参照）。
このタスクの一部として，保守者は，次のタスクステップを実施することが望ましい。
a) 移行日程計画の変更を伝達する。
b) 現場に固有な問題を文書化し，それをどのように解決するかを明記する。
c) 旧ソフトウェア及びデータを保管する。
d) 旧機器を撤去する。
5.5.2.6
運用後レビュー
新環境への変更による影響を評価するために，運用後レビューを実施する。レビューの結果は，しかる
べき責任者に，情報，手引及び対策として配付する（JIS X 0160の5.5.5.6を参照）。
このタスクの一部として，保守者は，次のタスクステップを実施することが望ましい。
a) システム並行運用の結果をレビューする。
b) 潜在的リスク領域を明確にする。
c) 現場に固有な問題を明確にする。
d) 得られたことを文書化する。
e) 影響分析報告を作成し，しかるべき責任者に送る。
5.5.2.7
データの保管
旧環境で用いていたデータ又は旧環境関連のデータをアクセス可能な状態にする。アクセスに関しては，
データ保護及びデータ監査に関する契約要求事項に従う（JIS X 0160の5.5.5.7を参照）。
このタスクの一部として，保守者は，次のタスクステップを実施することが望ましい。
a) 旧ソフトウェア及びデータを保管する。
b) 旧ソフトウェア及びデータの複製を作成する。
c) 安全な場所に媒体を保管する。
5.5.3
制御
共同レビュー（JIS X 0160の6.6を参照）を通して制御が行われる。
5.5.4
支援
移行作業は，次のJIS X 0160の支援ライフサイクルプロセスを利用する。
− 文書化プロセス
− 構成管理プロセス
− 品質保証プロセス
− 検証プロセス
− 妥当性確認プロセス
− 共同レビュープロセス
− 監査プロセス
− 問題解決プロセス
18
X 0161：2008 (ISO/IEC 14764：2006)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
5.5.5
出力
このアクティビティの出力は，次のものである。
− 移行計画
− 移行ツール
− 目的の通告
− 移行したソフトウェア製品
− 完了の通告
− 測定値
− 保管データ
5.6
ソフトウェア廃棄
ソフトウェア製品が有用でなくなった場合には，廃棄する。廃棄するかどうかの判断を支援するために，
分析を実施することが望ましい。そういう分析は，しばしば経済性に基づいており，廃棄計画に含まれて
もよい。分析では，次のことに費用をかける価値があるか判断することが望ましい。
− 時代遅れの技術の保持
− 新しいソフトウェア製品を開発することによる新技術への移行
− モジュール性を達成するための新しいソフトウェア製品の開発
− 保守を容易にするための新しいソフトウェア製品の開発
− 標準化を達成するための新しいソフトウェア製品の開発
− 納入者からの独立を容易にするための新しいソフトウェア製品の開発
ソフトウェア製品は，新しいソフトウェア製品に替えてもよいが，幾つかのケースでは替えられない。
ソフトウェア製品を廃棄するために，保守者は，廃棄を成し遂げるための処置を決定し，廃棄を可能にす
るために必要なステップを策定し，文書化することが望ましい。廃棄されたソフトウェア製品によって保
管されたデータの利用について考慮することが望ましい。
廃棄アクティビティからのすべての成果物を，構成管理の制御下に置く。
5.6.1
入力
廃棄作業の入力は，次のものである。
− 廃棄される旧ソフトウェア製品のベースライン
− 新しいソフトウェア製品
− 旧環境
5.6.2
タスク
保守者は，JIS X 0160に従って廃棄を行う。廃棄計画を策定し，廃棄を利用者に通知し，運用及び教育
訓練を併行に実施し，完了の通告を出し，データを保管する。廃棄アクティビティからのすべての成果物
を，構成管理の制御下に置く。
19
X 0161：2008 (ISO/IEC 14764：2006)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
5.6.2.1
廃棄計画
運用及び保守を行っている組織が，支援を停止するための廃棄計画を立案し，文書化する。計画立案に
は，利用者を参加させる。計画には，次の項目を記述し，その計画を実行する（JIS X 0160の5.5.6.1を参
照）。
a) 一定期間後の，全体又は一部分の支援の停止
b) ソフトウェア製品及び関連文書の保管
c) 将来にわたって残る支援責任
d) 新しいシステム・ソフトウェア製品への切替え（該当する場合）
e) 保管したデータへのアクセス可能性
このタスクの一部として，保守者は，次のタスクステップを実施することが望ましい。
a) 廃棄要求事項を分析する。
b) ソフトウェア製品廃棄の影響を決定する。
c) もしあるならば，代替ソフトウェアを明確にする。
d) ソフトウェア製品廃棄のスケジュールを確立する。
e) 将来にわたって残る支援の責務を明確にする。
f)
廃棄作業を定義し，文書化する。
5.6.2.2
目的の通告 (Notification of intent)
廃棄計画及び実施内容を利用者に通知する。通知には，次の項目を含める（JIS X 0160の5.5.6.2を参照）。
a) ソフトウェア製品の入替え又は増強に関する説明，及び利用開始日
b) 現行ソフトウェア製品の支援を停止する理由
c) 支援停止後，利用者が選択できる他の支援方法の説明
このタスクの一部として，保守者は，次のタスクステップを実施することが望ましい。
a) 影響のあるすべての作業場所を明確にする。
b) 現場に固有な問題を明確にする。
c) スケジュールを伝達する。
d) 現場からのフィードバックに対処する。
5.6.2.3
並行運用及び教育訓練の実施
新しいシステムへの切替えを円滑にするために，新旧ソフトウェア製品の並行運用を行うことが望まし
い（JIS X 0160の5.5.6.3を参照）。この期間中に，契約で指定するように利用者の教育訓練を行う（JIS X
0160 の5.5.6.3を参照）。
このタスクの一部として，保守者は，次のタスクステップを実施することが望ましい。
a) 現場の調査を実施する。
b) 機器を設置する。
c) ソフトウェア製品を導入する。
d) ハードウェア及びソフトウェアの導入が確実に成功するように，事前テストを実施する。
e) 旧システムと並行して，運用負荷を掛けた状態でソフトウェア製品を稼動させる。
f)
新旧製品からデータを収集する。
g) データ整理及び分析を実施する。
20
X 0161：2008 (ISO/IEC 14764：2006)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
5.6.2.4
完了の通告 (Notification of completion)
予定した廃棄時期がきたとき，関係者全員に通知する（JIS X 0160の5.5.6.4を参照）。関連するすべて
の開発文書，ログ及びコードは保管することが望ましい（JIS X 0160の5.5.6.4を参照）。
このタスクの一部として，保守者は，次のタスクステップを実施することが望ましい。
a) 廃棄日程計画の変更を伝達する。
b) 現場に固有な問題を文書化し，どのように解決するかを文書化する。
c) 旧ソフトウェア及びデータを保管する。
d) 旧機器を撤去する。
5.6.2.5
データの保管
廃棄するソフトウェア製品が，用いていたデータ又は廃棄するソフトウェア製品関連のデータをアクセ
ス可能な状態にする。アクセスに関しては，データ保護及びデータ監査に関する契約要求事項に従う（JIS
X 0160の5.5.6.5を参照）。
簡単に回復できるように，CD-ROM及び他のディジタルディスク製品に保管媒体を替えることを考慮す
ることが望ましい。このタスクの一部として，保守者は，次のタスクステップを実施することが望ましい。
a) 廃棄作業の過程で得た旧ソフトウェア及びデータを保管する。
b) 廃棄作業の過程で得た旧ソフトウェア及びデータの複製を作成する。
c) 安全な場所に媒体を保管する。
5.6.3
制御
共同レビュー（JIS X 0160の6.6を参照）を通して制御が行われる。
5.6.4
支援
廃棄作業は，次のJIS X 0160の支援ライフサイクルプロセスを利用する。
− 文書化プロセス
− 構成管理プロセス
− 品質保証プロセス
− 共同レビュープロセス
− 監査プロセス
5.6.5
出力
このアクティビティの出力は，次のものである。
− 廃棄計画
− 目的の通告
− 廃棄の結果
− 教育訓練を受けた人々
− 廃棄されたソフトウェア製品
− 完了の通告
− 測定値
− 保管されたベースライン及びデータ
21
X 0161：2008 (ISO/IEC 14764：2006)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
6
実施時の考慮事項
6.1
はじめに
ソフトウェア保守ライフサイクルプロセスは，保守計画を立てるプロセス実装に始まり，ソフトウェア
製品の廃棄とともに終わる。それには，問題又は改善のニーズによるコードの修正及び文書化が含まれる。
保守プロセスの目的は，ソフトウェアの完全性を維持しながら，既存のソフトウェア製品に対して修正を
行うことである。次に実施時の考慮事項を示す。
保守プロセスは，運用環境が誤りを発見するために必要である。そして，保守プロセスは，予期しない
新規能力及び／又は修正された能力へのニーズを運用が取り込むために必要である。ソフトウェア製品が
CASEツールによって開発されていたとしても，やはり保守は必要である。CASEツールは，保守を容易
にするが，保守の必要性をなくしてくれるわけではない。既製品をそのまま使用し，アプリケーションコ
ードを一行も書かなかったとしても，やはり保守が必要となる可能性がある。取得者又は供給者による既
製ソフトウェア製品の保守では，通常，データ及び運用の双方に関して，製品に対するインタフェースの
修正を伴う。
製品開発元に課せるべき暗黙の要求事項及び制約について考慮することが望ましい。環境が変化したか
もしれないし，当初の要求の幾つかは，もはや適用できない可能性がある。
JIS X 0160の開発，運用及び保守のプロセス実行中に発見された問題は，JIS X 0160の問題解決プロセ
スで記録し，監視する。修正依頼又は問題報告を提出する。しばしばこれらは，変更依頼と呼ばれる。JIS
X 0160の問題解決プロセスは，問題を分析し，解決する。また，ある修正依頼・問題報告が，訂正すべき
問題であるのか改良であるのかを決定する。JIS X 0160の構成管理プロセスは，修正依頼・問題報告の状
態を記録し，報告するものである。構成管理プロセスの構成制御アクティビティによって，その依頼を承
認するかどうかが決定される。承認された修正依頼・問題報告は，開発プロセスを呼び出すことによって
実現される。システムには，ソフトウェアを含む。システムエンジニアリングの側面は，JIS X 0170で規
定されている。
保守は，ソフトウェア開発製品が利用者要求を満足し続けることを確実にするために必要である。保守
は，どのような開発ライフサイクルモデル（例えば，段階的，ウォータフォール又は進化的）を使って開
発されたソフトウェアについても適用可能である。
運用環境によって課せられた制約は，保守プロセスに影響する。しばしば，24時間無停止の運用・保守
サービス環境がある。ソフトウェア保守は，簡単に停止することができないシステムに対しても行う必要
がある。この型に対して保守の戦略を適切に立てる必要がある。そのようなソフトウェアの保守は，合意
したサービス水準を下回ることがないよう慎重に計画する必要がある。保守者は，保守の行為が一般的な
システム障害を引き起こすことがないように，いつも準備しておくことが望ましい。
保守プロセスが，ライフサイクル費用のかなりの部分を消費する場合がある。実施した保守の型を分析
することでライフサイクル費用の理解に役立つ。
6.2
保守の型
是正保守は，ソフトウェア製品に実際に起きた誤りによって余儀なくされた修正を指す。ソフトウェア
製品がその要求事項を満たさないときに，是正保守を実施する。緊急保守は，是正保守を保留にして一時
的にシステムを運用状態に保つために行う計画外の修正である。
予防保守は，ソフトウェア製品に潜在的な誤りが検出されたことによって余儀なくされた修正を指す。
適応保守及び完全化保守は，ソフトウェア製品の改良のための修正である。これらの修正は，製品の設
計仕様書又はリリース済みソフトウェアには含まれていなかったものである。適応のための修正は，変化
22
X 0161：2008 (ISO/IEC 14764：2006)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
する環境に適応させるために必要な修正である。適応のための修正は，新しいシステムインタフェース，
新しいシステム又は新しいハードウェアの要求事項を実現するための修正を含む。完全化のための修正は，
ソフトウェア製品の性能又は保守性を向上させるためのものである。完全化のための修正は，利用者のた
めの新機能改善の提供を必然的に伴い，また，これまで存在しなかった保守文書の作成のためのリバース
エンジニアリング又は現行文書修正のためのリバースエンジニアリングの提供を必然的に伴う。
ソフトウェア保守は，現行の構造又はシステムの修正を必要とする。例えば，ソフトウェア修正は現行
のアーキテクチャに対して行われ，設計構造によって課せられた制約を考慮するはずである。このように
適応及び完全化保守の形態での改良は，しばしば多大な費用及び時間を消費する。改良は，保守費用のか
なりの部分を占める。
6.3
保守の段取り
取得者は，開発元が保守を行う合意を締結してもよいし，第三者が保守者になってもよい。また，保守
は，内部での二者間合意によっても提供可能である。
保守サービスモデルは，合意されていることが望ましい。このモデルは，すべての型の保守を対象とし，
費用及び資源の総計が当初の固定価格を超えない範囲であれば，新規開発を含むことが望ましい。責任者
は，どの型の保守が含まれているかを識別することが望ましい。
なお，包括契約は，固定価格で作成されることが望ましい。推奨契約形態は，次のものがある。
− 形態1：総保守費を固定した一括契約である。これにはすべての型の保守を含み，かつ，新規開発を
含んでいてもよい。
− 形態2：保守の個別契約である。典型的には合意した期間での是正保守がある。予防保守，適応保
守，完全化保守は，通常それぞれ別に契約を結ぶ。
JIS X 0160は，取得者と供給者との間の合意締結を導くための詳細なタスクを提供する。これは，取得
者と供給者とが同じか又は異なる組織であるかにかかわらず，保守合意締結を導く助けに使用されること
が望ましい。これらの契約は，しばしばサービスレベル契約 (SLA)と呼ばれる。特定の保守問題について
は，後ほどで示す。
取得者が，引渡し後又は保証期間終了時に，ソフトウェア保守を開発者に要求する場合には，合意書に，
このことを明文化することが望ましい。更新された文書を納入するよう，契約の中で明文化することが望
ましい。教育訓練も，同様に明文化した方がよい。その後，供給者は，保守タスクのための手続を準備し，
これらの手続を最新に維持し，活動が合意要求事項及び準備した手続に適合しているかどうかを確認する
ことが望ましい。経験的データは，当該手続の使用が，費用対効果が高いことを示している。保守すべき
項目，保守の手続及びそれらの保守のための時間は，保守計画の中で規定することが望ましい。
供給者（保守者）及び取得者は，保守合意締結について合意し，保守対象ソフトウェア製品に修正を取
り込む手続を明記することが望ましい。保守者が開発元及び第三者である場合にも，同様の手続が利用さ
れることが望ましい。
これら手続には，次を含む。
− ソフトウェアが局所的に訂正できる時期，又は導入及びリリースのためにJIS X 0160の開発プロセス
を用いている新しいベースラインが必要となる時期を決定するための基本ルール
− 頻度又はソフトウェア運用に影響するリリースのタイプの記述（例えば，緊急リリース，定期的リリ
ース）
− 現在又は将来の修正の状態について取得者に知らせる方法
− 変更がソフトウェアに新たな別の問題を発生させないことを確認する手法
23
X 0161：2008 (ISO/IEC 14764：2006)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
− 修正の分類は，次のとおりである。
a) 大規模・小規模
b) その他の特徴 修正がどのように認証され，処理され，そして承認されるかの区別
6.4
保守ツール
ソフトウェア保守費用を抑える可能性のある方法は，CASEツールの使用である。これらのツールは，
ソフトウェア保守の作業を助ける。CASEの潜在的な性能は，ソフトウェア開発及び保守のすべての局面
を支援する相互に関連したツールのセットである (ISO/IEC TR 14471)。これらの相互に関連したCASEツ
ール群は，ソフトウェア保守の作業を支援する手法，方針，指針及び標準をソフトウェアエンジニアリン
グ環境(SEE)の形式にまとめ上げることが望ましい。ソフトウェアテスト環境(STE)も，また修正したソフ
トウェア製品を非運用環境でテストすることができるように保守者のために提供されることが望ましい。
SEEは，最初に，ソフトウェア製品を開発し，かつ，修正するためのツールを提供する。STEは，テスト
環境を提供する。STEは，修正したソフトウェア製品を非運用環境でテストするために使用するとよい。
これまでのところ，CASEツールの導入は，十分でないところもある。保守者は，CASEツールの導入
を慎重に計画することが望ましい (ISO/IEC TR 14471)。ISO/IEC TR 19759は，ツールに関する補足情報
を提供する。
6.5
ソフトウェア保守の測定
ソフトウェア品質は，ソフトウェア製品の保守の重要な考慮事項である。保守者は，JIS X 0129-1に規
定されているソフトウェア品質の6特性を含むソフトウェア品質計画をもつことが望ましい。JIS X 0160
追補1 (F.3.1.6)による測定プロセスが，ソフトウェア保守のためのソフトウェア測定の特定，定義，選択，
適用，妥当性確認及び改善のために，実装されていることが望ましい。JIS X 0141は，測定に関する補足
情報を提供する。
ソフトウェア測定の一部として，保守者は，是正保守，予防保守，適応保守及び完全化保守のための作
業工数を（費やす資源について）割り出すのがよい。保守プロセスの改善を促進し，保守費用が何に費や
されているかを，よりよく理解するために，データを収集し，分析し，解釈することが望ましい。ライフ
サイクル費用の見積りを助けるために，更に必要であれば，ソフトウェア製品の品質問題及び次期ソフト
ウェア製品に対する開発者のプロセスの改善に対して何ができるかを説明するためにも，実証的測定デー
タを集めることが望ましい。
6.6
プロセスの文書化
ソフトウェア保守プロセスの詳細（箇条5を参照）は，すべての保守要員が同じプロセスに従うように
文書化することが望ましい。測定値によって，プロセス及び関連するソフトウェアプロセス改善作業を支
援することが望ましい。
6.7
開発への早期参加
これまでのデータによれば，ソフトウェア保守費用及び保守者のソフトウェア保守を行う能力は，ソフ
トウェア開発プロセスにおいて，何が発生したか，又は発生しなかったかに大きく影響を受けていること
を示している。多くの場合，契約又はその他の理由で，保守者は開発に参画できない。特に，保守が第三
者に外部委託される場合は，開発に参画する機会は多くの場合，全くない。開発中に保守者が参画するこ
とが可能ならば，参画することが望ましい。
保守者によって実施される機能には，次を含めるとよい。
− そのソフトウェア製品を支援する業務を計画する。
− 知識引継ぎを計画する。
24
X 0161：2008 (ISO/IEC 14764：2006)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
− そのソフトウェア製品の保守性を確実にする。
− 開発から保守へのソフトウェア製品の引継ぎ計画立案を支援する。
計画については，この規格の7.3で詳しく示す。保守者のプロジェクトへの早期参画は，ソフトウェア
の保守性要求を明らかにし，確立し，提示することに役立つ。JIS X 0129規格群は，保守性及び他のソフ
トウェア品質特性を明示的に定義するために使用するのが望ましい。保守性は，保守者がJIS X 0160の支
援ライフサイクルプロセスの品質保証，検証及び妥当性確認のプロセスに参加することによって改善でき
る。保守者は，次のことを実施するのがよい。
− レビューに参加する。
− コード分析を行う。
− 要求事項の追跡をする。
− 検証及び妥当性確認を行う。
6.8
保守性
ソフトウェアの保守性及び保守は，ディペンダビリティの重要な側面である。保守性は，取得者，供給
者及び利用者にとって，ソフトウェアの重要な特質である。保守性要求事項は，JIS X 0160の取得プロセ
スの開始アクティビティに含まれ，JIS X 0160の開発プロセスを通じて評価することが望ましい。設計の
変化が，保守性への影響を与えることについて，開発を通して監視することが望ましい。ソフトウェアの
品質を定義し，評価するために，複雑度測定値を含む，様々な測定値を用いることが望ましい。定性的及
び定量的評価がともに重要である。ソフトウェアの解析性，変更性，安定性，及び試験性を扱う四つの保
守性の副特性がある。これら四つの特性が，作業（速さではない。）及びソフトウェア修正の容易さに影響
する。
6.8.1
保守性及び開発プロセス
非機能的要求である保守性要求は，ソフトウェアプロジェクトの早い段階で作成及び合意しておくこと
が望ましい。ソフトウェアが第三者から取得されるとき，JIS X 0160の開始アクティビティの一部として，
取得者と供給者との間で，保守性要求水準の取決めがなされることが望ましい。
保守性の基準（又は目標）を監視し，評価するための能力は，各々の要求について特定し，ソフトウェ
ア開発中に作成するのがよい。この能力によって，顧客が定めた定性的及び定量的なソフトウェア保守性
の要求事項を記述する。これによって，基準及び検査法を定義する。定性的要求事項（例えば，使用性，
保守性）は，保守の見積り及び資源を準備するために用いる技法を定義するために利用する。定量的要求
事項は，保守性の評定，評定水準又は品質基準及び測定値を定義するのに使用され，様々なソフトウェア
のライフサイクルの段階を通じて，数値又は指標を決定するために用いる。
指定された保守性の副特性は，ソフトウェア開発期間中にレビューし，制御することが望ましい。保守
者による保守性の妥当性検証を確実なものにするための見積り工数は，保守戦略文書の中に規定されるこ
とが望ましい。開発者は，保守性の要求事項を実現し，保守者は，その実施を監視することが望ましい。
この作業は，保守戦略の一部である。
JIS X 0160を適用するためのかぎ（鍵）となる一つの要因は，保守戦略（ISO/IEC TR 15271, Guide for
ISO/IEC 12207）の策定である。それゆえ，保守戦略を策定し，保守を計画することが望ましい（箇条7
を参照）。
保守戦略は，また，設計前に確立するとよい。初期に保守者が，ソフトウェアプロジェクトに参画する
ことで，保守費用の節減につながる可能性がある。ソフトウェア保守計画を含めて，開発プロセスの間に
多くの行為が行われる。これらの行為は，保守計画に文書化することが望ましい（7.3.2を参照）。
25
X 0161：2008 (ISO/IEC 14764：2006)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
保守性は，アーキテクチャ，設計，コーディング及びそのプログラム言語，並びにテストアクティビテ
ィに影響される。ISO/IEC TR 19759は，保守性を高めるために，よいアーキテクチャ及び設計への取組に
関する追加情報を提供する。
次の側面は，すべて保守性に影響するものであるが，プログラム言語を選ぶときに考慮することが望ま
しい。
− 言語の移植性
− 言語の読みやすさ
− 言語の安定性
− 自己記述性
− プログラムの分かりやすさを損なうプログラミングの技巧の許容範囲
− プログラム構造化の可能性
− 新規リリース作成の容易さ
− データ構造化の可能性
− コンパイラなどのツールの入手可能性
− コンパイラなどのツールの安定性
− コンパイル及び実行中のテスト可能性
− 作成，デバッグ，構成管理，及び信頼性要求事項・品質要求事項の充足を支援するソフトウェアエン
ジニアリング環境及びソフトウェアテスト環境の利用可能性
− 様々な開発ツールの使用可能期間
6.8.2
保守性及び開発プロセスでの特定のアクティビティ群
6.8.2.1
ソフトウェア要求分析
ソフトウェア仕様書は，ソフトウェアの保守性の要求事項を漏れなくあいまい（曖昧）でなく記述して
いることが望ましい。これらのものは，JIS X 0160が要求する品質特性仕様書に含まれていることが望ま
しい。次の側面は，保守性に影響を与えるものであり，考慮することが望ましい。
− 機能の識別及び定義，特に付加機能の特定及び定義
− データの正確性及び論理的構成
− インタフェース（機械及び利用者），特に将来変更が起こり得るインタフェースの要求
− 訂正及び追加の影響を考慮した性能要求事項
− 規模性の要求事項及び予測されるシステム成長を考慮して，計画された環境によって課せられる要求
事項
− 追跡の容易さ又は困難さに影響するような要求事項の粒度
− 文書化及び文書適合性に重点を置いたソフトウェア品質保証計画
6.8.2.2 ソフトウェア方式設計
このアクティビティは，ソフトウェア品目に対する要求事項を，ソフトウェアの最上位水準の構造及び
ソフトウェアコンポーネントを明らかにするソフトウェア方式に変換する（JIS X 0160を参照）。ユーザア
プリケーション層及び基盤システム運用層がインターネットシステムに対して適切に独立しているような
方式例では，基盤ソフトウェアからアプリケーションを分離して保守する大きな助けとなる。保守性に影
響を及ぼすJIS X 0160の開発プロセスのアクティビティの主な特徴は，プログラム構造を選択し，それを
構成要素に分解し，そこでのデータの流れを定めることである。他のアクティビティのように，プログラ
ミングチームのデータ処理の知識を利用することが重要であり，特にこれによって，ディペンダビリティ
26
X 0161：2008 (ISO/IEC 14764：2006)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
が既に確認済みの，既存のプログラム又はライブラリ部品の利用可能性を明らかにできるからである。
注記 ディペンダビリティ(dependability) アベイラビリティ及びその影響要因，すなわち，信頼性，
保守性及び保全支援の能力を記述するために用いる用語の総称(JIS Q 9000:2000を参照)。
6.8.2.3
ソフトウェア詳細設計
JIS X 0160の開発プロセスのこのアクティビティは，それぞれのソフトウェアコンポーネント，インタ
フェース及びデータベースの詳細な設計を提供する。このアクティビティは，提示されたプログラミング
の解決策を仕上げるために，機能を正確に詳細化した記述を作り出す。
6.8.2.4
ソフトウェアコード作成及びテスト
JIS X 0160の開発プロセスのこのアクティビティは，ソフトウェアユニット及びデータベースを開発し，
文書化し，テストする。ソフトウェアの保守性は，文書の品質を向上することによって改善される。質の
高い文書は，保守プロセスの実行を助ける情報を提供することが望ましい。保守性を改善させるための提
言としては，次がある。
− 確実に読みやすくする。
− 構造化コーディングをやり通す。
− コーディングの複雑度を低減する。
− コードに正確なコメントをつける。
− 字下げ及び空白を利用する。
− 言語の弱点を考慮することによって，古典的なわな（罠）をさける。
− 誤りの追跡を容易にするような技術を使用する。
− ソースコードから設計への追跡性を確実にする。
− コーディング標準を使用する。
− 制御フロー及び判定の複雑度を低減する。
− コード及びテストケースの検査を指揮する。
− 開発サイクル期間中の文書を維持する。
6.8.2.5
ソフトウェア適格性確認テスト
このアクティビティは，それぞれ実装されたソフトウェア品目がその適格性確認要求に適合しているか
をテストするのを確実にする。ソフトウェア開発中に使用されたテストケースは，修正後の回帰
(regression)テストのために保管しておくことが望ましい。さらに，開発期間中のソフトウェアの進化をよ
りよく理解するために，プログラムの開発履歴が保守で利用できることが望ましい。
6.9
ソフトウェアの引継ぎ
ソフトウェアの引継ぎは，ソフトウェア開発を，最初のソフトウェア開発実施組織から，ソフトウェア
保守を実施する組織に受け渡すための，制御され，調整された一連の行為である。もし，保守の責務があ
る組織から他の組識へ移るならば，引継ぎ計画を策定することが望ましい。この計画では，次のことを考
慮することが望ましい。
− 開発者から保守者への，ハードウェア，ソフトウェア，データ，支援サービス及び経験の引継ぎ
− ソフトウェア保守戦略を実現する上で，保守者に必要なタスク（例えば，要員配置，教育訓練，導入
及び保守中の問題の再現）
− 知識引継ぎ及び文書化の評価
− 突出した問題及び新規要求事項の優先順位
− テスト環境の準備状況の評価
27
X 0161：2008 (ISO/IEC 14764：2006)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
− ソースコード及びオブジェクトコードについて構築時構成情報の引継ぎ（未解決又は延期された問題
報告及び新規要求事項，保守期間に更新する可能性がある媒体の原本の数量及び保管場所を含む。）。
6.10 文書化
保守者は，文書がわずかしかないか，全くないソフトウェア製品の保守を行うことにしばしば直面する。
このような状況に直面した場合は，計画から最終移行までの期間に，保守者が，必要な文書を作成するこ
とが望ましい。保守者は，保守の準備をするために，次のタスクを実行する間に必要な文書を作成するこ
とが望ましい。
a) 問題の領域（アプリケーションの種類）を理解する。（入手できれば）文書をすべて読み，（可能なら
ば）開発者とソフトウェア製品について議論し，ソフトウェア製品を操作する。
b) ソフトウェア製品の構造及び構成（例えば，制御フロー，データフロー，データ構造，呼出し図）を
学ぶ。ソフトウェア製品の棚卸しを実施し，ソフトウェア製品を構成管理の下におき，構成管理ライ
ブラリからソフトウェア製品を再構築し，呼出し木構造を作成し，ソフトウェアの構造を分析する。
c) ソフトウェア製品が何をしているのか判定する。（利用できれば）仕様書をレビューし，全体の構造を
レビューし，呼出し木構造を分析し，コードを読み，他の保守者に口頭で説明し，コードにコメント
を付ける。
d) ソフトウェアの安定性を維持するために，低リスクな修正に取り組み，そして次第にリスクが高く，
かつ，複雑な修正に取り組むことによって，徐々に信頼を築く。
保守者は，上の手引を実行しながらソフトウェア製品の文書を作成することが望ましい。仕様書，プロ
グラマの保守マニュアル，利用者マニュアル及び導入手引のような文書は，必要に応じて更新又は作成す
ることが望ましい。
保守環境では，様々な要素が文書作成及び更新に影響を与える。幾つかの要素には，ソースコードへの
アクセス，コードを分析するツールの利用可能性，性能を決定するためにソフトウェア製品を操作する能
力及びソフトウェアテスト環境(STE)の利用可能性が含まれる。
7
ソフトウェア保守の戦略
7.1
はじめに
ここでは，ソフトウェア保守戦略の策定について定める。この戦略は，ソフトウェア製品の保守をする
のに必要な人的資源及び物的資源の準備のためにある。保守者は，保守性のために開発作業を監視するの
が望ましい。保守性分析の結果は，保守計画立案を支援する目的で利用することが望ましい。この分析は，
保守戦略の策定への入力として提供されることが望ましい。ソフトウェア保守戦略は，次の要素から構成
されることが望ましい。
− 保守概念
− 保守計画
− 資源分析
7.2
保守概念
保守概念の決定は，ソフトウェア保守戦略策定の最初の段階で行うことが望ましい。最適なソフトウェ
ア保守計画作成のために, 保守概念は，ソフトウェア製品に対する初期のニーズが最初に表明された後，
直ちに作成することが望ましい。
保守概念は，次を取り扱うことが望ましい。
− ソフトウェア保守の適用範囲
28
X 0161：2008 (ISO/IEC 14764：2006)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
− 保守プロセス全体の定義
− 保守者の指名
− 保守費用の見積り
注記 保守概念は，当該保守計画の中に文書化する。
7.2.1
適用範囲
保守の適用範囲は，保守者がどのように対応するかに関係する。保守者がどのくらいの支援を行うかを
決定しておくことが望ましい。予算的制約は，しばしば保守の適用範囲に影響する。保守の適用範囲は，
次を取り扱うことが望ましい。
− 実施する保守の型
− 維持すべき文書化の水準
− 対応度
− 提供する教育訓練の水準
− 引渡しのときの支援
− ヘルプデスクの支援
7.2.2
プロセスの定義
保守概念は，引渡し後のソフトウェア保守で使用されるプロセスの全体像を含むことが望ましい。その
プロセスの全体像は，上位のタスクを特定することが望ましい。早い段階で，各ソフトウェア保守のタス
クに関係する種々の組織を特定することが望ましい。
7.2.3
保守者の指名
保守者の指名は，重要な課題の一つであり，早い段階で取り扱い，保守概念に文書化しておくことが望
ましい。このことは，組織内での作業についても同様に当てはまる。外部委託した第三者との合意に基づ
く保守活動に関しては，保守概念の中に保守を外部委託するということを，指摘しておくことが望ましい。
JIS X 0160の取得及び供給の主プロセスは，ソフトウェアサービスの取得及び供給について詳細を示す。
保守者の指名は，次のものを含んだ幾つかの要素を基に行うことが望ましい。
− 要求されたサービス水準
− ソフトウェア製品の寿命
− 長期的費用
− 業務開始時費用
− 作業スペースの利用可能性
− 資格
− 稼働可能性
− スケジュール
− 対象分野の知識
7.2.4
保守費用の見積り
保守費用の見積りを準備することが望ましい。その見積り費用は，保守の適用範囲に依存したある種の
関数であることが望ましい。次の追加的な要因を含むことが望ましい。
− 利用者の所在地までの移動
− 保守者と同様に利用者への教育訓練
− ソフトウェアエンジニアリング環境及びソフトウェアテスト環境の費用及び年間保守費
− 給料及び手当のような人件費
29
X 0161：2008 (ISO/IEC 14764：2006)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
保守概念策定時，システムダウン時間の費用を含む，利用可能な限られたデータで費用を見積るとよい。
開発が進めば，再見積りを行うことが望ましい。過去の計測データは，保守費用を見積る場合の入力とし
て使うことが望ましい。
7.3
保守計画立案
7.3.1
はじめに
保守計画立案の目的は，保守アクティビティの計画を立てること，及びソフトウェア製品の保守への引
継ぎと同時に資源が利用可能となるように，十分に早い段階で必要な資源を取得することである。計画立
案作業は，保守概念を定義したら着手し，ソフトウェアのサービス開始と同時に保守者の手引として使用
する保守計画として完結する。IEEE Std 1058を保守計画の手引に利用してもよい。
7.3.2
保守計画
保守のアクティビティ及びタスクの計画立案は，上記でも示したように保守概念が定義されると同時に
始めることが望ましい。保守計画の提出で計画立案作業は完結する。保守計画は，ソフトウェア開発期間
中に保守者によって準備され，かつ，利用者がどのようにソフトウェア製品への修正を要求するかを記述
することが望ましい。
保守計画には，次のことを盛り込むことが望ましい。
− なぜ保守が必要か。
− だれがどの作業をするか。
− 参画している全員の役割及び責任は何か。
− どのように作業を実施するか。
− 保守のためにどのような資源が利用できるか。
− どこで保守を実施するか。
− いつ保守を開始するか。
− システム記述
− 合意のための手続き
− 教育訓練
− 制御
− 記録及び報告
7.3.3
保守計画の題目
ここでは，保守計画を策定するための指針を示す。保守計画に含める題目について提案する。作業量に
基づいて，含めた方がよい題目を決めることが望ましい。
幾つかの情報については，別の文書を参照することで記述できる。
a) はじめに
1) 保守支援されるべきシステムの記述
2) ソフトウェアの初期状態の特定
3) なぜ支援が必要かの記述
4) 保守者及び支援組織の特定
5) 保守作業で扱う個別のソフトウェアプロセスの特定
6) 顧客と供給者との間の合意のための規約の記述
7) 保守を行う場所の特定
8) 保守を始める時期の特定
30
X 0161：2008 (ISO/IEC 14764：2006)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
9) 保守を提供するための費用の特定
10) スケジュールの特定
b) 計画の制御及び確認
1) 発行日の特定
2) 計画の状態の特定
3) 発行組織の特定
4) 承認権限の特定
5) 計画修正手続の記述
6) 修正履歴の準備
7) 用語解説の準備
c) 参照（上位の方針，手続及び文書への参照，並びに下位の計画及び追加情報提供の手続への参照）
1) 保守作業の制限事項に関する文書の特定
2) 保守計画で参照される文書の特定
3) 保守計画の補完又は実施を支援する文書の特定
d) 定義
1) 保守計画を理解するために要求されるすべての用語の定義又は参照
2) 使用されたすべての略語及び記法の記述
e) 保守概念
1) システムに対する支援水準の記述を含む概念の記述。例えば，是正保守だけの実施。
2) 支援期間の特定
f)
組織及び保守のアクティビティ
1) 引渡し前の保守者の役割及び責任
1.1) プロセス実装
1.2) 環境整備の確立
1.3) 人材育成プロセスの確立
1.4) ソフトウェア保守プロセスの確立
1.5) 保守性計画の策定
1.6) 保守性についての開発実施の監視
1.7) 移行計画の策定
1.8) 開発アクティビティへの保守者の参加
1.9) 他組織とのインタフェース
2) 引渡し後の保守者の役割及び責任
2.1) プロセス実装
2.2) 問題分析及び修正の分析
2.3) 修正実施
2.4) 保守のレビュー及び受入れ
2.5) 移行
2.6) 廃棄
2.7) 問題解決策（ヘルプデスクを含む。）
2.8) 該当する場合，人員（保守者及び利用者）に対する必要な訓練
31
X 0161：2008 (ISO/IEC 14764：2006)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
2.9) プロセスの改善
2.10) 組織の保守優先度を決定するための要素
2.11) 作業パッケージへの優先順位割当てのプロセス
2.12) 優先付けされた作業パッケージへの資源の割当て法
2.13) 計画見積り手法
2.14) 他組織とのインタフェース
3) 運用者の役割
3.1) 受入れテスト
3.2) 他組織とのインタフェース
g) 資源
1) 人員
1.1) プロジェクトの要員数
2) ソフトウェア
2.1) 支援システムに必要なソフトウェアの特定（システムに加え，SEE/STE/ツールの要求事項を含む。）
3) ハードウェア
3.1) 支援システムに必要なハードウェアの特定（システムに加え，SEE/STEの要求事項を含む。）
4) 施設
4.1) 施設についての要求事項の特定
5) 特別な手続についての要求事項（例えば，セキュリティ，アクセス権限及び文書管理）
6) 費用見積り
6.1) 費用見積り手法の記述
7) 文書化
7.1) ソフトウェア品質計画書
7.2) プロジェクト管理計画書
7.3) 構成管理計画書
7.4) 測定計画書
7.5) 開発文書
7.6) 保守マニュアル
7.7) 検証計画書
7.8) 妥当性確認計画書
7.9) テスト計画書，テスト手順書及びテスト報告書
7.10) 教育訓練計画書
7.11) 利用者マニュアル
8) データ管理
8.1) リポジトリーの特定
9) その他の必要な資源についての要求事項
h) プロセス（どのように作業を実施するか。）
1) 保守者のプロセス（プロセスの全体像は示すが，保守計画の中にすべてのプロセスを詳細記述する
ことはしない。）
2) 定義されたプロセス（プロセスの各アクティビティを実施するための行為の特定）
32
X 0161：2008 (ISO/IEC 14764：2006)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
i)
教育訓練
1) 保守者及び利用者が求める教育訓練の特定
j)
ソフトウェア保守制御要件
1) 想定範囲を超えた場合の方針の記述
2) 制御手順の記述
3) 品質を管理する測定値の特定
4) 標準，慣行，規約の記述
5) リスクの特定
k) 保守の記録及び報告
1) 情報を集め，提供する方法の記述
2) 支援の依頼，修正依頼又は問題報告の一覧
3) カテゴリ別依頼の状況
4) 依頼の優先度
5) 保守のアクティビティで収集される計測データ
7.4
資源分析
ソフトウェア保守戦略の最後の要素は，資源分析である。保守の適用範囲と担当組織とが分かると，必
要な人員，保守環境及び財政的な資源が決められる。取得者は，通常は供給者（開発者）からの支援を受
けて，ソフトウェア保守に必要な資源を決める。人的，環境及び財政的な資源を対象とすることが望まし
い。
7.4.1
人的資源
資源要求は，ソフトウェア保守計画を立案するときの大きな課題である。人的資源の要求は主要な費用
要素であると同時に，正確に見積もることが最も困難な要素である。最も一般的なソフトウェア保守資源
の見積り方法は，パラメトリックモデルを使用すること，及び経験を利用するという二つの方法である。
経験的データ及び歴史的データは，両方の方法に共通して利用され，パラメトリックモデル化のために必
要である。
保守の見積りには，標準的で広く受け入れられている方法論の使用を推奨する。人的資源を決定するた
めの方法論及びその結果を取り扱うような，保守に関する要員配置については個別の研究を行うことが望
ましい。
7.4.2
環境資源
ソフトウェアの開発及び保守は，それぞれ独自のアクティビティであり，それぞれ専用の別のシステム
を必要とする。個別のソフトウェアエンジニアリング環境（SEE）及びソフトウェアテスト環境 (STE)の
使用を推奨する。保守者は，保守環境計画を計画することによって取得者を支援することが望ましい。ソ
フトウェア製品の開発及び保守のために，資金の割当て及び予算の決定が行われる早い段階の計画立案作
業時に，保守環境のことを含めてしまうことが重要である。
7.4.3
財政的資源
三番目で，かつ，最後の側面は，財政的資源である。有効な保守支援を提供するため，保守者が次のこ
とを対象とする予算をもつことが望ましい。
− 給料
− 教育訓練費（1人に対し1年に2〜3週間）
− ソフトウェアライセンスの年間保守費
33
X 0161：2008 (ISO/IEC 14764：2006)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
− 出張
− 技術系出版物
− エンジニアリング及びテスト環境のためのハードウェア及びソフトウェア
− エンジニアリング及びテスト環境のためのハードウェア及びソフトウェアの更新
34
X 0161：2008 (ISO/IEC 14764：2006)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
附属書A
（参考）
JIS X 0161と，JIS X 0160:1996及びJIS X 0160追補1との参照関係
JIS X 0161の箇条番号
JIS X 0160:1996の箇条番号
JIS X 0160 追補1の箇条番号
1.1
1.2
3.2
3.5
4.1
4.1.1.1/4.1.1.2/ 4.1.1.3
F.3.4/F.3.4.2
5
5.5
5.1
5.5.1
5.1.2.1
5.5.1.1
5.1.2.2
5.5.1.2
5.1.2.3
5.5.1.3
5.1.3
6.6
5.2
5.5.2
5.2.2.1
5.5.2.1
F.1.5
5.2.2.2
5.5.2.2
5.2.2.3
5.5.2.3
5.2.2.4
5.5.2.4
F.1.5
5.2.2.5
5.5.2.5
5.2.3
6.6
5.3
5.5.3
5.3.2.1
5.5.3.1
5.3.2.2
5.3/5.5.3.2
F.1.3/F.1.3.1-F.1.3.11
5.3.3
6.6
5.4
5.5.4
5.4.2.1
5.5.4.1
5.4.2.2
5.5.4.2
F.3.4
5.4.3
6.6
5.5
5.5.5
5.5.2
5.5.5.4
F.3.4
5.5.2.1
5.5.5.1
5.5.2.2
5.5.5.2
F.1.5
5.5.2.3
5.5.5.3
5.5.2.4
5.5.5.4
F.1.5/F.3.4
5.5.2.5
5.5.5.5
5.5.2.6
5.5.5.6
5.5.2.7
5.5.5.7
5.5.3
6.6
5.5.4
5.5.5.4
F.3.4
5.6
5.5.6
5.6.2.1
5.5.6.1
F.1.5
5.6.2.2
5.5.6.2
5.6.2.3
5.5.6.3
F.1.5/F.3.4
5.6.2.4
5.5.6.4
5.6.2.5
5.5.6.5
5.6.3
6.6
6.1
5.5/6.2/6.8
F.1.5
6.3
5.1.3
6.5
F.3.1.6
7.1
5.5.1.1
F.1.5
7.2.1
5.5.1.1
F.3.4.2
7.2.3
5.1/5.2
7.2.4
5.5.1.1
F.3.4.2
7.3.3
5.5.1.1
F.3.4
35
X 0161：2008 (ISO/IEC 14764：2006)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
附属書B
（参考）
略語
CASE computer-aided software engineering
コンピュータ支援ソフトウェア エンジニアリング
CM
configuration management
構成管理
IEC
International Electrotechnical Commission 国際電気標準会議
IEEE
Institute of Electrical and Electronics
Engineers
IEEE（電気電子学会）
ISO
International Organization for
Standardization
国際標準化機構
JTC
Joint Technical Committee
合同専門技術委員会
MR
modification request
修正要求
MRs modification requests
修正要求
PR
problem report
問題報告
PRs
problem reports
問題報告
SEE
software engineering environment
ソフトウェアエンジニアリング環境
STE
software test environment
ソフトウェアテスト環境
36
X 0161：2008 (ISO/IEC 14764：2006)
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
附属書C
（参考）
参考文献
ISO/AFNOR:1989，Dictionary of Computer Science
JIS Q 9001: 2000 品質マネジメントシステム−要求事項
注記
対応国際規格：ISO 9001: 2000，Quality management systems−Requirements（IDT）
ISO/IEC 9003: 2004，Software engineering−Guidelines for the application of ISO 9001: 2000 to computer
software
JIS X 0132: 1996 CASEツールの評価及び選択のための指針
注記
対応国際規格：ISO/IEC 14102: 1995，Information technology−Guideline for the evaluation and
selection of CASE tools（IDT）
JIS X 0135-1: 1999 ソフトウェア測定−機能規模測定−第1部：概念の定義
注記
対応国際規格：ISO/IEC 14143-1: 1998，Information technology−Software measurement−
Functional size measurement−Part 1: Definition of concepts（IDT）
ISO/IEC TR 14471: 2007 Information technology−Software engineering−Guidelines for the adoption of CASE
tools
ISO/IEC TR 15271: 1998，Information technology−Guide for ISO/IEC 12207 (Software Life Cycle Processes)
JIS X 0170: 2004 システムライフサイクルプロセス
注記
対応国際規格：ISO/IEC 15288:2002，Systems engineering−System life cycle processes（IDT）
ISO/IEC TR 15846: 1998，Information technology−Software life cycle processes−Configuration management
ISO/IEC TR 19759: 2005，Software Engineering−Guide to the Software Engineering Body of Knowledge−
SWEBOK
ISO/IEC 2382-20: 1990，Information technology−Vocabulary; Part 20: System development
IEEE 730-2002，IEEE Standard for Software Quality Assurance Plans
IEEE 828-1998，IEEE Standard for Software Configuration Management Plans
IEEE 829-1998，IEEE Standard for Software Test Documentation
IEEE 1012-1998，IEEE Standard for Software Verification and Validation
IEEE 1012a-1998，Supplement to IEEE Standard for Software Verification and Validation: Content Map to
IEEE/EIA 12207.1-1997
IEEE 1028-1997(R2002)，IEEE Standard for Software Reviews
IEEE 1042-1987，IEEE Guide to Software Configuration Management
IEEE 1058-1998，Standard for Software Project Management Plans
IEEE 1061-1998，IEEE Standard for a Software Quality Metrics Methodology
IEEE 1219-1998，IEEE Standard for Software Maintenance
IEEE 1348-1995，IEEE Recommended Practice for the Adoption of Computer-Aided Software Engineering (CASE)
Tools