浅谈软件评审

开篇：润墨网以专业的文秘视角，为您筛选了一篇浅谈软件评审范文，如需获取更多写作素材，在线客服老师一对一协助。欢迎您的阅读与分享！

摘要:文章介绍了一般软件评审涉及的内容和软件评审中的各个角色与职责,重点说明软件评审的过程及评审的标准和评审中要注意的问题。同时也着重阐述了不同的软件开发可以根据此评审过程进行裁剪,评审过程是帮助作者提前发现评审对象的缺陷,而不是对评审对象的执行。

关键词:软件;预审;评审;评审专家;缺陷;质量

中图分类号:TP311文献标识码:A文章编号:1009-3044(2010)11-2629-02

On Software Review

CUI Hai-xia

(Shanghai Lida Computer Department, Polytechnic Institute, Shanghai 201609, China)

Abstract: This article outlines the general content of the software involved in the review process for software management, and shows in the software review in the various roles and responsibilities, focusing on the software review process, methods and review criteria adopted, the assessment is necessary to pay attention to issues. This article also focuses on the different software development can be carried out based on this review process, cutting the judging process is to help authors found that early assessment of defects in the object, rather than the release of the implementation of the review object.

Key words: software; preliminary review; review; review export; bug; quality

在软件开发管理中,人们总是希望用户的需求非常明确,软件的设计非常合理,代码的实现完全正确,并且软件开发可以按开发前制定的计划正常进行。但是,实际中这个要求在软件开发管理中往往是无法实现的,在实际的软件开发中,人们也是通过各种方法力求达到这一要求,其中软件评审就是一个很好的方法。软件评审可以组织项目组集体的力量,对软件相关内容进行合理分析,尽可能的在软件的生命前期发现并解决问题,所以软件评审的过程就显得尤为重要。

1 概述

在软件开发过程中软件评审至关重要,它贯穿软件开发的整个生命周期,是提高软件质量,降低软件成本,保证软件开发合理进行的重要保障。

1.1 软件评审的主要内容

软件评审一般包括计划评审,技术评审,过程评审,合同评审,管理评审等。计划评审一般是指项目级别计划的评审,具体又分为项目过程手册评审、项目计划书评审、项目WBS评审、质量保证计划评审、配置管理计划评审、项目工作任务书评审等。技术评审主要指售前技术方案,工作产品等的评审,具体分为架构设计、需求规格说明书、设计、代码、测试计划与测试案例、测试报告、部署验证案例等的评审。过程评审主要是指对公司各级管理规范及过程文档的评审,合同评审主要指销售合同、采购合同、外包合同等的评审,管理评审主要指项目立项评审、项目结项评审等。

1.2 软件评审过程的改进

软件评审过程的改进主要由质量管理部门负责。质量管理部门统一汇集本过程的改进需求后,提交公司级软件工程过程组,完成定义的过程改进任务。

2 软件评审过程中各角色与职责

软件评审中一般有5个角色:评审专家,讲解者,作者,QA。其中作者不能担当组织者、评审专家或讲解者的角色,别的角色之间可以兼任,下面具体介绍一下各角色的职责与分工。

2.1 组织者

组织者是被审对象方面的专家、权威。主要负责:确保评审对象满足发起评审的前提条件;与作者共同确定参加评审的人员;与评审专家一起确定评审时间表;确保评审专家有充分的时间参加评审,并在评审会议前已做好准备工作;决定评审的形式,详细说明评审目的,需要时,给评审专家分配评审的关注点;组织评审会议,组织评审专家发现评审对象的缺陷,并对发现的缺陷进行分类;保证相关人员完成了各自的职责,如评审专家完成预审并提交反馈意见、作者根据评审意见对评审对象做了修改、遗留问题得到解决等,确保在跟踪过程中发现的任何新的缺陷都已被标注并且添加到缺陷列表中去;协调评审专家的意见,对评审结论达成一致;裁决评审结论,通过、不通过;评审组织者可以兼任评审专家,执行相应的职责。

