将工作产品在评审会议上用自己的语言进行解说，测试工作产品的可理解性，暴露产品的二义性、隐含假设等各种缺陷；

4）评审人员

（1）在评审会议之前检查工作产品，发现其缺陷，为参加评审会议做准备；

（2）记录准备时间；

（3）参加评审，识别缺陷，提出问题，给出改进建议。

5）记录者

记录评审会议中提出的问题并分类。

6）验证者

进行跟踪，确认返工工作被正确执行。

审查的主要步骤有：

1）评审计划；

2）总体会议；

3）评审准备；

4）评审会议；

5）修改、验证。

二、软件开发模型

2.1 软件生命周期

软件生命周期指软件的产生直到报废的生命周期，周期内有系统定义、需求分析、系统设计、编码实现、系统/验收测试、运行维护到废弃等阶段。

组织软件开发过程的规则，可以称为软件生命周期模型。一个定义良好的软件生命周期模型，可以很好的指导我们的开发工作，使漫长的开发工作易于控制。事实上，我们可以任意定义自己喜欢的软件生命周期模型。但是，如果生命周期模型定义不合理，却会制约我们的开发过程。软件开发人员在长期开发过程已经总结出了几种常用的软件生命周期模型，我们可以根据项目的特点来选择一个合适的模型，然后在此基础上再加以裁减。

这些生命周期模型是：

1）瀑布模型，

2）快速原型模型，

3）渐增模型，

4）演进模型。

其中瀑布模型是所有生命周期模型的核心和基础，其他模型都是基于瀑布模型发展和衍化而来。瀑布模型分为六个阶段：系统定义、需求分析、系统设计、编码实现、系统验收测试、运行维护。

在瀑布模型中每个阶段都要有定义、工作、审查、形成文档以供交流或备查，以提高软件的质量。

2.2 项目开发V模型

在瀑布模型的基础上，衍生出了强调测试活动的V模型。它把瀑布模型的测试阶段进行细分，并于前面的阶段进行对应。细分出来的这些阶段分别为：单元测试阶段、集成测试阶段和系统测试阶段。

在V模型中，我们可以知道：

1）在需求分析阶段，《系统需求规格说明书》确认后，编写《系统测试计划》，准备系统测试用例、数据，对需求进行验证；对应的系统测试阶段，执行系统测试计划；

2）在概要设计阶段，《概要设计说明书》确认后，编写《集成测试计划》，准备集成测试用例、数据等，对概要设计进行验证；然后在对应的集成测试阶段，执行集成测试计划；

3）在详细设计阶段，《详细设计说明书》确认后，编写《单元测试计划》，准备单元测试用例、数据等，对详细设计进行验证，然后在对应的单元测试阶段，执行单元测试计划。

三、评审在高质量软件开发的实际应用

3.1 高质量软件开发项目介绍

高质量软件，如电信软件、金融证券类软件等，有较严格的要求：可用性要求非常高，并且不会因为系统维护和扩展而带来运营中断；支持使用现有管理工具和标准进行远程管理；能够提供更出色的性能以及运营在高可用性集群上的能力，减少任何单点的软硬件失效现象。五个九（99.999%）意味着一个系统的宕机时间一年不超过5分26秒。因此高质量软件项目是一种对可用性、可靠性、稳定性要求非常高的软件项目，要求软件能够每周7*24工作。

因此高质量软件开发一般采用严格的软件开发过程，明确定义每个阶段的质量目标和要求，严格项目软件开发过程控制。

我们在多个高质量软件开发项目中成功地采用了评审技术，并发挥了巨大的作用。从这些项目的实际开发过程中，我们针对于规模从30人月??300人月，代码行数从5万行??30万行的运营支撑系统项目制定了项目评审流程和相关要求。

3.2 软件过程定义

软件过程主要分为项目立项阶段、需求分析阶段、设计阶段、编码实现阶段、测试阶段（包括集成测试、系统测试和用户验收测试）、实施阶段和维护阶段，项目管理工作横贯于所有的阶段。详细流程见流程图。

在软件过程中，我们定义了以下角色：

1）客户

2）销售人员

