功能点过程

一无所有

功能点过程
Adams Wang
本规程的目的是基于软件需求产生软件规模的估计。功能点是基于应用软件的外部、内部特性以及软
件性能的，一种间接的软件规模的测量。功能点与软件成本具有重大的成本估计关系（CER：Cost Estimating
Relationship）。功能点可以作为经验统计参数化软件成本估计公式和模型的输入，以对软件的成本进行估
计。功能点方法被广泛的认可在信息系统、数据库密集型、4GL应用系统开发的规模测量。
功能点是对软件功能和规模的间接定量测量，它基于客观的外部应用接口和主观的内部应用复杂度以
及总体的性能特征。该规程由三个逻辑部分组成：决定未调整的功能点计数、加权因子和功能点。
决定未调整的功能计数包括对外部输入、外部输出、外部查询、内部逻辑文件和外部接口文件的计数。
决定加权因子包括划定系统、输入和输出、应用复杂度的级别。决定功能点包括将未调整的功能点和加权
功能点具有两个独立的目标。第一个目标是作为软件测量、对比和分析（如，软件度量方法）的基础。
第二个，也是更重要的目标是作为软件成本估计模型（如，公式）和产出工作量（如，工时）工具的输入，
软件成本估计模型和工具则基于功能点和工作量之间的经验成本估计关系（CER）。
角色和职责
任务经理： 任务经理负责为软件成本估计进行对功能点的估计。任务经理必须基于外部应用接口估计
未调整功能点，和基于应用程序的复杂度和性能对加权因子进行估计。任务经理必须辅助决定功能点以
及从技术人员处获取输入。
非程序员●第六期●过程●功能点过程
http://www.umlchina.com 57
下列任务承担责任：
   6.1 决定未调整功能点计数
   6.2 决定加权因子
   6.3 决定功能点
4 输入
事务和文件清单： 应用软件功能和规模的间接的定量测量基于外部应用接口客观的数量，如：外部输
入、外部输出、外部查询、内部逻辑文件和外部接口文件。
   外部输入：数据由外向内跨越边界的基本处理过程。数据可能来自于数据输入屏幕、电子输入或
其它应用程序。数据可以是控制信息或业务信息。如果数据是业务信息，它用于维护一个或多个
内部逻辑文件。如果数据是控制信息，它不必更新内部逻辑文件。
   外部输出：导出的数据由内向外跨越边界的基本处理过程。数据创建发送给其它应用的报表或输
出文件。这些报表和文件由一个或多个内部逻辑文件和外部接口文件所创建。
   外部查询：包括输入和输出构件的基本处理过程。输入和输出构件导致一个或多个内部逻辑文件
和外部接口文件的数据检索。该信息被发送出应用程序边界。输入过程不会更新任何内部逻辑文
件以及输出不包含导出的数据。
   内部逻辑文件：完全驻留在应用程序内部的逻辑相关数据的用户可识别的组，通过外部输入所维
护。
   外部接口文件：仅用于引用目的的逻辑相关数据的用户可识别的组。数据完全驻留在应用程序外
部，由其它应用程序所维护。外部接口文件是其它应用程序的内部逻辑文件。
下列任务需要输入条件：
   6.1 决定未调整功能点计数
系统的总体特性： 间接和主观的应用软件功能和规模的测量基于内部应用复杂度和整体性能特性级别
的划分，如系统、输入和输出以及应用复杂度。
以下的任务需要输入条件：
   6.2 决定加权因子
非程序员●第六期●过程●功能点过程
http://www.umlchina.com 58
5 输出
功能点： 功能点作为软件成本估计基础，是软件规模、功能和复杂度的测量。
下列任务需要输出条件：
   6.3 决定功能点
