德信无线标准软件过程TSSP-18-软件同行评审流程介绍

软件同行评审流程介绍

TF.SWChangeHistoryRecordDateVersionComposerModifyCause2005-7-180.1XingWenjuanInitial2005-10-310.2XingWenjuanModifyaccordingto<PeerReviewProcess>Version0.62006-4-140.3XingWenjuanUpdate<PeerReviewRecordForm>template提纲1.为什么需要同行评审2.同行评审的目的、对象和意义3.同行评审过程概述4.角色与职责5.评审过程解析6.相关流程及规程7.形成高效的评审氛围附一：评审组长名单附二：评审记录单附三：《文档分发式评审签单》模板1.为什么需要同行评审

原因一：

技术工作之所以需要接受同行评审就好比铅笔需要橡皮一样，请记住： 凡人皆有错！原因二：

尽管人们善于找出自己所犯的部分错误，但是相对于其他任何人而言，大量的各种错误还是很容易逃脱创作者的眼睛，这被称为思维定势。

2.同行评审的目的、对象和意义同行评审的目的 尽早地发现和消除工作产品中的缺陷，从而有效地提高产品的质量同行评审的对象 开发过程中的所有工作产品，包括代码、基线、文档等同行评审的作用通过消除工作成果的缺陷而提高产品的质量；越早消除缺陷就越能降低开发成本；开发人员能及时地得到同行专家的帮助和指导，无疑会加深对工作成果的理解，更好地预防缺陷，在一定程序上提高了开发生产率。3.同行评审过程概述

3.1评审方式

文档正式评审、文档分发式评审； 代码正式评审、代码非正式评审（桌面评审）；3.2评审原则

评审应关注接受评审的工作产品，而不是针对作者，评审结果不用于评价作者个人表现；同时，评审应将注意力放在缺陷的判定上，而不是缺陷的解决上，应限制争论和辩驳。

3.3评审过程

评审准备、评审执行、问题跟踪

3.4评审审计

SQA人员对评审的执行情况进行抽查（具体抽查范围和抽查频率在SDP的评审计划中定义）

3.5评审人数

评审人员应为三至七人，并且为奇数（不含SQA、作者、学习观摩人员）4.角色与职责作者

申请和组织评审，负责工作产品的讲解，评审问题的答辩，并按关闭计划修改评审出的问题；文档分发式评审时的问题记录和汇总提交；评审组长

审查并批准评审，指定评审成员，负责评审会议前的走查工作（并负责记录走查时发现的问题），评审会议的主持，协助分析评审中发现的问题，制定关闭计划，验证并关闭评审问题

；评审成员

参加评审会议，审查评审对象的正确性和合理性，通过场景联想触发发现新的问题；记录员

记录评审出的问题，负责评审会议中《评审记录单》的填写，并在评审会后将问题提交至评审管理工具

；SQA

抽查评审过程及评审记录，对评审记录进行分析

。代码正式评审作者申请—组长走查并记录预评审问题—组长批准申请—评审会—记录员完成《评审记录单》—记录员提交问题到PRM中—作者修改问题—组长验证关闭问题—组长关闭评审代码非正式评审

作者申请—组长批准—评审会—记录员完成《评审记录单》—记录员提交问题到PRM中—作者修改问题—组长验证关闭问题—组长关闭评审文档正式评审

作者申请—组长批准—评审组内预评审—作者汇总预评审问题至《评审记录单》—组长判定评审是否如期进行—评审会—记录员完成《评审记录单》—记录员提交问题到PRM中—作者修改问题—组长验证关闭问题—组长关闭评审文档非正式评审

作者申请—组长批准—分发工作产品—评审成员邮件反馈评审问题—作者提交问题到PRM中—作者修改问题—组长验证关闭问题—组长关闭评审—作者完成《文档分发式评审签单》 本节内容按评审活动的顺序，对各种评审方式具体活动做详细讲解：5.1评审准备5.1.1代码正式评审5.1.2文档正式评审5.1.3代码非正式评审

5.2评审会议5.3评审问题跟踪过程5.4文档分发式评审过程5.4.3文档分发式评审_评审问题跟踪请不要忽视此确认过程！作者将签字确认后的《文档分发式评审签单》（参见《文档分发式评审签单》模板

