From the preface:
The software industry is one of the most successful industries in history and has created numerous billionaires and millionaires as well as given employment to millions of technology workers.
Most forms of modern transportation such as automobiles, aircraft, trucks, and trains are heavily dependent on computers for many technical functions. We have all seen the news of driverless automobiles, which may be the wave of the future. All large aircraft have computerized autopilot systems and most have computerized basic controls. Some modern military aircraft cannot even fly without computer controls because normal human reaction times are not fast enough.
Yet for all the benefits that software and computers have provided, software remains a troubling technology. Software cost and schedule overruns are endemic and occur for over 50% of software projects larger than 1,000 function points or 50,000 lines of source code. Canceled projects above 10,000 function points amount to about 35% of all projects and waste millions of dollars annually. Of the large systems that are not canceled, over 70% run late, exceed their budgets, and have marginal-to-poor quality.
Among the reasons for these software problems is a chronic lack of reliable quantified data. This book will provide quantified data from many countries and many industries based on about 26,000 projects developed using a variety of methodologies and team experience levels. The data has been gathered between 1970 and 2017, so interesting historical trends are available. The book also examines a variety of software types and sizes. For example, there are big differences in software productivity and quality between Web applications, embedded software, information technology applications, open-source software, commercial software applications, and defense software.
Very few companies or government agencies actually know their software productivity and quality results for completed projects. Even fewer companies can estimate software quality, productivity, and schedules with reasonable accuracy before software projects start because the project managers keep using optimistic manual estimates instead of accurate parametric estimates. It is professionally embarrassing that so many companies and government groups have so little accurate quantified data available.
Software Metric and Measurement Changes
- Stop using bad metrics such as LOC and cost per defect.
- Stop using ambiguous metrics such as technical debt, story points, and use case points.
- Revise the SNAP metric so it becomes additive and equivalent to function point metrics.
- Provide conversion rules among all forms of function points (IFPUG, COSMIC, etc.).
- Adopt function point metrics for both software cost estimates and software benchmarks.
- Use work hours per function point for productivity as a standard metric.
- Adjust function points for month for national and local work hour patterns.
- Increase the number of governments that mandate function points to >100 countries.
- Use defect potentials with function points for quantifying software bugs.
- Use DRE for all software projects.
- Stop using single points of data or phases for software benchmarks.
- Adopt the concept of activity-based costs for all software benchmarks.
- Measure software requirements creep for all projects >100 function points.
- Improve function point sizing speed to <15 min per project.
- Use formal parametric estimates for all software >100 function points in size.
