AFP-自动化功能点（2）

1、AFP介绍

1.1功能点概述

使用功能点作为软件功能大小的度量，最初是在20世纪70年代中期引入的，并且今天被全世界的组织使用。IBM的AllanAlbrecht是第一个公开发布功能尺寸软件称为功能点分析（Albrecht，1979，1981）。自1986年成立以来，国际功能点用户组（ifpug）不断维护和增强了原有的albrecht。

功能尺寸软件（ifpug cpm）的方法。

功能点是一个标准化的度量，可以以可接受的精度一致地使用价值。

功能点分析的核心在于它能够以逻辑的、面向用户的方式度量任何可交付软件的大小。

功能点计数是技术不可知论，因为它们不依赖于技术或开发的类型。

功能点只是测量应用程序向最终用户提供的功能。

功能点分析评估软件可交付成果，并根据定义良好的功能度量其大小、软件系统的特性。功能点分析是应用程序的四个组成部分：

1。外部输入—进入系统的输入数据（逻辑事务输入、系统反馈）。

2。外部输出和外部查询-离开系统的数据（在线显示、报告、反馈给其他系统）。

3。内部逻辑文件-在系统中处理和存储的数据（用户定义数据的逻辑组）。

4。外部接口文件-在系统外部维护但满足特定过程所需的数据需求（与其他系统的接口）。

组织可以应用功能点来度量软件产品的大小。以及其他一些措施，

功能点可用于以下活动：

•质量和生产力分析。

•估算软件开发、增强和维护所需的成本和资源。

•规范化软件比较中使用的数据。

•通过尺寸确定购买的应用程序包（商用现货或定制系统）的尺寸包中包含的所有功能。

•允许用户通过调整特定功能来确定应用程序的投资回报符合他们组织的要求。

 

1.2功能点使用场景

成本估算、进度跟踪

AFP标准也是ISO标准，ISO 19515：2019 2019信息技术-对象管理组自动功能点（AFP），1.0

1.3输入到自动功能点计数

以下是在执行自动功能点之前必须收集的所需输入的列表分析。输入1和2必须符合国际标准。

1。输入1-应用程序的完整、当前和正确的源代码，至少包括“a”到“d.”如下：

a.源代码-包括从GUI到数据库的所有元素。

b.要从源代码中排除的文件列表-不属于应用程序的文件。

C.要从源代码中排除的库列表-不属于应用程序的库。

d.数据定义文件-例如，用于生成数据库模型和/或大型机的SQL脚本数据库定义文件。

e.文件-包含用户维护数据但不存储在关系数据库中的文件，如csv文件、制表符分隔的文件或用户维护的XML文件。

2。输入2-应用程序命名约定的列表，清楚描述并逐项列出：

a.数据库命名约定

B.文件命名惯例

C.应用程序中使用的其他命名约定

d.源代码中要标识为事务入口点的模式

以下是确定完整应用程序源代码的附加规范说明，用于描述正确的应用程序边界，确保可审计性。

•必须在用户界面级别定义应用程序边界，如果适用，还必须在Web服务级别定义应用程序边界、级别或批次级别。应用程序边界的错误标识可能会产生不准确的结果。反映正在测量的目标域的大小。

•不要假设所需的所有源代码都在边界内。外部源代码可用于推断相关应用程序的行为。在这种情况下，应用程序外部源代码的相关部分应包括在内，但应清楚地标记为外部。

•符合本国际标准的实施必须列出自动功能点的所有输入。计算由主题专家（SME）提供的技术。

 

 

1.4功能点计数过程概况

自动功能点计数的实施应通过以下步骤进行，并生成以下输出。

1。收集并访问清单中列出的执行本国际标准的系统使用的输入列表，并确定应用边界。

2。创建应用程序模型。

3。检测数据功能：

a.检测关系数据库中的逻辑文件

B.检测平面文件中的逻辑文件

4。检测事务函数。

5。检测并区分内部和外部逻辑文件。

6。计算应用程序中的功能点总数。

7。生成以下输出：

a.计数算法使用的所有输入的完整列表，包括上下文相关和提供的SME输入。

