实用软件工程
宁夏大学数学计算机学院 赵国栋
第14章 软件质量保证
本章导读
质量保证一直是CMMI和ISO9000的中心议题，是微 软公司和IBM公司的重点课题，同样也是项目管理的重 要内容。 通常，人们将“质量标准、配置管理、测试测量”， 作为质量管理的三大支柱，而将“SQA计划、SQA进度、 SQA评审和审计”，作为质量管理三大要素。 本章先论述软件质量保证的基本概念和多种方法， 后介绍IT企业软件质量保证文档书写的参考指南。
正式评审会议的流程(续)
阅读人：向评审小组展示工作产品的各部分。 检查者：提出缺陷、问题、疑问、改进建议。 创建者：解答问题，简短回答提出的问题，使检查者 进一步了解工作产品，从而帮助发现缺陷。 记录人：详细的记录到问题日志上。
3. 评审会议的跟踪
涉及的新角色有：审核者。 涉及的文档有：评审会议跟踪表，由审核者跟踪软件 缺陷的修复情况，并详细记录到评审会议跟踪表中。 审核者：进行跟踪，确定正式评审会议上确定的缺陷 都被按照改进意见修改了，填写评审会议确信跟踪表。
3. CMM2的“软件质量保证SQA”过程
(1) 首先，通过监控软件的开发过程，来保证产品的 质量； (2) 其次，保证软件产品及软件开发过程，符合相应 的标准与规程； (3) 最后，保证软件产品、软件过程中存在的不符合 项问题得到处理，必要时将问题反映给高级管理者。 结合这三项内容，CMM2的软件质量保证手段主要 有三项：“审计、评审和处理不符合项”。审计是检查 做没做，做了多少，以及按什么标准和规范做的。评审 是检查干得好不好，是否还存在不符合项。处理不符合 项是跟踪纠错过程，直至改正为止。
评审在质量保证中的作用
80 70 60 50 40 30 20 10 0 分析阶段 设计阶段 编码阶段 测试阶段 发布阶段 单位缺陷修改成本 单位缺陷发现时间
正式评审会议的流程
1. 评审会议的准备 涉及的角色有：创建者、评审负责人、检查者。 涉及的文档有：评审检查单。 (1)创建者负责陈述评审目标；提交工作产品及其规 范；与评审负责人一起选择检查者，并分配角色。 (2)评审负责人负责计划、安排和组织评审活动，与 创建者一起选择检查者。评审负责人应该从创建者处将 评审产品的内容准备齐全，并打包发送给检查者。评审 负责人还要询问每个检查者的准备时间，确定会议准备 是否充分，如果不充分，应重新安排会议时间。 (3)检查者：检查工作产品，发现其缺陷，提出问题， 并且记录到评审检查单中。
序号 1 2
3
4 5 6 7 8 9 10 11
质量因素 质量因素的定义 正确性 系统满足规格说明书和用户目标的程度。 健壮性 在意外环境或错误操作下，系统做出适当响应的 程度。 完整性 对未经授权的人使用系统的企图，系统能够控制 的程度。 可用性 系统完成预定的功能时，令人满意的程度。 可理解性 系统的理解和使用的容易程度。 可维修性 诊断和改正发现的错误所需的工作量大小。 灵活性 修改或改进系统，需要的工作量多少。 可测试性 系统容易测试的程度。 可移植性 移植到另一种平台中运行所需资源的多少。 可再用性 软件系统的可复用程度。 互运行性 与其他系统集成，所需的工作量多少。
5. CMM4的软件质量保证手段“软件质量管理”
CMM4的“软件质量管理”目的是：建立对项目的 软件产品质量的定量了解，以便实现特定的质量目标， 例如在流程、时间、功能、性能、接口、界面上的特定 需求目标。为此，要对软件工作产品，实施内容丰富的 特定测量计划，进行质量的定量管理。
6. CMM5的软件质量保证手段“缺陷预防”
14.2 软件质量保证方法
1. 从四个方面来改进软件质量
(1) 力图从编程语言上实现突破。已经从机器语言、 汇编语言、面向过程的语言、面向数据的语言，发展到 面向对象、面向构架的语言。 (2) 力图从CASE工具上实现突破。这些工具有： OracleDesigner，PowerDesigner，ERwin，Rose，San Francisco，北大青鸟系统，分行业的业务基础平台。 (3) 力图从软件过程管上实现突破。如CMMI， ISO9000，微软企业文化，IBM企业文化。 (4) 力图从测试与纠错上实现突破。先后出现了各种 测试方法、工具和纠错手段。
4. CMM3的软件质量保证手段“同行评审”
俗话说，隔行如隔山，所以外行不能参与评审。同 行评审是指同行进行软件产品验证的活动，其目的是为 了及早和高效地从软件工作产品中识别并消除缺陷。与 技术评审不同，同行评审的对象一般是部分软件工作产 品，重点是发现软件工作产品中的缺陷。 所谓同行，是指和开发者在被评审的软件工作产品 上有相同的开发经验和知识的人员。一般来讲，不建议 管理者作为同行，参与同行评审，也不应使用同行评审 的结果去评价产品开发者的功过是非。 有人会说：同行是“冤家”。没关系，因为同行评 审是挑剔，是找缺陷，“冤家”更好。
要求 具体内容 了解 1) 软件质量及其相关概念的定义 2) 质量管理与控制的三个层次 3) 传统软件工程中质量管理的弱点 4) 同行评审 5) 软件质量保证管理文档 理解 1) 从四个方面来改进软件质量 2) CMM/CMMI改进软件质量的方法 3) 软件组织内部的“七化原则”和“五报一例制 度” 关注 1) CMM2的“软件质量保证SQA”过程 2) 《软件质量保证计划》的编写方法
CMM5的“缺陷预防”目的是：鉴别缺陷的原因， 并防止它们再次发生。具体做法有：建立项目缺陷分析 的工程数据库，字段有：“缺陷编号、缺陷名称、缺陷 类型、缺陷部位、缺陷原因、影响范围、发生频率、发 生时间、所属项目”等。将分析结果，尤其是带普遍价 值的过程更改，通知组织中的其他软件项目组。
7．CMMI软件质量保证的措施
什么样的软件是质量好的软件？
事实上，不同的人对软件质量有不同的评价和看法： （1）用户认为，功能、性能、接口满足了需求就是好软件。 （2）营销人员认为，客户群大且能卖个好价钱就是好软件。 （3）管理者认为，软件开发的进度、成本、质量（功能+性 能+接口）在计划的控制范围内就是好软件。 （4）开发者认为，易维护、可移植、可重用就是好软件。 上述众多观点不无道理，但都是从各自的利益出发的。应当 说上述评价和看法的汇总，才是货真价实的好软件。
8. 软件质量保证的其他措施
除了CMM/CMMI外，为了抓好软件质量管理，软 件组织的高层经理和项目经理，还应该大力提倡并严格 执行“七化原则”，即在软件质量管理中，管理人员要 做到：行为规范化，报告制度化，报表统一化，数据标 准化，信息网络化，管理可视化，措施及时化。 为了执行好上述“七化原则”，在软件组织内部的 各个项目中，还要建立“五报一例制度” ：日报表、 周报表、月报表、里程碑报表、重大事件报表和例会制 度。实行“高层经理抓月报，部门经理抓周报，项目经 验抓日报”的上、中、下三层的管理方法。
14.1 软件质量基本概念
1. 软件质量及相关概念的定义
【定义14-1】所谓软件质量，就是供方提供的软件产 品满足用户明确和隐含需求的能力特性的总和。 【定义14-2】所谓软件产品，就是供方交付给用户 使用的一套计算机程序、数据以及相关文档。 【定义14-3】所谓供方，就是向用户提供产品的组 织。供方有时又称承包方。 通过上述定义，知道了软件质量是什么，以及意味 着什么。在此之前，可能不知道这么多概念，只知道好 的软件的特点是功能强、性能优、易使用、易维护、可 移植、可重用。
2. 质量管理与控制的三个层次
(1) 事先的预防措施：制订软件过程开发规范和软件 产品质量标准，对软件开发和管理人员进行这方面知识 和技能的定向培训；(规范是对行为的约束、标准是对 产品的约束、规程是对操作的约束) (2) 事中的跟踪监控措施：按照CMM/CMMI或 ISO9000的过程管理思想，对软件过程和软件产品的质 量控制提供可视性管理； (3) 事后的纠错措施：对软件工作产品和软件产品加 强评审和检测。评审是在宏观上框住您，在微观上挑剔 您，找出不符合项。检测是为了发现Bug，改正错误。 结论：软件质量保证措施，应以提前预防和实时跟 踪为主，以事后测试和纠错为辅。
CMMI软件质量保证的措施(续)
(3)项目计划过程，包括定义度量和度量的内容。度 量就是测量，分析就是统计与决策。 (4)过程和产品质量保证过程域，目的就是对过程及 相关工作产品进行客观评价，提供给项目成员和管理部 门。强调同行评审与审计，交流和解决不一致问题。 (5)验证过程域，目的就是保证所选的工作产品符合 特定的需求。验证是个增量过程，它从需求验证开始， 经历工作产品的验证，直到最后完整产品的验证。 (6)确认过程域，目的就是证明工作产品和产品构件， 当它们处于其计划的环境中时，能完成其计划的用途。
CMMI更关注软件质量管理与控制。在CMMI 的24个过程域中，直接与质量管理有关的过程域 有9个： (1)需求管理过程域，目的就是管理项目的产 品和产品构件的需求，标识需求与项目计划、工 作产品之间的不一致性，并解决不一致性问题。 (2)度量和分析过程域，目的就是开发和维持 用于支持管理信息需要的度量能力。
CMMI软件质量保证的措施(续)
(7)组织级过程性能过程域，目的就是建立和维护组 织标准过程集性能的定量理解，且提供过程性能数据、 基线和模型来定量地管理组织的项目。 (8)项目定量管理过程域，目的就是定量地管理项目 的已定义过程，从而实现项目已建立的质量和过程性能 目标。 (9)因果分析和解决方案过程域，目的就是识别发生 缺陷和其他问题的原因，采取行动来预防其将来再次发 生。 结论：质量来源于过程，过程需要改进，改进需求 量模型，改进是无止境的，这就是CMMI精神！ CMMI 精神万岁！
14.3 评审在质量保证中的作用
从大量的软件实践中得知，正式评审工作被认为是 尽早发现软件缺陷，降低软件成本的最有效手段。 软件缺陷的发现时间，同缺陷修正的成本呈幂次关 系。根据IBM的研究结果，假定在分析阶段发现的错误 其改正成本为1个货币单位，那么在测试之前（设计编 码阶段）发现一个错误的修改成本约为6.5个货币单位， 在测试时（集成测试、系统测试和验收测试）发现一个 错误的修改成本约为15个货币单位，而在发布之后（已 经交到用户手上）发现一个错误的修改成本约为60～ 100个货币单位。该比例同样也适用于发现一个错误需 要的时间代价。