软件开发成本估算.doc

1、软件开发成本估算 那些你应该知道的 2011-04-24 15:12:24 阅读 14 评论 0 字号：大中小 订阅 软件开发成本估算 软件开发成本估算主要指软件开发过程中所花费的工作量及相应的代价。 不同与传统的工业产品，软件 的成本不包括原材料和能源的消耗，主要是人的劳动的消耗。另外，软件也没有一个明显的制造过程，它 的开发成本是以一次性开发过 程所花费的代价来计算的。因此，软件开发成本的估算，应是从软件计划、 需求分析、设计、编码、单元测试、集成测试到认证测试，整个开发过程所花费的代价作 为依据的。 软件开发成本估算的经验模型 Putnam 模型 1978 年 Putnam 提出的，一种

2、动态多变量模型。 L = Ck * K1/3 * td4/3 其中： L-源代码行数( 以 LOC 计)项目管理论坛 K-整个开发过程所花费的工作量（以人年计） td-开发持续时间（以年计） Ck-技术状态常数，它反映“妨碍开发进展的限制”，取值因开发环境而异，见下表 Ck 的典型值 开发环境 开发环境举例 2000 差 没有系统的开发方法，缺乏文档和复审 8000 好 有合适的系统的开发方法，有充分的文档和复审 11000 优 有自动的开发工具和技术 从上述方程加以变换，可以得到估算工作量的公式： K = L3/(Ck3*td4) 还可以估算开发时间： td = L3/(Ck3*K)1/4

3、COCOMO 模型(constructive cost model) 这是由 TRW 公司开发，Boehm 提出的结构化成本估算模型。是一种精确的、易于使用的成本估算方法。 COCOMO 模型中用到以下变量： DSI-源指令条数。不包括注释。1KDSI = 1000DSI。 MM-开发工作量（以人月计） 1MM = 19 人日 = 152 人时 =1/12 人年 TDEV-开发进度。 (以月计) COCOMO 模型中，考虑开发环境，软件开发项目的类型可以分为 3 种： 组织型(organic): 相对较小、较简单的软件项目。开发人员对开发目标理解比较充分，与软件系统相关 的工作经验丰富，对软件

4、的使用环境很熟悉，受硬件的约束较小，程序的规模不是很大（50000 行） 嵌入型(embedded): 要求在紧密联系的硬件、软件和操作的限制条件下运行，通常与某种复杂的硬件设 备紧密结合在一起。对接口，数据结构，算法的要求高。软件规模任意。如大而复杂的事务处理系统，大 型/超大型操作系统，航天用控制系统，大型指挥系统等。 半独立型（semidetached）： 介于上述两种软件之间。规模和复杂度都属于中等或更高。最大可达 30 万行。 估算公式： 基本 COCOMO 模型估算工作量和进度的公式如下 工作量： MM = r*(KDSI)c 进度： TDKV = a(MM)b 其中经验常数 r,

5、 c, a, b 取决于项目的总体类型。 COCOMO 模型按其详细程度可以分为三级：基本 COCOMO 模型，中间 COCOMO 模型，详细 COCOMO 模型。其中基本 COCOMO 模型是是一个静态单变量模型，它用一个以已估算出来的原代码行 数(LOC) 为自变量的经验函数计算软件开发工作 量。 中级 COCOMO 模型在基本 COCOMO 模型的基 础上，再用涉及产品、硬件、人员、项目等方面的影响因素调整工作量的估算。详细 COCOMO 模型包括 中间 COCOMO 模型的所有特性，但更进一步考虑了软件工程中每一步骤（如分析、设计）的影响。 基本 COCOMO模型 通过统计 63 个历

6、史项目的历史数据，得到如下计算公式。 总体类型 工作量 进度 组织型 MM = 10.4*(KDSI)1.05 TDKV = 10.5(MM)0.38 半独立型 MM = 3.0*(KDSI)1.12 TDKV = 10.5(MM)0.35 嵌入型 MM = 3.0*(KDSI)1.20 TDKV = 10.5(MM)0.32 进度计划是从时间的角度对项目进行规划，而成本估算则是从费用的角度对项目进行规划。这里的费 用应理解为一个抽象概念，它可以是工时、材料或人员等。 成本估算是对完成项目所需费用的估计和计划，是项目计划中的一个重要组成部分。要实行成本控制， 首先要进行成本估算。理想的是，完成

7、某项任务所 需费用可根据历史标准估算。但对许多工业来说，由 于项目和计划变化多端，把以前的活动与现实对比几乎是不可能的。费用的信息，不管是否根据历史标准， 都只 能将其作为一种估算。而且，在费时较长的大型项目中，还应考虑到今后几年的职工工资结构是否 会发生变化，今后几年原材料费用的上涨如何，经营基础以及管理 费用在整个项目寿命周期内会不会变 化等问题。所以，成本估算显然是在一个无法以高度可靠性预计的环境下进行。在项目管理过程中，为了 使时间、费用和工作范 围内的资源得到最佳利用，人们开发出了不少成本估算方法，以尽量得到较好的 估算。这里简要介绍以下几种。 1经验估算法 进行估计的人应有专门知识

