function points more useful than a Swiss Army Knife? This
article outlines the many uses of function points. Perhaps function points
are not as useful as a Swiss army knife, but there are many uses.
Many re-engineering projects are undertaken without any cost benefit
analysis being done. Cost benefit analysis seeks the best ratio of benefits to cost; this
means for example, finding the applications that will benefit the most from re-engineering
efforts. To determine what applications will benefit the most from re-engineering two
questions should be asked.
Identifying applications to re-engineer
Once an organization has completed a baseline (established the number of function points) of all production applications, maintenance hours per function point can be calculated for each application. Maintenance hours per function point can be plotted on a chart similar to the one shown below. Along the x axis is size (as measured in function points) and up the y axis is maintenance hours per function point. The dots represent each individual application.
In the upper right hand corner are those applications that are both
large and are expensive to maintain per function point. These are the applications that
should be targeted for re-engineering projects. That is, these applications will provide
the biggest 'bang for the buck'. Once re-engineering has taken place, the application's
Maintenance Hours / Function Point should be reevaluated, and the chart recreated.
Maintenance hours per function point of those applications that were re-engineered should
have dropped and these applications should fall into the bottom right hand quadrant.
Estimating benefits (calculating pay back)
There are only a few pieces of information needed to estimate the
benefits of a re-engineering project. These include the current maintenance hours per
function point, the expected maintenance hour per function point after the re-engineering
project, and the desired pay back period. For example, an application has 1,000 function
points and maintenance hours per function point is 10 hours. The desired, to drop into the
lower right quadrant, maintenance hours per function points is 8 hours. That is, the
re-engineering project should reduce maintenance cost per hour by 2 hours per function
point. If the desired pay back period is one year then the re-engineering project should
not take any more than 2,000 hours to complete. Simple put, 2,000 hours is the difference
between the old and new maintenance hours per function point (2 in this case) multiplied
by the number of function points (1,000 in this case).
The same analysis done above can be performed to compare enhancement
costs to development costs. It is a truism that enhancement dollars per function point
should be less than development dollars per function point. If development dollars per
function point are less than enhancement dollars per function point, then it is cheaper to
develop a new application than to enhance the current application.
Many attempts have been made to establish a relationship between
function points and the effort associated with software development. Much of the
difficulty in establishing this relationship is due to the fact that only the relationship
between function points and the entire software lifecycle is examined. This section
examines the relationship between function points and testing -- in particular the
relationship between test cases and function points.
The relationship between function points and the number of test
cases is very strong. Capers Jones estimates that the number of test cases will
approximately equal the number of Function Points raised to the 1.2 power (FP 1.2).
That is, test cases grow at a faster rate than function points. This is intuitive because
as an application grows the number of interrelationships within the applications becomes
For example, if a development application has 1,000 function points
there should be approximately 4,000 test cases. Obviously, the development team should
begin creating test cases as soon as possible. If the development team waits until coding
has been completed, they will more than likely create far fewer than 4,000 test cases.
Understanding Defects Potential
The number of defects are related to the number of possible
outcomes. The number of possible outcomes are related to the number of test cases. There
is great benefit in estimating the number of test cases. Understanding the number of test
cases leads to the logical analysis of comparing actual test cases with expected test
cases. If actual test cases falls short of expected test cases, then there is inadequate
test coverage. Testing coverage is a direct indication of potential defects and future
maintenance costs. The larger the gap between expected test cases and actual test cases,
the greater the potential of defects not being detected during testing.
The following is a basic principle of software quality: The only way
to production software will improve is if and only if all software migrated to production
is of a higher quality than the software that exists in production currently. It is
important to understand both defect potentials of production software and defect
potentials of new software. It may be impossible to estimate the number of defects
embedded in current production software, but defect potential for each release of software
can be estimated. The gap between expected test cases and actual test cases is a good
indicator of potential defects.
Inconsistent productivity rates between projects may be an
indication that a standard process is not being followed. Productivity is defined as the
ratio of inputs / outputs. For software, productivity is defined as the amount of effort
required to deliver a given set of functionality (as measured in function points).
Many organizations suffer from productivity rates being plus or
minus 100 percent. This is true even when they have counted function points correctly and
captured time consistently. Organizations often complain that productivity analysis
provides no value. In most organizations software is created in many different ways, using
many different processes (and in many cases, no process at all). If software is developed
inconsistently, then productivity rates will also be inconsistent. The same can be true of
any production process. Large swings in productivity rates between projects is an
indication that a standard process is not being followed. As development teams conform to
a standard development process, the productivity ranges should stabilize and become more
Function Point Analysis provides a mechanism to track and monitor
scope creep. Function Point Counts at the end of requirements, analysis, design, and
implementation can be compared. The function point count at the end of requirements and/or
design can be compared to function points actually delivered. If the number of function
points has increased, it can be assumed that either the project has become better defined
or the project has actually grown in size. The amount of growth is an indication of how
well requirements were gathered by and/or communicated to the project team. Growth of all
projects should be tracked. If the amount of growth of projects declines over time it is a
natural assumption that communication with the user has improved.
Most organizations greatly understate the cost of software. The true
cost of software is the sum of all costs for the life of the project including all
expected enhancement and maintenance costs. In fact, the real calculation would be the
present value of all expected development, enhancement, and maintenance costs for the life
of the project. This type of analysis demonstrates the reward of investing in good 'up
front' design and analysis. The more that is invested in 'up front' design, the more that
will be saved in reduced maintenance and enhancement costs. It is important to be able to
have a unit cost to evaluate initial investment and compare this to future expenditures.
The unit cost can be hours/FP or $/FP. Increases in the initial investment should reduce
per unit cost for future enhancement and maintenance activities.
Successful estimating using function points is based upon several
estimating techniques: Top-Down, Analogy, and Expert Advice. Top-down estimating is an
estimating technique that estimates the entire schedule, cost and effort using broad
parameters. The broad parameters and comparisons are based upon historical benchmark data
using Analogy estimating techniques. Expert advice can be gathered from experts with like
project experience or experience using function points.
Comparing projects with like projects is critical to successful
estimating. When evaluating like projects the following should be considered:
Type of Hardware Platform - Mainframe, Client Server, Stand Alone PC
Type of Language - COBOL, C, C++
Type of Project - System Software, Middleware, Application Software
Type of Operating System - MVS, Windows, Unix
Once like projects have been determined gather the following data
Historical Delivery Rate (hours per function point) of like projects
Historical Schedules (schedule duration per function point) of like projects
Historical Cost (dollars per function point) of like projects
Once project size has been determined in function points, the estimates of hours, cost and schedule can be computed. The computations should be done with data from like projects as identified above.
For example, if you determine the size of the current project is 500
function points and the delivery rate for a like or similar project was $10 per function
point, then the expected total cost for the project would be $10 ($/Function Point) x 500
FP's = $5,000 dollars. Similar calculations could be made for schedules, duration, and
Many maintenance budgets are established based on prior years
performance. Many organizations attempt to reduce maintenance cost and do not plan on
increasing maintenance cost from year to year for any particular application. If the
amount of new functionality is tracked and added to the base product the unit maintenance
cost may actual fall while actual maintenance expenditures remain constant or increase. If
maintenance cost are increasing at a rate less than function point growth maintenance
costs are actually falling. For example, if an organization spends $100,000 to maintain
10,000 function points or $10 per function point, but the number of function points grow
10 percent to 11,000 and maintenance dollars remain constant, then maintenance costs per
function point falls to $9. Many IS executives fail to understand and grasp this concept.
Contract managers can use their knowledge of function points to
construct and manage projects based on the price per function point, as well as comparing
vendor pricing. These individuals establish cost effective use of third parties in
development, validate bids based on function point size, and can evaluate the impact of
Function points can be used to help specify key deliverables to a
vendor, to ensure appropriate levels of functionality will be delivered, and to develop
objective measures of cost effectiveness and quality. They are most effectively used with
fixed price contracts as a means of specifying exactly what will be delivered. From an
internal perspective, successful management of fixed price contracts depends absolutely on
accurate representations of effort. Estimation of this effort (across the entire life
cycle) can occur only when a normalized metric such as provided by function points is
In short, function point analysis provides the best objective method
for sizing software projects, and for managing the size of a software project during
development. It is the best method for managing risk on two counts. First, the client
(user/specifier) can more readily accept the risk for a given size of software project (in
function points). Second, the developer can more readily accept the risk for the cost of
production (the cost per function point). Adhering to a consistent means of function point
counting optimizes this relationship and facilitates on-time, on-budget development.
Pricing "external software" (i.e., designed for use
outside the organization) can be tied more directly into production efforts when
functional metrics are required. If a software developer knows exactly what their internal
cost is to develop a function point, they can easily incorporate it into the costing
algorithms used to set external prices. Without a clear understanding of time and effort
per function point, pricing software packages will continue to be difficult.
Of course, function points need to be collected in association with
the other measures. In fact, function points by themselves provide little or no benefit.
Many metrics need to be reported at the organizational level. For example, both
productivity/cost metrics and quality metrics need to be reported at the organizational
level. Productivity/Cost metrics are used to demonstrate the rate and cost of
functionality that is being delivered. Quality metrics are used to demonstrate existing
levels of quality and to track continuous improvement efforts in the software development
process. These metrics should be tracked and trended.
Productivity / Cost Metrics
1. Cost per Function Point: measures the average cost to deliver or maintain a function point. This data can be used to develop a historical database that can be used to estimate future projects.
2. Function Points per Calendar Month or Year: measures the average amount of time taken to deliver a function point to production with given staffing levels
3. Function Points per Staff Month: measures the
average number of function points delivered for applied month of effort
1. Defects per Installed Function Points: correlates the quality of the software to the size of the application
2. Maintenance Hours per Installed Function Points: correlates support effort to application size for currently installed software and legacy systems. Applications with high ratios may be targets for re-engineering or replacement.
3. Defects per New Installed Function Points:
evaluates the quality of new software to ensure improvements in the delivery process are
Metrics should be indicators of performance, not exact measures of
performance. They should provide enough granularity to show general trends, identify
problem areas, and demonstrate progress. If trying to make metrics perfect causes them to
be reported two to three months after they are taken, then too much time is being spent on
precision and not enough on action. Avoid making metrics too precise.
This article began by asking the question, "Are Function Points Useful?" There are many uses of function points beyond estimating schedule, effort and cost. Many project managers do not believe that function points provide any use whatsoever. In a way, they are correct. Many organizations just using function points and software metrics to report organizational level trends. Many project teams report data to a central metrics group and never see the data again. It is analogous to reporting data into a black hole. If project managers begin to understand how function points can be used to estimate test cases, calculate maintenance costs, so on and so forth, they will be more likely to invest in counting function points.
To see other full articles click here
Copy and reproduction of this article is permitted if and only if copyright notice appears.