同行评审指南V10

《同行评审指南V10》由会员分享，可在线阅读，更多相关《同行评审指南V10（12页珍藏版）》请在金锄头文库上搜索。

1、文件编号： 同行评审指南同行评审指南 本本 V1.0 文文 档档 编编 号号保保 密密 等等 级级机密机密 作作 者者最后修改日期最后修改日期 审审 核核 人人最后审批日期最后审批日期 文档修订记录文档修订记录 编号编号章节名称章节名称 修订内容简述修订内容简述修订日期修订日期 修订前修订前 版本号版本号 修订后修订后 版本号版本号 修订人修订人 1 2 3 4 5 6 7 8 目目 录录 1编制目的编制目的1 2适用范围适用范围1 3过程指南过程指南1 3.1软件工作交付物同行评审类型的选择1 3.2正规检视指南 .2 3.2.1同行评审组织者的选择.2 3.2.2正规检视计划.2 3.2.

2、3介绍会议.5 3.2.4预评审.5 3.2.5评审会议.5 3.2.6缺陷的修改与验证.7 3.3走查流程 .7 3.3.1计划.7 3.3.2准备.8 3.3.3评审会议.8 3.3.4缺陷的修改与跟踪.8 4附录附录9 4.1附录 1： 表格索引.9 1 编制目的编制目的 本文档的编制目的是为同行评审过程提供指导，以提高同行评审的效率，及早地发现 被评审的软件工作交付物中的错误与缺陷，提高软件交付物质量。 2 适用范围适用范围 本指南适用于XXX银行信息科技部软件开发系统的同行评审活动。 3 过程指南过程指南 开始执行该过程的必须具备的前提条件：如执行该过程的角色应具备的能力和资源、 约

3、束条件已满足等。 3.1 软件工作交付物同行评审类型的选择软件工作交付物同行评审类型的选择 项目技术经理在计划同行评审类型时可以根据表1 进行选择。 软件工作交付物类型软件工作交付物类型评审类型选择建议评审类型选择建议 需求说明书 正规检视 需求规格说明书 正规检视 软件设计说明书 正规检视 架构设计说明书 正规检视 代码正规检视 / 走查 测试用例 正规检视 / 走查 用户手册 正规检视 / 走查 计划文档 正规检视 / 走查 表 1.同行评审类型选择建议 在需求与设计过程中，在正式的正规检视之前，可以安排走查，对过程可以不具体要 求，但是必须完成同行评审总结报告中的缺陷汇总表。 为了保证同

4、行评审的效率，项目技术经理在制定项目计划时应注意以下事项： 在估计工作量时应考虑评审的工作量。 提供同行评审所需的资源，项目组成员的任务安排中要包括同行评审。 3.2 正规检视指南正规检视指南 3.2.1同行评审组织者的选择 项目技术经理在确定了要进行正规检视的软件工作交付物同时要选择同行评审组织者， 同行评审组织者要符合以下要求： 是所要评审的软件工作交付物方面的专家。 接受过同行评审组织者培训，参加过两次以上正规检视类型同行评审。 3.2.2正规检视计划 作者在软件工作交付物完成后，根据评审计划提交软件工作交付物。评审组织者要验 证正规检视的入口准则与输入物。 软件工作交付物是否使用了经批

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

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

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

8、分最小单位建议 2.评审组织者要计划评审所需准备时间，确定了评审会议时间之后，要为正规检视 选择评审人员，可以指定一名朗读者。评审人员人数建议在3-7 人之间，有数据 表明，5-6 人效率较高。评审组织者也是评审人员。需要注意的是一个为评审做 好充分准备的普通工程师发现错误与缺陷的效率要远远高于一个没做好准备的专 家，所以评审组织者一定要得到项目技术经理与评审人员的承诺，评审准备与评 审会议会安排进WBS 计划，确认选择的评审人员有充足的时间为评审做好准备。 评审人员的选择建议见表4。评审组织者选择评审人员时可以请求项目技术经理的 帮助。 软件工作交付物类型软件工作交付物类型评审人员选择建议评

9、审人员选择建议 可行性分析报告 需求分析专员、安全技术专员、应用管理员、系统维护专员、 架构管理专员、其他相关团队负责人 需求规格说明书 项目技术经理、开发经理、架构师（开发方）、设计组（开发方）、 开发人员、技术测试负责人、应用管理员、系统维护专员、 QA、CM 概要设计说明书 项目技术经理、开发经理、架构师（开发方）、设计组（开发方）、 开发人员、技术测试负责人、应用管理员、系统维护专员、QA、CM 详细设计说明书项目技术经理、开发经理、架构师（开发方）、设计组（开发方）、 开发人员、QA、CM 代码与单元测试用例开发经理、架构师（开发方）、开发人员 集成测试用例 架构师（开发方）、设计组

10、（开发方）、开发人员、技术测试负责 人、技术测试人员、QA、CM 系统测试用例 架构师（开发方）、设计组（开发方）、开发人员、技术测试负责 人、技术测试人员、QA、CM 表 4.评审人员的选择建议 3.在决定了评审人员后，评审组织者要注意以下事情： 为评审人员分配任务，对任务的分配有以下建议 可以根据评审人员的职责、技术特性等分配任务。如在需求分析同行评 审中测试人员可以关注可测试性与一致性，其他人员要关注可实现性与 完备性等。 最好不要分配评审人员关注 XX 页至XX 页这样的任务。 任务的分配要保证某一个特性或部分最少有两个评审人员关注，这样可 以防止有一个评审人员没有做好准备以至于有特性