◎）及最终文档，交给SCM进行发布。当评审组长认定本次评审失败时，该评审转成正式评审，且作者需在评审记录中记录后续评审记录号

代码正式评审作者申请—组长走查并记录预评审问题—组长批准申请—评审会—记录员完成《评审记录单》—记录员提交问题到PRM中—作者修改问题—组长验证关闭问题—组长关闭评审—交《评审记录单》给项目SQA代码非正式评审

作者申请—组长批准—评审会—记录员完成《评审记录单》—记录员提交问题到PRM中—作者修改问题—组长验证关闭问题—组长关闭评审—交《评审记录单》给项目SQA文档正式评审

作者申请—组长批准—评审组内预评审—作者汇总预评审问题至《评审记录单》—组长判定评审是否如期进行—评审会—记录员完成《评审记录单》—记录员提交问题到PRM中—作者修改问题—组长验证关闭问题—组长关闭评审—交《评审记录单》给项目SQA文档非正式评审

作者申请—组长批准—分发工作产品—评审成员邮件反馈评审问题—作者提交问题到PRM中—作者修改问题—组长验证关闭问题—组长关闭评审—作者完成《文档分发式评审签单》让我们再回顾一下四种评审方式……5.6评审问题状态说明Opened当问题被提交时状态为Opened；Closed评审组长确认问题已经修改正确时，将问题状态置成Closed；Rejected当评审组长最终确认该问题不是问题时，将其状态置Rejected；Postponed不能立刻解决的问题，经SPM在《评审记录单》上特采后，评审组长将其状态置成Postponed；返回：5.3评审问题管理跟踪◎5.7评审问题级别定义级别定义1致命问题2严重问题3一般问题4轻微问题（如，没写History）5.8评审对象与角色对应表请评审组长依此表选择评审成员5.9评审方式选择

评审方式评审对象文档分发式评审文档改动页数低于2页已入库的文档，版本间变化较少的版本升级文档正式评审

不满足文档分发式评审进入条件的其他所有文档代码非正式评审

变更代码50行且文件5个以下代码正式评审

不满足代码非正式评审进入条件的其他所有代码返回：5.1.1代码正式评审◎5.4.1文档分发式评审◎5.10复审参考原则复审定义：评审出的问题有必要在改正之后再次评审，此时的再次评审称为复审复审原则：发现的问题是否超过缺陷密度上限（参见组织数据库中定义）代码非正式评审复审时转为正式评审的参考原则：存在严重逻辑问题、软件结构存在严重问题、需求理解不清楚、代码混乱、存在严重潜在危险文档分发式评审复审时转为正式评审的参考原则：修改太多，不符合文档分发式评审的进入条件返回：5.2评审会议◎6.相关流程及规程《同行评审过程》Version0.6《软件工程师开发流程》《CodeReviewChecklist种种原因Top25》7.形成高效的评审氛围1.评审前，充分准备 作者，应提前准备好待评审的工作产品、测试手机、会议室等，避免因准备工作不到位而造成时间浪费；2.评审中，积极合作 作者讲述清晰、准确；评审组长和评审成员检查认真、负责； 记录员记录准确、详尽；3.评审后，认真提交 被评审人认真修正问题； 评审组长仔细审核修正结果；附一：评审组长名单Skyworks:App组:赖旭芳、詹倩雯、张小东、王俊杰、刘辉、张海宁、靳晓雨;DS组：王伟、马国欣、丁伟德、陈雅嘉、段晓亮；Driver组：彭海波、原慧、张捷、庞仙平；WAP组：赖旭芳、曲宗钦(要求review时该组人员全部参加)；WinCE:System 张建朝、李雪峰、李东华、王振刚、翟建强、田虎；App 李新征、韩双焕、马洪波、孙伟、高雁；CETK 陈坚、赵懿、张鹏、丁亚琼、张宁、李伟春；Driver 王潍、王宇、王爱军、李光宇、万敬麟、廖丽荣、赵苏、王大宇、李伟森、 周韬、阮