前    言

　　提及软件功能点，有些读者可能会认为“不就是我们常说的功能模块、功能点么？这也值得费神费力地写本书来讨论”。其实软件功能点度量方法作为一种度量软件规模的标准，于20世纪90年代已经在世界范围内得到普遍的应用。如果考虑IFPUG功能点标准，自1979年就由IBM的Allan Albrecht提出，功能点度量方法发展到今天已经超过了30年。所以本书所描述的功能点度量方法是一套用于度量软件规模的标准，它采用规则约束的方式来衡量软件规模的大小。基于软件功能点度量方法，可以在关心软件规模的人员之间建立一种客观、透明的评价机制，使得软件规模的评价工作摆脱传统评价方法所具备的“黑盒子”特征。

　　软件行业作为一个新兴行业，几乎在促进每一个传统行业的升级换代。正是因为普遍地采用了软件技术，我们的生活和工作变得越来越方便、快捷。但软件行业带给人们方便的同时，也给人们带来了一系列的难题：如何评价开发和维护软件所需的代价？应该为软件项目设置多长的开发工期？如何评价软件系统的质量，而不是毫无预见地接受来自最终用户的抱怨和指责？诸如此类的问题总是成为客户和软件开发商所讨论的重点问题。因为软件本身所具备的“不透明”特点，所以在软件项目的前期可行性研究阶段、招标阶段很难确定软件项目对应的预算和相应的开发工期等关键项目管理指标。

　　随着软件行业成熟度的提高，国家对于软件项目预算监督的要求也进一步提高，软件开发项目逐渐也要遵循严格的招投标模式。对于软件项目的招投标，客户往往会采用“倒推法”确定软件项目工期。即以客户方软件项目立项时批准的工期为依据，要求软件开发商提供满足该工期约束的技术方案建议书。项目工期采用预先设定的方式，客户更多考虑自己的业务需求、市场特点、领导意愿等因素，而对实现软件项目的技术因素则考虑不足。对于软件项目的费用评价普遍采用“低价中标”原则。根据软件开发商的报价来比较开发商之间的价格，最终选择低价中标。软件开发商的报价方法目前仍然停留在“拍脑袋”、类比法等粗粒度的经验估算法层面。这些方法的弊端在于不具备客观性，不同的人员可能会给出完全不同的结论。对于那些没有足够技术背景的客户来说，这种粗粒度的估算方法更是缺乏说服力。

　　例如客户需要开发一个网上茶叶城应用系统，要求开发方给出报价和工期。开发方通常会采用如下的方式：

估算方法类型 估算对象 费用 工期 备注 拍脑袋 网上茶城 确实需要50万元，我真的没有骗你 既然要求6个月，那我们就设6个月吧 如何让客户相信没有虚报的成份呢 类比法 网上茶城 需要50万元，以前的项目就需要这么多 既然要求6个月，那我们就设6个月吧 工作分解结构法 网上茶城 需要50万元。具体的功能拆分如下：

功能一：用户注册；5人天；4000元

功能二：普通用户升级为VIP用户；8人天；6400元

功能三：茶叶订购；15人天；12000元

功能四：礼包促销；10人天；8000元

……

功能九十：防伪码查询；4人天；32000元 需要6个月。具体的时间拆分如下：

功能一：用户注册；10天

功能二：升级为VIP用户；14天

功能三：茶叶订购；20天

功能四：礼包促销；8天

……

功能九十：防伪码查询；5天 说明：每个功能模块的费用采用资源单价的方式估算。例如功能一需要5人天，假设每人天的对应费用为800元，则对应的费用即为5×800=4000元

　　以上三种方法即为常用的报价方法，前两种方法的弊端在于过于粗略；第三种方法虽然更为详细，但每项功能所需的工作量仍然对客户不透明。例如功能三：茶叶订购所需的工作量为15人天，客户可能就会有疑问，5人天行不行？5人天不行，10人天应该没问题吧？所以即使采用工作分解结构法，仍然不容易在客户和开发方就软件开发的费用达成    一致。

　　所以不论是软件项目的费用还是工期的确定，都存在较强的主观性。对于软件项目而言，很难从第三方的角度去评判一个软件项目的费用是多还是少？工期是长还是短？不妨将视线转移到其他行业，例如建筑业。如何确定一栋大楼的建设费用和建设工期？首先要知道大楼的建筑面积，然后再根据国家和地区所颁布的定额标准进行核算。通过这种方式可以得到该大楼的建设费用和建设工期。例如要在北京方庄南路建造一处商品住宅楼盘，假设每平方米的造价为14 000元（含土地购置费用），该楼盘的建筑面积为50 000平方米，那么就可以得到该楼盘的大概造价为14 000×50 000=7亿元。在这个例子中我们用平方米作为单位去衡量建筑面积，但我们用什么作为单位来衡量软件系统的大小呢？读者可能会给出一系列的例子：可以使用功能模块数量、代码行数量、用例数、需求数、甚至需求的页数等。但特别需要注意的是，与建筑行业所使用的平方米相比较，衡量软件系统规模的这些单位都不是标准单位，因而也就无法采用定额方式来计算软件项目的费用和工期。

