发布网友 发布时间:2022-05-04 16:01
共2个回答
热心网友 时间:2022-06-23 22:19
(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天的时间。 分析:会议周期太长,无法保证各位专家能够高效地的投入到评审工作中,建议拆分为多次评审。热心网友 时间:2022-06-23 22:20
具有分类和排序功能、年薪;