The Function Points method has been the most popular method of sizing software functionality over the past 30 years or so. It is an established fact that accurate Function Point sizing helps in obtaining good estimates of project effort, duration, cost, and quality. However, in order to size projects accurately using Function Points, it is necessary to get detailed information about the user’s requirements in order to classify them as Data Functions (Internal Logical Files, External Interface Files) or Transaction Functions(External Inputs, External Outputs, and External Queries). These are the essential components for using the Function Points method. It is also necessary to further study these functions in order to identify the attributes (DETs, RETs and FTRs)relevant to each function.

 

The current challenge

Unfortunately, when clients issue Request ForProposal to IT service providers for application development and maintenance work they very rarely have this detailed information available with them. Consequently, the bid pursuit teams of IT service providers only have some high-level requirements available with them in order to estimate the project and prepare a competitive proposal. This leads to a challenging situation where the bid pursuit team is expected to provide accurate estimates with minimal high-level requirements from the client.

Over the past 30 years, various organizations and individuals have created Function Points based models that can be used early in the lifecycle to obtain Rough Order of Magnitude estimates. This article describes some of the more common models available in the industry along with a comparison of their accuracy and confidence with which the accuracy can be achieved. The article assumes that the reader is familiar with the Function Points model. It concludes by providing a set of recommendations on the usage of these models and their applicability.

 

Function Points based Early Lifecycle Sizing Models

Three popular early lifecycle sizing models used to compute Functional Size (unadjusted) are described below:

• Quick FP / FP Lite

This method involves:

> Listing all the Data Functions and Transaction Functions associated with the application

> Assigning‘Average’ complexity to each Data and Transaction Function and computing its FP size

> Summing the FP size of all Data and Transaction Functions to compute the Functional Size of the application

• Estimated FP Count

In this method:

> All the Data Functions and Transaction Functions associated with the application are first listed down

> ‘Low’ complexity is assigned to each Data Function and ‘Average’ complexity is assigned to each Transaction Function and its FP size is computed

> The FP size of all Data and Transaction Functions is summed up to compute the Functional Size of the application

• Indicative FP Count

The following steps are carried out while using this model:

> List all the Data Functions associated with the application

> Classify each Data Function as either ILF or EIF

> Use the following formula to compute the Functional Size

UFP = (35 * Number of ILFs) + (15 * Number of EIFs)

 

Comparison of Function Points based Early Lifecycle Sizing Models

The models described above vary in their ability to estimate Functional Size accurately. In order to compare these models a sample set of 150+ applications was chosen. The above mentioned models were applied to these applications to obtain their size using each model. A comparison of the performance of the various models is given below:

Sr#	Model	Projects with < 20% Variance from Actual Size	Projects with < 30% Variance from Actual Size
1	Quick FP / FP Lite	75%	90%
2	Estimated FP Count	55%	75%
3	Indicative FP Count	16%	28%

 

Observations

It was observed that:

• As expected the performance of the models improved with the level of detail available as input. Thus models such as the Indicative FP Count model that used only one type of functionality as input (either Data or Transaction Functions) did not perform as well as the Quick FP/FP Lite or Estimated FP Count models that used both Data and Transaction Functions as input.
• Amongst these models the Quick FP/FP Lite model performed better than the Estimated FP Count or Indicative FP Count models.
• Predictability of the Indicative FP Count model was not found to be very high despite details such as ILF and EIF classification being available.
• Predictability depends on the ability to identify / anticipate the requirements. Better anticipation of requirements leads to a better choice of estimation model and consequently higher predictability.

 

Recommendations

• When high-level requirements are available it is recommended that a domain expert be involved in the estimation exercise to anticipate and expand the requirements to the desired level of detail.
• Apply the relevant models described above depending on the level of detail available
• Use the above models as thumb-rules to quickly and effectively validate FP counts during estimation review.

 

References

> “Function Point Lite™ – Is It a Statistically Valid Method of Counting?” By David Herron

> “Function point analysis using NESMA: simplifying the sizing without simplifying the size” By P. Morrow, F.G. Wilkie, I.R. McChesney