ILF Example

Example taken from

In the FPTracker application the data is stored in a series of relational database tables, so we'll use those as the basis of our analysis. The following is a list of the database table names used in the FPTracker application:

  1. Project
  2. Entity
  3. Process Group
  4. Process
  5. ProcessDETs
  6. ProcessEntities

The full listing of the fields stored in each table are shown in the following tables. These tables provide each field name, a field description, and indicator as to whether the field should be counted as a DET, and other notes/comments regarding each field. The last row of each table provides a count of the total number of DETs in the corresponding database table.

Table 13: The "Project" database table

Field Description Count as a DET? Notes
project_id Sequential id, system-assigned. No This is a technical artifact. It is not user-recognizable, and therefore not counted.
project_name The name a user assigns to a given project. Yes
2 additional fields, project_type and description that are counted as DETs
3 total DETs

Data snipped, see link above for details.

Plus five additional tables (Entity, Process Group, Process, ProcessDETs, ProcessEntities) with 6, 8, 2, 4, 3 DET's respectively.

I won't keep you guessing about these tables; the data they represent are all ILFs (and not EIFs) because they are maintained within the boundary of the FPTracker application. That being said, you're about to see some of the complexity of FP counting.

In this particular application there is not a one-to-one relationship between the database tables and the way a user would logically view this data being stored. As an FP counter, and also the primary user of this application :), I think of the data logically being stored like this:

  1. Project
  2. Entity
  3. Process Group
  4. Process
        1. ProcessDETs
        2. ProcessEntities

In this case what I'm saying is that, as the user of this application, I think of the Process DETs and the Process Entities as being logical subgroups of the overall Process data. Okay, you say, but what does that matter to me as an FP counter? Let's look at how our counts would differ if we count the tables first as being separate, then second as being logically merged.

First, if I think of the these six tables as separate ILFs, because of the number of DETs they contain, each table would be considered to be a "Low" complexity table. Because each Low table is worth 7 FPs, the FP count for these six tables would be 42 FPs (6x7=42).

However, if I look at the tables from a "logical" perspective instead of the physical RDBMS layout, what I really have are four logical groups. Because of their DET and RET counts, all four of the groups are considered "Low" in complexity. So, in this case, the total count is 28 FPs (4x7=28).

Therefore, had I counted the physical implementation of the tables as opposed to a logical grouping, I would have over-counted this portion of the application by 14 FPs, or 50%. This is a good example of where a physical implementation differs from a correct, logical grouping for an FP count. Total Count Due to ILFs

To tally up the FP count due to ILFs, I've identified four ILFs, with the number of RETs and number of DETs as shown in the table below. The first three ILFs are very straightforward, and as discussed above, I believe that I have one Process ILF with three RETs: (1) Process, (2) Process DETs, and (3) Process Entities. Using the ILF lookup table shown earlier in Table 2, I see that each ILF is considered "Low" in complexity. Looking up Low Complexity ILFs in Table 3, I see that a Low Complexity table is counted as seven FPs. This gives me the total of 28 FPs as a result of ILFs.

Total FP counts due to ILFs

ILF No. RETs No. DETs Complexity Function Points
Project 1 3 Low 7
Entity 1 6 Low 7
Process Group 1 2 Low 7
Process 3 13 Low 7
Total: 28