使用 COCOMO II 模型进行软件项目成本估算






4.57/5 (17投票s)
2005年1月10日
14分钟阅读

363870

4604
描述了一个真实软件项目的简单 COCOMO II 成本估算步骤。
目录
引言
本文档提供了一个真实项目的 COCOMO II 成本估算示例,重点介绍了项目经理在进行简单成本估算和使用的工具方面所需的基本操作指南。
目标读者
本文档面向刚接触项目成本估算技术的人员,以及希望获得 COCOMO II 模型反馈的人员。我的目标是以简单的方式描述基本成本估算步骤、工具和假设,同时考虑一个真实项目,并只提供项目本身的必要细节。
示例项目描述和范围
一家生物信息学公司,提供先进的遗传信息数据挖掘方法,计划构建一个用于分析和导航生物网络的分布式应用程序。作为该项目的一部分,需要构建一个数据库提供者,该提供者向 UI 程序员公开简单的接口,并隐藏数据层的复杂性。一旦该任务的范围大致定义如此,就将其切分为一个单独的项目。本文的内容针对后一个项目的成本估算视角。
该公司已经完成了初步阶段的工作,并提供了描述项目概念的文档。客户有以下偏好:
- 将托管在 Windows 上的现有 SQL Server 数据库(约 1 GB)迁移到托管在 Linux 上的 PostgreSQL 数据后端。
- 使用 Java 构建此项目组件。主要组件是数据库提供者。
- 由于项目规模较小,因此不需要细化阶段(或详细设计阶段)。
- 项目有时间限制。
以上是该公司提供的项目简短范围定义。与许多项目一样,下一步是进行成本估算。
COCOMO II 估算简介
COCOMO(建设性成本模型)是一个允许软件项目经理估算项目成本和持续时间的模型。它最初(COCOMO 81)由 Barry Boehm 在二十世纪八十年代初开发2)。COCOMO II1) 模型是 COCOMO 81 的更新,旨在解决 1990 年代和 2000 年代的软件开发实践。该模型现在是一个充满活力的软件工程产物,从客户的角度来看,它具有以下特点:
- 该模型简单且经过充分测试
- 提供约 20% 的成本和 70% 的时间估算准确性
总的来说,COCOMO II 估算的项目成本直接来源于人月工作量,它假定成本基本取决于所有项目文件的总物理大小,以千行代码 (KSLOC) 为单位。估算公式形式如下:
Effort (in person-months) = a x KSLOCb
其中系数 `a` 约为 3 (2.94),规模因子 `b` 接近 1 (1.0997)。
也有类似的 COCOMO 公式用于估算项目持续时间(以月为单位)和项目团队的平均规模。有趣的是,COCOMO 中的项目持续时间大约是工作量(以人月为单位)的立方根。
实际上,COCOMO 参数可能与其实际值大相径庭。COCOMO II 对可能影响项目成本的因素进行了分类,并允许您为特定项目更准确地估算系数和规模因子。调整后的“a
”系数取值范围在 0.056 – 120 之间。有关影响第一个参数的 COCOMO II 调整因素列表,请参见附录 A。规模因子“b
”的模型驱动调整是 COCOMO II 模型中的新增内容,反映了软件工程的最新趋势。您可以在附录 B 中看到规模因子的描述。
许多项目经理习惯于在产品功能、质量和进度这三个要素之间进行权衡,通过权衡三角形和权衡矩阵来协商项目成本。如果您也是这样,您可能会好奇 COCOMO II 调整参数如何融入其中。答案是,COCOMO II 参数可以看作是两组参数。第一组是外部参数,可以大致对应权衡三角形/矩阵视图,并且其术语经常在与利益相关者协商成本时使用。第二组是 COCOMO II 内部参数,通常不能用于此目的。在这种权衡三角形/矩阵视角下,进度大致对应于 `SCED`(所需开发进度),质量对应于 `RELY`(所需可靠性),功能对应于 `CPLX`(产品复杂性)、`DATA`(数据库大小)、`TIME`(执行时间)、`DOCU`(文档与生命周期需求匹配度)以及偶尔的 `RUSE`、`STOR`、`PVOL` 参数的组合。COCOMO II 内部参数,如评估人员能力/经验、使用过的项目工具等的参数,对项目成本估算显然很重要,但通常不是与利益相关者进行成本沟通的主题。
市面上有经过充分验证的 COCOMO II 工具,它们会以自然语言向您提问,例如“开发团队的经验如何?”或“项目进度有多紧张?”,从而在后台隐藏了模型的细节。
COCOMO II 取代了 COCOMO 81、Ada COCOMO 等早期版本的 COCOMO,这些版本现在被认为已经过时。该模型通过将参数总数从原始 COCOMO 模型的 15 个减少到 7 个,简化了初步阶段的成本估算,并建议在初步阶段使用功能点,而在后期更精确的阶段使用 SLOC。事实上,COCOMO II 减少了使用什么项目指标(SLOC 还是功能点)的争议,使得新模型更加灵活。
与经典的 COCOMO 81 相比,COCOMO II 引入了五个规模因子,其中至少有三个直接与 PM 活动相关,因此提高了项目管理在降低项目成本中的作用。
- 考虑组织中的过程成熟度(CMM 等级)
- 考虑在构建阶段之前项目架构存在的程度和稳定性
- 考虑关系视角:团队凝聚力,与利益相关者的关系
现在,我将演示 COCOMO II 模型中的基本估算步骤。为了进行实际估算,我将使用可以从此处下载的本项目的源代码。
如果您有项目源代码和一些项目细节,那么进行简单的成本估算就足够了。当然,在项目开始之前您还没有源代码,这种方法更像是“事后分析”。好的,这就是我的意图!这样做会丢失一些时间上的准确性,但实际成本估算会更准确。
计算项目中的 SLOC
为了进行实际估算,您首先需要弄清楚每个组件的 SLOC 数量,并将这些数量用于 COCOMO 模型。
简单地说,SLOC(单行代码)是程序中的物理代码行,但不包括注释。当然,您可以使用您喜欢的 IDE,查看状态栏以了解代码有多少行。这可能是 SLOC 的初步估算,可以接受。为了更准确,您需要排除注释和空行。虽然对于小型项目来说,这是一个简单的过程;但对于拥有数千 SLOC 和多个文件的较大项目,选择一个自动 SLOC 计数工具会是更自然的选择。
我决定使用 CodeCounter 程序进行这些估算,该程序具有友好的用户界面,并且可以计算包括 Java、C/C++、SQL(及变体)、HTML/XML 在内的多种语言的 SLOC。CodeCounter 程序可以从此处下载 30 天试用版。
该案例研究的源代码项目文件反映了在此项目中完成的四项任务:
- 创建 PostgreSQL 数据库、索引,编写 pgSQL(接近 PL/SQL)存储过程。
- 构建一个 Java 组件(由多个 JavaBean 组成),该组件封装了应用程序的基本逻辑,并作为数据库提供者。
- 构建一个 Servlet,将其视为一个单独的组件,用于将 UI 调用分派给核心 Java 组件。
- 编写简单的 HTML 页面来测试数据库提供者。
换句话说,示例项目源代码对应于用 SQL、Java 和 HTML/XML 编写的四个部分。在计数之前,最好创建与项目组件对应的单独文件夹,并将要计量的文件放在里面。
所有项目文件夹的单独 SLOC 计数结果如下:
文件夹 | 总 SLOC | |
1 | SQL 文件 | 414 |
2 | Java 数据库提供者文件 | 345 |
3 | Java Servlet | 156 |
4 | Web 文件 | 113 |
表 1。
COCOMO 通常建议使用标准的 SLOC 计数程序,这些程序可以对不同语言编写的代码进行行计数。其中一个程序是基于 C 的 CodeCount(无用户界面的命令行程序)。您可以从软件工程中心下载其源代码(您也需要自己编译!),并计算 C、C++、Java 等语言的 SLOC。CodeCount 的优点是它是免费的,并且多年来被许多公司用于代码计数。
使用 Costar 估算工具进行 COCOMO II 估算
当然,您可以直接使用 COCOMO II:选择模型、公式,确定参数值,然后手动计算项目成本。我相信这就像每年填写税务表格一样,取决于您喜欢简单的计算器还是自动化的软件工具。据说,您更喜欢(如果我错了,您可以选择跳过本节!)后者,因此,在本节中,我将介绍一个用于进行 COCOMO II 估算的特定工具。
我选择了 Costar 7.0 COCOMO II 工具,因为它拥有便捷的界面和简洁的帮助。该程序已授权给超过一百万客户。Costar 7.0 的 30 天试用版可从此处下载。
通常,您会创建一个主组件和子组件,以对应您项目的各个任务。主组件基本上充当所有其他组件的 Costar 项目根目录,并且是汇总所有估算的地方。它不应与您的项目文件相关联。您需要为每个项目任务创建子组件,并手动输入 SLOC 计数程序中的任务总 SLOC 数量。
对于这个示例项目(请参阅cocomo2.zip 中的 Costar 项目文件 costar_dbprovider.cst),我已经创建了主(根)组件和四个子组件:
db_provider
servlet
database_scripts
ui_web_testing
现在,当组件的初始状态在 Costar 项目中设置好后,我们就可以开始进行实际的 COCOMO II 估算了。尽管 COCOMO 模型中的项目总成本在很大程度上取决于总 SLOC 数量,但实际项目的调整和规模参数可以将项目成本相差数百倍。如上所述,有两种附加参数集用于使 COCOMO II 估算更准确。第一组是 17 个成本驱动因素,大部分继承自 COCOMO 81 模型;第二组是 5 个规模驱动因素,是 COCOMO II 模型中的新增项。
在实际项目中设置这些参数的方法相当直接。作为项目经理,您需要收集关于项目最重要方面的信息,例如所需的产品特性、所需的进度、所需的产品质量、项目团队的经验和能力、项目基础设施的就绪程度和成熟度。接下来是微妙的部分,即对与收集到的信息相对应的 COCOMO II 参数值做出假设。
由于我的目标是基于真实项目介绍 COCOMO II 技术和术语,因此我将仅简要描述为案例研究项目所做的假设。所有未在此处提到的 COCOMO II 参数都设置为其标称值 1。该项目具有以下特点:
规模因子和产品特性
- 已完成初步阶段,但缺乏已记录的架构,因为利益相关者认为该项目规模较小,并且没有将细化阶段作为单独的阶段。(`RESL` 规模因子非常低)。
- 开发团队熟悉软件开发方法论的基本概念,但软件过程成熟度接近 CMM 的初始阶段(描述 CMM 等级的 `PMAT` 规模因子较低)。
- 中等规模的数据库后端(约 1 GB),约有 20 个表和 100 个索引(`DATA` 成本驱动因素非常高)。
进度和人员
- 项目进度受固定时间限制,新团队成员适应环境和任务的时间有限,这意味着进度可以被认为是紧张的(`SCED` 进度参数很高)。
- 团队成员在 C/C++ 等编程语言方面经验丰富,但对 Java 开发是新手(`PCAP`,程序员能力高,而 `LTEX`,语言/工具经验成本驱动因素低)。
- 团队成员在 Windows 环境方面经验丰富,但在最新的 Linux 开发方面经验不足(`PLEX`,平台经验成本驱动因素低)。
有趣的是,COCOMO II 预测,选择经验丰富的开发团队,即使他们在语言、工具和平台方面经验不足,也会在项目中证明其价值。
PCAP
[high=0.88]xLTEX
[low=1.09]xPLEX
[low=1.09] =1.04 ~ 1 - 没有独立的分析师角色。这一因素降低了团队的分析能力。这在 COCOMO 模型中不是标准情况,该模型有一个 `ACAP` 参数来计算分析师的能力。似乎可以通过将分析师能力参数设置为较低的值(`ACAP`,分析师能力低)来考虑未填充的分析师职位。
最后,从 Costar 项目中截取的图 2 和图 3 显示了所有的 COCOMO II 成本驱动因素和规模因子及其值。
图 2。
图 3。
请注意,Costar 允许您查看用于最终成本估算的方程式,如图 4 所示。
图 4。
成本估算结果汇总
报告中展示的 COCOMO II 估算总体结果来自 Costar 项目。
图 5。
报告显示项目成本为 23,000 美元,项目持续时间为 4.6 个月(以 5000 美元作为平均月开发者工资)。
结论
本文简短地介绍了如何为示例项目进行成本估算,并概述了基本步骤、术语和工具。在小型甚至中型项目中,很容易削减在九十年代被广泛接受并在现在仍积极使用的传统开发方面。显然,临时估算容易出错。成本估算工具可以轻松地帮助您不仅明确预期的项目成本和持续时间,还可以促使您通过提供清晰、紧凑、简洁且经过大量实际项目检验的术语和方法来验证软件项目的各个基本方面,从而大大降低项目风险,并为与项目利益相关者的沟通提供合理依据。
参考文献
- “Software Cost Estimation With COCOMO II”,Prentice Hall,2000 年。
- “Software Engineering Economics”,作者:Barry Boehm,Prentice Hall,1981 年。
附录 A:成本驱动因素
影响项目成本的因素有很多。COCOMO II 模型定义了 17 个称为成本驱动因素的参数,它们对项目成本有主要影响。
项目经理可以根据项目具体情况确定成本驱动因素,并用它们来调整公式中的第一个系数。
a = 2.94 x EAF
其中 EAF(工作量调整因子)是通过将 17 个参数相乘得到的,这些参数
- 均具有标称值 1.0。
- 其中大多数参数可以具有值:非常低、低、标称、高、非常高(也可以考虑极低、极高)。
- 大多数成本驱动因素值的范围在 0.5-1.5 之间,最大值不超过最小值的 50%。有两个例外是产品复杂性(`CPLX`)和分析师能力(`ACAP`),其最大/最小值可高达 2。
- `SITE`、`RUSE`、`DOCU`、`PVOL`、`PCON`(加粗标记)等因素是 COCOMO II 的新增项,反映了 90 年代末和 2000 年代后期的软件开发趋势。
下表提供了 COCOMO II 调整因素列表。请注意,第二列显示了该案例研究项目的因素。
成本驱动因素 | 示例项目值 | 描述 | |
1 | DATA |
高 | 数据库大小。 |
2 | CPLX |
标称 | 产品复杂性。 |
3 | TIME |
标称 | 执行时间限制。 |
4 | STOR |
标称 | 主存储器限制。 |
5 | RUSE |
标称 | 所需可重用性。 |
6 | DOCU |
标称 | 文档与生命周期需求匹配度。 |
7 | PVOL |
标称 | 平台易变性。 |
8 | SCED |
非常高 | 进度因子。 |
9 | RELY |
标称 | 所需可靠性。 |
10 | 工具 |
标称 | 软件工具的使用。 |
11 | APEX |
标称 | 应用程序经验。 |
12 | ACAP |
低 | 分析师能力。 |
13 | PCAP |
高 | 程序员能力。 |
14 | PLEX |
低 | 平台经验。 |
15 | LTEX |
低 | 语言和工具经验。 |
16 | PCON |
标称 | 人员连续性。 |
17 | SITE |
标称 | 多站点开发。 |
附录 B:规模因素
规模因子是 COCOMO II 的新增项。它们会修改公式 1 中的第二个系数(系数 `b`)。规模因子的影响范围在 1.01 – 1.26 之间。第二列显示了该案例研究项目的因素。
规模因子 | 示例项目值 | 描述 | |
1 | PREC |
标称 | 先行性。 |
2 | PMAT |
CMM 等级 I(上) | 过程成熟度。 |
3 | TEAM |
标称 | 团队凝聚力。 |
4 | FLEX |
标称 | 开发灵活性。 |
5 | RESL |
较低(20%) | 架构和风险分辨率。 |