解决哪些错误将带来最大的成本收益[关闭]

我想根据解决的难易程度以及它将给我带来多少好处来对错误进行分类。例如，如果有一个错误需要一个小时（双文件关闭等）来解决，而另一个错误则需要一天（分段错误）。但是，如果解决第一个错误不是很重要，那么我可能会研究第二个错误。

是否有任何研究论文根据成本效益或类似指标对错误进行分类？

假设可以根据漏洞特征（例如安全漏洞，内存错误，逻辑错误等）对漏洞进行分类。在另一个维度上，可能会存在诸如难度（容易，中等，困难）之类的参数。我应该寻找其他尺寸吗？为简化起见，我可以假设两件事：

1. 团队中的每个程序员都具有解决任何错误的能力
2. 没有截止日期

典型的错误跟踪系统有两个，可能三个字段来标识错误成本收益率：

1. 优先级（由企业主分配）
2. 严重性（错误分类-低至严重）
3. 估计的小时数（猜测需要多长时间）

如您所注意到的，这确实确定了哪个错误是重要的错误。

PEF / REV中提出的系统：多维错误跟踪度量标准添加了有关业务和开发人员组件的更多信息，以使错误成本受益。

所有值均在1 .. N刻度上（每个值均具有相同的最大值）。

PEF由企业识别：

• P艾因-臭虫如何痛苦的是
• Ë ffort -它花多少精力花费要解决的bug
• ˚F requency -没有错误发生多久

REV来自开发人员：

• [R ISK -如何有风险是固定的系统
• Ë ffort -多少努力是有修复的bug
• V erifiability -这多么容易验证的bug修复

例如，如果您遇到了很少发生的崩溃，并且很容易解决（打开自动保存），则其PEF可能为7,1,1（得分9）。修复时，可能需要更改核心模块，并且REV为9,3,2（分数14）。

另一方面，您可能会一直烦恼（3,3,9-得分15），而琐事（1,1,3-得分5）总是令人讨厌。

在此示例中，烦恼似乎是更好的成本/收益目标。

您所描述的问题非常普遍，最好的答案可能是“利用您的直觉”。

我通常将错误分为三类：崩溃，烦人，整容（它们可能被称为1、2、3-没什么关系），然后对修复每个错误所需的时间做出总体估算（所有错误都必须随时都有大概的更新估算值）。

当解决错误>崩溃>烦人>外观错误时，我只是简单地做“最短的工作”，以获得尽可能多的初始吞吐量。

我发现很难通过解决任何漏洞来计算任何直接的经济利益-除非它是范围非常狭窄的带薪工作。

您可能需要注意的一点是，您确实应该在Joel测试中达到第五点-这可能会受到团队规模和其他“本地”问题的分布的影响-但这通常是良好实践的标志。

另一个要考虑的因素可能是在试图确定错误和修复的影响以及成本时发现该错误的测试或测试组织的类型。单元测试或功能测试可能指向设计中需要更改的内容，因此与早期进行校正相比，尽早进行校正更容易且成本更低。系统或集成测试可能会影响到更多客户。标准测试虽然通常对大部分客户来说都不重要，但是如果不进行更正，可能会导致认证丢失，并对业务产生负面影响。

就是说，仅因为特定的测试组织遇到测试失败，就不应自动将错误定为“关键”。例如，可能会说“所有系统测试必须在发货前通过，因此任何自动失败的系统测试都会导致严重/严重性错误”。希望任何组织都不会发表这样的声明（好的测试退出标准是另一番讨论），但是重点是应该根据错误对客户，产品或公司形象的影响来判断错误的“严重性”，而不是在何时何地进行判断。被发现。

解决这个问题的一种可能方法是区分“严重性”和“紧急性”。例如，随着发布日期的临近，可能会有时间压力来确定一个严重程度较低的错误是否会影响大量客户，从而给该错误带来了更大的“紧迫性”，并使该错误的工作比其他（某些）情况高。至少可以确定。两者之间的适当平衡，以及经验和良好的判断力，将有助于确定在哪里花费时间和精力。

除了其他人对bug的分类等所说的以外，还可以考虑使用传入耦合（Ca）来确定特定bug可能表示的严重程度。如果您在Ca计数较高的模块中遇到错误，我可能会首先考虑修复该错误，因为它可能会使系统中的其他组件受益。Ca可以帮助您确定责任级别，责任模块中包含错误的内容会损害整个应用程序（在此处了解有关Ca的更多信息：http : //www.ibm.com/developerworks/java/library/j-cq04256/index.html）。

考虑到这一点，我们倾向于对错误进行分类，并根据它们对客户的影响将其置于优先位置。您的客户会有所不同，但是让他们参与讨论将最终推动应解决哪些错误而不是其他错误。这不是真正的科学，但是作为一个整体，我们倾向于在错误的优先级和类别上达成共识，每个人都对“大错误”进行投入（所有利益相关者都可以提供意见），然后我们从那里进行堆叠和整理。

您无法确定所有错误的实际成本。有些可以，很多都很难量化。例如，假设您有一个错误，该错误导致按钮上的所有文本稍有对齐。它使您的1.0产品显得有些草率。这不会导致程序崩溃或用户丢失数据。可能是一个相当便宜的错误，对不对？

现在，如果您的每个客户都注意到此问题，而每个审阅者都在您的产品评论中提到了该问题。而且，如果此错误从版本1.0延续到1.1和1.2。您的公司现在可能在质量控制方面有些草。就您的公司未来产品的潜在销售损失而言，这个简单的错误可能造成多大的损失？或者，这可能会如何影响您的产品获得的评论-您的产品可能会完全满足客户的需求，但由于看上去有点草率，所以只能获得十分之九的评价。

因此，您不仅需要根据修复的成本以及对用户的直接影响来查看特定错误的成本，而且还必须在更广泛的范围内考虑它对产品感知的影响。在市场上，以及这种看法如何影响未来的销售。

这似乎有些牵强，但事实并非如此。在撰写本文时，您可以转到Web上的另一个站点，该站点上有一篇文章介绍了Apple如何将其日历图标上的“ 1”移动了一两个像素。如果您进行搜索，将会看到一些有关此小错误的负面文章。当然，这并没有直接影响苹果的底线，但它们将自己提升为良好设计的顶峰，因此，即使只是轻微影响，设计缺陷也会影响这种看法。