Unit 5

September 17, 2011

Defect

For the development phases before testing, the development activities themselves are subject to defect injection, and the reviews or inspections at end-of-phase activities are the key vehicles for defect removal. For the testing phases, the testing itself is for defect removal. When the problems found by testing are xed incorrectly, there is another chance to inject defects. In fact,even for the inspection steps, there are chances for bad xes. The Figure below describes the detailed mechanics of defect injection and removal at each step of the development process. From the gure, defect removal eectiveness for each development step, therefore, can be dened as:

P.Selvapriyavadhana,Asst.Prof,ACT

Figure 1: Defect Injection and Removal During One Process Step

SQM

P.Selvapriyavadhana,Asst.Prof,ACT

Defect Removal Eectiveness and Quality Planning

Phase defect removal eectiveness and related metrics associated with eectiveness analyzes (such as defect removal and defect injection rates) are useful for quality planning and quality management. These measurements clearly indicate which phase of the development process we should focus on for improvement. Eectiveness analyzes can be done for the entire project as well as for local areas, such as at the component level and specic departments in an organization, and the control chart technique can be used to enforce consistent improvement across the board. Longitudinal release-to-release monitoring of these metrics can give a good feel for the process capability of the development organization. In addition, experiences from previous releases provide the basis for phase-specic target setting and for quality planning.
Phase-Based Defect Removal Model

The phase-based defect removal model (DRM) summarizes the relationships among three metricsdefect injection, defect removal, and eectiveness. The DRM takes a set of error-injection rates and a set of phase-eectiveness rates as input, then models the defect removal pattern step by step. It takes a simplied view of Figure 6.3 and works like this:

SQM

P.Selvapriyavadhana,Asst.Prof,ACT

Figure 2: Defect Removal

SQM

P.Selvapriyavadhana,Asst.Prof,ACT

Ishikawa-Diagram

Basic concept

The Idea: Think about possible causes and reasons leading to an effect or a problem nd solution for preventing those problems. 7 causes lead to the problem/eect. The causes are divided into main-and side causes. The7 causes are: 1. Methods 2. Machinery 3. Management 4. Materials 5. Manpower 6. Environment 7. Measurement

SQM

P.Selvapriyavadhana,Asst.Prof,ACT

Figure 3: Ishikawa-Diagram

SQM

P.Selvapriyavadhana,Asst.Prof,ACT

Aim

Find the causes, main and side causes. Clarity Interdependence of the causes. Improve them for having the wanted eect or eliminate them for solving the problem.
theoretical conversion

1. sketch the diagram and in script the needed causes. 2. work the main and side causes out 3. check the completeness 4. weight the main & side causes in terms of meaning & inuence 5. check the selected causes for rightness 6. The team discusses about the solution. causes that can be improved or eliminated easily will be nished rst of all (no need to be weighted) The weighted causes are in a list of priority and will be nished in turn.
Example

Rise in productivity 1.sketch the diagram and in script the needed causes.

SQM

P.Selvapriyavadhana,Asst.Prof,ACT

SQM

P.Selvapriyavadhana,Asst.Prof,ACT

SQM

P.Selvapriyavadhana,Asst.Prof,ACT

SQM

10

P.Selvapriyavadhana,Asst.Prof,ACT

SQM

11

P.Selvapriyavadhana,Asst.Prof,ACT

SQM

12

P.Selvapriyavadhana,Asst.Prof,ACT

SQM

13

P.Selvapriyavadhana,Asst.Prof,ACT

SQM

14

P.Selvapriyavadhana,Asst.Prof,ACT

SQM

15

P.Selvapriyavadhana,Asst.Prof,ACT

SQM

16

P.Selvapriyavadhana,Asst.Prof,ACT

SQM

17

P.Selvapriyavadhana,Asst.Prof,ACT

SQM

18

P.Selvapriyavadhana,Asst.Prof,ACT

4. weight the main & side causes in terms of meaning & inuence. Lean Management Standardization Motivation Education 5. check the selected causes for rightness. 6. The team discusses about the solution causes that can be improved or eliminated easily: Hardware Software Temperature Noise weighted causes Lean Management Standardization Motivation Education

SQM

19

P.Selvapriyavadhana,Asst.Prof,ACT

Applying the Seven Basic Quality Tools in Software Development

The basic statistical tools for quality control promoted by Ishikawa (1989) are widely used in manufacturing productions. They have indeed become an integral part of the quality control literature, and have been known as Ishikawas seven basic tools. This chapter describes the application of these tools for process and quality control in software development. There are many ways to analyze software metrics; the applications of Ishikawas seven tools represent a set of basic operations. Keep in mind that these statistical tools are for process and quality control at the project and organization level and, hence, are useful for project leaders and process experts. In contrast, they do not provide specic information to software developers on how to improve the quality of their designs or implementation. Also, because not all these tools are equally useful for small projects where statistical patterns of parameters of the development process are less obvious, the benets of statistics may not be realized. The box at the end of the chapter oers specic recommendations for small teams. In addition, although the benets of these tools have long been proved in manufacturing operations, their use and roles in software development has not been widely recognized. For instance, the use of control charts in manufacturing production can ensure a certain endproduct quality once the process is dened and the control limits are set. In software development, however, the process is complex and involves a high degree of creativity and mental activity. It is extremely dicult, if not impossible, to dene the process capability of software development in statistical terms. Therefore, achieving statistical process control in software development may mean a lot more than control charting. It may require,
SQM 20

