COCOMO 模型详解：公式、类型与软件成本估算

是否有人问过您一个软件项目需要多长时间，而您发现自己最好的回答基本上只是猜测？

20 世纪 70 年代，多数团队进行软件工程成本估算的方式就是如此。项目经常超支、延期，且主要依赖专家判断和粗略类比的方法在系统规模和复杂度不断增长时并不可靠。

COCOMO 正是为了解决这个问题而建立的，其全称为 COnstructive COst MOdel。Barry W. Boehm 在 1981 年的著作《软件工程经济学》中提出了该模型，用真实项目数据而非直觉来建立公式。它成为该领域最广为教授的算法估算模型之一。Boehm 于 2022 年 8 月去世，他花了数十年时间打磨其中的思想。

在本教程中，我将带您了解该模型的工作原理、不同类型与层级的含义，并通过一个完整的数值示例，让这些数字在实践中更容易理解。

什么是软件工程中的 COCOMO 模型？

COCOMO 是一种参数化的软件成本估算模型。它只需要一个主要输入，即以千行代码（KLOC）计的软件项目规模估计值，并据此预测三件事：总工作量（人月，PM）、开发时间（月）以及所需人数。

该模型假设项目规模是工作量的主要预测因子。Boehm 通过对真实历史项目数据进行回归分析来确定模型中的常数。

需要说明的是，COCOMO 并不直接估算货币成本，它估算的是工作量。要把人月转换为货币，您需要乘以组织内每人月的平均劳务成本。模型给出工作量，费率由您提供。

为什么要开发 COCOMO 模型

Boehm 当时在 TRW 航空航天担任软件研究与技术总监，问题既迫切又现实。根据美国工程院后来发表的一篇纪念文所述，TRW 的一位副总裁在审阅一次软件竞标后对 Boehm 说：“我再也不想仅凭信任就签署任何软件投标。去发明一种可信的方法来估算软件产品的开发成本。”

这一要求催生了 COCOMO。Boehm 研究了 TRW 已完成的 63 个项目，规模从 2,000 到 100,000 行代码不等，语言涵盖从汇编到 PL/I，且都基于瀑布模型开发。对该数据集进行回归分析得出了 COCOMO I 所用的常数，模型于 1981 年公开发布。

COCOMO 模型公式及其工作原理

一旦理解了各个术语代表的含义，基础版 COCOMO I 背后的数学就很简单。

工作量公式为：

其中，工作量以人月计，KLOC 为以千行代码计的软件规模估计值， a 和 b 是依赖于项目类型的常数。

开发时间公式基于工作量估计：

常数 d 随模式变化，而 c 在三种模式中固定为 2.5。许多教程错误地暗示四个常数都会变化。一旦得到 Effort 和 后，您就可以估算平均所需人数：

下表显示了基础版 COCOMO I 的已验证常数：

此处的关键变量是 b。对于有机型项目，b = 1.05，表示工作量随项目规模近似线性增长。对于嵌入式项目，b = 1.20，意味着明显的规模不经济：将嵌入式项目规模加倍，所需工作量会超过两倍。

COCOMO 模型类型（COCOMO I）

COCOMO I 将软件项目划分为三种开发模式。每种模式反映了团队经验、项目复杂度与运行约束的不同组合。您选择的模式决定了公式中使用的常数。

需要首先说明：这三种模式仅适用于 COCOMO I。COCOMO II（2000 年更新版）用不同的方法取而代之。

三种 COCOMO I 模式的可视化对比。图作者自制。

这三种模式沿着复杂度与约束不断增强的尺度排列。您的项目类型与团队背景通常会清楚地指向其中一种。

有机型（Organic）模式

有机型适用于小到中等规模的项目，团队对应用领域经验扎实，需求相对清晰，且没有显著的硬件约束或监管要求带来的外部压力。工资发放系统、数据处理应用或库存管理工具通常属于这一类。

由于团队经验丰富、领域熟悉，随着项目增长，沟通开销仍能保持较低。这就是为什么 b 指数在三种模式中最小。

半分离型（Semi-detached）模式

