专题1功能点分析法
行政案例分析整理

100 年的历史,它初创于20 世纪30 年代中期的美国,40 年代正式确立。
就是运用一定的方法和技巧,通过直接或者间接的途径,以结构简洁紧凑的书面形式,把一个个真正的行政活动情景描述出来,供教学或者研究之用,从而提高学员分析问题和解决问题的能力。
(1)行政案例的公共性和公务性(2)行政案例涉及范围广、包容量大(3)行政案例的编排和分类具有相对性(4)行政案例的分析无统一的模式和格式4 单个型探索性案例、单个型描述性案例、单个型解释性案例、多重型探索性案例、多重型描述性案例、多重型解释性案例共六种行政案例类型。
规范型行政案例、决策型行政案例、评述型行政案例成功型、失败型、成败参合型它主要通过再现一个行政管理的问题或者情景,要求学生运用行政学中某一特定的概念、原则、理论或者方法来进行分析。
这种行政案例较好地贯彻了理论联系实际的教学原则,能培养学生运用某个特定的理论、方法去分析实际问题的能力,从而达到检验所学理论和加深对理论理解的目的7 、就是针对某一行政管理情景提出的问题,要求学生独立思量,提出解决这一问题的对策和办法。
一、提供实际知识的功能二、为案例使用者提供一个集思广益的机会三、有助于提高学生分析问题的能力和作出决策的能力四、有助于加深对行政学理论和方法的理解及运用五、有助于培养学生学习的主动性、创造性和参预性六、有助于培养学生对行政管理活动的敏锐性和适应性七、提高在职行政人员的素质,改进行政工作八、有利于促进行政学理论的发展以及学姐与政界的联系(一) “教练员”的角色:根据不同的案例类型选择不同的讨论方式(二) “导演”的角色:引导和控制课堂讨论进程(三) “书记员”的角色:做好课堂讨论记录和小结(一)做好案例课堂教学前的准备工作(二)积极参预课堂案例讨论(三)主动聆听别人的发言(四)认真听取教师对案例讨论的总结(五)撰写案例分析报告(一)专题分析法(二)综合分析法(三)讨论分析法第三章一是让学习者满意,这是最重要的一条原则。
软件功能点介绍

– 计算功能点
– FPC=UFP*VAF
• 示例一
示例
功能点应用场景
• 1 项目前期的可行性分析
– 关注技术可行性之外的内容 – 采用快速功能点方法判断项目所需完成的工期和初步
• 2 甲方确立项目范围与标的
– 甲方在招标的过程中首先需要在内部立项、申请预算 – 功能点方法有助于给出明确的预算申请依据,使得预
算过程更加透明
• 示例:1000个功能点的项目,甲方内部申请的预算为 1000*2K=2000K,其中1000FP是根据功能点标准得到,而 每个功能点的费用为2K则可以依据行业数据得到(假定一个 功能点的开发成本为1.5K左右,考虑到乙方的利润为20%, 以及甲方10%左右的管理成本)
Application A
file file
file
Application B file
内部逻辑文件ILF
外部接口文件EIF
数据功能
功能点分析方法
• 把用户的业务功能需求分为数据功能需求和处理 数据的事务功能需求
• 数据分为应用内部逻辑数据和应用外部的接口数 据,事务分为对数据的外部输入、输出和查询
功能点计数过程
user1
查询员工信息EQ
user1 新建员工信息EI
HR system
Байду номын сангаасEmployee information(ILF)
Boundary
Currency App
Conversion rate(EIF)
生成员工信息报表EO
功能点分析方法的一种形式化定义

