请告诉我们您的知识需求以及对本站的评价与建议。
满意 不满意
Email:
在软件项目成本计算中引入估算、预算和决算体系
栏目最新
- 工程爆破行业的信息化发展现状、实施问题和建议
- BIM技术及在工程项目管理模式中的应用
- 建筑扬尘污染监控平台中的Kerberos协议改进
- 云计算安全研究参考文献
- 云计算安全研究报告(5)：云计算安全关键技术研究
- 云计算安全研究报告(4)：云计算安全技术框架建议
- 云计算安全研究报告(3)：云计算安全现状
- 云计算安全研究报告(2)：云计算安全挑战
- 云计算安全研究报告(1)：云计算发展趋势
- 大型集团型建筑企业工程管理信息化工作探索
网站最新
内容提示：软件项目的成本估算和成本控制一直是软件项目管理研究的一大难题，本文提出在软件项目成本估算中采用功能点方法，在软件项目成本预算中实施工作结构分解和COCOMO方法结合的方法，在软件项目结束后引入决算和审计机制，为软件企业建立起一个基于估算、预算和决算的知识库系统，来达到提高成本管理能力的目的。
摘要：软件项目的成本估算和成本控制一直是软件项目管理研究的一大难题，本文提出在软件项目成本估算中采用功能点方法，在软件项目成本预算中实施工作结构分解和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、缺少成本总结和分析的方法
企业完成一个项目后，没有对项目成本估算和成本管理方面进行总结，这样便无法将项目经验转化成原始数据积累，不管做了多少项目，最后对成本还是测不准。没有将项目完成后的经验对成本估算参数进行校正，也此也造成企业管理水平的无法提高。
软件项目引入估算、预算和决算的必要性
软件估算在软件项目前期进行，在需求分析完成后，便能够利用功能点模型进行软件项目成本的估算，得到项目成本估算值。对于刚刚引入该方法的企业，成本估算值是不准确的，因此需要慢慢根据经验数据对它进行修正。
在软件的详细设计完成后，便可以利用工作结构分解将对之后的所有工作进行预算，预算的费用包括直接开发费和间接费用，直接开发费用为实现程序所有功能所花费的人力和物力，而间接费用包括管理费用和其他的辅助费用，间接费用可以根据本企业的特点，在直接费用上取一定的百分比。
直接费用的计算采用COCOMO模型，由于详细设计后已经能够较准确的对软件的代码行数进行估计，因此，这个时候计算出来的预算成本也是比较准确的。当然，系数还是需要根据经验进行修正。
原文网址：http://www.pipcn.com/research/200803/9761.htm
也许您还喜欢阅读：