软件工程实践十质量和风险管理

北京理工大学

软件工程实践

汤铭端

中国航天科工集团公司706所

第十讲

质量管理与质量保证

评审与审查

风险管理

目的与内容

-掌握质量的概念

-了解质量管理和质量保证的内容和过程

-掌握评审和审查的过程

-了解和掌握风险管理的概念与过程

质量管理

质量的概念

■质量定义：反映实体满足明确和隐含需

要能力的特性综合

■定义的说明：

■明确需要：指合同中用户明确提出的要求与

W女

■隐含需要：指由生产企业通过市场调研进行

识别与探明的要求或需要

■特性：实体所特有的性质，反映了实体满足

需要的能力

软件质量的定义

■ANSI/IEEEStd729-1983定义软件质量

为“与软件产品满足规定的和隐含的需

爰的能方有关的特征或特性的全体”。

■M.J.Fisher定义软件质量为“所有描述

计算机软件优秀程度的特性的组合”。

s质量特性及其组合

-为满足软件的各项精确定义的功能、性能需求，符合

文档化的开发标准，需要相应地给出或设计一些质量

将性及其组合。

■如果这些质量特性及其组合都能在产品中得到满足，

则这个软件产品质量就是高的。

.软件需求是度量软件质量的基础。不符合需求的软件

就不具备质量。

-标准定义了一组开发准则，用来指导软件人员用工程

化的方法来开发软件。如果不遵守这些开发准则，软

件质量就得不到保证。

■软件质量是各种特性的复杂组合。它随着应用的不同

而不同，随着用户提出的质量要求不同而不同。

什么是软件质量

软件质量的若干侧面

4项目的质量

■质量的类型：■项目的质量

-质量，通常指产品的-从项目作为一次性的活

质量，广义的还包括动来看，项目质量体现

工作的质量。产品质在由WBS反映出的项目

范围内所有的阶段、子

量是指产品的使用价

项目、项目工作单元的

值及其属性；

质量所构成，也即项目

-而工作质量则是产品的工作质量；

质量的保证，它反映-从项目作为一项最终产

了与产品质量直接有品来看，项目质量体现

关的工作对产品质量在其性能或者使用价值

的保证程度。上，也即项目的产品质

量。

产品质量与过程质量

^^7

/i成本了\

i时间、进屋

影响产品质量的4个方面

软件质量特性与模型

■软件质量特性，反映了软件的本质。讨

论一个软件的质量，问题最终要归结到

定义软件的质量特性。

-定义一个软件的质量，就等价于为该软

件定义一系列质量特性。

-人们通常把影响软件质量的特性用软件

质量模型来描述。

软件质量模型

■软件质量特性定义成分层模型

■最基本的叫做基本质量特性，它可以由

一些子质量特性定义和度量。

■二次特性在必要时又可由它的一些子质

量特性定义和度量。

■1976年Boehm质量模型

■1979年McCall质量模型

■1985年ISO质量模型

McCalI软件质量11特性

-使用性-测试性

■正确性-维护性

-可靠性■移植性

■效率-重用性

■完整性-互操作性

■适应性

可维护性(Maintainability)互连性(interoperability)

可测试性(Testability)可移植性(Portability)

灵活性(Flexibility)复用性(Reusability)

PRODUCTPRODUCT

REVITIONTRANSITION

产品修正产品转移

产品运行

PRODUCTOPERATIONS

正确性(Correctness)可靠性(Reliability)

可使用性(Usability)&率(Efficiency)

完整咫(Integrity)

Boehm质量模型

ISO的软件质量评价模型

■按照ISO/TC97/SC7/WG3/1985-1-

30/N382,软件质量度量模型由三层组成

■软件质量需求评价准则（SQRC）

-软件质量设计评价准则（SQDC）

■软件质量度量评价准则（SQMC）

-高层和中层建立国际标准，低层可由各

使用单位视实际情况制定

SQRCSQDCSQMC

可追踪性

