功能点方法是一种估算软件项目大小的方法，它是从用户视角出发，通过量化系统功能来度量软件的规模，这种度量主要基于系统的逻辑设计。功能点规模度量方法在国际上的应用已经比较广泛，并且已经取代代码行成为最主流的软件规模度量方法。功能点方法进入国内也有近10年的时间。在2018年由工业和信息化部发布的行业标准《软件研发成本度量规范》中也推荐使用功能点方法进行软件规模度量，进而对软件项目工作量、工期、成本进行估算。
一、功能点识别
- 功能点是度量软件规模的一种单位。
- 功能点方法从用户视角（业务价值）度量软件的规模大小
从业务视角/用户价值角度看待系统：
即，系统所维护的信息及处理的复杂程度决定了系统价值
根据数据功能分类：
- ILF（内部逻辑文件）：在本系统维护的业务数据
- EIF（外部接口文件）：本系统引用，在其他系统维护的业务数据
根据事务功能分类：
- EI（外部输入）：对数据进行维护或改变系统行为的事务
- EO（外部输出）：对数据加工后呈现或输出的事务
- EQ（外部输出）：对已有数据直接呈现或输出的事务
二、逻辑文件
逻辑文件是业务数据或业务规则。中间表、内部只读数据、缺省值、数据编码均不是逻辑文件。
| 逻辑数据 | 物理数据 |
|---|---|
| 交易记录 | 数据库表 |
| 账户信息 | 文档文件 |
| 审计数据 | 注册表 |
| …… | …… |
- 一个物理文件中可以包含多个逻辑数据
- 一个逻辑文件也可以分布在多个物理文件中
- 功能点方法关注逻辑文件而非物理文件
2.1 逻辑文件分类
业务数据：用户的核心数据或业务对象
- 用户可识别（一般针对业务客户）
- 用户可维护（一般针对业务客户）
- 频繁动态的（相对于业务）
- 物理特性：通常由关键域和多个属性；可能有从0到无限的记录
引用数据：用户用于维护业务数据的业务规则
- 用户可识别（通常指业务用户）
- 通常用户可维护（可能是管理员用户）
- 很少动态变化，通常在应用系统第一次安装时设置或周期性维护
- 在处理业务数据时常常需要访问引用数据
- 物理特性：通常由关键域和少量属性；可能为一个记录或有限的记录数
编码数据：
- 有时用户可维护（通常由用户支持人员操作）
- 存储数据以便使业务活动和业务的事务处理标准化和简易化
- 基本是静态的
- 物理特性：通常只由关键域和常用的一或两个属性组成；通常有较稳定的记录数量；有时未规格化并于其他编号数据放在一个物理表中；通常用户不限定实施方式（如：独立应用系统、数据字典、软件硬编码等）
- 类型识别：代换或者有效值：典型结构为编码-名称-[描述]，如国家或地区；一次性事件、静态值或常量
- 通常位于本系统内部；很少进行修改；通常没有专门界面对其进行维护；对其的修改常常采用导入覆盖或者直接修改数据库值的方式；
- 并非是业务数据或规则，对其的修改并非业务原因触发。
2.2 逻辑文件识别
逻辑差异：
- 用户可以感知其用途的明显不同
- 通常有不同的使用、维护方式
- 关键是可以形成独立的管理/应用闭环
依赖关系：
- 如果A依赖于B或者B依赖于A，则记为一个逻辑文件
- 如果A与B无明显逻辑联系，则记为两个逻辑文件
逻辑文件计数步骤：（发现→识别→去重）
- 找到数据并归类（包括潜在的逻辑文件，剔除编码数据）
- 确认是否有逻辑差异或依赖关系：只有存在逻辑差异且没有依赖关系的业务数据或引用数据才记为独立的逻辑文件
- 确认是否在系统边界内被维护：存在本系统维护即ILF，只引用而由其他系统维护则为EIF（本系统的EIF应该是其他某个系统的ILF）
- 任何逻辑文件在系统边界内仅被计数一次（多个模块重复操作一个逻辑文件/多个处理过程维护或访问一个逻辑文件）
2.3 ILF（内部逻辑文件）
- ILF（内部逻辑文件）：在本系统维护的业务对象/业务规则
- 复杂程度：10
识别规则
- ILF指在待计数系统内部逻辑上的一组数据
- 对单个ILF平均执行6种左右的操作（经验而非规则！），而且一定包含写操作
2.4 EIF（外部接口文件）
- EIF（外部接口文件）：本系统引用，在其他系统维护的数据
- 复杂程度：7
识别规则
- 本系统“引用”
- 是一个“逻辑”上的文件
- 在系统外部维护
关键点
- 是文件，而非系统或接口
- 引用的实现方式不影响计数结果
- 维护是指逻辑上而非物理上的维护或存储
2.5 逻辑文件识别关键点
- 识别出的ILF一定包含对其写的操作
- 仅部分在本系统维护的逻辑文件也识别为ILF
- 逻辑文件是文件，而非系统或接口
- 实现方式不影响计数结果
- 同一逻辑文件在系统内优先记为ILF
三、基本过程
- 用户可以明确感知其业务意义（具备业务价值）的一次操作
- 例如对业务数据的增、删、改、查
- 是业务上的原子操作：产生基本业务价值，操作后系统进入相对稳定状态
- 基本过程应包含从开始到结束所遇到的所有正常和异常情况
3.1 基本过程识别
基本过程的原子性：
- 无论本次操作成功或失败，数据完整/稳定
- 操作人员可以转而进行其他操作
- 即使掉电/重新启动系统，不会发生数据丢失的状态
非原子操作：
3.2 EI（外部输入）
- 复杂程度：4
识别规则
- 是一个完整的基本过程
- 其主要目的是对内部逻辑文件进行维护或接受某个控制信号使软件行为发生改变
- 可以包含任何的处理逻辑
主要目的
- 对内部逻辑文件进行维护
- 输入信号并改变系统行为
示例
- 如增/删/改
- 如启动服务
- 例如：启动端口监听、修改同步时间、导入Excel表格
3.3 EO（外部输出）
- 复杂程度：5
识别规则
- 是一个完整的基本过程
- 即通过处理逻辑（计算/产生衍生数据/维护逻辑文件/改变系统行为）表示/发送信息
主要目的
- 向系统边界之外发送/呈现数据
示例
- 例如：针对某业务数据的复杂报表/统计分析等（含计算）
- 查询3月份贷款记录，并计算贷款总额
- 输出报表
- 生成对账单
- 大额交易统计
- 员工所得税报表
3.4 EQ（外部查询）
- 复杂程度：4
识别规则
- 是一个完整的基本过程
- 对内部数据的简单输出（不得包含计算/产生衍生数据/维护逻辑文件/改变系统行为中的任意一种）
- 对内部数据的简单输出
- 可以排序、筛选、分组、等值代换等
主要目的
- 是向系统边界之外发送/呈现数据
示例
- 列表显示某业务数据基本信息
- 只显示未处理的授信申请
- 按日期显示收支记录
- 搜索某个ID的客户
- 帮助系统（搜索帮助条目）
- 帐号交易记录
- 人员信息查询
- 显示“我的待办
3.5 基本过程识别关键点
- 基本过程本身一定完整且具备业务价值
- EI可以向系统外发送信息，如操作成功或失败信息
- EI可以维护不止一个内部数据，仅识别为一个EI
- 排序、筛选、等值代换等操作不属于计算行为，也不产生衍生数据
- 多数信息在编辑、删除之前，可以识别一个隐含的查询，除非已在别处被识别
- 如果查询所输入的数据无需存储，则不额外计算一个EI，反之则酌情分析
- EO和EQ混淆仅产生少量误差
四、功能点计算方法
4.1 快速功能点法（2点法）
根据立项前期的需求分析及可研报告内容，确定计算范围、划定应用程序的边界；
对项目中涉及到的内部文件（ILF）、外部文件（EIF）的数量进行评估；
对ILF和EIF分别与一个权重因子相乘，计算出功能点数。
FP = ∑(35 * ILF + 15 * EIF)
即1个业务实体算35个功能点，1个外部数据接口算15个功能点，累加求和即可，非常简单，因为是粗略估算，误差也可能比较大。
4.2 初步功能点法（5点法）
设计阶段的软件开发工作量估算可采用初步功能点法，依据确定的内部文件（ILF）、外部文件（EIF）、用户输入（EI）、用户输出（EO）、用户查询（EQ）的个数来计算。
•FP = ∑(10 * ILF + 7 * EIF + 4 * EI + 5 * EO + 4 * EQ)
纳入了五要素，给予了不同的权重，比快速功能点法的进了一步，评估工作量变大，评估结果通常更准确一些。
4.3 标准功能点法*
相比前面两种方法，标准功能点法引入了更多的控制因子来处理差异性，进行更细颗粒度的衡量，以求更准确的衡量和评估。
首先，不同业务实体的属性数量是有差异的，一个8个属性的实体，和一个35个属性的实体，直观上就可以判断出来开发工作量是有差异的。
针对这种情况，标准功能点引入了功能复杂度来计算加权因子。功能复杂度按照高(H) 、平均(A) 或低(L)进行划分。功能复杂度高、中、低分别对应不同的功能单元加权因子取值，也就是功能点个数值。
| 功能单元类型 | 功能复杂度 | ||
|---|---|---|---|
| 低（L） | 平均（A） | 高（H） | |
| 内部逻辑文件(ILF) | 7 | 10 | 15 |
| 外部接口文件(EIF) | 5 | 7 | 10 |
| 外部输入(EI) | 3 | 4 | 6 |
| 外部输出(EO) | 4 | 5 | 7 |
| 外部查询(EQ) | 3 | 4 | 6 |
上表中的中位值，实际就对应着初步功能点估算法的权重值FP = ∑(10 * ILF + 7 * EIF + 4 * EI + 5 * EO + 4 * EQ)，所以初步功能点法就是放大了评估的粒度，降低估算的工作量。
至于如何具体评估某一个功能的功能复杂度，应该是低、中还是高，标准功能点法同样提供了一个参考标准，引入了DET（可简单理解为字段数量）和RET（可简单理解为表数量），以下是示例，不做详细展开。
| 1~19个RET | 20~50个RET | 51个以上RET | |
| 1个RET | 低 | 低 | 中等 |
| 2~5个RET | 低 | 中等 | 高 |
| 6个以上RET | 中等 | 高 | 高 |
其次，不同的需求，对系统要求是有差异的，例如有的系统对性能要求很高，有的系统对易用性有一定要求，这些因素同样会影响到系统实现的难度。标准功能点法，通过调整因子来处理差异性。
标准功能点法抽象出14个通用系统特性，具体如下：
- 数据通信：描述软件直接同处理器进行通信的程度；
- 分布式数据处理：描述软件的各部件间数据传输的程度；
- 性能：描述响应时间和数据吞吐量对软件研制的影响程度；
- 系统配置要求：描述计算机资源约束对软件研制的影响程度；
- 事务率：描述事务处理率对软件研制的影响程度；
- 在线数据输入：描述通过交互处理输入数据的程度；
- 最终用户效率：描述对各种人为因素和最终用户易用性的考虑程度；
- 在线更新： 描述内部逻辑文件被在线更新的程度；
- 复杂处理：描述，处理逻辑对软件研制的影响程度；
- 可重用性：描述经过专门设计、开发和支持的软件，可在其他软件中重用的程度；
- 易安装性：描述软件在不同环境下转换和安装操作的简便程度；
- 易操作性：描述软件在操作方面的满足程度，如:启动、备份和恢复过程；
- 多工作场所：描述软件用于多个用户组织、多种场所的程度；
- 易变更性：描述软件的数据结构和处理逻辑易于修改的程度；
每一个特性都有一些规则来进行评分，以判断该特性对这个应用的影响程度。评分的范围是从0到5，分别代表没有影响到影响很大。
以性能参数为例：
| 描述 | 分数 |
|---|---|
| 用户没有提出性能方面的要求 | 0 |
| 用户提出了性能和设计方面的要求，但不需要采取特定措施 | 1 |
| 响应时间和吞吐量在系统峰值时是关键的，但是不需要采取相应的CPU 使用方面的特殊设计。处理的最后期限是在下一个工作日。 | 2 |
| 在任何时候响应时间和吞吐量都是关键的，但是不需要采取相应的CPU 使用方面的特殊设计。处理的完成期限比较严格 | 3 |
| 除了上面一项的要求外，由于对需求的要求比较严格，在设计阶段就要进行性能分析 | 4 |
| 除了上面一项的要求之外，在设计和实施阶段需要使用性能分析工具来判断性能要求的完成情况 | 5 |
标准功能点法，评估每一个通用系统特性，并且为它们确定影响程度（Degree of influence - DI），然后将所有通用系统特性的DI 相加，得到整体影响程度（Total Degree of Influence - TDI），最后代入公式VAF（调整因子）=0.65+0.01×TDI。
通过公式可以得知，该系数会在正负35%的幅度上调整功能点数。
假设未经过调整因子计算前的功能点数是100，走两个极端情况，14个通用系统属性，打分都是0或者都是5，则调整后的功能点数，分别为65和135，即项目规模可能相差1倍。
五、功能点识别例题
5.1协同办公
1 日程安排
- 员工日程安排模块提供对员工日程的建立、修改、删除、查询、提醒等功能。所有员工的日程安排均在该系统中进行更新和备案，还包括对员工的日、周、月工作计划和工作总结进行起草、审核、审批、更新等功能。
2 领导专栏
- 各处室可以委派专门人员维护领导专栏，设立栏目子类，将领导关注的信息以Word、Excel和PowerPoint 等文件的方式定期或者不定期地提供给领导阅览。
3 规章制度
- 规章制度模块用于将企业内部的有关人事、劳资、财务、保密和其它管理制度、工作准则在公司内部发布，供员工随时查阅。可用于对已有规章制度的更新和新制度的发布。
4 会议管理
- 会议管理包含从确立大型会议议题、大型会议审批到日常会议安排通知、,会议资源预定、提交会议纪要的全过程管理，会议安排能自动加入相关人员的待办事宜中，真备接收会议参加人回执等功能。
5 设备管理
- 设备管理实现设备的入库登记、出库发放、调配、盘点、维护、处置等设备的整个生命周期的管理。
6 车辆管理
- 本功能模块管理车辆使用过程中所涉及到的相关数据，如每辆车的详细资料及相应的派车、事故、违规、加油、里程表、维修、司机等情况。它可以为车辆及司机的管理工作提供有力依据，能真正达到统一监控管理的目的。
7 办公综合管理
- 对办公信息进行综合统计分析以用于了解相关信息并用于决策支持。主要包括日程查询、会议情况查询、设备使用情况统计、车辆使用情况统计等。
8 个性设置
- 对于不常变化的属性类数据（如制度种类、会议类型、设备性质、车辆品牌等）也提供简单的维护功能，以便于需要时进行修改、维护。
5.2客户信息管理
某客户关系管理系统中“客户信息管理”功能描述如下：
客户信息包括客户基本信息、客户联条方式信息。其中客户基本信息包括客户姓名，客户身份证号，客户性别，出生日期，学历，职业，客户经理，备注；联系方式信息包括固定电话信息，移动电话信息，电子邮件信息，通讯地址信息，一个客户可以有多种联系方式，如多个移动电话，多个通讯地址。
其中客户姓名、客户身份证号，出生日期、联系方式、备注为输入项，其他（包括客户性别、学历、职业、客户经理）为选择项，采用下拉列表方式。学历下拉列表及职业下拉列表中的字段依据国家相关标准确定，客户经理下拉列表中的数据为岗位为客户经理的所有员工，该数据（员工信息）由人事管理系统进行维护。
针对客户信息的主要操作包括：
- 添加客户信息：将新的客户信息添加到系统中，其中客户基本信息除备注外均为必填项，联系方式信息应至少包含一种有效联系方式。添加过程中会验证身份证号是否重复，如果重复会提示重复
- 维护客户基本信息：显示客户信息列表，对选中的客户显示并维护其基本信息联系方式信息。
- 维护客户联系方式信息：显示客户列表，对选中的客户显示并维护其联系方式
- 客户查询：输入客户姓名或联系电显示查询结果，如果多名用户符合查询条件，则全部显示
- 客户统计：显示客户的数量并统计性别、学历分布（占比）
- 删除客户信息：显示客户信息列表，对选中的客户进行删除，删除成功后显示删除成功的确认信息。
- 导入客户信息： 按照特定的格式从 EXCEL 文件导入
- 导入码表数据：包括性别、学历、职业的码表数据可按照特定的格式从EXCEL文件导入
Comments NOTHING