软件评审的具体分析

杨浩

（浙江师范大学 数理与信息工程学院 浙江 金华）

摘要

软件评审的重要目的就是在评审重发现产品的缺陷，因此在评审上的投入可以减少大量的后期反工，通过评审，还可以将问题记录下来，使得问题具有可追溯性【1】。做好软件评审很重要。具体介绍软件评审的整个流程，对每个环节进行具体分析，促进管理规范化，评审正确化。

关键字：评审定义，评审步骤，评审种类，评审误区。

引言

软件评审直接关系到软件的命运和前途，好的软件评审能得到好的软件质量的保证。要做好软件评审好考虑多反面的因素，如何把用户，开发人员，软件功能和市场紧密的联系在一起将是评审是否成功的关键，因此我们必须适当的细化软件评审，熟悉评审的具体环节，规范评审，把评审的每一个环节做好，保证软件评审的正常进行，进而正确的指导软件开发。

背景

软件规模的扩大及复杂度的提高导致了20 世纪60年代末爆发的软件危机。所谓“软件危机”主要指在计算机软件的开发和维护过程中所遇到的一系列严重问题，如成本增加、进度难以控制、质量差、维护困难等。为了克服软件危机，人们开始探索用工程的方法来进行软件生产的可能性，软件工程应运而生【2】。在软件工程中，评审和测试是提高软件质量的非常重要的两个过程。在软件开发过程中，软件评审和软件测试是保证软件质量的两种主要方法和手段，测试主要在软件开发的后期进行，而评审主要在软件开发的前期进行。

评审的具体分析

一.软件评审的定义

软件评审，是指在软件开发过程中，由参与评审的人员对软件开发文档或代码进行评审或检查，帮助查找缺陷和改进。 软件评审的工作包括：

1. 检验产品是否满足以前的规范，如需求或设计文档； 2. 识别产品相对于标准的偏差； 3. 向作者提出改进建议； 4. 促进技术交流和学习。

评审的主要类别有：软件定义评审、软件需求评审、概要设计评审、详细设计评审、软件实现评审和软件验收评审等【3】。

二.设计质量的评审内容

(1) 评价软件的规格说明是否合乎用户的要求,即总体设计思想和设计方针是否明确;需求规格说明是否得到了用户或单位上级机关的批准;需求规格说明与软件的概要设计规格 说明是否一致等。

(2) 评审可靠性,即是否能避免输入异常（错误或超载等）、硬件失效及软件失效所产生的失效，一旦发生应能及时采取代替或恢复手段 。

(3) 评审保密措施实现情况,即是否提供对使用系统资格进行检查;对特定数据的使用资格、特殊功能的使用资格进行检查，在查出有违反使用资格情况后，能否向系统管理人员报告有关信息；是否提供对系统内重要数据加密的功能等。

(4) 评审操作特性实施情况，即操作命令和操作信息的恰当性，输入数据与输入控制语

句的恰当性；输出数据的恰当性；应答时间的恰当性等。 (5) 评审性能实现情况，即是否达到所规定性能的的目标值。 (6) 评审软件是否具有可修改性、可扩充性、可互换性和可移植性。 (7) 评审软件是否具有可测试性。 (8) 评审软件是否具有复用性。 三.程序质量的评审内容

程序质量评审通常它是从开发者的角度进行评审，直接与开发技术有关。它着眼于软件

本身的结构、与运行环境的接口、变更带来的影响而进行的评审活动。 1.软件的结构

功能结构。在软件的各种结构中，功能结构是用户唯一能见到的结构。 需要检查的项目有：

数据结构包括数据名和定义；构成该数据的数据项；数据与数据间的关系。

功能结构：包括功能名和定义；构成该功能的子功能；功能与子功能之间的关系。 数据结构和功能结构之间的对应关系：包括数据元素与功能元素之间的对应关系数据结

构与功能结构的一致性。 (2) 功能的通用性。 (3) 模块的层次。

( 4) 模块结构。

控制流结构：规定了处理模块与处理模块之间的流程关系。检查处理模块之间的转

移关系与控制转移形式（调用方式）。 数据流结构：规定了数据模块是如何被处理模块进行加工的流程关系。检查处理模

