New metrics needed for new generation: lines of code, function points won't do at the dawn of the graphical, object era - computer-aided software engineering: includes related article on Windows test tools and a glossary on metrics for object oriented design - Buyers Guide

Software Magazine, May, 1992 by Jessica Keyes

"For quality programs to be successful, you have to get scared enough to act. The manufacturing industry did this in the '80s. The '90s are the decade of fear in the IT world," said Bill Smillie, a partner in the Technology and Finance Unit of the federal practice of Coopers & Lybrand, located in Washington, D.C.

Along with increasing pressure to deliver better quality products in shorter time frames and for less money, information systems (IS) organizations must also navigate the uncharted waters of client/server architectures and object technology. These new paradigms of development are impacting quality improvement and measurement methodologies, as well as productivity.

"We've introduced new tools that are more complex, but demand for systems has gone up so greatly that it gives the appearance that our productivity has gone down," said Elliot Chikofsky, development director of 4GL application development environments at Progress Software Corp., Bedford, Mass. "In essence, our productivity is masked by complexity and demand for new systems," said Chikofsky, who is also associate editor-in-chief of IEEE Software magazine.

The old way of measuring development, "code or die," does not fit in with the new method for improving quality, called Total Quality Management (TQM). Measuring development by the lines of code written focuses on the product, whereas TQM focuses on the process, said Coopers & Lybrand's Smillie.

With the "code or die" syndrome, he said, "the greater the deadline pressures, the more we focus on 'I've got to code right now.' This is a quality problem because we fundamentally have no faith in the process. TQM says if you want to improve the quality of the product, you focus on improving the process."

TQM is a process by which one manages continuous improvement. "You need to learn the lessons in as close to real time as possible, and implement lessons learned across the organization," said Smillie.

To date, IS has not learned many of these quality lessons, according to Dr. Jerry Grochow, a vice president at American Management Systems, Alexandria, Va. Grochow, a vice president tracked quality for many years, believes that little progress has been made. Although there is a lot of noise about quality programs. Grochow said, "It's a little hard to tell at this time how may of these quality programs are actually bearing fruit."

The application of quality programs to IS organizations is limited to the early adopters today. "Less than 5% of IS organizations are doing this sort of thing," said Vaughan Merlyn, a partner at the Ernst & Young Center for Information Technology, Boston, Mass. Vaughan is a well-known proponent of the application of TQM to the IS industry. Even though TQM is strongly rooted in many industries as a whole, "IS tends to be a black hole," he said.

According to Merlyn, an organization starts the quality improvement process by understanding a single principle: Change is painful and lengthy. In fact, he said, "To effectuate any kind of change, you need something like a 10-year plan."

Ten years is a long time and management's patience is short. So how can you motivate change over that time period?

PUSHING FOR CHANGE

Techniques to introduce TQM programs into IS vary. The secret, according to Merlyn, is to make management dissatisfied with the status quo. (See box, page 44.)

Dissatisfaction will surface when management realizes the cost of the status quo. For example, Merlyn said, one can examine the cost of poor quality by asking certain questions. These include, "What are we spending to detect defects?" and "What are we spending to repair defects?" Armed with the answers to these questions, the IS organization can begin to accumulate the statistics it needs to push for change.

This data is not hard to track, he said. In most cases, it is already available through project management systems that track walk-throughs, reviews, defect rates and the like. Merlyn said that with 40% to 50% of the IS budget spent on fixing defects caused by poor quality, it should be rather easy to "motivate massive change."

Coopers & Lybrand also has a methodology for bringing TQM to IS organizations. "[It] provides a framework for managing continuous improvement for software delivery," said the firm's Smillie.

To combat behaviors such as the "code or die" syndrome that seem to sabotage the drive toward quality, Coopers & Lybrand modified their four-phase TQM methodology--assessment, planning, process improvement and integration--to suit the tenets of software engineering.

The centerpiece of the assessment phase is to develop metrics to assess the quality baseline, and to measure improvements over time. "We do not have a list of a half-dozen metrics. The choice of metrics depends upon the client. The reason is that quality is different things for different people," said Smillie. "What you think are key quality issues should drive what you're trying to measure."

To determine the appropriate metrics for a particular client, Coopers & Lybrand consultants utilize a method developed by the National Aeronautics and Space Administration (Nasa) which is now in the public domain. Called goal-question-metric (GQM), it is a disciplined technique used to refine individual components of key quality issues, and ultimately the metrics that might be derived from them.