1. Module 03 The Context for Quality Improvement
SMU CSE 8314 / NTU SE 762-N Software Measurement and Quality Engineering
Module 03
The Context for Quality Improvement
version 3.09

2. Contents Fundamentals of Quality Improvement Excuses for Poor Quality
8/18/2001
Contents
Fundamentals of Quality Improvement
Excuses for Poor Quality
Characteristics of Software and Software Culture
Characteristics of Software Development
Summary
version 3.09
CSE8314

3. Fundamentals of Quality Improvement
version 3.09

4. Fundamentals of Quality Improvement
8/18/2001
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
CSE8314

5. Excuses for Poor Quality
version 3.09

6. “Our Quality Isn’t That Bad”
Excuses for Poor Quality
8/18/2001
“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
Lack of Motivation
Excuses
version 3.09
CSE8314

7. “All Software Has Bugs”
Excuses for Poor Quality
8/18/2001
“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
Lack of Motivation
Excuses
version 3.09
CSE8314

8. “It’s Not Possible to Improve”
Excuses for Poor Quality
8/18/2001
“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?
Lack of Motivation
version 3.09
CSE8314

9. The Crosby Motivation Method: Start with the Cost of Quality
8/18/2001
The Crosby Motivation Method: Start with the Cost of Quality
Measure
the Cost
of Quality
Understand
the Value
of Quality
If you don’t understand the value of quality you won’t improve it
This cycle continues indefinitely
Understand
How to
Achieve
Quality
Motivate
Achievement
of Quality
version 3.09
CSE8314

10. “If It Ain’t Broke, Don’t Fix It”
Excuses for Poor Quality
8/18/2001
“If It Ain’t Broke, Don’t Fix It”
This is known as the “Lock-on” effect
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
We build oxcarts just fine -- we don’t need to build cars.
Cluster analysis example -- papers reference each other
(Academic incest)
version 3.09
CSE8314

11. 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

12. Cultures Resist Change
8/18/2001
Cultures Resist Change
“People will always choose the familiar over the comfortable.”
Virginia Satir, family therapist
Therefore
Quality improvement involves looking at the Culture and the Environment.
Preserve the good while changing vs
Revolution
Example from anthropological study of development of language -- the only changes that work are those that permit preservation of the status quo
version 3.09
CSE8314

13. Evolution vs Revolution
8/18/2001
Evolution vs Revolution
Natural tendency is to deteriorate over time
Continuous Process Improvement
Periodic “Revolution”
Reinventing the Corporation
Michael Hammer
version 3.09
CSE8314

14. Assignment 2 - Study Your Organization
8/18/2001
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 quality OR
Find evidence in your organization that people resist learning about customer opinions
For example, what happens to customer complaints
version 3.09
CSE8314

15. Assignment 2 - Deliverable
8/18/2001
Assignment 2 - Deliverable
Write up the example in a general form, suitable for presenting to the rest of the class.
version 3.09
CSE8314

16. Characteristics of Software and Software Culture
version 3.09

17. What is Software? IEEE: Software consists of
8/18/2001
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
CSE8314

18. Culture: That which is common to all members of a group.
8/18/2001
What is Culture?
Culture: That which is common to all members of a group.
For example, sense of humor, musical and artistic tastes, beliefs & behaviors, shared experiences, forms of entertainment
version 3.09
CSE8314

19. 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

20. 8/18/2001
Software Culture
Software 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
CSE8314

21. Software Culture Diagram
8/18/2001
Software Culture Diagram
Common to a
Subculture
Common to
All
version 3.09
CSE8314

22. Cultures are Inherently Conservative
8/18/2001
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
Most business executives would not accept that their organization has parallels to native tribes in Borneo
version 3.09
CSE8314

23. Characteristics of Subcultures - I
8/18/2001
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
High school football team example
version 3.09
CSE8314

24. Characteristics of Subcultures - II
8/18/2001
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
CSE8314

25. 8/18/2001
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
CSE8314

26. 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

27. The Change Process New Current State State Change regression
8/18/2001
The Change Process
New
State
Current
State
Change
regression
Example -- a New Software Tool
Productivity or
Quality
Cycle Time
Whatever
version 3.09
CSE8314

28. Characteristics of Software Development
version 3.09

29. Conformance to Requirements is Not Enough
8/18/2001
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
CSE8314

30. Software Development is Mostly Design, Not Manufacturing
8/18/2001
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
CSE8314

31. Software Development Activities
8/18/2001
Software Development Activities
Define & Understand requirements
Top level Design
Documentation 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
Maximum
Automation
Creativity
version 3.09
CSE8314

32. 8/18/2001
“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
CSE8314

33. 8/18/2001
“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
The Application Domain must be Understood
version 3.09
CSE8314

34. Existing Patterns May Be Successful and Costly to Change
8/18/2001
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
CSE8314

35. Perfection May Not Be Justifiable
8/18/2001
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
CSE8314

36. Note: If change is required, it may be essential for survival
8/18/2001
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
CSE8314

37. Further Analysis of Status Quo
8/18/2001
Further Analysis of Status Quo
version 3.09
CSE8314

38. 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

39. 8/18/2001
References
Hammer, Michael and James Champy, Reengineering the Corporation - A Manifesto for Business Revolution, Harper Business Publishers, 1993, ISBN
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
version 3.09
CSE8314

40. 8/18/2001
END OF
MODULE 03
This sign indicates it is time for one of the two breaks in the class
version 3.09
CSE8314