濱井です。
2001/09/03 16:01:25 +0900にono@....jpさんが送られた
メールに関する返信です。
> > この資料の４ページ目、「時間-コストカーブ」の図の左側の方を
> > 見ていて思ったのですが、変更コストが時間の経過とともに
> > 上昇していく原因の一つに、時間の経過とともに時間当たりの
> > 変更件数が減少していくということもあるのではないでしょうか。
>
> > 最近ではあまり聞きませんが、ずっと以前には、「後になれば
> > なるほどバグ１件当たりの修正コストが高くなるので、なるべく
> > 早くバグを摘出するべき」と言われていました。それに対して、
> > 「後になればなるほど摘出されるバグが少なくなるので、バグ１件
> > 当たりの修正コストが高くなる」という反論がなされました。
>
>
>これは 「同じ」 バグがプロジェクトの初期に見つかった場合と後期に
>見つかった場合では変更コストが違う、という、もともと Cosf of
>Change が扱っていた議論への反論にはなっていないのでは、と考えま
>す。
私の記憶では、「バグ１件当たりの修正コストの増大」は、米軍の
ソフトに関するもので、修正行当たりの修正コストを各フェーズ毎に
算出したものだったはずです。
「同じ」バグではないはずです。
同じバグを何度も検出し、何度も修正するというようなことは、
通常あり得ませんし、もし仮にそのようなことが起きたプロジェクト
があったとしても、そのような管理のデタラメなプロジェクトの
データは到底信頼できません。
実験してそのようなデータを得ることは不可能ではありませんが、
極めて大規模な実験となり、行うことは困難でしょう。
>１万部刷ったマニュアルの変更をする際に、９個所の変更をする場合と
>１個所の変更をする場合を考えてみます：どちらも訂正表を１万部刷る
>ことになりますが、変更一件あたりのコストは後者のほうが９倍になり
>ます。グラフを書いてみると右肩上がりになるでしょう。
>
>このような現象が、ソフトウェアプロジェクトでも発生するのではない
>かと思います。特に後期で、修正それ自体にかかる固定費(＝一万部の
>訂正表)がほぼコンスタントになる場合にはありえると思います。
>
> > 早めにバグを摘出すればするほど後になって摘出されるバグは
> > 少なくなるのでそのソフトに対して不慣れとなり、いざバグが
> > 見つかった時の修正コストは増大するため、無理をして早めに
> > バグを摘出しても効果が薄いことになります。
>
>ここはちょっと、混乱していて分りにくいです。
>
>印刷されたマニュアルの例のように、修正個所が１個であれ９個であれ
>必ずかかる固定費用のことを考えるのであれば、「無理をして早めにバ
>グを摘出しても」、バグをゼロにしない限り「効果が薄い」、というこ
>とは言えると思いますが。
その例のようなことが起こり得ると言っているつもりです。
例えば、バグが１件だけ見つかった場合とバグが２件立て続けに
見つかった場合とを比較すると、バグが２件立て続けに見つかった
場合の方が効率よくバグを修正できるであろうことは推測できます。