同行评审指南V10

1、文件编号：同行评审指南本 V1.0文 档 编 号保 密 等 级机密作 者最后修改日期审 核 人最后审批日期文档修订记录编号章节名称 修订内容简述修订日期修订前版本号修订后版本号修订人12345678目 录1编制目的12适用范围13过程指南13.1软件工作交付物同行评审类型的选择13.2正规检视指南2同行评审组织者的选择2正规检视计划2介绍会议5预评审5评审会议5缺陷的修改与验证73.3走查流程7计划7准备8评审会议8缺陷的修改与跟踪84附录94.1附录1： 表格索引91 编制目的本文档的编制目的是为同行评审过程提供指导，以提高同行评审的效率，及早地发现被评审的软件工作交付物中的错误与缺陷，提高

2、软件交付物质量。2 适用范围本指南适用于XXX银行信息科技部软件开发系统的同行评审活动。3 过程指南开始执行该过程的必须具备的前提条件：如执行该过程的角色应具备的能力和资源、约束条件已满足等。3.1 软件工作交付物同行评审类型的选择项目技术经理在计划同行评审类型时可以根据表1 进行选择。软件工作交付物类型评审类型选择建议需求说明书正规检视需求规格说明书正规检视软件设计说明书正规检视架构设计说明书正规检视代码正规检视 / 走查测试用例正规检视 / 走查用户手册正规检视 / 走查计划文档正规检视 / 走查表1. 同行评审类型选择建议在需求与设计过程中，在正式的正规检视之前，可以安排走查，对过程可以

3、不具体要求，但是必须完成同行评审总结报告中的缺陷汇总表。为了保证同行评审的效率，项目技术经理在制定项目计划时应注意以下事项： 在估计工作量时应考虑评审的工作量。 提供同行评审所需的资源，项目组成员的任务安排中要包括同行评审。3.2 正规检视指南3.2.1 同行评审组织者的选择项目技术经理在确定了要进行正规检视的软件工作交付物同时要选择同行评审组织者，同行评审组织者要符合以下要求： 是所要评审的软件工作交付物方面的专家。 接受过同行评审组织者培训，参加过两次以上正规检视类型同行评审。3.2.2 正规检视计划作者在软件工作交付物完成后，根据评审计划提交软件工作交付物。评审组织者要验证正规检视的入口

4、准则与输入物。 软件工作交付物是否使用了经批准的模板。 模板所要求的内容是否都具备，软件工作交付物是否完整。 软件工作交付物所应遵循的标准是否明确。 是否计划了正规检视。 正规检视所需的标准、规程、检查表明确并可得到。 软件工作交付物已经稳定，在提交评审到评审会议期间不会再进行修改。如果软件工作交付物不能满足入口准则，则返回给作者以进一步的改进。在确定入口准则得到了满足并且输入正确后，评审组织者要计划正规检视评审。1. 首先评审组织者要根据被评审软件工作交付物的规模估计评审准备时间与评审会议时间。一般情况下每个评审人员每天的评审准备时间不超过4 小时，应让评审人员有充足的时间进行准备。为了保证

5、评审会议效率，一次评审会议的持续时间最好不要超过2 个小时，有许多证据表明，当会议超过2 小时后，会议的效率会降低；同时在两次评审会议之间至少要间隔1 小时。评审组织者可以参考表2 估计评审准备时间与评审会议时间。软件工作交付物类型评审准备效率需求说明书6-10页/小时需求规格说明书6-10页/小时软件设计说明书6-10页/小时代码150-250行/小时其他文档8-15页/小时表2. 正规检视评审效率建议表 如果估计评审会议时间会超过 2 小时，可以举行多次评审会议评审软件工作交付物。 如果被评审的软件工作交付物有多个作者并且是每个作者独立负责其中一部分内容，则可以按作者划分评审会议，一次评审

6、会议评审一个或几个作者的内容，再举行其他评审会议评审其他作者的内容。 如果被评审的软件工作交付物是一个作者或多个作者完成但是每个作者负责的部分规模仍较大不能在一次评审会议完成，则可以按规模划分。评审对象按规模划分最小单位建议见表3。 不论用哪种方法划分，被评审的软件工作交付物中的全局性内容不能分开两次评审。 如进行多次评审会议，评审人员在每次评审会议时都要注意被评审的软件工作交付物两次评审会议评审内容的一致性。软件工作交付物类型最小单位需求规格说明书功能点概要设计说明书模块详细设计说明书类代码类，函数，方法，过程表3. 按规模划分最小单位建议2. 评审组织者要计划评审所需准备时间，确定了评审会

