基于 功能点 估算项目规模 FPA，以及估算软件开发成本 [更新]
Table of Contents
FPA估算的 项目规模，是指软件开发的项目规模，包含了需求分析、设计、编码、测试 等活动，但不包含项目管理，软件维护等支持性且因项目要求的不同而差异加大的活动。
用户需求分为 功能性用户需求和非功能性用户需求，IFPUG 和 NESMA 用来估算 功能性用户需求的规模； 而SNAP 用来估算 非功能性用户需求的规模
国内的行业标准，有使用 IFPUG 方法的，也有是 NESMA 方法的； 需要注意二者的差异和联系
估算软件开发成本的总体思路是：
1，先估算出规模，估算法方法可以选用其中一个
A，NESMA快速估算， 项目早期，需求不明朗，文档不全
B， NESMA估算，项目中期，需求清晰，文档较全
C， NESMA详细估算，项目完全，需求完成，文档完备
D， IFPUG 估算
2，然后使用方程 工作量 = 规模/ 生产率， 计算得出工作量
3，基于工作量计算开发成本
术语
功能点 FP function point
功能的度量单位，用于度量软件规模； 不等同于 功能，或者用户需求； 一般场景下所说的 功能点，是 指功能 【功能亮点、或者功能突出点】
A Function Point (FP) is a unit of measurement to express the amount of business functionality, an information system (as a product) provides to a user. FPs measure software size. They are widely accepted as an industry standard for functional sizing.
国标/行业标准所描述的功能点估算规范，既有IFPUG ，也有 NESMA，2者在流程和规则上，大部分是相同的；主要差异是
- NESMA具有 2个简易化模式，可以用于快速估算
- IFPUG 的处理过程比较复杂，没有简化模式
- IFPUG和NESMA在 调整因数的计算方法，是不同的。一个是 14项基本特征的影响值TDI， 另外一个是 5 项调整因子
- 对于非全新项目，NESMA可以在 FP计数时，就按 复用程度和修改类型进行估算 FP； 而 IFPUG 则需要 按 新增、转换、变更 分别进行初估，分别计算调整因子
基本概念
- 应用边界
- 基本处理过程
- 功能点
- 元素类型
应用边界 application boundary
被度量软件与用户或者其他系统之间的界限
控制信息 Control Information
Control Information is data that influences an elementary process by specifying what, when or how data is to be processed.
基本处理过程 elementary process
对用户来说是一个有意义的、最小的活动单元，是自包含的，并且使应用程序的业务处于一致状态
Elementary Process is the smallest unit of functional user requirement that − 基本处理是 用户功能需求的最小单元
- Is meaningful to the user. 对用户来说是有意义的
- Constitutes a complete transaction. 构成一个完整的交易
- Is self-contained and leaves the business of the application being counted in a consistent state. 自包含，并且使应用程序的业务处于一致状态
Processing Logic
Processing logic is defined as any of the requirements specifically requested by the user to complete an elementary process such as validations, algorithms or calculations and reading or maintaining a data function.
功能 function
功能分为 2 大类， 5种类型
- 数据功能
- 交易功能
- 数据 功能， 即 满足内部或者外部数据需求的功能 ， 存储数据的功能
- ILF 内部逻辑文件 【容纳一组在本应用中由一个或者一组基本处理来维护的数据 】
- EIF 外部接口文件【容纳一组在本应用中由一个或者 一组基本处理引用到的数据 】
"在这里，文件的概念并非是传统意义的文件， 而是一组逻辑上相关联的数据的集合。 "
- 交易 功能， 即 处理数据的功能
- EI 外部输入
- EO 外部输出
- EQ 外部查询
识别交易功能时，要 按 基本处理 elementary process 的原则进行识别
元素类型 element type
用来估计功能的复杂度，从而为功能估算出合适的FP数
- DET data element type / 数据元素类型，为 唯一、用户可识别、不重复的属性，即字段 //Data Element Type (DET) is the data subgroup within an FTR. They are unique and user identifiable.
- RET record element type / 记录元素类型，为 用户可识别的 DET 的子集【部分】， 例如， 主从类型的数据模式， 订单，订单行， 要识别为 2个 RET， 订单自身是1个RET，订单行 是1个RET //A Record Element Type (RET) is the largest user identifiable subgroup of elements within an ILF or an EIF. It is best to look at logical groupings of data to help identify them.
- FTR file type referenced / 引用文件类型，被交易功能读取或者维护的数据功能， 是被交易功能 读取或者维护的 ILF，或者是被交易功能 读取的 EIF， 例如， 订单业务中，创建确认订单并建立交货单，要识别为2个FTR，订单自身是1个FTR，还需要将 交货单识别为1个FTR //File Type Referenced (FTR) is the largest user identifiable subgroup within the EI, EO, or EQ that is referenced to.
估算方法
IFPUG估算流程概览 【ISO规范】
- 收集可用的文档
- 确定计数类型【开发？、增强？、应用系统？】
- 确定计数范围，边界，以及用户的功能性需求
- 度量数据功能
- 识别数据功能
- 识别 ILF和EIF
- 分别识别 ILF、EIF 的数据元素DET数量，记录元素RET数量，使用《功能元素复杂度计算表》确定复杂度，基于复杂度确定功能点数
- 度量交易功能
- 识别每一个基本处理
- 确定唯一的基本处理
- 将交易功能分类为 EI、EO、EQ
- 识别 EI、EO、EQ的数据元素DET数量，引用文件类型RFT数量，使用《功能元素复杂度计算表》确定复杂度，基于复杂度确定 功能点数
- 度量转换功能
- 度量增强功能
- 计算功能规模
- 开发类型公式： DFP = ADD + CFP // ADD 开发项目要交付给用户的功能规模， CFP = conversion function point 转换功能的规模
【 在开发完成后的应用系统的生命周期内，应用系统的 规模 计算为 AFP = ADD 】
- 增强类型公式： EFP = ADD + CHGA + CFP + DEL // CHGA 变更后的功能规模， DEL =deleted function point 删除的功能的规模
【 在项目增强后，应用系统的 规模 计算为： AFPA = （AFPB +ADD + CHGA） - （CHGB +DEL） // CHGA 变更后的功能规模， CHGB 变更前的功能规模， AFPA 增强项目后的功能规模，AFPB 增强项目前的功能规模 】
- 将功能点计数记录在案
- 报告功能点计数结果， 至此 IFPUG 流程结束
- 【依据SNAP】进行非功能性需求 的规模调整
NESMA估算流程
- 识别 功能点，确定 复用程度和修改类型
- 根据所处的估算时机，进行规模调整，得出未调整的 功能点
- 基于调整因子进行调整，得出调整后的 功能点
在进行计数实践的时候，按照估算的时机，或者文档的完备性，可以分为 3 种估算方法
- 1， Indicative方法， 预估功能点【用于项目早期】，
只 用识别出 数据功能，即 ILF 和 EIF 的数量
然后 按 公式 35*ILF + 15* EIF 计算出 未调整的功能点数
Indicative方法基于如下假设：
平均情况下，每个ILF对应3个EI(对应添加、修改、删除这三个操作)、2个EO(对应两种统计报表操作)和1个EQ(对应查询操作)；
平均情况下，每个EIF对应1个EO和1个EQ；
公式中的35和15这两个权重，则是全部ILF、EIF的复杂度默认为"低"，EI、EO、EQ的复杂度默认为"中"，再考虑系统整体的功能性得出的。？？？
- 2， Estimated方法， 估算功能点【用于项目中期】 ，
识别出 数据功能，以及 交易功能， 即 ILF 和 EIF 的数量 以及 EI、EO、EQ的数量
然后 按公式 10*ILF + 7* EIF + 4*EI + 5*EO + 4*EQ 计算出 未调整的功能点数
- 3，详细功能点【用于项目后期】
识别5类功能的功能个数
识别各功能的功能要素，基于功能要素的数量，使用《功能元素复杂度计算表》确定各个功能的复杂程度，根据《功能点数与复杂度之间的对应关系》 查出相应功能的 功能点数
汇总所有的功能点数为 未调整的功能点数
Indicative方法 和 Estimated方法，均是 是 详细功能点估算方法 的简化。
Estimated方法 就是 按中等复杂度进行估算
使用NESMA Estimated方法 估算未调整的功能点数时，可以基于 复用程度、修改类型进行对各功能的 功能点数进行调整, 调整系数 为 复用程度系数* 修改类型系数
复用程度 | 系数 |
高 | 1/3 |
中 | 2/3 |
低 | 1 |
修改类型 | 系数 |
新增 | 1 |
修改 | 0.8 |
删除 | 0.2 |
功能要素复杂度计算表
功能点数与复杂度之间的对应关系
功能点数 | 功能 |
|
|
|
|
复杂度 | ILF | EIF | EI | EO | EQ |
低 | 7 | 5 | 3 | 4 | 3 |
中 | 10 | 7 | 4 | 5 | 4 |
高 | 15 | 10 | 6 | 7 | 6 |
估算流程概览【国内行业规范-NESMA】
- 规模估算
- 收集可得文档
- 确定计数范围和边界识别功能用户需求
- 度量数据功能
- 度量事务功能
- 计算功能规模
- 功能规模调整
依据行业数据，确定CF【规模变更调整因子】，使用公式 S = UFP * CF
- 工作量计算
AE = （PDR *S）*SWF * RDF
其中：PDR 为生产率，取行业数据， SWF软件因素调整因子【完整性级别调整因子* 应用类型调整因子 *质量及特性调整因子】，RDF 开发因素调整因子【开发语言，开发团队背景】
- 工期计算
D = 1.227 *（ AE/176）^0.404
在规模估算时， 根据 项目阶段，使用不同的NESMA方法
- 项目匡算， 使用预估功能点，计算公式为 UFP = 35 * ILF + 15* EIF
- 项目概算，使用估算功能点，计算公式为 UFP = 10* ILF + 7 * EIF + 4 *EI + 5*EO + 4*EQ
在估算功能点时，要考虑复用程度，按 低/中/高 分类，各自取值为 1 、 2/3 、 1/3 各预设功能点值
- 项目阶段，使用详细功能点，计算公式为 UFP = ∑ ILF + ∑ EIF + ∑EI + ∑EO + ∑EQ
详细功能点估算时，要计算 数据功能和交易功能的复杂度，基于复杂度计算 功能点，即得出各项功能的 功能点数
估算流程概览【国内行业规范-IFPUG】
- 确定估算的类型
- 开发项目、升级项目、应用系统
- 识别分析范围和应用边界
- 识别分析范围和应用边界中的定义
- 定义应用边界
- 计数数据功能
- 识别数据功能
- 识别ILF，EIF
- 确定复杂度，基于复杂度确定功能点
- 计数交易功能
- 识别基本处理
- 识别EI、EO、EQ
- 确定复杂度，基于复杂度确定功能点
- 确定调整系统
- 调整系数 VAF 基于 14个通用系统特性计算得出， 每个特性取值范围0～5
- 14 个值相加，然后加上 0.65
- 计算调整功能点
- 开发项目： DFP = （UFP + CFP ） * VAF //
UFP 为应用在安装以后向用户提的 未经调整的功能点，
CFP 为额外的转换功能的未经调解的功能点
- 升级项目： EFP = (ADD+CHGA+CFP)* VAFA +DEL*VAFB //
ADD = 升级项目中增加的未经调整的功能点
CHGA = 升级项目中改变的功能在改变后所具有的未经调整的功能点 CFP = 额外的转换功能的未经调整的功能点
VAFA = 升级后的应用的调整系数
DEL = 被删除的功能的未经调整的功能点
VAFB = 升级前的应用的调整系数
- 应用系统：
基线 AFP = ADD * VAF //
ADD = 安装的功能的
UFPC VAF = 调整系数
应用升级后 AFP = [(UFPB+ADD+CHGA) – (CHGB+DEL)]*VAFA //
UFPB = 应用升级前的未经调整功能点
ADD = 新增功能的 UFPC
CHGA = 升级后的修改功能的 UFPC
CHGB = 升级前的修改功能的 UFPC
VAFA = 升级后的调整系数 【注意该公式中不包含转换功能， 因为转换功能与应用直接提供的功能无关 】
调整因素
国内ifpug标准
按 功能点计算出 工作量后，再 根据下面的14项系统基本特征 评分得出调整系数，然后进行调整
14项系统基本特征
- 数据通讯
- 分布式数据处理
- 性能
- 大业务量配置
- 交易处理率
- 在线数据输入
- 最终用户效率（用户界面友好程度）
- 在线更新
- 复杂处理（算法）
- 可复用性
- 易安装性
- 易操作性
- 多场地（多点运行）
- 支持变更（客户化程度）
上面14项目每个项目的分值 从0 到 5分
计算公式是： ∑14项因子*0.01 + 0.65， 即14项目 加总后 * 0.01 + 0.65
国内NESMA方法
在估算功能点后，根据计数时机，按规模调整系数进行规模调整，从而确定 未调整的功能点
计数时机 | 系数 |
早期 | 1.39 |
中期 | 1.22 |
完成 | 1.0 |
估算出未调整的 功能点后，再 根据软件因素，和开发因素，一共5项调整因素计算得出的调整系数，然后进行调整
计算公式是： ∏ 5项因子， 5 项得分 相乘
因素 | 得分范围 |
应用类型 | 1.0～2.0 |
质量特性 | 0.9～1.1 |
完整性级别 | 1.0～1.3 |
开发语言 | 0.6～1.5 |
开发团队背景 | 0.8～1.2 |
【 质量特性有4个维度，总体上应该是 8 个调整因素】
应用类型
应用类型 | 描述 | 调整因子 |
业务处理 | 办公自动化系统、日常管理及业务处理用软件等 | 1.0 |
应用集成 | 企业服务总线、应用集成等 | 1.2 |
科技 | 科学计算、仿真、基于复杂算法的统计分析等 | 1.2 |
多媒体 | 多媒体数据处理；地理信息系统；教育和娱乐应用等 | 1.3 |
智能信息 | 自然语言处理、人工智能、专家系统等 | 1.7 |
系统 | 操作系统、数据库系统、集成开发环境、自动化开发/设计工具等 | 1.7 |
通信控制 | 通信协议、仿真、交换机软件、全球定位系统等 | 1.9 |
流程控制 | 生产管理、仪器控制、机器人控制、实时控制、嵌入式软件等 | 2.0 |
质量特性
调整因子 | 判断标准 | 调整因子 |
分布式处理 | 没有明示对分布式处理的需求事项 | -1 |
| 通过网络进行客户端/服务器及网络基础应用分布处理和传输 | 0 |
| 通过特别的设计保证在多个服务器及处理器上同时相互执行应用中的处理功能 | 1 |
性能 | 没有明示对性能的特别需求事项或仅需提供基本性能 | -1 |
| 应答时间或处理率对高峰时间或所有业务时间来说都很重要，存在对连动系统结束处理时间的限制 | 0 |
| 为满足性能需求事项，要求设计阶段开始进行性能分析，或在设计、开发阶段使用分析工具 | 1 |
可靠性 | 没有明示对可靠性的特别需求事项或仅需提供基本的可靠性 | -1 |
| 发生故障时带来较多不便或经济损失 | 0 |
| 发生故障时造成重大经济损失或有生命危害 | 1 |
多重站点 | 在相同的硬件或软件环境下运行 | -1 |
| 在设计阶段需要考虑不同站点的相似硬件或软件环境下运行需求 | 0 |
| 在设计阶段需要考虑不同站点的不同硬件或软件环境下运行需求 | 1 |
质量因子 计算公式
质量系数 = 1 + 0.025* 以上调整因子之和
完整性级别
完整性级别 | 调整因子 |
没有明确的完整性级别或等级为C/D | 1.0 |
完整性级别为A/B同时为达成完整性级别要求采取了特殊的设计及实现方式 | 1.1 |
完整性级别为A同时为达成完整性级别要求在软件开发全生命周期均采取了特定、明确的措施 | 1.3 |
开发语言
开发语言 | 调整因子 |
C及其他同级别语言/平台 | 1.5 |
JAVA、C++、C#及其他同级别语言/平台 | 1.0 |
PowerBuilder、ASP及其他同级别语言/平台 | 0.6 |
开发团队背景
开发团队背景 | 调整因子 |
为本行业开发过类似的软件 | 0.8 |
为其他行业开发过类似的软件，或为本行业开发过不同但相关的软件 | 1.0 |
没有同类软件及本行业相关软件开发背景 | 1.2 |
计算案例：
工作量估算
例如， 使用NESMA 估算功能点法，估算出 功能点为 345.87 ， 经规模调整后为 480.75 ， 基准生产率为7.10 人时/功能点 ， 那么 工作量 = 480.75 功能点 * 7.10 人时/ 功能点 =3,413.325 人时 【480.75*7.10=3,413.325 人时 】 = 3,413.325/8 = 426.6656 人天
【规模调整因子是 根据估算时机确定的，上例是 以早期 1.39 取值的】
例如， 调整因子 得分如下
应用类型 | 1.00 |
质量特性 | 1.08 |
完整性级别 | 1.30 |
开发语言 | 0.60 |
开发团队背景 | 1.00 |
调整系数 为 1*1.08 * 1.3 *.6 * 1 = 0.8424
所以调整后的 工作量 = 426.6656 人天 * 0.8424 = 359.4231 人天
【基准生产率可以查行业数据，一般取中位数】
工期计算
工期 = 1.277 * （ 工作量 /176 ） ^ 0.404
【 此公式 中工作量的单位是 人时， 工期的单位是 月】
例如， 工作量为 359.4231 人天 ， 转换为 人时 为 3,413.325 人时， 计算得出 工期 为 1.227*( 3,413.325/176)^0.404=4.065 即 工期为 4.065 月
进一步 估算团队规模： 359.4231 人天 = 359.4231/22= 16.3374 人月， 16.3374 人月 / 4.065 月 = 【 16.3374/4.065 】 4.019 人
软件开发价格计算
软件开发价格 = 开发工作量 * 开发费用/ 人月
其中：
开发工作量 = 估算工作量 * 风险系数 * 复用系数
开发费用/人月 = 【工资 + 国家规定的福利 + 奖金以及奖励 + 办公成本 + 人力资源成本 + 设备/基础设施 + 税金和利润 】 * 管理系数 * 优质系数
国家规定的福利 = 工资 * 0.476
奖金以及奖励 = 工资 * 1/5
办公成本 = 工资 * 1/3
人力资源成本 = 工资 * 1/5
设备/基础设施 = 工资 * 0.15
税金和利润 = 工资 * 1/3
管理系数 取值于 1～ 1.2
优质系数 按 ISO9000 质量 或者 CMMI 认证确定，分别取值 1.05， 1.1，1.2，1.3
一般 综合下来， 按 平均月薪 * 3.23 作为开发费用/人月
人月开发费用，也可以采取 行业基准数据， 例如 2019年软件开发行业基准人月单价 2.8767 万元 /人月， 不包含 直 接非人力成本
继续 上例 359.4231 人天 换算为 人月， 为 359.4231/21.75=16.5252 人月，软件开发价格为 47.538 万 【 16.5252 * 2.8767=47.538 】
如果采用 月平均工资 * 3.23， 例如 月平均工资为 1.5W ， 则软件开发价格为 80.0646 万 【 16.5252*1.5 *3.23 = 80.0646 】
注意， FPA 方法是按 瀑布模式 运作项目的，如果是采用敏捷模式，工作量上应该要少很多。。。
对于系统集成项目
结论
前面部分所述的是软件开发部分， 软件开发之后，还需要进行 实施、运维支持，也存在相应的费用。
基于 Odoo 开发应用系统，存在3个优势
1，Odoo自身原本拥有大量的 应用
2，Odoo框架的 复用程度高
3，采用敏捷管理项目，比传统的瀑布模式更有效率
本文是学习笔记，难免有理解的错误，欢迎指正
