评审

1、评审的必要性

2、评审过程活动

• 评审是一种过程活动，它分为正式技术评审和非正式技术评审。
• 评审分为三个阶段：初审、复审、终审
• 评审要有预审、问题列表、跟踪过程
• 评审最终要得到批准
• 形成正式文件
• 进入配置管理
• CMM/ISO9000规范

3、软件评审定义

软件评审：是对软件工程过程任意阶段产生的任意正式工件进行的评审活动。评审贯穿于软件过程中的所有阶段，是软件工程过程中的“过滤器”，起到发现问题、排除错误的作用，它使得以相对较小的成本发现及排除错误成为可能。

正式技术评审（FormalTechnical Review, FTR）

• (1) 发现功能、逻辑或实现的错误
• (2) 证实经过评审的软件的确满足需求
• (3) 保证软件的表示符合预定义的标准
• (4) 得到一种一致的方式开发的软件
• (5) 使项目更易管理

同行评审：同行评审的对象一般是部分软件工作产品，其重点在于发现软件工作产品中的缺陷。所谓同行是指和生产者在被评审的软件工作产品上有相同的开发经验和知识的人员。一般来讲，不建议管理者作为同行参与同行评审。 

4、评审方式

正式技术评审

正式技术评审都是以会议评审方式，就是组织内外的专家召开评审会议，根据评审的内容和要求进行讨论、分析并就最终结果达成一致的评审方式。软件需求、软件设计、测试大纲需要进行会议评审。

非正式技术评审

非正式技术评审一般是以邮件评审，就是通过发送邮件给项目相关人员进行的评审方式。或者招开内部小型讨论会方式．通常项目开发计划等需要邮件评审。

5、评审结果

• 有条件通过:则需要说明什么条件（比如修改某某东西），下次就不用再开评审会了,作者修改完成后，发邮件给相关人员，多长时间内评审员要使用邮件回复评审意见，由组织者负责收集。
• 通过: 不需要再进行评审.
• 不通过:如果是不通过，还要再次评审(复审)

6、关于评审问题

评审什么？

• 需求评审——《软件开发需求》、《测试需求》
  需求表现在具体业务逻辑应用上，业务逻辑评审实际上是评审单元模块的功能，这些功能是以《用例规约》、《词汇表》、《补充用例规约》等工件为基础的。评审人员要有相关行业经验并且要对即将实现的系统有所远见。评审人员通过对各种参与评审工件的静态检查，来确定需求是否覆盖了最终客户的要求。
• 设计评审——《概要设计》、《详细设计》、《测试用例》
  进行程序设计和结构的评审是排除因为开发工具的使用错误和项目时间的限制而造成设计不详细，比较深入的设计评审表现为对设计UML的静态检查，由于设计人员的经验不同，所以设计评审中往往会暴露出很大的问题。评审人员要有相关的专业知识，最好在评审前准备一份审核列表，列出关键检查项目，如详细设计、设计生命周期等。但仅局限于列表是不够的，评审人员还要客观评审设计的精巧程度和创造性，这部分工作只能依靠于经验。
• 代码评审——《代码规范》
  代码风格和规则的审核是在每个程序员完成一个功能模块或类的时候要进行编码规范的检查。要召开审核会议让所有的项目组人员都参加，在会前制做一个检查表（以表的内容为检查依据），检查表的内容主要是检查的要点，比如类首字母、常量运用等。
• 贯穿软件过程各个阶段的正式工件

什么时候评审？

以什么形式评审？

评审前准备什么？

由什么人参加？

会议形式如何？

7、评审误区

• 参与人员不了解评审。

评审参与者拒绝参加评审，他们觉得这样做是在浪费时间，这是因为大家看不到做这件事情的任何效果，感觉到很迷茫，所以这样的情况严重影响了大家参与评审的积极性。危害指数最高，并且在各个项目组中比较常见。

• 评审目标偏移。

评审的主要目的是发现产品中的问题，而不是根据产品来评价开发人员的水平。但是往往会出现把产品质量和开发人员水平联系起来的事情，于是评审变了“味”，变成了“批斗大会”极大的打击了开发人员的自尊心，以至严重的影响了评审的效果。

