Softwareの品質について、規格がある。ISO9000-3及びISO9001、ISO8402、ISO/IEC 12207。しかし、これらは外郭を埋めるのみで具体的な取り決めをしたものは見当たらない。また、最近騒がしいCMM（能力成熟度Model）も、品質Processを内部にどの程度持っているかを示すのみだ。各社の取り組みもまちまちで、例えば日立は、ISO/IEC 12207を元にHITESTと呼ぶOriginalのToolsを使用している。また、三菱の重電では、購入するSoftware会社にニチメン社のTest ToolをPassさせることを納品の条件にしている。そして、経済産業庁では、GPL softwareのEPPを元に機能拡張したものを持っている。更に、JQAの構成員は、Software品質を高める項目にCoverage（検査網羅度）を追求すべきだろうと言っている。このCoverageは、いわゆるWhite-box testをどのくらいやったかを示している。ところが、コンピュータシステムとしての品質保証担当は、基本的にソフトウェアをBlack-box testにのみ重点を置いて、それ以外の項目はSoftware開発者に委ねているのが現状だろう。よく言われるように、品質は上流段階で作りこまれるものであり、下流に行けば行くほど欠陥（Bug）の修正にCostがかさむようになっている。
ところで、Object指向技術を導入すると、それまでの構造化指向programmingで使用していたStep数あたりの検査項目数を指標に出来ないことがわかってきた。しかし、何を基準にすればいいかわからないのでそのまま構造化指向programmingの基準を使っているところも多いように思う。
そこで、新しい指標を提案する。しかし、使用するものは新しくない。昔から普遍的なものである、program sizeを使用する。
まず、基準となるprojectを抽出する。これはできる限り完成度の高いものが望ましい。（完成度が高いとは、客先からのclaimや再検査の手間が少ないものを言う。）
基準projectの検査項目数を出す。再検査を実施した場合はそれも別項目として加える。客先からのclaimも加える。単位は［件］。
基準projectの容量を出す。単位は［byte］。但し、画像などのresourceは除外し、純粋なprogram容量を出す。
基準projectの容量あたりの検査項目数Pを計算する。
P = program容量 ÷ 検査項目数。単位は［byte/件］。
基準projectの情報entropy(エントロピー)H(S)を計算する。H(S)は次式により計算される。ここで、LOGは底を2とする対数である。
H(S) = -P × LOG(P)
同様に、計測しようとしているprojectの情報entropy H(M)を計算する。ここで、programの再利用をしている場合はその部分の容量及び検査項目を除外する。
この２つの情報entropyが、H(S)<H(M)の関係に近づいているほど良いと言える。また、programの再利用をしている場合、全体のprogram容量からprogramの再利用分の占める割合Fを求めて、次式に当てはめる。
H(S) × (1 -F) < H(M)
例を挙げる。基準projectが、1Kbyteの容量で、検査項目数が8件だったとする。これに対し計測対象projectが、4Kbyteの容量で、検査項目数が16件だったとする。
そうすると、情報entropyは、H(S)=7/128,H(M)=1/32となり、H(S)>H(M)になり、条件を満たしていないので、検査項目を増やす必要がある。
また、計測対象projectが、4Kbyteの容量で、検査項目数が64件だったとすれば、H(S)=7/128,H(M)=1/4となり、H(S)<H(M)になるので条件を満たしているので、適正な検査が行われていると言える。
もうひとつ、計測対象projectが、4Kbyteの容量で、検査項目数が64件だった場合で、programの再利用率がそれぞれ75%とすれば、H(M)は、3/32となる。条件式に当てはめると、左辺が7/512、右辺が3/32のため、条件を満たしているので、適正な検査が行われていると言える。
ところで、projectの規模が大きくなると、容量をKiB(キビバイト)で計算したくなるだろう。その場合、検査項目数も1024で割る必要がある。