软件成本估算课件.ppt

1、软件成本估算l预测一个软件开发过程所需要的资源目标l软件成本计算和软件报价的基本原理以及在它们之间存在的复杂关系。l对软件生产率评估的度量。l在对软件成本和进度安排进行评估时应当使用一系列不同的技术。l用于算法成本估算的COCOMO 2模型的原理内容l生产率l估算技术l算法成本建模l项目的工期和人员配备估算的基本问题l完成一项活动需要多少工作量?l完成一项活动需要多少时间?l一项活动的总成本是多少?l项目估算和进度安排是交叉进行的管理活动软件成本构成l硬件和软件成本l差旅费和培训费用l工作成本 (大多数项目中是主要成本)项目中投入的工程师的工资社会和保险费用l工作成本还要计入办公场所、供热和照

2、面费用网络和通信费用共用设施的费用 (e.g 图书馆,员工餐厅, etc.)成本和报价l估算是为了得到承包商开发一个软件的成本l在成本和报价之间没有一个简单的关系 价格成本利润l广泛的因素包括机构的、经济的和商务上的考虑会影响报价影响软件报价的因素因素因素描述描述市场机遇开发机构为了便于进入一个新的软件市场，可能会提出一个低报价。成本估算的不确定性如果机构对成本估算没有把握，它会提高报价，在正常利润之上增加某些意外费用。合同条款客户可能愿意让开发者保有程序源代码的所有权，以便可以在未来的开发项目中复用。这时的要价就会比移交源代码的情况低得多。需求易变性如果需求很有可能发生变化，机构就会降低报价

3、以赢得合同，当得到合同之后，一旦需求有所变更，机构就会乘机抬高报价。经济状况当开发者处于资金短缺阶段时，为得到合同而作出较低报价，少获点例甚至收支相抵总比破产强。l软件开发工程师生产软件和相关文档的效率的度量l不是面向质量的，虽然质量保证是生产率评估的一个因素l本质上，我们是想度量单位时间里生产的有用功能程序员的生产率l面向规模的度量 这种方法是根据活动输出的量来衡量。可能是提交的源代码行数，目标代码说明书的长度或者系统文档的页数等。l面向功能的度量 这种方法是看移交软件总的功能有多少。功能点和对象点方法是最常用的方法。生产率的度量l估算软件规模l估算总的程序员人月数l估算分包商生产率 ，并且

4、合并到总的估算中度量的问题l什么是一个代码行?当程序打印在卡片上时代开始就使用的度量方法，一行一张卡片代码行如何跟语句对应起来，一个语句可能占几行，一行也可能有几个语句。l什么程序应该算作系统的一部分?l假设在系统大小和源代码大小之间有着线性关系代码行l编程语言越低级，计算出来的生产率越高同样的功能，低级语言需要更多代码l程序员的代码越冗长，计算出来的生产率越高生产率计算是基于程序员所写的代码量的生产率比较的问题高级和低级语言系统开发时间AnalysisDesignCodingTestingDocumentationAssembly codeHigh-level language3 weeks

5、3 weeks5 weeks5 weeks8 weeks8 weeks10 weeks6 weeks2 weeks2 weeksSizeEffortProductivityAssembly codeHigh-level language5000 lines1500 lines28 weeks20 weeks714 lines/month300 lines/month功能点l基于程序特性的组合外部输入输出用户交互外部接口系统使用的文件l每一项都有一个复杂性权值（315）l功能点计数就是将每项功能点数乘以权值，然后求和的结果。功能点l功能点计数由项目复杂性修正l根据给定语言的每功能点平均代码行数，

6、功能点计数可以用来计算代码行数LOC = AVC * FPs AVC 是基于语言的因子，汇编语言200-300， 4GL则2-40l功能点计数是非常主观的，依赖于估算者。自动功能点计数是不可能的。对象点l当使用高级语言（特别是4GL）开发时，作为另一个功能相关方法，对象点方法可以代替功能点方法l对象点不同于对象类l 程序的对象点是下列内容的加权估算：独立的显示屏幕数生成的报表数为辅助4GL代码而必须开发的3GL模块数对象点估算l对象点估算比功能点容易，因为它只关心屏幕数、报告数和3GL模块数l可以在开发过程的很早期使用，这时要估计系统的代码行还很困难。l实时嵌入式系统, 40-160 LOC/

7、人月l系统程序, 150-400 LOC/人月l商业应用, 200-800 LOC/人月l在对象点方法中，随支持工具和开发者能力不同，生产率在 450对象点/人月生产率估算影响生产率的因素因素因素描述描述应用领域经验应用领域知识是有效的软件开发的根本。已经对领域有充分了解的工程人员很可能是生产率最高的。过程质量所用的开发过程对生产率有极大的影响。项目规模项目规模越大，团队之间的交流和沟通就越花时间，真正有用的时间就会减少，因而，个人生产率就会降低。技术支持好的支持技术和CASE工具、配置管理系统等有助于提高生产率。工作环境一个好的工作环境有助于提高生产率。l所有基于单位时间内产量的做法都有问题

