聊聊功能点分析FPA︱敏捷软件开发

功能点分析（FPA）是度量信息系统功能规模的一种方法。FPA通过查看业务中与用户相关的（功能性）事务和（逻辑）数据文件来度量功能规模。FPA使用的度量单位是“功能点”，信息系统的功能规模用功能点数表示。

FPA通常在为系统开发项目做预算时使用。信息系统的开发成本与它的规模有关：系统越大，开发成本就越高。一个组织根据以往项目的经验，就能推算出一个人实现一个功能点（平均）需要多少小时，我们称之为生产率。那么规模（功能点数）x生产率（每个功能点所需小时数）就可以作为项目预算的基础。

FPA可用于新的开发项目，也可用于功能增强的项目

FPA是一种快速的方法，无需计算机知识。如果有合适的文档，执行FPA并不需要太多时间。据估算，对于一个需要1000个开发小时的系统，FPA可以在大约1小时内完成。 

FPA能提供什么？

“功能点”是唯一能够具体客观地讨论待开发信息系统规模的度量单位。像“系统有314个功能点”这样的语句就比“它是一个相当大的系统”能提供的信息量大很多。

正因为如此，使用“功能点”作为度量单位（当然还要辅以其他手段），能够提供如下好处：

01更好更早进行项目成本估算和预算

利用功能性的用户需求，就可以确定信息系统的功能规模（功能点数）。利用过去已完成项目的实际经验，可以确定项目的预期生产率（每功能点的小时数）。通过计算规模和预期生产率的乘积，就可以为系统开发的项目预算打下坚实的基础。

02更好地控制项目

功能性用户需求的变化可以用功能点来度量其规模，使其具体化、量化并可控。

03更好地沟通系统开发项目

如果两个人同时进行功能点分析，计算的功能点数却不一样，这说明他们对系统的功能性用户需求有不同的理解。由此可见，通过执行FPA，就能够很容易识别不清楚或不完整的功能性用户需求。 

04度量生产力

实际花费的开发小时数除以信息系统的功能点数，就可以得出项目的实际生产率。我们可以将其与标准生产率进行比较，进行差异分析，从而对未来项目提出具体的控制和改进措施。

05度量信息系统质量

单位时间内每个功能点的错误数是度量信息系统质量的一个指标。

06提高系统开发过程的质量

通过以上对生产力和质量进行的分析改进，能够减少沟通中的问题，同时又引入了新的控制措施，从而可以提高软件开发过程的质量。 

FPA不提供什么？

FPA不是项目管理方法；

FPA不会自动提供无错误的项目估算，不过它确实在项目预算编制过程中提供了重要支持；

FPA不是项目规划方法。

在项目的哪些阶段可以执行FPA？

一旦了解了信息系统的高层级功能性用户需求，就可以执行FPA。最关键的是要知道功能性的用户事务的数量以及概念数据模型。

FPA的执行可以在建议/可行性调研阶段，也可以在需求/分析阶段，当然，在功能设计阶段更是没有问题的。在项目生命周期的早期阶段，可能需要使用指示性（indicative）或估算的功能点数来执行FPA估算，因为执行（详细）FPA所需的信息在这个阶段可能无法提供。

使用FPA可以估算哪些项目阶段？

FPA可以估算系统开发生命周期中每个阶段的开发工作。事实上，根据过去的经验，我们知道在项目的每个阶段中平均每个功能点需要多少小时。

例如对于系统开发构建阶段，FPA能够给出很好的估算，因为该阶段的活动非常具体，项目之间也比较相似。

在信息系统的运行阶段，人们可以使用FPA来估算信息系统的运营成本，即每年每个功能点所需小时数。

什么样的项目可以使用FPA？

人们可以将FPA用于新系统开发或功能增强项目。需要注意的是，在功能增强项目中，实现某些功能可能需要做额外的技术工作（因为现有系统的构造有可能无法直接支持功能的增强，需要什么样的项目可以使用FPA？进行额外的改造才行）。重点来了，FPA度量的是实际交付了多少功能，而我们把做额外技术修改的小时数也计算在内，这样一来，与标准交付速率相比，项目的预期生产率就降低了（因为每个功能点需要更多的小时数）。

功能点有多敏捷？

许多组织已经意识到，他们可以使用功能点对软件项目进行估算，从而更好地掌控软件项目。同时，我们也看到越来越多的组织采用敏捷的工作方式，通常是使用Scrum。那么最大的问题来了：在敏捷环境中，功能点还能用吗？Scrum会把功能点扔一边儿去吗？功能点在敏捷世界中还有价值吗？在该博客中，Jolijn Onvlee和Rini van Solingen展示了敏捷和功能点的相爱相杀。

敏捷/Scrum

敏捷（以Scrum为最常用的方法），作为解决大型IT项目失败境况的一剂良方，被越来越多的组织所接受。通过直接开始交付软件（译者注：而不是先花数月写上300页的需求文档），每两周客户就可以直接了解项目进度，能够看到交付的价值。用户不再为了能够用上最高业务价值的功能而进行漫长的等待。此外，持续的反馈信息流，能够让我们更快地交付更有价值的可用系统。事实上，随着Scrum的使用，一个大的IT项目被分成许多小项目，这样就能够更容易对新的想法做出响应，并能够大大降低整个项目的复杂性。

