第五章 软件项目成本管理_软件项目管理中成本管理的内容

• 软件项目的成本管理，就是为了确保项目在既定预算内按时、按质、经济、高效地实现项目目标所开展的一种项目管理过程。

• 项目的成本管理包括成本估算、成本预算和成本控制。

本章内容提要

5.1 软件项目成本管理概述
5.2 软件规模度量
5.3 成本估算
5.4 成本预算
5.5 成本控制

5.1 软件项目成本管理概述

• 软件项目规模一般是指所开发软件的规模大小，它的度量方法一般有两种：

       LOC(Lines of Code)：源代码程序长度的测量
       FP(Function Point)：系统功能数量的测量

• 软件项目工作量是指为了提供软件的功能而必须完成的软件工程任务量。其度量单位为：

       人月、人天、人年：人在单位时间内完成的任务量

       为了确定工作量度量单位，可设定一个“标准程序员”，例如具有15~18个月开发经验的程序员。

• 工作量与规模紧密相关，此外还与项目和产品特性（如团队的技术和能力、所使用的语言和平台、团队的稳定性、项目中的自动化程度、产品复杂性等）相关。

• 在不会引起混淆的情况下，工作量和规模这两个概念可不做区别。

软件项目成本

• 完成软件项目工作量相应付出的代价，即待开发软件项目所需要的资金。

• 人的劳动消耗所需要的代价是软件开发的主要成本。

• 成本一般采用货币单位来计算，如人民币、美元等。

工作量和成本的关系

• 工作量是项目成本的主要考虑因素，完成项目工作量所消耗的成本是项目成本最主要的部分。因此，项目的工作量估算和成本估算常常同时进行。

• 如果确定了单位工作量所消耗的成本，则可根据项目工作量直接计算出完成项目工作量所消耗的成本。

    例如：如果一个软件项目的工作量是20人月，而企业的人力成本参数是2万元/人月，则完成项目工作量所需的成本是40万元。

软件项目成本的构成

• 软件项目通常是技术密集型项目，其成本构成与一般的建设项目有很大区别，其中最主要的成本是在项目开发过程中所花费的工作量及相应的代价，它不包括原材料及能源的消耗，主要是人的劳动消耗。

• 一般来讲，软件项目的成本构成主要包括以下几种：

（1）软硬件购置成本：这部分费用虽然可以作为企业的固定资产，但因技术折旧太快，需要在项目开发中分摊一部分费用。
（2）人工成本（软件开发、系统集成费用）：主要是指开发人员、操作人员、管理人员的工资福利费等。在软件项目中人工费用总是占有相当大的份额，有的可以占到项目总成本的80％以上。
（3）维护成本： 维护成本是在项目交付使用之后，承诺给客户的后续服务所必需的开支。可以说，软件业属于服务行业，其项目的后期服务是项目必不可少的重要实施内容。所以，维护成本在项目生命周期成本中，占有相当大的比例。
（4）培训费：培训费是项目完毕后对使用方进行具体操作的培训所花的费用。
（5）业务费、差旅费：软件项目常以招投标的方式进行，并且会经过多次的谈判协商才能最终达成协议，在进行业务洽谈过程中所发生的各项费用比如业务宣传费、会议费、招待费、招投标费等必须以合理的方式计入项目的总成本费用中去。此外，对异地客户的服务需要一定的差旅费用。
（6）管理及服务费：这部分费用是指项目应分摊的公司管理层、财务及办公等服务人员的费用。
（7）其他费用：包括：基本建设费用，如新建、扩建机房、购置计算机机台、机柜等的费用；材料费，如打印纸、磁盘等购置费；水、电、气费；资料、固定资产折旧费及咨询费等等。

• 从财务角度看，可将项目成本构成按性质划分为两种：

（1）直接成本。与具体项目的开发直接相关的成本。如人员的工资、外包外购成本等。又可细分为开发成本、管理成本、质量成本等。
（2）间接成本。不归属于一个具体的项目，是企业的运营成本，分摊到各个项目中。如房租、水电、保安、税收、福利、培训，等等。

