Design for Trustworthy Software: Tools, Techniques, and Methodology of Developing Robust Software

Cause-and-effect diagrams are also called fishbone diagrams, because of their structure, or Ishikawa diagrams, after Kaoru Ishikawa, who developed this tool. Kinds of Ishikawa diagrams include standard, process, and Pareto, to name a few. They are among the most widely used tools in quality management and are used for the following purposes:

  • To identify causes of variation and to take countermeasures

  • Process classification

  • Pareto-Ishikawa

  • To generate data needed for FMEA

  • To identify possible "noise" and "control factors" in Taguchi Methods

  • As a visible communication tool

  • To categorize various inputs (causes) and output (effects)

The cause-and-effect diagram consists of the following three elements (see Figure 6.4):[5]

  • Effect or characteristic: It is best to find some way to express how bad the problem really isquantitatively, if possible. It is important to focus on one target at a time. Therefore, you need a cause-and-effect diagram for each characteristic that is being addressed.

  • Major branches: The major branches are identified by a brainstorming process that discusses what the major branches (also called the big bones) are. The major branches follow certain criteria, such as 4Ms (man, materials, machines, and methods), 5Ms-1E (the 4Ms plus measuring method and environment), related departments, and functions. In the case of software, we suggest 3Ms-SHE, which is defined as follows:

    Man: Includes software engineers, managers, support staff, and management

    Methodology: Includes procedures; methods such as QFD, FMEA, and Taguchi Methods; statistical and nonstatistical tools; techniques such as systematic processes, standardization, and documentation; policies; and the overall methodology, such as DFTS

    Measurement: Equipments and techniques used for measurement

    Software, such as OOD, CASE tools, and software development partner issues

    Hardware: Computer and other hardware used in development process

    Environment: Customer/user as well as internal work environments

  • Midsize, minor, and offshoot branches: You continue asking "Why?" after identifying the major branches. This leads sequentially to midsize branches (also called medium-sized bones), to minor branches (small bones), and then to offshoots of root causes. The exercise of looking for root causes continues until the group identifies an actionable countermeasure.

Figure 6.4. Elements of a Cause-and-Effect Diagram

The structured brainstorming process, invented by American advertising executive Alex Osborn, is at the heart of the cause-and-effect diagram. Creativity should be encouraged by not allowing ideas to be evaluated or discussion to take place until everyone has had a chance. All ideas, even wild ones, are entertained so long as they relate, even remotely, to the topic in question.

Creating Cause-and-Effect-Diagrams to Identify Causes

The procedure described here is used to identify and classify possible causes of a problem. It is also called the generic or standard type. It involves dispersion analysis and asking "Why does dispersion occur?" five times. It is a brainstorming tool and therefore should be built on broad discussion and consensus. The objective should be to generate a lot of ideas rather than a few "great" ones. No idea is stupid to start with. The bad ideas are eliminated in due course. The following steps are employed in conducting brainstorming:

1.

Assemble the group concerned with the problem. The group size should ideally be six but no larger than ten.

2.

Define the effect/characteristic or problem as precisely as possible in a problem statement.

3.

Have a skeleton diagram handy on a flip chart, and write the purpose, as defined by the problem statement, as the effect at the "head of the fish" (see Figure 6.4).

4.

Ask each person to come up with six major causes of the effect (the major branches along 3Ms-SHE or any other agreed-on grouping). Give them no more than a couple of minutes to write down their ideas on sticky notes before they are asked to read them for the group.

5.

Stick the notes from each individual on another flip chart.

6.

Discuss and combine common ideas. If grouped properly, they will fall into no more than six major branches. Record those on the diagram.

7.

Taking one major cause at a time, ask "Why?", and let each individual come up with the causes (minor branches) for each major cause.

8.

Discuss and agree on minor causes, and record them on the diagram.

9.

Taking one minor cause at a time, ask for offshoot causes. Repeat steps 7 and 8.

10.

Follow the preceding steps until all the actionable causes are identified and agreed on.

11.

Assign an importance to each cause ("important," "less important," and "trivial"), and identify those that are particularly significant in their impact on the effect.

12.

Collect data on as many causes as possible, particularly the "important" ones. Analyze them further to support the earlier brainstorming analysis and to identify the problem's root causes. Measure data in all cases where importance cannot be ascertained.

13.

Document your findings. Revise and upgrade the diagram as warranted.

Figure 6.5 shows a cause-and-effect diagram developed to identify causes.

Figure 6.5. A Cause-and-Effect Diagram for Identifying Causes

Cause-and-Effect-Diagrams for Process Classification

The purpose of process classification is to identify key factors that influence quality throughout the development process. The end product is an expanded view of the development process as a whole. It is a detailed analysis of the process that also reveals the implications of wrong or inadequate practice upstream on overall cost, quality, and schedule. The weak point of this kind of diagram is that similar causes may be cited repeatedly, as shown in Figure 6.6.

Figure 6.6. A Cause-and-Effect Diagram for Process Classification

As stated earlier, cause-and-effect diagrams have numerous applications. The basic approach is one of consensus building by structured brainstorming, in which the first and essential step is to agree on the "central question" or "effect." This must be followed by a broader discussion, including identifying the importance of various factors. That is followed by data collection and analyses of the supposed causes. The analyses often involve scatter diagrams and correlation analysis, which are discussed in the next section.

We suggested a 3Ms-SHE format for identifying major branches in a software process, but other formats may be equally applicable. It is wise to include as many ideas as possible initially. What is included can always be eliminated, but what's not included never gets considered. It is also smart to discuss "man" (people-related causes) last, for obvious reasons.

These diagrams are often used with other tools. For example, Pareto charts (see Figure 6.3) can be used to identify the major branches, which in this case are design creation, requirements development, testing, and coding. Such use of Pareto is called Pareto-Ishikawa. Similarly, these diagrams can be used in FMEA and Taguchi Methods, as discussed in Chapters 13, 16, and 17.

Related

Категории