Scrum以完全不同的方式处理系统规格说明。在Scrum中，仅仅使用一个笼统的术语（我们称之为产品待办事项列表）来描述产品。然后呢，只对那些具有最高业务价值的部分进行详细设计，并且快速交付。在这之后，确定剩余工作中具有最高业务价值的部分，然后开发和交付，周而复始，这样就可以进行持续的调整。这颠覆了原来期待项目只是交付预先定义的工作的想法。在这种情况下，对整个交付范围进行估算就不靠谱了，因为我们无法在最开始就能够将整个范围拆解的那么细。

分歧

Scrum处理估算和预算的方式与更传统和系统的方法不同。传统的方法通常使用功能点分析（FPA）进行量化，FPA用于估算软件开发成本和交付时间，功能点是用于度量系统规模的一个指标。这个规模的估算基于系统的功能规格说明书。要使用FPA，就需要对系统的细节了解到一定程度。

因此，功能点和Scrum看起来是没有办法好好在一起玩耍了。毕竟一个想要提前得到完整的需求规格说明书，而另一个又希望在任何时候都能够对需求规格提出质疑并进行更新，还不想搞得太详细。Scrum方法中的Sprint实在太短，变化又太大，根本没有办法基于功能点进行估算。可是呢，在敏捷组织中，也是需要控制成本啊。“别着急，活干完了就知道成本是多少了”对于大多数组织来说是不可接受的。这就意味着敏捷会在IT支出上造成无政府状态，这可不成。即使使用Scrum，客户也是需要掌控的，怎么可以裸奔。产品负责人需要对所有工作投入（目标）的产出以及最终花费的时间和金钱（预算）了然于胸。而这正是传统FPA能够解决的。 

相似之处

如果你仔细研究FPA和Scrum的结合，就会发现它们相互加强而不是相互削弱。毕竟，FPA有助于确定总体范围和适当的预算。Scrum能够帮助我们在预算内首先实现具有最高业务价值的功能。这样，对于系统的反馈能够以最快的速度进入到交付过程中。反馈有两个方面：一是总体范围是否正确，二是整个问题能否在预算内解决。

实际上，这意味着项目的待办事项列表是在全局级别上确定的。在Scrum中，通常的做法是，产品中具有最高业务价值的部分具有大量的细节，拥有这些细节信息的工作（最好是好几个Sprint的工作）通常足以进行功能点分析。接下来，就可以使用这个分析结果来推测整个待办事项列表的功能点总数。在FPA方法中，这是允许的。

Scrum和FPA是朋友

总之，Scrum和FPA可以很好地相互帮助和加强。功能点帮助你控制总开支，而使用Scrum，你可以基于新的洞察保持灵活性。最终你就可以解决整个问题。简直是多快好省！在这方面，功能点和Scrum的目标是相同的。

所以Scrum和FPA是朋友，失控和超支是（共同的）敌人！

速赢

在Scrum和功能点的结合中速赢：

1产品待办事项列表更快变得具体

产品待办事项列表描述了所有未实现的需求。在产品待办事项列表的顶部，是对业务来说最重要的条目，只有这些条目才会进行细粒度拆解。使用FPA，可以让产品待办事项列表的规模变得更加具体，因为FPA能够展示我们要做的功能都是什么。因此，FPA是从功能角度对产品待办事项列表进行了总结。

2目标可度量

前6个Sprint的详细产品待办事项列表足以用来做FPA估算（ISO/IEC 24570 Nesma功能规模度量方法），估算出来的功能点数量可以用于推测总功能点数。这样，可以对最终目标进行量化，最终结果也是明确的，无需整个产品的详细规格说明书。

3交付的价值更容易度量

团队交付软件的速度是以故事点来衡量的，这是对工作规模的相对估算。我们千万不要把故事点和功能点搞混，它们甚至长得都不像（当然，名字还是挺像的）。功能点是外向型的，考虑整个项目；故事点是内向型的，有助于防止Scrum团队吃得太多。然而，在Scrum中，很难表达交付的价值，而这正是功能点所擅长的，它可以完美搞定！

4帮助确定功能的优先级

Scrum的一个重要方面是确定最高业务价值的功能，下一个Sprint的工作就从这些功能中选择。根据估算的FPA来度量整个愿望列表（以及在这个愿望列表中的下几个Sprint）就变得很容易了，这种方法也可用于功能分组。这样，我们就能记录下来总体情况，并且所有的改变都是可追踪的。

5协助做估算

估算是团队的任务。做估算总是一件棘手的事情，毕竟团队没有魔法水晶球（译者注：用通天的法力预测未来），而且你也知道，以前大家把估算当承诺来用。Scrum使用故事点进行估算，但这些都是相对估算：团队可以用故事点和自己比，但是不能和其他团队比。然而，功能点是绝对估算，能够和其他团队进行比较。功能点在不同的项目之间可以进行比较，不仅可以事先度量，还可以在项目期间以及完成之后进行度量。因此，团队在进行估算时会从功能点得到额外的帮助。

