软件开发成本估算
软件开发成本估算主要指软件开发过程中所花费的工作量及相应的代价。 不同与传统的工业产品，软件的成本不包括原材料和能源的消耗，主要是人的劳动的消耗。另外，软件也没有一个明显的制造过程，它的开发成本是以一次性开发过程所花费的代价来计算的。因此，软件开发成本的估算，应是从软件计划、需求分析、设计、编码、单元测试、集成测试到认证测试，整个开发过程所花费的代价作为依据的。
软件开发成本估算的经验模型 1. Putnam 模型
1978年Putnam提出的，一种动态多变量模型。 L = Ck * K * td4/3
其中： L-----------源代码行数(以LOC计)
K-----------整个开发过程所花费的工作量（以人年计） td-----------开发持续时间（以年计）
Ck----------技术状态常数，它反映“妨碍开发进展的限制”，取值因开发环
1/3
1
境而异，见下表
Ck的典型值 开发环境 开发环境举例 2000 8000 11000 差 好 优 没有系统的开发方法，缺乏文档和复审 有合适的系统的开发方法，有充分的文档和复审 有自动的开发工具和技术 从上述方程加以变换，可以得到估算工作量的公式： K = L3/(Ck3*td4) 还可以估算开发时间： td = [L3/(Ck3*K)]1/4 2. COCOMO模型(constructive cost model)
这是由TRW公司开发，Boehm提出的结构化成本估算模型。是一种精确的、易于使用的成本估算方法。
COCOMO模型中用到以下变量：
DSI-------源指令条数。不包括注释。1KDSI = 1000DSI。
MM-------开发工作量（以人月计） 1MM = 19 人日 = 152 人时 =1/12 人年 TDEV-----开发进度。(以月计)
2
COCOMO模型中，考虑开发环境，软件开发项目的类型可以分为3种：
1. 组织型(organic): 相对较小、较简单的软件项目。开发人员对开发目标理解比较充分，与软件系统相关的工作经验丰富，对软件的使用环境很熟悉，受硬件的约束较小，程序的规模不是很大（<50000行）
2. 嵌入型(embedded): 要求在紧密联系的硬件、软件和操作的限制条件下运行，通常与某种复杂的硬件设备紧密结合在一起。对接口，数据结构，算法的要求高。软件规模任意。如大而复杂的事务处理系统，大型/超大型操作系统，航天用控制系统，大型指挥系统等。
3. 半独立型（semidetached）： 介于上述两种软件之间。规模和复杂度都属于中等或更高。最大可达30万行。 估算公式：
基本COCOMO模型估算工作量和进度的公式如下 工作量： MM = r*(KDSI)c 进度： TDKV = a(MM)b
其中经验常数 r, c, a, b 取决于项目的总体类型。
COCOMO模型按其详细程度可以分为三级：基本COCOMO模型，中间COCOMO模型，详
3
细COCOMO模型。其中基本COCOMO模型是是一个静态单变量模型，它用一个以已估算出来的原代码行数(LOC)为自变量的经验函数计算软件开发工作量。 中级COCOMO模型在基本COCOMO模型的基础上，再用涉及产品、硬件、人员、项目等方面的影响因素调整工作量的估算。详细COCOMO模型包括中间COCOMO模型的所有特性，但更进一步考虑了软件工程中每一步骤（如分析、设计）的影响。 基本COCOMO模型
通过统计63个历史项目的历史数据，得到如下计算公式。
总体类型 组织型 半独立型 嵌入型 工作量 MM = 10.4*(KDSI)1.05 MM = 3.0*(KDSI)1.12 MM = 3.0*(KDSI)1.20 进度 TDKV = 10.5(MM)0.38 TDKV = 10.5(MM)0.35 TDKV = 10.5(MM)0.32
最近在温习软件工程的课程,对软件项目成本估算模型有了些认识,以下是我的一些心得,希望与大家分享.
首先我们需要明确的是为什么要做软件项目预算.首先软件项目是不同于一般工程项目的项目类型.受用户需求,开发方式的影响很大.没有明确的预算,会导致软件开支的不可控制,随着项目的进行,开发放要承担的风险也会增加.另外如果没有预算,更不可能与客户达成开发协议.没有人会傻到委托别人做一个自己都不知道要花多少钱
4
才能完成的项目.最后也就是我个人对项目预算的看法,好的项目预算应该包括团体预算与小组或个人预算两部分,好的项目经理应该了解自己的团队,对突发事件等的考虑应该放在项目预算之中,然后将项目的开支细化到小组乃至个人,这一点看似多余,但是却很有必要.比如在实际的开发过程中,由于为了缩短工期而招收新的程序员,这就需要对新程序员进行培训.新程序员消耗的团队成本是要考虑在内的.这也就是传统意义上的peron-monthes所不能完全表达的部分. 新增人员的开支是不能被忽略的.这需要在实际开发过程中统计得到数据,来精确计算. 项目策划任务集: 1.明确项目范围 2.确定可行性 3.分析风险 4.确定需要的资源 a.确定需要的人力资源 b.确定可复用的软件资源 c.标识环境资源 5.估算成本和工作量 a.分解问题
b.使用规模,功能点,过程任务或用例等方法进行两种以上的估算
c.调和不同的估算
5
6.制定项目进度计划
a.建立一组有意义的任务集合 b.定义任务网络
c.使用进度计划工具制定时间表 d.定义进度跟踪机制
在项目策划任务集中,每一步都涉及到软件开发成本.对人员,环境,可复用软件的资源的统一调度,将直接影响成本.其中受软件开发的特殊行,人力资源成本是最不好控制的.相对来说环境资源就容易控制得多.
环境资源包括软件工具,硬件,网络资源等,当然还要包括公司的日常费用(刨除开发团队佣金与开支,因为这部分属于人力资源成本).这些无非是买来或者维持,成本是很容易计算的.
可复用软件资源就要考虑到软件的具体设计,功能模块的关系以及系统架构等具体信息.专家建议是将软件资源分为如下四部分: 1.成品构件:指能够从第三方直接购买的商品构件.或者以前项目中完全相同的构件.
2.具有完全经验的构件:以前项目开发过的,与当前需求相似的功能构件.
3.具有部分经验的构件:为以前项目开发,与当前项目要构造的软件有关的已有规格,设计,代码或测试数据.但是需要从新架构. 4.新构件
开发的成本可像而知,是升序排列的.所以在软件开发的一开始就
6
应该考虑的使用以后技术,对可复用软件资源进行整理,不能在开发过程中才考虑,要知道一个关键构件的重用会为软件开发带来多大的效益.不过凡事也不是必然,不已有构件的扩展要考虑到原构件设计,开发文档的完整性等因素.
还是就人力资源进行分析,由于跟人能力与技术方向的不同,programmer不可能像一般意义上的工人或者机器一样有效地预期成本.我们可以开发一个原型,利用原型数据来对应分析每个人的价值与成本.但是应该考虑的是,随着程序员的个人因素的变更(年龄,职务,时间,身体状况等),原型数据只能作为一个一般参考.例如SARS期间,或流行性感冒的传播,人力成本就会变得不好控制.(极限情况下,这将使一个项目面临流产~)
目前流行的估算模式大致可分为如下几类: 分解估算:
1.软件规模估算. 2.基于问题的估算.
3.基于loc估算.(loc:代码行数)
4.基于fp估算.(fp:functionpoint 功能点) 5.基于过程估算. 6.基于用例估算. ...... 经验估算:
典型的经验估算模型是通过回归分析从以往的软件项目中收集
7
的数据得来的.这种模型的总体结构表现为下面的形式: E=A+B*(e)^C
其中A,B,C都是经验常量.E是工作量(单位:人*月),e是估算变量(loc或者fp).除了公式表达的方式以外,还有一些形式的项目调整成分,如问题的复杂程度,开发人员经验,开发环境等,一下列出些常用的调整系数: Personnel Attributes
• Analyst capability
(ACAP)
(PCAP)
(AEXP)
(VEXP)
(LEXP)
• Programmer capability
• Applications experience
• Virtual machine Experience
• Programming language experience
Project Attributes
• Modern programming practices • Software Tools
(MODP)
(TOOL)
(SCED)
• Required Development schedule
这些系数都应该应该根据具体的项目进行调整和设计. cocomo:(constructive cost model)
这种模型是Barry Boehm在其论述\"软件工程经济学\"中介绍
8
的一种层次结构的软件估算模型.现在已经被广泛应用.主要应用于应用组装模型,早期设计阶段模型,体系结构后阶段模型.将在以后的日志中对大家进行更深入的介绍.
目前，有三种基本的软件项目成本估算方法：自顶向下、自底向上和差别估算法。自顶向下的方法是对整个项目的总开发时间和总工作量做出估算，然后把它们按阶段、步骤和工作单元进行分配；自底向上的方法是分别估算个工作单元所需的开发时间，然后汇总得出总的工作量和开发时间；差别估算是将开发项目与一个或多个已完成的类似项目进行比较，找出与某个类似项目的若干不同之处，并估算每个不同之处对成本的影响，导出开发项目的总成本。 专家估算法
专家估算法是依靠一个或多个专家对项目做出估计，它要求专家具有专门知识和丰富的经验，是一种近似的猜测。Delphi法是最流行的专家评估技术，在没有历史数据的情况下，这种方式适用于评定过去与将来，新技术与特定程序之间的差别，但专家\"专\"的程度及对项目的理解程度是工作中的难点，尽管Delphi技术可以减轻这种偏差，专家评估技术在评定一个新软件实际成本时通常用得不多，但是，这种方式对决定其它模型的输入时特别有用。Delphi法鼓励参加者就问题相互讨论，要求有多种软件相关经验人的参与，互相说服对方。
类推估算法
类推估算法是比较科学的一种传统估算方法，它适合评估一些与历史项目在应用领域、环境和复杂度的相似的项目，通过新项目与历史项目的比较得到规模估计。类推估算法估计结果的精确度取决于历史项目数据的完整性和准确度，因此，用好类推估算法的前提条件之一是组织建立起较好的项目后评价与分析机制，对历史项目的数据分析是可信赖的。 这种方法的基本步骤是：
（1） 整理出项目功能列表和实现每个功能的代码行；
（2） 标识出每个功能列表与历史项目的相同点和不同点，特别要注意历史项目做得不够的地方；
（3） 通过步骤1和2得出各个功能的估计值； （4） 产生规模估计。 算式估算法
算式估算法利用经验模型进行成本估算，它通常采用经验公式来预测软件项目计划所需要的成本、工作量和进度数据。目前还没有一种估算模型能够适用于所有的软件类型和开发环境，从这些模型中得到的结果必须慎重使用。 （1） Putnam模型
Putnam模型是一种动态多变量模型，它是假定软件开发的整个生存期中工作量的分布，如一个30人年以上的项目，其人力使用分布如图7.3所示。 然后根据曲线导出一个估算公式：
9
（2） COCOMO模型
结构性成本模型COCOMO（COnstructive COst MOdel）是一种精确的、易于使用的成本估算方法，它分为基本COCOMO模型和中级COCOMO模型两种类型。基本COCOMO模型是一个静态单变量模型，它用一个以已估算出来的源代码行数（LOC）为自变量的经验函数来计算软件开发工作量。中间COCOMO模型则在用LOC为自变量的函数计算软件开发工作量的基础上，再用涉及产品、硬件、人员、项目等方面属性的影响因素来调整工作量的估算。更详细的COCOMO模型除了包括中间COCOMO模型的所有特性外，还考虑了在需求分析、软件设计等每一步的影响。
* 基本COCOMO模型估算公式 E＝ab（KLOC）exp（bb） D＝cb（E）exp（db）
其中，E为开发所需的人力（人月），D为所需的开发时间（月），KLOC为估计提交的代码行，ab、bb、cb和db为不同软件开发方式的值，见下表。
方式 组织型 半独立型 嵌入型 ab 2.4 3.0 3.6 bb 1.05 1.12 1.2 cb 2.5 2.5 2.5 db 0.38 0.35 0.32 由以上公式可以导出生产率和所需人数的公式： 生产率＝（KLOC）／E（代码行/人月） 人数＝E／D
* 中级COCOMO模型估算公式
中级COCOMO模型先产生一个基本COCOMO模型一样形式的估算公式，然后对15个成本驱动属性打分，定出乘法因子，对公式进行修正。 15个影响软件工作量的因素见下表：
工作量因素fi 软件可靠性 产品因素 数据库规模 产品复杂性 非常低 低 正常 高 非常高 超高 0.75 0.88 1.00 1.15 1.40 0.94 1.00 1.08 1.16 0.87 0.87 1.46 1.13 1.17 1.10 1.00 1.11 1.00 1.06 1.00 1.15 1.00 1.07 1.30 1.21 1.66 1.30 1.56 1.15 0.70 0.85 1.00 1.15 1.30 1.65 执行时间限制 计算机因存储限制 素 虚拟机易变性 环境周转时间 人的因素 分析员能力 应用论域实际经验 程序员能力 1.29 1.42 1.21 1.00 0.86 0.71 1.00 0.91 0.82 1.00 0.86 0.70 1.00 0.90 10
虚拟机使用经验 程序语言使用经验 1.41 1.07 1.00 0.95 现代程序设计技术 1.24 1.10 1.00 0.91 0.82 项目因素 软件工具的使1.24 1.10 1.00 0.91 0.83 用 1.23 1.08 1.00 1.04 1.10 开发进度限制 中级COCOMO模型的估算公式： E＝ai（KLOC）exp（bi）×乘法因子 其中ai和bi的值见下表。
方式 组织型 半独立型 嵌入型 ai 3.2 3.0 2.8 bi 1.05 1.12 1.2 （3） IBM模型
1977年，Walston和Felix总结了IBM的60个项目数据，提出了如下的估算公式：
0.91
E＝5.2×L， L是源代码行数（以KLOC计），E是工作量（以PM计） D＝4.1×L0.36＝2.4×E0.35， D是项目持续时间（以月计） S＝0.54×E0.6， S是人员需要量（以人计） DOC＝49×L1.01， DOC是文档数量（以页计）
11
因篇幅问题不能全部显示，请点此查看更多更全内容