专题功能点分析法.pptx

上传人:莉*** 文档编号:89941678 上传时间:2023-05-13 格式:PPTX 页数:43 大小:494.32KB
返回 下载 相关 举报
专题功能点分析法.pptx_第1页
第1页 / 共43页
专题功能点分析法.pptx_第2页
第2页 / 共43页
点击查看更多>>
资源描述

《专题功能点分析法.pptx》由会员分享,可在线阅读,更多相关《专题功能点分析法.pptx(43页珍藏版)》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。

1、功能点估算法的意义功能点估算法是软件项目管理众多知识中比较有技术含量的一个。在软件项目管理中项目计划制定的优劣直接关系到项目的成败,项目计划中对项目范围的估算又尤为重要。如果项目负责人对项目的规模没有一个比较客观的认识,没有对工作量、所需资源、完工时间等因素进行估算,那么项目计划也就没有存在的意义。第1页/共43页功能点估算法的特点 项目范围的估算在CMMI的“MA”度量分析管理和“PP”项目计划中均有涉及。对软件项目范围的估算有很多种方法,常见的是LOC代码行和FP功能点法。它们之间的区别和关系如下:功能点估算法常用在项目开始或项目需求基本明确时使用,这时进行估算其结果的准确性比较高。假如这

2、个时候使用LOC代码行估算法,则误差会比较大。使用功能点估算法无需懂得软件使用何种开发技术。LOC代码行估算法则与软件开发技术密切相关。功能点估算法是以用户为角度进行估算,LOC代码行估算法则是以技术为角度进行估算。通过一些行业标准或企业自身度量的分析,功能点估算法是可以转换为LOC代码行的。在项目刚开始的时候进行功能点估算可以对项目的范围进行预测。在项目开发的过程中由于需求的变更和细化可能会导致项目范围的蔓延,计算出来的结果会与当初估计的不同。因此,在项目结束时还需要对项目的范围情况重新进行估算,这个时候估算的结果才能最准确反映项目的规模。第2页/共43页功能点分析的步骤 我们将以国际标准I

3、FPUG(InternationalFunctionPointUsersGroup)组织提供的功能点估算法V4.1.1为基础进行讲解。如下图所示,首先大家应该了解功能点估算法的使用步骤。具体步骤包括:识别功能点的类型。识别待估算应用程序的边界和范围。计算数据类型功能点所提供的未调整的功能点数量。计算人机交互功能所提供的未调整的功能点数量。确定调整因子。计算调整后的功能点数量。第3页/共43页识别项目的类型 国际IFPUG组织将软件项目分为三类,功能点估算法适用于任何一类项目:新开发项目二次开发的项目功能增强的项目第4页/共43页识别项目的范围和边界 使用UML的“UseCase”用例图是以用户

4、角度进行识别项目范围和边界的最好方法,在画用例图时就必须明确系统的边界。通过系统的边界,我们可以知道哪些功能要计算功能点,哪些功能点是外部系统负责计算的。以图为例:一个外贸订单系统只包含录入、修改、删除、查询和统计订单的功能,而汇率查询转换服务是不属于该系统的。应用程序边界的识别规则大家一定要牢记,不能从技术角度去思考,必须从用户角度来定义;如果项目牵扯到多个系统,那么必须将这多个系统的边界全部描述清楚。第5页/共43页功能点估算分类 功能点估算法将功能点分为以下5类:ILF:InternalLogicalFile内部逻辑文件EIF:ExternalInterfaceFile外部接口文件EI:

5、ExternalInput外部输入EO:ExternalOutput外部输出EQ:ExternalInquiry外部查询其中,ILF和EIF属于数据类型的功能点,EI、EO、EQ属于人机交互事务类型的功能点。以外贸订单系统项目为例:录入订单、修改订单、删除订单是EI;查询订单是EO统计订单是EQ汇率查询转换系统为EIF订单和客户是ILF第6页/共43页识别功能点的重要原则 软件项目管理中的功能点估算法将功能点分为5类:ILF、EIF、EI、EO和EQ。其中:ILF和EIF属于数据类型的功能点;EI、EO、EQ属于事务类型的功能点。ILF、EIF要与EI、EO、EQ分开计算。对ILF和EIF复杂