正确性完备性

一致性

准确性（精确性）

可靠性容错性（健壮性）使

简单性《复杂性》

简明性（可理解性）用

模块独立性

可维护性通用性单

可扩充性

自检性《工具性》位

效率自描述性

执行效率自

存储效率

安全性存取控制行

存取审查

操作性制

灵活性

可训练性《培训性》

通信性定

可使用性软件系统独立性

机器独立性

互连性通信共享性

数据共享性

（ISO/IEC9126，1991年）质量特性

■质量特性：功能性、可靠性、可维护性、

效率、可使用性、可移植性

■推荐21个子特性：适合性准确性互用

性依从性安全性成熟性容错性

可恢复性可理解性易学习性操作

性时间特性资源特性可分析性

稳定性可变更性可测试性可安装

性可替换性适应性一致性

功能性可靠性可使用性效率可维护性可移植性

功能性△△

可靠性V△

可使用性VA△

效率VVV

可维护性△V△

可移植性VV

其中，△表示有利影响,V表示不利影响。

《质量成本

-质量成本是实施单位为了保证和提高产品质量、满

足用户需要而支出的费用，以及因未达到质量标准

而产生的一切损失费用的总和。

■简单地说，质量成本可被分成“一致成本”和“不

一致成一”

-一致成本包括：培训、指导、查证、确认、测试、

维持、测量、审查等的费用

-不一致成本包括：损耗、返工、维修、产品回收、

投诉处理等的费用

-通过缩减一致成本来节省费用会带来灾难性后果

■第一次要完全正确

另外的区分费用的通用方法

■预防成本

■关注第一个以及以后诸个无瑕疵产品对顾客需求满足程度的预先

成本

■如设计评价、培训、QA、供给调查等预防活动

■评估成本

■评价产品或过程以确定如何满足所有客户需求相关的费用

■如产品检查、测试、设计评审等

■内部故障成本

■与满足客户需求在脱离组织控制前出现故障相关的费用

■如损耗、返工、维修、停工期、瑕疵评估、损耗评估等

■外部故障成本

■与那些需求没能满足的客户的决定相关的费用

■如客户退货和补贴、客户抱怨评估、检查、调查、纠正等

总质量成本

ri一

外部故障

评估

预防

当前未来

最小化质量总成本

■50%或更多的质量成本

来自内外部的故障

■故障的完全消除是一个

理想但非有效的解决方

案

■Juran：

■只要每单位的评价和预防

费用低于非一致成本，资

源会分配到预防和评价中

■当预防和评价成本开始增

加每单位的质量成本时，

策略是维持质量不变

-最小化质量总成本

100%次品最优质量成本100%

合格品

质量管理的内容

■质量计划戴明环—PDCA

■质量控制■P：Plan-计戈U

■D：Do-实施

■质量保证

-C：Check-检查

■A：Action-处理

VD

D

质量管理

■质量管理即在质量方面指挥和控制组织的协调活动

■质量管理是指确定质量方针、目标和职责并在质量体

系中通过诸如质量策划、质量控制、质量保证和质量

改进并使其实施的全部管理职能的活动

-质量方针

■质量目标

-质量策划

-质量控制

-质量保证

■质量改进

戴明环—PDCA环

■P：Plan-计划

■D：Do-实施

■C：Check-检查

■A：Action-处理

<D

3

《质量计划

-质量计划的目的主要是确保项目的质量

标准能够得以满意的实现，其关键是在

项目的计划期内确保项目按期完成，同

时要处理与其他项目计划之间的关系。

质量计划的内容

-需达到的质量目标

■质量工作具体流程

■在项目各个不同阶段，职责、权限和资源的具

彳本分酉已

■项目实施中需采用的具体的书面程序和指导书

■有关阶段适用的试验、检查、检验和评审大纲

■达到质量目标的测量方法

■随项目的进展而修改和完善质量计划的程序

■为达到项目质量目标必须采用的其它措施

项目质量控制

