软件项目成本管理课件(同名312)

成本管理的重要性美国斯坦迪什公司1995年的研究表明，项目失败的真正原因，包括成本失控，是没有很好的项目管理。成本管理的重要性美国斯坦迪什公司1995年的研究表明，项目失1软件项目的成本可控吗？软件项目的成本控制实在太难，按项目预算几乎是不可能的。（1）

需求不确定项目工期不确定、费用无法控制；（2）项目采用的技术先进，技术风险很大，因此，费用无法控制；（3）

软件开发是一个人行为，因此，人员的积极性、工作效率、配合情况等，不像其他行业的项目那样，可以准确地预测。因此，工作效率无法确定；（4）

项目具有独特性，没有历史资料可以借鉴。因此，成本估算带有很大的盲目性。为了使公司和项目组的项目管理水平获得提升，项目经理首先要提高自己的认识能力和实际管理水平。软件项目的成本可控吗？软件项目的成本控制实在太难，按项目预算2本章主要内容：3.1概述3.2软件规模估算3.3软件项目成本估算3.4软件项目成本监控本章主要内容：3.1概述3这种模型是依据在一些大型项目（总工作量达到或超过30个人年）中收集到的工作量分布情况而推导出来的，但也可以应用在一些较小的软件项目中。实际工作中，也常常使用KLOC（千代码行）来表示程序长度。各程序设计语言中实现一个功能点所需的代码行数的粗略估算(LOC/FP)5、运用多种独立的技术和原始资料L是用作输入的预测量，式中E为开发所需的人力（人/月）。系统设计阶段给出产品的完整软件体系结构和各个子系统及模块的说明。实际成本额（ACWP:ActualCostofWorkPerformed)10

），将15个评分值相乘即可获得EAF.要与WBS等相对应，以保证预算的全面性和有效性一个目标都很困难，更不用说要同时完成两个最好由多个专家进行估算。不仅仅是简单的数字，而是资源、成本估算和预算分解说明的有机结合。没有系统的开发方法，缺乏文档和复审根据成本估算值而做的承诺程度。3.1概述这种模型是依据在一些大型项目（总工作量达到或超过30个人年）4成本的解释)成本的解释)5软件项目成本包含：人力资源成本:工资、福利、招聘和培训等成本费用。软硬件资源成本：开发和测试工具、服务器、网络设备等软硬件资源费用。商务活动成本：差旅费、交通费、接待费、通信费等。其他成本费用：未计入上述分类的成本费用。软件项目成本包含：6为了评价项目成本的可确定程度为了评价项目成本的可确定程度7根据是否可以直接用一种经济的方式识别和跟踪项目成本，软件项目成本可分为以上类型。根据是否可以直接用一种经济的方式识别和跟踪项目成本，软件项目8软件项目成本管理活动包括：软件系统规模估算软件项目成本估算软件项目成本预算制订软件项目成本监控成本管理目标是确保在批准的预算范围内完成项目所需的各项任务。软件项目成本管理活动包括：成本管理目标是确保在批准的预算范围9估算的时机软件项目估算不是一劳永逸的活动，而是随项目的进行而进行的一个逐步求精的过程。估算的时机软件项目估算不是一劳永逸的活动，而是随项目的进行而10估算的时机对任何一种估算方法来说，估算的时机和精度都是一种矛盾。图3.1软件项目估算的时机估算的时机对任何一种估算方法来说，估算的时机和精度都是一种矛11估算的时机选择合适的时间点进行估算是估算中必须考虑的一个问题。因为估算本身也需要成本。图3.2软件项目估算时机软件产品生命周期及需要进行估算的五个时间点：E1,E2,E3,E4,E5估算的时机选择合适的时间点进行估算是估算中必须考虑的一个问题12估算的时机可行性论证：E1客户需求阶段列出客户需要的基本软件功能。时间点E1的估算可以为软件组织提供初步信息，否则需要重新考虑项目的可行性。估算的时机可行性论证：E113估算的时机需求分析：E2产品定义阶段完成对项目的规格说明，进一步细化系统功能。此时估算有助于软件组织在进入产品开发前再次权衡产品的可行性估算的时机需求分析：E214估算的时机系统设计：E3系统设计阶段给出产品的完整软件体系结构和各个子系统及模块的说明。估算的时机系统设计：E315估算的时机系统实现：E4设计通过审查之后，系统的实现工作就开始了。该阶段结束时，前面各项活动中消耗的资源（时间及人力等）和软件工作量均可获得，从而可对原有的估算进行调整，后期需要的工作则按此估算进行计划。估算的时机系统实现：E416估算的时机系统运行维护：E5当所有的工作都已完成并得到了验证后，系统就可以投入运行了。估算工作实际上是对估算过程的评价，即用实际的消耗与各个阶段估算值进行比较，为下一项目积累宝贵的经验。估算的时机系统运行维护：E5173.2软件项目规模估算3.2软件项目规模估算18因此，工作效率无法确定；对于不合适的计划进行修改变更后及时通知项目干系人等。项目初期制订的开发目标是不可实现的中级COCOMO模型在基本COCOMO模型的基础上，再用涉及产品、硬件、人员、项目等方面的影响因素调整工作量的估算。假定：如果资源具备的话，在什么条件下承诺交付该估算值？完成软件需求说明书从不可检验到可检验的转化，需要许多工作量。因为估算本身也需要成本。UFC：UnadjustedFunctionPointCount其缺点是难以识别较低级别上的技术性困难。根据成本估算值而做的承诺程度。a、b、c和d是指不同软件开发方式的经验值。一种预测未来事件的技术。如“快速”是不可检验，“响应时间不超过xx秒”是可检验的。专家召开小组会议讨论上次估计结果，自愿修改个人估计。（1）估计新的软件开发项目；3.2软件项目规模估算工作分解结构WBS 典型的WBS（WorkBreakdownStructure）因此，工作效率无法确定；3.2软件项目规模估算工作分解结构19工作分解结构WBS常用的软件规模度量标准：代码行LOC功能点FP工作分解结构WBS常用的软件规模度量标准：20工作分解结构WBS软件规模的估计步骤：1.在技术允许的条件下，应从最详细的WBS开始；2.精确定义度量的标准；3.估计底层每一模块的规模，汇总以得到 总体估计；4.适当考虑偶然因素的影响。

WBS越细，对软件规模的估计就越准确。工作分解结构WBS软件规模的估计步骤：21代码行： 代码行LOC是常用的源代码程序长度的度量标准。 代码行可分为：无注释的代码行（NCLOC）和注释的源代码行（CLOC） 实际工作中，也常常使用KLOC（千代码行）来表示程序长度。 一代码行（1LOC）价值和人月均代码行数可以体现一个软件生产组织的生产能力。代码行：22由IBM工程师A.J.Albrecht于79年首次提出;是基于系统功能的一种规模估计方法，FP法将信息系统抽象成输入数据、输出数据、查询数据、系统内部文件及系统外部文件由IBM工程师A.J.Albrecht于79年首次提出;23计算未调整的功能点数UFC的步骤UFC：UnadjustedFunctionPointCount（1）计算所需要的输入、输出、查询、外部文件、内部文件的数量。计算未调整的功能点数UFC的步骤UFC：Unadjusted24计算功能点数的步骤：功能项权

