In the 1970s Allan Albrecht and his colleagues at IBM measured a number of projects using both logical source code statements and function point metrics. These pioneering studies found some interesting but not perfect correlations between source code size and function points for many programming languages. In 1984, SPR began publishing a table of these empirically-derived relationships, termed "backfiring ratios." The table now incorporates over five hundred source code languages and dialects. Use of this data is subject to a number of caveats driven by its derivation and nature. Backfired function point counts are of lower accuracy than normal function point counts. Backfiring is ambiguous if the starting point is physical lines of code, and its accuracy is further compromised in sizing of mixed-language applications. Backfiring ratios vary based on individual programming styles and numerous. The accuracy of this approach is below that of counts by certified personnel, but the speed and ease of generating results continue to make this approach popular, particularly with legacy applications.

This latest (February 2006) version of the table includes a white paper describing our approach, and the table has been enhanced with 100 new languages, low-medium-high ratings, and a composite risk/reliability factor score for each language. In addition, entries rate the impact of Integrated Development Environments (IDEs).

Note: the 2006 edition of this table was published on February 1, 2006. If you purchased the previous version within the past 90 days and would like to upgrade to the new version at no additional charge, please send email to: PLTUpdate@spr.com

by Capers Jones     13 pages    December 2004

For large projects, automated estimates are more successful than manual estimates in terms of accuracy and usefulness. In descending order, the costs of large projects include defect removal, production of paper documents, coding, project management, and dealing with new requirements that appear during the development cycle. In addition, successful estimates for large projects must be adjusted to match specific development processes, to match the experience of the development team, and to match the results of the programming languages and tool sets that are to be utilized. Simple manual estimates cannot encompass all of the adjustments associated with large projects.

by Capers Jones     12 pages     June 2003

Accurate software estimating is too difficult for simple rules of thumb. Yet in spite of the availability of more than 50 commercial software estimating tools, simple rules of thumb remain the most common approach. Rules based on the function point metric are now replacing the older LOC rules.

by Capers Jones     19 pages     January 2003

Software costs for similar projects have been noted to vary widely. There are three significant reasons for such variances: 1) Variations in the work actually performed on the projects; 3) Variations in the work included in project measurements; 3) Variations in compensation rates and overhead costs. Each of these three reasons can introduce variances that approach 100%. Accurate understanding of software engineering economics requires that each of these three factors be quantified and included in economic studies. Without understanding the impact of these three factors, it is not possible to establish productivity averages.

by Capers Jones     16 pages    January 2005

The software industry lacks standard metric and measurement practices. Almost every major software metric has multiple definitions and ambiguous counting rules. Further, there are no standards for dealing with basic topics such as the activities to include in software measurement studies. There are also key topics with no metrics at all, such as quantifying the volume or quality levels of data bases and data warehouses. The result is a lack of solid empirical data on software costs, effort, schedules, quality, and other tangible matters. This report analyzes some of the key software size metrics and the underlying technical problems associated with software measurement.