功能点估算表(实例)
[荐]功能点估算(CMMI-FP)有实例介绍
![[荐]功能点估算(CMMI-FP)有实例介绍](https://img.taocdn.com/s3/m/3a981c1484868762cbaed578.png)
功能点估算(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. 计算调整后的功能点数量。
软件功能点估算.xls
大小估算 - FP简单个数一般个数复杂个数简单系数一般系数复杂系数外部输入(EI)100346外部输出(EO)010457外部查询(EQ)000346内部逻辑文件(ILF)01071015外部接口文件(EIF)00105710未调整FP个数(UFP)315100未调整FP合计:118UFP：未调整的功能点影响因数:分数 (0-5)理由分数: Data Communications(数据通信)00 = 无影响Distributed Functions(分布式数据处理)31 = 一般影响Performance(系统响应速度及处理能力)32 = 中等影响Heavily Used(大量使用)33 = 平均影响Transaction Rate(事务比率)34 = 重大影响Online Data Entry(在线数据输入)35 = 严重影响End-user Efficiency(用户友好度)3 Online Update(在线升级)0 通常请使用这里的缺省值，红色部分为重点考虑因数！Complex Processing(复杂处理)3 Reusability(复用性)3 Installation Ease(易安装性)3Operational Ease(易运行性)3 Multiple Sites(多站点支持)0 Facilitate Change(易改变性)3总分:33TDI：总的影响程度调整的FP合计:116根据公式计算：VAF = (TDI*0.01)+0.65 FP=UFP*VAFTDI：总的影响程度UFP：未调整的功能点VAF：价值调整因素FP转换成SLOC编程语言JavaSLOC/FP 55(从 Capers Jones table 中找到合适的值)Total SLOC:6360软件风险:注释/前提条件:注意:1. 如果你可以用历史数据，我们建议你使用它。
例如，当你设定影响因数时，你可以参考一些历史的项目。
功能点估算表
on 各阶段持续时间 Duration（Days） 200 1 236 76 13
70 60 195 15 42 130
18 68 360 0 15 357 42 56 168பைடு நூலகம்
事务功能类型 Transaction Function Type
功能数 # of Functions
低
中
高
6
17
60
0
3
51
14
14
28
未调整功能点数（UFP#） 值调整因子（VAF） 功能点数（FP #）
功能点数 Function Points ＃
生产率 Productivities （FP＃/PerDay） 总工作量 Total Effort (Person Days)
阶段 Phase 需求分析阶段 系统设计阶段 编码阶段 测试阶段 发布阶段
阶段 Phase 需求分析阶段 系统设计阶段 编码阶段 测试阶段 发布阶段
参数 每人月实现的功能点数为7个 每人月软件开发成本费为22000元
各阶段工作量分布 Effort Distributions
工作量百分比 ％ Phase-Wise 18% 1% 65% 14% 2%
低
中
高
100%
7
10
15 7 10 15
5
7
10 5 7 10
复杂度权重 Complexity weight
低
中
高
3
4
4
5
3
4
63 74 63
46 57 46
1596 1.08 1719
0.32 4346
butions
各阶段工作量（Person Days Phase-Wise）
IFPUG功能点估算含示例
IFPUG功能点估算含示例IFPUG（International Function Point Users Group）功能点估算是一种常用的软件度量方法，它通过对软件的功能进行分类和量化来估算软件的规模和复杂度。
功能点估算可以帮助软件开发团队更好地理解项目的规模和工作量，有助于项目管理和项目成本的预测。
IFPUG功能点估算的核心思想是将软件的功能进行分类，然后将每个功能点按照一定的规则进行加权，并与标准功能点系数相乘得出最终的功能点数。
这样可以对不同的软件进行可比较的度量，并且提供了一个基准来评估相对规模和复杂度。
1.功能性功能点包括以下四个子类：-输入（EI）功能点：表示软件接收外部输入并处理的功能。
例如，一个图书管理系统可以接收读者的借书请求并进行处理。
-输出（EO）功能点：表示软件向外部输出信息的功能。
例如，一个图书管理系统可以向读者输出图书的归还日期。
-查询（EQ）功能点：表示软件进行内部或外部查询的功能。
例如，一个图书管理系统可以查询图书的借阅记录。
-文件（F）功能点：表示软件维护的逻辑文件（包括输入和输出文件）的功能。
例如，一个图书管理系统可以维护图书的借阅记录文件。
2.非功能性功能点包括以下三个子类：-外部接口文件（EIF）功能点：表示软件与外部系统进行数据交换的功能。
例如，一个图书管理系统可以与图书供应商的系统进行数据交换。
-外部查询文件（EQF）功能点：表示软件使用的外部查询文件的功能。
例如，一个图书管理系统可以使用图书供应商的系统提供的查询功能。
-内部逻辑文件（ILF）功能点：表示软件内部维护的逻辑文件的功能。
例如，一个图书管理系统可以维护图书的库存信息。
在IFPUG功能点估算中，每个功能点都有一个权重或复杂度，可以根据软件的特点和相对复杂度进行调整。
例如，一个图书管理系统的输入功能点可能比输出功能点更复杂，因此输入功能点的权重可能更高。
下面是一个示例，用于说明如何进行IFPUG功能点估算：假设我们要开发一个学生管理系统，该系统可以记录学生的基本信息、课程成绩和考试安排等。
[荐]功能点估算(CMMI-FP)有实例介绍
![[荐]功能点估算(CMMI-FP)有实例介绍](https://img.taocdn.com/s3/m/4fc3008010a6f524ccbf85c4.png)
功能点估算(CMMI-FP)功能点估算法是软件项目管理众多知识中比较有技术含量的一个。
在软件项目管理中项目计划制定的优劣直接关系到项目的成败，项目计划中对项目范围的估算又尤为重要。
如果项目负责人对项目的规模没有一个比较客观的认识，没有对工作量、所需资源、完工时间等因素进行估算，那么项目计划也就没有存在的意义。
一、功能点估算法的特点项目范围的估算在CMMI的“MA”度量分析管理和“PP”项目计划中均有涉及。
对软件项目范围的估算有很多种方法，常见的是LOC代码行和FP功能点法。
它们之间的区别和关系如下：功能点估算法常用在项目开始或项目需求基本明确时使用，这时进行估算其结果的准确性比较高。
假如这个时候使用LOC代码行估算法，则误差会比较大。
使用功能点估算法无需懂得软件使用何种开发技术。
LOC代码行估算法则与软件开发技术密切相关。
功能点估算法是以用户为角度进行估算，LOC代码行估算法则是以技术为角度进行估算。
通过一些行业标准或企业自身度量的分析，功能点估算法是可以转换为LOC代码行的。
在项目刚开始的时候进行功能点估算可以对项目的范围进行预测。
在项目开发的过程中由于需求的变更和细化可能会导致项目范围的蔓延，计算出来的结果会与当初估计的不同。
因此，在项目结束时还需要对项目的范围情况重新进行估算，这个时候估算的结果才能最准确反映项目的规模。
二、功能点分析的步骤本文将以国际标准IFPUG（International Function Point Users Group）组织提供的功能点估算法为基础进行讲解。
如下图所示，首先大家应该了解功能点估算法的使用步骤。
图1 功能点估算法的步骤具体步骤包括：1. 识别功能点的类型。
2. 识别待估算应用程序的边界和范围。
3. 计算数据类型功能点所提供的未调整的功能点数量。
4. 计算人机交互功能所提供的未调整的功能点数量。
5. 确定调整因子。
6. 计算调整后的功能点数量。
三、识别项目的类型国际IFPUG组织将软件项目分为三类，功能点估算法适用于任何一类项目：新开发项目二次开发的项目功能增强的项目四、识别项目的范围和边界使用UML的“UseCase”用例图是以用户角度进行识别项目范围和边界的最好方法，在画用例图时就必须明确系统的边界。
功能点估算(CMMI-FP)含例子
功能点估算(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. 计算调整后的功能点数量。
软件功能点估算
大小估算 - FP详细计算从以下几个方面，找出各自的FP数，并确定其复杂程度输入(EI)输出(EO)查询(EQ)内部逻辑文件(ILF)外部接口文件(EIF)1. 外部输入(EI)外部输入是指用户维护系统的内部逻辑文件的一个处理过程，即对数据的新增、删除、或修改。
其复杂程度与FTR的个数，以及DET的个数有关。
数据元素类型(DET)处理中用到的ILF或EIF中的数据项总数。
2. 外部输出(EO)外部输出指数据在系统中做了些处理后的输出，通常是指经过查询后的结果进行计算而得到的结果。
比如比较复杂的报表展示。
其复杂程度与FTR的个数，以及DET的个数有关。
3. 外部查询(EQ)外部查询是数据的检索，是输入和输出的结合。
输入立即引起输出的产生。
例如，SELECT语句作为外部查询。
外部查询不应记入外部输入和外部输出中。
其复杂程度与FTR的个数，以及DET的个数有关。
判断方法同2. 输出(EO)。
4. 内部逻辑文件(ILF)存储在系统中并由系统维护，通常是数据库的表或文件，对于OA开发人员即是数据库表单、页面，帧结构集，Script库等设计元素。
其复杂程度与RET的个数，以及DET的个数有关。
记录元素类型(RET)ILF或EIF中的DET的子集。
(请参照次页的Sample)数据元素类型(DET)ILF或EIF中的数据项总数。
5. 外部接口文件(EIF)由系统使用但是由其他外部系统维护，通常是数据库的表或文件。
ImportFile往往是外部接口文件。
其复杂程度与RET的个数，以及DET的个数有关。
内部逻辑文件和外部接口文件的主要区别在于：（1） 一个文件不能同时定义为内部逻辑文件和外部接口文件，而只能是其中之一。
（2） 一个系统的外部接口文件必须是另一个系统的内部逻辑文件，由另一个系统维护。
判断方法同4. 内部逻辑文件(ILF)。
软件规模、工作量、费用测算评估样例表-两种方法
软件开发工作量评估
1、在预算阶段，需求一般较模糊，采用预估功能点计数法测算软件规模；
2、工作量、费用的测算结果宜为一个范围而不是单一值；
3、费用测算过程中宜采用不同方法分别测算并进行交叉验证。
如果不同方法的测算结果产生较大差异，可采用专家评审方法或加权平均方法确定测算结果。
4、ILF:内部逻辑文件
5、EIF：外部逻辑文件，
6、UFP:未调整的功能点数，单位为功能点
7、0.25≤复用系数τ≤1，预算阶段复用度调整系数通常取值为1（假设复用度低）；
8、US:复用调整后的软件规模，单位为功能点
7、CF:规模变更调整因子,预算时取值为1.39，招投标、项目计划时取值为1.21，需求分析阶段时取值1.1；
8、S:规模调整后的功能点，即功能规模,S＝US*规模变更调整因子。
功能点估算法
功能点是基于软件信息领域的可计算的(直接的)测量及对其复杂性的评估而导出的。
功能计算如图1所示。
针对每个功能确定了外部输出数、外部输入数、文件数、用户查询数和外部接口数等五个信息域特征，每个信息域特征值按下列方式定义。
1)用户输出数计算每个用户输出，外部输出是为用户提供的面向应用的输出信息，这些信息通常包括报告、屏幕信息、错误信息等方面的内容。
每一个外部输出数据都要进行计数，获得外部输出数。
2)用户输人数计算每个用户输入，它们向软件提供面向应用的数据。
外部输入是每个用户输入的面向不同应用的输入数据，输入应该与查询区分开来，分别计算。
3)文件数计算每个逻辑的主文件。
逻辑文件是软件修改或保存的逻辑记录集合，它可以是一个大的数据库的一部分，也可以是一个独立的文件。
4)用户查询数一个查询被定义为一次联机输入，它引发软件以联机方式产生某种即时响应，是软件以联机输出方式产生的独立查询信息。
每一个不同的查询都要计算。
5)外部接口数外部接口是所有用来将信息与其他系统进行交互或共享的端口(如磁带或磁盘上的数据文件)，利用这些接口可以将信息从一个系统传送到另一个系统。
收集到以上五个信息域特征值后，就将每个计数与一个复杂度值(加权因子)关联上。
采用功能点的组织建立了一个标准，以确定某个特定条目是简单的、平均的还是复杂的。
不过复杂的确定多少有些主观。
每个功能的总计数值可以作为这个功能的功能点使用，以估算该功能的成本和工作量。
整个项目的估算还应考虑一些全局性的因素，并不是所以功能总计数值的简单相加。
整个项目的功能点计算采用下面的公式：总FP=∑每个功能的总计数值×(0.65+0.01×∑Fi)其中，Fi(i=1，2，…，14)是基于对图2中问题的回答而得到的“复杂度调整值(0～5)”。
等式中的常数是根据经验确定的。
Fi的取值在0～5之间：Fi：(1)系统需要可靠的备份和复原吗?(2)需要数据通信吗?(3)有分布处理功能吗?(4)性能很关键吗?(5)系统在一个已有的、很实用的操作环境中运行吗?(6)系统需要联机数据项吗?(7)联机数据项是否需要在多个屏幕或多个操作之间切换以完成输入?(8)需要联机更新主文件吗?(9)输入、输出、文件或查询很复杂吗?(10)内部处理复杂吗?(11)代码需要被设计成可复用的吗?(12)设计中需要包括转换及安装吗?(13)系统的设计支持不同组织的多次安装吗?(14)应用的设计方便用户修改和使用吗?一旦计箕出功能点，则可以使用它以规范软件生产率、质量及其他属性的测量和估算，也可以类似于LOC的方法来对每个功能点的错误数、每个功能点的缺陷数、每个功能点的成本、每个功能点的文档页数、每人月完成的功能点数进行估算。
[荐]功能点估算(CMMI-FP)有实例介绍
功能点估算(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. 计算调整后的功能点数量。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
项目工作量(人月) 0.00
加权平均 ￥855.56
月工作天数 21.75
人月费用 ￥18,608.33
0 1 2 3 4 5
主模块
子模块
子节点
4
3
输 3,4, 入6 细化程度 EI Rate
总计 模块的UFP
00 0
功能点调节因子VAF
序号 1 2 3 4 5 6 7 8 9 10 11 12 13 14
总计 PERT VAF = 0.65 + Sum(Ci)/100
数据通讯 分布数据处理 性能 应用配置 事务处理频率 在线数据输入 最终用户效率 在线更新 复杂处理 复用性 安装难易 操作难易 多站点支持 变更难易
系统整体特征(GSC)
项目工作量 UFP 0
VAF
AFP
1.13
0
生产率(FP/PM) 30
原功能点数：
增长比例：
#DIV/0!
员工日工作费用
项目经理
￥1,100.00
开发总费用
项目开发费用 ￥0.00
系统分析/设计师
￥900.00
其它人员 ￥800.00
备注：
低 中 高
57 4 6 7 10
查询 3,4,6
FP EQ
0
0 0 0 0 0 0 0 0 0 0 0
0
0
0
0
0
0
0
0 0 0 0 0 0 0 0 0 0
Rate FP
0
0 0 0 0 0 0 0 0 0 0 0
0
0
0
0
0
0
0
0 0 0 0 0 0 0 0 0 0
5 15
7 10 内 部 逻 辑 文 件
输出 4,5 ,7
7,10, 15
EO
Ra te
FP
IL F
Rate FP
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
外 部 接 口 文 件
5,7,
10
EIF
Rat e
FP
0
0 0 0 0 0 0 0 0 0 0 0
0
0
0
0
0
0
0
0 0 0 0 0 0 0 0 0 0
0
0
0
0
0
00 0 0 0 0000 3 3 3 2 1 2 2 3
34
最可能(m)
5 4 2 2 4 5 4 3 5 3 2 3 3 4
49 48.00 1.13
最大(o)
5 4 3 3 4 5 5 4 7 4 2 3 4 5
58
生产率(FP/PM) 30