FPA笔记一 功能点分析法概述

1.   什么是功能点分析法（FPA）

 

功能点分析法，简称 FPA ，与代码行分析法是近年来最流行的两种基础软件规模估算和度量方法。

代码行估算法侧重技术角度，需要一定的基准数据支撑。基准数据越多，估算难度较小。代码行估算法与实现的技术，计算机语言密切相关。

功能点分析法侧重功能，在基准数据缺乏时也能进行，不过估算流程比较复杂。它完全独立于技术，且可以给用户量化的概念。

这里所说的功能点分析法，由 Allan J Albrecht 首先提出，又称 Albrecht 功能点分析法。除此之外，还有 Mark II FPA 和完全功能点等。但习惯上，人们说的功能点分析法就是 Albrecht 功能点分析法。

1.1.  功能点分析法的定义

官方文档 IFPUG CPM 4.2.1 给出功能点分析法的定义是： Function point analysis is a standard method for measuring software development from the user’s point of view.

具体来说， FPA 有这么几个特点：

l  它是一种适用于软件开发的度量方法。

l  它是一种标准的度量方法，由国际功能点用户组（ IFPUG ）维护和推动。

l  它从用户视角来度量产品规模。

l  它不注重产品的内部结构和技术复杂度。不过也并非完全无视这些因素。

FPA 标准的维护组织是国际功能点用户组 IFPUG ([url]http://www.ifpug.org[/url]) ，它不定期的发布 Counting Practices Manual ，简称 CPM 来统一不同公司和产品的功能点计算模型。这套模型基于大量已完成项目的分析数据，非常全面和精确。对于同一个产品，不同的公司，不同的人，参照 CPM 计算出来的功能点数应当是一样的。目前最新版本是 2005 的 CPM 4.2.1 ，现在三年未更新，计算模型已相当成熟。

1.2.  功能点的定义

什么是功能点？就是客户提出的一条条的需求吗？答案是否定的。在 FPA 中，客户提出的需求，是功能，功能组和产品；但不是功能点。

l  功能点是一个的度量单位，用于度量工作产品的规模。就像公斤和千米一样，仅仅是一个抽象化的单位。

l  功能点不直接度量软件的内部架构和技术复杂度。

l  单个功能点对用户没有意义，但一个功能包含多少个功能点对用户有意义。

l  一个系统，一个功能包含多少个功能点，是由一系列可见的要素分析计算得来，而不是拍脑袋的经验数字。

功能点分为两种：未调整功能点和调整功能点。未调整功能点是只记用户可见功能的中间结果，调整功能点是最终结果，在未调整后功能点基础上加入了系统实现和内部架构方面的因素。一般说一个系统包含多少个功能点，是指调整功能点。

1.3.  那些功能是用户可见的？

简而汇之，如下功能是用户可见的。

l  GUI ，如页面和窗体。

l  报表。

l  主要文件。

l  参考文件，引用文件。

l  控制文件。

l  数据输入。

 

2.   为什么使用功能点分析法

FPA 可以应用于所有的软件项目和软件身，包括新开发项目，升级项目，应用程序，维护项目等。 FPA 的基本目的有两个：

l  度量用户要求和接收到的功能

l  为软件的开发和维护而度量其技术独立度。

2.1.  功能点分析法的用途

软件度量的用途非常广泛，从客户，老板，管理人员，到程序员，都需要软件度量数据。 FPA 作为一种软件度量方法，主要有三方面的用途：持续的过程改进，软件资产管理，项目管理。

2.1.1.      持续的过程改进

FPA 支持用于软件质量分析与生产力分析的量化指标，比如每功能点的平均 bug 数，每功能点的平均人天数，等等。

分析这些量化指标，可以找到过程改进的机会；可以度量改进的效果。无论是组织还是个人，都需要持续的过程改进。具体来说， FPA 可这个过程中发挥如下作用：为现状提供基线数据。

1)         为改进决策提指明方向。

2)         为具体行动提供指南。

3)         度量改进的结果。

4)         将改进的结果基线化，进入下一轮改进。

可能改进的机会，英语是 Improvement Opportunities 。这里的 Opportunities 用的很好，可惜中文的译词“机会”很难让人理解。习惯上是说“值得改进的地方”。

2.1.2.      软件资产管理

FPA 为组织的软件资产提供了量化的指标。

l  软件资产的总规模

l  软件资产的增长率

l  软件资产的维护成本

l  软件资产的代换成本

对于软件开发和服务组织，这些指标可为软件资产的维护策略提供决策依据：是重新开发，重构系统，重写代码但不改结构，还是继续维护。

对于使用软件的组织，这些指标可作为采购的参考：是自行开发，还是采购？采购的合理价格区间，目标采购包的功能符合度。

FPA 为应用软件之间的功能比较提供了规范化指标。

 

 

2.1.3.      项目管理

(1)    估算开发或维护的成本，资源，为项目计划提供依据。

(2)    估算需求变更的成本和对项目的影响。

(3)    控制需求范围。

 

2.2.  功能点分析法的优点

l  基于定义良好的计算标准。

l  基于客户视角。容易理解和接受。

l  可应用于新项目，升级项目和维护项目。

l  与技术和计算机语言无关。

l  简单，易于计算，只需花费较少的工作量。

l  一致的规模度量尺度。可用来比较不同组织和技术之间的比较。

2.3.  功能点分析法的缺点

