评审流程.docx
《评审流程.docx》由会员分享，可在线阅读，更多相关《评审流程.docx（15页珍藏版）》请在冰豆网上搜索。
评审流程
评审规程
编写
兰洋
编写时间
2013-8-1
审批
审批时间
2013-8-18
文档版本
V1.0
未经允许，不可全部或部分发表、复制、使用于任何目的。
目录
第1章引言3
1.1文档用途3
1.2阅读对象3
1.3名词术语3
1.3.1同行评审3
第2章评审定义4
2.1评审的目的4
2.2评审分类4
2.2.1审查（Inspection）4
2.2.2小组评审（TeamReview）4
2.2.3走查（Walkthrough）5
2.2.4结对编程（PairProgramming）5
2.2.5桌查（Deskcheck）5
2.2.6同行桌查（PeerDeskcheck）5
2.2.7轮查（Passaround）6
第3章正式评审流程7
3.1角色和职责7
3.2准备评审7
3.2.1概述7
3.2.2主要步骤7
3.3个人审查8
3.3.1概述8
3.3.2主要步骤8
3.4会议评审8
3.4.1概述8
3.4.2主要步骤8
3.4.3评审通过标准9
3.5缺陷追踪10
3.5.1概述10
3.5.2主要步骤10
第4章非正式评审流程11
第5章选择合适的评审方法12
5.1选择原则12
5.2针对不同目标建议的方法12
5.3几种主要评审的参加人员12
文档修订摘要：
版本
作者
说明
第1章引言
1.1文档用途
本文档为评审活动的指导文档。
主要用来说明评审的方法和流程。
它为一个组织按照正确的方法进行评审活动提供了指导。
1.2阅读对象
●项目组全体
●EPG组成员
●高级经理
1.3名词术语
1.3.1同行评审
PeerReview，在工作产品的开发者中对工作产品进行评审，用以识别并消除缺陷。
第2章评审定义
2.1评审的目的
评审的目的是保证所选择的工作产品能满足确定的需求，同时发现其中可能存在的缺陷。
2.2评审分类
按照评审的不同目的，可以进行如下分类：
评审类型
目的
举例
教育评审
让其他项目相关人员来督促与项目相关的技术论题。
管理、预备、或准入评审
向高层经理提供信息，以帮助他们做出如下决策：
发布产品、继续（或取消）开发项目、批准（或拒绝）提案、改变项目范围、调整资源、改变承诺。
《项目计划书》的评审
同行评审
寻找工作产品中的缺陷和改进契机
产品总体方案评审
CodeReview
状态评审
向项目经理和其他项目成员提供最新的项目状态信息，包括里程碑的进度、所遇的问题、识别的或受控的风险。
《项目状态报告（里程碑）》的评审
项目总结评审
对最近完成的项目或阶段进行评审，让未来的项目吸取经验。
《项目总结报告》评审
上述的同行评审是应用比较广泛的一种方法，包括审查、小组评审、走查、结对编程、桌查、同行桌查和轮查。
下面对同行评审的这几种主要类型进行较详细介绍。
2.2.1审查（Inspection）
●是一种正式、严格的同行评审发生，遵循同行评审的流程
●作者不可以作为评审的主持人，需由指定的主席担当
●审查要求每次宣读或描述产品的一小部分，然后大家提出评审意见
●需要使用标准的评审检查单，并收集评审数据
2.2.2小组评审（TeamReview）
●是一种“轻型的审查”。
是有计划的、结构化的。
但没有审查正式和严格
●作者可以作为小组评审的主持人（审查不允许）
●小组评审是由主持人询问评审者这部分是否有问题（审查要求每次宣读或描述产品的一小部分）
●小组评审方法每小时发现的错误只有审查的2/3
●小组评审适用于不需要严格审查过程的工作产品。
由于没有审查正式，小组评审可以节省出一些会议时间来讨论解决问题的思路，并对技术方法达成共识
2.2.3走查（Walkthrough）
●是一种非正式的评审。
由产品的作者将该产品向一组同事介绍，并希望他们给出问题反馈
●走查之所以不正式，是因为它通常不按照事先预定的过程进行，不制订详细的准出条件，但为了度量，需要记录相关的走查数据。
●走查中，产品作者起主导作用，而其他评审角色则通常没有定义
●走查的目的是为了发现代码中隐藏比较深的逻辑方面的错误，当测试无法定位问题时，或出现不稳定等问题时，可以对主要模块进行走查。
●审查每检查1000行代码所发现的错误比走查多50%
●走查也适用于当评审的首要目的是使别人了解产品时：
✓设计方案
✓测试文档
✓用户界面设计
2.2.4结对编程（PairProgramming）
●属于一种流行的软件开发“敏捷方法”（agilemethodology），又称为极限编程（extremeprogramming）
●在结对编程过程中，两个开发者在一个工作站上同时操作同一个程序。
这种方法有利于交流并且允许每个人的观点进行持续的、非正式的评审
●两位小组成员都非常熟悉每一段代码，可减少因人事变动所带来的知识流失。
由于搭档的实时评审，结对者可以迅速纠正错误
●结对编程开发的软件相比个人开发的软件而言，其质量更加卓越，而且开发时间更少
●因其无结构性，属于非正式的评审方法，但更象一种软件开发方法
●在大多数情况下，它不能简单替换传统的同行评审
2.2.5桌查（Deskcheck）
●在程序编写的初期，程序员常在两次编译之间仔细检查源代码以保证程序的正常进行
●是PSP的一部分
●是一种自评审，不属于同行评审
2.2.6同行桌查（PeerDeskcheck）
●除作者外只有一个人对工作产品进行检查
●完全依靠评审者本身的知识、技能和自律
●是最便宜的评审方法，特别是有技术高超的同事
●同行桌查所发现的错误只是评审者最擅长寻找的
●作者本人既不能回答评审者的问题，也听不到那些有助于发现其他错误的讨论
●是开始形成评审文化的好方法
2.2.7轮查（Passaround）
●又成为分配审查方法，由多人组成的并行同行桌查
●作者将产品副本发给几位评审员并收集整理他们的意见
●可以将待评审的产品放入共享文件夹，评审者在规定时间内以注释方式提出建议，作者负责汇总和过滤意见，并对产品进行修改
●允许每位评审者看到别人的意见，可减少冗余
●有助于缓解同行桌查的两个主要风险
✓评审者不能及时反馈
✓评审效果差
第3章正式评审流程
同行评审中的审查和小组评审均属正式评审，这里主要介绍正式评审的流程。
其他类型的评审流程可以参考正式评审的流程进行理解。
3.1角色和职责
在正式评审活动中，涉及的角色有评审发起人、作者、评审委员会/评委、评审委员会主席、PPQA、记录人员。
他们的主要职责如下：
角色
职责
评审发起人
评审发起人负责评审文档发放，会议通知，确定评审委员会主席。
作者
待评审工作成果的开发者，可能是一个人或是小组。
在评审期间，作者答复评审小组的问题，并与评审小组共同查找缺陷、商讨缺陷解决方案。
评审会议结束后，作者应当及时消除工作成果中的缺陷。
评审委员会/评委
阅读评审文档和资料，参加评审会，发表评审意见。
评审委员会成员一般由如下角色组成：
✓作者（讲述被评审文档）
✓评审主席
✓有相关经验的经理、技术负责人、总工程师（尤其是重要技术类的评审）等
✓产品的直接受益人和要求者（如，需求的评审需要客户参加）
✓项目组相关人员（主要技术负责人、测试负责人、配置管理员等）
评审委员会主席
主持召开评审会议，控制评审会议进程，给出评审结论。
QA
检查评审流程是否符合要求；检查工作产品是否符合要求
记录人员
负责会议记录，发送评审结果报告
3.2准备评审
3.2.1概述
评审发起人提出评审要求，制定评审计划，通知相关人员，及其他相关准备工作。
3.2.2主要步骤
1.发起人制定同行评审计划，计划内容包括：
✓评审会主席、参加评审的人员名单、会议记录人员
✓评审内容及文档名称
✓评审地点
✓评审要求
2.同行评审计划只需包括以上内容即可，不强制要求使用固定模板。
3.对于不同评审人员，发起人可以给出不同的评审侧重方面的建议。
涉及到多个部门和项目的评审时，评审组成员中应包括其他部门和项目的代表。
4.评审发起人参考各过程提供的《评审检查表》模板，裁剪《评审检查表》及评审标准。
5.发起人将检查表以及评审文件及其上游输入文件分发给相关人员，让相关人员了解评审要求，阅读评审文档。
6.由QA审核被评审文档与过程的符合情况。
3.3个人审查
3.3.1概述
个人审查是正式评审前必要的准备工作。
评委各自仔细阅读评审文件，并将填好内容的《评审检查表》提交给评审主席。
评审主席做简要的检查，以确定是否如期举行会议。
3.3.2主要步骤
1.评委仔细阅读评审文件，使用《评审检查表》以一致的评审准则审查工作产品，做好评审会议的准备工作。
对工作产品有不明确的地方或者看起来存在缺陷的地方，评委应在《评审检查表》中记录缺陷或问题并加以必要的说明。
2.评委将填好内容的《评审检查表》提交给评审主席。
3.评审主席应对检查单中的工作量和缺陷数据做简要的检查，核实评委在个别审查中确实投入了足够充分的时间和精力。
4.如果准备工作不充分，则应该推迟评审会议。
3.4会议评审
3.4.1概述
会议评审过程主要按以下步骤进行：
主持人宣讲、作者介绍工作成果、识别缺陷和答辩、对缺陷达成一致、会议结束决议。
3.4.2主要步骤
1.评审主席在所有评委都已提交符合要求的《评审检查表》后召开评审会议。
由计划中明确的会议记录人对会议的过程予以记录。
2.在会议上，评审主席首先宣讲本次评审的议程、责任、原则、时间限制等，然后作者简要介绍工作产品。
3.作者回答评委的问题，采用逐项审议或者逐段审议的方式，确认个别审查中所发现的缺陷和问题。
双方对每个缺陷达成共识。
4.在会议结束之前，由记录人说明在会议中发现和确认了哪些缺陷和问题，还有哪些缺陷和问题需要进一步讨论和审查，由评审主席进行总结，给出评审是否通过的判定。
5.会后，会议记录人完整填写AIQCS系统中的各项信息（问题、工时等），形成《评审结果报告》，发送给与会者。
评审报告中的问题类型分为如下几种：
✓严重：
说明错误、引起系统功能严重错误的
✓一般：
不会严重影响功能但由于会引起异议或含糊不清也必须进行修改的；
✓改进：
不影响功能描述，但希望进一步完善能得到更好效果的；
✓新问题：
不是评审对象（文档）本身的问题，但和评审对象有关；
✓需要澄清：
需要作者在会后查询资料后给大家一个澄清的；
6.对于必须参加评审会议却因为特殊原因未能到会的评审参与人可以在评审报告正式发布之前以邮件的方式表明自己对评审的意见，并抄送给所有参加评审的人员。
其邮件确认也同到会者意见一致看待，与评审报告同时存档。
3.4.3评审通过标准
评审结论有三种：
【】完全通过，进入下一阶段
【】基本通过，需做修改
【】不通过，需处理评审出的问题，再评审
评审是否通过由评审主席根据如下规则进行判断：
评审结论
判断标准
完全通过，进入下一阶段
✓没有严重问题，所有疑问均已澄清，或
✓没有一般问题和建议，对内容的正确性得到评委们认可
基本通过，需做修改。
（不需要再进行正式评审，通过轮查的方式进行后续评审）
✓每个工作产品（文档）中的缺陷≤3个严重问题，或
✓解决方案已讨论清楚，作者已明确如何修改即可满足要求
不通过，需修改评审对象（文档），再评审
✓每个工作产品（文档）中的缺陷>3个严重问题，或
✓工作产品内容要发生较大变化，评委们无法判定作者后续的修改能否满足要求
注：
在实际应用中，评审主席可以根据实际情况或评审对象的特殊性，不完全采纳上述判断标准而采取例外放行的方法。
需要在评审结论中给予说明。
3.5缺陷追踪
3.5.1概述
经过同行评审，识别工作产品的缺陷后，项目人员要进行缺陷的修改。
项目经理进行缺陷的追踪，以保证所识别的产品缺陷已全部得到解决。
3.5.2主要步骤
1.评审主席负责对评审会上发现的缺陷是否修改进行跟踪。
2.缺陷由作者解决，而问题则可以由不同人员解决。
在会议结束之前明确问题负责人及问题解决的最后期限，以便跟踪所存在的问题解决情况。
3.评审会上确认的责任人应修改识别出的所有缺陷，项目经理负责跟踪缺陷修改情况，PPQA负责验证缺陷是否被修改。
必要时重新召开评审会议，重新评审经过修改的工作产品，或讨论对待解决问题的研究分析结果（工作方式与评审会议相同）。
第4章非正式评审流程
对非正式评审不需要召集评审会。
作者将待审批的产品提交给相关的评审人员进行审批，评审人员对提交审批的产品必须在指定的时间范围内进行评审、反馈意见。
在指定时间内没有批准或否决的产品将被认为是批准了。
如果产品没被批准，应将问题反馈给产品提交者。
如果问题解决了，产品应重新提交审批。
重新提交的产品只有在对原有问题的解决不令人满意的情况下，才能被再次否决，从而排除无休止的审批循环，否则可能会严重影响项目的进度情况。
第5章选择合适的评审方法
5.1选择原则
●组织应该选择最便宜的评审方法来将产品的风险降低到可接受的程度
●基本原则：
对高风险的工作产品使用正式评审，对低风险的构件使用相对便宜的技术
✓在需求开发阶段，先使用一系列的轮查，使参与评审的客户以非正式的方式评审越来越大的需求规格说明
✓将由多个分析员编写的各部分规格说明汇总后，再采用正式评审，并再一次邀请关键用户参与评审
●在何时使用何种评审方法，最佳途径就是在组织中记录下评审的有效性和效率数据
5.2针对不同目标建议的方法
评审活动
审查
小组评审
走查
结对编程
同行桌查
轮查
项目级活动
有关项目计划及子计划的评审
×
×
有关需求规格说明书的评审
×
×
×
×
有关总体设计规格说明书的评审
×
×
测试Case评审
×
×
有关产品缺陷的评审
×
×
×
×
×
×
CodeReview
×
×
×
有关发布的评审
×
×
培训其他组员以熟悉产品
×
×
×
组织级活动
组织级各种计划的评审
×
×
各种结果报告的评审
×
×
组织PCB方案和报告
×
×
5.3几种主要评审的参加人员
评审
项目经理
测试经理
高级经理
需求分析
总工程师
设计工程师
开发工程师
测试工程师
QA
配置管理员
客户
记录员
市场部售前
项目计划评审
V
V
V
V
V
V
V
V
V
测试计划评审
V
V
V
V
V
配置计划评审
V
V
V
需求规划说明评审
V
V
V
V
V
V
V
V
V
V
总体设计方案评审
V
V
V
V
V
V
V
V
V
详细设计方案评审
V
V
V
V
V
CodeReview
V
发布评审
V
V
V
V
V
V
V
V
升级会员 