文档库 最新最全的文档下载
当前位置:文档库 › [荐]功能点估算(CMMI-FP)有实例介绍

[荐]功能点估算(CMMI-FP)有实例介绍

[荐]功能点估算(CMMI-FP)有实例介绍
[荐]功能点估算(CMMI-FP)有实例介绍

功能点估算(CMMI-FP)

功能点估算法是软件项目管理众多知识中比较有技术含量的一个。在软件项目管理中项目计划制定的优劣直接关系到项目的成败,项目计划中对项目范围的估算又尤为重要。如果项目负责人对项目的规模没有一个比较客观的认识,没有对工作量、所需资源、完工时间等因素进行估算,那么项目计划也就没有存在的意义。

一、功能点估算法的特点

项目范围的估算在CMMI的“MA”度量分析管理和“PP”项目计划中均有涉及。对软件项目范围的估算有很多种方法,常见的是LOC代码行和FP功能点法。它们之间的区别和关系如下:

?功能点估算法常用在项目开始或项目需求基本明确时使用,这时进行估算其结果的准确性比较高。假如这个时候使用LOC代码行估算法,则误差会比较大。

?使用功能点估算法无需懂得软件使用何种开发技术。LOC代码行估算法则与软件开发技术密切相关。

?功能点估算法是以用户为角度进行估算,LOC代码行估算法则是以技术为角度进行估算。

?通过一些行业标准或企业自身度量的分析,功能点估算法是可以转换为LOC代码行的。

在项目刚开始的时候进行功能点估算可以对项目的范围进行预测。在项目开发的过程中由于需求的变更和细化可能会导致项目范围的蔓延,计算出来的结果会与当初估计的不同。因此,在项目结束时还需要对项目的范围情况重新进行估算,这个时候估算的结果才能最准确反映项目的规模。

二、功能点分析的步骤

本文将以国际标准IFPUG(International Function Point Users Group)组织提供的功能点估算法V4.1.1为基础进行讲解。如下图所示,首先大家应该了解功能点估算法的使用步骤。

图1 功能点估算法的步骤

具体步骤包括:

1. 识别功能点的类型。

2. 识别待估算应用程序的边界和范围。

3. 计算数据类型功能点所提供的未调整的功能点数量。

4. 计算人机交互功能所提供的未调整的功能点数量。

5. 确定调整因子。

6. 计算调整后的功能点数量。

三、识别项目的类型

国际IFPUG组织将软件项目分为三类,功能点估算法适用于任何一类项目:?新开发项目

?二次开发的项目

?功能增强的项目

四、识别项目的范围和边界

使用UML的“UseCase”用例图是以用户角度进行识别项目范围和边界的最好方法,在画用例图时就必须明确系统的边界。通过系统的边界,我们可以知道哪些功能要计算功能点,哪些功能点是外部系统负责计算的。以图2为例:一个外贸订单系统只包含录入、修改、删除、查询和统计订单的功能,而汇率查询转换服务是不属于该系统的。

应用程序边界的识别规则大家一定要牢记,不能从技术角度去思考,必须从用户角度来定义;如果项目牵扯到多个系统,那么必须将这多个系统的边界全部描述清楚。

图2 外贸订单系统用例图

五、功能点估算分类

功能点估算法将功能点分为以下5类:

1. ILF:Internal Logical File内部逻辑文件

2. EIF: External Interface File外部接口文件

3. EI: External Input外部输入

4. EO: External Output外部输出

5. EQ: External Inquiry外部查询

其中,ILF和EIF属于数据类型的功能点,EI、EO、EQ属于人机交互事务类型的功能点。

以外贸订单系统项目为例:

?录入订单、修改订单、删除订单是EI;

?查询订单是EO

?统计订单是EQ

?汇率查询转换系统为EIF

?订单和客户是ILF

六、识别功能点的重要原则

ILF、EIF要与EI、EO、EQ分开计算。对ILF和EIF复杂度的计算可以简单理解为对数据库复杂度的计算。对EI、EO、EQ复杂度的计算可以理解为对程序开发复杂度的计算。一般软件项目都是由数据和程序构成的,因此计算ILF、EIF 和计算EI、EO、EQ之间没有任何关系。

七、内部逻辑文件与外部接口文件

ILF内部逻辑文件

内部逻辑文件是指一组以用户角度识别的、在应用程序边界内且被维护的逻辑相关数据或控制信息。ILF的主要目的是通过应用程序的一个或多个基本处理过程来维护数据。

EIF外部接口文件

外部接口文件是指一组在应用程序边界内被查询,但在其他应用程序中被维护的、以用户角度来识别的、逻辑上相关的数据。因此,一个应用程序中的EIF 必然是其他应用程序中的ILF。EIF的主要目的是为边界内的应用程序提供一个或多个通过基础操作过程来引用的一组数据或信息。

EIF所遵循的规则:

?从用户角度出发识别的一组逻辑数据。

?这组数据是在应用程序外部,并被应用程序引用的。

?计算功能点的这个应用程序并不维护该EIF。

?这组数据是作为另一个应用程序中的ILF被维护的。

八、ILF和EIF的复杂性计算

ILF和EIF的复杂性是取决于RET(Record element type)和DET(Data element type)的数量。DET是一个以用户角度识别的、非重复的、有业务逻辑意义的字段。

DET计算的规则如下:

?通过一个基本处理过程的执行,对ILF进行维护,或从ILF/EIF中返回一个特定的、用户可识别的、非重复的字段,那么每个这样的字段算一个

DET。

例如:添加一个外贸订单时需要保存“订单号码、订单日期、地址、邮编”,那么对于ILF订单来说它的DET就是4个。

再如:保存订单时还会保存订单的明细。订单的明细往往作为一个子表进行保存,那么“订单号码”在主表和子表中都同时存在(主外键)。但以用户角度来识别时,存盘操作是一个最小的单位,那么订单号码只能算做一个DET。

?当两个应用程序维护和/或引用相同的ILF/EIF,但是每个应用程序分别维护/引用它们相应的DET时,这些DET在这两个应用程序的维护/引用中将单独计算。

例如,一个应用程序的两个“Elementary Process”基本处理过程都需要使用到“地址”的信息,地址信息又可以细分为“国家、城市、街道、邮编”。那么对于其中一个基本处理过程来说,它将整个地址信息作为一个整体进行处理,只算一个DET;另外一个基本处理过程使用每个地址的详细信息,那么DET就是4个。

RET计算的规则如下:

RET是指一个EIF/ILF中用户可以识别的DET的集合。如果把DET简单理解为字段的话,那RET就可以简单理解为数据库中的表。RET在ILF /EIF中分为两种类型:可选的(Optional)和必选的(Mandatory)。计算RET的规则为以下两点:

?在一个ILF/EIF中每一个可选或必选的集合都被计算为一个RET。

?如果一个ILF/EIF没有子集合,则ILF/EIF被计算为一个RET。

例如:在外贸订单系统中添加一个订单时会保存“订单信息、客户的ID、部门的ID”。那么订单系统ILF中的RET为:

1. 订单信息(必选的)

2. 客户信息(必选的)

3. 部门信息(可选的)

因此ILF中RET的个数为3个。

ILF/EIF复杂度的矩阵如下:

软件项目管理中的功能点估算法将功能点分为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的比较

EI是处理来自应用程序边界外部的一组数据输入,它的主要目的是维护一个或多个ILF,以及/或者更改系统的行为。

EO是输送数据到应用程序边界外部的过程。它的主要目的是通过逻辑处理过程向用户呈现信息。该处理过程必须包含至少一个数学公式或计算方法,或生成派生数据。一个EO也可以维护一个或多个ILF,并/或改变系统行为。

EQ是向应用程序边界外发送数据基本处理的过程。其主要目的是从ILF或EIF中通过恢复数据信息来向用户呈现。该处理逻辑不包括任何数学公式或计算方法,也不会生成任何派生数据。EQ不会维护任何一个ILF,也不会改变应用程序的系统行为。

EO和EQ的共同点是,其主要目的都是通过基本操作过程展现数据给用户。EI、EO、EQ的比较见下表。

表1 EI、EO、EQ的主要目的

表2 EI、EO、EQ的主要行为

