[荐]功能点估算(CMMI-FP)有实例介绍.doc

《[荐]功能点估算(CMMI-FP)有实例介绍.doc》由会员分享，可在线阅读，更多相关《[荐]功能点估算(CMMI-FP)有实例介绍.doc（24页珍藏版）》请在三一文库上搜索。

1、功能点估算 (CMMI-FP)功能点估算法是软件项目管理众多知识中比较有技术含量的一个。在软件项 目管理中项目 计划制定的优劣直接关系到项目的成败，项目计划中对项目围的 估算又尤为重要。 如果项目负责人对项目的规模没有一个比较客观的认识， 没有 对工作量、所需资 源、完工时间等因素进行估算，那么项目计划也就没有存在 的意义。一、功能点估算法的特点项目围的估算在CMM的“MA度量分析管理和“ PP项目计划中均有 涉及。对软件项目围的估算有很多种方法， 常见的是LOC代码行和FP功能点法。 它们之间的区别和关系如下：? 功能点估算法常用在项目开始或项目需求基本明确时使用， 这时进行估算 其结果的准

2、确性比较高。假如这个时候使用LOC弋码行估算法，则误差会 比较大。?使用功能点估算法无需懂得软件使用何种开发技术。LOC代码行估算法则 与软件开发技术密切相关。?功能点估算法是以用户为角度进行估算，LOC代码行估算法则是以技术为 角度进行估算。? 通过一些行业标准或企业自身度量的分析，功能点估算法是可以转换为 LOC代码行的。在项目刚开始的时候进行功能点估算可以对项目的围进行预测。 在项目开发 的过程中由于需求的变更和细化可能会导致项目围的蔓延， 计算出来的结果会与 当初 估计的不同。因此，在项目结束时还需要对项目的围情况重新进行估算， 这个时候估算的结果才能最准确反映项目的规模。二、功能点分

3、析的步骤本文将以国际标准 IFPUG(International Function Point Users Group) 组织提供的功能点估算法 为基础进行讲解。如下图所示，首先大家应该 了解功能点估算法的使用步骤。人臓互功能点分析数据类型功能点分析末调整的诅整后的功能点数量凋墓因子图1功能点估算法的步骤具体步骤包括：1. 识别功能点的类型。2. 识别待估算应用程序的边界和围。3. 计算数据类型功能点所提供的未调整的功能点数量。4. 计算人机交互功能所提供的未调整的功能点数量。5. 确定调整因子。6. 计算调整后的功能点数量。三、识别项目的类型国际IFPUG组织将软件项目分为三类，功能点估算法

4、适用于任何一类项目:?新开发项目?二次开发的项目?功能增强的项目四、识别项目的围和边界使用UML勺“UseCase用例图是以用户角度进行识别项目围和边界的 最好方法，在画用例图时就必须明确系统的边界。 通过系统的边界，我们可以知 道 哪些功能要计算功能点，哪些功能点是外部系统负责计算的。以图2为例：一个外贸订单系统只包含录入、修改、删除、查询和统计订单的功能，而汇率查 询转换服务是不属于该系统的。应用程序边界的识别规则大家一定要牢记，不能从技术角度去思考，必 须从用户角度来定义；如果项目牵扯到多个系统，那么必须将这多个系统的边界 全部描述清楚。外贸订单系统图2外贸订单系统用例图五、功能点估算分

5、类功能点估算法将功能点分为以下5类：1. ILF ： Internal Logical File部逻辑文件2. EIF: External In terface File外部接口文件3. EI: Exter nal In put外部输入4. EO: External Output外部输出5. EQ: Exter nal In quiry外部查询其中，ILF和EIF属于数据类型的功能点，El、EO EQ属于人机交互事 务类型的功能点。以外贸订单系统项目为例：?录入订单、修改订单、删除订单是 EI ；? 查询订单是EO? 统计订单是 EQ? 汇率查询转换系统为 EIF? 订单和客户是 ILF六、识

