Sunday, March 28, 2010

Function Point Analysis, Data Functions

Data function is one of the two most critical components of the entire FPA process. The functionality requirements of the application are met through data functions and are facilitated by means of internal and external files. The focus here is on logical storage of data in the forms of files and not the physical implementation.
IFPUG’s Counting Practice Manual broadly classifies the data function types into two categories: Internal Logical Files (ILF) and External Interface Files (EIFs). The boundary of the application being counted decides what is internal and what is external to the system. All files owned and maintained be the application being counted are ILFs and all files referenced by the application but outside the boundary of the scope of count, are EIFs. In other words, if the CRUD (Create, Read, Update and Delete) factors apply to a file in the system, it is likely to be an ILF, and if it is read only, the file is an EIF.
The CPM 4.2 defines ILF and EIF as follows:
ILF: An internal logical file (ILF) is a user identifiable group of logically related data or control information maintained within the boundary of the application. The Primary intent of an ILF is to hold data maintained through one or more elementary process of the application being counted.
EIF: An external interface file (EIF) is a user identifiable group of logically related data or control information referenced by the application, but maintained within the boundary of another application. The primary intent of an EIF is to hold data referenced through one or more elementary process within the boundary of the application counted. This means an EIF counted for an application must be an ILF in another application.
The basic difference between an ILF and EIF is that although the ILF is owned and maintained by the application being counted, the EIF is used and referenced by the application being considered for FP counting purpose. The EIF referenced by the application being counted must be an ILF to another application.
Determining Complexity of ILFs and EIFs
IFPUG has defined a clear process of identifying an ILF or EIF as Low, Average or High and also has a fixed number of unadjusted function points assigned to each of these categories. Only two major components of any data file decided its complexity: data elements (DET) and record elements (RET).
DET
A data element type (DET) is a unique, user-recognizable, non-repeated field. In simple terms, it is a filed within a record of a file or a column in a database table (file), but the mapping of a filed or column in the file should be with respect to the data element recognized from the user point of view.
RET
A record element type (RET) is a user-recognizable subgroup of data elements within an ILF or EIF. There are two types of subgroups, Optional and Mandatory.

ILF/EIF Complexity Factor
Range
1 to 19 DET
20 to 50 DET
51 or More DET
1 RET
Low
Low
Average
2 to 5 RET
Low
Average
High
6 or more RET
Average
High
High

ILF FP Contribution
Functional Complexity Rating
Unadjusted Function Points
Low
7
Average
10
High
15

EIF FP Contribution
Functional Complexity Rating
Unadjusted Function Points
Low
5
Average
7
High
10

Points to Remember
·       -   An ILF or EIF may appear repeatedly in multiple sections of the same application during the counting process. Ensure that once a specific, identified ILF or EIF is defined and recorder, any subsequent appearances of the same ILF or EIF should be ignored.
·         -  The basic definition of an ILF and EIF maps them to a logical implementation of a file. Do not confuse this with the physical implementation of an existing data model in an RDBMS system. You should identify an ILF or EIF based on user view and ensure it is a logical implementable only.

No comments:

Post a Comment