当前位置：文档之家 › IFPUG功能点估算含示例

IFPUG功能点估算含示例

  • 格式：pdf
  • 大小：278.83 KB
  • 文档页数：21

下载文档原格式

  / 21

合集下载

FP功能点估算方法[学习内容]

FP功能点估算方法[学习内容]
20世纪70年代提出，演进为一个总标准（ISO14143） 与5个子标准
MarkII、COSMIC、NESMA、FISMA、IFPUG
概念
✓ 软件功能规模是指通过量化功能用户需求而得到的软件规模。
软件规模用功能点（FP）来表示，即功能点是IFPUG功能规模的度量单位。
✓ IFPUG功能规模度量（Functional Size Measurement，FSM）
• 数据存储类的复杂度 • DET：具体数据存储文件的数据项（字段）的数目。 • RET：一个EIL\ILF中用户可以识别的DET的集合。
• EI复杂度计算规则 • EO/EQ复杂度计算规则 • ILF复杂度计算规则 • EIL复杂度计算规则
调整影响因子
● 1.数据通讯 ● 2. 分布式数据处理 ● 3. 性能 ● 4. 使用强度高的配置 ● 5. 事务处理率 ● 6. 在线数据输入 ● 7. 最终用户的效率
缺乏有效的估算方法与过程导致无法制 定出准确的项目计划
FP的价值
✓ 更准确的项目规模 ✓ 更客观的项目进度和预算 ✓ 项目的可预测性 ✓ 更早的风险识别
监控
计划
FP估算
• 仅仅通过估算实践本身并不能获得准确的估算结果，还需要 通过有效的项目控制。
• FP的首要目标不是预测项目的结果，而是确定项目目标是否 足够现实，从而让项目在可控的状态下达到这些目标。
• 用户通过界面向系统输入，目
逻辑文件
的是维护ILF或更改系统的行为。 • 用户角度识别的，被系统边界内
• 如：增、删、改的操作。
维护的数据或控制信息。
• 数据库的表、独立的文件
• EO: External Output外部输出
• 用户看到的一个完整业务逻辑对

基于IFPUG功能点分析方法的软件测试成本估算

基于IFPUG功能点分析方法的软件测试成本估算

2021年第04期(总第220期）《蓿窟画蓿基于IFPUG功能点分析方法的软件测试成本估算杜艳红,陈浩月(上海计算机软件技术开发中心，上海2〇i m)摘要:软件测试（Software Testing)作为软件质量保证的主要手段之一，在软件开发过程中所占的比重日益增加，成为保 证软件质■量的重要环节，对提高软件质量具有重要意义。

将IFPUG(Intem ationalFunctionPointU serG roup)功能点分析 方法结合国家标准《GB/T32911-2016软件测试成本度量规范》引入软件测试成本估算过程中，以提高软件测试规模评估 的准确率。

关键词:软件工程造价;软件测试;成本评估;IFPUG中图分类号:TP309 文献标识码:B文章编号:2096-9759(2021)04-0141-05Software Test Cost Estimation Based on IFPUG Function Point Analysis MethodDu Yanhong,Chen Haoyue(Shanghai Development Center o f Computer Software Technology,Shanghai201112)A bstract:Software Testing,as one o f the main means o f Software quality assurance,occupies an increasing proportion in theprocess o f Software development.lt has become an important lin k to ensure Software quality and is o f great significance to im_ prove Software quality.The IFPUG(International Function Point User Group)Function Point analysis method combined w ith the national standard GB/T32911-2016 Software Test Cost Measurement Code was introduced into the process o f software test cost estimation to improve the accuracy o f software test scale evaluation.Keywords:software engineering cost;software testmg;cost evaluation;IFPUG〇引言软件测试成本估算是软件成本估算中的一个分支，在早期 的软件成本估算模型中，因为测试和开发没有明显的界限，所 以成本估算对象是整个项目。

IFPUG功能点估算基本方法

IFPUG功能点估算基本方法

IFPUG功能点估算基本方法IFPUG（International Function Point Users Group）功能点估算基本方法是一种常用的软件开发项目估算方法，通过对软件的功能需求进行分析和量化，以功能点（Function Point，FP）作为衡量软件规模的指标，从而对软件项目的工作量、进度和成本进行估算和控制。