重简单一般复杂输入346输出457查询346外部文件71015内部文件5710（2）判断项目复杂性，计算UFC由估计人员对项目的复杂性作出判断，分成简单、一般、复杂三种情况。然后根据下表求出功能项的加权和。计算功能点数的步骤：功能项权重简单一般复杂输入34625功能点FP是由未调整的功能点数UFC与技术复杂度因子（TCF）相成得到。功能点FP是由未调整的功能点数UFC与技术复杂度因子（TCF计算功能点数的步骤：从上表计算出：

TCF=0.65+0.01*(SUM(Aj))TCF的取值范围为0.65～1.35，分别对应着组成部分Aj都取值0和5，得到功能点FP的计算公式：

FP=UFC*TCF计算功能点数的步骤：从上表计算出：27FP有助于在软件项目的早期作出规模估计，但无法自动度量。常用做法：早期估计时用FP，再依据经验将FP转化为LOC,再使用LOC继续进行估计。FP有助于在软件项目的早期作出规模估计，但无法自动度量。28功能点度量在以下情况下特别有用：（1）估计新的软件开发项目；（2）应用软件包括很多输入输出或文件活动；（3）拥有经验丰富的功能点估计专家；（4）拥有充分的数据资料，可以相当准确地将功能点转化为LOC。功能点度量在以下情况下特别有用：29各程序设计语言中实现一个功能点所需的代码行数的粗略估算(LOC/FP)程序设计语言平均值中值低值高值C16210933704C++665329178Java635377------SQL40377110VisualBasic474216158各程序设计语言中实现一个功能点所需的代码行数的粗略估算(LO30计划评审技术(ProgramEvaluationandReviewTechnique，PERT)是20世纪50年代末开发的用于项目进度规划的一种技术。后将其引入到软件规模估计的应用中。公式见书P85计划评审技术(ProgramEvaluationand313.3软件项目成本估算3.3软件项目成本估算32软件生产率估算生产率数据的获取选择一些最近完成的项目，要和等完成项目相似。获得各个项目的LOC数据，各项目都使用相同的计数方案对于更改过的程序，记录更改代码所占比例计算投入到每个项目的人员数量计算各个项目的软件生产率即LOC/PM,进而求出平均值。软件生产率估算生产率数据的获取33软件生产率估算影响因素需要大量的历史数据为基础，可以借公开的数据作参考，对比自己的数据，以确定自身生产率。软件生产率估算影响因素34软件生产率估算估算可以根据历史数据比如表中数据进行生产率数据的估算软件生产率估算估算35成本估算是软件项目计划中的一种重要组成部分；成本估算目标是要完成软件项目所需费用的估计和计划。成本估算是在无法以高可靠性预计的环境下进行的。根据历史数据进行估算----理想状况成本估算是软件项目计划中的一种重要组成部分；36软件项目成本管理课件(同名312)37一.专家判定由专家根据经验和对项目的理解对项目进行成本估算。最好由多个专家进行估算。对于由多个专家得到的多个估算值合成一个最终的估算值。可采用的方法有：求中值或平均值召开小组会议Delphi技术WidebandDelphi技术一.专家判定由专家根据经验和对项目的理解对项目进行成本估算。38一.专家判定求中值或平均值方法简单，但易于受到极端估算值的影响而造成偏差。一.专家判定求中值或平均值39一.专家判定召开小组会议组织专家们召开小组会议进行讨论，统一某一估算值；好处：去掉一些极端偏颇无知的估算不利：易受权威人士或能言善辩人士影响一.专家判定召开小组会议40一.专家判定Delphi技术一种预测未来事件的技术。作为一种使专家意见一致的方法。一.专家判定Delphi技术41一.专家判定Delphi技术步骤：协调员给每位专家一份软件规格说明书和一张记录估算值的表格;专家无记名填写表格，相互间不能讨论；协调员对专家填在表上的估算进行小结，给出估算迭代表，要求专家进行下一轮估算。专家重新无记名填表。一.专家判定Delphi技术42一.专家判定Delphi技术图3.4Delphi成本估算迭代表的样例一.专家判定Delphi技术图3.4Delphi成本估算43一.专家判定WidebandDelphi技术将小组讨论与Delphi技术结合起来：给每位专家发一份软件规格说明书和一张记录估算值的表格;专家开会讨论软件产品和任何与估算相关的问题专家无记名填写表格；协调员对专家填在表上的估算进行小结，给出估算迭代表，要求专家进行下一轮估算。专家召开小组会议讨论上次估计结果，自愿修改个人估计。一.专家判定WidebandDelphi技术44一.专家判定WidebandDelphi技术将小组讨论与Delphi技术结合起来：一.专家判定WidebandDelphi技术45二.类比把当前项目和以前做过的类似项目比较，获得其工作量的估算值。要保留以往完成项目的历史记录。基本步骤是：整理出项目功能列表和实现每个功能的代码行；标识出每个功能列表与历史项目的相同点和不同点，特别要注意历史项目做得不够的地方；通过步骤1和2得出各个功能的估计值；产生规模估计。二.类比把当前项目和以前做过的类似项目比较，获得其工作量的估46三.自顶向下推算出项目的总体成本或工作量，然后按比例分配到各个组成部分中去。优点：对系统级的重视，一般不会遗漏系统级事务的成本。如系统集成、用户手册、配置管理等。其缺点是难以识别较低级别上的技术性困难。这些困难会使成本上升，有时会遗漏开发软件中的某些部分。三.自顶向下推算出项目的总体成本或工作量，然后按比例分配到各47软件需求说明书的价值由它可检验的程度决定的，可检验性越好，则价值越高。KLOC为估计提交的千代码行。中级COCOMO模型在基本COCOMO模型的基础上，再用涉及产品、硬件、人员、项目等方面的影响因素调整工作量的估算。将每期预算成本累加得出累计计划预算成本（CBC:CumulativeBudgetedCost或BCWS：BudgetedCostofWorkScheduled)（4）

项目具有独特性，没有历史资料可以借鉴。当预测量是FP时，估算模型有：估算应征求所有项目干系人的意见，并采用可靠的模型算法。a、b、c和d是指不同软件开发方式的经验值。各程序设计语言中实现一个功能点所需的代码行数的粗略估算(LOC/FP)DOC＝49×L1.创新点过多，不利于快速开发。按照模型中的变量依存关系某一时点已经完成的工作所实际花费成本的总金额。计算赢得值(CEW或BCWP)如“快速”是不可检验，“响应时间不超过xx秒”是可检验的。三.自顶向下任务分解技术首先把软件开发工程分解为若干个相对独立的任务。再分别估计每个单独的开发任务的成本，最后累加起来得出软件开发工程的总成本。估计每个任务的成本时，通常先估计完成该项任务需要用的人力(以人月为单位)，再乘以每人每月的平均工资而得出每个任务的成本。482022/12/12软件需求说明书的价值由它可检验的程度决定的，可检验性越好，则48四.自底向上自底向上估算是把待开发的软件逐步细化，直到能明确工作量，由负责该部分的人给出工作量的估算值，然后把所有部分相加，就得到了软件开发的总工作量。每个部分的估算较精确。易于忽略许多与软件开发有关的系统级成本。总估算值偏低。花费的精力更多。四.自底向上自底向上估算是把待开发的软件逐步细化，直到能明确49四.自底向上任务单元法，最常见的一种方法。四.自底向上任务单元法，最常见的一种方法。50五算法模型经验模型容易受主观因素的影响。采用数学方法建立正式的模型是必需的。五算法模型经验模型容易受主观因素的影响。51五算法模型按照模型中的变量依存关系静态模型动态模型按照变量的多少，单变量模型多变量模型五算法模型按照模型中的变量依存关系52静态单变量模型用同一个基本公式通过同一个预测量来估算所需要的值。常见公式：其中C是待估算的量，L是用作输入的预测量，a,b是经验参数静态单变量模型用同一个基本公式通过同一个预测量来估算所需要的53静态单变量模型马里兰大学软件工程实验室所建立的SEI模型公式：L是用作预测量的LOC，E是以人有为单位的工作量，DOC是以页数为单位的文本量，D是以月为单位的所需时间。静态单变量模型马里兰大学软件工程实验室所建立的SEI模型公式54静态多变量模型基于静态单变量模型，但还取决于几个能代表软件开发环境的各种因素的变量，如软件开发方法、用户需求变化情况等。如COCOMO模型，静态多变量模型基于静态单变量模型，但还取决于几个能代表软件开55动态多变量模型Putnam模型就是一个动态多变量模型，见后面部分。动态多变量模型Putnam模型就是一个动态多变量模型，见后面56其他模型对以前的软件项目中收集到的数据进行回归分析而建立的模型，其结构如下：其中，A、B、C是由经验估计的常数，E是以人月为单位的工作量，X是预测变量，通常是LOC和FP两种方式。其他模型对以前的软件项目中收集到的数据进行回归分析而建立的模57其他模型当预测量是LOC时，估算模型有：当预测量是FP时，估算模型有：其他模型当预测量是LOC时，估算模型有：58软件项目成本管理课件(同名312)59IBM估算模型1977年，IBM的Walston和Felix提出了如下的估算公式：E＝5.2×L0.91，L是源代码行数(以KLOC计)，E是工作量（以PM计）D＝4.1×L0.36，D是项目持续时间(以月计)

S＝0.54×E0.6，S是人员需要量(以人计)

DOC＝49×L1.01。DOC是文档数量(以页计)

在此模型中，一般指一条机器指令为一行源代码。一个软件的源代码行数不包括程序注释、作业命令、调试程序在内。对于非机器指令编写的源程序，如汇编语言或高级语言程序，应转换成机器指令源代码行数来考虑。

IBM估算模型1977年，IBM的Walston和Felix60COCOMO估算模型

基本COCOMO模型估算公式：

工作量:E=a*(KLOC)b

进度:D=c*(E)d

式中E为开发所需的人力（人/月）。D为所需的开发时间（月）。KLOC为估计提交的千代码行。

a、b、c和d是指不同软件开发方式的经验值。

由TRW公司开发，Boehm提出的结构化成本估算模型（ConstructiveCostMode）是最精确、最易于使用的成本估算方法之一。COCOMO估算模型

基本COCOMO模型估算公式：

61软件项目成本管理课件(同名312)62软件项目成本管理课件(同名312)63中级COCOMO模型

中级COCOMO模型估算公式：

式中E为开发所需的人力（人/月）。S为以KLOC计数的程序规模，EAF是工作量调整因子，a、b、c、d是指不同软件开发方式的经验值。其中aSb是名义工作量。

EAF根据引入的15个成本驱动量计算，（见表3.10

），将15个评分值相乘即可获得EAF.进度:D=c*(E)d中级COCOMO模型中级COCOMO模型估算公式：

64中级COCOMO模型EAF根据引入的15个成本驱动量计算，（见表3.10

），将15个评分值相乘即可获得EAF.中级COCOMO模型EAF根据引入的15个成本驱动量计算，（65详细COCOMO模型详细COCOMO模型中名义工作量aSb估算公式与开发时间的计算公式和中级COCOMO模型相同，式中E为开发所需的人力（人/月）。S为以KLOC计数的程序规模，a、b、c、d是指不同软件开发方式的经验值。

其不同之处在于成本驱动因素的获取方式，（见表3.11-3.13）

这些成本驱动因素与下列方面有关：与产品层次有关（模块—子系统---系统）与软件开发阶段有关：需求计划和产品设计(RPD)详细设计(DD)编码和单元测试(CUI)集成测试(IT)进度:D=c*(E)d详细COCOMO模型详细COCOMO模型中名义工作量aSb估66详细COCOMO模型详细COCOMO模型67详细COCOMO模型详细COCOMO模型68详细COCOMO模型详细COCOMO模型69COCOMO模型总结COCOMO模型是按其详细程度分为三级：基本COCOMO模型中级COCOMO模型详细COCOMO模型基本COCOMO模型是是一个静态单变量模型，它用一个以已估算出来的原代码行数(LOC)为自变量的经验函数计算软件开发工作量。中级COCOMO模型在基本COCOMO模型的基础上，再用涉及产品、硬件、人员、项目等方面的影响因素调整工作量的估算。详细COCOMO模型包括中级COCOMO模型的所有特性，但更进一步考虑了软件工程中每一步骤（如分析、设计）的影响。70COCOMO模型总结COCOMO模型是按其详细程度分为三级：70

Putnam估算模型

1978年Putnam提出的模型，是一种动态多变量模型。L=Ck*K1/3*td4/3

其中：

L--------源代码行数(以LOC计)K--------整个开发过程所花费的工作量（以人年计）td--------开发持续时间（以年计）Ck-------技术状态常数，它反映“妨碍开发进展的限制”，取值因开发环境而异.Ck的典型值

开发环境

开发环境举例

2000

差

没有系统的开发方法，缺乏文档和复审

8000

好

有合适的系统的开发方法，有充分的文档和复审

11000

优

有自动的开发工具和技术

它是假定在软件开发的整个生存期中工作量有特定的分布。这种模型是依据在一些大型项目（总工作量达到或超过30个人年）中收集到的工作量分布情况而推导出来的，但也可以应用在一些较小的软件项目中。Putnam模型可以导出一个“软件方程”，把已交付的源代码（源语句）行数与工作量和开发时间联系起来。

Putnam估算模型

1978年Putnam提出711，建立成本估算目标

在软件成本估算中，有时耗费大量精力收集的用于估算的信息项,在进行估算时却因为与估算需要关系不在而不被使用,因而大量的艰难工作和细致分析付之东流。

因此，要先建立成本估算目标，以此来制定以后工作的详细程度。1，建立成本估算目标72建立成本估算目标规划需要的数据和资源确定软件需求拟定可行的细节运用多种独立的技术和原始资料比较并迭代各个估算值随访跟踪

建立成本估算目标731，建立成本估算目标

帮助因素：软件项目当前所处的生命周期阶段，它大致对应于对软件项目的认可程度；根据成本估算值而做的承诺程度。1，建立成本估算目标741，建立成本估算目标

软件项目在生命周期阶段的估算范围1，建立成本估算目标软件项目在生命周期阶段的估算范围751，建立成本估算目标为了决策需要，有时还要作出乐观和悲观估算，然后在随后的工作中逐步调整。1，建立成本估算目标762、规划需要的数据和资源为了避免出现因准备不充分而导致作出不可变更的软件承诺，我们可以将软件成本估算看成一个小型项目，制定一份项目规划，可包括如下内容：目的：为什么要求出该估算值？产品和进度：何时提供何种产品？责任：每种产品由何人负责？过程：如何进行该工作，采用哪些成本估算工具和技术？需要的资源：完成该工作需要多少数据、时间、费用及工作量等？假定：如果资源具备的话，在什么条件下承诺交付该估算值？2、规划需要的数据和资源773、确定软件需求软件需求对估算很重要。软件需求说明书的价值由它可检验的程度决定的，可检验性越好，则价值越高。如“快速”是不可检验，“响应时间不超过xx秒”是可检验的。完成软件需求说明书从不可检验到可检验的转化，需要许多工作量。3、确定软件需求784、拟定可行的细节考察越细，对软件开发技术理解得就越透彻。在估算时把软件分得越细，软件模块的个数越多，总的误差就减少。对软件必须执行的功能考虑得越多，遗漏某些次要成本的可能性就越小。4、拟定可行的细节795、运用多种独立的技术和原始资料软件成本估算方法有多种，专家判定、类比、自顶向下、自底向上、算法模型等，这些方法各有优缺点，没有一种方法能在所有方面胜过其它技术。因此综合运用这些方法很重要。5、运用多种独立的技术和原始资料806、比较并迭代各个估算值综合运用各种估算方法的目的在于将各估算值进行比较，分析得到不同估算值的原因，从而找出可以改进估算的地方，提高估算的准确度。估算值迭代的原因：乐观和悲观现象：选择合理的软件估算人员帐篷中的高杆现象：高杆部分占据大部分成本对突出部分进行更加详细的考虑和迭代。规模大---复杂度复杂度---最难实现部分的复杂度6、比较并迭代各个估算值817、随访跟踪原因是：软件成本估算的输入和相应技术是不完善的。比较后，可以改进成本驱动因子，提高估算精度，改进估算技术。确认有些项目确实不符合估算模型，有利于类似项目成本估算的有效性和模型改进。项目变动时，可通过此过程识别变动并及时调整成本估算值。当估算技术不能反映当前项目的实际情况时，需要将新项目中出现的新技术或方法等结合到改进的估算值和估算技术中。7、随访跟踪82制订软件项目预算要将项目成本估算分配到各个工作项，工作项是以WBS为基础的。成本预算过程的输出之一是项目成本预算计划。可用来管理后续成本工作，可用作项目绩效衡量标准。制订软件项目预算要将项目成本估算分配到各个工作项，工作项是以83制订在制订软件项目成本预算时要注意：资源计划的匹配资源计划由项目经理制订要与WBS等相对应，以保证预算的全面性和有效性预算的全面性不要漏算预算的综合性不仅仅是简单的数字，而是资源、成本估算和预算分解说明的有机结合。制订在制订软件项目成本预算时要注意：84MicorsoftWordforWindows1.0开发原计划为一年，而实际情况为五年。图3.9项目估算所需的天数MicorsoftWordforWindows1.085MicorsoftWordforWindows1.0开发延迟原因：项目初期制订的开发目标是不可实现的用最快的速度开发最好的字处理软件，12个月完成。过紧的进度计划降低了计划的精确度创新点过多，不利于快速开发。一个目标都很困难，更不用说要同时完成两个人员不稳定，且因为任务紧，代码质量低不完整，造成维护软件稳定性上超期。MicorsoftWordforWindows1.086启示：估算应征求所有项目干系人的意见，并采用可靠的模型算法。高层的决定不总是对的，需要和专家、项目组成员共同协商。启示：873.4软件项目监控3.4软件项目监控883.4软件项目监控软件项目成本控制包括监控成本预算执行状况，确保正在执行的预算计划是有效的，对于不合适的计划进行修改变更后及时通知项目干系人等。3.4软件项目监控软件项目成本控制包括89项目成本估算不准确预算不详细成本预算变更不及时项目成本估算不准确90项目成本监控的目的是确保项目成本管理规范行到执行，项目干系人对项目成本目标有共同的理解，软件项目成本监控的要素有：资源计划的完备性成本估算的准确性预算计划的有效性成本控制过程的完备性项目成本监控的目的是确保项目成本管理规范行到执行，项目干系人91

在实践中，需要引入当前完成项目的进度占总进度的多少这样的概念，通过累加预算成本、实际成本和这个值一起来对项目的进度和估算进行综合的分析，当这样做的时候，项目的进度和成本偏差能够同时被发现。这时，通常使用赢得值法进行分析。赢得值法是一种能全面衡量项目成本、进度的整体方法；以资金已经转化为项目成果的量来衡量；赢得值法是监视和报告项目进展情况的必要工具。简单的说，赢得值法能够监视、跟踪和报告项目的进度和成本情况，它不仅适用于大型的项目，同样适用于中型项目和小型项目。92在实践中，需要引入当前完成项目的进度占总进度的多少这样的概92EarnedValue分析法用BCWP、ACWP、BCWS三个基本值来表示项目状态，项目管理者能够清楚的辨别项目的进度和成本是否存在偏差。并以此预测项目可能的完工时间和完工时的可能费用。EarnedValue分析法用BCWP、ACWP、BCWS93累计计划成本额（BCWS:BudgetedCostofWorkScheduled):

