software quality assurance

1. INTRODUCTION
Software Quality Assurance
Lecture#01
1

2. OVERVIEW
• An Initial Definition of (Software) Quality
• Standard Definitions of (Software) Quality
• Quality Problems in Large Software
• SQE for Meeting Quality Expectations
• The SQE Process
• Scope of Major SQE Activities
2

3. INITIAL DEFINITION
• Quality can mean different
things to different people
• Quality =
• meeting the customer’s
requirements,
• at the agreed cost,
• within the agreed timescales.
• Quality = “Fitness for
purpose”
• Quality = Customer
satisfaction
3

4. STANDARD DEFINITIONS OF
(SOFTWARE) QUALITY
• IEEE Glossary: Degree to which a system, component, or
process meets
• (1) specified requirements, and
• (2) customer or user needs or expectations
• ISO 8402: The totality of features and characteristics of a
product or service that bear on its ability to satisfy specified or
implied needs
4

5. ALTERNATE VIEW OF QUALITY
• Quality:
• is not absolute
• is multidimensional (can be difficult to quantify)
• has aspects that are not easy to measure
• assessment is subject to constraints (e.g., cost)
• is about acceptable compromises
• criteria are not independent (can conflict)

6. QUALITY CRITERIA
• Correctness
• Efficiency
• Flexibility
• Integrity
• Interoperability
• Maintainability
• Portability
• Reliability
• Reusability
• Testability
• Usability

7. QUALITY CONCEPTS
Variation control is the heart of quality control
• Quality of design
• refers to characteristics designers specify for the end product to be
constructed
• Quality of conformance
• degree to which design specifications are followed in manufacturing the
product
• Quality control
• series of inspections, reviews, and tests used to ensure conformance of a
work product (artifact) to its specifications
• Quality assurance
• auditing and reporting procedures used to provide management with
data needed to make proactive decisions

8. FIVE VIEWS OF SOFTWARE QUALITY
• Transcendental view: Quality is viewed to be something ideal. In this
case, no effort is made to express it using concrete measures.
• User view: In this view, the user is concerned with whether or not the
product is fit for use. The product should meet user needs and
expectations.
• Manufacturing view: In this view, quality is seen as conforming to
requirements.
• Product view: if a product is manufactured with good internal
characteristics then it will have good external qualities.
• Value-Based view: The central view in this case is how much a customer
is willing to pay for a certain level of quality.

9. QUALITY PROBLEMS IN LARGE
SOFTWARE
• Pervasive use of software - ubiquitous
• Growing reliance on software
• This reliance requires the software to function correctly over a long
time, to be easy to use, and so on
• Large software systems
• Software with MLOC (lean vs fat software)
• E.g. operating systems, DBMS, defense related software,
Command/Communication/Control (CCC) systems etc.
• Involve 100’s or 1000’s of people
• Developed over months or years
• Operate under diverse, unanticipated application environments
• Together, all these factors make it impossible to have a perfect
system
9

10. FAILED VS SUCCESSFUL
PROJECTS - PAST
• Why Software Quality Engineering is important ?
• Software crises examples in past
• London Ambulance Service
• The system was deactivated one day after its deployment due to many errors.
Most of them related to non-functional requirements such as: Safety,
Reliability and Usability
• Taurus (London Stock Exchange)
• 11 years late & 132 times over budget
• Denver Airport (Baggage handling system)
• See more examples from:
http://en.wikipedia.org/wiki/List_of_software_bugs
http://www.it-cortex.com/Examples_f.htm
1
0

11. FAILED VS SUCCESSFUL
PROJECTS - PRESENT
• Software crises continues
Boston, Massachusetts, April 23, 2009
New Standish Group report shows more project failing and less
successful projects
11

12. THE STANDISH GROUP'S REPORT,
"CHAOS SUMMARY 2020”
• “This year's results show a marked decrease in project success
rates, with 32% of all projects succeeding which are delivered
on time, on budget, with required features and functions”,
says Jim Johnson, chairman of The Standish Group
• “44% were challenged which are late, over budget, and/or with
less than the required features and functions”
• “24% failed which are cancelled prior to completion or
delivered and never used”
1
2

13. SQE FOR MEETING QUALITY
EXPECTATIONS
• People’s quality expectations for software systems they
use and rely upon are two-fold:
• The software systems must do the right things
• They must do the things right
• Validation & Verification
• In the first case the focus of the related activities is to
validate that the software system performs what is required
• In the latter case the focus of the related activities is to verify
that the implemented system performs or operates as
specified
1
3

14. MAIN TASKS FOR SOFTWARE
QUALITY ENGINEERING
• Quality planning: assures that
• Software development, evaluation, and acceptance standards are
developed, documented and followed
• The results of quality reviews are given to appropriate management
• That test results follow to acceptance standards
• Execution of selected QA or software validation and
verification activities
• Software testing is the most common and frequently used means to
ensure quality
• Measurement and analysis to provide convincing evidence to
demonstrate software quality to all parties involved
14

15. BEYOND TESTING
• Beyond testing, there are many other QA
alternatives/techniques
• inspection
• formal verification
• defect prevention
• fault tolerance etc
• Other QA techniques employ specific means to assure
software quality
1
5

16. THE SQE PROCESS
• All these QA activities need to be managed in an engineered process
– the software quality engineering process.
• Quality goals are set early in the product
• Strategies for QA selected, carried out, and monitored to achieve
these preset quality goals
16

17. SCOPE OF MAJOR SQE
ACTIVITIES
17
Software Quality Engineering
Quality Assurance
Testing