软件质量管理的信任机制——确认.docx

本书从软件质量管理的流程和技术方法等方面对软件质量管理体系进行了详尽的讲述，并对日常工作中的案例进行剖析，使广大软件质量管理人员能够更加清楚了解和掌握软件质量管理的精髓。本书以CMMI软件能力成熟度模型为主线，穿插了PMP项目管理和软件测试技术的相关知识，从而形成了一套完整的软件质量管理理论。因此，本书是软件企业进行过程改进或CMMI认证的辅导资料，同样也可以作为PMP和软考“信息类项目管理师”考试材料的补充。作者：张瑾第1章 软件质量管理的信任机制确认人们的日常生活往往离不开对各种各样的事情进行确认，例如：当使用信用卡的时候，服务员会要求顾客确认银联回执单上的金额，然后在上面签字；当顾客在银联回执单上签字后，服务员还要确认签字笔迹是否与信用卡上的相符；当一对恋人打算结婚的时候，他们都会去民政局进行婚姻登记，以在法律上确认他们的合法关系，当然在婚姻登记时也需要男女双方签字确认。在软件研发过程中也离不开各种确认的工作，例如：甲乙双方签订合同时，要对合同上的金额、完工时间、项目范围等内容进行确认，确认后要双方签字、盖章；当需求人员在完成软件需求说明书后，为了减少需求的变更，往往也会给客户进行确认。由此可见，确认是一种行为，该行为的方式有很多，既可以通过口头方式进行确认，也可以通过书面形式进行确认。确认的深层含义是承诺，换句话说一个人的承诺是通过确认的方式来体现的。例如：顾客不在银联回执单上签字，那么就代表顾客否定了本次交易，这是一种相反的承诺，那么银行就会按照顾客的这种承诺拒绝付款给商家；当一对恋人没有进行婚姻登记，那么在法律上也就没有给彼此一个共同生活的承诺，因此他们还有权力选择他人；在软件研发过程中如果客户没有对软件需求说明书的内容进行确认，也就是他没有给出承诺，那么再发生需求变更时他也不会感到愧疚。确认（Validation）简称VAL，确认管理是软件工程体系中的一名新成员，它与配置管理、风险管理、度量管理等分支同等重要，是软件质量体系中不可或缺的环节。确认是指对软件研发生命周期中某个过程所产出的工作产品进行的审查，这些工作产品可以是软件需求说明书、合同等文档，也可以是开发出来的组件或最终产品，甚至可以是对某个生命周期阶段进行的整体审查。确认的目的就是确保某个过程或阶段“做对的工作产品”，并使它符合使用者的期望，并且只有通过审查后的工作产品才能交付给“使用者”使用。在软件研发过程中有两个重要的确认过程是众所周知的，一个是“客户”对软件需求说明书的确认，另一个是项目组开发出来的最终产品要在客户现场进行验收测试，以确认该产品是否符合“客户”的需要。这两个确认都是针对客户方的，但是在确认管理过程中却是不使用“客户”两个字的，而用“使用者”来代替“客户”，这是为了避免广大软件从业人员对确认过程的误解。软件需求说明书是软件项目范围的依据，它用来描述软件产品的功能，软件产品的最终“使用者”就是“客户”；验收测试的目的就是确保产品达到“客户”也就是最终“使用者”的要求。但在软件确认管理中并不是只有“客户”才需要对项目的工作产品进行确认，项目组或公司内部同样需要对某些工作产品进行确认，而这种确认往往非常关键，但进行确认的人却不是合同的甲方，因此在软件确认管理中要用“使用者”这个名称来对它进行代替。那么什么时候才会出现项目组内部的确认呢？很多人对这个事情都有疑问，这是可以理解的，因为在早期的软件工程中谈及确认管理的内容是非常少的。但项目组内的确认工作是天天都在进行的，例如：对概要设计文档进行评审并且合格通过后，与会人员都会在评审记录上签字。这个过程中就“包含”了确认的内容。但有人又会说同行评审是“验证”的过程，怎么会包含确认的内容呢？大家可以想想，首先确认的目的是承诺，那么签字就代表了与会人员对概要设计文档的正确性进行了承诺。其次参加本次评审的人员中一定会有软件开发人员，软件开发人员将是这份概要设计文档的“使用者”，只有“使用者”对该工作产品的质量进行确认后才能被使用。因此，在对概要设计文档进行评审时，这个过程除了对概要设计文档的内容进行验证，与会人员中的“使用者”还要对其内容是否符合要求并且是否可以指导软件开发人员的工作进行确认。由此可见，在软件生命周期内凡是一个环节“输出”的工作成果都将成为后续环节的“输入”，那么上一个环节的生产者要承诺该工作产品是符合质量要求的，后续环节的“使用者”也要对其工作产品进行确认。这就好比“亲兄弟明算账”，通过这样的方式来建立相互间的信任关系。1.1. 软件确认流程及最佳实践为了确保对工作产品确认的效果，通常建议该工作产品在仿真环境下进行审查，因此建立确认的环境是确认管理中的一个部分。一个软件项目所产出的工作产品非常多，仅配置项列表中的内容就有几十项，项目组需要在项目计划阶段识别所需进行确认的工作产品。确认是以使用者的视角来对工作产品进行审查，因此要在制订项目计划时就确定哪些项目关系人要对哪些工作产品进行确认。接下来我们对确认管理的流程和最佳实践进行举例讲解。1.1.1. 确认的准备工作确认工作在准备阶段包括以下3个方面的内容，这些内容都应该在项目计划阶段完成： 选择需要确认的工作产品与产品组件 建立和维护确认环境 建立确认的流程及准则1选择需要确认的工作产品与产品组件在选择需要确认的工作产品和产品组件时，可以根据项目的生命周期模型，并配合项目配置项列表来进行识别。配置项列表中的内容都是项目关键的工作产品，因为配置项是项目基线的组成部分，虽然并不是所有配置项都需要进行确认，但是确认管理的工作还需要很多资源、时间和成本的投入，这要根据项目的实际情况进行确定。在识别完待确认的对象后就应该为它制订相应的确认方法，并确定参与确认的角色。软件项目中确认的方法有以下两大类，软件生命周期中常见的确认内容及方法如表3-1所示。 对文档类型的工作产品进行确认，通常可以与其文档的评审合并进行。 对产品或产品组件进行确认时，通常可以与单元测试、集成测试、系统测试和验收测试合并进行。表3-1 软件项目中参加的确认内容及确认方法项目生命周期确认内容确认方法确认目的确 认 人需求阶段需求调研计划评审确保需求调研计划时间安排合理需求调研人员承诺可以按计划的时间参加需求调研的活动客户需求阶段软件需求说明书评审或 原型展示承诺需求尽量不发生变更客户确保软件功能可以实现项目组成员系统规格说明书评审或 原型展示承诺需求尽量不发生变更客户确保软件功能可以实现项目组成员计划阶段项目过程定义书评审确保所定义的过程是合理的项目组成员项目估算表评审确保项目估算的过程是合理的项目组成员项目计划及其 从属计划评审承诺可以提高所需的资源公司高层确保项目计划是合理的项目组成员设计阶段概要设计说明书评审承诺设计的内容合理有效软件设计人员确保概要设计的内容可以实现软件开发人员详细设计说明书评审承诺设计的内容合理有效软件设计人员确保概要设计的内容可以实现软件开发人员产品集成方案评审承诺产品基础的方案是合理有效的软件设计人员确保产品集成顺序是合理的软件开发人员编码阶段产品组件单元测试承诺代码的质量是合格的软件开发人员确保代码的功能是正确的软件测试人员集成后的产品 或组件集成测试承诺产品或组件的质量是合格的软件开发人员确保产品或组件的功能是正确的软件测试人员系统测试阶段产品或组件系统测试承诺产品的质量已经符合要求软件测试人员确认产品是否可以发布项目经理用户验收阶段产品验收测试承诺软件产品已经完成并且达到质量标准项目经理确认产品是否可以验收，项目是否可以结束客户在项目计划阶段通过对配置项列表中的配置项进行识别，挑选适当的工作产品在项目过程中进行确认，并将挑选出来的内容记录在确认清单或项目计划中，其流程如图3-1所示。2建立和维护确认环境确认工作的开展最好是在“使用者”的环境下进行，只有这样才能证明该工作产品的质量和功能是否符合“使用者”的要求。但在软件研发过程中这个前提条件并不一定完全可行，在建立确认环境时往往也要考虑确认的方法。例如：要对软件需求说明书进行确认，确认的方法是“评审”，开评审会所需要的环境通常是一间会议室，最好有白板、各种颜色的水笔、投影等设备，不管是甲方还是乙方召开软件需求说明书的评审，这些配备都是相同的。再例如对开发阶段集成后的产品或组件进行确认，往往是通过执行集成测试用例来完成的，由于确认的对象是代码，所以集成测试用例通常是由白盒测试技术实现的。在进行此种确认时，软件测试人员是该工作产品的“使用者”，但该确认的方法却是一种开发的技术，所以在软件测试人员的系统测试环境中是无法进行的。图3-1 选择确认的产品“环境”在软件工程中包含了两方面的内容：一个是以硬件设备为主的“硬环境”；另一方面是确认流程和准则的“软环境”。当项目组要对某一个工作产品开展确认活动时，制订配套的流程和准则是必不可少的。如果通过评审的方式进行确认，那么评审的议程应该提前制订，评审过程中的评判标准需要提前制订，否则就会出现无休止的争论。如果通过技术手段对工作产品进行确认，那么部署该工作产品的步骤要提前制订，否则产品部署出现问题，那么确认也就无法进行。软件研发过程中常用的确认环境如表3-2所示。表3-2 软件研发过程中常用的集成环境项目生命周期确认内容确认方法确认准则需求阶段需求调研计划评审客户方同意并签字确认软件需求说明书评审或原型展示客户方同意并签字确认；软件需求说明书中的每个功能都必须在评审中覆盖到；在评审时发现的严重和较严重级别的缺陷必须修复系统规格说明书评审或原型展示与会人员一致同意并签字确认；系统规格说明书中的每个功能都必须在评审中覆盖到；在评审时发现的严重和较严重级别的缺陷必须修复计划阶段项目计划及其从属计划评审项目组成员要同意并签字确认；公司高层领导要签字确认设计阶段概要设计说明书详细设计说明书产品集成方案评审软件开发人员要同意并签字确认；设计文档中的每个方法在评审时要被覆盖到；在评审时发现的严重和较严重级别的缺陷必须修复编码阶段产品组件单元测试软件开发人员要同意并签字确认；单元测试用例执行率要达到100%；单元测试代码行覆盖率平均要达到40%；单元测试中所发现的所有缺陷必须被修复；单元测试用例执行结果必须全部为通过集成后的产品或组件集成测试软件测试人员要同意并签字确认；集成测试用例执行率要达到100%；集成测试代码行覆盖率平均要达到30%；集成测试中所发现的所有缺陷必须被修复；集成测试用例执行结果必须全部为通过系统测试阶段产品或组件系统测试项目经理或软件测试经理要同意并签字确认；系统测试用例执行率要达到100%；产品功能覆盖率要达到100%；系统测试中所发现的严重或较严重级别的缺陷必须修复；系统测试中所发现的严重级别较低的缺陷必须修复80%用户验收阶段产品验收测试客户要同意并签字确认；验收测试用例执行率要达到100%在项目计划阶段制订确认环境时有可能会引发“Make or Buy”的决策或其他方面的变更。例如某项目要对代码进行确认，但是没有独立的编译服务器或日构建服务器，此时就会导致采购的发生，因此也会造成项目预算的变更。确认工作所使用的环境是确认的约束条件，同样也是项目约束条件之一，因此项目经理要在项目进度计划中增加相关的活动并分派相应的资源。当发现由确认导致的采购时，就需要对此约束按照项目监控的流程进行管理，否则确认环境不能按时到位，会影响项目的进度和产品的质量。建立确认环境的流程如图3-2所示。图3-2 建立确认的环境3建立确认的流程及准则在讲述建立确认环境时特别提到了“配套的流程和准则”，除了部署工作产品和搭建确认环境的流程外，还包含了判断本次确认是否通过的准则。这些判断的准则往往来源于： 产品或产品组件的需求 国际或行业的标准 客户方验收的标准 项目绩效的评判标准不同的软件公司对质量的要求是不同的，因此在制订确认准则时也不尽相同，一般的确认准则如表3-3所示。图3-3 制订确认的准则识别确认的对象、制订确认的方法、建立确认的环境、定义确认的准则都是确认准备阶段的工作，其目的是为了让“使用者”更好地接受放置在确认环境中工作产品的表现情况。1.1.2. 执行确认在确认管理的准备工作完成以后，就将按照既定的流程和准则在确认环境中执行并收集确认的结果。然后将确认的结果与评估的准则进行比较，当发生偏差时应该及时进行识别并制订相应的措施，最后根据偏差的程度判断确认工作是否还需要继续进行，其流程如图3-4所示。确认过程中的偏差往往有以下3种可能： 工作产品质量问题。 确认环境没有搭建好，而导致工作产品在该环境中出现偏差。 制订的确认准则不合理。1.2. 软件确认过程中常见问题及案例分析软件确认过程是以往软件工程中讲述不多的内容，但在软件研发过程中很多产品质量缺陷、项目进度偏差、项目成本偏差都是由于确认工作没有做好而导致的。以下通过几个案例来对它进行深入分析。图3-4 软件确认的执行过程1.2.1. 为什么开发和测试之间总是反复【案例】最近某软件公司GIS项目组负责人小黎头痛不已，项目已经进展到系统测试阶段，软件开发人员提交给测试组的产品总是无法通过系统测试，甚至一天出现两三次产品内部的发布，软件开发和测试人员都被加班压得透不过气来。软件开发和测试人员之间的埋怨也越来越多，开发人员认为软件测试人员在挑他们的毛病。软件测试人员总是觉得产品质量实在太差，还没有怎么测试系统就不能使用，这样的产品就不应该发布。可是软件开发人员却认为他们做过了单元测试和集成测试，所以提交的产品质量是合格的。项目负责人小黎觉得这个问题必须尽快解决，开发与测试之间的反复已经导致项目延期了一周的时间，以这样的情况发展下去还有可能恶化。更重要的一点是项目团队成员之间出现了矛盾，软件开发和测试人员之间已经越来越缺乏信任，这样下去将导致项目彻底崩溃。【分析】项目负责人小黎找到项目总监张经理，希望得到他的帮助。项目总监经过对项目组成员的访谈以及实际查看了项目的代码后，发现项目组发生的问题都是因为没有对工作产品进行确认而导致的。本着“亲兄弟明算账”的原则，软件开发人员必须证明他们提交的工作产品已经符合了质量的要求，软件测试人员也要确认开发人员所讲的是否是真实的。公司已经规定了单元测试代码平均覆盖率至少为60%，集成测试用例代码平均覆盖率至少为45%，那么确认的准则已经存在，就应该按照此准则进行确认。小黎按照张总的要求对项目组下达了对每次发布必须进行确认的任务，这下产品内部的发布戛然而止，原因是开发人员注意到他们的单元测试用例和系统测试用例很多都是重叠的，代码覆盖的比例达不到公司的要求，因此他们需要增加新的测试用例。在随后的日子中通过增加单元测试用例和集成测试用例又发现了很多产品质量的缺陷。通过采取对工作产品进行确认后，产品只经过了两轮的反复就通过了系统测试，而且开发和测试人员之间的矛盾也大大降低了。1.2.2. 确认是对需求变更的约束【案例】某软件公司人力资源管理系统的项目经理小白非常开心，因为他的项目已经顺利通过验收。虽然项目过程中发生了一大一小两次需求的变更，但是项目的进度、成本并没有发生什么偏差。公司领导让小白对他的项目进行总结，并且将心得体会与其他项目组成员进行分享。小白在他的项目经验总结中就提到了一点：“需求的确认工作是对需求变更的约束”。【分析】小白在项目需求调研阶段就把软件需求说明书拿出来让客户进行了确认，客户通过对需求说明书的评审了解到他们所提出来的内容已经完全包含在软件需求说明书中，由于软件需求说明书的内容非常细致，因此客户对本次合作充满信心，所以很痛快地就进行了确认。但在设计和编码开发阶段分别发生了一次需求的变更，主要原因是客户方忽略了一些需要实现的功能而没有告诉项目组，但是客户又对软件需求说明书进行了确认。由于第一次变更的影响不大，小白决定免费为其进行修改，并且将变更后的软件需求说明书给客户进行再次确认，客户对小白的工作态度非常满意。当在编码阶段发生再次需求变更时，小白将变更的影响告知了客户，并且提示客户方已经先后两次对需求进行了确认，希望可以对此次变更增加相应费用。客户方的代表也觉得自己有一定责任，所以就相应延长了项目的时间并增加了项目的费用，直到最后项目顺利交付。因此小白在本次项目中最大的收获就是体会到软件确认管理给项目需求变更带来的好处。1.3. 小结软件确认管理可以使软件研发“流水线”前、后环节中的操作人员增加彼此之间的信任感，而减少互相间推卸责任的理由。软件确认管理可以确保软件生命周期中的每个阶段都按部就班地开展工作，避免了外界或人为的因素而导致项目出现混乱，它是让项目“冷静”下来的重要手段。1.4. 思考题1软件确认的准备工作有哪些？2常用的确认方法有哪两大类？3确认是如何来提高团队合作信任感的？