6、别功能点的重要原则ILF、EIF要与El、EO EQ分开计算。对ILF和EIF复杂度的计算可以 简单理解为对数据库复杂度的计算。对El、EO EQ复杂度的计算可以理解为对 程序开发复杂度的计算。 一般软件项目都是由数据和程序构成的， 因此计算 ILF 、 EIF和计算El、EO EQ之间没有任何关系。七、部逻辑文件与外部接口文件ILF 部逻辑文件部逻辑文件是指一组以用户角度识别的、在应用程序边界且被维护的逻 辑相关数据或控制信息。 ILF 的主要目的是通过应用程序的一个或多个基本处理 过程来维护数据。EIF 外部接口文件外部接口文件是指一组在应用程序边界被查询，但在其他应用程序中被 维护的、以

7、用户角度来识别的、逻辑上相关的数据。因此，一个应用程序中的 EIF必然是 其他应用程序中的ILF 0 EIF的主要目的是为边界的应用程序提供一 个或多个通过基础操作过程来引用的一组数据或信息。EIF 所遵循的规则：? 从用户角度出发识别的一组逻辑数据0? 这组数据是在应用程序外部，并被应用程序引用的0? 计算功能点的这个应用程序并不维护该 EIF0? 这组数据是作为另一个应用程序中的 ILF 被维护的0八、ILF 和 EIF 的复杂性计算ILF 和 EIF 的复杂性是取决于 RET(Record element type )和 DET(Data element type )的数量。DET是一个

8、以用户角度识别的、非重复的、有业务逻辑 意义的字段0DET计算的规则如下：?通过一个基本处理过程的执行，对ILF进行维护，或从ILF/EIF中返回一 个特定的、用户可识别的、非重复的字段，那么每个这样的字段算一个DET例如：添加一个外贸订单时需要保存“订单、订单日期、地址、邮编”， 那么对于ILF订单来说它的DET就是4个。再如：保存订单时还会保存订单的明细。订单的明细往往作为一个子表 进行保存，那么“订单”在主表和子表中都同时存在（主外键）。但以用户角度 来识别时，存盘操作是一个最小的单位，那么订单只能算做一个 DET?当两个应用程序维护和/或引用相同的ILF/EIF，但是每个应用程序分别

9、维护/引用它们相应的DET时，这些DET在这两个应用程序的维护/引用中 将单独计算。例如，一个应用程序的两个“ Elementary Process ”基本处理过程都需 要使用到“地址”的信息，地址信息又可以细分为“国家、城市、街道、邮编”。 那么对于其中一个基本处理过程来说，它将整个地址信息作为一个整体进行处理，只算一个DET另外一个基本处理过程使用每个地址的详细信息，那么DET就是4个。RET计算的规则如下：RET是指一个EIF/ILF中用户可以识别的DET的集合。如果把DET简单 理解为字段的话，那RET就可以简单理解为数据库中的表。RET在 ILF /EIF中 分为两种类型：可选的（O

10、ptional ）和必选的（Mandatory ）。计算RET的规则 为以下两点：?在一个ILF/EIF中每一个可选或必选的集合都被计算为一个RET?如果一个ILF/EIF没有子集合，则ILF/EIF被计算为一个RET例如：在外贸订单系统中添加一个订单时会保存“订单信息、客户的ID、部门的ID”。那么订单系统ILF中的RET为：1. 订单信息（必选的）2. 客户信息（必选的）3. 部门信息（可选的）因此ILF中RET的个数为3个。ILF/EIF复杂度的矩阵如下:119 个 DET2050 个 DET超过51个DET1 个 RET低低中等25 个 RET低中等高6个以上RET中等高高软件项目管理