软件项目成本管理的内容和目标

• 软件项目成本管理的内容包括成本估算、成本预算、成本控制。

• 现实中，软件项目经常成本超支，这是因为：项目需求含糊，经常会由于客户不断变化的实际要求而变更计划；项目成本结构复杂，成本核算方法和实施难度大；成本的估算不合理，行业标准不明确，尤其是间接成本的估算没有标准成熟的方法和科学依据；项目涉及新的技术或商业过程，有很大的内在风险。

• 结合IT项目的成本特点，应用恰当的项目成本管理技术和方法可以很有效地改变成本超支状况。

• 成本管理的主要目的就是将项目的运作成本控制在预算的范围内，或者控制在可以接受的范围内。

5.2 软件规模度量

• 软件的规模是影响软件项目成本和工作量的主要因素。

• 最常用的度量软件规模的方法是代码行（Lines of Code，LOC）和功能点（Function Point，FP），分别利用代码行数和功能点数来表示软件系统的规模。

代码行（LOC）

从软件程序量的角度定义项目规模。

1. 要求功能分解足够详细。
2. 一般是根据经验数据估计实现每个功能模块所需的源程序行数，然后把源程序行数累加起来，得到软件的整体规模。
3. 有一定的经验数据（类比和经验方法）。
4. 与具体的编程语言有关。

优点：

1.     直观、准确（在有代码的情况下）、易于计算（可使用代码行统计工具）。

缺点：

1. 对代码行度量没有公认的标准定义。
2. 代码行数量依赖于所用的编程语言和个人的编程风格。
3. 在项目早期,需求不稳定、设计不成熟、实现不确定的情况下很难准确地估算代码量。

功能点（FP）

• 用系统的功能数量来测量其规模，与实现产品所使用的语言没有关系。

• 对系统的外部功能和内部功能进行计数。

• 根据技术复杂度因子（权）对它们进行调整，产生产品规模的度量结果。

功能点计算公式

• FP =UFC*TCF

1. UFC(Unadjusted Function Point Count)未调整功能点计数
2. TCF(Technical Complexity Factor)   技术复杂度因子

UFC的计算方法

• 首先计算功能计数项，对以下五类元素计数：

1. 用户输入：由用户输入的面向应用的数据项。
2. 用户输出：向用户提供的输出数据项。
3. 用户查询：要求系统回答的交互式输入。
4. 外部接口文件：与其它系统的接口数据文件。
5. 内部文件：系统使用的内部固定文件。

• 然后对各功能计数项加权并求和，得到UFC。

案例分析

• 某学院安装了一个工资系统，人事处要求创建一个子系统来分析每门课程的人力资源成本。要求该子系统提供查询每门课程人力资源成本的功能。每名教师所得工资的细节可以通过工资系统中的文件得到，教师花在教每门课上的小时数可通过一个基于计算机的计时表系统中的文件得到。该子系统将计算结果存放到由总会计系统读取的一个文件中，并产生一个报告，来显示每名教师每门课的课时数及这些课时数相应的成本。

• 问题：计算该子系统的UFC。（子系统产生的报告复杂度为高，其它所有元素的复杂度均为中等）

• 答案：UFC=1*7+1*4+3*7=32      

TCF的计算方法

每个技术复杂度影响因素的取值范围：

TCF=0.65+0.01(sum(Fi))： Fi:0-5,TCF:0.65~1.35

• 该子系统的功能点为：  FP=UFC*TCF=32*0.87=27.8
  

功能点度量的优缺点

• 优点：

1. 软件系统的功能与实现该软件系统的语言无关；
2. 在软件开发的早期阶段（如需求分析）就可通过对用户需求的理解获得软件系统的功能点数目，因而该方法可以较好地克服基于代码行的软件项目规模表示方法的不足。

• 缺点：

1. 功能点计算主要靠经验公式，主观因素比较多；
2. 没有直接涉及算法的复杂度，不适合算法比较复杂的软件系统；
3. 计算功能点所需的数据不好采集。
   