某一时点应当完成的工作所需投入资金或花费成本的累计值。等于计划工作量与预算单价的乘积之和。是衡量项目进度和成本费用的一个基准。累计计划成本额（BCWS:BudgetedCostof94赢得值或完成投资额（BCWP:BudgetedCostofWorkPerformed)某一时点已经完成的工作所需投入资金的累计值。等于已完成工作量与预算单价的乘积之和。是反映了满足质量标准的工作实际进度和工作绩效，体现了投资额到项目成果的转化。赢得值或完成投资额（BCWP:BudgetedCost95实际成本额（ACWP:ActualCostofWorkPerformed)某一时点已经完成的工作所实际花费成本的总金额。等于已完成工作量与实际支付单价的乘积之和。实际成本额（ACWP:ActualCostofWor96

通过对3个基本值的对比，可对项目的实际进展情况作出明确的测定的衡量，有利于对项目进行监控。图3.10赢得值法示意图通过对3个基本值的对比，可对项目的实际进展情况作出明确的测97

使用赢得值法进行成本、进度综合控制，必须定期监控以上3个参数。在项目开始之前，必须先为在整个项目工期内如何和何时使用资金作出预算和计划。在项目开始后监督实际成本和工作绩效以确何成本、进度都在控制范围之内。使用赢得值法进行成本、进度综合控制，必须定期监控以上3个参98项目预算和计划（CBC)收集实际成本(CAC)计算赢得值(CEW或BCWP)成本、进度绩效(CPI、CV)成本、进度控制具体步骤见书P109。主要有以下主要内容：项目预算和计划（CBC)具体步骤见书P109。主要有以下主要99项目预算和计划（CBC)制定详细的项目预算，把预算分解到每个工作包。为每个工作包建立总预算成本（TBC:TotalBudgetedCost)将每一个TBC分配到各工作包的整个工期中。每期的成本计划依据各工作包的各分项工作量进度计划来确定。当每一个工作包所需完成的工程量分配到工期的每个区间后，就能确定何时需要多少预算。将每期预算成本累加得出累计计划预算成本（CBC:CumulativeBudgetedCost或BCWS：BudgetedCostofWorkScheduled)项目预算和计划（CBC)100收集实际成本(CAC)在项目执行过程中，对已发生成本进行汇总，即累计已完工作量与合同单价之积，形成累计实际成本(CumulativeActualCost,CAC)。收集实际成本(CAC)101计算赢得值(CEW或BCWP)赢得值是整个项目期间必须的重要参数对项目每期已完成工作量与预算单价之积进行累积，即可确定累计赢得值（CEV:CumulativeEarnedValue）或（BCWP).计算赢得值(CEW或BCWP)102成本、进度绩效(CPI、CV)CEV与CAC实际是在同样进度下的价值比较，它反映了项目成本控制的状况和效率。成本绩效指数（CPI:CostPerformanceIndex)是衡量成本绩效的指标。CV也是衡量成本绩效的指标。成本、进度绩效(CPI、CV)103成本、进度控制要十分关注CPI或CV的走势。当CPI小于1时或逐步变小，CV为负且绝对值越来越大时，就要及时制订纠偏措施并加以实施。注意在那些有负成本差的工作包或分项工作上。根据CPI或CV值确定采取纠正措施的优先权。成本、进度控制104软件项目成本管理课件(同名312)105完工估算（EAC）成本总计由于劳力工资较高，成本超过估算约5.9%。完工估算（EAC）成本总计106进度总结对偏差分析表进行说明，配有里程碑报告。进度总结107软件项目成本管理课件(同名312)108小结成本概念软件项目成本估算时机软件项目规模估算WBS、FP、LOC、PERT软件项目成本估算方法专家判定、类比、自顶向下、自底向上、算法模型COCOMO模型（基本、中级、详细）软件项目成本监控赢得值分析法小结成本概念109估算的时机系统设计：E3系统设计阶段给出产品的完整软件体系结构和各个子系统及模块的说明。估算的时机系统设计：E3110一.专家判定Delphi技术图3.4Delphi成本估算迭代表的样例一.专家判定Delphi技术图3.4Delphi成本估算111产品和进度：何时提供何种产品？没有系统的开发方法，缺乏文档和复审一种预测未来事件的技术。要与WBS等相对应，以保证预算的全面性和有效性对于不合适的计划进行修改变更后及时通知项目干系人等。资源计划由项目经理制订可用来管理后续成本工作，可用作项目绩效衡量标准。后将其引入到软件规模估计的应用中。在软件成本估算中，有时耗费大量精力收集的用于估算的信息项,在进行估算时却因为与估算需要关系不在而不被使用,因而大量的艰难工作和细致分析付之东流。36，D是项目持续时间(以月计)a、b、c和d是指不同软件开发方式的经验值。赢得值或完成投资额（BCWP:BudgetedCostofWorkPerformed)要保留以往完成项目的历史记录。客户需求阶段列出客户需要的基本软件功能。假定：如果资源具备的话，在什么条件下承诺交付该估算值？静态单变量模型用同一个基本公式通过同一个预测量来估算所需要的值。常见公式：其中C是待估算的量，L是用作输入的预测量，a,b是经验参数产品和进度：何时提供何种产品？静态单变量模型用同一个基本公式112其他模型当预测量是LOC时，估算模型有：当预测量是FP时，估算模型有：其他模型当预测量是LOC时，估算模型有：113

