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

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

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

　　2. 个体行为

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

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

　　3. 项目行为

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

　　(1)提交缺陷

　　(2)分析和定位缺陷

　　(3)提请修改相应的软件

　　(4)修改相应的软件

　　(5)验证修改

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

　　4. 组织行为

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

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

　　5. 量化管理

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

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

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

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