十、事务类型功能点的计算规则

在IFPUG的定义中有一个重要的单词“Elementary Process”——基本处理过程。该过程对用户来说是一个有意义的、最小的活动单位,并且是一个自包含的活动。功能点的分类,EI、EO、EQ的识别都是基于“Elementary Process”基本处理过程的。

十一、EI的计算规则

1. 从应用边界之外收到数据。

2. 如果进入系统边界内的数据不是一个改变系统行为的控制信息,那么至少一个ILF应该被改变。

3. 对于已识别的处理过程,至少满足下面三个条件之一。

?该基本处理过程的逻辑与本应用系统中其它基本处理过程的逻辑不同。该基本处理过程应该具有唯一性。例如:不能存在两个完全一模一样的存盘操作。

?在应用程序边界内,该基本处理过程所使用的这组数据应该与其他基本处理过程所使用的数据不同。

?在应用程序边界内,基本处理过程所引用的ILF或EIF是不同于其它基本处理过程所引用的ILF或EIF。

十二、EO和EQ通用计算规则

必须全部满足以下内容才能被视为一个EO或EQ:

1. 从外部发送数据或控制信息到应用程序边界内。

2. 为了识别这个过程,以下三点必须满足一个:

?该基本处理过程逻辑上必须是唯一的,该唯一性是指其在应用程序中与其他EO或EQ在逻辑性上保持唯一。

?该基本处理过程所使用的数据应该是唯一的,该唯一性是指其在应用程序中与其他EO或EQ所使用的数据不同。

?该基本处理过程所引用的ILF或EIF文件应该是唯一的,该唯一性是指其在应用程序中与其他EO或EQ所引用的ILF或EIF文件不同。

十三、EO补充的计算规则

除了要满足上面的通用规则外,还要满足下面其中一条:?在基本操作过程中至少包含一个数学公式或计算方法

?在基本操作过程中要产生派生数据

?在基本操作过程中至少要维护一个ILF

?在基本操作过程中要改变系统的行为。

十四、EQ补充的计算规则

除了要满足上面的通用规则外,还要满足下面其中一条:?基本操作过程从ILF或EIF中获取数据。

?基本操作过程不能包含数学公式或计算方法。

?基本操作过程不能生成派生数据

?基本操作过程不能维护任何一个ILF

?基本操作过程不能改变系统的行为

十五、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。

例如,外贸订单系统中,订单的金额是被单价和数量自动计算的,那么金额是没有通过系统边界输入的,因此在EI操作中就不应该算做一个DET。

?在应用程序的EI操作时,系统提示的错误信息或完成操作的信息,应该被分别计算为一个DET。

例如,在网站注册用户信息时,由于输入错误系统会显示提示信息,那么这些提示信息应该被逐个计算为一个DET。

再如,当EI操作完成时系统提示并显示出来的信息,应该被计算为一个DET。

?在EI操作中,如果遇到主外键的字段,应该算作一个DET。

EO和EQ计算FTR的规则

1. 通用规则:

?每个在EO/EQ处理过程中读取的ILF和EIF算一个FTR

2. EO额外的FTR计算规则

?在EO处理过程中每个被维护的ILF算一个FTR

?在EO处理过程中既被读取又被维护的ILF算一个FTR

十六、EO和EQ计算DET的通用规则

?用户可识别的非重复字段,进入应用边界并指明处理什么、何时处理或处理方式,并且由EO/EQ返回或产生,那么这样的每个字段算一个DET。

例如,报表中的每个字段都是一个DET。

?在应用边界内以用户角度识别的非重复字段算一个DET。

例如,在报表中起到解释或备注作用的文字信息,不管是一个字、一个词或一段话,都当作一个DET。

再如,某种编号或日期,即使它被物理存储在不同字段中,但从用户角度看是一个整体的信息,因此被算作一个DET。

还有,在饼图中百分比和分类算作不同的DET。

?在EO或EQ操作中,如果对系统进行输入或读取操作时,相同的字段只计算一个DET。

例如,在报表查询时,输入的字段在报表上也有显示,那么将算作同一个DET。

?在应用程序的EO或EQ操作时,系统提示的错误信息或完成操作的信息,应该被计算为DET。

例如,用户查询一个列表时被拒绝,那么拒绝的提示信息就算为一个DET。

?在EO或EQ操作中如果遇到主外键的字段,应该算作一个DET。

?在EO或EQ过程中,只要没有通过系统边界输入,就算它存在于系统内的一个ILF中,也不能算为一个DET。

例如,在公司发工资的时候,员工对应的状态信息被更新,但这个状态信息的更新是没有通过系统边界输入的,因此也不能算做一个DET。

?页面的标题等类似信息不计算DET。

?系统字段生成的记号不能被算作一个DET。

例如,页码、位置信息、时间、上一页和下一页等信息,都不能算作一个DET。

十七、EI复杂度计算矩阵

十八、EO和EQ复杂度计算矩阵

未调整前功能点对应矩阵

EI、EO、EQ、ILF和EIF技术复杂度对应的功能点如下表所示:

用功能点估算法计算软件项目功能点时会用到调整因子(或称调整系数)。功能点的调整系数是通过通用系统特性及其影响程度来评定的,对每个常规系统特性的评估由其影响程度(DI)而定,分为0-5级:

0 毫无影响

1 偶然影响

2 适度影响

3 一般影响

4 重要影响

5 强烈影响

然后依次对以下14个系统常规特性进行打分,并带入以下计算公式算出功能点的调整因子。

Value Adjustment Factor=( sum of (DI) * 0.01 ) + 0.65

十九、计算调整因子

1. 数据通讯

数据通讯指的是应用程序直接与处理器通讯的程度。通常我们都是通过某种通讯手段来实现在一个应用中所使用的数据或者控制信息。连接到本地控制器上的终端被认为是通讯设施,协议则指两个系统或设备之间进行通讯时使用的一种约定。所有的数据通讯链接都需要某种协议。

2. 分布式数据处理

分布式数据处理是应用在内部组件之间传递信息的程度。这个特性是在应用边界内体现的。

3. 性能

性能是吞吐量、处理时间等指标对开发的影响。用户所提出的性能要求将直接影响到系统的设计、实施、安装和支持。

4. 大业务量配置

大业务量配置是指计算机资源对应用开发的影响程度。大业务量的运行配置对设计有特殊要求,是必须考虑的一个系统特性。

5. 事务处理率

事务处理率是业务交易处理速度对系统的设计、实施、安装和支持等的影响。

6. 在线数据输入

在线数据输入是指数据通过交互的方式输入系统的程度。系统中包括在线数据输入和控制信息功能。

7. 最终用户效率

最终用户效率是指对应用的人文因素及使用的便捷程度等的考虑程度。

如下功能设计是针对最终用户效率的:

?页面导航

?菜单

?在线帮助或文档

?光标自动跳转

?可以滚动

?在线远程打印

?预定义的功能键

?在线做批量提交任务

?光标可以选取界面上的数据

?用户使用大量反白显示、重点显示、下划线或其他的标识

?在线copy用户文档

?鼠标拖动功能

?弹出窗体

?使用最少的界面完成某种商业功能

?双语言支持(如果选择了这个就算4项)

?语言支持(如果选择了这个就算6项)

8. 在线更新

在线更新是指内部逻辑文件ILF被在线更新的程度。应用系统提供在线更新内部逻辑文件的功能。

9. 复杂处理

复杂处理描述了逻辑处理对应用开发的影响程度。它包含以下要素:

?敏感控制(例如特殊的审核过程)和/或程序特定的安全处理

?大量的逻辑处理

?大量的数学处理

?因为例外处理造成的需要重新处理的情况(例如,由TP中断、数据值缺少和验证失败导致的ATM事务)

?多种可能的输入/输出造成的复杂处理

10. 可复用性

应用系统中的应用和代码经过特殊设计、开发和支持,可以在其他应用系统中复用。

11. 易安装性

易安装性指应用系统的转换和安装容易度对开发的影响程度。系统测试阶段提供了转换和安装计划/转换工具。

12. 易操作性

易操作性指的是应用对运行的影响程度,如有效启动、备份和恢复规程的影响。易操作性是应用提供的一种特性,它最小化了手工操作的要求。

