2.8.2　LOC度量方法的经济学问题

使用LOC度量方法的生产力研究中如果包含了多种编程语言，则其结果会比较严重地违反标准的经济学方法，因而应该将LOC度量方法归类为失职。

LOC度量方法构成失职的说法是严肃的告诫，不应当轻视。原因是LOC度量方法违反了制造经济学的基本原则，并且确实为最低级的语言给出了最高的生产率。下述案例研究阐述了为什么LOC度量方法是有缺陷的（本案例来自一份真实的咨询合约，受一家欧洲电信公司委托）。

本书的一位作者及其同事受一家欧洲电信公司委托去考察一个有趣的问题。这家公司的很多产品使用CHILL编程语言编写。CHILL是一种相当强大的第三代过程化语言，它是CCITT（国际电报电话咨询委员会）专为电信应用程序开发的。

该公司的软件工程师和管理人员对迁移到使用C++作为主要语言的面向对象编程很感兴趣。公司实施了研究来比较编写类似的应用程序CHILL和C++的生产率。这项研究的结论是，当使用每人月LOC这个生产力度量方法时，CHILL项目的生产率高于C++。

这位作者需要考察这些实验的结果，确认或者质疑CHILL优于C++的这一发现。

因为很多其他编程语言被用于PBX交换系统，所以研究中总共包含了10种语言。可用的数据来自几家生产相似PBX交换机的公司。虽然实际的PBX软件规模从大约1350到1700个功能点不等，但所有规模都进行了数学处理，调整为相同的规模——1500个功能点。

为确保结果的一致性，所有版本都使用相同的活动集合来比较，任何只存在于某个特定项目中的活动都被去除了。使用CHECKPOINT度量和估算工具对数据进行了标准化。这种工具使得不同的编程语言和不同的活动集合间的比较变得容易，因为它能将应用程序转化为相同的规模，突出并标记出比较中那些不是所有项目都有的活动。例如，如果某个项目收集了无报酬的加班数据，但另外一个相似项目没有收集，那么CHECKPOINT能提供模拟的无报酬加班数值。

所研究的全部活动总计超过20种，但是最终提交给客户的报告中使用了基于6种主要活动的合并数据：

1）需求；

2）设计；

3）编码；

4）集成和测试；

5）客户文档；

6）管理。

将数据合并为6种主要活动主要是为了简化报告结果。这些所使用的粒度更小的数据包括了活动和任务级别的信息。例如，标记为“集成和测试”的成本实际上由来自集成、单元测试、新功能测试、回归测试、压力和性能测试以及现场测试的信息组成。

第一个有趣的话题是实现基本相同的应用程序所需要的代码量相差很大。注意，本例中用于分析的PBX项目，其所有10个版本的功能点总数被人为地控制在固定值1500。

当然，在现实生活中用到的研究项目的功能是有差别的。表2-21给出了这10个例子中一个功能点所需的源代码量和源代码语句数量。

下一个有趣的话题是开发这个项目的10个案例所需的工作量。表2-22给出了6种主要活动所需的工作量，所有的工作量都用术语“人月”来表述。注意，术语“人月”被定义为一个典型的工作月，大概是22个工作日，同时假设项目每天工作时间大概为6个小时，即每个月132个工作时。

因为数据来自4家公司，每家公司都有不同的会计假设、薪金比例、工作月定义和工作模式，以及其他复杂因素，各个项目分别使用CHECKPOINT工具转换为标准的每月132个小时的工作周期，每月10000美元的成本。

没有一个项目的规模恰好是1500个功能点，原始规模从1300到1750个功能点不等。同样，也使用了数据标准化功能，使得所有10个版本有相同的因素，这些因素可能会掩盖案例中隐含的相同点。

很容易看到，和过程化和低级语言相比，高级和面向对象语言在编码和测试方面的总工作量要少得多。然而，与初始需求、设计和用户文档相关的工作量则相对没有弹性，并且没有和所需的代码量按正比波动。

最有趣的结果与度量这10个版本的生产率有关。注意用每人月LOC表示的生产率和用每人月功能点表示的生产率相比，二者的结果明显是相反的。

表2-23中的数据源于表2-22的最后一列，即用于10个项目的总工作量。表2-24提供了使用LOC和功能点两种度量方法的全部结果。

容易看到，LOC数据不符合标准制造经济学的设想，实际上它和真实经济学生产力是相反的。

数百年来为人所熟知的是，当制造成本中的固定成本比例很高，且生产的部件个数降低时，单位部件成本将会上涨。这是制造经济学中的基本规律。

同样的逻辑对软件而言也是正确的。当LOC定义为生产单位，且存在从低级的过程式语言向高级和面向对象语言迁移时，“单位”的数目必定下降。

一方面，纸质文档（如需求和用户手册等）的成本不会下降，常常表现为固定成本。这必然导致当度量中包含纸质相关的活动时，面向对象项目的单位LOC成本增长和每人月LOC降低。

另一方面，功能点度量方法是人为的度量方法，完全源于应用程序所需的代码量。因此，功能点度量方法可以用于涉及多种编程语言和面向对象编程语言时的经济学研究，其结果不会有偏移或曲解。功能点度量方法也可应用在非编码活动，例如需求、设计、用户文档、集成、测试，甚至项目管理等。

为了明确地说明LOC度量方法的危害，表2-24简单地按生产率降序排列了10个版本。可以看到，功能点列表和LOC列表的排名正好完全相反。

当使用标准的经济学中生产力的定义，即单位劳动力或费用所产生的商品或服务时，功能点排名和经济学生产率设想是一致的。

功能点排名和经济学生产力设想相一致，是因为工作量和成本最低的版本有着最高的功能点生产率和最低的单位功能点成本率。

另外，LOC排名和实际的经济学生产率完全相反。这就是为什么LOC度量方法被用于跨语言生产力或既有高级又有低级编程语言的质量比较时，被看作“失职”的关键原因。

LOC度量方法对跨语言比较而言如此危险，所以使用LOC来标准化涉及多种或不同语言的数据就应当被认为是失职。

失职意指训练有素的工作人员做了一些危险和不安全的事，并且职业所需的培训和谨慎的级别应当能阻止此类不安全的行为。因为很显然LOC度量方法和经济生产力没有同向变动（事实上是反向变动），所以一个合理的论断是，如果报告或发表的数据引起某些损害或危害的话，那么LOC度量方法的错用应当被认为是失职。

事实上，整个案例研究是基于这样的事实，即客户使用LOC度量方法度量生产力，并错误地得出低级过程式语言的生产力比高级面向对象语言更高的结论。

软件行业的一个严重问题是无力对各种各样的工具、方法或编程语言的影响作出经济学分析。可以这样讲，LOC度量方法已经成为重大的障碍，减慢了软件工程的演化，因为它蒙蔽了研究人员并阻止了对软件工程因素适当的探索。