8、，因为没有考虑质量l以质量为代价，通常都能提高生产率l还不清楚生产率和质量之间的关系l变更不断的情况下，使用代码行生产率计算是没有意义的。质量和生产率估算技术l没有一个简单的方法可以精确估算软件开发所需的资源初始估算是基于用户需求定义中不充分的信息软件可能是运行于不熟悉的计算机系统或者使用新的技术项目中的开发人员不了解l项目成本估算可能是自己设定的用来确定项目预算和调整软件产品以保证预算不被突破估算技术l算法成本建模l专家判定l类比估计lParkinson定律l根据客户预算报价算法成本建模l所建立的模型利用有关历史信息来估计需要的工作量，用到的历史信息是有关某些软件度量（例如规模）与项目成本之

9、间的关系l本章后续讨论专家判定l多位软件开发和应用领域方面的专家用他们的经验预测软件成本。反复进行直到达成一致。l优点: 相对廉价的估算方法。如果专家具有相似系统的直接经验的话，可以比较精确。l缺点: 如果没有专家的话，将非常不精确。类比估计l将项目和一个同样应用领域里的类似项目作比较，从而计算出成本。l优点: 如果项目数据具备的话比较精确l缺点: 如果没有可比的项目，则不可能应用。需要系统性维护的成本数据库Parkinson定律l工作占满所有可用的时间。成本决定于所有可用的资源而不是客观的估算。l优点: 不会超支l缺点: 系统经常完不成根据客户预算报价l将客户对项目的预算作为软件的成本l优点

10、: 得到了合同l缺点: 成本无法精确反映工作所需。自上而下和自下而上的估算l以上的方法都可以是自上而下或自下而上的l自上而下从系统层面开始，评估系统的总体功能以及如何通过子系统间的交互完成的。l自下而上从组件层面开始，估算每个组件所需的工作量。将这些工作量加在一起得到最后的估算。自上而下的估算l无需系统体系结构以及组件的知识就可应用l成本考虑集成、配置管理和文档等l可能会低估解决低层技术难题的成本自下而上的估算l当体系结构和组件识别已知的情况下使用l如果系统已经得到详细设计时是比较精确的方法l可能会低估系统级活动的成本，如集成和文档等估算方法l每个方法都有优缺点l估算应该基于多种方法l如果得到

11、的结果相差甚远，意味着信息不够充分l为了得到更精确的估算，需要额外采取行动l有时候根据客户预算报价是唯一可用的方法。基于经验的估算l从根本上说估算是基于经验的l然而，一些新的方法和技术导致基于不精确的经验的估算面向对象开发而非面向功能的开发客户机/服务器系统而非基于主机的系统使用现成的软件组件基于组件的可复用的软件工程使用CASE工具和程序生成器根据客户预算报价l这个方法看似不道德的而且是不实事求是的l然而，当详细信息缺乏的时候，它可能是唯一合适的策略l项目成本基于开发大纲而定，成本是开发的限制因素。l开发商和客户之间通过协商建立详细的项目描述，或者使用一个进化式开发方法。算法成本建模l通过对

12、项目规模、程序员数量以及其他过程和产品因素的估算，用一个数学共识来估算项目的成本。工作量 = A SizeB MA 是反映机构情况的常数因子，B 反映了大型项目工作量的非线性因子，M 是一个乘数因子，反映了不同过程、产品及开发特征的混合因素。l最常用的产品特性是代码规模l大多数模型都是相似的，只是A，B和M的值不同估算的精度l只有系统完成后才能精确知道软件的规模l一些因素影响最后的规模使用现货产品和组件编程语言系统的分布l随着开发过程的进展，代码规模的估算变得更加精确估算的不确定性COCOMO模型l是一个基于项目经验的经验模型l是一个独立的模型，不限于特定的软件开发商l有较长的历史，初始版本发

13、布于1981年(COCOMO-81)，不断改进得到了 COCOMO 2lCOCOMO 2考虑了不同的软件开发方法COCOMO 81COCOMO 2 的分层lCOCOMO 2 是一个3层模型，随着开发进展允许有日益具体的估算l早期原型层规模估算是基于对象点的，使用一个简单的规模/生产率计算公式估算所需工作量l早期设计层估算基于功能点，然后把这些功能点转换成源代码行数l后体系结构层估算基于源代码行数早期原型层l支持原型开发项目和大量复用的项目l基于开发者每月对象点生产率的标准估算l考虑了CASE工具的使用l估算公式：PM = ( NOP (1 - %reuse/100 ) ) / PRODPM 是

