51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 10486|回复: 14
打印 上一主题 下一主题

请教各位一个问题:同行评审和技术评审的区别,请详解

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2004-6-8 10:00:42 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏

该用户从未签到

2#
发表于 2004-6-8 17:10:53 | 只看该作者
同行评审是指一类事物——通过评审这种方式进行质量控制
技术评审是诸多同行评审中的一种。
它应参照公司制定的同行评审相关规程就行具体的评审操作。
回复 支持 反对

使用道具 举报

该用户从未签到

3#
发表于 2004-6-8 18:57:01 | 只看该作者
还是没太明白
不过,楼主为什么想区分这两个名词呀
回复 支持 反对

使用道具 举报

该用户从未签到

4#
发表于 2004-6-10 12:44:48 | 只看该作者
技术评审和同行评审是两个不同层次的概念。
以需求阶段的评审举例子:
1、针对《软件需求规格说明书》的评审,采用同行评审的方式,评审的输入是《软件需求规格说明书》。同行评审是CMM的一个KPA。
2、针对需求阶段的工作评审,采用技术评审的方式,评审的输入包括《软件需求规格说明书》《系统测试计划、方案、测试用例》、度量数据等等其他的交付件,技术评审的对象是整个需求阶段的活动,通过评审,判断需求阶段的工作是否达到了要求,是否可以进入到设计阶段。

同行评审着眼的是微观流程,技术评审着眼的是宏观流程,关注的是大的开发阶段点的评审。
回复 支持 反对

使用道具 举报

该用户从未签到

5#
发表于 2004-6-23 15:25:33 | 只看该作者
个人觉得    正式技术评审 = 同行评审
都是从技术层面上对软件工作产品进行深入的检查,主要侧重于工作产品的完整性、正确性、可行性。
回复 支持 反对

使用道具 举报

该用户从未签到

6#
发表于 2004-6-23 18:44:24 | 只看该作者
qatest的解释很清楚,总算搞明白了,谢谢!
回复 支持 反对

使用道具 举报

该用户从未签到

7#
发表于 2007-10-11 14:24:36 | 只看该作者
同行评审

同行评审是指进行软件产品验证的活动,其目的是为了及早和高效地从软件工作产品中识别并消除缺陷。与技术评审不同,同行评审的对象一般是部分软件工作产品,其重点在于发现软件工作产品中的缺陷。所谓同行是指和生产者在被评审的软件工作产品上有相同的开发经验和知识的人员。一般来讲,不建议管理者作为同行参与同行评审,也不应使用同行评审的结果去评价产品生产者。
与一般评审流程相似,同行评审过程包括策划、准备和实施三个阶段。正式的同行评审一般采取会议的形式。同行评审负责人负责组织符合同行评审准备就绪准则的软件产品进行同行评审。同行评审会议重点在于确定产品的缺陷而不是如何解决问题。在会议结束之后,软件产品的生产者依据同行评审记录修正软件产品缺陷,然后由同行评审负责人确认缺陷的修正。
回复 支持 反对

使用道具 举报

该用户从未签到

8#
发表于 2007-10-11 14:31:49 | 只看该作者
同行评审


前几天,有位朋友问我同行评审的东东,今天就借此机会把一份看到的文章转给大家。

同行评审

同行评审简介
定义:由软件工作产品生产者的同行遵循已定义的规程对产品作的评审,目的在于识别出缺陷和需改进之处。

【同行评审类型】
正式评审(INSPECTION)
走查(WALKTHROUGH)
检查(DESKCHECK)

非正式
工作产品没有完成,正在开发中
不需要遵循明确定义的过程
正式
作者已经确认工作产品已经完成
评审会议遵循一个已经明确定义的过程
参与人员有明确的职责与检查表.
不同的角色
明确定义的进入与完成准则

【同行评审对象 】
Requirements Definition Document (RDD),
Software Requirements Specification (SRS),
Project Plan (PP), SQA Plan
Software Configuration Management Plan (SCMP),
Software Design Document (SDD) (HLD & LLD),
Test Plans (TP), Test Cases (TC),
Code
Test Report
User Document

一组在要评审的软件工作产品领域方面有经验的同行,确认工作产品是否正确
是软件开发、维护过程的重要组成部分
将注意力集中到尽可能在缺陷的引入阶段发现缺陷,不要将缺陷遗留到下一阶段
同行评审无法发现所有的缺陷,但是目的是尽可能发现更多的缺陷