6、度的计算可简单理解为对数据库复杂度的计算。对EI、EO、EQ复杂度的计算可理解为对程序开发复杂度的计算。一般软件项目都是由数据和程序构成的,因此计算ILF、EIF和计算EI、EO、EQ之间没有任何关系。第7页/共43页内部逻辑文件与外部接口文件 ILF内部逻辑文件内部逻辑文件是指一组以用户角度识别的、在应用程序边界内且被维护的逻辑相关数据或控制信息。ILF的主要目的是通过应用程序的一个或多个基本处理过程来维护数据。EIF外部接口文件外部接口文件是指一组在应用程序边界内被查询,但在其他应用程序中被维护的、以用户角度来识别的、逻辑上相关的数据。因此,一个应用程序中的EIF必然是其他应用程序中的IL

7、F。EIF的主要目的是为边界内的应用程序提供一个或多个通过基础操作过程来引用的一组数据或信息。EIF所遵循的规则:从用户角度出发识别的一组逻辑数据。这组数据是在应用程序外部,并被应用程序引用的。计算功能点的这个应用程序并不维护该EIF。这组数据是作为另一个应用程序中的ILF被维护的。第8页/共43页ILF和EIF的复杂性计算(1/2)ILF和EIF的复杂性是取决于RET(Recordelementtype)和DET(Dataelementtype)的数量。DET是一个以用户角度识别的、非重复的、有业务逻辑意义的字段。DET计算的规则如下:通过一个基本处理过程的执行,对ILF进行维护,或从ILF

8、/EIF中返回一个特定的、用户可识别的、非重复的字段,那么每个这样的字段算一个DET。例如:添加一个外贸订单时需要保存“订单号码、订单日期、地址、邮编”,那么对于ILF订单来说它的DET就是4个。再如:保存订单时还会保存订单的明细。订单的明细往往作为一个子表进行保存,那么“订单号码”在主表和子表中都同时存在(主外键)。但以用户角度来识别时,存盘操作是一个最小的单位,那么订单号码只能算做一个DET。当两个应用程序维护和/或引用相同的ILF/EIF,但是每个应用程序分别维护/引用它们相应的DET时,这些DET在这两个应用程序的维护/引用中将单独计算。例如,一个应用程序的两个“ElementaryP

9、rocess”基本处理过程都需要使用到“地址”的信息,地址信息又可以细分为“国家、城市、街道、邮编”。那么对于其中一个基本处理过程来说,它将整个地址信息作为一个整体进行处理,只算一个DET;另外一个基本处理过程使用每个地址的详细信息,那么DET就是4个。第9页/共43页ILF和EIF的复杂性计算(2/2)RET是指一个EIF/ILF中用户可以识别的DET的集合。如果把DET简单理解为字段的话,那RET就可以简单理解为数据库中的表。RET在ILF/EIF中分为两种类型:可选的(Optional)和必选的(Mandatory)。计算RET的规则为以下两点:在一个ILF/EIF中每一个可选或必选的集

10、合都被计算为一个RET。如果一个ILF/EIF没有子集合,则ILF/EIF被计算为一个RET。例如:在外贸订单系统中添加一个订单时会保存“订单信息、客户的ID、部门的ID”。那么订单系统ILF中的RET为:订单信息(必选的)客户信息(必选的)部门信息(可选的)因此ILF中RET的个数为3个。ILF/EIF复杂度的矩阵如下:119个个DET2050个个DET超过超过51个个DET1个个RET低低低低中等中等25个个RET低低中等中等高高6个以上个以上RET中等中等高高高高第10页/共43页EI、EO、EQ的比较 EI、EO、EQ的比较EI是处理来自应用程序边界外部的一组数据输入,它的主要目的是维

