作者：曹济,温丽
出版社：清华大学出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
软件项目功能点度量方法与应用试读：
前言
提及软件功能点，有些读者可能会认为“不就是我们常说的功能模块、功能点么？这也值得费神费力地写本书来讨论”。其实软件功能点度量方法作为一种度量软件规模的标准，于20世纪90年代已经在世界范围内得到普遍的应用。如果考虑IFPUG功能点标准，自1979年就由IBM的Allan Albrecht提出，功能点度量方法发展到今天已经超过了30年。所以本书所描述的功能点度量方法是一套用于度量软件规模的标准，它采用规则约束的方式来衡量软件规模的大小。基于软件功能点度量方法，可以在关心软件规模的人员之间建立一种客观、透明的评价机制，使得软件规模的评价工作摆脱传统评价方法所具备的“黑盒子”特征。
软件行业作为一个新兴行业，几乎在促进每一个传统行业的升级换代。正是因为普遍地采用了软件技术，我们的生活和工作变得越来越方便、快捷。但软件行业带给人们方便的同时，也给人们带来了一系列的难题：如何评价开发和维护软件所需的代价？应该为软件项目设置多长的开发工期？如何评价软件系统的质量，而不是毫无预见地接受来自最终用户的抱怨和指责？诸如此类的问题总是成为客户和软件开发商所讨论的重点问题。因为软件本身所具备的“不透明”特点，所以在软件项目的前期可行性研究阶段、招标阶段很难确定软件项目对应的预算和相应的开发工期等关键项目管理指标。
随着软件行业成熟度的提高，国家对于软件项目预算监督的要求也进一步提高，软件开发项目逐渐也要遵循严格的招投标模式。对于软件项目的招投标，客户往往会采用“倒推法”确定软件项目工期。即以客户方软件项目立项时批准的工期为依据，要求软件开发商提供满足该工期约束的技术方案建议书。项目工期采用预先设定的方式，客户更多考虑自己的业务需求、市场特点、领导意愿等因素，而对实现软件项目的技术因素则考虑不足。对于软件项目的费用评价普遍采用“低价中标”原则。根据软件开发商的报价来比较开发商之间的价格，最终选择低价中标。软件开发商的报价方法目前仍然停留在“拍脑袋”、类比法等粗粒度的经验估算法层面。这些方法的弊端在于不具备客观性，不同的人员可能会给出完全不同的结论。对于那些没有足够技术背景的客户来说，这种粗粒度的估算方法更是缺乏说服力。
例如客户需要开发一个网上茶叶城应用系统，要求开发方给出报价和工期。开发方通常会采用如下的方式：
以上三种方法即为常用的报价方法，前两种方法的弊端在于过于粗略；第三种方法虽然更为详细，但每项功能所需的工作量仍然对客户不透明。例如功能三：茶叶订购所需的工作量为15人天，客户可能就会有疑问，5人天行不行？5人天不行，10人天应该没问题吧？所以即使采用工作分解结构法，仍然不容易在客户和开发方就软件开发的费用达成一致。
所以不论是软件项目的费用还是工期的确定，都存在较强的主观性。对于软件项目而言，很难从第三方的角度去评判一个软件项目的费用是多还是少？工期是长还是短？不妨将视线转移到其他行业，例如建筑业。如何确定一栋大楼的建设费用和建设工期？首先要知道大楼的建筑面积，然后再根据国家和地区所颁布的定额标准进行核算。通过这种方式可以得到该大楼的建设费用和建设工期。例如要在北京方庄南路建造一处商品住宅楼盘，假设每平方米的造价为14 000元（含土地购置费用），该楼盘的建筑面积为50 000平方米，那么就可以得到该楼盘的大概造价为14 000×50 000=7亿元。在这个例子中我们用平方米作为单位去衡量建筑面积，但我们用什么作为单位来衡量软件系统的大小呢？读者可能会给出一系列的例子：可以使用功能模块数量、代码行数量、用例数、需求数、甚至需求的页数等。但特别需要注意的是，与建筑行业所使用的平方米相比较，衡量软件系统规模的这些单位都不是标准单位，因而也就无法采用定额方式来计算软件项目的费用和工期。何谓标准单位？标准单位即用于衡量所关注对象的某一属性时采用的尺度。例如，使用“平方米”衡量面积；使用“米”衡量长度；使用“千克”衡量重量等。因为此处的“米”或[1]“千克”在实际操作中不存在二义性，所以就可以使用“米”或“千克”来描述我们所关心对象的长度或者重量。而功能模块、代码行、用例数、需求数在实际的操作过程中并不具备标准单位的属性，只能被认为是衡量软件系统规模的粗略尺度。如果衡量单位本身就存在较多变数，所得结果的说服力也就可想而知了。正是基于将软件规模衡量单位标准化的考虑，本书的主题为软件功能点度量方法及其在实际工作中的应用。
软件的大小可以通过交付给用户的功能点数来度量，就如一间房子的大小通过提供给用户的建筑面积或使用面积来度量一样。根据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种功能点标准的组织加起来的比例也不会超过[2]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月[1]由计量组织维护各种相应的标准单位，确保不同人员使用同一标准单位对相同对象的属性衡量得到相同的结果。[2]国际软件标杆组织（International Software Benchmerk Standard Group）为一家致力于在世界范围内推广基于软件功能点度量方法应用的非盈利组织，根据其2004年所收集的3024组基于功能点的软件项目数据，使用MarkII标准的项目比例接近0.1%（25个项目）；使用COSMIC标准的项目比例接近2.5%（73个项目）；使用NESMA标准的项目比例接近5%（143个项目）；采用Fisma标准的项目比例为0；其余的项目均采用IFPUG功能点标准。第1章 软件功能点度量方法概述
本章介绍软件项目开发与维护所面临的典型问题，指出解决这些问题的基本途径是软件项目的定量评价分析。在比较了各种软件定量评价方法的基础上建议采用功能点方法作为软件定量评价的基础方法。本章进一步介绍目前被ISO标准采纳的5种功能点标准，依次是MarkII功能点标准、COSMIC功能点标准、NESMA功能点标准、FISMA功能点标准以及IFPUG功能点标准。本章还对5种功能点标准的不同之处进行了比对分析并给出了建议。1.1 软件困境
软件在我们生活和工作中的重要性正与日俱增。试想，没有银行软件系统和证券软件平台的应用，庞大复杂的银行业务便不能有效地开展，证券业务也只能局限于现场交易，因而不能发挥其应有的金融职能；没有网络管理软件系统的应用，快捷的电话联系方式也是不可想象的；除了目前已经广泛应用的固定电话和移动电话业务之外，更有如雨后春笋般出现的各种数据服务，例如宽带上网、GPS定位导航等，而这些应用无一例外地依赖于各种软件系统。软件应用对于很多行业的发展变革甚至起决定的作用，例如基于网络的传媒信息更多地取代了传统的纸质媒体，人们的阅读习惯因而发生了有史以来最重要的变化。
由此可见，软件无论在我们的生活还是工作中已经变得不可或缺。软件以其快捷、高效、经济等诸多优势几乎渗透到各个行业中，正是软件的普及应用塑造了信息时代的主要特征。因为软件应用的互通互联，因特网时代之前的“信息孤岛”正日益消亡，伴随着世界范围内各种经济、科技和教育等方面的信息共享，“地球村”的预言正成为现实。具有讽刺意味的是，软件在促进信息共享、信息透明的同时，自身却存在典型的“灯下黑”现象。
与传统的建筑等行业相比较，软件系统的建设与开发充满了各种不确定性。用户业务需求不明确、工期和费用设置的盲目性、开发团队不稳定、人员的工作经验和技术水平参差不齐、“作坊式”开发模式等诸多因素使得软件开发往往达不到预期的目的。软件开发与建设对客户来说更多地呈现为“黑盒子”特征。实际开发出的软件系统往往差强人意，用户在使用中抱怨不断，不能真正满足客户的要求。具体表现为所提交的软件系统功能与用户期望的需求差异过大、工期严重拖延、费用超支明显、质量问题层出不穷等现象。导致出现以上问题的原因纷繁复杂，但究其主要原因，则是因为软件系统的建设与开发的过程中管理不善所致。大量的实践表明有效的软件项目管理是改善和提高软件系统建设与开发效率的主要途径。要对软件项目进行有效的管理，首先得了解软件项目的特点。与传统行业相比较，软件项目具备以下三个重要特点。（1）前期业务需求不清，导致项目执行过程中需求频繁变更。
对于大部分软件项目，开发团队在启动软件需求分析之前都无法获取明确的需求。例如对于一个电子政务项目而言，前期可能只会给出该项目的定位，例如“通过将现有手工业务转变为软件支撑的电子流工作方式，提升工作效率，并对现有的业务模式进行合理优化”。可是如何对这样笼统的项目要求进行细化，并将其转变为相应的软件需求规格，软件开发团队还面临着各种挑战。首先是获取单一部门内的业务流程，现有的业务流程可能本身就存在不合理或者冲突的情形，需要需求分析人员与业务人员进一步讨论才能确定。如果涉及到部门之间的业务流程，其困难程度还会进一步加大，因为不同部门的人员都倾向于站在自己的立场来考虑问题，所以部门之间的业务流程确定往往还需要领导的强力参与。伴随着组织业务流程的调整，通常意味着部门和人员的重新定位，有时甚至影响相关人员的切身利益，此时的需求分析将会面临更大的阻力。
除了来自业务部门本身的挑战外，业务人员与技术人员的沟通也存在明显的障碍，即客户与技术开发方对业务需求的理解不一致。客户方的业务人员通常认为自己对业务需求的表述清楚无误，而开发方却觉得业务人员语焉不详，并没有将业务的来龙去脉交待清楚。不少项目在各方对于需求的理解还未达成一致的情况下就开始项目，结果项目是边做边改，等到项目临近结束时，需求已“面目全非”，与双方前期确定的需求相差甚远。
试想，一栋大楼或一座大桥在还未确定功能或结构的前提下就开始动工，然后在施工的过程中再根据用户的要求不断变更，将会出现什么样的结果？结果很可怕，所以没人做这样的尝试。但软件项目不然，环顾我们身边的软件项目，有多少项目真正能够做到“谋定而后动”呢？正是软件需求的脆弱性和易变性导致了软件项目的失控。（2）项目目标失控，明显超出客户心理预期。
所有的软件项目在初期都会设置相应的管理目标，包括项目所要实现的功能、项目工期、项目预算以及项目的质量目标等。可是在项目开发的过程中却发现这些目标无异于“海市蜃楼”，可望而不可及。大部分软件项目或多或少地表现出下列特征：要么是“种瓜得豆”，要求的功能大幅缩水；要么是项目工期严重滞后，影响客户业务的正常运行；或者项目严重超支，软件开发商虽然投入了额外的人力物力，但客户并不领情；更有甚者，虽然软件系统勉强按时上线，但后续的质量问题却层出不穷，“摁下葫芦浮起瓢”，永远有解决不完的问题。既然上述问题是目前软件项目所面临的共性问题，那么单一地将其归属为软件开发商的责任似乎有失公允。
设想这样的场景：如果对一个小学班级进行数学测验，孩子们最后的平均成绩为30分（考试采用百分制）。30分的平均成绩说明什么呢？首先孩子们的数学知识学得不够好，怎么才考30分呢？其次，数学测验题目有问题，为孩子们设置了过高的目标要求（学生家长往往更倾向于这种结论）。对软件项目而言，也存在类似的现象。所以在抱怨软件开发商工作绩效的同时，客户似乎也应该进行自我反省，客户要求的目标合理吗？
我国现在大部分的软件项目均采用招投标的方式来选择供应商，再加上在国内的软件行业中普遍存在“买方市场”的特点，许多软件开发商都存在“先拿到合同再说”这样的心理，故而往往对于客户所提的各种要求都满口应承，即使认为客户设置的项目目标不合理，也[1]往往忍气吞声、委曲求全。也有一些软件开发组织与客户签署合同之前，对于客户单方面设定的目标会提出不同的建议，例如更为合理的工期、成本与质量目标等，但这些建议对于客户往往缺乏足够的说服力。因为大多数软件开发组织并没有一个明确的、量化的过程可以向客户表明自己所建议目标的客观性、合理性，代之以“根据我们的经验”、“参照我们以前的项目”等说法，因而缺乏说服力，最终只能接受客户方设置的项目目标。但软件项目最终的结果却让客户追悔莫及，油然而生“早知如今，何必当初”的感叹。所以如何为客户设定合理的项目目标至关重要。（3）软件项目的成功过度依赖个人，缺乏来自组织的过程保证。
成熟与不成熟的软件开发组织相比较，其最大差异在于两者的可预期性。不成熟的软件开发组织往往倾向于过度承诺，而实际开发过程中却经常面临捉襟见肘的困境：要么是工期严重滞后，要么是成本超支，工期若能勉强得到保证，通常即意味着质量风险。而高成熟度组织所做出的承诺通常可以得到真实的兑现。在不成熟的软件开发组织内，更多地采用“游击队”、“个人英雄主义”的开发模式，在项目中甚至没有采用相应的软件配置管理平台，更没有进行软件项目计划与跟踪、软件项目质量评价等相应的管理措施。这种“作坊式”的开发模式导致软件开发的最终结果主要取决于个人因素，而组织对软件项目的管理与控制则力不从心，只能寄希望于员工在工作中一直表现出认真、负责、任劳任怨的态度。如果出现项目经理或项目组成员离职等情形，对软件开发的影响通常是致命的，新加入的人员不得不从头再将前任的工作完成一遍。
软件开发是一项群体的智力活动，软件开发过程是否高效、开发团队工作是否工作在同一基础之上、个人的工作成果能否完全融合到项目中等因素对于成功的软件开发至关重要，而要保证软件团队工作的有效性，来自软件开发组织的过程管理则必不可少。适用于软件开发的典型过程管理模型包括ISO9000模型、CMMI模型和RUP模型等，而在这些模型中无一例外地强调了过程度量的重要性。正是通过过程度量，我们才能评价当前工作的好与坏、正常还是异常、是否需要采取纠正措施或补救措施等。“人贵有自知之明”被许多人奉为人生的圭臬，可是许多软件开发组织却缺乏“自知之明”，项目组的产出如何？组织的开发绩效如何？对开发过程中生成的需求或技术文档质量状况是否满意？对类似的问题许多组织往往会采用“还行”、“不错”、“我们有信心”等模棱两可的说法来搪塞，因为组织根本就没有数据。
基于以上分析，目前软件项目管理所面临的困境可以归结为三个“说不清”：需求说不清；目标说不清；过程说不清。要做什么不清楚，做到什么程度不清楚，中间过程也说不清，这样的项目做出的软件可想而知会是什么结果。说不清首先和软件本身的特点相关，从客观角度分析可能包含两方面的原因：首先，软件不同于其他的有形产品，很多时候难以去想象最终的产品究竟是什么样子；其次，软件的开发过程主要表现为人们的智力活动，表现为建立模型、编写文档和代码调试等可见性较低的活动形式。所以上述两类原因导致人们对软件不容易“说清楚”。
除了客观方面的原因外，可能也有来自人员本身的主观原因。现在各行各业都在倡导“定量化”的管理模式，对于软件行业也应该引入定量管理的理念，可为什么在国内的软件开发组织中真正采用定量管理模式的组织却少之又少呢？第一，可能是由于思维惯性。“我们一直都是这么跟着感觉走，也没出啥大问题嘛”，不愿意主动提升和优化现有的软件开发过程。第二，和我们的传统文化有关。如果采用定量管理的办法使得大家的工作都透明化，是否组织中的每个人都喜欢看到这样的结果？中国的传统文化强调中庸，强调“水至清则无鱼”，你把账算那么清楚，犯得着吗？所以我们看到在各个国家审计部门都不是一个受欢迎的部门，他们总是拿着数据报告要别人解释自己的行为或结果。在软件项目中采用定量评价的方式虽不至于产生类似经济领域的“审计风暴”，但迫使人们在事后要关注自己的行为，有时甚至还需要为自己的行为进行解释。在潜意识里，人们希望自己在工作中的束缚和来自外部的检查尽可能的少。因而在软件开发组织中引入定量管理评价机制通常是不受欢迎的，甚至会遭到抵制。
因为存在这样那样的原因，所以我们国家的软件开发现状在最近[2]5年、甚至最近10年并没有发生明显的变化。虽然我们的软件行业表现得朝气蓬勃，但我们的沉淀和积累仍然不足。如果我们对现状不满，那就必须做出改变。如何改变？在软件开发过程中引入定量管理评价方法则是必不可少的一个主要步骤，而定量评价方法的基础则是软件项目规模的评价。如果能够在软件项目管理过程中引入基于功能点度量方法的规模评估，则有助于我们做到“需求说清楚”、“目标说清楚”和“过程说清楚”。[1]作为某些人的处世哲学，这种态度无可厚非。但用于软件项目目标的设置则弊端丛生，因为不负责任的承诺常常会害人又害己。[2]甚至于软件开发组织中的人员平均年龄也是如此，10年前的软件开发组织人员平均年龄大概为二十六七岁，10年后的平均年龄依然如此。1.2 软件规模评价方法
为什么说软件规模评价是软件量化管理的基础？在实际的软件开发项目中我们好像更关注工期、成本和质量。软件规模、工期、成本以及质量之间存在什么样的关系以及如何对这些关系进行定量表述是软件项目量化管理的主要内容。在介绍这些依赖关系之前，有必要首先建立“和谐项目管理”理念。对一个软件项目而言，在项目中会设置4个最主要的目标，即项目范围、项目时间、项目成本以及项目质量。它们4者之间相互影响、相互依赖，如图1.1所示。
也许有些读者还记得若干年前我们国家的一句政治口号：“多快好省地建设社会主义”，这种提法的出发点是好的，但忽视了经济建设的内在规律，最终导致了“大跃进”的局面，对中国经济的健康发展造成很大的伤害。即使在我们大力倡导科学发展观的今天，仍然有不少客户和领导希望软件项目完成的功能越多越好、工期越快越好、成本越低越好、质量越高越好，岂不是“多快好省”模式在软件行业的完全翻版？我们应该从错误的做法中汲取经验和教训，而不是重蹈覆辙。我们现在的社会和经济发展强调“和谐”理念，对于软件项目管理也要遵循“和谐”的管理模式。概言之，即要完成的软件功能有多少，就应该设置多长的工期，就应该设定多少预算，就应该设置相应的质量目标，而不是一味求快贪多，置客观事务的内在联系于不顾。图1.1 软件项目管理三角形
正如其他传统行业的定量评价机制一样，项目的工期、成本和质[1]量目标的设置主要取决于项目所要完成的工作内容。例如修建铁路的成本与工期主要取决于道路的长度；办公大楼的建设费用与工期则主要取决于建筑面积。所以要在软件项目管理过程中引入量化评价机制，对于软件规模本身的评价则是首要任务。只有确定了软件规模，才能得到其他的项目管理目标；只有预先设定了项目目标，定量管理才有执行的依据。根据软件行业的实践，目前评价软件规模的方法可以区分为两种评价方法：非标准评价方法和标准评价法。非标准评价方法具有操作简单、容易实施等特点，但不容易在项目干系人之间达成一致，往往会引起较多的分歧；标准评价法则较好地克服了非标准评价方法的不足，但因为其操作相对繁琐，很多情形下甚至需要外部咨询机构的辅导，因而在实际应用中也受到一定程度的限制。1.2.1 非标准评价方法
与软件规模标准评价方法相比，非标准评价方法更多采用约定俗成的方式，评价方法有较强的主观性，因而难以保证评估结果的一致性。但因为这些评价方式简便易行，因而在我国软件行业中仍然占据主导地位。典型的非标准评价方法包括软件源代码行评价法、对象点评价法、需求数量评价法、用例数评价法以及文档页码评价法等。
1.软件源代码行评价法
在所有的软件项目规模评价方法中，软件源代码行方法在我国的软件行业中仍然占据统治地位。顾名思义，软件源代码行法就是以完成的软件源代码的数量表示软件项目所完成的功能的多少。源代码行方法最大的特点即是简单，直接数出代码行的数量即可。不同的项目源代码行数量不同，小项目可能只有几千行代码，而那些规模巨大的项目动辄会超过百万行。但应用代码行作为评价软件项目规模的方法，其缺点也是显而易见的。
首先，代码行从技术而非业务角度度量软件规模。对于没有足够技术背景的客户或其他项目外部干系人来说，代码行不具备说服力，他们总是倾向猜测技术人员使用了过多的代码来实现软件功能。其次，代码行度量不及时。度量软件项目规模的主要目的往往要在前期确定项目的工期、费用等关键指标，但在项目前期只有笼统的业务需求，只有当项目完成后才能得到真正的代码行数量。项目前期或项目执行过程中估算出的代码行数量没有足够的说服力，不同人员估算得到的代码行数量也许会有50%的偏差。第三，缺乏代码行度量标准。一行代码是多长？注释语句算不算？跨行的语句算一行还是多行？在行业中并没有一致的规定。即使IEEE和SEI尝试过颁布了一些代码行度量标准，但并没有得到广泛的接受。最后，不同语言编写的代码行可比较性差。如何比较汇编语言、C语言或者Java语言编写的语句呢？如果使用多语言开发的程序，又该如何度量代码行的数量呢？
虽然软件代码行方法目前在我国的软件行业中仍然是一种普遍的规模估算方法，但因为其一致性不容易得到保证，越来越多的软件开发组织倾向于采用标准评价方法（功能点标准）来衡量软件项目的规模。
2.对象点评价法
对象点（Object Point）评价法属于Barry Bohem所提出的COCOMOII模型的组成部分，主要适用于基于组件或可视化开发环境的项目，同时也适用于原型项目。对象点评价法基于加权的概念将软件项目的工作内容转换为相应的对象点数量，它包含最基本的三个对[2]象点类型：屏幕、报表和组件。屏幕对应的复杂度加权表如表1.1所示。
如果一个屏幕包含了5个视图，且访问了5个数据表，其中两个是Server端的数据表，而另外三个是客户端的数据表，则该屏幕对应的复杂度为平均。
报表对应的复杂度加权表如表1.2所示。
如果一个报表包含三个节，访问一个服务器端的数据表，对应的复杂度为简单。
对象点评价法中并没有对组件设置相应的复杂度加权表，所有的组件默认其复杂度为平均。
确定了屏幕、报表以及组件的复杂度，然后再根据对象点权重表将其转换为统一的对象点，如表1.3所示。
如果一个软件开发项目要完成10个平均复杂度的屏幕、8个平均程度和3个困难程度的报表以及2个三代语言组件，则该项目的对象点规模即为（10×2+8×5+3×8+2×10）=104。基于对象点的生产率对应表（如表1.4所示），即可推算完成该项目所需要的工作量。假定项目组的生产率为平均水平，则对应的工作量为8人月（103/13=8）。
对象点评价法的评价方法一致，但其对对象点类型的划分并无详细的规定，所以在操作中容易引起歧义，例如不同人员对视图的理解可能就存在歧义。
3.其他非标准评价法
除了上面的两种方法外，实际工作中还会使用到需求数量评价法、用例数评价法以及文档页码评价法等方法。需求数量以项目需要完成的需求数量作为规模衡量的方法，但对于需求的粒度却从来就没有统一的规定，包括经常所提的模块数量、功能模块数量也属于需求数量衡量的范畴，它们共同的缺陷都在于缺乏统一的标准，甚至不如代码行方法的一致性。
用例（Use Case）是基于UML方法的一种定义软件需求的方式。用例是软件工程或系统工程中对系统如何反映外界请求的描述，每个用例提供了一个或多个场景，该场景说明了系统如何同最终用户或其他系统交互，从而获得一个明确的业务目标。通过用例描述的方式可以将软件系统所实现的功能进行抽象和总结，软件系统要实现的功能则表现为一组用例，所以可通过用例数量来描述软件项目的规模。相对笼统的“需求”、“功能”等说法，用例具有较好的一致性。UML语言对用例规范建立了用例模板，例如典型的用例应该包含如下内容：用例名、迭代、综述、前置条件、触发器、基本事件流、备选路径、后置条件、业务规则、说明、作者和日期等。如果能采用用例作为软件规模的衡量手段也不失为一种可取的方式。但用例也存在粒度不一致的缺点，不同的用例可能相差很大。对一个银行应用软件来说，描述用户管理的用例和住房贷款的用例可能会有很大的差别，从而缺乏横向比对的意义。除此之外，用例对于客户往往缺乏说服力，尽管UML的倡导者声称用例是客户和技术人员沟通需求的最佳方式，但客户对用例描述的需求多数还是采用敬而远之的态度。
采用文档页码评价法的优点和不足也是显而易见的，页码最容易统计，但人们的书写习惯、逻辑表达能力、图形与文字的比例、甚至纸张的大小等因素都使得页码评价法很难成为合适的软件规模评价方法。
非标准评价法以其方便理解、易于操作的特点在实际工作中得到广泛应用，尽管存在不同程度的不一致缺陷，但聊胜于无。无论如何，非标准评价法对于软件规模给出了一个明确的、用数字表示的数值，从而使得在此基础上讨论项目的工期、费用和质量目标等量化管理目标成为可能。如果要尽可能减少项目干系人对于软件规模评价结果理解的歧义，则需要采用软件规模的标准评价方法——功能点方法。[1]软件项目的工期、成本和质量目标主要取决于项目的工作内容，但同时还要受其他很多因素的影响，例如需求是否清晰、软件技术是否成熟、开发人员的工作经验和工作能力、开发团队的人员规模等许多因素。对这一话题感兴趣的读者可以通过网络途径参阅笔者的博士论文——《IT行业经济与管理指标测度与预报模型的实证研究》。[2]组件的概念在第三代开发语言面世后才出现，其实组件就是对象。C++Builder中叫组件，Delphi中叫部件，而在Visual BASIC中叫控件。与传统的代码编写通过定义函数实现功能不同，组件预定义了自己的属性和方法，使用者只需对这些方法进行相应的定制即可实现期望的功能。1.2.2 标准评价方法
上述各种非标准评价方法虽然在实际工作中也有着普遍的应用，但更多地局限于软件开发团队内部。如果要在业务部门与开发部门、甲方与乙方等外部组织约定软件开发的工期或费用等关键项目目标，则首先需要对软件项目规模进行标准、一致的评价与估算。目前的软件规模标准评价方法都同属一类方法，即功能点方法。用功能点衡量软件项目规模类似于用平方米衡量房间的面积，或者用千克衡量体重，所以如果使用功能点方法衡量软件项目规模，则不同的人员对同一项目的软件功能可以得到一致的结果，从而克服软件规模非标准评价方法的不足。从美国人Allan J.Albrecht在20世纪70年代末提出功能点方法以来，功能点在软件行业的应用与实践已超过30年，在Albrecht的功能点模型基础之上，经过进一步应用与发展，功能点标准演进为一个总标准（ISO14143）与5个子标准（MarkII标准、COSMIC标准、NESMA标准、FISMA标准以及IFPUG标准）。1.3 功能点标准
作为评价软件规模的标准方法，功能点度量方法（Function Point Analysis）已经被纳入ISO14143标准系列。就功能点方法的发展历程分析，目前被纳入ISO14143的5种实际操作方法都源自于Allan J.Albrecht所提出的功能点分析思想。当然，各种标准之间又存在一定的差异和共性。为了保证这些功能点操作方法的一致性和客观性，ISO组织委托ISO/IEC JTC 1（信息技术）的SC 7（软件与系统工程）委员会制定了ISO14143标准。
ISO14143标准本身又包含了6个子标准，各子标准的作用如下：
ISO14143-1：概念定义（Definition of Concepts），对标准中所采用的术语给出解释。
ISO14143-2：一致性评价（Conformity Evaluation），给出如何检验功能点操作标准是否符合ISO14143标准的评价过程。
ISO14143-3：验证（Verification），在需要时对功能点操作标准进行验证。
ISO14143-4：参考模型（Reference Model），给出功能度量方法模型以及需要度量的内容。
ISO14143-5：应用领域确定（Determination of Functional Domains），确定功能点操作标准适用的应用领域。
ISO14143-6：使用指南（Guideline for Use），对功能点标准的应用提出建议和指导。
ISO14143给出了度量功能模型的标准，但在度量具体的软件功能时，使用者还应该考虑所度量的软件应用领域，从而选取合适的功能点度量方法。所以从这个角度分析，ISO14143是关于功能点度量标准的标准。在实际的软件规模度量实践中，目前符合ISO14143标准的功能点操作方法有5种，依次是MarkII标准、COSMIC标准、NESMA标准、FISMA标准以及IFPUG标准。下面各节对这些操作标准的主要特点和操作方法进行简要说明。1.4 MarkII功能点标准
1991年，英国人Charles Symons在自己的《Software Sizing and Estimating：MkII Function Point Analysis》一书中介绍了MarkII功能点的操作方法。Symnos先生在为毕马威咨询公司工作期间提出了MarkII功能点操作方法，在该操作方法的基础之上形成了MarkII功能点标准，该标准提出后被英国政府所采纳，目前该标准由英国软件行[1]业协会维护。
MarkII功能点标准目前主要在英国应用，此外在印度等国家也有[2]一定的应用。正如Symons先生自己所言，该功能点标准受到Albreht先生的功能点操作方法启发，不过采用了不同的加权方式来定义功能点标准。除了功能点的操作方法外，该标准还包含了功能点的应用建议，例如如何基于MarkII功能点标准来计算项目的生产率和工作量等内容。1.4.1 MarkII功能规模度量规则
为了保证MarkII功能点标准的一致性，该标准采用了基于规则的度量方式。MarkII的度量规则共有6条，分述如下：
规则1 边界（1）MarkII功能点标准用于度量应用系统的用户所要求功能的规模。（2）由边界所包含的应用或部分应用必须是逻辑一致的功能，包含一个或多个完整的事务逻辑类型。
规则2 功能规模与逻辑事务（1）应用系统的功能规模是逻辑事务的规模之和，每个逻辑事务的输入和输出部分穿越应用边界。（2）逻辑事务是最低级别的完整过程，它包含三个组成部分：进入边界的输入、边界内和存储数据相关的处理以及离开边界的输出。（3）逻辑事务由用户关心的独特的事件触发，当事务完成时，[3]应用系统处于逻辑完整的状态。逻辑事务也可以由用户从应用系统获取信息的需求触发，此时应用系统为未修改状态。（4）在度量应用的功能规模时，一个逻辑事务即使在应用系统出现多次也只能度量一次。（5）对修改的应用系统规模度量时，将增加的、修改的和删除的逻辑事务规模相加。这意味着当逻辑事务的输入、处理和输出三部分出现增加、修改和删除时，将其视为事务的修改情形。
规则3 逻辑事务的处理类型（1）逻辑事务的处理类型根据对存储数据的操作确定，例如包含新增、删除、修改和查询。（2）处理部分的规模取决于逻辑事务所引用的主要实体类型以及系统实体类型。（3）对所有非主要实体类型的访问均视为对系统实体类型的访问。[4]（4）在一个应用边界内只能存在一个系统实体，逻辑事务类型的处理过程最多只能对其引用一次。
规则4 逻辑事务的输入和输出（1）逻辑事务输入与输出规模根据穿越应用系统边界的数据元素类型确定。（2）数据元素类型是逻辑事务类型中特定的处理信息，它不可分割，是穿越应用系统边界的输入或输出数据流的一部分。
规则5 逻辑事务规模（1）逻辑事务规模为输入、处理和输出三个组成部分的加权和。（2）该标准设定的加权方式为：输入加权为0.58（每个输入的数据元素类型）、处理加权为1.66（每个引用的实体类型）、输出加权为0.26（每个输出的数据元素类型）。
规则6 MarkII功能计数结果
根据该功能点计数标准所获得的结果应包含对应的标准版本号，例如“600 MarkII功能点（V1.3）”或“MarkII功能点=600（V1.3）”。[1]英国软件行业协会网站为http：//www.uksma.co.uk，读者可以访问该网站并下载MarkII功能点标准。[2]Symons先生不但作为MarkII功能点标准的创始人，最近他又作为COSMIC功能点标准的度量委员会成员，积极倡导COSMIC功能点标准的推广与应用。笔者曾在2007年与Symons先生在罗马有一面之缘，Symons先生是一位睿智和蔼的长者，对于功能点标准在软件行业的应用多有真知灼见。[3]Self-consistent state逻辑完整的状态，说明事务功能已经完成，不存在只有输入或者只有输出的状态。[4]MarkII方法中对于数据类型的定义，其含义为应用内部所有非主要实体类型数据的集合，即代码数据的集合。应用内无论存在多少个代码数据文件，都将其视为一个系统实体。1.4.2 MarkII功能规模度量步骤
MarkII功能点标准不但定义了详细的功能点技术规则，还规定了在度量软件规模中应遵循的完整步骤，根据这些步骤要求可以得到应用系统的MarkII功能规模。MarkII功能规模度量包含11个步骤，步骤1～6规定了MarkII的计数过程；步骤7和步骤8用于确定开发或维护应用系统所需的工作量、工期等关键的项目管理指标；步骤9～11则进一步考虑了技术复杂系数。MarkII功能点度量步骤如图1.2所示。图1.2 MarkII功能点度量步骤
功能点度量应该基于应用系统的用户角度来进行，对于那些系统所提供的，但用户却不需要的功能在功能点计数时不予考虑。功能点度量本身也需要花费一定的投入，根据MarkII功能点标准的特点，功能点度量所花费的工作量为项目总工作量的0.2%～0.4%。下面简述MarkII功能点度量的各个步骤。
步骤1：确定计数目的与计数类型。
首先应该识别计数的客户是谁。例如，是为了衡量开发团队的工作产出，还是希望了解特定用户所拥有的功能数量？另外考虑不同的因素有助于确定计数目的和计数类型，例如项目是否包含开发、修改、维护或支持各个阶段，项目的起始与截止时间等。
步骤2：确定计数边界。
该步骤与步骤1密切相关。确定边界将有助于识别计数过程中应包含的逻辑事务以及识别相应的接口。
步骤3：识别逻辑事务。
逻辑事务是应用系统所支持的最底层过程，其识别方式参见规则2。
步骤4：实体类型识别与分类。
识别实体类型时最好能够得到相应的实体关系数据模型。但因为只需要主要的实体类型（Primary Entity Types），所以并不需要完全符合第三范式的数据库模型。
步骤5：输入、过程与输出计数。
对每个逻辑事务计数时，度量输入数据元素类型（Ni）的数量、引用的数据实体类型的数量（Ne）以及输出的数据元素类型的数量（No）。
步骤6：计算功能规模。
功能规模（功能点指数，Function Point Index）是所有事务功能的加权和，其计算公式如下：
其中的加权系数取值依次为W=0.58；W=1.66；W=0.26。ieo
步骤7：确定工作量。
根据项目的特点确定项目的总工作量和开发工期，参见MarkII功能点标准第7章。
步骤8：计算生产率与其他绩效系数。
生产率的计算公式为：生产率=FPI/工作量；交付率的计算公式可以表示为：交付率=FPI/工期。参见MarkII功能点标准第8章。
步骤9：影响度评分。
使用技术复杂度特征来评估影响程度，参见MarkII功能点标准附录1。
步骤10：计算技术复杂度调整系数。
计算技术复杂度调整系数，参见MarkII功能点标准附录1。
步骤11：计算调整后的功能规模。
根据步骤10计算得到的技术复杂度调整系数计算调整后的功能规模，该功能规模也可替代步骤6所计算的FPI，在此基础上，再根据步骤7和步骤8进行计算，估算项目的工作量、工期和其他绩效系数。1.4.3 MarkII功能规模度量应用
MarkII功能点标准可广泛地应用于以下方面：（1）撰写应用系统的需求规格或功能规格。（2）应用于为客户定制的应用系统（例如ERP、CRM系统的实施）、批处理应用或实时应用系统。（3）度量项目级别或组织级别的项目绩效（例如生产率、交付率和缺陷率等）。（4）比较组织内外部的IT工作绩效。（5）比较应用系统的质量和可靠性。（6）比较不同平台上归一化之后的开发成本、维护成本或支持成本。（7）估算项目所需的资源、工期和成本。（8）分析新项目的成本和业务方面的风险。（9）辅助项目前期的需求识别。[1]（10）控制项目的“需求潜变”。（11）为人员分派工作提供依据。（12）确定应用资产规模。（13）为那些缺乏功能定义文档的遗留系统提供相应的功能说明。（14）确定应用系统的重置费用。[1]需求潜变（Scope Creep）描述因为项目前期需求定义不明确，在项目后期需求不断蔓延和扩展所对应的情形。1.5 COSMIC功能点标准
COSMIC（COmmon Software Measurement International Consortium，通用软件度量国际联盟）功能点的前身来源于1997年所提出的FFP（Full Function Point，全面功能点）功能点标准，后来FFP组织又与COSMIC组织共同合作于1999年提出了COSMIC功能点标准，该标准历经修订，目前的最新版本为该组织于2009年所提出的3.0.1版本，该标准也于2003年被ISO组织接纳成为国际标准。COSMIC组织提出该功能点标准的初衷在于克服IFPUG所维护的功能点标准的不足，COSMIC功能点标准对于实时类软件、嵌入式软件有[1]更好的适用性，同时对典型的MIS系统也具有良好的适用性。1.5.1 COSMIC功能规模度量过程
与MarkII功能点标准相似，COSMIC将度量软件功能点的过程划分为4个阶段，依次是度量规划阶段、映射阶段、度量阶段和报告阶段，如图1.3所示。图1.3 COSMIC功能点度量的4个阶段
相对于其他功能点标准，COSMIC功能点标准声称可以更好地度量实时项目和嵌入式项目的软件功能规模，因为这些类型的应用通常和用户的交互较少，更多的功能通过内部过程实现，所以在功能点计[2]数时应该考虑这些内部操作的功能，因而就引入了一个重要的概念——“层（Layer）”。图1.4给出典型的MIS类项目和嵌入式项目的物理分层模型。图1.4 MIS类项目的物理分层模型
图1.4的MIS类项目可分为软件层和硬件层，其中软件层又包含应用层、中间件层、数据库管理层和操作系统层；而硬件则是单独的一层。图1.5 嵌入式项目的物理分层模型
嵌入式项目也分为软件层和硬件层，见图1.5。其中软件分为嵌入式应用层和操作系统层，硬件则为单独的一层。
根据MarkII功能点标准或基于IFPUG的功能点标准，用户与应用系统通过边界进行交互。而根据COSMIC功能点标准，用户不但通过边界与应用系统交互，应用系统内的各个层之间也进行数据的交互，可以将一个层视为另一个层的用户，如图1.6所示。图1.6 用户与层以及层与层之间的数据交互示意图[1]COSMIC组织所声称的IFPUG功能点标准的不足并没有得到业界的认同，IFPUG功能点在实时类软件和嵌入式软件的应用并不存在障碍。对于实时类软件和嵌入式软件的工作量评判和工期判定不应只考虑项目的功能规模，还应结合项目的其他特征，例如行业类型、技术类型和开发平台等因素。许多人潜意识地认为既然定义了功能点，那么不同行业、不同技术路线的软件项目都应该具备相同的生产率、交付率和缺陷率等，这种观点就如要求每平方米的房子造价都相同那样经不住推敲。[2]在COSMIC模型中引入Layer的概念固然可以反映内部过程的复杂性，但Layer的划分更倾向于从技术实现的角度进行划分，所以“功能点标准对用户透明”这一基本特征可能就会受到负面的影响。1.5.2 COSMIC功能规模度量规则
确定了应用系统的边界以及应用系统的物理分层后，COSMIC将所有的软件功能区分为4种类型，即进入（Entry）、离开（Exit）、读（Read）和写（Write）4种功能类型。对于4种功能类型的识别，COSMIC也基于规则约束。下面简述对各个功能的识别规则。
进入功能描述从功能用户穿过边界转移一个数据组到功能过程的功能。识别进入功能应遵循以下6条识别规则：（1）一个进入功能从功能用户穿过边界转移一个关注对象的单个数据组到应用的功能过程。如果一个功能过程的输入由一个以上的数据组组成，那么要对输入中的每一个数据组识别为一个进入功能。（2）进入功能不会穿过边界输出数据或读写数据。（3）一个触发进入功能的数据组可能只包含一个数据属性，此属性简单通知软件“一个事件已经发生”。更常见地，触发进入的数据组可能有几个数据属性。（4）作为触发事件的时钟处于被度量软件之外。触发事件的发生是由硬件周期性触发还是由被度量软件边界外的其他软件触发没有区别。（5）除非需要特定的功能过程，否则从系统时钟获取时间不会引起一个进入功能。（6）如果一个进入功能转移的数据组由n个数据属性组成，而另一个进入功能转移的数据组由描述同一关注对象的此n个数据属性的子集组成，那么应该只识别出一个进入功能，其数据组包括n个数据属性。
离开功能描述一个从功能过程穿过边界转移一个数据组到功能用户的数据移动。离开功能与进入功能移动数据的方向正好相反。识别离开功能应遵循以下4条规则：（1）一个离开功能从功能过程穿过边界转移一个关注对象的单个数据组到功能用户。如果一个功能过程的输出由一个以上的数据组组成，那么要对输出中的每一个数据组识别一个离开功能。（2）离开功能不会穿过边界输入数据或读、写数据。（3）软件产生或输出的不含用户数据的所有消息（如出错信息）被认为是一个关注对象（错误指示）的一个属性的值。因此含有此功能的每个功能过程中的所有此类消息的输出识别为一个离开功能。（4）如果一个离开功能转移的数据组由n个数据属性组成，而另一个离开功能转移的数据组由描述同一关注对象的此n个数据属性的子集组成，那么应该只识别出一个离开功能，其数据组包括n个数据属性。
读功能描述从固定存储转移一个数据组到功能过程的数据移动。判断是否为读功能遵循以下3条规则：（1）一个读功能从固定存储转移描述一个关注对象的单个数据组到功能过程。如果一个功能过程需要从固定存储中提取一个以上的数据组，那么要对提取的每一个数据组都识别为一个读功能。（2）读功能不会穿过边界接收或输出数据，也不会写数据。（3）在一个功能过程中，如果常量或变量的数据移动或处理只能由程序员进行，或者是计算的中间结果，或者功能过程存储的数据是软件实现的需要，而不是功能用户需求，则不能算做读数据移动。
写功能描述从功能过程转移一个数据组到固定存储的数据移动，写功能的操作方向与读功能的数据操作方向相反。写功能的识别应遵循以下3条规则：（1）一个写功能从功能过程转移描述一个关注对象的单个数据组到固定存储。如果一个功能过程需要转移一个以上的数据组到固定存储，那么要对转移到固定存储的每一个数据组识别一个写。（2）写功能不会穿过边界接收或输出数据，也不会读数据。（3）从固定存储中删除一个数据组的需求算做一个单独的写数据移动。1.5.3 COSMIC功能规模计算
根据COSMIC规则识别了描述数据移动的4种功能之后，将4种功能的数量相加，即得到软件应用相应的COSMIC功能规模，如公式1.2所述。
根据COSMIC功能点标准，用户还可以在使用该标准的同时对其规则进行适当的扩充，经扩充后的功能规模可表述为如下形式。
其中，x表示CFP的数量；CFP表示为一个COSMIC标准功能点；v.y表示COSMIC标准的版本；z表示扩充的FP数量；LocalFP表示扩充或本地化的功能点。1.6 NESMA功能点标准
前文已经述及5种功能点操作标准有较强的相似性，其他4种标准均有意识地借鉴和使用了IFPUG的功能点标准。但其中NESMA标准对IFPUG功能点的借鉴尤为彻底，例如功能点标准的度量过程与术语完全一致。说的夸张一些，就是将英文版本的IFPUG功能点标准翻译为荷兰语标准而已，例如IFPUG的CPM4.2英文标准与NESMA的CPM2.2荷兰语标准几乎完全相同。NESMA为荷兰软件度量协会的简称（NEtherland Software Measurement Association），NESMA功能点标准主要在荷兰本国采用，在荷兰之外的国家几乎没有用户。功能点标准在荷兰的应用还是较为普遍的，笔者曾于2005年秋季前往荷兰参加功能点应用方面的学术交流活动，参与会议的代表大概有七八十人之多（其中国际代表约为20人），可见功能点应用在该国的普及状况。要知道荷兰的总人口也就1600万左右，比北京市现在的常住人口数量还差400万呢。当然，NESMA功能点标准与IFPUG并不完全相同，它们之间还存在些许差异，具体表现在外部查询与外部输出的识别差异、外部查询的复杂度确定、隐含查询处理和代码表处理等方面。
1.外部查询（EQ）与外部输出（EO）
根据IFPUG的功能点标准，EQ与EO的主要目的都是“向应用边界外的用户呈现信息”，不同之处在于EQ不能包含任何额外的处理逻辑（包括计算、生成衍生数据、更新内部逻辑文件和更改系统行为），否则即是EO。对于NESMA功能点标准而言，对于那些包含特定的选择功能的EQ视为EO（例如包含“显示所有客户”选项的EQ在IFPUG功能点标准中仍被视为EQ，而在NESMA标准中却当作EO）。尽管如此，这种差异并不会引起功能点度量结果方面的明显不同。
2.EQ的复杂度判定
根据NESMA标准，EQ复杂度的判定要根据两方面的复杂度比较结果而定，即根据外部输入（EI）的规则判定EQ输入端的复杂度，然后再根据EO的规则判定EQ输出端的复杂度，两者相比较后取复杂度较高的值作为EQ最终的复杂度。IFPUG的EQ判断规则与EI和EO的判断规则相似，根据EQ的数据元素类型和文件引用类型确定其复杂度。因为EI、EO、EQ本身的复杂度非常接近，所以EQ即使采用不同的判定规则，对最终的功能点度量结果影响也是微乎其微。
3.隐含查询判定
隐含查询是指当需要修改或删除数据时，首先需要展示数据，该功能即称为隐含查询。根据NESMA标准，对该情形并不会做特别的考虑。而在IFPUG功能点标准中规定当该隐含查询功能已经在其他地方出现过，判断修改功能或删除功能时不考虑该隐含查询功能所对应的数据元素类型和文件引用类型，否则需要考虑隐含查询对应的功能点数量。对于隐含查询的不同判定方式也不会引起两种标准度量结果的明显不同。
4.代码表处理
通常所说的实体概念由主要数据（业务对象）和次要数据（支持数据）组成。对于描述业务对象的主要数据，NESMA功能点标准和IFPUG功能点标准都遵循IFPUG功能点标准所设定的规则。两种标准对于次要数据的处理则有差异，NESMA将次要数据视为数据功能，并识别出相应的事务功能。例如，包含商品代码-商品描述字段的表即为典型的代码表。
IFPUG则认为次要数据的代码表并不是基于业务角度考虑，完全属于技术实现范畴的内容，因而进行功能点度量时既不考虑对应的数据功能，也不考虑与代码数据关联的事务功能。如果NESMA功能点操作标准和IFPUG操作标准在前面三种情形中的差异可以忽略的话，两者在代码表方面的差异可能会较为明显。例如在NESMA功能点操[1]作标准中一个代码表的数据功能可能为7个功能点，对应的事务功能可能只包含创建和查询两个事务功能，因而对应的功能点数均为3[2]个功能点，所以是否将一个次要数据代码表作为功能点度量范畴的内容，可能意味着13个功能点的差异。
尽管NESMA功能点标准与IFPUG功能点标准之间存在一定的差异，但与其他的功能点标准相比较（MarkII功能点标准、COSMIC功能点标准和FISMA功能点标准），NESMA功能点标准仍然与IFPUG功能点标准保持了最好的一致性。[1]次要数据代码一般只有两个数据元素类型，因而复杂度为简单，根据功能点复杂度转换表，该数据功能为简单时对应7个功能点。[2]因次要数据代码表一般只包含两个数据元素类型，所以对应的事务功能的复杂度也为简单，根据功能点复杂度转换表，EI、EQ为简单时，其对应的功能规模为3个功能点。1.7 FISMA功能点标准
与前面的三种功能点标准相比较，FISMA功能点标准虽然也借鉴了IFPUG功能点标准的设计思想，但其与IFPUG功能点标准所存在的差异最为明显。FISMA（FIland Software Measurement Association，芬兰软件度量行业协会）组织于1997年就提出了FISMA1.1功能点标准的前身——Experience 2.0 Function Point Analysis（FPA），目前该标准的应用主要集中于芬兰本国的软件开发组织。与其他的功能点标准相比较，FISMA功能点标准突出了“服务”概念，不再强调“功能”概念。另外，FISMA将软件的典型功能区分为28种服务，从而使得服务类型的划分更为细致，但同时也增加了操作方面的不便。
FISMA首先将软件应用的功能区分为以下7种基础功能模块（Base Function Components）：交互式最终用户导航与查询服务（Interacitive end-user navigiation and query services），简称q；交互式最终用户输入服务（Interacitive end-user input services），简称i；非交互式最终用户输出服务（Non-interacitive end-user output services），简称o；为其他应用提供的接口服务（Interface services to other application），简称t；来自其他应用提供的接口服务（Interface services from other application），简称f；数据存储服务（Data storage services），简称d；算法与操作服务（Algorithmic and manipulation services），简称a。FISMA功能点标准在划分了7种BFC基础模块后，对每一种BFC基础模块又进一步划分为不同的BFC类型。7种BFC基础模块对应了28种BFC类型，如图1.7所示。图1.7 FISMA的功能服务结构图
对于7种BFC类型的功能规模度量采用如下的计算方法。
交互式最终用户导航与查询服务采用如下计算公式：
其中，Sq为查询功能的规模；n表示数据元素的数量；rr代表查询功能所访问的实体数量；dq为FISMA功能点标准所设置的系数，为7.0；cq为FISMA功能点标准所设置的系数，为2.0，aq为FISMA功能点标准所设置的常数，为0.2Ffp（Fisma Function Point）。
交互式最终用户输入服务采用如下计算公式：
其中，Si为输入功能的规模；m为输入功能对应的系数，取决于BFC所具备的功能类别，包括创建、更新和删除，取值为1、2、3，例如只有创建功能，取值为1，三种功能全具备，则取值为3；n代表数据元素的数量；rw代表输入功能所写的实体数量；rr代表输入功能只读的实体数量；ai为FISMA功能点标准所设置的常数，为0.2Ffp；di为FISMA功能点标准所设置的系数，为5.0；ci为FISMA功能点标准所设置的系数，为1.5；bi为FISMA功能点标准所设置的系数，为2.0。
非交互式最终用户输出服务采用如下计算公式：
其中，So为输出功能的规模；n表示数据元素的数量；rr代表输出功能所访问的实体数量；ao为FISMA功能点标准所设置的常数，为1.0；do为FISMA功能点标准所设置的系数，为5.0；co为FISMA功能点标准所设置的系数，为2.0。
为其他应用提供的接口服务采用如下计算公式：
其中，St为输出接口功能的规模；n表示数据元素的数量；rr代表访问的实体数量；at为FISMA功能点标准所设置的常数，为0.5；dt为FISMA功能点标准所设置的系数，为7.0；ct为FISMA功能点标准所设置的系数，为2.0。
来自其他应用提供的接口服务采用如下计算公式：
其中，Sf为输入接口功能的规模；n表示数据元素的数量；rw代表所写的实体数量；rr代表所访问的实体数量；af为FISMA功能点标准所设置的常数，为0.2；df为FISMA功能点标准所设置的系数，为5.0；cf为FISMA功能点标准所设置的系数，为1.5；bf为FISMA功能点标准所设置的系数，为2.0。
数据存储服务采用如下计算公式：
其中，Sd为实体（数据文件）的规模；n表示数据元素的数量；ad为FISMA功能点标准所设置的常数，为1.5；dd为FISMA功能点标准所设置的系数，为4.0。
算法与操作服务采用如下计算公式：
其中，Sa为算法对应的规模；n表示数据元素（变量或操作数）的数量；rc表示操作数的数量；aa为FISMA功能点标准所设置的常数，为0.1；da为FISMA功能点标准所设置的系数，为5.0；ca为FISMA功能点标准所设置的系数，为3.0。
与其他的功能点标准相似，FISMA功能点度量标准也规定了度量软件功能点详细步骤，共包括8个步骤。
步骤1：收集信息。
收集被度量软件的相关文档和开发产品，例如用户功能需求、需求用例、用户手册、实体关系图、数据流图和页面流图等。
步骤2：确定度量范围。
度量范围应该根据度量目的来确定，通常包含需要开发的项目、需要升级的项目或者需要被度量的应用。
步骤3：确定用户功能需求。
根据FISMA功能点度量标准确定仅包含描述软件所要完成的任务和软件所要提供的服务。
步骤4：根据用户功能需求识别BFC类型。
BFC功能类型可区分为两大类：最终用户可见的服务以及间接服务。
步骤5：映射BFC类型。
根据步骤4将相应的功能映射为BFC类型，对于那些重复出现的功能仅度量一次。
步骤6：为每类BFC赋值。
步骤7：计算BFC的28个子类型的功能点数。
步骤8：计算被度量项目或应用的功能规模。
根据公式1.11计算被度量项目或应用的功能规模：1.8 IFPUG功能点标准
与本章前面所介绍的4种功能点相比较，IFPUG组织所维护的功能点标准无疑可以算得上“一枝独大”了。IFPUG功能点标准不仅比其他4种功能点标准拥有更多的使用者，更是其他4种功能点标准的“标准”。其他4种功能点标准通过公开或半公开的方式强调自己所度量的功能点结果与IFPUG功能点标准度量的结果完全一致或几乎一致。MarkII功能点标准和FISMA功能点标准都引入了加权系数，而这些加权系数的目的在于将得到度量结果转换为与IFPUG度量的结果尽可能趋于一致；NESMA功能点标准几乎就是IFPUG功能点标准的荷兰语版本；COSMIC虽然没有引入加权系数，但是因为采用了“层”的概念，最终度量的应用结果仍然与IFPUG功能点度量的结果比较接近。
另外，从功能点标准的详细程度和规则的完整性方面进行比较，IFPUG功能点标准无疑具备明显的优势。IFPUG充分考虑了软件需求的特点，给出了针对各种特殊情形的功能点计数规则，例如对于代码数据的处理等情形。正是基于以上的事实，本书后续章节主要对IFPUG功能点标准的内容和应用做了详细的介绍。
IFPUG功能点标准将所度量的项目或应用区分为两大类型的功能：对最终用户可见的事务功能（Transaction Function）和对最终用户不可见的数据功能（Data Function）。事务功能又进一步区分为三种子类型：外部输入（External Input, EI）、外部查询（External inQuiry, EQ）和外部输出（External Output, EO）；数据功能又区分为内部逻辑文件（Internal Logic File, ILF）和外部接口文件（External Interface File, EIF）。图1.9描述了IFPUG功能点标准所规定的5种功能。图1.9 IFPUG功能点标准规定的5种功能类型
对5种类型的功能再根据加权的方式将其转换为相应的功能点数值。对于数据功能首先采用表1.5的复杂性判定表，确定其复杂性为“低”、“平均”或“高”，然后再根据数据的类型——ILF或者EIF，将其转换为对应的功能点数值，如表1.6所示。例如一个具有25个数据元素类型（DET）和2个记录元素类型（RET）的内部逻辑文件对应[1]的复杂性为“平均”，其对应的功能点为10个功能点。根据表1.5和表1.6，可以得到已识别出DET和RET的数据功能的功能规模（FP）。
对于事务功能的度量采用与数据功能相似的方式。首先根据事务功能的识别规则区分出事务功能的类型，是外部输入、外部输出还是外部查询。识别出事务功能的类型之后，根据事务功能所使用的DET数目和FTR数目判断事务功能的复杂性，表1.7为EI复杂度判定表，表1.8为EQ和EO的复杂性判定表。然后根据表1.9将对应的事务功能的复杂度转换为功能点数值。例如，根据事务功能的识别规则识别出1个EI和1个EO, EI有7个DET和2个FTR，根据表1.7和表1.9可得该EI的功能点数值为4；EO有21个DET和3个FTR，根据表1.8和表1.9可得该EO的功能点数值为7。
在IFPUG功能点标准中还以附录的形式提供了非功能需求的规模度量方式，即通过度量被度量应用的通用系统特征（General Systematic Characteristics）计算相应的调整系数，用于对所度量的功能规模进行调整。
IFPUG功能点的详细内容以及操作方法参见本书的第2～6章，以及附录A。[1]此处的记录元素类型（Record Element Type）可理解为一个实体所包含的子实体。IFPUG功能点标准将实体本身和子实体的数量和做为记录元素类型的数量，如果一个实体没有子实体，则对应的记录元素类型数量为1。1.9 功能点标准比较
以上对目前ISO所接受的5种功能点标准进行了简单的介绍，下面采用表格形式对不同的功能点标准就功能点类型、应用范围、可操作性和应用现状等方面的信息进行了比对分析，如表1.10所示。
如前文所述，虽然目前存在不同的功能点标准，但就其应用的广泛程度来看，IFPUG标准仍然是目前最主要的标准，其他4种标准也都是在IFPUG功能点标准的基础之上发展而来的。
软件功能点标准在我们国家的应用任重道用，截止到目前为止，软件功能点在我国的软件行业中只有零星的应用，尚无出现大面积应用的趋势。这与我国整个软件行业的管理现状不无关系，那些相对成熟的软件开发和管理组织（例如银行）能感受到采用客观的、定量管理方式的必要性，而对一些成熟度还较低的软件开发和运维组织而言，更多的注意力还集中于管理过程、开发过程是否完善，人员的能力和经验是否能够满足组织的要求，如何防止人员流失等更为迫在眉睫的事项，因而对于软件功能点方法的采用目前还没有提到议事日程上。
那些高成熟度组织的做法无疑对于我们今天的软件开发和运维组织具备积极的参考意义，例如仅IBM一家公司就占据了全球认证功能点专家的20%（全球具备认证功能点专家的人数为1333人，IBM为255人，数据来自于IFPUG 2009年数据）。所以随着我国软件行业的发展壮大，软件开发和运维组织成熟度的提高，软件功能点度量方法在我国将会得到普遍的应用，为软件项目的定量管理决策提供坚实的基础。第2章 软件功能规模度量过程2.1 功能规模度量概述
在了解软件功能规模度量的过程之前，首先需要知道什么是软件功能规模？功能规模度量又是指什么？
在ISO/IEC 14143-1中，把用户需求区分为两种类型：一种是功能用户需求，另一种是非功能用户需求。功能用户需求是指描述软件要做什么，提供什么样服务的用户需求子集。如数据存储、数据传输和数据提取等都属于功能用户需求。非功能用户需求在ISO中没有做明确的定义，但给出了一些例子，如质量约束（可用性、可靠性、有效性和可移植性等）和组织约束（操作位置、目标硬件和符合标准规定等）、环境约束（互用性、安全性和保密性等）和实现约束（开发语言、交付进度等）。
软件功能规模是指通过量化功能用户需求而得到的软件规模。这里的软件规模用功能点（FP）来表示，即功能点是IFPUG功能规模的度量单位。就如使用平方米表示面积、千克表示重量一样，可以用一个软件的功能点数来表示该软件的功能规模。
IFPUG功能规模度量（Functional Size Measurement, FSM）是用功能点分析（FPA）方法来度量软件功能规模。功能点分析从用户角度度量软件开发，不考虑软件的物理实现。功能点计数是使用IFPUG FSM中的规则来度量一个应用或项目功能规模的活动。2.2 功能规模度量过程
软件功能规模度量过程一般分为如下几步：（1）收集可得的文档。（2）确定计数范围和边界，识别功能用户需求。（3）度量数据功能和事务功能。（4）计算软件功能规模。（5）编写文档，报告度量结果。
软件功能规模度量过程如图2.1所示。
要对软件项目进行功能规模度量，首先要熟悉该软件所交付的功能或所影响的功能，这些信息的主要来源就是该软件项目的文档，所以需要收集这些文档，以支持后续的功能规模度量活动。在熟悉文档的基础上，根据功能点计数的目的识别出功能点计数类型，然后确定计数范围和应用边界。由于软件功能规模是度量功能用户需求的结果，因此要识别功能用户需求，进而为后续的功能点计数过程作准备。度量数据功能和事务功能是功能规模度量过程中最重要的活动，把识别出来的功能用户需求分为数据功能和事务功能，然后根据相关规则对这些功能进行度量，得到这些数据功能和事务功能的功能规模。不同的功能点计数类型有不同的功能规模计算公式，结合前面得到的数据功能和事务功能的功能规模，利用相应公式计算出项目或应用的功能规模。最后对度量结果进行整理，编写文档并报告结果。图2.1 功能规模度量过程2.2.1 收集可得的文档
文档可以包括需求、数据/对象模型、类图、数据流图、用例、过程描述、报表显示、界面显示、用户手册，以及其他软件开发文档。软件的不同生命周期阶段可得到的文档也不同。本书作为示例，其模型包含三种类型的需求阶段，即初始用户需求、初始技术需求和最终功能用户需求。
初始用户需求为用户提出的初始需求，它可能具有下列特征：（1）不完整。（2）缺少“效用”功能。（3）不可能实现或很难使用。（4）太笼统。（5）没有考虑应用边界。（6）表达和功能点分析中用到的术语不一致。
初始技术需求是软件开发人员从可行性研究中创建的需求。初始技术需求可能包含技术实现的相关内容，而这些内容在功能规模度量中不予考虑。
初始技术需求可能具有下列特征：（1）依赖于技术。（2）使用用户不熟悉的术语。（3）确定功能时太多地考虑了技术约束。（4）边界可能根据技术结构确定而不是业务过程。
最终功能用户需求来自用户和软件开发方的共同讨论，达到了功能需求的一致性和完整性。本阶段是开发阶段开始之前功能用户需求的最后版本，具有如下特征：（1）用户和开发人员都能理解其中的术语。（2）是所有用户需求的集成描述。（3）定义了所有业务过程并为每个业务过程定义了数据源以及每个业务过程的确认信息。（4）业务过程和数据组都得到了用户和开发人员的共同认可。（5）可行性和可用性得到了开发人员的认可。
最终功能用户需求阶段是度量功能规模的最准确阶段。
开始功能规模度量之前，需要判断应用所处的生命周期阶段以确定是近似估算还是度量。近似估算允许对未知功能以及它们的复杂性做出假设，以便确定近似功能规模。度量则是识别所有功能及其复杂性来完成功能点分析。
在生命周期的早期阶段，初始用户需求可能是功能规模度量中可用的唯一文档，需要进行近似估算，虽然近似估算存在弊端，但这个规模对早期项目估算用处很大。需求阶段结束以后的后续各阶段都可以对功能规模进行度量，当然也可以做近似估算。
在功能规模度量过程中可参考的文档包括需求文档、用例、实体关系图、对象模型、数据模型、数据库设计文档、接口协议及接口文件、报表及用户界面示例、用户指南、用户手册、应用帮助文件、系统设计文档等。如果无法获得足够的文档，也可以求助于业务专家或用户的支持。2.2.2 确定计数范围和边界
功能点计数类型的识别、功能点计数范围和边界的确定都需要以功能点计数目的为依据，所以首先要明确本次功能点计数的目的。计数目的为业务问题提供答案，业务问题确定了计数目的。例如，想要估算开发新应用所需的工作量，这是一个业务问题，而功能规模是估算工作量的依据，所以要对该应用进行功能点计数。
1.功能点计数类型
根据功能点计数目的（度量目的）可以把功能点计数分为三种类型，即开发项目功能点计数、升级项目功能点计数和应用功能点计数。（1）开发项目。
开发项目是开发并交付软件应用的第一个正式版本的项目。开发项目功能规模是对软件第一个发布版本提供给用户的功能进行的度量，度量时使用IFPUG功能规模度量（FSM）方法，得到开发项目的功能规模（即功能点数）。（2）升级项目。
升级项目是开发并交付适应维护的项目。适应维护是软件产品交付后为使其适应变化的环境而进行的修改。升级项目功能规模是对已安装应用的修改（添加、修改和删除的用户功能）的度量，度量时使用IFPUG功能规模度量方法，得到升级项目的功能规模。（3）应用。
应用是一个业务目标的自动程序和数据支持的结合，由一个或多个组件、模块或子系统组成。应用的功能规模是对一个应用提供给用户的当前功能的度量，度量时使用IFPUG FSM方法得到应用的功能规模。
应用功能规模也称为基线或已安装的功能规模，它用来度量应用提供给用户的当前功能。开发项目功能点计数完成时应用功能点被初始化，以后每次升级项目完成时，应用功能点都需要更新。
功能点计数类型之间的关系如图2.2所示。图2.2 功能点计数类型间的关系
2.计数范围
计数范围定义了包含在功能点计数之内的功能用户需求集。
计数范围包含如下含义：（1）定义了需要度量规模的一组软件或软件的一个子集。（2）由执行功能点计数的目的决定。（3）识别哪些功能应该包含在功能规模度量中，从而为计数目的提供答案。（4）可以包含一个以上的应用。
不同的功能点计数类型，其计数范围也会不同，如：
开发项目功能点计数包括项目活动所影响的所有功能，也包括作为开发项目一部分的转换功能（转换功能参见第5章的5.2节）。
升级项目功能点计数包括增加、修改和删除的所有功能，也包括作为升级项目一部分的转换功能。
应用功能点计数根据计数目的不同可能包含用户使用的功能或交付的所有功能。
3.边界
边界（也称为应用边界）是软件和其用户之间概念上的分界。这里的用户不仅仅指操作软件的人，还包括和软件有交互的其他软件或硬件等。为什么要划分被度量应用的边界呢？因为IFPUG FSM中把功能用户需求分为数据功能和事务功能，对数据功能和事务功能复杂性的度量都和应用的边界有关，比如在应用边界内的数据功能为内部逻辑文件，应用边界外的数据功能为外部接口文件。事务功能的确定也和边界密切相关，如外部输入处理来自边界外的数据或控制信息，外部输出和外部查询都是发送数据或控制信息到边界外部。
边界的位置很重要，边界不同可能功能规模度量的结果也不同。而边界的划分又有一定的主观性，有时很难描绘一个应用从什么地方结束，另一个应用从什么地方开始，应尽量从业务需求的角度而不是从技术或物理实现的角度来划分应用边界。图2.3为一个网上购物系统的应用边界划分，图中的虚线表示应用的边界。图2.3 网上购物系统边界划分
4.确定计数范围和边界
确定计数范围时最重要的是要了解功能点计数目的，从计数目的来判断哪些功能应包含在计数范围内，哪些应排除在外。例如，计数目的是估算开发新应用所需的工作量，那么其计数范围就应该包括需要开发的新应用的所有功能；若计数目的是估算升级项目所需的成本，那么计数范围就应该包括升级时新增、修改、删除的所有功能，而不应包括其他不做任何修改的原有功能。
IFPUG标准中给出了如下识别应用边界的规则：（1）边界基于用户角度确定。（2）相关应用之间的边界基于用户所看到的那些独立功能，而不是基于技术考虑。（3）对已经建立初始边界的应用或修改中的应用，其边界不受计数范围的影响。
第一条和第二条含义相同，即识别边界的时候要以功能用户需求为依据，而不是技术实现。比如C/S结构的软件系统，不应按照其技术实现上分客户端和服务器端而在客户端和服务器端之间划分一条边界，而应按照其所要实现的功能来划分。
第三条说明边界不受计数范围影响，最典型的是在升级项目功能规模度量的时候，如果原先的应用已经识别出了边界，则边界不需要重新识别。这时虽然计数范围发生了变化（升级项目的计数范围），但边界仍然不变。
另外，识别应用边界的时候，也可借助系统流程图来作出判断，系统流程图使各个应用系统之间的交互更直观，有助于识别哪些功能属于应用内部，哪些功能属于应用外部。通过考察其他度量数据，如工作量、成本和缺陷等，也有助于判断应用边界，因为功能点和其他度量数据的边界是相同的。如果难以判断应用边界，也可以咨询业务专家。
5.识别功能用户需求
用户需求可包括功能需求和非功能需求，功能规模度量是针对功
试读结束[说明：试读内容隐藏了图片]