11、中的功能点估算法将功能点分为5类：ILF （Internal LogicalFile，部逻辑文件）、EIF （External In terface File，外部接口文件）、EI（External Input，外部输入）、EQ External Output，外部输出）和 EQ External Inquiry，外部查询）。其中，ILF和EIF属于数据类型的功能点，El、EO EQ 属于事务类型的功能点。九、El、EO、EQ的比较EI是处理来自应用程序边界外部的一组数据输入，它的主要目的是维护一个或多个ILF，以及/或者更改系统的行为。EO是输送数据到应用程序边界外部的过程。它的主要目的是通

12、过逻辑处理过程向用户呈现信息。该处理过程必须包含至少一个数学公式或计算方法，或 生成派生数据。一个EO也可以维护一个或多个ILF，并/或改变系统行为。EQ是向应用程序边界外发送数据基本处理的过程。其主要目的是从ILF或EIF过恢复数据信息来向用户呈现。该处理逻辑不包括任何数学公式 或计算方 法，也不会生成任何派生数据。EQ不会维护任何一个ILF，也不会改变应用程序 的系统行为。EO和EQ的共同点是，其主要目的都是通过基本操作过程展现数据给用 户。El、EO EQ的比较见下表。表1 EI、EO EQ的主要目的目的 |EIEOEQ改变应用程序的属性或行为主要目的次要目的不允许维护一个或多个ILF主

13、要目的次要目的不允许显示信息给用户次要目的主要目的主要目的表2 EI、EO EQ的主要行为行为EIEOEQ数学公式或计算被执行可以至少选择一次不可以至少一个ILF被修改至少选择一次至少选择一次不可以至少一个ILF或EIF被引用可选可选必选数据被重新恢复可选可选必选派生数据被创建可选至少选择一次可选应用程序的行为或属性被修改至少选择一次至少选择一次可选准备或呈现信息到系统边界外可选必选必选接受进入系统边界的数据的能力丄必须可选可选十、事务类型功能点的计算规则在IFPUG的定义中有一个重要的单词“ Elementary Process ”基本处理过程。该过程对用户来说是一个有意义的、 最小的活动单

14、位，并且是一个自 包含的活动。功能点的分类，El、EOEQ的识别都“ Elementary Process ”基本处理过程的。十一、EI的计算规则1. 从应用边界之外收到数据。2. 如果进入系统边界的数据不是一个改变系统行为的控制信息，那么至少一个ILF应该被改变。3. 对于已识别的处理过程，至少满足下面三个条件之一。?该基本处理过程的逻辑与本应用系统中其它基本处理过程的逻辑不同。该基本处理过程应该具有唯一性。例如：不能存在两个完全一模一样的存盘 操作。?在应用程序边界，该基本处理过程所使用的这组数据应该与其他基本处理 过程所使用的数据不同。?在应用程序边界，基本处理过程所引用的ILF或EIF

15、是不同于其它基本处 理过程所引用的ILF或EIF。十二、 EO和EQ通用计算规则必须全部满足以下容才能被视为一个 E0或EQ1. 从外部发送数据或控制信息到应用程序边界2. 为了识别这个过程，以下三点必须满足一个：? 该基本处理过程逻辑上必须是唯一的， 该唯一性是指其在应用程序中与其 他E0或EQ在逻辑性上保持唯一。? 该基本处理过程所使用的数据应该是唯一的， 该唯一性是指其在应用程序 中与其他E0或 EQ所使用的数据不同。? 该基本处理过程所引用的 ILF 或 EIF 文件应该是唯一的，该唯一性是指其 在应用程序中与其他E0或 EQ所引用的ILF或EIF文件不同。十三、 E0 补充的计算规则

16、除了要满足上面的通用规则外，还要满足下面其中一条：? 在基本操作过程中至少包含一个数学公式或计算方法? 在基本操作过程中要产生派生数据? 在基本操作过程中至少要维护一个 ILF? 在基本操作过程中要改变系统的行为。十四、 EQ 补充的计算规则除了要满足上面的通用规则外，还要满足下面其中一条：? 基本操作过程从 ILF 或 EIF 中获取数据。? 基本操作过程不能包含数学公式或计算方法。? 基本操作过程不能生成派生数据? 基本操作过程不能维护任何一个 ILF? 基本操作过程不能改变系统的行为十五、 El、EQ和E0的技术复杂性计算复杂性取决于FIRs和DETs的数量。FTR是被一个事物读取或维护

