软件工程中的 COCOMO 模型

在开始新的软件项目之前，了解当今软件开发所需的时间和成本至关重要。“构造性成本模型（COCOMO）”是一种广泛用于多个软件项目的有效成本估算方法。

1981 年，Barry W. Boehm 提出了 COCOMO 模型，这是一种用于软件成本评估的程序化方法。该成本估算模型用于预测软件项目的开发工作量、平均团队规模、开发时间以及所需的工作量。这增加了模型的透明度，有助于软件经理理解模型为何能提供其估算结果。此外，最初有一个 瀑布模型 的生命周期是基于基本的 COCOMO。

本教程将涵盖 COCOMO 模型概述、其通用类型、COCOMO 基于成本估算方法的基本计算、其扩展以及相对的优缺点。

此模型中的必要步骤是

1. 通过评估数千行已交付源代码（KDLOC）来获得开发工作量的初步估算。
2. 根据项目的各种属性确定一组 15 个乘数因子。
3. 通过将初步估算与所有乘数因子相乘来计算工作量估算，即步骤 1 和步骤 2 中的值相乘。

初步估算（也称为名义估算）由静态单变量模型中使用的形式的方程确定，使用 KDLOC 作为尺寸度量。要确定以人月为单位的初步工作量 E_i，使用的方程类型如下所示：

常数 a 和 b 的值取决于项目类型。

在 COCOMO 中，项目分为三种类型

1. 有机型
2. 半独立型
3. 嵌入式

1. 有机型：如果项目涉及开发一个大家已充分了解的应用程序，开发团队的规模相对较小，并且团队成员在开发类似项目方法方面经验丰富，则可以将开发项目视为有机型。此类项目的示例包括简单的业务系统、简单的库存管理系统和数据处理系统。

2. 半独立型：如果开发团队由经验丰富的员工和经验不足的员工混合组成，则可以将开发项目视为半独立型。团队成员可能在相关系统方面有有限的经验，但可能不熟悉正在开发的订单的某些方面。半独立系统示例包括开发新的操作系统（OS）、数据库管理系统（DBMS）以及复杂的库存管理系统。

3. 嵌入式型：如果正在开发的软件与复杂的硬件紧密耦合，或者对操作方法存在严格规定，则将开发项目视为嵌入式型。例如： ATM、空中交通管制。

对于这三种产品类别，Boehm 提供了不同的表达式，用于根据 KLOC（千行代码）的估算尺寸预测工作量（以人月为单位）和开发时间。工作量估算考虑了由于假日、周末休息、咖啡休息等造成的生产力损失。

应用 COCOMO 模型的前几项技术

通过遵循以下方法，任何使用 COCOMO 模型的软件开发人员都可以确保工作流程正确，并得出最准确和最高效的成本估算。

• 利用精确的历史数据
• 修改模型以满足精确的项目要求
• 定期更新估算
• 整合项目管理工具
• 结合使用其他估算方法和当前模型来提高判断能力
• 通过使用实用措施来验证结果
• 教授团队如何使用该模型
• 并非所有假设和修改
• 定期举行评审会议
• 确保利益相关者的持续参与

根据 Boehm 的说法，软件成本估算应通过三个阶段进行

1. 基本模型
2. 中间模型
3. 详细模型

1. 基本 COCOMO 模型：基本 COCOMO 模型提供项目参数的准确尺寸。以下表达式给出了基本 COCOMO 估算模型：

                Effort=a₁*(KLOC) a₂ PM
                Tdev=b₁*(efforts)b₂ Months

其中

KLOC 是以千行代码（Kilo Lines of Code）为单位的软件产品估计尺寸，

a₁,a₂,b₁,b₂ 是每组软件产品的常数，

Tdev 是软件开发的估计时间，以月为单位，

Effort 是开发软件产品所需的总工作量，以人月（PMs）为单位。

开发工作量估算

对于三类软件产品，基于代码尺寸估算工作量的公式如下：

有机型： Effort = 2.4(KLOC) 1.05 PM

半独立型： Effort = 3.0(KLOC) 1.12 PM

嵌入式型： Effort = 3.6(KLOC) 1.20 PM

开发时间估算

对于三类软件产品，基于工作量估算开发时间的公式如下：

有机型： Tdev = 2.5(Effort) 0.38 Months

半独立型： Tdev = 2.5(Effort) 0.35 Months

嵌入式型： Tdev = 2.5(Effort) 0.32 Months

通过绘制不同软件尺寸的估算特征，可以对基本 COCOMO 模型获得一些洞察。图显示了估算工作量与产品尺寸的图。从图中，我们可以观察到工作量与软件产品的尺寸存在一定的超线性关系。因此，开发产品所需的工作量随项目规模的增加而迅速增加。

图中绘制了开发时间与 KLOC（千行代码）中的产品尺寸的关系。从图中可以看出，开发时间是产品尺寸的亚线性函数，即当产品尺寸增加两倍时，开发产品的时间不会翻倍，而是适度增加。这可以解释为，对于较大的产品，可以识别出更多可以同时进行的活动。并行活动可以由工程师同时进行。这减少了完成项目的时间。此外，从图中可以看出，开发时间对于所有三类产品大致相同。例如，无论是一个 60 KLOC 的程序是有机型、半独立型还是嵌入式型，其开发时间都约为 18 个月。

根据工作量估算，可以通过将所需工作量乘以每月的劳动力成本来获得项目成本。但是，此项目成本计算中隐含的假设是，整个项目成本仅由劳动力成本承担。除了劳动力成本外，项目还会因项目所需的硬件和软件以及公司的管理、办公室空间等间接费用而产生费用。

