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

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

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  
project_type The type of project count. Yes  
description A description of the project. Yes  
Total DETs: 3    

Table 14: The "Entity" database table

Field Description Count as a DET? Notes
entity_id Sequential id, system-assigned. No System-generated sequence number. Not user-recognizable.
project_id Foreign key. Yes Do count a DET for pieces of data that are required by the user to establish a relationship with another ILF or EIF. Foreign keys usually fit this definition.
name Name of the entity. Yes  
type Type of entity (ILF or EIF). Yes  
no. RETs Number of RETs in the entity. Yes  
no. DETs Number of DETs in the entity. Yes  
complexity Calculated complexity (Low, Average, or High). Yes  
Total DETs: 6    

Table 15: The "Process" database table

Field Description Count as a DET? Notes
process_id Sequential id, system-assigned. No System-generated sequence number. Not user-recognizable.
pg_id Foreign key. Yes  
name Name of the process. Yes  
type Type of process (EI, EO, or EQ). Yes  
sort_order Order of appearance when displayed. Yes  
no. FTRs Number of FTRs. Yes  
no. DETs Number of DETs. Yes  
complexity Low, Average, or High. Yes  
description Description of the process. Yes  
Total DETs: 8    

Table 16: The "Process Group" database table

Field Description Count as a DET? Notes
process group id Sequential id, system-assigned. No System-generated sequence number. Not user-recognizable.
project id Foreign key. Yes  
name Name of the process group. Yes  
Total DETs: 2    

Table 17: The "ProcessDETs" database table

Field Description Count as a DET? Notes
id Sequential id, system-assigned. No System-generated sequence number. Not user-recognizable.
process_id Foreign key. Yes  
sequence Sort order, for display purposes. Yes  
description User-supplied description. Yes  
Total DETs: 4    

Table 18: The "ProcessEntities" database table

Field Description Count as a DET? Notes
id Sequential id, system-assigned. No System-generated sequence number. Not user-recognizable.
process_id Foreign key. Yes  
entity_id Foreign key. Yes  
sequence Sort order, for display purposes. Yes  
Total DETs: 3    

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