■质量控制主要是监督项目的实施结果，将项目

的结果与事先制定的质量标准进行比较，找出

其存在的差距，并分析形成这一差距的原因，

质量控制同样贯穿于项目实施的全过程。项目

的结果包括产品结果（如交付）以及管理结果

（如实施的费用和进度）。质量控制通常是由

质量控制部门或类似的质量组织单元实施，但

是也并非总是如此。

质量保证

■质量保证是所有计划和系统工作实施达到质量

计划要求的基础，为项目质量系统的正常运转

提供可靠的保证，它应该贯穿于项目实施的全

过程之中。在IS09000系列实施之前，质量保

证通常被描述在质量计划之中。

■质量保证通常是由质量保证部门或者类似的组

织单元提供，但是不必总是如此。质量保证通

常提供给项目管理组以及实施组织（内部质量

保证）或者提供给客户或项目工作涉及的其它

活动（外部质量保证）。

质量保证”与“保证质量”

■保证质量是质量控制的任务

■用户不提QA,项目实施者也要进行质量控制，

保证项目质量满足用户要求

■QA是以保证质量为基础，进一步引伸到提供质

量“信任”这一基本目的

■QA的主要工作是促进完善质量控制，以便准备

好客观证据，并根据对方的要求有计划、有步

骤地开展提供证据的活动

■“保证”有“保险”的意义

&软件质量保证

-软件质量保证的目的是向管理者提供适

当的对软件项目正使用的过程和正构造

产品的可视性。

■软件质量保证包括评审和审计软件产品

和活动以验证它们符合适用的规程和标

准，给项目和其它有关的经理提供这些

评审和审计的结果。

SQA的问题处理渠道

■首先在软件项目内部处理符合性问题，

如可能的话就地解决它。

■对于那些无法在软件项目内部解决的问

题，软件质量保证组逐级上递该问题到

管理者的恰当层次以求得解决。

&SQA的目标

-目标工软件质量保证活动是有计划的。

■目标2软件产品和活动遵守适用的标准、

规程和需求的情况得到客观的验证。

■目标3受影响的组和个人接到软件质量

保证活动和结果的通知。

■目标4高级管理者处理在软件项目内部

不能解决的不符合问题。

&SQA的独立性

■存在负责协调和实施项目的SQA的组

■SQA有一个向高级管理者报告的渠道，它独立于：项

目经理，软件工程组，其它的有关组

■组织机构支持那些要求独立性的活动，如SQA

■独立性应该：

■给担当SQA角色的个人提供组织上的自由度，使他

们成为高级管理者在软件项目上的“耳目”。

-使得担当SQA角色的个人免受他们正在评审的软件

项目的管理者所作的性能评价的影响。

-使高级管理者相信正在报告的有关项目过程和产品

的信息是客观的。

SQA过程活动

活动工按照已建档的规程为软件项目制订SQA计划

活动2按照SQA计划进行SQA组的活动

活动3SQA组参与准备和评审项目的软件开发计划、标

准和规程

活动4SQA组评审软件工程活动以验证符合性

活动5SQA组审计指定的软件工作产品以验证符合性

活动6SQA组定期向软件工程组报告其活动的结果

活动7按照已文档化的规程对在软件活动和软件工作产

品中所鉴别出的偏差建立文档并加以处理

活动8SQA组与顾客的SQA人员一起对它的活动和发现

进行定期评审

SQA计划的内容

1.SQA组的职责和权力

2.SQA组的资源要求

3.项目的SQA组活动的进度表和投资

4.SQA组参加制定项目的软件开发计划、标准和规程的情况

5,将由SQA完成的评价

6.将由SQA组进行的审计和评审

7.将用作SQA组评审和审计的基础的项目的标准和规程

8,用于对不符合性问题建立文档和进行跟踪直至结束的规程

9.要求SQA组生成的文档

10.就SQA活动给软件工程组和其它软件一有关组提供反馈信

息的方法和频率

软件可靠性与容错设计