l  只考虑可见部分的复杂度，对系统内部复杂性考虑太少。

l  功能复杂度三级划分比较武断。对一些比较复杂的功能，统计误差较大。

l  FPA 知识简单假设全部是部分的和，没有考虑系统集成带来的额外开销。

 

在 FPA 的基础上，还有一种 MARK II 功能点分析法，它能克服一些功能点法的缺陷。

2.4.  功能点分析法的度量描述举例

(1)    今年我们的生产率提高了 20% ，从每月 10 个功能点提高到 12 个功能点。

(2)    通过质量检视，我们交付的软件缺陷率由每功能点 2 个缺陷，减少到每功能点 0.5 个缺陷。

(3)    我们的项目进度估算准确率显著提高，实际人天数和估算人天数的误差 +45% 减小到 +15% 。

(4)    我们的应用软件包对相关业务的支持增加了 10% ，原来是 50K 功能点，现在是 55K 功能点 .

(5)    由于我们调整了维护策略，工程师人均维护的功能点数从 1000 提高到 1500. 从而节省了 $3M 的成本

(6)    由于提高了客户需求技术，我们把需求蔓延率从 35% 降到 10% 。

(7)      根据功能点分析的结果，我们购买一个软件包，比自己开发节省了 $1M.

 

 

3.   功能点分析法与软件生命周期

功能点分析必须渗透于作为软件生命周期的全部，而不仅仅是项目开发阶段。不同阶段的功能点分析有不同的目的，参与人员和相关材料。

 

3.1.  软件生命周期

FPA 将软件生命周期划分为六个阶段，与通常意义的软件生命周期基本相同。只不过有些具体名称上不同。比如：方案阶段又叫概念阶段，构建阶段又叫实现阶段。

构建阶段 Construction

交付阶段 Delivery

维护阶段 Maintenance

设计阶段 Design

需求阶段 Requirement

方案阶段 Proposal

 

有四个阶段应当进行功能点分析：方案阶段，需求或设计阶段，交付阶段，维护阶段。每个阶段的功能点分析都有不同的目的。

FPA 不是某一个人的工作，而是整个团队的工作。无论哪个阶段的 FPA ，都需要多种角色的参与。主要参与角色有：

l  客户或客户代表

l  项目经理

l  系统架构师

l  程序员（方案阶段可能没有程序员）

l  文档专家：负责整理文档的苦力。

l  应用方案经理：可能是项目经理，也可能管理好几个项目经理。

l  应用方案专家：估计 Reviewer, 挑刺的家伙。

l  度量分析员：可能和文档专家是同一个人。

l  功能点分析专家：一般是 QA ，主持分析过程。

l  功能点委员会：估计是 Reviewer, 挑刺的家伙。

每次进行 FPA 时，除了需要相应的项目文档外，还建议准备好如下 FPA 的指导文档：

n  IFPUG Counting Practices Manual

n  所在组织的 FAP 指导文档。

n  FPA 分析表。

n  自制一张简明指南卡： Quick Reference Card 。

 

3.2.  在方案阶段估算功能点

在方案阶段后期，可以采用 FPA 方法来估算软件的规模和项目的开发成本。具体来说有三个目的：

l  FPA 的过程可协助双方（用户和开发人员）把高层需求条理化。

l  得到较为明朗的项目的范围。

l  粗略的估算功能点数，并折算为开发成本和进度。为制定项目计划提供依据。

在此阶段只有一些非常原始，抽象的客户需求。所以估算的精度有限。此阶段可参考的项目文档有：

l  高层需求文档

n  高层系统架构（功能，数据存储，接口）。

n  高层逻辑数据模型。

n  高层业务模型。

n  业务用例（可选）。

l  历史项目或应用软件的功能点统计数据（可选）。

 

3.3.  需求或设计阶段二次估算功能点

在完成需求规格或概要设计时，如发现需求和范围较之方案阶段有较大的变化，估算的功能点不够精确，可在设计阶段的进行二次估算。其目的有三：

l  重新定义客户需求。

l  重新估算开发进度和成本。

l  度量项目范围的变更，如需求蔓延率。

实际上，只要项目范围发生了大的变化，就应当重新估算，最好不要超过三次。在设计完成后，项目范围已经基线化，如发生需求变更，只需估算变更部分，不要全部推到重来。

二次估算，除了需要初次估算的所有文档外，还需要如下项目文档：

l  需求规格。

n  业务用例

n  屏幕界面规划（ Layout ）

n  报表规划（ Layout ）

n  文件和数据库规划（ Layout ）

n  数据流：系统接收和发出的数据。

l  功能设计，也就是概要设计。

3.4.  交付阶段度量最终功能点

交付阶段，所有的开发工作都已结束，需求和功能设计自然也就全部冻结。此时应进行最终的实际功能点度量。其目的有四：

l  在交付文件中报告实际的功能点数。

l  度量项目范围的变更，如需求蔓延率。

l  回顾项目实施情况。

l  发布统计数据，作为组织的基线。

度量功能点，需要参考项目的全部需求和设计文档。同二次估算相比，可能增加了如下文档：

l  功能设计规格。

l  详细设计规格。

l  用户手册。

3.5.  维护阶段度量资产功能点

系统交付后，就会进入公司的 IT 资产库。此时需要从资产管理的角度度量一些数据。

l  审计资产功能点。

l  文档化。

l  确定维护策略。