アカウント名:
パスワード:
「バグは一定の割合で必ず発生する」「バグを0にすることはできない」
これってもしかしてT系のチェックリストにありがちな、「ソースnステップ辺りm個のバグを検出させること」を律儀にやった結果なんじゃ
Ｈ社の優秀な技術者なら当然できること。「プログラムの作成が終わりましたので、引き続きバグの埋め込みとデバッグ作業に移ります。」
小規模なら「確率論的に検出されない事もあり得る」みたいな品質見解書いて提出しちゃうよ。
うちは品質部門にその手のケンカ吹っかけて「理由が説明できるならOK」となるようにもって行きました
Tじゃなかった、Hだ。お詫びして訂正します…
NだってFだってやってんじゃない？今はしらんけど過去の話ならＩだってやってたし
Fは今もやってますね
Nの今は知らないですが、20年以上前はやってました。品質会計票にステップ数に対するバグ検出件数指標があって、デバッグ回数に従ってバグ検出件数が期待値通りに減って行く事が求められました。
この指標よりもバグ現出数が極端に少ない場合、試験項目の不備という判断になります。逆に多すぎの場合は、開発メンバーの脳ミソが問題とされます。
拝承
バグが無くせないならdebugしなければいいじゃない(マリー・アンドオアノット)
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
海軍に入るくらいなら海賊になった方がいい -- Steven Paul Jobs
T系？ (スコア:1)
「バグは一定の割合で必ず発生する」「バグを0にすることはできない」
これってもしかしてT系のチェックリストにありがちな、
「ソースnステップ辺りm個のバグを検出させること」を律儀にやった結果なんじゃ
一人以外は全員敗者
それでもあきらめるより熱くなれ
Re:T系？ (スコア:3)
小規模なプログラムで仕様通りの動作をして特にバグもなかったのだけど、担当者からバグ収束曲線に近似した形で推移してくれないと困るとか言われて、どうでもいいことをわざわざバグ認定してちょろっと直してを何度かやりました。
最初からバグが少ないと「それだと困る」と言われる世界を初めて知りました。
完成後かなり経ってから、通常あり得ない操作をやると本来あるべき動作にならないという仕様上のバグに気づいてしまったのは内緒。
Re: (スコア:0)
Ｈ社の優秀な技術者なら当然できること。
「プログラムの作成が終わりましたので、引き続きバグの埋め込みとデバッグ作業に移ります。」
Re: (スコア:0)
小規模なら「確率論的に検出されない事もあり得る」みたいな品質見解書いて提出しちゃうよ。
Re:T系？ (スコア:2)
向こうの担当者もわかってくれているのだけど「なんとかお願いします」って。
「検出されないことも<あり得る>」なんてこと言ったらやぶへびです。
Re: (スコア:0)
うちは品質部門にその手のケンカ吹っかけて
「理由が説明できるならOK」となるようにもって行きました
Re:T系？ (スコア:2)
お客さんも馬鹿を説得するよりそれっぽく数値を作った方が余計な手間がかからないということでこっちにお願いしてきているわけで。
品質管理部門も杓子定規に変な本の受け売りみたいなことに執着しないで、物事の本質を見てほしいものです。
Re:T系？ (スコア:1)
Tじゃなかった、Hだ。
お詫びして訂正します…
一人以外は全員敗者
それでもあきらめるより熱くなれ
Re:T系？ (スコア:1)
NだってFだってやってんじゃない？今はしらんけど
過去の話ならＩだってやってたし
Re: (スコア:0)
Fは今もやってますね
Re: (スコア:0)
Nの今は知らないですが、20年以上前はやってました。
品質会計票にステップ数に対するバグ検出件数指標があって、デバッグ回数に従ってバグ検出件数が期待値通りに減って行く事が求められました。
この指標よりもバグ現出数が極端に少ない場合、試験項目の不備という判断になります。逆に多すぎの場合は、開発メンバーの脳ミソが問題とされます。
Re: (スコア:0)
拝承
ある意味サイバーノーガード戦法かもよ (スコア:0)
バグが無くせないならdebugしなければいいじゃない(マリー・アンドオアノット)