度量与分析指南.doc

度量与分析指南度量与分析指南V 1.0上海开发中心CMMI项目EPG小组2004年9月文档修订记录编号版本号修订内容简述修订日期作者审核 目 录1目的32适用范围33指南33.1缩略语清单33.2度量项规格43.2.1进度43.2.1.1数据收集43.2.1.2分析参考53.2.2规模53.2.2.1数据收集53.2.2.2分析参考63.2.3需求稳定度63.2.3.1数据收集63.2.3.2分析参考73.2.4工作量73.2.4.1数据收集:73.2.4.2分析参考:83.2.5质量（缺陷）83.2.5.1缺陷属性93.2.5.2数据收集103.2.5.3分析参考104模板/工具115参考资料11 1 目的结合度量与分析规程，具体阐述项目执行过程中度量与分析方面的执行细节，指导度量工作相关人员在项目中的工作。2 适用范围适合上海开发中心所有项目中的度量与分析工作。3 指南3.1 缩略语清单abbreviations缩略语Description 描述CMConfiguration Management配置管理CRChange Requirement变更需求HLDHigh Level Design概要设计ITIntegration Test集成测试ITPIntegration Test Plan集成测试计划LLDLow Level Design详细设计PMProject Manager 项目经理PPLProject Plan项目计划QAQuality Assurance Manager质量经理RTMRequirements Traceability Matrix需求跟踪矩阵SOWStatements Of Work工作任务书SRSSoftware Requirement Specification软件需求规格RARequirement Analyze 需求分析STSystem Test系统测试STPSystem Test Plan系统测试计划TRGTraining培训UTUnit Test单元测试UTPUnit Test Plan单元测试计划WBSWork Breakdown Structure工作任务分解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.缺陷发现阶段/活动描述在哪个活动缺陷被发现的。开发阶段或活动包括：软件需求分析评审、系统测试计划评审、软件概要设计评审、集成测试计划评审、软件详细设计评审、单元测试计划评审、编码评审、单元测试、软件集成测试、软件系统测试、维护(由维护项目经理负责提供数据)。凡后期阶段工作产品的准备过程中发现前期阶段工作产品的缺陷，其发现的活动记为其他活动发现的缺陷。缺陷记录在度量表中“其他活动”所发现的缺陷中。各个阶段发现缺陷的具体方式可能不同：在前期（单元测试之前）主要是各类评审活动；后期则主要是各类测试。 b.缺陷严重程度致命：引起系统死机或系统崩溃的问题。文档的评审和编码没有致命问题。严重：如果不改正将引起严重的功能障碍或无法得到预期结果的缺陷。 一般：导致某一个重要/关键特性功能异常，但不会影响到其它特性的缺陷。 提示： 从操作或维护的角度发现的问题或建议。备注： 对提示性问题不计入质量目标。文档中的编辑错误，如错别字、表述不清等；编程风格规范方面的问题其严重程度定为“提示”。 c.缺陷来源软件需求缺陷：指在定义或确定软件需求时所引入的错误。它包括在功能规格、界面、设计和测试需求、以及规格标准的缺陷。概要设计缺陷：指在软件概要设计中所引入的错误。它包括在功能描述、界面、控制逻辑、数据结构、标准中所发现的缺陷。详细设计缺陷:指在软件详细设计中所引入的错误。编码缺陷：指在程序实现或编码时所引入的错误。它包括在程序逻辑、界面处理、数据定义、计算和标准中所发现的缺陷。测试计划：指在测试用例或测试设计中所引入的错误。包括评审测试用例时发现的缺陷和测试时发现的测试用例错误。备注：对提示性问题不计入缺陷来源。在计算缺陷密度时不计算TP（测试计划）类错误。3.2.5.2 数据收集 a.PM定期（建议每周）从CR Log和评审表单中收集缺陷数据，根据缺陷发现活动、缺陷来源和严重程度填入度量表中