11、护一个或多个ILF,以及/或者更改系统的行为。EO是输送数据到应用程序边界外部的过程。它的主要目的是通过逻辑处理过程向用户呈现信息。该处理过程必须包含至少一个数学公式或计算方法,或生成派生数据。一个EO也可以维护一个或多个ILF,并/或改变系统行为。EQ是向应用程序边界外发送数据基本处理的过程。其主要目的是从ILF或EIF中通过恢复数据信息来向用户呈现。该处理逻辑不包括任何数学公式或计算方法,也不会生成任何派生数据。EQ不会维护任何一个ILF,也不会改变应用程序的系统行为。EO和EQ的共同点是,其主要目的都是通过基本操作过程展现数据给用户。EI、EO、EQ的比较见下表:第11页/共43页表1

12、EI、EO、EQ的主要目的目的目的EIEIEOEOEQEQ改变应用程序的属性或行为主要目的次要目的不允许维护一个或多个ILF主要目的次要目的不允许显示信息给用户次要目的主要目的主要目的表2 EI、EO、EQ的主要行为行为行为EIEIEOEOEQEQ数学公式或计算被执行可以至少选择一次不可以至少一个ILF被修改至少选择一次至少选择一次不可以至少一个ILF或EIF被引用可选可选必选数据被重新恢复可选可选必选派生数据被创建可选至少选择一次可选应用程序的行为或属性被修改至少选择一次至少选择一次可选准备或呈现信息到系统边界外可选必选必选接受进入系统边界内的数据的能力必须可选可选第12页/共43页事务类型

13、功能点的计算规则(1/3)在IFPUG的定义中有一个重要的单词“ElementaryProcess”基本处理过程。该过程对用户来说是一个有意义的、最小的活动单位,并且是一个自包含的活动。功能点的分类,EI、EO、EQ的识别都是基于“ElementaryProcess”基本处理过程的。EI的计算规则从应用边界之外收到数据。如果进入系统边界内的数据不是一个改变系统行为的控制信息,那么至少一个ILF应该被改变。对于已识别的处理过程,至少满足下面三个条件之一。该基本处理过程的逻辑与本应用系统中其它基本处理过程的逻辑不同。该基本处理过程应该具有唯一性。例如:不能存在两个完全一模一样的存盘操作。在应用程序

14、边界内,该基本处理过程所使用的这组数据应该与其他基本处理过程所使用的数据不同。在应用程序边界内,基本处理过程所引用的ILF或EIF是不同于其它基本处理过程所引用的ILF或EIF。第13页/共43页事务类型功能点的计算规则(2/3)EO和EQ通用计算规则必须全部满足以下内容才能被视为一个EO或EQ:从外部发送数据或控制信息到应用程序边界内。为了识别这个过程,以下三点必须满足一个:该基本处理过程逻辑上必须是唯一的,该唯一性是指其在应用程序中与其他EO或EQ在逻辑性上保持唯一。该基本处理过程所使用的数据应该是唯一的,该唯一性是指其在应用程序中与其他EO或EQ所使用的数据不同。该基本处理过程所引用的I

15、LF或EIF文件应该是唯一的,该唯一性是指其在应用程序中与其他EO或EQ所引用的ILF或EIF文件不同。第14页/共43页事务类型功能点的计算规则(3/3)EO补充的计算规则除了要满足上面的通用规则外,还要满足下面其中一条:在基本操作过程中至少包含一个数学公式或计算方法在基本操作过程中要产生派生数据在基本操作过程中至少要维护一个ILF在基本操作过程中要改变系统的行为。EQ补充的计算规则除了要满足上面的通用规则外,还要满足下面其中一条:基本操作过程从ILF或EIF中获取数据。基本操作过程不能包含数学公式或计算方法。基本操作过程不能生成派生数据基本操作过程不能维护任何一个ILF基本操作过程不能改变

