アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
手段はともかく (スコア:1, 興味深い)
・前もって見積もったバグの量と比較するため？
・バグの再発を防ぐため？
・バグを作った原因をさぐるため？
・バグを上司に報告させるため？
・バグを直す
Re:手段はともかく (スコア:1, 参考になる)
「コードの行数あたりのバグ検出数」が、予言(藁)の値より小さかったら、
バグを探し直せ、と怒られるというプロジェクト運営を行なってくださる発注者を
経験したことが有ります。
ええ。勿論、まともなバグ報告なんて行なえなくなりました。
実際に見つかった数をどうやってそれ以上増やせってんだか。
どうということのない事象を「バグだ」とこじつけるとか、をする羽目になりましたね。
勿論そうすれば仕様書は逸脱するが、どうせ仕様書自体が曖昧模糊としたものだったので(藁)、
仕様書に「厳密に従う」方法が最初から存在しない…
Re:手段はともかく (スコア:2, 参考になる)
>バグを探し直せ、と怒られるというプロジェクト運営を行なってくださる発注者を
>経験したことが有ります。
>ええ。勿論、まともなバグ報告なんて行なえなくなりました。
>実際に見つかった数をどうやってそれ以上増やせってんだか。
コード行数あたりのバグ件数が、経験を元に算出した予想値より極端に小さければ、テスト不
Re:手段はともかく (スコア:0)
しかし、あくまでも母集団の統計的な指標で有意を判断するので、特異な(有能な)個人が多い(希な)Prjですと、全然バグ数が少なく、品質保証の担当部署から突っ込みが入ります。
ま、指標値を、どの位にすべきかはプロジェクト計画時のトピックになってしまうことが多々あります。 どの値を捻り出す、or 採用する、にしても合理的な根拠が必要な訳で。 ISO査察に耐えるのも大変ですわ。 (というとISOのauditの為の活動でなく業務品質維持向上の一環として取り組む姿勢が必要なのだという突っ込みが更に品証から・・・)