软件质量管理的信任机制

《软件质量管理的信任机制》由会员分享，可在线阅读，更多相关《软件质量管理的信任机制（12页珍藏版）》请在金锄头文库上搜索。

1、第1 章 软件质量管理的信任机制确认人们的日常生活往往离不开对各种各样的事情进行确认，例如：当使用信用卡的时候， 服务员会要求顾客确认银联回执单上的金额，然后在上面签字；当顾客在银联回执单上签字 后，服务员还要确认签字笔迹是否与信用卡上的相符；当一对恋人打算结婚的时候，他们都 会去民政局进行婚姻登记，以在法律上确认他们的合法关系，当然在婚姻登记时也需要男女 双方签字确认。在软件研发过程中也离不开各种确认的工作，例如：甲乙双方签订合同时，要对合同上 的金额、完工时间、项目范围等内容进行确认，确认后要双方签字、盖章；当需求人员在完 成软件需求说明书后，为了减少需求的变更，往往也会给客户进行确认。由

2、此可见，确认是一种行为，该行为的方式有很多，既可以通过口头方式进行确认，也 可以通过书面形式进行确认。确认的深层含义是承诺，换句话说一个人的承诺是通过确认的 方式来体现的。例如：顾客不在银联回执单上签字，那么就代表顾客否定了本次交易，这是 一种相反的承诺，那么银行就会按照顾客的这种承诺拒绝付款给商家；当一对恋人没有进行 婚姻登记，那么在法律上也就没有给彼此一个共同生活的承诺，因此他们还有权力选择他人； 在软件研发过程中如果客户没有对软件需求说明书的内容进行确认，也就是他没有给出 禅从软件质量生理的流程更时术方法等到愧疚。件质量管理体系进行了详尽的讲述，并对日 常工作确认的案V例进行剖析简鞭广大

3、软件质量管是软件工程体加中的一解新成握软件质量置管的 精理、风险管理、度量管理等分支同等重要，是软件质量体系中不可或缺的环节。确认是指对软件研发生命周期中某个过程所产出的工作产品进行的审查,这些工作产品 可以是软件需求说明书、合同等文档，作也者：可张以瑾是开发出来的组件或最终产品，甚至可以 是对某个生命周期阶段进行的整体审查。确认的目的就是确保某个过程或阶段“做对的工作产品”，并使它符合使用者的期望， 并且只有通过审查后的工作产品才能交付给“使用者”使用。在软件研发过程中有两个重要的确认过程是众所周知的，一个是“客户”对软件需求 说明书的确认，另一个是项目组开发出来的最终产品要在客户现场进行验

4、收测试，以确认 该产品是否符合“客户”的需要。这两个确认都是针对客户方的，但是在确认管理过程中却 是不使用“客户”两个字的，而用“使用者”来代替“客户”，这是为了避免广大软件从业 人员对确认过程的误解。软件需求说明书是软件项目范围的依据，它用来描述软件产品 的功能，软件产品的最终“使用者”就是“客户”；验收测试的目的就是确保产品达到“客 户”也就是最终“使用者”的要求。但在软件确认管理中并不是只有“客户”才需要对项目 的工作产品进行确认，项目组或公司内部同样需要对某些工作产品进行确认，而这种确认往 往非常关键，但进行确认的人却不是合同的甲方，因此在软件确认管理中要用“使用者”这 个名称来对它进

5、行代替。那么什么时候才会出现项目组内部的确认呢？很多人对这个事情都有疑问，这是可以理 解的，因为在早期的软件工程中谈及确认管理的内容是非常少的。但项目组内的确认工作是 天天都在进行的，例如：对概要设计文档进行评审并且合格通过后，与会人员都会在评 审记录上签字。这个过程中就“包含”了确认的内容。但有人又会说同行评审是“验证”的 过程，怎么会包含确认的内容呢？大家可以想想，首先确认的目的是承诺，那么签字就代表 了与会人员对概要设计文档的正确性进行了承诺。其次参加本次评审的人员中一定会有 软件开发人员，软件开发人员将是这份概要设计文档的“使用者”，只有“使用者”对 该工作产品的质量进行确认后才能被使

