架构：软件成本估算

估计工作负载对于掌握软件开发至关重要。这可以作为敏捷团队的持续开发部分来实现，也可以通过响应招标作为迁移前的成本估算等方式来实现。

负责生成估算的团队经常会遇到相当大的工作量，如果未使用正确的成本核算，可能会导致大量时间消耗方法论。

根据所采用技术的效率，生成的测量数据可能会有显着差异。此外，对于有效性要求及其范围也存在误解。

本文提出了一种新颖的软件成本估算混合方法，该方法将软件离散化为更小的任务，并使用专家判断和算法技术。通过使用基于体积和复杂性的双因素资格系统，我们提出了一种更具适应性和可扩展性的模型来估计软件项目持续时间，特别强调大型遗留迁移项目。

目录

1. 简介
2. 现有 SCE 调查
   2.1.算法方法
   2.2．非算法方法
   2.3．基于人工智能的方法
   2.4。敏捷估算技术
3. 混合模型方法
   3.1.离散化
   3.2.双因素资格体系和努力计算任务
   3.3。算盘系统
4. 大型旧迁移项目中的特定用例
   4.1. SCE 在遗留迁移中的重要性
   4.2。混合模型的应用
   4.3．结果和发现
5. 结论

简介

软件成本估算 (SCE) 是软件工程领域内的一个系统化、定量的过程，涉及分析、预测和分配财务、软件系统的开发、维护和管理所需的时间和资源投资。

这项重要工作使用不同的方法、模型和技术，为利益相关者提供对成功软件的预期财务、时间和资源需求的专业评估项目执行。

它是项目规划的重要组成部分，允许在软件开发生命周期中进行资源的逻辑分配并支持风险评估和管理。

现有分包商调查

算法方法

COCOMO

在软件工程和成本估算领域，建设性成本模型（通常称为 COCOMO）是一个完善且备受推崇的模型。概念。 COCOMO 由 Barry Boehm 博士开发，研究软件属性和开发成本之间的相互作用。

该模型在从基本到详细的层次结构上运行，每个级别提供不同程度的粒度 [1]。该模型仔细使用代码行和其他项目细节等因素，将它们与经验成本估算数据保持一致。

尽管如此，COCOMO 并不是过去停滞不前的遗迹。多年来，COCOMO II 不断取得进步，涵盖了当代软件开发实践的复杂性，特别是在面向对象编程和敏捷方法等不断发展的范式中 [2]。

然而，尽管 COCOMO 的实证和系统方法提供了可信度，但其使用代码行数作为主要指标却招致了批评。对于功能属性更为重要的项目尤其如此。

功能点分析 (FPA)

功能点分析 (FPA) 摆脱了代码指标的严格限制，成为从功能角度评估软件的整体方法。

FPA 由 IBM 的 Allan Albrecht 于 20 世纪 70 年代末提出，旨在通过软件的功能及其为用户提供的价值来衡量软件，而不是通过软件的功能来衡量软件的性能。代码行数。

通过分类和评估不同的用户功能（例如输入、输出、查询和接口），FPA 将软件复杂性简化为可测量的功能点 [3 ].

这种方法在功能输出比底层代码更重要的项目中特别有效。 FPA 采用以用户为中心的方法，很好地满足了客户的需求，并提供了对开发人员和利益相关者都有吸引力的具体指标。

但是需要注意的是，FPA 的有效性取决于对用户需求的透彻理解，不确定性可能会导致估算的差异.

SLIM（软件生命周期管理）

SLIM（软件生命周期管理的缩写）植根于概率建模哲学，是由 Lawrence Putnam 设计的多方面工具 [4] .

SLIM 的本质围绕一组非线性方程展开，当这些方程交织在一起时，可以追踪软件开发项目从开始到完成的轨迹。 SLIM 结合历史数据和项目具体情况，呈现了一个概率图景，提供有关项目时间表、成本和潜在风险的见解。