半分离型处于中间位置。此类团队成员经验参差不齐：部分人员对领域非常熟悉，其他人则不然。项目复杂度中等，可能需要与新硬件或外部系统进行一定交互。

常见示例包括编译器开发、事务处理系统以及中层业务应用。此处的规模不经济更为明显，b = 1.12。

嵌入式（Embedded）模式

嵌入式模式适用于具有严格运行约束的项目：苛刻的硬件要求、实时处理需求、监管标准，或航天与国防要求。团队可能规模庞大且技术精湛，但随着项目规模增加，集成、测试与验证的复杂性会使工作量急剧上升。

当 b = 1.20 时，嵌入式项目在三种模式中具有最陡的规模不经济。嵌入式模式也不以项目规模划分，即便系统较小，只要在严苛约束下运行也属于此类。

基础版 vs. 增强版 vs. 详细版 COCOMO

除三种项目模式外，COCOMO I 还有三个估算细化层级。模式决定使用哪些常数；层级决定对项目建模的深度。每个层级在前一层的基础上增加更多因素，从而提升准确性，但需要更多输入数据。

可以将其看作一个光谱：基础版 COCOMO 能快速给出大致范围，而详细版 COCOMO 则支持精确到各阶段的规划。

按估算细化深度划分的 COCOMO I 层级。图作者自制。

沿着金字塔向下，会引入更多因素，提高准确性，但也需要更多初始输入数据。

基础版 COCOMO

基础版只使用 KLOC 的项目规模和项目模式。您输入 KLOC，应用所选模式的常数，即可得到工作量估算。适用于早期可行性评估，当时尚无团队或开发环境的详细信息。

增强版 COCOMO

增强版 COCOMO 引入了工作量调整因子，通常记为 EAF。完整的成本驱动因子乘数列表记录在《COCOMO II 模型定义手册》中。工作量公式变为：

其中 EAF 为 15 个成本驱动因子的乘积，每个因子按“很低”到“特别高”的等级评定。这些因子分为四类：产品属性（可靠性、复杂度、数据库规模）、硬件属性（执行时间与存储约束）、人员属性（团队经验与能力）以及项目属性（工具、进度压力与开发实践）。

关于增强版 COCOMO 有一点需要了解： a 常数与基础版不同。有机型下 a 变为 3.2（非 2.4）。半分离型保持 3.0。嵌入式降低为 2.8。 b、c 与 d 指数在基础版与增强版之间保持一致。

人员类成本驱动因子呈反向：能力越强，乘数越小，从而降低工作量估算。经验丰富的程序员团队完成项目所需的人月确实少于初学者团队。

详细版 COCOMO

详细版（有时称高级版）在各个阶段层面而非整个项目层面应用工作量乘数。这意味着需求分析、详细设计、编码以及集成与测试的成本驱动因子会分别评估。

这是最精确的层级，同时也是最耗时的。适用于大型项目，不同团队负责不同阶段，并且阶段间的工作量分布对规划很重要。

COCOMO II：现代版本

到了 20 世纪 90 年代中期，COCOMO I 已显老旧。软件开发从大型机上的瀑布式项目转向面向对象编程、可复用组件库、快速原型与分布式桌面系统。将 70 年代的项目数据应用到 90 年代的软件环境会产生不可靠的估算。

Boehm 及其在南加州大学软件工程中心的同事们花了数年时间从零重建模型。成果是 COCOMO II，于 2000 年出版在《使用 COCOMO II 进行软件成本估算》一书中，并基于 161 个项目的数据进行校准，超过原模型 63 个项目的两倍。

COCOMO II 背后的动因包括面向对象与基于组件的开发、软件复用与商用现成组件集成、迭代与螺旋开发模型，以及现代工具链。需要澄清的一个常见误解：COCOMO II 并非为敏捷开发而构建。我们今日所知的敏捷在 1995–2000 年模型开发期间几乎尚未成形。

COCOMO II 的三个子模型

COCOMO II 提供三个子模型，分别适用于项目生命周期的不同阶段。

应用组装模型（Application Composition Model）面向早期原型阶段，尤其是在使用 GUI 构建器和组件库时。它以对象点（Object Points）为度量：对界面、报表与第三代语言组件按复杂度加权，并根据预期复用进行调整。该模型是线性的，不包含规模因子或指数调整。