P.Selvapriyavadhana,Asst.Prof,ACT

for example, new development technology, CASE tools, and the use of defect models and reliability estimating techniques. However, good use of the seven basic tools can lead to positive long-term results for process improvement and quality management in software development. The following sections begin with a brief description of the tools, followed by a discussion of each tool with examples of its applications. Where appropriate, the inuences of these tools on process improvement and on decision making are also described. The examples are either from software engineering literature or from software projects developed at IBM in Rochester, Minnesota. In addition to the seven basic tools, we discuss the relations diagram, which is eective for small team brainstorming and particularly useful in displaying cause-and-eect relationships.

SQM

21

P.Selvapriyavadhana,Asst.Prof,ACT

Figure 4: Ishikawas Seven Basic Tools for Quality Control

SQM

22

P.Selvapriyavadhana,Asst.Prof,ACT

A check sheet is a paper form with printed items to be checked. Its main purposes are to facilitate gathering data and to arrange data while collecting it so the data can be easily used later. Another type of check sheet is the check-up conrmation sheet. It is concerned mainly with the quality characteristics of a process or a product. To distinguish this conrmation check sheet from the ordinary data-gathering check sheet, we use the term checklist. In most software development environments, the data-gathering aspect is automated electronically and goes far beyond the data-gathering check sheet approach, which has been used in manufacturing production. Our discussion on this tool, therefore, is conned to checklists. A Pareto diagram is a frequency chart of bars in descending order; the frequency bars are usually associated with types of problems. It is named after a nineteenthcentury Italian economist named Vilfredo Pareto (1848 1923), who expounded his principle in terms of the distribution of wealththat a large share of the wealth is owned by a small percentage of the population. In 1950 Juran applied the principle to the identication of quality problemsthat most of the quality problems are due to a small percentage of the possible causes. In software development, the X -axis for a Pareto diagram is usually the defect cause and the Y -axis the defect count. By arranging the causes based on defect frequency, a Pareto diagram can identify the few causes that account for the majority of defects. It indicates which problems should be solved rst in eliminating defects and improving the operation. Pareto analysis is commonly referred to as the 8020 principle (20% of the causes account for 80% of the defects), although the cause-defect relationship is not always in an 8020 distribution. The histogram is a graphic representation of frequency
SQM 23

P.Selvapriyavadhana,Asst.Prof,ACT

counts of a sample or a population. The X-axis lists the unit intervals of a parameter (e.g., severity level of software defects) ranked in ascending order from left to right, and the Y-axis contains the frequency counts. In a histogram, the frequency bars are shown by the order of thXe variable, whereas in a Pareto diagram the frequency bars are shown by order of the frequency counts. The purpose of the histogram is to show the distribution characteristics of a parameter such as overall shape, central tendency, dispersion, and skewness. It enhances understanding of the parameter of interest. A scatter diagram vividly portrays the relationship of two interval variables. In a cause-eect relationship, the X -axis is for the independent variable and the Y -axis for the dependent variable. Each point in a scatter diagram represents an observation of both the dependent and independent variables. Scatter diagrams aid databased decision making (e.g., if action is planned on the X variable and some eect is expected on the Y variable). One should always look for a scatter diagram when the correlation coecient of two variables is presented. A run chart tracks the performance of the parameter of interest over time. The X-axis is time and the Y -axis is the value of the parameter. A run chart is best used for trend analysis, especially if historical data are available for comparisons with the current trend. Ishikawa (1989) includes various graphs such as the pie chart, bar graph, compound bar graph, and circle graph under the section that discusses run charts. An example of a run chart in software is the weekly number of open problems in the backlog; it shows the development teams workload of software xes. A control chart can be regarded as an advanced form of a run chart for situations where the process capability can be dened. It consists of a central line, a pair
SQM 24

P.Selvapriyavadhana,Asst.Prof,ACT

of control limits (and sometimes a pair of warning limits within the control limits), and values of the parameter of interest plotted on the chart, which represent the state of a process. The X -axis is real time. If all values of the parameter are within the control limits and show no particular tendency, the process is regarded as being in a controlled state. If they fall outside the control limits or indicate a trend, the process is considered out of control. Such cases call for causal analysis and corrective actions are to be taken. The cause-and-eect diagram, also known as the shbone diagram, was developed by Ishikawa and associates in the early 1950s in Japan. It was rst used to explain factors that aect the production of steel. It is included in the Japanese Industrial Standards terminology for quality control (Kume, 1989). It shows the relationship between a quality characteristic and factors that aect that characteristic. Its layout resembles a shbone, with the quality characteristic of interest labeled at the sh head, and factors aecting the characteristics placed where the bones are located. While the scatter diagram describes a specic bivariate relationship in detail, the cause-and-eect diagram identies all causal factors of a quality characteristic in one chart.

SQM

25