基于 功能点 估算项目规模 FPA
Table of Contents
国标、行业标准，基本上都是在遵从 NESMA方法进行实践的
术语
功能点 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.
功能点估算，主流有2种方法，IFPUG 和 NESMA，2者在流程和规则上，大部分是相同的；主要差异是
- NESMA具有 2个简易化模式，可以用于快速估算
- IFPUG 的处理过程比较复杂，没有简化模式
- IFPUG和NESMA在 调整因数的计算方法，是不同的。一个是 14项基本特征的影响值TDI， 另外一个是 5 项调整因子
- 对于非全新项目，NESMA可以在 FP计数时，就按 复用程度和修改类型进行估算 FP； 而 IFPUG 则需要 按 新增、转换、变更 分别进行初估，分别计算调整因子
基本概念
- 应用边界
- 基本处理过程
- 功能点
- 要素类型
应用边界 application boundary
被度量软件与用户或者其他系统之间的界限
基本处理过程 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.
功能 function
功能分为 2 大类， 5种类型
- 数据功能
- 事务功能
- 数据 功能， 即 满足内部或者外部数据需求的功能 ， 存储数据的功能
- ILF 内部逻辑文件 【容纳一组在本应用中由一个或者一组基本处理来维护的数据 】
- EIF 外部接口文件【容纳一组在本应用中由一个或者 一组基本处理引用到的数据 】
"在这里，文件的概念并非是传统意义的文件， 而是一组逻辑上相关联的数据的集合。 "
- 事务 功能， 即 处理数据的功能
- EI 外部输入
- EO 外部输出
- EQ 外部查询
识别事务功能时，要 按 基本处理 elementary process 的原则进行识别
要素类型 element type
对 数据功能，进一步按 对 要素类型进行识别计数 ，识别出 相关数据功能的复杂程度，以便基于复杂度 确定功能点数
- 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.
对于 事务功能，进一步对 要素类型进行识别计数，识别出 相关事务功能的复杂程度，以便基于复杂度确定 功能点数
- DET data element type / 数据要素类型，为 唯一、用户可识别、不重复的属性，即字段
- 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估算 ，流程和规则
- 识别 EI
- 识别 EI 的数据要素DET数量，引用文件类型RFT数量，确定复杂度，基于复杂度确定 功能点数
- 依次 识别 EO、EQ
- 识别 ILF和EIF
- 分别识别 ILF、EIF 的数据要素DET数量，记录要素RET数量，确定复杂度，基于复杂度确定功能点数
- 所有的功能的功能点数加总得出 未调整的功能点数
- 基于 14项基本特征的影响值TDI，计算调整因子 VAF=0.65 +TDI*0.01
- 步骤6 确定的功能点数 乘以 调整因子，得出 调整后的功能点
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估算未调整的功能点数时，可以基于 复用程度、修改类型进行对各功能的 功能点数进行调整, 调整系数 为 复用程度系数* 修改类型系数
复用程度 | 系数 |
高 | 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 |
工作量计算
计算公式： 工作量 = 功能点 * 基准生产率
ifpug方法
按 功能点计算出 工作量后，再 根据下面的14项系统基本特征 评分得出调整系数，然后进行调整
14项系统基本特征
- 数据通讯
- 分布式数据处理
- 性能
- 大业务量配置
- 事务处理率
- 在线数据输入
- 最终用户效率（用户界面友好程度）
- 在线更新
- 复杂处理（算法）
- 可复用性
- 易安装性
- 易操作性
- 多场地（多点运行）
- 支持变更（客户化程度）
上面14项目每个项目的分值 从0 到 5分
计算公式是： 14项目 加总后 * 0.01 + 0.65
NESMA方法
在估算功能点后，根据计数时机，按调整系数进行调整，从而确定 未调整的功能点
计数时机 | 系数 |
早期 | 1.39 |
中期 | 1.22 |
完成 | 1.0 |
按 功能点计算出 工作量后，再 根据下面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，采用敏捷管理项目，比传统的瀑布模式更有效率
本文是学习笔记，难免有理解的错误，欢迎指正
