互动科普

与石油、钢和纸等产品不同，软件是一种无形商品这种不易捉摸的特性使计算机程序难于被量化。

现代社会对软件的依赖性越来越大，这一点是令人欣慰的。计算机程序执行许多操作——例如编制工资表、记载银行交易、安排客机订票等——已经是家常便饭，而对于没有什么辅助手段的人来说，这些工作是极为繁琐的。计算机程序也能完成人所不能胜任的许多任务，例如在因特网上检索大量信息。

尽管软件这样重要，但它是一种无形的东西，对它进行计量是非常棘手的事。人们究竟应当如何确定软件的规模呢？

这个问题不只是一项学术探讨。由于软件没有合适的衡量指标，计算机行业改进计算机应用程序质量和提高其开发效率的努力遇到了麻烦。事实上，大多数公司和政府机构对于它们的软件的能力和编程人员的生产率都只有一点模模糊糊的概念，这样．设计程序所需的时间和经费投人的预测就变得极为困难，从而使成本超支和时间拖延成了司空见惯的事而不是个别的情况。事实上，软件己被证明是一项易惹起麻烦的技术，被媒体炒得沸沸扬扬的丹佛国际机场行李处理系统计算机故障一它使该设施的启用被推迟了1年以上——就是一个证据。事实上，在所谓的千年虫问题(2000年计算机问题)变得紧迫起来之前，大多数单位对于它们拥有多少软件都还蒙在鼓里，尽管软件是一笔至关重要的、昂贵的资产。我认为，这一关于软件计量的基本问题是软件行业目前面临的最大障碍之一。

当然，对软件进行计量的方法之一就是直截了当地统计一下某一计算机程序在计算机硬盘存储器中占据的所有字节。另一种方法则是统计代码的行数——即每个计算机应用程序所需要的长长的指令表——的行数。但是，这类计量指标并不总是反映软件的实际能力。有时候，一个仅有3百万行的程序其功能和特长可能比有5百万行的应用程序更丰富多彩。

因此。更妥当的方法是评估某一程序所执行的操作。这样做的一种正式方法是统计功能点”(Function Points)，它是衡量计算机的能力的定量指标。计算机科学家们在二十多年前开创了这种形式化方法。由于他们的不懈努力，一项国际标准可能很快就将制定出来。然而，现在还远不能肯定功能点最终是否将成为软件的通用计量系统。

软件究竟是什么？

数字计算机本身不过是在其上运行的软件的容器而己。在这方面，光盘放唱机(CD机)的作用是类似的把一盘录有奠扎特交响乐的碟片放进CD机，听众便可以欣赏古典音乐，而把一盘录有Billie Holiday的碟片放进CD机，就可以听到爵士乐类似地，使用不同的软件，计算机就可以起字处理器的作用，处理表格程序或从万维网上读出文件等。

软件本身由成千上万条(有时甚至多达数百万条)的一系列指令构成这些指令规定计算机进行各种各样的操作，例如显示信息，进行计算或存储数据等。如果我们继续使用上述音乐的类比，就可以把编程员比作作曲家。作曲家构想出乐曲然后用一个接一个的音符把它描述出来编程员则构想出软件然后用一条接一条的指令把它写出来。

不过，软件同音乐的类似之处也就到此为止了。举个例说，无论作曲家创作的是流行音乐还是歌剧唱段他们都使用同样的符号和记法。但另一方面，编程员却有至少5百种不同的语言可用。有的计算机语言(如COBOL)用于商业问题上。另外一些计算机语言如（FORTRAN)则用于数学与科学领域。此外，象PL／I这样一类语言则可以用于范围广泛的多种场合。

统计代码行数这一做法己被证明既不易实行又不可靠，原因有若干条，其中之一便是计算机程序有这样多的各种各样的语言可用，而每一种语言又有其自己的结构与句法。具体地说就是．不存在一般的规则或标准，可以确定所有程序设计语言中究竟怎样才算是构成一行代码对于较新的语言(如Visual Basic)，代码的行这一概念本身就没有多大意义，因为编程员通常既使用代码，也使用所谓图形控制(Graphical Contro1)来确定所开发的应用程序将如何起作用。此外，有时候同一软件中使用好几种语言。

即使能够绝对精确地统计代码，它仍然不是一个完美的解决办法。另外一种类似的计量软件的方法——简单地统计软件所占用的计算机硬盘存储容量一一则更成问题。其原因之一是，同一应用程序用不同语言编写时它所占据的存储空间相差扳大，即使在程序被转换为计算机所使用的二进制0和1数字串以后。因此，草率地使用这样一些整体性的衡量指标可能得出容易使人上当的结果，尤其是在用于大型程序时。

恼人的难题

现今使用的许多应用程序由1百万条以上的单个语句构成。有的应用程序的语句超过1千万条。编写这样一些大型软件的费用，远远不是仅由实际编码过程的费用所决定的。实际上，各公司用于编制纸印文件(包括规范和用户手册等)以及调试程序和校正错误——错误是必定会出现的——的费用比实际编码过程的费用要多。此外，管理一项大型软件工程的费用本身也是非常之高的。

