3-技术评审过程-K解读

3.1 什么是同行？
项目组内外的工程技术人员
项目经理 业务师 开发人员 （分析、设计、实现） 测试人员 质量保证人员 其它技术人员 其它技术专家 总体部人员 项目经理 业务师 开发人员 （分析、设计、实现） 测试人员 质量保证人员
评 审 员
项目组A
项目组B
3.2 同行评审参加人员
选择评审员应遵循如下原则：
技术评审过程
2008-2-18
培训目标
1.
了解技术评审的大致过程（公司的要求）
2.
对于项目经理：
了解如何制定技术评审计划；


了解针对何种工作产品应该采用何种评审方式；
了解如何组织同行评审、走查；

了解如何组织代码复查；
课程内容
1. 技术评审简介 2. 技术评审分类 3. 同行评审 4. 走查及代码复查 5. 表单模板及实例
详细设计文档 源代码 测试方案、案例
项目成员 项目成员 …
组内同行评审 代码复查 组内走查
课程内容
1. 技术评审简介
2. 技术评审分类 3. 同行评审 4. 走查及代码复查 5. 表单模板及实例
什么工作产品进 行同行评审？
问题？
•什么是同行？同行有哪些？
同行包括工作产品作者的同类角色人员和 该工作产品的上下游工作产品的作者等人 员。例如，《功能分析说明书》的同行包 括客户、客户代表、需求、设计、实现等 人员。
5. 表单模板及实例
2.1 技术评审分类
技术评审（TR）的三种评审方式： 软件中心分类方法 同行评审（Peer Review） 走查（Walkthrough） 代码复查（Code Review）
业界有不同的分法，内容大致一致 TR：FTR、ITR PR：Inspection、Walkthrough
同行评审 会议 （正式） 要求充分准备并输 出个人准备问题单 评审组长 评审员 记录员 验证员 作者 走查 会议或非正 会前尽量充分准备 组织者 走查记录 不需要。 评审报告 是。有三种评审 结论。
式形式
（非正式） 代码复查 会议或非正 会前尽量充分准备
评审员
作者 复查人员
单Βιβλιοθήκη Baidu
代码复查
不需要。
式形式
（非正式）
需求分析文档
总体设计文档 详细设计文档 源代码 测试方案、案例
2.5 什么时候确定评审方式
用户需求评审
用户需求获取
技术方案评审
方案制定
技术评审点
需求分析
制定开发项目的 《技术评审计划》
技术评审点
总体设计
技术评审点
评审计划 的制定
技术评审适用范围
详细设计
技术评审点
技术评审点
系统实现
系统测试
验收测试
产品推广
课程内容
1. 技术评审简介 2. 技术评审分类 3. 同行评审
4. 走查及代码复查
5. 表单模板及实例
1.1什么是技术评审
技术评审（TR），是指针对软件项目实施过程中产生 的工作产品进行的旨在尽早发现可能存在的技术缺陷 的一种验证活动。
1.2 为什么要技术评审？
及时发现和排除缺陷，减少后期返工的费用 帮助建立对产品的共同理解。
建议角色
项目成员 总体部、设计 角色、测试人
评审方式
组内走查 总体部组织的同行 评审
员、客户经理
、QA 总体设计结束 4月第1周 总体设计文档 项目成员 组内走查
总体设计结束
4月第2周
总体设计文档
总体部、需求
角色、测试人 员、QA
总体部组织的同行
评审
详细设计结束 程序实现期间 系统测试方案形成
5月第2周 6月第4周 6月第4周
作者
记录单
2.4 各评审项评审方式
评审项
用户需求说明书
评审方式
同行评审（需求管理部组织）
技术方案建议书
组内走查（项目成员） 同行评审（总体部组织）
组内走查（项目成员） 同行评审（总体部组织） 组内走查（项目成员） 同行评审（总体部组织） 同行评审（项目成员） 代码复查（项目成员） 组内走查（项目成员）
1.3 什么时候会进行技术评审？
用户需求评审
用户需求获取
技术方案评审
方案制定
技术评审点
需求分析
制定开发项目的 《技术评审计划》
技术评审点
总体设计
技术评审点
详细设计
技术评审点
技术评审点
系统实现
技术评审适用范围
系统测试
验收测试
产品推广
产品维护
1.4 技术评审效果
缺陷排除率：（Infosys,2000）
产品维护
2.6 制定技术评审计划
项目/产品经理：
确定需要评审的工作产品及评审方式
预定评审时间段以及相关的人员
获得评审参加人员的确认
输出
《技术评审计划》（属于项目开发计划的一部分）
2.6 《技术评审计划》范例
评审点
需求分析结束 需求分析结束
大致时间
3月第1周 3月第2周
评审项
需求分析文档 需求分析文档
受待评审的工作产品影响的小组或个人； 具备相关业务领域、相关系统或相关技术的知识或经验； 评审人员的连续性（参加过前期评审的人员优先考虑）；
评审员总人数一般控制到3～7人。
展示表3：工作产品的评审目的、评审方式及参加的人员
2.1 技术评审方式
同行评审（PR），又称同级评审(Peer Review)，是技术评审 的一种方式，是在软件项目实施过程中由工作产品生产者的 同行遵循规定的规程对工作产品进行的旨在识别并排除缺陷 的一种审查活动。同行评审的参加人员一般与工作产品作者 处于同一级别、具有类似工作（技术）经验。 走查(Walkthrough)，通常指项目组内部正式或非正式的检查 活动，以便尽早发现工作产品中可能存在的缺陷或不符合标 准、规范的问题。在项目实施过程中,走查可灵活安排，分散 、多批次进行。 代码复查，在我公司主要指针对代码所进行的交叉检查,是验 证的一种方式。
2.2 三种评审方式的共同点

以发现缺陷为主要目的，不是为了解决问题； 缺陷数据不会用于追究责任或考核； 评审之前做好准备工作，尤其是正式评审； 评审员帮助作者发现缺陷，但作者是工作产品质量的最终承 担者。
2.3 三种评审方式的差异
评审方式 组织形式 准备 参与者 输出 是否需要评审 结论？
80% 60% 40% 20% 0% 文档评审 上限 下限 15% 20% 15% 20% 20% 50% 28% 5% 代码复查＋单 集成测试＋系 元测试 统测试 50% 70% 20% 28% 10% 70%
验收测试 5% 10%
课程内容
1. 技术评审简介 2. 技术评审分类 3. 同行评审
4. 走查及代码复查