SLIM 的独特之处在于它能够随着项目的进展进行调整和重新配置。通过持续吸收项目反馈，SLIM 动态完善其估算，以确保它们始终立足于项目实际情况。

这种持续的重新校准既是 SLIM 最大的资产，也是它的主要障碍。虽然它提供了灵活的适应性，但它​​也需要详细的数据记录和跟踪，这需要项目团队采取严格的方法。

非算法方法

专家判断

在软件评估方法的古老走廊中行走，我们不能忽视专家判断的持久智慧 [5]。专家判断避免了其他技术的严格算法和形式，而是借鉴了行业资深人士积累的经验和直觉能力。

这些经验丰富的从业者凭借从众多项目中收集到的丰富见解，具有评估范围、复杂性和可能性的天生能力新事业的困难。他们细致入微的理解可以弥补更严格的数据驱动模型留下的差距。

专家判断巧妙地捕捉了项目的无形微妙之处，以量化指标可能会忽视的方式封装了软件开发工艺。然而，与任何艺术形式一样，专家判断也会受到其实践者的怪癖的影响。它很容易受到个人偏见和人类判断固有的可变性的影响。

类比估计（或历史数据）

历史数据估计，也称为类比估计，是一种通过回顾过去的项目来为未来项目提供估计的技术。这类似于凝视后视镜来导航前方的道路。

此方法涉及推断以前类似项目的经验和结果，并将其与当前项目进行比较。通过这样做，它提供了一个经过现实世界结果调整的扎根视角，为估计提供信息。

其有效性取决于其经验基础，过去的事件通常为未来的事业提供可靠的预测。然而，现有历史数据的质量和相关性是关键因素。

不匹配的比较或过时的数据可能会导致项目误入歧途，这凸显了仔细数据管理和谨慎实施的重要性 [6]。

Delphi 技术

该方法的名字来源于古老的德尔福甲骨文，它协调了专家们的和谐融合。德尔菲法是一种旨在通过收集专家组的匿名见解和预测来达成共识的方法[7]。

这种方法促进了集体智慧的研讨会，而不是依赖单一的观点。通过迭代轮次的反馈，根据集体输入对估计进行细化和重新校准。

德尔菲法是一种结构化且动态的过程，可以过滤掉异常值并趋向于更加平衡的集体判断。它本质上是迭代的，并强调匿名性，以减少群体思维和影响力偏见的潜在陷阱。

这提供了一个让每个专家的声音都能找到应有共鸣的环境。然而，德尔菲法需要细致的引导和耐心，因为它需要经过多轮审议才能达成共识。

基于人工智能的方法

SCE 中的机器学习

在快速发展的软件成本估算领域，机器学习 (ML) 成为变革的强大预兆 [8]。机器学习摆脱了传统方法的确定性限制，深入研究概率领域，利用大量历史数据来挖掘隐藏的模式和相关性。

通过对不同项目数据集进行训练，机器学习算法提高了预测能力，适应了经常被严格的基于规则的系统忽视的细微差别。这种适应性使机器学习成为动态软件生态系统中特别有效的工具，其中项目范围和挑战不断变化。

但是，ML 在 SCE 中的有效性取决于训练数据的质量和全面性。稀疏或有偏差的数据集可能会导致算法误入歧途，这凸显了稳健的数据管理和验证的重要性。

神经网络

神经网络 (NN) 深入研究计算建模的复杂神经通路，证明了人工智能的仿生愿望。神经网络的结构模仿人脑的神经元复杂性，部署节点和连接的分层架构来处理和解释信息。

在软件成本估算领域，神经网络从历史数据中编织出复杂的模式，捕获传统模型通常难以捉摸的非线性关系 [9]， [10]。它们的深度学习能力，尤其是随着多层架构的出现，为 SCE 的复杂数据集带来了巨大的希望。

然而，赋予神经网络强大功能的深度有时也会使它们笼罩在不透明之中。它们的“黑匣子”性质，加上容易过度拟合，需要进行细致的培训和验证，以确保可靠的估计。此外，最近发现的“Grokking”表明该领域可能会产生令人着迷的新发现[11]。

