功能点估算法
最新功能点估算法介绍及应用
功能点估算法介绍及应用一、功能点估算法识别项目范围和数据复杂度功能点估算法是软件项目管理众多知识中比较有技术含量的一个。
在软件项目管理中项目计划制定的优劣直接关系到项目的成败，项目计划中对项目范围的估算又尤为重要。
如果项目负责人对项目的规模没有一个比较客观的认识，没有对工作量、所需资源、完工时间等因素进行估算，那么项目计划也就没有存在的意义。
功能点估算法的特点项目范围的估算在CMMI的“MA”度量分析管理和“PP”项目计划中均有涉及。
对软件项目范围的估算有很多种方法，常见的是LOC代码行和FP功能点法。
它们之间的区别和关系如下：•功能点估算法常用在项目开始或项目需求基本明确时使用，这时进行估算其结果的准确性比较高。
假如这个时候使用LOC代码行估算法，则误差会比较大。
•使用功能点估算法无需懂得软件使用何种开发技术。
LOC代码行估算法则与软件开发技术密切相关。
•功能点估算法是以用户为角度进行估算，LOC代码行估算法则是以技术为角度进行估算。
•通过一些行业标准或企业自身度量的分析，功能点估算法是可以转换为LOC代码行的。
在项目刚开始的时候进行功能点估算可以对项目的范围进行预测。
在项目开发的过程中由于需求的变更和细化可能会导致项目范围的蔓延，计算出来的结果会与当初估计的不同。
因此，在项目结束时还需要对项目的范围情况重新进行估算，这个时候估算的结果才能最准确反映项目的规模。
功能点分析的步骤本文将以国际标准IFPUG（International Function Point Users Group）组织提供的功能点估算法V4.1.1为基础进行讲解。
如下图所示，首先大家应该了解功能点估算法的使用步骤。
图1 功能点估算法的步骤具体步骤包括：1. 识别功能点的类型。
2. 识别待估算应用程序的边界和范围。
3. 计算数据类型功能点所提供的未调整的功能点数量。
4. 计算人机交互功能所提供的未调整的功能点数量。
5. 确定调整因子。
功能点估算法
功能点估算法功能点估算法是软件项目管理众多知识中比较有技术含量的一个。
在软件项目管理中项目计划制定的优劣直接关系到项目的成败，项目计划中对项目范围的估算又尤为重要，如果项目负责人对项目的规模没有一个比较客观的认识，没有对工作量、所需资源、完工时间等因素进行估算，那么项目计划也就没有存在的意义。
FP功能点估算法的特点项目范围的估算在CMMI的“MA”度量分析管理和“PP”项目计划中均有涉及，对软件项目范围的估算有很多种方法，常见的就是LOC代码行和FP功能点法，它们之间的区别和关系如下：1、 FP功能点估算法常用在项目开始或项目需求基本明确时使用，这时进行估算其结果的准确性比较高，假如这个时候使用LOC代码行估算法，则误差会比较大。
2、使用FP功能点估算法无需懂得软件使用何种开发技术。
LOC代码行估算法与软件开发技术密切相关。
3、 FP功能点法是以用户为角度进行估算，LOC代码行估算法则是以技术为角度进行估算的。
4、通过一些行业标准或企业自身度量的分析，FP功能点估算法是可以转换为LOC代码行的。
在项目刚开始的时候进行功能点估算可以对项目的范围进行预测，在项目开发的过程中由于需求的变更和细化可能会导致项目范围的蔓延，计算出来的结果会与当初估计的不同，因此在项目结束时还需要对项目的范围情况进行估算，这个时候估算的结果才能最准确反映项目的规模。
功能点分析的步骤在本文中将以国际标准IFPUG(International Function Point Users Group)组织提供的功能点估算法V4.1.1为基础与大家进行讲解。
如下图所示，首先大家应该了解功能点估算法的使用步骤。
功能点估算的步骤1、识别功能点的类型。
2、识别待估算应用程序的边界和范围。
3、计算数据类型功能点所提供的未调整的功能点数量。
4、计算人机交互功能所提供的未调整的功能点数量。
5、确定调整因子。
6、计算调整后的功能点数量。
EI、EO、EQEI是处理来自于应用程序边界外部的一组数据的输入，它的主要目的是维护一个或多个ILF，以及/或者更改系统的行为。
NESMA功能点估算法
一、什么是功能点，功能点估算有什么用？对于一个软件来说，功能点是一个可以作为标准的一个计量单位，功能点的多少代表着软件的规模大小，那么有了一个同一的量级的表现后，不同产品或者功能通过功能点来表示，就可以很好地反馈出产品或者功能的复杂程度，同时我们利用功能点来辅助计算效率、成本等也有很大作用。
使用禅道作为项目管理工具的小伙伴，也会在提需求的板块，看到有功能点的录入要求，这也是作为项目管理中，工作量的估算的重要性。
二、功能点估算方法与基本过程功能点的估算方法有IFPUG和NESMA等，下面主要是介绍NESMA 功能点估算法，NESMA估算法更多的在项目前期，可以快速的利用逻辑文件，给出预估的功能点数量，起到较好的指导作用。
NESMA估算法有三种类型的功能点估算，包括：指示功能点计数、估算功能点计数、详细功能点计数；分别对应项目的前期，中后期的功能点估算需求，同时估算出来的功能点也是越来越细化和精准。
当然操作难度和复杂度也是越来越高。
对于一般性的产品而言，我们主要是使用前两种（指示功能点计数、估算功能点计数）估算方法即可，两种方法的主要区别就在于计算公式的不同，一个粗放，一个则较精细，两种都可以使用，可以根据自身项目的具体要求和所处阶段来进行选择。
指示功能点计数：ILF*35+EIF *15估算功能点计数：UFP=（7* ILF+5* EIL+4* EI+5* EO+4* EQ)下面就来介绍上面的公式中用到的因子以及查找方法。
三、两个逻辑文件与三个基本过程上面的估算方法中提到的ILF、EIF、EI、EO、EQ代表着什么呢？只要弄明白了这几个计算因子，那么带入公式就可以很快知道我们的这个产品或者功能的软件规模有多大了，所需多少开发量，也就有了较为准确的参考标准。
1. 两个逻辑文件：ILF和EIF首先我们理解一下逻辑文件是个什么东西。
功能点估算法，我们是从产品的角度，用户的视角来进行估算的。
那么逻辑文件的概念，也就是从用户的视角出发，来进行定义的一类对用户有意义的信息。
功能点估算法
功能点估算法功能点估算法是一种推断开发者所需完成的工作量的测算方法。
它通过计算软件系统实际功能所需要的数量，来估算软件开发项目所需要的工作量。
这类测算方法经常用于估算软件研发预算，以帮助管理人员更好地掌握软件研发项目的实施过程，更有效地控制开发成本。
在新系统开发项目中，由于缺乏项目的相关信息，无法采用其他的估算方法，所以采用功能点估算法会比较实用。
它可以根据软件系统的功能需求，通过统计分析和对比，对项目的实施过程进行估算。
换句话说，功能点估算法是根据软件系统的功能特性，采用质量控制的原则，对软件开发的工作量进行估算和控制。
功能点估算法的具体实施过程，首先要明确项目所需要实现的功能点，并对每个功能点进行细化，明确功能点的分类划分。
在功能点定义之后，要根据项目的功能和目标，进行功能点估算，确定每个功能点所需要实现的工作量，并将这些数据汇总起来，作为项目的工作量估算基准。
此外，在进行功能点估算时，还要结合项目的复杂性，适当的考虑系统中所需的技术支持、测试和文档等活动，以准确估算项目所需的工作量。
软件系统开发项目在估算阶段，采用功能点估算法可以使估算更加准确，从而更好地掌握项目的进度，减少开发时间和成本。
功能点估算不仅可以帮助开发者规划开发任务和工作负荷，而且还可以帮助客户评估项目的性价比，确保项目的经济效益。
同时，功能点估算还可以为开发者建立一套科学的计划，从而更精确地控制开发的时间和成本，提高开发效率。
总之，功能点估算法是一种实用的、灵活的估算方法，它可以帮助开发者更加精确地估算软件研发项目的工作量，从而更好地控制开发成本，提高项目的经济效益。
它既便于项目管理者和客户，也有利于开发者，是软件系统开发项目必不可少的一环。
IFPUG功能点估算含示例
IFPUG功能点估算含示例IFPUG（International Function Point Users Group）功能点估算是一种常用的软件度量方法，它通过对软件的功能进行分类和量化来估算软件的规模和复杂度。
功能点估算可以帮助软件开发团队更好地理解项目的规模和工作量，有助于项目管理和项目成本的预测。
IFPUG功能点估算的核心思想是将软件的功能进行分类，然后将每个功能点按照一定的规则进行加权，并与标准功能点系数相乘得出最终的功能点数。
这样可以对不同的软件进行可比较的度量，并且提供了一个基准来评估相对规模和复杂度。
1.功能性功能点包括以下四个子类：-输入（EI）功能点：表示软件接收外部输入并处理的功能。
例如，一个图书管理系统可以接收读者的借书请求并进行处理。
-输出（EO）功能点：表示软件向外部输出信息的功能。
例如，一个图书管理系统可以向读者输出图书的归还日期。
-查询（EQ）功能点：表示软件进行内部或外部查询的功能。
例如，一个图书管理系统可以查询图书的借阅记录。
-文件（F）功能点：表示软件维护的逻辑文件（包括输入和输出文件）的功能。
例如，一个图书管理系统可以维护图书的借阅记录文件。
2.非功能性功能点包括以下三个子类：-外部接口文件（EIF）功能点：表示软件与外部系统进行数据交换的功能。
例如，一个图书管理系统可以与图书供应商的系统进行数据交换。
-外部查询文件（EQF）功能点：表示软件使用的外部查询文件的功能。
例如，一个图书管理系统可以使用图书供应商的系统提供的查询功能。
-内部逻辑文件（ILF）功能点：表示软件内部维护的逻辑文件的功能。
例如，一个图书管理系统可以维护图书的库存信息。
在IFPUG功能点估算中，每个功能点都有一个权重或复杂度，可以根据软件的特点和相对复杂度进行调整。
例如，一个图书管理系统的输入功能点可能比输出功能点更复杂，因此输入功能点的权重可能更高。
下面是一个示例，用于说明如何进行IFPUG功能点估算：假设我们要开发一个学生管理系统，该系统可以记录学生的基本信息、课程成绩和考试安排等。
软件开发功能点估算方法
功能点估算方法1概述 (1)1.1编写目的 (1)1.2适用范围 (1)1.3术语定义 (1)1.4功能点定义与分类 (2)2功能点估算方法 (2)2.1估算流程 (2)2.1.1项目前期 (3)2.1.2需求明确 (4)2.1.3需求变更 (4)2.2调整前功能点计算（UFC） (5)2.2.1复杂度矩阵（项目前期） (5)2.2.2复杂度矩阵（需求明确、需求变更）.................. .62.3调整系数 (7)2.4调整后功能点计算（FP） (10)3实例说明 (10)3.1项目前期 (10)3.2需求明确 (13)3.3需求变更 (19)1概述1.1编写目的为规范软件项目规模的度量方法，结合国际先进的估算方法及公司业务运营模式，制定基于软件功能的度量估算方法，为度量项目规模和项目工作量提供指导依据。
1.2适用范本方法适用于公司的研发类项目，项目应覆盖软件开发全过程（包括项目准备阶段、需求阶段、设计阶段、编码与测试、交付部署、运行维护各个阶段工作，1.3术语定义1.4功能点定义与分类功能点（Function Points）是响应客户、其他应用请求或自行触发而进行处理并输出结果的一个最小功能单元。
功能估算过程中，将软件的功能分为以下4类：1）接口：是指在其他系统中维护但本系统需要调用的数据。
包括：调用外部接口和提供外部系统调用的接口。
2）数据处理：是指来自于系统外部的数据输入、控制信息或事务数据输入，并对输入数据进行逻辑处理。
包括：新增、修改、删除、流程流转和发布。
3）统计：是指对数据经过组合、计算、统计分析后得出的数据集合，并由程序内部输出到外部。
包括：定时统计和实时统计。
4）查询：是一个输入输出的组合过程，向应用程序边界外发送数据基本处理的过程。
包括：单表查询和多表联合查询。
2功能点估算方法2.1估算流程功能点估算方法，是从软件项目的功能需求角度来评估项目规模，功能点估算流程如下图所示。
IFPUG功能点估算含示例
功能点估算(CMMI-FP)含示例（内容来自互联网仅学习共享）功能点估算法是软件项目管理众多知识中比较有技术含量的一个。
在软件项目管理中项目计划制定的优劣直接关系到项目的成败，项目计划中对项目范围的估算又尤为重要。
如果项目负责人对项目的规模没有一个比较客观的认识，没有对工作量、所需资源、完工时间等因素进行估算，那么项目计划也就没有存在的意义。
功能点估算法的特点项目范围的估算在CMMI的“MA”度量分析管理和“PP”项目计划中均有涉及。
对软件项目范围的估算有很多种方法，常见的是LOC代码行和FP功能点法。
它们之间的区别和关系如下：∙功能点估算法常用在项目开始或项目需求基本明确时使用，这时进行估算其结果的准确性比较高。
假如这个时候使用LOC代码行估算法，则误差会比较大。
∙使用功能点估算法无需懂得软件使用何种开发技术。
LOC代码行估算法则与软件开发技术密切相关。
∙功能点估算法是以用户为角度进行估算，LOC代码行估算法则是以技术为角度进行估算。
∙通过一些行业标准或企业自身度量的分析，功能点估算法是可以转换为LOC代码行的。
在项目刚开始的时候进行功能点估算可以对项目的范围进行预测。
在项目开发的过程中由于需求的变更和细化可能会导致项目范围的蔓延，计算出来的结果会与当初估计的不同。
因此，在项目结束时还需要对项目的范围情况重新进行估算，这个时候估算的结果才能最准确反映项目的规模。
功能点分析的步骤本文将以国际标准IFPUG（International Function Point Users Group）组织提供的功能点估算法V4.1.1为基础进行讲解。
如下图所示，首先大家应该了解功能点估算法的使用步骤。
图1功能点估算法的步骤具体步骤包括：1.识别功能点的类型。
2.识别待估算应用程序的边界和范围。
3.计算数据类型功能点所提供的未调整的功能点数量。
4.计算人机交互功能所提供的未调整的功能点数量。
5.确定调整因子。
6.计算调整后的功能点数量。
功能点估算法 标准
功能点估算法标准
功能点估算法是一种软件规模度量方法，用于估算软件项目的规模和工作量。
它基于软件系统的功能和特性，将其分解为一系列可度量的功能点。
功能点估算法的核心思想是通过对软件系统的功能进行分析和分解，确定每个功能的复杂度和贡献度，并将其转换为对应的功能点数。
功能点可以根据不同的功能类型进行分类，如数据输入、数据输出、数据存储、外部接口等。
在进行功能点估算时，通常需要遵循一定的标准和规范，例如国际功能点用户组（IFPUG）发布的功能点计数规范。
这些规范定义了各种功能类型的计算方法和权重，以确保估算的准确性和一致性。
功能点估算法的优点包括：
1. 相对客观和准确：功能点估算法基于软件系统的功能和特性进行估算，不受开发人员经验和技能水平的影响，因此相对客观和准确。
2. 可重用性高：功能点估算法可以应用于不同类型的软件项目，具有较高的可重用性。
3. 便于项目管理和规划：通过功能点估算，可以更好地了解项目的规模和工作量，有助于项目管理和规划。
然而，功能点估算法也存在一些局限性，例如对于某些特殊类型的软件项目可能不适用，估算过程相对复杂，需要一定的专业知识和经验。
功能点估算法是一种常用的软件规模度量方法，通过对软件系统的功能进行分析和分解，确定每个功能的复杂度和贡献度，并将其转换为对应的功能点数，从而估算软件项目的规模和工作量。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
功能点估算法识别项目范围和数据复杂度功能点估算法是软件项目管理众多知识中比较有技术含量的一个。
在软件项目管理中项目计划制定的优劣直接关系到项目的成败，项目计划中对项目范围的估算又尤为重要。
如果项目负责人对项目的规模没有一个比较客观的认识，没有对工作量、所需资源、完工时间等因素进行估算，那么项目计划也就没有存在的意义。
功能点估算法的特点项目范围的估算在CMMI的“MA”度量分析管理和“PP”项目计划中均有涉及。
对软件项目范围的估算有很多种方法，常见的是LOC代码行和FP功能点法。
它们之间的区别和关系如下：∙功能点估算法常用在项目开始或项目需求基本明确时使用，这时进行估算其结果的准确性比较高。
假如这个时候使用LOC代码行估算法，则误差会比较大。
∙使用功能点估算法无需懂得软件使用何种开发技术。
LOC代码行估算法则与软件开发技术密切相关。
∙功能点估算法是以用户为角度进行估算，LOC代码行估算法则是以技术为角度进行估算。
∙通过一些行业标准或企业自身度量的分析，功能点估算法是可以转换为LOC代码行的。
在项目刚开始的时候进行功能点估算可以对项目的范围进行预测。
在项目开发的过程中由于需求的变更和细化可能会导致项目范围的蔓延，计算出来的结果会与当初估计的不同。
因此，在项目结束时还需要对项目的范围情况重新进行估算，这个时候估算的结果才能最准确反映项目的规模。
功能点分析的步骤本文将以国际标准IFPUG（International Function Point Users Group）组织提供的功能点估算法V4.1.1为基础进行讲解。
如下图所示，首先大家应该了解功能点估算法的使用步骤。
图1 功能点估算法的步骤具体步骤包括：1. 识别功能点的类型。
2. 识别待估算应用程序的边界和范围。
3. 计算数据类型功能点所提供的未调整的功能点数量。
4. 计算人机交互功能所提供的未调整的功能点数量。
5. 确定调整因子。
6. 计算调整后的功能点数量。
识别项目的类型国际IFPUG组织将软件项目分为三类，功能点估算法适用于任何一类项目：∙新开发项目∙二次开发的项目∙功能增强的项目识别项目的范围和边界使用UML的“UseCase”用例图是以用户角度进行识别项目范围和边界的最好方法，在画用例图时就必须明确系统的边界。
通过系统的边界，我们可以知道哪些功能要计算功能点，哪些功能点是外部系统负责计算的。
以图2为例：一个外贸订单系统只包含录入、修改、删除、查询和统计订单的功能，而汇率查询转换服务是不属于该系统的。
应用程序边界的识别规则大家一定要牢记，不能从技术角度去思考，必须从用户角度来定义；如果项目牵扯到多个系统，那么必须将这多个系统的边界全部描述清楚。
图2 外贸订单系统用例图功能点估算分类功能点估算法将功能点分为以下5类：1. ILF：Internal Logical File内部逻辑文件2. EIF: External Interface File外部接口文件3. EI: External Input外部输入4. EO: External Output外部输出5. EQ: External Inquiry外部查询其中，ILF和EIF属于数据类型的功能点，EI、EO、EQ属于人机交互事务类型的功能点。
以外贸订单系统项目为例：∙录入订单、修改订单、删除订单是EI；∙查询订单是EO∙统计订单是EQ∙汇率查询转换系统为EIF∙订单和客户是ILF识别功能点的重要原则ILF、EIF要与EI、EO、EQ分开计算。
对ILF和EIF复杂度的计算可以简单理解为对数据库复杂度的计算。
对EI、EO、EQ复杂度的计算可以理解为对程序开发复杂度的计算。
一般软件项目都是由数据和程序构成的，因此计算ILF、EIF 和计算EI、EO、EQ之间没有任何关系。
内部逻辑文件与外部接口文件ILF内部逻辑文件内部逻辑文件是指一组以用户角度识别的、在应用程序边界内且被维护的逻辑相关数据或控制信息。
ILF的主要目的是通过应用程序的一个或多个基本处理过程来维护数据。
EIF外部接口文件外部接口文件是指一组在应用程序边界内被查询，但在其他应用程序中被维护的、以用户角度来识别的、逻辑上相关的数据。
因此，一个应用程序中的EIF 必然是其他应用程序中的ILF。
EIF的主要目的是为边界内的应用程序提供一个或多个通过基础操作过程来引用的一组数据或信息。
EIF所遵循的规则：∙从用户角度出发识别的一组逻辑数据。
∙这组数据是在应用程序外部，并被应用程序引用的。
∙计算功能点的这个应用程序并不维护该EIF。
∙这组数据是作为另一个应用程序中的ILF被维护的。
ILF和EIF的复杂性计算ILF和EIF的复杂性是取决于RET（Record element type）和DET（Data element type）的数量。
DET是一个以用户角度识别的、非重复的、有业务逻辑意义的字段。
DET计算的规则如下：∙通过一个基本处理过程的执行，对ILF进行维护，或从ILF/EIF中返回一个特定的、用户可识别的、非重复的字段，那么每个这样的字段算一个DET。
例如：添加一个外贸订单时需要保存“订单号码、订单日期、地址、邮编”，那么对于ILF订单来说它的DET就是4个。
再如：保存订单时还会保存订单的明细。
订单的明细往往作为一个子表进行保存，那么“订单号码”在主表和子表中都同时存在（主外键）。
但以用户角度来识别时，存盘操作是一个最小的单位，那么订单号码只能算做一个DET。
∙当两个应用程序维护和/或引用相同的ILF/EIF，但是每个应用程序分别维护/引用它们相应的DET时，这些DET在这两个应用程序的维护/引用中将单独计算。
例如，一个应用程序的两个“Elementary Process”基本处理过程都需要使用到“地址”的信息，地址信息又可以细分为“国家、城市、街道、邮编”。
那么对于其中一个基本处理过程来说，它将整个地址信息作为一个整体进行处理，只算一个DET；另外一个基本处理过程使用每个地址的详细信息，那么DET就是4个。
RET计算的规则如下：RET是指一个EIF/ILF中用户可以识别的DET的集合。
如果把DET简单理解为字段的话，那RET就可以简单理解为数据库中的表。
RET在ILF/EIF中分为两种类型：可选的（Optional）和必选的（Mandatory）。
计算RET的规则为以下两点：∙在一个ILF/EIF中每一个可选或必选的集合都被计算为一个RET。
∙如果一个ILF/EIF没有子集合，则ILF/EIF被计算为一个RET。
例如：在外贸订单系统中添加一个订单时会保存“订单信息、客户的ID、部门的ID”。
那么订单系统ILF中的RET为：1. 订单信息（必选的）2. 客户信息（必选的）3. 部门信息（可选的）因此ILF中RET的个数为3个。
ILF/EIF复杂度的矩阵如下：1. 开发功能点计算（Development Project Function Point Count）开发功能点计算类型是计算当软件系统开发完成第一次安装给使用者时的功能性大小，此功能性大小亦必须包含从旧有系统数据转换（DataConversion）所需要的功能性大小。
开发功能点计算类型通常必须依软件开发生命周期的进行，重复地计算或修正功能性的大小。
一般后续的功能点数大小的计算是去验证上一次计算所得到的功能点数大小，看看是否有增加的功能性；如果有的话，就必须把增加的功能性大小加入。
一般这种开发功能点大小会依软件项目开发的进行而逐渐增加的现象，称为范围逐渐增加（Scope Creep）。
2. 增强功能点计算（Enhancement Project Function Point Count）增强功能点计算类型是计算软件系统修改（Modification）功能性的大小，包括新增（adding）、删除（deleting）、改变（changing）已安装使用中软件系统的功能性。
一般当已安装软件系统有修改功能性的时候，就必须去计算增强功能点数的大小；当增强功能点数大小计算完成后，也必须去修改应用功能点数（第三类型的功能点计算）的大小，以反映出软件系统功能性大小的变动。
3. 应用功能点计算（Application Project Function Point Count）应用功能点计算类型是计算已安装并在使用中系统功能性的大小，这种应用功能点数也被称为基准线或安装功能点数（Baseline or Installed FunctionPoint Count）。
此功能点数主要是度量目前已安装使用中软件系统提供给使用者的功能性大小。
应用功能点数的初值是软件系统开发完成时计算所得到的开发功能点数（不包含数据转换所需的功能性大小），而且当有增强项目（Enhancement Project）时，其值必须去修正以反映出软件系统维护之后功能性的变动，亦即当有计算增强功能点数时，就必须去修正应用功能点数。
步骤二：定义计算的范围与应用系统的界限功能点数计算的范围（Counting Scope）是由计算的目的所决定，例如是要针对系统或是子系统等进行评估。
而应用的界限（Application Boundary）是代表所评估的系统与外部系统或使用者间的界限分割。
步骤三：计算数据功能性（Data Functions）数据功能性是计算软件系统内所有内部逻辑档案（Internal Logical Files, ILFs）与外部接口档案（External Interface Files, EIFs）的功能性大小。
每一个功能性元素ILF或EIF的大小是依照数据元素类别（Data Element Types, DETs）与纪录元素类别（Record Element Types, RETs）个数的大小来决定其复杂度等级（如表一所示），再依其复杂度等级（低、中、高）给予不同的未调整功能点数（请参阅表五）。
表一：数据功能性ILFs与EIFs的复杂度矩阵步骤四：计算处理功能性（Transactional Functions）计算功能性是计算软件系统内所有外部输入（External Inputs, EIs）、外部输出（External Outputs, EOs）以及外部查询（External Inquires, EQs）的功能性大小。
每一个功能性元素EI、EO或EQ的大小是依照数据元素类别（Data Element Types, DETs）与参考档案类别（File Types Referenced, FTRs）个数的大小来决定其复杂度等级（如表二至表四所示），再依其复杂度等级（低、中、高）给予不同的未调整功能点数（请参阅表五）。
表二：处理功能性EIs的复杂度矩阵表三：处理功能性EOs的复杂度矩阵表四：处理功能性EQs的复杂度矩阵步骤五：计算未调整功能点数（Unadjusted Function Points, UFP）依步骤三求算出软件系统之数据功能性、处理功能性，与其复杂度等级后，便可按照权重分配表（如表五所示）将各功能性元素的个数乘上权重值后加总计算出未调整功能点数。