8、和丰富的经验，据此提出一个近似的数字。这种方法是一种最原始的方法， 还称不上估算，只是一种近似的猜测。它对要求很快拿出一个大概数字的项目是可以的，但对要求详细的 估算显然是不能满足要求的。 2因素估算法 这是比较科学的一种传统估算方法。它以过去为根据来预测未来，并利用数学知识。它的基本方法是 利用规模和成本图。如图所示，图上的线表示规模和 成本的关系，图上的点是根据过去类似项目的资料 而描绘，根据这些点描绘出的线体现了规模和成本之间的基本关系。这里画的是直线，但也有可能是曲线。 成本包 括不同的组成部分，如材料、人工和运费等。这些都可以有不同的曲线。项目规模知道以后，就 可以利用这些线找出成本

9、各个不同组成部分的近似数字。 这里要注意的是，找这些点要有一个“基准年度”，目的是消除通货膨胀的影响。画在图上的点应该是 经过调整的数字。例如以 1980 年为基准年，其 他年份的数字都以 1980 年为准进行调整，然后才能描 点划线。项目规模确定之后，从线上找出相应的点，但这个点是以 1980 年为基准的数字，还需要再调整 到当年，才是估算出的成本数字。此外，如果项目周期较长，还应考虑到今后几年可能发生的通货膨胀、 材料涨价等因素。 做这种成本估算，前提是有过去类似项目的资料，而且这些资料应在同一基础上，具有可比性。 3WBS 基础上的全面详细估算（ WBS：工作分解结构（Work Brea

10、kdown Structure） ） 即利用 WBS 方法，先把项目任务进行合理的细分，分到可以确认的程度，如某种材料，某种设备， 某一活动单元等。然后估算每个 WBS 要素的费用。采用这一方法的前提条件或先决步骤是： 对项目需求作出一个完整的限定。 制定完成任务所必需的逻辑步骤。 编制 WBS 表。 项目需求的完整限定应包括工作报告书、规格书以及总进度表。工作报告书是指实施项目所需的各项 工作的叙述性说明，它应确认必须达到的目标。如果 有资金等限制，该信息也应包括在内。规格书是对 工时、设备以及材料标价的根据。它应该能使项目人员和用户了解工时、设备以及材料估价的依据。总进 度表应明 确项目实

11、施的主要阶段和分界点，其中应包括长期定货、原型试验、设计评审会议以及其他任 何关键的决策点。如果可能，用来指导成本估算的总进度表应含有项目 开始和结束的日历时间。 一旦项目需求被勾划出来，就应制定完成任务所必需的逻辑步骤。在现代大型复杂项目中，通常是用 箭头图来表明项目任务的逻辑程序，并以此作为下一步绘制 CPM 或 PERT 图以及 WBS 表的根据。 编制 WBS 表的最简单方法是依据箭头图。把箭头图上的每一项活动当作一项工作任务，在此基础上 再描绘分工作任务。 进度表和 WBS 表完成之后，就可以进行成本估算了。在大型项目中，成本估算的结果最后应以下述 的报告形式表述出来： 对每个 WB

12、S 要素的详细费用估算。还应有一个各项分工作、分任务的费用汇总表，以及项目和整 个计划的累积报表。 每个部门的计划工时曲线。如果部门工时曲线含有“峰”和“ 谷” ，应考虑对进度表作若干改变，以得 到工时的均衡性。 逐月的工时费用总结。以便项目费用必须削减时，项目负责人能够利用此表和工时曲线作权衡性研 究。 逐年费用分配表。此表以 WBS 要素来划分，表明每年（或每季度）所需费用。此表实质上是每项 活动的项目现金流量的总结。 原料及支出预测，它表明供货商的供货时间、支付方式、承担义务以及支付原料的现金流量等。 采用这种方法估算成本需要进行大量的计算，工作量较大，所以只计算本身也需要花费一定的时间

13、和 费用。但这种方法的准确度较高，用这种方法作出的 这些报表不仅仅是成本估算的表述，还可以用来作 为项目控制的依据。最高管理层则可以用这些报表来选择和批准项目，评定项目的优先性。 以上介绍了 三种成本估算的方法。除此之外，在实践中还可将几种方法结合起来使用。例如，对项目的主要部分进行 详细估算，其他部分则按过去的经验或用因素估 算法进行估算。 FunctionPoing 的目的是基于软件需求产生软件规模的估计。功能点是基于应用软件的外部、内部特性 以及软件性能的，一种间接的软件规模的 测量。功能点与软件成本具有重大的成本估计关系（ CER ：Cost EstimatingRelationship ）。功能点可以作为经验统计参数化软件成本估计公式和模型的输入， 以对软件的成本进行估计。功能点方法被广泛的认可在信息系统、数据库密集型、4GL 应用系统开发的 规模测量。 加一本书的介绍用例点估算方法 .人们设想，基于用例模型来估算规模和工作量是可能的。因为用例模型被广泛用于捕捉功能需求，所以 人们认为，应该有基于用例的估算方法来代替功能点方法。然而，有几点困难可能阻碍基于用例的估算方 法的应用(Smith,1999) ：