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

« 【ソフトウェア開発品質】レビューチェックシートの活用 | トップページ | 【CMMI】Version 1.3 間もなくリリース »

2010年10月 1日 (金)

【ソフトウェア開発品質メトリクス】定義することはエイヤっと決めることではない

-------------
【注意】今回はグダグダの内容、かつ以前にも類似のことを書いています。しかし重要だと考えていますのでアップします。
-------------

ソフトウェア開発における品質メトリクスにおいて、モデルを表す式や計測方法等を定義するのは、本当は大変な作業である。

なぜそれで良いのかの論理的説明ができなければならないから。

しかしこの説明をすることは難しい。
単純なモデルほど誰にでも理解しやすいが、でも何でそれでよいの?には答えづらいはず。
例:バグ摘出密度はどうしてそれで説明できるのですか?

これが開発者から品質担当者への質問として出てくると困りものである。
例:テストケース1件とはどういうことですか

このような質問は普通に思いつくが答えられないものが多い。
結局、広く一般化された解答はなく、各システムの状況に合わせて同一システム内では整合性を取るように計上してくださいとかいうことになってしまう。

しかし、この解答はおかしい。
毎開発同じではないのに「同一システム内で整合性を取る」のは難しいのではないか。
もしできるのであればどうして「同一組織」ではダメなのか。さらに「同一業種では」、いやいや「日本の開発では」。

結局、もっともらしく「皆が現実的だと思いそうな」ところで手打ちしているだけである。

「当社は各システムがちゃんと定義してしっかりやっています」と胸を張るのが良いのかどうかと個人的には思う。

それでもシステムごとの定義は「皆が現実的だと思いそうな」ところなので推す気も理解できるし、聞かれればこれを押す。しかし、「ちゃんと定義するのであれば全社でも同じ理屈で定義できるのでは?」という問いにどう答えればよいだろうか。

« 【ソフトウェア開発品質】レビューチェックシートの活用 | トップページ | 【CMMI】Version 1.3 間もなくリリース »

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

コメント

コメントを書く

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

トラックバック

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

この記事へのトラックバック一覧です: 【ソフトウェア開発品質メトリクス】定義することはエイヤっと決めることではない:

« 【ソフトウェア開発品質】レビューチェックシートの活用 | トップページ | 【CMMI】Version 1.3 間もなくリリース »