北京理工大学
软件工程实践
汤铭端
中国航天科工集团公司 706所
第十讲
质量管理与质量保证
评审与审查
风险管理
目的与内容
? 掌握质量的概念
? 了解质量管理和质量保证的内容和过程
? 掌握评审和审查的过程
? 了解和掌握风险管理的概念与过程
质量管理
质量的概念
? 质量定义：反映实体满足明确和隐含需
要能力的特性综合
? 定义的说明,
? 明确需要：指合同中用户明确提出的要求与
需要
? 隐含需要：指由生产企业通过市场调研进行
识别与探明的要求或需要
? 特性：实体所特有的性质，反映了实体满足
需要的能力
软件质量的定义
? ANSI/IEEE Std 729-1983定义软件质量
为,与软件产品满足规定的和隐含的需
求的能力有关的特征或特性的全体,。
? M.J,Fisher 定义软件质量为,所有描述
计算机软件优秀程度的特性的组合,。
质量特性及其组合
? 为满足软件的各项精确定义的功能、性能需求，符合
文档化的开发标准，需要相应地给出或设计一些质量
特性及其组合。
? 如果这些质量特性及其组合都能在产品中得到满足，
则这个软件产品质量就是高的。
? 软件需求是度量软件质量的基础 。不符合需求的软件
就不具备质量。
? 标准定义了一组开发准则，用来指导软件人员用工程
化的方法来开发软件 。如果不遵守这些开发准则，软
件质量就得不到保证。
? 软件质量是各种特性的复杂组合。它随着应用的不同
而不同，随着用户提出的质量要求不同而不同。
什么是软件质量
成本
可靠
维护
及时
交付
正确 功能
功能
成本 及时 交付
软件质量的若干侧面
项目的质量
? 质量的类型,
? 质量，通常指产品的
质量，广义的还包括
工作的质量。 产品质
量 是指产品的使用价
值及其属性；
? 而 工作质量 则是产品
质量的保证，它反映
了与产品质量直接有
关的工作对产品质量
? 项目的质量
? 从项目作为一次性的活
动来看，项目质量体现
在由 WBS反映出的项目
范围内所有的阶段、子
项目、项目工作单元的
质量所构成，也即 项目
的工作质量 ；
? 从项目作为一项最终产
品来看，项目质量体现
在其性能或者使用价值
上，也即 项目的产品质
量 。
产品质量与过程质量
产品质量
开发技术
成本,
时间、进度
过程质量 人员素质
影响产品质量的 4个方面
软件质量特性与模型
? 软件质量特性，反映了软件的本质 。讨
论一个软件的质量，问题最终要归结到
定义软件的质量特性。
? 定义一个软件的质量，就等价于为该软
件定义一系列质量特性。
? 人们通常把影响软件质量的特性用软件
质量模型来描述 。
软件质量模型
? 软件质量特性定义成 分层模型
? 最基本的叫做 基本质量特性,它可以由
一些子质量特性定义和度量。
? 二次特性 在必要时又可由它的一些子质
量特性定义和度量。
? 1976年 Boehm质量模型
? 1979年 McCall质量模型
? 1985年 ISO质量模型
McCall软件质量 11特性
? 使用性
? 正确性
? 可靠性
? 效率
? 完整性
? 适应性
? 测试性
? 维护性
? 移植性
? 重用性
? 互操作性
Boehm质量模型
ISO的软件质量评价模型
? 按照 ISO/TC97/SC7/WG3/1985-1-
30/N382，软件质量度量模型由三层组成
? 软件质量需求评价准则 （ SQRC）
? 软件质量设计评价准则 （ SQDC）
? 软件质量度量评价准则 （ SQMC）
? 高层和中层建立国际标准，低层可由各
使用单位视实际情况制定
（ ISO/IEC9126,1991年） 质量特性
? 质量特性,功能性, 可靠性, 可维护性,
效率, 可使用性, 可移植性
? 推荐 21个子特性：适合性 准确性 互用
性 依从性 安全性 成熟性 容错性
可恢复性 可理解性 易学习性 操作
性 时间特性 资源特性 可分析性
稳定性 可变更性 可测试性 可安装
性 可替换性 适应性 一致性
质量成本
? 质量成本是实施单位为了保证和提高产品质量、满
足用户需要而支出的费用，以及因未达到质量标准
而产生的一切损失费用的总和。
? 简单地说，质量成本可被分成, 一致成本, 和, 不
一致成本,
? 一致成本包括：培训、指导、查证、确认、测试、
维持、测量、审查等的费用
? 不一致成本包括：损耗、返工、维修、产品回收、
投诉处理等的费用
? 通过缩减一致成本来节省费用会带来灾难性后果
? 第一次要完全正确
另外的区分费用的通用方法
?预防成本
?关注第一个以及以后诸个无瑕疵产品对顾客需求满足程度的预先
成本
?如设计评价、培训,QA、供给调查等预防活动
?评估成本
?评价产品或过程以确定如何满足所有客户需求相关的费用
?如产品检查、测试、设计评审等
?内部故障成本
?与满足客户需求在脱离组织控制前出现故障相关的费用
?如损耗、返工、维修、停工期、瑕疵评估、损耗评估等
?外部故障成本
?与那些需求没能满足的客户的决定相关的费用
?如客户退货和补贴、客户抱怨评估、检查、调查、纠正等
总质量成本
预防
评估
内部故障
外部故障
节约
当前 未来
最小化质量总成本
? 50%或更多的质量成本
来自内外部的故障
? 故障的完全消除是一个
理想但非有效的解决方
案
? Juran,
? 只要每单位的评价和预防
费用低于非一致成本，资
源会分配到预防和评价中
? 当预防和评价成本开始增
加每单位的质量成本时，
策略是维持质量不变
? 最小化质量总成本
内外部故障成本
评估和预防成本
总质量成本
100%次品 100%
合格品
最优质量成本
每
单
位
合
格
产
品
的
质
量
成
本
最小质量成本
质量管理的内容
? 质量计划
? 质量控制
? 质量保证
? 戴明环 ——PDCA
? P,Plan-计划
? D,Do-实施
? C,Check-检查
? A,Action-处理
P
D
C
A
质量管理
? 质量管理即在质量方面指挥和控制组织的协调活动
? 质量管理是指确定质量方针、目标和职责并在质量体
系中通过诸如质量策划、质量控制、质量保证和质量
改进并使其实施的全部管理职能的活动
? 质量方针
? 质量目标
? 质量策划
? 质量控制
? 质量保证
? 质量改进
戴明环 ——PDCA环
? P,Plan-计划
? D,Do-实施
? C,Check-检查
? A,Action-处理 P
D
C
A
质量计划
? 质量计划的目的主要是确保项目的质量
标准能够得以满意的实现, 其关键是在
项目的计划期内确保项目按期完成, 同
时要处理与其他项目计划之间的关系 。
质量计划的内容
? 需达到的质量目标
? 质量工作具体流程
? 在项目各个不同阶段，职责、权限和资源的具
体分配
? 项目实施中需采用的具体的书面程序和指导书
? 有关阶段适用的试验、检查、检验和评审大纲
? 达到质量目标的测量方法
? 随项目的进展而修改和完善质量计划的程序
? 为达到项目质量目标必须采用的其它措施
项目质量控制
? 质量控制主要是监督项目的实施结果, 将项目
的结果与事先制定的质量标准进行比较, 找出
其存在的差距, 并分析形成这一差距的原因,
质量控制同样贯穿于项目实施的全过程 。 项目
的结果包括产品结果 （ 如交付 ） 以及管理结果
（ 如实施的费用和进度 ） 。 质量控制通常是由
质量控制部门或类似的质量组织单元实施, 但
是也并非总是如此 。
质量保证
? 质量保证是所有计划和系统工作实施达到质量
计划要求的基础, 为项目质量系统的正常运转
提供可靠的保证, 它应该贯穿于项目实施的全
过程之中 。 在 ISO9000系列实施之前, 质量保
证通常被描述在质量计划之中 。
? 质量保证通常是由质量保证部门或者类似的组
织单元提供, 但是不必总是如此 。 质量保证通
常提供给项目管理组以及实施组织 （ 内部质量
保证 ） 或者提供给客户或项目工作涉及的其它
活动 （ 外部质量保证 ） 。
“质量保证, 与, 保证质量,
? 保证质量是质量控制的任务
? 用户不提 QA，项目实施者也要进行质量控制，
保证项目质量满足用户要求
? QA是以保证质量为基础，进一步引伸到提供质
量, 信任, 这一基本目的
? QA的主要工作是促进完善质量控制，以便准备
好客观证据，并根据对方的要求有计划、有步
骤地开展提供证据的活动
?, 保证, 有, 保险, 的意义
软件质量保证
? 软件质量保证 的目的是向管理者提供适
当的对软件项目正使用的过程和正构造
产品的可视性 。
? 软件质量保证 包括评审和审计软件产品
和活动以验证它们符合适用的规程和标
准，给项目和其它有关的经理提供这些
评审和审计的结果。
SQA的问题处理渠道
? 首先在软件项目内部处理符合性问题,
如可能的话就地解决它 。
? 对于那些无法在软件项目内部解决的问
题, 软件质量保证组逐级上递该问题到
管理者的恰当层次以求得解决 。
SQA的目标
? 目标 1 软件质量保证活动是有计划的 。
? 目标 2 软件产品和活动遵守适用的标准,
规程和需求的情况得到客观的验证 。
? 目标 3 受影响的组和个人接到软件质量
保证活动和结果的通知 。
? 目标 4 高级管理者处理在软件项目内部
不能解决的不符合问题 。
SQA的独立性
? 存在负责协调和实施项目的 SQA的组
? SQA有一个向高级管理者报告的渠道, 它独立于：项
目经理, 软件工程组, 其它的有关组
? 组织机构支持那些要求独立性的活动, 如 SQA
? 独立性应该,
? 给担当 SQA角色的个人提供组织上的自由度, 使他
们成为高级管理者在软件项目上的, 耳目, 。
? 使得担当 SQA角色的个人免受他们正在评审的软件
项目的管理者所作的性能评价的影响 。
? 使高级管理者相信正在报告的有关项目过程和产品
的信息是客观的 。
SQA过程活动
活动 1 按照已建档的规程为软件项目制订 SQA计划
活动 2 按照 SQA计划进行 SQA组的活动
活动 3 SQA组参与准备和评审项目的软件开发计划, 标
准和规程
活动 4 SQA组评审软件工程活动以验证符合性
活动 5 SQA组审计指定的软件工作产品以验证符合性
活动 6 SQA组定期向软件工程组报告其活动的结果
活动 7 按照已文档化的规程对在软件活动和软件工作产
品中所鉴别出的偏差建立文档并加以处理
活动 8 SQA组与顾客的 SQA人员一起对它的活动和发现
进行定期评审
SQA计划的内容
1,SQA组的职责和权力
2,SQA组的资源要求
3,项目的 SQA组活动的进度表和投资
4,SQA组参加制定项目的软件开发计划、标准和规程的情况
5,将由 SQA完成的评价
6,将由 SQA组进行的审计和评审
7,将用作 SQA组评审和审计的基础的项目的标准和规程
8,用于对不符合性问题建立文档和进行跟踪直至结束的规程
9,要求 SQA组生成的文档
10.就 SQA活动给软件工程组和其它软件 —有关组提供反馈信
息的方法和频率
软件可靠性与容错设计
软件可靠性
硬件系统故障率
0 t
Z(t)
软件系统故障率
0 t
Z(t)
软件可靠性定义
在给定 时间间隔 内 和特定的 环境
下，软件 按规格说明 成功运行 的
概率 。
软件可靠性的主要指标
借用硬件可靠性的定量度量方法来度
量软件的可靠性,
? MTBF:平均故障间隔时间
? MTTF:平均故障时间
t1,t2,.....,tn:失效时间
MTTF＝
n
i=1
n
1 ∑ t
i
软件可靠性定义的要素
(1)环境条件
规定软件的使用环境
(输入数据要求和环境 )
(2)规定时间
时间 t是随机变量。
(3)规定的功能
(4)成功运行
软件容错技术
? 提高软件质量和可靠性的技术,
? 避开错误技术
? 容错技术
? 对无法避开的差错，使其影响减至
最小的技术
什么是容错软件？
定义 1：规定功能的软件，在一定程度上对
自身错误的作用具有屏蔽能力的软件；
定义 2：规定功能的软件，在一定程度上能
从错误状态自动恢复到正常状态的软件；
定义 3：规定功能的软件，在因错误而发生
错误时，仍能在一定程度上完成预期的
功能的软件。
容错的一般方法
? 实现容错计算的方法（容错资源）,
? 错误检测算法
? 错误恢复算法
? 软件冗余备份
? 容错软件
? 主体：常规软件所需资源
? 附加体：容错资源
? 实现容错计算的主要手段是 冗余
容错
? 冗余技术分类,
? 结构冗余
? 静态冗余
? 动态冗余
? 混合冗余
? 信息冗余
? 时间冗余
? 软件的容错系统结
构
? 多版本结构
? 恢复块结构
结构冗余：静态冗余
? 3模冗余、多模冗余
? 3模（ TMR）表决系统的结构
U
M1
M2
M3
V
u2
u1
u3
I
表决器
U=(u1∧ u2)∨ (u2∧ u3)∨ =(u1∧ u3)
结构冗余：动态冗余
? 多重模块待机储备,相继运行
? 待机储备系统结构
M1
M2
M3
主模块
备用 I 开关
Mn
…,
备用
备用
结构冗余：混合冗余
? 混合冗余 H（ N,K）结构
M1
M2
Mk I
开关
Mn
…,
Mk+1
…,
V
转
换
开
关
信息冗余
? 以检测或纠正信息在运算或传输中的错
误为目的而外加的一部分信息
? 误差校正码,
? 奇偶码
? 定重码
? 循环码
? ……
时间冗余
? 以重复执行指令（指令复执）或程序
（程序复算）来消除瞬时错误带来的影
响
? 常用的程序复算方法,程序滚回技术
出错
…… t
0 t1 t2 t3 ti-1 ti ti+1
i-1 i 1 2
3
时刻 t0,t1,t2,…,对应于程序中预先设置好的恢复点
容错结构,多版本结构
? 把同一功能的不同版本的程序 (多为子系
统或模块级 )并行联结到系统中,构成冗
余并行模型
? 多版本程序示意图
版本 1
版本 2
版本 3
…..,
表决
同一功能
容错结构,恢复块结构
要求做容错的块 (基本块 )
提供,
备份块 (独立设计的相应冗余备份 )
附加的错误检验
恢复措施
恢复块 Ensure 接受测试
By 基本块
Else By备份块 1
……
Else By备份块 n
Else 错误
恢复块的工作方式
保存现场
队空 从恢复块的备份块
队列中取一个模块
激活此模块
执行此模块
恢复现场
接受测试 T
有问题
显示错误及位置
继续执行后续工作 通过
不通过
评审与审查
Review & Inspection
概论
? 在软件的研制过程中必须进行的一项重要工作，
就是软件的验证与确认。
? 软件验证是确定软件开发周期中的一个给定阶
段产品是否达到前阶段确立的需求的过程。它
包括评审、审查、测试、检查、审计等项活动。
? 软件确认是在软件开发过程结束时对软件进行
评价，以确认它和软件需求是否相一致的过程。
也可以说，确认是, 端到端, 的验证。
什么是验证与确认
? 验证和确认是两项相辅相成的工作，但它们之
间却极易混淆。
? 软件工程权威 Barry W,Boehm曾巧妙地用两句
形式相似但内容不同的话作过精辟的描述,
? Verification,Are we building the product right?
? Validation,Are we building the right product?
? 验证：我们正正确地制造产品吗？
? 确认：我们正制造正确的产品吗？
为什么 IV&V
? 不论项目大小如何，软件验证与确认很大程度地
影响着软件的质量。
? 人总是会犯错误的，而没有经过验证的软件将难
以正常工作。
? 有典型事例说明在开发期间每 1000行代码中发现
有 20到 50个错误，而即使是在系统测试之后每
1000行代码中仍有 1.5到 4个错误。
? 软件验证与确认的目标是把错误减少到可以接受
的水平。
? 软件的验证与确认工作占用整个项目的 30%～
90%的资源。
验证与确认 V形图
? 软件开发工作开始于图的左上角，沿左
边的产生, 软件规格, 侧向下进行到
,Ｖ, 的底端，其间要逐阶段进行验证；
? 之后沿右边的产生, 软件产品, 侧向上，
之间对应着它们对, 软件规格, 的验证。
? Ｖ形图强调在左侧按照输入验证每个输
出及在右侧根据, 软件规格, 验证软件
产品。
系统需求
软件需求
概要设计
详细设计 单元测试
组装测试
编码
确认测试
系统联试
详细设计
概要设计
软件需求
系统需求
型号任务
编译后的单元
测试后的单元
组装后的软件
测试后的软件
交付软件
验证
验证
验证
验证
验证
验证
验证与确认
验证与确认
V形图验证与确认说明
? 根据系统需求验证软件需求
? 根据软件需求验证概要设计
? 根据概要设计验证详细设计
? 根据详细设计验证编码
? 用单元测试验证详细设计
? 用组装测试验证概要设计
? 用确认测试验证软件需求
? 用系统联试验证系统需求
通过评审进行 IV&V
? 对软件的工作产品进行验证的一个重要
方法是评审 。
? 评审是把工作产品或工作产品集提交给
项目人员, 经理, 用户, 顾客或其它感
兴趣各方进行评价或批准的过程或会议 。
? 评审一般有技术评审, 审查, 走查, 审
计等多种形式 。
? 检查阶段工作的管理评审称作阶段评审 。
为什么要及早进行评审
1)程序中的大部分错误是在编码之前造成的 。 据
统计, 设计及之前阶段产生的错误大约占 63％,
而编码错误仅占 37％ 。
2)错误的检测与改正时间越晚, 所付出的代价也
就越高 。 通过对一些大型软件项目的分析表明；
如果在需求和设计阶段发现一个错误, 改正所
需费用为 1；那么在测试前发现该错误, 改正
费用则为 6.5；在测试时发现, 改正费用为 15；
而在交付使用后再发现, 改正费用则高达 67。
3)错误还会被, 放大, 。
阶段评审
? 评审的目的
? 阶段评审在软件研制的各
个阶段完成了预定工作时
进行, 目的是检查该阶段
工作是否完成, 是否达到
了规定的质量和技术要求,
检查计划管理, 质量管理,
风险管理, 配置管理的执
行情况, 决定是否可以转
入下一个研制阶段 。
? 各研制阶段结束时均应进
行阶段评审 。
? 评审组成员
? 评审由项目组上级主管机
构组织, 组长由上级主管
领导担任 。 成员包括,
? 1） 主管领导；
? 2） 同行专家；
? 3） 质量管理人员；
? 4） 科研 （ 计划 ） 管理人
员；
? 5） 项目组成员；
? 6 ） 交办方代表 （ 必要
时 ） 。
阶段评审 程序（ 1）
? （ 1）评审前的准备
? 准备阶段评审汇报和被评审文件。汇报内容,
? 1）本阶段研制工作的主要内容和完成情况；
? 2）为保证产品质量所做的质量保证工作；
? 3）计划落实和配置管理情况；
? 4）本阶段出现的主要问题及解决情况；
? 5）结论及建议。
? （ 2）确定评审人员和日期
? （ 3）评审组分工
? （ 4）评审组审阅评审文件
? 承办单位提前三天将评审文件提交评审组审阅
阶段评审 程序 （ 2）
? （ 5） 评审会议
? 1） 软件研制项目组作阶段评审汇报；
? 2） 评审组询问, 讨论, 审查各项工作, 项目组答辩；
? 3） 评审组作出评审结论并由组长宣布 。
? （ 6） 填写评审总结报告
? （ 7） 评审后的工作
? 评审结论入配置管理, 保存备案, 交上级审批 。
? 项目组针对修改意见和改进建议, 经审批进行修改补充 。
? 项目组根据评审意见, 转入下一研制阶段 。
阶段评审表
? 在每次阶段评审时, 都必须履行正式手续, 填
写必要的评审表格, 以利于项目管理和质量检
查 。
? 阶段评审表由三张子表组成
? 子表 1是对评审中发现问题的记录
? 子表 2是评审总结报告
? 子表 3是评审小组成员登记与签字表
? 对于在评审中发现的软件问题, 用软件问题报
告单对问题进行详细的描述 。
评审问题记录
登记号
评审日期
年 月 日
评审性质
评审□复审□
项目名
子项目名
代号
编号
问题摘要
问题类型
是否解决
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
评审总结报告
登记号
评审日期
年 月 日
评审性质
评审□复审□
项目名
子项目名
代号
阶段名
系统
需求
□
需求
分析
□
概要
设计
□
详细
设计
□
软件
实现
□
组装
测试
□
确认
测试
□
系统
联试
□
项目组长
姓名
单
位
电
话
评
审
任
务
评
审
材
料
通
过
不需修改
稍作修改
不
通过
作重要修改
要重新评审
备
注
评
审
小
组
成
员
职务
姓名
职称
单位
签字
组长
副组长
成员
成员
成员
成员
成员
成员
成员
技术评审
? 以下技术评审过程是欧洲航空局最佳实践过程
之一
? 目的
? 技术评审的目的是对具体的工作产品集 （ 如文档,
源代码 ） 进行评价, 并对管理提供以下信息,
? 它们符合前一阶段制定的软件规格；
? 它们已按照项目的标准和方法完成；
? 所有的更改都正确地得到完成, 并只影响对更改规定的范
围 。
组织
? 技术评审过程由评审组来执行, 评审
组中有以下的角色,
? 负责人
? 秘书
? 成员
职责
? 负责人的责任包括,
? 提名评审组；
? 组织评审并通知所有参加者评审的时间, 地点和日
程；
? 会议前向所有参加者分发评审项并在必要时分配评
审项；
? 必要时组织评审组开展准备工作；
? 主持评审会议；
? 发布技术评审报告 。
? 必要时秘书应协助负责人, 并负责记录评审组发现
的问题, 作出的决定和建议 。
职责
? 各评审组成员检查评审项并参加评审会议 。
? 如果被评审项规模大, 复杂或需要各种专业
的专家技能才能进行有效的评审, 那么负责
人可以在成员中分配评审项 。
输入
? 适当时，对技术评审过程的输入包括,
? 评审会议日程；
? 对目的的陈述；
? 评审项 （ 如被评审的软件需求规格说明, 软件概要
设计说明 ） ；
? 评审项应符合的上阶段给出的软件规格 （ 如评审软
件详细设计说明时所对应的软件概要设计说明 ） ；
? 评审项使用的计划, 标准及指南；
? 与评审项有关的评审差异表, 软件问题报告单, 修
改报告单；
? 软件质量保证人员的报告 。
评审差异表
编号
日期
提出人
1 文档标题,
2 文档代号,
3 文档发布 /版本号,
4 问题位置,
5 问题说明,
6 建议解决方法,
7 作者答复,
8 评审决定,
结束／更改／措施／拒收 （ 划出选择 ）
活动 =准备 +评审会议
? 准备
? 负责人起草日程表, 并将其与目的, 被评审项, 规
格, 计划和指南一起散发给评审组 。
? 评审组成员对评审项进行检查 。 通过完成评审差异
表来对在检查中发现的每个问题进行记录 。 将评审
差异表退还给秘书 。
? 负责人将每张评审差异表按主要的, 次要的或编辑
上的进行分类
? 由秘书按被评审项中偏差的位置对评审差异表进行
排序 。
活动 =准备 +评审会议
? 评审会议
? 1)开始；
? 2)展示被评审项；
? 3)评审差异表的分类；
? 4)对主要的评审差异表的评审；
? 5)对其它的评审差异表的评审；
? 6)结论 。
评审结论
? 典型的结论是,
? 授权进行下一步的工作, 条件是完成更改工作和采
取措施；
? 授权进行限定部分的工作；
? 执行决定的附加工作 。
? 如未能对达成一致意见和得出结论, 则,
? 在评审报告中记录非主流的不同观点；
? 由一名或多名成员在会议外寻找解决方法；
? 把问题移交给上一级管理部门 。
输出
? 报告摘要；
? 成员名单；
? 被评审项的确定；
? 按照分类编组的带处置标志的评审差异表, 软件问题
报告单, 软件修改报告单等；
? 措施清单, 以及各措施的人员责任和预期完成日期；
? 结论 。
? 输出可采取会议记录的形式, 或采取独立报告的形式 。
? 报告应足够详细, 以便于管理部门判断发生了什么事 。
? 如果在评审期间难以达成一致意见, 可建议评审组成员对输
出不签字 。
软件审查
? 软件审查可用于编码前发现详细设计中的缺陷, 在测
试前发现代码的缺陷 。 软件审查也可以用于验证测试
设计, 测试用例和测试过程 。
? 软件审查是有效的 。 通过审查, 可以查出开发过程所
带给项目的全部缺陷的 50%。
? 软件审查是经济的, 因为它可以大大减少缺陷的数量
和降低消除缺陷的费用 。 在缺陷产生后尽可能短的时
间内发现缺陷可以,
? 使软件开发者增强查找缺陷产生原因的意识, 以便
减少类似缺陷再出现的可能性；
? 使查找缺陷的工作量减少, 因为不需要在许多可能
的组成部分以外去诊断哪个组成部分有缺陷 。
审查的目的
? 软件审查的目的是查出文档或代码中的
缺陷。
软件审查的 组织
? 主任：主任领导审查并主持审查会 。 主任应具备完成这项工作的
技能, 而不必要精通所审查的项目 。 他 （ 她 ） 必须是公平的, 客
观的 。 鉴于这些原因, 主任常常从与项目无关的职员中选出 。 最
好他们受过有关审查过程的培训 。
? 秘书：秘书负责记录审查会的记录, 特别是记录发现的每个缺陷
的细节 。
? 阅读员：阅读者引导审查组遍历被审查项 。
? 审查员：审查员在审查时确定和描述被审查项的缺陷 。 选择的审
查员应能代表各种观点 （ 如：设计员, 编码员和测试员 ） 。
? 作者：作者是被审查项的编制人员 。 作者主要回答关于被审查项
的问题, 并负责所有的修改 。
? 一个人可担任上述一种或多种角色 。 没有人既担任作者又担任其
它角色 。
软件审查的 输入
? 被审查项（如源代码，或其它文档）
? 被审查项应符合的规格（如详细设计）
? 审查检查单
? 应用于被审查项的标准和指南
? 审查报告表
? 从上一次审查中获得的缺陷表
活动 =综述、准备、审查会、修改、补充活动
? 综述是对被审查项进行介绍 。
? 之后审查员对被审查项进行熟悉, 作好
参加审查会的准备 。
? 然后, 审查员在审查会上检查被审查项,
确定缺陷并决定是否对缺陷进行纠正 。
? 修改工作包括对故障的修复 。
? 补充活动是指检查在审查会上作出的所
有决定是否都得到了执行 。
审查的时间和速度
? 代码审查的初始参考值,
? 准备：每小时 125行非注释源代码；
? 审查会：每小时 90行非注释源代码 。
? 对伪码或 PDL的审查, 上述数字应加倍 。
? 审查会不应超过两个小时 。
软件审查活动
? 综述,综述的目的是向审查组介绍被审
查项 。 主任介绍要审查的范围, 然后详
细介绍设计的具体的范围, 再将输入分
配给参加者 。
软件审查活动
? 准备,主任, 阅读员和审查员对输入进行熟悉 。
通过阅读下列资料来做好代码审查的准备,
? 要审查的代码设计规范；
? 编码标准；
? 含以前审查发现的普遍编码错误的代码审查检查单；
? 被审查的代码 。
? 被审查项的缺陷要在评审差异表中记录, 并在
审查过程中合适的时候进行宣布 。 准备工作应
单独进行, 而不要在会议上进行 。
软件审查活动 -审查会
? 主任检查成员的准备工作, 报告和记录各成员所花费的时间 。
? 由阅读员引导会议遍历被评审项 。 对文件阅读员可总结某些部分
的内容, 并一行一行地读完所有内容 。 对代码阅读员应覆盖每个
逻辑块, 至少详细讨论每个分支一次 。 审查员利用检查单来发现
普遍错误 。
? 秘书对阅读中发现的缺陷立即进行记录 。 包括下列的内容,
? 严重性, 技术分类, 位置, 描述
? 不记录确定的任何解决措施 。 审查组应避免寻找解决措施, 而应
集中精力发现缺陷 。
? 在审查会结束前, 审查组应作出下列中的一种决定,
? 当修改完成之后 （ 如果有 ） 接收该审查项；
? 当修改完成之后由主任负责接收该审查项；
? 重新审查整个被审查项 （ 如果 5%以上需要修改 ） 。
? 秘书应在之前起草会议纪要, 以便修改工作能及时地进行 。
软件审查 — 活动
? 修改
? 审查之后, 软件作者纠正缺陷清单中列出的缺陷 。
? 补充活动
? 修改之后, 补充活动验证所有的缺陷都得到了正确
的纠正, 而无其它缺陷被引入 。
? 主任负责补充活动 。
? 其它补充活动是,
? 依据不同错误类型变化的频率修改检查单；
? 分析缺陷统计资料, 也许会导致对软件验证与确认工作的
改进 。
软件审查的 输出
? 缺陷单
? 缺陷统计
? 审查报告
技术评审和审查指南
? 事先必须建立技术评审和审查工作指南,
分发给所有的评审 （ 审查 ） 人员共同遵
守 。 一个不受控制的评审会常常出错,
可能会比不评审更坏 。
技术评审和审查指南的基本内容
(1) 评审产品, 不评审生产者
(2) 建立一个议事日程并遵循它
(3) 限制争论和辩驳
(4) 说明问题的大小, 但不要企图解决所有提出的问题
(5) 作记录
(6) 限制参与人数和坚持充分准备
(7) 为可能评审的产品准备一张检查表
(8) 为技术评审安排资源和时间表
(9)对所有评审人员进行有意义的培训
(10) 评审你早期的评审
项目风险管理
?“抱最大的希望，
做最坏的准备,
? -----------英国古谚
风险的概念
风险是损失发生的可能性
1、主体
2、损失
3、可能性
风险 =损失 × 可能性
风险大小
损失
概
率
（
可
能
性
）
风险增大
高度风险区
中度风险区
低度风险区
降低风险 的思路
损失
概
率
（
可
能
性
）
风险增大
高度风险区
中度风险区
低度风险区
风险的特征
? 客观性
? 普遍性
? 偶然性
? 可变性
风险管理
利用科学的方法去识别风险、评价风
险并设计、实施有效的方法去控制风
险。
风险管理过程
明确目标
风险识别
风险评价
设计、评价、抉择风险应对方案
实施方案
评估与审核
项目风险
项目风险,造成项目达不到预期目标甚至失败的
可能性。
IBM咨询集团发现 68%的顾客 /服务器项目耗时太长,55%的项目成本
超出预算。
,财富, 公布超过 80%的负责人对企业业务流程在造（ BPR）的工作
感到失望。
项目风险产生的原因
1,项目的未来性
2、项目的复杂性
3、项目环境的变化
4、项目中人的因素
现代项目风险产生的原因
1,生产极度复杂的产品
2、依赖多种数据来源
3、采用功能交叉的方法
4、项目管理与企业战略的紧密结合
5、产品从概念到市场的时间缩短
6、满足顾客需求
7、市场的国际化
8、鼓励参与者取得更大的合伙权和所有权
9、分散经营
10、应用更多专业技术
11、依赖更复杂的工具
风险识别的依据
? 产品或服务的说明书
? 项目的前提、假设、制约因素
? 项目规划
? 可以类比的项目
风险识别方法
? 基于损失的识别方法与系统安全技术
? 现场检查法
? 检核表及问卷调查法
? 流程图及组织结构图
? Hazard and Operability Studies
? 故障树
? 归因策略
Boehm(1991) Top Ten Risk Item
1,人力不足
2,不切实际的进度和预算
3,开发错误的软件功能
4,开发错误的用户界面
5,镀金
6,连续不断的需求变更
7,外部执行任务的短缺
8,外部供应部件的短缺
9,实时性能的短缺
10,紧张的计算机科学能力
项目风险衡量
? 风险事故发生造成损失衡量
? 损失发生概率衡量
项目风险应对选择策略
损失小 损失大
概
率
大
概
率
小
A
B
C
D
风险应对策略
? 风险回避
? 风险减轻
? 风险自担
? 风险转移
? 风险共担
谢谢！
汤铭端
68389085（ O） 68215365（ Fax）
mdtang@btamail.net.cn
软件工程实践
汤铭端
中国航天科工集团公司 706所
第十讲
质量管理与质量保证
评审与审查
风险管理
目的与内容
? 掌握质量的概念
? 了解质量管理和质量保证的内容和过程
? 掌握评审和审查的过程
? 了解和掌握风险管理的概念与过程
质量管理
质量的概念
? 质量定义：反映实体满足明确和隐含需
要能力的特性综合
? 定义的说明,
? 明确需要：指合同中用户明确提出的要求与
需要
? 隐含需要：指由生产企业通过市场调研进行
识别与探明的要求或需要
? 特性：实体所特有的性质，反映了实体满足
需要的能力
软件质量的定义
? ANSI/IEEE Std 729-1983定义软件质量
为,与软件产品满足规定的和隐含的需
求的能力有关的特征或特性的全体,。
? M.J,Fisher 定义软件质量为,所有描述
计算机软件优秀程度的特性的组合,。
质量特性及其组合
? 为满足软件的各项精确定义的功能、性能需求，符合
文档化的开发标准，需要相应地给出或设计一些质量
特性及其组合。
? 如果这些质量特性及其组合都能在产品中得到满足，
则这个软件产品质量就是高的。
? 软件需求是度量软件质量的基础 。不符合需求的软件
就不具备质量。
? 标准定义了一组开发准则，用来指导软件人员用工程
化的方法来开发软件 。如果不遵守这些开发准则，软
件质量就得不到保证。
? 软件质量是各种特性的复杂组合。它随着应用的不同
而不同，随着用户提出的质量要求不同而不同。
什么是软件质量
成本
可靠
维护
及时
交付
正确 功能
功能
成本 及时 交付
软件质量的若干侧面
项目的质量
? 质量的类型,
? 质量，通常指产品的
质量，广义的还包括
工作的质量。 产品质
量 是指产品的使用价
值及其属性；
? 而 工作质量 则是产品
质量的保证，它反映
了与产品质量直接有
关的工作对产品质量
? 项目的质量
? 从项目作为一次性的活
动来看，项目质量体现
在由 WBS反映出的项目
范围内所有的阶段、子
项目、项目工作单元的
质量所构成，也即 项目
的工作质量 ；
? 从项目作为一项最终产
品来看，项目质量体现
在其性能或者使用价值
上，也即 项目的产品质
量 。
产品质量与过程质量
产品质量
开发技术
成本,
时间、进度
过程质量 人员素质
影响产品质量的 4个方面
软件质量特性与模型
? 软件质量特性，反映了软件的本质 。讨
论一个软件的质量，问题最终要归结到
定义软件的质量特性。
? 定义一个软件的质量，就等价于为该软
件定义一系列质量特性。
? 人们通常把影响软件质量的特性用软件
质量模型来描述 。
软件质量模型
? 软件质量特性定义成 分层模型
? 最基本的叫做 基本质量特性,它可以由
一些子质量特性定义和度量。
? 二次特性 在必要时又可由它的一些子质
量特性定义和度量。
? 1976年 Boehm质量模型
? 1979年 McCall质量模型
? 1985年 ISO质量模型
McCall软件质量 11特性
? 使用性
? 正确性
? 可靠性
? 效率
? 完整性
? 适应性
? 测试性
? 维护性
? 移植性
? 重用性
? 互操作性
Boehm质量模型
ISO的软件质量评价模型
? 按照 ISO/TC97/SC7/WG3/1985-1-
30/N382，软件质量度量模型由三层组成
? 软件质量需求评价准则 （ SQRC）
? 软件质量设计评价准则 （ SQDC）
? 软件质量度量评价准则 （ SQMC）
? 高层和中层建立国际标准，低层可由各
使用单位视实际情况制定
（ ISO/IEC9126,1991年） 质量特性
? 质量特性,功能性, 可靠性, 可维护性,
效率, 可使用性, 可移植性
? 推荐 21个子特性：适合性 准确性 互用
性 依从性 安全性 成熟性 容错性
可恢复性 可理解性 易学习性 操作
性 时间特性 资源特性 可分析性
稳定性 可变更性 可测试性 可安装
性 可替换性 适应性 一致性
质量成本
? 质量成本是实施单位为了保证和提高产品质量、满
足用户需要而支出的费用，以及因未达到质量标准
而产生的一切损失费用的总和。
? 简单地说，质量成本可被分成, 一致成本, 和, 不
一致成本,
? 一致成本包括：培训、指导、查证、确认、测试、
维持、测量、审查等的费用
? 不一致成本包括：损耗、返工、维修、产品回收、
投诉处理等的费用
? 通过缩减一致成本来节省费用会带来灾难性后果
? 第一次要完全正确
另外的区分费用的通用方法
?预防成本
?关注第一个以及以后诸个无瑕疵产品对顾客需求满足程度的预先
成本
?如设计评价、培训,QA、供给调查等预防活动
?评估成本
?评价产品或过程以确定如何满足所有客户需求相关的费用
?如产品检查、测试、设计评审等
?内部故障成本
?与满足客户需求在脱离组织控制前出现故障相关的费用
?如损耗、返工、维修、停工期、瑕疵评估、损耗评估等
?外部故障成本
?与那些需求没能满足的客户的决定相关的费用
?如客户退货和补贴、客户抱怨评估、检查、调查、纠正等
总质量成本
预防
评估
内部故障
外部故障
节约
当前 未来
最小化质量总成本
? 50%或更多的质量成本
来自内外部的故障
? 故障的完全消除是一个
理想但非有效的解决方
案
? Juran,
? 只要每单位的评价和预防
费用低于非一致成本，资
源会分配到预防和评价中
? 当预防和评价成本开始增
加每单位的质量成本时，
策略是维持质量不变
? 最小化质量总成本
内外部故障成本
评估和预防成本
总质量成本
100%次品 100%
合格品
最优质量成本
每
单
位
合
格
产
品
的
质
量
成
本
最小质量成本
质量管理的内容
? 质量计划
? 质量控制
? 质量保证
? 戴明环 ——PDCA
? P,Plan-计划
? D,Do-实施
? C,Check-检查
? A,Action-处理
P
D
C
A
质量管理
? 质量管理即在质量方面指挥和控制组织的协调活动
? 质量管理是指确定质量方针、目标和职责并在质量体
系中通过诸如质量策划、质量控制、质量保证和质量
改进并使其实施的全部管理职能的活动
? 质量方针
? 质量目标
? 质量策划
? 质量控制
? 质量保证
? 质量改进
戴明环 ——PDCA环
? P,Plan-计划
? D,Do-实施
? C,Check-检查
? A,Action-处理 P
D
C
A
质量计划
? 质量计划的目的主要是确保项目的质量
标准能够得以满意的实现, 其关键是在
项目的计划期内确保项目按期完成, 同
时要处理与其他项目计划之间的关系 。
质量计划的内容
? 需达到的质量目标
? 质量工作具体流程
? 在项目各个不同阶段，职责、权限和资源的具
体分配
? 项目实施中需采用的具体的书面程序和指导书
? 有关阶段适用的试验、检查、检验和评审大纲
? 达到质量目标的测量方法
? 随项目的进展而修改和完善质量计划的程序
? 为达到项目质量目标必须采用的其它措施
项目质量控制
? 质量控制主要是监督项目的实施结果, 将项目
的结果与事先制定的质量标准进行比较, 找出
其存在的差距, 并分析形成这一差距的原因,
质量控制同样贯穿于项目实施的全过程 。 项目
的结果包括产品结果 （ 如交付 ） 以及管理结果
（ 如实施的费用和进度 ） 。 质量控制通常是由
质量控制部门或类似的质量组织单元实施, 但
是也并非总是如此 。
质量保证
? 质量保证是所有计划和系统工作实施达到质量
计划要求的基础, 为项目质量系统的正常运转
提供可靠的保证, 它应该贯穿于项目实施的全
过程之中 。 在 ISO9000系列实施之前, 质量保
证通常被描述在质量计划之中 。
? 质量保证通常是由质量保证部门或者类似的组
织单元提供, 但是不必总是如此 。 质量保证通
常提供给项目管理组以及实施组织 （ 内部质量
保证 ） 或者提供给客户或项目工作涉及的其它
活动 （ 外部质量保证 ） 。
“质量保证, 与, 保证质量,
? 保证质量是质量控制的任务
? 用户不提 QA，项目实施者也要进行质量控制，
保证项目质量满足用户要求
? QA是以保证质量为基础，进一步引伸到提供质
量, 信任, 这一基本目的
? QA的主要工作是促进完善质量控制，以便准备
好客观证据，并根据对方的要求有计划、有步
骤地开展提供证据的活动
?, 保证, 有, 保险, 的意义
软件质量保证
? 软件质量保证 的目的是向管理者提供适
当的对软件项目正使用的过程和正构造
产品的可视性 。
? 软件质量保证 包括评审和审计软件产品
和活动以验证它们符合适用的规程和标
准，给项目和其它有关的经理提供这些
评审和审计的结果。
SQA的问题处理渠道
? 首先在软件项目内部处理符合性问题,
如可能的话就地解决它 。
? 对于那些无法在软件项目内部解决的问
题, 软件质量保证组逐级上递该问题到
管理者的恰当层次以求得解决 。
SQA的目标
? 目标 1 软件质量保证活动是有计划的 。
? 目标 2 软件产品和活动遵守适用的标准,
规程和需求的情况得到客观的验证 。
? 目标 3 受影响的组和个人接到软件质量
保证活动和结果的通知 。
? 目标 4 高级管理者处理在软件项目内部
不能解决的不符合问题 。
SQA的独立性
? 存在负责协调和实施项目的 SQA的组
? SQA有一个向高级管理者报告的渠道, 它独立于：项
目经理, 软件工程组, 其它的有关组
? 组织机构支持那些要求独立性的活动, 如 SQA
? 独立性应该,
? 给担当 SQA角色的个人提供组织上的自由度, 使他
们成为高级管理者在软件项目上的, 耳目, 。
? 使得担当 SQA角色的个人免受他们正在评审的软件
项目的管理者所作的性能评价的影响 。
? 使高级管理者相信正在报告的有关项目过程和产品
的信息是客观的 。
SQA过程活动
活动 1 按照已建档的规程为软件项目制订 SQA计划
活动 2 按照 SQA计划进行 SQA组的活动
活动 3 SQA组参与准备和评审项目的软件开发计划, 标
准和规程
活动 4 SQA组评审软件工程活动以验证符合性
活动 5 SQA组审计指定的软件工作产品以验证符合性
活动 6 SQA组定期向软件工程组报告其活动的结果
活动 7 按照已文档化的规程对在软件活动和软件工作产
品中所鉴别出的偏差建立文档并加以处理
活动 8 SQA组与顾客的 SQA人员一起对它的活动和发现
进行定期评审
SQA计划的内容
1,SQA组的职责和权力
2,SQA组的资源要求
3,项目的 SQA组活动的进度表和投资
4,SQA组参加制定项目的软件开发计划、标准和规程的情况
5,将由 SQA完成的评价
6,将由 SQA组进行的审计和评审
7,将用作 SQA组评审和审计的基础的项目的标准和规程
8,用于对不符合性问题建立文档和进行跟踪直至结束的规程
9,要求 SQA组生成的文档
10.就 SQA活动给软件工程组和其它软件 —有关组提供反馈信
息的方法和频率
软件可靠性与容错设计
软件可靠性
硬件系统故障率
0 t
Z(t)
软件系统故障率
0 t
Z(t)
软件可靠性定义
在给定 时间间隔 内 和特定的 环境
下，软件 按规格说明 成功运行 的
概率 。
软件可靠性的主要指标
借用硬件可靠性的定量度量方法来度
量软件的可靠性,
? MTBF:平均故障间隔时间
? MTTF:平均故障时间
t1,t2,.....,tn:失效时间
MTTF＝
n
i=1
n
1 ∑ t
i
软件可靠性定义的要素
(1)环境条件
规定软件的使用环境
(输入数据要求和环境 )
(2)规定时间
时间 t是随机变量。
(3)规定的功能
(4)成功运行
软件容错技术
? 提高软件质量和可靠性的技术,
? 避开错误技术
? 容错技术
? 对无法避开的差错，使其影响减至
最小的技术
什么是容错软件？
定义 1：规定功能的软件，在一定程度上对
自身错误的作用具有屏蔽能力的软件；
定义 2：规定功能的软件，在一定程度上能
从错误状态自动恢复到正常状态的软件；
定义 3：规定功能的软件，在因错误而发生
错误时，仍能在一定程度上完成预期的
功能的软件。
容错的一般方法
? 实现容错计算的方法（容错资源）,
? 错误检测算法
? 错误恢复算法
? 软件冗余备份
? 容错软件
? 主体：常规软件所需资源
? 附加体：容错资源
? 实现容错计算的主要手段是 冗余
容错
? 冗余技术分类,
? 结构冗余
? 静态冗余
? 动态冗余
? 混合冗余
? 信息冗余
? 时间冗余
? 软件的容错系统结
构
? 多版本结构
? 恢复块结构
结构冗余：静态冗余
? 3模冗余、多模冗余
? 3模（ TMR）表决系统的结构
U
M1
M2
M3
V
u2
u1
u3
I
表决器
U=(u1∧ u2)∨ (u2∧ u3)∨ =(u1∧ u3)
结构冗余：动态冗余
? 多重模块待机储备,相继运行
? 待机储备系统结构
M1
M2
M3
主模块
备用 I 开关
Mn
…,
备用
备用
结构冗余：混合冗余
? 混合冗余 H（ N,K）结构
M1
M2
Mk I
开关
Mn
…,
Mk+1
…,
V
转
换
开
关
信息冗余
? 以检测或纠正信息在运算或传输中的错
误为目的而外加的一部分信息
? 误差校正码,
? 奇偶码
? 定重码
? 循环码
? ……
时间冗余
? 以重复执行指令（指令复执）或程序
（程序复算）来消除瞬时错误带来的影
响
? 常用的程序复算方法,程序滚回技术
出错
…… t
0 t1 t2 t3 ti-1 ti ti+1
i-1 i 1 2
3
时刻 t0,t1,t2,…,对应于程序中预先设置好的恢复点
容错结构,多版本结构
? 把同一功能的不同版本的程序 (多为子系
统或模块级 )并行联结到系统中,构成冗
余并行模型
? 多版本程序示意图
版本 1
版本 2
版本 3
…..,
表决
同一功能
容错结构,恢复块结构
要求做容错的块 (基本块 )
提供,
备份块 (独立设计的相应冗余备份 )
附加的错误检验
恢复措施
恢复块 Ensure 接受测试
By 基本块
Else By备份块 1
……
Else By备份块 n
Else 错误
恢复块的工作方式
保存现场
队空 从恢复块的备份块
队列中取一个模块
激活此模块
执行此模块
恢复现场
接受测试 T
有问题
显示错误及位置
继续执行后续工作 通过
不通过
评审与审查
Review & Inspection
概论
? 在软件的研制过程中必须进行的一项重要工作，
就是软件的验证与确认。
? 软件验证是确定软件开发周期中的一个给定阶
段产品是否达到前阶段确立的需求的过程。它
包括评审、审查、测试、检查、审计等项活动。
? 软件确认是在软件开发过程结束时对软件进行
评价，以确认它和软件需求是否相一致的过程。
也可以说，确认是, 端到端, 的验证。
什么是验证与确认
? 验证和确认是两项相辅相成的工作，但它们之
间却极易混淆。
? 软件工程权威 Barry W,Boehm曾巧妙地用两句
形式相似但内容不同的话作过精辟的描述,
? Verification,Are we building the product right?
? Validation,Are we building the right product?
? 验证：我们正正确地制造产品吗？
? 确认：我们正制造正确的产品吗？
为什么 IV&V
? 不论项目大小如何，软件验证与确认很大程度地
影响着软件的质量。
? 人总是会犯错误的，而没有经过验证的软件将难
以正常工作。
? 有典型事例说明在开发期间每 1000行代码中发现
有 20到 50个错误，而即使是在系统测试之后每
1000行代码中仍有 1.5到 4个错误。
? 软件验证与确认的目标是把错误减少到可以接受
的水平。
? 软件的验证与确认工作占用整个项目的 30%～
90%的资源。
验证与确认 V形图
? 软件开发工作开始于图的左上角，沿左
边的产生, 软件规格, 侧向下进行到
,Ｖ, 的底端，其间要逐阶段进行验证；
? 之后沿右边的产生, 软件产品, 侧向上，
之间对应着它们对, 软件规格, 的验证。
? Ｖ形图强调在左侧按照输入验证每个输
出及在右侧根据, 软件规格, 验证软件
产品。
系统需求
软件需求
概要设计
详细设计 单元测试
组装测试
编码
确认测试
系统联试
详细设计
概要设计
软件需求
系统需求
型号任务
编译后的单元
测试后的单元
组装后的软件
测试后的软件
交付软件
验证
验证
验证
验证
验证
验证
验证与确认
验证与确认
V形图验证与确认说明
? 根据系统需求验证软件需求
? 根据软件需求验证概要设计
? 根据概要设计验证详细设计
? 根据详细设计验证编码
? 用单元测试验证详细设计
? 用组装测试验证概要设计
? 用确认测试验证软件需求
? 用系统联试验证系统需求
通过评审进行 IV&V
? 对软件的工作产品进行验证的一个重要
方法是评审 。
? 评审是把工作产品或工作产品集提交给
项目人员, 经理, 用户, 顾客或其它感
兴趣各方进行评价或批准的过程或会议 。
? 评审一般有技术评审, 审查, 走查, 审
计等多种形式 。
? 检查阶段工作的管理评审称作阶段评审 。
为什么要及早进行评审
1)程序中的大部分错误是在编码之前造成的 。 据
统计, 设计及之前阶段产生的错误大约占 63％,
而编码错误仅占 37％ 。
2)错误的检测与改正时间越晚, 所付出的代价也
就越高 。 通过对一些大型软件项目的分析表明；
如果在需求和设计阶段发现一个错误, 改正所
需费用为 1；那么在测试前发现该错误, 改正
费用则为 6.5；在测试时发现, 改正费用为 15；
而在交付使用后再发现, 改正费用则高达 67。
3)错误还会被, 放大, 。
阶段评审
? 评审的目的
? 阶段评审在软件研制的各
个阶段完成了预定工作时
进行, 目的是检查该阶段
工作是否完成, 是否达到
了规定的质量和技术要求,
检查计划管理, 质量管理,
风险管理, 配置管理的执
行情况, 决定是否可以转
入下一个研制阶段 。
? 各研制阶段结束时均应进
行阶段评审 。
? 评审组成员
? 评审由项目组上级主管机
构组织, 组长由上级主管
领导担任 。 成员包括,
? 1） 主管领导；
? 2） 同行专家；
? 3） 质量管理人员；
? 4） 科研 （ 计划 ） 管理人
员；
? 5） 项目组成员；
? 6 ） 交办方代表 （ 必要
时 ） 。
阶段评审 程序（ 1）
? （ 1）评审前的准备
? 准备阶段评审汇报和被评审文件。汇报内容,
? 1）本阶段研制工作的主要内容和完成情况；
? 2）为保证产品质量所做的质量保证工作；
? 3）计划落实和配置管理情况；
? 4）本阶段出现的主要问题及解决情况；
? 5）结论及建议。
? （ 2）确定评审人员和日期
? （ 3）评审组分工
? （ 4）评审组审阅评审文件
? 承办单位提前三天将评审文件提交评审组审阅
阶段评审 程序 （ 2）
? （ 5） 评审会议
? 1） 软件研制项目组作阶段评审汇报；
? 2） 评审组询问, 讨论, 审查各项工作, 项目组答辩；
? 3） 评审组作出评审结论并由组长宣布 。
? （ 6） 填写评审总结报告
? （ 7） 评审后的工作
? 评审结论入配置管理, 保存备案, 交上级审批 。
? 项目组针对修改意见和改进建议, 经审批进行修改补充 。
? 项目组根据评审意见, 转入下一研制阶段 。
阶段评审表
? 在每次阶段评审时, 都必须履行正式手续, 填
写必要的评审表格, 以利于项目管理和质量检
查 。
? 阶段评审表由三张子表组成
? 子表 1是对评审中发现问题的记录
? 子表 2是评审总结报告
? 子表 3是评审小组成员登记与签字表
? 对于在评审中发现的软件问题, 用软件问题报
告单对问题进行详细的描述 。
评审问题记录
登记号
评审日期
年 月 日
评审性质
评审□复审□
项目名
子项目名
代号
编号
问题摘要
问题类型
是否解决
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
评审总结报告
登记号
评审日期
年 月 日
评审性质
评审□复审□
项目名
子项目名
代号
阶段名
系统
需求
□
需求
分析
□
概要
设计
□
详细
设计
□
软件
实现
□
组装
测试
□
确认
测试
□
系统
联试
□
项目组长
姓名
单
位
电
话
评
审
任
务
评
审
材
料
通
过
不需修改
稍作修改
不
通过
作重要修改
要重新评审
备
注
评
审
小
组
成
员
职务
姓名
职称
单位
签字
组长
副组长
成员
成员
成员
成员
成员
成员
成员
技术评审
? 以下技术评审过程是欧洲航空局最佳实践过程
之一
? 目的
? 技术评审的目的是对具体的工作产品集 （ 如文档,
源代码 ） 进行评价, 并对管理提供以下信息,
? 它们符合前一阶段制定的软件规格；
? 它们已按照项目的标准和方法完成；
? 所有的更改都正确地得到完成, 并只影响对更改规定的范
围 。
组织
? 技术评审过程由评审组来执行, 评审
组中有以下的角色,
? 负责人
? 秘书
? 成员
职责
? 负责人的责任包括,
? 提名评审组；
? 组织评审并通知所有参加者评审的时间, 地点和日
程；
? 会议前向所有参加者分发评审项并在必要时分配评
审项；
? 必要时组织评审组开展准备工作；
? 主持评审会议；
? 发布技术评审报告 。
? 必要时秘书应协助负责人, 并负责记录评审组发现
的问题, 作出的决定和建议 。
职责
? 各评审组成员检查评审项并参加评审会议 。
? 如果被评审项规模大, 复杂或需要各种专业
的专家技能才能进行有效的评审, 那么负责
人可以在成员中分配评审项 。
输入
? 适当时，对技术评审过程的输入包括,
? 评审会议日程；
? 对目的的陈述；
? 评审项 （ 如被评审的软件需求规格说明, 软件概要
设计说明 ） ；
? 评审项应符合的上阶段给出的软件规格 （ 如评审软
件详细设计说明时所对应的软件概要设计说明 ） ；
? 评审项使用的计划, 标准及指南；
? 与评审项有关的评审差异表, 软件问题报告单, 修
改报告单；
? 软件质量保证人员的报告 。
评审差异表
编号
日期
提出人
1 文档标题,
2 文档代号,
3 文档发布 /版本号,
4 问题位置,
5 问题说明,
6 建议解决方法,
7 作者答复,
8 评审决定,
结束／更改／措施／拒收 （ 划出选择 ）
活动 =准备 +评审会议
? 准备
? 负责人起草日程表, 并将其与目的, 被评审项, 规
格, 计划和指南一起散发给评审组 。
? 评审组成员对评审项进行检查 。 通过完成评审差异
表来对在检查中发现的每个问题进行记录 。 将评审
差异表退还给秘书 。
? 负责人将每张评审差异表按主要的, 次要的或编辑
上的进行分类
? 由秘书按被评审项中偏差的位置对评审差异表进行
排序 。
活动 =准备 +评审会议
? 评审会议
? 1)开始；
? 2)展示被评审项；
? 3)评审差异表的分类；
? 4)对主要的评审差异表的评审；
? 5)对其它的评审差异表的评审；
? 6)结论 。
评审结论
? 典型的结论是,
? 授权进行下一步的工作, 条件是完成更改工作和采
取措施；
? 授权进行限定部分的工作；
? 执行决定的附加工作 。
? 如未能对达成一致意见和得出结论, 则,
? 在评审报告中记录非主流的不同观点；
? 由一名或多名成员在会议外寻找解决方法；
? 把问题移交给上一级管理部门 。
输出
? 报告摘要；
? 成员名单；
? 被评审项的确定；
? 按照分类编组的带处置标志的评审差异表, 软件问题
报告单, 软件修改报告单等；
? 措施清单, 以及各措施的人员责任和预期完成日期；
? 结论 。
? 输出可采取会议记录的形式, 或采取独立报告的形式 。
? 报告应足够详细, 以便于管理部门判断发生了什么事 。
? 如果在评审期间难以达成一致意见, 可建议评审组成员对输
出不签字 。
软件审查
? 软件审查可用于编码前发现详细设计中的缺陷, 在测
试前发现代码的缺陷 。 软件审查也可以用于验证测试
设计, 测试用例和测试过程 。
? 软件审查是有效的 。 通过审查, 可以查出开发过程所
带给项目的全部缺陷的 50%。
? 软件审查是经济的, 因为它可以大大减少缺陷的数量
和降低消除缺陷的费用 。 在缺陷产生后尽可能短的时
间内发现缺陷可以,
? 使软件开发者增强查找缺陷产生原因的意识, 以便
减少类似缺陷再出现的可能性；
? 使查找缺陷的工作量减少, 因为不需要在许多可能
的组成部分以外去诊断哪个组成部分有缺陷 。
审查的目的
? 软件审查的目的是查出文档或代码中的
缺陷。
软件审查的 组织
? 主任：主任领导审查并主持审查会 。 主任应具备完成这项工作的
技能, 而不必要精通所审查的项目 。 他 （ 她 ） 必须是公平的, 客
观的 。 鉴于这些原因, 主任常常从与项目无关的职员中选出 。 最
好他们受过有关审查过程的培训 。
? 秘书：秘书负责记录审查会的记录, 特别是记录发现的每个缺陷
的细节 。
? 阅读员：阅读者引导审查组遍历被审查项 。
? 审查员：审查员在审查时确定和描述被审查项的缺陷 。 选择的审
查员应能代表各种观点 （ 如：设计员, 编码员和测试员 ） 。
? 作者：作者是被审查项的编制人员 。 作者主要回答关于被审查项
的问题, 并负责所有的修改 。
? 一个人可担任上述一种或多种角色 。 没有人既担任作者又担任其
它角色 。
软件审查的 输入
? 被审查项（如源代码，或其它文档）
? 被审查项应符合的规格（如详细设计）
? 审查检查单
? 应用于被审查项的标准和指南
? 审查报告表
? 从上一次审查中获得的缺陷表
活动 =综述、准备、审查会、修改、补充活动
? 综述是对被审查项进行介绍 。
? 之后审查员对被审查项进行熟悉, 作好
参加审查会的准备 。
? 然后, 审查员在审查会上检查被审查项,
确定缺陷并决定是否对缺陷进行纠正 。
? 修改工作包括对故障的修复 。
? 补充活动是指检查在审查会上作出的所
有决定是否都得到了执行 。
审查的时间和速度
? 代码审查的初始参考值,
? 准备：每小时 125行非注释源代码；
? 审查会：每小时 90行非注释源代码 。
? 对伪码或 PDL的审查, 上述数字应加倍 。
? 审查会不应超过两个小时 。
软件审查活动
? 综述,综述的目的是向审查组介绍被审
查项 。 主任介绍要审查的范围, 然后详
细介绍设计的具体的范围, 再将输入分
配给参加者 。
软件审查活动
? 准备,主任, 阅读员和审查员对输入进行熟悉 。
通过阅读下列资料来做好代码审查的准备,
? 要审查的代码设计规范；
? 编码标准；
? 含以前审查发现的普遍编码错误的代码审查检查单；
? 被审查的代码 。
? 被审查项的缺陷要在评审差异表中记录, 并在
审查过程中合适的时候进行宣布 。 准备工作应
单独进行, 而不要在会议上进行 。
软件审查活动 -审查会
? 主任检查成员的准备工作, 报告和记录各成员所花费的时间 。
? 由阅读员引导会议遍历被评审项 。 对文件阅读员可总结某些部分
的内容, 并一行一行地读完所有内容 。 对代码阅读员应覆盖每个
逻辑块, 至少详细讨论每个分支一次 。 审查员利用检查单来发现
普遍错误 。
? 秘书对阅读中发现的缺陷立即进行记录 。 包括下列的内容,
? 严重性, 技术分类, 位置, 描述
? 不记录确定的任何解决措施 。 审查组应避免寻找解决措施, 而应
集中精力发现缺陷 。
? 在审查会结束前, 审查组应作出下列中的一种决定,
? 当修改完成之后 （ 如果有 ） 接收该审查项；
? 当修改完成之后由主任负责接收该审查项；
? 重新审查整个被审查项 （ 如果 5%以上需要修改 ） 。
? 秘书应在之前起草会议纪要, 以便修改工作能及时地进行 。
软件审查 — 活动
? 修改
? 审查之后, 软件作者纠正缺陷清单中列出的缺陷 。
? 补充活动
? 修改之后, 补充活动验证所有的缺陷都得到了正确
的纠正, 而无其它缺陷被引入 。
? 主任负责补充活动 。
? 其它补充活动是,
? 依据不同错误类型变化的频率修改检查单；
? 分析缺陷统计资料, 也许会导致对软件验证与确认工作的
改进 。
软件审查的 输出
? 缺陷单
? 缺陷统计
? 审查报告
技术评审和审查指南
? 事先必须建立技术评审和审查工作指南,
分发给所有的评审 （ 审查 ） 人员共同遵
守 。 一个不受控制的评审会常常出错,
可能会比不评审更坏 。
技术评审和审查指南的基本内容
(1) 评审产品, 不评审生产者
(2) 建立一个议事日程并遵循它
(3) 限制争论和辩驳
(4) 说明问题的大小, 但不要企图解决所有提出的问题
(5) 作记录
(6) 限制参与人数和坚持充分准备
(7) 为可能评审的产品准备一张检查表
(8) 为技术评审安排资源和时间表
(9)对所有评审人员进行有意义的培训
(10) 评审你早期的评审
项目风险管理
?“抱最大的希望，
做最坏的准备,
? -----------英国古谚
风险的概念
风险是损失发生的可能性
1、主体
2、损失
3、可能性
风险 =损失 × 可能性
风险大小
损失
概
率
（
可
能
性
）
风险增大
高度风险区
中度风险区
低度风险区
降低风险 的思路
损失
概
率
（
可
能
性
）
风险增大
高度风险区
中度风险区
低度风险区
风险的特征
? 客观性
? 普遍性
? 偶然性
? 可变性
风险管理
利用科学的方法去识别风险、评价风
险并设计、实施有效的方法去控制风
险。
风险管理过程
明确目标
风险识别
风险评价
设计、评价、抉择风险应对方案
实施方案
评估与审核
项目风险
项目风险,造成项目达不到预期目标甚至失败的
可能性。
IBM咨询集团发现 68%的顾客 /服务器项目耗时太长,55%的项目成本
超出预算。
,财富, 公布超过 80%的负责人对企业业务流程在造（ BPR）的工作
感到失望。
项目风险产生的原因
1,项目的未来性
2、项目的复杂性
3、项目环境的变化
4、项目中人的因素
现代项目风险产生的原因
1,生产极度复杂的产品
2、依赖多种数据来源
3、采用功能交叉的方法
4、项目管理与企业战略的紧密结合
5、产品从概念到市场的时间缩短
6、满足顾客需求
7、市场的国际化
8、鼓励参与者取得更大的合伙权和所有权
9、分散经营
10、应用更多专业技术
11、依赖更复杂的工具
风险识别的依据
? 产品或服务的说明书
? 项目的前提、假设、制约因素
? 项目规划
? 可以类比的项目
风险识别方法
? 基于损失的识别方法与系统安全技术
? 现场检查法
? 检核表及问卷调查法
? 流程图及组织结构图
? Hazard and Operability Studies
? 故障树
? 归因策略
Boehm(1991) Top Ten Risk Item
1,人力不足
2,不切实际的进度和预算
3,开发错误的软件功能
4,开发错误的用户界面
5,镀金
6,连续不断的需求变更
7,外部执行任务的短缺
8,外部供应部件的短缺
9,实时性能的短缺
10,紧张的计算机科学能力
项目风险衡量
? 风险事故发生造成损失衡量
? 损失发生概率衡量
项目风险应对选择策略
损失小 损失大
概
率
大
概
率
小
A
B
C
D
风险应对策略
? 风险回避
? 风险减轻
? 风险自担
? 风险转移
? 风险共担
谢谢！
汤铭端
68389085（ O） 68215365（ Fax）
mdtang@btamail.net.cn