　　何谓标准单位？标准单位即用于衡量所关注对象的某一属性时采用的尺度。例如，使用“平方米”衡量面积；使用“米”衡量长度；使用“千克”衡量重量等。因为此处的“米”或“千克”在实际操作中不存在二义性①，所以就可以使用“米”或“千克”来描述我们所关心对象的长度或者重量。而功能模块、代码行、用例数、需求数在实际的操作过程中并不具备标准单位的属性，只能被认为是衡量软件系统规模的粗略尺度。如果衡量单位本身就存在较多变数，所得结果的说服力也就可想而知了。正是基于将软件规模衡量单位标准化的考虑，本书的主题为软件功能点度量方法及其在实际工作中的应用。

　　软件的大小可以通过交付给用户的功能点数来度量，就如一间房子的大小通过提供给用户的建筑面积或使用面积来度量一样。根据ISO的标准表述，功能点分析方法的目的是量化表述用户功能性需求的软件规模（A size of the software derived by quantifying the Functional User Requirement）。目前ISO标准ISO/IEC 14143认可有5种度量软件项目规模的方法，分别是英国人Charles Symon提出的Mark II功能点标准（http://www.uksma.co.uk）；加拿大非盈利组织COSMIC提出的COSMIC功能点（http://www.cosmicon.com）；芬兰软件度量协会提出的Fisma功能点标准（htpp://www.fisma.fi）。此外，还有荷兰软件度量协会提出的NESMA功能点标准（http://www.nesma.nl）和美国IFPUG组织提出的功能点标准（http://www.ifpug.org）。相对于其他4种功能点标准而言，目前IFPUG所维护的功能点标准CPM4.3.1是应用最广泛的功能点标准。事实上，其他4种功能点方法都在它的基础上发展而来。在全球采用功能点度量方法的组织中，估计采用IFPUG功能点标准的组织所占的比例不低于90%，而采用其他4种功能点标准的组织加起来的比例也不会超过10%②。所以本书虽然兼顾介绍了其他4种功能点标准的操作方法，但以IFPUG的功能点标准作为本书介绍的主要方法。

　　笔者从十余年前开始在软件企业中应用和研究功能点方法，并致力于功能点方法在国内各种软件组织的推广应用。在笔者提供功能点度量方法培训和咨询的过程中，越来越认识到功能点度量方法的必要性。功能点方法的采用将有助于解决我国软件行业所面临的普遍问题——“说不清、管不住”，对提升软件项目管理水平有很强的针对性。但不同的软件组织在导入和应用功能点方法的过程中，经常面临以下4方面的误区：

　　（1）没有充分认识到定量管理的重要性。

许多软件行业的管理人员倾向于将软件项目中出现的各种问题简单归结为个人能力和责任心不足，而对于项目目标设置的合理性与客观性重视不足。试想，如果不能采用量化的方式客观评价开发团队将要完成的工作内容，如何评判就一定是人员的绩效问题呢？更可能是目标本身不合理。

　　（2）不了解功能点标准。

　　不少从业人员也在积极探索采用各种方法量化评价软件项目规模，例如前文所述的代码行、需求数、用例数等，但这些方法皆因不具备标准单位的特点，很难在组织内获得普遍接受。

　　（3）对功能点标准望文生义。

　　有些读者一听到功能点标准，就觉得不可操作。功能点嘛，谁还不了解啊？不同的功能点如何能比较啊？殊不知，这些基本问题都解决不了的话，功能点方法如何能够被ISO接受作为国际标准呢？功能点方法又何以具备如此旺盛的生命力呢？也有部分人员通过阅读软件工程方面的教科书了解功能点方法，便在实际工作中动手操作，但凡一操作就会觉得头绪太多，例如一个功能到底应不应当算作事务功能，一个基本过程应算作输出功能（External Output）还是外部查询(External inQuiries)等问题会接踵而至。功能点方法是一个完整的标准，其内容多达500多页（CPM4.3.1标准全文535页），远非教科书几页纸的内容能够讲述清楚，所以仅依靠软件工程等概述功能点标准的资料进行功能点操作一定会面临许多困难。

　　（4）对功能点标准的应用画地为牢。