Putnam估算模型

1978年Putnam提出的模型，是一种动态多变量模型。L=Ck*K1/3*td4/3

其中：

L--------源代码行数(以LOC计)K--------整个开发过程所花费的工作量（以人年计）td--------开发持续时间（以年计）Ck-------技术状态常数，它反映“妨碍开发进展的限制”，取值因开发环境而异.Ck的典型值

开发环境

开发环境举例

2000

差

没有系统的开发方法，缺乏文档和复审

8000

好

有合适的系统的开发方法，有充分的文档和复审

11000

优

有自动的开发工具和技术

它是假定在软件开发的整个生存期中工作量有特定的分布。这种模型是依据在一些大型项目（总工作量达到或超过30个人年）中收集到的工作量分布情况而推导出来的，但也可以应用在一些较小的软件项目中。Putnam模型可以导出一个“软件方程”，把已交付的源代码（源语句）行数与工作量和开发时间联系起来。

Putnam估算模型

1978年Putnam提出1143、确定软件需求软件需求对估算很重要。软件需求说明书的价值由它可检验的程度决定的，可检验性越好，则价值越高。如“快速”是不可检验，“响应时间不超过xx秒”是可检验的。完成软件需求说明书从不可检验到可检验的转化，需要许多工作量。3、确定软件需求115EarnedValue分析法用BCWP、ACWP、BCWS三个基本值来表示项目状态，项目管理者能够清楚的辨别项目的进度和成本是否存在偏差。并以此预测项目可能的完工时间和完工时的可能费用。EarnedValue分析法用BCWP、ACWP、BCWS116实际成本额（ACWP:ActualCostofWorkPerformed)某一时点已经完成的工作所实际花费成本的总金额。等于已完成工作量与实际支付单价的乘积之和。实际成本额（ACWP:ActualCostofWor117成本管理的重要性美国斯坦迪什公司1995年的研究表明，项目失败的真正原因，包括成本失控，是没有很好的项目管理。成本管理的重要性美国斯坦迪什公司1995年的研究表明，项目失118软件项目的成本可控吗？软件项目的成本控制实在太难，按项目预算几乎是不可能的。（1）