13. 多场地

多场地指应用系统经特殊设计、开发可以在多个组织、多个地点应用的程度。

14. 支持变更

支持变更是指应用在设计上考虑支持处理逻辑和数据结构变化的程度。

可以具有如下的特性:

?提供可以处理简单要求的弹性查询和报告功能,如对一个ILF进行与(或)逻辑

?提供可以处理一般复杂度要求的弹性查询和报告功能,如对多于一个的ILF进行与(或)逻辑(当作两项计算)

?提供可以处理复杂要求的弹性查询和报告功能,如对一个或多个ILF进行与(或)逻辑的组合(当作三项计算)

?业务控制数据被保存到用户通过在线交互进程维护的表中,但变更只会在第二个工作日生效

?业务控制数据被保存到用户通过在线交互进程维护的表中,且变更即时生效

二十、计算调整后的功能点个数

国际IFPUG组织将软件项目分为三类,功能点估算法适用于任何一类项目,其计算公式中的术语请详见表1。

?功能点的原始计算公式:

FP Count =UFP * VAF

?新开发项目

有时新开发的软件项目也需要与其他现存的软件系统进行整合。例如:一个企业新开发的MIS内部管理系统经常会与财务系统进行整合。这时除了考虑本身项目的功能点个数外,还要考虑系统整合或数据迁移部分的工作量。因此,其功能点计算公式如下:

FP Count =(UFP+CFP)* VAF

?二次开发的项目

有时新开发的软件项目是在原有基础上进行二次开发的,只是为了增加一些新功能。因此,其功能点计算公式如下:

FP Count = ADD * VAF

?功能增强的项目

功能增强项目的功能点估算比较复杂。在计算功能点前大家需要计算有哪些是新增加的功能,哪些是被修改的功能,哪些是属于数据迁移

或系统整合的功能。然后计算新系统技术复杂度的调整因子“VAFA”,并在此基础上计算系统功能点的数量。当然,此类项目也会去掉一些原有功能,那么在原有系统的技术复杂度基础上重新计算功能点的调整因子“VAFB”,再计算所去掉功能贡献的功能点数量。因此,其功能点计算公式如下:

FP Count = [(ADD+CHGA+CFP)* VAFA]+(DEL * VAFB)

?表1 功能点技术公式术语

二十一、功能点估算实例分析

以员工管理系统为例,详细说明如何利用功能点估算法计算业务复杂度。

在员工管理系统中添加一个员工资料,会使用到员工的一般信息、教育情况、工作经历和家属信息。员工隶属于某个部门,在本系统中会有一个对部门进行维护的功能。员工的工资则由另外一个财务系统提供。因此,其用例图如下所示:

图1 员工管理系统用例图

假设员工基本信息如下所示:

?员工ID(标签控件)

?员工名称

?性别

?生日

?婚否

?所属部门ID(标签控件)

?所属部门名称

?——受教育的时间

?——学校名称

?——所学专业

?——工作时间

?——工作单位

?——工作部门

?——工作职务

?——亲属的姓名

?——之间关系

?——亲属年龄

?——工作单位

假设部门信息如下所示:

?部门ID(标签控件)

?部门名称

假设工资表信息如下所示:

?员工ID(标签控件)

?员工姓名

?金额

?单位

ILF和EIF的功能点数

本范例识别出来ILF和EIF功能点个数如下表所示。

EI、EQ和EO的功能点数

功能点估算案例

功能点估算案例 下面以员工管理系统为例,详细说明如何利用功能点估算法计算业务复杂度。 在员工管理系统中添加一个员工的资料,会使用到员工的一般信息、教育情况、工作经历和家属信息。员工隶属于某个部门,在本系统中会有一个对部门进行维护的功能。员工的工资则由另外一个财务系统提供。因此,其用例图如下所示: 图1 员工管理系统用例图 假设员工基本信息如下所示: ?员工ID(标签) ?员工名称 ?性别 ?生日 ?婚否 ?所属部门ID ?所属部门名称 ?受教育的时间 ?学校名称 ?所学专业

?工作时间 ?工作单位 ?工作部门 ?工作职务 ?家属的姓名 ?之间关系 ?家属年龄 ?工作单位 假设部门信息如下所示: ?部门ID ?部门名称 假设工资表信息如下所示: ?员工ID ?员工姓名 ?金额 ?单位 ILF和EIF的功能点数 本案例识别出来ILF和EIF功能点个数如下表所示。 EI、EQ和EO的功能点数 本范例识别出来EI、EQ和EO功能点个数如下表所示。

本系统的通用系统特性及其影响程度如下表所示。

最终调整后的功能点数量为: (19 + 25 + 9 + 5)* 0.84 = 48.72个 总结 功能点估算法是一个非常有用的对软件规模进行估算的国际通用技术,是项目管理人员必须掌握的工具。为了便于大家对功能点的技术进行理解和记忆,这里对其进行总结:由于计算机软件就是为了实现无纸办公,那么在估算功能点时应该多以用户的纸质表单为依据,每个表单就是一个ILF或EIF,表单上显示的字段都是DET,一个表单上的“核心”内容不管是由几个数据表来分别存放数据的,每个表都是一个RET。 简单来讲,ILF和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。

信息系统项目管理功能点估算

选用了FP功能点分析作为项目主要的估算方法.因为FP方法中有大量项目经验数据可以从网络上获得,同时其数据功能TLF、EIF,以及事务功能EI、EO、EQ的计算对经验数据依赖不强,只需对概念理解正确一般就可以正确估算了.在估算成本的时候,因为公司以前的生产率数据是以LOC为单位的,我利用软件工程书籍中的“逆火”经验数据,将 LOC转换为功能点单位,当然,这里必然导致一些误差。为了降低估算误差,最后使用Delphi专家分析法对估算结果进行了调整. 功能点估算法是软件项目管理众多知识中比较有技术含量的一个。在软件项目管理中项目计划制定的优劣直接关系到项目的成败,项目计划中对项目范围的估算又尤为重要。如果项目负责人对项目的规模没有一个比较客观的认识,没有对工作量、所需资源、完工时间等因素进行估算,那么项目计划也就没有存在的意义。 功能点估算法的特点 项目范围的估算在CMMI的“MA”度量分析管理和“PP”项目计划中均有涉及。对软件项目范围的估算有很多种方法,常见的是LOC代码行和FP功能点法。它们之间的区别和关系如下: ?功能点估算法常用在项目开始或项目需求基本明确时使用,这时进行估算其结果的准确性比较高。假如这个时候使用LOC代码行估算法,则误差会比较大。 ?使用功能点估算法无需懂得软件使用何种开发技术。LOC代码行估算法则与软件开发技术密切相关。 ?功能点估算法是以用户为角度进行估算,LOC代码行估算法则是以技术为角度进行估算。 ?通过一些行业标准或企业自身度量的分析,功能点估算法是可以转换为LOC代码行的。 在项目刚开始的时候进行功能点估算可以对项目的范围进行预测。在项目开发的过程中由于需求的变更和细化可能会导致项目范围的蔓延,计算出来的结果会与当初估计的不同。因此,在项目结束时还需要对项目的范围情况重新进行估算,这个时候估算的结果才能最准确反映项目的规模。 功能点分析的步骤 具体步骤包括: 1. 识别功能点的类型。 2. 识别待估算应用程序的边界和范围。 3. 计算数据类型功能点所提供的未调整的功能点数量。 4. 计算人机交互功能所提供的未调整的功能点数量。 5. 确定调整因子。 6. 计算调整后的功能点数量。

层次分析法实例与步骤

