数据功能（ILF/EIF）是功能点度量的核心组成部分，反映系统对数据的存储和管理能力。内部逻辑文件（ILF）代表被度量应用程序维护的业务数据，外部接口文件（EIF）代表被度量应用程序引用但由其他应用程序维护的业务数据。数据功能的识别准确与否，直接决定了功能点计数的基线水平，进而影响项目规模评估的可靠性。

在实际操作中，数据功能的识别面临诸多挑战：技术文件与业务文件的边界模糊、代码数据的分散计数、关联实体的独立性判断、内部文件与外部文件的归属判定等问题，都是导致度量偏差的常见原因。针对数据功能识别中的典型问题，有不同的约束规则。本文将逐一分析，并通过详细示例说明正确与错误做法的差异。

01 不被维护的实体不识别为逻辑文件

不被任何应用维护的实体不应被识别为逻辑文件。

判断某实体是否应识别为逻辑文件，首先要确认该实体是否被被度量应用程序维护。这里的维护指的是应用程序对其执行写操作（包括新增、修改、删除），而非仅仅读取。

以某电商系统为例，数据库中存在一张sys_config表，存储了数据库连接参数、缓存配置等技术性配置。这些数据由运维人员通过数据库客户端直接维护，应用程序仅读取不写入。

正确做法:

不将该表识别为ILF或EIF，因为它属于系统基础设施而非业务数据。

错误做法:

将该技术配置表识别为ILF，导致功能点虚增。

反面示例（应识别）：

如果该电商系统提供了系统参数配置界面，允许管理员通过应用层维护这些配置项，则应识别为ILF。

判断是否被维护时，应以被度量应用程序的视角为准，而非数据库层面。即使某张表在物理上存在于被度量系统的数据库中，如果应用程序对其没有任何写操作，则不应识别为逻辑文件。

02 不含用户要求属性的实体不识别

不包含用户要求的属性的实体不应被识别为逻辑文件。

此规则的核心在于区分业务驱动和技术驱动的数据实体，判断标准是该实体的属性是否直接来源于用户需求。

以某医院信息系统为例，数据库设计时为了性能优化创建了一张patientsearchcache表，存储了患者的姓名、身份证号的哈希值和索引字段。该表的数据来源于patient_info表（已识别为ILF），表中的字段（哈希值、索引字段）并非用户需求中要求的属性，是纯粹的技术优化手段。

正确做法：

不将该表识别为逻辑文件。如果所有属性都是技术实现的副产品，如自增ID、时间戳、缓存标记等，则不应识别。

对比场景：

如果需求文档明确要求支持患者快速检索、需建立检索索引并可配置检索字段，则该缓存表可能承载了用户要求的业务属性，需要进一步评估。

03 代码数据的统一计数

不应将各类代码数据分别识别为逻辑文件。应用中直接维护的常量、文本和解码等的实体类型，统一作为一个ILF进行计数；被度量应用程序引用但由另一个应用程序维护的常量、文本和解码等实体类型被统一作为一个EIF。

代码数据通常具有数据量小、结构简单、变更频率低、被多个业务模块引用等特征，将它们合并计数既符合功能点度量的精神，也避免了代码数据膨胀对总体规模的干扰。

以某社保系统为例，系统中存在以下代码数据表：codegender（性别代码）、codenation（民族代码）、codeeducation（学历代码）、codepolitical（政治面貌代码）、code_marriage（婚姻状况代码）。以上代码表均由本系统管理员通过代码管理功能维护。

正确做法：

将上述所有代码表统一识别为1个ILF（命名为系统代码数据），而不是5个独立的ILF。

错误做法：

将每张代码表分别识别为独立的ILF，导致功能点虚增5倍。

如果上述代码数据由基础信息平台维护、社保系统仅引用，则统一识别为1个EIF。

04 技术性临时文件不识别

不应将出于技术目的建立的各种临时表文件识别为逻辑文件，如索引文件、中间计算结果文件、工作文件、临时文件、排序文件、打印文件、脱机文件等。

区分技术文件和业务文件的关键在于：该文件的数据是否具有独立的业务含义？如果数据仅在某个计算或处理过程中临时存在、处理完成后即可丢弃，则属于技术文件。

以某财务系统为例，在生成年度报表时创建了以下临时数据结构：

正确做法：

以上均不识别为逻辑文件，因为它们是技术实现的产物，不反映用户的业务功能需求。

对比场景：

如果需求明确要求系统应支持报表模板管理、用户可自定义报表格式，则报表模板表应识别为ILF，因为它承载了用户要求的业务数据而非纯粹的技术临时文件。

05 关联实体的识别规则

非用户要求的附加属性的关联实体不应被识别为逻辑文件；；；；仅包含外键的关联实体不应被识别为逻辑文件。

它们从不同角度共同约束了关联实体的识别标准——关联实体是否承载了独立的业务数据。

以某CRM系统为例，客户表和联系人表之间存在多对多关系，数据库设计时创建了关联表customercontactrel，该表仅包含id（主键）、customerid（外键）、contactid（外键）、create_time（创建时间）、operator（创建人）等字段。

正确做法：

该关联表仅包含外键和审计字段，不包含用户要求的业务属性，不将其识别为独立的逻辑文件。

反面对比：

如果需求要求记录客户与联系人的关系类型（决策人、经办人、财务对接人）和关联备注，则关联表承载了用户要求的业务属性，应识别为ILF。

再以某教务系统为例，学生选课关联表studentcourse仅含studentid和course_id两个外键字段，无独立的业务属性，不识别为逻辑文件。但如果该表还包含成绩（score）、学期（semester）、选课状态（status）等用户要求的属性，则应识别为ILF。