功能点与代码行的转换

5.3 成本估算

5.3.1 引言

• 成本估算是对完成项目所需费用的估计，它是项目成本管理的核心。

• 成本估算可以有一些误差。估算结果可用一个范围表示，例如$10000±$1000。

• 由于影响软件成本的因素太多（人、技术、环境等），成本估算仍然是很不成熟的技术，大多数时候需要经验。目前没有一个估算方法或者成本估算模型可以适用于所有软件类型和开发环境。
  

成本估算的依据

A:可以校准的常量; S为软件规模; E为规模的指数,说明不同规模软件具有的相对规模经济和不经济性;EM为成本驱动因子,反映某个项目特征对完成项目开发所需工作量的影响程度;n为描述软件项目特征的成本驱动因子的个数。

项目类型

• 有机（Organic）

1. 各类应用程序，例如数据处理、科学计算等。
2. 受硬件的约束比较小，接口环境灵活；软件的规模不是很大。

• 嵌入式（Embeded）

1. 系统程序，例如实时处理、控制程序等。
2. 在硬件和软件的严格约束条件下运行，对系统进行变更的代价很高；软件的规模任意。

• 半相连（Semidetached）

1. 介于上述两种系统之间。

COCOMO81 模型类别

• 基本COCOMO

    静态单变量模型。

• 中等COCOMO

    在基本模型基础上考虑各种影响因素（工作量驱动因子），调整模型。

• 高级COCOMO

    中等COCOMO模型基础上考虑软件工程中各个步骤的影响。

基本COCOMO

• E=a*(KLOC)^b

1. E是项目的工作量（以人月计）
2. KLOC是软件产品的代码行数（以千行计）
3. a、b是依赖于项目自然属性的参数

基本COCOMO系数表

基本COCOMO举例

• 一个33.3 KLOC的软件开发项目，属于半相连型的项目，采用基本COCOMO进行工作量的估算：

1. a=3.0，b=1.12
2. E = 3.0＊L ^1.12 = 3.0＊33.3 ^1.12 = 152 PM

中等COCOMO

• E=a*(KLOC)b*工作量系数

    工作量系数是根据成本驱动因子的打分计算得出，是对公式的校正系数。

中等COCOMO系数表

成本驱动因子

工作量系数的计算

• 规定每个成本驱动因子的取值范围，将其取值划分为非常低、低、正常、高、非常高等级别，每个级别对应一个值。例如，软件组织可以决定使用以下系数来评估分析员能力(ACAP)的影响：

    非常低（very low）   1.46
    低（low）                  1.19
    正常（nominal）        1.00
    高（hign）                 0.80
    非常高（very hign)     0.71

• 当每个成本驱动因子Fi的值选定后，工作量系数的计算如下：

    工作量系数=F1*F2*…Fi…*Fn

中等COCOMO举例

• 一个33.3 KLOC的软件开发项目，属于半相连型的项目，采用中等COCOMO进行工作量的估算：

1.  a=3.0，b=1.12
2. 工作量系数=0.70*0.85*1……*1.15=1.09
3. E  = 3.0＊33.3 ^1.12 ×1.09＝166 PM

高级COCOMO

• 工作量计算公式与中等COCOMO模型一样，区别主要在于：

• (1) 把待估算的软件项目分解为模块、子系统、系统3个级别，从而可以在更细的粒度上估算工作量。

• (2)考虑了在项目各开发阶段中，成本驱动因子所产生的影响。

COCOMO Ⅱ

• COCOMOⅡ给出了三个层次的工作量估算模型，这三个层次的模型在估算工作量时，对软件细节考虑的详尽程度逐级增加。

（1）应用组成（application composition）模型。这个模型主要用于估算构建原型的工作量，用于项目规划阶段。
（2）早期设计（early design）模型。适用于体系结构设计阶段。
（3）后体系结构（post-architecture）模型。适用于完成体系结构设计之后的软件开发阶段。

后体系结构模型

• E是工作量（以人月为单位），a是模型系数，KLOC是估计的源代码行数（以千行为单位），b是模型指数，fi(i=1~17)是成本驱动因子。

