FPA学习笔记.docx
《FPA学习笔记.docx》由会员分享，可在线阅读，更多相关《FPA学习笔记.docx（37页珍藏版）》请在冰豆网上搜索。
FPA学习笔记
FBA学习笔记
——
一．功能点分析方法概述
1.什么是功能点分析法（FPA）
功能点分析法，简称FPA，与代码行分析法是近年来最流行的两种基础软件规模估算和度量方法。
代码行估算法侧重技术角度，需要一定的基准数据支撑。
基准数据越多，估算难度较小。
代码行估算法与实现的技术，计算机语言密切相关。
功能点分析法侧重功能，在基准数据缺乏时也能进行，不过估算流程比较复杂。
它完全独立于技术，且可以给用户量化的概念。
这里所说的功能点分析法，由AllanJAlbrecht首先提出，又称Albrecht功能点分析法。
除此之外，还有MarkIIFPA和完全功能点等。
但习惯上，人们说的功能点分析法就是Albrecht功能点分析法。
功能点分析法的定义
官方文档给出功能点分析法的定义是：
Functionpointanalysisisastandardmethodformeasuringsoftwaredevelopmentfromtheuser’spointofview.
具体来说，FPA有这么几个特点：
l它是一种适用于软件开发的度量方法。
l它是一种标准的度量方法，由国际功能点用户组（IFPUG）维护和推动。
l它从用户视角来度量产品规模。
l它不注重产品的内部结构和技术复杂度。
不过也并非完全无视这些因素。
FPA标准的维护组织是国际功能点用户组IFPUG（http:
//www.ifpug.org），它不定期的发布CountingPracticesManual，简称CPM来统一不同公司和产品的功能点计算模型。
这套模型基于大量已完成项目的分析数据，非常全面和精确。
对于同一个产品，不同的公司，不同的人，参照CPM计算出来的功能点数应当是一样的。
目前最新版本是2005的，现在三年未更新，计算模型已相当成熟。
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个缺陷，减少到每功能点个缺陷。
（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只能在正负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
开发工作量
人天~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
ExternalInterfaceFile
外部接口文件
EI
ExternalInput
外部输入
EO
ExternalOutput
外部输出
EQ
ExternalQuery
升级会员 