The Excellence Determining ILF and EIFs

Recently, the European Parliament has included the Functional Size concept (base for IT strategic information such as Productivy, Quality or PDR, in spite of low level development methods, tools, trends, ...) as Transversal Engineering Framework in the European Agency for the operational management of large-scale IT Systems in the Area of Freedom, Security and Justice (eu-LISA). IFPUG is the father of the Functional Size (ISO/IEC 14143). In this article (published in MetricViews) is included a set of tips and hints to size correctly the ILFs and EIFs

To measure a project with a high level of accuracy and excellence, adaptation or an enhancement is a must for a CFPS or CFPP.

Identifying correctly the Logical Files (ILF and EIF) is perhaps one of the most challenging tasks when no conceptual or logical data model exists or it is not as correct as desired.

In the opposite way, Input or Output transactional functions (EI, EO and EQ) by general rule have less discussion because in almost all the cases the evidences are clearly visible; e.g., an input screen, a process that imports a file, a report, a process that generates a file... Perhaps the main discussion can arise, again, determining what is considered a file (FTR; File Type Referenced) for those input and output transactions, and to refine the “process” concept. In addition, some small debate about the concrete number of DETs can exist, but those DET debates, in most of the cases, can be skipped because the size will be exactly the same if the ILF/EIF has 71 or 72 DETs. The exception is when the DET number determines a change in the process complexity from low to average, from average to high or vice versa.

It is well known, even for the people with relatively little experience counting Function Points, that a logical file is something different to a physical file. Sometimes technical or functional experts are more familiar with objects that can be touched, such as a physical file or a database table, for example; “logical” information is a little bit more abstract.

Obviously, those differences are essential because the IFPUG Function Point Counting Practices Manual (CPM) is based on logical files.

Even it is not new that Function Point analysis uses concept of a logical data entity, from the user point of view, that can be grouped in one or more logical files. Moreover, it is important to emphasize the words “user view” because sometimes a different understanding can be found applying the “user view” concept.

It is not unusual to see that a logical data model does not exist, in small as in non-small companies or projects. This situation could be improved but it is the real-life situation in many cases. In other cases, instead of this “user view entities” are reflected directly in the database tables or files.

Not having the correct information from the user point of view, or not reflecting it in the proper project documentation, can result in non-accurate counts. To consider a new superfluous/extra average complexity Internal Logical File (instead to consider that this is not really a new file because it might be comprised into an already existing file) will be counted as 10 FPs. This 10 FPs size will be exactly the same as creating two new average External Outputs (2 x 5 FPs).

Determining that an application has five outputs instead of three, or three instead of five, is very easy and the different parties involved (a CFPS, a user, IT technical people from the customer side, IT provider, etc.) will most likely arrive at the same conclusion after gathering all the information and after applying the CFPS to the correct criteria (criteria=method, output concept, boundary cross concept, process concept, etc.), but talking about the “files” concept, to arrive to the same point may not be so easy.

Why? Sometimes, different people with different disciplines (not technical, technical, CFPS experts) may see the situation differently. This may be the result of the information not being completely written, or the written information reflects more concrete technical aspects than functional (user eyes). Some parties could be interested in having higher or lower counts and even this last argument can increase artificially or decrease the number of files.

Special attention may be put into applying the part 3, chapter 2, of the CPM, step 1 “Identify Logical Files” to determine correctly the files from the user point of view, and step 4 “Identify Record Element Types” for identifying if different entities are one logical file or more than one.

Those two steps are essential and, in spite that it seems obvious, it is crucial to remember [with special attention to the first and second point], that:

• A logical file is a logical group of data as seen by the user.
• More than one data entities can derive into one logical file.
• Information contained might be recognizable or required for the user.
• Entities not maintained by any application are excluded.
• Code data entities are excluded.
• Entities without attributes required by the user are excluded.
• Entities created just for technical reasons are excluded.

To have all of the above points totally clear, to ensure that the answers are based on the word “user point of view” and without any kind of technical influence (synonym in some cases to a pseudo contamination) is essential for arriving to the correct and accurate results.