16、系统的行为第15页/共43页EI、EQ和EO的技术复杂性计算复杂性取决于FIRs和DETs的数量。FTR是被一个事物读取或维护的ILF,或者是被一个事物读取的EIF。EI中识别FTR规则每一个ILF应该算做一个FTR。通过EI读取的每个ILF或EIF都应该计算为一个FTR。既被EI维护又被读取的ILF仅计算为一个FTR。EI中识别DET规则在EI的过程中,以用户角度识别的、通过应用系统边界输入系统内部的非重复字段,应算作一个DET。在EI的过程中,只要没有通过系统边界输入,即使它存在于系统内的一个ILF中,也不能算为一个DET。例如:外贸订单系统中,订单的金额是被单价和数量自动计算的,那么金额

17、是没有通过系统边界输入的,因此在EI操作中就不应该算做一个DET。在应用程序的EI操作时,系统提示的错误信息或完成操作的信息,应该被分别计算为一个DET。例如:在网站注册用户信息时,由于输入错误系统会显示提示信息,那么这些提示信息应该被逐个计算为一个DET。再如:当EI操作完成时系统提示并显示出来的信息,应该被计算为一个DET。在EI操作中,如果遇到主外键的字段,应该算作一个DET。第16页/共43页EO和EQ计算FTR的规则1.通用规则:每个在EO/EQ处理过程中读取的ILF和EIF算一个FTR2.EO额外的FTR计算规则:在EO处理过程中每个被维护的ILF算一个FTR在EO处理过程中既被读

18、取又被维护的ILF算一个FTREO和EQ计算DET的通用规则用户可识别的非重复字段,进入应用边界并指明处理什么、何时处理或处理方式,并且由EO/EQ返回或产生,那么这样的每个字段算一个DET。例如:报表中的每个字段都是一个DET。在应用边界内以用户角度识别的非重复字段算一个DET。例如:在报表中起到解释或备注作用的文字信息,不管是一个字、一个词或一段话,都当作一个DET。再如:某种编号或日期,即使它被物理存储在不同字段中,但从用户角度看是一个整体的信息,因此被算作一个DET。还有:在饼图中百分比和分类算作不同的DET。第17页/共43页在EO或EQ操作中,如果对系统进行输入或读取操作时,相同的

19、字段只计算一个DET。例如,在报表查询时,输入的字段在报表上也有显示,那么将算作同一个DET。在应用程序的EO或EQ操作时,系统提示的错误信息或完成操作的信息,应该被计算为DET。例如,用户查询一个列表时被拒绝,那么拒绝的提示信息就算为一个DET。在EO或EQ操作中如果遇到主外键的字段,应该算作一个DET。在EO或EQ过程中,只要没有通过系统边界输入,就算它存在于系统内的一个ILF中,也不能算为一个DET。例如,在公司发工资的时候,员工对应的状态信息被更新,但这个状态信息的更新是没有通过系统边界输入的,因此也不能算做一个DET。页面的标题等类似信息不计算DET。系统字段生成的记号不能被算作一个

20、DET。例如,页码、位置信息、时间、上一页和下一页等信息,都不能算作一个DET。第18页/共43页EI复杂度计算矩阵14个个DET515个个DET多于多于16个个DET0101个个FTRFTR低低中等2 2个个FTRFTR低中等高大于大于2 2个个FTRFTR中等高高EO和EQ复杂度计算矩阵15个个DET619个个DET多于多于20个个DET0101个个FTRFTR低低中等2323个个FTRFTR低中等高多于多于4 4个个FTRFTR中等高高EI、EO、EQ、ILF和EIF技术复杂度对应的功能点如下表所示:低低一般一般高高EIEI346EOEO457EQEQ346ILFILF71015EIFE

21、IF5710未调整前功能点对应矩阵第19页/共43页计算调整因子用功能点估算法计算软件项目功能点时会用到调整因子(或称调整系数)。功能点的调整系数是通过通用系统特性及其影响程度来评定的,对每个常规系统特性的评估由其影响程度(DI)而定,分为05级:0毫无影响1偶然影响2适度影响3一般影响4重要影响5强烈影响然后依次对以下14个系统常规特性进行打分,并带入以下计算公式算出功能点的调整因子。ValueAdjustmentFactor=(sumof(DI)*0.01)+0.65第20页/共43页1.数据通讯 数据通讯指的是应用程序直接与处理器通讯的程度。通常我们都是通过某种通讯手段来实现在一个应用中

