FPA功能点算法全文.ppt

单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,*,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,FPA功能点算法(全文),内容提要,软件度量概述,1,功能点方法概述,2,功能点计数,基本,过程,3,功能点计数应用状况,4,2,引导案例：,IT,支撑系统软件开发中的窘境,3,投资规划,投资管理,系统开发,需求分析,运行维护,资产管理,采购管理,软件投资规模问题,软件投资合理性问题,需求描述不清问题,外包开发过程度量问题,系统增强开发问题,维护成本问题,总体来看，缺乏对,IT,支撑系统应用软件全生命周期的有效管理，尤其是软件的度量管理,商务谈判报价评定问题,需求变更与成本增加的平衡问题,软件资产核算问题,软件报废问题,开发商生产率评定问题,IT,支撑系统软件开发过程中各方窘境,系统开发商,传统工作量评定按人,/,天计算，没有科学的理论依据，缺乏说服力。,作为合作乙方，在系统开发工作量和费用平衡方面，难以说服甲方达成共识。,规划技术部,缺乏应用软件规模的估算方法，难以合理确定应用软件的投资规模。,采购管理中心,商务谈判中，对,IT,系统与开发商视角不同，信息不对称，双方沟通存在障碍。,缺乏双方一致认可的应用软件合同报价评定方法，难以合理确定外包开发软件价格。,业务部门,业务需求复杂、多变，希望应用软件能快速满足用户需求，对开发成本不敏感。,无法完整清晰、有序地提出业务需求。,业务支撑中心,缺乏科学的方法衡量需求变更带来的成本增加。,缺乏对系统开发商软件产品和开发过程有效、完整的度量和评价。,4,问题的解决途径,建立科学的软件规模度量体系,缺乏对软件规模在全生命周期中的科学度量方法,系统建设各方认识角度不同，难以沟通达成协议,采用通用的软件规模度量方法,功能点法,在不同角度搜集材料，进行科学分析,在系统开发的整个生命周期内，明确各方职责,规划技术部,采购中心,业务部门,系统开发商,业务支撑中心,5,。,理想的管理模式,6,系统开发商,由传统的工作量评定按人,/,天报价方式向功能点报价方式转变,在功能规模确定的前提下，把精力放在开发生产率的提升上,规划技术部,在计划阶段，借助建立的应用软件历史数据和快速功能点法，快速确定应用软件的投资规模,采购管理中心,合同谈判前，要求系统开发商采用功能点报价方式，谈判中以功能点作为协商的共同语言,签署的合同由单一的固定总价改为以功能点为基础的成本加成型合同，平衡需求变更影响,业务部门,按照功能点分析法的要求，清晰、完整地陈述业务需求，形成标准文档,每项新业务需求的提出，转换成功能点后与相应成本挂钩，防止需求泛滥,业务支撑中心,应用功能点法合理监控外包开发过程中需求变更的范围及相应成本的变动幅度,以功能点法为基础完善对系统开发商软件产品和开发过程有效、完整的度量和评价,软件的分类,系统软件,软件,应用软件,操作系统、数据库、中间件等,业务应用软件（针对特定的行业应用开发）,套装软件,软件,定制软件,由开发商开发的成型软件（一般不作定制或定制少）,按用户需求定制开发的软件（一般交由外部厂商开发）,按使用对象,按开发方式,我们通常所指的软件度量，主要指,定制软件,的度量,7,软件的生命周期,计划阶段,需求规,格阶段,设计阶段,2008-3-25,建设阶段,测试阶段,安装上,线阶段,按照,ISO12207,对软件工程生命周期的划分，软件的生命周期分为,6,个阶段,全面项目策划,可行性分析,成本收益分析,项目启动报告,系统分析,需求规格说明书,需求规格的评审,&,返工,架构设计,/,规格说明,架构规格说明评审,&,返工,功能,/,外部设计,创建物理,/,内部设计,设计评审和设计返工,软件包选择,构造代码,&,程序软件,代码评审或代码审查,&,代码返工,软件包定制,/,接口,单元测试,软件集成,系统或性能测试计划,系统测试,性能测试,创建,&,运行自动测试,验收测试,准备交付的发布,为用户安装发布的软件,准备用户文档,准备,&,实施用户培训,提供用户支持,8,软件规模的影响因素,功能：取决于用户（业务）的需求，是用户（业务）需求的逻辑规模,(logical size),反映,代码量：是用户（业务）需求逻辑规模,(logical size),的物理规模,(physical size),反映,均源自用户（业务）需求,软件的自身规模表现为代码量和功能点数,9,软件需求,-,规模的转换模型,功能性需求,技术需求,质量需求,用户,需求,软件功能,软件代码,非功能,需求,软件的逻辑规模,软件的物理规模,软件规模派生于量化的用户功能需求与非功能需求,软件的物理规模,-,代码量不仅取决于软件功能（用户的功能性需求），还取决于用户的技术需求和质量需求（隐含）。,10,常用软件规模度量方法,11,软件规模度量,(size measurement),是估算软件项目工作量、编制成本预算、策划合理项目进度的基础,估算方法有很多种，如：功能点分析,(FPA,：,function points analysis),、代码行,(LOC,：,lines of code),、德尔菲法,(Delphi technique),、,COCOMO,模型、特征点,(feature point),、对象点,(object point),、,3-D,功能点,(3-D function points),、,Bang,度量,(DeMarcos bang metric),、模糊逻辑,(fuzzy logic),、标准构件法,(standard component),等,功能点,VS,代码行法,12,软件规模的表达形式：,源代码行：,SLOC,（站在乙方立场，侧重“,如何做,”）,历史数据或专家意见法,(PERT),单位：,KSLOC,用于度量程序开发中的智能工作量,规模与开发语言联系密切，技术的视角反映软件规模,已逐渐失去吸引力，多用于乙方内部核算用,功能点：,FP,（站在甲方立场，侧重“,做什么,”）,基于软件的功能数和一组独立的项目因子,基于需求，在项目早期即可得到的信息,与,SLOC,存在一定的对应关系,优势在于独立于软件开发语言，用业务的视角反映软件规模,国际主流测算方法，适合甲乙双方谈判沟通,功能分析法的发展历程,最早由,IBM,工程师,AJAlbrecht,于,1979,年,提出,目前已发展为三类有代表性的方法,IFPUG-FPA,（应用最广泛）,COSMIC-FFP,（称为第二代功能点法）,UK-MKII,（在英国、香港等地使用）,13,三类功能点分析法的比较,数据,/,文件,其他,系统,系统,A,的边界,用户角度,数据,/,文件的处理,数据,/,文件的处理,一个典型的信息系统由程序和数据构成：,IFPUG-FPA,COSMIC-FFP,UK-MKII,功能元素,定义,3,类处理型文件（,EI,、,EO,、,EQ,）,2,类数据型文件（,ILF,、,EIF,）,4,类数据移动,（输入、输出、读、写）,输入、输出、处理,适用对象,最适于管理信息系统,MIS,、非复杂计算系统,MIS,或嵌入式系统,主要缺点,功能分解无方法指导,技术需求和质量需求没有反映,不考虑数据计算，无法应用于分析型系统,技术需求和质量需求没有反映,使用不广泛（英国、香港等地）,技术需求和质量需求没有反映,14,功能点标准概述,IFPUG,IFPUG(International Function Points Users Group),即国际功能点用户组是一个致力于功能点分析研究的非营利性组织。,1986,年,IFPUG,组织成立，后续的,FP,指南都是由,IFPUG,组织所发布的,Function Point Counting Practices Manual,系列版本,www.ifpug.org,15,功能点分析目的和用途,功能点定义,功能点（,Function Points,）是度量软件规模的一个标准度量单元,一个软件的大小可以通过交付给用户的功能点数来度量，就如一间房子的大小通过提供给用户的建筑面积或使用面积来度量一样。,功能点分析（,Function Point Analysis,）是从用户角度度量软件开发的一种标准方法。,功能点分析基于用户的逻辑功能需求，而不考虑应用的物理实现,用户视角表示使用用户的语言对用户业务需求进行的一种正规描述。,是一个业务功能的描述；是被用户认可的,可以用来计算功能点,可以在物理形式上变化的（例如：事务处理目录、建议书、需求文档、外部规格说明、详细规格说明、用户手册）,分析目的,用户视角定义,16,功能点分析方法内容,软件,功能点方法由,5,个仅取决,于需求规格说明的要素组成,外部接口,文件,外部,输入,外部,输出,外部,查询,内部逻,辑文件,17,功能点的五类要素,内部逻辑文件,ILF(Internal Logical File),，在信息系统内部，为了完成相关功能使用的逻辑文件，包括顺序文件、数据库表等,外部接口文件,EIF(External Interface File),，该系统和外部其他信息系统为了交换数据而使用的接口文件,外部输入处理,EI(External Input),，是获得数据的过程，对终端用户的输入进行相关的处理,外部输出处理,EO(External Output),，是反馈数据的过程，完成对票据、报表等的输出,外部查询处理,EQ(External Inquiry),，针对终端用户的查询请求，输出相应的检索结果,下列五要素中，前两种属于文件；后三种属于事务处理，它们涵盖了终端用户和信息系统对象之间存在的所有可能的交互内容。,18,功能点计数要素举例,19,file,file,file,Application A,Application B,file,外部输入,EI,外部输出,EO,外部查询,EQ,事务功能,内部逻辑文件,ILF,外部接口文件,EIF,数据功能,功能点计数要素举例,20,EI/EO/EQ,反映的是运动中的数据,(data in motion),ILF/EIF,反映的是存储中的静态数据,(data at rest),功能点计数基本过程,21,1,、确定功能点计数类型,2,、识别计数范围及应用系统边界,3,、数据功能计数,4,、事务处理功能计数,5,、确定未调整的功能点数,6,、确定调整系数值,7,、计算调整后功能点数,功能点计数方法,把用户的业务功能需求分为数据功能需求和处理数据的事务功能需求,数据分为应用内部逻辑数据和应用外部的接口数据，事务分为对数据的外部输入、输出和查询,分别分析这些组成部分的功能点,数据功能（,Data Function,）,指提供给用户的以满足应用内部和外部数据需求的功能性,分为内部逻辑文件（,ILF,）和外部接口文件（,EIF,）,复杂性由数据元素类型（,DET,）和记录元素类型（,RET,）决定,事务功能（,Transaction Function,）,指提供给用户的以满足应用数据处理需求的功能性,分为外部输入（,EI,）、外部输出（,EO,）、外部查询（,EQ,）,复杂性由数据元素类型（,DET,）和文件引用类型（,FTR,）决定,(file type referenced),22,功能点计数方法,数据功能,ILF,1 to 19 DET,20 to 50 DET,51 or more DET,1RET,低（,7,）,低（,7,）,中（,10,）,2 to 5 RET,低（,7,）,中（,10,）,高（,15,）,6 or more RET,中（,10,）,高（,15,）,高（,15,）,EIF,1 to 19 DET,20 to 50 DET,51 or more DET,1RET,低（,7,）,低（,7,）,中（,10,）,2 to 5 RET,低（,7,）,中（,10,）,高（,15,）,6 or more RET,中（,10,）,高（,15,）,高（,15,）,数据功能（,Data Function,）,23,功能点计数方法,事务处理功能,EI,1 to 4 DET,5 to 15 DET,16 or more DET,0 to 1 FTR,低,(3),低,(3),中,(4),2 FTR,低,(3),中,(4),高,(6),3 or more FTR,中,(4),高,(6),高,(6),事务处理功能（,Transaction Function,）,EO,1 to 5 DET,6 to 19 DET,20 or more DET,0 to 1 FTR,低,(4),低,(4),中,(5),2 to 3 FTR,低,(4),中,(5),高,(7),4 or more FTR,中,(5),高,(7),高,(7),E,Q,1 to 5 DET,6 to 19 DET,20 or more DET,0 to 1 FTR,低,(3),低,(3),中,(4),2 to 3 FTR,低,(3),中,(4),高,(6),4 or more FTR,中,(4),高,(6),高,(6),24,功能点计数举例,25,用户对人力资源管理系统某项功能的描述：,在员工管理系统中添加一个员工资料，会使用到员工的一般信息、教育情况、工作经历和家属信息。员工隶属于某个部门，在本系统中会有一个对部门进行维护的功能。员工的工资则由另外一个财务系统提供。,人力资源管理系统的用例图如下：,功能点计数举例,26,添加员工信息功能对应识别出来的,ILF,、,EIF,、,EI,功能点数如下：,ILF,RET,数量,DET,数量,复杂度,未调整的,FP,数,员工信息,员工基本信息受教育情况,工作经历,亲属信息,4,18,低,7,部门信息,部门基本信息,1,2,低,7,EIF,RET,数量,DET,数量,复杂度,未调整的,FP,数,工资信息,员工基本信息,工资信息,2,4,低,5,EI,FTR,数量,DET,数量,复杂度,未调整的,FP,数,添加员工信息,员工信息,部门信息,工资信息,3,18,高,6,功能点计数方法,确定系统的,14,个特征值,FPA,方法认为有,14,个因素影响,FP,的个数,这,14,个特征值根据,SRS,的内容来判断,非功能需求,设计约束,根据每个特征值的特点，决定它的取值，取值范围介于,0,到,5,之间,计算调整系数,VAF=(TDI*0.01)+0.65,TDI(TOTAL DEGREE OF INFLUENCE),0.65VAF1.35,计算功能点,FPC=UFP*VAF,27,功能点分析法小结（一）,28,系统功能,WBS,分解,事务功能,数据功能,外部输入,EI,外部输出,EO,外部查询,EQ,内部逻辑文件,ILF,外部接口文件,EIF,确定,5,类要素复杂度,依据,DET,和,FTR,数量判断,依据,DET,和,RET,数量判断,未调整功能点,UFP,调整后功能点,FP,14,项影响因子调整,我们称为常规功能点法,劣势：,项目早期缺乏详细设计文档，数据类型文件（,ILF,、,EIF,）和文件复杂度无法判定,软件设计说明书,软件功能规格说明书,29,功能点分析法小结（二）,我们称为：快速功能点法，适用于项目早期计划用,劣势：,有参照系的系统测算精度取决于历史数据积累的多寡，无历史参照的新系统测算误差较大，且一般低于完工时实测数,系统功能需求类推,系统,5,类文件确定,未调整功能点,UFP,假设,1,：同类应用功能需求具相似性,假设,2,：相同业务处理对应的数据实体复杂度相似,计数,EI,、,EO,、,EQ,，类推,EIF,、,ILF,借助历史数据，计算,5,类文件复杂,度期望值,E,i,=P,i,*W,i,调整后功能点,FP,测算条件,测算内容,14,项环境影响因素分五种情形简单赋权,假设,3,：系统特征具相似性,30,功能点分析法小结（三）,输入,计算过程,结果,功能需求,相似度判定,X,X,风险因素,简单赋权,数据复杂,相似度判定,进度,工作量,成本,历史项目参数,(,能力库,),功能域描绘,功能点数,功能点单价,单位工时功能点数,项目各阶段工时分布,快速功能点估算法,功能概要书,EXCEL,工具,功能点数,数,5,类,文件数量,X,X,14,项因素,权重赋值,依据规则,判断,5,类文件,复杂度权重,进度,工作量,成本,软件详,细设计书,常规功能点测算法,功能点数,31,功能点分析法小结（四）,1,系统设计,系统测试,系统上线,需求定义,系统开发,常规功,能点法,常规功,能点法,快速功,能点法,2,3,软件开发阶段,规模度量方法,估算精度,需求定义,快速功能点法（估算）,量级,较粗,系统设计或之后需求发生重大变更时,常规功能点法（测算）,预算级,较准,系统上线,常规功能点法（修正）,后评估级,很准,100FPs,120FPs,130FPs,功能点法在软件开发不同阶段的应用总结如下：,功能点应用场景,1,、项目前期的可行性分析,关注技术可行性之外的内容,采用快速功能点方法判断项目所需完成的工期和初步预算，从而决定组织是否能够支撑或接受该项目,示例：,某组织希望启动一个网上书城的应用项目，涉及的业务实体大概为,30,个左右，可以快速得到项目的功能点数为,1200,（,30*10*4,）个。所以对应的工作量为,40,到,80,人月，需要的预算为,120,万到,240,万左右，对应的开发时间为,8,到,17,个月,32,2,、甲方确立项目范围与标的,甲方在招标的过程中首先需要在内部立项、申请预算,功能点方法有助于给出明确的预算申请依据，使得预算过程更加透明,示例：,1000,个功能点的项目，甲方内部申请的预算为,1000*2K=2000K,，其中,1000FP,是根据功能点标准得到，而每个功能点的费用为,2K,则可以依据行业数据得到（假定一个功能点的开发成本为,1.5K,左右，考虑到乙方的利润为,20%,，以及甲方,10%,左右的管理成本）,功能点应用场景,4,、甲乙双方合同谈判的依据,与传统的基于模块的报价方法相比较，基于功能点的谈判过程对双方更为透明。,甲方不必再单独依赖于所谓的“最低价中标”或“中间价中标”等评判方式,甲方可以依据乙方所提供的软件功能点数量进行验收并支付合同款项,问题：,如何确保质量标准？,33,3,、,为乙方确立项目范围与标的,甲方要求乙方在投标过程中采用功能点报价或评估工期，便于甲方从第三方的角度审查核实乙方的报价是否过高或偏低,功能点应用场景,6,、项目计划与跟踪的基础,对于增量型项目，采用功能点可以直接衡量项目的产出，甚至可以作为依据向客户收取与功能点数量对应的费用,对于瀑布型项目则可以考虑引入转换机制，使得每阶段产出都可用功能点衡量,问题：,如何减小双向转换所带来的误差？,34,5,、乙方项目立项的依据,基于功能点方法，乙方内部的人员配备、费用安排以及工期设定等都可以更透明,乙方比较不同项目的预算,可以更好地将市场因素与技术因素区分开来，从而给定相对客观的立项依据,示例：,项目的项目，它们的合同价分别是,50,万、,100,万、,150,万，那么乙方内部立项的预算是否会有所不同？,功能点应用场景,8,、测试阶段的质量目标设定,软件测试除了关注测试用例是否充分外，还要考虑所发现的问题是否已经足够,测试用例的充分性可以功能点去衡量，测试发现的问题也用功能点去衡量，再结合缺陷趋势分析、缺陷正交分析，最后可以判断测试后质量状况,35,7,、评审质量目标的确定,每次评审会议的出口约束条件如何设定？基于过程约束的相对标准往往效果有限,例如：,评审会议要关闭所有已经发现的问题？那些没有发现的问题如何处理？,例如需求评审的质量目标为,0.1-0.3,缺陷,/FP,，则规模为,1000FP,的需求应该在需求评审之后发现,100,到,300,个缺陷，否则应该进行原因分析,功能点应用场景,10,、项目需求变更的测量,软件项目往往都面临需求变更的可能，采用功能点方法有助于将变更的程度和粒度描述清楚,开发过程中新增加了,2,个需求,修改了,1,个需求，则有可能是,50,功能点，也有可能是,80,个或者,100,个功能点，所以使用功能点方法可以统一对需求变更程度的衡量。,从过程度量的角度，需求稳定度指标才更有意义,36,9,、基于功能点的验收方式,与需求的功能点一一对应进行验收,考虑完整的需求变更流程，否则无法使用功能点严格对应方法,基于功能点评价质量标准,基于功能点预估应用系统的运营质量,功能点应用场景,12,、大项目与组合项目管理,大项目与组合项目管理要解决的关键问题之一就是在不同的项目间进行比较,而采用功能点方法可以对不同的项目进行归一化处理，从而比较单位生产率、单位成本或者单位质量状况,37,11,、软件需求详细程度的约束条件,甲乙双方往往无法界定需求描述的详细程度，从而为后续需求变更“埋下伏笔”。,使用功能点的方法可以有效地指导需求描述的详细程度，将需求评审的标准由相对标准转变为绝对标准,最大程度避免因为前期需求描述不清晰而导致需求频繁变更,功能点应用场景,14,、维护项目人员的工作量考核,维护人员的工作量往往难以确定，因为他们工作性质的复杂性，例如日常维护、简单开发、外包项目管理等。,采用功能点有助于核定维护人员的工作量，例如对于关键业务系统每个维护人员每年对应的工作量为,3K,左右的功能点,38,13,、甲方内部资产管理,对许多甲方组织的,IT,部门来说，描述现有的,IT,系统规模非常有意义，对于硬件设备相对容易，对于软件系统则可以采用功能点的方法。,例如计费系统为,40K,功能点，客服系统为,32K,功能点、内部工作管理系统为,13K,功能点。这样便于从资产管理的角度知道“自己的家底有多少,功能点应用场景,16,、行业或地区间项目数据比对,基于功能点的数据分析亦可以扩展到行业分析或地区分析,例如嵌入式行业与商业应用相比较；北京、上海、广州、深圳等地区与杭州、西安、武汉、长沙等地相比较；,中国的软件行业与美国、欧洲、印度、日本等比较，而这些比较对于软件公司的市场定位、政府部门的决策制定都有着重要的参考意义,39,15,、公司范围内项目间的数据比对,建立了功能点度量与估算的框架之后，组织内部可以基于过程改进的方式对项目的现状进行分析,比对组织内项目的生产率、缺陷率、需求变更频繁程度等，在组织范围内推广项目的最佳实践等,根据统计控制过程原理，从数据分析的角度进行过程改进,功能点法在中移动的应用现状,40,应用功能点法进行软件规模评估的既往案例,:,1,、中移动集团内容计费系统一期规模后评估和二期规模测算,2,、中移动集团定制终端营销资源管理系统一期规模测算,成功经验：,按照传统的工作量报价方式核算的内容计费系统一、二期开发工作量差别不大，但从用户的功能需求出发，按照功能点法，核算出的一、二期软件功能点数相差几乎一倍。,基于上述分析，我们认为采用功能点法进行软件开发报价是较为合理的方式。,Q&A,谢谢！,41,