功能点分析

合集下载

功能点分析方法的应用

功能点分析方法的应用功能点分析方法的应用功能点是软件规模的度量，是对软件的功能的细分和量化。

将功能点和其它度量数据一起分析，可以实现对软件产品的各个属性的定量、定性描述。

例如和质量参数结合分析时的缺陷密度；和生产力参数结合分析时的生产率；和成本参数结合分析是的单位开发成本等等。

成功地实施功能点分析，可以在很大程度上帮助我们掌控项目，提高工作水平。

a) 有效地沟通和交流；b) 建立度量基线，并加以跟踪；c) 尽早地发现并解决问题；d) 在做权衡决策的时候有明确的参考数据；以下讨论在项目生命周期内各个阶段内功能点分析方法起到的作用。

1. 项目立项阶段项目立项阶段的主要工作是做可行性分析，其中一个很重要的部分是对项目商业上的可行性进行分析，也就是要判断赚不赚钱。

对于软件项目来说，这是一个难以量化的工作，软件项目中有太多的不确定因素，客户需求不明确而且容易发生变化。

这是最重要的工作就是进行初步的需求分析，以期确定项目的基本范围。

如果这个项目的行业领域是企业或者项目团队比较熟悉的领域，可以根据历史经验进行分析。

如果一个企业已经实施了功能点分析方法，并且建立起了基本基础数据库，就可以在分析的时候使用这些量化的数据，这样可以使决策更加科学。

2. 项目计划编制项目计划的主要内容就是根据项目范围和需求分析，编制软件项目计划，确定时间周期、工作进度、成本、资源等等。

在软件项目计划工作中最重要的工作就是估计。

估计工作包括估计产品规模、选择生命周期、估计工作进度等任务。

估计得到的数据是编制项目计划的基础，在所有的估计活动中，估计产品规模是最基础的工作。

使用功能点分析方法能够很好地量化需求，比起按照经验估算来说更加科学。

2.1. 需求分析和评估在实际工作中，项目的功能性需求往往不能够一下子就分析清楚，项目的范围也不是一下就能够决定的，这是一个反复迭代的过程。

使用功能点分析方法，在这个反复收集、分析、测量的过程中，澄清了项目的需求，将含糊的内容都明确下来，逐步建立完整和详实的工作计划。

IFPUG功能点分析法

IFPUG功能点分析法1、功能点方法简介功能点方法是一种间接、但比较准确的软件开发工作量度量方法，目前普遍用于软件工作量估算。

功能点方法，自IBM的Albrech在1979年发表，随后被IFPUC (Internal Function Point UserCroup)继承，1999年发布了现行的4.1版。

一个功能点用一定规模的系统数据(ILF和EIF)及其处理(EI、EO、EQ)来表征，它囊括了为实现特定功能所固有和必需的需求分析、系统设计、编写文档和测试用例、编码、测试、部署、调优、培训等工作量。

功能点方法从用户需求和逻辑设计角度出发，根据软件需求规格说明书及IFPUG功能点分析法的操作规程，估算应用系统的功能点数，再从每个功能点的功能类型和复杂度两个维度，参考业界单功能点开发时长，测算出项目工作量，与具体技术和实现无关。

2、术语定义：●内部逻辑文件(ILF)是一组用户能够识别、存在内在逻辑关联、在系统边界之内被控制的数据或控制信息。

可理解为一个实体联系模型或一组关联的数据表。

●外部接口文件(EIF)是另外一个系统的ILF。

在本系统中被引用、在系统边界之外被控制。

●外部输入(EI)，一个接受来自系统边界之外的数据或控制信息的基本处理。

其目的是维护一个内部逻辑文件，或改变系统的行为。

●外部输出(EO) -个向系统边界之外发送数据或控制信息的基本处理。

其目的是向用户展示一组经过了（除提取之外的）逻辑处理的数据或控制信息，也可能包括对内部逻辑文件的维护或改变系统的行为。

