同行评审
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
[ 33 ]
审查员
Verifier &PR Coordinator
Verifier --跟踪验证缺陷的解决情况 Peer Review Coordinator --收集维护每次评审的数据
及相关记录，进行统计分析，形成《评审记录表》； 收集过程改进建议，向SEPG提交过程改进建议报告
[ 34 ]
[7]
同行评审的投资回报-2
从他人对自己工作的反馈中获得知识 帮助小组建立共同的期望，建立对工作产品的一致认
识 帮助开发者开发降低和易理解的产品，减少维护和改
进的成本 有助于建立合作精神，分享知识，彼此学习 通过同行评审互相学习，降低因人员跳槽而丢失关键
信wk.baidu.com的风险
[8]
因此——评审！
发现：评审降低了总的工作量和交付后缺陷数目
[ 24 ]
业界的相关经验－3
印度一家软件出口商，从事通信软件项目
程序数量 KLOC 编码人日 代码审查人日 单元测试人日 工作量小计（人日） KLOC/人日（CUT） 系统测试发现的缺陷密度（缺陷数/KLOC） 验收测试发现的缺陷密度（缺陷数/KLOC）
有审查 230 190
1086 130 489
1705 111 3.0 0.5
无审查 70 68 389 0 408 797 85 6.3 2.3
发现：审查可以达成更高的生产率和更低的缺陷密 度！
[ 25 ]
审查(Inspection)
一种正规的同行评审 ¾ 管理人员不参加、不用于对个人的考核 相关开发人员最大程度地畅所欲言 ¾ 完整定义的过程与角色 便于计划组织与实施 ¾ 经过培训的组织者/主持人 适当控制审查的组织和会议的进程 ¾ 不断优化的检查单 积累经验、指导审查工作 ¾ 完整的记录和报告 数据积累和过程改进
项目A（无评审）
人时数
缺陷数
0
0
0
0
0
0
1520
125
4290
190
5810
315
31900
185
37710
500
项目B（有评审）
人时数
缺陷数
115
50
700
140
1700
110
770
50
2490
100
5775
450
13000
50
18775
500
来源：Software Productivity Research, Inc.
对于项目或产品： ¾ 评估阶段产品质量和开发进展情况（考核） ¾ 早期发现缺陷（质量保证）
对于开发流程改进： ¾ 评估流程效果 ¾ 发现流程缺陷
[6]
同行评审的投资回报-1
HP公司测量所得的同行评审投资回报率为10：1，每 年节省2140万美元（Grody and Van Slack 1994）
变为正面效应： －－评审会激发我们去实践更先进的技术，间接提高
产品质量 －－当作者了解所要查找的缺陷类型后，能开发出更
好的产品
[ 12 ]
文化的影响
在组织里共同营造以质量为驱动的环境 ¾ 宁愿让同事而不是客户来发现软件中的缺陷 ¾ 被同伴发现错误是“合算的”，而不是个人失败
同行评审影响健康的软件文化 ¾ 作者必须信任和尊重评审员，并接受评审员的意见 ¾ 评审员必须尊重作者的技能和辛勤劳动
[ 17 ]
质量不是免费的 同行评审文化 同行评审的方法 试一试 同行评审的基础设施 同行评审的组织管理 关键成功因素 需避免的评审陷阱
[ 18 ]
主题
审查（Inspection） 走查（Walkthrough） 轮查（Passaround ） 单人复审
同行评审的若干方法
[ 26 ]
准备 概要介绍
预审 审查会议 第三小时 修改 跟踪
[ 27 ]
审查流程
会议介绍
复查并记录普遍问题
两
复查并记录特定问题
小
时
复查问题记录
以
内
作出决议
诸葛亮会 延续会议
3～7人，4人最佳 ¾ 主持人（Moderator） ¾ 讲解员（Reader） ¾ 记录员（Recorder） ¾ 作者（Author） ¾ 审查员（Inspector）
延期 如果实在没有时间——取消！
[ 36 ]
软件过程改进系列
怎样在组织内建立同行评审文化
赛宝认证中心 2006年3月
CEPREI
质量不是免费的 同行评审文化 同行评审的方法 试一试 同行评审的基础设施 同行评审的组织管理 关键成功因素 需避免的评审陷阱 其他评审
[2]
主题
许多缺陷是在早期阶段引入的
交付后的缺陷分布
文档 5%
¾ 以30个采用正式审查的项目和30个其它项目相比较 ¾ 生产率（LOC/人月）
有审查的为300 无审查的为144
ICI，Fine Chemical Manufacturing，UK
¾ 400个程序经过审查，400个未经审查 ¾ 未经审查的代码的维护工作量高10倍
Standard Bank
测试不能代替评审！ 评审是检查某些软件工作产品的有效方式！
越早就消越除经缺济陷
[9]
质量不是免费的 同行评审文化 同行评审的方法 试一试 同行评审的基础设施 同行评审的组织管理 关键成功因素 需避免的评审陷阱
[ 10 ]
主题
查找别人的错误
一些开发人员拒绝对他们的工作进行评审 ¾ 拒绝知道自己究竟犯了多少错误 ¾ 觉得让别人指出错误很没面子 ¾ 自己的软件水平已不需要同行评审
[ 14 ]
同行评审的管理承诺
为同行评审提供资源和时间 项目即使处于进度压力下，也要坚持评审 向评审参与者提供培训机会 决不要根据评审结果去评估个人业绩 公开表扬能率先采用评审的人，以激励他人 和那些质疑评审的必要性的其他管理者和客户进行沟
通 尊重评审小组对文档质量的评估意见 要求关于评审的进展、开销和获益情况的报告
¾ 88000行代码未经审查，90000行代码经过审查 ¾ 未经审查的代码的维护工作量高28倍
来源：Tom Gilb & Dorothy Graham，Software Inspections，Addison－Wesley
[ 23 ]
业界的相关经验－2
一次受控的试验
概要设计评审 详细设计评审 代码评审 单元测试 集成/系统测试 小计 维护 合计
一些开发组成员拒绝评审其他人的工作 ¾ 不愿意花时间帮助同事检查错误 ¾ 其他人的问题与我无关 ¾ 大家应该自己做好自己的事情
[ 11 ]
对待评审的不良态度
产生完全依靠评审来发现错误 ¾ 变得懒散
在将产品交给别人看之前总想把它尽善尽美 ¾ 把评审看成是得到别人的认同，而不是提高产品质 量的一种手段
Peer Review Coordinator Verifier
[ 28 ]
审查的角色
需要领导技巧 管理审查过程，保证效果：
¾ 保持公正无私 ¾ 确保满足进入和退出准则 ¾ 确保审查员准备充分 ¾ 进行收尾工作 ¾ 不一定来自同一项目 主持人是关键！ 不仅要控制进程，还要控制气 氛
“你没有初始化变量” （×） “我没有找到变量初始化的地方” （√）
[ 13 ]
评审与管理者
管理者态度和实际行动影响一个组织中评审执行的好 坏 ¾ 一方面想开发出质量过硬的产品 ¾ 一方面又想尽快发布产品 ¾ 不了解评审究竟为按时交付高质量的产品做了什么 贡献
管理者需要了解同行评审及同行评审对组织的影响， 这样他们才会： ¾ 将评审活动安排在项目计划中 ¾ 为评审分配资源 ¾ 将他们对评审的承诺传达给项目组
不同观点
不仅要分配审查角色，还需要不同的立场与观点 具体的需要取决于被审查项的类型 下表给出了推荐的组合：
观点
需求 总体设计 详细设计
代码
单元测试 集成测试 系统测试 验收测试 计划 计划 计划 计划
客户 √ √
√
分析员 √
√
√√
设计师 √
√
√
√√√
程序员
√√√
测试人员 √
√
√
√
√
√
√
[ 19 ]
审查——软件界的最佳实践之一
a. 一种正式的评定技术。由除作者之外的某人或某一小 组仔细检查软件需求、设计或代码，以找出故障、违 反开发标准之处和其它一些问题。
b. 质量管理的一个阶段。在此阶段借助检查、观察或测 量来确定材料、必须品、零部件、附属品、系统、过 程或结构是否符合预定的质量要求。 ——GB/T 11457-1995 软件工程术语
改错 10%
软件的缺陷
需求 15%
编码 30%
资料来源： Applied Software Measurement, Capers Jones
[3]
设计 40%
尽早消除软件缺陷的价值
缺陷发现越晚，纠 正费用越高
资料来源：Boehm, IBM, 1981
1000 100
消除一个缺陷 的相对成本
10
[ 31 ]
讲解员
收集与分发材料 提供概要介绍 能够参加审查以作出必要澄清 同时作为审查员 不要有自我防卫心理
作者
[ 32 ]
所有人（主持人、讲解员、 记录员、作者）都是审查员
理解被审材料 进行个人检查 做好准备并参加会议 寻找产品中的异常，而不是
针对作者 坦诚友善，言简意赅
[ 15 ]
同行评审为开发者带来好处
减少返工时间 提高编程生产率 保证实现的是正确的需求 减少单元测试和调试的时间 有利于组员间的信息交换
[ 16 ]
同行评审为项目经理带来好处
产品按时交付的可能性增强 更早发现质量问题 加强团队合作，提高开发的有效性 通过团队成员的交叉评审减少人员流动带来的影响 节约费用 项目产品有更高的一致性
[ 21 ]
审查的对象
最初起源于代码审查 实践证明可以用于对所有软件工作产品的检查
¾ 软件需求说明 ¾ 软件设计说明 ¾ 源代码 ¾ 软件测试文档 ¾ 用户手册 ¾ 安装规程 ¾ 版本发布说明 ¾ 计划等管理文档 ¾ …………
[ 22 ]
业界的相关经验－1
IBM Federal Systems Division（FSD）
3～6倍
1倍 1
40～1000倍
10倍
30～70倍 15～40倍
缺陷数量的放大
需求分析 设计
编码
每个进入下个步骤
的缺陷都可能引起 下个步骤中的多个 缺陷，导致消缺成
来自上个步骤 的缺陷
来自上个步骤的缺陷 放大了的缺陷，1:X 本步骤新产生的缺陷
本的剧增。
开发测试 系统测试 实际运行
缺陷检测 有效性 百分比
√
维护人员
√√√
质量保证 √
√
√
√
√
√
√
√
[ 35 ]
有效评审的若干原则
预审期间使用检查单 避免过度依赖检查单 审查会议限制在2小时内 审查产品而非生产者 避免长时间讨论——在一个问
题上的讨论不要超过5分钟 对评审员提供足够的预审时间
（至少提前两天） 如果有人未准备好，则将会议
传给下个步骤 的缺陷
[4]
测试是昂贵的
传统的测试只能在生存周期的后半部分进行 ¾ 在需求、设计等阶段进行测试是不可能的
测试消耗大量的时间 ¾ 测试计划、测试数据、测试脚本、测试执行和报 告、调试、修正、重新测试
通常测试不能发现一些特定类型的缺陷 ¾ （例如违背编码标准）
[5]
评审的目的
一种正式的评价技术，由不同于作者的一组人员详细 检查软件需求、设计或代码，以发现错误、与开发标 准的偏离和其它问题。 ——IEEE Std 729-1983
[ 20 ]
审查的目的
目的： ¾ 独立的验证 ¾ 验证规格说明是否得到满足 ¾ 验证与标准的一致性 ¾ 为后继改进收集数据 ¾ 集中于发现缺陷（而不是形式或备选方案）
在AT&T贝尔试验室，同行评审使得发现错误的费用 降低到10％，同时使质量提高了10倍，效率提高了14 ％(Humphrey 1989)
贝尔北方研究中心评审了250万行实时系统代码，避免 了平均每个缺陷33小时的维护费用。通过评审发现缺 陷的效率是测试的2～4倍（Russell 1991）
IBM公司数据：每小时的评审可节约20小时的测试， 如果在发布的产品遗留了评审发现的缺陷，则需返工 时间为82小时(Holland 1999)
[ 29 ]
主持人
记录员
按照主持人的示意记录异常 记录的同时记录异常分类 大声朗读记录下来的缺陷
¾ 在每次记录之后 ¾ 最后朗读整个记录表 笔迹清晰，文字简明
[ 30 ]
充分理解审查材料 讲解时加以解释 合理把握讲解的速度 等待记录员完成记录后继
续讲解 讲解员不能由作者担当
审查员
Verifier &PR Coordinator
Verifier --跟踪验证缺陷的解决情况 Peer Review Coordinator --收集维护每次评审的数据
及相关记录，进行统计分析，形成《评审记录表》； 收集过程改进建议，向SEPG提交过程改进建议报告
[ 34 ]
[7]
同行评审的投资回报-2
从他人对自己工作的反馈中获得知识 帮助小组建立共同的期望，建立对工作产品的一致认
识 帮助开发者开发降低和易理解的产品，减少维护和改
进的成本 有助于建立合作精神，分享知识，彼此学习 通过同行评审互相学习，降低因人员跳槽而丢失关键
信wk.baidu.com的风险
[8]
因此——评审！
发现：评审降低了总的工作量和交付后缺陷数目
[ 24 ]
业界的相关经验－3
印度一家软件出口商，从事通信软件项目
程序数量 KLOC 编码人日 代码审查人日 单元测试人日 工作量小计（人日） KLOC/人日（CUT） 系统测试发现的缺陷密度（缺陷数/KLOC） 验收测试发现的缺陷密度（缺陷数/KLOC）
有审查 230 190
1086 130 489
1705 111 3.0 0.5
无审查 70 68 389 0 408 797 85 6.3 2.3
发现：审查可以达成更高的生产率和更低的缺陷密 度！
[ 25 ]
审查(Inspection)
一种正规的同行评审 ¾ 管理人员不参加、不用于对个人的考核 相关开发人员最大程度地畅所欲言 ¾ 完整定义的过程与角色 便于计划组织与实施 ¾ 经过培训的组织者/主持人 适当控制审查的组织和会议的进程 ¾ 不断优化的检查单 积累经验、指导审查工作 ¾ 完整的记录和报告 数据积累和过程改进
项目A（无评审）
人时数
缺陷数
0
0
0
0
0
0
1520
125
4290
190
5810
315
31900
185
37710
500
项目B（有评审）
人时数
缺陷数
115
50
700
140
1700
110
770
50
2490
100
5775
450
13000
50
18775
500
来源：Software Productivity Research, Inc.
对于项目或产品： ¾ 评估阶段产品质量和开发进展情况（考核） ¾ 早期发现缺陷（质量保证）
对于开发流程改进： ¾ 评估流程效果 ¾ 发现流程缺陷
[6]
同行评审的投资回报-1
HP公司测量所得的同行评审投资回报率为10：1，每 年节省2140万美元（Grody and Van Slack 1994）
变为正面效应： －－评审会激发我们去实践更先进的技术，间接提高
产品质量 －－当作者了解所要查找的缺陷类型后，能开发出更
好的产品
[ 12 ]
文化的影响
在组织里共同营造以质量为驱动的环境 ¾ 宁愿让同事而不是客户来发现软件中的缺陷 ¾ 被同伴发现错误是“合算的”，而不是个人失败
同行评审影响健康的软件文化 ¾ 作者必须信任和尊重评审员，并接受评审员的意见 ¾ 评审员必须尊重作者的技能和辛勤劳动
[ 17 ]
质量不是免费的 同行评审文化 同行评审的方法 试一试 同行评审的基础设施 同行评审的组织管理 关键成功因素 需避免的评审陷阱
[ 18 ]
主题
审查（Inspection） 走查（Walkthrough） 轮查（Passaround ） 单人复审
同行评审的若干方法
[ 26 ]
准备 概要介绍
预审 审查会议 第三小时 修改 跟踪
[ 27 ]
审查流程
会议介绍
复查并记录普遍问题
两
复查并记录特定问题
小
时
复查问题记录
以
内
作出决议
诸葛亮会 延续会议
3～7人，4人最佳 ¾ 主持人（Moderator） ¾ 讲解员（Reader） ¾ 记录员（Recorder） ¾ 作者（Author） ¾ 审查员（Inspector）
延期 如果实在没有时间——取消！
[ 36 ]
软件过程改进系列
怎样在组织内建立同行评审文化
赛宝认证中心 2006年3月
CEPREI
质量不是免费的 同行评审文化 同行评审的方法 试一试 同行评审的基础设施 同行评审的组织管理 关键成功因素 需避免的评审陷阱 其他评审
[2]
主题
许多缺陷是在早期阶段引入的
交付后的缺陷分布
文档 5%
¾ 以30个采用正式审查的项目和30个其它项目相比较 ¾ 生产率（LOC/人月）
有审查的为300 无审查的为144
ICI，Fine Chemical Manufacturing，UK
¾ 400个程序经过审查，400个未经审查 ¾ 未经审查的代码的维护工作量高10倍
Standard Bank
测试不能代替评审！ 评审是检查某些软件工作产品的有效方式！
越早就消越除经缺济陷
[9]
质量不是免费的 同行评审文化 同行评审的方法 试一试 同行评审的基础设施 同行评审的组织管理 关键成功因素 需避免的评审陷阱
[ 10 ]
主题
查找别人的错误
一些开发人员拒绝对他们的工作进行评审 ¾ 拒绝知道自己究竟犯了多少错误 ¾ 觉得让别人指出错误很没面子 ¾ 自己的软件水平已不需要同行评审
[ 14 ]
同行评审的管理承诺
为同行评审提供资源和时间 项目即使处于进度压力下，也要坚持评审 向评审参与者提供培训机会 决不要根据评审结果去评估个人业绩 公开表扬能率先采用评审的人，以激励他人 和那些质疑评审的必要性的其他管理者和客户进行沟
通 尊重评审小组对文档质量的评估意见 要求关于评审的进展、开销和获益情况的报告
¾ 88000行代码未经审查，90000行代码经过审查 ¾ 未经审查的代码的维护工作量高28倍
来源：Tom Gilb & Dorothy Graham，Software Inspections，Addison－Wesley
[ 23 ]
业界的相关经验－2
一次受控的试验
概要设计评审 详细设计评审 代码评审 单元测试 集成/系统测试 小计 维护 合计
一些开发组成员拒绝评审其他人的工作 ¾ 不愿意花时间帮助同事检查错误 ¾ 其他人的问题与我无关 ¾ 大家应该自己做好自己的事情
[ 11 ]
对待评审的不良态度
产生完全依靠评审来发现错误 ¾ 变得懒散
在将产品交给别人看之前总想把它尽善尽美 ¾ 把评审看成是得到别人的认同，而不是提高产品质 量的一种手段
Peer Review Coordinator Verifier
[ 28 ]
审查的角色
需要领导技巧 管理审查过程，保证效果：
¾ 保持公正无私 ¾ 确保满足进入和退出准则 ¾ 确保审查员准备充分 ¾ 进行收尾工作 ¾ 不一定来自同一项目 主持人是关键！ 不仅要控制进程，还要控制气 氛
“你没有初始化变量” （×） “我没有找到变量初始化的地方” （√）
[ 13 ]
评审与管理者
管理者态度和实际行动影响一个组织中评审执行的好 坏 ¾ 一方面想开发出质量过硬的产品 ¾ 一方面又想尽快发布产品 ¾ 不了解评审究竟为按时交付高质量的产品做了什么 贡献
管理者需要了解同行评审及同行评审对组织的影响， 这样他们才会： ¾ 将评审活动安排在项目计划中 ¾ 为评审分配资源 ¾ 将他们对评审的承诺传达给项目组
不同观点
不仅要分配审查角色，还需要不同的立场与观点 具体的需要取决于被审查项的类型 下表给出了推荐的组合：
观点
需求 总体设计 详细设计
代码
单元测试 集成测试 系统测试 验收测试 计划 计划 计划 计划
客户 √ √
√
分析员 √
√
√√
设计师 √
√
√
√√√
程序员
√√√
测试人员 √
√
√
√
√
√
√
[ 19 ]
审查——软件界的最佳实践之一
a. 一种正式的评定技术。由除作者之外的某人或某一小 组仔细检查软件需求、设计或代码，以找出故障、违 反开发标准之处和其它一些问题。
b. 质量管理的一个阶段。在此阶段借助检查、观察或测 量来确定材料、必须品、零部件、附属品、系统、过 程或结构是否符合预定的质量要求。 ——GB/T 11457-1995 软件工程术语
改错 10%
软件的缺陷
需求 15%
编码 30%
资料来源： Applied Software Measurement, Capers Jones
[3]
设计 40%
尽早消除软件缺陷的价值
缺陷发现越晚，纠 正费用越高
资料来源：Boehm, IBM, 1981
1000 100
消除一个缺陷 的相对成本
10
[ 31 ]
讲解员
收集与分发材料 提供概要介绍 能够参加审查以作出必要澄清 同时作为审查员 不要有自我防卫心理
作者
[ 32 ]
所有人（主持人、讲解员、 记录员、作者）都是审查员
理解被审材料 进行个人检查 做好准备并参加会议 寻找产品中的异常，而不是
针对作者 坦诚友善，言简意赅
[ 15 ]
同行评审为开发者带来好处
减少返工时间 提高编程生产率 保证实现的是正确的需求 减少单元测试和调试的时间 有利于组员间的信息交换
[ 16 ]
同行评审为项目经理带来好处
产品按时交付的可能性增强 更早发现质量问题 加强团队合作，提高开发的有效性 通过团队成员的交叉评审减少人员流动带来的影响 节约费用 项目产品有更高的一致性
[ 21 ]
审查的对象
最初起源于代码审查 实践证明可以用于对所有软件工作产品的检查
¾ 软件需求说明 ¾ 软件设计说明 ¾ 源代码 ¾ 软件测试文档 ¾ 用户手册 ¾ 安装规程 ¾ 版本发布说明 ¾ 计划等管理文档 ¾ …………
[ 22 ]
业界的相关经验－1
IBM Federal Systems Division（FSD）
3～6倍
1倍 1
40～1000倍
10倍
30～70倍 15～40倍
缺陷数量的放大
需求分析 设计
编码
每个进入下个步骤
的缺陷都可能引起 下个步骤中的多个 缺陷，导致消缺成
来自上个步骤 的缺陷
来自上个步骤的缺陷 放大了的缺陷，1:X 本步骤新产生的缺陷
本的剧增。
开发测试 系统测试 实际运行
缺陷检测 有效性 百分比
√
维护人员
√√√
质量保证 √
√
√
√
√
√
√
√
[ 35 ]
有效评审的若干原则
预审期间使用检查单 避免过度依赖检查单 审查会议限制在2小时内 审查产品而非生产者 避免长时间讨论——在一个问
题上的讨论不要超过5分钟 对评审员提供足够的预审时间
（至少提前两天） 如果有人未准备好，则将会议
传给下个步骤 的缺陷
[4]
测试是昂贵的
传统的测试只能在生存周期的后半部分进行 ¾ 在需求、设计等阶段进行测试是不可能的
测试消耗大量的时间 ¾ 测试计划、测试数据、测试脚本、测试执行和报 告、调试、修正、重新测试
通常测试不能发现一些特定类型的缺陷 ¾ （例如违背编码标准）
[5]
评审的目的
一种正式的评价技术，由不同于作者的一组人员详细 检查软件需求、设计或代码，以发现错误、与开发标 准的偏离和其它问题。 ——IEEE Std 729-1983
[ 20 ]
审查的目的
目的： ¾ 独立的验证 ¾ 验证规格说明是否得到满足 ¾ 验证与标准的一致性 ¾ 为后继改进收集数据 ¾ 集中于发现缺陷（而不是形式或备选方案）
在AT&T贝尔试验室，同行评审使得发现错误的费用 降低到10％，同时使质量提高了10倍，效率提高了14 ％(Humphrey 1989)
贝尔北方研究中心评审了250万行实时系统代码，避免 了平均每个缺陷33小时的维护费用。通过评审发现缺 陷的效率是测试的2～4倍（Russell 1991）
IBM公司数据：每小时的评审可节约20小时的测试， 如果在发布的产品遗留了评审发现的缺陷，则需返工 时间为82小时(Holland 1999)
[ 29 ]
主持人
记录员
按照主持人的示意记录异常 记录的同时记录异常分类 大声朗读记录下来的缺陷
¾ 在每次记录之后 ¾ 最后朗读整个记录表 笔迹清晰，文字简明
[ 30 ]
充分理解审查材料 讲解时加以解释 合理把握讲解的速度 等待记录员完成记录后继
续讲解 讲解员不能由作者担当