7、议时间之后，要为正规检视选择评审人员，可以指定一名朗读者。评审人员人数建议在3-7 人之间，有数据表明，5-6 人效率较高。评审组织者也是评审人员。需要注意的是一个为评审做好充分准备的普通工程师发现错误与缺陷的效率要远远高于一个没做好准备的专家，所以评审组织者一定要得到项目技术经理与评审人员的承诺，评审准备与评审会议会安排进WBS 计划，确认选择的评审人员有充足的时间为评审做好准备。评审人员的选择建议见表4。评审组织者选择评审人员时可以请求项目技术经理的帮助。软件工作交付物类型评审人员选择建议可行性分析报告需求分析专员、安全技术专员、应用管理员、系统维护专员、架构管理专员、其他相关团队负责人需

8、求规格说明书项目技术经理、开发经理、架构师（开发方）、设计组（开发方）、开发人员、技术测试负责人、应用管理员、系统维护专员、QA、CM概要设计说明书项目技术经理、开发经理、架构师（开发方）、设计组（开发方）、开发人员、技术测试负责人、应用管理员、系统维护专员、QA、CM详细设计说明书项目技术经理、开发经理、架构师（开发方）、设计组（开发方）、开发人员、QA、CM代码与单元测试用例开发经理、架构师（开发方）、开发人员集成测试用例架构师（开发方）、设计组（开发方）、开发人员、技术测试负责人、技术测试人员、QA、CM系统测试用例架构师（开发方）、设计组（开发方）、开发人员、技术测试负责人、技术测试人

9、员、QA、CM表4. 评审人员的选择建议3. 在决定了评审人员后，评审组织者要注意以下事情： 为评审人员分配任务，对任务的分配有以下建议n 可以根据评审人员的职责、技术特性等分配任务。如在需求分析同行评审中测试人员可以关注可测试性与一致性，其他人员要关注可实现性与完备性等。n 最好不要分配评审人员关注 XX 页至XX 页这样的任务。n 任务的分配要保证某一个特性或部分最少有两个评审人员关注，这样可以防止有一个评审人员没有做好准备以至于有特性或部分没有做好准备而导致评审会议延期或取消。n 在任务分配时，评审组织者可以指明评审人员要关注的评审要点，以利于评审人员的准备。 为评审会议指定一名记录员，

10、记录员可以是评审组织者与朗读者以外参加评审会议的其他任何人。 如果计划了评审介绍会议，作者要为评审介绍会议做好准备。 评审组织者要在作者的协助下准备评审资料并发送给评审人员。4. 评审组织者要验证评审计划阶段是否完成，可以开始下一阶段工作。 评审会议时间已经确定，评审人员也已经确定并有足够的时间进行准备。 评审人员的任务已经分配，包括朗读者。 如果决定举行介绍会议，作者已做好准备。 评审资料已经准备完毕，并与评审会议通知一起发送给了评审人员。每个评审人员都确认收到了评审资料与会议通知。3.2.3 介绍会议1. 介绍会议的目的是向评审人员介绍被评审的软件工作交付物的背景、结构与基本原理，使评审人

11、员对被评审的软件工作交付物有大概的了解，评审组织者可以着重指出需评审人员注意的部分以利于评审人员的准备，作者可以准备幻灯片以利于沟通。2. 评审组织者可以在介绍会议上再次明确评审人员的任务，同时再次获得评审人员的承诺。3.2.4 预评审1. 评审组织者要验证入口准则 每个评审人员都收到了评审资料与会议通知，明确了任务安排并有时间进行准备。 评审人员承诺会为评审会议做好准备。2. 评审人员要检查被评审的软件工作交付物对需求的满足、对标准、过程的符合性以及检查项中的每一项细节，以发现问题与提出建议，并在会前半个工作日完成同行评审过程记录反馈表中的缺陷反馈表并发送给所有评审会议参加人员，同时评审人员

12、要记录在准备阶段的工作量。 评审组织者是评审人员的一员，也要为评审会议做好准备，在评审会议前半个工作日，评审组织者要验证其他评审人员的准备，将评审人员所提出的问题整理并找出其中的全局性问题。3. 评审组织者验证本阶段的完成准则 是否所有评审人员都做好了准备，如果有 30%以上的评审人员没有做好准备，建议评审会议延期。如果有部分内容或特性没有评审人员做好准备，评审会议延期。3.2.5 评审会议由评审组织者控制的会议是一个正式的会议。它的目的是尽可能找到软件工作交付物中的缺陷。为了保证评审人员的注意力，对评审会议地点有以下要求： 安静，不会受到他人的打扰。 有足够的空间，不会拥挤，空气良好。1.