1. 需求分析：首先，需要从用户对软件系统的需求描述中找出功能性需求（External Input、External Output、External Inquiry）和非功能性需求（Internal Logical Files、External Interface Files），并进行详细的分析和理解。

2.功能点计算：根据需求分析的结果，按照IFPUG的规定，对每个功能要素进行计数。

- External Input（EI）：输入功能要素，描述软件系统接收外部输入数据并对其进行处理的功能。

- External Output（EO）：输出功能要素，描述软件系统生成的输出数据。

- External Inquiry（EQ）：查询功能要素，描述软件系统提供给用户的查询功能。

- Internal Logical Files（ILF）：内部逻辑文件，描述软件系统内部生成、维护和管理的数据文件。

- External Interface Files（EIF）：外部接口文件，描述软件系统与外部系统交互的数据文件。

根据功能要素的计数和权重，可以计算出各个功能要素的功能点数。

3. 加权计算：根据软件的特定环境和特性，对功能点数进行加权计算，得出修正功能点数（developed function points，DFP）。

加权计算可以考虑以下一些因素：-数据处理复杂性：软件系统对数据进行处理的复杂程度。

-逻辑处理复杂性：软件系统的逻辑处理的复杂程度。

-用户界面复杂性：用户界面的复杂程度。

-数据存储复杂性：数据存储结构的复杂程度。

信息系统项目管理功能点估算(CMMI-FP)

信息系统项目管理功能点估算(CMMI-FP)

选用了FP功能点分析作为项目主要的估算方法．因为FP方法中有大量项目经验数据可以从网络上获得，同时其数据功能TLF、EIF，以及事务功能EI、EO、EQ的计算对经验数据依赖不强，只需对概念理解正确一般就可以正确估算了．在估算成本的时候，因为公司以前的生产率数据是以LOC为单位的，我利用软件工程书籍中的“逆火”经验数据，将 LOC转换为功能点单位，当然，这里必然导致一些误差。

为了降低估算误差，最后使用Delphi专家分析法对估算结果进行了调整．功能点估算法是软件项目管理众多知识中比较有技术含量的一个。

在软件项目管理中项目计划制定的优劣直接关系到项目的成败，项目计划中对项目范围的估算又尤为重要。

如果项目负责人对项目的规模没有一个比较客观的认识，没有对工作量、所需资源、完工时间等因素进行估算，那么项目计划也就没有存在的意义。

功能点估算法的特点项目范围的估算在CMMI的“MA”度量分析管理和“PP”项目计划中均有涉及。

对软件项目范围的估算有很多种方法，常见的是LOC代码行和FP功能点法。

它们之间的区别和关系如下：∙功能点估算法常用在项目开始或项目需求基本明确时使用，这时进行估算其结果的准确性比较高。

假如这个时候使用LOC代码行估算法，则误差会比较大。

∙使用功能点估算法无需懂得软件使用何种开发技术。

LOC代码行估算法则与软件开发技术密切相关。

∙功能点估算法是以用户为角度进行估算，LOC代码行估算法则是以技术为角度进行估算。

∙通过一些行业标准或企业自身度量的分析，功能点估算法是可以转换为LOC代码行的。

在项目刚开始的时候进行功能点估算可以对项目的范围进行预测。

在项目开发的过程中由于需求的变更和细化可能会导致项目范围的蔓延，计算出来的结果会与当初估计的不同。

因此，在项目结束时还需要对项目的范围情况重新进行估算，这个时候估算的结果才能最准确反映项目的规模。

功能点分析的步骤具体步骤包括：1. 识别功能点的类型。

2. 识别待估算应用程序的边界和范围。

IFPUG功能点估算含示例