层次分析法实例与步骤 结合一个具体例子,说明层次分析法的基本步骤和要点。 【案例分析】市政工程项目建设决策:层次分析法问题提出 市政部门管理人员需要对修建一项市政工程项目进行决策,可选择的方案是修建通往旅游区的高速路(简称建高速路)或修建城区地铁(简称建地铁)。除了考虑经济效益外,还要考虑社会效益、环境效益等因素,即是多准则决策问题,考虑运用层次分析法解决。 1. 建立递阶层次结构 应用AHP解决实际问题,首先明确要分析决策的问题,并把它条理化、层次化,理出递阶层次结构。 AHP要求的递阶层次结构一般由以下三个层次组成: *目标层(最高层):指问题的预定目标; *准则层(中间层):指影响目标实现的准则; *措施层(最低层):指促使目标实现的措施; 通过对复杂问题的分析,首先明确决策的目标,将该目标作为目标层(最高层)的元素,这个目标要求是唯一的,即目标层只有一个元素。 然后找出影响目标实现的准则,作为目标层下的准则层因素,在复杂问题中,影响目标实现的准则可能有很多,这时要详细分析各准则因素间的相互关系,即有些是主要的准则,有些是隶属于主要准则的次准则,然后根据这些关系将准则元素分成不同的层次和组,不同层次元素间一般存在隶属关系,即上一层元素由下一层元素构成并对下一层元素起支配作用,同一层元素形成若干组,同组元素性质相近,一般隶属于同一个上一层元素(受上一层元素支配),不同组元素性质不同,一般隶属于不同的上一层元素。 在关系复杂的递阶层次结构中,有时组的关系不明显,即上一层的若干元素同时对下一层的若干元素起支配作用,形成相互交叉的层次关系,但无论怎样,上下层的隶属关系应该是明显的。 最后分析为了解决决策问题(实现决策目标)、在上述准则下,有哪些最终解决方案(措施),并将它们作为措施层因素,放在递阶层次结构的最下面(最低层)。 明确各个层次的因素及其位置,并将它们之间的关系用连线连接起来,就构成了递阶层次结构。 【案例分析】市政工程项目进行决策:建立递阶层次结构 在市政工程项目决策问题中,市政管理人员希望通过选择不同的市政工程项目,使综合效益最高,即决策目标是“合理建设市政工程,使综合效益最高”。 为了实现这一目标,需要考虑的主要准则有三个,即经济效益、社会效益和环境效益。但问题绝不这么简单。通过深入思考,决策人员认为还必须考虑直接经济效益、间接经济效益、方便日常出行、方便假日出行、减少环境污染、改善城市面貌等因素(准则),从相互关系上分析,这些因素隶属于主要准则,因此放在下一层次考虑,并且分属于不同准则。 假设本问题只考虑这些准则,接下来需要明确为了实现决策目标、在上述准则下可以有哪些方案。根据题中所述,本问题有两个解决方案,即建高速路或建地铁,这两个因素作为措施层元素放在递阶层次结构的最下层。很明显,这两个方案于所有准则都相关。 将各个层次的因素按其上下关系摆放好位置,并将它们之间的关系用连线连接起来。同时,为了方便后面的定量表示,一般从上到下用A、B、C、D。。。代表不同层次,同一层次从左到右用1、2、3、4。。。代表不同因素。这样构成的递阶层次结构如下图。

鱼骨图分析法(完整篇)

编号:SY-AQ-01646 ( 安全管理) 单位:_____________________ 审批:_____________________ 日期:_____________________ WORD文档/ A4打印/ 可编辑 鱼骨图分析法(完整篇) Fishbone diagram analysis

鱼骨图分析法(完整篇) 导语:进行安全管理的目的是预防、消灭事故,防止或消除事故伤害,保护劳动者的安全与健康。在安全管理的四项主要内容中,虽然都是为了达到安全管理的目的,但是对生产因素状态的控制,与安全管理目的关系更直接,显得更为突出。 鱼骨分析法是咨询人员进行因果分析时经常采用的一种方法,其特点是简捷实用,比较直观。现以上面提到的某炼油厂情况作为实例,采用鱼骨分析法对其市场营销题进行解析。 鱼骨分析法简介 鱼骨图是由日本管理大师石川馨先生所发展出来的,故又名石川图。鱼骨图是一种发现问题“根本原因”的方法,它也可以称之为“因果图”。鱼骨图原本用于质量管理。 问题的特性总是受到一些因素的影响,我们通过头脑风暴找出这些因素,并将它们与特性值一起,按相互关联性整理而成的层次分明、条理清楚,并标出重要因素的图形就叫特性要因图。因其形状如鱼骨,所以又叫鱼骨图(以下称鱼骨图),它是一种透过现象看本质的分析方法。 头脑风暴法(BrainStorming——BS):一种通过集思广益、

发挥团体智慧,从各种不同角度找出问题所有原因或构成要素的会议方法。BS有四大原则:严禁批评、自由奔放、多多益善、搭便车。 鱼骨图的三种类型 A、整理问题型鱼骨图(各要素与特性值间不存在原因关系,而是结构构成关系) B、原因型鱼骨图(鱼头在右,特性值通常以“为什么……”来写) C、对策型鱼骨图(鱼头在左,特性值通常以“如何提高/改善……”来写) 鱼骨图制作 制作鱼骨图分两个步骤:分析问题原因/结构、绘制鱼骨图。 1、分析问题原因/结构。 A、针对问题点,选择层别方法(如人机料法环等)。 B、按头脑风暴分别对各层别类别找出所有可能原因(因素)。 C、将找出的各要素进行归类、整理,明确其从属关系。 D、分析选取重要因素。

最新功能点估算法介绍及应用

功能点估算法介绍及 应用

一、功能点估算法识别项目范围和数据复杂度 功能点估算法是软件项目管理众多知识中比较有技术含量的一个。在软件项目管理中项目计划制定的优劣直接关系到项目的成败,项目计划中对项目范围的估算又尤为重要。如果项目负责人对项目的规模没有一个比较客观的认识,没有对工作量、所需资源、完工时间等因素进行估算,那么项目计划也就没有存在的意义。 功能点估算法的特点 项目范围的估算在CMMI的“MA”度量分析管理和“PP”项目计划中均有涉及。对软件项目范围的估算有很多种方法,常见的是LOC代码行和FP功能点法。它们之间的区别和关系如下: ?功能点估算法常用在项目开始或项目需求基本明确时使用,这时进行估算其结果的准确性比较高。假如这个时候使用LOC代码行估算法,则误差会比较大。 ?使用功能点估算法无需懂得软件使用何种开发技术。LOC代码行估算法则与软件开发技术密切相关。 ?功能点估算法是以用户为角度进行估算,LOC代码行估算法则是以技术为角度进行估算。 ?通过一些行业标准或企业自身度量的分析,功能点估算法是可以转换为LOC代码行的。

在项目刚开始的时候进行功能点估算可以对项目的范围进行预测。在项目开发的过程中由于需求的变更和细化可能会导致项目范围的蔓延,计算出来的结果会与当初估计的不同。因此,在项目结束时还需要对项目的范围情况重新进行估算,这个时候估算的结果才能最准确反映项目的规模。 功能点分析的步骤 本文将以国际标准IFPUG(International Function Point Users Group)组织提供的功能点估算法V4.1.1为基础进行讲解。如下图所示,首先大家应该了解功能点估算法的使用步骤。 图1 功能点估算法的步骤 具体步骤包括: 1. 识别功能点的类型。 2. 识别待估算应用程序的边界和范围。 3. 计算数据类型功能点所提供的未调整的功能点数量。

功能点估算法

功能点估算法识别项目范围和数据复杂度 功能点估算法是软件项目管理众多知识中比较有技术含量的一个。在软件项目管理中项目计划制定的优劣直接关系到项目的成败,项目计划中对项目范围的估算又尤为重要。如果项目负责人对项目的规模没有一个比较客观的认识,没有对工作量、所需资源、完工时间等因素进行估算,那么项目计划也就没有存在的意义。 功能点估算法的特点 项目范围的估算在CMMI的“MA”度量分析管理和“PP”项目计划中均有涉及。对软件项目范围的估算有很多种方法,常见的是LOC代码行和FP功能点法。它们之间的区别和关系如下: ?功能点估算法常用在项目开始或项目需求基本明确时使用,这时进行估算其结果的准确性比较高。假如这个时候使用LOC代码行估算法,则误差会比较大。 ?使用功能点估算法无需懂得软件使用何种开发技术。LOC代码行估算法则与软件开发技术密切相关。 ?功能点估算法是以用户为角度进行估算,LOC代码行估算法则是以技术为角度进行估算。 ?通过一些行业标准或企业自身度量的分析,功能点估算法是可以转换为LOC代码行的。 在项目刚开始的时候进行功能点估算可以对项目的范围进行预测。在项目开发的过程中由于需求的变更和细化可能会导致项目范围的蔓延,计算出来的结果会与当初估计的不同。因此,在项目结束时还需要对项目的范围情况重新进行估算,这个时候估算的结果才能最准确反映项目的规模。 功能点分析的步骤 本文将以国际标准IFPUG(International Function Point Users Group)组织提供的功能点估算法V4.1.1为基础进行讲解。如下图所示,首先大家应该了解功能点估算法的使用步骤。