COCOMO 2对成本驱动因子的更新

• 与COCOMO81相比，COCOMOⅡ对成本驱动因子做了一些改变：

• 增加了4个成本驱动因子：要求的可重用性、需要的文档量、人员连续性、多地点开发

• 略去了COCOMO81模型中的2个成本驱动因子：虚拟机空间、实效编程经验使用情况

• 对某些成本驱动因子的取值大小做了调整。

b值分级模型

• COCOMO2对模型中指数b的确定方法进行了改进，采用了5个分级因素Wi(1≤i ≤5)，每个因素都划分成甚低、低、正常、高、甚高、特高6个级别，其取值分别为5、4、3、2、1、0，然后使用下式计算b的数值：

• 1.01 ≤b ≤1.26

b值分级模型中的5个分级因素

(1)项目先例性：指出对于开发组织来说该项目的新颖程度。
(2)开发灵活性：为了实现预先确定的外部接口需求及为了及早开发出产品而需要增加的工作量。
(3)风险排除度：反映了重大风险已被排除的比例。
(4)项目组凝聚力：反映了开发人员在目标和文化背景等方面相一致的程度，以及开发人员组成一个小组工作的经验。
(5)过程成熟度：反映了按照能力成熟度模型度量出的项目组织的过程成熟度。

COCOMO模型扩展及其系列

• Boehm教授及其研发团队对COCOMO模型做了许多扩展，用于解决不同领域内的问题，形成了COCOMO模型系列：

• COINCOMO(constructive incremental COCOMO)：用于支持增量开发中的成本估算。

• DBA COCOMO(database (access) doing  business as COCOMO Ⅱ)：基于数据库实现并支持灵活数据分析。

• COQUALMO(constructive quality model)：用于估算软件产品的遗留缺陷并体现质量方面的投资回报。

• iDAVE(information dependability attributed value estimation)：用于估算并跟踪软件依赖性方面投资回报。

• COPLIMO(constructive product line investment model)：支持对软件产品线的成本估算及投资回报分析。

• COPROMO(constructive productivity improvement model)：通过预测新技术中最成本有效的资源分配来提高生产率。

参数估算的适用性

• 参数估算方法需要大量历史数据作为支撑，而且数学模型的建立要使用特定的分析技术（如回归分析），因此具有较强的学术性，在许多实际软件项目中的可操作性并不好。

• 所以很多项目管理者更倾向于选择更为简单实用的成本估算方法，比如后面将介绍的“分解-累计”方法。

专家估算法

• 由多位对应用领域和开发环境有丰富经验的专家进行成本估算。

• 专家是指具有专门知识和经验，或经过专业培训的团体或个人。

• 为避免单个专家产生偏见，尽量由多位专家进行估算，取得多个估算值，最后得出综合的估算值。

专家估算法-Delphi

• 组织者发给每位专家一份软件系统的规格说明和一张记录估算值的表格，请他们估算。

• 专家详细研究软件规格说明后，对该软件提出3个工作量（或成本）的估算值：

1. 最小值ai
2. 最可能值mi
3. 最大值bi

• 组织者对专家的表格中的答复进行整理，计算每位专家的平均估算值Ei=(ai+4mi + bi)/6和总的平均值E=(E1 +E2+…+En)/n  (n表示n个专家)。

• 组织专家无记名填表格，比较估算差，并查找原因。

• 如果各个专家的估算差异超出规定的范围（例如：15%），则需重复上述过程 ，最终可以获得一个多数专家共识的软件工作量（或成本）估计值。

专家估算法举例

• 某管理信息系统-专家估算

1. 专家1：1，8，9         （1+9+4*8）/6=7（万元）
2. 专家2：4，6，8     （4+8+4*6）/6=6（万元）
3. 估算结果=（6+7）/2=6.5（万元）

“分解-累计”估算方法

• 该方法简单、直观。

• 首先估算产品规模。步骤如下：

