29
X 25040 : 2014 (ISO/IEC 25040 : 2011)
− インタフェース標準(規格)への適合の検証
− 実際の利用者による試用実験の実施
効率性
− 時間測定の実施
− ベンチマーク試験
− アルゴリズムの複雑さを決めるための設計の分析
保守性
− チェックリストで示された開発文書の検査
− コードレビュー及びプログラム規則の検証
− 開発文書の要素間の追跡可能性の分析
移植性
− ソフトウェア設置手順の分析
− プログラム規則の検証
− ソフトウェア設計の分析
――――― [JIS X 25040 pdf 31] ―――――
30
X 25040 : 2014 (ISO/IEC 25040 : 2011)
附属書B
(参考)
評価方法
この附属書Bは,ソフトウェア製品品質評価のために使用することができる評価方法の例を提供する。
B.1 利用者文書及び技術的な製品文書の審査(オンライン文書を含む)
製品仕様は,機能性要求事項及び使用性要求事項と同様に他の論点(例えば,移植性要求事項及び保守
性要求事項)を評価するために必要な全ての情報を提供することができる。実際にソフトウェア製品を購
入することなしに,文書を借りることによって又は一連の文書を購入することによって,関連するソフト
ウェア製品仕様を利用することができる。ソフトウェア製品文書の審査は,講座又は教育訓練を受けるの
と同様の効率は得られないかもしれないが,特に評価者が専門的知識をもっているのであれば,最も経済
的な経験であることが判明するかもしれない。
B.2 供給者の講座及び教育訓練を基にした評価
供給者又は第三者のいずれか一方を通じて,多くのソフトウェア製品に対する製品講座が提供されてい
る。講座が存在しないソフトウェア製品の場合,経験豊かな利用者又はソフトウェア製品の開発者によっ
て,特別な教育訓練が準備される可能性がある。製品講座又は教育訓練が提供する利点は,評価者が特定
の領域に焦点を当てること,並びに短期間にソフトウェア製品の機能性及び使用性に関する特定の情報を
得られるようにすることである。ソフトウェア製品仕様の審査によっても同一の情報を得ることができる
かもしれないが,しかし,審査にはより多くの時間がかかるかもしれない。講座又は教育訓練の追加費用
は,情報獲得の効率性及び講座の教材の一般性に対する重み付けが必要である。
B.3 ソフトウェアエンジニアリングプロセスの総合評価
ソフトウェアエンジニアリングプロセスの総合評価は,プロセスの中間製品,すなわち,製品品質計画,
要求事項仕様,方式記述,詳細設計記述,コードリスト,検証記録及び妥当性確認記録,コード検査及び
試験記録などを検査することによってソフトウェア製品の品質を決定する方法である。これを達成するた
め,結果として生成されるソフトウェア製品の品質を適切に保証するソフトウェアエンジニアリングプロ
セスについて,受入れ可能となる文書の基準を構成する要素が何かを定義することが必要となる。
受入れ可能な基準は,要求された開発アクティビティ及び関連する支援アクティビティを明示するため
に,目標とするインテグリティレベルに合わせるようにJIS X 0160の要求事項を修正することで定義する
ことができる。これは,次のことを決めることからなる。
a) 要求されたプロセス
b) 要求されたプロセスの出力文書
c) プロセス及びプロセスの出力文書への要求事項
この総合評価には,JIS X 0145-2に規定されたように,供給者プロセスの能力水準の評価を加えてもよ
い。JIS X 0160は,ソフトウェア製品のインテグリティレベルの要求事項に従って,適用すべきプロセス
及び期待される成果物を定義するために利用することができる。
注記 ソフトウェアエンジニアリングプロセスの多くのプロセスは,JIS X 0160の実装プロセス,ソ
――――― [JIS X 25040 pdf 32] ―――――
31
X 25040 : 2014 (ISO/IEC 25040 : 2011)
フトウェア実装プロセス及びソフトウェア支援プロセスに規定されている。
高いインテグリティ要求事項のあるシステムでは,追加プロセス及び製品要求事項が,その分野の規格
(例えば,IEC 880,IEC 1508,DOA-167A,MOD-55など)によって,要求されることがある。
その場合,供給者の品質・開発計画及び関連する方法論の手順は,この目標となる規準への供給者の適
合度を総合評価するために利用することができる。その結果,不備を識別し,それらがソフトウェア製品
の品質に影響を与え得る可能性を総合評価することによって,適合度の水準を決定することができる。追
加の評価又は問題の解決によって,不備が及ぼす影響に対処することができる。
特別な組織及び異なる種類のソフトウェア製品に影響を及ぼす,様々なソフトウェアエンジニアリング
プロセスがあることを認識することが望ましい。様々な合理的なソフトウェアエンジニアリングプロセス
及び方法に対応するために,評価プロセスに柔軟性をもたせることが望ましい。
ソフトウェアエンジニアリング審査は段階的な方法でなされることを推奨する。ソフトウェアのインテ
グリティレベルがソフトウェアエンジニアリングプロセスの完全な評価を要求していない場合,審査は第
I段階又は第II段階の後,中止してもよい。
B.4 供給者の運用操作履歴の審査
供給者との運用操作履歴の審査は,ソフトウェア製品の品質を示すのに非常に効果的な方法を提供する
ことができる。このことは,ソフトウェア製品の販売数並びにその製品が利用された産業及びアプリケー
ションの詳細を審査することで実現される。この審査は,ソフトウェアの版の履歴,版が保守された方法,
顧客からの不備報告書を処理した方法,及び不明な不備の詳細についても取り上げている。審査を実施す
るときに最も便利な方法は,供給者の技術担当者,販売担当者及び顧客支援担当者への面談,並びに支援
記録を調べることである。
B.4.1 運用操作履歴の要求事項
a) 販売数は,少なくとも過去6か月の販売数とすることが望ましい。この基準は,ソフトウェア製品が
納入され,設置され,引き渡され,サービスが提供できるまで6か月かかる場合があるという事実に
基づいている。
b) ソフトウェア製品は,少なくとも一つの主要な改訂を経ていることが望ましい。そして,その改訂を
行うために利用できる,運用操作履歴のデータを入手できることが望ましい。このことは,ソフトウ
ェア製品の品質はそれまでに実施された改良の量に依存しているという仮定に基づいている。
c) ソフトウェア製品の利用者が供給者へ不備報告書を提出してフィードバックする方法がある。この場
合,このことが起こったことの証拠及び結果として処置を実施していることを示す証拠がある。
B.4.2 運用操作履歴審査
製品の運用操作履歴の審査では,次のことを決めるのが望ましい。
a) ソフトウェアが他の製品を変更することによって製作されたかどうか,及びその製品の運用操作履歴
は利用することができるかどうか。このことは,ソフトウェア製品に加えられた変更の数及び変更の
程度に依存する。
b) ソフトウェア製品に対する一定年数当たりの運用操作の数。これは,次の手順で算出する。
1) 年間販売数の算出=[初期販売数(最初の年の合計販売数)+現在から過去6か月の最終的な総累
積量(ソフトウェア製品一式が運用操作可能となるまでに,通常6か月の遅れがあることを仮定し
ている。)]×ソフトウェア製品が市場に存在する年数)÷2
2) 一定年数当たりの運用操作の算出=[年間販売数×稼働可能期間(ソフトウェア製品を運用操作で
――――― [JIS X 25040 pdf 33] ―――――
32
X 25040 : 2014 (ISO/IEC 25040 : 2011)
きる状態になっている期間の割合)×実際に運用操作中のソフトウェア製品一式の割合(例えば,
このことは,ファームウェアの入ったハードウェアを複数,予備として保管する場合のあるファー
ムウェアに当てはまる。)]
c) 運用操作経験から,アプリケーションによって要求された機能性に関する証拠が提供されているかど
うか。例えば,他の顧客も同様のアプリケーションを利用しているかどうか。
d) 運用操作経験から,ソフトウェア製品の機能性の広さが活用されていることを示す証拠が提供されて
いるかどうか。例えば,幅広い範囲でのアプリケーション及び産業で利用されているかどうか。
e) ソフトウェアの各版及びソフトウェア製品の各特別な選択肢に対する一定年数当たりの操作の数
f) 版間の違い,変更の程度及び変更が分離されているかどうか。
g) 運用操作履歴データを支援するために,文書化された証拠が存在するかどうか。
h) ソフトウェア製品の版及び任意の関連するハードウェアの版は,どのように管理され,追跡されてい
るか。
i) ソフトウェア製品の特定の版を発注することができるのか及び最新でない版の発注による影響。
j) 顧客から受け取った不備報告書の受諾及び処置のための供給者プロセス
k) 顧客は,遅滞なく,報告された不備についての情報を受け取っているか。
l) ソフトウェアにおける,あらゆる際立った大きな不備及びその影響
B.5 顧客の運用操作履歴の審査
顧客のアプリケーションの一つのソフトウェア製品を利用しているか又は利用したことがある実際の顧
客とともに運用操作履歴を審査することによって,評価者は,実際の運用操作の状態に基づく特定の質問
に対して,比較的公平な回答を得ることができる。顧客のアプリケーションが提案されたアプリケーショ
ンにどのくらい類似しているかに応じて,総合的な品質又は特定の機能性について得られる保証は,プロ
トタイピング又は広範囲な試使用から得られるのと同じくらい役に立つ。審査を実施するために最も都合
のよい方法は,作業現場で顧客と面談すること,及び多分実際の運用操作の実演又は支援記録を調査する
ことである。
顧客とともに運用操作履歴を審査する評価者は,次のことをすることが望ましい。
a) 顧客のアプリケーションと提案されたアプリケーションとの類似度合いを判断する。
b) 運用操作中のソフトウェア製品の観察調査又は他の支援証拠の入手を試みる。
c) 供給者によって提供された支援の形態及び品質について,顧客に質問する。
d) エラーなしに行える運用操作の量を決定する。
B.6 供給者の能力,支援及び品質システムの審査
供給者の支援能力及びソフトウェア保守能力の水準の評価では,次のことに言及していることが望まし
い。
a) 財務面での安定性,経験及び能力
b) 組立ツール,使用されるオペレーティングシステムを含む製品開発環境面の支援,並びに,他の構成
要素及びライブラリオブジェクトの保守及び使用
c) インタフェース規格を含め,他の製品又は製品群への製品インタフェース
d) 第三者の関与についての偶発性
e) 製品支援への十分な資源の貢献
――――― [JIS X 25040 pdf 34] ―――――
33
X 25040 : 2014 (ISO/IEC 25040 : 2011)
f) 継続した支援を正当化するための十分な顧客基盤
g) バグ修正のための十分な保守サービス,環境面の支援
h) 実装された基盤からの適切な参照
i) 形式化された十分なリリース及び版管理手順並びに実践の証拠
j) 形式化された回帰試験及び設計変更の規則に従った評価
k) 文書化され実践された問題報告及び解決手順
l) 機能している品質システム
m) ハードウェア及びソフトウェアに使用される規格(標準)
n) 将来の開発計画,すなわち,現在の市場地位に関係した設定された戦略
o) 製品保証
B.7 プロトタイピング及びその他の評価方法
B.7.1 プロトタイピング
プロトタイピングは,次のことを行うために利用することができる評価の方法である。それは,要求事
項の解決又は微調整をするため,ソフトウェア製品の利用の技術的な実現可能性を見極めるため,又は特
定の機能性若しくは使用性の要求事項及びこれらの実装に関係する未知の要素若しくは技術面のリスクを
取り除くためである。プロトタイピングでは,ソフトウェア製品の機能性の全部を利用できるようにして
もよいし,全てではなく一部を利用できるようにしてもよい。また,アプリケーションの要求事項の全部
を取り上げてもよいし,全てではなく一部を取り上げてもよい。
プロトタイピングは,特殊な装置,要員及び文書の利用ができるようにすることを,供給者にしばしば
要求することに留意することが望ましい。これらの要因及び他の要因(例えば,特別の環境条件,サービ
スなど)についての費用関連事項及び日程関連事項は,ソフトウェア製品のプロトタイプ作成の実現可能
性を調査判断する中で考慮することが望ましい。
評価に対する一般の要求事項に加えて,プロトタイピングでは,次を行うことが望ましい。
a) 評価された要求事項に適切に対応する事例を用いて,重要な運用操作に関する変数の現実的な変更及
びシミュレーションを提供する。
b) 第三者によって繰り返すことができるように適切に文書化する。
c) 利用可能な場合,提案されているアプリケーションに関連する履歴データを使用する。
B.7.2 その他の評価方法
評価技法は,評価水準及びソフトウェア品質特性に関連付けられることができる(附属書D参照)。評
価水準は,評価のためにインテグリティレベルに対応させることができる。追加の評価方法には,次のも
のを含む。
a) ソフトウェア方式設計の分析(保守性)
b) ソフトウェアの故障木分析(信頼性)
c) ソフトウェア製品の統計に基づく無作為の利用に基づく試験(信頼性)
d) 正確さに対する構文及び意味を検査するためのコードの動的分析(信頼性)
e) ソフトウェア設計の危険性分析(信頼性)
f) ソフトウェア要求事項仕様の審査(機能性)
g) コード検査(機能性)
h) ソフトウェアのブラックボックス試験(機能性)
――――― [JIS X 25040 pdf 35] ―――――
次のページ PDF 36
JIS X 25040:2014の引用国際規格 ISO 一覧
- ISO/IEC 25040:2011(IDT)