Simplifying the Complex With Function Point Analysis – Part 2

By Todd Merry

Ready for some more estimating madness? Good! Persistence is a wonderful virtue, and you’ll need some persistence to become good at estimating software development projects. In part 2, I’m going to walk you through a couple of sample counting exercises to help you continue to become more familiar with the Function Point Analysis method of estimating software development projects.

Some more definition

In part 1, I introduced you to the notion that there are 5 different types of function points, also known as Elementary Processes (EP’s) – Inputs, outputs, queries, internal files and external files. The 5 types of EP’s can be grouped into 2 types of functions:

• Inputs, Outputs & Queries all qualify as Transactional Functions and,
• Internal Files & External Files are distinguished as Data Functions

These groupings are helpful in determining the types of elements that each function is broken down into, to determine the complexity of the EP and ultimately the number of function points that should be awarded for a given EP.

A Transactional Function is broken down into DET’s and FTR’s, while a Data Function is broken down into DET’s and RET’s. Time for a little acronym sharing:

• DET – Data Element Type is a unique user recognizable, non-repetitive field.
• FTR – File Type Referenced is a file type referenced by a transaction. An FTR must also be either an Internal or External file.
• RET – Record Element Type is a user recognizable sub group of data elements within an Internal or External File.

Great, now we have identified some real things to go count! If you are anything like me, you probably learn best by example. Let’s take a real world application, and apply these concepts to gain some understanding of how to break down an EP into measurable (Countable!) components.

A sample data function count

As a simple example, let’s use a real world application, whereby there is a component of a system that tracks and stores employee information, utilized in reporting on job activities. The data elements that will be stored within this system are: First Name, Last Name, Email, User Type, Username, Password, Employee Number, Status, Paygroup, Comp Code and Cost Code. For this example, let’s 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 would be identified as an Internal File. So, we know that we need to count the number of DET’s & RET’s to determine the level of complexity of this data function, which will then identify for us the number of Function Points to award for this file.

There are 11 DET’s, 1 DET for each of the data elements identified above.

How many RET’s? Based on the information provided, we can judge that there will be only 1 RET – meaning that all 11 DET’s will be stored in a single file or Table in the database.

To take this a step further, let’s say there was an additional requirement to be able to track the history of the employees Comp Code and Cost Code. After all, employees do get promoted, change jobs and such. Given this additional requirement, we would account for a second RET, whereby the Comp Code and Cost Code information is stored in a secondary table in the Employee File, with the Employee Number as the foreign key to maintain the relationship of the employee and the employees Comp and Cost Codes.

In this somewhat more complex scenario, there would still be 11 DET’s but now we would have 2 RET’s. Note that the secondary table would have a 3rd DET, the employee number, but you cannot count this DET twice! By definition, you should only count unique, non-repetitive DET’s once.

Referencing the following table provided by the IFPUG, we determine the complexity of this Internal File to be LOW for either scenario described above (1 RET or 2 RET):

Next, let’s now take a look at how the actual User Interface Might look to account for the Transaction of this data within the system. We’ll also determine the number of Function Points to award this Internal File after we take a look at the User Interface.

A sample transaction function count

Here is a screenshot from the same real world application used in the Sample Data Function above. In this screenshot¹ , we can see that the screen provides a function that enables a user of the application to create a New Employee within the application. The fact that there is a Save button, enables us to quickly identify this screen as an Input, so what we now need to do is simply count the number of DET’s and FTR’s.

So how many DET’s (fields) do you see? Well, the easy to identify fields here are the ‘text field boxes’ like First Name, Last Name etc. Each field is unique and user recognizable. There are 10 (ten) of these types of fields on this screen.

What about the Status Indicator? It does get counted as 1 field (DET) in this instance, as either ‘Active’ or ‘Inactive’ gets stored as a value in the Internal File.

There is also 1 more element that gets counted as a DET on this screen, and that is the Save button. Tapping on the Save button actually initiates the transaction, enabling the system to maintain an Internal File (sends data to a database for safe keeping). So there are a total of 12 DET’s on this screen!

Next, let’s think about how many FTR’s there are on this screen. I purposely chose this screen for its simplicity. The data entered here, based on our limited information of the business requirements, suggest that there is only one (1) FTR. All of the data entered relates to information about a single employee in the database. Upon hitting the Save button, we can safely predict that all of the data will be ‘transacted’ to a single record in an Internal File or FTR.

So this screen, by all accounts, includes 12 DET’s and 1 FTR. Now we can reference a table provided by the IFPUG that helps determine the level of complexity for this Input screen. Once we’ve determined the level of complexity, we can reference another table that will tell us how many function points that can be awarded for this screen.

Referencing the table, we determine that this particular input screen is scored as Low Complexity. Secondly, the IPFUG provides a secondary table that can tell us how many Function Points to award for this screen and for the Internal File discussed in the first Sample:

What’s next in Part 3

In Part 3, we’ll take a brief look at some samples that will help in the identification of Outputs, Queries and External Files – bringing all 5 types of EP’s into focus for you and ultimately arming you with a very powerful tool to add to your arsenal of estimating tools.

• Read Part One
• Read Part Three

References

1. International Function Point Users Group – www.ifpug.org
2. Function Point Training Guide
3. Function Point Quick Reference Card

^{1 Screenshot generously provided with approval by the wonderful folks at TruQC (www.truqcapp.com)↩}

Learn more

• View Job Openings: Find your home with us
• Goal Setting Techniques That Actually Work: How to create high quality goals to transform you and your organization, GovWebworks