度量与分析指南.docx
《度量与分析指南.docx》由会员分享，可在线阅读，更多相关《度量与分析指南.docx（15页珍藏版）》请在冰豆网上搜索。
度量与分析指南
度量与分析指南
V1.0
上海开发中心CMMI项目EPG小组
2004年9月
文档修订记录
编号
版本号
修订内容简述
修订日期
作者
审核
1目的
结合度量与分析规程，具体阐述项目执行过程中度量与分析方面的执行细节，指导度量工作相关人员在项目中的工作。
2适用范围
适合上海开发中心所有项目中的度量与分析工作。
3指南
3.1缩略语清单
abbreviations缩略语
Description描述
CM
ConfigurationManagement配置管理
CR
ChangeRequirement变更需求
HLD
HighLevelDesign概要设计
IT
IntegrationTest集成测试
ITP
IntegrationTestPlan集成测试计划
LLD
LowLevelDesign详细设计
PM
ProjectManager项目经理
PPL
ProjectPlan项目计划
QA
QualityAssuranceManager质量经理
RTM
RequirementsTraceabilityMatrix需求跟踪矩阵
SOW
StatementsOfWork工作任务书
SRS
SoftwareRequirementSpecification软件需求规格
RA
RequirementAnalyze需求分析
ST
SystemTest系统测试
STP
SystemTestPlan系统测试计划
TRG
Training培训
UT
UnitTest单元测试
UTP
UnitTestPlan单元测试计划
WBS
WorkBreakdownStructure工作任务分解
3.2度量项规格
3.2.1进度
基本度量项
职责
频率/时间点
数据源
派生度量项
阶段计划开始日期
（Plan/RA/HLD/LLD/Code/UT/IT/ST）
项目经理
一次，计划批准后
项目计划
阶段持续时间偏差
阶段进度偏移
阶段计划结束日期
（Plan/RA/HLD/LLD/Code/UT/IT/ST）
项目经理
一次，计划批准后
项目计划
阶段重新计划开始日期
（Plan/RA/HLD/LLD/Code/UT/IT/ST）
项目经理
修改后的计划得到批准后
项目计划
阶段重新计划结束日期
（Plan/RA/HLD/LLD/Code/UT/IT/ST）
项目经理
修改后的计划得到批准后
阶段实际开始日期
（Plan/RA/HLD/LLD/Code/UT/IT/ST）
项目经理
一次，阶段实际开始时
阶段开工会启动日期
阶段实际结束日期
（Plan/RA/HLD/LLD/Code/UT/IT/ST）
项目经理
一次，阶段实际结束时
当前阶段最终基线审计关闭
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规模
基本度量项
职责
频率/时间点
数据源
派生度量项
估计代码规模（KLOC）
项目经理
需求分析、概要设计、详细设计阶段结束时
项目估计记录
规模偏差
实际代码规模（非空非注释行）
项目经理
需求分析后，每个阶段结束时
已基线化代码
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需求稳定度
基本度量项
职责
频率/时间点
数据源
派生度量项
初始分配需求数
项目经理
RA阶段结束
需求跟踪矩阵
分配需求稳定性指数
已修改的分配需求数
项目经理
RTM基线化后
需求跟踪矩阵
已增加的分配需求数
项目经理
RTM基线化后
需求跟踪矩阵
已删除的分配需求数
项目经理
RTM基线化后
需求跟踪矩阵
软件需求总数
项目经理
RTM基线化后
需求跟踪矩阵
软件需求稳定指数
已修改的软件需求数
项目经理
RTM基线化后
需求跟踪矩阵
已增加的软件需求数
项目经理
RTM基线化后
需求跟踪矩阵
已删除的软件需求数
项目经理
RTM基线化后
需求跟踪矩阵
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.在工作量度量表中，项目组成员涉及到十三类活动：
项目管理、配置管理、质量管理、项目组公共活动、项目组外活动、需求分析活动、概要设计活动、详细设计活动、编码活动、单元测试活动、集成测试活动、系统测试活动、项目结束活动，每类活动又包含多个子项目。
b.当项目计划WBS基线化或者Re-plan完成，PM需要及时填写项目度量表中工作量页中的计划的工作量数据或重计划的数据。
c.项目成员每天填写工作量度量表，PM要对项目组成员填写工作量度量表的情况进行检查和监督，保证数据完整性，准确性。
d.项目经理每周汇总各项度量活动实际工作量数据，每周更新度量表中工作量页相应单元。
e.PM定期（每周/每月）或者在每个阶段结束后，进行工作量数据的统计和分析，对统计结果进行记录，用于项目计划和监控。
f.QA在阶段点，要对项目组提供的阶段工作量度量数据的准确性进行核实。
3.2.4.2分析参考:
a.PM在周例会使用周工作量偏差，分析偏差的根本原因，了解周计划和进度，监督工作量度量表填写的准确性。
b.PM每个活动和每个阶段完成后，分析该活动工作量的分布和偏差原因，为更新WBS计划、人力资源的申请等提供有效的依据。
c.整个开发项目结束，分析工作量按照活动和活动类型的分布，以及整个项目工作量的偏差有助于新项目估计、制订合理的计划和建立组织能力基线。
3.2.5质量（缺陷）
基本度量项
职责
频率/时间点
数据源
派生度量项
需求规格评审缺陷发现数目
项目经理
SRS评审后
评审报告
需求规格评审缺陷发现密度
SRS文档规模
项目经理
SRS评审后
已基线化的SRS文档
系统测试计划评审缺陷发现数目
项目经理
STP评审后
评审报告
系统测试计划评审缺陷发现密度_
系统测试用例数
项目经理
STP评审后
已基线化的STP文档
测试报告
概要设计评审缺陷发现数目
项目经理
HLD评审后
评审报告
概要设计评审缺陷发现密度
HLD文档规模
项目经理
HLD评审后
已基线化的HLD文档
集成测试计划评审缺陷发现数目
项目经理
ITP评审后
评审报告
集成测试计划评审缺陷发现密度
集成测试用例数
项目经理
IT结束后
已基线化的ITP文档
测试报告
详细设计评审缺陷发现数目
项目经理
LLD评审后
评审报告
详细设计评审缺陷发现密度
LLD文档规模
项目经理
LLD评审后
已基线化的LLD文档
单元测试计划评审缺陷发现数目
项目经理
UTP评审后
评审报告
单元测试计划评审缺陷发现密度
单元测试用例数
项目经理
UT结束后
已基线化的UTP文档
测试报告
代码评审缺陷发现数目
项目经理
代码走查后
评审报告
代码评审缺陷发现密度
代码规模
项目经理
编码完成
已基线化的代码
单元测试缺陷发现数目
项目经理
UT完成后
缺陷跟踪电子流
测试报告
缺陷报告
单元测试缺陷发现密度
集成测试缺陷发现数目
项目经理
IT完成后
缺陷跟踪电子流
测试报告
缺陷报告
集成测试缺陷发现密度
系统测试缺陷发现数目
项目经理
ST完成后
缺陷跟踪电子流
测试报告
缺陷报告
系统测试缺陷发现密度
其它活动缺陷发现数目
项目经理
定期（建议每周）
CR变更需求
其它活动缺陷发现密度
3.2.5.1缺陷属性
a.缺陷发现阶段/活动
1描述在哪个活动缺陷被发现的。
开发阶段或活动包括：
软件需求分析评审、系统测试计划评审、软件概要设计评审、集成测试计划评审、软件详细设计评审、单元测试计划评审、编码评审、单元测试、软件集成测试、软件系统测试、维护（由维护项目经理负责提供数据）。
凡后期阶段工作产品的准备过程中发现前期阶段工作产品的缺陷，其发现的活动记为其他活动发现的缺陷。
缺陷记录在度量表中“其他活动”所发现的缺陷中。
1各个阶段发现缺陷的具体方式可能不同：
在前期（单元测试之前）主要是各类评审活动；后期则主要是各类测试。
b.缺陷严重程度
致命：
引起系统死机或系统崩溃的问题。
文档的评审和编码没有致命问题。
1严重：
如果不改正将引起严重的功能障碍或无法得到预期结果的缺陷。
1一般：
导致某一个重要/关键特性功能异常，但不会影响到其它特性的缺陷。
提示：
从操作或维护的角度发现的问题或建议。
备注：
对提示性问题不计入质量目标。
文档中的编辑错误，如错别字、表述不清等；编程风格规范方面的问题其严重程度定为“提示”。
c.缺陷来源
软件需求缺陷：
指在定义或确定软件需求时所引入的错误。
它包括在功能规格、界面、设计和测试需求、以及规格标准的缺陷。
概要设计缺陷：
指在软件概要设计中所引入的错误。
它包括在功能描述、界面、控制逻辑、数据结构、标准中所发现的缺陷。
详细设计缺陷:
指在软件详细设计中所引入的错误。
编码缺陷：
指在程序实现或编码时所引入的错误。
它包括在程序逻辑、界面处理、数据定义、计算和标准中所发现的缺陷。
测试计划：
指在测试用例或测试设计中所引入的错误。
包括评审测试用例时发现的缺陷和测试时发现的测试用例错误。
备注：
对提示性问题不计入缺陷来源。
在计算缺陷密度时不计算TP（测试计划）类错误。
3.2.5.2数据收集
a.PM定期（建议每周）从CRLog和评审表单中收集缺陷数据，根据缺陷发现活动、缺陷来源和严重程度填入度量表中缺陷页相应单元；
b.PM在每轮测试结束后，从缺陷跟踪电子流中收集缺陷数据，根据缺陷发现活动、缺陷来源、严重程度填入度量表中缺陷页相应单元；
c.PM在交付物基线化后，从配置库中收集规模数据，填入度量表中规模页的相应单元。
对基线化的CI进行更改后，在基线化后重新收集规模数据。
3.2.5.3分析参考
a.活动缺陷发现密度可以指出软件质量是否足以进入下一阶段；可以判断评审或测试活动是否有效地发现缺陷。
确保活动缺陷发现密度在质量目标控制范围内就是为了及早发现和修正缺陷，减少返工的工作，达到交付高质量产品的目的。
b.在每个活动过程中，缺陷发现密度与质量目标的偏差都说明一些变化，可能是过程的改进，更可能的还是过程质量低劣。
在缺陷发现密度超出控制限时，应从过程、工程、人员和培训等方面进行偏差原因分析，必要时需要制定纠正和预防活动计划。
一般来说，低的缺陷发现密度可以表示高质量的软件，也可以表示低劣的评审或测试过程。
c.任何时候，都可以对生命周期的所有活动进行分析，如果前期缺陷发现密度低于质量目标，而后期的缺陷发现密度高于质量目标，这说明项目组需要分析前期用于发现缺陷的过程；如果相反，更证实了早期发现缺陷的重要意义，说明早期成熟的软件过程和有效的质量控制活动，当然也可能是因为项目组成员健全的技能和经验水平。
如果前期的活动缺陷发现密度都高于质量目标，这通常预示着后面将有更多的缺陷，要及时重新调整缺陷数据的估计和加强评审或测试活动的投入。
4模板/工具
项目度量表
工作量度量表
5参考资料
无。
升级会员 