例解:如何分析同行评审的度量数据?

在进行同行评审时,一般可以积累如下的度量数据:
(1)      评审文档或代码的规模
对于需求文档的规模一般是采用页或功能点为度量单位;
对于测试用例的规模一般是采用个或页为度量单位;
对代码的规模一般是采用行为度量单位;
对于设计或其他文档一般是采用页为度量单位。
(2)      个人评审的时间周期,计量单位为小时;
(3)      评审会议的时间周期,计量单位为小时;
(4)      个人评审发现的缺陷个数,计量单位为个;
(5)      评审会议发现的缺陷个数,计量单位为个;
(6)      缺陷总数=在评审会上确定的缺陷个数;
排除了不是缺陷的发现,以及各位专家重复的发现。
(7)      个人评审的工作量,计量单位为人时;
(8)      评审会议的工作量,计量单位为人时;
(9)      评审的总工作量=个人评审的工作量+评审会议的工作量,计量单位为人时;
(10)      个人评审的速率=个人评审的规模/个人评审的工作量,计量单位为:规模的计量单位/人时;
(11)      评审的总体效率=评审发现的缺陷总数/评审的总工作量,计量单位为:个/人时
(12)      评审发现的缺陷密度,计量单位为:个/规模的计量单位

对于上述数据如何分析与使用呢?请看下面的案例:

场景一:某次需求审查,个人评审阶段发现的缺陷为10个,会议上发现的缺陷为20个。
分析:对于审查这种评审方式,发现问题应该主要是在会前发现,而不是在记录会议上,上述的数据表明个人评审时各位专家的投入不够,本次评审的质量不高,需要考虑是否重新评审或者采取其他补救措施。

场景二:某次设计审查30页文档,平均个人评审花费的时间为1小时。
分析:按照业内度量数据,进行设计审查时,平均的速率应该为不超过5页/小时,本次设计审查个人评审投入的时间不够。

场景三:某次代码走查,花费了1个小时,评审了1000行代码。
分析:代码走查的速率太快,无法保证评审效果。

场景四:审查20页的需求文档,有5个专家参与,其中2个专家A花费了1小时进行了个
人评审,其他3位专家没有进行个人评审。
分析:2位专家投入的个人评审时间偏少,3为专家没有准备,建议推迟评审的时间以便于各位专家事先进行准备,后者修改评审的方式为走查或技术复审。

场景五:某次代码审查,专家A的个人评审速率为:1000行/小时,其他专家的个人评审效率约为300行/小时。
分析:专家A的审查速率太快,无法保证评审效果,建议安排其为记录员。

场景六:某次需求审查,发现的缺陷密度为2个/页,组织级的审查退出准则为1.5个/页。
分析:不能通过评审,需要重新审查,并要进行原因分析,判断是需求文档本身的质量太差,还是本次审查的水平高、准备充分或是审查的技术手段有改进。

场景七:某次需求审查的效率为1.8个/人时,组织级建立的基线为 0个/人时---1.6个/人时
分析:本次审查的效率超出了组织级基线,过程判定为异常,需要进行特殊原因分析,判断是审查不够仔细还是文档太简单,或者是专家水平高等因素。

场景八:某次需求评审持续进行了1天的时间。
分析:会议周期太长,无法保证各位专家能够高效地的投入到评审工作中,建议拆分为多次评审。

展开阅读全文
©️2020 CSDN 皮肤主题: 深蓝海洋 设计师: CSDN官方博客 返回首页
实付0元
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值