）软件可靠性

Z(t)

0

t

硬件系统故障率软件系统故障率

软件可靠性定义

在给定时间间隔内和特定的环境

下，软件按规格说明成功运行的

概率。

软件可靠性的主要指标

借用硬件可靠性的定量度量方法来度

量软件的可靠性：

■MTBF:平均故障间隔时间

■MTTF:平均故障时间

tLt2,..........,tn:失效时间

111

MTTF=-1-v+

n乙li

i=l

软件可靠性定义的要素

(1)环境条件

规定软件的使用环境

(输入数据要求和环境)

(2)规定时间

时间t是随机变量。

(3)规定的功能

(4)成功运行

《软件容错技术

-提高软件质量和可靠性的技术：

■避开错误技术

■容错技术

■对无法避开的差错，使其影响减至

最小的技术

什么是容错软件?

定义L规定功能的软件，在一定程度上对

自身错误的作用具有屏蔽能力的软件；

定义2：规定功能的软件，在一定程度上能

从错误状态自动恢复到正常状态的软件；

定义3：规定功能的软件，在因错误而发生

错误时，仍能在一定程度上完成预期的

功能的软件。

容错的一般方法

■实现容错计算的方法（容错资源）：

■错误检测算法

■错误恢复算法

■软件冗余备份

■容错软件

■主体：常规软件所需资源

■附加体：容错资源

■实现容错计算的主要手段是冗余

容错

■冗余技术分类:■软件的容错系统结

■结构冗余构

-静态冗余■多版本结构

■动态冗余■恢复块结构

.混合冗余

■信息冗余

■时间冗余

《结构冗余：静态冗余

■3模冗余、多模冗余

■3模(TMR)表决系统的结构

U=(ulAu2)V(u2Au3)V=(ulAu3)

I.结构几余：动态几余

-多重模块待机储备,相继运行

-待机储备系统结构

&结构冗余：混合冗余

■混合冗余H(N,K)结构

4信息冗余

-以检测或纠正信息在运算或传输中的错

误为目的而外加的一部分信息

■误差校正码：

■奇偶码

■定重码

■循环码

时间冗余

-以重复执行指令（指令复执）或程序

（程序复算）来消除瞬时错误带来的影

响

■常用的程序复算方法：程序滚回技术

1111____III.

tot]t2t3tj_xtj4+1

时刻％ti,t2,….对应于程序中预先设置好的恢复点

容错结构:多版本结构

■把同一功能的不同版本的程序（多为子系

统或模块级）并行联结到系统中，构成冗

余并行模型

■多版本程序不意图

同一功能

I容错结构:恢复块结构

&求做容错的块（基本块）

提供：

密环块（独立设计的相应冗余备份）

附加的错误检验

恢复措施

恢复块（Ensure接受测试

JBy基本块

ElseBy备份块1

ElseBy备份块n

