By Todd Merry
Welcome to part 3, where I’ll continue traversing the wonders of the Function Point Analysis. In part 3, I’ll take a brief look at some samples that will help in the identification of External Files, Queries and finally an Output – bringing all 5 types of Elementary Processes into focus for you and ultimately arming you with a very powerful tool to add to your arsenal of estimating tools.
I’ll continue to utilize sample counting exercises as the means to demonstrate the concepts that I plan to cover in this blog, with the sincere hope that they are meaningfully detailed enough to assist you with applying the concepts to your own project estimating exercises.
A data function count with an external file
I’ll continue to build upon the same real world application that I started using in Part 1, whereby there is a component of a system that tracks and stores employee information, utilized in reporting on job activities. In Part 2, I identified the data elements that will be stored within this component to be: First Name, Last Name, Email, User Type, Username, Password, Employee Number, Status, Paygroup, Comp Code and Cost Code.
Here in Part 3, our requirements have now evolved to encompass the notion that the data for the Paygroup, Comp Code and Cost Code fields will now be supplied to this new system by existing data that is maintained in the company HRIS, rather than requiring the user to enter all of this data. The Employee Number that the user enters in our new system will force a transaction to ‘fetch’ the needed data from the HRIS system. For this example, we’ll continue to assume that all of this data will be stored within the bounds of the application you are estimating, in a single database file named “Employee”.
Given this information, this Data Transaction now involves 2 files – an internal file that the new application maintains, and an external file where 3 fields are ‘fetched’ from an HRIS system that is responsible for maintaining the data that is fetched. So, we know that we need to count the number of DET’s & RET’s for both an internal file and an external file to determine the level of complexity of this data function, which will then identify for us the number of Function Points to award.
Adding a new employee
Below is a screenshot of the new employee screen, with the Paygroup, Comp Code & Cost Code fields ‘grayed’ out, indicating to the user that they are read only fields. Once the user fills in the necessary fields and presses Save, the application will retrieve these 3 fields from the HRIS system using the Employee Number field as the lookup value that is used to retrieve that data. Let’s systematically break this screen down in to its Function Point components.
The internal file
The employee database table, which we have previously identified as an Internal File now contains 8 DET’s (First Name, Last Name, Email, User Type, Username, Password, Employee Number and Status), all being stored in a single FTR. Note that you should not count the Paygroup, Comp Code or Cost Code fields as DET’s for the Internal file, as they will not be ‘maintained’ by our real world application.
The external file
The 3 fields (Paygroup, Comp Code & Cost Code) that contain ‘fetched’ data from the HRIS system are counted as DET’s for an external file. For the purposes of this exercise, we’ll assume that these 3 fields are maintained in a single FTR in the HRIS system.
Referencing the table that the IPFUG provides for determining the complexity of Internal and External Files, we determine that both the Internal File (1 RET and 8 DET’s) and the External File (1 RET and 3 DET’s) fall into the Low Complexity category.
| 1-19DET’s | 20-50 DET’s | 51 or more det’s | |
|---|---|---|---|
| 1 RET | Low Complexity | Low Complexity | Average Complexity |
| 2-5 RET’s | Low Complexity | Average Complexity | High Complexity |
| 6 or More RET’s | Average Complexity | High Complexity | High Complexity |
Next, let’s analyze the User Interface to account for the Transaction of this data within the system. We’ll also determine the number of Function Points to award this piece of the system.
A simple Transaction Function Count
Referencing the screenshot from the same real world application used in the Sample Data Function above, we can see that the screen still provides a function that enables a user of the application to create a New Employee within the application, but now they only have to enter 8 pieces of information. The remaining 3 pieces of information are ‘Fetched’ from an external HRIS system. I mentioned above that when the user presses Save, the system will ‘Fetch’ the data for the 3 fields from the HRIS system, using the Employee Number as the lookup field. This type of transaction is distinctly named an External Query. With this slightly more complex system, the act of pushing the save button will kick off two transactions. First, the system will go to the HRIS and fetch some data and then secondly, store the data entered by the end user and the data that is fetched from the HRIS into a single FTR.
Similar to the Data Function Count, our Transaction Function Count is now split into two parts. The data that is input by the user still qualifies as an Input, but now we have a portion of the transaction that conducts a Query to retrieve some data from an external system.
In part 2, we used the following table to identify the level of complexity for the input:
| 1-4 det’s | 5-15 det’s | 16 or More DET’s | |
|---|---|---|---|
| 0-1 FTR’s | Low Complexity | Low Complexity | Average Complexity |
| 2 FTR’s | Low Complexity | Average Complexity | High Complexity |
| 3 or more FTR’s | Average Complexity | High Complexity | High Complexity |
Given the information above, the Input file consists of 1 FTR, and 8 DET’s (the 8 fields filled in by the user). I’ve highlighted the Low Complexity cell of the table for this Input.
The Query also consists of 1 FTR, because we assumed that the 3 DET’s that are ‘Fetched’ from the HRIS system are contained within one table of that system. The IPFUG provides the following reference table to determine the level of Complexity for a Query:
| 1-5 det’s | 6-19 det’s | 20 or more det’s | |
|---|---|---|---|
| 0-1 FTR’s | Low Complexity | Low Complexity | Average Complexity |
| 2-3 FTR’s | Low Complexity | Average Complexity | High Complexity |
| 3 or more FTR’s | Average Complexity | High Complexity | High Complexity |
At this point, our sample screen has become fairly complex in that we’ve determined the data function is made up of both an Internal and External File, each with a low level of complexity. In addition, we’ve determined the transaction function is made up of both an Input and a Query, each with a low level of complexity. Referencing the IPFUG’s secondary table we can determine how many total Function Points to award for this screens data and transaction functions:
| Low | Average | High | |
|---|---|---|---|
| Input | 3 | 4 | 6 |
| Output | 4 | 5 | 7 |
| Query | 3 | 4 | 6 |
| Internal File | 7 | 10 | 15 |
| External File | 5 | 7 | 10 |
In summary, we’ve now awarded a total of 18 Function Points for this more complex transaction. With the addition of the External File in the mix, we’ve nearly doubled the total number of Function Points. If you remember, we counted only 10 Function Points in Part 2 of my blog, when we were analyzing a self contained system. I find it interesting to note that taking the step to make the system easier to use for the end user, by requiring less data to be entered, does have a cost associated with it.
What about the output?
At this point, you’ve probably noted that I haven’t covered an example that includes an External Output as part of the transaction function. I guess I’m guilty of saving for last, what I believe to be the most difficult concept to grasp.
By its simplest definition, an Output is an elementary process in which derived data passes across the boundary of the system. By derived, we mean that one or more of the data element(s) that may or may not be maintained in an ILF are computed by utilizing other data elements from the transaction. This may sound a bit convoluted, so let’s go over a simple example.
In the sample screen that I’ve been using in Part 3 of this blog, when we ‘Fetch’ the data from the external HRIS system, let’s also retrieve the employees Date of Hire. In the UI of our new system, we’ll add a new field labeled ‘Length of Service’. Our system will determine the Length of Service by computing the difference between the ‘Data of Hire’ date that is ‘Fetched’, and ‘today’s’ date – thus whenever a user pulls up the data on screen for a given employee, the Length of Service field will always reflect an accurate ‘Length of Service’ value. In this particular scenario, we wouldn’t even store the resultant ‘Length of Service’ in the Internal File of our system, as the system would dynamically compute the Length of Service whenever any employee in the system is viewed on screen.
In this particular scenario, adding an Output to the transaction function would result in counting an additional 4 Function Points for a Low Complexity output, for a final total of 22 Function Points. This is determined by using the same IPFUG reference table (see above) as you would for a Query. I’ve stated that we don’t have to store the Length of Service value, which counts as 0 (zero) FTR’s and we have 1 data element (Length of Service). Note that our External File would now have 4 DET’s (the addition of retrieving the Date of Hire) instead of 3, but that still results in a Low Level of complexity for our overall analysis of the External File, so the only measurable change to our Function Point count is due to the addition of a Low Complexity Output.
I’d encourage you to seek out some additional examples of External Outputs, as they can sometimes be difficult to identify. The IFPUG has some good examples on their website and you can also find several other examples by simply utilizing your internet search skills and the following keywords, ‘Function Point Analysis Examples’.
The finale – part 4
The hard part is now done! You should now have a solid understanding of how to identify each of the 5 types of Elementary Processes (Internal and External Files, Inputs, Outputs and Queries), AND how to utilize what you’ve learned to count Function Points. In Part 4, I’ll walk you through the process to determine what it takes to translate Function Points into something that is more easily understood, namely people hours.
References
- International Function Point Users Group – www.ifpug.org
- Function Point Training Guide
- Function Point Quick Reference Guide