At Total Metrics, we are promoters of function point analysis. Function points are commonly used when estimating, scope managing, and benchmarking software projects. In the abstract, it can be hard to appreciate the benefits of a function-point based approach, so we give examples of how the approach can be used.
What are function points?
A function point count is a measurement of the amount of functionality that software will provide. Function points help us understand software like kilometres help us understand the real world. Everything else being equal, delivering 15 function points of functionality will take longer than delivering 10 function points of functionality. Just like walking 15 kilometres takes longer than walking 10 kilometers.
Software project cost estimation - an example
Function point analysis is commonly used when estimating a project's cost. Please keep in mind that the method we give is suitable for a small low-risk project. A high-risk project justifies a considerably more thorough approach.
Imagine our customer wants to build an application for managing their store. They've refined the requirements for a system called CCAS.
An IFPUG function point count of CCAS is performed. The system is 173 function points.
The simplest way to generate an estimate is to combine the function point count with the productivity, that is the time or cost per function point, for similar projects. One such source of project data is the ISBSG dataset. We filter the ISBSG dataset for projects that:
- have a high quality rating
- are new development projects
- are developed for Microsoft Windows
- have IFPUG functional sizes
- are straightforward business systems.
The average productivity, in time per function point, for the projects in the sample is about 8 hours per function point. Multiplying the productivity by the size gives a project effort estimate of 1,384 hours.
With any estimate it is important to understand what effort is included. The ISBSG data we used captured productivity at Level 1. This productivity includes the development effort for the system, but it excludes lots of things. It excludes end-user's effort (the time to train the end-users of the system), and it excludes data conversion (the effort to load data from the current system into the new system).
The productivity does include the effort to build the requirements, which have already been finalised. So the effort estimate needs to be reduced to allow for the completed work. Requirements analysis typically comprised about 10% of similar projects' effort; so the effort estimate is corrected to 1,245 hours. Using a cost of $55 per hour gives an estimated project cost of $70,000.
This example gives a simple industry-based estimation, it is a useful estimation because it is easy to understand. A more sophisticated estimate would consider the uncertainty in each input, particularly the function point count, productivity, and cost per hour, to produce a range of likely costs.
More advanced estimation tools, like SEER for software, also help you understand the factors that impact the project's cost. Such tools have features to help you answer questions, for instance, what is the cheapest way to complete this project in 3 months? Is it to add staff, use more experienced staff, change the development methodology, or to use another programming environment?
Product scope management - an example
Change is inevitable during a project. Scope management controls which tasks are inside and outside of the project's scope. Each change to scope will alter the project's effort, cost and schedule. There may be disagreement about what a fair price is for these changes. Applying an objective function-point based methodology to managing scope provides an objective basis for negotiating the cost of modifications.
Reduced product scope
Continuing the example of the CCAS, imagine that we have signed a contract with a vendor to develop the system for $55,000, but have just decided to reduce the scope of the project by removing the accounting functions from the CCAS. We need to negotiate with the vendor to agree a fair price for the modified project.
Determining the function point count of the updated system is straightforward, perhaps ten minutes work. We just need to remove the accounting functions from the function point count. With the account functions removed, the system is now 131 function points. As a basis for agreeing a fair price, we use the $320 cost per function point that we have agreed with the vendor. So we propose an amended price for the CCAS system of $42,000.
Increased product scope
A function point based approach works equally well for extra features added to scope during the project. Imagine that the business now requires sales commission tracking functions. Again a function point analysis is performed, and 38 function points of functionality are identified. The function point analysis gives us an objective basis for determining a fair price. In this case, $12,000 is a fair starting price for negotiation.
We have shown a straight-forward and objective approach to negotiating with vendors about what is a fair price for changes in product scope during a project.
Benchmarking - an example
Benchmarking compares the cost-effectiveness of a software development organisation to its peers. Effectively, it's an industry-based estimation performed for the projects that an organisation has completed compared to the actual delivery cost.
Continuing again with the example of the CCAS. Crudely, if our development organisation charged us $55,000 for the CCAS system, which had an industry-based estimated of $70,000, they have above average productivity. If they charged us $95,000, they have below average productivity.