(Else错误J

&恢复块的工作方式

评审与审查

Review&Inspection

4概论

■在软件的研制过程中必须进行的一项重要工作,

就是软件的验证与确认。

■软件验证是确定软件开发周期中的一个给定阶

段产品是否达到前阶段确立的需求的过程。它

包括评审、审查、测试、检查、审计等项活动。

■软件确认是在软件开发过程结束时对软件进行

评价，以确认它和软件需求是否相一致的过程。

也可以说，确认是“端到端”的验证。

什么是验证与确认

■验证和确认是两项相辅相成的工作，但它们之

间却极易混淆。

■软件工程权威BarryW.Boehm曾巧妙地用两句

形式相似但内容不同的话作过精辟的描述：

■Verification:Arewebuildingtheproductright?

■Validation:Arewebuildingtherightproduct?

■验证：我们正正确地制造产品吗？

■确认：我们正制造正确的产品吗？

为什么IV&V

-不论项目大小如何，软件验证与确认很大程度地

影响着软件的质量。

■人总是会犯错误的，而没有经过验证的软件将难

以正常工作。

■有典型事例说明在开发期间每1000行代码中发现

有20到50个错误，而即使是在系统测试之后每

1000行代码中仍有L5到4个错误。

■软件验证与确认的目标是把错误减少到可以接受

的水平。

■软件的验证与确认工作占用整个项目的30%〜

90%的资源。

验证与确认V形图

■软件开发工作开始于图的左上角，沿左

边的产生“软件规格”侧向下进行到

“v”的底端，其间要逐阶段进行验证;

■之后沿右边的产生“软件产品”侧向上,

之间对应着它们对“软件规格”的验证。

■v形图强调在左侧按照输入验证每个输

出及在右侧根据“软件规格”验证软件

产品。

V形图验证与确认说明

■根据系统需求验证软件需求

■根据软件需求验证概要设计

■根据概要设计验证详细设计

■根据详细设计验证编码

■用单元测试验证详细设计

■用组装测试验证概要设计

■用确认测试验证软件需求

■用系统联试验证系统需求

通过评审进行IV&V

■对软件的工作产品进行验证的一个重要

方法是评审。

■评审是把工作产品或工作产品集提交给

项目人员、经理、用户、顾客或其它感

兴趣各方进行评价或批准的过程或会议。

■评审一般有技术评审、审查、走查、审

计等多种形式。

■检查阶段工作的管理评审称作阶段评审。

$为什么要及早进行评审

1）程序中的大部分错误是在编码之前造成的。据

统计，设计及之前阶段产生的错误大约占63%,

而编码错误仅占37%。

2）错误的检测与改正时间越晚，所付出的代价也

就越高。通过对一些大型软件项目的分析表明;

如果在需求和设计阶段发现一个错误，改正所

需费用为1；那么在测试前发现该错误，改正

费用则为6.5；在测试时发现，改正费用为15；

而在交付使用后再发现，改正费用则高达67。

3）错误还会被“放大”。

阶段评审

■评审的目的■评审组成员

-阶段评审在软件研制的各■评审由项目组上级主管机

个阶段完成了预定工作时构组织，组长由上级主管

领导担任。成员包括：

进行，目的是检查该阶段

工作是否完成，是否达到.1）主管领导；

了规定的质量和技术要求,■2）同行专家；

检查计划管理、质量管理、-3）质量管理人员；

风险管理、配置管理的执-4）科研（计划）管理人

行情况，决定是否可以转员；

入下一个研制阶段。-5）项目组成员；

■各研制阶段结束时均应进■6）交办方代表（必要

行阶段评审。时）。

阶段评审程序⑴

■(1)评审前的准备

-准备阶段评审汇报和被评审文件。汇报内容：

■1)本阶段研制工作的主要内容和完成情况；

■2)为保证产品质量所做的质量保证工作；

■3)计划落实和配置管理情况；

■4)本阶段出现的主要问题及解决情况；

■5)结论及建议。

■(2)确定评审人员和日期

■(3)评审组分工

■(4)评审组审阅评审文件

-承办单位提前三天将评审文件提交评审组审阅

阶段评审程序(2)

■(5)评审会议

■1)软件研制项目组作阶段评审汇报；

-2)评审组询问、讨论、审查各项工作，项目组答辩；

-3)评审组作出评审结论并由组长宣布。

-(6)填写评审总结报告

■(7)评审后的工作

■评审结论入配置管理、保存备案、交上级审批。

-项目组针对修改意见和改进建议，经审批进行修改补充。

-项目组根据评审意见，转入下一研制阶段。

阶段评审表

■在每次阶段评审时，都必须履行正式手续，填

写必要的评审表格，以利于项目管理和质量检

查。

■阶段评审表由三张子表组成

-子表1是对评审中发现问题的记录

-子表2是评审总结报告

-子表3是评审小组成员登记与签字表

■对于在评审中发现的软件问题，用软件问题报

告单对问题进行详细的描述。

登记号

评审问题记录

评审「1期年月日

