← 一覧に戻る ↓ このページの最下段に移る

JIS X 0133-1:1999
ソフトウェア製品の評価−第1部:全体的概観 1999制定

番号 用語 定義 対応英語
4.1 取得者 供給者からシステム,ソフトウェア製品又はソフトウェアサービスを取得又は調達する組織(JIS X 0160 : 1996)。 acquirer
4.2 属性 実体の測定可能な物理的又は概念的な特徴。
備考 属性は,内部属性でも外部属性でもよい。
参考 ソフトウェア製品の場合,実体とは,仕様書,原始プログラム,利用者用文書及びロードモジュール並びにそれを実行するシステムを含む。内部属性とは,仕様書,原始プログラムなどの属性を含み,外部属性とは,利用者が直接使用する実体(利用者用文書,ロードモジュールを実行中のシステムなど)の属性である。
attribute
4.3 開発者 ソフトウェアライフサイクルプロセスにおいて,開発活動(要求分析,設計,試験,受入れまでを含む。)を遂行する組織(JIS X 0160 : 1996)。 developer
4.4 直接測定値 他のいかなる属性の測定値にも依存しないある属性の測定値。 direct measure
4.5 評価モジュール 特定のソフトウェア品質特性又は品質副特性のための一組の評価技術。
備考 評価モジュールは,評価方法及び技法,評価への入力及び測定し収集すべきデータ,並びに支援手続き及びツールを含む。
evaluation module
4.6 外部測定値 対象とするソフトウェア製品を含むシステムのふるまいを測定することから導かれる,ソフトウェア製品の間接測定値。
備考1. システムは,あらゆる関連あるハードウェア,ソフトウェア(注文ソフトウェア又は既製ソフトウェア)及び利用者を含む。
2. 試験中に発見された故障の数は,対象プログラムを実行している計算機システムの運用時に数えられるので,プログラム中の障害の数の外部測定値である。
3. 外部測定値は,設計の本来の目的により近い品質属性を評価するために使うことができる。
external measure
4.7 外部品質 製品が指定された条件下で使用された場合に,明示的及び暗示的必要性を満足させる程度。 external quality
4.8 故障 要求された機能を遂行する製品の能力が尽きる状態,又は事前に仕様化された制限内で機能を遂行する製品の能力がない状態。 failure
4.9 障害 計算機プログラム内の不正確なステップ,プロセス又はデータの定義。
備考 この定義は,IEEE 610.12 : 1990から引用している。
fault
4.10 暗示的必要性 対象の実体が特定の条件下で使われるとき,明示されていないが配慮すべき必要性。
備考 暗示的必要性は,文書化されていないが,実際に必要となる事柄である。
implied needs
4.11 指標 他の測定値の見積り又は予測に使うことができる測定値。
備考1. 予測された測定値は,同じ又は異なったソフトウェア品質特性に対するものでもよい。
2. 指標は,ソフトウェア品質属性及び開発プロセスの属性を見積もるために使われてもよい。そのときには,属性に対する間接測定値である。
indicator
4.12 間接測定値 一つ以上の他の属性の測定値から導かれるある属性の測定値。
備考 計算機システムの属性の外部測定値(例えば,利用者からの入力への応答時間のような)は,ソフトウェアの属性だけでなく,その実行環境の属性の影響を受けるであろうから,ソフトウェアの属性の間接測定値である。
indirect measure
4.13 中間ソフトウェア製品 ソフトウェア開発プロセスのある段階の製品で,他の段階への入力として用いられる製品。
備考 ある場合には,中間製品は,同時に,最終製品でもよい。
intermediate software product
4.14 内部測定値 製品それ自身の測定値で,直接又は間接のいずれでもよい。
備考 コード行数,複雑さの測定値,ウォークスルーで発見された障害の数及びフォグインデックス(Fog Index) は,すべて製品それ自身の内部測定値である。
参考 フォグインデックスとは英文の複雑さを表す指標のことで,仕様書などに適用される。
フォグインデックス=〔(文章当たりの平均語数)+[総語数に対する長語数の割合(%)]〕×0.4
ここで,“文章当たりの平均語数”は,100語以上200語以下のサンプルを取り出したとき,その中の1文章当たりの語数の平均値。“長語数”は,3シラブル以上の語の数(ただし,固有名詞,合成語及びed esの付いた動詞を除く。)。
仕様書又は技術文書では,12から16の値が受容できる範囲とされている。
internal measure
4.15 内部品質 特定の条件下で使用される場合に,明示的及び暗示的必要性を満たす製品の能力を決定する製品の属性の全体。
備考1. “内部品質(internal quality)”という用語は,JIS X 0133群では,“外部品質(external quality)”と対比する意味で使われており,ISO 8402での“品質(quality)”と本質的に同じ意味をもっている。
2. “属性(attribute)”という用語は,4.21で使用されている“特性(characteristic)”と同じ意味で使われており,JIS X 0129群では,“特性(characteristic)”という用語は,より限定的な意味で使われる。
internal quality
4.16 保守者 保守活動を遂行する組織(JIS X 0160 : 1996) 。 maintainer
4.17 測定する 測定を行う行為。 measure (verb)
4.18 測定値 測定することによって,実体の属性に割り当てられた数又は分類。 measure (noun)
4.19 測定 実体の属性に対して尺度から値(数又は分類でもよい。)に割り当てるために,測定法を使う行為。
備考 分類を使うことで,質的な測定を行える。例えば,プログラムの言語(Ada,C,COBOLなど)のようなソフトウェア製品の重要な属性は,質的な分類である。
measurement
4.20 測定法 定義された測定方法及び測定尺度。
備考1. 測定法には,内部又は外部があり,かつ,直接的又は間接的であり得る。
2. 測定法は,性的なデータを分類するための方法を含む。
metric
4.21 品質 ある“もの(entity)”の明示された又は暗黙の必要性を満たす能力に関する特性の全体(ISO 8402 : 1994)。
備考1. 契約下において,又は原子力安全性の分野のような法的規制の状況下においては,必要性は,仕様化されるが,それ以外の場合には,暗黙の必要性を明確にし,定めることが望ましい(ISO 8402 : 1994,備考1.)。
2. JIS X 0133群の中での“もの”とは,ソフトウェア製品を示す。
参考 “entity”の訳語には,情報技術の分野では,“実体”が通常に用いられるが,ここでは,JIS Z 9900 : 1994の“参考品質管理と品質保証の規格−用語”に記載しているISO 8402 : 1994の翻訳を用い,“もの”とした。
quality
4.22 品質評価 ある“もの”が,規定要求事項をどれだけ満たすことができるかの程度を示すための体系的な審査(ISO 8402 : 1994)。
備考 製品が契約の下で,特定の利用者向けに開発される場合には,要求事項は,正式に仕様化されるのがよい。製品が消費者向けソフトウェアのような不特定利用者向けの場合には,要求事項は,開発組織によって仕様化されるのがよい。比較及び選択を目的として利用者が製品を評価する場合には,要求事項は,より概括的であってもよい。
quality evaluation
4.23 利用時の品質 指定された利用者が仕様化された特定の仕方で製品を利用したとき,仕様化された目的を達成するために,有効性,生産性及び満足度を伴い必要性を満たしている程度。
備考 この利用時の品質の定義は,ISO 9241-11における使用性(usability) と類似させている。JIS X 0133群においては,使用性という用語は,JIS X 0129-1に規定されたソフトウェア品質特性を参照して用いられている。
quality in use
4.24 品質モデル 品質要求及び品質評価の基礎を与えるような特性の集合及び特性間の関係。 quality model
4.25 評定 測定値を適切な評定水準に対応付ける行為。評定は,対象ソフトウェアについて,特定の品質特性がどの評定水準に対応するかを決定するために行う。 rating
4.26 評定水準 測定尺度を分類するために使われる順序尺度上の点。
備考1. 評定水準は,明示的又は暗示的必要性に基づき,ソフトウェアを分類(評定)することを可能にする(10.2参照)。
2. 適切な評定水準は,例えば,利用者,管理者,開発者のような異なる品質の視点に関係付けてもよい。
参考 例えば,次のように,それぞれ異なる視点から評定水準を区分する場合もある。
利用者の視点からは,利用時の得失及び影響の度合いに関係付けた水準,
開発者の視点からは,設計目標又は技術的な難易度に関係付けた水準,
保守者の視点からは,問題発生時の保守対応の緊急度に関係付けた水準,
管理者の視点からは,市場の中での位置付けに関係付けた水準。
このようにすると,一つの測定値をそれぞれの異なる品質の視点から解釈することができる。
rating level
4.27 尺度 定義された特徴をもつ値の集合。
備考 尺度の種別の例を,次に示す。
・分類の集合に対応する名義尺度。
・尺度上の点の順序に対応する順序尺度。
・等間隔の尺度上の点の順序に対応する間隔尺度。
・等間隔の尺度上の点だけでなく絶対値に対応する比率尺度。
測定法は,定性的なデータを扱う場合には,名義尺度又は順序尺度を用い,定量的なデータを扱う場合には,間隔尺度又は比率尺度を用いる。
scale
4.28 ソフトウェア 情報処理システムに関する,プログラム,プロセス,規則及び関連する文書の全体又は一部(JIS X 0001 : 1994)。
備考 ソフトウェアは,記録媒体によらない知的な創造物である。
software
4.29 ソフトウェア製品 計算機プログラム,手続き並びにその関連する文書及びデータを含めたまとまり。
備考 製品は,中間製品,開発者,保守者などの利用者向けに作成された製品を含む(JIS X 0160 : 1996)。
software product
4.30 供給者 契約を交わした取得者に,システム,ソフトウェア製品又はソフトウェアサービスを契約に基づいて提供する組織(JIS X 0160 : 1996)。 supplier
4.31 システム 明示的な必要性又は目的を満たす能力を与えるために,一つ以上のプロセス,ハードウェア,ソフトウェア,設備及び人間からなる統合されたもの(JIS X 0160 : 1996)。 system
4.32 利用者 特定の機能を遂行するために,ソフトウェア製品を使う個人。
備考 利用者には,オペレータ,ソフトウェアの結果の受入者,ソフトウェアの開発者又は保守者を含めてもよい。
user
4.33 妥当性確認 定められた用途に対する特有の要求事項が満たされていることを,客観的証拠の審査及び提出によって確認すること(ISO 8402 : 1994)
備考1. 設計及び開発において,妥当性確認は,使用者の必要性への適合性を確定するため,製品の検討のプロセスに関係する。
2. 妥当性確認は,通常,最終製品について規定の運用条件の下で実施される。これは,もっと早い段階で行うことが重要である。
3. “妥当性確認済”という用語は,妥当性が確認された状態を示すために用いる。
4. 複数の異なった用途があるとき,複数の妥当性確認が実施されることがある。
validation
4.34 検証 規定要求事項が満たされていることを,客観的証拠の審査及び提出によって確認すること (ISO 8402 : 1994, 2.17)。
備考1. 設計及び開発において,検証は,ある活動に対する規定要求事項への適合性を確定するため,その活動結果の検討のプロセスに関係する。
2.“検証済”という用語は,検証された状態を示すために用いる。
verification

← 一覧に戻る ↑ このページのトップに戻る