软件功能点技术与应用

软件功能点技术与应用内容功能点标准概述IFPUG功能点概述示例升级项目及维护活动功能点应用Q&A2014.022功能点标准概述功能点标准

IFPUG功能点标准MarkII功能点标准Nesma功能点标准COSMICFFP功能点标准2014.023功能点标准FunctionalSizeMeasurementStandardISO/IEC14143功能规模（Functionalsize）量化表述用户功能性需求的软件规模AsizeofthesoftwarederivedbyquantifyingtheFunctionalUserRequirement功能规模度量（FunctionalSizeMeasurementFSM）度量功能规模的过程（TheprocessofmeasuringFunctionalSize）2014.024功能点标准2014.025功能点标准IFPUG功能点标准MarkII功能点标准Nesma功能点标准COSMICFFP功能点标准IFPUG功能点1979IBM的AllanAlbrecht提出FP方法1984正式的FP使用指南发布1988FPCPMrelease2.01990FPCPMrelease3.01994FPCPMrelease4.01999FPCPMrelease4.12003加入ISO/IEC标准2004FPCPMrelease4.22014.026IFPUG功能点IFPUGIFPUG(InternationalFunctionPointsUsers’Group)即国际功能点用户组是一个致力于功能点分析研究的非营利性组织。1986年IFPUG组织成立，后续的FP指南都是由IFPUG组织所发布的FunctionPointCountingPracticesManual系列版本2014.027MarkII功能点MarkII英国人CharlesSymons为KPMG工作时提出的方法1991年定义MarkII方法目前该方法由英国软件度量协会MetricsPracticeCommittee委员会维护2002年11月纳入国际标准http://www.uksma.co.uk2014.028MarkII功能点MarkII视所有的用户功能为逻辑事务每个事务包括输入、处理过程和输出功能点指数（FPI）是所有逻辑事务的输入数据元素类型数量（Ni）、数据实体类型的引用数量(Ne)和输出数据元素类型数量(No)的加权和其中，Wi=0.58,We=1.66,Wo=0.262014.029Nesma功能点Nesma1989NESMA发布了CountingPracticesManual1.0版本1996NESMA发布了CountingPracticesManual2.0版本2004NESMA发布了CountingPracticesManual2.2版本http://www.nesma.nl2014.0210Nesma功能点NesmaNesma与IFPUG一样，将功能点划分为五个类型，分别是EI/EO/EQ/ILF/EIF但在一些方面存在差异，例如

EQ与EO的区分

