SOFTWARE QUALITY

ENGINEERING
Lecture 3
Iram Hina

BSSE-VI
 HADITH OF THE DAY

Iram Hina
BSSE-VI
 OVERVIEW

 Quality Assurance (QA)

 Classification Scheme for QA as Dealing with Defects
1. Defect Prevention
2. Defect Reduction (Defect Detection and Removal)
3. Defect Containment

Iram Hina
BSSE-VI
 CLASSIFICATION OF QA
ACTIVITIES
 Defect Prevention
 Defect Reduction
 Defection Containment

Iram Hina
BSSE-VI
 DEFECT PREVENTION
 Defect prevention through error blocking or error
source removal
 Prevent faults from being injected into the software
Errors are the missing or incorrect human actions
that lead to the injection of faults into software
systems
Directly correct or block these actions, or remove
the underlying causes for them

Iram Hina
BSSE-VI
 DEFECT PREVENTION
 Two generic ways:(defect prevention)
 Eliminating certain error sources, such as
eliminating ambiguities or correcting human
misconceptions
 Fault prevention or blocking: break the causal
relation between error sources and faults through
the use of certain tools and technologies,
enforcement of certain process and product
standards etc.

Iram Hina
BSSE-VI
 DEFECT REDUCTION
Defect reduction through fault detection and removal
 Detect and remove faults once they have been
injected
 Two categories:
 Inspection directly detects and removes faults

from the software code, design etc.

 Testing removes faults based on related failure

observations during program execution

Iram Hina
BSSE-VI
 DEFECT CONTAINMENT
Defect containment through failure prevention and
containment
 Containing the failures to local areas & no global
failures observable to users
 Limiting the damage
 Two generic ways:
 Fault tolerance techniques to break the causal relation

between local faults and global failures thus so that

local faults will not cause global failures, thus
“tolerating” these local faults

Iram Hina
BSSE-VI
 DEFECT CONTAINMENT
 Failure Containment measures to avoid catastrophic
consequences when the failure does occur, such as death,
personal injury, and severe property or environmental
damages. For example, failure containment for real-time
control software used in nuclear reactors may include
concrete walls to encircle and contain radioactive material
in case of reactor melt-down due to software failures.

Iram Hina
BSSE-VI
 DEALING WITH PRE-/POST-
RELEASE DEFECTS
 Pre-release
Defect prevention, detection, removal
Several approaches including development
methodologies, programming techniques,
debugging tools, testing, beta tests, (Controlled
field testing) etc.

10

Iram Hina
BSSE-VI
 DEALING WITH PRE-/POST-
 Post
RELEASE DEFECTS
Release
 defect containment (activities aim at minimizing the negative impact of
these remaining faults)
 Dormant defects (The faults left in the finished software products are
often called “dormant defects”, which may stay dormant for some time,
but have the potential of causing problems to customers and users of
the products)
 Known /unknown defects

 Defect containment techniques involve redundancies or

duplications, and require significantly more development
effort to design and implement related features.
 Bug reports
 Cost factor
 Reputation factor
11

Iram Hina
BSSE-VI
 DEFECT PREVENTION OVERVIEW

 Education and training

 Formal methods

 Process conformance and standards enforcement

 Tools and technologies

12

Iram Hina
BSSE-VI
 EDUCATION AND TRAINING
1. Education and training provide people-based
solutions for error source elimination
2. Education and training of software professionals
can help them control, manage, and improve the
way they work
3. The elimination of these human misconceptions
will help prevent certain types of faults from being
injected into software products

13

Iram Hina
BSSE-VI
 EDUCATION AND TRAINING
 Product and domain specific knowledge: If the people involved
are not familiar with the product type or application domain, there is a
good chance that wrong solutions will be implemented. For example,
developers unfamiliar with embedded software may design software
without considering its environmental constraints, thus leading to
various interface and interaction problems between software and its
physical surroundings.
 General software development knowledge and expertise
plays an important role in developing high-quality software products.
For example, lack of expertise with requirement analysis and product
specification usually leads to many problems and rework in
subsequent design, coding, and testing activities.

14

Iram Hina
BSSE-VI
 EDUCATION AND TRAINING
 Knowledge about the specific development methodologies and tools used