建造大型应用软件的工作有很大一部分同代码编写并无直接关系，这一事实导致了一个出人意料的难题。假定有两公司决定要开发其功能完全相同的程序，一家公司使用汇编语言，此语言用许多指令来处理一些基本的操作，例如把一个数加到另一个数上。采用这样低级的语言，该公司的程序需要(比如说)一百万行代码。第二家公司则使用一种面向商业的语言COBOL，它完成同样的功能所使用的语句数比汇编语言要少。使用这种高级语言，该公司的程序可能只有40万个语句。按照这种统计代码行数的结果来衡量，表面上看来第一个程序就比第二个程序“大一倍尽管事实上两个程序是完全相同的。

如果这两家假想公司的编程员以不同的速率编写代码(这是可以料想得到的，即使他们的基本工作能力不相上下)，那么这一比较就更复杂了．由于所用的程序设计语言不同，第一家公司的每位工作人员每月或许能完成500行代码，丽第二家公司的每位工作人员每月仅完成360行。尽管如此，第二家公司仍然能更快地开发出应用程序：只需用1100人/月而前者要用2000人/月)，其原因之一是它必须编写的代码行数较少，而且用高级语言编写的程序所需的调试工作量也较小、这样，第一家公司的程序的总成本将达2千万美元，而第二家公司的费用仅为1100万美元。但是第一家公司每行代码的成本为20美元，第二家公司每行代码的成本的27.50美元。因此，乍看起来第一家公司的编程员的工作教率似乎较高，尽管第二家公司开发同一应用程序的速度更快，费用也更低。这样，每一行代码的成本较低并不一定意味着经济效益较好。

显然，盲目地统计代码行数可能起误导作用。计算机科学家们多年前就意识到这个问题，因而IBM公司一—世界上最大的软件开发机构之一——的几个研究小组开始探索计量软件的其它方法。其中一个小组(包括作者本人在内)在1973年注意到了生产率难题，当时该小组比较了用汇编语言编写的软件和用PL／I开发的程序前者所需要的语句数平均来说为后者的4倍。但是两种语言能够以大致相同的速率编码。

为了解决这个把不同的东西扯在一起相互比较的问题我们当时立即提出了一种解决方案：把PL／I语言编写的程序代码行数乘以4，以使它与汇编语言的语句数等价。虽然这一方法可以使两者大致可比，但它远远说不上是理想的方法。实际上我们所做的不过就是相当于货币兑换而已，比如把美元兑换为日元。

功能点的关键

IBM公司在纽约怀特普莱因斯的其它一些研究人员以及其它地方的研究人员开始实施一项更根本的研究计划。Allan Albrecht及其同事们决定要制定出软件复杂性的计量单位，他们给这种计量单位取名为功能点。他们把这种新颖的核算方法设计成与程序设计语言无关的形式。

为了计算功能点，人们要考虑程序的5个方面：输入、输出、交互式询问（即用户发出一个询问而计算机给以一个应答)、外部逻辑文件（接口)和内部逻辑文件。试考虑一个简单的拼写检查程序，此程序有一个输人(即需要检查其拼写是否正确的文件的名称)，3个输出（检查的单词总数、找出的拼写出错数以及列出拼写有错的单词的一张表），一个询问（用户可以通过交互式询问得知到现在为止已经处理了的单词总数），一个外部文件（需要检查的文件)，以及一个内部文件（词典)。这样一个简单的程序有1+3+1+14-1=17个要素。

实际经验证明，功能点分析远远不只是统计一下上述五类特征，而是要复杂得多。接照设在俄亥俄州威斯特维尔市的国际功能点用户集团（International Function Point User’s Group，缩写为IFPUG）制定的详尽规则，此种方法的使用者根据每一要素的复杂性(低、中等或高)而赋予其不同的权重。实际计算是很复杂的，但是，在那个简单的拼写检查程序的例子中，如果它的7个要素的复杂程度均为中等的话，那么其功能点的加权和将为40。

最后，总的功能点得数还要乘以一个根据整个软件系统的复杂性而确定的因数，这样其功能点总数还会上调或下调。这一调整由14个因素决定，包括应用程序的处理过程是否在不同的计算机上分散进行，以及软件的各部分是否需要设计成未来的程序能够重新使用的形式。

复杂软件的功能点的计算是相当繁复的，通常需要经过资格考试的专家来做这项工作软件管理人员一般不要求借得计算功能点的实际方法，但是他们应当全都知道对生产率和质量的评估现在是用这样一些衡量指标来表示的。

由于功能点与所用的程序设计语言无关，因此它是比较不同软件的最精确的方法拿本文前面提到的那个恼人的问题来说，如果用汇编语言和COBOL语言编写的应用程序都有4千个功能点(具有相同功能性的两个程序其功能点的数目相等)，那么第一个公司的总成本每个功能点5千美元．而第二个公司的总成本为每个功能点2750美元[见图1]。这一结果更接近于两项软件工程的实际经济效益。

