Software Quality Assurance

Chapter # 2
What is Software Quality?
By:
Muhammad Imran
Assistant Prof. of Computer Science
Govt. Millat Degree College Mumtazabad, Multan

Lecturer (Visiting Faculty) of I.T

University of Education (Multan Campus) Multan
Ch # 1 (Software Quality Challenge) 2

What is software?
Software – IEEE definition

Software is:
Computer programs, procedures, and possibly associated documentation and data pertaining to
the operation of a computer system.
This definition lists the following four components of software:
■ Computer programs (the “code”)
■ Procedures
■ Documentation
■ Data necessary for operating the software system.

To sum up, software quality assurance always includes, in addition to code quality, the quality of
the procedures, the documentation and the necessary software data.

Software errors, faults and failures:

Failure: The inability of a system or component to perform its required functions within
specified performance requirements.
Fault: An incorrect step, process, or data definition in a computer program.
Error: A human action that produces an incorrect result. This could happen because of the
following reasons: some confusion in understanding the requirement of the software; some
miscalculation of the values; or/and misinterpretation of any value, etc

The origin of software failures lies in a software error made by a programmer. An error can be a
grammatical error in one or more of the code lines, or a logical error in carrying out one or more
of the client’s requirements. However, not all software errors become software faults. In other
words, in some cases, the software error can cause improper functioning of the software
in general or in a specific application. In many other cases, 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.
We are interested mainly in the software failures that disrupt our use of the software. This
requires us to examine the relationship between software faults and software failures. Do all
software faults end with software failures? Not necessarily: a software fault becomes a software
failure only when it is “activated” – when the software user tries to apply the specific, faulty
application. In many situations, a software fault is never activated due to the user’s lack of
interest in the specific application or to the fact that the combination of conditions necessary to
activate the fault never occurs.

Prepared By: Muhammad Imran

Assistant Prof. of Computer Science, Govt. Millat Degree College, Multan.
Lecturer (Visiting Faculty) of I.T, University of Education Multan Campus.
Ch # 1 (Software Quality Challenge) 3

Example : The “Meteoro-X” meteorological equipment firmware

The software requirements for “Meteoro-X” meteorological equipment firmware (software
embedded in the product) were meant to block the equipment’s operation when its internal
temperature rose above 60°C. A programmer error resulted in a software fault when the
temperature limit was coded as 160°. This fault could cause damage when the equipment was
subjected to temperatures higher than 60°. Because the equipment was used only in those coastal
areas where temperatures never exceeded 60°, the software fault never turned into a software
failure.

Software failure case study

 Therac-25
 The Therac-25 was a radiation therapy machine produced by Atomic Energy of
Canada Limited
 A software failure disaster.

Prepared By: Muhammad Imran

Assistant Prof. of Computer Science, Govt. Millat Degree College, Multan.
Lecturer (Visiting Faculty) of I.T, University of Education Multan Campus.
Ch # 1 (Software Quality Challenge) 4

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”. It should be
emphasized that the causes of all these errors are human, made by systems analysts,
programmers, software testers, documentation experts, managers and sometimes clients
and their representatives. Even in rare cases where software errors may be caused by the
development environment (interpreters, wizards, automatic software generators,
etc.), it is reasonable to claim that it is human error that caused the failure of the
development environment tool. The causes of software errors can be further classified as
follows according to the stages of the software development process in which they occur.

1. Faulty requirements definition

The faulty definition of requirements, usually prepared by the client, is one of the main causes of
software errors. The most common errors of this type are:
■ Erroneous definition of requirements.
■ Absence of vital requirements.
■ Incomplete definition of requirements.
■ Inclusion of unnecessary requirements,

2. Client–developer communication failures

Misunderstandings resulting from defective client–developer communication are additional
causes for the errors that prevail in the early stages of the development process:
■ Misunderstanding of the client’s instructions as stated in the requirement document.
■ Misunderstanding of the client’s requirements changes presented to the developer in written
form during the development period.
■ Misunderstanding of the client’s requirements changes presented orally to the developer during
the development period.
■ Misunderstanding of the client’s responses to the design problems presented by the developer.

3. Deliberate deviations from software requirements

In several circumstances, developers may deliberately deviate from the documented
requirements, actions that often cause software errors. The most common situations of
deliberate deviation are:

Prepared By: Muhammad Imran

Assistant Prof. of Computer Science, Govt. Millat Degree College, Multan.
Lecturer (Visiting Faculty) of I.T, University of Education Multan Campus.
Ch # 1 (Software Quality Challenge) 5

■ The developer reuses software modules taken from an earlier project without sufficient
analysis of the changes and adaptations needed to correctly fulfill all the new requirements.
■ Due to time or budget pressures, the developer decides to omit part of the required functions in
an attempt to cope with these pressures.
■ 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.

4. 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 erroneous algorithms.
■ Process definitions that contain sequencing errors.
■ Erroneous definition of boundary conditions. For example, the client’s requirements stated that
a special discount will be granted to customers who make purchases more than three times in
the same month. The analyst erroneously defined the software process to state that the discount
would be granted to those who make purchases three times or more in the same month.
■ Omission of required software system states. For example, a real-time computerized apparatus
is required to react according to a combination of temperatures and pressures. 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 of definitions concerning reactions to illegal operation of the software system.

5. Coding errors
A broad range of reasons cause programmers to make coding errors. These include
misunderstanding the design documentation, linguistic errors in the programming languages,
errors in the application of CASE and other development tools, errors in data selection, and so
forth.

