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、检查报告被移交给质量管理部门。