尽早地和高效率地从软件工作产品中消除缺陷
尽可能在缺陷的引入阶段就发现它们
收集度量数据,为缺陷预防建立基础
交流技术信息,培训参与者

【同行评审与测试的比较】
1.同行评审的成本低
往往愿意在测试中花费三周的时间,而不愿意在同行评审中花费三天的时间
2.同行评审的效率高
Mind Test的特点(测试用例的执行能够发现问题,但经验是不可替代的)
同行评审更多地定位问题发生的原因,而测试首先关注于现象

同行评审【CMM】
目标1 :同行评审的活动根据计划执行
要求
活动1:计划同行评审活动并文档化
目标2 :标识并去除软件工作产品中的缺陷
要求
活动2:根据文档规程执行同行评审
活动3:纪录同行评审活动的缺陷数据与过程数据
承诺1:遵循组织政策
能力1:充足的资源与资金
能力2:同行评审组织者接受培训
能力3:评审专家等接受培训
测量1:纪录测量数据并判断活动状态
验证1:SQA验证同行评审活动

【同行评审过程】
1.入口标准
2.计划同行评审
3.介绍会议(可选)
4.准备
5.缺陷纪录会议
6.编辑、返工与跟踪
7.缺陷分类、原因分析
8.过程改进、更新同行评审数据库
9.同行评审结束

【入口标准】
由评审组织者检查文档是否可以进行同行评审,如果问题太多的文档会浪费大家的时间
【计划同行评审】
确定评审专家
准备检查表
如果需要,提供额外的检查表(需求与设计之间的关系)
评审专家之间的角色分配
确定准备时间与会议时间
【介绍会议(可选)】
关于会议的安排
会议的日程安排
角色的分配
同行评审要达到的目的
评审对象内容的介绍
介绍评审对象的内容(一般是作者)
作者回答评审专家的问题
【准备】
同行评审专家自己发现缺陷并填写缺陷纪录表
准备工作非常重要
准备不充分的同行评审会议往往会蜕变成一次介绍会
【缺陷纪录会议】
评审组织者确保评审会议的有序进行
所有的评审专家提交自己发现的缺陷
作者可以对每个做出简短的回答
会议的主要目的是纪录缺陷
一般来说,至少每两分钟纪录一个缺陷
【编辑、返工与跟踪】
作者修改缺陷并更新缺陷的状态
【评审组织者验证缺陷】
必要时,评审组织者可以委托其他人验证
【缺陷分类、原因分析】
分析缺陷数据,根据缺陷类型、缺陷严重度、缺陷类别和缺陷来源对缺陷分类并召集缺陷原因分析会议
列出导致缺陷的原因
例如可以通过头脑风暴法来列出原因
【针对这些原因提出改进措施】
技能培训不足、标准不完整等
评审组织者负责提交改进措施的建议
【过程改进、更新同行评审数据库】
负责同行评审的SEPG定期与评审组织者分析不同项目的同行评审数据、缺陷原因等内容并改进过程
定期更新同行评审数据(生产率等数据)
【同行评审结束】
评审组织者检查同行评审的各个方面,确保同行评审所有的内容已完成
报告所有的度量数据

【同行评审的数据度量】
主要问题的个数/同行评审投入的总工作量
工作量一般用人时来表示
工作量包括准备、发现以及更正等所有环节和方面的工作量
一般在会议缺陷会议结束时估计,然后在同行评审结束时得到实际值
我们的效率是否正常/工作产品是否正常--看看我们的成就!
问题纪录的速率
纪录问题的个数/评审会议所用的时间,一般用个数/分钟表示
评审会议结束后得到问题纪录的速率
反映评审会议的控制是否得当
评审专家的准备是否充分
主要问题与所有纪录项的比率
主要问题个数/所有纪录项个数
判断角色分配是否合理

【同行评审过程】
读者解释软件工作产品内容.
评审组织者提出评审专家事先发现的问题
评审专家提问.
作者解释,但是只能是澄清问题
评审专家确定是否是缺陷,在要成一致
记录员记录.
确定缺陷性质、引入阶段
要求读者进入下一阶段.
【同行评审的角色】
评审组织者
记录员
读者(可选)
作者
评审专家

【评审组织者的职责】
具有技术技能
负责引导一次高效的同行评审,如果效率不高,要找出原因.
保证同行评审符合过程
确认评审专家的准备
避免没有准备好的评审专家参加会议
确认进入与完成准则
验证缺陷的修改
确保同行评审度量数据进入组织过程数据库