层次分析法实例与步骤(精)讲课教案

层次分析法实例与步 骤(精)

层次分析法实例与步骤 结合一个具体例子,说明层次分析法的基本步骤和要点。 【案例分析】市政工程项目建设决策:层次分析法问题提出 市政部门管理人员需要对修建一项市政工程项目进行决策,可选择的方案是修建通往旅游区的高速路(简称建高速路)或修建城区地铁(简称建地铁)。除了考虑经济效益外,还要考虑社会效益、环境效益等因素,即是多准则决策问题,考虑运用层次分析法解决。 1. 建立递阶层次结构 应用AHP解决实际问题,首先明确要分析决策的问题,并把它条理化、层次化,理出递阶层次结构。 AHP要求的递阶层次结构一般由以下三个层次组成: ●目标层(最高层):指问题的预定目标; ●准则层(中间层):指影响目标实现的准则; ●措施层(最低层):指促使目标实现的措施; 通过对复杂问题的分析,首先明确决策的目标,将该目标作为目标层(最高层)的元素,这个目标要求是唯一的,即目标层只有一个元素。 然后找出影响目标实现的准则,作为目标层下的准则层因素,在复杂问题中,影响目标实现的准则可能有很多,这时要详细分析各准则因素间的相互关系,即有些是主要的准则,有些是隶属于主要准则的次准则,然后根据这些关系将准则元素分成不同的层次和组,不同层次元素间一般存在隶属关系,即上一层元素由下一层元素构成并对下一层元素起支配作用,同一层元素形成若干组,同组元素性质相近,一般隶属于同一个上一层元素(受上一层元素支配),不同组元素性质不同,一般隶属于不同的上一层元素。 在关系复杂的递阶层次结构中,有时组的关系不明显,即上一层的若干元素同时对下一层的若干元素起支配作用,形成相互交叉的层次关系,但无论怎样,上下层的隶属关系应该是明显的。 最后分析为了解决决策问题(实现决策目标)、在上述准则下,有哪些最终解决方案(措施),并将它们作为措施层因素,放在递阶层次结构的最下面(最低层)。 明确各个层次的因素及其位置,并将它们之间的关系用连线连接起来,就构成了递阶层次结构。 【案例分析】市政工程项目进行决策:建立递阶层次结构

5M因素法(鱼骨图)分析案例

运用5M因素法(鱼骨图)分析及解决问题的实际操作案例 背景:某民营房地产集团公司下属商贸分公司,在自有房产基础上经营有超市5家, 经营业种以生鲜食品、传统食品、日用日化为主,总营业面积10000平方米;百货一家, 主要经营业种为服装针织、皮具、皮鞋、化妆品,小吃,营业面积4500平方米;正在筹备 中的购物中心18000平方米。 问题1 :经过统计商贸公司2001年9月一2002年3月的销售,总体毛利率为不到8%,注意:此毛利率是在公司无低毛利的家电以及百货毛利率近20%的基础上产生的总体毛利 率,相对于市场状况以及竞争对手来讲,此毛利率偏低,从中反映了占销售比重近80%的超市经营毛利不正常。 问题2 :经过进一步的市场调查,针对超市每个业种安排如下数量的市调(按销售数量排名),得出以下数据比较: 注:甲连锁店为一国营零售企业,在本地有34家连锁店,拥有诸多食品、日化产品的代理批发权; 乙连锁店为一民营连锁零售企业,现有18家分店,拥有部分食品、日化产品的批发代理权; 丙为一家200平方米左右的便利店; 将市调数据经过进一步分析,发现价格问题----[b]我司进价比竞争对手售价高[/h]的情况如下(先忽略在正常供价基础上零售价格异常状况): 感觉到问题的严重性,公司紧急召开了采购人员的专项会议,要求在规定时间内(一周) 针对以上问题各采购主任做出解释并及时与供应商进行谈判,希望能得到实质性的解决。

一周过去了,供价问题依然没有得到明显的改善,高出比例依然居高不下。总结各采购主任的解释,主要如下: 1、甲、乙对手拥有诸多敏感商品的控制权,近水楼台先得月,人家有权利及有实力去进行降价; 2、公司政策对于供应商的通道利润要求过高,厂商在无奈情况下,只有提高供价,保持其基本利润,如果要求供应商降价,只有舍弃部分通道利润才可行; 3、公司要求的经营方式过于呆板,竞争对手部分商品是从批发市场上进行铲货来冲击市场,而公司没有此先例,都是以正常方式进行经营; 4、公司的付款方式问题:由于现金进货与押款进货的供价有区别,但是公司最低的付款要求为7 天付款,因此在价格上没有办法降低; 5、竞争对手的恶意竞争行为:牺牲利润,亏本赚吆喝; 6、人手不够,杂事多,没有办法集中时间与精力与供应商谈判。 针对以上解释,公司明确回复:如果在有把握的情况下,以上由于公司自身原因造成的供价高的问题,可以放宽尺度与供应商进行交涉。 但是,一周时间过去了,问题仍然没有得到改善。 真的就是以上问题造成的吗?是主要的原因呢还是有其他的原因? 没有过多的责怪各采购主任,在随后的中层干部例会上,我将此问题谈了出来,然后让大家了解了什么是鱼骨图分析法(5M 因素分析法),希望通过大家的理解来讨论这个问题产生的根源所在,主要问题主要出现在哪些环节,哪些是需要重点解决的问题,哪些是虽然是先天的因素,但是可以通过努力去改进的环节,哪些是虽然由于条件的限制暂时不能改进但是可以通过改进其他问题予以弥补的问题。 5M 因素包括人、机、料、法、环5 个方面,“人”指的是造成问题产生人为的因素有哪些;“机”通俗一点就象战斗的武器,通指软、硬件条件对于事件的影响;“料”就如武器所用的子弹,指基础的准备以及物料;“法” 与事件相关的方式与方法问题是否正确有效;“环” 指的是内外部环境因素的影响。 5 个方面就象鱼的“主刺”一样,每个主刺上还有很多的小刺,这些小刺就是与主刺相关的问题,来构成了一条难以下咽的鱼骨头,如果不拔掉,一不小心就会卡住喉咙,让人痛苦不堪。

层次分析法的基本步骤和要点