需要注意的是，使用 COCOMO 模型获得的工作量和持续时间估算被称为名义工作量估算和名义持续时间估算。名义一词意味着，如果有人试图在比估算持续时间短的时间内完成项目，那么成本将急剧增加。但是，如果有人在比估算时间更长的时间内完成项目，那么估算成本值几乎没有下降。

示例 1：假设一个项目估计为 400 KLOC。计算三种模型（有机型、半独立型和嵌入式型）的每个模型的工作量和开发时间。

解决方案：基本 COCOMO 方程形式为：

                Effort=a₁*(KLOC) a₂ PM
                Tdev=b₁*(efforts)b₂ Months
                Estimated Size of project= 400 KLOC

(i)有机型

                E = 2.4 * (400)1.05 = 1295.31 PM
                D = 2.5 * (1295.31)0.38=38.07 PM

(ii)半独立型

                E = 3.0 * (400)1.12=2462.79 PM
                D = 2.5 * (2462.79)0.35=38.45 PM

(iii) 嵌入式型

                E = 3.6 * (400)1.20 = 4772.81 PM
                D = 2.5 * (4772.8)0.32 = 38 PM

示例 2：有一个 200 KLOC 的项目要开发。软件开发团队在类似项目方面拥有平均经验。项目时间表不是很紧张。计算项目的总工作量、开发时间、平均人员规模和生产力。

解决方案：考虑到项目规模、时间表和开发团队的经验，半独立型是最合适的模型。

因此       E=3.0(200)1.12=1133.12PM
                D=2.5(1133.12)0.35=29.3PM

            P = 176 LOC/PM

2. 中间模型：基本 Cocomo 模型认为工作量仅是代码行数和根据各种软件系统计算的某些常数的函数。中间 COCOMO 模型认识到这些事实，并通过使用一组基于软件工程各种属性的 15 个成本驱动因素来改进通过基本 COCOMO 模型获得的初始估算。

成本驱动因素及其属性的分类

(i) 产品属性 -

• 所需的软件可靠性程度
• 应用程序数据库的大小
• 产品的复杂性

硬件属性 -

• 运行时性能约束
• 内存约束
• 虚拟机环境的易变性
• 所需的周转时间

人员属性 -

• 分析师能力
• 软件工程能力
• 应用经验
• 虚拟机经验
• 编程语言经验

项目属性 -

• 软件工具的使用
• 软件工程方法的应用
• 所需开发进度

成本驱动因素分为四类

中间 COCOMO 方程

                E=a_i (KLOC) b_i*EAF
                D=c_i (E)d_i

中间 COCOMO 的系数

3. 详细 COCOMO 模型：详细 COCOMO 包含标准版本的所有特性，并评估成本驱动因素对软件工程过程的每个方法的影响。详细模型为每个成本驱动因素属性使用各种工作量乘数。在详细的 COCOMO 中，整个软件被划分为多个模块，然后我们将 COCOMO 应用于各个模块来估算工作量，然后将工作量相加。

详细 COCOMO 的六个阶段是

1. 规划和需求
2. 系统结构
3. 完整结构
4. 模块代码和测试
5. 集成和测试
6. 成本构造模型

工作量根据程序估算确定，并且根据软件生命周期的每个阶段都给出了一组成本驱动因素。

COCOMO 扩展

即使本页面仅讨论 COCOMO I 模型（1981），您也值得对这个成功的 COCOMO 模型的扩展进行更多研究。COCOMO II（1995）是 COCOMO I 的扩展，它被用于不同的软件开发过程类别，包括 敏捷、迭代 和 螺旋瀑布 模型。

除了 COCOMO I 和 COCOMO II 模型之外，还有许多成本估算模型正在开发中，例如构造性分阶段计划和工作量模型（COPSEMO）以及构造性快速应用程序开发计划估算模型（CORADMO）。

COCOMO 模型优点

• 与其他模型（如 SLIM）不同，COCOMO 易于理解其工作原理。
• 估算人员可以通过使用驱动因素更好地理解影响项目成本的许多因素的影响。
• COCOMO 为历史项目提供建议。
• 使用 COCOMO 模型可以轻松估算项目的总成本。
• 通过驱动因素可以更容易地理解影响项目危机的许多因素的影响。

COCOMO 模型缺点

• 当项目早期需要大部分工作量估算时，估算 KDSI 具有挑战性。
• 实际上，KDSI 是长度度量而不是尺寸度量。
• 非常容易因开发模式分类不当而受到影响。
• 成功的关键因素是根据组织的需求使用历史数据来调整模型，而历史数据并非总是可用。
• 它限制了软件成本的准确性。
• COCOMO 忽略了客户的知识、能力和协作。
• 此外，敏捷侧重于快速反馈循环和利用新想法，而 COCOMO 则基于预先设计。

基于案例研究和实际应用的示例

• NASA 项目： NASA 使用 COCOMO 模型估算了多个太空探索软件项目的成本和时间表。
• 国防系统：美国国防部主要使用国防系统来保证精确的预算和及时满足软件项目需求。
• 电信：电信公司使用 COCOMO 来计算创建复杂网络管理软件所涉及的时间和成本。
• IBM： IBM 使用 COCOMO 来有效管理项目时间表、优化资源并创建广泛的企业软件系统。
• 医疗保健：在医疗保健 IT 项目中，使用 COCOMO 来规划和开发电子健康记录系统和其他关键应用程序。