评审性质评审□复审口

项目名子项目名代号

编号问题摘要问题类型是否解决

1

2

3

5

6

7

8

9

10

11

12

13

14

15

职务姓名职称单位签字

组长

评副组长

审

小成员

组

成成员

员

成员

成员

成员

成员

成员

技术评审

・以下技术评审过程是欧洲航空局最佳实践过程

之一

■目的

-技术评审的目的是对具体的工作产品集（如文档、

源代码）进行评价，并对管理提供以下信息：

-它们符合前一阶段制定的软件规格；

■它们已按照项目的标准和方法完成；

.所有的更改都正确地得到完成，并只影响对更改规定的范

围。

4组织

■技术评审过程由评审组来执行，评审

组中有以下的角色：

■负责人

■秘书

■成员

■负责人的责任包括：

-提名评审组；

-组织评审并通知所有参加者评审的时间、地点和日

程；

-会议前向所有参加者分发评审项并在必要时分配评

审项；

-必要时组织评审组开展准备工作；

-主持评审会议；

-发布技术评审报告。

-必要时秘书应协助负责人，并负责记录评审组发现

的问题、作出的决定和建议。

■各评审组成员检查评审项并参加评审会议。

■如果被评审项规模大、复杂或需要各种专业

的专家技能才能进行有效的评审，那么负责

人可以在成员中分配评审项。

-适当时，对技术评审过程的输入包括：

-评审会议日程；

-对目的的陈述；

-评审项（如被评审的软件需求规格说明、软件概要

设计说明）；

-评审项应符合的上阶段给出的软件规格（如评审软

件详细设计说明时所对应的软件概要设计说明）；

-评审项使用的计划、标准及指南；

-与评审项有关的评审差异表、软件问题报告单，修

改报告单；

-软件质量保证人员的报告。

编号

评审差异表

日期

提出人

1文档标题:

2文档代号:

3文档发布/版木号:

4问题位置:

5问题说明:

6建议解决方法:

7作者答复:

8评审决定:

结束/更改/措施/拒收（划出选择）

活动=准备+评审会议

■准备

■负责人起草日程表，并将其与目的、被评审项、规

格、计划和指南一起散发给评审组。

-评审组成员对评审项进行检查。通过完成评审差异

表来对在检查中发现的每个问题进行记录。将评审

差异表退还给秘书。

-负责人将每张评审差异表按主要的、次要的或编辑

上的进行分类

-由秘书按被评审项中偏差的位置对评审差异表进行

排序。

活动=准备+评审会议

■评审会议

■1）开始；

■2）展示被评审项；

■3）评审差异表的分类；

■4）对主要的评审差异表的评审;

■5）对其它的评审差异表的评审;

■6）结论。

评审结论

■典型的结论是：

-授权进行下一步的工作，条件是完成更改工作和采

取措施；

.授权进行限定部分的工作；

-执行决定的附加工作。

■如未能对达成一致意见和得出结论，则：

-在评审报告中记录非主流的不同观点；

-由一名或多名成员在会议外寻找解决方法；

-把问题移交给上一级管理部门。

输出

-报告摘要；

-成员名单；

■被评审项的确定；

-按照分类编组的带处置标志的评审差异表、软件问题

报告单、软件修改报告单等；

■措施清单，以及各措施的人员责任和预期完成日期；

■结论。

■输出可采取会议记录的形式，或采取独立报告的形式。

.报告应足够详细，以便于管理部门判断发生了什么事。

■如果在评审期间难以达成一致意见，可建议评审组成员对输

出不签字。

软件审查

■软件审查可用于编码前发现详细设计中的缺陷，在测

试前发现代码的缺陷。软件审查也可以用于验证测试

设计、测试用例和测试过程。

■软件审查是有效的。通过审查，可以查出开发过程所

带给项目的全部缺陷的50%。

-软件审查是经济的，因为它可以大大减少缺陷的数量

和降低消除缺陷的费用。在缺陷产生后尽可能短的时