遗传算法

遗传算法 (GA) 从生命的本质中汲取灵感，将进化原理转移到计算画布上。 GA 将软件成本估算视为优化难题，通过模仿自然选择、交叉和突变的过程寻找最合适的解决方案。

通过启动不同群体的估计策略并通过进化周期迭代地完善它们，GA 收敛到更优化的估计模型。它们固有的适应性和探索性使它们非常适合充满局部最优的 SCE 景观 [12]。

然而，GA 的随机本质意味着它们的结果虽然通常稳健，但可能并不总是保证运行之间的绝对一致性。其进化参数的校准对于在探索和开发之间取得平衡仍然至关重要。

敏捷估算技术

敏捷方法最初是为了解决传统软件开发流程的挑战而制定的，它引入了项目管理和产品交付方式的范式转变。

这种方法的重要组成部分是开发的迭代性质以及对跨职能团队之间协作的重视。这种协作方法扩展到敏捷中的估计过程。

敏捷估算技术不是试图从一开始就预见项目的整体复杂性，而是旨在随着团队收集更多信息而不断发展和适应信息。

故事点

许多敏捷团队不是用几小时或几天来估计任务，而是使用故事点来估计用户故事所需的相对工作量。故事点考虑任务的复杂性、风险和工作量。

通过关注相对工作量而不是绝对时间，团队可以避免由于不可预见的挑战或依赖而导致低估或高估的陷阱。经过几次迭代，团队形成了一种对其“速度”的感觉——他们在一次迭代中完成的故事点的平均数量——这有助于预测[13]。

规划扑克

最流行的敏捷估算技术之一是规划扑克。团队成员（通常包括开发人员、测试人员和产品所有者）协作估算特定任务或用户故事所需的工作量。

使用一组具有预定义值（通常是斐波那契数列）的卡片，每个成员选择一张代表他们的估计的卡片。同时亮牌后，讨论估计的差异，从而达成共识[14]、[15]。

规划扑克的美妙之处在于它能够结合个人专家的意见并得出反映整个团队集体智慧的估计。该过程还揭示了潜在的挑战或不确定性，从而做出更明智的决策。

持续重新评估

敏捷估算的一个标志是它的迭代性质。当团队进行冲刺或迭代时，他们会根据新的知识和之前周期中花费的实际工作不断重新评估和调整他们的估计。随着项目的进展，这种迭代反馈循环可以实现更准确的预测[14]。

混合模型方法

我们的目标是提出一种结合了专家判断和算法方法的新颖模型。在考虑专家方法时，值得注意的是，它可能涉及主观评估，可能会在不同专家之间表现出不一致。

此外，它对专家经验和可用性的依赖有可能由于认知启发法和过度依赖最近的经验而引入偏差。

另一方面，算法方法可能需要大量的专业知识才能正确应用，并且可能关注某些参数，例如行数代码，可能不相关。

因此，这里的目的是提出一个独立于编程语言并考虑多种因素的模型，例如项目、硬件和人员属性。

任务离散化

在不断发展的软件工程领域，任务离散化实践已成为牢固的支柱[16]。这种方法强调将较大的软件目标分解为可管理的小型单元的重要性。

通过承认软件组件固有的谨慎性（从屏幕和 API 到 SQL 脚本），有条理的分解成为了实际需求 [17]。这种方法允许您在由一致元素组成的一致模块中定义软件。拥有同质的估算元素至关重要，这样估算团队就能轻松了解他们正在估算的内容，并避免适应这些元素。这些元素在本文中将被称为“任务”。

此外，在个人级别处理任务可以提高准确性，而它提供的详细信息可以提高灵活性，从而允许进行迭代调整以适应项目不断变化的需求.

这种方法保证了每个组件的独特特征得到适当且独立的考虑。这种离散化方法有几个优点。在个人层面上处理任务可以提高准确性，而它带来的粒度可以提高灵活性，从而实现迭代调整，以满足项目的流动需求。

