下载文档原格式
软件项⽬功能点（FP）估算指南⽂件编号：KT/PM-PP-0X-V0.1应⽤软件项⽬功能点（FP）规模估算⽅法修改记录⽬录1前⾔ (3)1.1⽬的 (3)1.2适⽤范围 (3)1.3术语和缩略语 (3)2功能点定义 (3)2.1信息域特性 (3)2.1.1定义 (3)2.1.1.1外部输⼊EI (3)2.1.1.2外部输出EO (3)2.1.1.3外部查询EQ (3)2.1.1.4内部逻辑⽂件ILF (4)2.1.1.5外部接⼝EIF (4)2.1.2复杂度计算 (4)2.1.2.1事务类特性复杂度估算 (4)2.1.2.2数据存储类特性复杂度估算 (5)2.2基本系统特征 (6)2.2.1定义 (6)2.2.2复杂度计算 (6)3估算功能点的步骤 (7)3.1计算UFP (7)3.2计算TCF (7)3.3计算功能点数FP (7)4输出 (7)1前⾔1.1⽬的功能性度量⽅法是⼀种独⽴于编程语⾔的软件规模度量⽅式，使⽤这种⽅法可在早期根据明确功能需求来对最终产品的规模进⾏估算。
在对软件开发环境校准以后,功能性度量的结果可以为评估开发⼯作量和软件产品的成本提供很好的指标。
1.2适⽤范围应⽤软件项⽬⽣命周期中，从需求分析开始直⾄系统测试结束均可使⽤本⽅法进⾏软件规模估算与度量。
1.3术语和缩略语EI: External Input外部输⼊EO: External Output外部输出EQ: External Queries外部查询ILF: Internal Logical Files内部逻辑⽂件EIF: External Interface Files外部接⼝⽂件UFP: Unadjusted Function Points未调整功能点TCF: Technical Complex Factor技术复杂度因⼦2功能点定义功能点技术依据对软件信息域特性和基本系统特征的评估结果来估算软件规模。
根据软件信息域特性可计算出未调整功能点（UFP），根据基本系统特征可计算出软件复杂性因⼦（TCF），最后⽤公式FP=UFP×TCF得出功能点规模。
功能点估算(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概述 (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估算流程功能点估算方法，是从软件项目的功能需求角度来评估项目规模，功能点估算流程如下图所示。
(2023)软件造价评估功能点计数模板、参数表、软件项目成本评估报告模板、评估过程示例(一)软件造价评估功能点计数模板•介绍•功能点计数模板的必要性•定义•如何使用•使用范围介绍软件造价评估是软件开发生命周期中非常重要的一环。
它可以帮助团队制定合理的项目计划和预算，同时也可以帮助评估软件的质量。
功能点计数模板是软件造价评估中非常重要的一环，它可以帮助团队更准确地评估项目的复杂度和所需要的资源。
功能点计数模板的必要性在项目开展过程中，团队需要对软件的功能点进行评估。
使用功能点计数模板可以确保评估的准确性，并能够快速生成数据，帮助项目管理。
定义功能点计数模板是软件开发中用来估算软件系统大小和复杂性的一种方法。
它通过对软件的需求文档进行分析，将软件的功能点分成多个不同的类型，并对每个功能点进行计数和分类。
这些功能点包括，输入输出，查询，转换和数据管理等。
如何使用1.了解软件开发过程2.确定所需的功能3.使用功能点计数模板对功能点进行分类和计数4.对计数的数据进行分析和评估使用范围功能点计数模板可以适用于不同类型的软件开发项目，包括 Web 应用开发、移动应用开发、安全软件开发等。
在评估软件项目成本时，功能点计数模板能够帮助团队更准确地评估所需的资源，确保项目计划和预算的准确性。
参数表•介绍•参数表的用途•如何生成参数表•参数表的分析介绍参数表是软件造价评估过程中非常重要的一环。
它用来记录和分析项目的各种参数，以帮助团队更准确地评估项目所需的资源和成本。
参数表的用途参数表可以帮助团队更全面地了解项目的各种参数，包括项目规模、开发进度、需求变更等。
通过对这些参数的分析，可以帮助团队更准确地评估项目所需的资源和成本，并制定合理的项目计划和预算。
如何生成参数表生成参数表的过程包括以下步骤：1.确定需要记录的参数，包括项目规模、开发进度、需求变更等。
2.对每个参数进行分类和描述，并确定所需的数据类型。
3.使用 Excel 或其他工具生成参数表，并填写相应的数据。
(2023)软件造价评估功能点计数模板、参数表、软件项目成本评估报告模板、评估过程示例(一)软件造价评估功能点计数模板•介绍：软件造价评估功能点计数模板用于对软件进行功能点的计数和评估。
•参数表：模板中包含需要评估的功能点名称、功能点数量和功能点权重。
•使用方法：根据模板中的参数表，计算出该软件的功能点数量，并将功能点权重相乘得到功能点价值，最终得出软件的成本。
软件项目成本评估报告模板•介绍：软件项目成本评估报告模板用于对软件项目的成本进行评估，包括开发成本、测试成本、人员成本等。
•参数表：模板中包含需要评估的成本项目名称、成本项目数量、成本项目单价和总价等信息。
•使用方法：根据模板中的参数表，计算出软件项目的总成本，并结合实际情况进行调整，最终生成软件项目成本评估报告。
评估过程示例•介绍：评估过程示例用于对软件成本评估过程进行解释和说明。
•示例流程：根据软件造价评估功能点计数模板进行功能点计数和权重计算，得出软件的功能点价值。
再结合软件项目成本评估报告模板中的成本项目信息，计算出软件项目的总成本。
最终生成软件项目成本评估报告，并根据实际情况进行调整。
如何有效使用模板进行软件成本评估•介绍：为了更有效地使用模板进行软件成本评估，需要注意以下几点：–准确收集软件项目信息；–熟悉模板中的参数表，确保数据计算准确；–根据实际情况对计算结果进行调整；–相关人员对评估结果进行审查。
模板使用的优势及应用场景•介绍：模板使用的优势和应用场景主要包括：–简化计算过程，提高工作效率；–减少误差和漏洞，提高准确性；–方便快捷地生成成本评估报告；–可应用于各种软件开发项目的成本评估。
以上就是关于软件造价评估功能点计数模板、参数表、软件项目成本评估报告模板、评估过程示例及模板使用的优势及应用场景的相关介绍，希望对您有所帮助。
软件功能点估算实例
假设我们正在开发一款任务管理软件，用户可以使用该软件创建、查看和完成任务。
下面是一些可能的功能点估算实例：
1. 用户注册和登录功能：估计需要1人天完成。
包括设计和开发用户注册和登录的界面和逻辑。
2. 创建任务功能：估计需要2人天完成。
包括设计和开发任务的创建界面、任务的字段和属性以及保存任务的逻辑。
3. 查看任务列表功能：估计需要1人天完成。
包括设计和开发任务列表的界面和逻辑，以及任务的排序和筛选功能。
4. 查看任务详情功能：估计需要1人天完成。
包括设计和开发任务详情的界面和逻辑，以及任务的编辑和删除功能。
5. 完成任务功能：估计需要0.5人天完成。
包括设计和开发任务完成的界面和逻辑，以及任务完成后的提示和状态更新。
6. 设置提醒功能：估计需要1人天完成。
包括设计和开发任务提醒的界面和逻辑，以及与系统日历的集成。
7. 数据备份和恢复功能：估计需要1人天完成。
包括设计和开发数据备份和恢复的界面和逻辑，以及与云存储的集成。
8. 用户权限管理功能：估计需要1人天完成。
包括设计和开发用户权限管理的界面和逻辑，以及角色和权限的定义。
总估算时间：8.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，以及/或者更改系统的行为。
原理Function Point Estimation 功能点估算是一种用来估算项目大小的技术。
功能点是对软件功能和规模的间接定量测量，它基于客观的外部应用接口和主观的内部应用复杂度以及总体的性能特征。
功能点法和专家法估算最大的不同点在于对估算规模的细化的定量分析上面．我们在用专家法估算的时候往往会直接去估算工作量，或在规模的估算中掺杂了生产率的数据，导致估算数据出现问题．专家法估算虽然有时候也很准确，但不能提升为组织级可以参考和借鉴的同样规则．其实专家法的估算要做准确也是遵循了功能点法估算的思路，在考虑一个软件功能究竟涉及到哪些操作，涉及到多少数据文件的存在，每个操作需要访问哪些数据文件等相关问题．只是这些想法停留在专家头脑里面而没有量化出来．我们的预测，分析和决策能力要提升，就必须对我们的经验进行模型化和定量分析．功能点法正好就起到了这个作用．其实功能点发也有不完善的地方，这可以根据我们项目实际的使用情况去不断的改进．功能点发进行估算的时候具体过程是：1.对估算功能单元的类型进行识别2.计算每种类型的复杂度．3.计算总体的调整前的功能点数4.根据调整因子对功能点数进行调整功能点估算中有5种信息域需要进行描述：其中事务类的有EI,EO和EQ，数据存储类有ILF和EIF.外部输入(EI):通过界面等的输入，插入更新等操作都是典型外部输入外部输出(EO):仅仅输出，入导出，报表，打印等输出外部查询(EQ):先要输入数据，在根据输入数据计算输出，如查询内部逻辑文件(ILF):可以理解为业务对象，可能对应多个数据表外部接口文件(EIF):其它应用提供的接口数据A.对事务类功能点的估算：对事务类的功能点估算需要确定DET和FTR两个指标：DET:可以理解为界面的录入具体数据项，按钮也要作为数据项FTR:事务功能需要操作的数据文件的数目对EI的复杂度的计算：对EO和EQ复杂度的计算：B.对数据存储类功能点的估算对数据存储类功能点的估算需要确定DET和RET两个指标DET:具体数据存储文件的数据项的数目RET:数据文件是复合文件时候关联或引用的个数．如订单数据文件由于存在订单头和明细关联引用,RET应该算2.对ILF和EIF复杂度的计算：信息域数据估算完成后可以开始考虑调整因子：调整因子是一种补偿机制，即通过五个信息域和复杂度都还没有办法考虑到的因素就应该做为调整因子．如同样一个软件系统一种是系统要支持分布式和自动更新，而另一种是不考虑这种需求，如果不考虑调整因子这两者的规模是一样的，但很明细第一种情况复杂度和规模都会更大些．有了调整因子后最终可以得到调整后的功能点数:AFP(调整后功能点)= UFP (未调整功能点数目)* AF (影响因子)实例需求：实现一个订单的录入，更新，删除和查询功能．订单信息是指一个用户订购的公司产品的情况．其中订单头包含了具体的类型，订购时间，发运地址，客户名称等信息．订单明细包含了订购的具体产品的数量的情况．假设：1.用户表和产品数据表已经建立，本次订单功能开发仅仅是引用和取这些数据．2.暂不考虑其它特殊业务逻辑和权限功能界面情况：STEP1:计算出EI,EO和EQ事务功能举例：对于订单保存功能，项目自我约定对于组合框DET算2,对于GRID的DET算3.其余界面控件DET都算1,所以可以数出DET数目为15.再来考虑FTR数目，这里需要操作订单数据文件，客户数据文件和产品数据文件FTR数应该算3.STEP2:计算出ILF和EIF事务功能1.这里订单文件只算一个DET，但后台数据表会涉及到两个数据表．由于订单头和订单明细有关联关系，所以这里RET取2.2.客户文件和产品文件虽然不是外部系统文件，但本次开发的功能并不需要再去设计该数据文件和数据表，所以这里把其作为EIF来处理．STEP3:根据对应表计算各个信息域复杂度的情况．最终的估算情况如下：最终的未调整的功能点数目为:61调整因子在这里不再举例说明了,如项目调整因子为1.08，则最终功能点数为：AFP = 61*1.08 = 66.还有些没有细化考虑的，如具体的DET数量的计算规则等，还请指正．。
1过程全图2准备文档●文档要求⏹文档应描述清楚◆有哪些内部数据需要处理◆有哪些外部系统及数据需要集成3直觉预估●直觉预估问题：⏹因为◆每个ILF内部数据需要约1.5～2人月◆每个EIF外部接口需要约1人月⏹所以◆这件事情是否值得花费这些时间？●直觉预估仅用于建立潜在对象的列表，而不是做最终确认4沟通●是：与客户确认潜在的对象是否值得开发⏹若值得开发，则客户应同意支付费用●否：沟通细节，如报告中的内容，流程的步骤等●对于无法确认的，标记为“未定”5确认●最终确认需符合简易识别标准⏹简易识别规则◆ILF（内部逻辑文件，简称内部数据）●ILF指在待开发系统内部逻辑上的一组数据●用户可以理解和识别ILF，对ILF的操作是用户的业务需求●对单个ILF平均执行6种左右的操作，而且一定包含写操作◆EIF（外部接口文件，简称外部接口）●EIF指在其它需要集成的系统中的ILF文件●“读”或“写”操作至少执行其中1种◆任何ILF/EIF只计数1次◆若有时是ILF，有时是EIF，则计数为ILF。
5.1ILF常见问题●这些一般是ILF：⏹客户的业务数据（会议，设备，人员……），对它们的操作是客户的日常业务工作●这些一般不是ILF：⏹配置数据（IP地址，邮政编码……），不是日常业务工作所需，只为了正常工作而不得已维护◆很多系统需求描述中有“系统设置”等章节，应注意⏹只有4次或以下操作的◆如“邮政编码”只有批量导入◆如“设备类型”只有最简单的增删改查●注意：“按设备类型对设备进行统计”是对设备的操作，而非对设备类型的●需要注意的情况⏹超过10次操作（含隐含的操作后），极有可能包含2个以上文件◆如对“公文”进行起草、审批、发布、转发、督办、浏览、查阅、统计……（外加保存草稿，删除，编辑……）⏹名称相近，但实际操作外观和逻辑类似◆如“日周月计划”中，若日、周计划都是关于“某日某时做某事”而只是查看时有所区别，应识别为1个⏹名称相近，但其实说的是一件或一类事情◆“领导日程”……“日周月计划”……“日程安排”……◆“违章、罚款、事故等记录”（关于交通队的信息，混在一起简单管理即可的）◆“故障、维修、加油等记录”（关于车队后勤的信息，混在一起简单管理即可的）⏹权限/流程等复杂情况◆视复杂程度定●若是针对本系统的权限且相当复杂并是业务需求的，一般是ILF⏹但一般客户仅认可1个权限文件，而不能凡有权限处均识别1个ILF●若仅是登录后即可访问，或简单的字段设置后即可访问，一般不是ILF⏹解释：这些所谓“设置”都不会超过4种操作，不值得也不需要花费1.5～2个人月⏹统计/报表/查询◆这些是EQ/EO而非文件◆很多系统需求描述中有“报表模块”“报表中心”“统计报告”等章节，应注意5.2EIF常见问题●这些一般是EIF：⏹与其他已经在运行的系统的接口（OA系统，设备管理系统……）◆这些系统中的人员，设备等常常是新系统的EIF⏹邮件/短信等提醒●这些一般不是EIF：⏹附件、需拷贝的情况◆如“可从Excel导入联系人方式”，但所谓导入是指从Excel表拷贝某格式化数据，粘贴到一个字段，而非从Excel表当作数据库表直接读取●需要注意的情况⏹EIF不是外部系统，而是外部系统的ILF◆如“邮件提醒”“通讯录”是2个EIF，而若有“短信提醒”则是第3个◆因此这些是恰当的EIF命名方法：●邮件提醒，短信提醒，邮件导入，短信回复⏹以上是4个不同的EIF⏹EIF被多次调用，只计算1次◆如会议和日程均需要邮件通知，但只计数1次◆解释：实际的确需要额外工作量，但对计数而言是2个EO而非EIF。
软件功能点估算为了能更好地理解和掌握软件功能点估算的一些规则，本文通过介绍一个需求实例来展开软件功能点估算的介绍，欢迎各位专家批评指正。
新增需求：实现一个订单的录入，更新，删除、查询、打印、导出功能，其中用户界面如下。
订单明细包含了订购的具体产品及数量的情况，明细记录数原则不限。
导出、打印、更新、删除订单记录应先从图2的查询界面查出记录，再鼠标双击某记录进入图1的增、删、改界面，也可以选择修改或删除菜单后输入订单号进入图1的增、删、改界面，新增时订单编号自动产生，更新时订单编号不能修改。
订单的明细记录在增、删、改界面可进行删除或添加处理，要添加时通过鼠标定位在编辑区按右键选择添加功能，然有会弹出一个产品列表来供操作者选择，材料代码和材料名称及单价是通过选择后自动添加的，不能人工修改，操作者只能修改订单数量，要删除时也通过鼠标定位在编辑区的某产品上按右键选择删除功能即可。
打印版面通过打印模板定制并打印到打印机、导出版面也通过excel模板定制并输出到excel文件。
其他说明：1、用户表和产品数据表本次不变，订单功能开发仅仅是引用这些数据。
2、暂不考虑其它特殊业务逻辑和权限，如：不写日志、功能按钮不根据权限加以屏蔽。
功能界面情况如下：图1：增、删、改界面图2：查询界面功能点分析：1、首先我们来确定本功能涉及到哪些用户数据（ILF,EIF）因为新增需求是订单管理，故订单信息属于一个，另外在需求中提到用户表和产品数据表本次不变，订单功能开发仅仅是引用这些数据，所以用户信息和产品信息也是系统的ILF或EIF，只不过本次新增需求时不计算它的ILF或EIF功能点，因为它没有改变，相信引用它的方式与以前一样，但在EI、EO、EQ中引用需要考虑其FTR复杂度。
另外，需求又要求打印和导出需要使用版面模板，故应该有三个模本文件。
订单类型没有提及需要动态从系统内部获取，根据一般经验应该是一个在程序中做死的下拉选择列表，到此这个新增需求涉及的ILF,EIF应为如下内容：2、然后我们再来确定本功能涉及到哪些用户事务（EI、EO、EQ）通过需求描述和界面我们不难发现，它们有新增、查询、修改、删除、打印和导出功能，只不过导出又分查询结果导出和订单导出，因为它们的内容和版面都不同，而查询结果没有提及需要打印输出，故无查询结果打印功能，查询又分批量查询和根据订单号查询。
大小估算 - 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(易安装性)3
Operational Ease(易运行性)3 Multiple Sites(多站点支持)0 Facilitate Change(易改变性)3
总分:33TDI：总的影响程度
调整的FP合计:116根据公式计算：
VAF = (TDI*0.01)+0.65 FP=UFP*VAF
TDI：总的影响程度UFP：未调整的功能点VAF：价值调整因素
FP转换成SLOC
编程语言Java
SLOC/FP 55(从 Capers Jones table 中找到合适的值)
Total SLOC:6360软件风险:
注释/前提条件:
注意:
1. 如果你可以用历史数据，我们建议
你使用它。
例如，当你设定影响因数
时，你可以参考一些历史的项目。
2. 如果你的项目可以分成几个子项
目，那你应对每个子项目分别来填写上
面的表格。
