软件技术评审规程整理版.docx

软件技术评审规程整理版.docx

《软件技术评审规程整理版.docx》由会员分享，可在线阅读，更多相关《软件技术评审规程整理版.docx（7页珍藏版）》请在冰豆网上搜索。

软件技术评审规程

1引言

1.1目的

明确技术评审的类型，以及如何组织同行评审会议。

1.2适用范围

本标准适用于对公司所有项目各阶段产生的产品的技术评审。

2技术评审

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

软件评审的工作包括：

1）检验产品是否满足以前的规范，如需求或设计文档；

2）识别产品相对于标准的偏差；

3）向作者提出改进建议；

4）促进技术交流和学习。

软件技术评审涉及评审的组织机构、管理、准则、类别、内容、文件和要求等。

一般要求在软件研制阶段的里程碑点进行软件评审。

评审的主要类别有：

软件定义评审、软件需求评审、概要设计评审、详细设计评审、软件实现评审和软件验收评审等。

软件技术评审主要分为3类：

审查、走查、四眼评审。

其中审查是最系统化、最严密的评审技术，严格规定了每个阶段的角色及各自职责，在质量要求非常高的软件开发项目中得到了较广泛的应用。

在判断采用哪种评审方法时，需考虑以下风险因素：

1）使用了新技术，方法，工具的组件

2）关键的架构性的组件

3）难以理解，却又必须准确和优化的复杂逻辑或算法

4）具有危险失败模式的组件，而且是任务、可靠性、安全性关键的

5）具有多个异常条件或失败模式的组件

6）不易测试的异常处理代码

7）打算复用的组件

8）将作为其他组件的模型或模板的组件

9）影响产品多个部分的组件

10）复杂的用户界面

11）由缺乏经验的开发者创建的组件

12）具有高度圈复杂性的代码模块

13）以往具有很多缺陷或变更的模块

3技术评审类型

技术评审分为：

审查（即同行评审）、走查、四眼评审3种方式。

3.1审查即同行评审

同行评审步骤一般是：

评审计划、总体会议，评审准备，评审会议，修改、验证。

同行评审的目的主要是及早高效的发现并消除开发过程中出现的缺陷。

整个过程关键是组织评审会议，只有评审会议进行完满，其他修改Bug、消除缺陷都比较容易完成。

评审会议流程一般采取以下几个步骤：

评审会议的准备、评审会议的召开、评审会议的跟踪三大环节。

组建评审小组是首先要做的工作。

评审小组通常由5人及5人以下组成，其中一人担任评审组组长。

评审组组长应全面负起组织评审会的责任，他工作的好坏直接影响评审会成功与否。

评审组成员应该由与被评审的工作产品无直接关系的同行专家，以保证评审工作开展的公正性、客观性。

还可以包括被评审项目的开发人员，他们主要是介绍被评审产品的情况，提供所需信息。

还可以有配置管理人员和质量保证人员参加。

3.1.1评审会议准备

会议的发起人召集会议，发出评审通知（评审内容、会议时间、会议地点、参加人员等），并且将相关待评审的相关资料也发送给参加会议的评委；主要的目的有两个：

第一、让参加会议的人员对会议的内容有一定的了解，在会议前做好准备，避免盲目的参加会议而浪费自己和其他人的时间；第二、如果该评委在会议时间有其他紧急的事情，可以及早反馈给会议召集人，必便召集人重新确定评委或者评审会议改期召开。

3.1.2评审会议的召开

一般情况下，确定一个会议主持人；其主要的职责是控制会议的进度、时间、协调会议中出现的偏差。

对于待评审的工作产品由其生产者采用“走读”的形式进行讲解，在讲解的过程中回答评委提出的问题。

会议记录人主要是记录会议中发现的所有问题，方便会后的修改完善。

QA人员参加会议主要的关注点在于对照QA的检查表Checklist 检查评审的流程是否符合规范。

3.1.3评审会议的跟踪

