アカウント名:
パスワード:
そのバグが出た時の影響の度合いと発生する頻度の積を点数化して、一定の得点がないものは対処しないってのは、普通にシステム設計する時の基本的な考え方ですね。評価の基準をどうするかってのを決めるのがたいへんですが。
細かいことにこだわる“力のある”人物のクレームのリスクをどう評価するか、難しいところでしょうねぇ(苦笑)
そして、こだわる人とこだわらない人の力関係も・・・・
# 相手が一人だったら問題も大きくないのに・・・・
うちは影響度でやってましたね。ものすごくレアだけど、巻き込んでクラッシュするようなモノは対処するし、まあまあ再現するけれども機能に影響しない(例えば画面遷移するまでボタンが大きくなるとか)は対処しないとか。# 政治的に正しい言い方にすると「対処しない」→「いつまでに対処することが決定している or 対応策の目処が立っている」:-P
大切なのはバグの洗い出しは終わっており、再現状況も確定していることですかね。# 再現できないバグは、影響度不明なバグなのでクリティカルであるという定義
より正確な言い方をするのであれば「バグを残すのはNG」で「修正しない課題はOK」というところ。納期が何よりも重視される職場且つ下請けでもなんでもなかったのでできたところではあるかな:-)「ヘルプの英数字が統一されて無くて修正で1日納期が遅れちゃったよ」とか聞くと平和だなあと思います。# 時折、何を守らなければならないのかが明確になっていない人が居て関係者軒並みぶっ飛ばされるのをみると、# 日本はつくづく減点方式なんだなあと思ふことしきり# 生産に関わる人にしか判らない限定的な話題かも知れないけどID
># 政治的に正しい言い方にすると「対処しない」→「いつまでに対処することが決定している or 対応策の目処が立っている」:-P
その他の例:「次のサービスパックで対応予定です」
>ものすごくレアだけど、巻き込んでクラッシュするようなモノは対処するし、#組み込み系だと、ほとんど全部がクリティカルという世界もある気がする。#でも上の人には、その違いが全然理解できてない。あの人が死んでくれて本当にホッとしたよ。
問題は、リスク評価にかかるコストの方が往々にしてバグ修正に必要なコストより大きいことでというよりバグ修正にかかるコストの大半が分析と評価だったり。
ちゃんとテストをするなら
>リスク評価にかかるコストの方が往々にしてバグ修正に必要なコストより大きい
とはならない気がしますが・・・。
修正コストや修正による別なバグの発生リスク等も考慮してます。最終的には偉い人の一声で決まるけど。
"Take the number of vehicles in the field, a. Multiply it by the probable rate of failure, b. Multiply the result by the average out-of-court settlement, c. a × b × c = x If x is less than the cost of a recall, we don't do one."
"Are there a lot of these kinds of accidents?"
"You wouldn't believe."
"Which car company do you work for?"
"A major one."
ま、娯楽作品が皮肉を効かせたつもりで取り上げたり、こういう場でヨタ話をするレベルであれば、ものすごく大ざっぱに言って間違いではないですが…
その和解金を見積もるためには、前提としてその故障がどの程度のものかを見積もり、製造時の技術水準から見て回避困難であることを主張できなければなりません。実際問題ないレベルの話で、説明を尽くしても「理屈ばかりで誠意がない」とかって感情論が勝っちゃうことがままあるぐらいですから、技術的な評価結果も出せないようじゃ際限なくつり上げられるばかりで、そのセリフがいう状況自体が成り立ちませんよ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall
リスク評価 (スコア:5, すばらしい洞察)
そのバグが出た時の影響の度合いと発生する頻度の積を点数化して、一定の得点がないものは対処しないってのは、
普通にシステム設計する時の基本的な考え方ですね。
評価の基準をどうするかってのを決めるのがたいへんですが。
Re:リスク評価 (スコア:3, 興味深い)
Re: (スコア:0)
細かいことにこだわる“力のある”人物のクレームのリスクをどう評価するか、難しいところでしょうねぇ(苦笑)
そして、こだわる人とこだわらない人の力関係も・・・・
# 相手が一人だったら問題も大きくないのに・・・・
Re: (スコア:0)
自分の会社の経営者
リスクというよりは (Re:リスク評価 (スコア:3, 興味深い)
うちは影響度でやってましたね。
ものすごくレアだけど、巻き込んでクラッシュするようなモノは対処するし、
まあまあ再現するけれども機能に影響しない(例えば画面遷移するまでボタンが大きくなるとか)は対処しないとか。
# 政治的に正しい言い方にすると「対処しない」→「いつまでに対処することが決定している or 対応策の目処が立っている」:-P
大切なのはバグの洗い出しは終わっており、再現状況も確定していることですかね。
# 再現できないバグは、影響度不明なバグなのでクリティカルであるという定義
より正確な言い方をするのであれば「バグを残すのはNG」で「修正しない課題はOK」というところ。
納期が何よりも重視される職場且つ下請けでもなんでもなかったのでできたところではあるかな:-)
「ヘルプの英数字が統一されて無くて修正で1日納期が遅れちゃったよ」とか聞くと平和だなあと思います。
# 時折、何を守らなければならないのかが明確になっていない人が居て関係者軒並みぶっ飛ばされるのをみると、
# 日本はつくづく減点方式なんだなあと思ふことしきり
# 生産に関わる人にしか判らない限定的な話題かも知れないけどID
Re: (スコア:0)
># 政治的に正しい言い方にすると「対処しない」→「いつまでに対処することが決定している or 対応策の目処が立っている」:-P
その他の例:「次のサービスパックで対応予定です」
>ものすごくレアだけど、巻き込んでクラッシュするようなモノは対処するし、
#組み込み系だと、ほとんど全部がクリティカルという世界もある気がする。
#でも上の人には、その違いが全然理解できてない。あの人が死んでくれて本当にホッとしたよ。
Re:リスク評価 (スコア:1, すばらしい洞察)
問題は、リスク評価にかかるコストの方が往々にしてバグ修正に必要なコストより大きいことで
というよりバグ修正にかかるコストの大半が分析と評価だったり。
Re: (スコア:0)
ちゃんとテストをするなら
>リスク評価にかかるコストの方が往々にしてバグ修正に必要なコストより大きい
とはならない気がしますが・・・。
Re:リスク評価 (スコア:1)
修正コストや修正による別なバグの発生リスク等も考慮してます。
最終的には偉い人の一声で決まるけど。
Mischief, Mayhem, Soap (スコア:0)
"Take the number of vehicles in the field, a.
Multiply it by the probable rate of failure, b.
Multiply the result by the average out-of-court settlement, c.
a × b × c = x
If x is less than the cost of a recall, we don't do one."
"Are there a lot of these kinds of accidents?"
"You wouldn't believe."
"Which car company do you work for?"
"A major one."
Re:Mischief, Mayhem, Soap (スコア:1)
ま、娯楽作品が皮肉を効かせたつもりで取り上げたり、こういう場でヨタ話をするレベルであれば、ものすごく大ざっぱに言って間違いではないですが…
その和解金を見積もるためには、前提としてその故障がどの程度のものかを見積もり、製造時の技術水準から見て回避困難であることを主張できなければなりません。
実際問題ないレベルの話で、説明を尽くしても「理屈ばかりで誠意がない」とかって感情論が勝っちゃうことがままあるぐらいですから、技術的な評価結果も出せないようじゃ際限なくつり上げられるばかりで、そのセリフがいう状況自体が成り立ちませんよ。