b.输入中指定的模式与应用程序中检测到的模式匹配的所有实例的列表。

c.输入中指定的模式匹配但被忽略的所有实例的列表以及已忽略实例。

d.应用程序中所有事务入口点及其权重的列表。

e.应用程序的所有数据函数及其权重的列表。

f.每笔事务：

1. 数据功能列表-外部接口文件（EIF）和内部逻辑文件（ILF）包含在该事务及其在源代码中的位置中。
2. 对于每个数据函数（EIFs和ILFs），数据元素类型（DETs）的计数和记录元素类型（RETs）及其在源代码中的位置。
3. 对于每个事务功能（EIS和EOS），DET和文件数量的计数，引用的类型（FTRs）及其在源代码中的位置。

g.应用中的数据功能点总数。

h.应用程序中事务功能点的总数。

i.数据和事务函数之间的映射。

j.应用中的功能点总数。

自动功能点计数程序的步骤1是手动执行的，通常借助于应用中的相关专家。应用程序边界的确定必须使用应用程序用户/所有者的并发。一旦建立了应用程序边界，并且输入已收集并正确配置以供自动功能点计数技术使用，其余该过程应在无需额外人工干预的情况下进行。

1.5应用模型

1.5.1应用模型元素

应用程序模型是通过分析应用程序规模大小的源代码产生的。它应包含在自动功能点计数过程中使用的应用程序静态元素。应用模型是定义为表6.1中列出的所有应用程序代码实体及其依赖项的列表。应用模型元素以与ifpug cpm一致的术语表示。

应用程序功能大小是每个数据和事务函数的功能大小之和。功能每个数据和事务函数的大小是通过评估它们各自的复杂性来确定的，然后使用它为每个函数分配大小的复杂性结果。

为了度量每个数据和事务函数的复杂性，所有数据和事务函数都是使用表示数据元素和事务函数之间的几个对象直接依赖关系的有向图标识，这种图是根据应用程序代码和数据模式的分析构建的。（从数据定义中显式的和从数据文件的推断中隐式的）。以下子条款提供进行这些分析的指南。

1.5.2数据功能检测

IFPUG数据功能应包括内部逻辑文件（ILF）和外部接口文件（EIF）。这些数据功能旨在表示为满足内部和外部数据需求而提供给用户的功能。这里使用的术语逻辑文件是指一组逻辑相关的数据，而不是这些数据的物理实现。本国际标准中阐述的方法描述了如何识别数据的逻辑分组。

通过以下方式检测逻辑文件：

•在关系数据库中检测逻辑文件

•检测平面文件中的逻辑文件

•检测分层数据库中的逻辑文件

•通过SME提供的上下文信息检测逻辑文件

 

1.5.2.1关系数据库中检测逻辑文件

功能点计数模型假定所有数据元素都可以被最终用户识别为信息，命名数据函数。由于关系模型的普遍性，这些实体通常对应于表（在数据库、文件或内存位置中）。问题是，这种映射并不总是一对一的。对于任何由于多种原因，用户可识别或原子实体有时可以拆分为一个主实体和一个或多个细节。例如，当一个字段可以附加多个值时，可以拆分一个实体，例如当用户有多个电子邮件地址时，包含用户的电子邮件地址。这通常会导致将字段与单个主实体的多个值。这个过程也称为关系数据库的规范化。尽管关系数据库的规范化会导致数据库中出现多个实体或表，但是函数点分析要求只计算用户可识别或原子实体。所以为了执行一个功能点分析一个系统的源代码，我们需要颠覆关系数据库的规范化，这是一个已知的过程。作为去规范化为了从一组数据库表中识别数据功能，应访问每个数据库表，以确定是否主表的详细表。每个表只能访问一次，以确定该表是否是主数据库表或特定表的详细表。

为了将数据表分组到主数据表下，必须依次检查以下测试：

1。该表具有主键，并且具有对另一个表的外键约束，这是一个表扩展模式。

2。该表在另一个表的外键上具有唯一索引。这是另一个表扩展模式。

