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

« 【共通フレーム2007第2版】「(b)要件定義プロセス」の解説が厚くなった | トップページ | 【共通フレーム2007第2版】V字モデル再び(適格性確認) »

2010年3月 1日 (月)

【ソフトウェア開発の定量的管理】できるのはそんなものという割切り

やはりよく言われるようにソフトウェア開発には直接測れる物差しが今のところ発見されていないことと人起因およびプロジェクト毎の要件のバラツキが大きくかつ避けられないことが、定量的管理手法を難しくさせる、というかうさん臭くさせるのであろう。

このあたりを解決するためには、現行の管理手法の効率化を探るより、開発手法自体を変えることを考えた方がよいであろう。
自動で欠陥密度が分かり過去データとの統計的比較からプログラムの品質がわかりますといわれても、そもそも欠陥密度の算出方法はそれで良いのか…というような話をまず片付けるべき。

定量的管理の経験発表等で、今後の改善策は測定パラメータを追加し、より詳細に計測していく…というパターンがよくあるが、何か違うと感じる。

パラメータ追加でメトリクスの精度を上げようという試み。気持ちは分かる。しかし、そもそもなぜメトリクス管理を行うか振り返るべき。複雑で混沌としたソフトウェア開発プロジェクトの状況を、特徴的に表すパラメータに着目して人が認識できるようにしようというのが目的のはず。

なのにパラメータ増やしたらまた混沌とするのではないか。バグ密度測るのに2個よりも100個のパラメータ計測したほうが良いと言えるのか。所詮は、発見バグ数を開発規模で割るだけならその程度のものと文字通り割り切った方が良いと思えるのだが。
そもそも、パラメータが多いと何かあったときにどのパラメータの寄与でデータが異常値になっているのかを判別することも難しくなってこよう。

まして1つのメトリクスだけで評価するのではなく複数のメトリクスを見て判断すべきだとか、管理限界を超えた値も一概にダメと決めつけずその原因を追求すべきと予防線をはる定量的管理など労多くして…となりかねない。

大量のパラメータからなるメトリクスデータをこれまた大量に手に入れたとして、それをどうするのか。結局はプロマネやチームで判断するのでしょう。その判断は恐らく定性的に行われると想像される。

ではわざわざ計測した意味はどこにあるのか。定量的管理の使い方を間違っているのではないだろうか。

« 【共通フレーム2007第2版】「(b)要件定義プロセス」の解説が厚くなった | トップページ | 【共通フレーム2007第2版】V字モデル再び(適格性確認) »

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

コメント

コメントを書く

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

トラックバック

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

この記事へのトラックバック一覧です: 【ソフトウェア開発の定量的管理】できるのはそんなものという割切り:

« 【共通フレーム2007第2版】「(b)要件定義プロセス」の解説が厚くなった | トップページ | 【共通フレーム2007第2版】V字モデル再び(適格性確認) »