Software design has long been more of an art than a technology. As an art, software-design quality depends heavily on the designer's talent, skill, and inspiration. However, today's system needs cannot afford to depend on artistic talents. Turning software design from an art into a technology may require your company to revamp its entire software-development process.

As software's reputation among end users indicates, there has always been concern about software's quality. Many people consider the term "software quality" to be an oxymoron. Software has even earned its own variation of Murphy's Law, called Weinberg's Second Law: If builders made buildings the way programmers create software, the first woodpecker would destroy civilization. A more serious indicator of public concern is the attention that software quality has received in the popular media (Ref 1).

As software becomes an increasing part of system operation, the electronics industry is also focusing on software quality. Software quality has an increasing economic impact on developers. As software-development projects become larger, the likelihood of cost overruns increases. For example, surveys from software-project-management-consulting-company Software Productivity Research (SPR) show that a project involving 100,000 lines of C code typically takes twice the planned effort. Maintenance costs on poor software can run from two to 10 times the initial development cost.

Many companies incorporate some form of software-quality control. If your company sells to Europe, for example, the organization needs ISO-9000 certification, including certification of its software-development practices (Ref 2). Although the ISO-9000 does not require specific methods, the standard necessitates that your company document its methods. That step may be impossible for more than 75% of US companies because they have no method.

According to SPR surveys, from 75 to 85% of software companies use ad hoc or random approaches to software development. These companies fall into the initial, or Level 1, category of the Software Engineering Institute's Capability Maturity Model (CMM) (see box, "Measuring your software development's maturity"). Another 10% of companies achieved repeatable, or Level 2, results. Only a handful of companies actually managed well-defined software development.

The low ranking of most companies doesn't mean that they are trying to produce poor-quality software. Many manufacturers have development standards, such as module-size limits and the use of structured programming, that they hope can engender quality. Companies use tools such as diagrammatic programming to ensure more accurate designs (Ref 3). But, tools and programming standards have not proven to be guarantors of quality (Ref 4).

Most Level 1 software-development efforts concentrate on generating, debugging, and maintaining code. Errors made in the overall design or design specifications don't show until system-integration tests begin. Then, the design team makes patches to the initial code to correct the problems rather than recoding. The equivalent in hardware engineering would be a company's using its prototype pc board for final production rather than laying out a new board from a corrected schematic. The production product ends up with many cut traces and blue-wire jumpers.

The industry's emphasis on debugging and maintaining code has resulted in great efficiency at detecting and removing coding errors. The industry can boast a 95% code-defect-removal rate (Ref 5). However, if there is a mistake in the overall design, the debugged code may be correctly executing the wrong function. Table 1 shows the origins of software errors in an average program. Coding errors comprise only one-third of all software errors that enter final test and only 12% of the errors in production software. The remaining errors come from other steps in the development process, such as defining initial specifications.

The Shlaer-Mellor Method The Shlaer-Mellor method for software development is an example of an advanced development process that is gaining commercial support. You begin by breaking the project into domains that a team can independently analyze as a single unit (Fig A). If a domain is too large for analysis, you break it into independent subsystems. Next, you analyze the domains, starting with the application domain, which describes what the system is supposed to accomplish. You analyze domains by first creating an information model describing the system's elements and the relationships among them (Fig B). You build state models that describe the behavior of each system element from the information model. Then, you create an action-flow diagram that describes the processing required in each state model. At no time does the analysis specify how the system performs its processing. The analysis only details the data, steps, and timing that the application needs. Application-domain analysis results in a model that completely describes the application's behavior. You can simulate the application using this model and check that your analysis is correct. By evaluating the simulation's outcome against the expected results, you can verify that the application will perform properly. Analysis of the application domain places requirements and constraints on the next domain for analysis, the service domain. The service domain describes all the functions or services that the software must provide to execute the processing models. Analysis proceeds as in the application domain and yields a set of requirements on a lower level service domain. Ultimately, the analysis process yields a service domain, such as an operating system, that is already implemented and provides the required capabilities. With the application and service analysis complete, you can begin examining the software architecture. The service analysis yields requirements on the types and amounts of data that the system must handle and the events and timing that affect data handling. Then, in light of these requirements, the architecture analysis examines issues such as languages, platforms, and operating systems; data organization and flow control; and synchronization. The architecture analysis produces descriptions of mechanisms, which are functional capabilities the programmer must provide. The analysis also describes structures that provide rules for implementing the service processes in code. The final step in the Shlaer-Mellor Method is to translate the process models into code following the guidelines set by the architecture's structures. In many cases, tools can automate this step.