3。该表由2个或3个外键属性和可选的主键组成。这是一个关联表。关联表总是与另一个表聚合在一起。选择了一个相关表基于最佳匹配算法。关联表从不被视为主表。

4。该表具有一组具有级联删除约束的强制外键。这是经典的主细节关系。主表是根据最佳名称匹配选择的。

5。该表具有一组外键，其他表具有相似的名称（相似的后缀和前缀）。主表是根据最佳名称匹配选择。

最佳匹配算法应基于：

•最长前缀或后缀（最大前缀/后缀匹配更相关）。

•确保可复制算法的最后一个标准只是实体排序名称中的第一个出现。主表A虽然不常见，但可能被视为另一个表B的明细表。在这种情况下，明细表和主表集群应在表B下汇总。

 

1.5.2.1.1筛选临时和技术数据表

一些数据表，即临时数据表和技术数据表，在按顺序调整大小的过程中被忽略。将自动计数过程与ifpug规则相匹配（参见“功能分级框架”[ifpug，2003]。

本国际标准规定了以下两种方法来识别临时或技术数据表条款：

1。使用查找结构匹配数据库表。

2。匹配的数据库表编码数据命名约定。

应在最终报告中标记临时或技术性数据库表，并应在这个过程的其余部分被忽略。

 

6.5.2.1.2查找结构的数据库表

具有查找结构的数据库表必须符合以下条件：

•有一个主键。

•可选，只有一个整型属性支持顺序（允许单个整型属性支持索引）以及排序查找数据）。

•没有其他具有级联删除关系的数据库表。

•少于三个文本属性或一组名称与名称、消息、类型、代码匹配的文本属性，描述、描述或标签。

 

1.5.2.1.3代码数据命名约定匹配

此检测应根据作为用户输入提供的命名约定进行。这些参数可以是在启动时根据所需的用户输入进行定制。这里显示的是默认值。每个命名约定模式由一个描述意图的标签和一个使用Perl 5不区分大小写的正则表达式定义。

正则表达式语法。英文数据库表的默认命名约定为：

•  Lookup entities - ^(lkp_.+|.+types?|.+_t)$

•  Status entities - ^(.+status)$

•  Translation extension entities - ^(.+_l|.+_lang)$

•  Temporary data entities -

^(.+temp|.*session.*|.*error.*|.*search.*|.*login.*|.*logon.*|.*filter.*)$

•  Template data entities - ^(.*template.*)$

•  Auditing data entities - ^(.*history.*|.+_old|.*audit.*)$

1.5.2.2平面文件中检测逻辑文件

尽管逻辑文件通常存在于关系数据库中，但它们也可以以任何形式永久存储数据。在关系数据库中存储数据的常见替代方法是将逻辑文件存储在平面文件中。问题是分析平面文件是不存在（统一的）数据定义语言，这对于关系数据库是存在的。即使存在平面文件的数据定义（例如，XML文件的DTD或XSD），通常也无法推断哪些部分定义了应用程序的RET，哪些部分仅用于将平面文件中的数据分组。因此，分析不应依赖于应用程序的数据定义，而应依赖于数据本身。根据这些数据，分析应推断出其结构，从中应计算出逻辑文件。从数据本身推断数据的结构需要分析对平面文件比为关系数据库创建的平面文件多。

为了自动分析平面文件，应将其分为不同的类别，随后可将其分为不同的类别分析。

 

在本国际标准中，我们区分以下平面文件类型：

•表格格式的平面文件-包含ASCII编码的数据矩阵的文件。常见的例子包括逗号分隔值文件、制表符分隔值文件和空白对齐值文件。

•嵌套标记形式平面文件-以树形式包含ASCII编码数据的文件。常见的例子包括XML，

HTML和SGML文件。

除了上面列出的平面文件类型之外，应用程序中可能还有更多不同的文件类型。如果没有更多的信息，从我们无法分析的数据文件中推断出RET和DET的数量是有风险的。更进一步。一种选择是假设所有文件都包含一个RET。但是，在某些情况下，假设不成立。例如，当文件系统中目录中的所有文件都包含单个记录时，实际上使目录成为RET而不是文件。为防止出现错误，不可识别的文件不应包含在本文件中。

