软件成本估算方法及应用.pptVIP

步骤 第一,建立因果关系模型(causal model),用来进行成本超支(cost overhead)的估算. ① 确定最重要的成本驱动因子. ② 建立定性的因果关系模型. ③ 提出项目数据问卷. ④ 量化关系.对各个成本因子的量化就是反映它们在非正常项目中对成本影响的百分比程度,该值称为成本超支乘数. ⑤ 建立成本超支估算模型,该模型由三角形分布的总和来表示. ⑥ 估算成本超支,用Monte Carlo 仿真来对三角形分布取样,仿真的结果是成本超支的一个分布,可以选取分布的中值作为项目成本超支的一个估算值. 第二,建立生产率等式(productivity equation),得到对应于一个成本超支值的资金数额或者工作量. 优缺点 优点:(1) 在仅有少量项目数据时可选用该方法; (2) 在项目估算方面,对可重用的专家知识进行了清晰的建模; (3) 模型是以组织自身经验为基础的,因此更容易被实践者所接受. 缺点：(1) 需要专家接受面访; (2) 知识抽取比较困难,需要更多培训与经验. 4 软件规模度量 第一,在算法模型发展中,很多研究结论不约而同地沿用了本文引用的通用公式(2)或者另外一种表达形式:Effort=A+B×(Size)C,这都表明了软件工作量PM 或者Effort 与规模Size 直接的紧密联系.随着时间的发展,函数中的参数值发生了变化,规模度量形式也发生了改变,但是这种强相关的形式却一直被沿用着. 第二,目前在软件估算方法的研究中又出现了一批更加直接使用规模度量值的方法。 度量方式 代码行 功能点及其扩展方式 对象点 用例点 4.1 代码行 (1) 对代码行没有公认的可接受的标准定义.例如,最常见的计算代码时的分歧有空代码行、注释代码行、数据声明、复用的代码,以及包含多条指令的代码行等.在Jones 的研究中发现,对同一个产品进行代码行计算,不同的计算方式可以带来5 倍之大的差异. (2) 代码行数量依赖于所用的编程语言和个人的编程风格.因此,计算的差异也会影响用多种语言编写的程序规模,进而也很难对不同语言开发的项目的生产率进行直接比较. (3) 在项目早期,需求不稳定、设计不成熟、实现不确定的情况下很难准确地估算代码量. (4) 代码行强调编码的工作量,只是项目实现阶段的一部分. 4.2 功能点 从需求得到系统所要实现功能的功能点,功能点的数量即系统规模.从功能点可以映射到代码行,从而用于成本和进度估算模型,这个转换随着开发语言的不同也会发生变化. 两步计算 第1 步,按照5 种基本类型(外部输入EI、外部输出EO、内部逻辑文件ILF、外部接口文件EIF、外部查询EQ)归类,得到初始功能点数,分别乘以复杂性权重(根据每个功能类型所含数据元素和引用文件的数量分别归为“简单”、“一般”、“复杂”3 个复杂度等级,并对应不同的复杂性权重,见表3),5个加权后的数字相加即得到“未调整功能点”UFP(unadjusted function points)数; 第2 步,根据14 个基本系统特征(general system characteristic,简称GSC)确定调整因子VAF(value adjustment factor),把调整因子应用到未调整功能点,即得到调整的功能点. 4.4 对象点 对象点(object point).可以应用于所有类型的软件开发,而不局限于面向对象的开发.利用功能点的基本原理,对象点方法需要考虑那些需投入大工作量的方面来获取规模,例如,服务器数据表的数量、客户数据表的数量、报表(report)和屏幕(screen)中可重用的百分比等等. 要计算对象点,分析人员首先要计算应用中屏幕(screen)、报表(report)和第三代语言组件(3GL component)数量的最可能值. 4.5 用例点 用例点(use case point,简称UCP)通过分析用例角色、场景和不同的技术与环境因子,把它们抽象到一个等式中.该等式由多个变量组成:未调整用例点(unadjusted use case point,简称UUCP)、技术复杂度因子(technical complexityfactor,简称TCF)和环境复杂度因子(environment complexity factor,简称ECF). 5 软件成本估算方法的评价与应用 软件成本估算方法、技术和工具种类很多,如何客观地评价和比较,以指导实际应用？ Briand 等人的3 组软件估算评价标准:(1) 模型与估算的标准(model andestimate criteria),包括模型与估算的质量、所需输入变量、估算的完整性、估算类型、校准、可解释性等; (2) 估算方法的标准(estimation method criteria),包