17、的ILF， 或者是被一个事物读取的 EIF。EI中识别FTR规则? 每一个 ILF 应该算做一个 FTR。? 通过 EI 读取的每个 ILF 或 EIF 都应该计算为一个 FTR。? 既被 EI 维护又被读取的 ILF 仅计算为一个 FTR。EI中识别DET规则? 在 EI 的过程中，以用户角度识别的、通过应用系统边界输入系统部的非 重复字段，应算作一个 DET。? 在 EI 的过程中，只要没有通过系统边界输入，即使它存在于系统的一个 ILF 中，也不能算为一个 DET。例如，外贸订单系统中，订单的金额是被单价和数量自动计算的，那么 金额是没有通过系统边界输入的，因此在 EI 操作中就不应该算

18、做一个 DET。? 在应用程序的 EI 操作时，系统提示的错误信息或完成操作的信息，应该 被分别计算为一个 DET。例如， 在注册用户信息时，由于输入错误系统会显示提示信息，那么这 些提示信息应该被逐个计算为一个 DET。再如，当El操作完成时系统提示并显示出来的信息， 应该被计算为一个 DET。? 在 El 操作中，如果遇到主外键的字段，应该算作一个 DET。EO和 EQ计算FTR的规贝U1. 通用规则：? 每个在EO/EQ处理过程中读取的ILF和EIF算一个FTR2. EO额外的FTR计算规则? 在EO处理过程中每个被维护的ILF算一个FTR?在EO处理过程中既被读取又被维护的ILF算一个

19、FTR十六、 EO 和 EQ 计算 DET 的通用规贝? 用户可识别的非重复字段， 进入应用边界并指明处理什么、 何时处理或处 理方式，并且由EO/EC返回或产生，那么这样的每个字段算一个 DET例如，报表中的每个字段都是一个 DET。? 在应用边界以用户角度识别的非重复字段算一个 DET。例如，在报表中起到解释或备注作用的文字信息，不管是一个字、一个 词或一段话，都当作一个 DET。再如，某种编号或日期，即使它被物理存储在不同字段中，但从用户角 度看是一个整体的信息，因此被算作一个 DET。还有，在饼图中百分比和分类算作不同的 DET。?在E0或EQ操作中，如果对系统进行输入或读取操作时，相

20、同的字段只计 算一个DET例如，在报表查询时，输入的字段在报表上也有显示，那么将算作同一个DET?在应用程序的E0或 EQ操作时，系统提示的错误信息或完成操作的信息， 应该被计算为DET例如，用户查询一个列表时被拒绝，那么拒绝的提示信息就算为一个DET?在E0或 EQ操作中如果遇到主外键的字段，应该算作一个 DET?在E0或 EQ过程中，只要没有通过系统边界输入，就算它存在于系统的一 个ILF中，也不能算为一个DET例如，在公司发工资的时候，员工对应的状态信息被更新，但这个状态 信息的更新是没有通过系统边界输入的，因此也不能算做一个DET?页面的标题等类似信息不计算DET?系统字段生成的记号不

21、能被算作一个 DET例如，页码、位置信息、时间、上一页和下一页等信息，都不能算作一个DET十七、 EI复杂度计算矩阵L114 个 DET515 个 DET多于16个DET01 个 FTR低低中等2 个 FTR低中等高大于2个FRT中等高高十八、 E0和EQ复杂度计算矩阵L115 个 DET619 个 DET多于20个DET01 个 FTR低低中等23 个 FTR低J中等丄高多于4个FTR中等高高未调整前功能点对应矩阵EI、EO EQ ILF和EIF技术复杂度对应的功能点如下表所示:EI34|6EO457EQ34J6ILF710 115EIF5710用功能点估算法计算软件项目功能点时会用到调整因

