山根さん、こんにちは。菊池です。
夏休みだったので、すっかり遅くなってしまいました。
もう、クローズみたいですが、ちょっと返事させて下さい。
> > > そうですね。カバレッジはあくまで指標だと考えています。
> > > 但し、最低限クリアすべき指標であると考えます。
> >
> こう言ってしまうと、やっぱりカバレッジは最低限満たして
> いなければならない、当然の作業のように聞こえてしまいます。
このメーリングリストメンバは、それこそ色々なドメインの
ソフトウェア開発者がいて、開発環境も色々、役割も違うのに、
ちょっと表現が一方的だったかな反省しています。
数値の独り歩きの危険性などは、その通りだと思います。
僕がカバレッジ率に期待するところを補足させてください。
http://objectclub.esm.co.jp/eXtremeProgramming/
からのリンクで日本科学技術連盟ホームページ内−
「小規模・短納期プロジェクトにXPを導入する際の課題」
という文章があるのですが、その中でXPは品質保証の面から
課題があると指摘されています。
僕はこれを
・XPが正しく行われていることを証明する検証プロセスがあった
ら良いかも。(組織的な取り組みであることの証明)
・誰がメンテしているか分からない数年後においても、継続して
保証できる仕組みがあったらよいかも。
(継続した取り組みであることの証明)
と解釈しました。
そして、ユニットテストが存在し、継続しメンテされている
状態をカバレッジ率で表すことにより、目に見える形で保証
できるのではないかと思ったのです。
このような要件を満たすための目標カバレッジ率の設定方法
ですが、過去(他)の同じような安定しているソフトウェアを
参照し無理のない合理的な範囲で決めればよいと考えます。
これができればXPの弱点と言われる品質保証についてもある程度
補完できるのかなと考えるのです。