Module 03 The Context for Quality Improvement
-
Upload
collin-cooper -
Category
Documents
-
view
221 -
download
0
description
Transcript of Module 03 The Context for Quality Improvement
version 3.09
Slide 1CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M03
SMU CSE 8314 / NTU SE 762-N
Software Measurement and Quality Engineering
Module 03The Context for Quality
Improvement
version 3.09
Slide 2CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M03
Contents• Fundamentals of Quality
Improvement• Excuses for Poor Quality• Characteristics of Software and
Software Culture• Characteristics of Software
Development• Summary
version 3.09
Slide 3CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M03
Fundamentals of Quality Improvement
version 3.09
Slide 4CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M03
Fundamentals of Quality Improvement
• Quality almost always meets some minimal level of acceptability – Or you would not be in business
• Quality can always be improved – No such thing as “total quality superiority”
• Quality is relative – If you don’t know how you compare, it is
easy to overestimate or underestimate • Quality improvement is hard work
– So it is hard to motivate improvement
version 3.09
Slide 5CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M03
Excuses for Poor Quality
version 3.09
Slide 6CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M03
“Our Quality Isn’t That Bad”
• “People Buy it”– This is true only as long as the
competition can not do any better!• “Users Like it”
– Prisoners like their gruel, too– What else can they choose from
Excuses for Poor Quality
version 3.09
Slide 7CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M03
“All Software Has Bugs”• This is a sign that software
development is not yet a profession for this organization– Does it have to have as many as it
has?– Some software has very few if any
bugs, so it IS possible to improve the quality
Excuses for Poor Quality
version 3.09
Slide 8CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M03
“It’s Not Possible to Improve”• “You cannot run a 2 minute mile”
– But you can do better than we do today• “I can’t get rid of bugs without
introducing more”– Because you don’t know how to
engineer quality into the product• “It isn’t worth the cost”
– How much are you spending on rework?
Excuses for Poor Quality
version 3.09
Slide 9CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M03
The Crosby Motivation Method:
Start with the Cost of QualityMeasurethe Cost
of Quality
UnderstandHow toAchieveQuality
MotivateAchievement
of Quality
Understandthe Valueof Quality
version 3.09
Slide 10CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M03
“If It Ain’t Broke, Don’t Fix It”
• Existing patterns fight against change• No reason to change
– Risk of change– It works
• The system fights change - preserves status quo– Look for an example on the next slide
Excuses for Poor Quality
This is known as the “Lock-on” effect
version 3.09
Slide 11CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M03
Example of Lock-on effect• New design method --> “Must”
change many other things: – Programming languages/methods– Software tools– Workstations– Schools of thought – Community of users– Managers/management styles– Reference books– User interface philosophy
version 3.09
Slide 12CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M03
Cultures Resist Change
ThereforeQuality improvement involves looking
at the Culture and the Environment.– Preserve the good while changing vs– Revolution
“People will always choose the familiar over the comfortable.”
Virginia Satir, family therapist
version 3.09
Slide 13CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M03
Evolution vs Revolution
Natural tendency is to
deteriorate over time
Continuous Process Improvement
Periodic “Revolution”
Reinventing the Corporation
Michael Hammer
version 3.09
Slide 14CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M03
Assignment 2 - Study Your Organization
Find evidence in your organization that people are satisfied with the current level of quality.– For example, what happens to people who express
dissatisfaction with qualityOR
Find evidence in your organization that people resist learning about customer opinions– For example, what happens to customer complaints
version 3.09
Slide 15CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M03
Assignment 2 - Deliverable
Write up the example in a general form, suitable for
presenting to the rest of the class.
version 3.09
Slide 16CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M03
Characteristics ofSoftware and Software
Culture
version 3.09
Slide 17CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M03
What is Software?IEEE: Software consists of
– Computer Programs– Procedures– Rules– (possibly) associated documentation
and data• Therefore, software development
includes all of these aspects, not just the code being produced
version 3.09
Slide 18CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M03
What is Culture?
• For example, sense of humor, musical and artistic tastes, beliefs & behaviors, shared experiences, forms of entertainment
Culture: That which is common to all members of a group.
version 3.09
Slide 19CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M03
Insider’s vs Outsider’s view• Every group has a culture.• Insiders know the rules and details
the best.• Outsiders often see best how the
culture differs from others - and how it is the same.
version 3.09
Slide 20CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M03
Software CultureSoftware Culture: What is common to all
software development organizations– Software jokes– Common behaviors & beliefs
Subculture: A cluster of members which share additional common characteristics.– MacIntosh users– Hackers– Operating system developers
version 3.09
Slide 21CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M03
Software Culture Diagram
Common toAll
Common to aSubculture
version 3.09
Slide 22CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M03
Cultures are Inherently Conservative
• Largely satisfied with the status quo• Often unable or unwilling to recognize
their own unique cultural behaviors• Often do not understand other cultures• Fear loss of what they have if change is
introduced
version 3.09
Slide 23CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M03
Characteristics of Subcultures - I
• The perception of uniqueness– “We are different”– Fact: most subcultures are largely the
same, but they tend to magnify their differences
• Self reinforcement– “We are the best”– Fact: you always seem better if you
don’t know about the others
version 3.09
Slide 24CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M03
Characteristics of Subcultures - II• Ability to achieve success
– “We are surviving, so we must be doing something right.”
– “Don’t mess with success.”
– Fact: if you have competition, you cannot rest on your laurels.
“Where there is arrogance, there is opportunity.”Japanese proverb
version 3.09
Slide 25CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M03
Pain Motivates Change• Throughout history, nature has
forced change by making the status quo too painful“The luxury of adversity.” Sandy Munro • The most successful and long-lived
organizations have either– Embraced change and learned to adjust
to changing environments, or– Successfully resisted change
version 3.09
Slide 26CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M03
Enlightened Leadership or Pain
“In the absence of true wisdom and enlightened leadership,
change happens only when the pain of change is less than the
pain of the status quo.”
version 3.09
Slide 27CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M03
The Change Process
CurrentState Change
regression
Productivityor
Qualityor
Cycle Timeor
Whatever
NewState
version 3.09
Slide 28CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M03
Characteristics of Software Development
version 3.09
Slide 29CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M03
Conformance to Requirements is Not Enough
• Requirements for software are never complete or correct
• Requirements are a means to an end• The ultimate requirement is
providing value to someone• You must identify who counts and
elicit what is of value to them
version 3.09
Slide 30CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M03
Software Development is Mostly Design, Not Manufacturing
• The manufacturing part is very suitable for traditional quality improvement techniques
• The design part is not - but it is where much of the cost is found
• Design must be the focus for software quality engineering - this is not like conventional quality programs that focus on production processes
version 3.09
Slide 31CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M03
Software Development Activities
Define & Understand requirements
Top level DesignDocumentation of
Design and Requirements (some CASE tools support this well)
Low Level Design (some CASE tools support this)
Coding (some tools support automatic code generation)
Translation or conversion of code to machine language (compilers, etc.)
Duplication of files and diskettes
Production (printing) of manuals
Assembly of parts and construction of product packages
MaximumAutomation
MaximumCreativity
version 3.09
Slide 32CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M03
“Zero Defects” Is Not Realistic for the Creative Parts of the
Development Process• Especially the requirements
analysis part since we don’t know how to do this part very well
• We need a better measure of software quality goals in the creative part of the process
version 3.09
Slide 33CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M03
“Do It Right the First Time” Cannot Work If You Don’t
Know What “It” Is.
• We need to rethink the economic incentives
• Learning is important so we can avoid making mistakes again
version 3.09
Slide 34CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M03
Existing Patterns May Be Successful and Costly to Change
• Must know when and whether to change
• Must know whether to change the product or the process
See “analysis of status quo”, below.
version 3.09
Slide 35CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M03
Perfection May Not Be Justifiable• Beware the “autocrats” who accept
nothing but perfection
The consequences of perfection may be unacceptable in terms of cost or schedule or morale impact
version 3.09
Slide 36CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M03
Analysis of Status Quo• Can you consistently produce quality
products (value for your customer)? • If not, why not? (process or product)
Note: If change is required, it may be essential for survival
version 3.09
Slide 37CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M03
Further Analysis of Status Quo
I f Code is …
I f Process is …
I f Customers
are ... Then Change OK OK Happy May be Fatal
Needs Fixes OKMildly
Unhappy Code only
OKNeeds Small
FixesMildly
UnhappyProcess
(I ncrementally)
Needs Fixes Needs Big
Fixes UnhappyProcess
(Revolutionary)
version 3.09
Slide 38CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M03
Summary• Organizations resist change and will
have many excuses for poor quality• You must understand and address
cultural issues• Software development quality
problems often stem from non-technical issues such as understanding the problem or being content with status quo
version 3.09
Slide 39CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M03
References• Hammer, Michael and James Champy,
Reengineering the Corporation - A Manifesto for Business Revolution, Harper Business Publishers, 1993, ISBN 0-88730-640-3.
• Satir, Virginia et al., The Satir Model, Family Therapy and Beyond, Palo Alto, CA., Science and Behavior Books, 1991.
• Weinberg, Gerald M., 1992, Quality Software Management, Volume 1, Systems Thinking, Dorset House, New York, ISBN 0-932633-22-6.
version 3.09
Slide 40CSE 8314 - SW Measurement and Quality EngineeringCopyright © 1995-2003, Dennis J. Frailey, All Rights Reserved CSE8314M03
END OFMODULE 03