评审技术在高质量软件开发中的应用
评审技术在高质量软件开发中的应用
郭华
摘要
软件质量和开发进度一直是软件开发成功关键的因素，而在实际工作中只有少量项目能按计划完成，进度要求往往迫使开发组无法保证软件质量，最终许多项目因为质量问题无法投入使用。软件评审作为一种软件产品验证的活动，能够及早地从软件产品中识别并消除缺陷，从而减少后期的返工，加快开发进度，提高产品质量。作为一种十分有效值得推广的评审方法，在软件过程改进中起到了非常大的作用，同时软件评审也是CMM等级3的关键过程域。
本文描述了正式和非正式的多种软件评审技术，包括临时评审、桌查、轮查、结队编程、走查、小组评审和审查等，并系统地介绍了最正式、最严格、最有效的软件评审——审查的整个过程，包括制定评审计划、指定评审角色、做评审准备、召开评审会议和验证分析等过程。高质量要求的软件，如电信软件、银行证券软件等，它们对可用性要求非常，因此对软件质量的要求非常严格。作者通过将评审技术应用在高质量软件开发过程中，在实际开发过程中确定了评审的质量标准和准入、准出条件，并针对数据采集、分析做了严格的控管，建立了质量可预测的软件开发过程体系，为有效地项目评估、质量保证和项目管理提供了可靠依据，从而保证了软件项目的成功。
关键词：软件评审、审查、开发过程、软件、质量、定量
一、软件评审
1.1 缺陷的产生
缺陷指软件工作产品中的一种情况，它将导致软件产生不令人满意或非预期的结果。在开发过程中缺陷随时可能产生，问题在于什么时候发现它，并为此产生多少纠正成本。。根据一些企业返工度量的报导，缺陷返工率可达到整个开发工作量的40%~60%。
缺陷在软件开发的任何阶段都可能会被引入。项目质量管理过程包含了许多可以识别缺陷、消除缺陷的过程。“识别缺陷”和“消除缺陷”本来是两个不同的过程，但在这里为了简便统一用“消除”来代表它们。潜在的缺陷越大，用来消除它所花的费用越高。因此成熟的软件开发过程在每一个可能会引入潜在缺陷的阶段完成之后都会开展质量控制活动。这些为了消除缺陷的活动包括：需求评审、设计评审、代码走查、单元测试、集成测试、系统测试以及验收测试等。一个缺陷如果保持没有被发现的时间越长，则以后纠正此缺陷的花费越大。
缺陷越早发现、越早解决，则所花费的成本越低。因此我们应该尽量在前期发现、识别并解决缺陷问题。
2、缺陷的识别
根据一些企业返工度量的报导，缺陷返工率可达到整个开发工作量的40%~60%。在软件开发过程中，软件评审和软件测试是保证软件质量的两种主要手段和方法。
测试可以识别可执行系统中的缺陷，而评审不仅可识别可执行系统中的缺陷，且能识别不能被执行的文档或人为产物。
测试和评审的比较
1）表现形式
测试的表现形式有：单元测试、集成测试、系统测试、用户验收测试
评审的表现形式有：审查、小组评审、走查、结对编程、同级桌查、轮查、临时评审
2）工作对象
测试的工作对象为：可执行系统（指编译后可运行的程序）
评审的工作对象为：需求规格说明书、架构（概要）设计文档、详细设计文档、项目计划、项目过程文档、源代码、系统界面、测试计划、测试用例和数据、用户手册
3）识别缺陷的阶段
测试识别缺陷的阶段：测试阶段（编码完成后）
评审识别缺陷的阶段：需求阶段、设计阶段、编码阶段、测试阶段
4）识别缺陷的成效
测试的成效：最多识别软件所有缺陷中30-35%的缺陷
评审的成效：最多识别软件所有缺陷中70-75%的缺陷
5）识别缺陷的成本
测试的成本：识别一个重要缺陷平均花费15-25小时
评审的成本：需求阶段识别一个重要缺陷平均花费2-3小时；
设计阶段识别一个重要缺陷平均花费3-4小时；
代码评审阶段识别一个重要缺陷3-5小时；
测试计划评审识别一个重要缺陷3-5小时
6）解决缺陷的成本
测试的成本：消除一个重要缺陷平均花费30-80小时（包括识别缺陷时间）
在开发后期才能识别缺陷，成本较高
评审的成本：需求及设计阶段消除一个重要缺陷5-10小时；
代码评审阶段消除一个重要缺陷5-15小时
更倾向于在开发前期识别缺陷，成本较低
7）投入回报比较
（1）航天飞机搭乘项目：在设计或代码评审时消除一个缺陷的成本为1美元，在系统测试时为13美元，交付使用后为92美元（Paulk etal,1995）。即13~92 : 1
（2）电信公司审查发现和纠正一个缺陷的平均费用为200美元，客户验收测试发现的缺陷平均花费4200美元(Boehm and Basili 2001)。即21 : 1
某研究表明，客户使用过程中发现、纠正与需求相关的缺陷的费用是比需求开发阶段发现和纠正同样缺陷的费用的68~110倍(Boehm 1981;Grady 1999)。即 68~110 : 1
（3）印度Infosys公司经验表明：在代码审查上多花费一天，这个产品就有期望在后期修改缺陷节省3-6天。即 3~6 : 1
3、软件评审概念
1.3.1 定义
软件评审，是指在软件开发过程中，由参与评审的人员对软件开发文档或代码进行评审或检查，帮助查找缺陷和改进。
软件评审的工作包括：
1）检验产品是否满足以前的规范，如需求或设计文档；
2）识别产品相对于标准的偏差；
3）向作者提出改进建议；
4）促进技术交流和学习。
软件评审涉及评审的组织机构、管理、准则、类别、内容、文件和要求等。一般要求在软件研制阶段的里程碑点进行软件评审。评审的主要类别有：软件定义评审、软件需求评审、概要设计评审、详细设计评审、软件实现评审和软件验收评审等。
1.3.2 软件评审的分类
自从25年前，IBM的Michael Fagan提出软件审查技术以来，许多组织使用这项技术得到了非常卓有成效的结果。这些组织包括IBM、HP、Motorola、Raytheon、Bull HN等。经过几十年的发展，软件评审技术和多种项目管理理论相结合，已经发展成一个庞大的体系。
就总体而言，软件评审主要分为六类：审查、小组评审、走查、结队编程、同级桌查和轮查、临时评审。
其中审查是最系统化、最严密的评审技术，严格规定了每个阶段的角色及各自职责，在质量要求非常高的软件开发项目中得到了较广泛的应用。
在判断采用哪种评审方法时，需考虑以下风险因素：
1）使用了新技术，方法，工具的组件
2）关键的架构性的组件
3）难以理解，却又必须准确和优化的复杂逻辑或算法
4）具有危险失败模式的组件，而且是任务、可靠性、安全性关键的
5）具有多个异常条件或失败模式的组件
6）不易测试的异常处理代码
7）打算复用的组件
8）将作为其他组件的模型或模板的组件
9）影响产品多个部分的组件
10）复杂的用户界面
11）由缺乏经验的开发者创建的组件
12）具有高度圈复杂性的代码模块
13）以往具有很多缺陷或变更的模块
1.3.4 审查的角色、职责及步骤
审查的角色主要分为评审组长、作者、读者、评审人员、记录者和验证者。部分专家认为审查的角色还有：评审协调人。根据管理的原则，评审协调人的角色应归入评审组长，其职责由评审组长负责。
审查的角色及职责
1）评审组长
（1）计划、安排和组织评审活动；
（2）和作者一起选择评审人，并分配角色；
（3）主持总体会议和评审会议；
（4）提交需评审的产品给每一个评审人；
（5）检查评审会议的准备是否充分，从而决定是否召开评审会议；
（6）领导小组确定评审效果；
（7）提交《评审总结报告》；
（8）维护每次评审的评审记录及来自评审总结报告中的数据；
（9）根据评审数据形成报告，提交给管理层、过程改进组及评审过程的拥有者。
2）作者
（1）作为被评审产品的作者或维护者，提交工作产品；
（2）协助评审组长选择评审人，并分配角色；
（3）陈述评审目标；
（4）初步讲解产品；
（5）返工；
（6）向评审组长报告返工时间和缺陷数；
3）读者
将工作产品在评审会议上用自己的语言进行解说，测试工作产品的可理解性，暴露产品的二义性、隐含假设等各种缺陷；
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
郭华
摘要
软件质量和开发进度一直是软件开发成功关键的因素，而在实际工作中只有少量项目能按计划完成，进度要求往往迫使开发组无法保证软件质量，最终许多项目因为质量问题无法投入使用。软件评审作为一种软件产品验证的活动，能够及早地从软件产品中识别并消除缺陷，从而减少后期的返工，加快开发进度，提高产品质量。作为一种十分有效值得推广的评审方法，在软件过程改进中起到了非常大的作用，同时软件评审也是CMM等级3的关键过程域。
本文描述了正式和非正式的多种软件评审技术，包括临时评审、桌查、轮查、结队编程、走查、小组评审和审查等，并系统地介绍了最正式、最严格、最有效的软件评审——审查的整个过程，包括制定评审计划、指定评审角色、做评审准备、召开评审会议和验证分析等过程。高质量要求的软件，如电信软件、银行证券软件等，它们对可用性要求非常，因此对软件质量的要求非常严格。作者通过将评审技术应用在高质量软件开发过程中，在实际开发过程中确定了评审的质量标准和准入、准出条件，并针对数据采集、分析做了严格的控管，建立了质量可预测的软件开发过程体系，为有效地项目评估、质量保证和项目管理提供了可靠依据，从而保证了软件项目的成功。
关键词：软件评审、审查、开发过程、软件、质量、定量
一、软件评审
1.1 缺陷的产生
缺陷指软件工作产品中的一种情况，它将导致软件产生不令人满意或非预期的结果。在开发过程中缺陷随时可能产生，问题在于什么时候发现它，并为此产生多少纠正成本。。根据一些企业返工度量的报导，缺陷返工率可达到整个开发工作量的40%~60%。
缺陷在软件开发的任何阶段都可能会被引入。项目质量管理过程包含了许多可以识别缺陷、消除缺陷的过程。“识别缺陷”和“消除缺陷”本来是两个不同的过程，但在这里为了简便统一用“消除”来代表它们。潜在的缺陷越大，用来消除它所花的费用越高。因此成熟的软件开发过程在每一个可能会引入潜在缺陷的阶段完成之后都会开展质量控制活动。这些为了消除缺陷的活动包括：需求评审、设计评审、代码走查、单元测试、集成测试、系统测试以及验收测试等。一个缺陷如果保持没有被发现的时间越长，则以后纠正此缺陷的花费越大。
缺陷越早发现、越早解决，则所花费的成本越低。因此我们应该尽量在前期发现、识别并解决缺陷问题。
2、缺陷的识别
根据一些企业返工度量的报导，缺陷返工率可达到整个开发工作量的40%~60%。在软件开发过程中，软件评审和软件测试是保证软件质量的两种主要手段和方法。
测试可以识别可执行系统中的缺陷，而评审不仅可识别可执行系统中的缺陷，且能识别不能被执行的文档或人为产物。
测试和评审的比较
1）表现形式
测试的表现形式有：单元测试、集成测试、系统测试、用户验收测试
评审的表现形式有：审查、小组评审、走查、结对编程、同级桌查、轮查、临时评审
2）工作对象
测试的工作对象为：可执行系统（指编译后可运行的程序）
评审的工作对象为：需求规格说明书、架构（概要）设计文档、详细设计文档、项目计划、项目过程文档、源代码、系统界面、测试计划、测试用例和数据、用户手册
3）识别缺陷的阶段
测试识别缺陷的阶段：测试阶段（编码完成后）
评审识别缺陷的阶段：需求阶段、设计阶段、编码阶段、测试阶段
4）识别缺陷的成效
测试的成效：最多识别软件所有缺陷中30-35%的缺陷
评审的成效：最多识别软件所有缺陷中70-75%的缺陷
5）识别缺陷的成本
测试的成本：识别一个重要缺陷平均花费15-25小时
评审的成本：需求阶段识别一个重要缺陷平均花费2-3小时；
设计阶段识别一个重要缺陷平均花费3-4小时；
代码评审阶段识别一个重要缺陷3-5小时；
测试计划评审识别一个重要缺陷3-5小时
6）解决缺陷的成本
测试的成本：消除一个重要缺陷平均花费30-80小时（包括识别缺陷时间）
在开发后期才能识别缺陷，成本较高
评审的成本：需求及设计阶段消除一个重要缺陷5-10小时；
代码评审阶段消除一个重要缺陷5-15小时
更倾向于在开发前期识别缺陷，成本较低
7）投入回报比较
（1）航天飞机搭乘项目：在设计或代码评审时消除一个缺陷的成本为1美元，在系统测试时为13美元，交付使用后为92美元（Paulk etal,1995）。即13~92 : 1
（2）电信公司审查发现和纠正一个缺陷的平均费用为200美元，客户验收测试发现的缺陷平均花费4200美元(Boehm and Basili 2001)。即21 : 1
某研究表明，客户使用过程中发现、纠正与需求相关的缺陷的费用是比需求开发阶段发现和纠正同样缺陷的费用的68~110倍(Boehm 1981;Grady 1999)。即 68~110 : 1
（3）印度Infosys公司经验表明：在代码审查上多花费一天，这个产品就有期望在后期修改缺陷节省3-6天。即 3~6 : 1
3、软件评审概念
1.3.1 定义
软件评审，是指在软件开发过程中，由参与评审的人员对软件开发文档或代码进行评审或检查，帮助查找缺陷和改进。
软件评审的工作包括：
1）检验产品是否满足以前的规范，如需求或设计文档；
2）识别产品相对于标准的偏差；
3）向作者提出改进建议；
4）促进技术交流和学习。
软件评审涉及评审的组织机构、管理、准则、类别、内容、文件和要求等。一般要求在软件研制阶段的里程碑点进行软件评审。评审的主要类别有：软件定义评审、软件需求评审、概要设计评审、详细设计评审、软件实现评审和软件验收评审等。
1.3.2 软件评审的分类
自从25年前，IBM的Michael Fagan提出软件审查技术以来，许多组织使用这项技术得到了非常卓有成效的结果。这些组织包括IBM、HP、Motorola、Raytheon、Bull HN等。经过几十年的发展，软件评审技术和多种项目管理理论相结合，已经发展成一个庞大的体系。
就总体而言，软件评审主要分为六类：审查、小组评审、走查、结队编程、同级桌查和轮查、临时评审。
其中审查是最系统化、最严密的评审技术，严格规定了每个阶段的角色及各自职责，在质量要求非常高的软件开发项目中得到了较广泛的应用。
在判断采用哪种评审方法时，需考虑以下风险因素：
1）使用了新技术，方法，工具的组件
2）关键的架构性的组件
3）难以理解，却又必须准确和优化的复杂逻辑或算法
4）具有危险失败模式的组件，而且是任务、可靠性、安全性关键的
5）具有多个异常条件或失败模式的组件
6）不易测试的异常处理代码
7）打算复用的组件
8）将作为其他组件的模型或模板的组件
9）影响产品多个部分的组件
10）复杂的用户界面
11）由缺乏经验的开发者创建的组件
12）具有高度圈复杂性的代码模块
13）以往具有很多缺陷或变更的模块
1.3.4 审查的角色、职责及步骤
审查的角色主要分为评审组长、作者、读者、评审人员、记录者和验证者。部分专家认为审查的角色还有：评审协调人。根据管理的原则，评审协调人的角色应归入评审组长，其职责由评审组长负责。
审查的角色及职责
1）评审组长
（1）计划、安排和组织评审活动；
（2）和作者一起选择评审人，并分配角色；
（3）主持总体会议和评审会议；
（4）提交需评审的产品给每一个评审人；
（5）检查评审会议的准备是否充分，从而决定是否召开评审会议；
（6）领导小组确定评审效果；
（7）提交《评审总结报告》；
（8）维护每次评审的评审记录及来自评审总结报告中的数据；
（9）根据评审数据形成报告，提交给管理层、过程改进组及评审过程的拥有者。
2）作者
（1）作为被评审产品的作者或维护者，提交工作产品；
（2）协助评审组长选择评审人，并分配角色；
（3）陈述评审目标；
（4）初步讲解产品；
（5）返工；
（6）向评审组长报告返工时间和缺陷数；
3）读者
将工作产品在评审会议上用自己的语言进行解说，测试工作产品的可理解性，暴露产品的二义性、隐含假设等各种缺陷；
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