• （1）项目规划小组先分解产品的功能，制定“产品功能分解与规模估算表”。软件规模的度量单位可以使用代码行，也可以使用对象数、页面数等。

产品功能分解与规模估算表：

• （2）项目规划小组成员独立填写产品功能分解与规模估算表。

• （3）汇总每个成员的表格，进行对比分析。如果各人估计的差额小于20%，则取平均值，如果差额大于20%，则转向第（2）步，让各成员重新估计产品的规模，直到各个成员估计的差额小于20%为止。

• 有了项目规模后，就可以估算项目工作量，步骤与产品规模估算相同。

• 先估算开发工作量，再估算管理工作量，填写下表所示的工作量估算表。

工作量估算表：

• 有了工作量估算值后，就可以计算项目的人力成本了，计算公式如下：

  项目人力成本 = 项目工作量×平均人力资源单价×成本系数

• 平均人力资源单价可由人员的工资确定。

• 之所以要乘以成本系数，是因为人力资源的成本要高于工资，企业除了要为人员支付工资外，还要支付各种保险金、福利、资源消耗等。对软件企业来说，成本系数大约是1.5至2.0。

5.3.3 一种实用的软件成本估算过程

该过程步骤如下：
1.对项目进行任务分解:1,2,…,i,…,n
2.估算每个任务的成本Ci
3.项目的开发成本=C1+C2+……+Ci+……+Cn
4.项目总估算成本= 直接成本+间接成本
5.项目总报价=项目总估算成本+风险利润

估算每个任务的成本

• 先估计任务的工作量Ei （一般以人月为单位）。

• 然后估算任务成本Ci= Ei*人力成本参数。

直接成本估算

• 直接成本的构成：开发成本、管理成本、质量成本

• 管理和质量成本的简易估算法：

1. 开发工作量：Effort(Dev)     
2. 管理和质量工作量：Effort(Mgn)=a*Effort(Dev)

   a为比例系数，可根据企业的具体情况而定，例如20%--25%。

• 直接成本= Effort(Dev) + a*Effort(Dev)

间接成本估算

• 根据企业具体的成本模型进行计算。

• 简易估算方法：

1. 间接成本=直接成本*间接成本系数
2. 间接成本系数根据企业的具体情况而定，例如取0.3。

项目总估算成本

• 总估算成本=直接成本+间接成本

                     =直接成本+直接成本*间接成本系数
                     =直接成本(1+间接成本系数)
                     =工作量*人力成本参数*（1+间接成本系数）

• 成本系数=人力成本参数*（1+间接成本系数）

• 总估算成本=工作量*成本系数

  例如：某项目的工作量是40人月，成本系数为2万元/人月，则项目的总估算成本为40*2=80万元。

项目总报价

• 风险利润包括风险基金、项目税费和税后利润等。

• 风险利润=项目总估算成本*a%

  a是利润系数，根据企业、项目的不同而不同。

• 项目总报价=项目总估算成本+项目总估算成本*a%

            =项目总估算成本（1+a%）

5.3.4 成本估算的准确度

估算不准确的原因

• 基础数据不足

• 估算对需求的敏感性

• 软件项目存在许多变更和不确定因素

• 缺乏有经验的估算人员

• 签约前后的不连贯

避免低劣的估算

• 留出估算的时间，并做好计划

• 注意积累项目数据，以开发人员提供的经验数据为基础进行估算

• 分类法估算

• 进行详细的较低层次上的估算

• 使用估算工具

• 使用几种不同估算技术，并比较它们的结果

估算的表达方式

• 加减限定表示

    6个人月的工作量可表示为6+3、6-1人月。

• 范围表示

    6个人月的工作量可表示为5~9人月。

• 风险量化

5.4 成本预算

• 成本预算是将批准的项目总成本估算按照进度分配到项目各项具体工作中，进而确定成本基准。

• 成本基准是按时间段分配的预算，用于与实际成本支出结果进行比较，从而对成本实施情况进行监控。

• 所以成本预算又称为制定成本计划。

• 成本预算的依据之一是项目进度计划。项目进度计划包括项目活动、里程碑和工作包的计划开始和完成时间，可根据这些信息，把计划成本分配到相应的日历时段中。