层次分析法的基本步骤和要点 结合一个具体例子,说明层次分析法的基本步骤和要点。 【案例分析】市政工程项目建设决策:层次分析法问题提出 市政部门管理人员需要对修建一项市政工程项目进行决策,可选择的方案是修建通往旅游区的高速路(简称建高速路)或修建城区地铁(简称建地铁)。除了考虑经济效益外,还要考虑社会效益、环境效益等因素,即是多准则决策问题,考虑运用层次分析法解决。 1. 建立递阶层次结构 应用AHP解决实际问题,首先明确要分析决策的问题,并把它条理化、层次化,理出递阶层次结构。 AHP要求的递阶层次结构一般由以下三个层次组成: ●目标层(最高层):指问题的预定目标; ●准则层(中间层):指影响目标实现的准则; ●措施层(最低层):指促使目标实现的措施; 通过对复杂问题的分析,首先明确决策的目标,将该目标作为目标层(最高层)的元素,这个目标要求是唯一的,即目标层只有一个元素。 然后找出影响目标实现的准则,作为目标层下的准则层因素,在复杂问题中,影响目标实现的准则可能有很多,这时要详细分析各准则因素间的相互关系,即有些是主要的准则,有些是隶属于主要准则的次准则,然后根据这些关系将准则元素分成不同的层次和组,不同层次元素间一般存在隶属关系,即上一层元素由下一层元素构成并对下一层元素起支配作用,同一层元素形成若干组,同组元素性质相近,一般隶属于同一个上一层元素(受上一层元素支配),不同组元素性质不同,一般隶属于不同的上一层元素。 在关系复杂的递阶层次结构中,有时组的关系不明显,即上一层的若干元素同时对下一层的若干元素起支配作用,形成相互交叉的层次关系,但无论怎样,上下层的隶属关系应该是明显的。 最后分析为了解决决策问题(实现决策目标)、在上述准则下,有哪些最终解决方案(措施),并将它们作为措施层因素,放在递阶层次结构的最下面(最低层)。 明确各个层次的因素及其位置,并将它们之间的关系用连线连接起来,就构成了递阶层次结构。 【案例分析】市政工程项目进行决策:建立递阶层次结构 在市政工程项目决策问题中,市政管理人员希望通过选择不同的市政工程项目,使综合效益最高,即决策目标是“合理建设市政工程,使综合效益最高”。 为了实现这一目标,需要考虑的主要准则有三个,即经济效益、社会效益和环境效益。但问题绝不这么简单。通过深入思考,决策人员认为还必须考虑直接经济效益、间接经济效益、方便日常出行、方便假日出行、减少环境污染、改善城市面貌等因素(准则),从相互关系上分析,这些因素隶属于主要准则,因此放在下一层次考虑,并且分属于不同准则。 假设本问题只考虑这些准则,接下来需要明确为了实现决策目标、在上述准则下可以有哪些方案。根据题中所述,本问题有两个解决方案,即建高速路或建地铁,这两个因素作为措施层元素放在递阶层次结构的最下层。很明显,这两个方案于所有准则都相关。 将各个层次的因素按其上下关系摆放好位置,并将它们之间的关系用连线连接起来。同时,为了方便后面的定量表示,一般从上到下用A、B、C、D。。。代表不同层次,同一层次从左到右用1、2、3、4。。。代表不同因素。这样构成的递阶层次结构如下图。

整理的功能点计算法

整理的功能点计算法

功能点描述 功能点估算法是软件项目管理众多知识中比较有技术含量的一个。在软件项目管理中项目计划制定的优劣直接关系到项目的成败,项目计划中对项目范围的估算又尤为重要,如果项目负责人对项目的规模没有一个比较客观的认识,没有对工作量、所需资源、完工时间等因素进行估算,那么项目计划也就没有存在的意义。 项目范围的估算在CMMI的“MA”度量分析管理和“PP”项目计划中均有涉及,对软件项目范围的估算有很多种方法,常见的就是LOC代码行和FP功能点法,它们之间的区别和关系如下: 1、FP功能点估算法常用在项目开始或项目需求基本明确时使用,这时进行估算其结果的准确性比较高,假如这个时候使用LOC代码行估算法,则误差会比较大。 2、使用FP功能点估算法无需懂得软件使用何种开发技术。LOC代码行估算法与软件开发技术密切相关。 3、FP功能点法是以用户为角度进行估算,LOC代码行估算法则是以技术为角度进行估算的。 4、通过一些行业标准或企业自身度量的分析,FP功能点估算法是可以转换为LOC代码行的。在项目刚开始的时候进行功能点估算可以对项目的范围进行预测,在项目开发的过程中由于需求的变更和细化可能会导致项目范围的蔓延,计算出来的结果会与当初估计的不同,因此在项目结束时还需要对项目的范围情况进行估算,这个时候估算的结果才能最准确反映项目的规模。 功能点的公式: ●功能点的原始计算公式:FP Count =UFP * VAF ●新开发项目有时新开发的软件项目也需要与其他现存的软件系统进行整合,例如:一个企业新开发的MIS 内部管理系统经常会与财务系统进行整合。这个时候除了考虑本身项目的功能点个数外,还要考虑系统整合或数据迁移部分的工作量,因此其功能点计算公式如下:FP Count =(UFP+CFP)* VAF ●二次开发的项目有时新开发的软件项目是在原有基础上进行二次开发的,只是为了增加一些新的功 能,因此其功能点计算公式如下:FP Count = ADD * VAF

功能点估算法

功能点估算法是软件项目管理众多知识中比较有技术含量的一个。在软件项目管理中项目计划制定的优劣直接关系到项目的成败,项目计划中对项目范围的估算又尤为重要,如果项目负责人对项目的规模没有一个比较客观的认识,没有对工作量、所需资源、完工时间等因素进行估算,那么项目计划也就没有存在的意义。 FP功能点估算法的特点 项目范围的估算在CMMI的“MA”度量分析管理和“PP”项目计划中均有涉及,对软件项目范围的估算有很多种方法,常见的就是LOC代码行和FP功能点法,它们之间的区别和关系如下: 1、 FP功能点估算法常用在项目开始或项目需求基本明确时使用,这时进行估算其结果的准确性比较高,假如这个时候使用LOC代码行估算法,则误差会比较大。 2、使用FP功能点估算法无需懂得软件使用何种开发技术。LOC代码行估算法与软件开发技术密切相关。 3、 FP功能点法是以用户为角度进行估算,LOC代码行估算法则是以技术为角度进行估算的。 4、通过一些行业标准或企业自身度量的分析,FP功能点估算法是可以转换为LOC代码行的。 在项目刚开始的时候进行功能点估算可以对项目的范围进行预测,在项目开发的过程中由于需求的变更和细化可能会导致项目范围的蔓延,计算出来的结果会与当初估计的不同,因此在项目结束时还需要对项目的范围情况进行估算,这个时候估算的结果才能最准确反映项目的规模。 功能点分析的步骤 在本文中将以国际标准IFPUG(International Function Point Users Group)组织提供的功能点估算法V4.1.1为基础与大家进行讲解。如下图所示,首先大家应该了解功能点估算法的使用步骤。 功能点估算的步骤 1、识别功能点的类型。 2、识别待估算应用程序的边界和范围。 3、计算数据类型功能点所提供的未调整的功能点数量。

层次分析法的基本步骤和要点

层次分析法的基本步骤与要点 结合一个具体例子,说明层次分析法的基本步骤与要点。 【案例分析】市政工程项目建设决策:层次分析法问题提出 市政部门管理人员需要对修建一项市政工程项目进行决策,可选择的方案就是修建通往旅游区的高速路(简称建高速路)或修建城区地铁(简称建地铁)。除了考虑经济效益外,还要考虑社会效益、环境效益等因素,即就是多准则决策问题,考虑运用层次分析法解决。 1、建立递阶层次结构 应用AHP解决实际问题,首先明确要分析决策的问题,并把它条理化、层次化,理出递阶层次结构。 AHP要求的递阶层次结构一般由以下三个层次组成: ●目标层(最高层):指问题的预定目标; ●准则层(中间层):指影响目标实现的准则; ●措施层(最低层):指促使目标实现的措施; 通过对复杂问题的分析,首先明确决策的目标,将该目标作为目标层(最高层)的元素,这个目标要求就是唯一的,即目标层只有一个元素。 然后找出影响目标实现的准则,作为目标层下的准则层因素,在复杂问题中,影响目标实现的准则可能有很多,这时要详细分析各准则因素间的相互关系,即有些就是主要的准则,有些就是隶属于主要准则的次准则,然后根据这些关系将准则元素分成不同的层次与组,不同层次元素间一般存在隶属关系,即上一层元素由下一层元素构成并对下一层元素起支配作用,同一层元素形成若干组,同组元素性质相近,一般隶属于同一个上一层元素(受上一层元素支配),不同组元素性质不同,一般隶属于不同的上一层元素。 在关系复杂的递阶层次结构中,有时组的关系不明显,即上一层的若干元素同时对下一层的若干元素起支配作用,形成相互交叉的层次关系,但无论怎样,上下层的隶属关系应该就是明显的。 最后分析为了解决决策问题(实现决策目标)、在上述准则下,有哪些最终解决方案(措施),并将它们作为措施层因素,放在递阶层次结构的最下面(最低层)。 明确各个层次的因素及其位置,并将它们之间的关系用连线连接起来,就构成了递阶层次结构。 【案例分析】市政工程项目进行决策:建立递阶层次结构 在市政工程项目决策问题中,市政管理人员希望通过选择不同的市政工程项目,使综合效益最高,即决策目标就是“合理建设市政工程,使综合效益最高”。 为了实现这一目标,需要考虑的主要准则有三个,即经济效益、社会效益与环境效益。但问题绝不这么简单。通过深入思考,决策人员认为还必须考虑直接经济效益、间接经济效益、方便日常出行、方便假日出行、减少环境污染、改善城市面貌等因素(准则),从相互关系上分析,这些因素隶属于主要准则,因此放在下一层次考虑,并且分属于不同准则。 假设本问题只考虑这些准则,接下来需要明确为了实现决策目标、在上述准则下可以有哪些方案。根据题中所述,本问题有两个解决方案,即建高速路或建地铁,这两个因素作为措施层元素放在递阶层次结构的最下层。很明显,这两个方案于所有准则都相关。 将各个层次的因素按其上下关系摆放好位置,并将它们之间的关系用连线连接起来。同时,为了方便后面的定量表示,一般从上到下用A、B、C、D。。。代表不同层次,同一层次从左到右用1、2、3、4。。。代表不同因素。这样构成的递阶层次结构如下图。

