CHAPTER 2

What is software quality

Chapter objectives
After completing this chapter, you will be able to:
•Define software, software quality and software quality assurance.
•Distinguish between software errors, software faults and
software failures.
•Identify the various causes of software errors.
•Explain the objectives of software quality assurance activities.
•Distinguish and explain the difference between software quality
assurance and quality control.
•Explain the relationship between software quality assurance and
software engineering.
Software- IEEE definition

• Software is:
Computer programs, procedures, and possible
associated documentation and data necessary to
the operation of a computer system.
Software components
Software components include:
•Computer programs ( “ the code”)
•Procedures
•Documentation
•Data necessary for operating the software system.

All four components are needed in order to assure the

quality of the software development process and the
coming years of maintenance services for the following
reasons:
 Software components
• Computer programs (the “code”) are needed to activate the
computer to perform the required applications.
• Procedures are required, to define the order and schedule in
which the programs are performed, the method employed, and the
person responsible for performing the activities.
• Documentation are needed for developers, users and maintenance
personnel.
• The development documentation (the requirements report, design reports,
program descriptions, etc.) allows efficient cooperation and coordination among
development team members and efficient reviews and inspections of the design
and programming products.
• The user’s documentation (the “user’s manual”, etc.) provides a description of
the available applications and the appropriate method for their use
• The maintenance documentation (the “programmer’s software manual”, etc.)
provides the maintenance team with all the required information about the
code, and the structure and tasks of each software module. This information is
used when trying to locate causes of software failures (“bugs”) or to change or
add to existing software.
• Data including parameters, codes and name lists are necessary for
operating the software.
Software Errors, Faults, and
Failures
• “We’ve used the Simplex HR software in our Human
Resources Department for about three years and we have
never had a software failure.”
• “I started to use Simplex HR two months ago; we had so many
failures that we are considering replacing the software
package.”
• “We have been using the same software package for almost
four years. We were very satisfied throughout the period until
the last few months, when we suddenly faced several severe
failures. The Support Center of the software house from which
we bought the package claims that they have never
encountered failures of the type we experienced even though
they serve about 700 customers who utilize Simplex HR.”
Software Errors, Faults, and Failures

Can a software package that successfully served an

organization for a long period suddenly change its
nature (quality) and become “bugged”?

The answer is Yes.

 Software Errors, Faults, and Failures
• Software errors: are sections of the code that are partially
or totally incorrect as a result of a grammatical, logical or
other mistake made by a systems analyst, a programmer,
or another member of the software development team.
 Syntax (grammatical) error
 Logic error (multiply vice add two operands)
Software faults: are software errors that cause the
incorrect functioning of the software during a specific
application. Erroneous code lines will not affect the
functionality of the software as a whole; in a part of these
cases, the fault will be corrected or “neutralized” by
subsequent code lines.
Software Errors, Faults, and Failures
Software failures: are activated software faults,
that is, when a user tries to apply the specific
software section that is faulty.

So, the root of any software failure is a software

error.
Software Errors, Faults, and Failures
Not all software errors becomes software faults.
That part of the software may not be executed
• (An error is present but not encountered….)

We are interested mainly in the software failures that hurt

our use of the software.

Do all software faults end with software failures?

the answer is Not necessarily:
A software fault becomes a software failure only when it
is “ activated” .
 11

Software errors, software faults and

software failures
Software development process

software error
software fault

software
failure
 The Causes of Software Errors
• As software errors are the cause of poor software quality, it is
important to investigate the causes of these errors in order to
prevent them.
• A software error can be “code error”, a “procedure error”, a
“documentation error”, or a “software data error”
• The causes of all these errors are human, made by systems
analysts, programmers, software testers, documentation
experts, managers and sometimes clients and their
representatives.
 The Causes of Software Errors
• The causes of software errors can be further classified as
follows:

1.Faulty requirements definition.