6、用。因此，在对概要设计文档进行评审时，这个 过程除了对概要设计文档的内容进行验证，与会人员中的“使用者”还要对其内容是否 符合要求并且是否可以指导软件开发人员的工作进行确认。由此可见，在软件生命周期内凡是一个环节“输出”的工作成果都将成为后续环节的“输 入”，那么上一个环节的生产者要承诺该工作产品是符合质量要求的，后续环节的“使用者” 也要对其工作产品进行确认。这就好比“亲兄弟明算账”，通过这样的方式来建立相互间的 信任关系。1.1. 软件确认流程及最佳实践为了确保对工作产品确认的效果，通常建议该工作产品在仿真环境下进行审查，因此建 立确认的环境是确认管理中的一个部分。一个软件项目所产出的工作

7、产品非常多，仅配置项 列表中的内容就有几十项，项目组需要在项目计划阶段识别所需进行确认的工作产品。确认 是以使用者的视角来对工作产品进行审查，因此要在制订项目计划时就确定哪些项目关系人 要对哪些工作产品进行确认。接下来我们对确认管理的流程和最佳实践进行举例讲解。1.1.1. 确认的准备工作确认工作在准备阶段包括以下3个方面的内容，这些内容都应该在项目计划阶段完成： 选择需要确认的工作产品与产品组件 建立和维护确认环境 建立确认的流程及准则1选择需要确认的工作产品与产品组件在选择需要确认的工作产品和产品组件时，可以根据项目的生命周期模型，并配合项目 配置项列表来进行识别。配置项列表中的内容都是项

8、目关键的工作产品，因为配置项是项目基线的组成部分，虽然并不是所有配置项都需要进行确认，但是确认管理的工作还需要很多资源、时间和成本的投入，这要根据项目的实际情况进行确定。在识别完待确认的对象后就应该为它制订相应的确认方法，并确定参与确认的角色。软 件项目中确认的方法有以下两大类，软件生命周期中常见的确认内容及方法如表3-1所示。 对文档类型的工作产品进行确认，通常可以与其文档的评审合并进行。 对产品或产品组件进行确认时，通常可以与单元测试、集成测试、系统测试和验收 测试合并进行。表3-1 软件项目中参加的确认内容及确认方法项目生命 周期确认内容确认方法确认目的确认人需求阶段需求调研计划评审确保

9、需求调研计划时间安排合理需求调研人员承诺可以按计划的时间参加需求调研的活动客户需求阶段软件需求说明书评审或原 型展示承诺需求尽量不发生变更客户确保软件功能可以实现项目组成员系统规格说明书评审或原 型展示承诺需求尽量不发生变更客户确保软件功能可以实现项目组成员计划阶段项目过程定义书评审确保所定义的过程是合理的项目组成员项目估算表评审确保项目估算的过程是合理的项目组成员项目计划及其从属计划评审承诺可以提高所需的资源公司高层确保项目计划是合理的项目组成员设计阶段概要设计说明书评审承诺设计的内容合理有效软件设计人员确保概要设计的内容可以实现软件开发人员详细设计说明书评审承诺设计的内容合理有效软件设计人

10、员确保概要设计的内容可以实现软件开发人员产品集成方案评审承诺产品基础的方案是合理有效 的软件设计人员确保产品集成顺序是合理的软件开发人员编码阶段产品组件单兀测试承诺代码的质量是合格的软件开发人员确保代码的功能是正确的软件测试人员集成后的产品或 组件集成测试承诺产品或组件的质量是合格的软件开发人员确保产品或组件的功能是正确的软件测试人员系统测试 阶段产品或组件系统测试承诺产品的质量已经符合要求软件测试人员确认产品是否可以发布项目经理用户验收 阶段产品验收测试承诺软件产品已经完成并且达到 质量标准项目经理确认产品是否可以验收，项目是否 可以结束客户在项目计划阶段通过对配置项列表中的配置项进行识别，