2.2 评审专家

评审专家主要负责:确保参加评审的时长达到评审质量的要求;理解评审对象;会前预审,发现缺陷并反馈;准备并参加评审会议,会上对评审对象的缺陷进行确认;验证作者修订的评审对象。

2.3 讲解者、作者和QA

讲解者主要负责理解评审对象并在介绍会、评审会上讲解评审对象,引导大家浏览评审对象。作者主要负责准备待评审的评审对象,并在评审会议上,确认评审专家的问题,根据评审意见,修改评审对象。QA主要负责评审过程审计,提供流程指导和过程数据指导,评审结论审核等。

3 软件评审流程

3.1 软件评审的一般流程

软件的评审过程一般可以分为提交评审申请,发评审通知,介绍会议,预审,评审会,第三小时会议,评审总结等,下面具体介绍。

1) 提交评审申请:作者提交评审申请给组织者,评审申请除提交评审对象外还需提交建议的评审专家及评审点,同时说明评审对象的背景及关键评审点,供组织者参考。

2) 发评审通知:组织者对评审对象及内容进行审核,对作者建议的评审专家进行审核,根据实际情况添加及删除评审专家,并跟评审专家做好沟通,确定他们能参加,并明确各自的角色与职责,制定评审的质量目标,决策评审对象是否符合评审条件,如果符合发评审通知,不符合打回给作者。

3) 介绍会议:如果评审专家反馈需要对被评审对象进行讲解,组织者安排介绍会议并由讲解者介绍待评审的评审对象。介绍会议是可选的,评审专家提出后,由组织者来决定是否需要举行,介绍会议的目的是帮助评审专家了解评审对象,以便进行评审。

4) 预审:评审专家检查评审对象,记录发现的问题及问题的严重程度并反馈给作者,作者对问题进行答复,对接受的问题完成文档修订,同时对问题的类型、引入根源、模式进行初步分析,并记录。评审专家必须反馈预审意见,即使没有发现问题,也要反馈无意见。

5) 评审会:讲解者引导大家浏览评审对象,确认预审发现的问题及作者对问题的答复,并对预审发现的问题做出缺陷分析结果,即对问题的类型、引入根源、模式、严重程度等进行确认。组织者对原记录的问题类型、引入根源、模式、严重程度可进行修改并引导大家发现新的缺陷。记录所有新增问题,包括存在疑问以及暂时无法裁决的问题。

6) 第三小时会议:目的是探讨问题的解决方案。作者在进行问题修改的时候,对于那些自己无法解决的问题,需要评审专家的协助,这时候可要求召开第三小时会议。

7) 评审结论:组织者对本次评审给出意见,如:通过、不通过、需重新评审、终止等。QA对组织者的评审结论进行审核,对于不符合通过条件的评审,QA可不予批准,并要求组织者重新评审或终止评审。组织者可对不符合评审过程的评审提出《例外报告》请求让步放行,但需经QA审核同意,本次评审方可通过。

3.2评审通过、不通过、终止的条件

1) 判定评审通过的条件:

全部达到如下条件时,评审可以通过。① 本次评审的质量目标达到;② 本次评审的过程附合规范;③ 评审发现的问题全部关闭,结论无挂起的问题;④ 反馈评审意见(包括反馈无意见)的评审专家不少于50%;⑤ 评审时间未超过计划结束时间达10个工作日以上。

2) 评审不通过须重新评审的条件

有如下情况之一时,评审不通过需重新评审的条件。① 本次评审的质量目标未达到;② 过程不附合规范;③ 发现问题未全部关闭,且经影响分析,遗留问题会给项目带来较大风险;④ 反馈评审意见(包括反馈无意见)的评审专家少于50%。

3)评审终止条件

如存在以下情况之一可终止评审。

① 经预审或评审发现评审对象完全不具备评审价值,如技术方案出现原则性错误;

