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