Step 3a: Determine the count resulting from ILF's

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

Table 14: The "Entity" database table

Table 15: The "Process" database table

Table 16: The "Process Group" database table

Table 17: The "ProcessDETs" database table

Table 18: The "ProcessEntities" database table

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. 

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

Table 19: Total FP counts due to ILFs

Next: Step 3b: Determine the Up: A sample count Previous: Step 3: Determine the