以上图为例，在项目开始时，项目可以根据过程能力基线并结合本项目的实际情况来设立缺陷密度目标；而在项目的生命周期里，可以使用这样的过程行为图（Process Behaviour Chart）来理解和控制项目的实际的缺陷密度。当项目的实际缺陷密度在UCL和LCL之间波动时，可以理解为项目的开发过程处于受控状态。换言之，当项目的实际缺陷密度超越了UCL或LCL时，可认为某异常的原因（Special Cause）导致了这一现象，必须进行分析并实施某种行动来防止该异常的原因再次发生，从而确保开发过程始终处于受控状态。
6. 持续优化
与CMM第四级相比，CMM第五级（或称为持续优化级）更强调对组织的过程进行持续性改进，从而使过程能力得到不断的提升。
就缺陷管理而言，软件组织应当在量化理解其过程能力的基础上，持续地改进组织级的开发过程、缺陷发现过程，引入新方法、新工具，加强经验交流，从而实现缺陷预防（Defect Prevention）。
缺陷预防的着眼点在于缺陷的共性原因（Common Cause）。通过找寻、分析和处理缺陷的共性原因，实现缺陷预防。
当实施了缺陷预防，缺陷密度的过程行为图将可表现为下图的形式。
7. 小结
软件的缺陷是软件开发过程中的重要属性，它提供了许多信息。不同成熟度的软件组织采用不同的方式管理缺陷。低成熟度的软件组织会记录缺陷，并跟踪缺陷纠正过程。高成熟度的软件组织，还会充分利用缺陷提供的信息，建立组织过程能力基线，实现量化过程管理，并可以此为基础，通过缺陷预防实现过程的持续性优化。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
