少し前に、社内プログラムの 1 つについて、アプリケーションのクラッシュを記録して分類するためのシステムを構築しました。当時、クラッシュの種類に優先順位を付けるために、頻度と失われた時間の合計 (プログラムの起動からクラッシュまでの時間) を組み合わせて使用していました。それはかなりうまくいった。
現在、The Powers That Be は、取り組んでいる各タイプのクラッシュのコストについて確実な数値を求めています。または、少なくとも、堅実に見える数字。総損失時間にもっともらしい数字を掛けたものを使用できると思いますが、それは危険に思えます。
アプリケーション クラッシュの実際のコストを計算する確立された方法はありますか? それとも、そのようなコストを推測する研究を発表しましたか?
正確さは不可能ですが、稼働時間に基づく見積もりは、それが一貫して適用され、その制限が明確に文書化されていれば十分です。これに答えるために時間を割いてくれてありがとう、マット、オリオン。
パワーズ・ザット・ビーは、取り組んでいる各タイプのクラッシュのコストについて確かな数字を求めています
熱気球で火星に行きたいのですが、そんなことができるとは限りません。
真剣に、これを正確に測定する方法がないことを彼らに伝える義務があると思います. クラッシュをランク付けできること、または実際にデータでできることは何でもよいことを伝えてください。ただし、それがすべてです。
「実際にどれくらいの費用がかかるかはわかりません。物事がどれくらいの時間実行されているかなどに関するこのデータはありますが、費用を付加する唯一の方法は、X 分が X ドルに等しいと仮定することです。これは現実には何の根拠もない」
でたらめなコスト計算アルゴリズムを作成し、まったく抵抗しない場合、経営陣が好転し、この恣意的に作られた数字を使用して消防士のような愚かなことをしたり、クラッシュを修正しないことを決定したりしたときに、責任を負うのは自分だけです。代わりに、SharePoint ポータル インターネット Web 共有 Love サーバー 2013 との相乗効果を活用することに重点を置きます。
更新:明確にするために言うと、100% の精度を持つ統計だけに頼るべきであり、他のすべてをあきらめるべきだと言っているわけではありません。
私が重要だと思うのは、何を測定しているのかを知ることです。実際にコストを測定しているのではなく、アップタイムを測定しています。そのため、あなたはそれについて率直であるべきです。コストを見積もりたい場合は結構ですが、これを明確にする必要があると思います..
このようなレポートを作成する場合、それを「クラッシュ アップタイム レポート」と呼び、「5 ドル/分に基づく推定コスト」という 2 番目のフィールドを作成することになるでしょう。マネージャーはコストの見積もりを取得しますが、実際のレポートが稼働時間に基づいていること、コストが見積もりにすぎないこと、および見積もりがどのように機能するかは明らかです。
私は研究を見たことがありませんが、合理的なヒューリスティックは次のようになります:
(クラッシュが発生したときに最後にアプリケーションを保存してからの時間 + アプリケーションを再起動するまでの時間) * アプリケーション オペレーターの平均時給。
クラッシュが外部の顧客に何らかの影響を与えたり、他のことを遅らせる可能性がある場合 (つまり、他の人のアプリケーションがクラッシュしたために別の人が座って待っているなどのボトルネックが発生する場合)、見積もりはより複雑になります。
とはいえ、それが一貫して適用され、時間の経過とともにどのように変化するかを見ることができる限り、あなたの「あるべき力」は非常に大まかな見積もりに満足するかもしれません.
ここに欠けている要素があります..ほとんどのアプリケーションには、アプリが提供するサービスに対する人々の信頼が失われるため、クラッシュが突然「費用がかかり」始める「座屈」要素があります。これが発生すると、ユーザーがシステムを信頼して使用できるように戻すに は、非常にコストがかかる可能性があります。
場合によります...
コストに関しては、問題はクラッシュによるビジネスへの影響だけなので、むしろアプリケーションの種類に依存します。
多くのアプリケーションでは、ビジネスへの影響を判断できない場合があります。他の人にとっては、意味のある対策があるかもしれません。
需要ベースの測定は意味がある場合があります。売上が安定している場合は、販売アプリのダウンタイムが役立つ場合があります。売上が予測できないほど変動する場合、そのような手段はあまり役に立ちません。
修理費用も参考になります。