《软件项目的成本管理.ppt》由会员分享，可在线阅读，更多相关《软件项目的成本管理.ppt（75页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、第七章软件项目成本估算学习目标1、软件项目规模成本的概念2、成本估算过程成本估算过程3、成本估算过程成本估算过程第一节 软件项目规模成本的概念主要内容：一、基本概念和术语一、基本概念和术语二、成本管理过程一、基本概念和术语一、基本概念和术语1、成本2、成本管理3、成本类型4、学习曲线5、收益递减规律1、成本成本，就是为了获取商品或服务而支付的货币总量。软件项目的成本，就是为了使软件项目如期完成，而支付的所有费用。软件项目成本可以从以下两个方面来看：1成本与质量、时间的关系。2在预算框架内控制成本。2、成本管理成本管理，就是为保障项目实际发生的成本不超过项目预算，使项目在批准的预算内按时、按质、
2、经济高效地完成既定目标而开展的项目管理活动。3、成本类型、成本类型可变成本：随规模变化的成本，如人员工资。固定成本：不随规模变化的非重复成本，如办公室租赁费用。直接成本：能够直接归属于项目的成本，如项目组旅行费用、项目组人员工资和奖金等。间接成本：需要几个项目共同分担的成本，如员工福利、保安费用、行政部门和财务部门费用等；沉入成本：那些在过去发生的费用，就像沉船一样不能回收的部分。当决定继续投资项目时，不应该考虑这部分费用。当决定项目是否该继续时，许多人像赌徒一样的心理指望能够收回沉入成本，这是不可取的。机会成本：如果选择另一个项目而放弃这一项目收益所引发的成本。4学习曲线理论学习曲线理论当重
3、复作某种类似的项目时，每次项目的成本会逐步下降；学习曲线理论认为，当作某事的次数翻倍时所花费的时间也会以一种有规律的方式递减，可以使用回归模拟的方式确定下降的速度。5收益递减规律收益递减规律投入的资源越多，单位投入的回报率就越低，有时甚至会呈现负增长。例如，在软件项目中，将编程人员增加一倍，项目总共的编程时间并不会减少一半。二、成本管理过程q资源计划编制:q确定项目需要的资源种类和数量q成本估算：中心环节q编制一个为完成项目各活动所需要的资源成本的近似估算q成本预算：项目进度q将总成本估算分配到各单项工作活动上q成本控制：项目跟踪q控制项目预算的变更关于估算q估算不是很准确的，有误差的q经验（
4、历史）数据非常重要q不要太迷信数学模型软件项目规模q软件项目规模即工作量，是从软件项目范围中抽出的软件功能，然后确定每个软件功能所必须执行的一系列软件工程任务q包括：软件规划，软件管理，需求，设计，编码，测试，以及后期的维护等任务。规模的单位qLOC(Loc of Code)q源代码程序长度的测量qFP(Function Point)q用系统的功能数量来测量q人月q人天q人年软件项目成本q完成软件规模相应付出的代价。q待开发的软件项目需要的资金。q人的劳动的消耗所需要的代价是软件产品的主要成本成本的单位q货币单位q人民币元q美元q.软件的规模和成本的关系q规模是成本的主要因素，是成本估算的基础
5、q有了规模就确定了成本,第二节成本估算过程成本估算过程估算输入估算结果成本估算方法成本估算输入q项目需求、WBSq历史项目度量q资源要求（资源编制计划）q资源消耗率:如人员成本:100元/小时q进度规划：项目总进度（一般是合同要求）q学习曲线资源规划q需要的资源种类、数量等Sample Resource Histogram for a Large IT Project成本估算q直接成本q间接成本直接成本q与具体项目相关的成本间接成本q不能具体到某个项目中的成本，q可以分摊到各个具体项目中的成本，例如：q培训q房租水电q员工福利q市场费用q管理费q其他等等项目估算输出q估算文件q资源，资源的数量
6、，质量标准，估算成本等信息q单位：一般是货币单位qBAC(Budget At completion)q估算说明q工作范围q估算的基础和依据q估算的假设q估算的误差变动等估算说明q预测所需要的总工作量的过程。q是一种量化的结果q可以有一些误差q成本估算不同于项目定价q贯穿于软件的生存周期。第三节成本估算方法估算的基本方法1.代码行、功能点、对象点、用例点2.自下而上估算法(WBS)3.参数法估算法4.专家估算法1、代码行 代码行：指源代码的总行数。包括无注释的源代码行NCLOC及注释的源代码行CLOC。源代码的总行数LOC包括NCLOC与CLOC之和。在评估时，可以分别根据LOC和NCLOC做为
7、评估值。一代码行（1LOC）的价值和人均代码行可以体现一个软件生产组织的生产能力，组织可以根据对历史项目的评审来核算组织的单行代码价值。（我们国内公司的私人老板不愿意这样做及有量化的东西，否则不好剥削）。代码行（LOC）从软件程序量的角度定义项目规模。q要求功能分解足够详细的q有一定的经验数据（类比和经验方法）q与具体的编程语言有关代码行（LOC）缺点1.对代码行没有公认的可接受的标准定义2.代码行数量依赖于所用的编程语言和个人的编程风格.3.在项目早期,需求不稳定、设计不成熟、实现不确定的情况下很难准确地估算代码量.4.代码行强调编码的工作量,只是项目实现阶段的一部分2、功能点功能点度量是在
8、需求分析阶段基于系统功能的一种规模估计方法，该方法通过研究初始应用需求来确定各种输入、输出、查询、外部文件、内部文件的数目，从而确定功能数量。为计算功能点数，首先要计算未调整的功能点数（UFC,Unadjusted Function Points）。其计算如下：（1）计算所需要的输入、输出、查询、外部文件、内部文件的数量。（2）根据以上五个功能项的数量，再由估计人员对项目的复杂性做出判断，大致划分为简单、一般、复杂三种情况，然后根据表1求出功能项的加权和，即为UFC。功能点FP是由未调整功能点数UFC与技术复杂因子（TCF，Technical Complexity Factor）相乘得到的。表
9、2有14个UFC，即A1A14，则计算：TCF=0.65+0.01*(SUM(Ai)。TCF的值为0.651.35之间，对应TCF的值为0与5。最后，计算FP=UFC*TCF。功能点有助于在软件项目的早期做出规模估计，但无法自动度量。一般的做法是在早期估计中使用功能点，然后依据经验将功能点转化为代码行，再用代码行继续进行估计。功能点度量在以下情况下特别有用：估计新的软件开发项目。应用软件包括很多输入输出或文件活动。拥有经验丰富的功能点估计专家。拥有充分的数据资料，可以相当准确地将功能点转化为LOC。功能点（FP:Function point）q用系统的功能数量来测量其规模q与实现产品所使用的语
10、言和技术没有关系的q两个评估q内部基本功能q外部基本功能q加权和量化 功能点的公式qFP=UFC*TCFqUFC：未调整功能点计数qTCF：技术复杂度因子UFC-未调整功能点计数功能计数项：1.外部输入2.外部输出3.外部查询4.外部文件5.内部文件UFC-未调整功能点计数功能计数项的复杂度等级复杂度权重因素项简单一般复杂外部输入346外部输出457外部查询346外部文件5710内部文件71015功能点计算实例-UFC功能点项简单一般复杂外部输入6*32*43*6外部输出7*47*50*7外部查询0*32*44*6外部文件5*52*73*10内部文件9*70*102*15总计UFC301TCF
11、-技术复杂度因子技术复杂度因子F1可靠的备份和恢复F2数据通信F3分布式函数F4性能F5大量使用的配置F6联机数据输入F7操作简单性F8在线升级F9复杂界面F10 复杂数据处理F11 重复使用性F12安装简易性F13 多重站点F14易于修改技术复杂度因子的取值范围调整系数调整系数描述描述0不存在或者没有影响1不显著的影响2相当的影响3平均的影响4显著的影响5强大的影响功能点计算实例qFP=UFC*TCFqUFC=301qTCF=0.65+0.01(14*3)=1.07qFP=301*1.07=322功能点与代码行的转换语言代码行代码行/FPAssembly320C150COBOL105FORT
12、RAN105PASCAL91ADA71PL/165PROLOG/LISP64SMALLTALK21SPREADSHEET63、WBS基础上的全面详细估算利用WBS方法，先把项目任务进行合理的细分，分到可以确认的程度，如某种材料，某种设备，某一活动单元等。然后估算每个WBS要素的费用。采用这一方法的前提条件或先决步骤是：对项目需求作出一个完整的限定。制定完成任务所必需的逻辑步骤。编制WBS表项目需求的完整限定应包括工作报告书、规格书以及总进度表。工作报告书是指实施项目所需的各项工作的叙述性说明，它应确认必须达到的目标。如果有资金等限制，该信息也应包括在内。规格书是对工时、设备以及材料标价的根据。
13、它应该能使项目人员和用户了解工时、设备以及材料估价的依据。总进度表应明确项目实施的主要阶段和分界点，其中应包括长期定货、原型试验、设计评审会议以及其他任何关键的决策点。如果可能，用来指导成本估算的总进度表应含有项目开始和结束的日历时间。一旦项目需求被勾划出来，就应制定完成任务所必需的逻辑步骤。在现代大型复杂项目中，通常是用箭头图来表明项目任务的逻辑程序，并以此作为下一步绘制CPM或PERT图以及WBS表的根据。编制WBS表的最简单方法是依据箭头图。把箭头图上的每一项活动当作一项工作任务，在此基础上再描绘分工作任务。进度表和WBS表完成之后，就可以进行成本估算了。在大型项目中，成本估算的结果最后
14、应以下述的报告形式表述出来：对每个WBS要素的详细费用估算。还应有一个各项分工作、分任务的费用汇总表，以及项目和整个计划的累积报表。每个部门的计划工时曲线。如果部门工时曲线含有“峰”和“谷”，应考虑对进度表作若干改变，以得到工时的均衡性。逐月的工时费用总结。以便项目费用必须削减时，项目负责人能够利用此表和工时曲线作权衡性研究。逐年费用分配表。此表以WBS要素来划分，表明每年（或每季度）所需费用。此表实质上是每项活动的项目现金流量的总结。采用这种方法估算成本需要进行大量的计算，工作量较大，所以只计算本身也需要花费一定的时间和费用。但这种方法的准确度较高，用这种方法作出的这些报表不仅仅是成本估算的
15、表述，还可以用来作为项目控制的依据。最高管理层则可以用这些报表来选择和批准项目，评定项目的优先性。4、建议掌握模型qCOCOMO模型(Boehm）COCOMO（Constructive Cost model）由Barry Boehm开发的详见：(南加州大学网站)COCOMO项目类型：项目类型：有机(组织):Organic嵌入式:Embedded半有机（半分离）:Semidetached模型类别：模型类别：q基本COCOMOq中等COCOMOq高级COCOMO模型类别q基本COCOMOq静态单变量模型q中等COCOMOq基本模型基础上考虑影响因素，调整模型q高级COCOMOq中等COCOMO模型
16、基础上考虑各个步骤的影响项目类型有机:Organic，各类应用程序，例如数据处理、科学计算等受硬件的约束比较小，程序的规模不是很大嵌入式:Embedded系统程序，例如实时处理、控制程序等紧密联系的硬件、软件和操作的限制条件下运行，软件规模任意半有机:Semidetached各类实用程序，介于上述两种软件之间，例如编译器（程序）规模和复杂度都属于中等或者更高基本COCOMOqE=a(KLOC)exp(b)q其中：qE是所需的人力（人月），qKLOC是交付的代码行qa，b是依赖于项目自然属性的参数：基本COCOMO系数表方式ab有机2.41.05半有机3.01.12嵌入式3.61.2举例一个33
17、.3KLOC的软件开发项目，属于中等规模、半有机型的项目，采用基本COCOMO：oa=3.0，b=1.12。oE=3.0L 1.12=3.033.3 1.12=152PM中等COCOMOqE=a(KLOC)exp(b)*乘法因子qa b是系数q乘法因子是根据成本驱动属性打分的结果，对公式的校正系数 中等COCOMO系数表方式ab有机2.81.05半有机3.01.12嵌入式3.21.2成本驱动因子乘法因子计算每个属性Fi的取值范围为：很低、低、正常、高、很高、极高，共六级。正常情况下Fi=1。Boehm推荐的Fi取值范围0.70,0.85,1.00,1.15,1.30,1.65当每个Fi的值选定
18、后，乘法因子的计算如下乘法因子F1*F2*Fi*Fn举例（续）一个33.3KLOC的软件开发项目，属于中等规模、半有机型的项目，采用中等COCOMO模型a=3.0，b=1.12。乘法因子0.70*0.85*1*1.15=1.09E=3.0L 1.12=3.033.3 1.12PM高级（详细）COCOMOq将项目分解为一系列的子系统或者子模型 q在一组子模型的基础上更加精确地调整一个模型的属性，高级（详细）COCOMO估算方法总结q初期q类比q专家估算q计划阶段q自下而上q参数模型q实施阶段（包括变更发生）q自下而上q参数模型成本估算方法综述q主要考虑三种模型:类比法,自下而上法,参数法.q自下
19、而上法费时费力,参数法比较简单q自下向上法与参数法的估计精度相似q类比法通常用来验证参数法和自下而上法的结果各种方法不是孤立的各种方法不是孤立的,应该注意相互的结合使用应该注意相互的结合使用4、专家判定专家判定就是与一位或多位专家探讨，专家根据自己的经验和对项目的理解对项目成本做出估算。由于单独一位专家可能会产生偏颇，因此最好由多位专家进行估算。对于由多个专家得到的多个估算值，需要采用某种方法将其合成一个最终的估算值，可以采用的方法有：求中值或平均值、召开小组会议讨论确定、Delphi技术（多次无记名跌代填表评估）、Wideband Delphi技术（多次无记名跌代填表评估，专家可以根据上面的结果修改自己的评估）。项目总报价1.1.项目总报价项目总报价=项目总估算成本项目总估算成本+风险利润风险利润1.项目利润=估算成本*a%2.风险基金=估算成本*b%3.税=估算成本*c%(例如:c为5.5左右)2.2.项目总报价项目总报价=(a+b+c)%*项目总估算成本项目总估算成本+项项目总估算成本目总估算成本综上所述：软件成本估算模型有助于制定项目计划，但使用时要谨慎。没有模型能完全反映软件组织及项目的特点、实际开发环境和很多相关的人为因素。到目前为止，还没有一种用于软件工作量估算的方法或模型能适用于所有的软件类型和开发环境，在具体使用这些估算方法时要根据实际项目的特征进行调整。