功能点分析法的实践与应用

1、 功能点分析法在环境监测管理系统项目开发中的应用Function Point Analysis in Development of Environment Monitoring Management System)秦波（ 马鞍山市环境监测中心站 ）摘 要 功能点分析是软件测量的重要工具 , 本文对其在一个具体项目的开发管理中的应用进行了介绍和探讨。关键词 功能点分析，UML软件项目管理，环境监测管理系统Abstract FPA is an important tool of software measurement , This paper describes the application

2、of Function-Point-Analysis in a real software project management.Key words FPA ; UML; Software Project Management; Environment Monitoring System1问题的提出1.1项目背景 环境监测管理系统的主要功能有：监测任务管理，监测数据采集分析，监测报告生成模块，数据分析评价，委托协议管理，档案管理，固定资产管理，样品试剂管理，财务结算管理等子系统。某单位虽拥有自己的计算机开发人员，但是由于工 作量巨大， 必须与多家软件公司合作开发该系统。 这样， 问题就来了。

3、首先， 各方的工作量如何核算， 公平地支付费用？ 其 次，项目管理困难， 无法掌握各方的具体项目进度， 合理分配工作。 这两个问题几乎是困扰所有软件开发项目管理人员的 “雾 区”。而其核心，实际上是如何对软件工作量进行科学合理的度量的问题。1.2 功能点分析法概念 那么，有没有比较科学而有效的软件度量方法（ Software Metrics ）呢？目前国际上，主要有两种方法，这就是代码行（Line-of-code简称LOC）估算和功能点分析法（Function-Point-Analysis简称FPA）。LOC是一种传统的估算方法，目前许多的软件估算模型就是基于它的，但是LOC过于依赖编程语言，

4、而且我们很难在系统分析完成之前估算产生的LOC，采用FPA方法，则可以很好地弥补 LOC的不足，取得比较理想的效果。FPA是一种基于数量计算的测量软件系统规模，工作量大小的计算方法，是基于软件信息领域的可计算的（直接）测量和软件复杂性的评估而导出的。它的计算方法比较直观，而且易于理解使用。FPA首先是由IBM的Allen Albrecht于1979年提出的，1984年由IFPUG公布了技术标准，目前最新的版本是 4.1。FPA为我们测算工作量大小和项目进度安排提供了较为准确的数值依据。它肯定比传统的基于经验估计的方法更加科学准确。功能点至今尚没有一个准确完整的定义，我们可以将其理解为“实现单位

5、功能所需的成本耗费”。研究表明：一个功能点相当于中等复杂程度系统里105114行COBOL程序。1020%，但是，第二、功能点分析的精确度会随着开发经验的积累而增长，第一次项目工作量估算误差可能会达到 第三次项目的误差会缩小到 15%。1.3 问题的解决目前在IBM，LuckSoft等许多软件公司广泛采用,但是， 国内的资料很少，功能点分析的应用在国际上已成为标准之一， 几乎没有听到应用的例子。FPA是软件定量化测算的有效手段，根据其对系统规模的测算结果，许多让项目管理者头疼的事 情都可以迎刃而解，体现在：确定项目开发的成本及费用；排定科学合理的开发计划； 方便人员分工，工作量分配； 对系统进

