高山老师：为什么要估算软件规模？

引言：一次奖金发放的困惑

刚开始从事软件开发时，我对“软件规模”这个概念完全陌生。即使在1994年被微软录取时，也未意识到软件规模的重要性。然而，2000年的一次经历，彻底改变了我对软件规模的看法。那时，我所在的安博公司经过一番努力，决定拨出一部分资金给研发团队发奖金。这个重任落在我这个工程副总和常务副总Jimmy的肩上。

问题来了，奖金应该如何分配？是根据工作能力、出勤率、职位高低，还是加班时间？如果某人对奖金数额有异议，我该如何说服他？由于缺乏衡量开发人员产出的标准，最后我们只能采取平均分配的方式。除非某位员工表现特别突出或未达标，其他人基本都拿到了相同的奖金。这种做法虽然简单，但从本质上失去了激励员工的作用。这次经历让我意识到，评估软件开发人员的工作贡献，应该有一套客观和科学的方法，而不是凭主观印象。如果当时我理解软件规模的概念，或许就能够更公平地依据开发人员的产出来发放奖金，从而更有效地激励员工多劳多得。

什么是软件规模？

正如所有事物都有其大小，软件的规模大小也可以用某种方式来衡量。就像房子的面积用平方米表示，人的体重用公斤表示，软件的大小也有其度量方法。在软件开发的早期，代码行数曾是衡量软件规模的重要指标。代码行越多，开发的工作量和时长也越大。

然而，代码行数存在局限性。首先，代码行数无法跨编程语言 — 1000行汇编代码和1000行Java代码的工作量可能相差数倍。其次，更多的代码行并不一定意味着更多功能，代码行也无法体现功能的复杂性。因此，随着时间的推移，代码行数逐渐被功能点（Function Points）取代。

功能点分析：衡量软件规模的经典方法

1979年，IBM的Allan Albrecht首次提出了“功能点”的概念，旨在克服代码行数在软件规模估算中的局限性。功能点分析基于软件系统的功能需求，考虑了软件功能的复杂性和工作量，目前已广泛应用于大规模和复杂的软件项目中。

功能点估算主要考虑两大类功能：

1、数据功能：包括内部逻辑文件（ILF）和外部接口文件（EIF）。

2、事务功能：包括外部输入（EI）、外部输出（EO）和外部查询（EQ）。

目前，国际上功能点分析方法有三大标准：IFPUG、COSMIC和NESMA。中国也在2018年根据NESMA建立了国家标准GB/T 36964-2018《软件开发成本度量规范》，并从2016年开始，每年发布与软件规模相关的度量数据标杆。

用例点分析：面向对象时代的新选择

随着统一建模语言（UML）的发展，用例点（Use Case Points，UCP）也成为衡量软件规模的重要方法。与功能点不同，用例点更关注用户与系统的交互，通常在软件需求分析的早期阶段使用，适用于面向对象的开发。

尽管用例点尚未被广泛的国际标准组织接受，但它已经在许多实际项目中得到了广泛应用。

故事点：敏捷开发中的规模估算

2001年，敏捷宣言的发布，标志着敏捷方法在软件开发领域的兴起。为了适应敏捷开发的快速迭代特点，“故事点”应运而生。故事点通过相对估算来衡量任务的复杂度和工作量，而不是基于绝对的工时长短，现已成为敏捷开发中的常用工具。

任务工时可以作为软件规模的度量吗？

经常有客户问我，“为什么不直接用估计的任务工时作为软件的规模？我们用项目估计工时来做项目计划，也可以管理项目啊！” 这里的核心问题在于，工时是一个动态的、因开发人员能力而异的第三方表述，并不能代表软件自身的功能和复杂度。例如，具有相同功能的软件，开发人员甲和乙花费的时间可能就不一样，因为甲有十年经验，而乙刚刚毕业。因此，在正规的软件开发项目中，不建议使用工时作为软件的规模度量。

软件规模估算工具

规模估算是软件项目计划的基础。规模估算不准确，项目计划也无法准确。尤其是基于国际标准的功能点估算，其相对复杂，需要专门培训才能掌握。在国际和国内都有相关的功能点估算证书和工具，而且逐渐在普及。英国的ScopeMaster（www.scopemaster.com）是知名的规模估算工具，国内也有CoCode软件成本造价工具（www.co-code.cn），有基于AI的自动估算功能。这些工具可以大幅提升规模估算的效率和准确性，甚至达到数十倍或数百倍的提升。

结语：软件规模的重要性

无论是功能点、用例点还是故事点，这些方法的核心都在于帮助我们更好地理解和管理软件项目的工作量。度量软件规模不仅有助于项目计划的制定，还对许多关键的度量项有直接影响，例如生产率（单位规模所花费的工时）和质量（缺陷密度，单位规模的缺陷数）。真正的软件开发人员应当理解软件规模的概念，而作为软件开发主管，更应该理解软件规模的概念，否则，未来你可能连奖金都不知道该怎么发。

祝你成功！

本文作者：高山 CMMI高成熟度主任评估师 讲师