因果图分析法实例讲解

因果图分析法: 前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑 输入条件之间的联系, 相互组合等。考虑输入条件之间的相互组合,可能会产生一些新的情况。但要检查输入条件的组合不是一件容易的事情,即使把所有输入条件划分成等价类,他们之间的组合情况也相当多。因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例。这就需要利用因果图(逻辑模型)。 因果图方法最终生成的就是判定表,它适合于检查程序输入条件的各种组合情况。 因果图中使用了简单的逻辑符号,以直线联接左右结点。左结点表示输入状态(或 称原因),右结点表示输出状态(或称结果)。 ci 表示原因,通常置于图的左部;ei 表示结果,通常在图的右部。ci 和ei 均可取值 0或1,0表示某状态不出现,1表示某状态出现。 4种符号分别表示了规格说明中向4种因果关系。如上图所示。 ①恒等:若ci 是1,则ei 也是1;否则ei 为0。 ②非:若ci 是1,则ei 是0;否则ei 是1。 ③或:若c1或c2或c3是1,则ei 是1;否则ei 为0。“或”可有任意个输入。 ④与:若c1和c2都是1,则ei 为1;否则ei 为0。“与”也可有任意个输入。 因果图概念--约束 输入状态相互之间还可能存在某些依赖关系,称为约束。例如, 某些输入条件本身不可能同时出现。输出状态之间也往往存在约束。在因果图中,用特定的符号标明这些约束。 A.输入条件的约束有以下4类: ① E 约束(异):a 和b 中至多有一个可能为1,即a 和b 不能同时为1。 ② I 约束(或):a 、b 和c 中至少有一个必须是1,即 a 、b 和c 不能同时为0。 ③ O 约束(唯一);a 和b 必须有一个,且仅有1个为1。 ④R 约束(要求):a 是1时,b 必须是1,即不可能a 是1时b 是0。 B.输出条件约束类型 (d )与

功能点估算法介绍及应用

一、功能点估算法识别项目范围和数据复杂度 功能点估算法是软件项目管理众多知识中比较有技术含量的一个。在软件项目管理中项目计划制定的优劣直接关系到项目的成败,项目计划中对项目范围的估算又尤为重要。如果项目负责人对项目的规模没有一个比较客观的认识,没有对工作量、所需资源、完工时间等因素进行估算,那么项目计划也就没有存在的意义。 功能点估算法的特点 项目范围的估算在CMMI的“MA”度量分析管理和“PP”项目计划中均有涉及。对软件项目范围的估算有很多种方法,常见的是LOC代码行和FP功能点法。它们之间的区别和关系如下: ?功能点估算法常用在项目开始或项目需求基本明确时使用,这时进行估算其结果的准确性比较高。假如这个时候使用LOC代码行估算法,则误差会 比较大。 ?使用功能点估算法无需懂得软件使用何种开发技术。LOC代码行估算法则与软件开发技术密切相关。 ?功能点估算法是以用户为角度进行估算,LOC代码行估算法则是以技术为角度进行估算。 ?通过一些行业标准或企业自身度量的分析,功能点估算法是可以转换为LOC代码行的。 在项目刚开始的时候进行功能点估算可以对项目的范围进行预测。在项目开发的过程中由于需求的变更和细化可能会导致项目范围的蔓延,计算出来的结果会与当初估计的不同。因此,在项目结束时还需要对项目的范围情况重新进行估算,这个时候估算的结果才能最准确反映项目的规模。 功能点分析的步骤 本文将以国际标准IFPUG(International Function Point Users Group)组织提供的功能点估算法V4.1.1为基础进行讲解。如下图所示,首先大家应该了解功能点估算法的使用步骤。

软件功能点估算

软件功能点估算 为了能更好地理解和掌握软件功能点估算的一些规则,本文通过介绍一个需求实例来展开软件功能点估算的介绍,欢迎各位专家批评指正。 新增需求:实现一个订单的录入,更新,删除、查询、打印、导出功能,其中用户界面如下。订单明细包含了订购的具体产品及数量的情况,明细记录数原则不限。导出、打印、更新、删除订单记录应先从图2的查询界面查出记录,再鼠标双击某记录进入图1的增、删、改界面,也可以选择修改或删除菜单后输入订单号进入图1的增、删、改界面,新增时订单编号自动产生,更新时订单编号不能修改。订单的明细记录在增、删、改界面可进行删除或添加处理,要添加时通过鼠标定位在编辑区按右键选择添加功能,然有会弹出一个产品列表来供操作者选择,材料代码和材料名称及单价是通过选择后自动添加的,不能人工修改,操作者只能修改订单数量,要删除时也通过鼠标定位在编辑区的某产品上按右键选择删除功能即可。打印版面通过打印模板定制并打印到打印机、导出版面也通过excel模板定制并输出到excel文件。其他说明: 1、用户表和产品数据表本次不变,订单功能开发仅仅是引用这些数据。

2、暂不考虑其它特殊业务逻辑和权限,如:不写日志、功能按钮不根据权限加以屏蔽。 功能界面情况如下: 图1:增、删、改界面 图2:查询界面 功能点分析: 1、首先我们来确定本功能涉及到哪些用户数据(ILF,EIF)因为新增需求是订单管理,故订单信息属于一个,另外在需求中提到用户表和产品数据表本次不变,订单功能开发仅仅是引用这些数据,所以用户信息和产品信息也是系统的ILF 或EIF,只不过本次新增需求时不计算它的ILF或EIF功能点,因为它没有改变,相信引用它的方式与以前一样,但在EI、EO、EQ中引用需要考虑其FTR复杂度。另外,需求又要求打印和导出需要使用版面模板,故应该有三个模本文件。订单类型没有提及需要动态从系统内部获取,根据一般经验应该是一个在程序中做死的下拉选择列表,到此这个新增需求涉及的ILF,EIF应为如下内容:用户数据列表 文件描述

功能点估算(CMMI-FP)含例子

功能点估算(CMMI-FP)含例子 功能点估算法是软件项目管理众多知识中比较有技术含量的一个。在软件项目管理中项目计划制定的优劣直接关系到项目的成败,项目计划中对项目范围的估算又尤为重要。如果项目负责人对项目的规模没有一个比较客观的认识,没有对工作量、所需资源、完工时间等因素进行估算,那么项目计划也就没有存在的意义。 功能点估算法的特点 项目范围的估算在CMMI的“MA”度量分析管理和“PP”项目计划中均有涉及。对软件项目范围的估算有很多种方法,常见的是LOC代码行和FP功能点法。它们之间的区别和关系如下: ?功能点估算法常用在项目开始或项目需求基本明确时使用,这时进行估算其结果的准确性比较高。假如这个时候使用LOC代码行估算法,则误差会比较大。 ?使用功能点估算法无需懂得软件使用何种开发技术。LOC代码行估算法则与软件开发技术密切相关。 ?功能点估算法是以用户为角度进行估算,LOC代码行估算法则是以技术为角度进行估算。 ?通过一些行业标准或企业自身度量的分析,功能点估算法是可以转换为LOC代码行的。 在项目刚开始的时候进行功能点估算可以对项目的范围进行预测。在项目开发的过程中由于需求的变更和细化可能会导致项目范围的蔓延,计算出来的结果会与当初估计的不同。因此,在项目结束时还需要对项目的范围情况重新进行估算,这个时候估算的结果才能最准确反映项目的规模。 功能点分析的步骤 本文将以国际标准IFPUG(International Function Point Users Group)组织提供的功能点估算法V4.1.1为基础进行讲解。如下图所示,首先大家应该了解功能点估算法的使用步骤。

