2162ICT Software Quality Principles

Introduction to Software Quality

R.G. Dromey

© R.G.Dromey, Griffith University, 2005

 "Maintainability, is par excellence,
a yardstick by which the quality
of software can be judged.
Paradoxical as it may seem,
software that has been developed
with a view to being changed is
likely to need changing less than
any other. It will be quality software”

Manns and Coleman

 Software Quality
At the highest level software quality
is a body of knowledge that describes:

• what must be done, and

• how it must be done

In other words the field of software quality

embodies a specification and an
implementation of processes for realizing
quality software.
 Quality Software

DEFINITION
Is software that exhibits all the functional
capabilities and non-functional attributes that
ensure that it can be put to all its intended
uses with the least effort, inconvenience
and resource cost to the user.
 Quality Software
This definition implies two things:

• software should function correctly with

respect to a specification that has been
predefined by the client who has
commissioned the development of
the software

• software must possess attributes other

than correctness with respect to a
specification before it can be classifies
as quality software
Quality Software
The International standard for  Software Product 
Evaluation :  ISO­9126 released in 1991 lists six 
key factors that are important in the production of 
quality software. They are: 
 
•   functionality 
 
•   reliability 
 
•   usability 
 
•   efficiency 
 
•   maintainability 
 
•   portability 
 Quality Software

Translating  these  (and  possibly  others  like 

reusability and assessability) high­level   quality 
requirements into meaningful constructive design 
and  implementation  principles  represents  one  of 
the  greatest  challenges  facing    software 
engineers 
Quality Software and Software Quality
In our study of these concepts we must be wary 
of   placing too much reliance on over­simplified 
and  highly abstract definitions to guide and build 
our  understanding. 
 
It would be very convenient if we could say: 
 
    "Quality is . . . " 
 
    "Software quality is . . . " 
 
If we are not careful " XXXX is  . . . " definitions 
can  severely limit and distract us from gaining a 
useful understanding of such concepts. 
 Some Simplistic Definitions

  CROSBY 
  "Quality is conformance to requirements"    
                 
  OULD 
  "Software quality means fitness­for­purpose" 
                   
  ISO­8402 
  Quality is all the features that allow a product 
 to  satisfy  stated  or  implied  needs  at  an 
affordable cost   
 Watts Humphrey – Software Process View
• Talented people are the most important element

• Even the best professionals need a structured

and disciplined environment to do cooperative
work

• Super programmers/designers is a myth

• No technology is going to solve the quality

problem – but it may help.

• Software process management is way to go.

Watts Humphrey – Controlling Chaos

1. Plan the work

3. Track and maintain the plan

5. Divide work into independent parts

7. Precisely define the requirements

for each part

5. Rigorously control the relationships

among the parts
Watts Humphrey – Controlling Chaos

1. Treat software development as a

learning process

4. Recognise what you don’t know.

6. When the gap between your knowledge

and the task is severe, fix it before
proceeding

9. Manage, audit, and review the work

to ensure it is done as planned
Watts Humphrey – Controlling Chaos

10. Commit to your work and work to meet

your commitments.

11. Refine the plan as your knowledge of

the job improves.
 WHAT WE ARE UP AGAINST

If the problem of software quality had

been easy it would have been solved
long ago!
 WHAT WE WANT
Quality Software
Product

Cost-
Project Effective
Outcomes Solution
Sought

On Schedule
 Descartes’ Advice

“It is better not to proceed at all than to

proceed without method”.
Enemies of Software Quality
– Silver bullets and rocket science
– Lack of genuine commitment
– Lack of common culture and training
– Lack of mature process, discipline, measures
– Waffle, shelf standards and bureacracy
– Arrogance, egos, parochialism and politics
– Cost and schedule pressures
– Unwillingness to work to achieve quality
– Failure to identify & manage risks to quality
– Process focus --product neglect •••
 Software Quality Problem

Current problems we face with software

development can be traced to:

– Lack of clear understanding of what is meant

by “software quality”

– Failure to follow management and

development practices that are sufficient to
meet the needs of the task
 Current Situation

Need to understand present context for

software development

There is a heavy emphasis on

process which comes at a price

There has been a neglect of

software product quality
 CRITICAL QUESTION

What is needed to produce quality

software?
Lessons From Engineering

Quality tackled differently

The Push-chair example :-

29 requirements - all product
Software safety - 115 process

Must satisfy stringent product

requirements.
 CONJECTURE
We must pay much more careful
attention to the tangible properties
of software in order to build better
software.

This is not the whole story but it is

an important part of it.
Approaches to Software Quality

Watch what
Curative happens and
(reactive) respond

Preventative Make things

(pro-active) happen
Desirable Software Quality Strategy

Curative Preventative
Approach Shifting
Approach

(expensive) (cost-effective)
Focus
Preventative Strategy - Advantages

• Allows to build-in or engineer-in

tangible properties that imply
high-level quality attributes.

• Is constructive - provides direct

guidance to designers and
programmers.
 Need a

Quality Model

Framework
 Key Ideas
There are four key ideas that underpin most of 
what we will discuss in this course. 
 
  Process 
It is generally accepted that the quality of the 
process  plays  a  crucial  role  in  determining 
the quality of the product 
 
  That is  "the means determines the end" 
 
  Constructive Principle 
  Quality must be built into software from the 
    outset ­ it cannot be added on later 
 
       Work­Products 
        Work­products must be clearly defined. 
 
  People 
Above  all  else  it  is  people  that  determine 
whether on not a quality product is produced 
Personal View on Producing Quality Software
1. You need to build a system out of it requirements
if you are to have any hope of controlling the
complexity – must account for short-term memory.

2. You need to find defects as early as possible.

Creating an integrated view of requirements
is a very effective way of finding defects.

---- need integrated view of functional reqs.

---- need integrated view of data requirements.

12.Need clearly defined processes that produce

clearly defined work-products
Functional Requirements Problems
• they may be incomplete, inconsistent
and/or contain redundancy

• they may not accurately convey

the intent of the stakeholders.

• the number and complexity of

the set of requirements may
tax people’s short-term memory
beyond it limits.

• intention may not be preserved

when requirements are converted
to some other representation(s)
during analysis/design.
 General References
P. Crosby, "Quality is Free", McGraw­Hill, N.Y., 
  1979 
 
R.G.Dromey, A.D.McGettrick, "On Specifying 
Software Quality", Software Quality Journal, Vol. 
1   (1), 1­31, May 1992 
 
D.A. Garvin, "What Does 'Product Quality' Really 
Mean", Sloan Management Review, 25­43, 1984 
 
M. Ould, "Quality Control and Assurance" in 
"Handbook of Software Engineering",J.McDermid 
(ed.), Butterworth, London, 1991.