3）项目经理

4）系统分析员

5）系统架构师

6）开发工程师

7）质量工程师

8）技术支持人员

在规划质量体系时，我们参考PMBOK对项目质量管理的要求，将项目质量管理过程设计为三个阶段：

1）质量规划??确定质量活动的流程和标准，如软件过程定义，质量达标定义等；

2）实施质量保证??编写相应的测试计划、执行测试和评审活动；

3）实施质量控制??监控质量保证活动的结果，判断是否达标，如不达标，则采取相应的风险防范措施。

3.3 软件评审过程及标准定义

我们在整体软件过程中明确定义了需要软件评审的过程及实施的方法。

3.3.1 采用审查的过程

采用严格系统的评审方法??审查的软件过程有：

1）《软件需求规格说明书》的评审

2）《概要设计说明书》的评审

3）《详细设计说明书》的评审

4）代码评审

5）《单元测试计划》的评审

6）《集成测试计划》的评审

7）《系统测试计划》的评审

对于文档评审以文档页数为基数，要求每页发现的缺陷数有一个目标值，并规定了上下限的范围。对于代码评审以代码行数为基数，要求每千行代码发现的缺陷数有一个目标值，并规定了上下限的范围。这个审查的缺陷数标准如下表。

软件过程审查的质量目标

质量目标 目标 下限 上限

SRS文档Review缺陷发现密度（个/页）： 0.80 0.50 1.10

HLD文档Review缺陷发现密度（个/页）： 0.70 0.50 0.90

LLD文档Review缺陷发现密度（个/页）： 0.43 0.22 0.64

代码检视缺陷发现密度（个/KLOC）： 10.62 7.43 13.81

单元测试计划Review缺陷发现密度（个/页）： 0.43 0.22 0.64

集成测试计划Review缺陷发现密度（个/页）： 0.70 0.50 0.90

系统测试计划Review缺陷发现密度（个/页）： 0.80 0.50 1.10

如果发现的缺陷密度低于或高于质量目标范围，则我们需要分析其原因，然后根据原因进行返工或相应处理流程。这要和实际情况相结合，具体情况具体分析：如某个开发工程师的水平和素质非常高，他的代码一般很少出错，这样他的代码检视缺陷密度低是属于正常的；而另外一个工程师水平一般，但发现的缺陷密度也很低，但原因是属于检视的过程不严格，大家没有时间来进行严格的评审，则此时需要重新进行检视。

3.3.2 采用小组评审的过程

采用小组评审的软件过程主要包括对客户需求的评审、项目计划的评审和维护计划的评审。

对客户需求的评审参加人员有项目经理、系统分析员、系统架构师、质量部主管等。

项目计划的评审主要由项目经理、系统分析员、系统架构师、质量部主管和部门经理等参加，对人力资源、进度和质量管控等进行评审。

维护计划由项目经理、技术支持人员、质量部主管和客户服务人员参加，对人力资源、管控流程等进行评审。

3.3.3 采用走查评审的过程

需求分析过程中，系统分析员、系统架构师相互之间的走查；

设计过程中，系统分析员、系统架构师相互之间的走查；

在进入维护阶段时，作者需和维护人员进行走查，让维护人员能够维护作者的工作产品。

3.3.4 采用桌查的过程

采用桌查的过程主要集中在代码提交阶段，主要是经验丰富的开发人员对提交的代码进行检查，合格的产品才会提交到CVS上面。

具体实施方法为：开发经验较少（8年以下开发经验）的开发人员在提交代码时，请经验丰富（10年以上开发经验）的开发人员进行桌查，没有明显问题后才允许提交；经验丰富的开发人员提交代码时也需另一名经验丰富的开发人员桌查后方可提交。

3.3.5 采用临时评审的过程

代码编写阶段开发工程师之间的临时评审；

其他开发阶段，开发人员相互之间的临时评审。

3.3.6 采用结队编程的过程

针对于需求不明确、采用迭代增量开发过程的小规模项目，采用极限编程时，建议采用结队编程，但一般不做强制规定。

