Software Quality Assurance

(ITC- 704)
Lecture 03
Software Defects – Part 02

Dr. Zulfikar Ahmed Maher

Lecturer, ITC
Defect Repair Rates
 Reported data on defect repair rates is not consistent

 Defect repair rates usually decline as cyclomatic and essential

complexity increases.

 CYCLOMATIC COMPLEXITY is a software metric used to measure

the complexity of a program. It is a quantitative measure of
independent paths in the source code of the program. Independent
path is defined as a path that has at least one edge which has not
been traversed before in any other paths. Cyclomatic complexity can
be calculated with respect to functions, modules, methods or classes
within a program.
 Essential complexity is a measurement developed by Thomas
McCabe to determine how well a program is structured. It measures
the number of entry points, termination points, and nondeductible
nodes. The closer to 1 this value is, the more well structured the
program is.
2
Defect Repair Rates
 Defect repair rates increase with experience in
application, language, inspections, structured design
and coding methods
 Defect repair rates are higher for maintenance
specialists than others during maintenance phase
 For coding errors, they correlate with comment
density. IBM’s study concluded that 18% comment
density is ideal
 It also found, flow charts had no impact, but good
error messages had great impact

3
Defect Seeding
 Willful insertion of errors into a software
deliverable prior to a review, inspection,
or testing activity
 It is the quickest way of determining
defect removal efficiency
 Considered unpleasant by many

4
Defect Severity Levels
 Most software defect tracking systems
include a multi-tier “severity level” scale
 For example,
 Severity level 1: total failure of application
 Severity level 2: failure of major function(s)
 Severity level 3: minor problem
 Severity level 4: cosmetic problem

5
Defect Tracking
 It is important to use an accurate and
automated defect tracking system
 Defect tracking tools
 Tracking defects by severity level and by
origin
 Routing defects to appropriate repair
facility
 Keeping records of duplicate defects
 Invalid defects
 Repair information against defects
6
Defect Prevention

7
Defect Prevention
 We do not want defects or faults to
enter our work products, requirements,
design, code, or other documents
 We try to eliminate the error sources in
defect prevention
 Defect prevention is very difficult to
understand, study, and quantify

8
Philosophy of Defect Prevention
 If human misconceptions are the error
sources, education and training can
help us remove these error sources
 If imprecise designs and
implementations that deviate from
product specifications or design
intentions are the causes for faults,
formal methods can help us prevent
such deviations
9
Philosophy of Defect Prevention
 If non-conformance to selected
processes or standards is the problem
that leads to fault injections, then
process conformance or standard
enforcement can help use prevent the
injection of related faults
 If certain tools or technologies can
reduce fault injections under similar
environments, they should be adopted
10
Education and Training
 Education and training provide people-
based solutions for error source
elimination
 The people factor is the most important
factor that determines the quality and,
ultimately, the success or failure of
most software projects

11
Education and Training
 Education and training of software
professionals can help them control,
manage, and improve the way they
work

12
Focus of Education & Training
 Product and domain specific knowledge
 Software development knowledge and
expertise
 Knowledge about Development
methodology, technology, and tools
 Development process knowledge

13
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
 Software Development Knowledge and
Expertise
 Knowledge about Development Methodology,
Technology, and Tools
 Development Process Knowledge
14
Formal Methods
 Formal methods are system design techniques that
use rigorously specified mathematical models to build
software and hardware systems. In contrast to other
design systems, formal methods use mathematical
proof as a complement to system testing in order to
ensure correct behavior.
 Formal methods provide a way to eliminate certain
error sources and to verify the absence of related
faults
 Formal methods include
 Formal specification

 Formal verification
15
Formal Specification
 Formal specification is concerned with
producing an unambiguous set of
product specifications so that customer
requirements, as well as environmental
constraints and design intentions, are
correctly reflected, thus reducing the
chances of accidental fault injections

16
Formal Verifications
 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

17
Other Defect Prevention
Approaches
 Formal requirements analysis, i.e., JAD
 Joint Application Development (JAD) involves continuous
interaction with the users and different designers of the
system in development. JAD process brings the experts
together so that they can share their views with each
other and share ideas for development.
 Formal risk-analysis early in the development
 Prototyping
 Structured programming methods
 Certified reusable design and code components

18
Software Defect Prevention
Req. Design Code Document Perf.
Defects Defects Defects Defects Defects

JAD Excellent Good N/A Fair Poor

Prototypes Excellent Excellent Fair N/A Excellent

Structured Fair Good Excellent Fair Fair

Methods

CASE Tools Fair Good Fair Fair Fair

Blueprints / Excellent Excellent Excellent Excellent Good

Reusable Code

QFD Good Excellent Fair Poor Good

19