Defect分析是软件开发和测试中一个重要的环节，ODC介绍了一种不同于大家常用的非常有效的defect分类及分析方法。这篇文章简单的向大家介绍了什么是ODC，以及如何在项目和产品开发中使用ODC来改进开发测试流程从而增强产品质量。希望读者具有基本的软件开发和测试经验，并且了解defect分析的基本方法。
软件开发中都包含有控制软件开发的流程。我们设计模块、开发代码、对产品进行测试、然后发布产品。但是，我们怎样从以前的错误中学习，怎样做得更好呢？一般情况下，我们会拿一些输出的数据来进行分析，从而知道我们应该怎么样和进行什么样的改进（如图1）。但是如何确定我们做的努力是真正有用的呢？这就是defect classification (defect分类) 能够帮助我们的地方，如果我们可以正确的使用defect classification，它会对我们有很多的帮助。
在软件开发过程中我们会在不同的阶段发现数量不等的defect，如图2所示，对于所发现的defect我们可以逐一的对它们进行分析，例如使用root causal analysis方法，可是这种分析方法占用了大量的时间和资源，显然我们非常需要有一种方法可以明确地告诉我们应该在哪里改进。
图2
下面我们来看看几种我们常见的defect 分析方法：
按照defect 严重程度分类
我们在测试过程中会根据defect的严重程度对defect 进行分类，在这里我们将严重度称为severity, 我们有如下图所示的一个项目不同测试阶段的defect的分布图：
图3
在这个图中defects跟据它们的severity属性进行了分类， severity为1的defect是最严重的defect, 它使系统根本不能运转，需要立即进行改正。那severity为 2的defect 是一般功能性的错误，这些错误是需求中所要求的，必须改正才能实现系统完整的功能。Severity 为3的defect是一些细小的错误，它们不影响功能的实现，但可能引起用户的误解或者使用不当。Severity为4 的 的defect是测试人员建议改进的地方，如果时间允许开发人员可以选择性的改正，或者等到下个版本中再改进。从图3中我们可以看到第一个图是在一个项目测试前期的时候，这时候1级的defect很多，整个系统还不能够运转，正需要大量的时间和人力进行测试和改正代码错误。第二个图则显示项目测试已经到了中期，这时候最严重的defect已经很少了，系统已经基本可以运转，然后测试人员发现了大量的功能性的错误和细节上的错误需要改正。第三个图显示了项目测试已经到了末期，这时的产品需求的功能已经实现，只有部分细节和建议需要改进，产品已经可以发布了。在用severity分类的图表中，我们可以了解到以下有关项目的几个方面：
1) 工作的优先级
2) 项目的进展状态
3) 产品的质量
按照component/module分类
对于不同的component或者module，我们也可以有类似的defect分布图来说明另外一些问题：
图4
图4中，对于第一个图，我们能看出C模块中发现的defect明显的比其他模块的少，那么原因可能是C模块的开发人员技术非常的好。第二个图中我们可以看出A和C中发现的defect明显比其他两个模块的多，那么可能这两个模块的难度、大小或者是改动的变化比较大，因此而造成了它们中发现的defect比较多。对于第三个图，C模块的defect明显比其他的多，那么可能是C模块的开发人员太差了，需要管理者的特别关注了。