5M因素法(鱼骨图)及其案例分析实例

案例分析方法:5M因素法(鱼骨图)及其案例分 析实例 发布时间:2010-09-28 (来源:应届毕业生求职网) 运用5M因素法(鱼骨图)分析及解决问题的实际操作案例 背景:某民营房地产集团公司下属商贸分公司,在自有房产基础上经营有超市5家,经营业种以生鲜食品、传统食品、日用日化为主,总营业面积10000平方米;百货一家,主要经营业种为服装针织、皮具、皮鞋、化妆品,小吃,营业面积4500平方米;正在筹备中的购物中心18000平方米。 问题1:经过统计商贸公司2001年9月—2002年3月的销售,总体毛利率为不到8%,注意:此毛利率是在公司无低毛利的家电以及百货毛利率近20%的基础上产生的总体毛利率,相对于市场状况以及竞争对手来讲,此毛利率偏低,从中反映了占销售比重近80%的超市经营毛利不正常。 问题2:经过进一步的市场调查,针对超市每个业种安排如下数量的市调(按销售数量排名),得出以下数据比较: 注:甲连锁店为一国营零售企业,在本地有34家连锁店,拥有诸多食品、日化产品的代理批发权;

乙连锁店为一民营连锁零售企业,现有18家分店,拥有部分食品、日化产品的批发代理权; 丙为一家200平方米左右的便利店; 将市调数据经过进一步分析,发现价格问题----我司进价比竞争对手售价高的情况如下(先忽略在正常供价基础上零售价格异常状况): 感觉到问题的严重性,公司紧急召开了采购人员的专项会议,要求在规定时间内(一周)针对以上问题各采购主任做出解释并及时与供应商进行谈判,希望能得到实质性的解决。 一周过去了,供价问题依然没有得到明显的改善,高出比例依然居高不下。总结各采购主任的解释,主要如下: 1、甲、乙对手拥有诸多敏感商品的控制权,近水楼台先得月,人家有权利及有实力去进行降价; 2、公司政策对于供应商的通道利润要求过高,厂商在无奈情况下,只有提高供价,保持其基本利润,如果要求供应商降价,只有舍弃部分通道利润才可行; 3、公司要求的经营方式过于呆板,竞争对手部分商品是从批发市场上进行铲货来冲击市场,而公司没有此先例,都是以正常方式进行经营; 4、公司的付款方式问题:由于现金进货与押款进货的供价有区别,但是公司最低的付款要求为7天付款,因此在价格上没有办法降低;

层次分析法案例与步骤

层次分析法实例与步骤 下面结合一个具体例子,说明层次分析法的基本步骤和要点。 【案例】 市政工程项目建设决策:层次分析法问题提出 市政部门管理人员需要对修建一项市政工程项目进行决策,可选择的方案是修建通往旅游区的高速路(简称建高速路)或修建城区地铁(简称建地铁)。除了考虑经济效益外,还要考虑社会效益、环境效益等因素,即是多准则决策问题,考虑运用层次分析法解决。 1. 建立递阶层次结构 应用AHP解决实际问题,首先明确要分析决策的问题,并把它条理化、层次化,理出递阶层次结构。 AHP要求的递阶层次结构一般由以下三个层次组成: ●目标层(最高层):指问题的预定目标; ●准则层(中间层):指影响目标实现的准则; ●措施层(最低层):指促使目标实现的措施; 通过对复杂问题的分析,首先明确决策的目标,将该目标作为目标层(最高层)的元素,这个目标要求是唯一的,即目标层只有一个元素。 然后找出影响目标实现的准则,作为目标层下的准则层因素,在复杂问题中,影响目标实现的准则可能有很多,这时要详细分析各准则因素间的相互关系,即有些是主要的准则,有些是隶属于主要准则的次准则,然后根据这些关系将准则元素分成不同的层次和组,不同层次元素间一般存在隶属关系,即上一层元素由下一层元素构成并对下一层元素起支配作用,同一层元素形成若干组,同组元素性质相近,一般隶属于同一个上一层元素(受上一层元素支配),不同组元素性质不同,一般隶属于不同的上一层元素。 在关系复杂的递阶层次结构中,有时组的关系不明显,即上一层的若干元素同时对下一层的若干元素起支配作用,形成相互交叉的层次关系,但无论怎样,上下层的隶属关系应该是明显的。 最后分析为了解决决策问题(实现决策目标)、在上述准则下,有哪些最终解决方案(措施),并将它们作为措施层因素,放在递阶层次结构的最下面(最低层)。 明确各个层次的因素及其位置,并将它们之间的关系用连线连接起来,就构成了递阶层次结构。 【案例分析】市政工程项目进行决策:建立递阶层次结构 在市政工程项目决策问题中,市政管理人员希望通过选择不同的市政工程项目,使综合效益最高,即决策目标是“合理建设市政工程,使综合效益最高”。 为了实现这一目标,需要考虑的主要准则有三个,即经济效益、社会效益和环境效益。但问题绝不这么简单。通过深入思考,决策人员认为还必须考虑直接经济效益、间接经济效益、方便日常出行、方便假日出行、减少环境污染、改善城市面貌等因素(准则),从相互关系上分析,这些因素隶属于主要准则,因此放在下一层次考虑,并且分属于不同准则。 假设本问题只考虑这些准则,接下来需要明确为了实现决策目标、在上述准则下可以有哪些方案。根据题中所述,本问题有两个解决方案,即建高速路或建地铁,这两个因素作为措施层元素放在递阶层次结构的最下层。很明显,这两个方案于所有准则都相关。 将各个层次的因素按其上下关系摆放好位置,并将它们之间的关系用连线连接起来。同时,为了方便后面的定量表示,一般从上到下用A、B、C、D。。。代表不同层次,同一层次从左到右用1、2、3、4。。。代表不同因素。这样构成的递阶层次结构如下图。

CMMI之功能点估算法---内部逻辑文件和外部接口文件

CMMI之功能点估算法---内部逻辑文件和外部接口文件 2008-01-24 作者:张瑾 关键词:CMMI、软件工程、MA、度量、PP、项目计划、项目估算 功能点估算法是软件项目管理众多知识中比较有技术含量的一个。在软件项目管理中项目计划制定的优劣直接关系到项目的成败,项目计划中对项目范围的估算又尤为重要,如果项目负责人对项目的规模没有一个比较客观的认识,没有对工作量、所需资源、完工时间等因素进行估算,那么项目计划也就没有存在的意义。 FP功能点估算法的特点 项目范围的估算在CMMI的“MA”度量分析管理和“PP”项目计划中均有涉及,对软件项目范围的估算有很多种方法,常见的就是LOC代码行和FP功能点法,它们之间的区别和关系如下: 1.FP功能点估算法常用在项目开始或项目需求基本明确时使用,这时进行估算其结果的 准确性比较高,假如这个时候使用LOC代码行估算法,则误差会比较大。 2.使用FP功能点估算法无需懂得软件使用何种开发技术。LOC代码行估算法与软件开 发技术密切相关。 3.FP功能点法是以用户为角度进行估算,LOC代码行估算法则是以技术为角度进行估 算的。 4.通过一些行业标准或企业自身度量的分析,FP功能点估算法是可以转换为LOC代码 行的。 在项目刚开始的时候进行功能点估算可以对项目的范围进行预测,在项目开发的过程中由于需求的变更和细化可能会导致项目范围的蔓延,计算出来的结果会与当初估计的不同,因此在项目结束时还需要对项目的范围情况进行估算,这个时候估算的结果才能最准确反映项目的规模。 功能点分析的步骤 在本文中将以国际标准IFPUG(International Function Point Users Group)组织提供的功能点估算法V4.1.1为基础与大家进行讲解。如下图所示,首先大家应该了解功能点估算法的使用步骤。

相关文档