【记录员职责】
正确地将评审会议中发现的所有缺陷和评审组织者一起确定缺陷的描述.
必须对评审对象相关的技术术语等了解

【读者职责(可选)】
细读并了解评审对象与相关资料
在会议上朗读工作产品并做出解释
确定逻辑结构并解释,发现逻辑问题

【作者职责】
与评审组织者一起确定评审专家
及时提交正确的工作产品
如果需要介绍会议,为介绍会议做准备
参加评审会议
不要引起争议
根据发现的缺陷,确定修改完成日期
根据评审发现,修改工作产品

【评审专家职责】
检查评审对象,不漏掉细节
评审工作产品,而不是作者
提出问题而不是指责
发现而不是解决缺陷
和作者共同负责
评审专家必须受到过同行评审过程培训.
4-5个评审专家,包括评审组织者
可以根据组织数据寻找评审专家
包括下一阶段的人员以了解工作产品
可以安排新员工参加评审会议以了解过程与标准.
建议可以对作者的业绩做出评价的人不要参加
所有的参加者要有兴趣并有时间做好准备
至少给评审专家两个工作日时间做准备

【里程碑评审与同行评审的区别】
目的不同
同行评审的目的是发现并解决问题
里程碑评审的目的是评价当前的工作并批准下一阶段的计划
参与人员不同
同行评审强调同行
里程碑往往由项目组以外的管理层决策
时间点不同
同行评审可以在项目进行中的任何时间点举行
里程碑在确定的时间点举行,同行评审通常作为里程碑的输入

【同行评审指南】
同行评审的时间安排
评审计划
项目应工作量安排中应有5-10%的工作量用于同行评审.
对高风险或技术复杂的要安排额外的工作量
把文档分为比较小的部分进行同行评审,每次会议不超过2小时
同行评审专家的互补性
经验表明,同行评审的参加人员在他相关的技术领域与方向发现缺陷的效率较高
这就需要我们为参加人员分配职责
评审会议参加人员要从不同和技术角度发现缺陷

正常:评审专家做好准备,预计不需要再次评审
延期:30%以上评审专家没有做好准备.
取消:发现问题过多,估计要进行第二次同行评审

确认评审对象的所有部分都得到了评审
每个评审专家提出的问题都得到了讨论.
当评审专家讨论起解决方案时,要求他们在会后讨论

如果一个评审专家破坏了会议进程,可以温和地建议休息一下,提醒后再召开
如果评审专家总是迟到,延期会议并报告原因
如果一个评审专家总是提前离开,终止会议并报告原因
如果在一个问题上超过3分钟,建议做出结论并到下一个问题
如果评审专家之间有不同意见,作出记录,得到结论并到下一个问题
评审作者而不是人,例如用“这个假设是错误的”而不是“你的假设根本不对”

【使用检查表(CheckList)】
检查表是评审专家在准备阶段使用的工具.
检查表应包括大多数的问题
检查表应在使用的过程中不断更新

转载请注明源自www.SCMLife.com,请保留版权. 本贴地址:http://bbs.scmlife.com/viewthread.php?tid=15
回复 支持 反对

使用道具 举报

该用户从未签到

9#
发表于 2007-10-11 14:34:54 | 只看该作者

评审

评审

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?(注-册)加入51Testing

x
回复 支持 反对

使用道具 举报

该用户从未签到

10#
发表于 2007-10-17 14:41:13 | 只看该作者
rerererererererer
回复 支持 反对

使用道具 举报

该用户从未签到

11#
发表于 2007-10-17 14:44:28 | 只看该作者
rerererere
回复 支持 反对

使用道具 举报

该用户从未签到

12#
发表于 2012-2-7 10:55:16 | 只看该作者
有帮助,谢谢!
回复 支持 反对

使用道具 举报

该用户从未签到

13#
发表于 2012-2-29 23:09:57 | 只看该作者
{:4_83:}摇身一变,伤不起,有点冗长
回复 支持 反对

使用道具 举报

该用户从未签到

14#
发表于 2012-3-14 11:46:26 | 只看该作者
学习了~
回复 支持 反对

使用道具 举报

该用户从未签到

15#
发表于 2012-11-8 09:17:49 | 只看该作者
哦也也  学习
回复 支持 反对

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-11-23 06:29 , Processed in 0.082503 second(s), 29 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表