13、评审组织者要验证入口准则。 评审人员是否做好了准备，为了提高评审会议的效率，建议没有做好准备的评审人员不要参加会议。 评审人员的准备时间已得到了记录。2. 会议进程 会议首先讨论评审组织者总结的全局性问题。而后按顺序讨论被评审的软件工作交付物的内容并识别缺陷。也可以只讨论在会前评审人员提出的问题与建议。 朗读者要找出与之关联上下文与参考资料，要在评审人员与作者之间达成一致。 当发现问题时，评审人员要达成一致，如果有争议，评审人员可以要求作者做出解释。评审组织者要控制会议进程，为了让评审人员的注意力保持在发现错误与缺陷而不是争吵与解决问题上，每个问题时间不要超过3 分钟。 当确定为缺陷时，首先要

14、确定引入阶段，而后评审组织者在评审人员与作者的协助下确定错误或缺陷的性质与种类。性质为三种：严重、一般、建议。 评审组织者要控制会议，为了保证效率，建议每小时休息 5-10 分钟。 记录员在评审会议上记录发现的每个缺陷，标识位置，为了方便作者的修改。 在评审会议最后阶段，评审组织者要决定是否对修改后的软件工作交付物进行再次评审。 记录员要在会后一个工作日内完成同行评审总结报告中的缺陷汇总表并发送给作者与评审人员，抄送项目组成员与相关小组成员。 在评审会议结束时，评审组织者应总结评审会议，包括以下内容：n 评审花费的总工作量n 在会前提出的问题数。n 评审会议时间。n 所标识的缺陷数量。3. 评

15、审组织者要验证完成准则。 软件工作交付物已全部被评审。 所发现的缺陷都得到了记录。3.2.6 缺陷的修改与验证1. 评审组织者验证入口准则。 评审会议已召开，缺陷得到了识别与描述。2. 作者根据评审意见对被评审的软件工作交付物进行返工，修改所发现的缺陷。3. 评审组织者负责验证缺陷的修改，可以要求评审人员的协助。4. 作者可以请求评审人员的协助，召开会议讨论解决缺陷的方法。5. 对以前阶段引入的缺陷进入变更流程处理。6. 评审组织者跟踪缺陷的状态，在评审会议上发现的缺陷初始状态为 Open，如果解决为Close，SVNB 可以决定缺陷挂起，在以后解决，挂起的原因要加以注明。在项目结束时，要对挂

16、起的缺陷做出最终决定。7. 在缺陷修改完成后，评审组织者要完成同行评审总结报告8. 评审组织者验证完成准则。 作者修改了软件工作交付物，没有缺陷处于 Open 状态。 作者及其他人员的修改工作量已记录。 同行评审总结报告完成，评审的文档进行管理和控制。3.3 走查流程3.3.1 计划1. 开发经理要验证入口准则。 所有没有进行正规检视评审的代码与详细设计说明书都要进行走查评审。 如果是代码，则应通过编译。 开发经理应审核计划评审的软件工作交付物以确认可以进行评审。 被评审的软件工作交付物有明确的标准与检查表，所有的项目组成员对此达成一致。2. 开发经理要计划走查。 为走查选择 2-4 名评审人

17、员。 每次评审的规模不要过大，走查的时间建议不要超过 1 小时。 计划评审会议时间。如果需要可以指定专人负责会议组织安排。要计划评审人员与作者的工作量，将评审人员准备与参加评审会议排入工作计划。 确定评审所要遵循的标准与检查表。 在确定了评审会议时间后，作者要将被评审的软件工作交付物与相关参考资料、标准、检查表发送给评审人员以利于准备。3. 项目技术经理要验证完成准则。 所有的评审人员都收到了评审资料与会议通知。3.3.2 准备1. 开发经理验证入口准则 每个评审人员都收到了评审资料与会议通知，包括被评审的软件工作交付物及其标准、检查表等。2. 评审人员的准备。 评审人员的准备是指对被评审的软

18、件工作交付物应遵循的标准、过程与检查表的准备，评审人员要在评审前明确这些标准以在评审会议上发现缺陷。 为了利于评审，建议评审人员了解被评审的软件工作交付物的背景及相关资料。3. 开发经理验证完成准则。 评审人员做好了准备，对软件工作交付物所应遵循的标准达成一致。3.3.3 评审会议1. 由作者主导的评审会议可以是一个正式的会议也可以是一个非正式的会议。2. 会议进程： 会议由作者控制。 作者引导评审人员通读被评审的软件工作交付物，评审人员在其中发现缺陷并协助作者确认引入阶段、性质。在会议上可以讨论解决缺陷的方法。 记录员要记录所发现的缺陷及其属性并在会后一个工作日内生成同行评审总结报告中的缺陷汇总表。3. 项目技术要对验证完成准则 软件工作交付物已经全部被评审。 所发现的缺陷已经记