濱井です。
2002/07/29 15:11:17 +0900にhattori@....jpさんが送られた
メールに関する返信です。
>> マイヤーズの本にも書かれていますが、カバレッジ率100%でも見つからない
>> 種類の欠陥があることがわかっています。あるべき処理が抜けていると
>> いうようなケースは、カバレッジ率は役に立ちません。CodeRedやNimdaで
>> 悪用されたバッファオーバーフローや、最近ウェブサイトで次々と
>> 見つかっているクロスサイトスクリプティング脆弱性などはその例です。
>>
>> このように仕様そのものに欠陥がある、仕様そのものが考慮不足である
>> というような例は珍しくありません。
>
>濱井さんのメールを読んでいて思ったのですが、実行させるテスト
>が機能仕様のどの範囲までをカバーしているかを判定するための方
>法論というのはあるのでしょうか。
機能仕様に対してなら、デシジョンテーブルを使って機能的な網羅性を
判定するやり方などがあります。これもマイヤーズの本に書かれていたはず
です。
しかし、機能仕様が充分か否かを判定する方法は見つかっていません。多分、
無いと思います。
>> カバレッジ率が無意味だとは思いませんが、カバレッジ率が重要か否かは
>> 一概には言えないでしょう。
>
>ここはちょっと一般論として扱うのは大雑把なような気がします。
「カバレッジ率」だけを取り出して、「ソフトウェア品質指標についての考察」
と大上段に構えていたので、「カバレッジ率」を重視し過ぎない方がいいと
述べたまでです。「カバレッジ率についての考察」であれば、そこまで
言わなかったかもしれません。
> 具体的
>にどのような状況（コンテキスト）でそのような「品質向上プログラムが
>品質低下プログラムになっていく」のかという問題が発生するかを把握し
>て、その歯止めを掛けていけばよいと思います。
投入できるリソースが有限である以上、あらゆる品質向上プログラムは、
品質低下プログラムとなる危険性があります。
品質のある特性を向上させようとしてリソースを投入することは、他の特性の
ために投入できたはずのリソースを奪うことでもあるのです。そのため、ある
特性の向上は、一般に他の特性の低下を引き起こします。それが、品質全体
として見た時、品質の低下となる場合があります。
> あとこうした問題の改善については
>CMM が本来その対象とするところかなとも思います。（レベル３か４あ
>たりかな）
それは、CMMの過大評価のような。というか、ソフトウェア工学の過大評価と
言う方が適切かもしれません。
# ソフトウェア工学を「裸の王様の服」に喩えた「ソフトウェア職人気質」
# (29ページ)と私はほぼ同意見です。