IFPUG功能点估算含示例
EO 补充的计算规则 除了要满足上面的通用规则外，还要满足下面其中一条：
在基本操作过程中至少包含一个数学公式或计算方法 在基本操作过程中要产生派生数据 在基本操作过程中至少要维护一个 ILF 在基本操作过程中要改变系统的行为。
EQ 补充的计算规则 除了要满足上面的通用规则外，还要满足下面其中一条：
EI 主要目的 主要目的 次要目的
EO 次要目的 次要目的 主要目的
EQ 不允许 不允许 主要目的
EI 可以 至少选择一次 可选 可选 可选 至少选择一次 可选 必须
EO 至少选择一次 至少选择一次 可选 可选 至少选择一次 至少选择一次 必选 可选
EQ 不可以 不可以 必选 必选 可选 可选 必选 可选
该基本处理过程逻辑上必须是唯一的，该唯一性是指其在应用程序中与其 他 EO 或 EQ 在逻辑性上保持唯一。
该基本处理过程所使用的数据应该是唯一的，该唯一性是指其在应用程序 中与其他 EO 或 EQ 所使用的数据不同。
该基本处理过程所引用的 ILF 或 EIF 文件应该是唯一的，该唯一性是指其 在应用程序中与其他 EO 或 EQ 所引用的 ILF 或 EIF 文件不同。
使用功能点估算法无需懂得软件使用何种开发技术。LOC 代码行估算法则 与软件开发技术密切相关。
功能点估算法是以用户为角度进行估算，LOC 代码行估算法则是以技术为 角度进行估算。
通过一些行业标准或企业自身度量的分析，功能点估算法是可以转换为 LOC 代码行的。
在项目刚开始的时候进行功能点估算可以对项目的范围进行预测。在项目开发 的过程中由于需求的变更和细化可能会导致项目范பைடு நூலகம்的蔓延，计算出来的结果会 与当初 估计的不同。因此，在项目结束时还需要对项目的范围情况重新进行估 算，这个时候估算的结果才能最准确反映项目的规模。

IFPUG功能点估算方法使用指南

IFPUG功能点估算方法使用指南
3.4. 计数数据功能.................................................................................................................. 8 3.4.1. 定义 ......................................................................................................................... 9 3.4.2. 计数流程概述........................................................................................................... 9 3.4.3. ILF 识别规则........................................................................................................... 10
IFPUG 功能点估算方法使用指南
排版整理：旦丰
目录
1. 引言....................................................................................................................................... 1
2.3.1. 决定分析的类型 ....................................................................................................... 2 2.3.2. 识别分析范围和应用边界......................................................................................... 3 2.3.3. 确定未经调整的功能点数（Unadjusted Function Point Count -- UFPC）.............. 3

功能点分析法 IFPUG


100 FPs
Impact Effort Schedule Cost
120 FPs
• State code input screen changed (3 FPs)
• Interface to N&A file added (10 FPs)
• N&A inquiry and state code inquiry added (7 FPs)
3
© Copyright 2001. International Function Point User Group 2001
..
IFPUG Mission Statement
• The mission of the International Function Point Users Group is to be a recognized leader in promoting and encouraging the effective management of application software development and maintenance activities through the use of Function Point Analysis and other software measurement techniques.
9
© Copyright 2001. International Function Point User Group 2001
..
Changes to Requirements
• Changes to Requirements
– Change Inevitable – Trade-offs – Customer Definition of Quality – Size

(整理)功能点估算法介绍及应用.

一、功能点估算法识别项目范围和数据复杂度功能点估算法是软件项目管理众多知识中比较有技术含量的一个。

在软件项目管理中项目计划制定的优劣直接关系到项目的成败，项目计划中对项目范围的估算又尤为重要。

如果项目负责人对项目的规模没有一个比较客观的认识，没有对工作量、所需资源、完工时间等因素进行估算，那么项目计划也就没有存在的意义。

功能点估算法的特点项目范围的估算在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. 计算调整后的功能点数量。

功能点估算修改版

