第6章 软件评审

---

在开发过程中，评审可以让我们获得以下收益：

• 提高项目的生产率。这是由于早期发现了错误，因而减少了返工时间，还可能减少测试时间。改善软件的质量。在评审过程中，使开发团队的其他成员更熟悉产品和开发过程。
• 通过评审，标志着软件开发的一个阶段的完成。
• 生产出更容易维护的软件。主要原因是：对于被评审的软件，评审者必须是非常熟悉的；同时，在评审过程中，一定会产生并利用很多证明文档，于是评审就迫使开发者产生出许多有用的文档，评审过程也将增加对所开发软件的理解。

6.6 软件评审的角色

1. 评审组长（Moderator）
2. 宣读员（Reader）
3. 记录员（Recorder）
4. 作者（Author）
5. 评审员（Reviewer、Inspector）

评审员主要职责：

• 熟悉评审内容，为评审做好准备。
• 在评审会议上应该关注问题而不是针对个人。
• 主要的问题和次要的问题可以被分别讨论。
• 在会议前或者会议后可以就存在的问题提出建设性的意见和建议。
• 明确自己的角色和责任。
• 做好接受错误的准备。

6.7 评审的内容

6.7.1 管理评审

  管理评审：最高管理者为评价管理体系的适宜性、充分性和有效性所进行的活动。

  管理评审原因：能更好的进步和发展。为了达到这个目的，通常需要对原来的发展状况进行回顾，分析并总结出存在的问题和改进的措施。

  管理评审主要内容：组织的最高管理者就管理体系的现状、适宜性、充分性和有效性以及方针和目标的贯彻落实及实现情况进行正式的评价，其目的就是通过这种评价活动来总结管理体系的业绩，并从当前业绩上考虑找出与预期目标的差距，

  管理评审目的：适宜性；有效性；充分性

管理评审的输入 ：

• 期内、外审的评审结果；
• 顾客信息反馈；
• 相关方关注的问题；
• 工作业绩与存在的问题；
• 纠正与预防措施实施情况；
• 上次管理评审有关决定和措施的执行情况；
• 可能影响管理体系变更的情况
  （如：法律、法规的变化，组织机构或产品、活动的变化、外部环境的变化等）；
• 管理方针、目标和指标的适宜性及其实现情况。

管理评审的输出 （结果通常为《管理评审报告》）：

• 管理评审的目的、时间、参加人员及评审内容；
• 管理体系及过程的适用性、充分性、有效性的综合评价和需要的改进；
• 管理方针、目标、指标适宜性的评价及需要的更改；
• 资源需求的决定和措施；
• 管理评审所确定的改进措施、责任部门和完成日期。

管理评审流程 ：

6.7.2 技术评审

  一组评审者按照规范的步骤对软件需求、设计、代码或其他技术文档进行仔细的检查，以找出和消除其中的缺陷

1. 技术评审的目的
   发现软件在功能、逻辑、实现上的错误；
   验证软件符合它的需求规格；
   确认软件符合预先定义的开发规范和标准；
   保证软件在统一的模式下进行开发；
   便于项目管理。
2. 技术评审的输入
   评审的目的是说明为什么要进行该评审，该评审的实施目的是什么；
   评审的内容包括需求文档、源代码、测试用例等；
   评审检查单（检查项）；
   其他必须的文档，如对设计文档进行评审，那么需求文档可以作为相关文档带入技术评审会。
3. 技术评审的输出——技术评审报告
   会议的基本信息；
   存在的问题和建议措施；
   评审结论和意见；
   问题跟踪表；
   技术评审问答记录（通常作为附录出现在报告中）。

6.7.3 文档评审

1. 文档评审的目的：在软件开发的各个阶段对该阶段形成的文档进行评审，尽早发现问题，并及时采取措施予以解决，确保文档的内容准确，为软件产品的质量提保障。
2. 文档评审的内容
   在软件开发过程中，需要进行评审的文档很多，主要包括如下内容：
   需求评审，对《市场需求说明书》、《产品需求说明书》、《功能说明书》等进行评审。
   设计评审，对《总体设计说明书》、《详细设计说明书》等进行评审。
   代码评审，对代码进行审核。
   质量验证评审，对《测试计划》、《测试用例》等进行评审。

6.7.4 过程评审

  对软件开发过程的评审，主要任务是通过对流程的监控保证SQA组织定义的软件过程在项目中得到了遵循，同时保证质量保证方针能得到更快、更好的执行。

1. 过程评审的作用如下：
   评估主要的质量保证流程。
   考虑如何处理和解决评审过程中发现的不符合问题。
   总结和共享好的经验。
   指出需要进一步完善和改进的部分

2. 过程评审流程
   

6.8 评审的方法和技术

6.8.1 评审的方法

• 特别检查（Ad hoc review）
• 轮查（Pass Around）
• 走查（Walkthrough）
• 团队评审（Group Review）
• 检视（Inspection）
  
  检视、团队评审和走查异同点比较表：
  

6.8.2 评审的技术

• 缺陷检查表
• 规则集
• 评审工具的使用
  Gerrit
  Jupiter
  SourceMonitor
• 从不同角度理解产品
• 场景分析技术

6.9 评审会议流程

6.9.1 准备评审会议

  在评审会议开始之前，评审组长需要发出评审通知（评审内容、会议时间、会议地点、参加人员等），并且将相关待评审的相关资料也发送给参加会议的评委。

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

评审会议召开时间点：进行评审会议准备时，首先，要确定的是召开评审会议的时间。

通常如下材料需要被打包分发：

• 需要评审的部分可交付产品和文档；
• 定义了可交付产品的前期文档；
• 评审会议成员需要的所有表格；
• 有助于评审员发现缺陷的工具和文档，如缺陷检查表、规则集等；
• 用于验证可交付产品的测试文档。

6.8.2 召开评审会议

• 评审预备
  评审开始
  成员介绍
  评审员进行演示或说明
  评审员就不清楚或疑惑的地方与作者进行沟通
  记录员在会议过程中完成会议记录
• 评审决议
• 评审结束
• 评审中应把握的几个原则

6.8.3 跟踪和分析评审结果

• 跟踪
  有条件接受的缺陷跟踪
  不接受的缺陷跟踪
• 分析
  有效性
  效率和成本