相反，对每项任务的复杂性的详细理解可以实现谨慎的资源分配和微调技能到最需要的地方。然而，这种详细程度并非没有缺点。

尽管提供了准确性，但将任务解构为其组成部分可能会导致管理方面的挑战，特别是在大型项目中。忽略某些任务的可能性（尽管很小）却始终存在。此外，过于详细的方法有时会掩盖更广泛的项目目标，导致决策延迟，这通常被称为“分析瘫痪”。

双因素资格体系和努力量计算任务离散化

通过描述具有同质属性的任务，必须确定分配适当工作量的通用决定因素。

经过仔细审查，我们发现了两个关键因素：复杂性和体积 [1]、[18]。

复杂性是衡量任务执行所需技术敏锐性的一个指标。例如，在用户界面中，动态表的合并可能会保证将任务分类为由于其复杂的要求而具有高复杂性。

体积测量描述了所涉及的工作量或数量。为了说明这一点，在用户界面的上下文中，广泛的 40 字段表单的存在可能表明由于其组件的庞大规模而具有大量体积的任务。

复杂度和体积均位于区间[1 − 5] 且必须为整数。现在我们将定义 Effort (E)，其计算方式如下：

E = C ∗V

其中 C 是复杂度，V 是体积。我们在此计算中使用乘法，以便在高复杂性和高体积之间建立联系。这使我们能够在两个评估标准同时增加时考虑潜在风险，同时保持系数较低的任务的准确性。通过使用 C 和 V 两个区间的简单乘积，我们获得 E 的以下可能性：

[1, 2, 3, 4, 5, 6, 8, 9, 10, 12, 15, 16, 20 , 25]

算盘系统

现在已经获得了工作量，可以为每个工作量值确定相应的天数。此阶段非常关键，需要了解目标架构和技术的专家进行干预。

但是，该模型允许这一关键资源在建立这些值时仅干预一次。

算法的使用

为了建立这些值，我们建议使用一种算法来提高准确性并防止错误。
它可用于模拟数据集使用三个不同的模型和两个起始标准：

• 最大天数（与 25 的努力相关联）
• 值之间的间隙填充

我们利用三种不同的模型，使专家和评估团队能够从可能产生不同特征（例如精度、风险）的不同曲线轮廓中进行选择评估和填充尺寸，以理想地适应要求。假设了三种不同的数学模型来解释这种关系：线性、二次和指数。每个模型都假设了一种独特的“努力到天”的转变行为：

• 线性模型假设工作量与天数之间成正比。
• 二次模型利用多项式数学设想加速增长率。
• 指数模型预测呈指数级增长，意味着更高的努力值会急剧上升。

可以调整这些模型以更准确地满足估计要求。最终我们得到如下代码：

将 numpy 导入为 np
将 matplotlib.pyplot 导入为 plt
import pandas as pd # 导入pandas进行表格显示
# 固定努力值
努力 = np.array([1, 2, 3, 4, 5, 6, 8, 9, 10, 12, 15, 16, 20, 25])
＃ 参数
最大天数 = 25
步骤_天数 = 0.25
def 线性模型（努力，最大努力，最大天数，步骤天数）：
 斜率 = (max_days - step_days) / max_effort
 返回斜率 * 努力 + step_days - 斜率
defquadratic_model（努力，最大努力，最大天数，步骤天数）：
 规模 = (max_days - step_days) / (max_effort + 0.05 * max_effort**2)
 回报率 *（努力 + 0.05 * 努力**2）
def指数模型（努力，最大努力，最大天数，步骤天数）：
 调整后的最大天数 = 最大天数 - 步长天数 + 1
 基数 = np.exp(np.log(调整后的最大天数) / 最大努力量)
 返回step_days + 基础 ** 努力 - 1
def logarithmic_model(工作量, max_effort, max_days, step_days):
 规模 = (max_days - step_days) / np.log(max_effort + 1)
 返回比例 * np.log(努力 + 1)