间内发现缺陷可以：

-使软件开发者增强查找缺陷产生原因的意识，以便

减少类似缺陷再出现的可能性；

-使查找缺陷的工作量减少，因为不需要在许多可能

的组成部分以外去诊断哪个组成部分有缺陷。

审查的目的

-软件审查的目的是查出文档或代码中的

缺陷。

软件审查的组织

■主任：主任领导审查并主持审查会。主任应具备完成这项工作的

技能，而不必要精通所审查的项目。他（她）必须是公平的、客

观的。鉴于这些原因，主任常常从与项目无关的职员中选出。最

好他们受过有关审查过程的培训。

■秘书：秘书负责记录审查会的记录，特别是记录发现的每个缺陷

的细节。

-阅读员：阅读者引导审查组遍历被审查项。

■审查员：审查员在审查时确定和描述被审查项的缺陷。选择的审

查员应能代表各种观点（如：设计员、编码员和测试员）。

-作者：作者是被审查项的编制人员。作者主要回答关于被审查项

的问题，并负责所有的修改。

■一个人可担任上述一种或多种角色。没有人既担任作者又担任其

它由色。

软件审查的输入

■被审查项（如源代码，或其它文档）

■被审查项应符合的规格（如详细设计）

■审查检查单

■应用于被审查项的标准和指南

■审查报告表

■从上一次审查中获得的缺陷表

活动=综述、准备、审查会、修改、补充活动

-综述是对被审查项进行介绍。

■之后审查员对被审查项进行熟悉，作好

参加审查会的准备。

■然后，审查员在审查会上检查被审查项、

确定缺陷并决定是否对缺陷进行纠正。

■修改工作包括对故障的修复。

■补充活动是指检查在审查会上作出的所

有决定是否都得到了执行。

审查的时间和速度

-代码审查的初始参考值：

■准备：每小时125行非注释源代码；

■审查会：每小时90行非注释源代码。

■对伪码或PDL的审查，上述数字应加倍。

■审查会不应超过两个小时。

软件审查活动

■综述：综述的目的是向审查组介绍被审

查项。主任介绍要审查的范围，然后详

细介绍设计的具体的范围，再将输入分

配给参加者。

软件审查活动

■准备：主任、阅读员和审查员对输入进行熟悉。

通过阅读下列资料来做好代码审查的准备：

-要审查的代码设计规范；

■编码标准；

-含以前审查发现的普遍编码错误的代码审查检查单;

-被审查的代码。

■被审查项的缺陷要在评审差异表中记录，并在

审查过程中合适的时候进行宣布。准备工作应

单独进行，而不要在会议上进行。

软件审查活动■审查会

-主任检查成员的准备工作，报告和记录各成员所花费的时间。

■由阅读员引导会议遍历被评审项。对文件阅读员可总结某些部分

的内容，并一行一行地读完所有内容。对代码阅读员应覆盖每个

逻辑块，至少详细讨论每个分支一次。审查员利用检查单来发现

普遍错误。

■秘书对阅读中发现的缺陷立即进行记录。包括下列的内容：

.严重性、技术分类、位置、描述

■不记录确定的任何解决措施。审查组应避免寻找解决措施，而应

集中精力发现缺陷。

■在审查会结束前，审查组应作出下列中的一种决定：

.当修改完成之后（如果有）接收该审查项；

■当修改完成之后由主任负责接收该审查项；

-重新审查整个被审查项（如果5%以上需要修改）。

■秘书应在之前起草会议纪要，以便修改工作能及时地进行。

软件审查—活动

■修改

.审查之后，软件作者纠正缺陷清单中列出的缺陷。

■补充活动

-修改之后，补充活动验证所有的缺陷都得到了正确

的纠正，而无其它缺陷被引入。

■主任负责补充活动。

-其它补充活动是：

-依据不同错误类型变化的频率修改检查单；

-分析缺陷统计资料，也许会导致对软件验证与确认工作的