1.目的
定义通用的评审方案,以控制评审活动的有效性,确保尽早发现问题,从而有效降低成本,减少返工,缩短项目周期,提高文档质量。
2.范围
适用于文档的评审工作。
3.术语定义
序号 | 术语 | 定义 |
1 | 评审 | 本文描述的评审即同行评审,是指软件工作产品作者的同行们按一定规则检查该工作产品,识别产 品的缺陷,改进产品的不足,跟踪缺陷的状态的过程。 |
2 | Checklist | 评审检查要素表。为每一类工作产品配备相应的评审检查要素表。其内容包括规范性、完整性、一致性、正确性等维度的检查要素 |
4.角色和职责
序号 | 角色 | 角色职责 |
1 | 材料作者 |
|
2 | 评审组织者 |
|
3 | 评审组组长 |
|
4 | 评审组成员 |
|
5 | 评审检查人 |
|
5.评审流程说明
5.1·总体说明
根据评审对象不同,将评审流程划分为三种类型,如下:
- 正式评审:需要进行事前准备,严格定义评审流程。操作方法:事先进行充分的预评审,并记录发现的缺陷,再召开会议进行评审,评审要求出具评审报告,并跟踪缺陷至关闭。
- 会议评审:不需要进行预评审,直接召开评审会议,会议现场提出问题。如果是对工程类文档进行会议评审,评审发现缺陷使用评审报告跟踪至解决;如果是对非工程类文档进行会议评审,发现的问题使用会议纪要跟踪至关闭。
- 邮件评审:评审人员将问题以批注的形式反馈给作者,作者修改完毕由检查人进行检查。不需要召开会议,不需要对评审进行统计分析,不需要产出评审报告。
三种评审方式的比较如下表:
评审方式 | 正式评审 | 会议评审 | 邮件评审 |
适用评审对象 | 工程类关键文档 | 非工程类文档或工程类的非关键文档 | 非工程类文档 |
是否需要预评审 | Yes | No | No |
是否需要召开会议 | Yes | Yes | No |
是否需要输出评审报告 | Yes | No(如果评审对象为工程类文档此处为Yes) | No |
是否需要对缺陷和问题进行跟踪 | Yes | Yes | Yes |
适用对象建议 | 需求规格说明书、概要\详细设计说明书、数据库设计说明书、界面原型、测试用例、测试方案分析等 | 项目计划、项目总结等 EPG相关文档 | 用户手册、发布文档等 |
5.2正式评审流程
5.2.2 准入条件
评审计划表时间已到达,评审文件已完成。
5.2.3 流程活动说明
序号 | 活动名称 | 活动描述 | 主要输出产物 | 支撑流程/规范 | 责任人 |
1 | 自检并修改 |
| 自检后的文档 《评审报告-自检签字表》 | 各种过程产品对应的《checklist》、 《评审报告-自检签字表》模板 | 材料作者 |
2 | 内部评审 |
| 内部评审通过的文档 |
| 评审组织者 |
3 | 发起评审 |
| 评审通知邮件 准备会议室 | 评审通知邮件模板 | 评审组织者 |
4 | 预评审 |
| 预评审意见记录邮件 |
| 评审组成员 |
5 | 收集并汇总预评审意见 |
| 《评审缺陷跟踪汇总表》(预审意见汇总) 更新后的评审计划 | 《评审报告-评审缺陷跟踪汇总表》模板 | 评审组织者 (参与人:材料作者) |
6 | 召开评审会 |
| 《评审报告-评审缺陷跟踪汇总表》 | 《评审报告》模板 | 评审组织者、评审组组长、评审组成员、材料作者 |
7 | 记录评审问题 |
| 《评审报告》 《会议纪要》 | 《评审报告》模板 《会议纪要》模板 | 材料作者 |
8 | 是否需要复评 |
|
|
|
|
9 | 纠正问题后重新申请评审 |
| 待重新评审的文档 《评审报告-评审缺陷跟踪汇总表》 |
| 材料作者 |
10 | 纠正问题 |
| 根据评审意见修改后的文档 《评审报告-评审缺陷跟踪汇总表》 |
| 材料作者 |
11 | 检查纠正结果 |
| 《评审报告-评审缺陷跟踪汇总表》 |
| 评审检查人 |
12 | 闭合评审报告 |
| 《评审报告》 评审通过的文档 |
| 评审检查人 |
5.2.4准出条件
评审通过,配置管理员依据闭合的《评审报告》,将对应的评审对象形成一个基线版本,存放于基线库,闭合评审。
5.3 会议评审流程
5.3.1会议评审流程图
5.3.2准入条件
评审计划表时间已到达,评审文件已完成。
5.3.3流程活动说明
序号 | 活动名称 | 活动描述 | 主要输出产物 | 支撑流程/规范 | 责任人 |
1 | 自检并修改 |
| 自检后的文档 《评审报告-自检签字表》 | 各种过程产品对应的《checklist》、 《评审报告-自检签字表》模板 | 材料作者 |
2 | 内部评审 |
| 内部评审通过的文档 |
| 评审组织者 |
3 | 发起评审 |
| 评审通知邮件 准备会议室 | 评审通知邮件模板 | 评审组织者 |
4 | 召开评审会 |
| 《评审报告-评审缺陷跟踪汇总表》 | 《评审报告》模板 | 评审组织者、评审组组长、评审组成员、材料作者 |
5 | 记录评审问题 |
| 《评审报告》 《会议纪要》 | 《评审报告》模板 《会议纪要》模板 | 材料作者 |
6 | 是否需要复评 |
|
|
|
|
7 | 纠正问题后重新申请评审 |
| 待重新评审的文档 《评审报告-评审缺陷跟踪汇总表》 |
| 材料作者 |
8 | 纠正问题 |
| 根据评审意见修改后的文档 《评审报告-评审缺陷跟踪汇总表》 |
| 材料作者 |
9 | 检查纠正结果 |
| 《评审报告-评审缺陷跟踪汇总表》 |
| 评审检查人 |
10 | 闭合评审报告 |
| 《评审报告》 评审通过的文档 |
| 评审检查人 |
5.3.4 准出条件
评审通过,配置管理员依据闭合的《评审报告》,将对应的评审对象形成一个基线版本,存放于基线库,闭合评审。
5.4邮件评审流程
5.4.1邮件评审流程图
5.4.2准入条件
评审计划表时间已到达,评审文件已完成。
5.4.3 流程活动说明
序号 | 活动名称 | 活动描述 | 主要输出产物 | 支撑流程/规范 | 责任人 |
1 | 自检并修改 |
| 自检后的文档 | 各种过程产品对应的《checklist》 | 材料作者 |
2 | 发起评审 |
| 评审通知邮件 | 评审通知邮件模板 | 材料作者 |
3 | 评审反馈 |
| 评审反馈邮件 |
| 评审组成员、材料作者 |
4 | 纠正问题 |
| 根据评审意见修改后的文档 |
| 材料作者 |
5 | 检查纠正结果 |
|
|
| 评审检查人 |
6 | 闭合评审 |
|
|
| 评审检查人 |
5.4.4 准出条件
评审组检查通过,评审对象存放于SVN指定目录,闭合评审。
6.评审原则
- 评审文档,而不是评审生产者:
评审涉及到别人和自我。如果进行的恰当,可以使所有参与者体会到温暖的成就感。如果不恰当,则可能陷入审问的气氛之中。应当温和的指出错误,会议的气氛应当是轻松和建设性的;不要试图贬低或者羞愧别人。评审组织人应当加以引导,以保证会议始终处于恰当的气氛和态度中,如果失去控制应立即休会。
- 制定日程,控制会议时间:
评审会议必须保证不要离题和按照计划进行。评审组织人要有维持会议的程序和控制会议进度的责任,有人在转移话题的时候应当提醒。
- 限制争论和辩驳:
评审人员提出问题时,未必所有人都能认同该问题的严重性或者能马上达成一致的意见。不要花费时间争论这一问题,应当记录在案,留会后讨论。
- 对各个问题发表见解,但是不要试图解决所有记录的问题:
评审会议不是解决问题的会议。问题的解决由生产者自己或者在其他人的帮助下完成。问题的解决方案应当在会后进行。
- 做书面笔记:
让评审记录人做书面笔记,在记录的时候,评审人员可以推敲措词,确定问题的优先次序,并宣读记录,以确认正确记录了问题。
- 限制参与人数,并且坚持事先做准备:
将评审涉及的人员数量保证保持在最小的值上,避免人员过多,但未起到实际效果,反而使会议更难管控。所有参与会议的人员要事先作好准备。
- 为每个可能要评审的文档建立一个检查表:
检查表能帮助评审组织人组织会议,并帮助每个与会人员将注意力集中在重要问题上。
- 为评审分配资源和时间:
评审要占项目组的资源和时间。所以,评审会议一定要作为软件工程活动的任务加以调度。一定要在制定计划时考虑进去。
- 对所有的评审者进行培训:
为了提高效率,所有参与评审会议的人都应当接受过正式的培训。熟悉评审流程及评审注意事项。且各级主管不能以管理者身份而只能以评审人员的身份参加评审。