Index: [Article Count Order] [Thread]

Date:  Tue, 4 Sep 2001 14:35:46 +0900
From:  hamai@....jp
Subject:  [XP-jp:02478] Re: 変更コストの変化 (was	オブ
To:  extremeprogramming-jp@....jp
Message-Id:  <200109040535.OAA02109@....jp>
In-Reply-To:  <20010904102911.30380cf0.01340@....jp>
References:  <20010904102911.30380cf0.01340@....jp>
X-Mail-Count: 02478

濱井です。

「現実のソフトウェアにいくつもの欠陥がリリース後残っているのは
なぜか?」ということを考えて欲しいのですが。

リリース後欠陥が見つかれば。

・欠陥の修正
・欠陥の広報
・欠陥の問い合わせへの対応
・製品やベンダーに対する評価の低下

といったコストを支払わなければなりません。これらのコストは
リリース後に残っている欠陥が少なければ少ないほど、少なくなる
わけです。この点からだけでも、リリース前に欠陥を修正すれば
修正するほどいいはずです。
ところが、現実のソフトウェアにはいくつもの欠陥がリリース後
残っています。これは、リリース前に欠陥を修正することが、
残っている欠陥が少なくなれば少なくなるほど困難になり、
修正のためのコストが増大するからです。

欠陥の修正は、レビューにより欠陥を発見した場合を除いて
以下のようなプロセスを経ます。

(1)欠陥により引き起こされる障害の検出
(2)欠陥の特定
(3)欠陥の修正

障害を引き起こした欠陥から修正していくことになるため、障害を
発現しにくい欠陥ほど、後まで残ることになります。つまり、(1)
が困難でそのコストのかかる欠陥ほど後まで残っているわけです。

リリース前に欠陥を修正するためには、(1)のコストの急激な増大が
ネックとなります。ところがリリースしてしまえば、障害の検出を
するのはユーザであり、(1)のコストから解放されます。

そのため、いくつもの欠陥が残っているであろう段階でソフトウェア
はリリースされてしまうのです。


変更コストについても欠陥の修正コストと同様のことが言えると
思います。

変更は欠陥の修正と同様、以下のようなプロセスを経ると
考えられます。

(1)'変更の必要性の認識
(2)'変更箇所の特定
(3)'変更

必要性を認識しにくい変更ほど後まで残り、(1)'のコストが急激に
増大するように思います。