软件评审的具体分析

《软件评审的具体分析》由会员分享，可在线阅读，更多相关《软件评审的具体分析（6页珍藏版）》请在金锄头文库上搜索。

1、软件评审的具体分析杨浩（浙江师范大学 数理与信息工程学院 浙江 金华）摘要摘要软件评审的重要目的就是在评审重发现产品的缺陷，因此在评审上的投入可以减少大量 的后期反工，通过评审，还可以将问题记录下来，使得问题具有可追溯性【 【1】 】。做好软件评审 很重要。具体介绍软件评审的整个流程，对每个环节进行具体分析，促进管理规范化，评审正确化。 关键字：评审定义，评审步骤，评审种类，评审误区。引言引言软件评审直接关系到软件的命运和前途，好的软件评审能得到好的软件质量的保证。要 做好软件评审好考虑多反面的因素，如何把用户，开发人员，软件功能和市场紧密的联系在 一起将是评审是否成功的关键，因此我们必须适当

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

3、发的前期进行。评审评审的具体分析的具体分析一一.软软件件评审评审的定的定义义 软件评审，是指在软件开发过程中，由参与评审的人员对软件开发文档或代码进行评审 或检查，帮助查找缺陷和改进。 软件评审的工作包括： 1. 检验产品是否满足以前的规范，如需求或设计文档； 2. 识别产品相对于标准的偏差； 3. 向作者提出改进建议； 4. 促进技术交流和学习。 评审的主要类别有：软件定义评审、软件需求评审、概要设计评审、详细设计评审、软件实现 评审和软件验收评审等【3】。二二.设计质设计质量的量的评审评审内容内容 (1) 评价软件的规格说明是否合乎用户的要求,即总体设计思想和设计方针是否明确;需求 规格说

4、明是否得到了用户或单位上级机关的批准;需求规格说明与软件的概要设计规格 说明是否一致等。 (2) 评审可靠性,即是否能避免输入异常（错误或超载等）、硬件失效及软件失效所产生的 失效，一旦发生应能及时采取代替或恢复手段 。 (3) 评审保密措施实现情况,即是否提供对使用系统资格进行检查;对特定数据的使用资格、 特殊功能的使用资格进行检查，在查出有违反使用资格情况后，能否向系统管理人员报 告有关信息；是否提供对系统内重要数据加密的功能等。(4) 评审操作特性实施情况，即操作命令和操作信息的恰当性，输入数据与输入控制语句 的恰当性；输出数据的恰当性；应答时间的恰当性等。(5) 评审性能实现情况，即是

5、否达到所规定性能的的目标值。(6) 评审软件是否具有可修改性、可扩充性、可互换性和可移植性。(7) 评审软件是否具有可测试性。(8) 评审软件是否具有复用性。三三.程序程序质质量的量的评审评审内容内容程序质量评审通常它是从开发者的角度进行评审，直接与开发技术有关。它着眼于软件 本身的结构、与运行环境的接口、变更带来的影响而进行的评审活动。1.软件的结构功能结构。在软件的各种结构中，功能结构是用户唯一能见到的结构。需要检查的项目有：数据结构包括数据名和定义；构成该数据的数据项；数据与数据间的关系。功能结构：包括功能名和定义；构成该功能的子功能；功能与子功能之间的关系。数据结构和功能结构之间的对应

6、关系：包括数据元素与功能元素之间的对应关系数据结 构与功能结构的一致性。(2) 功能的通用性。(3) 模块的层次。( 4) 模块结构。控制流结构：规定了处理模块与处理模块之间的流程关系。检查处理模块之间的转 移关系与控制转移形式（调用方式）。数据流结构：规定了数据模块是如何被处理模块进行加工的流程关系。检查处理模 块与数据模块之间的对应关系；处理模块与数据模 块之间的存取关系，如建立、删除、 查询、修改等。模块结构与功能结构之间的对应关系：包括功能结构与控制流结构的对应关系；功能 结构与数据流结构的对应关系；每个模块的定义 （包括功能、输入与输出数据）。(5) 处理过程的结构。处理过程是最基本