本国际标准假定每个平面数据文件组成一个独立的逻辑文件。信息在文件系统中，不足以对两个不同独立数据之间的关系做出可靠的假设。文件系统上的文件，这对于允许多个文件分组到单个逻辑文件是必需的。

平面文件的分析应包括五个步骤：

1。创建所有（平面文件）数据文件的清单。

2。确定平面文件数据文件的类型。

3。区分包含临时数据的文件（例如临时文件和交换文件）或不包含临时数据的数据由用户维护（例如，程序员的配置文件）和包含永久数据的文件。

4。确定每个平面文件中的RETs和DETs数量。

5。从仅读取且包含3个或更少DET的平面文件中删除所有RETs。

最后一步防止将代码表计为RETs。如果以这种方式删除所有DETs，则平面文件应被忽略。

1.5.2.2.1过滤临时和其他非维护文件

筛选临时文件是一项主要要求，因为并非应用程序存储的所有文件都包含应用程序永久存储的数据。非永久性数据不应按照功能点指南计算。正在计数不应包括的其他文件是系统用户（即终端用户和系统操作员），但由应用程序开发人员或编程环境生成和维护的

（例如，某些库或应用程序服务器的配置文件）。过滤不包含永久性数据的文件应包括两个步骤：

1。最初，通过用户选择符合本国际标准的实施方案，用户应选择哪些文件不包含永久性数据，应将这些数据文件从要分析的文件中删除/排除。

2。然后，通过文件名过滤——符合本国际标准的实现应使用文件名。用于检测已知仅包含临时文件或最终用户不维护的文件的平面文件的模式。

为了应用第二步-基于文件名的瞬态数据文件过滤-下面列出的文件名模式应过滤掉。每个命名约定模式都由一个标签定义，用于描述意图，并且使用Perl5不区分大小写的正则表达式语法的表达式。默认命名约定模式为：

 

•  Temporary files - ^(te?mp.+|.+\.te?mp|.+\.sav)$

•  Backup files - ^(.+\.bak|.+~|.+\.sav|.+\.old)$

•  Audit files - ^(.+\.log)$

 

1.5.2.2.2表格格式平面文件分析

表格格式的平面文件可以由已知包含表格格式数据的文件扩展名识别：

•以制表符分隔的值文件，可通过符合Perl 5不区分大小写规则的文件名进行标识

表达式^.*\.tsv$（即以“.tsv”结尾的文件名）。

•逗号分隔值文件，可通过符合Perl 5不区分大小写规则的文件名进行标识

表达式^.*\.csv$（即以.csv结尾的文件名）。

为了自动分析表格格式的平面文件，本国际标准作出以下假设：

这将指导实施：

•每个文件包含一个单独的关系实体类型-此规则的例外情况是，如果操作系统清除分段分割平面文件的规则（例如，ascii代码集中的soh、stx和etx字符）。如果一个部分-存在结束字符，每个部分应计为单独的ret。

•每个文件包含一个或多个记录-文件中的每个记录由一个记录分隔符分隔（例如ASCII码集中的CR和LF字符）。文件中的第一行/第一条记录应视为可能包含标题，因此被忽略。应分析第二行/记录和每个后续行，以计算检测数量。

•文件中的每个记录包含一个或多个字段或DET-每个字段或DET由字段分隔分隔开性格。对于单个RET，字段分隔字符应假定为常量（例如，制表符、逗号、ASCII代码集中的冒号或分号字符限定为分隔字符）。

 

1.5.2.3层次数据库中逻辑文件的检测

在大型机应用程序中大量使用的分层数据库（如IBM的IMS）使用分层存储数据模型。在层次数据库中，层次模型是使用称为段（即KDM的数据：数据集）。每个数据段可以包含几个称为字段（即kdm的数据列：columnset）。为了使国际监测系统数据库的分析自动化，本国际标准的实施应使以下假设：

•每个层次数据库应映射到单个逻辑文件。

•数据库的每个数据段应视为记录元素类型。

•每个字段应视为一个数据元素类型（DET）。

 

