评审技术在高质量软件开发中的应用分析

评审技术在高质量软件开发中的应用分析

摘要

软件质量和开发进度一直是软件开发成功关键的因素，而在实际工作 中只有少量项目能按计划完成，进度要求往往迫使开发组无法保证软件质量，最终许多项目因为质量问题无法投入使用。软件评审作为一种软件产品验证的活动，能 够及早地从软件产品中识别并消除缺陷，从而减少后期的返工，加快开发进度，提高产品质量。作为一种十分有效值得推广的评审方法，在软件过程改进中起到了非 常大的作用，同时软件评审也是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）《系统测试计划》的评审

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

本文来源：https://www.bwwdw.com/article/j415.html