软件质量保证基本概念与方法PPT课件( 25页)

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