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


Contents• Fundamentals of Quality

Improvement• Excuses for Poor Quality• Characteristics of Software and

Software Culture• Characteristics of Software

Development• Summary

version 3.09


Fundamentals of Quality Improvement

version 3.09


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


Excuses for Poor Quality

version 3.09


“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


version 3.09


“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


version 3.09


“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?


version 3.09


The Crosby Motivation Method:

Start with the Cost of QualityMeasurethe Cost

of Quality

UnderstandHow toAchieveQuality

MotivateAchievement

of Quality

Understandthe Valueof Quality

version 3.09


“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


This is known as the “Lock-on” effect

version 3.09


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


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


Evolution vs Revolution

Natural tendency is to

deteriorate over time

Continuous Process Improvement

Periodic “Revolution”

Reinventing the Corporation

Michael Hammer

version 3.09


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


Assignment 2 - Deliverable

Write up the example in a general form, suitable for

presenting to the rest of the class.

version 3.09


Characteristics ofSoftware and Software

Culture

version 3.09


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


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


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


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


Software Culture Diagram

Common toAll

Common to aSubculture

version 3.09


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


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


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


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


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


The Change Process

CurrentState Change

regression

Productivityor

Qualityor

Cycle Timeor

Whatever

NewState

version 3.09


Characteristics of Software Development

version 3.09


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


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


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


“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


“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


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


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


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


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


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


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


END OFMODULE 03

module 03 the context for quality improvement

Documents