1.5.3检测事务函数

事务函数表示为用户提供的处理和使用数据的功能应用程序。本国际标准确定了两种不同类型的交易功能：

•外部输入（EI）

•外部输出（EO）。

功能点计数标准通常根据主要目的。由于无法通过自动功能点计数工具评估主要目的，因此所有输出和查询应算作外部输出（EO）。基本过程应定义为满足以下所有特性的最小活动单元：

•跨越应用程序边界

•构成完整的交易

•自给自足

•使应用程序的业务保持一致状态

外部输入是处理从边界外发送的数据或控制信息的基本过程。安外部输出是将数据或控制信息发送到边界之外的基本过程。代码数据不得被视为有效的数据函数，不符合识别事务函数的条件。

符合本国际标准的自动功能点算法应识别交易

通过检测对已标识的内部数据实体所做的事务操作，函数类型。

•修改数据实体内容的交易应视为外部输入（EI）。这些交易是那些写入、插入、删除、更新属于应用程序数据函数的数据。

•不修改数据实体内容但只使用这些内容的事务应被视为外部输出。这些事务是从数据函数（ILF&EIF）中读取或选择数据的事务。应从表示用户界面和通信通道的源代码模式中捕获事务。与其他应用程序一起，以确保它们跨越应用程序边界。

为了在用户界面层捕获事务，代码分析应识别：

•与完整的数据层交互的独特最终用户事件。

•不同的最终用户输出，由完整的数据函数创建。典型的最终用户输出包括：屏幕、窗体、

为了捕获通信层上的事务，代码分析应识别所有可以由外部应用程序生成，以及为外部应用程序生成的所有不同事件。一对请求和响应事件构成单个事务。每一笔交易应按顺序使用静态代码分析进行跟踪。捕获所有涉及的数据函数、涉及的DET以及事务对这些数据执行的操作。功能。当静态代码分析器在事务上下文中找到多个可选路径时，它应该考虑这些多个可选路径将成为同一事务的一部分，以便捕获处理的所有数据函数，可能增加事务复杂性。

为了确定事务的开始和结束，静态代码分析器应假定代码包含一个完整的事务，只要它可以显示从用户界面到数据实体的一个或多个代码路径。如果事务执行取决于自动化工具未知或不可用的代码，代码端点（例如，外部Web服务操作或RPC）应编目并在生成的报告中列出，以便检测和量化特定计数过程缺少的模式和库。

 

1.5.4检测内部和外部逻辑文件

数据功能（logical files）应分类为内部逻辑文件（ILF）或外部接口文件。（EIF）基于它们在应用程序中的有效使用。在应用程序中有效使用数据函数应通过与应用程序的事务函数的交互来确定。如果维护数据功能通过应用程序的任何事务函数，数据函数应确定为ILF。数据函数如果事务函数插入、更新、删除（写入访问）和/或更改数据，则由应用程序维护；

然后将其识别为ILF。如果在应用程序的任何处理中都没有使用数据函数事务函数，应用程序中不应计算数据函数。

ifpug计数实践手册（ifpug cpm）将内部逻辑文件（ILF）定义为：

“内部逻辑文件（ILF）是在边界内维护的一组逻辑相关数据或控制信息。应用程序的。ILF保存通过应用程序的一个或多个基本过程维护的数据计数。数据组是通过正在计数的应用程序中的基本过程来维护的。”

“控制信息”是影响应用程序基本过程的数据。“维护”是指通过基本流程修改数据（例如，添加、创建、修改、更新和删除）。如果数据函数不是由应用程序维护，如果事务仅选择（读取）数据，则应将其标识为外部接口文件（EIF）。

ifpug计数实践手册（ifpug cpm）将外部接口文件（EIF）定义为：

“外部接口文件（EIF）是应用程序引用的一组逻辑相关数据或控制信息，但保留在另一个应用程序的边界内。EIF保存通过一个或多个元素引用的数据应用程序应用程序内的进程已计数。“应通过检测满足EIF定义的数据组或控制信息来识别EIF。这些计算自动功能点的应用程序不维护数据组。

(完)