ソフトウェア品質
メモリ容量の一部を将来の拡張のために取ってあるか? 各モジュールの凝集度は適切か? データ構造の変更に容易に対処可能か? 機能の変更にあたって全体の再構成を必要とするか(変更の内容にもよる)?
構成部品が一様なパターンとなっていることを意味する。構造化言語(Pascalなど)で書かれたソフトウェアはこの特性を満足する。
要求仕様がプログラムがすべきことを記述するのに対して、ソフトウェア設計ではプログラムがそれをどのようにすべきかを記述する。設計工程の有用性には異論もあるが、信頼性の観点からはソフトウェア設計工程の重要性が指摘されている。ソフトウェア設計では、ソフトウェアを部品にわけ、それらのすべきことを記述する。そのようにしてプログラムを細分化していき、部品群が全体として正しく機能するようにする。
高レベルな設計の目的は次のようになる。アーキテクチャ上の問題やプログラムの概念や構造に関する問題を実際のデータ処理に関わるコード上の問題と分離する。ソフトウェアコンポーネントを細分化することで個々のコンポーネントの開発に関わるものに制約を与え、結果としてバグを作りこみにくくする。コンポーネント間のインタフェースを定義することで複数のチームがそれぞれ別のコンポーネントを並行して開発できるようにし、各チームがその役割を認識できるようにする。また、実装言語を指定せずにプログラムの機能を記述することで、言語に依存した偏向を排除する。
もし重み付けしていない場合、100件のバグと1000件のバグのどちらが品質が良いのかをどう判断するのか?
検出バグ数が時と共に減っている場合、その意味をどう判断するか? 例えば、その製品が従来よりも品質が良くなっていると判断できるのか? あるいは、改造を以前ほどしなくなっただけか? あるいは、評価を行う者が変わって以前よりバグを検出できなくなっただけか? あるいは、チームが意図的にバグ数の報告を少なくしようとしているのか?
最後の質問は、特に管理上の難しさを示している。ソフトウェアは人間が作るものであるため、ソフトウェア品質のメトリックは、ある意味で人間の振る舞いを測定することである。チームがバグを過少に報告することで何らかの利益が得られるなら、そのチームは少なくバグを報告する傾向が強くなる。バグ追跡システムを出し抜く方法を見出したり、4、5件のバグを1件の報告にまとめてしまったり、些細なバグを報告しないことで作業量を減らすといったことである。意図したとおりの測定をすることは難しい。特にプログラマや評価者が、意識的か無意識的かに関わらず、測定そのものにゲームとしての誘因を見出さない場合、その傾向がある。例えば、品質保証部門がそのチームの過去のバグ傾向などから新たなソフトウェア開発におけるバグ収束曲線を予測し、実際のバグ報告とその予測を比較することで残存バグ数を見積もるとする。