• 评审没有被安排进项目开发计划。

参与评审需要投入大量的时间和精力，应该被提前安排到项目计划中。我经常碰到这样的情况，项目经理不太遵守评审的相关规则，往往是在自己完成工作的情况下才会递交评审请求。这样参与评审人员非常被动，必须加班加点才能完成任务。危害指数最高，并且在各个项目组中比较常见

• 评审会议变成了问题解决方案讨论会。

评审会议主要的目的是发现问题，而不是解决问题，问题的解决是评审会议之后需要做的事情。实际上，评审会议聚集了大量的技术人员，大家出于对技术的追求和解决现有工作处理方式，致使评审会议往往变成了问题研讨会，浪费了宝贵的评审时间，导致大量评审内容被忽略，留下无数的隐患。危害指数较高，这种情况比较常见。

• 评审人员事先对评审工件没有足够了解。

任何一份评审材料都是他人智慧和心血的结晶，需要花足够的时间去了解、熟悉和思考。只有这样，才能在评审会议上发现有价值的深层次问题。在很多的评审中，评审人员因为各种的原因，在评审会议之前对评审材料没有足够的了解，于是出现了评审会议变成了读文档的怪现象。危害指数较高，这种情况比较常见。

• 评审人员关注于非实质性问题。

在评审中，评审人员过多的关注于一些非实质性的问题，比如文档的格式、措词、语句等，而不是关注于产品的设计。出现这样的情况，可能的原因有：没有选择合适的人参与评审或者评审人员自身专业素质不过关，无法发现深层次的问题。危害指数中等，这种情况比较常见

• 忽视组织细节。

在组织评审的过程中，很多人不太注意细节。比如会议时间的设定，会议的通知，会议场所的选择，会议设施的提供等，我碰到过这种情况——组织者慌慌张张地去借投影仪的现象。危害指数较高，这种情况比较常见

• 会议时间过长。

这是一条血的教训，我们发现评审会议的时间最好不要超过2小时，如果拉长时间继续开会，你会发现大家已经是死气沉沉、毫无活力，这个时候的会议已经成为标准故事会了。危害指数中等，这种情况比较常见

8、评审流程图

9、评审参与角色

• 协调员。确保评审按议程进行，并以当前的主题为重点。协调员应该确保对枝节问题的讨论不会使评审脱离正轨，而且所有评审员都以平等的身份参加讨论。
• 记录员。经常被忽略，但却是评审团队中必不可少的部分。其专职任务是记录所讨论的内容和要采取的行动。将此任务分配给某个评审员，实质上是使其置身于讨论之外。然而，更糟的是，如果没有记录下所决定的事情，就很可能会导致将来再次发生该问题。确保指定一位记录员，并保证这是此人所扮演的唯一角色。
• 介绍员。是评审工件的生产者。介绍员解释工件和理解工件所需的所有背景信息（如果工件不是无需解释的，可能需要做一些工作）。重要的是，评审不能变成“审讯”，因为评审的重点是工件，而不是介绍员。协调员的作用是确保与会者（包括介绍员）记住这一点。讨论开始，介绍员首先发言，回答问题并提供解释说明。
• 评审员。提出问题。一定要侧重于提出问题，而不要耗费大量精力讨论如何解决问题。注重结果，而不是方法。

10、评审 - 计划

• 评审之前，对提出的问题确定评审范围，项目负责人在提交的《项目开发计划》中，要指明项目各个阶段的评审计划。范围确定的小，发现问题越集中。具体内容包括：各个阶段评审时间、评审方式、评审组成员等。
• SQA在其提交的《质量保证计划》中，应根据《项目开发计划》中描述的各个阶段评审计划，制定相应的评审检查点。
• 评审参与者的数目应该大约为3~7个。如果评审参与者的数量大于7个，实际上会因为会议时间过长、参与更困难，以及在评审过程中增加了枝节问题和讨论，而降低评审的质量。如果评审人员少于3个，则会因为减少了问题的多样性而增加片面性的风险。

11、评审 – 形式

12、评审－准备

