度量与分析标准指南

文档修订记录

目录

1 目的 (3)

2 适用范围 (3)

3 指南 (3)

3.1 缩略语清单 (3)

3.2 度量项规格 (4)

3.2.1进度 (4)

3.2.1.1 数据收集 (4)

3.2.1.2 分析参考 (5)

3.2.2规模 (5)

3.2.2.1数据收集 (5)

3.2.2.2分析参考 (6)

3.2.3需求稳定度 (6)

3.2.3.1数据收集 (6)

3.2.3.2分析参考 (7)

3.2.4工作量 (7)

3.2.4.1 数据收集: (7)

3.2.4.2 分析参考: (8)

3.2.5质量（缺陷） (8)

3.2.5.1 缺陷属性 (9)

3.2.5.2 数据收集 (10)

3.2.5.3 分析参考 (10)

4 模板/工具 (11)

5 参考资料 (11)

1目的

结合度量与分析规程，具体阐述项目执行过程中度量与分析方面的执行细节，指导度量工作相关人员在项目中的工作。

2适用范围

适合青岛华恒胜泰电子科技有限公司所有项目中的度量与分析工作。

3指南

3.1缩略语清单

3.2度量项规格

3.2.1进度

3.2.1.1数据收集

a. 计划日期：包括阶段计划开始日期、阶段计划结束日期，阶段可以依次为：

Plan/ SRS/ HLD/ LLD/ Code/ UT/ IT/ ST，当然，根据所选生命周期模型的不

同，项目阶段也需要根据实际情况进行调整。

b. 计划日期数据取值于项目计划文档，计划阶段结束后，项目经理根据基线化

的项目计划文档立即填写项目度量表中进度页中此项数据。

c. 重新计划日期：包括阶段重新计划开始日期、阶段重新计划结束日期。

d. 重新计划日期数据取值于更新的项目计划文档。当调整进度，并基线化项目

计划文档后，立即更新此数据。

f. 实际日期：包括阶段实际开始日期、阶段实际结束日期。

g. 项目起始时间= SOW签发时间，也是项目计划阶段开始时间。

h. 项目关闭日期= 项目关闭会议日期

i. 阶段实际开始日期=阶段开工会议日期；在阶段最后交付物审计报告关闭

后，下一阶段就可以开始。

j. 阶段实际结束日期=本阶段最后工作产品基线审计报告关闭的日期；要求关闭日期必须在下阶段开工会议后三天内。

k. 持续时间偏差= ((实际结束日期-实际开始日期)-(计划结束日期-计划开始日期))/ (计划结束日期-计划开始日期)

l. 进度偏移偏差= (实际结束日期-计划结束日期)/ (计划结束日期-计划开始日期)

3.2.1.2分析参考

a. 总持续时间偏差是项目监控的内容，是进度调整的指标，当项目总进度偏差

超出控制线（在项目度量表中质量目标中定义），就要求项目经理分析原因，

给出具体解决方案，如调整进度或资源等。

b. 阶段持续时间偏差仅作为项目管理参考，是与重新计划数据作比较，便于项

目组及时了解进度偏差情况。实际操作时，阶段内应再进行任务划分，在每

个任务完成后计算出进度偏差，根据偏差及时采取措施。

3.2.2规模

3.2.2.1数据收集

a. 项目经理分别在计划活动前进行估计，及在需求分析活动完成、概要设计活

动, 详细设计完成后对代码量重新估计，并填写估计表单；如果项目不适合用

代码量来表示规模，也可以根据项目实际情况，采用其他的度量方式，如交

易数、画面数等规模的表示方式。

b. 项目经理从项目估计表中获取代码估计的数据,并填写度量表中规模页代码估

计单元。

c. 在每个阶段（包括SRS, HLD, LLD, Code, UT, IT, ST）活动完成，项目经理从

配置库中获取已基线化的文档的实际规模，填写度量表中规模页相应的实际

规模单元。

d. 在CODE , UT , IT , ST阶段后，项目经理需要统计实际代码规模,，并填入到相

应的单元中。

e. 规模偏差=当前阶段实际或者估计的规模-上阶段实际或者估计的规模

f. 当规模偏差超出规模阀值，项目经理要进行根源分析，并采取相应的规避措

施。

g. 当分配需求发生变更时候，项目需要重新估计项目规模, 项目需要将估计结

果更新到项目计划中，相应的结果也将修改到度量表中的重计划单元（如果

项目组的进度或者工作量受到影响的话）。

3.2.2.2分析参考

a. 分析规模偏差的根本原因，可能的因素有：需求发生变化；估计的经验不足；

历史数据缺乏等。并给出偏差对计划、进度、成本的影响。

b. 制订并实施规避措施，包括调整计划，协调人力资源，增加投入，进行估计

培训等。

3.2.3需求稳定度

3.2.3.1数据收集

a. 项目的SOW基线化完成后，RTM 应该立刻建立，项目经理根据基线化的

RTM收集初始的分配需求数，并填写度量表需求稳定度页相应单元。

具体说明：

需求的变更类型包括初始、增加、删除、修改。对于软件需求，初始类型只

发生在需求分析阶段，以后无此类型，对于需求分析（RA）阶段后的不同阶段

可以有增加、删除、修改类型。对于分配需求，初始类型只发生在计划阶段，

以后无此类型，对于计划阶段后的不同阶段可以有增加、删除、修改类型。

• 需求变更的原因是指引起需求变更的原因，原因值有：标准、客户、及由于

开发及测试阶段发现的缺陷引起的修改等

• 在项目开发阶段：如果一些已接受的需求不能实现的话，项目组可以提交CR。

在计算需求稳定性的时候，这类CR应该考虑在内。同样，这种情况也适合于由

客户提交的CR。

b. 当SRS基线化完成，项目经理从RTM中收集软件需求总数并填写度量表中需

求稳定性页相应单元。

c. 当需求发生变更时，项目组应该更新RTM 。当新的RTM基线化后，项目经

理应该立刻更新度量表中的修改、增加和删除的分配需求数或软件需求数。

d. 当需求发生变更，PM就应分析分配需求稳定指数的影响。

3.2.3.2分析参考

a. 需分析需求变更对开发项目的进度、规模和成本带来的影响。

b. 给项目经理和客户提供有关成本增加，进度延迟，质量降低的报告。

3.2.4工作量

3.2.

4.1数据收集:

a. 在工作量度量表中，项目组成员涉及到十三类活动：项目管理、配置管理、

质量管理、项目组公共活动、项目组外活动、需求分析活动、概要设计活动、