# 四舍五入到最近的步长
def round_to_step(值, 步骤):
 返回回合(值/步数) *步数
Linear_days = np.array([round_to_step(线性模型(e,尽力[-1],Max_days,Step_Days),Step_Days) for e in尽力])
Quadratic_days = np.array([round_to_step(quadratic_model(e,尽力[-1],Max_days,Step_Days),Step_Days) for e in尽力])
exponential_days = np.array([round_to_step(exponential_model(e,尽力[-1],Max_days,Step_Days),Step_Days) for e in尽力])
logarithmic_days = np.array([round_to_step(logarithmic_model(e,尽力[-1],Max_days,Step_Days),Step_Days) for e in尽力])
＃ 阴谋
plt.figure(figsize=(10,6))
plt.plot（努力，线性天数，标签=“线性模型”，标记='o'）
plt.plot（努力，quadratic_days，label =“二次模型”，marker ='x'）
plt.plot（努力，exponential_days，label =“指数模型”，marker ='。'）
plt.plot（努力，logarithmic_days，标签=“对数模型”，marker='+'）
plt.xlabel("努力")
plt.ylabel("天数")
plt.title(“天数估计模型的工作量”)
plt.图例()
plt.网格（真）
plt.show()
# 以表格形式显示数据
df = pd.DataFrame({
 ‘努力’：努力，
 '线性模型（天）'：线性_天，
 '二次模型（天）'：quadratic_days，
 '指数模型（天）'：exponential_days，
 '对数模型（天）'：logarithmic_days
})
显示（df）

清单 1. 天生成模型代码，Python

模拟

现在让我们看一下图表生成的实际示例。如代码中所述，基本参数“Step Days”和“Max days”已分别设置为 0.25 和 25。下面列出了使用这些参数的三个模型生成的结果。

<图>
<源尺寸=“（最小分辨率：4dppx）和（最大宽度：700px）50vw，（-webkit-min-device-pixel-ratio：4）和（最大宽度：700px）50vw，（最小分辨率：3dppx）和（最大宽度：700px）67vw，（-webkit-min-device-pixel-ratio：3）和（最大宽度：700px）65vw，（最小分辨率：2.5dppx）和（最大宽度：700px）80vw，（-webkit-最小设备像素比：2.5）和（最大宽度：700px）80vw，（最小分辨率：2dppx）和（最大宽度：700px）100vw，（-webkit-最小设备像素比：2）和（最大宽度：700px）100vw，604px“srcset =”https://miro.medium.com/v2/resize：fit：640/format：webp/1 * o3FKHI6YuooRILW6C24cuw .png 640w，https://miro.medium.com/v2/resize:fit:720/format:webp/1*o3FKHI6YuooRILW6C24cuw.png 720w，https://miro.medium.com/v2/resize:fit:750 /格式：webp/1*o3FKHI6YuooRILW6C24cuw.png 750w，https://miro.medium.com/v2/resize:fit:786/format:webp/1*o3FKHI6YuooRILW6C24cuw.png 786w，https://miro.medium.com /v2/resize:fit:828/format:webp/1*o3FKHI6YuooRILW6C24cuw.png 828w，https://miro.medium.com/v2/resize:fit:1100/format:webp/1*o3FKHI6YuooRILW6C24cuw.png 1100w，https ://miro.medium.com/v2/resize:fit:1208/format:webp/1*o3FKHI6YuooRILW6C24cuw.png 1208w" type="image/webp"/>
<源data-testid =“og”尺寸=“（最小分辨率：4dppx）和（最大宽度：700px）50vw，（-webkit-min-device-pixel-ratio：4）和（最大宽度：700px） ）50vw，（最小分辨率：3dppx）和（最大宽度：700px）67vw，（-webkit-min-device-pixel-ratio：3）和（最大宽度：700px）65vw，（最小分辨率：2.5 dppx）和（最大宽度：700px）80vw，（-webkit-min-device-pixel-ratio：2.5）和（最大宽度：700px）80vw，（最小分辨率：2dppx）和（最大宽度：700px ) 100vw, (-webkit-min-device-pixel-ratio: 2) 和 (最大宽度: 700px) 100vw, 604px" srcset="https://miro.medium.com/v2/resize:fit:640/ 1*o3FKHI6YuooRILW6C24cuw.png 640w，https://miro.medium.com/v2/resize:fit:720/1*o3FKHI6YuooRILW6C24cuw.png 720w，https://miro.medium.com/v2/resize:fit:750/ 1*o3FKHI6YuooRILW6C24cuw.png 750w，https://miro.medium.com/v2/resize:fit:786/1*o3FKHI6YuooRILW6C24cuw.png 786w，https://miro.medium.com/v2/resize:fit:828/ 1*o3FKHI6YuooRILW6C24cuw.png 828w，https://miro.medium.com/v2/resize:fit:1100/1*o3FKHI6YuooRILW6C24cuw.png 1100w，https://miro.medium.com/v2/resize:fit:1208/ 1*o3FKHI6YuooRILW6C24cuw.png 1208w"/>

