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

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

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

2008-5-27 15:50 摘要:软件项目的成本估算和成本控制一直是软件项目管理研究的一大难题,本文提出在软件项目成本估算中采用功能点方法,在软件项目成本预算中实施工作结构分解和COCOMO方法结合的方法,在软件项目结束后引入决算和审计机制,为软件企业建立起一个基于估算、预算和决算的知识库系统,来达到提高成本管理能力的目的。

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

引言

软件成本超支是软件项目中经常遇到的问题。很多软件项目经理都曾经历过这样的情况,由于开发成本的超支,软件项目做完之后,不仅不能得到上级领导的表扬,甚至连项目奖金都拿不到,而这一切都来源于当初对项目成本估算的不准。

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

据国际数据公司的研究报告显示,全球500 强企业中,信息技术投资超过生产设备投资的企业达65%.然而软件项目的开发情况却不容乐观,1995 年,美国大概只有10%的软件项目可以按时交付,而且费用也不超支,约30%的项目没有完成就被取消了。

项目超支的原因是多方面的,其中一个主要原因是由于软件开发过程中,成本控制工作没有做好,没有对资源配置进行优化,因此造成了成本浪费。而更多的原因则来自对软件项目成本的错误估算,用一个不可能的成本来实现一个比预算昂对得多的软件,不管如何控制都将无法避免成本超支的噩运。

常用软件成本估算模型介绍在软件成本估算领域,有很多的估算模型,这些模型经过了几十年的发展,其中部分模型成为了目前软件成本估算的常用模型,如功能点、DELPHI、SDC 和COCOMO等。其中以功能点和COCOMO模型应用最广。

功能点估算模型

功能点方法的本质是站在客户的角度度量系统,它认为系统的功能可以分为以下5 类:内部逻辑文件、外部接口文件、外部输入、外部输出和外部查询。根据计算规则首先确定每个功能的分类及其功能复杂度,从而可以得到每个功能的权值,全部功能的权值相加就得到“未调整的功能点数”。

功能点方法可以在早期度量软件的规模,软件的规模与它的工作量、进度和成本关系紧密,早期准确的软件规模度量有助于确定软件价格和提高策划过程中估算的能力。

软件项目管理过程从项目计划开始,估算是项目计划的第1个活动。估算时需要考虑很多因素,其中最重要的就是要交付软件的规模。在软件开发生命周期的早期阶段,与用代码

行表示软件规模相比,用功能点表示软件规模作为估算的输入要准确得多,Kemerer的研究显示,采用功能点进行估算的误差是85%,而采用代码行估算的误差是601%.

由于软件项目都是从需求分析开始,需求分析的主要目的就是确定用户的需求,也即系统要实现的功能,因此功能点方法能够在需求分析阶段引入,如果有比较丰富的经验积累,则可以进行准确度很高的成本估算。

COCOMO模型

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

为适应软件工程领域的快速变化,COCOMO经过多次的更新,如1987年的Ada版本,1994年发展演变为COCOMOII模型。

COCOMO模型按详细程度可划分为三级,即基本COCOMO模型,中间COCOMO模型和详细COCOMO模型。

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

(2)中间COCOMO模型。它是用15个成本驱动改进基本模型,这是对产品、硬件、工作人员、项目的特性等因素的主观评估。成本驱动的影响定为项目级的,在考虑任何进度限制时进一步调整工作量。

(3)详细COCOMO模型。这是三种模型中最精确的模型。它是基于不同的成本驱动对项目的分段有不同的影响,是用于考虑成本驱动的阶段性影响时进一步改进估算,这时的计算细化到子系统/模块。它假定层次有三级:系统含有子系统,子系统含有模块。

在COCOMO模型中,首先需要确定的是待开发软件的KLOC(千行代码),因此COCOMO 模型要进行准确的成本估算需要等到详细设计阶段结束后,因为只有详细设计完成后,才能根据详细设计的结果对每个模块和类的代码数量根据代码功能的复杂程度进行较准确的估算。

程序结构分解和工作结构分解

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

在结构化设计方法中,先根据用户的需求规格说明书,确定系统的边界,绘制顶层数据流图,然后对顶层图中的加工进行细化,一层一层的细化下去,一直到得到系统的所有基本功能。

面向对象的设计虽然与结构化设计有了很大的区别,但是对对象的设计过程同样是一个细化的过程。在确定了对象后,需将其抽象成类,并要对类的属性,方法进行设计,这也是一个分解的过程。

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

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

需完成事项的细分之后,把各个单元中需要做的工作分配在树形结构的最下层。各个单元中所需要做的一系列的工作被称为工作包。在WBS的各个工作包里配置工作人员之后,项目实行的结构图就完成了。

工作结构分解是进行项目成本计算的基础,不同的工作结构分解将得到不同的项目成本,如果工作分配不恰当,如将简单任务分配给程序开发高手,而将复杂任务分配给新手,将会造成工作效率低下,并增加项目的成本。真实的软件项目成本不仅是软件的复杂度,并且与本项目的管理和人员能力有着直接的关系。

1、套用现成估算模型,误差太大。

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

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

2、缺少成本管理体系

很多软件企业都将成本估算用于项目投标使用,而没有意识到需要为企业建立一个成本管理体系。如果不对软件的成本进行有效的管理,即使估算得很准确,最后项目结束后,成本可能大幅度的超过估算。这是因为没有对项目的成本进行管理,在项目建设过程中没有合理搭配和利用资源,以至于造成了资源的浪费,这样项目的成本自然增加,也就造成成本估算估不准了。

3、缺少成本总结和分析的方法

企业完成一个项目后,没有对项目成本估算和成本管理方面进行总结,这样便无法将项目经验转化成原始数据积累,不管做了多少项目,最后对成本还是测不准。没有将项目完成后的经验对成本估算参数进行校正,也此也造成企业管理水平的无法提高。

相关文档
最新文档