3.2.11　功能点质量度量

因为本书使用了功能点度量方法，所以包含以下的简短的讨论还是比较合适的：功能点是什么，以及为什么功能点在软件项目中标准化质量和生产力数据方面变得如此常见。

在本书写作时，功能点团体似乎比较了解软件质量，而软件质量团体并不怎么了解功能点。

在本书一位作者的客户之中，600家公司中大约有500家现在在一些项目中的某些地方使用了功能点。其中，大约450家使用了标准的IFPUG功能点，剩下50家使用了一个或多个变种，如COSMIC功能点、NESMA功能点、back-firing等，这些变种是从基于逻辑语句的代码行数目直接转换而来的。不少客户还使用用例点、故事点或者更新的度量方法，这些方法有功能点的特点，但是使用了不同的因子并进行了调整。当然，军事和国防客户仍然使用LOC度量方法，但是即使在这些客户中有些也使用了功能点。

在该作者的客户中功能点用户的数目如此之多，这是由于人们对数据的偏爱。该作者因为他在功能点度量方法的成就而被大家熟知，1985年他的第一个基于功能点的估算工具发布。1986年，功能点的发明者Allan Albrecht从IBM退休，并与该作者合作建立了第一个功能点计算的课程。因此，使用功能点的公司比那些没有使用功能点的公司更有可能寻求他们的帮助。

有趣的是，这些客户中有大约400个同时使用了LOC和功能点度量方法。对于这些公司，backfiring（从旧的代码行数据直接转换成功能点形式）是使用两种度量方法的最常见动机。第二大动机是一些客户自己的客户（如美国军事服务机构）在某些情况下可能需要代码行。

功能点度量方法是由IBM White Plains的Allan J.Albrecht和几位同事在20世纪70年代中期发明的。功能点度量方法是由IBM在一个联合的IBM/SHARE/GUIDE会议上放到公共领域的，该会议是在1978年10月在加利福尼亚州蒙特雷市召开的。在这次会议上，Allan Albrecht做了第一个关于功能点度量方法的公开演讲。从此，功能点度量方法的使用开始迅速扩展到全球。

在1984年，一个非营利组织在加拿大多伦多市成立了，该组织由使用功能点的公司组成。这个组织最初的员工只是一些兼职的志愿者，但是成长迅猛，很快就需要正式注册（incorporation）并雇用常设的职员。在1986年，随着这个非营利的国际功能点用户组（IFPUG）变得出名起来，它在俄亥俄州韦斯特维尔市也成立了分部，并且雇用了几个常设的办公室职员来管理事情。

这个组织在2011年已经是美国最大的软件度量协会。其在约25个国家的功能点用户组分会是当地最大的软件度量协会。

功能点度量是一种通过枚举和调整5个对用户和开发者都显著易见的方面来确定软件应用程序规模的方式，标准的IFPUG功能点包含以下5个关键的外部因子：

1）进入应用程序的输入（如输入屏幕、表格、命令等）；

2）离开应用程序的输出（输出屏幕、报告）；

3）对应用程序进行的查询（信息查询）；

4）应用程序维护的逻辑文件（表格、文本文件）；

5）应用程序和其他应用程序的接口（共享的数据、消息）。

当未处理的这5个因子被枚举时，另外14个有影响的因子的集合也要评估以便针对复杂度进行调整。人们使用0（没有影响）～5（主要影响）的范围来评估这些调整因子的影响。

这14个调整因子超出了本书范围，但是本书包括了应用程序是否需要分布式的功能，是否使用数据通信，是否有较高的事务量（transaction volume）等主题，以及一些相似的主题。

调整因子被转化成有权重的范围，该范围可以修改初始的未加工的总数，修改范围可以从简单应用程序初始值的65%到复杂应用程序初始值的135%。复杂度调整之后，最终的值被称为应用程序“调整后的功能点总数”，当就功能点讨论质量或者生产力的时候这个值会被使用。