图 1：天数估算模型的工作量 – 数据

下面是这些结果的图形表示：

图 2：天数估计模型的工作量 – 图形表示

该图使我们能够区分三个模型之间“压缩”的变化，这将产生不同的特征，包括最小力的准确性或值之间的强关联。

大型遗留迁移项目中的特定用例

现在已经描述了模型，下面将在迁移项目的背景下提出具体的应用程序。人们相信，该模型非常适合此类项目，在此类项目中，团队面临着似乎不适合现有标准模型的情况，如第一部分中所述。

SCE 在旧版迁移中的重要性

迁移项目通常会受到成本的影响。迁移需求通常是由以下因素引起的：

• 更频繁的回归和副作用
• 难以 为过时的技术找到新资源
• 专业知识专注
• 集成新功能的复杂性
• 性能问题

上面列出的所有潜在原因都会增加成本和/或风险。可能有必要考虑有问题的技术构建模块的迁移。实施主要取决于所产生的成本，需要准确的估计[19]。

但是，重要的是要认识到，在组织的迁移过程中，技术变化必须伴随着人员和组织的调整。

通常，在定义目标架构和技术后，组织可能缺乏这些领域的必要专家。这可能会使“专家判断”方法变得复杂。算法方法似乎也不合适，因为它们需要知识和掌握，但也不一定考虑迁移在重绘要迁移的组件方面可能需要的所有微妙之处。

此外，初始代码行数并不始终是可靠的标准。最后，基于人工智能的方法似乎仍处于形成阶段，对于这些组织来说实施和掌握可能具有挑战性。

这就是为什么我们的模型看起来合适，因为它使现有团队能够量化工作量，然后向目标技术专家寻求建议创建估计值，从而获得准确的数字。值得注意的是，这种估计仅涵盖开发本身，而忽略了规范阶段和相关的基础设施
成本。

混合模型的应用

我们将概述实施我们的估计模型的整个过程。该过程包括三个阶段：初始化、估计和最终确定。

初始化

在此阶段，必须首先解构要估计的技术构建块。它需要被分解为一组统一的任务。

例如，具有调用 AS400 数据库的 GWT 前端的应用程序可以分为两个主要集合：

• 前端：任务由屏幕表示。
• 后端：任务由 API 表示。

然后我们可以组建估算团队。它不需要是目标技术的技术专家，但应该由现有项目的资源组成，最好是技术/功能对，他们可以评估每个任务与两个愿景的互补性。

该团队将能够开始列出离散化过程中确定的主要程序集的任务。

估计

我们现在有一个团队准备为要识别的任务集分配复杂性和体积值。在进行此关联工作的同时，我们可以开始设置与工作相关的天数的值。

这项工作可能需要目标技术方面的专家以及评估团队的成员来量化一些基准值，专家在此基础上可以进行批判性的审视并将结果扩展到整个图表。

在此阶段结束时，我们有一个天数/工作量对应算盘以及具有相关工作量值的任务列表。