EQ的复杂程度隐含查询（ImplicitInquiry）代码数据（CodeData）物理介质组合查询2014.0211CosmicFFP功能点2014.0212过程识别使用FPA方法识别输入、输出与查询使用FFP方法识别入口、出口、读、写得到FPC管理过程/控制过程CosmicFFP功能点2014.0213CosmicFFP功能点步骤一：获取功能性需求2014.0214CosmicFFP功能点步骤二：映射阶段2014.0215CosmicFFP功能点步骤二：映射阶段（续）2014.0216CosmicFFP功能点步骤二：映射阶段（续）2014.0217CosmicFFP功能点步骤二：映射阶段（续）2014.0218CosmicFFP功能点步骤三：度量阶段2014.0219IFPUG功能点概述功能点分析概述功能点分析的目的和用途为什么要使用功能点分析功能点分析方法功能点计数过程功能点计数（FPC）类型功能点计数范围和应用边界2014.0220功能点分析概述什么是功能点什么是功能点分析功能点历史IFPUG2014.0221功能点分析概述什么是功能点功能点（FunctionPoints）是度量软件规模的一个标准度量单元一个软件的大小可以通过交付给用户的功能点数来度量，就如一间房子的大小通过提供给用户的建筑面积或使用面积来度量一样。2014.0222功能点分析概述什么是功能点分析功能点分析（FunctionPointAnalysis）是从用户角度度量软件开发的一种标准方法。功能点分析基于用户的逻辑功能需求，而不考虑应用的物理实现2014.0223功能点分析概述功能点历史1979IBM的AllanAlbrecht提出FP方法1984正式的FP使用指南发布1988FPCPMrelease2.01990FPCPMrelease3.01994FPCPMrelease4.01999FPCPMrelease4.12003加入ISO/IEC标准2004FPCPMrelease4.22014.0224功能点分析概述IFPUGIFPUG(InternationalFunctionPointsUsers’Group)即国际功能点用户组是一个致力于功能点分析研究的非营利性组织。1986年IFPUG组织成立，后续的FP指南都是由IFPUG组织所发布的FunctionPointCountingPracticesManual系列版本2014.0225功能点分析的目的和用途功能点分析的目的度量用户要求的及得到的功能性脱离软件技术实现来度量软件的开发和维护除了满足以上目的，功能点分析过程应该：足够简单以最小化度量过程所需要的开销在不同的项目或组织之间保持一致的度量方法和标准2014.0226功能点分析的目的和用途功能点分析的用途通过计算包含在应用包中的所有功能点来确定购买的应用包的规模大小通过计算满足用户特定需求的功能点数来帮助用户确定一个软件应用包给组织带来的好处通过度量软件单元，进行软件质量和生产率分析是估计软件开发和维护所需成本和资源的一种方法是进行软件比较的一个标准化要素（factor）可以作为软件组织资产管理的一种方法2014.0227为什么使用功能点分析有效的规模度量方法的特征功能点和代码行的比较使用功能点分析的好处2014.0228为什么使用功能点分析有效的规模度量方法的特征对用户和开发人员都是有意义的、可理解的。已定义的（行业公认的）一致的方法（不同项目、不同组织等）容易学习和使用准确的，基于统计的需要时可用的（如在项目早期）2014.0229功能点分析满足以上特征，是从用户的角度度量软件规模的一种标准方法。为什么使用功能点分析功能点和代码行的比较

功能点的优点

