Eacr CMMI过程体系项目估算指南

Eacr CMMI 过程体系广东XXX技术股份有限公司文档控制记录文档编号HW GDL ESTM V2.0文档名称项目估算指南文档类别CMMI DEV文档密级公司机密发布日期存放位置文档修订记录1. 概述软件估算方法归根结底分为两类： 基于专家经验的估算方法 基于历史数据类比的估算方法其中基于历史数据类比的估算方法也结合专家经验。本指南主要内容是介绍四种软件估算方法，包括： 业务功能数估算法。属于基于历史数据类比的估算方法 功能点估算法。属于基于历史数据类比的估算方法。 PROBE 估算法。属于基于历史数据类比的估算方法。 WB-Delphi 估算法。属于基于专家经验的估算方法。 项目可根据实际情况选择使用这些估算方法的一种或者多种。【注意事项】CMMI3级要求使用历史数据帮助进行项目估算，因此项目使用单纯依赖专家经验的估算方法会被 认为不能满足3级的评估要求。2. 估算时机估算是项目计划的一部分，因此理论上讲，在整个项目启动、执行过程的任何时间都可以进行。 通常，执行估算的时机包括： 产品概念提出 此时，对项目的需求还没有比较准确的理解，估算的目的是为了大致理解项目成本和开发周期， 经常由专家根据经验直接估计一个大致的工作量和开发周期。估算不准确，与实际的偏差通常达100%，甚至高达 400%。 客户需求已经理解完成 此时，对客户需求已经有比较详细的理解，估算的目的是为项目建立工作量、开发周期基准。本指南中定义的业务功能数估算法、功能点估算法都适合于客户需求理解完成后的项目估算。估算比较准确，与实际的偏差通常可控制在50%以内。 产品需求已经开发完成 此时，待开发产品的架构已经基本建立，功能和性能需求都已经经过完整的分析，项目对需求的理解、各方面约束和限制的理解都已经非常细致。估算的目的是为下一步的开发活动建立更加准确的计 划。本指南中定义的业务功能数估算法、功能点估算法都适合于这种情况下的项目估算。估算很准确，与实际的偏差通常可控制在20-30%以内 概要设计已经开发完成 此时，项目已经对产品各个部件的设计、实现方法具备了完整的理解，估算的目的是为详细设计和实现建立更加准确的时间计划。本指南中定义的PROBE估算方法适合于这种情况下的项目估算。【执行提示】项目须在客户需求理解完成或者产品需求开发完成时根据当前对需求的理解执行尽可能详细的 估算，为项目计划奠定基础。项目可能也需要在立项前进行一次估算以便为编制项目任务书提供数据这时的估算可使用利用 专家经验的估算方法。如果此时已经对需求有了比较好的理解，也应该执行尽可能详尽的估算。3. 业务功能数估算法3.1 基本步骤工作量分布基准1、将软件功能分解为原子功能“原子功能”也叫做原子单元，是站在用户的角度具有独立使用意义的最小功能。功能可以逐级 细化，直到到达“原子”级别。例如，“账户管理”是一个对用户具有使用意义的功能，但是仍然可以把它细化为“增加账户”、“删 除账户”、“修改账户”三个功能，分解后的这三个功能对用户仍然具有独立的使用意义。因此，“账户 管理”不能认为是原子功能，而分解后的三个功能如果进一步细化就不具备独立的使用意义了，所以分 解后的这三个功能是原子功能项目建立功能列表，然后将每一个功能逐步细化就得到了原子功能列表。2、估计每一个原子功能的复杂度 项目团队根据经验为每一个原子功能估计一个复杂度，复杂度高、中、低三级。3、根据原子功能的复杂度确定其编程工作量 事先建立一个编程工作量基准，说明每种复杂度的一个原子功能完成编程工作所需要的工作量（参考“3.2 基准”，这个基准本质上是编程生产率），根据这个基准为每一个原子功能的编程工作量估计一 个数值。例如，假定编程生产率是“一个低复杂度的原子功能编程工作量在0.5-1.5个工作日”，估算人员就 可以为每个标识为“低”复杂度的原子功能的工作量赋予一个0.5-1.5之间的数值。4、统计总编程工作量 将所有原子功能的编程工作量相加，获得总编程工作量。5、根据工作量分布计算其它任务（阶段）的工作量 事先建立一个工作量分布比例基准，说明每种工作（阶段）占项目总工作量的比例（参考“3.2 基准，），其中包括编程。于是，可以通过总编程工作量计算其它工作（阶段）的预计工作量。6、编制阶段性时间表 根据阶段工作量、考虑每个阶段的人员投入，编制项目阶段性时间表。3.2 基准 编程生产率基准原子功能复杂度编程生产率基准 （人日/原子功能）备注低0.5-1.5中1.5-2.5高2.5-4注：在使用时以0.5人日为单位递增。 工作量阶段分布阶段（工作）工作量比例备注需求25%设计15%编程30%测试15%交付5%项目管理5%其它5%3.3 基准的建立估算方法中使用了两个基准：编程生产率、工作量阶段分布，这两个基准都是事先建立的。建立 基准可以由EPG执行、也可以由项目自己执行。两个基准都可以通过统计历史项目的数据获得。这里所说的历史数据，可以是真实的历史项目留 下来的数据、也可以是通过开发人员回忆的方式获得的数据。 编程生产率EPG可在组织级统计历史数据，建立编程生产率基准，步骤如下。1、划分项目或产品类型。不同类型的产品，生产率可能会有比较大的差别。2、选取几个项目，从中随机抽取30-60 个原子功能，并在开发人员的协助下，评价原子功能的复 杂度，按高、中、低三种复杂度分为三类。使每种复杂度的原子功能个数不少于10 个。3、获得这些原子功能的实际编程工作量（数据或者回忆）。4、计算每类原子功能的平均编程工作量。5、为每类原子功能的平均工作量设定一个取值范围（可根据经验判断），得到生产率基准。【执行提示】如果项目自行建立生产率基准，也可参照上述步骤进行。此时，如果能使用同一项目组、同类产品 的历史数据，会获得对本项目而言更具参考价值的生产率基准。工作量阶段分布一般的，工作量阶段分布基准是由EPG统计多个历史项目的数据获得。步骤如下。1、划分项目类型，考虑生命周期模型阶段划分。工作量分布与生命周期模型有关。2、选取多个即被相当可比性的历史项目，按照阶段统计它们的实际工作量，并计算每个阶段实际 工作量在总工作量中的比例（阶段工作量比例）。3、计算每个阶段的阶段工作量比例的平均值。4、根据经验适当调整各阶段工作量比例的平均值，获得工作量分布基准。5、可以为每个阶段的工作量比例设定一个取值范围（根据经验判断），项目使用时可在此范围内设 定其阶段工作量比例。【执行提示】如果项目自行建立工作量阶段分布基准也可参照上述步骤进行。匕时，如果能使用同一项目组所 执行的同类项目的历史数据，会获得对本项目而言更具参考价值的工作量阶段分布基准。3.4 示例功能ID功能原子单元复杂度编程工作量（人日）1计划查询1.1船舶动态计划低11.2船舶预报低11.3装卸车月计划低11.4月度分区装/卸车计划低11.5装车日计划中21.6吞吐量年计划低11.7吞吐量月计划中21.8库场运用计划低11.9火车进港计划低110商务计费查询5.1.1通用杳询高35.1.2高级杳询中25.1.3客运费用查询中25.2.1引航作业收入查询中25.2.2理货收入查询中25.2.3轮驳作业收入查询中25.2.4港铁行车费用查询高3总计1068118任务/阶段工作量比例工作量需求分析25100设计1560编程30118测试1560交付520项目管理520其他520合计1003983.5 需求理解不详细情况下的调整在需求理解尚未详细的情况下，功能将不能分解为原子单元，此时使用业务功能数估算法需要做一点调整：1、尽量分解功能、建立功能列表。2、为仍可以分解、但子功能不可知的功能，按照高、中、低三种复杂度分别估计一个原子功能个数。例如：功能“商务计费查询”的分解未知，但估计将包含“7 个中等复杂度的原子功能”3、根据原子功能的个数和生产率基准可计算编程工作量。其它步骤相同。3.6 模板参考“附件 1项目估算表-业务功能数”。4. 功能点估算法功能点估算法（FPA）实际上只估算了软件项目的“产品规模”它把产品规模表达为一个“分数”-功能点数(Function Point, FP)。 本指南指介绍功能点估算的基本步骤，详细的功能点分析流程，请参考附件2.4.1 基本概念FPA认为软件的规模包括两部分： 基本处理(Transaction)o对用户有意义的最小活动单元(实际上是原子单元)。基本处理可以 分为三类： EI(External Input)，外部输入。将数据沿系统边界由外而内传输。 EO(External Output)，外部输出。将数据沿系统边界由内而外传输，带有计算。 EQ(External Query)，外部查询。将数据沿系统边界由内而外传输，不带计算。 文件(File)。软件处理的数据集合。分为两类： ILF(Internal Logical File)，内部逻辑文件。系统维护的逻辑数据集合。 EIF (External Interface File)，外部接口文件。系统使用但不维护的文件。FPA规模估算方法，就是识别出所包含的这五种处理或文件，然后估计每一个处理或文件的功能点，就 得到了软件的规模4.2 总体步骤识别系统边界识别事务(EI,EO,EQ) 并评分识别文件(ILF,EIF) 并评分根据系统特性计算 调整因子VAF1、识别出软件包含的每一个EI、EO、EQ、ILF、EIF2、评价每一个 EI、 EO、 EQ、 ILF、 EIF 的复杂度3、根据复杂度查预定义的评分表获得其未经调整的功能点数(UFP)4、计算系统调整因子(VAF)5、计算功能点数 = UFP * VAF4.3 复杂度和复杂度评分基准识别出的每一个 EI、 EO、 EQ、 ILF、 EIF 都需要判断其复杂度，复杂度的判定有严格的准则，分 为两种情况： 基本处理（El、EO、EQ）基本处理类需要统计与之相关的逻辑文件个数（称为FTR）和数据元素个数（DET）确定其复杂度，复杂度分为低、平均、高三种，每种复杂度对应有预定义的功能点数。以EI为例，如下：Files 1 ypc Rrfcu nccd 0 1R)Dihi Ucincids1-45-15 iroller than 1 51ilun 21 I V：IW 1 1Av cragd (4)2Av chLue i：4iHigh ii wiicr limn 2Average (4 i1 lull 16)E ikih i fi)这个表的意思是：如果一个处理是EI，它关联的数据文件多于2个（FTR列）、关联的数据元素个数在5-15之间（Data Element 中间列），那么它的复杂度被判定为高，它的未经调整的功能点数是6。EO、EQ 也都有类似的对应的复杂度评分表，请参考“附件2. 功能点分析法-概述和流程”。 文件（ ILF、EIF）文件类需要统计其包含的记录个数（RET）和数据元素个数（DET）确定其复杂度，复杂度分为低、 平均、高三种，每种复杂度也对应有预定义的功能点数，请参考“附件2.功能点分析法-概述和流程”。4.4 系统调整因子依据前述步骤计算出来的功能点数，称为未经调整的功能点数（UFP），UFP需要经过调整才是最 终估算的功能点数。调整因子通过估计14个方面的系统特性计算，步骤是：1、为以下14个系统特性每一个估计一个影响程度（0-5之间）序号通用系统特性影响程度1数据通讯2分布式数据处理3性能4使用强度高的配置5交易速度6在线数据输入7最终用户的效率8在线更新9复杂的处理10可重用性11安装的简易性12运行的简易性13多场地14允许变更每一个系统特性影响程度的赋值规则，请参考“附件2. 功能点分析法-概述和流程”。2、计算调整因子（VAF）VAF 二 0.65 + 兰 C /100iI i=1 丿其中q是每一个系统特征的影响程度值。因此，VAL是介于0.65和1.35之间的一个数值。4.5 需求理解不详细情况下的调整在需求理解不充分的情况下，无法识别出每一个El、EO、EQ、ILF、EIF,更加无法识别FTR、 RET、DET。这种情况下，可使用以下调整的步骤：1、尽量分解功能、识别数据集合，建立功能和数据集合列表。2、估计每一个识别出的功能包含高、中、低复杂度的El、EO、EQ分别有多少个。复杂度根据经 验直接估计。3、估计每一个识别出的数据集合包含高、中、低复杂度的ILF、EIF分别有多少个。复杂度根据 经验直接估计。4、按照下表的准则、通过个数的乘积，获得UFPTransaction低中高El346EO457EQ346ILF71015EIF5710此后的 VAF 计算、 UFP 调整步骤与前述步骤相同。4.6 工作量估算功能点估算法得到的结果，是以功能点表示的规模，项目还需进一步估计工作量。工作量估算参 考以下步骤：1 、建立生产率基准EPG 或者项目通过历史数据统计建立项目生产率基准（这个生产率基准包含所有项目活动），例如：1.5FP/人天。这个基准可通过统计多个具备相当可比性的项目的实际工作量、交付产品功能点数，然后 计算均值并根据经验调整获得。2、根据生产率基准估计项目总工作量 估算出的功能点数除以生产率基准，即是项目的估算总工作量3、建立工作量阶段分布基准EPG或者项目通过历史数据统计建立项目阶段工作量分布基准。请参考本指南3.3 一节。4、将估算的总工作量分配到项目阶段 按照阶段工作量分布基准，估计阶段估算工作量。广东XXX技术股份有限公司 请参考“附件3.项目估算表-功能点”4.7 参考指南参考“附件2. 功能点分析法-概述和流程”可获得更详细的信息，包括 El、EO、EQ、ILF、EIF 的识别规则 复杂度判定规则 复杂度评分基准 不同应用场景的方法调整4.8 模板参考“附件3. 项目估算表-功能点”5. PROBE 估算法5.1 简介PROBE （PROxy-Base Estimation）方法的基本特点包括： 使用代码行作为规模单位 基于历史数据作为估算参考 需要至少概要级设计为基础因此，比较适合于在概要设计之后，开发小组或开发人员个人对工作包进行规模和工作量估算5.2 基本步骤1、建立 “LOC per Method”基准 选择历史上已完成程序的一些对象，研究这些对象的类型，把对象分成几类（下表第一列）。然后 研究这些对象中包含的方法的代码行规模，把方法分为从“很小”到“很大” 5 类（下表第一行），分 别计算五类方法的平均代码行数。举例如下表：Object TypesVery SmallSmallMediumLargeVery LargeCalculatio n2.345.1311.2524.6654.04Data2.604.798.8416.3130.09I/O9.0112.0616.1521.6228.93Logic7.5510.9815.9823.2533.83Set-up3.885.046.568.5311.09Text3.758.0017.0736.4177.66于是，“LOC per Method”基准就建立完成2、估计代码行数估计将要开发的软件或软件组件中可能包含的对象、对象的类型，获得对象列表。然后针对每一个 对象估计其中将包含的每一个方法、以及方法的规模类别（“很小”到“很大” 5 类）。不能准确估计出每一个方法的情况下，可按照5 类规模类别估计一个个数。广东XXX技术股份有限公司 于是，可根据“LOC per Method”基准估算总的代码行规模。3、调整规模估算并估算工作量选择历史上已经完成的一些对象（例如10个），统计它们“估计的LOC”、“实际的LOC”、“实际的工时”。举例如下表：ObjectEstimated LOCActual LOCActual Hours121023272801034313014554605245120124662002401071601586890102495062410110985根据这些数据统计，可获得： “实际的LOC”与“估计的LOC”之间的一元线性回归方程 “实际的工时”与“估计的LOC”之间的一元线性回归方程 上例中，这两个方程分别是： Actual LOC = -5.5 + 1.13 * Estimated LOC Actual Hours = 1.89 + 0.0299 * Estimated LOC于是，可以使用第一个方程调整估算的代码行规模、使用第二个方程估算工作量。6. WB-Delphi 估算法6.1 简介WB-Delphi 是依赖于专家经验的估算方法，其估算的对象可以是产品规模、也可以是工作量。其基本特点是： 使用多个专家分别、独立估算，以降低依赖专家经验带来的偏见。6.2 步骤1、成立估算小组估算小组一般由 4 人以上组成，其中一人担当协调员，其它人担当估算人。协调员不参加估算， 只负责汇总估算结果、协调估算活动。2、商定可接受的估算偏差范围 估算小组商定一个百分比（如正负20%），作为将来估算偏差可接受的范围。偏差范围可为总估算 工作量设置、也可以为单个任务的估算工作量设置。3、建立 WBS 分解建立WBS分解作为估算的依据。WBS分解可以由估算小组指定人员完成、也可以由估算小组集 体完成。4、估算小组成员独立依据WBS做出估算5、汇总结果，计算偏差协调人汇总每个估算人的估算结果，计算每一个任务估算值的平均值，并计算单个估算值与平均值 的偏差百分率，然后判断最大的偏差百分率是否在已商定的可接受偏差范围之内。如果最大偏差在可接受范围之内，则估算结束，平均值作为最终估算结果。否则，估算小组应讨论 WBS 是否有继续细化的可能、是否有任务属性理解不一致，建立新的 WBS 以及任务属性的理解。然 后估算人依据新的 WBS 分解及任务属性理解重新进行一轮估算。如此循环往复，直到估算的最大偏差落在可接受范围之内。【执行提示】WB-Delphi方法的核心是每一个估算人都不知道其它估算人的估算结并，且每一个估算人的估算 依据都是相同的。WB-Delphi方法在理论上存在“死循环的可能，因此估算小组应事先建立结束估算的条件，如: 估算已经进行了“轮或以上 WBS分解不能继续、各种属性、假定也被理解在以上两条被满足的情况下，没有估算人愿意再修改自己的估算结果6.3 示例ID任务产品特别属性 和假定估算人平均值取大偏差最终估算值1231T12.01.81.51.817%2T20.80.51.50.967%3T31.51.21.61.414%4T43.02.83.02.93%5T52.62.02.52.417%总计9.98.310.19.412%7. 附件附件 1. 项目估算表-业务功能数 Project_Estimation_BF_Template.xlsx附件 2. 功能点分析法-概述和流程 STSP_Guideline_FunctionPointAnalysis_V2.0.docx附件 3. 项目估算表-功能点 Project_Estimation_FP_Template.xlsx