早期设计模型（Early Design Model）用于架构尚未确定之前。它以未经调整的功能点为输入，并通过特定语言的转换表将其转为等效源码行数，同时应用七个成本驱动因子。当您知道系统该做什么、但尚不清楚如何构建时，它能给出合理估算。

后架构模型（Post-Architecture Model）三者中最为严谨。在软件架构确定后使用，以千行源码（KSLOC）或功能点为输入，包含 17 个成本驱动因子与 5 个规模因子。工作量公式为：

其中 E 为动态指数，计算方式为：

进度公式为：

其中：

常数 2.94、0.91、3.67 和 0.28 源自 COCOMO II.2000 的校准。一些旧资料引用 2.5 而非 2.94；那是 2000 年前的校准值，不应与当前模型混用。位于 softwarecost.org 的USC COCOMO II Web Tool 是后架构模型的免费在线实现，若您不想手工计算可直接使用。

COCOMO 中的成本驱动因子与规模因子

让 COCOMO II 与 COCOMO I 不同的两个机制是：规模因子与成本驱动因子。它们各自的作用如下。

在 COCOMO I 中，指数 b 由模式固定：选择有机型、半分离型或嵌入式，即得到预设数值。COCOMO II 用五个连续评定的规模因子替代，通过对它们的评分来计算指数。

COCOMO II 的五个规模因子是先例性（PREC）、开发灵活性（FLEX）、架构与风险化解（RESL）、团队凝聚力（TEAM）和流程成熟度（PMAT）。每项按“很低”到“特别高”评分，其合计决定工作量公式中的 E。更高的合计意味着项目不成熟、不熟悉且更具风险，因此指数更高、工作量更大。

规模因子影响的是工作量曲线的形状。相较之下，成本驱动因子是对基线工作量的乘法性调整。COCOMO II 的后架构模型包含 17 个成本驱动因子，而增强版 COCOMO I 为 15 个。COCOMO II 新增了诸如所需可复用性（RUSE）、文档要求（DOCU）、平台易变性（PVOL）、人员稳定性（PCON）、应用经验（APEX）、平台经验（PLEX）、语言与工具经验（LTEX）以及多地点开发（SITE）等因素。

值得强调的一个成本驱动因子是 SCED（进度要求）。如果大幅压缩进度，其乘数会高于 1.0，表示为了更快完成反而需要更多人月。这与大多数工程师的经验一致：强行冲刺会带来协调开销、错误与返工，往往比节省的时间更“昂贵”。

COCOMO 模型的优势

该模型的主要优势在于透明性。与专有估算工具不同，COCOMO 公开其全部方程、常数与校准方法。任何人都能审计输入并验证输出。这使其在政府、国防与航天的采购中颇为有用，在这些场景中，数学可审计性往往是法律或合同要求。

该模型也可再校准。收集自身项目历史数据的组织可以调整常数，以反映其特定环境、团队构成与技术栈。这一点很重要，因为默认常数来自数十年前的数据集。

三级结构（基础 → 增强 → 详细）也是一大实际优势。项目早期信息有限时，使用基础版获得粗略估算。随着项目成熟、对团队与环境了解加深，再使用增强版或详细版做更精细的规划。

COCOMO 模型的局限

最大局限在于 COCOMO 对 KLOC 的依赖。要使用 COCOMO，您需要在开工前就以代码行数估算项目规模。而在项目早期——恰是估算最关键的阶段——要准确做到这一点非常困难。

即使 KLOC 可估，COCOMO I 的常数来自 1968–1979 年间在瀑布模型下构建的 63 个项目；COCOMO II 的常数来自 90 年代的 161 个项目。两者都未包含云原生系统、移动应用、微服务架构或现代 DevOps 流水线。未经本地校准，直接将这些常数用于现代项目，会产生不可靠的估算。

一项 2025 年的研究给出了量化结果：将未校准的基础版 COCOMO 应用于 NASA 的项目数据集，平均相对误差约 100%，且无一预测落在实际工作量的 ±25% 范围内。误差幅度并不小，这反映的是模型在超出其适用条件的情境中被使用。