1）、组建评审组

• 项目组提出评审组长和评审组成员名单的建议，质量组根据项目组的建议，与相关部门或人员（如外项负责人）进行协商确定。
• 评审组成员一般包括：被评审产品项目组负责人（项目组负责人非被评审产品作者的情况）、与该项目有关的开发组成员、质量保证人员、测试人员、前一阶段技术骨干、后一阶段技术骨干等

2）、提交评审材料

• 被评审产品作者需要准备好待评审的产品、评审意见表和检查表。
• 待评审的产品可以是需求规格说明书、设计说明书、代码、测试大纲等。
• 评审意见表。
• 检查表随评审对象的不同而不同，分为：需求规格说明书检查表、设计说明书检查表、代码检查表、测试大纲检查表四种。
• 被评审产品作者将待评审产品以邮件的方式发送给评审组长，评审组长将收到的待评审产品附上评审意见表和检查表，以邮件方式发送给所有评审组成员。

3）、 评审意见的处理

• 评审组成员收到评审材料后，审查待评审产品，填写评审意见表。并在2工作日内，将评审意见表以邮件的方式发送给被评审产品作者。
• 被评审产品作者解决评审提出的问题，修改被评审产品并填写评审意见表的“处理办法”一栏，在2工作日内以邮件的方式回复给相应的评审组成员。
• 评审组成员根据修改后的被评审产品和项目组填写的“处理办法”进行反馈，填写“是否已改正”一栏，在1工作日内以邮件的方式将反馈后的评审意见表发送给被评审产品作者、评审组长、SQA人员。

13、评审 – 执行

• 评审会议将从协调员介绍会议日程开始，再由生产者对工件作出简单的介绍，接下来进行的是一个重复进行的循环过程：评审者根据各自的准备提出问题，生产者作出解释，当发现问题或错误时，记录员逐个加以记录。
• 工件产品可以不经修改而被接受。
• 暂时接受工件产品（发现必须改正的微小错误，但是不再需要进一步评审）。
• 由于严重错误而否决工件产品（错误改正后必须再次进行评审）。

14、评审 – 执行注意事项

• 评审产品，而不是评审生产者。FTR涉及到别人和自我，如果进行得恰当，FTR可以使所有参与者体会到温暖的成就感。如果进行得不恰当，则可能陷入一种审问的气氛之中，应该温和地指出错误，会议的气氛应该是轻松的和建设性的，不要试图贬低或羞愧别人。评审协调员应该引导评审会议，以保证会议始终处于恰当的气氛和态度之中，并在讨论失去控制时立即休会。
• 遵守日程。各种类型的会议都具有一个主要缺点：放任自流。FTR必须保证不要离题和按照计划进行。评审协调员被赋予维持会议程序的责任，在有人转移话题时应该提醒他。
• 限制争论和辩驳。在评审者提出问题时，未必所有人都认同该问题的重要性。不要花时间争论这一问题，这样的问题应该被记录在案，留到会后进一步讨论。
• 对各个问题都发表见解，但是不要试图解决所有记录的问题。评审不是一个问题解决会议。问题的解决通常由生产者本人或其他人的帮助下来完成。问题解决应该放到评审会议之后进行。
• 作书面笔记。有时候让记录员在黑板上做笔记是个好主意，这样在记录员记录信息时，评审员可以推敲措辞，并确定问题的优先次序。
• 为每个可能要评审的工件产品建立一个检查表。检查表能够帮助评审协调员组织FTR会议，并帮助每个评审员将注意力集中在主要问题上。应该为分析、设计、编码，甚至测试文档都建立检查表。

15、评审 -报告和问题跟踪

• 在评审会议结束时，记录员要完成一份简单的“评审总结报告”，此外，还要在会后整理所有被记录的问题生成一份“评审问题列表”，评审总结报告包括以下内容：评审内容、评审人员、工件生产者以及评审结论。
• 评审问题列表则有两个作用：⑴ 标识工件中存在的问题，⑵ 用作“行动条目”检查表以指导生产者进行改正。在通常情况下，评审问题列表作为一个附件附加于评审总结报告之后。