功能点
功能点是一个“测量单位”，以表达信息系统（作为产品）为用户提供的业务功能的量。功能点用于计算软件的功能尺寸测量（FSM）。单个单元的成本（以美元或小时为单位）是根据过去项目计算的。
标准
基于功能点，有几种公认的标准和/或公共规格，用于尺寸软件。
1. ISO标准
- FISMA：ISO/IEC 29881：2010信息技术 - 系统和软件工程 - FISMA 1.1功能尺寸测量方法。
- IFPUG ：ISO/IEC 20926：2009软件和系统工程 - 软件测量 - IFPUG功能尺寸测量方法。
- Mark-II：ISO/IEC 20968：2002软件工程 - ML II功能点分析 - 计数实践手册
- NESMA：ISO/IEC 24570：2018软件工程 - NESMA功能尺寸测量方法版本2.3 - 适用功能点分析的定义和计数指南
- 宇宙：ISO/IEC 19761：2011软件工程。功能尺寸测量方法。
- OMG ：ISO/IEC 19515：2019信息技术 - 对像管理组自动化功能点（AFP），1.0
前五个标准是实现功能尺寸测量ISO/IEC 14143的标准标准。OMG自动化功能点（AFP）规范，由财团的IT软件质量联盟领导但是，对于国际功能点用户组（ IFPUG ）的指南，该标准的当前实现有限制，即能够将外部输出（EO）与外部查询（EO）（EO）（EO）（eq）（EQ）区分开，而无需进行前期配置。
介绍
1979年，在IBM的Allan Albrecht测量应用程序发展生产率方面定义了功能点。标识了软件的功能用户要求，每个软件的功能要求分为五种类型之一：输出，查询，输入，内部文件和外部接口。一旦识别该功能并将其分类为一种类型，然后将其评估为复杂性并分配了许多函数点。这些功能用户需求中的每一个都映射到最终用户业务功能，例如输入的数据输入或查询的用户查询。这种区别很重要，因为它倾向于使功能在功能点中的函数轻松地映射到面向用户的要求中，但是它也倾向于隐藏内部功能（例如算法），这也需要资源来实现。
当前尚无ISO识别的FSM方法，该方法在大小结果中包含算法复杂性。最近，已经提出了不同的方法来应对几种商业软件产品中实施的这种感知的弱点。旨在弥补这一点（和其他弱点）的基于Albrecht的IFPUG方法的变化包括：
- 早期和简单的功能点 - 通过两个问题调整问题和数据复杂性，这些问题产生了一些主观的复杂性测量；通过消除计算数据元素的需求来简化测量。
- 工程功能点 - 元素（可变名称）和运算符（例如，算术，平等/不平等，布尔值）。这种变化突出了计算函数。该意图类似于基于操作机/操作数的Halstead复杂性度量的意图。
- BANG测量 - 定义一个基于影响或显示bang的十二个原始（简单）计数的函数度量，定义为“用户所感知的要交付的真实函数的度量”。爆炸量度可能有助于评估软件单元的价值，尽管文献中几乎没有证据表明，但该应用程序提供了多少功能。如维护操作系统的维护（概述）所讨论的那样，考虑重新设计（完整或分段）时，可以使用爆炸措施的使用。
- 特征点 - 增加更改以提高具有重要内部处理（例如，操作系统，通信系统）的系统的适用性。这允许用户不容易感知功能，但对于正确操作至关重要。
- 加权微功能点- 一种较新的型号（2009），它使用从程序流量复杂性，操作数和操作员词汇，对象使用和算法得出的权重调整功能点。
- 模糊功能点 - 提出了低x中和中等x高复杂性之间的模糊和渐变过渡
对比
使用功能点来支持代码行的使用点试图解决其他几个问题：
- 如果开发人员被激励以提高生产力，则创建的代码线“通货膨胀”的风险，从而降低了测量系统的价值。 FP倡导者将其称为测量解决方案的大小，而不是问题的大小。
- 代码（ LOC ）措施的行奖励低级语言，因为需要更多的代码行以向更高级别的语言传递类似数量的功能。 C. Jones提供了一种在他的工作中纠正这一点的方法。
- 在项目早期阶段，估计将要交付的代码线数量的早期项目阶段没有用。但是，功能点可以从需求中得出，因此在诸如代理估计之类的方法中很有用。
批评
阿尔布雷希（Albrecht）在他的研究中观察到，功能点与代码线高度相关，如果可以使用更客观的度量，即计数代码线，这导致了对这种度量的价值的质疑。此外，通过增强计数方案，已经进行了多次尝试解决该措施的缺点。其他人则通过开发替代方法来避免挑战的解决方案，从而为交付的功能量创造代理。