SPM软件工作量估算.pptVIP

COCOMO模型基本原理 每个成本因素根据它的重要程度和影响大小赋予一定的值，可把这些成本因素划分为： 产品因素 计算机因素 人员因素 项目因素。 1.10 1.04 1.00 1.08 1.23 开发进度的要求（SCED) 0.83 0.91 1.00 1.10 1.24 软件工具的使用(TOOL) 0.82 0.91 1.00 1.10 1.24 程序设计实践(MODP) 0.95 1.00 1.07 1.14 程序设计语言的经验(LEXP) 0.90 1.00 1.10 1.21 开发环境的经验(VEXP) 0.70 0.86 1.00 1.17 1.42 程序员水平(PCAP) 0.82 0.91 1.00 1.13 1.29 应用经验(AEXP) 0.71 0.86 1.00 1.19 1.46 系统分析员的能力(ACAP) 1.15 1.07 1.00 0.87 开发环境的响应速度(TURN) 1.30 1.15 1.00 0.87 软件开发环境的变化(VIRT) 1.56 1.21 1.06 1.00 内存约束(STOR) 1.66 1.30 1.11 1.00 执行时间约束(TIME) 1.65 1.30 1.15 1.00 0.85 0.70 软件复杂性(CPLX) 1.16 1.08 1.00 0.94 数据库规模(DATA) 1.40 1.15 1.00 0.88 0.75 软件可靠性(RELY) 极高 很高 高 正常 低 很低 级别 成本因素 基本COCOMO模型 基本COCOMO模型是一个静态单变量模型，它把软件系统所需要的成本看作是程序大小单一变量的函数，用于系统级的粗略估算。 工作量 MM=C×KLOCa (人月|人年) 开发时间 D=cEd (月|年) 中间COCOMO模型 中间COCOMO模型是一个静态多变量模型，它把软件系统所需要的成本看作是程序大小和一系列成本驱动属性的函数。该模型将软件系统区分为系统和部件两个层次；系统是由部件组成。 详细COCOMO模型 详细COCOMO模型除了包括中级COCOMO模型中所考虑的因素以外，并对工作量调节因子在软件过程中每个步骤的影响作出详细评估。 该模型则将软件系统分为系统、子系统、模块三个层次。 对规模估算的修正 为了补充单一算法的不足，实际上，软件项目经理常采用其他方法，来进行“校正”和补充。这些方法是： （1）把大块的任务分解为小规模的任务。例如：使用WBS对任务分解，然后对分解到的最“末梢”功能，进行规模估算，然后，在进行相加。这种方法的好处是化复杂为简单。当我们无法把握大系统的规模时，我们可以比较有把握地估算小模块的规模。但是，问题是，各单独模块的规模之合，一般（从工作量上）并不等于系统的工作量之合。这就是我们说到的系统集成的工作量。 （2）采用与历史数据比较、修正的方法。 （3）采用最大值、最小值和最可能值折算的方法。 （4）对同一项目，至少使用二种以上工具和方法进行测算，避免一种方法的局限性。 ` （5）使用同行专家评审、评估小组集体投票取折中值的方法，博采众长。 （6）逐步逼近的方法；不把评估结果作为最终值，而是看成是一个逐步逼近的近似值，在以后的再评估中，可以进行调整。当项目刚刚启动，做第一次测算时，可以允许有30%以上的波动范围。在完成需求分析阶段，希望能达到波动控制在30%的范围内的目标。当基本完成详细设计的时候，估计的编码规模，应只能有20%、甚至更低的误差。 对规模估算的迭代修正 随着软件项目进程的逐步展开，需求被逐步地精细描述和定义，任务被依据需求进行分配，使用任务分解结构(WBS)的方法来建立需求（产品架构）与任务（软件开发过程）之间直接的、准确的联系，并实现详细化、文档化，工作产品被分解成各个工作元素。 产品架构必然要反映出项目的整体设计概念、层次结构，并从分解后的组件和模块功能分层中体现出来。 随着产品架构的精化，进一步定义出了开发各产品元素所需的过程任务。再把这些任务分配给不同的工程师。其目的是使任务分解架构中每一项任务，可以由个人或几个人的小组在较短的时间内完成。总之，任务分解架构越详细，则任务分配越明确，产品估算越准确，项目计划越完善，项目跟踪也越精确。 在这个基础上，经过一段时间的运行，一些典型的模块已经完成，所没有完成的只是相类似的模块等待接着继续开发。这时，对每一个产品元素的规模进行再估算和精细化调整的条件已经具备，根据一段时间的经验，重新调整软件项目规模估算，逐步求精，将获得更接近实际的估算结果。 序号 系数 因素 因素取值准则 得分 1 2 3 4 5 1 1 创造性 要求 没有-在不同设备上重编程序 很少-具有更严格的要求 有限-具有新