6. Non-compliance with documentation and coding instructions

• Non-compliance with published templates (formats)
• Non-compliance with coding standards
Even if the quality of the “non-complying” software is acceptable, future handling of this
software (by the development and/or maintenance teams) is expected to increase the rate of
errors:

Prepared By: Muhammad Imran

Assistant Prof. of Computer Science, Govt. Millat Degree College, Multan.
Lecturer (Visiting Faculty) of I.T, University of Education Multan Campus.
Ch # 1 (Software Quality Challenge) 6

■ Team members who need to coordinate their own codes with code modules developed by
“non-complying” team members can be expected to encounter more than the usual number of
difficulties when trying to understand the software developed by the other team members.
■ The design review team will find it more difficult to review a design prepared by a non-
complying team.
■ The test team will find it more difficult to test the module; consequently, their efficiency is
expected to be lower, leaving more errors undetected.

7. Shortcomings of the testing process

Shortcomings of the testing process affect 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 portions of the software or the application functions and
states of the system.
■ Failure to promptly correct detected software faults as a result of inappropriate indications of
the reasons for the fault.
■ Incomplete correction of detected errors due to negligence or time pressures.

8. Procedure errors
Procedures direct the user with respect to the activities required at each step of the process. They
are of special importance in complex software systems where the processing is conducted in
several steps, each of which may feed a variety of types of data and allow for examination of the
intermediate results.

9. Documentation errors
The documentation errors that trouble the development and maintenance teams are errors in the
design documents and in the documentation integrated into the body of the software. These
errors can cause additional errors in further stages of development and during maintenance.
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.

Prepared By: Muhammad Imran

Assistant Prof. of Computer Science, Govt. Millat Degree College, Multan.
Lecturer (Visiting Faculty) of I.T, University of Education Multan Campus.
Ch # 1 (Software Quality Challenge) 7

OR
2. The degree to which a system, component, or process meets customer or user needs or
expectations.

■ “Quality means conformance to requirements” (Crosby, 1979).

■ “(1) Quality consists of those product features which meet the needs of
customers and thereby provide product satisfaction.
(2) Quality consists of freedom from deficiencies” (Juran, 1988).

Software quality – Pressman’s definition

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.
Pressman’s definition suggests three requirements for quality assurance:
1. Specific functional requirements
2. The software quality standards mentioned in the contract.
3. Good Software Engineering Practices (GSEP)

Software quality assurance – definition and objectives

Software quality assurance is:
1. A planned and systematic pattern of all actions necessary to provide adequate
confidence that an item or product conforms to established technical requirements.
2. A set of activities designed to evaluate the process by which the products are developed
or manufactured. Contrast with quality control.

SQA – expanded definition

Software quality assurance is:
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

Prepared By: Muhammad Imran

Assistant Prof. of Computer Science, Govt. Millat Degree College, Multan.
Lecturer (Visiting Faculty) of I.T, University of Education Multan Campus.
Ch # 1 (Software Quality Challenge) 8

conforms to established functional technical requirements as well as with the managerial

requirements of keeping the schedule and operating within the budgetary confines.

We will use the expanded definition of SQA, which will serve as the basis for the
inclusion and evaluation of various components of the SQA system.

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?

These two terms represent separate and distinct concepts:

■ 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. Accordingly, 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.

■ 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. As a result, quality assurance
activities substantially reduce the rate of products that do not qualify for shipment and, at
the same time, reduce the costs of guaranteeing quality in most cases.

To summarize the above concepts, we can say that:

Quality Control refers to the activities and techniques to verify that the developed
product is in conformance with the requirements. The ultimate output of both processes is
to deliver a quality product.

Quality Assurance is the set of activities that determine the procedures and standards to
develop a product.

The objectives of SQA activities

Prepared By: Muhammad Imran
Assistant Prof. of Computer Science, Govt. Millat Degree College, Multan.
Lecturer (Visiting Faculty) of I.T, University of Education Multan Campus.
Ch # 1 (Software Quality Challenge) 9

Software development (process-oriented):

1. Assuring an acceptable level of confidence that the software will conform to
functional and technical 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 improvement 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.
Software maintenance (product-oriented):
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.

Software Quality Assurance and Software Engineering:

According to the IEEE (1991), software engineering is defined as follows:
(1) The application of a systematic, disciplined, quantifiable approach to the
development, operation and maintenance of software; that is, the application of
engineering to software.
(2) The study of approaches as in (1).
The characteristics of software engineering, especially the systematic, disciplined and
quantitative approach at its core, make the software engineering environment a good
infrastructure for achieving SQA objectives. The methodologies and tools that are applied
by software engineering determine, to a considerable extent, the level of quality to be
expected from the software process and the maintenance services. Therefore, it is
desirable that when making decisions about software methodologies and tools, SQA
considerations be added to the efficiency and economy considerations associated with
software engineering. It is commonly accepted that cooperation between software
engineers and the SQA team is the appropriate way to achieve efficient and economic
development and maintenance activities that, at the same time, assure the quality of the
product of these activities.
Prepared By: Muhammad Imran
Assistant Prof. of Computer Science, Govt. Millat Degree College, Multan.
Lecturer (Visiting Faculty) of I.T, University of Education Multan Campus.
Ch # 1 (Software Quality Challenge) 10

Prepared By: Muhammad Imran

Assistant Prof. of Computer Science, Govt. Millat Degree College, Multan.
Lecturer (Visiting Faculty) of I.T, University of Education Multan Campus.