当前位置:文档之家› 软件造价培训 教程

软件造价培训 教程

2019
软件造价培训
01
03
02
01
主要原因
软件管理现状
软件量化管理缺乏科学统一的可比的一套标准体系
模型法(方程法)
PERT法
最悲观值(Optimistic);最可能值(Most likely);最乐观值(Pessimistic)估算值=(P+4M+O)/6; 标准差=(P-O)/6
经验法
软件成本估算方法
DELPHI法
组织3名以上专家对目标进行估算 召集专家讨论估算相关因素 匿名填写估算表格
设定估算接受的目标要求
类比法/类推法
是否有同类型项目的经验
这个经验是否适合当前的项目(应用在没有数据的情况下)
是否有同类型项目的经验
这个经验是否适合当前的项目当需求极其模糊或不确定时,如果此时有与本项目类似属性(如规模、应用类型、复杂度、开发团队经验等)的一组基准数据,则可直接采用类比法,充分利用基准数据来估算工作量。

类比法 可以在整个项目级上做基准比对, 也可以在子系统级上进行。

使用PERT计算工期的前提:工作分解结构WBS(Work Breakdown Structure)分解到位,相应各任务能根据历史及经验进行准确估算。

质量
工期
成本
规模估算
工作量估算
软件项目度量的核心
采用国际标准考虑规模需求变更调整因子
软件成本度量基础
成本估算
基于行业数据建立模型
引入软件因子和开发因子
参照行业数据采用基准对比方法
估算要点
测量值: 规模、工作量、工期、缺陷、成本 派生测量值:生产率、费率、缺陷密度
基准数据2018在软件开发人月费率方面北京仍然为A类城市中最高的,达到了2.7万/人月,项目功能点单价基准为1099.05元/功能点实际广州标准为:3.23W/人月,软件运维人月费率A类城市中上海为最高,达到了2.26万元/人月。

02
物理度量
技术估摸
功能规模
纸袋度量程序字节数
代码行函数个数数据库表模块类的数量
用例点功能点用户故事点数页面数窗口数按钮数
软件规模度量
功能点的方法:从用户角度出发
基于模型、规则和方法,对功能需求进行分析和度量功能点单位FP
功能点方法
目前ISO标准ISO/IEC 14143 认可有5 种度量软件项目规模的方法,分别是:英国人Charles Symon提出的Mark Ⅱ功能点标准;
加拿大非盈利织COSMIC 提出的COSMIC 功能点
芬兰软件度量协会提出的Fisma 功能点标准;
有荷兰软件度量协会提出的NESMA 功能点标准;
美国IFPUG 组织提出的功能点标准。

五种功能点标准有何区别
功能点标准功能点类型应用范围操作难度
IFPUG标准五种功能点:
ILF、EIF、EI、
EO、EQ 适用于所有项
目,尤其适用
于MIS类项目
适中。

IFPUG功能点标准基于明确的规则约束,因而能保证软件规模评估结果的客观性和一致
性。

因为IFPUG是目前应用最普遍的功能点度量方法,因而有较多的资源可以借鉴和参考,例
如IFPUG功能点相关的书籍、标准、文章、论坛、从业人员等资源都可以方便地得到。

MarkII标准一种功能点:
逻辑事务适用于所有项
目,尤其适用
于MIS类项目
简单。

MarkII功能点标准操作简单,只需进行简单的加权计算即可。

但标准缺乏对基本元素
的识别规则,例如对数据元素、逻辑事务仅采用举例的方式加以说明,实际操作过程中可能
会出现歧义,度量结果的一致性不强。

Nesma标准五种功能点:
ILF、EIF、EI、
EO、EQ 适用于所有项
目,尤其适用
于MIS类项目。

适中。

Nesma标准对IFPUG标准作了最“忠实”的借鉴,但也作了一些有别于IFPUG的规定,例
如对代码数据进行度量、对隐含查询不予考虑,这些规定尽管在实际操作中有其合理的一面,
但是却破坏了IPFUG规则的完整性和一致性。

Cosmic标准四种功能类型:
进入、离开、
读、写适用于所有项
目,尤其适用
于实时类应用
较高。

Cosmic借鉴了IFPUG功能点标准中基于规则约束的实践,但引入了分层(Layer)概念,
在评估功能规模时需要考虑软件的技术因素,从而减弱了软件功能点对业务人员透明的优势。

Fisma标准七种功能类型适用于所有项
目,要求了解
被度量应用的
技术实现方式。

很高。

Fisma强调采用“服务”替代“功能”,因而更能反映软件的特性。

但其功能分类的数量繁多,并且每种服务都采用不同数值的加权系数,因而操作很困难。

Nesma功能点方法
外部查询(EQ External Inquiry)
发送数据或控制信息到应用程序边界外的一个基本处理,其主要目的是通过检索来自内部逻辑文件或外部接口文件的数据或控制信息,向用户提供信息。

处理逻辑既不包含数学公式或计算,也不创建新的数据。

处理期间不维护内部逻辑文件,也不改变系统行为。

外部输入(EI External Input)
数据或控制信息由外向内穿越应用程序边界的一个基本处理过程,其主要目的是维护一个或多个 内部逻辑文件和/或改变系统行为。

外部输出(EO External Output)
发送数据或控制信息到应用程序边界外的一个基本处理,其主要目的是通过检索数据或控制信息, 此外还通过处理逻辑来向用户提供信息,其处理逻
辑必须包含至少一个数学公式或计算,或创建派生 的数据。

一个外部输出也可以维护一个或多个内部逻辑文件,和/或改变系统行为。

内部逻辑文件(ILF Internal Logical File)
在应用程序边界内维护的用户可识别的逻辑相关数据组或控制信息。

其主要目的是保存由被计数的应用程序的一个或多个基本处理所维护的
数据。

外部接口文件(EIF External Interface File)
被一应用程序引用但在另一应用程序边界内被维护的,用户可识别的逻辑相关数据组或控制信息, 其主要目的是保存由被计数的应用程序边
界内的一个或多个基本处理所引用的数据。

(1)数据类型:ILF、EIF
(2)事务类型:EI、EO、EQ
功能点估算类型
识别文件ILF/EIF
识别过程EI/EO/EQ
判断复杂度FTR/DET/RET
指示功能点计数
估算功能点计数
详细功能点计数
UFP=35*ILF+15*EIF
UFP=7*ILF+5*EIF+4*EI +5*EO+4*EQ
UFP=每个功能点的UFP之和
S=UFP*CF
(需求有变更的,预算阶段CF-2,招标阶段1.5,投标1.26)
预算、招标以及需求分析
投标以及项目分析
功能设计后的各阶段
复杂度
⏹数据元素类型(DET)
--Data Element Type
--用户能够识别的不重复的元素
⏹记录类型(RET)
--Record Element Type
--指一个ILF或EIF中用户可以识别的数据的子集
⏹引用文件类型(FTR)
--File Type Referenced
--一个被EI/EO/EQ维护的ILF或是读取的EIF
详细估算方法
EI、EO、EQ、ILF和EIF技术复杂度对应的功能点如下表所示:
UFP=每个功能点的UFP之和
功能设计后的各阶段
案例
指出下面需求中的ILF,EIF,EI,EO,EQ
以外贸订单系统项目为例:
录入订单、修改订单、删除订单是EI;
查询订单是EO
统计订单是EQ
汇率查询转换系统为EIF
订单和客户是ILF
03
国家标准《GB/T 36964-2018 软件工程 软件开发成本度量规范》中建议的软件成本估算基本流程如下图所示:软件规模估算
2019
谢谢大家。

相关主题