同行评审指南V10.docx
《同行评审指南V10.docx》由会员分享，可在线阅读，更多相关《同行评审指南V10.docx（12页珍藏版）》请在冰豆网上搜索。
同行评审指南V10
文件编号：
同行评审指南
本V1.0
文档编号
保密等级
机密
作者
最后修改日期
审核人
最后审批日期
文档修订记录
编号
章节名称
修订内容简述
修订日期
修订前
版本号
修订后
版本号
修订人
1
2
3
4
5
6
7
8
1编制目的
本文档的编制目的是为同行评审过程提供指导，以提高同行评审的效率，及早地发现被评审的软件工作交付物中的错误与缺陷，提高软件交付物质量。
2适用范围
本指南适用于XXX银行信息科技部软件开发系统的同行评审活动。
3过程指南
开始执行该过程的必须具备的前提条件：
如执行该过程的角色应具备的能力和资源、约束条件已满足等。
4软件工作交付物同行评审类型的选择
项目技术经理在计划同行评审类型时可以根据表1进行选择。
软件工作交付物类型
评审类型选择建议
需求说明书
正规检视
需求规格说明书
正规检视
软件设计说明书
正规检视
架构设计说明书
正规检视
代码
正规检视/走查
测试用例
正规检视/走查
用户手册
正规检视/走查
计划文档
正规检视/走查
表1.同行评审类型选择建议
在需求与设计过程中，在正式的正规检视之前，可以安排走查，对过程可以不具体要求，但是必须完成《同行评审总结报告》中的缺陷汇总表。
为了保证同行评审的效率，项目技术经理在制定项目计划时应注意以下事项：
Ø在估计工作量时应考虑评审的工作量。
Ø提供同行评审所需的资源，项目组成员的任务安排中要包括同行评审。
5正规检视指南
5.1.1同行评审组织者的选择
项目技术经理在确定了要进行正规检视的软件工作交付物同时要选择同行评审组织者，同行评审组织者要符合以下要求：
Ø是所要评审的软件工作交付物方面的专家。
Ø接受过同行评审组织者培训，参加过两次以上正规检视类型同行评审。
5.1.2正规检视计划
作者在软件工作交付物完成后，根据评审计划提交软件工作交付物。
评审组织者要验证正规检视的入口准则与输入物。
Ø软件工作交付物是否使用了经批准的模板。
Ø模板所要求的内容是否都具备，软件工作交付物是否完整。
Ø软件工作交付物所应遵循的标准是否明确。
Ø是否计划了正规检视。
Ø正规检视所需的标准、规程、检查表明确并可得到。
Ø软件工作交付物已经稳定，在提交评审到评审会议期间不会再进行修改。
如果软件工作交付物不能满足入口准则，则返回给作者以进一步的改进。
在确定入口准则得到了满足并且输入正确后，评审组织者要计划正规检视评审。
1.首先评审组织者要根据被评审软件工作交付物的规模估计评审准备时间与评审会议时间。
一般情况下每个评审人员每天的评审准备时间不超过4小时，应让评审人员有充足的时间进行准备。
为了保证评审会议效率，一次评审会议的持续时间最好不要超过2个小时，有许多证据表明，当会议超过2小时后，会议的效率会降低；同时在两次评审会议之间至少要间隔1小时。
评审组织者可以参考表2估计评审准备时间与评审会议时间。
软件工作交付物类型
评审准备效率
需求说明书
6-10页/小时
需求规格说明书
6-10页/小时
软件设计说明书
6-10页/小时
代码
150-250行/小时
其他文档
8-15页/小时
表2.正规检视评审效率建议表
Ø如果估计评审会议时间会超过2小时，可以举行多次评审会议评审软件工作交付物。
Ø如果被评审的软件工作交付物有多个作者并且是每个作者独立负责其中一部分内容，则可以按作者划分评审会议，一次评审会议评审一个或几个作者的内容，再举行其他评审会议评审其他作者的内容。
Ø如果被评审的软件工作交付物是一个作者或多个作者完成但是每个作者负责的部分规模仍较大不能在一次评审会议完成，则可以按规模划分。
评审对象按规模划分最小单位建议见表3。
Ø不论用哪种方法划分，被评审的软件工作交付物中的全局性内容不能分开两次评审。
Ø如进行多次评审会议，评审人员在每次评审会议时都要注意被评审的软件工作交付物两次评审会议评审内容的一致性。
软件工作交付物类型
最小单位
需求规格说明书
功能点
概要设计说明书
模块
详细设计说明书
类
代码
类，函数，方法，过程
表3.按规模划分最小单位建议
2.评审组织者要计划评审所需准备时间，确定了评审会议时间之后，要为正规检视选择评审人员，可以指定一名朗读者。
评审人员人数建议在3-7人之间，有数据表明，5-6人效率较高。
评审组织者也是评审人员。
需要注意的是一个为评审做好充分准备的普通工程师发现错误与缺陷的效率要远远高于一个没做好准备的专家，所以评审组织者一定要得到项目技术经理与评审人员的承诺，评审准备与评审会议会安排进WBS计划，确认选择的评审人员有充足的时间为评审做好准备。
评审人员的选择建议见表4。
评审组织者选择评审人员时可以请求项目技术经理的帮助。
软件工作交付物类型
评审人员选择建议
可行性分析报告
需求分析专员、安全技术专员、应用管理员、系统维护专员、
架构管理专员、其他相关团队负责人
需求规格说明书
项目技术经理、开发经理、架构师（开发方）、设计组（开发方）、
开发人员、技术测试负责人、应用管理员、系统维护专员、
QA、CM
概要设计说明书
项目技术经理、开发经理、架构师（开发方）、设计组（开发方）、开发人员、技术测试负责人、应用管理员、系统维护专员、QA、CM
详细设计说明书
项目技术经理、开发经理、架构师（开发方）、设计组（开发方）、开发人员、QA、CM
代码与单元测试用例
开发经理、架构师（开发方）、开发人员
集成测试用例
架构师（开发方）、设计组（开发方）、开发人员、技术测试负责人、技术测试人员、QA、CM
系统测试用例
架构师（开发方）、设计组（开发方）、开发人员、技术测试负责人、技术测试人员、QA、CM
表4.评审人员的选择建议
3.在决定了评审人员后，评审组织者要注意以下事情：
Ø为评审人员分配任务，对任务的分配有以下建议
⏹可以根据评审人员的职责、技术特性等分配任务。
如在需求分析同行评审中测试人员可以关注可测试性与一致性，其他人员要关注可实现性与完备性等。
⏹最好不要分配评审人员关注XX页至XX页这样的任务。
⏹任务的分配要保证某一个特性或部分最少有两个评审人员关注，这样可以防止有一个评审人员没有做好准备以至于有特性或部分没有做好准备而导致评审会议延期或取消。
⏹在任务分配时，评审组织者可以指明评审人员要关注的评审要点，以利于评审人员的准备。
Ø为评审会议指定一名记录员，记录员可以是评审组织者与朗读者以外参加评审会议的其他任何人。
Ø如果计划了评审介绍会议，作者要为评审介绍会议做好准备。
Ø评审组织者要在作者的协助下准备评审资料并发送给评审人员。
4.评审组织者要验证评审计划阶段是否完成，可以开始下一阶段工作。
Ø评审会议时间已经确定，评审人员也已经确定并有足够的时间进行准备。
Ø评审人员的任务已经分配，包括朗读者。
Ø如果决定举行介绍会议，作者已做好准备。
Ø评审资料已经准备完毕，并与评审会议通知一起发送给了评审人员。
每个评审人员都确认收到了评审资料与会议通知。
5.1.3介绍会议
1.介绍会议的目的是向评审人员介绍被评审的软件工作交付物的背景、结构与基本原理，使评审人员对被评审的软件工作交付物有大概的了解，评审组织者可以着重指出需评审人员注意的部分以利于评审人员的准备，作者可以准备幻灯片以利于沟通。
2.评审组织者可以在介绍会议上再次明确评审人员的任务，同时再次获得评审人员的承诺。
5.1.4预评审
1.评审组织者要验证入口准则
Ø每个评审人员都收到了评审资料与会议通知，明确了任务安排并有时间进行准备。
Ø评审人员承诺会为评审会议做好准备。
2.评审人员要检查被评审的软件工作交付物对需求的满足、对标准、过程的符合性以及检查项中的每一项细节，以发现问题与提出建议，并在会前半个工作日完成《同行评审过程记录反馈表》中的缺陷反馈表并发送给所有评审会议参加人员，同时评审人员要记录在准备阶段的工作量。
Ø评审组织者是评审人员的一员，也要为评审会议做好准备，在评审会议前半个工作日，评审组织者要验证其他评审人员的准备，将评审人员所提出的问题整理并找出其中的全局性问题。
3.评审组织者验证本阶段的完成准则
Ø是否所有评审人员都做好了准备，如果有30%以上的评审人员没有做好准备，建议评审会议延期。
如果有部分内容或特性没有评审人员做好准备，评审会议延期。
5.1.5评审会议
由评审组织者控制的会议是一个正式的会议。
它的目的是尽可能找到软件工作交付物中的缺陷。
为了保证评审人员的注意力，对评审会议地点有以下要求：
Ø安静，不会受到他人的打扰。
Ø有足够的空间，不会拥挤，空气良好。
1.评审组织者要验证入口准则。
Ø评审人员是否做好了准备，为了提高评审会议的效率，建议没有做好准备的评审人员不要参加会议。
Ø评审人员的准备时间已得到了记录。
2.会议进程
Ø会议首先讨论评审组织者总结的全局性问题。
而后按顺序讨论被评审的软件工作交付物的内容并识别缺陷。
也可以只讨论在会前评审人员提出的问题与建议。
Ø朗读者要找出与之关联上下文与参考资料，要在评审人员与作者之间达成一致。
Ø当发现问题时，评审人员要达成一致，如果有争议，评审人员可以要求作者做出解释。
评审组织者要控制会议进程，为了让评审人员的注意力保持在发现错误与缺陷而不是争吵与解决问题上，每个问题时间不要超过3分钟。
Ø当确定为缺陷时，首先要确定引入阶段，而后评审组织者在评审人员与作者的协助下确定错误或缺陷的性质与种类。
性质为三种：
严重、一般、建议。
Ø评审组织者要控制会议，为了保证效率，建议每小时休息5-10分钟。
Ø记录员在评审会议上记录发现的每个缺陷，标识位置，为了方便作者的修改。
Ø在评审会议最后阶段，评审组织者要决定是否对修改后的软件工作交付物进行再次评审。
Ø记录员要在会后一个工作日内完成《同行评审总结报告》中的缺陷汇总表并发送给作者与评审人员，抄送项目组成员与相关小组成员。
Ø在评审会议结束时，评审组织者应总结评审会议，包括以下内容：
⏹评审花费的总工作量
⏹在会前提出的问题数。
⏹评审会议时间。
⏹所标识的缺陷数量。
3.评审组织者要验证完成准则。
Ø软件工作交付物已全部被评审。
Ø所发现的缺陷都得到了记录。
5.1.6缺陷的修改与验证
1.评审组织者验证入口准则。
Ø评审会议已召开，缺陷得到了识别与描述。
2.作者根据评审意见对被评审的软件工作交付物进行返工，修改所发现的缺陷。
3.评审组织者负责验证缺陷的修改，可以要求评审人员的协助。
4.作者可以请求评审人员的协助，召开会议讨论解决缺陷的方法。
5.对以前阶段引入的缺陷进入变更流程处理。
6.评审组织者跟踪缺陷的状态，在评审会议上发现的缺陷初始状态为Open，如果解决为Close，SVNB可以决定缺陷挂起，在以后解决，挂起的原因要加以注明。
在项目结束时，要对挂起的缺陷做出最终决定。
7.在缺陷修改完成后，评审组织者要完成《同行评审总结报告》
8.评审组织者验证完成准则。
Ø作者修改了软件工作交付物，没有缺陷处于Open状态。
Ø作者及其他人员的修改工作量已记录。
Ø《同行评审总结报告》完成，评审的文档进行管理和控制。
6走查流程
6.1.1计划
1.开发经理要验证入口准则。
Ø所有没有进行正规检视评审的代码与详细设计说明书都要进行走查评审。
Ø如果是代码，则应通过编译。
Ø开发经理应审核计划评审的软件工作交付物以确认可以进行评审。
Ø被评审的软件工作交付物有明确的标准与检查表，所有的项目组成员对此达成一致。
2.开发经理要计划走查。
Ø为走查选择2-4名评审人员。
Ø每次评审的规模不要过大，走查的时间建议不要超过1小时。
Ø计划评审会议时间。
如果需要可以指定专人负责会议组织安排。
要计划评审人员与作者的工作量，将评审人员准备与参加评审会议排入工作计划。
Ø确定评审所要遵循的标准与检查表。
Ø在确定了评审会议时间后，作者要将被评审的软件工作交付物与相关参考资料、标准、检查表发送给评审人员以利于准备。
3.项目技术经理要验证完成准则。
Ø所有的评审人员都收到了评审资料与会议通知。
6.1.2准备
1.开发经理验证入口准则
Ø每个评审人员都收到了评审资料与会议通知，包括被评审的软件工作交付物及其标准、检查表等。
2.评审人员的准备。
Ø评审人员的准备是指对被评审的软件工作交付物应遵循的标准、过程与检查表的准备，评审人员要在评审前明确这些标准以在评审会议上发现缺陷。
Ø为了利于评审，建议评审人员了解被评审的软件工作交付物的背景及相关资料。
3.开发经理验证完成准则。
Ø评审人员做好了准备，对软件工作交付物所应遵循的标准达成一致。
6.1.3评审会议
1.由作者主导的评审会议可以是一个正式的会议也可以是一个非正式的会议。
2.会议进程：
Ø会议由作者控制。
Ø作者引导评审人员通读被评审的软件工作交付物，评审人员在其中发现缺陷并协助作者确认引入阶段、性质。
在会议上可以讨论解决缺陷的方法。
Ø记录员要记录所发现的缺陷及其属性并在会后一个工作日内生成《同行评审总结报告》中的缺陷汇总表。
3.项目技术要对验证完成准则
Ø软件工作交付物已经全部被评审。
Ø所发现的缺陷已经记录。
6.1.4缺陷的修改与跟踪
1.开发经理验证入口准则。
Ø评审会议已召开，错误与缺陷得到了识别与描述。
2.作者根据评审意见对被评审的软件工作交付物进行返工修改所发现的缺陷。
项目技术经理负责验证缺陷的修改。
3.作者可以请求评审人员的协助，召开会议讨论解决缺陷的方法。
4.开发经理跟踪缺陷的状态。
5.开发经理验证完成准则。
Ø作者修改了软件工作交付物，没有缺陷处于Open状态。
Ø作者及其他人员的修改工作量已记录。
7附录
8附录1：
表格索引
升级会员 