需求不确定项目工期不确定、费用无法控制；（2）项目采用的技术先进，技术风险很大，因此，费用无法控制；（3）

软件开发是一个人行为，因此，人员的积极性、工作效率、配合情况等，不像其他行业的项目那样，可以准确地预测。因此，工作效率无法确定；（4）

项目具有独特性，没有历史资料可以借鉴。因此，成本估算带有很大的盲目性。为了使公司和项目组的项目管理水平获得提升，项目经理首先要提高自己的认识能力和实际管理水平。软件项目的成本可控吗？软件项目的成本控制实在太难，按项目预算119本章主要内容：3.1概述3.2软件规模估算3.3软件项目成本估算3.4软件项目成本监控本章主要内容：3.1概述120这种模型是依据在一些大型项目（总工作量达到或超过30个人年）中收集到的工作量分布情况而推导出来的，但也可以应用在一些较小的软件项目中。实际工作中，也常常使用KLOC（千代码行）来表示程序长度。各程序设计语言中实现一个功能点所需的代码行数的粗略估算(LOC/FP)5、运用多种独立的技术和原始资料L是用作输入的预测量，式中E为开发所需的人力（人/月）。系统设计阶段给出产品的完整软件体系结构和各个子系统及模块的说明。实际成本额（ACWP:ActualCostofWorkPerformed)10

