FPA学习笔记.docx
- 文档编号:13984125
- 上传时间:2023-06-19
- 格式:DOCX
- 页数:37
- 大小:101.67KB
FPA学习笔记.docx
《FPA学习笔记.docx》由会员分享,可在线阅读,更多相关《FPA学习笔记.docx(37页珍藏版)》请在冰点文库上搜索。
FPA学习笔记
FBA学习笔记
——welkinhu.blog.51cto/447606/114781
一.功能点分析方式概述
1.什么是功能点分析法(FPA)
功能点分析法,简称FPA,与代码行分析法是最近几年来最流行的两种基础软件规模估算和气宇方式。
代码行估算法偏重技术角度,需要必然的基准数据支撑。
基准数据越多,估算难度较小。
代码行估算法与实现的技术,运算机语言紧密相关。
功能点分析法偏重功能,在基准数据缺乏时也能进行,只是估算流程比较复杂。
它完全独立于技术,且能够给用户量化的概念。
那个地址所说的功能点分析法,由AllanJAlbrecht第一提出,又称Albrecht功能点分析法。
除此之外,还有MarkIIFPA和完全功能点等。
但适应上,人们说的功能点分析法确实是Albrecht功能点分析法。
1.1功能点分析法的概念
官方文档IFPUGCPM4.2.1给出功能点分析法的概念是:
Functionpointanalysisisastandardmethodformeasuringsoftwaredevelopmentfromtheuser’spointofview.
具体来讲,FPA有这么几个特点:
l它是一种适用于软件开发的气宇方式。
l它是一种标准的气宇方式,由国际功能点用户组(IFPUG)保护和推动。
l它从用户视角来气宇产品规模。
l它不注重产品的内部结构和技术复杂度。
只是也并非完全无视这些因素。
FPA标准的保护组织是国际功能点用户组IFPUG(ifpug.org),它不按期的发布CountingPracticesManual,简称CPM来统一不同公司和产品的功能点计算模型。
这套模型基于大量已完成项目的分析数据,超级全面和精准。
关于同一个产品,不同的公司,不同的人,参照CPM计算出来的功能点数应当是一样的。
目前最新版本是2005的CPM4.2.1,此刻三年未更新,计算模型已相当做熟。
1.2.功能点的概念
什么是功能点?
确实是客户提出的一条条的需求吗?
答案是不是定的。
在FPA中,客户提出的需求,是功能,功能组和产品;但不是功能点。
l功能点是一个的气宇单位,用于气宇工作产品的规模。
就像千克和千米一样,仅仅是一个抽象化的单位。
l功能点不直接气宇软件的内部架构和技术复杂度。
l单个功能点对用户没成心义,但一个功能包括多少个功能点对用户成心义。
l一个系统,一个功能包括多少个功能点,是由一系列可见的要素分析计算得来,而不是拍脑袋的体会数字。
功能点分为两种:
未调整功能点和调整功能点。
未调整功能点是只记用户可见功能的中间结果,调整功能点是最终结果,在未调整后功能点基础上加入了系统实现和内部架构方面的因素。
一样说一个系统包括多少个功能点,是指调整功能点。
1.3.那些功能是用户可见的?
简而汇之,如下功能是用户可见的。
lGUI,如页面和窗体。
l报表。
l要紧文件。
l参考文件,引用文件。
l操纵文件。
l数据输入。
2.什么缘故利用功能点分析法
FPA能够应用于所有的软件项目和软件身,包括新开发项目,升级项目,应用程序,保护项目等。
FPA的大体目的有两个:
l气宇用户要求和接收到的功能
l为软件的开发和保护而气宇其技术独立度。
2.1.功能点分析法的用途
软件气宇的用途超级普遍,从客户,老板,治理人员,到程序员,都需要软件气宇数据。
FPA作为一种软件气宇方式,要紧有三方面的用途:
持续的进程改良,软件资产治理,项目治理。
2.1.1.持续的进程改良
FPA支持用于软件质量分析与生产力分析的量化指标,比如每功能点的平均bug数,每功能点的平均人天数,等等。
分析这些量化指标,能够找到进程改良的机遇;能够气宇改良的成效。
不管是组织仍是个人,都需要持续的进程改良。
具体来讲,FPA可那个进程中发挥如下作用:
为现状提供基线数据。
1)为改良决策提指明方向。
2)为具体行动提供指南。
3)气宇改良的结果。
4)将改良的结果基线化,进入下一轮改良。
可能改良的机遇,英语是ImprovementOpportunities。
那个地址的Opportunities用的专门好,可惜中文的译词“机遇”很难让人明白得。
适应上是说“值得改良的地址”。
2.1.2.软件资产治理
FPA为组织的软件资产提供了量化的指标。
l软件资产的总规模
l软件资产的增加率
l软件资产的保护本钱
l软件资产的代换本钱
关于软件开发和效劳组织,这些指标可为软件资产的保护策略提供决策依据:
是从头开发,重构系统,重写代码但不改结构,仍是继续保护。
关于利用软件的组织,这些指标可作为采购的参考:
是自行开发,仍是采购?
采购的合理价钱区间,目标采购包的功能符合度。
FPA为应用软件之间的功能比较提供了标准化指标。
2.1.3.项目治理
(1)估算开发或保护的本钱,资源,为项目打算提供依据。
(2)估算需求变更的本钱和对项目的阻碍。
(3)操纵需求范围。
2.2.功能点分析法的优势
l基于概念良好的计算标准。
l基于客户视角。
容易明白得和同意。
l可应用于新项目,升级项目和保护项目。
l与技术和运算机语言无关。
l简单,易于计算,只需花费较少的工作量。
l一致的规模气宇尺度。
可用来比较不同组织和技术之间的比较。
2.3.功能点分析法的缺点
l只考虑可见部份的复杂度,对系统内部复杂性考虑太少。
l功能复杂度三级划分比较武断。
对一些比较复杂的功能,统计误差较大。
lFPA知识简单假设全数是部份的和,没有考虑系统集成带来的额外开销。
在FPA的基础上,还有一种MARKII功能点分析法,它能克服一些功能点法的缺点。
2.4.功能点分析法的气宇描述举例
(1)今年咱们的生产率提高了20%,从每一个月10个功能点提高到12个功能点。
(2)通过质量检视,咱们交付的软件缺点率由每功能点2个缺点,减少到每功能点0.5个缺点。
(3)咱们的项目进度估算准确率显著提高,实际人天数和估算人天数的误差+45%减小到+15%。
(4)咱们的应用软件包对相关业务的支持增加了10%,原先是50K功能点,此刻是55K功能点.
(5)由于咱们调整了保护策略,工程师人均保护的功能点数从1000提高到1500.从而节省了$3M的本钱
(6)由于提高了客户需求技术,咱们把需求蔓延率从35%降到10%。
(7)依照功能点分析的结果,咱们购买一个软件包,比自己开发节省了$1M.
3.功能点分析法与软件生命周期
功能点分析必需渗透于作为软件生命周期的全数,而不单单是项目开发时期。
不同时期的功能点分析有不同的目的,参与人员和相关材料。
3.1.软件生命周期
FPA将软件生命周期划分为六个时期,与通常意义的软件生命周期大体相同。
只只是有些具体名称上不同。
比如:
方案时期又叫概念时期,构建时期又叫实现时期。
构建时期
Construction
交付时期
Delivery
保护时期
Maintenance
设计时期
Design
需求时期
Requirement
方案时期
Proposal
有四个时期应当进行功能点分析:
方案时期,需求或设计时期,交付时期,保护时期。
每一个时期的功能点分析都有不同的目的。
FPA不是某一个人的工作,而是整个团队的工作。
不管哪个时期的FPA,都需要多种角色的参与。
要紧参与角色有:
l客户或客户代表
l项目领导
l系统架构师
l程序员(方案时期可能没有程序员)
l文档专家:
负责整理文档的苦力。
l应用方案领导:
可能是项目领导,也可能治理好几个项目领导。
l应用方案专家:
估量Reviewer,挑刺的家伙。
l气宇分析员:
可能和文档专家是同一个人。
l功能点分析专家:
一样是QA,主持分析进程。
l功能点委员会:
估量是Reviewer,挑刺的家伙。
每次进行FPA时,除需要相应的项目文档外,还建议预备好如下FPA的指导文档:
nIFPUGCountingPracticesManual
n所在组织的FAP指导文档。
nFPA分析表。
n自制一张简明指南卡:
QuickReferenceCard。
3.2.在方案时期估算功能点
在方案时期后期,能够采纳FPA方式来估算软件的规模和项目的开发本钱。
具体来讲有三个目的:
lFPA的进程可协助两边(用户和开发人员)把高层需求层次化。
l取得较为明朗的项目的范围。
l粗略的估算功能点数,并折算为开发本钱和进度。
为制定项目打算提供依据。
在现在期只有一些超级原始,抽象的客户需求。
因此估算的精度有限。
现在期可参考的项目文档有:
l高层需求文档
n高层系统架构(功能,数据存储,接口)。
n高层逻辑数据模型。
n高层业务模型。
n业务用例(可选)。
l历史项目或应用软件的功能点统计数据(可选)。
3.3.需求或设计时期二次估算功能点
在完成需求规格或概要设计时,如发觉需求和范围较之方案时期有较大的转变,估算的功能点不够精准,可在设计时期的进行二次估算。
其目的有三:
l从头概念客户需求。
l从头估算开发进度和本钱。
l气宇项目范围的变更,如需求蔓延率。
事实上,只要项目范围发生了大的转变,就应当从头估算,最好不要超过三次。
在设计完成后,项目范围已经基线化,如发生需求变更,只需估算变更部份,不要全数推到重来。
二次估算,除需要第一次估算的所有文档外,还需要如下项目文档:
l需求规格。
n业务用例
n屏幕界面计划(Layout)
n报表计划(Layout)
n文件和数据库计划(Layout)
n数据流:
系统接收和发出的数据。
l功能设计,也确实是概要设计。
3.4.交付时期气宇最终功能点
交付时期,所有的开发工作都已终止,需求和功能设计自然也就全数冻结。
现在应进行最终的实际功能点气宇。
其目的有四:
l在交付文件中报告实际的功能点数。
l气宇项目范围的变更,如需求蔓延率。
l回忆项目实施情形。
l发布统计数据,作为组织的基线。
气宇功能点,需要参考项目的全数需求和设计文档。
同二次估算相较,可能增加了如下文档:
l功能设计规格。
l详细设计规格。
l用户手册。
3.5.保护时期气宇资产功能点
系统交付后,就会进入公司的IT资产库。
现在需要从资产治理的角度气宇一些数据。
l审计资产功能点。
l文档化。
l确信保护策略。
二.FPA流程概述
1.计算功能点的整体流程
FPA的计算流程比较复杂,要紧分为三大步骤:
概念分析目标;计算未调整功能点;计算调整功能点。
具体图示请参见图一。
图表1FPA计算流程
FPA的要紧步骤如下:
1)决定分析类型和目的:
开发项目、升级项目、应用。
小特性开发属于应用类型。
2)识别分析范围和应用边界。
3)计算未经调整的功能点数UPFC。
(1)列出系统的所有功能,包括数据功能和处置功能。
(2)计算每一个功能的功能点。
i.识别该功能的类型:
ILF、EIF、EI、EO、EQ。
ii.统计该功能包括元素的数量。
数据功能统计DET和RET;处置功能统计DET和FTR。
iii.依照该功能包括元素的数量,和相应功能类型的复杂度矩阵,确信其复杂度。
iv.依照相应功能类型的复杂度和功能点对照表,找到改功能的功能点数。
(3)统计所有功能的功能点总和。
(4)确信调整系数。
依照14个GSC确信VAF。
(5)计算调整后的功能点:
AFP=UPFC*VAF
1.1.概念分析类型
FPA可应用于各类软件项目和应用系统。
关于不同的项目和系统,FPA计算流程是一样的,但一些具体算法和规那么上各有不同。
FPA的目的也不尽相同。
分析类型有三种:
l新开发项目DevelopmentProject
估算或气宇系统的所有新功能点,包括新增的或系统切换的功能。
气宇的目的有:
n概念需求
n为项目打算提供估算数据:
工作量,本钱,人员,进度。
n气宇质量。
n气宇生产率。
l升级项目EnhancementProject
估算或气宇系统中转变的功能点,包括新增,改变,减少和系统切换的功能。
l应用软件Application
官方概念是气宇已安装的应用软件的功能点。
Appliction是指已经交付或从第三方取得的软件、软件包。
小软件工具的开发也可算作应用类型。
每次新开发项目完成后,都应当把交付的系统按应用软件气宇一次。
气宇应用软件的目的有:
l作为升级项目的基线。
l气宇软件质量
l确信保护策略
l确信保护的生产率
三种类型的分析关系如以下图所示。
图表2项目FPA与应用FPA的关系
1.2.概念范围边界
FPA是从用户视角和系统见交互的角度来分解功能。
只有严格的界定了分析的范围和边界,才能专门好的识别和分解功能。
基于用户视角概念边界,用户能够明白得和描述边界。
l相关应用之间的边界是由用户看到的不同功能区域划分,而不是由技术考虑来划分。
l应用之间的初始边界可不能因为功能点分析而改变。
概念边界的技术
l取得一个系统的流程图,在系统周围画上边框,作为边界。
l观察数据的保护方式。
l观察数据的应用范围。
2.计算未调整功能点UFPC
未调整功能点是从具体功能的复杂度计算取得,它包括三个步骤:
分解功能,分析功能的复杂度,依照复杂度确信功能点数。
2.1.识别,分解具体功能
所有系统的具体功能都可分为两种:
数据功能和处置功能。
正确识别出数据功能和处置功能的数量是FPA的关键。
l数据功能:
指为知足用户数据需求而提供的功能。
它以文件为单位计数。
文件分为两类:
ILF和EIF。
n内部逻辑文件ILF:
系统内部保护的文件,如系统创建和更新的文件。
n外部接口文件EIF:
被目标系统应用,但由外部系统保护的文件。
l处置功能:
指为知足用户通过系统处置数据或操纵信息而提供的功能。
它以处置元为单位计数。
处置必然是发生在系统边界内外的一个交互进程,可分为三种:
EI,EO和EQ。
n外部输入EI:
指处置来自系统外的文件的处置元。
它的大体目的是保护一个或多个ILF,或改变系统的行为。
n外部输出EO:
指把文件发送到系统外的处置元。
他的大体目的是给用户提供处置的结果。
EO包括至少一个逻辑处置运算进程。
n外部查询EQ:
EQ也是指把文件发送到系统外的处置元。
它的大体目的是为用户获取指定的信息。
EQ部包括逻辑处置运算进程。
请注意,FPA是从用户角度分析系统的。
那个地址的文件和处置元也是从用户角度来概念的,完全与实现技术无关。
特被是文件,必然要时刻记住他仅仅是一组数据,与运算机文件没有关系。
l文件:
一组用户可识别的,有逻辑关联的数据或操纵信息。
它不必然运算机系统实际产生,存储或利用的文件。
l处置元:
对用户成心义的最小活动单元。
它与实际程序中的方式,进程和API无关。
2.2.确信具体功能的复杂度
关于具体的文件和处置元,FPA采纳三个指标气宇其复杂度:
RET,DET和FTR。
这些指标都是直观的,可计量的。
其中文件用RET和DET来气宇,处置元用DET和FTR来气宇。
l记录元素类型RET:
在一个文件内,一个用户可识别的数据元素组。
l数据元素类型DET:
用户可识别的,不重复的字段。
l引用文件类型FTR:
处置涉及到的文件,包括读取,更新和修改的文件。
FPA给概念术语的名称都比较冗繁。
个人感觉把这三个术语中的“类型(Type)”去掉,会更易懂。
那个地址的“类型(Type)”都是强调对相同的东西不能重复计算的。
比犹如一个ILF中的两个RET都包括同一个DET,只能记为一个DET。
2.3.数据功能点权重矩阵
关于每一个文件(ILF或EIF),FPA是依照其复杂度来确信其功能点数。
复杂度又依照文件所含的DET和RET的数量分为三级:
低,中(平均)和高。
表格1文件功能点计算矩阵
DET个数
RET个数
1-19
20-50
>=50
复杂度
ILF功能点数
EIF功能点数
1
低
低
中
低
7
5
2-5
低
中
高
中
10
7
>=6
中
高
高
高
15
10
2.4.处置功能点权重矩阵
同数据功能点类似,处置功能点也是依照三级复杂度确信的。
而每一个处置元的复杂度依照DET和FTR计算得来。
但EI、EQ和EO三者的计算方式不尽相同。
表格2处置元复杂度矩阵
EI复杂度
EQ、EO复杂度
DET个数
RET个数
1-4
5-15
>=16
DET个数
RET个数
1-5
6-19
>=20
1
低
低
中
1
低
低
中
2
低
中
高
2-3
低
中
高
>=3
中
高
高
>=4
中
高
高
从表中可见一样文件作为输入要比输出的复杂度高。
表格3处置元功能点计算表
复杂度
低
中
高
EI、EQ功能点数
3
4
6
EO功能点数
4
5
7
2.5.汇总未调整功能点
把系统中所有ILF,EIF,EI,EO,EQ的功能点数汇总,确实是系统的总的未调整功能点数UFPC。
3.计算调整功能点AFP
未调整功能点数是从用户角度计算得出的,完全没有考虑不同系统或不同功能的实现复杂度。
FPA通过度析14个通用系统特性(GSC)对系统的阻碍程度(DI)得出每一个系统的功能点值调整因子VAT。
最后依照VAF调整功能点数,得出在系统和功能点可类比的调整功能点数。
UFP、VAT和AFP三者的关系是:
AFP=UFP*VAT
请注意,一个系统只有一个VAT,它是所有14个GSC分析汇总的结果。
3.1.通用系统特性GSC
GSC是由IFPUG统一指定的标准。
一共有14种GSC,适用于所有类型的系统和项目。
(1)数据通信(DataCommunications)
(2)散布式数据处置(DistributedDataProcessing)
(3)性能(Performance)
(4)利用强度高的配置(HeavilyUsedConfiguration)
(5)事务速度(TransactionRate)
(6)在线数据输入(OnlineDataEntry)
(7)最终用户的效率(End-UserEfficiency)
(8)在线更新(OnlineUpdate)
(9)复杂的处置(ComplexProcessing)
(10)可重用性(Reusability)
(11)安装的简易性(InstallationEase)
(12)运行的简易性(OperationalEase)
(13)多场地(MultipleSites)
(14)许诺变更(FacilitateChange)
3.2.阻碍程度DI和TDI
GSC对系统的阻碍程度分为6级,从0到5。
各级概念如下:
0不存在或没有阻碍
1偶然的阻碍
2轻微的阻碍
3中等的阻碍
4显著的阻碍
5强烈的阻碍
IFPUG针对每一中GSC,给出了详细的DI品级指南。
关于一些实在没有参考品级标准,用户也能够自己概念。
把14种GSC的DI都加起来,就取得系统的总阻碍程度TDI,即:
TDI=∑(DI)
3.3.值调整因子VAF
在得出TDI后,VAF按如下公式计算。
VAF=(TDI*0.01)+0.65。
VAF只能在正负35%的范围调整功能点数。
AFP=UFP*VAT
4.不同项目的调整功能点AFP
4.1.开发项目功能点
DFP=(UFP+CFP)*VAF
lDFP:
开发项目功能点。
lUFP:
项目应用的UFPC。
lCFP:
额外的转换功能的UFPC。
lVAFA:
调整系数。
4.2.升级项目功能点
EFP=(ADD+CHGA+CFP)*VAFA+DEL*VAFB
lEFP:
升级项目功能点。
lADD:
升级项目新增UFPC。
以升级后项目为基准。
lCHGA:
升级项目改变的UFPC。
以升级后项目为基准。
lCFP:
额外的转换功能的UFPC。
lVAFA:
升级后的调整系数。
lVAFB:
升级前的调整系数。
lDEL:
升级项目中删除的UFPC。
4.3.应用功能点
AFP=ADD*VAF
lAFP:
应用功能点
lADD:
安装的功能UFPC。
lVAF:
调整系数。
4.4.升级应用功能点
AFP=[(UFPB+ADD+CHGA)–(CHGB+DEL)]*VAFA
lAFP:
应用功能点
lADD:
安装的功能UFPC。
lVAFA:
调整系数。
lUFPB:
升级前的UPFC。
lCHGA:
升级后改变的UFPC
lCHGB:
升级前改变的UFPC?
!
5.附录
5.1.气宇功能点的工作量
很多公司不能推行FPA,并非主观上以为它没用。
其要紧缘故有二:
1.没有FPA的专家指导,不知从何做起,如何持续。
2.迫于项目进度压力,担忧FPA带来大量额外的工作量。
那个地址就推行FPA带来的额外工作量,给出一些参考数据。
大多数组织是平均每小时估算出100个功能点。
具体如下:
项目/应用系统的规模
很小
小
中
大
很大
功能点数
5-20
20-100
100-500
500-1k
10k-100k
C++代码行
256~1k
1k~5k
5k~26k
26k~500k
500k~5M
开发工作量
0.5人天~1人月
1人月~10人月
10人月~72人月
72人月~200人年
200人年~8k人年
FPA工作量
15分钟~30分钟
30分钟~1小时
1小时~5小时
5小时~100小时
100小时~1K小时
5.2.推行FPA的建议
应当做的情形
l取得老板的支持和指导。
l是气宇成为每一个人工作的一部份。
l安排专人总管和支持气宇活动,不必然是全职。
l培训技术人员和用户。
让用户有功能点的概念。
l关注在项目团队的收益上,不要一上来就资产治理什么的。
l提供自动化的支持。
l与组织的进程模式整合。
l气宇的结果应当发布出来,并取得利用。
不该当做的情形
l不要感觉气宇可有可无,或不可达到。
l不要苛求完美的气宇系统和环境。
l不要依托不准确的数据。
l不要用于衡量个人的绩效。
5.3.术语表
术语
英文
中文
说明
FPA
FunctionPointAnalysis
功能点分析法
UFP
UnadjustedFunctionPoint
未调整功能点
AFP
AdjustedFunctionPoint
调整功能点
VAF
ValueAdjustedFactor
值调整因子
ILF
InternalLogicFile
内部逻辑文件
EIF
E
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- FPA 学习 笔记