22、所使用的数据或者控制信息。连接到本地控制器上的终端被认为是通讯设施;协议则指两个系统或设备之间进行通讯时使用的一种约定。所有的数据通讯链接都需要某种协议。0 0 应用程序是单纯的批处理或者PC stand-alone1 1 应用程序是一种批处理过程,但是包含远程数据的录入或远程打印2 2 应用程序是一种批处理过程,但是包含远程数据的录入和远程打印3 3 应用程序包括在线数据收集或者包括批处理或查询系统的远程处理的前端应用4 4 应用程序不单只是前端应用,但是仅支持一种远程处理通讯协议5 5 应用程序不单只是前端应用,还支持多于一种的远程处理通讯协议第21页/共43页2.分布式数据处理分布式数据

23、处理是应用在内部组件之间传递信息的程度。这个特性是在应用边界内体现的。0 0应用程序不支持组件之间的数据传输和处理功能1 1应用程序为用户可能进行的处理准备数据(例如使用电子表格或者数据库等)2 2应用程序所准备的数据是为了在系统另外一个组件上传输和处理,并非为终端用户所处理。3 3分布式处理和数据传输是在线的,并且是单向的4 4分布式处理和数据传输是在线的,并且是双向的5 5由系统中最恰当的组件动态地执行处理功能第22页/共43页3.性能 性能是吞吐量、处理时间等指标对开发的影响。用户所提出的性能要求将直接影响到系统的设计、实施、安装和支持。0 0用户没有提出性能方面的要求1 1用户提出了性

24、能和设计方面的要求,但不需要采取特定措施2 2响应时间和吞吐量在系统峰值时是关键的,但是不需要采取相应的CPU使用方面的特殊设计。处理的最后期限是在下一个工作日。3 3在任何时候响应时间和吞吐量都是关键的,但是不需要采取相应的CPU使用方面的特殊设计。处理的完成期限比较严格。4 4除了上面一项的要求外,由于对需求的要求比较严格,在设计阶段就要进行性能分析。5 5除了上面一项的要求之外,在设计和实施阶段需要使用性能分析工具来判断性能要求的完成情况。第23页/共43页4.大业务量配置大业务量配置是指计算机资源对应用开发的影响程度。大业务量的运行配置对设计有特殊要求,是必须考虑的一个系统特性。0 0

25、没有提出明确的运行方面的限制1 1有运行方面的限制,但是不需要采取特别的措施以满足运行限制2 2提出了一些安全和时间方面的限制3 3应用程序的某些部分对处理器有特定的要求4 4提出的运行限制对应用的中央处理器或者专用处理器有特殊的要求5 5除上面一项之外,还对应用的分布式组件提出了限制第24页/共43页5.事务处理率事务处理率是业务交易处理速度对系统的设计、实施、安装和支持等的影响。0 0预计不会出现周期性的高峰事务处理期1 1预计会有周期性的高峰事务处理期(例如:每月、每季、每年)2 2预计每周都会出现高峰事务处理期3 3预计每天都会出现高峰事务处理期4 4用户在应用程序需求或者服务级别协议

26、中对事务率要求很高,因此必须在设计阶段进行性能分析。5 5用户在应用程序需求或者服务级别协议中对事务率要求很高,因此必须进行性能分析并在设计、开发和安装阶段中使用到性能分析工具。第25页/共43页6.在线数据输入 在线数据输入是指数据通过交互的方式输入系统的程度。系统中包括在线数据输入和控制信息功能。0 0所有事务都是批处理的1 11%7%的事务是以交互式的方式进行数据录入2 28%15%的事务是以交互式的方式进行数据录入3 316%23%的事务是以交互式的方式进行数据录入4 424%30%的事务是以交互式的方式进行数据录入5 530%以上的事务是以交互式的方式进行数据录入第26页/共43页7