• 成本基准的表示方式有两种。第一种是根据单位时间（例如每个月）内完成的工作量或投入的人力、物力和财力，计算单位时间的成本，然后以立方图的形式绘制出来。

• 第二种是计算时间t的累计成本，然后绘制成时间-成本累计曲线。

用直方图表示的按月编制的成本基准

用时间-成本累计曲线表示的成本基准

降低项目成本预算的方法

• 降低资源的费率

• 减少任务的工时

• 减少加班

• 替换资源

• 删除任务
• 降低资源的费率

           降低人力资源的费率往往会打击工作人员的积极性，但可以通过降低其他资源的费率来实现，比如降低能源消耗、设备费用、耗材费用等。

• 减少任务的工时

           使任务高效率地执行，避免浪费时间，从而适当减少任务的工时，可以降低任务的费用。

• 减少加班

           加班需要支付加班费率，这通常要高于正常情况下的人力资源费率，所以减少加班可以有效的减少项目成本。

• 替换资源

          用廉价的资源替换比较高价的资源，但有一个前提，那就是替换的资源同样能胜任这项任务。

• 删除任务

           确认删除该任务对项目没有影响或影响在可控制范围内才可采用。

重视维护阶段的成本预算

• 加强客户对软件维护在软件应用中重要性的认识。在签订软件合同时，应增加对软件维护的成本预算。

• 软件市场中对软件维护的规范性要有一个统一科学的认识和约束，要形成规范的软件服务市场。

• 坚持有偿服务的原则。

• 加强软件开发中的软件测试、软件复用，组件化，标准化、泛性模式的运用。  

5.5 成本控制

• 成本控制是指监督项目成本的支出情况，发现实际成本和成本预算的偏差，并找出偏差的原因，以便采取纠正措施，并阻止不正确、不合理和未经批准的成本变更。

• 成本控制的依据是成本基线、项目进度计划、项目工作范围等。

项目成本控制过程

挣值分析法

• 挣值分析法(Earned Value Analysis)也称为已获取价值分析法、盈余分析法，是利用成本会计的概念对项目的进度和成本状况进行绩效评估的一种有效方法。

• 该方法依赖于被称为“已获取价值”的一种主要测量。

挣值分析法中的基本概念

• BCWS(Budgeted cost of work scheduled)，计划工作预算成本：到目前为止计划完成工作的总预算成本，它表示“到该日期为止本应该完成的工作是多少”。

• ACWP(Actual cost of work performed)，已完成工作实际成本：到目前为止已完成工作所消耗的实际成本，它表示“到该日期为止实际花了多少钱”。

• BCWP(Budgeted cost of work performed)，已完成工作预算成本，也称已获取价值(Earned Value)：到目前为止已完成工作的预算成本，它表示“到该日期为止已完成了多少工作”。

• BAC(Budgeted At Completion),工作完成的预算成本：即项目完成的预计总成本。

挣值分析的导出度量

• 成本偏差(Cost Variance, CV): CV=BCWP-ACWP

1. =0：按照预算进行
2. >0：低于预算
3. <0：超出预算

• 进度偏差(Schedule Variance, SV): SV=BCWP-BCWS
  

1. =0：按照进度进行
2. >0：进度超前
3. <0：进度落后

举例

• 项目原来预计2009年10月10日完成1000元的工作，但是到该日期时只完成了其中850元的工作，而为了完成这些工作实际花费了900元，问在2009年10月10日项目的成本偏差和进度偏差各是多少？       
  

         BCWS=1000，BCWP=850，ACWP=900
         CV=BCWP-ACWP=850-900= -50元
         SV=BCWP-BCWS=850-1000= -150元

• 成本效能指数(Cost Performance Index, CPI): CPI=BCWP/ACWP 表示成本的支出速度
  

1.  =1：按照预算进行
2. >1：低于预算
3. <1：超出预算
   

• 进度效能指数(Schedule  Performance Index, SPI): SPI=BCWP/BCWS 表示已完成工作的百分比

