1 说明

1.1 简介

• 评审是一种正式的评估技术；
• 评审需详细考查软件需求、设计、编码等，以便发现缺陷、违反开发标准的情况或其它问题。

1.2 评审的目的

• 验证软件是是否否和规范；
• 验证软件是否达到应用标准；
• 对产品质量和过程质量，建立附带的和结构化的改进方法。

1.3 评审说明

• 评审过程中的缺陷和其它缺陷一样，根据严重性进行修改；
• 评审需在动态测试之前就开始；
• 准备阶段是评审的最重要阶段；
• 召集原因分析会议可以提升评审的价值；
• 组织检查的那个人必须有某种程度的独立性。

1.4 评审的优点

• 早期发现缺陷，解决成本低；
• 发现缺陷的比例比较高；
• 团队成员之间可以交换信息；
• 不止针对设计文档，还有开发过程和测试过程所交付的所有文档；
• 评审能够激励对于开发高质量产品的认识和动力。

2 规程

2.1 入口检查

• 对输入标准对产品入口进行检查；
• 其中输入标准的例子有以下：

1、产品必须完成；
2、参考文档必须是被任何的文档；
3、参考文档必须是正确的和最新的；
4、由主持人最初进行的快速检查，发现的缺陷应当不多于X个；
5、文档必须经过拼写检查；
6、文档是符合标准的文档。

2.2 组织评审

• 组织人员进行评审，必须组成一个团队，为每个成员分配角色；
• 成员分配的角色必须是与其兴趣和专业相关；
• 角色的例子如下：

1、用户：关注用户和客户的观点；
2、测试人员；关注可测性；
3、系统：关注广泛的系统问题；
4、质量：关注质量特性的各个方面；
5、服务：关注服务、维护、供应和安装。

2.3 开始

• 基于以下原因可组织开始会议（非必须）：

1、当从事评审的成员没有评审经验时，主持人可简要介绍评审技术、以及各成员的角色；
2、对于复杂产品，产品的作者对产品进行介绍，帮助大家理解产品；
3、评审规程发生改变，可以启动开始会议告诉大家。

2.4 准备

• 就是发现缺陷；
• 从成员的角色出发来评审产品；
• 记录发现的缺陷。

2.5 缺陷登记会议

• 目的是发现新的缺陷和交流知识；
• 主持人：列出所有缺陷；
• 产品作者：将所有缺陷记录在一份报告中；
• 不太重要的缺陷和解决方案可以不在会议上讨论；
• 会议限制在2小时以内。

2.6 原因分析会议

• 在一种建设性分氛围中开展；
• 最好以一种头脑风暴式的会议举行；
• 重点是查找缺陷根源，而不是缺陷本身。

2.7 修改

• 产品作者组织修改，并做变更记录；
• 更新后的文档交付给主持人。

2.8 后续工作

• 支持人必须检查是否已经解决了所有的缺陷；
• 但不检查缺陷是否被正确的解决；
• 将文档交付给能够检查缺陷是否正确解决的成员。

2.9 检查输出标准

• 例子如下：

1、修改工作必须完成；
2、新的文档符合配置管理；
3、按照规程来处理相关文档的变更请求；
4、检查报告被移交给质量管理部门。