从质量的角度出发，功能点有很多用途，包括但不限于：

●在需求、设计、编码、文档和不良修复类别中标准化缺陷数据；

●估算可能需要的测试用例的数目和测试执行次数。

由于有趣的巧合，这5个计算功能点的标准IFPUG因子，加上算法（功能点的角度）、实体与关系（MarkⅡ功能点的角度），提供了一个有用的关键软件功能的集合，测试用例通常是按照这个集合来构建的：

●算法；

●输入；

●输出；

●实体和关系；

●逻辑文件；

●查询。

这意味着使用功能点度量方法的公司能够在需求阶段准确地预测需要的测试用例和测试执行次数。进一步说，还可以进行准确的缺陷估算，如同采用缺陷预防方法一样。

尽管各种功能点度量方法并不是为质量保证而发明的，但是它们与软件质量的目标和方法是相互促进的。事实上，功能点度量方法开始了一些新形式的质量研究，例如前端的需求缺陷的研究，在功能点被开发出来之前较难发现的需求蠕变比率的研究。

计算和调整应用程序的功能点既不简单，也不是太难。功能点计算的常规培训课程为期2天，并且会有一些亲自动手的计算练习。为了保证计算规则的精确性和一致性，IFPUG提供了定期的认证考试。

IFPUG还编写和维护正式的计算规则，这些规则会按照需要进行修订。例如，本书假定使用的是IFPUG计算规则4.2版。

用来确定功能点总数的普通原始材料是软件应用程序的需求和功能规格说明书。因为功能点是独立于代码的，所以这个计算没有必要等到编码进行或者完成时。

对于已经存在的或者旧的应用程序，使用backfiring导出近似的功能点总数也是可能的（来自物理行数目的backfiring过于模糊和不确定，不推荐）。

对旧的应用程序使用数据挖掘并从代码中提取隐藏的业务规则和算法也是可能的。这些可以被组成一个合成的规格说明书，该规格说明书允许普通的功能点分析。基于这个方法，一些公司为旧的应用程序开发了高速的计算工具。这些工具在准确性上接近普通的功能点分析，比backfiring要准确得多。

为了明白为何人们愿意费力来使用功能点，有必要考虑LOC度量方法的限制，而功能点替代或加强了这些限制。功能点度量方法通常被用来替换或者增加软件应用程序中以源代码行数（SLOC）为基础的旧的软件度量方法。

当软件开始被用于商业目的时，人们对度量创建新项目的生产力方面就会有显著的兴趣。使用SLOC度量软件生产力是很自然的，因为大多数项目是比较小的，而且编码用掉了使计算机能够执行任务所需的总工作量的90%以上。

软件研究者开始开发越来越强大的编程语言，这些编程语言不需要与计算机机器语言一一对应。这些语言被称为“高级”语言，因为语言中的一条语句可以导致多条机器语言的执行。

这些高级的编译或解释语言常常是为专门的目的而创建的。例如，FORTRAN语言是为了数学和科学工作而创建的（FORTRAN代表Formula Translator（公式翻译））。COBOL语言是为商业应用而创建的（COBOL代表Common Business Oriented Language，即面向商业的通用语言）。

随着越来越多的编程语言和特殊目的的语言被创建，代码行的概念对于度量软件开发的生产力来说变得越来越没有用。事实上，对于很多现代语言（如Visual Basic），应用程序开发的一些部分是从使用控件、按钮或者操作图形符号导出的，因此代码行的整个概念就失去了实用性。

随着第4代语言、应用程序和程序生成器、“可视化”（Visual）语言、面向对象语言、数据库语言以及专用的语言开始混合使用，纯粹的编码在绝对工作量和占构建软件应用程序所需总工作量的比例两方面都稳定地减少了。表3-9对于该情况的描述虽然过于简单，但是却展示了随着时间变化的大致趋势。