② 评审时间超过计划结束时间10个工作日以上仍无法关闭的情况;

③ 评审因其他情况被中止,如项目中止、评审对象被裁剪等。

3.3 评审中的注意事项

软件评审虽然在软件开发中非常重要,是软件开发质量的重要保证,但软件评审具体执行时很容易形式话,或达不到预期的效果。下面总结了一些需要在评审中注意的问题。

评审之前,组织者对评审对象做审查,满足一定的条件,才能启动评审,审查内容包括文档格式、模板、文档名称等是否合适;建议,每次评审的专家和组织者不能少于3人;有效代码一般不超过500行;文档一般不超过40页;在有管理人员参加和有考核压力的情况下,不会降低评审的效果;超过一定的工作量评审就会没有效果,投入过多的工作量也不会发现更多的缺陷;准时参加评审会议;项目评审对象的评审,要作为项目的活动,在任务表中安排;评审过程中的评审会议阶段的目的是为了确认缺陷,而不是解决缺陷,因此,评审会议要避免陷入对缺陷解决方案的讨论之中;会议上无法达成一致或不能确定的问题,作为遗留问题进行跟踪;评审一定对事不对人,所有的问题、矛盾、讨论都是针对评审对象,绝对不能针对人,评审结果不能用来评价个人能力;会议之前做好准备工作,按照3-4-3原则进行,准备工作占30%,会议占40%,会后工作30%,切忌只管开会,会前会后啥都不管;如果做了预审,但没有发现问题,也要反馈,在反馈表里填写所用时间,不能以发现问题的多少来评定评审专家在评审中的作用;一定要做预审,把问题汇总,在会上先把问题确认一遍,然后讲解者带领大家一起浏览检查评审对象,讲解者需要有一定讲课技巧;选定评审专家的时候,跟评审对象有影响关系的人员要参与,另外,一定要让跟作者同一领域的技术专家参与,以保证评审能达到良好效果;启动评审之前,一定要先做好相关人员沟通工作,保证他们能参加评审,尤其是评审专家。

4 评审的裁减

一般根据评审的内容及组织特点,可以对以上子过程进行裁剪,只保留必要的子过程。走查和轮查就是两种常用的检查方法。走查是对同行评审的精简,取消预审会议,参与专家数也可以精简3人左右。专家意见完全可以在阅读评审对象提供的文档时,提出给组织者或作者本人。轮查是非常简单的一种检查方式,通常是作者或部门主管拿到一个评审对象,召集3个左右的资料相关方,坐在位置上一起讨论,给出评审意见。作者或部门主管结合评审意见进一步处理评审对象。

5 总结

评审是由相关的人员对评审对象进行检查的一项活动,目的是帮助作者在早期有效地发现评审对象的缺陷,防止缺陷流到后边的工作环节,并判定评审对象是否满足一定的要求,不是“执行”,也不是对评审对象决策。对于评审对象的质量,评审专家不承担责任,责任是作者的。至于如何考核评审专家,可通过行政处罚奖励等措施鼓励评审专家认真评审、尽可能发现缺陷。

参考文献:

[1] Wiegers K E.软件同级评审[M].北京:科学出版社,2004.

[2] 张万军, 储善忠.基于CMMI的软件工程教程[M].北京:北京交通大学出版社,2008.

[3] 朱少民.软件质量保证和管理[M].北京:清华大学出版社,2007.

[4] 张瑾.软件质量管理指南[M].北京:电子工业出版社,2009.

[5] 苏秦,张涑贤.软件过程质量管理[M].北京:科学出版社,2008.

[6] 钱乐秋,赵文耘,牛军钰.软件工程[M].北京:清华大学出版社,2007.

[7] 梁成材.CMM中各类评审的综合研究[J].计算机工程,2004,30(14):81-82.

[8] 范勇.一种有效的软件评审模型[J].计算机工程与设计,2007,28(23):5585-5587.