This diversity of error sources implies that, to be effective, any attempt to upgrade software quality must involve the entire development process. The development process should use methods that prevent, as well as remove, defects. One such method is the formal peer (not management) review of specifications, designs, and code. The review process typically provides about a 60% defect removal. In addition, all designers at the review can learn from the errors found and avoid making similar mistakes.

Another method to include in a software-quality upgrade is measurement and tracking of software-quality attributes throughout the design process. As Fig 1 shows, such attributes can include quality metrics such as design complexity, test coverage, and measures of the team's design efficiency. You cannot hope to recognize where the problems or improvements occur without using a few of these measurements. For the use of metrics to be effective, you must understand your development process. Otherwise, you won't know where to find the problems that the metrics indicate.

Although peer reviews and the use of metrics effectively improve software quality, they may not be enough if your design requirements change during the project. Typical design approaches first evaluate the application, make decisions about architecture and design methods, and then focus on the design's implementation. As requirements change, the design team adapts the implementation rather than re-examining the methods or architecture. The resulting code is choppy and difficult to maintain. The project becomes dependent on "gurus" who know the details of the entire project.

Such methods fail when project complexity becomes too great for a single person to apprehend and quality suffers. Even if you divide the project into independent, manageable sections, the code quality becomes erratic. The situation is similar to building a road by assigning a different engineer and construction team to each mile. You could end up with a four-lane highway alternating with sections of dirt and gravel road.

Because traditional methods fail on large and variable projects, companies are increasingly turning to object-oriented-analysis design practices that separate architectural and implementation decisions from the application design. By separating the project into such independent domains, the design team can create and debug the application design before committing the design to coding.

At least one such object-oriented-analysis project approach, the Shlaer-Mellor Method, has reached the market with support from a variety of commercial tool vendors. (See box, "The Shlaer-Mellor Method.") Cadre Technologies, Objective Spectrum, and Scientific and Engineering Software offer tools that support the method. The offerings range from graphical tools that assist analysis to tools that provide automatic translation of models into code. Project Technology Inc provides training and project-management tools for the method.

You can adopt the strict formalism of object-oriented-analysis or aspire to a more traditional, but managed, development process. In either case, the effort to establish a quality software program is probably more than you can muster at the departmental level. To be successful, the effort must be part of a corporate commitment to software quality. The effort requires a combination of tools, training, and changes in management practices as well as substantial time and cash investments. Estimates from SPR indicate that for an organization to go from a Level 1 company to a world-class software vendor takes three years of hard work. The estimated cost of such a move is more than $30,000 per software-staff member for tools and training.

Such investments, however, pay off fairly quickly. Operating-system provider Microware Systems Corp took two years to build its quality program and attain ISO-9000 certification. Product development now takes less effort, and the company spends less time in maintenance. The improved development efficiency and resource shift from maintenance to development has greatly increased Microware's ability to develop and sell new products. Raytheon's equipment division also invested more than $1 million in improved software quality. Since 1988, the company has seen a return of $7.80 in reduced rework costs for every dollar spent upgrading its methods.

Quality efforts also result in individual payoffs. You get to spend more time designing new products and less time fixing old ones. You also get to hold your head a trifle higher because people no longer laugh when you say "software quality."

1. Gibbs, W Wayt, "Software's Chronic Crisis," Scientific American, Sept, 1994, pg 86

2. Brow, Ike, "The Softer Side of ISO 9000," EDN Products Edition, Nov 21, 1994, pg 19.

3. Small, Charles H, "Diagrammatic Programming," EDN, Jan 6, 1994, pg 60.

4. Roche, John, Mike Jackson, and Martin Shepperd, "Software Measurement Methods: An Evaluation and Perspective," Proceedings of Third Symposium of Assessment of Quality Software-Development Tools, 1994, IEEE Computer Society Press, Los Alamitos, CA, pg 69 (footnote).

5. Jones, Capers, Global Software Quality in 1995, Software Productivity Research, Burlington, MA.

6. Capability Maturity Model for Software, Version 1.1, Technical Report CMU/SEI-93-TR-24, Feb 1993, Carnegie-Mellon University/Software Engineering Institute.