软件造价是软件工程的一个重要内容,涉及服务的标准实际上也是近期的一个焦点。说到信息工程造价,国家的GB/T36964-2018《软件工程软件开发成本度量规范》出台,算是给这个江湖定了基本的规矩。但是,功能点计数法在实际实施时,还是拍脑袋为主。基本模式是,现有领导决定大致预算,下面人员根据预算来确定大致需求。
一、估算过程 :
通常过程: 估算软件规模-----估算工作量---估算工期、成本----项目要素调整---确定软件研发成本---关键是估算工作量。
估算时机:一般是规划、前期研究、招投标、项目策划、变更控制等时点。
二、常用方法
经验法:俗称拍脑袋,是最好用的方法,也是最常用的方法。 比如拍脑袋,进阶版有基于WBS的分开拍脑袋;DELPHI/加权一起拍脑袋;关键是找领导和专家来拍脑袋。千万别找程序员或者产品经理来拍脑袋,程序员拍脑袋最好乘上10.
类推法:应该是最可靠的估算方法。结果经常产生很大偏差。一般是按照已有的同类项目经验来估算,进行经验类推。关键是有很多“同类”的假设,实际不一定是成立的。
类比法:基于基准数据量化,属于以算为主的方法。通常以50百分位为参考而非均值。
方程法:基于基准数据建模。一般与行业数据、企业数据相结合。
常用的方法比如IFPUG(4.1,3.0)、NESMA,已经形成标准。误差相对较小。但关键在于,需求文件要比较明确。NESMA分为预估功能点、估算功能点、详细功能点三种。对于一个组织而言,好的估算方法应该可以系统地持续改进。而非完全依赖于个人经验。换句话说,个人经验、项目团队经验要通过软件工程量化,逐步沉淀成组织资产。
三、快速功能点估算方法(NESMA)
1 NESMA方法3种应用场景
a) 预估功能点(简化一)
功能点规模统计只识别ILF和EIF文件,可用于预算或招投标阶段,采用如下公式计算:
功能点数≈35*ILF+15*EIF
这一公式基于如下假设:平均情况下,每个ILF对应3个EI、2个EO和1个EQ,每个EIF对应1个EO和1个EQ,35和15是将上述ILF、EIF、EI、EO、EQ的复杂度默认为中,再考虑系统整体的功能性得出的。
b) 估算功能点(简化二)
功能点规模统计仍是5类基本功能组件的功能点数之和,采用如下公式计算:
功能点数=10*ILF+7*EIF+4*EI+5*EO+4*EQ
这一公式基于如下假设:将ILF、EIF、EI、EO、EQ的复杂度默认为中,其他步骤与IFPUG方法一样。
c) 详细功能点
识别5类基本功能组件的功能点数,并根据复杂度决定取值后计算见表5.2。
NESMA的两种简化方法都是基于“默认”值来计算的,根据大量样本项目分析,此种计算结果与IFPUG方法得到的结果的平均值相近,但对个体项目,特别是小型项目常有较大差异。
在规模估算时,应考虑可能的需求变更程度,并对规模估算结果进行适当调整。据北京软件造价评估技术创新联盟统计数据,规模变更因子预算时取值为2,招标时取值为1.5,投标为1.26;项目计划为1.26,软件开发团队也可以根据具体情况进行调整,如根据组织内项目规模变更统计数据校正此数据。
2 NESMA方法估算过程
1、识别应用类型(新开发/增强)-----2、识别系统边界(事务功能应穿越系统边界) ---- 3、识别功能点计数项(预估ILF、EIF;估算EI/EO/EQ)-----4、识别计数项复杂度(预估和估算功能点方法不需要)-------5、得到未调整功能点数UFP-------6、 计算调整因子VAF-------------7、得到调整后功能点AFP
常用的有:
a规模维度 (根据不同时期确定不同变更因子)、
b工作量维度(软件因素:包括规模、应用类型、业务领域、质量要求)
c 工作量维度(开发因素:包括开发语言、团队经验、重用)
3 NESMA估算关键点
功能点分为事务功能类、数据功能类。
1)数据功能类
其中:EIF、ILF属于数据功能类。识别的关键就是需求中的名词。优先识别为ILF。多个模块重复操作只识别1次。
ILF识别的关键:业务数据(如业务处理形成的数据)、引用数据(如业务规则)、编码数据(如码表、字典、用户不可维护的数据)。
一个逻辑文件必须是用户可以理解、对其操作是业务需求、存在逻辑差异、独立没有从属关系:
a、编码数据及其相关功能不计入功能规模。
b、 子表依赖于主要信息,不单独识别为ILF。
c、对单个ILF一定包含写操作。
EIF识别的关键:本系统引用、逻辑上的文件、在系统外部维护。
a、是文件,而非外部系统或接口;
b、实现方式不影响计数结果;
c、维护是指逻辑上而非物理上维护或存储
2)事务功能类
EI/EO/EQ是基本过程。基本过程要求,产生基本的业务价值、是业务上的原子操作、操作后系统进入相对稳定状态,一般包括增删改查等。
不稳定状态(如导入过程中的输入目标地址、注册过程的验证邮件、身份证有效性)是中间过程,一般稳定状态的操作结果会被保存下来。
EI:对ILF进行维护,如增删改,从外部读取并存储到ILF,接受输入信号并改变系统状态、行为
EO:是一个完整的基本过程;对内部数据的计算、统计分析等;通过处理逻辑表示、发送信息
EQ:是一个完整的基本过程,对内部数据的简单输出(不计算,但可以筛选、分组、排序等),不能计算、产生衍生数据、不能维护ILF、不改变系统行为
在对某些数据进行删改的时候,往往隐含EQ。触发基本过程的用户、系统调用、定时器等触发源也是需求书写要点;需求的动作是书写的重点。
单个需求涉及操作太多(一般是6个,超过8个一般就是太多了),可能需要分解需求。
4 规模调整
常用的有:
a规模维度 (根据不同时期确定不同变更因子)、
b工作量维度(软件因素:包括规模、应用类型、业务领域、质量要求)、
c 工作量维度(开发因素:包括开发语言、团队经验、重用) ,这个需要根据实际情况来确定。也是企业工程资产库的重点。
四、 软件造价估算
这个需要参考行业协会等权威机构的数据:主要是人月费率、利润率。各地都有不同,一般要依据政策性标准或行业性发布数据来计算,不适合自己发挥。
当然通常是先估算好内部的费用,再来套费率和工作量。这时候内部估算成本可以参考下面的内容。
需要考虑:
直接人力成本:开发项目组人员、项目组支持人员,非全职的按比例折算
直接非人力成本:项目组的开发办公费、差旅费、培训费、业务费、采购费、其他。
间接人力成本:摊销的组织管理人员、组织QA人员、组织SCM等
间接非人力成本:研发人员分摊的办公场地费用、办公费用等