代码行的缺点1.功能点是独立于实现技术和平台的度量技术，是从用户角度来度量的2.功能点可以从早期需求阶段得到3.功能点是贯穿在整个生命周期中的一致的、客观的度量单元4.功能点用客户容易理解的方式表示软件的规模1.没有一个统一的数代码行的标准2.代码行度量组件而不是整个产品3.用代码行度量生产率会导致软件设计不严谨等问题2014.0230为什么使用功能点分析功能点和代码行的比较典型生产率度量矛盾Project1Project2LinesofCode10,0003,000FunctionPoints2525TotalMonthseffort2515TotalCosts$125,000$75,000CostperSourceLine$12.50$25.00LinesperPersonmonth400200FPsperPersonmonth1.22CostperFP$5,000$3,0002014.0231为什么使用功能点分析使用功能点分析的好处使用功能点管理软件开发估计和度量需求规模估计和度量需求变更带来的影响通过度量提升软件开发的生产率和质量使用功能点管理软件组织用于资产管理在CMMI中的运用改进客户关系进行组织级改进2014.0232为什么使用功能点分析使用功能点分析的好处使用功能点管理软件开发（需求变更）2014.0233为什么使用功能点分析使用功能点分析的好处使用功能点管理软件开发通过度量提升软件开发的生产率和质量2014.0234FP/HourProjectFunctionPointSize为什么使用功能点分析使用功能点分析的好处使用功能点管理软件组织用于资产管理Size=50,000FunctionPointsReplacementCost=$300,000,000Growth=7%peryearSupportCost=$20,000,000peryear2014.0235为什么使用功能点分析使用功能点分析的好处使用功能点管理软件组织在CMMI中的运用在CMMI的许多过程域中都需要作软件规模的度量，而功能点是度量规模的主要方法。CMMI四级以上对度量的要求很高，需要做到项目量化管理2014.0236为什么使用功能点分析使用功能点分析的好处使用功能点管理软件组织改进客户关系可预见的功能性可预见的工作量和工期可预见的成本2014.0237为什么使用功能点分析使用功能点分析的好处使用功能点管理软件组织进行组织级改进进行过程度量进行项目管理度量估计生产率缺陷密度等等进行标杆2014.0238功能点分析方法2014.0239filefilefileApplicationAApplicationBfile外部输入EI外部输出EO外部查询EQ事务功能内部逻辑文件ILF外部接口文件EIF数据功能功能点分析方法把用户的业务功能需求分为数据功能需求和处理数据的事务功能需求数据分为应用内部逻辑数据和应用外部的接口数据，事务分为对数据的外部输入、输出和查询分别分析这些组成部分的功能点2014.0240功能点分析方法数据功能（DataFunction）指提供给用户的以满足应用内部和外部数据需求的功能性分为内部逻辑文件（ILF）和外部接口文件（EIF）复杂性由数据元素类型（DET）和记录元素类型（RET）决定2014.0241功能点分析方法事务功能（TransactionFunction）指提供给用户的以满足应用数据处理需求的功能性分为外部输入（EI）、外部输出（EO）、外部查询（EQ）复杂性由数据元素类型（DET）和文件引用类型（FTR）决定2014.0242功能点计数过程2014.0243确定功能点计数类型识别计数范围及应用边界数数据功能点数事务功能点确定未调整功能点数确定调整系数值计算调整功能点数功能点分析方法数据功能确定ILF与EIF的复杂度确定ILF与EIF的复杂度要确定两个系数数据元素类型（DET）记录元素类型（RET）根据下表判断DET与RET的复杂度2014.02441-19DET20-50DET>50DET1RET简单简单平均2-5RET简单平均复杂>5RET平均复杂复杂功能点分析方法事务功能确定EI的复杂度2014.02451-4DET5-15DET>15DET0-1FTR简单简单平均2-FTR简单平均复杂>2FTR平均复杂复杂功能点分析方法事务功能确定EO的复杂度2014.02461-5DET6-19DET>19DET0-1FTR简单简单平均2-3FTR简单平均复杂>3FTR平均复杂复杂功能点分析方法事务功能确定EQ的复杂度2014.02471-5DET6-19DET>19DET0-1FTR简单简单平均2-3FTR简单平均复杂>3FTR平均复杂复杂功能点分析方法计算初始功能点初始功能点的取决于功能类型及其对应的复杂度2014.0248功能点分析方法确定系统的14个特征值FPA方法认为有14个因素影响FP的个数这14个特征值根据SRS的内容来判断非功能需求设计约束根据每个特征值的特点，决定它的取值，取值范围介于0到5之间2014.0249功能点分析方法2014.0250功能点分析方法计算调整系数VAF=(TDI*0.01)+0.65TDI(TOTALDEGREEOFINFLUENCE)0.65<VAF<1.35计算功能点FPC=UFP*VAF2014.0251功能点计数过程确定功能点计数类型识别计数范围及应用边界识别数据功能并转换为未调整功能点数识别事务功能并转换为未调整功能点数确定未调整功能点数（UFP）确定调整系数根据相应的计算公式计算调整功能点数2014.0252功能点计数过程2014.0253查询员工信息EQuser1HRsystemEmployeeinformation(ILF)CurrencyAppConversionrate(EIF)Boundary新建员工信息EIuser1user1生成员工信息报表EO常用术语用户（User）用户角度（Userview）应用（Application）项目（Project）文件（File）2014.0254常用术语用户（User）用户包括制定软件功能需求的人，和软件通讯或交互的人或者系统用户角度（UserView）是以用户语言对用户业务需求进行的正式描述。开发人员为了提供解决方案把用户语言转换成信息技术语言。业务功能描述被用户认可被用来数功能点有不同的物理形式（如：事务分类、建议书、需求文档、详细规格、用户手册等）2014.0255常用术语应用（Application）支持一个业务目标的自动过程和数据的集合由一个或多个组件、模块或子系统组成通常和系统（system）、应用系统、信息系统含义相同项目（Project）在规定时间内，为了交付产品而执行的一组任务。2014.0256常用术语文件（file）一个逻辑相关的数据组不是数据组的物理实现2014.0257功能点计数类型三种类型开发项目（DevelopmentProject）升级项目（EnhancementProject）应用（Application）三者关系三种类型使用不同的计算公式来计算功能点数2014.0258功能点计数类型三种类型开发项目（DevelopmentProject）开发项目功能点计数度量新项目完成时交付给用户的软件第一次安装的功能点升级项目（EnhancementProject）升级项目功能点计数度量对现有应用更改所带来的功能点，包括对现有应用功能的增加、修改和删除。应用（Application）应用功能点计数和已安装的应用相关，也称为基线或已安装功能点。它用来度量应用提供给用户的当前功能。2014.0259功能点计数类型三种功能点计数类型之间的关系2014.0260EstimatedCountDevelopmentProjectasProjectAEstimatedCountEnhancementsasProjectBFinalCountEnhancementsasProjectBFinalCountDevelopmentprojectasProjectAApplicationcountCompletedprojectCompletedproject注：projectB是在projectA完成后升级的项目当开发项目功能点计数完成后，应用功能点数被初始化，而当每次更改应用功能的升级项目完成时，应用功能点数都需要更新。initializesupdates功能点计数范围和应用边界定义（Definition）功能点计数的目的功能点计数的范围应用边界规则（Rules）程序（Procedure）提示（Hints）2014.0261功能点计数范围和应用边界定义功能点计数的目的（CountingPurpose）功能点计数的目的为业务问题提供答案它决定了功能点计数的类型以及计数范围它会影响所考察的软件与其它软件之间边界的位置举例：功能点计数的目的是用来估计开发一个新应用所需要的工作量功能点计数的目的是为已安装的应用提供功能点基线2014.0262功能点计数范围和应用边界定义功能点计数的范围（CountingScope）功能点计数的范围定义了将被包含在一个特定功能点计数中的功能性指定需要估计规模的一组软件由功能点计数的目的决定，识别哪些功能要包含在本次的功能点计数中可以包含一个以上的应用举例：升级项目的功能点计数范围包含被增加、修改、删除的所有功能。开发项目的功能点计数范围包含项目行为所影响的所有功能应用的功能点计数范围根据目的可以包含那些被用户使用的功能或者所有交付的功能2014.0263功能点计数范围和应用边界定义应用边界（ApplicationBoundary）应用边界表明了所度量的软件和用户之间的界限。它说明了哪些功能属于应用的外部它是内部应用和外部用户间概念上的接口它包含了应用所维护的逻辑数据（ILF）它有助于识别应用所引用的但不维护的逻辑数据（EIF）它从用户的角度确定，和技术及实现无关举例：2014.0264user1HRsystem(beingcounted)FixedAssetssystem功能点计数范围和应用边界规则（Rules）应用边界的识别必须遵循下列规则应用边界是基于用户的角度确定的。依据应该集中在用户能理解并描述的业务需求上。相关应用程序之间的边界应该基于用户分别对相应应用程序业务功能的理解，而不能从技术角度考虑。为应用程序或者被更改的应用程序建立的初始边界不受计数范围变化的影响。2014.0265功能点计数范围中可能包含一个以上的应用，这时，应该识别多个应用边界。边界应该尽可能定义准确，它将影响功能点计数结果。功能点计数范围和应用边界程序（Procedure）识别功能点计数范围和应用边界可以按照以下程序：确立数功能点的目的识别功能点计数范围识别应用边界把下面的几项文档化功能点计数目的功能点计数范围应用边界相关假设2014.0266功能点计数范围和应用边界提示在考察的软件和其它软件应用之间的边界位置可能是主观的。有时候很难描绘一个应用到什么地方停止而另一个应用开始，所以应尽量从用户业务需求的角度出发而不要从技术角度出发。2014.0267示例示例一示例二2014.0268升级项目及维护活动升级项目的范围和边界升级项目的数据功能升级项目的事务功能升级项目的通用系统特征升级项目功能点计数过程升级和维护对比2014.0269升级项目及维护活动升级项目的范围和边界升级项目的功能点计数包括被增加、修改和删除的所有功能升级应用与原应用边界保持相同在功能点计数范围内可能包含多个应用，这是需要识别多个应用边界，分别计算各个应用的升级功能点2014.0270升级项目及维护活动升级项目的数据功能需要数新增的、修改的及删除的数据功能新增的和删除的数据功能容易识别判断修改的数据功能时应注意：如果修改仅包含逻辑文件中新纪录的增加或者已存在字段中新值的增加，那么不能认为数据功能被修改如果数据功能中添加了新字段，而这个新字段不被应用所使用，那么该数据功能不能认为是被修改的数据功能一个数据功能被算作被修改的功能，通常其结构要发生改变（如：增加或删除一个字段或者修改了字段特征）2014.0271升级项目及维护活动升级项目的数据功能判断修改的数据功能时应注意：如果应用需要使用一个已经存在的字段，而这个字段升级前没有使用过，则相关的数据功能应该被算作修改的功能（这种情况文件物理上没变化）如果被两个应用共同维护的ILF新增了一个字段，且一个应用维护新字段而另一个应用仅引用新字段；则两个应用都把该ILF作为修改的ILF，但是第一个应用有新增的或修改的维护新字段的功能，而第二个应用没有。如果一个物理文件被增加到升级项目中，则它不一定是一个新增的数据功能2014.0272升级项目及维护活动升级项目的事务功能需要数新增的、修改的及删除的事务功能新增的和删除的事务功能容易识别判断修改的事务功能时应注意：事务功能的DET被增加或删除，则事务功能是修改的事务功能事务功能的处理逻辑被修改，则事务功能是修改的事务功能DET的增加和删除容易识别而处理逻辑的修改不容易识别2014.0273升级项目及维护活动升级项目的事务功能修改的事务功能2014.027412341、事务1新增了一个进入应用边界的DET2、事务2新增了一个发送到应用边界外的DET3、事务3验证的处理逻辑进行了修改4、事务4选择过滤的处理逻辑进行了修改升级项目及维护活动升级项目的事务功能修改的事务功能判断事务功能的修改要以升级项目的业务需求为依据事务功能的处理逻辑更改，则事务功能应计算在内，包括13个处理逻辑显示给用户的信息的格式、字体、颜色和其它物理元素发生改变，不应该算作处理逻辑改变，不应算到省级项目的功能点中重新分类或重新排列数据不会影响事务功能类型及唯一性的识别，但是引起了处理逻辑的修改，应该算作修改的事务功能2014.0275升级项目及维护活动升级项目的通用系统特征小的升级通常不需要重新评价14个通用系统特征值需要重新评价通用系统特征值的例子：对一个批处理应用增加了在线功能高事务率和减少的响应时间需要性能设计和相应的测试活动需要增加使用性特征对一个现存的在线应用增加了web接口对现存应用增加了新的通讯协议……2014.0276升级项目及维护活动升级项目功能点计数过程2014.0277收集并分析可得的文档和相关专家讨论升级中的功能变更识别并计算新增功能的未调整功能点识别并计算删除功能的未调整功能点识别并计算修改功能的未调整功能点识别并计算转换功能的未调整功能点判断GSC的变化并计算调整系数值计算升级项目功能点升级项目及维护活动升级项目功能点计数过程计算公式：EFP=[(ADD+CHGA+CFP)*VAFA]+(DEL*VAFB)项目升级后应用功能点计算公式：AFP=[(UFPB+ADD+CHGA)-(CHGB+DEL)]*VAFA2014.0278升级项目及维护活动升级和维护对比维护的分类（IEEE定义）适应维护维护软件使其适用于变化的环境（部分可用FPA中的升级功能点度量）纠错维护维护软件以纠正硬件或软件的缺陷（不可用FPA度量）优化（或预防）维护维护软件以提高性能、可维护性或其它程序属性（不可用FPA度量）2014.0279升级项目及维护活动升级和维护对比FPA不适用于所有的维护活动FPA中的升级项目是指业务功能的新增、修改、删除等如果项目包含几种维护的混合，需要分别考虑度量方法2014.0280功能点应用基于功能点的行业数据基于功能点的经验公式功能点应用场景2014.0281基于功能点的行业数据Capers统计的软件功能点数据国际软件标杆组织（ISBSG）提供的功能点数据2014.0282基于功能点的经验公式1功能点与代码行对应关系320statementsinBasicAssemblylanguage125statementsinC107statementsinCOBOL71statementsinADA15statementinSmallTalk说明：本部分给出的近似公式来源于Capers统计的项目数据2014.0283基于功能点的经验公式12014.0284基于功能点的经验公式2软件文档规模软件管理文档、规格文档、操作手册文档页数=（功能点）1.15例如：500FP=>1,270pages2014.0285基于功能点的经验公式3需求蔓延需求确认后的蔓延程度每个月蔓延的速度大约为2%2014.0286基于功能点的经验公式4测试用例数目估算测试用例数目=（功能点）1.2包括集成测试、系统测试、回归测试例如，1000FP=>3981testcases2014.0287基于功能点的经验公式5潜伏缺陷潜伏缺陷=（功能点）1.25幂指数有可能介于（0.8,1.25）缺陷包括所有级别与类型的缺陷2014.0288基于功能点的经验公式6缺陷去除率每一次正式的软件评审或测试都可以发现缺陷数目的30%依照5次检查推算缺陷遗漏率16.8%依照8次检查推算缺陷遗漏率5.7%依照10次检查推算缺陷遗漏率2.8%依照15次检查推算缺陷遗漏率0.47%2014.0289基于功能点的经验公式62014.0290基于功能点的经验公式7软件项目开发周期开发周期=（功能点）0.4幂指数可能介于（0.3,0.4）2014.0291基于功能点的经验公式72014.0292项目规模：1000FunctionPoints基于功能点的经验公式8项目平均人员规模功能点/1502014.0293基于功能点的经验公式9软件维护人员数目功能点数/7502014.0294基于功能点的经验公式10软件工作量规则7与规则8假设有1000功能点工期(FP^0.4)=16个月人员(FP/150)=6.6人工作量（16*6.6）=106人月2014.0295功能点应用场景1项目前期的可行性分析关注技术可行性之外的内容采用快速功能点方法判断项目所需完成的工期和初步预算，从而决定组织是否能够支撑或接受该项目示例：某组织希望启动一个网上书城的应用项目，涉及的业务实体大概为30个左右，可以快速得到项目的功能点数为1200（30*10*4）个。所以对应的工作量为40到80人月，需要的预算为120万到240万左右，对应的开发时间为8到17个月2014.0296功能点应用场景2甲方确立项目范围与标的甲方在招标的过程中首先需要在内部立项、申请预算功能点方法有助于给出明确的预算申请依据，使得预算过程更加透明示例：1000个功能点的项目，甲方内部申请的预算为1000*2K=2000K，其中1000FP是根据功能点标准得到，而每个功能点的费用为2K则可以依据行业数据得到（假定一个功能点的开发成本为1.5K左右，考虑到乙方的利润为20%，以及甲方10%左右的管理成本）2014.0297功能点应用场景3为乙方确立项目的范围与标的甲方要求乙方在投标过程中采用功能点报价或评估工期，便于甲方从第三方的角度审查核实乙方的报价是否过高或偏低2014.0298功能点应用场景4甲乙双方合同谈判的依据与传统的基于模块的报价方法相比较，基于功能点的谈判过程对双方更为透明。甲方不必再单独依赖于所谓的“最低价中标”或“中间价中标”等评判方式甲方可以依据乙方所提供的软件功能点数量进行验收并支付合同款项如何确保质量标准？2014.0299功能点应用场景5乙方项目立项的依据基于功能点方法，乙方内部的人员配备、费用安排以及工期设定等都可以更透明乙方比较不同项目的预算可以更好地将市场因素与技术因素区分开来，从而给定相对客观的立项依据示例：项目的项目，它们的合同价分别是50万、100万、150万，那么乙方内部立项的预算是否会有所不同？2014.02100功能点应用场景6项目计划与跟踪的基础对于增量型项目，采用功能点可以直接衡量项目的产出，甚至可以作为依据向客户收取与功能点数量对应的费用对于瀑布型项目则可以考虑引入转换机制，使得每阶段产出都可用功能点衡量问题：如何减小双向转换所带来的误差？2014.02101功能点应用场景7评审质量目标的确定每次评审会议的出口约束条件如何设定？基于过程约束的相对标准往往效果有限例如，评审会议要关闭所有已经发现的问题？那些没有发现的问题如何处理？例如需求评审的质量目标为0.1-0.3缺陷/FP