最终确定

最后一步是使用算盘计算工作量和天数之间的换算，以获得总天数。获得工作量值列表后，可以
使用以下标准进行风险分析：

• 努力概率密度曲线的标准差
• 分析组件的某些“区域”是否集中高努力值
• 工作量值大于 16 的任务数量

根据这些标准，可以在限制区域采取具体措施。

结果和发现

最后，我们得出以下流程，它提供了专家判断和算法分析之间的混合形式化。

该方法似乎特别适合迁移项目的需求，利用可访问的资源，并且不需要高水平的专业知识。

图 3：混合模型的完整流程

根据元素的性质，另一种表示形式可能如下：

图 4：混合模型的完整流程

结论

总之，我们的模型提供了一种实用且灵活的方法来估算大型遗留迁移项目所涉及的成本。

通过将专家判断要素与结构化算法分析相结合，该模型解决了迁移过时或复杂系统所带来的独特挑战。< /p>

它认识到准确衡量工作量和成本的重要性，不仅考虑技术方面，还考虑所需的人力和组织转变。

三阶段过程 – 初始化、估算和最终确定 – 确保全面评估，从将项目分解为可管理的任务到执行详细的风险分析。这种混合模型对于面临艰巨的迁移任务的团队特别有益，它提供了做出明智决策并有效为过渡做好准备的途径。

通过这种方法，组织可以应对错综复杂的迁移，确保更顺利地过渡到现代、更高效的系统。

根据所提出的讨论和调查结果，很明显，遗留迁移项目提出了一系列独特的挑战，而这些挑战无法通过仅使用传统的软件成本估算方法。

所提出的混合模型可以作为更具启发性的专家判断方法和更结构化的算法分析之间的一座有前途的桥梁，提供平衡和自适应解决方案。该模型的主要优势在于其适应性以及利用目标技术方面的机构知识和特定专业知识的能力。

此外，该模型能够将问题解构为一组统一的任务，并以适当的粒度进行估计，从而确保了其在各种情况下的相关性应用场景。虽然混合模型的当前实施显示出潜力，但未来的研究和改进可以进一步推动其实用性：

• 经验验证：与所有模型一样，对不同迁移项目集的经验验证至关重要。这不仅可以验证其有效性，还可以提高其准确性。
  （我们已经在努力。）
• 与 AI 集成：尽管基于 AI 的软件成本估算方法仍处于萌芽阶段，但其潜力不容忽视。混合模型的未来迭代可以集成机器学习以增强预测，特别是当可以使用过去项目的大型数据集时。
• 改进风险分析：建议的风险分析标准提供了坚实的起点。然而，更复杂的风险模型（考虑了移民项目固有的不可预见的复杂性和不确定性）可以集成到模​​型中。
• 工具和自动化：开发能够半自动化所描述流程的工具将使模型更易于访问和采用按组织划分。

总之，混合模型在软件成本估算领域取得了显着进步，尤其是对于遗留迁移项目。然而，与所有模型一样，它是一个不断发展的实体，持续改进只会增强其适用性和有效性。

参考文献

[1] 巴里·W·博姆。 软件工程经济学。 IEEE 软件工程汇刊，SE-7(1):4–21，1981。

[2] Barry W. Boehm、Chris Abts、A. Winsor Brown、Sunita Chulani、Bradford K. Clark 、埃利斯·霍洛维茨、雷·马达奇、唐纳德·J·雷弗和伯特·斯蒂斯。 未来软件生命周期流程的成本模型：Cocomo 2.0。软件工程年鉴，1(1):57–94，2000。

[3] 国际功能点用户组 (IFPUG)。 功能点计数实践手册。 IFPUG，2000。FPCPM。

[4] L.H.普特南。 宏观软件规模调整和估计问题的一般经验解决方案。 IEEE 软件工程汇刊， 4:345–361，1978 年。

[5] R.T.休斯. 专家判断作为一种估计方法。信息和软件技术，38(2):67–75, 1996。