27、.最终用户效率最终用户效率是指对应用的人文因素及使用的便捷程度等的考虑程度。如下功能设计是针对最终用户效率的:页面导航菜单在线帮助或文档光标自动跳转可以滚动在线远程打印预定义的功能键在线做批量提交任务光标可以选取界面上的数据用户使用大量反白显示、重点显示、下划线或其他的标识在线copy用户文档鼠标拖动功能弹出窗体使用最少的界面完成某种商业功能双语言支持(如果选择了这个就算4项)语言支持(如果选择了这个就算6项)0 0以上的一个都不包括1 1包括以上的13个2 2包括以上的45个3 3包括以上的6个或以上,但是没有用户对于效率的要求4 4包括以上的6个或以上,对用户使用效率有较高要求,因而必须考

28、虑用户方面的设计(例如,最少击键次数、尽可能提供默认值、模版的使用)5 5包括以上的6个或以上,用户对效率的要求使得开发人员必须使用特定的工具和流程以判定用户对效率的要求已经被达成第27页/共43页8.在线更新在线更新是指内部逻辑文件ILF被在线更新的程度。应用系统提供在线更新内部逻辑文件的功能。0 0没有在线更新1 1包含13 个控制文件的在线更新。更新的流量低,恢复容易。2 2包含对4 个以上控制文件的在线更新。更新的流量低,恢复容易。3 3包含对主要ILF 的更新。4 4除了3 之外,在设计和实施中要考虑对数据丢失的防范。5 5除了4 之外,大量的数据恢复工作要考虑成本因素,同时包含了高

29、度自动化的恢复流程。第28页/共43页9.复杂处理复杂处理描述了逻辑处理对应用开发的影响程度。它包含以下要素:敏感控制(例如特殊的审核过程)和/或程序特定的安全处理大量的逻辑处理大量的数学处理因为例外处理造成的需要重新处理的情况(例如,由TP中断、数据值缺少和验证失败导致的ATM事务)多种可能的输入/输出造成的复杂处理0 0上面一个都不满足1 1只满足一个2 2只满足两个3 3满足三个4 4满足四个5 5都满足第29页/共43页10.可复用性 应用系统中的应用和代码经过特殊设计、开发和支持,可以在其他应用系统中复用。0 0没有可复用的代码1 1代码在应用之内复用2 2应用中被其他用户复用的部分

30、不足10%3 3应用中被不止一个用户使用的部分超过10%4 4应用遵从一种易于复用的方式被打包和文档化。用户在源代码级客户化该应用。5 5应用按照一种易于复用的方式被打包和文档化。用户使用用户参数来对该应用进行客户化。第30页/共43页11.易安装性 易安装性指应用系统的转换和安装容易度对开发的影响程度。系统测试阶段提供了转换和安装计划/转换工具。0 0用户对安装没有特定的要求1 1用户对安装没有特定的要求,但有特定的安装环境要求2 2用户提出了安装和转化的要求,转化/安装指南被经过测试提供给用户。但是转化的影响对该应用不重要。3 3用户提出了安装和转化的要求,转化/安装指南被经过测试提供给用

31、户。转化的影响对该应用来说是重要的。4 4除了2 的要求之外,需要提供经过测试的自动化的安装和转化工具。5 5除了3 的要求之外,需要提供经过测试的自动化的安装和转化工具。第31页/共43页12.易操作性 易操作性指的是应用对运行的影响程度,如有效启动、备份和恢复规程的影响。易操作性是应用提供的一种特性,它最小化了手工操作的要求。0 0用户没有指定除正常备份程序外的其它特定操作1 1提供高效的启动、备份和恢复进程,但需要人手操作2 2提供高效的启动、备份和恢复进程,不需要人手操作(当作两项计算)3 3应用程序对磁带的需求最小化4 4应用程序对硬拷贝处理的需求最小化5 5程序设计成无人操作模式。

