Are function points more useful than a Swiss Army Knife? I have been accussed on more than one occassion that I believe function points are more useful than a Swiss Army Knife. Perhaps that is an over statement, but there are many uses.
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.
Function Points to help Define When and What to Re-engineer
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 total number of test cases will approximately equal the number
of Function Points raised to the 1.2 power (FP 1.2). Data
gathering and laboratory research indicates that Function Points times
1.2 estimates the number of acceptance test cases. Again
the difference between the two is that FP raised to the 1.2 power estimates
all test cases and FP times 1.2 estimates only acceptance test cases. 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 more complex. The test cases
Capers estimates includes all test cases not just acceptance test cases.
For example, if a development application has 1,000
function points there should be approximately 4,000 total test cases
and 1,200 acceptance 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 or 1,200 acceptance 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 consistent.
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
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,
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 canceled projects.
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 applied.
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 effective
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.
While function points have many uses, Function points are not very good measure when sizing maintenance efforts (fixing problems) or when trying to understand performance issues. Much of the effort associated with fixing problems (production fixes) is due to trying to resolve and understand the problem (detective work). Another inherent problem with measuring maintenance work is that much of maintenance programming is done by one or two individuals. Individual skill sets become a major factor when measuring this type of work. The productivity of individual maintenance programmers can very as much as 1,000 percent.
Performance tuning may or may not have anything to do with functionality. Performance tuning is more a result of trying to understand application throughput and processing time. There are better metrics to utilize when measuring this type of work.
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.
For more information:
or David Longstreet direct at David@SoftwareMetrics.Com
copyright: Longstreet Consulting Inc. 1992 - 2007
Keywords,Software Estimating, Benchmark, QA76, Software industry data, Software Productivity, function points, FPA, IFPUG, Initial Public Offerings, Merger, Acquisitions, Software Measurement,software metrics, CMM, benchmark studies, function point counting, outsourcing metrics, offshore, offshore measurement,venture capital,sizing software, software economics, economics of software, expert testimony, software litigation, IPO, software IPO, benchmark data, training,consulting,software productivity, industry data, productivity data, software estimating, process metrics
Software Estimating Training Class