by the organization also plays an important role in developing high-quality
software products. For example, in an implementation of Clean room
technology (Mills et al., 1987b), if the developers are not familiar with the
key components of formal verification or statistical testing, there is little
chance for producing high-quality products.
 Knowledge about the software process used by the organization If the
project personnel do not have a good understanding of the development
process involved, there is little chance that the process can be implemented
correctly. For example, if the people involved in incremental software
development do not know how the individual development efforts for
different increments fit together, the uncoordinated development may lead to
many interface or interaction problems.

15

Iram Hina
BSSE-VI
 FORMAL METHODS
 Formal methods provide a way to eliminate certain error
sources and to verify the absence of related faults
 Include formal specification and formal verification

 In Formal specification, an unambiguous set of product

specifications given so that customer requirements, as well as
environmental constraints and design intentions, are correctly
reflected, thus reducing the chances of accidental fault
injections
 Formal verification checks the conformance of software
design or code against these formal specifications, thus
ensuring that the software is fault-free with respect to its
formal specifications
16

Iram Hina
BSSE-VI
 PROCESS CONFORMANCE
 Follow the processes demonstrated by standard Frameworks
i.e. ISO, FURPS, etc

TOOLS AND TECHNOLOGIES

 Use of appropriate tools and technologies
 Should not be obsolete

 Staff must be trained for those tools and technology

17

Iram Hina
BSSE-VI
 DEFECT REDUCTION
 Inspection
 Testing

 Other techniques

18

Iram Hina
BSSE-VI
 DEFECT REDUCTION
 Software inspections are critical examinations of software
artefacts by human inspectors aimed at discovering and
fixing faults in the software systems. Inspection is a well-
known QA alternative familiar to most experienced software
quality professionals.
 The earliest and most influential work in software inspection
is Fagan inspection (Fagan, 1976).
 Various other variations have been proposed and used to
effectively conduct inspection under different environments

19

Iram Hina
BSSE-VI
 INSPECTION
 Inspections are critical reading and analysis of software code or
other software artefacts, such as designs, product specifications,
test plans, etc.
 Inspections are typically conducted by multiple human
inspectors, through some coordination process. Multiple
inspection phases or sessions might be used.
 Faults are detected directly in inspection by human inspectors,
either during their individual inspections or various types of
group sessions.
 Identified faults need to be removed as a result of the
inspection process, and their removal also needs to be verified.

20

Iram Hina
BSSE-VI
 INSPECTION
 The inspection processes vary, but typically include some planning and
follow-up activities in addition to the core inspection activity.
 The formality and structure of inspections may vary, from very informal
reviews and walkthroughs, to fairly formal variations of Fagan inspection, to
correctness inspections approaching the rigor and formality of formal
methods
 Informal reviews:
 self conducted reviews/walkthroughs
 independent reviews (and their coordination)
 Formal inspections:
 Fagan inspection
 Gilb inspection

21

Iram Hina
BSSE-VI
 INSPECTION
 Fagan inspection is a structured process of trying to find
defects in development documents such as programming code,
specifications, designs and others during various phases of the
software development process. It is named after Michael Fagan
who is credited with being the inventor of formal software
inspections
 Gilb’s Inspection:
 Establishment and evaluation of a framework for
performing software inspections based on Tom Gilb's
inspection method, covering all development phases and
work products

22

Iram Hina
BSSE-VI
 INSPECTION
 Inspection is most commonly applied to code, but it could also be applied to
requirement specifications, designs, test plans and test cases, user manuals,
and other documents or software artefacts
 Inspection can be used throughout the development process, particularly
early in the software development before anything can be tested
 Consequently, inspection can be an effective and economical QA alternative
because of the much increased cost of fixing late defects as compared to
fixing early ones
 Another important potential benefit of inspection is the opportunity to
conduct causal analysis during the inspection process, for example, as an
added step in Gilb inspection. These causal analysis results can be used to
guide defect prevention activities by removing identified error sources or
correcting identified missing/incorrect human actions.

23

Iram Hina
BSSE-VI
 TESTING?
NEXT LECTURE

24

Iram Hina
BSSE-VI
 END OF LECTURE

THANK YOU !

QUESTIONS?

25

BSSE-VI Iram Hina