小野です。
>> Regarding [XP-jp:02467] Re: 変更コストの変化 (was オブジェクト指向シンポジウウムの資料 ); hamai@....jp adds:
> 濱井です。
>> これは 「同じ」 バグがプロジェクトの初期に見つかった場合と後期に
>> 見つかった場合では変更コストが違う、という、もともと Cosf of
>> Change が扱っていた議論への反論にはなっていないのでは、と考えま
>> す。
> 私の記憶では、「バグ１件当たりの修正コストの増大」は、米軍の
> ソフトに関するもので、修正行当たりの修正コストを各フェーズ毎に
> 算出したものだったはずです。
> 「同じ」バグではないはずです。
濱井さんがおっしゃる、米軍のソフトを例に取った統計のお話であれ
ば、拙文で書いた「なにかの実証的なデータ」ですから、濱井さんの
解釈が可能だろうと思います(修正に「かかった」コストの統計なの
ですよね？それが、数字のトリックで説明可能な部分を含むだろうと
いうことだと思います)
XP におけるCost of Change の議論はもう少し、理論的な想定の話と
して扱われていたと思います(修正に「かかるだろう」コストを推定
する)。たとえば
http://www.XProgramming.com/xpmag/cost_of_change.htm
を御覧ください。
「同じバグ」についてですが、例えばエプ入門では想定上の問題として、
「要求分析で見つかっていれば１ドルで直せた問題が、
ソフトウェアが稼働(運用)に入ってからでは直すのに
数千ドルかかる」
(XP エクストリーム・プログラミング入門 p.21)
などという説明がコストカーブについています。私が「同じ」と書い
たのもこの意味での「同じ」です。存在する一つのバグに対して、初
期で見つかって修正される(そしてもう二度と現われない)場合と、後
期で見つかる場合と、二つの排他的なシナリオを考え、両者のコスト
を比較しよう、というものです。
＃「同じ」バグが二度三度と発見され修正される例の話ではありません
>> > 早めにバグを摘出すればするほど後になって摘出されるバグは
>> > 少なくなるのでそのソフトに対して不慣れとなり、いざバグが
>> > 見つかった時の修正コストは増大するため、無理をして早めに
>> > バグを摘出しても効果が薄いことになります。
>>
>> ここはちょっと、混乱していて分りにくいです。
>>
>> 印刷されたマニュアルの例のように、修正個所が１個であれ９個であれ
>> 必ずかかる固定費用のことを考えるのであれば、「無理をして早めにバ
>> グを摘出しても」、バグをゼロにしない限り「効果が薄い」、というこ
>> とは言えると思いますが。
> その例のようなことが起こり得ると言っているつもりです。
> 例えば、バグが１件だけ見つかった場合とバグが２件立て続けに
> 見つかった場合とを比較すると、バグが２件立て続けに見つかった
> 場合の方が効率よくバグを修正できるであろうことは推測できます。
了解しました。
// Tsuyoshi ONO //
e-Communications Dept, Telecom & Service Company / SONY Corporation
email: ono@....jp