CMMI5文档之评审规程

评审规程

文档编号：FHI_CMMI_VER_PRD_SYN

文档信息：评审规程

文档名称：评审规程

文档类别：CMMI规程

密级：内部秘密

版本信息：1.2

建立日期：2016-1-5

创建人：EPG

批准人：李庆林

批准日期：2016-2-25

存放位置：集成公司组织资产库/组织标准过程编辑软件：Microsoft Office 2003 中文版

文档修订记录

目录

s

1.简述 (4)

1.1.目的 (4)

1.2.适用范围 (4)

1.3.术语表 (4)

2.概述 (4)

3.同行评审过程说明 (6)

3.1.正式评审 (6)

3.2.技术评审 (9)

3.3.走查 (10)

3.4.审批 (11)

3.5.审阅 (11)

3.6.邮件评审 (11)

4.分析评审结果 (11)

5.同行评审验证准则 (11)

5.1.同行评审严重程度定义 (11)

5.2.同行评审不通过的准则 (11)

6.QA评审/审计 (12)

7.CM审计 (12)

1. 简述

1.1. 目的

本规程的目的是为了定义在软件生命周期内不同的评审类型，确定评审的时机和评审的一般流程，并规定各项评审的主要内容、入口、出口和评审人员等。

1.2. 适用范围

本规程适用于本公司的所有软件项目。

1.3. 术语表

无

2. 概述

软件生命周期内的评审分为三类：同行评审、QA 评审和审计、CM 审计，如下图所示：

(

经验人员或客户代表CM 人员

QA 人员相关人

员

:

图表 1 评审分类

正式评审活动评审的一般是比较重要的或具有里程碑意义的工作产品。正式评审的目的既是为了发现被评审项的缺陷，也是对重要工作产品的质量验证。评审的结果(通过或不通过)标志着项目是否进入下一个开发阶段。因此，项目评审具备一定意义上承诺的意味。

同行评审是在软件开发过程中按照明确定义的过程对工作产品进行系统检测的方式之一，同行评审分为技术评审、走查两种方式。

技术评审、走查由一组与软件工作产品的作者处于同一级别的、具有类似工作（技术）经验的技术人员来进行。技术评审和走查是作业过程中不可缺少的部分，使得缺陷能及早排除，产生较高的生产率和高质量产品。技术评审和走查关注的是被评审的软件工作产品本身，而不是软件工作产品的作者。与软件工作产品的作者相关的管理人员不应参加技术评审和走查，因为相关的管理人员参加技术评审和走查可能会妨碍评审人提出问题或发现缺陷。技术评审和走查的结果也不应作为管理人员评价个人工作业绩的依据。

●正式评审的特点：

高层经理通常被邀请参加。

评审对象可是技术工作产品也可是管理工作产品。

重点在于识别问题，不是解决问题。

要给评审做出结论。

●正式评审和技术评审及走查的区别：

正式评审中，软件工作产品或软件工作产品集要交给管理人员、客户、最终用户或其他相关人员，以征得他们的认可或同意。正式评审一般在任务完成后进行。

技术评审及走查中，软件工作产品或软件工作产品集提交给软件开发单位的同行，以发现其中存在的缺陷。管理人员、客户和最终用户一般不参与技术评审及走查，技术评审

及走查是不可缺少的任务。

有些软件工作产品需要经过正式评审，有些则需要经过技术评审及走查，而还有一些两者都需要。

根据评审对象的性质及项目的重要程度，可选择正式评审、技术评审、走查、审批、审阅、非正式评审六种方式进行评审活动。五者的区别如下：

3.同行评审过程说明

3.1.正式评审

3.1.1.概述

正式评审由项目组或质量管理部的人员进行组织，由遵守明确定义过程的一组人员对软件工作产品以召开评审会的方式进行的评审。其特点是：

●评审人事先进行准备，并在评审会议开始前确定其关注的内容和问题。

●记录评审数据，并用于监督评审过程的效果。

●整个过程是为参与者定义好角色的结构化过程。

3.1.2.优缺点

●优点

以经济的方式发现缺陷。在软件生命周期早期产生的产品中注入的缺陷，可以尽早发现，而不会导致以后发现缺陷所需的高额成本。

有效利用人力资源，即使有些人没有安排在项目中。

有助于建设团队精神，培养参与感和认同感。

评审人和作者通过该过程，对缺陷及其类型有了更多的认识，可以有效减少以后对该类产品的缺陷注入率。

若某工作产品的负责人中途退出，其它人员由于较早了解了该产品和退出人的思想，可以最大化地减少由于人员变动带来的损失。

●缺点

需要许多人花费时间来准备和参加评审会议。

安排评审会议也需要相关开销。

3.1.3.适用范围

重要的或非常复杂的工作产品需要进行公司正式评审，如：《软件需求规格说明书》、《用户需求说明书》、《项目计划》、《概要设计》或需要提交给用户的工作产品。

3.1.

4.参与人员

●作者：

不能作为主持人，尽量不要充当宣读人。

评审前准备工作产品和相关资料。

保持客观，避免防御。

快速确定是否是问题。

根据评审结果，积极修改原先的工作产品。

●主持人：

尽量不要充当宣读者。

安排、组织评审会议。

评审前与评审人积极沟通，发放材料。

评审开始时，检查评审人的《评审准备表》。

确保会议一直关注的是识别缺陷这个任务。

完成《评审报告》。

●评审人：

评审前，认真准备。

评审中不要关注解决方案。解决方案可以在评审结束后与作者交流。

积极参与问题的讨论和提出问题的解决建议，可以随时打断会议。

●宣读者：

逐行宣读产品，以便评审人更好的理解产品。

控制评审的速度。

●记录员：

在评审中，在《评审报告》中记录确认的问题。

●跟踪人：

由评审会议最后指定，负责跟踪问题的解决情况。

跟踪人不能是作者。

●软件工程组：进行项目评审。

●其他评审人员：必要时，请高层经理、客户代表参加。

3.1.5.入口准则

●待评审的工作产品已完成。