我们实际采用极限编程思想进行了两个项目（一个内部项目和一个外部项目）的开发，实际上取得了非常好的效果。开发人员实际产出值达到了5000行代码/人月以上。当然这些项目不太大，同时文档编写比较简单。

3.4 审查流程定义

我们规定了审查流程的定义，其他评审技术只是采用了其中的流程和管理思想。

3.5 软件评审效果分析

我们强化了软件评审技术后，在实际过程中取得了非常好的效果。以一个网络流量分析的项目为实例，在第一期没有严格实施软件评审技术，而第二期严格实施了软件评审技术，其中审查数据如下表。

评审过程数据及质量分析实例

文件/模块 计算基数(页数/KLOC) 致命 严重 一般 提示 总和 标准(目标/下限-上限) 比例 达标与否

SRS 42 1 1 29 10 31 0.8 / 0.5~1.1 0.738 OK

STP 58 22 15 12 37 0.8 / 0.5~1.1 0.638 OK

HLD 34 4 15 29 19 0.7 / 0.5~0.9 0.559 OK

LLD 205 11 59 29 70 0.43 / 0.22~0.64 0.341 OK

UTP 217 15 80 15 95 0.43 / 0.22~0.64 0.438 OK

CodeReview 50 7 372 151 379 10.62 / 7.43~13.8 7.580 OK

SITP 50 6 98 112 30 216 5.65/3.86~8.44 4.320 OK

产生的效果为：

1）产出量：单位开发人员的产出量由950行代码/人月（全流程）增长到1320行代码/人月（全流程），增长量为38.9%。关键原因在于大在减少了项目后期返工的工作量。考虑由于项目熟悉和学习曲线等的原因，实际的产出增长量应该超过20%。

2）产品质量（遗留缺陷密度）：我们从软件系统的遗留缺陷率来分析系统的质量情况。在半年的维护时间内，第一期代码行为4万行，严重缺陷有5个，一般缺陷有32个，严重缺陷发现密度为0.125个缺陷/千行代码，总遗留缺陷发现密度为0.925个缺陷/千行代码；第二期代码行数为5万行，严重缺陷有1个（属于客户需求问题引发的设计缺陷），一般缺陷有15个，严重缺陷发现密度为0.02个缺陷/千行代码，总遗留缺陷发现密度为0.32个缺陷/千行代码。因此严重缺陷发现密度改进了84%，一般缺陷发现密度改进了65.4%。

3）客户满意度：第一期客户严重不满意，称我们在做玩具，满意度只有22%；第二期客户满意度大幅上升，称我们是专业人士，非常敬业，为他们所钦佩，满意度达到了91%。因此满意度提高了314%。

主要的是，我们采用了软件评审技术，规范了软件开发过程的标准，并积累了实际的软件开发过程数据，为后面的项目管理和过程控制提供了宝贵的软件过程财富。

四、总结和展望

在实际工作中，我们以前掌握的过程数据不多，基本上一步一步摸索着前进，对于过程数据也在不断的收集及整理中。对于评审技术而言，其中重要的一点是采用多种实际工具和手段，如针对每个过程进行评审的《缺陷检查表》等，我们也在逐步地完善这套体系和过程数据，从而为我们的过程改进不断提供支持。

参考文献：

[1] Karl Wiegers. Seven Deadly Sins of Software Reviews. Software Development. 1997.3

[2] Steve McConnell. Software Quality at Top Speed. Software Development. 1996.8

[3] 沈备军，宿为民译. 软件同级评审. Karl E.Wiegers. Peer Reviews in Software A Practical Guide. 机械工业出版社. 2003.4

[4] Watts S. Humphrey. Introduction to the Personal Software Process. 人民邮电出版社. 2002.10

[5] 卢有杰，王勇译. 项目管理知识体系指南（第三版）. 美国项目管理协会. A Guide to the Project Management Body of Knowledge， Third Edition(PMBOK Guide). 电子工业出版社. 2005.1

[6] 胡春哲，张洁等译. CMM实践应用??Infosys公司的软件项目执行过程. Pearson Education. CMM in Practice: Processes for Executing Software Projects at Infosys. 电子工业出版社. 2002.8.1