7、的加工逻辑过程。2.与运行环境的接口(1) 与硬件的接口。(2) 与用户的接口。随着软件运行环境的变更，软件的规格也在跟着不断地变更。运行环境变更时的影 响范围，需要从以下三个方面来分析：(1) 与运行环境的接口。(2) 在每项设计工程规格内的影响。(3) 在设计工程相互间的影响。 四四.软软件件评审评审的步的步骤骤软件评审是一个交互的过程，执行软件评估时要做到严谨，认真。在评审进行前，首先 要做好计划，包括确定被评审的对象，期望达到的评审目标和计划选用的方法。然后 为评审计划的实施进行准备。包括选择参加评审合适的人员，协商和安排评审时间。接着召 开会议进行集体评审，确定问题，然后跟踪这些问题

8、。软件评审步骤的具体分析：序号 步骤 事务所的工作 贵公司的工作 1 签定合同 提供合同样本，提出完成项目所需时间，收费 商讨收费及时间 2 制定项目总体计划 提供项目计划书初稿 与事务所讨论计划 书 3 评审准备辅导 介绍评审要求、注意事项，提供法律文件，与 广州会计电算化协会沟通 协调财务部与电脑 部在评审中的工作 4 了解性测试 对软件进行初步测试 提供电脑及一名熟 悉系统的人员配合 5 审核相关法律文件 对企业提供的法律文件进行审核，并提出专 业意见 提供所需的法律文 件 6 审核并行会计资料 审核并行三个月的凭证、帐簿、会计报表 提供并行的资料并 复核 7 模拟测试 设置模拟测试的数

9、据，复核输入的模拟数据 复核输出结果 设置测试帐套，输 入模拟数据 8 综合测试 拟订测试提纲，与企业讨论，根据测试提纲 对 ORACLE 进行测试，对测试结果进行讨论， 提出改进建议 提供电脑及一名熟 悉系统的人员配合 9 改进结果复核 对系统改进结果进行复核 10 正式评审准备 指导企业准备正式评审的材料，与会计电算 化协会、企业协商评审时间 准备评审所需的资 料及场地，确定评 审时间 11 正式评审 组织评审会,派车接送会计电算化协会参加评 审的人员，评审中介绍前期工作,回答有关问 题 介绍企业及软件情 况，演示系统，回 答会计电算化协会 人员的提问 12 出具评审报告 出具评审报告及验

10、收表 在验收表封面盖章 13 报告送审 评审报告及验收表送广州会计电算化协会审 批 14 颁发证书 领取证书后送达企业 按合同支付评审费用 五五.软软件件评审评审的分的分类类 自从有软件开发以来，人们就在不断地采用各种正式或非正式的软件评审技术来提高 软件质量。经过几十年的发展，软件评审技术和多种项目管理理论相结合，已经发展成一个 庞大的体系。就总体而言，软件评审主要类：管理评审，技术评审，审查，走查，审核【4】。对于不同的分类，内容存在很大差异，在软件评估中占据着举足轻重的作用。 软件评审类型的具体分析：特征管理评审技术评审审查走查审核目的确保进度;推荐 纠正措施;确保 适当的资源分配评价与

11、规格说 明和计划的符合性;确保更改 的完整性发现异常; 验 证解决;验证 产品质量发现常检 查备选方 法; 改进 产品; 独立评价与客 观标准和条例的符合 性决策管理组制定行 动路线;在会议 上或作为建议 的结果作出决策评审组要求管 理部门或者技 术领导对建议采取措施审查组选折 预先定义的 产品处置方 法;必须消除缺陷走查组同意由作者 作出的更 改被审核的组织、 启动者、需方、 顾客或用户更改验证负责人验证选 择的措施项;更 改验证留给其 它项目控制人 员负责人验证选 择的措施项;更 改验证留给其 它项目控制人 员负责人验证 选择的措施 项;更改验证 留给其它项 目控制人员负责人验 证选择的

