小野です。
濱井さん、こんにちは。
>> Regarding [XP-jp:02460] 変更コストの変化 (was オブジェクト指向シンポジウウムの資料 ); hamai@....jp adds:
> 濱井と申します。
> この資料の４ページ目、「時間-コストカーブ」の図の左側の方を
> 見ていて思ったのですが、変更コストが時間の経過とともに
> 上昇していく原因の一つに、時間の経過とともに時間当たりの
> 変更件数が減少していくということもあるのではないでしょうか。
> 最近ではあまり聞きませんが、ずっと以前には、「後になれば
> なるほどバグ１件当たりの修正コストが高くなるので、なるべく
> 早くバグを摘出するべき」と言われていました。それに対して、
> 「後になればなるほど摘出されるバグが少なくなるので、バグ１件
> 当たりの修正コストが高くなる」という反論がなされました。
これは 「同じ」 バグがプロジェクトの初期に見つかった場合と後期に
見つかった場合では変更コストが違う、という、もともと Cosf of
Change が扱っていた議論への反論にはなっていないのでは、と考えま
す。
ただし「時間」対「バグ一件あたりの修正コスト」の右肩上がりカーブ
が、なにかの実証的なデータとして出された場合には、そのグラフの解
釈として濱井さんのおっしゃるようなことを疑ってみることはできるし、
またすべきだと思います。
１万部刷ったマニュアルの変更をする際に、９個所の変更をする場合と
１個所の変更をする場合を考えてみます：どちらも訂正表を１万部刷る
ことになりますが、変更一件あたりのコストは後者のほうが９倍になり
ます。グラフを書いてみると右肩上がりになるでしょう。
このような現象が、ソフトウェアプロジェクトでも発生するのではない
かと思います。特に後期で、修正それ自体にかかる固定費(＝一万部の
訂正表)がほぼコンスタントになる場合にはありえると思います。
> 早めにバグを摘出すればするほど後になって摘出されるバグは
> 少なくなるのでそのソフトに対して不慣れとなり、いざバグが
> 見つかった時の修正コストは増大するため、無理をして早めに
> バグを摘出しても効果が薄いことになります。
ここはちょっと、混乱していて分りにくいです。
印刷されたマニュアルの例のように、修正個所が１個であれ９個であれ
必ずかかる固定費用のことを考えるのであれば、「無理をして早めにバ
グを摘出しても」、バグをゼロにしない限り「効果が薄い」、というこ
とは言えると思いますが。
また、オリジナルの Cost of Change の議論には「バグを発見する」ま
でのコストは入っていないと記憶します。「見つかったバグを修正する／
要求された変更を実装する」コストだけ見ていたと思います。
// Tsuyoshi ONO //
e-Communications Dept, Telecom & Service Company / SONY Corporation
email: ono@....jp
"Be completely flexible on how we get there, but be totally
uncompromising on where we are going." -- Martin Fowler