上原です。
hamai@....jp writes:
> 欠陥の修正は、レビューにより欠陥を発見した場合を除いて
> 以下のようなプロセスを経ます。
>
> (1)欠陥により引き起こされる障害の検出
> (2)欠陥の特定
> (3)欠陥の修正
>
> 障害を引き起こした欠陥から修正していくことになるため、障害を
> 発現しにくい欠陥ほど、後まで残ることになります。つまり、(1)
> が困難でそのコストのかかる欠陥ほど後まで残っているわけです。
>
> リリース前に欠陥を修正するためには、(1)のコストの急激な増大が
> ネックとなります。ところがリリースしてしまえば、障害の検出を
> するのはユーザであり、(1)のコストから解放されます。
(3)のコスト
＼ ／
＼ ／
＼ ／
／ ＼
／ ＼
／ ＼ (1)のコスト
--------------------->時間
ということですね。バグ修正(伴って検出も)を前倒しするのはいいけど、無理
に前倒しすぎるのは全体のコストからみると割に合わないかもよ、という。
とはいえ、（下手すると有料の）β版公開が隆盛で、サービスパックやマイナー
バージョンアップという名のバグ修正が日常茶飯事のこのご時世を前提にする
と、あるいはオープンソースを前提にすると、(1)のコストは重要ではなくなっ
てきているとはいえるでしょう（本当か??）。
また、ちゃんとしたユニットテストは、早い段階でも(1)の検出コストを低め
てくれる役に立つと思います。開発中に「あれ、挙動が変だな、でもあとで試
験するからいいや」とあとまわしにするのではなく、こまめに頻繁にテストす
る、という状況にしてくれるからです。
（本来一体であるはずの）テストとコーディングとを分離することで、無駄な
手間がかかり全体コストが高くなるのか、
逆に、コーディングに混じりこんでいたテストを分離して「まとめて」やるこ
とで、効率が良くなりコストが低くなるのか、には議論があると思いますが。
どっちでしょう。
> そのため、いくつもの欠陥が残っているであろう段階でソフトウェアはリリー
> スされてしまうのです。
>
> 変更コストについても欠陥の修正コストと同様のことが言えると
> 思います。
>
> 変更は欠陥の修正と同様、以下のようなプロセスを経ると
> 考えられます。
>
> (1)'変更の必要性の認識
> (2)'変更箇所の特定
> (3)'変更
>
> 必要性を認識しにくい変更ほど後まで残り、(1)'のコストが急激に
> 増大するように思います。
これはよく分からないのですが、「機能拡張や改良」を変更としてとらえると、
市場にだせば「売れ行きが悪い」ということですぐに分かるような機能拡張・
改良の必要性について、あらかじめ認識するために、コンサルタント会社に頼
むとか、アンケート調査するとかのコストをかける、というのは欠陥の検出と
ちょっと似てるかもしれませんね。
--
§NTTS○FT 技術開発部エレクトロニックコマース技術センター 上原 潤二 §
PGP Key fingerprint = B7 C0 CB 1F 1C 88 69 2A 25 36 8A EE 93 A3 61 72