Fifteen percent of all bugs found in software are still being delivered to customers—and that’s simply not acceptable, according to Capers Jones, a leading expert on software quality.
“The software industry is not at all good with quality, and what’s surprising is that there are methods available, and have been available for more than 35 years, that can make software much, much better than it’s ever been,” he said.
Jones is the author of several seminal development books, including “Programming Productivity” and “Estimating Software Costs.” He is also known as a leading advocate for Function Points, a method of estimating the complexity (and cost) of large software projects.
Inspections and static code analysis are among the techniques that can be used to make software code quality better, in Jones’ opinion.
“Testing is the most expensive part of the development process, and these things [inspections and static code analysis] don’t even cost that much and can speed up development and shorten test cycles,” he said, adding that this could lower technical debt, and save companies on development and testing in general.
“Even if you do all the tests in the testing phase, you’re not likely to go above 90% [defect free], because testing alone isn’t efficient enough,” Jones said.
He believes that static code analysis and inspections of individual lines of code should be done before the testing phase in order to allow testing to catch the remaining bugs and provide a secure, stable product for customers.
“If you do up-front inspections and if you use static analysis before testing begins, your schedule will be shrunk by at least 50% and your software quality will be above 95%,” Jones said.
Jones said that design of experiments—a methodology which generates a smaller number of test cases based on a mathematical technique but finds more bugs—in conjunction with Team Software Process, is the most effective method for fairly large software projects, such as something involving the code used to run an aircraft.
Watts Humphrey, a software engineer, came up with the Team Software Process, which provides a framework for organization of large projects, specifically for developers and managers. This process has been in the public domain for a long time, according to Jones. He felt that agile development is not used by many teams developing large systems with stringent quality controls, although some thought leaders in that space may, and in fact do, disagree.
“If you’re going to do serious software, where lives are at stake, Team Software Process works best,” Jones said.
Inspections, he said, have not taken hold in many organizations because there aren’t really specific tools for it; it is a manual process, much like editing. Inspection teams are made up of an inspector, the developer whose code is being inspected, a recorder, and a moderator. While there are some tools to automatically inspect documents, code inspection must be done by hand, and the measured efficiency of finding software bug defects is about 85%.
“Any new kind of invention is not likely to be accepted by everyone at the same time, even if it’s a good invention,” Jones said, adding that static analysis has begun to take hold because many of the tools are open source and available at little to no cost.
Static code analysis has not yet reached its peak of acceptance, according to Jones. This can be attributed, he said, to people not understanding the economics of quality.
“If you are careless, your schedule will run late and your costs will be high because your schedule runs late,” he said, equating the theory of how to create secure code to the theory of how to stay healthy. He said you can tell people to eat healthy, but it is more that they have to do it and understand why they are doing it, instead of just following recommendations.
What is Team Software Process?
Team Software Process was created in 1996 by Watts Humphrey as an “operational process to help engineers consistently do quality work,” according to his report, “The Team Software Process.”
The model for TSP builds on Personal Software Process (a way to organize and enhance individual development processes) in order to create integrated process teams. TSP is designed to work with teams of two to 20 people, and then a larger, multi-team process designed to work with up to 150 people.
PSP is a skill-building operational process that provides directions for creating personal plans, planning methods and quality measurements, among other things. Then, engineering disciplines are introduced as individuals practicing PSP move into the TSP phase, which provides guidelines for commitment, aggressive planning, project goals and team roles. This discipline also fosters management disciplines, and then all three of these groups are merged into product team environments, which are designed to promote self-organization and stronger code development.