2.Client-developer communication failures
3.Deliberate deviations from software requirements
4.Logical design errors
5.Coding errors
6.Shortcomings of the testing process
7.Documentation error
Faulty requirements definition
• Usually prepared by the clients, most
common errors are:
• False definition of requirements
• Absence of vital requirements.
• Incomplete definition of requirements
• For example, a tax discount granted to senior citizens, parents of
large families, and so forth. Unfortunately, a discount granted to
students was not included in the requirements document.
• Inclusion of unnecessary requirements that are
not expected to be used in the near future
Client-developer communication failures
• such error can be occurred in the early stages
of development process:
• Misunderstanding of the client’s instructions as
stated in the requirement document.
• Misunderstanding of the client’s requirements
changes presented (written or orally) to developer
during the development period
• Lack of attention of client messages during
development process
Deliberate deviations from software
requirements
• The most common situations of deliberate deviation are:
• The developer reuse software modules from old projects
• Due time or budget issues, the developer decides to omit part
of required functions
• Developer Initiated, unapproved improvements to the
software, introduced without the client’s approval
• Frequently disregard requirements that seem minor to the
developer. Such “minor” changes may, eventually, cause
software errors.
 Logical design errors
• Software errors can enter the system when the
professionals who design the system – systems architects,
software engineers, analysts, etc. – formulate the software
requirements. Typical errors include:
• Definitions that represent software requirements by
means of false algorithm
• Process definitions that contain sequencing errors
• False definition of boundary conditions.
• Client: discount for purchase more than 3 time
• Analyst: discount for purchase 3 times or more
 Logical design errors
• Omission of required software system states
• For example, the analyst did not define the needed reaction when the
temperature is over 120°C and the pressure is between 6 and 8
atmospheres.
• Omission system reaction to illegal operation
• For example, the software system is required to limit the sales to 10 tickets
per customer. Accordingly, any request for the purchase of more than 10
tickets is “illegal”. In his design, the analyst included a message stating that
sales are limited to 10 tickets per customer, but did not define the system’s
reaction to the case where a customer (who might not have listened carefully
to the message) keys in a number higher than 10. When performing the
illegal request, a system “crash” is to be expected as no computerized
reaction was defined for this illegal operation.
Coding Errors
• Misunderstanding the design documentation
• Errors in the application of CASE and other
development tools, errors in data selection.
• Linguistic errors in the programming language.
Shortcomings of the testing process
• Shortcomings of the testing process affects the
error rate by leaving a greater number of errors
undetected or uncorrected.
• These shortcomings result from the following
causes:
• Incomplete test plans leave untreated parts of the software or
application.
• Failures to document and report detected errors and faults
• Incomplete correction of detected errors due to negligence or time
pressures or the indications of the reasons for the faults.
Documentation errors
• Such as, errors in the user manuals. Typical errors of
this type are:
• Omission of software functions.
• Errors in the explanations and instructions given to users,
resulting in “dead ends” or incorrect applications.
• Listing of non-existing software functions, that is, functions
planned in the early stages of development but later dropped,
and functions that were active in previous versions of the
software but cancelled in the current version.
Software quality-IEEE definition:
Software quality is:

1-The degree to which a system, component, or

process meets specified requirements.

2- The degree to which a system, component, or

process meets customer or user needs or
expectations.
Software quality-Other definitions
Quality means conformance to requirements
Crosby 1979.
This mean that errors included in the software specification are not
considered and do not reduce the software quality?!!!!

Quality consists of those products features which meet the needs

of customers and thereby provide product satisfaction.

Quality consists of freedom from deficiencies

Juran, 1988.
The main deficiency of this definition is the fact that it frees the customer
of any professional responsibility for the accuracy and completeness of
the software specifications
Software Quality-Pressman's definition
• Additional aspects of software quality are included in the
definition suggested by Pressman.

Software quality is defined as:

Conformance to explicitly stated functional and

performance requirements, explicitly documented
development standards, and implicit characteristics
that are expected of all professionally developed
software.
Software Quality-Pressman's definition
Pressman's definition suggest three requirements
for quality assurance that are to be met by the
developer :

1- Specific functional requirements, which refer

mainly to the output of the software system.

2- The software quality standards mentioned in the

contract.
Software Quality-Pressman's definition
3- Good software engineering practices (GSEP),
reflecting state-of-the-art professional practices,
to be met by the developer even though not
explicitly mentioned in the contract
Software Quality Assurance-The IEEE
definition
A planned and systematic pattern of all actions
necessary to provide adequate confidence that an
item or product conforms to established technical
requirements.
Software Quality Assurance-The IEEE
definition
• Despite its emphasis on planning and systematic
implementation, the IEEE definition excludes
maintenance, timetable and budget issues.

