软件缺陷管理

作者:刘寅    文章来源:希赛网

关键词
  能力成熟度模型 (Capability Maturity Modela, CMMa),
  统计过程控制 (Statistical Process Control, SPC),
  软件开发 (Software Development)
  持续性改进 (Continuous Improvement)
1. 背景介绍
  软件中的缺陷(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)理解和控制未来项目的实际结果。

  以上图为例,在项目开始时,项目可以根据过程能力基线并结合本项目的实际情况来设立缺陷密度目标;而在项目的生命周期里,可以使用这样的过程行为图(Process Behaviour Chart)来理解和控制项目的实际的缺陷密度。当项目的实际缺陷密度在UCL和LCL之间波动时,可以理解为项目的开发过程处于受控状态。换言之,当项目的实际缺陷密度超越了UCL或LCL时,可认为某异常的原因(Special Cause)导致了这一现象,必须进行分析并实施某种行动来防止该异常的原因再次发生,从而确保开发过程始终处于受控状态。
6. 持续优化
  与CMM第四级相比,CMM第五级(或称为持续优化级)更强调对组织的过程进行持续性改进,从而使过程能力得到不断的提升。
  就缺陷管理而言,软件组织应当在量化理解其过程能力的基础上,持续地改进组织级的开发过程、缺陷发现过程,引入新方法、新工具,加强经验交流,从而实现缺陷预防(Defect Prevention)。
  缺陷预防的着眼点在于缺陷的共性原因(Common Cause)。通过找寻、分析和处理缺陷的共性原因,实现缺陷预防。
  当实施了缺陷预防,缺陷密度的过程行为图将可表现为下图的形式。
7. 小结
  软件的缺陷是软件开发过程中的重要属性,它提供了许多信息。不同成熟度的软件组织采用不同的方式管理缺陷。低成熟度的软件组织会记录缺陷,并跟踪缺陷纠正过程。高成熟度的软件组织,还会充分利用缺陷提供的信息,建立组织过程能力基线,实现量化过程管理,并可以此为基础,通过缺陷预防实现过程的持续性优化。
参考资料
  [1] Capability Maturity Model for Software, Version 1.1, Mark C. Paulk, Bill Curtis, Mary B. Chrissis, Feb 1993.
  [2] Understanding Variation--The Key to Managing Chaos,Second Edition,Ronald J. Wheeler, SPC Press

 
软件质量管理实践 ——软件缺陷预防、清除、管理实用方法 目录 前言 1 致谢 3 序 3 宣传语 4 目录 4 第4章 同行评审 5 4.1 同行评审与测试的关系 6 4.2 同行评审的种类和对象 7 4.2.1 同行评审的种类 7 4.2.2 同行评审的对象 8 4.3 同行评审过程 8 4.3.1 正式评审流程 9 4.3.2 技术审查流程 9 4.3.3 走查流程 10 4.4 同行评审方式的选择 10 4.4.1 三种同行评审方式的比较 10 4.4.2 同行评审的结果 11 4.4.3 正式评审的特征 11 4.4.4 工作产品的同行评审方式 11 4.5 迭代生命周期的审查 12 4.6 同行评审的注意事项 13 4.6.1 同行评审遵循的原则 13 4.6.2 同行评审关注的问题 14 4.6.3 同行评审通过的准则 14 4.6.4 同行评审的经验共享 14 4.6.5 文档审查重点 15 4.7 同行评审的度量 15 4.7.1 常用度量元 16 4.7.2 同行评审的质量准则 16 4.7.3 建议的同行评审效率 16 4.7.4 同行评审覆盖率 17 4.8 评审常见问题 17 4.8.1 文化问题 18 4.8.2 准备问题 18 4.8.3 焦点问题 19 4.8.4 人员问题 19 4.8.5 效率问题 20 4.8.6 效果问题 20 4.9 小结 20 第7章 软件度量 21 7.1 软件度量及其方针 22 7.2 度量活动 23 7.2.1 度量目标 23 7.2.2 度量元 25 7.2.3 度量模型 26 7.2.5 度量方法与采集(1) 28 7.2.5 度量方法与采集(2) 31 7.3 资源模型 32 7.3.1 资源模型的定义 32 7.3.2 项目级资源模型 34 7.3.3 组织级资源模型 35 7.3.4 软件质量度量 36 7.4 数据质量 37 7.4.1 数据的真实性 37 7.4.2 数据的同步性 37 7.4.3 数据的有效性 37 7.4.4 数据的一致性 37 7.5 软件度量相关问题 38 7.5.1 增加度量正确性的措施 38 7.5.2 软件过程性能 38 7.5.3 度量过程的常见问题 39 7.6 缺陷度量 40 7.6.1 什么是缺陷度量 40 7.6.2 缺陷度量元 41 7.6.3 缺陷密度的定义 41 7.6.4 缺陷密度的用途 42 7.6.5 缺陷管理库 42 7.7节"缺陷分析"。 43 7.7.1 缺陷种类分析 43 7.7.2 缺陷根源分析 44 7.7.3 缺陷注入-发现矩阵 45 7.7.4 收敛趋势分析 45 7.7.5 回归分析 48 7.7.6 缺陷排除分析 49 7.7.7 ODC缺陷分析 51 7.8 小结 51
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值