功能点分析方法的一种形式化定义顾勋梅;虞慧群【摘要】针对功能点分析(FPA)方法因缺少精确化定义而导致度量结果与实际之间有一定偏差的问题,基于B方法对FPA的度量规则进行形式化定义,即为功能点计算提供一个明确的定义.实例应用表明,把B方法应用到软件度量中,能够提高软件项目管理的效率,为软件功能规模的自动化度量奠定基础.【期刊名称】《计算机工程》【年(卷),期】2010(036)014【总页数】4页(P10-12,15)【关键词】功能点分析;B方法;度量;形式化定义【作者】顾勋梅;虞慧群【作者单位】淮海工学院计算机科学系,连云港,222005;华东理工大学信息科学与工程学院,上海,200237【正文语种】中文【中图分类】TP3111 概述软件的功能规模是一个用来合理地管理和控制软件开发项目的基本要素。
功能点分析(Function Points Analysis, FPA)是一种基于软件系统的软件功能规模度量方法,用“功能点数量”来表示软件的规模。
与代码行这种度量单位相比,功能点数量与编程语言无关,而且在项目开发早期确定了软件需求后即可计算。
虽然FPA方法应用很广泛,但其方法本身还是存在不足,主要体现在:(1)功能点分析的计算规则是用简单的自然语言的形式给出的,易受度量工作者的主观性影响;(2)FPA方法主要是一个手工处理过程,其代价比较高;(3)功能点分析方法比较复杂,对使用者要求较高,所需时间较长,还要求较高的需求完整性和准确性。
而导致这些缺点的主要原因之一在于缺少一个精确的定义。
B方法是一个基于模型的形式化方法,对于建模和软件验证是一种有效的方法。
由于功能点分析方法提出得比较早,难以适应当今软件规模和网络的快速发展,因此在大规模软件项目中,把B方法和软件度量结合起来能够提高软件项目管理的效率。
本文采用B规格说明语言来定义和描述FPA,一方面能够更好地利用FPA的优势合理有效地度量软件,为功能点计算提供一个明确的定义;另一方面为软件功能规模的自动化度量奠定基础。
IFPUG功能点分析法

IFPUG功能点分析法1、功能点方法简介功能点方法是一种间接、但比较准确的软件开发工作量度量方法,目前普遍用于软件工作量估算。
功能点方法,自IBM的Albrech在1979年发表,随后被IFPUC (Internal Function Point UserCroup)继承,1999年发布了现行的4.1版。
一个功能点用一定规模的系统数据(ILF和EIF)及其处理(EI、EO、EQ)来表征,它囊括了为实现特定功能所固有和必需的需求分析、系统设计、编写文档和测试用例、编码、测试、部署、调优、培训等工作量。
功能点方法从用户需求和逻辑设计角度出发,根据软件需求规格说明书及IFPUG功能点分析法的操作规程,估算应用系统的功能点数,再从每个功能点的功能类型和复杂度两个维度,参考业界单功能点开发时长,测算出项目工作量,与具体技术和实现无关。
2、术语定义:●内部逻辑文件(ILF)是一组用户能够识别、存在内在逻辑关联、在系统边界之内被控制的数据或控制信息。
可理解为一个实体联系模型或一组关联的数据表。
●外部接口文件(EIF)是另外一个系统的ILF。
在本系统中被引用、在系统边界之外被控制。
●外部输入(EI),一个接受来自系统边界之外的数据或控制信息的基本处理。
其目的是维护一个内部逻辑文件,或改变系统的行为。
●外部输出(EO) -个向系统边界之外发送数据或控制信息的基本处理。
其目的是向用户展示一组经过了(除提取之外的)逻辑处理的数据或控制信息,也可能包括对内部逻辑文件的维护或改变系统的行为。
●外部查询(EQ) -个向系统边界之外发送数据或控制信息的基本处理。
其目的足向用户展示一组经过提取处理的数据或控制信息,不会引起对内部逻辑文件的维护或系统行为的改变。
界面.doc报表.doc业务逻辑.doc接口命令.doc 4、数据功能类型及事物功能类型复杂度权重对应表。
功能点分析方法之一-原理篇

