功能点

功能点是呈现信息系统提供给使用者功能多寡的“量测单位”。功能点可以用来计算软件的功能规模度量（functional size measurement，简称FSM）。每个单位开发需要的成本（可以用小时或是金钱计算）可以由以往的专案中得知^[1]。

标准

有关依功能点度量软件规模的方式，有几个受大众认可的标准或是公开规范。

• FiSMA: ISO/IEC 29881:2010 Information technology – Systems and software engineering – FiSMA 1.1 functional size measurement method.
• IFPUG（英语：IFPUG）: ISO/IEC 20926:2009 Software and systems engineering – Software measurement – IFPUG functional size measurement method.
• Mark-II: ISO/IEC 20968:2002 Software engineering – Ml II Function Point Analysis – Counting Practices Manual
• Nesma: ISO/IEC 24570:2018 Software engineering – Nesma functional size measurement method version 2.3 – Definitions and counting guidelines for the application of Function Point Analysis
• COSMIC（英语：COSMIC functional size measurement）: ISO/IEC 19761:2011 Software engineering. A functional size measurement method.
• OMG: ISO/IEC 19515:2019 Information technology — Object Management Group Automated Function Points (AFP), 1.0

上述五项标准是软件度量总体标准ISO/IEC 14143的实现^[2]。由软件品质联盟（英语：CISQ）主导的OMG自动化功能点（AFP）规范，提供了依照国际功能点用户群（英语：IFPUG）的指引自动化计算功能点的标准。不过，目前此标准的实现有一些限制，在没有预先配置的情形下，无法立刻区分外部输出（External Output）和外部查询（External Inquiries）^[3]。

简介

功能点是由IBM的llan J. Albrech于1979年在Measuring Application Development Productivity论文中所定义的^[4]。会先识别软件功能性使用者需求，将需求分为五类：输出、查询、输入、内部档案、外部界面。只要识别出功能，并且找到其分类，就可以评估其复杂度，并且给定功能点。每一个功能性使用者需求都可以对应终端用户的业务功能，例如一个输入中的资料输入栏位，或是查询中的使用者查询栏位。这个差异很重要，一般比较容易将用功能点度量的功能对应用户导向的需求，不过其缺点是会忽略同样需要资源才能实现的内部功能（算法）。

有关算法的规模度量

在目前ISO认可的功能规模度量方法中，还没有在度量中考虑算法复杂度的方法。目前已有许多不同的作法试图要考虑算法复杂度，也已出现在一些商用软件产品里，但都还有一些弱点。Albrecht为基础的IFPUG方法设法要处理这些弱点，其方法包括有:

• 早期和简单的功能点：用二个问题考量问题和资料的复杂度，不过二个问题是某程度主观的复杂度量度，去除了资料元素的计算，简化其量测。
• 工程功能点：计算元素（变数名称）和算子（算术、等式或不等式、布林运算）。此变体强调运算功能^[5]。此作法有点类似以算子和运算子为基础的霍尔斯特德复杂度量测。
• Bang measure：依12个会影响或是呈现出Bang的初级计数来定义功能度量。Bang的定义是“使用者可以收到或是感受到真正功能的度量”。若是要用软件单元提供给使用者机能的有用程度来评估软件单元，Bang measure很适。不过在这方面应用上，文献的佐证很少。若是在进行（部分或是完整）软件再造时，可以用Bang measure，正如Maintenance of Operational Systems—An Overview中所述的一样。
• 特征点（Feature point）：有进行修改，可以适用在有重大内部处理（例如操作系统、通讯系统）的系统中，可以考虑到一些使用者不一定会感受到，但是在正常运作中必要的功能。
• 加权微功能点（英语：Weighted Micro Function Points）：在2009年的一个版本中有用加权方式调整功能点，加权来自程式流复杂度、运算子和算子字汇、物件使用量，以及算法。
• 模糊功能点：在低到中之间的复杂度，以及中到高之间的复杂度中，加入模糊且渐进式的变换^[6]

和源代码行数的比较

源代码行数（LOC）是最常见估算软件规模的作法，而提倡功能点的人士认为因为以下的原固，功能点会比源代码行数要好：

• 会有源代码行数膨胀的风险，若开发者受此影响而让源代码行数膨胀，但没有对应机能的增加，会降低软件规模估算系统的价值。
• 源代码行数计算对低阶的编程语言比较有利，因为需要较多的程式码才能得到相同的功能^[7] C. Jones在其著作中有提到一种修正的方式^[8]。
• 在开发早期的阶段，很难去估算最后提供程式的源代码行数，因此在开发早期不太适用。而功能点可以从需求中衍生，适用于像estimation by proxy之类的方法。

Albrecht在其研究中发现功能点和源代码行数高度相关^[9]，因此他提出质疑，若有一个更客观的度量方式（源代码行数），是否还有功能点的价值。

后续研究

针对功能点的缺点，已有许多研究在设法改善，作法包括有强化计数制度^{[10][11][12][13][14][15]}。也有人开发其他方式以回避其困难点，例如建立代理器来计算所交付的功能^[16]。

相关条目

• 构造性成本模型（COCOMO）
• 软件开发工作量预估
• Mark II方法（英语：MK II FPA）
• 物件点（英语：Object point）
• 软件规模（英语：Software Sizing）
• 源代码行数
• 使用案例点（英语：Use Case Points）