2015年5月
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            
無料ブログはココログ

« 【定量的品質予測のススメ】「標本数の確保」と「詳細な品質管理、分析」 | トップページ | 【定量的品質予測のススメ】ソフトウェア信頼度成長モデルの横軸は何を取ると良いか »

2008年12月24日 (水)

【定量的品質予測のススメ】ソフトウェア信頼度成長モデルはお勧めなのか

P91「B ソフトウェア信頼度成長モデル」において、「しかし、その後の研究から種々のモデルが提唱された。現在では、こうしたモデルを統合的に扱う研究やツールの普及が進み、予測精度は格段に向上してきている」とある。

これまで、本書では信頼度成長曲線は度々書かれていたが、今一つ絶対お勧めと言う形では扱われていなかったが、本書のスタンスは結局は推奨しているのだろうか。

さらにP93において種々の信頼度成長モデルを統合したモデルについての記述で「なお、統合モデルについては市販ツールも存在し、これを利用すれば、既存の単独モデルのみを使用した場合に生ずるモデル不適合による誤差の増大の問題や、既存の複数のモデルを適用すつ場合に生ずる際的モデル選択作業の煩雑さから開放され、安定した精度で残存欠陥数の推定ができる」とある。

この記述からみれば、信頼度成長モデルは使えるツールとして考えられているようである。

しかし、P11の「テストに極端な偏りがないことや、テストの網羅性が十分確保されている等々注意すべきことがあり、信頼度成長モデルだけでテストの終了を判断するのは不充分である」という記述も合わせて読まねばならない。

モデルの曲線を実測値にフィットするように変形してくれる便利なツールがあるのは良いが、その元となる計測が、信頼度成長モデルを適用できるレベルに達していることが重要なのである。

収束に向かってきたと思ったら、立て続けに欠陥が出てきたということが過去のプロジェクトでなかったであろうか。

「テストに極端な偏りがないことや、テストの網羅性が十分確保されている等々」という記述は甘くみてはならない。

「信頼度成長モデル(この場合S字モデルをイメージ)は、テスト開始直後は環境準備等に時間を要するために指摘件数の立ち上がりは遅いが、すぐに開発した機能の確認が始まるので曲線の立ち上がりが急になる。開発した機能のテストが一段落ついたところでレグレッションテストを行うから寝るんだよ」みたいな説明をする人も入るが、そのような使い方は信頼度成長モデルとはいえないのではないか。

単なる発見欠陥のプロットと呼ぶべきである。
なぜか。

開発した機能の確認が不充分の時でも、レグレッションテストを行えば寝るからである。
これで信頼度が成長したとは言えまい。

また、信頼度成長モデルからあと10個欠陥を出さねばと言ってテストしたら、バグが50個も出てきた場合どうするのであろうか。
そのようなことはありえないので仮定することもおかしいことなのだろうか。

« 【定量的品質予測のススメ】「標本数の確保」と「詳細な品質管理、分析」 | トップページ | 【定量的品質予測のススメ】ソフトウェア信頼度成長モデルの横軸は何を取ると良いか »

定量的品質予測のススメ」カテゴリの記事

コメント

コメントを書く

(ウェブ上には掲載しません)

トラックバック

この記事のトラックバックURL:
http://app.f.cocolog-nifty.com/t/trackback/1048600/25961777

この記事へのトラックバック一覧です: 【定量的品質予測のススメ】ソフトウェア信頼度成長モデルはお勧めなのか:

« 【定量的品質予測のススメ】「標本数の確保」と「詳細な品質管理、分析」 | トップページ | 【定量的品質予測のススメ】ソフトウェア信頼度成長モデルの横軸は何を取ると良いか »