该模型也不善于处理迭代式开发。COCOMO 假设相对顺序的生命周期。敏捷团队在短冲刺中工作、任务清单不断演化，与 COCOMO 根植的瀑布式假设并不匹配。

还有一个更深层的问题。2026 年 3 月发表于《人工智能前沿》期刊的一篇论文认为，COCOMO II 与 AI 辅助软件开发从结构上存在根本错位，不仅仅是校准问题。当 AI 编码工具生成了代码库的相当部分时，KLOC 作为人为工作量的代理会误导。工作量的重心转向验证、架构治理与安全审查，而这些并非 COCOMO 成本驱动框架的设计目标。

COCOMO 与其他估算技术对比

COCOMO 并非唯一选项。了解替代方案有助于您在不同情境下选择合适的方法。

功能点分析（FPA）基于用户可见的输入输出评估系统复杂度，与编程语言无关。当需求明确但尚无 KLOC 估计时表现良好。COCOMO II 的早期设计模型可接受功能点作为输入，因此二者可配合使用。

故事点是敏捷环境中的标准做法。团队按相对复杂度为用户故事评分，再跟踪速度以预测进展。其快捷且团队特异，但并不能产出采购与长期规划所需的总体成本基线。COCOMO 与故事点的用途不同。

SEER-SEM 和 SLIM 等参数化工具使用专有的校准数据库和更广泛的参数集。研究发现，它们在准确性上优于未校准的 COCOMO II。COCOMO 的优势在于透明与开放，可用于学术或需审计的场景。

基于机器学习的估算是活跃的研究方向。2026 年 1 月的一项研究发现，将随机森林、支持向量回归与神经网络结合的集成模型在敏捷项目数据上，四项标准评估指标均优于 COCOMO 家族模型。这些方法会适应其训练数据，而非依赖数十年前确定的常数。

COCOMO 模型示例（完整计算）

了解 COCOMO 在其他方法中的位置很有帮助，但理解其实际工作方式的最佳途径是跑一遍数字。下面以有机型模式、项目规模估计为 50 KLOC，演示一次完整的基础版 COCOMO I 计算。

有机型模式的常数为： a = 2.4，b = 1.05， c = 2.5，d = 0.38。

步骤 1：计算工作量

要计算 50^1.05，可利用如下事实：。

步骤 2：计算开发时间

步骤 3：计算所需人数

总结：

有两点值得注意。人月与日历月是不同单位：145.8 人月在 16.6 个日历月内完成，意味着约 9 人并行工作。且由于这是基础版 COCOMO，它只使用规模与模式。通过 EAF 加入真实的成本驱动因子评分，会使工作量估算在此基础上上调或下调。

软件工程面试中的 COCOMO 模型

COCOMO 常出现在学术课程、大学考试，以及政府、国防与系统工程岗位的面试中。在敏捷的消费科技公司中则较少见。

最常见的问题是 COCOMO I 与 COCOMO II 的区别：前者是基于 63 个项目的固定模式与预设常数，后者则是基于更大、更新数据集的五个连续规模因子。了解这一差异、基本公式以及三种模式名称，足以覆盖大多数场景。面试官偶尔会要求做一个示例计算，因此上面的演算值得练习。

结语：COCOMO 模型仍然相关吗？

在其假设成立的地方，COCOMO 依然有用：顺序式开发、正式采购与学术研究。而当现代软件背离这些条件时，它的适用性就会下降。

项目早期可用基础版 COCOMO 做数量级检查。有了团队与环境数据后使用增强版。要在真实投标或计划中依赖任何输出之前，请先基于自身项目历史进行校准。正如在“局限”一节所述，将默认常数未经校准地应用到现代项目，会产生过大而无法据以行动的误差。

自 2015 年前后起，Boehm CSSE 一直在开发 COCOMO III，截至 2026 年 3 月尚未公开发布。1981 年的原版及其 2000 年更新仍是基准。

想进一步提升软件开发能力？我们提供关于Python 软件工程原则、使用 Cursor 进行软件开发以及使用 GitHub Copilot 进行软件开发的课程，助您将所学付诸实践。