　　对于有些已经较好地掌握了功能点操作方法的组织而言，他们却将功能点度量应用仅限于软件项目工作量评价。要知道对软件项目度量而言，软件项目规模是一个最基础的度量指标，所以如果得到软件项目的功能点，就可以以功能点作为基准去衡量软件项目的不同属性，并可以在不同的软件项目之间，甚至在不同的软件开发组织和运维组织之间比较软件项目的绩效水平。所以除了掌握软件功能点度量方法之外，还应该有意识地在组织内外广泛应用软件功能点度量的结果。功能点度量结果只有得到更多的应用，才能表现出该项工作的真正价值。

　　正是基于以上几点原因，笔者才敢于不揣简陋，将自己对于软件功能点度量方法所了解和思考的内容形成文字，以期与对功能点感兴趣的各位读者一起学习，一起进步，共同推动功能点度量方法在我国软件行业中的实践与应用。

　　为了方便读者阅读，本书内容采用以下的安排方式。建议读者按顺序阅读，如果读者已经掌握了功能点度量方法，也可选择性地阅读感兴趣的章节。各章内容概述如下：

　　第1章  软件功能点度量方法概述  介绍软件功能点出现的背景以及目前被纳入ISO国际标准的5种功能点标准（MarkII功能点标准、NESMA功能点标准、COSMIC功能点标准、FISMA功能点标准和IFPUG功能点标准）的操作方法，并对不同的功能点标准进行横向比较，指出各自的适用范围及其优缺点。

　　第2章  软件功能规模度量过程  介绍IFPUG功能点标准度量功能规模的详细过程以及注意事项。

　　第3章  度量数据功能  数据功能包含内部逻辑文件（Internal Logic File）和外部接口文件（External Interface File）两种类型，本章介绍ILF与EIF的识别及其规模的度量规则，还以实例方式描述数据功能的度量过程。

　　第4章  度量事务功能  事务功能包含外部输入（External Input）、外部输出（External Output）和外部查询（External inQuiry）3种功能类型，本章介绍识别事务功能及度量其功能规模的所有规则，还以实例的方式描述事务功能的度量过程。

　　第5章  计算功能规模  介绍在不同的情形下如何计算功能规模，包括开发项目功能规模计算、升级项目功能规模计算以及应用功能规模计算。此外，还补充介绍转换功能的度量及升级项目的度量。

　　第6章  软件功能点度量实例  以一个完整的“图书管理系统”为例，介绍功能点度量的详细步骤，包括如何确定功能规模度量的范围和边界，如何度量数据功能和事务功能。

　　第7章  软件功能点度量应用场景  与前面的章节不同，本章重点介绍功能规模度量结果的应用场景，读者可以参考相关建议将度量得到的软件规模应用到实际工作中。

　　第8章  软件功能点度量常见问题  本章列举了功能点度量过程中的常见问题，并对功能点度量过程中一些容易混淆的概念和方法进行辨析，引导读者如何基于规则进行功能点度量。

　　附录A  计算调整后功能规模  介绍用调整系数对功能规模进行调整，得到调整后功能规模的方法。

　　附录B  功能点度量快速参考  软件度量人员在度量软件功能规模的工作过程中，经常需要查阅度量规则以及计算公式等。为方便读者使用，本附录总结了功能规模度量过程中用到的主要定义、规则、表格及计算公式。

　　附录C  认证功能点专家（CFPS）考试介绍  为保证功能规模度量过程的一致性和客观性，IFPUG组织制定了严格的认证功能点专家（Certified Funtion Point Specialist）认证程序。本附录说明了具体的认证要求以及相关的注意事项。

　　本书在写作过程中得到了清华大学出版社柴文强编审的悉心帮助，笔者在此谨向柴老师致以诚挚的谢意。

　　鉴于笔者的能力和经验有限，读者在阅读和使用本书的过程中可能会发现这样或那样的不足，恭请各位读者提出批评指正，也欢迎各位就感兴趣的话题与笔者一起交流，共同进步。祝愿大家在学习和应用功能点度量方法的过程中取得丰硕的成果。

　　联系方式：caoji@suiji.com.cn 

　　          wenli@suiji.com.cn

　　编  者

　　2012年5月

　　① 由计量组织维护各种相应的标准单位，确保不同人员使用同一标准单位对相同对象的属性衡量得到相同的结果。

　　② 国际软件标杆组织（International Software Benchmerk Standard Group）为一家致力于在世界范围内推广基于软件功能点度量方法应用的非盈利组织，根据其2004年所收集的3024组基于功能点的软件项目数据，使用MarkII标准的项目比例接近0.1%（25个项目）；使用COSMIC标准的项目比例接近2.5%（73个项目）；使用NESMA标准的项目比例接近5%（143个项目）；采用Fisma标准的项目比例为0；其余的项目均采用IFPUG功能点标准。

??

??

??

??

IV

软件项目功能点度量方法与应用

II

软件项目功能点度量方法与应用