• The main deviations from the IEEE definition are:

-SQA should not be limited to the development

process. Instead, it should be extended to cover the
long years of service subsequent to product delivery.
Software Quality Assurance-The IEEE
definition

- SQA actions should not be limited to the technical

aspects of the functional requirements, but should
include also activities that deal with scheduling and the
budget.
• The reasoning behind this expansion in scope is the close
relationship between timetable or budget failure and the meeting of
functional technical requirements
 SQA- Expanded definition
A systematic, planned set of actions necessary to provide
adequate confidence that the software development process
or the maintenance process of a software system product
conforms to established functional technical requirements as
well as with the managerial requirements of keeping the
schedule and operating within the budgetary limits.
Table 2.2 compares elements of the expanded SQA definition
with:
■ The IEEE SQA definition
■ The relevant ISO 9000-3 sections
■ Capacity Maturity Model (CMM).
The CMM is based on knowledge acquired from software process assessments and
extensive feedback from both industry and government. The model provides
organizations with more effective guidance for establishing process improvement
programs.
 ISO 9000
• The ISO 9000 family addresses various aspects of quality
management and contains some of ISO’s best known
standards.
• The standards provide guidance and tools for companies and
organizations who want to ensure that their products and
services consistently meet customer’s requirements, and that
quality is consistently improved.
• Standards in the ISO 9000 family include:
• ISO 9001:2015 - sets out the requirements of a quality management system
• ISO 9000:2015 - covers the basic concepts and language
• ISO 9004:2009 - focuses on how to make a quality management system more
efficient and effective
• ISO 19011:2011 - sets out guidance on internal and external audits of quality
management systems.
 Software quality assurance vs.
software quality control
• Two phrases are constantly repeated within the context of software
quality:
• “Quality control” and “quality assurance”. Are they synonymous? How
are they related?

• Quality control is defined as “a set of activities designed to evaluate the

quality of a developed or manufactured product” (IEEE, 1991); in other
words, activities whose main objective is the withholding of any product
that does not qualify.
• Quality control inspection and other activities take place as the
development or manufacturing of the product is completed yet before the
product is shipped to the client
Software quality assurance vs.
software quality control
• The main objective of quality assurance is to
minimize the cost of guaranteeing quality by a
variety of activities performed throughout the
development and manufacturing processes
stages.
• These activities prevent the causes of errors, and
detect and correct them early in the development
process.
Software quality assurance vs.
software quality control
(1) Quality control and quality assurance activities serve
different objectives.
(2) Quality control activities are only a part of the total
range of quality assurance activities.
The objectives of SQA activities:
• The objectives of SQA activities refer to the functional, managerial and
economic aspects of software development and software maintenance.
• Software development:
1- Assuring an acceptable level of confidence that the software will
conform to functional requirements.
2- Assuring an acceptable level of confidence that the software will
conform to managerial scheduling and budgetary requirements.
3- Initiating and managing of activities for the improvements and
greater efficiency of software development and SQA activities.
This means improving the prospects that the functional and
managerial requirements will be achieved while reducing the costs
of carrying out the software development and SQA activities
The objectives of SQA activities
• Software maintenance
1. Assuring with an acceptable level of confidence that the
software maintenance activities will conform to the functional
technical requirements.
2. Assuring with an acceptable level of confidence that the
software maintenance activities will conform to managerial
scheduling and budgetary requirements.
3. Initiating and managing activities to improve and increase the
efficiency of software maintenance and SQA activities. This
involves improving the prospects of achieving functional and
managerial requirements while reducing costs.
Relationship between Software engineering
and SQA
• Software engineering is the application of a systematic,
disciplined, quantifiable approach to the development,
operation and maintenance of software.
• The characteristics of software engineering, especially its
systematic, disciplined and quantitative approach, make
software engineering a good environment for achieving SQA
objectives.
• Cooperation between software engineers and the SQA team
is the way to achieve efficient and economic development
and maintenance activities that, at the same time, assure the
quality of the products of these activities