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            
無料ブログはココログ

« 【見える化】見える化・視覚化・定量的管理で注意すべきこと | トップページ | 【深淵なるソフトウェア定量的管理再考②】ゾーン分析 »

2011年3月15日 (火)

【深淵なるソフトウェア定量的管理再考①】バグ曲線

ソフトウェア開発における定量的管理の奥深さとその奥深さに対する開発現場の姿勢について改めて考えてみたい。
考えるにあたっては、バグ曲線とゾーン分析を用いたい。

バグ曲線。
これは「事実の記録」としては正しいものだろう。
また、個々のプロジェクト毎の曲線のみについて分析することも有効だと考える。

しかし、これを複数プロジェクトの計測結果を基にした統計的処理を考えたり、そこまでは言わないまでも、複数プロジェクトの曲線間の共通の法則のようなことを考えるとなると、途端に色々なモデル上の前提・仮定やノイズについて考える必要が出てくる(この辺りは過去のエントリご参照)。

しかし、現場ではこのような難しい事項に対し考慮不足のまま走っているように思える。
例えば、実際のバグ曲線とモデルから描画される信頼度成長曲線を比べたりということをモデルの前提・仮定を顧みることなく行っている組織が多いのではないだろうか。

また、バグ曲線の横軸についても、実施テストケース累積数を採った方が、日付やテストへの投入時間とするよりも良いという考え方が提示されている。確かにその考えも理解できる。しかし日付やテストへの投入時間の方が劣っていると一概に言えないのではないだろうか。
日付は1日あたりのテスト件数のばらつきが多いことやテストを実施しない日の取り扱いが欠点/課題とされるし、テストへの投入時間の場合もテスト1件のテスト投入時間のばらつきが言われる。しかし、これは日付や経過時間といった時間に着目しているから出てくる当然の課題だと考えられないか。

優れていると言われるテスト件数を横軸にとった場合にこれらに相当する程度の欠点はないだろうか。
日付や経過時間の場合には時間に着目し欠点が挙げられるので、テスト件数の場合はテストケースに着目した欠点があるのではないだろうか。
それぞれのテストケース1件とは、テスト対象の規模に対して同じ価値のテストがされるのであろうか。1件のテストに対し確認されるFPやSLOC数は同じなのだろうか。同じでなくて良いのであろうか。

日付や経過時間は時間に付随した欠点があるから実施テストケース累積数の方が良いという考え方を採用する組織が多いように思われるが、そのような判断においてテストケース数の重みに関する欠点についての検討は十分なされているのであろうか。

信頼度成長曲線の横軸は、日付や経過時間は時間の場合と実施テストケース累積数の場合とでは、見たい傾向が異なるので優劣の話ではなく、両方採用すれば良いのではないかと考える。

日付や経過時間は、収束するには、あとどの程度の日数、時間テストを行う必要があるかを見るもので、実施テストケース累積数は、収束するには、あとどの程度のテストケースを実施する必要があるかを見るものと考えれば優劣をつけるべきものではないと考えられるのではないだろうか。

(…と書いたが、個人的にはどちらも大した予測はできないと考えている。上記は信頼度成長曲線を使うのであれば、検討した方が良いのではないかというものを客観的視点で書いたものである)

« 【見える化】見える化・視覚化・定量的管理で注意すべきこと | トップページ | 【深淵なるソフトウェア定量的管理再考②】ゾーン分析 »

ソフトウェア開発品質・生産性私見」カテゴリの記事

コメント

コメントを書く

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

トラックバック

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

この記事へのトラックバック一覧です: 【深淵なるソフトウェア定量的管理再考①】バグ曲線:

« 【見える化】見える化・視覚化・定量的管理で注意すべきこと | トップページ | 【深淵なるソフトウェア定量的管理再考②】ゾーン分析 »