《软件质量管理的信任机制之确认》由会员分享，可在线阅读，更多相关《软件质量管理的信任机制之确认（11页珍藏版）》请在金锄头文库上搜索。
1、本书从软件质量管理的流程和技术方法等方面对软件质量管理体系进行了详尽的讲述，并对日常工作中的案例进行剖析，使广大软件质量管理人员能够更加清楚了解和掌握软件质量管理的精髓。本书以CMMI软件能力成熟度模型为主线，穿插了PMP项目管理和软件测试技术的相关知识，从而形成了一套完整的软件质量管理理论。因此，本书是软件企业进行过程改进或CMMI认证的辅导资料，同样也可以作为PMP和软考“信息类项目管理师”考试材料的补充。作者：张瑾第1章 软件质量管理的信任机制确认人们的日常生活往往离不开对各种各样的事情进行确认，例如：当使用信用卡的时候，服务员会要求顾客确认银联回执单上的金额，然后在上面签字；当顾客在银
2、联回执单上签字后，服务员还要确认签字笔迹是否与信用卡上的相符；当一对恋人打算结婚的时候，他们都会去民政局进行婚姻登记，以在法律上确认他们的合法关系，当然在婚姻登记时也需要男女双方签字确认。在软件研发过程中也离不开各种确认的工作，例如：甲乙双方签订合同时，要对合同上的金额、完工时间、项目范围等内容进行确认，确认后要双方签字、盖章；当需求人员在完成软件需求说明书后，为了减少需求的变更，往往也会给客户进行确认。由此可见，确认是一种行为，该行为的方式有很多，既可以通过口头方式进行确认，也可以通过书面形式进行确认。确认的深层含义是承诺，换句话说一个人的承诺是通过确认的方式来体现的。例如：顾客不在银联回执
3、单上签字，那么就代表顾客否定了本次交易，这是一种相反的承诺，那么银行就会按照顾客的这种承诺拒绝付款给商家；当一对恋人没有进行婚姻登记，那么在法律上也就没有给彼此一个共同生活的承诺，因此他们还有权力选择他人；在软件研发过程中如果客户没有对软件需求说明书的内容进行确认，也就是他没有给出承诺，那么再发生需求变更时他也不会感到愧疚。确认（Validation）简称VAL，确认管理是软件工程体系中的一名新成员，它与配置管理、风险管理、度量管理等分支同等重要，是软件质量体系中不可或缺的环节。确认是指对软件研发生命周期中某个过程所产出的工作产品进行的审查，这些工作产品可以是软件需求说明书、合同等文档，也可以
4、是开发出来的组件或最终产品，甚至可以是对某个生命周期阶段进行的整体审查。确认的目的就是确保某个过程或阶段“做对的工作产品”，并使它符合使用者的期望，并且只有通过审查后的工作产品才能交付给“使用者”使用。在软件研发过程中有两个重要的确认过程是众所周知的，一个是“客户”对软件需求说明书的确认，另一个是项目组开发出来的最终产品要在客户现场进行验收测试，以确认该产品是否符合“客户”的需要。这两个确认都是针对客户方的，但是在确认管理过程中却是不使用“客户”两个字的，而用“使用者”来代替“客户”，这是为了避免广大软件从业人员对确认过程的误解。软件需求说明书是软件项目范围的依据，它用来描述软件产品的功能，软
5、件产品的最终“使用者”就是“客户”；验收测试的目的就是确保产品达到“客户”也就是最终“使用者”的要求。但在软件确认管理中并不是只有“客户”才需要对项目的工作产品进行确认，项目组或公司内部同样需要对某些工作产品进行确认，而这种确认往往非常关键，但进行确认的人却不是合同的甲方，因此在软件确认管理中要用“使用者”这个名称来对它进行代替。那么什么时候才会出现项目组内部的确认呢？很多人对这个事情都有疑问，这是可以理解的，因为在早期的软件工程中谈及确认管理的内容是非常少的。但项目组内的确认工作是天天都在进行的，例如：对概要设计文档进行评审并且合格通过后，与会人员都会在评审记录上签字。这个过程中就“包含”了
6、确认的内容。但有人又会说同行评审是“验证”的过程，怎么会包含确认的内容呢？大家可以想想，首先确认的目的是承诺，那么签字就代表了与会人员对概要设计文档的正确性进行了承诺。其次参加本次评审的人员中一定会有软件开发人员，软件开发人员将是这份概要设计文档的“使用者”，只有“使用者”对该工作产品的质量进行确认后才能被使用。因此，在对概要设计文档进行评审时，这个过程除了对概要设计文档的内容进行验证，与会人员中的“使用者”还要对其内容是否符合要求并且是否可以指导软件开发人员的工作进行确认。由此可见，在软件生命周期内凡是一个环节“输出”的工作成果都将成为后续环节的“输入”，那么上一个环节的生产者要承诺该工作产
7、品是符合质量要求的，后续环节的“使用者”也要对其工作产品进行确认。这就好比“亲兄弟明算账”，通过这样的方式来建立相互间的信任关系。1.1. 软件确认流程及最佳实践为了确保对工作产品确认的效果，通常建议该工作产品在仿真环境下进行审查，因此建立确认的环境是确认管理中的一个部分。一个软件项目所产出的工作产品非常多，仅配置项列表中的内容就有几十项，项目组需要在项目计划阶段识别所需进行确认的工作产品。确认是以使用者的视角来对工作产品进行审查，因此要在制订项目计划时就确定哪些项目关系人要对哪些工作产品进行确认。接下来我们对确认管理的流程和最佳实践进行举例讲解。1.1.1. 确认的准备工作确认工作在准备阶段
8、包括以下3个方面的内容，这些内容都应该在项目计划阶段完成： 选择需要确认的工作产品与产品组件 建立和维护确认环境 建立确认的流程及准则1选择需要确认的工作产品与产品组件在选择需要确认的工作产品和产品组件时，可以根据项目的生命周期模型，并配合项目配置项列表来进行识别。配置项列表中的内容都是项目关键的工作产品，因为配置项是项目基线的组成部分，虽然并不是所有配置项都需要进行确认，但是确认管理的工作还需要很多资源、时间和成本的投入，这要根据项目的实际情况进行确定。在识别完待确认的对象后就应该为它制订相应的确认方法，并确定参与确认的角色。软件项目中确认的方法有以下两大类，软件生命周期中常见的确认内容及方
9、法如表3-1所示。 对文档类型的工作产品进行确认，通常可以与其文档的评审合并进行。 对产品或产品组件进行确认时，通常可以与单元测试、集成测试、系统测试和验收测试合并进行。表3-1 软件项目中参加的确认内容及确认方法项目生命周期确认内容确认方法确认目的确 认 人需求阶段需求调研计划评审确保需求调研计划时间安排合理需求调研人员承诺可以按计划的时间参加需求调研的活动客户需求阶段软件需求说明书评审或 原型展示承诺需求尽量不发生变更客户确保软件功能可以实现项目组成员系统规格说明书评审或 原型展示承诺需求尽量不发生变更客户确保软件功能可以实现项目组成员计划阶段项目过程定义书评审确保所定义的过程是合理的项目
10、组成员项目估算表评审确保项目估算的过程是合理的项目组成员项目计划及其 从属计划评审承诺可以提高所需的资源公司高层确保项目计划是合理的项目组成员设计阶段概要设计说明书评审承诺设计的内容合理有效软件设计人员确保概要设计的内容可以实现软件开发人员详细设计说明书评审承诺设计的内容合理有效软件设计人员确保概要设计的内容可以实现软件开发人员产品集成方案评审承诺产品基础的方案是合理有效的软件设计人员确保产品集成顺序是合理的软件开发人员编码阶段产品组件单元测试承诺代码的质量是合格的软件开发人员确保代码的功能是正确的软件测试人员集成后的产品 或组件集成测试承诺产品或组件的质量是合格的软件开发人员确保产品或组件的
11、功能是正确的软件测试人员系统测试阶段产品或组件系统测试承诺产品的质量已经符合要求软件测试人员确认产品是否可以发布项目经理用户验收阶段产品验收测试承诺软件产品已经完成并且达到质量标准项目经理确认产品是否可以验收，项目是否可以结束客户在项目计划阶段通过对配置项列表中的配置项进行识别，挑选适当的工作产品在项目过程中进行确认，并将挑选出来的内容记录在确认清单或项目计划中，其流程如图3-1所示。2建立和维护确认环境确认工作的开展最好是在“使用者”的环境下进行，只有这样才能证明该工作产品的质量和功能是否符合“使用者”的要求。但在软件研发过程中这个前提条件并不一定完全可行，在建立确认环境时往往也要考虑确认的
12、方法。例如：要对软件需求说明书进行确认，确认的方法是“评审”，开评审会所需要的环境通常是一间会议室，最好有白板、各种颜色的水笔、投影等设备，不管是甲方还是乙方召开软件需求说明书的评审，这些配备都是相同的。再例如对开发阶段集成后的产品或组件进行确认，往往是通过执行集成测试用例来完成的，由于确认的对象是代码，所以集成测试用例通常是由白盒测试技术实现的。在进行此种确认时，软件测试人员是该工作产品的“使用者”，但该确认的方法却是一种开发的技术，所以在软件测试人员的系统测试环境中是无法进行的。图3-1 选择确认的产品“环境”在软件工程中包含了两方面的内容：一个是以硬件设备为主的“硬环境”；另一方面是确认
13、流程和准则的“软环境”。当项目组要对某一个工作产品开展确认活动时，制订配套的流程和准则是必不可少的。如果通过评审的方式进行确认，那么评审的议程应该提前制订，评审过程中的评判标准需要提前制订，否则就会出现无休止的争论。如果通过技术手段对工作产品进行确认，那么部署该工作产品的步骤要提前制订，否则产品部署出现问题，那么确认也就无法进行。软件研发过程中常用的确认环境如表3-2所示。表3-2 软件研发过程中常用的集成环境项目生命周期确认内容确认方法确认准则需求阶段需求调研计划评审客户方同意并签字确认软件需求说明书评审或原型展示客户方同意并签字确认；软件需求说明书中的每个功能都必须在评审中覆盖到；在评审时
14、发现的严重和较严重级别的缺陷必须修复系统规格说明书评审或原型展示与会人员一致同意并签字确认；系统规格说明书中的每个功能都必须在评审中覆盖到；在评审时发现的严重和较严重级别的缺陷必须修复计划阶段项目计划及其从属计划评审项目组成员要同意并签字确认；公司高层领导要签字确认设计阶段概要设计说明书详细设计说明书产品集成方案评审软件开发人员要同意并签字确认；设计文档中的每个方法在评审时要被覆盖到；在评审时发现的严重和较严重级别的缺陷必须修复编码阶段产品组件单元测试软件开发人员要同意并签字确认；单元测试用例执行率要达到100%；单元测试代码行覆盖率平均要达到40%；单元测试中所发现的所有缺陷必须被修复；单元
15、测试用例执行结果必须全部为通过集成后的产品或组件集成测试软件测试人员要同意并签字确认；集成测试用例执行率要达到100%；集成测试代码行覆盖率平均要达到30%；集成测试中所发现的所有缺陷必须被修复；集成测试用例执行结果必须全部为通过系统测试阶段产品或组件系统测试项目经理或软件测试经理要同意并签字确认；系统测试用例执行率要达到100%；产品功能覆盖率要达到100%；系统测试中所发现的严重或较严重级别的缺陷必须修复；系统测试中所发现的严重级别较低的缺陷必须修复80%用户验收阶段产品验收测试客户要同意并签字确认；验收测试用例执行率要达到100%在项目计划阶段制订确认环境时有可能会引发“Make or Buy”的决策或其他方面的变更。例如某项目要对代码进行确认，但是没有独立的编译