22、子 (或称调整系数)。功能 点的调整系数是通过通用系统特性及其影响程度来评定的，对每个常规系统特性 的评估由其影响程度(DI)而定，分为0 5级：0毫无影响1偶然影响2适度影响3 一般影响4重要影响5强烈影响然后依次对以下14个系统常规特性进行打分，并带入以下计算公式算出 功能点的调整因子。Value Adjustment Factor=( sum of (DI) * 0.01 ) + 0.65十九、计算调整因子1.数据通讯数据通讯指的是应用程序直接与处理器通讯的程度。通常我们都是通过 某种通讯手段来实现在一个应用中所使用的数据或者控制信息。连接到本地控制器上的终端被认为是通讯设施，协议则指两

23、个系统或设备之间进行通讯时使用的 一种约定。所有的数据通讯都需要某种协议。0应用程序是单纯的批处理或者PC sta nd-alo ne1应用程序是一种批处理过程，但是包含远程数据的录入 或远程打印2应用程序是一种批处理过程，但是包含远程数据的录入 和远程打印3应用程序包括在线数据收集或者包括批处理或查询系统 的远程处理的前端应用4应用程序不单只是前端应用，但是仅支持一种远程处理 通讯协议5应用程序不单只是前端应用，还支持多于一种的远程处 理通讯协议2.分布式数据处理分布式数据处理是应用在部组件之间传递信息的程度。这个特性是在应 用边界体现的。0应用程序不支持组件之间的数据传输和处理功能1应用程

24、序为用户可能进行的处理准备数据（例如使用电 子表格或者数据库等）2应用程序所准备的数据是为了在系统另外一个组件上传 输和处理，并非为终端用户所处理。3分布式处理和数据传输是在线的，并且是单向的4分布式处理和数据传输是在线的，并且是双向的5由系统中最恰当的组件动态地执行处理功能3性能性能是吞吐量、处理时间等指标对开发的影响。用户所提出的性能要求 将直接影响到系统的设计、实施、安装和支持。0用户没有提出性能方面的要求|1用户提出了性能和设计方面的要求，但不需要米取特定 措施2响应时间和吞吐量在系统峰值时是关键的，但是不需要 采取相应的CPU使用方面的特殊设计。处理的最后期限 是在下一个工作日。3在

25、任何时候响应时间和吞吐量都是关键的，但是不需要 米取相应的CPU使用方面的特殊设计。处理的完成期限 比较严格。4除了上面一项的要求外，由于对需求的要求比较严格， 在设计阶段就要进行性能分析。5除了上面一项的要求之外，在设计和实施阶段需要使用 性能分析工具来判断性能要求的完成情况。4. 大业务量配置大业务量配置是指计算机资源对应用开发的影响程度。大业务量的运行 配置对设计有特殊要求，是必须考虑的一个系统特性。0没有提出明确的运行方面的限制1有运行方面的限制，但是不需要米取特别的措施以满足 运行限制2提出了一些安全和时间方面的限制3应用程序的某些部分对处理器有特定的要求4提出的运行限制对应用的中央

26、处理器或者专用处理器有 特殊的要求5除上面一项之外，还对应用的分布式组件提出了限制5. 事务处理率事务处理率是业务交易处理速度对系统的设计、实施、安装和支持等的 影响。0预计不会出现周期性的高峰事务处理期1预计会有周期性的高峰事务处理期（例如：每月、每季、 每年）2预计每周都会出现咼峰事务处理期3预计每天都会出现高峰事务处理期4用户在应用程序需求或者服务级别协议中对事务率要求 很高，因此必须在设计阶段进行性能分析。5用户在应用程序需求或者服务级别协议中对事务率要求 很高，因此必须进行性能分析并在设计、开发和安装阶 段中使用到性能分析工具。6. 在线数据输入在线数据输入是指数据通过交互的方式输入

