【IT168 管理文档】    在进行同行评审时，一般可以积累如下的度量数据：

    （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天的时间。

    分析：会议周期太长，无法保证各位专家能够高效地的投入到评审工作中，建议拆分为多次评审。