块与数据模块之间的对应关系；处理模块与数据模 块之间的存取关系，如建立、删除、查询、修改等。

模块结构与功能结构之间的对应关系：包括功能结构与控制流结构的对应关系；功能结构与数据流结构的对应关系；每个模块的定义 （包括功能、输入与输出数据）。 (5) 处理过程的结构。处理过程是最基本的加工逻辑过程。 2.与运行环境的接口 (1) 与硬件的接口。 (2) 与用户的接口。

随着软件运行环境的变更，软件的规格也在跟着不断地变更。运行环境变更时的影

响范围，需要从以下三个方面来分析： (1) 与运行环境的接口。

(2) 在每项设计工程规格内的影响。 (3) 在设计工程相互间的影响。

四.软件评审的步骤

软件评审是一个交互的过程，执行软件评估时要做到严谨，认真。在评审进行前，首先要做好计划，包括确定被评审的对象，期望达到的评审目标和计划选用的方法。然后 为评审计划的实施进行准备。包括选择参加评审合适的人员，协商和安排评审时间。接着召开会议进行集体评审，确定问题，然后跟踪这些问题。

软件评审步骤的具体分析：

序号 1 2 3 4 5 6 7 8 步骤 签定合同 费 制定项目总体计划 提供项目计划书初稿 评审准备辅导 了解性测试 与事务所讨论计划书 介绍评审要求、注意事项，提供法律文件，协调财务部与电脑与广州会计电算化协会沟通 对软件进行初步测试 部在评审中的工作 提供电脑及一名熟悉系统的人员配合 审核相关法律文件 对企业提供的法律文件进行审核，并提出专提供所需的法律文业意见 件 审核并行会计资料 审核并行三个月的凭证、帐簿、会计报表 提供并行的资料并复核 模拟测试 综合测试 设臵模拟测试的数据，复核输入的模拟数据设臵测试帐套，输复核输出结果 入模拟数据 拟订测试提纲，与企业讨论，根据测试提纲提供电脑及一名熟对ORACLE进行测试，对测试结果进行讨论，悉系统的人员配合 提出改进建议 9 改进结果复核 对系统改进结果进行复核 10 正式评审准备 指导企业准备正式评审的材料，与会计电算准备评审所需的资化协会、企业协商评审时间 料及场地，确定评审时间 组织评审会,派车接送会计电算化协会参加介绍企业及软件情评审的人员，评审中介绍前期工作,回答有关况，演示系统，回问题 答会计电算化协会人员的提问 12 出具评审报告 13 报告送审 14 颁发证书 五.软件评审的分类 自从有软件开发以来，人们就在不断地采用各种正式或非正式的软件评审技术来提高软件质量。经过几十年的发展，软件评审技术和多种项目管理理论相结合，已经发展成一个庞大的体系。就总体而言，软件评审主要类：管理评审，技术评审，审查，走查，审核【4】。

出具评审报告及验收表 在验收表封面盖章 评审报告及验收表送广州会计电算化协会审 批 领取证书后送达企业 按合同支付评审费用 事务所的工作 贵公司的工作 提供合同样本，提出完成项目所需时间，收商讨收费及时间 11 正式评审 对于不同的分类，内容存在很大差异，在软件评估中占据着举足轻重的作用。 软件评审类型的具体分析： 特征 管理评审 技术评审 目的 确保进度;推荐纠正措施;确保适当的资源分配 决策 管理组制定行动路线;在会议上或作为建议 策 更改验证 负责人验证选择的措施项;更负责人验证选择的措施项;更评价与规格说明和计划的符合性;确保更改的完整性 评审组要求管理部门或者技术领导对建议审查组选折预先定义的产品处臵方法;必须消除缺陷 负责人验证选择的措施项;更改验证留给其它项目控制人员 负责人验证选择的措施项;更改验证留给其它项目控制人员 推荐的小2人或以上 组的规模 小组的成管理人员、技术员 领导和同行 组长 材料规模 3人或以上 技术领导和同行 3～6人 满足文档中规定的人数的同行 经过培训的协调人 相当低 2～7人 1～5人 被审核组织的责任 审查 发现异常; 验证解决;验证产品质量 走查 发现常检查备选方法; 改进产品; 走查组同意由作者作出的更改 审核 独立评价与客观标准 和条例的符合性 被审核的组织、启动者、需方、顾客或用户 的结果作出决采取措施 改验证留给其 改验证留给其它项目控制人它项目控制人员 员 技术领导审核员、被审核和同行 组织、管理和技术人员 协调人或主任审核员 作者 相当低 中到高,取决于具体审核的目的 审核员收集并检查被审核组织提供的信息 通常是责任经通常是主任工理 中到高,取决于具体会议的目的 项目代表 程师 中到高,取决于会议的目的 开发组代表 陈诉者 领读者 作者 数据收集 按适用政策、标不是一个正式强烈建议 准或计划的要的项目要求。可求进行 能需要局部 进行 技术评审文档 异常清单、异常概述、审查文档 建议 不是一个正式的项目要求。可能需要局部 进行 正式审核报告; 观察、发现和缺陷 输出 管理评审文档 异常清单、措施项、后续正式的协无 调员培训 使用缺陷无 检查单 无 无 有 有 工作建议 无 有 无 有 管理人员 有 可选 无 无 有

