QUALITY MANAGEMENT AND IMPROVEMENT – CH4 2015-2016 Sergio Sayago
SQA from Quality Experts • Notes from: • Software Quality Lessons Learned from the Quality
Experts, by G. Gordon Schulmeyer. In Handbook of Software Quality Assurance, 4th edition. Edited by G. Gordon Schulmeyer, pp. 35-62. Artech House, London, 2008.
• What important lessons learned in the recent past are the eminent quality experts telling us?
• This chapter looks to the works of Kaoru Ishikawa, Joseph M. Juran, Yoji Akao, W. Edwards Deming, Genichi Taguchi, Shigeo Shingo & Philip Crosby
1
Deming, Juran and Crosby • Commit to quality improvement throughout your entire
organization • Attack the system rather than the employee • Strip down the work process—whether it be the
manufacturing of a product or customer service—to find and eliminate problems that prevent quality
• Identify your customer, internal or external, and satisfy that customer’s requirements in the work process and the finished product
• Eliminate waste, instill pride and teamwork, and create an atmosphere of innovation for continued and permanent quality improvement
2
Kaoru Ishikawa (I) • Noted for his quality management innovations • He is considered a key figure in the development of
quality initiatives in Japan, particularly the quality circle. • A quality circle is a group of workers who do the same or similar
work, who meet regularly to identify, analyze and solve work-related problems
• He is best known outside Japan for the Ishikawa or cause and effect diagram (also known as fishbone diagram) often used in the analysis of industrial processes
3
Kaoru Ishikawa (II) • Company-wide quality control • It means that all departments and all levels of personnel
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
4
Kaoru Ishikawa (III) • 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 position to make corrective action happen quickly and thoroughly
• Education and training in quality control • It must be given to everybody in all departments at each
level, because company-wide quality control requires participation by everyone involved
5
Joseph M. Juran (I) • Engineer and management consultant • Books
• Quality Control Handbook, 1951 • Quality Planning and Analysis, 1970 • Upper Management and Quality, 1980
6
Joseph M. Juran (II) • To meet the challenges of solid quality achievement: • There is a grim reality in product development involving
software that quality needs immediate attention and can stand improvement yearly
• Too many software-intensive systems never meet their requirements, either because development overruns financial or time budgets, or because the user is unsatisfied
• Study the symptoms of defects and failures, develop a theory, test the theory, stimulate remedial action by the appropriate department(s)
7
Joseph M. Juran (III) • A quality-oriented training program: not only for
members of the specialized quality departments but also software developers (design reviews, quality cost analysis, and concepts of inspection for design and code)
8
Joseph M. Juran (IV) • Upper management leadership of the company's
approach to product quality: • The need for upper management leadership stems from
the need to create major changes, two of which include annual improvements in quality and a massive quality oriented training program already discussed above
• The recommended step for upper management in Western companies is to perform a comprehensive company- wide quality audit to understand what needs to be done
9
Yoji Akao (I) • A Japanese planning specialist • He developed Quality Function Deployment (QFD),
which is a • “method wily to transform qualitative user demands into
quantitative parameters, to deploy the functions forming quality, and to deploy methods for achieving the design quality into subsystems and component parts, and ultimately to specific elements of the manufacturing process.”
10
Yoji Akao (II) • House of Quality: matrix of customer requirements
versus technical product specifications which, when portrayed, this matrix had a roof-life appearance.
• The basic structure is a table with "Whats" as the labels on the left and "Hows" across the top. The roof is a diagonal matrix of "Hows vs. Hows" and the body of the house is a matrix of "Whats vs. Hows". Both of these matrices are filled with indicators of whether the interaction of the specific item is a strong positive, a strong negative, or somewhere in between.
• It provides a voice to the user.
11
W. Edwards Deming (I) • An American engineer, statistician, professor, author,
lecturer, and management consultant • The PDSA Cycle is a systematic series of steps for
gaining valuable learning and knowledge for the continual improvement of a product or process. Also known as the Deming Wheel, or Deming Cycle, the concept and application was first introduced to Dr. Deming by his mentor, Walter Shewhart of the famous Bell Laboratories in New York
12
W. Edwards Deming (II) • Statistical methods applied to quality control, which is
the application of statistical principles and techniques in all stages of production, maintenance, and service, directed toward the economic satisfaction of demand
• In addition to the statistical knowledge, W. Edwards Deming professes that everyone should learn a common method of attacking and describing problems
• This commonality of method is essential if people from different parts of the company are to work together on quality improvement
• The method is referred to as the P-D-C-A approach (Plan-Do-Check-Analyze and Act), and is usually represented as the Deming Circle
13
Genichi Taguchi (I) • From the 1950s onwards, Taguchi developed a
methodology for applying statistics to improve the quality of manufactured goods
• The Taguchi Method shows techniques for reducing variability in products and processes at the design stage, thus enhancing their ability to overcome the many uncontrollable changing conditions in production
14
Genichi Taguchi (II) • Off-line quality control: attempts to reduce product or
process variability by controlling noise and control factors. Noise factors are outer noise and inner noise (environmental conditions, hardware). Control factors include: personnel, software tools, desk layouts…
• Online quality control: measurement, prediction and correction, and adjustment. From the measurement, the average quality of the next n units is predicted. If the predicted value deviates from a target value, corrective action is taken. When normal, production continues; otherwise, adjustment
15
Shigeo Shingo (I) • A Japanese industrial engineer who is considered as the
world’s leading expert on manufacturing practices and the Toyota Production System
16
Shigeo Shingo (II) • Zero Quality Control: the ideal production system (one
that does not manufacture any defects). To achieve this ideal, two things are necessary:
• a) poka-yoke (mistake-proofing): looks as a defect, stops the production system, and gives immediate feedback so that we can get to the root cause of the problem
• b) source inspections: looks at errors before they become defects
17
Philip Crosby (I) • A businessman and author who contributed to
management theory and quality management practices • "doing it right the first time" (DIRFT)
18
Philip Crosby (II) • Quality Management Maturity Grid: five maturing stages
through which quality management evolves
• Drawing upon the Quality Management Maturity Grid as a guide, the Software Quality Assurance Measurement Category.
• In stage 1: uncertainty: five quality facts that software development believes: quality cannot be defined, because it cannot be defined, quality cannot be measured, error is inevitable...
19
Philip Crosby (III) - QMMG
20
Philip Crosby (IV)
3. The trouble with quality is that American workers don’t give a damn.4. Quality is fine, but we cannot afford it.5. Data processing is different—error is inevitable.
Among software developers there will usually be agreement about these quality“facts,” especially the inevitability of errors in software. Education is required todispel these erroneous “facts,” better identified as mind-sets.
When education is completed, there is usually lip service given to quality wherepeople will say “yes” from their minds while they feel “no” in the pits of their stom-achs. They will pay lip service to quality without really realizing it [39]. They willsay they want quality but will continue to judge performance solely by schedule andbudget.
There seems to be an implied assumption that the three goals of quality, cost,and schedule are all conflicting; all mutually exclusive. It is not true. Significantimprovements in both cost and schedule can be achieved as a result of focusing onquality [40]. Fundamental to W. Edwards Deming teachings is that the only way toincrease productivity and lower cost is to increase quality [9].
Often, it is company policy to supply exactly what a customer orders every time.This may seem too elementary to be important, but it is important. Remember thatsoftware quality is “to conform to requirements and to provide useful services” tothe customer. Too often, companies place the emphasis on making the shipment,whether it’s right or just close to right [41].
Some cost is incurred from the massive educational and procedural reworkingeffort that will be required. Each project will have to relearn what it really takes toachieve quality software production. To effectively increase quality, the SQA personhas to get into the “barrel” with software development to see that the relearningtakes place on every project.
In the awakening stage of software quality, the only times that SQA personnelare looked toward are times of crisis for the software development activity. One cri-sis during the awakening stage is customer assaults on the integrity of the softwaredevelopment activities. SQA personnel can contribute by acting as a buffer to absorbthese assaults. Usually this takes the form of special intensive quality investigationsinto the software development resulting in a report to the customer. There is value tobe gained by highlighting the quality perspective of the software development.
Another crises in software development is the software documentation trap.Software documentation is usually a deliverable item along with the computer
54 Software Quality Lessons Learned from the Quality Experts
Table 2.5 Software Quality Management Maturity Grid
MeasurementCategory
Stage 1:Uncertainty
Stage 2:Awakening
Stage 3:Enlightenment
Stage 4:Wisdom
Stage 5:Certainty
Softwarequalityassurance(SQA)
There are fivequality “facts”that softwaredevelopmentbelieves.
SQA is calledupon in crisissituations.
The SQA Plan iswritten first asthe “driver” tothe softwaredevelopmenteffort.
SQA managementand softwaredevelopmentmanagement areworking togetherto produce qualitysoftware.
Quality software isproduced on timewithin cost everytime.
Source: [4].
21
Philip Crosby (V) – facts (!?) • Because it cannot be defined, quality cannot be measured • The trouble with quality is that (American) workers don’t
give a damn • Error is inevitable
22
Summary • “Long-term improvement only comes about from
systematic study and action, nor from slogans or arbitrary objectives”
• "Quality is never an accident; it is always the result of intelligent effort"
23
Some thoughts / questions… • Why do you think there is a fairly strong focus on
quantitative (data / techniques…)? • Most of these leading experts come from manufacturing.
How do the lessons learned from quality in manufacturing carry over to software development?
• Do you know of any (internationally) well-known expert in software quality?
24