Unit 5

Unit 5

September 17, 2011

1 Defect

For the development phases before testing, the develop-ment activities themselves are subject to defect injection,and the reviews or inspections at end-of-phase activitiesare the key vehicles for defect removal. For the testingphases, the testing itself is for defect removal. When theproblems found by testing are fixed incorrectly, there isanother chance to inject defects. In fact,even for the in-spection steps, there are chances for bad fixes.The Figure below describes the detailed mechanics ofdefect injection and removal at each step of the develop-ment process. From the figure, defect removal effective-ness for each development step, therefore, can be definedas:

1

P.Selvapriyavadhana,Asst.Prof,ACT

Figure 1: Defect Injection and Removal During One Process Step

SQM 2


Defect Removal Effectiveness and Quality Planning

Phase defect removal effectiveness and related metricsassociated with effectiveness analyzes (such as defect re-moval and defect injection rates) are useful for qualityplanning and quality management. These measurementsclearly indicate which phase of the development processwe should focus on for improvement. Effectiveness an-alyzes can be done for the entire project as well as forlocal areas, such as at the component level and specificdepartments in an organization, and the control charttechnique can be used to enforce consistent improvementacross the board. Longitudinal release-to-release moni-toring of these metrics can give a good feel for the processcapability of the development organization. In addition,experiences from previous releases provide the basis forphase-specific target setting and for quality planning.

Phase-Based Defect Removal Model

The phase-based defect removal model (DRM) summa-rizes the relationships among three metricsdefect injec-tion, defect removal, and effectiveness. The DRM takes aset of error-injection rates and a set of phase-effectivenessrates as input, then models the defect removal patternstep by step. It takes a simplified view of Figure 6.3 andworks like this:

SQM 3


Figure 2: Defect Removal

SQM 4


2 Ishikawa-Diagram

Basic concept

The Idea:

Think about possible causes and reasons leading to an ef-fect or a problem find solution for preventing those prob-lems.

7 causes lead to the problem/effect. The causes are di-vided into main-and side causes.The7 causes are:

1. Methods

2. Machinery

3. Management

4. Materials

5. Manpower

6. Environment

7. Measurement

SQM 5


Figure 3: Ishikawa-Diagram

SQM 6


Aim

• Find the causes, main and side causes.

• Clarity

• Interdependence of the causes.

• Improve them for having the wanted effect or elimi-nate 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& influence

5. check the selected causes for rightness

6. The team discusses about the solution.

• causes that can be improved or eliminated eas-ily will be finished first of all (no need to beweighted)

• The weighted causes are in a list of priority andwill be finished in turn.

Example

Rise in productivity

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

SQM 7


SQM 8


SQM 9


SQM 10


SQM 11


SQM 12


SQM 13


SQM 14


SQM 15


SQM 16


SQM 17


SQM 18


4. weight the main & side causes in terms of meaning& influence.

• Lean Management

• Standardization

• Motivation

• Education

5. check the selected causes for rightness. 6. The teamdiscusses about the solution causes that can be improvedor eliminated easily:

• Hardware

• Software

• Temperature

• Noise

weighted causes

• Lean Management

• Standardization

• Motivation

• Education

SQM 19


Applying the Seven Basic Quality Tools in Software Devel-opment

The basic statistical tools for quality control promotedby Ishikawa (1989) are widely used in manufacturing pro-ductions. They have indeed become an integral part ofthe quality control literature, and have been known asIshikawa’s seven basic tools. This chapter describes theapplication of these tools for process and quality con-trol in software development. There are many ways toanalyze software metrics; the applications of Ishikawa’sseven tools represent a set of basic operations. Keepin mind that these statistical tools are for process andquality control at the project and organization level and,hence, are useful for project leaders and process experts.In contrast, they do not provide specific information tosoftware developers on how to improve the quality oftheir designs or implementation.

Also, because not all these tools are equally useful forsmall projects where statistical patterns of parametersof the development process are less obvious, the bene-fits of statistics may not be realized. The box at theend of the chapter offers specific recommendations forsmall teams. In addition, although the benefits of thesetools have long been proved in manufacturing operations,their use and roles in software development has not beenwidely recognized. For instance, the use of control chartsin manufacturing production can ensure a certain end-product quality once the process is defined and the con-trol limits are set. In software development, however, theprocess is complex and involves a high degree of creativ-ity and mental activity. It is extremely difficult, if notimpossible, to define the process capability of softwaredevelopment in statistical terms. Therefore, achievingstatistical process control in software development maymean a lot more than control charting. It may require,

SQM 20


for example, new development technology, CASE tools,and the use of defect models and reliability estimatingtechniques.

However, good use of the seven basic tools can lead topositive long-term results for process improvement andquality management in software development.