7
功能点估计法
内部逻辑文件（ILF：Internal Logic File）定义： 是系统里的逻辑主文件，通常，一个内部文件（ILF ）至少同一个输出（EO）或一个查询（EQ）相关。该 内部文件（ILF）作为输出（EO）或查询（EQ）的引 用文件类型（FTR）。计算方法：
8
功能点估计法—技术复杂度因子
复杂度调整表
10
功能点估计法—技术复杂度因子（续）
设前例中14 项复杂度调整项均为极其重要， 即调整值全都是 5 ，则调整后的功能点为：
FP=27 ×(0.65+0.01 ×14 ×5) =36.45
11
功能点估计法—技术复杂度因子（续）
总结： 根据用户需求确定系统需求边界和软件必须具有的功
能。 计算数据功能类型和事物功能类型功能的数目。 评估每一个功能类型的复杂度，求和得到系统未调节
简单 3 4 3 7 5
权重 一般 4 5 4 10 7
复杂 6 7 6 15 10
范例：现假设一项 目的功能项中只含 两个简单的输入和 三个复杂的输出， 则原始功能点为
UFC=2 ×3 +3 ×7 =27
3
功能点估计法
外部输入（EI：External Input） 定义：是由用户提供的 、描述面向应用的数据项，如文件名和菜单选项。其计算基 于数据元素类型（DET）和引用文件类型（FTR），关系如下 表：
功能点UFP。 确定技术复杂度因子TCP据项目特性，查询相关资料将功能点转化为工作量 （一般是代码行数）
最为简单的方法：程序语言表格(见下页表)
13
程序设计语言 ACCEL Access
EXCEL 1-2 EXCEL 3-4 EXCEL 5

IFPUG功能点估算含示例

IFPUG功能点估算含示例IFPUG（International Function Point Users Group）功能点估算是一种常用的软件度量方法，它通过对软件的功能进行分类和量化来估算软件的规模和复杂度。

功能点估算可以帮助软件开发团队更好地理解项目的规模和工作量，有助于项目管理和项目成本的预测。

IFPUG功能点估算的核心思想是将软件的功能进行分类，然后将每个功能点按照一定的规则进行加权，并与标准功能点系数相乘得出最终的功能点数。

这样可以对不同的软件进行可比较的度量，并且提供了一个基准来评估相对规模和复杂度。

1.功能性功能点包括以下四个子类：-输入（EI）功能点：表示软件接收外部输入并处理的功能。

例如，一个图书管理系统可以接收读者的借书请求并进行处理。

-输出（EO）功能点：表示软件向外部输出信息的功能。

例如，一个图书管理系统可以向读者输出图书的归还日期。

-查询（EQ）功能点：表示软件进行内部或外部查询的功能。

例如，一个图书管理系统可以查询图书的借阅记录。

-文件（F）功能点：表示软件维护的逻辑文件（包括输入和输出文件）的功能。

例如，一个图书管理系统可以维护图书的借阅记录文件。

2.非功能性功能点包括以下三个子类：-外部接口文件（EIF）功能点：表示软件与外部系统进行数据交换的功能。

例如，一个图书管理系统可以与图书供应商的系统进行数据交换。

-外部查询文件（EQF）功能点：表示软件使用的外部查询文件的功能。

例如，一个图书管理系统可以使用图书供应商的系统提供的查询功能。

-内部逻辑文件（ILF）功能点：表示软件内部维护的逻辑文件的功能。

例如，一个图书管理系统可以维护图书的库存信息。

在IFPUG功能点估算中，每个功能点都有一个权重或复杂度，可以根据软件的特点和相对复杂度进行调整。

例如，一个图书管理系统的输入功能点可能比输出功能点更复杂，因此输入功能点的权重可能更高。

下面是一个示例，用于说明如何进行IFPUG功能点估算：假设我们要开发一个学生管理系统，该系统可以记录学生的基本信息、课程成绩和考试安排等。

  1. 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
