SQA

4.1 软件缺陷对成本的影响 4.2 缺陷的放大和消除
开发步骤 缺陷 通过的错误 来自以 前步骤 的错误 放大的错误1:x 新产生的错误 错误检 测有效 性百分比 检测
传给下 一个步 骤的错误
缺陷放大模型
缺陷放大(无评审 缺陷放大 无评审) 无评审
概要设计 0 0 10 0%
详细设计 10 6 4 6
1.3 质量成本 预防成本:质量计划,FTR,测试设备,培训 质量计划, ,测试设备, 定义: 定义: 过程内和过程间的审查,设备校准, 鉴定成本 :过程内和过程间的审查,设备校准,测试 内部故障成本包括反工,修复, 质量成本 故障成本 :内部故障成本包括反工,修复,故障分析 外部故障成本包括解决客户抱怨, 外部故障成本包括解决客户抱怨,退换产 求助电话支持,保修工作. 品,求助电话支持,保修工作.
第六节 正式评审实战 1.讲解"正规评审指南" 讲解" 讲解 正规评审指南" 检查表) 2.Checklist (检查表)编写指南 检查表 3. 讲解"正规评审"之后应该提交的成果 讲解"正规评审" 评审问题记录表 评审总结报告
第8节 ISO9000及CMM的介绍 节 及 的介绍 8.1 ISO9000 ISO9000-3 标准的内容要点: 标准的内容要点: 1.仅仅适用于依据合同的"定制开发" .仅仅适用于依据合同的"定制开发" 2.对供需双方领导的责任作了明确的规定 . 3.从双方签约,设计,实现到维护整个软件生命周期的全部工序进 .从双方签约,设计, 行审查,并彻底文档化, 证据" 行审查,并彻底文档化,作为质量保证体系实施的 "证据" 4.规定了双方签约,设计,实现到整个软件生命周期中应该实施的 .规定了双方签约,设计, 质量保证活动 5.规定了供应方应实施内部质量审核制度 . 6.规定了供应方对每个合同条目进行审查 . 7.对需求规格说明有详细的规定 . 8.开发计划管理 . 9.质量计划管理 . 10.设计和实现 .
5.3 评审的指导原则 评审原则的最小集合有十条: 评审原则的最小集合有十条: 1. 评审产品,而不是评审生产者; 评审产品,而不是评审生产者; 2. 制定日程并遵守规程; 制定日程并遵守规程; 3. 限制争论和辩驳; 限制争论和辩驳; 4. 对问题发表见解,但不要试图解决所有的问题; 对问题发表见解,但不要试图解决所有的问题; 5. 做书面笔记; 做书面笔记; 6. 限制参与人数并坚持事先做准备; 限制参与人数并坚持事先做准备; 7. 为每个可能要评审的工作产品建立一个检查表( 为每个可能要评审的工作产品建立一个检查表(checklist); ; 8. FTR分配资源和时间; 分配资源和时间; 分配资源和时间 9. 对所有评审者进行有意义的培训; 对所有评审者进行有意义的培训; 10. 评审以前所做的评审. 评审以前所做的评审.
评审各项软件工程活动,对其是否符合定义好的软件过程进行核实. 评审各项软件工程活动,对其是否符合定义好的软件过程进行核实. 审计指定的软件工作产品. 审计指定的软件工作产品. 确保软件工作产品中的偏差已经记录在案并根据预定规程进行处理. 确保软件工作产品中的偏差已经记录在案并根据预定规程进行处理. 记录所有不符合要求的部分并报告高级管理者. 记录所有不符合要求的部分并报告高级管理者. 收集分析软件度量信息. 收集分析软件度量信息. 负责软件的配置管理(可能有专门的SCM小组). 小组). 负责软件的配置管理(可能有专门的 小组 第四节 软件评审 软件评审的一般描述: 软件评审的一般描述: 非正式的会议评审 评审的类型 介绍式的评审 正式的技术评审( 正式的技术评审(FTR)(有时称 (有时称walkthrough or inspection 等)
4*1.5,X=1.5
编码/单元测试 编码 单元测试 0% 37 10 27 10
27*3,X=3
25 94 集成测试 确认测试 0 0 50 % 47 0 0 50 24 %
20 %
94
25 到集成 系统测试 12
0 0
50 %
潜伏的错误
缺陷放大(有评审) 缺陷放大(有评审)
概要设计 0 0 10 70 %
SQA包含: 包含: 包含
1)一种质量管理方法 2)有效的软件工程技术(方法和工具)3)在 ) )有效的软件工程技术(方法和工具) ) 整个软件工程过程中采用正式的技术评审 4)一种多层次的测试 ) 策略 5)对软件代码,文档和数据及其修改的控制 6)保证软件开 )对软件代码, ) 发适时遵循开发标准 7) 度量和报告机制. ) 度量和报告机制.
改正一个错误的质量成本图 1000 100
15-40倍 15-40倍 30-70倍 30-70倍 10倍 10倍 3-6倍 1倍 40-1000倍 40-1000倍
10 1
需求分析
设计
编码 开发测试 系统测试 实际操作
第二节 质量运动 1.kaizen 2.Atarimae hinshitsu 全面质量管理(TQM) 全面质量管理 3.kansei 关注产品及其拓展 4.Miryokuteki hinshitsu 关注软件过程
第一节 软件质量保证体系
1.1 质量的几个概念 差异控制:差异控制是质量控制的核心, 差异控制:差异控制是质量控制的核心,控制差异是获得高 质量产品的关键.我们应该努力控制每一个不同的项目, 质量产品的关键.我们应该努力控制每一个不同的项目,减 少完成项目预计需要的资源和实际使用的资源之间的差异. 少完成项目预计需要的资源和实际使用的资源之间的差异. 质量的定义:某一事物的特征或属性.( .(设计质量和符合质 质量的定义:某一事物的特征或属性.(设计质量和符合质 量). 设计质量:设计者为一件产品规定的特征. 设计质量:设计者为一件产品规定的特征. 符合质量:在实现过程中符合设计规约的程度. 符合质量:在实现过程中符合设计规约的程度. 在软件开发时,设计质量包括软件的需求规约, 在软件开发时,设计质量包括软件的需求规约,概要设计和 详细设计,符合质量主要关注实现问题. 详细设计,符合质量主要关注实现问题. 1.2 质量控制 等同于差异控制, 等同于差异控制,是为了保证每一件工作产品都满足需求而 在整个开发周期中进行的一系列审查,评审和测试. 在整个开发周期中进行的一系列审查,评审和测试.质量控 制在创建工作产品的过程中包含一个反馈循环, 制在创建工作产品的过程中包含一个反馈循环,度量和反馈 相结合,使我们不断的调整开发过程,达到控制质量的目的. 相结合,使我们不断的调整开发过程,达到控制质量的目的.
第二部分 软件配置管理 (Software Configuration Management) 第一节 SCM介绍 介绍
概念:软件配置管理是一组活动 是设计用来标识变更的工作产品 是设计用来标识变更的工作产品, 概念:软件配置管理是一组活动,是设计用来标识变更的工作产品, 建立它们之间的关系,定义管理这些工作产品不同版本的机制, 建立它们之间的关系,定义管理这些工作产品不同版本的机制, 控制这些变更以及审计和报告所发生的变更. 控制这些变更以及审计和报告所发生的变更. 人员:每一个涉及到软件工程过程的人员均在某种程度上和SCM相 人员:每一个涉及到软件工程过程的人员均在某种程度上和 相 关联.一般情况下需要专门的SCM小组或专门的技术人员来管理 关联.一般情况下需要专门的 小组或专门的技术人员来管理 和支持. 和支持. 为什么重要:举例: 为什么重要:举例: 步骤: )在开发过程中每个中间产品惟一的标识. 步骤:1)在开发过程中每个中间产品惟一的标识. 2)建立版本和变更控制机制. )建立版本和变更控制机制. 3)为保证变更的质量,变更必须被审计. )为保证变更的质量,变更必须被审计. 4)对变更需进行统计,跟踪和实行报告制度. )对变更需进行统计,跟踪和实行报告制度. 产品:定义配置管理计划,其中涉及SCM的策略;当SCM启动之后, 的策略; 启动之后, 产品:定义配置管理计划,其中涉及 的策略 启动之后 需产生软件变更请求单,报告单和变更单. 需产生软件变更请求单,报告单和变更单.
11.测试和验证 . 12.验收 . 13.复制,交付和安装 .复制, 14.维护(对维护活动的计划,规定和支持等) .维护(对维护活动的计划,规定和支持等) 15.配置管理(版本变更和升级) .配置管理(版本变更和升级) 16.文档控制(各种文档的建立,审批和发布等) .文档控制(各种文档的建立,审批和发布等) 17.质量记录(包括质量记录确认,收集,索引,文件格式,存储 .质量记录(包括质量记录确认,收集,索引,文件格式, 和维护等) 和维护等) 18.测量 . 19.采购 . 20.培训 . 21.其他 . 11.2 一个具体的 一个具体的ISO9000的实例 的实例 11.3 CMM介绍 介绍
软件测试和质量保证 质量保证部分
杜庆峰 du_cloud@
第一部分
软件质量保证
本部分讲解的主要内容有:软件质量保证体系介绍; 本部分讲解的主要内容有:软件质量保证体系介绍;CMM和 和 ISO9000介绍;一个具体的 介绍; 计划; 介绍 一个具体的SQA计划;一个具体的正规评审过 计划 程实践介绍. 程实践介绍. 软件质量保证的概念: 软件质量保证的概念: 仅仅把软件质量的重要性挂在口头上是不够的,必须: 仅仅把软件质量的重要性挂在口头上是不够的,必须:
详细设计 3 2 1 2
1*1.5
编码/单元测试 编码 单元测试 50%15 5 10 5
10*3
25 24 集成测试 确认测试 0 0 50 % 12 0 0 50 6 %试 3
0 0
50 %
潜伏的错误
第五节 正式技术评审 正式评审的目标: 正式评审的目标: 1.在软件的任何一种表示中发现功能,逻辑或实现的错误 在软件的任何一种表示中发现功能, 在软件的任何一种表示中发现功能 2.证实经过评审的软件的确满足需求 证实经过评审的软件的确满足需求 3.保证软件的表示符合预定义的标准 保证软件的表示符合预定义的标准 4.得到一种一致的,具有连续性的方式开发的软件(风格,实现等 得到一种一致的, 得到一种一致的 具有连续性的方式开发的软件(风格, 方面) 方面) 5.使项目易于管理 使项目易于管理 FTR同时也是一个连续的培训过程,以会议形式进行,并有适当的 同时也是一个连续的培训过程, 同时也是一个连续的培训过程 以会议形式进行, 计划,控制和参与,才能成功. 计划,控制和参与,才能成功. 5.1 评审会议 评审会议的约束:人员3~5人之间;提前准备,每人占用不超过 人之间; 评审会议的约束:人员 人之间 提前准备,每人占用不超过2 小时;会议时间不超过2小时 小时. 小时;会议时间不超过 小时. 评审会议的组织 评审会议的结果 5.2 评审报告和记录保存 评审问题列表 评审总结报告 建立跟踪规程
第三节 软件质量保证 软件质量保证应关注三个方面: 软件质量保证应关注三个方面: 1.软件需求的符合程度 1.软件需求的符合程度 2.软件开发准则的遵循程度 2.软件开发准则的遵循程度 3.隐含需求的满足程度 3.隐含需求的满足程度 3.1 软件质量保证的背景 软件质量保证的标准20世纪70 20世纪70年代美国军方软件的合同中其定义 软件质量保证的标准20世纪70年代美国军方软件的合同中其定义 是为了保证软件高质量而必需执行的" 为:是为了保证软件高质量而必需执行的"有计划的和系统化的 行动模式" 行动模式". SQA在软件质量保证中的角色 软件工程师,项目管理者,客户, 在软件质量保证中的角色: SQA在软件质量保证中的角色:软件工程师,项目管理者,客户, 销售人员和SQA小组成员. SQA小组成员 销售人员和SQA小组成员. SQA的活动 3.2 SQA的活动 其活动由各种任务构成,并与两种不同的参与者相关, 其活动由各种任务构成,并与两种不同的参与者相关,即工程师 team.SQA组负责SQA的计划 监督,记录,分析及报告. 组负责SQA的计划, 和SQA team.SQA组负责SQA的计划,监督,记录,分析及报告. 活动内容: 活动内容: 为项目准备SQA计划.(计划内容) SQA计划.(计划内容 为项目准备SQA计划.(计划内容) 参与项目的软件过程描述的开发. 参与项目的软件过程描述的开发.
1. 2. 3. 4. 明确地定义软件质量的含义; 明确地定义软件质量的含义; 创建一组活动, 创建一组活动,这些活动保证软件工程过程中的每个工作产品具 有高质量 ; 对每个软件项目完成质量保证活动; 对每个软件项目完成质量保证活动; 使用度量以改善你的软件过程并最终改善软件产品的质量. 使用度量以改善你的软件过程并最终改善软件产品的质量.