），将15个评分值相乘即可获得EAF.要与WBS等相对应，以保证预算的全面性和有效性一个目标都很困难，更不用说要同时完成两个最好由多个专家进行估算。不仅仅是简单的数字，而是资源、成本估算和预算分解说明的有机结合。没有系统的开发方法，缺乏文档和复审根据成本估算值而做的承诺程度。3.1概述这种模型是依据在一些大型项目（总工作量达到或超过30个人年）121成本的解释)成本的解释)122软件项目成本包含：人力资源成本:工资、福利、招聘和培训等成本费用。软硬件资源成本：开发和测试工具、服务器、网络设备等软硬件资源费用。商务活动成本：差旅费、交通费、接待费、通信费等。其他成本费用：未计入上述分类的成本费用。软件项目成本包含：123为了评价项目成本的可确定程度为了评价项目成本的可确定程度124根据是否可以直接用一种经济的方式识别和跟踪项目成本，软件项目成本可分为以上类型。根据是否可以直接用一种经济的方式识别和跟踪项目成本，软件项目125软件项目成本管理活动包括：软件系统规模估算软件项目成本估算软件项目成本预算制订软件项目成本监控成本管理目标是确保在批准的预算范围内完成项目所需的各项任务。软件项目成本管理活动包括：成本管理目标是确保在批准的预算范围126估算的时机软件项目估算不是一劳永逸的活动，而是随项目的进行而进行的一个逐步求精的过程。估算的时机软件项目估算不是一劳永逸的活动，而是随项目的进行而127估算的时机对任何一种估算方法来说，估算的时机和精度都是一种矛盾。图3.1软件项目估算的时机估算的时机对任何一种估算方法来说，估算的时机和精度都是一种矛128估算的时机选择合适的时间点进行估算是估算中必须考虑的一个问题。因为估算本身也需要成本。图3.2软件项目估算时机软件产品生命周期及需要进行估算的五个时间点：E1,E2,E3,E4,E5估算的时机选择合适的时间点进行估算是估算中必须考虑的一个问题129估算的时机可行性论证：E1客户需求阶段列出客户需要的基本软件功能。时间点E1的估算可以为软件组织提供初步信息，否则需要重新考虑项目的可行性。估算的时机可行性论证：E1130估算的时机需求分析：E2产品定义阶段完成对项目的规格说明，进一步细化系统功能。此时估算有助于软件组织在进入产品开发前再次权衡产品的可行性估算的时机需求分析：E2131估算的时机系统设计：E3系统设计阶段给出产品的完整软件体系结构和各个子系统及模块的说明。估算的时机系统设计：E3132估算的时机系统实现：E4设计通过审查之后，系统的实现工作就开始了。该阶段结束时，前面各项活动中消耗的资源（时间及人力等）和软件工作量均可获得，从而可对原有的估算进行调整，后期需要的工作则按此估算进行计划。估算的时机系统实现：E4133估算的时机系统运行维护：E5当所有的工作都已完成并得到了验证后，系统就可以投入运行了。估算工作实际上是对估算过程的评价，即用实际的消耗与各个阶段估算值进行比较，为下一项目积累宝贵的经验。估算的时机系统运行维护：E51343.2软件项目规模估算3.2软件项目规模估算135因此，工作效率无法确定；对于不合适的计划进行修改变更后及时通知项目干系人等。项目初期制订的开发目标是不可实现的中级COCOMO模型在基本COCOMO模型的基础上，再用涉及产品、硬件、人员、项目等方面的影响因素调整工作量的估算。假定：如果资源具备的话，在什么条件下承诺交付该估算值？完成软件需求说明书从不可检验到可检验的转化，需要许多工作量。因为估算本身也需要成本。UFC：UnadjustedFunctionPointCount其缺点是难以识别较低级别上的技术性困难。根据成本估算值而做的承诺程度。a、b、c和d是指不同软件开发方式的经验值。一种预测未来事件的技术。如“快速”是不可检验，“响应时间不超过xx秒”是可检验的。专家召开小组会议讨论上次估计结果，自愿修改个人估计。（1）估计新的软件开发项目；3.2软件项目规模估算工作分解结构WBS 典型的WBS（WorkBreakdownStructure）因此，工作效率无法确定；3.2软件项目规模估算工作分解结构136工作分解结构WBS常用的软件规模度量标准：代码行LOC功能点FP工作分解结构WBS常用的软件规模度量标准：137工作分解结构WBS软件规模的估计步骤：1.在技术允许的条件下，应从最详细的WBS开始；2.精确定义度量的标准；3.估计底层每一模块的规模，汇总以得到 总体估计；4.适当考虑偶然因素的影响。

WBS越细，对软件规模的估计就越准确。工作分解结构WBS软件规模的估计步骤：138代码行： 代码行LOC是常用的源代码程序长度的度量标准。 代码行可分为：无注释的代码行（NCLOC）和注释的源代码行（CLOC） 实际工作中，也常常使用KLOC（千代码行）来表示程序长度。 一代码行（1LOC）价值和人月均代码行数可以体现一个软件生产组织的生产能力。代码行：139由IBM工程师A.J.Albrecht于79年首次提出;是基于系统功能的一种规模估计方法，FP法将信息系统抽象成输入数据、输出数据、查询数据、系统内部文件及系统外部文件由IBM工程师A.J.Albrecht于79年首次提出;140计算未调整的功能点数UFC的步骤UFC：UnadjustedFunctionPointCount（1）计算所需要的输入、输出、查询、外部文件、内部文件的数量。计算未调整的功能点数UFC的步骤UFC：Unadjusted141计算功能点数的步骤：功能项权

重简单一般复杂输入346输出457查询346外部文件71015内部文件5710（2）判断项目复杂性，计算UFC由估计人员对项目的复杂性作出判断，分成简单、一般、复杂三种情况。然后根据下表求出功能项的加权和。计算功能点数的步骤：功能项权重简单一般复杂输入346142功能点FP是由未调整的功能点数UFC与技术复杂度因子（TCF）相成得到。功能点FP是由未调整的功能点数UFC与技术复杂度因子（TCF计算功能点数的步骤：从上表计算出：

TCF=0.65+0.01*(SUM(Aj))TCF的取值范围为0.65～1.35，分别对应着组成部分Aj都取值0和5，得到功能点FP的计算公式：

