《软件成本估算及应用》由会员分享，可在线阅读，更多相关《软件成本估算及应用（53页珍藏版）》请在金锄头文库上搜索。
1、软件成本估算方法及应用,摘 要,软件成本估算是软件开发必需品； 按照基于算法模型的方法、非基于算法模型的方法以及组合方法的分类方式,分析了软件成本估算的各种代表性方法； 与成本估算强相关的软件规模度量问题； 研究了软件成本估算方法的评价标准,并给出了一个应用实例及其分析； 从估算模型、估算演进、估算应用、估算内容、工具支持和人为因素6 个方面说主要发展趋势.,背景,软件成本估算不足与需求不稳定并列,是造成软件项目失控最普遍的两个原因,是否采用算法模型分为3 大类:,1 基于算法模型的软件成本估算方法,提供了一个或多个算法形式,如线性模型、乘法模型、分析模型、表格模型以及复合模型等,将软件成本估
2、算为一系列主要成本驱动因子变量的函数.该方法通过成本估算关系(cost estimating relationship)把系统特征与工作量、进度的估算值联系起来.,基本思想,找到软件工作量的各种成本影响因子,并判定它对工作量所产生影响的程度是可加的、乘数的还是指数的,以期得到最佳的模型算法表达形式.,优缺点,一方面,它们比较客观、高效、可重复,而且能够利用以前的项目经验进行校准,可以很好地支持项目预算、权衡分析、规划控制和投资决策等; 另一方面,它们难以用在没有前例的场合,不能处理异常情况,也不能弥补不准确的规模输入和成本驱动因子级别的问题.,通用形式,A 为校准因子(calibration
3、factor); Size 为对工作量呈可加性影响的软件模块的功能尺寸的度量; B 为对工作量呈指数或非线性影响的比例因子(scale factor); EM 为影响软件开发工作量的工作量乘数(effort multiplicative).,COCOMO 81,(1) 基本(basic)模型,在项目相关信息极少的情况下使用; (2) 中等(intermediate)模型,在需求确定以后使用; (3) 详细(detailed)模型,在设计完成后使用.,模型通式,Effort 为工作量,表示为人月;a 和b 为系数,具体的值取决于建模等级(即基本、中等或详细)以及项目的模式(组织型、半独立型或嵌入
4、型). KDSI 为软件项目开发中交付的源指令(delivered sourceinstruction,简称DSI)千行数,也可用代码行LOC表示,代表着软件规模. F 是调整因子,基本模型中,F=1,后两个模型中,F 为15 个成本因子对应的工作量乘数的乘积.,例1,要开发一个估计规模为30KDSI 的银行系统应用程序项目,其功能以数据处理为主,属于组织型软件模式,根据专家意见和项目数据校准,系数a=2.4,b=1.05;调整因子F=1,则工作量Effort 估算为,随着项目的进展和需求的确定,可以使用中等COCOMO 81 模型进行估算.,例2,对于例1 的系统,随着项目进展,可以确定其1
5、5 个成本因子的情况：其软件可靠性因子RELY、计算机周转时间因子TURN(computer TURNaround time)、要求的开发进度因子SCED(required development schedule)等特殊说明外,其余因子均为标称取值1.00,详细COCOMO 81 模型与中等主要区别,一旦软件的各个模块都已确定,估算者就可以使用详细COCOMO 81 模型.其主要区别在于: (1) 将待估算的软件项目分解为模块、子系统、系统3 个等级. (2) 增加了与开发阶段相关的工作量乘数,它可以准确反映成本驱动因子对工作量阶段分布的影响.,需求与产品设计RPD(requirements
6、 & product design) 详细设计DD(detailed design) 代码与单元测试CUT(code & unittest) 集成与测试IT(integration & test).,COCOMO II模型,3 个子模型组成 (1) 应用组合(application composition)模型,基于对象点(object point)对采用集成计算机辅助软件工程工具快速应用开发的软件项目工作量和进度进行估算,用于项目规划阶段; (2) 早期设计(early design)模型,基于功能点(function point,简称FP)或可用代码行以及5 个规模指数因子、7个工作量乘数
7、因子,选择软件体系结构和操作,用于信息还不足以支持详细的细粒度估算阶段; (3) 后体系结构(post-architecture)模型，发生在软件体系结构完好定义和建立之后,基于源代码行和功能点以及5个规模指数因子、17 个工作量乘数因子,用于完成顶层设计和获取详细项目信息阶段.,改进,第一,COCOMO II规模度量在不同开发阶段,可以分别用对象点、功能点或代码行表示. 第二,COCOMO II充分考虑了复用与再工程. 其中需求演化和变更因子REVL：需求变更的百分比,等价KSLOC：将复用代码和改编代码的有效规模调整后的新代码行. 第三,进一步调整和改进成本因子.先例性、开发灵活性、早期体
8、系结构/风险化解RESL、团队凝聚力、过程成熟度.,2 非基于算法模型的软件成本估算方法,专家估算 类比估算 回归分析,2.1 专家估算,专家估算,由一个被认为是该任务专家的人来控制,并且估算过程的很大一部分是基于不清晰、不可重复的推理过程,也就是“直觉(intuition)”. 单个专家经常使用工作分解结构WBS(work breakdown structure),通过将项目元素放置到一定的等级划分中来简化预算估计与控制的相关工作. WBS 包括两个层次的分解: 一个表示软件产品本身的划分,分解为各个功能组件及其各个子模块; 一个表示开发软件所需活动的划分,分解为需求、设计、编码、测试、文档
9、等及其下更具体的细分,例如系统设计、数据库设计、详细设计等.,Delphi 方法,首先,每个专家在不与其他人讨论的前提下,先对某个问题给出自己的初步匿名评定. 第1 轮评定的结果收集、整理之后,返回给每个专家进行第2 轮评定. 这次专家们仍面对同一评定对象,所不同的是他们会知道第1 轮总的匿名评定情况.第2 轮的结果通常可以把评定结论缩小到一个小范围,得到一个合理的中间范围取值.,2.2 类比估算,使用类比(analogy)的方法进行估算是CBR(case-based reasoning,基于实例推理)的一种形式, 即通过对一个或多个已完成的项目与新的类似项目的对比来预测当前项目的成本与进度.
10、 在软件成本估算中,当把当前问题抽象为待估算的项目时,每个实例即指已完成的软件项目.,面对的问题,(1) 如何描述实例特征,即如何从相关项目特征中抽取出最具代表性的特征; (2) 通过选取合适的相似度/相异度的表达式,评价相似程度; (3) 如何用相似的项目数据得到最终估算值.特征量的选取是一个决定哪些信息可用的实际问题,通常会征求专家意见以找出最相似实例的特征.当选取的特征不够全面时,所用的解决方法也是使用专家意见.,相似度计算,可以直接取最相似的项目的工作量(对应P0 工作量取1000); 比较相似的几个项目的工作量平均值(对应P0 工作量取1900/2=950); 采用某种调整策略,例如
11、用项目的规模作调整参考,采用如下调整:Size(P0)/Size(P1)=Effort(P0)/Effort(P1),得到P0 工作量为1000180/200=900.,不足点,一是不能适用于早期规模等数据都不确定的情况 二是应用一般集中于已有经验的狭窄领域,不能跨领域应用; 三是难以适应新的项目中约束条件、技术、人员等发生重大变化的情况.,2.3 回归分析,数据驱动方法；在对软件项目进行估算时,通常情况下能得到相关软件组织或软件产品的某些历史数据.充分利用这些历史数据来预测与估算未来状况。 最传统回归方法OLS( 普通最小二乘回归,ordinary least squares regress
12、ion),假定了将一个依赖变量与一个/多个独立变量相关联的一个函数形式,OLS 方法的回归函数,对于OLS 回归,指定一个模型(以表现依赖变量与独立变量之间的关联形式),然后将数据与这个指定的模型相配合,试图使得方差的总和最小. 这里, ik i x x . 2 是对第 i 次观测值的回归变量, 2. 是响应系数,1是截距参数,yi是对第 i 次观测值的响应变量,ui 是随机误差. 令 ri表示对于第 i 次观测值的实际观测结果 yi与预计结果 yi的差值,则 2ri 就是平方误差.OLS 方法要做的就是估算出响应系数和截距参数,使得平方误差的总和达到最小化,缺点,(1) 由于每一个观测值对于
13、模型公式有同等的影响,因此,哪怕只有一个差异过大的极端观测值,也会对模型产生不可预计的影响. (2) 由于所需的历史数据依赖于回归模型中的参数个数,当模型中回归变量增多时,需要较多数量的历史数据.通常,回归模型所需的历史数据数必须至少是模型中参数个数的5 倍. (3) 需要满足对于软件工程数据来说比较严格的假设条件,即回归变量之间不能存在很强的相关性,回归误差的方差恒定.,3 软件成本估算的组合方法,所谓软件成本估算的组合方法,就是在估算技术上明显地综合运用了多种技术与分析方法,这是目前软件成本估算的趋势,也是中和各种估算方法利弊、适应不同估算场合与要求的更好选择.,3.1 COBRA,COB
14、RA(cost estimation, benchmarking, and risk assessment)是一种将算法方式与经验方式相结合的混合估算方法,其核心是建立一个由两组件构成的生产率估算模型,步骤,第一,建立因果关系模型(causal model),用来进行成本超支(cost overhead)的估算. 确定最重要的成本驱动因子. 建立定性的因果关系模型. 提出项目数据问卷. 量化关系.对各个成本因子的量化就是反映它们在非正常项目中对成本影响的百分比程度,该值称为成本超支乘数. 建立成本超支估算模型,该模型由三角形分布的总和来表示. 估算成本超支,用Monte Carlo 仿真来对三
15、角形分布取样,仿真的结果是成本超支的一个分布,可以选取分布的中值作为项目成本超支的一个估算值. 第二,建立生产率等式(productivity equation),得到对应于一个成本超支值的资金数额或者工作量.,优缺点,优点:(1) 在仅有少量项目数据时可选用该方法; (2) 在项目估算方面,对可重用的专家知识进行了清晰的建模; (3) 模型是以组织自身经验为基础的,因此更容易被实践者所接受. 缺点：(1) 需要专家接受面访; (2) 知识抽取比较困难,需要更多培训与经验.,4 软件规模度量,第一,在算法模型发展中,很多研究结论不约而同地沿用了本文引用的通用公式(2)或者另外一种表达形式:Ef
16、fort=A+B(Size)C,这都表明了软件工作量PM 或者Effort 与规模Size 直接的紧密联系.随着时间的发展,函数中的参数值发生了变化,规模度量形式也发生了改变,但是这种强相关的形式却一直被沿用着. 第二,目前在软件估算方法的研究中又出现了一批更加直接使用规模度量值的方法。,度量方式,代码行 功能点及其扩展方式 对象点 用例点,4.1 代码行,(1) 对代码行没有公认的可接受的标准定义.例如,最常见的计算代码时的分歧有空代码行、注释代码行、数据声明、复用的代码,以及包含多条指令的代码行等.在Jones 的研究中发现,对同一个产品进行代码行计算,不同的计算方式可以带来5 倍之大的差异. (2) 代码行数量依赖于所用的编程语言和个人的编程风格.因此,计算的差异也会影响用多种语言编写的程序规模,进而也很难对不同语言开发的项目的生产率进行直接比较. (3) 在项目早期,需求不稳定、设计不成熟、实现不确定的情况下很难准确地估算代码量. (4) 代码行强调编码的工作量,只是项目实现阶段的一部分.,4.2 功能点,从需求得到系统所要