因为bug或缺陷数量随着规模而增长，大型系统的审查和测试活动成本比早期小型的应用程序高得多。对于用高级语言编写的大型应用程序，编码变成一个较小的成本元素。按照降序，大型软件应用程序初始发布版本的4个主要成本驱动因素包括但不限于：

1）测试和缺陷清除；

2）撰写纸质计划和规格说明书；

3）团队与客户之间的会议和沟通；

4）编码。

遗憾的是，LOC度量方法对于标准化软件的前3个成本元素（缺陷清除成本、文档工作成本、沟通成本）不是一个好的选择。这意味着很难使用LOC度量方法对整个软件生命周期进行经济学研究，而且主要的研究主题往往不被上报，甚至被错误地上报。

如这些简单的例子所示，功能点度量方法与生产力的标准经济学定义是符合的：生产力是单位劳动力或费用生产的商品或服务的数量。

如果这样，对于软件项目提供给用户的“商品或服务”来说，功能点是一个非常实际可行的代用品。

相反，对于软件商品或服务来说，代码行就不是一个有效的代用品，因为这对用汇编语言等语言编写了大量代码的用户来说是不利的，使用Java、Ruby、ASP.Net等语言时同样的特性需要的代码会少很多。

功能点度量方法可以进行非常准确的软件经济学研究，这解释了为什么它在软件行业中被广泛用于经济分析。这也解释了功能点在本书中的经济学分析中被使用的原因。这些功能点度量方法是符合标准经济学假设的唯一可用的度量方法。一些功能点常用的度量包括：

●单位人月生产的功能点；

●生产一个功能点所需的工作小时数；

●支持一个功能点所需的工作小时数；

●维护（修复bug）单位功能点所需的工作小时数；

●单位功能点的开发成本；

●单位功能点的维护成本；

●开发过程中单位功能点缺陷；

●已发布的软件的单位功能点缺陷。

现在功能点的使用非常普遍，以至于美国国税局（IRS）和很多其他国家的税务服务机构现在都使用功能点来确定软件的税收价值。至少有两个国家，巴西和韩国，要求在政府软件合同中使用功能点。

功能点度量方法不仅可以被用来预测编码缺陷，而且可以预测非编码项目，例如需求和规格说明书（见表3-10）。

因此，功能点开启了前端缺陷水平和外部缺陷水平（如用户手册、屏幕）的质量研究，以及继续支持编码缺陷水平的研究。但是，如我们之前讨论的，当使用功能点度量方法时编码缺陷需要特别计算。

由于功能点作为质量度量方法的有用性，国际功能点用户社区拥有的可用质量数据可能比任何主要的质量协会都多，这是一个有趣的社会现象。无论如何，考虑到双方有着更好的度量和更好的质量这样的共同目标，功能点组织和软件质量组织之间有必要进行协调和沟通。

很多实时软件、系统软件、嵌入式软件的开发者中有一个信条：“功能点只能用于管理信息系统”。这种说法是荒谬的。功能点的发明人Allan Albrecht是一位电气工程师，常常设计功能点以用于工程项目。IBM在管理信息系统中首次使用功能点只是一个历史的偶然。

功能点可以而且正在被用在实时软件和嵌入式软件中，如燃油喷射系统、操作系统、电话交换系统、舰载火炮控制系统、战斧式巡航导弹中的嵌入式软件和飞机飞行控制软件等。

功能点度量方法并不是完美的。但是对于软件本身和软件质量的经济学分析来说，功能点是最好的可用度量方法。对于经济学分析而言，代码行和单位缺陷成本都不是有效的。

一些较新的专门度量方法（如故事点和用例点）过于专门化了：它们只能度量使用了用例或者故事点的项目，不能被用来分析使用了Nassi-Shneiderman图、数据流图或决策逻辑表等方法的其他项目。

功能点是中立的，因此可以被用在各种形式的软件中，如嵌入式和Web项目；可以被用在各种开发方法中，如敏捷和RUP；可以被用在所有的编程语言中，从汇编语言到Ruby和Perl。