X 0133-4 : 2001 (ISO/IEC 14598-4 : 1999)
(1)
まえがき
この規格は，工業標準化法に基づいて，日本工業標準調査会の審議を経て，経済産業大臣が制定した日
本工業規格である。
JIS X 0133-4
は，JIS X 0129 : 1994 を置き換えることになる ISO/IEC 9126-1（JIS 作成中）と組み合わせ
て利用することを意図している。この規格を含む JIS X 0133 群及び ISO/IEC 9126 群の二つの規格群は，
ソフトウェア製品の評価にかかわる技術の進展を考慮し，JIS X 0129 : 1994 で規定された品質モデル及び
評価プロセスモデルを拡張したものである。
JIS X 0133-4
には，次に示す附属書がある。
附属書 A（参考） 他の規格での定義
附属書 B（参考） 表
附属書 C（参考） 図
附属書 D（参考） 評価方法
附属書 E（参考） 段階的な評価プロセスの例
附属書 F（参考） 関連規格
附属書 G（参考） 参考文献
X 0133-4 : 2001 (ISO/IEC 14598-4 : 1999)
(1)
目次
ページ
序文
1
1.
適用範囲
1
2.
適合性
2
3.
引用規格
2
4.
定義
2
5.
ソフトウェア製品の評価−一般的考慮
3
5.1
評価プロセスと取得プロセスとの相関
3
5.2
評価プロセスの入力
3
5.2.1
システム要求
4
5.2.2
完全性水準の要求
5
5.2.3
ソフトウェアの要求仕様
5
5.2.4
他者による評価
5
5.3
修整
6
6.
既製ソフトウェア製品の取得における評価
7
6.1
ステップ 1−評価要求の確立
7
6.1.1
評価の目的及び範囲の確立
7
6.1.2
評価要求の仕様化
8
6.2
ステップ 2−評価の仕様化
9
6.2.1
測定法の選択
9
6.2.2
評価方法の選択
10
6.2.3
他者による評価
10
6.3
ステップ 3−評価の設計
11
6.4
ステップ 4−評価の実施
12
6.4.1
評価方法の実施
12
6.4.2
評価結果の分析
12
6.4.3
結論の記述
13
7.
注文ソフトウェアの取得及び既存のソフトウェアの修正における評価
14
7.1
ステップ 1−評価要求の確立
14
7.2
ステップ 2−評価の仕様化
14
7.3
ステップ 3−評価の設計
14
7.4
ステップ 4−評価の実施
14
附属書 A（参考） 他の規格での定義
15
附属書 B（参考） 表
21
附属書 C（参考） 図
24
X 0133-4 : 2001 (ISO/IEC 14598-4 : 1999)
目次
ページ
附属書 D（参考） 評価方法
26
附属書 E（参考） 段階的な評価プロセスの例
31
附属書 F（参考） 関連規格
33
附属書 G（参考） 参考文献
34
日本工業規格
JIS
X
0133-4
: 2001
(ISO/IEC
14598-4
: 1999
)
ソフトウェア製品の評価−
第 4 部：取得者のプロセス
Software engineering
−Product evaluation−Part 4 : Process for acquirers
序文 この規格は，1999 年に発行された ISO/IEC 14598-4, Software engineering−Product evaluation−Part 4 :
Process for acquires
を翻訳し，技術的内容及び規格票の様式を変更することなく作成した日本工業規格であ
る。
なお，この規格で点線の下線を施してある
参考
は，原国際規格にはない事項である。
1.
適用範囲 この規格は，既製ソフトウェア製品，注文ソフトウェア製品又は既存のソフトウェア製品
への修正部分の取得におけるソフトウェア製品品質の体系的な測定，
総合評価及び評価のための要求事項，
推奨事項及び要領を含む。この規格は，ISO/IEC 9126-1 に規定されたソフトウェア品質モデルを使用し，
JIS X 0133-1
に定義された一般的なソフトウェア製品評価プロセスを拡張し，JIS X 0160 に定義された取
得のプロセスを使用している。この規格は，JIS X 0152，JIS X 0133-2，JIS X 0133-3 及び ISO/IEC 14598-6
と併せて使用することができる。この規格と JIS X 0133-5 の評価プロセスのステップは類似しているが，
しかし利用状況はかなり異なる。取得者が第二者機関又は第三者機関に評価を依頼する場合には，JIS X
0133-5
の適用が求められ，ソフトウェアパッケージの品質要求に対する第三者試験を要求する場合には
JIS X 0152
が適用される。
参考 ここでの第二者機関とは，評価者となり得る関係者のうち，ソフトウェアを購入又は利用する
組織の評価部門をいう（JIS X 0133-5 5.2.2 参照）
。
備考 この規格の対応国際規格を，次に示す。
なお，対応の程度を表す記号は，ISO/IEC Guide 21 に基づき，IDT（一致している）
，MOD
（修正している）
，NEQ（同等でない）とする。
ISO/IEC 14598-4, Software engineering
−Product evaluation−Part 4 : Process for acquires (IDT)
この規格に記述された評価プロセスはまた，単一製品の受入れの決定，又はいくつかの候補製品の中か
ら製品を選択するための助けとなる。
評価プロセスは，アプリケーションの性質及び完全性水準によって修整してもよい。また費用対効果の
点から，ソフトウェア製品の広範な種類と用途に適応させるために十分な柔軟性を備えている。
この規格は，プロジェクト管理者，システム技術者，ソフトウェアの開発・保守担当技術者，ソフトウ
ェア製品の取得を計画している最終利用者及びそれらの製品を提供する供給者を対象としているが，それ
に限定されるものではない。
この規格の評価プロセスの対象となるソフトウェア製品は，より大きなシステムの構成要素として統合
されるもの又は単独で使用されるものを示す。これらは次のように分類される。
2
X 0133-4 : 2001 (ISO/IEC 14598-4 : 1999)
a)
商用既製ソフトウェア製品。
b)
他の用途に利用するために又は広範な汎用のアプリケーションに利用するために，開発又は取得され
た既存のソフトウェア製品。
c)
注文ソフトウェア製品又は既存のソフトウェア製品への修正部分。
この規格で定義された評価プロセスは CASE ツールにも適用可能である。CASE ツールの評価は JIS X
0132
に示されているので，CASE ツールは，この規格の適用範囲に含まれないものと考える。
この規格は，他の規格とともに働くように設計されている。完全性要求の高いシステムには，例えば IEC
60880
，DOA-167A，MOD-55 などの特定の産業部門に固有な規格からの追加的な要求を，この規格に定義
された評価プロセスに含めてもよい。
2.
適合性 推奨という一般的な性質によって，利用者に選択の自由があるので， この規格に適合してい
る
という単純な主張には，意味がない。取引きの条件として，この規格の適用を義務付けようとするい
かなる組織も，6.1.1 に示す必須の目的を満たす評価プロセスを仕様化し，公表する責任がある。仕様化さ
れた評価プロセスは，この規格の特定の適用に適合するための条件を構成する。この規格の 6.及び 7.に示
すすべての活動の適用可能性を考慮しなければならない。取得プロセスの実行過程において，評価プロセ
スへの要求が契約として確立される。したがって，この規格に記述された評価プロセスへの適合は，容易
に確立される。
3.
引用規格 次に掲げる規格は，この規格に引用されることによって，この規格の規定の一部を構成す
る。この規格の制定時点では，次に示す版が有効であった。この規格に基づくことに同意した関係者は，
次に示す規格の最新版が適用できるかを調べるとよい。日付の伴わない引用の場合には，引用した規格の
最新版を適用する。
ISO/IEC 9126-1, Software engineering
−Product quality−Part 1 : Quality Model
JIS X 0160 : 1996
ソフトウェアライフサイクルプロセス
備考 ISO/IEC 12207 : 1995, Information technology−Software life cycle processes がこの規格と一致
している。
JIS X 0133-1 : 1999
ソフトウェア製品の評価−第 1 部：全体的概観
備考 ISO/IEC 14598-1 : 1999, Information technology−Software product evaluation−Part 1 : General
overview
がこの規格と一致している。
JIS X 0133-5 : 1999
ソフトウェア製品の評価−第 5 部：評価者のプロセス
備考 ISO/IEC 14598-5 : 1999, Information technology−Software product evaluation−Part 5 : Process
for evaluators
がこの規格と一致している。
JIS X 0134 : 1999
システム及びソフトウェアに課せられたリスク制御の完全性水準
備考 ISO/IEC 15026 : 1998, Information technology−Software integrity−System and software integrity
levels
がこの規格と一致している。
4.
定義 この規格の目的として，以下の定義が適用される。この規格に使用する他の規格からの主要な
定義は引用を簡便にするために，
附属書 A に再定義されている。
3
X 0133-4 : 2001 (ISO/IEC 14598-4 : 1999)
4.1
商用既製ソフトウェア [commercial-off-the-shelf software (COTS)] 市場ニーズに依存して要求仕
様が定められ，市販によって入手可能で，幅広い一般消費者によって利用に適していることが示されてい
るソフトウェア。
備考 IEEE Std 1062-1993 の定義も参照する。
4.2
注文ソフトウェア (custom software) 利用者の要求仕様から特定のアプリケーションのために開
発されたソフトウェア。
4.3
既存のソフトウェア (existing software) 既に開発され入手でき，そのまま又は修正によって利用
可能で，供給者，取得者，又は第三者によって提供されたソフトウェア製品。
備考
既製品 (off-the-shelf product)
の定義も参照する (JIS X 0160 : 1996)。
5.
ソフトウェア製品の評価−一般的考慮
5.1
評価プロセスと取得プロセスとの相関 次に要約されている（JIS X 0160 で定義されている）取得
プロセスの活動は，6.及び 7.にある一般的評価プロセス活動（JIS X 0133-1 で定義されている）と結び付け
られる。6.は，商用既製ソフトウェア製品の取得における最終製品品質の評価への適用に焦点をあててい
る。7.は，注文ソフトウェアの取得又は既存のソフトウェアへの修正中における評価プロセスの適用に焦
点をあてている。
a)
開始−取得する製品のソフトウェア要求事項，取得計画並びに受入れ方針及び受入れ基準の識別。
b)
提案要求（入札要求）の準備−取得要求事項の仕様及び文書。
c)
契約準備及び更新−供給者の選択，契約準備及び交渉並びに契約変更制御。
d)
供給者の監視−ソフトウェア製品の受入れ及び納入までの契約実行中に実施される評価活動。
e)
受入れ及び完了−最終ソフトウェア製品の受入れ及び納入時に実施される活動。
JIS X 0133-1
に定義されている一般的評価プロセスは，JIS X 0160 と同様には定義されていないが，各
ライフサイクルプロセスで実施される plan-do-check-act (PDCA) サイクルの
check
部分に相当する基本
的な機能として定義されていることに注意する。しかし，一般的評価プロセスは JIS X 0160 のどのような
プロセス（すなわち，開発，保守，取得，妥当性確認）で実施してもよい。つまり，JIS X 0160 で用いら
れる
プロセス
の意味とは抽象化の水準が異なっている。
この区別は，一般的評価プロセスを実施する際には重要である。取得者は，取得時に評価要求を達成す
るために従う評価プロセス及び取得プロセスの両方を定義する必要がある。より大規模なシステム開発の
状況において，実施される取得及び評価活動は，他の開発及び統合活動に統合される必要があり，JIS X
0133-2
に明示されたようにプロジェクト測定計画において識別される必要がある。すなわち，特定の取得
における評価のための考慮事項には，次の点を含む。
・ 評価に必要なソフトウェア要求仕様は，提案要求（入札要求）で求められた取得要求の基礎になり得
る。
・ ソフトウェア製品及び提供者を事前に選択するために，個別に予備的評価活動が必要かもしれない。
・ 評価のための供給者及び製品情報に対する要求は，取得要求又は契約準備中に明示する必要がある。
・ 提案書評価の一部として契約実行の監視中に，製品開発の一部として正式な製品受入れの一部として
又は製品納入の後に評価活動を実行できる。
5.2
評価プロセスの入力
4
X 0133-4 : 2001 (ISO/IEC 14598-4 : 1999)
5.2.1
システム要求 対象ソフトウェアの評価要求を決定する開始点は，全体的なシステム要求から始ま
る。システム要求は，製品又はシステムの機能的及びその他の要求に加えて，製品が使用される環境を含
め，利用者，利用者の目標，作業及び特性を識別する。それらのシステム要求は，後続のシステムアーキ
テクチャ設計，ソフトウェア要求仕様及びソフトウェアアーキテクチャ設計の基礎になる。取得及び評価
プロセスの厳格さ及び正式さに影響がある場合には，この段階で関連した法的要求にはどのようなものが
あるかを識別する必要がある。
システム要求の展開及び設計の過程で，システム要求は，ハードウェア及びソフトウェアの構成品目に
割り付けられ，さらにシステムの手順を含む利用者の操作にも割り付けられる。システム開発ライフサイ
クルの中の設計活動の結果として，既製ソフトウェア製品を取得するか又は再利用するかという決定が行
われる。評価作業は，意思決定プロセスの中のある役割を果たすこともあるので，実際にはこれらの設計
活動の一部である。取得するソフトウェア製品の評価を個別に実行する。最終製品のシステム統合及びシ
ステム試験において，ソフトウェア構成品目は，他のソフトウェア及びハードウェア構成品目と統合され
る（JIS X 0160 参照）
。
図 1 は，評価及び取得のためのより大きなシステムエンジニアリング環境を表して
いる。
この規格において利用及び取得するソフトウェア製品の候補は，構成要素としてより大きなシステムに
統合されるもの又は単独で使用されるものである。それらは，次のように分類される。
a)
商用既製ソフトウェア製品
b)
他の用途又は汎用的な用途のために，開発又は取得された既存のソフトウェア製品
c)
注文ソフトウェア製品又は既存のソフトウェア製品に修正を加えたもの
より大きなシステムに統合されるソフトウェア構成品目の場合は，ソフトウェア要求は，品目毎に定義
する必要がある。その他の場合には，システム構成品目とソフトウェア構成品目は一致し，同一のものと
考えてもよい。
取得されるハードウェア構成品目は，ファームウェア（すなわち，ROM，PROM）に常駐するオペレー
ティングシステムなどのソフトウェアを含んでもよい。このように既存のソフトウェアがハードウェアの
一部をなすとき，通常はハードウェア構成品目とともに評価する必要がある。
5
X 0133-4 : 2001 (ISO/IEC 14598-4 : 1999)
図 1 ソフトウェア製品の評価及び取得のためのシステムエンジニアリング環境
5.2.2
完全性水準の要求 ソフトウェアが，受入れ可能な制限として通常以上の安全，機密，財務，環境
及び社会にかかわるシステムのリスクを含んで重要なものである場合，その要求される完全性水準は，調
達及び評価に先立って確立し，適切に文書化されていなければならない。完全性水準を決定するための手
引きは，JIS X 0134 で提供されている。完全性水準の結果は，評価プロセスの中でソフトウェアをどのよ
うに扱うかを決定する。
5.2.3
ソフトウェアの要求仕様 ソフトウェア要求は，適切に定義された品質モデルを用いて定義しなけ
ればならない。この目的のために，他のモデルを用いる特別の理由がないならば，ISO/IEC 9126-1 の品質
モデル及び定義を使うのがよい。このモデルは，ソフトウェアの利用に関する機能性，信頼性，使用性，
効率性，保守性及び移植性の 6 つの品質特性に大分類し定義している。これらはさらに，測定可能又は総
合評価可能な属性をもつ副特性に分解することができる。
要求は，利用者の必要性に直接関係する外部測定法で定義するのがよく，さらに要求仕様に文書化する
のがよい（外部測定法は ISO/IEC TR 9126-2 に定義されている）
。利用者必要性の文書化は，必要な機能要
求及び性能要求の非公式なリストを作成することから，製品（又は製品が組み込まれている場合はシステ
ム）の完全な要求仕様を準備することまで変化があり得る。要求仕様は，取得プロセスの入札ステップで
用いる取得要求の基となるかもしれないし，それに対する後続の製品評価を実施するための基となっても
よい。
5.2.4
他者による評価 実際の評価プロセスの範囲は，結果が信頼できる限りにおいて，第二者機関又は
第三者機関によって実施された評価活動の結果を利用することによって軽減することができる。そのよう
な評価活動は，事前認証，製品評価及び／又はプロセスアセスメントなどを含んでもよい。例えば，次の
ようなものがある。
・ 製品開発のためのソフトウェアエンジニアリングプロセスは，JIS X 0160，JIS Z 9900-3 又はその他の
規格の要求事項に合致するように標準化するかもしれない。
・ 供給者の品質システムは，それに基づいてソフトウェアが開発される場合には，第三者機関が JIS Z
6
X 0133-4 : 2001 (ISO/IEC 14598-4 : 1999)
9901
の要求事項に対して認証するかもしれない。
・ ソフトウェア製品は，第二者機関又は第三者機関が，JIS X 0133-5 又は JIS X 0152 の要求事項に対し
て評価するかもしれない。
・ 受入れ可能な製品開発のための供給者のソフトウェアプロセス能力は，第三者機関が TR X 0021-8 に
対して総合評価するかもしれない。
・ ソフトウェアは，より大きなシステム開発段階の一部として機能的に評価するかもしれない。
・ ソフトウェア製品は，異なる完全性要求をもつ他の用途のために事前に評価するかもしれない。
・ 製品の評価は，非公式又は公式な評価活動を通して，組織内の他の機関によって実施するかもしれな
い。
対象となるアプリケーションの外部評価結果を入手し解釈するのに必要な追加の費用と時間は，この方
法の実現可能性に影響するかもしれない。外部評価結果の適切な信用を得るために，評価者又は供給者に
意見を聞く必要があるかもしれない。
備考 供給者のソフトウェアエンジニアリングプロセス，供給者の品質システム又は供給者の能力に
ついての評価結果単独では，ソフトウェア製品が要求された品質特性を備えていることを実証
するための十分な基準とはならない。他の製品評価方法（例えば，最終利用者の要求に見合う
品質の要因及び属性明確に及び要素に特別な測定）の実行が必要である。
5.3
修整 評価プロセスは，取得要求，完全性要求及び評価者の具体目標に広範に適用可能である。例
えば，次のようなものがある。
・ ソフトウェアパッケージの取得者は，JIS X 0152 だけを用いてソフトウェアパッケージの評価を望む
かもしれない。
・ ソフトウェア製品の取得者は，独立した評価のために JIS X 0133-5 を用いるかもしれない。
・ 小規模又は単独の取得者は，評価のための最小限の文書を用いて，略式の評価プロセスを要求するか
もしれない。
・ 流通ソフトウェアでは，
評価プロセスの具体目標は，単にある製品を幾つかの類似製品の中から選び，
試験し及び取得することかもしれない。それゆえ公式の取得プロセスは，完全な購入に軽減され，ま
た契約準備を含まない。
評価プロセスは，各アプリケーションの独自性に適応するため，不必要又は価値を生まない作業を回避
するため，ソフトウェアに要求された信用を確立するための実際的な手段を提供するために，柔軟性をも
つのがよい。ソフトウェアに要求される完全性水準は，評価プロセスの厳格さ及び公式さをほとんど決定
する。
取得プロセスは，
又 JIS X 0160 で規定されている修整の手引きを使用する評価プロセスのために修整し，
そして取得する特定ソフトウェア製品に要求される完全性水準に基づくことができる。高い完全性要求を
もつソフトウェアシステム全体の取得は，通常，対応する供給プロセス活動及び作業とともに，JIS X 0160
に規定されているすべての取得活動及び作業を，用いるであろう。一般に，完全性水準が高くなるにつれ
て，厳格さの度合いを高め取得プロセスに関連する活動及び作業の数を増やすのがよい。
附属書 B の表 B.1 は，対象ソフトウェアの完全性水準の要求にしたがった，統合された取得プロセス活
動及び評価プロセス活動の修整の例を示している。
7
X 0133-4 : 2001 (ISO/IEC 14598-4 : 1999)
6.
既製ソフトウェア製品の取得における評価 JIS X 0133-1 に定義された一般的なソフトウェア製品評
価プロセスは，主要な 4 ステップからなる。この規格は，特に既製品を取得するときの最終製品の品質評
価に焦点を当てて，まとめ詳細化している。しかし，これは特定の品質特性に対する中間製品の評価をあ
らかじめ除外するものではない。それゆえに，評価のステップを実行する際の詳細は異なっていても，JIS
X 0133-1
に述べられている詳細と矛盾するものではない。評価プロセスのステップ及び主要な作業，並び
に入力及び出力を
表 1 に示す。
表 1 既製品取得時の評価プロセス
入力
評価ステップ
主要な作業
出力
シ ス テ ム 要 求 又
は ソ フ ト ウ ェ ア
要求
評価要求の確
立
(6.1)
具体目標，目的及び範囲を仕様化する。評価の厳密
さを仕様化する。評価への入力を識別する。
他者によって実施された又は実施される評価を識別
する。後続する取得プロセスを識別し，どのように
して評価への入力要求を供給者へ伝えられるかを識
別する。
評価要求仕様
評価要求仕様
評価の仕様化
(6.2)
ソフトウェア製品の特性に相関する測定法を選択す
る。
評定水準を確立する。最も効果的な評価方法の組合
せを選択する。
特定の環境でのソフトウェア製品の品質の総合評価
に貢献する，異なった品質特性及びその他の観点か
らの評価結果を集約するための手順を確立する。
評価仕様
評価仕様
評価の設計
(6.3)
評価方法及び評価スケジュールを記述した評価計画
を準備する。
評価活動と取得活動との間の接点を識別する。
評価計画
評価計画
評価の実施
(6.4)
選択した評価活動を実施し，ソフトウェア製品の合
目的性を決定するために評価結果を分析し記録す
る。製品使用上の制約を設けるために，識別された
欠点及び付加機能の影響を分析する。製品の受入れ
可能性及び購入するか否かの最終的な結論を記述す
る。
評価記録及び結
果
6.1
ステップ 1−評価要求の確立
6.1.1
評価の目的及び範囲の確立 評価プロセスは次の事柄を確立しなければならない。
a)
ISO/IEC 9126-1
の品質モデル及び定義を用いた一そろいのソフトウェア品質要求。これと比較対照す
ることによって，ソフトウェア製品が使用に適しているということに関して客観的に評価できる。
b)
適切な優先度。これは，各ソフトウェア品質特性について設定するのがよい。
c)
用途の完全性水準に合った，適切な評価のための体系化された基礎。この基礎の中には，評価プロセ
スへの入力及び評価プロセスからの出力，並びに評価活動で要求される厳密さ，又は詳細さの水準に
関しての要求を確立することを含む。
備考 図 2 はソフトウェア製品評価プロセスへの概観を与えている。図は取得者の観点から評価プロ
セスへの入力及び評価プロセスからの結果としての出力に関する異なる側面を示す。
d)
後続する取得プロセス及び評価への入力要求を供給者へ伝達する方法。
備考 附属書 C 中の図 C.1 の評価が取得プロセスと結合した例を参照。
e)
次の各項を考慮した評価の範囲，目的及び具体目標。
1)
ソフトウェア製品を，特定の用途，特定の用途の収集又は一般的な用途，のうちのいずれに使用す
8
X 0133-4 : 2001 (ISO/IEC 14598-4 : 1999)
るか。
2)
評価を第二者機関又は第三者機関が行ったかどうか，若しくは評価活動を後で行う計画をしている
か。
6.1.2
評価要求の仕様化 評価要求仕様は，次の事項を識別するのがよい。
a)
利用者及びその目標，作業，特性並びに製品の利用者環境。
b)
ソフトウェアの用途の完全性水準（ソフトウェア誤りによって発生するリスク）及びそのために評価
プロセスに要求される厳密さに関しての水準。
c)
規則事項の要求（
（ある場合には）製品品質の保証を規則上管理するために，どのような文書類を要求
するか）
（ISO/IEC 9126-1 にある適合性を参照）
。
d)
製品の境界及びインタフェース。これらはソフトウェア製品に対するインタフェース要求を含む（す
なわち，インタフェースを通して送られるデータのタイプ，データ形式，インタフェースアクセス機
構，故障／誤り処理，タイミング問題，インタフェース動作問題，並びにインタフェースの状態の依
存関係及び遷移）
（ISO/IEC 9126-1 にある相互運用性を参照）
。
e)
統合化要求。これは製品が大きなシステムの一部であり，他の構成要素又は製品との統合化の要求が
ある場合。
f)
ソフトウェア品質要求。次の事項を含む。
1)
必須の要求及び選択的な要求の区別。
2)
要求の解釈又は理解に必要なすべての仮定，例外，限界，除外又は未解決の問題。
3)
すべての重要な品質特性への利用者要求及びそれらの優先度（すなわち，保守性を重要と考える場
合は，特定の保守性の要求を識別する）
。
4)
すべての設計上及び環境上の制約（すなわち，ソフトウェア製品を使用することにより課せられる
機能又は性能の限界，利用者がその適用分野のために用いる他の既存のソフトウェア，注文ソフト
ウェア及びハードウェアとソフトウェア製品を統合化する際の水準及び複雑さ）
。
5)
すべてのプロジェクト管理上の制約（すなわち，評価活動を実行するための資源及び専門技術・知
識の利用可能性，スケジュール及び予算の許容範囲，発生する可能性のある依存関係又はリスク，
重要な仮定，若しくは評価作業自体の仮定）
。
6)
ISO/IEC 9126-1
に定義されている品質モデル以外の品質モデルを使用する場合の理由。
g)
評価すべき供給者のサービス［すなわち，支援能力，応用（ソフトウェア）開発能力及び教育訓練能
力］
。
h)
評価すべき特別な要求（すなわち，特定の技術的な実現可能性の問題又は設計実施上の質問など）
。
i)
相互に矛盾せず（すなわち，矛盾しない要求）
，かつ，アプリケーションの完全性水準とも矛盾しない
評価要求。
j)
製品が将来の適用分野及び将来の製品評価を支援するため必要な文書化に再利用されるか。
k)
取得プロセス及び提供時に供給者から要求される情報。
l)
製品評価の労力を軽減するために，他の第二者機関又は第三者機関により実施された評価。
備考 評価要求仕様の詳細水準及び完全性は，評価の完全性に直接影響する。すなわち，予備要求だ
けに基づく評価は，将来の他の段階でのさらなる作業を指示し，問題点を予測し，又はあるソ
フトウェア製品若しくは供給者を除外するために評価結果が使用されるかもしれない。しかし，
それだけでは十分な評価と考えることはできない。これらの評価は，一般的には主要な評価活
動の前に，適切な設計活動又は計画活動の一部として実行される。また，幾つかの評価作業が，
9
X 0133-4 : 2001 (ISO/IEC 14598-4 : 1999)
評価要求が完成する前にもまた求められる場合がある。
図 2 取得者からみたソフトウェア製品評価プロセスの概観
6.2
ステップ 2−評価の仕様化 適切な資格をもつ要員であれば，評価プロセスを繰り返して実施でき，
その結果同様な評価を得ることができるように，評価仕様を文書化するのがよい。
6.2.1
測定法の選択 評価仕様は次の事項を識別するのがよい。
a)
評価される製品の特性。
b)
ソフトウェアが利用されるとき，品質の測定可能な品質と相関する外部測定法（
附属書 B の表 B.2 の
例は，外部測定法及び受入れ可能な基準を示す。経験に基づいた実際の受入れ判断をするための値の
定義は，利用者に任されていることに注意する。これらの値に対して厳密で，不変の規則がないため
である）
。
c)
評価対象のソフトウェアを含むシステムの品質についての利用者の視点と相関する
利用時の品質
の測定法（
附属書 B の表 B.3 の例参照）。
d)
受入れ可能な範囲を表現するような測定法に関する満足できる判断基準［例えば，与えられた品質特
性及び与えられた完全性水準に対して，正当な程度の保証を与えるために，どれくらいの量の運用履
歴が必要かということ（運用履歴の詳細については
附属書 D.4 及び D.5 を参照のこと）］。
e)
パッケージ化された評価モジュール。
f)
他者が事前に実施した評価を審査した後に必要となる，評価要求に対する評価の網羅度の水準。
g)
評価によって回答するチェックリスト。
h)
質問に回答するための助けとなるような一連の例。
10
X 0133-4 : 2001 (ISO/IEC 14598-4 : 1999)
i)
利用するテストケース。
j)
収集及び分析するデータ及びデータ形式。
k)
利用する特定の評価方法，それは次の一つ以上の審査又は総合評価を含む。
1)
ソフトウェア製品の利用者及び技術文書（オンライン文書を含む）
（
附属書 D1 参照）。
2)
供給者の講習及び教育訓練に基づいたソフトウェア製品評価（
附属書 D2 参照）。
3)
中間ソフトウェア製品を含むソフトウェアエンジニアリングプロセス（
附属書 D3 参照）。
4)
供給者側の製品運用履歴（
附属書 D4 参照）。
5)
顧客側の製品運用履歴（
附属書 D5 参照）。
6)
供給者の能力，支援及び品質システム（
附属書 D6 参照）。
7)
プロトタイピング又は他の評価方法（
附属書 D7 参照）。
8)
製品の欠点一覧及び関連する情報（通常はウェブサイトに掲載されている）
。
l)
評価結果を総合評価するための方法。
m)
類似製品から一つの製品を選択するとき，選択ができるよう，総合評価を順位付けするのに適切な方
法。
n)
一つ以上のソフトウェア製品を比較するために利用できる，評定の方式。その評定方式は，品質特性
の優先順位に一致させて重み付けをしてもよい。
6.2.2
評価方法の選択 製品を選択できるようにするため又は製品を利用目的に適応させるために，一組
の評価方法の組合せを仕様化するのがよい。評価される分野には次のものが含まれる。
a)
考慮した幾つかのものが互いに矛盾しないか。
［例えば， 選択された（総合評価の）方法の費用は予
算内に収まりますか？ と， その方法はすべての評価要求を網羅的に割り当てていますか？ は，両
立しないかもしれない］
。この例の場合，評価要求に優先順位をつけて必要な交換条件を用意すること
は評価者に委ねられる。
備考 附属書 B の表 B.4 は，費用及び有効性によって，ソフトウェア品質特性に対する評価方法の順
位付けの例を示す。
b)
次のことを考慮して選ばれた方法の組合せにより，
評価が，適切な網羅度又は適用範囲を提供するか。
1)
ソフトウェアが仕様を満足することを実証する方法。
2)
追加の信用を提供するための，何種類かの評価方法が網羅する範囲の重複。
3)
一連の活動が，全体として，対象にしているソフトウェアの品質特性に対して受入れ可能な水準で
完全な網羅を行っているという保証を，与えているか。
4)
評価方法の間で互いに補完し合う程度。
5)
特性の多様性を明らかにするときの，各評価方法の有効性及び目的性。
6)
評価方法の中の多様なアプローチ（例えば，審査，分析及び試験に基づく評価方法）
。
7)
システム開発のライフサイクル全体の一部として最終的に実行される，そのアプリケーションに関
するどのような評価活動にも信用を与えること。
8)
他者による評価に信用を与えること。
c)
追加評価の際に，機能的に適合している製品の選択肢を絞り込むために，審査，調査，同僚又は利用
者の逸話として伝えられる経験，流通雑誌の製品審査，入手可能な製品の利用者用文書，あるいは製
品審査のデータベースリポジトリのような， 非公式な
予備評価活動の利用。
6.2.3
他者による評価 他者による評価を信用する前に，次のことを考慮するのがよい。
a)
評価において，用途の完全性水準に見合った厳格さの評価要求に対応しているか。
11
X 0133-4 : 2001 (ISO/IEC 14598-4 : 1999)
b)
評価報告書において，総合評価しているソフトウェア製品の版数，評価の範囲，利用した判定基準及
び到達した結論を識別しているか。
c)
評価報告書において，ソフトウェア製品又はソフトウェアエンジニアリングプロセスのあらゆる欠点
を識別し，これらの欠点に対処する是正活動を推奨しているか，及び是正活動が実行されたか。
d)
評価者が次のような適切な専門知識をもっていたか。
1)
評価及び分析を実行した経験
2)
国際的に認められた標準に関係したソフトウェア品質にかかわる経験
3)
ソフトウェアエンジニアリングに関する専門知識
4)
供給者からの完全な独立性
6.3
ステップ 3−評価の設計 製品の評価計画では，次のことを識別するのがよい。
a)
供給者又は第三者機関にその意思があり，要求された文書，設備，ツール，ソフトウェア，講習及び
／又は教育訓練，並びにこれらにかかわる費用を提供することができるか。
b)
あらゆる機密情報又は専有情報へのアクセスの規制に関するすべての条件。
c)
供給者又は第三者機関にその意思があり，質問に対して答えることができる正確な専門知識をもった
個人を提供することができるか，及びこれらに関する交通費も含めた費用がいくらかかるか。
d)
評価者が，評価要求に基づいて評価を実行する際に求められる専門知識，及びこの特別な専門知識の
獲得に関するあらゆる費用。
e)
製品が全範囲に及ぶ試験を行うに足ることを確立するためのあらゆる事前試験。
f)
評価を実行するための試験環境（例えば試験機器，支援設備，ツール，専門家）の提供に関するあら
ゆる費用。
g)
評価の責任及び要求されたスケジュールに対する責任。
h)
品質を保証する際に用いる評価方法のあらゆる限界又は欠点，及びそれらの限界又は欠点が計画以外
のどこかで網羅されるか（例えば，その評価方法では，特定の品質特性については，すべての副特性
を網羅できない）
。
i)
利用する様々な評価方法間のあらゆる相互依存性，すなわち，評価方法の最適な順序の確立を示す順
序依存性（ある試験で得られた情報が別の試験に役立つかもしれない）
。
j)
必要な資源，評価全体に要する費用及び各評価方法の費用。
k)
評価活動と取得活動との接点
（評価プロセスと取得プロセスの組合せ例は，
附属書 C の図 C.1 を参照）。
l)
評価プロセスにおいて，いつ及びなぜ，評価が完了したとみなすのがよいか（すなわち，受入れ又は
拒絶の基準）
，及び評価を中止した方がよいかの判断時点。
m)
各評価活動について計画される次の事項。
1)
従った方がよい手続き及び技法。
2)
情報の入力及び出力，並びに必要な文書。
3)
作成するあらゆる文書についての，様式及び内容に関するあらゆる要求。
n)
評価計画を定義する際に行う通常でない又は例外的なあらゆる決定の背後にある，理論，正当性及び
仮定が文書化される。
o)
評価ツール。
p)
測定法の開発及び妥当性確認，並びに評価プロセス，測定法及び測定値の標準化のための手続き。
備考1. ISO/IEC 14598-6は，特定の評価技法又は評価方法を適用した，品質特性の特定の観点からの
評価を実行するのに必要なすべての情報を体系的に収集するための評価モジュールの概念を
12
X 0133-4 : 2001 (ISO/IEC 14598-4 : 1999)
定義している。
2.
評価方法についての日程計画を行うとき，様々な評価方法間に高い相互依存性があることを
理解することが重要である。すなわち，ある方法で得られた情報は，他の方法が評価の焦点
とするところに影響するかもしれない。評価の反復性から情報の獲得に伴い課題は見直され
るかもしれない。したがって，評価の実施に伴い評価計画も同様に見直されるかもしれない。
例えば，評価が進むにつれ，より詳しい水準の評価を不要な要求とみなしたり追加の要求と
みなしたりすることがよく起こるかもしれない。
3.
ソフトウェア製品の評価は，開発のライフサイクルの異なる時点における段階で，又はライ
フサイクルの一つの時点で一度だけ実行されるかもしれない。個々人又は個々のグループが
異なる部分の評価の実行に責任をもつかもしれない。複数の段階で評価を実行する場合，評
価活動のステップは，追加作業が必要なくなるまで各段階で繰り返される（
附属書 E の段階
的な評価プロセスの例を参照）
。
6.4
ステップ 4−評価の実施
6.4.1
評価方法の実施
a)
次のような目的のために評価を実行し，記録し，分析するとよい。
1)
ソフトウェア製品が評価要求を満たすことが可能であるという，適切な信用を確立する。
2)
評価要求に関連する特定の欠点及びこれらの欠点の範囲を決めるために必要な追加の評価を識別す
る。
3)
ソフトウェア製品を利用するときに設定されている特別な限界又は条件を識別する。
4)
評価自体の弱点又は欠落，及び必要となる追加の評価を識別する。
5)
評価によって網羅されないソフトウェア製品の利用に対する付加機能を識別する。
b)
評価の実行に対する記録は，次の事項を識別するのがよい。
1)
評価計画で述べられた手続きに従った評価の実行。
2)
評価手続きの段階的実行（利用されるデータ，設定手順，あらゆる状態情報を含む）
，評価結果（す
べての質問に対する回答及び回答の出所への参照）及びソフトウェア製品の改訂番号。
3)
規定時間外のソフトウェア製品の利用，構成，修正又は一般的な保守による影響を含む，評価活動
でのあらゆる限界，強制，欠点又は除外。
4)
評価者及び評価者の資格。
5)
総合評価される製品版と対応する評価への入力（すなわち，文書又は講習）との間の相違。
6)
欠点に遭遇したときの解決方法又は
回避策 。
6.4.2
評価結果の分析 評価活動を分析するための記録は，次のことを識別するのがよい。
a)
各々の欠点，あらゆる関連する分析及び各々の欠点がどう解決されたか。欠点の解決には次のような
事実を含むかもしれない。
1)
他の評価方法の一つがその欠点が重要ではないという保証を与えていること。例えば，広範囲の運
用履歴が，欠点のあるソフトウェアエンジニアリングプロセスを補うかもしれない。
2)
満足できる
回避策
が，欠点の影響を軽減することを発見できること。例えば，製品の修正，不
必要な機能を無効にする又は取り除く，あるいはリバースエンジニアリングの利用により不足して
いる設計要求を再生する。
3)
当初の要求は必須事項ではなく，欠点も受入れ可能であること。
4)
欠点は，ソフトウェア製品の利用が特定の条件又は限界によって制御されるならば，受入れ可能で
13
X 0133-4 : 2001 (ISO/IEC 14598-4 : 1999)
あること。
5)
評価における欠点又は相違を解決するために，追加の評価作業が要求されること。
b)
あらゆる識別された欠点を解決するために追加の評価を実行する。追加の評価には次の目的を含む。
1)
欠点の適用範囲又は影響を決定すること。
2)
欠点はないという信用を確立すること。
3)
一つの回避策が技術的に矛盾しない，及び／又は適切で受入れ可能なことを検証すること。
4)
欠点を是正するために，一回以上の設計変更が行われたソフトウェアの性能が，是正されている及
び受入れ可能であることを検証すること。
c)
ソフトウェア製品の利用を制限する又は制御する必要がある場合，次のような限界があるかどうか。
1)
アプリケーションの必須の要求を満たすことが，そのソフトウェア製品を妨害する。
2)
アプリケーションの設計，予算及びスケジュールに影響を与える。
3)
追加の評価作業を要求する。
4)
アプリケーションのあらゆる故障の可能性を示唆する。
d)
評価の適用範囲からのあらゆる除外，及び／又は各々の評価の結果における制限とは，次のようなも
のを示す。
1)
この評価は，製品の機能性の詳細な審査を含んでいない。又は，
2)
このソフトウェア製品は，製品に対する要求された機能性の十分な評価が成功裏に完了したという
前提の基に，要求される完全性水準に達していると考えられる。
e)
ソフトウェア製品の評価に対する全体的な結論を認めるために，すべての評価活動の統合された結果
が作成される。
6.4.3
結論の記述 結論は，用途の完全性水準及び実際の評価要求を考慮に入れて，ソフトウェア製品が
意図した用途の利用に当たって妥当，かつ，適切かどうかを述べるとよい。ソフトウェア製品が，発見さ
れた欠点又は評価情報の不足によって，そのまま利用できないならば，対象とする用途のソフトウェア製
品のさらに詳しい評価を行うか，利用の制御又は制限を設けるなどの勧告を行う必要がある。
結論は， 要求への適合声明 を用いることで正式なものとなるかもしれない。これには，利用されるソ
フトウェア製品の特徴，機能又はサービスという特定の要求を満たしていること，及びその要求に合致し
ていることを適切な信頼度で提供している評価方法を明記する。設計の多様性の導入，構成上の冗長性，
完全性確認のインタフェース及び復旧技術のような発達の可能性のある設計戦略は，ソフトウェア製品の
欠点又は起こり得る故障を補うかもしれない。
評価は，ソフトウェア製品の利用を受け入れないという決定，又は評価要求に適合させることを試みな
いという決定に終わる可能性がある。その場合には，ほかの試みでの再評価を推薦するという決定になる
可能性がある。最終的な決定は，それを買うのか買わないのかということである。
買うという決定は，製品受け入れ試験という形態の，可能な追加の評価を伴いそのソフトウェア製品の
購入契約をするという結果になる。
買わないという決定は，ソフトウェア製品の変更，注文ソフトウェア製品の開発，又は要求そのものを
変えるということを含む，可能な代替手段を選ぶという結果になる。
14
X 0133-4 : 2001 (ISO/IEC 14598-4 : 1999)
7.
注文ソフトウェアの取得及び既存のソフトウェアの修正における評価 ここでは，注文ソフトウェア
の取得又は既存のソフトウェアの修正における，評価プロセスの適用に焦点を当てる。
附属書 C の図 C.2
は，注文ソフトウェア及び既存のソフトウェアの修正における，取得プロセス及び評価プロセスの組合せ
の例を示している。
7.1
ステップ 1−評価要求の確立 6.1 で定義されている評価要求の確立のためのプロセスを，この場合
にも適用する。評価要求は，事前に選択された供給者に，提案要求の一部として送付されるかもしれない
取得要求のための基になる。既存のソフトウェアの修正では，評価は，ソフトウェア製品の変更された部
分及びそのインタフェースに主眼を置く必要がある。
提案要求に先立ち，事前に選択された供給者に対する，供給者の能力，品質プログラム及びソフトウェ
アエンジニアリングプロセスに基づいて予備評価を遂行するのがよい。
7.2
ステップ 2−評価の仕様化 6.2 は，既製ソフトウェアの評価を述べていたが，これを注文ソフトウ
ェア及び既存のソフトウェアの修正に対しても適用する。しかし，中間製品の品質を測定することで最終
製品の品質を予測するために，供給者の開発プロセスの一部として，追加の測定が，要求される。JIS X
0133-3
は，開発期間中の中間製品品質を測定するための，要求事項及び手引きを規定する。
7.3
ステップ 3−評価の設計 6.3 は，次の追加留意事項とともに，注文ソフトウェアの取得及び既存の
ソフトウェアの修正に適用する。
入札期間中の供給者の選択において，対象の完全性要求を達成するために，ソフトウェアの開発又は修
正に先立ち，供給者がソフトウェアエンジニアリングプロセス又は保守プロセスを更新することを，要求
するかもしれない。
要求する評価活動は，その後，供給者の実行プロセスの一部となる。すなわち，供給者の開発実行プロ
セスにおける，検証，共同審査，監査，試験及び妥当性確認の活動。これらの要求は，供給者が従うこと
が要求されている，品質計画又は開発計画において仕様化される。取得者は，供給者と取得者間の契約上
の合意に基づき，供給者の計画の遂行状況を監視し，計画に対する要求を明確にする。
7.4
ステップ 4−評価の実施 6.4 に示す評価の実施のための要求は，実際の評価が，品質計画にしたが
った供給者の実行及び取得者の監視活動を通じて実行されることを除いて，ここでも適用する。ソフトウ
ェア製品受入れ試験の成功は，取得者への製品納入前の必要な基準である。取得者は，製品を使用する前
に，
評価期間中に発見した欠点に対処するためにソフトウェア製品に対する追加の修正を決定してもよい。
関連規格 関連規格及び標準情報を附属書 F（参考）に示す。
15
X 0133-4 : 2001 (ISO/IEC 14598-4 : 1999)
附属書 A（参考） 他の規格での定義
この
附属書 A（参考）は，この規格での用語を示すものであり，規格の一部ではない。ここでは，特に
明示しない限り，JIS X 0133-1 : 1999 の定義を示す。
A.1
取得者 (acquirer) 供給者から，システム，ソフトウェア製品又はソフトウェアサービスを取得又は
調達する組織。
備考 取得者は，発注者，顧客，所有者，利用者又は購入者のいずれであってもよい。 (JIS X 0160 :
1996)
A.2
取得 (acquisition) システム，ソフトウェア製品又はソフトウェアサービスを得るための一連の作業。
(JIS X 0160 : 1996)
A.3
属性 (attribute) 実体の測定可能な物理的又は概念的な特徴。
備考 属性は，内部属性でも外部属性でもよい。
A.4
監査 (audit) ソフトウェア製品及びその作成プロセスが要求事項を満足しているかどうかを，権限
を与えられた者が独立した立場で評価すること (JIS X 0160 : 1996)。
A.5
基準線 (baseline) 構成品目がそのライフサイクル上の決められた時期に媒体に関係なく，正式に指
定し確定された構成品目の正式版として認定されたもの (JIS X 0160 : 1996)。
A.6 CASE
ツール (CASE tool) JIS X 0160 : 1996 で定義されているようなソフトウェアライフサイクル
活動に対して，自動的に支援することでソフトウェア技術者を援助することのできるソフトウェア製品。
備考1. CASE ツールは，限られた機能範囲だけで又は広範な機能範囲で，支援を提供してもよい。
2. CASE
ツールは，次に示すように，多様に使用されるかもしれない。
・ 単独ツールの場合：環境要因との互換性だけに関心を払うのがよい。
・ 相互に直接通信しあう小グループの場合：おそらく自社独自に，事前に統合範囲を明確に
しているものと考えてもよい。
・ ソフトウェアエンジニアリング環境のような大きなフレームワークの存在；フレームワー
クに関連するサービスの利用に関するツールの能力に関心を払うのがよい。 (JIS X 0132 :
1996)
A.7
構成品目 (configuration item) 決められた時点で実利用者が使用する機能を実現し，かつ，全体構
成の中で一意に識別できる
もの
をいう (JIS X 0160 : 1996)。
A.8
契約 (contract) ソフトウェアサービスの提供に関する，又はソフトウェア製品の提供，開発，製造，
運用若しくは保守に関する，法的強制力のある二者間の合意。又は，一つの組織の中で行われる同様の内
部合意。 (JIS X 0160 : 1996)
16
X 0133-4 : 2001 (ISO/IEC 14598-4 : 1999)
A.9
開発者 (developer) ソフトウェアライフサイクルプロセスを通して，開発作業（要求分析，設計及
び受入れテストを含む。
）を遂行する組織 (JIS X 0160 : 1996)。
A.10
直接測定値 (direct measure) 他のいかなる属性の測定値にも依存しないある属性の測定値。
A.11
評価モジュール (evaluation module) 特定のソフトウェア品質特性又は品質副特性のための一組の
評価技術。それには，次のものが含まれる。
・ 評価方法及び技法。
・ 評価への入力。
・ 測定し収集すべきデータ。
・ 受入れ基準。
・ 支援手続き及び支援ツール。
(ISO/IEC 14598-6)
A.12
外部測定値 (external measure) 対象とするソフトウェア製品を含むシステムのふるまいを測定する
ことから導かれるソフトウェア製品の間接測定値。
備考1. システムは，あらゆる関連あるハードウェア，ソフトウェア（注文ソフトウェア又は既製ソ
フトウェア）及び利用者を含む。
2.
試験中に発見された故障の数は，対象プログラムを実行している計算機システムの運用時に
数えられるので，プログラム中の障害の数の外部測定値である。
3.
外部測定値は，設計の本来の目的により近い品質属性を評価するために使うことができる。
A.13
外部品質 (external quality) 製品が指定された条件下で使用された場合に，明示的及び暗示的必要性
を満足させる程度。
A.14
故障 (failure) 前もって指定された限界内で，要求された機能を遂行する品目の能力の停止，又は遂
行の能力がなくなること (JIS X 0134 : 1999)。
A.15
障害 (fault) 計算機プログラム内の不正確なステップ、プロセス又はデータの定義。
備考 この定義は IEEE 610.12-1990 から引用している。
A.16
ファームウェア (firmware) ハードウェア及びハードウェア上に読取り専用ソフトウェアとして組
み込まれた計算機命令又はデータとの組合せ。このソフトウェアは，プログラム制御の下では変更するこ
とはできない。 (JIS X 0160 : 1996)
A.17
暗示的必要性 (implied needs) 対象の実体が特定の条件下で使われるとき，明示されていないが配
慮すべき必要性。
備考 暗示的必要性は，文書化されていないが，実際に必要となる事柄である。
A.18
指標 (indicator) 他の測定値の見積り又は予測に使うことができる測定値。
17
X 0133-4 : 2001 (ISO/IEC 14598-4 : 1999)
備考1. 予測された測定値は，同じ又は異なったソフトウェア品質特性に対するものでもよい。
2.
指標は，ソフトウェア品質特性及び開発プロセスの属性を見積るために使われてもよい。そ
のときには，属性に対する間接測定値である。
A.19
間接測定値 (indirect measure) 1 つ以上の他の属性の測定値から導かれるある属性の測定値。
備考 計算機システムの属性の外部測定値（例えば，利用者からの入力への応答時間のような）は，
ソフトウェアの属性だけでなく，その実行環境の属性の影響を受けるであろうから，ソフトウ
ェアの属性の間接測定値である。
A.20
リスク抑制の完全性水準 (integrity level) システムリスクを受入れ可能な範囲内に維持するために
必要な品目がもつ性質の値の範囲（値域）を表わす表示記号。緩和機能を実行する品目の場合には，その
性質は，当該品目が緩和機能を実行する際に満たさなければならない信頼度とする。自己の故障が危険な
兆候をもたらす可能性のある品目の場合には，その性質は，その故障の発生の上限値とする (JIS X 0134 :
1999)
。
A.21
中間ソフトウェア製品 (intermediate software product) ソフトウェア開発プロセスのある段階の製
品で，他の段階への入力として用いられる製品。
備考 ある場合には，中間製品は，同時に，最終製品でもよい。
A.22
内部測定値 (internal measure) 製品それ自身の測定値で，直接又は間接のいずれでもよい。
備考 コード行数，複雑さの測定値，ウォークスルーで発見された障害の数及びフォグインデックス
(Fog Index)
は，すべて製品それ自身の内部測定値である。
A.23
内部品質 (internal quality) 特定の条件下で使用される場合に，明示的及び暗示的必要性を満たす製
品の能力を決定する，製品の属性の全体。
備考1.
内部品質 (internal quality) という用語は，JIS X 0133群では， 外部品質 (external quality)
と対比する意味で使われており，ISO 8402での
品質 (quality)
と本質的に同じ意味をもっ
ている。
2.
属性 (attribute)
という用語は，4.21 で使用されている
特性 (characteristic)
と同じ意味
で使われており，JIS X 0129 群では 特性 (characteristic) という用語は，より限定的な意味
で使われる。
A.24
測定する［measure（動詞）］ 測定を行う行為。
A.25
測定値［measure（名詞）］ 測定することによって，実体の属性に割り当てられた数又は分類。
A.26
測定 (measurement) 実体の属性に対して尺度から値（数又は分類でもよい）に割り当てるために，
測定法を使う行為。
備考 分類を使うことで，質的な測定を行える。例えば，プログラムの言語（Ada，C，CＯBOL など）
のようなソフトウェア製品の重要な属性は，質的な分類である。
18
X 0133-4 : 2001 (ISO/IEC 14598-4 : 1999)
A.27
測定法 (metric) 定義された測定方法及び測定尺度。
備考1. 測定法には，内部又は外部があり，かつ，直接的または間接的であり得る。
2.
測定法は，定性的なデータを分類するための方法を含む。
A.28
既製品 (off-the-shelf product) 既に開発が終わり，そのままで又は少し手を加えて使用できる状態に
ある製品。 (JIS X 0160 : 1996)
A.29
運用者 (operator) システムを運用する組織 (JIS X 0160 : 1996)。
A.30
品質 (quality) ある もの の明示された又は暗黙の必要性を満たす能力に関する特性の全体。 (ISO
8402 : 1994)
備考1. 契約下において，又は原子力安全性の分野のような法的規制の状況下においては，必要性は
仕様化されるが，それ以外の場合には，暗黙の必要性を明確にし，定めることが望ましい（ISO
8402 : 1994
備考1）。
2.
JIS X 0133
群の中での
もの
とは，ソフトウェア製品を示す。
(ISO 8402 : 1994)
A.31
品質評価 (quality evaluation) ある もの が，規定要求事項を満たすことができる程度の体系的な
審査 (ISO 8402 : 1994)。
備考 製品が契約の下で，特定の利用者向けに開発される場合には，要求事項は，正式に仕様化され
るのがよい。製品が消費者向けソフトウェアのような不特定利用者向けの場合には，要求事項
は，開発組織によって仕様化されるのがよい。比較及び選択を目的として利用者が製品を評価
する場合には，要求事項は，より概括的であってもよい。
A.32
利用時の品質 (quality in use) 指定された利用者が仕様化された特定の仕方で製品を利用したとき，
有効性，
生産性及び満足度に関する仕様化された目標を達成することができる，ソフトウェア製品の能力。
備考1. 利用時の品質は，ソフトウェアを含んだ環境の利用者視点から見た品質であり，ソフトウェ
アそれ自身の特徴というよりは，その環境におけるソフトウェアの使用結果によって測定さ
れる。
2.
現在，JIS X 0133 群での利用時の品質の定義には， 安全性 という新しい特性は含まれてお
らず，指定された利用者が仕様化された特定の仕方で製品を利用したとき，仕様化された目
的を達成するために，有効性，生産性及び満足度を伴い必要性を満たしている程度と定義さ
れている。
3.
ISO 9241-11
における使用性 (usability) は，この規格における利用時の品質の定義と類似し
ている。利用時の品質は，あらゆる品質特性に影響を受けるかもしれないので，この規格で
は，理解性，習得性，運用性，注目性及び適合性からなる ISO/IEC 9126-1 の使用性の定義よ
りも，広範囲である。
(ISO/IEC 9126-1) (
1
)
注(
1
)
作成中である。この規格が発効するまで，JIS X 0129 : 1994を使うのがよい。
19
X 0133-4 : 2001 (ISO/IEC 14598-4 : 1999)
A.33
品質モデル (quality model) 品質要求及び品質評価の基礎を与えるような特性の集合及び特性間の
関係。
A.34
評定 (rating) 測定値を適切な評定水準に対応づける行為。評定は，対象ソフトウェアについて，特
定の品質特性がどの評定水準に対応するかを決定するために行う。
A.35
評定水準 (rating level) 測定尺度を分類するために使われる順序尺度上の点。
備考1. 評定水準は，明示的又は暗示的必要性に基づき，ソフトウェアを分類（評定）することを可
能にする。
2.
適切な評定水準は，例えば，利用者，管理者，開発者のような，異なる品質の視点に関係付
けてもよい。
A.36
提案依頼書（見積依頼書） [request for proposal (tender)] 指定されたシステム，ソフトウェア製品
又はソフトウェアサービスを取得するために，取得者が入札者に対しその意図を伝えるために用いる文書
(JIS X 0160 : 1996)
。
A.37
尺度 (scale) 定義された特徴をもつ値の集合。
備考 尺度の種別の例を次に示す。
・ 分類の集合に対応する名義尺度。
・ 尺度上の点の順序に対応する順序尺度。
・ 等間隔の尺度上の順序に対応する間隔尺度。
・ 等間隔の尺度上の点だけでなく絶対値に対応する比率尺度。測定法は，定性的なデータを扱
う場合には，名義尺度又は順序尺度を用い，定量的なデータを扱う場合には，間隔尺度又は
比率尺度を用いる。
A.38
ソフトウェア (software) 情報処理システムに関する，プログラム，手続き，規則及び関連する文書
の全体又は一部 (JIS X 0001 : 1994)。
備考 ソフトウェアは，記録媒体によらない知的な創造物である。
A.39
ソフトウェア製品 (software product) 計算機プログラム，手続き並びにその関連する文書及びデー
タを含めたまとまり。
備考 製品は，中間製品，開発者，保守者などの利用者向けに作成された製品を含む。
(JIS X 0160 : 1996)
A.40
供給者 (supplier) 取得者と契約を交わし，その条項に基づいてシステム，ソフトウェア製品又はソ
フトウェアサービスを提供する組織。
備考1.
供給者
という言葉は，受注者，製作者，販売者又は納入者と同義である。
2.
取得者は，自組織の一部を供給者として指定する場合がある。
(JIS X 0160 : 1996)
20
X 0133-4 : 2001 (ISO/IEC 14598-4 : 1999)
A.41
システム (system) 一つ以上のプロセス，ハードウェア，ソフトウェア，設備及び人を統合化して，
規定のニーズ又は目的を満たす能力を提供するまとまり。 (JIS X 0160 : 1996)
A.42
利用者 (user) 特定の機能を遂行するために，ソフトウェア製品を使う個人。
備考 利用者には，オペレータ，ソフトウェアの結果の受入者，ソフトウェアの開発者又は保守者を
含めてもよい。
A.43
妥当性確認 (validation) 定められた用途に対する特有の要求事項が満たされていることを，客観的
証拠の調査及び提出によって確認すること。
備考1. 設計及び開発において，妥当性確認は，使用者の必要性への適合性を確定するため，製品の
検討プロセスに関係する。
2.
妥当性確認は通常，最終製品について規定の運用条件の下で実施される。これは，もっと早
い段階で行うことが必要なこともある。
3.
妥当性確認済
という用語は，妥当性が確認された状態を示すために用いられる。
4.
複数の異なった用途があるとき，複数の妥当性確認が実施されることがある。
(ISO 8402 : 1994)
A.44
検証 (verification) 規定要求事項が満たされていることを，客観的証拠の調査及び提出によって確
認すること。
備考1. 設計及び開発において，検証は，ある活動に対する規定要求事項への適合性を確定するため，
その活動結果の検討プロセスに関係する。
2.
検証済
という用語は検証された状態を示すために用いられる。
(ISO 8402 : 1994)
21
X 0133-4 : 2001 (ISO/IEC 14598-4 : 1999)
附属書 B（参考） 表
この附属書 B（参考）は，この規格で参考とする表を示すものであり，規格の一部ではない。
表 B.1 対象ソフトウェアの完全性ごとの評価／取得活動の修整例
対象ソフトウェアの完全性
評価／取得
活動
低
中
高
ソフトウェア要求仕様の準備
略式でもよい
必要
必要
取得要求の準備
不要
必要
必要
供給者の事前選択及び見積依頼書の準備
略式でもよい
略式でもよい
略式でもよい
供給者能力の総合評価
不要
不要
不要
供給者のソフトウェアプロセスの評価
不要
不要
必要
実行可能な製品の評価
必要
必要
必要
供給者における製品運用履歴の評価
略式でもよい
必要
必要
顧客における製品運用履歴の評価
略式でもよい
必要
必要
契約の準備
不要
必要
必要
正式な製品の受入れ試験
不要
必要
必要
追加の評価
不要
略式でもよい
必要
備考1. 完全性が低いソフトウェアの例は， 包装済みの ワープロ又はスプレッドシートのソフトウェアである。し
かし，スプレッドシートのソフトウェアが，化学プロセスプラントの重要な安全性パラメータを計算するの
に使用されるならば，例えば計算の意味が変わるなどの，機能の削減による完全性水準が減少しない限り，
ソフトウェアの完全性水準を増加させる必要がある。
2.
完全性が中のソフトウェアの例は，制御能力はもたずプラントの監視システムで使用される，グラフィカル
ユーザインタフェース (GUI) のソフトウェアである。
3.
完全性が高いソフトウェアの例は，航空管制システムで使用される UNIX オペレーテイングシステムのソフ
トウェアである。
22
X 0133-4 : 2001 (ISO/IEC 14598-4 : 1999)
表 B.2 仕様化されたソフトウェア品質特性，品質副特性，外部測定法の例
対 象 ソ フ
ト ウ ェ ア
の完全性
優先付けされた品質特性 選択された品質副特性
選択された外部測定法
受入れ可能な基準
1.
機能性
正確性
事前に計算し期待された結果に対
する，正しい結果の数
95%
2.
使用性
運用性
審査されたメッセージの総数に対
する，受信し明確に評価されたメッ
セージの数
80%
低 3.移植性
設置性
新規のプラットフォームに技術伝
達する場合に，モジュール総数に対
して，再コンパイルが必要なモジュ
ール数
6
モジュール未満
4.
効率性
時間効率性
システム活動の開始からシステム
応答の受信までの経過時間
5
秒未満
5.
信頼性
障害許容性
入力誤りの数に対する，誤りを検出
した故障の数
25%
6.
保守性（要求されない） −要求されない−
−要求されない−
−
1.
信頼性
可用性
特定の運用期間中の平均故障時間 6 か月より長い
2.
機能性
合目的性
必須要求の総数に対して，ソフトウ
ェア要求仕様で実現された必須要
求の数
100%
高 3.保守性
変更性
識別された類似の変更に対して，変
更が要求されるモジュールの数
1
4.
効率性
資源効率性
最悪の運用条件下で，特定の運用上
の CPU の使用率
80%
5.
使用性
理解性
特定の結果を導くためにソフトウ
ェアをどのように使用するかを，特
定の利用者が学ぶのに要求される
時間
10
分未満
6.
移植性
−要求されない−
−要求されない−
−
23
X 0133-4 : 2001 (ISO/IEC 14598-4 : 1999)
表 B.3 仕様化されたソフトウェアの利用時品質の測定法の例
利用者
外 部 品 質 目
標の特性
利用時品質の属性
利用時の測定値例
受入れ基準
有効性（目標を達成するため
の正確性及び完全性に関連
した利用システム／製品の
目標）
− 表示結果を処理する際の失敗
の数
− 転記された文書における特定
の形式から逸脱した数
− 0 に近いほどよ
い
− 0 に近いほどよ
い
効率性（精神的又は物理的労
力の消費に関連して達成さ
れた有効性の水準）
− 作業時間及び利用者時間の労
働費用
− 使用された資源及び設備の費
用
− 利用者によって要求されたあ
らゆる教育訓練の費用
− 少 な い ほ ど よ
い
− 少 な い ほ ど よ
い
− 少 な い ほ ど よ
い
オペレータ
及び最終利
用者
機能性，信頼
性，使用性，
効率性
満足度（利用の快適性及び受
入れ可能性）
− 利用者の相互作用の満足度の
アンケート
− 利用中の否定的コメントに対
する肯定的コメントの率
− 認識する作業量のアンケート
− 高いほどよい
− 高いほどよい
− 利 用 者 種 別 毎
の 母 集 団 の 平
均
有効性（目標を達成するため
の正確性及び完全性に関連
した利用システム／製品の
目標）
− 変更要求毎に影響されるモジ
ュール数
− 設置を試みた回数に対して，設
置が成功した回数
− 少 な い ほ ど よ
い
− 1.0 に近いほど
よい
効率性（精神的又は物理的労
力の消費に関連して達成さ
れた有効性の水準）
− 作業時間及び利用者時間の労
働費用
− 使用された資源及び設備の費
用
− 利用者によって要求されたあ
らゆる教育訓練の費用
− 少 な い ほ ど よ
い
− 少 な い ほ ど よ
い
− 少 な い ほ ど よ
い
保守者，設
置者
保守性，移植
性
満足度（利用の快適性及び受
入れ可能性）
− 利用者の相互作用の満足度の
アンケート
− 利用中の否定的コメントに対
する肯定的コメントの率
− 認識する作業量のアンケート
− 高いほどよい
− 高いほどよい
− 利 用 者 種 別 毎
の 母 集 団 の 平
均
表 B.4 評価方法の費用−有効性による順位の例
ソフトウェア品質侍性ごとの評価方法の有効性の順位
評価の方法
費用の順位
機能性
信頼性
使用性
効率性
保守性
移植性
最終製品の文書，講習及び教育訓練
低
高
低
高
中間
低
高
中間製品
高
低
中間
低
中間
高
高
運用履歴−供給者
中間
中間
高
低
低
中間
中間
運用履歴−顧客
中間
高
中間
高
中間
高
高
備考1. この表は，関連する有効性及び特定の製品品質特性に関連する評価方法の費用に関連する全体の質的な概算
順位付けを示す。この有効性の順位付けは，その評価が成功裡に処理されること及び厳密さの程度の適切さ
を仮定している。この表は，ソフトウェア要求仕様で仕様化されたものに対する製品品質特性の適切さを，
十分に総合評価されるために評価されることが必要な，対象の入力を選択するために使用できる。要求され
た評価は，製品評価の費用全体を見積るために使用できる。
2.
費用及び効率性の順位は，実行された評価の程度に関連しているようにみえる。
24
X 0133-4 : 2001 (ISO/IEC 14598-4 : 1999)
附属書 C（参考） 図
この附属書 C（参考）は，この規格で参考とする図を示したものであり，規格の一部ではない。
図 C.1 既製品に対する評価／取得プロセスの例
25
X 0133-4 : 2001 (ISO/IEC 14598-4 : 1999)
図 C.2 注文ソフトウェア又は既存のソフトウェアの変更における評価／取得プロセスの例
26
X 0133-4 : 2001 (ISO/IEC 14598-4 : 1999)
附属書 D（参考） 評価方法
この附属書 D（参考）は，この規格で参考とする評価方法を示すものであり，規格の一部ではない
D.1
利用者及び技術的な製品文書（オンライン文書を含む）の審査 製品文書は，移植性及び保守性のよ
うな他の事項だけでなく，機能性及び使用性についても，評価を実行するために必要なすべての情報を提
供していることがある。実際に製品を購入することなく，適切なソフトウェア製品文書にアクセスする方
法として，文書類を借用する，又は文書のセットを購入することが可能な場合がある。ソフトウェア製品
文書の審査は，製品についての講習又は教育訓練を受けるほどには有効ではないかもしれないが，特に評
価者が適切な専門知識を有している場合には，最も経済的な方法になることがある。
D.2
供給者の講習及び教育訓練に関する評価 製品の講習は，供給者によるものか，第三者機関によるも
のかを問わず，多数のソフトウェア製品において提供されている。講習が存在しないソフトウェア製品の
場合は，そのソフトウェア製品の使用経験がある利用者又は開発者から特別な教育訓練を受けられるよう
に折衝できることがある。製品の講習又は教育訓練の利点は，特定の範囲に焦点を当て，短期間でそのソ
フトウェア製品の機能性及び使用性についての特定の情報を得ることが，可能なところにある。ソフトウ
ェア文書の審査によって同じ情報を得ることは可能かもしれないが，より多くの時間が必要となることが
ある。講習又は教育訓練に必要な追加費用と，情報入手の効率性及び講習教材の汎用性とを比べて秤にか
ける必要がある。
D.3
ソフトウェアエンジニアリングプロセスの評価 ソフトウェアエンジニアリングプロセスの評価は，
プロセスにより出力される中間製品の詳細な検査により，
ソフトウェア製品品質の決定を行う方法である。
中間製品とは，製品の品質計画，要求仕様，アーキテクチャの記述，詳細設計記述，コード，検証の記録，
妥当性確認の記録，コード点検の記録，試験の記録などをいう。これを達成するには，結果として得られ
るソフトウェア製品の品質において適切な保証を与えられるよう，ソフトウェアエンジニアリングプロセ
スにおける受入れ可能な文書の基準線が，
どのような事項への適合を求めているかを定義する必要がある。
受入れ可能な基準線は，要求された開発及び関連する支援活動を仕様化するために，対象の完全性水準
に対応させて JIS X 0160 の要求事項を修整することで定義することができる。これには次の決定事項を含
む。
a)
要求されるプロセス。
b)
要求されるプロセスの出力文書［JIS X 0133-5 では，附属書（参考）にソフトウェアエンジニアリン
グプロセスを評価するのに使用可能な，製品文書の集合の一覧を示している］
。
c)
プロセス及びプロセスの出力文書に関する要求。
この評価は，TR X 0021-8 で定義されている，供給者のプロセス能力水準の決定と対をなすことがある。
例として，
表 D.1 に定義されているソフトウェアプロセス文書の基準線は，製品が中より高い完全性要求
のある製品で要求されるかもしれない。
27
X 0133-4 : 2001 (ISO/IEC 14598-4 : 1999)
表 D.1 ソフトウェアプロセス文書の基準線
JIS X 0160 : 1996
でのプロセス
出力
JIS X 0160 : 1996
での要求（節）
計画
ソフトウェア品質／開発計画及び支援手続き 7.1.2
システム要求の分析
システム要求仕様 5.3.2
システム要求の検証
検証記録 6.4.2.3
システムアーキテクチャの設計
システム設計の記述 5.3.3
システム設計の検証
検証記録 6.4.2.4
ソフトウェア要求の分析
ソフトウェア要求仕様 5.3.4
ソフトウェア要求の検証
検証記録 6.4.2.3
ソフトウェアアーキテクチャの設計
ソフトウェアアーキテクチャの記述 5.3.5
ソフトウェア詳細設計
ソフトウェア設計の記述 5.3.6
ソフトウェア設計の検証
検証記録 6.4.2.4
ソフトウェアのコーディング
コード 5.3.7
コードの検証
検証記録 6.4.2.5
ソフトウェア単体試験
試験記録 5.3.7
ソフトウェア結合
試験記録 5.3.8，6.4.2.6
ソフトウェアの妥当性確認
試験記録 5.3.9，6.5
システム結合
試験記録 5.3.10
シスアムの妥当性確認
試験記録 5.3.11，6.5
構成管理
計画，状況報告，リリース，変更要求 6.2
教育訓練
教育訓練記録 7.4
高い完全性要求をもつシステムにとっては，追加のプロセス及び製品への要求が，産業分野ごとの規格
により要求されるかもしれない。例えば，IEC 60880，IEC 1508（案）
，DOA-167A，MOD-55 などの規格
である。そして，供給者の品質／開発計画及び関連する方法論の手続きは，対象としている基準線に対す
る供給者の適合性を評価するために使用できる。適合性の水準は，主な欠点の識別及びソフトウェア製品
の品質への潜在的な影響を総合評価することで，決定してもよい。追加の評価又は回避策により，欠点の
影響を示すことができる。
特定の組織及び異なる種別のソフトウェア製品に対して，それぞれ有効なソフトウェアエンジニアリン
グプロセスがあるというプロセスの多様性を認識しているほうがよい。理にかなったソフトウェアエンジ
ニアリングプロセス及び方法の多様性に適応するため，評価プロセスには柔軟性をもたせるのがよい。
そのソフトウェアエンジニアリングの審査は
附属書 E の例に示すように，段階的に行う手法で実施され
ることが推奨される。ソフトウェアの完全性水準がソフトウェアエンジニアリングプロセス全体を通した
評価を要求していないとみなされる場合には，審査は，段階 1 又は段階 2 で終了することもある。
D.4
供給者との運用履歴の審査 供給者との運用履歴の審査は，ソフトウェア製品の品質を示すのに非常
に有効な方法を提供できる。それは，ソフトウェア製品の販売数及びソフトウェアが使用されている業界
及び用途での詳細を審査することで実現できる。この審査はまた，ソフトウェアの改訂の履歴，改訂版の
保守の仕方，利用した顧客からの欠点報告の対処の仕方及び既知の欠点の詳細を明確にする。審査を実施
するために最も便利な方法は，供給者のエンジニア，販売員及び顧客の支援スタッフにインタビューする
こと，及びあらゆる支援記録を調査することである。
D.4.1
運用履歴の要求
a)
販売数は，少なくとも 6 か月前のものがよい。すなわち，評価で使用する販売数は，評価の実施時点
より前の過去 6 か月に販売されたものだけにするためである。
この基準は，
ソフトウェア製品を納入，
28
X 0133-4 : 2001 (ISO/IEC 14598-4 : 1999)
設置，委託及びサービスを開始するには 6 か月かかる場合があるという事実に基づいている。
b)
ソフトウェア製品は，少なくとも一つの大きな改版が実施され，その改定版について利用中の運用履
歴のデータがあるのがよい。これは，ソフトウェア製品の品質は実施された改良の合計に依存すると
いう仮定に基づいている。
c)
ソフトウェア製品の利用者が供給者に欠点の報告を提供する方法が存在し，欠点の報告及び実施され
た対処の結果についての証拠が存在する。
D.4.2
運用履歴の審査 製品の運用履歴の審査は，次のことを調査判断するのがよい。
a)
そのソフトウェアが他の製品を変更して作成されたかどうか，及び製品の運用履歴は使用可能かどう
か。これは，ソフトウェア製品に対する変更の数及び変更された範囲を別な方法で調べている。
b)
ソフトウェア製品のユニット運用年数 (the number of unit-years of operation)。これは，次の手順で計算
する。
1)
年間販売数 (sales year) の計算＝（初期販売［初年度の販売総数］＋現時点より過去 6 か月前まで
の累積数計［ユニットが運用可能となるのに通常 6 か月の遅延が必要との仮定による］
）
*
（ソフト
ウェア製品の市場での年数）／2
2)
ユニット運用年数の計算＝（年間販売数
*
使用率 (duty cycle)［ソフトウェアが運用されている時間
の割合］
*
実際に運用されているユニットの割合［これは，例えば，ホストのハードウェア用のユニ
ットとして多くの予備が保持されているファームウェアについては適切な扱いである］
）
。
c)
運用経験は，用途で要求される機能性に適切に対応しているという証拠を提供しているか。例えば，
他の顧客によっても同様の用途で使用されているか。
d)
運用経験は，ソフトウェア製品の機能性が幅広く役立っている証拠を提供しているか。例えば，多く
の用途及び産業界で広く使用されているか。
e)
ソフトウェアの改版ごとの，及びそのソフトウェア製品の特別な付加機能ごとのユニット運用年数。
f)
改版間での差分，変更の範囲及びその変更が区別されているか。
g)
運用履歴データを裏付ける文書化された証拠が存在するか。
h)
ソフトウェア製品の改版と関連するハードウェアの改版との対応が，どのように制御及び追跡されて
いるか。
i)
ソフトウェア製品の特定の改訂版を指定した注文及び現行の最新版ではない版の注文が可能か。
j)
顧客からの欠点報告を受付及び対処する供給者のプロセス。
k)
顧客はすでに報告済みの欠点についても遅れなく知ることができるか。
l)
そのソフトウェアでの未解決の欠点及びその影響すべて。
D.5
顧客との運用履歴の審査 アプリケーションの一つとして評価対象のソフトウェア製品を利用してい
る又は利用していた実際の顧客とともに運用履歴を審査することにより，実際の運用条件下での特定の質
問に対して比較的偏見のない回答を評価者は得ることができる。顧客の適用方法が提案された適用方法と
どのように類似しているかによって，全体の品質又は特定の機能に対して得られた保証は，プロトタイピ
ング又は広範囲な試行利用から得られるのと同程度に役立つ場合がある。審査を実施する最も便利な方法
は，運用の現場での顧客へのインタビュー及び可能ならばデモンストレーション又は支援記録を見ながら
の，顧客へのインタビューである。
顧客との運用履歴の審査を実施する評価者は，次のことを行うのがよい。
a)
顧客の適用方法と提案された適用方法との類似性の度合いを明確にする。
29
X 0133-4 : 2001 (ISO/IEC 14598-4 : 1999)
b)
運用中のソフトウェア製品を見て調べる又は他の運用を裏付ける証拠を得ることを試みる。
c)
供給者から提供される運用支援の形式及び品質に関して顧客に質問する。
d)
誤ることなく行える操作の合計を調べて判断する。
D.6
供給者の能力，支援及び品質システムの審査 供給者の支援能力及びソフトウェアを保守する能力の
水準の評価は，次のことに着目するのがよい。
a)
財政状態，経験及び能力。
b)
構築用ツール，使用されるオペレーティングシステム及び他の構成要素／ライブラリの保守と使用を
含む，製品の開発環境支援。
c)
インタフェース規格を含む，他の製品又は製品グループへの製品のインタフェース。
d)
第三者機関の参加に対する対応。
e)
製品支援に対する十分な資源提供の約束。
f)
継続している支援を正当なものにするのに十分な顧客への配慮。
g)
バグを解決し，環境面で支援するために十分な保守サービス。
h)
設置されたものについての適切な参照。
i)
形式化された十分なリリース，並びに改訂の制御手続き及び実行の証拠。
j)
形式化された再帰試験及び設計変更の正式な評価。
k)
文書化及び実行された，問題の報告及び解決の手続き。
l)
実施されている品質システム。
m)
ハードウェア及びソフトウェアに対して用いられた規格。
n)
将来の開発に対する計画。すなわち，現在の市場での位置に関連づけて実施している戦略。
o)
製品保証。
D.7
プロトタイピング及び他の評価方法
D.7.1
プロトタイピング プロトタイピングは，評価の一手法である。プロトタイピングは，要求の解決
又は要求の微調整，ソフトウェア製品の使用上の技術的な実現可能性の決定，若しくは特定の機能性又は
使用性についての要求及びそれらの実現に関連する不明点又は技術的な危険の除去を行うために用いるこ
とができる。プロトタイピングは，ソフトウェア製品の全機能を利用できるようにしてもよいし，しなく
てもよい。又，アプリケーションの要求のすべてを明確にしてもよいし，しなくてもよい。
プロトタイピングは，供給者に専門の設備，人員，及び文書へアクセスできるようにすることを要求す
る場合がよくあることに注意するのがよい。これらの費用及びスケジュール，並びに特殊な環境条件又は
特別なサービスのような他の要因について，ソフトウェア製品のプロトタイピングの実現可能性を判断す
る際に考慮するほうがよい。
評価に対する一般的な要求に加えて，プロトタイピングは，次のことをするのがよい。
a)
総合評価された要求を明確に表明した例を用いること，並びに重要な運用のパラメータを再現するこ
と，及びシミュレーションを現実的に提供すること。
b)
第三者機関により再現できるように適切に文書化する。
c)
利用可能ならば，提案された適用方法に対して適切な履歴データを使用するのがよい。
30
X 0133-4 : 2001 (ISO/IEC 14598-4 : 1999)
D.7.2
他の評価方法 JIS X 0133-5 の附属書（参考）では，評価水準及びソフトウェア品質特性に属する評
価技法の一覧を示している。評価水準は，評価のための完全性水準に対応させることができる。追加の評
価方法は，次のことを含む。
a)
ソフトウェアアーキテクチャ設計の分析（保守性）
。
b)
ソフトウェアの故障の木解析（安全性，信頼性）
。
c)
ソフトウェア製品の試験に基づく統計的なランダム使用（信頼性）
。
d)
構文及び意味の正確性を確認するためのコードの動的分析（信頼性）
。
e)
ソフトウェア設計の危険要素分析（安全性，信頼性）
。
f)
ソフトウェア要求仕様の審査（機能性）
。
g)
コードの点検（機能性）
。
h)
ソフトウェアのブラックボックス試験（機能性）
。
i)
ベンチマーク試験（効率性）
。
j)
要求の追跡可能性の分析（保守性）
。
k)
構成要素間のインタフェースでの障害のシミュレート（堅固性）
。
完全性の高い複雑なソフトウェアのためには，ソフトウェア設計の故障の木解析又は危険要素分析は，
評価のための
重大な
ソフトウェアモジュールの分離に使用できる。これにより，アプリケーションの
完全性に影響を与えないソフトウェアについては，厳密な評価の実施を不必要とすることができる場合が
ある。
31
X 0133-4 : 2001 (ISO/IEC 14598-4 : 1999)
附属書 E（参考） 段階的な評価プロセスの例
この附属書 E（参考）は，この規格で参考とする段階的な評価プロセスの例を示すものであり，規格の
一部ではない。
段階的な評価の例は，三つの対象分野の各段階で要求される関連する作業を示している。
E.1
段階 1：計画−要求段階
E.1.1
製品文書，講習及び教育訓練 この範囲での幾つかの審査は，ソフトウェア製品の基本機能を確認
する又は決定するために，通常ほとんど最初に行われる。この最初の審査は，他者によって行われるかも
しれない。完全性水準次第で，この非公式な評価又は予備評価を文書として記録することを考慮するのが
よい。
E.1.2
ソフトウェアエンジニアリングプロセス 要求段階の時点で，ソフトウェア製品の品質計画又は開
発計画の審査によりソフトウェアエンジニアリングプロセスの評価を始めることは，通常はソフトウェア
製品にとって有効である。これは，完全性水準に対応して要求される特性を満たすような文書及び手続き
をソフトウェアエンジニアリングプロセスが提供できるかどうかを，幾つか示唆するであろう。適切なら
ば，他のプロセス評価の審査をすることで，この作業を補足することを考慮してもよい。
一般的な特性及び要求は，この時点で考慮するのがよい。次の点にも着目するのがよい。
a)
要求された文書に供給者の文書が正確に一致することが必要かどうか。
b)
ソフトウェアエンジニアリングプロセスの評価において，プロセス全体でのそのプロセスの位置づけ，
そのプロセスに至る以前のステップの重要性及びプロセスへの入力の品質に着目する。
E.1.3
運用履歴 供給者及び適切な顧客との運用履歴の最初の審査は，将来の評価作業に要求される早め
の示唆を提供できる。例えば，短期間の運用履歴及び／又は少数の適切な顧客では，プロトタイピング，
外部評価審査又はソフトウェアエンジニアリングプロセス評価の厳密さの度合いを増加させる必要がある
と考慮するようになるかもしれない。
E.2
段階 2：設計−取得段階
E.2.1
製品文書，講習及び教育訓練 ソフトウェア製品に要求されている機能性に対するより集中的な審
査は，このフェーズで必要となる。製品の講習又は製品文書が，要求された機能性を実証するために利用
できなければ，適切な顧客の運用履歴をより厳密に審査することを企画するのがよい。
E.2.2
ソフトウェアエンジニアリングプロセス この段階で，品質計画の実際の導入が評価される。これ
は，識別された一般的な特性に対する適合を確実にするために作成された実際の中間製品の審査を含むだ
ろう。この段階が見積プロセスに一致するならば，時間的要素により，主要な文書の確認だけの審査に制
限されるかもしれない。見積りは常に，契約の締結前にソフトウェア製品の品質計画で参照しているあら
ゆる文書に対する試験も許可するという文言を含むのがよい。
比較的に高価な費用のために，ソフトウェアエンジニアリングプロセスの審査は，運用履歴が製品の信
頼性の保証を提供するのに十分な規模であるとは思われない限り，完全性水準のより低いソフトウェア製
品のためには，通常考慮されないだろう。
32
X 0133-4 : 2001 (ISO/IEC 14598-4 : 1999)
E.2.3
運用履歴 既存ソフトウェア製品の特定の版及び要求された機能に集中している，より広範囲な運
用履歴の審査は，この段階で実施するのがよい。製品の講習，文書及び適切な顧客との運用履歴の審査が，
製品の信頼性及び機能性に関して適切な信用を提供しなければ，プロトタイピングを考慮するのがよい。
E.3
段階 3：完全な評価段階
E.3.1
製品文書，講習及び教育訓練 製品文書の審査又は講習への出席による製品の機能性に対する評価
は，以前の段階で実施されていなくても，完了させるのがよい。
E.3.2
ソフトウェアエンジニアリングプロセス このフェーズは，各プロセス又は製品の特定の要求が供
給者の要求に対比されているかの，ソフトウェアエンジニアリングプロセス全体の評価を伴うだろう。次
の点を追加して考慮する。
a)
供給者のソフトウェアエンジニアリングプロセスが要求の意図にしたがっているかいないかを決定す
るために，各要求を明確にするのがよい。このことは，供給者のソフトウェアエンジニアリングスタ
ッフへのインタビューによって，容易に判断できる。したがって，見積プロセス中にそれを決定する
ことは，適切でないか又は効果的ではない。
b)
供給者の要員は，その製品が適切な品質にあるとの証拠の提示を求められるかもしれない。基準線の
ソフトウェアプロセスでは，網羅されていない領域を照らすという見通しを提供するかもしれない。
評価者にはすぐには判らないが，基準線のソフトウェアプロセスの特定の領域とそのプロセス部分を
関係付けるのに役立つかもしれない。
c)
幾つかの要求は，主観性の要素をもち評価者による解釈を要求されるだろう。その要求の目的を満た
す多様な方法が存在するかもしれない。
d)
審査は，ソフトウェア製品の改訂の履歴を確立し，改版間の変更範囲を決定するのがよい。これには，
報告された欠点の試験を含むことができる。次の点を考慮するのがよい。
1)
すべての既知の欠点の状態。
2)
欠点を修正するために実行されたすべての変更に対する審査，評価及び試験の度合い。
3)
現行の設計改版の安定性。
4)
現行の改版日からの経過時間。
5)
変更数並びに規模，又はこれらの変更の大きさ。
欠点が存在するか又は詳細な審査が有効でない場合には，プロトタイピング又はブラックボックス試験
のような追加の評価方法を考慮するのがよい。
E.3.3
運用履歴 運用履歴の評価は，以前のフェーズで実施されていなくても，完了させるのがよい。
33
X 0133-4 : 2001 (ISO/IEC 14598-4 : 1999)
附属書 F（参考） 関連規格
この附属書 F（参考）は，この規格に関連する規格を示すものであり，規格の一部ではない。
ISO/IEC Guide 2 : 1991
General terms and their definitions concerning standardization and related
activities
JIS X 0001 : 1994
情報処理用語−基本用語
備考 ISO/IEC 2382-1 : 1993, Data processing−Vocabulary−Part 1 : Fundamental terms
JIS X 0020 : 1992
情報処理用語（システム開発）
備考 ISO/IEC 2382-20 : 1990, Information processing vocabulary−Part 20 : System development.
ISO 8402 : 1994, Quality management and quality assurance
−Vocabulary
JIS Z 9901 : 1998
品質システム−設計，開発，製造，据付け及び付帯サービスにおける品質保
証モデル
備考 ISO 9001 : 1994, Quality systems−Models for quality assurance in design, development, production,
installation and servicing
JIS X 0152 : 1995
ソフトウェアパッケージ−品質要求事項及び試験
備考 ISO/IEC 12119 : 1994, Information technology−Software packages−Quality requirements and testing
JIS X 0132 : 1996
CASE ツールの評価及び選択のための指針
備考 ISO/IEC 14102 : 1995, Information technology−Guideline for evaluation and selection of CASE tools
Radio Technical Commission for Aeronautics (RTCA) DO-178B/ED12-B, Software Considerations
in Airborne Systems and Equipment Certification
Ministry of Defence (UK) (MOD), Interim Defence Standard, 00-55 (Parts 1,2) /Issue 1, The
Procurement of Safety Critical Software in Defence Equipment
IEC 60880-1986, Software for computers in the safety systems of nuclear power stations
IEEE Std 1062-1993, Recommended Practice for Software Acquisition
34
X 0133-4 : 2001 (ISO/IEC 14598-4 : 1999)
附属書 G（参考） 参考文献
この附属書 G（参考）は，この規格に関連する参考文献を示すものであり，規格の一部ではない。
Tremaine, DR. and de Grosbois, JFP. Guideline for the Qualification of Predeveloped
Software.907-C-H-69002-0201, Ontario Hydro/AECL, April 22,1993.
Ferguson, JR. and DeRiso, ME. Software Acquisition : A Comparison of DoD and Commercial Practices.
CSU/SEI-94-SR-9, Software Engineering Institute, October, 1994.
Baker, ER., Cooper, L., Corson, BA. and Stevens, AE. Software Acquisition Management Maturity Model (SAM
3
).
Program Manager. July
−August, 1994, pp.43-49.
Scott, JA., Preckshot, GG. and Gallagher, JM. Using Commercial
−Off-the−Shelf (COTS) Software in High
Consequence Safety Systems (Draft Preprint). Lawrence Livermore National Laboratory, November, 1995.
Cochrane, Gail. Use of COTS/NDI In Safety
−Critical Systems. (based on original Report prepared for the Federal
Aviation Authority), TRW, 1996.
Brown, AW. and Wallnau, KC. Engineering of Component
− Based Systems. Prroceedings Second IEEE
International Conference on Engineering of Complex Computer Systems. October, 1996.
Bevan, N. and Azuma, M. Quality in Use : Incorporating human factors into the software engineering lifecycle.
Proceedings of the Third International Symposium on Software Engineering Standards. May, 1997.
Voas, J. and Miller, : K. Interface Robustness for COTS-Based Systems. IEE Symposium on COTS and Safety
−
Critical Systems. Savoy Place, London, January, 1997.
原案作成委員会 構成表
氏名
所属
（委員長）
東 基 衛
早稲田大学
（委員）
池 田 幸 男
沖電気工業株式会社
江 崎 和 博
株式会社荏原製作所
遠 藤 和 彦
三菱電機株式会社
神 品 芳 明
株式会社日立製作所
込 山 俊 博
日本電気株式会社
坂 本 健 一
株式会社 NTT データ
田 中 秀 明
情報処理振興事業協会
谷 津 行 穂
日本アイ・ビー・エム株式会社
田 川 淳
通商産業省工業技術院
三 宅 武 司
日本電信電話株式会社
山 田 淳
株式会社東芝
（事務局）
飯 田 登
財団法人日本規格協会（1999 年度）
横 山 繁 盛
財団法人日本規格協会（2000 年度）