软件造价成本估算：NESMA方法简介

    软件造价是软件工程的一个重要内容，涉及服务的标准实际上也是近期的一个焦点。说到信息工程造价，国家的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等

• 间接非人力成本：研发人员分摊的办公场地费用、办公费用等