管理软件缺陷

软件中的缺陷（Defect或Bug）是软件开发过程中的"副产品"。通常，缺陷会导致软件产品在某种程度上不能满足用户的需要。

每一个软件组织都知道必须妥善处理软件中的缺陷。这是关系到软件组织生存、发展的质量根本。可遗憾的是，并非所有的软件组织都知道如何有效地管理自己软件中的缺陷。

本文从CMM的视角阐述了不同成熟度的软件组织如何管理自己软件中的缺陷。希望软件组织可以结合自己的实践，找到适合自己的缺陷管理过程。

个体行为

处于CMM第一级（或称为初始级）的软件组织，对软件缺陷的管理无章可循。工程师们只是在发现缺陷后，修改相应的软件。通常，没有人会去记录自己发现的缺陷。也没有人知道在新的软件版本里，究竟纠正了哪些缺陷，还有哪些缺陷未被纠正。而且，只有在下一轮测试中才有可能知道那些所谓已被纠正了的缺陷是否真的被纠正了，更重要的是纠正过程是否引入了新的缺陷。

所以这样的软件组织的项目交货期（Release Date）表现出强烈的不可预测性。并且， 为了获得一个高质量的软件产品（如果能够的话），通常要在测试上花费大量的人力。

项目行为

在CMM第二级（或称为可重复级）的软件组织中，软件项目会从自身的需要出发，制定本项目的缺陷管理过程。一个完备软件缺陷管理过程通常会包括如下几个方面：

· 提交缺陷

· 分析和定位缺陷

· 提请修改相应的软件

· 修改相应的软件

· 验证修改

项目组会完整地记录开发过程中的缺陷，监控缺陷的修改过程，并验证修改缺陷的结果。

组织行为

CMM第三级（或称为已定义级）的软件组织会汇集组织内部以前项目的经验教训，制定组织级的缺陷管理过程。并且，要求项目根据组织级的缺陷管理过程定制本项目的缺陷管理过程。

从而，整个软件组织中的项目都遵循类似的过程来管理缺陷。好的缺陷管理实践成为所有项目的实践，而教训也为所有项目所了解。更重要的是，随着组织的不断发展完善，组织的过程会得到持续性的改进，所有项目的过程也都会相应的改进。

量化管理

CMM第四级（或称为已管理级）的软件组织会根据已收集的缺陷数据，采用SPC的方法建立软件过程能力基线（Process Capability Baseline）。对于缺陷管理，可以缺陷密度为例，过程能力基线通常包括期望（Mean），能力上限（Upper Control Limit，UCL），能力下限（Low Control Limit，LCL）。其中，"期望"描述了未来项目的缺陷密度的预期值，而UCL和LCL描述了未来项目的缺陷密度的合理变化范围。

这样的过程能力基线可以用来：

(1)帮助未来的项目设立量化的项目质量目标；

(2)理解和控制未来项目的实际结果。

以上图为例，在项目开始时，项目可以根据过程能力基线并结合本项目的实际情况来设立缺陷密度目标；而在项目的生命周期里，可以使用这样的过程行为图（Process Behaviour Chart）来理解和控制项目的实际的缺陷密度。当项目的实际缺陷密度在UCL和LCL之间波动时，可以理解为项目的开发过程处于受控状态。换言之，当项目的实际缺陷密度超越了UCL或LCL时，可认为某异常的原因（Special Cause）导致了这一现象，必须进行分析并实施某种行动来防止该异常的原因再次发生，从而确保开发过程始终处于受控状态。

持续优化

与CMM第四级相比，CMM第五级（或称为持续优化级）更强调对组织的过程进行持续性改进，从而使过程能力得到不断的提升。

就缺陷管理而言，软件组织应当在量化理解其过程能力的基础上，持续地改进组织级的开发过程、缺陷发现过程，引入新方法、新工具，加强经验交流，从而实现缺陷预防（Defect Prevention）。

缺陷预防的着眼点在于缺陷的共性原因（Common Cause）。通过找寻、分析和处理缺陷的共性原因，实现缺陷预防。

当实施了缺陷预防，缺陷密度的过程行为图将可表现为下图的形式。

小结

软件的缺陷是软件开发过程中的重要属性，它提供了许多信息。不同成熟度的软件组织采用不同的方式管理缺陷。低成熟度的软件组织会记录缺陷，并跟踪缺陷纠正过程。高成熟度的软件组织，还会充分利用缺陷提供的信息，建立组织过程能力基线，实现量化过程管理，并可以此为基础，通过缺陷预防实现过程的持续性优化。

原文转自：http://www.ltesting.net