ソフトウェア品質をはかる

前に不具合密度の話を書きました。共同研究の検討や相談や雑談を通じて感じたのですが、この指標は業界や業種によって受け止められ方がかなり違うようです。今回はこのあたりの話を。

まず、改めて不具合密度の話を．．ソフトウェアの品質を測るために、デザインレビュー、ソースコードレビュー、テストにおいてこの値を測ることは一般的です。機能別に求められる品質や複雑さに応じて目標値や範囲を設定して、それに達しているかどうかによって品質を類推しようというものです。類推できれば、テストのリソース配分を変更したり、設計の再検討など対策がとれます。ただ、実際には不具合の密度ではなく、不具合を検出した密度であるため、残存不具合については類推しかできません。たとえば、そもそも最初の品質が低い場合には、ちょっとしたテストをするだけでそれなりの不具合密度になりますし、既にかなりの高品質の場合には、相当気合いの入ったテストを実施した場合でも同じような不具合密度になる場合もあります。だいたい密度の分子は検出不具合数で、分母はKLOC(ソースコード1,000行)であったり、ドキュメントのページ数であったりします。1つの原因から複数の現象が現れている場合に不具合を何件と数えるか、ソースコードにはプログラミング言語やコメント計上の有無や様々なばらつきもあります。分子が比較的小さい値であったりしたときには、少ない数の不具合でもヘンに大きな値になったりもします。そういう欠点がありながらも、やはり不具合密度はそれなりの品質指標になります。計測もそれほど難しくはありませんし、学習/教育コストも低いというのもよく使われている理由でしょう。

やっと本題に入るのですが、長くエンタープライズ/IT系のソフトウェア開発をされているところにはもはやスタンダードになりつつあるこの指標ですが、急激にソフトウェア規模が大きくなったような組込み系のソフトウェア開発をされているところで市民権を得るには、まだ時間が必要なようです。ソフトウェアのコーディングはハードウェアの製造に対応するものと考えられてしまうと（ウォータフォールの開発の場合、コーディングを製造工程と呼ぶ場合もかなり多いです）、不具合密度が時とともに改善していかなかったり、一定量よりも低い場合に異常と考えることがハードウェアの製造となじまないようです。ハードウェアの製造工程において、出荷可能品率（歩留まり）は高くなっていくものであり、低くなることはあまりない。不具合密度（不良品率）が低いことにより品質を憂う意味や改善していかない不具合密度を実感として理解するのには今しばらくかかるのかもしれません。