将记录的问题汇总到《评审会议纪要》，由项目组进行修改、完善；QA监督所有问题是否封闭。

3.2采用同行评审的过程

采用最严格最系统的同行评审方法的软件过程有：

1）《软件需求规格说明书》的评审

2）《概要设计说明书》的评审

3）《详细设计说明书》的评审

4）代码评审

5）《集成测试计划》的评审

对于文档评审以文档页数为基数，要求每页发现的缺陷数有一个目标值，并规定了上下限的范围。

对于代码评审以代码行数为基数，要求每千行代码发现的缺陷数有一个目标值，并规定了上下限的范围。

3.3同行评审软件过程的准则

3.3.1软件需求规格

3.3.1.1输入

需提交的材料包括：

《产品需求规格说明书》、《系统测试计划（初稿）》、合同项目提交合同或投标书或项目方案书，研发项目提交《项目立项申请书》和《可行性分析报告》。

3.3.1.2评审准则

n《-SP-RDM-C01产品需求规格说明书检查单》

3.3.1.3评审重点

主要关注需求来源、需求的准确性、需求的完整性，需求的影响等方面；最好让测试人员和客户参加，以便让各角色达成共识。

3.3.1.4批准

《产品需求规格说明书》由高层经理批准

3.3.2项目计划

3.3.2.1输入

项目开发计划评审需提交的材料包括：

《项目计划》和《产品需求规格说明书》。

3.3.2.2评审准则

n《-SP-PP-C01项目计划检查单》

3.3.2.3评审重点

主要是关注的核心在于估计是否准确；人员安排是否合理；以上两个方面如果合理，项目的进度就不会出很大的问题。

3.3.2.4批准

《项目计划》由高层经理批准。

3.3.3概要设计

3.3.3.1输入

需提交的材料包括：

《概要设计说明书》、《数据库设计说明书》、《集成测试计划》（初稿）、《产品需求规格说明书》。

3.3.3.2评审准则

n《-SP-SD-C01概要设计检查单》

3.3.3.3评审重点

在总体设计评审中，最好将已经评审通过的需求文档从配置管理库中提出，对照总体设计是否和需求一致；另外，技术领域专家参加评审还要关注于设计的合理性、可实现性以及完整性。

3.3.3.4批准

《概要设计说明书》由高层经理批准

3.3.4详细设计

3.3.4.1输入

需提交的材料包括：

《详细设计说明书》、《概要设计说明书》、《接口规范》。

3.3.4.2评审准则

n《-SP-SD-C02详细设计检查单》

3.3.4.3批准

《详细设计说明书》由高层经理批准

3.3.5软件测试

3.3.5.1输入

需提交的材料包括：

《测试计划》、《测试用例》，系统测试和验收测试需提交《产品需求规格说明书》，集成测试需提交《概要设计说明书》，单元测试需提交《详细设计说明书》

。

3.3.5.2评审准则

n《-SP-PT-C01集成测试的检查单》

n《-SP-PT-C02验收测试计划检查单》

n《-SP-PT-C03验收测试报告检查单》

3.3.5.3批准

《集成测试计划》《系统测试计划》《验收测试报告》由高层经理批准。

3.4同行评审应当把握的原则

3.4.1评审工作产品，而不是评审生产者

评审涉及到别人和自我。

如果进行的恰当，可以使所有参与者体会到温暖的成就感。

如果不恰当，则可能陷入审问的气氛之中。

应当温和的指出错误，会议的气氛应当是轻松和建设性的；不要试图贬低或者羞愧别人。

主持人应当加以引导，以保证会议始终处于恰当的气氛和态度中，如果失去控制应立即休会。

3.4.2制定日程，并且遵守日程

各种会议经常有一个主要的缺点：

放任自流。

评审会议必须保证不要离题和按照计划进行。

主持人要有维持会议的程序的责任，有人在转移话题的时候应当提醒。

3.4.3限制争论和辩驳

评委提出问题时，未必所有人都能认同该问题的严重性或者能马上打成一直的意见。