11、挑选适当的工作产品在项目过程中进行确认，并将挑选出来的内容记录在确认清单或项目计划中，其流程如图3-1所示。2建立和维护确认环境确认工作的开展最好是在“使用者”的环境下进行，只有这样才能证明该工作产品的质 量和功能是否符合“使用者”的要求。但在软件研发过程中这个前提条件并不一定完全可行， 在建立确认环境时往往也要考虑确认的方法。例如：要对软件需求说明书进行确认，确 认的方法是“评审”，开评审会所需要的环境通常是一间会议室，最好有白板、各种颜色的 水笔、投影等设备，不管是甲方还是乙方召开软件需求说明书的评审，这些配备都是相 同的。再例如对开发阶段集成后的产品或组件进行确认，往往是通过执行集成测试

12、用例来完 成的，由于确认的对象是代码，所以集成测试用例通常是由白盒测试技术实现的。在进行此 种确认时，软件测试人员是该工作产品的“使用者”，但该确认的方法却是一种开发的技术， 所以在软件测试人员的系统测试环境中是无法进行的。软件砌认管理淮备阶段流程输入项目经理项目关系式输出工作产品确认蓿 单草案h识別所离雯确认的工作产品图3-1 选择确认的产品“环境”在软件工程中包含了两方面的内容：一个是以硬件设备为主的“硬环境”；另 一方面是确认流程和准则的“软环境”。当项目组要对某一个工作产品开展确认活动时，制 订配套的流程和准则是必不可少的。如果通过评审的方式进行确认，那么评审的议程应该提 前制订，评审

13、过程中的评判标准需要提前制订，否则就会出现无休止的争论。如果通过技术 手段对工作产品进行确认，那么部署该工作产品的步骤要提前制订，否则产品部署出现问题， 那么确认也就无法进行。软件研发过程中常用的确认环境如表3-2所示。表3-2 软件研发过程中常用的集成环境项目生命周期确认内容确认方法确认准则需求阶段需求调研计划评审客户方同意并签字确认软件需求说明书评审或原型展示客户方同意并签字确认；软件需求说明书中的每个功能都必须在评审中覆 盖到；在评审时发现的严重和较严重级别的缺陷必须修复系统规格说明书评审或原型展示与会人员一致同意并签字确认；系统规格说明书中的每个功能都必须在评审中覆 盖到；在评审时发现

14、的严重和较严重级别的缺陷必须修复计划阶段项目计划及其从属计划评审项目组成员要同意并签字确认；公司高层领导要签字确认设计阶段概要设计说明 书详细设计说明书产品集成方案评审软件开发人员要同意并签字确认；设计文档中的每个方法在评审时要被覆盖到；在评审时发现的严重和较严重级别的缺陷必须修复编码阶段产品组件单元测试软件开发人员要同意并签字确认；单元测试用例执行率要达到100%；单元测试代码行覆盖率平均要达到40%； 单元测试中所发现的所有缺陷必须被修复；单元测试用例执行结果必须全部为通过集成后的产品或组件集成测试软件测试人员要同意并签字确认；集成测试用例执行率要达到100%;集成测试代码行覆盖率平均要达

15、到30%； 集成测试中所发现的所有缺陷必须被修复； 集成测试用例执行结果必须全部为通过系统测试阶段产品或组件系统测试项目经理或软件测试经理要同意并签字确认；系统测试用例执行率要达到100%;产品功能覆盖率要达到100%;系统测试中所发现的严重或较严重级别的缺陷必须修复；系统测试中所发现的严重级别较低的缺陷必须修复80%用户验收阶段产品验收测试客户要同意并签字确认；验收测试用例执行率要达到100%在项目计划阶段制订确认环境时有可能会引发“Make or Buy”的决策或其他方面的变 更。例如某项目要对代码进行确认，但是没有独立的编译服务器或日构建服务器，此时就会 导致采购的发生，因此也会造成项目预算的变更。确认工作所使用的环境是确认的约束条件，同样也是项目约束条件之一，因此项目经理 要在项目进度计