软件项目成本估算研究

第１３４第ｌ期　２０１４年１月　软件导刊　Ｓｏｆｔｗａｒｅ　Ｇｕｉｄｅ　Ｖ＿０１．１３ＮＯ．１　Ｊａｎ．２Ｏ１４　软件项目成本估算研究　龚银锋　（宁波数字电视有限公司，浙江宁波３１５０００）　摘　要：软件项目成本估算是软件项目成本管理的基础，也是整个软件项目管理中的一个难点。对软件项目成本估　算步骤以及常用方法进行了初步探究，并着重介绍了ＩＦＰＵＧ和ＣＯＣＯＭ（）这两个参数模型的应用方法。　关键词：软件项目成本估算；软件估算；ＩＦＰＵＧ；ＣＯＣＯＭＯ　中图分类号：ＴＰ３０１　文献标识码：Ａ　文章编号：ｌ６７２—７８００（２０１４）００１—００２０—０３　将估算项目各任务单元可支配的时间，并制定里程碑计　０　弓Ｉ言　项目的成本管理，是指在规定时间内，为确保项目目　划。工作量估算和进度估算共同决定了项目团队的规模　和结构　。　标的实现，对项目实际发生的成本支出采取的各种控制措　施和控制过程。其管理活动包括：资源需求预测、成本估　算、成本预算和成本控制　。成本估算是后续成本管理活　动的前提，也是成本管理中的重点与难点。　（３）估算反馈阶段。包括对成本估算方法本身的反　馈，以及估算实践中的阶段性结果反馈　］。在初期对项目　掌握的情况较少并且仍有较多不确定性，随着项目开展可　了解到更多的信息以及既成事实后的情况。因此，通过不　断地进行阶段性估算结果反馈，有利于调整估算方法相关　数据，从而提高估算结果的精确性。　软件项目的成本估算，并非传统资金意义上的估算。　由于人的脑力劳动是软件开发的主体活动，因此软件开发　的主要投入在于支付开发人员脑力劳动的报酬。不同软　２软件成本估算方法　软件成本估算方法主要有以下４种：类比估算法、项　目分解法、专家估算法和参数模型法。　（１）类比估算法。类比估算法也称基于案例的推　理　，即从已完成的类似项目的实际成本来估算新项目的　成本。估算过程中，需确定项目之间的各项差异，并确定　件开发单位的薪资水平存在很大差别，所以从普适性考　虑，软件项目成本估算研究的主要范围是软件项目的工作　量和工作进度　］　因此，衡量软件成本的常用单位有人　天、人月、人年等形式，并且有转换系数可在不同单位间进　行换算。在估算出软件开发所需的人力成本之后，再根据　开发单位的实际情况和项目内的其它费用即可估算出相　应的成本Ⅲ。　各项修正系数，对各项数据加以运算调整。　（２）项目分解法。需要对项目进行分解，根据分解的　先后顺序不同，可分为自上而下估算法和自下而上估算　法。自上而下估算法的思想是从项目整体进行推算，将已　估算出的项目整体工作量，按比例分摊至项目的各项活动　中去。该方法比较适合在项目初期的总体设计中运用　］。　自下而上估算法与自上而下估算法正好相反，这种方法是　１软件项目成本估算阶段　软件项目的成本估算，一般需要经过以下３个阶段：　（１）规模估算阶段。规模估算是指对软件的大小进行　量化衡量，它是后续工作量估算的前提。估算软件大小有　两种基本方式：估算软件所解决问题的大小和数量，比如　将项目逐层分解成足够基本明确工作量的子任务，在测算　各子任务成本后，将它们累计起来就是整个软件项目的成　本。这种方法更适用于项目后期或分解后的子项目成本　估算。　功能点，因此也称功能规模的度量；估算解决方案的大小　即技术规模的度量，比如代码行数。一般在项目初期主要　以估算问题大小为主，随着项目的开展逐步采用以估算解　决方案大小的方式。　（２）工作量和进度估算阶段。ｒ［＿作量估算是对软件开　发所需人力的估算，这是软件项目的主要成本。进度估算　（３）专家估算法。邀请对软件应用领域或开发环境有　丰富知识的专家对该软件项目进行工作量估算，当遇到一　个与已有软件项目类似的新项目时，可邀请熟悉原软件项　作者简介：龚银锋（１９８３一），男，硕士，宁波数字电视有限公司项目经理，研究方向为软件项目管理、业务运营支撑系统。　第１期　龚银锋：软件项目成本估算研究　・２１・　目的人员作为专家。　为了避免单个专家主观因素的偏向性，该方法大都采　取邀请多个专家进行估算，并对多个估算结果进行综合。　其中由美国兰德公司（ＲＡＮＤ　Ｃｏｒｐｏｒａｔｉｏｎ）推广的Ｄｅｌｐｈｉ　法正是汇集多个专家意见的技术，其步骤大致如下　：①　组织者向各专家提供软件规格说明书和估算表格供他们　进行研究。估算表中应包括软件成本估算的最小值（ｎ　）、　最有可能值（ｍｉ）、最大值（６　）以及简要说明和填表时间；　②在专家研究软件规格说明后，组织者召集他们召开讨论　会议。会上专家可向组织者提问，组织者也可向专家介绍　类似软件的有关情况，专家之间也可展开讨论；③专家填　写估算表格，并匿名提交；④组织者对表格数据进行汇总　和分类摘要，并将结果反馈给各专家。Ｄｅｌｐｈｉ法中的估算　值汇总可用三点估计法，设各专家的估算期望值为Ｅ　，最　终估算期望中值为Ｅ，则有Ｅｉ一（ａｉ＋４ｍｉ＋ｂｉ）／６，Ｅ：ＳＵｍ　（Ｅｉ）／ｎ；⑤组织者召集专家开会，对估算结果进行讨论；⑥　各专家研究估算结果，重新提交一份估算表格。重复④至　⑥步骤，直至获得一个大多数专家认可的估算值。　Ｄｅｌｐｈｉ法可以避免集体讨论盲目屈从权威或多数的　缺陷，消除相互问的影响，能让专家充分表达各自见解，集　思广益。然而该方法实施过程繁琐，并且非常耗时。　（４）参数模型法，即通过采用一个或多个数学公式得　出估算值的方法。这些数学公式一般是在搜集大量历史　软件项目数据的基础上，进行数学建模得出经验公式，使　用起来比较方便快捷。但一般都需要经过一定的校准之　后才具有实际参考意义。　３　ＩＦＰＵＧ　在规模估算阶段，比较流行的参数模型有ＩＦＰＵＧ（Ｉｎ—　ｔｅｒｎａｔｉｏｎａｌ　Ｆｕｎｃｔｉｏｎ　Ｐｏｉｎｔ　Ｕｓｅｒｓ　Ｇｒｏｕｐ，国际功能点用户　协会）功能点分析法。该方法最初是由ＩＢＭ公司的工程　师Ａｌｌａｎ　Ａｌｂｒｅｃｈｔ所设计的自顶向下法，后被ＩＦＰＵＧ所　采用、发展和推广，并出版了多个版本的功能点计算实践　手册　］。该方法是目前应用最广泛的软件规模度量技术，　在我国的软件行业软件工程定额标准（２００９版）中也参考　了该方法。该方法的基本步骤如下：　（１）把软件系统分解为如表１所示的５类功能点，并　估算各类功能点的数量（ＦＰｉ）＿１］。　（２）给各功能点分配复杂度权重（Ｗｉ），如表２所　示　。　在给各功能点分配权重时，有定量的判断规则。判断　ＩＬＦ和ＥＩＦ的复杂度依据的是其中所包含的数据元素类　型数（ｄａｔａ　ｅｌｅｍｅｎｔ　ｔｙｐｅ，ＤＥＴ）和记录元素类型数（ｒｅｃｏｒｄ　ｅｌｅｍｅｎｔ　ｔｙｐｅ，ＲＥＴ）。它们的判断表格如表３所示　］。　而对ＥＩ、ＥＯ和ＥＱ复杂度的判断，除了ＤＥＴ外还需　要依据所涉及的文件类型数（ｆｉｌｅ　ｔｙｐｅ　ｒｅｆｅｒｅｎｃｅｄ，ＦＴＲ），　并且有所不同。ＥＩ的复杂度判断表格如表４所示　］，Ｅ０　和ＥＱ复杂度判断表格如表５所示　ｊ。　表１功能点类型　类型名称　描述　内部逻辑文件（ｉｎｔｅｒｎａｌ　用户可识别的，并且在本系统内进行维护的　ｌｏｇｉｃａｌ　ｆｉｌｅ，ＩＩ　Ｆ）　一组逻辑相关的数据或控制信息　外部接口文件（ｅｘｔｅｒｎａｌ　用户可识别的，并且由本系统引用的一组逻　ｉｎｔｅｒｆａｃｅ　ｆｉｌｅ，ＥＩＦ）　辑相关的数据或控制信息（此类数据或信息　由系统外部所维护）　外部输人（ｅｘｔｅｒｎａｌ　ｉｎ—　处理来自系统外部数据或控制信息的基本过　ｐｕｔ，ＥＩ）　程　外部输出（ｅｘｔｅｒｎａｌ　ｏｕｔ—　向系统外提供数据或控制信息的基本处理过　ｐｕｔ，ＥＯ）　程（该过程包含逻辑运算过程、维护ＩＩ　Ｆ或　改变系统本身）　外部查询（ｅｘｔｅｒｎａｌ　ｉｎ～　向系统外提供数据或控制信息的基本过程　ｑｕｉｒｙ，ＥＱ）　（该过程不包含逻辑运算过程、维护ＩＩ　Ｆ或　改变系统本身）　表３　１ＬＦ和ＥｌＦ的复杂度判断　（３）计算出一个未修正的功能点数（Ｕｎａｄｊｕｓｔｅｄ　Ｆｕｎｅ—　ｔｉｏｎ　Ｐｏｉｎｔ　Ｃｏｕｎｔ，ＵＦＰＣ）［　：　ＵＦＰＣ＝ｓｕｍ（ＦＰ　×Ｗ　）。　（４）计算调整后的功能点数。仅从功能点数和其本身　的复杂度，不能全面地反映系统规模，为此ＩＦＰＵＧ还引入　了ｌ４个系统特性（ｇｅｎｅｒａｌ　ｓｙｓｔｅｍ　ｃｈａｒａｃｔｅｒｉｓｔｉｃ）对ＵＦＰＣ　进行修正：数据通信、分布式数据处理、性能、可配置性、事　务效率、实时数据输入、终端用户易用性、在线升级、复杂　运算、代码复用性、安装简易程度、操作方便性、多场合适　应性、易于调整变更　。将该系统特性（Ｆｉ）按对系统规模　的影响程度划分为６个级别，从无影响到最大影响分别用　数字０～５表示，这样最终的功能点数ＦＰ可由以下公式　计算得出：　ＦＰ＝ＵＦＰＣ×（０．６５＋０．０１×ｓｕｍ（Ｆ，））　上式中的０．６５和０．０１均为经验常量。　・２２・　软件导刊　２０１４年　得了良好效果。但软件工程技术突飞猛进，新的软件过程　４　ＣＯＣＯＭｏ　模型不断涌现，ＣＯＣＯＭＯ８１的应用渐渐遇到了更多的困　难。为了适应新的需要，Ｂｏｅｈｍ与其合作者对ＣＯＣＯＭＯ　在工作量估算阶段，常用的参数模型有Ｃａ　ＭＯ（Ｃｏｎ—　ｓｔｒｕｃｔｉｖｅ　Ｃｏｓｔ　Ｍｏｄｅｌ，结构化成本模型）。该模型是由Ｂａｒｒｙ　Ｉ３ｏｅｈｍ在１９８１提出的（因此也称为ＣＯＣＯＭＯｇ１模型），是他　研究了美国ＴＲｗ公司的大量软件项目后，推导出的一个成　进行了不断改进，在１９９６年正式发布了第一个版本的　ＣＯＣＯＭ０Ⅱ　，在Ｃ０Ｃ０Ｍ０Ⅱ中对ＣＯＣ０Ｍ（）８１做了较　大变更，比如划分为应用组装模型、早期设计模型、后构架　模型。早期设计模型和后架构模型的计算公式均为　：　本估算模型　］。该模型按详细程度，分成基本型、中等型和　详细型。基本型按以下公式构建口　：Ｅ＝ａ×　。　其中，Ｅ表示工作量，是按人月度量的；Ｓ是指规模，　ＰＭ—Ａ　Ｘ　Ｓ　×Ｉｌ　ＥＭ　其中，ＰＭ为工作量，单位为人月，Ａ为常量３．１３（ＣＯ　是按千行源代码为单位的；ｎ、ｂ是常量，常量的选择与软　ＣＯＭ０ＩＩ　２００３版），Ｓ是指规模（按千行源代码为单位），　件项目的类型有关，Ｂｏｅｈｒｎ把系统类型分为３种，如表６　所示　］。　表６　ＣＯＣＯＭＯＳ１系统类型与基本型常量　中等型是对基本型的扩展，它对表６中的模型常量进　行了适当调整，如表７所示　。同时引入了１５个工作量　因素（Ｆｉ），这些因素都被分为６个等级，每级都有对应的　常量，如表８所示　。　表７　ＣＯＣＯＭＯ８１中间型常量　因素类型工作量因素　非常低低　很高非常高　０．７５　０．８８　譬星釜蓁霪规模　Ｏ．９４　０．７　０．８５　执行时间的约束　硬件　内存约束　因素　虚拟机稳定性　０．８７　回复时间的需求　Ｏ．８７　分析员能力　１．４６　。　应用经验　１．２９　１．１３　翥　验　１．４２　１．１７　１．２１　１．１　编程语言经验　Ｉ．４１　１．０７　项目　现代程序设计技术　１．２４　１．１　主嚣篇篙　求　１．２４　１．１　１．２３　１．Ｏ８　中等型模型的计算公式最终调整为：　１　５　Ｅ—ｎＸＳ　ＸＥＡＦ，其中ＥＡＦ：ＩＩＦ　１　详细模型是对中等模型的进一步扩展，其基本公式与　中等模型的公式相同。它把系统划分为系统层、子系统　层、模块层，按这３层提供不同的成本驱动因素表，供不同　层次估算使用。同时还将模型常量按开发阶段的不同进　行一定的调整。　ＣＯＣＯＭ０８１推出后，在软件业得到了广泛应用，也取　ＥＭ　为工作量系数，类似于Ｃ０Ｃ０Ｍ　１中的工作量因　素，在早期设计模型中概括为７个（式中ｎ＝７），而在后架　高一堕　一　１　够１　ｕ＿　ｌ　１　ｌ。　１　１　踮Ｏ　Ｏ　构模型中扩展为１７个（式中　一１７）。Ｅ由以下公式计算　所得　］：　５　Ｅ＝Ｂ＋０．０１×∑ＳＦ　ｚ＝１　其中，Ｂ为常量０．９３（ＣＯＣＯＭＯＩ］２００３版）＿６］，ＳＦ，为：　有先例、开发灵活性、架构／风险解决方案、团队凝聚力、过　程成熟这５个特性各按６个等级取值而来的比例因子　Ｊ。　５　结语　软件项目估算的目的不是预测项目实施的结果，而是　帮助确定项目目标，使其在合理范围内，从而能让项目在　可控状态下达成项目目标口　。软件的估算离不开历史数　据的支撑，虽然有行业数据参考，但其准确度非常低，不同　开发组织的生产率水平相差非常大，冈此需要尽早积累开　发组织自身的历史数据。可从一组少量的数据开始，例　如：每人每月完成的代码行数、交付一个用户故事的平均　时长、ＢＵＧ出现的概率以及修复时长等。　参考文献：　［１］ＩＦＰＵＧ．Ｆｕｎｃｔｉｏｎ　ｐｏｉｎｔ　ｃｏｕｎｔｉｎｇ　ｐｒａｃｔｉｃｅｓ　ｍａｎｕａｌ［Ｍ］．Ｗｅｓｔｅｒｖｉｌｌｅ：ＩＦ—　ＰＵＧ，１９９９．　［２］ＢＯＢ　ＨＵＧＨＥＳ，ＭＩＫＥ　ＣＯＴＴＥＲＥＩ　．软件项目管理［Ｍ］．第５　版．北京：机械工业出版社，２Ｏ１Ｏ．　［３］池仁勇．项目管理［Ｍ］．第２版．北京：清华大学出版社，２００９．　Ｅ４３　房东．软件项目估算模型研究与实践［Ｄ］．济南：山东大学，２００６．　［５］胡云龙．软件规模度量方法介绍［Ｊ］．计算机时代，２００６（７）：Ｉ７－２１．　Ｅ６］　蒋敏迪．软件成本估算模型及其实现［Ｄ］．广州：中山大学，２００４．　［７］　李莉．基于功能点的ＣＯＣＯＭＯＵ估算模型研究和应用［Ｄ］．厦门：　厦门大学，２００８．　［８］刘瑞河，陈志成．软件项目管理中的成本估算［Ｊ］．江西理工大学学　报，２００７，２８（１）：３６—３９．　［９］　舒小仙．软件项目管理的成本估算［Ｊ］．中国水运。２００８，８（１２）：８０～８１．　［１Ｏ］郑人杰，殷人昆，陶永雷．实用软件工程［Ｍ］．第２版．北京：清华　大学出版社，１９９７．　［１１］ＳＴＥＶＥ　ＭＣＣＯＮＮＥＩ　Ｉ　．软件估算一一“黑匣子”揭密［Ｍ］．北京：　电子工业出版社，２００７．　（责任编辑：孙娟）　０（０％　０