六.软件评审的误区

误区一：评审参与者不了解评审过程

如果评审参与者不了解整个的评审过程，就会有一种自然的抗拒情绪，因为大家看不到做这件事情的效果，感觉到很迷茫，这样会严重的影响大家参与评审的积极性。 误区二：评审人员评论开发人员，而不是产品

评审的主要目的是发现产品中的问题，而不是根据产品来评价开发人员的水平。但是往往会出现把产品质量和开发人员水平联系起来的事情，于是评审变了“味”，变成了“批斗大会”，极大的打击了开发人员的自尊心，以至严重的影响了评审的效果。

误区三：评审没有被安排进入项目计划

参与评审需要投入大量的时间和精力，应该被安排进入项目计划中。但是现实的情况往往是，评审变成了“义务工”，参与评审的人员必须加班加点才能完成评审任务。如此一来，出现评审人员对评审对象不了解的情况也就不足为奇了。 误区四：评审会议变成了问题解决方案讨论会

评审会议主要的目的是发现问题，而不是解决问题，问题的解决是评审会议之后需要做的事情。但是，由于开发人员对技术的追求，评审会议往往变成了问题研讨会，大量的占用了评审会议的时间，导致大量评审内容被忽略，留下无数的隐患。 误区五：评审人员事先对评审材料没有足够了解

任何一份评审材料都是他人智慧和心血的结晶，需要花足够的时间去了解、熟悉和思考。只有这样，才能在评审会议上发现有价值的深层次问题。在很多的评审中，评审人员因为各种的原因，在评审会议之前对评审材料没有足够的了解，于是出现了评审会议变成了技术报告的怪现象。 误区六：评审人员关注于非实质性问题

经常会出现这样的问题，在评审中，评审人员过多的关注于一些非实质性的问题，比如文档的格式，措词，而不是产品的设计。出现这样的情况，可能的原因有：没有选择合适的人参加评审；评审人员对评审对象没有足够的了解，无法发现深层次的问题。

误区七：忽视细节

在组织评审的过程中，很多人不太注意细节。比如会议时间的设定，会议的通知，会议场所的选择，会场环境的布臵，会议设施的提供，会议上气氛的调节和控制等等，而实际上这样的细节会大大影响评审会议的效果。比如，很难想象，大家在一个空气混浊、噪音很大的会议室里面能够全身心的投入。

结语

经过了近两年发展，我们逐步建立了软件开发过程及相应的过程控制体系。在实际工作中，我们以前掌握的过程数据不多，基本上一步一步摸索着前进，对于过程数据也在不断地收集及整理中。对于评审技术而言，其中重要的一点是采用多种实际工具和手段，如针对每个过程进行评审的《缺陷检查表》等，我们也在逐步地完善这体系和过程数据，从而为我们

的过程改进不断提供支持。

【1】 朱少明编著 《软件项目管理》 人民邮电出版社

【2】 Karl E.wiegers 沈备君翻译 《软件同级评审》 机械工业出版社

【3】摘自《技术经济与管理研究》2004年第六期中《评审在电信软件开发中的应用》 【4】 石柱主编.

《软件工程标准手册》中国标准出版社