32、无人操作模式的意思是除了启动和关闭之外,不需要对系统进行操作。程序的其中一个功能就是错误自动恢复。第32页/共43页13.多场地多场地指应用系统经特殊设计、开发可以在多个组织、多个地点应用的程度。0 0用户需求不含多场地和组织的要求1 1考虑了多场地的要求,但是设计要求应用在不同的场地使用相同的软硬件环境2 2考虑了多场地的要求,但是设计要求应用在不同的场地使用类似的软硬件环境3 3考虑了多场地的要求,同时设计支持应用在不同的场地使用不同的软硬件环境4 4在1 或者2 的要求之上,提供了经过测试的多场地的文档和支持计划5 5在3 的要求之上,提供了经过测试的多场地的文档和支持计划第33页/共4

33、3页14.支持变更 支持变更是指应用在设计上考虑支持处理逻辑和数据结构变化的程度。可以具有如下的特性:提供可以处理简单要求的弹性查询和报告功能,如对一个ILF进行与(或)逻辑提供可以处理一般复杂度要求的弹性查询和报告功能,如对多于一个的ILF进行与(或)逻辑(当作两项计算)提供可以处理复杂要求的弹性查询和报告功能,如对一个或多个ILF进行与(或)逻辑的组合(当作三项计算)业务控制数据被保存到用户通过在线交互进程维护的表中,但变更只会在第二个工作日生效业务控制数据被保存到用户通过在线交互进程维护的表中,且变更即时生效0 0一个都不满足1 1合计满足一个2 2合计满足二个3 3合计满足三个4 4合

34、计满足四个5 5合计满足五个第34页/共43页计算调整后的功能点个数国际IFPUG组织将软件项目分为三类,功能点估算法适用于任何一类项目,其计算公式中的术语请详见表1。功能点的原始计算公式:FPCount=UFP*VAF新开发项目:有时新开发的软件项目也需要与其他现存的软件系统进行整合。例如:一个企业新开发的MIS内部管理系统经常会与财务系统进行整合。这时除了考虑本身项目的功能点个数外,还要考虑系统整合或数据迁移部分的工作量。因此,其功能点计算公式如下:FPCount=(UFP+CFP)*VAF二次开发的项目:有时新开发的软件项目是在原有基础上进行二次开发的,只是为了增加一些新功能。因此,其功

35、能点计算公式如下:FPCount=ADD*VAF功能增强的项目:功能增强项目的功能点估算比较复杂。在计算功能点前大家需要计算有哪些是新增加的功能,哪些是被修改的功能,哪些是属于数据迁移或系统整合的功能。然后计算新系统技术复杂度的调整因子“VAFA”,并在此基础上计算系统功能点的数量。当然,此类项目也会去掉一些原有功能,那么在原有系统的技术复杂度基础上重新计算功能点的调整因子“VAFB”,再计算所去掉功能贡献的功能点数量。因此,其功能点计算公式如下:FPCount=(ADD+CHGA+CFP)*VAFA+(DEL*VAFB)第35页/共43页术语术语英文英文中文含义中文含义ADDAdded fu

36、nctionality被添加的功能点个数CFPConversion functionality被转换的功能点个数CHGAUFP of changed functionality after enhancement功能增强后所改动的功能所贡献的未调整的功能点个数DELDeleted functionality被删除的功能点个数UFPUnadjusted functional point count未调整的功能点个数VAFValue adjustment factorVAF=(sum of(DI)*0.01)+0.65功能点的调整因子的计算公式VAF=(sum of(DI)*0.01)+0.65V

37、AFAValue adjustment factor after enhancement功能增强后的功能点调整因子VAFBValue adjustment factor before enhancement功能增强前的功能点调整因子表1.功能点技术公式术语第36页/共43页举例以员工管理系统为例,详细说明如何利用功能点估算法计算业务复杂度。在员工管理系统中添加一个员工资料,会使用到员工的一般信息、教育情况、工作经历和家属信息。员工隶属于某个部门,在本系统中会有一个对部门进行维护的功能。员工的工资则由另外一个财务系统提供。其用例图如图:假设员工基本信息如下所示:员工ID(标签控件)员工名称性别生