The following sections begin with a brief description ofthe tools, followed by a discussion of each tool with ex-amples of its applications. Where appropriate, the in-fluences of these tools on process improvement and ondecision making are also described. The examples are ei-ther from software engineering literature or from softwareprojects developed at IBM in Rochester, Minnesota. Inaddition to the seven basic tools, we discuss the relationsdiagram, which is effective for small team brainstormingand particularly useful in displaying cause-and-effect re-lationships.

SQM 21


Figure 4: Ishikawa’s Seven Basic Tools for Quality Control

SQM 22


A check sheet is a paper form with printed items tobe checked. Its main purposes are to facilitate gather-ing data and to arrange data while collecting it so thedata can be easily used later. Another type of checksheet is the check-up confirmation sheet. It is concernedmainly with the quality characteristics of a process ora product. To distinguish this confirmation check sheetfrom the ordinary data-gathering check sheet, we use theterm checklist. In most software development environ-ments, the data-gathering aspect is automated electron-ically and goes far beyond the data-gathering check sheetapproach, which has been used in manufacturing produc-tion. Our discussion on this tool, therefore, is confinedto checklists.

A Pareto diagram is a frequency chart of bars in de-scending order; the frequency bars are usually associatedwith types of problems. It is named after a nineteenth-century Italian economist named Vilfredo Pareto (1848–1923), who expounded his principle in terms of the dis-tribution of wealth—that a large share of the wealth isowned by a small percentage of the population. In 1950Juran applied the principle to the identification of qual-ity problems—that most of the quality problems are dueto a small percentage of the possible causes. In softwaredevelopment, the X -axis for a Pareto diagram is usuallythe defect cause and the Y -axis the defect count. Byarranging the causes based on defect frequency, a Paretodiagram can identify the few causes that account for themajority of defects. It indicates which problems shouldbe solved first in eliminating defects and improving theoperation. Pareto analysis is commonly referred to asthe 80–20 principle (20% of the causes account for 80%of the defects), although the cause-defect relationship isnot always in an 80–20 distribution.

The histogram is a graphic representation of frequency

SQM 23


counts of a sample or a population. The X-axis liststhe unit intervals of a parameter (e.g., severity level ofsoftware defects) ranked in ascending order from left toright, and the Y-axis contains the frequency counts. Ina histogram, the frequency bars are shown by the orderof thXe variable, whereas in a Pareto diagram the fre-quency bars are shown by order of the frequency counts.The purpose of the histogram is to show the distribu-tion characteristics of a parameter such as overall shape,central tendency, dispersion, and skewness. It enhancesunderstanding of the parameter of interest.

A scatter diagram vividly portrays the relationship oftwo interval variables. In a cause-effect relationship, theX -axis is for the independent variable and the Y -axisfor the dependent variable. Each point in a scatter di-agram represents an observation of both the dependentand independent variables. Scatter diagrams aid data-based decision making (e.g., if action is planned on the Xvariable and some effect is expected on the Y variable).One should always look for a scatter diagram when thecorrelation coefficient of two variables is presented.

A run chart tracks the performance of the parameter ofinterest over time. The X-axis is time and the Y -axis isthe value of the parameter. A run chart is best used fortrend analysis, especially if historical data are availablefor 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 sectionthat discusses run charts. An example of a run chart insoftware is the weekly number of open problems in thebacklog; it shows the development team’s workload ofsoftware fixes.A control chart can be regarded as an advanced formof a run chart for situations where the process capabil-ity can be defined. It consists of a central line, a pair

SQM 24


of control limits (and sometimes a pair of warning limitswithin the control limits), and values of the parameter ofinterest plotted on the chart, which represent the stateof a process. The X -axis is real time. If all values ofthe parameter are within the control limits and show noparticular tendency, the process is regarded as being in acontrolled state. If they fall outside the control limits orindicate a trend, the process is considered out of control.Such cases call for causal analysis and corrective actionsare to be taken.

The cause-and-effect diagram, also known as thefishbone diagram, was developed by Ishikawa and asso-ciates in the early 1950s in Japan. It was first used toexplain factors that affect the production of steel. It isincluded in the Japanese Industrial Standards terminol-ogy for quality control (Kume, 1989). It shows the rela-tionship between a quality characteristic and factors thataffect that characteristic. Its layout resembles a fishbone,with the quality characteristic of interest labeled at thefish head, and factors affecting the characteristics placedwhere the bones are located. While the scatter diagramdescribes a specific bivariate relationship in detail, thecause-and-effect diagram identifies all causal factors of aquality characteristic in one chart.

SQM 25

Unit 5

Documents

act sqm

defect removal sqm

act defect removal eectiveness

act figure

solution causes

needed causes

selected causes

act aim