在软件项目成本计算中引入估算

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

在软件项目成本计算中引入估算、预算和决算体系

2008-5-27 15:50 摘要:软件项目的成本估算和成本控制一直是软件项目管理研究的一大难题,本文提出

在软件项目成本估算中采用功能点方法,在软件项目成本预算中实施工作结构分解和COCOMO方法结合的方法,在软件项目结束后引入决算和审计机制,为软件企业建立起一个基于估算、预算和决算的知识库系统,来达到提高成本管理能力的目的。

关键字:软件成本估算,功能点,WBS, COCOMO,估算,预算,决算

引言

软件成本超支是软件项目中经常遇到的问题。很多软件项目经理都曾经历过这样的情况,

由于开发成本的超支,软件项目做完之后,不仅不能得到上级领导的表扬,甚至连项目奖金

都拿不到,而这一切都来源于当初对项目成本估算的不准。

随着软件开发技术的发展,软件成本在计算机系统总成本中影响越来越大,它直接影响到投资者的决策和软件项目的开发。没有合理而准确的软件成本估算,就无法很好地进行软件项目的管理。

据国际数据公司的研究报告显示,全球500强企业中,信息技术投资超过生产设备投

资的企业达65%.然而软件项目的开发情况却不容乐观,1995年,美国大概只有10%的软件

项目可以按时交付,而且费用也不超支,约30%的项目没有完成就被取消了。

项目超支的原因是多方面的,其中一个主要原因是由于软件开发过程中,成本控制工作

没有做好,没有对资源配置进行优化,因此造成了成本浪费。而更多的原因则来自对软件项

目成本的错误估算,用一个不可能的成本来实现一个比预算昂对得多的软件,不管如何控制

都将无法避免成本超支的噩运。

常用软件成本估算模型介绍在软件成本估算领域,有很多的估算模型,这些模型经过了

几十年的发展,其中部分模型成为了目前软件成本估算的常用模型,如功能点、DEL PH、SDC 和COCO MO等。其中以功能点和COCOMO模型应用最广。

功能点估算模型

功能点方法的本质是站在客户的角度度量系统,它认为系统的功能可以分为以下5类: 内部逻辑文件、外部接口文件、外部输入、外部输出和外部查询。根据计算规则首先确定每

个功能的分类及其功能复杂度,从而可以得到每个功能的权值,全部功能的权值相加就得到

“未调整的功能点数”。

功能点方法可以在早期度量软件的规模,软件的规模与它的工作量、进度和成本关系紧

密,早期准确的软件规模度量有助于确定软件价格和提高策划过程中估算的能力。

软件项目管理过程从项目计划开始,估算是项目计划的第1个活动。估算时需要考虑很

多因素,其中最重要的就是要交付软件的规模。在软件开发生命周期的早期阶段,与用代码

行表示软件规模相比,用功能点表示软件规模作为估算的输入要准确得多,

Kemerer 的研究 显示,采用功能点进行估算的误差是

85%,而采用代码行估算的误差是 601%. 由于软件项目都是从需求分析开始, 需求分析的主要目的就是确定用户的需求,

也即系 统要实现的功能,因此功能点方法能够在需求分析阶段引入,如果有比较丰富的经验积累, 则可以进行准确度很高的成本估算。

coco MO 模型

COCOMO (Constructive Cost Model )是Boehm 利用加利福尼亚的一个咨询公司的大量 项目数据推导出的一个成本模型。该模型于 1981年首次发 项目管理者联盟文章,深入探 讨。

为适应软件工程领域的快速变化, COCOMO 经过多次的更新,如 1987年的Ada 版本,

1994年发展演变为COCOMOil 模型。

COCO MO 模型按详细程度可划分为三级,

即基本COCOMO 模型,中间COCOMO 模型和 详细COCOMO 模型。

(1)基本COCOMO 模型。它是静态、单变量模型,不考虑任何成本驱动,仅以规模为 基准进行估算只适于粗略迅速估算。

