ウィリアムのいたずらの、まちあるき、たべあるき

ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです(たま~にコンピューター関係も)

信頼度成長曲線は、仕様変更が頻繁に起こらない場合はそうなんだけど。。

2007-02-15 18:56:17 | 開発ネタ

 で、前のバグ管理の話のときに書こうとした、信頼度成長曲線の話。

 信頼度成長曲線は、横軸に期間、縦軸に累積のバグ量をとると、だんだん収束していく。。。はず(^^;)

 っていうのもだけど、実際にやると、必ずしもそうならないと思う。




 たしかに、納品局面において、バグは収束しているんだけど、その途中の局面では、急速にバグが出るという状況が何度も発生してしまうと思う。

 どーしてそういうことが起こるかというと、

(1)仕様変更がおこり、なにも手段を講じないとデグレードするから
  →そのデグレード部分が急激にバグになる

(2)テストで、秘孔を突いてしまうと、一気にバグが出るから。

 で、問題なのは(1)。
 信頼度成長曲線が語られる文脈は、昔のウォータフォール型開発で、仕様変更が頻繁に起こらないことを前提にしていると思う。なので、修正により精度が上がっていくことになる。
 一方、現在の場合は、仕様変更が頻繁に起こるから、デグレード対策をしておかないと、アウト!になる。とくに、インターフェースの仕様変更が起きるようなケースでは、関連箇所に対する変更通知が確実でないと、デグレードが起こる。
 このとき、関連箇所が全部確認できていれば、そこに通知するだけで問題ないが、そもそも、関連箇所全部が見えていればインターフェースの仕様変更って言うのはそんなにおこんないわけで、それが起こるということは、なんらかのインターフェース設計に問題があるって言うことになる。

 なので、その辺、体制を立て直さないと、デグレードになるリスクが多い。




 これを防ぐには、リグレッションテストで、はじけば良いわけなんだけど、そのリグレッションテストも全部やっている時間がない。

 で、そのために、ある程度の自動化って言うことになるけど、インターフェースが頻繁に変わると、この自動化も、たいへんになる気がする。。

 なんで、たぶん、やってないだろう。。

 そーすると、修正したときに、デグレードになってしまい、信頼度成長曲線は、わけわかんないことになってくる。




 で、この場合、バグが収束するか、発散するかの決め手は、主線が、どうなっているかによるんですけどね。主線が、発散しなければ、どうにかなるし、逆に主線が発散してしまう(あるいは、矛盾がおきたり、できなくなってしまう)と永遠に発散してしまう。

 この場合、主線が固まると、急速にバグは収束する。

 で、主線ってなに?っていう話になってしまうが、それはまあ、今回は置いておくとして(気が向いたら書きます)




 てなわけで、信頼度成長曲線をそのまま信じるのは危険だし、
 「なんでデグレードするんだ!」っていう上司に限って
   デグレード対策してない(だから、デグレードするんだよ)し

  そもそも、なんで、上司の問題なんだ?って聞いちゃいそうだし。。
   念のために、この問題は、今度説明しておくか。。

  簡単に言うと、インターフェースは担当者では読みきれないのよ。
  インターフェースは、対外に関するので、対外との交渉担当である
  マネージャーじゃないと管理できない。

  でも、問題は、その対外担当のマネージャーが、自分の仕事を理解できない
 構造にあるって言うこと(これは、昔は違った)なんだけど。。ね。



この記事についてブログを書く
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする
« JavascriptでIEからテキスト... | トップ | 2036年問題や2038年問題のほ... »
最新の画像もっと見る

開発ネタ」カテゴリの最新記事