6 步骤
6.1 决定未调整功能点：
决定未调整功能点的数目包括对外部输入、外部输出、外部查询、内部逻辑文件和外部接口文件的计
数。
6.1.1 决定外部输入：
外部输入是数据由外向内跨越边界的基本处理过程。数据可能来自于数据输入屏幕、电子输入或其它
应用程序。数据可以是控制信息或业务信息。如果数据是业务信息，它用于维护一个或多个内部逻辑文件。
如果数据是控制信息，它不必更新内部逻辑文件。
对于低、平均或高，将数目分别乘以3、4或6。
6.1.2 决定外部输出：
外部输出是导出的数据由内向外跨越边界的基本处理过程。数据创建发送给其它应用的报表或输出文
件。这些报表和文件由一个或多个内部逻辑文件和外部接口文件所创建。
对于低、平均或高，将数目分别乘以4、5或7。
6.1.3 决定外部查询：
外部查询是包括输入和输出构件的基本处理过程。输入和输出构件导致一个或多个内部逻辑文件和外
部接口文件的数据检索。该信息被发送出应用程序边界。输入过程不会更新任何内部逻辑文件以及输出不
包含导出的数据。
对于低、平均或高，将数目分别乘以3、4或6。
6.1.4 决定内部逻辑文件：
内部逻辑文件是完全驻留在应用程序内部的逻辑相关数据的用户可识别的组，通过外部输入所维护。
非程序员●第六期●过程●功能点过程
http://www.umlchina.com 59
对于低、平均或高，将数目分别乘以7、10或15。
6.1.5 决定外部接口文件：
外部接口文件是仅用于引用目的的逻辑相关数据的用户可识别的组。数据完全驻留在应用程序外部，
由其它应用程序所维护。外部接口文件是其它应用程序的内部逻辑文件。
对于低、平均或高，将数目分别乘以5、7或10。
6.1.6 决定未调整功能点总数：
将带有权重的外部输入、外部输出、外部查询、内部逻辑文件和外部接口文件总和在一起。其结果即
为未调整功能点。
6.2 决定加权因子子:
决定加权因子包括划系统复杂度、输入和输出复杂度和应用复杂度的级别。
6.2.1 划分系统复杂度级别：
采用0~5的分值划分每个系统复杂度，分别代表无影响（no influence）、偶尔（incidental）、适度
（moderate）、平均（average）、重大（significant）和根本（essential）。
6.2.1.1 划分数据通讯复杂度的级别：
具有多少数据通讯设备？
数据通讯描述了应用软件与处理器直接通讯的程度。应用软件使用的数据和控制信息在数据设备上发
送和接收。局部直接与控制单元连接的终端被认为会使用通讯设备。协议是一系列规约，它允许在两个系
统和设备之间传输或交换信息。所有的数据通讯链接需要某种协议。
以下是记分的指南：
0 应用软件是单纯的批处理或独立的PC。
1 应用软件是批处理，但具有远程的数据入口或者远程打印。
2 应用软件是批处理，但具有远程的数据入口和远程打印。
3 应用软件包括在线连接至批处理或查询系统的数据搜集或TP（远程处理）终端。
4 应用软件不仅仅是终端，并且支持一种通讯协议。
非程序员●第六期●过程●功能点过程
http://www.umlchina.com 60
5 应用软件不仅仅是终端，并且支持多种通讯协议。
远程处理现在非常普遍。仅仅10%的项目是“低于平均”的分值2或以下；56%则具有“高于平均”
的分值4或5。
对银行项目和个人PC开发的项目，该分值较低。从1991至1996，它具有持续降低的趋势，从高于平
均水平降至平均水平。
6.2.1.2 划分分布式处理复杂度的级别：
分布式数据和功能如何被处理？
分布式数据处理描述了应用软件在各个组成部分之间数据传送的程度。分布式数据或功能处理是应用
软件边界内部的一种特性。
以下是记分的指南：
0 应用软件无系统组件之间的数据传输或功能处理。
1 应用软件为系统其它组件上的最终用户处理，如PC电子表格或PC DBMS准备数据。
2 数据为传输做出准备，接着被传输以及在其它系统组件上被处理（并非最终用户处理）。
3 单方向的在线的分布式处理和数据传输。
4 双向的在线的分布式处理和数据传输。
5 功能处理动态的在相应的系统组件上执行。
在所有的常见系统特征中，该值取“低于平均值”具有非常大的比例。其统计分布是双峰值的：系统
要么是单机，或者分布式处理是作为系统一种比较重要的特性。
在工程系统中往往具有更多的分布式处理。分布式处理在中范围的平台上较其它平台上更为普遍。分
布式处理在交易/生产系统和办公信息系统中较管理信息系统和决策支持系统更为普遍。新的开发项目较改
进项目中更重要一些。
6.2.1.3 划分性能复杂度的级别：
用户对响应时间或吞吐量是否有所要求？
非程序员●第六期●过程●功能点过程
http://www.umlchina.com 61
性能描述了对响应时间和吞吐量性能方面考虑对应用软件开发的影响程度。用户以响应或吞吐量所陈
述或认可的性能目标，影响着（或将影响）设计、开发、安装以及支持。
以下是记分的指南：
0 用户没有特殊的性能需求。
1 性能和设计需求被陈述和评审，但不需要特殊的活动。
2 响应时间或吞吐量在峰值时间是关键的。对CPU利用没有特殊的设计。处理的极限在日后考虑。
3 响应时间或吞吐量在所有的工作时间是关键的。对CPU利用没有特殊的设计。与其它交互系统处理极
限方面的需求是强制的。
4 迫切的用户性能需求，要求在设计阶段进行性能分析方面的工作。
该特征具有较分散的分布：32%的项目低于平均值，30%的项目处于平均水平，38%的项目高于均值。
性能对于交易/生产系统较管理系统更为重要。新的开发项目较改进项目中更重要一些。
6.2.1.4 划分配置项负载复杂度的级别：
对当前的硬件平台的使用程度？
配置项的使用程度描述了计算机资源对应用软件开发的影响程度。需要特殊设计考虑的满负荷运行的
操作配置，是应用软件的一个特征。例如，用户想在现有的或指定的满载设备上使用应用软件。
以下是记分的指南：
0 没有明显的或隐式的操作限制。
1 存在操作约束，但限制较典型的应用较小。限制不需要特殊的工作。
2 存在某些安全性或时序的考虑。
3 特殊应用软件部分存在特殊的对处理器的需求。
4 所要求的操作限制对中心处理器或主要处理器上的应用软件需要特殊的限制。
5 另外，在系统的分布式组件上存在特殊的限制。
本特性的分值普遍较低：66%低于均值，20%处于平均水平，14%高于均值。
非程序员●第六期●过程●功能点过程
http://www.umlchina.com 62
交易/生产系统和办公信息系统的分值较管理信息系统和决策支持系统低。新的开发项目较改进项目
中低；中等项目较其它平台高；工程系统较高。从3GL项目至4GL项目，分值会增高。
6.2.1.5 决定系统复杂度的级别：
4个带权重的分值相加即为系统复杂度。
6.2.2 划分输入和输出复杂度的级别：
采用0~5的分值划分每个输入和输出复杂度，分别代表无影响（no influence）、偶尔（incidental）、
适度（moderate）、平均（average）、重大（significant）和根本（essential）。
6.2.2.1 划分事务率复杂度：
事务执行的频繁程度？
事务率描述了业务交易（事务）影响应用软件开发的程度。如果事物率高，它会影响设计、开发、安
装和支持。
以下是记分的指南：
0 预计没有峰值的事务处理周期。
1 预计存在峰值的事务处理周期（如：月、季、年）。
2 预计每周存在峰值的事务处理。
3 预计每日存在峰值的事务处理。
4 用户需求中要求高的事务率或者服务级别的约定足够的高，要求在设计阶段进行性能分析。
5 用户需求中要求高的事务率或者服务级别的约定足够的高，要求在设计阶段进行性能分析。另外，需
要在设计、开发和/或安装阶段使用性能分析工具。
事务率的分值在分布在0~4的范围内；5分情况较少。
事务率在银行系统中较一般情况重要性高，在工程系统中则较低。在大型机其它平台重要性高。尽管
可能期望对于事务/生产系统而言，重要程度高一些，但在应用类型之间没有重大的差别。从1991年至1996
年，该分值有着稳定的提高。
非程序员●第六期●过程●功能点过程
http://www.umlchina.com 63
6.2.2.2 划分在线数据项复杂度：
百分之多少的信息是在线输入的？
在线数据项描述了数据通过交互式事务输入的程度。应用软件提供在线数据项和控制功能。
以下是记分的指南：
0 所有的事务以批处理的形式处理。
1 1%至7%的事务是交互式数据项。
2 8%至15%的事务是交互式数据项。
3 16%至23%的事务是交互式数据项。
4 24%至30%的事务是交互式数据项。
5 超过30%的事务是交互式数据项。
直到现在，该特性在所有的调整因子中是最高的，并且变化是最少的。60%的项目对该特性的取值为
5分，最大的可能值。
根据IFPUG指南，5分意味着超过30%的事务包括交互式数据项。对于现在而言，作为阀值可能30%
过低；较高的取值可能能够提供更有用的区别。
对于单个机构COBOL!主机/银行项目，该分值较低（通常3分）。而5分的取值近乎适用于其它一切情
况。
6.2.2.3 划分用户使用效率复杂度：
应用软件是否就最终用户使用效率上有所设计？
最终用户使用效率描述了对人为因素和应用软件用户的易用性的考虑程度。在先功能强调了最终用户
使用效率的设计（如，漫游帮助、菜单、在线帮助和文档、自动游标移动、滚动条、在线事务的远程打印
以及预定义功能键）。
以下是记分的指南：
0 无
1 上文中的1或3项。
非程序员●第六期●过程●功能点过程
http://www.umlchina.com 64
2 上文中的4或5项。
3 上文中的6项以上，但无特定相关于使用效率的用户需求。
4 上文中的6项以上，用户使用效率的需求要求就人的因素安排设计任务（例如，最少击键次数、最大
化默认值、模板的使用）。
5 上文中的6项以上，用户使用效率的需求要求使用特殊的工具以展示达到即定的目标。
该特性具有广泛的分布，有些高分值的趋势：34%低于均值， 43%高于平均值。
用户使用效率对于信息管理系统较事务/生产系统重要。对于新开发项目，该分值较增强项目低，并
具有较扁平的分布。同样的，从3GL项目至4GL项目，分值会增高。
6.2.2.4 划分在线更新复杂度：
多少内部逻辑文件会被在线的事务更新？
在线更新描述了内部逻辑文件在线更新的程度。应用软件为内部逻辑文件提供在线更新。
以下是记分的指南：
0 无
1 在线更新1至3个控制文件。更新量较少，恢复容易。
2 在线更新4个或4个以上的控制文件。更新量较少，恢复容易。
3 在线更新大量的控制文件。
4 另外，遗失数据的保护是关键的，并在系统中进行特定的设计和编码实现。
5 另外，大数据量带来了恢复过程中的成本考虑。需要最少人为干涉的高度自动化的恢复步骤。
在线更新的分值倾向高（半数高于均值），但大多数在3~4，5分较少。
事务/生产系统的分值较高。个人PC平台比其它平台低。同样的，从3GL项目至4GL项目，分值会增
高。
6.2.2.5 决定输入和输出复杂度：
4个带权重的分值相加即为输入和输出复杂度。
非程序员●第六期●过程●功能点过程
http://www.umlchina.com 65
6.2.3 划分应用软件复杂度的级别：
采用0~5的分值划分每个应用软件复杂度，分别代表无影响（no influence）、偶尔（incidental）、
适度（moderate）、平均（average）、重大（significant）和根本（essential）。
6.2.3.1 划分复杂处理复杂度：
应用软件是否具有大量的逻辑或数学处理？
复杂度处理描述了处理逻辑对应用软件开发的影响程度。以下是一些处理情况：灵敏度控制、特殊的
监控处理、安全性处理、逻辑处理、数学运算、异常处理、复杂度处理以及设备无关性。
以下是记分的指南：
0 无灵敏度控制、逻辑处理、数学运算、异常处理或复杂度处理。
1 包括灵敏度控制、逻辑处理、数学运算、异常处理或复杂度处理中的任何一种。
2 包括灵敏度控制、逻辑处理、数学运算、异常处理或复杂度处理中的任何两种
3 包括灵敏度控制、逻辑处理、数学运算、异常处理或复杂度处理中的任何三种
4 包括灵敏度控制、逻辑处理、数学运算、异常处理或复杂度处理中的任何四种
5 包括所有的灵敏度控制、逻辑处理、数学运算、异常处理或复杂度处理。
该特性具有正态分布，主要分布在均值3，0和5的分值较少。
复杂处理的分值在大型机上是最高的，而微机上是最低的；在3GL项目中最高，4GL项目中最低。该
分值在新的项目中较增强型的项目高，并具有较扁平的分布。处理复杂度从1991年~1996年稳定的增高。
6.2.3.2 划分重用性复杂度：
应用软件开发以满足一个或是多个用户的需要？
重用性描述了应用软件和软件中的代码特定的被设计、开发和支持，以在其它软件中重用的程度。
以下是记分的指南：
0 无重用代码。
1 可重用代码在应用软件中重用。
非程序员●第六期●过程●功能点过程
http://www.umlchina.com 66
2 10%以下的应用软件考虑多个用户的需要。
3 10%以上的应用软件考虑多个用户的需要。
4 应用软件特定的被打包和/或文档化以易于重用，应用软件被用户在源代码级别客户化。
5 应用软件特定的被打包和/或文档化以易于重用，应用软件通过用户参数维护的方式被客户化使用。
重用性的重要性通常较低，59%项目低于均值，仅有14%高于平均值，但它处于非常混合的状态。
决策支持系统中重用性考虑比其它类型多一些，而个人PC上的重用性的考虑较大型机少。
6.2.3.3 划分安装容易程度复杂度：
转换和安装的困难程度多大？
安装的容易程度描述了环境的变化对应用软件开发的影响程度。转换和安装的容易程度是应用软件的
特性之一。转换和安装计划和/或转换工具在系统测试阶段被提供和测试。
以下是记分的指南：
0 用户未提出特殊的要求，安装不需要特殊的调整。
1 用户未提出特殊的要求，但安装不需要特殊的调整。
2 用户提出转换和安装的要求，转换和安装指南被提供和测试。项目中转换的因素不被认为是重要的因
素。
3 用户提出转换和安装的要求，转换和安装指南被提供和测试。项目中转换的因素被认为是重要的因素。
4 在2的基础上，自动转换和安装工具被提供和测试。
5 在3的基础上，自动转换和安装工具被提供和测试。
该特性具有最广泛的分布性，总的来说分值较低（54%低于均值，22%高于均值），但是两种极端的
情况均有体现。安装的容易程度在20%的项目中不被考虑，而在15%的项目中非常重要。
增强型项目的分值比新开发的项目高；大型机比其它平台高；工程系统比其它业务领域高。
6.2.3.4 划分操作容易程度复杂度：
应用软件在启动、备份和恢复的有效性/自动化程度？
非程序员●第六期●过程●功能点过程
http://www.umlchina.com 67
操作的容易特征描述了应用软件在操作方面（如，启动、备份和恢复过程）的考虑程度。操作的容易
程度是应用软件的特性之一。应用软件最小化人工活动，如磁盘的mount、文件处理和直接的现场人工干
涉。
以下是记分的指南：
0 除了平常的备份过程，用户没有要求特殊操作上的考虑。
1 任意一种人工启动、备份和恢复；自动启动、备份和恢复；磁盘mount的最小化；或文档（paper）处
理最小化。
2 任意两种人工启动、备份和恢复；自动启动、备份和恢复；磁盘mount的最小化；或文档（paper）处
理最小化。
3 任意三种人工启动、备份和恢复；自动启动、备份和恢复；磁盘mount的最小化；或文档（paper）处
理最小化。
4 任意四种人工启动、备份和恢复；自动启动、备份和恢复；磁盘mount的最小化；或文档（paper）处
理最小化。
5 应用程序设计为无人操作。无人操作意味除了启动和关闭系统，系统不需要操作员的干涉。自动错误
恢复是应用软件的特色。
操作容易程度是不怎么考虑的问题。该特性的分值近乎最低：62%低于均值，仅有14%高于平均值。
分值分布在0~3，2是最普遍的情况。
当项目根据应用类型分组时，出现的唯一重大的差异：信息管理系统和决策支持系统的分值较交易/
生产系统和办公信息系统高。
6.2.3.5 划分多个地点复杂度：
应用软件是否设计支持多个地点场所/机构？
多个场所描述了应用软件被开发以适于多个地点和用户机构的程度。应用软件特定的被设计、开发、
支持，以工不同的组织机构在不同地点安装。
以下是记分的指南：
0 用户需求不需要考虑多个用户/安装地点的需要。
非程序员●第六期●过程●功能点过程
http://www.umlchina.com 68
1 设计中考虑了多个场所的需要，应用软件设计在相同的软硬件环境中操作。
2 设计中考虑了多个场所的需要，应用软件设计在相似的软硬件环境中操作。
3 设计中考虑了多个场所的需要，应用软件设计在不同的软硬件环境中操作。
4 文档和支持计划被提供和测试，以支持应用软件在不同地点的使用；应用软件如1或2所述。
5 文档和支持计划被提供和测试，以支持应用软件在不同地点的使用；应用软件如3所述。
该特性在所有的因素中具有最低的取值：68%低于均值，33%具有最小的可能值0。
分值对于法律系统非常低，而对于工程系统较高。新开发的系统比增强或重新开发的系统高；3GL项
目比其它的高；中型机比大型机高。同样，管理系统和决策系统的分值较交易/生产系统和办公系统高。
6.2.3.6 划分修改容易程度复杂度：
应用软件是否被设计以方便于修改？
修改方便描述了应用软件被开发以利于处理逻辑或数据结构修改的程度。下列特性适用于应用软件：
处理请求的灵活的查询和报表（如，简单、平均和复杂）和使用每日或隔日更新的表保存业务控制数据。
以下是记分的指南：
0 无
1 任何一种简单、平均或复杂的查询和报表，或者即时的或隔日的业务控制数据维护。
2 任何两种简单、平均或复杂的查询和报表，或者即时的或隔日的业务控制数据维护。
3 任何三种简单、平均或复杂的查询和报表，或者即时的或隔日的业务控制数据维护。
4 任何四种简单、平均或复杂的查询和报表，或者即时的或隔日的业务控制数据维护。
5 所有五种简单、平均或复杂的查询和报表，或者即时的或隔日的业务控制数据维护。
该特性的每个分值均有较好的体现，但普遍较低：53%低于均值，20%高于平均值。分布是双峰值的，
两个通常的取值是0和3。
对于3GL项目取值较低，4GL项目较高。新开发的项目低；大型机低；工程项目高。并不令人奇怪，
该特性对信息管理系统和决策支持系统较重要，而交易/生产系统的重要性较低。
非程序员●第六期●过程●功能点过程
http://www.umlchina.com 69
6.2.3.7 决定应用复杂度
6个带权重的分值相加即为应用软件复杂度。
6.2.4 决定加权因子：
系统复杂度、输入和输出复杂度和应用软件复杂度相加即为加权因子的值。
6.3 决定功能点：
决定包括未调整功能点和加权因子的功能点。
6.3.1 决定复杂度因子：
将加权因子乘以0.01，加上0.65，作为复杂度因子。
6.3.2 决定功能点：
将未调整功能点和复杂度因子相加得到功能点。
参考资料
   Fischman, Lee, Evolving Function Points, Crosstalk, February 2001.
   Garmus, David, & Herron, David, Function Point Analysis: Measurement Practices for Successful
Software Projects, Addison Wesley, 2001.
   International Function Point User’s Group (IFPUG), Function Point Counting Practices Manual
(Release 4.1), May 1999.
   Longstreet, D., Function Points Step by Step, Longstreet Consulting, Inc., January 1999.
   Lokan, C. J., An Empirical Analysis of Function Point Adjustment Factors, University of South Wales,
December 1998.
   Garmus, David, & Herron, David, Measuring the Software Process: A Practical Guide to Functional
Measurements, Prentice Hall, 1996.
   Albrecht, Allan J., Measuring Application Development Productivity, Proceedings SHARE/GUIDE
IBM Applications Development Symposium, October 1979