软件工程中的评审技术及流程

在软件产品质量保证过程中，评审是优先使用的质量保证技术之一。与测试相比，评审的效率更高，成本也更低，特别是事先的评审，有助于缺陷的预防，可以尽量减少通过测试发现缺陷的数量，从而降低项目成本。在软件产品的生命周期当中，评审活动是经常开展的。具体评审可以分为正式评审、非正式评审；内部评审、外部评审；阶段评审、变更评审；项目评审、流程评审和管理评审等。有些时候评审也可以被称为审计。但不论哪种分类评审一般都是出现在项目的里程碑阶段或者项目有重大变化的时候。

以下阶段评审为例来说明评审工作是如何进行的。阶段评审属于正式评审的范畴，按照瀑布模型（其他开发模型同样也是可以分成若干阶段的），软件开发可以分成可行性分析、需求分析、设计（有时候被分为概要设计、详细设计）、编码、测试和维护六个阶段，每阶段的成果都是下一阶段工作开展的基础和依据，同时在上一阶段所出现的缺陷如果不能被及时发现，将会在下一阶段被放大，缺陷发现的越晚，修复缺陷所需要付出的代价越大，通过阶段性评审的目的就是要及早的发现产品中潜在的缺陷。阶段性评审一般都是采用会议的形式进行。在进行评审会议之前需要准备好评审所需的各类项目文档，包括但不限于以下文档：

·可行性分析阶段：可行性分析报告、开发计划等文档；

·需求分析阶段：软件需求规格说明（也称为：软件需求说明、软件规格说明）、数据要求说明和初步用户手册等文档；

·设计阶段：结构设计说明、详细设计说明和测试计划初稿等文档；

·实现阶段：程序清单、用户手册、操作手册、测试计划等文档；

·测试阶段：测试分析报告、项目开发总结报告等文档。(www.xing528.com)

用于评审的各类文档在经过质量管理人员和配置管理人员的审核并经项目经理确认后，需要提前发送给评审小组成员，而不是等会议开始的时候直接发给评审小组，要保障评审的效果，必须提供给评审小组足够的阅读和思考时间。评审小组的构成包括项目组成员、用户和外部专家三部分，必要的时候可以包括企业和用户的高层管理人员，特别是在项目前期的可行性分析和需求分析阶段，因为在这两个阶段需要确定软件产品的远景，也就是宏观上需要实现的目标，高层管理人员的参与能够避免项目的大方向偏离。对项目组成员而言并不是需要全体参与的，但以下几类人必须参加：项目经理、质量保证人员、配置管理人员、系统分析人员、主要开发设计人员、主要测试人员，这些人员是软件项目的核心团队成员。

在进行评审会议的时候，首先由项目经理介绍项目的整体进展情况；其次由各文档的主要负责人对文档内容进行说明；再次由评审小组成员提出问题，项目组成员进行解释说明；最后由评审小组进行审议。在评审会议以后，应该以会议纪要的形式将本次会议的内容进行记录，同时发送给评审小组成员。

很多时候阶段审核并不是一次审核通过，在审核不通过的情况下，项目组必须根据评审会议所发现的问题和所提出的修改意见重新开始上一阶段的工作，在完成修改后再次提请评审，第二次评审并不需要完全重复第一次的内容，重点应放在第一次评审之后，项目所作出的修改部分。

项目审核通过并不代表上一阶段不存在任何缺陷和问题，有两种情况：第一种是缺陷和问题没有被发现，这种情况只能够等待之后的阶段来发现；第二种情况是发现了缺陷和问题，但所发现的缺陷和问题是能够通过后续的步骤来改进或弥补，比如软件文档的质量，或者是某个数据结构当中的数据长度问题，因为这类问题可以通过简单的修改就能够解决，所以没有必要一定要经过下一次评审。

当阶段评审通过后，阶段评审所得到的各类正式文档（包括代码）应进入配置库，并成为下一阶段工作开展的基线，如果在下一阶段出现变更，则应按变更管理的流程执行，最后修改产品基线。

除了阶段性评审这样大规模的正式评审以外，在项目进展过程中还有很多小规模的评审，最常见的是项目周报和月报。项目周报和月报属于周期性的工作，通过对项目周报和月报的评审可以及时掌握和了解项目的实际进展情况，同时对下一步的工作计划可以根据需要进行调整。