借助于功能点，公司主管现在就可以对生产率和质量进行更为可靠的分析。目前这一方法是美国和欧洲许多地方所进行的这类研究中使用最广泛的方法。在世界范围内，使用功能点来计量的软件工程的总数超过了10万。我和我的同事以及其它一些研究人员已经使用从这些研究中得到的信息来考察各个国家、行业以及各种程序设计语言在生产率和质量方面的差异。

这类研究已经得出了许多有用的经验法则，它们可以对开发软件的各公司助一臂之力，特别是在这些公司着手实施大型软件工程之前。(如果软件一开始就被完全规定好了，那么甚至在一行代码都还没有写出时就可以计算出一项软件工程的功能点的总数。)比如，求出一个软件系统的功能点总数的1．25次方，就得出了对必须纠正的错误数目的一个粗略估计。把功能点的总数除以150，就得出了开发一项应用软件所需的编程员软件分析人员和技术人员的大致人数。求出功能点总数的0．4次方，就得出开发人员完成一项软件工程所需的时间(月数)。显然，这些经验规则不能代替正式的、详尽的估计，但它们所提供的初步数据可以给那些不切实际过份乐观的计划泼一瓢冷水让它们清醒一点，而在软件开发中这类计划比比皆是。

尽管有这些非常有用的信息，令人遗憾的事实是，绝大数单位根本就不进行任何有用的软件计量。迄夸为止已有10万多个软件工程用功能点进行了计量，然而这个数字却低于目前正在运行的软件应用项目总数的百分之一。在较小的公司中——特别是那些软件专业人员少于100人的公司——无论是功能点还是其它计量方法都还未得到推广。但是对于从事计算机程序的开发、澍试和维护的人员超过1万人的大公司，功能点的使用已经非常普遍。在这些公司中软件是一项很大的开支，因此需要进行精确的计量与估算。

考察一下个人应用软件的规模也是很有意思的。我在撰写本文时使用的字处理程序有43万5千行代码，约有3500个功能点。办公室工作人员在处理日常业务过程中使用的表格处理软件、字处理程序数据库应用程序、统计软件工具及专用程序等，其软件功能点总数可能超过25000个。所有这些应用软件在操作系统的控制下运行，而操作系统的规模可能超过10万个功能点。

并非尽善尽美

功能点的应用已遍及全球，但并非没有争议。例如，许多研究人员责备这个方法在根据软件的复杂性规定不同的权重时太易受人的错误判断的影响。这种主观性问题的确是存在的．但是通过实施资格认证培训和资格考试，已经使功能点统计方差的范围缩小到10以内。这一误差范围与统计广泛使用的语言(如COBOL)的代码行数时所出现的误差范围基本相同。(事实上，有的公司在统计代码行数时没有统一的标准；对于这些公司，不同的经理和绾程员在计量同一个程序时曾产生超过100的显著方差。)

许多研究人员抱怨说功能点的计算太费力太麻烦了。这种批评意见是有道理的，但是自动化的统计工具可能很快就会减轻工作负担。还有的人宣称，由于功能点是为商用信息系统开发的，它们不适用于计量其它类型的软件。但实际上功能点对于计量系统软件一一即永久性存人各种消费产品和高技术武器的应用程序——有很大的帮助。计算机专业人员仍在继续改进功能点规则，使它适用于更新的软件类型，例如用于万维网的应用程序。

标准化可能是最大的挑战。软件行业中的许多人无论对于IBM公司最初开创的方法还是对IFPUG所确立的当前方法中的部分统计规则都提出了质疑。这样，现在功能点方法已有大约20种不同形式。

八十年代初，伦敦Nolan Norton公司的研究人员Charles R. Symons开发出了一种统计功能点的方案，名为MarkⅡ。在其它的改进中，MarkⅡ把调整因素的个数从14个增加到19个，此外还作了另一些改进。另外一种方案叫做特征点(Feature Points)，它用于计量工程与科学应用软件。由于这类软件可能非常复杂，而输入和输出的数目却比较稀少，因此使用传统的功能点有时可能会导致低估。特征点方法考虑程序中算法的数目，并把调整因素的个数从14个减少到只有3个。其它计量方法包括所谓3维功能点、工程功能点．目标点以及完全功能点等等。

国际标准化组织以及世界各地的功能点用户的主要协会正在合作起草一套统一的计量规则。由于有各国代表的参与，因此，如果真的能够实现标准化的话，那么最终的标准可能会容纳IFPUG以及各个主要计量方法的设想。

尽管功能点存在这样那样的问题，但它目前仍是计量软件的最佳方法。这种形式化方法的普及的确是受欢迎的。因为，如果没有某种客观的衡量标准，开发软件就很难取得真正的工程学科这样一种地位，而只能是艺术活动，正如在其发展历程的大部分时期中的情形那样。