14、每人月工作量, NOP 对象点数， PROD是生产率，reuse是所期望的复用率对象点生产率早期设计层l需求确定后就可以做早期设计层的估算l基于算法模型的标准公式PM = A SizeB M + PMm 其中M = PERSRCPXRUSEPDIFPREXFCILSCEDPMm = (ASLOC (AT/100) / ATPRODA = 2.5, Size用KLOC表示, B根据项目的新颖程度、开发灵活性、风险管理方法和过程成熟度的不同从1.11.24不等乘法因子l乘法因子反映了开发者的能力、非功能需求、对开发平台的熟悉程度等。RCPX 产品的可靠性和复杂性RUSE 要求的复用性PDIF 平台

15、的难度PREX 个人经验PERS 个人能力SCED 要求的进度FCIL 团队支撑设施lPM 反映了自动生产代码的总量后体系结构层l使用和早期设计层同样的公式l对代码行数的估算要考虑以下修正因素需求的易变性。对需求变更的返工工作量进行估算。可能的复用程度。复用是非线性的，其相应的成本不能通过简单的减少单位时间内的LOCESLOC = ASLOC(AA + SU +0.4DM + 0.3CM +0.3IM)/100 ESLOC是新的代码行数。ASLOC是必须修改的复用代码行数。DM是设计修改的百分比。CM是代码修改的百分比。IM是集成复用软件所需的最初费用的百分比。 SU 是一个反映理解软件难易的

16、因子, AA反映为确定软件是否可复用所做的初始评估费用。l依赖于5个比例因子 (见下一页). 它们的和除以100再加上1.01就是该指数项的取值了l举例先例的援引 新项目 - 取值为“低”（4）开发的灵活性 没有客户介入 取值为“非常高”（1）体系结构/风险解决 没有风险分析 “非常低”（5）团队凝聚力 新团队 “一般”（3）过程成熟度 有一些过程控制 “一般”（3）l所以比例因子是 1.17指数因子指数比例因子比例因子比例因子解释解释先例的援引反映机构对这个类型项目的经验。“非常低”代表无经验，“非常高”代表机构对该领域已经彻底了解了开发的灵活性反映开发过程中的灵活性程度。“非常低”代表使用

17、事先规定的过程，“非常高”代表客户只给出了总的目标体系结构/风险解决反映风险分析完成的程度，“非常低”代表无分析，“非常高”代表完全和彻底的风险分析团队凝聚力反映开发团队成员相互了解的程度和协作的程度。“非常低”代表交互非常困难，“非常高”代表这是一个团结高效的团队，没有沟通障碍。过程成熟度反映机构的过程成熟度。该值的计算依赖于CMM的成熟度调查问卷，对它的估算可以用5减去CMM过程成熟度等级得到l产品属性关于所要开发的软件产品的要求特性l计算机属性硬件平台的约束l人员属性考虑开发人员的经验和能力l项目属性关于软件开发项目的特征乘数因子项目成本形成因素成本形成因素对工作量估算的影响l算法成本模

18、型为项目计划提供了基础，因为不同的算法成本模型提供了可供比较的不同的策略，以减少项目成本l举例：嵌入式太空船控制系统必须可靠必须最小化重量 (芯片的数量)可靠性和计算机约束的乘法因子 1l成本构成目标硬件开发平台所需工作量项目计划管理选项管理选项的成本选项的选择l选项D(使用更多有经验的人员)似乎是最好的选择然而，它有个高风险因数，因为有经验的人员难以找到l选项C(只升级存储器)节省成本较少但是风险很低l总之，这个模型显示了软件开发中人员经验的重要性。项目工期和人员配备l在估算工作量的同时，管理者必须估计一个项目的开发周期，以及人员要在什么时候到位l项目所需的日立时间可以用COCOMO 2公式

19、计算TDEV = 3 (PM)(0.33+0.2*(B-1.01)PM 是工作量计算值，B是上面所计算的指数项（对于早期原型模型，B=1)。通过这个计算预计了项目的名义进度。l所需时间不依赖于项目中的工作人员数人员要求l要求的人员不能单纯用所需工作量除以开发时间来计算。l项目不同时期，投入的工作人员数量是变化的l项目中的人员越多，往往要求的总工作量越大l草率的配置人员往往导致项目进度的拖延要点l影响生产率的因素包括个人能力、领域经验、开发过程、项目规模、工具支持和工作环境。l应使用多种软件成本估算技术，如果结果相差较大，则说明估算信息不充分。l软件通常是先有合同金额，然后再据此调整相应的功能。要点l算法成本估算是困难的，因为需要估计将要完成产品的特征。lCOCOMO模型预测成本时，要考虑项目、产品、人员和硬件的因素。l算法成本模型支持量化的选项分析。l完成一个项目所需要的时间和参加项目的人数不成比例。