Other Links

Main Page
Function Point Consulting
Software Economics
Training Courses
Online Library
Expert Testimony
Venture Capitalist & IPO's
Software Measurement
Mergers & Acquistions
Benchmark Studies
About David Longstreet
Client List
Site Map
Site Metrics

Using Function Points to help Define When and What to Re-engineer
Using Function Points to Estimate Test Cases
Using Function Points to help Understand Wide Productivity Ranges
Using Function Points to help Understand Scope Creep
Using Function Points to help Calculate the True Cost of Software
Using Function Points to help estimate project cost, schedule and effort
Using Function Points to help Understand Maintenance Costs
Using Function Points to help with Contract Negotiations
Using Function Points to develop a Standard set of Metrics
When not to use function points

Using 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.

1. How do we identify applications to be re-engineered?
2. How do we calculate the potential benefits of the re-engineering effort?

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.

Using Function Points to Estimate Test Cases

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.

Using Function Points to help Understand Wide Productivity Ranges

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.

Using Function Points to help Understand Scope Creep

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.

Using Function Points to help Calculate the True Cost of Software

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.

Using Function Points to help estimate project cost, schedule and effort

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 hours.

Using Function Points to help Understand Maintenance Costs

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.

Using Function Points to help with Contract Negotiations

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.

Using Function Points to develop a Standard set of Metrics

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

Quality Metrics

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.

When Not to Use Function Points

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.

Summary

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.

Tools   Consulting    Full Articles    Training    Contact Us    Clients    Links

For more information:
Knowledge@SoftwareMetrics.Com
Longstreet Consulting Inc.
2207 SW Walnut
Blue Springs, MO 64015
voice: 816.739.4058

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