12、措施项; 更改验证 留给其它 项目控制 人员被审核组织的 责任推荐的小 组的规模2 人或以上3 人或以上36 人27 人15 人小组的成 员管理人员、技术 领导和同行技术领导和同行满足文档中 规定的人数的同行技术领导和同行审核员、被审核 组织、管理和技 术人员组长通常是责任经理通常是主任工 程师经过培训的 协调人协调人或作者主任审核员材料规模中到高,取决于 具体会议的目的中到高,取决于 会议的目的相当低相当低中到高,取决于 具体审核的目的 陈诉者项目代表开发组代表领读者作者审核员收集并 检查被审核组 织提供的信息数据收集按适用政策、标 准或计划的要 求进行不是一个正式 的项目要求。可能需要局部

13、 进行强烈建议建议不是一个正式 的项目要求。可能需要局部 进行输出管理评审文档技术评审文档异常清单、异 常概述、审查文档异常清单、 措施项、 后续工作 建议正式审核报告; 观察、发现和缺陷正式的协 调员培训无无有无有使用缺陷 检查单无无有无有管理人员有可选无无有六六.软软件件评审评审的的误误区区误区一：评审参与者不了解评审过程 如果评审参与者不了解整个的评审过程，就会有一种自然的抗拒情绪，因为大家看不到做这件事情的效果，感觉到很迷茫，这样会严重的影响大家参与评审的积极性。 误区二：评审人员评论开发人员，而不是产品 评审的主要目的是发现产品中的问题，而不是根据产品来评价开发人员的水平。但是往往会

14、出现把产品质量和开发人员水平联系起来的事情，于是评审变了“味”，变成了“批斗大会”，极大的打击了开发人员的自尊心，以至严重的影响了评审的效果。 误区三：评审没有被安排进入项目计划 参与评审需要投入大量的时间和精力，应该被安排进入项目计划中。但是现实的情况往往是，评审变成了“义务工”，参与评审的人员必须加班加点才能完成评审任务。如此一来，出现评审人员对评审对象不了解的情况也就不足为奇了。 误区四：评审会议变成了问题解决方案讨论会 评审会议主要的目的是发现问题，而不是解决问题，问题的解决是评审会议之后需要做的事情。但是，由于开发人员对技术的追求，评审会议往往变成了问题研讨会，大量的占用了评审会议的

15、时间，导致大量评审内容被忽略，留下无数的隐患。 误区五：评审人员事先对评审材料没有足够了解 任何一份评审材料都是他人智慧和心血的结晶，需要花足够的时间去了解、熟悉和思考。只有这样，才能在评审会议上发现有价值的深层次问题。在很多的评审中，评审人员因为各种的原因，在评审会议之前对评审材料没有足够的了解，于是出现了评审会议变成了技术报告的怪现象。 误区六：评审人员关注于非实质性问题 经常会出现这样的问题，在评审中，评审人员过多的关注于一些非实质性的问题，比如文档的格式，措词，而不是产品的设计。出现这样的情况，可能的原因有：没有选择合适的人参加评审；评审人员对评审对象没有足够的了解，无法发现深层次的问

16、题。 误区七：忽视细节 在组织评审的过程中，很多人不太注意细节。比如会议时间的设定，会议的通知， 会议场所的选择，会场环境的布置，会议设施的提供，会议上气氛的调节和控制等等， 而实际上这样的细节会大大影响评审会议的效果。比如，很难想象，大家在一个空气 混浊、噪音很大的会议室里面能够全身心的投入。结结语语经过了近两年发展，我们逐步建立了软件开发过程及相应的过程控制体系。在实际工作 中，我们以前掌握的过程数据不多，基本上一步一步摸索着前进，对于过程数据也在不断地 收集及整理中。对于评审技术而言，其中重要的一点是采用多种实际工具和手段，如针对每 个过程进行评审的缺陷检查表等，我们也在逐步地完善这体系和过程数据，从而为我们的 过程改进不断提供支持。【1】 朱少明编著 软件项目管理 人民邮电出版社 【2】 Karl E.wiegers 沈备君翻译 软件同级评审 机械工业出版社 【3】摘自技术经济与管理研究2004 年第六期中评审在电信软件开发中的应用 【4】 石柱主编. 软件工程标准手册 中国标准出版社