1.  =1：按照进度进行
2. >1：超前于进度
3. <1：落后于进度

举例

• 项目原来预计2009年10月10日完成1000元的工作，但到该日期时只完成了其中850元的工作，而为了完成这些工作实际花费了900元，问在2009年10月10日项目的成本效能指数和进度效能指数各是多少？

         BCWS=1000，BCWP=850，ACWP=900
         CPI=BCWP/ACWP=850/900= 0.94
         SPI=BCWP/BCWS=850/1000= 0.85

• 项目完成的预测成本（Estimate At Completion, EAC）：EAC = BAC/CPI

• 项目完成的成本差异（Variance At Completion, VAC）：VAC = BAC – EAC

• 项目完成的预测时间（Schedule At Completion, SAC）：SAC = 计划完成时间/SPI

挣值分析法的基本原理

• 在项目的实际执行过程中，最理想的状态是BCWP、BCWS、ACWP三条曲线紧密相靠，平稳上升，这表示项目的实际情况和期望的走势差不多，向着良好的方向发展。

• 若三条曲线偏离很大，则表示项目实施过程有重大问题隐患，或已经发生了严重问题，应对项目重新评估和安排。

怎样确定未完成工作的已获取价值

• 应用一些规则，避免对工作的进展情况主观估计所产生的问题。

1. 50/50规则：当一项工作开始时，假定已经获得一半的价值，工作完成时获得全部价值。

   使用本规则的前提是任务分解足够详细。

   例如：工作包的工作量<1人1周的工作量

     2. 0/100规则：当一项工作没有完成时，不产生任何价值，直到完成后才获得全部的价值。

     3. 其它经验加权规则，如20/80规则等。

示例

课堂练习题

• 你被指定负责一个软件项目，其中有４部分，项目总预算为53000, A任务为26000, B任务为12000, C任务为10000, D任务为5000, 截止到5月31日，A任务已经全部完成，B任务过半，C任务刚开始，D任务还没有开始。下表显示了截止到5月31日的计划成本和实际花费，采用50/50规则计算截止到5月31日的CV，SV，CPI，SPI,EAC？

练习题-答案

截止到5月31日：
BCWS = 39800元，ACWP = 35000元，
    BCWP = 37000元
CV= BCWP – ACWP =2000元
SV = BCWP – BCWS = -2800元
SPI = BCWP/BCWS = 0.93
CPI = BCWP/ACWP = 1.06
EAC = BAC/CPI = 53000/1.06 = 50000元

例题

项目的阶段计划

软件设计的细化计划

第三周的BCWP

分析结果（第三周的项目性能分析：假设实际的工作量9人天）
ACWP=9（人天）    
BCWS=7（人天）
BCWP=6.5（人天）
BAC=31（人天)
 SV=BCWP-BCWS=-0.5（人天），进度落后0.5人天工作量
SPI=BCWP/BCWS=92.8％，以计划进度的92.8%效能在工作。
CV=BCWP-ACWP=-2.5（人天），超出预算2.5人天
CPI=BCWP/ACWP=72.2%，以超预算27.8%的状态在工作
EAC=BAC/CPI=43（人天），按目前的工作性能，项目总预算为43人天。
VAC=BAC-EAC=-12（人天），超出预算12人天的工作量
SAC=10/SPI=10.8（周）按目前的进度，完工时间是10.8周
总结：这个项目将推迟0.8周（4个工作日）左右，超出预算27.8%，完成预算比较困难。
此时应仔细研究原因，然后解决问题，如果是计划做得不合理，就要修正计划。

案例分析

“软件缺陷管理和度量系统”项目成本估算

本章小结

基本概念
  理解软件项目规模、工作量、成本的概念
软件规模度量
  理解代码行和功能点及其特征
成本估算
  了解类比估算法、自下而上估算法、专家估算法，理解参数估算法、分解-累计估算法
成本预算
  掌握成本预算的目的、成本基准的表示方法，了解降低成本预算的方法
成本控制
  理解挣值分析法