FP=UFC*TCF计算功能点数的步骤：从上表计算出：144FP有助于在软件项目的早期作出规模估计，但无法自动度量。常用做法：早期估计时用FP，再依据经验将FP转化为LOC,再使用LOC继续进行估计。FP有助于在软件项目的早期作出规模估计，但无法自动度量。145功能点度量在以下情况下特别有用：（1）估计新的软件开发项目；（2）应用软件包括很多输入输出或文件活动；（3）拥有经验丰富的功能点估计专家；（4）拥有充分的数据资料，可以相当准确地将功能点转化为LOC。功能点度量在以下情况下特别有用：146各程序设计语言中实现一个功能点所需的代码行数的粗略估算(LOC/FP)程序设计语言平均值中值低值高值C16210933704C++665329178Java635377------SQL40377110VisualBasic474216158各程序设计语言中实现一个功能点所需的代码行数的粗略估算(LO147计划评审技术(ProgramEvaluationandReviewTechnique，PERT)是20世纪50年代末开发的用于项目进度规划的一种技术。后将其引入到软件规模估计的应用中。公式见书P85计划评审技术(ProgramEvaluationand1483.3软件项目成本估算3.3软件项目成本估算149软件生产率估算生产率数据的获取选择一些最近完成的项目，要和等完成项目相似。获得各个项目的LOC数据，各项目都使用相同的计数方案对于更改过的程序，记录更改代码所占比例计算投入到每个项目的人员数量计算各个项目的软件生产率即LOC/PM,进而求出平均值。软件生产率估算生产率数据的获取150软件生产率估算影响因素需要大量的历史数据为基础，可以借公开的数据作参考，对比自己的数据，以确定自身生产率。软件生产率估算影响因素151软件生产率估算估算可以根据历史数据比如表中数据进行生产率数据的估算软件生产率估算估算152成本估算是软件项目计划中的一种重要组成部分；成本估算目标是要完成软件项目所需费用的估计和计划。成本估算是在无法以高可靠性预计的环境下进行的。根据历史数据进行估算----理想状况成本估算是软件项目计划中的一种重要组成部分；153软件项目成本管理课件(同名312)154一.专家判定由专家根据经验和对项目的理解对项目进行成本估算。最好由多个专家进行估算。对于由多个专家得到的多个估算值合成一个最终的估算值。可采用的方法有：求中值或平均值召开小组会议Delphi技术WidebandDelphi技术一.专家判定由专家根据经验和对项目的理解对项目进行成本估算。155一.专家判定求中值或平均值方法简单，但易于受到极端估算值的影响而造成偏差。一.专家判定求中值或平均值156一.专家判定召开小组会议组织专家们召开小组会议进行讨论，统一某一估算值；好处：去掉一些极端偏颇无知的估算不利：易受权威人士或能言善辩人士影响一.专家判定召开小组会议157一.专家判定Delphi技术一种预测未来事件的技术。作为一种使专家意见一致的方法。一.专家判定Delphi技术158一.专家判定Delphi技术步骤：协调员给每位专家一份软件规格说明书和一张记录估算值的表格;专家无记名填写表格，相互间不能讨论；协调员对专家填在表上的估算进行小结，给出估算迭代表，要求专家进行下一轮估算。专家重新无记名填表。一.专家判定Delphi技术159一.专家判定Delphi技术图3.4Delphi成本估算迭代表的样例一.专家判定Delphi技术图3.4Delphi成本估算160一.专家判定WidebandDelphi技术将小组讨论与Delphi技术结合起来：给每位专家发一份软件规格说明书和一张记录估算值的表格;专家开会讨论软件产品和任何与估算相关的问题专家无记名填写表格；协调员对专家填在表上的估算进行小结，给出估算迭代表，要求专家进行下一轮估算。专家召开小组会议讨论上次估计结果，自愿修改个人估计。一.专家判定WidebandDelphi技术161一.专家判定WidebandDelphi技术将小组讨论与Delphi技术结合起来：一.专家判定WidebandDelphi技术162二.类比把当前项目和以前做过的类似项目比较，获得其工作量的估算值。要保留以往完成项目的历史记录。基本步骤是：整理出项目功能列表和实现每个功能的代码行；标识出每个功能列表与历史项目的相同点和不同点，特别要注意历史项目做得不够的地方；通过步骤1和2得出各个功能的估计值；产生规模估计。二.类比把当前项目和以前做过的类似项目比较，获得其工作量的估163三.自顶向下推算出项目的总体成本或工作量，然后按比例分配到各个组成部分中去。优点：对系统级的重视，一般不会遗漏系统级事务的成本。如系统集成、用户手册、配置管理等。其缺点是难以识别较低级别上的技术性困难。这些困难会使成本上升，有时会遗漏开发软件中的某些部分。三.自顶向下推算出项目的总体成本或工作量，然后按比例分配到各164软件需求说明书的价值由它可检验的程度决定的，可检验性越好，则价值越高。KLOC为估计提交的千代码行。中级COCOMO模型在基本COCOMO模型的基础上，再用涉及产品、硬件、人员、项目等方面的影响因素调整工作量的估算。将每期预算成本累加得出累计计划预算成本（CBC:CumulativeBudgetedCost或BCWS：BudgetedCostofWorkScheduled)（4）

项目具有独特性，没有历史资料可以借鉴。当预测量是FP时，估算模型有：估算应征求所有项目干系人的意见，并采用可靠的模型算法。a、b、c和d是指不同软件开发方式的经验值。各程序设计语言中实现一个功能点所需的代码行数的粗略估算(LOC/FP)DOC＝49×L1.创新点过多，不利于快速开发。按照模型中的变量依存关系某一时点已经完成的工作所实际花费成本的总金额。计算赢得值(CEW或BCWP)如“快速”是不可检验，“响应时间不超过xx秒”是可检验的。三.自顶向下任务分解技术首先把软件开发工程分解为若干个相对独立的任务。再分别估计每个单独的开发任务的成本，最后累加起来得出软件开发工程的总成本。估计每个任务的成本时，通常先估计完成该项任务需要用的人力(以人月为单位)，再乘以每人每月的平均工资而得出每个任务的成本。1652022/12/12软件需求说明书的价值由它可检验的程度决定的，可检验性越好，则165四.自底向上自底向上估算是把待开发的软件逐步细化，直到能明确工作量，由负责该部分的人给出工作量的估算值，然后把所有部分相加，就得到了软件开发的总工作量。每个部分的估算较精确。易于忽略许多与软件开发有关的系统级成本。总估算值偏低。花费的精力更多。四.自底向上自底向上估算是把待开发的软件逐步细化，直到能明确166四.自底向上任务单元法，最常见的一种方法。四.自底向上任务单元法，最常见的一种方法。167五算法模型经验模型容易受主观因素的影响。采用数学方法建立正式的模型是必需的。五算法模型经验模型容易受主观因素的影响。168五算法模型按照模型中的变量依存关系静态模型动态模型按照变量的多少，单变量模型多变量模型五算法模型按照模型中的变量依存关系169静态单变量模型用同一个基本公式通过同一个预测量来估算所需要的值。常见公式：其中C是待估算的量，L是用作输入的预测量，a,b是经验参数静态单变量模型用同一个基本公式通过同一个预测量来估算所需要的170静态单变量模型马里兰大学软件工程实验室所建立的SEI模型公式：L是用作预测量的LOC，E是以人有为单位的工作量，DOC是以页数为单位的文本量，D是以月为单位的所需时间。静态单变量模型马里兰大学软件工程实验室所建立的SEI模型公式171静态多变量模型基于静态单变量模型，但还取决于几个能代表软件开发环境的各种因素的变量，如软件开发方法、用户需求变化情况等。如COCOMO模型，静态多变量模型基于静态单变量模型，但还取决于几个能代表软件开172动态多变量模型Putnam模型就是一个动态多变量模型，见后面部分。动态多变量模型Putnam模型就是一个动态多变量模型，见后面173其他模型对以前的软件项目中收集到的数据进行回归分析而建立的模型，其结构如下：其中，A、B、C是由经验估计的常数，E是以人月为单位的工作量，X是预测变量，通常是LOC和FP两种方式。其他模型对以前的软件项目中收集到的数据进行回归分析而建立的模174其他模型当预测量是LOC时，估算模型有：当预测量是FP时，估算模型有：其他模型当预测量是LOC时，估算模型有：175软件项目成本管理课件(同名312)176IBM估算模型1977年，IBM的Walston和Felix提出了如下的估算公式：E＝5.2×L0.91，L是源代码行数(以KLOC计)，E是工作量（以PM计）D＝4.1×L0.36，D是项目持续时间(以月计)

S＝0.54×E0.6，S是人员需要量(以人计)

DOC＝49×L1.01。DOC是文档数量(以页计)

在此模型中，一般指一条机器指令为一行源代码。一个软件的源代码行数不包括程序注释、作业命令、调试程序在内。对于非机器指令编写的源程序，如汇编语言或高级语言程序，应转换成机器指令源代码行数来考虑。

IBM估算模型1977年，IBM的Walston和Felix177COCOMO估算模型

基本COCOMO模型估算公式：

工作量:E=a*(KLOC)b

进度:D=c*(E)d

式中E为开发所需的人力（人/月）。D为所需的开发时间（月）。KLOC为估计提交的千代码行。

a、b、c和d是指不同软件开发方式的经验值。

由TRW公司开发，Boehm提出的结构化成本估算模型（ConstructiveCostMode）是最精确、最易于使用的成本估算方法之一。COCOMO估算模型

基本COCOMO模型估算公式：

178软件项目成本管理课件(同名312)179软件项目成本管理课件(同名312)180中级COCOMO模型

中级COCOMO模型估算公式：

式中E为开发所需的人力（人/月）。S为以KLOC计数的程序规模，EAF是工作量调整因子，a、b、c、d是指不同软件开发方式的经验值。其中aSb是名义工作量。

EAF根据引入的15个成本驱动量计算，（见表3.10

），将15个评分值相乘即可获得EAF.进度:D=c*(E)d中级COCOMO模型中级COCOMO模型估算公式：

181中级COCOMO模型EAF根据引入的15个成本驱动量计算，（见表3.10

），将15个评分值相乘即可获得EAF.中级COCOMO模型EAF根据引入的15个成本驱动量计算，（182详细COCOMO模型详细COCOMO模型中名义工作量aSb估算公式与开发时间的计算公式和中级COCOMO模型相同，式中E为开发所需的人力（人/月）。S为以KLOC计数的程序规模，a、b、c、d是指不同软件开发方式的经验值。

其不同之处在于成本驱动因素的获取方式，（见表3.11-3.13）

这些成本驱动因素与下列方面有关：与产品层次有关（模块—子系统---系统）与软件开发阶段有关：需求计划和产品设计(RPD)详细设计(DD)编码和单元测试(CUI)集成测试(IT)进度:D=c*(E)d详细COCOMO模型详细COCOMO模型中名义工作量aSb估183详细COCOMO模型详细COCOMO模型184详细COCOMO模型详细COCOMO模型185详细COCOMO模型详细COCOMO模型186COCOMO模型总结COCOMO模型是按其详细程度分为三级：基本COCOMO模型中级COCOMO模型详细COCOMO模型基本COCOMO模型是是一个静态单变量模型，它用一个以已估算出来的原代码行数(LOC)为自变量的经验函数计算软件开发工作量。中级COCOMO模型在基本COCOMO模型的基础上，再用涉及产品、硬件、人员、项目等方面的影响因素调整工作量的估算。详细COCOMO模型包括中级COCOMO模型的所有特性，但更进一步考虑了软件工程中每一步骤（如分析、设计）的影响。187COCOMO模型总结COCOMO模型是按其详细程度分为三级：187

Putnam估算模型

1978年Putnam提出的模型，是一种动态多变量模型。L=Ck*K1/3*td4/3

其中：

L--------源代码行数(以LOC计)K--------整个开发过程所花费的工作量（以人年计）td--------开发持续时间（以年计）Ck-------技术状态常数，它反映“妨碍开发进展的限制”，取值因开发环境而异.Ck的典型值

开发环境

开发环境举例

2000

差

没有系统的开发方法，缺乏文档和复审

8000

好

有合适的系统的开发方法，有充分的文档和复审

11000

优

有自动的开发工具和技术

它是假定在软件开发的整个生存期中工作量有特定的分布。这种模型是依据在一些大型项目（总工作量达到或超过30个人年）中收集到的工作量分布情况而推导出来的，但也可以应用在一些较小的软件项目中。Putnam模型可以导出一个“软件方程”，把已交付的源代码（源语句）行数与工作量和开发时间联系起来。

Putnam估算模型

1978年Putnam提出1881，建立成本估算目标

在软件成本估算中，有时耗费大量精力收集的用于估算的信息项,在进行估算时却因为与估算需要关系不在而不被使用,因而大量的艰难工作和细致分析付之东流。

因此，要先建立成本估算目标，以此来制定以后工作的详细程度。1，建立成本估算目标189建立成本估算目标规划需要的数据和资源确定软件需求拟定可行的细节运用多种独立的技术和原始资料比较并迭代各个估算值随访跟踪

建立成本估算目标1901，建立成本估算目标

帮助因素：软件项目当前所处的生命周期阶段，它大致对应于对软件项目的认可程度；根据成本估算值而做的承诺程度。1，建立成本估算目标1911，建立成本估算目标

软件项目在生命周期阶段的估算范围1，建立成本估算目标软件项目在生命周期阶段的估算范围1921，建立成本估算目标为了决策需要，有时还要作出乐观和悲观估算，然后在随后的工作中逐步调整。1，建立成本估算目标1932、规划需要的数据和资源为了避免出现因准备不充分而导致作出不可变更的软件承诺，我们可以将软件成本估算看成一个小型项目，制定一份项目规划，可包括如下内容：目的：为什么要求出该估算值？产品和进度：何时提供何种产品？责任：每种产品由何人负责？过程：如何进行该工作，采用哪些成本估算工具和技术？需要的资源：完成该工作需要多少数据、时间、费用及工作量等？假定：如果资源具备的话，在什么条件下承诺交付该估算值？2、规划需要的数据和资源1943、确定软件需求软件需求对估算很重要。软件需求说明书的价值由它可检验的程度决定的，可检验性越好，则价值越高。如“快速”是不可检验，“响应时间不超过xx秒”是可检验的。完成软件需求说明书从不可检验到可检验的转化，需要许多工作量。3、确定软件需求1954、拟定可行的细节考察越细，对软件开发技术理解得就越透彻。在估算时把软件分得越细，软件模块的个数越多，总的误差就减少。对软件必须执行的功能考