Ishikawa's seven basic tools are also called the seven old tools or the seven quality control tools. In recent years there emerged the seven new quality planning and management tools, which are the affinity diagram, the relations diagram, the tree diagram, the matrix chart, the matrix data analysis chart, the process decision program chart (PDPC), and the arrow diagram. Although discussion of these seven new tools is not in the scope of this book, it would be remiss not to mention that they may also be useful in software engineering. These seven new tools are mostly qualitative and seem more appropriate for project management and structural brainstorming. Rudisill (1992) reports that a large software development company has automated these seven new tools to facilitate the quality function deployment approach in software development and has gained positive experience, especially in gathering and verifying customers' requirements.
One of the seven new tools that we found very useful over the years is the relations diagram. It displays complex relationships and fosters cause-and-effect thinking. It organizes information from specific to general and surfaces key causes and key effects. It differs from the cause-and-effect diagram in that it displays multiple causes and effects, whereas the cause-and-effect diagram shows one dependent variable (effect) and its cause structure. Figure 5.17 shows a schematic representation of the relations diagram.
Figure 5.17. A Schematic Representation of a Relations Diagram
Figure 5.18 shows a loosely constructed relations diagram (which is somewhat different from the schematic representation in form). It displays the complex cause-and-effect relationships among the factors contributing to the number of customer critical situations for a software product. In this example, a critical situation occurred when a customer's business operations were affected because of issues related to this software product and the customer filed a complaint to the organization that provided the software. The issues could be product quality, the severity and impact of specific defects, technical support issues, ways-of-doing business issues (e.g., e-business issues ”business issues related to Internet and this software), and even issues related to business partners .
Figure 5.18. A Diagram of Complex Relationships Associated with Customer-Critical Situations of a Software Product
We found the relations diagram very appealing for complex situations like this example. It is flexible and it fits naturally with the small-team brainstorming process in problem identification and problem solving. In fact, the initial form of the diagram in Figure 5.18 was simply the result of a brainstorming session that was captured on a white board. The final form was the cumulative result of subsequent brainstorming sessions, interviews, further analysis, and verifications. The relations diagram can also be supported by quantitative data analysis. For example, the varying sizes of the circles of product components in Figure 5.18 reflect the relative contributions of these components to the number of customer critical situations. For interested experts, multivariate statistical analysis can also be performed to quantify the relationships in a relations diagram because applicable statistical techniques exist. For example, the structural equation models, or path analysis, appear to match well with the relations diagram. Even the two-way relationships among the factors in a relations diagram can be modeled via the recursive structural equation techniques (Duncan, 1975).
What Is Software Quality?
Software Development Process Models
Fundamentals of Measurement Theory
Software Quality Metrics Overview
Applying the Seven Basic Quality Tools in Software Development
Defect Removal Effectiveness
The Rayleigh Model
Exponential Distribution and Reliability Growth Models
Quality Management Models
In-Process Metrics for Software Testing
Complexity Metrics and Models
Metrics and Lessons Learned for Object-Oriented Projects
Measuring and Analyzing Customer Satisfaction
Conducting In-Process Quality Assessments
Conducting Software Project Assessments
Dos and Donts of Software Process Improvement
Using Function Point Metrics to Measure Software Process Improvements
A Project Assessment Questionnaire