methodology - 品質とROI-十分なのはいつですか？

Question

更新：開発の観点からこれを求めていますが、説明のために、頭に浮かぶ標準的な非開発の例は、99％の稼働率を維持するためにたとえば10,000ドルかかる場合、理論的には100,000ドルかかる可能性があるということです99.9％のレートを維持するために、そしておそらく99.99％のレートを維持するために$1,000,000。

0に近づく微積分のように、100％に近づくと、コストが指数関数的に増加する可能性があります。したがって、開発者またはPMとして、時間と金銭的な制約を考慮して、成果物が「十分に良い」とどこで判断しますか。たとえば、99％、99.9％、99.99％で良好なROIを取得していますか。

開発の確かな指標がわからないため、開発以外の例を使用しています。たぶん、上記の例では、「稼働時間」を「ファンクションポイントと欠陥の比率」、またはコードの複雑さに対するバグのそのような合理的な測定率に置き換えることができます。また、ソフトウェア開発ライフサイクルのすべての段階に関する意見を歓迎します。

従来のプロジェクトの三角形の制約（品質、速度、コスト）を念頭に置いてください。そして、顧客が当初の予算で提供できる最高の品質を望んでいると仮定しましょう。

Answer 1

アプリケーションがダウンしたときに何が起こるかを知らずに、これに答える方法はありません。

• アプリケーションがダウンしたときに誰かが死亡した場合、稼働時間は数百万ドルまたは数十億ドルを費やす価値があります (航空宇宙、医療機器)。
• ソフトウェアがダウンして誰かが負傷する可能性がある場合、稼働時間は数十万ドルまたは数百万ドルの価値があります (産業用制御システム、自動安全装置)。
• ソフトウェアがダウンして誰かが数百万ドルを失った場合、稼働時間は数百万ドルを費やす価値があります (金融サービス、大規模な電子商取引アプリ)。
• ソフトウェアがダウンして誰かが数千ドルを失ったとしても、アップタイムには数千ドルを費やす価値があります (小売、小規模な e コマース アプリ)。
• ソフトウェアがダウンしたときにコンピュータが再起動している間、誰かがコンピュータを罵倒し、生産性を失う場合、稼働時間は (ほとんどの内部ソフトウェア) に何千ドルも費やす価値があります。
• 等

基本的に、(ダウンするコスト) x (ソフトウェアがダウンする回数) を取ると、アップタイムにどれだけ費やすべきかがわかります。

Answer 2

私が見た品質と十分な議論では、95％の欠陥修正で実用的なROIが得られます。明らかにストッパー/重大な欠陥が修正されていることを示します（そして、飛行機の自動操縦などの例外が常にあり、それほど多くの欠陥を持っている必要はありません）。

95％の欠陥修正への参照が見つからないようです。これは、RapidDevelopmentまたはCaperJonesによるAppliedSoftwareMeasurementのいずれかにあります。

コード品質を攻撃するための有用な戦略へのリンクは次のとおりです。http： //www.gamedev.net/reference/articles/article1050.asp

Answer 3

もちろん、クライアントはその数に躊躇する可能性が高く、年間 1 時間以内のダウンタイムは許容できると言うかもしれません。これは 12 倍の安定性です。申し訳ありませんが、100,000 ドルでそれを行うことはできません。それとも、分析が保守的であることを期待して、最善を尽くしますか?

顧客が望んでいることは合理的ではないことを率直に伝えます。そのようなアップタイムを得るには、莫大な金額が必要になります。また、現実的には、常にそのパーセンテージのアップタイムに到達する可能性はまったくありません。

私は個人的に顧客に戻り、100k で最適なセットアップを提供し、停止レポートのガイドラインを設定することを伝えます。たとえば、停止が発生するたびに、この停止が発生した理由と、停止が再び発生する可能性をほとんどなくすためにどのように対処するかについて調査を完了します。

SLA を提供することは単なる間違いだと思います。

Answer 4

同様に単純な方法で答えるために....顧客からの連絡をやめたとき（そして彼らがあなたの製品の使用をやめたからではない）..強化要求と花束を除いて:)

そして、それは三角形ではなく、4つのコーナーがあります-コスト時間の品質と範囲。

Answer 5

この質問に対する答えは、個々のアプリケーションに完全に依存すると思います。

人間の安全に影響を与えるソフトウェアの要件は、RSS フィード リーダーなどとは大きく異なります。

Answer 6

プロジェクトの三角形は大幅な単純化です。多くの場合、品質を向上させることで実際に時間を節約できます。たとえば、修理を減らし、メンテナンスのコストを回避します。これはソフトウェア開発だけに当てはまるわけではありません。トヨタの無駄のない生産は、これが製造業でも機能することを証明しました。

ソフトウェア開発のプロセス全体は複雑すぎて、コストと品質を一般化することはできません。品質は、複数の要因からなるあいまいな概念です。テスト可能なコードはパフォーマンスの高いコードよりも品質が高いですか? 保守可能なコードは、テスト可能なコードよりも高品質ですか? RSS リーダーまたはパフォーマンス コードのテスト可能なコードが必要ですか? フライバイワイヤ F16 の場合は？

ケースバイケースで情報に基づいた決定を下す方が生産的です。そして、品質に過度に投資することを恐れないでください。通常、過少投資よりもはるかに安価で安全です。

Answer 7

「品質」という言葉を追いかけることは、地平線を追いかけるようなものです。私は（ITの世界でも外部でも）100％品質のものを見たことがありません。常に改善の余地があります。

第二に、「品質」は過度に広い用語です。それは、実装の程度において、誰にとっても主観的なものとは異なる何かを意味します。

そうは言っても、あらゆる努力は「エンジニアリング」の意味に要約されます。つまり、コスト、時間、および主要な特性（速度、サイズ、形状、重量など）のバランスをとるための正しい選択を行うことです。これらは制約です。

Answer 8

「26 問中 17 問」の言葉をさらに発展させると、答えは顧客にとっての価値によって異なります。航空機のコントローラ アプリケーションなどの重要なソフトウェアの場合、顧客が使用する手段にかかわらず、高い品質評価の価値は非常に高くなります。RSS フィード リーダーのユーザーにとって、高品質の価値はかなり低くなります。

それはすべて顧客に関するものです（ユーザーとは言っていないことに注意してください-同じ場合もあれば、そうでない場合もあります）。