6、行优化调整，提高生产率等。经过研究和探讨，双方决定在本项目中采用功能点分析法进行度量和项目管理，本文主要介绍FPA在环境监测管理系统项目开发中的实际应用。2. FPA结构和原理FPA认为整个项目的规模由三个部分构成：（1）信息处理规模 指系统包含的所有与外部交流的界面（输入，输出，查询界面，控制信息等），处理的文件（数据文件，数据库表） ，及与外部系统的接口等。这些内容按照其特性划分为五种元素：输入El (External Inputs),输出EO (External Outputs),查询EQ(External Inquiries)，文件 ILF (Internal Logical File

7、s)和接口 EIF( External Interface Files )。依据标准可以计算出系统 (或 模块)中所含每一种元素的数目，乘以加权值，其合计数即为信息处理的规模，称为UAF( Unadjusted Function Points 。技术复杂度指系统实现的复杂程度，按照系统特征分为十四个方面，他们是：数据通讯、分布式数据处理、性能、硬件负荷、事务 频度，联机数据录入，界面复杂程度，联机更新，内部处理复杂程度，代码复用考虑，转换和安装，备份与恢复，多平台考 虑，易用性。依据对每个方面的打分(0至U 5)推导出“调整系数”(Value Adjustment Factor)VAF。其推导

8、公式为：VAF=0.65+0.01 XE Fi，其中Fi为每一个问题的分数。环境因素指由外部因素决定的系统开发效率，称为“生产率系数”，即每个功能点耗用的时间(Hours/FP)。这个数据与开发时采用的工具，开发经验，项目大小有很大的关系。利用该值才能把功能点转换为时间概念，得到单个功能模块，以至于整个项 目的工作量(时间)。FPs=UAF X VAF。而以上三个方面因素的计算结果就构成了由(1)和(2)可以推算出系统的内在规模，即总的功能点数 一个软件项目的整体规模。3. FPA应用实例3.1需求分析阶段的功能点估算UML用例图(USE CASES )进行功能点的估算。为了更好FPA分析的步

9、骤和方法。在本系统的需求分析完成后，我们就依据设计文挡，系统的地理解FPA，下面将介绍系统中一个模块“监测任务管理”来说明 用例图见图1，事件流(flow of events )描述由于篇幅所限略去。A监测及分析 人员图1“监测任务管理”子系统的用例图计算步骤如下：一.计算未经调整的功能点数(UAF )计算功能模块所含的输入，输出，查询，文件，接口数目(对于USE CASE图，主要是参照Flow of Events描述来计算)。输入(EI)：指对于文件(ILF )的维护界面，它必须含有对一个或多个文件进行的维护(增删改)操作。用例1和3中含有对“任务”表和“监测结果”表的添加，删除，修改操作，

10、初步计算为2 X 3= 6个EI。(注：虽然增删改操作可能集中在同一个屏幕进行，也应当分别计算)。输出(EO)指系统依据输入的条件产生的报表，屏幕和输岀文件(例如：文本文件，EXCEL文件等)。用例4 “任务报告打印”含有一个报表(EO)。查询(EQ):指检索查询的个数，表现形式为：用户输入查询条件，对内部文件或外部接口文件进行检索，产生查询结果。EQ与EO的屏幕比较容易混淆，他们的区别是：EQ不能对文件或接口进行修改操作，也不包含通过计算产生的结果。用例2 “任务 执行”含有两个EQ: 个是输入查询条件后产生的“任务”列表屏幕，另一个是在列表的条目上用鼠标双击产生的任务明 细情况屏幕。（4）

11、文件（ILF）指在本系统范围内负责维护的逻辑文件（实体），从设计文档的“ Data Modal ”图中可以比较容易地计算出来。本例中假设含有两个ILF （任务表，监测数据表）。（5）接口（ EIF）如果应用牵涉到的文件不属于本系统维护的范围，例如：仪器数据采集接口，称为外部接口文件（EIF）。本例含有一个数据接口，采集大型仪器的某些分析结果。对上述数据进行加权合计，统计岀未经调整的功能点总数，见表2：表1UAF计算表类型数量权值（平均值）结果EI6424EO155EQ248ILF21020EIF177UAF合计64表1中权值的取法有一系列的标准，分为高、平均、低三档。但由于在生命周期的早期，系

12、统分析没有完成，屏幕与报 表的细节还无法确定，所以一般推荐取平均值，当然，如果采用同类项目的经验值，效果最好。需要说明的是，由于输入、输岀、查询的权值差别不大，所以即使搞混淆了，也没有太大关系。但是有一条原则需要牢 记：不要疏漏任何可能发生的工作量，即使目前你还不能确定。二.确定复杂度调整系数（VAF ）FPA依据系统对十四个方面的问题的考虑程度来打分确定VAF的取值。一般的GUI应用对于事务频度、界面复杂程度、联机更新、代码复用程度、联机数据录入这五个方面比较关注，分数高一点，分别为3、4、3、2、5,其他方面考虑的则比较少。关于VAF的确定有一系列的细则，但是，复杂度的打分多少有点主观。参

13、照计分标准得出总分数为17，则该模块的VAF依据推导公式：0.65+0.01 XE Fi=0.65+0.01 X 17=0.82。现在，该模块的功能点数可以确定了：FPs=UAF X VAF=64 X 0.82=52.5完成这一步，你基本可以估算出项目的大小和费用情况了，国外一个功能点的费用为 160-200美元，国内当然要打折扣，这就是无奈的现实。经过讨论，大家同意按照 800元每个功能点收费。这样该模块的估价为：800X 52.5=.42000元。至于整个项目的成本费用则以此类推可以得到，但是记住这个阶段由于详细设计尚未完成，软件实现的细节无法掌握，只能是个估价，不能作为最终费用。三计算“

14、生产率系数”“生产率系数”由开发工具、开发人员素质、代码复用率等方面决定。我们采取了直接有效的办法，通过对开发人员直接进行测试，获得每个人的开发效率。按照每人每月160工作时计算，对于中小型项目（小于3000FPS），开发效率为60100FPS/月人。这个值比较高，一方面是由于采用Delphi7开发工具，另一方面，是由于开发组成员都有着多年开发经验，非常熟练，代码复用率比较高。按保守的情况，算出每个功能点需要160/60=2.67小时。所以，该模块如果由一个人开发，需要2.67 X 52.5=140工作小时（合 20个工作日）的工作量。关于每种开发工具的开发效率， Caper Jones在Pr

15、ogramming Languages Table一文里有专门论述，按照文中的数据， 如果采用VB、PB等工具，每个人月的开发效率的平均值为 1630个FPs。目前，由于面向对象和组件技术的发展，以及代 码复用率的提高，一个熟练的开发员的开发效率超过100个FPs/月是完全正常的。3.2系统分析阶段的功能点计算由于在软件生命早期，软件实现的细节无法掌握，所以表1中采用的加权值为平均值。在系统分析完成后，需要根据规格说明文档对功能点的加权值进行修改校正。关于加权值的取值范围，见表3表3功能点加权值类型LOWAVERAGEHIGHEI346EO457EQ346ILF71015EIF5710那么，如

16、何判定每一种类型的加权值呢？对于El、EO、EQ来说，主要是确定界面的复杂程度。 这里引入两个概念 DET （ Data Elements Type）和FTR （ File Type Reference）。DET指界面上的动态控件，例如：数据敏感控件、动作按钮、计算字段、动态菜单、提示与错误窗口等。FTR指界面涉及的ILF和EIF。DET和FTR的数目越多，权值越高。本例中，用例 3 “监测数据录入”的屏幕（EI）所含DET超过 19个，涉及3个FTR （数据明细、数据说明和任务回复），权值应当取高值 6，因而，EI的功能点必须调整为 3X 6=18。同 理，系统内所有其他El、EQ和EO也必

17、须进行类似的调整。（2）对于ILF、EIF来说，主要是确定数据构成的复杂程度。这个复杂程度由其所含的DET和RET数目确定，这里的DET主要指的是数据字段，RET （Record Element Type）指的是文件中包含的数据子集。本例中的“任务”文件（ ILF ）包含了 一个子表（父子关系），其RET应记为两个，数据字段（DET）数目为33，因而，该ILF的权值应当取平均值10。关于加权值的取法，IFPUG提供了详细的对照表，限于篇幅，本文就不赘述了。通过重新计算整个项目的功能点数，本项目的费用，进度，工作安排也应做岀了相应调整。详细设计阶段的功能点测算 结果基本是准确的了。3.3功能点分

18、析与软件开发过程在整个软件项目的开发周期里，需要对功能点进行多次的计算，在软件生命周期的早期，就可以对整个项目的规模进行估算，作为计算费用成本、排定进度计划、调整人员分工和程序结构的依据，这一点，采用LOC方法很难实现。随着系统分析设计的深入，应当不断进行校正调整，以获得准确的数据，辅助项目的管理。系统完工时，应当提供准确的功能点数，作 为成本和收费的依据。如果系统需要增减功能，还可以做岀相应的计算调整。需要说明的是：功能点包含了系统从设计到测试完成的全部工作量，而不仅仅是编程，实际上真正编程（Coding）的工作只占整个工作量的 15%30%。4 结束语在“环境监测管理系统”项目的实施过程中由于采用了双方认可的测算标准，费用的测算有据可查，进度控制和人员分工的问题基本得到解决，保证了整个项目的顺利实施。应该说，取得了比较理想的结果。FPA的计算方法还是比较易于理解和掌握的，其算法和标准是有科学依据的，而且它还在不断进行调整和发展，变得 越来越严密。我们有理由相信，随着中国软件开发的规范化程度和软件项