这个属性字段能让团队把重点放在对整个进程影响最大的缺陷上。 
另一处由ODC评估结果引出的改进是让缺陷包含更多的信息，以便于对ODC分类的缺陷进行确认。这处改进对分类缺陷的团队也同样有用。提供更清晰的解释和说明，能够有效地对缺陷进行处理。
小结 这个项目使用ODC的时间刚好超过了一年。事实证明它是有价值的，当未达到传统的标准时，它能够帮助我们评估通过一个判断检查点时所产生的风险。
这个团队能够客观地查看他们的数据，而且很快就能确定出针对他们的过程和最终产品的改进措施。这些改进是合理的，不需要投入大量的时间、金钱或人力。通过对ODC的使用，测试团队达到了他们提高测试效率的目标。这项技术的价值在这个团队得到了证明，因此， ODC的使用范围也扩大到了其他的项目上。
Case Study 3: A small team project
案例3：一个小型团队项目
这个案例属于一个小型项目，由几个开发人员开发一个基于Java**的软件工具，其用途是让用户把与软件开发相关的数据进行可视化。这个工具支持ODC分析。这个产品的基本用户是整个IBM软件开发试验室中的测试人员、开发人员和服务人员。这个开发团队面临的挑战是：
缺少开发资源且经验有限 -- 这个团队缺乏面向对象编程和Java语言的开发经验，也没有工具开发方面的经验。此外，他们只有一点测试经验。团队成员们依靠一个功能检查表和他们自己的感觉来制定测试的内容。
时间进度上的压力 -- 他们经常要修复bug和增加功能，导致进度表越来越紧张。
客户需求 -- 用户要求这个工具必须能够大规模且成功地部署ODC。因此，为了最大限度地成功实现这项功能，它必须是一个高质量且稳定的产品。
ODC是有效管理资源、度量产品稳定性，以及指导团队进行高效测试的关键。
ODC过程 自产品的第一个版本发布以来，ODC已经得到了实践，但本文的关注点是产品在1.3版本中所做出的改进。到此版本可用时，团队已经有了ODC分类的经验。由于项目经理曾在过去的五年里做过ODC的顾问，在执行确认和评估方面有着丰富的经验，因此在执行评估的时候没有遇到“学习曲线”的问题。
评估 最初，他们计划在2000年的八月至九月间发布1.3版本。此版本的发布主要是解决一个软件bug，并没有增加新的功能。在计划发布的一个月前，团队成员们表达了他们的信心，产品已经为发布做好了准备。他们相信这次只是因为要修改bug，基本的功能都不会发生变化。他们已经花了几个星期的时间测试了新的代码，所以他们觉得时间进度不会在发生意外的变故了，产品能够按照原定的计划发布。然而，在他们进行了ODC评估后，却证明产品并没有做好发布的准备。
图10展现了相关的activity（活动）和triggers（触发器）。需要注意的第一点是只有15个缺陷。即使对于这个小型项目而言，功能和系统测试仍然会发现更多的缺陷。第二点，在功能测试中发现的缺陷数量和在用户界面检查中发现的缺陷数量一样多。但在产品的历史记录中，功能测试中发现的缺陷数量明显比GUI检查中的多很多。第三点，由coverage（覆盖）和variation（变量）可以证明，在功能测试中暴露的缺陷只是通过执行单个的功能发现的。通过点击按钮或执行简单的命令就可以很容易的发现这些缺陷。然而，在通常情况下，当每个活动上的缺陷都是通过大范围的triggers（触发器）发现的时，产品才是经过良好测试的产品。虽然在界面检查时发现的缺陷是通过各种不同的triggers（触发器）发现的，但功能和系统测试则没有。Coverage（覆盖）和variation（变量）只代表了此活动上的4个可用triggers（触发器）中的2个而已。在产品发布之前，还需要通过更复杂的triggers（触发器）进行测试。特别是，通过功能测试中的sequencing测试和系统测试中的workload/stress、software configuration测试发现更多的缺陷。 
图11展现的是ODC属性为age（码龄）的缺陷数量，进一步支持了产品还没有准备好发布的结论。其中有9个缺陷（占总数的60%）是在基础代码中发现的 – 缺陷在之前的版本中就已经存在了。这些是被隐藏的缺陷。本应该在之前的版本中发现却没有发现。因此，不仅通过执行单个的功能发现了缺陷，而且还有很大一部分的缺陷是在老代码（基代码）中发现的，并非在新代码中。此信息更进一步地支持了团队关于对代码没有进行充分测试的怀疑。所以依照情况，团队采取了唯一可能接受的措施。增加测试工作，推迟发布日期。 
为了提高测试效率，在variation、sequencing、interaction、software configuration和workload/stress区域里，添加了几个测试用例。图12展现了新增测试用例的测试结果，以及对应的ODC活动。 