●外部查询(EQ) -个向系统边界之外发送数据或控制信息的基本处理。

其目的足向用户展示一组经过提取处理的数据或控制信息，不会引起对内部逻辑文件的维护或系统行为的改变。

界面.doc报表.doc业务逻辑.doc接口命令.doc 4、数据功能类型及事物功能类型复杂度权重对应表。

功能点分析方法之一-原理篇

功能点分析方法之一-原理篇功能点分析法(FPA：function point analysis) 是一种相对抽象的方法,是一种”人为设计”出的度量方式,主要解决如何客观,公正,可重复地对软件地规模进行度量的问题.FPA 法由IBM的工程师艾伦·艾尔布策(Allan Albrech) 于20 世纪70 年代提出，随后被国际功能点用户协会(IFPUG：The International Function Point Users' Group) 提出的IFPUG 方法继承，从系统的复杂性和系统的特性这两个角度来度量系统的规模，其特征是：“ 在外部式样确定的情况下可以度量系统的规模” ，“ 可以对从用户角度把握的系统规模进行度量” 。

功能点可以用于“ 需求文档” 、“ 设计文档” 、“ 源代码” 、“ 测试用例” 度量，根据具体方法和编程语言的不同，功能点可以转换为代码行。

经由ISO 组织已经有多种功能点估算方法成为国际标准，如：①加拿大人艾伦·艾布恩(Alain Abran) 等人提出的全面功能点法(full function points) ；②英国软件度量协会(UKSMA ：United Kingdom Software Metrics Association) 提出的IFPUG 功能点法(IFPUG function points) ；③英国软件度量协会提出的Mark II FPA 功能点法(Mark II function points) ；④荷兰功能点用户协会(NEFPUG：Netherlands Function Point Users Group) 提出的NESMA 功能点法，以及软件度量共同协会(COSMIC：the Common Software Metrics Consortium) 提出的COSMIC-FFP 方法，这些方法都属于艾尔布策功能点方法的发展和细化。

功能点分析方法在软件需求管理中的应用

功能点分析方法在软件需求管理中的应用软件项目面临的一个普遍困难就是需求的不确定与频繁变更，有效管理软件需求要解决的一个基本问题是确定变更的粒度大小以及对项目的影响程度。

本文使用功能点标准度量需求的规模，使得采用量化方式管理软件需求成为可能，从而对功能点在软件项目管理方面的应用进行扩充。

1. 背景相对于传统行业的项目而言，在软件项目中经常会发生工期拖延、费用超支、质量低下、用户不满意等负面情形[1]，其原因可能包括客户要求不合理、过程管理不规范、质量意识淡漠等多种因素，但不能否认的是软件本身的特点是问题产生的根源。

相对于其他行业而言，例如土建、制造等传统行业，软件更为抽象和不易衡量，同时软件还具有容易变更的特点。

再加上软件不容易量化的特点使得软件项目的计划与跟踪粒度过粗、不能及时发现项目中存在的问题，从而导致软件项目的管理往往流于形式化，不能起到应有的作用。

软件项目管理主要从四个方面关注项目的进展状况[2]，它们依次是项目的范围、时间、成本和质量，如图一所示。

其中项目范围作为主要的变量，对其他三个指标产生明显的影响。

而软件项目范围的不确定性则会直接导致项目工期、项目成本和项目质量的不确定性。

图一：项目管理三角形软件项目范围的不确定性通常表现为如下两个方面：1. 项目前期需求不明确。

前期需求不明确导致项目范围不确定，而基于范围基础之上的工期、成本与质量目标显然也带有很大的不确定性。

正是因为需求不明确，许多项目倾向于采用固定价合同计价模式。

当后期发生追加需求时，甲方可以避免追加合同金额的情形（甲方申请由追加需求产生的额外费用是比较困难的，因为他往往缺乏有效的方法说服自己的上司追加费用与额外需求之间明确的对应关系）。

可想而知，固定价合同模式对项目的乙方会产生什么样的影响。

乙方只好做些力所能及的被动适应性工作，例如无可奈何的加班、质量方面的下降、工期方面的顺延等等。

2. 需求变更时无法做出可信的量化影响分析。

功能点分析法IFPUG

功能点分析法IFPUG功能点分析法(IFPUG)是一种常用的软件功能点评估方法，用于对软件开发中的各个功能点进行评估和估算。

它是由国际功能点用户组织(IFPUG)提出和推广的一种评估方法，是目前业界使用最广泛的功能点分析方法之一首先是鉴别功能点。

在这个步骤中，需要识别出软件系统中的各个功能点。

一个功能点是用户对系统的一个可视功能需求，它可以是一个输入项、一个输出项、一个查询项或一个用户界面。

通过分析需求文档和与客户的沟通，可以确定系统中的功能点。

接下来是计算功能点。

在这个步骤中，需要根据功能点类型的不同来计算功能点的数量。

对于输入项、输出项和查询项，可以根据其数量来计算功能点的数量。

对于用户界面，可以根据其复杂程度和用户思维的变化来计算功能点的数量。

通过计算功能点的数量，可以对软件开发的工作量进行估算。

然后是功能点评估。

在这个步骤中，需要对鉴别出的功能点进行评估。

评估功能点的复杂程度和难度，以确定其对开发工作的影响。

评估结果可以用来调整功能点的数量和开发工作的时间和资源，以更准确地完成开发任务。

最后是功能点估算。

在这个步骤中，需要根据功能点的数量和评估结果来进行功能点的估算。

通过将功能点的数量乘以每个功能点的工作量，可以得到整个软件开发任务的工作量。

根据团队的能力和资源，可以确定开发任务的时间表和资源分配。

1.精确度高：功能点分析法(IFPUG)可以通过对软件系统的功能点进行细致的评估和估算，从而得到比较准确的开发工作量和时间估算结果。

2.简洁易懂：功能点分析法(IFPUG)的方法和计算公式相对简单明了，易于理解和操作，可以快速进行功能点的评估和估算。

3. 适用性广泛：功能点分析法(IFPUG)不仅适用于传统软件开发，也适用于Web应用、移动应用和嵌入式系统等各种类型的软件开发项目。

总之，功能点分析法(IFPUG)是一种有效的软件功能点评估方法，通过对软件系统的功能点进行评估和估算，可以更加准确地确定开发工作量和时间表，提高软件开发的效率和质量。

功能点分析在测试中的应用

功能点分析在测试中的应用功能点分析是软件测试中至关重要的一个环节，它通过对软件的各个功能点进行分析和测试，以确保软件的正常运行和用户需求的满足。

在这篇文章中，我将详细介绍功能点分析在测试中的应用，并讨论它对软件测试的重要性。

功能点分析是测试过程中的关键一步。

它帮助测试人员全面了解软件的各个功能点，并确定测试策略和测试计划。

通过功能点分析，测试团队可以确保软件的每个功能点都得到充分的测试覆盖，从而减少了遗漏的风险。

正确认识软件的功能点对于测试人员来说至关重要，它们作为测试的依据，可以帮助测试人员制定准确的测试用例和测试方案，确保软件的每个功能得到充分的测试覆盖。

功能点分析还可以帮助测试团队鉴别出软件中的重要功能点。

在软件测试中，不同的功能点具有不同的重要性和优先级。

通过功能点分析，测试人员可以确定哪些功能点对于软件的正常运行至关重要，然后将重点测试资源分配给这些关键功能点。

这种有针对性的测试可以帮助测试人员更加高效地发现软件中的潜在问题，并着重解决这些重要功能点可能存在的风险。

功能点分析还可以帮助测试团队更好地评估测试的覆盖范围和深度。

通过对软件的功能点进行分析，测试人员可以计算出测试的覆盖度和深度指标。

这些指标可以用来衡量测试团队的测试工作是否充分，是否覆盖到了软件的每个关键功能点。

如果测试团队发现测试覆盖度和深度不够，他们可以根据功能点分析的结果进行相应的调整和改进，以确保测试的充分性和有效性。

功能点分析还有助于测试团队制定完善的测试用例。

在测试过程中，测试用例是评估软件功能的重要工具。

通过对软件的功能点进行分析，测试人员可以确定每个功能点所需要的测试用例类型和测试数据。

这样，他们可以有针对性地设计和执行测试用例，检查每个功能点的正确性和稳定性。

基于功能点分析的测试用例设计还可以帮助测试人员发现软件的潜在缺陷和漏洞，提高软件的质量和稳定性。

功能点分析还可以帮助测试团队更好地评估测试的进度和效果。

专题1：功能点分析法

• 功能点估算法将功能点分为以下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，但是每个应用程序分别维护/引用它们相应的DET时，这些DET在这两个应用程序的维护/引用中将单独计算。
• 例如，一个应用程序的两个“Elementary Process”基本处理过程都需要使用到“地址” 的信息，地址信息又可以细分为“国家、城市、街道、邮编”。那么对于其中一个基本处理过程来说，它将整个地址信息作为一个整体进行处理，只算一个DET；另外一个基本处理过程使用每个地址的详细信息，那么DET就是4个。
– 以图为例：一个外贸订单系统只包含录入、修改、删除、查询和统计订单的功能，而汇率查询转换服务是不属于该系统的。
图2 外贸订单系统用例图
• 应用程序边界的识别规则大家一定要牢记，不能从技术角度去思考，必须从用户角度来定义；如果项目牵扯到多个系统，那么必须将这多个系统的边界全部描述清楚。
功能点估算分类
• EI中识别DET规则
– 在EI的过程中，以用户角度识别的、通过应用系统边界输入系统内部的非重复字段，应算作一个DET。 – 在EI的过程中，只要没有通过系统边界输入，即使它存在于系统内的一个ILF中，也不能算为一个DET。
次要目的
主要目的
不允许

1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。

功能点分析IFPUG维护的功能点分析（FPA）是众多功能点评估方法中的一种，目前应用较广泛。

当前最新版本是4.2.1. 。

为了推动Function Point的方法在行业中的应用，IFPUG有推出CFPS的认证。

FPA是从用户角度出发度量软件规模的一种方法。

且该度量方法是面向用户的，从用户角度出发的，而其他的度量方法多从技术角度出发，很难让用户接收。

3、计算数据功能3.1、基本概念3.1.1、数据功能类型•内部逻辑文件InternalLogical File （ILF）•外部接口文件External Interface File （EIF）此处的文件不是传统数据处理意义上的文件，而是指一组逻辑上相互关联的数据，并不是实现意义上的物理的数据集合。

3.1.2、ILF•ILF是一组用户可识别的在应用边界内且被应用维护的逻辑相关数据或者控制信息。

•它的主要目的是通用应用的一个或几个基本处理过程维护数据。

3.1.3、EIF•EIF是一组在应用边界内被查询，但在其他应用中被维护的、用户可识别的、逻辑相关数据或者控制信息。

•EIF的主要目的是使数据在应用边界内通过一个或几个基本处理过程得以查询。

这就意味着一个应用中的一个EIF必然是其他应用中的ILF。

3.1.4、相关概念•用户可识别——它是指为处理而定义的需求或/和能被用户和软件开发者赞同和读懂的数据组。

•维护——它指的是可以通过一个基本处理过程更改数据的能力•控制信息——它是影响应用基本处理过程的数据。

它指明了处理什么、何时处理或处理方式。

•基本处理过程——一个基本处理过程就是一个用户可以理解的最小活动单元。

3.2、识别规则3.2.1、ILF识别规则•该组数据或控制信息是逻辑相关的且由用户定义。

•该组数据在应用的边界之内且通过一个或几个基本处理过程来维护。

•以上两条规则都须同时满足，才能算做ILF。

3.2.2、EIF识别规则•该组数据或控制信息是逻辑相关的且由用户定义。

•该组数据处于被计数应用之外，且被该应用查询。

•被计数的应用不对该组数据进行维护。

•该组数据被其它的应用维护。

•以上四条规则都须同时满足，才能算做EIF。

3.3、功能点计算•根据ILF和EIF的复杂度和贡献度来计算其功能点。

•ILF和EIF的复杂度和贡献度取决于以下两种类型元素的数量：o数据元素类型Date Element Types （DET）o记录元素类型Record Element Types （RET）3.3.1、基本概念•DET——一个DET就是一个唯一的用户可认知的、不重复的数据域•RET——一个RET就是一个ILF或EIF内用户可认知的数据元素子集3.3.2、DET计算规则•如果通过一个基本处理过程的执行在ILF维护或从ILF或EIF中返回一个特定的用户可识别的、非重复字段，那么每个这样的字段算一个DET•当两个应用维护和/或查询相同的ILF/EIF，但是每个应用单独维护/查询相应的DET，只计算被每个应用使用的DET•对于那些用户要求与其他的EIF/ILF建立关联的数据字段来说，每个这样的数据字段都应算一个DET3.3.3、RET计算规则•每个ILF或EIF得可选或必选子组算一个RET•如果该ILF/EIF没有子组，那么就将该ILF/EIF算作一个RET3.3.4、复杂矩阵3.3.5、功能点复杂程度对应表3.3.6、计算数据功能的提示•一个应用可以在多个处理过程中用到同一个ILF/EIF，但是这个ILF/EIF只能被计算一次•在同一个应用中一个逻辑文件不能同时作为ILF和EIF来计算。

如果一个数据集合同时满足ILF和EIF的识别规则，则当作ILF来计算。

•如果一组数据没有被作为一个ILF/EIF来计算，则可计算为包含这组数据的ILF/EIF 的DET•不要假设一个物理文件、表或对象等于一个从用户视角可以识别的数据逻辑文件•不要假设所有的物理文件都必须被计算为一个ILF/EIF，或是ILF/EIF的一部分3.3.7、计算数据功能的注意事项•以下数据不会作为ILF/EIF计算o临时文件或不同迭代阶段的同一文件o工作文件/排序文件o摘录或视图文件（在打印或显示前，从ILF/EIF中提取）o由于技术原因引入的文件o可选索引、联合、关系或联接o审计数据或历史数据，他们和应用功能数据一起计算•除以上外，以下数据也不会作为ILF计算o同一文件的复本o用作企业备份和恢复的数据（系统的基本特征）o包括不完整业务信息的中间数据•除以上外，以下数据也不会作为EIF计算o从另外系统接收的数据，用于应用中的一个或多个ILF(EI)o由应用格式化后发给其他应用的数据4、计算交易功能4.1、相关概念4.1.1、交易功能类型•外部输入External Inputs（EI）•外部输出External Outputs（EO）•外部查询External inQuiries（EQ）4.1.2、EI•是处理来自应用边界之外的数据或控制信息的基本处理过程。

•EI的主要目的是维护一个或多个ILF并且/或者改变系统的行为。

4.1.3、EO•是向应用边界之外发送数据或控制信息的基本处理过程。

•主要目的是通过逻辑处理方式向用户呈现信息，而不只是直接恢复数据或控制信息。

该处理逻辑必须包含至少一个数学公式或计算过程或生成派生数据。

•一个EO也可能维护一个或多个ILF和/或改变系统行为。

4.1.4、EQ•是向应用边界之外发送数据或控制信息的基本处理过程。

•主要目的是通过恢复数据或控制信息向用户呈现信息。

该处理逻辑不包括任何的数学公式或计算过程，不会生成任何的派生数据。

•EQ处理过程中既不会维护任何ILF，也不会改变系统行为。

4.1.5、EI、EO、EQ都是逻辑处理逻辑处理指的是用户提出的完成某个处理的请求。

逻辑处理的例子包括：•数据验证•数学公式和计算•数据的过滤和选择•分析适用的条件•更新一个或者多个ILF•引用一个或者多个ILF或EIF•运用现有的数据生成衍生数据•改变系统的行为•向应用范围之外准备和显示数据•接受进入系统边界的数据或者控制信息•恢复和重新整理数据4.2、识别规则4.2.1、EI识别规则•数据或控制信息从应用边界之外输入。

•如果穿过边界的数据不是改变系统行为的控制信息，那么至少应维护一个ILF。

•对于已识别的处理过程，至少满足下面三个条件之一：o处理逻辑与该应用中其它EI所用的处理逻辑不同o该组已识别的数据元素不同于该应用中其它EI的数据元素o所涉及的ILF或EIF不同于该应用中其它EI所涉及的文件4.2.2、EO识别规则•数据或控制信息发送出应用边界。

•对于已识别的基本处理过程，至少满足下面三个条件之一：o处理逻辑与该应用中其它EO所用的处理逻辑不同o该组已识别的数据元素不同于该应用中其它EO的数据元素o所涉及的ILF或EIF不同于该应用中其它EO所涉及的文件•还需满足下述条件之一o处理逻辑包含至少一个数学公式或计算过程o至少一个ILF被处理逻辑维护o处理逻辑改变了系统的行为4.2.3、EQ识别规则•数据或控制信息发送出应用边界。

•对于已识别的基本处理过程，至少满足下面三个条件之一：o处理逻辑与该应用中其它EQ所用的处理逻辑不同o该组已识别的数据元素不同于该应用中其它EQ的数据元素o所涉及的ILF或EIF不同于该应用中其它EQ所涉及的文件•还应该满足下述所有条件：o该处理逻辑从一个ILF或EIF返回数据或控制信息o该处理逻辑不包含任何数学公式或计算过程o该处理逻辑不改变系统行为o该处理逻辑不维护任何ILF4.3、计算规则4.3.1、基本概念•根据EI，EO，EQ的复杂度和贡献度来计算•EI, EO, EQ的复杂度和贡献度取决于以下两种元素的数量o引用文件类型FTR (File Types Referenced)o数据元素类型DET (Data Element Types)4.3.2、FTR•它是一个被交易功能读取或者维护的内部逻辑文件•或是一个被交易功能读取的外部接口文件4.3.3、DET•一个DET就是一个唯一的用户可认知的，不重复的数据域4.3.4、EI的功能点计算4.3.4.1、FTR计算规则•每个被维护的ILF算一个FTR•每个在EI处理过程中读取的ILF或EIF算一个FTR•由EI维护和读取的ILF只算一个FTR4.3.4.2、DET计算规则•完成EI的过程中，如果一个用户可识别的、非重复的字段穿越应用边界，那么该字段应算一个DET•如果在EI过程中，系统取出或派生一个字段并且该字段存储在一个ILF之内且没有穿越应用边界，则无须计算DET•如果应用能够发送一个系统响应信息（如：说明EI过程中发生错误，确认处理过程已经完成，确认处理过程应该继续）到应用边界之外，则算一个DET •即使有多种方法调用同一逻辑过程，也只能为这一特定动作计算一个DET4.3.4.3、注意事项以下不能单独计算为EI•包含在查询或输出中的输入请求•用于导航或选择不维护ILF的菜单窗口•帮助用户进行系统的登陆•激活同一逻辑的多种方法•刷新或取消窗口中的数据•需要用户删除或其他事务消息的反应•在同一系统内部（线程与批处理或客户端到服务器）4.3.4.4、复杂度矩阵4.3.4.5、功能点复杂度对应表4.3.5、EO、EQ功能点计算4.3.5.1、FTR计算规则•EO/EQ的FTR计算规则o每个在EO/EQ处理过程中读取的ILF和EIF算一个FTR •EO额外的FTR计算规则o每个在EO处理过程中维护的ILF算一个FTRo每个在EO处理过程中读取和维护的ILF算一个FTR4.3.5.2、DET计算规则•DET数量等于根据下列规则确定的字段总数•用户可识别的非重复的字段进入应用边界并且指明处理什么、何时处理或处理方式并且由EO/EQ返回或产生，那么每个字段算一个DET•每个发出应用边界的用户可识别的非重复字段算一个DET•如果字段同时进入发出边界，对该EO/EQ来说，只算一个DET•如果应用能够发送一个系统响应信息（如：说明过程中发生错误，确认处理过程已经完成，确认处理过程应该继续）到应用边界之外，这种能力算一个DET •即使有多种方法调用同一逻辑过程，也只能为这一特定动作计算一个DET•对那些虽然被保存、返回、派生的没有穿越边界的字段不计算DET•文字的，页面的，系统产生的标签不计算DET4.3.5.3、注意事项以下不能单独计算为EO•数据值不同的相同报告•不包含公式或复杂计算的报告•帮助（EQ）•退出系统•激活同一输出过程的多种方法•需要用户删除或其他事务消息的反应•在同一系统内部（线程与批处理或客户端到服务器）4.3.5.4、复杂度矩阵4.3.5.5、复杂度与功能点对应5、计算未经调整功能点数在分别识别并计算了数据功能（Data Function）和交易功能（Transaction Function）的复杂度之后，利用下表就可以计算出未经调整功能点数：6、计算调整系数和功能点6.1、调整系数（Value Adjustment Factor, V AF）VAF=（TDI×0.01）+0.65•其中TDI (Total Degree of Influence) 为所有系统特征因素影响程度的和•V AF值的范围为0.65~1.35间6.2、已调整功能点数（Adjusted Function Point）•开发项目（Development）=（UFP+CFP）×V AF•应用（Application）=ADD×V AF•增强项目（Enhancement）=[(ADD+CHGA+CFP)×V AFA]+(DEL×VAFB) •其中：o UFP为未调整功能点总数o CFP为转换功能点o ADD为增加的功能点o CHGA为增强后改变功能的UFPo V AFA为增强后调整系数o DEL为被删除功能点o V AFB为增强前调整系数6.3、系统特征因子有14个系统特征因子：•1、数据通讯2、分布式数据处理•3、性能4、资源需求•5、事务频率 6、在线数据输入•7、终端用户效率8、在线升级•9、复杂处理10、可重用性•11、易安装性12、易操作性•13、多点运行 14、易变更每个特征因子的影响程度分为6个级别：•0 毫无影响• 1 偶然影响• 2 小影响• 3 一般影响• 4 重要影响• 5 强烈影响每个特征引子的影响程度都有自己的判定规则！6.3.1、数据通讯（Data Communication）•0 应用程序是纯粹的批处理程序或者运行在独立的PC上• 1 应用程序是批处理程序，但是有远程数据输入或远程打印• 2 应用程序是批处理程序，但是有远程数据输入和远程打印• 3 对于批处理程序或者查询系统来说，应用程序包含在线数据收集或者一个远程处理前端• 4 应用程序不仅是一个前端，他还支持一种类型的通信协议• 5 应用程序不仅是一个前端，他还支持不止一种类型的通信协议6.3.2、分布式数据处理（distributed data processing）•0 应用程序不支持系统部件之间的数据传输或者处理• 1 应用程序为系统其他部件上的用户处理、准备数据• 2 为传输准备数据，将数据传输到系统的另一个部分进行处理（不是最终用户）【就是在系统个部件之间传输数据】• 3 分布式处理和数据传输在线进行并且是单项的• 4 分布式处理和数据传输是在线进行并且是双向的• 5 多数系统相应部件上都是动态执行处理功能6.3.3、性能（Performance）•0 用户没有提出任何要求• 1 提出并评审了性能，但不必采取专门措施• 2 响应时间和吞吐量在业务峰值时段是至关重要的。