不要花费时间争论这一问题，应当记录在案，留会后讨论。

3.4.4对各个问题发表见解，但是不要试图解决所有记录的问题

评审会议不是解决问题的会议。

问题的解决由生产者自己或者其他人的帮助下完成。

问题的解决方案应当在会后进行。

3.4.5作书面笔记

有时候让记录员在黑板上作笔记是个好主意，在记录的时候，评委可以推敲措词，确定问题的优先次序。

3.4.6限制参与人数，并且坚持事先做准备

个人的脑袋好过一个，但是14个脑袋未必就好过4个。

将评审涉及的人员数量保证保持在最小的值上。

所有参与会议的人员要事先作好准备。

3.4.7为每个可能要评审的工作产品建立一个检查表

检查表能帮助评审主持人组织会议，并帮助每个与会人员将注意力集中在重要问题上。

3.4.8为评审分配资源和时间

评审要占项目组的资源和时间。

所以，评审会议一定要作为软件工作活动的任务加以调度。

可以在综合计划中考虑进去。

3.4.9对所有的评审者进行有意义的培训

为了提高效率，所有参与评审会议的人都应当接受正式的培训。

3.4.10会议时间的控制

为了提高效率，每次评审会议只评审一个工作产品，并且时间最长不能超过2个小时。

所以要求，在评审准备时候各位评委事先作好准备。

4其它评审类型介绍

4.1走查

走查是一种常用的非正式的评审方式，它可以对代码、设计、需求进行检查。

通常用于开发小组成员间的评审方法，主要是达到纠正明显的错误的目的。

而四眼评审则是开发小组成员与项目经理之间评审，在项目组内部的评审方法，主要是能发现一些潜在的非功能、非设计性的错误，督促纠正。

同行评审是最为正式的技术评审，它独立于项目组外，由非此项目组的同行专家、测试部门、QA 人员、客户等角色组成，主要是考察项目系统的正确性，发现项目决定性的错误。

4.1.1代码走查的概念

代码走查是一种非正式的评审，它以小组为单元进行代码阅读，是一系列规程和错误检查技术的集合。

且代码走查可以采用持续一至两个小时的不间断会议的形式和开发现场演示这两种方式。

在现场进行代码走查，必须成立代码走查小组，小组成员的构成而言，一般由三至五人组成，其中一人扮演“协调人”，一人担任秘书角色，负责记录所有查处的错误，还有一人担任测试人员。

采用走查的过程：

n需求分析过程中，系统分析员、系统架构师相互之间的走查；

n设计过程中，系统分析员、系统架构师相互之间的走查；

n在进入维护阶段时，作者需和维护人员进行走查，让维护人员能够维护作者的工作产品。

4.1.2实施代码走查会议步骤

输入：

待检查的工作产品（代码、测试数据等）入口条件：

代码编写完毕

步骤：

（1）选择评审参与者，确认他们同意参与评审，安排走查会议时间；

（2）在会议之前分发工作产品给评审者；

（3）在会议期间，以适当的方式向评审者描述工作产品；

（4）向创建者表示评论，可能的缺陷和改进建议；

（5）基于评审者的评论，对工作产品执行必要的返工。

交付产品：

经过修改的工作产品

出口条件：

已经对工作产品做了恰当的修改

4.2四眼评审

四眼评审，顾名思义，四眼即为2个人面对面（评审者与工作产品创建者）就对所创建的工作产品进行非正式的评审，介于正式的同行评审和走查之间，可用于正式同行评审之前，达到尽早发现问题。

采用四眼评审的软件过程主要包括：

对客户需求的评审、项目计划的评审和维护计划的评审。

n对客户需求的评审参加人员有项目经理、系统分析员、系统架构师、质量部主管等。

n项目计划的评审主要由项目经理、系统分析员、系统架构师、质量部主管和部门经理等参加，对人力资源、进度和质量管控等进行评审。

n维护计划由项目经理、技术支持人员、质量部主管和客户服务人员参加，对人力资源、管控流程等进行评审。