(2)中间COCO MO 模型。它是用15个成本驱动改进基本模型,这是对产品、硬件、 工作人员、项目的特性等因素的主观评估。

成本驱动的影响定为项目级的, 在考虑任何进度 限制时进一步调整工作量。

(3)详细COCOMO 模型。这是三种模型中最精确的模型。它是基于不同的成本驱动对

项目的分段有不同的影响, 是用于考虑成本驱动的阶段性影响时进一步改进估算,

这时的计 算细化到子系统/模块。它假定层次有三级:系统含有子系统,

在COCOMO 模型中,首先需要确定的是待开发软件的 模型要

进行准确的成本估算需要等到详细设计阶段结束后, 根据详细设计

的结果对每个模块和类的代码数量根据代码功能的复杂程度进行较准

确的估 算。 程序结构分解和工作结构分解

结构化分析和设计遵从自顶向下, 逐层分解的设计原则。设计师在把握的大的框架之后, 在此基础上进行逐步细化,最后才能完成一个复杂系统的设计工作。

在结构化设计方法中, 先根据用户的需求规格说明书,

确定系统的边界,绘制顶层数据 流图,然后对顶层图中的加工进行细化,

一层一层的细化下去, 一直到得到系统的所有基本

功能。 子系统含有模块。 KLO (千行代码),因此COCOMO 因为只有详细设计完成后,才能

面向对象的设计虽然与结构化设计有了很大的区别, 但是对对象的设计过程同样是一个

细化的过程。在确定了对象后,需将其抽象成类,并要对类的属性,方法进行设计,这也是 一个分解的过程。

程序结构分解是软件实现上的分解, 在软件项目中,还需要对整个软件项目划分若干任 务,并将这些任务分配给项目组中的所有成员。 任务分解及分配的好坏也对项目的进度和成 本有着很大的影响。

项目的工作结构分解即 WBS 是先把项目中实际需要完成的事项尽量分解成更具体的工 作。具体做法是按照树形结构先把整个项目分解为大的单元,

再把各个大的单元分解为个小

的单元。 需完成事项的细分之后,把各个单元中需要做的工作

分配在树形结构的最下层。 元中所需要做的一系列的工作

被称为工作包。在 项目实行的结构图就完成了。 工作结构分解是进行项目成本计算的基础,

如果工作分配不恰当,如将简单任务分配给程序开发高

手, 造成工作效率低下, 并增加项目的成本。 真实的

软件项目成本不仅是软件的复杂度, 本项目的管理和人员

能力有着直接的关系。 1、套用现成估算模型,误差太大。

每个软件企业的情况都不同, 有着不同的管理模式, 不同的工作人员,不同的环境和背 景,因此如果简单的进行估算模型的套用, 使用别人的计算系数的话,得到的将是别人企业 的成本,而不是自己的成本。这样,当项目完成后,成本自然与估算数据相差很大。

不管是功能点模型还是 COCOMO 模型都是需要本企业的计算系数,如果提供不了正确 的计算系数,则这两个模型都无法正确使用, 因此每个软件企业都要对估算模型进行一定的 适应性调整,以适应自己企业的情况。

2、缺少成本管理体系

很多软件企业都将成本估算用于项目投标使用, 管理体系。如果不对软件的成本进行有效的管理, 本可能大幅度的

超过估算。 这是因为没有对项目的成本进行管理, 理搭配和

利用资源, 以至于造成了资源的浪费,

这样项目的成本自然增加,

算估不准了。 3、缺少成本总结和分析的方法

企业完成一个项目后, 没有对项目成本估算和成本管理方面进行总结, 目经验转

化成原始数据积累, 不管做了多少项目, 最后对成本还是测不准。 后的经验对成本估各个单 WBS 的各个工作包里配置工作人员之后,

不同的工作结构分解将得到不同的项目成本, 而将复杂任务分配给新手,将会 并且与

而没有意识到需要为企业建立一个成本 即使估算得很准确, 最后项目结束后,成 在项目建设过程中没有合 也就造成成本估

这样便无法将项 没有将项目完成

相关文档
最新文档