11、或部分没有做好准备 而导致评审会议延期或取消。 在任务分配时，评审组织者可以指明评审人员要关注的评审要点，以利 于评审人员的准备。 为评审会议指定一名记录员，记录员可以是评审组织者与朗读者以外参加评 审会议的其他任何人。 如果计划了评审介绍会议，作者要为评审介绍会议做好准备。 评审组织者要在作者的协助下准备评审资料并发送给评审人员。 4.评审组织者要验证评审计划阶段是否完成，可以开始下一阶段工作。 评审会议时间已经确定，评审人员也已经确定并有足够的时间进行准备。 评审人员的任务已经分配，包括朗读者。 如果决定举行介绍会议，作者已做好准备。 评审资料已经准备完毕，并与评审会议通知一起发送给了评审

12、人员。每个评 审人员都确认收到了评审资料与会议通知。 3.2.3介绍会议 1.介绍会议的目的是向评审人员介绍被评审的软件工作交付物的背景、结构与基本 原理，使评审人员对被评审的软件工作交付物有大概的了解，评审组织者可以着 重指出需评审人员注意的部分以利于评审人员的准备，作者可以准备幻灯片以利 于沟通。 2.评审组织者可以在介绍会议上再次明确评审人员的任务，同时再次获得评审人员 的承诺。 3.2.4预评审 1.评审组织者要验证入口准则 每个评审人员都收到了评审资料与会议通知，明确了任务安排并有时间进行 准备。 评审人员承诺会为评审会议做好准备。 2.评审人员要检查被评审的软件工作交付物对需求的满

13、足、对标准、过程的符合性 以及检查项中的每一项细节，以发现问题与提出建议，并在会前半个工作日完成 同行评审过程记录反馈表中的缺陷反馈表并发送给所有评审会议参加人员， 同时评审人员要记录在准备阶段的工作量。 评审组织者是评审人员的一员，也要为评审会议做好准备，在评审会议前半 个工作日，评审组织者要验证其他评审人员的准备，将评审人员所提出的问 题整理并找出其中的全局性问题。 3.评审组织者验证本阶段的完成准则 是否所有评审人员都做好了准备，如果有 30%以上的评审人员没有做好准备， 建议评审会议延期。如果有部分内容或特性没有评审人员做好准备，评审会 议延期。 3.2.5评审会议 由评审组织者控制的

14、会议是一个正式的会议。它的目的是尽可能找到软件工作交付物 中的缺陷。为了保证评审人员的注意力，对评审会议地点有以下要求： 安静，不会受到他人的打扰。 有足够的空间，不会拥挤，空气良好。 1.评审组织者要验证入口准则。 评审人员是否做好了准备，为了提高评审会议的效率，建议没有做好准备的 评审人员不要参加会议。 评审人员的准备时间已得到了记录。 2.会议进程 会议首先讨论评审组织者总结的全局性问题。而后按顺序讨论被评审的软件 工作交付物的内容并识别缺陷。也可以只讨论在会前评审人员提出的问题与 建议。 朗读者要找出与之关联上下文与参考资料，要在评审人员与作者之间达成一 致。 当发现问题时，评审人员要

15、达成一致，如果有争议，评审人员可以要求作者 做出解释。评审组织者要控制会议进程，为了让评审人员的注意力保持在发 现错误与缺陷而不是争吵与解决问题上，每个问题时间不要超过3 分钟。 当确定为缺陷时，首先要确定引入阶段，而后评审组织者在评审人员与作者 的协助下确定错误或缺陷的性质与种类。性质为三种：严重、一般、建议。 评审组织者要控制会议，为了保证效率，建议每小时休息 5-10 分钟。 记录员在评审会议上记录发现的每个缺陷，标识位置，为了方便作者的修改。 在评审会议最后阶段，评审组织者要决定是否对修改后的软件工作交付物进 行再次评审。 记录员要在会后一个工作日内完成同行评审总结报告中的缺陷汇总表并

16、 发送给作者与评审人员，抄送项目组成员与相关小组成员。 在评审会议结束时，评审组织者应总结评审会议，包括以下内容： 评审花费的总工作量 在会前提出的问题数。 评审会议时间。 所标识的缺陷数量。 3.评审组织者要验证完成准则。 软件工作交付物已全部被评审。 所发现的缺陷都得到了记录。 3.2.6缺陷的修改与验证 1.评审组织者验证入口准则。 评审会议已召开，缺陷得到了识别与描述。 2.作者根据评审意见对被评审的软件工作交付物进行返工，修改所发现的缺陷。 3.评审组织者负责验证缺陷的修改，可以要求评审人员的协助。 4.作者可以请求评审人员的协助，召开会议讨论解决缺陷的方法。 5.对以前阶段引入的缺陷进入变更流程处理。 6.评审组织者跟踪缺陷的状态，在评审会议上发现的缺陷初始状态为 Open，如果解 决为Close，SVNB 可以决定缺陷挂起，在以后解决，挂起的原因要加以注明。在 项目结束时，要对挂起的缺陷做出最终决定。 7. 在缺陷修改完成后，评审组织者要完成同行