27、系统的程度。系统中包括在 线数据输入和控制信息功能。0所有事务都是批处理的11%7的事务是以交互式的方式进行数据录入28%15的事务是以交互式的方式进行数据录入316%23的事务是以交互式的方式进行数据录入424%30的事务是以交互式的方式进行数据录入530沖上的事务是以交互式的方式进行数据录入7. 最终用户效率最终用户效率是指对应用的人文因素及使用的便捷程度等的考虑程度。 如下功能设计是针对最终用户效率的：? 页面导航? 菜单?在线帮助或文档?光标自动跳转?可以滚动?在线远程打印?预定义的功能键?在线做批量提交任务?光标可以选取界面上的数据?用户使用大量反白显示、重点显示、下划线或其他的标识

28、?在线copy用户文档?鼠标拖动功能?弹出窗体?使用最少的界面完成某种商业功能?双语言支持（如果选择了这个就算 4项）?语言支持（如果选择了这个就算 6项）0以上的一个都不包括1包括以上的13个2包括以上的45个3包括以上的6个或以上，但是没有用户对于效率的要求4包括以上的6个或以上，对用户使用效率有较咼要求， 因而必须考虑用户方面的设计（例如，最少击键次数、 尽可能提供默认值、模版的使用）5包括以上的6个或以上，用户对效率的要求使得开发人 员必须使用特定的工具和流程以判定用户对效率的要求已经被达成8. 在线更新在线更新是指部逻辑文件ILF被在线更新的程度。应用系统提供在线更 新部逻辑文件的功

29、能。0没有在线更新1包含13个控制文件的在线更新。更新的流量低，恢复 容易。2包含对4个以上控制文件的在线更新。更新的流量低， 恢复容易。3包含对主要ILF的更新。4除了 3之外，在设计和实施中要考虑对数据丢失的防。5除了 4之外，大量的数据恢复工作要考虑成本因素，同 时包含了高度自动化的恢复流程。9. 复杂处理复杂处理描述了逻辑处理对应用开发的影响程度。它包含以下要素：?敏感控制（例如特殊的审核过程）和/或程序特定的安全处理?大量的逻辑处理?大量的数学处理?因为例外处理造成的需要重新处理的情况（例如，由 TP中断、数据值缺 少和验证失败导致的ATM事务）?多种可能的输入/输出造成的复杂处理0

30、上面一个都不满足1只满足一个2只满足两个3满足三个4满足四个5都满足10. 可复用性应用系统中的应用和代码经过特殊设计、开发和支持，可以在其他应用 系统中复用。0没有可复用的代码|1代码在应用之复用2应用中被其他用户复用的部分不足 10%3应用中被不止一个用户使用的部分超过 10%4应用遵从一种易于复用的方式被打包和文档化。用户在 源代码级客户化该应用。5应用按照一种易于复用的方式被打包和文档化。用户使 用用户参数来对该应用进行客户化。11. 易安装性易安装性指应用系统的转换和安装容易度对开发的影响程度。系统测试 阶段提供了转换和安装计划/转换工具。0用户对安装没有特定的要求1用户对安装没有特

31、定的要求，但有特定的安装环境要求H2用户提出了安装和转化的要求，转化/安装指南被经过测 试提供给用户。但是转化的影响对该应用不重要。3用户提出了安装和转化的要求，转化/安装指南被经过测 试提供给用户。转化的影响对该应用来说是重要的。4除了 2的要求之外，需要提供经过测试的自动化的安装 和转化工具。5除了 3的要求之外，需要提供经过测试的自动化的安装 和转化工具。12. 易操作性易操作性指的是应用对运行的影响程度，如有效启动、备份和恢复规程 的影响。易操作性是应用提供的一种特性，它最小化了手工操作的要求。0用户没有指定除正常备份程序外的其它特定操作1提供高效的启动、备份和恢复进程，但需要人手操作

