ソフトウェア品質要因の測定
出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2021/10/17 06:20 UTC 版)
「ソフトウェア品質」の記事における「ソフトウェア品質要因の測定」の解説
ソフトウェア品質の測定には様々な観点がある。しかし、万人が納得する測定の観点は珍しい。人によってはソフトウェア品質の定量的測定が必須であるとされるが、他の人は定量的測定が有効な場面は限られると考えており、そのため定性的測定を好む。真に望ましい測定を行うことの難しさはソフトウェアテストの分野の権威が何人か書いている。例えば、Cem Kaner（英語版） の Software Engineering Metrics: What Do TheyMeasure and How Do We Know? と Douglass Hoffman The Darker Side of Metrics がある。 よく使われるメトリックの例として、検出バグ数がある。バグの少ないソフトウェアはバグの多いソフトウェアに比べて品質が高いとされる。以下のような質問の回答を考えることで、このメトリックが特定の場面で役立つかどうかを考えることができる。 どんなバグが多いのか? ソフトウェアの目的の違いを考慮しているか? ソフトウェアの規模や複雑さの違いを考慮しているか? バグの重大性を考慮しているか? 障害の重大性やユーザーへの影響によって重み付けしているか? もし重み付けしていない場合、100件のバグと1000件のバグのどちらが品質が良いのかをどう判断するのか? 検出バグ数が時と共に減っている場合、その意味をどう判断するか? 例えば、その製品が従来よりも品質が良くなっていると判断できるのか? あるいは、改造を以前ほどしなくなっただけか? あるいは、評価を行う者が変わって以前よりバグを検出できなくなっただけか? あるいは、チームが意図的にバグ数の報告を少なくしようとしているのか? 最後の質問は、特に管理上の難しさを示している。ソフトウェアは人間が作るものであるため、ソフトウェア品質のメトリックは、ある意味で人間の振る舞いを測定することである。チームがバグを過少に報告することで何らかの利益が得られるなら、そのチームは少なくバグを報告する傾向が強くなる。バグ追跡システムを出し抜く方法を見出したり、4、5件のバグを1件の報告にまとめてしまったり、些細なバグを報告しないことで作業量を減らすといったことである。意図したとおりの測定をすることは難しい。特にプログラマや評価者が、意識的か無意識的かに関わらず、測定そのものにゲームとしての誘因を見出さない場合、その傾向がある。例えば、品質保証部門がそのチームの過去のバグ傾向などから新たなソフトウェア開発におけるバグ収束曲線を予測し、実際のバグ報告とその予測を比較することで残存バグ数を見積もるとする。予測が正確であれば学習効果によって実際に報告されるバグ数は予測よりも少なくなる。予測通りのバグ数の報告が無ければ出荷が認められないとすれば、チームがバグ報告を過少に行うことはなくなる。しかし、予測が不正確であれば、実際のバグ数が予測を超過することになり、様々な目先の利害関係からバグを過少に報告するということが発生しうる。 ソフトウェア品質要因はその記述が曖昧であるために測定できない。しかし、機能以外の要求仕様を満たしているかどうかを明らかにするためには、何らかの測定が必要となる。例えば、信頼性はソフトウェア品質の要因のひとつであるが、そのままでは評価できない。しかし、信頼性という属性に関連して測定可能なものが存在する。例えば、障害発生間隔 (MTBF)、障害発生率、システムの可用性などである。同様に、移植性の属性はプログラム内のプラットフォーム依存の文の数で表される。 ソフトウェア品質要因の評価に使われるスキームを以下に示す。それぞれの要因（特性）について、関連する質問群がある。こういった質問への回答に基づいて一種の採点を行うことができ、それによって品質上の特性が定量化される。 理解可能性 変数名はその機能や構造をうまく表現しているか? コメント文を読んでそのコードの意味が明確に理解可能か? データ構造の機能は適切に分割されているか?（構造体が単なる無関係なデータの寄せ集めになっていないかなど） 完全性 通常のシステムには備わっていないサブプログラムが含まれているか? 必要とされるパラメータが全て揃っているか? プログラムに入力しなければならないデータが全て揃っているか? 簡潔性 実行されないコードを含んでいないか? 冗長なコードはないか? ループの外で実行してよいコードをループ内で無駄に複数回実行するようになっていないか? 分岐判定が複雑すぎないか? 移植性 特定のプラットフォームにしかないシステムやライブラリに依存していないか? 機種依存コードが明確化されているか（コメント、ifdefでの切り分けなど）? エンディアンや文字コードに依存していないか? 一貫性 1つの変数名を様々な用途に流用していないか? 定数の表現は一貫しているか? 同じ演算を一貫した表現で行っているか? 字下げスタイルは一貫しているか? 保守性 メモリ容量の一部を将来の拡張のために取ってあるか? 各モジュールの凝集度は適切か? データ構造の変更に容易に対処可能か? 機能の変更にあたって全体の再構成を必要とするか（変更の内容にもよる）? 試験性 コードの構造が複雑でないか? 詳細設計段階で明確な擬似コードが提示されているか? その擬似コードの抽象レベルはどうか? マルチタスクやマルチスレッドの場合、適切なテストが行える手段が整っているか? ユーザビリティ GUIが使われているか? 適切なオンラインヘルプが備わっているか? ユーザマニュアルは提供されるか? エラーメッセージは分かりやすいか? 信頼性 限界値のチェックは行われているか? ゼロ除算が起きないようになっているか? 例外処理を行っているか? 構造化の度合い モジュール分割の大きさは適切か? モジュール間の制御の渡し方は明確で、しかも例外なく守られているか? 効率性 実行時間は最適化されているか? 繰り返し使われるコードのブロックはサブルーチン化されているか? メモリリークが起きないか? セキュリティ 不正なアクセスからデータやプログラム自身が守られているか? セキュリティポリシーを操作者が設定可能か? 適切なセキュリティ機構を備えているか? そのセキュリティ機構の実装は正しいか? 攻撃を想定した設計になっているか? 脆弱性の原因となるような問題（バッファオーバーラン、書式文字列問題など）をはらんでいないか?
※この「ソフトウェア品質要因の測定」の解説は、「ソフトウェア品質」の解説の一部です。
「ソフトウェア品質要因の測定」を含む「ソフトウェア品質」の記事については、「ソフトウェア品質」の概要を参照ください。
- ソフトウェア品質要因の測定のページへのリンク