38、日婚否所属部门ID(标签控件)所属部门名称受教育的时间学校名称所学专业工作时间工作单位工作部门工作职务亲属的姓名之间关系亲属年龄工作单位假设部门信息如下所示:部门ID(标签控件)部门名称假设工资表信息如下所示:员工ID(标签控件)员工姓名金额单位第37页/共43页ILF和EIF的功能点数本范例识别出来ILF和EIF功能点个数如下表所示。ILF内部逻辑文件RETDET个数复杂度未调整的FP个数员工信息员工基本信息、受教育情况、工作经历、亲属信息,共4个。18低7部门信息部门基本信息,共1个。2低7EIF外部接口文件RETDET个数复杂度未调整的FP个数工资表员工基本信息、工资信息,共2个。4低5

39、合计:19个第38页/共43页EI、EQ和EO的功能点数本范例识别出来EI、EQ和EO功能点个数如下表所示。EIEIFTRFTRDETDET个数个数复杂度复杂度未调整的未调整的FPFP个数个数添加员工信息员工、部门、工资表18个员工信息的两个标签控件内容不是用户输入的,因此不算,共16个;部门信息与员工信息中的部门字段重复,因此一个都不算;工资表中的员工ID和名称不能重复,因此只能算金额和单位,所以共2个。高6修改员工信息员工、部门、工资表18个同上高6删除员工信息员工、部门、工资表1个员工ID中等4添加部门信息部门1个一个标签控件的内容不是用户输入的,因此不算低3修改部门信息部门1个一个标签

40、控件的内容不是用户输入的,因此不算低3删除部门信息部门1个部门ID低3合计:25个第39页/共43页EQEQFTRFTRDETDET个数个数复杂度复杂度未调整的未调整的FPFP个数个数查询员工信息员工、部门、工资表20高6查询部门信息部门2低3合计:9个EOEOFTRFTRDETDET个数个数复杂度复杂度未调整的未调整的FPFP个数个数统计员工年薪员工、工资表员工ID、员工名称、年份、年薪、单位共5个低4合计:4个第40页/共43页本系统的通用系统特性及其影响程度如下表所示:系统特性系统特性分数分数数据通讯3分布式数据处理2性能0高强度配置0交易速度0在线数据输入5最终用户效率2在线更新3负责

41、的处理0可复用性3易安装性0易操作性0多场地0支持变更1合计:19调整因子=19*0.01+0.65=0.84最终调整后的功能点数量为:(19+25+9+5)*0.84=48.72个第41页/共43页总结功能点估算法是一个非常有用的对软件规模进行估算的国际通用技术,是项目管理人员必须掌握的工具。为了便于大家对功能点的技术进行理解和记忆,这里对其进行总结:由于计算机软件就是为了实现无纸办公,那么在估算功能点时应该多以用户的纸质表单为依据,每个表单就是一个ILF或EIF,表单上显示的字段都是DET,一个表单上的“核心”内容不管是由几个数据表来分别存放数据的,每个表都是一个RET。简单来讲,ILF和

42、EIF可以被看作数据库中的数据表,但是主、从表将被视为一个ILF或EIF。那么,ILF和EIF的复杂度就是由数据表中的字段DET和一个ILF或EIF自身所包含的主、从表个数RET来决定。在计算DET时主、外键只能算作一个。EI就是对应用户增加、修改、删除的操作,EO和EQ都是用于用户查询的操作。EO和EQ的区别是,EO查询时使用了数学公式或计算方法。EI、EQ和EO的复杂度是由FTR和DET决定的。FTR的个数由ILF和EIF的个数决定,可以由主表中主、外键的个数来计算。在计算EI的DET时,只有用户在界面上直接输入的信息才算作DET,通过页面自动计算或转换的数据不能算作EI的DET。在EO和EQ计算DET时,报表的标题、页码等信息不能被计算为一个DET。第42页/共43页谢谢您的观看!第43页/共43页

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 应用文书 > PPT文档

本站为文档C TO C交易模式,本站只提供存储空间、用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有。本站仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知淘文阁网,我们立即给予删除!客服QQ:136780468 微信:18945177775 电话:18904686070

工信部备案号:黑ICP备15003705号© 2020-2023 www.taowenge.com 淘文阁