32、12提供高效的启动、备份和恢复进程，不需要人手操作（当 作两项计算）3应用程序对磁带的需求最小化4应用程序对硬拷贝处理的需求最小化5程序设计成无人操作模式。无人操作模式的意思是除了 启动和关闭之外，不需要对系统进行操作。程序的其中 一个功能就是错误自动恢复。13. 多场地多场地指应用系统经特殊设计、开发可以在多个组织、多个地点应用的 程度。0用户需求不含多场地和组织的要求1考虑了多场地的要求，但是设计要求应用在不同的场地 使用相同的软硬件环境2考虑了多场地的要求，但是设计要求应用在不同的场地 使用类似的软硬件环境3考虑了多场地的要求，同时设计支持应用在不同的场地 使用不同的软硬件环境4在1或者

33、2的要求之上，提供了经过测试的多场地的文 档和支持计划5在3的要求之上，提供了经过测试的多场地的文档和支 持计划14. 支持变更支持变更是指应用在设计上考虑支持处理逻辑和数据结构变化的程度。 可以具有如下的特性：?提供可以处理简单要求的弹性查询和报告功能，如对一个ILF进行与（或） 逻辑?提供可以处理一般复杂度要求的弹性查询和报告功能，如对多于一个的 ILF进行与（或）逻辑（当作两项计算）?提供可以处理复杂要求的弹性查询和报告功能，如对一个或多个ILF进行 与（或）逻辑的组合（当作三项计算）?业务控制数据被保存到用户通过在线交互进程维护的表中，但变更只会在 第二个工作日生效?业务控制数据被保存

34、到用户通过在线交互进程维护的表中，且变更即时生效0一个都不满足1合计满足一个2合计满足二个3合计满足三个4合计满足四个5合计满足五个二十、计算调整后的功能点个数国际IFPUG组织将软件项目分为三类，功能点估算法适用于任何一类项 目，其计算公式中的术语请详见表1。?功能点的原始计算公式：FP Coun t =UFP * VAF?新开发项目有时新开发的软件项目也需要与其他现存的软件系统进行整合。例如：一个企业新开发的MIS部管理系统经常会与财务系统进行整合。这时除了考虑本 身项目的功能点个数外，还要考虑系统整合或数据迁移部分的工作量。 因此，其 功能点计算公式如下：FP Count =（ UFP+

35、CF）* VAF?二次开发的项目有时新开发的软件项目是在原有基础上进行二次开发的，只是为了增加 一些新功能。因此，其功能点计算公式如下：FP Coun t = ADD * VAF?功能增强的项目功能增强项目的功能点估算比较复杂。在计算功能点前大家需要 计算有哪些是新增加的功能，哪些是被修改的功能，哪些是属于数据迁 移或系统整合的功能。然后计 算新系统技术复杂度的调整因子“ VAFA， 并在此基础上计算系统功能点的数量。 当然，此类项目也会去掉一些原有 功能，那么在原有系统的技术复杂度基础上重新计算功能点的调整因子“VAFB，再计算所去掉功能贡献的功能点数量。因此，其功能点计算公式如下：?表1功

36、能点技术公式术语术语英文中文含义ADDAdded fun cti on ality被添加的功能点个数CFPponv ersi on fun ctio nality被转换的功能点个数CHG丿UFP of cha nged function ality after pnhan ceme nt功能增强后所改动的功能所贡献的未调 整的功能点个数DELDeleted fun ctio nality被删除的功能点个数UFPUn adjusted functional point count未调整的功能点个数VAFValue adjustme nt factorVAF=( sum of( DI)* 0.01

37、)+ 0.65功能点的调整因子的计算公式VAF=( sum of( DI)* 0.01)+ 0.65VAFAValue adjustme nt factor after enhan ceme nt功能增强后的功能点调整因子VAFEValue adjustme nt factor before enhan ceme nt功能增强前的功能点调整因子功能点估算实例分析以员工管理系统为例，详细说明如何利用功能点估算法计算业务复杂度。在员工管理系统中添加一个员工资料，会使用到员工的一般信息、教育 情况、工作经历和家属信息。员工隶属于某个部门，在本系统中会有一个对部门 进行维护的功能。员工的工资则由另外一

