あきら＠ブリッジ・メタウエアです。
hamai@....jp wrote:
---------------
>欠陥の修正は、レビューにより欠陥を発見した場合を除いて
>以下のようなプロセスを経ます。
>
>(1)欠陥により引き起こされる障害の検出
>(2)欠陥の特定
>(3)欠陥の修正
>
>障害を引き起こした欠陥から修正していくことになるため、障害を
>発現しにくい欠陥ほど、後まで残ることになります。つまり、(1)
>が困難でそのコストのかかる欠陥ほど後まで残っているわけです。
>
>リリース前に欠陥を修正するためには、(1)のコストの急激な増大が
>ネックとなります。ところがリリースしてしまえば、障害の検出を
>するのはユーザであり、(1)のコストから解放されます。
>
>そのため、いくつもの欠陥が残っているであろう段階でソフトウェア
>はリリースされてしまうのです。
つまり、コスト的にリリース後に修正するコストが、リリース前に
修正するコストを上回ると予想される場合にリリースされる、
ということですね。それは確かにそのとおりだと思います。
欠陥を０にするためには、無限に近い工数が必要でしょうから。
しかし、それが欠陥を早い段階で検出・修正するべきではない、
という話になる過程がやはりよく分かりません。
相手にする規模が小さいうちにその芽を摘むべきだと思います。
・欠陥が入り込まない工夫
・欠陥を見つけ易くする工夫
・欠陥を修正しやすくする工夫
はプロジェクト全体で実行するべきではないでしょうか？
>変更は欠陥の修正と同様、以下のようなプロセスを経ると
>考えられます。
>
>(1)'変更の必要性の認識
>(2)'変更箇所の特定
>(3)'変更
>
>必要性を認識しにくい変更ほど後まで残り、(1)'のコストが急激に
>増大するように思います。
変更は要求が元になるので、(1)のコストが増大する、
ということは起こらないように思います。
変更の場合はやはり(2),(3)のコストが大半ではないでしょうか。
-------
佐藤 聡 - Verba volant, scripta manent.