码迷,mamicode.com
首页 > 其他好文 > 详细

浅谈Peer Review(同行评审)

时间:2015-04-12 11:52:38      阅读:162      评论:0      收藏:0      [点我收藏+]

标签:

    这周的《软件测试技术》,我们接触到了同行评审(Peer Review),并结合检测车位的说明书进行了实例分析。那么下面我就简单介绍下何为PR?

    从维基百科中,我们知道同行评审(Peer Review,在某些学术领域亦称Refereeing),或译为同行审查,是一种学术成果审查程序,即一位作者的学术著作或计划被同一领域的其他专家学者评审。一般学术出版单位主要以同行评审的方法来选择与筛选所投送的稿件录取与否,而学术研究资金提供机构,也广泛以同行评审的方式来決定研究是否授予资金、奖金等。同行评审程序的主要目的是确保作者的著作水平符合一般学术与该学科领域的标准。在许多领域著作的出版或者研究奖金的颁发,如果没有以同行评审的方式来进行就可能比较会遭人质疑,甚至成为某出版物、作品是否可以被称为学术出版物的主要标准。

     我们都知道一个软件的完整形成需分为以下几个阶段:

      (1) System analysis and design

      (2) Software requirement analysis

      (3) System outline design

      (4) Software detailed design

      (5) Coding and unit test

      (6) Software component test

      (7) Software configuration test

      (8) Software system test

      (9) System acceptance

   在这每个阶段中都应该安排相应的评审活动,PR的组织形式则分为技术评审(Technical review ),正规检视(Formal Inspection),走读(Walkthroughs),管理评审(Management Review)。组织形式有严格的,也有松散的。前三个同行评审关键在于技术专家和开发同行。管理者不应该参与同行评审否则会改变评审过程并且歪曲参与者的客观性。管理评审参与者是管理者,目的是确保项目的进展和资源的合理分配。

     一般而言,PR的过程如下图所示

          技术分享

   接下来我会逐一对走读、技术评审和正规检视进行介绍。
一、走读( Walkthrough)的目的是要评价一个产品,通常是软件代码。走读一直以来都与代码检查联系在一起,其实走读也可以应用到别的产品(如结构设计、详细设计、测试计划等文档)上。而走读的最主要目标是要发现缺陷、遗漏和矛盾的地方,改进产品和考虑替换的实现方法。另外走读也有一些其他的目的,包括技术的交换、参与人员的技术培训、设计思想的介绍等。
二、技术评审(Technical Review),是一种的同行审查技术。其主要特点是由一组评审者按照规范的步骤对软件需求、设计、代码或其他技术文档进行仔细地检查,以找出和消除其中的缺陷。技术评审也简称“审查”(Inspection)。而技术评审目的主要包含下面几点:
(1)发现软件在功能、逻辑、实现上的错误;
(2)验证软件符合它的需求规格;
(3)确认软件符合预先定义的开发规范和标准;
(4)保证软件在统一的模式下进行开发;
(5)便于项目管理。
     在这其中需要用到评审小组,评审小组至少由3人组成(包括被审材料作者),一般为4至7人。通常,概要性的设计文档需要较多评审人员,涉及详细技术的评审只需要较少的评审人员。
      评审小组应包括下列角色:
评审员(Reviewer、Inspector)
      评审小组中的每一成员,无论他(她)是否是主持人、作者、宣读员、记录员,都是评审员。他们的职责是在会前准备阶段和会上检查被审查材料,找出其中的缺陷。合适的评审员人选包括被审材料在生命周期中的前一阶段、本阶段和下一阶段的相关开发人员。例如,需求分析评审员可以包括客户和概要设计者,详细设计和代码的评审员可以包括概要设计者、相关模块开发人员、测试人员。
主持人(Moderator)
      支持人的主要职责,在评审会前负责正规技术评审计划和会前准备的检查;在评审会中负责调动每一个评审员在评审会上的工作热情,把握评审会方向,保证评审会的工作效率;在评审会后负责对问题的分类及问题修改后的复核。
宣读员(Reader)
      宣读员的任务是在评审会上通过朗读和分段来引导评审小组遍历被审材料。除了代码评审可以选择作者作为宣读员外,其他评审最好选择直接参与后续开发阶段的人员作为宣读员。
记录员(Recorder)
      记录员负责将评审会上发现的软件问题记录在“技术评审问题记录表”。在评审会上提出的但尚未解决的任何问题以及前序工作产品的任何错误都应加以记录。
作者(Author)
     被审材料的作者负责在评审会上回答评审员提出的问题,以避免明显的误解被当作问题。此外,作者须负责修正在评审会上发现的问题。
      实践证明,同行评审特别是技术同行评审是最有效的实践活动确认产品质量,以及及时交货。在NASA和工业界表现出它的效益。提高质量,降低成本。把错误终结在其萌芽阶段。防止其扩散到后续工程,减少整体rework返工成本费用。另外的好处是提高团队的工作效率。增进团队人员间的交流,快速培养新人,教育项目组成员的高效开发实践。
三、正规检视(Formal Inspection)是在软件开发过程中进行的、发现、排除软件在开发周期各阶段存在的错误、不足的过程,是一种软件静态测试方法,其生存周期为软件的开发周期,应用与开发过程中产生的(非阶段性)软件文档和程序代码。

其中在软件开发的各个阶段中,如何进行恰当的选择以上三种技术则成为了重中之重,可简单地用下图来表示:

技术分享

当然同行评审并非完美,也存在一些常见的问题,比如:

(1)没有评审计划

(2)专家选择不合适

(3)没有充分的准备

(4)评审会议偏离主题和重点

(5)没有使用CheckList作为指导

(6)评审会议中过多争论占用大量时间

(7)问题修改后跟踪不力

 

 

浅谈Peer Review(同行评审)

标签:

原文地址:http://www.cnblogs.com/xlwm/p/4419137.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!