Estimating Function Point Size

You don't have to do a function point count to estimate the functional size of a project. The following explains how functional size can be estimated using the known relationships between the functional component types of a project.

Early Prediction of Functional Size from a Logical Data Model

In the very early phases of a software development project it is not practical or even possible to know in detail all of the items which make up all of the FP components. However, it is often possible to detail one of the components with a fair degree of certainty - such as the Internal Logical Files or External Inputs. You can use the number of Logical Files or the number of Inputs as the base for estimating size. Outputs, Queries and Interface Files are too variable to use early in the lifecycle.

It is likely that the functional component that you will have the most knowledge of is the Internal Logical Files. These closely resemble a count of the entities in a logical data model, modeled to second normal form. Even in the early phase of a project, (eg. the Feasibility Study), it is often possible and very useful, to work with the client to develop a logical data model of the proposed application, as a means of assisting the client to define the requirements. When completed, this model can then be used to provide the starting point to establish the number of Internal Logical Files as part of the function point count.

The relative contribution of each functional component type to the total count is depicted in the following pie chart.

 

The knowledge of these relationships has offered a number of immediate valuable uses for the practitioner, one of which is the ability to predict the functional size of a new development project, or an implemented application, when any one of these components is known with any degree of certainty. However, the above relationships have only been found to be relevant to software which operates as a 'self-contained' system; i.e. a cohesive set of functionality which is loosely coupled with other applications.
For these reasons it is not advisable to use the following early prediction sizing techniques to predict the size of any enhancement project which has a mix of added, changed and deleted functionality scattered over several functional areas within an application.
Here is an example of how to use these known relationships to estimate the functional size of a project:

Example:

If the customer has identified a need and, on developing a logical data model to reflect that need, there are found to be 40 logical tables, it may be reasonably assumed that these relate to approximately 40 Internal Logical Files.

Analysis of the ISBSG Repository also shows that most Internal Logical Files in applications are rated as being 'low' to 'medium' in complexity. The mean score attributed to them across all projects is ~9 function points.

Based upon the above, it can be assumed that the total score for the Internal Logical Files component of the function point count will be:
40 (ILFs) x 9 (mean score for Internal Logical Files)= 360 FPs

From the above pie chart it can be seen that the Internal Logical Files component of the function point count is typically around 25%. On this basis the total function point count for the required application is predicted to be around:
360 FPs x 4 = 1,440 FPs

Warning: whether the above quick predictive technique is used, (or a detailed function point count is performed), to establish size as input into obtaining an early cost indicator for the project, a contingency of 20% to 30% should be added to allow for functionality not apparent early in the life cycle. Historical data indicates that this scope creep typically occurs as a result of additional functionality being identified as user requirements evolve in subsequent development phases.

Note: The techniques discussed above are only valid if your application or development project is loosely coupled from other applications and fits the profile of projects currently in the ISBSG Development & Enhancement Repository. Only a few projects within the Repository are from the domains of real-time, control, scientific or embedded software and early research indicates that the above relationships may not hold for these types of software. You can establish the project profile by referring to The Benchmark book, the Web Site (www.isbsg.org.au) or the repository demographics included on the Estimating, Benchmarking & Research Suite

The Rule of the "Thirties"

Various organisations have come up with a rule of thumb of one logical file equaling "thirty something" unadjusted function points of total project size for a development project. You can use this for a rough size estimate. Their range is between 31 to 35.
This roughly lines up with our example: 40 x 35 = 1,400FP project size