あ、そうそう、まえにバグ管理の話を書いたとき、引用した人のサイトに、
バグが収束しない場合の対策はあるのか？
http://blog.goo.ne.jp/wildriver_1977/e/47394ad4e947aef5f373ff9fa9f9d672
っていうエントリがあったのと、
そのあと、業績修正のTIS、「失敗案件ではない。結合テストに想定外の手間」っていう話で、結合の話を書いたので、それについて、ちょっと。。
バグが収束しないケースの多くは、デグレードによる発散で、これは、仕様変更にあるってことは前に書いた。
では、仕様変更がどうして起きるのかというと、
・マネージャーや営業がなんでもほいほい受け入れる
→自分の成績を上げるため。それでSEが何人死んでも、
自分は関係ない。
・担当した設計者の設計が甘い。
さらに、マネージャーが経験不足で、その設計者の甘さを見逃してしまう。
→各業務において、言わなくても、あらかじめ決めないといけない部分
というのがある。
→この部分をユーザーは知らない場合があり、
そうすると、ヒアリングから抜ける
そこの部分を考慮しないで設計しているケース。
マネージャーも、その業界に詳しくないと、そこを考慮してないことに
気づかない。
・ヒアリングのときにうそが入っている
→「ぜったいそんなことはない！」とかいっておいて、本当は、あるケース
・想定したプラットフォームや環境、方法では動かない。
なかんじ？
つまり、多くの場合、設計ミスや設計不足である。
なので、設計からやり直さないと、バグは収束しない。
そして、この設計の品質を高めたり、制約になってしまうのが、フレームワークになる。
フレームワークがプログラム構造を決定し、取得イベント、タイミングを決めてしまうので、コレに反した動きをさせようとすると、どーしても、無理をさせて、バグになってしまう。（っていうか、ハリウッドの法則で考えると、ここに無理をさせること自体、間違ってるけど）
でも、設計をやり直すっていう判断はふつうできないので、対処療法的になり、それが、さらなるバグをよび。。っていう構図になる。
なので、ソフトウエアの品質というのは、フレームワークである程度きまってしまう。
テストでカバーできる品質というのは、設計が間違っていない場合、その設計どおりにうごかすことが限界。
設計が矛盾している場合（設計どおり作ったら動かない場合、設計どおり作っても足りない場合）には、テストが収束しない（動かないんですから、テストできませんぜ ＾＾；）
まず、フレームワーク＋要素技術で、要求をどこまで満たせるかの品質のおおまかな枠組みが決まり、それを、設計で落とし込むことで、具体的に、要求を満たす品質がきまる。
ということで、フレームワークから要素技術、そして主要コンポーネント開発と行く。。。
あ、で、主線の話を書くっていうのを、前に書いた気がする。。。
わすれてた。。またこんどになっちゃった（＾＾；）
アクセス
トータル
ランキング