38、个财务系统提供。 因此，其用例图如下 所示：假设员工基本信息如下所示:?员工ID （标签控件）?员工名称?性别?生日? 婚否?所属部门ID （标签控件）?所属部门名称?受教育的时间?学校名称? 所学专业?工作时间?工作单位?工作部门?工作职务?亲属的?之间关系?亲属年龄?工作单位假设部门信息如下所示:?部门ID （标签控件）?部门名称假设工资表信息如下所示:?员工ID （标签控件）?员工? 金额? 单位ILF和EIF的功能点数本例识别出来ILF和EIF功能点个数如下表所示ILF部逻辑 文件RETDET个 数复杂度未调整的FP 个数员工信息员工基本信息、受教育情况、工作经历、亲属 信息，共4个。

39、18低7部门信息部门基本信息，共1个。2低7EIF外部接口文件RETDET个数复 杂 度未调整 的FP 个数工资表员工基本信息、工资信息，共 24个低5合计：19个EI、EQ和E0的功能点数本例识别出来El、EQ和 E0功能点个数如下表所示EIFTRDET个 数复杂度未调整的FP个数添加员 工信息员工、部门、 工资表员工信息的两个标签控件容不是用户输入的， 因此不算。共16个。部门信息与员工信息中的部门字段重复，因此 一个都不算。工资表中的员工ID和名称不能重复，因此只 能算金额和单位，所以共2个。18个高6修改员员工、部门、18个高6工信息工资表同上删除员员工、部门、1个中等4工信息工资表员

40、工ID添加部部门1个低3门信息一个标签控件的容不是用户输入的，因此不算修改部部门1个低3门信息一个标签控件的容不是用户输入的，因此不算删除部部门1个低门信息部门ID3合计：25个EQFTRDET个 数复杂度未调整的FP个数查询员工信息员工、部门、工资表20高6查询部门信息部门2低3合计：9个EOFTRDET个数复杂 度未调整的FP个 数统计员工年 薪员工、工资表员工ID、员工名称、年份、年薪、 单位共5个低4本系统的通用系统特性及其影响程度如下表所示系统特性分数数据通讯3分布式数据处理2性能0咼强度配置0交易速度0在线数据输入5最终用户效率2在线更新3负责的处理0可复用性3易安装性10易操作性

41、0多场地0支持变更1合计：19调整因子=19 * 0.01+ 0.65=0.84最终调整后的功能点数量为：(19 + 25 + 9 + 5) * 0.84 = 48.72 个总结功能点估算法是一个非常有用的对软件规模进行估算的国际通用技术， 是项目管理人员必须掌握的工具。为了便于大家对功能点的技术进行理解和记 忆，这里对其进行总结：由于计算机软件就是为了实现无纸办公，那么在估算功能点时应该多以 用户的纸质表单为依据，每个表单就是一个 ILF或EIF，表单上显示的字段都是 DET 一个表单上的“核心”容不管是由几个数据表来分别存放数据的，每个表 都是一个RET简单来讲，ILF和EIF可以被看作数

42、据库中的数据表，但是主、从表将 被视为一个ILF或EIF。那么，ILF和EIF的复杂度就是由数据表中的字段 DET 和一个ILF或EIF自身所包含的主、从表个数RET来决定。在计算DET时主、外 键只能算作一个。EI就是对应用户增加、修改、删除的操作，EO和 EQ都是用于用户查询的操作。EO和EQ的区别是，EO查询时使用了数学公式或计算方法。El、EQ和 EO 的复杂度是由FTR和DET决定的。FTR的个数由ILF和EIF的个数决定，可以由 主表中主、外键的个数来计算。在计算EI的DET时，只有用户在 界面上直接输 入的信息才算作DET通过页面自动计算或转换的数据不能算作EI的DET在EO和 EQ计算DET时，报表的标题、页码等信息不能被计算为一个DET