软件评审的具体剖析

《软件评审的具体剖析》由会员上传分享，免费在线阅读，更多相关内容在工程资料-天天文库。

软件评审的具体分析杨浩（浙江师范大学数理与信息工程学院浙江金华）摘要软件评审的重要目的就是在评审重发现产品的缺陷，因此在评审上的投入可以减少大量的后期反工，通过评审，还可以将问题记录下来，使得问题具有可追溯性【1】。做好软件评审很重要。具体介绍软件评审的整个流程，对每个环节进行具体分析，促进管理规范化，评审正确化。关键字：评审定义，评审步骤，评审种类，评审误区。引言软件评审直接关系到软件的命运和前途，好的软件评审能得到好的软件质量的保证。要做好软件评审好考虑多反面的因素，如何把用户，开发人员，软件功能和市场紧密的联系在一起将是评审是否成功的关键，因此我们必须适当的细化软件评审，熟悉评审的具体环节，规范评审，把评审的每一个环节做好，保证软件评审的正常进行，进而正确的指导软件开发。背景软件规模的扩大及复杂度的提高导致了20世纪60年代末爆发的软件危机。所谓“软件危机”主要指在计算机软件的开发和维护过程中所遇到的一系列严重问题，如成本增加、进度难以控制、质量差、维护困难等。为了克服软件危机，人们开始探索用工程的方法来进行软件生产的可能性，软件工程应运而生【2】。在软件工程中，评审和测试是提高软件质量的非常重要的两个过程。在软件开发过程中，软件评审和软件测试是保证软件质量的两种主要方法和手段，测试主要在软件开发的后期进行，而评审主要在软件开发的前期进行。评审的具体分析一.软件评审的定义软件评审，是指在软件开发过程中，由参与评审的人员对软件开发文档或代码进行评审或检查，帮助查找缺陷和改进。软件评审的工作包括：1.检验产品是否满足以前的规范，如需求或设计文档；2.识别产品相对于标准的偏差；3.向作者提出改进建议；4.促进技术交流和学习。 评审的主要类别有：软件定义评审、软件需求评审、概要设计评审、详细设计评审、软件实现评审和软件验收评审等【3】。二.设计质量的评审内容(1)评价软件的规格说明是否合乎用户的要求，即总体设计思想和设计方针是否明确；需求规格说明是否得到了用户或单位上级机关的批准；需求规格说明与软件的概要设计规格说明是否一致等。(2)评审可靠性，即是否能避免输入异常(错误或超载等)、硬件失效及软件失效所产生的失效，一旦发生应能及时采取代替或恢复手段。(3)评审保密措施实现情况，即是否提供对使用系统资格进行检查；对特定数据的使用资格、特殊功能的使用资格进行检査，在查出有违反使用资格情况后，能否向系统管理人员报告有关信息；是否提供对系统内重要数据加密的功能等。(4)评审操作特性实施情况，即操作命令和操作信息的恰当性，输入数据与输入控制语句的恰当性；输出数据的恰当性；应答时间的恰当性等。(5)评审性能实现情况，即是否达到所规定性能的的目标值。(6)评审软件是否具有可修改性、可扩充性、可互换性和可移植性。(7)评审软件是否具有可测试性。(8)评审软件是否具有复用性。三•程序质量的评审内容程序质量评审通常它是从开发者的角度进行评审，直接与开发技术有关。它着眼于软件本身的结构、与运行环境的接口、变更带来的影响而进行的评审活动。1.软件的结构功能结构。在软件的各种结构中，功能结构是用户唯一能见到的结构。需要检查的项目有：数据结构包括数据名和定义；构成该数据的数据项；数据与数据间的关系。功能结构：包括功能名和定义；构成该功能的子功能；功能与子功能之间的关系。数据结构和功能结构之间的对应关系：包括数据元素与功能元素之间的对应关系数据结构与功能结构的一致性O(2)功能的通用性。(3)模块的层次。(4)模块结构。控制流结构：规定了处理模块与处理模块之间的流程关系。检查处理模块之间的转移关系与控制转移形式(调用方式)。数据流结构：规定了数据模块是如何被处理模块进行加工的流程关系。检查处理模块与数据模块之间的对应关系；处理模块与数据模块之间的存取关系，如建立、删除、查询、修改等。模块结构与功能结构之间的对应关系：包括功能结构与控制流结构的对应关系；功 能结构与数据流结构的对应关系；每个模块的定义(包括功能、输入与输出数据)。(2)处理过程的结构。处理过程是最基本的加工逻辑过程。1.与运行环境的接口(1)与硬件的接口。(2)与用户的接口。随着软件运行环境的变更，软件的规格也在跟着不断地变更。运行环境变更时的影响范围，需要从以下三个方面来分析：(1)与运行环境的接口。(2)在每项设计工程规格内的影响。(3)在设计工程相互间的影响。四.软件评审的步骤软件评审是一个交互的过程，执行软件评估时要做到严谨，认真。在评审进行前，首先要做好计划，包括确定被评审的对象，期望达到的评审目标和计划选用的方法。然后为评审计划的实施进行准备。包括选择参加评审合适的人员，协商和安排评审时间。接着召开会议进行集体评审，确定问题，然后跟踪这些问题。软件评审步骤的具体分析:序号步骤事务所的工作贵公司的工作1签定合同提供合同样本，提出完成项目所需时间，收费商讨收费及时间2制定项目总体计划提供项目计划书初稿与事务所讨论计划书3评审准备辅导介绍评审要求、注意事项，提供法律文件，与广州会计电算化协会沟通协调财务部与电脑部在评审中的工作4了解性测试对软件进行初步测试提供电脑及一名熟悉系统的人员配合5审核相关法律文件对企业提供的法律文件进行审核，并提出专业意见提供所需的法律文件6审核并行会计资料审核并行三个月的凭证、帐簿、会计报表提供并行的资料并复核7模拟测试设置模拟测试的数据，复核输入的模拟数据复核输出结果设置测试帐套，输入模拟数据8综合测试拟订测试提纲，与企业讨论，根据测试提纲对ORACLE进行测试，对测试结果进行讨论，提出改进建议提供电脑及一名熟悉系统的人员配合9改进结果复核对系统改进结果进行复核10正式评审准备指导企业准备正式评审的材料，与会计电算化协会、企业协商评审时间准备评审所需的资料及场地，确定评审时间 11正式评审组织评审会，派车接送会计电算化协会参加评审的人员，评审中介绍前期工作，回答有关问题介绍企业及软件情况，演示系统，回答会计电算化协会人员的提问 12出具评审报告出具评审报告及验收表在验收表封面盖章13报告送审评审报告及验收表送广州会计电算化协会审批14颁发证书领取证书后送达企业按合同支付评审费用五.软件评审的分类自从有软件开发以来，人们就在不断地采用各种正式或非正式的软件评审技术来提高软件质量。经过几十年的发展，软件评审技术和多种项目管理理论相结合，已经发展成一个庞大的体系。就总体而言，软件评审主要类：管理评审，技术评审，审查，走查，审核【4】。对于不同的分类，内容存在很大差异，在软件评估中占据着举足轻重的作用。软件评审类型的具体分析:特征管理评审技术评审审查走查审核目的确保进度;推荐纠正措施;确保适当的资源分酉己评价与规格说明和计划的符合性;确保更改的完整性发现异常；验证解决;验证产品质量发现常检查备选方法；改进产品;独立评价与客观标准和条例的符合性决策管理组制定行动路线;在会议上或作为建议的结果作出决评审组要求管理部门或者技术领导对建议采取措施审查组选折预先定义的产品处置方法；必须消除缺陷走查组同意由作者作出的更改被审核的组织、启动者、需方、顾客或用户更改验证负责人验证选择的措施项；更改验证留给其它项目控制人员负责人验证选择的措施项；更改验证留给其它项目控制人员负责人验证选择的措施项；更改验证留给其它项目控制人员负责人验证选择的措施项；更改验证留给其它项目控制人员被审核组织的责任推荐的小组的规模2人或以上3人或以上3~6人2~7人1~5人小组的成员管理人员、技术领导和同行技术领导和同行满足文档中规定的人数的同行扌支术领导和同行审核员、被审核组织、管理和技术人员组长通常是责任经理通常是主任工程师经过培训的协调人协调人或作者主任审核员材料规模中到高，取决于具体会议的目的中到高，取决于会议的目的相当低相当低中到高，取决于具体审核的目的陈诉者项目代表开发组代表领读者作者审核员收集并检查被审核组织提供的信息数据收集按适用政策、标准或计划的要不是一个正式的项目要求。可强烈建议建议不是一个正式的项目要求。可 求进行能需要局部进行能需要局部进行输出管理评审文档技术评审文档异常清单、异常概述、审查文档异常清单、措施项、后续工作建议正式审核报告；观察、发现和缺陷正式的协调员培训无无有无有使用缺陷检查单无无有无有管理人员有可选无无有六.软件评审的误区误区一：评审参与者不了解评审过程如果评审参与者不了解整个的评审过程，就会有一种自然的抗拒情绪，因为大家看不到做这件事情的效果，感觉到很迷茫，这样会严重的影响大家参与评审的积极性。误区二：评审人员评论开发人员，而不是产品评审的主要目的是发现产品中的问题，而不是根据产品来评价开发人员的水平。但是往往会出现把产品质量和开发人员水平联系起来的事情，于是评审变了“味”，变成了“批斗大会”，极大的打击了开发人员的自尊心，以至严重的影响了评审的效果。误区三：评审没有被安排进入项目计划参与评审需要投入大量的时间和精力，应该被安排进入项目计划中。但是现实的情况往往是，评审变成了“义务工”，参与评审的人员必须加班加点才能完成评审任务。如此一来，出现评审人员对评审对象不了解的情况也就不足为奇了。误区四：评审会议变成了问题解决方案讨论会评审会议主要的目的是发现问题，而不是解决问题，问题的解决是评审会议之后需要做的事情。但是，由于开发人员对技术的追求，评审会议往往变成了问题研讨会,大量的占用了评审会议的时间，导致大量评审内容被忽略，留下无数的隐患。误区五：评审人员事先对评审材料没有足够了解任何一份评审材料都是他人智慧和心血的结晶，需要花足够的时间去了解、熟悉和思考。只有这样，才能在评审会议上发现有价值的深层次问题。在很多的评审中，评审人员因为各种的原因，在评审会议之前对评审材料没有足够的了解，于是出现了评审会议变成了技术报告的怪现象。误区六：评审人员关注于非实质性问题经常会出现这样的问题，在评审中，评审人员过多的关注于一些非实质性的问题,比如文档的格式，措词，而不是产品的设计。出现这样的情况，可能的原因有：没有选择合适的人参加评审；评审人员对评审对象没有足够的了解，无法发现深层次的问题。误区七：忽视细节 在组织评审的过程中，很多人不太注意细节。比如会议时间的设定，会议的通知，会议场所的选择，会场环境的布置，会议设施的提供，会议上气氛的调节和控制等等，而实际上这样的细节会大大影响评审会议的效果。比如，很难想象，大家在一个空气混浊、噪音很大的会议室里面能够全身心的投入。结语经过了近两年发展，我们逐步建立了软件开发过程及相应的过程控制体系。在实际工作中，我们以前掌握的过程数据不多，基本上一步一步摸索着前进，对于过程数据也在不断地收集及整理中。对于评审技术而言，其中重要的一点是采用多种实际工具和手段，如针对每个过程进行评审的《缺陷检查表》等，我们也在逐步地完善这体系和过程数据，从而为我们的过程改进不断提供支持。[1]朱少明编著《软件项目管理》人民邮电出版社[2]KarlE.wiegers沈备君翻译《软件同级评审》机械工业出版社【3】摘自《技术经济与管理研究》2004年第六期中《评审在电信软件开发中的应用》[4]石柱主编.《软件工程标准手册》中国标准出版社