EO 补充的计算规则 除了要满足上面的通用规则外，还要满足下面其中一条：
在基本操作过程中至少包含一个数学公式或计算方法 在基本操作过程中要产生派生数据 在基本操作过程中至少要维护一个 ILF 在基本操作过程中要改变系统的行为。
EQ 补充的计算规则 除了要满足上面的通用规则外，还要满足下面其中一条：
EI 的计算规则 1. 从应用边界之外收到数据。 2. 如果进入系统边界内的数据不是一个改变系统行为的控制信息，那么至少一 个 ILF 应该被改变。 3. 对于已识别的处理过程，至少满足下面三个条件之一。
该基本处理过程的逻辑与本应用系统中其它基本处理过程的逻辑不同。该 基本处理过程应该具有唯一性。例如：不能存在两个完全一模一样的存盘 操作。
使用功能点估算法无需懂得软件使用何种开发技术。LOC 代码行估算法则 与软件开发技术密切相关。
功能点估算法是以用户为角度进行估算，LOC 代码行估算法则是以技术为 角度进行估算。
通过一些行业标准或企业自身度量的分析，功能点估算法是可以转换为 LOC 代码行的。
在项目刚开始的时候进行功能点估算可以对项目的范围进行预测。在项目开发 的过程中由于需求的变更和细化可能会导致项目范围的蔓延，计算出来的结果会 与当初 估计的不同。因此，在项目结束时还需要对项目的范围情况重新进行估 算，这个时候估算的结果才能最准确反映项目的规模。
通过一个基本处理过程的执行，对 ILF 进行维护，或从 ILF/EIF 中返回一 个特定的、用户可识别的、非重复的字段，那么每个这样的字段算一个 DET。
例如：添加一个外贸订单时需要保存“订单号码、订单日期、地址、邮编”， 那么对于 ILF 订单来说它的 DET 就是 4 个。 再如：保存订单时还会保存订单的明细。订单的明细往往作为一个子表进行保 存，那么“订单号码”在主表和子表中都同时存在（主外键）。但以用户角度来 识别时，存盘操作是一个最小的单位，那么订单号码只能算做一个 DET。
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 外部查询
功能点分析的步骤
本文将以国际标准 IFPUG（International Function Point Users Group）组 织提供的功能点估算法 V4.1.1 为基础进行讲解。如下图所示，首先大家应该了 解功能点估算法的使用步骤。
1
图 1 功能点估算法的步骤
具体步骤包括： 1. 识别功能点的类型。 2. 识别待估算应用程序的边界和范围。 3. 计算数据类型功能点所提供的未调整的功能点数量。 4. 计算人机交互功能所提供的未调整的功能点数量。 5. 确定调整因子。 6. 计算调整后的功能点数量。 识别项目的类型 国际 IFPUG 组织将软件项目分为三类，功能点估算法适用于任何一类项目：
ILF/EIF 复杂度的矩阵如下：
1 个 RET 2~5 个 RET 6 个以上 RET
1~19 个 DET 低 低 中等
20~50 个 DET 低 中等 高
超过 51 个 DET 中等 高 高
软件项目管理中的功能点估算法将功能点分为 5 类：ILF（Internal Logical File，内部逻辑文件）、EIF（External Interface File，外部接口文件）、EI （External Input，外部输入）、EO（External Output，外部输出）和 EQ（External Inquiry，外部查询）。其中，ILF 和 EIF 属于数据类型的功能点，EI、EO、EQ 属于事务类型的功能点。
在应用程序边界内，该基本处理过程所使用的这组数据应该与其他基本处 理过程所使用的数据不同。
在应用程序边界内，基本处理过程所引用的 ILF 或 EIF 是不同于其它基本 处理过程所引用的 ILF 或 EIF。
6
EO 和 EQ 通用计算规则 必须全部满足以下内容才能被视为一个 EO 或 EQ： 1. 从外部发送数据或控制信息到应用程序边界内。 2. 为了识别这个过程，以下三点必须满足一个：
基本操作过程从 ILF 或 EIF 中获取数据。 基本操作过程不能包含数学公式或计算方法。 基本操作过程不能生成派生数据 基本操作过程不能维护任何一个 ILF 基本操作过程不能改变系统的行为
其中，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 之间没有任何关系。
新开发项目 二次开发的项目 功能增强的项目 识别项目的范围和边界 使用 UML 的“UseCase”用例图是以用户角度进行识别项目范围和边界的最好 方法，在画用例图时就必须明确系统的边界。通过系统的边界，我们可以知道 哪 些功能要计算功能点，哪些功能点是外部系统负责计算的。以图 2 为例：一个外 贸订单系统只包含录入、修改、删除、查询和统计订单的功能，而汇率查询转换 服 务是不属于该系统的。 应用程序边界的识别规则大家一定要牢记，不能从技术角度去思考，必须从用 户角度来定义；如果项目牵扯到多个系统，那么必须将这多个系统的边界全部描 述清楚。
事务类型功能点的计算规则
在 IFPUG 的定义中有一个重要的单词“Elementary Process”——基本处理过 程。该过程对用户来说是一个有意义的、最小的活动单位，并且是一个自包含的 活动。功能点的分类，EI、EO、EQ 的识别都 是基于“Elementary Process”基 本处理过程的。
该基本处理过程逻辑上必须是唯一的，该唯一性是指其在应用程序中与其 他 EO 或 EQ 在逻辑性上保持唯一。
该基本处理过程所使用的数据应该是唯一的，该唯一性是指其在应用程序 中与其他 EO 或 EQ 所使用的数据不同。
该基本处理过程所引用的 ILF 或 EIF 文件应该是唯一的，该唯一性是指其 在应用程序中与其他 EO 或 EQ 所引用的 ILF 或 EIF 文件不同。
从用户角度出发识别的一组逻辑数据。 这组数据是在应用程序外部，并被应用程序引用的。 计算功能点的这个应用程序并不维护该 EIF。 这组数据是作为另一个应用程序中的 ILF 被维护的。
ILF 和 EIF 的复杂性计算
ILF 和 EIF 的复杂性是取决于 RET（Record element type）和 DET（Data element type）的数量。DET 是一个以用户角度识别的、非重复的、有业务逻辑意义的字 段。 DET 计算的规则如下：
4
RET 计算的规则如下： RET 是指一个 EIF/ILF 中用户可以识别的 DET 的集合。如果把 DET 简单理解为 字段的话，那 RET 就可以简单理解为数据库中的表。RET 在 ILF /EIF 中分为两 种类型：可选的（Optional）和必选的（Mandatory）。计算 RET 的规则为以下 两点：
EI 主要目的 主要目的 次要目的
EO 次要目的 次要目的 主要目的
EQ 不允许 不允许 主要目的
ห้องสมุดไป่ตู้
EI 可以 至少选择一次 可选 可选 可选 至少选择一次 可选 必须
EO 至少选择一次 至少选择一次 可选 可选 至少选择一次 至少选择一次 必选 可选
EQ 不可以 不可以 必选 必选 可选 可选 必选 可选
功能点估算法的特点
项目范围的估算在 CMMI 的“MA”度量分析管理和“PP”项目计划中均有涉及。 对软件项目范围的估算有很多种方法，常见的是 LOC 代码行和 FP 功能点法。它 们之间的区别和关系如下：
功能点估算法常用在项目开始或项目需求基本明确时使用，这时进行估算 其结果的准确性比较高。假如这个时候使用 LOC 代码行估算法，则误差会 比较大。
5
表 1 EI、EO、EQ 的主要目的
目的 改变应用程序的属性或行为 维护一个或多个 ILF 显示信息给用户
表 2 EI、EO、EQ 的主要行为
行为 数学公式或计算被执行 至少一个 ILF 被修改 至少一个 ILF 或 EIF 被引用 数据被重新恢复 派生数据被创建 应用程序的行为或属性被修改 准备或呈现信息到系统边界外 接受进入系统边界内的数据的能力
当两个应用程序维护和/或引用相同的 ILF/EIF，但是每个应用程序分别 维护/引用它们相应的 DET 时，这些 DET 在这两个应用程序的维护/引用中 将单独计算。
例如，一个应用程序的两个“Elementary Process”基本处理过程都需要使用 到“地址”的信息，地址信息又可以细分为“国家、城市、街道、邮编”。那么 对于其中一个基本处理过程来说，它将整 个地址信息作为一个整体进行处理， 只算一个 DET；另外一个基本处理过程使用每个地址的详细信息，那么 DET 就是 4 个。
功能点估算(CMMI-FP)含示例
（内容来自互联网仅学习共享）
功能点估算法是软件项目管理众多知识中比较有技术含量的一个。在软件项 目管理中项目 计划制定的优劣直接关系到项目的成败，项目计划中对项目范围 的估算又尤为重要。如果项目负责人对项目的规模没有一个比较客观的认识，没 有对工作量、所需资 源、完工时间等因素进行估算，那么项目计划也就没有存 在的意义。