功能点分析方法之一-原理篇功能点分析法(FPA:function point analysis) 是一种相对抽象的方法,是一种”人为设计”出的度量方式,主要解决如何客观,公正,可重复地对软件地规模进行度量的问题.FPA 法由IBM的工程师艾伦·艾尔布策(Allan Albrech) 于20 世纪70 年代提出,随后被国际功能点用户协会(IFPUG:The International Function Point Users' Group) 提出的IFPUG 方法继承,从系统的复杂性和系统的特性这两个角度来度量系统的规模,其特征是:“ 在外部式样确定的情况下可以度量系统的规模” ,“ 可以对从用户角度把握的系统规模进行度量” 。
功能点可以用于“ 需求文档” 、“ 设计文档” 、“ 源代码” 、“ 测试用例” 度量,根据具体方法和编程语言的不同,功能点可以转换为代码行。
经由ISO 组织已经有多种功能点估算方法成为国际标准,如:①加拿大人艾伦·艾布恩(Alain Abran) 等人提出的全面功能点法(full function points) ;②英国软件度量协会(UKSMA :United Kingdom Software Metrics Association) 提出的IFPUG 功能点法(IFPUG function points) ;③英国软件度量协会提出的Mark II FPA 功能点法(Mark II function points) ;④荷兰功能点用户协会(NEFPUG:Netherlands Function Point Users Group) 提出的NESMA 功能点法,以及软件度量共同协会(COSMIC:the Common Software Metrics Consortium) 提出的COSMIC-FFP 方法,这些方法都属于艾尔布策功能点方法的发展和细化。
功能点分析法 IFPUG

100 FPs
Impact Effort Schedule Cost
120 FPs
• State code input screen changed (3 FPs)
• Interface to N&A file added (10 FPs)
• N&A inquiry and state code inquiry added (7 FPs)
3
© Copyright 2001. International Function Point User Group 2001
..
IFPUG Mission Statement
• The mission of the International Function Point Users Group is to be a recognized leader in promoting and encouraging the effective management of application software development and maintenance activities through the use of Function Point Analysis and other software measurement techniques.
9
© Copyright 2001. International Function Point User Group 2001
..
Changes to Requirements
• Changes to Requirements
– Change Inevitable – Trade-offs – Customer Definition of Quality – Size
功能点分析实例

• 员工基本信息如下所示:
员工ID 员工名称 性别 生日 婚否 所属部门ID 所属部门名称 工作时间 工作单位 工作部门 工作职务 受教育的时间 学校名称 所学专业 亲属的姓名 之间关系 亲属年龄 工作单位
• 假设部门信息如下所示:
– 部门ID – 部门名称
• 假设工资表信息如下所示:
– 员工ID – 员工姓名 – 金额 – 单位
FPA功能点估算法实例 V1.2
卫剑钒
摘要
• 以员工管理系统为例,详细说明如何利用 功能点估算法计算业务复杂度。
员工管理系统概要
• 在员工管理系统中,操作有 :
“添加员工信息” “修改员工信息” “删除员工信息” “查询员工信息” “统计员工年薪”
“添加部门信息” “修改部门信息” “删除部门信息” “查询部门信息”
结 束!
2012.11.8Fra bibliotek• 在另外一个系统“财务系统”中,有个 “工资表”,员工管理系统会用它来统计 年薪。
分 析
• 员工管理系统中如果要添加一个员工,会 用到员工的一般信息,如教育情况、工作 经历和家属信息等等。 • 由于每个员工都隶属于某个部门,所以在 本系统中,还要维护“部门” 信息。 • 员工的工资则由另外一个财务系统提供。
• 简单来讲,ILF和EIF可以被看作数据库中的数据表,但是 主、从表将被视为一个ILF或EIF。 • 那么,ILF和EIF的复杂度就是由数据表中的字段DET和一 个ILF或EIF自身所包含的主、从表个数RET来决定。在计 算DET时主、外键只能算作一个。 • 主从表的情况:类似于订单表与订单明细表的关系。 • 主键是定义一个表唯一的,同时系统按主键为表建立索引。 • 外键:一个表中所定义的外键是另一张表的主键。 • 若有两个表A,B,C是A的主键,而B中也有C字段,则C 就是表B的外键,外键约束主要用来维护两个表之间数据 的一致性。
功能点分析法指南

功能点分析法指南版本1.0文档编号:SW_SPP_GUI_FPA_V1.0SEPG*修改状态:A——增加,M——修改,D——删除文件批准单职务签字日期1. 功能点分析法概论 (5)1.1. 目标 (5)1.2. 收益 (5)1.3. 步骤 (5)1.3.1. 决定分析的类型 (5)1.3.2. 识别分析范围和应用边界 (5)1.3.3. 确定未经调整的功能点数 (6)1.3.3.1.数据功能的计数 (6)1.3.3.2. 交易功能的计数 (6)1.3.3.3. 确定调整系数 (7)1.3.3.4. 计算经过调整的功能点 (7)2. 分析流程 (7)2.1. 决定分析的类型 (7)2.1.1. 定义:功能点分析的类型 (7)2.2. 识别分析范围和应用边界 (8)2.2.1. 定义 (8)2.2.2. 定义应用边界 (9)2.3. 规则和流程 (9)2.3.1. 边界识别的规则 (9)2.3.2. 分析范围和应用边界流程 (9)2.3.3. 边界识别的一些技巧 (9)2.4. 计数数据功能 (10)2.4.1. 定义 (10)2.4.2. 计数流程概述 (10)2.4.3. ILF识别规则 (11)2.4.4. EIF识别规则 (11)2.4.5. 复杂度和贡献的定义和规则 (11)2.4.6. ILF/EIF计数流程 (12)2.4.7. 复杂度和贡献确定流程 (13)2.4.8. 数据功能计数技巧 (13)2.5. 计数交易功能 (14)2.5.1. 定义 (14)2.5.1.1. 基本定义 (14)2.5.1.2. 交易功能的总结 (14)2.5.1.3. 相关术语的定义 (15)2.5.1.4. 交易功能执行的逻辑处理总结 (16)2.5.2. EI、EO、EQ计数规则 (16)2.5.2.1. 交易功能计数的概要流程 (17)2.5.2.2. 基本处理的识别规则 (17)2.5.2.3. 交易功能计数规则 (17)2.5.3. 复杂度和贡献的定义和规则 (18)2.5.3.1. EI的复杂度和贡献规则 (18)2.5.3.2. EO/EQ的复杂度和贡献规则 (19)2.5.4. EI、EO、EQ的计数流程 (19)2.5.5. 复杂度和贡献确定流程 (20)2.5.6. 交易功能计数技巧 (21)2.6. 决定调整系数 (22)2.6.1. 调整系数的决定 (22)2.6.2. 确定V AF的流程 (22)2.6.3. 通用系统特性及其影响程度的评定 (22)2.6.4. 各GSC的DI分级详述 (23)2.6.4.1. 数据通讯 (23)2.6.4.2. 分布式数据处理 (23)2.6.4.3. 性能 (24)2.6.4.4. 使用强度高的配置 (24)2.6.4.5. 交易速度 (25)2.6.4.6. 在线数据输入 (25)2.6.4.7. 最终用户的效率 (25)2.6.4.8. 在线更新 (26)2.6.4.9. 复杂的处理 (26)2.6.4.10. 可重用性 (27)2.6.4.11. 安装的简易性 (27)2.6.4.12. 运行的简易性 (27)2.6.4.13. 多场地 (28)2.6.4.14. 允许变更 (28)2.7. 计算调整功能点 (29)2.7.1. 开发项目功能点的计算 (29)2.7.2. 升级项目功能点的计算 (29)2.7.3. 应用功能点的计算 (30)3. 附录A: 未经调整的功能点计算表 (31)4. 附录B:功能点计数中的规则表 (32)5. 附录C: 词汇表 (35)1.功能点分析法概论本章概要地介绍了功能点分析的方法,包括功能点方法的目的以及对功能点分析的方法进行总结。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
– 功能点估算法是以用户为角度进行估算,LOC代码行估算法则是以技术为角度进 行估算。
– 通过一些行业标准或企业自身度量的分析,功能点估算法是可以转换为LOC代码 行的。
• 在项目刚开始的时候进行功能点估算可以对项目的范围进行预测。在项目开 发的过程中由于需求的变更和细化可能会导致项目范围的蔓延,计算出来的 结果会与当初估计的不同。因此,在项目结束时还需要对项目的范围情况重 新进行估算,这个时候估算的结果才能最准确反映项目的规模。
① 从用户角度出发识别的一组逻辑数据。 ② 这组数据是在应用程序外部,并被应用程序引用的。 ③ 计算功能点的这个应用程序并不维护该EIF。 ④ 这组数据是作为另一个应用程序中的ILF被维护的。
ILF和EIF的复杂性计算(1/2)
• ILF和EIF的复杂性是取决于RET(Record element type)和DET(Data element type)的数量。
点是外部系统负责计算的。
– 以图为例:一个外贸订单系统只包含录入、修改、删
除、查询和统计订单的功能,而汇率查询转换服务是
图2 外贸订单系统用例图
不属于该系统的。
• 应用程序边界的识别规则大家一定要牢记,不能 从技术角度去思考,必须从用户角度来定义;如
果项目牵扯到多个系统,那么必须将这多个系统 的边界全部描述清楚。
功能点估算法的特点
• 项目范围的估算在CMMI的“MA”度量分析管理和“PP”项目计划中均有涉及。 对软件项目范围的估算有很多种方法,常见的是LOC代码行和FP功能点法。 它们之间的区别和关系如下:
– 功能点估算法常用在项目开始或项目需求基本明确时使用,这时进行估算其结果 的准确性比较高。假如这个时候使用LOC代码行估算法,则误差会比较大。
功能点估算分类
• 功能点估算法将功能点分为以下5类:
① ILF:Internal Logical File内部逻辑文件 ② EIF: External Interface File外部接口文件 ③ EI: External Input外部输入 ④ EO: External Output外部输出 ⑤ EQ: External Inquiry外部查询 – 其中,ILF和EIF属于数据类型的功能点,EI、EO、EQ属于
人机交互事务类型的功能点。
• 以外贸订单系统项目为例:
– 录入订单、修改订单、删除订单是EI; – 查询订单是EO – 统计订单是EQ – 汇率查询转换系统为EIF – 订单和客户是ILF图2 外贸订单系来自用例图识别功能点的重要原则
• 软件项目管理中的功能点估算法将功能点分为5类: ILF、EIF、EI、EO和EQ。其中:
功能点分析法专题
功能点估算法的意义
• 功能点估算法是软件项目管理众多知识中 比较有技术含量的一个。
• 在软件项目管理中项目计划制定的优劣直 接关系到项目的成败,项目计划中对项目 范围的估算又尤为重要。
– 如果项目负责人对项目的规模没有一个比较客 观的认识,没有对工作量、所需资 源、完工时 间等因素进行估算,那么项目计划也就没有存 在的意义。
功能点分析的步骤
• 我们将以国际标准IFPUG(International Function Point Users Group)组织提供的功能 点估算法V4.1.1为基础进行讲解。如下图所示, 首先大家应该了解功能点估算法的使用步骤。
• 具体步骤包括:
① 识别功能点的类型。 ② 识别待估算应用程序的边界和范围。 ③ 计算数据类型功能点所提供的未调整的功能点数量。 ④ 计算人机交互功能所提供的未调整的功能点数量。 ⑤ 确定调整因子。 ⑥ 计算调整后的功能点数量。
识别项目的类型
• 国际IFPUG组织将软件项目分为三类,功 能点估算法适用于任何一类项目:
– 新开发项目 – 二次开发的项目 – 功能增强的项目
识别项目的范围和边界
• 使用UML的“UseCase”用例图是以用户角度进 行识别项目范围和边界的最好方法,在画用例图
时就必须明确系统的边界。通过系统的边界,我 们可以知道 哪些功能要计算功能点,哪些功能
内部逻辑文件与外部接口文件
• ILF内部逻辑文件 内部逻辑文件是指一组以用户角度识别的、在应用程序边界内且被维护的
逻辑相关数据或控制信息。ILF的主要目的是通过应用程序的一个或多个基本 处理过程来维护数据。 • EIF外部接口文件
外部接口文件是指一组在应用程序边界内被查询,但在其他应用程序中被 维护的、以用户角度来识别的、逻辑上相关的数据。因此,一个应用程序中 的EIF必然是 其他应用程序中的ILF。EIF的主要目的是为边界内的应用程序 提供一个或多个通过基础操作过程来引用的一组数据或信息。 • EIF所遵循的规则:
– ILF和EIF属于数据类型的功能点; – EI、EO、EQ属于事务类型的功能点。
• ILF、EIF要与EI、EO、EQ分开计算。
– 对ILF和EIF复杂度的计算可简单理解为对数据库复杂度 的计算。
– 对EI、EO、EQ复杂度的计算可理 解为对程序开发复杂 度的计算。
• 一般软件项目都是由数据和程序构成的,因此计算 ILF、EIF和计算EI、EO、EQ之间没有任何关系。
• 再如:保存订单时还会保存订单的明细。订单的明细往往作为一个子表进行保存,那么 “订单号码”在主表和子表中都同时存在(主外键)。但以用户角度来识别时,存盘操 作是一个最小的单位,那么订单号码只能算做一个DET。
– 当两个应用程序维护和/或引用相同的ILF/EIF,但是每个应用程序分别维护/引用它 们相应的DET时,这些DET在这两个应用程序的维护/引用中将单独计算。
• DET是一个以用户角度识别的、非重复的、有业务逻辑意义的字段。
• DET计算的规则如下:
– 通过一个基本处理过程的执行,对ILF进行维护,或从ILF/EIF中返回一个特定的、 用户可识别的、非重复的字段,那么每个这样的字段算一个DET。
• 例如:添加一个外贸订单时需要保存“订单号码、订单日期、地址、邮编”,那么对于 ILF订单来说它的DET就是4个。