As noted in Counting IFPUG Function Points, The Process and More, there are two data functions: Internal Logical Files (ILF) and External Interface Files (EIF). ILFs are logical groups of user-recognizable data maintained within the boundary of the application being sized and EIFs are logical groups of user-recognizable data referenced within the boundary of the application being sized, but maintained in another application. Both of these data functions come in three sizes. IFPUG uses the labels of low, average and high, but because of my personal background small, medium and large feels better. The different sizes represent file size complexity. I feel that using the word complexity when determining the size of a file (or a transaction) is confusing as complexity in development and maintenance generally is applied to a set of concepts that is much broader than size.
How do we size ILFs and EIFs?
The size of logical files is determined by the number of data element types and the number of record element types. Clear as mud? A data element type (DET) is defined as a user-recognizable, non-repeated attribute[1]. The IFPUG Counting Practice Manual goes into depth on rules to help recognize and count DETs in a standard manner. If you ever do a count with me you might hear me ask whether the DET is maintained or retrieved; whether the DET is unique; whether the DET should be counted as part of another DET, or whether the DET is needed to create a relationship with another group of data. Once we have a handle on the rules to ensure we only count unique, user-recognizable attributes, counting the DET is as simple making tic marks on a piece of paper and then summing them up.
Where DETs is a simple concept, record element types is more difficult. The definition of a record element type (RETs) is a user-recognizable subgroup of data elements within an ILF or EIF. Classifying groups of data as RETs requires understanding the relationships between groups of data. For example, an HR system that has a group of DETs used to define employees and another group of used to define employee dependents. Looking at the relationship between the logical groups “employees” and “dependents,” it is apparent that a dependent can’t exist without an employee, but that an employee does not need to have a dependent. We would consider employee and dependents to be two RETs, employee is a mandatory subgroup and dependent is an optional subgroup. Understanding the basic data modeling and normalization techniques is useful for identifying RETs.
Once you have worked through counting DETs and RETs for either an ILF or an EIF, we can determine the size of the logical group. IFPUG provides a simple matrix to derive size.
RETs |
1 – 19 DETs |
20 – 50 DETs |
51 + DETs |
1 |
Low |
Low |
Average |
2 – 5 |
Low |
Average |
High |
6+ |
Average |
High |
High |
Using the matrix is a matter of counting the number of RETs in a logical group, finding the corresponding row and then finding the corresponding column for the number of DETs that you counted for the logical group.
Using the employee and dependent example from above, let’s assume that employee has 8 DETs (Employee Number, Name, Address, City, State, Zip, Work Location, and Job Code) and dependent had 8 DETs (Employee Number, Name, Address, City, State, Zip, Relationship and Birth Date). The total count of DETs would be 15 (employee number is not counted twice because it is repeated in both entries). We would find the column and row in them matrix that corresponds to two RETs and 15 DETs which tell us that the logical group was classified as low. We would then repeat the process for each ILF and EIF we identified and counted during the function point count.
[1] Function Point Counting Practice Manual 4.0, Part 3 2-24
December 26, 2013 at 11:55 pm
[…] types of transactions identified in the IFPUG Function Point methodology are classified into three categories: low, average and high (small, medium and large). The process for sizing transactions is similar […]
December 27, 2013 at 11:56 pm
[…] our examples from ‘Counting IFPUG Function Points: Small, Medium and Large Logical Files?’ and ‘Counting IFPUG Function Points: Sizing Transactions.’ Our function point count would […]
June 30, 2014 at 3:54 pm
[…] Measure the data functions. IFPUG recognizes two types of data functions. The first is an Internal Logical File (ILF). An ILF is a user-recognizable group of logically related data maintained within the boundary of the application being measured. Employee is an ILF typically found in a human resources application. The logical grouping of data needed to define an employee would be grouped together as single logical group (even if it were in multiple tables or objects). The logical group data named “employee” would be easily recognizable by users of the systems. This logical group of data can have records added, changed and deleted by an HR system, therefore the ILF can be maintained. The second type of data function is called an External Interface File (EIF). An EIF is an ILF from another application that is used as reference. For example, the HR system may require the entry of a health benefit package when adding or changing an employee. Let’s assume that the definition of the health benefits package was maintained in the benefits application. The health benefits package would be an ILF in the benefits application and an EIF if used for validation or reference in the HR application. A counter would identify the ILFs and EIFs in the scope of the count. When doing an enhancement count the counter would count all of the ILFs or EIFs that were added (new), changed (modified structure) or deleted. Application counts would count all ILFs within the boundaries and any EIFs referenced in the application. Finally a development project would count any ILFs added (by definition a development project is equivalent to a new application. Once the counter has identified the data functions he or she will determine their size. We explore the science of sizing ILFs and EIFs here. […]