06 外部系统数据不应识别为ILF

不应将被度量系统不能维护的外部系统数据错误地识别为内部逻辑文件（ILF）。

ILF和EIF的核心区别在于：ILF是被度量应用程序可以执行写操作的逻辑文件，EIF是被度量应用程序仅能读取、由其他应用程序维护的逻辑文件。

以某银行信贷系统为例，该系统需要引用央行征信数据。征信数据由央行征信中心维护，信贷系统通过接口查询但不能修改。

正确做法：

将征信数据识别为EIF而非ILF。

错误做法：

信贷系统为了提高查询效率将部分征信数据缓存到本地数据库中，如果将这些缓存数据识别为ILF，则犯了将外部数据错误识别为内部文件的错误。

在微服务架构下此规则的适用需要更加谨慎：如果服务A和服务B分属不同团队或系统、服务A调用服务B的API获取数据，则服务B的数据对服务A而言是EIF；但如果A和B属于同一系统的不同模块、共享同一个数据库，则可能属于同一ILF的不同操作视角。

07 唯一性与不拆分原则

一个逻辑文件在一个应用程序中只能作为ILF或EIF两者之一被计数一次，不能同时作为两者计数。

功能点识别过程中不应将同一个逻辑文件按属性或类别进行拆分识别。这两条控制点是正确的，它们共同维护了逻辑文件计数的唯一性。

示例1：

以某供应链管理系统为例，商品信息表既被本系统维护（ILF特征）又被ERP系统引用（EIF特征）。

正确做法是在本系统中将商品信息表识别为1个ILF，不能既计为ILF又计为EIF。在ERP系统中同一张商品信息表识别为1个EIF。

常见误区是度量人员看到商品信息表既被本系统写入又被其他系统读取，就分别计为1个ILF和1个EIF，导致重复计数。

示例2：

以某人事系统为例，员工信息表包含100多个字段，涵盖基本信息、联系方式、教育经历、工作经历、薪酬信息等多个类别。

正确做法是将员工信息表识别为1个ILF，不按信息类别拆分为5个ILF。即使在数据库设计中将员工信息拆分为多张物理表（如employeebasic、employeeeducation、employee_salary），在功能点识别时仍应视为一个逻辑文件，因为它们在业务上属于同一实体员工的信息。

08 关联逻辑文件的独立性判断

不应将两个有关联的逻辑文件都识别为两个独立的逻辑文件，通过判断两个文件之间是否存在业务依赖关系来确定其是否是两个独立的逻辑文件。

判定标准是：如果文件B的生命周期完全依赖于文件A（删除A则B也无意义）且B是A的详细展开，则合并计数；如果文件A和文件B各自有独立的业务含义和生命周期，则分别计数。

以某物流系统为例，订单表包含订单号、客户信息、收货地址等，订单明细表包含订单号、商品ID、数量、单价等。订单明细表完全依赖于订单表存在且在需求中作为订单的一部分描述。

正确做法：

将"订单表"和"订单明细表"合并识别为 1个ILF（订单信息）

反面对比：

商品信息表虽然与订单有关联，但具有独立的业务生命周期（商品可独立于订单存在和管理），应识别为独立的ILF。

09 ILF的基本完整性要求

每个内部逻辑文件（ILF）应当至少包含一个外部输入（EI），并且应当至少包含一个外部输出（EO）或者一个外部查询（EQ）。

合规示例是客户信息ILF，它至少有1个EI（客户信息录入）和至少1个EQ（客户信息查询）。

违规示例：

某系统识别了一个日志审计ILF，但该系统中没有任何EI（日志由系统自动生成非用户输入），也没有EO/EQ（日志不对外输出仅管理员直接查数据库）。

正确做法：

不应将日志审计识别为ILF。一个只有读没有写的数据实体可能只是引用了外部数据（应为EIF），一个只有写没有读的数据实体可能只是技术性的中间存储。

此规则是一个自洽性校验——确保识别出的ILF确实承载了完整的业务数据管理功能。一个只有"读"没有"写"的数据实体，可能只是引用了外部数据（应为EIF）；一个只有"写"没有"读"的数据实体，可能只是技术性的中间存储

10 总结

数据功能识别的控制点可以归纳为五大核心原则：业务性原则，要求将技术文件与业务文件严格区分，避免将非业务驱动的数据实体误计为功能点；唯一性原则，要求对同一逻辑文件只计数一次，防止拆分或重复计数；完整性原则，要求每个ILF必须满足基本的事务功能配套条件；归属原则，要求正确判定内部文件与外部文件的边界；合并原则，要求根据业务依赖关系判断关联文件的独立性。

在实践中，建议从以下方面落实数据功能的质量控制：第一，在数据库设计文档基础上建立逻辑文件识别清单，逐表评估是否满足ILF/EIF识别条件；第二，在ER图中用不同颜色标记业务实体和技术实体，形成可视化的分类标注；第三，对每个识别的ILF执行完整性校验，检查其是否至少关联1个EI和1个EO/EQ；第四，建立代码数据清单，将分散的代码表统一管理避免重复计数；第五，升级改造项目对既有逻辑文件逐一评估是否有变更，仅对有变更的部分重新计数。

功能点的测算可使用“软件造价喵”：平台集成国内各省市60余个计费标准，支持一键测算，自动生成符合测算要求的造价评估结果，大幅缩短预算编制周期，确保功能点识别的准确性。

数据功能是功能点度量的存储层基础，其识别质量直接影响事务功能的计数准确性。只有在数据功能层面做到精准识别、不重不漏，才能为整个功能点度量体系奠定可靠的基础。