6看出改进

因为FPA提供了客观的度量，所以在Scrum回顾会中，我们可以借助功能点来彰显改进的状况。所以你可以因此帮助团队相互学习，找出阻碍改进的主要因素。

7为Scrum确认商业案例

虽然许多组织都对Scrum充满热情，但是通过小道消息，我们也能听到很多流言蜚语，说Scrum流程带来了更多的返工（因为用户看到软件后又提出很多新的想法和修改意见），这让Scrum流程的代价变得更加高昂。我们通过度量新增以及改进功能的功能点数量，就能够对整个过程中以及不断调整中的生产力心中有底。这样就可以对商业案例客观地进行准确的计算。

该博客最初是作为一篇评论文章发表在AutomatiseringGids （使用荷兰语发表）上的。

Allan Albrecht的思想

根据软件的“功能”而不是“物理组件”（译者注：比如代码行数）来度量软件规模的想法是由IBM的Allan Albrecht在1979年首次提出的。他提出了一种称为“功能点分析（FPA）”的方法，后来发展成为“IFPUG”方法——此方法的定义现在由国际功能点用户组（International Function Point Users Group, IFPUG）管理。

Albrecht聪明的横向思维为“功能规模度量（Functional Size Measurement, FSM）”这一主题奠定了基础。

IFPUG方法实际上有两个组成部分，第一部分涉及功能规模的度量，第二部分涉及14个技术和质量因素对总规模的贡献的度量。Albrecht最初的方法在过去30年中得到了显著的改进，但其基本概念与70年代中期相比没有变化。尽管IFPUG方法仍然是最广泛使用的FSM方法，但它仅限于业务应用软件领域。

其他第一代方法的发展

人们对Albrecht/IFPUG方法进行了一些发展，以期对规模度量这一工作做出改进，或者扩展其适用范围。我们称之为“第一代”FSM方法（见下文）。值得注意的是以下几个：

Capers Jones在Albrecht的基础上发表了一种称为“特性点（Feature Points）”的方法，旨在将FSM扩展到科学算法中。由于计算数学算法固有的困难，该方法已被大量抛弃。

Charles Symons开发了“MkII功能点方法”，旨在通过更好地考虑“富数据（data-rich）”业务应用软件的内部复杂性来改进Albrecht的方法。

波音公司的Scott Whitmire利用Albrecht的通用方法开发了“3D功能点”来确定业务应用程序和实时软件的规模。该方法的细节仍归波音公司所有。

荷兰软件度量协会（Nesma）发布了IFPUG方法的变体，旨在简化一些规模度量规则。

魁北克大学、蒙特勒艾尔大学和其他大学出版了“全功能点法”，该方法对业务应用软件使用IFPUG规则，并添加了额外的组件来确定实时软件的规模。

功能规模度量的国际标准化

同时，1994年前后，ISO/IEC第一联合技术委员会第七分委员会（软件工程）成立了一个新的“第12工作组（简称WG/12）”，以寻求建立功能规模度量的国际标准。WG/12很快确认，当时没有一种现有的方法适合作为世界标准采用，因此着手制定FSM的一些基本原则。这项工作导致了ISO/IEC 14143/1:1997的出版，题为“信息技术-软件度量-功能规模度量-概念定义”。14143系列中的其他标准和技术报告涵盖了诸如候选FSM方法的一致性测试和验证，以及FSM软件域类型的定义等主题。本标准到现在为止已更新至ISO/IEC 14143/1:2007。

COSMIC方法的发展

1998年，WG/12的一些成员在伦敦举行非正式会议，决定开发一种新的“第二代”FSM方法。不同之处在于，新方法的设计将仅从基本的既定软件工程原则开始（“第一代”FSM方法都使用软件功能的特定模型，并且都是根据开发各自功能组件的相对工作量进行校准的）。该小组能够借鉴过去的FSM方法的经验，并旨在从一开始就遵守ISO/IEC 14143/1:1997。该方法应该同样适用于MIS/业务软件、实时和基础设施软件（如操作系统软件）以及这些软件的混合。

伦敦会议的结果，就是成立了“COSMIC（Common Software Measurement International Consortium）”。

其方法的第一个版本“COSMIC-FFP v2.0”于1999年10月出版，这是第一个真正的“第二代”FSM方法。

2000/2001年期间进行了广泛和成功的实地试验。

COSMIC于2003年1月发布了该方法的2.2版。

2007年9月发布了3.0版。在这个版本中，这个方法的名字被简化为“COSMIC方法”。

随后的版本有一些进一步的改进，使其更容易理解，但自从第一次出版以来，该方法的基本原则没有变。

由于ISO/IEC JTC1/SC7做出了“由市场决定”打算，国际标准在2002/3年期间公布了COSMIC方法（ISO/IEC 19761）、IFPUG方法（ISO/IEC 20926）、MkII-FPA方法（ISO/IEC 20968）和NESMA方法（ISO/IEC 24570）。ISO/IEC 19761标准每几年修订一次，以与COSMIC方法的最新版本保持一致。（文章来源：徐伟东敏捷教练）