Kaoru Ishikawa

To explain the quality “miracle” in Japan, Kaoru Ishikawa offers six features of quality work there [6]:

• _{Company-wide quality control;}

• _{Top management quality control audit;} • _{Industrial education and training;} • _{Quality Circles activities;}

• _{Application of statistical methods;}

• _{Nationwide quality control promotion activities.}

Company-wide quality control means that all departments and all levels of per- sonnel are engaged in systematic work guided by written quality policies from upper management. The consequences of this point to software quality are that the software developers are committed to producing a quality product and are guided by software development management (upper management) trying to achieve the same objective. This is how to build quality into the software product.

Ishikawa recommends that a quality control audit team of executives visits each department to uncover and eliminate any obstacles to the productivity and quality goals. This recommendation comes from the belief that the executives are in a posi- tion to make corrective action happen quickly and thoroughly. Normally this audit- ing of software is placed in the hands of the software quality experts, but with the backing of executives, such as happens with a sponsor to a CMMI®-based SCAMPISMappraisal. Such appraisals report findings to executives (especially the sponsor) that result in executive attention to the matter of correcting the findings, as necessary.

Education and training in quality control must be given to everybody in all departments at each level, because company-wide quality control requires partici- pation by everyone involved. The initial training has to take place within the devel- opment quality assurance organization so that development quality personnel, per Kaoru Ishikawa’s advice, will “train ourselves before we are fit to train others.” Then, the quality organization can provide a concentrated, intensive development quality training program to be attended by product developers and their managers. This is a necessary, but not sufficient, way to develop quality products that include software. Education about how to develop “quality” products solidifies the aware- ness and discipline necessary for meeting that objective. The teachers in this arena should be the development quality personnel who also carry out the evaluation

functions on a daily basis. Having development quality personnel as the teachers brings uniformity to the effort by providing knowledge common to all quality development.

A Quality Circle (QC) is “a small group [which met] voluntarily to perform quality control within the workshop to which they belonged” [7]. QCs originated in Japan in the early 1960s as part of a drive for quality and a critical economic need to overcome a reputation for cheap, poorly made goods. W. Edwards Deming and J. M. Juran introduced the concepts of statistical quality control and quality manage- ment to the Japanese. Dr. Ishikawa, merging these two disciplines, created a system called quality control circles. In 1961, a series of exploratory meetings were spon- sored by the Union of Japanese Scientists and Engineers (JUSE) under the leadership of Dr. Ishikawa, an engineering professor at the University of Tokyo. The objective was to develop a way for hands-on workers to contribute to the company. In 1962, the first circle was registered with JUSE, and a total of 20 circles were registered and operating by the end of the year. Since that time, QC techniques have been taught to and applied by the entire Japanese work force. Today, there are an estimated 1 mil- lion Quality Circles in Japan with more than 10 million members [8].

The QC has traditionally been applied to the manufacturing process, and has recently been used to enhance some management and professional (engineering) quality. The product developers could use the QC as another tool to guide the pro- duction of quality product. The QC provides a forum to discuss product production problems.

The QC frequently uses Ishikawa diagrams to highlight influential factors. Ishikawa diagrams are usually drawn to identify control points; the ingredients include people, materials, machines, organization, and processes [9]. Using Ishikawa’s “fishbone” cause-and-effect diagram provides a useful tool to find the specific cause(s) of the software production problem(s) and the resolution(s) to it (them).

A sample Ishikawa diagram is shown (Figure 2.1) that explores the possible causes of a slipped software development schedule. Each of the probable causes is written onto the fishbone in relation to the major control points of Manpower, Machines, Methods, and Materials (the 4 Ms). The group then reviews all the possi- ble causes in detail to determine the most likely ones. Those that are most likely are circled and receive the appropriate attention. In the sample, “insufficient develop- ment computers” is the most likely cause of software development being behind schedule.

Statistical methods for quality control include the Pareto analysis, cause-and-effect diagram, stratification, check sheet, histogram, scatter diagram, and the Shewhart control chart. Thomas McCabe has advocated the use of Pareto analysis to software quality techniques that are further explored in Chapter 6. Suf- fice it to say that these various statistical concepts were so influential in Japan through the guidance of W. Edwards Deming that they brought about Japan’s “quality revolution.” Each of these statistical methods may provide help to the product developer, and a few are explored in Section 2.5, on W. E. Deming. Since the details of these methods are sufficiently covered in various textbooks, they are not covered here.

Nationwide quality promotion activities reach their peak in Japan in November (Quality Month) when the Deming Prize is awarded. The Deming Prize is used to advertise the company’s products because it instills such a high degree of customer confidence that the consumer can be sure of a quality product. In the United States, quality interest in product development is stimulated with the IEEE Computer Society/SEI Software Process Achievement Award. It is an annual award given by the IEEE Computer Society and the SEI to recognize outstanding achievement in improving an organization’s ability to create and evolve software-dependent sys- tems. In addition to rewarding excellence, the purpose of this award is to foster con- tinuous advancement in the practice of software engineering and to disseminate insights, experiences, and proven practices throughout the relevant research and practitioner communities. Why not also stimulate quality interest more locally by providing incentives in contracts for measurable product development that involves software quality achievements? These types of awareness continually reinforce the quality concepts for product and software developers.