软件企业的缺陷预防

来源:用户上传      作者: 王庆波

　　提要本文首先定义软件业中缺陷及缺陷预防的概念，简要分析软件企业进行缺陷预防的必要性。然后讨论了帕累托图、鱼骨图等方法在缺陷预防中的应用。最后在项目级和组织级两个层面上讨论了如何实施缺陷预防。
　　
　　一、软件业中缺陷的定义
　　
　　在软件过程中中，缺陷指软件与需求的不一致，常常指软件的功能和特性与设计说明书或用户需求不一致，也可称之为bug。但与通常所指的bug不同的是，缺陷不仅指代码级别的错误，而且可以是在设计和测试阶段发现的缺陷。
　　软件缺陷表现为：软件未达到产品说明书标明的功能；软件出现产品说明书指明不应出现的错误；软件功能超出产品说明书指明的范围；虽然产品说明书未指出但是软件应达到却未达到的目标；软件测试人员或用户认为软件难以理解，不易使用；运行速度缓慢等。
　　
　　二、缺陷预防及进行缺陷预防的原因
　　
　　每一个软件企业都必须妥善处理软件中的缺陷。这是关系到软件企业生存、发展的质量根本。然而目前大多数软件企业对缺陷的控制处在很混乱的状态中。项目中基本上延续着测试后发现错误，改正，再测试，再改正这样一个无序的过程。这样不仅不能保证缺陷被正确修正，而且对项目的成本和进度是一个巨大的威胁。
　　软件开发中的一个重要法则就是：缺陷发现越晚，修改成本越大，进度延误越严重。如果产品交付之后由客户发现缺陷并返回重新开发，对软件企业的质量声誉和开发成本都是巨大的打击。下面图1显示软件错误发现的时间和改正它的费用之间的关系。（图1）
　　因此，消除缺陷并不应简单对缺陷进行发现和纠正。等到缺陷被发现时，缺陷已经发生了，不利于节省项目成本和控制进度。从长远来看，企业要逐步提高质量，并在提高质量的同时不断控制、降低成本，就必须进行缺陷预防。在CMM（软件能力成熟度模型）中，5级中一个非常重要的关键过程域（KPA）就是缺陷预防。
　　缺陷预防（DP）指分析过去所遇到的缺陷，采取相应的措施消除产生这类缺陷的根本原因，防止同类的缺陷与问题在将来再次出现，以规范和优化企业内各项目的开发过程。这些缺陷可能发生在当前项目的早期阶段，也可能发生在其他项目中，所以缺陷预防活动是项目内部及不同项目间汲取经验教训的有效手段。
　　
　　三、缺陷预防的方法论
　　
　　缺陷预防的着眼点在于缺陷的共性原因。通过找寻、分析和处理缺陷的共性原因，实现缺陷预防。
　　（一）共性原因及其类型。共性原因指软件开发过程中引发一类缺陷的共同原因。每个企业都可以根据自身的实际情况在总结出自己的一套共性原因，并在项目实践中不断完善。一般来说，共性原因应该是有层次的，在底层应该非常细化，便于项目定位到这个具体的共性原因，以采取切实有效的措施进行消除。
　　举例来说，共性原因可分为内部和外部两方面。内部的原因可分为人员，环境，规范几个方面。人员方面又可具体分为：项目成员缺乏项目相关的业务知识；缺乏标准化的代码复审技能等。分析出具体的共性原因后，就可以指导后继项目在开始之初就有针对性地组织项目成员进行项目相关业务知识的培训及代码复审技能培训等。
　　外部共性原因可分为沟通，需求定义等几个方面。沟通方面又可以细化为：与国外客户交流的语言障碍；沟通渠道不流畅等。由此可以在组织级范围内采取加强员工外语能力的培训，建立规范化的沟通渠道等措施。
　　（二）帕累托图在缺陷分布分析和共性原因分析中的应用。帕累托法则，也称为80/20法则，是意大利经济学家维弗雷多・帕雷托在1906年提出的，说明了在现实生活很多事件中20％的原因引起80％的结果。帕累托图则是对帕累托法则形象化的反映，它按照事件发生的频度降序排列，用直方图显示由每一个识别出来的原因产生了多少结果（图2）。
　　
　　在软件开发中缺陷分布也服从帕累托法则，即80％的缺陷都属于20％的缺陷类型。把指定范围内（如编码阶段）各缺陷按缺陷类型分组，把各缺陷类型按照次数降序排列，以直方图显示，反映出包含80％的缺陷的20％的缺陷类型。说明应首先针对这20％的缺陷类型采取措施。这就是帕累托图在缺陷分布分析中的应用。同样，把指定范围内各缺陷分派到各自的共性原因中，按共性原因次数降序排列，标识出引起80％错误的20％的共性原因。这就是帕累托图在共性原因分析中的应用。通过对帕累托图的分析，可以清楚地对缺陷类型划分优先级，定位重点缺陷类型，并找到引发大多数错误的主要原因，便于采取针对性措施进行消除。
　　（三）鱼骨图在RCA中的应用。鱼骨图，也称特性要因图，用来表示导致问题的因素以及因素之间的关系，通过对原因再做细化分析，找出主要因子。
　　在根本原因分析（RCA）中，先找出产生问题的几大方面原因（如人员方面，制度方面等）作为“鱼骨架”，针对每方面原因再找出具体原因（如人员方面可分为成员技能不够，培训不足等），这样对“鱼骨”（原因）进行层层细分，直到细化为可以针对此原因制定具体的措施，这样被细化出来的原因就称之为根本原因。只有分析出深层的根本原因，而非停留在问题的表面，才能制定切实可行而有效的措施来消除缺陷。
　　
　　四、缺陷预防的实施
　　
　　在软件开发中项目组是基本的开发单位，软件企业制定的缺陷预防制度和措施必须在项目中得以实施。而项目组又必须依靠企业积累的缺陷预防的规范、工具和经验，才能有效地实施缺陷预防来保证质量、控制成本。因此，要从项目和组织两方面同时着手采取适当措施来实施缺陷预防。
　　（一）项目级缺陷预防实施。在缺陷预防的实施过程中，项目之间是彼此相互影响和有机联系的。项目开始之前项目成员要学习、吸收以前项目积累的DP经验，在开发过程中避免以前项目经常发生的错误。项目每一阶段及项目结束前要分析、总结本项目发生密度比较大的缺陷产生的原因，制定预防措施，并把经验传递到项目后继阶段及以后的项目中。因此，项目级缺陷预防实施可分为以下三个步骤。
　　1、缺陷预防开始会议。在项目开始或每一个开发阶段（如编码阶段，测试阶段）开始时，每一位项目成员都应该参加DP开始会议。
　　在会议中，首先应选出一位或几位经验丰富的成员担任本项目缺陷预防协调人,作为本项目缺陷预防的负责人。在组织级缺陷预防协调人的帮助下，项目组根据以前项目或本项目以前阶段总结出的经验，找出本项目后一阶段可能会发生的缺陷，并提前制定措施来预防缺陷的发生。
　　2、缺陷预防会议。在项目进行中要定期召开缺陷预防会议，一般为每周一次。在会议中通过对缺陷日志和代码复审表的分析，找出主要缺陷类型。大家分享在开发过程中各自消除这些缺陷时的经验和教训。在大家讨论的基础上，项目组制定后一阶段的DP行动计划，要求项目成员在开发过程中遵守。
　　3、RCA会议。在每一个开发阶段（如编码阶段，测试阶段）结束或项目结束时，或项目进行了较长时间后（如两个月），应进行根本原因分析会议。
　　在会议中，项目成员应利用帕累托图、鱼骨图等工具，找出主要的缺陷类型，分析出根本原因，并制定针对具体原因的各项措施，把经验记录在相关文档中，传到项目后继阶段或后期项目。
　　（二）组织级缺陷预防实施
　　1、组织级缺陷记录数据库。项目组应定期把项目的缺陷数据及记录缺陷预防会议、RCA会议内容的相关文档输入到组织级缺陷记录数据库中。在组织级缺陷记录数据库中，记录组织范围内的缺陷数据，如组织级范围内各个开发阶段的缺陷数量、缺陷分布等。只有以组织级缺陷记录数据库为基础进行分析，才能对组织的缺陷预防现状有一个清楚的把握，进而制定有效措施。
　　对组织级缺陷记录数据库的输入及分析、修改，应进行严格的角色控制。只有这样才能保证数据的准确。一般来说，只有项目级缺陷预防协调人，组织级缺陷预防协调人，项目经理和SQA有权限对此数据库进行操作。（图3）
　　
　　2、组织级缺陷预防会议。公司的高级管理人员和项目经理定期召开组织级缺陷预防会议。在会议中，应制定或修正组织的缺陷预防原则，以此指导整个组织缺陷预防活动的开展。另外要对组织级缺陷记录数据库进行分析，查出组织范围的共性原因，并制定组织级缺陷预防的措施，如加强公司员工代码复审技能培训等。
　　3、SEPG与组织级缺陷预防协调人。组织级缺陷预防会议制定原则和措施决议后，应该有一个组织来实施缺陷预防活动，软件工程过程组（SEPG）承担了这个职责。SEPG负责整个组织包括缺陷预防在内的各项软件过程的改进。SEPG在缺陷预防方面重点在于制定组织级缺陷预防计划，在项目中推广缺陷预防计划，及制定规范化的缺陷预防文档。
　　SEPG中应有专门负责缺陷预防的组织级缺陷预防协调人。他负责收集、整理整个组织内各项目的缺陷数据，根据对组织级缺陷记录数据库分析的结果，对组织的软件过程中缺陷预防部分进行修改、完善。他向组织级缺陷预防会议提供数据及建议，并指导各项目缺陷预防活动的开展。

转载注明来源:https://www.xzbu.com/2/view-414843.htm