软件工程中的成本估算模型
软件成本估算方法是一种软件专业人员用来估算项目成本的间接度量。它们被用于各种用途。它包含以下项目 -
预算 - 最需要的功能是整体估算的准确性。因此,首先要关注的是估算软件产品的预算。
权衡和风险分析 - 能够揭示软件项目选择(范围、人员配备、工具、重用等)的成本和进度敏感性是一个重要的附加功能。
控制和规划项目 - 另一个选项是按组件、阶段和活动细分成本和进度。软件增强的投资分析 工具、重用和流程成熟度都对软件开发过程有益。
成本估算模型
软件开发效率将缓解软件生产当前面临的挑战,这些挑战导致了成本超支甚至项目取消。软件工程成本模型,与任何其他学科一样,也面临着一些挑战。软件开发的快速发展使得开发能够在所有学科中为软件开发提供高准确度的参数模型变得非常具有挑战性。软件开发成本正在以惊人的速度增长,从业者不断抱怨他们无法有效预测所涉及的成本。软件模型有助于描述开发生命周期并预测构建软件产品的成本。在过去的二十年中,由于学术界开创性的工作,出现了许多软件估算模型。由于大多数模型都是专有的,因此无法在模型结构方面进行比较和对比。这些模型的功能形状是由理论或实验决定的。以下是其中一些 -
COCOMO 81
(a) COCOMO 基础
COCOMO 代表构造性成本模型。Barry Boehm 的著作《软件工程经济学》最初于 1981 年出版。由于模型易于透明,它提供了项目费用的量级。它专为小型项目设计,因为它具有有限数量的成本驱动因素。当团队规模较小时,即当员工人数较少时,它很有用。
它对于快速、早期、粗略地估算软件成本很有用,但由于缺乏因素来解释硬件约束、人员质量和经验、现代工具和技术的应用以及其他已知对软件成本有重大影响的项目属性的差异,因此其准确性有限。
工作量 = a* (KDSI)b 工作量 = a* (KDSI)
常数 a 和 b 根据项目类型具有不同的值。KLOC 是项目预计交付的代码行数。
COCOMO 中有三种模式 -
有机模式 - 一个小型、基本的软件项目,涉及一小群具有先前应用知识的人员。工作量 E 和开发时间 D 如下 -
E = 2.4*(KLOC)^1.05
D=2.5*(E)^0.38
半独立模式 - 一个中等规模的软件项目,其中具有不同专业知识水平的团队协作。
E= 3.0*(KLOC)^1.12D=2.5*(E)^0.35
嵌入式模式 - 一个必须在严格的硬件、软件和操作限制下构建的软件项目。
E= 3.6*(KLOC)^1.20
D= 2.5*(E)^0.32
(b) COCOMO 中级
它将软件开发工作量评估为程序规模和一组成本驱动因素的函数,其中包括对产品、硬件、员工和项目特征的主观评估。
它适用于中等规模的任务。成本驱动因素包括从基本到高级的 COCOMO。成本因素会影响产品可靠性、数据库大小、执行和存储。团队规模适中。COCOMO 中级模型如下 -
工作量 = a*(KLOC)b*EAF
这里,工作量以人月为单位测量,KLOC 是项目预计交付的代码行数。
(c) COCOMO 高级
它专为大型项目而设计。成本驱动因素由需求、分析、设计、测试和维护确定。团队规模相当大。高级 COCOMO 模型包含中级版本的所有特性,以及对成本驱动因素对软件工程过程每个阶段(分析、设计等)的影响的评估。
Explore our latest online courses and learn new skills at your own pace. Enroll and become a certified expert to boost your career.
COCOMO-II
COCOMO II 是一个始于 1994 年在南加州大学进行的研究项目。它非常重视非顺序和快速开发过程模型、再工程、重用驱动的 методология、面向对象的方法等等。它是三种模型的组合结果:应用组合、早期设计和后期架构。
在使用集成计算机辅助软件工程技术进行快速应用开发的项目中,应用组合模型用于估算工作量和进度。它基于对象点的概念(对象点是对应用程序中开发的屏幕、报表和 3GL 语言模块的计数)。
早期设计模型涉及查看备选系统设计和操作方法。
后期架构模型顾名思义,在完成顶层设计并获得有关项目的详细信息以及软件架构已明确定义且众所周知时使用。它是早期设计模型的全面扩展,考虑了整个开发生命周期。这是一个从精益到中级的 COCOMO 模型,定义如下 -
工作量 = 2.9(KLOC)^1.10
PUTNAM 模型 (SLIM)
软件生命周期模型 (SLIM) 基于 Putnam 对项目人员级别与时间的关系的瑞利分布的研究。它结合了大多数常见的规模估算方法,例如概算技术、源指令、功能指针等。它计算项目的工时、时间线和缺陷率。收集和分析先前完成的项目的数据,然后对模型进行标准化。如果数据不可用,可以完成一系列问题以从数据库中获取 MBI 和 PF 值。P 代表生产力,定义为软件产品规模 S 与开发工作量 E 的比率,如下 -
S/E = P
ESTIMACS
管理和计算机服务将这项专有技术商业化,它用于关键飞行软件(MACS)。在业务方面,ESTIMACS 强调审查的迫切工作。Rubin 确定了六个关键估算比例和一张描述它们之间相互作用的地图,从他所谓的“总体业务条款”到它们对开发人员长期预测的投资组合组合的影响。重要的估算维度如下:工作量小时数、工作量小时数、工作量小时数、工作量小时数、工作量小时数、工作量小时数
员工的数量和分布,
价格,
对硬件资源的需求,
风险,
对投资组合的影响。
SEER-SEM
加利福尼亚州埃尔塞贡多的 Galorath, Inc. 销售一种名为 SEER-SEM 的产品,它代表系统评估和资源估算。该模型已上市 15 年,基于原始的 Jensen 模型 [Jensen1983]。该模型具有广泛的应用。它涵盖了整个项目生命周期,从规范的早期阶段到设计、开发、交付和维护。它使对模型输入参数的灵敏度和权衡分析更容易。它将项目方面分解为工作分解结构,以便更好地规划和管理,并显示项目成本驱动因素。在甘特图上,该概念允许对项目方面进行交互式调度。估算基于先前项目的庞大数据库。
成本估算技术
A. 算法方法
软件成本估算使用算法技术计算,该技术使用公式。该公式源自通过合并而形成的成本因素模型。此外,还使用统计方法来构建模型。算法技术旨在提供一组可用于估算软件的数学方程。这些数学计算基于研究和历史数据,并考虑诸如源代码行数 (SLOC) 的数量、要运行的函数的数量以及其他成本驱动因素(如语言、设计方法、人才水平、风险评估等)。许多模型,例如 COCOMO 模型、Putnam 模型和基于功能点的模型,都是使用经过广泛研究的算法方法构建的。
功能点分析
另一种根据软件系统提供给用户的服务来评估软件系统规模和复杂性的方法是功能点分析。例如,ESTIMACS 和 SPQR/20 是两种使用功能点方法的专有成本估算方法。Albrecht [8] 是第一个建立此度量标准的人,该度量标准基于程序的效用。总功能点数由计算的不同(格式或处理逻辑)类型数量决定。
计算功能点包括两个步骤
用户函数列表的编译 − 原始函数数量是使用五个基本软件组件的线性组合计算得出的:外部输入、外部输出、外部查询、逻辑内部文件和外部接口,所有这些都分为三个复杂度等级:简单、中等和困难。函数数量的总数是这些数字的总和,并根据难度级别加权 (FC)。
考虑环境处理难度 − 最终的功能点是通过将 FC 乘以一个调整因子计算得出的,该调整因子是通过考虑 14 个不同的处理复杂度因素得到的。
B. 非算法技术
软件成本估算不是使用非算法方式中的公式计算的。
自顶向下估算方法
宏观模型是自顶向下估算的另一个名称。使用自顶向下估算方法,从软件项目的全局属性获得项目的总体成本估算,然后将项目划分为几个低级机制或组件。Putnam 模型是最流行的采用此策略的技术。当只有全局属性已知时,此技术更适合于早期成本估算。由于在软件开发的早期阶段没有可访问的精确信息,因此它非常有价值。
自底向上估算方法
使用自底向上估算方法计算每个软件组件的成本,然后将结果合并以得出整个项目的估计成本。其目标是利用收集到的关于小型软件组件及其交互的信息来构建系统估算。COCOMO 的详细模型是最流行的采用此方法的技术。
基于类比的估算
基于类比的估算就是将计划中的项目与已经完成的类似项目进行比较,并且该项目的开发信息是可用的。为了估算计划中的项目,将已完成项目的实际数据进行外推。此策略可用于系统级和组件级。以下是使用此方法估算的步骤
了解拟议项目的特性。
根据其特性,从历史数据库中选择最类似的已完成项目。
通过类比,使用最类似的已完成项目的成本计算拟议项目的成本。